Re: com(4) and LSI bug workaround
Hi! From: Izumi Tsutsui tsut...@ceres.dti.ne.jp Date: Wed, 2 Oct 2013 22:29:52 +0900 First of all, your guess has no evidence and actually it seems incorrect. There are some articles that indicate it's a documented future: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/203948 Yes. Although that those are not the things for 16750 understood me, I did not know that it was IP of Synopsys DesignWare. And although his mail does not have a corroboration which is a fact, either, probably it is right. Then can you revert your changes? Is it better to revirt right now? Isn't it much simpler and explicit to call such a MD workaround function directly from comintr() and wrap those blocks with #if COM_XXXMDname 0 / #endif with needs-flag declaration in the config(9) file? I think that I should check not by needs-flag but by COM_TYPE_. Since ARMADAXP has some PCIe, com should be able to be attached there. What makes you think the com at PCIe will also have the same quirk? If the quirks is not chip specific, the workaround function should also be in the MI com.c, then no need to wrap them with #ifdef. COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? In ARMADAXP case I don't see any reason to put #ifdef at all. If IIR_BUSY is returned we should always check the USR register. It's no worth to have a separate mvuart_armadaxp_workaround() function you suggested. Please let me confirm. Is it wrong although I understood that you desired #ifdef ARMADAXP ... #endif? I desire a method of setting COM_TYPE_ to sc_type like OMAP and PXA2x0. it is like COM_TYPE_APBUART. # It may be better for the name of sinopsys to enter. COM_TYPE_SNPS? And actual processing will move to com.c. This is because it is not dependent on ARMADAXP. This understands that you also agree. Thanks, -- kiyohara
Re: com(4) and LSI bug workaround
Then can you revert your changes? Is it better to revirt right now? Why not? Your current code doesn't work as expected. You changed the original code without confirmation. Your guess was wrong and the original code looks correct. I see no reason to keep current code. Isn't it much simpler and explicit to call such a MD workaround function directly from comintr() and wrap those blocks with #if COM_XXXMDname 0 / #endif with needs-flag declaration in the config(9) file? I think that I should check not by needs-flag but by COM_TYPE_. Since ARMADAXP has some PCIe, com should be able to be attached there. What makes you think the com at PCIe will also have the same quirk? If the quirks is not chip specific, the workaround function should also be in the MI com.c, then no need to wrap them with #ifdef. COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? In ARMADAXP case I don't see any reason to put #ifdef at all. If IIR_BUSY is returned we should always check the USR register. It's no worth to have a separate mvuart_armadaxp_workaround() function you suggested. Please let me confirm. Is it wrong although I understood that you desired #ifdef ARMADAXP ... #endif? : I just said #ifdef with a flag was still better than dumb function pointers in MI softc. For now I don't see any reason to add any MD functions called from MI com.c. Revert your changes first, then propose your next changes (COM_TYPE names etc.) against the original one, not against sources you broke. --- Izumi Tsutsui
Re: com(4) and LSI bug workaround
Hi! From: Izumi Tsutsui tsut...@ceres.dti.ne.jp Date: Thu, 3 Oct 2013 21:11:04 +0900 Then can you revert your changes? Is it better to revirt right now? Why not? Done. Your current code doesn't work as expected. You changed the original code without confirmation. Your guess was wrong and the original code looks correct. hmm... This problem influences only ARMADAXP. And nobody noticed until I reported. Furthermore, the problem of LCR(com.c r1.312) before that and nobody reported. Probably ARMADAXP is not used in many cases. Thanks, -- kiyohara
Re: com(4) and LSI bug workaround
Then can you revert your changes? Is it better to revirt right now? Why not? Done. Thanks. Your current code doesn't work as expected. You changed the original code without confirmation. Your guess was wrong and the original code looks correct. hmm... This problem influences only ARMADAXP. And nobody noticed until I reported. Furthermore, the problem of LCR(com.c r1.312) before that and nobody reported. Probably ARMADAXP is not used in many cases. Probably you should read the commit guideline again and/or consult your sponsors. Even if we have few users, leaving a wrong comment like this http://nxr.netbsd.org/xref/src/sys/dev/marvell/com_mv.c?r=1.6#187 is a quite bad thing. I agree that the hardware design is quite awful, but it's documented, not a bug. --- Izumi Tsutsui
