On Sat, 19 Apr 2008, Al Viro wrote:
> ... and while we are at it,
> for (miter = 0, s = optrom, d = dwptr;
> miter < OPTROM_BURST_DWORDS; miter++, s++, d++)
> *s = cpu_to_le32(*d);
>
> ret = qla2x00_load_ram(ha, optrom_dma,
> flash_data_to_access_addr(faddr),
> OPTROM_BURST_DWORDS);
>
> in qla24xx_write_flash_data() looks bloody odd. We have dwptr pointing
> to fixed-endian data, so conversion gets us host-endian and then we pass
> the area filled with results of conversion for DMA?
>
> And yes, dwptr points to fixed-endian - it comes from
> qla24xx_write_optrom_data(struct scsi_qla_host *ha, uint8_t *buf,
> uint32_t offset, uint32_t length)
> {
> ...
> rval = qla24xx_write_flash_data(ha, (uint32_t *)buf, offset >> 2,
> length >> 2);
>
> Comments?
Sure, you're not understanding the format of the various pieces of
data as they flow through the driver (often times opaquely)...
Look at this code from qla_init.c:qla24xx_load_risc_flash():
...
qla24xx_read_flash_data(ha, dcode, faddr, dlen);
for (i = 0; i < dlen; i++)
dcode[i] = swab32(dcode[i]);
rval = qla2x00_load_ram(ha, ha->request_dma, risc_addr, dlen);
...
why the explicit swab32()? Because at production time the data was
written in big-endian format. Yet, when the driver used to carry the
firmware within the driver, the FW folks built the corresponding .C
file of the array of 32-bit words in little-endian format... There's
a similar case for the code in qla24xx_load_risc() where the .bin file
read via request_firmware() was generated in big-endian format...
Why? Well...sometimes "stuff" happens and we accept things...
Look, rather than pick apart (the rat hole) each access-region within
flash and determine which endian-format is used during read and
write, let me just say that we'll continue to be extra-cautious when
adding features which interact with the ISPs little-endian RISC and
various BE/LE regions of flash...
Thanks again for your endianess-scrubbing of qla2xxx, I do appreciate
your time and efforts and should have patches submitted shortly for
much of the 'badness' reported.
Thanks,
Andrew Vasquez
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
