lkml.org 
[lkml]   [2003]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4
Date
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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.598 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site