On Thu, Oct 10, 2024 at 11:29 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Tue, Oct 08, 2024 at 03:34:26PM +0800, Chen-Yu Tsai wrote:
> > Some devices are designed and manufactured with some components having
> > multiple drop-in replacement options. These components are often
> > connected to the mainboard via ribbon cables, having the same signals
> > and pin assignments across all options. These may include the display
> > panel and touchscreen on laptops and tablets, and the trackpad on
> > laptops. Sometimes which component option is used in a particular device
> > can be detected by some firmware provided identifier, other times that
> > information is not available, and the kernel has to try to probe each
> > device.
> >
> > This change attempts to make the "probe each device" case cleaner. The
> > current approach is to have all options added and enabled in the device
> > tree. The kernel would then bind each device and run each driver's probe
> > function. This works, but has been broken before due to the introduction
> > of asynchronous probing, causing multiple instances requesting "shared"
> > resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
> > time, with only one instance succeeding. Work arounds for these include
> > moving the pinmux to the parent I2C controller, using GPIO hogs or
> > pinmux settings to keep the GPIO pins in some fixed configuration, and
> > requesting the interrupt line very late. Such configurations can be seen
> > on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
> > Lenovo Thinkpad 13S.
> >
> > Instead of this delicate dance between drivers and device tree quirks,
> > this change introduces a simple I2C component prober. For any given
> > class of devices on the same I2C bus, it will go through all of them,
> > doing a simple I2C read transfer and see which one of them responds.
> > It will then enable the device that responds.
> >
> > This requires some minor modifications in the existing device tree.
> > The status for all the device nodes for the component options must be
> > set to "fail-needs-probe". This makes it clear that some mechanism is
> > needed to enable one of them, and also prevents the prober and device
> > drivers running at the same time.
>
> ...
>
> > +#include <linux/array_size.h>
> > +#include <linux/errno.h>
> > +#include <linux/i2c-of-prober.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
>
> > +static int chromeos_i2c_component_prober(struct device *dev, const void *_data)
> > +{
> > + const struct chromeos_i2c_probe_data *data = _data;
> > + struct i2c_of_probe_simple_ctx ctx = {
> > + .opts = data->opts
>
> Leave trailing comma in such cases (when it's not a terminator and
> not on the same line with the variable definition).
Ack.
> > + };
> > +
> > + return i2c_of_probe_component(dev, data->cfg, &ctx);
> > +}
> > +
> > +static const struct chromeos_i2c_probe_data chromeos_i2c_probe_dumb_touchscreen = {
> > + .cfg = &(const struct i2c_of_probe_cfg) {
>
> Perhaps you can introduce something like
>
> #define DEFINE_I2C_OF_PROBE_CFG(_type_, _ops_) \
> (struct ...) { \
> .ops = _ops_, \
> .type = #_type_, \
> }
>
> and use it here as
>
> .cfg = DEFINE_I2C_OF_PROBE_CFG(touchscreen, NULL),
Overall reply about the compound literals is in my other email.
> > + .type = "touchscreen"
>
> Ditto.
Ack.
>
> > + }
>
> Ditto.
>
> > +};
> > +
> > +static const struct i2c_of_probe_cfg chromeos_i2c_probe_simple_trackpad_cfg = {
> > + .ops = &i2c_of_probe_simple_ops,
> > + .type = "trackpad"
>
> Leave a comma.
Ack.
> > +};
>
> ...
>
> > +static const struct chromeos_i2c_probe_data chromeos_i2c_probe_hana_trackpad = {
> > + .cfg = &chromeos_i2c_probe_simple_trackpad_cfg,
>
> .cfg = DEFINE_I2C_OF_PROBE_CFG(trackpad, i2c_of_probe_simple_ops),
>
> Or even
>
> #define DEFINE_I2C_OF_PROBE_CFG_SIMPLE(_type_) \
> DEFINE_I2C_OF_PROBE_CFG(type, &i2c_of_probe_simple_ops)
>
> > + .opts = &(const struct i2c_of_probe_simple_opts) {
>
> Perhaps also DEFINE_xxx for this compound literal?
I think it's better to leave this one as is. Not every entry will
use the same combination of parameters. And having the entry spelled
out like this makes it easier to read which value is for what
parameter, instead of having to go up to the macro definition.
For comparison, this entry uses just two of the parameters, while for
another platform I'm working on the full set of parameters is needed.
> > + .res_node_compatible = "elan,ekth3000",
> > + .supply_name = "vcc",
> > + /*
> > + * ELAN trackpad needs 2 ms for H/W init and 100 ms for F/W init.
> > + * Synaptics trackpad needs 100 ms.
> > + * However, the regulator is set to "always-on", presumably to
> > + * avoid this delay. The ELAN driver is also missing delays.
> > + */
> > + .post_power_on_delay_ms = 0,
> > + }
> > +};
> > +
> > +static const struct hw_prober_entry hw_prober_platforms[] = {
> > + { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_dumb_touchscreen },
> > + { .compatible = "google,hana", .prober = chromeos_i2c_component_prober, .data = &chromeos_i2c_probe_hana_trackpad },
>
> These strings are a bit long, perhaps wrap on one member per line?
Sure.
ChenYu
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
