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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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