linux-kernel - Re: [PATCH 0/2] Avoid firmware warning in imx-sdma

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] [day] [month] [year] [list]

Date:   Thu, 28 Jun 2018 05:13:32 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
        Kees Cook <keescook@...omium.org>,
        Hans de Goede <hdegoede@...hat.com>, andresx7@...il.com,
        torvalds@...ux-foundation.org
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Vinod Koul <vkoul@...nel.org>, dmaengine@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH 0/2] Avoid firmware warning in imx-sdma

On Fri, Jun 22, 2018 at 04:49:49PM +0200, Sebastian Reichel wrote:
> Subject: Avoid firmware warning in imx-sdma
> 
> Hi,
> 
> I grabbed the first patch from patchwork from an 2017 patch series. As far as I
> could see, their usecase vanished due to switching to sync FW API (that already
> supports NOWARN). This series fixes a kernel warning in imx-sdma driver, which
> works fine with ROM firmware (and already prints an info message about ROM
> firmware being used due to missing firmware file). This has been tested on
> arch/arm/boot/dts/imx53-ppd.dts.

Please read these threads about the state of affairs with respect to data
driven Vs functional API evolution on the firmware API [0] and my latests
recommendation for what to do for the async firmware API [1].

Then, recently I've come to realize that perhaps the best thing actually
is to *break* the cycle for the async API and make it more functional driven.

For instance the call to not use the uevent should be made a separate
call as only two drivers use it:

  o CONFIG_LEDS_LP55XX_COMMON
  o CONFIG_DELL_RBU

Using a struct would make it data driven. A flags approach would make it
more flexible and I although I think this is reasonable, if we wanted
to match the sync API, we'd have one call per variation.

It is therefore subjective whether or not to keep a flags based mechanism
for the async API or not. If we at least use flags, we'd just break away
from the sync approach.

I'll let Kees and Greg pick and choose how they would prefer to see this
broken down now as I am off on vacation today and won't be back until the
middle of next month.

[0] https://lkml.kernel.org/r/20180421173650.GW14440@wotan.suse.de              
[1] https://lkml.kernel.org/r/20180422202609.GX14440@wotan.suse.de 

  Luis