On Mar 5, 2013, at 2:40 PM, Wolfgang Denk wrote:

Dear Xu Lei-B33228,

Please do not top post / full quote. Thanks.

In message 8CB6A38ADF9E994697FF8A45E96E085338810E@039-SN1MPN1-004.039d.mgd.msft.net you wrote:

...

Thank you and I agree with you. It is a little ugly but because these registers info are not publicly, so I did not use C struct to describe them, for this case is it ok, or other method such as define a struct but keep all other registers and bits in this register reserved? Thank you.

I'm not throwing in a formal NAK here, but for reasons of consistency (and because others are just too eager to quote such patches as authoritative precedent) I'd prefer the use of a struct.

While I'd prefer a struct as well, unfortunately this isn't something FSL has documented and we publish the erratum write ups with address like this. So when a customer comes and looks for the code its more inline with the erratum writeup.

I'm not sure what value a dummy struct would provide above the explicit addressing utilized in the patch.

Again, I'm not happy about the situation, just not sure what additional value doing something like:

struct dummy_usb_dscr { u8 res[0x520]; u32 erratum_usb14_reg; u8 res[4096-0x524]; };

Its going to be a bit more error prone than the method used when the struct needs updating for a new register field and when someone screws up getting the res[] sizes correct.

- k