On di, 2005-11-22 at 08:36 +0000, Christoph Hellwig wrote:
> The 53c700 already has a rather awkward mechanism to deal with different
> bus byte orders, I'd suggest you use that now and switch the driver to
> use ioread*be later, without introducing arch-specific config symbols.
I don't really understand the current mechanism. It seems to result in
different behaviour for BE systems depending on the definition of
CONFIG_53C700_LE_ON_BE.
I would have expected the behaviour on BE systems without defining
CONFIG_53C700_LE_ON_BE to be the same as on BE systems with
CONFIG_53C700_LE_ON_BE defined but with hostdata->force_le_on_be set to
0.
Was this driver ever used on BE systems without CONFIG_53C700_LE_ON_BE
being defined?
For reference:
BE with CONFIG_53C700_LE_ON_BE defined but hostdata->force_le_on_be set
to 0:
/* This is terrible, but there's no raw version of ioread32. That means
* that on a be board we swap twice (once in ioread32 and once again to
* get the value correct) */
#define bS_to_io(x) ((hostdata->force_le_on_be) ? (x) : cpu_to_le32(x))
evaluates to
0 ----------> cpu_to_le32(x)
And without CONFIG_53C700_LE_ON_BE defined:
#define bS_to_io(x) (x)
I think this last define should be cpu_to_le32() as well, then the
driver would work on m68k out-of-the-box.
James, can you comment on this?
> Anyway, could you folks please submit what you have now? The 53c7xx hasn't
> worked ever in 2.6.x, and we're gonna remove it for 2.6.16. It would be
> nice to keep the m68k glue drivers switched over to use 53c700 even if there's
> still some odd hacks required to actually make it work - we'll surely sort
> them out once the basics are in.
They wouldn't compile, because I'm not going to submit Romans DMA patch
myself.
Kind regards,
Kars.
-
: 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
