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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 8 Nov 2021 12:01:35 -0800 From: Brad Larson <brad@...sando.io> To: Marc Zyngier <maz@...nel.org> Cc: Mark Rutland <mark.rutland@....com>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Arnd Bergmann <arnd@...db.de>, Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski <bgolaszewski@...libre.com>, Mark Brown <broonie@...nel.org>, Serge Semin <fancer.lancer@...il.com>, Adrian Hunter <adrian.hunter@...el.com>, Ulf Hansson <ulf.hansson@...aro.org>, Olof Johansson <olof@...om.net>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, linux-spi <linux-spi@...r.kernel.org>, linux-mmc <linux-mmc@...r.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v3 11/11] arm64: dts: Add Pensando Elba SoC support On Mon, Nov 8, 2021 at 11:54 AM Marc Zyngier <maz@...nel.org> wrote: > > > > The Elba SoC is an embedded chip and not intended as a SBSA-compliant > > general platform. > > This has nothing to do with following a standard. It has to do with > following the intended use of the architecture. What you have here is > the system architecture equivalent of trusting userspace to build the > kernel page tables. It can work in limited cases. But would you want > to deploy such construct at scale? Probably not. > > > In this implementation the ITS is used to provide message-based > > interrupts for our (potentially large set) of hardware based > > platform device instances. Virtualization is not a consideration. > > We don't have a SMMU. Interrupt isolation isn't a practical > > consideration for this product. > > Because you have foreseen all use cases for this HW ahead of time, and > can already tell how SW is going to make use of it? Oh well... > > > Propose adding a comment to the dts. > > > > + /* > > + * Elba SoC implemented a pre-ITS that happened to > > + * be the same implementation as synquacer. > > + */ > > Which contains zero information. What you really want is: "We have > decided to ignore the system architecture, good luck". > > M. > > -- > Without deviation from the norm, progress is not possible. On the contrary, the confusion of using the existing driver match "socionext,synquacer-pre-its" is answered, why add new code. Looks like we are deviating from the norm ;-). I'm not seeing how this conversation is a productive use of time for a platform in production. Thanks, Brad
Powered by blists - more mailing lists