On Fri, 2020-06-26 at 12:43 +0200, Philipp Zabel wrote:

On Wed, 2020-06-17 at 12:44 +0200, Nicolas Saenz Julienne wrote:

quoted

On Wed, 2020-06-17 at 12:02 +0200, Philipp Zabel wrote:

quoted

Hi Nicolas,

On Fri, 2020-06-12 at 19:13 +0200, Nicolas Saenz Julienne wrote:

quoted

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 <redacted>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>

Thanks!

quoted

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.

quoted

quoted

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.

TBH there is no hurry, this only provides a better design on something that's
already available upstream. USB works on RPi4, so I don't mind if this gets
delayed a release.

Regards,
Nicolas