On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: > On Fri, Jul 8, 2016 at 4:51 PM, joshua stein <j...@openbsd.org> wrote: > > If the EC fails to go into burst mode for whatever reason, the Burst > > Acknowledge byte will not be there to read, which means the status > > won't have EC_STAT_OBF, which means acpiec_wait will spin forever, > > hanging the machine. > > > > This at least gets us moving again, ignoring the failure to enter > > burst mode. > > Is it truly failing to enter burst mode, or are we just not doing the > dance to enter correctly? Looks like we should be waiting for an SCI > and checking for a burst acknowledge byte?
All subsequent status fetches show that burst is not on. > ... > > @@ -196,7 +197,10 @@ void > > acpiec_burst_enable(struct acpiec_softc *sc) > > { > > acpiec_write_cmd(sc, EC_CMD_BE); > > - acpiec_read_data(sc); > > + if (acpiec_status(sc) & (EC_STAT_BURST|EC_STAT_OBF)) > > + acpiec_read_data(sc); > > + else > > + dnprintf(10, "%s: failed to enter burst mode\n", > > DEVNAME(sc)); > > } > > So if it doesn't immediately set either the burst or OBF flag then > we'll continue on without reading the data? That's going to break > systems where EC isn't always fast to respond, no? That's why the diff also includes the change to acpiec_write_cmd to wait until IBF is 0, so it won't get to that new status check until the controller has processed the EC_CMD_BE fully.