Re: [irda-users] Re: Problems with incoming connections

[Martin D. <li...@md...>]

On Mon, 30 Sep 2002, Daniele Peri wrote:

> > 	One of the "particularity" of the SMC driver is that it wrap
> > around irport for all SIR operation. So, most often, you end up using
> > code in irport.c, not in smc-ircc.c.
> I know. That's why I got rid of irport and wrote a brand new driver for 
> smsc-ircc. Now I have just a module to cope with. By now it just work 
> exactly as the old couple irport & smc-ircc but I can easier control how 
> it is working. I plan to add some more functionalities to my module so 
> if there isn't anyone else interested in it I could take care of the 
> smsc-ircc driver maintenance.

Well, I'm not using smc-ircc, but this sounds like very good news for
quite a number of people! Note that I am (was) somewhat concerned with my
partial irport rewrite/unification with irtty because smc-ircc used to
rely on irport. Sure, given smc-ircc being the only one we could just
bundle existing irport with smc-ircc to keep it working (well, "as is",
you know ;-) but this wouldn't bring any progress to smc-ircc. So if you
plan to submit a rewritten smc-ircc independent from current irport this
would be helpful for both sides, I believe.

> > 	The difference between incomming and outgoing connections, as
> > far as speed change are concerned, is that outgoing speed changes are
> > done with a extra zero byte frame, while incomming speed change are
> > done by piggybacking the new speed on the "ua:rsp".
> 
> I realized it. But my question is why all this works fine with nsc-ircc 
> (Am I right?)... Interrupt management is different there though.

The point is to defer the actual speed change until all outgoing data has
been transmitted. Note it is _not_ sufficient to wait until the last byte
has been given to the hardware (i.e. last write/dma completed). One has to
wait until the hardware has really transmitted the data, f.e. the fifo
gets drained and THRE set - if not, the last frame with some bytes still 
in the fifo gets corrupted. This is easy to trigger with the "ua:rsp" at
LAP disconnect, because the stack sends a len==0 skb only a few microsec
later to request the speed change. Also note that the same thing can
happen with piggyback speed change on len>0 skb if the queue isn't stopped
after every single tx-frame (because the tx-complete for the previous
frame might already see the self->new_speed meant to be applied after the
current frame).

AFAICS recent nsc-ircc has all the stuff to deal with this situation. Some
(most?) other drivers are probably questionable, IMHO. Of course the
driver also needs to stop the queue to prevent the stack from sending more
frames while the speed change is pending and some spin_lock_irqsave() for
correct serialization with the interrupt handler.

> > 	Note also that Martin has a rewrite of irtty in the pipeline
> > that could/should clean a lot of this code by making the dongle
> > management code common.
> Irtty already works fine with my chipset but I don't like it very much 
> and not just because it doesn't support FIR.

Impossible by definition: this would require both the underlaying tty
layer and the serial driver to know about FIR encoding/stuffing and 
baudrates. And I doubt it would be a good idea to cause all the FIR
traffic to travel thru the tty layer...

In contrast to SIR where most hardware behaves like a standard uart (with
irda-usb and the vlsi_ir being exceptions) there is no standard FIR
hardware interface. Therefore, in order to have a irport/irtty-like driver
with FIR support, one would have to use irport as baseline and put all the
controller-specific stuff around. No tty-layer, no need for irattach.
That's more or less exactly what existing smc-ircc was trying to do when
using stuff from irport.

But as said, AFAIK smc-ircc is the only one trying to do so. Therefore I
tend to say it might be better to make the whole smc-ircc independent from
irport - just like your approach above.

Martin