Messages in this thread | | | From | Linus Walleij <> | Date | Wed, 2 May 2018 12:10:32 +0200 | Subject | Re: [PATCH] gpio: zynq: Setup chip->base based on alias ID |
| |
On Thu, Apr 26, 2018 at 3:35 PM, Michal Simek <michal.simek@xilinx.com> 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
| |