RE: Is the PCI serial driver code GPL v2 or v3

[Lee Howard]

(Sorry for the top-post, but Outlook is a pain...)

The "hack" originates from code done by Oxford Semiconductor.  I would be
happy to have it done with the quirk system, and I am willing to write a
patch to that effect.  My guess, however, would be that I'll still not do it
in your favorite way, and so I'm asking if you would like me to write the
code change or will you (or someone else here familiar with the favorite
ways) do it?

For what it's worth, I have tested 2.6.28-rc3 and it works vanilla with this
hardware.  :-)

Thanks,

Lee.


Lee Howard
Mainpine, Inc. Software Development Lead
Tel: +1 866 363 6680 ext 805 | Fax: +1 360 462 8160
lee.howard@xxxxxxxxxxxx | www.mainpine.com

-----Original Message-----
From: Russell King [mailto:rmk@xxxxxxxxxxxxxxxx] On Behalf Of Russell King
Sent: Thursday, November 06, 2008 11:13 AM
To: Peter Alfredsen; Alan Cox; Lee Howard
Cc: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: Is the PCI serial driver code GPL v2 or v3

BTW, now that you bring this to my attention, I see this hack in there:

struct serial_private *
pciserial_init_ports(struct pci_dev *dev, struct pciserial_board *board) {
        if (dev->vendor == PCI_VENDOR_ID_OXSEMI ||
            dev->vendor == PCI_VENDOR_ID_MAINPINE)
                pci_oxsemi_tornado_init(dev, board);

        nr_ports = board->num_ports;

It's completely unnecessary with the quirk system, which follows these
lines:

        /*
         * Run the new-style initialization function.
         * The initialization function returns:
         *  <0  - error
         *   0  - use board->num_ports
         *  >0  - number of ports
         */
        if (quirk->init) {
                rc = quirk->init(dev);
                if (rc < 0) {
                        priv = ERR_PTR(rc);
                        goto err_out;
                }
                if (rc)
                        nr_ports = rc;
        }

So, why they couldn't add a quirk where the init function returns the number
of ports, instead of modifying some random board structure and possibly
upsetting future allocations is beyond me.

We now have the situation, again, where some random entry in the pci_boards
array is being modified which could trip up a future board registration.

This is plainly idiotic and utterly buggy.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/