All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Arnd Bergmann <arnd@arndb.de>, Thierry Reding <thierry.reding@gmail.com>
Cc: arm-soc <arm@kernel.org>, SoC Team <soc@kernel.org>,
	"open list:TEGRA ARCHITECTURE SUPPORT"
	<linux-tegra@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	James Morse <james.morse@arm.com>,
	Robert Richter <rric@kernel.org>
Subject: Re: [GIT PULL 1/7] soc/tegra: Changes for v5.20-rc1
Date: Wed, 13 Jul 2022 13:19:35 +0100	[thread overview]
Message-ID: <d12fa14a-bf0d-4e98-acd8-69229315d660@nvidia.com> (raw)
In-Reply-To: <CAK8P3a0cSq47B=acZ854TVu=RckJNfyfKdqQUMzCX7SsV7Wt0g@mail.gmail.com>


On 13/07/2022 13:14, Arnd Bergmann wrote:

...

>>> For the other patches, I found two more problems:
>>>
>>>> Bitan Biswas (1):
>>>>        soc/tegra: fuse: Expose Tegra production status
>>>
>>> Please don't just add random attributes in the soc device infrastructure.
>>> This one has a completely generic name but a SoC specific
>>> meaning, and it lacks a description in Documentation/ABI.
>>> Not sure what the right ABI is here, but this is something that needs
>>> to be discussed more broadly when you send a new version.
>>
>> I wasn't aware that the SoC device infrastructure was restricted to only
>> standardized attributes. Looks like there are a few other outliers that
>> add custom attributes: UX500, ARM Integrator and RealView, and OMAP2.
>>
>> Do we have some other place where this kind of thing can be exposed? Or
>> do we just need to come up with some better way of namespacing these?
>> Perhaps it would also be sufficient if all of these were better
>> documented so that people know what to look for on their platform of
>> interest.
> 
> It's not a 100% strict rule, I've just tried to limit it as much as possible,
> and sometimes missed drivers doing it anyway. My main goal here is
> to make things consistent between SoC families, so if one piece of
> information is provided by a number of them, I'd rather have a standard
> attribute, or a common way of encoding this in the existing attributes
> than to have too many custom attributes with similar names.


Makes sense. Any recommendations for this specific attribute? I could 
imagine other vendors may have engineering devices and production 
versions. This is slightly different from the silicon version.

Cheers
Jon

-- 
nvpublic

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Arnd Bergmann <arnd@arndb.de>, Thierry Reding <thierry.reding@gmail.com>
Cc: arm-soc <arm@kernel.org>, SoC Team <soc@kernel.org>,
	"open list:TEGRA ARCHITECTURE SUPPORT"
	<linux-tegra@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	James Morse <james.morse@arm.com>,
	Robert Richter <rric@kernel.org>
Subject: Re: [GIT PULL 1/7] soc/tegra: Changes for v5.20-rc1
Date: Wed, 13 Jul 2022 13:19:35 +0100	[thread overview]
Message-ID: <d12fa14a-bf0d-4e98-acd8-69229315d660@nvidia.com> (raw)
In-Reply-To: <CAK8P3a0cSq47B=acZ854TVu=RckJNfyfKdqQUMzCX7SsV7Wt0g@mail.gmail.com>


On 13/07/2022 13:14, Arnd Bergmann wrote:

...

>>> For the other patches, I found two more problems:
>>>
>>>> Bitan Biswas (1):
>>>>        soc/tegra: fuse: Expose Tegra production status
>>>
>>> Please don't just add random attributes in the soc device infrastructure.
>>> This one has a completely generic name but a SoC specific
>>> meaning, and it lacks a description in Documentation/ABI.
>>> Not sure what the right ABI is here, but this is something that needs
>>> to be discussed more broadly when you send a new version.
>>
>> I wasn't aware that the SoC device infrastructure was restricted to only
>> standardized attributes. Looks like there are a few other outliers that
>> add custom attributes: UX500, ARM Integrator and RealView, and OMAP2.
>>
>> Do we have some other place where this kind of thing can be exposed? Or
>> do we just need to come up with some better way of namespacing these?
>> Perhaps it would also be sufficient if all of these were better
>> documented so that people know what to look for on their platform of
>> interest.
> 
> It's not a 100% strict rule, I've just tried to limit it as much as possible,
> and sometimes missed drivers doing it anyway. My main goal here is
> to make things consistent between SoC families, so if one piece of
> information is provided by a number of them, I'd rather have a standard
> attribute, or a common way of encoding this in the existing attributes
> than to have too many custom attributes with similar names.


Makes sense. Any recommendations for this specific attribute? I could 
imagine other vendors may have engineering devices and production 
versions. This is slightly different from the silicon version.

Cheers
Jon

-- 
nvpublic

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-13 12:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 18:56 [GIT PULL 0/7] NVIDIA Tegra changes for v5.20-rc1 Thierry Reding
2022-07-08 18:56 ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 1/7] soc/tegra: Changes " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-12 13:27   ` Arnd Bergmann
2022-07-12 13:27     ` Arnd Bergmann
2022-07-13 10:58     ` Thierry Reding
2022-07-13 10:58       ` Thierry Reding
2022-07-13 12:14       ` Arnd Bergmann
2022-07-13 12:14         ` Arnd Bergmann
2022-07-13 12:19         ` Jon Hunter [this message]
2022-07-13 12:19           ` Jon Hunter
2022-07-13 12:36           ` Arnd Bergmann
2022-07-13 12:36             ` Arnd Bergmann
2022-07-14  6:49             ` Jon Hunter
2022-07-14  6:49               ` Jon Hunter
2022-07-13 20:22         ` Thierry Reding
2022-07-13 20:22           ` Thierry Reding
2022-07-14  6:30           ` Jon Hunter
2022-07-14  6:30             ` Jon Hunter
2022-07-14 14:45           ` Arnd Bergmann
2022-07-14 14:45             ` Arnd Bergmann
2022-07-14 13:31         ` Borislav Petkov
2022-07-14 13:31           ` Borislav Petkov
2022-07-15  8:06           ` Sumit Gupta
2022-07-15  8:06             ` Sumit Gupta
2022-07-28 17:34             ` Thierry Reding
2022-07-28 17:34               ` Thierry Reding
2022-08-22  9:31               ` Sumit Gupta
2022-08-22  9:31                 ` Sumit Gupta
2022-09-27 16:00           ` Thierry Reding
2022-09-27 16:00             ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 2/7] firmware: tegra: " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 3/7] dt-bindings: " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 4/7] memory: tegra: " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 5/7] ARM: tegra: Device tree changes " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 6/7] arm64: " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-08 18:56 ` [GIT PULL 7/7] arm64: tegra: Default configuration updates " Thierry Reding
2022-07-08 18:56   ` Thierry Reding
2022-07-11 16:20 ` [GIT PULL 0/7] NVIDIA Tegra changes " patchwork-bot+linux-soc
2022-07-12 21:30 ` patchwork-bot+linux-soc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d12fa14a-bf0d-4e98-acd8-69229315d660@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=rric@kernel.org \
    --cc=soc@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.