On 2014/12/1 21:59, Linus Walleij wrote: > On Fri, Nov 28, 2014 at 6:00 PM, Haojian Zhuang > <haojian.zhuang@xxxxxxxxxx> wrote: > >> It's a bit different. >> >> The commit 51e13c2475 is used to fix this scenario. There're 8 gpio >> pins in GPIO CHIP #19. There're pin muxing on gpio152 - >> gpio155. And there're _no_ pin muxing on gpio156 - gpio159. When >> user tries to request gpio159, he'll meet failure since the pinctrl device >> can't cover gpio159. But the pinctrl device is already register for >> gpio152. In order to distinguish whether the pinctrl device registered, >> I added pinctrl_ready_for_gpio_range(gpio). >> >> In another scenario, there's no back-end pinctrl device for GPIO >> CHIP #0. So pinctrl_request_gpio() always returns EPROBE_DEFER. >> The commit 51e13c2475 can't cover this. >> >> I suggest to write code in below. > This looks much simpler. Anyway: Xinwei whatever you come up > with, include Haojian on To: and get is ACK on the solution. > > Yours, > Linus Walleij > hi Linus: two patches slove the same problem about GPIO PL061. You can understand our patches and merge it in the next kernel version while ensuring that others use the kernal will not meet with our problem. Because this bug spend too much time to debug our board. I will be glad to reduce the kernel bug and help others. yours Xinwei -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html