From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Chen-Yu Tsai <wenst@chromium.org>, Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Wolfram Sang <wsa@kernel.org>, Benson Leung <bleung@chromium.org>,
Tzung-Bi Shih <tzungbi@kernel.org>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
chrome-platform@lists.linux.dev, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Johan Hovold <johan@kernel.org>, Jiri Kosina <jikos@kernel.org>,
linux-i2c@vger.kernel.org
Subject: Re: [PATCH v6 09/12] i2c: of-prober: Add regulator support
Date: Wed, 11 Sep 2024 17:38:23 +0300 [thread overview]
Message-ID: <ZuGrX67LzMe9S6ce@smile.fi.intel.com> (raw)
In-Reply-To: <CAD=FV=U2yDGv74GQWRQuHN9sjdY5iThqpH-br-jYXMkV1cujEg@mail.gmail.com>
On Tue, Sep 10, 2024 at 05:30:07PM -0700, Doug Anderson wrote:
> On Thu, Sep 5, 2024 at 8:45 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
...
> > At least for the stuff that we have (touchscreens and trackpads) such
> > registers typically don't exist, unless it's an HID-over-I2C device,
> > in which case there's the standard HID descriptor at some address.
> > But, yeah, reading the HID descriptor was the use case I had in mind.
> >
> > At least for one Chromebooks it's a bit more tricky because that one
> > HID-over-I2C component shares the same address as a non-HID one. We
> > currently have different SKU IDs and thus different device trees for
> > them, but we could make the prober work with this. It just has be able
> > to tell if the component it's currently probing needs the special
> > prober and is it responding correctly. This bit I need to think about.
>
> I guess Mark Brown also thought that there wouldn't be some magic
> register, but my gut still tells me that most i2c devices have some
> way to confirm that they are what you expect even if it's not an
> official "vendor" or "version" register. Some type of predictable
> register at a predictable location that you could use, at least if you
> knew all of the options that someone might stuff.
"most" is way too optimistic to say, I believe that not even close to majority
of I²C target devices they are not reliably discoverable.
That's the downside of non-discoverable busses like I²C. Maybe I³C has
a mechanism for that, but I am not an expert, just wondering.
> For instance, in elan trackpads you can see elan_i2c_get_product_id().
> That just reads a location (ETP_I2C_UNIQUEID_CMD = 0x0101) that could
> theoretically be used to figure out (maybe in conjunction with other
> registers) that it's an elan trackpad instead of an i2c-hid one. You'd
> have to (of course) confirm that an i2c-hid device wouldn't somehow
> return back data from this read that made it look like an elan
> trackpad, but it feels like there ought to be some way to figure it
> out with a few i2c register reads.
>
> ...that being said, I guess my original assertion that you might be
> able to figure out with a simple register read was naive and you'd
> actually need a function (maybe as a callback) to figure this out.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-09-11 14:38 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 9:00 [PATCH v6 00/12] platform/chrome: Introduce DT hardware prober Chen-Yu Tsai
2024-09-04 9:00 ` [PATCH v6 01/12] of: dynamic: Add of_changeset_update_prop_string Chen-Yu Tsai
2024-09-04 9:00 ` [PATCH v6 02/12] of: base: Add for_each_child_of_node_with_prefix_scoped() Chen-Yu Tsai
2024-09-04 13:03 ` Andy Shevchenko
2024-09-04 13:43 ` Rob Herring
2024-09-04 9:00 ` [PATCH v6 03/12] regulator: Move OF-specific regulator lookup code to of_regulator.c Chen-Yu Tsai
2024-09-04 13:09 ` Andy Shevchenko
2024-09-04 13:14 ` Andy Shevchenko
2024-09-05 8:11 ` Chen-Yu Tsai
2024-09-05 8:29 ` Andy Shevchenko
2024-09-04 9:00 ` [PATCH v6 04/12] regulator: Split up _regulator_get() Chen-Yu Tsai
2024-09-04 9:00 ` [PATCH v6 05/12] regulator: Do pure DT regulator lookup in of_regulator_bulk_get_all() Chen-Yu Tsai
2024-09-04 13:13 ` Andy Shevchenko
2024-09-09 2:39 ` Chen-Yu Tsai
2024-09-04 9:00 ` [PATCH v6 06/12] gpiolib: Add gpio_get_property_name_length() Chen-Yu Tsai
2024-09-04 13:40 ` Andy Shevchenko
2024-09-09 2:45 ` Chen-Yu Tsai
2024-09-11 7:37 ` Chen-Yu Tsai
2024-09-11 14:39 ` Andy Shevchenko
2024-09-04 9:00 ` [PATCH v6 07/12] i2c: core: Remove extra space in Makefile Chen-Yu Tsai
2024-09-04 13:41 ` Andy Shevchenko
2024-09-04 9:00 ` [PATCH v6 08/12] i2c: Introduce OF component probe function Chen-Yu Tsai
2024-09-04 13:47 ` Andy Shevchenko
2024-09-09 3:02 ` Chen-Yu Tsai
2024-09-04 15:37 ` Rob Herring
2024-09-04 9:00 ` [PATCH v6 09/12] i2c: of-prober: Add regulator support Chen-Yu Tsai
2024-09-04 13:53 ` Andy Shevchenko
2024-09-04 22:57 ` Doug Anderson
2024-09-05 15:10 ` Chen-Yu Tsai
2024-09-05 18:14 ` Doug Anderson
2024-09-05 18:42 ` Mark Brown
2024-09-05 19:13 ` Andy Shevchenko
2024-09-06 3:45 ` Chen-Yu Tsai
2024-09-11 0:30 ` Doug Anderson
2024-09-11 6:12 ` Chen-Yu Tsai
2024-09-11 14:38 ` Andy Shevchenko [this message]
2024-09-11 14:49 ` Mark Brown
2024-09-04 9:00 ` [PATCH v6 10/12] i2c: of-prober: Add GPIO support Chen-Yu Tsai
2024-09-04 14:04 ` Andy Shevchenko
2024-09-04 9:00 ` [PATCH v6 11/12] platform/chrome: Introduce device tree hardware prober Chen-Yu Tsai
2024-09-04 10:08 ` Tzung-Bi Shih
2024-09-05 3:52 ` Chen-Yu Tsai
2024-09-05 4:34 ` Tzung-Bi Shih
2024-09-04 9:00 ` [PATCH v6 12/12] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail Chen-Yu Tsai
2024-09-04 17:19 ` (subset) [PATCH v6 00/12] platform/chrome: Introduce DT hardware prober Mark Brown
2024-09-07 16:58 ` Wolfram Sang
2024-09-09 3:24 ` Chen-Yu Tsai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZuGrX67LzMe9S6ce@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bleung@chromium.org \
--cc=broonie@kernel.org \
--cc=chrome-platform@lists.linux.dev \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=jikos@kernel.org \
--cc=johan@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=tzungbi@kernel.org \
--cc=wenst@chromium.org \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.