On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
>
> > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> > struct foo {
> > char x;
> > void *p;
> > }; will have 1 byte occupied by x, followed by 1-byte gap, followed by 4 bytes
> > occupied by p.
> >
> > Note, BTW, that m68k includes things like coldfire, etc. and I wouldn't be
> > surprised by e.g. coldfire-based SoC with i2c on it.
>
> BTW, that's easily verified - take a cross-compiler and do this:
> ; cat >a.c <<'EOF'
> struct { char x; void *y; } v;
> int z = (char *)&v.y - (char *)&v;
> EOF
> ; m68k-linux-gnu-gcc -S a.c
> ; grep -A1 'z:' a.s
> z:
> .long 2
> ;
> and watch what it puts into z. gcc is very liberal about what it considers
> a constant expression, so it allows that sort of expressions as initializers
> for global variables. Not a portable C, but convenient for experiments like
> that; just grab a cross-toolchain and feed it testcases of that kind...
... and google for i2c coldfire immediately turns up this:
http://mailman.uclinux.org/pipermail/uclinux-dev/2012-May/051874.html
with
+config I2C_COLDFIRE
+ tristate "Freescale Coldfire I2C driver"
+ depends on !M5272
+ help
+ This driver supports the I2C interface availible on most Freescale
+ Coldfire processors.
+
+ This driver can be built as a module. If so, the module
+ will be called i2c-coldfire.
in it, along with addition of drivers/i2c/busses/i2c-coldfire.c... IOW,
i2c on m68k is quite real. Sorry, no go - you don't even have an excuse
of i2c never existing on the architecture in question.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
