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:	Fri, 19 Sep 2014 13:46:57 +0300
From:	Mika Westerberg <>
To:	Alexandre Courbot <>
Cc:	Linus Walleij <>,
	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 Fri, Sep 19, 2014 at 04:20:22PM +0900, Alexandre Courbot wrote:
> I should have responded to that thread long ago, but I am currently on
> holidays and strangely tend to check my mail less often than I should.
> :P
> On Tue, Sep 9, 2014 at 4:24 PM, Linus Walleij <> wrote:
> > 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.
> >
> > But better still, now that we have descriptors etc would be to define
> > some new per-arch selectable config option like
> > CONFIG_ONLY_DYNAMIC_GPIO that changes the GPIO
> > 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.
> desc_to_gpio()/gpio_to_desc() could still work even if we remove the
> big array of GPIO descriptors. Actually that's what I intended to do
> when I first submitted the gpiod patches some time ago but it was
> rejected for performance reasons.
> desc_to_gpio() actually doesn't even access this array - it does its
> job using the chip base and the beginning address of its descriptors
> array.
> gpio_to_desc() would suffer a performance hit. What I initially
> proposed was to parse the linked list of GPIO chips and check if the
> requested number is in their assigned range. This is obviously slower
> than accessing an array, but if we consider that we generally don't
> have too many GPIO chips on a given hardware I don't think the hit
> would be that bad. It would also give some incentive for people to
> move to the gpiod interface.

>From what I can tell based on x86 based systems, there is typically only
one GPIO controller in the PCH/SoC that controls all the pins. A good
example is the Braswell/Cherryview controller.

So I agree with you that the performance hit would be negliglible.

> I also have a patch in my queue that enables multiple users on the
> same GPIO descriptor (something requested since some time already).
> What happens with it is that descriptors ownership is fully
> transferred to the gpio_chip instances, and the static array becomes a
> array of double-pointers, making it considerable smaller and reducing
> the impact of increasing its size. Maybe I should submit that change
> just for this case?

Go for it :)

I can try to assist if any testing is needed.
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