linux-kernel - Re: [RFC][PATCH 0/4] SRAM based reboot reason driver for HiKey

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 5 Aug 2016 15:46:10 +0300
From:	Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
To:	John Stultz <john.stultz@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Rob Herring <robh@...nel.org>
CC:	Andy Yan <andy.yan@...k-chips.com>, Rob Herring <robh@...nel.org>,
	"Arnd Bergmann" <arnd@...db.de>,
	Thierry Reding <treding@...dia.com>,
	Heiko Stübner <heiko@...ech.de>,
	Caesar Wang <wxt@...k-chips.com>,
	Kees Cook <keescook@...omium.org>,
	Guodong Xu <guodong.xu@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	"Vishal Bhoj" <vishal.bhoj@...aro.org>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	<devicetree@...r.kernel.org>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [RFC][PATCH 0/4] SRAM based reboot reason driver for HiKey

Hi John,

On 08/04/2016 02:05 AM, John Stultz wrote:
> Now that Andy's reboot reason core driver has landed, I wanted
> to resubmit a reworked version of my SRAM based reboot reason
> driver.
>
> This allows the kernel to communicate to the bootloader what mode
> it should reboot to using some reserved memory.
>
> Feedback would be very much appreciated!

in my opinion the taken approach is wrong, and I've already explained
why and how to rework your driver to shrink the change, please see
https://lkml.org/lkml/2016/1/27/133

In this case I think that a SRAM device node should just contain
a plain description of partitions, compatible = "sram-reboot-mode" is
clearly not a device on "SRAM bus", it is not a device at all, so
please let's separate policy from mechanism

Because my proposed alternative approach separates policy from
mechanism, it for instanse allows to avoid overlappings on SRAM areas,
and still other drivers may serve as consumers of partitions on SRAM.

Please add me to Cc list when you send the next version of the driver.

With best wishes,
Vladimir

> thanks
> -john
>
> Cc: Andy Yan <andy.yan@...k-chips.com>
> Cc: Rob Herring <robh@...nel.org>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Thierry Reding <treding@...dia.com>
> Cc: Heiko Stübner <heiko@...ech.de>
> Cc: Caesar Wang <wxt@...k-chips.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Guodong Xu <guodong.xu@...aro.org>
> Cc: Haojian Zhuang <haojian.zhuang@...aro.org>
> Cc: Vishal Bhoj <vishal.bhoj@...aro.org>
> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
> Cc: devicetree@...r.kernel.org
> Cc: Android Kernel Team <kernel-team@...roid.com>
>
> John Stultz (4):
>   drivers: sram: Have sram driver probe children nodes
>   dt-bindings: power: reset: Add document for sram-reboot-mode driver
>   power: reset: Add sram-reboot-mode driver
>   dts: hikey: Add hikey support for sram-reboot-mode
>
>  .../bindings/power/reset/sram-reboot-mode.txt      | 35 ++++++++
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     | 22 ++++-
>  drivers/misc/sram.c                                |  3 +
>  drivers/power/reset/Kconfig                        | 10 +++
>  drivers/power/reset/Makefile                       |  1 +
>  drivers/power/reset/sram-reboot-mode.c             | 95 ++++++++++++++++++++++
>  6 files changed, 165 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/power/reset/sram-reboot-mode.txt
>  create mode 100644 drivers/power/reset/sram-reboot-mode.c
>