From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH] gpio: zynq: Setup chip->base based on alias ID Date: Thu, 26 Apr 2018 15:08:24 +0200 Message-ID: References: <6ee982f8eb6e07f9ecbb0cc5093152f4a16b9c31.1523454899.git.michal.simek@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <6ee982f8eb6e07f9ecbb0cc5093152f4a16b9c31.1523454899.git.michal.simek@xilinx.com> Sender: linux-kernel-owner@vger.kernel.org To: Michal Simek Cc: "linux-kernel@vger.kernel.org" , Michal Simek , Steffen Trumtrar , Peter Crosthwaite , "open list:GPIO SUBSYSTEM" , Rob Herring , Linux ARM List-Id: linux-gpio@vger.kernel.org On Wed, Apr 11, 2018 at 3:55 PM, Michal Simek wrote: Thanks for your patch! > In past Xilinx gpio-zynq driver was setting up gpio chip->base as 0 > which was chagned to autodetection when driver was upstreamed. Older > systems, which were using this old version, setup SW stack which expects > zynq gpio base as 0 and right now there is no way how to set this up. > > The patch is adding an option to setup chip->base based on aliases which > is something what some other drivers are doing too. > It means when gpio0 alias is setup then chip->base is 0. When gpio alias > is not setup gpiochip_find_base() set it up properly which is current > behavior. > > Signed-off-by: Michal Simek In general, we stopped any controlling of the GPIO base. Also this use would have to be OK with the DT maintainers as I never saw this use of alias before. Please describe the use case for this. 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. Yours, Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 From: linus.walleij@linaro.org (Linus Walleij) Date: Thu, 26 Apr 2018 15:08:24 +0200 Subject: [PATCH] gpio: zynq: Setup chip->base based on alias ID In-Reply-To: <6ee982f8eb6e07f9ecbb0cc5093152f4a16b9c31.1523454899.git.michal.simek@xilinx.com> References: <6ee982f8eb6e07f9ecbb0cc5093152f4a16b9c31.1523454899.git.michal.simek@xilinx.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Apr 11, 2018 at 3:55 PM, Michal Simek wrote: Thanks for your patch! > In past Xilinx gpio-zynq driver was setting up gpio chip->base as 0 > which was chagned to autodetection when driver was upstreamed. Older > systems, which were using this old version, setup SW stack which expects > zynq gpio base as 0 and right now there is no way how to set this up. > > The patch is adding an option to setup chip->base based on aliases which > is something what some other drivers are doing too. > It means when gpio0 alias is setup then chip->base is 0. When gpio alias > is not setup gpiochip_find_base() set it up properly which is current > behavior. > > Signed-off-by: Michal Simek In general, we stopped any controlling of the GPIO base. Also this use would have to be OK with the DT maintainers as I never saw this use of alias before. Please describe the use case for this. 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. Yours, Linus Walleij