Re: [PATCH v2 1/3] dt-bindings: HID: i2c-hid: Label this binding as deprecated

From: Doug Anderson <dianders@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrea Borgia <andrea@borgia.bo.it>,
	Kai-Heng Feng <kai.heng.feng@canonical.com>,
	linux-input@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] dt-bindings: HID: i2c-hid: Label this binding as deprecated
Date: Mon, 2 Nov 2020 16:16:04 -0800	[thread overview]
Message-ID: <CAD=FV=UoDUVyUakJGL=Pmedjj7DFexbi=WHeEkkD9XNhay64JQ@mail.gmail.com> (raw)
In-Reply-To: <20201030164743.GA3967106@bogus>

Hi,

On Fri, Oct 30, 2020 at 9:47 AM Rob Herring <robh@kernel.org> 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