linux-kernel - Re: [PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi

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]

Message-ID: <CAN+gG=G32y=Xp2jpfF7F+F=1-UxeEdX8+ikUNacCXFYmVu14RQ@mail.gmail.com>
Date:	Tue, 10 Nov 2015 10:03:12 +0100
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Andrew Duggan <aduggan@...aptics.com>,
	linux-input <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Christopher Heiny <cheiny@...aptics.com>,
	Stephen Chandler Paul <cpaul@...hat.com>
Subject: Re: [PATCH 01/26] Input: synaptics-rmi4 - embed the function modules
 in rmi_core

On Tue, Nov 10, 2015 at 12:06 AM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Thu, Nov 05, 2015 at 03:36:18PM -0800, Andrew Duggan wrote:
>> From: Benjamin Tissoires <benjamin.tissoires@...hat.com>
>>
>> the function modules can not be auto-loaded by udev. So at boot, the
>> functions are not there and the device is not properly populated.
>> Force the functions to be embedded in rmi_core so that when the touchpad
>> is there, the functions are there too.
>
> There is nothing inherently different in RMI compared to other buses.
> kmod package simply needs to be aware of it.
>

I can't help but thinking that it is slightly different though. We
register one RMI bus like the others, but then, the only driver
(rmi-driver) on the bus needs to enumerate the device and attach other
kernel modules on demand. It looks as if the rmi device is an other
internal bus. But the current implementation only allows the functions
to be loaded during the probe of the rmi_device.

During this probe, we can't block to wait for userspace to load the
various modules, and so we are screwed. The solution would be to allow
deferring the loading of the various functions, which basically comes
down to create a sub-bus per device.

The way I see it is:
- for 90 % of the cases, RMI4 will be used for touchpads in general
laptops. Distributions will likely enable 2D sensors, F30, fingerprint
readers, and maybe a few others. I don't think we want to chase all
the initrd tools to include the various RMI modules or people will
have a non functional touchpad.
- for the rest (embedded, phones, etc,...), these projects usually
already configure their own kernels and they can decide whether or not
they want to include which function depending on the actual hardware.

I am not saying that having autoloading is a bad thing. I just can't
see the interest for the general use case, and I can see the nightmare
to maintain the autoloading :).

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/