On Fri, Aug 15, 2008 at 02:11:31AM -0700, Andrew Morton wrote:
> On Fri, 15 Aug 2008 11:52:48 +0300 Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote:
>
> > Wonder if it's possible to have the above patch applied so I can get rid
> > of those stubs in musb_io.h
>
> Someone would need to take care of it and document it and repair all
> those driver which broke because they went and created private copies.
>
> I could do some of that but I'm stuck at step #1. What the heck _are_
> these things? Why do they exist? What are their semantics?
>
> The arm implementation says
>
> * Generic IO read/write. These perform native-endian accesses. Note
> * that some architectures will want to re-define __raw_{read,write}w.
>
> which is somewhat clear as mud. I'd guess that these are the MMIO
> partners to insl and friends?
Yes.
> And then it has
>
> extern void __raw_writesb(void __iomem *addr, const void *data, int bytelen);
> extern void __raw_writesw(void __iomem *addr, const void *data, int wordlen);
> extern void __raw_writesl(void __iomem *addr, const void *data, int longlen);
>
> which is a bit odd.
Shrug. Everything is not a PC. I don't see anything odd about the above.
We basically implement a standard set of IO macros (the __raw_*) stuff
which is used to implement the standard set of IO support (inl, insl)
and provide a set of extensions for our platforms (readsl to complement
insl - named precisely the same way because that's what they are) because
the generic stuff doesn't cover all our needs.
> I assume that "bytelen" should have been "bytecount" or similar.
bytelen and bytecount mean the same thing to me.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
