LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: avorontsov@ru.mvista.com
Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org, i2c@lm-sensors.org,
	Jean Delvare <khali@linux-fr.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
Date: Wed, 22 Oct 2008 22:19:03 -0700	[thread overview]
Message-ID: <200810222219.04768.david-b@pacbell.net> (raw)
In-Reply-To: <20081022222940.GA14636@oksana.dev.rtsoft.ru>

On Wednesday 22 October 2008, Anton Vorontsov wrote:
> > 
> > So have it live in the __init text section...
> 
> Won't work, unfortunately. I2C devices are created by the
> i2c controllers, via drivers/of_i2c.c  of_register_i2c_devices().

And I'm pointing out a way to have the normal I2C core code
flow do that creation.  OF shouldn't need to be so much of a
special case.


> There is a good reason to do so, the code needs to know
> controller's OF node to walk down and register the child nodes
> (devices). See drivers/i2c/busses/i2c-mpc.c -- it calls
> of_register_i2c_devices() at the end of the probe().

I don't get it.  (But then, so much of the OF support seems
needlessly convoluted to me ... on top of seeming to be
insufficient for configuring board-specific details.)

There's an OF device tree, distinct from the Linux driver
model tree.  Why should there be any obstacle to accessing
records from that tree before the relevant driver model nodes
have been created?  Remember that the various board_info
structs get registered before the driver model nodes for
which they are templates.  Just translate the OF tree data
to those templates(*), then register them.

I understand that it's currently structured differetnly
than that ... consulting the OF tree "late" not early.
But that's still newish, and from what I've heard so far
it doesn't seem like the best structure either... nothing
seems to plug in smoothly.

- Dave

(*) The role of the board_info structs is very similar
    to the role of OF device attributes.  As is the role
    of the platform_data ... except that's more specific
    to the chip involved (and its driver), and expects
    any callbacks to be in C code not FORTH.

  reply	other threads:[~2008-10-23  5:19 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16 17:12 [PATCH 0/7 RFC] Handle I2C GPIO controllers with the OF (was: pca9539 I2C gpio expander) Anton Vorontsov
2008-10-16 17:12 ` [PATCH 1/7] powerpc and sparc: introduce dev_archdata node accessors Anton Vorontsov
2008-10-16 22:36   ` David Miller
2008-10-16 23:02     ` Grant Likely
2008-10-16 17:12 ` [PATCH 2/7] i2c: add info->archdata field Anton Vorontsov
2008-10-17  9:21   ` Jean Delvare
2008-10-22  0:27     ` Benjamin Herrenschmidt
2008-10-22  6:50       ` Jean Delvare
2008-10-22  7:37         ` Benjamin Herrenschmidt
2008-10-22 10:08           ` Anton Vorontsov
2008-10-22 11:07             ` Jean Delvare
2008-10-22 12:50               ` Anton Vorontsov
2008-10-16 17:12 ` [PATCH 3/7] of: fill the archdata for I2C devices Anton Vorontsov
2008-10-22  4:14   ` Grant Likely
2008-10-16 17:12 ` [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls Anton Vorontsov
2008-10-17 20:24   ` David Brownell
2008-10-17 21:29     ` Anton Vorontsov
2008-10-20  7:29       ` David Brownell
2008-10-20 15:48         ` Anton Vorontsov
2008-10-22  0:29           ` Benjamin Herrenschmidt
2008-10-22  1:03             ` Anton Vorontsov
2008-10-22  1:42               ` Anton Vorontsov
2008-10-22  2:28                 ` Benjamin Herrenschmidt
2008-10-22  4:20                   ` Grant Likely
2008-10-22  4:22                   ` David Brownell
2008-10-22 10:36                     ` Anton Vorontsov
2008-10-22 10:46                       ` Anton Vorontsov
2008-10-22 18:32                         ` Anton Vorontsov
2008-10-22 21:04                           ` David Brownell
2008-10-22 21:22                             ` Anton Vorontsov
2008-10-22 21:52                               ` David Brownell
2008-10-22 22:29                                 ` Anton Vorontsov
2008-10-23  5:19                                   ` David Brownell [this message]
2008-10-23  4:45                             ` Benjamin Herrenschmidt
2008-10-23  6:06                               ` David Brownell
2008-10-23  6:15                           ` David Brownell
2008-10-28 17:45                         ` [PATCH 0/6 RFC] OF-glue devices for I2C/SPI (was: " Anton Vorontsov
2008-10-28 17:46                           ` [PATCH 1/6] of/base: Add new helper of_should_create_pdev() Anton Vorontsov
2008-10-28 17:46                           ` [PATCH 2/6] of/of_i2c: implement of_{,un}register_i2c_device Anton Vorontsov
2008-10-28 17:46                           ` [PATCH 3/6] of/of_i2c: add support for dedicated OF I2C devices Anton Vorontsov
2008-10-28 18:41                             ` David Miller
2008-10-28 17:46                           ` [PATCH 4/6] of/gpio: add support for two-stage registration for the of_gpio_chips Anton Vorontsov
2008-10-28 17:46                           ` [PATCH 5/6] gpio/pca953x: pass gpio_chip pointer to the setup/teardown callbacks Anton Vorontsov
2008-10-28 17:46                           ` [PATCH 6/6] gpio: OpenFirmware bindings for the pca953x Anton Vorontsov
2008-10-28 17:53                           ` [PATCH 0/6 RFC] OF-glue devices for I2C/SPI (was: Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls Grant Likely
2008-10-22  2:27               ` Benjamin Herrenschmidt
2008-10-16 17:13 ` [PATCH 5/7] of/gpio: implement of_dev_gpiochip_{add,remove} calls Anton Vorontsov
2008-10-17 20:25   ` David Brownell
2008-10-17 21:13     ` Anton Vorontsov
2008-10-16 17:13 ` [PATCH 6/7] gpio/pca953x: convert to dev_gpiochip_add and make it work with the OF Anton Vorontsov
2008-10-16 17:13 ` [PATCH 7/7] i2c/mcu_mpc8349emitx: convert to the new I2C/OF/GPIO infrastructure Anton Vorontsov
2008-10-17 16:07 ` [PATCH 0/7 RFC] Handle I2C GPIO controllers with the OF (was: pca9539 I2C gpio expander) Steven A. Falco

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=200810222219.04768.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=avorontsov@ru.mvista.com \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=i2c@lm-sensors.org \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --subject='Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).