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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 9 Sep 2014 12:46:44 +0300
From:	Mika Westerberg <>
To:	Linus Walleij <>
Cc:	Alexandre Courbot <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>,,
	Ning Li <>, Alan Cox <>,
	Mark Brown <>,
	"" <>,
	"" <>
Subject: Re: [PATCH 1/2] x86, gpio: Increase ARCH_NR_GPIOs to 512

On Tue, Sep 09, 2014 at 09:24:59AM +0200, Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 1:47 PM, Mika Westerberg
> <> wrote:
> > Some newer Intel SoCs like Braswell already have more than 256 GPIOs
> > available so the default limit is exceeded. In order to support these add
> > back the custom GPIO header with limit of 512 GPIOs for x86.
> >
> > Signed-off-by: Mika Westerberg <>
> Argh! This is the kind of stuff I want to get rid of ....
> Preferably gpio should be a subsystem without a lot of hooks all over
> the place with arch-specific modifications for this and that, including
> the max number of GPIOs.
> I would actually prefer if you bump the value in
> include/asm-generic/gpio.h to 512 over this.

OK, this makes sense and I can do the change for the next revision of
the patch.

> But better still, now that we have descriptors etc would be to define
> some new per-arch selectable config option like
> core to use something like a radix tree to store and retrieve
> descriptors.
> I.e. in drivers/gpio/gpiolib.c get rid of this:
> static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
> Replace it with a radix tree of descriptors.
> This however makes it *impossible* to use things like desc_to_gpio()
> and/or gpio_to_desc() so the code has to be augmented all over the
> place to avoid any uses of GPIO numbers on that architecture,
> but I am sure it *can* be done on pure ACPI or device tree
> systems, and that's what we should aim for.
> Comments?

That's a rather big rework to the GPIO subsystem and its users. I agree
that it should be the goal eventually. For x86 such conversion is not
that simple because we have systems out there that have neither ACPI nor
DT available.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists