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@xxxxxxxxxxx.
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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
