Re: com(4) and LSI bug workaround

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

Hi!


From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Date: Mon, 30 Sep 2013 23:02:17 +0900

>> > It looks meaningless that the (*sc_vendor_workaround)() hook function
>> > is inside of MD if (sc->sc_type == COM_TYPE_ARMADAXP) statement.
>> > 
>> > Isn't it simpler to prepare a MD hook function that returns
>> > (possible pre-processed) IIR register value that can be used
>> > to check if the interrupt for the device is pending or not?
>> 
>> I performed operation to a com register into com.c.
>> I think that it is not so brief to return the value of both IIR(u_char)
>> and an error moreover.
> 
> Sorry I don't understand what you mean.
> 
> Do you think the name of "sc_vendor_workaround" is really appropriate
> for the function that is called only in COM_TYPE_ARMADAXP case?

I apologize for the first explanation having been lacking.

I consider calling this method for evasion processing of the problem
of LSI.  Only ARMADAXP uses it only in comintr() now.
However, this may be used during the processing from which LSI besides
the future differs.
In such a case, is a different method from this prepared?
  For example

      void *sc_vendor_workaround{1,2,3...}(void);

We are evaluating the conditions of COM_TYPE_ARMADAXP and can cope with
it by one method.


When it depends especially, LSI with much fault may come out to a market.
In this case, it may be able to be coped with by making a fault number
(tag ?) and a reason into an argument, and calling a method.

      void *sc_vendor_workaround(int reason, int value);


> The requirement in the MI interrupt handler is just
> "whether interrupts are pending or not," isn't it?

Yes, it is.

Thanks,
--
kiyohara