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:

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

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel