On Thu, Apr 26, 2018 at 3:35 PM, Michal Simek <michal.simek@xxxxxxxxxx> wrote: >> The only use case which I can think about is userspace sysfs >> and then I would really like to know why these userspace >> users cannot use the character device that is nowadays >> supported by libgpiod and there is even patches for some >> IoT libraries to use it. The character device makes the >> GPIO Linux "base" irrelevant for userspace. >> >> GPIO sysfs is deprecated and moved to the obsolete ABI. >> >> If there are legacy applications that use this I would have >> to consider it, but since this has been -1 since the driver >> was merged I find that unlikely. > > Yes, it is about legacy application which I have seen recently and there > is no source code for application calls it because board vendor doesn't > provide it. > > You are right that -1 was used from the beginning in mainline but > unfortunately this driver was in vendor tree for a while and it uses 0 > there. > > In upstreaming this was changed to -1 but customers have a lot of code > which developed against vendor tree and they want to use > latest&greatest. And without this they are not able to run that > applications. > > I found that this logic is already in 5 drivers in mainline that's why I > send this patch to be +1. I see. Sadly comaptibility with out-of-tree driver code is none of our (community) business. We do pay a lot of effort not to break the ABI to userspace, but it needs to be an ABI coming from the mainline kernel, not from a vendor tree. So to the mainline kernel this is no regression. Yours, Linus Walleij -- 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