Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200716223627.253936-1-daniel.gutson@eclypsium.com>
 <20200717062841.GA3238569@kroah.com> <CAK8P3a1yy7YyeJH5k40yAXb23y9siBnfuqixb76t3BK9Xh=uXQ@mail.gmail.com>
 <CAFmMkTFLm9mw5-8Dj_7rhP2KBcLUoJ1WcQCJv5_k+QRsmJPxjg@mail.gmail.com>
 <20200717145746.GB3008378@kroah.com> <CAFmMkTEsm7CRBzEJSCjkhCT7NHvRUXzcgchExbnfFbwPjT0YFg@mail.gmail.com>
 <20200721105256.GC1678476@kroah.com> <CAFmMkTGtG6p48o9qSzYqQs8mJXiGAMw7b5wp2LLAmwcdhn2u4A@mail.gmail.com>
 <20200721182608.GB2586085@kroah.com>
In-Reply-To: <20200721182608.GB2586085@kroah.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Tue, 21 Jul 2020 22:44:03 +0200
Message-ID: <CAK8P3a1e0pnGGC7tvncCLDizG3jhEds9RXJz359J0Jma5W=0cw@mail.gmail.com>
Subject: Re: [PATCH] [PATCH] Firmware security information in SYSFS
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Daniel Gutson <daniel@eclypsium.com>,
        Derek Kiernan <derek.kiernan@xilinx.com>,
        Tudor Ambarus <tudor.ambarus@microchip.com>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Richard Hughes <hughsient@gmail.com>,
        Alex Bazhaniuk <alex@eclypsium.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jul 21, 2020 at 8:26 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Jul 21, 2020 at 01:27:27PM -0300, Daniel Gutson wrote:
> > On Tue, Jul 21, 2020 at 7:52 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > If so, great, it should be a "class", as that way it is independent of
> > > > > any hardware type, right?  Classes show how devices talk to userspace
> > > in
> > > > > a common way (input, tty, led, block, etc.)  So why is this any
> > > > > different from that?
> > > > >
> > > >
> > > > Are you suggesting to create a new class, or use an existing one?
> > >
> > > Probably a new one, unless you can find an existing one that would fit?
> > >
> >
> > IIUC, Arnd Bergmann proposed that I create a class for each device driver
> > (in this case,
> > for the intel-spi, though I think the class would be spi-nor) and add
> > attributes to it.
> > In such a case, your proposal and his are different, mutually exclusive.
>
> Classes should be driver agnositic, and you should not have a single
> class per driver, as that is pretty pointless.

Yes, that was of course my suggestion as well.  The class is how the
interface is shown to user space, and each driver that can provide the
functionality would have to register an instance of the class device per
physical device.

> > For me it's easier and makes more sense to have a class for, say,
> > firmware-security (if I understood you correctly).
>
> I still think that's a horrible name, as that is not what you are
> describing here, but sure, a single class is good.

Right, neither the word "firmware" nor the word "security" gives it
any sufficiently specific meaning.

      Arnd