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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:29 EST