linux-kernel - Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in gnubee-pc1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Mar 2018 21:21:38 +0100
From:   John Crispin <john@...ozen.org>
To:     NeilBrown <neil@...wn.name>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/13] staging: add drivers to support Mediatek mt7621 in
 gnubee-pc1



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@...ozen.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