[Prism54-devel] Re: wireless API semantics when netif down?

[Herbert Valerio Riedel]

On Tue, Nov 25, 2003 at 07:10:55PM -0800, Jean Tourrilhes wrote:
> On Tue, Nov 25, 2003 at 11:25:32AM +0100, Herbert Valerio Riedel wrote:
> > On Tue, Nov 25, 2003 at 10:54:26AM +0100, Bjørn Mork wrote:
> > [..]
> > > The best solution would of course be if the driver could report the
> > > real mac address even before the interface is up. 
> > [..]
> > 
> > alas this requires the firmware to have been uploaded and be operational;
> > something that'd be easiest/best to do at ifup time... 
> 
> 	I know, that's why I told you about it.

while at it, I'll try to paraphrase what I got from you, and formulate
it as a TODO-kinda-list (with some embedded questions to you to
answer) for the short term future :-)

*) we need to duplicate most objects in the MIB in our private driver
   struct (partlally done by me some weeks ago) and try best-effort to
   make it syncronized with the firmware's MIB (to be improved)

*) when the device is down,
   . the IW handlers should succeed in setting values (do they 'return
     0' or 'return EINPROGRESS' in that case)? (btw, which patch for 
     orinoco were you referring to?), and copy them to our private MIB-mirror

   . what shall we do, when on ifup some of the setted values in our 
     private MIB-mirror should show up as being rejected by the firmware 
     as being invalid? 

   . the values we return on queries are those in our private MIB-mirror...? 
     (what else could make sense?)

*) when the device get's up, we restore settings in our MIB (partially
   done as well); what do if some settings are invalid? let ->open fail?
   update our MIB-mirror with the values the firmware now actually has set?
   should ->open delay until all settings are restored, or should it
   return immediately while the restoration continues in background?

   shall we care about calling netif_carrier_on/off? would this help
   applications in userspace? would dhcpd wait until carrier is on?

   after initialization has been completed, we can start passing
   user-requests/queries to firwmare, instead of operating only on our
   MIB copy; but while in initialization phase, how shall we block/delay
   user-requests? delay the ioctl() caller, or simply let it fail? or
   even succeed without effect?

*) when device is up,
   . on queries, we return just the copy in the MIB, assuming we have
     the the mirror syncronized; or maybe we really query the firmware, and
     while at it, we update the MIB mirror (if the value should have
     changed without our knowledge... which actually would be bad for some
     values which aren't supposed to change without our intervention...)

   . when setting values, now we can finally test immediately whether
     the arguments are valid; and return this directly to the userspace caller


...ok, enough questions for now, I surely forgot to write down some of
the ones I had on my mind while reading your long reply... ;-)

...btw, is there some wlan/linux-driver-writing-guidelines document?

> > it's quite annoying to have such a large firmware, which needs to be
> > loaded from time to time, and which for now has to reside on the
> > filesystem...
> 	Probably better than having to reside in kernel memory (non
> swapable).

indeed... alas this makes in-kernel ip-autoconfiguration out of reach...
 
> 	By the way, do you have any plan to merge into 2.6.X, or do
> you plan to remain standalone ?

well, I guess I can speak for the rest of the team, that we
 want to get the driver merged into the stock kernel sooner or later;
but honestly the driver is far from being ready for that...

on the other hand, being so dependant on a proprietary firmware, which
_seems_ to be the source of some bugs, we might never get a rock-solid
driver worth being included in 2.6.x :-(

btw, there's one major bug right now which we have a real hard time
pinning down: it seems to be powermanagement related, especially when
acpi is inolved, the card tends to hang hard which requires it to be
completely powered down to be reset at all... there's been a
suggestion, it might have to do with bus-mastering and entering C3
state... any ideas/hints where else to look at?

regards,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org       /    Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142