linux-kernel - Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC

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]

Date: Wed, 20 Dec 2023 22:49:33 +0100
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: Gregory CLEMENT <gregory.clement@...tlin.com>
Cc: Paul Burton <paulburton@...nel.org>, linux-mips@...r.kernel.org,
	Jiaxun Yang <jiaxun.yang@...goat.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
	Tawfik Bayouk <tawfik.bayouk@...ileye.com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Théo Lebrun <theo.lebrun@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC

On Fri, Dec 15, 2023 at 05:39:39PM +0100, Gregory CLEMENT wrote:
> Hello Thomas,
> 
> > Hello,
> >
> > The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
> > and features multiple controllers such as the classic UART, I2C, SPI,
> > as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
> > Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
> > Security Module, Functional Safety Hardware, and MJPEG encoder.
> >
> > One peculiarity of this SoC is that the physical address of the DDDR
> > exceeds 32 bits. Given that the architecture is 64 bits, this is not
> > an issue, but it requires some changes in how the mips64 is currently
> > managed during boot.
> >
> > In this fifth version, there aren't many changes, mostly just tweaking
> > commit messages based on Sergey's feedback and fixing up the code
> > style. But, the real reason for this series is a bit of a whoopsie on
> > my end. It turns out, despite what I confidently claimed in the last
> > round, some configuration tweaks were missing. All sorted now, though!
> >
> 
> A few weeks ago, you were concerned about the introduction of the
> specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
> to set up a new platform instead. Since then, Jiaxun proposed a series
> that was merged here to provide more generic support.

well, there is more to improve and stuff I don't like in Jaixun series.
For example misusing CONFIG_PHYSICAL_START to force a load address via config
(IMHO it's already a hack for CRASH_DUMP).

As there is your series and Jiaxun series, where should I comment more
detailed ?

> I had other issues in the initial series, and I think that now I've
> fixed all of them. So, I would like to know what your opinion is now
> about this series.
> 
> Will you accept it, or do you still think that a new platform has to be
> set up?

things have improved, but I'm still in favor to use a new platform.
And my main point stays. A "generic" kernel compiled for EyeQ5 will
just run on that platform, which doesn't sound generic to me.

Thomas.

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