[alsa-devel] [PATCH] [RFC 3/13] Intel SST driver include headers

[Harsha, Priya]

>>
>> >>
>> >> >> +/* Firmware Version info */
>> >> >> +struct snd_sst_fw_version {
>> >> >> +	__u8 build;	/* build number*/
>> >> >> +	__u8 minor;	/* minor number*/
>> >> >> +	__u8 major;	/* major number*/
>> >> >> +	__u8 type; /* build type*/
>> >> >> +};
>> >> >> +
>> >> >> +/* Port info structure */
>> >> >> +struct snd_sst_port_info {
>> >> >> +	__u16 port_type;
>> >> >
>> >> >Just wondering -- is there big-endian support?
>> >> We have not tested this on big-endian, Could you tell us that should
>> >> we make it endian safe?
>> >
>> >When a field is more than one byte, you'd need endian conversion at
>> >read/write.  I didn't find it thus I suspected it.
>> So, does it look safe to keep the code as such?
>
>Unlikely...
>
>> We are using the bit
>> field in union only for ease of setting/getting bit values and not
>> for communication.
>
>What I meant is the data used for the communication.  Not the
>communication method itself.  Here the communication includes the
>firmware data, too.
>
>If the data is created by the driver locally and used only inside the
>driver, then it's fine.  Otherwise, you shouldn't use bit fields.


Yes. This is the case. The data is generated internally to the driver and used inside the driver only. When the data is communicated to the firmware, only the 32bit register is passed and the bit fields are not used.

Thanks,
Harsha