linux-kernel - Re: [PATCH 0/3] capebus moving omap

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: <E08E316D-E7C5-4AFC-8C82-6423E5128FAA@antoniou-consulting.com>
Date:	Thu, 1 Nov 2012 00:00:45 +0200
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Benoit Cousson <b-cousson@...com>, linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org, Kevin Hilman <khilman@...com>,
	Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

Hi Tony,

On Oct 31, 2012, at 11:43 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@...oniou-consulting.com> [121031 14:38]:
>> 
>> There a a whole bunch of conflicting capes. There's no
>> way to instantiate them together. They must be instantiated
>> only after their EEPROMs are read and they are matched
>> to their corresponding cape drivers.
> 
> You don't need to instantiate the capes during __init,
> you need to just instantiate the omap internal devices
> which are always there in the hardware. These internal
> devices just need to be set to state = "disabled" until
> they are used.
> 

If you set the device's node state to disable the device
doesn't get registered; i.e. the device's probe method will not be
called.

The devices are instantiated by the call to 

	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);

in omap_generic_init() (arch/arm/mach-omap2/board-generic.c)

Which for each child of the root node will call of_platform_bus_create
which in turn will call of_platform_device_create_pdata.

First check in there is

       if (!of_device_is_available(np))
                return NULL;

of_device_is_available() will return 0 in any case status is neither
"okay" or "ok".

So when device's node is 'disabled' of_platform_device_create_pdata()
will not create the device.

Now, of course it is possible to re-trigger the platform's probe method
to be called, and in fact I do so in the capebus patches.

Since the bus drives of things like i2c & spi must be disabled if not
used by any cape, they are "disabled" by default, and are activated when
referenced by a cape.

In the file drivers/capebus/capebus-driver.c, there are two functions.

The first, capebus_of_platform_device_enable() will check if the referenced
device node is disabled, and after enabling it (with capebus_of_device_node_enable())
will call of_platform_device_create(), but now this time the instantiation
will be successful.

The problem is that now, we're way past the point in the boot sequence
that omap_build_device has been freed; calling the probe method will now lead
to a crash.

> The capes themselves should not have anything to do
> with omap_hwmod or omap_device, they just contain
> external connectors, regulators, LCD panels etc.
> 
> To your capebus the omap internal devices should look
> like just regular struct device entries.
> 
> Regards,
> 
> Tony

Regards

-- Pantelis

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