Re: [PATCH 1/5] staging:iio:core add in kernel interface mapping and getting IIO channels.

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

On Thu, Feb 09, 2012 at 10:57:54AM -0800, Greg KH wrote:

> So, would the "keep looping until all dependancies are met" patches from
> Grant that have been floating around for a while, solve this issue?
> Modules would properly initialize only when the needed other bits are
> present, which solves the problems the regulators and other drivers have
> today.

> If so, then I suggest we get that code into the tree soon, and then all
> of this "wierd" logic would go away, right?

Could you identify the logic you're talking about here?  Looking at the
last patch set I can find[1] this all looks very vanilla for this sort of
subsystem?  You've got a mapping mechanism and a get function but that's
about it which is all pretty normal.  Grant's changes make module
probing nicer in that you don't need to worry about the order in which
things get registered but I can't see anything here which is
particularly related to that ordering.

All the code is doing is providing a mechanism for drivers that need IIO
facilities to locate the thing that's providing their IIO facilities
(which is in the general case going to be board specific on a totally
unrelated chip in a different part of the system and discovered through
reading the schematic) without requiring custom code in every single
single IIO using device to do the mapping.  Instead the boards use a
standard subsystem facility to tell the IIO core what's wired where and
then the core matches things up for them.

This is nothing to do with init ordering, it's all about the two devices
finding each other at all.

[1] http://article.gmane.org/gmane.linux.kernel.iio/3287

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]