On Wed, 2020-01-15 at 13:17 +0100, Greg KH wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On Tue, Jan 14, 2020 at 04:57:53PM +0100, Christian Gromm wrote:
> > This patch moves the struct device of the interface structure to
> > its
> > private section, because only the core should access it directly.
> > For
> > other entities an API is provided.
> 
> This feels "wrong".
> 
> Shouldn't the struct device in this structure be the thing that is
> handling the reference counting and sysfs integration for this
> structure?

Yes, that's right.

>   To put it as a "pointer" in a private section of the
> structure feels like it is now backwards.
> 
> What is this helping with?  Who was messing with the device structure
> here that needed to not mess with it?

Well, it's not that somebody was messing with it. It's just the
fact that somebody could. 

> 
> It's good that you are now releasing the memory for the device
> structure
> properly, but this still feels really wrong.  What is keeping the
> lifetime of this structure now that the device is removed from it?

It's the most_dev structure of the of USB module (or any other lower
adapter driver), which embeds the most_interface sturcture that 
contained the dev struct (which I moved to the private section).

The thing that might be confusing is that the place, where the parent 
structure with the device is being allocated, is not the same where
the device actually gets registered with the kernel. These are two
different kernel modules actually.

thanks,
Chris

> 
> thanks,
> 
> greg k-h
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to