From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C420C3FF4 for ; Thu, 12 May 2022 23:46:23 +0000 (UTC) Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-deb9295679so8627315fac.6 for ; Thu, 12 May 2022 16:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=CCXk4aGiQyCTAljD0WBKOYV+IYE8EXr1rYTSu6VFgtI=; b=FFyemYPiqGMWq2J42zvVIy56OVbEqIuNlxuncSVPaNxNIIJ5ZycERdzKRulHFGsJEr oumADnP6plIx6csRjg0toODmGtxNF15v1tIvtE34hTfIWKIZI4lQPYRCfz+j1TgnixOx LQc4iQyXWPoOM+4Sw9q+M3yt1yefAvrCDz8Gs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=CCXk4aGiQyCTAljD0WBKOYV+IYE8EXr1rYTSu6VFgtI=; b=CAxQP/8iR5i/yG3obf0DKX+Po/sAVaeEpLyDH6dB/FXkUlB2wCQoneGPZGZmYx+wqr jR3QQ8/3bzbjPJ44WUAvOdB+Zx/FJGQcnGKovgnTx1euM1tpkGjq7YObQRX8cB76pqqt wE43jUcD20VG4llmZGX0YnDzLDGQzTQNjW975enEbrj+tPT/FBasmFyMWgo/dRpvfQWt wAdRPpCrZT/wrYYVea76+84KnH93k0ms2zPoAeP0oacd5+BgZWblDCX+I38nWghZXlod 9BQfm7q4guCIVY2u5WDAmhSTSUndppRgoZ+wBqfEsDyH/3BN7wQy5DsRIdvsHfR+7VjP IlZw== X-Gm-Message-State: AOAM5311wG2ExQ1cMjMVwwJvAvtPjF51P6uK0l4G814a8ZEEVHuzLn4P SqmxzC+T06wW/1FSgrSnjwDOqQ7fE2sAEAKPzQ0LmA== X-Google-Smtp-Source: ABdhPJx6v0KgMb/jRnx6/Krbb322vnBPBMhicMUGbwrtS2/aRy1hFLrReMk71FzK8VJf5Kfd6+nfPastJffMlxFFYcA= X-Received: by 2002:a05:6870:558e:b0:e1:db7c:26aa with SMTP id n14-20020a056870558e00b000e1db7c26aamr1255109oao.63.1652399182819; Thu, 12 May 2022 16:46:22 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 May 2022 16:46:22 -0700 Precedence: bulk X-Mailing-List: chrome-platform@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: References: <20220429233112.2851665-1-swboyd@chromium.org> <20220429233112.2851665-2-swboyd@chromium.org> From: Stephen Boyd User-Agent: alot/0.10 Date: Thu, 12 May 2022 16:46:22 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] dt-bindings: google,cros-ec-keyb: Introduce switches only compatible To: Dmitry Torokhov Cc: Doug Anderson , LKML , patches@lists.linux.dev, chrome-platform@lists.linux.dev, Krzysztof Kozlowski , Rob Herring , devicetree@vger.kernel.org, Benson Leung , Guenter Roeck , Hsin-Yi Wang , "Joseph S. Barrera III" Content-Type: text/plain; charset="UTF-8" Quoting Dmitry Torokhov (2022-05-12 16:31:08) > On Thu, May 12, 2022 at 01:11:39PM -0700, Stephen Boyd wrote: > > Quoting Stephen Boyd (2022-05-12 11:58:02) > > > Quoting Dmitry Torokhov (2022-05-12 03:22:30) > > > > > > > > Have we solved module loading in the presence of multiple compatibles? > > > > IIRC we only ever try to load module on the first compatible, so you'd > > > > be breaking autoloading cros-ec-keyb on these older kernels. I think the > > > > cure that is being proposed is worse than the disease. > > > > > > > > > > The first compatible is still cros-ec-keyb in the driver though? Or you > > > mean the first compatible in the node? I'm not aware of this problem at > > > all but I can certainly test out a fake node and module and see if it > > > gets autoloaded. > > > > I can't get this test module to fail to load no matter what I do. I > > commented out the second match table entry, and kept it there and > > removed 'vendor,switch-compat' from the DTS. Module still autoloads. > > > > Ah, indeed, if the module contains both compatibles we will load it. It > is broken when we have 2 or more modules and DT lists several > compatibles for a device. > > OK, it looks like you feel very strongly regarding having a dedicated > compatible. In this case please make sure that the compatible's behavior > is properly documented (i.e. google,cros-ec-keyb compatible does not > imply that there are *NO* switches, and users having buttons and > switches in addition to matrix keys can also use google,cros-ec-keyb as > a compatible for their device). We also need to mention that with the > 2nd compatible the device still can report key/button events, it is > simply that there is no matrix component. Should we call the other > compatible google,cros-ec-bs? ;) I think I covered that in v3 of this series[1]. > > We should also abort binding the device if it specifies the new > compatible, but EC does not report any buttons or switches. Sure. I don't have that done in v3 so I can respin the patch series to fail probe if there aren't any switches and the cros-ec-keyb-switches compatible is present. Can you take a quick glance at v3 and let me know if anything else is needed? [1] https://lore.kernel.org/all/20220503042242.3597561-1-swboyd@chromium.org/