linux-kernel - Re: [sodaville] [PATCH 03/11] x86/dtb: Add a device tree for CE4100

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:	Tue, 30 Nov 2010 07:14:34 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Mitch Bradley <wmb@...mworks.com>, sodaville@...utronix.de,
	devicetree-discuss@...ts.ozlabs.org, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [sodaville] [PATCH 03/11] x86/dtb: Add a device tree for CE4100

On Mon, 2010-11-29 at 20:36 +0100, Sebastian Andrzej Siewior wrote:
> 
> This also works with the flat tree, right?

Yes, of course. You use similar references in your interrupt-map :-)

> Okay, so we want this for a quirk at a later point in time. Now I
> understand.

More precisely, if something has to depend on a specific
revision/errata/feature, in the future, it would be problematic to have
to modify the device-tree.

The "rule" for compatible is to be a list going from a reasonably
precise description of the specific device to the more generic
programming interface the device implements.

> Would "isa-bridge" be acceptable? So I don't have to add a new bus to
> the probe list for every new SoC.

Just call it 'isa', as for device_type, we shouldn't need it.

The default "probe list" is crap. If you want to have platform devices
instanciated for the ISA devices from the device-tree, I'd rather you
explicitely do it from the architecture code. As Scott said, "isa"
doesn't quite qualify as a "generic" simple bus.

> Yes. of_address_to_resource() will do the right thing in this case. It
> can only be used after unflatten_device_tree() and I need this
> earlier.

This probably means you are doing the unflattening too late...

> Now using unflatten_device_tree() earlier isn't that easy, or is it.
> I defered the ioapic init a little, so it is now called from
> x86_init.mpparse.get_smp_config() so I have alloc_bootmem() working.

You can probably do the unflattening way before alloc_bootmem is
available.

The unflattening does a first pass to scan for the size, so all you need
is a way to get a single contiguous chunk of memory, I'm sure x86 has
ways to provide that sort of thing really early before bootmem is
initialized (what about memblock btw ?).

> So unflatten_device_tree() seems to work here. The ugly part comes
> now:
> early_init_dt_alloc_memory_arch() expects u64 which works with
> phys_to_virt() and the other way around. This isn't really the case
> with
> what __alloc_bootmem(). This looks like phys_map to me. Since the dtb
> code
> simply uses phys_to_virt() it doesn't really matter. So it works and
> I 
> probably can use of_address_to_resource().

Yeah just __pa what alloc_bootmem returns but as I said, it should
probably be unflattened earlier than that.

Peter (CC) should be able to help finding the right spot/API there.

Cheers,
Ben.

> > Cheers,
> > Ben.
> 
> Sebastian
> --
> 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/ 

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