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=-3.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3EFF3C433E1 for ; Wed, 26 Aug 2020 16:14:02 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 04CFE20825 for ; Wed, 26 Aug 2020 16:14:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RFlx3qAs"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mU5mHLFB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04CFE20825 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=r5coe0JIXkMR8s78751qOyarDgR4itpdL8SkqRBgCfM=; b=RFlx3qAsQ0kN0dU92cSANxVzn 3hfiCkWqWQPWowDiEGCaRTfXr4TtHVdRqpk1fDNdhPMNpACePeoa7AGuQ2WQiPob23qsvfovIUk/l QB7kZAKoUVxSAutJpRuRXUEkpuRdFmf8nAQzull+abWyg3bBoekDLbw6wY6ORMdCfbAW5vmqXQMLP zVTxBR2Qsp8T0pDxm1hzoBo2fQajGYxXUF2g/AAwbo5VPjAqwmfuiERzxe4Cup4OTJ7ZLJAjnY2U7 Uok3rZcS59xSj0A1hihx1fvjer+jQcU962Qduq2gzAnCJSy1Z6NQEGJS51dufzUsacP2iPK4cUX4n YAU5bB0/Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAy2K-0002aL-1F; Wed, 26 Aug 2020 16:12:32 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAy2H-0002Zg-CE for linux-arm-kernel@lists.infradead.org; Wed, 26 Aug 2020 16:12:30 +0000 Received: by mail-pl1-x644.google.com with SMTP id 10so1113758plg.8 for ; Wed, 26 Aug 2020 09:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vCC6VIFL/8vbneGa9TCjtGewPaPoIkGUkGSrSp6SBYo=; b=mU5mHLFBrcL9FdlRJXV9jmQ7l9CKe5sTWfuDpXyIsG9XMqa5OcqzzjHQO/QOPY36DG gbA0EpMvlFVHU977sKx0d62vlrUbcRnqo8G4zbC3jrNfSRj5qNIcmJ0Xn3PW1lD9Up7B TKpSzrOZBMsUz0FQ5gnnkWDvLlWKQ/IXSYppCGC/wcaIyPwt6kBHXIkRMIfyyoXc3RTM TQVmRfZMRPJyNlLLyujTPMoCkWoeinnBXUj9ZnfJRTOphjAphQWnx8K8KXmGmDTb9SNT bJaTli1KLZul4XhVsV1H3JESdakCzAcAYSsAHPR80BfHKk2vx9Yn7i5dpu/WRKe65w7x 6x7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vCC6VIFL/8vbneGa9TCjtGewPaPoIkGUkGSrSp6SBYo=; b=OL8KvPmS9054yS/X2CQFDLQpavDuSTSNVFLfKk9FZNUgtPQKWwfVH9PWo1RmBA/zr4 4k5Ou4OvzrnFNxGExPWO7Rjw8GsUI6JMUiolStSlrO3L7jssTPNwLtwKWrb+oI+LMa6G 40rwQFIVQ3yODyA+07IUtG4i2yi6CdRr0A0CawVGmZwE7OmTwCM1lH2QdgVeV8dZ45ug nB4y7yl+tsCK7dXpROzGIYpSQtY/KsYA3L1+1f7m7V0yZeZ9GwCmSjOA25qb4VBC06Pn JqsA8qeje+Mb4mY5U1Lh4J9g+hAfHU5pT+11cBEq2742IkRxB2abvQzhESH5DMo/qZkL Vq2A== X-Gm-Message-State: AOAM530LYB/Jf+pg8wpicsU6ar+i+AgJNfD+CoLjq2AsU2JXAUQy72Iw RDPPAZMN6LsoBrKB+MnpKRM= X-Google-Smtp-Source: ABdhPJyhmcLJ1YQ8U2/6jG0tg/PsMPw8FeQRjej1dJ1/x8O375Ov5EU269+O2J2jB2V4gxy9yn8P0w== X-Received: by 2002:a17:90a:c715:: with SMTP id o21mr6510642pjt.41.1598458345412; Wed, 26 Aug 2020 09:12:25 -0700 (PDT) Received: from dtor-ws ([2620:15c:202:201:a6ae:11ff:fe11:fcc3]) by smtp.gmail.com with ESMTPSA id q25sm3452093pfn.181.2020.08.26.09.12.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Aug 2020 09:12:24 -0700 (PDT) Date: Wed, 26 Aug 2020 09:12:22 -0700 From: Dmitry Torokhov To: Heikki Krogerus Subject: Re: [PATCH 0/5] Make gpio_keys accept board descriptors Message-ID: <20200826161222.GA1665100@dtor-ws> References: <20171124093045.5961-1-linus.walleij@linaro.org> <20171125233324.afdt4netamvkrkm2@dtor-ws> <20200826143543.GC813478@kuha.fi.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200826143543.GC813478@kuha.fi.intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200826_121229_429009_5EC10F97 X-CRM114-Status: GOOD ( 35.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linus Walleij , Linux ARM , Linux Input Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 26, 2020 at 05:35:43PM +0300, Heikki Krogerus wrote: > On Wed, Aug 26, 2020 at 03:20:14PM +0200, Linus Walleij wrote: > > Hi Dmitry, > > > > On Sun, Nov 26, 2017 at 12:33 AM Dmitry Torokhov > > wrote: > > > On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote: > > > > > > The goal I'm working toward is to rid the kernel of the global > > > > GPIO numberspace. > > > > > > > > This means GPIO lines should be references by the local offset > > > > on the GPIO chip. > > > > > > > > This patch set starts to move gpio_keys toward using GPIO > > > > look-up tables instead of global GPIO numbers to find their > > > > GPIOs. > > > > > > > > As an example I did (I think) the necessary patches to > > > > convert DaVinci and i.MX to use this. There are several users > > > > also x86 platform devices. > > (...) > > > I think this is a worthy goal, but I wonder if we could get static GPIO > > > descriptors work with fwnode_get_named_gpiod() so we could retire the > > > platform data parsing altogether. We'd need to extend static device > > > properties to have notion of children though. > > > > Do we have this now? I've looked at Heikki's et al work > > on software nodes but I cannot see whether we are there now. > > > > We have fwnode_create_software_node() and friends, but > > I haven't seen if this can be used with input and GPIO descriptors > > are still a bit on the side. I can create a lot of properties but > > not really add a descriptor table as a software node as far as > > I can tell. I'm also a bit lost on whether it will be possible > > to get there sadly :/ > > I'm sorry but I'm not completely sure what is this about? Are software > nodes still missing something that would prevent us from for example > using them to describe the GPIO information exactly the same way it is > described in DT? I don't know if that is what we want, but I'm just > trying to understand what is still missing? Dmitry? No, my changes to improve the fwnode handling of references have landed, a while ago, so now I need to refresh the series of patches to gpiolib I was working on around Plumbers time last year. Linus seemed mostly OK with them, so it just a matter of finding time and picking this up again. Thanks. -- Dmitry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel