RE: [PATCH] powerpc/mpc85xx: Add pcsphy nodes to FManV3 device tree
Regards,
Igal Liberman
> -Original Message-
> From: Shaohui Xie [mailto:shaohui@nxp.com]
> Sent: Tuesday, December 22, 2015 8:27 AM
> To: Liberman Igal-B31950 <igal.liber...@freescale.com>;
> devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Cc: Wood Scott-B07421 <scottw...@freescale.com>; Bucur Madalin-
> Cristian-B32716 <madalin.bu...@freescale.com>; Xie Shaohui-B21989
> <shaohui@freescale.com>
> Subject: RE: [PATCH] powerpc/mpc85xx: Add pcsphy nodes to FManV3
> device tree
>
> > @@ -55,6 +55,7 @@ fman@40 {
> > reg = <0xe 0x1000>;
> > fsl,fman-ports = <_rx_0x08 _tx_0x28>;
> > ptp-timer = <_timer0>;
> > + pcsphy-handle = <>;
> > };
> >
> > mdio@e1000 {
> > @@ -62,5 +63,9 @@ fman@40 {
> > #size-cells = <0>;
> > compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
> > reg = <0xe1000 0x1000>;
> > +
> > + pcsphy0: ethernet-phy@0 {
> > + reg = <0x0>;
> > + };
> > };
> > };
>
> [S.H] snip.
>
> > mdio@e1000 {
> > @@ -58,5 +59,9 @@ fman@40 {
> > #size-cells = <0>;
> > compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
> > reg = <0xe1000 0x1000>;
> > +
> > + pcsphy0: pcs-phy@0 {
> > + reg = <0x0>;
> > + };
> > };
> [S.H] Should use 'ethernet-phy', same as above.
>
I'll resubmit and fix this (pcs-phy ---> ethernet-phy).
Thank you,
Igal
> Thanks,
> Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/mpc85xx: Add pcsphy nodes to FManV3 device tree
Regards, Igal Liberman > -Original Message- > From: Wood Scott-B07421 > Sent: Monday, December 21, 2015 4:41 PM > To: Liberman Igal-B31950 <igal.liber...@freescale.com>; > devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Cc: Bucur Madalin-Cristian-B32716 <madalin.bu...@freescale.com>; Xie > Shaohui-B21989 <shaohui@freescale.com> > Subject: Re: [PATCH] powerpc/mpc85xx: Add pcsphy nodes to FManV3 > device tree > > On Mon, 2015-12-21 at 01:57 +0200, igal.liber...@freescale.com wrote: > > From: Igal Liberman <igal.liber...@freescale.com> > > > > Signed-off-by: Igal Liberman <igal.liber...@freescale.com> > > > > This patch adds pcsphy node to FManV3 device tree. > > Based on: https://patchwork.ozlabs.org/patch/503921/ > > --- > > .../dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi |5 + > > .../dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi |5 + > > arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi |5 + > > 18 files changed, 90 insertions(+) > > Binding? > Working on that, I'll submit ASAP. Igal > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl: Update fman dt binding with pcs-phy and tbi-phy
Regards,
Igal Liberman
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Tuesday, December 22, 2015 5:57 PM
> To: linuxppc-dev@lists.ozlabs.org; Liberman Igal-B31950
> <igal.liber...@freescale.com>; devicet...@vger.kernel.org
> Cc: Wood Scott-B07421 <scottw...@freescale.com>; Xie Shaohui-B21989
> <shaohui@freescale.com>; Bucur Madalin-Cristian-B32716
> <madalin.bu...@freescale.com>
> Subject: Re: [PATCH] powerpc/fsl: Update fman dt binding with pcs-phy and
> tbi-phy
>
> On Tue, 2015-12-22 at 06:18 +0200, igal.liber...@freescale.com wrote:
> > From: Igal Liberman <igal.liber...@freescale.com>
> >
> > Signed-off-by: Igal Liberman <igal.liber...@freescale.com>
> > ---
> > .../devicetree/bindings/powerpc/fsl/fman.txt | 39
> >
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > index 1fc5328..7a6d7c3 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > @@ -315,6 +315,16 @@ PROPERTIES
> > Value type:
> > Definition: A phandle for 1EEE1588 timer.
> >
> > +- pcsphy-handle
> > + Usage required for "fsl,fman-memac" MACs
> > + Value type:
> > + Definition: A phandle for pcsphy.
> > +
> > +- tbi-handle
> > + Usage required for "fsl,fman-dtsec" MACs
> > + Value type:
> > + Definition: A phandle for tbiphy.
> > +
> > EXAMPLE
> >
> > fman1_tx28: port@a8000 {
> > @@ -340,6 +350,7 @@ ethernet@e {
> > reg = <0xe 0x1000>;
> > fsl,fman-ports = <_rx8 _tx28>;
> > ptp-timer = <>;
> > + tbi-handle = <>;
> > };
> >
> >
> >
> ==
>
> > ==
> > @@ -415,6 +426,13 @@ PROPERTIES
> > The settings and programming routines for internal/external
> > MDIO are different. Must be included for internal MDIO.
> >
> > +For internal PHY device on internal mdio bus, a PHY node should be
> created.
> > +See the definition of the PHY node in booting-without-of.txt for an
> > +example of how to define a PHY (Internal PHY has no interrupt line).
> > +- For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
> > +- For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is
> > +PCS PHY,
> > + PCS PHY addr must be '0'.
>
> Will this replace the need for fixed PHYs ?
>
Hi Jocke,
No, this is internal PCS configuration which required for both types of links.
The configuration for fixed links is different, but we use the same method.
Igal
> Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v9, 3/6] fsl/fman: Add FMan MAC support
Regards,
Igal Liberman
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, December 03, 2015 10:24 PM
> To: Liberman Igal-B31950 <igal.liber...@freescale.com>
> Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; Wood Scott-B07421 <scottw...@freescale.com>;
> Bucur Madalin-Cristian-B32716 <madalin.bu...@freescale.com>;
> pebo...@tiscali.nl; joakim.tjernl...@transmode.se; p...@mindchasers.com;
> step...@networkplumber.org
> Subject: Re: [v9, 3/6] fsl/fman: Add FMan MAC support
>
> From: <igal.liber...@freescale.com>
> Date: Thu, 3 Dec 2015 09:19:14 +0200
>
> > +static u32 crc_table[256] = {
>
> No way.
>
> We have every conceivable implementation of CRC calculations in the kernel
> already. Use them.
OK, I will remove the private implementation of CRC calculation in the next
submission. Thank you.
Igal
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v8, 2/6] fsl/fman: Add FMan support
Hi David, Thank you for your feedback, I'll address it and re-submit. Regards, Igal Liberman > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, December 01, 2015 11:28 PM > To: Liberman Igal-B31950 <igal.liber...@freescale.com> > Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Wood Scott-B07421 <scottw...@freescale.com>; > Bucur Madalin-Cristian-B32716 <madalin.bu...@freescale.com>; > pebo...@tiscali.nl; joakim.tjernl...@transmode.se; p...@mindchasers.com; > step...@networkplumber.org > Subject: Re: [v8, 2/6] fsl/fman: Add FMan support > > From: <igal.liber...@freescale.com> > Date: Mon, 30 Nov 2015 14:20:58 +0200 > > > +typedef irqreturn_t (fman_exceptions_cb)(struct fman *fman, > > +enum fman_exceptions exception); > > Function and function pointer declarations and definitions should be > indented such that the second and subsequent lines begin precisely at the > first column after the openning parenthesis of the first line. > > Please audit this and fix it in your entire submission, almost ever new such > case is done incorrectly. > > > + fman->state->exceptions = (EX_DMA_BUS_ERROR | > > + EX_DMA_READ_ECC | > > + EX_DMA_SYSTEM_WRITE_ECC | > > + EX_DMA_FM_WRITE_ECC | > > + EX_FPM_STALL_ON_TASKS| > > + EX_FPM_SINGLE_ECC| > > + EX_FPM_DOUBLE_ECC| > > + > EX_QMI_DEQ_FROM_UNKNOWN_PORTID | > > + EX_BMI_LIST_RAM_ECC | > > + EX_BMI_STORAGE_PROFILE_ECC | > > + EX_BMI_STATISTICS_RAM_ECC| > > + EX_MURAM_ECC | > > + EX_BMI_DISPATCH_RAM_ECC | > > + EX_QMI_DOUBLE_ECC| > > + EX_QMI_SINGLE_ECC); > > The same applies to multi-line parenthesized expressions like this one. > Again, please audit and fix this in your entire submission. > > Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [V5, 2/6] fsl/fman: Add FMan support
Regards,
Igal Liberman
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, October 28, 2015 11:31 PM
> To: Liberman Igal-B31950 <igal.liber...@freescale.com>
> Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; Bucur Madalin-Cristian-B32716
> <madalin.bu...@freescale.com>
> Subject: Re: [V5, 2/6] fsl/fman: Add FMan support
>
> On Tue, 2015-10-27 at 11:32 -0500, Liberman Igal-B31950 wrote:
>
> > > > +
> > > > +struct device *fman_get_device(struct fman *fman) { return
> > > > +fman->dev; }
> > >
> > > Is this really necessary?
> > >
> >
> > Fman port needs fman->dev, fman structure is opaque, so yes, it's needed.
>
> Why is opacity being maintained from one part of the fman driver to
> another?
> Isn't this the sort of excessive layering that was complained about?
>
>
It's not really layering.
Fman Port uses Fman resources, it's not completely standalone.
> > > > + /* In B4 rev 2.0 (and above) the MURAM size is 512KB.
> > > > + * Check the SVR and update MURAM size if required.
> > > > + */
> > > > + u32 svr;
> > > > +
> > > > + svr = mfspr(SPRN_SVR);
> > > > +
> > > > + if ((SVR_SOC_VER(svr) == SVR_B4860) && (SVR_MAJ(svr) >=
> > > 2))
> > > > + fman->dts_params.muram_size = 0x8; }
> > >
> > > Why wasn't the MURAM size described in the device tree, as it was
> > > with CPM/QE?
> > >
> >
> > MURAM size described by the device-tree.
> > In B4860 rev 2.0 (and above) MURAM size is bigger.
> > This is workaround, in order to have the same device tree for all
> > B4860 revisions.
>
> We don't support b4860 prior to rev 2.0 (due to e6500 core errata) so this is
> irrelevant. Fix the device tree.
>
OK, thanks.
I'll submit a new device tree patch (on top of the existing patches, which are
awaiting upstream) and remove this code from Fman.
> > > > +
> > > > + of_node_put(muram_node);
> > > > + of_node_put(fm_node);
> > > > +
> > > > + err = devm_request_irq(_dev->dev, irq, fman_irq,
> > > > +IRQF_NO_SUSPEND, "fman", fman); if (err <
> > > > + 0) {
> > > > + pr_err("Error: allocating irq %d (error = %d)\n", irq, err);
> > > > + goto fman_free;
> > > > + }
> > >
> > > Why IRQF_NO_SUSPEND?
> > >
> >
> > It shouldn't be IRQF_NO_SUSPEND for now, removed.
>
> Why just "for now"?
>
Unsuccessful wording, sorry.
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [V5, 2/6] fsl/fman: Add FMan support
Regards,
Igal Liberman
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, October 29, 2015 5:25 PM
> To: Liberman Igal-B31950 <igal.liber...@freescale.com>
> Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; Bucur Madalin-Cristian-B32716
> <madalin.bu...@freescale.com>
> Subject: Re: [V5, 2/6] fsl/fman: Add FMan support
>
> On Thu, 2015-10-29 at 10:22 -0500, Liberman Igal-B31950 wrote:
> > Regards,
> > Igal Liberman
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, October 28, 2015 11:31 PM
> > > To: Liberman Igal-B31950 <igal.liber...@freescale.com>
> > > Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > > ker...@vger.kernel.org; Bucur Madalin-Cristian-B32716
> > > <madalin.bu...@freescale.com>
> > > Subject: Re: [V5, 2/6] fsl/fman: Add FMan support
> > >
> > > On Tue, 2015-10-27 at 11:32 -0500, Liberman Igal-B31950 wrote:
> > >
> > > > > > +
> > > > > > +struct device *fman_get_device(struct fman *fman) { return
> > > > > > +fman->dev; }
> > > > >
> > > > > Is this really necessary?
> > > > >
> > > >
> > > > Fman port needs fman->dev, fman structure is opaque, so yes, it's
> > > > needed.
> > >
> > > Why is opacity being maintained from one part of the fman driver to
> > > another?
> > > Isn't this the sort of excessive layering that was complained about?
> > >
> > >
> >
> > It's not really layering.
> > Fman Port uses Fman resources, it's not completely standalone.
>
> That's my point -- if it's not standalone, why is "struct fman" opaque to the
> port code?
>
OK, I'll expose struct fman.
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [V5, 2/6] fsl/fman: Add FMan support
Regards,
Igal Liberman
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, September 26, 2015 2:02 AM
> To: Liberman Igal-B31950 <igal.liber...@freescale.com>
> Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; Bucur Madalin-Cristian-B32716
> <madalin.bu...@freescale.com>
> Subject: Re: [V5, 2/6] fsl/fman: Add FMan support
>
> On Mon, Sep 21, 2015 at 02:52:34PM +0300, Igal.Liberman wrote:
> > diff --git a/drivers/net/ethernet/freescale/fman/fman.c
> > b/drivers/net/ethernet/freescale/fman/fman.c
> > new file mode 100644
> > index 000..924685f
> > --- /dev/null
> > +++ b/drivers/net/ethernet/freescale/fman/fman.c
> > @@ -0,0 +1,2738 @@
> > +/*
> > + * Copyright 2008-2015 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are
> met:
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in
> > the
> > + * documentation and/or other materials provided with the
> distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote
> products
> > + * derived from this software without specific prior written
> > permission.
> > + *
> > +// *
> > + * ALTERNATIVELY, this software may be distributed under the terms of
> > +the
> > + * GNU General Public License ("GPL") as published by the Free
> > +Software
> > + * Foundation, either version 2 of that License or (at your option)
> > +any
> > + * later version.
>
> What is that // doing there?
Removed.
>
> > +/* Exceptions bit map */
> > +#define EX_DMA_BUS_ERROR 0x8000
> > +#define EX_DMA_READ_ECC0x4000
> > +#define EX_DMA_SYSTEM_WRITE_ECC0x2000
> > +#define EX_DMA_FM_WRITE_ECC0x1000
> > +#define EX_FPM_STALL_ON_TASKS 0x0800
> > +#define EX_FPM_SINGLE_ECC 0x0400
> > +#define EX_FPM_DOUBLE_ECC 0x0200
> > +#define EX_QMI_SINGLE_ECC 0x0100
> > +#define EX_QMI_DEQ_FROM_UNKNOWN_PORTID 0x0080
> > +#define EX_QMI_DOUBLE_ECC 0x0040
> > +#define EX_BMI_LIST_RAM_ECC0x0020
> > +#define EX_BMI_STORAGE_PROFILE_ECC 0x0010
> > +#define EX_BMI_STATISTICS_RAM_ECC 0x0008
> > +#define EX_IRAM_ECC0x0004
> > +#define EX_MURAM_ECC 0x0002
> > +#define EX_BMI_DISPATCH_RAM_ECC0x0001
> > +#define EX_DMA_SINGLE_PORT_ECC 0x8000
> > +
> > +#define DFLT_EXCEPTIONS\
> > +((EX_DMA_BUS_ERROR)| \
> > + (EX_DMA_READ_ECC) | \
> > + (EX_DMA_SYSTEM_WRITE_ECC) | \
> > + (EX_DMA_FM_WRITE_ECC) | \
> > + (EX_FPM_STALL_ON_TASKS)| \
> > + (EX_FPM_SINGLE_ECC)| \
> > + (EX_FPM_DOUBLE_ECC)| \
> > + (EX_QMI_DEQ_FROM_UNKNOWN_PORTID) | \
> > + (EX_BMI_LIST_RAM_ECC) | \
> > + (EX_BMI_STORAGE_PROFILE_ECC) | \
> > + (EX_BMI_STATISTICS_RAM_ECC)| \
> > + (EX_MURAM_ECC) | \
> > + (EX_BMI_DISPATCH_RAM_ECC) | \
> > + (EX_QMI_DOUBLE_ECC)| \
> > + (EX_QMI_SINGLE_ECC))
>
> You don't need parentheses around each symbol.
>
Removed the parentheses (here and in other places)
> This is only used in one place -- why put the list here rather than in the
> place
> where it's used?
>
Moved this define.
> > +struct fman_state_struct {
> > + u8 fm_id;
> > + u16 fm_clk_freq;
> > + struct fman_rev_info rev_info;
> > + bool enabled_time_stamp;
> > + u8 count1_micro_bit;
> > + u8 total_num_of_tasks;
> > + u8 accumulated_num_of_tasks;
> > + u32 accumulated_fifo_size;
> > + u8 accumulated_num_of_open_dmas;
> > + u8 accumulated_num_of_deq_tnums;
> > + bool low_end_restriction;
> > + u32 exceptions;
> > + u32 extra_fifo_pool_size;
> > + u8 extra_tasks_pool_size;
> > + u8 extra_open_dmas_pool_size;
> > + u16 port_mfl[MAX_NUM_OF_MACS];
> > +
RE: [v4, 0/9] Freescale DPAA FMan
Hello David, Thank you for your feedback. I understand your concerns regarding the FMan driver, we've come a long way from where we started but still there are issues. The community support is critical for getting the code to the desired quality level and I appreciate the support I receive from you and from the other previous reviewers. In order to reduce the code scattering I plan to put together all the code for a certain IP block in one file. For example FMan port in his current state in /drivers/net/freescale/fman/: flib (directory) fsl_fman_port.h inc (directory) fm_port_ext.h (API for other drivers/modules) port (directory) fman_port.c (flib) fm_port.c fm_port.h Makefile fm_port_drv.c (file) New proposed structure in /drivers/net/freescale/fman/: fman_port_drv.c (includes simplified code from fm_port.c, fman_port.c and fm_port_drv.c) fman_port_drv.h (exported structures and API, minimal) Of-course, I'll do the same for other modules (MAC, FMan itself). After this structure change we get: - Subdirectories completely removed - Layering reduced, each module becomes much flatter, with one source and header file - Fewer number of files (sources and headers) - Namespace pollution drastically reduced - General complexity of the driver reduced. I would appreciate your comments about the steps described above. Regards, Igal -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Saturday, August 08, 2015 1:31 AM To: Liberman Igal-B31950 igal.liber...@freescale.com Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; Wood Scott-B07421 scottw...@freescale.com; Bucur Madalin-Cristian-B32716 madalin.bu...@freescale.com; pebo...@tiscali.nl; joakim.tjernl...@transmode.se; p...@mindchasers.com; step...@networkplumber.org Subject: Re: [v4, 0/9] Freescale DPAA FMan From: igal.liber...@freescale.com Date: Wed, 5 Aug 2015 12:25:16 +0300 The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores and the accelerators. I think the directory and code structure of this new driver is quite excessive. Because you've split things up _so_ much, you have to have all of these directories, and even worse and much more important to me you have to export so many functions from one source file to another. I think this is way too much. For example, in one file you have a bunch of initialization routines. init_a(), init_b(), init_c(), and you export them all. Then they are always called in sequence: init_a(); init_b(); init_c(); This is completely pointless. You just needed to export one function which calls all three functions. The namespace pollution of this driver is out of control. You really need to completely rework the architecture and layout of this driver before I will even begin to review it again. And the lack of review interest by other developers should be an indication to you how undesirable this code submission is to read. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v3, 1/2] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan
Regards,
Igal Liberman
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 04, 2015 8:00 AM
To: Liberman Igal-B31950 igal.liber...@freescale.com
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur
Madalin-Cristian-B32716 madalin.bu...@freescale.com; linux-
ker...@vger.kernel.org
Subject: Re: [v3,1/2] powerpc/mpc85xx: Create dts components for the FSL
QorIQ DPAA FMan
[Resending after bogofilter adjustment on vger.kernel.org]
On Mon, Aug 03, 2015 at 09:44:01AM +0300, Igal.Liberman wrote:
+ xmdio0: mdio@f1000{
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,fman-xmdio;
+ reg = 0xf1000 0x1000;
+ interrupts = 101 1 0 0;
+ };
Why is this 101 1 0 0 and not 101 2 0 0? Internal interrupts are active-
high.
OK, I'll fix this issue. Thanks.
Igal.
+ mdio0: mdio@e1120{
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,fman-mdio;
+ reg = 0xe1120 0xee0;
+ interrupts = 100 1 0 0;
Likewise.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 30, 2015 11:12 PM
To: Liberman Igal-B31950
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur
Madalin-Cristian-B32716; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan
support to the SoC device tree(s)
On Thu, 2015-07-30 at 07:33 +0300, Igal.Liberman wrote:
@@ -307,4 +307,117 @@
reg = 0xe 0x1000;
fsl,has-rstcr;
};
+
+ fman@10{
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ ranges = 0 0x10 0x10;
+ compatible = fsl,fman;
+ reg = 0x10 0x10;
+ interrupts = 24 2 0 0, 16 2 1 30;
+ clock-frequency = 0;
+ fsl,qman-channel-range = 0x40 0x7;
fman is supposed to have clocks/clock-names, not clock-frequency.
The new clock binding doesn't support P1023 yet.
I'll drop P1023 from this submission, it's not supported currently by the
driver, we'll re-add it later.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/2] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 30, 2015 11:00 PM
To: Liberman Igal-B31950
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur
Madalin-Cristian-B32716; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2 1/2] powerpc/mpc85xx: Create dts components for
the FSL QorIQ DPAA FMan
On Thu, 2015-07-30 at 07:32 +0300, Igal.Liberman wrote:
+fman0: fman@40{
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ compatible = fsl,fman;
+ ranges = 0 0x40 0x10;
+ reg = 0x40 0x10;
+ interrupts = 96 2 0 0, 16 2 1 1;
+ clocks = clockgen 3 0;
+ clock-names = fm0clk;
clock-names should be fmanclk as per the binding. And why would you
want the driver to have to encode the fman index into the name in order to
look the clock up by name?
Well, yes, this should be fmanclk. The driver doesn't need to know the index.
I'll fix that and re-submit.
Igal.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Thursday, July 30, 2015 11:16 PM To: Liberman Igal-B31950 Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur Madalin-Cristian-B32716; Xie Shaohui-B21989; linux-ker...@vger.kernel.org Subject: Re: [PATCH v4] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s) On Thu, 2015-07-30 at 07:47 +0300, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com Describe the PHY topology for all configurations supported by each board Based on prior work by Andy Fleming aflem...@freescale.com Signed-off-by: Igal Liberman igal.liber...@freescale.com Signed-off-by: Shruti Kanetkar shr...@freescale.com Signed-off-by: Emil Medve emilian.me...@freescale.com Signoffs should be in chronological order. You were the last to touch/submit this, so yours should go last. Likewise in the other patches you just posted. Ok, I'll keep the correct order, thanks for pointing out. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 8/8] powerpc/fsl: Use new clockgen binding
Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Friday, June 19, 2015 5:49 AM To: Mike Turquette; Tang Yuantian-B29983 Cc: Rafael J. Wysocki; Liberman Igal-B31950; Bucur Madalin-Cristian-B32716; linux-...@vger.kernel.org; linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Wood Scott-B07421 Subject: [RFC PATCH 8/8] powerpc/fsl: Use new clockgen binding The driver retains compatibility with old device trees, but we don't want the old nodes lying around to be copied, or used as a reference (some of the mux options are incorrect), or even just being clutter. We will also need the #clock-cells in the clockgen node in order to add fman nodes. Signed-off-by: Scott Wood scottw...@freescale.com --- Tested on: several e500mc, e5500 and e6500 platforms. Tested-by: Igal Liberman igal.liber...@freescale.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v3, 5/9] fsl/fman: Add Frame Manager support
Regards,
Igal Liberman.
+static struct platform_driver fm_driver = {
+ .driver = {
+.name = fsl-fman,
+.of_match_table = fm_match,
+},
+ .probe = fm_probe,
+};
+
+builtin_platform_driver(fm_driver);
+
+static int __init __cold fm_load(void)
+{
+ if (platform_driver_register(fm_driver)) {
+ pr_crit(platform_driver_register() failed\n);
+ return -ENODEV;
+ }
+
+ pr_info(Freescale FMan module\n);
+ return 0;
+}
+
+device_initcall(fm_load);
Please notice, when using builtin_platform_driver, device_initcall(fm_load);
becomes redundant.
Same issue in 2 other places.
I have patches which fix that which were left out of this submission, I'll add
them to v4.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v3, 2/9] fsl/fman: Add the FMan port FLIB
Regards, Igal Liberman. -Original Message- From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: Wednesday, July 22, 2015 7:56 PM To: Liberman Igal-B31950 Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; Wood Scott-B07421; Bucur Madalin-Cristian-B32716; pebo...@tiscali.nl; joakim.tjernl...@transmode.se; p...@mindchasers.com Subject: Re: [v3, 2/9] fsl/fman: Add the FMan port FLIB On Wed, 22 Jul 2015 14:21:48 +0300 igal.liber...@freescale.com wrote: diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig index 8aeae29..af42c3a 100644 --- a/drivers/net/ethernet/freescale/fman/Kconfig +++ b/drivers/net/ethernet/freescale/fman/Kconfig @@ -5,3 +5,4 @@ config FSL_FMAN help Freescale Data-Path Acceleration Architecture Frame Manager (FMan) support + Bogus blank line introduced at end of file? Why was this not in patch 1? It was added during the patch splitting. I'll fix that in the next submission, thank you for noticing. Igal. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v2,5/9] fsl/fman: Add Frame Manager support
Hi Scott, Thank you for your feedback, please take a look at my comments/questions. Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Friday, June 26, 2015 6:55 AM To: Liberman Igal-B31950 Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur Madalin- Cristian-B32716; pebo...@tiscali.nl Subject: Re: [v2,5/9] fsl/fman: Add Frame Manager support On Wed, 2015-06-24 at 22:35 +0300, igal.liber...@freescale.com wrote: From: Igal Liberman igal.liber...@freescale.com Add Frame Manger Driver support. This patch adds The FMan configuration, initialization and runtime control routines. Signed-off-by: Igal Liberman igal.liber...@freescale.com --- drivers/net/ethernet/freescale/fman/Kconfig| 35 + drivers/net/ethernet/freescale/fman/Makefile |2 +- drivers/net/ethernet/freescale/fman/fm.c | 1406 drivers/net/ethernet/freescale/fman/fm.h | 394 ++ drivers/net/ethernet/freescale/fman/fm_common.h| 142 ++ drivers/net/ethernet/freescale/fman/fm_drv.c | 701 ++ drivers/net/ethernet/freescale/fman/fm_drv.h | 116 ++ drivers/net/ethernet/freescale/fman/inc/enet_ext.h | 199 +++ drivers/net/ethernet/freescale/fman/inc/fm_ext.h | 488 +++ .../net/ethernet/freescale/fman/inc/fsl_fman_drv.h | 99 ++ drivers/net/ethernet/freescale/fman/inc/service.h | 55 + 11 files changed, 3636 insertions(+), 1 deletion(-) create mode 100644 drivers/net/ethernet/freescale/fman/fm.c create mode 100644 drivers/net/ethernet/freescale/fman/fm.h create mode 100644 drivers/net/ethernet/freescale/fman/fm_common.h create mode 100644 drivers/net/ethernet/freescale/fman/fm_drv.c create mode 100644 drivers/net/ethernet/freescale/fman/fm_drv.h create mode 100644 drivers/net/ethernet/freescale/fman/inc/enet_ext.h create mode 100644 drivers/net/ethernet/freescale/fman/inc/fm_ext.h create mode 100644 drivers/net/ethernet/freescale/fman/inc/fsl_fman_drv.h create mode 100644 drivers/net/ethernet/freescale/fman/inc/service.h Again, please start with something pared down, without extraneous features, but *with* enough functionality to actually pass packets around. Getting this thing into decent shape is going to be hard enough without carrying around the excess baggage. diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig index 825a0d5..12c75bfd 100644 --- a/drivers/net/ethernet/freescale/fman/Kconfig +++ b/drivers/net/ethernet/freescale/fman/Kconfig @@ -7,3 +7,38 @@ config FSL_FMAN Freescale Data-Path Acceleration Architecture Frame Manager (FMan) support +if FSL_FMAN + +config FSL_FM_MAX_FRAME_SIZE + int Maximum L2 frame size + range 64 9600 + default 1522 + help + Configure this in relation to the maximum possible MTU of your + network configuration. In particular, one would need to + increase this value in order to use jumbo frames. + FSL_FM_MAX_FRAME_SIZE must accommodate the Ethernet FCS + (4 bytes) and one ETH+VLAN header (18 bytes), to a total of + 22 bytes in excess of the desired L3 MTU. + + Note that having too large a FSL_FM_MAX_FRAME_SIZE (much larger + than the actual MTU) may lead to buffer exhaustion, especially + in the case of badly fragmented datagrams on the Rx path. + Conversely, having a FSL_FM_MAX_FRAME_SIZE smaller than the + actual MTU will lead to frames being dropped. Scatter gather can't be used for jumbo frames? Scatter gather is used, it's introduced in dpaa_eth as a separate patch from the basic support. The dpaa_eth can work in S/G mode or use large buffers, max frame size sized to reduce S/G overhead (performance vs memory used trade-off). Why is this a compile-time option? This is needed for a couple of reasons: - FMan resource sizing - we need to know the maximum frame size we plan to use for determining the Rx FIFO sizes at config time - There are issues when changing the MAC maximum frame size at runtime thus the need to set in HW the maximum allowable and compensate from sw (drop frames above the set MTU). + +config FSL_FM_RX_EXTRA_HEADROOM + int Add extra headroom at beginning of data buffers + range 16 384 + default 64 + help + Configure this to tell the Frame Manager to reserve some extra + space at the beginning of a data buffer on the receive path, + before Internal Context fields are copied. This is in addition + to the private data area already reserved for driver internal + use. The provided value must be a multiple of 16. + + This option does not affect in any way
RE: [v2,8/9] fsl/fman: Add FMan Port Support
Hi Paul,
All those exported functions are used by DPAA ETH driver, which was submitted
by Bucur Madalin (only fm_port_get_buffer_time_stamp() is not used currently,
I'll remove it).
Regards,
Igal Liberman.
-Original Message-
From: Paul Bolle [mailto:pebo...@tiscali.nl]
Sent: Friday, June 26, 2015 2:29 AM
To: Liberman Igal-B31950; net...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Bucur Madalin-
Cristian-B32716
Subject: Re: [v2,8/9] fsl/fman: Add FMan Port Support
On Wed, 2015-06-24 at 22:37 +0300, igal.liber...@freescale.com wrote:
--- a/drivers/net/ethernet/freescale/fman/fm_drv.c
+++ b/drivers/net/ethernet/freescale/fman/fm_drv.c
+struct fm_port_t *fm_port_drv_handle(const struct fm_port_drv_t
+*port) {
+ return port-fm_port;
+}
+EXPORT_SYMBOL(fm_port_drv_handle);
I couldn't find any users of this function.
+void fm_port_get_buff_layout_ext_params(struct fm_port_drv_t *port,
+ struct fm_port_params *params)
(Evolution 3.16 is a piece of ...).
+{
+ params-data_align = 0;
+}
+EXPORT_SYMBOL(fm_port_get_buff_layout_ext_params);
Ditto.
+int fm_get_tx_port_channel(struct fm_port_drv_t *port) {
+ return port-tx_ch;
+}
+EXPORT_SYMBOL(fm_get_tx_port_channel);
Ditto.
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/fm_port_drv.c
+void fm_set_rx_port_params(struct fm_port_drv_t *port,
+ struct fm_port_params *params)
+{
+ [...]
+}
+EXPORT_SYMBOL(fm_set_rx_port_params);
Ditto.
(If you hear about my arrest for randomly attacking innocent people:
blame evolution 3.16!)
+void fm_set_tx_port_params(struct fm_port_drv_t *port,
+ struct fm_port_params *params)
+{
+ [...]
+}
+EXPORT_SYMBOL(fm_set_tx_port_params);
Ditto.
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/port/fm_port.c
+u64 *fm_port_get_buffer_time_stamp(const struct fm_port_t
*p_fm_port,
+ char *p_data)
+{
+ [...]
+}
+EXPORT_SYMBOL(fm_port_get_buffer_time_stamp);
Ditto.
+int fm_port_disable(struct fm_port_t *p_fm_port) {
+ [...]
+}
+EXPORT_SYMBOL(fm_port_disable);
This exports a function that I think is only used inside this file.
+int fm_port_enable(struct fm_port_t *p_fm_port) {
+ [...]
+}
+EXPORT_SYMBOL(fm_port_enable);
And here I could again find no users of this function.
Thanks,
Paul Bolle
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 01/12] fsl/fman: Add the FMan FLIB headers
Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Wednesday, June 10, 2015 9:54 PM To: Bucur Madalin-Cristian-B32716 Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; Liberman Igal-B31950 Subject: Re: [PATCH 01/12] fsl/fman: Add the FMan FLIB headers On Wed, 2015-06-10 at 18:21 +0300, Madalin Bucur wrote: From: Igal Liberman igal.liber...@freescale.com This patch presents the FMan Foundation Libraries (FLIB) headers. The FMan FLib provides the basic API used by the FMan drivers to configure and control the FMan hardware. Signed-off-by: Igal Liberman igal.liber...@freescale.com --- .../ethernet/freescale/fman/flib/common/general.h | 41 ++ .../net/ethernet/freescale/fman/flib/fsl_fman.h| 609 + 2 files changed, 650 insertions(+) create mode 100644 drivers/net/ethernet/freescale/fman/flib/common/general.h create mode 100644 drivers/net/ethernet/freescale/fman/flib/fsl_fman.h Why do we need separate patches just for headers? We wanted to make the patches smaller, it's the main reason for this separation. What does common refer to? I removed ./flib/common. What does the flib directory mean, in the context of Linux? If someone were to add code to this driver, how do they know if the code should go into the flib directory or not? +#define iowrite32be(val, addr) out_be32((*addr), val) +#define ioread32be(addr) in_be32((*addr)) iowrite32be()/ioread32be() are already defined for all relevant architectures. Why are you redefining them into something PPC- specific? Removed those. +/* do not change! if changed, must be disabled for rev1 ! */ #define +DEFAULT_HALT_ON_EXTERNAL_ACTIVATION false +/* do not change! if changed, must be disabled for rev1 ! */ #define +DEFAULT_HALT_ON_UNRECOVERABLE_ECC_ERROR false rev1 of what chip? P4080. I'll update the comments. -Scott Igal. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 08/12] fsl/fman: Add Frame Manager support
Hi Paul,
Thank you very much for your feedback.
I'm planning to address the issues you've raised in the next submission.
Regards,
Igal Liberman.
-Original Message-
From: Paul Bolle [mailto:pebo...@tiscali.nl]
Sent: Thursday, June 11, 2015 12:38 PM
To: Bucur Madalin-Cristian-B32716
Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; Wood Scott-B07421; Liberman Igal-B31950
Subject: Re: [PATCH 08/12] fsl/fman: Add Frame Manager support
So I couldn't help having yet another look at the code, just to drive home my
point.
On Thu, 2015-06-11 at 10:55 +0200, Paul Bolle wrote:
+void *fm_drv_init(void)
static.
+{
+ memset(fm_drvs, 0, sizeof(fm_drvs));
fm_drvs is an external variable. It is guaranteed to be zero, isn't it?
+ mutex_init(fm_drv_mutex);
+
+ /* Register to the DTB for basic FM API */
+ platform_driver_register(fm_driver);
+
+ return fm_drvs;
You're returning a pointer to external variable. How's that useful?
And note this is the last time we'll ever see fm_drvs. So I think that all
this
variable does for the code is getting initialized to zero, twice.
+}
+
+int fm_drv_free(void *p_fm_drv)
static.
+{
+ platform_driver_unregister(fm_driver);
+ mutex_destroy(fm_drv_mutex);
+
+ return 0;
This function has one caller, which doesn't check the return value. So this
should be a function returning void. Of course, a wrapper of two lines called
only once means you should actually not put this into a separate function.
+}
+static void *p_fm_drv;
+static int __init __cold fm_load(void) {
+ p_fm_drv = fm_drv_init();
+ if (!p_fm_drv) {
fm_drv_init() returns a pointer to an external variable. So how can this
happen?
+ pr_err(Failed to init FM wrapper!\n);
+ return -ENODEV;
+ }
+
+ pr_info(Freescale FM module\n);
+ return 0;
+}
This is all rather basic. It must be, otherwise I wouldn't spot it.
So I keep spotting these basic oddities, with every cup of coffee I treat
myself to while reading through this, wherever I look. By now I'm sure
there's no need for the netdev people to look at this, not yet.
Paul Bolle
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl: Add FMan best effort port compatible
Hi Scott, I understand your point, let me please explain more about the hardware configuration and suggest another solution. I'm referring only to external ports (TX/RX), not OP. In FMan V3 we have maximum of 8 Port, it depends on the FMan revision (in B4, T2, T4 we have 8 ports, in T1024 and T1040 we have 4). The following configuration are valid: - All 8 ports can work as 1G ports. - Ports 7, 8 (if available) can work as 10G (with full hardware resources). - Port 1, 2 (1 in T1024; 1, 2 in T2080) can be configured as 10G (with limited hardware resources). Currently we use only fsl,fm-v3-port-rx/tx. We can go 2 ways: 1. Having 2 compatibles: fsl,fman-v3-port-rx/tx fsl,fman-v3-best-effort-port-rx/tx The driver can determine the port type of fsl,fman-v3-port-rx/tx by reading the HW port id. fsl,fman-v3-best-effort-port-rx/tx will let the driver know about the best effort port and it will be used instead of fsl,fman-v3-port-rx/tx. In your opinion, should we add fsl,fman-v3-10g-port-rx/tx for 10G (with full hardware resources)? In such chase, fsl,fman-v3-port-rx/tx will denote 1G explicitly. In FMan V2, dual ports/MACs are not available, so no need change the compatibles. Igal -Original Message- From: Wood Scott-B07421 Sent: Tuesday, May 19, 2015 12:09 AM To: Liberman Igal-B31950 Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur Madalin-Cristian-B32716 Subject: Re: [PATCH] powerpc/fsl: Add FMan best effort port compatible On Mon, 2015-05-18 at 11:41 +0300, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com This patch adds a compatible which represents FMan V3 best effort ports. FMan best effort port is configured as 10G ports, however, it uses 1G hardware. Signed-off-by: Igal Liberman igal.liber...@freescale.com --- .../devicetree/bindings/powerpc/fsl/fman.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt index edda55f..c2e3ec3 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt @@ -166,6 +166,11 @@ PROPERTIES - fsl,fman-v3-port-oh for FManV3 OH ports - fsl,fman-v3-port-rx for FManV3 RX ports - fsl,fman-v3-port-tx for FManV3 TX ports + Optional compatible which can be used in addition to the + compatibles above is: + - fsl,fman-v3-best-effort-port + This compatible represents 10G best effort ports: + Port configured as 10G, using 1G hardware. What does this mean? If it's using 1G hardware then it's a 1G port, right? How can you configure a 1G port to be 10G? Why is this compatible in addition to others (note that this implies such ports are 100% backwards compatible with hardware that lacks the new compatible)? You'd have the same compatible on rx and tx nodes (I'm assuming this isn't applicable to oh)? What are the implications of this that warrant adding a compatible? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
