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: <ZJqp5nRx22J9ty6J@sunil-laptop>
Date:   Tue, 27 Jun 2023 14:50:38 +0530
From:   Sunil V L <sunilvl@...tanamicro.com>
To:     Conor Dooley <conor.dooley@...rochip.com>
Cc:     Conor Dooley <conor@...nel.org>,
        Andrew Jones <ajones@...tanamicro.com>, palmer@...belt.com,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Heiko Stuebner <heiko.stuebner@...ll.eu>,
        Evan Green <evan@...osinc.com>,
        linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/9] RISC-V: don't parse dt/acpi isa string to get
 rv32/rv64

On Tue, Jun 27, 2023 at 09:51:05AM +0100, Conor Dooley wrote:
> On Tue, Jun 27, 2023 at 01:32:23PM +0530, Sunil V L wrote:
> > On Mon, Jun 26, 2023 at 05:16:09PM +0100, Conor Dooley wrote:
> > > On Mon, Jun 26, 2023 at 06:05:40PM +0200, Andrew Jones wrote:
> > > > On Mon, Jun 26, 2023 at 04:51:29PM +0100, Conor Dooley wrote:
> > > > > On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote:
> > > > > > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote:
> 
> > > > > One of the few things I know does parsing of /proc/cpuinfo is:
> > > > > https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c
> > > > > and that doesn't seem to care about the mmu, but does rely on
> > > > > vendor/uarch ordering.
> > > > > 
> > > > > Makes me wonder, does ACPI break things by leaving out uarch/vendor
> > > > > fields, if there is something that expects them to exist? We should
> > > > > not intentionally break stuff in /proc/cpuinfo, but can't say I feel any
> > > > > sympathy for naively parsing it.
> > > > 
> > > > Yes, it would be nice for ACPI to be consistent. I'm not sure what can be
> > > > done about that.
> > > 
> > > Print "unknown", until there's a way of passing the info?
> > > Speaking of being an eejit, adding new fields to the file would probably
> > > break some really naive parsers & quite frankly that sort of thing can
> > > keep the pieces IMO. Ditto if adding more extensions breaks someone that
> > > expects _zicbom_zicboz that breaks when _zicbop is slid into the middle.
> 
> > Instead of unknown, could you print "risc-v" or "riscv"?
> 
> I don't really see how that is better. "riscv" is not the uarch or
> vendor. If we don't know, we should either say we don't know or omit the
> field IMO.
> 
Okay. Makes sense. In that case, I prefer to skip.
uarch is anyway printed using other ways. Even in DT, this is not
printed for generic cpus having compatible string riscv. So, consumers
should expect it not being printed.

Thanks,
Sunil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ