From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752554AbdIEQvw (ORCPT ); Tue, 5 Sep 2017 12:51:52 -0400 Received: from muru.com ([72.249.23.125]:39536 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752295AbdIEQvt (ORCPT ); Tue, 5 Sep 2017 12:51:49 -0400 Date: Tue, 5 Sep 2017 09:51:45 -0700 From: Tony Lindgren To: Kishon Vijay Abraham I Cc: Rob Herring , Sebastian Reichel , Ulf Hansson , Adrian Hunter , Sekhar Nori , Russell King , Ravikumar Kattekola , "linux-mmc@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller Message-ID: <20170905165145.GC5024@atomide.com> References: <20170823054246.23927-1-kishon@ti.com> <0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com> <20170829115050.3axlr5uysmqlhvd2@earth> <20170829135822.GR6008@atomide.com> <20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop> <20170829173913.GD6008@atomide.com> <06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kishon Vijay Abraham I [170905 01:53]: > Hi, > > On Tuesday 29 August 2017 11:09 PM, Tony Lindgren wrote: > > * Rob Herring [170829 10:09]: > >> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote: > >>> * Sebastian Reichel [170829 04:51]: > >>>> I would expect the conversion to look like the one done for UART, > >>>> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the > >>>> same compatible value and you can choose using kernel configuration. > >>> > >>> That does not work unfortunately :( We are now stuck in a situation > >>> where two drivers are attempting to probe with the same compatible > >>> and we can't enable 8250_OMAP because of the user space breakage > >>> with the device names. And I'm actuallly thinking we should add a > >>> new compatible for 8250-omap to be able to start enabling it one > >>> board at a time. > >> > >> Is that the only problem? Presumably, the SD driver doesn't have a > >> userspace facing issue. > > > > No userspace issue with the sdhci-omap. But the sdhci-omap driver > > still has the issue of trying enable it for everything at once and > > expect everything to work. The sdhci-omap driver can already be > > used for boards that don't need power management for example, but > > will break things for devices running on batteries. > > > >>> It's best to enable devices to use the new compatible as things are > >>> tested rather than hope for some magic "flag day" flip that might > >>> never happen. Having two days attempting to probe with the same > >>> binding just won't work. > >> > >> Aren't you just picking whether the flag day is in DT or the kernel? I > >> guess you're assuming one kernel build and it would be switching all > >> boards at one. > > > > Right, this would be risky and would take unnecessarily long > > to use the new driver on boards that can already use it. While > > power management won't work yet, I'd expect the sdhci-omap be > > faster on SoCs that can do ADMA. > > > >>> So yeah, I agree with Kishon that we should stick with generic > >>> and sdhci bindings. And then we can start already using it for > >>> boards that can use it, then eventually when we're ready, start > >>> parsing also the legacy bindings and maybe drop the old driver. > >> > >> I assume there are some other common properties you would switch to in > >> the transition? You could make the legacy driver bail from probe based > >> on presence or absence of other properties. Or you could just blacklist > >> converted platforms in the legacy driver. The point is that the problems > >> are solvable in the kernel. > > > > Yes this could be done too. But let's enable it on per-board > > basis rather than attempt to flip it on at once. > > > >> But if your really want a new compatible, I don't really care. It's > >> only one device. > > > > Both a new compatible or a check for some resource work just fine > > for me as long as the driver can be selected on per-board basis. > > New compatible sounds simpler to me since it allows to select a driver per-MMC > instance. (SDIO support is not added/validated in sdhci-omap). > > To summarize, we'll create new compatible and new bindings for sdhci-omap and > start enabling sdhci-omap on per-board basis. When all the TI platforms starts > to use sdhci-omap, omap-hsmmc will be removed at which point support for old > compatible and old dt bindings will be added to sdhci-omap.c. Does this sound > reasonable? Sounds like a plan to me. Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller Date: Tue, 5 Sep 2017 09:51:45 -0700 Message-ID: <20170905165145.GC5024@atomide.com> References: <20170823054246.23927-1-kishon@ti.com> <0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com> <20170829115050.3axlr5uysmqlhvd2@earth> <20170829135822.GR6008@atomide.com> <20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop> <20170829173913.GD6008@atomide.com> <06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com> Sender: linux-kernel-owner@vger.kernel.org To: Kishon Vijay Abraham I Cc: Rob Herring , Sebastian Reichel , Ulf Hansson , Adrian Hunter , Sekhar Nori , Russell King , Ravikumar Kattekola , "linux-mmc@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org * Kishon Vijay Abraham I [170905 01:53]: > Hi, > > On Tuesday 29 August 2017 11:09 PM, Tony Lindgren wrote: > > * Rob Herring [170829 10:09]: > >> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote: > >>> * Sebastian Reichel [170829 04:51]: > >>>> I would expect the conversion to look like the one done for UART, > >>>> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the > >>>> same compatible value and you can choose using kernel configuration. > >>> > >>> That does not work unfortunately :( We are now stuck in a situation > >>> where two drivers are attempting to probe with the same compatible > >>> and we can't enable 8250_OMAP because of the user space breakage > >>> with the device names. And I'm actuallly thinking we should add a > >>> new compatible for 8250-omap to be able to start enabling it one > >>> board at a time. > >> > >> Is that the only problem? Presumably, the SD driver doesn't have a > >> userspace facing issue. > > > > No userspace issue with the sdhci-omap. But the sdhci-omap driver > > still has the issue of trying enable it for everything at once and > > expect everything to work. The sdhci-omap driver can already be > > used for boards that don't need power management for example, but > > will break things for devices running on batteries. > > > >>> It's best to enable devices to use the new compatible as things are > >>> tested rather than hope for some magic "flag day" flip that might > >>> never happen. Having two days attempting to probe with the same > >>> binding just won't work. > >> > >> Aren't you just picking whether the flag day is in DT or the kernel? I > >> guess you're assuming one kernel build and it would be switching all > >> boards at one. > > > > Right, this would be risky and would take unnecessarily long > > to use the new driver on boards that can already use it. While > > power management won't work yet, I'd expect the sdhci-omap be > > faster on SoCs that can do ADMA. > > > >>> So yeah, I agree with Kishon that we should stick with generic > >>> and sdhci bindings. And then we can start already using it for > >>> boards that can use it, then eventually when we're ready, start > >>> parsing also the legacy bindings and maybe drop the old driver. > >> > >> I assume there are some other common properties you would switch to in > >> the transition? You could make the legacy driver bail from probe based > >> on presence or absence of other properties. Or you could just blacklist > >> converted platforms in the legacy driver. The point is that the problems > >> are solvable in the kernel. > > > > Yes this could be done too. But let's enable it on per-board > > basis rather than attempt to flip it on at once. > > > >> But if your really want a new compatible, I don't really care. It's > >> only one device. > > > > Both a new compatible or a check for some resource work just fine > > for me as long as the driver can be selected on per-board basis. > > New compatible sounds simpler to me since it allows to select a driver per-MMC > instance. (SDIO support is not added/validated in sdhci-omap). > > To summarize, we'll create new compatible and new bindings for sdhci-omap and > start enabling sdhci-omap on per-board basis. When all the TI platforms starts > to use sdhci-omap, omap-hsmmc will be removed at which point support for old > compatible and old dt bindings will be added to sdhci-omap.c. Does this sound > reasonable? Sounds like a plan to me. Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Tue, 5 Sep 2017 09:51:45 -0700 Subject: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller In-Reply-To: <06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com> References: <20170823054246.23927-1-kishon@ti.com> <0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com> <20170829115050.3axlr5uysmqlhvd2@earth> <20170829135822.GR6008@atomide.com> <20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop> <20170829173913.GD6008@atomide.com> <06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com> Message-ID: <20170905165145.GC5024@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Kishon Vijay Abraham I [170905 01:53]: > Hi, > > On Tuesday 29 August 2017 11:09 PM, Tony Lindgren wrote: > > * Rob Herring [170829 10:09]: > >> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote: > >>> * Sebastian Reichel [170829 04:51]: > >>>> I would expect the conversion to look like the one done for UART, > >>>> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the > >>>> same compatible value and you can choose using kernel configuration. > >>> > >>> That does not work unfortunately :( We are now stuck in a situation > >>> where two drivers are attempting to probe with the same compatible > >>> and we can't enable 8250_OMAP because of the user space breakage > >>> with the device names. And I'm actuallly thinking we should add a > >>> new compatible for 8250-omap to be able to start enabling it one > >>> board at a time. > >> > >> Is that the only problem? Presumably, the SD driver doesn't have a > >> userspace facing issue. > > > > No userspace issue with the sdhci-omap. But the sdhci-omap driver > > still has the issue of trying enable it for everything at once and > > expect everything to work. The sdhci-omap driver can already be > > used for boards that don't need power management for example, but > > will break things for devices running on batteries. > > > >>> It's best to enable devices to use the new compatible as things are > >>> tested rather than hope for some magic "flag day" flip that might > >>> never happen. Having two days attempting to probe with the same > >>> binding just won't work. > >> > >> Aren't you just picking whether the flag day is in DT or the kernel? I > >> guess you're assuming one kernel build and it would be switching all > >> boards at one. > > > > Right, this would be risky and would take unnecessarily long > > to use the new driver on boards that can already use it. While > > power management won't work yet, I'd expect the sdhci-omap be > > faster on SoCs that can do ADMA. > > > >>> So yeah, I agree with Kishon that we should stick with generic > >>> and sdhci bindings. And then we can start already using it for > >>> boards that can use it, then eventually when we're ready, start > >>> parsing also the legacy bindings and maybe drop the old driver. > >> > >> I assume there are some other common properties you would switch to in > >> the transition? You could make the legacy driver bail from probe based > >> on presence or absence of other properties. Or you could just blacklist > >> converted platforms in the legacy driver. The point is that the problems > >> are solvable in the kernel. > > > > Yes this could be done too. But let's enable it on per-board > > basis rather than attempt to flip it on at once. > > > >> But if your really want a new compatible, I don't really care. It's > >> only one device. > > > > Both a new compatible or a check for some resource work just fine > > for me as long as the driver can be selected on per-board basis. > > New compatible sounds simpler to me since it allows to select a driver per-MMC > instance. (SDIO support is not added/validated in sdhci-omap). > > To summarize, we'll create new compatible and new bindings for sdhci-omap and > start enabling sdhci-omap on per-board basis. When all the TI platforms starts > to use sdhci-omap, omap-hsmmc will be removed at which point support for old > compatible and old dt bindings will be added to sdhci-omap.c. Does this sound > reasonable? Sounds like a plan to me. Regards, Tony