linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>,
	devicetree-discuss@lists.ozlabs.org,
	Stephen Warren <swarren@nvidia.com>,
	Wolfram Sang <w.sang@pengutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	STEricsson_nomadik_linux@list.st.com,
	linus.walleij@stericsson.com, arnd@arndb.de,
	linux-i2c@vger.kernel.org
Subject: Re: [PATCH 3/3] i2c: nomadik: Add Device Tree support to the Nomadik I2C driver
Date: Mon, 3 Sep 2012 15:19:13 +0200	[thread overview]
Message-ID: <CACRpkdZvWkH2gQQuNvCkNuB-faT8qHAjyiULSqPKrn+FCktvLg@mail.gmail.com> (raw)
In-Reply-To: <20120903123424.GA31163@gmail.com>

On Mon, Sep 3, 2012 at 2:34 PM, Lee Jones <lee.jones@linaro.org> wrote:

> When booting DT booting take a different path and no platform data
> is passed. We can't boot DT AND register devices with platform data
> or else we will double probe every device. The only way to pass
> pdata when booting with DT is with AUX_DATA() and that's a hack to
> get around things we don't have support for yet. Up until now that
> has been DMA bindings, clock and pinctrl names and call-backs.

So if we pass some augmented platform data using AUX_DATA()
that appears as pdata in this case, and gets discarded.

Thus we cannot use AUX_DATA() to override a broken, as in
"the interrupt number is wrong" device tree.

> If DT is corrupt or missing the kernel will boot using platform
> data, but np will always be NULL, so we don't have the problem you
> were alluding to above.

That was not the problem I had in mind.

I had a valid, but incorrect device tree in mind. I.e the device
is there, but with wrong base address, or wrong IRQ number.

If pdata takes precedence, we can use AUX_DATA() to
override such errors from the platform, since drivers/of/platform.c
helpfully pokes in the auxdata as the platform data.
I thought this was one of the reasons why auxdata exist
at all.

Or is the proper solution to runtime-patch the device tree
per se in such cases? How is that actually done then?

Yours,
Linus Walleij

  reply	other threads:[~2012-09-03 13:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 15:01 [PATCH 1/3] ARM: ux500: Add i2c configurations to the Device Tree for DB8500 based devices Lee Jones
2012-08-23 15:01 ` [PATCH 2/3] Documentation: Device Tree binding information for i2c-nomadik driver Lee Jones
2012-08-23 15:01 ` [PATCH 3/3] i2c: nomadik: Add Device Tree support to the Nomadik I2C driver Lee Jones
2012-08-27 23:42   ` Linus Walleij
2012-08-31 10:36     ` Lee Jones
2012-08-31 11:22   ` Wolfram Sang
2012-08-31 12:04     ` Lee Jones
2012-08-31 12:23     ` Lee Jones
2012-09-03  9:22       ` Linus Walleij
2012-09-03  9:44         ` Wolfram Sang
2012-09-03  9:50           ` Lee Jones
2012-09-03 10:07           ` Lee Jones
2012-09-03 11:07             ` Linus Walleij
     [not found]               ` <CAF2Aj3j25w1Nn9O6hV+=i-j1ts_p_Ucswk_M7r04S7i5BzPkHg@mail.gmail.com>
2012-09-03 11:58                 ` Linus Walleij
2012-09-03 12:34                   ` Lee Jones
2012-09-03 13:19                     ` Linus Walleij [this message]
2012-09-03 13:28                       ` Lee Jones
2012-09-03 14:33                   ` Stephen Warren
2012-09-03 14:35                     ` Linus Walleij
2012-09-03 15:09                       ` Rob Herring
2012-09-03 15:20                         ` Lee Jones
2012-09-04 14:28                           ` Arnd Bergmann
2012-09-04 17:27                             ` Linus Walleij
2012-09-05  6:41                               ` Lee Jones
2012-09-05  6:53                                 ` Linus Walleij
2012-09-04 17:35                             ` Alessandro Rubini
2012-09-05  7:33     ` Lee Jones
2012-09-05  8:22       ` 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=CACRpkdZvWkH2gQQuNvCkNuB-faT8qHAjyiULSqPKrn+FCktvLg@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=STEricsson_nomadik_linux@list.st.com \
    --cc=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@nvidia.com \
    --cc=w.sang@pengutronix.de \
    /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 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).