Hi Linus,
I'm submitting driver for IPWireless PC Card modem for inclusion to 2.6.25.
The driver has been in -mm series as ipwireless_cs.git tree for

some time and has passed through lkml (http://lkml.org/lkml/2007/12/12/165).

The PCMCIA subsystem is unmaintained, so I'm sending it directly as Andrew

suggested.
David Sterba

---

From: David Sterba <dsterba@suse.cz>
ipwireless: driver for PC Card, 3G internet connection
The driver is manufactured by IPWireless.
Rewieved-by: Jiri Slaby <jslaby@suse.cz>

Signed-off-by: Ben Martel <benm@symmetric.co.nz>

Signed-off-by: Stephen Blackheath <stephen@symmetric.co.nz>

Signed-off-by: David Sterba <dsterba@suse.cz>

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

---

 MAINTAINERS                                     |    8

 drivers/char/pcmcia/Kconfig                     |    9

 drivers/char/pcmcia/Makefile                    |    2

 drivers/char/pcmcia/ipwireless/Makefile         |   10

 drivers/char/pcmcia/ipwireless/hardware.c       | 1784 ++++++++++++++++++++++++

 drivers/char/pcmcia/ipwireless/hardware.h       |   63

 drivers/char/pcmcia/ipwireless/main.c           |  496 ++++++

 drivers/char/pcmcia/ipwireless/main.h           |   70

 drivers/char/pcmcia/ipwireless/network.c        |  513 ++++++

 drivers/char/pcmcia/ipwireless/network.h        |   54

 drivers/char/pcmcia/ipwireless/setup_protocol.h |  108 +

 drivers/char/pcmcia/ipwireless/tty.c            |  687 +++++++++

 drivers/char/pcmcia/ipwireless/tty.h            |   48

 13 files changed, 3852 insertions(+)

---

diff --git a/MAINTAINERS b/MAINTAINERS

index df40a4e..a38e94a 100644

--- a/MAINTAINERS

+++ b/MAINTAINERS

@@ -2007,6 +2007,14 @@ M:	acme@ghostprotocols.net

 L:	netdev@vger.kernel.org

 S:	Maintained
+IPWIRELESS DRIVER

+P:	Jiri Kosina

+M:	jkosina@suse.cz

+P:	David Sterba

+M:	dsterba@suse.cz

+S:	Maintained

+T:	git://git.kernel.org/pub/scm/linux/kernel/git/jikos/ipwireless_cs.git

+

 IRDA SUBSYSTEM

 P:	Samuel Orti...
[ message continues ]

Could we get better names? PCIOB is cryptic, pci_io_base is pretty
Not sure how this is supposed to work. If you assume unshared

interrupts, it should be possible to return something and make core

care.
If you are assuming shared interrupts, either you should disable on

first 0xFFFF (are you sure cast is needed, btw?), or not at all,

because it could be the other device sedning you 100 of those...
...so which one is it?
Hiding structs BehindTypedefsIsEvil.
									Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Some items are set during initial phase and read only afterwards. This don't

need to be protected. Nevetheless, I've found some missing locking around 
Unfortunatelly PCMCIA subsystem is full of these and all drivers use them.

I'll stay consistent for now.
Updated patch v4 will follow.
dave

--

can you remove bad_interrupt_count? It seems very random in presence
Thanks!

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Pavel & all,
We should keep these names because they are part of the interface

This code is obsolete (a workaround to an embedded system bug) and

should be removed - sorry I didn't step on it earlier.  It can removed

with minimal risk of destabilizing the driver.  It should look like this:
static irqreturn_t ipwireless_handle_v1_interrupt(int irq,

ipw_hardware_t *hw)

{

        u_short irqn;

        u_short ack;
        irqn = inw(hw->base_port + IOIR);
        if (irqn == (u_short) 0xFFFF)

                return IRQ_NONE;

        else if (irqn != 0) {

                ack = 0;

                /* Transmit complete. */

                if (irqn & IR_TXINTR) {

                        hw->tx_ready++;

                        ack |= IR_TXINTR;

                }
                /* Received data */

                if (irqn & IR_RXINTR) {

                        ack |= IR_RXINTR;

                        hw->rx_ready++;

                }

                if (ack != 0) {

                        outw(ack, hw->base_port + IOIR);
                        /* Perform the I/O retrieval in a tasklet,

because the ppp_generic

                           may be called from a tasklet, but not from a

hardware interrupt. */

                        if (!hw->tasklet_pending) {

                                hw->tasklet_pending = 1;

                                tasklet_schedule(&hw->tasklet);

                        }

                }

                return IRQ_HANDLED;

        } else

                return IRQ_NONE;
}
The v2_v3 handler should not have it either, and should start like this:
static irqreturn_t ipwireless_handle_v2_v3_interrupt(int irq,

ipw_hardware_t *hw)

{

    int tx = 0;

    int rx = 0;

    int rx_repeat = 0;

    int b_try_MemTX_OLD;

    do {

        u_short memtx = ioread16(hw->MemTX);

        u_short memtx_serial;

        u_short memrxdone = ioread16(&hw->memInfReg->MemRXDone);
        b_try_MemTX_...
[ message continues ]

No. Use sensible names, and put manufacturer-defined 5-letter crap in

the comments. Heck, notice that they just took first letter of each
You have a structure, and are accessing its fields from interrupts. I

assume you access the fields outside interrupt, too? As the fields are

not of atomic_t, I believe you need locking.
(Oh, and I should have said that earlier: Thanks for the driver and

congratulations for getting it this far).

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

On Mon, 28 Jan 2008 18:19:29 +0100 David Sterba wrote:
From C99 spec:

"The order of allocation of bit-fields within a unit (high-order to

low-order or low-order to high-order) is implementation-defined."
so if the order/location of these bitfields is important (from one

system to another), you should use bit masks instead of bitfields
Need ":" and/or space between CARD_NAME and following string.
Will these parameters be documented anywhere?
---

~Randy

--

I've changed it to __BIG_ENDIAN_BITFIELDS, as suggested by Alexey. The order 
The options are intended for debugging. Normal user does not need to tweak 
Fixed.
Updated patch will follow.
Thank you for comments.
Dave
--

Anyway the descs are wrong. Those 3 are for the only one variable.
--

Well, I've removed them, this was not consistent neither within the driver nor 
Yes this was my copy&paste error, thanks.
Dave

--

Ack, thanks.
---

~Randy

--

So then, what's the problem?

--

Why is it there?  We have a kernel documentation language.

Please use it or plain text.
---

~Randy

--

Hi,
Yes please.
                        Pekka

--

You want __BIG_ENDIAN_BITFIELD here.

--

Actually, you probably want to avoid bitfields here, and just do bit

arithmetics by hand.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--