All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Vallejo <agarciav@amd.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Alistair Francis" <alistair.francis@wdc.com>,
	"Bob Eshleman" <bobbyeshleman@gmail.com>,
	"Connor Davis" <connojdavis@gmail.com>,
	"Oleksii Kurochko" <oleksii.kurochko@gmail.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h
Date: Fri, 6 Jun 2025 12:21:32 +0200	[thread overview]
Message-ID: <DAFDIY3ZUD7P.25YOTSEIDV71M@amd.com> (raw)
In-Reply-To: <20e6673b-bf85-4f9d-9938-7005a481b898@suse.com>

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


  reply	other threads:[~2025-06-06 10:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05 19:47 [PATCH v2 00/15] Allow x86 to unflatten DTs Alejandro Vallejo
2025-06-05 19:47 ` [PATCH v2 01/15] xen: Clean up asm-generic/device.h Alejandro Vallejo
2025-06-06  6:51   ` Jan Beulich
2025-06-06  9:55     ` Alejandro Vallejo
2025-06-06 10:03       ` Jan Beulich
2025-06-06 10:21         ` Alejandro Vallejo [this message]
2025-06-05 19:47 ` [PATCH v2 02/15] arm/gnttab: Break links between asm/grant_table.h and xen/grant_table.h Alejandro Vallejo
2025-06-06  6:52   ` Jan Beulich
2025-06-06 10:02     ` Alejandro Vallejo
2025-06-06 10:07       ` Jan Beulich
2025-06-06 10:30         ` Alejandro Vallejo
2025-06-06 12:23           ` Jan Beulich
2025-06-05 19:47 ` [PATCH v2 03/15] xen/dt: Add BOOTMOD_MICROCODE Alejandro Vallejo
2025-06-06  8:47   ` Orzel, Michal
2025-06-05 19:47 ` [PATCH v2 04/15] x86: Preinitialise all modules to be of kind BOOTMOD_UNKNOWN Alejandro Vallejo
2025-06-05 19:47 ` [PATCH v2 05/15] x86: Replace boot_module with bootmodule Alejandro Vallejo
2025-06-05 19:47 ` [PATCH v2 06/15] xen: Refactor kernel_info to have a header like boot_domain Alejandro Vallejo
2025-06-05 19:47 ` [PATCH v2 07/15] x86: Replace boot_domain with bootdomain Alejandro Vallejo
2025-06-06 23:28   ` Stefano Stabellini
2025-06-09  8:57     ` Alejandro Vallejo
2025-06-09 16:56       ` Stefano Stabellini
2025-06-05 19:48 ` [PATCH v2 08/15] xen/dt: Move bootfdt functions to xen/bootfdt.h Alejandro Vallejo
2025-06-06  8:59   ` Orzel, Michal
2025-06-06 10:08     ` Alejandro Vallejo
2025-06-06 19:59       ` Stefano Stabellini
2025-06-09  8:59         ` Alejandro Vallejo
2025-06-09 16:55           ` Stefano Stabellini
2025-06-05 19:48 ` [PATCH v2 09/15] xen/dt: Move bootinfo functions to a new bootinfo.h Alejandro Vallejo
2025-06-06 23:39   ` Stefano Stabellini
2025-06-05 19:48 ` [PATCH v2 10/15] xen/dt: Rename bootfdt.c -> bootinfo-fdt.c Alejandro Vallejo
2025-06-05 19:48 ` [PATCH v2 11/15] xen/dt: Move bootinfo-independent helpers out of bootinfo-fdt.c Alejandro Vallejo
2025-06-06 23:43   ` Stefano Stabellini
2025-06-05 19:48 ` [PATCH v2 12/15] xen/dt: Extract helper to map nodes to module kinds Alejandro Vallejo
2025-06-05 19:48 ` [PATCH v2 13/15] xen/dt: ifdef out DEV_DT-related bits from device_tree.{c,h} Alejandro Vallejo
2025-06-06 23:54   ` Stefano Stabellini
2025-06-05 19:48 ` [PATCH v2 14/15] xen/dt: Allow CONFIG_DOM0LESS_BOOT to include device-tree/ Alejandro Vallejo
2025-06-06 23:55   ` Stefano Stabellini
2025-06-05 19:48 ` [PATCH v2 15/15] kconfig: Allow x86 to pick CONFIG_DOM0LESS_BOOT Alejandro Vallejo
2025-06-06 23:57   ` Stefano Stabellini

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=DAFDIY3ZUD7P.25YOTSEIDV71M@amd.com \
    --to=agarciav@amd.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=bobbyeshleman@gmail.com \
    --cc=connojdavis@gmail.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.