On Sat, 26 Jun 2021 14:41:13 +0900
Hector Martin <marcan@xxxxxxxxx> wrote:
> + /*
> + * The controller provides a bit that implements a mutex mechanism
> + * between users of the bus. First, try to lock the hardware mutex.
> + * If this doesn't work, we give up trying to do this, but then
> + * bail if ACPI uses SMBus at all.
> + */
> + if (!priv->inuse_stuck) {
> + while (inb_p(SMBHSTSTS(priv)) & SMBHSTSTS_INUSE_STS) {
> + if (++timeout >= MAX_RETRIES) {
> + dev_warn(&priv->pci_dev->dev,
> + "BIOS left SMBus locked\n");
> + priv->inuse_stuck = true;
> + break;
> + }
> + usleep_range(250, 500);
> + }
> + }
> +
> mutex_lock(&priv->acpi_lock);
Hi Hector,
I do have a question about the order of mutex locking here: Wouldn't it
be better to lock priv->acpi_lock before trying to lock the hardware
mutex? As it is, if a large number of threads are all trying to read
from the SMBus concurrently, couldn't the loop time out and print the
message "BIOS left SMBus locked" when it's really not the BIOS's fault?
-Alex
