linux-kernel - Re: [PATCH] Input: synaptics-rmi4

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 11 Jan 2017 17:54:11 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     Andrew Duggan <aduggan@...aptics.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Christopher Heiny <cheiny@...aptics.com>,
        Nick Dyer <nick@...anahar.org>, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, Lyude Paul <thatslyude@...il.com>
Subject: Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

On Wednesday, January 11, 2017 5:28:28 PM CET Benjamin Tissoires wrote:
> Yep, it was initially written that way, and IIRC there was some issues
> depending on how the drivers were compiled. For example, if rmi4_core is
> Y and some functions are m, you can't load the device initially, so you
> send a -EPROBE_DEFER, but how can you be sure that the function will
> ever be loaded?

I'm not sure if I understand your problem correctly, but normally
the way it's done is that the bus driver notifies user space that
a new device has appeared on the bus, and udev looks for the right
driver for the device, using a MODULE_DEVICE_TABLE list. Once the
driver gets loaded, it binds to the device.

> Given that we need to have all the functions loaded during probe, we
> decided to switch to a monolithic rmi4_core driver that has everything
> it needs inside.

If everything is in one module, you can probably get rid of at
least part of the bus abstraction as well and just call the functions
directly.

Looking through the driver some more, I also find the
'rmi_driver rmi_physical_driver' concept very odd, you seem to
have a device on the bus that is actually just another representation
of the parent device and that creates another set of devices for
the functions. Either I misunderstand what this is for, or you have
a candidate for cleanup there and once you remove it (by calling
rmi_driver_probe() instead of rmi_register_transport_device()
to oversimplify the idea), the actual probing for the function
drivers becomes much easier to do right.

	Arnd