linux-kernel - Re: [PATCH] soc/tegra: fuse: Export tegra_get_platform() & tegra_is

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: <b6c37fd4-d9ca-484a-80c2-d4b6b05c77cb@app.fastmail.com>
Date:   Thu, 20 Oct 2022 11:57:39 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Thierry Reding" <thierry.reding@...il.com>,
        "Olof Johansson" <olof@...om.net>
Cc:     Kartik <kkartik@...dia.com>, "Jon Hunter" <jonathanh@...dia.com>,
        windhl@....com, sumitg@...dia.com, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] soc/tegra: fuse: Export tegra_get_platform() & tegra_is_silicon()

On Thu, Oct 20, 2022, at 11:54, Thierry Reding wrote:
> On Mon, Sep 26, 2022 at 03:35:59PM +0530, Kartik wrote:
>> Functions tegra_get_platform() and tegra_is_silicon() are required
>> for pre-silicon development to correctly identify the platform on
>> which the software is running.
>> 
>> Export tegra_get_platform() and tegra_is_silicon(), so they can be
>> used for pre-slicon development of device drivers and kernel space
>> tests.
>> 
>> Signed-off-by: Kartik <kkartik@...dia.com>
>> ---
>>  drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>
> Hi Arnd, Olof,
>
> can you take a quick look at this and provide some feedback regarding
> acceptance? It's slightly unorthodox because the only in-tree users of
> these functions are built-in drivers and early code, so they don't
> technically need to be exported for strictly in-kernel users. However,
> we do see these used quite frequently in pre-silicon development and
> having these available upstream would help with internal kernel
> transitions and so on. We may also see them used more commonly in
> upstream drivers in the future.

Hi Thierry and Kartik,

Have you looked at using soc_device_match() instead?

As long as the information is part of the soc_device_attribute
prvoided by the soc info driver, any other kernel driver should
be able to just use string matching to get what you need here.

    Arnd