Re: [PATCH 0/1] Input: soc_button_array - Work around DSDTs which modify the irqflags

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Mon, Sep 14, 2020 at 04:08:09PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 9/14/20 3:52 PM, Hans de Goede wrote:
> > Hi,
> > 
> > On 9/14/20 10:00 AM, Andy Shevchenko wrote:
> > > On Mon, Sep 14, 2020 at 10:45 AM Hans de Goede <hdegoede@redhat.com> wrote:
> > > > On 9/14/20 8:12 AM, Dmitry Torokhov wrote:
> > > > > On Sun, Sep 06, 2020 at 02:20:15PM +0200, Hans de Goede wrote:
> > > 
> > > ...
> > > 
> > > > > > The soc_button_array code really is x86 specific glue code to translate
> > > > > > various incarnations of gpio-keys in ACPI tables to gpio_keys_platform_data.
> > > > > > As such I wonder if it would not be better to move this driver to
> > > > > > drivers/platform/x86?
> > > 
> > > AFAIU the above is a justification why PDx86 suits better to host it.
> > 
> > Correct.
> > 
> > > > > > I seem to be doing most if not all of the recent work on soc_button_array,
> > > > > > and soon I will be a co-maintainer of drivers/platform/x86. So having it
> > > > > > there and adding me in MAINTAINERS as maintaining it seems to be best?
> > > > > > 
> > > > > > If you want I can do a patch moving soc_button_array to drivers/platform/x86
> > > > > > and then add the other 3 patches on top and then we can merge all of this
> > > > > > through drivers/platform/x86?
> > > > > 
> > > > > Sorry, misread this first time through, so already merged the 3 patches,
> > > > > but I to not mind at all moving the driver to platform tree. If you send
> > > > > me such a patch I will apply it.
> > > > 
> > > > Ok.
> > > > 
> > > > Andy are you ok with moving the driver to the pdx86 tree too?
> > > 
> > > Taking into consideration the above, if I read it correctly, I agree.
> > > Feel free to add my Ack.
> > 
> > Ok, since Dmitry's tree currently has some changes to soc_button_array.c,
> > the plan is to merge the patch through Dmitry's tree.
> > 
> > I will prepare a patch with your Acked-by and submit it.
> 
> So to make sure that there won't be any merge issues,
> I was comparing bases for
> {drivers/input/misc,drivers/platform/x86}/{Makefile,Kconfig}
> looking at the versions in:
> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/log/?h=next
> http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/for-next (which atm is just 5.9-rc1)
> 
> And the latter has a couple of commits to
> drivers/platform/x86/Kconfig which the input tree is missing;
> and these commits touch part of the file which moving the driver
> over will also be touching.
> 
> Dmitry, it seems that your for next-tree is based on 5.7 + 2
> large merges and as such does not have all the commits from
> 5.9-rc1 ?

Yeah, I typically merge with mainline if I need new APIs or to sync up
with shared stuff.

Thanks.

-- 
Dmitry