[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55B732E6.7080901@xilinx.com>
Date: Tue, 28 Jul 2015 09:44:38 +0200
From: Michal Simek <michal.simek@...inx.com>
To: Nicolas Ferre <nicolas.ferre@...el.com>,
Moritz Fischer <moritz.fischer@...us.com>,
Michal Simek <monstr@...str.eu>
CC: <p.zabel@...gutronix.de>, <mark.rutland@....com>,
<devicetree@...r.kernel.org>, <linux@....linux.org.uk>,
<pawel.moll@....com>, <ijc+devicetree@...lion.org.uk>,
Michal Simek <michal.simek@...inx.com>,
<linux-kernel@...r.kernel.org>, <robh+dt@...nel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Kumar Gala <galak@...eaurora.org>,
Sören Brinkmann <soren.brinkmann@...inx.com>
Subject: Re: [RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset
controller.
On 07/28/2015 08:59 AM, Nicolas Ferre wrote:
> Le 28/07/2015 07:03, Moritz Fischer a écrit :
>> Hi Michal,
>>
>> I agree we need to be careful with changing the bindings.
>>
>> On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek <monstr@...str.eu> wrote:
>>> Hi Moritz,
>>>
>>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>>> Signed-off-by: Moritz Fischer <moritz.fischer@...us.com>
>>>> ---
>>>> arch/arm/boot/dts/zynq-7000.dtsi | 43 ++++++++++++-
>>>
>>> This patch is nice in general but every change in binding should be
>>> discussed separately. There is also necessary to wire them up in the
>>> driver to do action. That's why I think that will be the best just to
>>> add the code to slcr and keep others untouched.
>>
>> Ok, just to clarify: You'd suggest to just add the rstc as child node
>> to the slcr,
>> and leave the other nodes untouched?
>>
>>>
>>> For example MACB/GEM is one example. Adding names to this node and
>>> extending driver to work properly with reset means that all others MACB
>>> users will be affected. Definitely this patch should be ACKed by Nicolas.
>
> Actually, I don't know why a reset property should be added to the macb
> driver...
I expect resetting IP core can solve something. But as I said it is
questionable if IP should be reset when driver is probed. Definitely on
Zynq there is a support for it. I am not aware about any problem which
requires IP to be reset.
Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists