linux-kernel - Re: [PATCH] soc/tegra: fuse: Add custom SoC attributes

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: <20200320151035.GB3706404@ulmo>
Date:   Fri, 20 Mar 2020 16:10:35 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc/tegra: fuse: Add custom SoC attributes

On Fri, Mar 20, 2020 at 11:37:16AM +0000, Jon Hunter wrote:
> Add a custom SoC attribute for Tegra to expose the HIDREV register
> contents to userspace via the sysfs. This register provides additional
> details about the fabrication and versioning of the device. Exposing
> this information is useful for identifying the exact device revision and
> device type.
> 
> Please note that the fields in this register vary depending on the Tegra
> generation and so instead of exposing the individual fields, just expose
> the entire contents of the register. Details of the register fields can
> be found in the Technical Reference Manual for each Tegra device.

That seems a little suboptimal to me. It's pretty trivial for the kernel
to distinguish between different SoC generations in order to know what
the fields are. It's a lot more difficult for userspace to do so. Is the
register completely different between SoC generations or just slightly?

Having individual fields exposed as individual attributes seems like it
would make it a lot easier for userspace to get at the needed bits.

Thierry

> 
> Signed-off-by: Jon Hunter <jonathanh@...dia.com>
> ---
>  drivers/soc/tegra/fuse/fuse-tegra.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c b/drivers/soc/tegra/fuse/fuse-tegra.c
> index 802717b9f6a3..217e326da232 100644
> --- a/drivers/soc/tegra/fuse/fuse-tegra.c
> +++ b/drivers/soc/tegra/fuse/fuse-tegra.c
> @@ -300,6 +300,24 @@ static void tegra_enable_fuse_clk(void __iomem *base)
>  	writel(reg, base + 0x14);
>  }
>  
> +static ssize_t tegra_soc_hidrev_show(struct device *dev,
> +				     struct device_attribute *attr,
> +				     char *buf)
> +{
> +	return sprintf(buf, "%d\n", tegra_read_chipid());

Would it be better to print this as hexadecimal?

> +}
> +
> +static DEVICE_ATTR(hidrev, S_IRUGO, tegra_soc_hidrev_show,  NULL);
> +
> +static struct attribute *tegra_soc_attr[] = {
> +	&dev_attr_hidrev.attr,
> +	NULL,
> +};
> +
> +static const struct attribute_group tegra_soc_attr_group = {
> +	.attrs = tegra_soc_attr,
> +};
> +
>  struct device * __init tegra_soc_device_register(void)
>  {
>  	struct soc_device_attribute *attr;
> @@ -312,6 +330,7 @@ struct device * __init tegra_soc_device_register(void)
>  	attr->family = kasprintf(GFP_KERNEL, "Tegra");
>  	attr->revision = kasprintf(GFP_KERNEL, "%d", tegra_sku_info.revision);
>  	attr->soc_id = kasprintf(GFP_KERNEL, "%u", tegra_get_chip_id());

I guess we print all of these as decimal, so hidrev should probably be
the same, so never mind the previous comment.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)