From patchwork Thu Mar 9 18:48:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 9613845 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7CA3D60414 for ; Thu, 9 Mar 2017 18:48:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5C6A6285A2 for ; Thu, 9 Mar 2017 18:48:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 511702860E; Thu, 9 Mar 2017 18:48:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9E658285A2 for ; Thu, 9 Mar 2017 18:48:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932345AbdCISsM (ORCPT ); Thu, 9 Mar 2017 13:48:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56240 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932164AbdCISsL (ORCPT ); Thu, 9 Mar 2017 13:48:11 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 680937E9E7; Thu, 9 Mar 2017 18:48:11 +0000 (UTC) Received: from shalem.localdomain (ovpn-116-25.ams2.redhat.com [10.36.116.25]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v29Im85n007213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2017 13:48:09 -0500 Subject: Re: [PATCH v2] Input: silead - Do not try to directly access the GPIO when using ACPI pm To: Andy Shevchenko , Mika Westerberg , Daniel Vetter References: <20170122200008.27027-1-hdegoede@redhat.com> <1487778778.20145.22.camel@linux.intel.com> <65b7a7ed-3199-84d2-c004-adedadce1d88@redhat.com> <1488454727.20145.71.camel@linux.intel.com> <1488553076.20145.79.camel@linux.intel.com> <3be3837a-a57c-e6bf-538b-e135c1b37ff0@redhat.com> <1488554609.20145.81.camel@linux.intel.com> <693ce7b3-99e9-eb60-b164-50b27294a239@redhat.com> <1488887470.20145.108.camel@linux.intel.com> <015d1f87-fcfe-b08d-6934-732145d534ca@redhat.com> <1488969002.20145.119.camel@linux.intel.com> <1488973582.20145.125.camel@linux.intel.com> <654981a1-2493-01d6-13e6-1287b70e22f2@redhat.com> <1488997525.20145.161.camel@linux.intel.com> <114fa24e-b726-28e1-66c7-aa90bcf5c966@redhat.com> <1489068196.20145.169.camel@linux.intel.com> <93370dd7-f017-ff3a-5518-b01820452867@redhat.com> Cc: Dmitry Torokhov , "russianneuromancer @ ya . ru" , Gregor Riepl , linux-input@vger.kernel.org, Linus Walleij From: Hans de Goede Message-ID: <97099577-181d-ac94-4d9e-ab5ca64f9ff6@redhat.com> Date: Thu, 9 Mar 2017 19:48:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <93370dd7-f017-ff3a-5518-b01820452867@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 09 Mar 2017 18:48:11 +0000 (UTC) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On 09-03-17 15:45, Hans de Goede wrote: > Hi, > > On 09-03-17 15:03, Andy Shevchenko wrote: >> On Thu, 2017-03-09 at 14:57 +0100, Hans de Goede wrote: >>> Hi, >>> >>> On 08-03-17 19:25, Andy Shevchenko wrote: > > > >>>>>>>>> I think that "extcon: int3496: Add GPIO ACPI mapping >>>>>>>>> table" >>>>>>>>> will >>>>>>>>> need >>>>>>>>> a similar change (I haven't tested it yet). >>>>> >>>>> So I assume you want to do the same (pass NULL as con-id to >>>>> gpiod_get_index()) for the extcon-in3496 driver or do you want >>>>> to keep the GPIO ACPI mapping table there? >>>> >>>> A slightly preferable table variant (needs to be fixed I guess) >>>> because >>>> initial one used to have different labels. >>> >>> Ok, I will test with the acpi-mapping table then and if necessary >>> create a fixup patch for it and send that to you. >> >> Sounds like a plan! >> >> Since extcon patches are landed already mainstream it might make sense >> to send it as usual to all maintainers. > > Ack, so to be clear we should use gpiod_get not gpiod_get_index with > the acpi mapping table, right ? The reason I'm asking is that my > test devices only have the id pin which has index 0 so in my > experience with soc_button_array it will work with both > (the button with index 0 would even work with gpiod_get_index). Ok, so there is one problem with the extcon-intel-int3496.c together with your gpio patches: [ 2382.484415] gpio gpiochip1: (INT33FF:01): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 2382.484425] gpio gpiochip1: (INT33FF:01): unable to lock HW IRQ 3 for IRQ [ 2382.484429] genirq: Failed to request resources for INT3496:00 (irq 174) on irqchip chv-gpio [ 2382.484518] intel-int3496 INT3496:00: can't request IRQ for USB ID GPIO: -22 [ 2382.500359] intel-int3496: probe of INT3496:00 failed with error -22 This can be fixed / worked around by doing this: But the gpio is requested as: data->gpio_usb_id = devm_gpiod_get(dev, "id", GPIOD_IN); Note the GPIOD_IN I think the new behavior is caused by: https://bitbucket.org/andy-shev/linux/commits/ba458eb945879a66eac75de69a4e7312c4f44cc7 Of which I'm not sure it is a good idea, as the dsdt of my cube iwork8 air shows: Device (OTG2) { Name (_HID, "INT3496") // _HID: Hardware ID Name (_CID, "INT3496") // _CID: Compatible ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (ABUF, ResourceTemplate () { GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0003 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO3", 0x00, ResourceConsumer, , ) { // Pin list 0x002E } }) Return (ABUF) /* \_SB_.PCI0.OTG2._CRS.ABUF */ } } The dstd-s out there in the wild do not always get this right. With my workaround from above the extcon-intel-int3496 driver does work properly again, so I see 2 options here: 1) Let drivers workaround known broken IoRestriction in dstd-s by using gpiod_direction_... 2) Drop the patch which makes gpiod_get honor the IoRestrictions I've also tested the silead driver and with the new more strict gpio code it works as it should as-is (as expected). Regards, Hans --- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/extcon/extcon-intel-int3496.c +++ b/drivers/extcon/extcon-intel-int3496.c @@ -113,6 +113,7 @@ static int int3496_probe(struct platform_device *pdev) dev_err(dev, "can't request USB ID GPIO: %d\n", ret); return ret; } + gpiod_direction_input(data->gpio_usb_id); data->usb_id_irq = gpiod_to_irq(data->gpio_usb_id); if (data->usb_id_irq < 0) {