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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
