Hi, On Fri, Oct 30, 2020 at 9:47 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > On Fri, Oct 23, 2020 at 04:22:52PM -0700, Douglas Anderson wrote: > > As pointed out by Rob Herring [1], we should have a device-specific > > compatible string. This means people shouldn't be using the > > "i2c-over-hid" compatible string anymore, or at least not without a > > more specific compatible string before it. Specifically: > > > > 1. For newly added devices we should just have the device-specific > > device string (no "hid-over-i2c" fallback) and infer the timings > > and hid-descr-addr from there. > > I wouldn't go that far. Having a fallback is perfectly acceptible. And > hopefully there are at least some devices where that's good enough for > drivers to use. > > If we have cases of only 'i2c-over-hid' being used (in DT), then the > solution is making this a schema so we can enforce that as not valid. OK, fair enough. I think in the case of the Goodix touchscreen I'm trying to support, though, it's not useful to have the fallback since it really doesn't seem to work without all the delays. :( I sent my v3 without touching anything about "i2c-over-hid" as far as bindings goes. For my edification, though, when do you believe "i2c-over-hid" should be the fallback? Presumably you would advocate for "post-power-on-delay-ms" being marked as deprecated, right? That should have been inferred by the compatible string, right? So, in theory, anyone who needed this delay couldn't have ever taken advantage of the fallback, right? They wouldn't have worked without the delay? -Doug
