Re: com(4) and LSI bug workaround

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

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