linux-kernel - Re: [PATCH v2] dt-bindings: phy: ti,tcan104x-can: Document TI TCAN1046

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdXW2iFQO3vTzMg_ydqZ5YC1EPqyNzkpLRfTAkLhmC+K5g@mail.gmail.com>
Date: Wed, 17 Dec 2025 09:15:07 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Conor Dooley <conor@...nel.org>, Prabhakar <prabhakar.csengg@...il.com>, 
	Vincent Mailhol <mailhol@...nel.org>, Vinod Koul <vkoul@...nel.org>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Aswath Govindraju <a-govindraju@...com>, Frank Li <Frank.li@....com>, linux-can@...r.kernel.org, 
	linux-phy@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, 
	Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2] dt-bindings: phy: ti,tcan104x-can: Document TI TCAN1046

On Fri, 12 Dec 2025 at 12:22, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> On 10.12.2025 18:21:34, Conor Dooley wrote:
> > On Wed, Dec 10, 2025 at 08:52:58AM +0100, Marc Kleine-Budde wrote:
> > > On 09.12.2025 16:21:19, Prabhakar wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > >
> > > > Document the TI TCAN1046 automotive CAN transceiver. The TCAN1046 is a
> > > > dual high-speed CAN transceiver with sleep-mode support and no EN pin,
> > > > mirroring the behaviour of the NXP TJA1048, which also provides dual
> > > > channels and STB1/2 sleep-control lines.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > > ---
> > > > TCAN 1046, https://www.ti.com/lit/ds/symlink/tcan1046v-q1.pdf?ts=1765297159307&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTCAN1046V-Q1
> > > > NXP TJA1048, https://www.nxp.com/docs/en/data-sheet/TJA1048.pdf
> > >
> > > The polarity of the standby line of the chips is different.
> > >
> > > You must set the correct active high/low property for the GPIO, as the
> > > driver uses logical levels.
> > >
> > > Reviewed-by: Marc Kleine-Budde <mkl@...gutronix.de>
> >
> > What you're saying seems to contradict the tag you've given, is a
> > fallback really suitable if the standby polarity is not the same?
>
> The driver uses _logical_ levels to switch the GPIOs. For example to
> power on the PHY, it disables the standby GPIO by setting the value to
> "0".
>
> | static int can_transceiver_phy_power_on(struct phy *phy)
> | {
> [...]
> |         gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 0);
> [...]
> | }
>
> You have to use GPIO_ACTIVE_HIGH/GPIO_ACTIVE_LOW in the DT to configure
> the actual level of the GPIO.
>
> If you connect the PHY's standby input directly to the SoC's GPIO....
>
> | TJA1048: HIGH = Normal mode, LOW = Standby mode
> | TCAN1046: High = Standby mode, Low = Normal Mode
>
> ...for the TJA1048 you would use GPIO_ACTIVE_LOW, while for the
> TCAN1046 you would use GPIO_ACTIVE_HIGH.

Exactly.  For most of these CAN transceivers, there are typically two
almost identical parts (usually differing in the last digit of the part
number), one with active-high standby, another with active-low standby.
These differences can be handled perfectly fine using the GPIO_ACTIVE_*
lags.

Note that there can be other differences: the RZ/V2H board Prabhakar
works on actually has TCAN1046V.  The "V" variant differs from TCAN1046
(and TJA1048) in configuration of the two power supply pins:
  - TCAN1046 has independent supplies for the two channels,
  - TCAN1046V has separate logic and I/O supplies for the combined
    channels.
Since this difference can be handled through *-supply properties
(when the need arises, and the driver gains regulator support),
I don't think separate compatible values are needed for "V" variants.

BTW, how do I know? Because I had started working on adding support
for TCAN1046V myself, but Prabhakar beat me to sending out patches ;-)

Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds