[PATCH 0/2] i2c: i801: Use MMIO if available

[PATCH 0/2] i2c: i801: Use MMIO if available

[Heiner Kallweit]

Newer versions of supported chips support MMIO in addition to legacy
PMIO register access. Probe the MMIO PCI BAR and use faster MMIO
register access if available.

Tested on N100 (Alder Lake-N).

This series is a rebased re-spin of a series submitted last October.

Heiner Kallweit (2):
  i2c: i801: Switch to iomapped register access
  i2c: i801: Use MMIO if available

 drivers/i2c/busses/i2c-i801.c | 157 +++++++++++++++++-----------------
 1 file changed, 79 insertions(+), 78 deletions(-)

-- 
2.48.1

[PATCH 1/2] i2c: i801: Switch to iomapped register access

[Heiner Kallweit]

Switch to iomapped register access as a prerequisite for adding
support for MMIO register access.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/i2c/busses/i2c-i801.c | 149 +++++++++++++++++-----------------
 1 file changed, 73 insertions(+), 76 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 6a4147054..bf5702ccb 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -276,7 +276,7 @@ struct i801_mux_config {
 
 struct i801_priv {
 	struct i2c_adapter adapter;
-	unsigned long smba;
+	void __iomem *smba;
 	unsigned char original_hstcfg;
 	unsigned char original_hstcnt;
 	unsigned char original_slvcmd;
@@ -345,7 +345,7 @@ static int i801_wait_intr(struct i801_priv *priv)
 
 	do {
 		usleep_range(250, 500);
-		status = inb_p(SMBHSTSTS(priv));
+		status = ioread8(SMBHSTSTS(priv));
 		busy = status & SMBHSTSTS_HOST_BUSY;
 		status &= STATUS_ERROR_FLAGS | SMBHSTSTS_INTR;
 		if (!busy && status)
@@ -363,7 +363,7 @@ static int i801_wait_byte_done(struct i801_priv *priv)
 
 	do {
 		usleep_range(250, 500);
-		status = inb_p(SMBHSTSTS(priv));
+		status = ioread8(SMBHSTSTS(priv));
 		if (status & (STATUS_ERROR_FLAGS | SMBHSTSTS_BYTE_DONE))
 			return status & STATUS_ERROR_FLAGS;
 	} while (time_is_after_eq_jiffies(timeout));
@@ -373,7 +373,7 @@ static int i801_wait_byte_done(struct i801_priv *priv)
 
 static int i801_get_block_len(struct i801_priv *priv)
 {
-	u8 len = inb_p(SMBHSTDAT0(priv));
+	u8 len = ioread8(SMBHSTDAT0(priv));
 
 	if (len < 1 || len > I2C_SMBUS_BLOCK_MAX) {
 		pci_err(priv->pci_dev, "Illegal SMBus block read size %u\n", len);
@@ -390,9 +390,9 @@ static int i801_check_and_clear_pec_error(struct i801_priv *priv)
 	if (!(priv->features & FEATURE_SMBUS_PEC))
 		return 0;
 
-	status = inb_p(SMBAUXSTS(priv)) & SMBAUXSTS_CRCE;
+	status = ioread8(SMBAUXSTS(priv)) & SMBAUXSTS_CRCE;
 	if (status) {
-		outb_p(status, SMBAUXSTS(priv));
+		iowrite8(status, SMBAUXSTS(priv));
 		return -EBADMSG;
 	}
 
@@ -405,7 +405,7 @@ static int i801_check_pre(struct i801_priv *priv)
 {
 	int status, result;
 
-	status = inb_p(SMBHSTSTS(priv));
+	status = ioread8(SMBHSTSTS(priv));
 	if (status & SMBHSTSTS_HOST_BUSY) {
 		pci_err(priv->pci_dev, "SMBus is busy, can't use it!\n");
 		return -EBUSY;
@@ -414,7 +414,7 @@ static int i801_check_pre(struct i801_priv *priv)
 	status &= STATUS_FLAGS;
 	if (status) {
 		pci_dbg(priv->pci_dev, "Clearing status flags (%02x)\n", status);
-		outb_p(status, SMBHSTSTS(priv));
+		iowrite8(status, SMBHSTSTS(priv));
 	}
 
 	/*
@@ -440,9 +440,9 @@ static int i801_check_post(struct i801_priv *priv, int status)
 	 */
 	if (unlikely(status < 0)) {
 		/* try to stop the current command */
-		outb_p(SMBHSTCNT_KILL, SMBHSTCNT(priv));
+		iowrite8(SMBHSTCNT_KILL, SMBHSTCNT(priv));
 		status = i801_wait_intr(priv);
-		outb_p(0, SMBHSTCNT(priv));
+		iowrite8(0, SMBHSTCNT(priv));
 
 		/* Check if it worked */
 		if (status < 0 || !(status & SMBHSTSTS_FAILED))
@@ -493,13 +493,13 @@ static int i801_transaction(struct i801_priv *priv, int xact)
 
 	if (priv->features & FEATURE_IRQ) {
 		reinit_completion(&priv->done);
-		outb_p(xact | SMBHSTCNT_INTREN | SMBHSTCNT_START,
+		iowrite8(xact | SMBHSTCNT_INTREN | SMBHSTCNT_START,
 		       SMBHSTCNT(priv));
 		result = wait_for_completion_timeout(&priv->done, adap->timeout);
 		return result ? priv->status : -ETIMEDOUT;
 	}
 
-	outb_p(xact | SMBHSTCNT_START, SMBHSTCNT(priv));
+	iowrite8(xact | SMBHSTCNT_START, SMBHSTCNT(priv));
 
 	return i801_wait_intr(priv);
 }
@@ -508,7 +508,7 @@ static int i801_block_transaction_by_block(struct i801_priv *priv,
 					   union i2c_smbus_data *data,
 					   char read_write, int command)
 {
-	int i, len, status, xact;
+	int len, status, xact;
 
 	switch (command) {
 	case I2C_SMBUS_BLOCK_PROC_CALL:
@@ -522,14 +522,13 @@ static int i801_block_transaction_by_block(struct i801_priv *priv,
 	}
 
 	/* Set block buffer mode */
-	outb_p(inb_p(SMBAUXCTL(priv)) | SMBAUXCTL_E32B, SMBAUXCTL(priv));
+	iowrite8(ioread8(SMBAUXCTL(priv)) | SMBAUXCTL_E32B, SMBAUXCTL(priv));
 
 	if (read_write == I2C_SMBUS_WRITE) {
 		len = data->block[0];
-		outb_p(len, SMBHSTDAT0(priv));
-		inb_p(SMBHSTCNT(priv));	/* reset the data buffer index */
-		for (i = 0; i < len; i++)
-			outb_p(data->block[i+1], SMBBLKDAT(priv));
+		iowrite8(len, SMBHSTDAT0(priv));
+		ioread8(SMBHSTCNT(priv));	/* reset the data buffer index */
+		iowrite8_rep(SMBBLKDAT(priv), data->block + 1, len);
 	}
 
 	status = i801_transaction(priv, xact);
@@ -545,12 +544,11 @@ static int i801_block_transaction_by_block(struct i801_priv *priv,
 		}
 
 		data->block[0] = len;
-		inb_p(SMBHSTCNT(priv));	/* reset the data buffer index */
-		for (i = 0; i < len; i++)
-			data->block[i + 1] = inb_p(SMBBLKDAT(priv));
+		ioread8(SMBHSTCNT(priv));	/* reset the data buffer index */
+		ioread8_rep(SMBBLKDAT(priv), data->block + 1, len);
 	}
 out:
-	outb_p(inb_p(SMBAUXCTL(priv)) & ~SMBAUXCTL_E32B, SMBAUXCTL(priv));
+	iowrite8(ioread8(SMBAUXCTL(priv)) & ~SMBAUXCTL_E32B, SMBAUXCTL(priv));
 	return status;
 }
 
@@ -573,17 +571,17 @@ static void i801_isr_byte_done(struct i801_priv *priv)
 
 		/* Read next byte */
 		if (priv->count < priv->len)
-			priv->data[priv->count++] = inb(SMBBLKDAT(priv));
+			priv->data[priv->count++] = ioread8(SMBBLKDAT(priv));
 		else
 			pci_dbg(priv->pci_dev, "Discarding extra byte on block read\n");
 
 		/* Set LAST_BYTE for last byte of read transaction */
 		if (priv->count == priv->len - 1)
-			outb_p(priv->cmd | SMBHSTCNT_LAST_BYTE,
+			iowrite8(priv->cmd | SMBHSTCNT_LAST_BYTE,
 			       SMBHSTCNT(priv));
 	} else if (priv->count < priv->len - 1) {
 		/* Write next byte, except for IRQ after last byte */
-		outb_p(priv->data[++priv->count], SMBBLKDAT(priv));
+		iowrite8(priv->data[++priv->count], SMBBLKDAT(priv));
 	}
 }
 
@@ -591,7 +589,7 @@ static irqreturn_t i801_host_notify_isr(struct i801_priv *priv)
 {
 	unsigned short addr;
 
-	addr = inb_p(SMBNTFDADD(priv)) >> 1;
+	addr = ioread8(SMBNTFDADD(priv)) >> 1;
 
 	/*
 	 * With the tested platforms, reading SMBNTFDDAT (22 + (p)->smba)
@@ -601,7 +599,7 @@ static irqreturn_t i801_host_notify_isr(struct i801_priv *priv)
 	i2c_handle_smbus_host_notify(&priv->adapter, addr);
 
 	/* clear Host Notify bit and return */
-	outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
+	iowrite8(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
 	return IRQ_HANDLED;
 }
 
@@ -632,12 +630,12 @@ static irqreturn_t i801_isr(int irq, void *dev_id)
 		return IRQ_NONE;
 
 	if (priv->features & FEATURE_HOST_NOTIFY) {
-		status = inb_p(SMBSLVSTS(priv));
+		status = ioread8(SMBSLVSTS(priv));
 		if (status & SMBSLVSTS_HST_NTFY_STS)
 			return i801_host_notify_isr(priv);
 	}
 
-	status = inb_p(SMBHSTSTS(priv));
+	status = ioread8(SMBHSTSTS(priv));
 	if ((status & (SMBHSTSTS_BYTE_DONE | STATUS_ERROR_FLAGS)) == SMBHSTSTS_BYTE_DONE)
 		i801_isr_byte_done(priv);
 
@@ -647,7 +645,7 @@ static irqreturn_t i801_isr(int irq, void *dev_id)
 	 * so clear it always when the status is set.
 	 */
 	status &= STATUS_FLAGS | SMBHSTSTS_SMBALERT_STS;
-	outb_p(status, SMBHSTSTS(priv));
+	iowrite8(status, SMBHSTSTS(priv));
 
 	status &= STATUS_ERROR_FLAGS | SMBHSTSTS_INTR;
 	if (status) {
@@ -679,8 +677,8 @@ static int i801_block_transaction_byte_by_byte(struct i801_priv *priv,
 	len = data->block[0];
 
 	if (read_write == I2C_SMBUS_WRITE) {
-		outb_p(len, SMBHSTDAT0(priv));
-		outb_p(data->block[1], SMBBLKDAT(priv));
+		iowrite8(len, SMBHSTDAT0(priv));
+		iowrite8(data->block[1], SMBBLKDAT(priv));
 	}
 
 	if (command == I2C_SMBUS_I2C_BLOCK_DATA &&
@@ -699,14 +697,14 @@ static int i801_block_transaction_byte_by_byte(struct i801_priv *priv,
 		priv->data = &data->block[1];
 
 		reinit_completion(&priv->done);
-		outb_p(priv->cmd | SMBHSTCNT_START, SMBHSTCNT(priv));
+		iowrite8(priv->cmd | SMBHSTCNT_START, SMBHSTCNT(priv));
 		result = wait_for_completion_timeout(&priv->done, adap->timeout);
 		return result ? priv->status : -ETIMEDOUT;
 	}
 
 	if (len == 1 && read_write == I2C_SMBUS_READ)
 		smbcmd |= SMBHSTCNT_LAST_BYTE;
-	outb_p(smbcmd | SMBHSTCNT_START, SMBHSTCNT(priv));
+	iowrite8(smbcmd | SMBHSTCNT_START, SMBHSTCNT(priv));
 
 	for (i = 1; i <= len; i++) {
 		status = i801_wait_byte_done(priv);
@@ -722,27 +720,27 @@ static int i801_block_transaction_byte_by_byte(struct i801_priv *priv,
 			len = i801_get_block_len(priv);
 			if (len < 0) {
 				/* Recover */
-				while (inb_p(SMBHSTSTS(priv)) &
+				while (ioread8(SMBHSTSTS(priv)) &
 				       SMBHSTSTS_HOST_BUSY)
-					outb_p(SMBHSTSTS_BYTE_DONE,
+					iowrite8(SMBHSTSTS_BYTE_DONE,
 					       SMBHSTSTS(priv));
-				outb_p(SMBHSTSTS_INTR, SMBHSTSTS(priv));
+				iowrite8(SMBHSTSTS_INTR, SMBHSTSTS(priv));
 				return -EPROTO;
 			}
 			data->block[0] = len;
 		}
 
 		if (read_write == I2C_SMBUS_READ) {
-			data->block[i] = inb_p(SMBBLKDAT(priv));
+			data->block[i] = ioread8(SMBBLKDAT(priv));
 			if (i == len - 1)
-				outb_p(smbcmd | SMBHSTCNT_LAST_BYTE, SMBHSTCNT(priv));
+				iowrite8(smbcmd | SMBHSTCNT_LAST_BYTE, SMBHSTCNT(priv));
 		}
 
 		if (read_write == I2C_SMBUS_WRITE && i+1 <= len)
-			outb_p(data->block[i+1], SMBBLKDAT(priv));
+			iowrite8(data->block[i+1], SMBBLKDAT(priv));
 
 		/* signals SMBBLKDAT ready */
-		outb_p(SMBHSTSTS_BYTE_DONE, SMBHSTSTS(priv));
+		iowrite8(SMBHSTSTS_BYTE_DONE, SMBHSTSTS(priv));
 	}
 
 	return i801_wait_intr(priv);
@@ -750,7 +748,7 @@ static int i801_block_transaction_byte_by_byte(struct i801_priv *priv,
 
 static void i801_set_hstadd(struct i801_priv *priv, u8 addr, char read_write)
 {
-	outb_p((addr << 1) | (read_write & 0x01), SMBHSTADD(priv));
+	iowrite8((addr << 1) | (read_write & 0x01), SMBHSTADD(priv));
 }
 
 /* Single value transaction function */
@@ -767,30 +765,30 @@ static int i801_simple_transaction(struct i801_priv *priv, union i2c_smbus_data
 	case I2C_SMBUS_BYTE:
 		i801_set_hstadd(priv, addr, read_write);
 		if (read_write == I2C_SMBUS_WRITE)
-			outb_p(hstcmd, SMBHSTCMD(priv));
+			iowrite8(hstcmd, SMBHSTCMD(priv));
 		xact = I801_BYTE;
 		break;
 	case I2C_SMBUS_BYTE_DATA:
 		i801_set_hstadd(priv, addr, read_write);
 		if (read_write == I2C_SMBUS_WRITE)
-			outb_p(data->byte, SMBHSTDAT0(priv));
-		outb_p(hstcmd, SMBHSTCMD(priv));
+			iowrite8(data->byte, SMBHSTDAT0(priv));
+		iowrite8(hstcmd, SMBHSTCMD(priv));
 		xact = I801_BYTE_DATA;
 		break;
 	case I2C_SMBUS_WORD_DATA:
 		i801_set_hstadd(priv, addr, read_write);
 		if (read_write == I2C_SMBUS_WRITE) {
-			outb_p(data->word & 0xff, SMBHSTDAT0(priv));
-			outb_p((data->word & 0xff00) >> 8, SMBHSTDAT1(priv));
+			iowrite8(data->word & 0xff, SMBHSTDAT0(priv));
+			iowrite8((data->word & 0xff00) >> 8, SMBHSTDAT1(priv));
 		}
-		outb_p(hstcmd, SMBHSTCMD(priv));
+		iowrite8(hstcmd, SMBHSTCMD(priv));
 		xact = I801_WORD_DATA;
 		break;
 	case I2C_SMBUS_PROC_CALL:
 		i801_set_hstadd(priv, addr, I2C_SMBUS_WRITE);
-		outb_p(data->word & 0xff, SMBHSTDAT0(priv));
-		outb_p((data->word & 0xff00) >> 8, SMBHSTDAT1(priv));
-		outb_p(hstcmd, SMBHSTCMD(priv));
+		iowrite8(data->word & 0xff, SMBHSTDAT0(priv));
+		iowrite8((data->word & 0xff00) >> 8, SMBHSTDAT1(priv));
+		iowrite8(hstcmd, SMBHSTCMD(priv));
 		read_write = I2C_SMBUS_READ;
 		xact = I801_PROC_CALL;
 		break;
@@ -806,12 +804,12 @@ static int i801_simple_transaction(struct i801_priv *priv, union i2c_smbus_data
 	switch (command) {
 	case I2C_SMBUS_BYTE:
 	case I2C_SMBUS_BYTE_DATA:
-		data->byte = inb_p(SMBHSTDAT0(priv));
+		data->byte = ioread8(SMBHSTDAT0(priv));
 		break;
 	case I2C_SMBUS_WORD_DATA:
 	case I2C_SMBUS_PROC_CALL:
-		data->word = inb_p(SMBHSTDAT0(priv)) +
-			     (inb_p(SMBHSTDAT1(priv)) << 8);
+		data->word = ioread8(SMBHSTDAT0(priv)) +
+			     (ioread8(SMBHSTDAT1(priv)) << 8);
 		break;
 	}
 
@@ -832,7 +830,7 @@ static int i801_smbus_block_transaction(struct i801_priv *priv, union i2c_smbus_
 		i801_set_hstadd(priv, addr, I2C_SMBUS_WRITE);
 	else
 		i801_set_hstadd(priv, addr, read_write);
-	outb_p(hstcmd, SMBHSTCMD(priv));
+	iowrite8(hstcmd, SMBHSTCMD(priv));
 
 	if (priv->features & FEATURE_BLOCK_BUFFER)
 		return i801_block_transaction_by_block(priv, data, read_write, command);
@@ -858,9 +856,9 @@ static int i801_i2c_block_transaction(struct i801_priv *priv, union i2c_smbus_da
 
 	/* NB: page 240 of ICH5 datasheet shows that DATA1 is the cmd field when reading */
 	if (read_write == I2C_SMBUS_READ)
-		outb_p(hstcmd, SMBHSTDAT1(priv));
+		iowrite8(hstcmd, SMBHSTDAT1(priv));
 	else
-		outb_p(hstcmd, SMBHSTCMD(priv));
+		iowrite8(hstcmd, SMBHSTCMD(priv));
 
 	if (read_write == I2C_SMBUS_WRITE) {
 		/* set I2C_EN bit in configuration register */
@@ -903,9 +901,9 @@ static s32 i801_access(struct i2c_adapter *adap, u16 addr,
 		&& size != I2C_SMBUS_I2C_BLOCK_DATA;
 
 	if (hwpec)	/* enable/disable hardware PEC */
-		outb_p(inb_p(SMBAUXCTL(priv)) | SMBAUXCTL_CRC, SMBAUXCTL(priv));
+		iowrite8(ioread8(SMBAUXCTL(priv)) | SMBAUXCTL_CRC, SMBAUXCTL(priv));
 	else
-		outb_p(inb_p(SMBAUXCTL(priv)) & (~SMBAUXCTL_CRC),
+		iowrite8(ioread8(SMBAUXCTL(priv)) & (~SMBAUXCTL_CRC),
 		       SMBAUXCTL(priv));
 
 	if (size == I2C_SMBUS_BLOCK_DATA || size == I2C_SMBUS_BLOCK_PROC_CALL)
@@ -921,13 +919,13 @@ static s32 i801_access(struct i2c_adapter *adap, u16 addr,
 	 * time, so we forcibly disable it after every transaction.
 	 */
 	if (hwpec)
-		outb_p(inb_p(SMBAUXCTL(priv)) & ~SMBAUXCTL_CRC, SMBAUXCTL(priv));
+		iowrite8(ioread8(SMBAUXCTL(priv)) & ~SMBAUXCTL_CRC, SMBAUXCTL(priv));
 out:
 	/*
 	 * Unlock the SMBus device for use by BIOS/ACPI,
 	 * and clear status flags if not done already.
 	 */
-	outb_p(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv));
+	iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv));
 
 	pm_runtime_mark_last_busy(&priv->pci_dev->dev);
 	pm_runtime_put_autosuspend(&priv->pci_dev->dev);
@@ -964,11 +962,11 @@ static void i801_enable_host_notify(struct i2c_adapter *adapter)
 	 * from the SMB_ALERT signal because the driver does not support
 	 * SMBus Alert.
 	 */
-	outb_p(SMBSLVCMD_HST_NTFY_INTREN | SMBSLVCMD_SMBALERT_DISABLE |
+	iowrite8(SMBSLVCMD_HST_NTFY_INTREN | SMBSLVCMD_SMBALERT_DISABLE |
 	       priv->original_slvcmd, SMBSLVCMD(priv));
 
 	/* clear Host Notify bit to allow a new notification */
-	outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
+	iowrite8(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
 }
 
 static void i801_disable_host_notify(struct i801_priv *priv)
@@ -976,7 +974,7 @@ static void i801_disable_host_notify(struct i801_priv *priv)
 	if (!(priv->features & FEATURE_HOST_NOTIFY))
 		return;
 
-	outb_p(priv->original_slvcmd, SMBSLVCMD(priv));
+	iowrite8(priv->original_slvcmd, SMBSLVCMD(priv));
 }
 
 static const struct i2c_algorithm smbus_algorithm = {
@@ -1441,7 +1439,7 @@ static void i801_add_tco(struct i801_priv *priv)
 static bool i801_acpi_is_smbus_ioport(const struct i801_priv *priv,
 				      acpi_physical_address address)
 {
-	return address >= priv->smba &&
+	return address >= pci_resource_start(priv->pci_dev, SMBBAR) &&
 	       address <= pci_resource_end(priv->pci_dev, SMBBAR);
 }
 
@@ -1518,7 +1516,7 @@ static void i801_setup_hstcfg(struct i801_priv *priv)
 
 static void i801_restore_regs(struct i801_priv *priv)
 {
-	outb_p(priv->original_hstcnt, SMBHSTCNT(priv));
+	iowrite8(priv->original_hstcnt, SMBHSTCNT(priv));
 	pci_write_config_byte(priv->pci_dev, SMBHSTCFG, priv->original_hstcfg);
 }
 
@@ -1564,8 +1562,7 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	}
 
 	/* Determine the address of the SMBus area */
-	priv->smba = pci_resource_start(dev, SMBBAR);
-	if (!priv->smba) {
+	if (!pci_resource_start(dev, SMBBAR)) {
 		pci_err(dev, "SMBus base address uninitialized, upgrade BIOS\n");
 		return -ENODEV;
 	}
@@ -1573,12 +1570,12 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	if (i801_acpi_probe(priv))
 		return -ENODEV;
 
-	err = pcim_iomap_regions(dev, 1 << SMBBAR, DRV_NAME);
-	if (err) {
+	priv->smba = pcim_iomap_region(dev, SMBBAR, DRV_NAME);
+	if (IS_ERR(priv->smba)) {
 		pci_err(dev, "Failed to request SMBus region %pr\n",
 			pci_resource_n(dev, SMBBAR));
 		i801_acpi_remove(priv);
-		return err;
+		return PTR_ERR(priv->smba);
 	}
 
 	pci_read_config_byte(dev, SMBHSTCFG, &priv->original_hstcfg);
@@ -1596,7 +1593,7 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 
 	/* Clear special mode bits */
 	if (priv->features & (FEATURE_SMBUS_PEC | FEATURE_BLOCK_BUFFER))
-		outb_p(inb_p(SMBAUXCTL(priv)) &
+		iowrite8(ioread8(SMBAUXCTL(priv)) &
 		       ~(SMBAUXCTL_CRC | SMBAUXCTL_E32B), SMBAUXCTL(priv));
 
 	/* Default timeout in interrupt mode: 200 ms */
@@ -1632,9 +1629,9 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 		priv->features &= ~FEATURE_HOST_NOTIFY;
 
 	/* Remember original Interrupt and Host Notify settings */
-	priv->original_hstcnt = inb_p(SMBHSTCNT(priv)) & ~SMBHSTCNT_KILL;
+	priv->original_hstcnt = ioread8(SMBHSTCNT(priv)) & ~SMBHSTCNT_KILL;
 	if (priv->features & FEATURE_HOST_NOTIFY)
-		priv->original_slvcmd = inb_p(SMBSLVCMD(priv));
+		priv->original_slvcmd = ioread8(SMBSLVCMD(priv));
 
 	i801_add_tco(priv);
 
@@ -1643,9 +1640,9 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	 * to instantiante i2c_clients, do not change.
 	 */
 	snprintf(priv->adapter.name, sizeof(priv->adapter.name),
-		 "SMBus %s adapter at %04lx",
+		 "SMBus %s adapter at %s",
 		 (priv->features & FEATURE_IDF) ? "I801 IDF" : "I801",
-		 priv->smba);
+		 pci_name(dev));
 
 	err = i2c_add_adapter(&priv->adapter);
 	if (err) {
-- 
2.48.1

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andy Shevchenko]

Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
> Switch to iomapped register access as a prerequisite for adding
> support for MMIO register access.

I believe that I at least discussed the similar change a few years ago or even
proposed a one. The problem here is that *_p() variants of IO port accessors
are not the same as non-_p ones. And commit message is kept silent about
possible consequences of this change.

So, at bare minumum it would be good to test for some period of time before
going for it.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andi Shyti]

Hi Andy,

On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
> > Switch to iomapped register access as a prerequisite for adding
> > support for MMIO register access.
> 
> I believe that I at least discussed the similar change a few years ago or even
> proposed a one. The problem here is that *_p() variants of IO port accessors
> are not the same as non-_p ones. And commit message is kept silent about
> possible consequences of this change.
> 
> So, at bare minumum it would be good to test for some period of time before
> going for it.

How would you do it?

Andi

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Heiner Kallweit]

On 19.03.2025 00:22, Andi Shyti wrote:
> Hi Andy,
> 
> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
>>> Switch to iomapped register access as a prerequisite for adding
>>> support for MMIO register access.
>>
>> I believe that I at least discussed the similar change a few years ago or even
>> proposed a one. The problem here is that *_p() variants of IO port accessors
>> are not the same as non-_p ones. And commit message is kept silent about
>> possible consequences of this change.
>>
>> So, at bare minumum it would be good to test for some period of time before
>> going for it.
> 
> How would you do it?
> 

Documentation/driver-api/device-io.rst states that the artificially delayed
_p versions were needed on ISA devices. And in general I didn't find any hint
that the non-delayed versions ever caused issues on PCI devices.
On my system using the non-delayed version works fine, but I can't say 100%
that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.

Likely users with old systems don't run -next kernels, therefore leaving
this change a full cycle in -next may not really help. We can argue that
we have the -rc period for testing (and reverting if needed).

> Andi

Heiner

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andy Shevchenko]

On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> On 19.03.2025 00:22, Andi Shyti wrote:
> > On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
> >> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:


> >>> Switch to iomapped register access as a prerequisite for adding
> >>> support for MMIO register access.
> >>
> >> I believe that I at least discussed the similar change a few years ago or even
> >> proposed a one. The problem here is that *_p() variants of IO port accessors
> >> are not the same as non-_p ones. And commit message is kept silent about
> >> possible consequences of this change.
> >>
> >> So, at bare minumum it would be good to test for some period of time before
> >> going for it.
> >
> > How would you do it?
>
> Documentation/driver-api/device-io.rst states that the artificially delayed
> _p versions were needed on ISA devices. And in general I didn't find any hint
> that the non-delayed versions ever caused issues on PCI devices.

At least put this in the commit message. It will show that you were aware of _p.

> On my system using the non-delayed version works fine, but I can't say 100%
> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
>
> Likely users with old systems don't run -next kernels, therefore leaving
> this change a full cycle in -next may not really help. We can argue that
> we have the -rc period for testing (and reverting if needed).

My main concern is to make no regressions for most currently used
cases, that's why one cycle in Linux Next is better than none.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Heiner Kallweit]

On 19.03.2025 09:23, Andy Shevchenko wrote:
> On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> On 19.03.2025 00:22, Andi Shyti wrote:
>>> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
>>>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
> 
> 
>>>>> Switch to iomapped register access as a prerequisite for adding
>>>>> support for MMIO register access.
>>>>
>>>> I believe that I at least discussed the similar change a few years ago or even
>>>> proposed a one. The problem here is that *_p() variants of IO port accessors
>>>> are not the same as non-_p ones. And commit message is kept silent about
>>>> possible consequences of this change.
>>>>
>>>> So, at bare minumum it would be good to test for some period of time before
>>>> going for it.
>>>
>>> How would you do it?
>>
>> Documentation/driver-api/device-io.rst states that the artificially delayed
>> _p versions were needed on ISA devices. And in general I didn't find any hint
>> that the non-delayed versions ever caused issues on PCI devices.
> 
> At least put this in the commit message. It will show that you were aware of _p.
> 
>> On my system using the non-delayed version works fine, but I can't say 100%
>> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
>>
>> Likely users with old systems don't run -next kernels, therefore leaving
>> this change a full cycle in -next may not really help. We can argue that
>> we have the -rc period for testing (and reverting if needed).
> 
> My main concern is to make no regressions for most currently used
> cases, that's why one cycle in Linux Next is better than none.
> 

Even ICH7 datasheet from 2012 mentions that SMBus register space is also
memory-mapped. So all systems from at least the last 10 yrs should use MMIO
instead of PMIO now, and therefore not be affected by switching to non-delayed
PMIO access. This should significantly reduce the risk you're referring to.

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andy Shevchenko]

On Wed, Mar 19, 2025 at 9:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> On 19.03.2025 09:23, Andy Shevchenko wrote:
> > On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >> On 19.03.2025 00:22, Andi Shyti wrote:
> >>> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
> >>>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
> >
> >>>>> Switch to iomapped register access as a prerequisite for adding
> >>>>> support for MMIO register access.
> >>>>
> >>>> I believe that I at least discussed the similar change a few years ago or even
> >>>> proposed a one. The problem here is that *_p() variants of IO port accessors
> >>>> are not the same as non-_p ones. And commit message is kept silent about
> >>>> possible consequences of this change.
> >>>>
> >>>> So, at bare minumum it would be good to test for some period of time before
> >>>> going for it.
> >>>
> >>> How would you do it?
> >>
> >> Documentation/driver-api/device-io.rst states that the artificially delayed
> >> _p versions were needed on ISA devices. And in general I didn't find any hint
> >> that the non-delayed versions ever caused issues on PCI devices.
> >
> > At least put this in the commit message. It will show that you were aware of _p.
> >
> >> On my system using the non-delayed version works fine, but I can't say 100%
> >> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
> >>
> >> Likely users with old systems don't run -next kernels, therefore leaving
> >> this change a full cycle in -next may not really help. We can argue that
> >> we have the -rc period for testing (and reverting if needed).
> >
> > My main concern is to make no regressions for most currently used
> > cases, that's why one cycle in Linux Next is better than none.
>
> Even ICH7 datasheet from 2012 mentions that SMBus register space is also
> memory-mapped. So all systems from at least the last 10 yrs should use MMIO
> instead of PMIO now, and therefore not be affected by switching to non-delayed
> PMIO access. This should significantly reduce the risk you're referring to.

Cool! So, can we just put a summary into the commit message of all
findings, worries (or their absence)?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Heiner Kallweit]

On 19.03.2025 20:48, Andy Shevchenko wrote:
> On Wed, Mar 19, 2025 at 9:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> On 19.03.2025 09:23, Andy Shevchenko wrote:
>>> On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>>> On 19.03.2025 00:22, Andi Shyti wrote:
>>>>> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
>>>>>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
>>>
>>>>>>> Switch to iomapped register access as a prerequisite for adding
>>>>>>> support for MMIO register access.
>>>>>>
>>>>>> I believe that I at least discussed the similar change a few years ago or even
>>>>>> proposed a one. The problem here is that *_p() variants of IO port accessors
>>>>>> are not the same as non-_p ones. And commit message is kept silent about
>>>>>> possible consequences of this change.
>>>>>>
>>>>>> So, at bare minumum it would be good to test for some period of time before
>>>>>> going for it.
>>>>>
>>>>> How would you do it?
>>>>
>>>> Documentation/driver-api/device-io.rst states that the artificially delayed
>>>> _p versions were needed on ISA devices. And in general I didn't find any hint
>>>> that the non-delayed versions ever caused issues on PCI devices.
>>>
>>> At least put this in the commit message. It will show that you were aware of _p.
>>>
>>>> On my system using the non-delayed version works fine, but I can't say 100%
>>>> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
>>>>
>>>> Likely users with old systems don't run -next kernels, therefore leaving
>>>> this change a full cycle in -next may not really help. We can argue that
>>>> we have the -rc period for testing (and reverting if needed).
>>>
>>> My main concern is to make no regressions for most currently used
>>> cases, that's why one cycle in Linux Next is better than none.
>>
>> Even ICH7 datasheet from 2012 mentions that SMBus register space is also
>> memory-mapped. So all systems from at least the last 10 yrs should use MMIO
>> instead of PMIO now, and therefore not be affected by switching to non-delayed
>> PMIO access. This should significantly reduce the risk you're referring to.
> 
> Cool! So, can we just put a summary into the commit message of all
> findings, worries (or their absence)?
> 
Sure. Would be a question to Andi how this should be done technically.

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andi Shyti]

On Wed, Mar 19, 2025 at 09:26:35PM +0100, Heiner Kallweit wrote:
> On 19.03.2025 20:48, Andy Shevchenko wrote:
> > On Wed, Mar 19, 2025 at 9:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >> On 19.03.2025 09:23, Andy Shevchenko wrote:
> >>> On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>> On 19.03.2025 00:22, Andi Shyti wrote:
> >>>>> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
> >>>>>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
> >>>
> >>>>>>> Switch to iomapped register access as a prerequisite for adding
> >>>>>>> support for MMIO register access.
> >>>>>>
> >>>>>> I believe that I at least discussed the similar change a few years ago or even
> >>>>>> proposed a one. The problem here is that *_p() variants of IO port accessors
> >>>>>> are not the same as non-_p ones. And commit message is kept silent about
> >>>>>> possible consequences of this change.
> >>>>>>
> >>>>>> So, at bare minumum it would be good to test for some period of time before
> >>>>>> going for it.
> >>>>>
> >>>>> How would you do it?
> >>>>
> >>>> Documentation/driver-api/device-io.rst states that the artificially delayed
> >>>> _p versions were needed on ISA devices. And in general I didn't find any hint
> >>>> that the non-delayed versions ever caused issues on PCI devices.
> >>>
> >>> At least put this in the commit message. It will show that you were aware of _p.
> >>>
> >>>> On my system using the non-delayed version works fine, but I can't say 100%
> >>>> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
> >>>>
> >>>> Likely users with old systems don't run -next kernels, therefore leaving
> >>>> this change a full cycle in -next may not really help. We can argue that
> >>>> we have the -rc period for testing (and reverting if needed).
> >>>
> >>> My main concern is to make no regressions for most currently used
> >>> cases, that's why one cycle in Linux Next is better than none.
> >>
> >> Even ICH7 datasheet from 2012 mentions that SMBus register space is also
> >> memory-mapped. So all systems from at least the last 10 yrs should use MMIO
> >> instead of PMIO now, and therefore not be affected by switching to non-delayed
> >> PMIO access. This should significantly reduce the risk you're referring to.
> > 
> > Cool! So, can we just put a summary into the commit message of all
> > findings, worries (or their absence)?
> > 
> Sure. Would be a question to Andi how this should be done technically.

yes, please do and I will update the commit. You can even provide
the new commit message in reply to this email and I will update
the rest.

Thanks,
Andi

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Heiner Kallweit]

On 19.03.2025 22:53, Andi Shyti wrote:
> On Wed, Mar 19, 2025 at 09:26:35PM +0100, Heiner Kallweit wrote:
>> On 19.03.2025 20:48, Andy Shevchenko wrote:
>>> On Wed, Mar 19, 2025 at 9:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>>> On 19.03.2025 09:23, Andy Shevchenko wrote:
>>>>> On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>>>>> On 19.03.2025 00:22, Andi Shyti wrote:
>>>>>>> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
>>>>>>>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
>>>>>
>>>>>>>>> Switch to iomapped register access as a prerequisite for adding
>>>>>>>>> support for MMIO register access.
>>>>>>>>
>>>>>>>> I believe that I at least discussed the similar change a few years ago or even
>>>>>>>> proposed a one. The problem here is that *_p() variants of IO port accessors
>>>>>>>> are not the same as non-_p ones. And commit message is kept silent about
>>>>>>>> possible consequences of this change.
>>>>>>>>
>>>>>>>> So, at bare minumum it would be good to test for some period of time before
>>>>>>>> going for it.
>>>>>>>
>>>>>>> How would you do it?
>>>>>>
>>>>>> Documentation/driver-api/device-io.rst states that the artificially delayed
>>>>>> _p versions were needed on ISA devices. And in general I didn't find any hint
>>>>>> that the non-delayed versions ever caused issues on PCI devices.
>>>>>
>>>>> At least put this in the commit message. It will show that you were aware of _p.
>>>>>
>>>>>> On my system using the non-delayed version works fine, but I can't say 100%
>>>>>> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
>>>>>>
>>>>>> Likely users with old systems don't run -next kernels, therefore leaving
>>>>>> this change a full cycle in -next may not really help. We can argue that
>>>>>> we have the -rc period for testing (and reverting if needed).
>>>>>
>>>>> My main concern is to make no regressions for most currently used
>>>>> cases, that's why one cycle in Linux Next is better than none.
>>>>
>>>> Even ICH7 datasheet from 2012 mentions that SMBus register space is also
>>>> memory-mapped. So all systems from at least the last 10 yrs should use MMIO
>>>> instead of PMIO now, and therefore not be affected by switching to non-delayed
>>>> PMIO access. This should significantly reduce the risk you're referring to.
>>>
>>> Cool! So, can we just put a summary into the commit message of all
>>> findings, worries (or their absence)?
>>>
>> Sure. Would be a question to Andi how this should be done technically.
> 
> yes, please do and I will update the commit. You can even provide
> the new commit message in reply to this email and I will update
> the rest.
> 
Updated commit message for d4ac3f93ff23:

Switch to iomapped register access as a prerequisite for adding
support for MMIO register access.

This changes replaces the delayed inb_p/outb_p calls with calls to
ioread8/iowrite8 which don't have this extra delay. According to
Documentation/driver-api/device-io.rst the _p versions are needed
for ISA device access only, therefore switching to the non-delayed
versions should not cause problems. However a certain risk remains,
which on the other hand is significantly reduced by the fact that
recent systems will use MMIO instead of PIO. ICH7 datasheet from 2012
mentions already that SMBus register space is also memory-mapped.
So all systems from at least the last 10 yrs should be safe.


> Thanks,
> Andi

Heiner

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andy Shevchenko]

On Thu, Mar 20, 2025 at 10:06 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> On 19.03.2025 22:53, Andi Shyti wrote:
> > On Wed, Mar 19, 2025 at 09:26:35PM +0100, Heiner Kallweit wrote:
> >> On 19.03.2025 20:48, Andy Shevchenko wrote:
> >>> On Wed, Mar 19, 2025 at 9:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:

...

> >>> Cool! So, can we just put a summary into the commit message of all
> >>> findings, worries (or their absence)?
> >>>
> >> Sure. Would be a question to Andi how this should be done technically.
> >
> > yes, please do and I will update the commit. You can even provide
> > the new commit message in reply to this email and I will update
> > the rest.
> >
> Updated commit message for d4ac3f93ff23:

Thank you, LGTM!

> Switch to iomapped register access as a prerequisite for adding
> support for MMIO register access.
>
> This changes replaces the delayed inb_p/outb_p calls with calls to

inb_p()/outb_p()

> ioread8/iowrite8 which don't have this extra delay. According to

ioread8()/iowrite8()

> Documentation/driver-api/device-io.rst the _p versions are needed
> for ISA device access only, therefore switching to the non-delayed
> versions should not cause problems. However a certain risk remains,
> which on the other hand is significantly reduced by the fact that
> recent systems will use MMIO instead of PIO. ICH7 datasheet from 2012
> mentions already that SMBus register space is also memory-mapped.
> So all systems from at least the last 10 yrs should be safe.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] i2c: i801: Switch to iomapped register access

[Andi Shyti]

Hi,

On Thu, Mar 20, 2025 at 09:06:29PM +0100, Heiner Kallweit wrote:
> On 19.03.2025 22:53, Andi Shyti wrote:
> > On Wed, Mar 19, 2025 at 09:26:35PM +0100, Heiner Kallweit wrote:
> >> On 19.03.2025 20:48, Andy Shevchenko wrote:
> >>> On Wed, Mar 19, 2025 at 9:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>> On 19.03.2025 09:23, Andy Shevchenko wrote:
> >>>>> On Wed, Mar 19, 2025 at 9:17 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>>>> On 19.03.2025 00:22, Andi Shyti wrote:
> >>>>>>> On Wed, Mar 19, 2025 at 12:18:47AM +0200, Andy Shevchenko wrote:
> >>>>>>>> Wed, Mar 12, 2025 at 08:07:23PM +0100, Heiner Kallweit kirjoitti:
> >>>>>
> >>>>>>>>> Switch to iomapped register access as a prerequisite for adding
> >>>>>>>>> support for MMIO register access.
> >>>>>>>>
> >>>>>>>> I believe that I at least discussed the similar change a few years ago or even
> >>>>>>>> proposed a one. The problem here is that *_p() variants of IO port accessors
> >>>>>>>> are not the same as non-_p ones. And commit message is kept silent about
> >>>>>>>> possible consequences of this change.
> >>>>>>>>
> >>>>>>>> So, at bare minumum it would be good to test for some period of time before
> >>>>>>>> going for it.
> >>>>>>>
> >>>>>>> How would you do it?
> >>>>>>
> >>>>>> Documentation/driver-api/device-io.rst states that the artificially delayed
> >>>>>> _p versions were needed on ISA devices. And in general I didn't find any hint
> >>>>>> that the non-delayed versions ever caused issues on PCI devices.
> >>>>>
> >>>>> At least put this in the commit message. It will show that you were aware of _p.
> >>>>>
> >>>>>> On my system using the non-delayed version works fine, but I can't say 100%
> >>>>>> that it's the same for the very first (> 25 yrs ago) chipsets supported by i801.
> >>>>>>
> >>>>>> Likely users with old systems don't run -next kernels, therefore leaving
> >>>>>> this change a full cycle in -next may not really help. We can argue that
> >>>>>> we have the -rc period for testing (and reverting if needed).
> >>>>>
> >>>>> My main concern is to make no regressions for most currently used
> >>>>> cases, that's why one cycle in Linux Next is better than none.
> >>>>
> >>>> Even ICH7 datasheet from 2012 mentions that SMBus register space is also
> >>>> memory-mapped. So all systems from at least the last 10 yrs should use MMIO
> >>>> instead of PMIO now, and therefore not be affected by switching to non-delayed
> >>>> PMIO access. This should significantly reduce the risk you're referring to.
> >>>
> >>> Cool! So, can we just put a summary into the commit message of all
> >>> findings, worries (or their absence)?
> >>>
> >> Sure. Would be a question to Andi how this should be done technically.
> > 
> > yes, please do and I will update the commit. You can even provide
> > the new commit message in reply to this email and I will update
> > the rest.
> > 
> Updated commit message for d4ac3f93ff23:
> 
> Switch to iomapped register access as a prerequisite for adding
> support for MMIO register access.
> 
> This changes replaces the delayed inb_p/outb_p calls with calls to
> ioread8/iowrite8 which don't have this extra delay. According to
> Documentation/driver-api/device-io.rst the _p versions are needed
> for ISA device access only, therefore switching to the non-delayed
> versions should not cause problems. However a certain risk remains,
> which on the other hand is significantly reduced by the fact that
> recent systems will use MMIO instead of PIO. ICH7 datasheet from 2012
> mentions already that SMBus register space is also memory-mapped.
> So all systems from at least the last 10 yrs should be safe.

Thanks Heiner, updated!

Andi

[PATCH 2/2] i2c: i801: Use MMIO if available

[Heiner Kallweit]

Newer versions of supported chips support MMIO in addition to legacy
PMIO register access. Probe the MMIO PCI BAR and use faster MMIO
register access if available.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/i2c/busses/i2c-i801.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index bf5702ccb..48e1af544 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -144,6 +144,7 @@
 #define SMBNTFDADD(p)	(20 + (p)->smba)	/* ICH3 and later */
 
 /* PCI Address Constants */
+#define SMBBAR_MMIO	0
 #define SMBBAR		4
 #define SMBHSTCFG	0x040
 #define TCOBASE		0x050
@@ -1522,7 +1523,7 @@ static void i801_restore_regs(struct i801_priv *priv)
 
 static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
-	int err, i;
+	int err, i, bar = SMBBAR;
 	struct i801_priv *priv;
 
 	priv = devm_kzalloc(&dev->dev, sizeof(*priv), GFP_KERNEL);
@@ -1570,10 +1571,13 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	if (i801_acpi_probe(priv))
 		return -ENODEV;
 
-	priv->smba = pcim_iomap_region(dev, SMBBAR, DRV_NAME);
+	if (pci_resource_flags(dev, SMBBAR_MMIO) & IORESOURCE_MEM)
+		bar = SMBBAR_MMIO;
+
+	priv->smba = pcim_iomap_region(dev, bar, DRV_NAME);
 	if (IS_ERR(priv->smba)) {
 		pci_err(dev, "Failed to request SMBus region %pr\n",
-			pci_resource_n(dev, SMBBAR));
+			pci_resource_n(dev, bar));
 		i801_acpi_remove(priv);
 		return PTR_ERR(priv->smba);
 	}
-- 
2.48.1

Re: [PATCH 0/2] i2c: i801: Use MMIO if available

[Andi Shyti]

Hi Heiner,

> Heiner Kallweit (2):
>   i2c: i801: Switch to iomapped register access
>   i2c: i801: Use MMIO if available

thanks for resending it. It looks good and I applied it to
i2c/i2c-host.

Andi