[net-next,v1,1/2] dt-bindings: net: dsa: Add KSZ8567 switch support

  From: Philippe Schenker <philippe.schenker@impulsing.ch>

This commit adds the dt-binding for KSZ8567, a robust 7-port
Ethernet switch. The KSZ8567 features two RGMII/MII/RMII interfaces,
each capable of gigabit speeds, complemented by five 10/100 Mbps
MAC/PHYs.

Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
---

 Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 1 +
 1 file changed, 1 insertion(+)
  

On Tue, Jan 23, 2024 at 02:50:13PM +0100, Philippe Schenker wrote:
> From: Philippe Schenker <philippe.schenker@impulsing.ch>
> 
> This commit adds the dt-binding for KSZ8567, a robust 7-port
> Ethernet switch. The KSZ8567 features two RGMII/MII/RMII interfaces,
> each capable of gigabit speeds, complemented by five 10/100 Mbps
> MAC/PHYs.
> 
> Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>

This device has all the same constraints as the other ones in this
binding, why is it not compatible with any of them? If it isn't, the
compatible should mention why it is not.

Cheers,
Conor.

> ---
> 
>  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> index c963dc09e8e1..52acc15ebcbf 100644
> --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> @@ -31,6 +31,7 @@ properties:
>        - microchip,ksz9893
>        - microchip,ksz9563
>        - microchip,ksz8563
> +      - microchip,ksz8567
>  
>    reset-gpios:
>      description:
> -- 
> 2.34.1
>
  

On Tue, 2024-01-23 at 16:06 +0000, Conor Dooley wrote:
> On Tue, Jan 23, 2024 at 02:50:13PM +0100, Philippe Schenker wrote:
> > From: Philippe Schenker <philippe.schenker@impulsing.ch>
> > 
> > This commit adds the dt-binding for KSZ8567, a robust 7-port
> > Ethernet switch. The KSZ8567 features two RGMII/MII/RMII
> > interfaces,
> > each capable of gigabit speeds, complemented by five 10/100 Mbps
> > MAC/PHYs.
> > 
> > Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
> 
> This device has all the same constraints as the other ones in this
> binding, why is it not compatible with any of them? If it isn't, the
> compatible should mention why it is not.

Hi Conor, Thanks for your message!

I need the compatible to make sure the correct ID of the switch is
being set in the driver as well as its features.

You mean I shall mention the reason in the commit-message, or where?

Philippe

> 
> Cheers,
> Conor.
> 
> > ---
> > 
> >  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > index c963dc09e8e1..52acc15ebcbf 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > @@ -31,6 +31,7 @@ properties:
> >        - microchip,ksz9893
> >        - microchip,ksz9563
> >        - microchip,ksz8563
> > +      - microchip,ksz8567
> >  
> >    reset-gpios:
> >      description:
> > -- 
> > 2.34.1
> >
  

On Tue, Jan 23, 2024 at 05:17:53PM +0100, Philippe Schenker wrote:
> 
> 
> On Tue, 2024-01-23 at 16:06 +0000, Conor Dooley wrote:
> > On Tue, Jan 23, 2024 at 02:50:13PM +0100, Philippe Schenker wrote:
> > > From: Philippe Schenker <philippe.schenker@impulsing.ch>
> > > 
> > > This commit adds the dt-binding for KSZ8567, a robust 7-port
> > > Ethernet switch. The KSZ8567 features two RGMII/MII/RMII
> > > interfaces,
> > > each capable of gigabit speeds, complemented by five 10/100 Mbps
> > > MAC/PHYs.
> > > 
> > > Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
> > 
> > This device has all the same constraints as the other ones in this
> > binding, why is it not compatible with any of them? If it isn't, the
> > compatible should mention why it is not.
> 
> Hi Conor, Thanks for your message!
> 
> I need the compatible to make sure the correct ID of the switch is
> being set in the driver as well as its features.

Are the features of this switch such that a driver for another ksz
switch would not work (even in a limited capacity) with the 8567?
Things like the register map changing or some feature being removed are
examples of why it may not work.

> You mean I shall mention the reason in the commit-message, or where?

Yes.

Thanks,
Conor

> > >  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > index c963dc09e8e1..52acc15ebcbf 100644
> > > --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > @@ -31,6 +31,7 @@ properties:
> > >        - microchip,ksz9893
> > >        - microchip,ksz9563
> > >        - microchip,ksz8563
> > > +      - microchip,ksz8567
> > >  
> > >    reset-gpios:
> > >      description:
> > > -- 
> > > 2.34.1
> > >
  

On Tue, 2024-01-23 at 17:23 +0000, Conor Dooley wrote:
> On Tue, Jan 23, 2024 at 05:17:53PM +0100, Philippe Schenker wrote:
> > 
> > 
> > On Tue, 2024-01-23 at 16:06 +0000, Conor Dooley wrote:
> > > On Tue, Jan 23, 2024 at 02:50:13PM +0100, Philippe Schenker
> > > wrote:
> > > > From: Philippe Schenker <philippe.schenker@impulsing.ch>
> > > > 
> > > > This commit adds the dt-binding for KSZ8567, a robust 7-port
> > > > Ethernet switch. The KSZ8567 features two RGMII/MII/RMII
> > > > interfaces,
> > > > each capable of gigabit speeds, complemented by five 10/100
> > > > Mbps
> > > > MAC/PHYs.
> > > > 
> > > > Signed-off-by: Philippe Schenker
> > > > <philippe.schenker@impulsing.ch>
> > > 
> > > This device has all the same constraints as the other ones in
> > > this
> > > binding, why is it not compatible with any of them? If it isn't,
> > > the
> > > compatible should mention why it is not.
> > 
> > Hi Conor, Thanks for your message!
> > 
> > I need the compatible to make sure the correct ID of the switch is
> > being set in the driver as well as its features.
> 
> Are the features of this switch such that a driver for another ksz
> switch would not work (even in a limited capacity) with the 8567?
> Things like the register map changing or some feature being removed
> are
> examples of why it may not work.

Yes the ksz dsa driver is made so that it checks the ID of the attached
chip and refuses to work if it doesn't match. [1]
It is a very similar chip and uses the same regmap as KSZ9567 but with
lower phy-speeds on its 5 switch ports. The two upstream CPU ports are
gigabit capable. All this information is set-up in the second patch of
this series. [2]

I will include a description to the second series. Thanks for your
feedback.

Philippe


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/microchip/ksz_common.c?h=v6.8-rc1#n3181
[2]
https://patchwork.kernel.org/project/netdevbpf/patch/20240123135014.614858-2-dev@pschenker.ch/

> 
> > You mean I shall mention the reason in the commit-message, or
> > where?
> 
> Yes.
> 
> Thanks,
> Conor
> 
> > > >  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml |
> > > > 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > index c963dc09e8e1..52acc15ebcbf 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > +++
> > > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > @@ -31,6 +31,7 @@ properties:
> > > >        - microchip,ksz9893
> > > >        - microchip,ksz9563
> > > >        - microchip,ksz8563
> > > > +      - microchip,ksz8567
> > > >  
> > > >    reset-gpios:
> > > >      description:
> > > > -- 
> > > > 2.34.1
> > > >
  

On Tue, Jan 23, 2024 at 06:30:16PM +0100, Philippe Schenker wrote:
> 
> 
> On Tue, 2024-01-23 at 17:23 +0000, Conor Dooley wrote:
> > On Tue, Jan 23, 2024 at 05:17:53PM +0100, Philippe Schenker wrote:
> > > 
> > > 
> > > On Tue, 2024-01-23 at 16:06 +0000, Conor Dooley wrote:
> > > > On Tue, Jan 23, 2024 at 02:50:13PM +0100, Philippe Schenker
> > > > wrote:
> > > > > From: Philippe Schenker <philippe.schenker@impulsing.ch>
> > > > > 
> > > > > This commit adds the dt-binding for KSZ8567, a robust 7-port
> > > > > Ethernet switch. The KSZ8567 features two RGMII/MII/RMII
> > > > > interfaces,
> > > > > each capable of gigabit speeds, complemented by five 10/100
> > > > > Mbps
> > > > > MAC/PHYs.
> > > > > 
> > > > > Signed-off-by: Philippe Schenker
> > > > > <philippe.schenker@impulsing.ch>
> > > > 
> > > > This device has all the same constraints as the other ones in
> > > > this
> > > > binding, why is it not compatible with any of them? If it isn't,
> > > > the
> > > > compatible should mention why it is not.
> > > 
> > > Hi Conor, Thanks for your message!
> > > 
> > > I need the compatible to make sure the correct ID of the switch is
> > > being set in the driver as well as its features.
> > 
> > Are the features of this switch such that a driver for another ksz
> > switch would not work (even in a limited capacity) with the 8567?
> > Things like the register map changing or some feature being removed
> > are
> > examples of why it may not work.
> 
> Yes the ksz dsa driver is made so that it checks the ID of the attached
> chip and refuses to work if it doesn't match. [1]

That sounds counter productive to be honest. Why does the driver not
trust that the dt is correct? I saw this recently in some IIO drivers,
but it was shot down for this sort of reason.

> It is a very similar chip and uses the same regmap as KSZ9567 but with
> lower phy-speeds on its 5 switch ports. The two upstream CPU ports are
> gigabit capable. All this information is set-up in the second patch of
> this series. [2]

That, to me, means the lack of a fallback is justified. If it were the
other way around, then a fallback sounds like it would be suitable.

> 
> I will include a description to the second series. Thanks for your
> feedback.

Okay, thanks. You can add
Acked-by: Conor Dooley <conor.dooley@microchip.com>
when you do.

And despite the email, I have nothing to do with these switches, I am
just a sucker that signed up to review dt-bindings...

Thanks,
Conor.

> 
> Philippe
> 
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/microchip/ksz_common.c?h=v6.8-rc1#n3181
> [2]
> https://patchwork.kernel.org/project/netdevbpf/patch/20240123135014.614858-2-dev@pschenker.ch/
> 
> > 
> > > You mean I shall mention the reason in the commit-message, or
> > > where?
> > 
> > Yes.
> > 
> > Thanks,
> > Conor
> > 
> > > > >  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml |
> > > > > 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > > index c963dc09e8e1..52acc15ebcbf 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> > > > > @@ -31,6 +31,7 @@ properties:
> > > > >        - microchip,ksz9893
> > > > >        - microchip,ksz9563
> > > > >        - microchip,ksz8563
> > > > > +      - microchip,ksz8567
> > > > >  
> > > > >    reset-gpios:
> > > > >      description:
> > > > > -- 
> > > > > 2.34.1
> > > > >
  

On Tue, 2024-01-23 at 18:37 +0000, Conor Dooley wrote:
> On Tue, Jan 23, 2024 at 06:30:16PM +0100, Philippe Schenker wrote:
> > 
> > 
> > On Tue, 2024-01-23 at 17:23 +0000, Conor Dooley wrote:
> > > On Tue, Jan 23, 2024 at 05:17:53PM +0100, Philippe Schenker wrote:
> > > > 
> > > > 
> > > > On Tue, 2024-01-23 at 16:06 +0000, Conor Dooley wrote:
> > > > > On Tue, Jan 23, 2024 at 02:50:13PM +0100, Philippe Schenker
> > > > > wrote:
> > > > > > From: Philippe Schenker <philippe.schenker@impulsing.ch>
> > > > > > 
> > > > > > This commit adds the dt-binding for KSZ8567, a robust 7-port
> > > > > > Ethernet switch. The KSZ8567 features two RGMII/MII/RMII
> > > > > > interfaces,
> > > > > > each capable of gigabit speeds, complemented by five 10/100
> > > > > > Mbps
> > > > > > MAC/PHYs.
> > > > > > 
> > > > > > Signed-off-by: Philippe Schenker
> > > > > > <philippe.schenker@impulsing.ch>
> > > > > 
> > > > > This device has all the same constraints as the other ones in
> > > > > this
> > > > > binding, why is it not compatible with any of them? If it
> > > > > isn't,
> > > > > the
> > > > > compatible should mention why it is not.
> > > > 
> > > > Hi Conor, Thanks for your message!
> > > > 
> > > > I need the compatible to make sure the correct ID of the switch
> > > > is
> > > > being set in the driver as well as its features.
> > > 
> > > Are the features of this switch such that a driver for another ksz
> > > switch would not work (even in a limited capacity) with the 8567?
> > > Things like the register map changing or some feature being
> > > removed
> > > are
> > > examples of why it may not work.
> > 
> > Yes the ksz dsa driver is made so that it checks the ID of the
> > attached
> > chip and refuses to work if it doesn't match. [1]
> 
> That sounds counter productive to be honest. Why does the driver not
> trust that the dt is correct? I saw this recently in some IIO drivers,
> but it was shot down for this sort of reason.
> 
> > It is a very similar chip and uses the same regmap as KSZ9567 but
> > with
> > lower phy-speeds on its 5 switch ports. The two upstream CPU ports
> > are
> > gigabit capable. All this information is set-up in the second patch
> > of
> > this series. [2]
> 
> That, to me, means the lack of a fallback is justified. If it were the
> other way around, then a fallback sounds like it would be suitable.

Yes, I believe a generic fallback would anyway mostly end up with errors
or misbehavior. But I also might be wrong. What I checked is that these
per-switch settings even increased from 5.15..6.7 which to me it seems
those are really needed.
I am no expert in this driver at all I just try to make my hardware work
and with these patches it now seems to switch really well.

> 
> > 
> > I will include a description to the second series. Thanks for your
> > feedback.
> 
> Okay, thanks. You can add
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> when you do.
> 
> And despite the email, I have nothing to do with these switches, I am
> just a sucker that signed up to review dt-bindings...

Well, I'm grateful for your review and feedback. Thanks for your work
around Linux kernel! And thanks for the Acked-by.

Philippe

> 
> Thanks,
> Conor.
> 
> > 
> > Philippe
> > 
> > 
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/microchip/ksz_common.c?h=v6.8-rc1#n3181
> > [2]
> > https://patchwork.kernel.org/project/netdevbpf/patch/20240123135014.614858-2-dev@pschenker.ch/
> > 
> > > 
> > > > You mean I shall mention the reason in the commit-message, or
> > > > where?
> > > 
> > > Yes.
> > > 
> > > Thanks,
> > > Conor
> > > 
> > > > > >  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yam
> > > > > > l |
> > > > > > 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.ya
> > > > > > ml
> > > > > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.ya
> > > > > > ml
> > > > > > index c963dc09e8e1..52acc15ebcbf 100644
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.ya
> > > > > > ml
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.ya
> > > > > > ml
> > > > > > @@ -31,6 +31,7 @@ properties:
> > > > > >        - microchip,ksz9893
> > > > > >        - microchip,ksz9563
> > > > > >        - microchip,ksz8563
> > > > > > +      - microchip,ksz8567
> > > > > >  
> > > > > >    reset-gpios:
> > > > > >      description:
> > > > > > -- 
> > > > > > 2.34.1
> > > > > >
  

> That sounds counter productive to be honest. Why does the driver not
> trust that the dt is correct? I saw this recently in some IIO drivers,
> but it was shot down for this sort of reason.

DT is software, therefore it contains bugs.

Say we ignore that the compatible does not match the hardware on the
board and just accept the DT has a bug in it and keep going.

That then makes the compatible pointless, and unusable for anything,
since there are boards out in the wild with incorrect compatibles. If
we later actually use the compatible for something, it might cause
regressions for those buggy DT blobs.

By erroring out then the compatible does not match the hardware avoids
such bugs.

The marvell mv88e6xxx driver takes a different approach. All the
compatible does is tell the driver where to find the ID
register. Marvell keeps moving it around, so there are three different
compatibles for the three different locations. If you use the wrong
compatible, its not going to find a device is knows about and errors
out. So this also avoids bugs in the compatible.

     Andrew
  

Hi Conor,

On Tue, Jan 23, 2024 at 06:37:55PM +0000, Conor Dooley wrote:
> On Tue, Jan 23, 2024 at 06:30:16PM +0100, Philippe Schenker wrote:
> > > > Hi Conor, Thanks for your message!
> > > > 
> > > > I need the compatible to make sure the correct ID of the switch is
> > > > being set in the driver as well as its features.
> > > 
> > > Are the features of this switch such that a driver for another ksz
> > > switch would not work (even in a limited capacity) with the 8567?
> > > Things like the register map changing or some feature being removed
> > > are
> > > examples of why it may not work.
> > 
> > Yes the ksz dsa driver is made so that it checks the ID of the attached
> > chip and refuses to work if it doesn't match. [1]
> 
> That sounds counter productive to be honest. Why does the driver not
> trust that the dt is correct? I saw this recently in some IIO drivers,
> but it was shot down for this sort of reason.

If the hardware provides device ID registers, what is the best practice
in reconciling them with the compatible string?

I see 2 extreme cases. Ethernet PHY devices seem to blindly trust the
PHY ID from the "ethernet-phy-idXXXX.XXXX" compatible string, and phylib
won't read the PHY ID from the standard MDIO registers when this is present.
Whereas PCI seems to completely disregard the vendor ID and device ID
from the "pciXXXX,XXXX" compatible string of function OF nodes. Both
these subsystems have the "compatible" string optional.

I could see an advantage in using a precise device ID in the compatible
string, rather than just one from which the _location_ of the device ID
can be deduced, because the precise compatible string allows for much
finer grained static analysis in the schema for the device. In case of a
switch, that is the number of ports, supported interface modes for each
port, etc. With an imprecise device ID, you don't know what you really
get until you boot the board.

> And despite the email, I have nothing to do with these switches, I am
> just a sucker that signed up to review dt-bindings...

Same here, just a sucker with some switches and not many clues about
other things :)
  

On Wed, Jan 24, 2024 at 07:08:29PM +0100, Andrew Lunn wrote:
> > That sounds counter productive to be honest. Why does the driver not
> > trust that the dt is correct? I saw this recently in some IIO drivers,
> > but it was shot down for this sort of reason.
> 
> DT is software, therefore it contains bugs.
> 
> Say we ignore that the compatible does not match the hardware on the
> board and just accept the DT has a bug in it and keep going.
> 
> That then makes the compatible pointless, and unusable for anything,
> since there are boards out in the wild with incorrect compatibles. If
> we later actually use the compatible for something, it might cause
> regressions for those buggy DT blobs.
> 
> By erroring out then the compatible does not match the hardware avoids
> such bugs.

It also makes fallback compatibles useless, which is what I see as being
counter productive, since you'll have to add support to the driver even
if (other than the id) the change is imperceptible to software.
If you have your reasons why you do not trust the compatibles for these
devices, then it is your prerogative as a driver author to cross check it
and fail if they don't match.

That said, it does not prevent the fallback being accurately described
in the binding itself, which at the end of the day is what I am more
interested it.

> The marvell mv88e6xxx driver takes a different approach. All the
> compatible does is tell the driver where to find the ID
> register. Marvell keeps moving it around, so there are three different
> compatibles for the three different locations. If you use the wrong
> compatible, its not going to find a device is knows about and errors
> out. So this also avoids bugs in the compatible.
> 
>      Andrew
  

On Thu, Jan 25, 2024 at 11:57:19AM +0200, Vladimir Oltean wrote:
> Hi Conor,
> 
> On Tue, Jan 23, 2024 at 06:37:55PM +0000, Conor Dooley wrote:
> > On Tue, Jan 23, 2024 at 06:30:16PM +0100, Philippe Schenker wrote:
> > > > > Hi Conor, Thanks for your message!
> > > > > 
> > > > > I need the compatible to make sure the correct ID of the switch is
> > > > > being set in the driver as well as its features.
> > > > 
> > > > Are the features of this switch such that a driver for another ksz
> > > > switch would not work (even in a limited capacity) with the 8567?
> > > > Things like the register map changing or some feature being removed
> > > > are
> > > > examples of why it may not work.
> > > 
> > > Yes the ksz dsa driver is made so that it checks the ID of the attached
> > > chip and refuses to work if it doesn't match. [1]
> > 
> > That sounds counter productive to be honest. Why does the driver not
> > trust that the dt is correct? I saw this recently in some IIO drivers,
> > but it was shot down for this sort of reason.
> 
> If the hardware provides device ID registers, what is the best practice
> in reconciling them with the compatible string?
> 
> I see 2 extreme cases. Ethernet PHY devices seem to blindly trust the
> PHY ID from the "ethernet-phy-idXXXX.XXXX" compatible string, and phylib
> won't read the PHY ID from the standard MDIO registers when this is present.
> Whereas PCI seems to completely disregard the vendor ID and device ID
> from the "pciXXXX,XXXX" compatible string of function OF nodes. Both
> these subsystems have the "compatible" string optional.

The software is free to do either, even if the compatible is a mandatory
property. Which is the right thing to do varies though. In your first
example, the compatible might be used because the standard MDIO
registers do not provide that function for whatever reason and therefore
cannot be read. Or there might be some shenzen market ripoff of another
device that it claims to be in its ID registers but has some
incompatible difference in the programming model.

In general though, if a device can self identify, I would be inclined to
value the self identification over that provided by the devicetree.

My comments here were because of the default in the switch statement
that rejects probe if the ID is unknown as it excludes the use of
fallback compatibles.

In this particular case, and maybe some historical reasons prevent this
that I am unaware of, I would read the ID of the device and if that is
an ID that the driver is aware of, treat that as the truth. As far as I
can tell from my quick look, the driver does this.

The first potential mismatch then is where the ID is, but does not match
what the DT claims the device is. As I said, I'd be inclined to trust
the self identification here, but I can at least understand rejection of
probe. Again from a quick look, the driver seems to trust the self
identification.

If the driver don't recognise the ID then I would treat the device as if
it is what the match data says it is, so that fallback compatibles would
work. This is the case that this driver does not allow.

> I could see an advantage in using a precise device ID in the compatible
> string, rather than just one from which the _location_ of the device ID
> can be deduced, because the precise compatible string allows for much
> finer grained static analysis in the schema for the device. In case of a
> switch, that is the number of ports, supported interface modes for each
> port, etc. With an imprecise device ID, you don't know what you really
> get until you boot the board.

That is true, I think it is pretty desirable (although admittedly I am
rather biased) to add specific compatibles for validation reasons even
if the drivers make no use of them. Generally new bindings for such
cases require a fair bit of justification, but its harder to stop the
proliferation of existing cases, without retrofitting specific
compatibles to the dts users (in addition to the generic one), and
disallowing the generic compatible in isolation.

> > And despite the email, I have nothing to do with these switches, I am
> > just a sucker that signed up to review dt-bindings...
> 
> Same here, just a sucker with some switches and not many clues about
> other things :)