[PATCH v3 2/9] reset: Add Raspberry Pi 4 firmware reset controller

Philipp Zabel p.zabel at pengutronix.de
Fri Jun 26 06:43:07 EDT 2020


On Wed, 2020-06-17 at 12:44 +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-06-17 at 12:02 +0200, Philipp Zabel wrote:
> > Hi Nicolas,
> > 
> > On Fri, 2020-06-12 at 19:13 +0200, Nicolas Saenz Julienne wrote:
> > > Raspberry Pi 4's co-processor controls some of the board's HW
> > > initialization process, but it's up to Linux to trigger it when
> > > relevant. Introduce a reset controller capable of interfacing with
> > > RPi4's co-processor that models these firmware initialization routines as
> > > reset lines.
> > > 
> > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne at suse.de>
> > > Reviewed-by: Florian Fainelli <f.fainelli at gmail.com>
> > 
> > Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> 
> Thanks!
> 
> > If there is a good reason for the single DT specified reset id, I can
> > pick up patches 1 and 2.
> 
> The idea here is to make sure we're reasonably covered against further changes
> in firmware. If we define constraints too narrow it can be a pain to support
> new features without breaking backwards compatibility in dt.

Ok.

> > If you change the dts patch 4 to use a number instead of the reset id
> > define for now, there wouldn't even be a dependency between these reset
> > and dts patches.
> 
> I was under the impression that having an explicit definition was nice to have.
> What's troubling about creating the dependency?

Just that the last patch has to wait for the reset patches to be merged
before it can be applied.

regards
Philipp



More information about the linux-arm-kernel mailing list