On Fri, Nov 28, 2014 at 6:00 PM, Haojian Zhuang <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
