On Thu, Mar 15 2018, John Crispin wrote: > 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. Hi John, I don't understand why you would want to deny people easy access to code which makes their hardware work. I'm sure that isn't your intention, but it could well be the effect. If you think you can make it work in 3-5 days, then please go right ahead. I will happily test anything you submit. I suspect the most likely outcome, however, is that I'll end up doing all the work, and I'm sure it will take a lot more than 3-5 days and will involve a lot of learning. I'll be happy if I can get all of this back out of staging in 6 months. That is an extra 6 months (at least) that people will be able to use a mainline kernel on their gnubee. With respect to your suggestion that "having duplicate drivers is a certain no-go", I don't think that is correct. As an approximate counter-point, I'm in the process of cleaning up the drivers/staging/lustre filesystem with the hope of eventually moving it out of staging. It had duplicate wait_event() code, duplicate PRNG, duplicate workqueues, duplicate resizeable hashtable, duplicate tracing infrastructure, and more that I haven't had a chance to look closely at yet. This duplication certainly kept it out of linux/fs/, but has no bearing on whether it belong in linux/drivers/staging/. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
