netdev - Re: [PATCH] net: add QCA alx Ethernet driver

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: <CAB=NE6W-CYjEhbfYOv7XqXFGvdhZxRECqfAmgouaa5_j45gnOQ@mail.gmail.com>
Date:	Wed, 21 Mar 2012 18:28:07 -0700
From:	"Luis R. Rodriguez" <rodrigue@....qualcomm.com>
To:	David Miller <davem@...emloft.net>
Cc:	xiong@....qualcomm.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, qca-linux-team@...lcomm.com,
	nic-devel@...lcomm.com, kgiori@....qualcomm.com,
	chris.snook@...il.com, mathieu@....qualcomm.com,
	bryanh@...cinc.com, Jesper Andersen <jespera@...u.dk>,
	Julia Lawall <julia@...u.dk>
Subject: Re: [PATCH] net: add QCA alx Ethernet driver

On Tue, Feb 28, 2012 at 7:32 PM, David Miller <davem@...emloft.net> wrote:
> From: "Huang, Xiong" <xiong@....qualcomm.com>
> Date: Wed, 29 Feb 2012 03:11:14 +0000
>
>> We understand your concern.  To support the new chipset, do you
>> think it's reasonable to upstream it as a new driver, not a
>> replacement ?
>
> It depends upon how similar the chips are.

OK.

> To be honest tg3, as one example, supports quite a large array of
> different pieces of hardware that use the same logical core.

At certain point it becomes a pain in the ass to support older
chipsets, and simply easier to leave the older driver to rot.

> So that would be my litmus test about how different a chip needs
> to be to deserve an entirely new driver.

Understood.

> I strongly suggest you try to get atl1c working properly.

This is what I have recommended since the alx driver was rejected, and
our team has been working on the atl1c driver now but we need to get
the legal approval to get contributions out to atl1c (I know this is
silly, but hey just letting you know).

Anyway, in the meantime another topic has creeped up, and that is to
share with BSD and also help kill proprietary drivers [0]. Me and
Adrian intend on sharing our thoughts on how we intend on doing this
at LF collab but was in hopes we can use alx as a test case. We've
gone back to the drawing board for another simple driver to test our
work against but... we come back to alx.

Would it be worthwhile to consider alx upstream only for the newer
chipsets (regardless of the litmus test, which I do agree with on
technical grounds) in consideration for helping pave the way on
killing proprietary drivers?

[0] https://events.linuxfoundation.org/events/collaboration-summit/rodriguez-chadd

 Luis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html