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]

Date:	Wed, 31 Oct 2012 11:09:36 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
Cc:	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, "Cousson, Benoit" <b-cousson@...com>,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

* Pantelis Antoniou <panto@...oniou-consulting.com> [121031 11:05]:
> Hi Tony,
> 
> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote:
> 
> > * Pantelis Antoniou <panto@...oniou-consulting.com> [121031 10:26]:
> >> It is painless to move the adapter DT devices to arch/arm/mach-omap2
> >> 
> >> However I got bit by the __init at omap_build_device family functions.
> >> If you don't remove it, crashes every time you instantiate a device
> >> at runtime, or you load the cape driver as a module.
> > 
> > Hmm I think you misunderstood me. You only need to create the
> > platform_device under arch/arm/mach-omap2. The device creation
> > happens only at __init, so omap_build_device can stay as __init.
> > The driver itself should be under drivers.
> > 
> > But is this bus on non-device-tree omaps? If not, just make it
> > device tree only.
> > 
> 
> I'm afraid that's not the case. The whole notion of capebus is that
> instantiation of the devices doesn't just happen early at the boot
> sequence.
> 
> It is perfectly valid for a cape to be instantiated via loading
> a module, or by making an override by writing a sysfs file.
> 
> When having the __init there, the function has been long removed
> and you get a crash by calling into the weeds.
> 
> So the sequence is:
> 
> <early boot>       Register the adapter driver.

OK this is always there for the hardware, and done during
the __init and this one should have an omap_device..
 
> <user>             insmod bone-geiger-cape
> <cape-is-matched>  call omap_build_device
> 
> Please look into the capebus patches for the details. 

..but it seems that the devices connected to capebus should
not have anything to do with omap_device and hwmod?

They should only need to use capebus, just like USB devices
use the USB bus and are registered as USB devices.

Anyways, please sort it out with Benoit, Kevin and Paul,
I've added them to cc. Maybe I'm missing something here.

Regards,

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