On Tue, 2018-05-29 at 08:18 +0300, Kalle Valo wrote:
> <pks...@realtek.com> writes:
>
> > From: Ping-Ke Shih <pks...@realtek.com>
> >
> > The format of C2H data is ID(1 byte) + Length(1 byte) + value, and it is
> > more readable to use macros to access C2H data.
> >
> > Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
>
> [...]
>
> > --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
> > +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
> > @@ -177,6 +177,11 @@ enum rtl_c2h_evt_v2 {
> > C2H_V2_CCX_RPT = 0x0F,
> > };
> >
> > +#define GET_C2H_CMD_ID(c2h) ({u8 *__c2h = c2h; __c2h[0]; })
> > +#define GET_C2H_SEQ(c2h) ({u8 *__c2h = c2h; __c2h[1]; })
> > +#define C2H_DATA_OFFSET 2
> > +#define GET_C2H_DATA_PTR(c2h) ({u8 *__c2h = c2h;
> > &__c2h[C2H_DATA_OFFSET]; })
>
> These macros are not really pretty, a proper static inline function
> would be a much better choise. But I'm planning to apply this patch
> anyway, I don't think it's a blocker but a good idea to cleanup later.
>
> And rtlwifi really should get away with this foo[0] and foo[1] style of
> buffers and switch to proper structs (foo->bar and foo->koo).
Thanks for your review and suggestion.
Because C2H data is little endian order, the struct will look like
struct foo {
#ifdef __LITTLE_ENDIAN
u8 bar:4;
u8 koo:4;
#else
u8 koo:4;
u8 bar:4;
#endif
}
Is this a linux convention?
Regards
PK
