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]

Message-ID: <20170111174813.GB7997@mail.corp.redhat.com>
Date:   Wed, 11 Jan 2017 18:48:13 +0100
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
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 Jan 11 2017 or thereabouts, Arnd Bergmann wrote:
> 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.
> 

I agree, but we never managed to make it properly working for RMI4. See
https://lkml.org/lkml/2015/11/5/726 where we decided to switch to a
static list of functions. Maybe we did not try hard enough, but we kept
the current bus/functions_as_drivers to be able to switch back to the
modular option,

> > 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.

Agree, though that means we won't be able to switch back. In the current
form it's overly engineered.

> 
> 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

I think you have this right.

> 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.
> 

Agree, that would simplify the code a lot. I just don't know how
important it is for other users of RMI4 to have a modular solution or if
the monolithic approach is a consensus now. The modular solution is
currently disabled, but we can "always" switch back with a small effort.

My opinion on this matter is that there is no need for the modular
functions, but others might have a different opinion.

Cheers,
Benjamin