Re: [PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

[Dan Williams]

On Wed, Jul 19, 2017 at 5:24 PM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
> There are certain touch controllers that may come up in either normal
> (application) or boot mode, depending on whether firmware/configuration is
> corrupted when they are powered on. In boot mode the kernel does not create
> input device instance (because it does not necessarily know the
> characteristics of the input device in question).
>
> Another number of controllers does not store firmware in a non-volatile
> memory, and they similarly need to have firmware loaded before input device
> instance is created. There are also other types of devices with similar
> behavior.
>
> There is a desire to be able to trigger firmware loading via udev, but it
> has to happen only when driver is bound to a physical device (i2c or spi).
> These udev actions can not use ADD events, as those happen too early, so we
> are introducing BIND and UNBIND events that are emitted at the right
> moment.
>
> Also, many drivers create additional driver-specific device attributes
> when binding to the device, to provide userspace with additional controls.
> The new events allow userspace to adjust these driver-specific attributes
> without worrying that they are not there yet.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>

Hi Dmitry,

Mike (cc'd) reports a regression with this change:

---

Previously, if I did:

# rmmod hfi1

The driver would be removed.

With 4.14.0-rc2+, when I remove the driver, the PCI bus is
automatically re-probed and the driver re-loaded.

---

A bisect points to commit 1455cf8dbfd0 "driver core: emit uevents when
device is bound to a driver". I'm sending this because I have this
mail in my archive, but I'll let Mike follow up with any other
details.