From: Conor Dooley <conor@kernel.org>
To: Ilya Orazov <ilordash02@gmail.com>
Cc: geert+renesas@glider.be, mkl@pengutronix.de,
mailhol.vincent@wanadoo.fr, vkoul@kernel.org, kishon@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, a-govindraju@ti.com,
linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561
Date: Tue, 23 Jul 2024 21:14:09 +0100 [thread overview]
Message-ID: <20240723-municipal-snowy-136b08b6db90@spud> (raw)
In-Reply-To: <CAGCz5H=Gncw+Tr0XaQQhhGWQER5Rs1BcxbkPaJwx9jJ-8j7LGQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5420 bytes --]
On Tue, Jul 23, 2024 at 10:55:17PM +0300, Ilya Orazov wrote:
> On Tue, 23 Jul 2024 at 21:50, Conor Dooley <conor@kernel.org> wrote:
> >
> > On Tue, Jul 23, 2024 at 08:20:04PM +0300, IlorDash wrote:
> > > On Fri, 19 Jul 2024 at 18:07, Conor Dooley <conor@kernel.org> wrote:
> > > >
> > > > On Fri, Jul 19, 2024 at 12:03:21AM +0300, Ilya Orazov wrote:
> > > > > Microchip ATA6561 is High-Speed CAN Transceiver with Standby Mode.
> > > > > It is pin-compatible with TI TCAN1042.
> > > > >
> > > > > Signed-off-by: Ilya Orazov <ilordash02@gmail.com>
> > > > > ---
> > > > > Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > index 79dad3e89aa6..03de361849d2 100644
> > > > > --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > > @@ -18,6 +18,7 @@ properties:
> > > > > - nxp,tjr1443
> > > > > - ti,tcan1042
> > > > > - ti,tcan1043
> > > > > + - microchip,ata6561
> > > >
> > > > Given that your driver patch has
> > > > | diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> > > > | index ee4ce4249698..dbcd99213ba1 100644
> > > > | --- a/drivers/phy/phy-can-transceiver.c
> > > > | +++ b/drivers/phy/phy-can-transceiver.c
> > > > | @@ -89,6 +89,10 @@ static const struct of_device_id can_transceiver_phy_ids[] = {
> > > > | .compatible = "nxp,tjr1443",
> > > > | .data = &tcan1043_drvdata
> > > > | },
> > > > | + {
> > > > | + .compatible = "microchip,ata6561",
> > > > | + .data = &tcan1042_drvdata
> > > > | + },
> > > > | { }
> > > > | };
> > > >
> > > > the driver patch is actually not needed at all, and you just need to
> > > > allow ti,tcan1042 as fallback compatible in the binding, so something
> > > > like:
> > > >
> > > > compatible:
> > > > oneOf:
> > > > - enum:
> > > > - nxp,tjr1443
> > > > - ti,tcan1042
> > > > - ti,tcan1043
> > > > - items:
> > > > - const: microchip,ata6561
> > > > - const: ti,tcan1042
> > > >
> > > > '#phy-cells':
> > > > const: 0
> > >
> > > I tested the build with fallback compatible:
> > >
> > > compatible:
> > > oneOf:
> > > - items:
> > > - enum:
> > > - microchip,ata6561
> > > - const: ti,tcan1042
> > > - items:
> > > - enum:
> > > - nxp,tjr1443
> > > - const: ti,tcan1043
> > >
> > > and modified compatible property in DTS:
> > >
> > > compatible = "microchip,ata6561", "ti,tcan1042";
> > >
> > > Build succeeded, phy-can-transceiver driver was used. So I would like
> > > to add a fallback compatible for both "microchip,ata6561" and
> > > "nxp,tjr1443" in this binding and modify other DTS files with
> > > compatible = "nxp,tjr1443". What do you think?
> >
> > This is wrong on two counts. Firstly, were what you have correct, you
> > should
> > squash the two:
> > - items:
> > - enum:
> > - nxp,tjr1443
> > - microchip,ata6561
> > - const: ti,tcan1042
> >
> > However, that does not allow the TI compatibles in isolation, so you
> > still need to allow that for the actual TI devices, so you need:
> >
> > oneOf:
> > - items:
> > - enum:
> > - microchip,ata6561
> > - nxp,tjr1443
> > - ti,tcan1043
> > - const: ti,tcan1042
> > - const: ti,tcan1042
> >
> > There's probably some devicetrees that would need to be fixed up. I'm
> > just not convinced that this is worth retrofitting however.
>
> But nxp,tjr1443 is pin compatible with ti,tcan1043, so it should
> fallback only to ti,tcan1043 and not ti,tcan1042. That's why I decided
> to split them into different enums.
Ah, sorry I missed that. I misread the match data. Then you need:
compatible:
oneOf:
- items:
- enum:
- microchip,ata6561
- const: ti,tcan1042
- items:
- enum:
- nxp,tjr1443
- const: ti,tcan1043
- enum:
const: ti,tcan1042
const: ti,tcan1043
because the TI devices exist and we still need to be able to
differentiate the TI and NXP devices. If you have
compatible = "nxp,tjr1443", "ti,tcan1042";
that means the device is an nxp,tjr1443. If you have
compatible = "ti,tcan1042";
then that's a tcan1042.
> I made my patch according to a similar one that adds support for
> nxp,tjr1443. You can find it's conversation on
> https://lore.kernel.org/all/6ee5e2ce00019bd3f77d6a702b38bab1a45f3bb0.1674037830.git.geert+renesas@glider.be/t/#u.
> I thought we want to hold all PHY chip names in one compatible enum
> and each in its own of_device_id struct in driver and extend them
> where appropriate.
Nah, fallbacks are preferred when the programming model is either
identical or a "compatible superset" of an existing device. New
of_device_id structs should only be used where we need to account for
differences in the programming model.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-07-23 20:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 21:03 [PATCH 0/2] phy: Add support for Microchip ATA6561 CAN Transceiver Ilya Orazov
2024-07-18 21:03 ` [PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561 Ilya Orazov
2024-07-19 15:07 ` Conor Dooley
2024-07-23 17:20 ` IlorDash
2024-07-23 18:50 ` Conor Dooley
2024-07-23 19:55 ` Ilya Orazov
2024-07-23 20:14 ` Conor Dooley [this message]
2024-07-28 8:52 ` Ilya Orazov
2024-07-29 8:51 ` Geert Uytterhoeven
2024-08-01 15:12 ` Conor Dooley
2024-08-03 12:31 ` Ilya Orazov
2024-08-05 10:11 ` Conor Dooley
2024-08-07 18:02 ` [PATCH v2 0/1] phy: Add support for Microchip ATA6561 CAN Transceiver Ilya Orazov
2024-08-07 18:02 ` [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561 Ilya Orazov
2024-08-07 18:09 ` [PATCH v2 0/1] phy: Add support for Microchip ATA6561 CAN Transceiver Ilya Orazov
2024-08-07 18:09 ` [PATCH v2 1/1] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561 Ilya Orazov
2024-08-07 19:12 ` Rob Herring (Arm)
2024-08-08 15:48 ` Conor Dooley
2024-08-08 16:40 ` Krzysztof Kozlowski
2024-08-08 19:17 ` [PATCH v3 " Ilya Orazov
2024-08-09 14:57 ` Conor Dooley
2024-08-13 17:14 ` Ilya Orazov
2024-08-14 9:03 ` Krzysztof Kozlowski
2024-08-14 16:56 ` Ilya Orazov
2024-07-18 21:03 ` [PATCH 2/2] phy: phy-can-transceiver: Add support for " Ilya Orazov
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=20240723-municipal-snowy-136b08b6db90@spud \
--to=conor@kernel.org \
--cc=a-govindraju@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=ilordash02@gmail.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mkl@pengutronix.de \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/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