Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4483542pxf; Tue, 30 Mar 2021 08:54:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzquzcCrFcNOZ1oQpOmWn7yymz+pGVO/5SGXj7Wba9INmQmQTJwvteE+/DUIDxwvlSlAFCS X-Received: by 2002:a17:906:bccc:: with SMTP id lw12mr33320651ejb.268.1617119648820; Tue, 30 Mar 2021 08:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617119648; cv=none; d=google.com; s=arc-20160816; b=iBinQ0SFhdga0whqVUd2GG1Ev8MUHWwzJyhH4iF6nX4IzpIYmepYKGAk2LGls5qRAy OcVfMgDz2Ph0T3viAVMSjBJ/zP0YK2N6v/s0AFLPjy7yp07Yw9HN7hr9+LhgM8YQ1WiT 7U3YUP6pph6s6AiEJdT6jLiIEQTQ4u9iVXYx0UyErrjlSnhOcP48TxDB9c1iMTbieUzI GIHOe4TFMrnBhWvRjv3a+rw8bK0cbkMG34zmvpQ4cRVZ6FsHXrq2qfTQD8szMqw0/BE8 5x5KaDovOiFnrYDaarX9TkcKYZtoZHSFaemAIR8pQjn81aWcOlF7ZoEyBKc///6Ky1dk Q7iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:ironport-sdr :ironport-sdr; bh=nd2cA0WEEhhf5EUIARnXEO/481TqVVSaaND6kv4zfvw=; b=Sc/AdJGwN4R6wTHDelqJdW6/sweGNce4mtnC4YW0wVY+NHMNa5qsdCZgM2hfCsPIKD dbUisSrz8HFTVDODPPGi8vlbua4Qkd2z02LYv4uAT9ngS/Lrq7c8OPKs5DEj+ev1ce18 8LACr957a3ZqM/AMsrAETHr9ZuZSfRCpQDsKaswPwQeizKQaJmytmFjwVoz0y9pYNxVD DWZsqi0jPomH3Fx6PILsT2Be3d46N3psQgu3eyvrziBIOwrPeV+wPN/3WVQ/aNiuDmtf nALqra5GyczjdH1klPSBlTaJtNpy5DPTYMIFlaT3aVLyyXIJjYxjYxzvB1QiIW+b4ecS DPtw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bq23si14904042ejb.498.2021.03.30.08.53.45; Tue, 30 Mar 2021 08:54:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232046AbhC3PuL (ORCPT + 99 others); Tue, 30 Mar 2021 11:50:11 -0400 Received: from mga04.intel.com ([192.55.52.120]:64711 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231991AbhC3PuH (ORCPT ); Tue, 30 Mar 2021 11:50:07 -0400 IronPort-SDR: YfAp4jE1+IsYs29iGbHnZKqjMCwK9qyVlPUHLFaHWT4CHRjB1vEf/Az31EJrbPry/WxG43J6bg 1M+SGtHQtW/g== X-IronPort-AV: E=McAfee;i="6000,8403,9939"; a="189553510" X-IronPort-AV: E=Sophos;i="5.81,291,1610438400"; d="scan'208";a="189553510" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2021 08:50:06 -0700 IronPort-SDR: 41/9bI8WUCMUw1VAww60kVAXSnK+BEjNveSFmjwH6T3dAKa+HUb7txo1YTLEHj3EZNztQFi7U0 /0jbNrBIBmEA== X-IronPort-AV: E=Sophos;i="5.81,291,1610438400"; d="scan'208";a="445200586" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2021 08:50:00 -0700 Received: by lahna (sSMTP sendmail emulation); Tue, 30 Mar 2021 18:49:57 +0300 Date: Tue, 30 Mar 2021 18:49:57 +0300 From: Mika Westerberg To: "Rafael J. Wysocki" Cc: Angela Czubak , akpm@linux-foundation.org, john.garry@huawei.com, linux-kernel@vger.kernel.org, upstream@semihalf.com, dtor@chromium.org, linux-acpi , rafael@kernel.org Subject: Re: [PATCH] resource: Prevent irqresource_disabled() from erasing flags Message-ID: <20210330154957.GU2542@lahna.fi.intel.com> References: <20210329195238.9455-1-acz@semihalf.com> <1c086b9e-d5c2-6e8d-1d81-748935b0dd64@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1c086b9e-d5c2-6e8d-1d81-748935b0dd64@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Mar 30, 2021 at 05:09:42PM +0200, Rafael J. Wysocki wrote: > On 3/29/2021 9:52 PM, Angela Czubak wrote: > > Do not overwrite flags as it leads to erasing triggering and polarity > > information which might be useful in case of hard-coded interrupts. > > This way the information can be read later on even though mapping to > > APIC domain failed. > > > > Signed-off-by: Angela Czubak > > --- > > Some Chromebooks use hard-coded interrupts in their ACPI tables. > > This is an excerpt as dumped on Relm: > > > > ... > > ? ? ? ? ? ? Name (_HID, "ELAN0001") ?// _HID: Hardware ID > > ? ? ? ? ? ? Name (_DDN, "Elan Touchscreen ") ?// _DDN: DOS Device Name > > ? ? ? ? ? ? Name (_UID, 0x05) ?// _UID: Unique ID > > ? ? ? ? ? ? Name (ISTP, Zero) > > ? ? ? ? ? ? Method (_CRS, 0, NotSerialized) ?// _CRS: Current Resource Settings > > ? ? ? ? ? ? { > > ? ? ? ? ? ? ? ? Name (BUF0, ResourceTemplate () > > ? ? ? ? ? ? ? ? { > > ? ? ? ? ? ? ? ? ? ? I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80, > > ? ? ? ? ? ? ? ? ? ? ? ? AddressingMode7Bit, "\\_SB.I2C1", > > ? ? ? ? ? ? ? ? ? ? ? ? 0x00, ResourceConsumer, , Exclusive, > > ? ? ? ? ? ? ? ? ? ? ? ? ) > > ? ? ? ? ? ? ? ? ? ? Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive, ,, ) > > ? ? ? ? ? ? ? ? ? ? { > > ? ? ? ? ? ? ? ? ? ? ? ? 0x000000B8, > > ? ? ? ? ? ? ? ? ? ? } > > ? ? ? ? ? ? ? ? }) > > ? ? ? ? ? ? ? ? Return (BUF0) /* \_SB_.I2C1.ETSA._CRS.BUF0 */ > > ? ? ? ? ? ? } > > ... > > > > This interrupt is hard-coded to 0xB8 = 184 which is too high to be mapped > > to IO-APIC, so no triggering information is propagated as acpi_register_gsi() > > fails and irqresource_disabled() is issued, which leads to erasing triggering > > and polarity information. > > If that function added its flags instead of overwriting them the correct IRQ > > type would be set even for the hard-coded interrupts, which allows device driver > > to retrieve it. > > Please, let me know if this kind of modification is acceptable. > > From the quick look it should not be problematic, but it needs to be checked > more carefully. > > Mika, what do you think? I think it makes sense. We still set IORESOURCE_DISABLED unconditionally so this should not cause issues. In theory at least :) > > include/linux/ioport.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/linux/ioport.h b/include/linux/ioport.h > > index 55de385c839cf..647744d8514e0 100644 > > --- a/include/linux/ioport.h > > +++ b/include/linux/ioport.h > > @@ -331,7 +331,7 @@ static inline void irqresource_disabled(struct resource *res, u32 irq) > > { > > res->start = irq; > > res->end = irq; > > - res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET; > > + res->flags |= IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET; > > } > > extern struct address_space *iomem_get_mapping(void); >