Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

> Now I activated the debug messages in em28xx. From the messages I
> see no correlation of the pool exhaustion and lost sync. Also I
> cannot see any error messages from the em28xx driver.
> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
> draining the coherent pool (checked with 'cat
> /debug/dma-api/num_free_entries', which gave stable numbers), but
> after half an hour there are only init_isoc messages without
> corresponding stop_urbs messages and num_free_entries decreased
> until coherent pool exhaustion.

Hi Soeren

em28xx_stop_urbs() is only called by em28xx_stop_streaming().

em28xx_stop_streaming() is only called by em28xx_stop_feed()
when 0 == dvb->nfeeds.

em28xx_stop_feed()and em28xx_start_feed() look O.K, dvb->nfeeds is
protected by a mutex etc.

Now, em28xx_init_isoc() is also called by buffer_prepare(). This uses
em28xx_alloc_isoc() to do the actual allocation, and that function
sets up the urb such that on completion the function
em28xx_irq_callback() is called.

It looks like there might be issues here:

Once the data has been copied out, it resubmits the urb:

   urb->status = usb_submit_urb(urb, GFP_ATOMIC);
if (urb->status) {
em28xx_isocdbg("urb resubmit failed (error=%i)\n",
   urb->status);
}
  
However, if the ubs_submit_urb fails, it looks like the urb is lost.

If you look at other code submitting urbs you have this pattern:

   rc = usb_submit_urb(isoc_bufs->urb[i], GFP_ATOMIC);
if (rc) {
em28xx_err("submit of urb %i failed (error=%i)\n", i,
   rc);
em28xx_uninit_isoc(dev, mode);
return rc;
}
 
Do you have your build such that you would see "urb resubmit failed"
in your logs? Are there any?

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] power/reset: Remove newly introduced __dev* annotations

[Andrew Lunn]

On Wed, Jan 30, 2013 at 12:28:13PM +0100, Thierry Reding wrote:
> __devinit, __devexit and __devexit_p have recently been removed and
> should no longer be used.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/power/reset/restart-poweroff.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/reset/restart-poweroff.c 
> b/drivers/power/reset/restart-poweroff.c
> index b11b9e8..059cd15 100644
> --- a/drivers/power/reset/restart-poweroff.c
> +++ b/drivers/power/reset/restart-poweroff.c
> @@ -22,7 +22,7 @@ static void restart_poweroff_do_poweroff(void)
>   arm_pm_restart('h', NULL);
>  }
>  
> -static int __devinit restart_poweroff_probe(struct platform_device *pdev)
> +static int restart_poweroff_probe(struct platform_device *pdev)
>  {
>   /* If a pm_power_off function has already been added, leave it alone */
>   if (pm_power_off != NULL) {
> @@ -35,7 +35,7 @@ static int __devinit restart_poweroff_probe(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> -static int __devexit restart_poweroff_remove(struct platform_device *pdev)
> +static int restart_poweroff_remove(struct platform_device *pdev)
>  {
>   if (pm_power_off == &restart_poweroff_do_poweroff)
>   pm_power_off = NULL;
> @@ -50,7 +50,7 @@ static const struct of_device_id 
> of_restart_poweroff_match[] = {
>  
>  static struct platform_driver restart_poweroff_driver = {
>   .probe = restart_poweroff_probe,
> - .remove = __devexit_p(restart_poweroff_remove),
> + .remove = restart_poweroff_remove,
>       .driver = {
>   .name = "poweroff-restart",
>   .owner = THIS_MODULE,
> -- 
> 1.8.1.2
> 

Acked-by: Andrew Lunn 

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: mv78xx0: correct addr_map_cfg __initdata annotation

[Andrew Lunn]

On Wed, Oct 03, 2012 at 07:06:34PM +, Arnd Bergmann wrote:
> The annotation on the addr_map_cfg variable is in the wrong place.
> 
> Without this patch, building mv78xx0_defconfig results in:
> 
> /home/arnd/linux-arm/arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: 
> initialization from incompatible pointer type [enabled by default]
> /home/arnd/linux-arm/arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near 
> initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]
> 
> Signed-off-by: Arnd Bergmann 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> ---
> Queued in the late/fixes branch
> 
> diff --git a/arch/arm/mach-mv78xx0/addr-map.c 
> b/arch/arm/mach-mv78xx0/addr-map.c
> index a9bc841..03f7486 100644
> --- a/arch/arm/mach-mv78xx0/addr-map.c
> +++ b/arch/arm/mach-mv78xx0/addr-map.c
> @@ -53,7 +53,7 @@ static void __init __iomem *win_cfg_base(const struct 
> orion_addr_map_cfg *cfg, i
>  /*
>   * Description of the windows needed by the platform code
>   */
> -static struct __initdata orion_addr_map_cfg addr_map_cfg = {
> +static struct orion_addr_map_cfg addr_map_cfg __initdata = {
>   .num_wins = 14,
>   .remappable_wins = 8,
>   .win_cfg_base = win_cfg_base,

Humm, been there, done that once. Must of forgotten to post it. :-(

Acked-by: Andrew Lunn 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

[Andrew Lunn]

On Wed, Oct 24, 2012 at 03:49:21PM +0200, Gregory CLEMENT wrote:
> From: Lior Amsalem 
> 
> Signed-off-by: Gregory CLEMENT 
> Signed-off-by: Lior Amsalem 
> ---
>  arch/arm/boot/dts/armada-370-db.dts  |3 +++
>  arch/arm/boot/dts/armada-370-xp.dtsi |   10 ++
>  arch/arm/boot/dts/armada-xp-db.dts   |3 +++
>  arch/arm/configs/mvebu_defconfig |7 +++
>  4 files changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-370-db.dts 
> b/arch/arm/boot/dts/armada-370-db.dts
> index 4a31b03..2a2aa75 100644
> --- a/arch/arm/boot/dts/armada-370-db.dts
> +++ b/arch/arm/boot/dts/armada-370-db.dts
> @@ -34,5 +34,8 @@
>   clock-frequency = <2>;
>   status = "okay";
>   };
> + sata@d00a {
> + status = "okay";
> + };
>   };
>  };
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
> b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 94b4b9e..3f08233 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -69,6 +69,16 @@
>   compatible = "marvell,armada-addr-decoding-controller";
>   reg = <0xd002 0x258>;
>   };
> +
> + sata@d00a {
> +compatible = "marvell,orion-sata";
> +reg = <0xd00a 0x2400>;
> +interrupts = <55>;
> +nr-ports = <2>;
> + clocks = <&coreclk 0>;//,  <&coreclk 0>;
> +status = "disabled";
> + };
> +
>   };
>  };
>  
> diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
> b/arch/arm/boot/dts/armada-xp-db.dts
> index b1fc728..b0db9a3 100644
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@ -46,5 +46,8 @@
>   clock-frequency = <25000>;
>   status = "okay";
>   };
> + sata@d00a {
> + status = "okay";
> + };
>   };
>  };

Hi Gregory

Should there be some pinctrl setup somewhere, to ensure the pins used
for SATA are really setup up for SATA?

Also, for kirkwood, the number of SATA ports varies. So we don't
define it in the base kirkwood.dtsi and leave each board to set it.
Do we want to be consistent between kirkwood and 370/xp?

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 0/4] Adding SATA support for Armada 370/XP

[Andrew Lunn]

On Fri, Oct 26, 2012 at 02:30:45PM +0200, Gregory CLEMENT wrote:
> Hello,
> 
> this patch set adds the SATA support for Armada 370 and Armada XP. Few
> changes have been done since the first version by taking in account
> the comments received for the first version.
> 
> The evaluation boards for Armada 370 and Armada XP come with 2 SATA
> ports, and when both are enable the coherent pool for DMA mapping was
> too short. It was exactly the same issue that was fixed for Kirkwood
> two months ago. So I used the same fix in the first patch. Later when
> Kirkwood will be part of mach-mvebu, then this fix will be shared
> between the 2 SoCs families.
> 
> This patch set is based on 3.7-rc2 and depends one the framework clock
> support (the last version was posted last week:
> http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
> called mvebu-SATA-for-3.8 is also available at
> https://github.com/MISL-EBU-System-SW/mainline-public.git.

Hi Gregory

What about the openblocks-ax3?

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 0/4] Adding SATA support for Armada 370/XP

[Andrew Lunn]

On Fri, Oct 26, 2012 at 02:48:04PM +0200, Thomas Petazzoni wrote:
> 
> On Fri, 26 Oct 2012 14:39:08 +0200, Andrew Lunn wrote:
> 
> > What about the openblocks-ax3?
> 
> Gr??gory does not (yet) have an OpenBlocks AX3, but I'm planning to do
> the work for SATA soon for this platform. However, supporting the
> OpenBlocks AX3 is not part of our official contract with Marvell, it's
> just an additional thing I'm happily doing on my spare time.

Ah, O.K. I did not realize that.

> So I'll
> provide support for SATA, network and SMP on OpenBlocks AX3, but we
> would like to first see the SATA support for the Marvell evaluation
> boards being merged, and on my side the basic support for the
> OpenBlocks AX3. I'll send followup patches to enable SATA/network/SMP
> on OpenBlocks AX3 later on, if that's ok for you?

Sure, no problem.

Thanks for the clarification,

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP

[Andrew Lunn]

On Fri, Oct 26, 2012 at 09:31:54AM -0400, Jason Cooper wrote:
> On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
> > Signed-off-by: Gregory CLEMENT 
> > Signed-off-by: Lior Amsalem 
> > ---
> >  arch/arm/boot/dts/armada-370-xp.dtsi |9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
> > b/arch/arm/boot/dts/armada-370-xp.dtsi
> > index 94b4b9e..a911f7a 100644
> > --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> > +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> > @@ -69,6 +69,15 @@
> > compatible = "marvell,armada-addr-decoding-controller";
> > reg = <0xd002 0x258>;
> > };
> > +
> > +   sata@d00a {
> > +compatible = "marvell,orion-sata";
> > +reg = <0xd00a 0x2400>;
> > +interrupts = <55>;
> > +   clocks = <&coreclk 0>;
> 
> nit. whitespace?

[Don't shoot the messenger]

How about extending checkpatch to check for this? I guess its just
spaces which should be tabs.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP

[Andrew Lunn]

> Now, about white spaces vs tab, I don't know what is the rule for .dts
> file.

I personally use tabs, but i don't see anything in the
Documentation/CodingStyle.

Maybe ask on the device tree mailing list?

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] ARM: dove: DT support for sdhci-dove

[Andrew Lunn]

+++ b/Documentation/devicetree/bindings/mmc/sdhci-dove.txt
@@ -0,0 +1,12 @@
+* Marvell sdhci-dove controller
+
+Required properties:
+- compatible: Should be "marvell,dove-sdhci".
+
+Example:
+
+sdio0: sdio@92000 {
+   compatible = "marvell,dove-sdhci";
+   reg = <0x92000 0x100>;
+   interrupts = <35>, <37>;


Hi Sebastian

Since there are two interrupts here, maybe it would be good to
document what each one is?

 Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] ARM: dove: Fix tauros2 device tree init

[Andrew Lunn]

On Tue, Sep 25, 2012 at 03:22:04AM +0200, Sebastian Hesselbarth wrote:
> On 09/25/2012 02:02 AM, Sebastian Hesselbarth wrote:
> >During the review process of dove DT patches, Tauros2 cache
> >init call was changed and DT support added. This patch fixes
> >the call to Tauros2 init and adds a DT node. Moreover, plat/irq.h
> >include was missing from mach-dove/common.c.
> > ...
> >diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
> >index b37bef1..343a4bc 100644
> >--- a/arch/arm/mach-dove/common.c
> >+++ b/arch/arm/mach-dove/common.c
> >@@ -32,6 +32,7 @@
> >  #include
> >  #include
> >  #include
> >+#include
> >  #include
> >  #include
> >  #include "common.h"
> >@@ -399,7 +400,7 @@ static void __init dove_dt_init(void)
> > (dove_tclk + 49) / 100);
> >
> >  #ifdef CONFIG_CACHE_TAUROS2
> >-tauros2_init();
> >+tauros2_init(0);
> >  #endif
> > dove_setup_cpu_mbus();
> >
> 
> I thought about the importance of the individual patches and
> except 2/6 all can wait for the next release cycle if too late.
> 
> But 2/6 is important because the change in tauros2_init
> breaks build on dove.

Hi Sebastian

Interestingly, kisskb does not show this break:

http://kisskb.ellerman.id.au/kisskb/config/308/

and yesterdays build does not have the parameter to tauros2_init().
Is the cache not enabled in dove_defconfig?

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

On Tue, Sep 25, 2012 at 02:02:17AM +0200, Sebastian Hesselbarth wrote:
> The watchdog on dove requires an interrupt that is not yet
> available on DT. Therefore, the watchdog DT node is removed
> until the corresponding chained intc is available.

Hi Sebastian

Just for my understanding: Is the problem here:

/* Clear watchdog timer interrupt */
reg = readl(BRIDGE_CAUSE);
reg &= ~WDT_INT_REQ;
writel(reg, BRIDGE_CAUSE);

I ask, because there is no need to pass an interrupt in the DT node.

It is clear to me that bit of code above needs cleaning up sometime
soon.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] Dove fixes for arm-soc/for-next

[Andrew Lunn]

On Tue, Sep 25, 2012 at 02:02:12AM +0200, Sebastian Hesselbarth wrote:
> With the current speed of changes within arm kernel tree, there
> have been some issues related to the mach-dove DT support patches
> introduced lately. This patch set keeps up with the changes between
> initial patch submission and current status of arm-soc/for-next.
> 
> Sebastian Hesselbarth (6):
>   ARM: dove: Add pcie clock support
>   ARM: dove: Fix tauros2 device tree init
>   ARM: dove: Fix clock names of sata and gbe
>   ARM: dove: Restructure SoC device tree descriptor
>   ARM: dove: Remove watchdog from DT
>   ARM: dove: Add crypto engine to DT
> 
>  arch/arm/boot/dts/dove.dtsi |   49 
> ---
>  arch/arm/mach-dove/common.c |8 +++
>  arch/arm/mach-dove/pcie.c   |5 +
>  3 files changed, 41 insertions(+), 21 deletions(-)

Its a bit late, Jason has already sent the pull request. But:

Acked-by: Andrew Lunn 

None of my questions should be considered as NACKs for these patches.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

On Tue, Sep 25, 2012 at 11:18:26AM +0200, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
> 
> On Tue, 25 Sep 2012 11:11:42 +0200, Sebastian Hesselbarth wrote:
> 
> > I didn't try to post all the dove on mach-mvebu patches in the current
> > release cycle, because mach-mvebu is still evolving to fast for me to keep
> > up with my limited spare time. But I have dove running on mach-mvebu...
> 
> Yes, this work is really great. However, I think that instead of making
> a big change at once, we should rather follow something like:
> 
>  * Make mach-dove, mach-kirkwood, mach-orion5x, mach-mv78xx0 use the
>new gpio/pinctrl code

I principle, i agree. However, i'm not too sure about mach-orion5x &
mach-mv78xx0. orion5x has probably been broken since -rc1 was released
and nobody noticed. In the same time, we got around 5 people
independently reporting kirkwood was broken. We have not received any
new boards for orion5x in the time i've been looking at Orion
platforms. mv78xx0 only has one board which is not a Marvell reference
design. So im tempted to not spend any effort moving orion5x or
mv78xx0 to DT unless these actually hinder the effort of moving the
others to DT.  What may make sense is to flatten mv78xx0 and orion5x
into plat-orion and then just watch the bit-rot happen.

I have patches which convert all existing DT based kirkwood boards to
the new gpio/pinctrl code. There are two outstanding issues:

1) I've no idea which kirkwood variant each board uses. Hence the
   compatibility string will be wrong for a lot of them.

2) I'm probably made lots of dumb typos.

So we need to get board maintainers to complete and test the work.

>  * Refactor the PCI code so that it can cover all cases. We should soon
>be working on PCI support on Armada 370/XP, so it will show what are
>the differences/issues in having something that covers all cases.

Have you looked at the orion5x PCI code? Its very different to all the
others and i doubt it will be easy to make work with all the others.

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] ARM: dove: Remove watchdog from DT

[Andrew Lunn]

On Tue, Sep 25, 2012 at 12:14:39PM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Tue, 25 Sep 2012 11:46:10 +0200, Andrew Lunn wrote:
> 
> > I principle, i agree. However, i'm not too sure about mach-orion5x &
> > mach-mv78xx0. orion5x has probably been broken since -rc1 was released
> > and nobody noticed. In the same time, we got around 5 people
> > independently reporting kirkwood was broken. We have not received any
> > new boards for orion5x in the time i've been looking at Orion
> > platforms. mv78xx0 only has one board which is not a Marvell reference
> > design. So im tempted to not spend any effort moving orion5x or
> > mv78xx0 to DT unless these actually hinder the effort of moving the
> > others to DT.  What may make sense is to flatten mv78xx0 and orion5x
> > into plat-orion and then just watch the bit-rot happen.
> 
> I'll try to see if I can get people from LaCie to test mach-orion5x as
> I have a few contacts there, and I'll contact Marvell to see if they can
> still provide Orion-based platforms.

Marvell supplied my one one reference platform. So i can do some
testing that the basic infrastructure works.

But the problem with converting to DT is that there is a lot of
brainless monkey work needed per supported board, and its very easy to
make a typo. So each board converted to DT needs testing. I don't know
if we can find testers for all the boards. But should we throw out
working boards just because we cannot find somebody to test the DT
version?

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Andrew Lunn]

> diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
> new file mode 100644
> index 000..88a5a11
> --- /dev/null
> +++ b/arch/arm/boot/dts/mbx001.dts

Hi Gregory

Maybe it would be good to prefix this with armada-370. It then fits
with armada-370-db.dts, and all the kirkwood files are kirkwood-*.dts.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Regulator: core: Unregister when gpio request fails.

[Andrew Lunn]

If the gpio_request_one() fails, or returns EPROBE_DEFER, the
regulator must be device_unregister()ed. When this is not done,
there are WARNING: from sysfs:

WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x238/0x268()

Signed-off-by: Andrew Lunn 
---
 drivers/regulator/core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5c4829c..aa4d28b 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3365,7 +3365,7 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
 config->ena_gpio, ret);
-   goto clean;
+   goto wash;
}
 
rdev->ena_gpio = config->ena_gpio;
@@ -3449,6 +3449,7 @@ scrub:
if (rdev->ena_gpio)
gpio_free(rdev->ena_gpio);
kfree(rdev->constraints);
+wash:
device_unregister(&rdev->dev);
/* device core frees rdev */
rdev = ERR_PTR(ret);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ARM: kirkwood: retain MAC address for DT ethernet

[Andrew Lunn]

On Thu, Oct 03, 2013 at 02:44:53PM +0200, Sebastian Hesselbarth wrote:
> Ethernet IP on Kirkwood SoCs loose their MAC address register content
> if clock gated. To allow modular ethernet driver setups and gated clocks
> also on non-DT capable bootloaders, we fixup port device nodes with no
> valid MAC address property. This patch copies MAC address register
> contents set up by bootloaders early, notably before ethernet clocks
> are gated. While at it, also reorder call sequence in _dt_init.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> - Added Benjamin and Grant who where part of the discussion last time
>   and gave valuable input on DT fixups.
> - Patches are based on v3.12-rc1 and depend on latest mv643xx_eth
>   fixes applied yesterday by David Miller [1].
> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=569943d0639c85a451ea853087cbd5f738247dd9
> 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Russell King 
> Cc: Grant Likely 
> Cc: Benjamin Herrenschmidt 
> Cc: Jason Gunthorpe 
> Cc: Ezequiel Garcia 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-kirkwood/board-dt.c |   72 
> +++--
>  1 file changed, 69 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-kirkwood/board-dt.c 
> b/arch/arm/mach-kirkwood/board-dt.c
> index 82d3ad8..a2974ad 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -66,6 +68,71 @@ static void __init kirkwood_legacy_clk_init(void)
>   clk_prepare_enable(clk);
>  }
>  
> +#define MV643XX_ETH_MAC_ADDR_LOW 0x0414
> +#define MV643XX_ETH_MAC_ADDR_HIGH0x0418
> +
> +static void __init kirkwood_dt_eth_fixup(void)
> +{
> + struct device_node *np;
> +
> + /*
> +  * The ethernet interfaces forget the MAC address assigned by u-boot
> +  * if the clocks are turned off. Usually, u-boot on kirkwood boards
> +  * has no DT support to properly set local-mac-address property.
> +  * As a workaround, we get the MAC address from mv643xx_eth registers
> +  * and update the port device node if no valid MAC address is set.
> +  */
> + for_each_compatible_node(np, NULL, "marvell,kirkwood-eth-port") {
> + struct device_node *pnp = of_get_parent(np);
> + struct property *pmac;
> + void __iomem *io;
> + u8 *macaddr;
> + u32 reg;
> +
> + if (!pnp || !of_device_is_available(pnp))
> + continue;
> +
> + if (of_get_mac_address(np))
> + continue;
> +
> + pr_err(FW_BUG "%s: local-mac-address is not set\n",
> +np->full_name);
> +
> + io = of_iomap(pnp, 0);
> + if (!io)
> + continue;
> +
> + pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
> + if (!pmac) {
> + iounmap(io);
> + continue;
> + }
> +
> + pmac->value = pmac + 1;
> + pmac->length = 6;
> + pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
> + if (!pmac->name) {
> + kfree(pmac);
> + iounmap(io);
> + continue;
> + }
> +
> + macaddr = pmac->value;
> + reg = readl(io + MV643XX_ETH_MAC_ADDR_HIGH);
> + macaddr[0] = (reg >> 24) & 0xff;
> + macaddr[1] = (reg >> 16) & 0xff;
> + macaddr[2] = (reg >> 8) & 0xff;
> + macaddr[3] = reg & 0xff;

Hi Sebastian

What happens if at this point, the ethernet clock is gated off?  I
assume the CPU locks solid, requiring a power cycle.

It would be a bit of an odd situation, u-boot has disabled the clock,
yet we have a DT node for the device and no valid local-mac-address.
We do however know that Jason Gunthorpe u-boot does gate the second
ethernet for his board, so it is not completely impossible to hit this
situation, particularly when bringing up a new board.

Are we too early in the boot to actually use the clock information in
the node to find it, and clk_prepare_enable() it before making the
access?

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] ARM: kirkwood: retain MAC address for DT ethernet

[Andrew Lunn]

> Sebastian, does __clk_enabled work properly for the mvebu clock
> provider? I don't see a clk_ops.is_enabled for mvebu.. (don't know
> much about clk)

Hi Jason

It is implemented in drivers/clk/clk-gate.c, which is what mvebu is
using.

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: provide public clk_is_enabled function

[Andrew Lunn]

On Fri, Oct 04, 2013 at 12:08:30PM +0200, Sebastian Hesselbarth wrote:
> To determine if a clk has been previously enabled, provide a public
> clk_is_enabled function. This is especially helpful to check the state
> of clk-gate without actually changing the state of the gate.
> 
> Signed-off-by: Sebastian Hesselbarth 

Tested-by: Andrew Lunn 

   Andrew


> ---
> Cc: Mike Turquette 
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Grant Likely 
> Cc: Benjamin Herrenschmidt 
> Cc: Jason Gunthorpe 
> Cc: Ezequiel Garcia 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/clk/clk.c   |   18 ++
>  include/linux/clk.h |   13 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index a004769..26698d3 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -929,6 +929,24 @@ int clk_enable(struct clk *clk)
>  EXPORT_SYMBOL_GPL(clk_enable);
>  
>  /**
> + * clk_is_enabled - return the enabled state of a clk
> + * @clk: the clk whose enabled state gets returned
> + *
> + * Returns true if the clock is enabled, false otherwise.
> + */
> +bool clk_is_enabled(struct clk *clk)
> +{
> + bool is_en;
> +
> + clk_prepare_lock();
> + is_en = __clk_is_enabled(clk);
> + clk_prepare_unlock();
> +
> + return is_en;
> +}
> +EXPORT_SYMBOL_GPL(clk_is_enabled);
> +
> +/**
>   * __clk_round_rate - round the given rate for a clk
>   * @clk: round the rate of this clock
>   * @rate: the rate which is to be rounded
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 9a6d045..8cbf2f7 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -187,6 +187,14 @@ int clk_enable(struct clk *clk);
>  void clk_disable(struct clk *clk);
>  
>  /**
> + * clk_is_enabled - return the enabled state of a clk
> + * @clk: the clk whose enabled state gets returned
> + *
> + * Returns true if the clock is enabled, false otherwise.
> + */
> +bool clk_is_enabled(struct clk *clk);
> +
> +/**
>   * clk_get_rate - obtain the current clock rate (in Hz) for a clock source.
>   * This is only valid once the clock source has been enabled.
>   * @clk: clock source
> @@ -299,6 +307,11 @@ static inline int clk_enable(struct clk *clk)
>  
>  static inline void clk_disable(struct clk *clk) {}
>  
> +static inline bool clk_is_enabled(struct clk *clk)
> +{
> + return false;
> +}
> +
>  static inline unsigned long clk_get_rate(struct clk *clk)
>  {
>   return 0;
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND v3] ARM: kirkwood: retain MAC address for DT ethernet

[Andrew Lunn]

On Fri, Oct 04, 2013 at 12:17:22PM +0200, Sebastian Hesselbarth wrote:
> Ethernet IP on Kirkwood SoCs loose their MAC address register content
> if clock gated. To allow modular ethernet driver setups and gated clocks
> also on non-DT capable bootloaders, we fixup port device nodes with no
> valid MAC address property. This patch copies MAC address register
> contents set up by bootloaders early, notably before ethernet clocks
> are gated. While at it, also reorder call sequence in _dt_init.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v2->v3:
> - make use of new public clk_is_enabled (adds dependency [1])
> - add warning about gated clock && missing MAC property
>   (Suggested by Jason Gunthorpe)
> v1->v2:
> - check for gated clock before accessing eth registers
>   (Suggested by Andrew Lunn)
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg277392.html
> 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Russell King 
> Cc: Grant Likely 
> Cc: Benjamin Herrenschmidt 
> Cc: Jason Gunthorpe 
> Cc: Ezequiel Garcia 
> Cc: Mike Turquette 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-kirkwood/board-dt.c |   85 
> +++--
>  1 file changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-kirkwood/board-dt.c 
> b/arch/arm/mach-kirkwood/board-dt.c
> index 82d3ad8..28e952b 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -66,6 +68,84 @@ static void __init kirkwood_legacy_clk_init(void)
>   clk_prepare_enable(clk);
>  }
>  
> +#define MV643XX_ETH_MAC_ADDR_LOW 0x0414
> +#define MV643XX_ETH_MAC_ADDR_HIGH0x0418
> +
> +static void __init kirkwood_dt_eth_fixup(void)
> +{
> + struct device_node *np;
> +
> + /*
> +  * The ethernet interfaces forget the MAC address assigned by u-boot
> +  * if the clocks are turned off. Usually, u-boot on kirkwood boards
> +  * has no DT support to properly set local-mac-address property.
> +  * As a workaround, we get the MAC address from mv643xx_eth registers
> +  * and update the port device node if no valid MAC address is set.
> +  */
> + for_each_compatible_node(np, NULL, "marvell,kirkwood-eth-port") {
> + struct device_node *pnp = of_get_parent(np);
> + struct clk *clk;
> + struct property *pmac;
> + void __iomem *io;
> + u8 *macaddr;
> + u32 reg;
> +
> + if (!pnp)
> + continue;
> +
> + /* skip disabled nodes or nodes with valid MAC address*/
> + if (!of_device_is_available(pnp) || of_get_mac_address(np))
> + continue;
> +
> + /* skip already gated ports, spill warning about missing MAC */
> + clk = of_clk_get(pnp, 0);
> + if (!clk_is_enabled(clk)) {
> + pr_err(FW_BUG "%s: gated port has no local-mac-address 
> set\n",
> +np->full_name);
> + clk_put(clk);
> + continue;
> + }
> + clk_put(clk);
> +
> + /* store MAC address register contents in local-mac-address */
> + pr_err(FW_BUG "%s: local-mac-address is not set\n",
> +np->full_name);

Hi Sebastian

I've tested on Kirkwood with a modular build. Works as expected.

My only question is the pr_err(FW_BUF above. My guess is, 99% of
orion5x, kirkwood, and Dove systems will never get a U-boot with DT
support, which sets the local-mac-address property. I would drop it
down to FW_INFO, or drop the message altogether.

Otherwise,

Tested-by: Andrew Lunn 

   Andrew

> +
> + io = of_iomap(pnp, 0);
> + if (!io)
> + continue;
> +
> + pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
> + if (!pmac) {
> + iounmap(io);
> + continue;
> + }
> +
> + pmac->value = pmac + 1;
> + pmac->length = 6;
> + pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
> + if (!pmac->name) {
> + kfree(pmac);
> + iounmap(io);
> + continue;
> + }
> +
> + macaddr = pmac->value;
> + reg = readl(io + MV643XX_ET

Re: [PATCH] clk: provide public clk_is_enabled function

[Andrew Lunn]

On Sat, Oct 05, 2013 at 10:24:30PM +0200, Uwe Kleine-König wrote:
> On Fri, Oct 04, 2013 at 12:08:30PM +0200, Sebastian Hesselbarth wrote:
> > To determine if a clk has been previously enabled, provide a public
> > clk_is_enabled function. This is especially helpful to check the state
> > of clk-gate without actually changing the state of the gate.
> I wonder what you want to do with the return value.
> 
> When doing
> 
>   if (clk_is_enabled(someclk))
>   do_something();
> 
> you cannot in general know if the clock is still on when you start to
> do_something.

Hi Uwe

At least in the use case Sebastian needs it for, we don't need an "in
general" solution. It is used early boot time to see if the boot
loader left the clock running. The other user of the clock is the
ethernet driver, which we know cannot change it yet, because driver
probing has not started yet.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: provide public clk_is_enabled function

[Andrew Lunn]

On Sun, Oct 06, 2013 at 11:06:09AM +0200, Gerhard Sittig wrote:
> On Sat, Oct 05, 2013 at 22:42 +0200, Andrew Lunn wrote:
> > 
> > On Sat, Oct 05, 2013 at 10:24:30PM +0200, Uwe Kleine-König wrote:
> > > On Fri, Oct 04, 2013 at 12:08:30PM +0200, Sebastian Hesselbarth wrote:
> > > > To determine if a clk has been previously enabled, provide a public
> > > > clk_is_enabled function. This is especially helpful to check the state
> > > > of clk-gate without actually changing the state of the gate.
> > > I wonder what you want to do with the return value.
> > > 
> > > When doing
> > > 
> > >   if (clk_is_enabled(someclk))
> > >   do_something();
> > > 
> > > you cannot in general know if the clock is still on when you start to
> > > do_something.
> > 
> > Hi Uwe
> > 
> > At least in the use case Sebastian needs it for, we don't need an "in
> > general" solution. It is used early boot time to see if the boot
> > loader left the clock running.
> 
> Wait, unless I'm missing something, the clk_is_enabled() call
> _won't_ determine whether the clock is enabled in hardware
> (whether the boot loader created or left this condition), instead
> it only determines whether clk_enable() was called previously and
> thus the clock _shall_ be enabled.

Nope, you are wrong.

static int clk_gate_is_enabled(struct clk_hw *hw)
{
u32 reg;
struct clk_gate *gate = to_clk_gate(hw);

reg = clk_readl(gate->reg);

/* if a set bit disables this clk, flip it before masking */
if (gate->flags & CLK_GATE_SET_TO_DISABLE)
   reg ^= BIT(gate->bit_idx);

   reg &= BIT(gate->bit_idx);

   return reg ? 1 : 0;
}

It reads the hardware state.

> AFAIK the kernel's CCF support is "self contained" and does not
> consider any data or state that was "inherited" from boot staged
> before the kernel.  That's why the "disable unused" step disables
> everything that wasn't acquired _in the kernel_ regardless of
> what the boot loader may have done or what is enabled at reset.

Not quite true. It uses the is_enabled(), which gets the real hardware
state, to turn off clocks which are unused but on. It will not turn
off clock which are already off. So it is inheriting some state from
the boot loader, in that it knows if the bootloader turned it
on. However this is not propagated into prepare/enable status.

> > The other user of the clock is the
> > ethernet driver, which we know cannot change it yet, because driver
> > probing has not started yet.
> 
> I understand that the situation here is, that the ethernet driver
> hasn't probed yet, but the clock driver did.  You are in early setup
> code and want to (check and) fetch data from the hardware which the
> ethernet driver later needs.

Nearly, but not quite. If there is an enabled DT node for the device,
and that node does not have a valid local-mac-address property in the
node, the bootloader should of programmed the MAC address into the
device. If it has done that, the clock should be running, because as
soon as you turn the clock off, it forgets the MAC address. Thus, if
we find an enabled device in DT, without a valid local-mac-address,
and the clock is off, we have a bootloader bug, which we want to
report.

> What's wrong with an explicit enable/disable around the data
> acquisition?

It avoids the CPU locking hard, but will not get us a valid MAC
address, which is the point of the exercise.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: provide public clk_is_enabled function

[Andrew Lunn]

> Andrew has mentioned, that some bootloaders might disable clocks but
> leave the nodes enabled. Reading those registers would lock up
> the HW, of course. So we thought about to check clk gate status first,
> which this patch is about.
> 
> Of course, we can do clk_enable, read, clk_disable as said before - and
> given the amount of questions and misinterpretation, I think it is the
> saner way.

Hi Sebastian

I agree. As you say, too many people have asked questions or
misinterpretation what is happening, so lets go for the simpler method
people can understand.

I would also suggest in the ethernet driver, maybe set_params(), check
if we have a valid MAC address, and if not, issue a warning and call
to eth_hw_addr_random(dev) to get a random one.

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 069/228] cpufreq: kirkwood: Use generic cpufreq routines

[Andrew Lunn]

On Fri, Sep 13, 2013 at 06:30:15PM +0530, Viresh Kumar wrote:
> Most of the CPUFreq drivers do similar things in .exit() and .verify() 
> routines
> and .attr. So its better if we have generic routines for them which can be 
> used
> by cpufreq drivers then.
> 
> This patch uses these generic routines for this driver.
> 
> Cc: Andrew Lunn 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 22 +++---
>  1 file changed, 3 insertions(+), 19 deletions(-)

Hi Viresh

You can add:

Tested-by: Andrew Lunn 

to

[PATCH 069/228] cpufreq: kirkwood: Use generic cpufreq routines
[PATCH 107/228] cpufreq: kirkwood: don't initialize part of policy that is set 
by core
[PATCH 161/228] cpufreq: kirkwood: Convert to light weight ->target_index() 
routine
[PATCH 195/228] cpufreq: kirkwood: remove calls to cpufreq_notify_transition()

It does however require the patch:

http://www.spinics.net/lists/arm-kernel/msg273378.html

but this is not because of this patch series, it was already broken.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 195/228] cpufreq: kirkwood: remove calls to cpufreq_notify_transition()

[Andrew Lunn]

On Fri, Sep 13, 2013 at 06:32:21PM +0530, Viresh Kumar wrote:

> - if (freqs.old != freqs.new) {
> - local_irq_disable();
> -
> - /* Disable interrupts to the CPU */
> - reg = readl_relaxed(priv.base);
> - reg |= CPU_SW_INT_BLK;
> - writel_relaxed(reg, priv.base);
> -
> - switch (state) {
> - case STATE_CPU_FREQ:
> - clk_disable(priv.powersave_clk);
> - break;
> - case STATE_DDR_FREQ:
> - clk_enable(priv.powersave_clk);
> - break;
> - }

Hi Viresh

I see you removed the test that the old and the new frequency are
different. Is this guaranteed by the core? Because if not, you can
lockup the CPU. The call to cpu_do_idle() will never return.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/26] ARM: dove: remove custom .init_time hook

[Andrew Lunn]

On Wed, Sep 18, 2013 at 07:53:44PM +0200, Sebastian Hesselbarth wrote:
> With arch/arm calling of_clk_init(NULL) from time_init(), we can now
> remove custom .init_time hooks. While at it, also remove some obsolete
> includes.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Olof Johansson 
> Cc: Arnd Bergmann 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-dove/board-dt.c |   11 ---
>  1 file changed, 11 deletions(-)

Hi Sebastian

Boot tested on cubox.

Tested-by: Andrew Lunn 

   Andrew

> 
> diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
> index 49f72a8..ddb8663 100644
> --- a/arch/arm/mach-dove/board-dt.c
> +++ b/arch/arm/mach-dove/board-dt.c
> @@ -10,17 +10,13 @@
>  
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "common.h"
>  
>  /*
> @@ -45,12 +41,6 @@ static void __init dove_legacy_clk_init(void)
>of_clk_get_from_provider(&clkspec));
>  }
>  
> -static void __init dove_dt_time_init(void)
> -{
> - of_clk_init(NULL);
> - clocksource_of_init();
> -}
> -
>  static void __init dove_dt_init_early(void)
>  {
>   mvebu_mbus_init("marvell,dove-mbus",
> @@ -84,7 +74,6 @@ static const char * const dove_dt_board_compat[] = {
>  DT_MACHINE_START(DOVE_DT, "Marvell Dove (Flattened Device Tree)")
>   .map_io = dove_map_io,
>   .init_early = dove_dt_init_early,
> - .init_time  = dove_dt_time_init,
>   .init_machine   = dove_dt_init,
>   .restart= dove_restart,
>   .dt_compat  = dove_dt_board_compat,
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 15/26] ARM: kirkwood: remove custom .init_time hook

[Andrew Lunn]

On Wed, Sep 18, 2013 at 07:53:48PM +0200, Sebastian Hesselbarth wrote:
> With arch/arm calling of_clk_init(NULL) from time_init(), we can now
> remove custom .init_time hooks.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Olof Johansson 
> Cc: Arnd Bergmann 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-kirkwood/board-dt.c |8 
>  1 file changed, 8 deletions(-)


Hi Sebastian

Boot tested on a Kirkwood Topkick.

Tested-by: Andrew Lunn 

   Andrew

> 
> diff --git a/arch/arm/mach-kirkwood/board-dt.c 
> b/arch/arm/mach-kirkwood/board-dt.c
> index 82d3ad8..a32a3e5 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -15,7 +15,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -66,12 +65,6 @@ static void __init kirkwood_legacy_clk_init(void)
>   clk_prepare_enable(clk);
>  }
>  
> -static void __init kirkwood_dt_time_init(void)
> -{
> - of_clk_init(NULL);
> - clocksource_of_init();
> -}
> -
>  static void __init kirkwood_dt_init_early(void)
>  {
>   mvebu_mbus_init("marvell,kirkwood-mbus",
> @@ -122,7 +115,6 @@ DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood 
> (Flattened Device Tree)")
>   /* Maintainer: Jason Cooper  */
>   .map_io = kirkwood_map_io,
>   .init_early = kirkwood_dt_init_early,
> - .init_time  = kirkwood_dt_time_init,
>   .init_machine   = kirkwood_dt_init,
>   .restart= kirkwood_restart,
>   .dt_compat  = kirkwood_dt_board_compat,
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/26] ARM: dove: remove custom .init_time hook

[Andrew Lunn]

On Sun, Sep 22, 2013 at 02:20:28PM +0200, Sebastian Hesselbarth wrote:
> On 09/21/2013 02:22 PM, Andrew Lunn wrote:
> >On Wed, Sep 18, 2013 at 07:53:44PM +0200, Sebastian Hesselbarth wrote:
> >>With arch/arm calling of_clk_init(NULL) from time_init(), we can now
> >>remove custom .init_time hooks. While at it, also remove some obsolete
> >>includes.
> >>
> >>Signed-off-by: Sebastian Hesselbarth 
> >>---
> >>Cc: Olof Johansson 
> >>Cc: Arnd Bergmann 
> >>Cc: Jason Cooper 
> >>Cc: Andrew Lunn 
> >>Cc: Russell King 
> >>Cc: linux-arm-ker...@lists.infradead.org
> >>Cc: linux-kernel@vger.kernel.org
> >>---
> >>  arch/arm/mach-dove/board-dt.c |   11 ---
> >>  1 file changed, 11 deletions(-)
> [...]
> >Boot tested on cubox.
> >
> >Tested-by: Andrew Lunn 
> 
> Thanks Andrew!
> 
> Aren't you giving any Acks for dove/kirkwood anymore?

Hi Sebastian

In my opinion, a Tested-by: has more weight than an Acked-by. I could
of given you an Acked-by in about 60 seconds, given the simplicity of
the patch. It took a lot more effort to get your tree, build it, fix
my binutils, since it was the first 3.12 tree i had tried and my
binutils was too old, and boot it.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4 v2] gpio/mvebu: convert to use irq_domain_add_simple()

[Andrew Lunn]

On Fri, Oct 19, 2012 at 12:54:02PM +0200, Linus Walleij wrote:
> The MVEBU driver probably just wants a few IRQs. Using the simple
> domain has the upside of allocating IRQ descriptors if need be,
> especially in a SPARSE_IRQ environment.
> 
> Cc: Rob Herring 
> Cc: Grant Likely 
> Cc: Thomas Petazzoni 
> Cc: Sebastian Hesselbarth 
> Cc: Andrew Lunn 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Keep irq_create_mapping() and do not replace with
>   irq_find_mapping() - if a linear domain is the outcome,
>   we really need to allocate a descriptor on the first mapping
>   call.
> ---
>  drivers/gpio/gpio-mvebu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index 902af43..e0bde06 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -645,8 +645,8 @@ static int __devinit mvebu_gpio_probe(struct 
> platform_device *pdev)
>  IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
>  
>   /* Setup irq domain on top of the generic chip. */
> - mvchip->domain = irq_domain_add_legacy(np, mvchip->chip.ngpio,
> -mvchip->irqbase, 0,
> + mvchip->domain = irq_domain_add_simple(np, mvchip->chip.ngpio,
> +mvchip->irqbase,
>  &irq_domain_simple_ops,
>  mvchip);
>   if (!mvchip->domain) {
> -- 
> 1.7.11.7
> 

Hi Linus

I tested this on a kirkwood QNAP NAS box. gpio-keys still work and
generate interrupts etc.

Tested-by: Andrew Lunn 

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer

[Andrew Lunn]

On Fri, Dec 07, 2012 at 03:55:07PM -0700, Jason Gunthorpe wrote:
> The intent of this patch is to expose the other bridge cause
> interrupts to users in the kernel.
> 
> - Add orion_bridge_irq_init to create a new edge triggered interrupt
>   chip based on the bridge cause register
> - Remove all interrupt register code from time.c and use normal
>   interrupt functions instead
> - Update the machines that use orion_time_init to call
>   orion_bridge_irq_init and use the new signature

Hi Jason

I like the idea, but i think it needs to go a bit further. 

1) It should have an IRQ domain, like the other IRQ chips we have.
2) It should have a DT binding, like the other IRQ chips we have.
3) We then pass the timer interrupt via DT to the timer driver.
4) We than pass the watchdog interrupt via DT.

We plan to remove old style platforms in the next few cycles, so its
important that changes like this are orientated towards DT but have
the necessary backward compatibility for the old ways for the boards
not yet converted. I think for Dove all boards are DT based...

3) is not so simple, because we currently don't have a timer binding
for Orion SoC. However, with this cleanup, we are much closer to being
able to use the 370/XP timer code.


> @@ -534,8 +535,9 @@ static void __init kirkwood_timer_init(void)
>  {
>   kirkwood_tclk = kirkwood_find_tclk();
>  
> - orion_time_init(BRIDGE_VIRT_BASE, BRIDGE_INT_TIMER1_CLR,
> - IRQ_KIRKWOOD_BRIDGE, kirkwood_tclk);
> + orion_bridge_irq_init(IRQ_KIRKWOOD_BRIDGE, IRQ_KIRKWOOD_BRIDGE_START,
> +   BRIDGE_CAUSE);
> + orion_time_init(IRQ_KIRKWOOD_BRIDGE_TIMER1, kirkwood_tclk);
>  }

I think it would be better to do this in kirkwood_init_irq(). Same for
the other platforms. 

> +static void bridge_irq_handler(unsigned irq, struct irq_desc *desc)
> +{
> + struct irq_chip_generic *gc = irq_get_handler_data(irq);
> + u32 cause;
> + int i;
> +
> + cause = readl(gc->reg_base) & readl(gc->reg_base + 4);

Could you add a #define for this 4. I guess its an interrupt enable
mask? Could regs.mask be used?

> + for (i = 0; i < 6; i++)
> + if ((cause & (1 << i)))
> + generic_handle_irq(i + gc->irq_base);
> +}
> +
> +static void irq_gc_eoi_inv(struct irq_data *d)
> +{
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + u32 mask = 1 << (d->irq - gc->irq_base);
> + struct irq_chip_regs *regs;
> +
> + regs = &container_of(d->chip, struct irq_chip_type, chip)->regs;
> + irq_gc_lock(gc);
> + irq_reg_writel(~mask, gc->reg_base + regs->eoi);
> + irq_gc_unlock(gc);
> +}
> +
> +void __init orion_bridge_irq_init(unsigned int bridge_irq,
> +   unsigned int irq_start,
> +   void __iomem *causeaddr)
> +{
> + struct irq_chip_generic *gc;
> + struct irq_chip_type *ct;
> +
> + gc = irq_alloc_generic_chip("orion_irq_edge", 1, irq_start,

Maybe the name orion_bridge would be better?

Thanks
  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer

[Andrew Lunn]

On Sat, Dec 08, 2012 at 07:57:48PM -0700, Jason Gunthorpe wrote:
> On Sat, Dec 08, 2012 at 12:26:24PM +0100, Andrew Lunn wrote:
>  
> > 1) It should have an IRQ domain, like the other IRQ chips we have.
> > 2) It should have a DT binding, like the other IRQ chips we have.
> 
> I was going to look at a DT binding for this as a follow on, since
> I'll want to bind to these interrupts. 
> 
> Are you OK with keeping this patch as is and seeing DT in a follow up,
> or as a series? It is already pretty big.

Hi Jason

A patch series is great. However, its not so good practice to add
something on the first patch, and then move it somewhere else in the
next. So i would suggest initializing the controller in
kirkwood_irq_init(), etc as its added.

> > 4) We than pass the watchdog interrupt via DT.
> 
> Right now the watchdog driver is coded to cause a board reset, so it
> doesn't use interrupts at all. Adding interrupt support to watchdog
> seems orthogonal to this?

Yes, its orthogonal, but a logical extension which could be part of a
patchset.
 
> What would it look like? For my boards I want the watchdog to panic(),
> because I have another watchdog that takes care of reset, but that
> won't be universal.

There are examples of watchdogs that allow this. However, none yet
have DT bindings. I would suggest adding an optional property,
"panic", which indicates the driver should panic rather than
reboot. Make sure to run this by the device tree mailing list.
 
> > 3) We then pass the timer interrupt via DT to the timer driver.
> > 3) is not so simple, because we currently don't have a timer binding
> > for Orion SoC. However, with this cleanup, we are much closer to being
> > able to use the 370/XP timer code.
> 
> Interesting.. The 370/XP is a more advanced version of the same timer
> IP, there are several registers that driver is touching that are not
> HW supported, at least on kirkwood.

Yes, the 25MHz and the divider for example. I'm not 100% sure it will
actually work, it will need a different compatibility string, and a
bit of configuration based on that string, but i think it goes. If you
compare the two different drivers, they are very similar.

> The two DT bindings are straightforward, and my testing on Kirkwood
> should cover alot - but it would be great if non-kirkwood boards could
> review/test with this patch..
> 
> Do you expect a DT conversion for all orion_time_init users, or just
> the one I can test or ..?

Please take a stab at converting them all. We have an active set of
testers. I can test kirkwood and orion5x, Sebastian tests Dove, Thomas
and Gregory test 370/XP if needed. Nobody seems to care about mv78xx0
so its slowly bit-rotting in a corner.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
> On 11.11.2012 18:22, Andrew Lunn wrote:
> > On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> >> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless
> >> the flags provided by the caller. This causes excessive pruning of
> >> emergency memory pools without any good reason. This patch
> changes the code
> >> to correctly use gfp flags provided by the dmapool caller. This should
> >> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
> >> allocations can be served only from the special, very limited
> memory pool.
> >>
> >> Reported-by: Soren Moch 
> Please use
> Reported-by: Soeren Moch 
> 
> >> Reported-by: Thomas Petazzoni 
> >> Signed-off-by: Marek Szyprowski 
> >
> > Tested-by: Andrew Lunn 
> >
> > I tested this on a Kirkwood QNAP after removing the call to
> > init_dma_coherent_pool_size().
> >
> > Andrew
> 
> Tested-by: Soeren Moch 
> 
> Now I had a chance to test this patch on my Kirkwood guruplug
> system with linux-3.6.6 . It is running much better now, but with the
> original 256K coherent pool size I still see errors after several hours
> of runtime:
> 
> Nov 12 09:42:32 guru kernel: ERROR: 256 KiB atomic DMA coherent pool
> is too small!
> Nov 12 09:42:32 guru kernel: Please increase it with coherent_pool=
> kernel parameter!

Hi Soeren

Could you tell us what DVB devices you are using.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP

[Andrew Lunn]

On Tue, Nov 06, 2012 at 10:28:45PM +0100, S?ren Moch wrote:
> resent as plain text, sorry.
> 
> 
> > For Armada 370/XP we have the same problem that for the commit
> > cb01b63, so we applied the same solution: "The default 256 KiB
> > coherent pool may be too small for some of the Kirkwood devices, so
> > increase it to make sure that devices will be able to allocate their
> > buffers with GFP_ATOMIC flag"
> 
> I see a regression from linux-3.5 to linux-3.6 and think there might
> be a fundamental problem
> with this patch. On my Kirkwood system (guruplug server plus) with
> linux-3.6.2 I see following
> errors and corresponding malfunction even with further increased
> (2M, 4M) pool size:
> 
> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
> pool is too small!
> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
> kernel parameter!
> 
> So I had to downgrade to linux-3.5 which is running without problems.
> 
> I use SATA and several DVB sticks (em28xx / drxk and dib0700).

I'm guess its the DVB sticks which are causing the problems. We have a
number of kirkwood devices with two SATA devices which had problems
until we extended the coherent_pool. The DVB sticks are probably take
more coherent RAM. There was also an issue found recently:

http://www.spinics.net/lists/arm-kernel/msg203962.html

That conversation has gone quiet, but that could be because the
participants are at ELCE.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the caller. This causes excessive pruning of
> emergency memory pools without any good reason. This patch changes the code
> to correctly use gfp flags provided by the dmapool caller. This should
> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
> allocations can be served only from the special, very limited memory pool.
> 
> Reported-by: Soren Moch 
> Reported-by: Thomas Petazzoni 
> Signed-off-by: Marek Szyprowski 

Tested-by: Andrew Lunn 

I tested this on a Kirkwood QNAP after removing the call to
init_dma_coherent_pool_size().

Andrew


> ---
>  mm/dmapool.c |   27 +++
>  1 file changed, 7 insertions(+), 20 deletions(-)
> 
> diff --git a/mm/dmapool.c b/mm/dmapool.c
> index c5ab33b..86de9b2 100644
> --- a/mm/dmapool.c
> +++ b/mm/dmapool.c
> @@ -62,8 +62,6 @@ struct dma_page {   /* cacheable header for 
> 'allocation' bytes */
>   unsigned int offset;
>  };
>  
> -#define  POOL_TIMEOUT_JIFFIES((100 /* msec */ * HZ) / 1000)
> -
>  static DEFINE_MUTEX(pools_lock);
>  
>  static ssize_t
> @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool 
> *pool, gfp_t mem_flags)
>   memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
>  #endif
>   pool_initialise_page(pool, page);
> - list_add(&page->page_list, &pool->page_list);
>   page->in_use = 0;
>   page->offset = 0;
>   } else {
> @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t 
> mem_flags,
>   might_sleep_if(mem_flags & __GFP_WAIT);
>  
>   spin_lock_irqsave(&pool->lock, flags);
> - restart:
>   list_for_each_entry(page, &pool->page_list, page_list) {
>   if (page->offset < pool->allocation)
>   goto ready;
>   }
> - page = pool_alloc_page(pool, GFP_ATOMIC);
> - if (!page) {
> - if (mem_flags & __GFP_WAIT) {
> - DECLARE_WAITQUEUE(wait, current);
>  
> - __set_current_state(TASK_UNINTERRUPTIBLE);
> - __add_wait_queue(&pool->waitq, &wait);
> - spin_unlock_irqrestore(&pool->lock, flags);
> + /* pool_alloc_page() might sleep, so temporarily drop &pool->lock */
> + spin_unlock_irqrestore(&pool->lock, flags);
>  
> - schedule_timeout(POOL_TIMEOUT_JIFFIES);
> + page = pool_alloc_page(pool, mem_flags);
> + if (!page)
> + return NULL;
>  
> - spin_lock_irqsave(&pool->lock, flags);
> - __remove_wait_queue(&pool->waitq, &wait);
> - goto restart;
> - }
> - retval = NULL;
> - goto done;
> - }
> + spin_lock_irqsave(&pool->lock, flags);
>  
> + list_add(&page->page_list, &pool->page_list);
>   ready:
>   page->in_use++;
>   offset = page->offset;
> @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t 
> mem_flags,
>  #ifdef   DMAPOOL_DEBUG
>   memset(retval, POOL_POISON_ALLOCATED, pool->size);
>  #endif
> - done:
>   spin_unlock_irqrestore(&pool->lock, flags);
>   return retval;
>  }
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] clk: mvebu: armada 370/XP add clock gating control provider for DT

[Andrew Lunn]

Hi Gregory

Nice work

On Fri, Nov 16, 2012 at 07:01:59PM +0100, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT 
> ---
>  .../bindings/clock/mvebu-gated-clock.txt   |   43 ++
>  arch/arm/mach-mvebu/Kconfig|1 +
>  drivers/clk/mvebu/clk-gating-ctrl.c|   61 
> 
>  3 files changed, 105 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt 
> b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> index 7497cc0..9dbcdd9 100644
> --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> @@ -6,6 +6,49 @@ the clock ID in its "clocks" phandle cell. The clock ID is 
> directly mapped to
>  the corresponding clock gating control bit in HW to ease manual clock lookup
>  in datasheet.
>  
> +The following is a list of provided IDs for Armada XP:

Should that the 370, not XP?

> +ID   Clock   Peripheral
> +---
> +0Audio   AC97 Cntrl
> +1pex0_en PCIe 0 Clock out
> +2pex1_en PCIe 1 Clock out
> +3ge1 Gigabit Ethernet 1
> +4ge0 Gigabit Ethernet 0
> +5pex0PCIe Cntrl 0
> +9pex1PCIe Cntrl 1
> +15   sata0   SATA Host 0
> +17   sdioSDHCI Host
> +25   tdm Time Division Mplx
> +28   ddr DDR Cntrl
> +30   sata1   SATA Host 0

Not many clocks there. USB? XOR? Crypto?

What is the ddr clock for? Does bad things happen if you turn it off?
Kirkwood has a similar clock, dunit, which i decided not to export,
since when you turn it off, the whole SoC locks up.

Thanks
  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] clk: mvebu: armada 370/XP add clock gating control provider for DT

[Andrew Lunn]

> > What is the ddr clock for? Does bad things happen if you turn it off?
> > Kirkwood has a similar clock, dunit, which i decided not to export,
> > since when you turn it off, the whole SoC locks up.
> 
> Well of course if you code run in DDR then it could be a problem. But
> I think it could be useful to turn it off when going to suspend, it
> the DDR can do self-refresh. In this case it should be possible to run
> the code from SRAM or L2 Cache.

O.K. Just watch out for the lateinit call in the clock framework.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v1 1/1] RTL8712 alignment bug in 3.6.5 on ARM

[Andrew Lunn]

On Sun, Nov 18, 2012 at 12:06:40PM -0500, Josh Coombs wrote:
> Starting with 3.6.5 on a Marvell Kirkwood based GoFlex Net I began
> observing scheduler bugs when using a USB based RTL8712 WiFi NIC.
> These would eventually overwhelm systemd's logger under moderate
> network activity and crash the box.
> 
> [   64.312377] BUG: scheduling while atomic: crond/151/0x4300
> [   79.771862] BUG: scheduling while atomic: swapper/0/0x4500
> [   81.826267] BUG: scheduling while atomic: swapper/0/0x4500
> [   90.330911] BUG: scheduling while atomic: swapper/0/0x40000500
> 
> Working with Andrew Lunn we dug in further with full stack traces:
> 
> [   53.173973] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [   54.191655] BUG: scheduling while atomic: crond/144/0x4300
> [   54.197537] Modules linked in: rmd160 sha1_generic hmac
> blowfish_generic blowfish_common sr_mod cdrom fbcon bitblit softcursor
> font udlfb syscopyarea sysfillrect sysimgblt fb_sys_fops fb
> hid_generic snd_usb_audio snd_usbmidi_lib snd_hwdep mct_u232
> snd_rawmidi snd_seq_device snd_pcm snd_page_alloc usbhid usbserial
> snd_timer snd hid soundcore mv_cesa cryptodev(O) ipv6 autofs4
> [   54.231214] [] (unwind_backtrace+0x0/0xe0) from
> [] (__schedule_bug+0x48/0x60)
> [   54.240171] [] (__schedule_bug+0x48/0x60) from
> [] (__schedule+0x4c/0x4bc)
> [   54.248773] [] (__schedule+0x4c/0x4bc) from []
> (__cond_resched+0x24/0x34)
> [   54.257365] [] (__cond_resched+0x24/0x34) from
> [] (_cond_resched+0x3c/0x44)
> [   54.266134] [] (_cond_resched+0x3c/0x44) from
> [] (do_alignment+0x29c/0x784)
> [   54.274895] [] (do_alignment+0x29c/0x784) from
> [] (do_DataAbort+0x34/0x98)
> [   54.283571] [] (do_DataAbort+0x34/0x98) from []
> (__dabt_svc+0x38/0x60)
> [   54.291891] Exception stack(0xc4575ac8 to 0xc4575b10)
> [   54.296976] 5ac0:   0138  
>  c781c200 
> [   54.305209] 5ae0: c7020338 c7000440 c70806e4 090e c781c238
> c781c220 0002 c4575b10
> [   54.313438] 5b00: c035f994 c035f4bc 6013 
> [   54.318536] [] (__dabt_svc+0x38/0x60) from []
> (r8712_xmitframe_coalesce+0x388/0x8a0)
> [   54.328092] [] (r8712_xmitframe_coalesce+0x388/0x8a0)
> from [] (r8712_xmit_direct+0x18/0x40)
> [   54.338256] [] (r8712_xmit_direct+0x18/0x40) from
> [] (r8712_pre_xmit+0xac/0xb4)
> [   54.347373] [] (r8712_pre_xmit+0xac/0xb4) from
> [] (r8712_xmit_entry+0x70/0xf0)
> [   54.356410] [] (r8712_xmit_entry+0x70/0xf0) from
> [] (dev_hard_start_xmit+0x440/0x67c)
> [   54.366056] [] (dev_hard_start_xmit+0x440/0x67c) from
> [] (sch_direct_xmit+0x50/0x1a4)
> [   54.375694] [] (sch_direct_xmit+0x50/0x1a4) from
> [] (dev_queue_xmit+0x2ec/0x4d8)
> [   54.384993] [] (dev_queue_xmit+0x2ec/0x4d8) from
> [] (ip6_finish_output2+0x294/0x344 [ipv6])
> [   54.395288] [] (ip6_finish_output2+0x294/0x344 [ipv6])
> from [] (ndisc_send_skb+0x110/0x1f4 [ipv6])
> [   54.406202] [] (ndisc_send_skb+0x110/0x1f4 [ipv6]) from
> [] (ndisc_send_rs+0x3c/0x44 [ipv6])
> [   54.416493] [] (ndisc_send_rs+0x3c/0x44 [ipv6]) from
> [] (addrconf_dad_completed+0x80/0xc0 [ipv6])
> [   54.427289] [] (addrconf_dad_completed+0x80/0xc0 [ipv6])
> from [] (addrconf_dad_timer+0x70/0x10c [ipv6])
> [   54.438563] [] (addrconf_dad_timer+0x70/0x10c [ipv6])
> from [] (run_timer_softirq+0x1b0/0x2fc)
> [   54.448904] [] (run_timer_softirq+0x1b0/0x2fc) from
> [] (__do_softirq+0xa0/0x1f8)
> [   54.458103] [] (__do_softirq+0xa0/0x1f8) from
> [] (irq_exit+0x40/0x8c)
> [   54.466345] [] (irq_exit+0x40/0x8c) from []
> (handle_IRQ+0x64/0x84)
> [   54.474322] [] (handle_IRQ+0x64/0x84) from []
> (__irq_svc+0x34/0x78)
> [   54.482389] [] (__irq_svc+0x34/0x78) from []
> (lookup_fast+0x74/0x258)
> [   54.490615] [] (lookup_fast+0x74/0x258) from []
> (path_lookupat+0xfc/0x71c)
> [   54.499286] [] (path_lookupat+0xfc/0x71c) from
> [] (do_path_lookup+0x1c/0x5c)
> [   54.508138] [] (do_path_lookup+0x1c/0x5c) from
> [] (user_path_at_empty+0x54/0x8c)
> [   54.517338] [] (user_path_at_empty+0x54/0x8c) from
> [] (user_path_at+0x10/0x14)
> [   54.526368] [] (user_path_at+0x10/0x14) from []
> (vfs_fstatat+0x2c/0x5c)
> [   54.534789] [] (vfs_fstatat+0x2c/0x5c) from []
> (sys_stat64+0x14/0x30)
> [   54.543027] [] (sys_stat64+0x14/0x30) from []
> (ret_fast_syscall+0x0/0x2c)
> [   54.831585] BUG: scheduling while atomic: crond/144/0x4300
> [   54.837464] Modules linked in: rmd160 sha1_generic hmac
> blowfish_generic blowfish_common sr_mod cdrom fbcon bitblit softcursor
> font udlfb syscopyarea sysfillrect sysimgblt fb_sys_fops fb
> hid_generic snd_usb_audio snd_usbmidi_lib snd_hwdep mct_u232
> snd_rawmidi snd_seq_device snd_pcm snd_page_alloc usbhid usbserial
> s

Re: [Patch v1 1/1] RTL8712 alignment bug in 3.6.5 on ARM

[Andrew Lunn]

> >> diff -ruN a/drivers/staging/rtl8712/rtl871x_sta_mgt.c
> >> b/drivers/staging/rtl8712/rtl871x_sta_mgt.c
> >> --- a/drivers/staging/rtl8712/rtl871x_sta_mgt.c 2012-11-05
> >> 03:57:06.0 -0500
> >> +++ b/drivers/staging/rtl8712/rtl871x_sta_mgt.c 2012-11-13
> >> 12:54:28.0 -0500
> >> @@ -55,8 +55,8 @@
> >> NUM_STA + 4);
> >>   if (pstapriv->pallocated_stainfo_buf == NULL)
> >>   return _FAIL;
> >> - pstapriv->pstainfo_buf = pstapriv->pallocated_stainfo_buf + 4 -
> >> - ((addr_t)(pstapriv->pallocated_stainfo_buf) & 3);
> >> + pstapriv->pstainfo_buf = pstapriv->pallocated_stainfo_buf + 8 -
> >> + ((addr_t)(pstapriv->pallocated_stainfo_buf) & 7);
> >
> > Are you sure this is safe?  Is the allocated buffer large enough for
> > those additional 4 bytes of alignment you're adding?
> 
> I'm not certain on that, I bumped the allocations at Andrew's
> suggestion, but don't know enough to certify the changes as 100%
> correct.

Its not correct.

The original code is:

pstapriv->pallocated_stainfo_buf = _malloc(sizeof(struct sta_info) *
   NUM_STA + 4);
if (pstapriv->pallocated_stainfo_buf == NULL)
return _FAIL;
pstapriv->pstainfo_buf = pstapriv->pallocated_stainfo_buf + 4 -
((addr_t)(pstapriv->pallocated_stainfo_buf) & 3);

The 4 in the _malloc() also needs increasing to 8.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v1 1/1] RTL8712 alignment bug in 3.6.5 on ARM

[Andrew Lunn]

On Sun, Nov 18, 2012 at 02:18:37PM -0600, Larry Finger wrote:
> On 11/18/2012 12:11 PM, Andrew Lunn wrote:
> >
> >Just to clarify the issue here:
> >
> >union pn48 {
> > u64 val;
> >#if defined(__BIG_ENDIAN)
> > struct {
> > u8 TSC7;
> > u8 TSC6;
> >
> >Any instance of pn48 needs to be 64 bit aligned when the val member of
> >the union is used. The structure sta_info contains two such pn48s, so
> >the code allocating the pool of these needs to ensure it allocated
> >them 64 bit aligned, not 32bit aligned as it currently is.
> 
> Andrew,
> 
> For my education, would the following patch ensure 64-bit alignment
> for the pn48 instances, or is more needed?

This is not sufficient. In fact it makes no difference at all. The
problem is not with the structure, but with the allocation of memory
used to contain the structure.

pstapriv->pallocated_stainfo_buf = _malloc(sizeof(struct sta_info) *
   NUM_STA + 4);
if (pstapriv->pallocated_stainfo_buf == NULL)
return _FAIL;
pstapriv->pstainfo_buf = pstapriv->pallocated_stainfo_buf + 4 -
((addr_t)(pstapriv->pallocated_stainfo_buf) & 3);

kmalloc() guarantees that its alignment is correct for any type of
structure. Thus all this code above is redundant in Linux, but maybe
needed in some other OS. Worse still, this code actually breaks the
alignment. kmalloc() gave out something which was 64 bit aligned. But
by adding 4 and then masking off the lower 2 bits, it destroys the 64
bit alignment and makes it only 32bit aligned.

Removing the _malloc() wrapper, fixing the GFP_ATOMIC, and leaving the
allocater to worry about alignment will be one of the steps to getting
out of staging.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] clk: mvebu: armada 370/XP add clock gating control provider for DT

[Andrew Lunn]

On Mon, Nov 19, 2012 at 04:46:11PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Sat, 17 Nov 2012 14:54:35 +0100, Andrew Lunn wrote:
> > > > What is the ddr clock for? Does bad things happen if you turn it off?
> > > > Kirkwood has a similar clock, dunit, which i decided not to export,
> > > > since when you turn it off, the whole SoC locks up.
> > > 
> > > Well of course if you code run in DDR then it could be a problem. But
> > > I think it could be useful to turn it off when going to suspend, it
> > > the DDR can do self-refresh. In this case it should be possible to run
> > > the code from SRAM or L2 Cache.
> > 
> > O.K. Just watch out for the lateinit call in the clock framework.
> 
> I don't think there is a problem with the dramclk and the lateinit call
> of the clock framework. The dramclk is a fixed factor clock, and the
> fixed factor clock driver does not implement the ->disable() operation.
> And therefore, the clk_disable_unused() code executed as the lateinit
> call will not be able to disable it:
> 
>   if (__clk_is_enabled(clk) && clk->ops->disable)
>   clk->ops->disable(clk->hw);
> 
> So I think we're quite safe with fixed rate clocks and fixed factor
> clocks in that no-one can disable them :-)

Hi Thomas

I don't think we are taking about the same clock. I mean the gate
clock:

28   ddr DDR Cntrl

not the core clock.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/6] clocksource: add Marvell Orion SoC timer

[Andrew Lunn]

On Mon, Jun 10, 2013 at 11:35:55AM +0200, Sebastian Hesselbarth wrote:
> This patch add a DT enabled driver for timers found on Marvell Orion SoCs
> (Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free-
> running clocksource on timer0 and a clockevent source on timer1.
> Corresponding device tree documentation is also added.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v3->v4:
> - export thread-safe access to TIMER_CTRL register to use with watchdog
> - remove IRQF_DISABLED and add .irq to clock event (Suggested by Daniel 
> Lezcano)
> 
> Notes:
> - This is only an update to clocksource driver, the remaining patches are
>   not resent as they have not been changed.
> - I will not rework orion watchdog driver for this patch set. It is written
>   Kirkwood/Orion5x specific although it will also work on Dove and it is 
> messing
>   with shared registers. It has done it before, so I consider it broken 
> anyway.
>   I (or somebody else) will take care of proper watchdog later.
> - An updated branch can be found on
>   git://github.com/shesselba/linux-dove.git orion-irqchip-for-v3.11_v4

Hi Sebastian

You can add a

Tested-by: Andrew Lunn 

I tested on my kirkwood QNAP.

   CPU0
  2:   6062  bridge-interrupt-ctrl  orion_event
  9:  0  f1010140.gpio  Reset
 15:  0  f1010140.gpio  USB Copy
 24:106  main-interrupt-ctrl  ehci_hcd:usb1
 25:   2463  main-interrupt-ctrl  sata_mv
 26:  0  main-interrupt-ctrl  f103.crypto
 27:  2  main-interrupt-ctrl  f1060800.xor
 28:  2  main-interrupt-ctrl  f1060800.xor
 29: 71  main-interrupt-ctrl  mv64xxx_i2c
 30:  2  main-interrupt-ctrl  f1060900.xor
 31:  2  main-interrupt-ctrl  f1060900.xor
 32: 41  main-interrupt-ctrl  eth0
 33:   1317  main-interrupt-ctrl  serial
 75:745  main-interrupt-ctrl  f1072004.mdio-bus
Err:  0  

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] arm: mvebu: Select DMA_BOUNCE when LPAE is selected in Kconfig

[Andrew Lunn]

On Thu, Mar 21, 2013 at 05:26:15PM +0100, Gregory CLEMENT wrote:
> From: Lior Amsalem 
> 
> For mvebu IOs are 32 bits and we have 40 bits memory due to LPAE so
> make sure we give 32 bits addresses to the IOs.

Hi Gregory, Lior

I don't really understand what this comment is supposed to mean. I
would of expect DMA and bounce to appear at least

> Signed-off-by: Lior Amsalem 
> Tested-by: Franklin 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm/mach-mvebu/Kconfig |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 440b13e..617da94 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -13,6 +13,7 @@ config ARCH_MVEBU
>   select MVEBU_CLK_CORE
>   select MVEBU_CLK_CPU
>   select MVEBU_CLK_GATING
> + select DMABOUNCE if ARM_LPAE
>  
>  if ARCH_MVEBU
>  
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits

[Andrew Lunn]

>   /*
> -  * 4 GB of plug-in RAM modules by default but only 3GB
> -  * are visible, the amount of memory available can be
> -  * changed by the bootloader according the size of the
> -  * module actually plugged
> +  * 8 GB of plug-in RAM modules by default.The amount
> +  * of memory available can be changed by the
> +  * bootloader according the size of the module
> +  * actually plugged. Only 7GB are usable because
> +  * addresses from 0xC000 to 0x are used by
> +  * the internal registers of the SoC.
>*/
> - reg = <0x 0xC000>;
> + reg = <0x 0x 0x 0xC000>,
> +   <0x0001 0x 0x0001 0x>;
> +

Hi Gregory

Could you recommend a document which introduces LPAE.

Only being able to address 7GB seems a bit odd to me. I kind of
expected you set up the translation tables to map a page in the 32 bit
address range to any arbitrary page in the 40 bit address range. So
leaving 0xC000 to 0x in the 32bit address range clear is
easy. But why do you loose space in the 40bit address range?

  Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits

[Andrew Lunn]

On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote:
> 
> > Could you recommend a document which introduces LPAE.
> > 
> > Only being able to address 7GB seems a bit odd to me. I kind of
> > expected you set up the translation tables to map a page in the 32 bit
> > address range to any arbitrary page in the 40 bit address range. So
> > leaving 0xC000 to 0x in the 32bit address range clear is
> > easy. But why do you loose space in the 40bit address range?
> 
> translation tables convert virtual addresses to physical addresses.
> Here, we are only talking about physical addresses. There is an overlap
> between the physical addresses used by the RAM, and the physical
> addresses at which I/O devices are visible.
> 
> And I'm not sure the SDRAM address decoding windows allows to split the
> first 4 GB of RAM into two areas, one that would be mapped starting at
> physical address 0x0, and another area that would be mapped at a
> different address (above 4 GB).

So why not map the whole SDRAM above 4GB physical address?

   Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] USB: EHCI: fix for leaking isochronous data

[Andrew Lunn]

On Thu, Mar 21, 2013 at 05:12:01PM -0400, Alan Stern wrote:
> On Thu, 21 Mar 2013, Alan Stern wrote:
> 
> > On Thu, 21 Mar 2013, Soeren Moch wrote:
> > 
> > > Now I found out what is going on here:
> > > 
> > > In itd_urb_transaction() we allocate 9 iTDs for each URB with 
> > > number_of_packets == 64 in my case. The iTDs are added to 
> > > sched->td_list. For a frame-aligned scheduling we need 8 iTDs, the 9th 
> > > one is released back to the front of the streams free_list in 
> > > iso_sched_free(). This iTD was cleared after allocation and has a frame 
> > > number of 0 now. So for each allocation when now_frame == 0 we allocate 
> > > from the dma_pool, not from the free_list.
> > 
> > Okay, that is a problem.  But it shouldn't be such a big problem,
> > because now_frame should not be equal to 0 very often.
> 
> Oh, wait, now I get it.  We never reach a steady state, because the
> free list never shrinks, but occasionally it does increase when
> now_frame is equal to 0.  Even though that doesn't happen very often,
> the effects add up.
> 
> Very good; tomorrow I will send your patch in.

Hi Alan, Soeren

Could you word the description a bit better. If Alan did not get it
without a bit of thought, few others are going to understand it
without a better explanation.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: kirkwood: make use of DT mvsdio on guruplug board

[Andrew Lunn]

On Sat, Mar 23, 2013 at 01:58:09PM +0100, Sebastian Hesselbarth wrote:
> Device tree based guruplug boards still use mvsdio platform_data and
> kirkwood_sdio_init to enable sdio. DT support for sdio is already there,
> so make use of it.
> 
> This also fixes mvsdio accidentially breaking nand by configuring mpp0
> to gpio, while used also by nand (nand_io2 on mpp0).
> 
> Signed-off-by: Sebastian Hesselbarth 
> Tested-by: Soeren Moch 

Acked-by: Andrew Lunn 

> ---
> Cc: Soeren Moch 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Russell King 
> Cc: Willy Tarreau 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts |4 
>  arch/arm/mach-kirkwood/board-guruplug.c |6 --
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts 
> b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
> index 9555a86..44fd97d 100644
> --- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
> +++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
> @@ -69,6 +69,10 @@
>   status = "okay";
>   nr-ports = <1>;
>   };
> +
> + mvsdio@9 {
> + status = "okay";
> + };
>   };
>  
>   gpio-leds {
> diff --git a/arch/arm/mach-kirkwood/board-guruplug.c 
> b/arch/arm/mach-kirkwood/board-guruplug.c
> index 0a0df45..a857163 100644
> --- a/arch/arm/mach-kirkwood/board-guruplug.c
> +++ b/arch/arm/mach-kirkwood/board-guruplug.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "common.h"
>  
>  static struct mv643xx_eth_platform_data guruplug_ge00_data = {
> @@ -24,10 +23,6 @@ static struct mv643xx_eth_platform_data guruplug_ge01_data 
> = {
>   .phy_addr   = MV643XX_ETH_PHY_ADDR(1),
>  };
>  
> -static struct mvsdio_platform_data guruplug_mvsdio_data = {
> - /* unfortunately the CD signal has not been connected */
> -};
> -
>  void __init guruplug_dt_init(void)
>  {
>   /*
> @@ -35,5 +30,4 @@ void __init guruplug_dt_init(void)
>*/
>   kirkwood_ge00_init(&guruplug_ge00_data);
>   kirkwood_ge01_init(&guruplug_ge01_data);
> - kirkwood_sdio_init(&guruplug_mvsdio_data);
>  }
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: kirkwood: add MACH_GURUPLUG_DT to defconfig

[Andrew Lunn]

On Sat, Mar 23, 2013 at 01:58:22PM +0100, Sebastian Hesselbarth wrote:
> This patch just adds the missing MACH_GURUPLUG_DT to kirkwood_defconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reported-by: Soeren Moch 

Acked-by: Andrew Lunn 

> ---
> Cc: Soeren Moch 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Russell King 
> Cc: Stefan Peter 
> Cc: Nobuhiro Iwamatsu 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/configs/kirkwood_defconfig |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/kirkwood_defconfig 
> b/arch/arm/configs/kirkwood_defconfig
> index 13482ea..5e40f96 100644
> --- a/arch/arm/configs/kirkwood_defconfig
> +++ b/arch/arm/configs/kirkwood_defconfig
> @@ -24,6 +24,7 @@ CONFIG_MACH_IB62X0_DT=y
>  CONFIG_MACH_TS219_DT=y
>  CONFIG_MACH_DOCKSTAR_DT=y
>  CONFIG_MACH_GOFLEXNET_DT=y
> +CONFIG_MACH_GURUPLUG_DT=y
>  CONFIG_MACH_LSXL_DT=y
>  CONFIG_MACH_IOMEGA_IX2_200_DT=y
>  CONFIG_MACH_KM_KIRKWOOD_DT=y
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dove: fix Dove cpu type from V7 to PJ4

[Andrew Lunn]

On Sat, Mar 23, 2013 at 04:06:51PM +0100, Sebastian Hesselbarth wrote:
> The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using
> CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will also allow to enable
> iWMMXt extensions on Dove.
> 
> Signed-off-by: Sebastian Hesselbarth 

Acked-by: Andrew Lunn 

> ---
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2c3bdce..4fc9bca 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -556,7 +556,7 @@ config ARCH_IXP4XX
>  config ARCH_DOVE
>   bool "Marvell Dove"
>   select ARCH_REQUIRE_GPIOLIB
> - select CPU_V7
> + select CPU_PJ4
>   select GENERIC_CLOCKEVENTS
>   select MIGHT_HAVE_PCI
>   select PINCTRL
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -next] mtd: orion_nand: convert to use devm_* APIs

[Andrew Lunn]

On Wed, Jul 17, 2013 at 10:09:10AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Convert to use devm_* APIs to avoid resources leak on error handling case.
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/mtd/nand/orion_nand.c | 29 +
>  1 file changed, 9 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index 46f308d..ce711b4 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -85,25 +85,23 @@ static int __init orion_nand_probe(struct platform_device 
> *pdev)
>   int ret = 0;
>   u32 val = 0;
>  
> - nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info), 
> GFP_KERNEL);
> + nc = devm_kzalloc(&pdev->dev,
> +   sizeof(struct nand_chip) + sizeof(struct mtd_info),
> +   GFP_KERNEL);
>   if (!nc) {
>   printk(KERN_ERR "orion_nand: failed to allocate device 
> structure.\n");
> - ret = -ENOMEM;
> - goto no_res;
> + return -ENOMEM;
>   }
>   mtd = (struct mtd_info *)(nc + 1);
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - ret = -ENODEV;
> - goto no_res;
> - }
> + if (!res)
> + return -ENODEV;
>  
> - io_base = ioremap(res->start, resource_size(res));
> + io_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
>   if (!io_base) {
>   printk(KERN_ERR "orion_nand: ioremap failed\n");
> - ret = -EIO;
> - goto no_res;
> + return -EIO;

Hi Wei

Thanks for working on this.

The above code can be further simplified:

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
io_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(io_base))
return PTR_ERR(io_base); 


While you are editing this file, it would be nice to replace all the
printk() statements with dev_err(), dev_info() etc. Please do that as
a separate patch.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes

[Andrew Lunn]

On Wed, Jul 17, 2013 at 03:06:20PM +0100, sudeep.karkadanage...@arm.com wrote:
> From: Sudeep KarkadaNagesha 
> 
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
> 
> This patch removes all DT parsing and uses cpu->of_node instead.
> 
> Cc: Andrew Lunn 
> Cc: Jason Cooper 
> Acked-by: Viresh Kumar 
> Signed-off-by: Sudeep KarkadaNagesha 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index c233ea6..18aa3eb 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
>  static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>  {
>   struct device_node *np;
> + struct device *cpu_dev;
>   struct resource *res;
>   int err;
>  
> @@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(priv.base))
>   return PTR_ERR(priv.base);
>  
> - np = of_find_node_by_path("/cpus/cpu@0");
> - if (!np)
> + cpu_dev = get_cpu_device(0);
> + if (!cpu_dev) {
> + dev_err(&pdev->dev, "failed to get cpu device\n");
>   return -ENODEV;
> + }
> +
> + np = of_node_get(cpu_dev->of_node);
> + if (!np) {
> + dev_err(&pdev->dev, "failed to get cpu device node\n");
> + return -ENODEV;
> + }

Hi Sudeep

Are we not going a bit backwards here? You are replacing two lines
with 10 lines.

How about putting these 10 lines into some helper,
of_get_cpu_device()?  It would be useful for spear, kirkwood and
imx6q, and maybe others.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] ARM: dove: add initial DT file for Globalscale D2Plug

[Andrew Lunn]

On Mon, Jul 29, 2013 at 02:29:06PM +0200, Sebastian Hesselbarth wrote:
> This adds an initial DT file for the Globalscale D2Plug with Dove SoC.
> Currently, one LED is missing and I have not been able to get SD8787 driver
> working. Those will be taken care of later.

Hi Sebastion

I took a hard look at SDIO and failed to get it working when doing
DMA. Polled IO does however work. I guess we need some help from
Marvell engineers before we get stable SDIO with DMA.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ATA: sata_mv: Remove uneeded CONFIG_HAVE_CLK ifdefs

[Andrew Lunn]

On Mon, Jul 29, 2013 at 12:21:22PM -0300, Ezequiel Garcia wrote:
> If CONFIG_HAVE_CLK is not selected, then all the clk API turn out
> into stubs, so there's no need to have the ifdefs.
> The only side-effect of this patch is the extra tiny kmalloc,
> but that's not enough reason to have such ugly ifdefs all around
> the code.
> 
> Signed-off-by: Ezequiel Garcia 

Hi Ezequiel

What architectures did you compile this for? PowerPC and x86 as well
as ARM? I _think_ this driver is also used there, and i _think_
without some #ifdef, it failed to build. But maybe since then, the
common clock is now available on all architectures?

   Andrew


> ---
>  drivers/ata/sata_mv.c | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
> index 10ea99a..3519987 100644
> --- a/drivers/ata/sata_mv.c
> +++ b/drivers/ata/sata_mv.c
> @@ -553,10 +553,8 @@ struct mv_host_priv {
>   u32 irq_mask_offset;
>   u32 unmask_all_irqs;
>  
> -#if defined(CONFIG_HAVE_CLK)
>   struct clk  *clk;
>   struct clk  **port_clks;
> -#endif
>   /*
>* These consistent DMA memory pools give us guaranteed
>* alignment for hardware-accessed data structures,
> @@ -4032,9 +4030,7 @@ static int mv_platform_probe(struct platform_device 
> *pdev)
>   struct resource *res;
>   int n_ports = 0, irq = 0;
>   int rc;
> -#if defined(CONFIG_HAVE_CLK)
>   int port;
> -#endif
>  
>   ata_print_version_once(&pdev->dev, DRV_VERSION);
>  
> @@ -4068,13 +4064,11 @@ static int mv_platform_probe(struct platform_device 
> *pdev)
>  
>   if (!host || !hpriv)
>   return -ENOMEM;
> -#if defined(CONFIG_HAVE_CLK)
>   hpriv->port_clks = devm_kzalloc(&pdev->dev,
>   sizeof(struct clk *) * n_ports,
>   GFP_KERNEL);
>   if (!hpriv->port_clks)
>   return -ENOMEM;
> -#endif
>   host->private_data = hpriv;
>   hpriv->n_ports = n_ports;
>   hpriv->board_idx = chip_soc;
> @@ -4084,7 +4078,6 @@ static int mv_platform_probe(struct platform_device 
> *pdev)
>  resource_size(res));
>   hpriv->base -= SATAHC0_REG_BASE;
>  
> -#if defined(CONFIG_HAVE_CLK)
>   hpriv->clk = clk_get(&pdev->dev, NULL);
>   if (IS_ERR(hpriv->clk))
>   dev_notice(&pdev->dev, "cannot get optional clkdev\n");
> @@ -4098,7 +4091,6 @@ static int mv_platform_probe(struct platform_device 
> *pdev)
>   if (!IS_ERR(hpriv->port_clks[port]))
>   clk_prepare_enable(hpriv->port_clks[port]);
>   }
> -#endif
>  
>   /*
>* (Re-)program MBUS remapping windows if we are asked to.
> @@ -4124,7 +4116,6 @@ static int mv_platform_probe(struct platform_device 
> *pdev)
>   return 0;
>  
>  err:
> -#if defined(CONFIG_HAVE_CLK)
>   if (!IS_ERR(hpriv->clk)) {
>   clk_disable_unprepare(hpriv->clk);
>   clk_put(hpriv->clk);
> @@ -4135,7 +4126,6 @@ err:
>   clk_put(hpriv->port_clks[port]);
>   }
>   }
> -#endif
>  
>   return rc;
>  }
> @@ -4151,13 +4141,10 @@ err:
>  static int mv_platform_remove(struct platform_device *pdev)
>  {
>   struct ata_host *host = platform_get_drvdata(pdev);
> -#if defined(CONFIG_HAVE_CLK)
>   struct mv_host_priv *hpriv = host->private_data;
>   int port;
> -#endif
>   ata_host_detach(host);
>  
> -#if defined(CONFIG_HAVE_CLK)
>   if (!IS_ERR(hpriv->clk)) {
>   clk_disable_unprepare(hpriv->clk);
>   clk_put(hpriv->clk);
> @@ -4168,7 +4155,6 @@ static int mv_platform_remove(struct platform_device 
> *pdev)
>   clk_put(hpriv->port_clks[port]);
>   }
>   }
> -#endif
>   return 0;
>  }
>  
> -- 
> 1.8.1.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] ARM: dove: add initial DT file for Globalscale D2Plug

[Andrew Lunn]

On Tue, Jul 30, 2013 at 10:03:56AM +0200, Sebastian Hesselbarth wrote:
> On 07/29/2013 08:45 PM, Andrew Lunn wrote:
> >On Mon, Jul 29, 2013 at 02:29:06PM +0200, Sebastian Hesselbarth wrote:
> >>This adds an initial DT file for the Globalscale D2Plug with Dove SoC.
> >>Currently, one LED is missing and I have not been able to get SD8787 driver
> >>working. Those will be taken care of later.
> >
> >I took a hard look at SDIO and failed to get it working when doing
> >DMA. Polled IO does however work. I guess we need some help from
> >Marvell engineers before we get stable SDIO with DMA.
> 
> Andrew,
> 
> have you tried this on the Dove D2Plug or any other Marvell SoC?

Hi Sebastian

I only tried it on Kirkwood. I've had similar bug reports for 370,
which appears to shares the same IP core.

> Dove is using a different SDHCI compatible SDIO controller.

Ah, O.K. Didn't know. It will be interesting to see if this core has
the same problems, i.e. shares the same DMA engine as the MVSDIO core.

> Also, the DMA issue is not holding back this patch, is it?

No, not at all. I just wanted to point out, there are known problems
with the in kernel driver for MVSDIO.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/35] cpufreq: kirkwood: use cpufreq_table_validate_and_show()

[Andrew Lunn]

On Thu, Aug 08, 2013 at 07:18:19PM +0530, Viresh Kumar wrote:
> Lets use cpufreq_table_validate_and_show() instead of calling
> cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr().
> 
> Cc: Andrew Lunn 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index 45e4d7f..336f171 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -125,19 +125,11 @@ static int kirkwood_cpufreq_target(struct 
> cpufreq_policy *policy,
>  /* Module init and exit code */
>  static int kirkwood_cpufreq_cpu_init(struct cpufreq_policy *policy)
>  {
> - int result;
> -
>   /* cpuinfo and default policy values */
>   policy->cpuinfo.transition_latency = 5000; /* 5uS */
>   policy->cur = kirkwood_cpufreq_get_cpu_frequency(0);
>  
> - result = cpufreq_frequency_table_cpuinfo(policy, kirkwood_freq_table);
> - if (result)
> - return result;
> -
> - cpufreq_frequency_table_get_attr(kirkwood_freq_table, policy->cpu);
> -
> - return 0;
> + return cpufreq_table_validate_and_show(policy, kirkwood_freq_table);
>  }
>  
>  static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> -- 
> 1.7.12.rc2.18.g61b472e

Reviewed-by: Andrew Lunn 

Thanks
Andrew 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 12/16] cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes

[Andrew Lunn]

On Mon, Jul 22, 2013 at 12:32:23PM +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha 
> 
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
> 
> This patch removes all DT parsing and uses cpu->of_node instead.
> 
> Cc: Andrew Lunn 
> Cc: Jason Cooper 
> Acked-by: Viresh Kumar 
> Signed-off-by: Sudeep KarkadaNagesha 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index c233ea6..25ac2cb 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -175,9 +175,11 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(priv.base))
>   return PTR_ERR(priv.base);
>  
> - np = of_find_node_by_path("/cpus/cpu@0");
> - if (!np)
> + np = of_cpu_device_node_get(0);
> + if (!np) {
> + dev_err(&pdev->dev, "failed to get cpu device node\n");
>   return -ENODEV;
> + }
>  
>   priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
>   if (IS_ERR(priv.cpu_clk)) {
> -- 
> 1.8.1.2

Hi Sudeep

I've not had chance to test it, but it looks O.K.

Acked-by: Andrew Lunn 

  Andrew

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irqchip: add support for Marvell Orion SoCs

[Andrew Lunn]

On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote:
> On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
> >I have kirkwood HW but I haven't had time to make newer kernels run on
> >it, otherwise I'd test it too :(
> 
> I also have kirkwood HW but that will cut me from email as I use it as
> relay server ;) Maybe I can turn it into a test bed for a while.
> 
> There is also Orion5x and Discovery Innovation (mv78xx0) to be tested.

I can test kirkwood and Orion5x.

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] ARM: dove: add DT parsing for legacy mv643xx_eth

[Andrew Lunn]

On Fri, May 03, 2013 at 01:48:36AM +0200, Sebastian Hesselbarth wrote:
> To allow to move to orion irqchip driver, existing legacy devices
> have to map their irqs. This patch adds init code to map the
> corresponding irqs. It will vanish as soon as there is true device tree
> support for mv643xx_eth.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v1->v2:
> - split off DT changes (Suggested by Jason Cooper)
> 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Rob Landley 
> Cc: Thomas Gleixner 
> Cc: Russell King 
> Cc: Arnd Bergmann 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Jason Gunthorpe 
> Cc: Thomas Petazzoni 
> Cc: Gregory Clement 
> Cc: Ezequiel Garcia 
> Cc: Jean-Francois Moine 
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/mach-dove/board-dt.c |   31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
> index fbde1dd..9df6dd7 100644
> --- a/arch/arm/mach-dove/board-dt.c
> +++ b/arch/arm/mach-dove/board-dt.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -57,6 +58,34 @@ static struct mv643xx_eth_platform_data dove_dt_ge00_data 
> = {
>   .phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
>  };
>  
> +#define DOVE_GE00_PHYS_BASE  0xf107
> +
> +static void __init dove_legacy_ge00_init(void)
> +{
> + struct device_node *np = of_find_compatible_node(NULL, NULL,
> +  "marvell,mv643xx-eth-block");
> + int irq_sum, irq_err;
> +
> + if (!np)
> + return;
> +
> + irq_sum = irq_of_parse_and_map(np, 0);
> + if (!irq_sum) {
> + pr_err("%s: missing sum irq\n", np->full_name);
> + return;
> + }
> +
> + irq_err = irq_of_parse_and_map(np, 1);
> + if (!irq_err) {
> + pr_err("%s: missing err irq\n", np->full_name);
> + return;
> + }
> +
> + /* legacy ge00_init wants phys base */
> + orion_ge00_init(&dove_dt_ge00_data, DOVE_GE00_PHYS_BASE,
> + irq_sum, irq_err, 1600);
> +}

Hi Sebastian

I know the above code is throw away, but it might help with getting
Kirkwood, Orion5x, mv78xx00 supported if we refactor this code and
move most of it into plat-orion/common.c. I could imaging a function

orion_ge00_irq_init(struct mv643xx_eth_platform_data *eth_data,
unsigned long mapbase, unsigned int tx_csum_limit)

which does the irq lookup and then calls orion_ge00_init().


Jason: what is the status of the ethernet driver conversion to DT?
Will it get merged this week, or is it material for the next merge
window?

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

[Andrew Lunn]

On Tue, May 21, 2013 at 06:41:44PM +0200, Sebastian Hesselbarth wrote:
> This patch adds orion-eth and mvmdio device tree nodes for DT enabled
> Dove boards. As there is only one ethernet controller on Dove, a default
> phy node is also added with a note to set its reg property on a per-board
> basis.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v3->v4:
> - convert to new device tree binding
> 
> Cc: David Miller 
> Cc: Lennert Buytenhek 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Benjamin Herrenschmidt 
> Cc: net...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/dove-cubox.dts |7 +++
>  arch/arm/boot/dts/dove.dtsi  |   35 +++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dove-cubox.dts 
> b/arch/arm/boot/dts/dove-cubox.dts
> index 7e3065a..02618fa 100644
> --- a/arch/arm/boot/dts/dove-cubox.dts
> +++ b/arch/arm/boot/dts/dove-cubox.dts
> @@ -49,6 +49,13 @@
>  &uart0 { status = "okay"; };
>  &sata0 { status = "okay"; };
>  &i2c0 { status = "okay"; };
> +&mdio { status = "okay"; };
> +ð { status = "okay"; };
> +
> +ðphy {
> + compatible = "marvell,88e1310";
> + reg = <1>;
> +};
>  
>  &sdio0 {
>   status = "okay";
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index 6cab468..8612658 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -258,5 +258,40 @@
>   dmacap,xor;
>   };
>   };
> +
> + mdio: mdio-bus@72004 {
> + compatible = "marvell,orion-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x72004 0x84>;
> + interrupts = <30>;
> + clocks = <&gate_clk 2>;
> + status = "disabled";
> +
> + ethphy: ethernet-phy {
> + device-type = "ethernet-phy";
> + /* set phy address in board file */
> + };
> + };
> +
> + eth: ethernet-controller@72000 {
> + compatible = "marvell,orion-eth";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x72000 0x4000>;
> + clocks = <&gate_clk 2>;
> + marvell,tx-checksum-limit = <1600>;
> + status = "disabled";
> +
> + ethernet-port@0 {
> + device_type = "network";
> + compatible = "marvell,orion-eth-port";
> + reg = <0>;
> + interrupts = <29>;
> + /* overwrite MAC address in bootloader */
> + local-mac-address = [00 00 00 00 00 00];

Hi Sebastian

Its probably a good idea to set the local administration bit in this
MAC address. i.e. first byte is 02.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/12] net: mv643xx_eth DT support and fixes

[Andrew Lunn]

On Tue, May 21, 2013 at 06:41:38PM +0200, Sebastian Hesselbarth wrote:
> This patch set picks up work by Florian Fainelli bringing full DT
> support to mv643xx_eth and Marvell SoCs using it.

Hi Sebastian

I tested on my QNAP and topkick. Works great.

Tested-by: Andrew Lunn 

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

[Andrew Lunn]

> > Why are you not keen on this? It seems like normal device driver
> > practice, that is what the data field of of_device_id is typically
> > used for..
> 
> I'm not keen on it because we don't have a document saying "All kirkwood
> SoCs need PSC1 set to X after reset."  We know it, but have we tested
> the 6282?

6282 looses its MAC address, that much i know. I've no idea about
PSC1, but if its MAC address behaviour is the same as 6281, is expect
PSC1 is the same.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kirkwood: fix coccicheck warnings

[Andrew Lunn]

On Mon, Mar 11, 2013 at 09:35:19AM +0200, Silviu-Mihai Popescu wrote:
> Convert all uses of devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
> 
> devm_ioremap_resource() provides its own error messages so all explicit
> error messages can be removed from the failure code paths.
> 
> Signed-off-by: Silviu-Mihai Popescu 
> ---

Acked-by: Andrew Lunn 

Thanks
  Andrew


>  drivers/cpufreq/kirkwood-cpufreq.c |8 +++-
>  drivers/cpuidle/cpuidle-kirkwood.c |6 +++---
>  drivers/thermal/kirkwood_thermal.c |8 +++-
>  3 files changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index 0e83e3c..6052476 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -175,11 +175,9 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   dev_err(&pdev->dev, "Cannot get memory resource\n");
>   return -ENODEV;
>   }
> - priv.base = devm_request_and_ioremap(&pdev->dev, res);
> - if (!priv.base) {
> - dev_err(&pdev->dev, "Cannot ioremap\n");
> - return -EADDRNOTAVAIL;
> - }
> + priv.base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv.base))
> + return PTR_ERR(priv.base);
>  
>   np = of_find_node_by_path("/cpus/cpu@0");
>   if (!np)
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c 
> b/drivers/cpuidle/cpuidle-kirkwood.c
> index 670aa1e..53aad73 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c
> +++ b/drivers/cpuidle/cpuidle-kirkwood.c
> @@ -66,9 +66,9 @@ static int kirkwood_cpuidle_probe(struct platform_device 
> *pdev)
>   if (res == NULL)
>   return -EINVAL;
>  
> - ddr_operation_base = devm_request_and_ioremap(&pdev->dev, res);
> - if (!ddr_operation_base)
> - return -EADDRNOTAVAIL;
> + ddr_operation_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(ddr_operation_base))
> + return PTR_ERR(ddr_operation_base);
>  
>   device = &per_cpu(kirkwood_cpuidle_device, smp_processor_id());
>   device->state_count = KIRKWOOD_MAX_STATES;
> diff --git a/drivers/thermal/kirkwood_thermal.c 
> b/drivers/thermal/kirkwood_thermal.c
> index 65cb4f0..e5500ed 100644
> --- a/drivers/thermal/kirkwood_thermal.c
> +++ b/drivers/thermal/kirkwood_thermal.c
> @@ -85,11 +85,9 @@ static int kirkwood_thermal_probe(struct platform_device 
> *pdev)
>   if (!priv)
>   return -ENOMEM;
>  
> - priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
> - if (!priv->sensor) {
> - dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
> - return -EADDRNOTAVAIL;
> - }
> + priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->sensor))
> + return PTR_ERR(priv->sensor);
>  
>   thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
>  priv, &ops, NULL, 0, 0);
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the akpm tree with the arm-soc tree

[Andrew Lunn]

On Tue, Mar 12, 2013 at 02:47:14PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm tree got a conflict in
> drivers/rtc/rtc-mv.c between commit 89c58c198b25 ("rtc: rtc-mv: Add
> support for clk to avoid lockups") from the arm-soc tree and commit "rtc:
> rtc-mv: use devm_rtc_device_register()" from the akpm tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

Hi Stephan

Looks O.K. to me.

Acked-by: Andrew Lunn 

> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/rtc/rtc-mv.c
> index f378e17,1ee8551..000
> --- a/drivers/rtc/rtc-mv.c
> +++ b/drivers/rtc/rtc-mv.c
> @@@ -272,16 -262,15 +272,17 @@@ static int __init mv_rtc_probe(struct p
>   
>   if (pdata->irq >= 0) {
>   device_init_wakeup(&pdev->dev, 1);
> - pdata->rtc = rtc_device_register(pdev->name, &pdev->dev,
> + pdata->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
>&mv_rtc_alarm_ops,
>THIS_MODULE);
> - } else
> - pdata->rtc = rtc_device_register(pdev->name, &pdev->dev,
> + } else {
> + pdata->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
>&mv_rtc_ops, THIS_MODULE);
> + }
>  -if (IS_ERR(pdata->rtc))
>  -return PTR_ERR(pdata->rtc);
>  +if (IS_ERR(pdata->rtc)) {
>  +ret = PTR_ERR(pdata->rtc);
>  +goto out;
>  +}
>   
>   if (pdata->irq >= 0) {
>   writel(0, pdata->ioaddr + RTC_ALARM_INTERRUPT_MASK_REG_OFFS);
> @@@ -308,10 -292,6 +309,9 @@@ static int __exit mv_rtc_remove(struct 
>   if (pdata->irq >= 0)
>   device_init_wakeup(&pdev->dev, 0);
>   
> - rtc_device_unregister(pdata->rtc);
>  +if (!IS_ERR(pdata->clk))
>  +clk_disable_unprepare(pdata->clk);
>  +
>   return 0;
>   }
>   


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/11] pinctrl: mvebu: pinctrl driver core

[Andrew Lunn]

On Mon, Aug 20, 2012 at 11:09:51AM +0200, Linus Walleij wrote:
> On Sat, Aug 11, 2012 at 2:56 PM, Sebastian Hesselbarth
>  wrote:
> 
> > This patch adds a pinctrl driver core for Marvell SoCs plus DT
> > binding documentation. This core driver will be used by SoC family
> > specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso.
> 
> Thanks for dealing with this, much appreaciated!
> 
> Are you taking this patch series through some Marvell tree or do you want
> me to carry it in the pinctrl tree?

Hi Linus

We can carry it thought the Marvell tree. 

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.6-rc3 regression] sata_mv cannot get optional clkdev breaking boot on QNAP TS-119P+

[Andrew Lunn]

On Sat, Aug 25, 2012 at 03:01:33PM +0200, Mikael Pettersson wrote:
> My Kirkwood-based QNAP TS-119P+ boots fine with the 3.5 kernel.  With
> 3.6-rc2 and 3.6-rc3 however sata_mv complains:
> 
> sata_mv sata_mv.0: cannot get optional clkdev
> sata_mv sata_mv.0: slots 32 ports 2
> 
> and then the kernel grinds to a halt with no further messages.
> 
> Full boot log from 3.6-rc3 appended below.  .config available upon
> request, but this is a non-DT kernel.

Hi Mikael

This is a known issue. See:

http://comments.gmane.org/gmane.linux.ports.arm.kernel/181989

There are patches being developed to fix this. I hope we can push them
to an RC soon.

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

[Andrew Lunn]

> +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> @@ -0,0 +1,279 @@
> +* Marvell Kirkwood SoC pinctrl driver for mpp
> +
> +Please refer to marvell,mvebu-pinctrl.txt in this directory for common 
> binding
> +part and usage.
> +
> +Required properties:
> +- compatible: "marvell,88f6180-pinctrl",
> +  "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
> +  "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
> +
> +This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628

Hi Sebastian 

The current MPP code determines for itself what chip it is running on.
It can then check if a pin configuration is valid for the current
run time environment.

Here you are suggesting we have to put into the DT what chip we expect
to be on.

What is the advantage of this, over getting the information from the
device itself?

If i wanted to mass convert all existing kirkwood DT boards over to
use pinctrl, im stuck at the very first step. I've no idea what chip
they use, it was not relevant before.

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

[Andrew Lunn]

> I had a closer look at how kirkwood probes its id. I mentionend kirkwood_id()
> earlier but in fact it is kirkwood_pcie_id(). I assume pcie registers are shut
> down with pcie clk gated? That would require to have pcie running at least at
> boot-time on all boards.
> 
> While it is still possible to grab the id and power down pcie later, I still
> think that using five different compatible strings is better here. Of course,
> there is some effort to obtain the kirkwood SoC variant for all boards.

Hi Sebastian

I did the monkey work last night for converting all existing kirkwood
DT boards over to pinctrl. I noticed that in all the DT descriptions,
they all declare themselves as 88f6281. This is probably cut/paste
from the first board we ever had. For these boards, i doubt it will be
a problem, finding out what chip is really used, as there are active
maintainers. The problem comes with old style devices which we want to
convert. But if we do the monkey work for older boards, we are going
to have to find testers anyway and they can tell us what SoC is used.

Having said that, not probing the hardware, having it configurable is
a source of errors. We already probe the hardware in order to display:

Kirkwood: MV88F6282-Rev-A0, TCLK=2.

so we just need to cache this and make it available to anybody who
wants it.

I'm surprised we don't have the infrastructure of this already. We
have info about the CPU, e.g.

cat /proc/cpuinfo 
Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS  : 1587.60
Features  : swp half thumb fastmult edsp 
CPU implementer   : 0x56
CPU architecture: 5TE
CPU variant   : 0x2
CPU part  : 0x131
CPU revision  : 1

Hardware  : Marvell Kirkwood (Flattened Device Tree)
Revision  : 
Serial  : 

but don't seem to have anything about the SoC the CPU is embedded in.

AT91 has at91_get_soc_type(struct at91_socinfo *c) which is what we
would need for Kirkwood. However, interestingly, its never used
outside of arch/arm/mach-at91/setup.c!

davinci has a global structure davinci_soc_info which
gpio/gpio-davinci.c uses.

So we would not be the only architecture making such information
available. We just need to make sure we do it such that its multi-arch
kernel compatible.

   Andrew




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

[Andrew Lunn]

On Thu, Sep 13, 2012 at 05:41:45PM +0200, Sebastian Hesselbarth wrote:
> This patch adds a SoC specific pinctrl driver for Marvell Kirkwood SoCs
> plus DT binding documentation. This driver will use the mvebu pinctrl
> driver core.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> v2:
> - restructured pinctrl/Kconfig to hide pinctrl driver as it will be
>   always selected by arch/arm/mach-mvebu/Kconfig
> - use enum for kirkwood variants instead of defines
> 
> v3:
> - moved variant specific data to DT match struct
> 
> v4:
> - fix bogus v3 patch set


Since Linus Walleij thinks that autoprobing is not going to happen, 

Tested-by: Andrew Lunn 

However, i still think it would be nice to have auto probing.

 Andrew

> Cc: Sebastian Hesselbarth 
> Cc: Thomas Petazzoni 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Rob Landley 
> Cc: Russell King 
> Cc: Lior Amsalem 
> Cc: Andrew Lunn 
> Cc: Jason Cooper 
> Cc: Gregory CLEMENT 
> Cc: Ben Dooks 
> Cc: Linus Walleij 
> Cc: Stephen Warren 
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt  |  279 
>  drivers/pinctrl/Kconfig|4 +
>  drivers/pinctrl/Makefile   |1 +
>  drivers/pinctrl/pinctrl-kirkwood.c |  472 
> 
>  4 files changed, 756 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-kirkwood.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> new file mode 100644
> index 000..361bccb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> @@ -0,0 +1,279 @@
> +* Marvell Kirkwood SoC pinctrl driver for mpp
> +
> +Please refer to marvell,mvebu-pinctrl.txt in this directory for common 
> binding
> +part and usage.
> +
> +Required properties:
> +- compatible: "marvell,88f6180-pinctrl",
> +  "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
> +  "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
> +
> +This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 
> 88f628x.
> +
> +Available mpp pins/groups and functions:
> +Note: brackets (x) are not part of the mpp name for marvell,function and 
> given
> +only for more detailed description in this document.
> +
> +* Marvell Kirkwood 88f6180
> +
> +name  pins functions
> +
> +mpp0  0gpio, nand(io2), spi(cs)
> +mpp1  1gpo, nand(io3), spi(mosi)
> +mpp2  2gpo, nand(io4), spi(sck)
> +mpp3  3gpo, nand(io5), spi(miso)
> +mpp4  4gpio, nand(io6), uart0(rxd), ptp(clk)
> +mpp5  5gpo, nand(io7), uart0(txd), ptp(trig)
> +mpp6  6sysrst(out), spi(mosi), ptp(trig)
> +mpp7  7gpo, pex(rsto), spi(cs), ptp(trig)
> +mpp8  8gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
> +   mii(col)
> +mpp9  9gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
> +   mii(crs)
> +mpp10 10   gpo, spi(sck), uart0(txd), ptp(trig)
> +mpp11 11   gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
> +   ptp-2(trig)
> +mpp12 12   gpo, sdio(clk)
> +mpp13 13   gpio, sdio(cmd), uart1(txd)
> +mpp14 14   gpio, sdio(d0), uart1(rxd), mii(col)
> +mpp15 15   gpio, sdio(d1), uart0(rts), uart1(txd)
> +mpp16 16   gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs)
> +mpp17 17   gpio, sdio(d3)
> +mpp18 18   gpo, nand(io0)
> +mpp19 19   gpo, nand(io1)
> +mpp20 20   gpio, mii(rxerr)
> +mpp21 21   gpio, audio(spdifi)
> +mpp22 22   gpio, audio(spdifo)
> +mpp23 23   gpio, audio(rmclk)
> +mpp24 24   gpio, audio(bclk)
> +mpp25 25   gpio, audio(sdo)
> +mpp26 26   gpio, audio(lrclk)
> +mpp27 27   gpio, audio(mclk)
> +mpp28 28   gpio, audio(sdi)
> +mpp29 29   gpio, audio(extclk)
> +
> +* Marvell Kirkwood 88f6190
> +
> +name  pins functions
> +

Re: [PATCH 00/11] pinctrl: mvebu: pinctrl driver

[Andrew Lunn]

Hi Thomas

> Hum, which patches are stalling the integration into the Marvell tree?

l2 cache, I think.

The trees Jason built for pull requests in the direction of arm-soc
had the l2 cache patch as the very first in the series. Now that these
patches have run into some trouble, its blocking all the patches that
followed.

Jason is re-building his trees, throwing out l2 cache for the
moment. That should allow Olof/Arnd to pull these trees into arm-soc,
and then Jason will work on integrating the remaining patches not
already in his trees.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

[Andrew Lunn]

On Thu, Sep 20, 2012 at 03:30:40PM +, Arnd Bergmann wrote:
> On Monday 17 September 2012, Linus Walleij wrote:
> > You found the weak spot between two consolidation tracks.
> > 
> > Getting rid of a broadcast autodetect functions from say
> >  is nominally done by passing the data
> > to the driver as platform data instead, and only using
> > these functions in the mach-foo folder when populating
> > platform data, and thus it can be made into a local
> > header, say mach-foo/foo-id-probe.h
> > 
> > So the machine/arch code reads these registers to
> > populate the platform data and device drivers only
> > look at the platform data, which has some enum or
> > bool indicating what hardware it's running on, cool.
> > 
> > But according to the other consolidation track, platform
> > data should go into device tree bindings.
> > 
> > So the conclusion is that the DT must contain the data
> > about the platform, so it's not auto-probed by the kernel.
> > (I.e. the kernel reads no registers to figure out what hardware
> > this is, that stuff comes from the device tree.)
> > 
> > DT purists will say that the boot loader should ask the chipset
> > what it is with the same register writes and populate the
> > DT accordingly, instead of loading a precompiled blob.
> > Some may even ponder the crazy concept of amending the
> > DT in the kernel at early boot.
> > 
> > But in practice someone will give up, encode the stuff in
> > the static device tree and autoprobing of the platform
> > goes out the window.
> 
> In general, I would prefer probing hardware by asking the hardware itself
> rather than duplicating the information in the device tree. We do this
> whenever we can, e.g. on PCI or USB, but we cannot normally do the same
> on embedded buses like AHB, I2C or SPI, so we have to use the device
> tree to provide some or all of the information.
> 
> A corner case is the one where you have different versions of the same
> IP block (e.g. the pinctrl) and the kernel cannot find out which one it
> is by looking at registers inside it or on the parent bus, but only
> by looking at other hardware (CPU core revision, or PCI device ID of
> the root complex).

Hi Arnd

Even if we did look at the PCIe device IDs, we would still have one
odd-ball case to deal with. We have had an initial port to a Marvell
98DX4122 contributed. This chip is a Marvell Ethernet chip, with an
embedded Kirkwood SoC. The SoC is missing SATA, RTC, SDIO, I2S, TDM,
and TS which other kirkwoods have. So it will need a different pinctrl
table. However, looking at the PCIe device ID, it identifies itself as
a normal MV88F6281. So we would have to deal with this in DT with a
different compatibility string.

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

[Andrew Lunn]

> So, wouldn't we need a small, architecture-independent, infrastructure,
> through which architecture-specific code could "register" at boot
> time which SoC we are running on, and drivers could query this
> information from the common infrastructure?
> 
> Of course, the major problem is to figure out what is the good
> representation for this SoC identifier. Do we need a big list of SoCs
> like we had machine IDs? A simple string? Or maybe there is just no
> good way, and the whole idea is moot.

I did think about stuffing it inside the cpuinfo structures:

$ cat /proc/cpuinfo 
Processor   : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 1196.85
Features: swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Hardware: BUBBA3 Kirkwood based miniserver
Revision: 
Serial  : 

I could imaging a 
SoC : MV88F6281

It would probably need a bit of string parsing by any consumer, which
is not so good.

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] ARM: dove: unify clock setup

[Andrew Lunn]

Hi Sebastian

> -static void __init clk_init(void)
> +static void __init dove_clk_init(void)
>  {
>   tclk = clk_register_fixed_rate(NULL, "tclk", NULL, CLK_IS_ROOT,
> -get_tclk());
> +dove_tclk);
>  
>   orion_clkdev_init(tclk);
> +
> + /* Ensure tclk is always clocked */
> + clk_prepare_enable(tclk);
>  }

"ticking" would be better than clocked. 

Since this is a root fixed clock, is it necessary to prepare_enable()
it? I think prepare and enable become NOPs in this situation.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/6] ARM: dove: add clock gating control

[Andrew Lunn]

On Sat, Aug 11, 2012 at 12:35:22PM +0200, Sebastian Hesselbarth wrote:
> This patch adds clock gates from the clock gating control register
> available on dove. All clock gates are hooked up to tclk, except for
> gigabit ethernet controller (ge) which is a child of gephy to allow
> both enabled/disabled at the same time.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Rabeeh Khoury 
> Cc: Ian Molton 
> Cc: Arnd Bergmann 
> Cc: Maen Suleiman 
> Cc: Olof Johansson 
> 
> v2: adapted to removed clk_prepare_enable from patch 1
> ---
>  arch/arm/mach-dove/common.c  |   59 
> +-
>  arch/arm/mach-dove/include/mach/pm.h |   54 ---
>  2 files changed, 94 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
> index b6f092c..7281591 100644
> --- a/arch/arm/mach-dove/common.c
> +++ b/arch/arm/mach-dove/common.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -24,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "common.h"
>  
>  
> /*
> @@ -69,14 +72,68 @@ void __init dove_map_io(void)
>   * CLK tree
>   
> /
>  static int dove_tclk;
> +
> +static DEFINE_SPINLOCK(gating_lock);
>  static struct clk *tclk;
>  
> +static struct clk __init *dove_register_gate(const char *name,
> +  const char *parent, u8 bit_idx)
> +{
> + return clk_register_gate(NULL, name, parent, 0,
> +  (void __iomem *)CLOCK_GATING_CONTROL,
> +  bit_idx, 0, &gating_lock);
> +}
> +
>  static void __init dove_clk_init(void)
>  {
> + struct clk *usb0, *usb1, *sata, *pex0, *pex1, *sdio0, *sdio1;
> + struct clk *nand, *camera, *i2s0, *i2s1, *crypto, *ac97, *pdma;
> + struct clk *xor0, *xor1, *ge, *gephy;
> +
>   tclk = clk_register_fixed_rate(NULL, "tclk", NULL, CLK_IS_ROOT,
>  dove_tclk);
>  
> - orion_clkdev_init(tclk);
> + usb0 = dove_register_gate("usb0", "tclk", CLOCK_GATING_BIT_USB0);
> + usb1 = dove_register_gate("usb1", "tclk", CLOCK_GATING_BIT_USB1);
> + sata = dove_register_gate("sata", "tclk", CLOCK_GATING_BIT_SATA);
> + pex0 = dove_register_gate("pex1", "tclk", CLOCK_GATING_BIT_PCIE0);
> + pex1 = dove_register_gate("pex1", "tclk", CLOCK_GATING_BIT_PCIE1);
> + sdio0 = dove_register_gate("sdio0", "tclk", CLOCK_GATING_BIT_SDIO0);
> + sdio1 = dove_register_gate("sdio1", "tclk", CLOCK_GATING_BIT_SDIO1);
> + nand = dove_register_gate("nand", "tclk", CLOCK_GATING_BIT_NAND);
> + camera = dove_register_gate("camera", "tclk", CLOCK_GATING_BIT_CAMERA);
> + i2s0 = dove_register_gate("i2s0", "tclk", CLOCK_GATING_BIT_I2S0);
> + i2s1 = dove_register_gate("i2s1", "tclk", CLOCK_GATING_BIT_I2S1);
> + crypto = dove_register_gate("crypto", "tclk", CLOCK_GATING_BIT_CRYPTO);
> + ac97 = dove_register_gate("ac97", "tclk", CLOCK_GATING_BIT_AC97);
> + pdma = dove_register_gate("pdma", "tclk", CLOCK_GATING_BIT_PDMA);
> + xor0 = dove_register_gate("xor0", "tclk", CLOCK_GATING_BIT_XOR0);
> + xor1 = dove_register_gate("xor1", "tclk", CLOCK_GATING_BIT_XOR1);
> + gephy = dove_register_gate("gephy", "tclk", CLOCK_GATING_BIT_GIGA_PHY);
> + ge = dove_register_gate("ge", "gephy", CLOCK_GATING_BIT_GBE);
> +
> + orion_clkdev_add(NULL, "orion_spi.0", tclk);
> + orion_clkdev_add(NULL, "orion_spi.1", tclk);
> + orion_clkdev_add(NULL, "orion_wdt", tclk);
> + orion_clkdev_add(NULL, MV64XXX_I2C_CTLR_NAME ".0", tclk);
> +
> + orion_clkdev_add(NULL, "orion-ehci.0", usb0);
> + orion_clkdev_add(NULL, "orion-ehci.1", usb1);
> + orion_clkdev_add(NULL, MV643XX_ETH_NAME ".0", ge);

Hi Sebastian

Take a look at the patch [PATCH v3 7/7] NET: mv643xx: remove device
name macro, from Ian Molten, and the discussion around the macro
MV643XX_ETH_NAME and its friend.

It is probably best to not use the I2C and XOR macro as well.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/10] ARM: mv78xx0: fix win_cfg_base prototype

[Andrew Lunn]

On Wed, Aug 08, 2012 at 11:27:51PM +0200, Arnd Bergmann wrote:
> Patch b6d1c33a31 "ARM: Orion: Consolidate the address map setup" tried
> to merge the address map for the four orion platforms, but apparently
> got it wrong for mv78xx0. Admittedly I don't understand what this
> code actually does, but it's clear that the current version is
> wrong.
> 
> Without this patch, building mv78xx0_defconfig results in:
> 
> arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from 
> incompatible pointer type [enabled by default]
> arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 
> 'addr_map_cfg.win_cfg_base') [enabled by default]
> 
> Signed-off-by: Arnd Bergmann 
> Cc: Andrew Lunn 
> Cc: Michael Walle 
> Cc: Nicolas Pitre 
> ---
>  arch/arm/mach-mv78xx0/addr-map.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-mv78xx0/addr-map.c 
> b/arch/arm/mach-mv78xx0/addr-map.c
> index 62b53d7..a9bc841 100644
> --- a/arch/arm/mach-mv78xx0/addr-map.c
> +++ b/arch/arm/mach-mv78xx0/addr-map.c
> @@ -37,7 +37,7 @@
>  #define WIN0_OFF(n)  (BRIDGE_VIRT_BASE + 0x + ((n) << 4))
>  #define WIN8_OFF(n)  (BRIDGE_VIRT_BASE + 0x0900 + (((n) - 8) << 4))
>  
> -static void __init __iomem *win_cfg_base(int win)
> +static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg 
> *cfg, int win)
>  {
>   /*
>* Find the control register base address for this window.
> -- 
> 1.7.10
> 

Acked-by: Andrew Lunn 

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

On Thu, Jan 17, 2013 at 08:26:45PM +, Arnd Bergmann wrote:
> On Thursday 17 January 2013, Soeren Moch wrote:
> > On 17.01.2013 11:49, Arnd Bergmann wrote:
> > > On Wednesday 16 January 2013, Soeren Moch wrote:
> >  I will see what I can do here. Is there an easy way to track the buffer
> >  usage without having to wait for complete exhaustion?
> > >>>
> > >>> DMA_API_DEBUG
> > >>
> > >> OK, maybe I can try this.

I tried this. Not what i expected. We have at least one problem with
the ethernet driver:

WARNING: at lib/dma-debug.c:933 check_unmap+0x4b8/0x8a8()
mv643xx_eth_port mv643xx_eth_port.0: DMA-API: device driver failed to check map 
error[device address=0x1f22be00] [size=1536 bytes] [mapped as single]
Modules linked in:
[] (unwind_backtrace+0x0/0xf4) from [] 
(warn_slowpath_common+0x4c/0x64)
[] (warn_slowpath_common+0x4c/0x64) from [] 
(warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt+0x30/0x40) from [] 
(check_unmap+0x4b8/0x8a8)
[] (check_unmap+0x4b8/0x8a8) from [] 
(debug_dma_unmap_page+0x8c/0x98)
[] (debug_dma_unmap_page+0x8c/0x98) from [] 
(mv643xx_eth_poll+0x630/0x800)
[] (mv643xx_eth_poll+0x630/0x800) from [] 
(net_rx_action+0xcc/0x1d4)
[] (net_rx_action+0xcc/0x1d4) from [] 
(__do_softirq+0xa8/0x170)
[] (__do_softirq+0xa8/0x170) from [] (do_softirq+0x5c/0x6c)
[] (do_softirq+0x5c/0x6c) from [] 
(local_bh_enable+0xcc/0xdc)
[] (local_bh_enable+0xcc/0xdc) from [] 
(ip_finish_output+0x1c8/0x39c)
[] (ip_finish_output+0x1c8/0x39c) from [] 
(ip_local_out+0x28/0x2c)
[] (ip_local_out+0x28/0x2c) from [] 
(ip_queue_xmit+0x118/0x338)
[] (ip_queue_xmit+0x118/0x338) from [] 
(tcp_transmit_skb+0x3fc/0x8e4)
[] (tcp_transmit_skb+0x3fc/0x8e4) from [] 
(tcp_write_xmit+0x228/0xb08)
[] (tcp_write_xmit+0x228/0xb08) from [] 
(__tcp_push_pending_frames+0x30/0x9c)
[] (__tcp_push_pending_frames+0x30/0x9c) from [] 
(tcp_sendmsg+0x158/0xdc4)
[] (tcp_sendmsg+0x158/0xdc4) from [] 
(inet_sendmsg+0x38/0x74)
[] (inet_sendmsg+0x38/0x74) from [] 
(sock_aio_write+0x12c/0x138)
[] (sock_aio_write+0x12c/0x138) from [] 
(do_sync_write+0xa0/0xd0)
[] (do_sync_write+0xa0/0xd0) from [] (vfs_write+0x13c/0x144)
[] (vfs_write+0x13c/0x144) from [] (sys_write+0x44/0x70)
[] (sys_write+0x44/0x70) from [] (ret_fast_syscall+0x0/0x2c)
---[ end trace b75faa8779652e63 ]---

I'm getting about 4 errors reported a second from the ethernet driver.

Before i look at issues with em28xx i will first try to get the noise
from the ethernet driver sorted out.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

> Please find attached a debug log generated with your patch.
> 
> I used the sata disk and two em28xx dvb sticks, no other usb devices,
> no ethernet cable connected, tuners on saa716x-based card not used.
> 
> What I can see in the log: a lot of coherent mappings from sata_mv
> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> All coherent mappings are page aligned, some of them (from orion_ehci)
> are not really small (as claimed in __alloc_from_pool).
> 
> I don't believe in a memory leak. When I restart vdr (the application
> utilizing the dvb sticks) then there is enough dma memory available
> again.

Hi Soeren

We should be able to rule out a leak. Mount debugfg and then:

while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done

while you are capturing. See if the number goes down.

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
> On 19.01.2013 19:59, Andrew Lunn wrote:
> >>Please find attached a debug log generated with your patch.
> >>
> >>I used the sata disk and two em28xx dvb sticks, no other usb devices,
> >>no ethernet cable connected, tuners on saa716x-based card not used.
> >>
> >>What I can see in the log: a lot of coherent mappings from sata_mv
> >>and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> >>All coherent mappings are page aligned, some of them (from orion_ehci)
> >>are not really small (as claimed in __alloc_from_pool).
> >>
> >>I don't believe in a memory leak. When I restart vdr (the application
> >>utilizing the dvb sticks) then there is enough dma memory available
> >>again.
> >
> >Hi Soeren
> >
> >We should be able to rule out a leak. Mount debugfg and then:
> >
> >while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; 
> >done
> >
> >while you are capturing. See if the number goes down.
> >
> >   Andrew
> 
> Now I built a kernel with debugfs enabled.
> It is not clear to me what I can see from the
> dma-api/num_free_entries output. After reboot (vdr running) I see
> decreasing numbers (3453 3452 3445 3430...), min_free_entries is
> lower (3390). Sometimes the output is constant for several minutes (
> 3396 3396 3396 3396 3396,...)

We are interesting in the long term behavior. Does it gradually go
down? Or is it stable? If it goes down over time, its clearly a leak
somewhere.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Andrew Lunn]

> >>
> >
> >Now (in the last hour) stable, occasionally lower numbers:
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> >3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3394 3396 3396 3396 3396 3396 3396 3396
> >
> >Before the last pool exhaustion going down:
> >3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> >3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> >3247 3247 3247 3242 3236 3236
> >
> Here I stopped vdr (and so closed all dvb_demux devices), the number
> was remaining the same 3236, even after restart of vdr (and restart
> of streaming).

So it does suggest a leak. Probably somewhere on an error path,
e.g. its lost video sync.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] Enable ecc-mode selection in the driver

[Andrew Lunn]

On Tue, Jan 15, 2013 at 01:13:12PM +0100, Stefan Peter wrote:
> In order to be able to use the ecc-mode, add the bch module to the default
> settings for the kirwood boards and enable the activation in orin-nand.c
> 
> Signed-off-by: Stefan Peter 
> ---
> diff --git a/arch/arm/configs/kirkwood_defconfig 
> b/arch/arm/configs/kirkwood_defconfig
> index 93f3794..4a9d3f7 100644
> --- a/arch/arm/configs/kirkwood_defconfig
> +++ b/arch/arm/configs/kirkwood_defconfig
> @@ -84,6 +84,7 @@ CONFIG_MTD_CFI_STAA=y
>  CONFIG_MTD_PHYSMAP=y
>  CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
> +CONFIG_MTD_NAND_ECC_BCH=y
>  CONFIG_MTD_NAND_ORION=y
>  CONFIG_BLK_DEV_LOOP=y
>  # CONFIG_SCSI_PROC_FS is not set
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index cd72b92..1a35257 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -130,6 +131,7 @@ static int __init orion_nand_probe(struct platform_device 
> *pdev)
>   if (!of_property_read_u32(pdev->dev.of_node,
>   "chip-delay", &val))
>   board->chip_delay = (u8)val;
> + board->ecc_mode = of_get_nand_ecc_mode(pdev->dev.of_node);

>   } else
>   board = pdev->dev.platform_data;
>  
> @@ -140,7 +142,8 @@ static int __init orion_nand_probe(struct platform_device 
> *pdev)
>   nc->IO_ADDR_R = nc->IO_ADDR_W = io_base;
>   nc->cmd_ctrl = orion_nand_cmd_ctrl;
>   nc->read_buf = orion_nand_read_buf;
> - nc->ecc.mode = NAND_ECC_SOFT;
> + nc->ecc.mode = board->ecc_mode == NAND_ECC_SOFT_BCH ?
> + NAND_ECC_SOFT_BCH : NAND_ECC_SOFT;

Hi Stefan

What about a user that wants one of the other valid values?
NAND_ECC_OOB_FIRST, NAND_ECC_HW_SYNDROME, etc.

Would:

if (IS_ERR(board->ecc_mode)) {
nc->ecc.mode = NAND_ECC_SOFT;
dev_info(&pdev->dev, "Defaulting to NAND_ECC_SOFT");
} else
nc->ecc.mode = board->ecc_mode

be better?

   Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: power: Add simple poweroff-gpio driver

[Andrew Lunn]

On Thu, Dec 13, 2012 at 03:51:59PM -0500, Dave Jones wrote:
> On Thu, Dec 13, 2012 at 08:21:57PM +, Linux Kernel wrote:
>  > Gitweb: 
> http://git.kernel.org/linus/;a=commit;h=96ff0f5c7efd4a2205c48a76a6a1fcd2731e6128
>  > Commit: 96ff0f5c7efd4a2205c48a76a6a1fcd2731e6128
>  > Parent: f4a00139b7cbeff538e616a21f6b57249a9d3ed8
>  > Author: Jamie Lentin 
>  > AuthorDate: Sat Nov 17 09:51:04 2012 +0100
>  > Committer:  Jason Cooper 
>  > CommitDate: Sat Nov 24 02:56:38 2012 +
>  > 
>  > power: Add simple poweroff-gpio driver
>  > 
>  > Given appropriate devicetree bindings, this driver registers a
>  > pm_power_off function to set a GPIO line high/low to power down
>  > your board.
> 
> Given this seems to be dependant on device-tree, shouldn't there be
> some 'depends on' in the kconfig to prevent this showing up on architectures
> that don't implement it ? 
> 
>  > +menuconfig POWER_RESET
>  > +  bool "Board level reset or power off"
>  > +  help
>  > +Provides a number of drivers which either reset a complete board
>  > +or shut it down, by manipulating the main power supply on the board.
>  > +
>  > +Say Y here to enable board reset and power off
>  > +
>  > +config POWER_RESET_GPIO
>  > +  bool "GPIO power-off driver"
>  > +  depends on OF_GPIO && POWER_RESET

Hi Dave

Don't these depends on here do what you want?

>  > +  help
>  > +This driver supports turning off your board via a GPIO line.
>  > +If your board needs a GPIO high/low to power down, say Y and
>  > +create a binding in your devicetree.
> 
> If not, upon seeing this, I suspect many users will ask "how do I know if I 
> need this?"
> given there's no mention of the sort of hardware this is useful on.

Its a generic driver. I know its useful on various Marvell kirkwood
and orion5x devices. I've also heard it useful on some Tegra boards.

Are you asking i list these boards?

Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: power: Add simple poweroff-gpio driver

[Andrew Lunn]

> > I think it needs to be on the menuconfig, rather than the child options.
> > I don't have OF_GPIO, but I still got asked for the former.
> 
> The menuconfig enables a class of drivers (at least theoretically in the
> future, when more such drivers turn up), and there's no reason to
> believe that all of those drivers will depend on OF. So in my opinion,
> making POWER_RESET_GPIO depend on OF makes sense, but making POWER_RESET
> depend on it doesn't.

I have another driver coming soon which will not depend on OF_GPIO. It
does however depend on OF. Its for a class of boards which have a
microcontroller controlling the main power supply, and sending an
character over a UART port is used to turn the board power off.

There might also be some legacy drivers which could be moved here
which don't depend on OF at all.

So i would prefer to keep POWER_RESET generic.

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: power: Add simple poweroff-gpio driver

[Andrew Lunn]

>  > Its a generic driver. I know its useful on various Marvell kirkwood
>  > and orion5x devices. I've also heard it useful on some Tegra boards.
>  > 
>  > Are you asking i list these boards?
> 

> No, but at least mentioning the architecture might have clued me in
> quicker that this wasn't some now ACPI-ism when I saw it on x86.

Hi Dave

It is architecture independent. There are examples of ARM, AVR32, &
unicore32 boards which could use this and there might be more.

  Andrew
  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type

[Andrew Lunn]

On Sun, Sep 30, 2012 at 04:23:27PM +0800, Axel Lin wrote:
> Signed-off-by: Axel Lin 
> ---
>  drivers/gpio/gpio-mvebu.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index 902af43..7a874129 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -381,11 +381,13 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, 
> unsigned int type)
>   u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
>   u &= ~(1 << pin);
>   writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
> + break;
>   case IRQ_TYPE_EDGE_FALLING:
>   case IRQ_TYPE_LEVEL_LOW:
>   u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
>   u |= 1 << pin;
>   writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
> + break;
>   case IRQ_TYPE_EDGE_BOTH: {
>   u32 v;
>  
> @@ -401,6 +403,7 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, 
> unsigned int type)
>   else
>   u &= ~(1 << pin);   /* rising */
>   writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
> + break;
>   }
>   }
>   return 0;

Hi Axel

Good catch, thanks.

Acked-by: Andrew Lunn 

  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] Enable ecc-mode selection in the driver

[Andrew Lunn]

On Wed, Jan 16, 2013 at 12:43:57PM +0100, Stefan Peter wrote:
> Hi Andrew
> 
> on 15.01.2013 13:51, Andrew Lunn wrote:
> > On Tue, Jan 15, 2013 at 01:13:12PM +0100, Stefan Peter wrote:
> >> In order to be able to use the ecc-mode, add the bch module to the default
> >> settings for the kirwood boards and enable the activation in orin-nand.c
> >>
> >> Signed-off-by: Stefan Peter 
> >> ---
> >> diff --git a/arch/arm/configs/kirkwood_defconfig 
> >> b/arch/arm/configs/kirkwood_defconfig
> >> index 93f3794..4a9d3f7 100644
> >> --- a/arch/arm/configs/kirkwood_defconfig
> >> +++ b/arch/arm/configs/kirkwood_defconfig
> >> @@ -84,6 +84,7 @@ CONFIG_MTD_CFI_STAA=y
> >>  CONFIG_MTD_PHYSMAP=y
> >>  CONFIG_MTD_M25P80=y
> >>  CONFIG_MTD_NAND=y
> >> +CONFIG_MTD_NAND_ECC_BCH=y
> >>  CONFIG_MTD_NAND_ORION=y
> >>  CONFIG_BLK_DEV_LOOP=y
> >>  # CONFIG_SCSI_PROC_FS is not set
> >> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> >> index cd72b92..1a35257 100644
> >> --- a/drivers/mtd/nand/orion_nand.c
> >> +++ b/drivers/mtd/nand/orion_nand.c
> >> @@ -14,6 +14,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -130,6 +131,7 @@ static int __init orion_nand_probe(struct 
> >> platform_device *pdev)
> >>if (!of_property_read_u32(pdev->dev.of_node,
> >>"chip-delay", &val))
> >>board->chip_delay = (u8)val;
> >> +  board->ecc_mode = of_get_nand_ecc_mode(pdev->dev.of_node);
> > 
> >>} else
> >>board = pdev->dev.platform_data;
> >>  
> >> @@ -140,7 +142,8 @@ static int __init orion_nand_probe(struct 
> >> platform_device *pdev)
> >>nc->IO_ADDR_R = nc->IO_ADDR_W = io_base;
> >>nc->cmd_ctrl = orion_nand_cmd_ctrl;
> >>nc->read_buf = orion_nand_read_buf;
> >> -  nc->ecc.mode = NAND_ECC_SOFT;
> >> +  nc->ecc.mode = board->ecc_mode == NAND_ECC_SOFT_BCH ?
> >> +  NAND_ECC_SOFT_BCH : NAND_ECC_SOFT;
> > 
> > Hi Stefan
> > 
> > What about a user that wants one of the other valid values?
> > NAND_ECC_OOB_FIRST, NAND_ECC_HW_SYNDROME, etc.
> 
> As far as I understand, NAND_ECC_NONE, NAND_ECC_SOFT and
> NAND_ECC_SOFT_BCH are the only ECC modes that do not require
> corresponding hardware support which is missing in the marvell
> 88F6180/88F619x/88F628x. From my point of view, NAND_ECC_NONE does not
> make sense, too, because MLC NAND Flash requires ECC to be usable.
> 
> > 
> > Would:
> > 
> > if (IS_ERR(board->ecc_mode)) {
> > nc->ecc.mode = NAND_ECC_SOFT;
> > dev_info(&pdev->dev, "Defaulting to NAND_ECC_SOFT");
> > } else
> > nc->ecc.mode = board->ecc_mode
> > 
> > be better?
> 
> I feel safer by limiting the modes to what I could test.

Hi Stefan

O.K, but i still think a warning message would be useful when
board->ecc_mode is an error code.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v3 12/12] net: dsa: mv88e6xxx: add support for DSA ageing time

[Andrew Lunn]

On Mon, Jul 18, 2016 at 08:45:40PM -0400, Vivien Didelot wrote:
> Implement the DSA driver function to configure the bridge ageing time.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next v3 10/12] net: dsa: support switchdev ageing time attr

[Andrew Lunn]

On Mon, Jul 18, 2016 at 08:45:38PM -0400, Vivien Didelot wrote:
> Add a new function for DSA drivers to handle the switchdev
> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute.
> 
> The ageing time is passed as milliseconds.
> 
> Also because we can have multiple logical bridges on top of a physical
> switch and ageing time are switch-wide, call the driver function with
> the fastest ageing time in use on the chip instead of the requested one.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next v3 11/12] net: dsa: mv88e6xxx: add G1 helper for ageing time

[Andrew Lunn]

On Mon, Jul 18, 2016 at 08:45:39PM -0400, Vivien Didelot wrote:
> All Marvell switch chips from (88E6060 to 88E6390) have a ATU Control
> register containing bits 11:4 to configure an ATU Age Time quotient.
> 
> However the coefficient used to calculate the ATU Age Time vary with the
> models. E.g. 88E6060, 88E6352 and 88E6390 use respectively 16, 15 and
> 3.75 seconds.
> 
> Add a age_time_coeff to the info structure to handle this and a Global 1
> helper to set the default age time of 5 minutes in the setup code.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next] net: dsa: add CONFIG_NET_DSA_LEGACY

[Andrew Lunn]

On Wed, Jul 20, 2016 at 06:26:41PM -0400, Vivien Didelot wrote:
> This patch simply moves the legacy DSA code from dsa.c to legacy.c,
> except the few shared symbols which remain in dsa.c.

I think it is a bit early for this. Lets convert all in kernel users
to the new binding first.

> Signed-off-by: Vivien Didelot 
> ---
>  drivers/net/dsa/Kconfig  |4 +-
>  drivers/net/dsa/mv88e6xxx/chip.c |8 +
>  include/net/dsa.h|4 +
>  net/dsa/Kconfig  |8 +
>  net/dsa/Makefile |1 +
>  net/dsa/dsa.c|  985 
>  net/dsa/legacy.c | 1013 
> ++

I'm surprised git did not notice this is a rename.

Andrew

Re: [PATCH net-next v2 1/3] net: dsa: mv88e6xxx: remove unused phy_mutex

[Andrew Lunn]

On Wed, Jul 20, 2016 at 06:18:34PM -0400, Vivien Didelot wrote:
> Only reg_lock is necessary now and phy_mutex is dead. Remove it.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: rework EEPROM access

[Andrew Lunn]

On Wed, Jul 20, 2016 at 06:18:35PM -0400, Vivien Didelot wrote:
> The 6352 family of switches and compatibles provide a 8-bit address and
> 16-bit data access to an optional EEPROM.
> 
> Newer chip such as the 6390 family slightly changed the access to 16-bit
> address and 8-bit data.
> 
> This commit cleans up the EEPROM access code for 16-bit access and makes
> it easy to eventually introduce future support for 8-bit access.
> 
> Here's a list of notable changes brought by this patch:
> 
>   - provide Global2 unlocked helpers for EEPROM commands
>   - remove eeprom_mutex, only reg_lock is necessary for driver functions
>   - eeprom_len is 0 for chip without EEPROM, so return it directly
>   - the Running bit must be 0 before r/w, so wait for Busy *and* Running
>   - remove now unused mv88e6xxx_wait and mv88e6xxx_reg_write
>   - other than that, the logic (in _{get,set}_eeprom16) didn't change
> 
> Chips with an 8-bit EEPROM access will require to implement the
> 8-suffixed variant of G2 helpers and the related flag:
> 
> #define MV88E6XXX_FLAGS_EEPROM8   \
>   (MV88E6XXX_FLAG_G2_EEPROM_CMD | \
>    MV88E6XXX_FLAG_G2_EEPROM_ADDR)
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next v2 3/3] net: dsa: mv88e6xxx: kill last locked reg_read

[Andrew Lunn]

On Wed, Jul 20, 2016 at 06:18:36PM -0400, Vivien Didelot wrote:
> Get rid of the last usage of the locked mv88e6xxx_reg_read function with
> a new mv88e6xxx_port_read helper, useful later for chips with different
> port registers base address.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH 00/18] ARM: mvebu: misc Armada 38x/39x DT and v7 defconfig improvements

[Andrew Lunn]

On Thu, Jul 21, 2016 at 02:43:56PM +0200, Grzegorz Jaszczyk wrote:

Hi Grzegorz

Some of these patches are missing a commit log entry. Please add at
least one line.

  Andrew

Re: [PATCH net-next] net: dsa: add CONFIG_NET_DSA_LEGACY

[Andrew Lunn]

On Thu, Jul 21, 2016 at 10:46:56AM -0400, Vivien Didelot wrote:
> Florian Fainelli  writes:
> 
> > Le 20/07/2016 à 17:35, Andrew Lunn a écrit :
> >> On Wed, Jul 20, 2016 at 06:26:41PM -0400, Vivien Didelot wrote:
> >>> This patch simply moves the legacy DSA code from dsa.c to legacy.c,
> >>> except the few shared symbols which remain in dsa.c.
> >> 
> >> I think it is a bit early for this. Lets convert all in kernel users
> >> to the new binding first.
> >
> > Fine with me, let's try to get the in-tree DTS files converted to the
> > new binding by v4.9 so we can then introduce this Kconfig symbol and
> > start producing warnings if the old binding is encountered, how does
> > that sound?
> 
> If you guys prefer going that way, that's fine with me too ;-)

Yes, i would prefer that.

 Andrew

Re: [PATCH 1/4] net-next: dsa: fix duplicate invocation of set_addr()

[Andrew Lunn]

On Mon, Sep 19, 2016 at 03:28:00PM +0200, John Crispin wrote:
> commit 83c0afaec7b730b ("net: dsa: Add new binding implementation")
> has a duplicate invocation of the set_addr() operation callback. Remove one
> of them.

Upps. My error...

> 
> Signed-off-by: John Crispin 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH 0/4] net-next: dsa: set_addr should be optional

[Andrew Lunn]

On Mon, Sep 19, 2016 at 03:27:59PM +0200, John Crispin wrote:
> The Marvell driver is the only one that actually sets the switches HW
> address. All other drivers have an empty stub. fix this by making the
> callback optional.

Hi John

Thanks for doing this,

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next] net: dsa: mv88e6xxx: handle multiple ports in ATU

[Andrew Lunn]

Hi Vivien

> + do {
> + err = _mv88e6xxx_atu_getnext(chip, fid, &next);
> + if (err)
> + return err;
> +
> + if (next.state == GLOBAL_ATU_DATA_STATE_UNUSED)
> + break;
> +
> + if (ether_addr_equal(next.mac, addr)) {
> + *entry = next;
> + return 0;
> + }
> + } while (!is_broadcast_ether_addr(next.mac));

This is correct, but i wonder how well it scales? When we have a lot
of entries in the ATU, this is going to take time. At some point in
the future, we might want to keep a shadow copy of static entries of
the ATU in RAM. We then don't need to search for them.

But that is for later, once we have some complaints this is too slow.

Andrew

Re: [PATCH net-next] net: dsa: mv88e6xxx: handle multiple ports in ATU

[Andrew Lunn]

On Mon, Sep 19, 2016 at 08:29:40PM -0400, Vivien Didelot wrote:
> Hi Andrew,
> 
> Andrew Lunn  writes:
> 
> > Hi Vivien
> >
> >> +  do {
> >> +  err = _mv88e6xxx_atu_getnext(chip, fid, &next);
> >> +  if (err)
> >> +  return err;
> >> +
> >> +  if (next.state == GLOBAL_ATU_DATA_STATE_UNUSED)
> >> +  break;
> >> +
> >> +  if (ether_addr_equal(next.mac, addr)) {
> >> +  *entry = next;
> >> +  return 0;
> >> +  }
> >> +  } while (!is_broadcast_ether_addr(next.mac));
> >
> > This is correct, but i wonder how well it scales? When we have a lot
> > of entries in the ATU, this is going to take time. At some point in
> > the future, we might want to keep a shadow copy of static entries of
> > the ATU in RAM. We then don't need to search for them.
> 
> There won't be any issue about time here, because we are searching a
> precise FID.

Ah, i didn't realise you can do that. However, it makes sense, the
hardware needs to do it all the time when it receives a frame.

 Andrew

Re: [PATCH net-next] net: dsa: mv88e6xxx: handle multiple ports in ATU

[Andrew Lunn]

On Mon, Sep 19, 2016 at 07:56:11PM -0400, Vivien Didelot wrote:
> An address can be loaded in the ATU with multiple ports, for instance
> when adding multiple ports to a Multicast group with "bridge mdb".
> 
> The current code doesn't allow that. Add an helper to get a single entry
> from the ATU, then set or clear the requested port, before loading the
> entry back in the ATU.
> 
> Note that the required _mv88e6xxx_atu_getnext function is defined below
> mv88e6xxx_port_db_load_purge, so forward-declare it for the moment. The
> ATU code will be isolated in future patches.
> 
> Fixes: 83dabd1fa84c ("net: dsa: mv88e6xxx: make switchdev DB ops generic")

Is this a real fixes? You don't make it clear what goes wrong. I
assume adding the same MAC address for a second time but for a
different port removes the first entry for the old port?

> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

[Andrew Lunn]

On Tue, Sep 20, 2016 at 10:13:14PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-09-20 at 16:00 +0930, Joel Stanley wrote:
> > On Aspeed SoC with a direct PHY connection (non-NSCI), we receive
> > continual PHYSTS interrupts:
> > 
> >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] = 0x200: PHYSTS_CHG
> >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] = 0x200: PHYSTS_CHG
> >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] = 0x200: PHYSTS_CHG
> >  [   20.30] ftgmac100 1e66.ethernet eth0: [ISR] = 0x200: PHYSTS_CHG
> > 
> > This is because the driver was enabling low-level sensitive interrupt
> > generation where the systems are wired for high-level. All CPU cycles
> > are spent servicing this interrupt.
> 
> If this is a system wiring issue, should it be represented by a DT
> property ?

Is there a device tree binding document somewhere?

Is it possible just to put ACTIVE_HIGH in the right place in the
binding?

Andrew

Re: [PATCH net-next] net: dsa: mv88e6xxx: handle multiple ports in ATU

[Andrew Lunn]

On Mon, Sep 19, 2016 at 09:07:16PM -0400, Vivien Didelot wrote:
> Hi Andrew,
> 
> Andrew Lunn  writes:
> 
> > On Mon, Sep 19, 2016 at 07:56:11PM -0400, Vivien Didelot wrote:
> >> An address can be loaded in the ATU with multiple ports, for instance
> >> when adding multiple ports to a Multicast group with "bridge mdb".
> >>
> >> The current code doesn't allow that. Add an helper to get a single entry
> >> from the ATU, then set or clear the requested port, before loading the
> >> entry back in the ATU.
> >>
> >> Note that the required _mv88e6xxx_atu_getnext function is defined below
> >> mv88e6xxx_port_db_load_purge, so forward-declare it for the moment. The
> >> ATU code will be isolated in future patches.
> >>
> >> Fixes: 83dabd1fa84c ("net: dsa: mv88e6xxx: make switchdev DB ops generic")
> >
> > Is this a real fixes? You don't make it clear what goes wrong. I
> > assume adding the same MAC address for a second time but for a
> > different port removes the first entry for the old port?
> 
> Yes, this is what happens, sorry for the bad message. Below is an
> example with the relevant hardware bits.
> 
> Here's the current behavior, without this patch:
> 
> # bridge mdb add dev br0 port lan0 grp 238.39.20.86
> 
> FID  MAC Addr  State Trunk?  DPV/Trunk ID
> 001:00:5e:27:14:56 MC_STATIC   n 0 - - - - - -
> 
> # bridge mdb add dev br0 port lan2 grp 238.39.20.86
> 
> FID  MAC Addr  State Trunk?  DPV/Trunk ID
> 001:00:5e:27:14:56 MC_STATIC   n - - 2 - - - - 
> 
> Here's the new behavior, with this patch:
> 
> # bridge mdb add dev br0 port lan0 grp 238.39.20.86
> 
> FID  MAC Addr  State Trunk?  DPV/Trunk ID
> 001:00:5e:27:14:56 MC_STATIC   n 0 - - - - - -
> 
> # bridge mdb add dev br0 port lan2 grp 238.39.20.86
> 
> FID  MAC Addr  State Trunk?  DPV/Trunk ID
> 001:00:5e:27:14:56 MC_STATIC   n 0 - 2 - - - -

Hi Vivien

it would be nice to update the commit message with this text. 

Otherwise

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

[Andrew Lunn]

On Mon, Jun 20, 2016 at 12:03:37PM -0400, Vivien Didelot wrote:
> When the SMI address of the switch chip is zero, the chip assumes to be
> the only one on the SMI master bus and thus responds to all its known
> SMI devices addresses (port registers, Global2, etc.)
> 
> When its SMI address is not zero, some chips (e.g. 88E6352) use an
> indirect access through two SMI Command and Data registers.
> 
> Other models (e.g. 88E6060) using less than 16 internal SMI addresses
> always use a direct access.
> 
> Add a capability flag to describe chips supporting the (indirect)
> Multi-chip Addressing Mode, and a low-level API to access the registers
> via SMI.
> 
> Other accesses (like Ethernet management frames) may be added later.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

This series is now ready for merging.

Thanks
Andrew