All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	linux-iio@vger.kernel.org, guenter.roeck@ericsson.com,
	khali@linux-fr.org, dmitry.torokhov@gmail.com,
	alan@lxorguk.ukuu.org.uk, arnd@arndb.de,
	linus.walleij@linaro.org, maxime.ripard@free-electrons.com,
	thomas.petazzoni@free-electrons.com, zdevai@gmail.com,
	w.sang@pengutronix.de, marek.vasut@gmail.com,
	Jonathan Cameron <jic23@cam.ac.uk>
Subject: Re: [PATCH 1/5] staging:iio:core add in kernel interface mapping and getting IIO channels.
Date: Thu, 9 Feb 2012 11:17:18 -0800	[thread overview]
Message-ID: <20120209191718.GA10999@kroah.com> (raw)
In-Reply-To: <20120209191509.GM3058@opensource.wolfsonmicro.com>

On Thu, Feb 09, 2012 at 07:15:10PM +0000, Mark Brown wrote:
> 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.

Ok, if that's all this is for, they why name it "iio in-kernel logic"?
That made me believe that this is something that is needed if anyone who
happens to want to use the iio interface needs it.

If it's just "iio discovery" then call it that :)

thanks,

greg k-h

  reply	other threads:[~2012-02-09 19:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-29 11:46 [RFC PATCH 0/5 V5] IIO: in kernel pull interfaces Jonathan Cameron
2012-01-29 11:46 ` [PATCH 1/5] staging:iio:core add in kernel interface mapping and getting IIO channels Jonathan Cameron
2012-01-30 20:22   ` Mark Brown
2012-01-30 20:28     ` Jonathan Cameron
2012-02-01 19:58       ` Linus Walleij
2012-02-06 21:30         ` Jonathan Cameron
2012-02-09 18:10   ` Greg KH
2012-02-09 18:34     ` Jonathan Cameron
2012-02-09 18:57       ` Greg KH
2012-02-09 19:15         ` Mark Brown
2012-02-09 19:17           ` Greg KH [this message]
2012-02-09 19:20             ` Mark Brown
2012-02-09 21:20               ` Jonathan Cameron
2012-02-10  1:03                 ` Linus Walleij
2012-01-29 11:46 ` [PATCH 2/5] staging:iio: move iio data return types into types.h for use by inkern Jonathan Cameron
2012-01-29 11:46 ` [PATCH 3/5] staging:iio::hwmon interface client driver Jonathan Cameron
2012-01-29 11:46 ` [PATCH 4/5] staging:iio:Documentation in kernel pull description Jonathan Cameron
2012-01-29 11:46 ` [PATCH 5/5] stargate2: example of map configuration for iio to hwmon example Jonathan Cameron
2012-01-30 19:33   ` Mark Brown
2012-01-30 20:26     ` Jonathan Cameron
2012-01-30 21:22       ` Mark Brown
2012-01-30 21:48         ` Jonathan Cameron
2012-01-31  8:39         ` Linus Walleij
2012-01-31 11:09           ` Mark Brown
2012-01-30 19:28 ` [RFC PATCH 0/5 V5] IIO: in kernel pull interfaces Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120209191718.GA10999@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=guenter.roeck@ericsson.com \
    --cc=jic23@cam.ac.uk \
    --cc=jic23@kernel.org \
    --cc=khali@linux-fr.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=w.sang@pengutronix.de \
    --cc=zdevai@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.