linux-kernel - Re: Is the PCI serial driver code GPL v2 or v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081106191250.GA28514@flint.arm.linux.org.uk>
Date:	Thu, 6 Nov 2008 19:12:50 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Peter Alfredsen <loki_val@...too.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Lee Howard <lee.howard@...npine.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Is the PCI serial driver code GPL v2 or v3

On Thu, Nov 06, 2008 at 08:52:31PM +0200, Peter Alfredsen wrote:
> It seems like a typo to me to.. That wording has been constant since the 
> file drivers/serial/serial_8250_pci.c was created based on work in 
> drivers/char/serial.c:
> http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=33c0d1b0c3ebb61243d9b19ce70d9063acff2aac
> serial_8250.c has the "or later" clause there.
> 
> But I suppose the best way is to ask the originator of that file. 
> Russell, what say you?
> Did you mean to license that file under GPL-2 or GPL-2+?

It was based upon the original serial.c by Ted T'so, but with some
reworking to add a separate quirks table, and quite a number of cleanups.

My personal position is that code I author is GPLv2, and not GPLv2 or
later.  So it's a question whether you consider that I'm the author
of the code in that file, or whether you think it's Ted's with my
contributions were under Ted's original terms.

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/