public inbox for kernelci@lists.linux.dev
 help / color / mirror / Atom feed
From: Minas Hambardzumyan <minas@ti.com>
To: "Jan Lübbe" <jlu@pengutronix.de>,
	"kernelci@lists.linux.dev" <kernelci@lists.linux.dev>
Cc: "Menon, Nishanth" <nm@ti.com>, "Sheraw, Barry" <bsheraw@ti.com>
Subject: Re: Hardware registry schema proposal
Date: Mon, 13 Oct 2025 16:01:34 -0500	[thread overview]
Message-ID: <43bed489-93d0-ec48-dd28-601317ec2e79@ti.com> (raw)
In-Reply-To: <2c821447e222e825b36bcc19917e6527d8358e8f.camel@pengutronix.de>

On 10/9/25 04:58, Jan Lübbe wrote:
> On Wed, 2025-10-08 at 21:20 +0000, Hambardzumyan, Minas wrote:
>> Hello,
>>
>> I signed up a couple of weeks ago to propose a schema for organizing information about the hardware tested in Kernel-CI labs.
>>
>> Please review and share your comments on a proposed schema here:
>> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry_schema.yaml
>>
>> along with an example yaml file here:
>> https://github.com/TexasInstruments-Sandbox/KernelCi-collaboration/blob/main/hardware_registry/hardware_registry.yaml
>>
>> In summary, the schema defines following main sections with cross references:
>>
>> * silicon_vendors: A collection of silicon vendors (processors, SOCs)
>> * platform_vendors: A collection of platform vendors (servers, laptops, boards, etc.)
>> * processors: A collection of processors used on tested platforms
>> * system_modules: A collection of system modules (SoMs, SiPs)
>> * platforms: A collection of platforms tested in labs
> 
> You have an `id` property which seems to always match the mapping entry name.
> Can they be different? If not, it seems redundant and the property could be
> removed.

Yes I have set id and yaml key name the same. Intention was include the 
hardware name in each yaml section, such that functions taking it as an 
argument would have access to the name without having to pass an extra 
parameter. I agree this does create a possibility for the two being 
different by mistake.

I think keeping the id would make it easier to use, but I have no 
problem removing it if there is a strong opinion to remove it.

> 
> Regards,
> Jan


      reply	other threads:[~2025-10-13 21:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-08 21:20 Hardware registry schema proposal Hambardzumyan, Minas
2025-10-09  8:19 ` Ben Copeland
2025-11-13 12:53   ` Minas Hambardzumyan
2025-10-09  9:58 ` Jan Lübbe
2025-10-13 21:01   ` Minas Hambardzumyan [this message]

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=43bed489-93d0-ec48-dd28-601317ec2e79@ti.com \
    --to=minas@ti.com \
    --cc=bsheraw@ti.com \
    --cc=jlu@pengutronix.de \
    --cc=kernelci@lists.linux.dev \
    --cc=nm@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox