devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: James Tai <james.tai@realtek.com>
Cc: "linux-realtek-soc@lists.infradead.org" 
	<linux-realtek-soc@lists.infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes
Date: Tue, 19 Nov 2019 09:34:46 +0100	[thread overview]
Message-ID: <ed7c483d-b518-c74f-f66d-a812d0858f4c@suse.de> (raw)
In-Reply-To: <20b3d0956bed4338a540216df07f16e5@realtek.com>

Hi James,

Adding Philipp.

Am 18.11.19 um 10:22 schrieb James Tai:
>> +			reset1: reset-controller@0 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x0 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
>> +			reset2: reset-controller@4 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x4 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
>> +			reset3: reset-controller@8 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x8 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
>> +			iso_reset: reset-controller@7088 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x7088 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
> 
> We don't use the DesignWare IP for the reset controller.

Thanks for reviewing.

We already merged the equivalent nodes for RTD129x into arm-soc.git.
No Realtek review was received back when it was posted [1], sadly.

How does your reset controller differ from DesignWare, and how would you
prefer to handle it?

a) Do you want to send patches for a new Realtek-specific dt-binding [2]
and extend reset-simple driver to cover it as a copy&paste of the
DesignWare of_device_id?

b) Do you believe you need to submit a completely new reset driver?

An issue I had raised twice [4, 1] was that reset-simple only allows for
contiguous registers and thus couldn't handle the gap between reset3 and
reset4 on RTD1295, forcing me to use per-register nodes for consistency.
I am against modeling RTD1195 differently from RTD1295+, assuming
they're the equivalent IP, so we need a solution that works for both.
Philipp did indicate in [4] we could extend reset-simple for this gap
"if the implementation could be kept reasonably simple".

With v5.4-rc8 already tagged, please hurry if you want a different
binding in v5.5.

Regards,
Andreas

[1] https://patchwork.kernel.org/cover/11206255/
[2] https://patchwork.kernel.org/patch/9902665/
[3] https://patchwork.kernel.org/patch/9902673/
[4] https://patchwork.kernel.org/patch/9902675/
[5] https://patchwork.kernel.org/patch/9902671/
[6] https://patchwork.kernel.org/patch/9902663/

-- 
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-19  8:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-17  7:21 [PATCH v3 0/8] ARM: Initial RTD1195 and MeLE X1000 support Andreas Färber
2019-11-17  7:21 ` [PATCH v3 1/8] dt-bindings: arm: realtek: Add RTD1195 and MeLE X1000 Andreas Färber
2019-11-17  7:21 ` [PATCH v3 3/8] ARM: dts: Prepare Realtek " Andreas Färber
2019-11-17 10:47   ` Marc Zyngier
2019-11-17 15:40     ` Andreas Färber
2019-11-17 16:22       ` Marc Zyngier
2019-11-18  1:24         ` Andreas Färber
2019-11-18  9:14           ` Marc Zyngier
2019-11-17  7:21 ` [PATCH v3 4/8] ARM: dts: rtd1195: Introduce r-bus Andreas Färber
2019-11-17  7:21 ` [PATCH v3 5/8] dt-bindings: reset: Add Realtek RTD1195 Andreas Färber
2019-11-17  7:21 ` [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes Andreas Färber
2019-11-18  9:22   ` James Tai
2019-11-19  8:34     ` Andreas Färber [this message]
2019-11-20  6:53       ` James Tai
2019-11-17  7:21 ` [PATCH v3 7/8] ARM: dts: rtd1195: Add UART resets 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=ed7c483d-b518-c74f-f66d-a812d0858f4c@suse.de \
    --to=afaerber@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=james.tai@realtek.com \
    --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=p.zabel@pengutronix.de \
    --cc=robh+dt@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).