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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 Feb 2019 10:02:10 +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 Mon, Feb 11, 2019 at 11:46 AM Enrico Weigelt, metux IT consult
<lkml@...ux.net> wrote:
> On 08.02.19 15:25, Linus Walleij wrote:

> >> +/*>> + * struct amd_fch_gpio_reg - GPIO register definition>> + * @reg:
> register index>> + * @name: signal name>> + */>> +struct
> amd_fch_gpio_reg {>> +    int         reg;>> +    const char* name;>>
> +};> > Can't you put this in the driver file?
>
> I'm afraid, I can't. Because the board driver needs to tell the
> gpio driver which gpio's we actually have. This seems to be really
> board specific, and the register layout of the FCHs gpio bank seems
> to be not actually linear (or maybe the pin naming is just weird)
>
> What I really don't want is undocumented registers or lines being
> exposed as gpio somewhere (not knowing what they actually do).
> Therefore, I'd like to add only those gpio registers that I can
> confirm being safe - at least until I've managed to get more
> information.

What we normally do is expose all the lines from a gpio chip
as kernel abstraction.

This is because at least in theory this chip can be used by
several boards.

The chip abstraction does have facilities for masking off
unavailable lines: in struct gpio_chip there is .valid_mask
and even a callback .init_valid_mask() to set it up.

This is currently used on ACPI systems to mask off an
make unavailable lines that are handled by firmware/BIOS.

So this is what you should use to make existing lines
unavailable, do not try to hide them by not exposing
registers or line offsets. The abstraction should model
the hardware, not the usecase.

Imposing a restriction from a board is a new thing,
and would involve setting these masks somehow using
machine data from <linux/gpio/machine.h>,
I am sure we can figure something out if you absolutely
need this.

FYI there are tons of systems out there that expose a
whole range of GPIOs that the developer have no clue
where they are connected on the PCB, the most common
case is that they are not connected (sometimes not
even leaving the chip die) or go to test points. They are
very seldom dangerous, in fact I've never seen dangerous
GPIOs, just dangerous set-ups of pins already known
to be in use for something.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ