linux-kernel - Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cb173df9-4c70-4619-b36d-8e99272551b6@kernel.org>
Date: Sun, 19 Oct 2025 12:19:09 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Peter Wang (王信友) <peter.wang@...iatek.com>,
 "chu.stanley@...il.com" <chu.stanley@...il.com>,
 "robh@...nel.org" <robh@...nel.org>,
 "James.Bottomley@...senPartnership.com"
 <James.Bottomley@...senPartnership.com>,
 "bvanassche@....org" <bvanassche@....org>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,
 Macpaul Lin (林智斌) <Macpaul.Lin@...iatek.com>,
 "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
 "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
 "avri.altman@....com" <avri.altman@....com>,
 "martin.petersen@...cle.com" <martin.petersen@...cle.com>
Cc: "macpaul@...il.com" <macpaul@...il.com>,
 Pablo Sun (孫毓翔) <pablo.sun@...iatek.com>,
 Project_Global_Chrome_Upstream_Group
 <Project_Global_Chrome_Upstream_Group@...iatek.com>,
 Bear Wang (萩原惟德) <bear.wang@...iatek.com>,
 Ramax Lo (羅明遠) <Ramax.Lo@...iatek.com>
Subject: Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195
 compatible and update clock nodes

On 23/07/2025 11:41, Peter Wang (王信友) wrote:
>> Please, look at my old submission, which actually fixes the
>> compatibles other than
>> adding the right clocks for all UFS controllers in MediaTek
>> platforms.
>>
>> https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/
>>
> 
> Hi Angelo,
> 
> The clock architecture may vary depending on the platform.
> These clock patch look good to me.
> 
> 
>> I want to take the occasion to remind everyone that my fixes were
>> discarded because
>> the MediaTek UFS driver maintainer wants to keep the low quality of
>> the driver in
>> favor of easier downstream porting - which is *not* in any way
>> adhering to quality
>> standards that the Linux community deserves.
>>
>> Cheers,
>> Angelo
> 
> I want to clarify that I am not opposing this in order to keep the 
> low quality of the driver for the sake of easier downstream porting.

You did.

You wrote very clearly here:
https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/

"In addition, it will require MediaTek to put in extra
effort to migrate the kernel. "


Also you wrote:
"The role of MediaTek UFS maintainer is not suitable to be handed over
to someone outside of MediaTek."

https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/

Holy molly, you really wrote this!

That's completely unacceptable. You don't understand how upstream
development works and you push your downstream narrative which for us
does not matter. You also object community led efforts, because you
apparently want to control the upstream process.

That is red flag.

I think you should step down from maintainer position and find more
suitable person, who is willing to work with the community, or rethink
how upstream process works and understand that your downstream goals do
not matter completely.

I will be watching closely this and if situation does not improve, I
believe we should mark the driver orphaned until we find maintainer
caring about community, not about corporate goals.

Best regards,
Krzysztof