lkml.org 
[lkml]   [2017]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table
    From
    Date
    Hello Nikolaus,

    On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
    > Hi Dmitry, Javier,
    >
    >> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
    >>
    >> Hi Dmitry,
    >>
    >>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.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?
    >

    As said, changing the core is trivial. A RFC patch is [0].

    The problem is how to make sure that this change won't cause regressions
    in existing drivers.

    There was particularly tricky for the spi-nor driver, it doesn't help that
    a lot of DT are using undocumented compatible strings (sometimes with no
    vendor prefix). You can see the discussion here [1].

    In the same thread Mark Brown said that it wasn't that bad to have the
    information in the OF device ID table duplicated in a SPI device table.

    Certainly isn't the best approach but IMHO is better than the module not
    loading.

    https://patchwork.kernel.org/patch/7041141/
    https://patchwork.ozlabs.org/patch/545125/

    > If not, I'd recommend to stay with the current level of optimality.
    >
    > BR and thanks,
    > Nikolaus
    >

    Best regards,
    --
    Javier Martinez Canillas
    Open Source Group
    Samsung Research America

    \
     
     \ /
      Last update: 2017-02-01 22:16    [W:2.675 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site