Message ID | 20240213080348.248916-1-s-vadapalli@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-63070-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp387754dyb; Tue, 13 Feb 2024 00:04:22 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWN4IJvXr+kZBpk5WupZXZwKKemBSl1cKdVuIryxEjaAt70hn/xC0OFQVbuczybQRKg1637FuouBPJK0ZCjYE0H4guCxA== X-Google-Smtp-Source: AGHT+IHMKoXmizS/BTlgvywLXMC8nL0UpA6lFZIp6RUitNHPTWMBrolEydEuWDNceX6iH1+j03qA X-Received: by 2002:a05:6358:724c:b0:178:9b51:b8e5 with SMTP id i12-20020a056358724c00b001789b51b8e5mr9634814rwa.24.1707811462347; Tue, 13 Feb 2024 00:04:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707811462; cv=pass; d=google.com; s=arc-20160816; b=xMHbUDCvFqYMbn4R+KmANdx/oblhZ3aFD5xpLwUwfLhVQITMDebYIEH1qhva9O57Ds nq775Stq1vyR/HIK3VUho4usfzxvmwaJ3GrgkSR/ozmjLMkpXQp+jZBCR11dHtXXEXR6 wzGXPxA6ODYJlGskF9kL1hxrV2YO4/SDFIjXLLUtKT3vGWK7g0s7iexGUgkJpvI+vLdT hDPLmM5HmaUPgG6vePY/HRMA8fohD2iZwzuJgYdbEizwyc70sERDcTTYkKWMrFlhpyld XVbHKr2GnQN24DiyQOGDHsos/tIUtOmQsHdA44KIabNBOotEIsaPYWYlJIAKgOU44zU2 v77A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=xFJdH5D8oRdeSN0w0kQ5lxzFXQwgpIsAFAk3dHwUpmA=; fh=e61Wom4ULCTmbzLCcaDFy0L2o3K8kTVkwIhO4+Dc9us=; b=wsBf/1yHETVm0mXkqgKAOMmpLX6EkcYvok0jtCFMN0HGPdqiklNh35BOJZzLmPZZ3w 6/fWrX87wN+H23aXpFuDpwJJrTCHZbHa0WIeAqvuMzk3EhGoQibWbOxNjKeEaLGWS98T 7e49zCEgjp8ed0X1IkjIHw1sA4WvKpi6JEbZSlnxotrliUpp9kKuNYP1m0c8xDUt3MRt C9f54O4A2dNeUwCOxEpsPjA9V3H6kNS+j24SFW1cEi28el3AkpxU2mgJU89jkS9ETcsM b4PEjBVd5kJELsfoAD7Vzr4JpRUOEfC4A+QHL+jOsomZMSlGxZUDSG6S4jXMcFI9ijwo pkuQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=S8Jho6AI; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-63070-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63070-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com X-Forwarded-Encrypted: i=2; AJvYcCUsJGBbS+XOh8XBCeO2BYKqXHdLkHiVRUZYuJ11wuXVvaGZLl9ev/MAoaduNqfuZxa5yZ+nPQIUHphTFVIycwp9JIWASw== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id lp19-20020a056a003d5300b006e0fdf2106asi432772pfb.329.2024.02.13.00.04.22 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 00:04:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-63070-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=S8Jho6AI; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-63070-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63070-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 16DED283E29 for <ouuuleilei@gmail.com>; Tue, 13 Feb 2024 08:04:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 07C701803D; Tue, 13 Feb 2024 08:04:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="S8Jho6AI" Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BED6182BE; Tue, 13 Feb 2024 08:04:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.19.142 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707811447; cv=none; b=rCoDer9pmhwagLOrpQLvsDpo4jrAmZc+I5guP+xblviGqrNPhze6pDRiqoTQx6n2WI1yDHxNyEFVUtbkcotx39wKeKJ1sQxQvKNPDxINLheYHoeNY9xsfnsEEykRsvhz/CDtQb9uR+oyiA2mwAdutV50TKbm9Mt+FWzzDtN7Ta0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707811447; c=relaxed/simple; bh=r1gw4eEHQDadsJ4+WMyRJ3mYkL3JPF57Rjxv9EGqEic=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=n3YsJYEPpswVpY5gM/UTqnDpd1eoPx1K7vulQYcLmB8yrd2UsNePw7gBYlA9OpKw87EIdjFHQToQq7fFfvIfDLPsgWW1+CP8QvyzTR+9b10XQEX2eFoOyCIOrI0auzVIxLOffQHCcmiIuUhPE9IesvR+oARaEb64lxxkgNGAf84= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=S8Jho6AI; arc=none smtp.client-ip=198.47.19.142 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 41D83rk4045006; Tue, 13 Feb 2024 02:03:53 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1707811433; bh=xFJdH5D8oRdeSN0w0kQ5lxzFXQwgpIsAFAk3dHwUpmA=; h=From:To:CC:Subject:Date; b=S8Jho6AIx7herkxOkD+g/1GB4m/qt12BCzXMK7yRYqtrSe8EVndRgF9ImbeDa8cks HoUIseMsQ9e790IFkZgOVwQqk0JK9LQhiG6HZkWDF17+cSjualeHcDGiaDMA3YITOy LRCBat0qbWVtI7rZPxwr3GjpfdqTa6S2voDV6RF8= Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 41D83r10118887 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 13 Feb 2024 02:03:53 -0600 Received: from DLEE113.ent.ti.com (157.170.170.24) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Tue, 13 Feb 2024 02:03:53 -0600 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Tue, 13 Feb 2024 02:03:53 -0600 Received: from uda0492258.dhcp.ti.com (uda0492258.dhcp.ti.com [172.24.227.9]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 41D83m6Q074348; Tue, 13 Feb 2024 02:03:49 -0600 From: Siddharth Vadapalli <s-vadapalli@ti.com> To: <nm@ti.com>, <vigneshr@ti.com>, <kristo@kernel.org>, <robh@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <peda@axentia.se>, <afd@ti.com>, <gregkh@linuxfoundation.org> CC: <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <c-vankar@ti.com>, <srk@ti.com>, <s-vadapalli@ti.com> Subject: [PATCH v5] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl Date: Tue, 13 Feb 2024 13:33:48 +0530 Message-ID: <20240213080348.248916-1-s-vadapalli@ti.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790770111978784214 X-GMAIL-MSGID: 1790770111978784214 |
Series |
[v5] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl
|
|
Commit Message
Siddharth Vadapalli
Feb. 13, 2024, 8:03 a.m. UTC
From: Chintan Vankar <c-vankar@ti.com> Change offset in mux-reg-masks property for serdes_ln_ctrl node since reg-mux property is used in compatible. Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon") Signed-off-by: Chintan Vankar <c-vankar@ti.com> Acked-by: Andrew Davis <afd@ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> --- Hello, This patch is based on linux-next tagged next-20240213. The v4 of this patch is a part of the series at: https://lore.kernel.org/r/20240131101441.1362409-1-c-vankar@ti.com/ Since the v4 series mentioned above has open comments on the other patches in the series, this patch is being posted separately to unblock other dependent series which rely on the fix implemented by this patch. Changes since v4: - Rebased patch on linux-next tagged next-20240213. Regards, Siddharth. arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Comments
Hi! 2024-02-13 at 09:03, Siddharth Vadapalli wrote: > From: Chintan Vankar <c-vankar@ti.com> > > Change offset in mux-reg-masks property for serdes_ln_ctrl node > since reg-mux property is used in compatible. > > Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon") > Signed-off-by: Chintan Vankar <c-vankar@ti.com> > Acked-by: Andrew Davis <afd@ti.com> > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> > --- > Hello, > > This patch is based on linux-next tagged next-20240213. > The v4 of this patch is a part of the series at: > https://lore.kernel.org/r/20240131101441.1362409-1-c-vankar@ti.com/ > > Since the v4 series mentioned above has open comments on the other > patches in the series, this patch is being posted separately to unblock > other dependent series which rely on the fix implemented by this patch. > > Changes since v4: > - Rebased patch on linux-next tagged next-20240213. > > Regards, > Siddharth. > > arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi > index 3cb964982792..3b7f0eca977b 100644 > --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi > @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 { > compatible = "reg-mux"; > reg = <0x00004080 0x30>; > #mux-control-cells = <1>; > - mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */ > - <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */ > - <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ > - <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */ > - <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ > - <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */ > + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ > + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ > + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ > + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ > + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ > + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ > idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, > <J784S4_SERDES0_LANE1_PCIE1_LANE1>, > <J784S4_SERDES0_LANE2_IP3_UNUSED>, Ouch. I suspect there is a similar problem in arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi: fss: bus@47000000 { compatible = "simple-bus"; reg = <0x0 0x47000000 0x0 0x100>; #address-cells = <2>; #size-cells = <2>; ranges; hbmc_mux: mux-controller@47000004 { compatible = "reg-mux"; reg = <0x00 0x47000004 0x00 0x2>; #mux-control-cells = <1>; - mux-reg-masks = <0x4 0x2>; /* HBMC select */ + mux-reg-masks = <0x0 0x2>; /* HBMC select */ }; Who knows what non-upstreamed devices and devicetrees are affected? I guess we need to revert 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon") unless someone sees a sane way to fix this. Cheers, Peter
On 2/13/24 3:19 AM, Peter Rosin wrote: > Hi! > > 2024-02-13 at 09:03, Siddharth Vadapalli wrote: >> From: Chintan Vankar <c-vankar@ti.com> >> >> Change offset in mux-reg-masks property for serdes_ln_ctrl node >> since reg-mux property is used in compatible. >> >> Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon") >> Signed-off-by: Chintan Vankar <c-vankar@ti.com> >> Acked-by: Andrew Davis <afd@ti.com> >> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> >> --- >> Hello, >> >> This patch is based on linux-next tagged next-20240213. >> The v4 of this patch is a part of the series at: >> https://lore.kernel.org/r/20240131101441.1362409-1-c-vankar@ti.com/ >> >> Since the v4 series mentioned above has open comments on the other >> patches in the series, this patch is being posted separately to unblock >> other dependent series which rely on the fix implemented by this patch. >> >> Changes since v4: >> - Rebased patch on linux-next tagged next-20240213. >> >> Regards, >> Siddharth. >> >> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi >> index 3cb964982792..3b7f0eca977b 100644 >> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi >> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi >> @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 { >> compatible = "reg-mux"; >> reg = <0x00004080 0x30>; >> #mux-control-cells = <1>; >> - mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */ >> - <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */ >> - <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ >> - <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */ >> - <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ >> - <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */ >> + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ >> + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ >> + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ >> + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ >> + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ >> + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ >> idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, >> <J784S4_SERDES0_LANE1_PCIE1_LANE1>, >> <J784S4_SERDES0_LANE2_IP3_UNUSED>, > > Ouch. I suspect there is a similar problem in > arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi: > > > fss: bus@47000000 { > compatible = "simple-bus"; > reg = <0x0 0x47000000 0x0 0x100>; > #address-cells = <2>; > #size-cells = <2>; > ranges; > > hbmc_mux: mux-controller@47000004 { > compatible = "reg-mux"; > reg = <0x00 0x47000004 0x00 0x2>; > #mux-control-cells = <1>; > - mux-reg-masks = <0x4 0x2>; /* HBMC select */ > + mux-reg-masks = <0x0 0x2>; /* HBMC select */ > }; > > Who knows what non-upstreamed devices and devicetrees are affected? > I guess we need to revert 2765149273f4 ("mux: mmio: use reg property > when parent device is not a syscon") unless someone sees a sane way > to fix this. There are only two in-tree nodes with "reg-mux" with a reg property: the one this patch fixes, and the hbmc_mux you point out, both in TI devices. I'd say it is safe to assume we are the only users, and our non-upstreamed DTs depend on that patch, reverting it would cause more issues for out-of-tree users than just fixing the two broken nodes above. Andrew > > Cheers, > Peter
On 24/02/13 11:08AM, Andrew Davis wrote: > On 2/13/24 3:19 AM, Peter Rosin wrote: > > Hi! > > > > 2024-02-13 at 09:03, Siddharth Vadapalli wrote: > > > From: Chintan Vankar <c-vankar@ti.com> > > > > > > Change offset in mux-reg-masks property for serdes_ln_ctrl node > > > since reg-mux property is used in compatible. > > > > > > Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon") > > > Signed-off-by: Chintan Vankar <c-vankar@ti.com> > > > Acked-by: Andrew Davis <afd@ti.com> > > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> > > > --- .. > > > + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ > > > + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ > > > + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ > > > + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ > > > + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ > > > + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ > > > idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, > > > <J784S4_SERDES0_LANE1_PCIE1_LANE1>, > > > <J784S4_SERDES0_LANE2_IP3_UNUSED>, > > > > Ouch. I suspect there is a similar problem in > > arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi: > > > > > > fss: bus@47000000 { > > compatible = "simple-bus"; > > reg = <0x0 0x47000000 0x0 0x100>; > > #address-cells = <2>; > > #size-cells = <2>; > > ranges; > > > > hbmc_mux: mux-controller@47000004 { > > compatible = "reg-mux"; > > reg = <0x00 0x47000004 0x00 0x2>; > > #mux-control-cells = <1>; > > - mux-reg-masks = <0x4 0x2>; /* HBMC select */ > > + mux-reg-masks = <0x0 0x2>; /* HBMC select */ > > }; > > > > Who knows what non-upstreamed devices and devicetrees are affected? > > I guess we need to revert 2765149273f4 ("mux: mmio: use reg property > > when parent device is not a syscon") unless someone sees a sane way > > to fix this. > > There are only two in-tree nodes with "reg-mux" with a reg property: the > one this patch fixes, and the hbmc_mux you point out, both in TI devices. > I'd say it is safe to assume we are the only users, and our non-upstreamed > DTs depend on that patch, reverting it would cause more issues for > out-of-tree users than just fixing the two broken nodes above. Peter, Is it alright for this patch to be merged, given Andrew's response above? The problem with "hbmc_mux" node that you pointed out above could be fixed by another patch. Please let me know. Regards, Siddharth.
On 2/15/24 10:56 PM, Siddharth Vadapalli wrote: > On 24/02/13 11:08AM, Andrew Davis wrote: >> On 2/13/24 3:19 AM, Peter Rosin wrote: >>> Hi! >>> >>> 2024-02-13 at 09:03, Siddharth Vadapalli wrote: >>>> From: Chintan Vankar <c-vankar@ti.com> >>>> >>>> Change offset in mux-reg-masks property for serdes_ln_ctrl node >>>> since reg-mux property is used in compatible. >>>> >>>> Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon") >>>> Signed-off-by: Chintan Vankar <c-vankar@ti.com> >>>> Acked-by: Andrew Davis <afd@ti.com> >>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> >>>> --- > ... > >>>> + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ >>>> + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ >>>> + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ >>>> + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ >>>> + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ >>>> + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ >>>> idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, >>>> <J784S4_SERDES0_LANE1_PCIE1_LANE1>, >>>> <J784S4_SERDES0_LANE2_IP3_UNUSED>, >>> >>> Ouch. I suspect there is a similar problem in >>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi: >>> >>> >>> fss: bus@47000000 { >>> compatible = "simple-bus"; >>> reg = <0x0 0x47000000 0x0 0x100>; >>> #address-cells = <2>; >>> #size-cells = <2>; >>> ranges; >>> >>> hbmc_mux: mux-controller@47000004 { >>> compatible = "reg-mux"; >>> reg = <0x00 0x47000004 0x00 0x2>; >>> #mux-control-cells = <1>; >>> - mux-reg-masks = <0x4 0x2>; /* HBMC select */ >>> + mux-reg-masks = <0x0 0x2>; /* HBMC select */ >>> }; >>> >>> Who knows what non-upstreamed devices and devicetrees are affected? >>> I guess we need to revert 2765149273f4 ("mux: mmio: use reg property >>> when parent device is not a syscon") unless someone sees a sane way >>> to fix this. >> >> There are only two in-tree nodes with "reg-mux" with a reg property: the >> one this patch fixes, and the hbmc_mux you point out, both in TI devices. >> I'd say it is safe to assume we are the only users, and our non-upstreamed >> DTs depend on that patch, reverting it would cause more issues for >> out-of-tree users than just fixing the two broken nodes above. > > Peter, > > Is it alright for this patch to be merged, given Andrew's response above? > The problem with "hbmc_mux" node that you pointed out above could be fixed > by another patch. Please let me know. The hbmc_mux fix is now also posted: https://lore.kernel.org/linux-arm-kernel/20240215141957.13775-1-afd@ti.com/ Andrew > > Regards, > Siddharth.
Hi Siddharth Vadapalli, On Tue, 13 Feb 2024 13:33:48 +0530, Siddharth Vadapalli wrote: > Change offset in mux-reg-masks property for serdes_ln_ctrl node > since reg-mux property is used in compatible. > > I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl commit: 9a0c0a9baa2d1f906589d715f9baeab93e7fcdcb All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git -- Vignesh
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi index 3cb964982792..3b7f0eca977b 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 { compatible = "reg-mux"; reg = <0x00004080 0x30>; #mux-control-cells = <1>; - mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */ - <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */ - <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ - <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */ - <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ - <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */ + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>, <J784S4_SERDES0_LANE2_IP3_UNUSED>,