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

[Takashi Iwai]

At Tue, 7 Jul 2009 12:21:00 +0530,
Harsha, Priya wrote:
> 
> >>
> >> >>
> >> >> >> +/* 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.

Hm, then I misread the code too quickly.
I thought the 32bit data is generated from the bit fields in a way
depending on the architecture.


Takashi