There's some pretense this header may be used without
CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
that option, and it fully overrides this header, typedeffing struct
pci_dev to be device_t.

Furthermore there's an include for xen/device_tree.h halfway through the
header, but that header already includes asm/device.h, creating a cycle.

Clean up the header removing ifdef guards, merging the typedef onto the
struct definition for device_t and removing the spurious include.

The only affected file is aplic.c, in riscv, which is forced now to
include device_tree.h directly.

Not a functional change.

Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
v2:
  * Add new comment and ifdef guard with #error
---
 xen/arch/riscv/aplic.c           |  3 ++-
 xen/include/asm-generic/device.h | 26 ++++++++++----------------
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 10ae81f7ac..dd7a274c52 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,13 +9,14 @@
  * Copyright (c) 2024-2025 Vates
  */
 
+#include <xen/device_tree.h>
 #include <xen/errno.h>
 #include <xen/init.h>
+#include <xen/lib.h>
 #include <xen/irq.h>
 #include <xen/sections.h>
 #include <xen/types.h>
 
-#include <asm/device.h>
 #include <asm/intc.h>
 
 static struct intc_info __ro_after_init aplic_info = {
diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-generic/device.h
index 1acd1ba1d8..631dab046a 100644
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
@@ -1,14 +1,20 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * This header helps DTB-based architectures abstract away where a particular
+ * device came from, be it the DTB itself or enumerated on a PCI bus.
+ */
 #ifndef __ASM_GENERIC_DEVICE_H__
 #define __ASM_GENERIC_DEVICE_H__
 
+#ifndef CONFIG_HAS_DEVICE_TREE
+#error "Header for exclusive use of DTB-based architectures"
+#endif
+
 #include <xen/stdbool.h>
 
 enum device_type
 {
-#ifdef CONFIG_HAS_DEVICE_TREE
     DEV_DT,
-#endif
     DEV_PCI
 };
 
@@ -23,23 +29,15 @@ enum device_class
 };
 
 /* struct device - The basic device structure */
-struct device
+typedef struct device
 {
     enum device_type type;
-#ifdef CONFIG_HAS_DEVICE_TREE
     struct dt_device_node *of_node; /* Used by drivers imported from Linux */
-#endif
 #ifdef CONFIG_HAS_PASSTHROUGH
     void *iommu; /* IOMMU private data */;
     struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU instance data */
 #endif
-};
-
-typedef struct device device_t;
-
-#ifdef CONFIG_HAS_DEVICE_TREE
-
-#include <xen/device_tree.h>
+} device_t;
 
 #define dev_is_dt(dev)  ((dev)->type == DEV_DT)
 
@@ -87,10 +85,6 @@ struct device_desc {
     int (*init)(struct dt_device_node *dev, const void *data);
 };
 
-#else /* !CONFIG_HAS_DEVICE_TREE */
-#define dev_is_dt(dev) ((void)(dev), false)
-#endif /* CONFIG_HAS_DEVICE_TREE */
-
 #define dev_is_pci(dev) ((dev)->type == DEV_PCI)
 
 #ifdef CONFIG_ACPI
-- 
2.43.0

On 05.06.2025 21:47, Alejandro Vallejo wrote:
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -1,14 +1,20 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * This header helps DTB-based architectures abstract away where a particular
> + * device came from, be it the DTB itself or enumerated on a PCI bus.
> + */
>  #ifndef __ASM_GENERIC_DEVICE_H__
>  #define __ASM_GENERIC_DEVICE_H__
>  
> +#ifndef CONFIG_HAS_DEVICE_TREE
> +#error "Header for exclusive use of DTB-based architectures"
> +#endif
> +
>  #include <xen/stdbool.h>
>  
>  enum device_type
>  {
> -#ifdef CONFIG_HAS_DEVICE_TREE
>      DEV_DT,
> -#endif
>      DEV_PCI
>  };

My objection to these changes remains; as a generic header it ought to be what
that attribute says - generic.

Jan

On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>> --- a/xen/include/asm-generic/device.h
>> +++ b/xen/include/asm-generic/device.h
>> @@ -1,14 +1,20 @@
>>  /* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * This header helps DTB-based architectures abstract away where a particular
>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>> + */
>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>  #define __ASM_GENERIC_DEVICE_H__
>>  
>> +#ifndef CONFIG_HAS_DEVICE_TREE
>> +#error "Header for exclusive use of DTB-based architectures"
>> +#endif
>> +
>>  #include <xen/stdbool.h>
>>  
>>  enum device_type
>>  {
>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>      DEV_DT,
>> -#endif
>>      DEV_PCI
>>  };
>
> My objection to these changes remains; as a generic header it ought to be what
> that attribute says - generic.
>
> Jan

It is generic for any architecture where platform DTs exist (that is, anything
but x86).

As the commit message states, these guards are useless, provide no functionality
and create the fiction that somehow this header is still relevant on an
architecture where only PCI is available. And that's just not true. x86 being
the sole architecture without DTs actively overrides it, and relies on device_t
(defined as struct device here) to be a "struct pci_dev" instead in
x86/include/asm/device.h, with dev_to_pci() and pci_to_dev() being irrelevant
because device_t* and struct pci_dev* are identical types in x86. Removing that
override header is not just a matter of performance. All the IOMMU ops are
referencing device_t, while the drivers are assuming pci_dev, so all IOMMU
code breaks immediately when x86 tries to use this.

To be perfectly clear, this patch isn't strictly required to do DT unflattening
on x86. But it's a piece of arm tech debt that Xen is better off without.

Cheers,
Alejandro

On 06.06.2025 11:55, Alejandro Vallejo wrote:
> On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>> --- a/xen/include/asm-generic/device.h
>>> +++ b/xen/include/asm-generic/device.h
>>> @@ -1,14 +1,20 @@
>>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * This header helps DTB-based architectures abstract away where a particular
>>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>>> + */
>>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>>  #define __ASM_GENERIC_DEVICE_H__
>>>  
>>> +#ifndef CONFIG_HAS_DEVICE_TREE
>>> +#error "Header for exclusive use of DTB-based architectures"
>>> +#endif
>>> +
>>>  #include <xen/stdbool.h>
>>>  
>>>  enum device_type
>>>  {
>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>      DEV_DT,
>>> -#endif
>>>      DEV_PCI
>>>  };
>>
>> My objection to these changes remains; as a generic header it ought to be what
>> that attribute says - generic.
> 
> It is generic for any architecture where platform DTs exist (that is, anything
> but x86).

Here you're limiting things to what Xen presently "knows". I'm sure there are
other architectures where DT is entirely unknown.

Furthermore isn't the work here part of the hyperlaunch effort, where DT will
be introduced to x86? Hence "anything but" isn't quite right either then.

Jan

> As the commit message states, these guards are useless, provide no functionality
> and create the fiction that somehow this header is still relevant on an
> architecture where only PCI is available. And that's just not true. x86 being
> the sole architecture without DTs actively overrides it, and relies on device_t
> (defined as struct device here) to be a "struct pci_dev" instead in
> x86/include/asm/device.h, with dev_to_pci() and pci_to_dev() being irrelevant
> because device_t* and struct pci_dev* are identical types in x86. Removing that
> override header is not just a matter of performance. All the IOMMU ops are
> referencing device_t, while the drivers are assuming pci_dev, so all IOMMU
> code breaks immediately when x86 tries to use this.
> 
> To be perfectly clear, this patch isn't strictly required to do DT unflattening
> on x86. But it's a piece of arm tech debt that Xen is better off without.
> 
> Cheers,
> Alejandro

On Fri Jun 6, 2025 at 12:03 PM CEST, Jan Beulich wrote:
> On 06.06.2025 11:55, Alejandro Vallejo wrote:
>> On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
>>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>>> --- a/xen/include/asm-generic/device.h
>>>> +++ b/xen/include/asm-generic/device.h
>>>> @@ -1,14 +1,20 @@
>>>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>>> +/*
>>>> + * This header helps DTB-based architectures abstract away where a particular
>>>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>>>> + */
>>>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>>>  #define __ASM_GENERIC_DEVICE_H__
>>>>  
>>>> +#ifndef CONFIG_HAS_DEVICE_TREE
>>>> +#error "Header for exclusive use of DTB-based architectures"
>>>> +#endif
>>>> +
>>>>  #include <xen/stdbool.h>
>>>>  
>>>>  enum device_type
>>>>  {
>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>      DEV_DT,
>>>> -#endif
>>>>      DEV_PCI
>>>>  };
>>>
>>> My objection to these changes remains; as a generic header it ought to be what
>>> that attribute says - generic.
>> 
>> It is generic for any architecture where platform DTs exist (that is, anything
>> but x86).
>
> Here you're limiting things to what Xen presently "knows". I'm sure there are
> other architectures where DT is entirely unknown.

You'll struggle a lot to find one such arch unless you want to revive the
itanium port, and even then itanium would simply re-use x86's asm override.

>
> Furthermore isn't the work here part of the hyperlaunch effort, where DT will
> be introduced to x86? Hence "anything but" isn't quite right either then.
>
> Jan

Not a general DTB, no. A DTB defines the platform (in the same vein as a ACPI/
DSDT), with all platform devices enumerated there. x86 will not get any of that.

Without devices defined in the DTB, my original point still stands.

In general, if you don't have DT devices you typedef device_t to pci_dev to
avoid these wrappers altogether, and if you do you don't and the ifdef guards
stop having meaning.

If you remain unconvinced and others don't pitch in I'll just drop it from v3.
As I said, it's not essential.

Cheers,
Alejandro