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>] [day] [month] [year] [list]
Message-ID: <CAGETcx-=g-qU-A5YO5co52Q02OtKnP6R6Z4YbisiG91R+QkaJQ@mail.gmail.com>
Date:   Thu, 14 Jan 2021 08:49:01 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "kernel-team@...roid.com" <kernel-team@...roid.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kevin Hilman <khilman@...libre.com>,
        John Stultz <john.stultz@...aro.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Marc Zyngier <maz@...nel.org>,
        Serge Semin <fancer.lancer@...il.com>
Subject: Re: [PATCH v1 0/5] Enable fw_devlink=on by default

On Wed, Jan 13, 2021 at 11:48 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
>
>
> On Monday, December 21, 2020, Jisheng Zhang <Jisheng.Zhang@...aptics.com> wrote:
>>
>> On Thu, 17 Dec 2020 19:16:58 -0800 Saravana Kannan wrote:
>>
>>
>> >
>> >
>> > As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>> > be broken using logic was one of the last remaining reasons
>> > fw_devlink=on couldn't be set by default.
>> >
>> > This series changes fw_devlink so that when a cyclic dependency is found
>> > in firmware, the links between those devices fallback to permissive mode
>> > behavior. This way, the rest of the system still benefits from
>> > fw_devlink, but the ambiguous cases fallback to permissive mode.
>> >
>> > Setting fw_devlink=on by default brings a bunch of benefits (currently,
>> > only for systems with device tree firmware):
>> > * Significantly cuts down deferred probes.
>> > * Device probe is effectively attempted in graph order.
>> > * Makes it much easier to load drivers as modules without having to
>> >   worry about functional dependencies between modules (depmod is still
>> >   needed for symbol dependencies).
>> >
>> > Greg/Rafael,
>> >
>> > Can we get this pulled into 5.11-rc1 or -rc2 soon please? I expect to
>> > see some issues due to device drivers that aren't following best
>> > practices (they don't expose the device to driver core). Want to
>> > identify those early on and try to have them fixed before 5.11 release.
>> > See [1] for an example of such a case.
>> >
>> > If we do end up have to revert anything, it'll just be Patch 5/5 (a one
>> > liner).
>> >
>> > Marc,
>> >
>> > You had hit issues with fw_devlink=on before on some of your systems.
>> > Want to give this a shot?
>> >
>> > Jisheng,
>> >
>> > Want to fix up one of those gpio drivers you were having problems with?
>> >
>>
>> Hi Saravana,
>>
>> I didn't send fix for the gpio-dwapb.c in last development window, so can
>> send patch once 5.11-rc1 is released.
>
>
> If you are going to do anything with that GPIO driver, it should be removal of compatible strings from the device child nodes. The driver IIRC never used them anyhow anyway.

We already discussed this in a different thread. Just deleting DT is
not okay. That breaks a new kernel + old DT combo. Upgrading the
kernel shouldn't break a board.

-Saravana

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ