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

[Arend Van Spriel]

On August 14, 2024 4:08:52 PM Krzysztof Kozlowski 
<krzysztof.kozlowski@xxxxxxxxxx> wrote:

> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> > > > > reference to:
> > > > > https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@xxxxxxxxxx
> > > > >
> > > > > 2) brcmfmac driver changes  -> linux-wireless@xxxxxxxxxxxxxxx
> > > >
> > > > 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@xxxxxxxxxxxxxxx
> > >
> > > 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.

I used the "series" which is my term for "patchset". Sorry for confusion. 
So "[PATCH 3/5] arm64: dts: rockchip: Add AP6275P wireless support to 
Khadas Edge 2" should be submitted to rockchip soc related tree and the 
rest can go through the wireless-next tree. Got it.

Regards,
Arend
---
$ ./scripts/get_maintainer.pl -f 
arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts
Rob Herring <robh@xxxxxxxxxx> (maintainer:OPEN FIRMWARE AND FLATTENED 
DEVICE TREE BINDINGS)
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx> (maintainer:OPEN FIRMWARE AND 
FLATTENED DEVICE TREE BINDINGS)
Conor Dooley <conor+dt@xxxxxxxxxx> (maintainer:OPEN FIRMWARE AND FLATTENED 
DEVICE TREE BINDINGS)
Heiko Stuebner <heiko@xxxxxxxxx> (maintainer:ARM/Rockchip SoC 
support,commit_signer:11/11=100%,authored:1/11=9%,removed_lines:1/1=100%)
Muhammed Efe Cetin <efectn@xxxxxxxxxxxxxx> 
(commit_signer:10/11=91%,authored:10/11=91%,added_lines:685/685=100%)
Dragan Simic <dsimic@xxxxxxxxxxx> (commit_signer:1/11=9%)
devicetree@xxxxxxxxxxxxxxx (open list:OPEN FIRMWARE AND FLATTENED DEVICE 
TREE BINDINGS)
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx (moderated list:ARM/Rockchip SoC support)
linux-rockchip@xxxxxxxxxxxxxxxxxxx (open list:ARM/Rockchip SoC support)
linux-kernel@xxxxxxxxxxxxxxx (open list)

> And just in case: this is neither specific to wireless nor to Broadcom.
> This is for entire Linux kernel.
>
> Best regards,
> Krzysztof