Hi,
One more remark inline.
On 8/8/19 11:55 PM, Yauhen Kharuzhy wrote:
Existing intel_cht_int33fe ACPI pseudo-device driver assumes that
hardware has TypeC connector and register related devices described as
I2C connections in the _CRS resource.
There at least one hardware (Lenovo Yoga Book YB1-91L/F) with microUSB
connector exists. It has INT33FE device in the DSDT table but there are
only two I2C connection described: PMIC and BQ27452 battery fuel gauge.
Splitting existing INT33FE driver allow to maintain code for microUSB
variant separately and make it simpler.
Signed-off-by: Yauhen Kharuzhy <jekhor@xxxxxxxxx>
---
<snip>
diff --git a/drivers/platform/x86/intel_cht_int33fe_musb.c b/drivers/platform/x86/intel_cht_int33fe_musb.c
new file mode 100644
index 000000000000..49a8d34ac666
--- /dev/null
+++ b/drivers/platform/x86/intel_cht_int33fe_musb.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Cherry Trail ACPI INT33FE pseudo device driver for devices with
+ * microUSB connector (e.g. without of FUSB302 USB Type-C controller)
+ *
+ * Copyright (C) 2019 Yauhen Kharuzhy <jekhor@xxxxxxxxx>
+ *
+ * At least one Intel Cherry Trail based device which ship with Windows 10
+ * (Lenovo YogaBook YB1-X91L/F tablet), have this weird INT33FE ACPI device
+ * with a CRS table with 2 I2cSerialBusV2 resources, for 2 different chips
+ * attached to various i2c busses:
+ * 1. The Whiskey Cove pmic, which is also described by the INT34D3 ACPI device
+ * 2. TI BQ27542 Fuel Gauge Controller
+ *
+ * So this driver is a stub / pseudo driver whose only purpose is to
+ * instantiate i2c-client for battery fuel gauge, so that standard i2c driver
+ * for these chip can bind to the it.
+ */
+
+#define DEBUG
+
+#include <linux/acpi.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <linux/usb/pd.h>
+
+#include "intel_cht_int33fe_common.h"
+
+struct cht_int33fe_data {
+ struct i2c_client *battery_fg;
+};
+
+static const char * const bq27xxx_suppliers[] = { "bq25890-charger" };
+
+static const struct property_entry bq27xxx_props[] = {
+ PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq27xxx_suppliers),
+ { }
+};
+
+static int cht_int33fe_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct i2c_board_info board_info;
+ struct cht_int33fe_data *data;
+ int ret;
+
+ ret = cht_int33fe_check_hw_compatible(dev, INT33FE_HW_MUSB);
+ if (ret < 0)
+ return ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ memset(&board_info, 0, sizeof(board_info));
+ stracpy(board_info.type, "bq27542");
stracpy ? that does not compile for me, normally you would use:
strlcpy(board_info.type, "bq27542", I2C_NAME_SIZE);
here, I've used this for my testing.
+ board_info.dev_name = "bq27542";
+ board_info.properties = bq27xxx_props;
+ data->battery_fg = i2c_acpi_new_device(dev, 1, &board_info);
+
+ if (IS_ERR(data->battery_fg)) {
+ dev_err(dev, "Failed to register battery fuel gauge: %ld\n",
+ PTR_ERR(data->battery_fg));
+ return PTR_ERR(data->battery_fg);
+ }
+
+ platform_set_drvdata(pdev, data);
+
+ return 0;
+}
<snip>
With that fixed, I can confirm that everything still works as it should on a
device which uses this driver combined with a Type-C connector.
Regards,
Hans
