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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
