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

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

On 10/4/24 16:35, Sam Edwards wrote:
> On Fri, Oct 4, 2024 at 9:14 AM Florian Fainelli
> <florian.fainelli@broadcom.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

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy