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=-0.7 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, URIBL_BLOCKED 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 82F7DC432BE for ; Wed, 28 Jul 2021 09:16:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4D7D560F9B for ; Wed, 28 Jul 2021 09:16:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4D7D560F9B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=CLzbciKsZCJs2309C+8FNc/V6gd+nXIEwIwaqpunMQw=; b=UnvmOIokL51Toa imijtnN6X2d4BFLto5ZVZLwLKxvc9INOEItRmFWj+Cg5o964aFOj7CYmrL5WoyWAFVVPV6hvMgake aw8OkE6O9+0C5anfZdJFebqS9i/Ja5ZTcTGcjTSErJvX1JhlrEaZRIExwgKXr5fmp5Op4lGNduG/K l3LIYJBS84ADXjIJ3m1EaEEmCvVTByRZA+SSocXl80vK2dniVHbsbsjxUw888WwvzuacqQkxTo7/o eURBN48KkDictE9MryUuGrvIjl6K4lvjd+ODXvbvGiTir5IvXhU0Z11m8SNIMHCIaX49ywbTqTLmP l0bHd0ARXfiETh9VRkxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8fe5-0007Ro-2s; Wed, 28 Jul 2021 09:14:33 +0000 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8fdH-00077T-T7 for linux-arm-kernel@lists.infradead.org; Wed, 28 Jul 2021 09:13:45 +0000 Received: by mail-pl1-x636.google.com with SMTP id c16so1894922plh.7 for ; Wed, 28 Jul 2021 02:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6m4UZEx/kYzeDD67ywCPsN6+L14vcm0XjCn8vgnR0gs=; b=iC6z8Qctytr3DWMW26XBlXyJXmcX9mHqtGYg7L6xD94wbl7ajzQi5zIilGaoIAsNBu ZN7L0JWLQB0NsyAQiW+JqWlOT1mTbK4f+uOaBNUne3qrnSByPi9LK4eaUGHE6oXAo+tw 7gXczYP9K2NW9xgp4RU0Wn0tG7xRBm8dvpW/t/+zJk+V0r1Lb6GZzxN+922cNAK3aV+j lKtMq4xZPZfiDze9gJjeELttGZiHW7K0jpIUX7aPHQVSLXgmQga/VBWMx7C7W9UDTxml zt0rZuogVBn8QhRnDgl2my8YDzXxJUe2Cy1wtm27Z5pRU6koXTuaHQgUeJXb1z/uUgVX Qrbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6m4UZEx/kYzeDD67ywCPsN6+L14vcm0XjCn8vgnR0gs=; b=KBbgZbSwMlNzBZSkjwobadyv6clfwd0bqRRITMO3t9Z+PdWZNwXRkHwVxhUKx1NTxK v3Yrurgp7zx61khiaJ580rDnO8hfA0qpZEAPoKHliNxDjpGIQWzO89DdfKOJV6/RBoUH S/qDg5aShcvq+TmxMK+dJ4bm2DIISAa08yOgYt62/oYsdixc98tCMI6EYS0/W3Y76Nnl IxAFPHsveddKazOappSMPK4yTD+Pny4rPVd7soPG4Hi6p3Qo9m61wuwaNj1w/zjy1h9H bwV8zwpUbKeIPQGCKUNfa4Oh4ixU9nsLDhQnmPd3brybW8Bt2FYavupMblaK5RG+9ldh BjVg== X-Gm-Message-State: AOAM533GgZHRwF9ZKKuDeGgiRYN1R5lHdGmicE+L+bqByFIIQmbFUNyK iQRGXt50dYAy8W+jYNgg6Cx7IOlUt+HSS/tzlYk= X-Google-Smtp-Source: ABdhPJyyR2mCT0pEZEhhVsDOslGMUTe+AfTMeNLSOODQi5iwax+TD6tMAXsYw27Coe070sKnGki21opJt2OQkPeCxzA= X-Received: by 2002:a17:902:ac90:b029:12c:e7a:c183 with SMTP id h16-20020a170902ac90b029012c0e7ac183mr14859743plr.21.1627463622505; Wed, 28 Jul 2021 02:13:42 -0700 (PDT) MIME-Version: 1.0 References: <20210723075858.376378-1-andrew@aj.id.au> In-Reply-To: From: Andy Shevchenko Date: Wed, 28 Jul 2021 12:13:06 +0300 Message-ID: Subject: Re: [RFC PATCH 0/6] leds: Fix pca955x GPIO pin mappings To: Andrew Jeffery Cc: "linux-leds@vger.kernel.org" , "linux-gpio@vger.kernel.org" , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Rob Herring , Joel Stanley , Pavel Machek , Linus Walleij , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210728_021343_994195_23329A98 X-CRM114-Status: GOOD ( 32.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Jul 28, 2021 at 8:43 AM Andrew Jeffery wrote: > On Fri, 23 Jul 2021, at 17:45, Andy Shevchenko wrote: > > On Friday, July 23, 2021, Andrew Jeffery wrote: > > > This series does a bunch of crimes, so it's an RFC. I'm cross-posting to the > > > pinctrl/GPIO and LEDs lists because the PCA955x devices impact all of them. What > > > needs fixing is the leds-pca955x driver's failure to map the GPIO numberspace to > > > the pin numberspace of the PCA955x devices. The series solves that by > > > implementing pinctrl and pinmux in the leds-pca955x driver. > > > > > > Things I'm unsure about: > > > > > > 1. Patch 1: The pinctrl_gpio_as_pin() API feels a bit dirty, not sure what > > > others thoughts are on that (Linus?). > > > > > > 2. Patch 2: I've added a new callback to hook the entirety of the pinctrl map > > > parsing rather than supplying a subnode-specific callback. This was necessary > > > to handle the PCA955x devicetree binding in a backwards compatible way. > > > > > > 3. Patch 4: The PCA955x devices don't actually have any pinmux hardware, but the > > > properties of the pinctrl/pinmux subsystems in the kernel map nicely onto the > > > problem we have. But it's quite a bit of code... > > > > > > 4. Patch 6: I also lost a bunch of time to overlooking the get_group_pins() > > > callback for pinctrl, and it seems odd to me that it isn't required. > > > > > > Please review! > > > > > > Sounds like a hack. > > Yes, possibly. Feedback like this is why I sent the series as an RFC. > > > I was briefly looking into patches 1-4 and suddenly > > realized that the fix can be similar as in PCA9685 (PWM), I.e. we > > always have chips for the entire pin space and one may map them > > accordingly, requested in one realm (LED) in the other (GPIO) > > automatically is BUSY. Or I missed the point? > > No, you haven't missed the point. I will look at the PCA9685 driver. > > That said, my goal was to implement the behaviour intended by the > existing binding (i.e. fix a bug). Okay, so it implies that this used to work at some point. What has changed from that point? Why can't we simply fix the culprit commit? > However, userspace would never have > got the results it expected with the existing driver implementation, so > I guess you could argue that no such (useful) userspace exists. Given > that, we could adopt the strategy of always defining a gpiochip > covering the whole pin space, and parts of the devicetree binding just > become redundant. I'm lost now. GPIO has its own userspace ABI, how does it work right now in application to this chip? -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel