From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 C74AD2E7375 for ; Thu, 2 Jul 2026 08:55:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782982554; cv=none; b=GDfRCa0d9c+OU3Gg3dateOa8jaOHD/fxFZdaJ/5MWdK2UPDD45Nf9KjmgNIwR6eyfnL2AeSWWDRMuA1aoDSBh4nTR7o3L8lkBNZd9ifzi/OzXZtXQ4wgEc20U43ybrOUA7SOCFjxstgBwaksnEF61z5y+UvXX5x8crtz/UurgoU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782982554; c=relaxed/simple; bh=IGCykDh6psS+r7kUCWByAKB9NnFwtLwmKKrpYiTMfx8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KINk8+CALTM0pHjJX2MsmeotEqyAt26I5sKPduBNPBaC7gCVTnEiRUUju+cQ3FIm+9DmwyOc/IzWU19UTIuMk1X5YSeSDYZYlwuiseRuRyHopB/3xRTtv7w3ChNqzsJWaAK5PetusGXEuLDU38Qo9jW2cRXrSew//i261UeP8c4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=LGrgx/g4; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="LGrgx/g4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1782982544; bh=IGCykDh6psS+r7kUCWByAKB9NnFwtLwmKKrpYiTMfx8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LGrgx/g4Ftej2T+WGhpzoX+1btciiqeo47agTbAmlff18OS1sS8CxQ3NnEgsHn4dE LBz0ansDXylX3Wzu+L11kXj5v6lYKgQot+6oBK0IzYIYoNVdugWcdho6GKYS0f9AUN NMICkuXpal2sCOViaKChuV52YmidvRwTaLm7fKvDAubmjA8FPXKxTi5IYwuFmQJ6WA 13t82xE6lDvifYjNkB0+MOkaVIliHOJL1x4NEJvTAyH6OvjmTJkMUhZw0SA0bvZPH2 UTf2QhYl6RM0v3Bh+EI/YvQcWjjLRiNORGgwiCC1M5mRudk2F55ylZ72PUQ/4YYNJE ayzww6GwZ6xPA== Received: from [100.64.1.21] (unknown [100.64.1.21]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: kholk11) by bali.collaboradmins.com (Postfix) with ESMTPSA id 19E7E17E00A0; Thu, 2 Jul 2026 10:55:44 +0200 (CEST) Message-ID: <7ad86380-6fc3-40d0-8908-22ab2943ac55@collabora.com> Date: Thu, 2 Jul 2026 10:55:43 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] Documentation: dt: reset: add mediatek,syscon-reset binding To: Conor Dooley , =?UTF-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?= , Arnaud Ferraris , Louis-Alexis Eyraud Cc: "p.zabel@pengutronix.de" , "linux-kernel@vger.kernel.org" , =?UTF-8?B?QWxpY2UgQ2hhbyAo6LaZ54+u5Z2HKQ==?= , "krzysztof.kozlowski@linaro.org" , "robh@kernel.org" , wsd_upstream , =?UTF-8?B?Q2h1bi1IdW5nIFd1ICjlt6vpp7/lro8p?= , "linux-devicetree@vger.kernel.org" , =?UTF-8?B?TmFvbWkgQ2h1ICjmnLHoqaDnlLAp?= , "linux-mediatek@lists.infradead.org" , "conor+dt@kernel.org" , "matthias.bgg@gmail.com" , =?UTF-8?B?RWQgVHNhaSAo6JSh5a6X6LuSKQ==?= References: <20260626074820.2537772-1-peter.wang@mediatek.com> <20260626074820.2537772-2-peter.wang@mediatek.com> <4ac862d82690a850eeaa997f041f22ee61233ed7.camel@pengutronix.de> <20260701-city-during-7d76a326f2f4@spud> From: AngeloGioacchino Del Regno Content-Language: en-US In-Reply-To: <20260701-city-during-7d76a326f2f4@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/1/26 18:57, Conor Dooley wrote: > On Wed, Jul 01, 2026 at 06:35:20AM +0000, Peter Wang (王信友) wrote: >> On Fri, 2026-06-26 at 10:33 +0200, Philipp Zabel wrote >>> >>> Where is the binding doc for mediatek,mt8183-ufs0cfg_ao? Is this >>> simple-mfd just to load the reset driver? >>> >> >> Hi Philipp, >> >> Thanks for the review, and sorry for the late reply. >> Yes, "mediatek,mt8183-ufs0cfg_ao" should be removed. >> I will remove it in the next version. >> >>>> +        reg = <0x16840000 0x1000>; >>>> +        #address-cells = <1>; >>>> +        #size-cells = <1>; >>>> + >>>> +        ufs0cfgao_rst: reset-controller { >>>> +            compatible = "mediatek,syscon-reset"; >>> >>> It looks to me like this is just two registers inside ufs0cfg_ao, not >>> a >>> separate device. Why don't you just add #reset-cells to the parent >>> node? >>> >>>> +            #reset-cells = <1>; >>>> +            mediatek,reset-bits = >>>> +                <0x48  3  0x4c  3  100>, >>>> +                <0x148 0  0x14c 0  100>, >>>> +                <0x148 1  0x14c 1  100>, >>>> +                <0x148 2  0x14c 2  0>; >>>> +        }; >>> >>> Why is this in DT? This should be a table in the reset driver. >>> >>> regards >>> Philipp >> >> Regarding the child node and reset-bits in DT, >> We chose the child node approach with 'mediatek,reset-bits' defined >> in DT to keep the reset line descriptions self-contained and reusable >> across different SoC variants. MediaTek has many SoCs (mt8183, mt6985, >> mt6989, ...) where the same UFS subsystem may have different register >> offsets for reset lines. By describing them in DT, we can support new >> SoC variants by updating the DT alone, without requiring a new driver >> patch for every new SoC. > > From what I recall, mediatek ufs is a mess with lots of vendor kernel > type things slipping into mainline without proper review on the DT > front. > Because of that, I at least am going to require that everything is done > completely (and perhaps excessively) by the book here, including > introducing complete bindings for syscon regions rather than partial > bits for components like this one. > Conor, thanks for chiming in. I would've done that earlier but I'm going through a bit of busy period here, so thanks x2. Yes the UFS driver is quite a bit messy. The latest version of our series that cleans it up is version 9, sent quite a while ago at this point: https://patchwork.kernel.org/project/linux-scsi/cover/20260306-mt8196-ufs-v9-0-55b073f7a830@collabora.com/ ...but anyway, during these months we kept going on with it and we do have a newer version of this series in our tree, which we're planning to send in a week or two. That'll start fixing stuff around, at least, in both bindings and code. >> This approach is also consistent with the existing 'ti,syscon-reset' >> binding, which uses a similar per-entry table property 'ti,reset-bits' >> to describe reset lines within a syscon block. > > This was done about 10 years ago, I would not consider it a guide for > what's acceptable today. > I completely agree about that. Honestly, I'm not even sure why MediaTek needs the resets in the ufscfg0-ao space (because I didn't do extensive research, but that might be rightful), but this is getting a bit annoying as they keep pushing for adding something similar to the TI syscon reset at least at every new chip that comes out (or every 6-8 months if I recall correctly), and we keep doing the same review over and over. Please MediaTek, stop trying to add syscon-reset. Please! I know that you're trying to do that because in your downstream you never stopped using ti,syscon-reset: if that works better for you in your downstream, that's ok as it's purely yours but, as a matter of fact, in this form, it's not upstreamable. If you have to upstream a *pure* reset controller, make a reset controller driver and put it in the appropriate kernel subsystem - but I also want to remind you that I know MediaTek SoCs, and I know that up until MT8196 there shouldn't be any hardware that is purely a reset controller (as in, there's no IP that manages only resets). Thanks everyone! Angelo