[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200426104713.216896-3-hdegoede@redhat.com>
Date: Sun, 26 Apr 2020 12:47:13 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: "Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>
Cc: Hans de Goede <hdegoede@...hat.com>, linux-acpi@...r.kernel.org,
platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 2/2] ACPI / scan: Create platform device for CPLM3218 ACPI nodes
Some CPLM3218 ACPI nodes also put the SMBus Alert Response Address (0x0c)
in their ACPI resource table; and they put it there as the first entry,
here is an example from the CPLM3218 device in the DSDT of an Asus T100TA:
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
{
0x00000033,
}
})
Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */
}
The actual I2C address of the sensor in this case is the 0x48 address
from the second resource-table entry. On some other devices
(e.g. HP X2 Bay Trail models, Acer SW5-012) the CPLM3218 node contains
only 1 I2C resource.
Add the CPLM3218 to the I2C multi instantiate list, so that the
i2c-multi-instantiate.c driver can handle it.
Note in the case where there are 2 I2C resources we simply instatiate
i2c-clients for both and let the cm32181 driver figure out that the
first one is not the one it wants.
Doing things this way is actually desirable because on devices where
there are 2 I2C resources it seems that we first need to do a SMBus
read of the 0x0c address before the sensor will respond to I2C transfers
on its actual address.
Signed-off-by: Hans de Goede <hdegoede@...hat.com>
---
drivers/acpi/scan.c | 1 +
drivers/platform/x86/i2c-multi-instantiate.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6d3448895382..937d72fc212c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1544,6 +1544,7 @@ static bool acpi_device_enumeration_by_parent(struct acpi_device *device)
static const struct acpi_device_id i2c_multi_instantiate_ids[] = {
{"BSG1160", },
{"BSG2150", },
+ {"CPLM3218", },
{"INT33FE", },
{"INT3515", },
{}
diff --git a/drivers/platform/x86/i2c-multi-instantiate.c b/drivers/platform/x86/i2c-multi-instantiate.c
index dcafb1a29d17..e1cdc44e6f57 100644
--- a/drivers/platform/x86/i2c-multi-instantiate.c
+++ b/drivers/platform/x86/i2c-multi-instantiate.c
@@ -180,6 +180,12 @@ static const struct i2c_inst_data int3515_data[] = {
{}
};
+static const struct i2c_inst_data cplm3218_data[] = {
+ { "cm32181", PASS_FWNODE },
+ { "cm32181", PASS_FWNODE },
+ {}
+};
+
/*
* Note new device-ids must also be added to i2c_multi_instantiate_ids in
* drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
@@ -187,6 +193,7 @@ static const struct i2c_inst_data int3515_data[] = {
static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
{ "BSG1160", (unsigned long)bsg1160_data },
{ "BSG2150", (unsigned long)bsg2150_data },
+ { "CPLM3218", (unsigned long)cplm3218_data },
{ "INT3515", (unsigned long)int3515_data },
{ }
};
--
2.26.0
Powered by blists - more mailing lists