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: <8B058B00-6C21-4410-A24B-75651D49F6EC@antoniou-consulting.com>
Date:	Wed, 31 Oct 2012 23:36:25 +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

Tony,

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

> * Pantelis Antoniou <panto@...oniou-consulting.com> [121031 13:14]:
>> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
>>> 
>>> Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control
>>> could have an hwmod and thus must be handled by an omap_device.
>>> 
>>> Any devices that is created later cannot be omap_device. The DT core
>>> will create regular platform_device for them.
>>> 
>>> Since cape is an external board, it should have nothing to do with
>>> omap_device.
>>> 
>>> Looking at your patch:
>>> da8xx-dt: Create da8xx DT adapter device
>>> 
>>> I understand why you do that, but in fact that patch does not make sense
>>> to me :-(
>>> 
>>> Why do you have to create an omap_device from the driver probe?
>>> 
>> 
>> The problem is that capes are not external boards in the normal sense
>> as a PCI board is. In the PCI case the hardware that implements the 
>> desired functionality is on the PCI board, while in the cape case the
>> hardware module is in the SoC. The cape most of the times is quite
>> simple and contains passive components, leds or some kind of I2C/SPI devices.
> 
> Ah now I see, you're talking about the beaglebone extension
> boards :)
> 
> The way to deal with those properly is to just edit the
> board .dts entry to include omap-beaglebone-cape-xyz.dtsi
> whatever.
> 

That is what is being done...
This is the fallout.

>> You can't instantiate the omap_device early in the boot process like it was done up to 
>> now in the board file. You can only do that later in the boot process (for built-in 
>> cape drivers), or even after user-space has booted and the matching cape driver module
>> has been loaded.
> 
> Yes you can, just edit the .dts file for the extension
> board you have connected. This stuff should be DT
> only for sure, let's not even start adding platform_data
> entries for that.
> 
> The omap_device entries for the omap internal devices
> will be created automatically during startup based on the
> .dts. Note that you can set status = "disabled" for the
> omap internal devices in the .dts file, the devices are
> there in the hardware.
> 
> If you are sure the extension boards are safely hot
> pluggable, then all you need is some interface to enable
> and disable devices after booting. But that should be
> done in Linux generic way.
> 
> So we should not export any omap_hwmod or omap_device
> things, and want to keep it __init only, and local to
> arch/arm/mach-omap2.
> 

I disagree. This is not something that is handled by just
editing the dts. The way it is handled, is in the Linux
generic way, we have a proper bus, and the drivers as compiled
as standalone file. 

We're hitting a use case that wasn't there in omap until now.

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.

We don't have a board file anymore where to do i. This is all on
board-generic, getting ready for the one kernel fits all for ARM.

Everything is local to arch/arm/mach-omap2, the only
problem is that __init modifier that's keeping us from
loading the cape drivers as modules.

If you take some time and scan the full patchset you will 
understand why this is the way it is.

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