From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: sashiko-reviews@lists.linux.dev
Cc: Frank.Li@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
wsa+renesas@sang-engineering.com, imx@lists.linux.dev,
conor+dt@kernel.org
Subject: Re: [PATCH v6 1/1] arm64: dts: add tqma9596la-mba95xxca
Date: Wed, 01 Jul 2026 10:50:11 +0200 [thread overview]
Message-ID: <15795907.O9o76ZdvQC@steina-w> (raw)
In-Reply-To: <20260701084522.5A5301F000E9@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]
Hi,
here some comments about the findings.
Am Mittwoch, 1. Juli 2026, 10:45:22 CEST schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Hardware components (PWM fan and 10G SFP) remain permanently unpowered due to disabled regulators
> - [Low] Dead code: Unreferenced `pinctrl_ethphy0` node
> --
>
> commit f54617810555494fd6b435aa3ac070a14b264e01
> Author: Markus Niebel <Markus.Niebel@ew.tq-group.com>
>
> arm64: dts: add tqma9596la-mba95xxca
>
> This adds support for TQMa95xxLA modules, designed to be soldered
> on a carrier board. MBa95xxCA is a carrier reference board / starter kit
> design. Enable the external accessible PCIe controllers as host, add
> clocking and reset GPIO.
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> > new file mode 100644
> > index 0000000000000..e90f37bbdcd80
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
>
> [ ... ]
>
> > + reg_3v3a_10g: regulator-3v3a-10g {
> > + compatible = "regulator-fixed";
> > + regulator-name = "3V3A_10G";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + gpio = <&expander2 15 GPIO_ACTIVE_HIGH>;
> > + startup-delay-us = <2000>;
> > + enable-active-high;
> > + };
>
> [Severity: High]
> Is this regulator missing a consumer or the regulator-always-on property?
>
> Since the sfp_xfi node does not have a vcc-supply or vcc link to this
> regulator, and there is no always-on flag, won't the regulator framework
> automatically disable it, leaving the 10G SFP module unpowered?
XFI is not yet supported upstream, but the regulator is already prepared.
> [ ... ]
>
> > + fan_controller: fan-controller@2f {
> > + compatible = "microchip,emc2301", "microchip,emc2305";
> > + reg = <0x2f>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #pwm-cells = <3>;
> > + status = "okay";
> > +
> > + fan: fan@0 {
> > + reg = <0x0>;
> > + pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED 1>;
> > + #cooling-cells = <2>;
> > + fan-supply = <®_pwm_fan>;
> > + };
> > + };
>
> [Severity: High]
> Is reg_pwm_fan guaranteed to be enabled to power the cooling fan?
>
> While it is referenced via fan-supply in the fan@0 node here, the
> microchip,emc2305 hardware monitor driver does not parse fan-supply or manage
> regulators.
>
> Without regulator-always-on in the reg_pwm_fan node, won't this regulator
> remain permanently disabled, preventing the fan from operating?
Indeed the driver is missing regulator support for now.
> [ ... ]
>
> > + /* IRQ pin is AON GPIO, not usable */
> > + ethphy0: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + reset-gpios = <&expander3 0 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <500000>;
> > + reset-deassert-us = <50000>;
> > + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> > + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> > + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> > + ti,dp83867-rxctrl-strap-quirk;
> > + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> > + };
>
> [ ... ]
>
> > + pinctrl_ethphy0: ethphy0grp {
> > + fsl,pins = <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x1100>;
> > + };
>
> [Severity: Low]
> Is this pinctrl group missing a reference?
>
> It defines pin configuration for the ethphy0 IRQ pin, but doesn't seem to be
> referenced by the ethphy0 node (e.g., via pinctrl-0) or any other node.
This pad is connected to gpio1 which is under control of the system manager,
so Cortex-A55 (Linux) has no access to it.
Best regards
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-07-01 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 8:26 [PATCH v6 1/1] arm64: dts: add tqma9596la-mba95xxca Alexander Stein
2026-07-01 8:45 ` sashiko-bot
2026-07-01 8:50 ` Alexander Stein [this message]
2026-07-01 15:02 ` Frank Li
2026-07-01 15:37 ` Alexander Stein
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=15795907.O9o76ZdvQC@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox