linux-kernel - Re: [PATCH 2/2] RFT: pinctrl: sirf: move sgpio lock into state container

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: <CAGsJ_4zEgwADkVzdFOHVgXbSmo13Y5SBMzssHA5D19rhdNSb2g@mail.gmail.com>
Date:	Sun, 25 May 2014 15:51:19 +0800
From:	Barry Song <baohua@...nel.org>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Barry Song <Baohua.Song@....com>,
	Linux GPIO List <linux-gpio@...r.kernel.org>,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>
Subject: Re: [PATCH 2/2] RFT: pinctrl: sirf: move sgpio lock into state container

2014-05-09 19:57 GMT+08:00 Linus Walleij <linus.walleij@...aro.org>:
> On Thu, May 1, 2014 at 2:40 PM, Barry Song <baohua@...nel.org> wrote:
>> 2014-04-24 5:16 GMT+08:00 Linus Walleij <linus.walleij@...aro.org>:
>
>>> Instead of referring to a global static variable for the sgpio
>>> locking, use the state container to contain the lock.
>>>
>>> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
>>
>> hi Linus, thanks! this looks very good only if we fix the
>> gpiochip_add_pin_range() failure in patch 1:
>>
>> [    0.231658] pinmux-sirf b0120000.pinctrl: initialized SIRFSOC pinmux driver
>> [    0.261200] bio: create slab <bio-0> at 0
>> [    0.268264] GPIO chip /axi/peri-iobg/pinctrl@...20000: could not
>> create pin range
>> [    0.276142] pinmux-sirf b0120000.pinctrl: could not add gpiochip pin range
>
> Hm! This may mean that the pin controller is not there at this point,
> so the pin controller needs to be probed first, before the gpiochip
> and its range is probed.
>
> What happens if you do this:

Linus, pinctrl has been probed by arch_initcall:
419 static int __init sirfsoc_pinmux_init(void)
420 {
421         return platform_driver_register(&sirfsoc_pinmux_driver);
422 }
423 arch_initcall(sirfsoc_pinmux_init);

so moving to device_initcall for gpio has nothing different.

>
> diff --git a/drivers/pinctrl/sirf/pinctrl-sirf.c
> b/drivers/pinctrl/sirf/pinctrl-sirf.c
> index 76502aab2cb1..ce7c3552398f 100644
> --- a/drivers/pinctrl/sirf/pinctrl-sirf.c
> +++ b/drivers/pinctrl/sirf/pinctrl-sirf.c
> @@ -950,7 +950,7 @@ static int __init sirfsoc_gpio_init(void)
>
>         return sirfsoc_gpio_probe(np);
>  }
> -subsys_initcall(sirfsoc_gpio_init);
> +device_initcall(sirfsoc_gpio_init);
>
>  MODULE_AUTHOR("Rongjun Ying <rongjun.ying@....com>, "
>         "Yuping Luo <yuping.luo@....com>, "
>
>
> Yours,
> Linus Walleij

-barry
--
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/