linux-kernel - Re: [PATCH v2 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

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: <f9f11958-7c9a-47cb-b9b4-d921a8215ba6@app.fastmail.com>
Date: Fri, 17 Jan 2025 10:43:28 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Gregory CLEMENT" <gregory.clement@...tlin.com>,
 "Rob Herring" <robh@...nel.org>
Cc: "Aleksandar Rikalo" <arikalo@...il.com>,
 "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Krzysztof Kozlowski" <krzk+dt@...nel.org>,
 "Conor Dooley" <conor+dt@...nel.org>,
 "Vladimir Kondratiev" <vladimir.kondratiev@...ileye.com>,
 Théo Lebrun <theo.lebrun@...tlin.com>,
 "Tawfik Bayouk" <tawfik.bayouk@...ileye.com>,
 "Thomas Petazzoni" <thomas.petazzoni@...tlin.com>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for
 EyeQ6



在2025年1月17日一月 上午9:46，Gregory CLEMENT写道：
[...]

Hi all,

>>
>> These 2 blocks don't look related and the only property shared is 
>> 'compatible'. This should be a separate doc.
>
> As mentioned in the cover letter, I reused the work from Jiaxun, who
> needed to deal with bogus CM but in a different way. In his use case,
> the issue with the CM was that the address in CP0 was wrong. In my case,
> this address is correct; it is only one piece of information reported by
> the CM that is wrong. I don't mind creating a separate doc if you
> still think it is the right thing to do.

Precisely I'm dealing with two kind of systems, the first is systems doesn't
come with CP0.CMCGRBase, and thus rely on DeviceTree for probing the CM. The
second is systems mapping CMGCR at inappropriate locations and we want kernel
to remap it.

We don't want reg property to be mandatory as we are dealing with a huge amount
of legacy systems which mapping CM registers at different locations, while we
have to use a uniformed built-in DT and probe mapping at runtime.

Thanks
- Jiaxun
>
> Gregory
>
>>
>> Rob
>
> -- 
> Grégory CLEMENT, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-- 
- Jiaxun