From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 456DC32ED42 for ; Mon, 5 Jan 2026 10:55:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767610557; cv=none; b=uL1qZ/vMuhWogSDDfeqvG5wXIPCuDVK4q+PW+HfnNDL7jassxx125mkn6I2MjyQQ2szxxIi4uKs5i2RyfbUwg6lorQH52VUrga8dzUBbBhGzWVA3JpgJjBDeEs96dbWsNpogwEgO8b5GWdu34uKZOzUxx+fZwMTTXt7lUmggxjA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767610557; c=relaxed/simple; bh=gwAM3gYozmj68G3BkMYx4yPS500ChdCcsRj5wEpBaOM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EKEHLm86buUZJEMrsLrCw0CXF3dAhEyWROGv/X0KhGsSjvfoycQ3Oor9R0KFIBma88gv/yQ6eqYg9VrVJNGOtLciQqMaadBg6ylW8MPOhDCjm464R2/cQ3inOUePyRSdRIa1ON+RTF2caKTE+o3ig2pGlm1s6Xcdn0IyKZ7Cmvc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=kPaJmSLr; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="kPaJmSLr" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-47bdbc90dcaso88994265e9.1 for ; Mon, 05 Jan 2026 02:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1767610554; x=1768215354; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=JnIbT9EGamTtHAub2XVlZI7RjkEaaQIsimhhYGKZi4M=; b=kPaJmSLrheOj5Iku9kftAyjUtf9BIpLLuLEeijhDt9TIujariUoxdZ15vsa82Zbg/+ YfLlQQOwZtAU5P4eJnddD9OYqDR0e5ovONUFpvlFsqBuA+C+ABwwkQMoFLxYdmx/gbGv htFtIz4WBDEgntI/0/9G/H3S6/EazJi0H/GKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767610554; x=1768215354; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JnIbT9EGamTtHAub2XVlZI7RjkEaaQIsimhhYGKZi4M=; b=bZuVKsyVtlszDx7TKrnd5L6JekaPbCYx+NBU9KLvChfqSyBHza9NJmaPrifehvT73Z eM9eAH4ziFpnLyL5gDwuXq/5/wB1RJEc+alExpWrMYsS2k1t108AN+ZTaANU87wf74IM 7OlkVzyDVamQhkqqmQteJc3Q4XHRq8NjbkKBSoPVdrpFJaluDWRsK4Wxo4qZw9QpMpzo VtkBSa8DC8iUt7iHjFAxo4OdBTTw3PNoL6DD8y6DFDvbZv2O2h5wE9eyQXKRtk/nj4KA RwQ4BGsGtyZIULKcMD/LSHLDoDXs6Zk9aeAQmBcoiTGuN4HLNZdCjN4rzOu4BvVF+fmU NGNg== X-Forwarded-Encrypted: i=1; AJvYcCW69pSwpQTsiBdJfDOJ3d3bEy8RgWSmkakYD8B+ZHWgGLXRSzWLDwc+ziwUiCb8nUtE5pMq0zkkyqap@vger.kernel.org X-Gm-Message-State: AOJu0YyYSz+ai3wr4BdYCO+rz3zoaJMyBD7hH59rFkxW4GZshSMePCVm 6BX0QLyNS22J/1LZoJhLwk3fRyyzTkvl9A1PS5FexTcsupLEhvkFse5rFmTHuHP//w== X-Gm-Gg: AY/fxX5d6JRbeJySH03H7SebhZpU/+h/xpUC/iNApH/3dU5ry6e/ZS7VOc/AGgusRU/ rPTMM2S4QkOFRrWiuBfyH4l2I2axUKB0wVZ3jqDom6QF+2OGvq4C7MDaJ0dn3oGAUTagklU+XQi qQxwg0uFP6rIfwFJL8/dKT76OjI4pn12jM299wDKLZ8nO8JtziWQmv7mZHg5hywmS/3IQhLrAbr udR9BhBWFEofP1f1QqjdqszgF0a4Z6x/NhbIGcCDqksh+VI9NqB8bqeZanonhWFy7v0eGtZB0jW Vijd8mIWQ4xvWFWPr823/vbzydF45snkUEh0ytlLC8CwPrPKsRskVuUojQJ7wqYnttSQ3SycXOv 468MnXw3FuKM3SV9LdgYq/V7bdNlR8dWNkYBNfe7HMzZlOfLaIeHpvnYZ3GW9luh49PoUZDLBU/ LCd/7iaRjK3SRQaSiqBA== X-Google-Smtp-Source: AGHT+IFA865YiL/SGKYZvDw31gF6v3vjD/bgpQhTY+81CJ5vFnSIbiTZ9Gkdx9EH+BTrotYpNM83Zw== X-Received: by 2002:a05:600c:c1c8:10b0:47d:403c:e5a0 with SMTP id 5b1f17b1804b1-47d403ce6e0mr358741175e9.12.1767610553632; Mon, 05 Jan 2026 02:55:53 -0800 (PST) Received: from google.com ([37.228.206.31]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6da2425esm146867955e9.12.2026.01.05.02.55.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 02:55:53 -0800 (PST) Date: Mon, 5 Jan 2026 10:55:51 +0000 From: Fabio Baltieri To: Krzysztof Kozlowski Cc: Dmitry Torokhov , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Benson Leung , Guenter Roeck , Tzung-Bi Shih , Simon Glass , linux-input@vger.kernel.org, devicetree@vger.kernel.org, chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] dt-bindings: google,cros-ec-keyb: add has-fn-map prop Message-ID: References: <20251231143538.37483-1-fabiobaltieri@chromium.org> <20251231143538.37483-2-fabiobaltieri@chromium.org> <20260105-helpful-ocelot-of-eternity-6bb1ee@quoll> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260105-helpful-ocelot-of-eternity-6bb1ee@quoll> On Mon, Jan 05, 2026 at 08:52:56AM +0100, Krzysztof Kozlowski wrote: > On Wed, Dec 31, 2025 at 02:35:37PM +0000, Fabio Baltieri wrote: > > Add binding documentation for the has-fn-map property. > > > > Signed-off-by: Fabio Baltieri > > --- > > .../devicetree/bindings/input/google,cros-ec-keyb.yaml | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > index fefaaf46a240..fa24b1cbc788 100644 > > --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > @@ -44,6 +44,14 @@ properties: > > where the lower 16 bits are reserved. This property is specified only > > when the keyboard has a custom design for the top row keys. > > > > + google,has-fn-map: > > + description: | > > + The keymap has function key layer. This allows defining an extra set of > > + codes that are sent if a key is pressed while the KEY_FN is held pressed > > + as well. The function codes have to be defined in the linux,keymap > > + property with an offset of keypad,num-rows from the normal ones. > > + type: boolean > > You still did not answer to my previous question, why this is not > deducible from the key map (presence of KEY_FN in the map). The driver behaves differently with the fn layer is present, has to make extra space for the extra codes and enable the logic to use it. I can certainly detect it in runtime, would have to always allocate the extra space even if not needed and check not only that there is an FN key but if there's anything in the second half of the map. I'm not overly enthusiastic about it, it's a bit wasteful on memory (probably no big deal, half a kb of RAM I guess) and somewhat less defensive to misconfigurations and in general I don't like the new logic to be enabled magically, as a side effect. It'd be extra complexity for the sake of saving one boolean property, but sure if you think that's the way to go then I guess I can implement it that way.