devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Markus Schneider-Pargmann <msp@baylibre.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Conor Dooley <conor+dt@kernel.org>,
	Chandrasekar Ramakrishnan <rcsekar@samsung.com>,
	Michal Kubiak <michal.kubiak@intel.com>,
	Vivek Yadav <vivek.2311@samsung.com>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Simon Horman <simon.horman@corigine.com>
Subject: Re: [PATCH v2 5/6] can: tcan4x5x: Add support for tcan4552/4553
Date: Sat, 1 Jul 2023 10:34:00 +0200	[thread overview]
Message-ID: <e5bd4f01-0b00-4d70-c642-4fdfc0a139fc@linaro.org> (raw)
In-Reply-To: <20230627142300.heju4qccian5hsjk@blmsp>

On 27/06/2023 16:23, Markus Schneider-Pargmann wrote:

>>> The version information is always readable for that chip, regardless of
>>> state and wake GPIOs as far as I know. So yes it is possible to setup
>>> the GPIOs based on the content of the ID register.
>>>
>>> I personally would prefer separate compatibles. The binding
>>> documentation needs to address that wake and state GPIOs are not
>>> available for tcan4552/4553. I think having compatibles that are for
>>> these chips would make sense then. However this is my opinion, you are
>>> the maintainer.
>>
>> We do not talk about compatibles in the bindings here. This is
>> discussion about your driver. The entire logic of validating DTB is
>> flawed and not needed. Detect the variant and act based on this.
> 
> I thought it was about the bindings, sorry.
> 
> So to summarize the compatibles ti,tcan4552 and ti,tcan4553 are fine.
> But the driver should use the ID register for detection and not compare
> the detected variant with the given compatible?
> 
> In my opinion it is useful to have an error messages that says there is
> something wrong with the devicetree as this can be very helpful for the
> developers who bringup new devices. This helps to quickly find issues
> with the devicetree.

That's not a current policy for other drivers, so this shouldn't be
really special. Kernel is poor in validating DTS. It's not its job. It's
the job of the DT schema.

Best regards,
Krzysztof


  reply	other threads:[~2023-07-01  8:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21  9:30 [PATCH v2 0/6] can: tcan4x5x: Introduce tcan4552/4553 Markus Schneider-Pargmann
2023-06-21  9:30 ` [PATCH v2 1/6] dt-bindings: can: tcan4x5x: Add tcan4552 and tcan4553 variants Markus Schneider-Pargmann
2023-06-21 10:26   ` Krzysztof Kozlowski
2023-06-21 10:29   ` Krzysztof Kozlowski
2023-06-21 12:20     ` Markus Schneider-Pargmann
2023-06-21  9:30 ` [PATCH v2 2/6] can: tcan4x5x: Remove reserved register 0x814 from writable table Markus Schneider-Pargmann
2023-06-21  9:31 ` [PATCH v2 3/6] can: tcan4x5x: Check size of mram configuration Markus Schneider-Pargmann
2023-06-21  9:31 ` [PATCH v2 4/6] can: tcan4x5x: Rename ID registers to match datasheet Markus Schneider-Pargmann
2023-06-21  9:31 ` [PATCH v2 5/6] can: tcan4x5x: Add support for tcan4552/4553 Markus Schneider-Pargmann
2023-06-21 10:28   ` Krzysztof Kozlowski
2023-06-21 12:31     ` Markus Schneider-Pargmann
2023-06-21 13:00       ` Krzysztof Kozlowski
2023-06-22 12:23         ` Markus Schneider-Pargmann
2023-06-22 12:52           ` Krzysztof Kozlowski
2023-06-27 14:23             ` Markus Schneider-Pargmann
2023-07-01  8:34               ` Krzysztof Kozlowski [this message]
2023-07-18  7:57                 ` Marc Kleine-Budde
2023-06-21  9:31 ` [PATCH v2 6/6] can: tcan4x5x: Add error messages in probe Markus Schneider-Pargmann

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=e5bd4f01-0b00-4d70-c642-4fdfc0a139fc@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.kubiak@intel.com \
    --cc=mkl@pengutronix.de \
    --cc=msp@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rcsekar@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=simon.horman@corigine.com \
    --cc=vivek.2311@samsung.com \
    --cc=wg@grandegger.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;
as well as URLs for NNTP newsgroup(s).