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, 21 Oct 2011 02:21:44 +0000
From:	"Ren, Cloud" <cjren@....qualcomm.com>
To:	"Luis R. Rodriguez" <mcgrof@...jolero.org>
CC:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161
 Ethernet driver

>On Thu, Oct 20, 2011 at 2:48 AM, Ren, Cloud <cjren@....qualcomm.com>
>wrote:
>>
>>>From: "Ren, Cloud" <cjren@....qualcomm.com>
>>>Date: Thu, 20 Oct 2011 09:23:07 +0000
>>>
>>>> As you saw, should I do the two following steps?
>>>> 1. I firstly try to submit code to linux-staging.git.
>>>> 2. After the driver have been accepted by  linux-staging.git, I
>>>> submit to net-
>>>next.git again.
>>>
>>>You submit and get it into staging so that it can sit there for some
>>>time and get reviewed and improved by others.
>>>
>>>One doesn't submit directly to net-next right after it gets into
>>>staging, staging is a place where your driver lives while it still
>>>smelly funky and needs more work.
>>
>> The driver will support the next generation NICs of Atheros.
>> Meanwhile, the driver can also have better optimization for AR8131 and
>> AR8151 than atl1c. For some reason, we don't plan to patch atl1c
>> driver to support our new NIC, such as AR8161. So I hope the driver
>> can stay in net-next in the end. Of course, I will be responsible for modify
>source code and let it match kernel requirements.
>
>Cloud,
>
>If you want to skip staging (which I recommend) then you need to address all
>upstream concerns expressed. Given that you indicate that you will be
>working on following up with the driver until its acceptable upstream my
>recommendation is either to clean up the driver very well and review it
>internally at Atheros prior to a public submission *or* just dump into staging
>and get the benefit of community cleanup and eventually wait until it is ready
>for proper upstream. If you want internal private review at Atheros you can
>use the internal private ath9k-devel list.
>
>Also are you going to maintain the older atlx drivers? While at it can you clear
>up who maintains what as far as Atheros is concerned for Ethernet?
>
>  Luis

Dear Luis

Thanks for your suggestions. I would rather do an internal review than only submit to staging.
Alx driver is one of the most important drivers for Atheros Ethernet. It's easier to maintain. 
Because it shares many codes with other drivers on different OSs, it can be convenient to patch
some issues which are found on different OSs.

I'm going to maintain alx linux driver. alx linux driver can support all NICs which atl1c linux driver supports.
So we don't plan to maintain atl1c driver. atl1e and atlx driver are also maintained by me. But maybe I can
not response requests for those drivers on time, because sometimes I am busy at alx driver.

cloud


Powered by blists - more mailing lists