Re: [PATCH v4 01/10] staging: most: remove device from interface structure

2020-03-23 Thread Christian.Gromm
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
> 
> 
> 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...

Do you have a rough idea when I can expect this to be reviewed?

Should I resend one more time?


thanks,
Chris


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4 01/10] staging: most: remove device from interface structure

2020-02-14 Thread Greg KH
On Thu, Feb 06, 2020 at 09:14:55AM +, christian.gr...@microchip.com wrote:
> 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 +, 
> > christian.gr...@microchip.com 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?

I haven't, sorry.  Can you resend the movement patch so that I can just
see it from that point?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4 01/10] staging: most: remove device from interface structure

2020-02-06 Thread Christian.Gromm
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 +, 
> christian.gr...@microchip.com 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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4 01/10] staging: most: remove device from interface structure

2020-01-24 Thread Greg KH
On Fri, Jan 24, 2020 at 08:56:56AM +, christian.gr...@microchip.com 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...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4 01/10] staging: most: remove device from interface structure

2020-01-24 Thread Christian.Gromm
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).

> 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.

thanks,
Chris

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v4 01/10] staging: most: remove device from interface structure

2020-01-23 Thread Greg KH
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?  Who handles the lifetime rules of these interfaces now?  Why
remove this?

Why isn't the interface dynamically created properly?  That should solve
the lifetime rules here, right?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel