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]
Message-ID: <6304362.XcrazqMAeC@wuerfel>
Date:	Mon, 28 Dec 2015 17:09:03 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Heiko Stübner <heiko@...ech.de>,
	mark.rutland@....com, geert+renesas@...der.be,
	catalin.marinas@....com, will.deacon@....com,
	linux-kernel@...r.kernel.org,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	lorenzo.pieralisi@....com, linux@....linux.org.uk,
	dbaryshkov@...il.com, linux-rockchip@...ts.infradead.org,
	joel@....id.au, treding@...dia.com, wxt@...k-chips.com,
	devicetree@...r.kernel.org, khilman@...aro.org, pawel.moll@....com,
	ijc+devicetree@...lion.org.uk, robh+dt@...nel.org,
	john.stultz@...aro.org, akpm@...ux-foundation.org,
	moritz.fischer@...us.com, gregkh@...uxfoundation.org,
	sjg@...omium.org, sre@...nel.org, galak@...eaurora.org,
	olof@...om.net, Andy Yan <andy.yan@...k-chips.com>,
	jun.nie@...aro.org
Subject: Re: [PATCH v1 0/6] misc: add reboot mode driver

On Monday 28 December 2015 16:56:12 Heiko Stübner wrote:
> Am Montag, 28. Dezember 2015, 16:28:55 schrieb Arnd Bergmann:
> > On Wednesday 23 December 2015 17:31:45 Andy Yan wrote:
> > > +        { .compatible = "rockchip,reboot-mode-nvram",
> > > +                .data = (void *)&reboot-mode-nvram },
> > > +        {},
> > > +};
> > 
> > nvram is a complex topic by itself, because there are so many ways to do it.
> > I think what you are referring to here is a battery-backed memory that uses
> > one or more bytes at a fixed offset to store a particular piece of
> > information, as the drivers/char/nvram.c driver does. Maybe we should put
> > the reboot mode into that driver then?
> > 
> > There are other nvram drivers at various places in the kernel, and each may
> > be slightly different, or completely different, like the EFIVARs driver on
> > UEFI firmware or the key/value store on Open Firmware, these probably need
> > their own methods and not share the generic driver.
> 
> actually we now have drivers/nvmem/* that does that byte-wise addressing for 
> eeproms, efuses, etc in a generic way.

Good point, so some of the reboot-reason users will be able to use that
framework, but some will not:

- drivers/nvmem only works for fixed-length data in a fixed location, but
  not for key/value pairs, TLVs etc.

- Coming back to an earlier problem I pointed out, a lot of the things
  stored in an nvram need a consistent user interface. This includes stuff
  like kernel command line, boot image name, boot device, console
  configuration, network mac address. We probably want the reboot reason
  to fit into the wider framework for these, and drivers/nvmem doesn't
  (currently) look like a good place for that.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ