linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hao <haokexin@gmail.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 3/5] of/platform: introduce a generic way to declare a platform bus
Date: Sat, 27 Aug 2016 15:40:13 +0800	[thread overview]
Message-ID: <20160827074012.GA28370@pek-khao-d1> (raw)
In-Reply-To: <CAL_JsqK42T1M3MO26p46K0zTuvGUAdMWAf4FHGVpAJgDa+SudQ@mail.gmail.com>

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

On Thu, Aug 25, 2016 at 08:44:56AM -0500, Rob Herring wrote:
> On Mon, Aug 22, 2016 at 9:06 PM, Kevin Hao <haokexin@gmail.com> wrote:
> > The specific buses which need to be probed at boot time are different
> > between platforms. Instead of put all the buses into the default
> > of_default_bus_match_table[] match tables, this patch introduces a
> > general way to declare a platform bus.
> 
> I'd prefer to not do this with linker sections if possible. Doesn't
> PPC have machine descriptors that you could add the match table to? If
> that table exists then arch_want_default_of_probe could return a
> pointer to it.

Hmm, I thought about adding a match table in ppc_md. But it is very arch
specific. I thought maybe other archs also need to probe some arch or even
board specific bus, so I introduces these arch independent macros and wish
it may be useful for other archs. :-)

> 
> Are there any platforms that work with the default match table?

Yes, some boards can work with the default match table. But most won't.

> I'd be
> fine with adding some strings to the default if that helps.
> 
> { .type = "soc", },
> 
> device_type is deprecated for FDT, so this shouldn't be needed except
> for really old stuff.
> 
> { .compatible = "soc", },
> 
> Doesn't appear in kernel dts files. Could be out of tree or old ones?
> 
> { .compatible = "simple-bus" },
> 
> Already handled.
> 
> { .compatible = "gianfar" },
> 
> Seems like the children of this should be probed by the gianfar driver.
> 
> { .compatible = "gpio-leds", },
> 
> I don't think this is needed.
> 
> { .type = "qe", },
> 
> Again, deprecated.
> 
> { .compatible = "fsl,qe", },
> 
> No issue to add this. Though, you could also probe it from mpc85xx_qe_init().

Do you mean we put all the probe of the specific bus into the corresponding
drivers? Yes, if we do so, we probably can shrink the default match table to
be something like this:
	{ .compatible = "soc", },
	{ .compatible = "simple-bus" },

OK, now we have three options to fix this issue:
a) Create a separate link section to contain all the buses needed to be probed.
   Just as what this patch does.

b) Put the match table into the machine descriptor.

c) Sprinkle the probe of all the specific bus into the corresponding driver
   (such as gian, pcie controller) and the default probe function only handle
   the very common buses.

So what option do you guys think is best?

Thanks,
Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-08-27  7:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  2:06 [PATCH 0/5] ppc32: use the default of_platform_default_populate_init() for 83xx boards Kevin Hao
2016-08-23  2:06 ` [PATCH 1/5] of/platform: introduce arch_want_default_of_probe() Kevin Hao
2016-08-23  2:06 ` [PATCH 2/5] powerpc: introduce arch_enable_default_of_probe() Kevin Hao
2016-08-23  2:06 ` [PATCH 3/5] of/platform: introduce a generic way to declare a platform bus Kevin Hao
2016-08-25 13:44   ` Rob Herring
2016-08-27  7:40     ` Kevin Hao [this message]
2016-08-23  2:06 ` [PATCH 4/5] powerpc/83xx: factor out the common codes of setup arch functions Kevin Hao
2016-08-23  2:06 ` [PATCH 5/5] powerpc/83xx: enable the default of probe Kevin Hao

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=20160827074012.GA28370@pek-khao-d1 \
    --to=haokexin@gmail.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=robh+dt@kernel.org \
    /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).