linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

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: <20090528054714.GM1464@yookeroo.seuss>
Date:	Thu, 28 May 2009 15:47:14 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	David Miller <davem@...emloft.net>
Cc:	linux@....linux.org.uk, jonsmirl@...il.com,
	devicetree-discuss@...abs.org, linux-kernel@...r.kernel.org,
	timur@...escale.com, scottwood@...escale.com,
	yuan-bo.ye@...orola.com, linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 10:31:47PM -0700, David Miller wrote:
> From: David Gibson <david@...son.dropbear.id.au>
> Date: Thu, 28 May 2009 14:47:32 +1000
> 
> > The conceptual problem becomes apparent when you consider things like
> > i2c.  The devtree is the obvious source to discover what i2c device
> > are present, but they need to be instantiated as i2c devices on the
> > i2c bus, not of platform devices.
> 
> Sure, but there is no reason there can't be an of_platform driver
> for those i2c devices.  And such instantiated devices get propagated
> either instantly to the parent, or later when the parent controller
> probes.

Right, but the point is the bus info is trying to do two things here -
one is to supply stuff that's actually common to the bus interface,
the other is the probing logic.  That's usually connected to the bus
interface, but in the case of non-probeable basses on a system with a
devtree, that's no longer the case.  As soon as the bus has some
common logic that's really related to the bus interface regardless of
platform, then you start losing to use of_platform instead of a
specific bus structure because you have to duplicate that -
essentially having both OF and non-OF variants of however many busses
we need.

I think its saner instead to have the device model stuff only
represent stuff that's actually related to the bus interface, and
separately instantiate things into those busses from an OF tree
traversal.  I think this can be made as convenient as the current
setup for OF systems, though obviously I'll have to get around to
actually implementing it to be sure.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/