public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor@kernel.org>,
	Philippe Schenker <dev@pschenker.ch>, <netdev@vger.kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Conor Dooley <conor+dt@kernel.org>,
	Woojung Huh <woojung.huh@microchip.com>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	<linux-kernel@vger.kernel.org>, <UNGLinuxDriver@microchip.com>,
	Marek Vasut <marex@denx.de>,
	Florian Fainelli <f.fainelli@gmail.com>,
	<devicetree@vger.kernel.org>, Eric Dumazet <edumazet@google.com>,
	"David S . Miller" <davem@davemloft.net>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH net-next v1 1/2] dt-bindings: net: dsa: Add KSZ8567 switch support
Date: Thu, 25 Jan 2024 12:53:38 +0000	[thread overview]
Message-ID: <20240125-crouch-decay-5b149b60e9f3@wendy> (raw)
In-Reply-To: <359c32a1-3ffb-4bb2-9a46-802dff3812c4@lunn.ch>

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-01-25 12:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 13:50 [PATCH net-next v1 1/2] dt-bindings: net: dsa: Add KSZ8567 switch support Philippe Schenker
2024-01-23 13:50 ` [PATCH net-next v1 2/2] " Philippe Schenker
2024-01-23 15:58   ` Arun.Ramadoss
2024-01-23 16:12     ` Philippe Schenker
2024-01-23 16:06 ` [PATCH net-next v1 1/2] dt-bindings: " Conor Dooley
2024-01-23 16:17   ` Philippe Schenker
2024-01-23 17:23     ` Conor Dooley
2024-01-23 17:30       ` Philippe Schenker
2024-01-23 18:37         ` Conor Dooley
2024-01-23 19:44           ` Philippe Schenker
2024-01-24 18:08           ` Andrew Lunn
2024-01-25 12:53             ` Conor Dooley [this message]
2024-01-25  9:57           ` Vladimir Oltean
2024-01-25 13:22             ` Conor Dooley

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=20240125-crouch-decay-5b149b60e9f3@wendy \
    --to=conor.dooley@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dev@pschenker.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=woojung.huh@microchip.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