Enable ACPI-defined peripherals on i2c-piix4 SMBus
Status from this message: Applied to for-current, thanks!
Get series with b4
b4 am 20190802145109.38dd4045@endymionVersions newest first
Changes in v5 from the cover letter
take over from Andrew Cooks who apparently moved to other projects fix style issues reported by Tobin C. Harding
fix potential array overrun
make sure all registered adapters get unregistered
keep ports 3 and 4 on early Hudson2
assume AMD SMBus numbering for ACPI devices
Patches in v5 Applied
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | i2c: piix4: Fix port selection for AMD Family 16h Model 30hdrivers/ | +5 | 1 reply | |
| 2/3 | i2c: piix4: Fix probing of reserved ports on AMD Family 16h Model 30hdrivers/ | +13 | 1 reply | |
| 3/3 | i2c: piix4: Add ACPI supportdrivers/ | +14 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [PATCH v5 0/3] Enable ACPI-defined peripherals on i2c-piix4 SMBus
These patches fix a couple of issues with the i2c-piix4 driver on AMD Family 16h Model 30h SoCs and add ACPI-based enumeration to the i2c-piix4 driver.
Some I2C peripherals, eg. PCA953x IO expander, are not discovered by the probe or detect mechanisms when attached to an SMBus controller that uses the i2c-piix4 SMBus driver.
ACPI provides a mechanism to define these peripherals and the controller port that they're attached to.
Based on earlier work by Andrew Cooks.
Changes:
v5:
take over from Andrew Cooks who apparently moved to other projects fix style issues reported by Tobin C. Harding
fix potential array overrun
make sure all registered adapters get unregistered
keep ports 3 and 4 on early Hudson2
assume AMD SMBus numbering for ACPI devices
v4:
remove unnecessary SB800_MAIN_PORTS constant
reduce piix4_remove change
v3:
take chip revision into account when determining port selection register
v2:
count the adapters, instead of misusing port numbers
Signature · 2 lines
Jean Delvare SUSE L3 Support