netdev - Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines.

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]

Date:   Tue, 19 Jul 2022 10:33:45 +1000
From:   Dave Airlie <airlied@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Daniel Vetter <daniel@...ll.ch>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.sf.net" <dri-devel@...ts.sf.net>,
        Network Development <netdev@...r.kernel.org>,
        Linux Wireless List <linux-wireless@...r.kernel.org>,
        alsa-devel@...a-project.org,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linux-block@...r.kernel.org, Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines.

On Tue, 19 Jul 2022 at 08:04, Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 18 Jul 2022 11:33:11 +0200 Thorsten Leemhuis wrote:
> > > If the hardware isn't
> > > +  enabled by default or under development,
> >
> > Wondering if it might be better to drop the "or under development", as
> > the "enabled by default" is the main part afaics. Maybe something like
> > "If support for the hardware is normally inactive (e.g. has to be
> > enabled manually by a kernel parameter)" would be better anyway.
>
> It's a tricky one, I'd say something like you can break the FW ABI
> "until HW becomes available for public consumption" or such.
> I'm guessing what we're after is letting people break the compatibility
> in early stages of the product development cycles. Pre-silicon and
> bring up, but not after there are products on the market?

I'll stick with enabled by default I think, "public consumption"
invites efforts to describe corners of the cloud or other places where
hw has shipped but is not technically "public",

Dave.