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, 17 Aug 2011 00:23:34 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
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 Tue, Aug 16, 2011 at 03:37:28PM +0200, Arnd Bergmann wrote:
> On Friday 12 August 2011, Mark Brown wrote:

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

No, that's not the case at all - I'm not sure what gave you that
impression.  This is new technology which is rolling out at the minute.
It is a standard bus.

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

That's what the code does, yes.  I'd need to recheck the spec but I do
seem to recall some device IDs in there.

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

That's one platform, this is not at all constructive for other devices
(or worse, architectures) implementing slimbus support.  Insisting that
new ARM platforms use device tree is one thing, insisting that new bus
implementations only work with device tree is quite a different thing.
--
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