Add a sample board file describing the file's format and with the list
of devices expected to be probed on the XPS 13 9300 machine as an
example x86 platform.

Test output:

TAP version 13
Using board file: boards/Dell Inc.,XPS 13 9300.yaml
1..22
ok 1 /pci-controller/14.0/usb2-controller/9/camera.device
ok 2 /pci-controller/14.0/usb2-controller/9/camera.0.driver
ok 3 /pci-controller/14.0/usb2-controller/9/camera.1.driver
ok 4 /pci-controller/14.0/usb2-controller/9/camera.2.driver
ok 5 /pci-controller/14.0/usb2-controller/9/camera.3.driver
ok 6 /pci-controller/14.0/usb2-controller/10/bluetooth.device
ok 7 /pci-controller/14.0/usb2-controller/10/bluetooth.0.driver
ok 8 /pci-controller/14.0/usb2-controller/10/bluetooth.1.driver
ok 9 /pci-controller/2.0/gpu.device
ok 10 /pci-controller/2.0/gpu.driver
ok 11 /pci-controller/4.0/thermal.device
ok 12 /pci-controller/4.0/thermal.driver
ok 13 /pci-controller/12.0/sensors.device
ok 14 /pci-controller/12.0/sensors.driver
ok 15 /pci-controller/14.3/wifi.device
ok 16 /pci-controller/14.3/wifi.driver
ok 17 /pci-controller/1d.0/0.0/ssd.device
ok 18 /pci-controller/1d.0/0.0/ssd.driver
ok 19 /pci-controller/1d.7/0.0/sdcard-reader.device
ok 20 /pci-controller/1d.7/0.0/sdcard-reader.driver
ok 21 /pci-controller/1f.3/audio.device
ok 22 /pci-controller/1f.3/audio.driver
Totals: pass:22 fail:0 xfail:0 xpass:0 skip:0 error:0

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
 .../devices/boards/Dell Inc.,XPS 13 9300.yaml      | 40 ++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml b/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml
new file mode 100644
index 000000000000..ff932eb19f0b
--- /dev/null
+++ b/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml	
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# This is the device definition for the XPS 13 9300.
+# The filename "Dell Inc.,XPS 13 9300" was chosen following the format
+# "Vendor,Product", where Vendor comes from
+# /sys/devices/virtual/dmi/id/sys_vendor, and Product comes from
+# /sys/devices/virtual/dmi/id/product_name.
+#
+# See google,spherion.yaml for more information.
+#
+- type: pci-controller
+  # This machine has a single PCI host controller so it's valid to not have any
+  # key to identify the controller. If it had more than one controller, the UID
+  # of the controller from ACPI could be used to distinguish as follows:
+  #acpi-uid: 0
+  devices:
+    - path: 14.0
+      type: usb-controller
+      usb-version: 2
+      devices:
+        - path: 9
+          name: camera
+          interfaces: [0, 1, 2, 3]
+        - path: 10
+          name: bluetooth
+          interfaces: [0, 1]
+    - path: 2.0
+      name: gpu
+    - path: 4.0
+      name: thermal
+    - path: 12.0
+      name: sensors
+    - path: 14.3
+      name: wifi
+    - path: 1d.0/0.0
+      name: ssd
+    - path: 1d.7/0.0
+      name: sdcard-reader
+    - path: 1f.3
+      name: audio

-- 
2.43.0

"Nícolas F. R. A. Prado" <nfraprado@collabora.com>:
> Add a sample board file describing the file's format and with the list
> of devices expected to be probed on the XPS 13 9300 machine as an
> example x86 platform.

And now "Dell Inc.,XPS 13 9300.yaml" became the only file in the repository,
which has space in its name:

$ find . -name '* *'
./tools/testing/selftests/devices/probe/boards/Dell Inc.,XPS 13 9300.yaml

I kindly ask you to rename file. New name should not contain space or comma
in it.

The file name in its current form breaks tools. For example, it breaks
"xargs".

For example, the following will work in "fs" directory:

stable/fs$ find . | xargs chmod -w

But it will not work in root of source tree because of this
"Dell Inc.,XPS 13 9300.yaml" file:

stable$ find . | xargs chmod -w
chmod: cannot access './tools/testing/selftests/devices/probe/boards/Dell': No such file or directory
chmod: cannot access 'Inc.,XPS': No such file or directory
chmod: cannot access '13': No such file or directory
chmod: cannot access '9300.yaml': No such file or directory

-- 
Askar Safin

On Sun, 2025-12-28 at 08:47 +0300, Askar Safin wrote:
> "Nícolas F. R. A. Prado" <nfraprado@collabora.com>:
> > Add a sample board file describing the file's format and with the
> > list
> > of devices expected to be probed on the XPS 13 9300 machine as an
> > example x86 platform.
> 
> And now "Dell Inc.,XPS 13 9300.yaml" became the only file in the
> repository,
> which has space in its name:
> 
> $ find . -name '* *'
> ./tools/testing/selftests/devices/probe/boards/Dell Inc.,XPS 13
> 9300.yaml
> 
> I kindly ask you to rename file. New name should not contain space or
> comma
> in it.

While I understand it might be inconvenient that this is the only file
with a space in its name, that is exactly the string that is reported
by DMI, so it is natural that it would be used for the filename.

Besides, I'm not aware of there being a style guide rule that prohibits
space in filenames in the kernel tree, or that could have easily be
detected by checkpatch during submission.

Furthermore, not containing a comma is not even feasible, there are
tons of dt-binding filenames containing commas in the tree.

> 
> The file name in its current form breaks tools. For example, it
> breaks
> "xargs".
> 
> For example, the following will work in "fs" directory:
> 
> stable/fs$ find . | xargs chmod -w
> 
> But it will not work in root of source tree because of this
> "Dell Inc.,XPS 13 9300.yaml" file:
> 
> stable$ find . | xargs chmod -w
> chmod: cannot access
> './tools/testing/selftests/devices/probe/boards/Dell': No such file
> or directory
> chmod: cannot access 'Inc.,XPS': No such file or directory
> chmod: cannot access '13': No such file or directory
> chmod: cannot access '9300.yaml': No such file or directory

You can use 'find -print0' and 'xargs -0' instead so the space in the
filename is not an issue.

-- 
Thanks,

Nícolas

"Nícolas F. R. A. Prado" <nfraprado@collabora.com>:
> While I understand it might be inconvenient that this is the only file

As well as I understand, it is intended that more files will be added
to tools/testing/selftests/devices/boards with various vendor names and
product names.

So I did some further research. I grepped Linux source and found some
vendor names and product names with undesirable chars.

Let's go.

/rbt/linux/arch/x86/kernel/apm_32.c:2097:                       DMI_MATCH(DMI_PRODUCT_NAME, "PC-PJ/AX"),
/rbt/linux/arch/x86/kernel/reboot.c:396:                        DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 300/"),
/rbt/linux/drivers/platform/x86/samsung-laptop.c:1633:          DMI_MATCH(DMI_PRODUCT_NAME, "R40/R41"),

Here we see / chars, which are simply forbidden in Linux filesystems.

I also found a lot of others undesirable chars, such as "(" ")" "'" "&" "#" "*",
which surely will break a lot of tools. In particular, "'" is used in bash
to quote something verbatim.

Here is extended result of my research:
https://zerobin.net/?d1f2655a979acd3f#oBhwIedQvBL/iB9Src65aRYuyjaye2GQBNL3+6yfvGg=

Unfortunately, I'm not sure which of these names refer to whole "board",
and which of them refer to merely some particular device, such as USB device.

BUT for 3 instances of / chars given in the top of this email I'm totally
sure that they refer to whole "boards", so we have at least 3 totally
legitime cases, where we have / in product name, which simply cannot appear
in UNIX filesystem at all.

So, conclusion: if it is indeed intended that further examples of boards
will be added to tools/testing/selftests/devices/boards, then they
will contain all sorts of undesirable chars and notably "/", which cannot
appear in filename at all.

For all these reasons I ask you to change name convention for this directory.
For example, use some kind of sanitized vendor/product names.

> there are
> tons of dt-binding filenames containing commas in the tree.

Okay, I agree with this point. There already are a lot of files with commas.
But I still don't like spaces and all sorts of characters, which are present
in DMI vendor names and product names ( "(" ")" "'" "&" "#" "*" "/" ).

-- 
Askar Safin

Il 22/01/24 19:53, Nícolas F. R. A. Prado ha scritto:
> Add a sample board file describing the file's format and with the list
> of devices expected to be probed on the XPS 13 9300 machine as an
> example x86 platform.
> 
> Test output:
> 
> TAP version 13
> Using board file: boards/Dell Inc.,XPS 13 9300.yaml
> 1..22
> ok 1 /pci-controller/14.0/usb2-controller/9/camera.device
> ok 2 /pci-controller/14.0/usb2-controller/9/camera.0.driver
> ok 3 /pci-controller/14.0/usb2-controller/9/camera.1.driver
> ok 4 /pci-controller/14.0/usb2-controller/9/camera.2.driver
> ok 5 /pci-controller/14.0/usb2-controller/9/camera.3.driver
> ok 6 /pci-controller/14.0/usb2-controller/10/bluetooth.device
> ok 7 /pci-controller/14.0/usb2-controller/10/bluetooth.0.driver
> ok 8 /pci-controller/14.0/usb2-controller/10/bluetooth.1.driver
> ok 9 /pci-controller/2.0/gpu.device
> ok 10 /pci-controller/2.0/gpu.driver
> ok 11 /pci-controller/4.0/thermal.device
> ok 12 /pci-controller/4.0/thermal.driver
> ok 13 /pci-controller/12.0/sensors.device
> ok 14 /pci-controller/12.0/sensors.driver
> ok 15 /pci-controller/14.3/wifi.device
> ok 16 /pci-controller/14.3/wifi.driver
> ok 17 /pci-controller/1d.0/0.0/ssd.device
> ok 18 /pci-controller/1d.0/0.0/ssd.driver
> ok 19 /pci-controller/1d.7/0.0/sdcard-reader.device
> ok 20 /pci-controller/1d.7/0.0/sdcard-reader.driver
> ok 21 /pci-controller/1f.3/audio.device
> ok 22 /pci-controller/1f.3/audio.driver
> Totals: pass:22 fail:0 xfail:0 xpass:0 skip:0 error:0
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
>   .../devices/boards/Dell Inc.,XPS 13 9300.yaml      | 40 ++++++++++++++++++++++
>   1 file changed, 40 insertions(+)
> 
> diff --git a/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml b/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml
> new file mode 100644
> index 000000000000..ff932eb19f0b
> --- /dev/null
> +++ b/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml	
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# This is the device definition for the XPS 13 9300.
> +# The filename "Dell Inc.,XPS 13 9300" was chosen following the format
> +# "Vendor,Product", where Vendor comes from
> +# /sys/devices/virtual/dmi/id/sys_vendor, and Product comes from
> +# /sys/devices/virtual/dmi/id/product_name.
> +#
> +# See google,spherion.yaml for more information.

What if - instead of taking google,spherion.yaml as an example - you create a new
file named something like

"example,device.yaml"

that would be a fantasy device, bringing examples for all .. or most of .. the
currently supported types/devices?

You would also move the nice documentation that you wrote in spherion.yaml to the
new example,device.yaml and ask to refer to that instead in all of the real device
specific definitions.

# SPDX-License-Identifier: GPL-2.0 <--- (GPL-2.0 OR MIT) like device trees perhaps?
#
# This is the device definition for the Example Device
# The filename "Example Device" was chosen following the format
# "Vendor,Product", where:
#  - Vendor is "Example" and comes from /sys/devices/virtual/dmi/id/sys_vendor
#  - Product is "Device" and comes from /sys/devices/virtual/dmi/id/product_name
#
# ....the rest of the blurb goes here
#

- type : .... this that the other
   devices:
     - the least amount of device descriptions that you can use for documenting how
       to write this stuff :-)

Anything against that?

Cheers,
Angelo

> +#
> +- type: pci-controller
> +  # This machine has a single PCI host controller so it's valid to not have any
> +  # key to identify the controller. If it had more than one controller, the UID
> +  # of the controller from ACPI could be used to distinguish as follows:
> +  #acpi-uid: 0
> +  devices:
> +    - path: 14.0
> +      type: usb-controller
> +      usb-version: 2
> +      devices:
> +        - path: 9
> +          name: camera
> +          interfaces: [0, 1, 2, 3]
> +        - path: 10
> +          name: bluetooth
> +          interfaces: [0, 1]
> +    - path: 2.0
> +      name: gpu
> +    - path: 4.0
> +      name: thermal
> +    - path: 12.0
> +      name: sensors
> +    - path: 14.3
> +      name: wifi
> +    - path: 1d.0/0.0
> +      name: ssd
> +    - path: 1d.7/0.0
> +      name: sdcard-reader
> +    - path: 1f.3
> +      name: audio
> 

On Tue, Jan 23, 2024 at 12:08:22PM +0100, AngeloGioacchino Del Regno wrote:
> Il 22/01/24 19:53, Nícolas F. R. A. Prado ha scritto:
> > Add a sample board file describing the file's format and with the list
> > of devices expected to be probed on the XPS 13 9300 machine as an
> > example x86 platform.
> > 
> > Test output:
> > 
> > TAP version 13
> > Using board file: boards/Dell Inc.,XPS 13 9300.yaml
> > 1..22
> > ok 1 /pci-controller/14.0/usb2-controller/9/camera.device
> > ok 2 /pci-controller/14.0/usb2-controller/9/camera.0.driver
> > ok 3 /pci-controller/14.0/usb2-controller/9/camera.1.driver
> > ok 4 /pci-controller/14.0/usb2-controller/9/camera.2.driver
> > ok 5 /pci-controller/14.0/usb2-controller/9/camera.3.driver
> > ok 6 /pci-controller/14.0/usb2-controller/10/bluetooth.device
> > ok 7 /pci-controller/14.0/usb2-controller/10/bluetooth.0.driver
> > ok 8 /pci-controller/14.0/usb2-controller/10/bluetooth.1.driver
> > ok 9 /pci-controller/2.0/gpu.device
> > ok 10 /pci-controller/2.0/gpu.driver
> > ok 11 /pci-controller/4.0/thermal.device
> > ok 12 /pci-controller/4.0/thermal.driver
> > ok 13 /pci-controller/12.0/sensors.device
> > ok 14 /pci-controller/12.0/sensors.driver
> > ok 15 /pci-controller/14.3/wifi.device
> > ok 16 /pci-controller/14.3/wifi.driver
> > ok 17 /pci-controller/1d.0/0.0/ssd.device
> > ok 18 /pci-controller/1d.0/0.0/ssd.driver
> > ok 19 /pci-controller/1d.7/0.0/sdcard-reader.device
> > ok 20 /pci-controller/1d.7/0.0/sdcard-reader.driver
> > ok 21 /pci-controller/1f.3/audio.device
> > ok 22 /pci-controller/1f.3/audio.driver
> > Totals: pass:22 fail:0 xfail:0 xpass:0 skip:0 error:0
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
> >   .../devices/boards/Dell Inc.,XPS 13 9300.yaml      | 40 ++++++++++++++++++++++
> >   1 file changed, 40 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml b/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml
> > new file mode 100644
> > index 000000000000..ff932eb19f0b
> > --- /dev/null
> > +++ b/tools/testing/selftests/devices/boards/Dell Inc.,XPS 13 9300.yaml	
> > @@ -0,0 +1,40 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# This is the device definition for the XPS 13 9300.
> > +# The filename "Dell Inc.,XPS 13 9300" was chosen following the format
> > +# "Vendor,Product", where Vendor comes from
> > +# /sys/devices/virtual/dmi/id/sys_vendor, and Product comes from
> > +# /sys/devices/virtual/dmi/id/product_name.
> > +#
> > +# See google,spherion.yaml for more information.
> 
> What if - instead of taking google,spherion.yaml as an example - you create a new
> file named something like
> 
> "example,device.yaml"
> 
> that would be a fantasy device, bringing examples for all .. or most of .. the
> currently supported types/devices?
> 
> You would also move the nice documentation that you wrote in spherion.yaml to the
> new example,device.yaml and ask to refer to that instead in all of the real device
> specific definitions.
> 
> # SPDX-License-Identifier: GPL-2.0 <--- (GPL-2.0 OR MIT) like device trees perhaps?
> #
> # This is the device definition for the Example Device
> # The filename "Example Device" was chosen following the format
> # "Vendor,Product", where:
> #  - Vendor is "Example" and comes from /sys/devices/virtual/dmi/id/sys_vendor
> #  - Product is "Device" and comes from /sys/devices/virtual/dmi/id/product_name
> #
> # ....the rest of the blurb goes here
> #
> 
> - type : .... this that the other
>   devices:
>     - the least amount of device descriptions that you can use for documenting how
>       to write this stuff :-)
> 
> Anything against that?

That'd also work. Though I feel like a single example file for both a DT-based
and an ACPI-based platform might get unnecessarily confusing (given the
different way for identifying the machine - DMI vs DT compatible - and for
identifying the root level controller - ACPI UID vs DT MMIO).

I also feel like a real machine example is helpful to have.

In my opinion, your suggestion would make much more sense - and be needed even -
if we had several machine files in this directory, so that the documentation
stands out among them. However the feedback that I got from Shuah during
Plumbers was that maintaining per-machine files in-tree wasn't going to happen.
So these two files serve as the documentation, with real-life examples, that
other machines could build upon in a separate repository.

Thanks,
Nícolas