chrome-platform.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Doug Anderson <dianders@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	patches@lists.linux.dev,  chrome-platform@lists.linux.dev,
	Krzysztof Kozlowski <krzk@kernel.org>,
	 Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org,  Benson Leung <bleung@chromium.org>,
	Guenter Roeck <groeck@chromium.org>,
	 Hsin-Yi Wang <hsinyi@chromium.org>,
	"Joseph S. Barrera III" <joebar@chromium.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: google,cros-ec-keyb: Introduce switches only compatible
Date: Mon, 2 May 2022 13:41:33 -0700	[thread overview]
Message-ID: <CAE-0n50Y8tZD9Djn9TVaAiHxehFJ2cZKZ1Z09piDk47uw3nK+Q@mail.gmail.com> (raw)
In-Reply-To: <CAKdAkRSOtAD6u_cwKhHeMLgz5dC2hfPvVvqmj+17b4i-nspfgg@mail.gmail.com>

Quoting Dmitry Torokhov (2022-05-02 10:43:06)
> On Mon, May 2, 2022 at 10:00 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > That goes against the recently landed commit 4352e23a7ff2 ("Input:
> > cros-ec-keyb - only register keyboard if rows/columns exist") but
> > perhaps we should just _undo_ that that since it landed pretty
> > recently and say that the truly supported way to specify that you only
> > have keyboards/switches is with the compatible.
> >
> > What do you think?
>
> I am sorry, I am still confused on what exactly we are trying to solve
> here? Having a device with the new device tree somehow run an older
> kernel and fail? Why exactly do we care about this case?

Yes, we're trying to solve the problem where a new device tree is used
with an older kernel because it doesn't have the driver patch to only
create an input device for the matrix when rows/columns properties are
present. Otherwise applying that devicetree patch to an older kernel
will break bisection.

> We have
> implemented the notion that without rows/columns properties we will
> not be creating input device for the matrix portion, all older devices
> should have it defined, so the newer driver is compatible with them...
>

Agreed, that solves half the problem. This new compatible eases
integration so that devicetrees can say they're compatible with the old
binding that _requires_ the rows/column properties. By making the driver
change we loosened that requirement, but the binding should have been
making the properties required at the start because it fails to bind
otherwise.

My interpretation of what Doug is saying is that we should maintain that
requirement that rows/columns exists if the original compatible
google,cros-ec-keyb is present and use the new compatible to indicate
that there are switches. Combining the two compatibles means there's
switches and a matrix keyboard, having only the switches compatible
means only switches, and having only the keyboard compatible means only
matrix keyboard.

It sounds OK to me.

  reply	other threads:[~2022-05-02 20:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 23:31 [PATCH v2 0/2] Input: cros-ec-keyb: Better matrixless support Stephen Boyd
2022-04-29 23:31 ` [PATCH v2 1/2] dt-bindings: google,cros-ec-keyb: Introduce switches only compatible Stephen Boyd
2022-05-02 17:00   ` Doug Anderson
2022-05-02 17:43     ` Dmitry Torokhov
2022-05-02 20:41       ` Stephen Boyd [this message]
2022-05-02 23:49         ` Stephen Boyd
2022-05-03  1:09         ` Doug Anderson
2022-05-12 10:22         ` Dmitry Torokhov
2022-05-12 18:58           ` Stephen Boyd
2022-05-12 20:11             ` Stephen Boyd
2022-05-12 23:31               ` Dmitry Torokhov
2022-05-12 23:46                 ` Stephen Boyd
2022-05-12 23:53                   ` Stephen Boyd
2022-05-13 19:07                     ` Dmitry Torokhov
2022-04-29 23:31 ` [PATCH v2 2/2] Input: cros-ec-keyb - skip keyboard registration for switches compatible Stephen Boyd
2022-05-02 17:02   ` Doug Anderson
2022-05-02 22:02     ` Stephen Boyd
2022-05-03  1:06       ` Doug Anderson
2022-05-03  2:18         ` Stephen Boyd

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=CAE-0n50Y8tZD9Djn9TVaAiHxehFJ2cZKZ1Z09piDk47uw3nK+Q@mail.gmail.com \
    --to=swboyd@chromium.org \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=groeck@chromium.org \
    --cc=hsinyi@chromium.org \
    --cc=joebar@chromium.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=robh+dt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).