| 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
| ||
|
Message-ID: <20240314082842.GA6963@tpx1.home>
Date: Thu, 14 Mar 2024 09:28:42 +0100
From: Kamel Bouhara <kamel.bouhara@...tlin.com>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Henrik Rydberg <rydberg@...math.org>, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
Jeff LaBundy <jeff@...undy.com>,
catalin.popescu@...ca-geosystems.com,
mark.satterthwaite@...chnetix.com,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Gregory Clement <gregory.clement@...tlin.com>,
bsp-development.geo@...ca-geosystems.com
Subject: Re: [PATCH v9 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
Le Wed, Mar 13, 2024 at 09:21:35PM +0100, Marco Felsch a écrit :
> Hi Kamel,
>
Hi Marco,
> please see below, be aware that this is just an rough review.
>
[...]
> > +
> > +static int axiom_i2c_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + struct input_dev *input_dev;
> > + struct axiom_data *ts;
> > + u32 poll_interval;
> > + int target;
> > + int error;
> > +
> > + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
> > + if (!ts)
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(client, ts);
> > + ts->client = client;
> > + ts->dev = dev;
> > +
> > + ts->regmap = devm_regmap_init_i2c(client, &axiom_i2c_regmap_config);
> > + error = PTR_ERR_OR_ZERO(ts->regmap);
> > + if (error) {
> > + dev_err(dev, "Failed to initialize regmap: %d\n", error);
> > + return error;
> > + }
> > +
> > + ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(ts->reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(ts->reset_gpio), "failed to get reset GPIO\n");
> > +
> > + if (ts->reset_gpio)
> > + axiom_reset(ts->reset_gpio);
>
> This seems useless, since you doing an reset without enabling the power
> supply (below). I know there are systems which do have the supply always
> connected or for ACPI the supply is managed via firmware, but the driver
> should implement the correct logic and for DT/OF case this is not
> correct.
>
Alright, this can be moved after enabling vdda regulator as this is
still required in the power sequence.
> > +
> > + ts->vddi = devm_regulator_get_optional(dev, "vddi");
> > + if (!IS_ERR(ts->vddi)) {
> > + error = devm_regulator_get_enable(dev, "vddi");
>
> Regulators are ref counted and now you request the regulator twice. Also
> the regulator is not optional, it is required for the device to work.
> Same applies to the vdda below.
>
Ack, I wrongly took my use case (ACPI + fixed regulators) but this isn't
a common use case.
> > + if (error)
> > + return dev_err_probe(&client->dev, error,
> > + "Failed to enable vddi regulator\n");
> > + }
> > +
> > + ts->vdda = devm_regulator_get_optional(dev, "vdda");
> > + if (!IS_ERR(ts->vdda)) {
> > + error = devm_regulator_get_enable(dev, "vdda");
> > + if (error)
> > + return dev_err_probe(&client->dev, error,
> > + "Failed to enable vdda regulator\n");
> > + msleep(AXIOM_STARTUP_TIME_MS);
> > + }
> > +
> > + error = axiom_discover(ts);
> > + if (error)
> > + return dev_err_probe(dev, error, "Failed touchscreen discover\n");
> > +
> > + input_dev = devm_input_allocate_device(ts->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + input_dev->name = "TouchNetix axiom Touchscreen";
> > + input_dev->phys = "input/axiom_ts";
> > +
> > + input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 65535, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 65535, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_MAX, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_DISTANCE, 0, 127, 0, 0);
> > + input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 127, 0, 0);
> > +
> > + touchscreen_parse_properties(input_dev, true, &ts->prop);
> > +
> > + /* Registers the axiom device as a touchscreen instead of a mouse pointer */
> > + error = input_mt_init_slots(input_dev, AXIOM_U41_MAX_TARGETS, INPUT_MT_DIRECT);
> > + if (error)
> > + return error;
> > +
> > + /* Enables the raw data for up to 4 force channels to be sent to the input subsystem */
> > + set_bit(EV_REL, input_dev->evbit);
> > + set_bit(EV_MSC, input_dev->evbit);
> > + /* Declare that we support "RAW" Miscellaneous events */
> > + set_bit(MSC_RAW, input_dev->mscbit);
> > +
> > + ts->input_dev = input_dev;
> > + input_set_drvdata(ts->input_dev, ts);
> > +
> > + /* Ensure that all reports are initialised to not be present. */
> > + for (target = 0; target < AXIOM_U41_MAX_TARGETS; target++)
> > + ts->targets[target].state = AXIOM_TARGET_STATE_NOT_PRESENT;
> > +
> > + error = devm_request_threaded_irq(dev, client->irq, NULL,
> > + axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
> > + if (error) {
> > + dev_info(dev, "Request irq failed, falling back to polling mode");
> > +
> > + error = input_setup_polling(input_dev, axiom_i2c_poll);
> > + if (error)
> > + return dev_err_probe(ts->dev, error, "Unable to set up polling mode\n");
> > +
> > + if (!device_property_read_u32(ts->dev, "poll-interval", &poll_interval))
>
> This is not wrong but can we move the "poll-intervall" parsing into
> touchscreen_parse_properties() since it seems pretty common to me.
Maybe too late to add it in this series :).
>
> > + input_set_poll_interval(input_dev, poll_interval);
> > + else
> > + input_set_poll_interval(input_dev, POLL_INTERVAL_DEFAULT_MS);
> > + }
> > +
> > + error = input_register_device(input_dev);
> > + if (error)
> > + return dev_err_probe(ts->dev, error,
> > + "Could not register with Input Sub-system.\n");
>
> return input_register_device(input_dev);
Ack, thanks.
>
> > +
> > + return 0;
> > +}
> > +
> > +static const struct i2c_device_id axiom_i2c_id_table[] = {
> > + { "ax54a" },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(i2c, axiom_i2c_id_table);
>
> Do we really need an i2c-id table here? Most platforms do either use OF
> or ACPI.
If not wrong this is used to enumarate the device from userspace
and in my case it is required as there is no direct i2c controller
exposed from ACPI pov.
Thanks !
--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists