Hi, > Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>: > > On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote: >> 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@xxxxxxxxxxxxx>: >>>> >>>> Hi Dmitry, >>>> >>>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>: >>>>> >>>>> 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@xxxxxxxxx>: >>>>>>> >>>>>>> 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. > > If the concern with drivers having I2C or SPI device table, but not OF > device table, then I think cocinnelle could be used to scan and find > them. > >> >> 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. > > You can always build the module into kernel or load it by hand if it is > that important. Well, it is the only exception on the OpenPandora that does NOT yet load automatically from the DT. And sure we can always find a hack or workaround in user-space for everything the kernel isn't doing well. > Module autoloading does not work anyway if you have > several compatible strings, like > > compatible = "vendor,new-device", "vendor,generic-device"; We don't use that mechanism here since there is only one ads7846 installed and it won't change. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
