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]

Date:	Fri, 30 Mar 2012 10:10:55 -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 Wed, Mar 21, 2012 at 6:28 PM, Luis R. Rodriguez
<rodrigue@....qualcomm.com> wrote:
> 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

David, please us know if you think the above reason is worthy for
consideration of alx upstream, if at least for the newer chipsets. Our
engineers are ready to work on either approach, and we have a approval
take either route now. The sharing benefits however would make this a
great case to work on for the above mentioned project.

  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