[PATCH v8 04/12] pinctrl: verify whether gpio chip overlapps range
linus.walleij at linaro.org
Fri Feb 15 04:06:18 EST 2013
On Thu, Feb 14, 2013 at 6:01 PM, Haojian Zhuang
<haojian.zhuang at linaro.org> wrote:
> On 14 February 2013 23:23, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Mon, Feb 11, 2013 at 6:10 PM, Haojian Zhuang
>> <haojian.zhuang at linaro.org> wrote:
>>> + * pinctrl_overlapped_gpio_range() - check if the GPIO chip of a certain GPIO
>>> + * pin is overlapped with gpio range.
>>> + * @gpio: gpio pin to check taken from the global GPIO pin space
>>> + *
>>> + * This function is complement of pinctrl_match_gpio_range(). If the return
>>> + * value of pinctrl_match_gpio_range() is NULL, this function could be used
>>> + * to check whether pinctrl device is ready or not. Maybe some GPIO pins
>>> + * don't have back-end pinctrl interface.
>>> + * If the return value is true, it means that pinctrl device is ready & the
>>> + * certain GPIO pin doesn't have back-end pinctrl device. If the return value
>>> + * is false, it means that pinctrl device may not be ready.
>>> + */
>>> +static bool pinctrl_overlapped_gpio_range(unsigned gpio)
>> The name of this function confuses me, can we name it something
>> Which is actually what you test, right?
> How about pinctrl_match_gpio_range_exclude_some_pins()?
Actually I get ever more confused by this patch, I just don't understand
Something will need to be expanded on here or I will be unable to
maintaine the code, sorry for being a slow learner...
By the way:
Nowaday the recommended practice is to register a GPIO chip,
then add ranges using gpiochip_add_pin_range() in the non-DT
case. Doesn't that create a race window when the above code will
not behave as expected, e.g. between registration of the gpio
chip, the pin controller and the ranges? I guess the code assumes
that *all* initialization is complete?
More information about the linux-arm-kernel