From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754750AbcDKMnt (ORCPT ); Mon, 11 Apr 2016 08:43:49 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:48215 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754209AbcDKMnr (ORCPT ); Mon, 11 Apr 2016 08:43:47 -0400 Reply-To: Subject: Re: [PATCH v7 3/3] gpio: dwapb: add gpio-signaled acpi event support References: <1459926480-32966-1-git-send-email-qiujiang@huawei.com> <1459926480-32966-4-git-send-email-qiujiang@huawei.com> <20160408083830.GT1727@lahna.fi.intel.com> To: Mika Westerberg , Linus Walleij CC: Alexandre Courbot , Andy Shevchenko , Alan Tull , "Jamie Iles" , , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "ACPI Devel Maling List" , Linuxarm From: Jiang Qiu Message-ID: <570B9BEA.8060608@huawei.com> Date: Mon, 11 Apr 2016 20:43:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160408083830.GT1727@lahna.fi.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.74.160.152] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.570B9BF1.01EE,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fd172d1207c863a08fd01bb5b99277e1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/4/8 16:38, Mika Westerberg 写道: > On Fri, Apr 08, 2016 at 10:26:28AM +0200, Linus Walleij wrote: >> On Wed, Apr 6, 2016 at 9:08 AM, qiujiang wrote: >> >>> This patch adds gpio-signaled acpi event support. It is used for >>> power button on hisilicon D02 board, an arm64 platform. >>> >>> The corresponding DSDT file is defined as follows: >>> Device(GPI0) { >>> Name(_HID, "HISI0181") >>> Name(_ADR, 0) >>> Name(_UID, 0) >>> >>> Name (_CRS, ResourceTemplate () { >>> Memory32Fixed (ReadWrite, 0x802e0000, 0x10000) >>> Interrupt (ResourceConsumer, Level, ActiveHigh, >>> Exclusive,,,) {344} >>> }) >>> >>> Device(PRTa) { >>> Name (_DSD, Package () { >>> Package () { >>> Package () {"reg",0}, >>> Package () {"snps,nr-gpios",32}, >>> } >>> }) >>> } >>> >>> Name (_AEI, ResourceTemplate () { >>> GpioInt(Edge, ActiveLow, ExclusiveAndWake, >>> PullUp, , " \\_SB.GPI0") {8} >>> }) >>> >>> Method (_E08, 0x0, NotSerialized) { >>> Notify (\_SB.PWRB, 0x80) >>> } >>> } >>> >>> Acked-by: Mika Westerberg >>> Reviewed-by: Andy Shevchenko >>> Signed-off-by: qiujiang >> Admittedly I'm an ACPI novice and need help with deciding >> about ACPI, but I mostly trust Mika to know these things right. >> >> About this: >> >>> + /* Add GPIO-signaled ACPI event support */ >>> + if (pp->irq) >>> + acpi_gpiochip_request_interrupts(&port->gc); >> It's weird to me that the driver already has a requested IRQ and >> everything, now it has to request it again from ACPI. > This is different thing, though. > > Calling acpi_gpiochip_request_interrupts() results _AEI ACPI method > being evaluated that returns a list of GPIOs which are used as event > sources. acpi_gpiochip_request_interrupts() then goes and installs > interrupt handler per each GPIO in that list. > >> When I look into the acpi_gpiochip_request_interrupts() >> I find it weird that it is void given how much can go wrong >> inside it. Should it not return an errorcode? > Currently it just complains if something goes wrong. The GPIO driver > itself can still work just fine (including interrupts). > > I'm fine to change it to return an error code. Agree, if add a error code for acpi_gpiochip_request_interrupts(), it looks more pretty. However, this function is common for other part, maybe cause any other effects if I do this change, did you think so? >>> + if (has_acpi_companion(dev) && pp->idx == 0) >>> + pp->irq = platform_get_irq(to_platform_device(dev), 0); >> As it was already fetched here and then later requested, >> we still have to call acpi_gpiochip_request_interrupts() >> further down the road? That is confusing to me, can you >> explain what is going on? > See above. > > . >