On Fri, 2020-01-24 at 10:09 +0100, Greg KH wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > On Fri, Jan 24, 2020 at 08:56:56AM +0000, > Christian.Gromm@xxxxxxxxxxxxx wrote: > > On Thu, 2020-01-23 at 19:18 +0100, Greg KH wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you > > > know the content is safe > > > > > > On Thu, Jan 23, 2020 at 04:38:17PM +0100, Christian Gromm wrote: > > > > This patch makes the adapter drivers use their own device > > > > structures > > > > when registering a most interface with the core module. > > > > With this the module that actually operates the physical device > > > > is > > > > the > > > > owner of the device. > > > > > > Ick, why? The interface should be part of sysfs, right, and now > > > it > > > isn't? > > > > It still is. What has changed is that the device that actually > > represents the attached hardware is used (see probe function of > > the USB adapter driver for instance). > > Ah. Ick. odd... > > > > Who handles the lifetime rules of these interfaces now? Why > > > remove this? > > > > The struct device that is allocated when attaching a MOST device is > > handling the lifetime and the struct most_interface is > > representing this device in the kernel. Hence, registered with > > sysfs. > > > > This ensures that the device is present in the kernel until its > > physical stature is being detached from the system. > > The core driver is just the man in the middle that registers the > > bus and itself as the driver and organizes the configfs, sysfs and > > communication paths to user space. > > > > > > > > Why isn't the interface dynamically created properly? That > > > should > > > solve > > > the lifetime rules here, right? > > > > The interface is dynamically allocated. This happens inside the > > USB, DIM2, I2C etc. drivers. The struct most_interface is part of > > the container struct there. > > Ok, I'll take the first 7 of these patches and see what the end > result > looks like after that, it will make reviewing the code easier... Did you find some time for the review yet? thanks, Chris _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
