linux-kernel - Re: [PATCH] gpiolib: fix chip->base handling in of_gpio_simple

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: <500E9D75.60002@gmail.com>
Date:	Tue, 24 Jul 2012 15:04:53 +0200
From:	Daniel Mack <zonque@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...ricsson.com>
Subject: Re: [PATCH] gpiolib: fix chip->base handling in of_gpio_simple_xlate()

Hi Arnd,

On 24.07.2012 14:56, Arnd Bergmann wrote:
> On Monday 23 July 2012, Daniel Mack wrote:
>> (Cc: Arnd)
>>
>> On 22.07.2012 19:10, Daniel Mack wrote:
>>> of_gpio_simple_xlate() is called for each chip when a GPIO is looked up.
>>> When registering several chips off the same DT node (with different pin
>>> offsets) however, the lookup fails as the GPIO number passed in to
>>> of_gpio_simple_xlate() is likely higher than the chip's ->ngpio value.
>>>
>>> Fix that by taking into account the chip's ->base value, and return the
>>> relative offset of the pin inside the chip.
>>>
>>> Signed-off-by: Daniel Mack <zonque@...il.com>
>>> Cc: Grant Likely <grant.likely@...retlab.ca>
>>> Cc: Linus Walleij <linus.walleij@...ricsson.com>
>>> ---
>>>
>>> I'm currently porting the PXA pieces over to DT, and stumbled over what
>>> looks like an obvious bug to me. Correct me if I'm mistaken, but I see
>>> no reason why one shouldn't be able to instanciate several GPIO chips
>>> from a single DT node.
> 
> But why would you do that? Both the "gpiochip" and its DT representation
> attempt to represent the hardware structure. If they don't match, then
> I'd assume one of them is wrong ;-)

Well, have a look at what's currently there in drivers/gpio/gpio-pxa.c.
There are several gpio_chips that are registered. On the DT side,
however, I would much like to present all GPIO line in one array, so the
numbers match the hardware documentation.

I prepared patches for all that and they work find, the only thing I
need to touch in the core for that is this minor detail.

> 
>>> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
>>> index d18068a..51bc232 100644
>>> --- a/drivers/gpio/gpiolib-of.c
>>> +++ b/drivers/gpio/gpiolib-of.c
>>> @@ -147,13 +147,13 @@ int of_gpio_simple_xlate(struct gpio_chip *gc,
>>>  	if (WARN_ON(gpiospec->args_count < gc->of_gpio_n_cells))
>>>  		return -EINVAL;
>>>  
>>> -	if (gpiospec->args[0] >= gc->ngpio)
>>> +	if (gpiospec->args[0] >= gc->ngpio + gc->base)
>>>  		return -EINVAL;
>>>  
>>>  	if (flags)
>>>  		*flags = gpiospec->args[1];
>>>  
>>> -	return gpiospec->args[0];
>>> +	return gpiospec->args[0] - gc->base;
>>>  }
>>>  EXPORT_SYMBOL(of_gpio_simple_xlate);
> 
> Where would that gc->base come from?

It is set up when the chips are initialized. Let's put it that way: why
would we have this ->base if it is practically unusable in devicetree
environments?

And In case ->base equals 0, this patch is a no-op anyway.


Thanks,
Daniel
--
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/