On 03/14, Timur Tabi wrote: > On 03/14/2017 04:41 PM, Linus Walleij wrote: > > On Mon, Mar 6, 2017 at 10:52 PM, Timur Tabi <timur@xxxxxxxxxxxxxx> wrote: > > >> So would it be acceptable, for example, to change msm_gpio_set() such that > >> if the function of that pin is non-zero, just return an error? > > > > I would ask the driver maintainer about his opinion, and also whoever > > is an authority on ACPI for the TLMM-chips, I am no expert > > in ACPI. Hell I'm not even good at device tree. Not to mention SFI. > > Oh well... > > Well, I was hoping that Stephen would respond to this question. :-) > > My point is, if the driver knows that the GPIO cannot be written to (because > it's muxed to something else), shouldn't the driver return with an error if the > caller attempts to write? > (I reply faster when my name is written!) I don't see any problem with failing msm_gpio_set() when the function is "not gpio", but I also wonder why it matters. Drivers shouldn't be doing that, because if the gpio is muxed to some other functionality they shouldn't be treating it as a gpio in the first place. Perhaps we can have some sort of gpio validation debug option that the check goes under. Then we could fail and print a big warning if this happens, but if we aren't debugging then we don't do any checking and rely on drivers to do the right thing. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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