linux-kernel - Re: RFC: Platform data for onboard USB assets

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: <1300859095.2402.339.camel@pasglop>
Date:	Wed, 23 Mar 2011 16:44:55 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	andy.green@...aro.org,
	Jaswinder Singh <jaswinder.singh@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>, arnd@...db.de,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	greg@...ah.com, grant.likely@...retlab.ca
Subject: Re: RFC: Platform data for onboard USB assets

On Wed, 2011-03-23 at 00:21 -0400, Nicolas Pitre wrote:
> 
> I wholeheartedly agree with that idea.  One thing that bothers me about DT 
> is its tendency to show up deep into the guts of kernel code all over 
> the place.  If a generic abstraction can be put in place, such as this 
> get_device_attribute() example, then it is far more convenient to use 
> DT, or _eventually_ use DT, or even _not_ use it in some cases but 
> something else, without battling over the actual interface 

I've always tried to take the approach on powerpc when designing an
important feature such as the virtual IRQ remapping, to make the
device-tree use a "useful add-on" without making it entirely necessary.

To continue on that example, the low level irq_domain (irq_host but
being renamed) only carries the OF pointer as a "token" (I think at some
point I even had it a void *), and the low level APIs for establishing
the mapping between a domain/hw_irq and virq don't rely on any
device-tree bits at all.

However, helpers built on top of that (along with one "translation"
callback in the irq domain itself) provide the device-tree integration
which makes the whole thing a lot easier to use.

But we still use the low level bits in some areas, old machines with 
broken DT, hard wired interrupt numbers coming from firmware, etc...

Cheers,
Ben.

--
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/