[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87bk1uyvkv.fsf@kernel.org>
Date: Thu, 15 Aug 2024 12:38:40 +0300
From: Kalle Valo <kvalo@...nel.org>
To: Arend Van Spriel <arend.vanspriel@...adcom.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Krzysztof
Kozlowski <krzk@...nel.org>, Jacobe Zang <jacobe.zang@...ion.com>,
<robh@...nel.org>, <krzk+dt@...nel.org>, <heiko@...ech.de>,
<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<pabeni@...hat.com>, <conor+dt@...nel.org>, <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
Arend Van Spriel <arend.vanspriel@...adcom.com> writes:
> On August 14, 2024 4:08:52 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> 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@...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.
>
> 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
Powered by blists - more mailing lists