Re: New FarSync T-Series driver

[Robert J.Dunlop]

Thanks for the freedback guys.

Revised versions of the driver patches against 2.4.6-ac2 and 2.4.7-pre3
are available at:
http://www.xyzzy.clara.co.uk/farsync/farsync-patch-2.4.6ac2.gz and
http://www.xyzzy.clara.co.uk/farsync/farsync-patch-2.4.7pre3.gz

On Wed, Jul 04, 2001 at 04:18:45PM +0200, François romieu wrote:
> Just my HO:
Hey it's all good feedback.

> * error_1, error_2... error_n labels are ugly;
I don't like goto's either but in this function the structure kinda demands
it. Lot's of points where you fail and need to release an increasing list of
resources. Not sure a list of labels like this is any better.
    err_out_free_iqrx:
    err_out_free_iqtx:
    err_out_free_irq:
    err_out_iounmap:
    err_out_free_mmio_region:
    err_out_free_mmio_region0:
    err_out:

I've left this one as it is for the present. I have removed the gotos from
fst_open() however.

> * ioremap may fail;
Fixed that one, although it did add a "goto error_6" :-(

> * mix of spin_lock and FST_LOCK isn't nice (kill the latter ?);
Quite correct. Un-helpful information hiding. I've unwound the macros in
place and removed them.

> +                offset = BUF_OFFSET ( rxBuffer[pi][i]);
> [...]
> +                                card->mem + BUF_OFFSET ( rxBuffer[pi][rxp][0]),
> A bit of a macro abuse imho.
Not quite sure what you mean here. I have corrected the code so that BUF_OFFSET
sees a consistent argument.

> +        if ( ++port->txpos >= NUM_TX_BUFFER )
> +                port->txpos = 0;
> 
> Why not:
> port->txpos++;
> foo = port->txpos%NUM_TX_BUFFER;
I think mine is clearer but then I've always bumped and wrapped pointers and
indexs that way. Another alternative would be:
    port->txpos = ( port->txpos + 1 ) % NUM_TX_BUFFER;

Looks cleaner than both and lets the compiler decide, but if the % operator
produces a div operation instead of a mask on even one processor type then I
think we lose. If anyone can prove there's an optimal way to do this sort of
bump and wrap operation I'll gladly adopt it.

And finally one from Alan Cox:
> Don't assume short is 16bits. It is so far but that might change
> Use u8/u16/u32 (or for user exposed structs __u16/__u32 etc)
Oh God! how did I miss that one!
And after I'd taken the NT driver writers to task over the same issue :(
Still corrected now.

-- 
        Bob Dunlop                      FarSite Communications
        [e-mail]           [e-mail]
        www.xyzzy.clara.co.uk           www.farsite.co.uk