linux-kernel - Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

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 linux-cve-announce 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]

Message-ID: <CAK8P3a17xU5m+_X-qWQK+LZq-bt3NnuVCgwzg+C2yYsVrdFhWw@mail.gmail.com>
Date:   Fri, 27 Apr 2018 21:08:53 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        David Lechner <david@...hnology.com>,
        Rich Felker <dalias@...c.org>, 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 6:05 PM, Bartosz Golaszewski
<bgolaszewski@...libre.com> wrote:
> 2018-04-27 16:48 GMT+02:00 Arnd Bergmann <arnd@...db.de>:
>> On Fri, Apr 27, 2018 at 4:05 PM, Bartosz Golaszewski
>
> So speaking in pseudo-C we basically have two ways for an imaginary
> future timer driver:
>
> int foo_probe(struct platform_device *pdev)
> {
>     struct clk *clk;
>
>     if (probing_early(pdev)) {
>         clk = devm_clk_get(dev, "earlyclock");
>
>        /* Do early stuff. */
>         return 0;
>     }
>
>     /* Do late stuff. */
>
>     return 0;
> }
>
>     --- vs ---
>
> int foo_probe(struct platform_device *pdev)
> {
>     /* Do late stuff. */
>
>     return 0;
> }
>
> static int foo_init(struct device_node *np)
> {
>     struct clk *clk;
>     struct device *dev = device_from_device_node(np);
>
>     /* Do early stuff. */
>     clk = devm_clk_get(dev, "earlyclock");
>
>     return 0;
> }
>
> TIMER_OF_DECLARE(foo, "bar,foo", foo_init);
>
> I still believe the first approach is easier to implement and has the
> added benefit of supporting board files.

Right. I still like the second approach better, since it avoids
multiplexing two very different code paths into a single
function, and because it's closer to what everyone is used
to at the moment.

Prototyping both is probably helpful to get a better idea
of the actual complexity this introduces.

> I'll give it a thought and will be back at it next week.

Ok. I'll be on vacation for three weeks so I wont' be able
to reply on the new patches.

       Arnd