lkml.org 
[lkml]   [2021]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@gmail.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


    \
     
     \ /
      Last update: 2021-01-18 15:48    [W:3.527 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site