> Date: Fri, 11 Mar 2016 18:26:15 +0100
> From: Stefan Sperling <[email protected]>
>
> On Fri, Mar 11, 2016 at 02:58:12PM +0100, Stefan Sperling wrote:
> > Here's another suggestion which doesn't impact the code path for
> > other interrupts. Fixes the problem just as well.
>
> This also helps -- all ideas in here from deraadt@.
>
> It's better than my other diffs, but we're not entirely sure if this
> is the best possible fix.
I think this one makes the most sense.
However. If there really is an SMBus slave device that is asserting
SMBALERT#, ignoring it will mean that the interrupt handler gets
called over and over again. That's probably not going to be a
full-blown interrupt storm as the SMBus device is fairly low-speed.
But what we really should do the SMBALERT# dance of reading the Alert
Response Address, which will make sure the device de-asserts the
SMBALERT# line.
If we're going with this diff, it would be good to add an XXX comment
that we ignore SMBALERT# for now.
> Index: ichiic.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/ichiic.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 ichiic.c
> --- ichiic.c 7 Dec 2015 02:56:36 -0000 1.37
> +++ ichiic.c 11 Mar 2016 17:22:10 -0000
> @@ -340,17 +340,18 @@ ichiic_intr(void *arg)
>
> /* Read status */
> st = bus_space_read_1(sc->sc_iot, sc->sc_ioh, ICH_SMB_HS);
> +
> + /* Clear status bits */
> + bus_space_write_1(sc->sc_iot, sc->sc_ioh, ICH_SMB_HS, st);
> +
> if ((st & ICH_SMB_HS_BUSY) != 0 || (st & (ICH_SMB_HS_INTR |
> ICH_SMB_HS_DEVERR | ICH_SMB_HS_BUSERR | ICH_SMB_HS_FAILED |
> - ICH_SMB_HS_SMBAL | ICH_SMB_HS_BDONE)) == 0)
> + ICH_SMB_HS_BDONE)) == 0)
> /* Interrupt was not for us */
> return (0);
>
> DPRINTF(("%s: intr st 0x%b\n", sc->sc_dev.dv_xname, st,
> ICH_SMB_HS_BITS));
> -
> - /* Clear status bits */
> - bus_space_write_1(sc->sc_iot, sc->sc_ioh, ICH_SMB_HS, st);
>
> /* Check for errors */
> if (st & (ICH_SMB_HS_DEVERR | ICH_SMB_HS_BUSERR | ICH_SMB_HS_FAILED)) {
>
>
