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] [day] [month] [year] [list]
Date:	Sat, 20 Sep 2014 14:56:48 +0900
From:	Alexandre Courbot <>
To:	Linus Walleij <>
Cc:	Mika Westerberg <>,
	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 Sat, Sep 20, 2014 at 2:48 AM, Linus Walleij <> wrote:
> On Fri, Sep 19, 2014 at 12:20 AM, Alexandre Courbot <> wrote:
>> On Tue, Sep 9, 2014 at 4:24 PM, Linus Walleij <> wrote:
>>> 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.
> OK. I'm ready to revisit the subject.
>> 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.
> Right.
>> 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 think the performance hit is acceptable, because this should
> not be on a hot path anyway. I would say go ahead with this refactoring.

Great! I will come with something once my holidays are over. It should
not be a complex change.

>> 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?
> Ummmmm I think that is an orthogonal thing, but honestly I'm
> not following the double-pointers thing, so I guess I need to see
> the patch.

Yes, this is completely orthogonal, and actually this won't be needed
if we decide to get rid of that array.
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