[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: com(4) and LSI bug workaround
> > Then can you revert your changes?
> Is it better to revirt right now?
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 ...
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.
Main Index |
Thread Index |