linux-kernel - Re: [PATCH v2 1/4] dt-bindings: power: reset: add document for reboot-mode driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160120182840.GA15741@rob-hp-laptop>
Date:	Wed, 20 Jan 2016 12:28:40 -0600
From:	Rob Herring <robh@...nel.org>
To:	Andy Yan <andy.yan@...k-chips.com>
Cc:	heiko@...ech.de, arnd@...db.de, john.stultz@...aro.org,
	linux@...ck-us.net, galak@...eaurora.org,
	ijc+devicetree@...lion.org.uk, catalin.marinas@....com,
	geert+renesas@...der.be, sre@...nel.org, olof@...om.net,
	dbaryshkov@...il.com, alexandre.belloni@...e-electrons.com,
	jun.nie@...aro.org, pawel.moll@....com, f.fainelli@...il.com,
	will.deacon@....com, linux-rockchip@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
	linux@....linux.org.uk, linux-arm-kernel@...ts.infradead.org,
	lorenzo.pieralisi@....com, moritz.fischer@...us.com,
	cernekee@...il.com, linux-kernel@...r.kernel.org,
	dwmw2@...radead.org, mark.rutland@....com,
	maxime.ripard@...e-electrons.com
Subject: Re: [PATCH v2 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver

On Tue, Jan 12, 2016 at 07:29:49PM +0800, Andy Yan wrote:
> add device tree binding document for reboot-mode driver
> 
> Signed-off-by: Andy Yan <andy.yan@...k-chips.com>
> 
> ---
> 
> Changes in v2: None
> Changes in v1: None
> 
>  .../bindings/power/reset/reboot-mode.txt           | 41 +++++++++++++++++
>  .../bindings/power/reset/syscon-reboot-mode.txt    | 52 ++++++++++++++++++++++
>  2 files changed, 93 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>  create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> new file mode 100644
> index 0000000..81d9f66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> @@ -0,0 +1,41 @@
> +Generic reboot mode core map driver
> +
> +This driver get reboot mode arguments and call the write
> +interface to stores the magic value in special register
> +or ram . Then the bootloader can read it and take different
> +action according to the argument stored.
> +
> +Required properties:
> +- compatible: only support "syscon-reboot-mode" now.
> +
> +Each mode is represented as a sub-node of reboot_mode:
> +
> +Subnode required properties:
> +- linux,mode: reboot mode command,such as "loader", "recovery", "fastboot".
> +- loader,magic: magic number for the mode, this is vendor specific.
> +
> +Example:
> +	reboot_mode {

reboot-mode instead please.

> +		compatible = "syscon-reboot-mode";
> +		offset = <0x40>;

This doc by itself is a little confusing. For example, is a child of the 
syscon node? I would remove offset (and perhaps compatible) from this 
example.

> +
> +		loader {
> +			linux,mode = "loader";
> +			loader,magic = <BOOT_LOADER>;
> +		};

Sorry, my previous suggestion was not clear. I'm suggesting get rid of 
the subnodes and just do properties like this:

loader = <BOOT_LOADER>;
maskrom = <BOOT_MASKROM>;

That's the same amount of information unless node names and linux,mode 
values are going to diverge. Do they need to? I can't see a reason.


We need to be clear what loader means. More specifically, it is boot 
into bootloader shell. 

> +
> +		maskrom {

In theory, the bootrom could have multiple modes. This typically means a 
USB download mode. So perhaps a more precise name would be 
"rom-download". 

In chips I'm familiar with the bootrom mode is selected via a different 
mechanism than the secondary bootloader modes, but I suppose the same 
mechanism could be used.

> +			linux,mode = "maskrom";
> +			loader,magic = <BOOT_MASKROM>;
> +		};
> +
> +		recovery {
> +			linux,mode = "recovery";
> +			loader,magic = <BOOT_RECOVERY>;
> +		};
> +
> +		fastboot {
> +			linux,mode = "fastboot";
> +			loader,magic = <BOOT_FASTBOOT>;
> +		};