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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 20 Feb 2019 10:37:46 +0100 From: Linus Walleij <linus.walleij@...aro.org> To: "Enrico Weigelt, metux IT consult" <lkml@...ux.net> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Enrico Weigelt, metux IT consult" <info@...ux.net>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, Bartosz Golaszewski <bgolaszewski@...libre.com>, Darren Hart <dvhart@...radead.org>, Andy Shevchenko <andy@...radead.org>, platform-driver-x86 <platform-driver-x86@...r.kernel.org> Subject: Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver On Thu, Feb 14, 2019 at 10:56 AM Enrico Weigelt, metux IT consult <lkml@...ux.net> wrote: > On 08.02.19 15:25, Linus Walleij wrote: > > >> +config GPIO_AMD_FCH > >> + tristate "GPIO support for AMD Fusion Controller Hub (G-series SOCs)" > >> + select GPIO_GENERIC > > > > You are selecting GPIO_GENERIC, is this necessary? I thought > > X86 was already selecting this. > > Doesn't look so - at least haven't found anything where it's > automatically selected on x86. OTOH, that wouldn't make much > sense to me - I somewhat doubt that x86 can't run w/o that. Sorry my bad. You should select this if you use it, but are you using the GPIO MMIO abstractions? The hallmark of those implementations are that they call bgpio_init() and this driver does not, and it seems with the funny layout of the registers it can't even use it anyway. > IMHO, dependencies should always be direct - indirect ones could > suddenly change in subtle ways. Agreed. > >> + priv->gc.owner = THIS_MODULE; > >> + priv->gc.parent = &pdev->dev; > >> + priv->gc.label = dev_name(&pdev->dev); > >> + priv->gc.base = priv->pdata->gpio_base; > > > > No please, use priv->gc.base = -1; > > Could I also leave that field untouched (IOW: =0) ? No unfortunately not, because 0 is a valid GPIO base. Yours, Linus Walleij
Powered by blists - more mailing lists