Message ID | 20230206203720.1177718-1-horatiu.vultur@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2452468wrn; Mon, 6 Feb 2023 12:46:13 -0800 (PST) X-Google-Smtp-Source: AK7set9rezPUMv0FTicJzHNrxliaR4VtcrJ++UWArb0s/ErpUcFP9SsH7xpn+D6zQ8AXCUthAypl X-Received: by 2002:a17:906:c7ce:b0:8a0:7158:15dc with SMTP id dc14-20020a170906c7ce00b008a0715815dcmr614068ejb.74.1675716373465; Mon, 06 Feb 2023 12:46:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675716373; cv=none; d=google.com; s=arc-20160816; b=eAaRi8jAxGIsRf/w5XVCpKYuJWkPXU8en4OdElYe2swvep1TH2FslLCBUPDJutBkkb N5ec1rutYlEhcl4hJQpSf03s3Qwi3GpuXtlI0657qfZaEf1dFLIUKNpLoKf0jusoOm6B 0uTk/uS/mVnPseK9a26fwvFyz92wVRIh/qhE6fv+ykupaBz7S+onnsC/ClShd37RjYRf efTDa3pK8POA6qXrvuJh8QiEnduKyWV4MNlch3gk3/IaSG/sSYP80ufRNzMmqi+2BLNX jsrAhwKCrCgkUA6TMWQ3aCAAvkh3gIjRJWM68VcjOtGhehR0SkchtIGzMVlIEzI7/qQq LzTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=AKs0MOT/dmm48bunhZ/c7jUlJr74x7KATWeOSgt3uEM=; b=q66gRPP+U+Bapdo6X6Nkzd7ox8ltXrt3ZiHyPO/IBpnN81NozUrYYT0vc/njv7GW8F 2LB6YVbv8O32H5e7HrYeEPH7hJK2kmmG6w8DemriWcZIx5WCkrQX1lsq+Y4y7QRkoMBh inj9LjFelk30OY5b2LtfzD+9DwDO/dAeSD0ngMn9I0WWSTo7dXrz5gjx+VUY18nJQVhC 58kvO494pRzd8pGA2aIHcDerIeFEnUAwqJ3XmiVMJDCwiGTIApfWuoNfk328MiNBaCIg sFP8xmlqidGLdUsUkwUjRTbudO/DNmxEb92PouB7wmtVl+E0zWJYFLVjnpS5YqJS0fmR OA5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=V29em4zN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v1-20020aa7cd41000000b004aab3450a00si4008816edw.498.2023.02.06.12.45.48; Mon, 06 Feb 2023 12:46:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=V29em4zN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230286AbjBFUhz (ORCPT <rfc822;kmanaouilinux@gmail.com> + 99 others); Mon, 6 Feb 2023 15:37:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230266AbjBFUhx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Feb 2023 15:37:53 -0500 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FFFC30F4; Mon, 6 Feb 2023 12:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1675715871; x=1707251871; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=CS/vfAX5/Ot+oMAZ0EEUA8Xr6RUbaTmuRhID/hDbHrM=; b=V29em4zNrFSFOAk9yoacmCcL6xfq8/rLV1lLmjCGpjvzKEOUmaX0/Kks jECCO30dUY+MglF9uy+Ft9ivVQKUsUwFbu/VdQN59zA9D+x0yzhgm4yZr 9NzOHAWnoRoaX7+yuvTqgUoR8PtQj4Tsh4MBXHb1zyrKu+TGqZXi2q8lG LMuNdGKauh739zINhKJLqXfU93is0OKZT0N0v3u+MCIltw4YpvcyiWk5P PWYd4UWKVb+bbMVFPNGmzOvBh+acLFODdxc3VhTrOtwZTAB73ivo2UoyY 48WK3qui38uTaLPKSHDjn/5O5YFLVGdDh+YLaC2GuVh/QcTmGE6F684E7 Q==; X-IronPort-AV: E=Sophos;i="5.97,276,1669100400"; d="scan'208";a="199188691" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa2.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 06 Feb 2023 13:37:49 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Mon, 6 Feb 2023 13:37:48 -0700 Received: from soft-dev3-1.microsemi.net (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.2507.16 via Frontend Transport; Mon, 6 Feb 2023 13:37:46 -0700 From: Horatiu Vultur <horatiu.vultur@microchip.com> To: <linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <linus.walleij@linaro.org>, <alexandre.belloni@bootlin.com>, <andy.shevchenko@gmail.com>, Horatiu Vultur <horatiu.vultur@microchip.com> Subject: [PATCH] pinctrl: ocelot: Fix alt mode for ocelot Date: Mon, 6 Feb 2023 21:37:20 +0100 Message-ID: <20230206203720.1177718-1-horatiu.vultur@microchip.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757115971798257784?= X-GMAIL-MSGID: =?utf-8?q?1757115971798257784?= |
Series |
pinctrl: ocelot: Fix alt mode for ocelot
|
|
Commit Message
Horatiu Vultur
Feb. 6, 2023, 8:37 p.m. UTC
In case the driver was trying to set an alternate mode for gpio
0 or 32 then the mode was not set correctly. The reason is that
there is computation error inside the function ocelot_pinmux_set_mux
because in this case it was trying to shift to left by -1.
Fix this by actually shifting the function bits and not the position.
Fixes: 4b36082e2e09 ("pinctrl: ocelot: fix pinmuxing for pins after 31")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
---
drivers/pinctrl/pinctrl-ocelot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Feb 6, 2023 at 10:37 PM Horatiu Vultur <horatiu.vultur@microchip.com> wrote: > > In case the driver was trying to set an alternate mode for gpio > 0 or 32 then the mode was not set correctly. The reason is that > there is computation error inside the function ocelot_pinmux_set_mux > because in this case it was trying to shift to left by -1. > Fix this by actually shifting the function bits and not the position. > > Fixes: 4b36082e2e09 ("pinctrl: ocelot: fix pinmuxing for pins after 31") > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> ... > regmap_update_bits(info->map, REG_ALT(0, info, pin->pin), > BIT(p), f << p); > regmap_update_bits(info->map, REG_ALT(1, info, pin->pin), > - BIT(p), f << (p - 1)); > + BIT(p), (f >> 1) << p); I'm not sure I understand how this doesn't break anything that has a bit 0 set in f. Is it not a problem?
The 02/06/2023 22:59, Andy Shevchenko wrote: Hi Andy, > > On Mon, Feb 6, 2023 at 10:37 PM Horatiu Vultur > <horatiu.vultur@microchip.com> wrote: > > > > In case the driver was trying to set an alternate mode for gpio > > 0 or 32 then the mode was not set correctly. The reason is that > > there is computation error inside the function ocelot_pinmux_set_mux > > because in this case it was trying to shift to left by -1. > > Fix this by actually shifting the function bits and not the position. > > > > Fixes: 4b36082e2e09 ("pinctrl: ocelot: fix pinmuxing for pins after 31") > > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > ... > > > regmap_update_bits(info->map, REG_ALT(0, info, pin->pin), > > BIT(p), f << p); > > regmap_update_bits(info->map, REG_ALT(1, info, pin->pin), > > - BIT(p), f << (p - 1)); > > + BIT(p), (f >> 1) << p); > > I'm not sure I understand how this doesn't break anything that has a > bit 0 set in f. Is it not a problem? I don't think it is a problem. This is similar to the implementation of 'lan966x_pinmux_set_mux', the only difference is that lan966x_pinmux_set_mux has more GPIOs than ocelot. If we take an example where f equals 0x1 and p equals 0. REG_ALT(0): BIT(0) & (0x1 << 0) equals 0x1 REG_ALT(1): BIT(0) & ((0x1 >> 1) << 0)) equals 0x0. Or am I misunderstood something? > > -- > With Best Regards, > Andy Shevchenko
The 02/07/2023 08:48, Horatiu Vultur wrote: > The 02/06/2023 22:59, Andy Shevchenko wrote: Hi, Just a gentle ping about this patch. I don't see anything that I should do, please let me know otherwise. Thanks. > > Hi Andy, > > > > > On Mon, Feb 6, 2023 at 10:37 PM Horatiu Vultur > > <horatiu.vultur@microchip.com> wrote: > > > > > > In case the driver was trying to set an alternate mode for gpio > > > 0 or 32 then the mode was not set correctly. The reason is that > > > there is computation error inside the function ocelot_pinmux_set_mux > > > because in this case it was trying to shift to left by -1. > > > Fix this by actually shifting the function bits and not the position. > > > > > > Fixes: 4b36082e2e09 ("pinctrl: ocelot: fix pinmuxing for pins after 31") > > > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > > > ... > > > > > regmap_update_bits(info->map, REG_ALT(0, info, pin->pin), > > > BIT(p), f << p); > > > regmap_update_bits(info->map, REG_ALT(1, info, pin->pin), > > > - BIT(p), f << (p - 1)); > > > + BIT(p), (f >> 1) << p); > > > > I'm not sure I understand how this doesn't break anything that has a > > bit 0 set in f. Is it not a problem? > > I don't think it is a problem. This is similar to the implementation of > 'lan966x_pinmux_set_mux', the only difference is that > lan966x_pinmux_set_mux has more GPIOs than ocelot. > > If we take an example where f equals 0x1 and p equals 0. > REG_ALT(0): BIT(0) & (0x1 << 0) equals 0x1 > REG_ALT(1): BIT(0) & ((0x1 >> 1) << 0)) equals 0x0. > > Or am I misunderstood something? > > > > > -- > > With Best Regards, > > Andy Shevchenko > > -- > /Horatiu
On Mon, Feb 6, 2023 at 9:37 PM Horatiu Vultur <horatiu.vultur@microchip.com> wrote: > In case the driver was trying to set an alternate mode for gpio > 0 or 32 then the mode was not set correctly. The reason is that > there is computation error inside the function ocelot_pinmux_set_mux > because in this case it was trying to shift to left by -1. > Fix this by actually shifting the function bits and not the position. > > Fixes: 4b36082e2e09 ("pinctrl: ocelot: fix pinmuxing for pins after 31") > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Patch applied for fixes. Yours, Linus Walleij
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c index 29e4a6282a641..1dcbd0937ef5a 100644 --- a/drivers/pinctrl/pinctrl-ocelot.c +++ b/drivers/pinctrl/pinctrl-ocelot.c @@ -1204,7 +1204,7 @@ static int ocelot_pinmux_set_mux(struct pinctrl_dev *pctldev, regmap_update_bits(info->map, REG_ALT(0, info, pin->pin), BIT(p), f << p); regmap_update_bits(info->map, REG_ALT(1, info, pin->pin), - BIT(p), f << (p - 1)); + BIT(p), (f >> 1) << p); return 0; }