search for: visorbus

...- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/uncore.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 - arch/x86/kernel/cpu/vmware.c | 2 +- arch/x86/kernel/kvm.c | 2 +- drivers/staging/unisys/visorbus/visorchipset.c | 2 +- 6 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c index 7946c4231169..d5045c8e2e63 100644 --- a/arch/x86/events/intel/cstate.c +++ b/arch/x86/events/intel/cstate.c @@ -677,7 +677,7 @@ static int __in...

...- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/uncore.c | 2 +- arch/x86/include/asm/cpufeature.h | 1 - arch/x86/kernel/cpu/vmware.c | 2 +- arch/x86/kernel/kvm.c | 2 +- drivers/staging/unisys/visorbus/visorchipset.c | 2 +- 6 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c index 7946c4231169..d5045c8e2e63 100644 --- a/arch/x86/events/intel/cstate.c +++ b/arch/x86/events/intel/cstate.c @@ -677,7 +677,7 @@ static int __in...

...es the HW access > > (think PCI level things), and a 'hw driver' attaches to the bus > > device, > > This is not true, kernel had already had plenty virtual bus where virtual > devices and drivers could be attached, besides mdev and virtio, you can see > vop, rpmsg, visorbus etc. Sure, but those are not connecting HW into the kernel.. > > and instantiates a 'subsystem device' (think netdev, rdma, > > etc) using some per-subsystem XXX_register(). > > > Well, if you go through virtio spec, we support ~20 types of different > devices....

On Thu, Feb 13, 2020 at 10:56:00AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote: > > > That bus is exactly what Greg KH proposed. There are other ways > > > to solve this I guess but this bikeshedding is getting tiring. > > > > This discussion was for a different goal, IMHO. > > Hmm couldn't find it

On Thu, Feb 13, 2020 at 10:56:00AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote: > > > That bus is exactly what Greg KH proposed. There are other ways > > > to solve this I guess but this bikeshedding is getting tiring. > > > > This discussion was for a different goal, IMHO. > > Hmm couldn't find it

...'bus' driver provides the HW access > (think PCI level things), and a 'hw driver' attaches to the bus > device, This is not true, kernel had already had plenty virtual bus where virtual devices and drivers could be attached, besides mdev and virtio, you can see vop, rpmsg, visorbus etc. > and instantiates a 'subsystem device' (think netdev, rdma, > etc) using some per-subsystem XXX_register(). Well, if you go through virtio spec, we support ~20 types of different devices. Classes like netdev and rdma are correct since they have a clear set of semantics the...