[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5992593.DvuYhMxLoT@workhorse>
Date: Thu, 08 Jan 2026 10:14:44 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: "chu.stanley@...il.com" <chu.stanley@...il.com>,
"robh@...nel.org" <robh@...nel.org>,
Chunfeng Yun (云春峰) <Chunfeng.Yun@...iatek.com>,
"kishon@...nel.org" <kishon@...nel.org>,
"James.Bottomley@...senPartnership.com"
<James.Bottomley@...senpartnership.com>,
"bvanassche@....org" <bvanassche@....org>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
Chaotian Jing (井朝天) <Chaotian.Jing@...iatek.com>,
"lgirdwood@...il.com" <lgirdwood@...il.com>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"avri.altman@....com" <avri.altman@....com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"broonie@...nel.org" <broonie@...nel.org>,
Peter Wang (王信友) <peter.wang@...iatek.com>
Cc: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
Louis-Alexis Eyraud <louisalexis.eyraud@...labora.com>,
"kernel@...labora.com" <kernel@...labora.com>
Subject: Re: [PATCH v4 11/25] scsi: ufs: mediatek: Rework probe function
On Tuesday, 6 January 2026 14:23:58 Central European Standard Time Peter Wang (王信友) wrote:
> On Thu, 2025-12-18 at 13:55 +0100, Nicolas Frattaroli wrote:
> >
> > Remove the ti,syscon-reset cruft.
> >
>
> Hi Nicolas,
>
> Why do we need to remove the reset node? If an error occurs and the
> host
> does not perform a reset, it could lead to error recovery failure.
Because it's not described by the binding, and appears to be a
downstream hack to work around not having the reset controller
properly described and referred to with a `resets` property.
Even if you were to use `ti,syscon-reset` to describe a reset
controller, the UFS controller driver should not be searching
for this compatible. It should access the reset through the
reset API. The common reset code can then take care of probe
ordering without every driver reinventing it.
>
> Thanks.
> Peter
>
Powered by blists - more mailing lists