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] [day] [month] [year] [list]
Date:	Tue, 19 Nov 2013 21:34:09 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Grygorii Strashko <grygorii.strashko@...com>
Cc:	Prabhakar Lad <prabhakar.csengg@...il.com>,
	Sekhar Nori <nsekhar@...com>,
	LKML <linux-kernel@...r.kernel.org>,
	DLOS <davinci-linux-open-source@...ux.davincidsp.com>,
	LAK <linux-arm-kernel@...ts.infradead.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Landley <rob@...dley.net>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH v5 3/7] gpio: davinci: use irqdomain

On Tue, Nov 19, 2013 at 5:22 PM, Grygorii Strashko
<grygorii.strashko@...com> wrote:
> On 11/19/2013 01:06 AM, Linus Walleij wrote:

>> The problem that appear is if someone is using platform data-provided
>> IRQs off the irq_chip without calling gpio_to_irq() on the GPIO line
>> first. This has been determined to be legal to do, so preferably
>> create the map when registering the lines.
>
> Ok, I understand. It may fail in case if someone will define/calculate
>  IRQ number for device manually in board code, like:
>  dev_irq = (DA850_N_CP_INTC_IRQ + gpioN)

Usually people just hardcode the IRQ value or use some
#define, like they have often also done with GPIO numbers ...

> Also, looks like It is possible to fail if Main/arch IRQ controller
> code doesn't make call of irq_alloc_descs() during init, so
> allocated_irqs will be empty.

If you use irq_domain_add_simple() the irqdomain core
will actually attempt to do this.

But if you use a linear domain, you have to create these
irqdescs as you go. The simplest way to do this is to call
irq_create_mapping() on all IRQs, because that call will
also allocate some descriptor.

> Before recommending that, I've checked Davinci platform code and didn't
> find any risk places - BUT, Seems my findings need to be confirmed by
> Sekhar.

It's no big deal, but I just want you to be aware that this
may cause a problem at some point.

>> I think you should try to keep the 5 irqdomains, but whatever
>> gives the simplest code is usually the right answer, and
>> divide-and-conquer (split down the problem) is usually a good
>> idea.
>>
>> How the GPIO block(s) are represented in the device tree is
>> another totally separate issue about hardware description,
>> do not let the device tree model your driver structure.
>
>
> Thanks for you comments, but looks like I have to be more specific :)
>
> How irq_find_host() will look for proper IRQ domain in our case?
> And will it work at all, taking into account that all (5) IRQ domains
> will have the same value of "of_node" property?
> of_irq_to_resource()
> |-irq_of_parse_and_map()
>   |-irq_create_of_mapping()
>     |-irq_find_host(irq_data->np)
>  where np will point on GPIO node.
>
> As result my question is about what do DT core frameworks allow or not
> allow to do? And according to that implementation of driver can be
> changed.

Hm, I'm not like a super-expert on the interrupt core, but maybe
you need to create subnodes inside the top node to represent this,
then use of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
to populate them from the main node.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ