Re: com(4) and LSI bug workaround

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> > 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?

> > 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_XXXX.
> 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.

---
Izumi Tsutsui