Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1569003 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module  table Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-28 20:50 +0100
    Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-01-29 09:50 +0100
      Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module  table Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-29 19:10 +0100
        Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-01-29 19:30 +0100

#1569003 — Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

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.

Thanks.

-- 
Dmitry

[toc] | [next] | [standalone]

#1569165 — Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

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.

BR,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1569255

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?

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1569262 — Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

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.

I can't do it since I have no idea how to and as you say it is non-trivial.
I am just a poor driver developer who has to use what he finds in core APIs
but has the task to make the driver work and be accepted upstream.

What I don't like is if core development tasks are piggybacked on top of a
driver patch series and used as argument against acceptance of the driver
patch. IMHO, the core developers should have the task to clean up such
workarounds after developing a modification for core and it seems to be
common practise in other subsystems if you follow what Linus is merging
every week.

Anyways, it piles up only in code. If you do not CONFIG the driver it does
not even matter that there are 10 more source code lines. And they are
factored out into a clean patch 6/8 that can easily be reverted.

BR and thanks,
Nikolaus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web