linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Agustin Vega-Frias <agustinv@codeaurora.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
	lenb@kernel.org, tglx@linutronix.de, jason@lakedaemon.net,
	marc.zyngier@arm.com, timur@codeaurora.org, cov@codeaurora.org,
	agross@codeaurora.org, harba@codeaurora.org, jcm@redhat.com,
	msalter@redhat.com, mlangsdo@redhat.com, ahs3@redhat.com,
	astone@redhat.com, graeme.gregory@linaro.org,
	guohanjun@huawei.com, charles.garcia-tobin@arm.com
Subject: Re: [PATCH V9 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan
Date: Fri, 16 Dec 2016 11:30:41 -0500	[thread overview]
Message-ID: <b63b1d787c91024d1e49a4fd430ed29d@codeaurora.org> (raw)
In-Reply-To: <20161216162439.GA24673@red-moon>

Hi Lorenzo,

On 2016-12-16 11:24, Lorenzo Pieralisi wrote:
> On Wed, Dec 14, 2016 at 05:10:36PM -0500, Agustin Vega-Frias wrote:
>> ACPI extended IRQ resources may contain a Resource Source field to 
>> specify
>> an alternate interrupt controller, attempting to map them as GSIs is
>> incorrect, so just disable the platform resource.
>> 
>> Since this field is currently ignored, we make this change conditional
>> on CONFIG_ACPI_GENERIC_GSI to keep the current behavior on x86 
>> platforms,
>> in case some existing ACPI tables are using this incorrectly.
>> 
>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>> ---
>>  drivers/acpi/resource.c | 17 ++++++++++++++++-
>>  1 file changed, 16 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 56241eb..76ca4e9 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -43,6 +43,18 @@ static inline bool 
>> acpi_iospace_resource_valid(struct resource *res)
>>  acpi_iospace_resource_valid(struct resource *res) { return true; }
>>  #endif
>> 
>> +#ifdef CONFIG_ACPI_GENERIC_GSI
>> +static inline bool is_gsi(struct acpi_resource_extended_irq *ext_irq)
>> +{
>> +	return ext_irq->resource_source.string_length == 0;
>> +}
>> +#else
>> +static inline bool is_gsi(struct acpi_resource_extended_irq *ext_irq)
>> +{
>> +	return true;
>> +}
>> +#endif
> 
> Well, patch is simple there is not much to say other that on the
> firmware side I honestly do not see many options, either we remove the
> ifdeffery above and make the check unconditional (ie we do check on
> x86/ia64 too instead of always returning true) and see if things hold 
> up
> on x86 (at least we try) or we will never know and will never be able 
> to
> use this on x86 if there will ever be need.
> 
> It would be certainly weird to find out that a descriptor has a
> resource_source pointer put there by mistake (because that's what we 
> are
> talking about, things work on x86/ia64 by ignoring the resource_source
> pointer so any string there is just an unfortunate mistake AFAICS).
> 
> I am quite tempted to remove the ifdef and make the is_gsi() check 
> effective on
> x86/ia64 too.

I wouldn't be opposed to that. I added the #ifdef out of abundance of 
caution,
but if the x86 folks agree and we can get sufficient testing to ensure 
this
doesn't break anything I'd like to remove it too.

Thanks,
Agustin

> 
> Lorenzo
> 
>> +
>>  static bool acpi_dev_resource_len_valid(u64 start, u64 end, u64 len, 
>> bool io)
>>  {
>>  	u64 reslen = end - start + 1;
>> @@ -470,9 +482,12 @@ bool acpi_dev_resource_interrupt(struct 
>> acpi_resource *ares, int index,
>>  			acpi_dev_irqresource_disabled(res, 0);
>>  			return false;
>>  		}
>> -		acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> +		if (is_gsi(ext_irq))
>> +			acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>>  					 ext_irq->triggering, ext_irq->polarity,
>>  					 ext_irq->sharable, false);
>> +		else
>> +			acpi_dev_irqresource_disabled(res, 0);
>>  		break;
>>  	default:
>>  		res->flags = 0;
>> --
>> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
>> Linux Foundation Collaborative Project.
>> 

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

  reply	other threads:[~2016-12-16 16:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14 22:10 [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver Agustin Vega-Frias
2016-12-14 22:10 ` [PATCH V9 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan Agustin Vega-Frias
2016-12-16 16:24   ` Lorenzo Pieralisi
2016-12-16 16:30     ` Agustin Vega-Frias [this message]
2017-01-17 12:15   ` Hanjun Guo
2017-01-17 15:04     ` Agustin Vega-Frias
2016-12-14 22:10 ` [PATCH V9 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping Agustin Vega-Frias
2017-01-17 12:47   ` Hanjun Guo
2017-01-17 15:07     ` Agustin Vega-Frias
2017-01-18  1:40       ` Hanjun Guo
2016-12-14 22:10 ` [PATCH V9 3/3] irqchip: qcom: Add IRQ combiner driver Agustin Vega-Frias
2017-01-05 16:48   ` Marc Zyngier
2017-01-06 13:17     ` Agustin Vega-Frias
2017-01-09 15:25       ` Marc Zyngier
2017-01-03 15:19 ` [PATCH V9 0/3] " Agustin Vega-Frias
2017-01-03 21:56   ` Rafael J. Wysocki
2017-01-04 12:37     ` Agustin Vega-Frias
2017-01-16 14:07     ` Agustin Vega-Frias
2017-01-16 14:14       ` Marc Zyngier
2017-01-16 14:41         ` Hanjun Guo
2017-01-16 14:53           ` Lorenzo Pieralisi
2017-01-17 12:10             ` Hanjun Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b63b1d787c91024d1e49a4fd430ed29d@codeaurora.org \
    --to=agustinv@codeaurora.org \
    --cc=agross@codeaurora.org \
    --cc=ahs3@redhat.com \
    --cc=astone@redhat.com \
    --cc=charles.garcia-tobin@arm.com \
    --cc=cov@codeaurora.org \
    --cc=graeme.gregory@linaro.org \
    --cc=guohanjun@huawei.com \
    --cc=harba@codeaurora.org \
    --cc=jason@lakedaemon.net \
    --cc=jcm@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=mlangsdo@redhat.com \
    --cc=msalter@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=timur@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).