Re: [PATCH] pata_platform struct resource signness fix

[Leo Li]

On Thu, Sep 25, 2008 at 4:36 PM, Wang Jian [EMAIL PROTECTED] wrote:
 Hi,

 This patch is to pata_platform.c but at this time, it's powerpc specific
 because it can only be triggerred using openfirmware, so I post the patch
 here. The patch is against 2.6.26-rc8.

Powerpc isn't the only arch to use openfirmware.  Anyway, you have to
cc [EMAIL PROTECTED] if you want the patch to be merged.

- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] powerpc/pm: add api to get suspend state which is STANDBY or MEM

[Leo Li]

On Sat, Apr 26, 2014 at 5:45 AM, Scott Wood scottw...@freescale.com wrote:
 On Thu, 2014-04-24 at 14:11 +0800, Dongsheng Wang wrote:
 From: Wang Dongsheng dongsheng.w...@freescale.com

 Add set_pm_suspend_state  pm_suspend_state functions to set/get
 suspend state. When system going to sleep or deep sleep, devices
 can get the system suspend state(STANDBY/MEM) through pm_suspend_state
 function and to handle different situations.

 Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
 ---
 *v2*
 Move pm api from fsl platform to powerpc general framework.

 What is powerpc-specific about this?

Generally I agree with you.  But I had the discussion about this topic
a while ago with the PM maintainer.  He suggestion to go with the
platform way.

https://lkml.org/lkml/2013/8/16/505

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

Re: [PATCH 1/1] booke/watchdog: refine and clean up the codes

[Leo Li]

On Thu, May 8, 2014 at 10:04 AM,  yuantian.t...@freescale.com wrote:
 From: Tang Yuantian yuantian.t...@freescale.com

 Basically, this patch does the following:
 1. Move the codes of parsing boot parameters from setup-common.c
to driver. In this way, code reader can know directly that
there are boot parameters that can change the timeout.
 2. Make boot parameter 'booke_wdt_period' effective.
currently, when driver is loaded, default timeout is always
being used in stead of booke_wdt_period.
 3. Wrap up the watchdog timeout in device struct and clean up
unnecessary codes.

 Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
 Acked-by: Scott Wood scottw...@freescale.com

Reviewed-by: Li Yang le...@freescale.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Driver(s) for Synopsys' DesignWare USB OTG

[Leo Li]

On Sun, Jan 8, 2012 at 8:56 PM, Nikolai Zhubr n-a-zh...@yandex.ru wrote:
 Hello Piter,


 08.01.2012 7:12, you wrote:

 2012/1/8 Nikolai Zhubrn-a-zh...@yandex.ru:

 Hello developers,

 I'm trying to find/combine/fix a driver for Synopsys' DesignWare USB
 controller. This thing is USB 2.0 host/slave/otg capable and is used in
 various SoCs including Amlogic 8726M, Ralink RT305x, and probably more.

 [...trim...]


 Please see:
 http://marc.info/?l=linux-usbm=129906859817430w=2

 Ah, thanks. So sadly uncoordinated work in this area is quite common.
 However, in case of Synopsys the situation is even more disappointing
 because initially it _was_ a single driver! What probably lacked was some
 shared repository and proper communication between developers to stay in
 sync. Maybe there were also licensing issues at some point, though currently
 file headers contain rather reasonable (imho) permissive license from
 Synopsys.

I think the challenge of cooperation in situation like this is that
most companies don't like to advertise the source of the licensed IP
block.  Even the owner of the IP block doesn't list all users of the
block(maybe business requirement). It was really hard to find out if
the same IP has been used by anyone else.  Also the owner of this USB
IP block has been changed for several times(ARC, TDI, ChipIdea, and
Synopsys) which made it even more difficult to tell.



 I am not sure we can combine all Synopsys USB drivers to single file, but
 we


 Synopsys driver which I examine consists of 16 files (each of 2 versions),
 200k lines total. I've already perpared some few smaller files for version
 merging. So probably it is doable, but quite a lot of work, therefore I
 wouldn't like it to be wasted.

I didn't examine the Synopsys driver myself.  But if it is so complex
as you described, it might be better to start with the in-tree drivers
IMO.

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

Re: [PATCH][v3] mtd/ifc: Add support for IFC controller version 2.0

[Leo Li]

On Thu, Apr 7, 2016 at 7:45 PM, Boris Brezillon
<boris.brezil...@free-electrons.com> wrote:
> On Wed, 6 Apr 2016 18:53:39 +0000
> Yang-Leo Li <leoyang...@nxp.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Brian Norris [mailto:computersforpe...@gmail.com]
>> > Sent: Wednesday, April 06, 2016 12:53 PM
>> > To: Li Yang <le...@freescale.com>
>> > Cc: Scott Wood <o...@buserror.net>; Raghav Dogra <raghav.do...@nxp.com>;
>> > linux-...@lists.infradead.org; linuxppc-dev 
>> > <linuxppc-dev@lists.ozlabs.org>;
>> > Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Raghav Dogra
>> > <rag...@freescale.com>; Jaiprakash Singh <b44...@freescale.com>; Boris
>> > Brezillon <boris.brezil...@free-electrons.com>
>> > Subject: Re: [PATCH][v3] mtd/ifc: Add support for IFC controller version 
>> > 2.0
>> >
>> > Hi,
>> >
>> > On Wed, Mar 30, 2016 at 03:43:40PM -0500, Li Yang wrote:
>> > > Hi Brian,
>> > >
>> > > Could you help to review and pull in this patch and the Kconfig update
>> > > after this patch(https://patchwork.ozlabs.org/patch/557389/)?  It
>> >
>> > It's probably best for Boris to apply this now.
>>
>> Thanks Brian.  I see Boris is taking over the maintenance of NAND recently, 
>> we will follow up with him.
>>
>> Hi Boris,
>>
>> Can you consider to pull in this patch and then Kconfig patch 
>> (https://patchwork.ozlabs.org/patch/557389/)?
>
> Applied.
>
> Thanks,
>
> Boris

Hi Boris,

It seems that the patch at https://patchwork.ozlabs.org/patch/557389/
mentioned above was not in tree for 4.7.  Can you review and apply
that patch too?

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

Re: [PATCH][v3] mtd/ifc: Add support for IFC controller version 2.0

[Leo Li]

On Wed, May 25, 2016 at 3:34 PM, Boris Brezillon
<boris.brezil...@free-electrons.com> wrote:
> On Wed, 25 May 2016 14:18:43 -0500
> Leo Li <pku@gmail.com> wrote:
>
>> On Thu, Apr 7, 2016 at 7:45 PM, Boris Brezillon
>> <boris.brezil...@free-electrons.com> wrote:
>> > On Wed, 6 Apr 2016 18:53:39 +
>> > Yang-Leo Li <leoyang...@nxp.com> wrote:
>> >
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Brian Norris [mailto:computersforpe...@gmail.com]
>> >> > Sent: Wednesday, April 06, 2016 12:53 PM
>> >> > To: Li Yang <le...@freescale.com>
>> >> > Cc: Scott Wood <o...@buserror.net>; Raghav Dogra <raghav.do...@nxp.com>;
>> >> > linux-...@lists.infradead.org; linuxppc-dev 
>> >> > <linuxppc-dev@lists.ozlabs.org>;
>> >> > Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Raghav Dogra
>> >> > <rag...@freescale.com>; Jaiprakash Singh <b44...@freescale.com>; Boris
>> >> > Brezillon <boris.brezil...@free-electrons.com>
>> >> > Subject: Re: [PATCH][v3] mtd/ifc: Add support for IFC controller 
>> >> > version 2.0
>> >> >
>> >> > Hi,
>> >> >
>> >> > On Wed, Mar 30, 2016 at 03:43:40PM -0500, Li Yang wrote:
>> >> > > Hi Brian,
>> >> > >
>> >> > > Could you help to review and pull in this patch and the Kconfig update
>> >> > > after this patch(https://patchwork.ozlabs.org/patch/557389/)?  It
>> >> >
>> >> > It's probably best for Boris to apply this now.
>> >>
>> >> Thanks Brian.  I see Boris is taking over the maintenance of NAND 
>> >> recently, we will follow up with him.
>> >>
>> >> Hi Boris,
>> >>
>> >> Can you consider to pull in this patch and then Kconfig patch 
>> >> (https://patchwork.ozlabs.org/patch/557389/)?
>> >
>> > Applied.
>> >
>> > Thanks,
>> >
>> > Boris
>>
>> Hi Boris,
>>
>> It seems that the patch at https://patchwork.ozlabs.org/patch/557389/
>> mentioned above was not in tree for 4.7.  Can you review and apply
>> that patch too?
>
> I see it in the PR Brian sent 2 days ago [1], so it should appear in
> Linus tree soon.
>
> Regards,
>
> Boris
>
> [1]https://lkml.org/lkml/2016/5/24/9


The pull request does have patch "mtd/ifc: Add support for IFC
controller version 2.0", but it doesn't have another patch
"driver/memory: Update dependency of IFC for
Layerscape"(https://patchwork.ozlabs.org/patch/557389/) needed to make
the driver selectable on new hardware.

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

Re: [PATCH][v3] mtd/ifc: Add support for IFC controller version 2.0

[Leo Li]

On Fri, May 27, 2016 at 4:12 PM, Brian Norris
<computersforpe...@gmail.com> wrote:
> Hi Leo,
>
> On Fri, May 27, 2016 at 10:44:01PM +0200, Boris Brezillon wrote:
>> On Fri, 27 May 2016 15:15:00 -0500
>> Leo Li <pku@gmail.com> wrote:
>> > On Wed, May 25, 2016 at 3:34 PM, Boris Brezillon
>> > <boris.brezil...@free-electrons.com> wrote:
>> > > On Wed, 25 May 2016 14:18:43 -0500
>> > > Leo Li <pku@gmail.com> wrote:
>> > >> It seems that the patch at https://patchwork.ozlabs.org/patch/557389/
>> > >> mentioned above was not in tree for 4.7.  Can you review and apply
>> > >> that patch too?
>> > >
>> > > I see it in the PR Brian sent 2 days ago [1], so it should appear in
>> > > Linus tree soon.
>> > >
>> > > Regards,
>> > >
>> > > Boris
>> > >
>> > > [1]https://lkml.org/lkml/2016/5/24/9
>> >
>> >
>> > The pull request does have patch "mtd/ifc: Add support for IFC
>> > controller version 2.0", but it doesn't have another patch
>> > "driver/memory: Update dependency of IFC for
>> > Layerscape"(https://patchwork.ozlabs.org/patch/557389/) needed to make
>> > the driver selectable on new hardware.
>
> Your patches seem to have broken threading. Or at least, in my mailbox,
> I have that patch, but I can't easily find [PATCH 1/3] or [PATCH 3/3].
> Please fix your threading next time, to help ensure things get handled
> together.
>
> (It also helps when you reply to the patch you're asking about, and not
> to a different patch.)
>
>> Sorry, I overlooked that part in your different emails (even though you
>> clearly stated that you needed both patches).
>>
>> For my defense, I haven't followed the patch series from the beginning,
>> and only took the patch because Brian suggested to do so (and the
>> changes seemed ok).
>> It would have been clearer if the different patches were part of the
>> same series.
>
> +1 to the last sentence.
>
>> Anyway, Brian, can you take it into your tree and make it appear in
>> -rc1 (or earlier if it's still possible)?
>
> Not sure how I could get it any "earlier"? It's not making -rc1 at this
> point.
>
>> BTW, in the patch description you say you're only modifying a Kconfig
>> dependency, but you're actually doing more than that: you're removing
>> an asm header inclusion and manually include several other headers
>> (which I guess were previously included by asm/prom.h).
>
> Please resend this patch with a more complete commit description; I'd
> like it to get actual review (and time in linux-next) before it gets
> merged, so at best, it'll wait a few -rc's. I also suspect the patch
> isn't optimal. I believe Scott has suggested [1] that we didn't need the
> FSL_SOC dependency on the LBC driver. I think IFC looks like a similar
> case?

Thanks Brian.

Raghav, Can you do that as soon as possible?

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

Re: [PATCH][v2] drivers/memory: Add deep sleep support for IFC

[Leo Li]

On Fri, Jan 8, 2016 at 5:18 AM, Raghav Dogra  wrote:
> Add support of suspend, resume function to support deep sleep.
> Also make sure of SRAM initialization  during resume.
>
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Raghav Dogra 
> ---
> Changes for v2: Copying only the correct registers while resume.
> Based on git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> branch "next"

The patch can not apply cleanly on 4.5-rc.  You probably need to re-spin it.

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

Re: [PATCH] qe_ic: fix a buffer overflow error and add check elsewhere

[Leo Li]

On Thu, Jan 21, 2016 at 9:06 AM, Zhao Qiang  wrote:
> 127 is the theoretical up boundary of QEIC number,
> in fact there only be 44 qe_ic_info now.
> add check to overflow for qe_ic_info
>
> Signed-off-by: Zhao Qiang 

Acked-by: Li Yang 

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

Re: [PATCH][v3] drivers/memory: Add deep sleep support for IFC

[Leo Li]

On Wed, Feb 17, 2016 at 8:40 AM, Raghav Dogra  wrote:
>
>
>> -Original Message-
>> From: Scott Wood [mailto:o...@buserror.net]
>> Sent: Tuesday, February 16, 2016 2:05 PM
>> To: Raghav Dogra ; linuxppc-dev@lists.ozlabs.org
>> Cc: Prabhakar Kushwaha 
>> Subject: Re: [PATCH][v3] drivers/memory: Add deep sleep support for IFC
>>
>> On Mon, 2016-02-15 at 11:44 +0530, Raghav Dogra wrote:
>> > Add support of suspend, resume function to support deep sleep.
>> > Also make sure of SRAM initialization  during resume.
>> >
>> > Signed-off-by: Prabhakar Kushwaha 
>> > Signed-off-by: Raghav Dogra 

Similar comment as last time, that we should involve the MTD guys.

>> > ---
>> > Changes for v3: Replace spin_event_timeout() with arch independent
>> > macro
>> >
>> > Based on
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> > branch "master"
>> >
>> >  drivers/memory/fsl_ifc.c | 165
>> > +++
>> >  include/linux/fsl_ifc.h  |   6 ++
>> >  2 files changed, 171 insertions(+)
>> >
>> > diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c index
>> > acd1460..fa028bd 100644
>> > --- a/drivers/memory/fsl_ifc.c
>> > +++ b/drivers/memory/fsl_ifc.c
>> > @@ -24,6 +24,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -35,6 +36,8 @@
>> >
>> >  struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
>> > EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
>> > +#define FSL_IFC_V1_3_0 0x0103
>> > +#define IFC_TIMEOUT_MSECS  10 /* 100ms */
>>
>> What does the "MSECS" mean in IFC_TIMEOUT_MSECS?  It's a unit without a
>> quantity.
>
> Yes, I agree. I will rename it to IFC_WAIT_ITR.
>
>>
>> >
>> >  /*
>> >   * convert_ifc_address - convert the base address @@ -309,6 +312,163
>> > @@ err:
>> > return ret;
>> >  }
>> >
>> > +#ifdef CONFIG_PM_SLEEP
>> > +/* save ifc registers */
>> > +static int fsl_ifc_suspend(struct device *dev) {
>> > +   struct fsl_ifc_ctrl *ctrl = dev_get_drvdata(dev);
>> > +   struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
>> > +   __be32 nand_evter_intr_en, cm_evter_intr_en, nor_evter_intr_en,
>> > +gpcm_evter_intr_en
>> > ;
>>
>> s/__be32/u32/ as they've already been converted to host endianness.
>>
>> Also please repeat the type on a new line rather than use continuation lines
>> to declare more variables (and don't indent continuation lines so far).
>>
>
> Okay, will take care of this in the next version.
>
>> > +
>> > +   ctrl->saved_regs = kzalloc(sizeof(struct fsl_ifc_regs),
>> > GFP_KERNEL);
>> > +   if (!ctrl->saved_regs)
>> > +   return -ENOMEM;
>>
>> Allocate memory at probe time, not here.
>>
>
> But, why allocate memory at the probe when it is not known at that time 
> whether
> deep sleep state would be required or not? Is that because we want to save 
> time
> while going to deep sleep?
>
>> > +   cm_evter_intr_en = ifc_in32(>cm_evter_intr_en);
>> > +   nand_evter_intr_en = ifc_in32(>ifc_nand.nand_evter_intr_en);
>> > +   nor_evter_intr_en = ifc_in32(>ifc_nor.nor_evter_intr_en);
>> > +   gpcm_evter_intr_en = ifc_in32(
>> >ifc_gpcm.gpcm_evter_intr_en);
>> > +
>> > +/* IFC interrupts disabled */
>> > +
>> > +   ifc_out32(0x0, >cm_evter_intr_en);
>>
>> Indent the comments the same as the code.
>>
>
> Okay.
>
>> > +   ifc_out32(0x0, >ifc_nand.nand_evter_intr_en);
>> > +   ifc_out32(0x0, >ifc_nor.nor_evter_intr_en);
>> > +   ifc_out32(0x0, >ifc_gpcm.gpcm_evter_intr_en);
>> > +
>> > +   memcpy_fromio(ctrl->saved_regs, ifc, sizeof(struct fsl_ifc_regs));
>> > +
>> > +/* save the interrupt values */
>> > +   ctrl->saved_regs->cm_evter_intr_en = cm_evter_intr_en;
>> > +   ctrl->saved_regs->ifc_nand.nand_evter_intr_en =
>> nand_evter_intr_en;
>> > +   ctrl->saved_regs->ifc_nor.nor_evter_intr_en = nor_evter_intr_en;
>> > +   ctrl->saved_regs->ifc_gpcm.gpcm_evter_intr_en =
>> gpcm_evter_intr_en;
>>
>> Why didn't you use the memcpy_fromio() to save these, and clear intr_en
>> later?
>>
>
> I used it whenever I did a write/read on iomem. In this case, both memories
> are non iomem.
>
>> That said, I still don't like this approach.  I'd rather see the nand driver 
>> save
>> the registers it cares about, and this driver wouldn't have to do much other
>> than quiesce the rest of the interrupts.
>>
>
> Okay, we will analyze the required changes and include them.
>
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +/* restore ifc registers */
>> > +static int fsl_ifc_resume(struct device *dev) {
>> > +   struct fsl_ifc_ctrl *ctrl = dev_get_drvdata(dev);
>> > +   struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
>> > +   struct fsl_ifc_regs *savd_regs = ctrl->saved_regs;
>> > +   uint32_t ver = 0, ncfgr, timeout, ifc_bank, i;
>>
>> s/savd/saved/
>>
>
> Okay.
>
>> > +
>> > +/*
>> > + * IFC interrupts disabled
>> > 

Re: [PATCH][v3] mtd/ifc: Add support for IFC controller version 2.0

[Leo Li]

On Wed, Feb 17, 2016 at 5:24 AM, Raghav Dogra  wrote:
> The new IFC controller version 2.0 has a different memory map page.
> Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 PAGE size is 64KB.
> This patch segregates the IFC global and runtime registers to appropriate
> PAGE sizes.
>
> Signed-off-by: Jaiprakash Singh 
> Signed-off-by: Raghav Dogra 
> Acked-by: Li Yang 
> Signed-off-by: Raghav Dogra 
> ---
> Changes for v3: not dependent on
> "drivers/memory: Add deep sleep support for IFC" patch
>
> Changes for v2: rebased to resolve conflicts
> Applicable to git://git.infradead.org/l2-mtd.git
>
> This patch is dependent on "drivers/memory: Add deep sleep support for IFC"
> https://patchwork.ozlabs.org/patch/582762/
> which is also applicable to git://git.infradead.org/l2-mtd.git

This patch seems to be in good shape, but the dependency is still
having quite some feedback to be addressed.  Depending on it will
greatly delay the time that this critical patch for LS2 to be merged.
Could you remove the dependency like Scott already suggested?

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

Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory

[Leo Li]

On Thu, Mar 17, 2016 at 12:57 PM, Rob Herring  wrote:
> On Thu, Mar 17, 2016 at 12:11 PM, Arnd Bergmann  wrote:
>> On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
>>> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
>>> > b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>>> > similarity index 91%
>>> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>>> > rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
>>> > index b71b203..07adca9 100644
>>> > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>>> > +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>>> > @@ -25,6 +25,9 @@ Recommended properties:
>>> >   - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
>>> > registers, for those SOCs that have a PAMU device.
>>> >
>>> > + - little-endian : Indicates that the global utilities block is little
>>> > +   endian. The default is big endian.
>>>
>>> The default is "the native endianness of the system".
>>
>> This may be what is currently documented, but not what we are doing
>> in practice, as there is no "native endianess" for either PowerPC or
>> ARM -- both allow running big-endian or little-endian kernels and the
>> device registers are fixed.
>
> Notice I said system, not architecture. The way the device registers
> are fixed is what I mean by native endianness.

I think sometimes it's also hard to define the native endianess of the
system too.  For whatever reason, we have hardware that having
big-endian registers on some on-chip devices but using little-endian
registers on other devices.  Even if all the devices on certain
hardware use registers of the same endianess, it is also hard for the
device driver to know what the native endianess really is.

>
> If the purpose of adding this property now is to support GUTS on the
> ARM SoCs, then I'd argue using this property is probably wrong. If the
> PPC systems are designed with BE device registers and ARM systems with
> LE, then this property is not needed.
>
>> I think the property here is fine.
>
> Unless you have studied the FSL ARM based SoCs, then there is not
> enough information here to tell.

Recent FSL ARM SoCs seems to have more weird endianess issue. :( The
same IP could have registers of different endianess on different ARM
SoCs.  That why we need to define the endianess explicitly in device
tree.

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

Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific driver

[Leo Li]

On Mon, Apr 25, 2016 at 10:12 PM, Yangbo Lu <yangbo...@nxp.com> wrote:
> Hi Scott and Leo,
>
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Scott Wood
>> Sent: Saturday, April 23, 2016 7:23 AM
>> To: Yangbo Lu; linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
>> linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org
>> Cc: ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma;
>> Scott Wood; Claudiu Manoil; Kumar Gala; Yang-Leo Li; Xiaobo Xie; Michael
>> Ellerman
>> Subject: Re: [v8, 6/7] MAINTAINERS: add entry for Freescale SoC specific
>> driver
>>
>> On Fri, 2016-04-22 at 14:27 +0800, Yangbo Lu wrote:
>> > Add maintainer entry for Freescale SoC specific driver including the
>> > QE library and the GUTS driver. Also add entry for GUTS driver and add
>> > maintainer for QE library.
>> >
>> > Signed-off-by: Yangbo Lu <yangbo...@nxp.com>
>> > ---
>> > Changes for v8:
>> > - Added this patch
>> > ---
>> >  MAINTAINERS | 16 +++-
>> >  1 file changed, 15 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..d20aeb6 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -4622,13 +4622,27 @@ F:  drivers/net/ethernet/freescale/fec_ptp.c
>> >  F: drivers/net/ethernet/freescale/fec.h
>> >  F: Documentation/devicetree/bindings/net/fsl-fec.txt
>> >
>> > +FREESCALE SOC SPECIFIC DRIVER
>>
>> FREESCALE SOC DRIVERS
>
> [Lu Yangbo-B47093] Ok, will change it to 'FREESCALE SOC DRIVERS'.
>
>>
>> > +M: Scott Wood <o...@buserror.net>
>>
>> Please CC me at this address, not the NXP address that you sent this to...
>
> [Lu Yangbo-B47093] Sorry for mistaking your email. Will send the one you said.
>
>>
>> > +L: linuxppc-dev@lists.ozlabs.org
>> > +S: Maintained
>> > +F: drivers/soc/fsl/
>> > +F: include/linux/fsl/
>>
>> This directory will contain drivers that work on PPC and ARM... I'm not
>> sure what to put here in terms of mailing lists (we could put both, but
>> people probably shouldn't spam both lists if only one arch is relevant to
>> the patch), and whom to make pull requests to.
>
> [Lu Yangbo-B47093] But sooner or later we need to do this for files in fsl/ 
> ...
> :)
>
> Hi Leo, do you have any idea?

I think it would be ok to put both linuxppc and linux-arm mailing
lists here.  Driver doesn't fall into any of the functional based
sub-systems would very likely be platform stuff.  And if patch author
has the knowledge that a patch only impacts one arch, he can remove
the other list to reduce the spam.

>
>
>>
>> > +FREESCALE GUTS DRIVER
>> > +M: Yangbo Lu <yangbo...@nxp.com>
>> > +L: linuxppc-dev@lists.ozlabs.org
>> > +S: Maintained
>> > +F: drivers/soc/fsl/guts.c
>>
>> What about the header?
>>
>> Does guts really need a separate maintainer from drivers/soc/fsl?
>
> [Lu Yangbo-B47093] I was hesitating to add the maintainer...
> And I was not so familiar with it. Let me leave it to the fsl/ directory and 
> remove this...
>
>>
>> -Scott
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev



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

Re: [PATCH][v3] drivers/memory: Add deep sleep support for IFC

[Leo Li]

Hi Raghav,

Are we planning to send a new version of this patch?  Btw, I see that
the current patch covers NOR/GPCM related registers, but the driver is
only built when IFC NAND is enabled right now.  Do we want to change
the Kconfig to make it not depending on NAND?

Regards,
Leo

On Wed, Feb 17, 2016 at 7:19 PM, Scott Wood  wrote:
> On Wed, 2016-02-17 at 14:40 +, Raghav Dogra wrote:
>>
>> > -Original Message-
>> > From: Scott Wood [mailto:o...@buserror.net]
>> > Sent: Tuesday, February 16, 2016 2:05 PM
>> > To: Raghav Dogra ; linuxppc-dev@lists.ozlabs.org
>> > Cc: Prabhakar Kushwaha 
>> > Subject: Re: [PATCH][v3] drivers/memory: Add deep sleep support for IFC
>> >
>> > On Mon, 2016-02-15 at 11:44 +0530, Raghav Dogra wrote:
>> > >
>> > > +
>> > > + ctrl->saved_regs = kzalloc(sizeof(struct fsl_ifc_regs),
>> > > GFP_KERNEL);
>> > > + if (!ctrl->saved_regs)
>> > > + return -ENOMEM;
>> >
>> > Allocate memory at probe time, not here.
>> >
>>
>> But, why allocate memory at the probe when it is not known at that time
>> whether
>> deep sleep state would be required or not? Is that because we want to save
>> time
>> while going to deep sleep?
>
> We also want to avoid potential failures here.  We can also keep the code
> simpler by embedding this into the ctrl struct itself, and not dynamically
> allocating it at all.
>
>> > >
>> > > + ifc_out32(0x0, >ifc_nand.nand_evter_intr_en);
>> > > + ifc_out32(0x0, >ifc_nor.nor_evter_intr_en);
>> > > + ifc_out32(0x0, >ifc_gpcm.gpcm_evter_intr_en);
>> > > +
>> > > + memcpy_fromio(ctrl->saved_regs, ifc, sizeof(struct
>> > > fsl_ifc_regs));
>> > > +
>> > > +/* save the interrupt values */
>> > > + ctrl->saved_regs->cm_evter_intr_en = cm_evter_intr_en;
>> > > + ctrl->saved_regs->ifc_nand.nand_evter_intr_en =
>> > nand_evter_intr_en;
>> > > + ctrl->saved_regs->ifc_nor.nor_evter_intr_en =
>> > > nor_evter_intr_en;
>> > > + ctrl->saved_regs->ifc_gpcm.gpcm_evter_intr_en =
>> > gpcm_evter_intr_en;
>> >
>> > Why didn't you use the memcpy_fromio() to save these, and clear intr_en
>> > later?
>> >
>>
>> I used it whenever I did a write/read on iomem. In this case, both memories
>> are non iomem.
>
> Huh?  >ifc_nand.nand_evter_intr_en and such are iomem.
>
>> > > +
>> > > +/*
>> > > + * IFC interrupts disabled
>> > > + */
>> > > + ifc_out32(0x0, >cm_evter_intr_en);
>> > > + ifc_out32(0x0, >ifc_nand.nand_evter_intr_en);
>> > > + ifc_out32(0x0, >ifc_nor.nor_evter_intr_en);
>> > > + ifc_out32(0x0, >ifc_gpcm.gpcm_evter_intr_en);
>> > > +
>> > > +
>> > > + if (ctrl->saved_regs) {
>> > > + for (ifc_bank = 0; ifc_bank < FSL_IFC_BANK_COUNT;
>> > > ifc_bank++) {
>> > > + ifc_out32(savd_regs
>> > > ->cspr_cs[ifc_bank].cspr_ext,
>> > > + 
>> > > ->cspr_cs[ifc_bank].cspr_ext);
>> > > + ifc_out32(savd_regs->cspr_cs[ifc_bank].cspr,
>> > > + >cspr_cs[ifc_bank].cspr);
>> > > + ifc_out32(savd_regs->amask_cs[ifc_bank].amask,
>> > > + 
>> > > ->amask_cs[ifc_bank].amask);
>> > > + ifc_out32(savd_regs
>> > > ->csor_cs[ifc_bank].csor_ext,
>> > > + 
>> > > ->csor_cs[ifc_bank].csor_ext);
>> > > + ifc_out32(savd_regs->csor_cs[ifc_bank].csor,
>> > > + >csor_cs[ifc_bank].csor);
>> >
>> > Align continuation lines the way patchwork suggests ("" aligned with
>> > "savd").
>>
>> Okay, I will take care of this in the next patch.
>>
>> >
>> > Does resume from deep sleep go via U-Boot (which would initialize these
>> > registers) on these chips?
>>
>> Yes, deep sleep resume goes via u-boot and these registers should be
>> initialized
>> By u-boot.
>
> So then we don't need to save/restore them.
>
>>
>
>> > > +
>> > > +/*
>> > > +* IFC controller NOR machine registers */
>> > > + ifc_out32(savd_regs->ifc_nor.nor_evter_en,
>> > > + >ifc_nor.nor_evter_en);
>> > > + ifc_out32(savd_regs->ifc_nor.norcr, 
>> > > ->ifc_nor.norcr);
>> >
>> > What uses these?
>> >
>>
>> These registers are not used as such, but we would like to retain their
>> value as they
>> can be of help in case of error conditions.
>
> I don't follow.  Neither of those registers reports errors, and the registers
> that *do* report errors are generally w1c and thus you can't save/restore
> them.
>
>> > >
>> > > +
>> > > + ver = ifc_in32(>regs->ifc_rev);
>> > > + ncfgr = ifc_in32(>ifc_nand.ncfgr);
>> > > + if (ver >= FSL_IFC_V1_3_0) {
>> > > +
>> > > + ifc_out32(ncfgr | IFC_NAND_SRAM_INIT_EN,
>> > > + >ifc_nand.ncfgr);
>> > > + /* wait for  SRAM_INIT bit to be clear or timeout */
>> > > + timeout = IFC_TIMEOUT_MSECS;
>> > > + while ((ifc_in32(>ifc_nand.ncfgr) &
>> > > + 

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Leo Li]

On Tue, Jul 19, 2016 at 10:02 PM, Yuantian Tang <yuantian.t...@nxp.com> wrote:
>
> PING.
>
> Regards,
> Yuantian
>
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Saturday, July 09, 2016 5:07 AM
> > To: Michael Turquette <mturque...@baylibre.com>; Russell King
> > <li...@armlinux.org.uk>; Stephen Boyd <sb...@codeaurora.org>; Viresh
> > Kumar <viresh.ku...@linaro.org>; Rafael J. Wysocki <r...@rjwysocki.net>
> > Cc: linux-...@vger.kernel.org; linux...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org; Yuantian Tang <yuantian.t...@nxp.com>; Yang-Leo Li
> > <leoyang...@nxp.com>; Xiaofeng Ren <xiaofeng@nxp.com>
> > Subject: Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock
> > implementation details
> >
> > On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> > > Quoting Scott Wood (2016-07-06 21:13:23)
> > > >
> > > > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > > > >
> > > > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > > > >
> > > > > >
> > > > > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > > > > +static struct clk *cpu_to_clk(int cpu)
> > > > > >  {
> > > > > > -   struct device_node *np, *clk_np;
> > > > > > +   struct device_node *np;
> > > > > > +   struct clk *clk;
> > > > > >
> > > > > > if (!cpu_present(cpu))
> > > > > > return NULL;
> > > > > > @@ -112,37 +80,28 @@ static struct device_node
> > > > > > *cpu_to_clk_node(int
> > > > > > cpu)
> > > > > > if (!np)
> > > > > > return NULL;
> > > > > >
> > > > > > -   clk_np = of_parse_phandle(np, "clocks", 0);
> > > > > > -   if (!clk_np)
> > > > > > -   return NULL;
> > > > > > -
> > > > > > +   clk = of_clk_get(np, 0);
> > > > > Why not use devm_clk_get here?
> > > > devm_clk_get() is a wrapper around clk_get() which is not the same
> > > > as of_clk_get().  What device would you pass to devm_clk_get(), and
> > > > what name would you pass?
> > > I'm fuzzy on whether or not you get a struct device from a cpufreq
> > > driver. If so, then that would be the one to use. I would hope that
> > > cpufreq drivers model cpus as devices, but I'm really not sure without
> > > looking into the code.
> >
> > It's not the cpufreq code that provides it, but get_cpu_device() could be
> > used.
> >
> > Do you have any comments on the first patch of this set?


Any action on this patch?  This patch is still a dependency for
cpufreq to work on all QorIQ platforms.

Regards,
Leo

Re: [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings

[Leo Li]

On Wed, Jun 8, 2016 at 2:52 PM, Rob Herring  wrote:
> On Tue, Jun 07, 2016 at 11:27:34AM +0800, Jia Hongtao wrote:
>> For different types of SoC the sensor id and endianness may vary.
>> "#thermal-sensor-cells" is used to provide sensor id information.
>> "little-endian" property is to tell the endianness of TMU.
>>
>> Signed-off-by: Jia Hongtao 
>> ---
>> Changes for V2:
>> * Remove formatting chnages.
>>
>>  Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7 +++
>>  1 file changed, 7 insertions(+)
>
> Acked-by: Rob Herring 

Hi Zhang Rui,

Since you have applied the driver patch, can you also apply the
binding patch?  The binding is supposed to go with the driver.

Regards,
Leo

RE: [PATCH] dma/fsldma : Unmap region obtained by of_iomap

[Leo Li]

> -Original Message-
> From: Arvind Yadav [mailto:arvind.yadav...@gmail.com]
> Sent: Wednesday, September 28, 2016 5:45 AM
> To: le...@freescale.com; z...@zh-kernel.org; vinod.k...@intel.com
> Cc: dan.j.willi...@intel.com; linuxppc-dev@lists.ozlabs.org;
> dmaeng...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] dma/fsldma : Unmap region obtained by of_iomap
> 
> Free memory mapping, if probe is not successful.
> 
> Signed-off-by: Arvind Yadav 

Acked-by: Li Yang 

> ---
>  drivers/dma/fsldma.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index
> 911b717..7ba8944 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1351,7 +1351,7 @@ static int fsldma_of_probe(struct platform_device
> *op)
>   if (!fdev->regs) {
>   dev_err(>dev, "unable to ioremap registers\n");
>   err = -ENOMEM;
> - goto out_free_fdev;
> + goto out_free;
>   }
> 
>   /* map the channel IRQ if it exists, but don't hookup the handler yet */
> @@ -1416,6 +1416,8 @@ static int fsldma_of_probe(struct platform_device
> *op)
> 
>  out_free_fdev:
>   irq_dispose_mapping(fdev->irq);
> + iounmap(fdev->regs);
> +out_free:
>   kfree(fdev);
>  out_return:
>   return err;
> --
> 1.7.9.5

Re: [PATCH v5 2/2] QE: remove PPCisms for QE

[Leo Li]

On Tue, Sep 20, 2016 at 8:13 PM, Qiang Zhao <qiang.z...@nxp.com> wrote:
> On Mon, Sep 20, 2016 at 4:13 AM, Leo Li wrote:
>> -Original Message-----
>> From: Leo Li [mailto:pku@gmail.com]
>> Sent: Tuesday, September 20, 2016 4:13 AM
>> To: Qiang Zhao <qiang.z...@nxp.com>
>> Cc: Scott Wood <o...@buserror.net>; linuxppc-dev > d...@lists.ozlabs.org>; lkml <linux-ker...@vger.kernel.org>; X.B. Xie
>> <xiaobo@nxp.com>
>> Subject: Re: [PATCH v5 2/2] QE: remove PPCisms for QE
>>
>> On Mon, Jul 25, 2016 at 12:43 AM, Zhao Qiang <qiang.z...@nxp.com> wrote:
>> > QE was supported on PowerPC, and dependent on PPC, Now it is supported
>> > on other platforms. so remove PPCisms.
>> >
>> > Signed-off-by: Zhao Qiang <qiang.z...@nxp.com>
>> > ---
>> > Changes for v2:
>> > - na
>> > Changes for v3:
>> > - add NO_IRQ
>> > Changes for v4:
>> > - modify spin_event_timeout to opencoded timeout loop
>> > - remove NO_IRQ
>> > - modify virq_to_hw to opencoed code Changes for v5:
>> > - modify commit msg
>> > - modify depends of QUICC_ENGINE
>> > - add kerneldoc header for qe_issue_cmd
>> >
>> >  drivers/irqchip/qe_ic.c   | 28 +--
>> >  drivers/soc/fsl/qe/Kconfig|  2 +-
>> >  drivers/soc/fsl/qe/qe.c   | 80 
>> > ++--
>> ---
>> >  drivers/soc/fsl/qe/qe_io.c| 42 ++-
>> >  drivers/soc/fsl/qe/qe_tdm.c   |  8 ++---
>> >  drivers/soc/fsl/qe/ucc.c  | 10 +++---
>> >  drivers/soc/fsl/qe/ucc_fast.c | 68 ++--
>> >  include/soc/fsl/qe/qe.h   |  1 -
>> >  include/soc/fsl/qe/qe_ic.h| 12 +++
>> >  9 files changed, 133 insertions(+), 118 deletions(-)
>> >
>>
>> [snip]
>>
>> > diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
>> > index 73a2e08..b26b643 100644
>> > --- a/drivers/soc/fsl/qe/Kconfig
>> > +++ b/drivers/soc/fsl/qe/Kconfig
>> > @@ -4,7 +4,7 @@
>> >
>> >  config QUICC_ENGINE
>> > bool "Freescale QUICC Engine (QE) Support"
>> > -   depends on FSL_SOC && PPC32
>> > +   depends on OF && HAS_IOMEM
>> > select GENERIC_ALLOCATOR
>> > select CRC32
>> > help
>>
>> You make it possible to build QE drivers on ARM, but the UCC_GETH fails to
>> build on arm64.  Please make sure all these drivers can build on other
>> architectures.  Or you can simply make them only build for Power architecture
>> as most of them are not available on ARM.
>>
>
> Most of them are not available on ARM and ARM64.
> Now, only qe-hdlc is available on ARM64.

Then you should update the Kconfig for these drivers too, if they are
only depending on CONFIG_QUICC_ENGINE.

Regards,
Leo

Re: [PATCH v5 2/2] QE: remove PPCisms for QE

[Leo Li]

On Mon, Jul 25, 2016 at 12:43 AM, Zhao Qiang  wrote:
> QE was supported on PowerPC, and dependent on PPC,
> Now it is supported on other platforms. so remove PPCisms.
>
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v2:
> - na
> Changes for v3:
> - add NO_IRQ
> Changes for v4:
> - modify spin_event_timeout to opencoded timeout loop
> - remove NO_IRQ
> - modify virq_to_hw to opencoed code
> Changes for v5:
> - modify commit msg
> - modify depends of QUICC_ENGINE
> - add kerneldoc header for qe_issue_cmd
>
>  drivers/irqchip/qe_ic.c   | 28 +--
>  drivers/soc/fsl/qe/Kconfig|  2 +-
>  drivers/soc/fsl/qe/qe.c   | 80 
> ++-
>  drivers/soc/fsl/qe/qe_io.c| 42 ++-
>  drivers/soc/fsl/qe/qe_tdm.c   |  8 ++---
>  drivers/soc/fsl/qe/ucc.c  | 10 +++---
>  drivers/soc/fsl/qe/ucc_fast.c | 68 ++--
>  include/soc/fsl/qe/qe.h   |  1 -
>  include/soc/fsl/qe/qe_ic.h| 12 +++
>  9 files changed, 133 insertions(+), 118 deletions(-)
>

[snip]

> diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
> index 73a2e08..b26b643 100644
> --- a/drivers/soc/fsl/qe/Kconfig
> +++ b/drivers/soc/fsl/qe/Kconfig
> @@ -4,7 +4,7 @@
>
>  config QUICC_ENGINE
> bool "Freescale QUICC Engine (QE) Support"
> -   depends on FSL_SOC && PPC32
> +   depends on OF && HAS_IOMEM
> select GENERIC_ALLOCATOR
> select CRC32
> help

You make it possible to build QE drivers on ARM, but the UCC_GETH
fails to build on arm64.  Please make sure all these drivers can build
on other architectures.  Or you can simply make them only build for
Power architecture as most of them are not available on ARM.

Regards,
Leo

Re: [PATCH v5 2/2] QE: remove PPCisms for QE

[Leo Li]

On Wed, Sep 21, 2016 at 8:43 PM, Qiang Zhao <qiang.z...@nxp.com> wrote:
> On Mon, Sep 22, 2016 at 2:19 AM, Leo Li wrote:
>> -Original Message-----
>> From: Leo Li [mailto:pku@gmail.com]
>> Sent: Thursday, September 22, 2016 2:19 AM
>> To: Qiang Zhao <qiang.z...@nxp.com>
>> Cc: Scott Wood <o...@buserror.net>; linuxppc-dev > d...@lists.ozlabs.org>; lkml <linux-ker...@vger.kernel.org>; X.B. Xie
>> <xiaobo@nxp.com>
>> Subject: Re: [PATCH v5 2/2] QE: remove PPCisms for QE
>>
>> On Tue, Sep 20, 2016 at 8:13 PM, Qiang Zhao <qiang.z...@nxp.com> wrote:
>> > On Mon, Sep 20, 2016 at 4:13 AM, Leo Li wrote:
>> >> -Original Message-
>> >> From: Leo Li [mailto:pku@gmail.com]
>> >> Sent: Tuesday, September 20, 2016 4:13 AM
>> >> To: Qiang Zhao <qiang.z...@nxp.com>
>> >> Cc: Scott Wood <o...@buserror.net>; linuxppc-dev > >> d...@lists.ozlabs.org>; lkml <linux-ker...@vger.kernel.org>; X.B. Xie
>> >> <xiaobo@nxp.com>
>> >> Subject: Re: [PATCH v5 2/2] QE: remove PPCisms for QE
>> >>
>> >> On Mon, Jul 25, 2016 at 12:43 AM, Zhao Qiang <qiang.z...@nxp.com>
>> wrote:
>> >> > QE was supported on PowerPC, and dependent on PPC, Now it is
>> >> > supported on other platforms. so remove PPCisms.
>> >> >
>> >> > Signed-off-by: Zhao Qiang <qiang.z...@nxp.com>
>> >> > ---
>> >> > Changes for v2:
>> >> > - na
>> >> > Changes for v3:
>> >> > - add NO_IRQ
>> >> > Changes for v4:
>> >> > - modify spin_event_timeout to opencoded timeout loop
>> >> > - remove NO_IRQ
>> >> > - modify virq_to_hw to opencoed code Changes for v5:
>> >> > - modify commit msg
>> >> > - modify depends of QUICC_ENGINE
>> >> > - add kerneldoc header for qe_issue_cmd
>> >> >
>> >> >  drivers/irqchip/qe_ic.c   | 28 +--
>> >> >  drivers/soc/fsl/qe/Kconfig|  2 +-
>> >> >  drivers/soc/fsl/qe/qe.c   | 80 ++--
>> 
>> >> ---
>> >> >  drivers/soc/fsl/qe/qe_io.c| 42 ++-
>> >> >  drivers/soc/fsl/qe/qe_tdm.c   |  8 ++---
>> >> >  drivers/soc/fsl/qe/ucc.c  | 10 +++---
>> >> >  drivers/soc/fsl/qe/ucc_fast.c | 68 ++--
>> >> >  include/soc/fsl/qe/qe.h   |  1 -
>> >> >  include/soc/fsl/qe/qe_ic.h| 12 +++
>> >> >  9 files changed, 133 insertions(+), 118 deletions(-)
>> >> >
>> >>
>> >> [snip]
>> >>
>> >> > diff --git a/drivers/soc/fsl/qe/Kconfig
>> >> > b/drivers/soc/fsl/qe/Kconfig index 73a2e08..b26b643 100644
>> >> > --- a/drivers/soc/fsl/qe/Kconfig
>> >> > +++ b/drivers/soc/fsl/qe/Kconfig
>> >> > @@ -4,7 +4,7 @@
>> >> >
>> >> >  config QUICC_ENGINE
>> >> > bool "Freescale QUICC Engine (QE) Support"
>> >> > -   depends on FSL_SOC && PPC32
>> >> > +   depends on OF && HAS_IOMEM
>> >> > select GENERIC_ALLOCATOR
>> >> > select CRC32
>> >> > help
>> >>
>> >> You make it possible to build QE drivers on ARM, but the UCC_GETH
>> >> fails to build on arm64.  Please make sure all these drivers can
>> >> build on other architectures.  Or you can simply make them only build
>> >> for Power architecture as most of them are not available on ARM.
>> >>
>> >
>> > Most of them are not available on ARM and ARM64.
>> > Now, only qe-hdlc is available on ARM64.
>>
>> Then you should update the Kconfig for these drivers too, if they are only
>> depending on CONFIG_QUICC_ENGINE.
>
> You mean adding "depends on FSL_SOC && PPC32 " to the drivers that are not 
> available for ARM?

Yes.  Previously these drivers get the architecture limitation from
CONFIG_QUICC_ENGINE, but now they need them by their own.

Regards,
Leo

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-dev@lists.ozlabs.org; linux-ker...@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: [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-ker...@vger.kernel.org;
> Claudiu Manoil <claudiu.man...@nxp.com>; colin.k...@canonical.com;
> linuxppc-dev@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: [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-ker...@vger.kernel.org;
> Claudiu Manoil ; colin.k...@canonical.com;
> linuxppc-dev@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: [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-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-ker...@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: Machine Check in P2010(e500v2)

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Wednesday, September 20, 2017 11:45 AM
> To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>; York Sun
> <york@nxp.com>
> Subject: Re: Machine Check in P2010(e500v2)
> 
> On Sat, 2017-09-09 at 14:45 +0200, Joakim Tjernlund wrote:
> > On Fri, 2017-09-08 at 22:27 +, Leo Li wrote:
> > > > -Original Message-
> > > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > > Sent: Friday, September 08, 2017 7:51 AM
> > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>;
> > > > York Sun <york@nxp.com>
> > > > Subject: Re: Machine Check in P2010(e500v2)
> > > >
> > > > On Fri, 2017-09-08 at 11:54 +0200, Joakim Tjernlund wrote:
> > > > > On Thu, 2017-09-07 at 18:54 +, Leo Li wrote:
> > > > > > > -Original Message-
> > > > > > > From: Joakim Tjernlund
> > > > > > > [mailto:joakim.tjernl...@infinera.com]
> > > > > > > Sent: Thursday, September 07, 2017 3:41 AM
> > > > > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li
> > > > > > > <leoyang...@nxp.com>; York Sun <york@nxp.com>
> > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > >
> > > > > > > On Thu, 2017-09-07 at 00:50 +0200, Joakim Tjernlund wrote:
> > > > > > > > On Wed, 2017-09-06 at 21:13 +, Leo Li wrote:
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Joakim Tjernlund
> > > > > > > > > > [mailto:joakim.tjernl...@infinera.com]
> > > > > > > > > > Sent: Wednesday, September 06, 2017 3:54 PM
> > > > > > > > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li
> > > > > > > > > > <leoyang...@nxp.com>; York Sun <york@nxp.com>
> > > > > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > > > > >
> > > > > > > > > > On Wed, 2017-09-06 at 20:28 +, Leo Li wrote:
> > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > From: Joakim Tjernlund
> > > > > > > > > > > > [mailto:joakim.tjernl...@infinera.com]
> > > > > > > > > > > > Sent: Wednesday, September 06, 2017 3:17 PM
> > > > > > > > > > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li
> > > > > > > > > > > > <leoyang...@nxp.com>; York Sun <york@nxp.com>
> > > > > > > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 2017-09-06 at 19:31 +, Leo Li wrote:
> > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > From: York Sun
> > > > > > > > > > > > > > Sent: Wednesday, September 06, 2017 10:38 AM
> > > > > > > > > > > > > > To: Joakim Tjernlund
> > > > > > > > > > > > > > <joakim.tjernl...@infinera.com>;
> > > > > > > > > > > > > > linuxppc- d...@lists.ozlabs.org; Leo Li
> > > > > > > > > > > > > > <leoyang...@nxp.com>
> > > > > > > > > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Scott is no longer with Freescale/NXP. Adding Leo.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:
> > > > > > > > > > > > > > > So after some debugging I found this bug:
> > > > > > > > > > > > > > > @@ -996,7 +998,7 @@ int
> > > > > > > > > > > > > > > fsl_pci_mcheck_exception(struct pt_regs
> > > > > > > > > >

RE: Machine Check in P2010(e500v2)

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Friday, September 08, 2017 7:51 AM
> To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>; York Sun
> <york@nxp.com>
> Subject: Re: Machine Check in P2010(e500v2)
> 
> On Fri, 2017-09-08 at 11:54 +0200, Joakim Tjernlund wrote:
> > On Thu, 2017-09-07 at 18:54 +, Leo Li wrote:
> > > > -Original Message-
> > > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > > Sent: Thursday, September 07, 2017 3:41 AM
> > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>;
> > > > York Sun <york@nxp.com>
> > > > Subject: Re: Machine Check in P2010(e500v2)
> > > >
> > > > On Thu, 2017-09-07 at 00:50 +0200, Joakim Tjernlund wrote:
> > > > > On Wed, 2017-09-06 at 21:13 +, Leo Li wrote:
> > > > > > > -Original Message-
> > > > > > > From: Joakim Tjernlund
> > > > > > > [mailto:joakim.tjernl...@infinera.com]
> > > > > > > Sent: Wednesday, September 06, 2017 3:54 PM
> > > > > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li
> > > > > > > <leoyang...@nxp.com>; York Sun <york@nxp.com>
> > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > >
> > > > > > > On Wed, 2017-09-06 at 20:28 +, Leo Li wrote:
> > > > > > > > > -Original Message-
> > > > > > > > > From: Joakim Tjernlund
> > > > > > > > > [mailto:joakim.tjernl...@infinera.com]
> > > > > > > > > Sent: Wednesday, September 06, 2017 3:17 PM
> > > > > > > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li
> > > > > > > > > <leoyang...@nxp.com>; York Sun <york@nxp.com>
> > > > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > > > >
> > > > > > > > > On Wed, 2017-09-06 at 19:31 +, Leo Li wrote:
> > > > > > > > > > > -Original Message-
> > > > > > > > > > > From: York Sun
> > > > > > > > > > > Sent: Wednesday, September 06, 2017 10:38 AM
> > > > > > > > > > > To: Joakim Tjernlund
> > > > > > > > > > > <joakim.tjernl...@infinera.com>;
> > > > > > > > > > > linuxppc- d...@lists.ozlabs.org; Leo Li
> > > > > > > > > > > <leoyang...@nxp.com>
> > > > > > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > > > > > >
> > > > > > > > > > > Scott is no longer with Freescale/NXP. Adding Leo.
> > > > > > > > > > >
> > > > > > > > > > > On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:
> > > > > > > > > > > > So after some debugging I found this bug:
> > > > > > > > > > > > @@ -996,7 +998,7 @@ int
> > > > > > > > > > > > fsl_pci_mcheck_exception(struct pt_regs
> > > > > > >
> > > > > > > *regs)
> > > > > > > > > > > >  if (is_in_pci_mem_space(addr)) {
> > > > > > > > > > > >  if (user_mode(regs)) {
> > > > > > > > > > > >  pagefault_disable();
> > > > > > > > > > > > -   ret = get_user(regs->nip, 
> > > > > > > > > > > > );
> > > > > > > > > > > > +   ret = get_user(inst,
> > > > > > > > > > > > + (__u32 __user *)regs->nip);
> > > > > > > > > > > >  pagefault_enable();
> > > > > > > > > > > >  } else {
> > > > > > > > > > > >  ret =
> > > > > > > > > > > > probe_kernel_address(regs->nip, inst);
> > > > > > > > > > > >
> > > > > > > > > > > > Howev

RE: Machine Check in P2010(e500v2)

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Thursday, September 07, 2017 3:41 AM
> To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>; York Sun
> <york@nxp.com>
> Subject: Re: Machine Check in P2010(e500v2)
> 
> On Thu, 2017-09-07 at 00:50 +0200, Joakim Tjernlund wrote:
> > On Wed, 2017-09-06 at 21:13 +, Leo Li wrote:
> > > > -Original Message-
> > > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > > Sent: Wednesday, September 06, 2017 3:54 PM
> > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>;
> > > > York Sun <york@nxp.com>
> > > > Subject: Re: Machine Check in P2010(e500v2)
> > > >
> > > > On Wed, 2017-09-06 at 20:28 +, Leo Li wrote:
> > > > > > -Original Message-
> > > > > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > > > > Sent: Wednesday, September 06, 2017 3:17 PM
> > > > > > To: linuxppc-dev@lists.ozlabs.org; Leo Li
> > > > > > <leoyang...@nxp.com>; York Sun <york@nxp.com>
> > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > >
> > > > > > On Wed, 2017-09-06 at 19:31 +, Leo Li wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: York Sun
> > > > > > > > Sent: Wednesday, September 06, 2017 10:38 AM
> > > > > > > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>;
> > > > > > > > linuxppc- d...@lists.ozlabs.org; Leo Li
> > > > > > > > <leoyang...@nxp.com>
> > > > > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > > > > >
> > > > > > > > Scott is no longer with Freescale/NXP. Adding Leo.
> > > > > > > >
> > > > > > > > On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:
> > > > > > > > > So after some debugging I found this bug:
> > > > > > > > > @@ -996,7 +998,7 @@ int fsl_pci_mcheck_exception(struct
> > > > > > > > > pt_regs
> > > >
> > > > *regs)
> > > > > > > > >  if (is_in_pci_mem_space(addr)) {
> > > > > > > > >  if (user_mode(regs)) {
> > > > > > > > >  pagefault_disable();
> > > > > > > > > -   ret = get_user(regs->nip, );
> > > > > > > > > +   ret = get_user(inst, (__u32
> > > > > > > > > + __user *)regs->nip);
> > > > > > > > >  pagefault_enable();
> > > > > > > > >  } else {
> > > > > > > > >  ret =
> > > > > > > > > probe_kernel_address(regs->nip, inst);
> > > > > > > > >
> > > > > > > > > However, the kernel still locked up after fixing that.
> > > > > > > > > Now I wonder why this fixup is there in the first place?
> > > > > > > > > The routine will not really fixup the insn, just return
> > > > > > > > > 0x for the failing read and then advance the process 
> > > > > > > > > NIP.
> > > > > > >
> > > > > > > You are right.  The code here only gives 0x to the
> > > > > > > load instructions and
> > > > > >
> > > > > > continue with the next instruction when the load instruction
> > > > > > is causing the machine check.  This will prevent a system
> > > > > > lockup when reading from PCI/RapidIO device which is link down.
> > > > > > >
> > > > > > > I don't know what is actual problem in your case.  Maybe it
> > > > > > > is a write
> > > > > >
> > > > > > instruction instead of read?   Or the code is in a infinite loop 
> > > > > > waiting for
> a
> > > >
> > > > valid
> > > > > > read result?  Are you able to do some further debugging with
> > > > > > the NIP correctly printed?
> > &

RE: Machine Check in P2010(e500v2)

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Wednesday, September 06, 2017 3:54 PM
> To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>; York Sun
> <york@nxp.com>
> Subject: Re: Machine Check in P2010(e500v2)
> 
> On Wed, 2017-09-06 at 20:28 +, Leo Li wrote:
> > > -Original Message-
> > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > Sent: Wednesday, September 06, 2017 3:17 PM
> > > To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>; York
> > > Sun <york@nxp.com>
> > > Subject: Re: Machine Check in P2010(e500v2)
> > >
> > > On Wed, 2017-09-06 at 19:31 +, Leo Li wrote:
> > > > > -Original Message-
> > > > > From: York Sun
> > > > > Sent: Wednesday, September 06, 2017 10:38 AM
> > > > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>; linuxppc-
> > > > > d...@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>
> > > > > Subject: Re: Machine Check in P2010(e500v2)
> > > > >
> > > > > Scott is no longer with Freescale/NXP. Adding Leo.
> > > > >
> > > > > On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:
> > > > > > So after some debugging I found this bug:
> > > > > > @@ -996,7 +998,7 @@ int fsl_pci_mcheck_exception(struct pt_regs
> *regs)
> > > > > >  if (is_in_pci_mem_space(addr)) {
> > > > > >  if (user_mode(regs)) {
> > > > > >  pagefault_disable();
> > > > > > -   ret = get_user(regs->nip, );
> > > > > > +   ret = get_user(inst, (__u32 __user
> > > > > > + *)regs->nip);
> > > > > >  pagefault_enable();
> > > > > >  } else {
> > > > > >  ret = probe_kernel_address(regs->nip,
> > > > > > inst);
> > > > > >
> > > > > > However, the kernel still locked up after fixing that.
> > > > > > Now I wonder why this fixup is there in the first place? The
> > > > > > routine will not really fixup the insn, just return 0x
> > > > > > for the failing read and then advance the process NIP.
> > > >
> > > > You are right.  The code here only gives 0x to the load
> > > > instructions and
> > >
> > > continue with the next instruction when the load instruction is
> > > causing the machine check.  This will prevent a system lockup when
> > > reading from PCI/RapidIO device which is link down.
> > > >
> > > > I don't know what is actual problem in your case.  Maybe it is a
> > > > write
> > >
> > > instruction instead of read?   Or the code is in a infinite loop waiting 
> > > for a
> valid
> > > read result?  Are you able to do some further debugging with the NIP
> > > correctly printed?
> > > >
> > >
> > > According to the MC it is a Read and the NIP also leads to a read in the
> program.
> > > ATM, I have disabled the fixup but I will enable that again.
> > > Question, is it safe add a small printk when this MC happens(after
> > > fixing up)? I need to see that it has happened as the error is somewhat
> random.
> >
> > I think it is safe to add printk as the current machine check handlers are 
> > also
> using printk.
> 
> I hope so, but if the fixup fires there is no printk at all so I was a bit 
> unsure.
> Don't like this fixup though, is there not a better way than faking a read to 
> user
> space(or kernel for that matter) ?

I don't have a better idea.  Without the fixup, the offending load instruction 
will never finish if there is anything wrong with the backing device and freeze 
the whole system.  Do you have any suggestion in mind?

Regards,
Leo

RE: Machine Check in P2010(e500v2)

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Wednesday, September 06, 2017 3:17 PM
> To: linuxppc-dev@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>; York Sun
> <york@nxp.com>
> Subject: Re: Machine Check in P2010(e500v2)
> 
> On Wed, 2017-09-06 at 19:31 +, Leo Li wrote:
> > > -Original Message-
> > > From: York Sun
> > > Sent: Wednesday, September 06, 2017 10:38 AM
> > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>; linuxppc-
> > > d...@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>
> > > Subject: Re: Machine Check in P2010(e500v2)
> > >
> > > Scott is no longer with Freescale/NXP. Adding Leo.
> > >
> > > On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:
> > > > So after some debugging I found this bug:
> > > > @@ -996,7 +998,7 @@ int fsl_pci_mcheck_exception(struct pt_regs *regs)
> > > >  if (is_in_pci_mem_space(addr)) {
> > > >  if (user_mode(regs)) {
> > > >  pagefault_disable();
> > > > -   ret = get_user(regs->nip, );
> > > > +   ret = get_user(inst, (__u32 __user
> > > > + *)regs->nip);
> > > >  pagefault_enable();
> > > >  } else {
> > > >  ret = probe_kernel_address(regs->nip,
> > > > inst);
> > > >
> > > > However, the kernel still locked up after fixing that.
> > > > Now I wonder why this fixup is there in the first place? The
> > > > routine will not really fixup the insn, just return 0x for
> > > > the failing read and then advance the process NIP.
> >
> > You are right.  The code here only gives 0x to the load 
> > instructions and
> continue with the next instruction when the load instruction is causing the
> machine check.  This will prevent a system lockup when reading from
> PCI/RapidIO device which is link down.
> >
> > I don't know what is actual problem in your case.  Maybe it is a write
> instruction instead of read?   Or the code is in a infinite loop waiting for 
> a valid
> read result?  Are you able to do some further debugging with the NIP correctly
> printed?
> >
> 
> According to the MC it is a Read and the NIP also leads to a read in the 
> program.
> ATM, I have disabled the fixup but I will enable that again.
> Question, is it safe add a small printk when this MC happens(after fixing 
> up)? I
> need to see that it has happened as the error is somewhat random.

I think it is safe to add printk as the current machine check handlers are also 
using printk.

> 
>  Jocke
> 
> > Regards,
> > Leo
> >
> > > >
> > > > Removing the fixup does not help either, kernel still locks up:
> > > > [   28.170532] Machine check in kernel mode.
> > > > [   28.174538] Caused by (from MCSR=10008):
> > > > [   28.182804] Bus - Read Data Bus Error: DAR:b7013000
> > > > [   28.197079] Oops: Machine check, sig: 7 [#1]
> > > > [   28.201343] P1010 RDB
> > > > [   28.203608] Modules linked in: linux_bcm_knet(PO) linux_user_bde(PO)
> > >
> > > linux_kernel_bde(PO)
> > > > [   28.211796] CPU: 0 PID: 470 Comm: emxp2_hw_bl Tainted: P   O
> > >
> > > 4.1.38+ #201
> > > > [   28.219540] task: db16ed10 ti: df122000 task.ti: df122000
> > > > [   28.224935] NIP: 10a4e2f4 LR: 10a4e404 CTR: 10046c38
> > > > [   28.229896] REGS: df123f10 TRAP: 0204   Tainted: P   O 
> > > > (4.1.38+)
> > > > [   28.236942] MSR: 0002d000 <CE,EE,PR,ME>  CR: 44002428  XER:
> 
> > > > [   28.243306] DEAR: b7013000 ESR: 
> > > > GPR00: 10a4e404 bfab2730 b7b354a0 132f9fa8 07006000 0700
> > >
> > > 
> > > > 132f9fd8
> > > > GPR08: b6fd5000 b6fe5000 0003e000 bfab2720 24004424 11d6cf7c
> > > > 
> > > > 
> > > > GPR16: 10f6e29c 10f6c872 10f6db01 b541 b541 11d92fcc
> > > > 0011
> > > > 0001
> > > > GPR24: 01a5bd3e 132ffbf0 11d6  07006000 
> > > > 132f9fa8
> > >
> > > 
> > > > [   28.275547] NIP [10a4e2f4] 0x10a4e2f4
> > > > [   28.279204] LR [10a4e404] 0x10a4e404
> > > > [   28.282772] Call Trace:
> > > > [   28.2

RE: Machine Check in P2010(e500v2)

[Leo Li]

> -Original Message-
> From: York Sun
> Sent: Wednesday, September 06, 2017 10:38 AM
> To: Joakim Tjernlund <joakim.tjernl...@infinera.com>; linuxppc-
> d...@lists.ozlabs.org; Leo Li <leoyang...@nxp.com>
> Subject: Re: Machine Check in P2010(e500v2)
> 
> Scott is no longer with Freescale/NXP. Adding Leo.
> 
> On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:
> > So after some debugging I found this bug:
> > @@ -996,7 +998,7 @@ int fsl_pci_mcheck_exception(struct pt_regs *regs)
> >  if (is_in_pci_mem_space(addr)) {
> >  if (user_mode(regs)) {
> >  pagefault_disable();
> > -   ret = get_user(regs->nip, );
> > +   ret = get_user(inst, (__u32 __user
> > + *)regs->nip);
> >  pagefault_enable();
> >  } else {
> >  ret = probe_kernel_address(regs->nip, inst);
> >
> > However, the kernel still locked up after fixing that.
> > Now I wonder why this fixup is there in the first place? The routine
> > will not really fixup the insn, just return 0x for the failing
> > read and then advance the process NIP.

You are right.  The code here only gives 0x to the load instructions 
and continue with the next instruction when the load instruction is causing the 
machine check.  This will prevent a system lockup when reading from PCI/RapidIO 
device which is link down.

I don't know what is actual problem in your case.  Maybe it is a write 
instruction instead of read?   Or the code is in a infinite loop waiting for a 
valid read result?  Are you able to do some further debugging with the NIP 
correctly printed?

Regards,
Leo

> >
> > Removing the fixup does not help either, kernel still locks up:
> > [   28.170532] Machine check in kernel mode.
> > [   28.174538] Caused by (from MCSR=10008):
> > [   28.182804] Bus - Read Data Bus Error: DAR:b7013000
> > [   28.197079] Oops: Machine check, sig: 7 [#1]
> > [   28.201343] P1010 RDB
> > [   28.203608] Modules linked in: linux_bcm_knet(PO) linux_user_bde(PO)
> linux_kernel_bde(PO)
> > [   28.211796] CPU: 0 PID: 470 Comm: emxp2_hw_bl Tainted: P   O
> 4.1.38+ #201
> > [   28.219540] task: db16ed10 ti: df122000 task.ti: df122000
> > [   28.224935] NIP: 10a4e2f4 LR: 10a4e404 CTR: 10046c38
> > [   28.229896] REGS: df123f10 TRAP: 0204   Tainted: P   O 
> > (4.1.38+)
> > [   28.236942] MSR: 0002d000 <CE,EE,PR,ME>  CR: 44002428  XER: 
> > [   28.243306] DEAR: b7013000 ESR: 
> > GPR00: 10a4e404 bfab2730 b7b354a0 132f9fa8 07006000 0700
> 
> > 132f9fd8
> > GPR08: b6fd5000 b6fe5000 0003e000 bfab2720 24004424 11d6cf7c 
> > 
> > GPR16: 10f6e29c 10f6c872 10f6db01 b541 b541 11d92fcc 0011
> > 0001
> > GPR24: 01a5bd3e 132ffbf0 11d6  07006000  132f9fa8
> 
> > [   28.275547] NIP [10a4e2f4] 0x10a4e2f4
> > [   28.279204] LR [10a4e404] 0x10a4e404
> > [   28.282772] Call Trace:
> > [   28.285213] ---[ end trace 9f8b64ab1e83f449 ]---
> > [   28.289825]
> >
> >
> >   Jocke
> >
> > On Fri, 2017-09-01 at 13:32 +0200, Joakim Tjernlund wrote:
> >> I am trying to debug a Machine Check for a P2010 (e500v2) CPU:
> >>
> >> [   28.111816] Caused by (from MCSR=10008): Bus - Read Data Bus Error
> >> [   28.117998] Oops: Machine check, sig: 7 [#1]
> >> [   28.122263] P1010 RDB
> >> [   28.124529] Modules linked in: linux_bcm_knet(PO) linux_user_bde(PO)
> linux_kernel_bde(PO)
> >> [   28.132718] CPU: 0 PID: 470 Comm: emxp2_hw_bl Tainted: P   O
> 4.1.38+ #49
> >> [   28.140376] task: db16cd10 ti: df128000 task.ti: df128000
> >> [   28.145770] NIP:  LR: 10a4e404 CTR: 10046c38
> >> [   28.150730] REGS: df129f10 TRAP: 0204   Tainted: P   O 
> >> (4.1.38+)
> >> [   28.157776] MSR: 0002d000 <CE,EE,PR,ME>  CR: 44002428  XER: 
> >> [   28.164140] DEAR: b7187000 ESR: 
> >> GPR00: 10a4e404 bf86ea30 b7ca94a0 132f9fa8 07006000 0700
> 
> >> 132f9fd8
> >> GPR08: b7149000 b7159000 0003e000 bf86ea20 24004424 11d6cf7c
> 
> >> 
> >> GPR16: 10f6e29c 10f6c872 10f6db01 b541 b541 11d92fcc
> 0011
> >> 0001
> >> GPR24: 01a4d12d 132ffbf0 11d6  07006000 
> 132f9fa8 
> >> [   28.196375] NIP []   (null)
> >> [   28.199859] LR [10a4e404] 0x10a4e404
> >> [   28.203426] C

RE: [PATCH] fsl_pci: Correct fsl_pci_mcheck_exception

[Leo Li]

> -Original Message-
> From: York Sun
> Sent: Wednesday, September 06, 2017 10:34 AM
> To: Leo Li <leoyang...@nxp.com>
> Cc: Joakim Tjernlund <joakim.tjernl...@infinera.com>; linuxppc-dev linuxppc-
> dev <linuxppc-dev@lists.ozlabs.org>
> Subject: Re: [PATCH] fsl_pci: Correct fsl_pci_mcheck_exception
> 
> On 09/05/2017 04:59 AM, Joakim Tjernlund wrote:
> > get_user() had it args reversed causing NIP to be NULL:ed instead of
> > fixing up the PCI access.
> >
> > Note: This still hangs my P1020 Freescale CPU hard, but at least I get
> > a NIP now.
> >
> > Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > ---
> >   arch/powerpc/sysdev/fsl_pci.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c index 7c8b779c329a..9e64c12dff6a
> > 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -996,7 +996,7 @@ int fsl_pci_mcheck_exception(struct pt_regs *regs)
> > if (is_in_pci_mem_space(addr)) {
> > if (user_mode(regs)) {
> > pagefault_disable();
> > -   ret = get_user(regs->nip, );
> > +   ret = get_user(inst, (__u32 __user *)regs->nip);
> > pagefault_enable();
> > } else {
> > ret = probe_kernel_address(regs->nip, inst);
> >
> 
> Leo,
> 
> Can you take a look, or assign it to someone who is familiar with this code?

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

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: [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-ker...@vger.kernel.org; linux-
> p...@vger.kernel.org; linuxppc-dev@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] fsl_pci: Correct fsl_pci_mcheck_exception

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Tuesday, November 21, 2017 11:17 AM
> To: Leo Li <leoyang...@nxp.com>; York Sun <york@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] fsl_pci: Correct fsl_pci_mcheck_exception
> 
> On Wed, 2017-09-06 at 19:19 +, Leo Li wrote:
> > > -Original Message-
> > > From: York Sun
> > > Sent: Wednesday, September 06, 2017 10:34 AM
> > > To: Leo Li <leoyang...@nxp.com>
> > > Cc: Joakim Tjernlund <joakim.tjernl...@infinera.com>; linuxppc-dev
> > > linuxppc- dev <linuxppc-dev@lists.ozlabs.org>
> > > Subject: Re: [PATCH] fsl_pci: Correct fsl_pci_mcheck_exception
> > >
> > > On 09/05/2017 04:59 AM, Joakim Tjernlund wrote:
> > > > get_user() had it args reversed causing NIP to be NULL:ed instead
> > > > of fixing up the PCI access.
> > > >
> > > > Note: This still hangs my P1020 Freescale CPU hard, but at least I
> > > > get a NIP now.
> > > >
> > > > Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > > ---
> > > >   arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > > > b/arch/powerpc/sysdev/fsl_pci.c index 7c8b779c329a..9e64c12dff6a
> > > > 100644
> > > > --- a/arch/powerpc/sysdev/fsl_pci.c
> > > > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > > > @@ -996,7 +996,7 @@ int fsl_pci_mcheck_exception(struct pt_regs
> *regs)
> > > > if (is_in_pci_mem_space(addr)) {
> > > > if (user_mode(regs)) {
> > > > pagefault_disable();
> > > > -   ret = get_user(regs->nip, );
> > > > +   ret = get_user(inst, (__u32 __user *)regs->nip);
> > > > pagefault_enable();
> > > > } else {
> > > > ret = probe_kernel_address(regs->nip, inst);
> > > >
> > >
> > > Leo,
> > >
> > > Can you take a look, or assign it to someone who is familiar with this
> code?
> >
> > Acked-by: Li Yang <leoyang...@nxp.com>
> >
> > Regards,
> > Leo
> 
> I think this is forgotten, cannot se it in Linus tree.

Hi Scott,

Could you help to review this patch and pick it up?  Thanks.

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-ker...@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-dev@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] QE GPIO: Add qe_gpio_set_multiple

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Thursday, August 2, 2018 5:37 PM
> To: Leo Li ; York Sun 
> Cc: linuxppc-dev@lists.ozlabs.org; m...@ellerman.id.au; Qiang Zhao
> 
> Subject: Re: [PATCH] QE GPIO: Add qe_gpio_set_multiple
> 
> Leo, did this go anywhere ?

It has been included in my soc pull request for 4.19.  
http://lkml.iu.edu/hypermail/linux/kernel/1807.3/02295.html

Leo

> 
> Jocke
> 
> On Tue, 2018-07-03 at 16:35 +, Leo Li wrote:
> >
> > > -Original Message-
> > > From: York Sun
> > > Sent: Tuesday, July 3, 2018 10:27 AM
> > > To: jo...@infinera.com ; Leo Li
> > > 
> > > Cc: linuxppc-dev@lists.ozlabs.org; m...@ellerman.id.au; Qiang Zhao
> > > 
> > > Subject: Re: [PATCH] QE GPIO: Add qe_gpio_set_multiple
> > >
> > > +Leo
> > >
> > > On 07/03/2018 03:30 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2018-06-26 at 23:41 +1000, Michael Ellerman wrote:
> > > > >
> > > > > Joakim Tjernlund  writes:
> > > > > > On Thu, 2018-06-21 at 02:38 +, Qiang Zhao wrote:
> > > > > > > On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
> > > > > > > -Original Message-
> > > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > >
> > > bounces+qiang.zhao=nxp@lists.ozlabs.org] On Behalf Of Joakim
> > > Tjernlund
> > > > > > > Sent: 2018年6月20日 0:22
> > > > > > > To: York Sun ; linuxppc-dev  > >
> > > d...@lists.ozlabs.org>
> > > > > > > Subject: [PATCH] QE GPIO: Add qe_gpio_set_multiple
> > > > > > >
> > > > > > > This cousin to gpio-mpc8xxx was lacking a multiple pins
> > > > > > > method, add
> > >
> > > one.
> > > > > > >
> > > > > > > Signed-off-by: Joakim Tjernlund
> > > > > > > 
> > > > > > > ---
> > > > > > >  drivers/soc/fsl/qe/gpio.c | 28 
> > > > > > >  1 file changed, 28 insertions(+)
> > > > >
> > > > > ...
> > > > > > >  static int qe_gpio_dir_in(struct gpio_chip *gc, unsigned int 
> > > > > > > gpio)  {
> > > > > > > struct of_mm_gpio_chip *mm_gc =
> > > > > > > to_of_mm_gpio_chip(gc); @@ -
> > >
> > > 298,6 +325,7 @@ static int __init qe_add_gpiochips(void)
> > > > > > > gc->direction_output = qe_gpio_dir_out;
> > > > > > > gc->get = qe_gpio_get;
> > > > > > > gc->set = qe_gpio_set;
> > > > > > > +   gc->set_multiple = qe_gpio_set_multiple;
> > > > > > >
> > > > > > > ret = of_mm_gpiochip_add_data(np, mm_gc, qe_gc);
> > > > > > > if (ret)
> > > > > > >
> > > > > > > Reviewed-by: Qiang Zhao 
> > > > > > >
> > > > > >
> > > > > > Who picks up this patch ? Is it queued somewhere already?
> > > > >
> > > > > Not me.
> > > >
> > > > York? You seem to be the only one left.
> > > >
> > >
> > > I am not a Linux maintainer. Even I want to, I can't merge this patch.
> > >
> > > Leo, who can merge this patch and request a pull?
> >
> > Since it falls under the driver/soc/fsl/ folder.  I can take it.
> >
> > Regards,
> > Leo

RE: [PATCH] QE GPIO: Add qe_gpio_set_multiple

[Leo Li]

> -Original Message-
> From: York Sun
> Sent: Tuesday, July 3, 2018 10:27 AM
> To: jo...@infinera.com ; Leo Li
> 
> Cc: linuxppc-dev@lists.ozlabs.org; m...@ellerman.id.au; Qiang Zhao
> 
> Subject: Re: [PATCH] QE GPIO: Add qe_gpio_set_multiple
> 
> +Leo
> 
> On 07/03/2018 03:30 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-06-26 at 23:41 +1000, Michael Ellerman wrote:
> >>
> >> Joakim Tjernlund  writes:
> >>> On Thu, 2018-06-21 at 02:38 +, Qiang Zhao wrote:
> >>>> On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
> >>>> -Original Message-
> >>>> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+qiang.zhao=nxp@lists.ozlabs.org] On Behalf Of Joakim
> Tjernlund
> >>>> Sent: 2018年6月20日 0:22
> >>>> To: York Sun ; linuxppc-dev  d...@lists.ozlabs.org>
> >>>> Subject: [PATCH] QE GPIO: Add qe_gpio_set_multiple
> >>>>
> >>>> This cousin to gpio-mpc8xxx was lacking a multiple pins method, add
> one.
> >>>>
> >>>> Signed-off-by: Joakim Tjernlund 
> >>>> ---
> >>>>  drivers/soc/fsl/qe/gpio.c | 28 
> >>>>  1 file changed, 28 insertions(+)
> >>
> >> ...
> >>>>  static int qe_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)  {
> >>>> struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc); @@ -
> 298,6 +325,7 @@ static int __init qe_add_gpiochips(void)
> >>>> gc->direction_output = qe_gpio_dir_out;
> >>>> gc->get = qe_gpio_get;
> >>>> gc->set = qe_gpio_set;
> >>>> +   gc->set_multiple = qe_gpio_set_multiple;
> >>>>
> >>>> ret = of_mm_gpiochip_add_data(np, mm_gc, qe_gc);
> >>>> if (ret)
> >>>>
> >>>> Reviewed-by: Qiang Zhao 
> >>>>
> >>>
> >>> Who picks up this patch ? Is it queued somewhere already?
> >>
> >> Not me.
> >
> > York? You seem to be the only one left.
> >
> 
> I am not a Linux maintainer. Even I want to, I can't merge this patch.
> 
> Leo, who can merge this patch and request a pull?

Since it falls under the driver/soc/fsl/ folder.  I can take it.

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 v4 1/2] dt-bindings: soc: fsl: Document Qixis FPGA usage

[Leo Li]

> -Original Message-
> From: Pankaj Bansal
> Sent: Tuesday, February 5, 2019 4:15 AM
> To: Leo Li ; Rob Herring ; Mark
> Rutland 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> open list : OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; Pankaj Bansal 
> Subject: [PATCH v4 1/2] dt-bindings: soc: fsl: Document Qixis FPGA usage
> 
> an FPGA-based system controller, called “Qixis”, which
> manages several critical system features, including:
> • Reset sequencing
> • Power supply configuration
> • Board configuration
> • hardware configuration
> 
> The qixis registers are accessible over one or more system-specific
> interfaces, typically I2C, JTAG or an embedded processor.

In theory the on-board FPGA is not part of the SoC.  The Qixis device has been 
defined previously in Documentation/devicetree/bindings/board/fsl-board.txt 
file.  Although normally board bindings are defined in architecture specific 
binding folders, this is a good place for board related stuff used across 
multiple architectures.  You can update the existing binding if needed.

> 
> Signed-off-by: Pankaj Bansal 
> ---
> 
> Notes:
> V4:
> - No Change
> V3:
> - Added boardname based compatible field in bindings
> - Added bindings for MMIO based FPGA
> V2:
> - No change
> 
>  .../bindings/soc/fsl/qixis_ctrl.txt  | 53 ++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
> b/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
> new file mode 100644
> index ..5d510df14be8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
> @@ -0,0 +1,53 @@
> +* QIXIS FPGA block
> +
> +an FPGA-based system controller, called “Qixis”, which
> +manages several critical system features, including:
> +• Configuration switch monitoring
> +• Power on/off sequencing
> +• Reset sequencing
> +• Power supply configuration
> +• Board configuration
> +• hardware configuration
> +• Background power data collection (DCM)
> +• Fault monitoring
> +• RCW bypass SRAM (replace flash RCW with internal RCW) (NOR only)
> +• Dedicated functional validation blocks (POSt/IRS, triggered event, and so
> on)
> +• I2C master for remote board control even with no DUT available
> +
> +The qixis registers are accessible over one or more system-specific
> interfaces,
> +typically I2C, JTAG or an embedded processor.
> +
> +FPGA connected to I2C:
> +Required properties:
> +
> + - compatible: should be a board-specific string followed by a string
> +   indicating the type of FPGA.  Example:
> + "fsl,-fpga", "fsl,fpga-qixis-i2c"
> + - reg : i2c address of the qixis device.
> +
> +Example (LX2160A-QDS):
> + /* The FPGA node */
> +fpga@66 {
> + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> + reg = <0x66>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + }
> +
> +* Freescale on-board FPGA
> +
> +This is the memory-mapped registers for on board FPGA.
> +
> +Required properties:
> +- compatible: should be a board-specific string followed by a string
> +  indicating the type of FPGA.  Example:
> + "fsl,-fpga", "fsl,fpga-qixis"
> +- reg: should contain the address and the length of the FPGA register set.
> +
> +Example (LS2080A-RDB):
> +
> +cpld@3,0 {
> +compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
> +reg = <0x3 0 0x1>;
> +};
> +
> --
> 2.17.1

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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@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 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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@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: [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-dev@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: [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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@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: [PATCH v3 35/36] net/wan: make FSL_UCC_HDLC explicitly depend on PPC32

[Leo Li]

> -Original Message-
> From: Christophe Leroy 
> Sent: Friday, November 1, 2019 11:30 AM
> To: Rasmus Villemoes ; Qiang Zhao
> ; Leo Li 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Scott Wood ;
> net...@vger.kernel.org
> Subject: Re: [PATCH v3 35/36] net/wan: make FSL_UCC_HDLC explicitly
> depend on PPC32
> 
> 
> 
> Le 01/11/2019 à 13:42, Rasmus Villemoes a écrit :
> > Currently, FSL_UCC_HDLC depends on QUICC_ENGINE, which in turn
> depends
> > on PPC32. As preparation for removing the latter and thus allowing the
> > core QE code to be built for other architectures, make FSL_UCC_HDLC
> > explicitly depend on PPC32.
> 
> Is that really powerpc specific ? Can't the ARM QE perform HDLC on UCC ?

No.  Actually the HDLC and TDM are the major reason to integrate a QE on the 
ARM based Layerscape SoCs.

Since Rasmus doesn't have the hardware to test this feature Qiang Zhao probably 
can help verify the functionality of TDM and we can drop this patch.

Regards,
Leo

> 
> Christophe
> 
> >
> > Signed-off-by: Rasmus Villemoes 
> > ---
> >   drivers/net/wan/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig index
> > dd1a147f2971..78785d790bcc 100644
> > --- a/drivers/net/wan/Kconfig
> > +++ b/drivers/net/wan/Kconfig
> > @@ -270,7 +270,7 @@ config FARSYNC
> >   config FSL_UCC_HDLC
> > tristate "Freescale QUICC Engine HDLC support"
> > depends on HDLC
> > -   depends on QUICC_ENGINE
> > +   depends on QUICC_ENGINE && PPC32
> > help
> >   Driver for Freescale QUICC Engine HDLC controller. The driver
> >   supports HDLC in NMSI and TDM mode.
> >

RE: [PATCH v2 20/23] serial: make SERIAL_QE depend on PPC32

[Leo Li]

> -Original Message-
> From: Rasmus Villemoes 
> Sent: Friday, October 25, 2019 7:41 AM
> To: Qiang Zhao ; Leo Li ;
> Christophe Leroy 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Scott Wood ; Valentin
> Longchamp ; Rasmus Villemoes
> ; linux-ser...@vger.kernel.org
> Subject: [PATCH v2 20/23] serial: make SERIAL_QE depend on PPC32
> 
> Currently SERIAL_QE depends on QUICC_ENGINE, which in turn depends on
> PPC32, so this doesn't add any extra dependency. However, the QUICC
> Engine IP block also exists on some arm boards, so this serves as preparation
> for removing the PPC32 dependency from QUICC_ENGINE and build the QE
> support in drivers/soc/fsl/qe, while preventing allmodconfig/randconfig
> failures due to SERIAL_QE not being supported yet.
> 
> Signed-off-by: Rasmus Villemoes 

I think your purpose of this series is to make the QE UART not depending on 
PPC32.  If it does accomplish that then we don't need this change.

> ---
>  drivers/tty/serial/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index
> 67a9eb3f94ce..78246f535809 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1056,6 +1056,7 @@ config SERIAL_LANTIQ  config SERIAL_QE
>   tristate "Freescale QUICC Engine serial port support"
>   depends on QUICC_ENGINE
> + depends on PPC32
>   select SERIAL_CORE
>   select FW_LOADER
>   help
> --
> 2.23.0

RE: [PATCH v9 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

[Leo Li]

> -Original Message-
> From: Ran Wang 
> Sent: Wednesday, October 23, 2019 4:53 AM
> To: Rafael J. Wysocki 
> Cc: Rafael J . Wysocki ; Rob Herring
> ; Leo Li ; Mark Rutland
> ; Pavel Machek ; Anson Huang
> ; Biwen Li ; Len Brown
> ; Greg Kroah-Hartman
> ; linuxppc-dev  d...@lists.ozlabs.org>; Linux ARM ;
> devicet...@vger.kernel.org; Linux Kernel Mailing List  ker...@vger.kernel.org>; Linux PM 
> Subject: RE: [PATCH v9 1/3] PM: wakeup: Add routine to help fetch wakeup
> source object.
> 
> Hi Rafael,
> 
> On Wednesday, October 23, 2019 17:07, Rafael J. Wysocki wrote:
> >
> > On Wed, Oct 23, 2019 at 10:24 AM Ran Wang 
> wrote:
> > >
> > > Some user might want to go through all registered wakeup sources and
> > > doing things accordingly. For example, SoC PM driver might need to
> > > do HW programming to prevent powering down specific IP which wakeup
> > > source depending on. So add this API to help walk through all
> > > registered wakeup source objects on that list and return them one by
> one.
> > >
> > > Signed-off-by: Ran Wang 
> > > Tested-by: Leonard Crestez 
> >
> > OK, thanks for making all of the requested changes:
> 
> Thanks for your patient direction :)
> Actually Leo and me planed to have a f2f discussion with you about this patch
> on LPC 2019 but unfortunately missed the opportunity finally (v6 review was
> pending at time).
> 
> > Reviewed-by: Rafael J. Wysocki 

Thanks for the review.

> >
> > and please feel free to push this through the appropriate arch/platform
> tree.
> 
> Yes, we will do this later.
> 
> > Alternatively, please let me know if you want me to take this series,
> > but then I need an ACK from the appropriate
> > maintainer(s) on patch 3.
> 
> Thanks again, I will wait Leo's comment on patch 3.

I will do another review on patch 3 and apply the series through my soc/fsl 
tree.

Regards,
Leo

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 v6 44/49] net/wan/fsl_ucc_hdlc: avoid use of IS_ERR_VALUE()

[Leo Li]

> -Original Message-
> From: Rasmus Villemoes 
> Sent: Thursday, November 28, 2019 8:56 AM
> To: Qiang Zhao ; Leo Li ;
> Christophe Leroy 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Scott Wood ; Timur Tabi
> ; Rasmus Villemoes ;
> net...@vger.kernel.org
> Subject: [PATCH v6 44/49] net/wan/fsl_ucc_hdlc: avoid use of
> IS_ERR_VALUE()

Hi David,

Would you help to review patch 44-47 in the series?  If it is fine with you, I 
can take these 4 patches with the whole series though soc tree to enable the QE 
drivers on ARM and PPC64 with your ACK.

Thanks,
Leo

> 
> When building this on a 64-bit platform gcc rightly warns that the error
> checking is broken (-ENOMEM stored in an u32 does not compare greater
> than (unsigned long)-MAX_ERRNO). Instead, now that
> qe_muram_alloc() returns s32, use that type to store the return value and
> use standard kernel style "ret < 0".
> 
> Reviewed-by: Timur Tabi 
> Signed-off-by: Rasmus Villemoes 

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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@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:47 PM
> To: Leo Li ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@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:13 PM
> To: Leo Li ; shawn...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Ran Wang
> 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@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: [PATCH] serial: cpm_uart: call cpm_muram_init before registering console

[Leo Li]

> -Original Message-
> From: Rasmus Villemoes 
> Sent: Thursday, February 13, 2020 5:44 AM
> To: Greg Kroah-Hartman ; Jiri Slaby
> ; Timur Tabi ; Leo Li
> ; Rasmus Villemoes 
> Cc: Qiang Zhao ; linuxppc-dev@lists.ozlabs.org; Scott
> Wood ; Christophe Leroy ;
> linux-ser...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] serial: cpm_uart: call cpm_muram_init before registering
> console
> 
> Christophe reports that powerpc 8xx silently fails to 5.6-rc1. It turns out I 
> was
> wrong about nobody relying on the lazy initialization of the cpm/qe muram in
> commit b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of
> cpm_muram_init()).
> 
> Rather than reinstating the somewhat dubious lazy call (initializing a 
> currently
> held spinlock, and implicitly doing a GFP_KERNEL under that spinlock), make
> sure that cpm_muram_init() is called early enough - I thought the calls from
> the subsys_initcalls were good enough, but when used by console drivers,
> that's obviously not the case. cpm_muram_init() is safe to call twice (there's
> an early return if it is already initialized), so keep the call from 
> cpm_init() - in
> case SERIAL_CPM_CONSOLE=n.
> 
> Reported-by: Christophe Leroy 
> Fixes: b6231ea2b3c6 (soc: fsl: qe: drop broken lazy call of cpm_muram_init())
> Signed-off-by: Rasmus Villemoes 

Acked-by: Li Yang 

> ---
> 
> Christophe, can I get you to add a formal Tested-by?
> 
> I'm not sure which tree this should go through.
> 
>  drivers/tty/serial/cpm_uart/cpm_uart_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> index 19d5a4cf29a6..d4b81b06e0cb 100644
> --- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> @@ -1373,6 +1373,7 @@ static struct console cpm_scc_uart_console = {
> 
>  static int __init cpm_uart_console_init(void)  {
> + cpm_muram_init();
>   register_console(_scc_uart_console);
>   return 0;
>  }
> --
> 2.23.0

RE: [PATCH 0/3] soc: fsl: dpio: Enable QMAN batch enqueuing

[Leo Li]

> -Original Message-
> From: Roy Pledge (OSS) 
> Sent: Thursday, February 6, 2020 2:40 PM
> To: Youri Querry ; Roy Pledge
> ; Leo Li ; linux-
> ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; Ioana Ciornei ;
> Alexandru Marginean 
> Subject: Re: [PATCH 0/3] soc: fsl: dpio: Enable QMAN batch enqueuing
> 
> On 12/12/2019 12:01 PM, Youri Querry wrote:
> > This patch set consists of:
> > - We added an interface to enqueue several packets at a time and
> >improve performance.
> > - Make the algorithm decisions once at initialization and use
> >function pointers to improve performance.
> > - Replaced the QMAN enqueue array mode algorithm with a ring
> >mode algorithm. This is to make the enqueue of several frames
> >at a time more effective.
> >
> > Youri Querry (3):
> >soc: fsl: dpio: Adding QMAN multiple enqueue interface.
> >soc: fsl: dpio: QMAN performance improvement. Function pointer
> >  indirection.
> >soc: fsl: dpio: Replace QMAN array mode by ring mode enqueue.
> >
> >   drivers/soc/fsl/dpio/dpio-service.c |  69 +++-
> >   drivers/soc/fsl/dpio/qbman-portal.c | 766
> 
> >   drivers/soc/fsl/dpio/qbman-portal.h | 158 +++-
> >   include/soc/fsl/dpaa2-io.h  |   6 +-
> >   4 files changed, 907 insertions(+), 92 deletions(-)
> >
> Acked-by: Roy Pledge 
> 
> Leo - can you look at this series so we can get it integrated? Thanks

Sure.  Thanks for the review.  I will queue them up for v5.7.

Regards,
Leo

RE: [PATCH][next] soc: fsl: dpio: fix dereference of pointer p before null check

[Leo Li]

> -Original Message-
> From: Colin King 
> Sent: Friday, February 21, 2020 5:12 PM
> To: Roy Pledge ; Leo Li ; Youri
> Querry ; linuxppc-dev@lists.ozlabs.org; linux-
> arm-ker...@lists.infradead.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH][next] soc: fsl: dpio: fix dereference of pointer p before 
> null
> check
> 
> From: Colin Ian King 
> 
> Pointer p is currently being dereferenced before it is null checked on a
> memory allocation failure check. Fix this by checking if p is null before
> dereferencing it.
> 
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with ring
> mode enqueue")
> Signed-off-by: Colin Ian King 

Applied for next.  Thanks.

> ---
>  drivers/soc/fsl/dpio/qbman-portal.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/fsl/dpio/qbman-portal.c
> b/drivers/soc/fsl/dpio/qbman-portal.c
> index 740ee0d19582..d1f49caa5b13 100644
> --- a/drivers/soc/fsl/dpio/qbman-portal.c
> +++ b/drivers/soc/fsl/dpio/qbman-portal.c
> @@ -249,10 +249,11 @@ struct qbman_swp *qbman_swp_init(const struct
> qbman_swp_desc *d)
>   u32 mask_size;
>   u32 eqcr_pi;
> 
> - spin_lock_init(>access_spinlock);
> -
>   if (!p)
>   return NULL;
> +
> + spin_lock_init(>access_spinlock);
> +
>   p->desc = d;
>   p->mc.valid_bit = QB_VALID_BIT;
>   p->sdq = 0;
> --
> 2.25.0

RE: [PATCH] soc: fsl: Remove bogus packed attributes from qman.h

[Leo Li]

> -Original Message-
> From: Herbert Xu 
> Sent: Thursday, July 30, 2020 7:53 AM
> To: Leo Li ; linuxppc-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org
> Subject: [PATCH] soc: fsl: Remove bogus packed attributes from qman.h
> 
> There are two __packed attributes in qman.h that are both unnecessary
> and causing compiler warnings because they're conflicting with
> explicit alignment requirements set on members within the structure.

Sorry for the late response.  I missed this email previously.

These structures are descriptors used by hardware, we cannot have _ANY_ padding 
from the compiler.  The compiled result might be the same with or without the 
__packed attribute for now, but I think keep it there probably is safer for 
dealing with unexpected alignment requirements from the compiler in the future.

Having conflicting alignment requirements warning might means something is 
wrong with the structure in certain scenario.  I just tried a ARM64 build but 
didn't see the warnings.  Could you share the warning you got and the build 
setup?  Thanks.

Regards,
Leo 
> 
> This patch removes them both.
> 
> Signed-off-by: Herbert Xu 
> 
> diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
> index cfe00e08e85b..d81ff185dc0b 100644
> --- a/include/soc/fsl/qman.h
> +++ b/include/soc/fsl/qman.h
> @@ -256,7 +256,7 @@ struct qm_dqrr_entry {
>   __be32 context_b;
>   struct qm_fd fd;
>   u8 __reserved4[32];
> -} __packed;
> +};
>  #define QM_DQRR_VERB_VBIT0x80
>  #define QM_DQRR_VERB_MASK0x7f/* where the verb
> contains; */
>  #define QM_DQRR_VERB_FRAME_DEQUEUE   0x60/* "this format" */
> @@ -289,7 +289,7 @@ union qm_mr_entry {
>   __be32 tag;
>   struct qm_fd fd;
>   u8 __reserved1[32];
> - } __packed ern;
> + } ern;
>   struct {
>   u8 verb;
>   u8 fqs; /* Frame Queue Status */
> --
> Email: Herbert Xu 
> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fdata=02%7C01%7Cleoyang.li%40nxp.com
> %7Cb69aca8dc53a4030b14b08d8348783a9%7C686ea1d3bc2b4c6fa92cd99c5c3
> 01635%7C0%7C0%7C637317103931120730sdata=g3%2FJfa%2FNcuhLD5
> SYhbmhno65O1bxisVt2xltu2IMPjQ%3Dreserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txtdata=02%7C01%7Cleoyang.li%4
> 0nxp.com%7Cb69aca8dc53a4030b14b08d8348783a9%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C637317103931120730sdata=uSS2C4cuAL
> XcCgIhpIORK4EZ1BHHj%2BqAW2Pu%2FLrFKPM%3Dreserved=0

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: [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-ker...@vger.kernel.org; linuxppc-dev@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-ker...@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-ker...@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 v2] usb: gadget: fsl: Fix unsigned expression compared with zero in fsl_udc_probe

[Leo Li]

> -Original Message-
> From: Ye Bin 
> Sent: Monday, August 24, 2020 3:43 AM
> To: Leo Li ; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Cc: Ye Bin 
> Subject: [PATCH v2] usb: gadget: fsl: Fix unsigned expression compared with
> zero in fsl_udc_probe
> 
> udc_controller->irq is "unsigned int" always >= 0, but platform_get_irq may
> return little than zero. So "dc_controller->irq < 0" condition is never
> accessible.
> 
> Signed-off-by: Ye Bin 

Acked-by: Li Yang 

> ---
>  drivers/usb/gadget/udc/fsl_udc_core.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
> b/drivers/usb/gadget/udc/fsl_udc_core.c
> index a6f7b2594c09..3e98740b8cfc 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2439,11 +2439,12 @@ static int fsl_udc_probe(struct platform_device
> *pdev)
>   /* DEN is bidirectional ep number, max_ep doubles the number */
>   udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK)
> * 2;
> 
> - udc_controller->irq = platform_get_irq(pdev, 0);
> - if (udc_controller->irq <= 0) {
> - ret = udc_controller->irq ? : -ENODEV;
> + ret = platform_get_irq(pdev, 0);
> + if (ret <= 0) {
> + ret = ret ? : -ENODEV;
>   goto err_iounmap;
>   }
> + udc_controller->irq = ret;
> 
>   ret = request_irq(udc_controller->irq, fsl_udc_irq, IRQF_SHARED,
>   driver_name, udc_controller);
> --
> 2.25.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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@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 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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@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 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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@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 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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@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 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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@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 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-ker...@vger.kernel.org;
> Qiang Zhao ; Leo Li ; Scott
> Wood ; act ; Dan Malek
> ; Software, Inc ; Vitaly
> Bordug ; linuxppc-dev@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-dev@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] usb: gadget: fsl: properly remove remnant of MXC support

[Leo Li]

> -Original Message-
> From: Joel Stanley 
> Sent: Monday, June 14, 2021 8:52 PM
> To: Leo Li 
> Cc: Felipe Balbi ; Greg Kroah-Hartman
> ; linux-...@vger.kernel.org; linuxppc-dev
> ; Linux Kernel Mailing List  ker...@vger.kernel.org>; Arnd Bergmann ; Ran Wang
> ; Fabio Estevam 
> Subject: Re: [PATCH] usb: gadget: fsl: properly remove remnant of MXC
> support
> 
> On Sat, 12 Jun 2021 at 00:31, Li Yang  wrote:
> >
> > Commit a390bef7db1f ("usb: gadget: fsl_mxc_udc: Remove the driver")
> > didn't remove all the MXC related stuff which can cause build problem
> > for LS1021 when enabled again in Kconfig.  This patch remove all the
> > remnants.
> >
> > Signed-off-by: Li Yang 
> 
> Reviewed-by: Joel Stanley 
> 
> Will you re-submit the kconfig change once this is merged?

I think that we can re-use your previous patch.

Hi Greg,

Can you apply the reverted Kconfig patch again?  Or do you prefer us to 
re-submit it again?

Regards,
Leo

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 -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-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@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 v4] soc: fsl: qe: convert QE interrupt controller to platform_device

[Leo Li]

> -Original Message-
> From: Maxim Kochetkov 
> Sent: Tuesday, August 3, 2021 6:36 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Qiang Zhao ; Leo Li ;
> gre...@linuxfoundation.org; sarava...@google.com; linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Maxim Kochetkov
> ; kernel test robot ; Dan Carpenter
> 
> Subject: [PATCH v4] soc: fsl: qe: convert QE interrupt controller to
> platform_device
> 
> Since 5.13 QE's ucc nodes can't get interrupts from devicetree:
> 
>   ucc@2000 {
>   cell-index = <1>;
>   reg = <0x2000 0x200>;
>   interrupts = <32>;
>   interrupt-parent = <>;
>   };
> 
> Now fw_devlink expects driver to create and probe a struct device for
> interrupt controller.
> 
> So lets convert this driver to simple platform_device with probe().
> Also use platform_get_ and devm_ family function to get/allocate resources
> and drop unused .compatible = "qeic".
> 
> [1] -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Flkml%2FCAGETcx9PiX%3D%3DmLxB9PO8Myyk6u2vhPVwTMsA
> 5NkD-
> ywH5xhusw%40mail.gmail.comdata=04%7C01%7Cleoyang.li%40nxp.co
> m%7C1833b32e26de4ed7ef7908d956728eae%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C0%7C637635872281355718%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C1000sdata=HrivK73GYFAwygPz24JtO%2BTdkicCVYXOl3uywjOqS
> %2BA%3Dreserved=0
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by
> default""")
> Signed-off-by: Maxim Kochetkov 
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 

Applied to fix.  Thanks.

> ---
>  drivers/soc/fsl/qe/qe_ic.c | 75 ++
>  1 file changed, 44 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c index
> 3f711c1a0996..e710d554425d 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -404,41 +405,40 @@ static void qe_ic_cascade_muxed_mpic(struct
> irq_desc *desc)
>   chip->irq_eoi(>irq_data);
>  }
> 
> -static void __init qe_ic_init(struct device_node *node)
> +static int qe_ic_init(struct platform_device *pdev)
>  {
> + struct device *dev = >dev;
>   void (*low_handler)(struct irq_desc *desc);
>   void (*high_handler)(struct irq_desc *desc);
>   struct qe_ic *qe_ic;
> - struct resource res;
> - u32 ret;
> + struct resource *res;
> + struct device_node *node = pdev->dev.of_node;
> 
> - ret = of_address_to_resource(node, 0, );
> - if (ret)
> - return;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL) {
> + dev_err(dev, "no memory resource defined\n");
> + return -ENODEV;
> + }
> 
> - qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
> + qe_ic = devm_kzalloc(dev, sizeof(*qe_ic), GFP_KERNEL);
>   if (qe_ic == NULL)
> - return;
> + return -ENOMEM;
> 
> - qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
> -_ic_host_ops, qe_ic);
> - if (qe_ic->irqhost == NULL) {
> - kfree(qe_ic);
> - return;
> + qe_ic->regs = devm_ioremap(dev, res->start, resource_size(res));
> + if (qe_ic->regs == NULL) {
> + dev_err(dev, "failed to ioremap() registers\n");
> + return -ENODEV;
>   }
> 
> - qe_ic->regs = ioremap(res.start, resource_size());
> -
>   qe_ic->hc_irq = qe_ic_irq_chip;
> 
> - qe_ic->virq_high = irq_of_parse_and_map(node, 0);
> - qe_ic->virq_low = irq_of_parse_and_map(node, 1);
> + qe_ic->virq_high = platform_get_irq(pdev, 0);
> + qe_ic->virq_low = platform_get_irq(pdev, 1);
> 
> - if (!qe_ic->virq_low) {
> - printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
> - kfree(qe_ic);
> - return;
> + if (qe_ic->virq_low < 0) {
> + return -ENODEV;
>   }
> +
>   if (qe_ic->virq_high != qe_ic->virq_low) {
>   low_handler = qe_ic_cascade_low;
>   high_handler = qe_ic_cascade_high;
> @@ -447,6 +447,13 @@ static void __init qe_ic_init(struct

RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund 
> Sent: Thursday, December 2, 2021 4:45 PM
> To: regressi...@leemhuis.info; Leo Li ;
> eugene_bordenkirc...@selinc.com; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Cc: gre...@linuxfoundation.org; ba...@kernel.org
> Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to
> unrecoverable loop.
> 
> On Thu, 2021-12-02 at 20:35 +, Leo Li wrote:
> >
> > > -Original Message-
> > > From: Joakim Tjernlund 
> > > Sent: Wednesday, December 1, 2021 8:19 AM
> > > To: regressi...@leemhuis.info; Leo Li ;
> > > eugene_bordenkirc...@selinc.com; linux-...@vger.kernel.org;
> > > linuxppc- d...@lists.ozlabs.org
> > > Cc: gre...@linuxfoundation.org; ba...@kernel.org
> > > Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list
> > > leads to unrecoverable loop.
> > >
> > > On Tue, 2021-11-30 at 12:56 +0100, Joakim Tjernlund wrote:
> > > > On Mon, 2021-11-29 at 23:48 +, Eugene Bordenkircher wrote:
> > > > > Agreed,
> > > > >
> > > > > We are happy pick up the torch on this, but I'd like to try and
> > > > > hear from
> > > Joakim first before we do.  The patch set is his, so I'd like to
> > > give him the opportunity.  I think he's the only one that can add a
> > > truly proper description as well because he mentioned that this
> > > includes a "few more fixes" than just the one we ran into.  I'd
> > > rather hear from him than try to reverse engineer what was being
> addressed.
> > > > >
> > > > > Joakim, if you are still watching the thread, would you like to
> > > > > take a stab
> > > at it?  If I don't hear from you in a couple days, we'll pick up the
> > > torch and do what we can.
> > > > >
> > > >
> > > > I am far away from this now and still on 4.19. I don't mind if you
> > > > tweak
> > > tweak the patches for better "upstreamability"
> > >
> > > Even better would be to migrate to the chipidea driver, I am told
> > > just a few tweaks are needed but this is probably something NXP
> > > should do as they have access to other SOC's using chipidea.
> >
> > I agree with this direction but the problem was with bandwidth.  As this
> controller was only used on legacy platforms, it is harder to justify new 
> effort
> on it now.
> >
> 
> Legacy? All PPC is legacy and not supported now?

I'm not saying that they are not supported, but they are in maintenance only 
mode.

Regards,
Leo

RE: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary inclusions

[Leo Li]

> -Original Message-
> From: Andy Shevchenko 
> Sent: Monday, November 15, 2021 5:30 AM
> To: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Leo Li ; Qiang Zhao 
> Subject: Re: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary
> inclusions
> 
> On Wed, Nov 10, 2021 at 12:59:52PM +0200, Andy Shevchenko wrote:
> > When kernel.h is used in the headers it adds a lot into dependency
> > hell, especially when there are circular dependencies are involved.
> >
> > Replace kernel.h inclusion with the list of what is really being used.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: updated Cc list based on previous changes to MAINTAINERS
> 
> Any comments on this, please?
> 
> I really want to decrease amount of kernel.h usage in the common headers.
> So others won't copy'n'paste bad example.

There seems to be no problem with the patch although I didn't get time to 
really compile with it applied.

Will pick them up later after build test.

Regards,
Leo

RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.

[Leo Li]

> -Original Message-
> From: Eugene Bordenkircher 
> Sent: Monday, November 29, 2021 11:25 AM
> To: Thorsten Leemhuis ; jo...@infinera.com
> ; linuxppc-dev@lists.ozlabs.org; linux-
> u...@vger.kernel.org
> Cc: Leo Li ; gre...@linuxfoundation.org;
> ba...@kernel.org
> Subject: RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to
> unrecoverable loop.
> 
> The final result of our testing is that the patch set posted seems to address 
> all
> known defects in the Linux kernel.  The mentioned additional problems are
> entirely caused by the antivirus solution on the windows box.  The antivirus
> solution blocks the disconnect messages from reaching the RNDIS driver so it
> has no idea the USB device went away.  There is nothing we can do to
> address this in the Linux kernel.

Thanks for the confirmation.

> 
> I propose we move forward with the patchset.

I think that we should proceed to merge the patchset but it seems to need some 
cleanup for coding style issues and better description before submitted 
formally.

> 
> Eugene T. Bordenkircher
> 
> -Original Message-
> From: Thorsten Leemhuis 
> Sent: Thursday, November 25, 2021 5:59 AM
> To: Eugene Bordenkircher ; Thorsten
> Leemhuis ; Joakim Tjernlund
> ; linuxppc-dev@lists.ozlabs.org; linux-
> u...@vger.kernel.org
> Cc: leoyang...@nxp.com; gre...@linuxfoundation.org; ba...@kernel.org
> Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to
> unrecoverable loop.
> 
> Hi, this is your Linux kernel regression tracker speaking.
> 
> Top-posting for once, to make this easy to process for everyone:
> 
> Li Yang and Felipe Balbi: how to move on with this? It's quite an old
> regression, but nevertheless it is one and thus should be fixed. Part of my
> position is to make that happen and thus remind developers and maintainers
> about this until the regression is resolved.
> 
> Ciao, Thorsten
> 
> On 16.11.21 20:11, Eugene Bordenkircher wrote:
> > On 02.11.21 22:15, Joakim Tjernlund wrote:
> >> On Sat, 2021-10-30 at 14:20 +, Joakim Tjernlund wrote:
> >>> On Fri, 2021-10-29 at 17:14 +, Eugene Bordenkircher wrote:
> >>
> >>>> We've discovered a situation where the FSL udc driver
> (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the
> request queue, but the queue has been corrupted at some point so it loops
> infinitely.  I believe we have narrowed into the offending code, but we are in
> need of assistance trying to find an appropriate fix for the problem.  The
> identified code appears to be in all versions of the Linux kernel the driver
> exists in.
> >>>>
> >>>> The problem appears to be when handling a USB_REQ_GET_STATUS
> request.  The driver gets this request and then calls the ch9getstatus()
> function.  In this function, it starts a request by "borrowing" the per device
> status_req, filling it in, and then queuing it with a call to list_add_tail() 
> to add
> the request to the endpoint queue.  Right before it exits the function
> however, it's calling ep0_prime_status(), which is filling out that same
> status_req structure and then queuing it with another call to list_add_tail() 
> to
> add the request to the endpoint queue.  This adds two instances of the exact
> same LIST_HEAD to the endpoint queue, which breaks the list since the prev
> and next pointers end up pointing to the wrong things.  This ends up causing
> a hard loop the next time nuke() gets called, which happens on the next
> setup IRQ.
> >>>>
> >>>> I'm not sure what the appropriate fix to this problem is, mostly due to
> my lack of expertise in USB and this driver stack.  The code has been this way
> in the kernel for a very long time, which suggests that it has been working,
> unless USB_REQ_GET_STATUS requests are never made.  This further
> suggests that there is something else going on that I don't understand.
> Deleting the call to ep0_prime_status() and the following ep0stall() call
> appears, on the surface, to get the device working again, but may have side
> effects that I'm not seeing.
> >>>>
> >>>> I'm hopeful someone in the community can help provide some
> information on what I may be missing or help come up with a solution to the
> problem.  A big thank you to anyone who would like to help out.
> >>>
> >>> Run into this to a while ago. Found the bug and a few more fixes.
> >>> This is against 4.19 so you may have to tweak them a bit.
> >>> Feel free to upstream them.
> >>
> >> Curious, did my patches help? Good to known once we upgrade as well.
> >

RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.

[Leo Li]

> -Original Message-
> From: Joakim Tjernlund 
> Sent: Wednesday, December 1, 2021 8:19 AM
> To: regressi...@leemhuis.info; Leo Li ;
> eugene_bordenkirc...@selinc.com; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Cc: gre...@linuxfoundation.org; ba...@kernel.org
> Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to
> unrecoverable loop.
> 
> On Tue, 2021-11-30 at 12:56 +0100, Joakim Tjernlund wrote:
> > On Mon, 2021-11-29 at 23:48 +, Eugene Bordenkircher wrote:
> > > Agreed,
> > >
> > > We are happy pick up the torch on this, but I'd like to try and hear from
> Joakim first before we do.  The patch set is his, so I'd like to give him the
> opportunity.  I think he's the only one that can add a truly proper 
> description
> as well because he mentioned that this includes a "few more fixes" than just
> the one we ran into.  I'd rather hear from him than try to reverse engineer
> what was being addressed.
> > >
> > > Joakim, if you are still watching the thread, would you like to take a 
> > > stab
> at it?  If I don't hear from you in a couple days, we'll pick up the torch 
> and do
> what we can.
> > >
> >
> > I am far away from this now and still on 4.19. I don't mind if you tweak
> tweak the patches for better "upstreamability"
> 
> Even better would be to migrate to the chipidea driver, I am told just a few
> tweaks are needed but this is probably something NXP should do as they
> have access to other SOC's using chipidea.

I agree with this direction but the problem was with bandwidth.  As this 
controller was only used on legacy platforms, it is harder to justify new 
effort on it now.

Regards,
Leo

RE: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary inclusions

[Leo Li]

> -Original Message-
> From: Andy Shevchenko 
> Sent: Thursday, December 2, 2021 3:33 AM
> To: Leo Li 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Qiang Zhao 
> Subject: Re: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary
> inclusions
> 
> On Wed, Dec 01, 2021 at 01:41:16PM -0600, Li Yang wrote:
> > On Tue, Nov 23, 2021 at 10:32 AM Andy Shevchenko
> >  wrote:
> > >
> > > On Tue, Nov 16, 2021 at 11:38:01AM +0200, Andy Shevchenko wrote:
> > > > On Mon, Nov 15, 2021 at 10:24:36PM +, Leo Li wrote:
> > > > > > From: Andy Shevchenko 
> > > > > > Sent: Monday, November 15, 2021 5:30 AM On Wed, Nov 10, 2021
> > > > > > at 12:59:52PM +0200, Andy Shevchenko wrote:
> > > >
> > > > ...
> > > >
> > > > > > > v2: updated Cc list based on previous changes to MAINTAINERS
> > > > > >
> > > > > > Any comments on this, please?
> > > > > >
> > > > > > I really want to decrease amount of kernel.h usage in the common
> headers.
> > > > > > So others won't copy'n'paste bad example.
> > > > >
> > > > > There seems to be no problem with the patch although I didn't get
> time to really compile with it applied.
> > > > >
> > > > > Will pick them up later after build test.
> > > >
> > > > Thank you!
> > > >
> > > > Note, it has two fixes against MAINTAINERS which may be sent, I
> > > > believe, sooner than later to Linus.
> > >
> > > Any new so far?
> >
> > The build test is good.  I have applied it for next.  Thanks.
> 
> Thanks, what about MAINTAINERS updates? I don't see them neither in next
> nor in your tree.

I am ok with these MAINTAINERS updates.  I thought you want to send them 
directly to Linus.  I can take them if you like.

Regards,
Leo

RE: [PATCH v3] soc: fsl: qe: convert QE interrupt controller to platform_device

[Leo Li]

> -Original Message-
> From: Maxim Kochetkov 
> Sent: Monday, July 26, 2021 12:22 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
> sarava...@google.com; Leo Li ; Qiang Zhao
> ; gre...@linuxfoundation.org; Maxim Kochetkov
> ; kernel test robot ; Dan Carpenter
> 
> Subject: [PATCH v3] soc: fsl: qe: convert QE interrupt controller to
> platform_device
> 
> Since 5.13 QE's ucc nodes can't get interrupts from devicetree:
> 
>   ucc@2000 {
>   cell-index = <1>;
>   reg = <0x2000 0x200>;
>   interrupts = <32>;
>   interrupt-parent = <>;
>   };
> 
> Now fw_devlink expects driver to create and probe a struct device for
> interrupt controller.
> 
> So lets convert this driver to simple platform_device with probe().
> Also use platform_get_ and devm_ family function to get/allocate resources
> and drop unused .compatible = "qeic".
> 
> [1] -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Flkml%2FCAGETcx9PiX%3D%3DmLxB9PO8Myyk6u2vhPVwTMsA
> 5NkD-
> ywH5xhusw%40mail.gmail.comdata=04%7C01%7Cleoyang.li%40nxp.co
> m%7C6e64e4b86f2d4a89390808d94ff50bec%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637628736153046082%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C1000sdata=G7HhGFmRLvMyNMULSddWctD3HhtVWMfZAxPXjl8
> CBTY%3Dreserved=0
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by
> default""")
> Signed-off-by: Maxim Kochetkov 
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 
> ---
> Changes in v3:
>  - use .compatible = "qeic" again (Li Yang  asks to keep
> it)
> 
> Changes in v2:
>  - use devm_ family functions to allocate mem/resources
>  - use platform_get_ family functions to get resources/irqs
>  - drop unused .compatible = "qeic"
> 
>  drivers/soc/fsl/qe/qe_ic.c | 75 ++
>  1 file changed, 44 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c index
> 3f711c1a0996..54cabd2605dd 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -404,41 +405,40 @@ static void qe_ic_cascade_muxed_mpic(struct
> irq_desc *desc)
>   chip->irq_eoi(>irq_data);
>  }
> 
> -static void __init qe_ic_init(struct device_node *node)
> +static int qe_ic_init(struct platform_device *pdev)
>  {
> + struct device *dev = >dev;
>   void (*low_handler)(struct irq_desc *desc);
>   void (*high_handler)(struct irq_desc *desc);
>   struct qe_ic *qe_ic;
> - struct resource res;
> - u32 ret;
> + struct resource *res;
> + struct device_node *node = pdev->dev.of_node;
> 
> - ret = of_address_to_resource(node, 0, );
> - if (ret)
> - return;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL) {
> + dev_err(dev, "no memory resource defined\n");
> + return -ENODEV;
> + }
> 
> - qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
> + qe_ic = devm_kzalloc(dev, sizeof(*qe_ic), GFP_KERNEL);
>   if (qe_ic == NULL)
> - return;
> + return -ENOMEM;
> 
> - qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
> -_ic_host_ops, qe_ic);
> - if (qe_ic->irqhost == NULL) {
> - kfree(qe_ic);
> - return;
> + qe_ic->regs = devm_ioremap(dev, res->start, resource_size(res));
> + if (qe_ic->regs == NULL) {
> + dev_err(dev, "failed to ioremap() registers\n");
> + return -ENODEV;
>   }
> 
> - qe_ic->regs = ioremap(res.start, resource_size());
> -
>   qe_ic->hc_irq = qe_ic_irq_chip;
> 
> - qe_ic->virq_high = irq_of_parse_and_map(node, 0);
> - qe_ic->virq_low = irq_of_parse_and_map(node, 1);
> + qe_ic->virq_high = platform_get_irq(pdev, 0);
> + qe_ic->virq_low = platform_get_irq(pdev, 1);
> 
> - if (!qe_ic->virq_low) {
> - printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
> - kfree(qe_ic);
> - return;
> + if (qe_ic->virq_low < 0) {
> + return -EN

RE: [PATCH RESEND v2 0/7] soc: fsl: guts: cleanups and serial_number support

[Leo Li]

> -Original Message-
> From: Shawn Guo 
> Sent: Monday, June 27, 2022 1:53 AM
> To: Michael Walle 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Leo Li ; Ulf Hansson
> ; Sudeep Holla ; Arnd
> Bergmann ; Dan Carpenter 
> Subject: Re: [PATCH RESEND v2 0/7] soc: fsl: guts: cleanups and
> serial_number support
> 
> On Wed, Jun 22, 2022 at 01:03:33PM +0200, Michael Walle wrote:
> > Am 2022-04-04 11:56, schrieb Michael Walle:
> > > [Resend because of new development cycle. Shawn, can this series get
> > > through your tree? Sorry you weren't on CC on the former
> > > submissions.]
> > >
> > > This series converts the guts driver from a platform driver to just
> > > an core_initcall. The driver itself cannot (or rather should never)
> > > be unloaded because others depends on detecting the current SoC
> > > revision to apply chip errata. Other SoC drivers do it the same way.
> > > Overall I got rid of all the global static variables.
> > >
> > > The last patch finally adds unique id support to the guts driver. DT
> > > binding can be found at:
> > >   Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
> > >
> > > changes since v1:
> > >  - call kfree() in error case, thanks Dan
> > >  - add missing of_node_put(np), thanks Dan
> > >
> > > Michael Walle (7):
> > >   soc: fsl: guts: machine variable might be unset
> > >   soc: fsl: guts: remove module_exit() and fsl_guts_remove()
> > >   soc: fsl: guts: embed fsl_guts_get_svr() in probe()
> > >   soc: fsl: guts: allocate soc_dev_attr on the heap
> > >   soc: fsl: guts: use of_root instead of own reference
> > >   soc: fsl: guts: drop platform driver
> > >   soc: fsl: guts: add serial_number support
> > >
> > >  drivers/soc/fsl/guts.c | 219
> > > ++---
> > >  1 file changed, 118 insertions(+), 101 deletions(-)
> >
> > There goes another kernel release without any comments on this series
> > :(
> >
> > Shawn, can you pick this up and give it some time in linux-next?
> 
> Okay, I just picked the series up to IMX tree.
> 
> Leo, let me know if you want to drop it from IMX tree.

No problem.  You can take these through your tree.  Thanks.

Regards,
Leo

RE: [PATCH v3 3/4] dt-bindings: interrupt-controller: fsl, ls-extirq: convert to YAML

[Leo Li]

> -Original Message-
> From: Michael Walle 
> Sent: Wednesday, April 27, 2022 2:54 AM
> To: Rob Herring ; Krzysztof Kozlowski
> 
> Cc: Leo Li ; Michael Walle ; Shawn
> Guo ; Thomas Gleixner ; Marc
> Zyngier ; linuxppc-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v3 3/4] dt-bindings: interrupt-controller: fsl,ls-extirq:
> convert to YAML
> 
> Convert the fsl,ls-extirq binding to the new YAML format.
> 
> In contrast to the original binding documentation, there are three
> compatibles which are used in their corresponding device trees which have a
> specific compatible and the (already documented) fallback
> compatible:
>  - "fsl,ls1046a-extirq", "fsl,ls1043a-extirq"
>  - "fsl,ls2080a-extirq", "fsl,ls1088a-extirq"
>  - "fsl,lx2160a-extirq", "fsl,ls1088a-extirq"
> 
> Depending on the number of the number of the external IRQs which is
> usually 12 except for the LS1021A where there are only 6, the interrupt-map-
> mask was reduced from 0x to 0xf and 0x7 respectively and the number
> of interrupt-map entries have to match.

I assume this change won't prevent driver to be compatible with older device 
trees using the 0x?  The original 0x should work for both 6/12 
interrupts or whatever reasonable number of interrupts that maybe used in 
future SoCs.  So the purpose of this change is to make the binding more 
specific to catch more errors in device tree?

> 
> Signed-off-by: Michael Walle 
> ---
> changes since v2:
>  - drop $ref to interrupt-controller.yaml
>  - use a more strict interrupt-map-mask and make it conditional on SoC
> 
> changes since v1:
>  - new patch
> 
>  .../interrupt-controller/fsl,ls-extirq.txt|  53 
>  .../interrupt-controller/fsl,ls-extirq.yaml   | 118 ++
>  2 files changed, 118 insertions(+), 53 deletions(-)  delete mode 100644
> Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
>  create mode 100644 Documentation/devicetree/bindings/interrupt-
> controller/fsl,ls-extirq.yaml
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-
> extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-
> extirq.txt
> deleted file mode 100644
> index 4d47df1a5c91..
> --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-
> extirq.txt
> +++ /dev/null
> @@ -1,53 +0,0 @@
> -* Freescale Layerscape external IRQs
> -
> -Some Layerscape SOCs (LS1021A, LS1043A, LS1046A -LS1088A, LS208xA,
> LX216xA) support inverting -the polarity of certain external interrupt lines.
> -
> -The device node must be a child of the node representing the -
> Supplemental Configuration Unit (SCFG).
> -
> -Required properties:
> -- compatible: should be "fsl,-extirq", e.g. "fsl,ls1021a-extirq".
> -  "fsl,ls1043a-extirq": for LS1043A, LS1046A.
> -  "fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA.
> -- #interrupt-cells: Must be 2. The first element is the index of the
> -  external interrupt line. The second element is the trigger type.
> -- #address-cells: Must be 0.
> -- interrupt-controller: Identifies the node as an interrupt controller
> -- reg: Specifies the Interrupt Polarity Control Register (INTPCR) in
> -  the SCFG or the External Interrupt Control Register (IRQCR) in
> -  the ISC.
> -- interrupt-map: Specifies the mapping from external interrupts to GIC
> -  interrupts.
> -- interrupt-map-mask: Must be <0x 0>.
> -
> -Example:
> - scfg: scfg@157 {
> - compatible = "fsl,ls1021a-scfg", "syscon";
> - reg = <0x0 0x157 0x0 0x1>;
> - big-endian;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0x0 0x0 0x157 0x1>;
> -
> - extirq: interrupt-controller@1ac {
> - compatible = "fsl,ls1021a-extirq";
> - #interrupt-cells = <2>;
> - #address-cells = <0>;
> - interrupt-controller;
> - reg = <0x1ac 4>;
> - interrupt-map =
> - <0 0  GIC_SPI 163
> IRQ_TYPE_LEVEL_HIGH>,
> - <1 0  GIC_SPI 164
> IRQ_TYPE_LEVEL_HIGH>,
> - <2 0  GIC_SPI 165
> IRQ_TYPE_LEVEL_HIGH>,
> - <3 0  GIC_SPI 167
> IRQ_TYPE_LEVEL_HIGH>,
> - &l

RE: usb.c:undefined reference to `qe_immr'

[Leo Li]

> -Original Message-
> From: Christophe Leroy 
> Sent: Wednesday, January 11, 2023 1:43 PM
> To: Randy Dunlap ; Michael Ellerman
> ; kernel test robot ; Masahiro
> Yamada 
> Cc: Nicolas Schier ; linux-ker...@vger.kernel.org; Leo Li
> ; oe-kbuild-...@lists.linux.dev; linuxppc-dev
> ; Qiang Zhao 
> Subject: Re: usb.c:undefined reference to `qe_immr'
> 
> 
> 
> Le 11/01/2023 à 17:01, Randy Dunlap a écrit :
> >
> >
> > On 1/10/23 23:39, Michael Ellerman wrote:
> >> Randy Dunlap  writes:
> >>> [adding Cc's]
> >>>
> >>>
> >>> On 1/9/23 23:59, kernel test robot wrote:
> >>>> Hi Masahiro,
> >>>>
> >>>> FYI, the error/warning still remains.
> >>>>
> >>>> tree:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke
> rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git
> ata=05%7C01%7Cleoyang.li%40nxp.com%7Cd7f37490b9ad42174b0408daf40c
> 0376%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63809062972159
> 7124%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=uv8%2
> BzM6uKMc9VPSXwH60Hi4V27pIKvv7BPzAFA3GOK8%3D=0 master
> >>>> head:   5a41237ad1d4b62008f93163af1d9b1da90729d8
> >>>> commit: 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b kbuild: link
> symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
> >>>> date:   8 months ago
> >>>> config: powerpc-randconfig-r026-20230110
> >>>> compiler: powerpc-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1
> >>>> build):
> >>>>  wget
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.g
> ithubusercontent.com%2Fintel%2Flkp-
> tests%2Fmaster%2Fsbin%2Fmake.cross=05%7C01%7Cleoyang.li%40nx
> p.com%7Cd7f37490b9ad42174b0408daf40c0376%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C638090629721753373%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C=bZocY77aLRAMjD3F1ttgzm%2F2tW8JfhYf
> xq%2B6vxJh9Mc%3D=0 -O ~/bin/make.cross
> >>>>  chmod +x ~/bin/make.cross
> >>>>  #
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke
> rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2
> Fcommit%2F%3Fid%3D7b4537199a4a8480b8c3ba37a2d44765ce76cd9b=
> 05%7C01%7Cleoyang.li%40nxp.com%7Cd7f37490b9ad42174b0408daf40c0376
> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638090629721753373
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2F%2BX1fl
> KB1kjgv3wNK18Cu9uq6%2FUOr%2FCTjIsudBfiGho%3D=0
> >>>>  git remote add linus
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke
> rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git
> ata=05%7C01%7Cleoyang.li%40nxp.com%7Cd7f37490b9ad42174b0408daf40c
> 0376%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63809062972175
> 3373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BvI
> %2BGkvbol1aWLlg%2FAF12%2F44xZeN8U1c%2B0Y%2BvGCadt0%3D
> d=0
> >>>>  git fetch --no-tags linus master
> >>>>  git checkout 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b
> >>>>  # save the config file
> >>>>  mkdir build_dir && cp config build_dir/.config
> >>>>  COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0
> make.cross W=1 O=build_dir ARCH=powerpc olddefconfig
> >>>>  COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0
> >>>> make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash
> >>>>
> >>>> If you fix the issue, kindly add following tag where applicable
> >>>> | Reported-by: kernel test robot 
> >>>>
> >>>> All errors (new ones prefixed by >>):
> >>>>
> >>>> powerpc-linux-ld: powerpc-linux-ld: DWARF error: could not find
> abbrev number 74
> >>>> drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set':
> >>>>>> usb.c:(.text+0x1e): undefined reference to `qe_immr'
> >>>>>> powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to
> `qe_immr'
> >>>>>> powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to
> `qe_setbrg'
> >>>>>> powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to
> `cmxgcr_lock'
> >>>> powerp

RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

[Leo Li]

> -Original Message-
> From: Paul Gortmaker 
> Sent: Monday, February 20, 2023 5:59 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Leo Li ; Claudiu Manoil ;
> Paul Gortmaker ; Scott Wood
> ; Michael Ellerman ; Benjamin
> Herrenschmidt ; Paul Mackerras
> 
> Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
> 
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
> 
> This series removes support for four e300 (MPC83xx) Freescale processor
> family evaluation boards that were added to the kernel in the 2006 era.

Thanks.  Let me discuss this with our marketing team to see if they have any 
valid reason to keep them around.

> 
> These boards were all of a very similar form factor, a largish PCI or PCI-X 
> card
> that could also be used standalone with an external power brick, and all
> shared the Modular Development System (MDS) designation.
> 
> These platforms were made in limited quantity and were generally designed
> to get early silicon into the hands of OEMs who would later develop their
> own boards/platforms.  As such, availability was limited to those who would
> be working on boards and/or BSP support.
> 
> Many early revision MDS platforms used a mechanical clamping system to
> hold the BGA CPU in place to facilitate CPU updates -- something not
> normally possible for a soldered down BGA in a COTS system.
> 
> The point of these details is to give context that reflects that these four
> boards were made in limited quantities, were not in a form factor that is
> really "hobbyist" friendly and hence make sense for removal 17 years later.
> 
> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel.
> 
> There will still exist several e300 Freescale Reference Design System (RDS)
> boards[5] and mini-ITX boards[6] with support in the kernel.  While these
> were more of a COTS "ready to deploy" design more suited to hobbyists, it
> probably makes sense to consider removing these as well, based on age.
> 
> But before we get to that, lets see how this goes -- and then we should look
> at similar early e500 evaluation platforms [MPC8540-ADS, etc] next, as the
> oldest there date back to 2002[7] -- before considering RDB/mITX.
> 
> I intentionally didn't put any links in the commits, since as we all know, 
> they
> tend not to be stable long term, so keep them here in the merge data.
> Credit to NXP for keeping around these old legacy docs this long!
> 
> Paul.
> 
> --
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fdesign%2Fqoriq-developer-resources%2Fmpc8349e-modular-
> development-
> system%3AMPC8349EMDS=05%7C01%7Cleoyang.li%40nxp.com%7Ca2
> 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C=Q4COgwpjsE4mHXvl9HdGo3otPCYML3z%2FR6IoCEYRE
> wg%3D=0
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fdocs%2Fen%2Fuser-
> guide%2FMPC8360EMDSUM.pdf=05%7C01%7Cleoyang.li%40nxp.com
> %7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C=JyLT0MfGAHQ8a%2FNgpLdVFtyACkwPR%2FOkB
> yN1aW0wySs%3D=0
> [3]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu-
> mcus%2Fpowerquicc-processors%2Fpowerquicc-iii-mpc85xx%2Fmpc837xe-
> modular-development-
> system%3AMPC837XEMDS=05%7C01%7Cleoyang.li%40nxp.com%7Ca2
> 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C=052dpEEcGmbuhRLnMDCNoOkTeguF%2BPA0oJGNvV1
> jSjI%3D=0
> [4]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu-
> mcus%2Fpowerquicc-processors%2Fpowerquicc-ii-pro-mpc83xx%2Flow-
> power-powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc-
> engine-with-
> utopia%3AMPC8323E=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1
> e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C%7C=mZQh%2FogNgNUb0wNJV972kYIDvn61gx0TWNd1u1d7PZ
&

RE: [PATCH v5 02/10] soc: fsl: cpm1: Add support for TSA

[Leo Li]

> -Original Message-
> From: Herve Codina 
> Sent: Thursday, February 16, 2023 7:42 AM
> To: Herve Codina ; Leo Li
> ; Rob Herring ; Krzysztof
> Kozlowski ; Liam Girdwood
> ; Mark Brown ; Christophe
> Leroy ; Michael Ellerman
> ; Nicholas Piggin ; Qiang Zhao
> ; Jaroslav Kysela ; Takashi Iwai
> ; Shengjiu Wang ; Xiubo Li
> ; Fabio Estevam ; Nicolin
> Chen 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; alsa-devel@alsa-
> project.org; Thomas Petazzoni 
> Subject: [PATCH v5 02/10] soc: fsl: cpm1: Add support for TSA
> 
> The TSA (Time Slot Assigner) purpose is to route some
> TDM time-slots to other internal serial controllers.
> 
> It is available in some PowerQUICC SoC such as the
> MPC885 or MPC866.
> 
> It is also available on some Quicc Engine SoCs.
> This current version support CPM1 SoCs only and some
> enhancement are needed to support Quicc Engine SoCs.
> 
> Signed-off-by: Herve Codina 

Looks good to me

Acked-by: Li Yang 

> ---
>  drivers/soc/fsl/qe/Kconfig  |  11 +
>  drivers/soc/fsl/qe/Makefile |   1 +
>  drivers/soc/fsl/qe/tsa.c| 869
> 
>  drivers/soc/fsl/qe/tsa.h|  42 ++
>  4 files changed, 923 insertions(+)
>  create mode 100644 drivers/soc/fsl/qe/tsa.c
>  create mode 100644 drivers/soc/fsl/qe/tsa.h
> 
> diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
> index 357c5800b112..b0088495c323 100644
> --- a/drivers/soc/fsl/qe/Kconfig
> +++ b/drivers/soc/fsl/qe/Kconfig
> @@ -33,6 +33,17 @@ config UCC
>   bool
>   default y if UCC_FAST || UCC_SLOW
> 
> +config CPM_TSA
> + tristate "CPM TSA support"
> + depends on OF && HAS_IOMEM
> + depends on CPM1 || COMPILE_TEST
> + help
> +   Freescale CPM Time Slot Assigner (TSA)
> +   controller.
> +
> +   This option enables support for this
> +   controller
> +
>  config QE_TDM
>   bool
>   default y if FSL_UCC_HDLC
> diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile
> index 55a555304f3a..45c961acc81b 100644
> --- a/drivers/soc/fsl/qe/Makefile
> +++ b/drivers/soc/fsl/qe/Makefile
> @@ -4,6 +4,7 @@
>  #
>  obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
>  obj-$(CONFIG_CPM)+= qe_common.o
> +obj-$(CONFIG_CPM_TSA)+= tsa.o
>  obj-$(CONFIG_UCC)+= ucc.o
>  obj-$(CONFIG_UCC_SLOW)   += ucc_slow.o
>  obj-$(CONFIG_UCC_FAST)   += ucc_fast.o
> diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c
> new file mode 100644
> index ..90d9a5254d9b
> --- /dev/null
> +++ b/drivers/soc/fsl/qe/tsa.c
> @@ -0,0 +1,869 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TSA driver
> + *
> + * Copyright 2022 CS GROUP France
> + *
> + * Author: Herve Codina 
> + */
> +
> +#include "tsa.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +/* TSA SI RAM routing tables entry */
> +#define TSA_SIRAM_ENTRY_LAST (1 << 16)
> +#define TSA_SIRAM_ENTRY_BYTE (1 << 17)
> +#define TSA_SIRAM_ENTRY_CNT(x)   (((x) & 0x0f) << 18)
> +#define TSA_SIRAM_ENTRY_CSEL_MASK(0x7 << 22)
> +#define TSA_SIRAM_ENTRY_CSEL_NU  (0x0 << 22)
> +#define TSA_SIRAM_ENTRY_CSEL_SCC2(0x2 << 22)
> +#define TSA_SIRAM_ENTRY_CSEL_SCC3(0x3 << 22)
> +#define TSA_SIRAM_ENTRY_CSEL_SCC4(0x4 << 22)
> +#define TSA_SIRAM_ENTRY_CSEL_SMC1(0x5 << 22)
> +#define TSA_SIRAM_ENTRY_CSEL_SMC2(0x6 << 22)
> +
> +/* SI mode register (32 bits) */
> +#define TSA_SIMODE   0x00
> +#define   TSA_SIMODE_SMC20x8000
> +#define   TSA_SIMODE_SMC10x8000
> +#define   TSA_SIMODE_TDMA(x) ((x) << 0)
> +#define   TSA_SIMODE_TDMB(x) ((x) << 16)
> +#define TSA_SIMODE_TDM_MASK  0x0fff
> +#define TSA_SIMODE_TDM_SDM_MASK  0x0c00
> +#define   TSA_SIMODE_TDM_SDM_NORM0x
> +#define   TSA_SIMODE_TDM_SDM_ECHO0x0400
> +#define   TSA_SIMODE_TDM_SDM_INTL_LOOP   0x0800
> +#define   TSA_SIMODE_TDM_SDM_LOOP_CTRL   0x0c00
> +#define TSA_SIMODE_TDM_RFSD(x)   ((x) << 8)
> +#define TSA_SIMODE_TDM_DSC   0x0080
> +#define TSA_SIMODE_TDM_CRT   0x0040
> +#define TSA_SIMODE_TDM_STZ   0x0020
> +#define TSA_SIMODE_TDM_CE   

RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

[Leo Li]

> -Original Message-
> From: Paul Gortmaker 
> Sent: Monday, February 20, 2023 5:59 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Leo Li ; Claudiu Manoil ;
> Paul Gortmaker ; Scott Wood
> ; Michael Ellerman ; Benjamin
> Herrenschmidt ; Paul Mackerras
> 
> Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
> 
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
> 
> This series removes support for four e300 (MPC83xx) Freescale processor
> family evaluation boards that were added to the kernel in the 2006 era.

Hi Paul,

I talked with our marketing team on this.  Although we do not recommend any new 
design with these SoCs, they are still being shipped in large amount to 
customers now.  Plus it is possible for the bigger amount of existing devices 
to be updating their software that includes a new kernel.  So we should 
definitely keep all the common SoC code that might be needed to support their 
own design.

> 
> These boards were all of a very similar form factor, a largish PCI or PCI-X 
> card
> that could also be used standalone with an external power brick, and all
> shared the Modular Development System (MDS) designation.
> 
> These platforms were made in limited quantity and were generally designed
> to get early silicon into the hands of OEMs who would later develop their
> own boards/platforms.  As such, availability was limited to those who would
> be working on boards and/or BSP support.
> 
> Many early revision MDS platforms used a mechanical clamping system to
> hold the BGA CPU in place to facilitate CPU updates -- something not
> normally possible for a soldered down BGA in a COTS system.
> 
> The point of these details is to give context that reflects that these four
> boards were made in limited quantities, were not in a form factor that is
> really "hobbyist" friendly and hence make sense for removal 17 years later.

We would agree with you that the MDS platforms are only used by a limited 
number of customers for evaluation purpose, so it should be fine to be removed. 
 So for this series:

Acked-by: Li Yang 

> 
> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel.
> 
> There will still exist several e300 Freescale Reference Design System (RDS)
> boards[5] and mini-ITX boards[6] with support in the kernel.  While these
> were more of a COTS "ready to deploy" design more suited to hobbyists, it
> probably makes sense to consider removing these as well, based on age.

These boards are mass market boards that sold in larger amount and are much 
more likely to still be used.  We would suggest we keep them for now.

> 
> But before we get to that, lets see how this goes -- and then we should look
> at similar early e500 evaluation platforms [MPC8540-ADS, etc] next, as the
> oldest there date back to 2002[7] -- before considering RDB/mITX.
> 
> I intentionally didn't put any links in the commits, since as we all know, 
> they
> tend not to be stable long term, so keep them here in the merge data.
> Credit to NXP for keeping around these old legacy docs this long!
> 
> Paul.
> 
> --
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fdesign%2Fqoriq-developer-resources%2Fmpc8349e-modular-
> development-
> system%3AMPC8349EMDS=05%7C01%7Cleoyang.li%40nxp.com%7Ca2
> 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C=Q4COgwpjsE4mHXvl9HdGo3otPCYML3z%2FR6IoCEYRE
> wg%3D=0
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fdocs%2Fen%2Fuser-
> guide%2FMPC8360EMDSUM.pdf=05%7C01%7Cleoyang.li%40nxp.com
> %7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C=JyLT0MfGAHQ8a%2FNgpLdVFtyACkwPR%2FOkB
> yN1aW0wySs%3D=0
> [3]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu-
> mcus%2Fpowerquicc-processors%2Fpowerquicc-iii-mpc85xx%2Fmpc837xe-
> modular-development-
> system%3AMPC837XEMDS=05%7C01%7Cleoyang.li%40nxp.com%7Ca2
> 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C=052dpEEcGmbuhRLnMDCNoOkTeguF%2BPA0oJGNvV1
> jSjI%3D=0
> [4]
> https://eur01.safelink

RE: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms

[Leo Li]

> -Original Message-
> From: Michael Ellerman 
> Sent: Thursday, April 13, 2023 9:14 PM
> To: Leo Li ; Paul Gortmaker
> 
> Cc: Scott Wood ; Paul Mackerras ;
> Claudiu Manoil ; linuxppc-dev@lists.ozlabs.org;
> Pali Rohár 
> Subject: Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation
> platforms
> 
> Li Yang  writes:
> > On Tue, Feb 21, 2023 at 1:52 PM Paul Gortmaker
> >  wrote:
> >>
> >> [This RFC is proposed for v6.4 and hence is based off linux-next.]
> >>
> >> In a similar theme to the e300/MPC83xx evaluation platform
> >> removal[1], this targets removal of some 13 --> 21 year old
> >> e500/MPC85xx evaluation boards that were produced in limited numbers
> >> and primarily made available to hardware/software developers to shape
> their own boards and BSPs.
> >
> > These e500 platforms are similar to the e300 platforms that they are
> > still being shipped, the targeting market probably caused it to have a
> > longer life cycle.
> >
> ...
> >
> > The difference here from the e300 platforms is that MPC8540ADS,
> > MPC8560ADS, MPC8548CDS, MPC8568-MDS are the only reference
> platforms
> > supplied by us for these SoCs.  We don't have a separation of
> > evaluation platforms vs product-like platforms like we did later.
> > That probably means even if they don't look like "hobbyist" friendly
> > they are more likely to be still in use.
> 
> OK. But what is the chance anyone is booting upstream kernels on them?

We do still have these parts shipped, which means that there are definitely 
active users of these silicons.  But it is really hard to say how many of they 
are running latest upstream kernel.  IMO, if the nature of the application is 
critical it is likely they will need to update the kernel to get all the 
security fixes.  And the reference board will be helpful as a starting point 
when they update the kernel.

> 
> I assume no one at NXP is testing upstream on those boards?

To be frank they are not included in the routine tests carried out by the 
development team now which is not ideal to me.  But I think the support team 
are probably willing to help on issues with latest kernel when needed.

Regards,
Leo

RE: [PATCH 0/6] bus: fsl-mc: Make remove function return void

[Leo Li]

> -Original Message-
> From: Uwe Kleine-König 
> Sent: Wednesday, April 12, 2023 12:11 PM
> To: Stuart Yoder ; Laurentiu Tudor
> ; Roy Pledge ; Leo Li
> ; Horia Geanta ; Pankaj
> Gupta ; Gaurav Jain ;
> Herbert Xu ; David S. Miller
> ; Vinod Koul ; Ioana Ciornei
> ; Eric Dumazet ; Jakub
> Kicinski ; Paolo Abeni ; Y.B. Lu
> ; Diana Madalina Craciun (OSS)
> ; Alex Williamson
> ; Richard Cochran
> 
> Cc: k...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-cry...@vger.kernel.org;
> ker...@pengutronix.de; dmaeng...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
> 
> Hello,
> 
> On Fri, Mar 10, 2023 at 11:41:22PM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > many bus remove functions return an integer which is a historic
> > misdesign that makes driver authors assume that there is some kind of
> > error handling in the upper layers. This is wrong however and
> > returning and error code only yields an error message.
> >
> > This series improves the fsl-mc bus by changing the remove callback to
> > return no value instead. As a preparation all drivers are changed to
> > return zero before so that they don't trigger the error message.
> 
> Who is supposed to pick up this patch series (or point out a good reason for
> not taking it)?

Previously Greg KH picked up MC bus patches.

If no one is picking up them this time, I probably can take it through the fsl 
soc tree.

Regards,
Leo

RE: [PATCH v4 06/10] soc: fsl: cmp1: Add support for QMC

[Leo Li]

> -Original Message-
> From: Herve Codina 
> Sent: Thursday, January 26, 2023 2:32 AM
> To: Herve Codina ; Leo Li
> ; Rob Herring ; Krzysztof
> Kozlowski ; Liam Girdwood
> ; Mark Brown ; Christophe
> Leroy ; Michael Ellerman
> ; Nicholas Piggin ; Qiang Zhao
> ; Jaroslav Kysela ; Takashi Iwai
> ; Shengjiu Wang ; Xiubo Li
> ; Fabio Estevam ; Nicolin
> Chen 
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; alsa-devel@alsa-
> project.org; Thomas Petazzoni 
> Subject: [PATCH v4 06/10] soc: fsl: cmp1: Add support for QMC

Typo: cpm1

> 
> The QMC (QUICC Multichannel Controller) emulates up to 64 channels within
> one serial controller using the same TDM physical interface routed from the
> TSA.
> 
> It is available in some   PowerQUICC SoC such as the
> MPC885 or MPC866.
> 
> It is also available on some Quicc Engine SoCs.
> This current version support CPM1 SoCs only and some enhancement are
> needed to support Quicc Engine SoCs.
> 
> Signed-off-by: Herve Codina 

Otherwise looks good to me.

Acked-by: Li Yang 

> ---
>  drivers/soc/fsl/qe/Kconfig  |   12 +
>  drivers/soc/fsl/qe/Makefile |1 +
>  drivers/soc/fsl/qe/qmc.c| 1533
> +++
>  include/soc/fsl/qe/qmc.h|   71 ++
>  4 files changed, 1617 insertions(+)
>  create mode 100644 drivers/soc/fsl/qe/qmc.c  create mode 100644
> include/soc/fsl/qe/qmc.h
> 
> diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig index
> 60ec11c9f4d9..25b218351ae3 100644
> --- a/drivers/soc/fsl/qe/Kconfig
> +++ b/drivers/soc/fsl/qe/Kconfig
> @@ -44,6 +44,18 @@ config CPM_TSA
> This option enables support for this
> controller
> 
> +config CPM_QMC
> + tristate "CPM QMC support"
> + depends on OF && HAS_IOMEM
> + depends on CPM1 || (PPC && COMPILE_TEST)
> + depends on CPM_TSA
> + help
> +   Freescale CPM QUICC Multichannel Controller
> +   (QMC)
> +
> +   This option enables support for this
> +   controller
> +
>  config QE_TDM
>   bool
>   default y if FSL_UCC_HDLC
> diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile index
> 45c961acc81b..ec8506e13113 100644
> --- a/drivers/soc/fsl/qe/Makefile
> +++ b/drivers/soc/fsl/qe/Makefile
> @@ -5,6 +5,7 @@
>  obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
>  obj-$(CONFIG_CPM)+= qe_common.o
>  obj-$(CONFIG_CPM_TSA)+= tsa.o
> +obj-$(CONFIG_CPM_QMC)+= qmc.o
>  obj-$(CONFIG_UCC)+= ucc.o
>  obj-$(CONFIG_UCC_SLOW)   += ucc_slow.o
>  obj-$(CONFIG_UCC_FAST)   += ucc_fast.o
> diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c new file
> mode 100644 index ..cfa7207353e0
> --- /dev/null
> +++ b/drivers/soc/fsl/qe/qmc.c
> @@ -0,0 +1,1533 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * QMC driver
> + *
> + * Copyright 2022 CS GROUP France
> + *
> + * Author: Herve Codina   */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "tsa.h"
> +
> +/* SCC general mode register high (32 bits) */
> +#define SCC_GSMRL0x00
> +#define SCC_GSMRL_ENR(1 << 5)
> +#define SCC_GSMRL_ENT(1 << 4)
> +#define SCC_GSMRL_MODE_QMC   (0x0A << 0)
> +
> +/* SCC general mode register low (32 bits) */
> +#define SCC_GSMRH0x04
> +#define   SCC_GSMRH_CTSS (1 << 7)
> +#define   SCC_GSMRH_CDS  (1 << 8)
> +#define   SCC_GSMRH_CTSP (1 << 9)
> +#define   SCC_GSMRH_CDP  (1 << 10)
> +
> +/* SCC event register (16 bits) */
> +#define SCC_SCCE 0x10
> +#define   SCC_SCCE_IQOV  (1 << 3)
> +#define   SCC_SCCE_GINT  (1 << 2)
> +#define   SCC_SCCE_GUN   (1 << 1)
> +#define   SCC_SCCE_GOV   (1 << 0)
> +
> +/* SCC mask register (16 bits) */
> +#define SCC_SCCM 0x14
> +/* Multichannel base pointer (32 bits) */
> +#define QMC_GBL_MCBASE   0x00
> +/* Multichannel controller state (16 bits) */
> +#define QMC_GBL_QMCSTATE 0x04
> +/* Maximum receive buffer length (16 bits) */
> +#define QMC_GBL_MRBLR0x06
> +/* Tx time-slot assignment table pointer (16 bits) */
> +#define QMC_GBL_TX_S_PTR 0x08
> +/* Rx pointer (16 bits) */
> +#define QMC_GBL_RXPTR0x0A
> +/* Global receive frame threshold (16 bits) */
&g

RE: [PATCH v4 06/10] soc: fsl: cmp1: Add support for QMC

[Leo Li]

> -Original Message-
> From: Christophe Leroy 
> Sent: Wednesday, February 15, 2023 10:08 AM
> To: Leo Li ; Qiang Zhao 
> Cc: linuxppc-dev@lists.ozlabs.org; Krzysztof Kozlowski
> ; Rob Herring ;
> Herve Codina ; linux-arm-
> ker...@lists.infradead.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Nicholas Piggin ; Fabio
> Estevam ; Xiubo Li ;
> Shengjiu Wang ; Takashi Iwai
> ; Jaroslav Kysela ; Michael Ellerman
> ; Mark Brown ; Liam Girdwood
> ; alsa-de...@alsa-project.org; Thomas Petazzoni
> ; Nicolin Chen 
> Subject: Re: [PATCH v4 06/10] soc: fsl: cmp1: Add support for QMC
> 
> Hi Li and Qiang
> 
> Le 26/01/2023 à 09:32, Herve Codina a écrit :
> > The QMC (QUICC Multichannel Controller) emulates up to 64 channels
> > within one serial controller using the same TDM physical interface
> > routed from the TSA.
> >
> > It is available in some PowerQUICC SoC such as the
> > MPC885 or MPC866.
> >
> > It is also available on some Quicc Engine SoCs.
> > This current version support CPM1 SoCs only and some enhancement are
> > needed to support Quicc Engine SoCs.
> 
> Do you have any comment on this patch ?
> 
> Otherwise, may I ask you to send your Acked-by: so that the series can be
> merged in a relevant tree, most likely sound tree ?

Sure.  I will give it a review.

> 
> Thanks
> Christophe
> 
> >
> > Signed-off-by: Herve Codina 
> > ---
> >   drivers/soc/fsl/qe/Kconfig  |   12 +
> >   drivers/soc/fsl/qe/Makefile |1 +
> >   drivers/soc/fsl/qe/qmc.c| 1533
> +++
> >   include/soc/fsl/qe/qmc.h|   71 ++
> >   4 files changed, 1617 insertions(+)
> >   create mode 100644 drivers/soc/fsl/qe/qmc.c
> >   create mode 100644 include/soc/fsl/qe/qmc.h
> >
> > diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
> > index 60ec11c9f4d9..25b218351ae3 100644
> > --- a/drivers/soc/fsl/qe/Kconfig
> > +++ b/drivers/soc/fsl/qe/Kconfig
> > @@ -44,6 +44,18 @@ config CPM_TSA
> >   This option enables support for this
> >   controller
> >
> > +config CPM_QMC
> > +   tristate "CPM QMC support"
> > +   depends on OF && HAS_IOMEM
> > +   depends on CPM1 || (PPC && COMPILE_TEST)
> > +   depends on CPM_TSA
> > +   help
> > + Freescale CPM QUICC Multichannel Controller
> > + (QMC)
> > +
> > + This option enables support for this
> > + controller
> > +
> >   config QE_TDM
> > bool
> > default y if FSL_UCC_HDLC
> > diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile
> > index 45c961acc81b..ec8506e13113 100644
> > --- a/drivers/soc/fsl/qe/Makefile
> > +++ b/drivers/soc/fsl/qe/Makefile
> > @@ -5,6 +5,7 @@
> >   obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_common.o qe_ic.o qe_io.o
> >   obj-$(CONFIG_CPM) += qe_common.o
> >   obj-$(CONFIG_CPM_TSA) += tsa.o
> > +obj-$(CONFIG_CPM_QMC)  += qmc.o
> >   obj-$(CONFIG_UCC) += ucc.o
> >   obj-$(CONFIG_UCC_SLOW)+= ucc_slow.o
> >   obj-$(CONFIG_UCC_FAST)+= ucc_fast.o
> > diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/qe/qmc.c new
> > file mode 100644 index ..cfa7207353e0
> > --- /dev/null
> > +++ b/drivers/soc/fsl/qe/qmc.c
> > @@ -0,0 +1,1533 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * QMC driver
> > + *
> > + * Copyright 2022 CS GROUP France
> > + *
> > + * Author: Herve Codina   */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "tsa.h"
> > +
> > +/* SCC general mode register high (32 bits) */
> > +#define SCC_GSMRL  0x00
> > +#define SCC_GSMRL_ENR  (1 << 5)
> > +#define SCC_GSMRL_ENT  (1 << 4)
> > +#define SCC_GSMRL_MODE_QMC (0x0A << 0)
> > +
> > +/* SCC general mode register low (32 bits) */
> > +#define SCC_GSMRH  0x04
> > +#define   SCC_GSMRH_CTSS   (1 << 7)
> > +#define   SCC_GSMRH_CDS(1 << 8)
> > +#define   SCC_GSMRH_CTSP   (1 << 9)
> > +#define   SCC_GSMRH_CDP(1 << 10)
> > +
> > +/* SCC event register (16 bits) */
> > +#define SCC_SCCE   0x10
> > +#define   SCC_SCCE_IQOV(1 << 3)
> > +#define   SCC_SCCE_GINT(1 << 2)
> > +#d

RE: [PATCH] soc: fsl: qe: Replace all non-returning strlcpy with strscpy

[Leo Li]

> -Original Message-
> From: Azeem Shaikh 
> Sent: Sunday, July 9, 2023 9:36 PM
> To: Kees Cook 
> Cc: Qiang Zhao ; linux-harden...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Leo Li
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] soc: fsl: qe: Replace all non-returning strlcpy with
> strscpy
> 
> On Tue, May 23, 2023 at 1:20 PM Kees Cook 
> wrote:
> >
> > On Tue, May 23, 2023 at 02:14:25AM +, Azeem Shaikh wrote:
> > > strlcpy() reads the entire source buffer first.
> > > This read may exceed the destination size limit.
> > > This is both inefficient and can lead to linear read overflows if a
> > > source string is not NUL-terminated [1].
> > > In an effort to remove strlcpy() completely [2], replace
> > > strlcpy() here with strscpy().
> > > No return values were used, so direct replacement is safe.
> > >
> > > [1]
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >
> w.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fdeprecated.html%23s
> tr
> > >
> lcpy=05%7C01%7Cleoyang.li%40nxp.com%7C11f9df1df1b5440e4ec108
> db8
> > >
> 0ee64de%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63824553360
> 3780
> > >
> 889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJB
> > >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jcTy3IF37wqC1
> MWsSuF
> > > %2F51Z1trQEMaow7BHkPSh3hzI%3D=0
> > > [2]
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > >
> thub.com%2FKSPP%2Flinux%2Fissues%2F89=05%7C01%7Cleoyang.li%
> 40nx
> > >
> p.com%7C11f9df1df1b5440e4ec108db80ee64de%7C686ea1d3bc2b4c6fa92cd
> 99c5
> > >
> c301635%7C0%7C0%7C638245533603780889%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjo
> > >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7
> > >
> C%7C%7C=Blr0W1oYPIw5uDu7HqlEkU7xOuAo4bQNkk%2Bt%2BAuFqc
> s%3D
> > > erved=0
> > >
> > > Signed-off-by: Azeem Shaikh 
> >
> > Reviewed-by: Kees Cook 
> >
> 
> Friendly ping on this.

Sorry for the late response.  But I found some old discussions with the 
conclusion to be not converting old users.  Has this been changed later on?
https://lwn.net/Articles/659214/

Regards,
Leo

RE: [PATCH v2 RESEND] soc/fsl/qe: fix usb.c build errors

[Leo Li]

> -Original Message-
> From: Randy Dunlap 
> Sent: Sunday, May 21, 2023 5:52 PM
> To: linux-ker...@vger.kernel.org
> Cc: Randy Dunlap ; kernel test robot
> ; Michael Ellerman ; Christophe
> Leroy ; Leo Li ;
> Masahiro Yamada ; Nicolas Schier
> ; Qiang Zhao ; linuxppc-dev
> ; linux-arm-ker...@lists.infradead.org;
> Kumar Gala 
> Subject: [PATCH v2 RESEND] soc/fsl/qe: fix usb.c build errors
>
> Fix build errors in soc/fsl/qe/usb.c when QUICC_ENGINE is not set.
> This happens when PPC_EP88XC is set, which selects CPM1 & CPM.
> When CPM is set, USB_FSL_QE can be set without QUICC_ENGINE being set.
> When USB_FSL_QE is set, QE_USB deafults to y, which causes build errors
> when QUICC_ENGINE is not set. Making QE_USB depend on QUICC_ENGINE
> prevents QE_USB from defaulting to y.
>
> Fixes these build errors:
>
> drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set':
> usb.c:(.text+0x1e): undefined reference to `qe_immr'
> powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to `qe_immr'
> powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to `qe_setbrg'
> powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to `cmxgcr_lock'
> powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to `cmxgcr_lock'
>
> Fixes: 5e41486c408e ("powerpc/QE: add support for QE USB clocks routing")
> Signed-off-by: Randy Dunlap 
> Reported-by: kernel test robot 
> Link:
> https://lore.k/
> ernel.org%2Fall%2F202301101500.pillNv6R-
> lkp%40intel.com%2F=05%7C01%7Cleoyang.li%40nxp.com%7Ca43927d9
> 554b4434845608db5a4e0db5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C638203063513512722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C%7C=LkLi6lS%2Fh3pVXW%2Bg9fauCWmptC9lRt3sTdkvn0Extqk%
> 3D=0
> Suggested-by: Michael Ellerman 
> Cc: Christophe Leroy 
> Cc: Leo Li 
> Cc: Masahiro Yamada 
> Cc: Nicolas Schier 
> Cc: Qiang Zhao 
> Cc: linuxppc-dev 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Kumar Gala 

Applied for next.  Thanks.

Regards,
Leo

RE: [PATCH 0/6] bus: fsl-mc: Make remove function return void

[Leo Li]

> -Original Message-
> From: Uwe Kleine-König 
> Sent: Tuesday, May 30, 2023 8:51 AM
> To: Leo Li 
> Cc: Stuart Yoder ; Gaurav Jain
> ; Roy Pledge ; Diana
> Madalina Craciun (OSS) ; Eric Dumazet
> ; Ioana Ciornei ;
> k...@vger.kernel.org; Horia Geanta ; Jakub
> Kicinski ; Paolo Abeni ; Laurentiu
> Tudor ; Richard Cochran
> ; Pankaj Gupta ; Alex
> Williamson ; linux-arm-
> ker...@lists.infradead.org; Herbert Xu ;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; Vinod Koul
> ; linux-cry...@vger.kernel.org; ker...@pengutronix.de;
> Y.B. Lu ; dmaeng...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; David S. Miller 
> Subject: Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
> 
> Hello,
> 
> On Mon, May 08, 2023 at 04:57:00PM -0500, Li Yang wrote:
> > On Mon, May 8, 2023 at 8:44 AM Uwe Kleine-König
> >  wrote:
> > > On Thu, Apr 13, 2023 at 08:00:04AM +0200, Uwe Kleine-König wrote:
> > > > On Wed, Apr 12, 2023 at 09:30:05PM +, Leo Li wrote:
> > > > > > On Fri, Mar 10, 2023 at 11:41:22PM +0100, Uwe Kleine-König wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > many bus remove functions return an integer which is a
> > > > > > > historic misdesign that makes driver authors assume that
> > > > > > > there is some kind of error handling in the upper layers.
> > > > > > > This is wrong however and returning and error code only yields an
> error message.
> > > > > > >
> > > > > > > This series improves the fsl-mc bus by changing the remove
> > > > > > > callback to return no value instead. As a preparation all
> > > > > > > drivers are changed to return zero before so that they don't
> trigger the error message.
> > > > > >
> > > > > > Who is supposed to pick up this patch series (or point out a
> > > > > > good reason for not taking it)?
> > > > >
> > > > > Previously Greg KH picked up MC bus patches.
> > > > >
> > > > > If no one is picking up them this time, I probably can take it
> > > > > through the fsl soc tree.
> > > >
> > > > I guess Greg won't pick up this series as he didn't get a copy of
> > > > it :-)
> > > >
> > > > Browsing through the history of drivers/bus/fsl-mc there is no
> > > > consistent maintainer to see. So if you can take it, that's very
> > > > appreciated.
> > >
> > > My mail was meant encouraging, maybe it was too subtile? I'll try again:
> > >
> > > Yes, please apply, that would be wonderful!
> >
> > Sorry for missing your previous email.  I will do that.  Thanks.
> 
> Either you didn't apply this patch set yet, or your tree isn't in next.
> Both variants would be great to be fixed.
> 
> I have another change pending for drivers/bus/fsl-mc/fsl-mc-bus.c, would be
> great to see these base patches in next first.

I have applied them to the next branch of my tree.  They will be part of the 
Linux-next soon.

Regards,
Leo

RE: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for ch9 udc

[Leo Li]

> -Original Message-
> From: Ma Ke 
> Sent: Wednesday, June 28, 2023 3:15 AM
> To: Leo Li 
> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Ma Ke
> 
> Subject: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for ch9
> udc
> 
> We should verify the bound of the array to assure that host may not
> manipulate the index to point past endpoint array.
> 
> Signed-off-by: Ma Ke 
> ---
>  drivers/usb/gadget/udc/fsl_qe_udc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
> b/drivers/usb/gadget/udc/fsl_qe_udc.c
> index 3b1cc8fa30c8..f4e5cbd193b7 100644
> --- a/drivers/usb/gadget/udc/fsl_qe_udc.c
> +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
> @@ -1959,6 +1959,8 @@ static void ch9getstatus(struct qe_udc *udc, u8
> request_type, u16 value,
>   } else if ((request_type & USB_RECIP_MASK) ==
> USB_RECIP_ENDPOINT) {
>   /* Get endpoint status */
>   int pipe = index & USB_ENDPOINT_NUMBER_MASK;
> + if (pipe >= USB_MAX_ENDPOINTS)
> + goto stall;

Thanks.  This seems to be the right thing to do.  But normally we don't mix 
declarations with code within a code block.  Could we re-arrange the code a 
little bit so declarations stay on top?

>   struct qe_ep *target_ep = >eps[pipe];
>   u16 usep;
> 
> --
> 2.37.2

RE: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for ch9 udc

[Leo Li]

> -Original Message-
> From: Christophe Leroy 
> Sent: Wednesday, June 28, 2023 2:40 PM
> To: Leo Li ; Ma Ke 
> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for
> ch9 udc
> 
> 
> 
> Le 28/06/2023 à 19:04, Leo Li a écrit :
> >
> >
> >> -Original Message-
> >> From: Ma Ke 
> >> Sent: Wednesday, June 28, 2023 3:15 AM
> >> To: Leo Li 
> >> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linuxppc-
> >> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Ma Ke
> >> 
> >> Subject: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for
> >> ch9 udc
> >>
> >> We should verify the bound of the array to assure that host may not
> >> manipulate the index to point past endpoint array.
> >>
> >> Signed-off-by: Ma Ke 
> >> ---
> >>   drivers/usb/gadget/udc/fsl_qe_udc.c | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
> >> b/drivers/usb/gadget/udc/fsl_qe_udc.c
> >> index 3b1cc8fa30c8..f4e5cbd193b7 100644
> >> --- a/drivers/usb/gadget/udc/fsl_qe_udc.c
> >> +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
> >> @@ -1959,6 +1959,8 @@ static void ch9getstatus(struct qe_udc *udc, u8
> >> request_type, u16 value,
> >>} else if ((request_type & USB_RECIP_MASK) ==
> >> USB_RECIP_ENDPOINT) {
> >>/* Get endpoint status */
> >>int pipe = index & USB_ENDPOINT_NUMBER_MASK;
> >> +  if (pipe >= USB_MAX_ENDPOINTS)
> >> +  goto stall;
> >
> > Thanks.  This seems to be the right thing to do.  But normally we don't mix
> declarations with code within a code block.  Could we re-arrange the code a
> little bit so declarations stay on top?
> 
> But we are at the start of a code block aren't we ?

But they were at the beginning of a { } block which is compliant with the C89 
standard.  I know gcc is more relaxed from this.  But it is probably still good 
to stick to the standard?

> 
> The only missing thing is the blank line between the declarations and the
> code, so that we clearly see where declarations end and where code start.
> 
> >
> >>struct qe_ep *target_ep = >eps[pipe];
> >>u16 usep;
> >>
> >> --
> >> 2.37.2
> >

RE: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for ch9 udc

[Leo Li]

> -Original Message-
> From: gre...@linuxfoundation.org 
> Sent: Thursday, June 29, 2023 3:41 AM
> To: Christophe Leroy 
> Cc: Leo Li ; Ma Ke ; linux-
> u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index for
> ch9 udc
> 
> On Thu, Jun 29, 2023 at 05:56:30AM +, Christophe Leroy wrote:
> >
> >
> > Le 28/06/2023 à 23:10, Leo Li a écrit :
> > >
> > >
> > >> -Original Message-
> > >> From: Christophe Leroy 
> > >> Sent: Wednesday, June 28, 2023 2:40 PM
> > >> To: Leo Li ; Ma Ke 
> > >> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> > >> linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org
> > >> Subject: Re: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint
> > >> index for
> > >> ch9 udc
> > >>
> > >>
> > >>
> > >> Le 28/06/2023 à 19:04, Leo Li a écrit :
> > >>>
> > >>>
> > >>>> -Original Message-
> > >>>> From: Ma Ke 
> > >>>> Sent: Wednesday, June 28, 2023 3:15 AM
> > >>>> To: Leo Li 
> > >>>> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> > >>>> linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Ma
> > >>>> Ke 
> > >>>> Subject: [PATCH] usb: gadget: fsl_qe_udc: validate endpoint index
> > >>>> for
> > >>>> ch9 udc
> > >>>>
> > >>>> We should verify the bound of the array to assure that host may
> > >>>> not manipulate the index to point past endpoint array.
> > >>>>
> > >>>> Signed-off-by: Ma Ke 
> > >>>> ---
> > >>>>drivers/usb/gadget/udc/fsl_qe_udc.c | 2 ++
> > >>>>1 file changed, 2 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
> > >>>> b/drivers/usb/gadget/udc/fsl_qe_udc.c
> > >>>> index 3b1cc8fa30c8..f4e5cbd193b7 100644
> > >>>> --- a/drivers/usb/gadget/udc/fsl_qe_udc.c
> > >>>> +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
> > >>>> @@ -1959,6 +1959,8 @@ static void ch9getstatus(struct qe_udc
> > >>>> *udc, u8 request_type, u16 value,
> > >>>>} else if ((request_type & USB_RECIP_MASK) ==
> > >>>> USB_RECIP_ENDPOINT) {
> > >>>>/* Get endpoint status */
> > >>>>int pipe = index & USB_ENDPOINT_NUMBER_MASK;
> > >>>> +  if (pipe >= USB_MAX_ENDPOINTS)
> > >>>> +  goto stall;
> > >>>
> > >>> Thanks.  This seems to be the right thing to do.  But normally we
> > >>> don't mix
> > >> declarations with code within a code block.  Could we re-arrange
> > >> the code a little bit so declarations stay on top?
> > >>
> > >> But we are at the start of a code block aren't we ?
> > >
> > > But they were at the beginning of a { } block which is compliant with the
> C89 standard.  I know gcc is more relaxed from this.  But it is probably still
> good to stick to the standard?
> >
> > Sorry I misread the patch and failed to see that the declaration block
> > was continuing after the change.
> >
> > So yes don't interleave code with declarations. Leave declaration at
> > the top of a block with a blank line between declarations and code.
> 
> This is fine as-is, no need to change anything.

With the approval from Greg, I have no objection to the patch.

Acked-by: Li Yang 

Regards,
Leo

RE: [PATCH][v3] mtd/ifc: Add support for IFC controller version 2.0

[Yang-Leo Li]

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Wednesday, April 06, 2016 12:53 PM
> To: Li Yang <le...@freescale.com>
> Cc: Scott Wood <o...@buserror.net>; Raghav Dogra <raghav.do...@nxp.com>;
> linux-...@lists.infradead.org; linuxppc-dev <linuxppc-dev@lists.ozlabs.org>;
> Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Raghav Dogra
> <rag...@freescale.com>; Jaiprakash Singh <b44...@freescale.com>; Boris
> Brezillon <boris.brezil...@free-electrons.com>
> Subject: Re: [PATCH][v3] mtd/ifc: Add support for IFC controller version 2.0
> 
> Hi,
> 
> On Wed, Mar 30, 2016 at 03:43:40PM -0500, Li Yang wrote:
> > Hi Brian,
> >
> > Could you help to review and pull in this patch and the Kconfig update
> > after this patch(https://patchwork.ozlabs.org/patch/557389/)?  It
> 
> It's probably best for Boris to apply this now.

Thanks Brian.  I see Boris is taking over the maintenance of NAND recently, we 
will follow up with him.

Hi Boris,

Can you consider to pull in this patch and then Kconfig patch 
(https://patchwork.ozlabs.org/patch/557389/)?

Regards,
Leo

> 
> > stated a dependency in the notes, but actually it should be applied
> > cleanly without that patch.  These patches are critical to make NAND
> > mtd feature work for our new chips.
> >
> > Regards,
> > Leo
> >
> > On Thu, Feb 18, 2016 at 6:07 PM, Scott Wood <o...@buserror.net> wrote:
> > > On Thu, 2016-02-18 at 15:18 -0600, Leo Li wrote:
> > >> On Wed, Feb 17, 2016 at 5:24 AM, Raghav Dogra <raghav.do...@nxp.com>
> wrote:
> > >> > The new IFC controller version 2.0 has a different memory map page.
> > >> > Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 PAGE size is 64KB.
> > >> > This patch segregates the IFC global and runtime registers to
> > >> > appropriate PAGE sizes.
> > >> >
> > >> > Signed-off-by: Jaiprakash Singh <b44...@freescale.com>
> > >> > Signed-off-by: Raghav Dogra <rag...@freescale.com>
> > >> > Acked-by: Li Yang <leoyang...@nxp.com>
> > >> > Signed-off-by: Raghav Dogra <raghav.do...@nxp.com>
> > >> > ---
> > >> > Changes for v3: not dependent on
> > >> > "drivers/memory: Add deep sleep support for IFC" patch
> > >> >
> > >> > Changes for v2: rebased to resolve conflicts Applicable to
> > >> > git://git.infradead.org/l2-mtd.git
> > >> >
> > >> > This patch is dependent on "drivers/memory: Add deep sleep
> > >> > support for IFC"
> > >> > https://patchwork.ozlabs.org/patch/582762/
> > >> > which is also applicable to git://git.infradead.org/l2-mtd.git
> 
> For the patch:
> 
> Acked-by: Brian Norris <computersforpe...@gmail.com>
> 
> > >> This patch seems to be in good shape, but the dependency is still
> > >> having quite some feedback to be addressed.  Depending on it will
> > >> greatly delay the time that this critical patch for LS2 to be merged.
> > >> Could you remove the dependency like Scott already suggested?
> > >
> > > According to the changelog the dependency has been removed (it would
> > > have been clearer to remove this comment as well...).
> > >
> > > -Scott
> > >
> >
> >
> >
> > --
> > - Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 5/5] dmaengine: fsldma: Use dma_pool_zalloc

[Yang-Leo Li]

> -Original Message-
> From: Julia Lawall [mailto:julia.law...@lip6.fr]
> Sent: Friday, April 29, 2016 3:09 PM
> To: Li Yang 
> Cc: kernel-janit...@vger.kernel.org; Zhang Wei ; Vinod
> Koul ; Dan Williams ;
> linuxppc-dev@lists.ozlabs.org; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH 5/5] dmaengine: fsldma: Use dma_pool_zalloc
> 
> Dma_pool_zalloc combines dma_pool_alloc and memset 0.  The semantic patch
> that makes this transformation is as follows: (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> expression d,e;
> statement S;
> @@
> 
> d =
> -dma_pool_alloc
> +dma_pool_zalloc
>  (...);
> if (!d) S
> -   memset(d, 0, sizeof(*d));
> // 
> 
> Signed-off-by: Julia Lawall 

Acked-by: Li Yang 

> 
> ---
>  drivers/dma/fsldma.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index
> aac85c3..a8828ed 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -462,13 +462,12 @@ static struct fsl_desc_sw
> *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
>   struct fsl_desc_sw *desc;
>   dma_addr_t pdesc;
> 
> - desc = dma_pool_alloc(chan->desc_pool, GFP_ATOMIC, );
> + desc = dma_pool_zalloc(chan->desc_pool, GFP_ATOMIC, );
>   if (!desc) {
>   chan_dbg(chan, "out of memory for link descriptor\n");
>   return NULL;
>   }
> 
> - memset(desc, 0, sizeof(*desc));
>   INIT_LIST_HEAD(>tx_list);
>   dma_async_tx_descriptor_init(>async_tx, >common);
>   desc->async_tx.tx_submit = fsl_dma_tx_submit;

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

RE: [PATCH v2 3/5] powerpc/dts: add a compatible string to gpio0

[Yang-Leo Li]

> -Original Message-
> From: linuxppc-release-boun...@linux.freescale.net [mailto:linuxppc-release-
> boun...@linux.freescale.net] On Behalf Of Chenhui Zhao
> Sent: Friday, April 15, 2016 6:13 AM
> To: linuxppc-dev@lists.ozlabs.org; o...@buserror.net
> Cc: Chenhui Zhao ; Zhengxiong Jin
> 
> Subject: [linuxppc-release] [PATCH v2 3/5] powerpc/dts: add a compatible 
> string
> to gpio0
> 
> All gpio nodes used the same compatible string "fsl,qoriq-gpio".
> To identify the node corresponding to the GPIO1 pins, add a compatible string
> "fsl,qoriq-gpio-1".

This is not a documented binding.  And we normally don't add compatible strings 
for this purpose.  If you want to reference a specific GPIO pin, use the 
binding described at Documentation/devicetree/bindings/gpio/gpio.txt

Regards,
Leo

> 
> Signed-off-by: Chenhui Zhao 
> ---
>  arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi
> b/arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi
> index cf714f5..1a26d6b 100644
> --- a/arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi
> @@ -33,7 +33,7 @@
>   */
> 
>  gpio0: gpio@13 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,qoriq-gpio-1", "fsl,qoriq-gpio";
>   reg = <0x13 0x1000>;
>   interrupts = <55 2 0 0>;
>   #gpio-cells = <2>;
> --
> 1.9.1
> 
> ___
> linuxppc-release mailing list
> linuxppc-rele...@linux.freescale.net
> http://linux.freescale.net/mailman/listinfo/linuxppc-release
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev