Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <9915035d-88ce-f961-00c0-fad24aa07764@gmail.com>
Date:   Sat, 9 Dec 2023 12:26:52 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH 1/2] xhci: Introduce "disable-usb3" DT property/quirk
Content-Language: en-US
To:     Krzysztof Kozlowski <krzk@kernel.org>,
        Mathias Nyman <mathias.nyman@intel.com>,
        Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Heiko Stuebner <heiko@sntech.de>, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20231208210458.912776-1-CFSworks@gmail.com>
 <20231208210458.912776-2-CFSworks@gmail.com>
 <d9ebe207-1f20-4254-9523-f2231bf9a0a4@kernel.org>
From:   Sam Edwards <cfsworks@gmail.com>
In-Reply-To: <d9ebe207-1f20-4254-9523-f2231bf9a0a4@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 12/9/23 06:53, Krzysztof Kozlowski wrote:
> On 08/12/2023 22:04, Sam Edwards wrote:
>> Some systems may have xHCI controllers that enumerate USB 3.0 ports, but
>> these ports nevertheless cannot be used. Perhaps enabling them triggers a
>> hardware bug, or perhaps they simply aren't connected and it would be
>> confusing to the user to see an unusable USB 3.0 rhub show up -- whatever
>> the case may be, it's reasonable to want to disable these ports.
>>
>> Add a DT property (and associated quirk) to the xHCI driver that skips
>> over (i.e. ignores and doesn't initialize) any USB 3.0 ports discovered
>> during driver initialization.
>>
>> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
>> ---
>>   Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++

Hi Krzysztof,

> 
> Bindings are always separate patches.
> 
> Please do not sneak in properties without DT review.
> 

It makes sense that the new property should be introduced in a separate 
patch. I'll ensure that is the case in v2. (If there is one -- see below.)

> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
> 
> You missed at least devicetree list (maybe more), so this won't be
> tested by automated tooling.

I have tried (and failed) to find the documentation for this 
linux-devicetree bot. Do you have the link? In particular, I'd like to 
ensure that patch 2/2 (the one that actually changes established 
behavior) is tested sufficiently thoroughly.

> Performing review on untested code might be
> a waste of time, thus I will skip this patch entirely till you follow
> the process allowing the patch to be tested.

That's fine; this patch has just failed review anyway (due to the new 
property not being introduced in a separate patch), and I'll need to 
prepare and send a v2 to proceed. However as I mentioned in the cover, 
this is a semi-RFC. I haven't discussed the overall idea with anyone 
yet, so to avoid wasting my own time, I need to give the USB folks ample 
opportunity to object to the proposed changes or suggest improvements 
before investing more effort in refining the patchset.

As of now, I'm only seeking commentary, not formal review. I'd 
appreciate any insights on the approach I've taken and whether there are 
any potential challenges or alternatives that haven't been explored yet. 
Therefore, I'll hold off on CC-ing linux-devicetree at this stage to 
keep the focus on the broader concept, and will loop them in (with any 
other recipients as appropriate) for v2 when (and if!) there's consensus 
here on linux-usb that the general direction is worth pursuing.

> 
> Please kindly resend and include all necessary To/Cc entries.
> 
> Best regards,
> Krzysztof
> 

Happy Saturday,
Sam