* [TECH TOPIC] Driver probe fails and register succeeds
@ 2022-06-23 23:05 Shuah Khan
2022-06-23 23:13 ` Laurent Pinchart
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Shuah Khan @ 2022-06-23 23:05 UTC (permalink / raw)
To: ksummit, ksummit; +Cc: Shuah Khan
I have been debugging a driver probe failure and noticed that driver gets
registered even when driver probe fails. This is not a new behavior. The
code in question is the same since 2005.
dmesg will say that a driver probe failed with error code and then the very
next message from interface core that says driver is registered successfully.
It will create sysfs interfaces.
The probe failure is propagated from the drive probe routine all the way up to
__driver_attach(). __driver_attach() ignores the error and and returns success.
__device_driver_lock(dev, dev->parent);
driver_probe_device(drv, dev);
__device_driver_unlock(dev, dev->parent);
return 0;
Interface driver register goes on to create sysfs entries as if driver probe
worked. It handles errors from driver_register() and unwinds the register
properly, however in this case it doesn't know about the failure.
At this point the driver is defunct with sysfs interfaces. User has to run
rmmod to get rid of the defunct driver.
Simply returning the error from __driver_attach() didn't work as expected.
I figured it would fail since not all interface drivers can handle errors
from driver probe routines.
I propose that we discuss the scenario to find possible solutions to avoid
defunct drivers.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:05 [TECH TOPIC] Driver probe fails and register succeeds Shuah Khan @ 2022-06-23 23:13 ` Laurent Pinchart 2022-06-23 23:28 ` Shuah Khan 2022-06-23 23:24 ` Guenter Roeck 2022-06-24 6:31 ` Greg KH 2 siblings, 1 reply; 11+ messages in thread From: Laurent Pinchart @ 2022-06-23 23:13 UTC (permalink / raw) To: Shuah Khan; +Cc: ksummit, ksummit Hi Shuah, On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: > I have been debugging a driver probe failure and noticed that driver gets > registered even when driver probe fails. This is not a new behavior. The > code in question is the same since 2005. > > dmesg will say that a driver probe failed with error code and then the very > next message from interface core that says driver is registered successfully. > It will create sysfs interfaces. > > The probe failure is propagated from the drive probe routine all the way up to > __driver_attach(). __driver_attach() ignores the error and and returns success. > > __device_driver_lock(dev, dev->parent); > driver_probe_device(drv, dev); > __device_driver_unlock(dev, dev->parent); > > return 0; > > Interface driver register goes on to create sysfs entries as if driver probe > worked. It handles errors from driver_register() and unwinds the register > properly, however in this case it doesn't know about the failure. > > At this point the driver is defunct with sysfs interfaces. User has to run > rmmod to get rid of the defunct driver. > > Simply returning the error from __driver_attach() didn't work as expected. > I figured it would fail since not all interface drivers can handle errors > from driver probe routines. > > I propose that we discuss the scenario to find possible solutions to avoid > defunct drivers. This seems to be the expected behaviour to me. The probe failure doesn't necessarily indicate that the driver is at fault, it means that something went wrong when associating a particular device with the driver. It could be that the device is faulty for instance, and that shouldn't prevent the driver from being registered, especially if multiple instances of the device can be present in the system, as that would then prevent any of those instances from working due to one faulty device. What other behaviour would you expect ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:13 ` Laurent Pinchart @ 2022-06-23 23:28 ` Shuah Khan 2022-06-23 23:30 ` Laurent Pinchart 0 siblings, 1 reply; 11+ messages in thread From: Shuah Khan @ 2022-06-23 23:28 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit, ksummit On 6/23/22 5:13 PM, Laurent Pinchart wrote: > Hi Shuah, > > On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: >> I have been debugging a driver probe failure and noticed that driver gets >> registered even when driver probe fails. This is not a new behavior. The >> code in question is the same since 2005. >> >> dmesg will say that a driver probe failed with error code and then the very >> next message from interface core that says driver is registered successfully. >> It will create sysfs interfaces. >> >> The probe failure is propagated from the drive probe routine all the way up to >> __driver_attach(). __driver_attach() ignores the error and and returns success. >> >> __device_driver_lock(dev, dev->parent); >> driver_probe_device(drv, dev); >> __device_driver_unlock(dev, dev->parent); >> >> return 0; >> >> Interface driver register goes on to create sysfs entries as if driver probe >> worked. It handles errors from driver_register() and unwinds the register >> properly, however in this case it doesn't know about the failure. >> >> At this point the driver is defunct with sysfs interfaces. User has to run >> rmmod to get rid of the defunct driver. >> >> Simply returning the error from __driver_attach() didn't work as expected. >> I figured it would fail since not all interface drivers can handle errors >> from driver probe routines. >> >> I propose that we discuss the scenario to find possible solutions to avoid >> defunct drivers. > > This seems to be the expected behaviour to me. The probe failure doesn't > necessarily indicate that the driver is at fault, it means that > something went wrong when associating a particular device with the > driver. It could be that the device is faulty for instance, and that > shouldn't prevent the driver from being registered, especially if > multiple instances of the device can be present in the system, as that > would then prevent any of those instances from working due to one faulty > device. > Agreed. This behavior works well in the cases of hardware/device failures that cause probe failure. The case I am seeing is a driver bug that causes probe failure. > What other behaviour would you expect ? > I am looking to see if we can propagate the error to the interface driver to handle instead of leaving the defunct driver. This isn't an easy problem to solve though. As you mentioned driver probe could fail if device is bad and we want the driver to handle the others. The fact is we will end up with defunct drivers in some cases. If user notices the error they could go clean it up. My main concern is the sysfs interfaces hanging around. The desired behavior would be not leaving defunct drivers with associated sysfs files. thanks, -- Shuah ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:28 ` Shuah Khan @ 2022-06-23 23:30 ` Laurent Pinchart 2022-06-23 23:38 ` Shuah Khan 0 siblings, 1 reply; 11+ messages in thread From: Laurent Pinchart @ 2022-06-23 23:30 UTC (permalink / raw) To: Shuah Khan; +Cc: ksummit, ksummit Hi Shuah, On Thu, Jun 23, 2022 at 05:28:09PM -0600, Shuah Khan wrote: > On 6/23/22 5:13 PM, Laurent Pinchart wrote: > > On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: > >> I have been debugging a driver probe failure and noticed that driver gets > >> registered even when driver probe fails. This is not a new behavior. The > >> code in question is the same since 2005. > >> > >> dmesg will say that a driver probe failed with error code and then the very > >> next message from interface core that says driver is registered successfully. > >> It will create sysfs interfaces. > >> > >> The probe failure is propagated from the drive probe routine all the way up to > >> __driver_attach(). __driver_attach() ignores the error and and returns success. > >> > >> __device_driver_lock(dev, dev->parent); > >> driver_probe_device(drv, dev); > >> __device_driver_unlock(dev, dev->parent); > >> > >> return 0; > >> > >> Interface driver register goes on to create sysfs entries as if driver probe > >> worked. It handles errors from driver_register() and unwinds the register > >> properly, however in this case it doesn't know about the failure. > >> > >> At this point the driver is defunct with sysfs interfaces. User has to run > >> rmmod to get rid of the defunct driver. > >> > >> Simply returning the error from __driver_attach() didn't work as expected. > >> I figured it would fail since not all interface drivers can handle errors > >> from driver probe routines. > >> > >> I propose that we discuss the scenario to find possible solutions to avoid > >> defunct drivers. > > > > This seems to be the expected behaviour to me. The probe failure doesn't > > necessarily indicate that the driver is at fault, it means that > > something went wrong when associating a particular device with the > > driver. It could be that the device is faulty for instance, and that > > shouldn't prevent the driver from being registered, especially if > > multiple instances of the device can be present in the system, as that > > would then prevent any of those instances from working due to one faulty > > device. > > Agreed. This behavior works well in the cases of hardware/device failures > that cause probe failure. The case I am seeing is a driver bug that causes > probe failure. Is there a way for the kernel to determine that the probe failure was caused by a buggy driver and not a faulty device ? > > What other behaviour would you expect ? > > I am looking to see if we can propagate the error to the interface driver to > handle instead of leaving the defunct driver. This isn't an easy problem to > solve though. As you mentioned driver probe could fail if device is bad > and we want the driver to handle the others. > > The fact is we will end up with defunct drivers in some cases. If user notices > the error they could go clean it up. My main concern is the sysfs interfaces > hanging around. The desired behavior would be not leaving defunct drivers with > associated sysfs files. I don't think the driver is "defunct". It has been loaded successfully, and it's fully operational, just not bound to any device. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:30 ` Laurent Pinchart @ 2022-06-23 23:38 ` Shuah Khan 2022-06-23 23:57 ` Dan Williams 0 siblings, 1 reply; 11+ messages in thread From: Shuah Khan @ 2022-06-23 23:38 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit, ksummit, Shuah Khan On 6/23/22 5:30 PM, Laurent Pinchart wrote: > Hi Shuah, > > On Thu, Jun 23, 2022 at 05:28:09PM -0600, Shuah Khan wrote: >> On 6/23/22 5:13 PM, Laurent Pinchart wrote: >>> On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: >>>> I have been debugging a driver probe failure and noticed that driver gets >>>> registered even when driver probe fails. This is not a new behavior. The >>>> code in question is the same since 2005. >>>> >>>> dmesg will say that a driver probe failed with error code and then the very >>>> next message from interface core that says driver is registered successfully. >>>> It will create sysfs interfaces. >>>> >>>> The probe failure is propagated from the drive probe routine all the way up to >>>> __driver_attach(). __driver_attach() ignores the error and and returns success. >>>> >>>> __device_driver_lock(dev, dev->parent); >>>> driver_probe_device(drv, dev); >>>> __device_driver_unlock(dev, dev->parent); >>>> >>>> return 0; >>>> >>>> Interface driver register goes on to create sysfs entries as if driver probe >>>> worked. It handles errors from driver_register() and unwinds the register >>>> properly, however in this case it doesn't know about the failure. >>>> >>>> At this point the driver is defunct with sysfs interfaces. User has to run >>>> rmmod to get rid of the defunct driver. >>>> >>>> Simply returning the error from __driver_attach() didn't work as expected. >>>> I figured it would fail since not all interface drivers can handle errors >>>> from driver probe routines. >>>> >>>> I propose that we discuss the scenario to find possible solutions to avoid >>>> defunct drivers. >>> >>> This seems to be the expected behaviour to me. The probe failure doesn't >>> necessarily indicate that the driver is at fault, it means that >>> something went wrong when associating a particular device with the >>> driver. It could be that the device is faulty for instance, and that >>> shouldn't prevent the driver from being registered, especially if >>> multiple instances of the device can be present in the system, as that >>> would then prevent any of those instances from working due to one faulty >>> device. >> >> Agreed. This behavior works well in the cases of hardware/device failures >> that cause probe failure. The case I am seeing is a driver bug that causes >> probe failure. > > Is there a way for the kernel to determine that the probe failure was > caused by a buggy driver and not a faulty device ? > That has to be explored. >>> What other behaviour would you expect ? >> >> I am looking to see if we can propagate the error to the interface driver to >> handle instead of leaving the defunct driver. This isn't an easy problem to >> solve though. As you mentioned driver probe could fail if device is bad >> and we want the driver to handle the others. >> >> The fact is we will end up with defunct drivers in some cases. If user notices >> the error they could go clean it up. My main concern is the sysfs interfaces >> hanging around. The desired behavior would be not leaving defunct drivers with >> associated sysfs files. > > I don't think the driver is "defunct". It has been loaded successfully, > and it's fully operational, just not bound to any device. > Not in the case I am debugging. It won't be successfully bound any device. That is what I meant by defunct. Maybe there is a better word to use. The driver releases all resources in its probe failure path. thanks, -- Shuah ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:38 ` Shuah Khan @ 2022-06-23 23:57 ` Dan Williams 2022-06-24 1:00 ` Dmitry Torokhov 0 siblings, 1 reply; 11+ messages in thread From: Dan Williams @ 2022-06-23 23:57 UTC (permalink / raw) To: Shuah Khan, Laurent Pinchart; +Cc: ksummit, ksummit, Shuah Khan Shuah Khan wrote: > On 6/23/22 5:30 PM, Laurent Pinchart wrote: > > Hi Shuah, > > > > On Thu, Jun 23, 2022 at 05:28:09PM -0600, Shuah Khan wrote: > >> On 6/23/22 5:13 PM, Laurent Pinchart wrote: > >>> On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: > >>>> I have been debugging a driver probe failure and noticed that driver gets > >>>> registered even when driver probe fails. This is not a new behavior. The > >>>> code in question is the same since 2005. > >>>> > >>>> dmesg will say that a driver probe failed with error code and then the very > >>>> next message from interface core that says driver is registered successfully. > >>>> It will create sysfs interfaces. > >>>> > >>>> The probe failure is propagated from the drive probe routine all the way up to > >>>> __driver_attach(). __driver_attach() ignores the error and and returns success. > >>>> > >>>> __device_driver_lock(dev, dev->parent); > >>>> driver_probe_device(drv, dev); > >>>> __device_driver_unlock(dev, dev->parent); > >>>> > >>>> return 0; > >>>> > >>>> Interface driver register goes on to create sysfs entries as if driver probe > >>>> worked. It handles errors from driver_register() and unwinds the register > >>>> properly, however in this case it doesn't know about the failure. > >>>> > >>>> At this point the driver is defunct with sysfs interfaces. User has to run > >>>> rmmod to get rid of the defunct driver. > >>>> > >>>> Simply returning the error from __driver_attach() didn't work as expected. > >>>> I figured it would fail since not all interface drivers can handle errors > >>>> from driver probe routines. > >>>> > >>>> I propose that we discuss the scenario to find possible solutions to avoid > >>>> defunct drivers. > >>> > >>> This seems to be the expected behaviour to me. The probe failure doesn't > >>> necessarily indicate that the driver is at fault, it means that > >>> something went wrong when associating a particular device with the > >>> driver. It could be that the device is faulty for instance, and that > >>> shouldn't prevent the driver from being registered, especially if > >>> multiple instances of the device can be present in the system, as that > >>> would then prevent any of those instances from working due to one faulty > >>> device. > >> > >> Agreed. This behavior works well in the cases of hardware/device failures > >> that cause probe failure. The case I am seeing is a driver bug that causes > >> probe failure. > > > > Is there a way for the kernel to determine that the probe failure was > > caused by a buggy driver and not a faulty device ? > > > > That has to be explored. > > >>> What other behaviour would you expect ? > >> > >> I am looking to see if we can propagate the error to the interface driver to > >> handle instead of leaving the defunct driver. This isn't an easy problem to > >> solve though. As you mentioned driver probe could fail if device is bad > >> and we want the driver to handle the others. > >> > >> The fact is we will end up with defunct drivers in some cases. If user notices > >> the error they could go clean it up. My main concern is the sysfs interfaces > >> hanging around. The desired behavior would be not leaving defunct drivers with > >> associated sysfs files. > > > > I don't think the driver is "defunct". It has been loaded successfully, > > and it's fully operational, just not bound to any device. > > > > Not in the case I am debugging. It won't be successfully bound any device. > That is what I meant by defunct. Maybe there is a better word to use. > > The driver releases all resources in its probe failure path. If the driver is bad there is no way for the kernel to know. Are you perhaps looking for a technique to unload the driver if another driver knows that it is indeed ok to unload the driver if it does not attach to its intended device? You mention the interface driver getting involved. The interface driver could do something like: device_add(dev); device_lock(dev); if (!dev->driver) driver_unregister(drv); device_unlock(dev); ...but that would need to know that nothing else needs @drv and that @drv has been registered and ->probe() run synchronous with device_add(). That does not work with the async and deferred probing options. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:57 ` Dan Williams @ 2022-06-24 1:00 ` Dmitry Torokhov 2022-06-24 6:33 ` Greg KH 0 siblings, 1 reply; 11+ messages in thread From: Dmitry Torokhov @ 2022-06-24 1:00 UTC (permalink / raw) To: Dan Williams; +Cc: Shuah Khan, Laurent Pinchart, ksummit, ksummit On Thu, Jun 23, 2022 at 04:57:11PM -0700, Dan Williams wrote: > Shuah Khan wrote: > > On 6/23/22 5:30 PM, Laurent Pinchart wrote: > > > Hi Shuah, > > > > > > On Thu, Jun 23, 2022 at 05:28:09PM -0600, Shuah Khan wrote: > > >> On 6/23/22 5:13 PM, Laurent Pinchart wrote: > > >>> On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: > > >>>> I have been debugging a driver probe failure and noticed that driver gets > > >>>> registered even when driver probe fails. This is not a new behavior. The > > >>>> code in question is the same since 2005. > > >>>> > > >>>> dmesg will say that a driver probe failed with error code and then the very > > >>>> next message from interface core that says driver is registered successfully. > > >>>> It will create sysfs interfaces. > > >>>> > > >>>> The probe failure is propagated from the drive probe routine all the way up to > > >>>> __driver_attach(). __driver_attach() ignores the error and and returns success. > > >>>> > > >>>> __device_driver_lock(dev, dev->parent); > > >>>> driver_probe_device(drv, dev); > > >>>> __device_driver_unlock(dev, dev->parent); > > >>>> > > >>>> return 0; > > >>>> > > >>>> Interface driver register goes on to create sysfs entries as if driver probe > > >>>> worked. It handles errors from driver_register() and unwinds the register > > >>>> properly, however in this case it doesn't know about the failure. > > >>>> > > >>>> At this point the driver is defunct with sysfs interfaces. User has to run > > >>>> rmmod to get rid of the defunct driver. > > >>>> > > >>>> Simply returning the error from __driver_attach() didn't work as expected. > > >>>> I figured it would fail since not all interface drivers can handle errors > > >>>> from driver probe routines. > > >>>> > > >>>> I propose that we discuss the scenario to find possible solutions to avoid > > >>>> defunct drivers. > > >>> > > >>> This seems to be the expected behaviour to me. The probe failure doesn't > > >>> necessarily indicate that the driver is at fault, it means that > > >>> something went wrong when associating a particular device with the > > >>> driver. It could be that the device is faulty for instance, and that > > >>> shouldn't prevent the driver from being registered, especially if > > >>> multiple instances of the device can be present in the system, as that > > >>> would then prevent any of those instances from working due to one faulty > > >>> device. > > >> > > >> Agreed. This behavior works well in the cases of hardware/device failures > > >> that cause probe failure. The case I am seeing is a driver bug that causes > > >> probe failure. > > > > > > Is there a way for the kernel to determine that the probe failure was > > > caused by a buggy driver and not a faulty device ? > > > > > > > That has to be explored. > > > > >>> What other behaviour would you expect ? > > >> > > >> I am looking to see if we can propagate the error to the interface driver to > > >> handle instead of leaving the defunct driver. This isn't an easy problem to > > >> solve though. As you mentioned driver probe could fail if device is bad > > >> and we want the driver to handle the others. > > >> > > >> The fact is we will end up with defunct drivers in some cases. If user notices > > >> the error they could go clean it up. My main concern is the sysfs interfaces > > >> hanging around. The desired behavior would be not leaving defunct drivers with > > >> associated sysfs files. > > > > > > I don't think the driver is "defunct". It has been loaded successfully, > > > and it's fully operational, just not bound to any device. > > > > > > > Not in the case I am debugging. It won't be successfully bound any device. > > That is what I meant by defunct. Maybe there is a better word to use. > > > > The driver releases all resources in its probe failure path. > > If the driver is bad there is no way for the kernel to know. > > Are you perhaps looking for a technique to unload the driver if another > driver knows that it is indeed ok to unload the driver if it does not > attach to its intended device? > > You mention the interface driver getting involved. The interface driver > could do something like: > > device_add(dev); > device_lock(dev); > if (!dev->driver) > driver_unregister(drv); > device_unlock(dev); > > ...but that would need to know that nothing else needs @drv and that > @drv has been registered and ->probe() run synchronous with > device_add(). That does not work with the async and deferred probing > options. Nor does this work for drivers for devices that might be hot-plugged, instantiated via sysfs/new_id, etc, etc. So if you want to fail driver registration because you know that you are dealing with a singleton platform device with no additional dependencies then it has to be done in the driver itself, not by the driver core. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-24 1:00 ` Dmitry Torokhov @ 2022-06-24 6:33 ` Greg KH 0 siblings, 0 replies; 11+ messages in thread From: Greg KH @ 2022-06-24 6:33 UTC (permalink / raw) To: Dmitry Torokhov Cc: Dan Williams, Shuah Khan, Laurent Pinchart, ksummit, ksummit On Thu, Jun 23, 2022 at 06:00:06PM -0700, Dmitry Torokhov wrote: > Nor does this work for drivers for devices that might be hot-plugged, > instantiated via sysfs/new_id, etc, etc. Agreed. > So if you want to fail driver registration because you know that you are > dealing with a singleton platform device with no additional dependencies > then it has to be done in the driver itself, not by the driver core. And even then, it really should not be done in the driver, that is not how Linux drivers should work at all. That's why we have macros to make it so that module_init() just calls [SUBSYSTEM]_register() for the subsystem in question, and the module is not supposed to do anything else. thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:05 [TECH TOPIC] Driver probe fails and register succeeds Shuah Khan 2022-06-23 23:13 ` Laurent Pinchart @ 2022-06-23 23:24 ` Guenter Roeck 2022-06-24 6:31 ` Greg KH 2 siblings, 0 replies; 11+ messages in thread From: Guenter Roeck @ 2022-06-23 23:24 UTC (permalink / raw) To: Shuah Khan, ksummit, ksummit On 6/23/22 16:05, Shuah Khan wrote: > I have been debugging a driver probe failure and noticed that driver gets > registered even when driver probe fails. This is not a new behavior. The > code in question is the same since 2005. > > dmesg will say that a driver probe failed with error code and then the very > next message from interface core that says driver is registered successfully. > It will create sysfs interfaces. > > The probe failure is propagated from the drive probe routine all the way up to > __driver_attach(). __driver_attach() ignores the error and and returns success. > > __device_driver_lock(dev, dev->parent); > driver_probe_device(drv, dev); > __device_driver_unlock(dev, dev->parent); > > return 0; > > Interface driver register goes on to create sysfs entries as if driver probe > worked. It handles errors from driver_register() and unwinds the register > properly, however in this case it doesn't know about the failure. > > At this point the driver is defunct with sysfs interfaces. User has to run > rmmod to get rid of the defunct driver. > > Simply returning the error from __driver_attach() didn't work as expected. > I figured it would fail since not all interface drivers can handle errors > from driver probe routines. > > I propose that we discuss the scenario to find possible solutions to avoid > defunct drivers. > Doesn't this confuse device probe from loading the driver ? If multiple devices are instantiated using a single driver, I would not want the driver to unload because one of the devices it supports failed to probe. Guenter ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-23 23:05 [TECH TOPIC] Driver probe fails and register succeeds Shuah Khan 2022-06-23 23:13 ` Laurent Pinchart 2022-06-23 23:24 ` Guenter Roeck @ 2022-06-24 6:31 ` Greg KH 2022-06-24 15:55 ` Shuah Khan 2 siblings, 1 reply; 11+ messages in thread From: Greg KH @ 2022-06-24 6:31 UTC (permalink / raw) To: Shuah Khan; +Cc: ksummit, ksummit On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: > I have been debugging a driver probe failure and noticed that driver gets > registered even when driver probe fails. This is not a new behavior. The > code in question is the same since 2005. As others have pointed out, this is "by design". Probe is independent of a driver registering in the kernel (i.e. module_init()) and should never determine if a module is to not be loaded or not. That was part of the explicit design of the driver model we did back in the 2.5 kernel days. We don't want to go back to the old style of "if a module can not find a device to control, fail to load" model, it does not work well for a variety of reasons. So it sounds like the driver is working properly for this portion of it, we can discuss the specifics of it on the subsystem-specific mailing list to find out of anything else is currently wrong with it, but I don't think this needs to be a tech topic from what I can tell. thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [TECH TOPIC] Driver probe fails and register succeeds 2022-06-24 6:31 ` Greg KH @ 2022-06-24 15:55 ` Shuah Khan 0 siblings, 0 replies; 11+ messages in thread From: Shuah Khan @ 2022-06-24 15:55 UTC (permalink / raw) To: Greg KH; +Cc: ksummit, ksummit, Shuah Khan, Shuah Khan On 6/24/22 12:31 AM, Greg KH wrote: > On Thu, Jun 23, 2022 at 05:05:30PM -0600, Shuah Khan wrote: >> I have been debugging a driver probe failure and noticed that driver gets >> registered even when driver probe fails. This is not a new behavior. The >> code in question is the same since 2005. > > As others have pointed out, this is "by design". Probe is independent > of a driver registering in the kernel (i.e. module_init()) and should > never determine if a module is to not be loaded or not. > > That was part of the explicit design of the driver model we did back in > the 2.5 kernel days. We don't want to go back to the old style of "if a > module can not find a device to control, fail to load" model, it does > not work well for a variety of reasons. > Thank you - this is helpful. > So it sounds like the driver is working properly for this portion of it, > we can discuss the specifics of it on the subsystem-specific mailing > list to find out of anything else is currently wrong with it, but I > don't think this needs to be a tech topic from what I can tell. > Thank you. Makes sense. This driver probe failure is a bug that needs to be fixed. I have a few fixes to send. thanks, -- Shuah ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-06-24 15:55 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-23 23:05 [TECH TOPIC] Driver probe fails and register succeeds Shuah Khan 2022-06-23 23:13 ` Laurent Pinchart 2022-06-23 23:28 ` Shuah Khan 2022-06-23 23:30 ` Laurent Pinchart 2022-06-23 23:38 ` Shuah Khan 2022-06-23 23:57 ` Dan Williams 2022-06-24 1:00 ` Dmitry Torokhov 2022-06-24 6:33 ` Greg KH 2022-06-23 23:24 ` Guenter Roeck 2022-06-24 6:31 ` Greg KH 2022-06-24 15:55 ` Shuah Khan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).