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]

Message-ID: <CACRpkdYbmcxi=BXEyGzLpxN4omt+v_Cg_BxCiN4vS9ZUwYTLzQ@mail.gmail.com>
Date:	Fri, 19 Sep 2014 10:48:01 -0700
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Alexandre Courbot <gnurou@...il.com>
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

On Fri, Sep 19, 2014 at 12:20 AM, Alexandre Courbot <gnurou@...il.com> wrote:
> On Tue, Sep 9, 2014 at 4:24 PM, Linus Walleij <linus.walleij@...aro.org> 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.

> 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.

Yours,
Linus Walleij
--
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/