[ARM] head.S change broke platform device registration?

[richard.purdie@linuxfoundation.org (Richard Purdie)]

On Wed, 2012-12-12 at 17:59 +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 12, 2012 at 03:55:45PM +0000, Richard Purdie wrote:
> > On Tue, 2012-12-11 at 00:25 +0000, Russell King - ARM Linux wrote:
> > > On Mon, Dec 10, 2012 at 06:21:52PM +0100, Marko Kati? wrote:
> > > > > The code which distinguishes between Borzoi and Akita is this:
> > > > >
> > > > > /* Check for a second SCOOP chip - if found we have Borzoi */
> > > > >         ldr     r1, .SCOOP2ADDR
> > > > > ==cacheline boundary without patch (0x120)=====
> > > > >         ldr     r7, .BORZOIID
> > > > >         mov     r6, #0x0140
> > > > >         strh    r6, [r1]
> > > > > ==cacheline boundary with patch (0x160)======
> > > > >         ldrh    r6, [r1]
> > > > >         cmp     r6, #0x0140
> > > > >         beq     .SHARPEND                       @ We have Borzoi
> > > > >
> > > > > /* Must be Akita */
> > > > >         ldr     r7, .AKITAID
> > > > >         b       .SHARPEND                       @ We have Borzoi
> > > > >
> > > > > and I've marked where the cache line boundary ends up with the patch
> > > > > in place... except of course that the caches are off here, so the
> > > > > placement of the code should be irrelevant.  It also would have the
> > > > > reverse results from those that you're experiencing.
> > > > >
> > > > > My guess is that because the Scoop2 device is not present, the strh
> > > > > access places 0x140 onto the data bus.  By the time the ldrh is
> > > > > executed, it reads the data bus, and because nothing drives it, it
> > > > > reads back the value last present on the bus, which happens to be
> > > > > 0x140 - and this allows us to think we have the Scoop2 device.
> > > > >
> > > > > In theory, because the caches are off (including the instruction
> > > > > cache) the CPU should fetch ldrh between the strh write and the
> > > > > ldrh access to the same address.
> > > > >
> > > > > Having said all that, I'm not impressed by the above code; to write to
> > > > > a memory region which may or may not have a device, and immediately
> > > > > read it back is a recipe for exactly this kind of stuff happening.  If
> > > > > anyone has looked at any real device detection code, they'll know that
> > > > > this sequence is typical:
> > > > >
> > > > >         ldr     r0, =address
> > > > >         mov     r1, #probe_data
> > > > >         eor     r2, r1, #~0
> > > > >         str     r1, [r0, #reg1]
> > > > >         str     r2, [r0, #reg2]
> > > > >         ldr     r3, [r0, #reg1]
> > > > >         ldr     r0, [r0, #reg2]
> > > > >         teq     r1, r3
> > > > >         teqeq   r2, r0
> > > > >         beq     found
> > > > >
> > > > > This sequence _purposely_ writes the opposite value between the first
> > > > > store and the read-back of it to perturb the bus in case it's floating,
> > > > > to prevent exactly these kinds of false positives.  The second check is
> > > > > additional belt and braces to make the check even more secure.
> > > > >
> > > > > Can we do that with Scoop2?  I've no idea, I don't know what the weird
> > > > > 0x40 offset is that's being probed by this code.  We need whoever wrote
> > > > > this code, but I suspect they've long since moved on and aren't
> > > > > interested in it.
> > 
> > I suspect this was me and I was missing some of the subtleties in this
> > case. I think the eor to perturb the bus should be fine and fix this
> > code.
> 
> Except... we're currently hitting the register at 0x08800040 (presumably
> a 64-byte offset) which doesn't appear in the scoop header file... so
> I'm not sure if this is a special register or not for this.  Also we need
> to know another register for the 2nd access which isn't going to cause
> problems.  Any suggestions?

Looking at spitz.c (which is the one which handles borzoi):

/* SCOOP Device #2 */
static struct resource spitz_scoop_2_resources[] = {
	[0] = {
		.start		= 0x08800040,
		.end		= 0x08800fff,
		.flags		= IORESOURCE_MEM,
	},
};

so we're reading SCOOP_MCR (offset 0x00). For the second register, I'd
suggest something from the reset code in scoop.c: 	iowrite16(0x00FF,
sdev->base + SCOOP_IRM)

looks appropriate since the 0x00ff value should perturb the bus. I'm
guessing MCR is some kind of memory control and handles device reset,
IRM is probably interrupt related and we don't use interrupt
functionality of the GPIO expander.

Does that help?

Cheers,

Richard