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@xxxxxxxxxxxx> 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
