* Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Chen-Yu Tsai @ 2026-06-09 3:33 UTC (permalink / raw)
To: Rob Herring, Manivannan Sadhasivam
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Ryder Lee,
Lorenzo Pieralisi, Krzysztof Wilczyński, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-pci,
linux-mediatek, linux-kernel
In-Reply-To: <CAGXv+5GK6+X3-eY8PbrLTsSwK2Uk2URiQti_Gd_9C=RwRaJ44Q@mail.gmail.com>
On Tue, Jun 2, 2026 at 4:02 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> On Tue, Jun 2, 2026 at 5:48 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, May 19, 2026 at 12:51:49PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, May 18, 2026 at 05:02:11PM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, May 15, 2026 at 8:34 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Fri, May 15, 2026 at 05:16:19PM +0800, Chen-Yu Tsai wrote:
> > > > > > On Thu, May 14, 2026 at 7:48 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > >
> > > > > > > On Thu, May 14, 2026 at 03:54:29PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, May 14, 2026 at 1:23 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, May 08, 2026 at 02:36:32PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > > On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> > > > > > > > > > controller memory access could be limited to a small region by the
> > > > > > > > > > firmware configuring a memory protection unit. This memory region
> > > > > > > > > > must be assigned to the PCIe controller so that the OS knows to
> > > > > > > > > > use that region. Otherwise PCIe devices would not work properly.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > So this means, the PCIe devices can only access a specific carveout memory
> > > > > > > > > configured by MPU for DMA? If so, you should use 'dma-ranges' as suggested by
> > > > > > > > > Rob.
> > > > > > > > >
> > > > > > > > > 'memory-region' also serves the purpose, but for PCI, we have the dedicated
> > > > > > > > > 'dma-ranges' property.
> > > > > > > >
> > > > > > > > I think I need some sort of guide on writing the 'dma-ranges' property,
> > > > > > > > because it is not working for me.
> > > > > > > >
> > > > > > > > I'm adding
> > > > > > > >
> > > > > > > > dma-ranges = <0x42000000 0 0x00000000 0 0xc0000000 0 0x4000000>;
> > > > > > > >
> > > > > > >
> > > > > > > So the device DMA address start from 0x0? Isn't it a 1:1 mapping?
> > > > > >
> > > > > > I actually don't know. But
> > > > > >
> > > > > > > dma-ranges = <0x42000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > > > > >
> > > > > > this didn't work either.
> > > > >
> > > > >
> > > > > Hmm. Can you print the DMA address programmed to the device? i.e., the address
> > > > > returned by dma_map_single() in the driver.
> > > >
> > > > On a working system still using the restricted-dma-pool memory region,
> > > > it gives something like 0x00000000c0009000, so indeed it is 1:1 mapping?
> > >
> > > It has to be 1:1 mapping.
> > >
> > > > These are for the RX/TX descriptors [1][2].
> > > >
> > > > When using dma-ranges, the failure is from dma_alloc_coherent() [3][4],
> > > > which is the descriptor ring. On a working system, this is something
> > > > like 0x00000000c0c9d000, so again 1:1.
> > > >
> > > > [1] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L221
> > > > [2] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L829
> > > > [3] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L192
> > > > [4] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L265
> > > >
> > > > > Also, using prefetchable flag is not correct for DMA memory. You should use:
> > > > >
> > > > > dma-ranges = <0x02000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > > >
> > > > This didn't work either. What exactly is supposed to handle dma-ranges?
> > > > I see some code parsing it in the PCI core, but it just saves it to a list.
> > > >
> > >
> > > I think the failure is due to marking the memory as 'reserved' in DT. With
> > > 'dma-ranges', the allocator will only ensure that the allocated memory stays
> > > within this limit. But the allocator itself will not use this property to
> > > allocate from the reserved region.
> >
> > So the region should not be reserved. Reserved generally means the OS
> > shouldn't use the region (though maybe a specific driver/device can). It
> > should just be a CMA area I think.
>
> No. The whole reason for this is that we want an isolated piece of memory
> for PCIe so that PCIe transfers cannot corrupt memory used by other parts
> of the system. Normally the IOMMU provides the isolation. On this platform
> there is no IOMMU for the PCIe controller.
>
> System memory isolation as setup by the firmware already restricts the
> PCIe controller to only be able to use this region. And we absolutely do
> not want any other part of the system, be it kernel, DMA buffers, or
> userspace, to use it.
>
> And also, if it is not reserved, the kernel is free to put "other" reserved
> regions, such as the default CMA region or the software IO TLB region in
> this piece of memory.
>
> So I believe using memory-region is the way to go. The memory needs to be
> reserved, and assigned to just the PCIe controller.
Ping? We need this merged for the coming cycle.
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Add TCP LRO support
From: Jakub Kicinski @ 2026-06-09 2:15 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Alexander Lobakin, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal
In-Reply-To: <20260606-airoha-eth-lro-v1-1-0ebceb0eafc3@kernel.org>
On Sat, 06 Jun 2026 16:45:28 +0200 Lorenzo Bianconi wrote:
> Add hardware TCP Large Receive Offload (LRO) support to the airoha_eth
> driver, leveraging the EN7581/AN7583 SoC's 8 dedicated LRO hardware queues
> mapped to RX queues 24–31. LRO hw offloading does not support
> Scatter-Gather (SG) so it is required to increase the page_pool allocation
> order to 2 for RX queues 24–31 (LRO queues).
NIPA says this doesn't apply
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: mediatek: mt6795: document the slew-rate property
From: Linus Walleij @ 2026-06-08 22:46 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Sean Wang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260601152707.29039-1-l.scorcia@gmail.com>
On Mon, Jun 1, 2026 at 5:27 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The driver for MT6795 pinctrl already supports the slew-rate property.
> Add its description to the documentation.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins 34-39
From: Linus Walleij @ 2026-06-08 21:56 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Fabien Parent, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260531162340.5326-1-l.scorcia@gmail.com>
On Sun, May 31, 2026 at 6:23 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The correct Schmitt trigger register offset for pins 34-39 is 0xA00. Value
> was verified with SoC data sheet.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Fixes: 82d70627e94a ("pinctrl: mediatek: Add MT8167 Pinctrl driver")
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins 34-39
From: Linus Walleij @ 2026-06-08 21:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Fabien Parent, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260531162237.5290-1-l.scorcia@gmail.com>
On Sun, May 31, 2026 at 6:23 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The correct Schmitt trigger register offset for pins 34-39 is 0xA00.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Fixes: 264667112ef0 ("pinctrl: mediatek: Add MT8516 Pinctrl driver")
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net-next] net: airoha: move get_sport() callback at the beginning of airoha_enable_gdm2_loopback()
From: Lorenzo Bianconi @ 2026-06-08 21:24 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Move the get_sport() callback invocation at the beginning of
airoha_enable_gdm2_loopback() routine in order to avoid leaving the
hardware in a partially configured state if get_sport() fails.
Previously, get_sport() was called after GDM2 forwarding, loopback,
channel, length, VIP and IFC registers had already been programmed.
A failure at that point would return an error leaving GDM2 with
loopback enabled but WAN port, PPE CPU port and flow control mappings
not configured.
Performing the get_sport() lookup before any register write guarantees
the routine either completes the full configuration sequence or exits
with no side effects on the hardware.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..cbc0f4079df0 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1905,6 +1905,10 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
u32 val, pse_port, chan;
int i, src_port;
+ src_port = eth->soc->ops.get_sport(port, dev->nbq);
+ if (src_port < 0)
+ return src_port;
+
airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
FE_PSE_PORT_DROP);
airoha_fe_clear(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
@@ -1934,10 +1938,6 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
- src_port = eth->soc->ops.get_sport(port, dev->nbq);
- if (src_port < 0)
- return src_port;
-
airoha_fe_rmw(eth, REG_FE_WAN_PORT,
WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
FIELD_PREP(WAN0_MASK, src_port));
---
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
change-id: 20260608-airoha_enable_gdm2_loopback-minor-change-fda3a3351a06
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH v3 3/3] ARM: dts: ti: Add specific compatibles for SCM conf nodes
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
writing-bindings.rst rules dictate that "syscon" must come with a
specific compatible identifying the register layout. Add specific
compatibles for these devices.
This also allows to solve a different problem: "syscon" is contradictory
to "simple-bus". A system controller with registers having their own
functions is not really a trivial MMIO simple bus. These two cannot be
used together, unless listed as an exception.
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v3:
1. s/ti,omap5-scm-conf/ti,omap5-sysc-padconf-global/ because it is more
appropriate (specific)
---
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/am437x-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm814x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm816x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap2430.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap3.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 6 +++---
9 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
index 89d16fcc773e..1e09d2b48925 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
@@ -308,7 +308,7 @@ am33xx_pinmux: pinmux@800 {
};
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,am3352-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi b/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi
index e08f356e71cb..30fcce33f4b7 100644
--- a/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am437x-l4.dtsi
@@ -301,7 +301,7 @@ am43xx_pinmux: pinmux@800 {
};
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,am4372-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/dm814x.dtsi b/arch/arm/boot/dts/ti/omap/dm814x.dtsi
index 27d1f35a31fd..9e02bfa5c3a2 100644
--- a/arch/arm/boot/dts/ti/omap/dm814x.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dm814x.dtsi
@@ -432,7 +432,7 @@ control: control@140000 {
ranges = <0 0x140000 0x20000>;
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,dm814-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/dm816x.dtsi b/arch/arm/boot/dts/ti/omap/dm816x.dtsi
index a1e0e904e0f0..ee0090f7aa64 100644
--- a/arch/arm/boot/dts/ti/omap/dm816x.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dm816x.dtsi
@@ -100,7 +100,7 @@ dm816x_pinmux: pinmux@800 {
/* Device Configuration Registers */
scm_conf: syscon@600 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,dm8168-scm-conf", "syscon", "simple-bus";
reg = <0x600 0x110>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index c8d325b0f57b..9df7648c4b79 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -64,7 +64,7 @@ scm: scm@0 {
ranges = <0 0 0x2000>;
scm_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,dra7-scm-conf", "syscon", "simple-bus";
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap2430.dtsi b/arch/arm/boot/dts/ti/omap/omap2430.dtsi
index 222613d2a4d1..01bd471f9223 100644
--- a/arch/arm/boot/dts/ti/omap/omap2430.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap2430.dtsi
@@ -50,7 +50,7 @@ omap2430_pmx: pinmux@30 {
};
scm_conf: scm_conf@270 {
- compatible = "syscon",
+ compatible = "ti,omap2-scm-conf", "syscon",
"simple-bus";
reg = <0x270 0x240>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap3.dtsi b/arch/arm/boot/dts/ti/omap/omap3.dtsi
index 959069e24730..447736d2e53c 100644
--- a/arch/arm/boot/dts/ti/omap/omap3.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3.dtsi
@@ -116,7 +116,7 @@ omap3_pmx_core: pinmux@30 {
};
scm_conf: scm_conf@270 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,omap3-scm-conf", "syscon", "simple-bus";
reg = <0x270 0x330>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 4c78a0b28fab..c1afc49f456c 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -681,7 +681,7 @@ omap4_pmx_core: pinmux@40 {
};
omap4_padconf_global: omap4_padconf_global@5a0 {
- compatible = "syscon",
+ compatible = "ti,omap4-sysc-padconf-global", "syscon",
"simple-bus";
reg = <0x5a0 0x170>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
index 915870eb5c99..72849e1c95b0 100644
--- a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
@@ -96,8 +96,7 @@ omap5_pmx_core: pinmux@40 {
};
omap5_padconf_global: omap5_padconf_global@5a0 {
- compatible = "syscon",
- "simple-bus";
+ compatible = "ti,omap5-sysc-padconf-global", "syscon", "simple-bus";
reg = <0x5a0 0xec>;
#address-cells = <1>;
#size-cells = <1>;
@@ -2311,7 +2310,8 @@ omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@da0 {
ranges = <0 0 0x60>;
scm_wkup_pad_conf: scm_conf@0 {
- compatible = "syscon", "simple-bus";
+ compatible = "ti,omap5-scm-wkup-conf",
+ "syscon", "simple-bus";
reg = <0x0 0x60>;
#address-cells = <1>;
#size-cells = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] dt-bindings: mfd: syscon: Drop custom select for older dtschema
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
Older dtschema <2024.02 required custom select to avoid applying this
binding to anything having "syscon" compatible. That's not the case
anymore and this additional select has two headaches:
1. Duplicates all the compatibles listed in the schema.
2. Is error-prone, because it requires contributor to add the compatible
in two places, otherwise the schema will be silently ignored.
The select list already misses mentioning compatibles:
mediatek,mt8365-infracfg-nao and renesas,r9a08g046-lvds-cmn (with the
latter being reverted for different reasons).
This requires bumping minimum dtschema requirement to v2024.04, which
feels old enough to be a safe requirement.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v3:
1. Bump dtschema requirement
Changes in v2:
1. New patch
---
Documentation/devicetree/bindings/Makefile | 2 +-
Documentation/devicetree/bindings/mfd/syscon.yaml | 116 ----------------------
2 files changed, 1 insertion(+), 117 deletions(-)
diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
index 7b668f7fd400..40c2094f47c2 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
DT_SCHEMA_LINT = $(shell which yamllint || \
echo "warning: python package 'yamllint' not installed, skipping" >&2)
-DT_SCHEMA_MIN_VERSION = 2023.9
+DT_SCHEMA_MIN_VERSION = 2024.4
PHONY += check_dtschema_version
check_dtschema_version:
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 9c81010d5a74..b70018bf1bcf 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -19,122 +19,6 @@ description: |
maintainers:
- Lee Jones <lee@kernel.org>
-# Need a select with all compatibles listed for compatibility with older
-# dtschema (<2024.02), so this will not be selected for other schemas having
-# syscon fallback.
-select:
- properties:
- compatible:
- contains:
- enum:
- - airoha,en7581-pbus-csr
- - al,alpine-sysfabric-service
- - allwinner,sun8i-a83t-system-controller
- - allwinner,sun8i-h3-system-controller
- - allwinner,sun8i-v3s-system-controller
- - allwinner,sun50i-a64-system-controller
- - altr,l3regs
- - altr,sdr-ctl
- - amd,pensando-elba-syscon
- - amlogic,meson-mx-assist
- - amlogic,meson-mx-bootrom
- - amlogic,meson8-analog-top
- - amlogic,meson8b-analog-top
- - amlogic,meson8-pmu
- - amlogic,meson8b-pmu
- - apm,merlin-poweroff-mailbox
- - apm,mustang-poweroff-mailbox
- - apm,xgene-csw
- - apm,xgene-efuse
- - apm,xgene-mcb
- - apm,xgene-rb
- - apm,xgene-scu
- - atmel,sama5d2-sfrbu
- - atmel,sama5d3-nfc-io
- - atmel,sama5d3-sfrbu
- - atmel,sama5d4-sfrbu
- - axis,artpec6-syscon
- - brcm,cru-clkset
- - brcm,sr-cdru
- - brcm,sr-mhb
- - cirrus,ep7209-syscon1
- - cirrus,ep7209-syscon2
- - cirrus,ep7209-syscon3
- - cnxt,cx92755-uc
- - econet,en751221-chip-scu
- - freecom,fsg-cs2-system-controller
- - fsl,imx93-aonmix-ns-syscfg
- - fsl,imx93-wakeupmix-syscfg
- - fsl,ls1088a-reset
- - fsl,vf610-anatop
- - fsl,vf610-mscm-cpucfg
- - hisilicon,dsa-subctrl
- - hisilicon,hi6220-sramctrl
- - hisilicon,hip04-ppe
- - hisilicon,pcie-sas-subctrl
- - hisilicon,peri-subctrl
- - hpe,gxp-sysreg
- - loongson,ls1b-syscon
- - loongson,ls1c-syscon
- - lsi,axxia-syscon
- - marvell,armada-3700-cpu-misc
- - marvell,armada-3700-nb-pm
- - marvell,armada-3700-avs
- - marvell,armada-3700-usb2-host-device-misc
- - marvell,armada-3700-usb2-host-misc
- - marvell,dove-global-config
- - mediatek,mt2701-pctl-a-syscfg
- - mediatek,mt2712-pctl-a-syscfg
- - mediatek,mt6397-pctl-pmic-syscfg
- - mediatek,mt7981-topmisc
- - mediatek,mt7988-topmisc
- - mediatek,mt8135-pctl-a-syscfg
- - mediatek,mt8135-pctl-b-syscfg
- - mediatek,mt8173-pctl-a-syscfg
- - mediatek,mt8365-syscfg
- - microchip,lan966x-cpu-syscon
- - microchip,mpfs-control-scb
- - microchip,mpfs-sysreg-scb
- - microchip,sam9x60-sfr
- - microchip,sama7d65-ddr3phy
- - microchip,sama7d65-sfrbu
- - microchip,sama7g5-ddr3phy
- - mscc,ocelot-cpu-syscon
- - mstar,msc313-pmsleep
- - nuvoton,ma35d1-sys
- - nuvoton,wpcm450-shm
- - nxp,s32g2-gpr
- - nxp,s32g3-gpr
- - qcom,apq8064-mmss-sfpb
- - qcom,apq8064-sps-sic
- - rockchip,px30-qos
- - rockchip,rk3036-qos
- - rockchip,rk3066-qos
- - rockchip,rk3128-qos
- - rockchip,rk3228-qos
- - rockchip,rk3288-qos
- - rockchip,rk3368-qos
- - rockchip,rk3399-qos
- - rockchip,rk3528-qos
- - rockchip,rk3562-qos
- - rockchip,rk3568-qos
- - rockchip,rk3576-qos
- - rockchip,rk3588-qos
- - rockchip,rv1126-qos
- - st,spear1340-misc
- - stericsson,nomadik-pmu
- - starfive,jh7100-sysmain
- - ti,am62-opp-efuse-table
- - ti,am62-usb-phy-ctrl
- - ti,am625-dss-oldi-io-ctrl
- - ti,am62p-cpsw-mac-efuse
- - ti,am654-dss-oldi-io-ctrl
- - ti,j784s4-acspcie-proxy-ctrl
- - ti,j784s4-pcie-ctrl
- - ti,keystone-pllctrl
- required:
- - compatible
-
properties:
compatible:
oneOf:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: mfd: syscon: Disallow simple-bus with syscon
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-0-4eba9ec1212a@oss.qualcomm.com>
"syscon" is a system controller with registers having their own
functions, thus not really a trivial MMIO simple bus. "simple-bus" on
the other hand is just a bus on which multiple devices sit and the
"simple" means no functions are allowed here.
Combination of both "syscon" and "simple-bus" is abuse of DT for easier
instantiating of Linux device drivers so add a schema to disallow that.
Unfortunately there are a few old cases of that patterns, so add
exceptions:
1. "cznic,turris1x-cpld" and "img,pistachio-cr-periph" are already used
in upstream DTS.
2. TI has several DTSI with a child of SCM device (e.g. "ti,am3-scm")
using "syscon" and "simple-bus" but without a dedicated compatible
documented anywhere. Add new compatibles for such cases.
Additionally, add comments around code enforcing two or three
compatibles: it is similar safeguard detecting incorrect bindings.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v3:
1. s/ti,omap5-scm-conf/ti,omap5-sysc-padconf-global/ because it is more
appropriate (specific)
2. Add comments, why simple-mfd+syscon has dedicated if:then:
Changes in v2:
1. Complete patch. I accidentally sent only part of it, built on top of
internal WIP which I forgot to squash.
I received Ack from Rob, but change is significant, so please kindly
re-review.
---
.../devicetree/bindings/mfd/syscon-common.yaml | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon-common.yaml b/Documentation/devicetree/bindings/mfd/syscon-common.yaml
index 14a08e7bc8bd..2d5eef5add54 100644
--- a/Documentation/devicetree/bindings/mfd/syscon-common.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon-common.yaml
@@ -32,6 +32,7 @@ properties:
compatible:
contains:
const: syscon
+ # Always require a specific compatible for syscon
minItems: 2
maxItems: 5 # Should be enough
@@ -52,11 +53,44 @@ allOf:
contains:
const: simple-mfd
then:
+ # Always require a specific compatible for syscon with simple-mfd
properties:
compatible:
minItems: 3
maxItems: 5
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: simple-bus
+ then:
+ # simple-bus conflicts with syscon - if a device is a system controller
+ # with miscellaneous registers, then it has at least one dedicated
+ # function thus it is not a simple bus. Allow existing exceptions.
+ if:
+ properties:
+ compatible:
+ not:
+ contains:
+ # This list CANNOT grow
+ enum:
+ - cznic,turris1x-cpld
+ - img,pistachio-cr-periph
+ - ti,am3352-scm-conf
+ - ti,am4372-scm-conf
+ - ti,dm814-scm-conf
+ - ti,dm8168-scm-conf
+ - ti,dra7-scm-conf
+ - ti,omap2-scm-conf
+ - ti,omap3-scm-conf
+ - ti,omap4-sysc-padconf-global
+ - ti,omap5-scm-wkup-conf
+ - ti,omap5-sysc-padconf-global
+ then:
+ required:
+ - incorrect-usage-of-simple-bus-and-syscon
+
additionalProperties: true
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/3] dt-bindings: mfd: syscon: Tighten checks
From: Krzysztof Kozlowski @ 2026-06-08 20:44 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, linux-rockchip, linux-omap,
Krzysztof Kozlowski
Changes in v3:
- Drop patch #2:
dt-bindings: mfd: syscon: Drop unneeded case for syscon + simple-mfd
- Bump dtschema requirement
- Link to v2: https://patch.msgid.link/20260608-n-dt-bindings-simple-bus-syscon-v2-0-0203e6c249dc@oss.qualcomm.com
Changes in v2:
1. New patches #2 and #3
1. Add missing part of patch #1, thus not adding Rob's Ack.
https://lore.kernel.org/all/20260531110404.12768-3-krzysztof.kozlowski@oss.qualcomm.com/
I tested dt_binding_check and dtbs_check for arm, arm64 and riscv and I
think I did not introduce new dtbs_check warnings. Old code anyway has
multiple abuses of syscon, thus tricky to judge for arm at least.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (3):
dt-bindings: mfd: syscon: Disallow simple-bus with syscon
dt-bindings: mfd: syscon: Drop custom select for older dtschema
ARM: dts: ti: Add specific compatibles for SCM conf nodes
Documentation/devicetree/bindings/Makefile | 2 +-
.../devicetree/bindings/mfd/syscon-common.yaml | 34 ++++++
Documentation/devicetree/bindings/mfd/syscon.yaml | 116 ---------------------
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/am437x-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm814x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dm816x.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap2430.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap3.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 2 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 6 +-
12 files changed, 46 insertions(+), 128 deletions(-)
---
base-commit: 78f5e68a8d0a1123dd1b007688ccf0e6876a5c15
change-id: 20260608-n-dt-bindings-simple-bus-syscon-e39df408a02d
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v8 6/6] pinctrl: mediatek: Add MT6735 pinctrl driver
From: Linus Walleij @ 2026-06-08 19:41 UTC (permalink / raw)
To: Yassine Oudjana
Cc: Sean Wang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Andy Teng,
Yassine Oudjana, linux-mediatek, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260530145800.1029920-7-y.oudjana@protonmail.com>
Hi Yassine,
thanks for your patch!
On Sat, May 30, 2026 at 4:58 PM Yassine Oudjana
<yassine.oudjana@gmail.com> wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
>
> Add a driver for the MediaTek MT6735 SoC pin controller. This driver
> also supports the pin controller on MT6735M, which lacks 6 physical
> pins (198-203) used for MSDC2 on MT6735.
>
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Sashiko has good comments on this driver, look into them!
> +config PINCTRL_MT6735
> + bool "MediaTek MT6735(M) pin control"
> + depends on OF
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK_PARIS
There are in-flight patches to make MTK drivers tristate for
the Android GKI. Do you want to use tristate for this driver too?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: mediatek: Enable MT8189 as loadable module
From: Linus Walleij @ 2026-06-08 19:29 UTC (permalink / raw)
To: Justin Yeh
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260529100308.51271-1-justin.yeh@mediatek.com>
On Fri, May 29, 2026 at 12:04 PM Justin Yeh <justin.yeh@mediatek.com> wrote:
> This series enables PINCTRL_MT8189 to be built as a loadable kernel
> module, which is required for GKI (Generic Kernel Image) + vendor_dlkm
> deployments where vendor-specific drivers must be kept separate from
> the GKI vmlinux.
Maybe tell us that this is for Android?
> Patch 1 restores the tristate option that was recently changed to bool,
No the driver was merged with tristate.
See
commit a3fe1324c3c5c292ec79bd756497c1c44ff247d2 (tag: pinctrl-v6.17-1)
"pinctrl: mediatek: Add pinctrl driver for mt8189"
> preventing module builds. Patch 2 adds the missing MODULE_LICENSE macro
> that's required when building as a module.
So that should be squashed into one patch or it will not bisect.
> Together these changes allow MT8189 pinctrl to be properly packaged as
> a vendor kernel module while maintaining the existing built-in option.
So why do we change this only for MT8189 and not for all
Mediatek pinctrl drivers?
I would just add this tristate option and license to all of them while
you're at it or I will get like 20 identical patches and it's a waste
of time for me.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net-next v3] net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
From: Lorenzo Bianconi @ 2026-06-08 18:03 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
GDM3 and GDM4 ports require GDM2 loopback to be enabled for hardware
QoS offload to function. Without it, HTB and ETS offload on these ports
do not work.
Previously, GDM3/GDM4 ports were automatically configured as WAN with
GDM2 loopback enabled during ndo_init(). Move this setup to be performed
on demand when QoS offload is created or destroyed. GDM3 and GDM4 now
default to LAN mode at init time, while GDM2 is always WAN.
Hook airoha_enable_qos_for_gdm34() into TC_HTB_CREATE so that requesting
HTB offload on a GDM3/GDM4 LAN port switches it to WAN mode and enables
GDM2 loopback, with proper rollback on failure. Hook the counterpart
airoha_disable_qos_for_gdm34() into TC_HTB_DESTROY to restore LAN mode
when the offloaded qdisc is torn down.
Add airoha_disable_gdm2_loopback() as the teardown counterpart of the
existing airoha_enable_gdm2_loopback().
Move QDMA TX/RX DMA enable from airoha_dev_open() to airoha_probe() and
the corresponding disable from airoha_dev_stop() to airoha_qdma_cleanup(),
removing the per-QDMA atomic refcount that was needed for the open/close
path. DMA is now always active from probe to remove.
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v3:
- Do not introduce ethtool private flags support to configure LAN/WAN
for GDM3/4 and rely on tc qdisc offload for it instead.
- Set GDM3/4 ports as LAN by default.
- Move QDMA TX/RX DMA enable from airoha_dev_open() to airoha_probe()
and the corresponding disable from airoha_dev_stop() to airoha_qdma_cleanup().
- Link to v2: https://lore.kernel.org/r/20260607-airoha-ethtool-priv_flags-v2-1-742c7aa1e182@kernel.org
Changes in v2:
- Rework airoha_dev_set_wan_flag routine
- Enable GDM_STRIP_CRC_MASK in airoha_disable_gdm2_loopback()
- Do not always reset REG_SRC_PORT_FC_MAP6 in
airoha_disable_gdm2_loopback() but use the same condition used in
airoha_enable_gdm2_loopback().
- Link to v1: https://lore.kernel.org/r/20260606-airoha-ethtool-priv_flags-v1-1-401b2c9fe9f1@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 177 ++++++++++++++++++++++--------
drivers/net/ethernet/airoha/airoha_eth.h | 2 -
drivers/net/ethernet/airoha/airoha_regs.h | 1 +
3 files changed, 131 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5a8e84fa9918..9bfb1e5b2b54 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1516,6 +1516,10 @@ static void airoha_qdma_cleanup(struct airoha_qdma *qdma)
{
int i;
+ airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
+ GLOBAL_CFG_TX_DMA_EN_MASK |
+ GLOBAL_CFG_RX_DMA_EN_MASK);
+
for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
if (!qdma->q_rx[i].ndesc)
continue;
@@ -1806,11 +1810,6 @@ static int airoha_dev_open(struct net_device *netdev)
}
port->users++;
- airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
- GLOBAL_CFG_TX_DMA_EN_MASK |
- GLOBAL_CFG_RX_DMA_EN_MASK);
- atomic_inc(&qdma->users);
-
if (!airoha_is_lan_gdm_dev(dev) &&
airoha_ppe_is_enabled(qdma->eth, 1))
pse_port = FE_PSE_PORT_PPE2;
@@ -1863,19 +1862,6 @@ static int airoha_dev_stop(struct net_device *netdev)
REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
- if (atomic_dec_and_test(&qdma->users)) {
- airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
- GLOBAL_CFG_TX_DMA_EN_MASK |
- GLOBAL_CFG_RX_DMA_EN_MASK);
-
- for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
- if (!qdma->q_tx[i].ndesc)
- continue;
-
- airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
- }
- }
-
return 0;
}
@@ -1960,6 +1946,49 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
return 0;
}
+static int airoha_disable_gdm2_loopback(struct airoha_gdm_dev *dev)
+{
+ struct airoha_gdm_port *port = dev->port;
+ struct airoha_eth *eth = dev->eth;
+ int i, src_port;
+ u32 pse_port;
+
+ src_port = eth->soc->ops.get_sport(dev->port, dev->nbq);
+ if (src_port < 0)
+ return src_port;
+
+ airoha_fe_clear(eth,
+ REG_SP_DFT_CPORT(src_port >> fls(SP_CPORT_DFT_MASK)),
+ SP_CPORT_MASK(src_port & SP_CPORT_DFT_MASK));
+
+ airoha_fe_set(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ GDM_STRIP_CRC_MASK);
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ FE_PSE_PORT_DROP);
+ airoha_fe_clear(eth, REG_GDM_LPBK_CFG(AIROHA_GDM2_IDX),
+ LPBK_CHAN_MASK | LPBK_MODE_MASK | LPBK_EN_MASK);
+ pse_port = airoha_ppe_is_enabled(eth, 1) ? FE_PSE_PORT_PPE2
+ : FE_PSE_PORT_PPE1;
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ pse_port);
+
+ airoha_fe_rmw(eth, REG_FE_WAN_PORT, WAN0_MASK,
+ FIELD_PREP(WAN0_MASK, AIROHA_GDM2_IDX));
+
+ for (i = 0; i < eth->soc->num_ppe; i++)
+ airoha_fe_clear(eth, REG_PPE_DFT_CPORT(i, AIROHA_GDM2_IDX),
+ DFT_CPORT_MASK(AIROHA_GDM2_IDX));
+
+ /* Enable VIP and IFC for GDM2 */
+ airoha_fe_set(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
+ airoha_fe_set(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
+
+ if (port->id == AIROHA_GDM4_IDX && airoha_is_7581(eth))
+ airoha_fe_wr(eth, REG_SRC_PORT_FC_MAP6, FC_MAP6_DEF_VALUE);
+
+ return 0;
+}
+
static struct airoha_gdm_dev *
airoha_get_wan_gdm_dev(struct airoha_eth *eth)
{
@@ -2002,40 +2031,14 @@ static int airoha_dev_init(struct net_device *netdev)
struct airoha_gdm_dev *dev = netdev_priv(netdev);
struct airoha_gdm_port *port = dev->port;
- switch (port->id) {
- case AIROHA_GDM3_IDX:
- case AIROHA_GDM4_IDX: {
- struct airoha_eth *eth = dev->eth;
-
- /* GDM2 supports a single net_device */
- if (eth->ports[1] && eth->ports[1]->devs[0])
- break;
-
- if (airoha_get_wan_gdm_dev(eth))
- break;
-
- fallthrough;
- }
- case AIROHA_GDM2_IDX:
- /* GDM2 is always used as wan */
+ if (port->id == AIROHA_GDM2_IDX) {
+ /* GDM2 is always used as WAN */
dev->flags |= AIROHA_PRIV_F_WAN;
- break;
- default:
- break;
}
airoha_dev_set_qdma(dev);
airoha_set_macaddr(dev, netdev->dev_addr);
- if (!airoha_is_lan_gdm_dev(dev) &&
- (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
- int err;
-
- err = airoha_enable_gdm2_loopback(dev);
- if (err)
- return err;
- }
-
return 0;
}
@@ -3008,6 +3011,79 @@ static int airoha_tc_htb_delete_leaf_queue(struct net_device *netdev,
return 0;
}
+static int airoha_enable_qos_for_gdm34(struct net_device *netdev)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
+ u32 pse_port;
+ int err;
+
+ if (port->id != AIROHA_GDM3_IDX &&
+ port->id != AIROHA_GDM4_IDX) {
+ /* HW QoS is always supported by GDM1 and GDM2 */
+ return 0;
+ }
+
+ if (!airoha_is_lan_gdm_dev(dev)) /* Already enabled */
+ return 0;
+
+ /* Verify the WAN device is not already configured */
+ if (airoha_get_wan_gdm_dev(dev->eth))
+ return -EBUSY;
+
+ dev->flags |= AIROHA_PRIV_F_WAN;
+ airoha_dev_set_qdma(dev);
+ err = airoha_enable_gdm2_loopback(dev);
+ if (err)
+ goto error_disable_wan;
+
+ err = airoha_set_macaddr(dev, netdev->dev_addr);
+ if (err)
+ goto error_disable_loopback;
+
+ pse_port = airoha_ppe_is_enabled(dev->eth, 1) ? FE_PSE_PORT_PPE2
+ : FE_PSE_PORT_PPE1;
+ airoha_set_gdm_port_fwd_cfg(dev->eth, REG_GDM_FWD_CFG(port->id),
+ pse_port);
+
+ return 0;
+
+error_disable_loopback:
+ /* Restore previous LAN configuration */
+ airoha_disable_gdm2_loopback(dev);
+error_disable_wan:
+ dev->flags &= ~AIROHA_PRIV_F_WAN;
+ airoha_dev_set_qdma(dev);
+
+ return err;
+}
+
+static void airoha_disable_qos_for_gdm34(struct net_device *netdev)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
+ int err;
+
+ if (port->id != AIROHA_GDM3_IDX &&
+ port->id != AIROHA_GDM4_IDX) {
+ return;
+ }
+
+ if (airoha_is_lan_gdm_dev(dev)) /* Already disabled */
+ return;
+
+ err = airoha_disable_gdm2_loopback(dev);
+ if (err)
+ netdev_warn(netdev,
+ "failed disabling GDM2 loopback: %d\n", err);
+
+ dev->flags &= ~AIROHA_PRIV_F_WAN;
+ airoha_dev_set_qdma(dev);
+ airoha_set_macaddr(dev, netdev->dev_addr);
+ airoha_set_gdm_port_fwd_cfg(dev->eth, REG_GDM_FWD_CFG(port->id),
+ FE_PSE_PORT_PPE1);
+}
+
static int airoha_tc_htb_destroy(struct net_device *netdev)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
@@ -3016,6 +3092,8 @@ static int airoha_tc_htb_destroy(struct net_device *netdev)
for_each_set_bit(q, dev->qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS)
airoha_tc_remove_htb_queue(netdev, q);
+ airoha_disable_qos_for_gdm34(netdev);
+
return 0;
}
@@ -3040,7 +3118,7 @@ static int airoha_tc_setup_qdisc_htb(struct net_device *dev,
{
switch (opt->command) {
case TC_HTB_CREATE:
- break;
+ return airoha_enable_qos_for_gdm34(dev);
case TC_HTB_DESTROY:
return airoha_tc_htb_destroy(dev);
case TC_HTB_NODE_MODIFY:
@@ -3414,6 +3492,11 @@ static int airoha_probe(struct platform_device *pdev)
if (err)
goto error_napi_stop;
+ for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
+ airoha_qdma_set(ð->qdma[i], REG_QDMA_GLOBAL_CFG,
+ GLOBAL_CFG_TX_DMA_EN_MASK |
+ GLOBAL_CFG_RX_DMA_EN_MASK);
+
return 0;
error_napi_stop:
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 8f42973f9cf5..cd0706a0c07f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -526,8 +526,6 @@ struct airoha_qdma {
struct airoha_eth *eth;
void __iomem *regs;
- atomic_t users;
-
struct airoha_irq_bank irq_banks[AIROHA_MAX_NUM_IRQ_BANKS];
struct airoha_tx_irq_queue q_tx_irq[AIROHA_NUM_TX_IRQ];
diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
index 436f3c8779c1..4e17dfbcf2b8 100644
--- a/drivers/net/ethernet/airoha/airoha_regs.h
+++ b/drivers/net/ethernet/airoha/airoha_regs.h
@@ -376,6 +376,7 @@
#define REG_SRC_PORT_FC_MAP6 0x2298
#define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
+#define FC_MAP6_DEF_VALUE 0x1b1a1918
#define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
---
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
change-id: 20260606-airoha-ethtool-priv_flags-b6aa70caa780
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH 16/18] pinctrl: airoha: an7583: remove an7583 prefix from variable names
From: Bartosz Golaszewski @ 2026-06-08 16:17 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-17-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:52 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> We have only an7583 specific code in the pinctrl-an7583 kernel module,
> so 'an75831_' prefix is not necessary anymore. Remove it.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 17/18] pinctrl: airoha: prepare for en7523 adding
From: Bartosz Golaszewski @ 2026-06-08 16:15 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-18-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:53 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> en7523 a bit differs from an7581/an7583. It has different register
> offsets and slightly different bitfield masks.
>
> Let's adapt common header and existing drivers for the future addition
> of en7523.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Looks good to me.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 06/18] pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
From: Bartosz Golaszewski @ 2026-06-08 16:13 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-7-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:42 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> phy4_led1 pin function maps led incorrectly. It uses the same map as
> phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 49/78] drm/mediatek: dp: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-49-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 50/78] drm/mediatek: dpi: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-50-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 51/78] drm/mediatek: dsi: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-51-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 52/78] drm/mediatek: hdmi: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-52-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 53/78] drm/mediatek: hdmi_v2: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:31 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-53-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 12/18] pinctrl: airoha: move driver to separate directory
From: Bartosz Golaszewski @ 2026-06-08 14:55 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-13-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:48 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Preparation step. Later the driver will be split on several SoC
> specific drivers and a common code. So it's better put them to
> a separate directory.
>
> No functional changes.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 05/18] pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
From: Bartosz Golaszewski @ 2026-06-08 14:52 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-6-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:41 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> phy4_led1 pin function maps led incorrectly. It uses the same map as
> phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
>
> Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 04/18] pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
From: Bartosz Golaszewski @ 2026-06-08 14:50 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-5-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:40 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
> a proper bit number in the configuration register.
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 03/18] pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
From: Bartosz Golaszewski @ 2026-06-08 14:50 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-4-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:39 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
> a proper bit number in the configuration register.
>
> Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
I think the term we typically use is "typo" but I won't die on that hill.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
page: next (older)
- 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