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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 16 Aug 2011 15:37:28 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Kenneth Heitke <kheitke@...eaurora.org>, davidb@...eaurora.org,
	bryanh@...eaurora.org, linux-arm-msm@...r.kernel.org,
	Sagar Dharia <sdharia@...eaurora.org>, rdunlap@...otime.net,
	rmk+kernel@....linux.org.uk, john.stultz@...aro.org,
	akpm@...ux-foundation.org, ohad@...ery.com, gregkh@...e.de,
	stefanr@...6.in-berlin.de, lethal@...ux-sh.org,
	linville@...driver.com, zajec5@...il.com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

On Friday 12 August 2011, Mark Brown wrote:
> On Thu, Aug 11, 2011 at 02:55:55PM +0200, Arnd Bergmann wrote:
> > On Thursday 11 August 2011, Kenneth Heitke wrote:
> 
> > > +EXPORT_SYMBOL_GPL(slim_add_device);
> 
> > I don't think this should be exported: AFAICT, the set of slim_devices
> > is a property of the platform, so I don't see how any other device driver
> > would add another device.
> 
> The platform may be comprised of multiple hardwaare modules with
> functionality on daughtercards which can be probed at runtime.  You may
> also find someone constructing a PCI card or something with a slimbus
> controller on it at some point.

This is theoretically true, but IIRC David mentioned that the bus is
only present on few SoCs and has since been abandoned in favor of standard
busses for new devices.

> > > +EXPORT_SYMBOL_GPL(slim_register_board_info);
> 
> > We are trying to gradually convert platforms that have hardcoded device
> > lists and cannot probe devices by looking at the hardware over to using
> > device tree files that list all the devices.
> 
> > I think that this would work well for slimbus and should be done
> > right from the start. This means however that you should not
> > register a "board_info" but instead change the slim_register_controller
> > function so that it adds all devices listed as children of the
> > controller in the device tree.
> 
> It seems a bit extreme to prevent anyone implementing a subsystem for
> their platform until they've converted it into device tree.  Though with
> slimbus it should be at least somewhat probeable IIRC?

>From what I've heard (and seen in the code), there is no support for
probing, just like in I2C.
The platform is in the process of getting converted to device tree
already, the first patches were posted on Saturday. I don't know what
the timeline is for this, or how many board with slimbus are supported
in mainline or still waiting to get merged, but my guess is that the
bulk is still out of tree. If that's true, it's definitely cleaner to
convert it over to device tree before merging, instead of having to
change all the board files again when doing the conversion.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ