From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752203AbbL1QKG (ORCPT ); Mon, 28 Dec 2015 11:10:06 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:53039 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbbL1QKA convert rfc822-to-8bit (ORCPT ); Mon, 28 Dec 2015 11:10:00 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Heiko =?ISO-8859-1?Q?St=FCbner?= , mark.rutland@arm.com, geert+renesas@glider.be, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, Alexandre Belloni , lorenzo.pieralisi@arm.com, linux@arm.linux.org.uk, dbaryshkov@gmail.com, linux-rockchip@lists.infradead.org, joel@jms.id.au, treding@nvidia.com, wxt@rock-chips.com, devicetree@vger.kernel.org, khilman@linaro.org, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, robh+dt@kernel.org, john.stultz@linaro.org, akpm@linux-foundation.org, moritz.fischer@ettus.com, gregkh@linuxfoundation.org, sjg@chromium.org, sre@kernel.org, galak@codeaurora.org, olof@lixom.net, Andy Yan , jun.nie@linaro.org Subject: Re: [PATCH v1 0/6] misc: add reboot mode driver Date: Mon, 28 Dec 2015 17:09:03 +0100 Message-ID: <6304362.XcrazqMAeC@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <3171716.cOpneyGyL8@diego> References: <1450774949-23901-1-git-send-email-andy.yan@rock-chips.com> <3460735.DIRnhNBgbJ@wuerfel> <3171716.cOpneyGyL8@diego> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" X-Provags-ID: V03:K0:Tt8+NdUz+kuUk6rFRuDCT6BlSWCo1MkhR6D0KhHKedxQskykYdO 7xXrG91Klrec9mgcRthKRaWrzlWrIqVBadw1S8/NSAR6UmRMT5Z7k8jNRF51/9cIdfVzh00 cMc9lGe4Jo/+srcZdSdj9I2uQFD5kmm9ev1eEjrYn/m1vZSnTXpVIajAapwuk3iYV4/0oJP RMbUR5ZbFTm/UfnHPx6Zg== X-UI-Out-Filterresults: notjunk:1;V01:K0:soLRWOMD/i8=:dGWtR+LwPhkfK2+FEbtCei 2F4/aECLKIQ/+lglZNEqnbMR2khRoX7kGnuQ4GRuf2copXcv1JwR/D88KZeUh/WKkhodeqxjR 7A5jxKpZfynx0LHyQBJ/efLYh9qid3GglnYrmXFJ3YSHcp7sdwfOQZRj757AZJTJX23YCGhDC YKuPsBB6Lwr6Qsxem37T5uMMYbVLq4ZotfWU1qEpC3nPS9GN0rEiOFUOCBGqLJYeaY0Nmg47l cXCdXrUeGdByApMhR+23xeeSPArIaBilSkpbIwJtJcga3tfEjk1VtG6dv/79/tBh18MHwzNG/ lf46rQVmHnwya52FaThb/LgSe9NHw9Ab8ILfW+mNm1UNypt1IYUhjniV4bydXyPBrc3yXOLFT 3Jd0x4Ad9Sy2tPAzAzDq6W3sQ06xZ+yQa1+k5mpsJcdG34SoLRSX+CPLwe3IFKMPRrCc9RRVZ zXlMnwQCKEy/MA+WXthwrvwmlgM3VAMEURAqxEQugbQr7jEbOhIqYlUGgq7rcrOm4t0xHTm1/ BNWeNLMcqSf6ghph32EVz2qANl4ejWd5XBc3RLt8CZo1Kw3/L8QpT1bOzVCnbSvyvvrJZW9At 5z/AYWDo1ifY4bA7KReVDiN90+Vw3veWSib9a5lmeiBNKuH6lEXLdcb+38uM3KTPasO5vru3p eWfDRPYkZBZkTQdZo+RK298XGdpqxcyLCS1vFmZobWvISopW4fGQXEQKjODD2YcuTXoF+LCsO zWudStjrItxMz9ac Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v1 0/6] misc: add reboot mode driver Date: Mon, 28 Dec 2015 17:09:03 +0100 Message-ID: <6304362.XcrazqMAeC@wuerfel> References: <1450774949-23901-1-git-send-email-andy.yan@rock-chips.com> <3460735.DIRnhNBgbJ@wuerfel> <3171716.cOpneyGyL8@diego> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <3171716.cOpneyGyL8@diego> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, Heiko =?ISO-8859-1?Q?St=FCbner?= , geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org, catalin.marinas-5wv7dgnIgG8@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Alexandre Belloni , lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org, treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org, Andy Yan , akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org List-Id: devicetree@vger.kernel.org On Monday 28 December 2015 16:56:12 Heiko St=FCbner wrote: > Am Montag, 28. Dezember 2015, 16:28:55 schrieb Arnd Bergmann: > > On Wednesday 23 December 2015 17:31:45 Andy Yan wrote: > > > + { .compatible =3D "rockchip,reboot-mode-nvram", > > > + .data =3D (void *)&reboot-mode-nvram }, > > > + {}, > > > +}; > > = > > nvram is a complex topic by itself, because there are so many ways to d= o 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 p= ut > > 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 n= eed > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 28 Dec 2015 17:09:03 +0100 Subject: [PATCH v1 0/6] misc: add reboot mode driver In-Reply-To: <3171716.cOpneyGyL8@diego> References: <1450774949-23901-1-git-send-email-andy.yan@rock-chips.com> <3460735.DIRnhNBgbJ@wuerfel> <3171716.cOpneyGyL8@diego> Message-ID: <6304362.XcrazqMAeC@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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