Messages in this thread | | | From | OSDL <> | Subject | Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4 | Date | Sat, 26 Jul 2003 12:17:01 -0700 |
| |
Stefan Jones wrote: > > I added > > printk(KERN_DEBUG "yenta_get_status: status=%04x\n",state); > > after the call > u32 state = cb_readl(socket, CB_SOCKET_STATE); > in > static int yenta_get_status(struct pcmcia_socket *sock, unsigned int > *value) > in drivers/pcmcia/yenta_socket.c > > in both 2.4.21 and 2.6.0-test1 > > 2.6.0-test1 gives: 30000411 > 2.4.21 gives: 30000419 > > I wonder why the values are different, and yet fairly close. It is > enough to give hard lockups ( I debugged this one with printk's and > commenting out code ) > > I have added > > state |= CB_CBCARD;
The difference between 2.4 and 2.6 is not CB_CBCARD (0x0020), but CB_PWRCYCLE (0x0008).
For some reason 2.6.x hasn't powered up the 16-bit card.
However, the whole CB_POWERCYCLE thing is ignored for 16-bit cards, and what you end up doing by marking the card as a 32-bit cardbus card (that's what the CB_CBCARD define means) is to basically force the wrong code to be run, at which point the 32-bit code decides that the card isn't powered.
The real question is why the card isn't powered up. Also, it sounds like the 16-bit status (from I365_STATUS) doesn't agree with the 32-bit status (from CB_SOCKET_STATE), so when you _do_ force trusting of the 32-bit status, then things work.
Which is interesting in itself. It's entirely possible that we should just ignore the 16-bit status when it comes to the SS_POWERON logic.
Does the card actually _work_ when you do your hack? Or does it just stop the hang?
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |