Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1382555
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 05/15] irqchip: Mask the non-type/sense bits when translating an IRQ |
| Date | 2016-04-19 16:20 +0200 |
| Message-ID | <rpEFs-8b6-23@gated-at.bofh.it> (permalink) |
| References | <rdGWl-8uZ-9@gated-at.bofh.it> <rdH62-6P-13@gated-at.bofh.it> <rlYW6-3XE-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 09/04/16 12:03, Marc Zyngier wrote:
> On Thu, 17 Mar 2016 14:19:09 +0000
> Jon Hunter <jonathanh@nvidia.com> wrote:
>
>> The firmware parameter that contains the IRQ sense bits may also contain
>> other data. When return the IRQ type, bits outside of these sense bits
>> should be masked. If these bits are not masked and
>> irq_create_fwspec_mapping() is called to map an IRQ, then the comparison
>> of the type returned from irq_domain_translate() will never match
>> that returned by irq_get_trigger_type() (because this function masks the
>> none sense bits) and so we will always call irq_set_irq_type() to program
>> the type even if it was not really necessary.
>>
>> Currently, the downside to this is unnecessarily re-programmming the type
>> but nevertheless this should be avoided.
>>
>> The Tegra LIC, TI Crossbar and GIC-V3 irqchips all have client instances
>> (from reviewing the device-tree sources) where bits outside the IRQ sense
>> bits are set, but do not mask these bits. Therefore, ensure these bits
>> are masked for these irqchips.
>
> For GICv3, this shouldn't be the case. The DT clearly says that the 3rd
> field should only contain the trigger description. It looks like people
> have been copying their GICv2 DT and simply slapped the v3 description
> in the middle, without changing their interrupt specifiers. Duh.
Hmmm ... I was just double checking on this for the gic-v3 by wading
through the DTS files, and may be there is no issue here. However,
looking at the current code it is a bit inconsistent between firmware
types ...
static int gic_irq_domain_translate(struct irq_domain *d,
struct irq_fwspec *fwspec,
unsigned long *hwirq,
unsigned int *type)
{
if (is_of_node(fwspec->fwnode)) {
if (fwspec->param_count < 3)
return -EINVAL;
switch (fwspec->param[0]) {
case 0: /* SPI */
*hwirq = fwspec->param[1] + 32;
break;
case 1: /* PPI */
*hwirq = fwspec->param[1] + 16;
break;
case GIC_IRQ_TYPE_LPI: /* LPI */
*hwirq = fwspec->param[1];
break;
default:
return -EINVAL;
}
*type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
return 0;
}
if (is_fwnode_irqchip(fwspec->fwnode)) {
if(fwspec->param_count != 2)
return -EINVAL;
*hwirq = fwspec->param[0];
*type = fwspec->param[1];
return 0;
}
return -EINVAL;
> I guess this patch doesn't hurt though.
Yes, it doesn't but I think I will leave this alone for now, given that
I can't find a case where this would be a problem.
Cheers
Jon
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [PATCH 05/15] irqchip: Mask the non-type/sense bits when translating an IRQ Jon Hunter <jonathanh@nvidia.com> - 2016-04-19 16:20 +0200 Re: [PATCH 05/15] irqchip: Mask the non-type/sense bits when translating an IRQ Marc Zyngier <marc.zyngier@arm.com> - 2016-04-19 16:30 +0200
csiph-web