From: sashiko-bot@kernel.org
To: "Jens Glathe" <jens.glathe@oldschoolsolutions.biz>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/5] dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property
Date: Sat, 18 Jul 2026 17:11:45 +0000 [thread overview]
Message-ID: <20260718171145.9B62E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260718-ps883x-disable-usb4-v1-1-cec86d0b909e@oldschoolsolutions.biz>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The device tree binding violates OS-agnostic design principles by describing Linux-specific software behavior and internal driver states instead of hardware properties.
- [Low] The commit message contains a malformed and non-standard patch trailer 'Assisted-by: Grok(xAI):4.3'.
--
--- Patch [1]: [PATCH 1/5] dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property ---
commit 3e93d13f3a0b964fe4e6611bd03b162fa75d29a3
Author: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property
This commit documents a new optional boolean property parade,disable-usb4
for the parade,ps8830 device tree binding, which disables USB4 mode.
> Assisted-by: Grok(xAI):4.3
> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
[Severity: Low]
Does the Assisted-by trailer conform to the standard patch submission
guidelines?
This tag is non-standard, and it is missing the expected Name <email>
formatting. Could this cause issues with automated patch parsing tools?
> diff --git a/Documentation/devicetree/bindings/usb/parade,ps8830.yaml b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
> index eaeab1c01a594..44242907461eb 100644
> --- a/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
> +++ b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
[ ... ]
> @@ -66,6 +66,12 @@ properties:
> Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of
> handling altmode muxing and orientation switching.
>
> + parade,disable-usb4:
> + type: boolean
> + description:
> + When present, the retimer rejects USB4 mode (returns -EOPNOTSUPP).
> + This forces the Type-C stack to fall back to USB3 + DP Alternate Mode.
[Severity: Low]
Should the description for parade,disable-usb4 focus on the physical
hardware state or board constraints rather than Linux-specific driver
behavior?
Mentioning internal software details like returning -EOPNOTSUPP and the
Type-C stack seems to go against the principle that device tree bindings
should be OS-agnostic. Could this be rephrased to describe the hardware
limitations instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ps883x-disable-usb4-v1-0-cec86d0b909e@oldschoolsolutions.biz?part=1
next prev parent reply other threads:[~2026-07-18 17:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 17:06 [PATCH 0/5] usb: typec: ps883x: fixes for older Thunderbolt 4 / USB4 docks Jens Glathe via B4 Relay
2026-07-18 17:06 ` Jens Glathe
2026-07-18 17:06 ` [PATCH 1/5] dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property Jens Glathe via B4 Relay
2026-07-18 17:06 ` Jens Glathe
2026-07-18 17:11 ` sashiko-bot [this message]
2026-07-18 17:06 ` [PATCH 2/5] usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set Jens Glathe via B4 Relay
2026-07-18 17:06 ` Jens Glathe
2026-07-18 17:14 ` sashiko-bot
2026-07-19 1:14 ` Dr. David Alan Gilbert
2026-07-18 17:06 ` [PATCH 3/5] usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F Jens Glathe via B4 Relay
2026-07-18 17:06 ` Jens Glathe
2026-07-18 17:29 ` sashiko-bot
2026-07-18 17:06 ` [PATCH 4/5] usb: typec: mux: ps883x: add a delay after writing config regs Jens Glathe via B4 Relay
2026-07-18 17:06 ` Jens Glathe
2026-07-18 17:06 ` [PATCH 5/5] arm64: dts: qcom: x1: disable ps883x USB4 capability Jens Glathe via B4 Relay
2026-07-18 17:06 ` Jens Glathe
2026-07-18 17:22 ` sashiko-bot
2026-07-19 1:15 ` Dr. David Alan Gilbert
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=20260718171145.9B62E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jens.glathe@oldschoolsolutions.biz \
--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.