Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> writes: > 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. Yes, this is how we have done before as well. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
