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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 27 Apr 2018 10:59:15 +0200
From:   Bartosz Golaszewski <>
To:     Arnd Bergmann <>
Cc:     Sekhar Nori <>, David Lechner <>,
        Rich Felker <>,
        Bartosz Golaszewski <>,
        Kevin Hilman <>,
        Michael Turquette <>,
        Stephen Boyd <>,
        Greg Kroah-Hartman <>,
        Rob Herring <>,
        Mark Rutland <>,
        Yoshinori Sato <>,
        Frank Rowand <>,
        "Rafael J . Wysocki" <>,
        Jarkko Sakkinen <>,
        Dmitry Torokhov <>,
        Arend van Spriel <>,
        Heikki Krogerus <>,
        Michal Suchanek <>,
        Jan Kiszka <>,
        Andy Shevchenko <>,
        Marc Zyngier <>,
        Peter Rosin <>,
        Linux ARM <>,
        Linux Kernel Mailing List <>,
        DTML <>
Subject: Re: [PATCH RFC PoC 0/2] platform: different approach to early
 platform drivers

2018-04-27 10:55 GMT+02:00 Arnd Bergmann <>:
> On Fri, Apr 27, 2018 at 10:29 AM, Sekhar Nori <> wrote:
>> On Friday 27 April 2018 01:22 PM, Arnd Bergmann wrote:
>>> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner <> wrote:
>>>> On 04/26/2018 12:31 PM, Rich Felker wrote:
>>> I haven't seen the discussion about your clock drivers, but I know that
>>> usually only a very small subset of the clocks on an SoC are needed
>>> that 'early', and you should use a regular platform driver for the rest.
>> Its true that the subset is small, but they are either PLL bypass clocks
>> or clocks derived out of the main clock gate controller on the Soc
>> (DaVinci PSC). So we need some non-platform-device based initialization
>> support in the two main clock drivers used on mach-davinci anyway.
>>> Can you elaborate on which devices need to access your clocks before
>>> you are able to initialize the clk driver through the regular platform_driver
>>> framework? Do any of these need complex interactions with the clk
>>> subsystem, or do you just need to ensure they are turned on?
>> Its just the timer IP. There is no complex interaction, just need to
>> ensure that the clock is registered with the framework and also switched
>> on when there is a gate clock.
>> The latest attempt by David for this was posted last night here:
> Ok, so the workaround in that series is to set up the timer clk manually
> in the SoC specific code (dm365_init_time etc) and register it to the
> clk subsystem, right?
> That seems to be a much more appropriate workaround than adding
> back early_platform devices. We can always try to do something better
> later, but for now I'm happy with that as a workaround.

Just to clarify: this is not bringing back the hacky early platform
devices from before. It's a new approach that actually uses the linux
platform driver model (unlike the current mechanism which only uses
the same data structures).


Powered by blists - more mailing lists