linux-kernel - Re: [PATCH v2 0/6] MIPS: cm: Probe GCR address from devicetree

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2xkut5pyzk4b4ugl4ku72y4rfqrfsoxj4aww2jwlgkc3lmd464@zwf773fr7fpq>
Date: Tue, 10 Sep 2024 15:20:10 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
	Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: Jiaxun Yang <jiaxun.yang@...goat.com>, 
	Paul Burton <paulburton@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-mips@...r.kernel.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 0/6] MIPS: cm: Probe GCR address from devicetree

On Tue, Sep 10, 2024 at 11:06:56AM +0300, Serge Semin wrote:
> Hi Thomas
> 
> On Mon, Sep 09, 2024 at 03:32:21PM +0200, Thomas Bogendoerfer wrote:
> > On Tue, Aug 06, 2024 at 10:49:52PM +0300, Serge Semin wrote:
> > > Hi Jiaxun
> > > 
> > > On Wed, Jun 12, 2024 at 11:08:52AM +0100, Jiaxun Yang wrote:
> > > > Hi all,
> > > > 
> > > > This series enabled mips-cm code to probe GCR address from devicetree.
> > > > 
> > > > This feature has been implemented in MIPS's out-of-tree kernel for
> > > > a while, and MIPS's u-boot fork on boston will generate required
> > > > "mti,mips-cm" node as well.
> > > > 
> > > > Please review.
> > > > Thanks
> > > 
> > > Got this tested on my P5600-based SoC implemented as non-generic
> > > platform. Alas the system hangs up on the early boot-up stage with no
> > > even a single char printed to the console. I'll be able to get back to
> > > the problem debugging on the next week.
> > 
> > any news about that ?
> 
> Oops. This patch set has absolutely slipped out of my mind. I am
> getting back to it immediately and will submit the debug status
> shortly after I dig out the reason of the hanging up. Sorry for the
> inconvenience.

Found the reason of the problem on my platform. It was due to the too
early change_gcs_control() invocation. Since mips_cm_probe() is now
called after the prom_init() method the later function can't access
any CM-register. So for the system to boot up I had to move the GCR
controler register update to the plat_mem_setup() method in my
platform code. After that the system booted up successfully. Double
checked the rest of the platforms in the vanilla kernel repo for having
the similar issue. It seems to me there is no platform left in the
kernel with such potential problem presented.

But then I decided to test out the actual GCR-base address setup
procedure implemented in this patch set, and found another problem
unrelated to my platform. I'll submit the problem summary in reply to
the respective patch in this series.

-Serge(y)

> 
> -Serge(y)
> 
> > 
> > Thomas.
> > 
> > -- 
> > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> > good idea.                                                [ RFC1925, 2.3 ]