From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8562FC433E0 for ; Tue, 7 Jul 2020 10:04:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6028420708 for ; Tue, 7 Jul 2020 10:04:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b="PXysaG3X" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727090AbgGGKEJ (ORCPT ); Tue, 7 Jul 2020 06:04:09 -0400 Received: from smtpcmd14161.aruba.it ([62.149.156.161]:39660 "EHLO smtpcmd14161.aruba.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726467AbgGGKEI (ORCPT ); Tue, 7 Jul 2020 06:04:08 -0400 X-Greylist: delayed 427 seconds by postgrey-1.27 at vger.kernel.org; Tue, 07 Jul 2020 06:04:07 EDT Received: from [192.168.1.129] ([93.146.66.165]) by smtpcmd14.ad.aruba.it with bizsmtp id 09wx2300z3Zw7e5019wyCE; Tue, 07 Jul 2020 11:56:59 +0200 Subject: Re: [RFC] GPIO User I/O To: Geert Uytterhoeven Cc: Linus Walleij , Geert Uytterhoeven , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski , Rob Herring , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <01afcac0-bd34-3fd0-b991-a8b40d4b4561@enneenne.com> <1c4f1a83-835a-9317-3647-b55f6f39c0ba@enneenne.com> <87efe96c-3679-14d5-4d79-569b6c047b00@enneenne.com> From: Rodolfo Giometti Message-ID: Date: Tue, 7 Jul 2020 11:56:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1594115819; bh=iMxzmbAXPORie8pkdG5YzxTMnrq/UBvG98R/J9x/Zgo=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=PXysaG3XMcA3HoMihAJhEede4iaDg8Oa1xrq/8tpYb9MhHbvO47WVbkI5coxEiX+8 KyYKeMkVLIARfKCn9bAP/PfKJe1UjiIHT88BmUdN3Zrkh4lxIVLZrCm0LL+0qH99+f PuKfdBMt1700JYiBPabJZvJGyVtQzIT6+dOQ8ueWxxRwxaCB2NnmnRmCxJCDSx/d8F bgAWCrXoyOZJkX5Twi6UD+IRRZXsmpl+rRl77Tyl6J9aqyFJEoIgGvL2LzgxDVN/Qh 2+ZWMDGTHOncdUWuzMsQUFLGzr//oMlfKO8vazmQCn0MQyM5/DwYGldcLOdTN3MptR fArYo77cL1HPg== Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 07/07/2020 09:41, Geert Uytterhoeven wrote: > Hi Rodolfo, > > CC devicetree > > On Tue, Jul 7, 2020 at 9:17 AM Rodolfo Giometti wrote: >> On 06/07/2020 23:00, Geert Uytterhoeven wrote: >>> On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij wrote: >>>> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti wrote: >>>>>> With Geert's GPIO aggregator userspace and device tree can conjure >>>>>> special per-usecase gpio chips as pointed out by Drew: this is >>>>>> very useful when you want some kernel-managed yet >>>>>> usecase-specific GPIO lines in a special "container" chip. >>>>>> To me this is the best of two worlds. (Kernelspace and userspace.) >>>>> >>>>> Maybe this is the "best of two worlds" as you say but the problem is that board >>>>> manufactures need a way to well-define how a GPIO line must be used for within >>>>> the device-tree and without the need of patches! In this point of view neither >>>>> the "driver_override" way nor adding a compatible value to >>>>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each >>>>> board!). That's why at the moment they prefer not specify these GPIO lines at >>>>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it >>>>> simple... >>>> >>>> I think the idea is to add a very generic DT compatible to the >>>> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator >>>> to create a new chip with named lines etc. >>>> >>>> But Geert can speak of that. >>> >>> The idea is to describe the real device in DT, and add it's compatible value >>> to gpio_aggregator_dt_ids[], or enable support for it dynamically using >>> driver_override. >>> The former indeed requires modifying the driver. >> >> I see. >> >>> Note that if you ever want to write a pure kernelspace driver, you do need >>> a proper compatible value anyway. >> >> OK, but for our purposes we need just one compatible value. >> >>> I do agree that it's annoying to have "gpio-leds", but not "gpio-motors" >>> or "gpio-relays". However, you can always propose bindings for the >>> latter, and, when they have been accepted, add those compatible >>> values to upstream gpio_aggregator_dt_ids[]. >> >> Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as >> in my solution would be suffice. However, after these discussions, are there any >> chances my patch (with needed modifications and documentation) may be accepted? :) >> >> Thanks for your time and answers. > > Let's ask the DT people... I think I need an OK from GPIO SUBSYSTEM's maintainers first... Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti