linux-kernel - Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

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, 1 Feb 2017 21:20:37 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Javier Martinez Canillas <javier@....samsung.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Michel Verlaan <michel.verl@...il.com>,
        Nick Dyer <nick@...anahar.org>,
        Tony Lindgren <tony@...mide.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-omap <linux-omap@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Igor Grinberg <grinberg@...pulab.co.il>,
        Hans Verkuil <hans.verkuil@...co.com>,
        linux-input@...r.kernel.org,
        devicetree <devicetree@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Eric Engestrom <eric@...estrom.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Petr Cvek <petr.cvek@....cz>,
        Siebren Vroegindeweij <siebren.vroegindeweij@...mail.com>,
        Sebastian Reichel <sre@...nel.org>, linux-iio@...r.kernel.org,
        "Andrew F. Davis" <afd@...com>, Mark Brown <broonie@...nel.org>,
        Benoît Cousson <bcousson@...libre.com>,
        kernel@...a-handheld.com, Michael Welling <mwelling@...e.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Alexander Stein <alexander.stein@...tec-electronic.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

Hi Dmitry, Javier,

> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> Hi Dmitry,
> 
>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@...il.com>:
>> 
>> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
>>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov <dmitry.torokhov@...il.com>:
>>>> 
>>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
>>>>> Fix module table so that the driver is loaded if compiled
>>>>> as module and requested by DT.
>>>>> 
>>>> 
>>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>>> aliases in this driver, we need to fix module loading to use it.
>>> 
>>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>>> 
>>>>> We really need to fix it between spi/i23c core and module utils instead
>>>>> of keeping adding duplicate IDs all over drivers. We already have OF
>>>>> module device table containing the same data, we should be able to use
>>>>> it.
>>> 
>>> And Javier Martinez Canillas replied (23 Nov 2016):
>>> 
>>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>>> 
>>>> And changing the I2C and SPI core isn't trivial since it could break a
>>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>>> OF device IDs present in the drivers even when are registered via DT).
>>> 
>>> Therefore I didn't see a need to change it.
>> 
>> I agree that changing I2C and SPI core is not trivial, however this is
>> no reason for piling up workarounds in all drivers. Are you seriously
>> advocating going though *every* driver and copying OF data into I2C/SPI
>> instead of doing the right thing and fixing the root of the issue?
> 
> If you prefer to have this done (and I agree it would be a tiny improvement),
> please do it for us all. But please after merging this workaround.

Have we been lucky to find someone who is able and willing to work on this?

If not, I'd recommend to stay with the current level of optimality.

BR and thanks,
Nikolaus