| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Jan 2021 16:46:06 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Daniel Scally <djrscally@...il.com>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-i2c@...r.kernel.org, platform-driver-x86@...r.kernel.org,
devel@...ica.org, rjw@...ysocki.net, lenb@...nel.org,
andy@...nel.org, mika.westerberg@...ux.intel.com,
linus.walleij@...aro.org, bgolaszewski@...libre.com,
wsa@...nel.org, lee.jones@...aro.org, hdegoede@...hat.com,
mgross@...ux.intel.com, robert.moore@...el.com,
erik.kaneda@...el.com, sakari.ailus@...ux.intel.com,
kieran.bingham@...asonboard.com
Subject: Re: [PATCH v2 6/7] platform: x86: Add intel_skl_int3472 driver
On Mon, Jan 18, 2021 at 11:15:21AM +0200, Laurent Pinchart wrote:
> On Mon, Jan 18, 2021 at 12:34:27AM +0000, Daniel Scally wrote:
My comments on top of Laurent's to avoid dups.
First of all, PDx86 has its own prefix pattern: "platform/x86: ..."
> > ACPI devices with _HID INT3472 are currently matched to the tps68470
> > driver, however this does not cover all situations in which that _HID
> > occurs. We've encountered three possibilities:
> >
> > 1. On Chrome OS devices, an ACPI device with _HID INT3472 (representing
> > a physical tps68470 device) that requires a GPIO and OpRegion driver
> > 2. On devices designed for Windows, an ACPI device with _HID INT3472
> > (again representing a physical tps68470 device) which requires GPIO,
> > Clock and Regulator drivers.
> > 3. On other devices designed for Windows, an ACPI device with _HID
> > INT3472 which does NOT represent a physical tps68470, and is instead
In cover letter you are using form of "**not**", as well as in prerequisite
patch series, can we be consistent with that?
tps -> TPS (same reason as Laurent put below).
> > used as a dummy device to group some system GPIO lines which are meant
> > to be consumed by the sensor that is dependent on this entry.
> >
> > This commit adds a new module, registering a platform driver to deal
> > with the 3rd scenario plus an i2c-driver to deal with #1 and #2, by
I²C driver ?
> > querying the CLDB buffer found against INT3472 entries to determine
> > which is most appropriate.
...
> > +INTEL SKL INT3472 ACPI DEVICE DRIVER
Here you may spell it in full, i.e. SKYLAKE
> > +M: Daniel Scally <djrscally@...il.com>
> > +S: Maintained
> > +F: drivers/platform/x86/intel_skl_int3472_*
...
> > +config INTEL_SKL_INT3472
> > + tristate "Intel SkyLake ACPI INT3472 Driver"
> > + depends on X86 && ACPI
X86 is a dup. Entire lot of PDx86 is a priory dependent on it (find "if X86"
line in Kconfig).
> > + select REGMAP_I2C
> > + help
> > + This driver adds support for the INT3472 ACPI devices found on some
> > + Intel SkyLake devices.
> > +
> > + There are 3 kinds of INT3472 ACPI device possible; two for devices
> > + designed for Windows (either with or without a physical tps68470
>
> I'd capitalize TPS, chip names are usually written in upper case, and
> driver names in lower case.
>
> > + PMIC) and one designed for Chrome OS.
...
> > +obj-$(CONFIG_INTEL_SKL_INT3472) += intel_skl_int3472.o
> > +intel_skl_int3472-objs := intel_skl_int3472_common.o \
> > + intel_skl_int3472_discrete.o \
> > + intel_skl_int3472_tps68470.o
Mix of TABs and spaces detected in above two lines!
...
> > +static const struct acpi_device_id int3472_device_id[] = {
> > + { "INT3472", 0 },
> > + { },
No comma for terminator entry.
> > +};
...
> > +static struct i2c_driver int3472_tps68470 = {
> > + .driver = {
> > + .name = "int3472-tps68470",
> > + .acpi_match_table = int3472_device_id,
> > + },
> > + .probe_new = skl_int3472_tps68470_probe,
> > +};
I'm not sure we want to have like this. If I'm not mistaken the I²C driver can
be separated without ACPI IDs (just having I²C IDs) and you may instantiate it
via i2c_new_client_device() or i2c_acpi_new_device() whichever suits better...
> > +module_init(skl_int3472_init);
> > +module_exit(skl_int3472_exit);
...and this will become simple module_platfom_driver().
...
> > +#define INT3472_REGULATOR(_NAME, _SUPPLY, _OPS) \
>
> Macro arguments don't need to be capitalized.
>
> > + (const struct regulator_desc) { \
> > + .name = _NAME, \
> > + .supply_name = _SUPPLY, \
> > + .id = 0, \
IIRC it will be 0 by standard rules.
> > + .type = REGULATOR_VOLTAGE, \
> > + .ops = _OPS, \
> > + .owner = THIS_MODULE, \
> > + }
> > +
> > +#define INT3472_GPIO_FUNCTION_REMAP(_PIN, _FUNCTION) \
> > + (const struct int3472_gpio_function_remap) { \
> > + .documented = _PIN, \
> > + .actual = _FUNCTION \
+ comma
> > + }
...
> > +struct int3472_gpio_clock {
> > + struct clk *clk;
> > + struct clk_hw clk_hw;
> > + struct clk_lookup *cl;
> > + struct gpio_desc *gpio;
> > +};
Wondering if this has some similarities with and actually can utilize clk-gpio
driver.
...
> > + /* Lenovo Miix 510-12ISK - OV5648, Rear */
> > + { "GEFF150023R", REGULATOR_SUPPLY("avdd", "i2c-OVTI5648:00"), NULL},
> > + /* Surface Go 1&2 - OV5693, Front */
> > + { "YHCU", REGULATOR_SUPPLY("avdd", "i2c-INT33BE:00"), NULL},
I'm wondering if you should use same I2C format macro and create this
dynamically? Or rather find a corresponding ACPI device instance and copy it's
name?
...
> > +static const struct clk_ops skl_int3472_clock_ops = {
> > + .prepare = skl_int3472_clk_prepare,
> > + .unprepare = skl_int3472_clk_unprepare,
> > + .enable = skl_int3472_clk_enable,
> > + .disable = skl_int3472_clk_disable,
> > +};
Yeah, sounds like reinventing clk-gpio.c.
static const struct clk_ops clk_gpio_gate_ops = {
.enable = clk_gpio_gate_enable,
.disable = clk_gpio_gate_disable,
.is_enabled = clk_gpio_gate_is_enabled,
};
(Or is it mux? It has support there as well.
...
> > +static struct int3472_sensor_config *
> > +skl_int3472_get_sensor_module_config(struct int3472_device *int3472)
> > +{
> > + unsigned int i = ARRAY_SIZE(int3472_sensor_configs);
> > + struct int3472_sensor_config *ret;
> > + union acpi_object *obj;
> > +
> > + obj = acpi_evaluate_dsm_typed(int3472->sensor->handle,
> > + &cio2_sensor_module_guid, 0x00,
> > + 0x01, NULL, ACPI_TYPE_STRING);
> > +
> > + if (!obj) {
> > + dev_err(&int3472->pdev->dev,
> > + "Failed to get sensor module string from _DSM\n");
> > + return ERR_PTR(-ENODEV);
> > + }
> > +
> > + if (obj->string.type != ACPI_TYPE_STRING) {
> > + dev_err(&int3472->pdev->dev,
> > + "Sensor _DSM returned a non-string value\n");
> > + ret = ERR_PTR(-EINVAL);
> > + goto out_free_obj;
And after below change you can turn this to
ACPI_FREE(obj);
return ERR_PTR(-EINVAL);
and remove label completely, but it's up to you.
> > + }
> > + ret = ERR_PTR(-ENODEV);
This seems redundant. Or are you expecting ARRAY_SIZE() to be 0?
If no, you may add static_assert() near to the array definition.
> > + while (i--) {
>
> Unless there's a specific need to iterate backward over the array,
>
> for (i = 0; i < ARRAY_SIZE(int3472_sensor_configs); ++i) {
>
> > + if (!strcmp(int3472_sensor_configs[i].sensor_module_name,
> > + obj->string.pointer)) {
> > + ret = &int3472_sensor_configs[i];
>
> Just
>
> break;
>
> > + goto out_free_obj;
> > + }
> > + }
> > +
> > +out_free_obj:
> > + ACPI_FREE(obj);
> > + return ret;
> > +}
...
> > + sensor_config = skl_int3472_get_sensor_module_config(int3472);
> > + if (!IS_ERR(sensor_config) && sensor_config->function_maps) {
> > + unsigned int i = 0;
>
> const struct int3472_gpio_function_remap *remap =
> sensor_config->function_maps;
>
> for (; remap->documented; ++remap) {
Post-increment in for-loops will work fine (to all Laurent's examples :-).
> if (!strcmp(func, remap->documented)) {
> func = remap->actual;
>
> > +
> > + while (sensor_config->function_maps[i].documented) {
> > + if (!strcmp(func, sensor_config->function_maps[i].documented)) {
> > + func = sensor_config->function_maps[i].actual;
> > +
>
> Extra blank line.
>
> > + break;
> > + }
> > +
> > + i++;
> > + }
> > + }
...
> > + table_entry = (struct gpiod_lookup)GPIO_LOOKUP_IDX(acpi_dev_name(adev),
> > + ares->data.gpio.pin_table[0],
> > + func, 0, polarity);
Agree with below. But you nay change those GPIO_LOOKUP*() macros to be compound
literals in order to be used in the assignments like this.
> I wonder if
>
> table_entry.key = acpi_dev_name(adev);
> table_entry.chip_hwnum = ares->data.gpio.pin_table[0];
> table_entry.con_id = func;
> table_entry.idx = 0;
> table_entry.flags = polarity;
>
> (with struct gpiod_lookup table_entry = { }; above) would be more
> readable. Up to you.
>
> > +
> > + memcpy(&int3472->gpios.table[int3472->n_sensor_gpios], &table_entry,
> > + sizeof(table_entry));
>
> Ah, or maybe
>
> struct gpio_lookup *table_entry;
>
> table_entry = &int3472->gpios.table[int3472->n_sensor_gpios];
> table_entry->key = acpi_dev_name(adev);
> table_entry->chip_hwnum = ares->data.gpio.pin_table[0];
> table_entry->con_id = func;
> table_entry->idx = 0;
> table_entry->flags = polarity;
>
> (no need to memset() to 0 first as the whole structure has been
> allocated with kzalloc()).
...
> > + int3472->clock.cl = clkdev_create(int3472->clock.clk, "xvclk",
> > + int3472->sensor_name);
> > + if (IS_ERR_OR_NULL(int3472->clock.cl))
>
> if (!int3472->clock.cl)
>
> as the function never return an error pointer.
One more time, please consider to utilize clk-gpio.c.
...
> > + int3472->regulator.gpio = acpi_get_gpiod(path,
> > + ares->data.gpio.pin_table[0]);
> > + if (IS_ERR(int3472->regulator.gpio)) {
> > + dev_err(&int3472->pdev->dev, "Failed to get GPIO line\n");
>
> s/GPIO line/regulator GPIO lines/ ?
>
> > + return PTR_ERR(int3472->regulator.gpio);
> > + }
> > +
> > + cfg.dev = &int3472->adev->dev;
> > + cfg.init_data = &init_data;
> > + cfg.ena_gpiod = int3472->regulator.gpio;
> > +
> > + int3472->regulator.rdev = regulator_register(&int3472->regulator.rdesc,
> > + &cfg);
> > + if (IS_ERR(int3472->regulator.rdev)) {
> > + ret = PTR_ERR(int3472->regulator.rdev);
> > + goto err_free_gpio;
> > + }
Similar here, can we utilize gpio-regulator.c?
...
> > + return EINVAL; /* Deliberately positive so parsing continues */
>
> Maybe 1 instead of EINVAL ?
That's, i.e. 1, what we usually use in other ACPI related code like this.
...
> > + dev_warn(&int3472->pdev->dev,
Better to have struct device in the structure, you will put this on one line
and derive struct platform_device from it whenever it's required by
to_platform_device() call.
> > + "No _DSM entry for this GPIO pin\n");
>
> s/this GPIO pin/GPIO pin %u/
>
> (and add the corresponding argument).
...
> > + dev_warn(&int3472->pdev->dev,
> > + "GPIO type 0x%llx unknown; the sensor may not work\n",
> > + (obj->integer.value & 0xff));
>
> No need for parentheses.
And instead of "%llx" with " & 0xff" you may use "%x" with "(u8)" cast.
However, I don't think we need to show only last byte, because it may give
wrong impression on values like "0x100".
...
> > + ret = skl_int3472_get_cldb_buffer(adev, &cldb);
> > + if (ret || cldb.control_logic_type != 1)
>
> An error message is needed for unsupported control_logic_type values.
Yeah, please split checks to two.
> > + return -EINVAL;
...
> > + int3472 = kzalloc(sizeof(*int3472) +
> > + ((INT3472_MAX_SENSOR_GPIOS + 1) * sizeof(struct gpiod_lookup)),
>
> One more space for the indentation, and the outer parentheses are not
> needed.
And use struct_size() from overflow.h.
> > + GFP_KERNEL);
...
> > + if (int3472->gpios_mapped)
> > + gpiod_remove_lookup_table(&int3472->gpios);
>
> You could avoid the need for the gpios_mapped field by checking for
>
> if (int3472->gpios.list.next)
I think this is an intrusion to GPIO realm.
Instead would you consider to drop the check completely and use ->gpios to be
NULL / not-NULL (and yes, you won't need gpios_mapped flag)?
d321ad1286d2 ("gpiolib: Follow usual pattern for gpiod_remove_lookup_table() call")
in I²C tree makes it possible.
...
> > +static struct platform_device *
> > +skl_int3472_register_pdev(const char *name, struct device *parent)
> > +{
> > + struct platform_device *pdev;
> > + int ret;
> > +
> > + pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
> > + if (IS_ERR_OR_NULL(pdev))
> > + return ERR_PTR(-ENOMEM);
> > +
> > + pdev->dev.parent = parent;
> > + pdev->driver_override = kstrndup(pdev->name, INT3472_PDEV_MAX_NAME_LEN,
> > + GFP_KERNEL);
NULL check?
> > + ret = platform_device_add(pdev);
> > + if (ret) {
> > + platform_device_put(pdev);
> > + return ERR_PTR(ret);
> > + }
> > +
> > + return pdev;
> > +}
...
> > +int skl_int3472_tps68470_probe(struct i2c_client *client)
> > +{
> > + struct acpi_device *adev = ACPI_COMPANION(&client->dev);
> > + struct platform_device *regulator_dev;
> > + struct platform_device *opregion_dev;
> > + struct platform_device *gpio_dev;
> > + struct int3472_cldb cldb = { 0 };
> > + struct platform_device *clk_dev;
> > + bool cldb_present = true;
> > + struct regmap *regmap;
> > + int ret = 0;
Redundant assignment.
> > + regmap = devm_regmap_init_i2c(client, &tps68470_regmap_config);
> > + if (IS_ERR(regmap)) {
> > + dev_err(&client->dev, "devm_regmap_init_i2c Error %ld\n",
>
> s/Error/error/
>
> I'd actually write "Failed to create regmap" or something similar.
>
> > + PTR_ERR(regmap));
> > + return PTR_ERR(regmap);
> > + }
> > +
> > + i2c_set_clientdata(client, regmap);
> > +
> > + ret = tps68470_chip_init(&client->dev, regmap);
> > + if (ret < 0) {
> > + dev_err(&client->dev, "TPS68470 Init Error %d\n", ret);
>
> s/Init Error/init error/
>
> > + return ret;
> > + }
> > +
> > + /*
> > + * Check CLDB buffer against the PMIC's adev. If present, then we check
> > + * the value of control_logic_type field and follow one of the
> > + * following scenarios:
> > + *
> > + * 1. No CLDB - likely ACPI tables designed for ChromeOS. We
> > + * create platform devices for the GPIOs and OpRegion drivers.
> > + *
> > + * 2. CLDB, with control_logic_type = 2 - probably ACPI tables
> > + * made for Windows 2-in-1 platforms. Register pdevs for GPIO,
> > + * Clock and Regulator drivers to bind to.
> > + *
> > + * 3. Any other value in control_logic_type, we should never have
> > + * gotten to this point; crash and burn.
>
> Crash is a bit hard, and that's not what you do below.
>
> > + */
> > + ret = skl_int3472_get_cldb_buffer(adev, &cldb);
> > + if (!ret && cldb.control_logic_type != 2)
>
> You should print an error message here (at least to catch an unsupported
> control_logic_type value, skl_int3472_get_cldb_buffer() errors are
> already logged in that function).
>
> > + return -EINVAL;
> > +
> > + if (ret)
> > + cldb_present = false;
> > +
> > + gpio_dev = skl_int3472_register_pdev("tps68470-gpio", &client->dev);
> > + if (IS_ERR(gpio_dev))
> > + return PTR_ERR(gpio_dev);
> > +
> > + if (cldb_present) {
> > + clk_dev = skl_int3472_register_pdev("tps68470-clk",
> > + &client->dev);
> > + if (IS_ERR(clk_dev)) {
> > + ret = PTR_ERR(clk_dev);
> > + goto err_free_gpio;
> > + }
> > +
> > + regulator_dev = skl_int3472_register_pdev("tps68470-regulator",
> > + &client->dev);
> > + if (IS_ERR(regulator_dev)) {
> > + ret = PTR_ERR(regulator_dev);
> > + goto err_free_clk;
> > + }
> > + } else {
> > + opregion_dev = skl_int3472_register_pdev("tps68470_pmic_opregion",
> > + &client->dev);
> > + if (IS_ERR(opregion_dev)) {
> > + ret = PTR_ERR(opregion_dev);
> > + goto err_free_gpio;
> > + }
> > + }
>
> I wonder if this could be simplified by using devm_mfd_add_devices. You
> could have two arrays of mfd_cell, one for each case.
Yeah, which effectively means that we should have some kind of mfd/tps68470 in
place.
> > + return 0;
> > +
> > +err_free_clk:
> > + platform_device_put(clk_dev);
> > +err_free_gpio:
> > + platform_device_put(gpio_dev);
> > +
> > + return ret;
> > +}
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists