On Tue, Sep 26, 2023 at 07:00:51AM +0000, Wei Liu wrote: > On Tue, Sep 26, 2023 at 08:31:03AM +0200, Greg KH wrote: > > On Tue, Sep 26, 2023 at 05:54:34AM +0000, Wei Liu wrote: > > > On Tue, Sep 26, 2023 at 06:52:46AM +0200, Greg KH wrote: > > > > On Mon, Sep 25, 2023 at 05:07:24PM -0700, Nuno Das Neves wrote: > > > > > On 9/23/2023 12:58 AM, Greg KH wrote: > > > > > > Also, drivers should never call pr_*() calls, always use the proper > > > > > > dev_*() calls instead. > > > > > > > > > > > > > > > > We only use struct device in one place in this driver, I think that is the > > > > > only place it makes sense to use dev_*() over pr_*() calls. > > > > > > > > Then the driver needs to be fixed to use struct device properly so that > > > > you do have access to it when you want to print messages. That's a > > > > valid reason to pass around your device structure when needed. > > > > > > Greg, ACRN and Nitro drivers do not pass around the device structure. > > > Instead, they rely on a global struct device. We can follow the same. > > > > A single global struct device is wrong, please don't do that. > > > > Don't copy bad design patterns from other drivers, be better :) > > > > If we're working with real devices like network cards or graphics cards > I would agree -- it is easy to imagine that we have several cards of the > same model in the system -- but in real world there won't be two > hypervisor instances running on the same hardware. > > We can stash the struct device inside some private data fields, but that > doesn't change the fact that we're still having one instance of the > structure. Is this what you want? Or do you have something else in mind? You have a real device, it's how userspace interacts with your subsystem. Please use that, it is dynamically created and handled and is the correct representation here. thanks, greg k-h
