[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAtXAHeko4tUhK-yjXxwfJkLxG3c5kjtyHML=z4mdnOXDy3E2Q@mail.gmail.com>
Date: Tue, 28 Jul 2015 06:54:43 -0700
From: Moritz Fischer <moritz.fischer@...us.com>
To: Michal Simek <michal.simek@...inx.com>
Cc: Nicolas Ferre <nicolas.ferre@...el.com>,
Michal Simek <monstr@...str.eu>, p.zabel@...gutronix.de,
mark.rutland@....com, devicetree@...r.kernel.org,
linux@....linux.org.uk, pawel.moll@....com,
ijc+devicetree@...lion.org.uk, 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.
Nicolas, Michal,
if macb doesn't benefit from it, no need for the reset in there then.
I think Michal's suggestion of adding it on an as necessary basis works fine.
For the PATCH round I'll just have the SLCR in there and drivers can
add it to their nodes later on if required.
Thanks,
Moritz
On Tue, Jul 28, 2015 at 12:44 AM, Michal Simek <michal.simek@...inx.com> wrote:
> 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