* Re: [PATCH] dt-bindings: i2c: cnxt,cx92755-i2c: Convert to DT schema
From: Rob Herring @ 2026-04-07 16:46 UTC (permalink / raw)
To: Shi Hao
Cc: krzk+dt, andi.shyti, conor+dt, linux-i2c, devicetree,
linux-kernel, daniel.baluta, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <20260323174236.147507-1-i.shihao.999@gmail.com>
On Mon, Mar 23, 2026 at 11:12:36PM +0530, Shi Hao wrote:
> Convert the Conexant Digicolor I2C bindings to DT schema.
>
> Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
> ---
>
> Note:
> This patch is part of the GSoC2026 application process for device tree
> bindings conversions https://github.com/LinuxFoundationGSoC/ProjectIde
> as/wiki/GSoC-2026-Device-Tree-Bindings
> ---
> .../bindings/i2c/cnxt,cx92755-i2c.yaml | 51 +++++++++++++++++++
> .../devicetree/bindings/i2c/i2c-digicolor.txt | 25 ---------
> 2 files changed, 51 insertions(+), 25 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
> delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-digicolor.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml b/Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
> new file mode 100644
> index 000000000000..669397bbc571
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/cnxt,cx92755-i2c.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i2c/cnxt,cx92755-i2c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Conexant Digicolor I2C controller
> +
> +allOf:
> + - $ref: /schemas/i2c/i2c-controller.yaml#
> +
> +maintainers:
> + - Baruch Siach <baruch@tkos.co.il>
> +
> +properties:
> + compatible:
> + const: cnxt,cx92755-i2c
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-frequency:
> + default: 100000
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - '#address-cells'
> + - '#size-cells'
These 2 are required by i2c-controller.yaml already, so you can drop
them. Otherwise, I don't know what issue Krzysztof sees either.
With that,
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH 15/15] Introduce v18 dtb version
From: Herve Codina @ 2026-04-07 16:44 UTC (permalink / raw)
To: Luca Ceresoli
Cc: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <DHHX3P5TS0D3.VWALCUNJ7LGL@bootlin.com>
Hi Luca,
On Wed, 01 Apr 2026 17:19:09 +0200
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> > This v18 version will add support for
> > - Structured tags.
> > Those tags value definition will allow old libfdt, dtc and other
> > tools to skip unknown tags if encountered in future dtb version.
>
> "old" seems to imply that versions released before today will be able to
> wkip unknown tags. I think this should be clarified along the lines of:
>
> libfdt, dtc and other tools implementing version v18 will be able to wkip
> unknown tags in dtbs generated with later versions of dtc
Yes, I will add this clarification in the next iteration.
>
> > - dt_flags header field.
> > For now this flag field is set to 0. It is a placeholder for future
> > dtb version and could be used to store some dtb related information
> > such as the kind of dtb.
>
> Is this intended for DT addons?
>
> You may mention a realistiv use case here.
Intended, maybe not. Used by addons, yes, for sure.
What do you think if I add the following:
For instance, the future addons format will use this field to
clearly identify that the dtb is an addon dtb.
...
> >
> > Compared to previous version, it is worth noting that the dtb is not
> ^
> "dtb version"
>
> > downgrade for all modification but only when unknown tags are removed
> ^
> downgraded for any
>
>
> > due a property modification.
> ^
> "due to a ..."
>
> I'm not sure I got what you mean by the initial "Compared to previous
> version". Version(s) of what?
>
> If I just remove those 4 words the sentence seems OK to me BTW.
Is the following clearer?
It is worth noting that with this v18 version, the dtb version is not
downgraded for any modification but only when unknown tags are removed
due to a property modification. In v17 or older version any modification
led to a dtb version downgrade.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: display: panel: Add ChipWealth CH13726A AMOLED driver
From: Rob Herring @ 2026-04-07 16:40 UTC (permalink / raw)
To: Aaron Kling
Cc: Krzysztof Kozlowski, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Krzysztof Kozlowski, Conor Dooley, dri-devel,
devicetree, linux-kernel, Teguh Sobirin
In-Reply-To: <CALHNRZ-TAQmcwYr9iW+j+S5Egh11C0LpPeY1SO=hgDdvG8otqQ@mail.gmail.com>
On Tue, Mar 24, 2026 at 11:01:33AM -0500, Aaron Kling wrote:
> On Tue, Mar 24, 2026 at 4:08 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Mon, Mar 23, 2026 at 12:08:32PM -0500, Aaron Kling wrote:
> > > The Chip Wealth Technology CH13726A AMOLED driver is a single chip
> > > solution for MIPI-DSI. This is used for the AYN Thor bottom panel.
> > >
> > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > ---
> > > .../display/panel/chipwealth,ch13726a.yaml | 65 ++++++++++++++++++++++
> > > 1 file changed, 65 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml b/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..5d964900795653401a871994bcf6403cdeaad64f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/panel/chipwealth,ch13726a.yaml
> > > @@ -0,0 +1,65 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/panel/chipwealth,ch13726a.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Chip Wealth Technology CH13726A AMOLED driver
> > > +
> > > +maintainers:
> > > + - Neil Armstrong <neil.armstrong@linaro.org>
> > > +
> > > +description:
> > > + Chip Wealth Technology CH13726A is a single-chip solution
> > > + for AMOLED connected using a MIPI-DSI video interface.
> >
> > Here you describe the hardware, including what I asked last time -
> > explain why this is ayntec thor panel, but not chipwealth,ch13726a.
> >
> > Then also name the file as the compatible. If you do not know the part
> > (model?) number, then why do you think filename should be called
> > ch13726a?
>
> The vendor source release for the AYN Thor calls the 'panel' ch13726a,
> but per the data sheet for said part, it's a chip used in various
> panels, not a panel itself. The handling for various panels using this
> chip will share a lot of similarities since the chip is what the
> kernel driver will talk to. The alternative would be having separate
> drivers and bindings for every panel that will be mostly duplicated.
> This is the case for multiple things supported in the kernel already,
> such as the vtdr6130 which is currently described as a unique panel
> but is in fact the part number for a ddic. And I will need to refactor
> that for another device I have in the pipeline. In fact, all the
> device panels I need to submit in this context reference ddic's and
> not unique panel models. I'm waiting to see what gets approved for
> this series before sending the rest of those in.
>
> If I add something to the description like 'This chip is not a panel
> itself, but is used to control various panels', would that be
> sufficient? Or does the kernel need a new way to describe ddic's
> separately from panels, since this seems to be common now?
So sounds like the compatible should be '"ayntec,thor-panel-bottom",
"chipwealth,ch13726a"' with the filename being chipwealth,ch13726a.yaml.
At least that is how we do most cases where we know the underlying chip.
Rob
^ permalink raw reply
* Re: [PATCH 2/2] riscv: dts: sophgo: sg2042: use hex for CPU unit address
From: Conor Dooley @ 2026-04-07 16:31 UTC (permalink / raw)
To: Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Chen Wang, Han Gao,
Nutty Liu, Guodong Xu, Guo Ren, Xiaoguang Xing, devicetree,
linux-riscv, sophgo, linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260406232655.144043-3-inochiama@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
On Tue, Apr 07, 2026 at 07:26:55AM +0800, Inochi Amaoto wrote:
> Previous the CPU unit address cpu of sg2042 use decimal, it is
> not following the general convention for unit addresses of the
> OF. Convent the unit address to hex to resolve this problem.
>
> The introduces a small ABI break for the CPU id, but it should
> affect nothing since there is no direct full-path reference to
> these CPU nodes.
I don't think node names are abi anyway.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] riscv: add UltraRISC SoC family Kconfig support
From: Conor Dooley @ 2026-04-07 16:29 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260407-ultrarisc-pcie-v2-1-2aa2a19a7fb3@ultrarisc.com>
[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]
On Tue, Apr 07, 2026 at 10:40:52AM +0800, Jia Wang wrote:
> The first SoC in the UltraRISC series is UR-DP1000, containing octa
> UltraRISC C100 cores.
Not gonna lie, I find it odd that pcie is where this platform starts
off, but sure. What's the plan for adding the rest of the platform?
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> arch/riscv/Kconfig.socs | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index d621b85dd63b..98708569ec6a 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -84,6 +84,15 @@ config ARCH_THEAD
> help
> This enables support for the RISC-V based T-HEAD SoCs.
>
> +config ARCH_ULTRARISC
> + bool "UltraRISC RISC-V SoCs"
> + help
> + This enables support for UltraRISC SoC platform hardware,
> + including boards based on the UR-DP1000.
> + UR-DP1000 is an 8-core 64-bit RISC-V SoC that supports
> + the RV64GCBHX ISA. It supports Hardware Virtualization
> + and RISC-V RV64 ISA H(v1.0) Extension.
Delete this section IMO, doesn't provide any real value. Don't need nor
want the marketing brochure in the help text. The first sentence is
sufficient.
> +
> config ARCH_VIRT
> bool "QEMU Virt Machine"
> select POWER_RESET
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH ath-next v5 6/6] wifi: ath12k: Enable IPQ5424 WiFi device support
From: Rameshkumar Sundaram @ 2026-04-07 16:24 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Sowmiya Sree Elavalagan, Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-6-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com>
>
> Currently, ath12k AHB (in IPQ5332) uses SCM calls to authenticate the
> firmware image to bring up userpd. From IPQ5424 onwards, Q6 firmware can
> directly communicate with the Trusted Management Engine - Lite (TME-L),
> eliminating the need for SCM calls for userpd bring-up.
>
> Hence, to enable IPQ5424 device support, use qcom_mdt_load_no_init() and
> skip the SCM call as Q6 will directly authenticate the userpd firmware.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com>
> Co-developed-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/ahb.c | 36 ++++++++++++++++++-----------
> drivers/net/wireless/ath/ath12k/ahb.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/ahb.c | 8 +++++++
> 3 files changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
> index 9a4d34e49104..2dcf0a52e4c1 100644
> --- a/drivers/net/wireless/ath/ath12k/ahb.c
> +++ b/drivers/net/wireless/ath/ath12k/ahb.c
> @@ -382,8 +382,12 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
> ATH12K_AHB_UPD_SWID;
>
> /* Load FW image to a reserved memory location */
> - ret = qcom_mdt_load(dev, fw, fw_name, pasid, mem_region, mem_phys, mem_size,
> - &mem_phys);
> + if (ab_ahb->scm_auth_enabled)
> + ret = qcom_mdt_load(dev, fw, fw_name, pasid, mem_region,
> + mem_phys, mem_size, &mem_phys);
> + else
> + ret = qcom_mdt_load_no_init(dev, fw, fw_name, mem_region,
> + mem_phys, mem_size, &mem_phys);
> if (ret) {
> ath12k_err(ab, "Failed to load MDT segments: %d\n", ret);
> goto err_fw;
> @@ -414,11 +418,13 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
> goto err_fw2;
> }
>
> - /* Authenticate FW image using peripheral ID */
> - ret = qcom_scm_pas_auth_and_reset(pasid);
> - if (ret) {
> - ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
> - goto err_fw2;
> + if (ab_ahb->scm_auth_enabled) {
> + /* Authenticate FW image using peripheral ID */
> + ret = qcom_scm_pas_auth_and_reset(pasid);
> + if (ret) {
> + ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
> + goto err_fw2;
> + }
> }
>
> /* Instruct Q6 to spawn userPD thread */
> @@ -475,13 +481,15 @@ static void ath12k_ahb_power_down(struct ath12k_base *ab, bool is_suspend)
>
> qcom_smem_state_update_bits(ab_ahb->stop_state, BIT(ab_ahb->stop_bit), 0);
>
> - pasid = (u32_encode_bits(ab_ahb->userpd_id, ATH12K_USERPD_ID_MASK)) |
> - ATH12K_AHB_UPD_SWID;
> - /* Release the firmware */
> - ret = qcom_scm_pas_shutdown(pasid);
> - if (ret)
> - ath12k_err(ab, "scm pas shutdown failed for userPD%d: %d\n",
> - ab_ahb->userpd_id, ret);
> + if (ab_ahb->scm_auth_enabled) {
> + pasid = (u32_encode_bits(ab_ahb->userpd_id, ATH12K_USERPD_ID_MASK)) |
> + ATH12K_AHB_UPD_SWID;
> + /* Release the firmware */
> + ret = qcom_scm_pas_shutdown(pasid);
> + if (ret)
> + ath12k_err(ab, "scm pas shutdown failed for userPD%d\n",
> + ab_ahb->userpd_id);
> + }
> }
>
> static void ath12k_ahb_init_qmi_ce_config(struct ath12k_base *ab)
> diff --git a/drivers/net/wireless/ath/ath12k/ahb.h b/drivers/net/wireless/ath/ath12k/ahb.h
> index be9e31b3682d..0fa15daaa3e6 100644
> --- a/drivers/net/wireless/ath/ath12k/ahb.h
> +++ b/drivers/net/wireless/ath/ath12k/ahb.h
> @@ -68,6 +68,7 @@ struct ath12k_ahb {
> int userpd_irq_num[ATH12K_USERPD_MAX_IRQ];
> const struct ath12k_ahb_ops *ahb_ops;
> const struct ath12k_ahb_device_family_ops *device_family_ops;
> + bool scm_auth_enabled;
> };
>
> struct ath12k_ahb_driver {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/ahb.c b/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
> index a6c5f7689edd..6a8b8b2a56f9 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
> @@ -19,6 +19,9 @@ static const struct of_device_id ath12k_wifi7_ahb_of_match[] = {
> { .compatible = "qcom,ipq5332-wifi",
> .data = (void *)ATH12K_HW_IPQ5332_HW10,
> },
> + { .compatible = "qcom,ipq5424-wifi",
> + .data = (void *)ATH12K_HW_IPQ5424_HW10,
> + },
> { }
> };
>
> @@ -38,6 +41,11 @@ static int ath12k_wifi7_ahb_probe(struct platform_device *pdev)
> switch (hw_rev) {
> case ATH12K_HW_IPQ5332_HW10:
> ab_ahb->userpd_id = ATH12K_IPQ5332_USERPD_ID;
> + ab_ahb->scm_auth_enabled = true;
> + break;
> + case ATH12K_HW_IPQ5424_HW10:
> + ab_ahb->userpd_id = ATH12K_IPQ5332_USERPD_ID;
> + ab_ahb->scm_auth_enabled = false;
> break;
> default:
> return -EOPNOTSUPP;
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 0/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-04-07 15:35 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
This series adds support for the DDR Performance Monitoring Unit (PMU)
present in Marvell CN20K SoCs.
The DDR PMU is part of the DRAM Subsystem (DSS) and provides hardware
counters to monitor DDR traffic and performance events. The block
implements eight programmable counters and two fixed-function counters
tracking DDR read and write activity, and is accessed via a dedicated
MMIO region.
CN20K is the successor to CN10K, and the DDR PMU hardware is functionally
equivalent to the CN10K implementation, with only minor differences in
register offsets and event mappings. To allow software to distinguish
between the two silicon variants, this series introduces a specific
"marvell,cn20k-ddr-pmu" compatible and extends the existing
marvell_cn10k_ddr_pmu driver to handle CN20K via variant-specific data.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Chnages in v3:
- Expanded cover letter and commit message to better describe the DDR PMU
hardware and its relationship to CN10K
- Fixed the file name.
Changes in v2:
- Fixed YAML syntax error triggered by a tab character in the examples
section, which caused dt_binding_check to fail.
Changes in v1:
- Added a description field to the binding.
- Simplified the compatible property using 'const' instead of 'items/enum'.
- Updated the example node name to include a unit-address matching the reg base.
Geetha sowjanya (2):
dt-bindings: perf: marvell: Document CN20K DDR PMU
perf: marvell: Add CN20K DDR PMU support
.../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 ++++
drivers/perf/marvell_cn10k_ddr_pmu.c | 187 ++++++++++++++++--
2 files changed, 210 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr-pmu.yaml
--
2.25.1
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: thermal: idle: Complete the example code
From: Conor Dooley @ 2026-04-07 16:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20260407053957.10508-2-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
From: Conor Dooley @ 2026-04-07 16:23 UTC (permalink / raw)
To: Sandie Cao
Cc: Yixun Lan, Troy Mitchell, Conor Dooley, Emil Renner Berthing,
Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel
In-Reply-To: <20260407055707.1202730-1-sandie.cao@deepcomputing.io>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH ath-next v5 5/6] wifi: ath12k: Add CE remap hardware parameters for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:23 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-5-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add CE remap hardware parameters for Ath12k AHB device IPQ5424.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/ce.h | 13 +++++++++----
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 22 +++++++++++++++++-----
> 2 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/ce.h b/drivers/net/wireless/ath/ath12k/ce.h
> index df4f2a4f8480..009cddf2d68d 100644
> --- a/drivers/net/wireless/ath/ath12k/ce.h
> +++ b/drivers/net/wireless/ath/ath12k/ce.h
> @@ -38,10 +38,15 @@
> #define PIPEDIR_INOUT 3 /* bidirectional */
> #define PIPEDIR_INOUT_H2H 4 /* bidirectional, host to host */
>
> -/* CE address/mask */
> -#define CE_HOST_IE_ADDRESS 0x75804C
> -#define CE_HOST_IE_2_ADDRESS 0x758050
> -#define CE_HOST_IE_3_ADDRESS CE_HOST_IE_ADDRESS
> +/* IPQ5332 CE address/mask */
> +#define CE_HOST_IPQ5332_IE_ADDRESS 0x75804C
> +#define CE_HOST_IPQ5332_IE_2_ADDRESS 0x758050
> +#define CE_HOST_IPQ5332_IE_3_ADDRESS CE_HOST_IPQ5332_IE_ADDRESS
> +
> +/* IPQ5424 CE address/mask */
> +#define CE_HOST_IPQ5424_IE_ADDRESS 0x21804C
> +#define CE_HOST_IPQ5424_IE_2_ADDRESS 0x218050
> +#define CE_HOST_IPQ5424_IE_3_ADDRESS CE_HOST_IPQ5424_IE_ADDRESS
>
> #define CE_HOST_IE_3_SHIFT 0xC
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> index 2b5d1f7e9e04..cb3185850439 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> @@ -329,9 +329,15 @@ static const struct ath12k_hw_ring_mask ath12k_wifi7_hw_ring_mask_wcn7850 = {
> };
>
> static const struct ce_ie_addr ath12k_wifi7_ce_ie_addr_ipq5332 = {
> - .ie1_reg_addr = CE_HOST_IE_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> - .ie2_reg_addr = CE_HOST_IE_2_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> - .ie3_reg_addr = CE_HOST_IE_3_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> + .ie1_reg_addr = CE_HOST_IPQ5332_IE_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> + .ie2_reg_addr = CE_HOST_IPQ5332_IE_2_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> + .ie3_reg_addr = CE_HOST_IPQ5332_IE_3_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
> +};
> +
> +static const struct ce_ie_addr ath12k_wifi7_ce_ie_addr_ipq5424 = {
> + .ie1_reg_addr = CE_HOST_IPQ5424_IE_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .ie2_reg_addr = CE_HOST_IPQ5424_IE_2_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .ie3_reg_addr = CE_HOST_IPQ5424_IE_3_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
> };
>
> static const struct ce_remap ath12k_wifi7_ce_remap_ipq5332 = {
> @@ -340,6 +346,12 @@ static const struct ce_remap ath12k_wifi7_ce_remap_ipq5332 = {
> .cmem_offset = HAL_SEQ_WCSS_CMEM_OFFSET,
> };
>
> +static const struct ce_remap ath12k_wifi7_ce_remap_ipq5424 = {
> + .base = HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .size = HAL_IPQ5424_CE_SIZE,
> + .cmem_offset = HAL_SEQ_WCSS_CMEM_OFFSET,
> +};
> +
> static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
> {
> .name = "qcn9274 hw1.0",
> @@ -824,8 +836,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
> .iova_mask = 0,
> .supports_aspm = false,
>
> - .ce_ie_addr = NULL,
> - .ce_remap = NULL,
> + .ce_ie_addr = &ath12k_wifi7_ce_ie_addr_ipq5424,
> + .ce_remap = &ath12k_wifi7_ce_remap_ipq5424,
> .bdf_addr_offset = 0x940000,
>
> .current_cc_support = false,
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 4/6] wifi: ath12k: add ath12k_hw_regs for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:22 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-4-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add register addresses (ath12k_hw_regs) for ath12k AHB based
> WiFi 7 device IPQ5424.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/wifi7/hal.c | 2 +-
> drivers/net/wireless/ath/ath12k/wifi7/hal.h | 3 +
> .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 88 ++++++++++++++++++++++
> .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h | 1 +
> 4 files changed, 93 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> index c2cc99a83f09..a0a1902fb491 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> @@ -55,7 +55,7 @@ static const struct ath12k_hw_version_map ath12k_wifi7_hw_ver_map[] = {
> .hal_desc_sz = sizeof(struct hal_rx_desc_qcn9274_compact),
> .tcl_to_wbm_rbm_map = ath12k_hal_tcl_to_wbm_rbm_map_qcn9274,
> .hal_params = &ath12k_hw_hal_params_ipq5332,
> - .hw_regs = NULL,
> + .hw_regs = &ipq5424_regs,
> },
> };
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.h b/drivers/net/wireless/ath/ath12k/wifi7/hal.h
> index 9337225a5253..3d9386198893 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal.h
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.h
> @@ -364,6 +364,9 @@
> #define HAL_IPQ5332_CE_WFSS_REG_BASE 0x740000
> #define HAL_IPQ5332_CE_SIZE 0x100000
>
> +#define HAL_IPQ5424_CE_WFSS_REG_BASE 0x200000
> +#define HAL_IPQ5424_CE_SIZE 0x100000
> +
> #define HAL_RX_MAX_BA_WINDOW 256
>
> #define HAL_DEFAULT_BE_BK_VI_REO_TIMEOUT_USEC (100 * 1000)
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
> index 41c918eb1767..ba9ce1e718e8 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
> @@ -484,6 +484,94 @@ const struct ath12k_hw_regs ipq5332_regs = {
> HAL_IPQ5332_CE_WFSS_REG_BASE,
> };
>
> +const struct ath12k_hw_regs ipq5424_regs = {
> + /* SW2TCL(x) R0 ring configuration address */
> + .tcl1_ring_id = 0x00000918,
> + .tcl1_ring_misc = 0x00000920,
> + .tcl1_ring_tp_addr_lsb = 0x0000092c,
> + .tcl1_ring_tp_addr_msb = 0x00000930,
> + .tcl1_ring_consumer_int_setup_ix0 = 0x00000940,
> + .tcl1_ring_consumer_int_setup_ix1 = 0x00000944,
> + .tcl1_ring_msi1_base_lsb = 0x00000958,
> + .tcl1_ring_msi1_base_msb = 0x0000095c,
> + .tcl1_ring_base_lsb = 0x00000910,
> + .tcl1_ring_base_msb = 0x00000914,
> + .tcl1_ring_msi1_data = 0x00000960,
> + .tcl2_ring_base_lsb = 0x00000988,
> + .tcl_ring_base_lsb = 0x00000b68,
> +
> + /* TCL STATUS ring address */
> + .tcl_status_ring_base_lsb = 0x00000d48,
> +
> + /* REO DEST ring address */
> + .reo2_ring_base = 0x00000578,
> + .reo1_misc_ctrl_addr = 0x00000b9c,
> + .reo1_sw_cookie_cfg0 = 0x0000006c,
> + .reo1_sw_cookie_cfg1 = 0x00000070,
> + .reo1_qdesc_lut_base0 = 0x00000074,
> + .reo1_qdesc_lut_base1 = 0x00000078,
> + .reo1_ring_base_lsb = 0x00000500,
> + .reo1_ring_base_msb = 0x00000504,
> + .reo1_ring_id = 0x00000508,
> + .reo1_ring_misc = 0x00000510,
> + .reo1_ring_hp_addr_lsb = 0x00000514,
> + .reo1_ring_hp_addr_msb = 0x00000518,
> + .reo1_ring_producer_int_setup = 0x00000524,
> + .reo1_ring_msi1_base_lsb = 0x00000548,
> + .reo1_ring_msi1_base_msb = 0x0000054C,
> + .reo1_ring_msi1_data = 0x00000550,
> + .reo1_aging_thres_ix0 = 0x00000B28,
> + .reo1_aging_thres_ix1 = 0x00000B2C,
> + .reo1_aging_thres_ix2 = 0x00000B30,
> + .reo1_aging_thres_ix3 = 0x00000B34,
> +
> + /* REO Exception ring address */
> + .reo2_sw0_ring_base = 0x000008c0,
> +
> + /* REO Reinject ring address */
> + .sw2reo_ring_base = 0x00000320,
> + .sw2reo1_ring_base = 0x00000398,
> +
> + /* REO cmd ring address */
> + .reo_cmd_ring_base = 0x000002A8,
> +
> + /* REO status ring address */
> + .reo_status_ring_base = 0x00000aa0,
> +
> + /* WBM idle link ring address */
> + .wbm_idle_ring_base_lsb = 0x00000d3c,
> + .wbm_idle_ring_misc_addr = 0x00000d4c,
> + .wbm_r0_idle_list_cntl_addr = 0x00000240,
> + .wbm_r0_idle_list_size_addr = 0x00000244,
> + .wbm_scattered_ring_base_lsb = 0x00000250,
> + .wbm_scattered_ring_base_msb = 0x00000254,
> + .wbm_scattered_desc_head_info_ix0 = 0x00000260,
> + .wbm_scattered_desc_head_info_ix1 = 0x00000264,
> + .wbm_scattered_desc_tail_info_ix0 = 0x00000270,
> + .wbm_scattered_desc_tail_info_ix1 = 0x00000274,
> + .wbm_scattered_desc_ptr_hp_addr = 0x0000027c,
> +
> + /* SW2WBM release ring address */
> + .wbm_sw_release_ring_base_lsb = 0x0000037c,
> +
> + /* WBM2SW release ring address */
> + .wbm0_release_ring_base_lsb = 0x00000e08,
> + .wbm1_release_ring_base_lsb = 0x00000e80,
> +
> + /* PPE release ring address */
> + .ppe_rel_ring_base = 0x0000046c,
> +
> + /* CE address */
> + .umac_ce0_src_reg_base = 0x00200000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .umac_ce0_dest_reg_base = 0x00201000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .umac_ce1_src_reg_base = 0x00202000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> + .umac_ce1_dest_reg_base = 0x00203000 -
> + HAL_IPQ5424_CE_WFSS_REG_BASE,
> +};
> +
> static inline
> bool ath12k_hal_rx_desc_get_first_msdu_qcn9274(struct hal_rx_desc *desc)
> {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
> index 08c0a0469474..03cf3792d523 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
> @@ -17,6 +17,7 @@ extern const struct hal_ops hal_qcn9274_ops;
> extern const struct ath12k_hw_regs qcn9274_v1_regs;
> extern const struct ath12k_hw_regs qcn9274_v2_regs;
> extern const struct ath12k_hw_regs ipq5332_regs;
> +extern const struct ath12k_hw_regs ipq5424_regs;
> extern const struct ath12k_hal_tcl_to_wbm_rbm_map
> ath12k_hal_tcl_to_wbm_rbm_map_qcn9274[DP_TCL_NUM_RING_MAX];
> extern const struct ath12k_hw_hal_params ath12k_hw_hal_params_qcn9274;
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 3/6] wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:21 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-3-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> Add a new ath12k_hw_version_map entry for the AHB based WiFi 7 device
> IPQ5424.
>
> Reuse most of the ath12k_hw_version_map fields such as hal_ops,
> hal_desc_sz, tcl_to_wbm_rbm_map, and hal_params from IPQ5332. The
> register addresses differ on IPQ5424, hence set hw_regs temporarily
> to NULL and populated it in a subsequent patch.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/wifi7/hal.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> index bd1753ca0db6..c2cc99a83f09 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
> @@ -50,6 +50,13 @@ static const struct ath12k_hw_version_map ath12k_wifi7_hw_ver_map[] = {
> .hal_params = &ath12k_hw_hal_params_wcn7850,
> .hw_regs = &qcc2072_regs,
> },
> + [ATH12K_HW_IPQ5424_HW10] = {
> + .hal_ops = &hal_qcn9274_ops,
> + .hal_desc_sz = sizeof(struct hal_rx_desc_qcn9274_compact),
> + .tcl_to_wbm_rbm_map = ath12k_hal_tcl_to_wbm_rbm_map_qcn9274,
> + .hal_params = &ath12k_hw_hal_params_ipq5332,
> + .hw_regs = NULL,
> + },
> };
>
> int ath12k_wifi7_hal_init(struct ath12k_base *ab)
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v6 2/3] dt-bindings: hwmon: emc2305: Add fan-shutdown-percent property
From: Conor Dooley @ 2026-04-07 16:20 UTC (permalink / raw)
To: florin.leotescu
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel,
daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-3-florin.leotescu@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Thu, Apr 02, 2026 at 03:25:13PM +0300, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> The EMC2305 fan controller supports multiple independent PWM fan
> outputs. Some systems require fans to enter a defined safe state
> during system shutdown or reboot handoff, until firmware or the next
> boot stage reconfigures the controller.
>
> Add an optional "fan-shutdown-percent" property to fan child nodes
> allowing the PWM duty cycle applied during shutdown to be configured
> per fan output.
>
> Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH ath-next v5 2/6] wifi: ath12k: Add ath12k_hw_params for IPQ5424
From: Rameshkumar Sundaram @ 2026-04-07 16:20 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Baochen Qiang
In-Reply-To: <20260407-ath12k-ipq5424-v5-2-8e96aa660ec4@oss.qualcomm.com>
On 4/7/2026 10:56 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add ath12k_hw_params for the ath12k AHB-based WiFi 7 device IPQ5424.
> The WiFi device IPQ5424 is similar to IPQ5332. Most of the hardware
> parameters like hw_ops, wmi_init, ring_mask, etc., are the same between
> IPQ5424 and IPQ5332, hence use these same parameters for IPQ5424.
> Some parameters are specific to IPQ5424; initially set these to
> 0 or NULL, and populate them in subsequent patches.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/core.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 79 ++++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 59c193b24764..68453594eba8 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -157,6 +157,7 @@ enum ath12k_hw_rev {
> ATH12K_HW_WCN7850_HW20,
> ATH12K_HW_IPQ5332_HW10,
> ATH12K_HW_QCC2072_HW10,
> + ATH12K_HW_IPQ5424_HW10,
> };
>
> enum ath12k_firmware_mode {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> index ec6dba96640b..2b5d1f7e9e04 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> @@ -753,6 +753,85 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
>
> .dp_primary_link_only = false,
> },
> + {
> + .name = "ipq5424 hw1.0",
> + .hw_rev = ATH12K_HW_IPQ5424_HW10,
> + .fw = {
> + .dir = "IPQ5424/hw1.0",
> + .board_size = 256 * 1024,
> + .cal_offset = 128 * 1024,
> + .m3_loader = ath12k_m3_fw_loader_remoteproc,
> + .download_aux_ucode = false,
> + },
> + .max_radios = 1,
> + .single_pdev_only = false,
> + .qmi_service_ins_id = ATH12K_QMI_WLFW_SERVICE_INS_ID_V01_IPQ5332,
> + .internal_sleep_clock = false,
> +
> + .hw_ops = &qcn9274_ops,
> + .ring_mask = &ath12k_wifi7_hw_ring_mask_ipq5332,
> +
> + .host_ce_config = ath12k_wifi7_host_ce_config_ipq5332,
> + .ce_count = 12,
> + .target_ce_config = ath12k_wifi7_target_ce_config_wlan_ipq5332,
> + .target_ce_count = 12,
> + .svc_to_ce_map =
> + ath12k_wifi7_target_service_to_ce_map_wlan_ipq5332,
> + .svc_to_ce_map_len = 18,
> +
> + .rxdma1_enable = true,
> + .num_rxdma_per_pdev = 1,
> + .num_rxdma_dst_ring = 0,
> + .rx_mac_buf_ring = false,
> + .vdev_start_delay = false,
> +
> + .interface_modes = BIT(NL80211_IFTYPE_STATION) |
> + BIT(NL80211_IFTYPE_AP) |
> + BIT(NL80211_IFTYPE_MESH_POINT),
> + .supports_monitor = true,
> +
> + .idle_ps = false,
> + .download_calib = true,
> + .supports_suspend = false,
> + .tcl_ring_retry = true,
> + .reoq_lut_support = false,
> + .supports_shadow_regs = false,
> +
> + .num_tcl_banks = 48,
> + .max_tx_ring = 4,
> +
> + .mhi_config = NULL,
> +
> + .wmi_init = &ath12k_wifi7_wmi_init_qcn9274,
> +
> + .qmi_cnss_feature_bitmap = BIT(CNSS_QDSS_CFG_MISS_V01),
> +
> + .rfkill_pin = 0,
> + .rfkill_cfg = 0,
> + .rfkill_on_level = 0,
> +
> + .rddm_size = 0,
> +
> + .def_num_link = 0,
> + .max_mlo_peer = 256,
> +
> + .otp_board_id_register = 0,
> +
> + .supports_sta_ps = false,
> +
> + .acpi_guid = NULL,
> + .supports_dynamic_smps_6ghz = false,
> + .iova_mask = 0,
> + .supports_aspm = false,
> +
> + .ce_ie_addr = NULL,
> + .ce_remap = NULL,
> + .bdf_addr_offset = 0x940000,
> +
> + .current_cc_support = false,
> +
> + .dp_primary_link_only = true,
> + },
> };
>
> /* Note: called under rcu_read_lock() */
>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] interconnect: qcom: add Hawi interconnect provider driver
From: Mike Tipton @ 2026-04-07 16:18 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260406-icc-hawi-v2-2-6cfee87a1d25@oss.qualcomm.com>
On Mon, Apr 06, 2026 at 04:04:42PM -0700, Vivek Aknurwar wrote:
> Add driver for the Qualcomm interconnect buses found in Hawi
> based platforms. The topology consists of several NoCs that are
> controlled by a remote processor that collects the aggregated
> bandwidth for each master-slave pair.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Add clock guard DT description
From: Conor Dooley @ 2026-04-07 16:17 UTC (permalink / raw)
To: Vyacheslav Yurkov
Cc: Krzysztof Kozlowski, Rob Herring, Vyacheslav Yurkov,
Michael Turquette, Stephen Boyd, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, linux-clk, devicetree
In-Reply-To: <8129d377-8a63-4589-820b-930a2b43a2f7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
On Sat, Mar 28, 2026 at 03:58:47AM +0100, Vyacheslav Yurkov wrote:
> On 26.03.2026 19:32, Conor Dooley wrote:
>
> > > I was not sure how to provide a diagram in the mailing list, so I posted in
> > > on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1
> > >
> > > It is a driver which models dependencies for other drivers. These are soft
> > > or "indirect" dependencies, because we cannot access the FPGA unless the
> > > FPGA_PLL_locked, and GPIO is telling us we are good to go.
> > >
> > > Conor, I think this should answer your question as well.
> >
> > Not really, but it gets part of the way there. I want to know what this
> > provider actually is. I now know it is a PLL, not an off-chip
> > oscillator, but I know nothing about the interface that you have to it
> > (or if you have one at all). What compatible string/kernel driver does
> > it use?
> >
> > Because SoC-FPGAs can route GPIOs from the SoC part to the FPGA fabric
> > and use them as if interacting with something off-chip, I'm not sure if
> > we are dealing with an separate FPGA or a SoC-FPGA. Which is it?
> > Effectively I want to understand why you cannot just read the lock bit
> > from the PLL directly. In my experience with *SoC*-FPGAs, things like
> > PLLs that must lock for the fabric to be usable have a register
> > interface from which the lock bit can be read, that is of course not
> > clocked by the PLL output clock and therefore accessible before the
> > PLL has locked.
> >
> > I think more info is needed here to guide you on where such a "helper
> > driver" should be located and what the dt represetation should be.
>
> I really appreciate your feedback on this. Here's an attempt to provide a
> better exlanation.
>
> We have various use cases. Most of the time it's a PLL in the FPGA but it
> can also be some signal from a custom FPGA IP used to indicate if some
> preconditions are met and the IP is ready to be used (some kind of inverted
> reset but exposed by the IP). For a PLL we typically get the signal
> connected either to a GPIO IP block (altr,pio-1.0) OR to a bit in a custom
> IP register.
> In addition, some of the IPs in our design do not have a proper split
> between registers and IP core, which means that if an external clock and/or
> PLL lock is missing and we access the registers we won’t ever get an answer
> and thus stall the CPU.
>
> We are using a SoC-FPGA and use some GPIO IP within the FPGA (altr,pio-1.0
> for example).
>
> The PLL itself doesn't have any registers but the signal indicating that it
> is locked is available and routed to such a GPIO.
>
> The point is that we will have several IPs/drivers that will depend on the
> same preconditions (clk, gpios being high or low) and we want to use this
> clk_guard driver as an aggregator for those pre-conditions. Define once,
> reuse a lot.
Apologies for the delay responding, been sick the last week.
I think what you have here is not unreasonable, but may never have users
other than yourself! It's effectively gated-fixed-clock but the gpio
direction is inverted. I'm not keen on the "guarded" wording, but I
think I would want you to become a fixed-clock variant w/ a prefix that
indicates what's different. Then you get locked-gpios instead of
enable-gpios that gated-fixed-clock has.
Or maybe you're a gpio-gate-clock variant instead, and represent the PLL
as a fixed-clock (but I think being a fixed-clock variant makes more
sense).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Hawi SoC
From: Mike Tipton @ 2026-04-07 16:16 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260406-icc-hawi-v2-1-6cfee87a1d25@oss.qualcomm.com>
On Mon, Apr 06, 2026 at 04:04:41PM -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip Interconnect of the Hawi platform.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../bindings/interconnect/qcom,hawi-rpmh.yaml | 131 ++++++++++++++++
> include/dt-bindings/interconnect/qcom,hawi-rpmh.h | 164 +++++++++++++++++++++
> 2 files changed, 295 insertions(+)
>
[..]
> +
> +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_HAWI_H
> +#define __DT_BINDINGS_INTERCONNECT_QCOM_HAWI_H
> +
> +#define MASTER_QSPI_0 0
> +#define MASTER_QUP_2 1
> +#define MASTER_QUP_3 2
> +#define MASTER_QUP_4 3
> +#define MASTER_CRYPTO 4
> +#define MASTER_IPA 5
> +#define MASTER_QUP_1 6
> +#define MASTER_SOCCP_PROC 7
> +#define MASTER_QDSS_ETR 8
> +#define MASTER_QDSS_ETR_1 9
> +#define MASTER_SDCC_2 10
> +#define MASTER_SDCC_4 11
> +#define MASTER_UFS_MEM 12
> +#define MASTER_USB3 13
> +#define SLAVE_A1NOC_SNOC 14
Let's align these values.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Manivannan Sadhasivam @ 2026-04-07 16:14 UTC (permalink / raw)
To: Joe Sandom
Cc: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260407113925.4imd3lxkcrq47pu3@linaro>
On Tue, Apr 07, 2026 at 12:39:25PM +0100, Joe Sandom wrote:
[...]
> > > +&pcie0 {
> > > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> > > +
> > > + pinctrl-0 = <&pcie0_default_state>;
> > > + pinctrl-names = "default";
> > > +
> > > + iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
> > > + <0x100 &apps_smmu 0x1401 0x1>,
> > > + <0x208 &apps_smmu 0x1402 0x1>,
> > > + <0x210 &apps_smmu 0x1403 0x1>,
> > > + <0x218 &apps_smmu 0x1404 0x1>,
> > > + <0x300 &apps_smmu 0x1407 0x1>,
> > > + <0x400 &apps_smmu 0x1408 0x1>,
> > > + <0x500 &apps_smmu 0x140c 0x1>,
> > > + <0x501 &apps_smmu 0x140e 0x1>;
> > > +
> > > + /delete-property/ msi-map;
> >
> > Why?
> I tried extending the msi-map to cover the RIDs from the QPS615
> PCIe switch (matching the iommu-map entries), but this caused
> ITS MAPD command timeouts.
I'm not aware of any specific issue with ITS on this chipset. At what time did
you see the timeout? During probe?
> From what I could gather, deleting
> msi-map forces the PCIe controller to fall back to the internal
> iMSI-RX module, where this worked properly.
>
That's true.
> For reference, I checked the RB3gen2 since it also uses a QPS615
> and there doesn't seem to be any msi-map defined (in kodiak.dtsi).
>
But Kodiak has no MSI support (no LPIs). That's why the ITS node is disabled and
iommu-map is used.
> Any recommendations to resolve this properly?
I will also check internally in the meantime.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: pinctrl: sun55i-a523: increase IRQ bank number
From: Rob Herring (Arm) @ 2026-04-07 16:14 UTC (permalink / raw)
To: Andre Przywara
Cc: linux-sunxi, Chen-Yu Tsai, linux-arm-kernel, Linus Walleij,
Krzysztof Kozlowski, Michal Piekos, linux-gpio, linux-kernel,
Samuel Holland, Conor Dooley, devicetree, Jernej Skrabec
In-Reply-To: <20260323110151.2352832-4-andre.przywara@arm.com>
On Mon, 23 Mar 2026 12:01:49 +0100, Andre Przywara wrote:
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Rob Herring @ 2026-04-07 16:13 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-1-ce0fc07f0e52@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 12:15:28AM -0700, Qiang Yu wrote:
> The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
>
> 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> follower to form a single 8-lane PCIe Gen5 interface
>
> In bifurcation mode, the hardware design requires controlling additional
> resources beyond the standard pcie3a PHY configuration:
>
> - pcie3b's aux_clk (phy_b_aux)
> - pcie3b's phy_gdsc power domain
> - pcie3b's bcr/nocsr reset
>
> Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> 8-lane bifurcation configuration.
>
> The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> requiring the clock-names enum to be extended to support both
> [phy_b_aux, pipediv2] options at index 5. This follows the existing
> pattern used for [rchng, refgen] clocks at index 3.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 45 ++++++++++++++++++----
> 1 file changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..25717bc9be98824e38f3c27c3299fbd1f2e7e299 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> @@ -18,6 +18,7 @@ properties:
> enum:
> - qcom,glymur-qmp-gen4x2-pcie-phy
> - qcom,glymur-qmp-gen5x4-pcie-phy
> + - qcom,glymur-qmp-gen5x8-pcie-phy
> - qcom,kaanapali-qmp-gen3x2-pcie-phy
> - qcom,qcs615-qmp-gen3x1-pcie-phy
> - qcom,qcs8300-qmp-gen4x2-pcie-phy
> @@ -68,20 +69,23 @@ properties:
> - const: ref
> - enum: [rchng, refgen]
> - const: pipe
> - - const: pipediv2
> + - enum: [phy_b_aux, pipediv2]
>
> power-domains:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
Once there is more than 1, you have to define the order and what each
one is for.
>
> resets:
> minItems: 1
> - maxItems: 2
> + maxItems: 4
>
> reset-names:
> minItems: 1
> items:
> - const: phy
> - const: phy_nocsr
> + - const: phy_b
> + - const: phy_b_nocsr
>
> vdda-phy-supply: true
>
> @@ -183,6 +187,7 @@ allOf:
> enum:
> - qcom,glymur-qmp-gen4x2-pcie-phy
> - qcom,glymur-qmp-gen5x4-pcie-phy
> + - qcom,glymur-qmp-gen5x8-pcie-phy
> - qcom,qcs8300-qmp-gen4x2-pcie-phy
> - qcom,sa8775p-qmp-gen4x2-pcie-phy
> - qcom,sa8775p-qmp-gen4x4-pcie-phy
> @@ -201,6 +206,17 @@ allOf:
> clock-names:
> minItems: 6
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,glymur-qmp-gen5x8-pcie-phy
> + then:
> + properties:
> + power-domains:
> + minItems: 2
else:
maxItems: 1
> +
> - if:
> properties:
> compatible:
> @@ -223,11 +239,24 @@ allOf:
> reset-names:
> minItems: 2
> else:
> - properties:
> - resets:
> - maxItems: 1
> - reset-names:
> - maxItems: 1
> + if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,glymur-qmp-gen5x8-pcie-phy
> + then:
> + properties:
> + resets:
> + minItems: 4
> + reset-names:
> + minItems: 4
> + else:
> + properties:
> + resets:
> + maxItems: 1
> + reset-names:
> + maxItems: 1
>
> - if:
> properties:
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Hawi SoC
From: Mike Tipton @ 2026-04-07 16:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vivek Aknurwar, Georgi Djakov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260407-prehistoric-inescapable-loon-cf0dd0@quoll>
Hi Krzysztof,
On Tue, Apr 07, 2026 at 09:42:09AM +0200, Krzysztof Kozlowski wrote:
> On Mon, Apr 06, 2026 at 04:04:41PM -0700, Vivek Aknurwar wrote:
> > Document the RPMh Network-On-Chip Interconnect of the Hawi platform.
> >
> > Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
>
> Same fixes needed I wrote to Hawi upstreaming lead in private. That's
> why I gave that feedback (privately) very fast, to avoid repeating the
> mistake. So since private feedback was ignored, you have now review on
> the lists.
>
> All Qualcomm previous patches are poor:
>
> document the RPMh Network-On-Chip interconnect in Mahua SoC
> document the RPMh Network-On-Chip interconnect in Eliza SoC
> document the RPMh Network-On-Chip interconnect in Kaanapali SoC
> document the RPMh Network-On-Chip interconnect in Glymur SoC
>
> Made by the same people.
>
> Why can't you look how Neil did it for SM8650? Or Luca recently for
> Milos? Or if you cannot look at non-qcom commits then Rajendra for X1E?
I believe you're mainly referring to the lack of "Qualcomm" in the
commit summary and description? I agree that should have been added.
That's understood and it was overlooked for this patch. Most of our
other patches inherently have "qcom" in the area prefixes, but yes when
that isn't present which should clarify that this is Qualcomm-specific.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH 8/9] dt-bindings: arm: apple: Add M3 based devices
From: Rob Herring (Arm) @ 2026-04-07 16:10 UTC (permalink / raw)
To: Janne Grunau
Cc: devicetree, Lorenzo Pieralisi, Wim Van Sebroeck, linux-watchdog,
linux-arm-kernel, linux-kernel, asahi, Guenter Roeck, Neal Gompa,
Andi Shyti, linux-gpio, Conor Dooley, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, Sven Peter,
Linus Walleij, Krzysztof Kozlowski, linux-i2c, linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-8-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:26 +0100, Janne Grunau wrote:
> The Apple devices with the t8122 SoC (M3) are very similar to their M1
> and M2 predecessors.
> Only the 13-inch Macbook Pro is replaced by a 14-inch version based on
> the design of the 14-inch Macbook Pro with (M1/M2 Pro/Max). The Mac mini
> was not offered with M3.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/arm/apple.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 7/9] dt-bindings: pwm: apple,s5l-fpwm: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:09 UTC (permalink / raw)
To: Janne Grunau
Cc: Neal Gompa, linux-arm-kernel, linux-gpio, linux-i2c,
Uwe Kleine-König, Wim Van Sebroeck, linux-watchdog,
devicetree, Guenter Roeck, Krzysztof Kozlowski, Sven Peter,
Sasha Finkelstein, Lorenzo Pieralisi, Andi Shyti, Mark Kettenis,
Linus Walleij, linux-pwm, linux-kernel, asahi, Conor Dooley
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-7-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:25 +0100, Janne Grunau wrote:
> The PWM controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-fpwm" as SoC specific
> compatible under "apple,s5l-fpwm" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: Uwe Kleine-König, Lorenzo Pieralisi, Sven Peter, devicetree,
Andi Shyti, asahi, Guenter Roeck, Krzysztof Kozlowski,
Wim Van Sebroeck, linux-i2c, linux-pwm, Mark Kettenis,
linux-kernel, Linus Walleij, linux-watchdog, Sasha Finkelstein,
Conor Dooley, linux-gpio, Neal Gompa, linux-arm-kernel
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-5-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:23 +0100, Janne Grunau wrote:
> The pin controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
> compatible under "apple,t8103-pinctrl" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: i2c: apple,i2c: Add t8122 compatible
From: Rob Herring (Arm) @ 2026-04-07 16:08 UTC (permalink / raw)
To: Janne Grunau
Cc: Andi Shyti, Wim Van Sebroeck, Sven Peter, linux-watchdog,
linux-kernel, Sasha Finkelstein, devicetree, Neal Gompa, asahi,
Mark Kettenis, linux-pwm, Guenter Roeck, Krzysztof Kozlowski,
linux-arm-kernel, linux-i2c, linux-gpio, Uwe Kleine-König,
Conor Dooley, Lorenzo Pieralisi, Linus Walleij
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-6-5842e1e393a8@jannau.net>
On Fri, 20 Mar 2026 13:23:24 +0100, Janne Grunau wrote:
> The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
> "apple,t8103-i2c" used by the deriver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Documentation/devicetree/bindings/i2c/apple,i2c.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox