linux-kernel - Re: [PATCH 1/2] x86, gpio: Increase ARCH_NR

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 19 Sep 2014 16:20:22 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Ning Li <ning.li@...el.com>, Alan Cox <alan@...ux.intel.com>,
	Mark Brown <broonie@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH 1/2] x86, gpio: Increase ARCH_NR_GPIOs to 512

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 <linus.walleij@...aro.org> 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.

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/