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

[Chunfeng Yun]

Hi Marek & Simon,


Firstly, thanks for your suggestion and discussion.

As Simon guess, MediaTek indeed has some policies to avoid to move
registers around for USB IP, I think we will not encounter the
worst-case scenarios as Marek mentioned. Due to there is only a little
registers, both struct and macros approach are OK for me.

And in a word, I tend to agree with Simon's opinion, choose struct or
macro approach, case by case, after weigh the pros and cons. But Marek
is the maintainer of USB subsystem, so I'd better to make him happy, and
should follow his suggetions:)

Again, thank you guys


On Sun, 2020-03-22 at 16:34 +0100, Marek Vasut wrote:
> On 3/22/20 4:17 PM, Simon Glass wrote:
> > Hi Marek,
> 
> Hi,
> 
> > 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?
> 
> It's also very difficult to easily figure out the address of a register
> that's buried somewhere down in a long structure, possibly with embedded
> sub-structures.
> 
> > 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.
> 
> Well, like I said, my experience tells me the struct approach was a big
> mistake in multiple places, so I would prefer macros here.
>