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-next>] [day] [month] [year] [list]
Date:	Wed, 29 Oct 2014 10:41:19 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Ning Li <ning.li@...el.com>, Alan Cox <alan@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] gpio / ACPI: Add knowledge about pin controllers to acpi_get_gpiod()

On Fri, Oct 24, 2014 at 2:16 PM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:

> The GPIO resources (GpioIo/GpioInt) used in ACPI contain a GPIO number
> which is relative to the hardware GPIO controller. Typically this number
> can be translated directly to Linux GPIO number because the mapping is
> pretty much 1:1.
>
> However, when the GPIO driver is using pins exported by a pin controller
> driver via set of GPIO ranges, the mapping might not be 1:1 anymore and
> direct translation does not work.
>
> In such cases we need to translate the ACPI GPIO number to be suitable for
> the GPIO controller driver in question by checking all the pin controller
> GPIO ranges under the given device and using those to get the proper GPIO
> number.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>

I'm not sure what this patch does so I try to rely on you guys here.
I would strongly like to have Rafael's ACK before proceeding.

Trying to get the GPIO offsets to map 1:1 to Linux GPIO numbers
is something that should be avoided since we want to get rid of the
GPIO number space altogether. GPIO chips should try to register
with .base = -1 so that the gpiolib just assigns some random GPIO
numbers to the lines.

What does actually exist?

- GPIO offsets for a certain gpio_chip 0..N
- Pin offsets for a certain pin controller 0..N

GPIO ranges are for translating between these two.

But I have a vague idea that there is something like a numberspace
concept inside ACPI as well, and that is all magic to me...
mixing that into this is a bit scary to me.

> +#ifdef CONFIG_PINCTRL
> +/**
> + * acpi_gpiochip_pin_to_gpio_offset() - translates ACPI GPIO to Linux GPIO
> + * @chip: GPIO chip
> + * @pin: ACPI GPIO pin number from GpioIo/GpioInt resource

So I guess I'm curious about this Gpiolo/GpioInt resource number space...

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ