[RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.

[Moritz Fischer]

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 at xilinx.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 at monstr.eu> wrote:
>>>> Hi Moritz,
>>>>
>>>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>>>> Signed-off-by: Moritz Fischer <moritz.fischer at ettus.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
>