From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail56.out.titan.email (mail56.out.titan.email [209.209.25.162]) (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 C4696257AEC for ; Tue, 16 Dec 2025 09:52:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.209.25.162 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765878723; cv=none; b=SBrkva5q1r29BJwmhULcH1uKRan3i1zLFYNCeegiYp/a+/5HMig9jEiDPUNBg4llOdh+a72yjx8tMDQO/wDiNpzDUQjvr+CVCjyGN/5Okew3t1Odh3eQujHQ7Ofd4z6trnL/5lgnV+BSEHp7JAJ/Ay3U+isWlRuof66KZoLV5BM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765878723; c=relaxed/simple; bh=PUFAyyeMb5AhKlkBKg1drn56hj0vT5LMt3ZkgWpcO2k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DtietqCvUOqPConLpsethnEVViiKPfYDdZW2P7LiCk3xyxRO9Fo/SVLwS4qHN72mTAjo6vGTIew0/HWLUz6Or8lspWEW9Gw5DHUuWh69fwf0f/zlYdQgLc+QRlAQZll4VbpPhOCaoY1SUQWsq5oHrvslVYUBF4aLlqL6+4hHLR8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ziyao.cc; spf=pass smtp.mailfrom=ziyao.cc; dkim=pass (1024-bit key) header.d=ziyao.cc header.i=@ziyao.cc header.b=Fs2cDlqq; arc=none smtp.client-ip=209.209.25.162 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ziyao.cc Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziyao.cc Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ziyao.cc header.i=@ziyao.cc header.b="Fs2cDlqq" Received: from localhost (localhost [127.0.0.1]) by smtp-out.flockmail.com (Postfix) with ESMTP id 4dVsTY4YCtz9rxf; Tue, 16 Dec 2025 09:44:33 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=1CseB0MqoJFvzm74cS5sjzhEHKvHJ6oW75xDVjFAP74=; c=relaxed/relaxed; d=ziyao.cc; h=from:message-id:references:to:cc:mime-version:in-reply-to:date:subject:from:to:cc:subject:date:message-id:in-reply-to:references:reply-to; q=dns/txt; s=titan1; t=1765878273; v=1; b=Fs2cDlqqtQ92UMaZaq6QFCjOXdq9f098pKSoy74GgNMuyy0jvL8Dwh8djvRYJ/5VoR29LG/m CFvPfwXN/rO/yGNJ7nhFnEEQSx6jpalpXQeIMBGdJ+zTb5DaMDb2vGxNIIZuW8InnMpNbr6WNuS VtFE9n7NPS4wj+9nYZYhQT/8= Received: from pie (unknown [117.171.66.90]) by smtp-out.flockmail.com (Postfix) with ESMTPA id 4dVsTV0TfVz9rwn; Tue, 16 Dec 2025 09:44:29 +0000 (UTC) Date: Tue, 16 Dec 2025 09:44:26 +0000 Feedback-ID: :me@ziyao.cc:ziyao.cc:flockmailId From: Yao Zi To: Binbin Zhou , Binbin Zhou , Huacai Chen , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: Huacai Chen , Xuerui Wang , loongarch@lists.linux.dev, devicetree@vger.kernel.org Subject: Re: [PATCH 7/7] LoongArch: dts: loongson-2k1000: Fix i2c-gpio node names Message-ID: References: <9684ae4e58fd1e9768cccf6e3ae730eff46fb29c.1765778124.git.zhoubinbin@loongson.cn> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9684ae4e58fd1e9768cccf6e3ae730eff46fb29c.1765778124.git.zhoubinbin@loongson.cn> X-F-Verdict: SPFVALID X-Titan-Src-Out: 1765878273474105894.21635.4198284917602837240@prod-use1-smtp-out1003. X-CMAE-Score: 0 X-CMAE-Analysis: v=2.4 cv=a8/K9VSF c=1 sm=1 tr=0 ts=69412a01 a=rBp+3XZz9uO5KTvnfbZ58A==:117 a=rBp+3XZz9uO5KTvnfbZ58A==:17 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=CEWIc4RMnpUA:10 a=pGLkceISAAAA:8 a=nWqmHdOqKvjv4xVzHEUA:9 a=CjuIK1q_8ugA:10 a=0Om0YbJOx1jdy8GrVaHL:22 a=3z85VNIBY5UIEeAh_hcH:22 a=NWVoK91CQySWRX1oVYDe:22 On Tue, Dec 16, 2025 at 03:56:59PM +0800, Binbin Zhou wrote: > From: Binbin Zhou > > The binding wants the node to be named "i2c-number", alternatively > "i2c@address", but those are named "i2c-gpio-number" instead. > > Rename those to i2c-0, i2c-1 to adhere to the binding and suppress > dtbs_check warnings. I think this is an unintended breakage in dtschema upstream, but not really a violation. As I've mentioned in my original cover-letter, > which IMHO is a regression caused by dt-schema commit 57138f5b8c92 > ("schemas: i2c: Avoid extra characters in i2c nodename pattern"). Commit > 647181a1f8ff ("schemas: i2c: Allow for 'i2c-.*' node names") fails to > fix the case, as it doesn't take nodenames with multiple hyphens in > account. I'll start a separate series for this. So I think it should probably be fixed in dt-schema instead. i2c-gpio-X provides more information to me, and I don't think it causes any inconsistency or ambiguity. By the way, we also have dozens of arm dtb targets shipping nodes named like i2c-gpio-*, mostly microchip and st ones, fixing the regex in dtschema upstream will also eliminate warnings for them. Best regards, Yao Zi > Signed-off-by: Binbin Zhou > --- > arch/loongarch/boot/dts/loongson-2k1000.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/loongarch/boot/dts/loongson-2k1000.dtsi b/arch/loongarch/boot/dts/loongson-2k1000.dtsi > index fa1c000fd3e0..f70b245c8bc4 100644 > --- a/arch/loongarch/boot/dts/loongson-2k1000.dtsi > +++ b/arch/loongarch/boot/dts/loongson-2k1000.dtsi > @@ -46,7 +46,7 @@ cpuintc: interrupt-controller { > }; > > /* i2c of the dvi eeprom edid */ > - i2c-gpio-0 { > + i2c-0 { > compatible = "i2c-gpio"; > scl-gpios = <&gpio0 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > sda-gpios = <&gpio0 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > @@ -57,7 +57,7 @@ i2c-gpio-0 { > }; > > /* i2c of the eeprom edid */ > - i2c-gpio-1 { > + i2c-1 { > compatible = "i2c-gpio"; > scl-gpios = <&gpio0 33 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > sda-gpios = <&gpio0 32 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; > -- > 2.47.3 >