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
| ||
|
Message-ID: <20170914234934.GV5024@atomide.com> Date: Thu, 14 Sep 2017 16:49:35 -0700 From: Tony Lindgren <tony@...mide.com> To: Linus Walleij <linus.walleij@...aro.org> Cc: Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>, "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Grygorii Strashko <grygorii.strashko@...com>, linux-omap@...r.kernel.org Subject: Re: [PATCH 14/16] gpio: Add support for banked GPIO controllers * Tony Lindgren <tony@...mide.com> [170914 16:38]: > * Linus Walleij <linus.walleij@...aro.org> [170914 07:00]: > > On Fri, Sep 1, 2017 at 8:57 PM, Thierry Reding <thierry.reding@...il.com> wrote: > > > > > From: Thierry Reding <treding@...dia.com> > > > > > > Some GPIO controllers are subdivided into multiple logical blocks called > > > banks (or ports). This is often caused by the design assigning separate > > > resources, such as register regions or interrupts, to each bank, or some > > > set of banks. > > > > > > This commit adds support for describing controllers that have such a > > > banked design and provides common code for dealing with them. > > > > > > Signed-off-by: Thierry Reding <treding@...dia.com> > > > > This patch makes me really happy. > > > > It pulls in a lot of weirdness to the OF core and creates a coherent > > way of handling these "banked" GPIO chips. > > > > CC to Tony to make sure he checks that OMAP is ready to use this > > too. > > Adding Grygorii to Cc as well, we'll take a look. > > Probably the runtime PM will be an issue here still. We must currently > do runtime PM on per GPIO bank basis instead of per GPIO pin level as > we constantly runtime_suspend/resume the whole GPIO bank for idle modes > on the SoCs that support PM. So the usage count for the bank needs to > be either 0 or 1 and cannot be the lines used in the bank. And based on a quick look at this series it should not cause problems there. For managing the banks in a generic way, I like the idea too. Regards, Tony
Powered by blists - more mailing lists