Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in
 gnubee-pc1
To:     NeilBrown <neil@brown.name>
Cc:     Dan Carpenter <dan.carpenter@oracle.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org, lkml <linux-kernel@vger.kernel.org>
References: <152105892255.22262.1902152685410223215.stgit@noble>
 <20180315104853.bthffdd4hzklzo6d@mwanda>
 <be0d1e2d-67c5-bac1-63d4-72568dbf9d23@phrozen.org>
 <87muz9ayjz.fsf@notabene.neil.brown.name>
From:   John Crispin <john@phrozen.org>
Message-ID: <9e8e07b4-1a4d-3434-402f-920c19c65122@phrozen.org>
Date:   Thu, 15 Mar 2018 21:21:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <87muz9ayjz.fsf@notabene.neil.brown.name>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 15/03/18 21:12, NeilBrown wrote:
> On Thu, Mar 15 2018, John Crispin wrote:
>
>> On 15/03/18 11:48, Dan Carpenter wrote:
>>> This all seems fine.  Generally the requirements for staging are that it
>>> has a TODO, someone to work on it, and it doesn't break the build.  But
>>> some of the patches don't have commit message and those are required and
>>> some of the commit messages are just the changes you have made not don't
>>> describe the actual code...
>>>
>>> John Crispin's email is john@phrozen.org.
>>>
>>> regards,
>>> dan carpenter
>>>
>> Hi All,
>>
>> looks like i was CC'ed on the openwrt addr, which no longer exists. This
>> series makes no sense. None of the stuff posted is anywhere near ready
>> to be upstreamed.
>>
>> * we dont need a dedicated pinctrl driver, pinctrl-single will work fine
>> on these SoCs
>> * the DMA/sdhci driver is a hacked up version of the SDK driver.
>> * drivers/net/ethernet/mediatek/* works on mt7623 and is easily portable
>> to mt7621, same goes for the gsw driver.
> Hi John,
>   I think it makes sense in that, with the patches, the hardware works, and
>   without the patches (at least the first) you cannot even build with
>   CONFIG_SOC_MT7621=y as pcibios_map_irq() is undefined.  Having
>   working code is a great starting point for further development.
>   It certainly isn't ready for upstream, which is why it is heading for
>   drivers/staging.  This is explicitly for code that isn't yet ready.
>   By putting the code there it should be safe from bit-rot, and can be
>   worked on by multiple people.  It gets increased visibility so people
>   can say how bad it is (as you have done - thanks).  This feed back is a
>   valuable part of improving the code and getting it out of staging.
>
>   I'll add notes to various TODO files based on your comments.  If you
>   have anything else to add, it would be most welcome.  Thank you for
>   making these patches available in the first place, so that my hardware
>   can work!
>
> Thanks,
> NeilBrown

Hi Neil,

I understand your reasoning, however ...
only the pcie driver is worth merging. all other drivers are already 
inside the kernel for mt7623 and can be easily adapted to work on 
mt7621. having duplicate drivers is a certain no-go.
cleaning up the pci driver is a matter of a few days work. merging a 
shitty pci driver just to postpone doing the 3-5 days work involved to 
polish it seems a rally bad trade-off.
i strongly oppose having any of this code merged into the kernel, even 
if it is only the staging area.

     John