| Message ID | 20240813082007.2625841-1-jacobe.zang@wesion.com |
|---|---|
| Headers | show |
| Series | Add AP6275P wireless support | expand |
On 13/08/2024 19:04, Arend Van Spriel wrote: > On August 13, 2024 10:20:24 AM Jacobe Zang <jacobe.zang@wesion.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. Best regards, Krzysztof
On 2024/8/14 16:53, 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@wesion.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. > I'm little confused that I should push bindings as a series, DTS as a series and driver as a series separately, so next time I should push 3 series, right?
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@wesion.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@vger.kernel.org reference to: https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com 2) brcmfmac driver changes -> linux-wireless@vger.kernel.org Regards, Arend
On 14/08/2024 11:12, Jacobe Zang wrote: > > > On 2024/8/14 16:53, 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@wesion.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. >> > > I'm little confused that I should push bindings as a series, DTS as a > series and driver as a series separately, so next time I should push 3 > series, right? No. I said only DTS. Best regards, Krzysztof
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@wesion.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@vger.kernel.org > reference to: > https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com > > 2) brcmfmac driver changes -> linux-wireless@vger.kernel.org No. I said only DTS is separate. This was always the rule, since forever. Documentation/devicetree/bindings/submitting-patches.rst Best regards, Krzysztof
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@wesion.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@vger.kernel.org >> reference to: >> https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com >> >> 2) brcmfmac driver changes -> linux-wireless@vger.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@vger.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? Regards, Arend
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@wesion.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@vger.kernel.org >>> reference to: >>> https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com >>> >>> 2) brcmfmac driver changes -> linux-wireless@vger.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@vger.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. Best regards, Krzysztof
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@wesion.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@vger.kernel.org >>>> reference to: >>>> https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com >>>> >>>> 2) brcmfmac driver changes -> linux-wireless@vger.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@vger.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
On August 14, 2024 4:08:52 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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@wesion.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@vger.kernel.org >>>>> reference to: >>>>> https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com >>>>> >>>>> 2) brcmfmac driver changes -> linux-wireless@vger.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@vger.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. Regards, Arend --- $ ./scripts/get_maintainer.pl -f arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts Rob Herring <robh@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) Krzysztof Kozlowski <krzk+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) Conor Dooley <conor+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC support,commit_signer:11/11=100%,authored:1/11=9%,removed_lines:1/1=100%) Muhammed Efe Cetin <efectn@protonmail.com> (commit_signer:10/11=91%,authored:10/11=91%,added_lines:685/685=100%) Dragan Simic <dsimic@manjaro.org> (commit_signer:1/11=9%) devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support) linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support) linux-kernel@vger.kernel.org (open list) > > And just in case: this is neither specific to wireless nor to Broadcom. > This is for entire Linux kernel. > > Best regards, > Krzysztof
Arend Van Spriel <arend.vanspriel@broadcom.com> writes: > On August 14, 2024 4:08:52 PM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.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@wesion.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@vger.kernel.org >>>>>> reference to: >>>>>> https://patch.msgid.link/20240813082007.2625841-1-jacobe.zang@wesion.com >>>>>> >>>>>> 2) brcmfmac driver changes -> linux-wireless@vger.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@vger.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.
These add AP6275P wireless support on Khadas Edge2. Enable 32k clock for Wi-Fi module and extend the hardware IDs table in the brcmfmac driver for it to attach. Changes in v10: - Use ret instead unused probe_attach_result in sdio.c - Link to v9: https://lore.kernel.org/all/20240810035141.439024-1-jacobe.zang@wesion.com/ Changes in v9: - Add return -ENODEV error pointer from brcmf_sdio_probe as the default for the fail path - Add if statement for brcmf_of_probe in common.c - Retain modifications to of.c other than the return values - Link to v8: https://lore.kernel.org/all/20240805073425.3492078-1-jacobe.zang@wesion.com/ Changes in v8: - Add appropriate errno's for return values that will be send to bus when error occurred. - Link to v7: https://lore.kernel.org/all/20240802025715.2360456-1-jacobe.zang@wesion.com/ Changes in v7: - Change brcmf_of_probe prototypes from void to int, add appropriate errno's for return value, move clock check to the end of brcmf_of_probe - Add "brcm,bcm4329-fmac" compatible for wifi node - Link to v6: https://lore.kernel.org/all/20240731061132.703368-1-jacobe.zang@wesion.com/ Changes in v6: - Move "brcm,bcm4329-fmac" check to the top of brcmf_of_probe in of.c - Add return if clk didn't set in DTS -Link to v5: https://lore.kernel.org/all/20240730033053.4092132-1-jacobe.zang@wesion.com/ Changes in v5: - Add more commit message to the clock in bindings - Use IS_ERR_OR_NULL as a judgment condition of clk - Link to v4: https://lore.kernel.org/all/20240729070102.3770318-1-jacobe.zang@wesion.com/ Changes in v4: - Change clock description in dt-bindings - Move enable clk from pcie.c to of.c - Add compatible for wifi node in DTS - Add random seed flag for firmware download - Link to v3: https://lore.kernel.org/all/20240630073605.2164346-1-jacobe.zang@wesion.com/ Changes in v3: - Dropped redundant parts in dt-bindings. - Change driver patch title prefix as 'wifi: brcmfmac:'. - Change DTS Wi-Fi node clock-name as 'lpo'. - Link to v2: https://lore.kernel.org/all/20240624081906.1399447-1-jacobe.zang@wesion.com/ Changes in v2: - Add SoB tags for original developer. - Add dt-bindings for pci14e4,449d and clocks. - Replace dev_info to brcmf_dbg in pcie.c - Link to v1: https://lore.kernel.org/all/20240620020015.4021696-1-jacobe.zang@wesion.com/ Jacobe Zang (5): dt-bindings: net: wireless: brcm4329-fmac: add pci14e4,449d dt-bindings: net: wireless: brcm4329-fmac: add clock description for AP6275P arm64: dts: rockchip: Add AP6275P wireless support to Khadas Edge 2 wifi: brcmfmac: Add optional lpo clock enable support wifi: brcmfmac: add flag for random seed during firmware download .../net/wireless/brcm,bcm4329-fmac.yaml | 9 +++ .../dts/rockchip/rk3588s-khadas-edge2.dts | 16 ++++++ .../broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +- .../broadcom/brcm80211/brcmfmac/common.c | 3 +- .../wireless/broadcom/brcm80211/brcmfmac/of.c | 53 +++++++++++------- .../wireless/broadcom/brcm80211/brcmfmac/of.h | 9 +-- .../broadcom/brcm80211/brcmfmac/pcie.c | 55 ++++++++++++++++--- .../broadcom/brcm80211/brcmfmac/sdio.c | 22 +++++--- .../broadcom/brcm80211/brcmfmac/usb.c | 3 + .../broadcom/brcm80211/include/brcm_hw_ids.h | 2 + 10 files changed, 132 insertions(+), 44 deletions(-)