[U-Boot] reset uclass rename?

[U-Boot] reset uclass rename?

[Stephen Warren]

Simon,

For Tegra186 support, I'd like to introduce a reset subsystem into 
U-Boot, to support the reset DT bindings[1]. It'd be equivalent to the 
existing reset subsystem in Linux. This binding/subsystem does/would 
control reset of e.g. individual HW blocks in an SoC, or individual 
chips on the board.

It looks like there's already a "reset" uclass (include/reset.h, 
drivers/misc/reset*.c). However, that seems to address a slightly 
different case; CPU- or system-level reset rather than individual blocks.

I'd like to propose renaming the existing uclass to sysreset (system 
reset) to allow the new per-block/-module reset uclass/subsystem just 
"reset". Does that make sense to you, or should I name the new 
uclass/subsystem e.g. "module_reset"?

An alternative might be to extend the existing U-Boot reset subsystem to 
cover the new use-case too. However, U-Boot's existing concepts of warm 
vs. cold vs. power reset, and reset_walk_halt() don't exist in the reset 
DT bindings, so my instinct is that combining the two doesn't make sense 
semantically; I believe the sysreset API is a higher level concept that 
may use the raw capabilities of the new reset API in some HW-specific 
implementations.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reset 
(in particular, reset.txt)

[U-Boot] reset uclass rename?

[Simon Glass]

Hi Stephen,

On 11 May 2016 at 12:45, Stephen Warren <swarren@wwwdotorg.org> wrote:
> Simon,
>
> For Tegra186 support, I'd like to introduce a reset subsystem into U-Boot,
> to support the reset DT bindings[1]. It'd be equivalent to the existing
> reset subsystem in Linux. This binding/subsystem does/would control reset of
> e.g. individual HW blocks in an SoC, or individual chips on the board.
>
> It looks like there's already a "reset" uclass (include/reset.h,
> drivers/misc/reset*.c). However, that seems to address a slightly different
> case; CPU- or system-level reset rather than individual blocks.
>
> I'd like to propose renaming the existing uclass to sysreset (system reset)
> to allow the new per-block/-module reset uclass/subsystem just "reset". Does
> that make sense to you, or should I name the new uclass/subsystem e.g.
> "module_reset"?
>
> An alternative might be to extend the existing U-Boot reset subsystem to
> cover the new use-case too. However, U-Boot's existing concepts of warm vs.
> cold vs. power reset, and reset_walk_halt() don't exist in the reset DT
> bindings, so my instinct is that combining the two doesn't make sense
> semantically; I believe the sysreset API is a higher level concept that may
> use the raw capabilities of the new reset API in some HW-specific
> implementations.

Yes that is fine with me. I've been thinking the same thing.
'sysreset' seems like a reasonable name.

>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reset
> (in particular, reset.txt)

Regards,
Simon