Hi Yuquan,
On Fri, Jun 02, 2023 at 11:24:11 +0800, Yuquan Wang wrote:
> > > > To skip the migration hazard, my prefernece is we just leave the EHCI
> > > > device in for now, and add a separate XHCI on PCIe. We can drop the
> > > > EHCI device at some point in the future.
> > >
> > > Why PCIe for the XHCI and not sysbus? At the time the board
> > > was originally added the argument was in favour of using
> > > a sysbus USB controller (you can see Ard making that point
> > > in the linked archive thread).
> >
> > The original argument was that having the device on the sysbus
> > 1) enabled codepaths we wanted to exercise and
>
> Sorry, for my poor engineering experience, I am confused about the meaning
> of "enabled codepaths" here. Is it like a code target that to realize the
> original purpose of this board ?
It is a bit of a convoluted term.
sbsa-ref isn't a normal platform. We are using it as a vehicle for
developing and verifying common firmware and software for sbsa (or now
SystemReady SR) compliant platforms.
This means that we ideally want it to expose *permitted* but not
necessarily ideal behaviours, so that the parts of software that deals
with those situations get frequently exercised (enabled).
It's code coverage for the hw-interacting pieces of code.
/
Leif
