From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers Date: Wed, 2 May 2018 23:11:14 +0200 Message-ID: References: <20180426152920.21569-1-brgl@bgdev.pl> <20180426173151.GJ3094@brightrain.aerifal.cx> <6d1f9114-f1d1-961f-4f36-74adff059dc3@lechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Bartosz Golaszewski , Mark Rutland , Rich Felker , Jan Kiszka , Michael Turquette , Sekhar Nori , Jarkko Sakkinen , Heikki Krogerus , Frank Rowand , Yoshinori Sato , Kevin Hilman , "Rafael J . Wysocki" , Bartosz Golaszewski , Andy Shevchenko , Michal Suchanek , DTML , David Lechner , Marc Zyngier , Rob Herring List-Id: devicetree@vger.kernel.org On Fri, Apr 27, 2018 at 2:40 PM, Arnd Bergmann wrote: > On Fri, Apr 27, 2018 at 1:53 PM, Bartosz Golaszewski wrote: >> 2018-04-27 12:18 GMT+02:00 Arnd Bergmann : >>> On Fri, Apr 27, 2018 at 10:57 AM, Bartosz Golaszewski >>> wrote: >>>> 2018-04-27 9:52 GMT+02:00 Arnd Bergmann : >>>>> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner wrote: >>>> My patch tries to address exactly the use cases we're facing - for >>>> example by providing means to probe devices twice (early and late) and >>>> to check the state we're at in order for users to be able to just do >>>> the critical initialization early on and then continue with regular >>>> stuff later. >>> >>> Maybe the problem is reusing the name and some of the code from >>> an existing functionality that we've been trying to get rid of. >>> >> >> I'm not reusing the name - in fact I set the prefix to earlydev_ >> exactly in order to not confuse anyone. I'm also not reusing any code >> in the second series. > > Ok. > >>> If what you want to do is completely different from the existing >>> early_platform implementation, how about starting by moving that >>> out of drivers/base/platform.c into something under arch/sh/ >>> and renaming it to something with an sh_ prefix. >>> >> >> Yes, this is a good idea, but what about the sh-specific drivers that >> rely on it? Is including headers from arch/ in driver code still an >> accepted practice? > > I think it's fine here, since we're just move it out of the way and > there are only very few drivers using it: > > drivers/clocksource/sh_cmt.c:early_platform_init("earlytimer", > &sh_cmt_device_driver); > drivers/clocksource/sh_mtu2.c:early_platform_init("earlytimer", > &sh_mtu2_device_driver); > drivers/clocksource/sh_tmu.c:early_platform_init("earlytimer", > &sh_tmu_device_driver); > drivers/clocksource/timer-ti-dm.c:early_platform_init("earlytimer", > &omap_dm_timer_driver); > drivers/tty/serial/sh-sci.c:early_platform_init_buffer("earlyprintk", > &sci_driver, > > For timer-ti-dm, it seems like a leftover from old times that can > be removed. The other four are shared between arch/sh and > arch/arm/mach-shmobile and already have some #ifdef > to handle those two cases. Sh-sci is also used on arm64, for R-Car Gen3 SoCs. While the latter has CMT and TMU hardware blocks, so far we haven't enabled support for it yet (just using the ARM arch timer is too convenient? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds