Hi Marek,
On Sat, 21 Mar 2020 at 09:09, Marek Vasut <ma...@denx.de> wrote:
>
> On 3/21/20 3:12 PM, Simon Glass wrote:
> > Hi Marek,
> >
> > On Wed, 11 Mar 2020 at 01:11, Marek Vasut <ma...@denx.de> wrote:
> >>
> >> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
> >> [...]
> >>> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are
> >>> used
> >>> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are
> >>> used
> >>> + * @u2_phy_pll: usb2 phy pll control register
> >>> + */
> >>> +struct mtk_ippc_regs {
> >>> + __le32 ip_pw_ctr0;
> >>> + __le32 ip_pw_ctr1;
> >>> + __le32 ip_pw_ctr2;
> >>
> >> Please define the registers with #define macros , this struct-based
> >> approach doesn't scale.
> >>
> >
> > What does this mean? I much prefer the struct approach, unless the
> > registers move around in future generations.
>
> This means I want to see #define MTK_XHCI_<register name> 0xf00
>
> The struct based approach doesn't scale and on e.g. altera is causing us
> a massive amount of problems now. It looked like a good idea back then,
> but now it's a massive burden, so I don't want that to proliferate. And
> here I would expect the registers to move around, just like everywhere else.
That sounds like something that is easily avoided. For example,
Designware doesn't seem to move things around.
Perhaps MediaTek has a policy of not doing this either?
Regards,
Simon
