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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 29 Sep 2017 12:36:46 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tejun Heo <htejun@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Guenter Roeck <linux@...ck-us.net>, michael.j.ruhl@...el.com
Subject: Re: [PATCH v2 1/7] driver core: emit uevents when device is bound to
 a driver

On Wed, Jul 19, 2017 at 5:24 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> 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@...il.com>

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.