Re: [PATCH 4/5] platform/x86/intel/ifs: Implement Array BIST test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 01, 2023 at 05:22:18PM +0000, Luck, Tony wrote:
> > > +/* MSR_ARRAY_BIST bit fields */
> > > +union ifs_array {
> > > +   u64     data;
> > > +   struct {
> > > +           u32     array_bitmask           :32;
> > > +           u32     array_bank              :16;
> > > +           u32     rsvd                    :15;
> > > +           u32     ctrl_result             :1;
> >
> > This isn't going to work well over time, just mask the bits you want off
> > properly, don't rely on the compiler to lay them out like this.
> 
> What is this "time" issue?  This driver is X86_64 specific (and it seems
> incredibly unlikely that some other architecture will copy this h/w
> interface so closely that they want to re-use this driver. There's an x86_64
> ABI that says how bitfields in C are allocated. So should not break moving
> to other C compilers.

Ok, but generally this is considered a "bad idea" that you should not
do.  It's been this way for many many years, just because this file only
runs on one system now, doesn't mean you shouldn't use the proper apis.

Also, odds are, using the proper apis will get you faster/smaller code
than using a bitfield like this as compilers were notorious for doing
odd things here in the past.

> Is there going to be a "re-write all drivers in Rust" edict coming soon?

Don't be silly, it's been this way for drivers for decades.

> 
> > Note, we have bitmask and bitfield operations, please use them.
> 
> We do, but code written using them is not as easy to read (unless
> you wrap in even more macros, which has its own maintainability
> issues).

It shouldn't be that hard, lots of people use them today.

Try and see!

thanks,

greg k-h



[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux