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@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.