RE: [PATCH -next] soc: fsl: qe: use DEFINE_SPINLOCK() for spinlock

[Leo Li]

> -Original Message-
> From: Ye Bin 
> Sent: Friday, April 9, 2021 4:52 AM
> To: yebi...@huawei.com; Qiang Zhao ; Leo Li
> 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org; Hulk Robot
> 
> Subject: [PATCH -next] soc: fsl: qe: use DEFINE_SPINLOCK() for spinlock
> 
> spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than
> explicitly calling spin_lock_init().

The previous version has been applied.  Thanks.

> 
> Reported-by: Hulk Robot 
> Signed-off-by: Ye Bin 
> ---
>  drivers/soc/fsl/qe/qe_common.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/fsl/qe/qe_common.c
> b/drivers/soc/fsl/qe/qe_common.c index 654e9246ce6b..a0cb8e746879
> 100644
> --- a/drivers/soc/fsl/qe/qe_common.c
> +++ b/drivers/soc/fsl/qe/qe_common.c
> @@ -26,7 +26,7 @@
>  #include 
> 
>  static struct gen_pool *muram_pool;
> -static spinlock_t cpm_muram_lock;
> +static DEFINE_SPINLOCK(cpm_muram_lock);
>  static void __iomem *muram_vbase;
>  static phys_addr_t muram_pbase;
> 
> @@ -54,7 +54,6 @@ int cpm_muram_init(void)
>   if (muram_pbase)
>   return 0;
> 
> - spin_lock_init(_muram_lock);
>   np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
>   if (!np) {
>   /* try legacy bindings */

RE: [PATCH v6] soc: fsl: enable acpi support in RCPM driver

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Tuesday, April 6, 2021 8:32 PM
> To: Leo Li 
> Cc: Christophe Leroy ; linuxppc-dev
> ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ; lkml  ker...@vger.kernel.org>
> Subject: RE: [PATCH v6] soc: fsl: enable acpi support in RCPM driver
> 
> Hi Leo,
> 
> On Wednesday, April 7, 2021 5:45 AM, Li Yang wrote:
> >
> > On Fri, Mar 12, 2021 at 2:56 AM Ran Wang  wrote:
> > >
> > > From: Peng Ma 
> > >
> > > This patch enables ACPI support in RCPM driver.
> > >
> > > Signed-off-by: Peng Ma 
> > > Signed-off-by: Ran Wang 
> > > ---
> > > Change in v6:
> > >  - Remove copyright udpate to rebase on latest mainline
> > >
> > > Change in v5:
> > >  - Fix panic when dev->of_node is null
> > >
> > > Change in v4:
> > >  - Make commit subject more accurate
> > >  - Remove unrelated new blank line
> > >
> > > Change in v3:
> > >  - Add #ifdef CONFIG_ACPI for acpi_device_id
> > >  - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
> > >
> > > Change in v2:
> > >  - Update acpi_device_id to fix conflict with other driver
> > >
> > >  drivers/soc/fsl/rcpm.c | 18 --
> > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> > > 4ace28cab314..7aa997b932d1 100644
> > > --- a/drivers/soc/fsl/rcpm.c
> > > +++ b/drivers/soc/fsl/rcpm.c
> > > @@ -13,6 +13,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #define RCPM_WAKEUP_CELL_MAX_SIZE  7
> > >
> > > @@ -78,10 +79,14 @@ static int rcpm_pm_prepare(struct device *dev)
> > > "fsl,rcpm-wakeup", value,
> > > rcpm->wakeup_cells + 1);
> > >
> > > -   /*  Wakeup source should refer to current rcpm device */
> > > -   if (ret || (np->phandle != value[0]))
> > > +   if (ret)
> > > continue;
> > >
> > > +   if (is_of_node(dev->fwnode))
> > > +   /*  Should refer to current rcpm device */

Better to be /* Only handle devices with fsl,rcpm-wakeup pointing to the 
current rcpm node*/
> > > +   if (np->phandle != value[0])
> > > +   continue;
> >
> > It looks like that we assume that in the ACPI scenario there will only
> > be one RCPM controller and all devices are controlled by this single
> > PM controller.  This probably is true for all existing SoCs with a RCPM.  
> > But
> since the driver tried to support multiple RCPMs, maybe we should continue
> to support multiple RCPM controllers or at least mention that in the
> comment.
> 
> How about adding some comment as below:
> 
> /* For ACPI mode, currently we assume there is only one RCPM controller
> existing */

Ok.  On the other hand, it will be clearer to update the existing comment above.

> 
> Regards,
> Ran
> 
> >
> > > +
> > > /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines 
> > > the
> > >  * number of IPPDEXPCR register cells, and 
> > > "fsl,rcpm-wakeup"
> > >  * of wakeup source IP contains an integer array:
> > >  > > rcpm_of_match[] = {  };  MODULE_DEVICE_TABLE(of, rcpm_of_match);
> > >
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id rcpm_acpi_ids[] = {
> > > +   {"NXP0015",},
> > > +   { }
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids); #endif
> > > +
> > >  static struct platform_driver rcpm_driver = {
> > > .driver = {
> > > .name = "rcpm",
> > > .of_match_table = rcpm_of_match,
> > > +   .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
> > > .pm = _pm_ops,
> > > },
> > > .probe = rcpm_probe,
> > > --
> > > 2.25.1
> > >

RE: [PATCH 03/15] dt-bindings: memory: fsl: convert ifc binding to yaml schema

[Leo Li]

> -Original Message-
> From: Rob Herring 
> Sent: Monday, February 8, 2021 12:21 PM
> To: Leo Li 
> Cc: linux-arm-ker...@lists.infradead.org; Oleksij Rempel  privat.de>; Krzysztof Kozlowski ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Shawn Guo
> 
> Subject: Re: [PATCH 03/15] dt-bindings: memory: fsl: convert ifc binding to
> yaml schema
> 
> On Mon, Feb 08, 2021 at 05:07:14PM +, Leo Li wrote:
> >
> >
> > > -Original Message-
> > > From: Rob Herring 
> > > Sent: Monday, February 8, 2021 10:55 AM
> > > To: Leo Li 
> > > Cc: linux-arm-ker...@lists.infradead.org; Oleksij Rempel
> > > ; Rob Herring ;
> > > Krzysztof Kozlowski ; devicet...@vger.kernel.org;
> > > linux- ker...@vger.kernel.org; Shawn Guo 
> > > Subject: Re: [PATCH 03/15] dt-bindings: memory: fsl: convert ifc
> > > binding to yaml schema
> > >
> > > On Fri, 05 Feb 2021 17:47:22 -0600, Li Yang wrote:
> > > > Convert the txt binding to yaml format and add description.  Also
> > > > updated the recommended node name to ifc-bus to align with the
> > > > simple-bus node name requirements.
> > > >
> > > > Signed-off-by: Li Yang 
> > > > ---
> > > >  .../bindings/memory-controllers/fsl/ifc.txt   |  82 --
> > > >  .../bindings/memory-controllers/fsl/ifc.yaml  | 140
> > > > ++
> > > >  2 files changed, 140 insertions(+), 82 deletions(-)  delete mode
> > > > 100644
> > > > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > >  create mode 100644
> > > > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.yaml
> > > >
> > >
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > Documentation/devicetree/bindings/memory-
> > > controllers/fsl/ifc.example.dts:36.27-49.19: Warning (simple_bus_reg):
> > > /example-0/soc/ifc-bus@ffe1e000/flash@0,0: simple-bus unit address
> > > format error, expected "0"
> > > Documentation/devicetree/bindings/memory-
> > > controllers/fsl/ifc.example.dts:51.27-64.19: Warning (simple_bus_reg):
> > > /example-0/soc/ifc-bus@ffe1e000/flash@1,0: simple-bus unit address
> > > format error, expected "1"
> > > Documentation/devicetree/bindings/memory-
> > > controllers/fsl/ifc.example.dts:66.26-71.19: Warning (simple_bus_reg):
> > > /example-0/soc/ifc-bus@ffe1e000/cpld@3,0: simple-bus unit address
> > > format error, expected "3"
> >
> > Hi Rob,
> >
> > I saw these warnings, but cannot find a good solution to it.  The
> > first cell in the address is the Chip select, while the second cell in
> > the address is the address offset within the chip select.  It would
> > confusing to combine the two cells of different purposes into a single
> > address as suggested by the warning.  Can we allow the multi-cell
> > address in the node name?
> 
> Drop 'simple-bus'. It's not a simple bus. You have registers that presumably
> have some configuration needed.

That's probably true for just using "simple-bus" as compatible along.  But I 
see many of the current bindings are defining a more specific compatible string 
in addition to the "simple-bus" compatible and have their own drivers.  I think 
this probably meet the statement in the device tree spec? "Bindings may be 
defined as extensions of other each. For example a new bus type could be 
defined as an extension of the
simple-bus binding."

Regards,
Leo

RE: [PATCH 03/15] dt-bindings: memory: fsl: convert ifc binding to yaml schema

[Leo Li]

> -Original Message-
> From: Rob Herring 
> Sent: Monday, February 8, 2021 10:55 AM
> To: Leo Li 
> Cc: linux-arm-ker...@lists.infradead.org; Oleksij Rempel  privat.de>; Rob Herring ; Krzysztof Kozlowski
> ; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Shawn Guo 
> Subject: Re: [PATCH 03/15] dt-bindings: memory: fsl: convert ifc binding to
> yaml schema
> 
> On Fri, 05 Feb 2021 17:47:22 -0600, Li Yang wrote:
> > Convert the txt binding to yaml format and add description.  Also
> > updated the recommended node name to ifc-bus to align with the
> > simple-bus node name requirements.
> >
> > Signed-off-by: Li Yang 
> > ---
> >  .../bindings/memory-controllers/fsl/ifc.txt   |  82 --
> >  .../bindings/memory-controllers/fsl/ifc.yaml  | 140
> > ++
> >  2 files changed, 140 insertions(+), 82 deletions(-)  delete mode
> > 100644
> > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> >  create mode 100644
> > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.yaml
> >
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/memory-
> controllers/fsl/ifc.example.dts:36.27-49.19: Warning (simple_bus_reg):
> /example-0/soc/ifc-bus@ffe1e000/flash@0,0: simple-bus unit address
> format error, expected "0"
> Documentation/devicetree/bindings/memory-
> controllers/fsl/ifc.example.dts:51.27-64.19: Warning (simple_bus_reg):
> /example-0/soc/ifc-bus@ffe1e000/flash@1,0: simple-bus unit address
> format error, expected "1"
> Documentation/devicetree/bindings/memory-
> controllers/fsl/ifc.example.dts:66.26-71.19: Warning (simple_bus_reg):
> /example-0/soc/ifc-bus@ffe1e000/cpld@3,0: simple-bus unit address format
> error, expected "3"

Hi Rob,

I saw these warnings, but cannot find a good solution to it.  The first cell in 
the address is the Chip select, while the second cell in the address is the 
address offset within the chip select.  It would confusing to combine the two 
cells of different purposes into a single address as suggested by the warning.  
Can we allow the multi-cell address in the node name?

Regards,
Leo 

RE: drivers/net/ethernet/freescale/gianfar.c:580 gfar_parse_group() warn: 'grp->regs' not released on lines: 517.

[Leo Li]

> -Original Message-
> From: Dan Carpenter 
> Sent: Monday, November 16, 2020 3:25 AM
> To: kbu...@lists.01.org; Rasmus Villemoes 
> Cc: l...@intel.com; Dan Carpenter ; kbuild-
> a...@lists.01.org; linux-kernel@vger.kernel.org; Leo Li ;
> Timur Tabi 
> Subject: drivers/net/ethernet/freescale/gianfar.c:580 gfar_parse_group()
> warn: 'grp->regs' not released on lines: 517.
> 
> Hi Rasmus,
> 
> First bad commit (maybe != root cause):
> 
> tree:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke
> rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git
> mp;data=04%7C01%7Cleoyang.li%40nxp.com%7Cfcd86334161e4c85f12408d8
> 8a11d649%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6374111565
> 08189838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Zvr6xt8Ew
> NKnUbBs1NMdnLf8xfeYbDGy1yASNs21pKU%3Dreserved=0 master
> head:   f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
> commit: 5a35435ef4e6e4bd2aabd6706b146b298a9cffe5 soc: fsl: qe: remove
> PPC32 dependency from CONFIG_QUICC_ENGINE

It is strange that this driver is not related to the commit above.

> config: powerpc64-randconfig-m031-20201113 (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 
> 
> smatch warnings:
> drivers/net/ethernet/freescale/gianfar.c:580 gfar_parse_group() warn: 'grp-
> >regs' not released on lines: 517.
> 
> vim +580 drivers/net/ethernet/freescale/gianfar.c
> 
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  491  static int gfar_parse_group(struct device_node *np,
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  492   struct gfar_private *priv, const char 
> *model)
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  493  {
> 5fedcc14d40e355 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  494   struct gfar_priv_grp *grp = >gfargrp[priv-
> >num_grps];
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  495   int i;
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  496
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  497   for (i = 0; i < GFAR_NUM_IRQS; i++) {
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  498   grp->irqinfo[i] = kzalloc(sizeof(struct
> gfar_irqinfo),
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  499 GFP_KERNEL);
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  500   if (!grp->irqinfo[i])
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  501   return -ENOMEM;
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  502   }
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  503
> 5fedcc14d40e355 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  504   grp->regs = of_iomap(np, 0);
>   
>   ^^^
> 
> 5fedcc14d40e355 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  505   if (!grp->regs)
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  506   return -ENOMEM;
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  507
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  508   gfar_irq(grp, TX)->irq = irq_of_parse_and_map(np,
> 0);
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  509
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  510   /* If we aren't the FEC we have multiple interrupts */
> 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> 2009-11-
> 02  511   if (model && strcasecmp(model, "FEC")) {
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> 2013-01-29  512   gfar_irq(grp, RX)->irq =
> irq_of_parse_and_map(np, 1);
> ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c 

RE: [PATCH 11/25] soc: fsl: qe: qe_common: Fix misnamed function attribute 'addr'

[Leo Li]

> -Original Message-
> From: Lee Jones 
> Sent: Thursday, November 12, 2020 4:33 AM
> To: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> Qiang Zhao ; Leo Li ; Scott
> Wood ; act ; Dan Malek
> ; Software, Inc ; Vitaly
> Bordug ; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH 11/25] soc: fsl: qe: qe_common: Fix misnamed function
> attribute 'addr'
> 
> On Tue, 03 Nov 2020, Lee Jones wrote:
> 
> > Fixes the following W=1 kernel build warning(s):
> >
> >  drivers/soc/fsl/qe/qe_common.c:237: warning: Function parameter or
> member 'addr' not described in 'cpm_muram_dma'
> >  drivers/soc/fsl/qe/qe_common.c:237: warning: Excess function parameter
> 'offset' description in 'cpm_muram_dma'
> >
> > Cc: Qiang Zhao 
> > Cc: Li Yang 
> > Cc: Scott Wood 
> > Cc: act 
> > Cc: Dan Malek 
> > Cc: "Software, Inc" 
> > Cc: Vitaly Bordug 
> > Cc: linuxppc-...@lists.ozlabs.org
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/soc/fsl/qe/qe_common.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/fsl/qe/qe_common.c
> > b/drivers/soc/fsl/qe/qe_common.c index 75075591f6308..497a7e0fd0272
> > 100644
> > --- a/drivers/soc/fsl/qe/qe_common.c
> > +++ b/drivers/soc/fsl/qe/qe_common.c
> > @@ -231,7 +231,7 @@ EXPORT_SYMBOL(cpm_muram_offset);
> >
> >  /**
> >   * cpm_muram_dma - turn a muram virtual address into a DMA address
> > - * @offset: virtual address from cpm_muram_addr() to convert
> > + * @addr: virtual address from cpm_muram_addr() to convert
> >   */
> >  dma_addr_t cpm_muram_dma(void __iomem *addr)  {
> 
> Any idea who will pick this up?

I can pick them up through my tree, but I haven't created the for-next branch 
for the next kernel yet.  Will look through this series soon.  Thanks.

> 
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services Linaro.org │ Open source
> software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog

RE: [PATCH v2 5/5] arm64: dts: lx2160a: fix FlexSPI clock

[Leo Li]

> -Original Message-
> From: Michael Walle 
> Sent: Thursday, November 5, 2020 1:35 PM
> To: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Cc: Michael Turquette ; Stephen Boyd
> ; Rob Herring ; Shawn Guo
> ; Leo Li ; Michael Walle
> 
> Subject: [PATCH v2 5/5] arm64: dts: lx2160a: fix FlexSPI clock
> 
> Now that we have a proper driver for the FlexSPI interface use it. This will 
> fix
> SCK frequency switching on Layerscape SoCs.
> 
> This was only compile time tested.
> 
> Signed-off-by: Michael Walle 
> ---
> Changes since v1:
>  - none
> 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index 83072da6f6c6..6e375e80bd35 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -659,9 +659,20 @@
>   };
> 
>   dcfg: syscon@1e0 {
> - compatible = "fsl,lx2160a-dcfg", "syscon";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,lx2160a-dcfg", "syscon", "simple-
> mfd";
>   reg = <0x0 0x1e0 0x0 0x1>;
> + ranges = <0x0 0x0 0x1e0 0x1>;
>   little-endian;
> +
> + fspi_clk: clock-controller@900 {
> + compatible = "fsl,lx2160a-flexspi-clk";
> + reg = <0x900 0x4>;
> + #clock-cells = <0>;
> + clocks = < 4 0>;

This is different from the current < 4 3>, is it an intended change?

> + clock-output-names = "fspi_clk";
> + };
>   };
> 
>   tmu: tmu@1f8 {
> @@ -776,7 +787,7 @@
> <0x0 0x2000 0x0 0x1000>;
>   reg-names = "fspi_base", "fspi_mmap";
>   interrupts = ;
> - clocks = < 4 3>, < 4 3>;
> + clocks = < 4 3>, <_clk>;
>   clock-names = "fspi_en", "fspi";
>   status = "disabled";
>   };
> --
> 2.20.1

RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt

[Leo Li]

> -Original Message-
> From: Rasmus Villemoes 
> Sent: Tuesday, November 3, 2020 2:03 AM
> To: Leo Li ; Biwen Li (OSS) ;
> shawn...@kernel.org; robh...@kernel.org; mark.rutl...@arm.com; Z.q.
> Hou ; t...@linutronix.de; ja...@lakedaemon.net;
> m...@kernel.org
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiafei Pan
> ; Xiaobo Xie ; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A
> external interrupt
> 
> On 02/11/2020 22.22, Leo Li wrote:
> >>>
> >>> Where did you get this information that the register on LS1043 and
> >>> LS1046 is bit reversed?  I cannot find such information in the RM.
> >>> And does this mean all other SCFG registers are also bit reversed?
> >>> If this is some information that is not covered by the RM, we
> >>> probably should clarify it in the code and the commit message.
> >> Hi Leo,
> >>
> >> I directly use the same logic to write the bit(field IRQ0~11INTP) of
> >> the register SCFG_INTPCR in LS1043A and LS1046A.
> >> Such as,
> >> if I want to control the polarity of IRQ0(field IRQ0INTP, IRQ0 is
> >> active low) of LS1043A/LS1046A, then I just need write a value 1 << (31 - 
> >> 0)
> to it.
> >> The logic depends on register's definition in LS1043A/LS1046A's RM.
> >
> > Ok.  The SCFG_SCFGREVCR seems to be a one-off fixup only existed on
> LS1021.  And it is mandatory to be bit_reversed according to the RM which is
> already taken care of in the RCW.  So the bit reversed case should be the only
> case supported otherwise a lot of other places for SCFG access should be
> failed.
> >
> > I think we should remove the bit_reverse thing all together from the driver
> for good.  This will prevent future confusion.  Rasmus, what do you think?
> 
> Yes, all the ls1021a-derived boards I know of do have something like
> 
> # Initialize bit reverse of SCFG registers
> 09570200 
> 
> in their pre-boot-loader config file. And yes, the RM does say
> 
>   This register must be written 0x_ as a part of
>   initialization sequence before writing to any other SCFG
>   register.
> 
> but nowhere does it say "or else...", nor a little honest addendum "because
> we accidentally released broken silicon with this misfeature _and_ wrong
> POR value".

Yeah.  I do think they messed up at the beginning when trying to integrate the 
big endian registers on little endian core.  It is good that we are doing it 
correctly in later SoCs.

> 
> Can we have an official statement from NXP stating that SCFGREVCR is a
> hardware design bug? And can you send it through a time-machine so I had it
> three years ago avoiding the whole "fsl,bit-reverse device-tree-property, no,
> read the register if you're on a ls1021a and decide" hullabaloo.

I'm not sure if it is possible to update the related documents right now for 
this.  But definitely it was not your fault to have introduced this in the 
driver due to the confusion from document.  My suggestion to remove it is just 
to prevent this from causing more confusions in the future as this driver is 
used on more SoCs.

Regards,
Leo

RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt

[Leo Li]

> -Original Message-
> From: Biwen Li (OSS) 
> Sent: Monday, November 2, 2020 12:15 AM
> To: Leo Li ; Rasmus Villemoes
> ; Biwen Li (OSS) ;
> shawn...@kernel.org; robh...@kernel.org; mark.rutl...@arm.com; Z.q.
> Hou ; t...@linutronix.de; ja...@lakedaemon.net;
> m...@kernel.org
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiafei Pan
> ; Xiaobo Xie ; linux-arm-
> ker...@lists.infradead.org
> Subject: RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A
> external interrupt
> 
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On 27/10/2020 05.46, Biwen Li wrote:
> > > > > From: Hou Zhiqiang 
> > > > >
> > > > > Add an new IRQ chip declaration for LS1043A and LS1088A
> > > > > - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
> > SCFG_INTPCR[31:0]
> > > > >   of these SoCs is stored/read as SCFG_INTPCR[0:31] defaultly(bit
> > > > >   reverse)
> > > >
> > > > s/defaultly/by default/ I suppose. But what does that mean? Is it
> > > > still configurable, just now through some undocumented register?
> > > > If that register still exists, does it now have a reset value of
> > > > all-ones as opposed to the ls1021 case? If it's not configurable,
> > > > then describing the situation as "by default" is confusing and
> > > > wrong, it should just say "On LS1043A, LS1046A, SCFG_INTPCR is
> > > > stored/read bit-
> > > reversed."
> > > Okay, got it. Will update it in v3. Thanks.
> >
> > Hi Biwen,
> >
> > Where did you get this information that the register on LS1043 and
> > LS1046 is bit reversed?  I cannot find such information in the RM.
> > And does this mean all other SCFG registers are also bit reversed?  If
> > this is some information that is not covered by the RM, we probably
> > should clarify it in the code and the commit message.
> Hi Leo,
> 
> I directly use the same logic to write the bit(field IRQ0~11INTP) of the
> register SCFG_INTPCR in LS1043A and LS1046A.
> Such as,
> if I want to control the polarity of IRQ0(field IRQ0INTP, IRQ0 is active low) 
> of
> LS1043A/LS1046A, then I just need write a value 1 << (31 - 0) to it.
> The logic depends on register's definition in LS1043A/LS1046A's RM.

Ok.  The SCFG_SCFGREVCR seems to be a one-off fixup only existed on LS1021.  
And it is mandatory to be bit_reversed according to the RM which is already 
taken care of in the RCW.  So the bit reversed case should be the only case 
supported otherwise a lot of other places for SCFG access should be failed.

I think we should remove the bit_reverse thing all together from the driver for 
good.  This will prevent future confusion.  Rasmus, what do you think?

Regards,
Leo

> 
> Regards,
> Biwen
> 
> >
> > Regards,
> > Leo
> >
> > > >
> > > >
> > > > > - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
> > > > >
> > > > > Signed-off-by: Hou Zhiqiang 
> > > > > Signed-off-by: Biwen Li 
> > > > > ---
> > > > > Change in v2:
> > > > >   - add despcription of bit reverse
> > > > >   - update copyright
> > > > >
> > > > >  drivers/irqchip/irq-ls-extirq.c | 10 +-
> > > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/irqchip/irq-ls-extirq.c
> > > > > b/drivers/irqchip/irq-ls-extirq.c index
> > > > > 4d1179fed77c..9587bc2607fc
> > > > > 100644
> > > > > --- a/drivers/irqchip/irq-ls-extirq.c
> > > > > +++ b/drivers/irqchip/irq-ls-extirq.c
> > > > > @@ -1,5 +1,8 @@
> > > > >  // SPDX-License-Identifier: GPL-2.0
> > > > > -
> > > > > +/*
> > > > > + * Author: Rasmus Villemoes 
> > > >
> > > > If I wanted my name splattered all over the files I touch or add,
> > > > I'd add it myself, TYVM. The git history is plenty fine for
> > > > recording authorship as far as I'm concerned, and I absolutely
> > > > abhor having to skip over any kind of legalese boilerplate when opening
> a file.
> > > Okay, got it. Will drop it in v3. Thanks.
> > > >
> > > > Rasmus

RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt

[Leo Li]

> -Original Message-
> From: Biwen Li 
> Sent: Tuesday, October 27, 2020 2:48 AM
> To: Rasmus Villemoes ; Biwen Li (OSS)
> ; shawn...@kernel.org; robh...@kernel.org;
> mark.rutl...@arm.com; Leo Li ; Z.q. Hou
> ; t...@linutronix.de; ja...@lakedaemon.net;
> m...@kernel.org
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiafei Pan
> ; Xiaobo Xie ; linux-arm-
> ker...@lists.infradead.org
> Subject: RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A
> external interrupt
> 
> >
> > Caution: EXT Email
> >
> > On 27/10/2020 05.46, Biwen Li wrote:
> > > From: Hou Zhiqiang 
> > >
> > > Add an new IRQ chip declaration for LS1043A and LS1088A
> > > - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A. SCFG_INTPCR[31:0]
> > >   of these SoCs is stored/read as SCFG_INTPCR[0:31] defaultly(bit
> > >   reverse)
> >
> > s/defaultly/by default/ I suppose. But what does that mean? Is it
> > still configurable, just now through some undocumented register? If
> > that register still exists, does it now have a reset value of all-ones
> > as opposed to the ls1021 case? If it's not configurable, then
> > describing the situation as "by default" is confusing and wrong, it
> > should just say "On LS1043A, LS1046A, SCFG_INTPCR is stored/read bit-
> reversed."
> Okay, got it. Will update it in v3. Thanks.

Hi Biwen,

Where did you get this information that the register on LS1043 and LS1046 is 
bit reversed?  I cannot find such information in the RM.  And does this mean 
all other SCFG registers are also bit reversed?  If this is some information 
that is not covered by the RM, we probably should clarify it in the code and 
the commit message.

Regards,
Leo

> >
> >
> > > - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
> > >
> > > Signed-off-by: Hou Zhiqiang 
> > > Signed-off-by: Biwen Li 
> > > ---
> > > Change in v2:
> > >   - add despcription of bit reverse
> > >   - update copyright
> > >
> > >  drivers/irqchip/irq-ls-extirq.c | 10 +-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/irqchip/irq-ls-extirq.c
> > > b/drivers/irqchip/irq-ls-extirq.c index 4d1179fed77c..9587bc2607fc
> > > 100644
> > > --- a/drivers/irqchip/irq-ls-extirq.c
> > > +++ b/drivers/irqchip/irq-ls-extirq.c
> > > @@ -1,5 +1,8 @@
> > >  // SPDX-License-Identifier: GPL-2.0
> > > -
> > > +/*
> > > + * Author: Rasmus Villemoes 
> >
> > If I wanted my name splattered all over the files I touch or add, I'd
> > add it myself, TYVM. The git history is plenty fine for recording
> > authorship as far as I'm concerned, and I absolutely abhor having to
> > skip over any kind of legalese boilerplate when opening a file.
> Okay, got it. Will drop it in v3. Thanks.
> >
> > Rasmus

RE: [RESEND 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt

[Leo Li]

> -Original Message-
> From: Marc Zyngier 
> Sent: Monday, October 26, 2020 4:23 AM
> To: Rasmus Villemoes 
> Cc: Biwen Li (OSS) ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Leo Li ;
> Z.q. Hou ; t...@linutronix.de;
> ja...@lakedaemon.net; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Jiafei Pan ; Xiaobo Xie
> ; linux-arm-ker...@lists.infradead.org; Biwen Li
> 
> Subject: Re: [RESEND 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external
> interrupt
> 
> On 2020-10-26 09:06, Rasmus Villemoes wrote:
> > On 26/10/2020 09.44, Marc Zyngier wrote:
> >> On 2020-10-26 08:01, Biwen Li wrote:
> >>> From: Hou Zhiqiang 
> >>>
> >>> Add an new IRQ chip declaration for LS1043A and LS1088A
> >>> - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A
> >>> - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
> >>
> >> Three things:
> >> - This commit message doesn't describe the bit_reverse change
> >
> > Yeah, please elaborate on that, as the RM for 1043 or 1046 doesn't
> > mention anything about bit reversal for the scfg registers - they
> > don't seem to have the utter nonsense that is SCFG_SCFGREVCR, but
> > perhaps, instead of removing it, that has just become a hard-coded
> > part of the IP.
> >
> > Also, IANAL etc., but
> >
> >>> +// Copyright 2019-2020 NXP
> >
> > really? Seems to be a bit of a stretch.
> >
> > At the very least, cc'ing the original author and only person to ever
> > touch that file would have been appreciated.
> 
> Huh. Well spotted. That's definitely not on.
> NXP people, please talk to your legal department.

We do have an internal policy to require developer adding/updating NXP 
copyright on non-trivial changes.  I'm not sure if this change should be 
considered trivial, but adding copyright claim on a file without prior 
copyright claims could causing confusion like in this case.  One potential 
solution is to add a more specific description on the NXP change together with 
the copyright claim.  But maybe an easier solution is to add Rasmus your 
Copyright claim first if you are ok with it.

Regards,
Leo

RE: [PATCH v3 2/2] arm64: dts: lx2160a: add device tree for lx2162aqds board

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Monday, October 26, 2020 2:19 AM
> To: Meenakshi Aggarwal 
> Cc: robh...@kernel.org; Varun Sethi ; Leo Li
> ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ioana Ciornei
> ; Kuldeep Singh 
> Subject: Re: [PATCH v3 2/2] arm64: dts: lx2160a: add device tree for
> lx2162aqds board
> 
> On Mon, Oct 19, 2020 at 09:00:33AM +, Meenakshi Aggarwal wrote:
> > Hi,
> >
> > Any further comments?
> 
> Please address the following checkpatch warnings.
> 
> WARNING: DT compatible string "nxp,lx2162a-qds" appears un-documented
> -- check ./Documentation/devicetree/bindings/
> #49: FILE: arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts:13:
> + compatible = "nxp,lx2162a-qds", "fsl,lx2160a";
> 
> WARNING: DT compatible string "ethernet-phy-id001c.c916" appears un-
> documented -- check ./Documentation/devicetree/bindings/
> #80: FILE: arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts:44:
> + compatible = "ethernet-phy-id001c.c916";

Interesting that it doesn't match the following in 
Documentation/devicetree/bindings/net/ethernet-phy.yaml

  - pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
description:
  If the PHY reports an incorrect ID (or none at all) then the
  compatible list may contain an entry with the correct PHY ID
  in the above form.
  The first group of digits is the 16 bit Phy Identifier 1
  register, this is the chip vendor OUI bits 3:18. The
  second group of digits is the Phy Identifier 2 register,
  this is the chip vendor OUI bits 19:24, followed by 10
  bits of a vendor specific ID.

> 
> WARNING: DT compatible string "ethernet-phy-id001c.c916" appears un-
> documented -- check ./Documentation/devicetree/bindings/
> #92: FILE: arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts:56:
> + compatible = "ethernet-phy-id001c.c916";
> 
> 
> Shawn

RE: [PATCH v2] soc: fsl: dpio: Change 'cpumask_t mask' to the driver's private data

[Leo Li]

> -Original Message-
> From: Leo Li
> Sent: Friday, October 16, 2020 4:20 PM
> To: 'Yi Wang' ; Roy Pledge ;
> Laurentiu Tudor 
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; xue.zhih...@zte.com.cn;
> jiang.xue...@zte.com.cn; Hao Si ; Lin Chen
> 
> Subject: RE: [PATCH v2] soc: fsl: dpio: Change 'cpumask_t mask' to the
> driver's private data
> 
> 
> 
> > -Original Message-
> > From: Yi Wang 
> > Sent: Friday, October 16, 2020 1:49 AM
> > To: Roy Pledge ; Laurentiu Tudor
> > 
> > Cc: Leo Li ; linux-kernel@vger.kernel.org;
> > linuxppc- d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> > xue.zhih...@zte.com.cn; wang.y...@zte.com.cn;
> jiang.xue...@zte.com.cn;
> > Hao Si ; Lin Chen 
> > Subject: [PATCH v2] soc: fsl: dpio: Change 'cpumask_t mask' to the
> > driver's private data
> >
> > From: Hao Si 
> >
> > The local variable 'cpumask_t mask' is in the stack memory, and its
> > address is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> > But the memory area where this variable is located is at risk of being
> > modified.
> >
> > During LTP testing, the following error was generated:
> >
> > Unable to handle kernel paging request at virtual address
> > 12e9b790 Mem abort info:
> >   ESR = 0x9607
> >   Exception class = DABT (current EL), IL = 32 bits
> >   SET = 0, FnV = 0
> >   EA = 0, S1PTW = 0
> > Data abort info:
> >   ISV = 0, ISS = 0x0007
> >   CM = 0, WnR = 0
> > swapper pgtable: 4k pages, 48-bit VAs, pgdp = 75ac5e07
> > [12e9b790] pgd=0027dbffe003, pud=0027dbffd003,
> > pmd=0027b6d61003, pte= Internal error: Oops:
> > 9607 [#1] PREEMPT SMP Modules linked in: xt_conntrack Process
> > read_all (pid: 20171, stack limit = 0x44ea4095)
> > CPU: 14 PID: 20171 Comm: read_all Tainted: GB   W
> > Hardware name: NXP Layerscape LX2160ARDB (DT)
> > pstate: 8085 (Nzcv daIf -PAN -UAO) pc :
> > irq_affinity_hint_proc_show+0x54/0xb0
> > lr : irq_affinity_hint_proc_show+0x4c/0xb0
> > sp : 1138bc10
> > x29: 1138bc10 x28: d131d1e0
> > x27: 007000c0 x26: 8025b9480dc0
> > x25: 8025b9480da8 x24: 03ff
> > x23: 8027334f8300 x22: 80272e97d000
> > x21: 80272e97d0b0 x20: 8025b9480d80
> > x19: 09a49000 x18: 
> > x17:  x16: 
> > x15:  x14: 
> > x13:  x12: 0040
> > x11:  x10: 802735b79b88
> > x9 :  x8 : 
> > x7 : 09a49848 x6 : 0003
> > x5 :  x4 : 08157d6c
> > x3 : 1138bc10 x2 : 12e9b790
> > x1 :  x0 :  Call trace:
> >  irq_affinity_hint_proc_show+0x54/0xb0
> >  seq_read+0x1b0/0x440
> >  proc_reg_read+0x80/0xd8
> >  __vfs_read+0x60/0x178
> >  vfs_read+0x94/0x150
> >  ksys_read+0x74/0xf0
> >  __arm64_sys_read+0x24/0x30
> >  el0_svc_common.constprop.0+0xd8/0x1a0
> >  el0_svc_handler+0x34/0x88
> >  el0_svc+0x10/0x14
> > Code: f9001bbf 943e0732 f94066c2 b462 (f9400041) ---[ end trace
> > b495bdcb0b3b732b ]--- Kernel panic - not syncing: Fatal exception
> > SMP: stopping secondary CPUs
> > SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15 Kernel Offset:
> > disabled CPU features: 0x0,21006008 Memory Limit: none ---[ end Kernel
> > panic - not syncing: Fatal exception ]---
> >
> > Fix it by changing 'cpumask_t mask' to the driver's private data.
> 
> Thanks for the patch.  Sorry to chime in late.
> 
> Since we are only setting single bit in the cpumask, it is actually not 
> necessary
> to keep the cpumask in private data as we already kept the cpu number in
> desc.cpu.  The better and easier approach is to actually use
> get_cpu_mask(cpu) API to get the pre-defined cpumask in the static
> cpu_bit_bitmap array.  We don't even need to declare the mask/cpu_mask
> in the register_dpio_irq_handlers().

Btw, cpumask_of(cpu) is more commonly used than get_cpu_mask(cpu), although 
they are essentially the same.

> 
> >
> > Signed-off-by: Hao Si 
> > Signed-off-by: Lin Chen 
> > Signed-off-by: Yi Wang 
> > ---
> > v2: Place 'cpumask_t mask' in the driver's private data and while at
> > it, rename it to cpu_mask.
> >
> >  drivers/soc/fsl/dpio/dpio-driver.c | 9 +++

RE: [PATCH v2] soc: fsl: dpio: Change 'cpumask_t mask' to the driver's private data

[Leo Li]

> -Original Message-
> From: Yi Wang 
> Sent: Friday, October 16, 2020 1:49 AM
> To: Roy Pledge ; Laurentiu Tudor
> 
> Cc: Leo Li ; linux-kernel@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> xue.zhih...@zte.com.cn; wang.y...@zte.com.cn; jiang.xue...@zte.com.cn;
> Hao Si ; Lin Chen 
> Subject: [PATCH v2] soc: fsl: dpio: Change 'cpumask_t mask' to the driver's
> private data
> 
> From: Hao Si 
> 
> The local variable 'cpumask_t mask' is in the stack memory, and its address
> is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> But the memory area where this variable is located is at risk of being
> modified.
> 
> During LTP testing, the following error was generated:
> 
> Unable to handle kernel paging request at virtual address 12e9b790
> Mem abort info:
>   ESR = 0x9607
>   Exception class = DABT (current EL), IL = 32 bits
>   SET = 0, FnV = 0
>   EA = 0, S1PTW = 0
> Data abort info:
>   ISV = 0, ISS = 0x0007
>   CM = 0, WnR = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp = 75ac5e07
> [12e9b790] pgd=0027dbffe003, pud=0027dbffd003,
> pmd=0027b6d61003, pte=
> Internal error: Oops: 9607 [#1] PREEMPT SMP
> Modules linked in: xt_conntrack
> Process read_all (pid: 20171, stack limit = 0x44ea4095)
> CPU: 14 PID: 20171 Comm: read_all Tainted: GB   W
> Hardware name: NXP Layerscape LX2160ARDB (DT)
> pstate: 8085 (Nzcv daIf -PAN -UAO)
> pc : irq_affinity_hint_proc_show+0x54/0xb0
> lr : irq_affinity_hint_proc_show+0x4c/0xb0
> sp : 1138bc10
> x29: 1138bc10 x28: d131d1e0
> x27: 007000c0 x26: 8025b9480dc0
> x25: 8025b9480da8 x24: 03ff
> x23: 8027334f8300 x22: 80272e97d000
> x21: 80272e97d0b0 x20: 8025b9480d80
> x19: 09a49000 x18: 
> x17:  x16: 
> x15:  x14: 
> x13:  x12: 0040
> x11:  x10: 802735b79b88
> x9 :  x8 : 
> x7 : 09a49848 x6 : 0003
> x5 :  x4 : 08157d6c
> x3 : 1138bc10 x2 : 12e9b790
> x1 :  x0 : 
> Call trace:
>  irq_affinity_hint_proc_show+0x54/0xb0
>  seq_read+0x1b0/0x440
>  proc_reg_read+0x80/0xd8
>  __vfs_read+0x60/0x178
>  vfs_read+0x94/0x150
>  ksys_read+0x74/0xf0
>  __arm64_sys_read+0x24/0x30
>  el0_svc_common.constprop.0+0xd8/0x1a0
>  el0_svc_handler+0x34/0x88
>  el0_svc+0x10/0x14
> Code: f9001bbf 943e0732 f94066c2 b462 (f9400041)
> ---[ end trace b495bdcb0b3b732b ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
> Kernel Offset: disabled
> CPU features: 0x0,21006008
> Memory Limit: none
> ---[ end Kernel panic - not syncing: Fatal exception ]---
> 
> Fix it by changing 'cpumask_t mask' to the driver's private data.

Thanks for the patch.  Sorry to chime in late.

Since we are only setting single bit in the cpumask, it is actually not 
necessary to keep the cpumask in private data as we already kept the cpu number 
in desc.cpu.  The better and easier approach is to actually use 
get_cpu_mask(cpu) API to get the pre-defined cpumask in the static 
cpu_bit_bitmap array.  We don't even need to declare the mask/cpu_mask in the 
register_dpio_irq_handlers().

> 
> Signed-off-by: Hao Si 
> Signed-off-by: Lin Chen 
> Signed-off-by: Yi Wang 
> ---
> v2: Place 'cpumask_t mask' in the driver's private data and while at it,
> rename it to cpu_mask.
> 
>  drivers/soc/fsl/dpio/dpio-driver.c | 9 +
>  include/linux/fsl/mc.h | 2 ++
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-
> driver.c
> index 7b642c3..e9d820d 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -95,7 +95,7 @@ static int register_dpio_irq_handlers(struct
> fsl_mc_device *dpio_dev, int cpu)
>  {
>   int error;
>   struct fsl_mc_device_irq *irq;
> - cpumask_t mask;
> + cpumask_t *cpu_mask;
> 
>   irq = dpio_dev->irqs[0];
>   error = devm_request_irq(_dev->dev,
> @@ -112,9 +112,10 @@ static int register_dpio_irq_handlers(struct
> fsl_mc_device *dpio_dev, int cpu)
>   }
> 
>   /* set the affinity hint */
> - cpumask_clear();
> - cpumask_set_cpu(cpu, );
> - if (irq_set_affinity_hint(irq->msi_desc->irq, ))
> + cpu_mask = _dev->mask;
> 

RE: [PATCH] arm64: dts: fix endianness of rcpm

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Monday, September 28, 2020 4:05 AM
> To: Shawn Guo ; Leo Li 
> Cc: moderated list:ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE  arm-ker...@lists.infradead.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS ; open list
> ; Biwen Li 
> Subject: [PATCH] arm64: dts: fix endianness of rcpm
> 
> From: Biwen Li 
> 
> Add little-endian property of rcpm for ls1028a,ls1088a,ls208xa
> 
> Signed-off-by: Biwen Li 

Acked-by: Li Yang 

> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 0efeb8f..651bfe1 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -1012,6 +1012,7 @@
>   compatible = "fsl,ls1028a-rcpm", "fsl,qoriq-rcpm-
> 2.1+";
>   reg = <0x0 0x1e34040 0x0 0x1c>;
>   #fsl,rcpm-wakeup-cells = <7>;
> + little-endian;
>   };
> 
>   ftm_alarm0: timer@280 {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 169f474..2ef812d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -787,6 +787,7 @@
>   compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-
> 2.1+";
>   reg = <0x0 0x1e34040 0x0 0x18>;
>   #fsl,rcpm-wakeup-cells = <6>;
> + little-endian;
>   };
> 
>   ftm_alarm0: timer@280 {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index 41102da..141b3d2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -769,6 +769,7 @@
>   compatible = "fsl,ls208xa-rcpm", "fsl,qoriq-rcpm-
> 2.1+";
>   reg = <0x0 0x1e34040 0x0 0x18>;
>   #fsl,rcpm-wakeup-cells = <6>;
> + little-endian;
>   };
> 
>   ftm_alarm0: timer@280 {
> --
> 2.7.4

RE: [PATCH 1/2] arm64: dts: ls1028a: add missing CAN nodes

[Leo Li]

> -Original Message-
> From: Michael Walle 
> Sent: Thursday, September 24, 2020 6:31 AM
> To: Leo Li 
> Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; Shawn Guo
> ; Rob Herring ; Marc Kleine-
> Budde ; Joakim Zhang 
> Subject: Re: [PATCH 1/2] arm64: dts: ls1028a: add missing CAN nodes
> 
> Am 2020-09-24 02:35, schrieb Leo Li:
> >> -Original Message-
> >> From: Michael Walle 
> >> Sent: Wednesday, September 23, 2020 4:57 AM
> >> To: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> >> linux-
> >> ker...@vger.kernel.org; linux-...@vger.kernel.org
> >> Cc: Shawn Guo ; Leo Li ;
> Rob
> >> Herring ; Marc Kleine-Budde
> ;
> >> Joakim Zhang ; Michael Walle
> >> 
> >> Subject: [PATCH 1/2] arm64: dts: ls1028a: add missing CAN nodes
> >>
> >> The LS1028A has two FlexCAN controller. These are compatible with the
> >> ones
> >> from the LX2160A. Add the nodes.
> >>
> >> The first controller was tested on the Kontron sl28 board.
> >>
> >> Signed-off-by: Michael Walle 
> >> ---
> >>  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 18
> >> ++
> >>  1 file changed, 18 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> >> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> >> index 0efeb8fa773e..807ee921ec12 100644
> >> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> >> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> >> @@ -386,6 +386,24 @@
> >>status = "disabled";
> >>};
> >>
> >> +  can0: can@218 {
> >> +  compatible = "fsl,ls1028ar1-flexcan", "fsl,lx2160ar1-
> >> flexcan";
> >
> > The explicit compatible strings cannot be found in the binding, but
> > matched by the "fsl,-flexcan" pattern in the binding.  Is
> > this considered to be acceptable now?
> 
> What is the consequence if it is not acceptable? replacing the pattern
> with individual compatible strings?

There is a recommendation in the kernel documentation quoted below:

  7) The wildcard "" may be used in compatible strings, as in
 the following example:

 - compatible: Must contain '"nvidia,-pcie",
   "nvidia,tegra20-pcie"' where  is tegra30, tegra132, ...

 As in the above example, the known values of "" should be
 documented if it is used.

But I am not sure if this is still a hard requirement.  If so, we should list 
the processors in the binding.

Regards,
Leo

RE: [PATCH 1/2] arm64: dts: ls1028a: add missing CAN nodes

[Leo Li]

> -Original Message-
> From: Michael Walle 
> Sent: Wednesday, September 23, 2020 4:57 AM
> To: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Cc: Shawn Guo ; Leo Li ; Rob
> Herring ; Marc Kleine-Budde ;
> Joakim Zhang ; Michael Walle
> 
> Subject: [PATCH 1/2] arm64: dts: ls1028a: add missing CAN nodes
> 
> The LS1028A has two FlexCAN controller. These are compatible with the ones
> from the LX2160A. Add the nodes.
> 
> The first controller was tested on the Kontron sl28 board.
> 
> Signed-off-by: Michael Walle 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 0efeb8fa773e..807ee921ec12 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -386,6 +386,24 @@
>   status = "disabled";
>   };
> 
> + can0: can@218 {
> + compatible = "fsl,ls1028ar1-flexcan", "fsl,lx2160ar1-
> flexcan";

The explicit compatible strings cannot be found in the binding, but matched by 
the "fsl,-flexcan" pattern in the binding.  Is this considered to be 
acceptable now?

> + reg = <0x0 0x218 0x0 0x1>;
> + interrupts = ;
> + clocks = <>, < 4 1>;
> + clock-names = "ipg", "per";
> + status = "disabled";
> + };
> +
> + can1: can@219 {
> + compatible = "fsl,ls1028ar1-flexcan", "fsl,lx2160ar1-
> flexcan";
> + reg = <0x0 0x219 0x0 0x1>;
> + interrupts = ;
> + clocks = <>, < 4 1>;
> + clock-names = "ipg", "per";
> + status = "disabled";
> + };
> +
>   duart0: serial@21c0500 {
>   compatible = "fsl,ns16550", "ns16550a";
>   reg = <0x00 0x21c0500 0x0 0x100>;
> --
> 2.20.1

RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless property of rtc

[Leo Li]

> -Original Message-
> From: Biwen Li 
> Sent: Monday, September 21, 2020 10:13 PM
> To: Shawn Guo ; Biwen Li (OSS)
> 
> Cc: alexandre.bell...@bootlin.com; Leo Li ;
> robh...@kernel.org; mark.rutl...@arm.com; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Jiafei Pan ; linux-
> r...@vger.kernel.org
> Subject: RE: [EXT] Re: [PATCH 2/5] arm64: dts: lx2160a-rdb: remove useless
> property of rtc
> 
> >
> > Caution: EXT Email
> >
> > On Tue, Sep 15, 2020 at 03:32:10PM +0800, Biwen Li wrote:
> > > From: Biwen Li 
> > >
> > > Remove useless property interrupts of rtc
> > >
> > > Signed-off-by: Biwen Li 
> > > ---
> > >  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > index dce79018d397..e9e982176e07 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > > @@ -171,8 +171,6 @@
> > >   rtc@51 {
> > >   compatible = "nxp,pcf2129";
> > >   reg = <0x51>;
> > > - // IRQ10_B
> > > - interrupts = <0 150 0x4>;
> >
> > If it's a correct description of hardware, I do not see why we would
> > need to remove it.
> Hi Shawn,
> 
> Don't need use the interrupt, only read time from rtc.

User probably will choose to use the alarm feature of the RTC and need the 
interrupt property.  Is there any issue when the interrupt property is present?

> 
> Best Regards,
> Biwen Li
> >
> > Shawn
> >
> > >   };
> > >  };
> > >
> > > --
> > > 2.17.1
> > >

RE: [PATCH 4/5] arm: dts: ls1021a: fix flextimer failed to wake system

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Wednesday, September 16, 2020 3:19 AM
> To: Leo Li ; Rob Herring ;
> Shawn Guo 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ran Wang
> 
> Subject: [PATCH 4/5] arm: dts: ls1021a: fix flextimer failed to wake system
> 
> The data of property 'fsl,rcpm-wakeup' is not corrcet, which causing RCPM
> driver incorrectly program register IPPDEXPCR1, then flextimer is wrongly
> clock gated during system suspend, can't send interrupt to wake.
> 
> Signed-off-by: Ran Wang 

Acked-by: Li Yang 

> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 089fe86..e372630f 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -1014,7 +1014,7 @@
>   compatible = "fsl,ls1021a-ftm-alarm";
>   reg = <0x0 0x29d 0x0 0x1>;
>   reg-names = "ftm";
> - fsl,rcpm-wakeup = < 0x2 0x0>;
> + fsl,rcpm-wakeup = < 0x0 0x2000>;
>   interrupts = ;
>   big-endian;
>   };
> --
> 2.7.4

RE: [PATCH 3/5] arm: dts: ls1021a: fix that FlexTimer cannot wakeup system in deep sleep

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Wednesday, September 16, 2020 3:18 AM
> To: Leo Li ; Rob Herring ;
> Shawn Guo 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Biwen Li
> ; Ran Wang 
> Subject: [PATCH 3/5] arm: dts: ls1021a: fix that FlexTimer cannot wakeup
> system in deep sleep

A better description should be enabling the A-008646 workaround to be 
consistent with other patches.

> 
> From: Biwen Li 
> 
> The patch fixes a bug that FlexTimer cannot wakeup system in deep sleep.
> 
> Signed-off-by: Biwen Li 
> Signed-off-by: Ran Wang 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 827373e..089fe86 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -1007,6 +1007,7 @@
>   compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> 2.1+";
>   reg = <0x0 0x1ee2140 0x0 0x8>;
>   #fsl,rcpm-wakeup-cells = <2>;
> + fsl,ippdexpcr1-alt-addr = < 0x51c>;
>   };
> 
>   ftm_alarm0: timer0@29d {
> --
> 2.7.4

RE: [PATCH 2/5] soc: fsl: handle RCPM errata A-008646 on SoC LS1021A

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Wednesday, September 16, 2020 3:18 AM
> To: Leo Li ; Rob Herring ;
> Shawn Guo 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Biwen Li
> ; Ran Wang 
> Subject: [PATCH 2/5] soc: fsl: handle RCPM errata A-008646 on SoC LS1021A
> 
> From: Biwen Li 
> 
> Description:
>   - Reading configuration register RCPM_IPPDEXPCR1
> always return zero
> 
> Workaround:
>   - Save register RCPM_IPPDEXPCR1's value to
> register SCFG_SPARECR8.(uboot's psci also
> need reading value from the register SCFG_SPARECR8
> to set register RCPM_IPPDEXPCR1)
> 
> Impact:
>   - FlexTimer module will cannot wakeup system in
Will not..
Also it will be better to merge this with the issue description part above to 
prevent confusion.

> deep sleep on SoC LS1021A
> 
> Signed-off-by: Biwen Li 
> Signed-off-by: Ran Wang 
> ---
>  drivers/soc/fsl/rcpm.c | 42
> +-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
> index a093dbe..e6354f5 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -2,7 +2,7 @@
>  //
>  // rcpm.c - Freescale QorIQ RCPM driver
>  //
> -// Copyright 2019 NXP
> +// Copyright 2019-2020 NXP
>  //
>  // Author: Ran Wang 
> 
> @@ -13,6 +13,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> 
>  #define RCPM_WAKEUP_CELL_MAX_SIZE7
> 
> @@ -37,6 +40,9 @@ static int rcpm_pm_prepare(struct device *dev)
>   struct device_node  *np = dev->of_node;
>   u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1];
>   u32 setting[RCPM_WAKEUP_CELL_MAX_SIZE] = {0};
> + struct regmap *scfg_addr_regmap = NULL;
> + u32 reg_offset[2];
> + u32 reg_value = 0;
> 
>   rcpm = dev_get_drvdata(dev);
>   if (!rcpm)
> @@ -90,6 +96,40 @@ static int rcpm_pm_prepare(struct device *dev)
>   tmp |= ioread32be(address);
>   iowrite32be(tmp, address);
>   }
> + /*
> +  * Workaround of errata A-008646 on SoC LS1021A:
> +  * There is a bug of register ippdexpcr1.
> +  * Reading configuration register RCPM_IPPDEXPCR1
> +  * always return zero. So save ippdexpcr1's value
> +  * to register SCFG_SPARECR8.And the value of
> +  * ippdexpcr1 will be read from SCFG_SPARECR8.
> +  */
> + if (device_property_present(dev, "fsl,ippdexpcr1-alt-addr"))
> {
> + if (dev_of_node(dev)) {
> + scfg_addr_regmap =
> syscon_regmap_lookup_by_phandle(np,
> +
>  "fsl,ippdexpcr1-alt-addr");
> + } else if (is_acpi_node(dev->fwnode)) {
> + continue;
> + }
> +
> + if (scfg_addr_regmap && (i == 1)) {
> + if (device_property_read_u32_array(dev,
> + "fsl,ippdexpcr1-alt-addr",
> + reg_offset,
> + 2)) {

It is not necessary to read out the whole fsl,ippdexpcr1-alt-addr property if 
we only need the offset.  Also you can change to use the 
syscon_regmap_lookup_by_phandle_args() API above to simplify the code.

> + scfg_addr_regmap = NULL;
> + continue;
> + }
> + /* Read value from register SCFG_SPARECR8
> */
> + regmap_read(scfg_addr_regmap,
> + reg_offset[1],
> + _value);
> + /* Write value to register SCFG_SPARECR8 */
> + regmap_write(scfg_addr_regmap,
> +  reg_offset[1],
> +  tmp | reg_value);
> + }
> + }
>   }
> 
>   return 0;
> --
> 2.7.4

RE: [PATCH 1/5] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-addr' property

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Wednesday, September 16, 2020 3:18 AM
> To: Leo Li ; Rob Herring ;
> Shawn Guo 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Biwen Li
> ; Ran Wang 
> Subject: [PATCH 1/5] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-
> addr' property
> 
> From: Biwen Li 
> 
> The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata A-008646 on
> LS1021A

It looks like the previous version of this patch has gotten the reviewed-by 
from Rob.  It would be good to be added to the patch for new submission.

> 
> Signed-off-by: Biwen Li 
> Signed-off-by: Ran Wang 
> ---
>  Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 19
> +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> index 5a33619..1be58a3 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> @@ -34,6 +34,11 @@ Chassis VersionExample Chips
>  Optional properties:
>   - little-endian : RCPM register block is Little Endian. Without it RCPM
> will be Big Endian (default case).
> + - fsl,ippdexpcr1-alt-addr : The property is related to a hardware issue
> +   on SoC LS1021A and only needed on SoC LS1021A.
> +   Must include 2 entries:
> +   The first entry must be a link to the SCFG device node.
> +   The 2nd entry must be offset of register IPPDEXPCR1 in SCFG.
> 
>  Example:
>  The RCPM node for T4240:
> @@ -43,6 +48,20 @@ The RCPM node for T4240:
>   #fsl,rcpm-wakeup-cells = <2>;
>   };
> 
> +The RCPM node for LS1021A:
> + rcpm: rcpm@1ee2140 {
> + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
> + reg = <0x0 0x1ee2140 0x0 0x8>;
> + #fsl,rcpm-wakeup-cells = <2>;
> +
> + /*
> +  * The second and third entry compose an alt offset
> +  * address for IPPDEXPCR1(SCFG_SPARECR8)
> +  */
> + fsl,ippdexpcr1-alt-addr = < 0x51c>;
> + };
> +
> +
>  * Freescale RCPM Wakeup Source Device Tree Bindings
>  ---
>  Required fsl,rcpm-wakeup property should be added to a device node if the
> device
> --
> 2.7.4

RE: [PATCH 5/5] arm: dts: ls1021a: fix rcpm failed to claim resource

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Wednesday, September 16, 2020 3:19 AM
> To: Leo Li ; Rob Herring ;
> Shawn Guo 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ran Wang
> 
> Subject: [PATCH 5/5] arm: dts: ls1021a: fix rcpm failed to claim resource
> 
> The range of dcfg reg is wrong, which overlap with other device, such as rcpm.
> This issue causing rcpm driver failed to claim reg resource when calling
> devm_ioremap_resource().
> 
> Signed-off-by: Ran Wang 

Acked-by: Li Yang 

> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index e372630f..286c547 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -173,7 +173,7 @@
> 
>   dcfg: dcfg@1ee {
>   compatible = "fsl,ls1021a-dcfg", "syscon";
> - reg = <0x0 0x1ee 0x0 0x1>;
> + reg = <0x0 0x1ee 0x0 0x1000>;
>   big-endian;
>   };
> 
> --
> 2.7.4

RE: [PATCH] fsldma: fsl_ioread64*() do not need lower_32_bits()

[Leo Li]

> -Original Message-
> From: Linus Torvalds 
> Sent: Saturday, August 29, 2020 4:20 PM
> To: Guenter Roeck 
> Cc: Luc Van Oostenryck ; Herbert Xu
> ; Andrew Morton  foundation.org>; Joerg Roedel ; Leo Li
> ; Zhang Wei ; Dan Williams
> ; Vinod Koul ; linuxppc-dev
> ; dma ; Linux
> Kernel Mailing List 
> Subject: Re: [PATCH] fsldma: fsl_ioread64*() do not need lower_32_bits()
> 
> On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck  wrote:
> >
> > Except for
> >
> > CHECK: spaces preferred around that '+' (ctx:VxV)
> > #29: FILE: drivers/dma/fsldma.h:223:
> > +   u32 val_lo = in_be32((u32 __iomem *)addr+1);
> 
> Added spaces.
> 
> > I don't see anything wrong with it either, so
> >
> > Reviewed-by: Guenter Roeck 
> >
> > Since I didn't see the real problem with the original code, I'd take
> > that with a grain of salt, though.
> 
> Well, honestly, the old code was so confused that just making it build is
> clearly already an improvement even if everything else were to be wrong.
> 
> So I committed my "fix". If it turns out there's more wrong in there and
> somebody tests it, we can fix it again. But now it hopefully compiles, at 
> least.
> 
> My bet is that if that driver ever worked on ppc32, it will continue to work
> whatever we do to that function.
> 
> I _think_ the old code happened to - completely by mistake - get the value
> right for the case of "little endian access, with dma_addr_t being 32-bit".
> Because then it would still read the upper bits wrong, but the cast to
> dma_addr_t would then throw those bits away. And the lower bits would be
> right.
> 
> But for big-endian accesses or for ARCH_DMA_ADDR_T_64BIT it really looks
> like it always returned a completely incorrect value.
> 
> And again - the driver may have worked even with that completely incorrect
> value, since the use of it seems to be very incidental.
> 
> In either case ("it didn't work before" or "it worked because the value
> doesn't really matter"), I don't think I could possibly have made things 
> worse.
> 
> Famous last words.

Thanks for the patch.  

Acked-by: Li Yang 

We are having periodical auto regression tests covering ppc32 platforms.  But 
looks like it missed this issue.  I will ask the test team to investigate on 
why the test cases are not sufficient.

Regards,
Leo

RE: [RESEND PATCH] arm64: dts: ls1028a: Add DSPI nodes

[Leo Li]

> -Original Message-
> From: Qiang Zhao 
> Sent: Monday, June 22, 2020 3:29 AM
> To: shawn...@kernel.org
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Leo Li
> ; Qiang Zhao ; Xiaowei Bao
> 
> Subject: [RESEND PATCH] arm64: dts: ls1028a: Add DSPI nodes

This patch is actually defining dspi flash nodes for LS1028a-qds board instead 
of adding dspi nodes for the soc.

> 
> From: Xiaowei Bao 
> 
> Add the DSPI nodes for ls1028a.
> 
> Signed-off-by: Xiaowei Bao 
> Signed-off-by: Zhao Qiang 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 85
> +++
>  1 file changed, 85 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index dd69c5b..e4f00c2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -107,6 +107,91 @@
>   };
>  };
> 
> + {
> + bus-num = <0>;
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <0>;
> + spi-max-frequency = <1000>;
> + };
> +
> + flash@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <1>;
> + spi-max-frequency = <1000>;
> + };
> +
> + flash@2 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <2>;
> + spi-max-frequency = <1000>;
> + };
> +};
> +
> + {
> + bus-num = <1>;
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;

These probably are not needed when no sub nodes are defined.

> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <0>;
> + spi-max-frequency = <1000>;
> + };
> +
> + flash@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <1>;
> + spi-max-frequency = <1000>;
> + };
> +
> + flash@2 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <2>;
> + spi-max-frequency = <1000>;
> + };
> +};
> +
> + {
> + bus-num = <2>;
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-cpol;
> + spi-cpha;
> + reg = <0>;
> + spi-max-frequency = <1000>;
> + };
> +};
> +
>   {
>   status = "okay";
>  };
> --
> 2.7.4

RE: [PATCH] gpio: mpc8xxx: change the gpio interrupt flags.

[Leo Li]

> -Original Message-
> From: Hui Song 
> Sent: Tuesday, June 9, 2020 4:38 AM
> To: linux-de...@linux.nxdi.nxp.com; Shawn Guo ;
> Leo Li ; Rob Herring ; Mark
> Rutland ; Linus Walleij ;
> Bartosz Golaszewski 
> Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-g...@vger.kernel.org; Hui Song
> 
> Subject: [PATCH] gpio: mpc8xxx: change the gpio interrupt flags.
> 
> From: Song Hui 
> 
> delete the interrupt IRQF_NO_THREAD flags.

I think this is the correct direction but would be better to describe a little 
bit on what motived this change.  Any issue encountered or latency optimization?

> 
> Signed-off-by: Song Hui 
> ---
>  drivers/gpio/gpio-mpc8xxx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index
> 604dfec..1e86652 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -417,7 +417,7 @@ static int mpc8xxx_probe(struct platform_device
> *pdev)
> 
>   ret = devm_request_irq(>dev, mpc8xxx_gc->irqn,
>  mpc8xxx_gpio_irq_cascade,
> -IRQF_NO_THREAD | IRQF_SHARED, "gpio-
> cascade",
> +IRQF_SHARED, "gpio-cascade",
>  mpc8xxx_gc);
>   if (ret) {
>   dev_err(>dev, "%s: failed to devm_request_irq(%d),
> ret = %d\n",
> --
> 2.9.5

RE: [PATCH net] soc: fsl: dpio: properly compute the consumer index

[Leo Li]

> -Original Message-
> From: Ioana Ciornei 
> Sent: Tuesday, May 5, 2020 3:14 PM
> To: da...@davemloft.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Youri Querry ; Leo Li ;
> Ioana Ciornei 
> Subject: [PATCH net] soc: fsl: dpio: properly compute the consumer index
> 
> Mask the consumer index before using it. Without this, we would be writing
> frame descriptors beyond the ring size supported by the QBMAN block.
> 
> Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with ring
> mode enqueue")
> Signed-off-by: Ioana Ciornei 

If you would like it go through net tree.

Acked-by: Li Yang 

> ---
> 
> I am sending this fix through the net tree since the bug manifests itself only
> on net-next and not the soc trees. This way it would be easier to integrate
> this sooner rather than later.

Since the description of the patch says it fixes a patch included from soc 
tree, it is not very clear why this problem only exists on net-next.

> 
>  drivers/soc/fsl/dpio/qbman-portal.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/fsl/dpio/qbman-portal.c
> b/drivers/soc/fsl/dpio/qbman-portal.c
> index 804b8ba9bf5c..23a1377971f4 100644
> --- a/drivers/soc/fsl/dpio/qbman-portal.c
> +++ b/drivers/soc/fsl/dpio/qbman-portal.c
> @@ -669,6 +669,7 @@ int qbman_swp_enqueue_multiple_direct(struct
> qbman_swp *s,
>   eqcr_ci = s->eqcr.ci;
>   p = s->addr_cena + QBMAN_CENA_SWP_EQCR_CI;
>   s->eqcr.ci = qbman_read_register(s,
> QBMAN_CINH_SWP_EQCR_CI);
> + s->eqcr.ci &= full_mask;
> 
>   s->eqcr.available = qm_cyc_diff(s->eqcr.pi_ring_size,
>   eqcr_ci, s->eqcr.ci);
> --
> 2.17.1

RE: [V2] dmaengine: fsl-edma: Add eDMA support for QorIQ LS1028A platform

[Leo Li]

> -Original Message-
> From: Peng Ma 
> Sent: Sunday, October 20, 2019 9:22 PM
> To: vk...@kernel.org
> Cc: dan.j.willi...@intel.com; Leo Li ;
> k.kozlowsk...@gmail.com; Fabio Estevam ;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; Peng Ma
> 
> Subject: [V2] dmaengine: fsl-edma: Add eDMA support for QorIQ LS1028A
> platform
> 
> Our platforms(such as LS1021A, LS1012A, LS1043A, LS1046A, LS1028A) with
> below

You only covered QorIQ SoCs, how about the situation for IMX SoCs?

> registers(CHCFG0 - CHCFG15) of eDMA as follows:
> *---*
> | Offset   |  OTHERS  |   LS1028A |
> |--||---|
> | 0x0  |CHCFG0  |   CHCFG3  |
> |--||---|
> | 0x1  |CHCFG1  |   CHCFG2  |
> |--||---|
> | 0x2  |CHCFG2  |   CHCFG1  |
> |--||---|
> | 0x3  |CHCFG3  |   CHCFG0  |
> |--||---|
> | ...  |..  |   ..  |
> |--||---|
> | 0xC  |CHCFG12 |   CHCFG15 |
> |--||---|
> | 0xD  |CHCFG13 |   CHCFG14 |
> |--||---|
> | 0xE  |CHCFG14 |   CHCFG13 |
> |--||---|
> | 0xF  |CHCFG15 |   CHCFG12 |
> *---*
> 
> This patch is to improve edma driver to fit LS1028A platform.
> 
> Signed-off-by: Peng Ma 
> ---
> Changed for V2:
>   - Explaining what's the "Our platforms"
> 
>  drivers/dma/fsl-edma-common.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-
> common.c index b1a7ca9..611186b 100644
> --- a/drivers/dma/fsl-edma-common.c
> +++ b/drivers/dma/fsl-edma-common.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "fsl-edma-common.h"
> 
> @@ -42,6 +43,11 @@
> 
>  #define EDMA_TCD 0x1000
> 
> +static struct soc_device_attribute soc_fixup_tuning[] = {
> + { .family = "QorIQ LS1028A"},
> + { },
> +};
> +
>  static void fsl_edma_enable_request(struct fsl_edma_chan *fsl_chan)  {
>   struct edma_regs *regs = _chan->edma->regs; @@ -109,10
> +115,16 @@ void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
>   u32 ch = fsl_chan->vchan.chan.chan_id;
>   void __iomem *muxaddr;
>   unsigned int chans_per_mux, ch_off;
> + int endian_diff[4] = {3, 1, -1, -3};
>   u32 dmamux_nr = fsl_chan->edma->drvdata->dmamuxs;
> 
>   chans_per_mux = fsl_chan->edma->n_chans / dmamux_nr;
>   ch_off = fsl_chan->vchan.chan.chan_id % chans_per_mux;
> +
> + if (!fsl_chan->edma->big_endian &&
> + soc_device_match(soc_fixup_tuning))
> + ch_off += endian_diff[ch_off % 4];
> +

This probably is not the best fix now.  There is a new mux_configure32() API 
added but it doesn't consider endianness.  How about making it properly taken 
care of endianness?  And use it to set these registers?

>   muxaddr = fsl_chan->edma->muxbase[ch / chans_per_mux];
>   slot = EDMAMUX_CHCFG_SOURCE(slot);
> 
> --
> 2.9.5

RE: [PATCH 0/7] towards QE support on ARM

[Leo Li]

> -Original Message-
> From: Rasmus Villemoes 
> Sent: Friday, October 18, 2019 7:52 AM
> To: Qiang Zhao ; Leo Li ; Greg
> Kroah-Hartman ; Jiri Slaby
> ; Timur Tabi ; linuxppc-
> d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-ser...@vger.kernel.org
> Cc: Rasmus Villemoes 
> Subject: [PATCH 0/7] towards QE support on ARM
> 
> There have been several attempts in the past few years to allow building the
> QUICC engine drivers for platforms other than PPC. This is (the beginning of)
> yet another attempt. I hope I can get someone to pick up these relatively
> trivial patches (I _think_ they shouldn't change functionality at all), and 
> then
> I'll continue slowly working towards removing the PPC32 dependency for
> CONFIG_QUICC_ENGINE.

Hi Rasmus,

I don't fully understand the motivation of this work.  As far as I know the 
QUICC ENGINE is only used on PowerPC based SoCs.  Can you give an example on 
how is it used on ARM system?

> 
> Tested on an MPC8309-derived board.

MPC8309 is also PPC based.

> 
> Rasmus Villemoes (7):
>   soc: fsl: qe: remove space-before-tab
>   soc: fsl: qe: drop volatile qualifier of struct qe_ic::regs
>   soc: fsl: qe: avoid ppc-specific io accessors
>   soc: fsl: qe: replace spin_event_timeout by readx_poll_timeout_atomic
>   serial: make SERIAL_QE depend on PPC32
>   serial: ucc_uart.c: explicitly include asm/cpm.h
>   soc/fsl/qe/qe.h: remove include of asm/cpm.h
> 
>  drivers/soc/fsl/qe/gpio.c | 30 
>  drivers/soc/fsl/qe/qe.c   | 44 +++
>  drivers/soc/fsl/qe/qe_ic.c|  8 ++---
>  drivers/soc/fsl/qe/qe_ic.h|  2 +-
>  drivers/soc/fsl/qe/qe_io.c| 40 ++---
>  drivers/soc/fsl/qe/qe_tdm.c   |  8 ++---
>  drivers/soc/fsl/qe/ucc.c  | 12 +++
>  drivers/soc/fsl/qe/ucc_fast.c | 66 ++-
>  drivers/soc/fsl/qe/ucc_slow.c | 38 ++--
>  drivers/soc/fsl/qe/usb.c  |  2 +-
>  drivers/tty/serial/Kconfig|  1 +
>  drivers/tty/serial/ucc_uart.c |  1 +
>  include/soc/fsl/qe/qe.h   |  1 -
>  13 files changed, 126 insertions(+), 127 deletions(-)
> 
> --
> 2.20.1

RE: [PATCH v2] arm64: dts: ls1028a: fix a compatible issue

[Leo Li]

> -Original Message-
> From: Yuantian Tang 
> Sent: Thursday, October 10, 2019 3:34 AM
> To: shawn...@kernel.org
> Cc: Leo Li ; robh...@kernel.org;
> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Tang
> 
> Subject: [PATCH v2] arm64: dts: ls1028a: fix a compatible issue
> 
> The I2C multiplexer used on ls1028aqds is PCA9547, not PCA9847.
> If the wrong compatible was used, this chip will not be able to be probed
> correctly and hence fail to work.
> 
> Signed-off-by: Yuantian Tang 

Acked-by: Li Yang 

> ---
> v2:
>   - refine the description
>  arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index 5e14e5a19744..f5da9e8b0d9d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -107,7 +107,7 @@
>   status = "okay";
> 
>   i2c-mux@77 {
> - compatible = "nxp,pca9847";
> + compatible = "nxp,pca9547";
>   reg = <0x77>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> --
> 2.17.1

RE: [PATCH] arm64: dts: lx2160a: Correct CPU core idle state name

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Monday, October 7, 2019 6:51 AM
> To: Ran Wang ; Leo Li 
> Cc: Rob Herring ; Mark Rutland
> ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] arm64: dts: lx2160a: Correct CPU core idle state name
> 
> On Tue, Sep 17, 2019 at 03:33:56PM +0800, Ran Wang wrote:
> > lx2160a support PW15 but not PW20, correct name to avoid confusing.
> >
> > Signed-off-by: Ran Wang 
> 
> Leo, agree?

Ya.  The statement is correct.

Acked-by: Li Yang 

> 
> Shawn
> 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 36 +--
> ---
> >  1 file changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > index 408e0ec..b032f38 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > @@ -33,7 +33,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@1 {
> > @@ -49,7 +49,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@100 {
> > @@ -65,7 +65,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@101 {
> > @@ -81,7 +81,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@200 {
> > @@ -97,7 +97,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@201 {
> > @@ -113,7 +113,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@300 {
> > @@ -129,7 +129,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@301 {
> > @@ -145,7 +145,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@400 {
> > @@ -161,7 +161,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle-states = <_pw20>;
> > +   cpu-idle-states = <_pw15>;
> > };
> >
> > cpu@401 {
> > @@ -177,7 +177,7 @@
> > i-cache-line-size = <64>;
> > i-cache-sets = <192>;
> > next-level-cache = <_l2>;
> > -   cpu-idle

RE: [v2 1/2] arm64: dts: ls1028a: Update the clock providers for the Mali DP500

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Monday, October 7, 2019 7:32 AM
> To: Wen He 
> Cc: linux-de...@linux.nxdi.nxp.com; Leo Li ; Rob
> Herring ; Mark Rutland ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [v2 1/2] arm64: dts: ls1028a: Update the clock providers for the
> Mali DP500
> 
> On Fri, Sep 20, 2019 at 04:34:18PM +0800, Wen He wrote:
> > In order to maximise performance of the LCD Controller's 64-bit AXI
> > bus, for any give speed bin of the device, the AXI master interface
> > clock(ACLK) clock can be up to CPU_frequency/2, which is already
> > capable of optimal performance. In general, ACLK is always expected to
> > be equal to CPU_frequency/2. APB slave interface clock(PCLK) and Main
> > processing clock(PCLK) both are tied to the same clock as ACLK.
> >
> > This change followed the LS1028A Architecture Specification Manual.
> >
> > Signed-off-by: Wen He 
> 
> @Leo, agree?

Yes.

Acked-by: Li Yang 

> 
> Shawn
> 
> > ---
> > change in v2:
> > - add details commit description for this change.
> > - v1: Link:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F1119145%2Fdata=02%7C01%
> 7Cleoyan
> >
> g.li%40nxp.com%7C628134d8d86548af60ab08d74b227a54%7C686ea1d3bc2b4
> c6fa9
> >
> 2cd99c5c301635%7C0%7C0%7C637060483779667257sdata=vX2DqsXlKE
> SqesXy
> > LwTqnBFt0GftY0XNphkmx5dR7vA%3Dreserved=0
> >
> >  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 17 ++---
> >  1 file changed, 2 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > index 72b9a75976a1..51fa8f57fdac 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > @@ -86,20 +86,6 @@
> > clocks = <_27m>;
> > };
> >
> > -   aclk: clock-axi {
> > -   compatible = "fixed-clock";
> > -   #clock-cells = <0>;
> > -   clock-frequency = <65000>;
> > -   clock-output-names= "aclk";
> > -   };
> > -
> > -   pclk: clock-apb {
> > -   compatible = "fixed-clock";
> > -   #clock-cells = <0>;
> > -   clock-frequency = <65000>;
> > -   clock-output-names= "pclk";
> > -   };
> > -
> > reboot {
> > compatible ="syscon-reboot";
> > regmap = <>;
> > @@ -679,7 +665,8 @@
> > interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
> >  <0 223 IRQ_TYPE_LEVEL_HIGH>;
> > interrupt-names = "DE", "SE";
> > -   clocks = < 0>, <>, <>, <>;
> > +   clocks = < 0>, < 2 2>, < 2 2>,
> > +< 2 2>;
> > clock-names = "pxlclk", "mclk", "aclk", "pclk";
> > arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
> > arm,malidp-arqos-value = <0xd000d000>;
> > --
> > 2.17.1
> >

RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property

[Leo Li]

> -Original Message-
> From: Biwen Li
> Sent: Tuesday, September 24, 2019 10:47 PM
> To: Leo Li ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-
> addr' property
> 
> > > > > > >
> > > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an
> > > > > > > errata
> > > > > > > A-008646 on LS1021A
> > > > > > >
> > > > > > > Signed-off-by: Biwen Li 
> > > > > > > ---
> > > > > > > Change in v3:
> > > > > > >   - rename property name
> > > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > > > >
> > > > > > > Change in v2:
> > > > > > >   - update desc of the property 'fsl,rcpm-scfg'
> > > > > > >
> > > > > > >  Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > > > ++
> > > > > > >  1 file changed, 14 insertions(+)
> > > > > > >
> > > > > > > diff --git
> > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > @@ -34,6 +34,11 @@ Chassis VersionExample
> Chips
> > > > > > >  Optional properties:
> > > > > > >   - little-endian : RCPM register block is Little Endian.
> > > > > > > Without it
> > RCPM
> > > > > > > will be Big Endian (default case).
> > > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > > > > + LS1021A,
> > > > > >
> > > > > > You probably should mention this is related to a hardware
> > > > > > issue on LS1021a and only needed on LS1021a.
> > > > > Okay, got it, thanks, I will add this in v4.
> > > > > >
> > > > > > > +   Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such 
> > > > > > > as:
> > > > > > > +   #fsl,rcpm-wakeup-cells equal to 2, then must include 2 +
> > > > > > > + 1
> > entries).
> > > > > >
> > > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on
> > > > > > an
> > SoC.
> > > > > > However you are defining an offset to scfg registers here.
> > > > > > Why these two are related?  The length here should actually be
> > > > > > related to the #address-cells of the soc/.  But since this is
> > > > > > only needed for LS1021, you can
> > > > > just make it 3.
> > > > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0
> > > > > device node(fsl,rcpm-wakeup = < 0x0 0x2000>;
> > > > > 0x0 is a value for IPPDEXPCR0, 0x2000 is a value for
> > IPPDEXPCR1).
> > > > > But because of the hardware issue on LS1021A, I need store the
> > > > > value of IPPDEXPCR registers to an alt address. So I defining an
> > > > > offset to scfg registers, then RCPM driver get an abosolute
> > > > > address from offset, RCPM driver write the value of IPPDEXPCR
> > > > > registers to these abosolute addresses(backup the value of
> > > > > IPPDEXPCR
> > registers).
> > > >
> > > > I understand what you are trying to do.  The problem is that the
> > > > new fsl,ippdexpcr-alt-addr property contains a phandle and an offset.
> > > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> > > You maybe like this: fsl,ippdexpcr-alt-addr = < 0x51c>;/*
> > > SCFG_SPARECR8 */
> >
> > No.  The #address-cell for the soc/ is 2, so the offset to scfg should
> > be 0x0 0x51c.  The total size should be 3, but it shouldn't be coming
> > from #fsl,rcpm-wakeup-cells like you mentioned in the binding.
> Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative with 
> #address-cells
> instead of #fsl,rcpm-wakeup-cells.

Yes.

Regards,
Leo
> >
> > > >
> > > > > >
> > > > > > > +   The first entry must be a link to the SCFG device node.
> > > > > > > +   The non-first entry must be offset of registers of SCFG.
> > > > > > >
> > > > > > >  Example:
> > > > > > >  The RCPM node for T4240:
> > > > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > > >   #fsl,rcpm-wakeup-cells = <2>;
> > > > > > >   };
> > > > > > >
> > > > > > > +The RCPM node for LS1021A:
> > > > > > > + rcpm: rcpm@1ee2140 {
> > > > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> > > 2.1+";
> > > > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > + fsl,ippdexpcr-alt-addr = < 0x0 0x51c>; /*
> > > > > > > SCFG_SPARECR8 */
> > > > > > > + };
> > > > > > > +
> > > > > > > +
> > > > > > >  * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > >  ---
> > > > > > >  Required fsl,rcpm-wakeup property should be added to a
> > > > > > > device node if the device
> > > > > > > --
> > > > > > > 2.17.1

RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property

[Leo Li]

> -Original Message-
> From: Biwen Li
> Sent: Tuesday, September 24, 2019 10:30 PM
> To: Leo Li ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-
> addr' property
> 
> > > > >
> > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an
> > > > > errata
> > > > > A-008646 on LS1021A
> > > > >
> > > > > Signed-off-by: Biwen Li 
> > > > > ---
> > > > > Change in v3:
> > > > >   - rename property name
> > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > >
> > > > > Change in v2:
> > > > >   - update desc of the property 'fsl,rcpm-scfg'
> > > > >
> > > > >  Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > ++
> > > > >  1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > @@ -34,6 +34,11 @@ Chassis VersionExample Chips
> > > > >  Optional properties:
> > > > >   - little-endian : RCPM register block is Little Endian. Without it 
> > > > > RCPM
> > > > > will be Big Endian (default case).
> > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > > + LS1021A,
> > > >
> > > > You probably should mention this is related to a hardware issue on
> > > > LS1021a and only needed on LS1021a.
> > > Okay, got it, thanks, I will add this in v4.
> > > >
> > > > > +   Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > > > +   #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 
> > > > > entries).
> > > >
> > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.
> > > > However you are defining an offset to scfg registers here.  Why
> > > > these two are related?  The length here should actually be related
> > > > to the #address-cells of the soc/.  But since this is only needed
> > > > for LS1021, you can
> > > just make it 3.
> > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device
> > > node(fsl,rcpm-wakeup = < 0x0 0x2000>;
> > > 0x0 is a value for IPPDEXPCR0, 0x2000 is a value for IPPDEXPCR1).
> > > But because of the hardware issue on LS1021A, I need store the value
> > > of IPPDEXPCR registers to an alt address. So I defining an offset to
> > > scfg registers, then RCPM driver get an abosolute address from
> > > offset, RCPM driver write the value of IPPDEXPCR registers to these
> > > abosolute addresses(backup the value of IPPDEXPCR registers).
> >
> > I understand what you are trying to do.  The problem is that the new
> > fsl,ippdexpcr-alt-addr property contains a phandle and an offset.  The
> > size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> You maybe like this: fsl,ippdexpcr-alt-addr = < 0x51c>;/*
> SCFG_SPARECR8 */

No.  The #address-cell for the soc/ is 2, so the offset to scfg should be 0x0 
0x51c.  The total size should be 3, but it shouldn't be coming from 
#fsl,rcpm-wakeup-cells like you mentioned in the binding.

> >
> > > >
> > > > > +   The first entry must be a link to the SCFG device node.
> > > > > +   The non-first entry must be offset of registers of SCFG.
> > > > >
> > > > >  Example:
> > > > >  The RCPM node for T4240:
> > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > >   #fsl,rcpm-wakeup-cells = <2>;
> > > > >   };
> > > > >
> > > > > +The RCPM node for LS1021A:
> > > > > + rcpm: rcpm@1ee2140 {
> > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> 2.1+";
> > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > + fsl,ippdexpcr-alt-addr = < 0x0 0x51c>; /*
> > > > > SCFG_SPARECR8 */
> > > > > + };
> > > > > +
> > > > > +
> > > > >  * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > >  ---
> > > > >  Required fsl,rcpm-wakeup property should be added to a device
> > > > > node if the device
> > > > > --
> > > > > 2.17.1

RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property

[Leo Li]

> -Original Message-
> From: Biwen Li
> Sent: Tuesday, September 24, 2019 10:13 PM
> To: Leo Li ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-
> addr' property
> 
> > >
> > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata
> > > A-008646 on LS1021A
> > >
> > > Signed-off-by: Biwen Li 
> > > ---
> > > Change in v3:
> > >   - rename property name
> > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > >
> > > Change in v2:
> > >   - update desc of the property 'fsl,rcpm-scfg'
> > >
> > >  Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > ++
> > >  1 file changed, 14 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > index 5a33619d881d..157dcf6da17c 100644
> > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > @@ -34,6 +34,11 @@ Chassis VersionExample Chips
> > >  Optional properties:
> > >   - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > will be Big Endian (default case).
> > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC LS1021A,
> >
> > You probably should mention this is related to a hardware issue on
> > LS1021a and only needed on LS1021a.
> Okay, got it, thanks, I will add this in v4.
> >
> > > +   Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > +   #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
> >
> > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.
> > However you are defining an offset to scfg registers here.  Why these
> > two are related?  The length here should actually be related to the
> > #address-cells of the soc/.  But since this is only needed for LS1021, you 
> > can
> just make it 3.
> I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device
> node(fsl,rcpm-wakeup = < 0x0 0x2000>;
> 0x0 is a value for IPPDEXPCR0, 0x2000 is a value for IPPDEXPCR1).
> But because of the hardware issue on LS1021A, I need store the value of
> IPPDEXPCR registers to an alt address. So I defining an offset to scfg 
> registers,
> then RCPM driver get an abosolute address from offset,  RCPM driver write
> the value of IPPDEXPCR registers to these abosolute addresses(backup the
> value of IPPDEXPCR registers).

I understand what you are trying to do.  The problem is that the new 
fsl,ippdexpcr-alt-addr property contains a phandle and an offset.  The size of 
it shouldn't be related to #fsl,rcpm-wakeup-cells.

> >
> > > +   The first entry must be a link to the SCFG device node.
> > > +   The non-first entry must be offset of registers of SCFG.
> > >
> > >  Example:
> > >  The RCPM node for T4240:
> > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > >   #fsl,rcpm-wakeup-cells = <2>;
> > >   };
> > >
> > > +The RCPM node for LS1021A:
> > > + rcpm: rcpm@1ee2140 {
> > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
> > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > + #fsl,rcpm-wakeup-cells = <2>;
> > > + fsl,ippdexpcr-alt-addr = < 0x0 0x51c>; /*
> > > SCFG_SPARECR8 */
> > > + };
> > > +
> > > +
> > >  * Freescale RCPM Wakeup Source Device Tree Bindings
> > >  ---
> > >  Required fsl,rcpm-wakeup property should be added to a device node
> > > if the device
> > > --
> > > 2.17.1

RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property

[Leo Li]

> -Original Message-
> From: Biwen Li 
> Sent: Monday, September 23, 2019 9:46 PM
> To: Leo Li ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Biwen Li
> 
> Subject: [v3,3/3] Documentation: dt: binding: fsl: Add 
> 'fsl,ippdexpcr-alt-addr'
> property
> 
> The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata A-008646 on
> LS1021A
> 
> Signed-off-by: Biwen Li 
> ---
> Change in v3:
>   - rename property name
> fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> 
> Change in v2:
>   - update desc of the property 'fsl,rcpm-scfg'
> 
>  Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> index 5a33619d881d..157dcf6da17c 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> @@ -34,6 +34,11 @@ Chassis VersionExample Chips
>  Optional properties:
>   - little-endian : RCPM register block is Little Endian. Without it RCPM
> will be Big Endian (default case).
> + - fsl,ippdexpcr-alt-addr : Must add the property for SoC LS1021A,

You probably should mention this is related to a hardware issue on LS1021a and 
only needed on LS1021a.

> +   Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> +   #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).

#fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.  However 
you are defining an offset to scfg registers here.  Why these two are related?  
The length here should actually be related to the #address-cells of the soc/.  
But since this is only needed for LS1021, you can just make it 3.

> +   The first entry must be a link to the SCFG device node.
> +   The non-first entry must be offset of registers of SCFG.
> 
>  Example:
>  The RCPM node for T4240:
> @@ -43,6 +48,15 @@ The RCPM node for T4240:
>   #fsl,rcpm-wakeup-cells = <2>;
>   };
> 
> +The RCPM node for LS1021A:
> + rcpm: rcpm@1ee2140 {
> + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
> + reg = <0x0 0x1ee2140 0x0 0x8>;
> + #fsl,rcpm-wakeup-cells = <2>;
> + fsl,ippdexpcr-alt-addr = < 0x0 0x51c>; /*
> SCFG_SPARECR8 */
> + };
> +
> +
>  * Freescale RCPM Wakeup Source Device Tree Bindings
>  ---
>  Required fsl,rcpm-wakeup property should be added to a device node if the
> device
> --
> 2.17.1

RE: rtc: pcf85363/pcf85263: fix error that failed to run hwclock -w

[Leo Li]

> -Original Message-
> From: Biwen Li
> Sent: Wednesday, August 14, 2019 11:15 PM
> To: Leo Li ; a.zu...@towertech.it;
> alexandre.bell...@bootlin.com
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: rtc: pcf85363/pcf85263: fix error that failed to run hwclock -w
> 
> > > Subject: rtc: pcf85363/pcf85263: fix error that failed to run
> > > hwclock -w
> > >
> > > Issue:
> > > # hwclock -w
> > > hwclock: RTC_SET_TIME: Invalid argument
> > >
> > > The patch fixes error when run command hwclock -w with rtc
> > > pcf85363/pcf85263
> >
> > Can you explain a little bit more in the commit message on how the
> changes fix
> > the above issue?   It is not that clear just from the code.
> 1. Relative patch: https://lkml.org/lkml/2019/4/3/55 , this patch will always
> check for unwritable registers, it will compare reg with max_register in
> regmap_writeable.
> 
> 2. In drivers/rtc/rtc-pcf85363.c, CTRL_STOP_EN is 0x2e, but DT_100THS is 0,
> max_regiter is 0x2f, then reg will be equal to 0x30, '0x30 < 0x2f' is false,so
> regmap_writeable will return false.

>From you description, it looks like the problem is actually that the buf[] was 
>written to a wrong place.  If that's the case, we should say that in the 
>commit message.

> 
> >
> > >
> > > Signed-off-by: Biwen Li 
> > > ---
> > >  drivers/rtc/rtc-pcf85363.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
> > > index a075e77617dc..3450d615974d 100644
> > > --- a/drivers/rtc/rtc-pcf85363.c
> > > +++ b/drivers/rtc/rtc-pcf85363.c
> > > @@ -166,7 +166,12 @@ static int pcf85363_rtc_set_time(struct device
> > > *dev, struct rtc_time *tm)
> > >   buf[DT_YEARS] = bin2bcd(tm->tm_year % 100);
> > >
> > >   ret = regmap_bulk_write(pcf85363->regmap, CTRL_STOP_EN,
> > > - tmp, sizeof(tmp));
> > > + tmp, 2);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = regmap_bulk_write(pcf85363->regmap, DT_100THS,
> > > + buf, sizeof(tmp) - 2);
> > >   if (ret)
> > >   return ret;
> > >
> > > --
> > > 2.17.1

RE: rtc: pcf85363/pcf85263: fix error that failed to run hwclock -w

[Leo Li]

> -Original Message-
> From: Biwen Li 
> Sent: Wednesday, August 14, 2019 4:33 AM
> To: a.zu...@towertech.it; alexandre.bell...@bootlin.com; Leo Li
> 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Biwen Li
> 
> Subject: rtc: pcf85363/pcf85263: fix error that failed to run hwclock -w
> 
> Issue:
> # hwclock -w
> hwclock: RTC_SET_TIME: Invalid argument
> 
> The patch fixes error when run command hwclock -w
> with rtc pcf85363/pcf85263

Can you explain a little bit more in the commit message on how the changes fix 
the above issue?   It is not that clear just from the code.

> 
> Signed-off-by: Biwen Li 
> ---
>  drivers/rtc/rtc-pcf85363.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
> index a075e77617dc..3450d615974d 100644
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
> @@ -166,7 +166,12 @@ static int pcf85363_rtc_set_time(struct device *dev,
> struct rtc_time *tm)
>   buf[DT_YEARS] = bin2bcd(tm->tm_year % 100);
> 
>   ret = regmap_bulk_write(pcf85363->regmap, CTRL_STOP_EN,
> - tmp, sizeof(tmp));
> + tmp, 2);
> + if (ret)
> + return ret;
> +
> + ret = regmap_bulk_write(pcf85363->regmap, DT_100THS,
> + buf, sizeof(tmp) - 2);
>   if (ret)
>   return ret;
> 
> --
> 2.17.1

RE: [PATCH] arm64: dts: ls1028a: fix gpio nodes

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Monday, August 12, 2019 8:47 AM
> To: Hui Song ; Leo Li 
> Cc: Rob Herring ; Mark Rutland
> ; Linus Walleij ; Bartosz
> Golaszewski ; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-g...@vger.kernel.org
> Subject: Re: [PATCH] arm64: dts: ls1028a: fix gpio nodes
> 
> On Mon, Aug 05, 2019 at 02:57:00PM +0800, Hui Song wrote:
> > From: Song Hui 
> >
> > Update the nodes to include little-endian property to be consistent
> > with the hardware.
> >
> > Signed-off-by: Song Hui 
> 
> @Leo, looks good?

Acked-by: Li Yang 

> 
> Shawn
> 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > index aef5b06..7ccbbfc 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > @@ -277,33 +277,36 @@
> > };
> >
> > gpio1: gpio@230 {
> > -   compatible = "fsl,qoriq-gpio";
> > +   compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
> > reg = <0x0 0x230 0x0 0x1>;
> > interrupts = ;
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > +   little-endian;
> > };
> >
> > gpio2: gpio@231 {
> > -   compatible = "fsl,qoriq-gpio";
> > +   compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
> > reg = <0x0 0x231 0x0 0x1>;
> > interrupts = ;
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > +   little-endian;
> > };
> >
> > gpio3: gpio@232 {
> > -   compatible = "fsl,qoriq-gpio";
> > +   compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
> > reg = <0x0 0x232 0x0 0x1>;
> > interrupts = ;
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > +   little-endian;
> > };
> >
> > usb0: usb@310 {
> > --
> > 2.9.5
> >

RE: [PATCH 1/4] arm64: dts: ls1088a: Fix incorrect I2C clock divider

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Monday, August 12, 2019 9:17 AM
> To: Chuanhua Han 
> Cc: Leo Li ; robh...@kernel.org;
> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/4] arm64: dts: ls1088a: Fix incorrect I2C clock divider
> 
> On Tue, Aug 06, 2019 at 04:42:20PM +0800, Chuanhua Han wrote:
> > Ls1088a platform, the i2c input clock is actually platform pll CLK / 8
> > (this is the hardware connection), other clock divider can not get the
> > correct i2c clock, resulting in the output of SCL pin clock is not
> > accurate.
> >
> > Signed-off-by: Chuanhua Han 
> 
> @Leo, looks good?

Yes.

Acked-by: Li Yang 

> 
> Shawn
> 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > index 20f5ebd..30b760e 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > @@ -324,7 +324,7 @@
> > #size-cells = <0>;
> > reg = <0x0 0x200 0x0 0x1>;
> > interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
> > -   clocks = < 4 3>;
> > +   clocks = < 4 7>;
> > status = "disabled";
> > };
> >
> > @@ -334,7 +334,7 @@
> > #size-cells = <0>;
> > reg = <0x0 0x201 0x0 0x1>;
> > interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
> > -   clocks = < 4 3>;
> > +   clocks = < 4 7>;
> > status = "disabled";
> > };
> >
> > @@ -344,7 +344,7 @@
> > #size-cells = <0>;
> > reg = <0x0 0x202 0x0 0x1>;
> > interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
> > -   clocks = < 4 3>;
> > +   clocks = < 4 7>;
> > status = "disabled";
> > };
> >
> > @@ -354,7 +354,7 @@
> > #size-cells = <0>;
> > reg = <0x0 0x203 0x0 0x1>;
> > interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
> > -   clocks = < 4 3>;
> > +   clocks = < 4 7>;
> > status = "disabled";
> > };
> >
> > --
> > 2.9.5
> >

RE: [PATCH] dmaengine: fsldma: Mark expected switch fall-through

[Leo Li]

> -Original Message-
> From: Gustavo A. R. Silva 
> Sent: Sunday, August 11, 2019 7:22 PM
> To: Leo Li ; Zhang Wei ; Vinod
> Koul ; Dan Williams 
> Cc: linuxppc-...@lists.ozlabs.org; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Gustavo A. R. Silva 
> Subject: [PATCH] dmaengine: fsldma: Mark expected switch fall-through
> 
> Mark switch cases where we are expecting to fall through.
> 
> Fix the following warning (Building: powerpc-ppa8548_defconfig powerpc):
> 
> drivers/dma/fsldma.c: In function ‘fsl_dma_chan_probe’:
> drivers/dma/fsldma.c:1165:26: warning: this statement may fall through [-
> Wimplicit-fallthrough=]
>chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
>~~~^~~
> drivers/dma/fsldma.c:1166:2: note: here
>   case FSL_DMA_IP_83XX:
>   ^~~~
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Li Yang 

> ---
>  drivers/dma/fsldma.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index
> 23e0a356f167..ad72b3f42ffa 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1163,6 +1163,7 @@ static int fsl_dma_chan_probe(struct
> fsldma_device *fdev,
>   switch (chan->feature & FSL_DMA_IP_MASK) {
>   case FSL_DMA_IP_85XX:
>   chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
> + /* Fall through */
>   case FSL_DMA_IP_83XX:
>   chan->toggle_ext_start = fsl_chan_toggle_ext_start;
>   chan->set_src_loop_size = fsl_chan_set_src_loop_size;
> --
> 2.22.0

RE: [PATCH v6 40/57] soc: Remove dev_err() usage after platform_get_irq()

[Leo Li]

> -Original Message-
> From: Bjorn Andersson 
> Sent: Tuesday, July 30, 2019 1:35 PM
> To: Stephen Boyd 
> Cc: linux-kernel@vger.kernel.org; Andy Gross ;
> Thierry Reding ; Leo Li ; Simon
> Horman ; Greg Kroah-Hartman
> 
> Subject: Re: [PATCH v6 40/57] soc: Remove dev_err() usage after
> platform_get_irq()
> 
> On Tue 30 Jul 11:15 PDT 2019, Stephen Boyd wrote:
> 
> > We don't need dev_err() messages when platform_get_irq() fails now
> > that
> > platform_get_irq() prints an error message itself when something goes
> > wrong. Let's remove these prints with a simple semantic patch.
> >
> > // 
> > @@
> > expression ret;
> > struct platform_device *E;
> > @@
> >
> > ret =
> > (
> > platform_get_irq(E, ...)
> > |
> > platform_get_irq_byname(E, ...)
> > );
> >
> > if ( \( ret < 0 \| ret <= 0 \) )
> > {
> > (
> > -if (ret != -EPROBE_DEFER)
> > -{ ...
> > -dev_err(...);
> > -... }
> > |
> > ...
> > -dev_err(...);
> > )
> > ...
> > }
> > // 
> >
> > While we're here, remove braces on if statements that only have one
> > statement (manually).
> >
> > Cc: Andy Gross 
> > Cc: Thierry Reding 
> > Cc: Bjorn Andersson 
> 
> Reviewed-by: Bjorn Andersson 
> 
> > Cc: Li Yang 
> > Cc: Simon Horman 
> > Cc: Greg Kroah-Hartman 
> > Signed-off-by: Stephen Boyd 
> > ---
> >
> > Please apply directly to subsystem trees
> >
> >  drivers/soc/fsl/qbman/bman_portal.c | 4 +---
> > drivers/soc/fsl/qbman/qman_portal.c | 4 +---
> >  drivers/soc/qcom/smp2p.c| 4 +---
> 
> If you had split this in a fsl and a qcom patch I would have just merged the
> latter.
> 
> I don't see a problem with Li taking this patch through the Freescale tree
> though (or vise versa).

The patch looks good to me too.  I can take it through my tree with your 
reviewed-by.

Regards,
Leo
> 
> Regards,
> Bjorn
> 
> >  3 files changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_portal.c
> > b/drivers/soc/fsl/qbman/bman_portal.c
> > index cf4f10d6f590..e4ef35abb508 100644
> > --- a/drivers/soc/fsl/qbman/bman_portal.c
> > +++ b/drivers/soc/fsl/qbman/bman_portal.c
> > @@ -135,10 +135,8 @@ static int bman_portal_probe(struct
> platform_device *pdev)
> > pcfg->cpu = -1;
> >
> > irq = platform_get_irq(pdev, 0);
> > -   if (irq <= 0) {
> > -   dev_err(dev, "Can't get %pOF IRQ'\n", node);
> > +   if (irq <= 0)
> > goto err_ioremap1;
> > -   }
> > pcfg->irq = irq;
> >
> > pcfg->addr_virt_ce = memremap(addr_phys[0]->start, diff --git
> > a/drivers/soc/fsl/qbman/qman_portal.c
> > b/drivers/soc/fsl/qbman/qman_portal.c
> > index e2186b681d87..991c35a72e00 100644
> > --- a/drivers/soc/fsl/qbman/qman_portal.c
> > +++ b/drivers/soc/fsl/qbman/qman_portal.c
> > @@ -275,10 +275,8 @@ static int qman_portal_probe(struct
> platform_device *pdev)
> > pcfg->channel = val;
> > pcfg->cpu = -1;
> > irq = platform_get_irq(pdev, 0);
> > -   if (irq <= 0) {
> > -   dev_err(dev, "Can't get %pOF IRQ\n", node);
> > +   if (irq <= 0)
> > goto err_ioremap1;
> > -   }
> > pcfg->irq = irq;
> >
> > pcfg->addr_virt_ce = memremap(addr_phys[0]->start, diff --git
> > a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c index
> > c7300d54e444..07183d731d74 100644
> > --- a/drivers/soc/qcom/smp2p.c
> > +++ b/drivers/soc/qcom/smp2p.c
> > @@ -474,10 +474,8 @@ static int qcom_smp2p_probe(struct
> platform_device *pdev)
> > goto report_read_failure;
> >
> > irq = platform_get_irq(pdev, 0);
> > -   if (irq < 0) {
> > -   dev_err(>dev, "unable to acquire smp2p interrupt\n");
> > +   if (irq < 0)
> > return irq;
> > -   }
> >
> > smp2p->mbox_client.dev = >dev;
> > smp2p->mbox_client.knows_txdone = true;
> > --
> > Sent by a computer through tubes
> >

RE: [v5,2/2] Documentation: dt: binding: rtc: add binding for ftm alarm driver

[Leo Li]

> -Original Message-
> From: Biwen Li 
> Sent: Tuesday, July 16, 2019 5:17 AM
> To: a.zu...@towertech.it; alexandre.bell...@bootlin.com; Leo Li
> ; robh...@kernel.org
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo Xie
> ; Jiafei Pan ; Ran Wang
> ; mark.rutl...@arm.com;
> devicet...@vger.kernel.org; Biwen Li 
> Subject: [v5,2/2] Documentation: dt: binding: rtc: add binding for ftm alarm
> driver
> 
> The patch adds binding for ftm alarm driver
> 
> Signed-off-by: Biwen Li 
> ---
> Change in v5:
> - None
> 
> Change in v4:
> - add note about dts and kernel options
> - add aliases in example
> 
> Change in v3:
>   - remove reg-names property
>   - correct cells number
> 
> Change in v2:
>   - replace ls1043a with ls1088a as example
>   - add rcpm node and fsl,rcpm-wakeup property
> 
> 
>  .../bindings/rtc/rtc-fsl-ftm-alarm.txt| 49 +++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-
> alarm.txt
> 
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> new file mode 100644
> index ..fb018065406c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> @@ -0,0 +1,49 @@
> +Freescale FlexTimer Module (FTM) Alarm
> +
> +Note:
> +- The driver depends on RCPM driver
> +  to wake up system in sleep.
> +- Need stop using RTC_HCTOSYS or use the DT aliases
> +  to ensure the driver is not used as the primary RTC.
> +  (Select DT aliases defaultly)
> +
> +Required properties:
> +- compatible : Should be "fsl,-ftm-alarm", the
> +supported chips include
> +"fsl,ls1012a-ftm-alarm"
> +"fsl,ls1021a-ftm-alarm"
> +"fsl,ls1028a-ftm-alarm"
> +"fsl,ls1043a-ftm-alarm"
> +"fsl,ls1046a-ftm-alarm"
> +"fsl,ls1088a-ftm-alarm"
> +"fsl,ls208xa-ftm-alarm"
> +- reg : Specifies base physical address and size of the register sets for the
> +  FlexTimer Module and base physical address of IP Powerdown Exception
> Control
> +  Register.

You removed the IP Powerdown exception register in the examples, but not here.

> +- interrupts : Should be the FlexTimer Module interrupt.
> +- fsl,rcpm-wakeup property and rcpm node : Please refer
> + Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> +
> +Optional properties:
> +- big-endian: If the host controller is big-endian mode, specify this 
> property.
> +  The default endian mode is little-endian.
> +
> +Example:
> +aliases {
> + ...
> + rtc1 = ftm_alarm0; /* Use flextimer alarm driver as /dev/rtc1 */
> + ...
> +};
> +
> +rcpm: rcpm@1e34040 {
> + compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
> + reg = <0x0 0x1e34040 0x0 0x18>;
> + fsl,#rcpm-wakeup-cells = <6>;
> +};
> +
> +ftm_alarm0: timer@280 {
> + compatible = "fsl,ls1088a-ftm-alarm";
> + reg = <0x0 0x280 0x0 0x1>;
> + fsl,rcpm-wakeup = < 0x0 0x0 0x0 0x0 0x4000 0x0>;
> + interrupts = <0 44 4>;
> +};
> --
> 2.17.1

RE: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup source

[Leo Li]

> -Original Message-
> From: Biwen Li 
> Sent: Friday, July 5, 2019 5:18 AM
> To: a.zu...@towertech.it; alexandre.bell...@bootlin.com; Leo Li
> 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo Xie
> ; Jiafei Pan ; Ran Wang
> ; Biwen Li 
> Subject: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup source
> 
> For the paltforms including LS1012A, LS1021A, LS1028A, LS1043A, LS1046A,
> LS1088A, LS208xA that has the FlexTimer module, implementing alarm
> functions within RTC subsystem to wakeup the system when system going to
> sleep.
> 
> Signed-off-by: Biwen Li 
> ---
>  drivers/rtc/Kconfig |  14 ++
>  drivers/rtc/Makefile|   1 +
>  drivers/rtc/rtc-fsl-ftm-alarm.c | 417
> 
>  3 files changed, 432 insertions(+)
>  create mode 100644 drivers/rtc/rtc-fsl-ftm-alarm.c
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 03b60d5..0758a08
> 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1313,6 +1313,20 @@ config RTC_DRV_IMXDI
>  This driver can also be built as a module, if so, the module
>  will be called "rtc-imxdi".
> 
> +config RTC_DRV_FSL_FTM_ALARM
> + tristate "Freescale FlexTimer alarm timer"
> + depends on ARCH_LAYERSCAPE
> + default y
> + help
> +For the FlexTimer in LS1012A, LS1021A, LS1028A, LS1043A, LS1046A,
> +LS1088A, LS208xA, we can use FTM as the wakeup source.
> +
> +Say y here to enable FTM alarm support. The FTM alarm provides
> +alarm functions for wakeup system from deep sleep.
> +
> +This driver can also be built as a module, if so, the module
> +will be called "rtc-fsl-ftm-alarm".
> +
>  config RTC_DRV_MESON
>   tristate "Amlogic Meson RTC"
>   depends on (ARM && ARCH_MESON) || COMPILE_TEST diff --git
> a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 9d997fa..5cccb07 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -79,6 +79,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-
> hid-sensor-time.o
>  obj-$(CONFIG_RTC_DRV_HYM8563)+= rtc-hym8563.o
>  obj-$(CONFIG_RTC_DRV_IMXDI)  += rtc-imxdi.o
>  obj-$(CONFIG_RTC_DRV_IMX_SC) += rtc-imx-sc.o
> +obj-$(CONFIG_RTC_DRV_FSL_FTM_ALARM)  += rtc-fsl-ftm-alarm.o
>  obj-$(CONFIG_RTC_DRV_ISL12022)   += rtc-isl12022.o
>  obj-$(CONFIG_RTC_DRV_ISL12026)   += rtc-isl12026.o
>  obj-$(CONFIG_RTC_DRV_ISL1208)+= rtc-isl1208.o
> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
> new file mode 100644 index 000..e4075f0
> --- /dev/null
> +++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
> @@ -0,0 +1,417 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Freescale FlexTimer Module (FTM) alarm device driver.
> + *
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2019 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_MASK_SHIFT)
> +
> +/*
> + * Select Fixed frequency clock as clock source
> + * of FlexTimer Module
> + */
> +#define FTM_SC_CLKS_FIXED_FREQ   0x02
> +
> +#define FIXED_FREQ_CLK   32000
> +#define MAX_FREQ_DIV (1 << FTM_SC_PS_MASK)
> +#define MAX_COUNT_VAL0x
> +
> +struct ftm_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem *base;
> + bool endian;
> + u32 alarm_freq;
> +};
> +
> +enum pmu_endian_type {
> + BIG_ENDIAN,
> + LITTLE_ENDIAN,
> +};
> +
> +/*
> + * rcpm (Run Control and Power Management)
> + * is another IP block,different IP block
> + * has different endianness,so add new element
> + * big_endian to struct rcpm_cfg.
> + */
> +struct rcpm_cfg {
> + enum pmu_endian_type big_endian; /* Big/Little endian of PMU
> module */
> + u32 flextimer_set_bit;  /* FTM is not powerdown during device
> sleep */
> +};
> +
> +static struct rcpm_cfg default_rcpm_cfg = {
> + .big_endian = LITTLE_ENDIAN,
> + .flextimer_set_bit = 0x4000,
> +};
> +
> +static struct rcpm_cfg ls1012a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> +

RE: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3)

[Leo Li]

> -Original Message-
> From: Leo Li
> Sent: Monday, June 17, 2019 8:29 AM
> To: Olof Johansson 
> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; shawn...@kernel.org
> Subject: RE: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3)
> 
> 
> 
> > -Original Message-
> > From: Olof Johansson 
> > Sent: Monday, June 17, 2019 6:50 AM
> > To: Leo Li 
> > Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > ker...@vger.kernel.org; shawn...@kernel.org
> > Subject: Re: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3)
> >
> > On Wed, Jun 05, 2019 at 02:45:11PM -0500, Li Yang wrote:
> > > Hi arm-soc maintainers,
> > >
> > > This is a rebase of patches that missed 5.2 merge window together
> > > with some new patches for QE.  Please help to review and merge it.
> > > We would like this to be merged earlier because there are other
> > > patches depending on patches in this pull request.  After this is
> > > merged in arm-soc, we can ask other sub-system maintainers to pull
> > > from this tag and apply additional patches.  Thanks.
> >
> > Li,
> >
> > You never followed up with a reply, or removed, the previous tag. So
> > when we process the pull requests that come in, we've already merged it.
> 
> Sorry about that.  Will reply the previous pull request and remove the old tag
> if update is needed next time.
> 
> >
> > So, I've merged the previous version. Can you send an incremental pull
> > request on top of that branch/tag instead of a rebase like this was, please?
> 
> Actually the new pull request is based on the old pull request this time.  I
> sent the new one as V2 hoping that you can see this first and avoid merging
> two times.  Since you have already merged the first one, you can merge the
> second pull request as an incremental pull request directly.

Hi Olof,

I was on vacation for the past two weeks to follow up on this.  Hope this is 
not too late for this merge window.  Like I mentioned, the new tag is on top of 
the previous tag (you merged) so that it should be able to be merged 
incrementally.  The only thing is that the description of the new tag also 
included patches you merged with old tag.  Do you want me to regenerate the tag 
before you can merge it?

Regards,
Leo

RE: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3)

[Leo Li]

> -Original Message-
> From: Olof Johansson 
> Sent: Monday, June 17, 2019 6:50 AM
> To: Leo Li 
> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; shawn...@kernel.org
> Subject: Re: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3)
> 
> On Wed, Jun 05, 2019 at 02:45:11PM -0500, Li Yang wrote:
> > Hi arm-soc maintainers,
> >
> > This is a rebase of patches that missed 5.2 merge window together with
> > some new patches for QE.  Please help to review and merge it.  We
> > would like this to be merged earlier because there are other patches
> > depending on patches in this pull request.  After this is merged in
> > arm-soc, we can ask other sub-system maintainers to pull from this tag
> > and apply additional patches.  Thanks.
> 
> Li,
> 
> You never followed up with a reply, or removed, the previous tag. So when
> we process the pull requests that come in, we've already merged it.

Sorry about that.  Will reply the previous pull request and remove the old tag 
if update is needed next time.

> 
> So, I've merged the previous version. Can you send an incremental pull
> request on top of that branch/tag instead of a rebase like this was, please?

Actually the new pull request is based on the old pull request this time.  I 
sent the new one as V2 hoping that you can see this first and avoid merging two 
times.  Since you have already merged the first one, you can merge the second 
pull request as an incremental pull request directly.

Regards,
Leo

> 
> 
> Thanks!
> 
> -Olof

RE: [PATCH] arm64: defconfig: Enable FSL_EDMA driver

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Wednesday, June 12, 2019 7:45 PM
> To: Leo Li 
> Cc: Madalin-cristian Bucur ; Rob Herring
> ; Aisheng Dong ; Vinod Koul
> ; Grant Likely ; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE  ker...@lists.infradead.org>; lkml 
> Subject: Re: [PATCH] arm64: defconfig: Enable FSL_EDMA driver
> 
> On Wed, Jun 12, 2019 at 03:01:29PM -0500, Li Yang wrote:
> > On Thu, May 9, 2019 at 10:15 PM Shawn Guo 
> wrote:
> > >
> > > On Mon, Apr 22, 2019 at 01:30:56PM -0500, Li Yang wrote:
> > > > Enables the FSL EDMA driver by default.  This also works around an
> > > > issue that imx-i2c driver keeps deferring the probe because of the
> > > > DMA is not ready.  And currently the DMA engine framework can not
> > > > correctly tell if the DMA channels will truly become available
> > > > later (it will never be available if the DMA driver is not enabled).
> > > >
> > > > This will cause indefinite messages like below:
> > > > [3.335829] imx-i2c 218.i2c: can't get pinctrl, bus recovery not
> supported
> > > > [3.344455] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000
> uOhm)
> > > > [3.350917] lm90 0-004c: 0-004c supply vcc not found, using dummy
> regulator
> > > > [3.362089] imx-i2c 218.i2c: can't get pinctrl, bus recovery not
> supported
> > > > [3.370741] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000
> uOhm)
> > > > [3.377205] lm90 0-004c: 0-004c supply vcc not found, using dummy
> regulator
> > > > [3.388455] imx-i2c 218.i2c: can't get pinctrl, bus recovery not
> supported
> > > > .
> > > >
> > > > Signed-off-by: Li Yang 
> > >
> > > Applied, thanks.
> >
> > Hi Shawn,
> >
> > Is it possible to move this patch to the -fix series so that it can
> > reach the mainline earlier?  It is having a boot failure in mainline
> > for platforms using this device without this workaround.
> 
> Why would I2C device deferring cause boot failure on a platform?  I'm just
> trying to understand severity of the problem.

Currently the probe of imx-i2c will be retried immediately after it is deferred 
when the optional dependency on DMA driver is not met.  This will cause an 
indefinite loop of probe-defer-probe and keep printing the message as shown in 
the commit message.

On a further look into the imx-i2c driver, it looks like the driver need some 
fix too.  The requesting of dma channel is done at the very late stage of the 
imx-i2c probe after registering the i2c adapter.  Adding the i2c adapter 
triggers the probe of the i2c bus which probably immediately triggers the retry 
of deferred probe.  This was fine previously as requesting dma channel didn't 
trigger a defer.  But now it triggers defer after commit 
e1ab9a468e3b1636d60cebd0a778461270dde208.  We probably should move the 
i2c_imx_dma_request() to the beginning of the probe as it is considered as a 
dependency now.

Regards,
Leo

RE: [PATCH v3 0/6] soc/fsl/qe: cleanups and new DT binding

[Leo Li]

> -Original Message-
> From: Rasmus Villemoes 
> Sent: Monday, June 3, 2019 2:54 PM
> To: devicet...@vger.kernel.org; Qiang Zhao ; Leo Li
> 
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring ; Scott
> Wood ; Christophe Leroy ;
> Mark Rutland ; jo...@infinera.com
> 
> Subject: Re: [PATCH v3 0/6] soc/fsl/qe: cleanups and new DT binding
> 
> On 13/05/2019 13.14, Rasmus Villemoes wrote:
> > This small series consists of some small cleanups and simplifications
> > of the QUICC engine driver, and introduces a new DT binding that makes
> > it much easier to support other variants of the QUICC engine IP block
> > that appears in the wild: There's no reason to expect in general that
> > the number of valid SNUMs uniquely determines the set of such, so it's
> > better to simply let the device tree specify the values (and,
> > implicitly via the array length, also the count).
> >
> > Which tree should this go through?
> 
> Ping? These patches should be ready to go in, but I don't know who is
> supposed to pick them up.

I can pick them up through the soc/fsl tree.

Regards,
Leo

RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: Add temperature sensor node

[Leo Li]

> -Original Message-
> From: Andy Tang
> Sent: Monday, May 27, 2019 3:27 AM
> To: Leo Li 
> Cc: Shawn Guo ; Rob Herring
> ; Mark Rutland ;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE  ker...@lists.infradead.org>; open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS ; lkml  ker...@vger.kernel.org>
> Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: Add temperature sensor
> node
> 
> Hi Leo,
> 
> > -Original Message-
> > From: Li Yang 
> > Sent: 2019年5月25日 6:32
> > To: Andy Tang 
> > Cc: Shawn Guo ; Rob Herring
> ;
> > Mark Rutland ; moderated list:ARM/FREESCALE
> IMX
> > / MXC ARM ARCHITECTURE ;
> > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > ; lkml 
> > Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: Add temperature sensor
> > node
> >
> > Caution: EXT Email
> >
> > On Thu, May 23, 2019 at 8:30 PM Yuantian Tang 
> > wrote:
> > >
> > > Add nxp sa56004 chip node for temperature monitor.
> > >
> > > Signed-off-by: Yuantian Tang 
> > > ---
> > >  arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 5 +
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 5 +
> > >  2 files changed, 10 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > > index b359068d9605..31fd626dd344 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > > @@ -131,6 +131,11 @@
> > > compatible = "atmel,24c512";
> > > reg = <0x57>;
> > > };
> > > +
> > > +   temp@4c {
> >
> > The recommended name for temperature senor in dts spec is
> > temperature-sensor.
> I didn't find the spec for this recommendation. Could you please provide the
> link?

You can find the spec on https://www.devicetree.org/

> I like to update it to temp-sensor though.
> 
> >
> > > +   compatible = "nxp,sa56004";
> >
> > The binding says the following property is required.  If it is not the
> > case, probably we should update the binding.
> > - vcc-supply: vcc regulator for the supply voltage.
> I will add the vcc-supply to comply this requirement.
> 
> Thanks,
> Andy
> >
> > > +   reg = <0x4c>;
> > > +   };
> > > };
> > >
> > > i2c@5 {
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > > index f9c272fb0738..012b3f8696b7 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > > @@ -119,6 +119,11 @@
> > > compatible = "nxp,pcf2129";
> > > reg = <0x51>;
> > > };
> > > +
> > > +   temp@4c {
> > > +   compatible = "nxp,sa56004";
> > > +   reg = <0x4c>;
> > > +   };
> > > };
> > > };
> > >  };
> > > --
> > > 2.17.1
> > >

RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node

[Leo Li]

> -Original Message-
> From: Chuanhua Han
> Sent: Wednesday, May 22, 2019 1:26 AM
> To: Leo Li ; Shawn Guo 
> Cc: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying Zhang
> 
> Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node
> 
> 
> 
> > -----Original Message-
> > From: Leo Li
> > Sent: 2019年5月22日 4:15
> > To: Chuanhua Han ; Shawn Guo
> > 
> > Cc: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying Zhang
> > 
> > Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > device node
> >
> >
> >
> > > -Original Message-
> > > From: Chuanhua Han
> > > Sent: Tuesday, May 21, 2019 8:00 AM
> > > To: Leo Li ; Shawn Guo 
> > > Cc: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying Zhang
> > > 
> > > Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > > device node
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Leo Li
> > > > Sent: 2019年5月18日 6:01
> > > > To: Chuanhua Han ; Shawn Guo
> > > > 
> > > > Cc: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying
> > > > Zhang 
> > > > Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > > > device node
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Chuanhua Han
> > > > > Sent: Friday, May 17, 2019 1:11 AM
> > > > > To: Shawn Guo 
> > > > > Cc: Leo Li ; mark.rutl...@arm.com;
> > > > > linux-arm- ker...@lists.infradead.org;
> > > > > devicet...@vger.kernel.org; linux- ker...@vger.kernel.org; Ying
> > > > > Zhang 
> > > > > Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > > > > device node
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Shawn Guo 
> > > > > > Sent: 2019年5月17日 10:38
> > > > > > To: Chuanhua Han 
> > > > > > Cc: Leo Li ; mark.rutl...@arm.com;
> > > > > > linux-arm-ker...@lists.infradead.org;
> > > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying
> > > > > > Zhang 
> > > > > > Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > > > > > device node
> > > > > >
> > > > > > Caution: EXT Email
> > > > > >
> > > > > > On Thu, May 09, 2019 at 03:06:57PM +0800, Chuanhua Han wrote:
> > > > > > > ls1028a platform uses sp805 watchdog, and use 1/16 platform
> > > > > > > clock as timer clock, this patch fix device tree node.
> > > > > > >
> > > > > > > Signed-off-by: Zhang Ying-22455 
> > > > > > > Signed-off-by: Chuanhua Han 
> > > > > > > ---
> > > > > > >  .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 19
> > > > > > > ---
> > > > > > >  1 file changed, 12 insertions(+), 7 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > > > index b04581249f0b..1510b1858246 100644
> > > > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > > > @@ -285,13 +285,18 @@
> > > > > > >   #interrupt-cells = <2>;
> > > > > > >   };
> > > > > > >
> > > > > > > - wdog0: watchdog@23c {
> > > > > > > - compatible = "fsl,ls1028a-wdt",
> > "fsl,imx21-wdt";
> > > > > > > - reg = <0x0 0x23c 0x0 0x1>;
> > > > > > > -

RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node

[Leo Li]

> -Original Message-
> From: Chuanhua Han
> Sent: Tuesday, May 21, 2019 8:00 AM
> To: Leo Li ; Shawn Guo 
> Cc: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying Zhang
> 
> Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node
> 
> 
> 
> > -----Original Message-
> > From: Leo Li
> > Sent: 2019年5月18日 6:01
> > To: Chuanhua Han ; Shawn Guo
> > 
> > Cc: mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Ying Zhang
> > 
> > Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > device node
> >
> >
> >
> > > -Original Message-
> > > From: Chuanhua Han
> > > Sent: Friday, May 17, 2019 1:11 AM
> > > To: Shawn Guo 
> > > Cc: Leo Li ; mark.rutl...@arm.com; linux-arm-
> > > ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; Ying Zhang 
> > > Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > > device node
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Shawn Guo 
> > > > Sent: 2019年5月17日 10:38
> > > > To: Chuanhua Han 
> > > > Cc: Leo Li ; mark.rutl...@arm.com;
> > > > linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> > > > linux-kernel@vger.kernel.org; Ying Zhang 
> > > > Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog
> > > > device node
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Thu, May 09, 2019 at 03:06:57PM +0800, Chuanhua Han wrote:
> > > > > ls1028a platform uses sp805 watchdog, and use 1/16 platform
> > > > > clock as timer clock, this patch fix device tree node.
> > > > >
> > > > > Signed-off-by: Zhang Ying-22455 
> > > > > Signed-off-by: Chuanhua Han 
> > > > > ---
> > > > >  .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 19
> > > > > ---
> > > > >  1 file changed, 12 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > index b04581249f0b..1510b1858246 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > > @@ -285,13 +285,18 @@
> > > > >   #interrupt-cells = <2>;
> > > > >   };
> > > > >
> > > > > - wdog0: watchdog@23c {
> > > > > - compatible = "fsl,ls1028a-wdt", "fsl,imx21-wdt";
> > > > > - reg = <0x0 0x23c 0x0 0x1>;
> > > > > - interrupts =  > IRQ_TYPE_LEVEL_HIGH>;
> > > > > - clocks = < 4 1>;
> > > > > - big-endian;
> > > > > - status = "disabled";
> > > > > + cluster1_core0_watchdog: wdt@c00 {
> > > >
> > > > Keep 'watchdog' as the node name,
> > > Thanks for your replay
> > > Do you mean replace the ‘wdt’ with ‘watchdog’?
> > > and keep nodes sort in unit-address.
> > > What does this mean?
> >
> > That means order the nodes by the addresses (e.g. c00, c01)
> The current order is correct（The first is c00, then c00）.

But they are added after gpio@232 and before sata@320.

> >
> > > >
> > > > Shawn
> > > >
> > > > > + compatible = "arm,sp805", "arm,primecell";
> > > > > + reg = <0x0 0xc00 0x0 0x1000>;
> > > > > + clocks = < 4 15>, < 4 15>;
> > > > > + clock-names = "apb_pclk", "wdog_clk";
> > > > > + };
> > > > > +
> > > > > + cluster1_core1_watchdog: wdt@c01 {
> > > > > + compatible = "arm,sp805", "arm,primecell";
> > > > > + reg = <0x0 0xc01 0x0 0x1000>;
> > > > > + clocks = < 4 15>, < 4 15>;
> > > > > + clock-names = "apb_pclk", "wdog_clk";
> > > > >   };
> > > > >
> > > > >   sata: sata@320 {
> > > > > --
> > > > > 2.17.1
> > > > >

RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node

[Leo Li]

> -Original Message-
> From: Chuanhua Han
> Sent: Friday, May 17, 2019 1:11 AM
> To: Shawn Guo 
> Cc: Leo Li ; mark.rutl...@arm.com; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ying Zhang 
> Subject: RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node
> 
> 
> 
> > -Original Message-
> > From: Shawn Guo 
> > Sent: 2019年5月17日 10:38
> > To: Chuanhua Han 
> > Cc: Leo Li ; mark.rutl...@arm.com;
> > linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Ying Zhang 
> > Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device
> > node
> >
> > Caution: EXT Email
> >
> > On Thu, May 09, 2019 at 03:06:57PM +0800, Chuanhua Han wrote:
> > > ls1028a platform uses sp805 watchdog, and use 1/16 platform clock as
> > > timer clock, this patch fix device tree node.
> > >
> > > Signed-off-by: Zhang Ying-22455 
> > > Signed-off-by: Chuanhua Han 
> > > ---
> > >  .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 19
> > > ---
> > >  1 file changed, 12 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > index b04581249f0b..1510b1858246 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > @@ -285,13 +285,18 @@
> > >   #interrupt-cells = <2>;
> > >   };
> > >
> > > - wdog0: watchdog@23c {
> > > - compatible = "fsl,ls1028a-wdt", "fsl,imx21-wdt";
> > > - reg = <0x0 0x23c 0x0 0x1>;
> > > - interrupts = ;
> > > - clocks = < 4 1>;
> > > - big-endian;
> > > - status = "disabled";
> > > + cluster1_core0_watchdog: wdt@c00 {
> >
> > Keep 'watchdog' as the node name,
> Thanks for your replay
> Do you mean replace the ‘wdt’ with ‘watchdog’?
> and keep nodes sort in unit-address.
> What does this mean?

That means order the nodes by the addresses (e.g. c00, c01)

> >
> > Shawn
> >
> > > + compatible = "arm,sp805", "arm,primecell";
> > > + reg = <0x0 0xc00 0x0 0x1000>;
> > > + clocks = < 4 15>, < 4 15>;
> > > + clock-names = "apb_pclk", "wdog_clk";
> > > + };
> > > +
> > > + cluster1_core1_watchdog: wdt@c01 {
> > > + compatible = "arm,sp805", "arm,primecell";
> > > + reg = <0x0 0xc01 0x0 0x1000>;
> > > + clocks = < 4 15>, < 4 15>;
> > > + clock-names = "apb_pclk", "wdog_clk";
> > >   };
> > >
> > >   sata: sata@320 {
> > > --
> > > 2.17.1
> > >

RE: [EXT] Re: [PATCH 1/3] dt-bindings: i2c: add optional mul-value property to binding

[Leo Li]

> -Original Message-
> From: Chuanhua Han
> Sent: Wednesday, May 8, 2019 6:45 AM
> To: Rob Herring 
> Cc: mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; Leo Li ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org;
> ker...@pengutronix.de; dl-linux-imx ;
> feste...@gmail.com; wsa+rene...@sang-engineering.com; u.kleine-
> koe...@pengutronix.de; e...@deif.com; li...@rempel-privat.de; Sumit
> Batra ; l.st...@pengutronix.de; p...@axentia.se
> Subject: RE: [EXT] Re: [PATCH 1/3] dt-bindings: i2c: add optional mul-value
> property to binding
> 
> 
> 
> > -Original Message-
> > From: Rob Herring 
> > Sent: 2019年5月3日 4:59
> > To: Chuanhua Han 
> > Cc: mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de;
> > Leo Li ; linux-kernel@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux-...@vger.kernel.org; ker...@pengutronix.de; dl-linux-imx
> > ; feste...@gmail.com;
> > wsa+rene...@sang-engineering.com; u.kleine-koe...@pengutronix.de;
> > e...@deif.com; li...@rempel-privat.de; Sumit Batra
> > ; l.st...@pengutronix.de; p...@axentia.se
> > Subject: [EXT] Re: [PATCH 1/3] dt-bindings: i2c: add optional
> > mul-value property to binding
> >
> > Caution: EXT Email
> >
> > On Tue, Apr 30, 2019 at 12:32:40PM +0800, Chuanhua Han wrote:
> > > NXP Layerscape SoC have up to three MUL options available for all
> > > divider values, we choice of MUL determines the internal monitor
> > > rate of the I2C bus (SCL and SDA signals):
> > > A lower MUL value results in a higher sampling rate of the I2C signals.
> > > A higher MUL value results in a lower sampling rate of the I2C signals.
> > >
> > > So in Optional properties we added our custom mul-value property in
> > > the binding to select which mul option for the device tree i2c
> > > controller node.
> > >
> > > Signed-off-by: Chuanhua Han 
> > > ---
> > >  Documentation/devicetree/bindings/i2c/i2c-imx.txt | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
> > > b/Documentation/devicetree/bindings/i2c/i2c-imx.txt
> > > index b967544590e8..ba8e7b7b3fa8 100644
> > > --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
> > > +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt
> > > @@ -18,6 +18,9 @@ Optional properties:
> > >  - sda-gpios: specify the gpio related to SDA pin
> > >  - pinctrl: add extra pinctrl to configure i2c pins to gpio function for 
> > > i2c
> > >bus recovery, call it "gpio" state
> > > +- mul-value: NXP Layerscape SoC have up to three MUL options
> > > +available for all I2C divider values, it describes which MUL we
> > > +choose to use for the driver, the values should be 1,2,4.
> >
> > Needs a vendor prefix. I don't find 'value' to add anything nor do I
> > understand what MUL is.
> Yes,you are right!
> >
> > If it is determined by SoC rather than board, then it should perhaps
> > be implied by compatible.
> This is determined by the SOC, but it has three options to choose from, so I
> think it's better to use the optional option instead of compatible

If there is only one best choice for each SoC letting the SoC compatible 
determine it will be the best.  Unless different board designs(use cases) of 
the same SoC requires different MUL settings, I also don't see much value of 
making it defined in device tree.

Regards,
Leo

RE: [PATCH] soc: fsl: add DPAA2 console support

[Leo Li]

> -Original Message-
> From: Ioana Ciornei
> Sent: Thursday, April 4, 2019 5:48 AM
> To: Leo Li 
> Cc: linux-kernel@vger.kernel.org; Roy Pledge 
> Subject: Re: [PATCH] soc: fsl: add DPAA2 console support
> 
> On 4/3/19 10:55 PM, Li Yang wrote:
> > On Tue, Mar 26, 2019 at 2:17 PM Ioana Ciornei 
> wrote:
> >>
> >> This patch adds DPAA2 MC and AIOP console log support.
> >>
> >> The platform driver probes on the "fsl,dpaa2-console" device tree
> >> node which describes the base firmware address needed in order to
> >> infer the start address of both firmware logs: MC and AIOP.
> >> It then exports two misc char devices which can be used to dump the
> >> needed logs.
> >>
> >> Signed-off-by: Ioana Ciornei 
> >> Signed-off-by: Roy Pledge 
> >> ---
> >>   drivers/soc/fsl/Kconfig |  10 ++
> >>   drivers/soc/fsl/Makefile|   1 +
> >>   drivers/soc/fsl/dpaa2-console.c | 306
> 
> >>   3 files changed, 317 insertions(+)
> >>   create mode 100644 drivers/soc/fsl/dpaa2-console.c
> >>
> >> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig index
> >> 61f8e1433d0a..9fe8222c3968 100644
> >> --- a/drivers/soc/fsl/Kconfig
> >> +++ b/drivers/soc/fsl/Kconfig
> >> @@ -29,4 +29,14 @@ config FSL_MC_DPIO
> >>other DPAA2 objects. This driver does not expose the DPIO
> >>objects individually, but groups them under a service layer
> >>API.
> >> +
> >> +config DPAA2_CONSOLE
> >> +   tristate "QorIQ DPAA2 console driver"
> >> +   depends on OF && (ARCH_LAYERSCAPE || (COMPILE_TEST && (ARM
> ||
> >> +ARM64 || X86_LOCAL_APIC || PPC)))
> >
> > I don't know why FSL_MC driver added there architectures dependency
> > for COMPILE_TEST, but is this driver also only buildable on these
> > architectures?  Can we really just remove these dependencies?
> >
> 
> The initial reasoning behind the dependency on the COMPILE_TEST config
> was to catch early build problems on any build configuration.
> And yes, the dpaa2-console can be compiled without a problem on these
> architectures.
> 
> In this case, I would suggest to leave the dependencies as they are but if you
> want I can also remove them.

Can we keep the COMPILE_TEST and remove the (ARM || ARM64 || X86_LOCAL_APIC || 
PPC) if we are not using any architecture specific stuff?

> 
> >> +   default y
> >> +   help
> >> + Console driver for DPAA2 platforms. Exports 2 char devices,
> >> + /dev/dpaa2_mc_console and /dev/dpaa2_aiop_console,
> >> + which can be used to dump the Management Complex and AIOP
> >> + firmware logs.
> >>   endmenu
> >> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> >> index 803ef1bfb5ff..57762c9fc7da 100644
> >> --- a/drivers/soc/fsl/Makefile
> >> +++ b/drivers/soc/fsl/Makefile
> >> @@ -7,3 +7,4 @@ obj-$(CONFIG_QUICC_ENGINE)  += qe/
> >>   obj-$(CONFIG_CPM)  += qe/
> >>   obj-$(CONFIG_FSL_GUTS) += guts.o
> >>   obj-$(CONFIG_FSL_MC_DPIO)  += dpio/
> >> +obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
> >> diff --git a/drivers/soc/fsl/dpaa2-console.c
> >> b/drivers/soc/fsl/dpaa2-console.c new file mode 100644 index
> >> ..21a5e121f87b
> >> --- /dev/null
> >> +++ b/drivers/soc/fsl/dpaa2-console.c
> >> @@ -0,0 +1,306 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> >
> > Probably good to have a one-line description of the driver?
> 
> Will add one in the next version.
> 
> >
> >> +/* Copyright 2015-2016 Freescale Semiconductor Inc.
> >> + * Copyright 2018 NXP
> >> + */
> >> +
> >> +#define pr_fmt(fmt) "dpaa2-console: " fmt
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +MODULE_LICENSE("Dual BSD/GPL");
> >> +MODULE_AUTHOR("Roy Pledge ");
> >> +MODULE_DESCRIPTION("DPAA2 console driver");
> >
> > These normally go to the bottom of a driver.
> 
> Will move them.
> 
> >
> >> +
> >> +/* MC firmware base low/high 

RE: [PATCH v1 1/4] dt-bindings: arm64: add compatible for LX2160A

[Leo Li]

> -Original Message-
> From: Vabhav Sharma
> Sent: Wednesday, April 3, 2019 3:28 AM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: Leo Li ; Meenakshi Aggarwal
> ; Andy Tang ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH v1 1/4] dt-bindings: arm64: add compatible for LX2160A
> 
> Hello Maintainers,
> Please merge below patch.
> 
> Regards,
> Vabhav
> 
> > -Original Message-
> > From: Vabhav Sharma 
> > Sent: Tuesday, February 26, 2019 3:41 PM
> > To: sudeep.ho...@arm.com; o...@buserror.net;
> > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
> > robh...@kernel.org; mark.rutl...@arm.com;
> > linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> > mturque...@baylibre.com; sb...@kernel.org; r...@rjwysocki.net;
> > viresh.ku...@linaro.org; linux-...@vger.kernel.org; linux-
> > p...@vger.kernel.org; linux-kernel-ow...@vger.kernel.org;
> > catalin.mari...@arm.com; will.dea...@arm.com;
> > gre...@linuxfoundation.org; a...@arndb.de;
> > kstew...@linuxfoundation.org; yamada.masah...@socionext.com; Leo Li
> > ; shawn...@kernel.org
> > Cc: li...@armlinux.org.uk; adrian.hun...@intel.com;
> > ulf.hans...@linaro.org; Vabhav Sharma 
> > Subject: [PATCH v1 1/4] dt-bindings: arm64: add compatible for LX2160A
> >
> > Add compatible for LX2160A SoC,QDS and RDB board Add lx2160a
> > compatible for clockgen and dcfg
> >
> > Signed-off-by: Vabhav Sharma 
> > Reviewed-by: Rob Herring 
> > ---
> >  .../bindings/arm/freescale/fsl,layerscape-dcfg.txt   |  2 +-
> >  Documentation/devicetree/bindings/arm/fsl.txt| 12
> 
> >  Documentation/devicetree/bindings/clock/qoriq-clock.txt  |  1 +
> >  3 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-
> > dcfg.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-
> > dcfg.txt
> > index b5cb374..dc76046 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-
> > dcfg.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-d
> > +++ cf
> > +++ g.txt
> > @@ -8,7 +8,7 @@ Required properties:
> >- compatible: Should contain a chip-specific compatible string,
> > Chip-specific strings are of the form "fsl,-dcfg",
> > The following s are known to be supported:
> > -   ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
> > +   ls1012a, ls1021a, ls1043a, ls1046a, ls2080a, lx2160a.
> >
> >- reg : should contain base address and length of DCFG
> > memory-mapped registers
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
> > b/Documentation/devicetree/bindings/arm/fsl.txt
> > index 7fbc424..baef162 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.txt
> > +++ b/Documentation/devicetree/bindings/arm/fsl.txt

This file has been converted to yaml format in mainline kernel.  Please respin 
the patch in order to apply.

> > @@ -235,3 +235,15 @@ Required root node properties:
> >  LS2088A ARMv8 based RDB Board
> >  Required root node properties:
> >  - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";
> > +
> > +LX2160A SoC
> > +Required root node properties:
> > +- compatible = "fsl,lx2160a";
> > +
> > +LX2160A ARMv8 based QDS Board
> > +Required root node properties:
> > +- compatible = "fsl,lx2160a-qds", "fsl,lx2160a";
> > +
> > +LX2160A ARMv8 based RDB Board
> > +Required root node properties:
> > +- compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
> > diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > index c655f28..f322989 100644
> > --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> > @@ -43,6 +43,7 @@ Required properties:
> > * "fsl,ls1046a-clockgen"
> > * "fsl,ls1088a-clockgen"
> > * "fsl,ls2080a-clockgen"
> > +   * "fsl,lx2160a-clockgen"
> > Chassis-version clock strings include:
> > * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
> > * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
> > --
> > 2.7.4

RE: [RESEND] i2c: imx: defer probing on dma channel request

[Leo Li]

> -Original Message-
> From: laurentiu.tu...@nxp.com 
> Sent: Monday, March 25, 2019 10:30 AM
> To: linux-...@vger.kernel.org; Ying Zhang 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> feste...@gmail.com; dl-linux-imx ; upstream-
> rele...@linux.nxdi.nxp.com; Leo Li ; Laurentiu Tudor
> 
> Subject: [RESEND] i2c: imx: defer probing on dma channel request
> 
> From: Laurentiu Tudor 
> 
> If the dma controller is not yet probed, defer i2c probe.
> The error path in probe was slightly modified (no functional change) to avoid
> triggering this WARN_ON():
> "cg-pll0-div1 already disabled
> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"

You are removing clk_disable_unprepare() from all error paths except the irq 
error.  Not sure why this is needed.

> 
> Signed-off-by: Laurentiu Tudor 
> ---
>  drivers/i2c/busses/i2c-imx.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index
> 42fed40198a0..4e34b1572756 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
>   pdev->name, i2c_imx);
>   if (ret) {
>   dev_err(>dev, "can't claim irq %d\n", irq);
> - goto clk_disable;
> + clk_disable_unprepare(i2c_imx->clk);
> + return ret;
>   }
> 
>   /* Init queue */
> @@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
>   pm_runtime_mark_last_busy(>dev);
>   pm_runtime_put_autosuspend(>dev);
> 
> + /* Init DMA config if supported */
> + ret = i2c_imx_dma_request(i2c_imx, phy_addr);
> + if (ret) {
> + if (ret != -EPROBE_DEFER)
> + dev_info(>dev, "can't use DMA, using PIO
> instead.\n");
> + else
> + goto del_adapter;
> + }
> +
>   dev_dbg(_imx->adapter.dev, "claimed irq %d\n", irq);
>   dev_dbg(_imx->adapter.dev, "device resources: %pR\n", res);
>   dev_dbg(_imx->adapter.dev, "adapter name: \"%s\"\n",
>   i2c_imx->adapter.name);
> 
> - /* Init DMA config if supported */
> - ret = i2c_imx_dma_request(i2c_imx, phy_addr);
> - if (ret < 0)
> - goto clk_notifier_unregister;
> -
>   dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n");
>   return 0;   /* Return OK */
> 
> +del_adapter:
> + i2c_del_adapter(_imx->adapter);
>  clk_notifier_unregister:
>   clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
>  rpm_disable:
> @@ -1182,8 +1189,6 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
>   pm_runtime_set_suspended(>dev);
>   pm_runtime_dont_use_autosuspend(>dev);
> 
> -clk_disable:
> - clk_disable_unprepare(i2c_imx->clk);
>   return ret;
>  }
> 
> --
> 2.17.1

RE: [PATCH 01/20] docs/zh_CN: add disclaimer file

[Leo Li]

> -Original Message-
> From: Alex Shi 
> Sent: Monday, March 4, 2019 1:58 AM
> To: Leo Li 
> Cc: Coly Li ; Federico Vaga ;
> Fengguang Wu ; Li Zefan
> ; Shawn Guo ;
> cor...@lwn.net; harryxi...@gmail.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-ker...@zh-kernel.org
> Subject: Re: [PATCH 01/20] docs/zh_CN: add disclaimer file
> 
> Hi Leo.
> 
> Do you know others' email address except yourself. I guess leoyang.li is same
> one as mailto:l...@zh-kernel.org, is this right? :)

Hi Alex,

I will try to get the new email addresses for others too.   Yes.  But probably 
I will use a private email for this instead of the company email. 

> 
> Thanks
> Alex
> On 2019/3/4 2:30 下午, Li Yang wrote:
> 
> 
> On Mon, Mar 4, 2019 at 12:23 AM Alex Shi
> <mailto:alex@linux.alibaba.com> wrote:
> BTW, Corbet,
> 
> Some of email address are unused and
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fzh-
> kernel.org=02%7C01%7Cleoyang.li%40nxp.com%7C6b64721b126944de
> 835c08d6a0771379%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63
> 6872830634024412=cMnFjRjAzodh5IgFVaZvZpmXNXfHb%2FwWCTxwt
> t%2FO6e4%3D=0 web site are unused and on sale. That are:
> 
> The website has been down for a while and won’t be reopen.  But we can
> definitely update these email addresses.
> 
> 

RE: [PATCH][next] soc: fsl: dpio: fix memory leak of a struct qbman on error exit path

[Leo Li]

> -Original Message-
> From: Colin King 
> Sent: Tuesday, February 19, 2019 8:05 AM
> To: Roy Pledge ; Leo Li ;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH][next] soc: fsl: dpio: fix memory leak of a struct qbman on
> error exit path
> 
> From: Colin Ian King 
> 
> Currently the error check for a null reg leaks a struct qbman that was
> allocated earlier. Fix this by kfree'ing p on the error exit path.
> 
> Signed-off-by: Colin Ian King 

Applied for next.  Thanks.

> ---
>  drivers/soc/fsl/dpio/qbman-portal.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/fsl/dpio/qbman-portal.c
> b/drivers/soc/fsl/dpio/qbman-portal.c
> index 0bddb85c0ae5..5a73397ae79e 100644
> --- a/drivers/soc/fsl/dpio/qbman-portal.c
> +++ b/drivers/soc/fsl/dpio/qbman-portal.c
> @@ -180,6 +180,7 @@ struct qbman_swp *qbman_swp_init(const struct
> qbman_swp_desc *d)
>   reg = qbman_read_register(p, QBMAN_CINH_SWP_CFG);
>   if (!reg) {
>   pr_err("qbman: the portal is not enabled!\n");
> + kfree(p);
>   return NULL;
>   }
> 
> --
> 2.20.1

RE: [PATCH] drivers: mux: Generic register bitfield-based multiplexer driver

[Leo Li]

> -Original Message-
> From: Peter Rosin 
> Sent: Monday, February 18, 2019 5:39 PM
> To: Leo Li ; Pankaj Bansal ;
> linux-kernel@vger.kernel.org; Philipp Zabel 
> Subject: Re: [PATCH] drivers: mux: Generic register bitfield-based
> multiplexer driver
> 
> On 2019-02-18 22:07, Leo Li wrote:
> > From: Peter Rosin 
> >> On 2019-02-18 11:20, Pankaj Bansal wrote:
> >>> From: Peter Rosin [mailto:p...@axentia.se]
> >>>> Anyway, I would prefer if you could extend drivers/mux/mmio.c to
> >>>> support both compatibles, and using the compatible to select if
> >>>>
> >>>>  regmap = syscon_node_to_regmap(np->parent);
> >>>>
> >>>> or
> >>>>
> >>>>  regmap = dev_get_regmap(dev->parent, NULL);
> >>>>
> >>>> is called to get to the desired regmap.
> >>>
> >>> This can be done. The name mmio.c however suggests that mux is
> >>> controlled by a Memory mapped device.
> >>> IMO, if the generic regmap API is to be added to it, the name needs
> >>> to changed. Any suggestions ?
> >>
> >> Just keep the driver name as is, there is no shortage of drivers
> >> supporting more than one thing...
> >
> > You are right that a lot of drivers support multiple functions. But
> > the problem here is that the current name mmio is only a subset of
> > what the updated driver will handle, which can create confusion.
> 
> I refuse the duplication. This new driver is doing the exact same thing (-ish)
> as the old one. Having the same code in two places is just a recipe for future
> divergence when everyone have forgotten that there are two nearly
> identical drivers that both need patching. Stating this in a comment
> somewhere in the drivers will not help all that much in my experience. The
> comment will be missing from the context in some seemingly trivial patch,
> and there you go. There *will* be weed down the line, if duplication is
> allowed.

I agree that we should avoid the duplication.

> 
> I can agree that mux-regmap.c and CONFIG_MUX_REGMAP would have
> been better names, but mux-mmio is already there. So it is what it is. But if
> you can convince me that changing the name will not cause any trouble
> anywhere for any existing mux-mmio users, I suppose we can do a rename.
> But I bet there will be some nasty corner cases and odd use cases, so you will
> have to present strong arguments.

I don't think that it is hard to maintain the backward compatibility with the 
rename.  The updated driver can keep handling the "mmio-mux" device tree 
compatible string.  And we can also have MUX_MMIO selects the new MUX_REGMAP if 
we want to keep the compatibility with old kernel config file.

> 
> Just update the Kconfig to document the dual nature and remove the
> MFD_SYSCON dependency. I suppose you also need to handle the possibly
> missing syscon in the .c file, details, details. But something like this 
> perhaps:
> 
> config MUX_MMIO
>   tristate "MMIO/Regmap register bitfield-controlled Multiplexer"
>   depends on OF || COMPILE_TEST
>   help
> MMIO/Regmap register bitfield-controlled Multiplexer controller.
> 
> The driver builds multiplexer controllers for bitfields in either
> a syscon register or a driver regmap register. For N bit wide
> bitfields, there will be 2^N possible multiplexer states.
> 
> To compile the driver as a module, choose M here: the module will
> be called mux-mmio.
> 
> Cheers,
> Peter

RE: [PATCH] drivers: mux: Generic register bitfield-based multiplexer driver

[Leo Li]

> -Original Message-
> From: Peter Rosin 
> Sent: Monday, February 18, 2019 8:28 AM
> To: Pankaj Bansal ; Leo Li ;
> linux-kernel@vger.kernel.org; Philipp Zabel 
> Subject: Re: [PATCH] drivers: mux: Generic register bitfield-based
> multiplexer driver
> 
> On 2019-02-18 11:20, Pankaj Bansal wrote:
> > Hi Peter,
> >
> >> -Original Message-
> >> From: Peter Rosin [mailto:p...@axentia.se]
> >> Sent: Monday, 18 February, 2019 03:17 PM
> >> To: Pankaj Bansal ; Leo Li
> >> ; linux-kernel@vger.kernel.org; Philipp Zabel
> >> 
> >> Subject: Re: [PATCH] drivers: mux: Generic register bitfield-based
> >> multiplexer driver
> >>
> >> Hi!
> >>
> >> On 2019-02-18 06:40, Pankaj Bansal wrote:
> >>> Generic register bitfield-based multiplexer driver that controls the
> >>> multiplexer producer defined under a parent node.
> >>> The driver corresponding to parent node provides register read/write
> >>> capabilities.
> >>
> >> This driver is just a rename of drivers/mux/mmio.c with a one-liner
> >> on top. And there's a license change too. That's obnoxious. Please
> >> keep this as GPL v2. Not that I /think/ Philipp nor Pengutronix cares
> deeply, but what do I know?
> >> Changing the license as you copy the code is simply not all right.
> >
> > My Apologies. I will fix it as I send V2.
> >
> >>
> >> Anyway, I would prefer if you could extend drivers/mux/mmio.c to
> >> support both compatibles, and using the compatible to select if
> >>
> >>regmap = syscon_node_to_regmap(np->parent);
> >>
> >> or
> >>
> >>regmap = dev_get_regmap(dev->parent, NULL);
> >>
> >> is called to get to the desired regmap.
> >
> > This can be done. The name mmio.c however suggests that mux is
> controlled by a Memory mapped device.
> > IMO, if the generic regmap API is to be added to it, the name needs to
> changed. Any suggestions ?
> 
> Just keep the driver name as is, there is no shortage of drivers supporting
> more than one thing...

You are right that a lot of drivers support multiple functions.  But the 
problem here is that the current name mmio is only a subset of what the updated 
driver will handle, which can create confusion.

Regards,
Leo
> 
> Cheers,
> Peter
> 
> >>
> >> Philipp, you don't object to extending the mmio driver, right?
> >>
> >> Or are there more differences that I failed to notice?
> >
> > Nope, it's the only difference.
> >
> >>
> >> Cheers,
> >> Peter
> >>
> >>>
> >>> Signed-off-by: Pankaj Bansal 
> >>> ---
> >>>
> >>> Notes:
> >>> Dependencies:
> >>> -
> >>>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> >>> at
> >>>
> >>
> chwork.ozlabs.org%2Fpatch%2F1043790%2Fdata=02%7C01%7Cpankaj.
> b
> >> ansa
> >>>
> >>
> l%40nxp.com%7C3b8a1e8520ce4345105108d695861210%7C686ea1d3bc2b4c6
> f
> >> a92cd
> >>>
> >>
> 99c5c301635%7C0%7C0%7C636860800396857042sdata=5e%2BhyasYwf
> >> uc%2Fbr
> >>> 1u6WKlKybYipz5c4ndBeLZDflHqk%3Dreserved=0
> >>>
> >>>  drivers/mux/Kconfig  |  13 
> >>>  drivers/mux/Makefile |   2 +
> >>>  drivers/mux/regmap.c | 139
> >> +
> >>>  3 files changed, 154 insertions(+)
> >>>
> >>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig index
> >>> 7659d6c5f718..a412d0955258 100644
> >>> --- a/drivers/mux/Kconfig
> >>> +++ b/drivers/mux/Kconfig
> >>> @@ -58,4 +58,17 @@ config MUX_MMIO
> >>> To compile the driver as a module, choose M here: the module will
> >>> be called mux-mmio.
> >>>
> >>> +config MUX_REGMAP
> >>> + tristate "Regmap register bitfield-controlled Multiplexer"
> >>> + depends on (OF && REGMAP) || COMPILE_TEST
> >>> + help
> >>> +   Regmap register bitfield-controlled Multiplexer controller.
> >>> +
> >>> +   The driver builds multiplexer controllers for bitfields in a regmap
> >>> +   device register. For N bit wide bitfields, there will be 2^N possible
> >>> +   multiplexer states.
> >>> +
> >>> +   To compile the driver as a module, choose

RE: [PATCH v2 2/3] dt-bindings: arm: fsl: Add devicetree binding for Oxalis

[Leo Li]

> -Original Message-
> From: Manivannan Sadhasivam 
> Sent: Monday, January 21, 2019 12:10 AM
> To: Shawn Guo ; Rob Herring 
> Cc: Leo Li ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> a.tropsc...@ebs-systart.com; m.bitt...@ebs-systart.com; Amit Kucheria
> 
> Subject: Re: [PATCH v2 2/3] dt-bindings: arm: fsl: Add devicetree binding for
> Oxalis
> 
> On Wed, Jan 16, 2019 at 06:14:43PM +0800, Shawn Guo wrote:
> > On Tue, Jan 15, 2019 at 10:07:12PM -0600, Rob Herring wrote:
> > > On Tue, Jan 15, 2019 at 8:21 PM Shawn Guo 
> wrote:
> > > >
> > > > On Mon, Jan 14, 2019 at 12:02:47PM -0600, Rob Herring wrote:
> > > > > On Mon, Jan 14, 2019 at 4:21 AM Manivannan Sadhasivam
> > > > >  wrote:
> > > > > >
> > > > > > Add devicetree binding for Oxalis board in JSON format. While
> > > > > > adding that, let's fix the description for LS1012A also.
> > > > > >
> > > > > > Signed-off-by: Manivannan Sadhasivam
> > > > > > 
> > > > > > ---
> > > > > >  Documentation/devicetree/bindings/arm/fsl.yaml | 3 ++-
> > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > > index d34fe0749199..0f30142fe316 100644
> > > > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > > @@ -173,12 +173,13 @@ properties:
> > > > > >- fsl,vf610
> > > > > >- fsl,vf610m4
> > > > > >
> > > > > > -  - description: LS1021A based Boards
> > > > > > +  - description: LS1012A based Boards
> > > > >
> > > > > Well, yes that was wrong...
> > > > >
> > > > > >  items:
> > > > > >- enum:
> > > > > >- fsl,ls1012a-rdb
> > > > > >- fsl,ls1012a-frdm
> > > > > >- fsl,ls1012a-qds
> > > > > > +  - ebs-systart,oxalis
> > > > >
> > > > > Sort alphabetically.
> > > > >
> > > > > >- const: fsl,ls1021a
> > > > >
> > > > > And this is wrong too.
> > > > >
> > > > > I you just change it, then we will be missing an entry for LS1021A.
> > > > > What's the status of that SoC because there is no board dts
> > > > > file? We should not have .dtsi files in the kernel which don't get 
> > > > > built.
> > > >
> > > > Hmm, I do not see any LS1021A SoC .dtsi in the tree.  I suspect
> > > > it's just a typo of LS1012A.
> > > >
> > > > @Leo, do we have a LS1021A SoC?
> > >
> > > arch/arm/boot/dts/ls1021a.dtsi
> >
> > Oops, I only searched arm64 folder.
> >
> > So it seems the compatible of the boards below are missing there.
> >
> >   ls1021a-moxa-uc-8410a.dts
> >   ls1021a-qds.dts
> >   ls1021a-twr.dts
> 
> So how should we proceed here? The above mentioned boards are lacking
> compatible in dts files and I guess that's the reason they didn't get
> mentioned in "fsl" binding file.
> 
> Should I just go ahead and add the compatibles for these boards and list
> them in binding file?

Please go ahead and do that.  One thing is that the moxa-uc-8410a board is a 
3rd-party board, not sure if it should belong to the fsl binding file.

Regards,
Leo

RE: [PATCH] soc: fsl: guts: us devm_kstrdup_const() for RO data

[Leo Li]

> -Original Message-
> From: Nicholas Mc Guire 
> Sent: Thursday, January 10, 2019 8:44 PM
> To: Leo Li 
> Cc: Scott Wood ; linuxppc-dev  d...@lists.ozlabs.org>; lkml ; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE  ker...@lists.infradead.org>; Nicholas Mc Guire 
> Subject: Re: [PATCH] soc: fsl: guts: us devm_kstrdup_const() for RO data
> 
> On Thu, Jan 10, 2019 at 01:43:01PM -0600, Li Yang wrote:
> > On Sat, Dec 22, 2018 at 2:02 AM Nicholas Mc Guire 
> wrote:
> > >
> > > On Fri, Dec 21, 2018 at 08:29:56PM -0600, Scott Wood wrote:
> > > > On Fri, 2018-12-07 at 09:22 +0100, Nicholas Mc Guire wrote:
> > > > > devm_kstrdup() may return NULL if internal allocation failed,
> > > > > but as  machine  is from the device tree, and thus RO,
> > > > > devm_kstrdup_const() can be used here, which will only copy the
> reference.
> > > >
> > > > Is it really going to only copy the reference?  That would require
> > > > that
> > > > is_kernel_rodata(machine) be true, which it shouldn't be since
> > > > it's not part of the kernel image.
> > > >
> > > I had tried to figure out what is RO and what not but was not able
> > > to determine that - from the discussion it seemed that the
> > > assumption of RO is correct though I did not ask if it would satisfy
> > > is_kernel_rodata() so that explains the incorrect assertion.
> > > see
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > >
> kml.org%2Flkml%2F2018%2F12%2F6%2F42data=02%7C01%7Cleoyang.l
> i%40
> > >
> nxp.com%7Cf72d70a65d1b47f6883808d6776e9d58%7C686ea1d3bc2b4c6fa92c
> d99
> > >
> c5c301635%7C0%7C1%7C636827714307963102sdata=xnaO0Y7q%2Byad
> Yv8sF
> > > VPFtkfllgnwpEIkkTIgw0K%2Fovg%3Dreserved=0
> > > So then the only option is to check the return and cleanup on
> > > allocation failure as the orriginal patch proposed.
> >
> > Thanks for the good discussion. I will drop the previous patch. But
> > would it also be good to just have "soc_dev_attr.machine = machine"
> > directly?
> >
> I think that the intent is to switch to managed devm API so that the cleanup 
> is
> handled properly currently you would get "machine" from
> of_property_read_string_index
>   -> of_property_read_string_helper
>-> of_find_property
> which does not do any allocation - so there would actually not be anything to
> cleanup here - don´t see why your solution would not be suitable given the
> current API. the only advantage of the devm_kstrdup() is that underlying
> APIs internal changes would have no effect.

Thanks.  I will sent out a new version.

Regards,
Leo

RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support

[Leo Li]

> -Original Message-
> From: Peng Ma
> Sent: Thursday, January 10, 2019 4:32 AM
> To: Peng Ma ; shawn...@kernel.org;
> ax...@kernel.dk
> Cc: Leo Li ; robh...@kernel.org;
> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> i...@vger.kernel.org; Andy Tang 
> Subject: RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support
> 
> Hi Jens，
> 
>   I send the sata patchs to the upstream patchwork
> with ./scripts/get_maintainer.pl, but I find my patch on
> http://patchwork.ozlabs.org/project/linux-ide/list/ , I saw the MAINTAINERS,
> the driver/ata/* should be on https://patchwork.kernel.org/project/linux-
> block/list/ . could you please help me what the patchwork is right.

Peng,

The patchwork used is related to the mailing list which you send the patch to 
not the maintainer's git tree used.  Since the MAINTAINERS file says 
drivers/ata should use linux-ide mailing list, patches will appear in linux-ide 
patchwork.

Regards,
Leo

>   Thanks a lot.
> 
> Best Regards,
> Peng
> 
> >-Original Message-
> >From: Peng Ma 
> >Sent: 2019年1月10日 18:06
> >To: shawn...@kernel.org; ax...@kernel.dk
> >Cc: Leo Li ; robh...@kernel.org;
> >mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
> >devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >linux-...@vger.kernel.org; Peng Ma 
> >Subject: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support
> >
> >Lx2160a is a new introduced soc which supports ATA3.0 and Clean up some
> >code
> >
> >Signed-off-by: Peng Ma 
> >---
> > drivers/ata/ahci_qoriq.c |   44 
> > 1 files changed, 12 insertions(+), 32 deletions(-)
> >
> >diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c index
> >ce59253..1994bf2 100644
> >--- a/drivers/ata/ahci_qoriq.c
> >+++ b/drivers/ata/ahci_qoriq.c
> >@@ -57,7 +57,7 @@ enum ahci_qoriq_type {
> > AHCI_LS2080A,
> > AHCI_LS1046A,
> > AHCI_LS1088A,
> >-AHCI_LS2088A,
> >+AHCI_LX2160A,
> > };
> >
> > struct ahci_qoriq_priv {
> >@@ -73,7 +73,7 @@ struct ahci_qoriq_priv {
> > { .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
> > { .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
> > { .compatible = "fsl,ls1088a-ahci", .data = (void *)AHCI_LS1088A},
> >-{ .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
> >+{ .compatible = "fsl,lx2160a-ahci", .data = (void *)AHCI_LX2160A},
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match); @@ -174,12 +174,10
> @@
> >static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
> > writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
> > writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
> > writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> >-if (qpriv->is_dmacoherent)
> >-writel(AHCI_PORT_AXICC_CFG,
> >-reg_base + LS1021A_AXICC_ADDR);
> > break;
> >
> > case AHCI_LS1043A:
> >+case AHCI_LS1046A:
> > if (!qpriv->ecc_addr)
> > return -EINVAL;
> > writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2, @@ -
> 188,8
> >+186,6 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
> > writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
> > writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
> > writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> >-if (qpriv->is_dmacoherent)
> >-writel(AHCI_PORT_AXICC_CFG, reg_base +
> PORT_AXICC);
> > break;
> >
> > case AHCI_LS2080A:
> >@@ -197,24 +193,10 @@ static int ahci_qoriq_phy_init(struct
> >ahci_host_priv
> >*hpriv)
> > writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
> > writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
> > writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> >-if (qpriv->is_dmacoherent)
> >-writel(AHCI_PORT_AXICC_CFG, reg_base +
> PORT_AXICC);
> >-break;
> >-
> >-case AHCI_LS1046A:
> >-if (!qpriv->ecc_addr)
> >-return -EINVAL;
> >-writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
> >- 

RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller

[Leo Li]

> -Original Message-
> From: Z.q. Hou
> Sent: Sunday, November 11, 2018 5:48 PM
> To: Leo Li ; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; lorenzo.pieral...@arm.com
> Cc: Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao 
> Subject: RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller
> 
> Hi Leo,
> 
> Thanks a lot for your comments!
> 
> > -Original Message-
> > From: Leo Li
> > Sent: 2018年11月9日 5:29
> > To: Z.q. Hou ; linux-...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> > mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> > shawn...@kernel.org; lorenzo.pieral...@arm.com
> > Cc: Mingkai Hu ; M.h. Lian
> > ; Xiaowei Bao 
> > Subject: RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe
> > controller
> >
> >
> >
> > > -Original Message-
> > > From: Z.q. Hou
> > > Sent: Tuesday, November 6, 2018 7:21 AM
> > > To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > ; lorenzo.pieral...@arm.com
> > > Cc: Mingkai Hu ; M.h. Lian
> > > ; Xiaowei Bao ; Z.q.
> > Hou
> > > 
> > > Subject: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe
> > > controller
> > >
> > > From: Hou Zhiqiang 
> > >
> > > Add PCIe controller DT bindings of NXP LX series SoCs.
> >
> > I'm not sure if this is a good idea to name this controller LX PCIe 
> > controller.
> > Right now, it could be true that it is only used on LX series SoCs.
> > But I'm not sure if the LS series will not use this controller or LX
> > series will only use this controller in the future.
> >
> > Since the LX series is still using the layerscape branding, so
> > probably we should keep using the layerscape-pci.txt and define the PCIe
> Gen4 variant?
> 
> Yes, will add the new PCIe IP bindings to Layerscape-pci.txt.
> 
> >
> > Same comment for other places using the LX naming in this driver.
> 
> Do you have any suggestion about how to name the driver and prefix of
> structures in the driver?

Probably something like pcie-layerscape-gen4?

> 
> >
> > >
> > > Signed-off-by: Hou Zhiqiang 
> > > ---
> > >  .../devicetree/bindings/pci/lx-pci.txt| 52
> > +++
> > >  MAINTAINERS   |  8 +++
> > >  2 files changed, 60 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/pci/lx-pci.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/lx-pci.txt
> > > b/Documentation/devicetree/bindings/pci/lx-pci.txt
> > > new file mode 100644
> > > index ..dc602fef93b0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pci/lx-pci.txt
> > > @@ -0,0 +1,52 @@
> > > +NXP LX PCIe controller
> > > +
> > > +This PCIe controller is based on the Mobiveil PCIe IP and thus
> > > +inherits all the common properties defined in mobiveil-pcie.txt.
> > > +
> > > +Required properties:
> > > +- compatible: should contain the platform identifier such as:
> > > +  "fsl,lx2160a-pcie"
> > > +- reg: base addresses and lengths of the PCIe controller register blocks.
> > > +  "config_axi_slave": PCIe controller registers
> > > +  "csr_axi_slave": Bridge config registers
> > > +- interrupts: A list of interrupt outputs of the controller. Must
> > > +contain an
> > > +  entry for each entry in the interrupt-names property.
> > > +- interrupt-names: It could include the following entries:
> > > +  "intr": The interrupt that is asserted for controller interrupts
> > > +  "aer": Asserted for aer interrupt when chip support the aer
> > > +interrupt
> > with
> > > +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> > > aer.
> > > +  "pme": Asserted for pme interrupt when chip support the pme
> > > + interrupt
> > > with

RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller

[Leo Li]

> -Original Message-
> From: Z.q. Hou
> Sent: Sunday, November 11, 2018 5:48 PM
> To: Leo Li ; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; lorenzo.pieral...@arm.com
> Cc: Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao 
> Subject: RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller
> 
> Hi Leo,
> 
> Thanks a lot for your comments!
> 
> > -Original Message-
> > From: Leo Li
> > Sent: 2018年11月9日 5:29
> > To: Z.q. Hou ; linux-...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> > mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> > shawn...@kernel.org; lorenzo.pieral...@arm.com
> > Cc: Mingkai Hu ; M.h. Lian
> > ; Xiaowei Bao 
> > Subject: RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe
> > controller
> >
> >
> >
> > > -Original Message-
> > > From: Z.q. Hou
> > > Sent: Tuesday, November 6, 2018 7:21 AM
> > > To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > ; lorenzo.pieral...@arm.com
> > > Cc: Mingkai Hu ; M.h. Lian
> > > ; Xiaowei Bao ; Z.q.
> > Hou
> > > 
> > > Subject: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe
> > > controller
> > >
> > > From: Hou Zhiqiang 
> > >
> > > Add PCIe controller DT bindings of NXP LX series SoCs.
> >
> > I'm not sure if this is a good idea to name this controller LX PCIe 
> > controller.
> > Right now, it could be true that it is only used on LX series SoCs.
> > But I'm not sure if the LS series will not use this controller or LX
> > series will only use this controller in the future.
> >
> > Since the LX series is still using the layerscape branding, so
> > probably we should keep using the layerscape-pci.txt and define the PCIe
> Gen4 variant?
> 
> Yes, will add the new PCIe IP bindings to Layerscape-pci.txt.
> 
> >
> > Same comment for other places using the LX naming in this driver.
> 
> Do you have any suggestion about how to name the driver and prefix of
> structures in the driver?

Probably something like pcie-layerscape-gen4?

> 
> >
> > >
> > > Signed-off-by: Hou Zhiqiang 
> > > ---
> > >  .../devicetree/bindings/pci/lx-pci.txt| 52
> > +++
> > >  MAINTAINERS   |  8 +++
> > >  2 files changed, 60 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/pci/lx-pci.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/lx-pci.txt
> > > b/Documentation/devicetree/bindings/pci/lx-pci.txt
> > > new file mode 100644
> > > index ..dc602fef93b0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pci/lx-pci.txt
> > > @@ -0,0 +1,52 @@
> > > +NXP LX PCIe controller
> > > +
> > > +This PCIe controller is based on the Mobiveil PCIe IP and thus
> > > +inherits all the common properties defined in mobiveil-pcie.txt.
> > > +
> > > +Required properties:
> > > +- compatible: should contain the platform identifier such as:
> > > +  "fsl,lx2160a-pcie"
> > > +- reg: base addresses and lengths of the PCIe controller register blocks.
> > > +  "config_axi_slave": PCIe controller registers
> > > +  "csr_axi_slave": Bridge config registers
> > > +- interrupts: A list of interrupt outputs of the controller. Must
> > > +contain an
> > > +  entry for each entry in the interrupt-names property.
> > > +- interrupt-names: It could include the following entries:
> > > +  "intr": The interrupt that is asserted for controller interrupts
> > > +  "aer": Asserted for aer interrupt when chip support the aer
> > > +interrupt
> > with
> > > +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> > > aer.
> > > +  "pme": Asserted for pme interrupt when chip support the pme
> > > + interrupt
> > > with

RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller

[Leo Li]

> -Original Message-
> From: Z.q. Hou
> Sent: Tuesday, November 6, 2018 7:21 AM
> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com
> Cc: Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao ; Z.q. Hou
> 
> Subject: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller
> 
> From: Hou Zhiqiang 
> 
> Add PCIe controller DT bindings of NXP LX series SoCs.

I'm not sure if this is a good idea to name this controller LX PCIe controller. 
 Right now, it could be true that it is only used on LX series SoCs.  But I'm 
not sure if the LS series will not use this controller or LX series will only 
use this controller in the future.

Since the LX series is still using the layerscape branding, so probably we 
should keep using the layerscape-pci.txt and define the PCIe Gen4 variant?

Same comment for other places using the LX naming in this driver.

> 
> Signed-off-by: Hou Zhiqiang 
> ---
>  .../devicetree/bindings/pci/lx-pci.txt| 52 +++
>  MAINTAINERS   |  8 +++
>  2 files changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/lx-pci.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/lx-pci.txt
> b/Documentation/devicetree/bindings/pci/lx-pci.txt
> new file mode 100644
> index ..dc602fef93b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/lx-pci.txt
> @@ -0,0 +1,52 @@
> +NXP LX PCIe controller
> +
> +This PCIe controller is based on the Mobiveil PCIe IP and thus inherits
> +all the common properties defined in mobiveil-pcie.txt.
> +
> +Required properties:
> +- compatible: should contain the platform identifier such as:
> +  "fsl,lx2160a-pcie"
> +- reg: base addresses and lengths of the PCIe controller register blocks.
> +  "config_axi_slave": PCIe controller registers
> +  "csr_axi_slave": Bridge config registers
> +- interrupts: A list of interrupt outputs of the controller. Must
> +contain an
> +  entry for each entry in the interrupt-names property.
> +- interrupt-names: It could include the following entries:
> +  "intr": The interrupt that is asserted for controller interrupts
> +  "aer": Asserted for aer interrupt when chip support the aer interrupt with
> +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> aer.
> +  "pme": Asserted for pme interrupt when chip support the pme interrupt
> with
> +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> pme.
> +- dma-coherent: Indicates that the hardware IP block can ensure the
> +coherency
> +  of the data transferred from/to the IP block. This can avoid the
> +software
> +  cache flush/invalid actions, and improve the performance significantly.
> +- msi-parent : See the generic MSI binding described in
> +  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> +
> +Example:
> +
> + pcie@340 {
> + compatible = "fsl,lx2160a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010   /* controller
> registers */
> +0x80 0x 0x0 0x1000>; /* configuration
> space */
> + reg-names = "csr_axi_slave", "config_axi_slave";
> + interrupts = , /* AER
> interrupt */
> +  , /* PME
> interrupt */
> +  ; /*
> controller interrupt */
> + interrupt-names = "aer", "pme", "intr";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + apio-wins = <8>;
> + ppio-wins = <8>;
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + msi-parent = <>;
> + ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1  GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2  GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3  GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4  GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0c57ccff3188..7da555

RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller

[Leo Li]

> -Original Message-
> From: Z.q. Hou
> Sent: Tuesday, November 6, 2018 7:21 AM
> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com
> Cc: Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao ; Z.q. Hou
> 
> Subject: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller
> 
> From: Hou Zhiqiang 
> 
> Add PCIe controller DT bindings of NXP LX series SoCs.

I'm not sure if this is a good idea to name this controller LX PCIe controller. 
 Right now, it could be true that it is only used on LX series SoCs.  But I'm 
not sure if the LS series will not use this controller or LX series will only 
use this controller in the future.

Since the LX series is still using the layerscape branding, so probably we 
should keep using the layerscape-pci.txt and define the PCIe Gen4 variant?

Same comment for other places using the LX naming in this driver.

> 
> Signed-off-by: Hou Zhiqiang 
> ---
>  .../devicetree/bindings/pci/lx-pci.txt| 52 +++
>  MAINTAINERS   |  8 +++
>  2 files changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/lx-pci.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/lx-pci.txt
> b/Documentation/devicetree/bindings/pci/lx-pci.txt
> new file mode 100644
> index ..dc602fef93b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/lx-pci.txt
> @@ -0,0 +1,52 @@
> +NXP LX PCIe controller
> +
> +This PCIe controller is based on the Mobiveil PCIe IP and thus inherits
> +all the common properties defined in mobiveil-pcie.txt.
> +
> +Required properties:
> +- compatible: should contain the platform identifier such as:
> +  "fsl,lx2160a-pcie"
> +- reg: base addresses and lengths of the PCIe controller register blocks.
> +  "config_axi_slave": PCIe controller registers
> +  "csr_axi_slave": Bridge config registers
> +- interrupts: A list of interrupt outputs of the controller. Must
> +contain an
> +  entry for each entry in the interrupt-names property.
> +- interrupt-names: It could include the following entries:
> +  "intr": The interrupt that is asserted for controller interrupts
> +  "aer": Asserted for aer interrupt when chip support the aer interrupt with
> +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> aer.
> +  "pme": Asserted for pme interrupt when chip support the pme interrupt
> with
> +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> pme.
> +- dma-coherent: Indicates that the hardware IP block can ensure the
> +coherency
> +  of the data transferred from/to the IP block. This can avoid the
> +software
> +  cache flush/invalid actions, and improve the performance significantly.
> +- msi-parent : See the generic MSI binding described in
> +  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> +
> +Example:
> +
> + pcie@340 {
> + compatible = "fsl,lx2160a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010   /* controller
> registers */
> +0x80 0x 0x0 0x1000>; /* configuration
> space */
> + reg-names = "csr_axi_slave", "config_axi_slave";
> + interrupts = , /* AER
> interrupt */
> +  , /* PME
> interrupt */
> +  ; /*
> controller interrupt */
> + interrupt-names = "aer", "pme", "intr";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + apio-wins = <8>;
> + ppio-wins = <8>;
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + msi-parent = <>;
> + ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1  GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2  GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3  GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4  GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0c57ccff3188..7da555

RE: [PATCH v2] arm64: dts: lx2160a: enable eSDHC controller

[Leo Li]

> -Original Message-
> From: Yinbo Zhu 
> Sent: Thursday, October 11, 2018 1:35 AM
> To: Yinbo Zhu ; Y.b. Lu ; linux-
> m...@vger.kernel.org; Adrian Hunter ;
> ulf.hans...@linaro.org; Leo Li 
> Cc: Xiaobo Xie ; devicet...@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: [PATCH v2] arm64: dts: lx2160a: enable eSDHC controller
> 
> There are two eSDHC controllers in lx2160a. This patch is to enable eSDHC for
> RDB and QDS board.
> 
> Signed-off-by: Yinbo Zhu 
> ---
> Change in v2:
>   squash all lx2160a esdhc dts patch into the original patch

Hi Yinbo,

What I meant is that the eSDHC nodes should be squashed into the patches adding 
these device tree.  I don't see a good reason that SDHC nodes should be a 
separate patch for now, especially when the original patch is still being 
reviewed and could be changing.
https://lore.kernel.org/patchwork/patch/995433/
https://lore.kernel.org/patchwork/patch/995434/

Regards,
Leo
> 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts |8 ++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   15 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   25
> +
>  3 files changed, 48 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index bc30173..b58b96c 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -294,6 +294,14 @@
>   status = "okay";
>  };
> 
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   dflash0: n25q128a {
>   #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 53b0e80..cbe8919 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -170,6 +170,21 @@
>   status = "okay";
>  };
> 
> + {
> + sd-uhs-sdr104;
> + sd-uhs-sdr50;
> + sd-uhs-sdr25;
> + sd-uhs-sdr12;
> + status = "okay";
> +};
> +
> + {
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>   nxp,fspi-has-second-chip;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index fa4a1f8..174544a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -356,6 +356,31 @@
>   little-endian;
>   };
> 
> + esdhc0: esdhc@214 {
> + compatible = "fsl,esdhc";
> + reg = <0x0 0x214 0x0 0x1>;
> + interrupts = <0 28 0x4>; /* Level high type */
> + clocks = < 4 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + esdhc1: esdhc@215 {
> + compatible = "fsl,esdhc";
> + reg = <0x0 0x215 0x0 0x1>;
> + interrupts = <0 63 0x4>; /* Level high type */
> + clocks = < 4 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + broken-cd;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
>   gpio0: gpio@230 {
>   compatible = "fsl,ls2080a-gpio", "fsl,qoriq-gpio";
>   reg = <0x0 0x230 0x0 0x1>;
> --
> 1.7.1

RE: [PATCH v2] arm64: dts: lx2160a: enable eSDHC controller

[Leo Li]

> -Original Message-
> From: Yinbo Zhu 
> Sent: Thursday, October 11, 2018 1:35 AM
> To: Yinbo Zhu ; Y.b. Lu ; linux-
> m...@vger.kernel.org; Adrian Hunter ;
> ulf.hans...@linaro.org; Leo Li 
> Cc: Xiaobo Xie ; devicet...@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: [PATCH v2] arm64: dts: lx2160a: enable eSDHC controller
> 
> There are two eSDHC controllers in lx2160a. This patch is to enable eSDHC for
> RDB and QDS board.
> 
> Signed-off-by: Yinbo Zhu 
> ---
> Change in v2:
>   squash all lx2160a esdhc dts patch into the original patch

Hi Yinbo,

What I meant is that the eSDHC nodes should be squashed into the patches adding 
these device tree.  I don't see a good reason that SDHC nodes should be a 
separate patch for now, especially when the original patch is still being 
reviewed and could be changing.
https://lore.kernel.org/patchwork/patch/995433/
https://lore.kernel.org/patchwork/patch/995434/

Regards,
Leo
> 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts |8 ++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   15 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   25
> +
>  3 files changed, 48 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index bc30173..b58b96c 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -294,6 +294,14 @@
>   status = "okay";
>  };
> 
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   dflash0: n25q128a {
>   #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 53b0e80..cbe8919 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -170,6 +170,21 @@
>   status = "okay";
>  };
> 
> + {
> + sd-uhs-sdr104;
> + sd-uhs-sdr50;
> + sd-uhs-sdr25;
> + sd-uhs-sdr12;
> + status = "okay";
> +};
> +
> + {
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>   nxp,fspi-has-second-chip;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index fa4a1f8..174544a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -356,6 +356,31 @@
>   little-endian;
>   };
> 
> + esdhc0: esdhc@214 {
> + compatible = "fsl,esdhc";
> + reg = <0x0 0x214 0x0 0x1>;
> + interrupts = <0 28 0x4>; /* Level high type */
> + clocks = < 4 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + esdhc1: esdhc@215 {
> + compatible = "fsl,esdhc";
> + reg = <0x0 0x215 0x0 0x1>;
> + interrupts = <0 63 0x4>; /* Level high type */
> + clocks = < 4 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + broken-cd;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
>   gpio0: gpio@230 {
>   compatible = "fsl,ls2080a-gpio", "fsl,qoriq-gpio";
>   reg = <0x0 0x230 0x0 0x1>;
> --
> 1.7.1

RE: [GIT PULL v2] for-next updates for soc/fsl drivers for v4.20 take 2

[Leo Li]

> -Original Message-
> From: Arnd Bergmann 
> Sent: Monday, October 8, 2018 7:51 AM
> To: Leo Li 
> Cc: arm-soc ; Linux ARM  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; Shawn Guo 
> Subject: Re: [GIT PULL v2] for-next updates for soc/fsl drivers for v4.20 take
> 2
> 
> On Fri, Oct 5, 2018 at 9:30 PM Li Yang  wrote:
> >
> > 
> > NXP/FSL SoC drivers updates for v4.20 take 2
> >
> > - Update qbman driver to better work with CPU hotplug
> > - Add Kconfig dependency of 64-bit DMA addressing for qbman driver
> > - Use last reponse to determine valid bit for qbman driver
> > - Defer bman_portals probe if bman is not probed
> > - Add interrupt coalescing APIs to qbman driver
> 
> Pulled into next/drivers.
> 
> I was a little surprised to see these commits in your branch:
> 
>   ARM: dts: BCM63xx: Fix incorrect interrupt specifiers
>   MAINTAINERS: update the Annapurna Labs maintainer email
>   ARM: dts: sun8i: drop A64 HDMI PHY fallback compatible from R40 DT
>   ARM: dts: at91: sama5d2_ptc_ek: fix nand pinctrl
> 
> These are from our earlier 'fixes' branch and they were also part of your
> fixes branch that I already pulled, which you had based on top of the other
> fixes.
> 
> In the future, please don't do this again. Instead, base each branch on top
> of a plain -rc unless you have a specific reason to require something else
> (like in this case, where you require the fixes to build on top of).

I rebased my second fix pull request to the arm-soc fix branch because some 
patches from my first fix pull request were cherry picked to the fix branch.  I 
did the rebase to avoid conflicts in merge.   But probably your for-next branch 
doesn't have all the fix patches yet, so these patches showed up.

> 
> This time we were lucky because the 'fixes' branch you built on was also
> done on top of -rc1, so at least it did not contain any commits from
> upstream that were not already part of our next/drivers.
> 
>Arnd

RE: [GIT PULL v2] for-next updates for soc/fsl drivers for v4.20 take 2

[Leo Li]

> -Original Message-
> From: Arnd Bergmann 
> Sent: Monday, October 8, 2018 7:51 AM
> To: Leo Li 
> Cc: arm-soc ; Linux ARM  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; Shawn Guo 
> Subject: Re: [GIT PULL v2] for-next updates for soc/fsl drivers for v4.20 take
> 2
> 
> On Fri, Oct 5, 2018 at 9:30 PM Li Yang  wrote:
> >
> > 
> > NXP/FSL SoC drivers updates for v4.20 take 2
> >
> > - Update qbman driver to better work with CPU hotplug
> > - Add Kconfig dependency of 64-bit DMA addressing for qbman driver
> > - Use last reponse to determine valid bit for qbman driver
> > - Defer bman_portals probe if bman is not probed
> > - Add interrupt coalescing APIs to qbman driver
> 
> Pulled into next/drivers.
> 
> I was a little surprised to see these commits in your branch:
> 
>   ARM: dts: BCM63xx: Fix incorrect interrupt specifiers
>   MAINTAINERS: update the Annapurna Labs maintainer email
>   ARM: dts: sun8i: drop A64 HDMI PHY fallback compatible from R40 DT
>   ARM: dts: at91: sama5d2_ptc_ek: fix nand pinctrl
> 
> These are from our earlier 'fixes' branch and they were also part of your
> fixes branch that I already pulled, which you had based on top of the other
> fixes.
> 
> In the future, please don't do this again. Instead, base each branch on top
> of a plain -rc unless you have a specific reason to require something else
> (like in this case, where you require the fixes to build on top of).

I rebased my second fix pull request to the arm-soc fix branch because some 
patches from my first fix pull request were cherry picked to the fix branch.  I 
did the rebase to avoid conflicts in merge.   But probably your for-next branch 
doesn't have all the fix patches yet, so these patches showed up.

> 
> This time we were lucky because the 'fixes' branch you built on was also
> done on top of -rc1, so at least it did not contain any commits from
> upstream that were not already part of our next/drivers.
> 
>Arnd

RE: [GIT PULL] fixes for soc/fsl drivers for v4.19

[Leo Li]

> -Original Message-
> From: Olof Johansson 
> Sent: Tuesday, September 25, 2018 2:48 PM
> To: Leo Li 
> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; shawn...@kernel.org
> Subject: Re: [GIT PULL] fixes for soc/fsl drivers for v4.19
> 
> Hi,
> 
> On Mon, Sep 24, 2018 at 05:19:54PM -0500, Li Yang wrote:
> > Hi arm-soc maintainers,
> >
> > Please pull soc/fsl drivers fixes for v4.19.
> >
> > Regards,
> > Leo
> >
> >
> > The following changes since commit
> 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> >
> >   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git
> > tags/soc-fsl-fix-v4.19
> >
> > for you to fetch changes up to
> 3cb31b634052ed458922e0c8e2b4b093d7fb60b9:
> >
> >   soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift()
> > (2018-09-17 16:01:46 -0500)
> >
> > 
> > NXP/FSL SoC driver fixes for v4.19
> >
> > - Fix crash of qman_portal by deferring its probe if qman is not
> > probed
> > - Fix NULL pointer dereference by adding more checks in qman_portal
> > - Fix copy/paste bug in ucc_get_tdm_sync_shift()
> 
> Good summary, thanks!
> 
> However:
> 
> > Alexandre Belloni (2):
> >   soc: fsl: qbman: qman_portal: defer probing when qman is not
> > available
> 
> I think this fix has issues, I replied on the patch. Let me know if you want 
> me to
> cherry-pick the other two fixes for now.

Thanks for the review.  Please help to cherry-pick the other two.  I will work 
with the patch author for an update for the first one.

Regards,
Leo

RE: [GIT PULL] fixes for soc/fsl drivers for v4.19

[Leo Li]

> -Original Message-
> From: Olof Johansson 
> Sent: Tuesday, September 25, 2018 2:48 PM
> To: Leo Li 
> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; shawn...@kernel.org
> Subject: Re: [GIT PULL] fixes for soc/fsl drivers for v4.19
> 
> Hi,
> 
> On Mon, Sep 24, 2018 at 05:19:54PM -0500, Li Yang wrote:
> > Hi arm-soc maintainers,
> >
> > Please pull soc/fsl drivers fixes for v4.19.
> >
> > Regards,
> > Leo
> >
> >
> > The following changes since commit
> 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> >
> >   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git
> > tags/soc-fsl-fix-v4.19
> >
> > for you to fetch changes up to
> 3cb31b634052ed458922e0c8e2b4b093d7fb60b9:
> >
> >   soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift()
> > (2018-09-17 16:01:46 -0500)
> >
> > 
> > NXP/FSL SoC driver fixes for v4.19
> >
> > - Fix crash of qman_portal by deferring its probe if qman is not
> > probed
> > - Fix NULL pointer dereference by adding more checks in qman_portal
> > - Fix copy/paste bug in ucc_get_tdm_sync_shift()
> 
> Good summary, thanks!
> 
> However:
> 
> > Alexandre Belloni (2):
> >   soc: fsl: qbman: qman_portal: defer probing when qman is not
> > available
> 
> I think this fix has issues, I replied on the patch. Let me know if you want 
> me to
> cherry-pick the other two fixes for now.

Thanks for the review.  Please help to cherry-pick the other two.  I will work 
with the patch author for an update for the first one.

Regards,
Leo

RE: [GIT PULL] fixes for soc/fsl drivers for v4.19

[Leo Li]

> -Original Message-
> From: Olof Johansson 
> Sent: Sunday, September 23, 2018 7:37 AM
> To: Leo Li 
> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; shawn...@kernel.org
> Subject: Re: [GIT PULL] fixes for soc/fsl drivers for v4.19
> 
> Hi Li,
> 
> On Thu, Sep 20, 2018 at 11:56:56AM -0500, Li Yang wrote:
> > Hi arm-soc maintainers,
> >
> > Please merge the following fixes for soc/fsl drivers.
> >
> > Regards,
> > Leo
> >
> > The following changes since commit
> 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> >
> >   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git
> > tags/soc-fsl-fixes-for-4.19
> >
> > for you to fetch changes up to
> 3cb31b634052ed458922e0c8e2b4b093d7fb60b9:
> >
> >   soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift()
> > (2018-09-17 16:01:46 -0500)
> >
> > 
> > soc/fsl fixes for 4.19
> 
> Please spend a bit of effort on writing up the tag for all pull requests, even
> fixes. For fixes in particular, just as with the patch descriptions we want 
> the
> pull request to contain some brief information to what the bug is and why
> the fix is needed.
> 
> Care to give this another go with a new tag description, please?

Sure.  Will send a new version right away.

RE: [GIT PULL] fixes for soc/fsl drivers for v4.19

[Leo Li]

> -Original Message-
> From: Olof Johansson 
> Sent: Sunday, September 23, 2018 7:37 AM
> To: Leo Li 
> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; shawn...@kernel.org
> Subject: Re: [GIT PULL] fixes for soc/fsl drivers for v4.19
> 
> Hi Li,
> 
> On Thu, Sep 20, 2018 at 11:56:56AM -0500, Li Yang wrote:
> > Hi arm-soc maintainers,
> >
> > Please merge the following fixes for soc/fsl drivers.
> >
> > Regards,
> > Leo
> >
> > The following changes since commit
> 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> >
> >   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git
> > tags/soc-fsl-fixes-for-4.19
> >
> > for you to fetch changes up to
> 3cb31b634052ed458922e0c8e2b4b093d7fb60b9:
> >
> >   soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift()
> > (2018-09-17 16:01:46 -0500)
> >
> > 
> > soc/fsl fixes for 4.19
> 
> Please spend a bit of effort on writing up the tag for all pull requests, even
> fixes. For fixes in particular, just as with the patch descriptions we want 
> the
> pull request to contain some brief information to what the bug is and why
> the fix is needed.
> 
> Care to give this another go with a new tag description, please?

Sure.  Will send a new version right away.

RE: [PATCH 1/2] staging:fsl-mc: Move DPIO from staging to drivers/soc/fsl

[Leo Li]

> -Original Message-
> From: Roy Pledge
> Sent: Monday, July 9, 2018 10:24 AM
> To: Laurentiu Tudor ;
> de...@driverdev.osuosl.org; linux-arm-ker...@lists.infradead.org;
> gre...@linuxfoundation.org; Leo Li 
> Cc: Ioana Ciocoi Radulescu ; Horia Geanta
> ; linux-kernel@vger.kernel.org; a...@arndb.de;
> catalin.mari...@arm.com; robin.mur...@arm.com
> Subject: Re: [PATCH 1/2] staging:fsl-mc: Move DPIO from staging to
> drivers/soc/fsl
> 
> On 7/9/2018 6:37 AM, Laurentiu Tudor wrote:
> > Hi Roy,
> >
> > Couple of comments inline.
> >
> > On 05.07.2018 22:41, Roy Pledge wrote:
> >> Move the NXP DPIO (Datapath I/O Driver) out of the drivers/staging
> >> directory and into the drivers/soc/fsl directory.
> >>
> >> The DPIO driver enables access to Queue and Buffer Manager (QBMAN)
> >> hardware on NXP DPAA2 devices. This is a prerequisite to moving the
> >> DPAA2 Ethernet driver out of staging.
> >>
> >> Signed-off-by: Roy Pledge 
> >> ---
> >>   MAINTAINERS|  2 +-
> >>   drivers/crypto/caam/sg_sw_qm2.h|  2 +-
> >>   drivers/crypto/caam/sg_sw_sec4.h   |  2 +-
> >>   drivers/soc/fsl/Kconfig| 10 
> >> ++
> >>   drivers/soc/fsl/Makefile   |  1 +
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile  |  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h|  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c |  2 +-
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt   |  0
> > Maybe this should be converted to .rst and go in the already existing
> > Documentation/networking/dpaa2/?
> 
> I can look into converting this to RST but I'm not sure it belongs in the
> networking documentation folder since it will be used by other non
> networking drivers in the near future - compress/decompress for example.
> >
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c|  2 +-
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c|  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h|  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c|  2 +-
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h|  2 +-
> >>   drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  4 ++--
> >>   drivers/staging/fsl-mc/bus/Kconfig |  9 
> >> -
> >>   drivers/staging/fsl-mc/bus/Makefile|  2 --
> >>   {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h |  0
> >>   .../staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h  |  0
> >>   {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h |  0
> >>   20 files changed, 20 insertions(+), 20 deletions(-)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c (99%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt
> (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c (99%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c
> (99%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h
> (99%)
> >>   rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h
> (100%)
> >>   rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-
> global.h (100%)
> >>   rename {drivers/staging/fsl-mc/include =>
> >> include/soc/fsl}/dpaa2-io.h (100%)
> > I received feedback in the past on mc-bus that a driver should limit
> > to only one public header and one private one. Would it make sense to
> > do the same for dpio too?
> Looking at this the dpaa-2global.h file should probably be integrated into the
> dpaa2-io.h file.
> The dpaaa2-fd.h can be used by devices that don't need to used DPIO - the
> definition of a frame descriptor isn't DPIO specific so I would argue it 
> should
> be kept in a seperate file.

Hi Roy,

Will there be a re-spin of the patch soon so that we can probably catch the 
next merge window?

Regards,
Leo

RE: [PATCH 1/2] staging:fsl-mc: Move DPIO from staging to drivers/soc/fsl

[Leo Li]

> -Original Message-
> From: Roy Pledge
> Sent: Monday, July 9, 2018 10:24 AM
> To: Laurentiu Tudor ;
> de...@driverdev.osuosl.org; linux-arm-ker...@lists.infradead.org;
> gre...@linuxfoundation.org; Leo Li 
> Cc: Ioana Ciocoi Radulescu ; Horia Geanta
> ; linux-kernel@vger.kernel.org; a...@arndb.de;
> catalin.mari...@arm.com; robin.mur...@arm.com
> Subject: Re: [PATCH 1/2] staging:fsl-mc: Move DPIO from staging to
> drivers/soc/fsl
> 
> On 7/9/2018 6:37 AM, Laurentiu Tudor wrote:
> > Hi Roy,
> >
> > Couple of comments inline.
> >
> > On 05.07.2018 22:41, Roy Pledge wrote:
> >> Move the NXP DPIO (Datapath I/O Driver) out of the drivers/staging
> >> directory and into the drivers/soc/fsl directory.
> >>
> >> The DPIO driver enables access to Queue and Buffer Manager (QBMAN)
> >> hardware on NXP DPAA2 devices. This is a prerequisite to moving the
> >> DPAA2 Ethernet driver out of staging.
> >>
> >> Signed-off-by: Roy Pledge 
> >> ---
> >>   MAINTAINERS|  2 +-
> >>   drivers/crypto/caam/sg_sw_qm2.h|  2 +-
> >>   drivers/crypto/caam/sg_sw_sec4.h   |  2 +-
> >>   drivers/soc/fsl/Kconfig| 10 
> >> ++
> >>   drivers/soc/fsl/Makefile   |  1 +
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile  |  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h|  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c |  2 +-
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt   |  0
> > Maybe this should be converted to .rst and go in the already existing
> > Documentation/networking/dpaa2/?
> 
> I can look into converting this to RST but I'm not sure it belongs in the
> networking documentation folder since it will be used by other non
> networking drivers in the near future - compress/decompress for example.
> >
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c|  2 +-
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c|  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h|  0
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c|  2 +-
> >>   drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h|  2 +-
> >>   drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  4 ++--
> >>   drivers/staging/fsl-mc/bus/Kconfig |  9 
> >> -
> >>   drivers/staging/fsl-mc/bus/Makefile|  2 --
> >>   {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h |  0
> >>   .../staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h  |  0
> >>   {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h |  0
> >>   20 files changed, 20 insertions(+), 20 deletions(-)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c (99%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt
> (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c (99%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h (100%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c
> (99%)
> >>   rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h
> (99%)
> >>   rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h
> (100%)
> >>   rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-
> global.h (100%)
> >>   rename {drivers/staging/fsl-mc/include =>
> >> include/soc/fsl}/dpaa2-io.h (100%)
> > I received feedback in the past on mc-bus that a driver should limit
> > to only one public header and one private one. Would it make sense to
> > do the same for dpio too?
> Looking at this the dpaa-2global.h file should probably be integrated into the
> dpaa2-io.h file.
> The dpaaa2-fd.h can be used by devices that don't need to used DPIO - the
> definition of a frame descriptor isn't DPIO specific so I would argue it 
> should
> be kept in a seperate file.

Hi Roy,

Will there be a re-spin of the patch soon so that we can probably catch the 
next merge window?

Regards,
Leo

RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM

[Leo Li]

> -Original Message-
> From: Yinbo Zhu [mailto:yinbo@nxp.com]
> Sent: Thursday, May 10, 2018 10:35 PM
> To: Yinbo Zhu <yinbo@nxp.com>; Rob Herring <robh...@kernel.org>;
> Mark Rutland <mark.rutl...@arm.com>; Catalin Marinas )
> <catalin.mari...@arm.com>; Will Deacon ) <will.dea...@arm.com>;
> Lorenzo Pieralisi ) <lorenzo.pieral...@arm.com>; Leo Li <leoyang...@nxp.com>
> Cc: Xiaobo Xie <xiaobo@nxp.com>; Ran Wang <ran.wan...@nxp.com>;
> Daniel Lezcano <daniel.lezc...@linaro.org>; Thomas Gleixner
> <t...@linutronix.de>; Shawn Guo <shawn...@kernel.org>; Madalin-cristian
> Bucur <madalin.bu...@nxp.com>; Z.q. Hou <zhiqiang@nxp.com>; Jerry
> Huang <jerry.hu...@nxp.com>; M.h. Lian <minghuan.l...@nxp.com>;
> Qiang Zhao <qiang.z...@nxp.com>; Fabio Estevam
> <fabio.este...@nxp.com>; Jiaheng Fan <jiaheng@nxp.com>; Po Liu
> <po@nxp.com>; Nipun Gupta <nipun.gu...@nxp.com>; Horia Geantă
> <horia.gea...@nxp.com>; Priyanka Jain <priyanka.j...@nxp.com>; Sumit
> Garg <sumit.g...@nxp.com>; costi <constantin.tu...@freescale.com>;
> Bogdan Purcareata <bogdan.purcare...@nxp.com>; Meng Yi
> <meng...@nxp.com>; Wang Dongsheng <dongsheng.w...@nxp.com>; open
> list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicet...@vger.kernel.org>; linux-arm-ker...@lists.infradead.org; open
> list:FREESCALE SOC DRIVERS <linuxppc-...@lists.ozlabs.org>; Andy Tang
> <andy.t...@nxp.com>; Ying Zhang <ying.zhang22...@nxp.com>
> Subject: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
> 
> From: Zhang Ying-22455 <ying.zhang22...@nxp.com>
> 
> Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
> module of each platform has different big-end and little-end mode, there
> need to set RCPM depending on the platform.
> 
> Signed-off-by: Zhang Ying-22455 <ying.zhang22...@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo@nxp.com>
> ---
>  .../devicetree/bindings/timer/fsl,ftm-timer.txt|7 ++
>  drivers/soc/fsl/layerscape/ftm_alarm.c |   92 ++-
>  2 files changed, 94 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> index aa8c402..15ead58 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> @@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer  Required
> properties:
> 
>  - compatible : should be "fsl,ftm-timer"

Hi Yingbo,

This is a change that breaks backward compatibility and not acceptable.

> + Possible compatibles for ARM:
> + "fsl,ls1012a-ftm"
> + "fsl,ls1021a-ftm"
> + "fsl,ls1043a-ftm"
> + "fsl,ls1046a-ftm"
> + "fsl,ls1088a-ftm"
> + "fsl,ls208xa-ftm"
>  - reg : Specifies base physical address and size of the register sets for the
>clock event device and clock source device.
>  - interrupts : Should be the clock event device interrupt.
> diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c
> b/drivers/soc/fsl/layerscape/ftm_alarm.c
> index 6f9882f..811dcfa 100644
> --- a/drivers/soc/fsl/layerscape/ftm_alarm.c
> +++ b/drivers/soc/fsl/layerscape/ftm_alarm.c

There is no such file in the mainline kernel.  So it looks like the patch set 
is based on some internal git repo instead of the upstream Linux kernel.  This 
kind of patches shouldn't be sent to the upstream mailing list for review.

Regards,
Leo

RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM

[Leo Li]

> -Original Message-
> From: Yinbo Zhu [mailto:yinbo@nxp.com]
> Sent: Thursday, May 10, 2018 10:35 PM
> To: Yinbo Zhu ; Rob Herring ;
> Mark Rutland ; Catalin Marinas )
> ; Will Deacon ) ;
> Lorenzo Pieralisi ) ; Leo Li 
> Cc: Xiaobo Xie ; Ran Wang ;
> Daniel Lezcano ; Thomas Gleixner
> ; Shawn Guo ; Madalin-cristian
> Bucur ; Z.q. Hou ; Jerry
> Huang ; M.h. Lian ;
> Qiang Zhao ; Fabio Estevam
> ; Jiaheng Fan ; Po Liu
> ; Nipun Gupta ; Horia Geantă
> ; Priyanka Jain ; Sumit
> Garg ; costi ;
> Bogdan Purcareata ; Meng Yi
> ; Wang Dongsheng ; open
> list:CLOCKSOURCE, CLOCKEVENT DRIVERS ;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; linux-arm-ker...@lists.infradead.org; open
> list:FREESCALE SOC DRIVERS ; Andy Tang
> ; Ying Zhang 
> Subject: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
> 
> From: Zhang Ying-22455 
> 
> Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
> module of each platform has different big-end and little-end mode, there
> need to set RCPM depending on the platform.
> 
> Signed-off-by: Zhang Ying-22455 
> Signed-off-by: Yinbo Zhu 
> ---
>  .../devicetree/bindings/timer/fsl,ftm-timer.txt|7 ++
>  drivers/soc/fsl/layerscape/ftm_alarm.c |   92 ++-
>  2 files changed, 94 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> index aa8c402..15ead58 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> @@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer  Required
> properties:
> 
>  - compatible : should be "fsl,ftm-timer"

Hi Yingbo,

This is a change that breaks backward compatibility and not acceptable.

> + Possible compatibles for ARM:
> + "fsl,ls1012a-ftm"
> + "fsl,ls1021a-ftm"
> + "fsl,ls1043a-ftm"
> + "fsl,ls1046a-ftm"
> + "fsl,ls1088a-ftm"
> + "fsl,ls208xa-ftm"
>  - reg : Specifies base physical address and size of the register sets for the
>clock event device and clock source device.
>  - interrupts : Should be the clock event device interrupt.
> diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c
> b/drivers/soc/fsl/layerscape/ftm_alarm.c
> index 6f9882f..811dcfa 100644
> --- a/drivers/soc/fsl/layerscape/ftm_alarm.c
> +++ b/drivers/soc/fsl/layerscape/ftm_alarm.c

There is no such file in the mainline kernel.  So it looks like the patch set 
is based on some internal git repo instead of the upstream Linux kernel.  This 
kind of patches shouldn't be sent to the upstream mailing list for review.

Regards,
Leo

RE: [PATCHv4 1/3] ARMv8: dts: ls1046a: add the property of IB and OB

[Leo Li]

> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Friday, November 10, 2017 12:22 AM
> To: Xiaowei Bao <xiaowei@nxp.com>; robh...@kernel.org;
> mark.rutl...@arm.com; catalin.mari...@arm.com; will.dea...@arm.com;
> bhelg...@google.com; shawn...@kernel.org; Madalin-cristian Bucur
> <madalin.bu...@nxp.com>; Sumit Garg <sumit.g...@nxp.com>; Y.b. Lu
> <yangbo...@nxp.com>; hongtao....@nxp.com; Andy Tang
> <andy.t...@nxp.com>; Leo Li <leoyang...@nxp.com>; jingooh...@gmail.com;
> pbrobin...@gmail.com; songxiao...@hisilicon.com;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Z.q. Hou <zhiqiang@nxp.com>; Mingkai Hu
> <mingkai...@nxp.com>; M.h. Lian <minghuan.l...@nxp.com>
> Subject: Re: [PATCHv4 1/3] ARMv8: dts: ls1046a: add the property of IB and OB
> 
> Hi Bao,
> 
> On Friday 10 November 2017 09:18 AM, Bao Xiaowei wrote:
> > Add the property of inbound and outbound windows number for ep driver.
> >
> > Signed-off-by: Bao Xiaowei <xiaowei@nxp.com>
> > Acked-by: Minghuan Lian <minghuan.l...@nxp.com>
> > ---
> >  v2:
> >  - no change
> >  v3:
> >  - modify the commit message
> >  v4:
> >  - no change
> >
> >  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> $subject should start with something like
> arm64: dts: ls1046a: **
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > index 06b5e12d04d8..f8332669663c 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > @@ -674,6 +674,8 @@
> > device_type = "pci";
> > dma-coherent;
> > num-lanes = <4>;
> > +   num-ib-windows = <6>;
> > +   num-ob-windows = <6>;
> 
> EP specific properties shouldn't be added in RC dt node. Ideally you should 
> have
> a separate dt node for RC and EP.

It is a single PCIe controller which can be configured to either RC mode or EP 
mode.  Wouldn't it conflict with the device tree principles to have two device 
tree nodes for the same PCIe controller?  And obviously the two modes cannot be 
used at the same time so we cannot have two drivers both probe on the same 
hardware.

Regards,
Leo

RE: [PATCHv4 1/3] ARMv8: dts: ls1046a: add the property of IB and OB

[Leo Li]

> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Friday, November 10, 2017 12:22 AM
> To: Xiaowei Bao ; robh...@kernel.org;
> mark.rutl...@arm.com; catalin.mari...@arm.com; will.dea...@arm.com;
> bhelg...@google.com; shawn...@kernel.org; Madalin-cristian Bucur
> ; Sumit Garg ; Y.b. Lu
> ; hongtao@nxp.com; Andy Tang
> ; Leo Li ; jingooh...@gmail.com;
> pbrobin...@gmail.com; songxiao...@hisilicon.com;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Z.q. Hou ; Mingkai Hu
> ; M.h. Lian 
> Subject: Re: [PATCHv4 1/3] ARMv8: dts: ls1046a: add the property of IB and OB
> 
> Hi Bao,
> 
> On Friday 10 November 2017 09:18 AM, Bao Xiaowei wrote:
> > Add the property of inbound and outbound windows number for ep driver.
> >
> > Signed-off-by: Bao Xiaowei 
> > Acked-by: Minghuan Lian 
> > ---
> >  v2:
> >  - no change
> >  v3:
> >  - modify the commit message
> >  v4:
> >  - no change
> >
> >  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> $subject should start with something like
> arm64: dts: ls1046a: **
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > index 06b5e12d04d8..f8332669663c 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> > @@ -674,6 +674,8 @@
> > device_type = "pci";
> > dma-coherent;
> > num-lanes = <4>;
> > +   num-ib-windows = <6>;
> > +   num-ob-windows = <6>;
> 
> EP specific properties shouldn't be added in RC dt node. Ideally you should 
> have
> a separate dt node for RC and EP.

It is a single PCIe controller which can be configured to either RC mode or EP 
mode.  Wouldn't it conflict with the device tree principles to have two device 
tree nodes for the same PCIe controller?  And obviously the two modes cannot be 
used at the same time so we cannot have two drivers both probe on the same 
hardware.

Regards,
Leo

RE: [PATCH 0/3] dts: Add the property of IB and OB

[Leo Li]

> -Original Message-
> From: Bao Xiaowei [mailto:xiaowei@nxp.com]
> Sent: Friday, November 03, 2017 4:31 AM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; bhelg...@google.com; shawn...@kernel.org;
> Madalin-cristian Bucur <madalin.bu...@nxp.com>; Sumit Garg
> <sumit.g...@nxp.com>; Y.b. Lu <yangbo...@nxp.com>; hongtao@nxp.com;
> Andy Tang <andy.t...@nxp.com>; Leo Li <leoyang...@nxp.com>;
> kis...@ti.com; jingooh...@gmail.com; pbrobin...@gmail.com;
> songxiao...@hisilicon.com; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Z.q. Hou
> <zhiqiang@nxp.com>; Mingkai Hu <mingkai...@nxp.com>; M.h. Lian
> <minghuan.l...@nxp.com>
> Cc: Xiaowei Bao <xiaowei@nxp.com>
> Subject: [PATCH 0/3] dts: Add the property of IB and OB

When you send a v2 series, please include v2 in the title of all patches like 
"[PATCH v2 0/3]"...

Also the title of this summary email should really be the summary of all 3 
patches like "Adding PCIe EP support to ls1046a".

-Leo


> 
> Depend on
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchw
> ork.ozlabs.org%2Fpatch%2F815382%2F=02%7C01%7Cleoyang.li%40nxp.c
> om%7C7db015020c8a414f57e708d522a03165%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C636452993777387982=19Fmzg%2FOJGl%2Bgizv
> xfY1yELlFgWKRuZ%2FVNbx49yz2Wk%3D=0
> 
> Bao Xiaowei (3):
>   ARMv8: dts: ls1046a: add the property of IB and OB
>   ARMv8: layerscape: add the pcie ep function support
>   ARMv8: pcie: make the DWC EP driver support for layerscape
> 
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   6 ++
>  drivers/pci/dwc/Kconfig|   1 +
>  drivers/pci/dwc/pci-layerscape.c   | 122 
> +++--
>  3 files changed, 123 insertions(+), 6 deletions(-)
> 
> --
> 2.14.1

RE: [PATCH 0/3] dts: Add the property of IB and OB

[Leo Li]

> -Original Message-
> From: Bao Xiaowei [mailto:xiaowei@nxp.com]
> Sent: Friday, November 03, 2017 4:31 AM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; bhelg...@google.com; shawn...@kernel.org;
> Madalin-cristian Bucur ; Sumit Garg
> ; Y.b. Lu ; hongtao@nxp.com;
> Andy Tang ; Leo Li ;
> kis...@ti.com; jingooh...@gmail.com; pbrobin...@gmail.com;
> songxiao...@hisilicon.com; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Z.q. Hou
> ; Mingkai Hu ; M.h. Lian
> 
> Cc: Xiaowei Bao 
> Subject: [PATCH 0/3] dts: Add the property of IB and OB

When you send a v2 series, please include v2 in the title of all patches like 
"[PATCH v2 0/3]"...

Also the title of this summary email should really be the summary of all 3 
patches like "Adding PCIe EP support to ls1046a".

-Leo


> 
> Depend on
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchw
> ork.ozlabs.org%2Fpatch%2F815382%2F=02%7C01%7Cleoyang.li%40nxp.c
> om%7C7db015020c8a414f57e708d522a03165%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C636452993777387982=19Fmzg%2FOJGl%2Bgizv
> xfY1yELlFgWKRuZ%2FVNbx49yz2Wk%3D=0
> 
> Bao Xiaowei (3):
>   ARMv8: dts: ls1046a: add the property of IB and OB
>   ARMv8: layerscape: add the pcie ep function support
>   ARMv8: pcie: make the DWC EP driver support for layerscape
> 
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   6 ++
>  drivers/pci/dwc/Kconfig|   1 +
>  drivers/pci/dwc/pci-layerscape.c   | 122 
> +++--
>  3 files changed, 123 insertions(+), 6 deletions(-)
> 
> --
> 2.14.1

RE: [v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

[Leo Li]

> -Original Message-
> From: Roy Pledge [mailto:roy.ple...@nxp.com]
> Sent: Monday, September 18, 2017 3:40 PM
> To: Leo Li <leoyang...@nxp.com>; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Cc: o...@buserror.net; Madalin-cristian Bucur <madalin.bu...@nxp.com>;
> catalin.mari...@arm.com; li...@armlinux.org.uk; a...@arndb.de;
> mark.rutl...@arm.com; Roy Pledge <roy.ple...@nxp.com>
> Subject: [v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for
> QBMan
> 
> Updates the QMan and BMan device tree bindings for reserved memory
> nodes. This makes the reserved memory allocation compatible with
> the shared-dma-pool usage.
> 
> Signed-off-by: Roy Pledge <roy.ple...@nxp.com>

Hi Rob and Mark,

Would you help to review this binding patch and ACK if it is ok?

Regards,
Leo

> ---
>  Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +-
>  Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 -
> -
>  2 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.txt
> b/Documentation/devicetree/bindings/soc/fsl/bman.txt
> index 47ac834..48eed14 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/bman.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/bman.txt
> @@ -65,8 +65,8 @@ to the respective BMan instance
>  BMan Private Memory Node
> 
>  BMan requires a contiguous range of physical memory used for the backing
> store
> -for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated
> as a
> -node under the /reserved-memory node
> +for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated
> as
> +a node under the /reserved-memory node.
> 
>  The BMan FBPR memory node must be named "bman-fbpr"
> 
> @@ -75,7 +75,9 @@ PROPERTIES
>  - compatible
>   Usage:  required
>   Value type: 
> - Definition: Must inclide "fsl,bman-fbpr"
> + Definition: PPC platforms: Must include "fsl,bman-fbpr"
> + ARM platforms: Must include "shared-dma-pool"
> +as well as the "no-map" property
> 
>  The following constraints are relevant to the FBPR private memory:
>   - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
> @@ -100,10 +102,10 @@ The example below shows a BMan FBPR dynamic
> allocation memory node
>   ranges;
> 
>   bman_fbpr: bman-fbpr {
> - compatible = "fsl,bman-fbpr";
> - alloc-ranges = <0 0 0x10 0>;
> + compatible = "shared-mem-pool";
>   size = <0 0x100>;
>   alignment = <0 0x100>;
> + no-map;
>   };
>   };
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/qman.txt
> b/Documentation/devicetree/bindings/soc/fsl/qman.txt
> index 556ebb8..ee96afd 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/qman.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/qman.txt
> @@ -60,6 +60,12 @@ are located at offsets 0xbf8 and 0xbfc
>   Value type: 
>   Definition: Reference input clock. Its frequency is half of the
>   platform clock
> +- memory-regions
> + Usage:  Required for ARM
> + Value type: 
> + Definition: List of phandles referencing the QMan private memory
> + nodes (described below). The qman-fqd node must be
> + first followed by qman-pfdr node. Only used on ARM
> 
>  Devices connected to a QMan instance via Direct Connect Portals (DCP) must
> link
>  to the respective QMan instance
> @@ -74,7 +80,9 @@ QMan Private Memory Nodes
> 
>  QMan requires two contiguous range of physical memory used for the backing
> store
>  for QMan Frame Queue Descriptor (FQD) and Packed Frame Descriptor Record
> (PFDR).
> -This memory is reserved/allocated as a nodes under the /reserved-memory
> node
> +This memory is reserved/allocated as a node under the /reserved-memory
> node.
> +
> +For additional details about reserved memory regions see reserved-memory.txt
> 
>  The QMan FQD memory node must be named "qman-fqd"
> 
> @@ -83,7 +91,9 @@ PROPERTIES
>  - compatible
>   Usage:  required
>   Value type: 
> - Definition: Must inclide "fsl,qman-fqd"
> + Definition: PPC platforms: Must include "fsl,qman-fqd"
> +

RE: [v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

[Leo Li]

> -Original Message-
> From: Roy Pledge [mailto:roy.ple...@nxp.com]
> Sent: Monday, September 18, 2017 3:40 PM
> To: Leo Li ; linuxppc-...@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Cc: o...@buserror.net; Madalin-cristian Bucur ;
> catalin.mari...@arm.com; li...@armlinux.org.uk; a...@arndb.de;
> mark.rutl...@arm.com; Roy Pledge 
> Subject: [v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for
> QBMan
> 
> Updates the QMan and BMan device tree bindings for reserved memory
> nodes. This makes the reserved memory allocation compatible with
> the shared-dma-pool usage.
> 
> Signed-off-by: Roy Pledge 

Hi Rob and Mark,

Would you help to review this binding patch and ACK if it is ok?

Regards,
Leo

> ---
>  Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +-
>  Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 -
> -
>  2 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.txt
> b/Documentation/devicetree/bindings/soc/fsl/bman.txt
> index 47ac834..48eed14 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/bman.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/bman.txt
> @@ -65,8 +65,8 @@ to the respective BMan instance
>  BMan Private Memory Node
> 
>  BMan requires a contiguous range of physical memory used for the backing
> store
> -for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated
> as a
> -node under the /reserved-memory node
> +for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated
> as
> +a node under the /reserved-memory node.
> 
>  The BMan FBPR memory node must be named "bman-fbpr"
> 
> @@ -75,7 +75,9 @@ PROPERTIES
>  - compatible
>   Usage:  required
>   Value type: 
> - Definition: Must inclide "fsl,bman-fbpr"
> + Definition: PPC platforms: Must include "fsl,bman-fbpr"
> + ARM platforms: Must include "shared-dma-pool"
> +as well as the "no-map" property
> 
>  The following constraints are relevant to the FBPR private memory:
>   - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
> @@ -100,10 +102,10 @@ The example below shows a BMan FBPR dynamic
> allocation memory node
>   ranges;
> 
>   bman_fbpr: bman-fbpr {
> - compatible = "fsl,bman-fbpr";
> - alloc-ranges = <0 0 0x10 0>;
> + compatible = "shared-mem-pool";
>   size = <0 0x100>;
>   alignment = <0 0x100>;
> + no-map;
>   };
>   };
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/qman.txt
> b/Documentation/devicetree/bindings/soc/fsl/qman.txt
> index 556ebb8..ee96afd 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/qman.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/qman.txt
> @@ -60,6 +60,12 @@ are located at offsets 0xbf8 and 0xbfc
>   Value type: 
>   Definition: Reference input clock. Its frequency is half of the
>   platform clock
> +- memory-regions
> + Usage:  Required for ARM
> + Value type: 
> + Definition: List of phandles referencing the QMan private memory
> + nodes (described below). The qman-fqd node must be
> + first followed by qman-pfdr node. Only used on ARM
> 
>  Devices connected to a QMan instance via Direct Connect Portals (DCP) must
> link
>  to the respective QMan instance
> @@ -74,7 +80,9 @@ QMan Private Memory Nodes
> 
>  QMan requires two contiguous range of physical memory used for the backing
> store
>  for QMan Frame Queue Descriptor (FQD) and Packed Frame Descriptor Record
> (PFDR).
> -This memory is reserved/allocated as a nodes under the /reserved-memory
> node
> +This memory is reserved/allocated as a node under the /reserved-memory
> node.
> +
> +For additional details about reserved memory regions see reserved-memory.txt
> 
>  The QMan FQD memory node must be named "qman-fqd"
> 
> @@ -83,7 +91,9 @@ PROPERTIES
>  - compatible
>   Usage:  required
>   Value type: 
> - Definition: Must inclide "fsl,qman-fqd"
> + Definition: PPC platforms: Must include "fsl,qman-fqd"
> + ARM platforms: Must include "shared-dma-pool"
> + 

RE: [linux-devel] [PATCH 3/3] core-arm: add a member about dma_map_ops in dev_archdata struct

[Leo Li]

> -Original Message-
> From: linux-devel-boun...@gforge.freescale.net [mailto:linux-devel-
> boun...@gforge.freescale.net] On Behalf Of yinbo@nxp.com
> Sent: Friday, August 11, 2017 5:01 AM
> To: linux-de...@gforge.freescale.net; Yinbo Zhu ; Rob
> Herring ; Mark Rutland ;
> Russell King ; Felipe Balbi 
> Cc: open list ; Laurent Pinchart
> ; Catalin Marinas
> ; open list ; open list
> ; Doug Ledford ;
> Stefano Stabellini ; Greg Kroah-Hartman
> ; Bart Van Assche
> ; moderated list  ker...@lists.infradead.org>
> Subject: [linux-devel] [PATCH 3/3] core-arm: add a member about
> dma_map_ops in dev_archdata struct
> 
> From: "yinbo.zhu" 

The dma_ops was just moved from struct dev_archdata to struct device with 
commit 5657933dbb6e25feaf5d8df8c88f96cdade693a3.  Don't duplicate the dma_ops 
in both places if you don't have a good reason.

> 
> Signed-off-by: yinbo.zhu 
> ---
>  arch/arm/include/asm/device.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index 220ba20..c93d3df 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -7,6 +7,7 @@
>  #define ASMARM_DEVICE_H
> 
>  struct dev_archdata {
> +const struct dma_map_ops*dma_ops;
>  #ifdef CONFIG_DMABOUNCE
>   struct dmabounce_device_info *dmabounce;  #endif
> --
> 2.1.0.27.g96db324
> 
> ___
> linux-devel mailing list
> linux-de...@gforge.freescale.net
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgforge.
> freescale.net%2Fmailman%2Flistinfo%2Flinux-
> devel=01%7C01%7Cleoyang.li%40nxp.com%7Cc83542988dac448bd8b908
> d4e0a230af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=1pbSjxG781
> yjcCF%2BuXbRCkV6ytbfTTgQkHNWmm0e9nk%3D=0

RE: [linux-devel] [PATCH 3/3] core-arm: add a member about dma_map_ops in dev_archdata struct

[Leo Li]

> -Original Message-
> From: linux-devel-boun...@gforge.freescale.net [mailto:linux-devel-
> boun...@gforge.freescale.net] On Behalf Of yinbo@nxp.com
> Sent: Friday, August 11, 2017 5:01 AM
> To: linux-de...@gforge.freescale.net; Yinbo Zhu ; Rob
> Herring ; Mark Rutland ;
> Russell King ; Felipe Balbi 
> Cc: open list ; Laurent Pinchart
> ; Catalin Marinas
> ; open list ; open list
> ; Doug Ledford ;
> Stefano Stabellini ; Greg Kroah-Hartman
> ; Bart Van Assche
> ; moderated list  ker...@lists.infradead.org>
> Subject: [linux-devel] [PATCH 3/3] core-arm: add a member about
> dma_map_ops in dev_archdata struct
> 
> From: "yinbo.zhu" 

The dma_ops was just moved from struct dev_archdata to struct device with 
commit 5657933dbb6e25feaf5d8df8c88f96cdade693a3.  Don't duplicate the dma_ops 
in both places if you don't have a good reason.

> 
> Signed-off-by: yinbo.zhu 
> ---
>  arch/arm/include/asm/device.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index 220ba20..c93d3df 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -7,6 +7,7 @@
>  #define ASMARM_DEVICE_H
> 
>  struct dev_archdata {
> +const struct dma_map_ops*dma_ops;
>  #ifdef CONFIG_DMABOUNCE
>   struct dmabounce_device_info *dmabounce;  #endif
> --
> 2.1.0.27.g96db324
> 
> ___
> linux-devel mailing list
> linux-de...@gforge.freescale.net
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgforge.
> freescale.net%2Fmailman%2Flistinfo%2Flinux-
> devel=01%7C01%7Cleoyang.li%40nxp.com%7Cc83542988dac448bd8b908
> d4e0a230af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=1pbSjxG781
> yjcCF%2BuXbRCkV6ytbfTTgQkHNWmm0e9nk%3D=0

RE: [linux-devel] [PATCH 1/3] dts: usb3: Add configure-gfladj property to USB3 nod

[Leo Li]

> -Original Message-
> From: linux-devel-boun...@gforge.freescale.net [mailto:linux-devel-
> boun...@gforge.freescale.net] On Behalf Of yinbo@nxp.com
> Sent: Friday, August 11, 2017 4:30 AM
> To: linux-de...@gforge.freescale.net; Yinbo Zhu ; Rob
> Herring ; Mark Rutland ;
> Russell King ; Felipe Balbi 
> Cc: open list ; Laurent Pinchart
> ; Catalin Marinas
> ; open list ; open list
> ; Doug Ledford ;
> Stefano Stabellini ; Greg Kroah-Hartman
> ; Bart Van Assche
> ; moderated list  ker...@lists.infradead.org>
> Subject: [linux-devel] [PATCH 1/3] dts: usb3: Add configure-gfladj property to
> USB3 nod
> 
> From: "yinbo.zhu" 
> 

There is no device tree binding for this property.  You need to add the binding 
first before you add it to the dts.  And normally you need to describe why the 
change is needed in the commit message.

> Signed-off-by: yinbo.zhu 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index ffbf3cf..f525297 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -731,6 +731,8 @@
>   interrupts = ;
>   dr_mode = "host";
>   snps,quirk-frame-length-adjustment = <0x20>;
> + configure-gfladj;
> + dma-coherent;

This change is not aligned with your patch title.

>   snps,dis_rxdet_inp3_quirk;
>   };
> 
> --
> 2.1.0.27.g96db324
> 
> ___
> linux-devel mailing list
> linux-de...@gforge.freescale.net
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgforge.
> freescale.net%2Fmailman%2Flistinfo%2Flinux-
> devel=01%7C01%7Cleoyang.li%40nxp.com%7C015b054c76ad48399ea408
> d4e09de91d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=7ioU%2Bb
> QUP4X%2F8%2BFpcQZICVDHugioStScbrHc0XOqaQs%3D=0

RE: [linux-devel] [PATCH 1/3] dts: usb3: Add configure-gfladj property to USB3 nod

[Leo Li]

> -Original Message-
> From: linux-devel-boun...@gforge.freescale.net [mailto:linux-devel-
> boun...@gforge.freescale.net] On Behalf Of yinbo@nxp.com
> Sent: Friday, August 11, 2017 4:30 AM
> To: linux-de...@gforge.freescale.net; Yinbo Zhu ; Rob
> Herring ; Mark Rutland ;
> Russell King ; Felipe Balbi 
> Cc: open list ; Laurent Pinchart
> ; Catalin Marinas
> ; open list ; open list
> ; Doug Ledford ;
> Stefano Stabellini ; Greg Kroah-Hartman
> ; Bart Van Assche
> ; moderated list  ker...@lists.infradead.org>
> Subject: [linux-devel] [PATCH 1/3] dts: usb3: Add configure-gfladj property to
> USB3 nod
> 
> From: "yinbo.zhu" 
> 

There is no device tree binding for this property.  You need to add the binding 
first before you add it to the dts.  And normally you need to describe why the 
change is needed in the commit message.

> Signed-off-by: yinbo.zhu 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index ffbf3cf..f525297 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -731,6 +731,8 @@
>   interrupts = ;
>   dr_mode = "host";
>   snps,quirk-frame-length-adjustment = <0x20>;
> + configure-gfladj;
> + dma-coherent;

This change is not aligned with your patch title.

>   snps,dis_rxdet_inp3_quirk;
>   };
> 
> --
> 2.1.0.27.g96db324
> 
> ___
> linux-devel mailing list
> linux-de...@gforge.freescale.net
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgforge.
> freescale.net%2Fmailman%2Flistinfo%2Flinux-
> devel=01%7C01%7Cleoyang.li%40nxp.com%7C015b054c76ad48399ea408
> d4e09de91d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=7ioU%2Bb
> QUP4X%2F8%2BFpcQZICVDHugioStScbrHc0XOqaQs%3D=0

RE: [linux-devel] [PATCH 2/3] usb: dwc3 : Add support for USB snooping

[Leo Li]

> -Original Message-
> From: linux-devel-boun...@gforge.freescale.net [mailto:linux-devel-
> boun...@gforge.freescale.net] On Behalf Of yinbo@nxp.com
> Sent: Friday, August 11, 2017 5:00 AM
> To: linux-de...@gforge.freescale.net; Yinbo Zhu ; Rob
> Herring ; Mark Rutland ;
> Russell King ; Felipe Balbi 
> Cc: open list ; Laurent Pinchart
> ; Catalin Marinas
> ; open list ; open list
> ; Doug Ledford ;
> Stefano Stabellini ; Greg Kroah-Hartman
> ; Bart Van Assche
> ; moderated list  ker...@lists.infradead.org>
> Subject: [linux-devel] [PATCH 2/3] usb: dwc3 : Add support for USB snooping
> 
> From: Rajesh Bhagat 
> 
> Add support for USB3 snooping by asserting bits in register DWC3_GSBUSCFG0
> for data and descriptor

The description doesn't fully cover the change you made below, for example 
allocating multiple event buffers.  Please explain why you made such change.

> 
> Signed-off-by: Nikhil Badola 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: yinbo.zhu 
> ---
>  drivers/usb/dwc3/core.c | 71 ---
> --
>  drivers/usb/dwc3/core.h |  3 +++
>  drivers/usb/dwc3/host.c |  8 +-
>  3 files changed, 63 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index
> 02a534a..b51b0d8 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -90,6 +90,7 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
> 
>   if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
>   mode = USB_DR_MODE_HOST;
> +

Why are you adding a new line here?

>   else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
>   mode = USB_DR_MODE_PERIPHERAL;
>   }
> @@ -305,14 +306,27 @@ static void dwc3_free_event_buffers(struct dwc3
> *dwc)
>   */
>  static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)  {
> - struct dwc3_event_buffer *evt;
> + int num;
> + int i;
> +
> + num = DWC3_NUM_INT(dwc->hwparams.hwparams1);
> + dwc->num_event_buffers = num;
> +
> + dwc->ev_buffs = devm_kzalloc(dwc->dev, sizeof(*dwc->ev_buffs) * num,
> + GFP_KERNEL);
> + if (!dwc->ev_buffs)
> + return -ENOMEM;
> 
> - evt = dwc3_alloc_one_event_buffer(dwc, length);
> - if (IS_ERR(evt)) {
> - dev_err(dwc->dev, "can't allocate event buffer\n");
> - return PTR_ERR(evt);
> + for (i = 0; i < num; i++) {
> + struct dwc3_event_buffer*evt;
> +
> + evt = dwc3_alloc_one_event_buffer(dwc, length);
> + if (IS_ERR(evt)) {
> + dev_err(dwc->dev, "can't allocate event buffer\n");
> + return PTR_ERR(evt);
> + }
> + dwc->ev_buffs[i] = evt;
>   }
> - dwc->ev_buf = evt;
> 
>   return 0;
>  }
> @@ -325,17 +339,25 @@ static int dwc3_alloc_event_buffers(struct dwc3
> *dwc, unsigned length)
>   */
>  static int dwc3_event_buffers_setup(struct dwc3 *dwc)  {
> - struct dwc3_event_buffer*evt;
> -
> - evt = dwc->ev_buf;
> - evt->lpos = 0;
> - dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0),
> - lower_32_bits(evt->dma));
> - dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(0),
> - upper_32_bits(evt->dma));
> - dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(0),
> - DWC3_GEVNTSIZ_SIZE(evt->length));
> - dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), 0);
> + struct dwc3_event_buffer*evt;
> + int n;
> +
> + for (n = 0; n < dwc->num_event_buffers; n++) {
> + evt = dwc->ev_buffs[n];
> + dev_dbg(dwc->dev, "Event buf %p dma %08llx length %d\n",
> + evt->buf, (unsigned long long) evt->dma,
> + evt->length);
> +
> + evt->lpos = 0;
> +
> + dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(n),
> + lower_32_bits(evt->dma));
> + dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(n),
> + upper_32_bits(evt->dma));
> + dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n),
> + DWC3_GEVNTSIZ_SIZE(evt->length));
> + dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(n), 0);
> + }
> 
>   return 0;
>  }
> @@ -1181,6 +1203,7 @@ static void dwc3_check_params(struct dwc3 *dwc)
> static int dwc3_probe(struct platform_device *pdev)  {
>   struct 

RE: [linux-devel] [PATCH 2/3] usb: dwc3 : Add support for USB snooping

[Leo Li]

> -Original Message-
> From: linux-devel-boun...@gforge.freescale.net [mailto:linux-devel-
> boun...@gforge.freescale.net] On Behalf Of yinbo@nxp.com
> Sent: Friday, August 11, 2017 5:00 AM
> To: linux-de...@gforge.freescale.net; Yinbo Zhu ; Rob
> Herring ; Mark Rutland ;
> Russell King ; Felipe Balbi 
> Cc: open list ; Laurent Pinchart
> ; Catalin Marinas
> ; open list ; open list
> ; Doug Ledford ;
> Stefano Stabellini ; Greg Kroah-Hartman
> ; Bart Van Assche
> ; moderated list  ker...@lists.infradead.org>
> Subject: [linux-devel] [PATCH 2/3] usb: dwc3 : Add support for USB snooping
> 
> From: Rajesh Bhagat 
> 
> Add support for USB3 snooping by asserting bits in register DWC3_GSBUSCFG0
> for data and descriptor

The description doesn't fully cover the change you made below, for example 
allocating multiple event buffers.  Please explain why you made such change.

> 
> Signed-off-by: Nikhil Badola 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: yinbo.zhu 
> ---
>  drivers/usb/dwc3/core.c | 71 ---
> --
>  drivers/usb/dwc3/core.h |  3 +++
>  drivers/usb/dwc3/host.c |  8 +-
>  3 files changed, 63 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index
> 02a534a..b51b0d8 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -90,6 +90,7 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
> 
>   if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
>   mode = USB_DR_MODE_HOST;
> +

Why are you adding a new line here?

>   else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
>   mode = USB_DR_MODE_PERIPHERAL;
>   }
> @@ -305,14 +306,27 @@ static void dwc3_free_event_buffers(struct dwc3
> *dwc)
>   */
>  static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)  {
> - struct dwc3_event_buffer *evt;
> + int num;
> + int i;
> +
> + num = DWC3_NUM_INT(dwc->hwparams.hwparams1);
> + dwc->num_event_buffers = num;
> +
> + dwc->ev_buffs = devm_kzalloc(dwc->dev, sizeof(*dwc->ev_buffs) * num,
> + GFP_KERNEL);
> + if (!dwc->ev_buffs)
> + return -ENOMEM;
> 
> - evt = dwc3_alloc_one_event_buffer(dwc, length);
> - if (IS_ERR(evt)) {
> - dev_err(dwc->dev, "can't allocate event buffer\n");
> - return PTR_ERR(evt);
> + for (i = 0; i < num; i++) {
> + struct dwc3_event_buffer*evt;
> +
> + evt = dwc3_alloc_one_event_buffer(dwc, length);
> + if (IS_ERR(evt)) {
> + dev_err(dwc->dev, "can't allocate event buffer\n");
> + return PTR_ERR(evt);
> + }
> + dwc->ev_buffs[i] = evt;
>   }
> - dwc->ev_buf = evt;
> 
>   return 0;
>  }
> @@ -325,17 +339,25 @@ static int dwc3_alloc_event_buffers(struct dwc3
> *dwc, unsigned length)
>   */
>  static int dwc3_event_buffers_setup(struct dwc3 *dwc)  {
> - struct dwc3_event_buffer*evt;
> -
> - evt = dwc->ev_buf;
> - evt->lpos = 0;
> - dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0),
> - lower_32_bits(evt->dma));
> - dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(0),
> - upper_32_bits(evt->dma));
> - dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(0),
> - DWC3_GEVNTSIZ_SIZE(evt->length));
> - dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), 0);
> + struct dwc3_event_buffer*evt;
> + int n;
> +
> + for (n = 0; n < dwc->num_event_buffers; n++) {
> + evt = dwc->ev_buffs[n];
> + dev_dbg(dwc->dev, "Event buf %p dma %08llx length %d\n",
> + evt->buf, (unsigned long long) evt->dma,
> + evt->length);
> +
> + evt->lpos = 0;
> +
> + dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(n),
> + lower_32_bits(evt->dma));
> + dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(n),
> + upper_32_bits(evt->dma));
> + dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n),
> + DWC3_GEVNTSIZ_SIZE(evt->length));
> + dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(n), 0);
> + }
> 
>   return 0;
>  }
> @@ -1181,6 +1203,7 @@ static void dwc3_check_params(struct dwc3 *dwc)
> static int dwc3_probe(struct platform_device *pdev)  {
>   struct device   *dev = >dev;
> + struct device_node  *node = dev->of_node;
>   struct resource *res;
>   struct dwc3 *dwc;
> 
> @@ -1188,7 +1211,6 @@ static int dwc3_probe(struct platform_device *pdev)
> 
>   void __iomem*regs;
> 
> - struct device_node  *node = dev->of_node;
>   dwc = devm_kzalloc(dev, sizeof(*dwc), GFP_KERNEL);
>   if (!dwc)
>   return -ENOMEM;
> @@ -1260,6 

RE: [PATCH] usb: gadget: fsl_qe_udc: constify qe_ep0_desc

[Leo Li]

> -Original Message-
> From: Julia Lawall [mailto:julia.law...@lip6.fr]
> Sent: Wednesday, August 02, 2017 10:29 AM
> To: Leo Li <leoyang...@nxp.com>
> Cc: kernel-janit...@vger.kernel.org; Felipe Balbi <ba...@kernel.org>; Greg
> Kroah-Hartman <gre...@linuxfoundation.org>; linux-...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Bhumika Goyal
> <bhumi...@gmail.com>
> Subject: [PATCH] usb: gadget: fsl_qe_udc: constify qe_ep0_desc
> 
> qe_ep0_desc is only passed as the second argument to qe_ep_init, which is
> const, so qe_ep0_desc can be const too.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall <julia.law...@lip6.fr>

Acked-by: Li Yang <leoyang...@nxp.com>

> 
> ---
> I got a lot of warnings when compiling this file, but none seemed to be 
> related
> to the change.
> 
>  drivers/usb/gadget/udc/fsl_qe_udc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
> b/drivers/usb/gadget/udc/fsl_qe_udc.c
> index 303328ce..a3e72d6 100644
> --- a/drivers/usb/gadget/udc/fsl_qe_udc.c
> +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
> @@ -62,7 +62,7 @@
>   "ep3",
>  };
> 
> -static struct usb_endpoint_descriptor qe_ep0_desc = {
> +static const struct usb_endpoint_descriptor qe_ep0_desc = {
>   .bLength =  USB_DT_ENDPOINT_SIZE,
>   .bDescriptorType =  USB_DT_ENDPOINT,
> 

RE: [PATCH] usb: gadget: fsl_qe_udc: constify qe_ep0_desc

[Leo Li]

> -Original Message-
> From: Julia Lawall [mailto:julia.law...@lip6.fr]
> Sent: Wednesday, August 02, 2017 10:29 AM
> To: Leo Li 
> Cc: kernel-janit...@vger.kernel.org; Felipe Balbi ; Greg
> Kroah-Hartman ; linux-...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Bhumika Goyal
> 
> Subject: [PATCH] usb: gadget: fsl_qe_udc: constify qe_ep0_desc
> 
> qe_ep0_desc is only passed as the second argument to qe_ep_init, which is
> const, so qe_ep0_desc can be const too.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Acked-by: Li Yang 

> 
> ---
> I got a lot of warnings when compiling this file, but none seemed to be 
> related
> to the change.
> 
>  drivers/usb/gadget/udc/fsl_qe_udc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
> b/drivers/usb/gadget/udc/fsl_qe_udc.c
> index 303328ce..a3e72d6 100644
> --- a/drivers/usb/gadget/udc/fsl_qe_udc.c
> +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
> @@ -62,7 +62,7 @@
>   "ep3",
>  };
> 
> -static struct usb_endpoint_descriptor qe_ep0_desc = {
> +static const struct usb_endpoint_descriptor qe_ep0_desc = {
>   .bLength =  USB_DT_ENDPOINT_SIZE,
>   .bDescriptorType =  USB_DT_ENDPOINT,
> 

RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.

[Leo Li]

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of David Laight
> Sent: Monday, June 26, 2017 10:55 AM
> To: 'Karim Eshapa' ; o...@buserror.net
> Cc: Roy Pledge ; linux-kernel@vger.kernel.org;
> Claudiu Manoil ; colin.k...@canonical.com;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.
> 
> From: Karim Eshapa
> > Sent: 25 June 2017 16:14
> > Use msleep() instead of stucking with
> > long delay will be more efficient.
> ...
> > --- a/drivers/soc/fsl/qbman/qman.c
> > +++ b/drivers/soc/fsl/qbman/qman.c
> > @@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
> >  * entries well before the ring has been fully consumed, so
> >  * we're being *really* paranoid here.
> >  */
> > -   u64 now, then = jiffies;
> > -
> > -   do {
> > -   now = jiffies;
> > -   } while ((then + 1) > now);
> > +   msleep(1);
> ...
> How is that in any way equivalent?
> If HZ is 1000 the old code loops for 10 seconds.
> If HZ is 250 (common for some distros) it loops for 40 seconds.
> 
> Clearly both are horrid, but it isn't at all clear that a 1ms sleep is 
> performing
> the same job.
> 
> My guess is that this code is never called, and broken if actually called.

It was indeed broken.  The intent was to wait for 1 cycles but mistakenly 
coded as 1 jiffies.  I think we choose 1ms as it is not too long and almost 
guarantees the 1 cycles delay.

Regards,
Leo

RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.

[Leo Li]

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of David Laight
> Sent: Monday, June 26, 2017 10:55 AM
> To: 'Karim Eshapa' ; o...@buserror.net
> Cc: Roy Pledge ; linux-kernel@vger.kernel.org;
> Claudiu Manoil ; colin.k...@canonical.com;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.
> 
> From: Karim Eshapa
> > Sent: 25 June 2017 16:14
> > Use msleep() instead of stucking with
> > long delay will be more efficient.
> ...
> > --- a/drivers/soc/fsl/qbman/qman.c
> > +++ b/drivers/soc/fsl/qbman/qman.c
> > @@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
> >  * entries well before the ring has been fully consumed, so
> >  * we're being *really* paranoid here.
> >  */
> > -   u64 now, then = jiffies;
> > -
> > -   do {
> > -   now = jiffies;
> > -   } while ((then + 1) > now);
> > +   msleep(1);
> ...
> How is that in any way equivalent?
> If HZ is 1000 the old code loops for 10 seconds.
> If HZ is 250 (common for some distros) it loops for 40 seconds.
> 
> Clearly both are horrid, but it isn't at all clear that a 1ms sleep is 
> performing
> the same job.
> 
> My guess is that this code is never called, and broken if actually called.

It was indeed broken.  The intent was to wait for 1 cycles but mistakenly 
coded as 1 jiffies.  I think we choose 1ms as it is not too long and almost 
guarantees the 1 cycles delay.

Regards,
Leo

RE: [v3] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

[Leo Li]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Saturday, June 24, 2017 9:47 PM
> To: Karim Eshapa <karim.esh...@gmail.com>
> Cc: Roy Pledge <roy.ple...@nxp.com>; linux-kernel@vger.kernel.org;
> Claudiu Manoil <claudiu.man...@nxp.com>; colin.k...@canonical.com;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; Leo Li
> <leoyang...@nxp.com>
> Subject: Re: [v3] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck
> hacking jiffies.
> 
> On Fri, May 05, 2017 at 07:45:18AM +0200, Karim Eshapa wrote:
> > Use msleep() instead of stucking with
> > long delay will be more efficient.
> >
> > Signed-off-by: Karim Eshapa <karim.esh...@gmail.com>
> > ---
> >  drivers/soc/fsl/qbman/qman.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> Acked-by: Scott Wood <o...@buserror.net>
> 
> (though the subject line should be "soc/qman: ...")
> 
> Leo, are you going to send this patch (and other qman patches) via arm-soc?

Yes.  I can take it through the pull request for soc/fsl via arm-soc.  As 
mentioned in the feedback from David in another email, probably we should 
update the comment and commit message to mention how 1 cycles becomes 1ms.

Regards,
Leo

RE: [v3] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

[Leo Li]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Saturday, June 24, 2017 9:47 PM
> To: Karim Eshapa 
> Cc: Roy Pledge ; linux-kernel@vger.kernel.org;
> Claudiu Manoil ; colin.k...@canonical.com;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; Leo Li
> 
> Subject: Re: [v3] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck
> hacking jiffies.
> 
> On Fri, May 05, 2017 at 07:45:18AM +0200, Karim Eshapa wrote:
> > Use msleep() instead of stucking with
> > long delay will be more efficient.
> >
> > Signed-off-by: Karim Eshapa 
> > ---
> >  drivers/soc/fsl/qbman/qman.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> Acked-by: Scott Wood 
> 
> (though the subject line should be "soc/qman: ...")
> 
> Leo, are you going to send this patch (and other qman patches) via arm-soc?

Yes.  I can take it through the pull request for soc/fsl via arm-soc.  As 
mentioned in the feedback from David in another email, probably we should 
update the comment and commit message to mention how 1 cycles becomes 1ms.

Regards,
Leo

RE: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI

[Leo Li]

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Wednesday, October 26, 2016 5:31 AM
> To: M.H. Lian <minghuan.l...@nxp.com>
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Marc Zyngier <marc.zyng...@arm.com>; Stuart
> Yoder <stuart.yo...@nxp.com>; Leo Li <leoyang...@nxp.com>; Scott Wood
> <scott.w...@nxp.com>; Shawn Guo <shawn...@kernel.org>; Mingkai Hu
> <mingkai...@nxp.com>
> Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
> 
> On Tue, Oct 25, 2016 at 08:35:40PM +0800, Minghuan Lian wrote:
> > 1. The different version of a SoC may have different MSI
> > implementation. But compatible "fsl,-msi" can not describe
> > the SoC version.
> 
> Surely, "fsl,--msi" can describe this?
> 
> If the hardware differs, it needs a new compatible string.
> 
> If there's some configuration value that varies across revisions (e.g.
> number of slots), you can add a proeprty to describe that explciitly.
> 
> > The MSI driver will use SoC match interface to get SoC type and
> > version instead of compatible string. So all MSI node can use the
> > common compatible "fsl,ls-scfg-msi" and the original compatible is
> > unnecessary.
> >
> > 2. Layerscape SoCs may have one or several MSI controllers.
> > In order to increase MSI interrupt number of a PCIe, the patch moves
> > all MSI node into the parent node "msi-controller". So a PCIe can
> > request MSI from all the MSI controllers.
> 
> This is not necessary, and does not represent a real block of hardware.
> So NAK for this approach.
> 
> The msi-parent property can contain a list of MSI controllers. See the 
> examples
> in Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> Likewise, the msi-map property can map to a number of MSI controllers.
> 
> If the core code can only consider one at a time, then that's an issue to be
> addressed in core code, not one to be bodged around in bindings.
> 
> >
> > Signed-off-by: Minghuan Lian <minghuan.l...@nxp.com>
> > ---
> >  .../interrupt-controller/fsl,ls-scfg-msi.txt   | 57 
> > +++---
> >  1 file changed, 49 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > index 9e38949..29f95fd 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-sc
> > +++ fg-msi.txt
> > @@ -1,18 +1,28 @@
> >  * Freescale Layerscape SCFG PCIe MSI controller
> >
> > +Layerscape SoCs may have one or multiple MSI controllers.
> > +Each MSI controller must be showed as a child node.
> > +
> >  Required properties:
> >
> > -- compatible: should be "fsl,-msi" to identify
> > - Layerscape PCIe MSI controller block such as:
> > -  "fsl,1s1021a-msi"
> > -  "fsl,1s1043a-msi"
> > +- compatible: should be "fsl,ls-scfg-msi"
> 
> This breaks old DTBs, and throws away information which you describe above as
> valuable. So another NAK for that.

I agree with you that we should maintain the backward compatibility.  But on 
the other hand, I just found that there is a silly typo in the original binding 
that "ls" is wrongly spelled as "1s" and they look too close to be noticed in 
previous patch reviews.  :(  The driver and all the DTSes used the binding with 
the typo which covered up the problem.  So even if we want to keep the 
"fsl,-msi" binding, we probably want to fix the typo, right?  And 
that breaks the backward compatibility too.

Regards,
Leo

RE: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI

[Leo Li]

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Wednesday, October 26, 2016 5:31 AM
> To: M.H. Lian 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Marc Zyngier ; Stuart
> Yoder ; Leo Li ; Scott Wood
> ; Shawn Guo ; Mingkai Hu
> 
> Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
> 
> On Tue, Oct 25, 2016 at 08:35:40PM +0800, Minghuan Lian wrote:
> > 1. The different version of a SoC may have different MSI
> > implementation. But compatible "fsl,-msi" can not describe
> > the SoC version.
> 
> Surely, "fsl,--msi" can describe this?
> 
> If the hardware differs, it needs a new compatible string.
> 
> If there's some configuration value that varies across revisions (e.g.
> number of slots), you can add a proeprty to describe that explciitly.
> 
> > The MSI driver will use SoC match interface to get SoC type and
> > version instead of compatible string. So all MSI node can use the
> > common compatible "fsl,ls-scfg-msi" and the original compatible is
> > unnecessary.
> >
> > 2. Layerscape SoCs may have one or several MSI controllers.
> > In order to increase MSI interrupt number of a PCIe, the patch moves
> > all MSI node into the parent node "msi-controller". So a PCIe can
> > request MSI from all the MSI controllers.
> 
> This is not necessary, and does not represent a real block of hardware.
> So NAK for this approach.
> 
> The msi-parent property can contain a list of MSI controllers. See the 
> examples
> in Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> Likewise, the msi-map property can map to a number of MSI controllers.
> 
> If the core code can only consider one at a time, then that's an issue to be
> addressed in core code, not one to be bodged around in bindings.
> 
> >
> > Signed-off-by: Minghuan Lian 
> > ---
> >  .../interrupt-controller/fsl,ls-scfg-msi.txt   | 57 
> > +++---
> >  1 file changed, 49 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > index 9e38949..29f95fd 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-sc
> > +++ fg-msi.txt
> > @@ -1,18 +1,28 @@
> >  * Freescale Layerscape SCFG PCIe MSI controller
> >
> > +Layerscape SoCs may have one or multiple MSI controllers.
> > +Each MSI controller must be showed as a child node.
> > +
> >  Required properties:
> >
> > -- compatible: should be "fsl,-msi" to identify
> > - Layerscape PCIe MSI controller block such as:
> > -  "fsl,1s1021a-msi"
> > -  "fsl,1s1043a-msi"
> > +- compatible: should be "fsl,ls-scfg-msi"
> 
> This breaks old DTBs, and throws away information which you describe above as
> valuable. So another NAK for that.

I agree with you that we should maintain the backward compatibility.  But on 
the other hand, I just found that there is a silly typo in the original binding 
that "ls" is wrongly spelled as "1s" and they look too close to be noticed in 
previous patch reviews.  :(  The driver and all the DTSes used the binding with 
the typo which covered up the problem.  So even if we want to keep the 
"fsl,-msi" binding, we probably want to fix the typo, right?  And 
that breaks the backward compatibility too.

Regards,
Leo

RE: [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer

[Leo Li]

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Friday, October 21, 2016 10:37 AM
> To: Leo Li <leoyang...@nxp.com>
> Cc: Bjorn Helgaas <bhelg...@google.com>; Minghuan Lian
> <minghuan.l...@freescale.com>; Mingkai Hu <mingkai...@freescale.com>;
> Roy Zang <tie-fei.z...@freescale.com>; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Stuart Yoder
> <stuart.yo...@nxp.com>
> Subject: Re: [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL 
> pointer
> 
> On Mon, Oct 17, 2016 at 04:44:06PM -0500, Li Yang wrote:
> > Commit fefe6733e added reference to the pcie->drvdata before it is
> > initialized which causes a kernel panic.  Fix the problem by
> > initializing the pcie->drvdata earlier before it is used.
> >
> > Reported-by: Stuart Yoder <stuart.yo...@nxp.com>
> > Signed-off-by: Li Yang <leoyang...@nxp.com>
> 
> I applied Marc Zyngier's identical patch to for-linus for v4.9.  I don't know 
> which
> was posted first, but I saw Marc's first.  Sorry I didn't at least credit you 
> when I
> applied it.

It's ok.  Seems Marc sent the patch earlier and I didn't notice his patch.  
There is no difference as long as the problem is addressed.  :)

Regards,
Leo