[Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Luis R. Rodriguez]

I see some open slots for Monday, there is some overlap in interest
between the Audio workshop folks and the tech topic for Tuesday
"addressing complex dependencies". We seem to have come to some
arrangement to split topics up to avoid such overlap, but one subject
overlapping both, but that seems more appropriate for the core day is
"Generic drivers":

Having some generic device driver load, prior to a specific driver,
and issues / maintenance issues that come with the hacks currently in
place to support this / re-invent the wheel to support this per
subsystem.

It might be good then to move this to a Monday slot, provided most
interested folks can and will be there. Thoughts?

 Luis

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Jiri Kosina]

On Fri, 28 Oct 2016, Luis R. Rodriguez wrote:

> Having some generic device driver load, prior to a specific driver, and 
> issues / maintenance issues that come with the hacks currently in place 
> to support this / re-invent the wheel to support this per subsystem.
> 
> It might be good then to move this to a Monday slot, provided most 
> interested folks can and will be there. Thoughts?

As this is exactly the (current worked around in not a very nice way) 
problem of HID subsystem (hid-generic handling most of the devices "more 
or less fine", and then having drivers implementing "specific 
functionality on top"), I'd be very much interested in any discussion / 
ideas around this topic. I'll be there on monday.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Greg KH]

On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
> Having some generic device driver load, prior to a specific driver,
> and issues / maintenance issues that come with the hacks currently in
> place to support this / re-invent the wheel to support this per
> subsystem.

We have hacks for this today?  What do you mean by this, quirks?

People have been talking about this since the 2.4 days, but I have yet
to see any code for it.  I'd love to see something be proposed, with
code, but note, you need to be aware of why it's been only talked about
for that long without any code being written :)

Why can't this be done in email?

thanks,

greg k-h

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Luis R. Rodriguez]

On Fri, Oct 28, 2016 at 2:23 PM, Greg KH <greg@kroah.com> wrote:
> On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
>> Having some generic device driver load, prior to a specific driver,
>> and issues / maintenance issues that come with the hacks currently in
>> place to support this / re-invent the wheel to support this per
>> subsystem.
>
> We have hacks for this today?  What do you mean by this, quirks?

The thread in question was rather huge, this was just *one* of the
topics that came up, and I was not the one who brought it up.

> People have been talking about this since the 2.4 days, but I have yet
> to see any code for it.  I'd love to see something be proposed, with
> code, but note, you need to be aware of why it's been only talked about
> for that long without any code being written :)

Ah I see..

> Why can't this be done in email?

Perhaps, and if so then saves us time.

 Luis

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Jiri Kosina]

On Fri, 28 Oct 2016, Greg KH wrote:

> On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
> > Having some generic device driver load, prior to a specific driver,
> > and issues / maintenance issues that come with the hacks currently in
> > place to support this / re-invent the wheel to support this per
> > subsystem.
> 
> We have hacks for this today?  What do you mean by this, quirks?

I have to maintain a device-id list that explicitly enumerates "these 
devices can be handled by generic driver, but would better be handled by 
specific driver", in the generic driver itself. Which is horrible.

It'd be nice for the specific driver to be able to claim this property 
somehow.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Dmitry Torokhov]

On Fri, Oct 28, 2016 at 2:29 PM, Jiri Kosina <jikos@kernel.org> wrote:
> On Fri, 28 Oct 2016, Greg KH wrote:
>
>> On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
>> > Having some generic device driver load, prior to a specific driver,
>> > and issues / maintenance issues that come with the hacks currently in
>> > place to support this / re-invent the wheel to support this per
>> > subsystem.
>>
>> We have hacks for this today?  What do you mean by this, quirks?
>
> I have to maintain a device-id list that explicitly enumerates "these
> devices can be handled by generic driver, but would better be handled by
> specific driver", in the generic driver itself. Which is horrible.
>
> It'd be nice for the specific driver to be able to claim this property
> somehow.

Now that most of the environment is ready to handle hotplug, for HID
it should be doable: have hid-generic probe devices last and have
driver core recognize generic/vs tailored driver (flag?) and if device
matches tailored driver forcibly unbind from generic and allow
tailored to bind to the device. There will be window of time when
device is bound to a "wrong" driver, but because of hotplug who cares.

Thanks.

-- 
Dmitry

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Greg KH]

On Fri, Oct 28, 2016 at 02:38:13PM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 28, 2016 at 2:29 PM, Jiri Kosina <jikos@kernel.org> wrote:
> > On Fri, 28 Oct 2016, Greg KH wrote:
> >
> >> On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
> >> > Having some generic device driver load, prior to a specific driver,
> >> > and issues / maintenance issues that come with the hacks currently in
> >> > place to support this / re-invent the wheel to support this per
> >> > subsystem.
> >>
> >> We have hacks for this today?  What do you mean by this, quirks?
> >
> > I have to maintain a device-id list that explicitly enumerates "these
> > devices can be handled by generic driver, but would better be handled by
> > specific driver", in the generic driver itself. Which is horrible.
> >
> > It'd be nice for the specific driver to be able to claim this property
> > somehow.
> 
> Now that most of the environment is ready to handle hotplug, for HID
> it should be doable: have hid-generic probe devices last and have
> driver core recognize generic/vs tailored driver (flag?) and if device
> matches tailored driver forcibly unbind from generic and allow
> tailored to bind to the device. There will be window of time when
> device is bound to a "wrong" driver, but because of hotplug who cares.

"forcibly unbind" is the trick here, along with the fact of drivers not
being asked to match with devices already bound to a driver.  It might
be possible, I'd love to see patches to try it, given that the topic
comes up every other year or so...

thanks,

greg k-h

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Dmitry Torokhov]

On Fri, Oct 28, 2016 at 2:44 PM, Greg KH <greg@kroah.com> wrote:
> On Fri, Oct 28, 2016 at 02:38:13PM -0700, Dmitry Torokhov wrote:
>> On Fri, Oct 28, 2016 at 2:29 PM, Jiri Kosina <jikos@kernel.org> wrote:
>> > On Fri, 28 Oct 2016, Greg KH wrote:
>> >
>> >> On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
>> >> > Having some generic device driver load, prior to a specific driver,
>> >> > and issues / maintenance issues that come with the hacks currently in
>> >> > place to support this / re-invent the wheel to support this per
>> >> > subsystem.
>> >>
>> >> We have hacks for this today?  What do you mean by this, quirks?
>> >
>> > I have to maintain a device-id list that explicitly enumerates "these
>> > devices can be handled by generic driver, but would better be handled by
>> > specific driver", in the generic driver itself. Which is horrible.
>> >
>> > It'd be nice for the specific driver to be able to claim this property
>> > somehow.
>>
>> Now that most of the environment is ready to handle hotplug, for HID
>> it should be doable: have hid-generic probe devices last and have
>> driver core recognize generic/vs tailored driver (flag?) and if device
>> matches tailored driver forcibly unbind from generic and allow
>> tailored to bind to the device. There will be window of time when
>> device is bound to a "wrong" driver, but because of hotplug who cares.
>
> "forcibly unbind" is the trick here, along with the fact of drivers not
> being asked to match with devices already bound to a driver.  It might
> be possible, I'd love to see patches to try it, given that the topic
> comes up every other year or so...

We already allow forcibly unbinding via sysfs, so it should be
possible to do that when loading new driver.

Thanks.

-- 
Dmitry

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Laurent Pinchart]

On Friday 28 Oct 2016 14:51:36 Dmitry Torokhov wrote:
> On Fri, Oct 28, 2016 at 2:44 PM, Greg KH <greg@kroah.com> wrote:
> > On Fri, Oct 28, 2016 at 02:38:13PM -0700, Dmitry Torokhov wrote:
> >> On Fri, Oct 28, 2016 at 2:29 PM, Jiri Kosina <jikos@kernel.org> wrote:
> >> > On Fri, 28 Oct 2016, Greg KH wrote:
> >> >> On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
> >> >> > Having some generic device driver load, prior to a specific driver,
> >> >> > and issues / maintenance issues that come with the hacks currently
> >> >> > in
> >> >> > place to support this / re-invent the wheel to support this per
> >> >> > subsystem.
> >> >> 
> >> >> We have hacks for this today?  What do you mean by this, quirks?
> >> > 
> >> > I have to maintain a device-id list that explicitly enumerates "these
> >> > devices can be handled by generic driver, but would better be handled
> >> > by
> >> > specific driver", in the generic driver itself. Which is horrible.
> >> > 
> >> > It'd be nice for the specific driver to be able to claim this property
> >> > somehow.
> >> 
> >> Now that most of the environment is ready to handle hotplug, for HID
> >> it should be doable: have hid-generic probe devices last and have
> >> driver core recognize generic/vs tailored driver (flag?) and if device
> >> matches tailored driver forcibly unbind from generic and allow
> >> tailored to bind to the device. There will be window of time when
> >> device is bound to a "wrong" driver, but because of hotplug who cares.
> > 
> > "forcibly unbind" is the trick here, along with the fact of drivers not
> > being asked to match with devices already bound to a driver.  It might
> > be possible, I'd love to see patches to try it, given that the topic
> > comes up every other year or so...
> 
> We already allow forcibly unbinding via sysfs, so it should be
> possible to do that when loading new driver.

I expect many drivers to crash though, especially if userspace starts using 
the device and races with the unbind. Nothing new under the sun, drivers will 
need to be fixed, and the new CONFIG_DEBUG_TEST_DRIVER_REMOVE should help a 
bit. I however still believe the the cargo cult usage of devm_* functions in 
drivers has only gotten worse since I raised the issue last year.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Greg KH]

On Fri, Oct 28, 2016 at 11:29:00PM +0200, Jiri Kosina wrote:
> On Fri, 28 Oct 2016, Greg KH wrote:
> 
> > On Fri, Oct 28, 2016 at 02:16:59PM -0700, Luis R. Rodriguez wrote:
> > > Having some generic device driver load, prior to a specific driver,
> > > and issues / maintenance issues that come with the hacks currently in
> > > place to support this / re-invent the wheel to support this per
> > > subsystem.
> > 
> > We have hacks for this today?  What do you mean by this, quirks?
> 
> I have to maintain a device-id list that explicitly enumerates "these 
> devices can be handled by generic driver, but would better be handled by 
> specific driver", in the generic driver itself. Which is horrible.

Yes, I agree, but so far, it's the only way we know how :(

> It'd be nice for the specific driver to be able to claim this property 
> somehow.

I also agree, it would be "nice", but I have yet to see a way to do this
in a generic way :(

thanks,

greg k-h

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Rob Herring]

On Fri, Oct 28, 2016 at 4:16 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> I see some open slots for Monday, there is some overlap in interest
> between the Audio workshop folks and the tech topic for Tuesday
> "addressing complex dependencies". We seem to have come to some
> arrangement to split topics up to avoid such overlap, but one subject
> overlapping both, but that seems more appropriate for the core day is
> "Generic drivers":
>
> Having some generic device driver load, prior to a specific driver,
> and issues / maintenance issues that come with the hacks currently in
> place to support this / re-invent the wheel to support this per
> subsystem.

This is a looming, unsolved problem for DT as well. We can potentially
bind different drivers to same device if the device has multiple
compatible strings. There's not any control of which one binds first
either other than link or initcall order.

> It might be good then to move this to a Monday slot, provided most
> interested folks can and will be there. Thoughts?

I'd like to be there and won't be there on Mon.

BTW, is there a schedule for Tues published?

Rob

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Laurent Pinchart]

On Sunday 30 Oct 2016 21:13:34 Rob Herring wrote:
> On Fri, Oct 28, 2016 at 4:16 PM, Luis R. Rodriguez wrote:
> > I see some open slots for Monday, there is some overlap in interest
> > between the Audio workshop folks and the tech topic for Tuesday
> > "addressing complex dependencies". We seem to have come to some
> > arrangement to split topics up to avoid such overlap, but one subject
> > overlapping both, but that seems more appropriate for the core day is
> > "Generic drivers":
> > 
> > Having some generic device driver load, prior to a specific driver,
> > and issues / maintenance issues that come with the hacks currently in
> > place to support this / re-invent the wheel to support this per
> > subsystem.
> 
> This is a looming, unsolved problem for DT as well. We can potentially
> bind different drivers to same device if the device has multiple
> compatible strings. There's not any control of which one binds first
> either other than link or initcall order.
>
> > It might be good then to move this to a Monday slot, provided most
> > interested folks can and will be there. Thoughts?
> 
> I'd like to be there and won't be there on Mon.

This reminds me of a problem discussed a few years ago, about how to decide 
whether to automatically offload handling of functional clocks declared in DT 
to core code in an attempt to simplify drivers. The issue was that the 
decision had to be taken at a time the related driver(s) might not be 
available yet.

In any case, I'm interested in this topic.

> BTW, is there a schedule for Tues published?

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] Schedule slot suggestion- Generic drivers - core topic

[Theodore Ts'o]

On Sun, Oct 30, 2016 at 09:13:34PM -0500, Rob Herring wrote:
> On Fri, Oct 28, 2016 at 4:16 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> > I see some open slots for Monday, there is some overlap in interest
> > between the Audio workshop folks and the tech topic for Tuesday
> > "addressing complex dependencies". We seem to have come to some
> > arrangement to split topics up to avoid such overlap, but one subject
> > overlapping both, but that seems more appropriate for the core day is
> > "Generic drivers":
> >
> > Having some generic device driver load, prior to a specific driver,
> > and issues / maintenance issues that come with the hacks currently in
> > place to support this / re-invent the wheel to support this per
> > subsystem.
> 
> This is a looming, unsolved problem for DT as well. We can potentially
> bind different drivers to same device if the device has multiple
> compatible strings. There's not any control of which one binds first
> either other than link or initcall order.

So in general, sessions, either at the Kernel Summit, or the LPC,
which are of the form, "we should bell the cat", generally aren't
particularly productive.

>From what I can tell, people have hacks that mostly work, but they
take the form of hard-coded lists or quirk tables, and fact that they
are hacks are making people sad.  Is that a fair summary?

If people have ideas towards a better solution, or better yet, a
patch, and there is resistance to accepting the patch, or if there are
multiple competing solutions, then it's much more likely we would make
forward progress by scheduling a sessions.

Do we have something that makes it likely that we would make forwawrd
progress by scheduling such a session on Monday

> > It might be good then to move this to a Monday slot, provided most
> > interested folks can and will be there. Thoughts?
> 
> I'd like to be there and won't be there on Mon.
> 
> BTW, is there a schedule for Tues published?

There is are the Audio, RDMA, and Wireless workshops.  We also
currently have an "Addressing Complex Depndencies" session scheduled
for Tuesday at 9:30am.

Please see:

	https://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/schedule
and
	http://goo.gl/qtSi1v

Cheers,

				- Ted