On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote:
> On Fri, Jul 8, 2016 at 4:51 PM, joshua stein <[email protected]> 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.
