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: <CAGETcx_AHV8CDzRQ-y3xNRcT_QTi2ise1YwO7mw=u85g6O1uYQ@mail.gmail.com>
Date:   Thu, 16 Apr 2020 13:56:29 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] of: property: fw_devlink misc fixes

On Thu, Apr 16, 2020 at 4:03 AM Nicolas Saenz Julienne
<nsaenzjulienne@...e.de> wrote:
>
> On Wed, 2020-04-15 at 11:17 -0700, Saravana Kannan wrote:
> > On Wed, Apr 15, 2020 at 8:06 AM Nicolas Saenz Julienne
> > <nsaenzjulienne@...e.de> wrote:
> > > As I'm interested in using this feature to fine-tune Raspberry Pi 4's
> >
> > You've made my day! Finally another user outside of Android. :) If
> > this does improve the boot time, I'd be super interested to see the
> > numbers.
>
> Actually making the boot time faster isn't my main objective just a nice
> possible side-effect. I'll give you some numbers nonetheless :).

Thanks!

> I have two things in mind:
>  - Exploring if fw_devlink=on can help us solve a rather convoluted device
>    initialization depency we're seeing in RPi4. It could potentially prevent us
>    from adding nasty platform specific driver code.

I hope it does! I've also noticed that fw_devlink avoids the need for
ugly hacks in drivers and side steps poorly written error handling in
drivers.

>  - See if we can use all this information to fine-tune initrd generation on
>    smaller arm devices with limited i/o speeds.

That's pretty cool. I have no idea how fw_devlink helps here, but I'm
glad it does :)

> Do you have any plans in moving the default behavior to fw_devlink=on? If so
> what is blocking us?

That's my eventual goal. The main reasons it hasn't been done yet are:
1. Cases like yours where there might be fake cycles.
2. Cases of DT with bad choice of properties. Say, something like
"nr-gpios" would cause error spew in the logs (not a functional
error).
3. Whatever other unknown reasons this might cause boot up issues.

I'm starting with trying to turn on fw_devlink=permissive so that
driver developers can stop playing chicken with initcall levels. Then
work towards setting fw_devlink=on (going to be a long road).

> Also do you think it'd be reasonable to add a DT binding to set the desired
> fw_devlink level? Something like a 'linux,fw_devlink' property under the
> /chosen node.

I don't mind that, but not sure if DT maintainers are okay with it.
But if we do have that, I'd still want the kernel command line to
override it.

Thanks,
Saravana

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ