Re: [PATCH v4 1/3] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

[Jason Cooper]

Hi Zhao Qiang,

On Mon, Aug 01, 2016 at 10:53:18AM +0800, Zhao Qiang wrote:
> move the driver from drivers/soc/fsl/qe to drivers/irqchip,
> merge qe_ic.h and qe_ic.c into irq-qeic.c.
> 
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v2:
>   - modify the subject and commit msg
> Changes for v3:
>   - merge .h file to .c, rename it with irq-qeic.c
> Changes for v4:
>   - modify comments
> 
>  drivers/irqchip/Makefile   |   1 +
>  drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} |  95 ++-
>  drivers/soc/fsl/qe/Makefile|   2 +-
>  drivers/soc/fsl/qe/qe_ic.h | 103 
> -
>  4 files changed, 94 insertions(+), 107 deletions(-)
>  rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%)

Could you disable rename detection so that we can review the entire
codebase being brought into drivers/irqchip?

thx,

Jason.

>  delete mode 100644 drivers/soc/fsl/qe/qe_ic.h
> 
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 38853a1..846b34e 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)+= irq-pic32-evic.o
>  obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
>  obj-$(CONFIG_LS_SCFG_MSI)+= irq-ls-scfg-msi.o
>  obj-$(CONFIG_EZNPS_GIC)  += irq-eznps.o
> +obj-$(CONFIG_QUICC_ENGINE)   += irq-qeic.o
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c
> similarity index 85%
> rename from drivers/soc/fsl/qe/qe_ic.c
> rename to drivers/irqchip/irq-qeic.c
> index ec2ca86..48ceded 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/irqchip/irq-qeic.c
> @@ -1,7 +1,7 @@
>  /*
> - * arch/powerpc/sysdev/qe_lib/qe_ic.c
> + * drivers/irqchip/irq-qeic.c
>   *
> - * Copyright (C) 2006 Freescale Semiconductor, Inc.  All rights reserved.
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.  All rights reserved.
>   *
>   * Author: Li Yang 
>   * Based on code from Shlomi Gridish 
> @@ -30,7 +30,96 @@
>  #include 
>  #include 
>  
> -#include "qe_ic.h"
> +#define NR_QE_IC_INTS64
> +
> +/* QE IC registers offset */
> +#define QEIC_CICR0x00
> +#define QEIC_CIVEC   0x04
> +#define QEIC_CRIPNR  0x08
> +#define QEIC_CIPNR   0x0c
> +#define QEIC_CIPXCC  0x10
> +#define QEIC_CIPYCC  0x14
> +#define QEIC_CIPWCC  0x18
> +#define QEIC_CIPZCC  0x1c
> +#define QEIC_CIMR0x20
> +#define QEIC_CRIMR   0x24
> +#define QEIC_CICNR   0x28
> +#define QEIC_CIPRTA  0x30
> +#define QEIC_CIPRTB  0x34
> +#define QEIC_CRICR   0x3c
> +#define QEIC_CHIVEC  0x60
> +
> +/* Interrupt priority registers */
> +#define CIPCC_SHIFT_PRI0 29
> +#define CIPCC_SHIFT_PRI1 26
> +#define CIPCC_SHIFT_PRI2 23
> +#define CIPCC_SHIFT_PRI3 20
> +#define CIPCC_SHIFT_PRI4 13
> +#define CIPCC_SHIFT_PRI5 10
> +#define CIPCC_SHIFT_PRI6 7
> +#define CIPCC_SHIFT_PRI7 4
> +
> +/* CICR priority modes */
> +#define CICR_GWCC0x0004
> +#define CICR_GXCC0x0002
> +#define CICR_GYCC0x0001
> +#define CICR_GZCC0x0008
> +#define CICR_GRTA0x0020
> +#define CICR_GRTB0x0040
> +#define CICR_HPIT_SHIFT  8
> +#define CICR_HPIT_MASK   0x0300
> +#define CICR_HP_SHIFT24
> +#define CICR_HP_MASK 0x3f00
> +
> +/* CICNR */
> +#define CICNR_WCC1T_SHIFT20
> +#define CICNR_ZCC1T_SHIFT28
> +#define CICNR_YCC1T_SHIFT12
> +#define CICNR_XCC1T_SHIFT4
> +
> +/* CRICR */
> +#define CRICR_RTA1T_SHIFT20
> +#define CRICR_RTB1T_SHIFT28
> +
> +/* Signal indicator */
> +#define SIGNAL_MASK  3
> +#define SIGNAL_HIGH  2
> +#define SIGNAL_LOW   0
> +
> +struct qe_ic {
> + /* Control registers offset */
> + volatile u32 __iomem *regs;
> +
> + /* The remapper for this QEIC */
> + struct irq_domain *irqhost;
> +
> + /* The "linux" controller struct */
> + struct irq_chip hc_irq;
> +
> + /* VIRQ numbers of QE high/low irqs */
> + unsigned int virq_high;
> + unsigned int virq_low;
> +};
> +
> +/*
> + * QE interrupt controller internal structure
> + */
> +struct qe_ic_info {
> + /* location of this source at the QIMR register. */
> + u32 mask;
> +
> + /* Mask register offset */
> + u32 mask_reg;
> +
> + /*
> +  * for grouped interrupts sources - the interrupt
> +  * code as appears at the group priority register
> +  */
> + u8  pri_code;
> +
> + /* Group priority register offset */
> + u32 pri_reg;
> +};
>  
>  static DEFINE_RAW_SPINLOCK(qe_ic_lock);
>  
> diff --git a/drivers/soc/fsl/qe/Makefile 

Re: [Patch v3 1/3] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

[Jason Cooper]

Hi Zhao Qiang,

On Mon, Jul 25, 2016 at 04:59:54PM +0800, Zhao Qiang wrote:
> move the driver from drivers/soc/fsl/qe to drivers/irqchip,
> merge qe_ic.h and qe_ic.c into irq-qeic.c.
> 
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v2:
>   - modify the subject and commit msg
> Changes for v3:
>   - merge .h file to .c, rename it with irq-qeic.c
> 
>  drivers/irqchip/Makefile   |   1 +
>  drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} |  82 +++-
>  drivers/soc/fsl/qe/Makefile|   2 +-
>  drivers/soc/fsl/qe/qe_ic.h | 103 
> -
>  4 files changed, 83 insertions(+), 105 deletions(-)
>  rename drivers/{soc/fsl/qe/qe_ic.c => irqchip/irq-qeic.c} (85%)
>  delete mode 100644 drivers/soc/fsl/qe/qe_ic.h
> 
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 38853a1..cef999d 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)+= irq-pic32-evic.o
>  obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
>  obj-$(CONFIG_LS_SCFG_MSI)+= irq-ls-scfg-msi.o
>  obj-$(CONFIG_EZNPS_GIC)  += irq-eznps.o
> +obj-$(CONFIG_QUICC_ENGINE)   += qe_ic.o

Did you test this? ;-)

> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/irqchip/irq-qeic.c
> similarity index 85%
> rename from drivers/soc/fsl/qe/qe_ic.c
> rename to drivers/irqchip/irq-qeic.c
> index ec2ca86..1f91225 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/irqchip/irq-qeic.c
> @@ -30,7 +30,87 @@
>  #include 
>  #include 
>  
> -#include "qe_ic.h"
> +#define NR_QE_IC_INTS64
> +
> +/* QE IC registers offset */
> +#define QEIC_CICR0x00
> +#define QEIC_CIVEC   0x04
> +#define QEIC_CRIPNR  0x08
> +#define QEIC_CIPNR   0x0c
> +#define QEIC_CIPXCC  0x10
> +#define QEIC_CIPYCC  0x14
> +#define QEIC_CIPWCC  0x18
> +#define QEIC_CIPZCC  0x1c
> +#define QEIC_CIMR0x20
> +#define QEIC_CRIMR   0x24
> +#define QEIC_CICNR   0x28
> +#define QEIC_CIPRTA  0x30
> +#define QEIC_CIPRTB  0x34
> +#define QEIC_CRICR   0x3c
> +#define QEIC_CHIVEC  0x60
> +
> +/* Interrupt priority registers */
> +#define CIPCC_SHIFT_PRI0 29
> +#define CIPCC_SHIFT_PRI1 26
> +#define CIPCC_SHIFT_PRI2 23
> +#define CIPCC_SHIFT_PRI3 20
> +#define CIPCC_SHIFT_PRI4 13
> +#define CIPCC_SHIFT_PRI5 10
> +#define CIPCC_SHIFT_PRI6 7
> +#define CIPCC_SHIFT_PRI7 4
> +
> +/* CICR priority modes */
> +#define CICR_GWCC0x0004
> +#define CICR_GXCC0x0002
> +#define CICR_GYCC0x0001
> +#define CICR_GZCC0x0008
> +#define CICR_GRTA0x0020
> +#define CICR_GRTB0x0040
> +#define CICR_HPIT_SHIFT  8
> +#define CICR_HPIT_MASK   0x0300
> +#define CICR_HP_SHIFT24
> +#define CICR_HP_MASK 0x3f00
> +
> +/* CICNR */
> +#define CICNR_WCC1T_SHIFT20
> +#define CICNR_ZCC1T_SHIFT28
> +#define CICNR_YCC1T_SHIFT12
> +#define CICNR_XCC1T_SHIFT4
> +
> +/* CRICR */
> +#define CRICR_RTA1T_SHIFT20
> +#define CRICR_RTB1T_SHIFT28
> +
> +/* Signal indicator */
> +#define SIGNAL_MASK  3
> +#define SIGNAL_HIGH  2
> +#define SIGNAL_LOW   0
> +
> +struct qe_ic {
> + /* Control registers offset */
> + volatile u32 __iomem *regs;
> +
> + /* The remapper for this QEIC */
> + struct irq_domain *irqhost;
> +
> + /* The "linux" controller struct */
> + struct irq_chip hc_irq;
> +
> + /* VIRQ numbers of QE high/low irqs */
> + unsigned int virq_high;
> + unsigned int virq_low;
> +};
> +
> +/*
> + * QE interrupt controller internal structure
> + */
> +struct qe_ic_info {
> + u32 mask; /* location of this source at the QIMR register. */
> + u32 mask_reg; /* Mask register offset */
> + u8  pri_code; /* for grouped interrupts sources - the interrupt
> +  code as appears at the group priority register */
> + u32 pri_reg;  /* Group priority register offset */
> +};

Please, no tail comments.  Refer to KernelDoc.

>  
>  static DEFINE_RAW_SPINLOCK(qe_ic_lock);
>  
> diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile
> index 2031d38..51e4726 100644
> --- a/drivers/soc/fsl/qe/Makefile
> +++ b/drivers/soc/fsl/qe/Makefile
> @@ -1,7 +1,7 @@
>  #
>  # Makefile for the linux ppc-specific parts of QE
>  #
> -obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
> +obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_io.o
>  obj-$(CONFIG_CPM)+= qe_common.o
>  obj-$(CONFIG_UCC)+= ucc.o
>  obj-$(CONFIG_UCC_SLOW)   += ucc_slow.o
> diff --git a/drivers/soc/fsl/qe/qe_ic.h b/drivers/soc/fsl/qe/qe_ic.h
> deleted 

Re: [PATCH v2] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

[Jason Cooper]

Hi Zhao Qiang,

On Thu, Jul 07, 2016 at 09:23:55AM +0800, Zhao Qiang wrote:
> The driver stays the same.
> 
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v2:
>   - modify the subject and commit msg
> 
>  drivers/irqchip/Makefile| 1 +
>  drivers/{soc/fsl/qe => irqchip}/qe_ic.c | 0
>  drivers/{soc/fsl/qe => irqchip}/qe_ic.h | 0
>  drivers/soc/fsl/qe/Makefile | 2 +-
>  4 files changed, 2 insertions(+), 1 deletion(-)
>  rename drivers/{soc/fsl/qe => irqchip}/qe_ic.c (100%)
>  rename drivers/{soc/fsl/qe => irqchip}/qe_ic.h (100%)

Please merge the include file into the C file and rename to follow the
naming convention in drivers/irqchip/.  e.g. irq-qeic.c or irq-qe_ic.c.

Once you have that, please resend the entire series with this as the
first patch.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] irqchip/qeic: merge qeic init code from platforms to a common function

[Jason Cooper]

Hi Zhao Qiang,

On Wed, Jul 06, 2016 at 02:01:38PM +0800, Zhao Qiang wrote:
> The codes of qe_ic init from a variety of platforms are redundant,
> merge them to a common function and put it to irqchip/qe_ic.c
> 
> For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0,
> qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of
> "qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);".
> 
> qe_ic_cascade_muxed_mpic was used for boards has the same interrupt
> number for low interrupt and high interrupt, qe_ic_init has checked
> if "low interrupt == high interrupt"
> 
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v2:
>   - modify subject and commit msg
>   - add check for qeic by type
> 
>  arch/powerpc/platforms/83xx/misc.c| 15 ---
>  arch/powerpc/platforms/85xx/corenet_generic.c |  9 -
>  arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 --
>  arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 
>  arch/powerpc/platforms/85xx/twr_p102x.c   | 14 --
>  drivers/irqchip/qe_ic.c   | 16 
>  6 files changed, 16 insertions(+), 68 deletions(-)

Hmmm, I seem to be missing the patch moving qe_ic.c into
drivers/irqchip/ ... :-/  Please resend with it attached.  Also, while
we're here,  please follow the file naming convention inside the
drivers/irqchip/ directory.  Something like drivers/irqchip/irq-qeic.c

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] qe/ic: move qe_ic_init from platforms to irqchip

[Jason Cooper]

On Tue, Jul 05, 2016 at 07:27:21AM +, Qiang Zhao wrote:
> On 07/05/2016 11:19 AM, Jason Cooper <ja...@lakedaemon.net> wrote:
> > -Original Message-
> > From: Jason Cooper [mailto:ja...@lakedaemon.net]
> > Sent: Tuesday, July 05, 2016 11:19 AM
> > To: Qiang Zhao <qiang.z...@nxp.com>
> > Cc: o...@buserror.net; t...@linutronix.de; marc.zyng...@arm.com; linuxppc-
> > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Xiaobo Xie
> > <xiaobo@nxp.com>
> > Subject: Re: [PATCH 1/2] qe/ic: move qe_ic_init from platforms to irqchip
> > 
> > Hi Zhao Qiang,
> > 
> > Please reword your subject line to conform to the standard in irqchip (since
> > that's where the code is added).  Also, please adjust the subject line to 
> > express
> > *why* the change is being made.
> > 
> > On Tue, Jul 05, 2016 at 09:46:58AM +0800, Zhao Qiang wrote:
> > > The codes of qe_ic_init in platforms are redundant, move them to qe_ic
> > > under irqchip
> > 
> > This needs to be a lot more clear.  How is backwards compatibility 
> > preserved?
> > Why is lookup by type "qeic" dropped?  In short, please explain everything 
> > that
> > looks funny so we don't have to guess.
> 
> Thank you for your review and feedback.
> 
> > 
> > > Signed-off-by: Zhao Qiang <qiang.z...@nxp.com>
> > > ---
> > >  arch/powerpc/platforms/83xx/misc.c| 15 ---
> > >  arch/powerpc/platforms/85xx/corenet_generic.c |  9 -
> > >  arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 --
> > >  arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 
> > >  arch/powerpc/platforms/85xx/twr_p102x.c   | 14 --
> > >  drivers/irqchip/qe_ic.c   | 14 ++
> > >  6 files changed, 14 insertions(+), 68 deletions(-)
> > >
> > > diff --git a/arch/powerpc/platforms/83xx/misc.c
> > > b/arch/powerpc/platforms/83xx/misc.c
> > > index 7e923ca..9431fc7 100644
> > > --- a/arch/powerpc/platforms/83xx/misc.c
> > > +++ b/arch/powerpc/platforms/83xx/misc.c
> > > @@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void)  }
> > >
> > >  #ifdef CONFIG_QUICC_ENGINE
> > > -void __init mpc83xx_qe_init_IRQ(void) -{
> > > - struct device_node *np;
> > > -
> > > - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> > > - if (!np) {
> > > - np = of_find_node_by_type(NULL, "qeic");
> > > - if (!np)
> > > - return;
> > > - }
> > 
> > This block isn't preserved in the irqchip driver.  Why not?
> 
> I grep qeic in arch/powerpc/boot/dts/*, doesn't find which board use qeic as 
> type.

Unfortunately, checking powerpc/boot/dts/* isn't sufficient for
confirming we aren't going to break backwards compatibility with boards
*in the field*.

Please take a look at:

  d4fb5ebd83c70 powerpc/83xx: consolidate init_IRQ functions
  8159df72d43e2 83xx: add support for the kmeter1 board.

Perhaps one or two of the authors is still around and can say why that
check is there and if it's ok to remove it.

Or, we could just play it safe and keep the check.

...
> > > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > > b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > > index f61cbe2..7ae4901 100644
> > > --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > > +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> > > @@ -279,20 +279,6 @@ static void __init mpc85xx_mds_qeic_init(void)
> > >   of_node_put(np);
> > >   return;
> > >   }
> > > -
> > > - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> > > - if (!np) {
> > > - np = of_find_node_by_type(NULL, "qeic");
> > > - if (!np)
> > > - return;
> > > - }
> > > -
> > > - if (machine_is(p1021_mds))
> > > - qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> > > - qe_ic_cascade_high_mpic);
> > > - else
> > > - qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
> > 
> > This block is also not preserved.  Nor explained in the commit log.  Is it 
> > really ok
> > to drop it?  If so, why?
> 
> on non-p1021_mds mpc85xx_mds boards(mpc8568 and mpc8569).
> The qeic has the same interrupt number for low and high. So use 
> qe_ic_cascade_muxed_mpic for this situation.
> 
> qeic: interr

Re: [PATCH 2/2] qe/ic: refactor qe_ic to simplify

[Jason Cooper]

Morning!

On Tue, Jul 05, 2016 at 07:38:49AM +, Qiang Zhao wrote:
> On 07/05/2016 11:51 AM, Jason Cooper <ja...@lakedaemon.net> wrote:
> > On Tue, Jul 05, 2016 at 09:46:59AM +0800, Zhao Qiang wrote:
...
> > >
> > > Signed-off-by: Zhao Qiang <qiang.z...@nxp.com>
> > > ---
> > >  drivers/irqchip/qe_ic.c| 83 
> > > +--
> > ---
> > >  include/soc/fsl/qe/qe_ic.h |  7 
> > >  2 files changed, 45 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/irqchip/qe_ic.c b/drivers/irqchip/qe_ic.c index
> > > f7f9a81..46652c0 100644
> > > --- a/drivers/irqchip/qe_ic.c
> > > +++ b/drivers/irqchip/qe_ic.c
...
> > > - printk(KERN_DEBUG "Registering qe_ic with sysfs...\n");
> > > + ret = qe_ic_init(0);
> > 
> > Sorry, build machine is down atm.  How was qe_ic_init() called previously?  
> > Is
> > that removed?
> 
> Sorry, I don't understand, could you please explain?

-ENOSLEEP when I wrote that.  :)  *My* build machine, with my copies of
the kernel tree was down, so I had no easy way to dig into the source.

And 

> > > -static int __init qeic_of_init(void)
> > > -{
> > > - struct device_node *np;
> > > -
> > > - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> > > - if (np) {
> > > - qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> > > -qe_ic_cascade_high_mpic);
> > > - of_node_put(np);
> > > - }
> > >   return 0;
> > >  }
> > >
> > > -subsys_initcall(qeic_of_init);

this block is what I missed last night. :-/  Sorry for the noise.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] qe/ic: refactor qe_ic to simplify

[Jason Cooper]

Hi Zhao Qiang,

Same comment as previous patch regarding the subject line.

On Tue, Jul 05, 2016 at 09:46:59AM +0800, Zhao Qiang wrote:
> there are init_qe_ic_sysfs and qeic_of_init, refactor
> them.

Same comment from previous patch about commit log.

> 
> Signed-off-by: Zhao Qiang 
> ---
>  drivers/irqchip/qe_ic.c| 83 
> +-
>  include/soc/fsl/qe/qe_ic.h |  7 
>  2 files changed, 45 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/irqchip/qe_ic.c b/drivers/irqchip/qe_ic.c
> index f7f9a81..46652c0 100644
> --- a/drivers/irqchip/qe_ic.c
> +++ b/drivers/irqchip/qe_ic.c
> @@ -317,27 +317,35 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
>   return irq_linear_revmap(qe_ic->irqhost, irq);
>  }
>  
> -void __init qe_ic_init(struct device_node *node, unsigned int flags,
> -void (*low_handler)(struct irq_desc *desc),
> -void (*high_handler)(struct irq_desc *desc))
> +static int __init qe_ic_init(unsigned int flags)
>  {
> + struct device_node *node;
>   struct qe_ic *qe_ic;
>   struct resource res;
> - u32 temp = 0, ret, high_active = 0;
> + u32 temp = 0, high_active = 0;
> + int ret = 0;
> +
> + node = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (!node)
> + return -ENODEV;
>  
>   ret = of_address_to_resource(node, 0, );
> - if (ret)
> - return;
> + if (ret) {
> + ret = -ENODEV;
> + goto err_put_node;
> + }
>  
>   qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
> - if (qe_ic == NULL)
> - return;
> + if (qe_ic == NULL) {
> + ret = -ENOMEM;
> + goto err_put_node;
> + }
>  
>   qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
>  _ic_host_ops, qe_ic);
>   if (qe_ic->irqhost == NULL) {
> - kfree(qe_ic);
> - return;
> + ret = -ENOMEM;
> + goto err_free_qe_ic;
>   }
>  
>   qe_ic->regs = ioremap(res.start, resource_size());
> @@ -348,9 +356,9 @@ void __init qe_ic_init(struct device_node *node, unsigned 
> int flags,
>   qe_ic->virq_low = irq_of_parse_and_map(node, 1);
>  
>   if (qe_ic->virq_low == NO_IRQ) {
> - printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
> - kfree(qe_ic);
> - return;
> + pr_err("Failed to map QE_IC low IRQ\n");
> + ret = -ENOMEM;
> + goto err_domain_remove;
>   }
>  
>   /* default priority scheme is grouped. If spread mode is*/
> @@ -377,13 +385,23 @@ void __init qe_ic_init(struct device_node *node, 
> unsigned int flags,
>   qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
>  
>   irq_set_handler_data(qe_ic->virq_low, qe_ic);
> - irq_set_chained_handler(qe_ic->virq_low, low_handler);
> + irq_set_chained_handler(qe_ic->virq_low, qe_ic_cascade_low_mpic);
>  
>   if (qe_ic->virq_high != NO_IRQ &&
>   qe_ic->virq_high != qe_ic->virq_low) {
>   irq_set_handler_data(qe_ic->virq_high, qe_ic);
> - irq_set_chained_handler(qe_ic->virq_high, high_handler);
> + irq_set_chained_handler(qe_ic->virq_high,
> + qe_ic_cascade_high_mpic);
>   }
> + return ret;

of_node_put(node)?  Explicitly return success?

> +
> +err_domain_remove:
> + irq_domain_remove(qe_ic->irqhost);
> +err_free_qe_ic:
> + kfree(qe_ic);
> +err_put_node:
> + of_node_put(node);
> + return ret;
>  }
>  
>  void qe_ic_set_highest_priority(unsigned int virq, int high)
> @@ -490,37 +508,26 @@ static struct device device_qe_ic = {
>   .bus = _ic_subsys,
>  };
>  
> -static int __init init_qe_ic_sysfs(void)
> +static int __init init_qe_ic(void)
>  {
> - int rc;
> + int ret;
>  
> - printk(KERN_DEBUG "Registering qe_ic with sysfs...\n");
> + ret = qe_ic_init(0);

Sorry, build machine is down atm.  How was qe_ic_init() called
previously?  Is that removed?

> + if (ret)
> + return ret;
>  
> - rc = subsys_system_register(_ic_subsys, NULL);
> - if (rc) {
> - printk(KERN_ERR "Failed registering qe_ic sys class\n");
> + ret = subsys_system_register(_ic_subsys, NULL);
> + if (ret) {
> + pr_err("Failed registering qe_ic sys class\n");
>   return -ENODEV;
>   }
> - rc = device_register(_qe_ic);
> - if (rc) {
> - printk(KERN_ERR "Failed registering qe_ic sys device\n");
> + ret = device_register(_qe_ic);
> + if (ret) {
> + pr_err("Failed registering qe_ic sys device\n");
>   return -ENODEV;
>   }
> - return 0;
> -}
>  
> -static int __init qeic_of_init(void)
> -{
> - struct device_node *np;
> -
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (np) {
> -

Re: [PATCH 1/2] qe/ic: move qe_ic_init from platforms to irqchip

[Jason Cooper]

Hi Zhao Qiang,

Please reword your subject line to conform to the standard in irqchip
(since that's where the code is added).  Also, please adjust the subject
line to express *why* the change is being made.

On Tue, Jul 05, 2016 at 09:46:58AM +0800, Zhao Qiang wrote:
> The codes of qe_ic_init in platforms are redundant,
> move them to qe_ic under irqchip

This needs to be a lot more clear.  How is backwards compatibility
preserved?  Why is lookup by type "qeic" dropped?  In short, please
explain everything that looks funny so we don't have to guess.

> Signed-off-by: Zhao Qiang 
> ---
>  arch/powerpc/platforms/83xx/misc.c| 15 ---
>  arch/powerpc/platforms/85xx/corenet_generic.c |  9 -
>  arch/powerpc/platforms/85xx/mpc85xx_mds.c | 14 --
>  arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 
>  arch/powerpc/platforms/85xx/twr_p102x.c   | 14 --
>  drivers/irqchip/qe_ic.c   | 14 ++
>  6 files changed, 14 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/83xx/misc.c 
> b/arch/powerpc/platforms/83xx/misc.c
> index 7e923ca..9431fc7 100644
> --- a/arch/powerpc/platforms/83xx/misc.c
> +++ b/arch/powerpc/platforms/83xx/misc.c
> @@ -93,24 +93,9 @@ void __init mpc83xx_ipic_init_IRQ(void)
>  }
>  
>  #ifdef CONFIG_QUICC_ENGINE
> -void __init mpc83xx_qe_init_IRQ(void)
> -{
> - struct device_node *np;
> -
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (!np) {
> - np = of_find_node_by_type(NULL, "qeic");
> - if (!np)
> - return;
> - }

This block isn't preserved in the irqchip driver.  Why not?

> - qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> - of_node_put(np);
> -}
> -
>  void __init mpc83xx_ipic_and_qe_init_IRQ(void)
>  {
>   mpc83xx_ipic_init_IRQ();
> - mpc83xx_qe_init_IRQ();
>  }
>  #endif /* CONFIG_QUICC_ENGINE */
>  
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
> b/arch/powerpc/platforms/85xx/corenet_generic.c
> index a2b0bc8..526fc2b 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -41,8 +41,6 @@ void __init corenet_gen_pic_init(void)
>   unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
>   MPIC_NO_RESET;
>  
> - struct device_node *np;
> -
>   if (ppc_md.get_irq == mpic_get_coreint_irq)
>   flags |= MPIC_ENABLE_COREINT;
>  
> @@ -50,13 +48,6 @@ void __init corenet_gen_pic_init(void)
>   BUG_ON(mpic == NULL);
>  
>   mpic_init(mpic);
> -
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (np) {
> - qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> - qe_ic_cascade_high_mpic);
> - of_node_put(np);
> - }
>  }
>  
>  /*
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
> b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> index f61cbe2..7ae4901 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> @@ -279,20 +279,6 @@ static void __init mpc85xx_mds_qeic_init(void)
>   of_node_put(np);
>   return;
>   }
> -
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (!np) {
> - np = of_find_node_by_type(NULL, "qeic");
> - if (!np)
> - return;
> - }
> -
> - if (machine_is(p1021_mds))
> - qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> - qe_ic_cascade_high_mpic);
> - else
> - qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);

This block is also not preserved.  Nor explained in the commit log.  Is
it really ok to drop it?  If so, why?

> - of_node_put(np);
>  }
>  #else
>  static void __init mpc85xx_mds_qe_init(void) { }
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index 3f4dad1..779f54f 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -49,10 +49,6 @@ void __init mpc85xx_rdb_pic_init(void)
>   struct mpic *mpic;
>   unsigned long root = of_get_flat_dt_root();
>  
> -#ifdef CONFIG_QUICC_ENGINE
> - struct device_node *np;
> -#endif
> -
>   if (of_flat_dt_is_compatible(root, "fsl,MPC85XXRDB-CAMP")) {
>   mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET |
>   MPIC_BIG_ENDIAN |
> @@ -67,18 +63,6 @@ void __init mpc85xx_rdb_pic_init(void)
>  
>   BUG_ON(mpic == NULL);
>   mpic_init(mpic);
> -
> -#ifdef CONFIG_QUICC_ENGINE
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (np) {
> - qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> - qe_ic_cascade_high_mpic);
> - of_node_put(np);
> -
> - } else
> -   

Re: [PATCH v2 3/5] ARM: mvebu: Change vendor prefix for Intersil Corporation to isil

[Jason Cooper]

On Mon, Sep 08, 2014 at 11:19:18AM +0200, Philipp Zabel wrote:
 Currently there is a wild mixture of isl, isil, and intersil
 compatibles in the kernel. At this point, changing the vendor
 symbol to the most often used variant, which is equal to the
 NASDAQ symbol, isil, should not hurt.
 
 Signed-off-by: Philipp Zabel p.za...@pengutronix.de
 ---
  arch/arm/boot/dts/armada-370-netgear-rn102.dts | 2 +-
  arch/arm/boot/dts/armada-370-netgear-rn104.dts | 2 +-
  arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

Applied to mvebu/dt

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/6] Change vendor prefix for Intersil Corporation

[Jason Cooper]

On Wed, Aug 20, 2014 at 08:16:43AM -0400, Jason Cooper wrote:
 Philipp,
 
 On Wed, Aug 20, 2014 at 10:42:58AM +0200, Philipp Zabel wrote:
  Hi,
  
  currently there is a wild mixture of isl, isil, and intersil
  compatibles in the kernel. I figure at this point it is still
  possible to change this to use isil everywhere without too
  much pain, but it might be preferred to keep the already
  documented isl prefix, even though it doesn't follow the
  convention to use the NASDAQ symbol where available.
  
  The current users of the isil prefix are the following drivers
  and device trees, so we could just as well change those instead:
  arch/arm/boot/dts/tegra20-seaboard.dts
  arch/arm/boot/dts/tegra20-ventana.dts
  arch/arm/boot/dts/tegra30-cardhu.dtsi
  arch/powerpc/boot/dts/p1022rdk.dts
  drivers/staging/iio/light/isl29018.c
  drivers/staging/iio/light/isl29028.c
  
  regards
  Philipp
  
  Philipp Zabel (6):
of: Change vendor prefix for Intersil Corporation to isil
Documentation: Add isl1208 and isl12022 to trivial-devices list
ARM: mvebu: Change vendor prefix for Intersil Corporation to isil
powerpc/85xx: Change vendor prefix for Intersil Corporation to isil
rtc: rtc-isl12022: Change vendor prefix for Intersil Corporation to
  isil
rtc: rtc-isl12057: Change vendor prefix for Intersil Corporation to
  isil
  
   Documentation/devicetree/bindings/i2c/trivial-devices.txt | 4 +++-
   Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +-
   arch/arm/boot/dts/armada-370-netgear-rn102.dts| 2 +-
   arch/arm/boot/dts/armada-370-netgear-rn104.dts| 2 +-
   arch/arm/boot/dts/armada-xp-netgear-rn2120.dts| 2 +-
   arch/powerpc/boot/dts/ppa8548.dts | 2 +-
   drivers/rtc/rtc-isl12022.c| 3 ++-
   drivers/rtc/rtc-isl12057.c| 3 ++-
   8 files changed, 12 insertions(+), 8 deletions(-)
 
 This looks good overall.  My only nit is that I'd like to see the legacy
 name(s) captured in the binding docs.
 
 I'll take the Armada dts changes through mvebu/arm-soc after a few days.

Just to dot our i's and cross our t's, would you mind sending out a
non-rfc version of this series?

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/6] Change vendor prefix for Intersil Corporation

[Jason Cooper]

Philipp,

On Wed, Aug 20, 2014 at 10:42:58AM +0200, Philipp Zabel wrote:
 Hi,
 
 currently there is a wild mixture of isl, isil, and intersil
 compatibles in the kernel. I figure at this point it is still
 possible to change this to use isil everywhere without too
 much pain, but it might be preferred to keep the already
 documented isl prefix, even though it doesn't follow the
 convention to use the NASDAQ symbol where available.
 
 The current users of the isil prefix are the following drivers
 and device trees, so we could just as well change those instead:
   arch/arm/boot/dts/tegra20-seaboard.dts
   arch/arm/boot/dts/tegra20-ventana.dts
   arch/arm/boot/dts/tegra30-cardhu.dtsi
   arch/powerpc/boot/dts/p1022rdk.dts
   drivers/staging/iio/light/isl29018.c
   drivers/staging/iio/light/isl29028.c
 
 regards
 Philipp
 
 Philipp Zabel (6):
   of: Change vendor prefix for Intersil Corporation to isil
   Documentation: Add isl1208 and isl12022 to trivial-devices list
   ARM: mvebu: Change vendor prefix for Intersil Corporation to isil
   powerpc/85xx: Change vendor prefix for Intersil Corporation to isil
   rtc: rtc-isl12022: Change vendor prefix for Intersil Corporation to
 isil
   rtc: rtc-isl12057: Change vendor prefix for Intersil Corporation to
 isil
 
  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 4 +++-
  Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +-
  arch/arm/boot/dts/armada-370-netgear-rn102.dts| 2 +-
  arch/arm/boot/dts/armada-370-netgear-rn104.dts| 2 +-
  arch/arm/boot/dts/armada-xp-netgear-rn2120.dts| 2 +-
  arch/powerpc/boot/dts/ppa8548.dts | 2 +-
  drivers/rtc/rtc-isl12022.c| 3 ++-
  drivers/rtc/rtc-isl12057.c| 3 ++-
  8 files changed, 12 insertions(+), 8 deletions(-)

This looks good overall.  My only nit is that I'd like to see the legacy
name(s) captured in the binding docs.

I'll take the Armada dts changes through mvebu/arm-soc after a few days.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

[Jason Cooper]

On Tue, Nov 05, 2013 at 11:12:00PM +0100, Arnaud Ebalard wrote:
 Hi Jason,
 
 Jason Gunthorpe jguntho...@obsidianresearch.com writes:
 
  Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
  present' made the call to phy_scan optional, if the DT has a link to
  the phy node.
 
  However phy_scan has the side effect of calling phy_addr_set, which
  writes the phy MDIO address to the ethernet controller. If phy_addr_set
  is not called, and the bootloader has not set the correct address then
  the driver will fail to function.
 
 Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
 (Armada 370 based) which I had put on a todo list and temporarily

readynas duo v2?

thx,

Jason.

 workarounded by including a 'ping whatever' call in my u-boot env in
 order to force it to do the init. Without it, I was unable to properly
 use the interface. With your fix, after multiple reboots to test it,
 everything works as expected. So, FWIW: 
 
 Tested-by: Arnaud Ebalard a...@natisbad.org
 
 Cheers,
 
 a+
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

[Jason Cooper]

Jason,

On Mon, Nov 04, 2013 at 05:27:19PM -0700, Jason Gunthorpe wrote:
 Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node

fyi: set core.abbrev = 12 in your git config, according to Linus, 7/8
was a bad decision...

 present' made the call to phy_scan optional, if the DT has a link to
 the phy node.
 
 However phy_scan has the side effect of calling phy_addr_set, which
 writes the phy MDIO address to the ethernet controller. If phy_addr_set
 is not called, and the bootloader has not set the correct address then
 the driver will fail to function.
 
 Tested on Kirkwood.
 
 Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com

Fixes: cc9d459894b0 net: mv643xx_eth: use of_phy_connect if phy_node present
Acked-by: Jason Cooper ja...@lakedaemon.net

And it should be suitable for v3.11+

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option

[Jason Cooper]

On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
 Dear Bjorn Helgaas,
 
 On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
 
  Acked-by: Bjorn Helgaas bhelg...@google.com
  
  Again, please update the subject line to PCI: Remove ...
  
  I doubt that you'll get explicit acks from all the arches you touched,
  but I think it's reasonable to put at least patches 2  3 in -next
  soon after v3.11-rc1, so we should have time to shake out issues.
 
 Sure. Which merge strategy do you suggest for this patch series, which
 touches a number of different areas, and has some build-time
 dependencies between the patches (if needed, I can detail those build
 time dependencies to help figuring out the best strategy).

If we end up handling this the same as the of/pci  mvebu-pcie series
(whole series through mvebu - arm-soc) I can have it up in -next within
a few days of -rc1.  Just let me know.

hth,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option

[Jason Cooper]

On Sat, Jul 06, 2013 at 09:40:55AM -0600, Bjorn Helgaas wrote:
 On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper ja...@lakedaemon.net wrote:
  On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
  Dear Bjorn Helgaas,
 
  On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
 
   Acked-by: Bjorn Helgaas bhelg...@google.com
  
   Again, please update the subject line to PCI: Remove ...
  
   I doubt that you'll get explicit acks from all the arches you touched,
   but I think it's reasonable to put at least patches 2  3 in -next
   soon after v3.11-rc1, so we should have time to shake out issues.
 
  Sure. Which merge strategy do you suggest for this patch series, which
  touches a number of different areas, and has some build-time
  dependencies between the patches (if needed, I can detail those build
  time dependencies to help figuring out the best strategy).
 
  If we end up handling this the same as the of/pci  mvebu-pcie series
  (whole series through mvebu - arm-soc) I can have it up in -next within
  a few days of -rc1.  Just let me know.
 
 That sounds fine with me.  I don't think it's worth trying to split
 out the drivers/pci stuff and trying to coordinate it going through
 different trees.

Ok, will do.

Thomas, I assume there will be one more version to address Bjorn's last
comments?

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files

[Jason Cooper]

Arnaud,

On Fri, May 31, 2013 at 12:28:56AM +0200, Arnaud Ebalard wrote:
 Hi,
 
 Jason Cooper ja...@lakedaemon.net writes:
 
  For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
  PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
  the PCIE init routine in board-readynas.c, and yours remove ge00
  init. With both applied, the whole file can go away.
  
  AFAICT, this may be the case soon for:
  
   arch/arm/mach-kirkwood/board-iconnect.c   (36e5722089)
   arch/arm/mach-kirkwood/board-mplcec4.c(9470fbfb8d)
   arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2)
   arch/arm/mach-kirkwood/board-readynas.c   (6bd98481ab)
   arch/arm/mach-kirkwood/board-ts219.c  (259e234608)
 
  Would you mind putting a patch together (for after v3.10 drops) to do
  this?  If you applied Sebastian's series on top of mvebu/pcie_kirkwood,
  that should get you almost there.  The last half of his series is going
  in after v3.10...
 
 Something like the quick quilt-generated patch at the end of this email
 (done after a dummy merge of Sebastian's set in mvebu/pcie_kirkwood)? 

yep.

 I will take a look at what remains after Sebastian's set hit one of
 your branch but I guess he will have included most of what is in the
 patch to help you with the merge.
 
 Anyway, at the end here is what DT board files would remain:
 
 $ ls -1 arch/arm/mach-kirkwood/board-*.c
 arch/arm/mach-kirkwood/board-dnskw.c

This one seems to just be setting a gpio to enable reboot after power
failure.  Should be simple to move to DT.

 arch/arm/mach-kirkwood/board-dt.c

We obviously need this one. ;-)

 arch/arm/mach-kirkwood/board-lsxl.c

This is taken care of in mvebu/boards

  391a16c ARM: Kirkwood: Convert LSXL to restart-poweroff driver.

 arch/arm/mach-kirkwood/board-ts219.c

Also in mvebu/boards

  4350a47 ARM: Kirkwood: Make use of the QNAP Power off driver.

 Just one question though: the removal of MACH_*_DT in Kconfig removes
 the automatic selection of useful board specific options like
 ARM_APPENDED_DTB, ARM_ATAG_DTB_COMPAT, POWER_RESET_RESTART,
 POWER_RESET_QNAP. Is that expected?

I would select POWER_RESET_QNAP and POWER_RESET_RESTART in Kconfig for
ARCH_KIRKWOOD_DT, and put ARM_APPENDED_DTB and ARM_ATAG_DTB_COMPAT into
the defconfig.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files

[Jason Cooper]

On Thu, May 30, 2013 at 11:06:08AM +0200, Arnaud Ebalard wrote:
 Hi Jason and Sebastian,
 
 Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:
 
  With DT support for mv643xx_eth board specific init for some boards now
  is unneccessary. Remove those board files, Kconfig entries, and
  corresponding entries in kirkwood_defconfig.
 
  Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
  ---
  Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
  the lock-up is not caused by accessing clock gating registers but rather
  non-existent device registers. This will be addressed by dtsi separation
  for kirkwood and bobcat SoC variants.
 
  Changelog:
  v3-v4:
  - remove more boards that don't require board specific setup
 
  Cc: David Miller da...@davemloft.net
  Cc: Lennert Buytenhek buyt...@wantstofly.org
  Cc: Jason Cooper ja...@lakedaemon.net
  Cc: Andrew Lunn and...@lunn.ch
  Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
  Cc: net...@vger.kernel.org
  Cc: linux-arm-ker...@lists.infradead.org
  Cc: linuxppc-dev@lists.ozlabs.org
  Cc: linux-ker...@vger.kernel.org
  ---
   arch/arm/configs/kirkwood_defconfig   |   16 
   arch/arm/mach-kirkwood/Kconfig|  117 
  -
   arch/arm/mach-kirkwood/Makefile   |   16 
   arch/arm/mach-kirkwood/board-dnskw.c  |7 --
   arch/arm/mach-kirkwood/board-dockstar.c   |   32 ---
   arch/arm/mach-kirkwood/board-dreamplug.c  |   35 
   arch/arm/mach-kirkwood/board-dt.c |   62 +
   arch/arm/mach-kirkwood/board-goflexnet.c  |   34 ---
   arch/arm/mach-kirkwood/board-guruplug.c   |   33 ---
   arch/arm/mach-kirkwood/board-ib62x0.c |   29 --
   arch/arm/mach-kirkwood/board-iconnect.c   |   10 ---
   arch/arm/mach-kirkwood/board-iomega_ix2_200.c |   34 ---
   arch/arm/mach-kirkwood/board-km_kirkwood.c|   44 --
   arch/arm/mach-kirkwood/board-lsxl.c   |   16 
   arch/arm/mach-kirkwood/board-mplcec4.c|   14 ---
   arch/arm/mach-kirkwood/board-ns2.c|   35 
   arch/arm/mach-kirkwood/board-openblocks_a6.c  |   26 --
   arch/arm/mach-kirkwood/board-readynas.c   |6 --
 
 Just a stupid note: With Thomas ongoing work to get mvebu-pcie driver in
 place and enabled for kirkwood, some boards setup files will also lose
 their pcie init routines, which may allow you to kill those additonal
 files soon.

Yes, we're very excited about this ;-)

 For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
 PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
 the PCIE init routine in board-readynas.c, and yours remove ge00
 init. With both applied, the whole file can go away.
 
 AFAICT, this may be the case soon for:
 
  arch/arm/mach-kirkwood/board-iconnect.c   (36e5722089)
  arch/arm/mach-kirkwood/board-mplcec4.c(9470fbfb8d)
  arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2)
  arch/arm/mach-kirkwood/board-readynas.c   (6bd98481ab)
  arch/arm/mach-kirkwood/board-ts219.c  (259e234608)

Would you mind putting a patch together (for after v3.10 drops) to do
this?  If you applied Sebastian's series on top of mvebu/pcie_kirkwood,
that should get you almost there.  The last half of his series is going
in after v3.10...

You may want to try merging in mvebu/boards and mvebu/soc.  Those have
the changes to use dt for the restart and power-off drivers.  That'll
allow us to empty out a few more board files.  mvebu/dt also has a patch
from Valentin allowing us to remove the keymile board as well.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5 01/13] net: mv643xx_eth: use phy_disconnect instead of phy_detach

[Jason Cooper]

Sebastian,

On Wed, May 29, 2013 at 09:32:43PM +0200, Sebastian Hesselbarth wrote:
 Using a separated mdio bus driver with mvmdio, phy_detach on network device
 removal will not stop the phy and finally lead to NULL pointer dereference
 in mvmdio due to non-existent network device. Use phy_disconnect instead
 to properly stop phy device from accessing network device prior removal of
 the network device.
 
 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 ---
 Note: I observed this behavior when removing a modular mv643xx_eth driver
 after attaching it to a phy handled by (also modular) mvmdio. The mvmdio
 conversion has been done in
 
 commit c3a07134e6aa5b93a37f72ffa3d11fadf72bf757
  (mv643xx_eth: convert to use the Marvell Orion MDIO driver)
 
 and should go back any -stable version with that commit (propably only 3.9)

It looks like just v3.10-rcX, here.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

Jason,

Sorry, I meant to get back to this earlier and it slipped off of my
plate. :(

On Fri, May 24, 2013 at 11:33:06AM -0600, Jason Gunthorpe wrote:
 On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote:
 
   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?
 
 I disagree. The manul is very clear how PSC1 must be set for proper
 operation. Clk125BypassEn bit is used only for loopback testing, it
 should never set for driver operation. Similarly PortReset must be
 cleared for driver operation.
 
 It is always safe for the driver to clear these bits, if it knows they
 are available.  In fact, I would argue the driver should always clear
 these bits so that the bootloader isn't relied on to do it. It doesn't
 matter if the SOC errantly sets the bit or not, it can *always* be
 safely cleared.

Great!

 Further, I compared my 88F6282/88F6283 manual against the public
 88F6180/88F619x/88F6281 spec and confirmed that the PSC1 layout is the
 same.

Even better.

 So all of these SOC's can share a driver compatible string.

Ok, marvell,kirkwood-eth works for me then.  I think Sebastian already
has patches for that.

 AFAICT the only reason the driver doesn't touch PSC1 today is because
 the PSC1 was introduced in a later IP revision and its presence isn't
 auto-detectable.

Makes sense.

 The last bit of the puzzle to get bootloader independence on kirkwood
 is to encode the phy interface type (GMII/RGMII/BASE-X) in the DT so
 the entire PSC1 can be set by the driver..

Hmm, let's work on that separately, and later.  I've snowballed this
attempt enough ;-)

Thanks for digging into this for us,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Thu, May 23, 2013 at 01:01:40PM -0600, Jason Gunthorpe wrote:
 On Thu, May 23, 2013 at 02:40:28PM -0400, Jason Cooper wrote:
 
   But there is a larger problem here then just this one bit.
   
   The PSC1 register must be set properly for the board layout, and today
   we rely on the bootloader to set it. In fact, even with Sebastian's
   change the ethernet port won't work without bootloader
   intervention. The PortReset bit should also be cleared by the driver
   (and it is only present on some variants of this IP block,
   apparently).
   
   We know that some Marvell SOC's wack the ethernet registers when they
   clock gate, and the flip of Clk125Bypass is another symptom of this
   general problem.
   
   So, long term, the PSC1 must be fully set by the driver, based on DT
   information describing the board (eg RGMII/MII/1000Base-X [SFP] Phy
   type), and the layout of this register seems to vary on a SOC by SOC
   basis.
   
   Thus, I think it is appropriate to call this variant of the eth IP
   'marvell,kirkwood-eth' which indicates that the register block follows
   the kirkwood manual and the PSC1 register specifically has the
   kirkwood layout.
  
  Ok, so mv643xx_eth would match both marvell,orion-eth and
  marvell,kirkwood-eth, then write to PSC1 iff it sees a node matching
  marvell,kirkwood-eth.  I'm not too keen on that, however, the matching
  of the machine doesn't look to good, either.
 
 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?

That being said, if marvell,kirkwood-eth is the best we can do for
now, I'm all for it.  I would just like to be reasonably certain that
the binding we are creating doesn't lock us into a difficult decision
later.

 There are more compatible strings than just kirkwood and orion in this
 driver, the whole TX_BW_CONTROL_OLD_LAYOUT/TX_BW_CONTROL_NEW_LAYOUT
 buisness (affecting PPC/MIPS) should also someday be captured with
 compatible strings rather than auto-detection too..

Agreed.

   The question is what other Marvell SOCs have the same PSC1 layout as
   kirkwood?
  
  I think marvell,psc1_reset = ; gives us the most flexibility in
  accurately describing the hardware.
 
 Agree, providing psc1_reset value is a good idea to setup the phy
 modes. If all 'orion' SOCs have the PSC1 value then we don't need the
 kirkwood differentiators, especially if things like the reset bit are
 in the same place.
 
 The same trick Sebastian used to capture the mac address could be used
 to capture the PSC1 value from the bootloader.
 
 Basically, I think any IP variants that have idential register layouts
 can share a compatible string, otherwise different layouts need
 different compatible strings, so the general format:
 
  compatible = marvell,SOCNAME-eth, marvell,something-eth;
 
 Seems very sane to me. At least this way if we discover more changes
 then the driver can match on the SOCNAME compatible string to find
 them.

After glancing a LinusW's email, I'm thinking this isn't the correct
path.  I'll write more in my response to him.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Fri, May 24, 2013 at 12:40:26AM +0200, Sebastian Hesselbarth wrote:
 On 05/23/2013 08:40 PM, Jason Cooper wrote:
 On Thu, May 23, 2013 at 11:53:57AM -0600, Jason Gunthorpe wrote:
 On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
 Shouldn't it rather be
 
compatible = marvell,kirkwood-eth, marvell,orion-eth;
 
 Not sure about orion-eth?

Sorry, yep, one or the other.

 Jason, Jason,

For a second, I read this as tsk tsk tsk... ;-)

 sorry I didn't came back to this conversation earlier. I already
 reworked the patch to rely on
 of_device_is_compatible(..marvell,kirkwood-eth..). This is a
 kirkwood only thing as other Orions cannot do clock gating or
 retain critcal register content (Dove). I will stick with orion-eth
 for all other and maybe introduce new compatible strings (and new
 fixes) as soon as issues surface.

Okay, as I mentioned to Jason, I would like to test 6282 before we
settle on this path.  Other than that, I'm fine with it.

 I'm inclined to go with of_machine_is_compatible() since the only
 concrete difference we know is that the tweak is needed on kirkwood and
 nowhere else.
 
 But there is a larger problem here then just this one bit.
 
 The PSC1 register must be set properly for the board layout, and today
 we rely on the bootloader to set it. In fact, even with Sebastian's
 change the ethernet port won't work without bootloader
 intervention. The PortReset bit should also be cleared by the driver
 (and it is only present on some variants of this IP block,
 apparently).
 
 Actually, fixing modular scenarios is only for the sake of multiarch
 someday. I don't see the point in running current kernel without eth
 compiled in _on a NAS SoC_ ;)

Good point, but if the eth can be gated to save power, we shouldn't
limit the user's ability just because the SoC is primarily in NAS's.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote:
 On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth
 sebastian.hesselba...@gmail.com wrote:
  On 05/23/2013 08:40 PM, Jason Cooper wrote:
 
  I think marvell,psc1_reset =; gives us the most flexibility in
  accurately describing the hardware.
 
 
  IMHO using that is just another workaround for a broken driver. We
  could hack the whole register setup in DT as it would still accurately
  describe HW. Don't get me wrong, but I don't like it.
 
  Haven't checked how happy Linus Walleij is about pinctrl drivers with
  reg values hacked in lately.
 
 One of the things I've been ranting about lately is that Linux
 subsystem maintainers have become de-facto device tree
 standard commite chairs. :-(

This is the first I've heard this rant.  :(

To that end, I agree with you.  My frustration boiled down to trying to
predict the future, which is futile. :-P

For our scenario, once we can confirm our least popular kirkwood
variant, the 6282, behaves the same as we've seen so far, then
marvell,kirkwood-eth is fine by me.

 So to the actual question:
 
 In general I think we need to draw a line and define what we
 mean with describing the hardware in a device tree.
 
 We have some consensus:
 - reg properties to describe regsiter BASE offset in physical
   memory and size.
 - Resources like IRQ, DMA channel, regulator, GPIO pin control
   handles, are passed using ampersand notation.
 
 And so it goes on.
 
 When it comes to defining different registers and their individual
 bits and the meaning of these and/or default values, I personally
 think that is making things harder for developers rather than
 simplifying things. I know that pinctrl-single is anyway doing this
 and I was talked into accepting it under circumstances where
 developers are being passed opaque machine-generated
 data that would otherwise be translated into unreadable header
 files littering the kernel.
 
 For a coder it is definately better if the *driver* know these
 details, but whether that is possible seems to depend on things
 like hardware development process.

Agree.

 IMO: if you want to go down that road, what you really want is not
 ever more expressible device trees, but real open firmware,
 or ACPI or UEFI that can interpret and run bytecode as some
 bios for you. With DT coming from OF maybe this is a natural
 progression of things, but one has to realize when we reach the
 point where what we really want is a bios. Then your time is
 likely better spent with Tianocore or something than with the
 kernel.

shudder.  I like embedded systems because the *don't* have a bios.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Fri, May 24, 2013 at 06:53:15PM +0200, Andrew Lunn wrote:
   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.

Do you have a board set up for testing you could try Sebastian's
forthcoming series on (with marvell,kirkwood-eth)?

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

Sebastian,

On Wed, May 22, 2013 at 02:16:07PM -0600, Jason Gunthorpe wrote:
 On Wed, May 22, 2013 at 10:04:02PM +0200, Sebastian Hesselbarth wrote:
 
  Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
  MAC address register contents on clock gating but also some important
  registers are reset to values that would break ethernet. This patch
 
 FWIW, we found that the bootloader has to write to PSC1, the driver
 doesn't work with the power on/reset value of the register. So I think
 it is safe to assume that all kirkwood bootloaders alter the value.
 
 Our systems write the value 0x00638488 to PSC1.
 
 I looked at patching mv643xx_eth, but ran into the same complexity you
 did, it isn't clear what variants of this IP block have the
 register/etc.
 
  +   /* Kirkwood resets some registers on gated clocks. Especially
  +* CLK125_BYPASS_EN must be cleared but is not available on
  +* all other SoCs/System Controllers using this driver.
  +*/
  +   if (of_machine_is_compatible(marvell,kirkwood))
  +   wrlp(mp, PORT_SERIAL_CONTROL1,
  +rdlp(mp, PORT_SERIAL_CONTROL1)  ~CLK125_BYPASS_EN);
 
 of_machine_is_compatible seems heavy handed, I would expect this to be
 based on the compatible string of the ethernet node itself, not the
 machine??

Is there a model number variation between IP that needs this and IP that
doesn't?  If not, I'm fine with of_machine_is_compatible().

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Thu, May 23, 2013 at 11:11:12AM -0600, Jason Gunthorpe wrote:
 On Thu, May 23, 2013 at 12:01:11PM -0400, Jason Cooper wrote:
+   /* Kirkwood resets some registers on gated clocks. Especially
+* CLK125_BYPASS_EN must be cleared but is not available on
+* all other SoCs/System Controllers using this driver.
+*/
+   if (of_machine_is_compatible(marvell,kirkwood))
+   wrlp(mp, PORT_SERIAL_CONTROL1,
+rdlp(mp, PORT_SERIAL_CONTROL1)  
~CLK125_BYPASS_EN);
   
   of_machine_is_compatible seems heavy handed, I would expect this to be
   based on the compatible string of the ethernet node itself, not the
   machine??
  
  Is there a model number variation between IP that needs this and IP that
  doesn't?  If not, I'm fine with of_machine_is_compatible().
 
 Well the name 'mv643xx' is a family of system controller SOC's
 from ages ago, it seems reasonble to continue the trend and label the
 IP variations with the SOC name:
 
  compatible = marvell,kirwood,ethernet, marvell,mv643xx_eth

Shouldn't it rather be

compatible = marvell,kirkwood-eth, marvell,orion-eth;

I'm inclined to go with of_machine_is_compatible() since the only
concrete difference we know is that the tweak is needed on kirkwood and
nowhere else.

If we had an errata, or a datasheet saying specifically flavor X needs
this and none other does, then we could trigger on the ethernet node
compatible string or a boolean in the node.  But we don't have that...

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Thu, May 23, 2013 at 11:53:57AM -0600, Jason Gunthorpe wrote:
 On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
 
  Shouldn't it rather be
  
  compatible = marvell,kirkwood-eth, marvell,orion-eth;
 
 Not sure about orion-eth?
  
  I'm inclined to go with of_machine_is_compatible() since the only
  concrete difference we know is that the tweak is needed on kirkwood and
  nowhere else.
 
 But there is a larger problem here then just this one bit.
 
 The PSC1 register must be set properly for the board layout, and today
 we rely on the bootloader to set it. In fact, even with Sebastian's
 change the ethernet port won't work without bootloader
 intervention. The PortReset bit should also be cleared by the driver
 (and it is only present on some variants of this IP block,
 apparently).
 
 We know that some Marvell SOC's wack the ethernet registers when they
 clock gate, and the flip of Clk125Bypass is another symptom of this
 general problem.
 
 So, long term, the PSC1 must be fully set by the driver, based on DT
 information describing the board (eg RGMII/MII/1000Base-X [SFP] Phy
 type), and the layout of this register seems to vary on a SOC by SOC
 basis.
 
 Thus, I think it is appropriate to call this variant of the eth IP
 'marvell,kirkwood-eth' which indicates that the register block follows
 the kirkwood manual and the PSC1 register specifically has the
 kirkwood layout.

Ok, so mv643xx_eth would match both marvell,orion-eth and
marvell,kirkwood-eth, then write to PSC1 iff it sees a node matching
marvell,kirkwood-eth.  I'm not too keen on that, however, the matching
of the machine doesn't look to good, either.

Perhaps a better answer is to add a boolean, marvell,kirkwood_psc1 and
check for that?

Or, marvell,psc1_reset = 0xWWXXYYZZ;

 The question is what other Marvell SOCs have the same PSC1 layout as
 kirkwood?

I think marvell,psc1_reset = ; gives us the most flexibility in
accurately describing the hardware.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Wed, May 22, 2013 at 12:13:58PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 12:04 PM, tiejun.chen wrote:
 On 05/22/2013 05:43 PM, Sebastian Hesselbarth wrote:
 On 05/21/2013 07:48 PM, Andrew Lunn wrote:
 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 Hesselbarthsebastian.hesselba...@gmail.com
 ---
 ...
 + 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,
 
 we just need an invalid address here to trigger the default behavior of
 the driver and load the MAC address from its register. As PPC binding
 documentation also has all zero, I just took it.
 
 The truth is in PPC case, often we set the real mac address with some
 variables like 'eth[x]addr' in u-boot prompt, then u-boot will parse
 that value to fill the dtb. At last the associated driver can get the
 actual mac address from the dtb. And especially for those older u-boot
 version, even you have to reset the 'local-mac-address' property in dts
 directly with the real mac address before generate the dtb since the
 older u-boot have no this ability to fill dtb again before pass the kernel.
 
 Tiejun,
 
 with Marvell SoCs it is no different, except that there is almost no dtb
 support in their u-boot.

iirc, our solution to this was to parse the ATAGs for the mac addr and
update the appended dtb.  This way, module load and unload would work
without loosing the mac address.  I believe Jason Gunthorpe has a patch
to atags_to_fdt() for this...  This should allow us to get rid of the
clocks hack.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Wed, May 22, 2013 at 10:59:08AM -0600, Jason Gunthorpe wrote:
 On Wed, May 22, 2013 at 09:10:10AM -0400, Jason Cooper wrote:
 
  iirc, our solution to this was to parse the ATAGs for the mac addr and
  update the appended dtb.  This way, module load and unload would work
  without loosing the mac address.  I believe Jason Gunthorpe has a patch
  to atags_to_fdt() for this...  This should allow us to get rid of the
  clocks hack.
 
 Sorry, no, we don't use ATAGs here, our platforms start the kernel
 with a correct DTB that has the correct mac address to use. My patch
 was to have the driver accept it, and I think Sebastian has already
 got that functionality...

Yes, you're right.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 06:59 PM, Jason Gunthorpe wrote:
 On Wed, May 22, 2013 at 09:10:10AM -0400, Jason Cooper wrote:
 iirc, our solution to this was to parse the ATAGs for the mac addr and
 update the appended dtb.  This way, module load and unload would work
 without loosing the mac address.  I believe Jason Gunthorpe has a patch
 to atags_to_fdt() for this...  This should allow us to get rid of the
 clocks hack.
 
 Sorry, no, we don't use ATAGs here, our platforms start the kernel
 with a correct DTB that has the correct mac address to use. My patch
 was to have the driver accept it, and I think Sebastian has already
 got that functionality...
 
 Not neccessary anyway, after talking Jason C in a Kirkwood-only
 workaround I prepared a patch that reads mac address registers early
 and stores it in the local-mac-address property.

Sweet!

 Just tested on Dockstar with gated clocks and modular DT mv643xx_eth.
 
 Will append to the DT mv643xx_eth patch set if a v5 will be required
 or as single patch prior Jason C taking in the ARM part of it
 otherwise.

Please post, in-reply-to v4 is fine.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 07:35 PM, Jason Cooper wrote:
 On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 06:59 PM, Jason Gunthorpe wrote:
 On Wed, May 22, 2013 at 09:10:10AM -0400, Jason Cooper wrote:
 iirc, our solution to this was to parse the ATAGs for the mac addr and
 update the appended dtb.  This way, module load and unload would work
 without loosing the mac address.  I believe Jason Gunthorpe has a patch
 to atags_to_fdt() for this...  This should allow us to get rid of the
 clocks hack.
 
 Sorry, no, we don't use ATAGs here, our platforms start the kernel
 with a correct DTB that has the correct mac address to use. My patch
 was to have the driver accept it, and I think Sebastian has already
 got that functionality...
 
 Not neccessary anyway, after talking Jason C in a Kirkwood-only
 workaround I prepared a patch that reads mac address registers early
 and stores it in the local-mac-address property.
 
 Sweet!
 
 Just tested on Dockstar with gated clocks and modular DT mv643xx_eth.
 
 Will append to the DT mv643xx_eth patch set if a v5 will be required
 or as single patch prior Jason C taking in the ARM part of it
 otherwise.
 
 Please post, in-reply-to v4 is fine.
 
 Hmm, maybe a little bit too early. While restoring the MAC address now
 works, another bug arises which I guess is related with phy setup
 and aneg.
 
 Will investigate and update patch set accordingly.

Cool, chances are, we should be able to take that patch in by itself for
this merge window...

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Wed, May 22, 2013 at 08:44:20PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 07:48 PM, Jason Cooper wrote:
 On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
 Hmm, maybe a little bit too early. While restoring the MAC address now
 works, another bug arises which I guess is related with phy setup
 and aneg.
 
 Will investigate and update patch set accordingly.
 
 Cool, chances are, we should be able to take that patch in by itself for
 this merge window...
 
 Which patch do you mean? The local-mac-address workaround will only be
 available for DT mv643xx_eth because it uses the DT node to store the
 MAC.

I thought you were replacing the unconditional ethernet clock grabbing
with reading the mac from the registers and updating the dtb?  In
mach-kirkwood/board-dt.c?

confused. :-/

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Jason Cooper]

On Wed, May 22, 2013 at 08:55:01PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 08:49 PM, Jason Cooper wrote:
 On Wed, May 22, 2013 at 08:44:20PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 07:48 PM, Jason Cooper wrote:
 On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
 Hmm, maybe a little bit too early. While restoring the MAC address now
 works, another bug arises which I guess is related with phy setup
 and aneg.
 
 Will investigate and update patch set accordingly.
 
 Cool, chances are, we should be able to take that patch in by itself for
 this merge window...
 
 Which patch do you mean? The local-mac-address workaround will only be
 available for DT mv643xx_eth because it uses the DT node to store the
 MAC.
 
 I thought you were replacing the unconditional ethernet clock grabbing
 with reading the mac from the registers and updating the dtb?  In
 mach-kirkwood/board-dt.c?
 
 True. But there is no node for ethernet controllers in kirkwood.dtsi
 yet. It will be there with mv643xx_eth DT patches applied and that is
 when the corresponding replacement patch should also be taken in.
 
 I was just confused about your referral to the merge window, because I
 guess it is up to David Miller to decide when/whether to take
 mv643xx_eth patches in.

Ahh, no, that was me.  I was contemplating adding the dt entries in this
merge window at one point and must've got my wires crossed.  Sorry for
the confusion.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files

[Jason Cooper]

On Wed, May 22, 2013 at 10:55:43PM +0200, Sebastian Hesselbarth wrote:
 On 05/22/2013 10:36 PM, Simon Baatz wrote:
 Hi Sebastian,
 
 On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote:
 With DT support for mv643xx_eth, board specific init for some boards now
 is unneccessary. Remove those board files, Kconfig entries, and
 corresponding entries in kirkwood_defconfig.
 
 Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
 ---
 Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
 the lock-up is not caused by accessing clock gating registers but rather
 non-existent device registers. This will be addressed by dtsi separation
 for kirkwood and bobcat SoC variants.
 
 Changelog:
 v3-v4:
 - remove more boards that don't require board specific setup
 
 ...
 We still have:
 
 static const char * const kirkwood_dt_board_compat[] = {
  globalscale,dreamplug,
  globalscale,guruplug,
  dlink,dns-320,
  dlink,dns-325,
  iom,iconnect,
  raidsonic,ib-nas62x0,
  qnap,ts219,
  seagate,dockstar,
  seagate,goflexnet,
  buffalo,lsxl,
  iom,ix2-200,
  keymile,km_kirkwood,
  lacie,cloudbox,
  lacie,inetspace_v2,
  lacie,netspace_lite_v2,
  lacie,netspace_max_v2,
  lacie,netspace_mini_v2,
  lacie,netspace_v2,
  mpl,cec4,
  netgear,readynas-duo-v2,
  plathome,openblocks-a6,
  usi,topkick,
  zyxel,nsa310,
  NULL
 };
 
 in that file. I think it does not make sense that we need to list
 boards here that can be described fully by DT. When adding such a
 board in the future, you will still need to adapt board-dt.c.
 
 True, will remove the redundant compatible strings for v5.
 Actually, if I am not missing something, all compatible strings except
 marvell,kirkwood are redundant as long as board.dts append it
 correctly.
 
 Should we remove the boards that you removed above here as well and
 add
 
  marvell,kirkwood-88f6192,
  marvell,kirkwood-88f6281,
  marvell,kirkwood-88f6282,
  marvell,kirkwood-88f6283,
  marvell,kirkwood-88f6702,
  marvell,kirkwood-98DX4122,
 
 or even just state marvell,kirkwood?
 
 I would stick with marvell,kirkwood only. This is SoC init code and
 we do not distinguish variants here at all.

Agreed, nice catch Simon.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing

[Jason Cooper]

On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote:
 This patchset factors out duplicated code associated with parsing PCI
 DT ranges properties across the architectures and introduces a
 ranges parser. This parser of_pci_range_parser can be used directly
 by ARM host bridge drivers enabling them to obtain ranges from device
 trees.
 
 I've included the Reviewed-by, Tested-by and Acked-by's received from v5/v6/v7
 in this patchset, earlier versions of this patchset (v3) have been tested-by:
 
 Thierry Reding thierry.red...@avionic-design.de
 Jingoo Han jg1@samsung.com
 
 I've tested that this patchset builds and runs on ARM and that it builds on
 PowerPC, x86_64 and MIPS.

Andrew,

Unfortunately, the mvebu/drivers branch containing your series had to be
dropped from arm-soc for v3.10.  This was not due to your series, but
since arm-soc's granularity is branches, your series was caught in the
drop.

As the mvebu-pcie driver is now v3.11 material, I have taken the
opportunity to upgrade from your v7 patchset to v8.  You can find the
whole branch at mvebu-next/pcie.

mvebu-next/pcie *will* be rebased onto v3.9 once it drops.  Several
dependencies will be removed (since they will have been merged into
v3.9).

Once the rebase is done, I'll send a pull request to Arnd and Olof so we
can get as many cycles on -next as possible.

thx,

Jason.

 
 Compared to the v7 sent by Andrew Murray, the following changes have been made
 (please note that the first patch is unchanged from v7):
 
  * Rename of_pci_range_parser to of_pci_range_parser_init and
of_pci_process_ranges to of_pci_range_parser_one as suggested by Grant
Likely.
 
  * Reverted back to using a switch statement instead of if/else in
pci_process_bridge_OF_ranges. Grant Likely highlighted this change from
the original code which was unnecessary.
 
  * Squashed in a patch provided by Gabor Juhos which fixes build errors on
MIPS found in the last patchset.
 
 Compared to the v6 sent by Andrew Murray, the following changes have
 been made in response to build errors/warnings:
 
  * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
Simek to prevent compilation failures on Microblaze (and others) and his
ack.
 
  * Use of externs, static inlines and a typo in linux/of_address.h in response
to linker errors (multiple defination) on x86_64 as spotted by a kbuild 
 test
robot on (jcooper/linux.git mvebu/drivers)
 
  * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
with of_pci_process_ranges function
 
 Compared to the v5 sent by Andrew Murray, the following changes have
 been made:
 
  * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by
Rob Herring in drivers/of/of_pci.c
 
  * Added forward declaration of struct pci_controller in linux/of_pci.h
to prevent compiler warning as suggested by Thomas Petazzoni
 
  * Improved error checking (!range check), removal of unnecessary be32_to_cpup
call, improved formatting of struct of_pci_range_parser layout and
replacement of macro with a static inline. All suggested by Rob Herring.
 
 Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray,
 the following changes have been made:
 
  * Split the patch as suggested by Rob Herring
 
 Compared to the v3 sent by Andrew Murray, the following changes have
 been made:
 
  * Unify and move duplicate pci_process_bridge_OF_ranges functions to
drivers/of/of_pci.c as suggested by Rob Herring
 
  * Fix potential build errors with Microblaze/MIPS
 
 Compared to [PATCH v5 01/17] of/pci: Provide support for parsing PCI DT
 ranges property, the following changes have been made:
 
  * Correct use of IORESOURCE_* as suggested by Russell King
 
  * Improved interface and naming as suggested by Thierry Reding
 
 Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did:
 
  * Add a memset() on the struct of_pci_range_iter when starting the
for loop in for_each_pci_range(). Otherwise, with an uninitialized
of_pci_range_iter, of_pci_process_ranges() may crash.
 
  * Add parenthesis around 'res', 'np' and 'iter' in the
for_each_of_pci_range macro definitions. Otherwise, passing
something like foobar as 'res' didn't work.
 
  * Rebased on top of 3.9-rc2, which required fixing a few conflicts in
the Microblaze code.
 
 v2:
   This follows on from suggestions made by Grant Likely
   (marc.info/?l=linux-kernelm=136079602806328)
 
 Andrew Murray (3):
   of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and
 PowerPC
   of/pci: Provide support for parsing PCI DT ranges property
   of/pci: mips: convert to common of_pci_range_parser
 
  arch/microblaze/include/asm/pci-bridge.h |5 +-
  arch/microblaze/pci/pci-common.c |  192 
 --
  arch/mips/pci/pci.c  |   51 +++-
  arch/powerpc/include/asm/pci-bridge.h|5 +-
  arch/powerpc/kernel/pci-common.c |  192 
 

Re: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing

[Jason Cooper]

On Mon, Apr 22, 2013 at 12:53:43PM -0400, Jason Cooper wrote:
 On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote:
  This patchset factors out duplicated code associated with parsing PCI
  DT ranges properties across the architectures and introduces a
  ranges parser. This parser of_pci_range_parser can be used directly
  by ARM host bridge drivers enabling them to obtain ranges from device
  trees.
  
  I've included the Reviewed-by, Tested-by and Acked-by's received from 
  v5/v6/v7
  in this patchset, earlier versions of this patchset (v3) have been 
  tested-by:
  
  Thierry Reding thierry.red...@avionic-design.de
  Jingoo Han jg1@samsung.com
  
  I've tested that this patchset builds and runs on ARM and that it builds on
  PowerPC, x86_64 and MIPS.
 
 Andrew,
 
 Unfortunately, the mvebu/drivers branch containing your series had to be
 dropped from arm-soc for v3.10.  This was not due to your series, but
 since arm-soc's granularity is branches, your series was caught in the
 drop.
 
 As the mvebu-pcie driver is now v3.11 material, I have taken the
 opportunity to upgrade from your v7 patchset to v8.  You can find the
 whole branch at mvebu-next/pcie.
 
 mvebu-next/pcie *will* be rebased onto v3.9 once it drops.  Several
 dependencies will be removed (since they will have been merged into
 v3.9).

s/v3.9/v3.10-rc1/g  :)

 Once the rebase is done, I'll send a pull request to Arnd and Olof so we
 can get as many cycles on -next as possible.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser

[Jason Cooper]

On Fri, Apr 19, 2013 at 09:19:50AM +0200, Gabor Juhos wrote:
 2013.04.18. 15:09 keltezéssel, Jason Cooper írta:
  On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote:
  On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote:
  On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray andrew.mur...@arm.com 
  wrote:
 
  This patch converts the pci_load_of_ranges function to use the new common
  of_pci_range_parser.
 
  Signed-off-by: Andrew Murray andrew.mur...@arm.com
  Signed-off-by: Liviu Dudau liviu.du...@arm.com
  Reviewed-by: Rob Herring rob.herr...@calxeda.com
 
  Tested-by: Linus Walleij linus.wall...@linaro.org
 
  Jason - you may not have seen this, but here (Linus Walleij) is another 
  Tested-by
  to add to this patch in your tree (if you can).
  
  Thanks, I saw it.  Unfortunately, the PR was already sent, and the branch
  is now pulled into arm-soc.
 
 Sorry I had no time earlier, but I have tested this now on MIPS. The patch
 causes build errors unfortunately. Given the fact that this has been merged
 already, I will send a fixup patch.

Olof has dropped this branch from arm-soc, plase post the build error
and fix here so that it can be included in this series.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

[Jason Cooper]

On Thu, Apr 18, 2013 at 01:48:32PM +0100, Grant Likely wrote:
 On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper ja...@lakedaemon.net wrote:
  On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote:
   On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper ja...@lakedaemon.net 
   wrote:
On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray 
andrew.mur...@arm.com wrote:
 On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
  The pci_process_bridge_OF_ranges function, used to parse the 
  ranges
  property of a PCI host device, is found in both Microblaze and 
  PowerPC
  architectures. These implementations are nearly identical. This 
  patch
  moves this common code to a common place.
 
  Signed-off-by: Andrew Murray andrew.mur...@arm.com
  Signed-off-by: Liviu Dudau liviu.du...@arm.com
  Reviewed-by: Rob Herring rob.herr...@calxeda.com
  Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
  Tested-by: Linus Walleij linus.wall...@linaro.org
  Acked-by: Michal Simek mon...@monstr.eu
  ---
   arch/microblaze/include/asm/pci-bridge.h |5 +-
   arch/microblaze/pci/pci-common.c |  192 
  
   arch/powerpc/include/asm/pci-bridge.h|5 +-
   arch/powerpc/kernel/pci-common.c |  192 
  

 Is there anyone on linuxppc-dev/linux-mips that can help test this 
 patchset?

 I've tested that it builds on powerpc with a variety of configs 
 (some which
 include fsl_pci.c implementation). Though I don't have hardware to 
 verify that
 it works.

 I haven't tested this builds or runs on MIPS.

 You shouldn't see any difference in behaviour or new warnings and 
 PCI devices
 should continue to operate as before.
   
I've got through a line-by-line comparison between powerpc, microblaze,
and then new code. The differences are purely cosmetic, so I have
absolutely no concerns about this patch. I've applied it to my tree.
   
oops.  Due to the number of dependencies the mvebu-pcie series has (this
being one of them, we (arm-soc/mvebu) asked if we could take this
through our tree.  Rob Herring agreed to this several days ago.  Is this
a problem for you?
   
It would truly (dogs and cats living together) upset the apple cart for
us at this stage to pipe these through a different tree...
   
   Not a problem at all. I'll drop it.
  
  Great!  Thanks.
 
 You can add my Acked-by: Grant Likely grant.lik...@linaro.org to the
 first patch. I've not reviewed out the second or third patches yet.
 
 None of this appears to be in linux-next yet. I've boot tested on
 PowerPC, but that isn't the same as an ack by the PowerPC maintainers.
 It is probably too late for the whole now since we're after -rc7.
 However, if you ask me to, I have absolutely no problem putting the
 first patch into my tree for v3.10 merging. I went over the patch
 line-by-line and am convinced that it is functionally identical.
 
 Let me know if you need me to do this.

Thanks for the offer, Olof just pulled the branch last night (my PRs
were a little late trying to sort all this out), so it should be in
shortly.

FYI:

  65ee348 of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

is in arm-soc/mvebu/drivers as well as arm-soc/next/drivers (and
arm-soc/for-next if you want to test merging everything...)

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser

[Jason Cooper]

On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote:
 On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote:
  On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray andrew.mur...@arm.com 
  wrote:
  
   This patch converts the pci_load_of_ranges function to use the new common
   of_pci_range_parser.
  
   Signed-off-by: Andrew Murray andrew.mur...@arm.com
   Signed-off-by: Liviu Dudau liviu.du...@arm.com
   Reviewed-by: Rob Herring rob.herr...@calxeda.com
  
  Tested-by: Linus Walleij linus.wall...@linaro.org
 
 Jason - you may not have seen this, but here (Linus Walleij) is another 
 Tested-by
 to add to this patch in your tree (if you can).

Thanks, I saw it.  Unfortunately, the PR was already sent, and the branch
is now pulled into arm-soc.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

[Jason Cooper]

On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
 On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com 
 wrote:
  On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
   The pci_process_bridge_OF_ranges function, used to parse the ranges
   property of a PCI host device, is found in both Microblaze and PowerPC
   architectures. These implementations are nearly identical. This patch
   moves this common code to a common place.
   
   Signed-off-by: Andrew Murray andrew.mur...@arm.com
   Signed-off-by: Liviu Dudau liviu.du...@arm.com
   Reviewed-by: Rob Herring rob.herr...@calxeda.com
   Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
   Tested-by: Linus Walleij linus.wall...@linaro.org
   Acked-by: Michal Simek mon...@monstr.eu
   ---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c |  192 
   
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c |  192 
   
  
  Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
  
  I've tested that it builds on powerpc with a variety of configs (some which
  include fsl_pci.c implementation). Though I don't have hardware to verify 
  that
  it works.
  
  I haven't tested this builds or runs on MIPS.
  
  You shouldn't see any difference in behaviour or new warnings and PCI 
  devices
  should continue to operate as before.
 
 I've got through a line-by-line comparison between powerpc, microblaze,
 and then new code. The differences are purely cosmetic, so I have
 absolutely no concerns about this patch. I've applied it to my tree.

oops.  Due to the number of dependencies the mvebu-pcie series has (this
being one of them, we (arm-soc/mvebu) asked if we could take this
through our tree.  Rob Herring agreed to this several days ago.  Is this
a problem for you?

It would truly (dogs and cats living together) upset the apple cart for
us at this stage to pipe these through a different tree...

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC

[Jason Cooper]

On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote:
 On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper ja...@lakedaemon.net wrote:
  On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
  On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com 
  wrote:
   On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
The pci_process_bridge_OF_ranges function, used to parse the ranges
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
   
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Acked-by: Michal Simek mon...@monstr.eu
---
 arch/microblaze/include/asm/pci-bridge.h |5 +-
 arch/microblaze/pci/pci-common.c |  192 

 arch/powerpc/include/asm/pci-bridge.h|5 +-
 arch/powerpc/kernel/pci-common.c |  192 

  
   Is there anyone on linuxppc-dev/linux-mips that can help test this 
   patchset?
  
   I've tested that it builds on powerpc with a variety of configs (some 
   which
   include fsl_pci.c implementation). Though I don't have hardware to 
   verify that
   it works.
  
   I haven't tested this builds or runs on MIPS.
  
   You shouldn't see any difference in behaviour or new warnings and PCI 
   devices
   should continue to operate as before.
 
  I've got through a line-by-line comparison between powerpc, microblaze,
  and then new code. The differences are purely cosmetic, so I have
  absolutely no concerns about this patch. I've applied it to my tree.
 
  oops.  Due to the number of dependencies the mvebu-pcie series has (this
  being one of them, we (arm-soc/mvebu) asked if we could take this
  through our tree.  Rob Herring agreed to this several days ago.  Is this
  a problem for you?
 
  It would truly (dogs and cats living together) upset the apple cart for
  us at this stage to pipe these through a different tree...
 
 Not a problem at all. I'll drop it.

Great!  Thanks.

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v7 0/3] of/pci: Provide common support for PCI DT parsing

[Jason Cooper]

On Tue, Apr 16, 2013 at 11:18:25AM +0100, Andrew Murray wrote:
 This patchset factors out duplicated code associated with parsing PCI
 DT ranges properties across the architectures and introduces a
 ranges parser. This parser of_pci_range_parser can be used directly
 by ARM host bridge drivers enabling them to obtain ranges from device
 trees.
 
 I've included the Reviewed-by and Tested-by's received from v5/v6 in this
 patchset, earlier versions of this patchset (v3) have been tested-by:
 
 Thierry Reding thierry.red...@avionic-design.de
 Jingoo Han jg1@samsung.com
 
 I've tested that this patchset builds and runs on ARM and that it builds on
 PowerPC and x86_64.

Series replaces v6 in mvebu/drivers

thx,

Jason.

 
 Compared to the v6 sent by Andrew Murray, the following changes have
 been made in response to build errors/warnings:
 
  * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal
Simek to prevent compilation failures on Microblaze (and others) and his
ack.
 
  * Use of externs, static inlines and a typo in linux/of_address.h in response
to linker errors (multiple defination) on x86_64 as spotted by a kbuild 
 test
robot on (jcooper/linux.git mvebu/drivers)
 
  * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent
with of_pci_process_ranges function
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4 v3] mv643xx_eth: use mvmdio MDIO bus driver

[Jason Cooper]

On Fri, Mar 22, 2013 at 02:39:24PM +0100, Florian Fainelli wrote:
 Hi all,
 
 This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
 instead of rolling its own implementation. As a result, all users of this
 mv643xx_eth driver are converted to register an orion-mdio platform_device.
 The mvmdio driver is also updated to support an interrupt line which reports
 SMI error/completion, and to allow traditionnal platform device registration
 instead of just device tree.
 
 David, I think it makes sense for you to merge all of this, since we do
 not want the architecture files to be desynchronized from the mv643xx_eth to
 avoid runtime breakage. The potential for merge conflicts should be very 
 small.
 
 Florian Fainelli (4):
   net: mvmdio: allow platform device style registration
   net: mvmdio: rename base register cookie from smireg to regs
   net: mvmdio: enhance driver to support SMI error/done interrupts
   mv643xx_eth: convert to use the Marvell Orion MDIO driver
 
  .../devicetree/bindings/net/marvell-orion-mdio.txt |3 +
  arch/arm/plat-orion/common.c   |   54 +++---
  arch/powerpc/platforms/chrp/pegasos_eth.c  |   20 ++
  arch/powerpc/sysdev/mv64x60_dev.c  |   16 +-
  drivers/net/ethernet/marvell/Kconfig   |5 +-
  drivers/net/ethernet/marvell/Makefile  |2 +-
  drivers/net/ethernet/marvell/mv643xx_eth.c |  195 
 ++--
  drivers/net/ethernet/marvell/mvmdio.c  |  130 ++---
  include/linux/mv643xx_eth.h|1 -
  9 files changed, 187 insertions(+), 239 deletions(-)

Whole series applied on top of v3.9-rc3 and tested on dreamplug
(kirkwood DT boot with legacy mv643xx_eth init)

Tested-by: Jason Cooper ja...@lakedaemon.net

also, for the bits changing plat-orion:

Acked-by: Jason Cooper ja...@lakedaemon.net

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4 v3] mv643xx_eth: use mvmdio MDIO bus driver

[Jason Cooper]

On Fri, Mar 22, 2013 at 03:24:55PM +0100, Florian Fainelli wrote:
 Le 03/22/13 15:14, Jason Cooper a écrit :
 On Fri, Mar 22, 2013 at 02:39:24PM +0100, Florian Fainelli wrote:
 Hi all,
 
 This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
 instead of rolling its own implementation. As a result, all users of this
 mv643xx_eth driver are converted to register an orion-mdio 
 platform_device.
 The mvmdio driver is also updated to support an interrupt line which reports
 SMI error/completion, and to allow traditionnal platform device registration
 instead of just device tree.
 
 David, I think it makes sense for you to merge all of this, since we do
 not want the architecture files to be desynchronized from the mv643xx_eth to
 avoid runtime breakage. The potential for merge conflicts should be very 
 small.
 
 Florian Fainelli (4):
net: mvmdio: allow platform device style registration
net: mvmdio: rename base register cookie from smireg to regs
net: mvmdio: enhance driver to support SMI error/done interrupts
mv643xx_eth: convert to use the Marvell Orion MDIO driver
 
   .../devicetree/bindings/net/marvell-orion-mdio.txt |3 +
   arch/arm/plat-orion/common.c   |   54 +++---
   arch/powerpc/platforms/chrp/pegasos_eth.c  |   20 ++
   arch/powerpc/sysdev/mv64x60_dev.c  |   16 +-
   drivers/net/ethernet/marvell/Kconfig   |5 +-
   drivers/net/ethernet/marvell/Makefile  |2 +-
   drivers/net/ethernet/marvell/mv643xx_eth.c |  195 
  ++--
   drivers/net/ethernet/marvell/mvmdio.c  |  130 ++---
   include/linux/mv643xx_eth.h|1 -
   9 files changed, 187 insertions(+), 239 deletions(-)
 
 Whole series applied on top of v3.9-rc3 and tested on dreamplug
 (kirkwood DT boot with legacy mv643xx_eth init)
 
 Ok, thanks! Does that mean that you want these changes to go via
 your tree? David initially applied my v2 of this patchset, and since
 it thouches mostly ethernet driver stuff, I would rather make it go
 via his tree if both of you agree.

Yeah, I thought I should have reworded that after I hit send :)  I
simply meant it applied cleanly against v3.9-rc3, booted, and worked.  I
Acked it so David could take the whole series through his tree.  Sorry
for the confusion.

Now that I can build mv643xx_eth DT on top of this, I'll structure it so
those changes go on top of yours (in David's tree) and try to avoid the
external dependency for the DT bits going though arm-soc.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/5] mv643xx_eth: use mvmdio MDIO bus driver

[Jason Cooper]

On Thu, Mar 14, 2013 at 07:09:18PM +0100, Florian Fainelli wrote:
 Hello Jason,
 
 Le 03/14/13 18:25, Jason Cooper a écrit :
 Florian,
 
 Any word on version 2 of this series?  I'd like to base the conversion
 of kirkwood to DT based ethernet init on it.
 
 Just sent them out for review, thanks for reminder, they were
 sitting in my tree for a couple days already.

Great!  I'll give this a spin.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] mv643xx_eth: convert to use the Marvell Orion MDIO driver

[Jason Cooper]

Florian,

On Thu, Mar 14, 2013 at 07:08:32PM +0100, Florian Fainelli wrote:
 This patch converts the Marvell MV643XX ethernet driver to use the
 Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
 registering the Marvell MV643XX ethernet driver are also updated to
 register a Marvell Orion MDIO driver. This driver voluntarily overlaps
 with the Marvell Ethernet shared registers because it will use a subset
 of this shared register (shared_base + 0x4 - shared_base + 0x84). The
 Ethernet driver is also updated to look up for a PHY device using the
 Orion MDIO bus driver.
 
 Signed-off-by: Florian Fainelli flor...@openwrt.org
 ---
  arch/arm/plat-orion/common.c   |   97 +++
  arch/powerpc/platforms/chrp/pegasos_eth.c  |   20 +++
  arch/powerpc/sysdev/mv64x60_dev.c  |   14 ++-
  drivers/net/ethernet/marvell/Kconfig   |1 +
  drivers/net/ethernet/marvell/mv643xx_eth.c |  186 
 ++--
  include/linux/mv643xx_eth.h|1 -
  6 files changed, 117 insertions(+), 202 deletions(-)

Isn't this the old version of 4/4 ?

thx,

Jason.

 
 diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
 index 2d4b641..dc4345e 100644
 --- a/arch/arm/plat-orion/common.c
 +++ b/arch/arm/plat-orion/common.c
 @@ -238,6 +238,7 @@ static __init void ge_complete(
   struct mv643xx_eth_shared_platform_data *orion_ge_shared_data,
   struct resource *orion_ge_resource, unsigned long irq,
   struct platform_device *orion_ge_shared,
 + struct platform_device *orion_ge_mvmdio,
   struct mv643xx_eth_platform_data *eth_data,
   struct platform_device *orion_ge)
  {
 @@ -247,6 +248,8 @@ static __init void ge_complete(
   orion_ge-dev.platform_data = eth_data;
  
   platform_device_register(orion_ge_shared);
 + if (orion_ge_mvmdio)
 + platform_device_register(orion_ge_mvmdio);
   platform_device_register(orion_ge);
  }
  
 @@ -258,8 +261,6 @@ struct mv643xx_eth_shared_platform_data 
 orion_ge00_shared_data;
  static struct resource orion_ge00_shared_resources[] = {
   {
   .name   = ge00 base,
 - }, {
 - .name   = ge00 err irq,
   },
  };
  
 @@ -271,6 +272,19 @@ static struct platform_device orion_ge00_shared = {
   },
  };
  
 +static struct resource orion_ge00_mvmdio_resources[] = {
 + {
 + .name   = ge00 mvmdio base,
 + }, {
 + .name   = ge00 mvmdio irr irq,
 + },
 +};
 +
 +static struct platform_device orion_ge00_mvmdio = {
 + .name   = orion-mdio,
 + .id = 0,
 +};
 +
  static struct resource orion_ge00_resources[] = {
   {
   .name   = ge00 irq,
 @@ -295,26 +309,25 @@ void __init orion_ge00_init(struct 
 mv643xx_eth_platform_data *eth_data,
   unsigned int tx_csum_limit)
  {
   fill_resources(orion_ge00_shared, orion_ge00_shared_resources,
 -mapbase + 0x2000, SZ_16K - 1, irq_err);
 +mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
 + fill_resources(orion_ge00_mvmdio, orion_ge00_mvmdio_resources,
 + mapbase + 0x2004, 0x84 - 1, irq_err);
   orion_ge00_shared_data.tx_csum_limit = tx_csum_limit;
   ge_complete(orion_ge00_shared_data,
   orion_ge00_resources, irq, orion_ge00_shared,
 + orion_ge00_mvmdio,
   eth_data, orion_ge00);
  }
  
  
 /*
   * GE01
   
 /
 -struct mv643xx_eth_shared_platform_data orion_ge01_shared_data = {
 - .shared_smi = orion_ge00_shared,
 -};
 +struct mv643xx_eth_shared_platform_data orion_ge01_shared_data;
  
  static struct resource orion_ge01_shared_resources[] = {
   {
   .name   = ge01 base,
 - }, {
 - .name   = ge01 err irq,
 - },
 + }
  };
  
  static struct platform_device orion_ge01_shared = {
 @@ -325,6 +338,19 @@ static struct platform_device orion_ge01_shared = {
   },
  };
  
 +static struct resource orion_ge01_mvmdio_resources[] = {
 + {
 + .name   = ge01 mdio base,
 + }, {
 + .name   = ge01 mdio err irq,
 + },
 +};
 +
 +static struct platform_device orion_ge01_mvmdio = {
 + .name   = orion-mdio,
 + .id = 1,
 +};
 +
  static struct resource orion_ge01_resources[] = {
   {
   .name   = ge01 irq,
 @@ -349,26 +375,25 @@ void __init orion_ge01_init(struct 
 mv643xx_eth_platform_data *eth_data,
   unsigned int tx_csum_limit)
  {
   fill_resources(orion_ge01_shared, orion_ge01_shared_resources,
 -mapbase + 0x2000, SZ_16K - 1, irq_err);
 +mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
 + fill_resources(orion_ge01_mvmdio, orion_ge01_mvmdio_resources,
 +  

Re: [PATCH 0/5] mv643xx_eth: use mvmdio MDIO bus driver

[Jason Cooper]

Florian,

Any word on version 2 of this series?  I'd like to base the conversion
of kirkwood to DT based ethernet init on it.

thx,

Jason.

On Tue, Jan 29, 2013 at 04:24:03PM +0100, Florian Fainelli wrote:
 Hi all,
 
 This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
 instead of rolling its own implementation. As a result, all users of this
 mv643xx_eth driver are converted to register an orion-mdio platform_device.
 The mvmdio driver is also updated to support an interrupt line which reports
 SMI error/completion, and to allow traditionnal platform device registration
 instead of just device tree.
 
 David, I think it makes sense for you to merge all of this, since we do
 not want the architecture files to be desynchronized from the mv643xx_eth to
 avoid runtime breakage. The potential for merge conflicts should be very 
 small.
 
 You can probably safely merge patches 1 to 4 if Thomas agrees, and we will
 see what kind of feeback I get on patch 5.
 
 Florian Fainelli (5):
   net: mvmdio: unmap base register address at driver removal
   net: mvmdio: rename base register cookie from smireg to regs
   net: mvmdio: enhance driver to support SMI error/done interrupts
   net: mvmdio: allow Device Tree and platform device to coexist
   mv643xx_eth: convert to use the Marvell Orion MDIO driver
 
  .../devicetree/bindings/net/marvell-orion-mdio.txt |3 +
  arch/arm/plat-orion/common.c   |   84 +++--
  arch/powerpc/platforms/chrp/pegasos_eth.c  |   20 +++
  arch/powerpc/sysdev/mv64x60_dev.c  |   14 +-
  drivers/net/ethernet/marvell/Kconfig   |1 +
  drivers/net/ethernet/marvell/mv643xx_eth.c |  187 
 +---
  drivers/net/ethernet/marvell/mvmdio.c  |  136 +++---
  7 files changed, 226 insertions(+), 219 deletions(-)
 
 -- 
 1.7.10.4
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] mv643xx_eth: convert to use the Marvell Orion MDIO driver

[Jason Cooper]

On Thu, Mar 14, 2013 at 08:32:57PM +0100, Florian Fainelli wrote:
 Hello Jason,
 
 Le 14/03/2013 20:02, Jason Cooper a écrit :
 Florian,
 
 On Thu, Mar 14, 2013 at 07:08:32PM +0100, Florian Fainelli wrote:
 This patch converts the Marvell MV643XX ethernet driver to use the
 Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
 registering the Marvell MV643XX ethernet driver are also updated to
 register a Marvell Orion MDIO driver. This driver voluntarily overlaps
 with the Marvell Ethernet shared registers because it will use a subset
 of this shared register (shared_base + 0x4 - shared_base + 0x84). The
 Ethernet driver is also updated to look up for a PHY device using the
 Orion MDIO bus driver.
 
 Signed-off-by: Florian Fainelli flor...@openwrt.org
 ---
   arch/arm/plat-orion/common.c   |   97 +++
   arch/powerpc/platforms/chrp/pegasos_eth.c  |   20 +++
   arch/powerpc/sysdev/mv64x60_dev.c  |   14 ++-
   drivers/net/ethernet/marvell/Kconfig   |1 +
   drivers/net/ethernet/marvell/mv643xx_eth.c |  186 
  ++--
   include/linux/mv643xx_eth.h|1 -
   6 files changed, 117 insertions(+), 202 deletions(-)
 
 Isn't this the old version of 4/4 ?
 
 No this really is v2, but I reformatted just that one and sent it
 without the v2 changelog, you should have received the proper
 version a couple minutes later once I realized my mistake.

Yes, I received both, just making sure.

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.

[Jason Cooper]

Pong.  ;-)

On Tue, Sep 11, 2012 at 04:03:31PM +1000, Benjamin Herrenschmidt wrote:
 On Mon, 2012-09-10 at 14:22 +, Arnd Bergmann wrote:
  Following up on the old discussion, I talked briefly about this
  issue with BenH at the kernel summit. The outcome basically is that
  it's a bit sad to have incompatible bindings, but it's not the end
  of the world,and it's more important to do it right this time.
  
  Just make sure that you use different values for the 'compatible'
  strings and then do what you need to get the ARM hardware working.
  
  Ideally, the new binding should be written in a way that powerpc
  machines can use the same one, but the existing ones all use
  an version of Open Firmware that is not going to get updated
  and it's also not too likely that we are going to see new
  powerpc machines based on this chip.
 
 Right, mostly these machines where the Pegasos. Those came with a fairly
 busted variant of Open Firmware which generated a pretty gross
 device-tree.
 
 For some reason, the manufacturer of those things was never willing to
 fix anything in their firmware (despite the distributor providing
 patches etc...), seemingly on the assumption that whatever they were
 doing was perfect and operating system people like us didn't matter one
 little bit :-)
 
 So I don't care much about it. It would be nice to keep them working
 since people in the community still have them but if it goes through
 some compat code that detects old/broken device-trees and eventually
 disappears when we finally drop support, then so be it.

Ian,

What is the status of this work?

thx,

Jason.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev