On Mon, 19 Nov 2018 at 04:44, Leif Lindholm <leif.lindh...@linaro.org> wrote: > > On Fri, Nov 16, 2018 at 02:04:07PM -0800, Ard Biesheuvel wrote: > > > > > What is this using the exynos4210 USB device for? That > > > > > is definitely not correct for a generic board. > > > > > > > > > Checked the code: > > > > #define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb" > > > > #define TYPE_EXYNOS4210_EHCI "exynos4210-ehci-usb" > > > > #define TYPE_TEGRA2_EHCI "tegra2-ehci-usb" > > > > #define TYPE_PPC4xx_EHCI "ppc4xx-ehci-usb" > > > > #define TYPE_FUSBH200_EHCI "fusbh200-ehci-usb" > > > > > > > > The first one seems only a parent type, not a general instance, cannot > > > > be used directly. > > > > The other four are specific instances using the first as parent type, > > > > one of them can be chosen to use. > > > > That is my understanding, any comments, or do we need to implement one > > > > which seems generic? > > > > > > I think what we *really* want is sysbus-xhci-generic. > > > > > > That'll be a bit more work though as xhci core and xhci pci needs to be > > > splitted, simliar to how it was done for ehci in commit > > > 5010d4dc618b6b8e7c21129c487c06f6493f71fc (and related patches). > > > > > > Or just plug qemu-xhci into a pcie slot. Not sure which would be closer > > > to physical hardware. > > > > We don't need XHCI especially, EHCI is perfectly fine as well. > > > > This is mostly about ensuring that the emulated hardware spans the > > space of what we encounter on real hardware, and non-PCIE SATA and USB > > controllers is something we see often. > > > > So I could live with MMIO SATA and PCI USB as well, but I'd prefer it > > if we could have both MMIO. > > I would actually strongly prefer non-MMIO. > > What "we see" is generally a result of embedded companies "value > adding" in the usual way when moving from embedded to servers. > > I want the SBSA target to be an idealised machine, not an educational > vehicle for showing how companies have got it wrong. > > Where in doubt, anything software discoverable should win over > non-discoverable. >
I don't think it makes sense at all to idealize the SBSA machine in this way. For example, there are elaborate provisions in the IORT spec how to describe an I/O topology involving named components (as opposed to PCIe devices), and I have not seen an arm64 SoC yet that uses PCIe internally for on-chip network controllers, nor do I expect to in the near future. So having non-PCIe USB or SATA will permit us to exercise code paths in the OS that we do rely on in production, and will for the foreseeable future.
