lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 27 Apr 2018 11:22:12 -0400 From: Rich Felker <dalias@...c.org> To: Arnd Bergmann <arnd@...db.de> Cc: Bartosz Golaszewski <brgl@...ev.pl>, Bartosz Golaszewski <bgolaszewski@...libre.com>, David Lechner <david@...hnology.com>, Sekhar Nori <nsekhar@...com>, Kevin Hilman <khilman@...nel.org>, Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Rob Herring <robh+dt@...nel.org>, Mark Rutland <mark.rutland@....com>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Frank Rowand <frowand.list@...il.com>, "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>, Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>, Dmitry Torokhov <dmitry.torokhov@...il.com>, Arend van Spriel <aspriel@...il.com>, Heikki Krogerus <heikki.krogerus@...ux.intel.com>, Michal Suchanek <msuchanek@...e.de>, Jan Kiszka <jan.kiszka@...mens.com>, Andy Shevchenko <andy.shevchenko@...il.com>, Marc Zyngier <marc.zyngier@....com>, Peter Rosin <peda@...ntia.se>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, DTML <devicetree@...r.kernel.org> Subject: Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers On Fri, Apr 27, 2018 at 02:40:34PM +0200, Arnd Bergmann wrote: > On Fri, Apr 27, 2018 at 1:53 PM, Bartosz Golaszewski <brgl@...ev.pl> wrote: > > 2018-04-27 12:18 GMT+02:00 Arnd Bergmann <arnd@...db.de>: > >> On Fri, Apr 27, 2018 at 10:57 AM, Bartosz Golaszewski > >> <bgolaszewski@...libre.com> wrote: > >>> 2018-04-27 9:52 GMT+02:00 Arnd Bergmann <arnd@...db.de>: > >>>> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner <david@...hnology.com> 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. FWIW if arch/sh is the only remaining user of the earlyprintk part, please don't go to any trouble to preserve it. I want to move to earlycon exclusively. Not sure if that is possible before moving the boards that are using it to device tree; if so and it's easy, please consider sending a patch or a sketch of what it should look like so I can do it. Rich
Powered by blists - more mailing lists