DT version of kirkwood_ge0x_init()

DT version of kirkwood_ge0x_init()

[Gerlando Falauto]

Hi everyone,

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?

I noticed how NS2 can somehow trick this value depeding on the 
compatible string, so I assume it's not really *THAT* early, as the 
whole DT infrastructure is already available:

	if (of_machine_is_compatible("lacie,cloudbox") ||
	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
	    of_machine_is_compatible("lacie,netspace_mini_v2"))
		ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
	kirkwood_ge00_init(&ns2_ge00_data);

I guess we could remove a lot of board-specific code if we could move 
this last bit of information to the DT.
Unless compatibility with existing DTs is an issue -- but what about new 
boards?

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").

Any feedback (swearwords included -- in case I'm talking non-sense) 
would be more than welcome.

Thank you!
Gerlando

DT version of kirkwood_ge0x_init()

[Sebastian Hesselbarth]

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

DT version of kirkwood_ge0x_init()

[Jason Cooper]

On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote:
> 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.

Gerlando,

Yes, the mess you describe is temporary.  Those board files used to have
a lot more code in them, legacy init of partitions, MPP, LEDs, etc.  As
we have converted drivers, they have gotten smaller and smaller.

Now, with Sebastian's hard work, we'll finally be able to remove them
and kirkwood will be completely DT.  We're very excited about this. :)

Next, we'll move the Marvell DT boards over to mach-mvebu/ and only
legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will
remain.  After a few releases we will deprecate any legacy boards which
haven't been converted to DT.

thx,

Jason.

DT version of kirkwood_ge0x_init()

[Simon Guinot]

On Tue, Jun 04, 2013 at 06:43:02AM -0400, Jason Cooper wrote:
> On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote:
> > 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.
> 
> Gerlando,
> 
> Yes, the mess you describe is temporary.  Those board files used to have
> a lot more code in them, legacy init of partitions, MPP, LEDs, etc.  As
> we have converted drivers, they have gotten smaller and smaller.
> 
> Now, with Sebastian's hard work, we'll finally be able to remove them
> and kirkwood will be completely DT.  We're very excited about this. :)
> 
> Next, we'll move the Marvell DT boards over to mach-mvebu/ and only
> legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will
> remain.  After a few releases we will deprecate any legacy boards which
> haven't been converted to DT.

Hi Jason,

While I have obviously planed to convert all the LaCie boards to DT,
I think that removing the legacy support so quickly is a little bit
harsh.

IMHO, it could be nice to wait the end-of-life for all this products
before removing their support.

Regards,

Simon

> 
> thx,
> 
> Jason.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130604/957339ae/attachment.sig>

DT version of kirkwood_ge0x_init()

[Jason Cooper]

On Tue, Jun 04, 2013 at 01:59:27PM +0200, Simon Guinot wrote:
> On Tue, Jun 04, 2013 at 06:43:02AM -0400, Jason Cooper wrote:
> > On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote:
> > > 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.
> > 
> > Gerlando,
> > 
> > Yes, the mess you describe is temporary.  Those board files used to have
> > a lot more code in them, legacy init of partitions, MPP, LEDs, etc.  As
> > we have converted drivers, they have gotten smaller and smaller.
> > 
> > Now, with Sebastian's hard work, we'll finally be able to remove them
> > and kirkwood will be completely DT.  We're very excited about this. :)
> > 
> > Next, we'll move the Marvell DT boards over to mach-mvebu/ and only
> > legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will
> > remain.  After a few releases we will deprecate any legacy boards which
> > haven't been converted to DT.
> 
> Hi Jason,
> 
> While I have obviously planed to convert all the LaCie boards to DT,
> I think that removing the legacy support so quickly is a little bit
> harsh.

Yeah, my wording might not have been the best.  See below.

> IMHO, it could be nice to wait the end-of-life for all this products
> before removing their support.

I'd prefer to convert them to DT, then keep them as long as folks are
interested in them.  If no one cares about a board, and no one wants to
convert it to DT or test the conversion, why keep it around?

Let me clarify, by 'deprecate them' I meant *begin* the process of
deprecating them.  eg marking them as deprecated for around three
releases or so.

thx,

Jason.

DT version of kirkwood_ge0x_init()

[Simon Guinot]

On Tue, Jun 04, 2013 at 08:05:00AM -0400, Jason Cooper wrote:
> On Tue, Jun 04, 2013 at 01:59:27PM +0200, Simon Guinot wrote:
> > On Tue, Jun 04, 2013 at 06:43:02AM -0400, Jason Cooper wrote:
> > > On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote:
> > > > 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.
> > > 
> > > Gerlando,
> > > 
> > > Yes, the mess you describe is temporary.  Those board files used to have
> > > a lot more code in them, legacy init of partitions, MPP, LEDs, etc.  As
> > > we have converted drivers, they have gotten smaller and smaller.
> > > 
> > > Now, with Sebastian's hard work, we'll finally be able to remove them
> > > and kirkwood will be completely DT.  We're very excited about this. :)
> > > 
> > > Next, we'll move the Marvell DT boards over to mach-mvebu/ and only
> > > legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will
> > > remain.  After a few releases we will deprecate any legacy boards which
> > > haven't been converted to DT.
> > 
> > Hi Jason,
> > 
> > While I have obviously planed to convert all the LaCie boards to DT,
> > I think that removing the legacy support so quickly is a little bit
> > harsh.
> 
> Yeah, my wording might not have been the best.  See below.
> 
> > IMHO, it could be nice to wait the end-of-life for all this products
> > before removing their support.
> 
> I'd prefer to convert them to DT, then keep them as long as folks are
> interested in them.  If no one cares about a board, and no one wants to
> convert it to DT or test the conversion, why keep it around?
> 
> Let me clarify, by 'deprecate them' I meant *begin* the process of
> deprecating them.  eg marking them as deprecated for around three
> releases or so.

OK. Thanks for the clarifications.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130604/0305b17c/attachment.sig>

DT version of kirkwood_ge0x_init()

[Jason Cooper]

On Tue, Jun 04, 2013 at 08:05:00AM -0400, Jason Cooper wrote:
> On Tue, Jun 04, 2013 at 01:59:27PM +0200, Simon Guinot wrote:
> > On Tue, Jun 04, 2013 at 06:43:02AM -0400, Jason Cooper wrote:
> > > On Tue, Jun 04, 2013 at 12:34:42PM +0200, Sebastian Hesselbarth wrote:
> > > > 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.
> > > 
> > > Gerlando,
> > > 
> > > Yes, the mess you describe is temporary.  Those board files used to have
> > > a lot more code in them, legacy init of partitions, MPP, LEDs, etc.  As
> > > we have converted drivers, they have gotten smaller and smaller.
> > > 
> > > Now, with Sebastian's hard work, we'll finally be able to remove them
> > > and kirkwood will be completely DT.  We're very excited about this. :)
> > > 
> > > Next, we'll move the Marvell DT boards over to mach-mvebu/ and only
> > > legacy boards in -kirkwood/, -orion5x/, -dove/, and -mv78xx0/ will
> > > remain.  After a few releases we will deprecate any legacy boards which
> > > haven't been converted to DT.
> > 
> > Hi Jason,
> > 
> > While I have obviously planed to convert all the LaCie boards to DT,
> > I think that removing the legacy support so quickly is a little bit
> > harsh.
> 
> Yeah, my wording might not have been the best.  See below.
> 
> > IMHO, it could be nice to wait the end-of-life for all this products
> > before removing their support.
> 
> I'd prefer to convert them to DT, then keep them as long as folks are
> interested in them.  If no one cares about a board, and no one wants to
> convert it to DT or test the conversion, why keep it around?
> 
> Let me clarify, by 'deprecate them' I meant *begin* the process of
> deprecating them.  eg marking them as deprecated for around three
> releases or so.

And, now that I've had some coffee, I should also mention that any
boards that are removed can always be brought back by reverting the
commit.  Sometimes people don't complain until it outright disappears
;-)

Heads up:  complain = "volunteer to convert to DT"

thx,

Jason.

DT version of kirkwood_ge0x_init()

[Gerlando Falauto]

Hi Sebastian,

thanks for your answer and your hard work about this whole cleanup.

Two more questions though -- the whole pulling sequence and the 
mainlining process is still very confusing to me so I really have no 
idea where to look or what to expect.

1) Has this been pulled somewhere? You provided a pointer to the LKML 
but I assume this would pop up by way of an -arm tree... is that right?
I'd like to start using that.

2) About my old fixes for the IRQ conflicts on Kirkwood, I saw that 
Thomas Gleixner's rework was pulled into the "tip" tree, but that's more 
genirq related. Did you (or anyone else) also follow up on that and make 
the changes for Kirkwood in order to enable the separate mask registers? 
I'd like to test that (that's actually why I started looking at recent 
kernels with FDT support to begin with).
Or shall I just follow Thomas' proof of concept on irq-sun4i and do the 
same for Kirkwood?

Sorry, I am really more than lost when it's about tracking 
how/where/when changes are pulled. Any "mainlining for dummies" pointer 
would be more than appreciated.

Thank you,
Gerlando

On 06/04/2013 12:34 PM, Sebastian Hesselbarth wrote:
> 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
>

DT version of kirkwood_ge0x_init()

[Sebastian Hesselbarth]

On 06/04/13 22:53, Gerlando Falauto wrote:
> thanks for your answer and your hard work about this whole cleanup.
>
> Two more questions though -- the whole pulling sequence and the
> mainlining process is still very confusing to me so I really have no
> idea where to look or what to expect.
>
> 1) Has this been pulled somewhere? You provided a pointer to the LKML
> but I assume this would pop up by way of an -arm tree... is that right?
> I'd like to start using that.

mv643xx_eth DT support (i.e. Patches 1-6 of that patch set) have been
pulled into net-next by David Miller. The rest will be pulled by Jason
Cooper as soon as net-next goes into mainline linux.

> 2) About my old fixes for the IRQ conflicts on Kirkwood, I saw that
> Thomas Gleixner's rework was pulled into the "tip" tree, but that's more
> genirq related. Did you (or anyone else) also follow up on that and make
> the changes for Kirkwood in order to enable the separate mask registers?
> I'd like to test that (that's actually why I started looking at recent
> kernels with FDT support to begin with).
> Or shall I just follow Thomas' proof of concept on irq-sun4i and do the
> same for Kirkwood?

I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood,
Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.

> Sorry, I am really more than lost when it's about tracking
> how/where/when changes are pulled. Any "mainlining for dummies" pointer
> would be more than appreciated.

Hmm, sometimes I am also lost especially about when branches will be
merged. Jason can tell you for sure. Basically, patches go into some
maintainer's or submaintainer's branch first.

For mv643xx_eth DT patches the drivers/net related part goes through
net-next, the dove/kirkwood/orion5x related patches go through mvebu
(Jason Cooper) which will be pulled into arm-soc. But that varies with
every patch set and depends on likes and wishes.

Sebastian

DT version of kirkwood_ge0x_init()

[Gerlando Falauto]

Hi Sebastian,

thanks for the info.

On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
[...]
>
> I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood,
> Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.

[sorry we've moved to a different topic]
[adding Thomas Gleixner]
You mean the driver in arch/arm/plat-orion/gpio.c or the generic
one in drivers/gpio/gpio-mvebu.c?

Because the first one looks like it's using generic irq chip already.
For the second one I don't understand how you can handle the per-CPU 
registers which are peculiar to MV78200/ArmadaXP.
Unless there's already patches on top of Thomas's rework for the per-CPU 
registers.

Thank you,
Gerlando

DT version of kirkwood_ge0x_init()

[Gregory CLEMENT]

Hi Geraldo,
On 06/05/2013 11:37 AM, Gerlando Falauto wrote:
> Hi Sebastian,
> 
> thanks for the info.
> 
> On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
> [...]
>>
>> I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood,
>> Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.
> 
> [sorry we've moved to a different topic]
> [adding Thomas Gleixner]
> You mean the driver in arch/arm/plat-orion/gpio.c or the generic
> one in drivers/gpio/gpio-mvebu.c?
> 
> Because the first one looks like it's using generic irq chip already.
> For the second one I don't understand how you can handle the per-CPU 
> registers which are peculiar to MV78200/ArmadaXP.
> Unless there's already patches on top of Thomas's rework for the per-CPU 
> registers.
> 

Currently we don't use the per-CPU register for Armada XP (I am not sure for
MV78200). it was the cause of bugs and we didn't find how to properly fix
them, so the solution was to not use the per-cpu part.

> Thank you,
> Gerlando
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

DT version of kirkwood_ge0x_init()

[Sebastian Hesselbarth]

On 06/05/13 11:37, Gerlando Falauto wrote:
> On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
> [...]
>>
>> I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood,
>> Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.
>
> [sorry we've moved to a different topic]
> [adding Thomas Gleixner]
> You mean the driver in arch/arm/plat-orion/gpio.c or the generic
> one in drivers/gpio/gpio-mvebu.c?

For Kirkwood and Dove, DT kernels use gpio-mvebu. And that is there
from a time when there was no irqdomain support in generic chip. That
should be updated.

Sebastian

DT version of kirkwood_ge0x_init()

[Gerlando Falauto]

On 06/05/2013 11:49 AM, Sebastian Hesselbarth wrote:
> On 06/05/13 11:37, Gerlando Falauto wrote:
>> On 06/05/2013 11:04 AM, Sebastian Hesselbarth wrote:
>> [...]
>>>
>>> I have irqchip and clocksource drivers ready for Orion SoCs (Kirkwood,
>>> Dove, Orion5x, MV78x00). Just need some time to rebase and send patches.
>>
>> [sorry we've moved to a different topic]
>> [adding Thomas Gleixner]
>> You mean the driver in arch/arm/plat-orion/gpio.c or the generic
>> one in drivers/gpio/gpio-mvebu.c?
>
> For Kirkwood and Dove, DT kernels use gpio-mvebu. And that is there
> from a time when there was no irqdomain support in generic chip. That
> should be updated.

I know, that's why I was wondering how it is possible to update this 
driver and yet support per-cpu registers.
But I am admittedly not 100% sure I know what I'm talking about.

Anyway, could you please Cc: me when you post those patches?

Thank you,
Gerlando

DT version of kirkwood_ge0x_init()

[Jason Cooper]

Gerlando,

On Wed, Jun 05, 2013 at 11:04:38AM +0200, Sebastian Hesselbarth wrote:
> On 06/04/13 22:53, Gerlando Falauto wrote:
...
> >Sorry, I am really more than lost when it's about tracking
> >how/where/when changes are pulled. Any "mainlining for dummies" pointer
> >would be more than appreciated.
> 
> Hmm, sometimes I am also lost especially about when branches will be
> merged. Jason can tell you for sure. Basically, patches go into some
> maintainer's or submaintainer's branch first.

In the simple case, we look at the diffstat to see what sections of the
kernel are being changed.  drivers/net, arch/arm, arch/arm/mach-mvebu,
arch/arm/mm are all maintained by different people.  Depending on where
the changes are, that dictates who it will go through, DaveM, LinusW,
Arnd and Olof, Russell King, etc.

Any code changes in arch/arm that are SoC dependent go through arm-soc.
Otherwise, it goes through Russell.  arm-soc is maintained by Arnd and
Olof.  It's so large, that they've broken it up into sub-archs with
maintainers for each.  Myself, Andrew Lunn, and Gregory Clemente
maintain code changes in
arch/arm/mach-{mvebu,kirkwood,orion5x,dove,mv78xx0}.  We feed those
changes in the form of branches to arm-soc, who put it all together and
send it to Linus.

It gets complicated when part of a patch series, like Sebastian's, needs
to go through -net, and the rest through arm-soc.  If the two halves
don't depend on one another, then it's easy.  In this case, the arm-soc
changes _do_ depend on the -net changes.  So, we wait for the -net
changes to get into mainline Linux (because all of the branches from
everyone will have merged together), in this case, in v3.11-rc1.  Once
that lands, I'll base a branch off of it and include Sebastian's changes
to mach-kirkwood.  It will then be sent up to arm-soc for inclusion in
v3.12-rc1.

There's also a corner case where a driver maintainer will Ack a patch
series he would normally take and allow arm-soc to take it.  Usually
this is only if the driver changes are limited to a SoC specific file,
eg drivers/clk/mvebu/*, and the driver maintainer doesn't anticipate any
drivers/clk/* changes that will conflict.  Then, we can take the whole
series in one merge window through arm-soc.  But that's purely up to the
driver maintainer(s), and is by exception, not the rule.

hth,

Jason.