[PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller

Simon Glass sjg at chromium.org
Sun Mar 22 16:17:36 CET 2020

Hi Marek,

On Sat, 21 Mar 2020 at 20:15, Marek Vasut <marex at denx.de> wrote:
> On 3/22/20 3:08 AM, Simon Glass wrote:
> > Hi Marek,
> Hi,
> > I think at this point we've covered all the ground and mentioned the
> > pros and cons of each method, so I'll leave the discussion where it
> > is.
> Great, so let's remove the struct-based access from the driver and use
> regular #define REGISTER 0xoffset.

I think any individual decision depends on the pros and cons we
outlined in our discussion. I don't have any information to suggest
that the Mediatek XHCI driver has any of the variations you talked
about in your worst-case scenarios, so I can't comment on that. I am
more concerned about this as a general rule as I feel that the
struct-based approach is generally best for U-Boot, except for the
cases you highlighted:

- where the registers appear at different offsets in different
hardware revisions served by the same driver
- where the driver only uses a small subset of the registers and it is
not worth defining a struct to cover them all, with associated empty
regions, etc.

Anything else?

This is a USB driver and you are the USB maintainer, so your decision
is OK with me. For driver model in general I feel that struct access
should be the default, but individual maintainers with strong views on
their subsystem need to have preference.


More information about the U-Boot mailing list