Quoting Doug Anderson (2022-04-27 08:09:59) > Hi, > > On Tue, Apr 26, 2022 at 5:17 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Tue, Apr 26, 2022 at 3:57 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > > > > > Trogdor devices that have a detachable keyboard still have a > > > non-detachable keyboard input device present because we include the > > > cros-ec-keyboard.dtsi snippet in the top-level sc7180-trogdor.dtsi file > > > that every variant board includes. We do this because the > > > keyboard-controller node also provides some buttons like the power > > > button and volume buttons. Unfortunately, this means we register a > > > keyboard input device that doesn't do anything on boards with a > > > detachable keyboard. Let's delete the rows/columns properties of the > > > device node to indicate that there isn't a matrix keyboard on these > > > boards. > > > > > > Cc: Benson Leung <bleung@xxxxxxxxxxxx> > > > Cc: Guenter Roeck <groeck@xxxxxxxxxxxx> > > > Cc: Douglas Anderson <dianders@xxxxxxxxxxxx> > > > Cc: Hsin-Yi Wang <hsinyi@xxxxxxxxxxxx> > > > Cc: "Joseph S. Barrera III" <joebar@xxxxxxxxxxxx> > > > Signed-off-by: Stephen Boyd <swboyd@xxxxxxxxxxxx> > > > --- > > > arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 5 +++++ > > > arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi | 5 +++++ > > > 2 files changed, 10 insertions(+) > > > > Presumably we need to do this same thing for wormdingler [1] > > > > [1] https://lore.kernel.org/r/20220426151204.1.Id2821de5fde55ebe928e8fc87a71c8d535edb383@changeid > > > > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > > Do we need to delay landing this patch for a release? I haven't tested > myself, but from re-reading through the code it looks as if > cros_ec_keyb_register_matrix() will return an error code if we have > the device tree patch _without_ commit 4352e23a7ff2 ("Input: > cros-ec-keyb - only register keyboard if rows/columns exist"). That > will cause it to skip registering the buttons/switches, right? Yes, if the driver patch isn't applied then we'll skip registering switches when these properties are removed. I suppose a better way to gracefully migrate the logic here would be to add another compatible string. Then we could make the compatible be compatible = "google,cros-ec-keyb-switches", "google,cros-ec-keyb"; on detachables and the driver can skip registering the keyboard if the more specific "google,cros-ec-keyb-switches" compatible is present. The driver will continue to probe and we don't have to remove any properties. The driver patch has been accepted[1] so in theory this patch can be applied and when the two meet up in linux-next things will work but when bisecting down the DTS the switches won't work. Not a huge problem but sort of annoying that the switches are busted. [1] https://lore.kernel.org/all/Ymh1J9zQ+5EyQadE@xxxxxxxxxx/
