On Sat, Sep 14, 2024 at 1:43 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> On Wed, Sep 11, 2024 at 12:29 AM Chen-Yu Tsai <wenst@xxxxxxxxxxxx> wrote:
> >
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_CHROMEOS_ACPI) += chromeos_acpi.o
> > obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> > obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN) += chromeos_privacy_screen.o
> > obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> > +obj-$(CONFIG_CHROMEOS_OF_HW_PROBER) += chromeos_of_hw_prober.o
>
> "o" sorts before "p" so "of" should sort before "privacy"?
>
> I guess it's not exactly all sorted, but this small section is. Since
> it's arbitrary you could preserve the existing sorting. :-P
To me it seemed more like they are just sorted in the order they were
added.
> > +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_dumb_trackpad },
>
> The fact that the example is only using "dumb" probers doesn't make it
> quite as a compelling proof that the code will scale up. Any chance
> you could add something that requires a bit more oomph? ;-)
I only have a hacked up thing right now.
This is the one I'm using to test things:
http://git.kernel.org/wens/c/5c2c920429167a15b990a7cf8427705eec321134
About this one, it seems we can at least merge the device trees of
each product into just one. The touchscreen or trackpad (or lack thereof)
is probed by the kernel.
This one I only started looking into:
http://git.kernel.org/wens/c/42c21929aeb3c7ca7b0ce9cacb1d0ff915d3c783
About the second one, AFAIK the device tree descriptions are incomplete.
Only one of the trackpad options has the regulator supply described.
The regulator itself is marked as always on, so things currently work.
Some work will need to be put in to research the schematics and test
whether things do work correctly.
> > +static int chromeos_of_hw_prober_driver_init(void)
> > +{
> > + size_t i;
> > + int ret;
> > +
> > + for (i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
> > + if (of_machine_is_compatible(hw_prober_platforms[i].compatible))
> > + break;
> > + if (i == ARRAY_SIZE(hw_prober_platforms))
> > + return -ENODEV;
> > +
> > + ret = platform_driver_register(&chromeos_of_hw_prober_driver);
> > + if (ret)
> > + return ret;
> > +
> > + chromeos_of_hw_prober_pdev =
> > + platform_device_register_simple(DRV_NAME, PLATFORM_DEVID_NONE, NULL, 0);
> > + if (IS_ERR(chromeos_of_hw_prober_pdev))
> > + goto err;
>
> FWIW if you didn't want to see your prober called over and over again
> if one of the devices deferred you could just register one device per
> type, right? Then each device would be able to defer separately. Dunno
> if it's worth it but figured I'd mention it...
I think that adds some unnecessary complexity, and more lingering devices
in the system. These platform devices are not removed.
> Also: as a high level comment, this all looks much nicer to me now
> that it's parameterized. :-)
Thanks!
ChenYu
