linux-kernel - Re: [PATCH v7 09/11] input: keyboard: Add support for MAX7360 keypad

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aBTJcQp-wBLJTh-6@smile.fi.intel.com>
Date: Fri, 2 May 2025 16:32:33 +0300
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Mathieu Dubois-Briand <mathieu.dubois-briand@...tlin.com>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Kamel Bouhara <kamel.bouhara@...tlin.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Uwe Kleine-König <ukleinek@...nel.org>,
	Michael Walle <mwalle@...nel.org>, Mark Brown <broonie@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	linux-input@...r.kernel.org, linux-pwm@...r.kernel.org,
	Grégory Clement <gregory.clement@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v7 09/11] input: keyboard: Add support for MAX7360 keypad

On Fri, May 02, 2025 at 03:15:34PM +0200, Mathieu Dubois-Briand wrote:
> On Fri May 2, 2025 at 12:46 PM CEST, Andy Shevchenko wrote:
> > On Mon, Apr 28, 2025 at 01:57:27PM +0200, Mathieu Dubois-Briand wrote:

...

> >> +static irqreturn_t max7360_keypad_irq(int irq, void *data)
> >> +{
> >> +	struct max7360_keypad *max7360_keypad = data;
> >> +	struct device *dev = max7360_keypad->input->dev.parent;
> >> +	unsigned int val;
> >> +	unsigned int row, col;
> >> +	unsigned int release;
> >> +	unsigned int code;
> >> +	int error;
> >> +
> >> +	do {
> >> +		error = regmap_read(max7360_keypad->regmap, MAX7360_REG_KEYFIFO, &val);
> >> +		if (error) {
> >> +			dev_err(dev, "Failed to read max7360 FIFO");
> >> +			return IRQ_NONE;
> >> +		}
> >> +
> >> +		/* FIFO overflow: ignore it and get next event. */
> >> +		if (val == MAX7360_FIFO_OVERFLOW)
> >> +			dev_warn(dev, "max7360 FIFO overflow");
> >
> > If many events are missing this will flood the logs, perhaps _ratelimited() ?
> >
> >> +	} while (val == MAX7360_FIFO_OVERFLOW);
> >
> > regmap_read_poll_timeout() ?
> 
> OK, I can try something like:
> 
> +       error = regmap_read(max7360_keypad->regmap, MAX7360_REG_KEYFIFO, &val);
> +
> +       /* FIFO overflow: ignore it and get next event. */
> +       if (!error && (val == MAX7360_FIFO_OVERFLOW)) {
> +               dev_warn(dev, "max7360 FIFO overflow");
> +               error = regmap_read_poll_timeout(max7360_keypad->regmap, MAX7360_REG_KEYFIFO,
> +                                                val, val != MAX7360_FIFO_OVERFLOW, 0, 0);
> +       }
> +
> +       if (error) {
> +               dev_err(dev, "Failed to read max7360 FIFO");
> +               return IRQ_NONE;
> +       }

Maybe something like this (see also below about timeouts)?

       error = regmap_read(max7360_keypad->regmap, MAX7360_REG_KEYFIFO, &val);
       if (error) {
               dev_err(dev, "Failed to read MAX7360 FIFO");
               return IRQ_NONE;
       }

       /* FIFO overflow: ignore it and get next event. */
       if (val == MAX7360_FIFO_OVERFLOW) {
               dev_warn(dev, "max7360 FIFO overflow");
               error = regmap_read_poll_timeout(max7360_keypad->regmap, MAX7360_REG_KEYFIFO,
                                                val, val != MAX7360_FIFO_OVERFLOW, 0, 1000);
               if (error) {
                       dev_err(dev, "Failed to empty MAX7360 FIFO");
                       return IRQ_NONE;
               }
       }

> Sleep_us is 0 as we are in the IRQ handler,

Isn't it under the mutex, so we are fine to have small delays? But in general
it seems not okay to sleep here. In any case 0 for sleep_us gives an atomic read.

> but I'm not sure about
> timeout_us. We could set one to make sure we are not stuck in the IRQ
> handler, but the IRQ would fire again right after we return. I will stay
> with 0 for now.

I would still choose sane limit. The backend uses ktime for this, so it might
be corner cases (tickless systems) but in general should be fine.

> Also, the "max7360 FIFO overflow" message would be shown at most once
> per IRQ, so probably no need for dev_warn_ratelimited().
> 
> >> +	if (val == MAX7360_FIFO_EMPTY) {
> >> +		dev_dbg(dev, "Got a spurious interrupt");
> >> +
> >> +		return IRQ_NONE;
> >> +	}
> >> +
> >> +	row = FIELD_GET(MAX7360_FIFO_ROW, val);
> >> +	col = FIELD_GET(MAX7360_FIFO_COL, val);
> >> +	release = val & MAX7360_FIFO_RELEASE;
> >> +
> >> +	code = MATRIX_SCAN_CODE(row, col, MAX7360_ROW_SHIFT);
> >> +
> >> +	dev_dbg(dev, "key[%d:%d] %s\n", row, col, release ? "release" : "press");
> >> +
> >> +	input_event(max7360_keypad->input, EV_MSC, MSC_SCAN, code);
> >> +	input_report_key(max7360_keypad->input, max7360_keypad->keycodes[code], !release);
> >> +	input_sync(max7360_keypad->input);
> >> +
> >> +	return IRQ_HANDLED;
> >> +}

-- 
With Best Regards,
Andy Shevchenko