linux-kernel - Re: [PATCH] irq_domain: Standardise legacy/linear domain selection

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]

Message-ID: <CAHp75Vesp7KrYvQrNXK=fGOH5y+jk9AMHVJkGyu8o+72F9LSrg@mail.gmail.com>
Date:	Thu, 5 Jul 2012 14:43:42 +0300
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, mathias.nyman@...ux.intel.com,
	mika.westerberg@...ux.intel.com
Subject: Re: [PATCH] irq_domain: Standardise legacy/linear domain selection

On Thu, Jul 5, 2012 at 2:19 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> A large proportion of interrupt controllers that support legacy mappings
> do so because non-DT systems need to use fixed IRQ numbers when registering
> devices via buses but can otherwise use a linear mapping. The interrupt
> controller itself typically is not affected by the mapping used and best
> practice is to use a linear mapping where possible so drivers frequently
> select at runtime depending on if a legacy range has been allocated to
> them.
>
> Standardise this behaviour by providing irq_domain_register_simple() which
> will allocate a linear mapping unless a positive first_irq is provided in
> which case it will fall back to a legacy mapping. This helps make best
> practice for irq_domain adoption clearer.

We have a hardware which doesn't support ACPI nor DT. We had got a nice
issue with irq domains after the gpio driver has been moved to the
linear scheme.
Our internal discussion is roughly about misdesigned irq domains
concept for that
kind of hardware. In generic case we could have more than one PIC, and more than
one hardware that requires real 1:1 mapping of the irq numbers, and
kernel doesn't
know about the last mapping until real driver module is loaded (for
example a PCI
controller of something).

The issue is in plain array of the numbers that are assigned to the devices.
Somehow looks better to have real namespaces, or even hide irq number in the API
struct device, request_irq(), but keep reference between driver and PIC via some
object.

So, given solution just hides an issue, but doesn't resolve it fully
from my p.o.v.

-- 
With Best Regards,
Andy Shevchenko
--
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/