linux-kernel - Re: [PATCH v2 1/2] device property: Add fwnode_irq_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Nov 2021 10:53:04 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Puranjay Mohan <puranjay12@...il.com>
Cc:     gregkh@...uxfoundation.org, rafael@...nel.org,
        heikki.krogerus@...ux.intel.com, kuba@...nel.org,
        saravanak@...gle.com, linux-kernel@...r.kernel.org,
        lars@...afoo.de, Michael.Hennerich@...log.com, jic23@...nel.org,
        linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 1/2] device property: Add fwnode_irq_get_byname()

On Wed, Nov 10, 2021 at 01:38:39AM +0530, Puranjay Mohan wrote:
> The fwnode framework did not have means to obtain the IRQ number from
> the name of a node.
> Add that now, in form of the fwnode_irq_get_byname() function.

...

> +int fwnode_irq_get_byname(struct fwnode_handle *fwnode, const char *name)
> +{
> +	int index;
> +
> +	if (unlikely(!name))
> +		return -EINVAL;

> +	index = fwnode_property_match_string(fwnode, "interrupt-names", name);
> +	if (index < 0)
> +		return index;

It won't work like this. The ACPI table quite likely won't have this in them.
Also it doesn't cover the GPIO interrupts in ACPI case.

> +	return fwnode_irq_get(fwnode, index);

Neither this covers GPIO IRQs.

> +}
> +EXPORT_SYMBOL(fwnode_irq_get_byname);

So, first you need to provide a design for this how ACPI cases can be handled.

Imagine these cases (at least) for _CRS method in ACPI:
  1/ Single GSI

	Interrupt()

  2/ Single GPIO IRQ

	GpioInt()

  3/ Both in different orders
    a)
	Interrupt()
	GpioInt()

    b)
	GpioInt()
	Interrupt()

  4/ Mixed (complicated cases)

	Interrupt()
	Interrupt()
	GpioInt()
	Interrupt()
	GpioInt()

Obvious question, what does the index mean in all these cases?

Next one is, how can we quirk out the platforms with the old ACPI tables
where no properties are provided? For GPIO there is struct acpi_gpio_params
which goes deep into ACPI glue layer.

Luckily, the GPIO IRQ case has already available APIs for indexing and naming
match: acpi_dev_gpio_irq_get_by().

Hence, the main task is to define index in cases like 4 and see what can be
done for the GSI cases.

-- 
With Best Regards,
Andy Shevchenko