diff mbox

ARM: kirkwood: DT board setup for Network Space v2 and parents

Message ID 1349277270-24962-1-git-send-email-simon.guinot@sequanux.org (mailing list archive)
State New, archived
Headers show

Commit Message

Simon Guinot Oct. 3, 2012, 3:14 p.m. UTC
This patch adds DT board setup for LaCie Network Space v2 and parents,
based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max)
v2 and Internet Space v2.

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
 arch/arm/boot/dts/kirkwood-is2.dts         |   20 +++++
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi |   63 +++++++++++++++
 arch/arm/boot/dts/kirkwood-ns2.dts         |   20 +++++
 arch/arm/boot/dts/kirkwood-ns2max.dts      |   39 ++++++++++
 arch/arm/mach-kirkwood/Kconfig             |    8 ++
 arch/arm/mach-kirkwood/Makefile            |    1 +
 arch/arm/mach-kirkwood/Makefile.boot       |    1 +
 arch/arm/mach-kirkwood/board-dt.c          |    8 ++
 arch/arm/mach-kirkwood/board-ns2.c         |  117 ++++++++++++++++++++++++++++
 arch/arm/mach-kirkwood/common.h            |    6 ++
 drivers/leds/Kconfig                       |    3 +-
 11 files changed, 285 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
 create mode 100644 arch/arm/mach-kirkwood/board-ns2.c

Comments

Andrew Lunn Oct. 3, 2012, 3:43 p.m. UTC | #1
On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote:
> This patch adds DT board setup for LaCie Network Space v2 and parents,
> based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max)
> v2 and Internet Space v2.

Hi Simon

At a first look, this looks good. Also nice to see you use the new
gpio-fan binding.

> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
>  	if (of_machine_is_compatible("keymile,km_kirkwood"))
>  		km_kirkwood_init();
>  
> +	if (of_machine_is_compatible("lacie,inetspace_v2") ||
> +	    of_machine_is_compatible("lacie,netspace_v2") ||
> +	    of_machine_is_compatible("lacie,netspace_max_v2"))
> +		ns2_init();
> +
>  	of_platform_populate(NULL, kirkwood_dt_match_table,
>  			     kirkwood_auxdata_lookup, NULL);

I'm not a DT policy expert. Could this be one compatibility string for
all the boards? Maybe ask on the DT mainline list?

> +#define NETSPACE_V2_GPIO_BLUE_LED_SLOW	29
> +#define NETSPACE_V2_GPIO_BLUE_LED_CMD	30
> +
> +static struct ns2_led ns2_led_pins[] = {
> +	{
> +		.name	= "ns_v2:blue:sata",
> +		.cmd	= NETSPACE_V2_GPIO_BLUE_LED_CMD,
> +		.slow	= NETSPACE_V2_GPIO_BLUE_LED_SLOW,
> +	},
> +};
> +
> +static struct ns2_led_platform_data ns2_leds_data = {
> +	.num_leds	= ARRAY_SIZE(ns2_led_pins),
> +	.leds		= ns2_led_pins,
> +};
> +
> +static struct platform_device ns2_leds = {
> +	.name		= "leds-ns2",
> +	.id		= -1,
> +	.dev		= {
> +		.platform_data	= &ns2_leds_data,
> +	},
> +};

Have you thought about adding a DT binding for this driver?

It would be nice if you could respin the patches for -rc1, when it
comes out. There are changes to Makefile.boot at least required.

Thanks
	Andrew
Simon Guinot Oct. 3, 2012, 10:09 p.m. UTC | #2
On Wed, Oct 03, 2012 at 05:43:10PM +0200, Andrew Lunn wrote:
> On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote:
> > This patch adds DT board setup for LaCie Network Space v2 and parents,
> > based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max)
> > v2 and Internet Space v2.
> 
> Hi Simon
> 
> At a first look, this looks good. Also nice to see you use the new
> gpio-fan binding.

Hi Andrew,

It is nice to have this binding. It works fine.

> 
> > --- a/arch/arm/mach-kirkwood/board-dt.c
> > +++ b/arch/arm/mach-kirkwood/board-dt.c
> > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
> >  	if (of_machine_is_compatible("keymile,km_kirkwood"))
> >  		km_kirkwood_init();
> >  
> > +	if (of_machine_is_compatible("lacie,inetspace_v2") ||
> > +	    of_machine_is_compatible("lacie,netspace_v2") ||
> > +	    of_machine_is_compatible("lacie,netspace_max_v2"))
> > +		ns2_init();
> > +
> >  	of_platform_populate(NULL, kirkwood_dt_match_table,
> >  			     kirkwood_auxdata_lookup, NULL);
> 
> I'm not a DT policy expert. Could this be one compatibility string for
> all the boards? Maybe ask on the DT mainline list?

Maybe I could use "lacie,ns2_common" as a compatibility string. But this
does not match any existing device. I don't know if it is correct.

> 
> > +#define NETSPACE_V2_GPIO_BLUE_LED_SLOW	29
> > +#define NETSPACE_V2_GPIO_BLUE_LED_CMD	30
> > +
> > +static struct ns2_led ns2_led_pins[] = {
> > +	{
> > +		.name	= "ns_v2:blue:sata",
> > +		.cmd	= NETSPACE_V2_GPIO_BLUE_LED_CMD,
> > +		.slow	= NETSPACE_V2_GPIO_BLUE_LED_SLOW,
> > +	},
> > +};
> > +
> > +static struct ns2_led_platform_data ns2_leds_data = {
> > +	.num_leds	= ARRAY_SIZE(ns2_led_pins),
> > +	.leds		= ns2_led_pins,
> > +};
> > +
> > +static struct platform_device ns2_leds = {
> > +	.name		= "leds-ns2",
> > +	.id		= -1,
> > +	.dev		= {
> > +		.platform_data	= &ns2_leds_data,
> > +	},
> > +};
> 
> Have you thought about adding a DT binding for this driver?

Yes. I am on it.

> 
> It would be nice if you could respin the patches for -rc1, when it
> comes out. There are changes to Makefile.boot at least required.

OK. I will.

Note that this patch is based against the branch kirkwood/boards from
the git repository git://git.infradead.org/users/jcooper/linux.git. Is
that correct ?

Thanks.

Simon
Andrew Lunn Oct. 4, 2012, 5:17 a.m. UTC | #3
On Thu, Oct 04, 2012 at 12:09:16AM +0200, Simon Guinot wrote:
> On Wed, Oct 03, 2012 at 05:43:10PM +0200, Andrew Lunn wrote:
> > On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote:
> > > This patch adds DT board setup for LaCie Network Space v2 and parents,
> > > based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max)
> > > v2 and Internet Space v2.
> > 
> > Hi Simon
> > 
> > At a first look, this looks good. Also nice to see you use the new
> > gpio-fan binding.
> 
> Hi Andrew,
> 
> It is nice to have this binding. It works fine.

It good to hear that it works. There is one other board which could
use it. I plan to convert it over for 3.8.

I will take a look at other DT boards and see if there is any patterns
which might help here, for naming of a shared compatibility string.

> > Have you thought about adding a DT binding for this driver?
> 
> Yes. I am on it.

Great. Please include my CC: when you post it.

> > It would be nice if you could respin the patches for -rc1, when it
> > comes out. There are changes to Makefile.boot at least required.
> 
> OK. I will.
> 
> Note that this patch is based against the branch kirkwood/boards from
> the git repository git://git.infradead.org/users/jcooper/linux.git. Is
> that correct ?

Its a good start. However, the Makefile.boot changes were merged in in
arm-soc, and not by the Marvell maintainers in our trees. So changes
across multiple arm platforms are not in Jason's tree. -rc1 will have
all these changes, and forms the best base for a new board.

    Thanks
	Andrew
Andrew Lunn Oct. 4, 2012, 5:54 a.m. UTC | #4
> > > --- a/arch/arm/mach-kirkwood/board-dt.c
> > > +++ b/arch/arm/mach-kirkwood/board-dt.c
> > > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
> > >  	if (of_machine_is_compatible("keymile,km_kirkwood"))
> > >  		km_kirkwood_init();
> > >  
> > > +	if (of_machine_is_compatible("lacie,inetspace_v2") ||
> > > +	    of_machine_is_compatible("lacie,netspace_v2") ||
> > > +	    of_machine_is_compatible("lacie,netspace_max_v2"))
> > > +		ns2_init();
> > > +
> > >  	of_platform_populate(NULL, kirkwood_dt_match_table,
> > >  			     kirkwood_auxdata_lookup, NULL);
> > 
> > I'm not a DT policy expert. Could this be one compatibility string for
> > all the boards? Maybe ask on the DT mainline list?
> 
> Maybe I could use "lacie,ns2_common" as a compatibility string. But this
> does not match any existing device. I don't know if it is correct.

Hi Simon

I did a bit of looking around. For kirkwood, we already have two
boards sharing the same compatibility string. kirkwood-dns320.dts and
kirkwood-dns325.dts both have dlink,dns-kirkwood and this is what the
board-dt.c matches on.

For the tegra20 soc, all boards match on nvidia,tegra20, and that is the only
compatibility string in board-dt-tegra20.c.

So i don't see any problem having just one compatibility string here.

The question is, what is the appropriate name. How common is this
common C code? Are there ns2 where this C code is not appropriate. One
thing to remember is that most of this C code will soon disappear and
become DT. All the mpp will be replaced with pinctrl in 3.8. I hope we
can get the Ethernet setup in DT as well. You are working on ns2_led,
so all the C code will be replaced by DT. So all we are really left
with is power off GPIO handling.

So i think the danger of using lacie,ns2_common, and then finding it
does not work with some other ns2 device is quite low.

What do you think?

     Thanks
	Andrew
Simon Guinot Oct. 4, 2012, 7:53 a.m. UTC | #5
On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
> > > > --- a/arch/arm/mach-kirkwood/board-dt.c
> > > > +++ b/arch/arm/mach-kirkwood/board-dt.c
> > > > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
> > > >  	if (of_machine_is_compatible("keymile,km_kirkwood"))
> > > >  		km_kirkwood_init();
> > > >  
> > > > +	if (of_machine_is_compatible("lacie,inetspace_v2") ||
> > > > +	    of_machine_is_compatible("lacie,netspace_v2") ||
> > > > +	    of_machine_is_compatible("lacie,netspace_max_v2"))
> > > > +		ns2_init();
> > > > +
> > > >  	of_platform_populate(NULL, kirkwood_dt_match_table,
> > > >  			     kirkwood_auxdata_lookup, NULL);
> > > 
> > > I'm not a DT policy expert. Could this be one compatibility string for
> > > all the boards? Maybe ask on the DT mainline list?
> > 
> > Maybe I could use "lacie,ns2_common" as a compatibility string. But this
> > does not match any existing device. I don't know if it is correct.
> 
> Hi Simon
> 
> I did a bit of looking around. For kirkwood, we already have two
> boards sharing the same compatibility string. kirkwood-dns320.dts and
> kirkwood-dns325.dts both have dlink,dns-kirkwood and this is what the
> board-dt.c matches on.
> 
> For the tegra20 soc, all boards match on nvidia,tegra20, and that is the only
> compatibility string in board-dt-tegra20.c.
> 
> So i don't see any problem having just one compatibility string here.
> 
> The question is, what is the appropriate name. How common is this
> common C code? Are there ns2 where this C code is not appropriate. One
> thing to remember is that most of this C code will soon disappear and
> become DT. All the mpp will be replaced with pinctrl in 3.8. I hope we
> can get the Ethernet setup in DT as well. You are working on ns2_led,
> so all the C code will be replaced by DT. So all we are really left
> with is power off GPIO handling.
> 
> So i think the danger of using lacie,ns2_common, and then finding it
> does not work with some other ns2 device is quite low.
> 
> What do you think?

The status for this ns2 boards is more or less end-of-life. I mean, this
boards are no longer in production. So I think it is safe to consider
the code inside board-ns2.c as common and shareable between ns2, is2 and
ns2max.

Once this file will be removed, the compatibility checks will be removed
as well. But one could easily forget to remove the useless compatibility
string "lacie,ns2_common" from the dts...

Let me know your preference.

Simon
Stephen Warren Oct. 4, 2012, 3:41 p.m. UTC | #6
On 10/04/2012 01:53 AM, Simon Guinot wrote:
> On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
>>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++
>>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@
>>>>> static void __init kirkwood_dt_init(void) if
>>>>> (of_machine_is_compatible("keymile,km_kirkwood")) 
>>>>> km_kirkwood_init();
>>>>> 
>>>>> +	if (of_machine_is_compatible("lacie,inetspace_v2") || +
>>>>> of_machine_is_compatible("lacie,netspace_v2") || +
>>>>> of_machine_is_compatible("lacie,netspace_max_v2")) +
>>>>> ns2_init(); + of_platform_populate(NULL,
>>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL);
>>>> 
>>>> I'm not a DT policy expert. Could this be one compatibility
>>>> string for all the boards? Maybe ask on the DT mainline
>>>> list?
>>> 
>>> Maybe I could use "lacie,ns2_common" as a compatibility string.
>>> But this does not match any existing device. I don't know if it
>>> is correct.
>> 
>> Hi Simon
>> 
>> I did a bit of looking around. For kirkwood, we already have two 
>> boards sharing the same compatibility string. kirkwood-dns320.dts
>> and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is
>> what the board-dt.c matches on.
>> 
>> For the tegra20 soc, all boards match on nvidia,tegra20, and that
>> is the only compatibility string in board-dt-tegra20.c.

nvidia,tegra20 is the compatible value for the SoC itself, so
naturally any Tegra20-based board has that.

>> So i don't see any problem having just one compatibility string
>> here.
>> 
>> The question is, what is the appropriate name. How common is
>> this common C code? Are there ns2 where this C code is not
>> appropriate. One thing to remember is that most of this C code
>> will soon disappear and become DT. All the mpp will be replaced
>> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
>> as well. You are working on ns2_led, so all the C code will be
>> replaced by DT. So all we are really left with is power off GPIO
>> handling.
>> 
>> So i think the danger of using lacie,ns2_common, and then finding
>> it does not work with some other ns2 device is quite low.

lacie,ns2_common doesn't sound like a HW description, but rather a SW
invention. DT should be describing purely the HW. If there's no common
HW between these compatible boards (which seems unlikely), then there
shouldn't be a shared compatible value.

>> What do you think?
> 
> The status for this ns2 boards is more or less end-of-life. I mean,
> this boards are no longer in production. So I think it is safe to
> consider the code inside board-ns2.c as common and shareable
> between ns2, is2 and ns2max.
> 
> Once this file will be removed, the compatibility checks will be
> removed as well. But one could easily forget to remove the useless
> compatibility string "lacie,ns2_common" from the dts...

If that value is added to the DT, it should not be removed, and the
kernel should continue to support it indefinitely.
Andrew Lunn Oct. 9, 2012, 11:17 a.m. UTC | #7
> >> The question is, what is the appropriate name. How common is
> >> this common C code? Are there ns2 where this C code is not
> >> appropriate. One thing to remember is that most of this C code
> >> will soon disappear and become DT. All the mpp will be replaced
> >> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
> >> as well. You are working on ns2_led, so all the C code will be
> >> replaced by DT. So all we are really left with is power off GPIO
> >> handling.
> >> 
> >> So i think the danger of using lacie,ns2_common, and then finding
> >> it does not work with some other ns2 device is quite low.
> 
> lacie,ns2_common doesn't sound like a HW description, but rather a SW
> invention. DT should be describing purely the HW. If there's no common
> HW between these compatible boards (which seems unlikely), then there
> shouldn't be a shared compatible value.

Actually, there is common hardware between these boards:

NS2 LED driver
Pinctrl setup
GPIO used for power off
Ethernet configuration.

At the moment, we don't have DT for these, so there is C code.  The
"lacie,ns2_common" compatibility string would be used to enable this C
code for these boards.

     Andrew
Simon Guinot Oct. 9, 2012, 3:05 p.m. UTC | #8
On Thu, Oct 04, 2012 at 09:41:06AM -0600, Stephen Warren wrote:
> On 10/04/2012 01:53 AM, Simon Guinot wrote:
> > On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
> >>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++
> >>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@
> >>>>> static void __init kirkwood_dt_init(void) if
> >>>>> (of_machine_is_compatible("keymile,km_kirkwood")) 
> >>>>> km_kirkwood_init();
> >>>>> 
> >>>>> +	if (of_machine_is_compatible("lacie,inetspace_v2") || +
> >>>>> of_machine_is_compatible("lacie,netspace_v2") || +
> >>>>> of_machine_is_compatible("lacie,netspace_max_v2")) +
> >>>>> ns2_init(); + of_platform_populate(NULL,
> >>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL);
> >>>> 
> >>>> I'm not a DT policy expert. Could this be one compatibility
> >>>> string for all the boards? Maybe ask on the DT mainline
> >>>> list?
> >>> 
> >>> Maybe I could use "lacie,ns2_common" as a compatibility string.
> >>> But this does not match any existing device. I don't know if it
> >>> is correct.
> >> 
> >> Hi Simon
> >> 
> >> I did a bit of looking around. For kirkwood, we already have two 
> >> boards sharing the same compatibility string. kirkwood-dns320.dts
> >> and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is
> >> what the board-dt.c matches on.
> >> 
> >> For the tegra20 soc, all boards match on nvidia,tegra20, and that
> >> is the only compatibility string in board-dt-tegra20.c.
> 
> nvidia,tegra20 is the compatible value for the SoC itself, so
> naturally any Tegra20-based board has that.
> 
> >> So i don't see any problem having just one compatibility string
> >> here.
> >> 
> >> The question is, what is the appropriate name. How common is
> >> this common C code? Are there ns2 where this C code is not
> >> appropriate. One thing to remember is that most of this C code
> >> will soon disappear and become DT. All the mpp will be replaced
> >> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
> >> as well. You are working on ns2_led, so all the C code will be
> >> replaced by DT. So all we are really left with is power off GPIO
> >> handling.
> >> 
> >> So i think the danger of using lacie,ns2_common, and then finding
> >> it does not work with some other ns2 device is quite low.
> 
> lacie,ns2_common doesn't sound like a HW description, but rather a SW
> invention. DT should be describing purely the HW. If there's no common
> HW between these compatible boards (which seems unlikely), then there
> shouldn't be a shared compatible value.

Indeed "lacie,ns2_common" is not an hardware description. But actually,
even if the PCB and the BOM are not exactly the same, there is a lot of
common HW between this boards. I understand that sharing a compatible
value between all this boards could be uncertain. For example, the BOMs
could evolve differently during the production process and at a given
time, the compatibility could be broken. But as I said, this will not
happen here because this boards are no longer in production.

> 
> >> What do you think?
> > 
> > The status for this ns2 boards is more or less end-of-life. I mean,
> > this boards are no longer in production. So I think it is safe to
> > consider the code inside board-ns2.c as common and shareable
> > between ns2, is2 and ns2max.
> > 
> > Once this file will be removed, the compatibility checks will be
> > removed as well. But one could easily forget to remove the useless
> > compatibility string "lacie,ns2_common" from the dts...
> 
> If that value is added to the DT, it should not be removed, and the
> kernel should continue to support it indefinitely.

I understand it is a strong requirement. But as I mentioned before, due
to the production process, one could easily end up with an embedded DTB
not matching exactly the hardware. It could even be worse. A end-of-life
device could be replaced by a supposed compatible one. And sometimes the
compatibility assumption is false. In a such scenario, maybe you don't
want the kernel to support indefinitely a DT statement.

Simon

> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Stephen Warren Oct. 9, 2012, 4:26 p.m. UTC | #9
On 10/09/2012 05:17 AM, Andrew Lunn wrote:
>>>> The question is, what is the appropriate name. How common is
>>>> this common C code? Are there ns2 where this C code is not
>>>> appropriate. One thing to remember is that most of this C code
>>>> will soon disappear and become DT. All the mpp will be replaced
>>>> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
>>>> as well. You are working on ns2_led, so all the C code will be
>>>> replaced by DT. So all we are really left with is power off GPIO
>>>> handling.
>>>>
>>>> So i think the danger of using lacie,ns2_common, and then finding
>>>> it does not work with some other ns2 device is quite low.
>>
>> lacie,ns2_common doesn't sound like a HW description, but rather a SW
>> invention. DT should be describing purely the HW. If there's no common
>> HW between these compatible boards (which seems unlikely), then there
>> shouldn't be a shared compatible value.
> 
> Actually, there is common hardware between these boards:
> 
> NS2 LED driver
> Pinctrl setup
> GPIO used for power off
> Ethernet configuration.
> 
> At the moment, we don't have DT for these, so there is C code.  The
> "lacie,ns2_common" compatibility string would be used to enable this C
> code for these boards.

The typical way to support this is to simply include a .dtsi file from
both board-specific .dts file. That .dtsi file will provide the
description of the two common pieces of hardware.

In the interim where you're stilling using some board file C code rather
than DT for this common part, just trigger that C code from any of the
compatible values for the boards where it's needed. Don't invent a new
compatible value that means "run this C code".
Stephen Warren Oct. 9, 2012, 4:30 p.m. UTC | #10
On 10/09/2012 09:05 AM, Simon Guinot wrote:
> On Thu, Oct 04, 2012 at 09:41:06AM -0600, Stephen Warren wrote:
>> On 10/04/2012 01:53 AM, Simon Guinot wrote:
>>> On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
>>>>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++ 
>>>>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@ 
>>>>>>> static void __init kirkwood_dt_init(void) if 
>>>>>>> (of_machine_is_compatible("keymile,km_kirkwood")) 
>>>>>>> km_kirkwood_init();
>>>>>>> 
>>>>>>> +	if (of_machine_is_compatible("lacie,inetspace_v2") ||
>>>>>>> + of_machine_is_compatible("lacie,netspace_v2") || + 
>>>>>>> of_machine_is_compatible("lacie,netspace_max_v2")) + 
>>>>>>> ns2_init(); + of_platform_populate(NULL, 
>>>>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup,
>>>>>>> NULL);
>>>>>> 
>>>>>> I'm not a DT policy expert. Could this be one
>>>>>> compatibility string for all the boards? Maybe ask on the
>>>>>> DT mainline list?
>>>>> 
>>>>> Maybe I could use "lacie,ns2_common" as a compatibility
>>>>> string. But this does not match any existing device. I
>>>>> don't know if it is correct.
...
>>> The status for this ns2 boards is more or less end-of-life. I
>>> mean, this boards are no longer in production. So I think it is
>>> safe to consider the code inside board-ns2.c as common and
>>> shareable between ns2, is2 and ns2max.
>>> 
>>> Once this file will be removed, the compatibility checks will
>>> be removed as well. But one could easily forget to remove the
>>> useless compatibility string "lacie,ns2_common" from the
>>> dts...
>> 
>> If that value is added to the DT, it should not be removed, and
>> the kernel should continue to support it indefinitely.
> 
> I understand it is a strong requirement. But as I mentioned before,
> due to the production process, one could easily end up with an
> embedded DTB not matching exactly the hardware. It could even be
> worse. A end-of-life device could be replaced by a supposed
> compatible one. And sometimes the compatibility assumption is
> false. In a such scenario, maybe you don't want the kernel to
> support indefinitely a DT statement.

I'm not sure I fully understand that last paragraph. However, if the
board is replaced by a new board model, and that new board model is
not 100% SW-compatible with the old model, then you'll want to invent
a new compatible value to represent the new board version. Removing
support from the kernel for the old compatible value, or keeping the
same compatible value and changing how the kernel handles it in a way
that prevents the original board and .dts from working, is not
appropriate.
diff mbox

Patch

diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
new file mode 100644
index 0000000..6390db5
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -0,0 +1,20 @@ 
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+	model = "LaCie Internet Space v2";
+	compatible = "lacie,inetspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x8000000>;
+	};
+
+	ocp@f1000000 {
+		sata@80000 {
+			status = "okay";
+			nr-ports = <1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
new file mode 100644
index 0000000..030904d
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -0,0 +1,63 @@ 
+/include/ "kirkwood.dtsi"
+
+/ {
+	chosen {
+		bootargs = "console=ttyS0,115200n8";
+	};
+
+	ocp@f1000000 {
+		serial@12000 {
+			clock-frequency = <166666667>;
+			status = "okay";
+		};
+
+		spi@10600 {
+			status = "okay";
+
+			flash@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "mx25l4005a";
+				reg = <0>;
+				spi-max-frequency = <20000000>;
+				mode = <0>;
+
+				partition@0 {
+					reg = <0x0 0x80000>;
+					label = "u-boot";
+				};
+			};
+		};
+
+		i2c@11000 {
+			status = "okay";
+
+			eeprom@50 {
+				compatible = "at,24c04";
+				pagesize = <16>;
+				reg = <0x50>;
+			};
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		button@1 {
+			label = "Power push button";
+			linux,code = <116>;
+			gpios = <&gpio1 0 0>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		red-fail {
+			label = "ns_v2:red:fail";
+			gpios = <&gpio0 12 0>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
new file mode 100644
index 0000000..6ef66b9
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -0,0 +1,20 @@ 
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+	model = "LaCie Network Space v2";
+	compatible = "lacie,netspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x10000000>;
+	};
+
+	ocp@f1000000 {
+		sata@80000 {
+			status = "okay";
+			nr-ports = <1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
new file mode 100644
index 0000000..30ed909
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -0,0 +1,39 @@ 
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+	model = "LaCie Network Space Max v2";
+	compatible = "lacie,netspace_max_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x10000000>;
+	};
+
+	ocp@f1000000 {
+		sata@80000 {
+			status = "okay";
+			nr-ports = <2>;
+		};
+	};
+
+	gpio_fan {
+		compatible = "gpio-fan";
+		gpios = <&gpio0 22 1
+			 &gpio0  7 1
+			 &gpio1  1 1
+			 &gpio0 23 1>;
+		gpio-fan,speed-map =
+			<   0  0
+			 1500 15
+			 1700 14
+			 1800 13
+			 2100 12
+			 3100 11
+			 3300 10
+			 4300  9
+			 5500  8>;
+		alarm-gpios = <&gpio0 25 1>;
+	};
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 50bca50..5b239a6 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -130,6 +130,14 @@  config MACH_KM_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
 
+config MACH_NETSPACE_V2_DT
+	bool "LaCie Network Space v2 NAS and parents (Flattened Device Tree)"
+	select ARCH_KIRKWOOD_DT
+	help
+	  Say 'Y' here if you want your kernel to support the LaCie
+	  Network Space v2 NAS and parents, using Flattened Device Tree.
+	  This includes Network Space (Max) v2 and Internet Space v2.
+
 config MACH_TS219
 	bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
 	help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 294779f..0562753 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -31,3 +31,4 @@  obj-$(CONFIG_MACH_GOFLEXNET_DT)		+= board-goflexnet.o
 obj-$(CONFIG_MACH_LSXL_DT)		+= board-lsxl.o
 obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT)	+= board-iomega_ix2_200.o
 obj-$(CONFIG_MACH_KM_KIRKWOOD_DT)	+= board-km_kirkwood.o
+obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index 5edef8e..1e15c37 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -15,3 +15,4 @@  dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lsxhl.dtb
 dtb-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += kirkwood-iomega_ix2_200.dtb
 dtb-$(CONFIG_MACH_DOCKSTAR_DT) += kirkwood-dockstar.dtb
 dtb-$(CONFIG_MACH_KM_KIRKWOOD_DT) += kirkwood-km_kirkwood.dtb
+dtb-$(CONFIG_MACH_NETSPACE_V2_DT) += kirkwood-ns2.dtb
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 4965546..f1746b3 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -96,6 +96,11 @@  static void __init kirkwood_dt_init(void)
 	if (of_machine_is_compatible("keymile,km_kirkwood"))
 		km_kirkwood_init();
 
+	if (of_machine_is_compatible("lacie,inetspace_v2") ||
+	    of_machine_is_compatible("lacie,netspace_v2") ||
+	    of_machine_is_compatible("lacie,netspace_max_v2"))
+		ns2_init();
+
 	of_platform_populate(NULL, kirkwood_dt_match_table,
 			     kirkwood_auxdata_lookup, NULL);
 }
@@ -112,6 +117,9 @@  static const char *kirkwood_dt_board_compat[] = {
 	"buffalo,lsxl",
 	"iom,ix2-200",
 	"keymile,km_kirkwood",
+	"lacie,inetspace_v2",
+	"lacie,netspace_max_v2",
+	"lacie,netspace_v2",
 	NULL
 };
 
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
new file mode 100644
index 0000000..f87abad
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -0,0 +1,117 @@ 
+/*
+ * Copyright 2012 (C), Simon Guinot <simon.guinot@sequanux.org>
+ *
+ * arch/arm/mach-kirkwood/board-ns2.c
+ *
+ * LaCie Network Space v2 board (and parents) initialization for drivers
+ * not converted to flattened device tree yet.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mv643xx_eth.h>
+#include <linux/gpio.h>
+#include <mach/leds-ns2.h>
+#include "common.h"
+#include "mpp.h"
+
+static struct mv643xx_eth_platform_data ns2_ge00_data = {
+	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
+};
+
+/*****************************************************************************
+ * Dual-GPIO CPLD LEDs
+ ****************************************************************************/
+
+#define NETSPACE_V2_GPIO_BLUE_LED_SLOW	29
+#define NETSPACE_V2_GPIO_BLUE_LED_CMD	30
+
+static struct ns2_led ns2_led_pins[] = {
+	{
+		.name	= "ns_v2:blue:sata",
+		.cmd	= NETSPACE_V2_GPIO_BLUE_LED_CMD,
+		.slow	= NETSPACE_V2_GPIO_BLUE_LED_SLOW,
+	},
+};
+
+static struct ns2_led_platform_data ns2_leds_data = {
+	.num_leds	= ARRAY_SIZE(ns2_led_pins),
+	.leds		= ns2_led_pins,
+};
+
+static struct platform_device ns2_leds = {
+	.name		= "leds-ns2",
+	.id		= -1,
+	.dev		= {
+		.platform_data	= &ns2_leds_data,
+	},
+};
+
+/*****************************************************************************
+ * General Setup
+ ****************************************************************************/
+
+static unsigned int ns2_mpp_config[] __initdata = {
+	MPP0_SPI_SCn,
+	MPP1_SPI_MOSI,
+	MPP2_SPI_SCK,
+	MPP3_SPI_MISO,
+	MPP4_NF_IO6,
+	MPP5_NF_IO7,
+	MPP6_SYSRST_OUTn,
+	MPP7_GPO,		/* Fan speed (bit 1) */
+	MPP8_TW0_SDA,
+	MPP9_TW0_SCK,
+	MPP10_UART0_TXD,
+	MPP11_UART0_RXD,
+	MPP12_GPO,		/* Red led */
+	MPP14_GPIO,		/* USB fuse */
+	MPP16_GPIO,		/* SATA 0 power */
+	MPP17_GPIO,		/* SATA 1 power */
+	MPP18_NF_IO0,
+	MPP19_NF_IO1,
+	MPP20_SATA1_ACTn,
+	MPP21_SATA0_ACTn,
+	MPP22_GPIO,		/* Fan speed (bit 0) */
+	MPP23_GPIO,		/* Fan power */
+	MPP24_GPIO,		/* USB mode select */
+	MPP25_GPIO,		/* Fan rotation fail */
+	MPP26_GPIO,		/* USB device vbus */
+	MPP28_GPIO,		/* USB enable host vbus */
+	MPP29_GPIO,		/* Blue led (slow register) */
+	MPP30_GPIO,		/* Blue led (command register) */
+	MPP31_GPIO,		/* Board power off */
+	MPP32_GPIO,		/* Power button (0 = Released, 1 = Pushed) */
+	MPP33_GPO,		/* Fan speed (bit 2) */
+	0
+};
+
+#define NETSPACE_V2_GPIO_POWER_OFF	31
+
+static void ns2_power_off(void)
+{
+	gpio_set_value(NETSPACE_V2_GPIO_POWER_OFF, 1);
+}
+
+void __init ns2_init(void)
+{
+	/*
+	 * Basic setup. Needs to be called early.
+	 */
+	kirkwood_mpp_conf(ns2_mpp_config);
+
+	kirkwood_ehci_init();
+	kirkwood_ge00_init(&ns2_ge00_data);
+	platform_device_register(&ns2_leds);
+
+	if (gpio_request(NETSPACE_V2_GPIO_POWER_OFF, "power-off") == 0 &&
+	    gpio_direction_output(NETSPACE_V2_GPIO_POWER_OFF, 0) == 0)
+		pm_power_off = ns2_power_off;
+	else
+		pr_err("ns2: failed to configure power-off GPIO\n");
+}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index bcffd7c..f6c0fc9 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -112,6 +112,12 @@  void km_kirkwood_init(void);
 static inline void km_kirkwood_init(void) {};
 #endif
 
+#ifdef CONFIG_MACH_NETSPACE_V2_DT
+void ns2_init(void);
+#else
+static inline void ns2_init(void) {};
+#endif
+
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index c96bbaa..483ef81 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -367,7 +367,8 @@  config LEDS_NS2
 	tristate "LED support for Network Space v2 GPIO LEDs"
 	depends on LEDS_CLASS
 	depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \
-		   MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2
+		   MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \
+		   MACH_NETSPACE_V2_DT
 	default y
 	help
 	  This option enable support for the dual-GPIO LED found on the