Hi,

On Wed, Sep 16, 2020 at 10:00:51AM +0200, Lars Povlsen wrote:
> Lars Povlsen writes:
> > Sebastian Reichel writes:
> >> On Tue, Jun 02, 2020 at 11:49:08AM +0200, Lars Povlsen wrote:
> >> > Rob Herring writes:
> >> > > On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> >> > >> This documents the 'microchip,reset-switch-core' property in the
> >> > >> ocelot-reset driver.
> >> > >>
> >> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> >> > >> ---
> >> > >>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
> >> > >>  1 file changed, 6 insertions(+)
> >> > >>
> >> > >> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-rese=
> >> t.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> > >> index 4d530d8154848..20fff03753ad2 100644
> >> > >> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> > >> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> > >> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
> >> > >>  Required Properties:
> >> > >>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-res=
> >> et"
> >> > >>
> >> > >> +Optional properties:
> >> > >> +- microchip,reset-switch-core : Perform a switch core reset at the
> >> > >> +  time of driver load. This is may be used to initialize the switch
> >> > >> +  core to a known state (before other drivers are loaded).
> >> > >
> >> > > How do you know when other drivers are loaded? This could be a module
> >> > > perhaps. Doesn't seem like something that belongs in DT.
> >> > >
> >> > 
> >> > The reset driver is loaded at postcore_initcall() time, which ensures it
> >> > is loaded before other drivers using the switch core. I noticed other
> >> > drivers do the same to do low-level system reset and initialization at
> >> > early boot time.
> >> > 
> >> > > Can this behavior be implied with "microchip,sparx5-chip-reset"?
> >> > 
> >> > Since we need to cater for both modus operandi, I would need two driver
> >> > compatible strings per platform, which scales worse than a single
> >> > property.
> >> > 
> >> > The "microchip,reset-switch-core" is a device configuration property
> >> > which tells the system (driver) how the hw should be handled. Since you
> >> > do not *always* want to reset the switch core (f.ex. when implementing
> >> > systems with warm reboot), I think it makes perfect sense - but I may be
> >> > biased off course :-)
> >> > 
> >> > Thank you for (all) of your comments, by the way!
> >> > 
> >> > ---Lars
> >> 
> >> Is this series still needed? Did I miss a follow-up?
> >
> > Hi Sebastian!
> >
> > Yes, the series is still needed, but the conversation died after my
> > last message.
> >
> > If the DT-controlled reset property is too controversial, I am willing
> > to drop that part. (Rob just reviewed the bindings).
> >
> > MCHP reference designs have GPIO resets, so we *could* get by without,
> > but new designs may this feature.
> >
> >> -- Sebastian
> >
> 
> Sebastian,
> 
> Any update on the patches? They're the last part of the original Sparx5
> series, so I would love to get them done.
> 
> As previously stated, I could remove the "microchip,reset-switch-core"
> parts if that's whats what holding it stuck.

I am waiting for Rob's Acked-by for the binding.

-- Sebastian