Created
March 17, 2021 00:04
-
-
Save neheb/bfab060cf1b0b06779e290eef1866d66 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 01:08 < Rene__> I am also happy that NAND issue is resolved and that Weijie sended patches upstream. | |
| 01:16 < gch981213> Rene__: You could send patches/create pull requests for that SFP support. | |
| 01:18 < gch981213> Rene__: Unfortunately Weijie made the difference between mt7621 and other mtk nand controllers too clear, giving upstream a perfect reason to reject it. :P | |
| 01:24 < mangix> gch981213: how difficult is upstream's suggestion? | |
| 01:25 < gch981213> mangix: Impossible for us and almost impossible for Weijie. | |
| 01:26 < gch981213> Existing mtk_nand driver uses legacy nand APIs and I doubt if upstream will accept this kind of major rework without also replacing legacy APIs. | |
| 01:27 < gch981213> Rewriting that driver requires testing on mt2701 and mt7622. | |
| 01:29 < gch981213> mt2701 is MTK's android chip. I believe we can't obtain a board allowing custom firmware on it. | |
| 01:33 < PaulFertser> Why does rewriting the driver _require_ testing on an unobtainable chip? | |
| 01:34 < Rene__> gch981213: Yes I can. | |
| 01:35 -!- Acinonyx_ is now known as Acinonyx | |
| 01:37 < PaulFertser> Why can't your rewrite the driver dropping support for that nasty mt2701 and then it's up to MTK to bring it back if they care. | |
| 01:38 < PaulFertser> If the vendor actively prevents community maintenance of their driver then it's a fair game for the community to break the support while reworking it. | |
| 01:40 < gch981213> PaulFertser: Oh. I'd say that's fair enough :) | |
| 01:42 < mangix> hahaha I love that suggestion | |
| 01:42 < blogic> PaulFertser: lol | |
| 01:42 < blogic> PaulFertser: you liturally have no clue what you are talking about in regards to mtk | |
| 01:43 < blogic> utter pile of boolocks, sorry to be so direct | |
| 01:43 < blogic> gch981213: was it no in car entertainment ? | |
| 01:43 < blogic> .... which is probably android based | |
| 01:44 < gch981213> blogic: I only know that's not a router chip so I guessed it's for some android devices. | |
| 01:44 < PaulFertser> blogic: so why should be they be taken into account when reworking the drivers? If they do not allow testing on some SoC, so be it, drop the support, why not? | |
| 01:44 < blogic> i think it was set top box or in car | |
| 01:44 < blogic> PaulFertser: do you know the /ignore feature ? | |
| 01:45 < PaulFertser> blogic: my IRC client has one, yes, why? | |
| 01:46 < gch981213> When I rewrote MTK's crappy spi nor driver using spi-mem, they expressed their concern about their product maintenance via private email. | |
| 01:47 < blogic> who did that ? | |
| 01:47 < blogic> i consider mtk to be the community friendliest company | |
| 01:47 < blogic> they even release datasheets | |
| 01:47 < gch981213> I'd also like to avoid this additional test pressure for them but upstream insist that I remove the old one. | |
| 01:48 < gch981213> blogic: They said it's okay if it's a decision from upstream maintainers :D | |
| 01:49 < gch981213> and they do give me the controller datasheet | |
| 01:50 < blogic> gch981213: so they just paricipated in the public process raising a concern and agreeing that it is not their call | |
| 01:50 < blogic> and provided the required docs | |
| 01:50 < blogic> sounds pretty legit to me |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment