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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id CA1A5FCC05A for ; Fri, 6 Mar 2026 18:37:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oKyKNZTQ3z66jWtSjSN1+R3K9aCPt08hx4nox97xvHk=; b=R2xaZXjwnImJXkrwgd5JhFEWB1 EG8IY1KXJn2b8nyc4XP84EY3qFDBjMY6cFJDFbNMgeHqERnIv/F60Jr5vbc+F5OlZ5nsfn8aV8Oxd OnJEwQe76EqPRxMmbrNfEsG7a4AYWnlVQ6WZAkow1i4EqsUIpwUrnvCxl3CXt5PL6dY1rn0v7KgBT 3uFzO6vGbF3/sdrQdB7ecpKg7jtEFJfNeTRIe8/qVrLPQXullD1vWyAQR45+2tTe0jlKuG/EZgWdq wYllt4M8Gr8SDSO9ronAYxkiarWGFlP42MvW9ulGw7M0lCpaKc0bBKmPILlkTGPwBW8PSD4qGWrPY e8j7oJPg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vya3Q-00000004LJv-1Ju5; Fri, 06 Mar 2026 18:37:40 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vya3L-00000004LJC-1BQ5; Fri, 06 Mar 2026 18:37:38 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1772822232; cv=none; d=zohomail.com; s=zohoarc; b=VMEWbvz5Hnj4zLmKTQduz85HWk/983I4lo59idwq7q35KXDHwytP9XlKfLdFURo+P+b0UhCEdR14V13S4KY87hdQZDMScQ+TvwjJqFoYhxEXiHMH5Ahrwk47FTFBB0Qi/zU/i0FKZN98kxErgKtyMm9Vupd3WuL/roxAGAobj/s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772822232; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=oKyKNZTQ3z66jWtSjSN1+R3K9aCPt08hx4nox97xvHk=; b=XrWbKcUyPpthDMFxY696KrDfler1hA+RB2/7EjBkQRxuEz8wOG5h++7KXIzztVwSzrNFZiK6b9cfzGOXMrBhJQuiiEWZrEin96hapASASro8tOAR0ajl1LvedgcnggAxbqm4vtzvoW8HhDFoeOLAmKOcdYsBtRZIw/fV3PuixrI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1772822232; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=oKyKNZTQ3z66jWtSjSN1+R3K9aCPt08hx4nox97xvHk=; b=K2UYhZDqtQWwaDNMOSNXNi/NUilmovHzmHnxXpWOa4Bg9Pj9jPWEmhsIq/DNNgbM c8vlhm5MZIhtvigANBjvTPU9lxq1duvw2Y3XrP0ZyU6WfG9JCa05+wUDHYGsJiuS/3L ujchqcxj/xFKK1Y75VVQDxT2pQCRfszw5vxZ7yn4= Received: by mx.zohomail.com with SMTPS id 1772822230152545.7385167448177; Fri, 6 Mar 2026 10:37:10 -0800 (PST) From: Nicolas Frattaroli To: Rob Herring Cc: Alim Akhtar , Avri Altman , Bart Van Assche , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , AngeloGioacchino Del Regno , Chunfeng Yun , Vinod Koul , Kishon Vijay Abraham I , Peter Wang , Stanley Jhu , "James E.J. Bottomley" , "Martin K. Petersen" , Philipp Zabel , Liam Girdwood , Mark Brown , Chaotian Jing , Neil Armstrong , Louis-Alexis Eyraud , kernel@collabora.com, linux-scsi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-phy@lists.infradead.org, Conor Dooley Subject: Re: [PATCH v9 03/23] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant Date: Fri, 06 Mar 2026 19:37:02 +0100 Message-ID: <4089450.ElGaqSPkdT@workhorse> In-Reply-To: <20260306163305.GA2680515-robh@kernel.org> References: <20260306-mt8196-ufs-v9-0-55b073f7a830@collabora.com> <20260306-mt8196-ufs-v9-3-55b073f7a830@collabora.com> <20260306163305.GA2680515-robh@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260306_103735_408554_606565A9 X-CRM114-Status: GOOD ( 25.34 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Friday, 6 March 2026 17:33:05 Central European Standard Time Rob Herring wrote: > On Fri, Mar 06, 2026 at 02:24:44PM +0100, Nicolas Frattaroli wrote: > > The MediaTek MT8196 SoC's UFS controller uses three additional clocks > > compared to the MT8195, and a different set of supplies. It is therefore > > not compatible with the MT8195. > > > > While it does have a AVDD09_UFS_1 pin in addition to the AVDD09_UFS pin, > > it appears that these two pins are commoned together, as the board > > schematic I have access to uses the same supply for both, and the > > downstream driver does not distinguish between the two supplies either. > > > > Add a compatible for it, and modify the binding correspondingly. > > > > Reviewed-by: Conor Dooley > > Acked-by: Vinod Koul > > Acked-by: Conor Dooley > > Reviewed-by: AngeloGioacchino Del Regno > > Signed-off-by: Nicolas Frattaroli > > --- > > .../devicetree/bindings/ufs/mediatek,ufs.yaml | 58 +++++++++++++++++++++- > > 1 file changed, 57 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml > > index e0aef3e5f56b..a82119ecbfe8 100644 > > --- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml > > +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml > > @@ -16,10 +16,11 @@ properties: > > - mediatek,mt8183-ufshci > > - mediatek,mt8192-ufshci > > - mediatek,mt8195-ufshci > > + - mediatek,mt8196-ufshci > > > > clocks: > > minItems: 1 > > - maxItems: 13 > > + maxItems: 16 > > > > clock-names: > > minItems: 1 > > @@ -37,6 +38,9 @@ properties: > > - const: crypt_perf > > - const: ufs_rx_symbol0 > > - const: ufs_rx_symbol1 > > + - const: ufs_sel > > "ufs" is redundant as all the clocks are for UFS. Same comment on prior > patch. Is this naming a big enough concern to block this series with two explicit acks on this patch that fixes a wholly broken and useless binding? > > > + - const: ufs_sel_min_src > > + - const: ufs_sel_max_src > > "src" sounds like a parent clock? If so, probably shouldn't be in the > clocks list. 'assigned-clocks' is for dealing with parent clocks. > I don't know what it is, and I have no way to consult any documentation that would tell me what it is. I am trying to put out this dumpster fire of a downstream turd that made its way into mainline as the review process has been completely subverted, and is only getting worse with each passing month that MediaTek is allowed to block this series from progressing while sneaking further changes through. > Rob >