Message-ID: <CAB=NE6W4v-SqxQ5uDvREACKH7cWHzpvZu4tNT1zy8iFKsiK96g@mail.gmail.com>
Date:	Thu, 20 Oct 2011 19:36:37 -0700
From:	"Luis R. Rodriguez" <mcgrof@...jolero.org>
To:	"Ren, Cloud" <cjren@....qualcomm.com>,
	Xiong Huang <xiong@....qualcomm.com>
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 7:21 PM, Ren, Cloud <cjren@....qualcomm.com> wrote:
>>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.

Are there issues with the atl1x driver that are fixed in the alx
driver? How many ? Do we expect to find many more ? If there isn't
much churn then why not let atl1x rot to death while atx can move
without atl1x support at all upstream?

A driver replacement for atl1x seems fair only if you can ensure there
will be no regressions Vs the atx driver code. I'd much prefer an atx
driver that *is* actively maintained by Atheros than only Gigabit
support for atx, and an orphaned atl1x driver but if we don't expect
much changes to go for atl1x what is the point?

  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

Powered by blists - more mailing lists