[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <35a07230-08f9-472c-bb30-bd1c1ca912d6@linux.dev>
Date: Tue, 21 Jan 2025 17:19:53 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Xi Ruoyao <xry111@...111.site>, WANG Xuerui <kernel@...0n.name>,
Icenowy Zheng <uwu@...nowy.me>, Huacai Chen <chenhuacai@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Weihao Li <liweihao@...ngson.cn>, "Mike Rapoport (IBM)" <rppt@...nel.org>,
Jun Yi <yijun@...ngson.cn>, Baoquan He <bhe@...hat.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
David Hildenbrand <david@...hat.com>,
Hongchen Zhang <zhanghongchen@...ngson.cn>,
Binbin Zhou <zhoubinbin@...ngson.cn>, Zhen Lei <thunder.leizhen@...wei.com>,
Tiezhu Yang <yangtiezhu@...ngson.cn>, Thomas Gleixner <tglx@...utronix.de>,
Zhihong Dong <donmor3000@...mail.com>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org, Shuah <shuah@...nel.org>,
"conduct@...nel.org" <conduct@...nel.org>
Subject: Re: [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as
same as ioremap_wc
Hi,
On 2023/10/13 21:53, Xi Ruoyao wrote:
> On Fri, 2023-10-13 at 21:15 +0800, Xi Ruoyao wrote:
>> Again, why this is only an issue with AMD or ATI GPUs?
>>
>> Can you provide some detailed documentations about this hardware issue
>> so the community can help to figure out a solution?
I don't ever owns you anything, so I think I don't have any obligation
to have to provide you something, right?
> 3 years ago we had https://lkml.org/lkml/2020/8/10/255:
Its not "we". Just him or "you" if you want to pretend to be included.
> In this case the patch is a clear NAK since youhaven't root caused the issue
Excuse me, its not me posting that patch to upstream anyway. So who don't have the
root cause? Can you figure out different person at the first place? Please?
> are just working around it in a very questionable manner.
The patch[1] that this patch fixes are circumvent the root issue in a very questionable manner.
So, who don't know the root cause? or just cheating the community, pretend it solve the problem?
[1] https://lore.kernel.org/loongarch/20230315085314.1083141-1-chenhuacai@loongson.cn/
> and
>
> But when the hardware doesn't correctly implement WC for PCIe BARs, then
> this is a violation of the PCIe spec and a bit more serious issue for
> the whole platform.
>
> So do we know the root cause now?
Its not "we" here, we are not on the same side.
So the proper expression is "Do you *really* know the root cause now"?
> <rant>Or in all the 3 years we
Not including you here.
> just keep carrying a problematic workaround downstream,
Who told you that its problematic?
Again, its works *super* well for *both* discrete GPU and Loongson integrated graphics.
With the patch applied, Loongson has been sell tons of machine and making million dollars,
if not billion.
So *who* exactly told you that its problematic? Did him ever use Loongson machine?
Did him responsible for Loongson downstream *product* and commercial deals?
If you can't effectively answer those questions, please stop your nonsense.
> burying the head into the sand like an ostrich,
I neverbury my head into the sand and I'm not like an ostrich.
In the past, Loongson downstream developers are rather diligent and busy .
I don't think I deserve this insult, so please stop it and apology.
CCing conduct@...nel.org and CCing shuah.
> and self comforting with "oh they don't understand our hardware"?!</rant>
This is exactly what I'm helping to resolve, just help the community to
figure out the root issue. Seek better solution so that we can avoid
endless the low-end repeation.
We certainly don't hope Loongson continue to produce such an ill CPU
and/or bridge chips all the time.
> Even if the problem is really "they don't understand our hardware" you
> need to provide some materials to help people understanding the hardware
> better.
Again, Its not me posting the patch anyway. So please stop the blaming and
the spams.
> If we cannot figure out the root cause or a proper fix is too difficult,
> we should *at least* have a cmdline option and/or a configuration option
> to allow the user to decide, like how we treat these spectre-like bugs.
> "Should the option be enabled or disabled by default" can be debated
> later.
>
> And please try to fix the hardware, to me it will be a compelling reason
> to pay some money for an upgrade :).
>
--
Best regards,
Sui
Powered by blists - more mailing lists