I see I might have missed this mail, sorry for that. On Thu, Apr 5, 2018 at 6:35 PM, Christian Lamparter <chunkeey@xxxxxxxxx> wrote: > On Montag, 2. April 2018 17:04:47 CEST Bjorn Andersson wrote: >> On Mon 02 Apr 05:10 PDT 2018, Christian Lamparter wrote: >> > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c >> > index 495432f3341b..258fa357d946 100644 >> > --- a/drivers/pinctrl/qcom/pinctrl-msm.c >> > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c >> > @@ -831,11 +831,22 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl) >> > return ret; >> > } >> > >> > - ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio); >> > - if (ret) { >> > - dev_err(pctrl->dev, "Failed to add pin range\n"); >> > - gpiochip_remove(&pctrl->chip); >> > - return ret; >> > + if (!is_of_node(pctrl->dev->fwnode)) { >> >> Afaict this still means that if I boot this kernel with yesterday's dtb >> (without gpio-ranges) I will not get any gpios. This isn't okay. > Ok, fair point. I drop this chunk. > >> @Linus, I count 24 callers of gpiochip_add_pin_range(). Is this >> suggestion reasonable? >> >> Can we make gpiochip_add_pin_range() check if there's already a >> gpio-range and return ok in some way? I think I replied in some other mail that I think we need to be backwards compatible and it's not too hard to do both. (Correct me if I'm wrong.) > Looks like Linus is currently really busy updating the gemini > target (a lot of work went into it) for OpenWrt. > <https://lists.openwrt.org/pipermail/openwrt-devel/2018-April/043752.html> > (Kinda funny, because I do help to maintain the apm821xx and the new > ipq40xx target over there.) Yeah it was more of a hobby, partly research for a lecture on maintaining old ARM systems and all dangerous aftermarket devices that is littering the world. Since I have noticed that the adoption of OpenWRT/LEDE goes far beyond routers and it is one of the most prevalent distributions that is existing in the IoT of darkness on the planet being the most deployed OS for bitcoin mining and being picked up for functional safety (such as automotive) because of its minimalist userspace. I'm still amazed by the weirdness of our business. > In any case, I implemented your suggestion and it does look reasonable. > The gpiolib already uses the gpio_offset as an ID of some sorts. For > now I went with a simple ID value check, but this could be extended to > a range/intersection check if necessary. But then again, let's not > overengineer it. Comments are welcome, I'll wait around till sometime > next week before I post v3. I'm going through my mailbox now, sorry for delays in feedback and review :( Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html