| Message ID | 20200906122016.4628-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Input: soc_button_array - Work around DSDTs which modify the irqflags | expand |
Hi Hans, On Sun, Sep 06, 2020 at 02:20:15PM +0200, Hans de Goede wrote: > Hi Dmitry, > > This patch is a bit of a kludge, but the problem it fixes has been > encountered on 2 different models now, so it seems that we really > need a workaround for this. > > This patch applies on top of these 2 patches: > > "Input: soc_button_array - Add active_low setting to soc_button_info" > "Input: soc_button_array - Add support for INT33D3 tablet-mode switch devices" > > Which I have posted multiple times upstream already (they are from May!), > but these have not been getting any attention. Sorry about that, I merged them just now. > > 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? > > 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. Thanks.
Hi, On 9/14/20 8:12 AM, Dmitry Torokhov wrote: > Hi Hans, > > On Sun, Sep 06, 2020 at 02:20:15PM +0200, Hans de Goede wrote: >> Hi Dmitry, >> >> This patch is a bit of a kludge, but the problem it fixes has been >> encountered on 2 different models now, so it seems that we really >> need a workaround for this. >> >> This patch applies on top of these 2 patches: >> >> "Input: soc_button_array - Add active_low setting to soc_button_info" >> "Input: soc_button_array - Add support for INT33D3 tablet-mode switch devices" >> >> Which I have posted multiple times upstream already (they are from May!), >> but these have not been getting any attention. > > Sorry about that, I merged them just now. No problem, and thank you. >> 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? >> >> 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? Regards, Hans
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. > >> 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.
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. Regards, Hans
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 ? Anyways this is not urgent, given the conflict I think it might be best if I send out the patch after 5.10-rc1, using 5.10-rc1 as a base for it. Regards, Hans
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.