linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-realtek-soc@lists.infradead.org
Subject: Re: [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property
Date: Wed, 6 Nov 2019 09:42:01 +0100	[thread overview]
Message-ID: <202d501d-f548-24c6-b99c-652a59a9e255@suse.de> (raw)
In-Reply-To: <20191106044605.GA28959@bogus>

Am 06.11.19 um 05:46 schrieb Rob Herring:
> On Sun, Nov 03, 2019 at 02:36:39AM +0100, Andreas Färber wrote:
>> Allow to optionally specify a second register to identify the chip.
>> Whether needed and which register to specify depends on the family;
>> RTD1295 family will want the CHIP_INFO1 register.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  A SoC specific binding would defeat the purpose of the generic Linux driver;
> 
> Why? You can map any number of compatibles to a generic driver.

Because the purpose of the driver is to read from the registers which
chip it is. If we tell it via the compatible what it is supposed to be,
1) only the revision would need to be read, and 2) how should it react
if the compatible tells it one thing and the register value another.

Also it doesn't solve the problem that we may need to extend the binding
as new models emerge, or instead of just rtd1195, rtd1295, rtd1395, etc.
we'd also need one for each chip, i.e., rtd1296, cf. 1) above.

>>  is it possible to check the root node's compatible in an if: expression
>>  to prohibit using more than one reg on "realtek,rtd1195"?
> 
> The "rule" is different programming model, different compatible string 
> for the block.

Agreed in general.

> But this looks simple enough, I don't really care.

Hope you also read the cover letter wrt syscon? That would probably
obsolete this binding then and require to move the driver's logic into a
module init instead for lack of dedicated compatible to bind against,
like Meson does.

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

  reply	other threads:[~2019-11-06  8:42 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-03  1:36 [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber
2019-11-03  1:36 ` [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding Andreas Färber
2019-11-06  4:41   ` Rob Herring
2019-11-03  1:36 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 Andreas Färber
2019-11-03  1:45   ` Andreas Färber
2019-11-11  4:56   ` [PATCH] base: soc: Export soc_device_to_device() helper Andreas Färber
2019-11-11  5:27     ` Greg Kroah-Hartman
2019-11-11  5:42       ` Andreas Färber
2019-11-11  6:40         ` Greg Kroah-Hartman
2019-11-11 20:10           ` Andreas Färber
2019-11-12  0:29             ` Andreas Färber
2019-11-12  5:23             ` Greg Kroah-Hartman
2019-11-12  7:29               ` Uwe Kleine-König
2019-11-12 10:47                 ` Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Andreas Färber
2019-11-14 22:09                   ` Rob Herring
2019-11-15 11:15                     ` Andreas Färber
2019-11-15 11:49                     ` Andreas Färber
2019-11-15  8:52                   ` Neil Armstrong
2019-11-15  8:58                     ` Geert Uytterhoeven
2019-11-15 12:00                       ` Andreas Färber
2019-11-15 12:34                         ` Geert Uytterhoeven
2019-11-18 15:55                           ` Tony Lindgren
2019-11-12 10:48                 ` [PATCH] base: soc: Export soc_device_to_device() helper Lee Jones
2020-01-02 14:29   ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 James Tai
2020-01-02 14:39     ` Andreas Färber
2020-01-02 15:02       ` James Tai
2020-01-03  5:07     ` Stanley Chang[昌育德]
2019-11-03  1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber
2020-01-02 14:32   ` James Tai
2020-01-03  5:07     ` Stanley Chang[昌育德]
2020-01-02 14:33   ` James Tai
2020-01-02 14:34   ` James Tai
2019-11-03  1:36 ` [RFC 04/11] ARM: dts: rtd1195: " Andreas Färber
2019-11-03  1:36 ` [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property Andreas Färber
2019-11-06  4:46   ` Rob Herring
2019-11-06  8:42     ` Andreas Färber [this message]
2019-11-03  1:36 ` [RFC 06/11] soc: realtek: chip: Detect RTD1296 Andreas Färber
2020-01-02 14:35   ` James Tai
2019-11-03  1:36 ` [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 Andreas Färber
2019-11-03  1:36 ` [RFC 08/11] soc: realtek: chip: Detect RTD1293 Andreas Färber
2019-11-03  1:36 ` [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again Andreas Färber
2019-11-03  1:36 ` [RFC 10/11] soc: realtek: chip: Detect RTD1294 Andreas Färber
2019-11-03  1:36 ` [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse Andreas Färber
2019-11-07  7:16 ` [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber

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=202d501d-f548-24c6-b99c-652a59a9e255@suse.de \
    --to=afaerber@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-realtek-soc@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh@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;
as well as URLs for NNTP newsgroup(s).