Hi Jon,
On 19/04/16 15:14, Jon Hunter wrote:
>
> On 09/04/16 12:03, Marc Zyngier wrote:
>> On Thu, 17 Mar 2016 14:19:09 +0000
>> Jon Hunter <jonathanh@xxxxxxxxxx> 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];
That's because param[1] doesn't really come from the firmware. It is
actually provided directly by acpi_dev_get_irq_type, so more or less
guaranteed to be a valid value.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
