linux-kernel - Re: [PATCH v8 2/4] drivers/acpi: Introduce Platform Firmware Runtime Update device driver

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:   Mon, 8 Nov 2021 11:20:22 +0200
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     Chen Yu <yu.c.chen@...el.com>
Cc:     linux-acpi@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>, Len Brown <lenb@...nel.org>,
        Ashok Raj <ashok.raj@...el.com>,
        Mike Rapoport <rppt@...nel.org>,
        Aubrey Li <aubrey.li@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 2/4] drivers/acpi: Introduce Platform Firmware Runtime
 Update device driver

On Sat, Nov 06, 2021 at 11:14:56PM +0800, Chen Yu wrote:
> On Wed, Nov 03, 2021 at 07:32:09PM +0200, Andy Shevchenko wrote:
> > On Wed, Nov 03, 2021 at 11:43:50PM +0800, Chen Yu wrote:

...

> > > +enum cap_index {
> > > +	CAP_STATUS_IDX = 0,
> > > +	CAP_UPDATE_IDX = 1,
> > > +	CAP_CODE_TYPE_IDX = 2,
> > > +	CAP_FW_VER_IDX = 3,
> > > +	CAP_CODE_RT_VER_IDX = 4,
> > > +	CAP_DRV_TYPE_IDX = 5,
> > > +	CAP_DRV_RT_VER_IDX = 6,
> > > +	CAP_DRV_SVN_IDX = 7,
> > > +	CAP_PLAT_ID_IDX = 8,
> > > +	CAP_OEM_ID_IDX = 9,
> > > +	CAP_OEM_INFO_IDX = 10,
> > 
> > > +	CAP_NR_IDX = 11
> > 
> > Assignment here doesn't make any sense (it just adds unneeded churn and
> > burden). Same to the rest of similar cases below.
> >
> Greg mentioned that, we might need to "explicit about the numbers here, because it
> is uncerntain this is guaranteed by all C compilers or not."
> https://lore.kernel.org/lkml/YXj+QaMcCeV71XbI@kroah.com/
> My understanding is that, this applys to both uapi headers and the kernel internal
> headers.

I was talking only about the last item. This is guaranteed to be LAST+1 by the
C standard and any deviation from that is a compiler bug that must be fixed.

The first elements may be explicitly defined so we will be sure they are always
stay. Greg is right about it.

> > > +};

-- 
With Best Regards,
Andy Shevchenko