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: <ZsiygIj9SiP4O0OM@google.com>
Date: Fri, 23 Aug 2024 09:02:08 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Haojian Zhuang <haojian.zhuang@...il.com>,
	Daniel Mack <daniel@...que.org>,
	Robert Jarzmik <robert.jarzmik@...e.fr>,
	Arnd Bergmann <arnd@...db.de>, soc@...nel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: [PATCH 0/5] Remove support for platform data from matrix keypad
 driver

Hi Linus,

On Fri, Aug 23, 2024 at 05:51:30PM +0200, Linus Walleij wrote:
> On Mon, Aug 5, 2024 at 3:47 AM Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> 
> > This series attempts to remove support for platform data from
> > matrix_keypad driver, and have it use generic device properties only
> > for the keypad configuration. Spitz is the only board [left] that
> > uses platform data.
> >
> > As part of the migration I am also dropping support for "clustered"
> > interrupt mode, as it was only available through platform data and there
> > are no users of it in the mainline kernel.
> >
> > Additionally gpio-keys device used by Spitz converted to use device
> > properties instead of platform data.
> >
> > I would prefer not to have the song and dance of merging first 2 patches
> > through the input tree, waiting, merging the spitz patches through SoC
> > tree, waiting, and finally merging the last patch to matrix keypad
> > through input again, so maybe we could merge it all through SoC?
> > Alternatively, I could merge everything through input. What do you
> > think?
> 
> Sounds like a plan. The series:
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Thanks!

I'm glad that we agree that we do not want the elaborate merge process
and instead push the changes through one tree in one shot we just need
to decide which one - soc or input. I am fine with using either.

Sorry if I am being obtuse.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ