Problems with GSPI

[Dan Williams]

On Sat, 2008-12-20 at 00:19 +0100, Erwin Authried wrote:
> Am Freitag, den 19.12.2008, 16:39 -0500 schrieb Dan Williams:
> > On Sun, 2008-12-14 at 12:47 +0100, Erwin Authried wrote:
> > > Hi,
> > > 
> > > I'm using the 88W8686 in GSPI mode, and I have created a if_gspi module
> > > to be able to use the libertas driver instead of Marvell's original
> > > driver. I tried ad-hoc mode first, and that seems to work fine, I'm
> > > getting event interrupts when a link is lost or re-established. In
> > > managed mode, I can establish a WEP connection using iwconfig, and I'm
> > > getting an interrupt when the link to the AP is lost. I'm not getting
> > > any further event interrupts when the link comes back or goes down
> > > again, however. With wpa supplicant, everything works fine, but I'd
> > > still like to know if it's normal that no events are received in managed
> > > mode, except the first event when the link goes down. I'm using firmware
> > > version gspi 9.70.3p37, but I have seen the same problem with older
> > > firmware and the original Marvell driver as well. I'd like to know if
> > > there's the same problem is there with SD and CF.
> > 
> > Any chance you could try one of the GSPI patches that just got posted?
> I can't use those patches directly because my hardware uses a CPLD that
> does the serial/parallel conversion. But the comments in the source give
> some insight on the correct usage of the registers.
> 
> > We should try to converge on a single GSPI driver so that we can
> > actually try to track down stuff like this.  
> I'm thinking about creating a SPI driver for my hardware to make that
> possible. 
> 
> > In response to the actual
> > question though, when you say "the link comes back", do you mean that
> > the reconnection process initiated by wpa_supplicant is successful and
> > eventually reports CONNECTED?  Can you post some wpa_supplicant logs
> > with "-dddt" full debugging?  AFAIK MAC events should still be
> > generated, though the firmware is sometimes dodgy.  I'd suspect
> > something odd in your GSPI code about clearing the interrupt register
> > correctly, or handling the event correctly when the event packet comes
> > back from the card.  
> 
> With "the link comes back" I mean that I turn the AP on again. I believe

Ok, so you turn off the AP and turn it back on again?  If that's the
case, then no, we don't expect the driver/firmware to reconnect
automatically.  That's what the supplicant does through scanning and
reconnection.  The driver/firmware won't necessarily continually try to
reconnect, because there's no idea when the AP might come back.  When
the connection drops, the supplicant will terminate the association in
the driver, and enter the scan loop, where it will periodically scan for
the highest priority access point and when it's found, try to reconnect.
You won't necessarily get unsolicited MAC association events when you
turn the AP back on because the association has been torn down already.
Roaming/reassoc is done by the supplicant.

So I think what you're seeing is expected.

Dan

> that an interrupt should signal somethink like a "link sensed" event. I
> have observed, however, that there is no interrupt at all, neither with
> the manual iwconfig configuration nor the supplicant. When the
> supplicant is used, however, it seems to do some kind of polling on the
> driver to detect the link status, and I can see a "CONNECTED" after a
> couple of seconds. It's well possible that I'm doing something wrong in
> my gspi driver, that's why I asked if other people see the same
> phenomenon with SDIO or CF. I'll take a look at the brand new GSPI
> patches at the beginning of next week.
> 
> > Then I'd suspect the firmware, then next the driver
> > event handling code.  To diagnose though, we'd need some visibility into
> > how the actual GSPI code you wrote works, or we can all try to use the
> > same code (ie, Colin McCabe's patch or something).
> > 
> > Dan
> > 
> > 
> 
> -Erwin
> 
>