From: sashiko-bot@kernel.org
To: muhammad.nazim.amirul.nazle.asmade@altera.com
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH net-next 1/3] dt-bindings: net: snps,dwmac: Add snps,pagepool-tx-buf-quirk
Date: Tue, 04 Aug 2026 07:05:32 +0000 [thread overview]
Message-ID: <20260804070533.525341F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803070513.4657-2-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The property `snps,pagepool-tx-buf-quirk` encodes Linux-specific software implementation details ('page pool' and 'skb') and dictates software memory management policy, violating the core rule that Device Tree bindings must remain OS-agnostic and describe only hardware.
- [Low] The patch adds a new Device Tree flag (`snps,pagepool-tx-buf-quirk`) without any corresponding driver code in the series to parse or handle the property.
--
--- Patch [1]: [PATCH net-next 1/3] dt-bindings: net: snps,dwmac: Add snps,pagepool-tx-buf-quirk ---
commit 8d997cfca114fafc51861d3c95f903b66f45af7f
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
dt-bindings: net: snps,dwmac: Add snps,pagepool-tx-buf-quirk
This commit adds a new device tree flag to enable the use of page pool buffers
instead of streaming skb buffers for transmit. This aims to avoid high IOMMU
invalidate wait times on certain platforms.
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
[ ... ]
> @@ -545,6 +545,14 @@ properties:
> Enables the TSO feature otherwise it will be managed by MAC HW capability
> register.
>
> + snps,pagepool-tx-buf-quirk:
> + $ref: /schemas/types.yaml#/definitions/flag
[Severity: Low]
Is this flag used by any driver code in this series?
Adding a device tree binding without the corresponding driver implementation
makes it difficult to review how the property is actually consumed by the
kernel.
> + description:
> + Enable use of page pool buffers instead of streaming buffers for transmit.
> + This avoids IOMMU invalidate wait time on platforms where that cost is
> + high, with the trade-off of copying data from the skb into dma-mapped
> + page pool buffers.
[Severity: Medium]
Does this description violate the rule that device tree bindings should remain
OS-agnostic?
The terms page pool buffers and skb encode Linux-specific networking stack
implementation details. Should this property instead describe the underlying
hardware characteristics, such as the high IOMMU latency itself, rather than
dictating a software memory management policy?
> +
> mdio:
> $ref: mdio.yaml#
> unevaluatedProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803070513.4657-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=1
next prev parent reply other threads:[~2026-08-04 7:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 7:05 [PATCH net-next 0/3] net: stmmac: page pool Tx buffer quirk muhammad.nazim.amirul.nazle.asmade
2026-08-03 7:05 ` [PATCH net-next 1/3] dt-bindings: net: snps,dwmac: Add snps,pagepool-tx-buf-quirk muhammad.nazim.amirul.nazle.asmade
2026-08-04 7:05 ` sashiko-bot [this message]
2026-08-04 8:37 ` Krzysztof Kozlowski
2026-08-03 7:05 ` [PATCH net-next 2/3] net: stmmac: Use pagepool instead of streaming buffers for Tx muhammad.nazim.amirul.nazle.asmade
2026-08-03 18:39 ` Mina Almasry
2026-08-03 18:53 ` Mina Almasry
2026-08-04 7:05 ` sashiko-bot
2026-08-03 7:05 ` [PATCH 3/3] arm64: dts: agilex5: Enable pagepool Tx buffer quirk muhammad.nazim.amirul.nazle.asmade
2026-08-04 7:05 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260804070533.525341F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=muhammad.nazim.amirul.nazle.asmade@altera.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.