linux-kernel - Re: [PATCH v2 1/2] phy: usb: Fix missing elements in BCM4908 USB init array

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]

Message-ID: <4b8302db-be90-48aa-8d10-16b961458a2d@broadcom.com>
Date: Fri, 4 Oct 2024 16:37:23 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Sam Edwards <cfsworks@...il.com>
Cc: Justin Chen <justin.chen@...adcom.com>, Al Cooper <alcooperx@...il.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Vinod Koul <vkoul@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>, linux-kernel@...r.kernel.org,
 linux-phy@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] phy: usb: Fix missing elements in BCM4908 USB init
 array

On 10/4/24 16:35, Sam Edwards wrote:
> On Fri, Oct 4, 2024 at 9:14 AM Florian Fainelli
> <florian.fainelli@...adcom.com> wrote:
>>
>> On 10/3/24 20:41, Sam Edwards wrote:
>>> The Broadcom USB PHY driver contains a lookup table
>>> (`reg_bits_map_tables`) to resolve register bitmaps unique to certain
>>> versions of the USB PHY as found in various Broadcom chip families. A
>>> recent commit (see 'fixes' tag) introduced two new elements to each chip
>>> family in this table -- except for one: BCM4908. This resulted in the
>>> xHCI controller not being initialized correctly, causing a panic on
>>> boot.
>>
>> Yes, I think I see what happened here, we took the patch in the "fixes"
>> tag from the our downstream tree, and it applied just fine, we will keep
>> a closer eye on other entries in the future.
>>
>>>
>>> The next patch will update this table to use designated initializers in
>>> order to prevent this from happening again. For now, just add back the
>>> missing array elements to resolve the regression.
>>
>> Out of curiosity, can you check whether building with
>> -Wmissing-field-initializers would have caught this?
> 
> It appears that the answer is no, at least here on Clang. I also just
> tried -Wextra to see if any warning would catch it and didn't see one.
> My understanding is that -Wmissing-field-initializers is for struct
> fields, and a construct like:
> int array[3] = {1, 2};
> ...does not result in a warning because it's considered perfectly
> valid standards-compliant C per C's default initialization rule.

I suspected that much, thanks for having checked!
-- 
Florian