linux-kernel - Re: [PATCH v10 1/5] dt-bindings: net: wireless: brcm4329-fmac: add pci14e4,449d

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]

Message-ID: <f504a3e7-cb18-41ce-a76d-267d464b6b05@linaro.org>
Date: Wed, 14 Aug 2024 16:08:49 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Arend van Spriel <arend.vanspriel@...adcom.com>,
 Krzysztof Kozlowski <krzk@...nel.org>, Jacobe Zang <jacobe.zang@...ion.com>,
 robh@...nel.org, krzk+dt@...nel.org, heiko@...ech.de, kvalo@...nel.org,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, conor+dt@...nel.org
Cc: efectn@...tonmail.com, dsimic@...jaro.org, jagan@...eble.ai,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 arend@...adcom.com, linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
 megi@....cz, duoming@....edu.cn, bhelgaas@...gle.com,
 minipli@...ecurity.net, brcm80211@...ts.linux.dev,
 brcm80211-dev-list.pdl@...adcom.com, nick@...das.com
Subject: Re: [PATCH v10 1/5] dt-bindings: net: wireless: brcm4329-fmac: add
 pci14e4,449d

On 14/08/2024 13:15, Krzysztof Kozlowski wrote:
> On 14/08/2024 12:59, Arend van Spriel wrote:
>> On 8/14/2024 12:39 PM, Krzysztof Kozlowski wrote:
>>> On 14/08/2024 12:08, Arend van Spriel wrote:
>>>> On 8/14/2024 10:53 AM, Krzysztof Kozlowski wrote:
>>>>> On 13/08/2024 19:04, Arend Van Spriel wrote:
>>>>>> On August 13, 2024 10:20:24 AM Jacobe Zang <jacobe.zang@...ion.com> wrote:
>>>>>>
>>>>>>> It's the device id used by AP6275P which is the Wi-Fi module
>>>>>>> used by Rockchip's RK3588 evaluation board and also used in
>>>>>>> some other RK3588 boards.
>>>>>>
>>>>>> Hi Kalle,
>>>>>>
>>>>>> There probably will be a v11, but wanted to know how this series will be
>>>>>> handled as it involves device tree bindings, arm arch device tree spec, and
>>>>>> brcmfmac driver code. Can it all go through wireless-next?
>>>>>
>>>>> No, DTS must not go via wireless-next. Please split it from the series
>>>>> and provide lore link in changelog for bindings.
>>>>
>>>> Hi Krzysztof,
>>>>
>>>> Is it really important how the patches travel upstream to Linus. This
>>>> binding is specific to Broadcom wifi devices so there are no
>>>> dependencies(?). To clarify what you are asking I assume two separate
>>>> series:
>>>>
>>>> 1) DT binding + Khadas Edge2 DTS  -> devicetree@...r.kernel.org
>>>> 	reference to:
>>>> https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com
>>>>
>>>> 2) brcmfmac driver changes	  -> linux-wireless@...r.kernel.org
>>>
>>> No. I said only DTS is separate. This was always the rule, since forever.
>>>
>>> Documentation/devicetree/bindings/submitting-patches.rst
>>
>> I am going slightly mad (by Queen). That documents says:
>>
>>    1) The Documentation/ and include/dt-bindings/ portion of the patch 
>> should
>>       be a separate patch.
>>
>> and
>>
>>    4) Submit the entire series to the devicetree mailinglist at
>>
>>         devicetree@...r.kernel.org
>>
>> Above I mentioned "series", not "patch". So 1) is a series of 3 patches 
>> (2 changes to the DT binding file and 1 patch for the Khadas Edge2 DTS. 
>> Is that correct?
>>
> 
> My bookmark to elixir.bootling does not work, so could not paste
> specific line. Now it works, so:
> 
> https://elixir.bootlin.com/linux/v6.11-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L79
> 
> The rule was/is:
> 1. Binding for typical devices always go via subsystem tree, with the
> driver changes.
> There can be exceptions from above, e.g. some subsystems do not pick up
> bindings, so Rob does. But how patches are organized is not an exception
> - it is completely normal workflow.
> 
> 2. DTS *always* goes via SoC maintainer. DTS cannot go via any other
> driver subsystem tree. There is no exception here. There cannot be an
> exception, because it would mean the hardware depends on driver, which
> is obviously false.

In case my message was not clear: we talk here about organizing
patchsets, not individual patches. If you ask about patches, then DTS,
bindings and driver are all separate patches. This set already is split
like that, so this was fine and I did not comment on it. Only through
whom the DTS patch goes - separate tree.

And just in case: this is neither specific to wireless nor to Broadcom.
This is for entire Linux kernel.

Best regards,
Krzysztof