All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Dragan Simic <dsimic@manjaro.org>
Cc: alexandre.belloni@bootlin.com, conor+dt@kernel.org,
	devicetree@vger.kernel.org, dmitry.torokhov@gmail.com,
	heiko@sntech.de, kernel@collabora.com, krzk+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rockchip@lists.infradead.org, robh@kernel.org
Subject: Re: [PATCH 2/4] Input: adc-keys - support types that aren't just keyboard keys
Date: Mon, 15 Dec 2025 12:10:21 +0100	[thread overview]
Message-ID: <2411362.ElGaqSPkdT@workhorse> (raw)
In-Reply-To: <20251028213209.2646838-1-dsimic@manjaro.org>

On Tuesday, 28 October 2025 22:32:09 Central European Standard Time Dragan Simic wrote:
> Hello Nicolas,
> 
> On Monday, June 30, 2025, 12:19:24 Nicolas Frattaroli wrote:
> > Instead of doing something like what gpio-keys is doing, adc-keys
> > hardcodes that all keycodes must be of type EV_KEY.
> > 
> > This limits the usefulness of adc-keys, and overcomplicates the code
> > with manual bit-setting logic.
> > 
> > Instead, refactor the code to read the linux,input-type fwnode property,
> > and get rid of the custom bit setting logic, replacing it with
> > input_set_capability instead. input_report_key is replaced with
> > input_event, which allows us to explicitly pass the type.
> 
> Thanks for this patch, it's indeed very useful!  Please see some
> comments below.
> 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >  drivers/input/keyboard/adc-keys.c | 16 ++++++++++++----
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> > index f1753207429db02ce6510e5ec0da9b24d9edb61d..339dd4d4a0842108da2c6136b1e0098cd1f6a3cd 100644
> > --- a/drivers/input/keyboard/adc-keys.c
> > +++ b/drivers/input/keyboard/adc-keys.c
> > @@ -19,12 +19,14 @@
> >  struct adc_keys_button {
> >  	u32 voltage;
> >  	u32 keycode;
> > +	u32 type;
> >  };
> >  
> >  struct adc_keys_state {
> >  	struct iio_channel *channel;
> >  	u32 num_keys;
> >  	u32 last_key;
> > +	u32 last_type;
> >  	u32 keyup_voltage;
> >  	const struct adc_keys_button *map;
> >  };
> > @@ -35,6 +37,7 @@ static void adc_keys_poll(struct input_dev *input)
> >  	int i, value, ret;
> >  	u32 diff, closest = 0xffffffff;
> >  	int keycode = 0;
> > +	u32 type = EV_KEY;
> >  
> >  	ret = iio_read_channel_processed(st->channel, &value);
> >  	if (unlikely(ret < 0)) {
> > @@ -46,6 +49,7 @@ static void adc_keys_poll(struct input_dev *input)
> >  			if (diff < closest) {
> >  				closest = diff;
> >  				keycode = st->map[i].keycode;
> > +				type = st->map[i].type;
> >  			}
> >  		}
> >  	}
> > @@ -54,13 +58,14 @@ static void adc_keys_poll(struct input_dev *input)
> >  		keycode = 0;
> >  
> >  	if (st->last_key && st->last_key != keycode)
> > -		input_report_key(input, st->last_key, 0);
> > +		input_event(input, st->last_type, st->last_key, 0);
> >  
> >  	if (keycode)
> > -		input_report_key(input, keycode, 1);
> > +		input_event(input, type, keycode, 1);
> 
> When EV_ABS is defined in the DT as the key type, which happens with
> joysticks and whatnot, separate handling is needed, by requiring the
> actual associated button values to be reported in the input_event()
> invocations, more specifically on the keypresses only.

Analogue control devices like joysticks are handled in adc-joystick.c.
adc-keys is specifically for resistor-ladder key devices. A driver or
binding for some absolute/relative positioning device that is not a
joystick should get its own binding first. Overloading the meaning
of the adc-keys binding and then adding functionality to the driver
is not the way to go.

I'll instead add code to only allow EV_KEY and EV_SW. Switches
function like keys for all intents and purposes, so they fit here.

> 
> That's also visible in the gpio_keys_gpio_report_event() function in
> drivers/input/keyboard/gpio_keys.c.
> 
> >  	input_sync(input);
> >  	st->last_key = keycode;
> > +	st->last_type = type;
> >  }
> >  
> >  static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> > @@ -93,6 +98,10 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> >  			return -EINVAL;
> >  		}
> >  
> > +		if (fwnode_property_read_u32(child, "linux,input-type",
> > +					     &map[i].type))
> > +			map[i].type = EV_KEY;
> 
> Going along with the remarks above, it will also be needed to read
> and record the values of "linux,input-value" DT properties here, and
> to extend the associated binding to define their presence.
> 
> >  		i++;
> >  	}
> >  
> > @@ -156,9 +165,8 @@ static int adc_keys_probe(struct platform_device *pdev)
> >  	input->id.product = 0x0001;
> >  	input->id.version = 0x0100;
> >  
> > -	__set_bit(EV_KEY, input->evbit);
> >  	for (i = 0; i < st->num_keys; i++)
> > -		__set_bit(st->map[i].keycode, input->keybit);
> > +		input_set_capability(input, st->map[i].type, st->map[i].keycode);
> >  
> >  	if (device_property_read_bool(dev, "autorepeat"))
> >  		__set_bit(EV_REP, input->evbit);
> 






WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Dragan Simic <dsimic@manjaro.org>
Cc: alexandre.belloni@bootlin.com, conor+dt@kernel.org,
	devicetree@vger.kernel.org, dmitry.torokhov@gmail.com,
	heiko@sntech.de, kernel@collabora.com, krzk+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rockchip@lists.infradead.org, robh@kernel.org
Subject: Re: [PATCH 2/4] Input: adc-keys - support types that aren't just keyboard keys
Date: Mon, 15 Dec 2025 12:10:21 +0100	[thread overview]
Message-ID: <2411362.ElGaqSPkdT@workhorse> (raw)
In-Reply-To: <20251028213209.2646838-1-dsimic@manjaro.org>

On Tuesday, 28 October 2025 22:32:09 Central European Standard Time Dragan Simic wrote:
> Hello Nicolas,
> 
> On Monday, June 30, 2025, 12:19:24 Nicolas Frattaroli wrote:
> > Instead of doing something like what gpio-keys is doing, adc-keys
> > hardcodes that all keycodes must be of type EV_KEY.
> > 
> > This limits the usefulness of adc-keys, and overcomplicates the code
> > with manual bit-setting logic.
> > 
> > Instead, refactor the code to read the linux,input-type fwnode property,
> > and get rid of the custom bit setting logic, replacing it with
> > input_set_capability instead. input_report_key is replaced with
> > input_event, which allows us to explicitly pass the type.
> 
> Thanks for this patch, it's indeed very useful!  Please see some
> comments below.
> 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >  drivers/input/keyboard/adc-keys.c | 16 ++++++++++++----
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> > index f1753207429db02ce6510e5ec0da9b24d9edb61d..339dd4d4a0842108da2c6136b1e0098cd1f6a3cd 100644
> > --- a/drivers/input/keyboard/adc-keys.c
> > +++ b/drivers/input/keyboard/adc-keys.c
> > @@ -19,12 +19,14 @@
> >  struct adc_keys_button {
> >  	u32 voltage;
> >  	u32 keycode;
> > +	u32 type;
> >  };
> >  
> >  struct adc_keys_state {
> >  	struct iio_channel *channel;
> >  	u32 num_keys;
> >  	u32 last_key;
> > +	u32 last_type;
> >  	u32 keyup_voltage;
> >  	const struct adc_keys_button *map;
> >  };
> > @@ -35,6 +37,7 @@ static void adc_keys_poll(struct input_dev *input)
> >  	int i, value, ret;
> >  	u32 diff, closest = 0xffffffff;
> >  	int keycode = 0;
> > +	u32 type = EV_KEY;
> >  
> >  	ret = iio_read_channel_processed(st->channel, &value);
> >  	if (unlikely(ret < 0)) {
> > @@ -46,6 +49,7 @@ static void adc_keys_poll(struct input_dev *input)
> >  			if (diff < closest) {
> >  				closest = diff;
> >  				keycode = st->map[i].keycode;
> > +				type = st->map[i].type;
> >  			}
> >  		}
> >  	}
> > @@ -54,13 +58,14 @@ static void adc_keys_poll(struct input_dev *input)
> >  		keycode = 0;
> >  
> >  	if (st->last_key && st->last_key != keycode)
> > -		input_report_key(input, st->last_key, 0);
> > +		input_event(input, st->last_type, st->last_key, 0);
> >  
> >  	if (keycode)
> > -		input_report_key(input, keycode, 1);
> > +		input_event(input, type, keycode, 1);
> 
> When EV_ABS is defined in the DT as the key type, which happens with
> joysticks and whatnot, separate handling is needed, by requiring the
> actual associated button values to be reported in the input_event()
> invocations, more specifically on the keypresses only.

Analogue control devices like joysticks are handled in adc-joystick.c.
adc-keys is specifically for resistor-ladder key devices. A driver or
binding for some absolute/relative positioning device that is not a
joystick should get its own binding first. Overloading the meaning
of the adc-keys binding and then adding functionality to the driver
is not the way to go.

I'll instead add code to only allow EV_KEY and EV_SW. Switches
function like keys for all intents and purposes, so they fit here.

> 
> That's also visible in the gpio_keys_gpio_report_event() function in
> drivers/input/keyboard/gpio_keys.c.
> 
> >  	input_sync(input);
> >  	st->last_key = keycode;
> > +	st->last_type = type;
> >  }
> >  
> >  static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> > @@ -93,6 +98,10 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
> >  			return -EINVAL;
> >  		}
> >  
> > +		if (fwnode_property_read_u32(child, "linux,input-type",
> > +					     &map[i].type))
> > +			map[i].type = EV_KEY;
> 
> Going along with the remarks above, it will also be needed to read
> and record the values of "linux,input-value" DT properties here, and
> to extend the associated binding to define their presence.
> 
> >  		i++;
> >  	}
> >  
> > @@ -156,9 +165,8 @@ static int adc_keys_probe(struct platform_device *pdev)
> >  	input->id.product = 0x0001;
> >  	input->id.version = 0x0100;
> >  
> > -	__set_bit(EV_KEY, input->evbit);
> >  	for (i = 0; i < st->num_keys; i++)
> > -		__set_bit(st->map[i].keycode, input->keybit);
> > +		input_set_capability(input, st->map[i].type, st->map[i].keycode);
> >  
> >  	if (device_property_read_bool(dev, "autorepeat"))
> >  		__set_bit(EV_REP, input->evbit);
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-12-15 11:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-30 10:19 [PATCH 0/4] ROCK 4D audio enablement Nicolas Frattaroli
2025-06-30 10:19 ` Nicolas Frattaroli
2025-06-30 10:19 ` [PATCH 1/4] dt-bindings: input: adc-keys: allow linux,input-type property Nicolas Frattaroli
2025-06-30 10:19   ` Nicolas Frattaroli
2025-06-30 11:37   ` Heiko Stübner
2025-06-30 11:37     ` Heiko Stübner
2025-06-30 10:19 ` [PATCH 2/4] Input: adc-keys - support types that aren't just keyboard keys Nicolas Frattaroli
2025-06-30 10:19   ` Nicolas Frattaroli
2025-06-30 11:49   ` Heiko Stübner
2025-06-30 11:49     ` Heiko Stübner
2025-10-28 21:32   ` Dragan Simic
2025-10-28 21:32     ` Dragan Simic
2025-12-15 11:10     ` Nicolas Frattaroli [this message]
2025-12-15 11:10       ` Nicolas Frattaroli
2025-06-30 10:19 ` [PATCH 3/4] arm64: dts: rockchip: add analog audio to ROCK 4D Nicolas Frattaroli
2025-06-30 10:19   ` Nicolas Frattaroli
2025-07-02  9:49   ` Cristian Ciocaltea
2025-07-02  9:49     ` Cristian Ciocaltea
2025-06-30 10:19 ` [PATCH 4/4] arm64: dts: rockchip: add HDMI audio on " Nicolas Frattaroli
2025-06-30 10:19   ` Nicolas Frattaroli
2025-07-02  8:57   ` Cristian Ciocaltea
2025-07-02  8:57     ` Cristian Ciocaltea
2025-07-10  9:27 ` (subset) [PATCH 0/4] ROCK 4D audio enablement Heiko Stuebner
2025-07-10  9:27   ` Heiko Stuebner

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=2411362.ElGaqSPkdT@workhorse \
    --to=nicolas.frattaroli@collabora.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dsimic@manjaro.org \
    --cc=heiko@sntech.de \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.