From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751026AbdBBFsq (ORCPT ); Thu, 2 Feb 2017 00:48:46 -0500 Received: from mo4-p04-ob.smtp.rzone.de ([81.169.146.179]:18790 "EHLO mo4-p04-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdBBFsn (ORCPT ); Thu, 2 Feb 2017 00:48:43 -0500 X-RZG-CLASS-ID: mo04 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6mSAGQ+qKIDsoIyHCuw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table From: "H. Nikolaus Schaller" In-Reply-To: <20170201222832.GA25554@dtor-ws> Date: Thu, 2 Feb 2017 06:47:12 +0100 Cc: Javier Martinez Canillas , Mark Rutland , Michel Verlaan , Nick Dyer , Tony Lindgren , LKML , Benjamin Tissoires , linux-omap , Russell King , Igor Grinberg , Hans Verkuil , linux-input@vger.kernel.org, devicetree , Arnd Bergmann , Eric Engestrom , Hans de Goede , Rob Herring , =?utf-8?Q?Mika_Penttil=C3=A4?= , Mauro Carvalho Chehab , Petr Cvek , Siebren Vroegindeweij , Sebastian Reichel , linux-iio@vger.kernel.org, "Andrew F. Davis" , Mark Brown , =?utf-8?Q?Beno=C3=AEt_Cousson?= , kernel@pyra-handheld.com, Michael Welling , Jonathan Cameron , Alexander Stein , Discussions about the Letux Kernel Message-Id: <3BB78F3F-F1FE-4F4C-BFA9-EAB19845161B@goldelico.com> References: <20170128193558.GC38136@dtor-ws> <20170129180108.GA10743@dtor-ws> <20170201222832.GA25554@dtor-ws> To: Dmitry Torokhov X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v125msvd025415 Hi, > Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov : > > 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 : >>>> >>>> Hi Dmitry, >>>> >>>>> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov : >>>>> >>>>> 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 : >>>>>>> >>>>>>> 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