[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] PCI: drop pci_segments_init()
On 2/26/25 06:38, Jan Beulich wrote: > Have callers invoke pci_add_segment() directly instead: With radix tree > initialization moved out of the function, its name isn't quite > describing anymore what it actually does. > > On x86 move the logic into __start_xen() itself, to reduce the risk of > re-introducing ordering issues like the one which was addressed by > 26fe09e34566 ("radix-tree: introduce RADIX_TREE{,_INIT}()"). > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > --- > This is entirely optional and up for discussion. There certainly also is > an argument towards keeping the function. Otoh on Arm there is the still > open question whether segment 0 really is kind of special there (as it > is on x86, largely for historical reasons), or whether the code can be > dropped there altogether. Segment 0 is not special on Arm as far as I'm aware. You can have a perfectly functioning system with only, say, segment 1, for example: (XEN) ==== PCI devices ==== (XEN) ==== segment 0001 ==== (XEN) 0001:00:01.0 - d0 - node -1 (XEN) 0001:00:00.0 - d0 - node -1 Segment numbers can be arbitrarily chosen by specifying the linux,pci-domain device tree property. > --- > v4: Move x86 logic into __start_xen() itself. > v3: Adjust description to account for and re-base over dropped earlier > patch. > v2: New. > > --- a/xen/arch/arm/pci/pci.c > +++ b/xen/arch/arm/pci/pci.c > @@ -88,7 +88,8 @@ static int __init pci_init(void) > if ( !pci_passthrough_enabled ) > return 0; > > - pci_segments_init(); > + if ( pci_add_segment(0) ) > + panic("Could not initialize PCI segment 0\n"); IMO it's okay to remove the call here since there is already a call to pci_add_segment() in xen/arch/arm/pci/pci-host-common.c:pci_host_common_probe() If there happens to be an Arm SoC with segment number quirks, that could be worked out in a SoC-specific xen/arch/arm/pci/pci-host-*.c.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |