Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4769202imm; Tue, 21 Aug 2018 00:13:31 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyPsCFco2g5vZKeCjqsM8/iIVcgGHaGhvq23rv4AxcuOiLQ/kMKn0IP4P9CBwCzmZfMKhRP X-Received: by 2002:a63:dd09:: with SMTP id t9-v6mr45604666pgg.370.1534835611525; Tue, 21 Aug 2018 00:13:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534835611; cv=none; d=google.com; s=arc-20160816; b=tXKZOjqkJTEzUN6dRiTnGF2Qxnk7a1v8bYiLe5tbBYuHUUPJLEg19hWnNcuW7sjFDP kJil5q+sHIaAaZUcnu/JWnOaY02c/9mAnL68gSeVTOxe4Ac4kH7ATyB/+gJCCtP/pC13 F4rbkaMq2ocKmgRpkfE+sLvum6Uy1reqH1ZzHj7nH2iPxNZ9ktPXlc6xwyEodhnDVJLD O46IKjB3EOqyPdiAZf7AdHJifXVuqmoeNkqJXtqvuavK18Do+27bq5VAtFhKZLdbufxR R7AQ1mY8/HYeHMsqtOUEAbr90VjIQbFMjhqpWIK06F+x0OpZepJw6sGhX2O6ZqyRj16p qjyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=4G3jhZASS9ZgNHdHHbZBBisy4BxSrwI2imIlSkRu1MU=; b=alvYxkceZErXnusPp5ScbKc1EG392gTTV073Kx289q8TlpDoyU/ozgz3iciW5FRC9b yZ+zbvghp6lD6J2O+oe5dJGX1U8obsZjets3ivomJcU40X0rE9RLFc8mLD3A826a42Ww QLxaCV1/Rq4eG/PChhn2T5L3h5kViSD3zW9Skj91FeLsYDGmtrucLnjOVQ5sLXsx4asV WsKhwwZhe3wLumGquL1MvMytblcLqtfQbWR+wZe9+UhgsGtrrNecCnJTEEMR4IfGBtxW Hdzn6PGepDWzz80HQorrMBXMBJOW6E842zqwa4V+qqa5W4Ip9F7yscZaVfy/FI9Q1J0u 8ebQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j193-v6si11347456pge.617.2018.08.21.00.13.13; Tue, 21 Aug 2018 00:13:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726658AbeHUKa7 (ORCPT + 99 others); Tue, 21 Aug 2018 06:30:59 -0400 Received: from foss.arm.com ([217.140.101.70]:45572 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726253AbeHUKa7 (ORCPT ); Tue, 21 Aug 2018 06:30:59 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 197E3ED1; Tue, 21 Aug 2018 00:12:02 -0700 (PDT) Received: from why.wild-wind.fr.eu.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE4173F2EA; Tue, 21 Aug 2018 00:11:59 -0700 (PDT) Date: Tue, 21 Aug 2018 08:11:55 +0100 From: Marc Zyngier To: Lina Iyer Cc: bjorn.andersson@linaro.org, sboyd@kernel.org, evgreen@chromium.org, linus.walleij@linaro.org, rplsssn@codeaurora.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, rnayak@codeaurora.org, devicetree@vger.kernel.org, andy.gross@linaro.org, dianders@chromium.org Subject: Re: [PATCH RESEND v1 2/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend Message-ID: <20180821081155.1865db14@why.wild-wind.fr.eu.org> In-Reply-To: <20180820154959.GS5081@codeaurora.org> References: <20180817191026.32245-1-ilina@codeaurora.org> <20180817191026.32245-3-ilina@codeaurora.org> <86a7pjq0l1.wl-marc.zyngier@arm.com> <20180820152629.GR5081@codeaurora.org> <047d37fb-1011-0650-6517-e6052ba47a18@arm.com> <20180820154959.GS5081@codeaurora.org> Organization: ARM Ltd X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Aug 2018 09:49:59 -0600 Lina Iyer wrote: > On Mon, Aug 20 2018 at 09:34 -0600, Marc Zyngier wrote: > >On 20/08/18 16:26, Lina Iyer wrote: > >> On Sat, Aug 18 2018 at 07:13 -0600, Marc Zyngier wrote: > >>> Hi Lina, > >>> > >>> On Fri, 17 Aug 2018 20:10:23 +0100, > >>> Lina Iyer wrote: > > > >[...] > > > >>>> @@ -920,6 +928,8 @@ static int msm_gpio_pdc_pin_request(struct irq_data *d) > >>>> } > >>>> > >>>> irq_set_handler_data(d->irq, irq_get_irq_data(irq)); > >>>> + irq_set_handler_data(irq, d); > >>>> + irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY); > >>> > >>> Could you explain what this is trying to do? I'm trying to understand > >>> this code, but this function isn't in 4.18... > >>> > >> Oh, I have been able to test only on 4.14 so far. The flag does seem to > >> exist at least, I didn't get a compiler error. > >> > >> I read this in kernel/irq/chip.c - > >> > >> If the interrupt chip does not implement the irq_disable callback, > >> a driver can disable the lazy approach for a particular irq line by > >> calling 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'. This can > >> be used for devices which cannot disable the interrupt at the > >> device level under certain circumstances and have to use > >> disable_irq[_nosync] instead. > >> > >> And interpreted this as something that this would prevent 'relaxed' > >> disable. I am enabling and disabling the IRQ in suspend path, that I > >> thought this would help avoid issues caused by late disable. Am I > >> mistaken? > > > >Sorry, I wasn't clear enough. I'm talking about what you're trying to do > >in this particular function (msm_gpio_pdc_pin_request), which doesn't > >exist in 4.18. Short of having a bit of context, I can hardly review this. > > > Sorry, my patch generation during the resend is messed up. Seems like I > didn't send that patch out during the resend. Please make sure you test with mainline. Basing your developments on something as old as 4.14 makes no sense for something that targets mainline. You should write your code on mainline, test it there, and eventually backport it to whatever version you want to use. Otherwise, we are guaranteed to merge something that will not work. Thanks, M. -- Without deviation from the norm, progress is not possible.