All of lore.kernel.org
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: DT version of kirkwood_ge0x_init()
Date: Tue, 04 Jun 2013 12:34:42 +0200	[thread overview]
Message-ID: <51ADC2C2.6010106@gmail.com> (raw)
In-Reply-To: <51ADBEE0.5040500@keymile.com>

On 06/04/13 12:18, Gerlando Falauto wrote:
> I noticed how most of the DT-aware board-setup files only have a single
> <board>_init() function, calling kirkwood_ge00_init() with a struct
> mv643xx_eth_platform_data as a single argument.
>
> I was wondering -- is there a reason why we cannot remove all this
> board-specific code and move all this to the DT?

Gerlando,

DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then
move all DT Orion SoCs to it.

 > I would really love to have all our boards under a single
 > CONFIG_<FAMILY>_DT and a single compatible string, with all the
 > differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>,
 > no more of_machine_is_compatible("boardXXX").

All those will happen if there is DT support for mv643xx_eth which
is the only driver left without DT and board dependencies. But there
will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT
and board dependent stuff described in the corresponding dts.

Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Gerlando Falauto
	<gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
	Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	"Longchamp,
	Valentin"
	<Valentin.Longchamp-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	"Brunck,
	Holger" <Holger.Brunck-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>,
	Simon Guinot <simon-jKBdWWKqtFpg9hUCZPvPmw@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: DT version of kirkwood_ge0x_init()
Date: Tue, 04 Jun 2013 12:34:42 +0200	[thread overview]
Message-ID: <51ADC2C2.6010106@gmail.com> (raw)
In-Reply-To: <51ADBEE0.5040500-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>

On 06/04/13 12:18, Gerlando Falauto wrote:
> I noticed how most of the DT-aware board-setup files only have a single
> <board>_init() function, calling kirkwood_ge00_init() with a struct
> mv643xx_eth_platform_data as a single argument.
>
> I was wondering -- is there a reason why we cannot remove all this
> board-specific code and move all this to the DT?

Gerlando,

DT for mv643xx_eth is on the way (https://lkml.org/lkml/2013/5/29/527).
We wait for the driver to surface to relax branch dependencies and then
move all DT Orion SoCs to it.

 > I would really love to have all our boards under a single
 > CONFIG_<FAMILY>_DT and a single compatible string, with all the
 > differences within the DTs itself -- no more #ifdef CONFIG_<BOARD>,
 > no more of_machine_is_compatible("boardXXX").

All those will happen if there is DT support for mv643xx_eth which
is the only driver left without DT and board dependencies. But there
will be no CONFIG_LACIE_DT or whatever, but just CONFIG_KIRKWOOD_DT
and board dependent stuff described in the corresponding dts.

Sebastian

  reply	other threads:[~2013-06-04 10:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 10:18 DT version of kirkwood_ge0x_init() Gerlando Falauto
2013-06-04 10:18 ` Gerlando Falauto
2013-06-04 10:34 ` Sebastian Hesselbarth [this message]
2013-06-04 10:34   ` Sebastian Hesselbarth
2013-06-04 10:43   ` Jason Cooper
2013-06-04 10:43     ` Jason Cooper
2013-06-04 11:59     ` Simon Guinot
2013-06-04 11:59       ` Simon Guinot
2013-06-04 12:05       ` Jason Cooper
2013-06-04 12:05         ` Jason Cooper
2013-06-04 12:18         ` Simon Guinot
2013-06-04 12:18           ` Simon Guinot
2013-06-04 13:10         ` Jason Cooper
2013-06-04 13:10           ` Jason Cooper
2013-06-04 20:53   ` Gerlando Falauto
2013-06-04 20:53     ` Gerlando Falauto
2013-06-05  9:04     ` Sebastian Hesselbarth
2013-06-05  9:04       ` Sebastian Hesselbarth
2013-06-05  9:37       ` Gerlando Falauto
2013-06-05  9:37         ` Gerlando Falauto
2013-06-05  9:45         ` Gregory CLEMENT
2013-06-05  9:45           ` Gregory CLEMENT
2013-06-05  9:49         ` Sebastian Hesselbarth
2013-06-05  9:49           ` Sebastian Hesselbarth
2013-06-05  9:55           ` Gerlando Falauto
2013-06-05  9:55             ` Gerlando Falauto
2013-06-05 13:23       ` Jason Cooper
2013-06-05 13:23         ` Jason Cooper

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=51ADC2C2.6010106@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.