[PATCH] tty:vt remove obsolete struct initializer

[Peng Fan]

This patch fixes sparse warning:
"obsolete struct initializer, use C99 syntax"

Signed-off-by: Peng Fan 
---
 drivers/tty/vt/vt.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b33b00b..cf18bd4 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1367,9 +1367,11 @@ static void csi_m(struct vc_data *vc)
rgb_from_256(vc->vc_par[i]));
} else if (vc->vc_par[i] == 2 &&  /* 24 bit */
   i <= vc->vc_npar + 3) {/* extremely 
rare */
-   struct rgb c = {r:vc->vc_par[i+1],
-   g:vc->vc_par[i+2],
-   b:vc->vc_par[i+3]};
+   struct rgb c = {
+   .r = vc->vc_par[i + 1],
+   .g = vc->vc_par[i + 2],
+   .b = vc->vc_par[i + 3],
+   };
rgb_foreground(vc, c);
i += 3;
}
@@ -1388,9 +1390,11 @@ static void csi_m(struct vc_data *vc)
rgb_from_256(vc->vc_par[i]));
} else if (vc->vc_par[i] == 2 && /* 24 bit */
   i <= vc->vc_npar + 3) {
-   struct rgb c = {r:vc->vc_par[i+1],
-   g:vc->vc_par[i+2],
-   b:vc->vc_par[i+3]};
+   struct rgb c = {
+   .r = vc->vc_par[i + 1],
+   .g = vc->vc_par[i + 2],
+   .b = vc->vc_par[i + 3],
+   };
rgb_background(vc, c);
i += 3;
}
-- 
1.8.4

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

[PATCH 2/2] arm:kvm remove len 8 for mmio read write buf

[Peng Fan]

For arm 32 bit architecture, 8 bytes load/store operation in one instruction
will not be generated by compiler.

And before invoke mmio_read_buf, there is a piece of code:
"
 len = run->mmio.len;
 if (len > sizeof(unsigned long))
 return -EINVAL;

data = mmio_read_buf(run->mmio.data, len);
"

This piece code also tells that len variable does not exceeds 4 bytes.
So, remove 8 bytes assign in mmio_read_buf and mmio_write_buf.

Signed-off-by: Peng Fan 
CC: Gleb Natapov 
CC: Paolo Bonzini 
CC: Christoffer Dall 
CC: Marc Zyngier 
CC: Russell King 
---
 arch/arm/kvm/mmio.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 4cb5a93..953a819 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -30,7 +30,6 @@ static void mmio_write_buf(char *buf, unsigned int len, 
unsigned long data)
u8  byte;
u16 hword;
u32 word;
-   u64 dword;
} tmp;
 
switch (len) {
@@ -46,10 +45,6 @@ static void mmio_write_buf(char *buf, unsigned int len, 
unsigned long data)
tmp.word= data;
datap   = &tmp.word;
break;
-   case 8:
-   tmp.dword   = data;
-   datap   = &tmp.dword;
-   break;
}
 
memcpy(buf, datap, len);
@@ -61,7 +56,6 @@ static unsigned long mmio_read_buf(char *buf, unsigned int 
len)
union {
u16 hword;
u32 word;
-   u64 dword;
} tmp;
 
switch (len) {
@@ -76,10 +70,6 @@ static unsigned long mmio_read_buf(char *buf, unsigned int 
len)
memcpy(&tmp.word, buf, len);
data = tmp.word;
break;
-   case 8:
-   memcpy(&tmp.dword, buf, len);
-   data = tmp.dword;
-   break;
}
 
return data;
-- 
1.8.4

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

[PATCH 1/2] arm:kvm correct prototype to make sparse happy

[Peng Fan]

Warning message:
arch/arm/kvm/arm.c:85:17:
error: symbol 'kvm_get_running_vcpus' redeclared with different type
(originally declared at ./arch/arm/include/asm/kvm_host.h :190) -
different address spaces

Signed-off-by: Peng Fan 
CC: Gleb Natapov 
CC: Paolo Bonzini 
CC: Christoffer Dall 
CC: Marc Zyngier 
CC: Russell King 
---
 arch/arm/include/asm/kvm_host.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 53036e2..219d025 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -187,7 +187,7 @@ static inline void 
kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
 }
 
 struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
-struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
+struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void);
 
 int kvm_arm_copy_coproc_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
 unsigned long kvm_arm_num_coproc_regs(struct kvm_vcpu *vcpu);
-- 
1.8.4

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

Re: [PATCH 2/2] arm:kvm remove len 8 for mmio read write buf

[Peng Fan]

Just began learning this piece of code.
Thanks for correcting me. 

On 12/22/2014 07:51 PM, Marc Zyngier wrote:
> On 22/12/14 11:23, Peng Fan wrote:
>> For arm 32 bit architecture, 8 bytes load/store operation in one instruction
>> will not be generated by compiler.
> 
> Ever heard of lrdr/strd?
> 
>> And before invoke mmio_read_buf, there is a piece of code:
>> "
>>  len = run->mmio.len;
>>  if (len > sizeof(unsigned long))
>>  return -EINVAL;
>>
>>  data = mmio_read_buf(run->mmio.data, len);
>> "
>>
>> This piece code also tells that len variable does not exceeds 4 bytes.
>> So, remove 8 bytes assign in mmio_read_buf and mmio_write_buf.
> 
> NAK. This code is shared between arm and arm64. See commit f42798c.
> 
>   M.
> 
>>
>> Signed-off-by: Peng Fan 
>> CC: Gleb Natapov 
>> CC: Paolo Bonzini 
>> CC: Christoffer Dall 
>> CC: Marc Zyngier 
>> CC: Russell King 
>> ---
>>  arch/arm/kvm/mmio.c | 10 --
>>  1 file changed, 10 deletions(-)
>>
>> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
>> index 4cb5a93..953a819 100644
>> --- a/arch/arm/kvm/mmio.c
>> +++ b/arch/arm/kvm/mmio.c
>> @@ -30,7 +30,6 @@ static void mmio_write_buf(char *buf, unsigned int len, 
>> unsigned long data)
>>  u8  byte;
>>  u16 hword;
>>  u32 word;
>> -u64 dword;
>>  } tmp;
>>  
>>  switch (len) {
>> @@ -46,10 +45,6 @@ static void mmio_write_buf(char *buf, unsigned int len, 
>> unsigned long data)
>>  tmp.word= data;
>>  datap   = &tmp.word;
>>  break;
>> -case 8:
>> -tmp.dword   = data;
>> -datap   = &tmp.dword;
>> -break;
>>  }
>>  
>>  memcpy(buf, datap, len);
>> @@ -61,7 +56,6 @@ static unsigned long mmio_read_buf(char *buf, unsigned int 
>> len)
>>  union {
>>  u16 hword;
>>  u32 word;
>> -u64 dword;
>>  } tmp;
>>  
>>  switch (len) {
>> @@ -76,10 +70,6 @@ static unsigned long mmio_read_buf(char *buf, unsigned 
>> int len)
>>  memcpy(&tmp.word, buf, len);
>>  data = tmp.word;
>>  break;
>> -case 8:
>> -memcpy(&tmp.dword, buf, len);
>> -data = tmp.dword;
>> -break;
>>  }
>>  
>>  return data;
>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm: Do not overwrite __machine_arch_type

[Peng Fan]

If using DT_MACHINE_START when enabled CONFIG_OF, the nr of mdesc is ~0.
The value of __machine_arch_type is passsed from bootloader using reigster
r1, and assigned in head-common.S. Remove this line to avoid overwrite it.

Signed-off-by: Peng Fan 
---
 arch/arm/kernel/devtree.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..3a04486 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -243,8 +243,5 @@ const struct machine_desc * __init 
setup_machine_fdt(unsigned int dt_phys)
 
early_init_dt_scan_nodes();
 
-   /* Change machine number to match the mdesc we're using */
-   __machine_arch_type = mdesc->nr;
-
return mdesc;
 }
-- 
1.8.4


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

Re: [PATCH] arm: Do not overwrite __machine_arch_type

[Peng Fan]

On 08/19/2014 03:43 PM, Russell King - ARM Linux wrote:
> On Tue, Aug 19, 2014 at 11:21:31AM +0800, Peng Fan wrote:
>> If using DT_MACHINE_START when enabled CONFIG_OF, the nr of mdesc is ~0.
>> The value of __machine_arch_type is passsed from bootloader using reigster
>> r1, and assigned in head-common.S. Remove this line to avoid overwrite it.
> 
> No.  The idea here is that the machine_is_xxx() methods are not used when
> using DT, so this disables them.
> 
Got it. Thanks.

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

RE: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Rob,

> Subject: Re: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Mon, Jul 15, 2019 at 4:10 AM Peng Fan  wrote:
> >
> > From: Peng Fan 
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception 
> > levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >
> > V3:
> >  Convert to yaml
> >  Drop interrupt
> >  Introudce transports to indicate mem/reg  The func id is still kept
> > as optional, because like SCMI it only  cares about message.
> >
> > V2:
> >  Introduce interrupts as a property.
> >
> >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 124
> +
> >  1 file changed, 124 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index ..da9b1a03bc4e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,124 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C424e0d1c19c344406b6008d709465591%7C686ea1
> d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C0%7C636988070002772705&sdata=DV
> stQ%2FhuN
> > +c67%2Bt08yXibQrX7sIeocHziYp3dkkeRoJ4%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C424e0d1c19c344406b6008d709465591%7C686ea1d3bc2b4
> c6fa92cd9
> >
> +9c5c301635%7C0%7C0%7C636988070002782698&sdata=D%2Fa2SU
> W%2FCqclJdy
> > +RbFggqqL%2BAEumER0K3rAaisY2bMc%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > +  - Peng Fan 
> > +
> > +description: |
> > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > +  call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > +  executing on the very same core as the caller. By nature this
> > +operation
> > +  is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > +  to be delivered the other way round, from firmware to the OS, but
> > +  asynchronous notification could also be supported. However the
> > +value of
> > +  r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received
> > +  message to the mailbox framework, so a synchronous communication
> > +can be
> > +  established, for a asynchronous notification, no value will be returned.
> > +  The exact meaning of both the action the mailbox triggers as well
> > +as the
> > +  return value is defined by their users and is not subject to this 
> > binding.
> > +
> > +  One use case of this mailbox is the SCMI interface, which uses
> > + shared memory  to transfer commands and parameters, and a mailbox
> to
> > + trigger a function  call. This allows SoCs without a separate
> > + management processor (or when  such a processor is not available or
> > + used) to use this standardized  interface anyway.
> > +
> > +  This binding describes no hardware, but establishes a firmware
> interface.
> > +  Upon receiving an SMC using one of the described SMC function
> > + identifiers,  the firmware is expected to trigger some mailbox connected
> functionality.
> > +  The communication follows the ARM SMC calling convention.
> > +  Firmware expects an SMC function identifier in r0 or w0. The
> > + supported  identifiers are passed from consumers, or listed in the
> > + the arm,func-ids  properties as described below. The firmware can
> > + return one value in  the first SMC result register, it is expected
> > + to be an error value,  which shall be propagated to the mailbox client.
> > +
> > +  Any core which supports the SMC or HVC instruction can be used, as
> > + long as  a firmware component running in EL3 or EL2 is handling these
> calls.
&g

RE: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Sudeep,

> Subject: Re: [PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> This looks much better now.
> 
> On Mon, Jul 15, 2019 at 10:10:10AM +, Peng Fan wrote:
> > From: Peng Fan 
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception 
> > levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >
> > V3:
> >  Convert to yaml
> >  Drop interrupt
> >  Introudce transports to indicate mem/reg  The func id is still kept
> > as optional, because like SCMI it only  cares about message.
> >
> > V2:
> >  Introduce interrupts as a property.
> >
> >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 124
> +
> >  1 file changed, 124 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index ..da9b1a03bc4e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,124 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7Cb5039d50ce8c40928edb08d70adc20f9%7C686ea1
> d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C636989812923178414&sdata=UT
> 7r2vOLX4a
> > +tv7Yfh750wdSXSh2ZPxeJOXLWl5yACK0%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7Cb5039d50ce8c40928edb08d70adc20f9%7C686ea1d3bc2b4c
> 6fa92cd9
> >
> +9c5c301635%7C0%7C1%7C636989812923178414&sdata=3Gjn1NQtO
> PbvfTvyN3X
> > +b89%2BvvGO2ff6DpGQUQejGAzU%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > +  - Peng Fan 
> > +
> > +description: |
> > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > +  call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > +  executing on the very same core as the caller. By nature this
> > +operation
> > +  is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > +  to be delivered the other way round, from firmware to the OS, but
> > +  asynchronous notification could also be supported. However the
> > +value of
> > +  r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received
> > +  message to the mailbox framework, so a synchronous communication
> > +can be
> > +  established, for a asynchronous notification, no value will be returned.
> > +  The exact meaning of both the action the mailbox triggers as well
> > +as the
> > +  return value is defined by their users and is not subject to this 
> > binding.
> > +
> > +  One use case of this mailbox is the SCMI interface, which uses
> > + shared memory  to transfer commands and parameters, and a mailbox
> to
> > + trigger a function  call. This allows SoCs without a separate
> > + management processor (or when  such a processor is not available or
> > + used) to use this standardized  interface anyway.
> > +
> > +  This binding describes no hardware, but establishes a firmware
> interface.
> > +  Upon receiving an SMC using one of the described SMC function
> > + identifiers,  the firmware is expected to trigger some mailbox connected
> functionality.
> > +  The communication follows the ARM SMC calling convention.
> > +  Firmware expects an SMC function identifier in r0 or w0. The
> > + supported  identifiers are passed from consumers, or listed in the
> > + the arm,func-ids  properties as described below. The firmware can
> > + return one value in  the first SMC result register, it is expected
> > + to be an error value,  which shall be propagated to the mailbox client.
> > +
> > +  Any core which supports the SMC or HVC instruction can be used, as
> > + long as  a firmware component running in EL3 or EL2 is han

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Fri, 30 Aug 2019 03:12:29 -0500
> Jassi Brar  wrote:
> 
> Hi,
> 
> > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan  wrote:
> > >
> > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > for the ARM SMC/HVC mailbox
> > > >
> > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan  wrote:
> > > > >
> > > > > Hi Jassi,
> > > > >
> > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding
> > > > > > doc for the ARM SMC/HVC mailbox
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan 
> wrote:
> > > > > >
> > > > > > > > > +examples:
> > > > > > > > > +  - |
> > > > > > > > > +sram@91 {
> > > > > > > > > +  compatible = "mmio-sram";
> > > > > > > > > +  reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > +  #address-cells = <1>;
> > > > > > > > > +  #size-cells = <1>;
> > > > > > > > > +  ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > +
> > > > > > > > > +  cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x0 0x200>;
> > > > > > > > > +  };
> > > > > > > > > +
> > > > > > > > > +  cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > > +reg = <0x200 0x200>;
> > > > > > > > > +  };
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +firmware {
> > > > > > > > > +  smc_mbox: mailbox {
> > > > > > > > > +#mbox-cells = <1>;
> > > > > > > > > +compatible = "arm,smc-mbox";
> > > > > > > > > +method = "smc";
> > > > > > > > > +arm,num-chans = <0x2>;
> > > > > > > > > +transports = "mem";
> > > > > > > > > +/* Optional */
> > > > > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > > > > >
> > > > > > > > SMC/HVC is synchronously(block) running in "secure mode",
> > > > > > > > i.e, there can only be one instance running platform wide. 
> > > > > > > > Right?
> > > > > > >
> > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > For virtualization case, there could be dedicated channel for each
> VM.
> > > > > > >
> > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above,
> > > > > > can't both be active at the same time, right?
> > > > >
> > > > > If I get your point correctly,
> > > > > On UP, both could not be active. On SMP, tx/rx could be both
> > > > > active, anyway this depends on secure firmware and Linux firmware
> design.
> > > > >
> > > > > Do you have any suggestions about arm,func-ids here?
> > > > >
> > > > I was thinking if this is just an instruction, why can't each
> > > > channel be represented as a controller, i.e, have exactly one func-id 
> > > > per
> controller node.
> > > > Define as many controllers as you need channels ?
> > >
> > > I am ok, this could make driver code simpler. Something as below?
> > >
> > > smc_tx_mbox: tx_mbox {
> > >   #mbox-cells = <0>;
> > >   compatible = "arm,smc-mbox";
> > >   method = "smc";
> > >   transports = "mem";
> > >   arm,func-id = <0xc2fe>;
> > > };
> > >
> > > smc_rx_mbox: rx_mbox {
> > >   #mbox-cells = <0

RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi Andre,

> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Wed, 28 Aug 2019 03:03:02 +0000
> Peng Fan  wrote:
> 
> Hi,
> 
> > From: Peng Fan 
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Cce8d04bcbdea4de6a77a08d7353c4e35%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637036405476727893&sdata=y5%2FI%2B
> w%2FPOypEh
> > zh6gWdXAGMGnl677B7gDZsX%2F5zfAQw%3D&reserved=0
> >
> > Cc: Andre Przywara 
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/mailbox/Kconfig   |   7 ++
> >  drivers/mailbox/Makefile  |   2 +
> >  drivers/mailbox/arm-smc-mailbox.c | 215
> > ++
> >  3 files changed, 224 insertions(+)
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > ab4eb750bbdd..7707ee26251a 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -16,6 +16,13 @@ config ARM_MHU
> >   The controller has 3 mailbox channels, the last of which can be
> >   used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > +   tristate "Generic ARM smc mailbox"
> > +   depends on OF && HAVE_ARM_SMCCC
> > +   help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> >  config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
> >
> >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..76a2ae11ee4d
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include  #include 
> > +#include 
> > +
> > +#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
> > +
> > +struct arm_smc_chan_data {
> > +   u32 function_id;
> > +   u32 chan_id;
> > +   u32 flags;
> > +};
> > +
> > +struct arm_smccc_mbox_cmd {
> > +   unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
> 
> I think this is one or even two registers too long?
> The SMCCC speaks of the function ID in x0/r0 and six arguments, with a
> "client ID" being an optional seventh argument. Looking at the description
> there I believe we cannot use the client ID here for this purpose, as this is
> supposed to be set by a hypervisor before passing on an SMC to EL3 firmware.
> KVM does not allow passing on SMCs in this way.

I'll drop a7.

> 
> Also, while using "long" in here seems to make sense from the mailbox and
> SMC point of view, aliasing this to the mailbox client provided data seems
> dangerous to me, as this exposes the difference between arm32 and arm64
> to the client. I think this is not what we want, the client should not be
> architecture specific.

I see.

> 
> > +};
> > +
> > +typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
> > + 

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Wed, Sep 11, 2019 at 10:03 AM Andre Przywara
>  wrote:
> >
> > On Tue, 10 Sep 2019 21:44:11 -0500
> > Jassi Brar  wrote:
> >
> > Hi,
> >
> > > On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara
>  wrote:
> > > >
> > > > On Wed, 28 Aug 2019 03:02:58 + Peng Fan 
> > > > wrote:
> > > >
> > [ ... ]
> > > >
> > > > > +
> > > > > +  arm,func-ids:
> > > > > +description: |
> > > > > +  An array of 32-bit values specifying the function IDs used by
> each
> > > > > +  mailbox channel. Those function IDs follow the ARM SMC
> calling
> > > > > +  convention standard [1].
> > > > > +
> > > > > +  There is one identifier per channel and the number of
> supported
> > > > > +  channels is determined by the length of this array.
> > > >
> > > > I think this makes it obvious that arm,num-chans is not needed.
> > > >
> > > > Also this somewhat contradicts the driver implementation, which allows
> the array to be shorter, marking this as UINT_MAX and later on using the first
> data item as a function identifier. This is somewhat surprising and not
> documented (unless I missed something).
> > > >
> > > > So I would suggest:
> > > > - We drop the transports property, and always put the client provided
> data in the registers, according to the SMCCC. Document this here.
> > > >   A client not needing those could always puts zeros (or garbage) in
> there, the respective firmware would just ignore the registers.
> > > > - We drop "arm,num-chans", as this is just redundant with the length of
> the func-ids array.
> > > > - We don't impose an arbitrary limit on the number of channels. From
> the firmware point of view this is just different function IDs, from Linux' 
> point
> of view just the size of the memory used. Both don't need to be limited
> artificially IMHO.
> > > >
> > > Sounds like we are in sync.
> > >
> > > > - We mark arm,func-ids as required, as this needs to be fixed, allocated
> number.
> > > >
> > > I still think func-id can be done without. A client can always pass
> > > the value as it knows what it expects.
> >
> > I don't think it's the right abstraction. The mailbox *controller* uses a
> specific func-id, this has to match the one the firmware expects. So this is a
> property of the mailbox transport channel (the SMC call), and the *client*
> should *not* care about it. It just sees the logical channel ID (if we have 
> one),
> which the controller translates into the func-ID.
> >
> arg0 is special only to the client/protocol, otherwise it is simply the first
> argument for the arm_smccc_smc *instruction* controller.
> arg[1,7] are already provided by the client, so it is only neater if
> arg0 is also taken from the client.
> 
> But as I said, I am still ok if func-id is passed from dt and arg0 from 
> client is
> ignored because we have one channel per controller design and we don't have
> to worry about number of channels there can be dedicated to specific
> functions.

Ok, so I'll make it an optional property.

> 
> > So it should really look like this (assuming only single channel 
> > controllers):
> > mailbox: smc-mailbox {
> > #mbox-cells = <0>;
> > compatible = "arm,smc-mbox";
> > method = "smc";
> >
> Do we want to do away with 'method' property and use different 'compatible'
> properties instead?
>  compatible = "arm,smc-mbox"; orcompatible = "arm,hvc-mbox";

I am ok, just need add data in driver to differentiate smc/hvc.
Andre, are you ok?

Thanks,
Peng.

> 
> > arm,func-id = <0x82fe>;
> > };
> > scmi {
> > compatible = "arm,scmi";
> > mboxes = <&smc_mbox>;
> > mbox-names = "tx"; /* rx is optional */
> > shmem = <&cpu_scp_hpri>;
> > };
> >
> > If you allow the client to provide the function ID (and I am not saying 
> > this is
> a good idea): where would this func ID come from? It would need to be a
> property of the client DT node, then. So one way would be to use the func ID
> as the Linux mailbox channel ID:
> > mailbox: smc-mailbox {
> > #mbox-cells = <1>;
> > compatible = "arm,smc-mbox";
> > method = "smc";
> > };
> > scmi {
> > compatible = "arm,scmi";
> > mboxes = <&smc_mbox 0x82fe>;
> > mbox-names = "tx"; /* rx is optional */
> > shmem = <&cpu_scp_hpri>;
> > };
> >
> > But this doesn't look desirable.
> >
> > And as I mentioned this before: allowing some mailbox clients to provide
> the function IDs sound scary, as they could use anything they want, triggering
> random firmware actions (think PSCI_CPU_OFF).
> >
> That paranoia is unwarranted. We have to keep faith in kernel-space code
> doing the right thing.
> Either the illegitimate function request should be rejected by the firmware or
> client driver be called buggy just as we would call a block device driver
> buggy if it messed up the sector numbers in a write request.
> 
> thnx.

[PATCH V6 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

From: Peng Fan 

V6:
Switch to per-channel a mbox controller
Drop arm,num-chans, transports, method
Add arm,hvc-mbox compatible
Fix smc/hvc args, drop client id and use correct type.

V5:
yaml fix
https://patchwork.kernel.org/cover/7741/

V4:
yaml fix for num-chans in patch 1/2.
https://patchwork.kernel.org/cover/6521/

V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
 
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.

[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi




Peng Fan (2):
  dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.yaml   |  96 
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 167 +
 4 files changed, 272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.16.4

[PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

From: Peng Fan 

The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Peng Fan 
---
 .../devicetree/bindings/mailbox/arm-smc.yaml   | 96 ++
 1 file changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml 
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..bf01bec035fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+  - Peng Fan 
+
+description: |
+  This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+  call) instruction to trigger a mailbox-connected activity in firmware,
+  executing on the very same core as the caller. The value of r0/w0/x0
+  the firmware returns after the smc call is delivered as a received
+  message to the mailbox framework, so synchronous communication can be
+  established. The exact meaning of the action the mailbox triggers as
+  well as the return value is defined by their users and is not subject
+  to this binding.
+
+  One use case of this mailbox is the SCMI interface, which uses shared
+  memory to transfer commands and parameters, and a mailbox to trigger a
+  function call. This allows SoCs without a separate management processor
+  (or when such a processor is not available or used) to use this
+  standardized interface anyway.
+
+  This binding describes no hardware, but establishes a firmware interface.
+  Upon receiving an SMC using one of the described SMC function identifiers,
+  the firmware is expected to trigger some mailbox connected functionality.
+  The communication follows the ARM SMC calling convention.
+  Firmware expects an SMC function identifier in r0 or w0. The supported
+  identifiers are passed from consumers, or listed in the the arm,func-ids
+  properties as described below. The firmware can return one value in
+  the first SMC result register, it is expected to be an error value,
+  which shall be propagated to the mailbox client.
+
+  Any core which supports the SMC or HVC instruction can be used, as long
+  as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+  compatible:
+oneOf:
+  - description:
+  For implementations using ARM SMC instruction.
+const: arm,smc-mbox
+
+  - description:
+  For implementations using ARM HVC instruction.
+const: arm,hvc-mbox
+
+  "#mbox-cells":
+const: 1
+
+  arm,func-id:
+description: |
+  An 32-bit value specifying the function ID used by the mailbox.
+  The function ID follow the ARM SMC calling convention standard [1].
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+  - compatible
+  - "#mbox-cells"
+
+examples:
+  - |
+sram@93f000 {
+  compatible = "mmio-sram";
+  reg = <0x0 0x93f000 0x0 0x1000>;
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges = <0x0 0x93f000 0x1000>;
+
+  cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+  };
+};
+
+smc_tx_mbox: tx_mbox {
+  #mbox-cells = <1>;
+  compatible = "arm,smc-mbox";
+  /* optional */
+  arm,func-id = <0xc2fe>;
+};
+
+firmware {
+  scmi {
+compatible = "arm,scmi";
+mboxes = <&smc_tx_mbox 0>;
+mbox-names = "tx";
+shmem = <&cpu_scp_lpri>;
+  };
+};
+
+...
-- 
2.16.4

[PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

From: Peng Fan 

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Cc: Andre Przywara 
Signed-off-by: Peng Fan 
---
 drivers/mailbox/Kconfig   |   7 ++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 167 ++
 3 files changed, 176 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..c84aef39c8d9
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct arm_smc_chan_data {
+   unsigned int function_id;
+};
+
+struct arm_smccc_mbox_cmd {
+   unsigned int function_id;
+   union {
+   unsigned int args_smccc32[6];
+   unsigned long args_smccc64[6];
+   };
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   unsigned long ret;
+   u32 function_id;
+
+   function_id = chan_data->function_id;
+   if (!function_id)
+   function_id = cmd->function_id;
+
+   if (function_id & BIT(30)) {
+   ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
+cmd->args_smccc64[1],
+cmd->args_smccc64[2],
+cmd->args_smccc64[3],
+cmd->args_smccc64[4],
+cmd->args_smccc64[5]);
+   } else {
+   ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
+cmd->args_smccc32[1],
+cmd->args_smccc32[2],
+cmd->args_smccc32[3],
+cmd->args_smccc32[4],
+cmd->args_smccc32[5]);
+   }
+
+   mbox_chan_received_data(link, (void *)ret);
+
+   return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+   return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsi

RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux

[Peng Fan]

Hi Stephen, Shawn,

> Subject: [PATCH V3 0/4] clk: imx8m: fix glitch/mux

Sorry to ping early. Is there a chance to land this patchset in 5.3 release?

Thanks,
Peng.

> 
> From: Peng Fan 
> 
> V3:
>  Add cover-letter
> 
> V2:
>  Added patch [2,3,4]/4 and avoid glitch when prepare
> 
> There is two bypass bit in the pll, BYPASS and EXT_BYPASS.
> There is also a restriction that to avoid glitch, need set BYPASS bit when
> RESETB changed from 0 to 1, otherwise there will be glitch.
> 
> However the BYPASS bit is also used as mux bit in imx8mm/imx8mn clk driver.
> 
> This means two paths touch the same bit which is wrong. So switch to use
> EXT_BYPASS bit as the mux.
> 
> Peng Fan (4):
>   clk: imx: pll14xx: avoid glitch when set rate
>   clk: imx: clk-pll14xx: unbypass PLL by default
>   clk: imx: imx8mm: fix pll mux bit
>   clk: imx: imx8mn: fix pll mux bit
> 
>  drivers/clk/imx/clk-imx8mm.c  | 32 ++--
> drivers/clk/imx/clk-imx8mn.c  | 32 ++--
> drivers/clk/imx/clk-pll14xx.c | 27 ++-
>  3 files changed, 46 insertions(+), 45 deletions(-)
> 
> --
> 2.16.4

RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux

[Peng Fan]

Hi Stephen,

> Subject: RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux
> 
> Quoting Peng Fan (2019-09-16 23:20:15)
> > Hi Stephen, Shawn,
> >
> > > Subject: [PATCH V3 0/4] clk: imx8m: fix glitch/mux
> >
> > Sorry to ping early. Is there a chance to land this patchset in 5.3 release?
> >
> 
> No, it won't be in 5.3 because that version is released. Shawn already sent 
> the
> PR for 5.4 too so this will most likely be in v5.5 at the earliest.

Thanks for the info. But this patchset is bugfix, so hope this could be 
accepted in 5.4.

Thanks,
Peng.

RE: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Jassi,

> Subject: Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the
> ARM SMC/HVC mailbox
> 
> On Tue, Sep 17, 2019 at 12:31 PM Andre Przywara
>  wrote:
> >
> > On Mon, 16 Sep 2019 09:44:37 +
> > Peng Fan  wrote:
> >
> > Hi,
> >
> > > From: Peng Fan 
> > >
> > > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > > trigger actions in software layers running in the EL2 or EL3 exception
> levels.
> > > The term "ARM" here relates to the SMC instruction as part of the
> > > ARM instruction set, not as a standard endorsed by ARM Ltd.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 96
> ++
> > >  1 file changed, 96 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > > new file mode 100644
> > > index ..bf01bec035fc
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > > @@ -0,0 +1,96 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > > +---
> > > +$id:
> > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> > >
> +vicetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%
> 7C01
> > >
> +%7Cpeng.fan%40nxp.com%7Cf8065d24dd474238baf008d73bf8dc7a%7C686
> ea1d3
> > >
> +bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637043812342903260&sd
> ata=vC3
> > >
> +S8hvYDxDhNbIQoC44hpO5bw1yYZdBwu%2B%2Fp8mV0hI%3D&reserv
> ed=0
> > > +$schema:
> > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> > >
> +vicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7C
> peng.
> > >
> +fan%40nxp.com%7Cf8065d24dd474238baf008d73bf8dc7a%7C686ea1d3bc2
> b4c6f
> > >
> +a92cd99c5c301635%7C0%7C1%7C637043812342903260&sdata=IDHd
> vf1Mgw1
> > > +BR%2Bo4XJ%2BjQS%2Bx1pSBzADnW44B2hZLzKw%3D&reserved=0
> > > +
> > > +title: ARM SMC Mailbox Interface
> > > +
> > > +maintainers:
> > > +  - Peng Fan 
> > > +
> > > +description: |
> > > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > > +(hypervisor
> >
> > I think "or" instead of "and" is less confusing.
> >
> > > +  call) instruction to trigger a mailbox-connected activity in
> > > + firmware,  executing on the very same core as the caller. The
> > > + value of r0/w0/x0  the firmware returns after the smc call is
> > > + delivered as a received  message to the mailbox framework, so
> > > + synchronous communication can be  established. The exact meaning
> > > + of the action the mailbox triggers as  well as the return value is
> > > + defined by their users and is not subject  to this binding.
> > > +
> > > +  One use case of this mailbox is the SCMI interface, which uses
> > > + shared
> >
> >  One example use case of this mailbox ...
> > (to make it more obvious that it's not restricted to this)
> >
> > > +  memory to transfer commands and parameters, and a mailbox to
> > > + trigger a  function call. This allows SoCs without a separate
> > > + management processor  (or when such a processor is not available
> > > + or used) to use this  standardized interface anyway.
> > > +
> > > +  This binding describes no hardware, but establishes a firmware
> interface.
> > > +  Upon receiving an SMC using one of the described SMC function
> > > + identifiers,
> >
> >  ... the described SMC function
> > identifier,
> >
> > > +  the firmware is expected to trigger some mailbox connected
> functionality.
> > > +  The communication follows the ARM SMC calling convention.
> > > +  Firmware expects an SMC function identifier in r0 or w0. The
> > > + supported  identifiers are passed from consumers,
> >
> >  identifier
> >
> > "passed from consumers": How? Where?
> > But I want to repeat: We should not allow this.
> > This is a binding for a mailbox controller driver, not a generic firmware
> backdoor.
> >
> Exactly. The mailbox controller here is the  SMC/HVC instruction, wh

RE: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Andre,

> Subject: Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the
> ARM SMC/HVC mailbox
> 
> On Mon, 16 Sep 2019 09:44:37 +0000
> Peng Fan  wrote:
> 
> Hi,
> 
> > From: Peng Fan 
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception 
> > levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 96
> ++
> >  1 file changed, 96 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index ..bf01bec035fc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,96 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7Cff378bc3d622436c39ba08d73b94dfcc%7C686ea1d
> 3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C637043382928045369&sdata=rnx
> KdDGjPPd
> > +8VBI5WmgnZ3jxIjL2hcRYzbljfFxDkA0%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7Cff378bc3d622436c39ba08d73b94dfcc%7C686ea1d3bc2b4c6
> fa92cd9
> >
> +9c5c301635%7C0%7C1%7C637043382928045369&sdata=R02nWzpp9
> %2BrDYG9tA
> > +ot4pdWb8tGGHet1MOjrD0dEjwA%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > +  - Peng Fan 
> > +
> > +description: |
> > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> 
> I think "or" instead of "and" is less confusing.

ok

> 
> > +  call) instruction to trigger a mailbox-connected activity in
> > + firmware,  executing on the very same core as the caller. The value
> > + of r0/w0/x0  the firmware returns after the smc call is delivered as
> > + a received  message to the mailbox framework, so synchronous
> > + communication can be  established. The exact meaning of the action
> > + the mailbox triggers as  well as the return value is defined by
> > + their users and is not subject  to this binding.
> > +
> > +  One use case of this mailbox is the SCMI interface, which uses
> > + shared
> 
>  One example use case of this mailbox ...
> (to make it more obvious that it's not restricted to this)

ok

> 
> > +  memory to transfer commands and parameters, and a mailbox to
> > + trigger a  function call. This allows SoCs without a separate
> > + management processor  (or when such a processor is not available or
> > + used) to use this  standardized interface anyway.
> > +
> > +  This binding describes no hardware, but establishes a firmware
> interface.
> > +  Upon receiving an SMC using one of the described SMC function
> > + identifiers,
> 
>  ... the described SMC function identifier,

ok

> 
> > +  the firmware is expected to trigger some mailbox connected
> functionality.
> > +  The communication follows the ARM SMC calling convention.
> > +  Firmware expects an SMC function identifier in r0 or w0. The
> > + supported  identifiers are passed from consumers,
> 
>  identifier

ok

> 
> "passed from consumers": How? Where?
> But I want to repeat: We should not allow this. This is a binding for a 
> mailbox
> controller driver, not a generic firmware backdoor.

As Jassi suggested the function identifier as an optional for mailbox driver.
The driver should support function id passed from consumers.
Currently there is no users for such case that passed from consumers,
so I have no idea how.

> We should be as strict as possible to avoid any security issues.
> The firmware certainly knows the function ID it implements. The firmware
> controls the DT. So it is straight-forward to put the ID into the DT. The
> firmware could even do this at boot time, dynamically, before passing on the
> DT to the non-secure world (bootloader 

RE: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi Andre,

> Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Mon, 16 Sep 2019 09:44:41 +0000
> Peng Fan  wrote:
> 
> Hi,
> 
> looks quite good now, some smaller comments below.
> I think the only thing left is the "function ID passed by the client" topic.
> 
> Have you tried using this interface using hvc, for instance in KVM or Xen? For

No. I do not have that implementation in hypervisor.

> instance to provide access to a clock for a passed-through platform device?
> Another use case that pops up from time to time is GPIO for guests. This
> sounds like a use case for using the register interface, also we could use the
> hvc return value.
> 
> > From: Peng Fan 
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C58a1ed4078264d14958f08d73b95ed7e%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C1%7C637043387484474825&sdata=Cp1zlhlpQbg
> BsWu9ZDV
> > RKkXmd6kvUR%2BtPO7EPR7YLpA%3D&reserved=0
> >
> > Cc: Andre Przywara 
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/mailbox/Kconfig   |   7 ++
> >  drivers/mailbox/Makefile  |   2 +
> >  drivers/mailbox/arm-smc-mailbox.c | 167
> > ++
> >  3 files changed, 176 insertions(+)
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > ab4eb750bbdd..7707ee26251a 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -16,6 +16,13 @@ config ARM_MHU
> >   The controller has 3 mailbox channels, the last of which can be
> >   used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > +   tristate "Generic ARM smc mailbox"
> > +   depends on OF && HAVE_ARM_SMCCC
> > +   help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> >  config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
> >
> >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..c84aef39c8d9
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,167 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include  #include 
> > +#include 
> > +
> > +struct arm_smc_chan_data {
> > +   unsigned int function_id;
> > +};
> > +
> > +struct arm_smccc_mbox_cmd {
> > +   unsigned int function_id;
> > +   union {
> > +   unsigned int args_smccc32[6];
> > +   unsigned long args_smccc64[6];
> 
> Shouldn't this be u32 and u64 here, as the data type has this explicit length 
> in
> the SMCCC?

ok

> 
> > +   };
> > +};
> 
> If this is the data structure that this mailbox controller uses, I would 
> expect
> this to be documented somewhere, or even exported.

Export this structure in include/linux/mailbox/smc-mailbox.h?

> 
> And again, I don't l

RE: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

> Subject: Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the
> ARM SMC/HVC mailbox
> 
> On Wed, Sep 18, 2019 at 3:53 AM Peng Fan  wrote:
> 
> > > >
> > > > > +
> > > > > +  "#mbox-cells":
> > > > > +const: 1
> > > >
> > > > Why is this "1"? What is this number used for? It used to be the
> > > > channel ID,
> > > but since you are describing a single channel controller only, this
> > > should be 0 now.
> > > >
> > > Yes. I overlooked it and actually queued the patch for pull request.
> >
> > In Documentation/devicetree/bindings/mailbox/mailbox.txt
> > #mbox-cells: Must be at least 1.
> >
> > So I use 1 here, 0 not work. Because of_mbox_index_xlate expect at least 1
> here.
> > So I need modify Documentation/devicetree/bindings/mailbox/mailbox.txt
> > and add xlate for smc mailbox?
> >
> No, you just can not use the generic xlate() provided by the api.
> Please implement your own xlate() that requires no argument.

ok. Will add xlate.

Thanks,
Peng.

> 
> Cheers!

RE: [PATCH 2/2] nvmem: imx: scu: support write

[Peng Fan]

> Subject: [PATCH 2/2] nvmem: imx: scu: support write

Ping..

Thanks,
Peng.

> 
> From: Peng Fan 
> 
> The fuse programming from non-secure world is blocked, so we could only use
> Arm Trusted Firmware SIP call to let ATF program fuse.
> 
> Because there is ECC region that could only be programmed once, so add a
> heler in_ecc to check the ecc region.
> 
> Signed-off-by: Peng Fan 
> ---
> 
> The ATF patch will soon be posted to ATF community.
> 
>  drivers/nvmem/imx-ocotp-scu.c | 73
> ++-
>  1 file changed, 72 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
> index 2f339d7432e6..0f064f2e74a8 100644
> --- a/drivers/nvmem/imx-ocotp-scu.c
> +++ b/drivers/nvmem/imx-ocotp-scu.c
> @@ -7,6 +7,7 @@
>   * Peng Fan 
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -14,6 +15,9 @@
>  #include 
>  #include 
> 
> +#define IMX_SIP_OTP  0xC20A
> +#define IMX_SIP_OTP_WRITE0x2
> +
>  enum ocotp_devtype {
>   IMX8QXP,
>  };
> @@ -45,6 +49,8 @@ struct imx_sc_msg_misc_fuse_read {
>   u32 word;
>  } __packed;
> 
> +static DEFINE_MUTEX(scu_ocotp_mutex);
> +
>  static struct ocotp_devtype_data imx8qxp_data = {
>   .devtype = IMX8QXP,
>   .nregs = 800,
> @@ -73,6 +79,23 @@ static bool in_hole(void *context, u32 index)
>   return false;
>  }
> 
> +static bool in_ecc(void *context, u32 index) {
> + struct ocotp_priv *priv = context;
> + const struct ocotp_devtype_data *data = priv->data;
> + int i;
> +
> + for (i = 0; i < data->num_region; i++) {
> + if (data->region[i].flag & ECC_REGION) {
> + if ((index >= data->region[i].start) &&
> + (index <= data->region[i].end))
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
>u32 *val)
>  {
> @@ -116,6 +139,8 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
>   if (!p)
>   return -ENOMEM;
> 
> + mutex_lock(&scu_ocotp_mutex);
> +
>   buf = p;
> 
>   for (i = index; i < (index + count); i++) { @@ -126,6 +151,7 @@ static 
> int
> imx_scu_ocotp_read(void *context, unsigned int offset,
> 
>   ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
>   if (ret) {
> + mutex_unlock(&scu_ocotp_mutex);
>   kfree(p);
>   return ret;
>   }
> @@ -134,18 +160,63 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
> 
>   memcpy(val, (u8 *)p + offset % 4, bytes);
> 
> + mutex_unlock(&scu_ocotp_mutex);
> +
>   kfree(p);
> 
>   return 0;
>  }
> 
> +static int imx_scu_ocotp_write(void *context, unsigned int offset,
> +void *val, size_t bytes)
> +{
> + struct ocotp_priv *priv = context;
> + struct arm_smccc_res res;
> + u32 *buf = val;
> + u32 tmp;
> + u32 index;
> + int ret;
> +
> + /* allow only writing one complete OTP word at a time */
> + if ((bytes != 4) || (offset % 4))
> + return -EINVAL;
> +
> + index = offset >> 2;
> +
> + if (in_hole(context, index))
> + return -EINVAL;
> +
> + if (in_ecc(context, index)) {
> + pr_warn("ECC region, only program once\n");
> + mutex_lock(&scu_ocotp_mutex);
> + ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, index, &tmp);
> + mutex_unlock(&scu_ocotp_mutex);
> + if (ret)
> + return ret;
> + if (tmp) {
> + pr_warn("ECC region, already has value: %x\n", tmp);
> + return -EIO;
> + }
> + }
> +
> + mutex_lock(&scu_ocotp_mutex);
> +
> + arm_smccc_smc(IMX_SIP_OTP, IMX_SIP_OTP_WRITE, index, *buf,
> +   0, 0, 0, 0, &res);
> +
> + mutex_unlock(&scu_ocotp_mutex);
> +
> + return res.a0;
> +}
> +
>  static struct nvmem_config imx_scu_ocotp_nvmem_config = {
>   .name = "imx-scu-ocotp",
> - .read_only = true,
> + .read_only = false,
>   .word_size = 4,
>   .stride = 1,
>   .owner = THIS_MODULE,
>   .reg_read = imx_scu_ocotp_read,
> + .reg_write = imx_scu_ocotp_write,
>  };
> 
>  static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> --
> 2.16.4

RE: [PATCH 1/2] nvmem: imx: scu: support hole region check

[Peng Fan]

> Subject: [PATCH 1/2] nvmem: imx: scu: support hole region check

Ping..

Thanks,
Peng.

> 
> From: Peng Fan 
> 
> Introduce HOLE/ECC_REGION flag and in_hole helper to ease the check of
> hole region. The ECC_REGION is also introduced here which is preparing for
> programming support. ECC_REGION could only be programmed once, so need
> take care.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/nvmem/imx-ocotp-scu.c | 42
> +-
>  1 file changed, 37 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
> index d9dc482ecb2f..2f339d7432e6 100644
> --- a/drivers/nvmem/imx-ocotp-scu.c
> +++ b/drivers/nvmem/imx-ocotp-scu.c
> @@ -18,9 +18,20 @@ enum ocotp_devtype {
>   IMX8QXP,
>  };
> 
> +#define ECC_REGION   BIT(0)
> +#define HOLE_REGION  BIT(1)
> +
> +struct ocotp_region {
> + u32 start;
> + u32 end;
> + u32 flag;
> +};
> +
>  struct ocotp_devtype_data {
>   int devtype;
>   int nregs;
> + u32 num_region;
> + struct ocotp_region region[];
>  };
> 
>  struct ocotp_priv {
> @@ -37,8 +48,31 @@ struct imx_sc_msg_misc_fuse_read {  static struct
> ocotp_devtype_data imx8qxp_data = {
>   .devtype = IMX8QXP,
>   .nregs = 800,
> + .num_region = 3,
> + .region = {
> + {0x10, 0x10f, ECC_REGION},
> + {0x110, 0x21F, HOLE_REGION},
> + {0x220, 0x31F, ECC_REGION},
> + },
>  };
> 
> +static bool in_hole(void *context, u32 index) {
> + struct ocotp_priv *priv = context;
> + const struct ocotp_devtype_data *data = priv->data;
> + int i;
> +
> + for (i = 0; i < data->num_region; i++) {
> + if (data->region[i].flag & HOLE_REGION) {
> + if ((index >= data->region[i].start) &&
> + (index <= data->region[i].end))
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
>u32 *val)
>  {
> @@ -85,11 +119,9 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
>   buf = p;
> 
>   for (i = index; i < (index + count); i++) {
> - if (priv->data->devtype == IMX8QXP) {
> - if ((i > 271) && (i < 544)) {
> - *buf++ = 0;
> - continue;
> - }
> + if (in_hole(context, i)) {
> + *buf++ = 0;
> + continue;
>   }
> 
>   ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
> --
> 2.16.4

[PATCH V3 0/4] clk: imx8m: fix glitch/mux

[Peng Fan]

From: Peng Fan 

V3:
 Add cover-letter

V2:
 Added patch [2,3,4]/4 and avoid glitch when prepare

There is two bypass bit in the pll, BYPASS and EXT_BYPASS.
There is also a restriction that to avoid glitch, need set BYPASS
bit when RESETB changed from 0 to 1, otherwise there will be glitch.

However the BYPASS bit is also used as mux bit in imx8mm/imx8mn clk driver.

This means two paths touch the same bit which is wrong. So switch to use
EXT_BYPASS bit as the mux.

Peng Fan (4):
  clk: imx: pll14xx: avoid glitch when set rate
  clk: imx: clk-pll14xx: unbypass PLL by default
  clk: imx: imx8mm: fix pll mux bit
  clk: imx: imx8mn: fix pll mux bit

 drivers/clk/imx/clk-imx8mm.c  | 32 ++--
 drivers/clk/imx/clk-imx8mn.c  | 32 ++--
 drivers/clk/imx/clk-pll14xx.c | 27 ++-
 3 files changed, 46 insertions(+), 45 deletions(-)

-- 
2.16.4

[PATCH V3 1/4] clk: imx: pll14xx: avoid glitch when set rate

[Peng Fan]

From: Peng Fan 

According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."

So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.

When prepare clock, also need to take care to avoid glitch. So
we also follow Spec to set BYPASS before RESETB changed from 0 to 1.
And add a check if the RESETB is already 0, directly return 0;

Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V3:
 None
V2:
  Avoid glitch when prepare
  update commit log

 drivers/clk/imx/clk-pll14xx.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..656f48b002dd 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw, 
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
 
+   /* Enable BYPASS */
+   tmp |= BYPASS_MASK;
+   writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw, 
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
 
+   /* Enable BYPASS */
+   tmp |= BYPASS_MASK;
+   writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -283,16 +291,28 @@ static int clk_pll14xx_prepare(struct clk_hw *hw)
 {
struct clk_pll14xx *pll = to_clk_pll14xx(hw);
u32 val;
+   int ret;
 
/*
 * RESETB = 1 from 0, PLL starts its normal
 * operation after lock time
 */
val = readl_relaxed(pll->base + GNRL_CTL);
+   if (val & RST_MASK)
+   return 0;
+   val |= BYPASS_MASK;
+   writel_relaxed(val, pll->base + GNRL_CTL);
val |= RST_MASK;
writel_relaxed(val, pll->base + GNRL_CTL);
 
-   return clk_pll14xx_wait_lock(pll);
+   ret = clk_pll14xx_wait_lock(pll);
+   if (ret)
+   return ret;
+
+   val &= ~BYPASS_MASK;
+   writel_relaxed(val, pll->base + GNRL_CTL);
+
+   return 0;
 }
 
 static int clk_pll14xx_is_prepared(struct clk_hw *hw)
-- 
2.16.4

[PATCH V3 3/4] clk: imx: imx8mm: fix pll mux bit

[Peng Fan]

From: Peng Fan 

pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.

So use EXT_BYPASS bit here.

And drop uneeded set parent, because EXT_BYPASS default is 0.

Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Suggested-by: Jacky Bai 
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V3:
 None
V2:
 New patch


 drivers/clk/imx/clk-imx8mm.c | 32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 2758e3f0d15d..067ab876911d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -408,28 +408,16 @@ static int imx8mm_clocks_probe(struct platform_device 
*pdev)
clks[IMX8MM_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", 
base + 0x114, &imx8mm_sys_pll);
 
/* PLL bypass out */
-   clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass", 
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass", 
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass", 
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), 
CLK_SET_RATE_PARENT);
-
-   /* unbypass all the plls */
-   clk_set_parent(clks[IMX8MM_AUDIO_PLL1_BYPASS], clks[IMX8MM_AUDIO_PLL1]);
-   clk_set_parent(clks[IMX8MM_AUDIO_PLL2_BYPASS], clks[IMX8MM_AUDIO_PLL2]);
-   clk_set_parent(clks[IMX8MM_VIDEO_PLL1_BYPASS], clks[IMX8MM_VIDEO_PLL1]);
-   clk_set_parent(clks[IMX8MM_DRAM_PLL_BYPASS], clks[IMX8MM_DRAM_PLL]);
-   clk_set_parent(clks[IMX8MM_GPU_PLL_BYPASS], clks[IMX8MM_GPU_PLL]);
-   clk_set_parent(clks[IMX8MM_VPU_PLL_BYPASS], clks[IMX8MM_VPU_PLL]);
-   clk_set_parent(clks[IMX8MM_ARM_PLL_BYPASS], clks[IMX8MM_ARM_PLL]);
-   clk_set_parent(clks[IMX8MM_SYS_PLL1_BYPASS], clks[IMX8MM_SYS_PLL1]);
-   clk_set_parent(clks[IMX8MM_SYS_PLL2_BYPASS], clks[IMX8MM_SYS_PLL2]);
-   clk_set_parent(clks[IMX8MM_SYS_PLL3_BYPASS], clks[IMX8MM_SYS_PLL3]);
+   clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 28, 1, arm_pll_bypass_sels, AR

[PATCH V3 4/4] clk: imx: imx8mn: fix pll mux bit

[Peng Fan]

From: Peng Fan 

pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.

So use EXT_BYPASS bit here.

And drop uneeded set parent, because EXT_BYPASS default is 0.

Suggested-by: Jacky Bai 
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V3:
 None
V2:
 New patch

 drivers/clk/imx/clk-imx8mn.c | 32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index f41116d59749..f767d18679ea 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -421,28 +421,16 @@ static int imx8mn_clocks_probe(struct platform_device 
*pdev)
clks[IMX8MN_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", 
base + 0x114, &imx8mn_sys_pll);
 
/* PLL bypass out */
-   clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass", 
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass", 
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass", 
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), 
CLK_SET_RATE_PARENT);
-
-   /* unbypass all the plls */
-   clk_set_parent(clks[IMX8MN_AUDIO_PLL1_BYPASS], clks[IMX8MN_AUDIO_PLL1]);
-   clk_set_parent(clks[IMX8MN_AUDIO_PLL2_BYPASS], clks[IMX8MN_AUDIO_PLL2]);
-   clk_set_parent(clks[IMX8MN_VIDEO_PLL1_BYPASS], clks[IMX8MN_VIDEO_PLL1]);
-   clk_set_parent(clks[IMX8MN_DRAM_PLL_BYPASS], clks[IMX8MN_DRAM_PLL]);
-   clk_set_parent(clks[IMX8MN_GPU_PLL_BYPASS], clks[IMX8MN_GPU_PLL]);
-   clk_set_parent(clks[IMX8MN_VPU_PLL_BYPASS], clks[IMX8MN_VPU_PLL]);
-   clk_set_parent(clks[IMX8MN_ARM_PLL_BYPASS], clks[IMX8MN_ARM_PLL]);
-   clk_set_parent(clks[IMX8MN_SYS_PLL1_BYPASS], clks[IMX8MN_SYS_PLL1]);
-   clk_set_parent(clks[IMX8MN_SYS_PLL2_BYPASS], clks[IMX8MN_SYS_PLL2]);
-   clk_set_parent(clks[IMX8MN_SYS_PLL3_BYPASS], clks[IMX8MN_SYS_PLL3]);
+   clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_SYS_PLL1_BYPASS] =

RE: [PATCH V2 1/4] clk: imx: pll14xx: avoid glitch when set rate

[Peng Fan]

Hi Stephen,

> Subject: Re: [PATCH V2 1/4] clk: imx: pll14xx: avoid glitch when set rate
> 
> Quoting Peng Fan (2019-08-26 02:42:14)
> > From: Peng Fan 
> >
> > According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB
> > is changed from 0 to 1, FOUT starts to output unstable clock until
> > lock time passes. PLL1416X/PLL1443XA may generate a glitch at FOUT."
> >
> > So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
> > In the end of set rate, BYPASS will be cleared.
> >
> > When prepare clock, also need to take care to avoid glitch. So we also
> > follow Spec to set BYPASS before RESETB changed from 0 to 1.
> > And add a check if the RESETB is already 0, directly return 0;
> >
> > Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
> > Reviewed-by: Leonard Crestez 
> > Signed-off-by: Peng Fan 
> > ---
> 
> Please make cover letters for multi-patch series.

Just sent out v3 to include cover-letter, no other changes.

Thanks,
Peng.

[PATCH V3 2/4] clk: imx: clk-pll14xx: unbypass PLL by default

[Peng Fan]

From: Peng Fan 

When registering the PLL, unbypass the PLL.
The PLL has two bypass control bit, BYPASS and EXT_BYPASS.
we will expose EXT_BYPASS to clk driver for mux usage, and keep
BYPASS inside pll14xx usage. The PLL has a restriction that
when M/P change, need to RESET/BYPASS pll to avoid glitch, so
we could not expose BYPASS.

To make it easy for clk driver usage, unbypass PLL which does
not hurt current function.

Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V3:
 None
V2:
 New patch


 drivers/clk/imx/clk-pll14xx.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 656f48b002dd..7a815ec76aa5 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -368,6 +368,7 @@ struct clk *imx_clk_pll14xx(const char *name, const char 
*parent_name,
struct clk_pll14xx *pll;
struct clk *clk;
struct clk_init_data init;
+   u32 val;
 
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
@@ -399,6 +400,10 @@ struct clk *imx_clk_pll14xx(const char *name, const char 
*parent_name,
pll->rate_table = pll_clk->rate_table;
pll->rate_count = pll_clk->rate_count;
 
+   val = readl_relaxed(pll->base + GNRL_CTL);
+   val &= ~BYPASS_MASK;
+   writel_relaxed(val, pll->base + GNRL_CTL);
+
clk = clk_register(NULL, &pll->hw);
if (IS_ERR(clk)) {
pr_err("%s: failed to register pll %s %lu\n",
-- 
2.16.4

[PATCH] clk: imx: imx8mm: fix audio pll setting

[Peng Fan]

From: Peng Fan 

The AUDIO PLL max support 650M, so the original clk settings violate
spec. This patch makes the output 786432000 -> 393216000,
and 722534400 -> 361267200 to aligned with NXP vendor kernel without any
impact on audio functionality and go within 650MHz PLL limit.

Cc: 
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan 
---
 drivers/clk/imx/clk-imx8mm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 3a873e0e278f..b72bad064d8d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -55,8 +55,8 @@ static const struct imx_pll14xx_rate_table 
imx8mm_pll1416x_tbl[] = {
 };
 
 static const struct imx_pll14xx_rate_table imx8mm_audiopll_tbl[] = {
-   PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
-   PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+   PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
+   PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
 };
 
 static const struct imx_pll14xx_rate_table imx8mm_videopll_tbl[] = {
-- 
2.16.4

[PATCH v3 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

From: Peng Fan 

V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
 
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.

[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi

Peng Fan (2):
  dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.yaml   | 124 
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 215 +
 4 files changed, 348 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.16.4

[PATCH v3 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

From: Peng Fan 

The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Peng Fan 
---

V3:
 Convert to yaml
 Drop interrupt
 Introudce transports to indicate mem/reg
 The func id is still kept as optional, because like SCMI it only
 cares about message.

V2:
 Introduce interrupts as a property.

 .../devicetree/bindings/mailbox/arm-smc.yaml   | 124 +
 1 file changed, 124 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml 
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..da9b1a03bc4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+  - Peng Fan 
+
+description: |
+  This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+  call) instruction to trigger a mailbox-connected activity in firmware,
+  executing on the very same core as the caller. By nature this operation
+  is synchronous and this mailbox provides no way for asynchronous messages
+  to be delivered the other way round, from firmware to the OS, but
+  asynchronous notification could also be supported. However the value of
+  r0/w0/x0 the firmware returns after the smc call is delivered as a received
+  message to the mailbox framework, so a synchronous communication can be
+  established, for a asynchronous notification, no value will be returned.
+  The exact meaning of both the action the mailbox triggers as well as the
+  return value is defined by their users and is not subject to this binding.
+
+  One use case of this mailbox is the SCMI interface, which uses shared memory
+  to transfer commands and parameters, and a mailbox to trigger a function
+  call. This allows SoCs without a separate management processor (or when
+  such a processor is not available or used) to use this standardized
+  interface anyway.
+
+  This binding describes no hardware, but establishes a firmware interface.
+  Upon receiving an SMC using one of the described SMC function identifiers,
+  the firmware is expected to trigger some mailbox connected functionality.
+  The communication follows the ARM SMC calling convention.
+  Firmware expects an SMC function identifier in r0 or w0. The supported
+  identifiers are passed from consumers, or listed in the the arm,func-ids
+  properties as described below. The firmware can return one value in
+  the first SMC result register, it is expected to be an error value,
+  which shall be propagated to the mailbox client.
+
+  Any core which supports the SMC or HVC instruction can be used, as long as
+  a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+  compatible:
+const: arm,smc-mbox
+
+  "#mbox-cells":
+const: 1
+
+  arm,num-chans:
+description: The number of channels supported.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  method:
+items:
+  - enum:
+  - smc
+  - hvc
+
+  transports:
+items:
+  - enum:
+  - mem
+  - reg
+
+  arm,func-ids:
+description: |
+  An array of 32-bit values specifying the function IDs used by each
+  mailbox channel. Those function IDs follow the ARM SMC calling
+  convention standard [1].
+
+  There is one identifier per channel and the number of supported
+  channels is determined by the length of this array.
+minItems: 0
+maxItems: 4096   # Should be enough?
+
+required:
+  - compatible
+  - "#mbox-cells"
+  - arm,num-chans
+  - transports
+  - method
+
+examples:
+  - |
+sram@91 {
+  compatible = "mmio-sram";
+  reg = <0x0 0x93f000 0x0 0x1000>;
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges = <0 0x0 0x93f000 0x1000>;
+
+cpu_scp_lpri: scp-shmem@0 {
+  compatible = "arm,scmi-shmem";
+  reg = <0x0 0x200>;
+};
+
+cpu_scp_hpri: scp-shmem@200 {
+  compatible = "arm,scmi-shmem";
+  reg = <0x200 0x200>;
+};
+};
+
+firmware {
+  smc_mbox: mailbox {
+#mbox-cells = <1>;
+compatible = "arm,smc-mbox";
+method = "smc";
+arm,num-chans = <0x2>;
+transports = "mem";
+/* Optional */
+arm,func-ids = <0xc2fe>, <0xc2ff>;
+  };
+
+  scmi {
+ 

[PATCH v3 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

From: Peng Fan 

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Cc: Andre Przywara 
Signed-off-by: Peng Fan 
---

V3:
 Drop interrupt.
 Introduce transports for mem/reg usage.
 Add chan-id for mem usage.

V2:
 Add interrupts notification support.

 drivers/mailbox/Kconfig   |   7 ++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 215 ++
 3 files changed, 224 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 595542bfae85..c3bd0f1ddcd8 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+   u32 function_id;
+   u32 chan_id;
+   u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+   unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   unsigned long ret;
+   u32 function_id;
+   u32 chan_id;
+
+   if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+   if (chan_data->function_id != UINT_MAX)
+   function_id = chan_data->function_id;
+   else
+   function_id = cmd->a0;
+   chan_id = chan_data->chan_id;
+   ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+0, 0);
+   } else {
+   ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+   }
+
+   mbox_chan_received_data(link, (void *)ret);
+
+   return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &res);
+   return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+

[PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

From: Peng Fan 

V10:
 - Add R-b tag from Andre, Rob and Florian
 - Two minor fixes
  - Drop "passed from consumers" in patch 1/2 per Andre's comments
  - Drop interrupts.h in patch 2/2 per Andre's comments

V9:
 - Add Florian's R-b tag in patch 1/2
 - Mark arm,func-id as a required property per Andre's comments in patch 1/2.
 - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's
   comments in pach 2/2
 - Include linux/types.h in arm-smccc-mbox.h in patch 2/2
 - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT
   in patch 2/2/.

   Andre,
I have marked arm,func-id as a required property and dropped function-id
from client, please see whether you are happy with the patchset.
Hope we could finalize and get patches land in.

   Thanks,
   Peng.

V8:
Add missed arm-smccc-mbox.h

V7:
Typo fix
#mbox-cells changed to 0
Add a new header file arm-smccc-mbox.h
Use ARM_SMCCC_IS_64

Andre,
  The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id
property is optional, so clients could pass function_id to mbox driver.

V6:
Switch to per-channel a mbox controller
Drop arm,num-chans, transports, method
Add arm,hvc-mbox compatible
Fix smc/hvc args, drop client id and use correct type.
https://patchwork.kernel.org/cover/11146641/

V5:
yaml fix
https://patchwork.kernel.org/cover/7741/

V4:
yaml fix for num-chans in patch 1/2.
https://patchwork.kernel.org/cover/6521/

V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/

V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.

[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi



Peng Fan (2):
  dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.yaml   |  96 
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 166 +
 include/linux/mailbox/arm-smccc-mbox.h |  20 +++
 5 files changed, 291 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smccc-mbox.h

-- 
2.16.4

[PATCH V10 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

From: Peng Fan 

The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Reviewed-by: Rob Herring 
Reviewed-by: Andre Przywara 
Reviewed-by: Florian Fainelli 
Signed-off-by: Peng Fan 
---
 .../devicetree/bindings/mailbox/arm-smc.yaml   | 96 ++
 1 file changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml 
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..c165946a64e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+  - Peng Fan 
+
+description: |
+  This mailbox uses the ARM smc (secure monitor call) or hvc (hypervisor
+  call) instruction to trigger a mailbox-connected activity in firmware,
+  executing on the very same core as the caller. The value of r0/w0/x0
+  the firmware returns after the smc call is delivered as a received
+  message to the mailbox framework, so synchronous communication can be
+  established. The exact meaning of the action the mailbox triggers as
+  well as the return value is defined by their users and is not subject
+  to this binding.
+
+  One example use case of this mailbox is the SCMI interface, which uses
+  shared memory to transfer commands and parameters, and a mailbox to
+  trigger a function call. This allows SoCs without a separate management
+  processor (or when such a processor is not available or used) to use
+  this standardized interface anyway.
+
+  This binding describes no hardware, but establishes a firmware interface.
+  Upon receiving an SMC using the described SMC function identifier, the
+  firmware is expected to trigger some mailbox connected functionality.
+  The communication follows the ARM SMC calling convention.
+  Firmware expects an SMC function identifier in r0 or w0. The supported
+  identifier is listed in the the arm,func-id property as described below.
+  The firmware can return one value in the first SMC result register,
+  it is expected to be an error value, which shall be propagated to the
+  mailbox client.
+
+  Any core which supports the SMC or HVC instruction can be used, as long
+  as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+  compatible:
+oneOf:
+  - description:
+  For implementations using ARM SMC instruction.
+const: arm,smc-mbox
+
+  - description:
+  For implementations using ARM HVC instruction.
+const: arm,hvc-mbox
+
+  "#mbox-cells":
+const: 0
+
+  arm,func-id:
+description: |
+  An single 32-bit value specifying the function ID used by the mailbox.
+  The function ID follows the ARM SMC calling convention standard.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+  - compatible
+  - "#mbox-cells"
+  - arm,func-id
+
+examples:
+  - |
+sram@93f000 {
+  compatible = "mmio-sram";
+  reg = <0x0 0x93f000 0x0 0x1000>;
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges = <0x0 0x93f000 0x1000>;
+
+  cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+  };
+};
+
+smc_tx_mbox: tx_mbox {
+  #mbox-cells = <0>;
+  compatible = "arm,smc-mbox";
+  arm,func-id = <0xc2fe>;
+};
+
+firmware {
+  scmi {
+compatible = "arm,scmi";
+mboxes = <&smc_tx_mbox>;
+mbox-names = "tx";
+shmem = <&cpu_scp_lpri>;
+  };
+};
+
+...
-- 
2.16.4

[PATCH V10 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

From: Peng Fan 

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Reviewed-by: Florian Fainelli 
Reviewed-by: Andre Przywara 
Signed-off-by: Peng Fan 
---
 drivers/mailbox/Kconfig|   7 ++
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 166 +
 include/linux/mailbox/arm-smccc-mbox.h |  20 
 4 files changed, 195 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smccc-mbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..a6ec56f41f7f
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long);
+
+struct arm_smc_chan_data {
+   unsigned int function_id;
+   smc_mbox_fn *invoke_smc_mbox_fn;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   unsigned long ret;
+
+   if (ARM_SMCCC_IS_64(chan_data->function_id)) {
+   ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id,
+   cmd->args_smccc64[0],
+   cmd->args_smccc64[1],
+   cmd->args_smccc64[2],
+   cmd->args_smccc64[3],
+   cmd->args_smccc64[4],
+   cmd->args_smccc64[5]);
+   } else {
+   ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id,
+   cmd->args_smccc32[0],
+   cmd->args_smccc32[1],
+   cmd->args_smccc32[2],
+   cmd->args_smccc32[3],
+   cmd->args_smccc32[4],
+   cmd->args_smccc32[5]);
+   }
+
+   mbox_chan_received_data(link, (void *)ret);
+
+   return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+   return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsig

RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64

[Peng Fan]

Hi Stefano,

> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> 
> On Wed, 28 Aug 2019, Peng Fan wrote:
> > Hi Robin,
> >
> > > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> > >
> > > On 09/07/2019 09:22, Peng Fan wrote:
> > > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > > However ZONE_DMA is removed by commit
> > > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > > So to ARM64, need use __GFP_DMA32.
> 
> Hi Peng,
> 
> Sorry for being so late in replying, this email got lost in the noise.
> 
> 
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >   arch/arm/xen/mm.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > > e1d44b903dfc..a95e76d18bf9 100644
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > > @@ -27,7 +27,7 @@ unsigned long
> > > > xen_get_swiotlb_free_pages(unsigned
> > > > int order)
> > > >
> > > > for_each_memblock(memory, reg) {
> > > > if (reg->base < (phys_addr_t)0x) {
> > > > -   flags |= __GFP_DMA;
> > > > +   flags |= __GFP_DMA | __GFP_DMA32;
> > >
> > > Given the definition of GFP_ZONE_BAD, I'm not sure this combination
> > > of flags is strictly valid, but rather is implicitly reliant on only
> > > one of those zones ever actually existing. As such, it seems liable
> > > to blow up if the plans to add ZONE_DMA to arm64[1] go ahead.
> >
> > How about this, or do you have any suggestions?
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > d33b77e9add3..f61c29a4430f 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0x) {
> > +#ifdef CONFIG_ARM64
> > +   flags |= __GFP_DMA32; #else
> > flags |= __GFP_DMA;
> > +#endif
> > break;
> > }
> > }
> 
> Yes I think this is the way to go, but we are trying not to add any #ifdef
> CONFIG_ARM64 under arch/arm. Maybe you could introduce a static inline
> function to set GFP_DMA:
> 
>   static inline void xen_set_gfp_dma(gfp_t *flags)
> 
> it could be implemented under arch/arm/include/asm/xen/page.h for arm
> and under arch/arm64/include/asm/xen/page.h for arm64 using __GFP_DMA
> for the former and __GFP_DMA32 for the latter.

Thanks for your suggestion. I'll use this in V2.

Thanks,
Peng.

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote:
> > From: Peng Fan 
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception 
> > levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 125
> +
> >  1 file changed, 125 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index ..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1
> d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C637025974936865698&sdata=Inp
> %2FLs39m
> > +Gv1fe3dZMSaGmgmyWPT6awPh47s3mEtQ%2BQ%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1d3bc2b4c
> 6fa92cd9
> >
> +9c5c301635%7C0%7C1%7C637025974936865698&sdata=jmoR1Qqm7
> 6N5NwDbgFE
> > +Fm8cpdW%2B%2FgqmG9mSGz9mXv58%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > +  - Peng Fan 
> > +
> > +description: |
> > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > +  call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > +  executing on the very same core as the caller. By nature this
> > +operation
> > +  is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > +  to be delivered the other way round, from firmware to the OS, but
> 
> 
> > +  asynchronous notification could also be supported.
> 
> What do you mean by that ? I would prefer to drop the above line unless I am

Ok. Dropped it in v6.

> missing something. IMO it contradicts the previous statement less you
> elaborate more on this.
> 
> > However the value of
> > +  r0/w0/x0 the firmware returns after the smc call is delivered as a
> > + received  message to the mailbox framework, so a synchronous
> > + communication can be  established, for a asynchronous notification, no
> value will be returned.
> 
> I assume you refer to asynchronous communication from OS to firmware in
> the above statement and "not asynchronous notification" from firmware to
> OS.

Since asynchronous notification dropped, so it should only be
synchronous communication could be established. So I'll
modify it as below:

r0/w0/x0 the firmware returns after the smc call is delivered as a received
message to the mailbox framework, so synchronous communication can be
established

> 
> > +  The exact meaning of both the action the mailbox triggers as well
> > + as the  return value is defined by their users and is not subject to this
> binding.
> > +
> > +  One use case of this mailbox is the SCMI interface, which uses
> > + shared memory  to transfer commands and parameters, and a mailbox
> to
> > + trigger a function  call. This allows SoCs without a separate
> > + management processor (or when  such a processor is not available or
> > + used) to use this standardized  interface anyway.
> > +
> 
> Not sure if reference to SCMI is needed at all but I don't have any objections
> to it, just thought worth mentioning.
> 
> > +  This binding describes no hardware, but establishes a firmware
> interface.
> > +  Upon receiving an SMC using one of the described SMC function
> > + identifiers,  the firmware is expected to trigger some mailbox connected
> functionality.
> > +  The communication follows the ARM SMC calling convention.
> > +  Firmware expects an SMC function identifier in r0 or w0. The

RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Wed, Aug 28, 2019 at 03:03:02AM +0000, Peng Fan wrote:
> > From: Peng Fan 
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Ca1e96c6b782d43b2cfb208d72bc05898%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637025977487779923&sdata=rzC%2B4Y1c
> q9Y3tSDFR
> > %2Fsvf5ktk7INP2rwXN%2BXdWCVjNs%3D&reserved=0
> >
> > Cc: Andre Przywara 
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/mailbox/Kconfig   |   7 ++
> >  drivers/mailbox/Makefile  |   2 +
> >  drivers/mailbox/arm-smc-mailbox.c | 215
> > ++
> >  3 files changed, 224 insertions(+)
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
> 
> [...]
> 
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > +   struct device *dev = &pdev->dev;
> > +   struct mbox_controller *mbox;
> > +   struct arm_smc_chan_data *chan_data;
> > +   const char *method;
> > +   bool mem_trans = false;
> > +   int ret, i;
> > +   u32 val;
> > +
> > +   if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
> > +   if (!val) {
> > +   dev_err(dev, "invalid arm,num-chans value %u\n", val);
> > +   return -EINVAL;
> > +   }
> > +   } else {
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (!of_property_read_string(dev->of_node, "transports", &method)) {
> > +   if (!strcmp("mem", method)) {
> > +   mem_trans = true;
> > +   } else if (!strcmp("reg", method)) {
> > +   mem_trans = false;
> > +   } else {
> > +   dev_warn(dev, "invalid \"transports\" property: %s\n",
> > +method);
> > +
> > +   return -EINVAL;
> > +   }
> > +   } else {
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (!of_property_read_string(dev->of_node, "method", &method)) {
> > +   if (!strcmp("hvc", method)) {
> > +   invoke_smc_mbox_fn = __invoke_fn_hvc;
> > +   } else if (!strcmp("smc", method)) {
> > +   invoke_smc_mbox_fn = __invoke_fn_smc;
> > +   } else {
> > +   dev_warn(dev, "invalid \"method\" property: %s\n",
> > +method);
> > +
> > +   return -EINVAL;
> > +   }
> > +   } else {
> > +   return -EINVAL;
> > +   }
> > +
> > +   mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > +   if (!mbox)
> > +   return -ENOMEM;
> > +
> > +   mbox->num_chans = val;
> > +   mbox->chans = devm_kcalloc(dev, mbox->num_chans,
> sizeof(*mbox->chans),
> > +  GFP_KERNEL);
> > +   if (!mbox->chans)
> > +   return -ENOMEM;
> > +
> > +   chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> > +GFP_KERNEL);
> > +   if (!chan_data)
> > +   return -ENOMEM;
> > +
> > +   for (i = 0; i < mbox->num_chans; i++) {
> > +   u32 function_id;
> > +
> > +   ret = of_property_read_u32_index(dev->of_node,
> > +"arm,func-ids", i,
> > +&function_id);
> 
> I missed it in binding but I thought we agreed to make this "arm,func-ids"
> a required property and not optional ?

Not sure Jassi is fine with it being a required property, but I could convert
it to a required property in V6.

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Jassi,

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Tue, Aug 27, 2019 at 10:02 PM Peng Fan  wrote:
> >
> > From: Peng Fan 
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception 
> > levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 125
> +
> >  1 file changed, 125 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index ..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d
> 3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C637027415448196145&sdata=xd
> nUObNqlRF
> > +lu8NiXSuc35fYrHIzR%2Fyak6IzW05Q3nA%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d3bc2b4c6
> fa92cd9
> >
> +9c5c301635%7C0%7C1%7C637027415448196145&sdata=wl%2Fdg09
> QMS%2FoHgI
> > +yD7ZBNpoIGXYxfFDRWhyYHogFd6A%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > +  - Peng Fan 
> > +
> > +description: |
> > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > +  call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > +  executing on the very same core as the caller. By nature this
> > +operation
> > +  is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > +  to be delivered the other way round, from firmware to the OS, but
> > +  asynchronous notification could also be supported. However the
> > +value of
> > +  r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received
> > +  message to the mailbox framework, so a synchronous communication
> > +can be
> > +  established, for a asynchronous notification, no value will be returned.
> > +  The exact meaning of both the action the mailbox triggers as well
> > +as the
> > +  return value is defined by their users and is not subject to this 
> > binding.
> > +
> > +  One use case of this mailbox is the SCMI interface, which uses
> > + shared memory  to transfer commands and parameters, and a mailbox
> to
> > + trigger a function  call. This allows SoCs without a separate
> > + management processor (or when  such a processor is not available or
> > + used) to use this standardized  interface anyway.
> > +
> > +  This binding describes no hardware, but establishes a firmware
> interface.
> > +  Upon receiving an SMC using one of the described SMC function
> > + identifiers,  the firmware is expected to trigger some mailbox connected
> functionality.
> > +  The communication follows the ARM SMC calling convention.
> > +  Firmware expects an SMC function identifier in r0 or w0. The
> > + supported  identifiers are passed from consumers, or listed in the
> > + the arm,func-ids  properties as described below. The firmware can
> > + return one value in  the first SMC result register, it is expected
> > + to be an error value,  which shall be propagated to the mailbox client.
> > +
> > +  Any core which supports the SMC or HVC instruction can be used, as
> > + long as  a firmware component running in EL3 or EL2 is handling these
> calls.
> > +
> > +properties:
> > +  compatible:
> > +const: arm,smc-mbox
> > +
> > +  "#mbox-cells":
> > +const: 1
> > +
> > +  arm,num-chans:
> > +description: The number of channels supported.
> > +items:
> > + 

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Jassi,

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Fri, Aug 30, 2019 at 1:28 AM Peng Fan  wrote:
> 
> > > > +examples:
> > > > +  - |
> > > > +sram@91 {
> > > > +  compatible = "mmio-sram";
> > > > +  reg = <0x0 0x93f000 0x0 0x1000>;
> > > > +  #address-cells = <1>;
> > > > +  #size-cells = <1>;
> > > > +  ranges = <0 0x0 0x93f000 0x1000>;
> > > > +
> > > > +  cpu_scp_lpri: scp-shmem@0 {
> > > > +compatible = "arm,scmi-shmem";
> > > > +reg = <0x0 0x200>;
> > > > +  };
> > > > +
> > > > +  cpu_scp_hpri: scp-shmem@200 {
> > > > +compatible = "arm,scmi-shmem";
> > > > +reg = <0x200 0x200>;
> > > > +  };
> > > > +};
> > > > +
> > > > +firmware {
> > > > +  smc_mbox: mailbox {
> > > > +#mbox-cells = <1>;
> > > > +compatible = "arm,smc-mbox";
> > > > +method = "smc";
> > > > +arm,num-chans = <0x2>;
> > > > +transports = "mem";
> > > > +/* Optional */
> > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > >
> > > SMC/HVC is synchronously(block) running in "secure mode", i.e, there
> > > can only be one instance running platform wide. Right?
> >
> > I think there could be channel for TEE, and channel for Linux.
> > For virtualization case, there could be dedicated channel for each VM.
> >
> I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be
> active at the same time, right?

If I get your point correctly,
On UP, both could not be active. On SMP, tx/rx could be both active, anyway
this depends on secure firmware and Linux firmware design.

Do you have any suggestions about arm,func-ids here?

Thanks,
Peng.

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Fri, Aug 30, 2019 at 2:37 AM Peng Fan  wrote:
> >
> > Hi Jassi,
> >
> > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > for the ARM SMC/HVC mailbox
> > >
> > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan  wrote:
> > >
> > > > > > +examples:
> > > > > > +  - |
> > > > > > +sram@91 {
> > > > > > +  compatible = "mmio-sram";
> > > > > > +  reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > +  #address-cells = <1>;
> > > > > > +  #size-cells = <1>;
> > > > > > +  ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > +
> > > > > > +  cpu_scp_lpri: scp-shmem@0 {
> > > > > > +compatible = "arm,scmi-shmem";
> > > > > > +reg = <0x0 0x200>;
> > > > > > +  };
> > > > > > +
> > > > > > +  cpu_scp_hpri: scp-shmem@200 {
> > > > > > +compatible = "arm,scmi-shmem";
> > > > > > +reg = <0x200 0x200>;
> > > > > > +  };
> > > > > > +};
> > > > > > +
> > > > > > +firmware {
> > > > > > +  smc_mbox: mailbox {
> > > > > > +#mbox-cells = <1>;
> > > > > > +compatible = "arm,smc-mbox";
> > > > > > +method = "smc";
> > > > > > +arm,num-chans = <0x2>;
> > > > > > +transports = "mem";
> > > > > > +/* Optional */
> > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > >
> > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e,
> > > > > there can only be one instance running platform wide. Right?
> > > >
> > > > I think there could be channel for TEE, and channel for Linux.
> > > > For virtualization case, there could be dedicated channel for each VM.
> > > >
> > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > both be active at the same time, right?
> >
> > If I get your point correctly,
> > On UP, both could not be active. On SMP, tx/rx could be both active,
> > anyway this depends on secure firmware and Linux firmware design.
> >
> > Do you have any suggestions about arm,func-ids here?
> >
> I was thinking if this is just an instruction, why can't each channel be
> represented as a controller, i.e, have exactly one func-id per controller 
> node.
> Define as many controllers as you need channels ?

I am ok, this could make driver code simpler. Something as below?

smc_tx_mbox: tx_mbox {
  #mbox-cells = <0>;
  compatible = "arm,smc-mbox";
  method = "smc";
  transports = "mem";
  arm,func-id = <0xc2fe>;
};

smc_rx_mbox: rx_mbox {
  #mbox-cells = <0>;
  compatible = "arm,smc-mbox";
  method = "smc";
  transports = "mem";
  arm,func-id = <0xc2ff>;
};

firmware {
  scmi {
compatible = "arm,scmi";
mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
  };
};

Thanks,
Peng.

> 
> -j

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Fri, Aug 30, 2019 at 3:07 AM Peng Fan  wrote:
> >
> > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > for the ARM SMC/HVC mailbox
> > >
> > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan  wrote:
> > > >
> > > > Hi Jassi,
> > > >
> > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding
> > > > > doc for the ARM SMC/HVC mailbox
> > > > >
> > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan  wrote:
> > > > >
> > > > > > > > +examples:
> > > > > > > > +  - |
> > > > > > > > +sram@91 {
> > > > > > > > +  compatible = "mmio-sram";
> > > > > > > > +  reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > +  #address-cells = <1>;
> > > > > > > > +  #size-cells = <1>;
> > > > > > > > +  ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > +
> > > > > > > > +  cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > +reg = <0x0 0x200>;
> > > > > > > > +  };
> > > > > > > > +
> > > > > > > > +  cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > +compatible = "arm,scmi-shmem";
> > > > > > > > +reg = <0x200 0x200>;
> > > > > > > > +  };
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +firmware {
> > > > > > > > +  smc_mbox: mailbox {
> > > > > > > > +#mbox-cells = <1>;
> > > > > > > > +compatible = "arm,smc-mbox";
> > > > > > > > +method = "smc";
> > > > > > > > +arm,num-chans = <0x2>;
> > > > > > > > +transports = "mem";
> > > > > > > > +/* Optional */
> > > > > > > > +arm,func-ids = <0xc2fe>, <0xc2ff>;
> > > > > > > >
> > > > > > > SMC/HVC is synchronously(block) running in "secure mode",
> > > > > > > i.e, there can only be one instance running platform wide. Right?
> > > > > >
> > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > For virtualization case, there could be dedicated channel for each
> VM.
> > > > > >
> > > > > I am talking from Linux pov. Functions 0xfe and 0xff above,
> > > > > can't both be active at the same time, right?
> > > >
> > > > If I get your point correctly,
> > > > On UP, both could not be active. On SMP, tx/rx could be both
> > > > active, anyway this depends on secure firmware and Linux firmware
> design.
> > > >
> > > > Do you have any suggestions about arm,func-ids here?
> > > >
> > > I was thinking if this is just an instruction, why can't each
> > > channel be represented as a controller, i.e, have exactly one func-id per
> controller node.
> > > Define as many controllers as you need channels ?
> >
> > I am ok, this could make driver code simpler. Something as below?
> >
> > smc_tx_mbox: tx_mbox {
> >   #mbox-cells = <0>;
> >   compatible = "arm,smc-mbox";
> >   method = "smc";
> >   transports = "mem";
> >   arm,func-id = <0xc2fe>;
> > };
> >
> > smc_rx_mbox: rx_mbox {
> >   #mbox-cells = <0>;
> >   compatible = "arm,smc-mbox";
> >   method = "smc";
> >   transports = "mem";
> >   arm,func-id = <0xc2ff>;
> > }
> >
> > firmware {
> >   scmi {
> > compatible = "arm,scmi";
> > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
> > mbox-names = "tx", "rx";
> > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> >   };
> > };
> >
> Yes, the channel part is good.
> But I am not convinced by the need to have SCMI specific "transport" mode.

SCMI spec only support shared memory message. However to make this driver
generic, need to take care of message using ARM registers.

If using shared memory message, the call will be
invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0, 0, 0);
If using ARM registers to transfer message, the call will be
invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3, 
cmd->a4, cmd->a5, cmd->a6, cmd->a7);

So I added "transports" mode.

Code as below:
if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
if (chan_data->function_id != UINT_MAX)
function_id = chan_data->function_id;
else
function_id = cmd->a0;
chan_id = chan_data->chan_id;
ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
 0, 0);
} else {
ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
 cmd->a4, cmd->a5, cmd->a6, cmd->a7);
}


Per Sudeep's comments in previous version, better pass chan_id
to secure firmware.
If drop the "transports" mode, I do not have a good idea how to differentiate
the two cases, reg and mem. Any suggestions?

Thanks,
Peng.


> 
> thanks

RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Sudeep

> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Fri, Aug 30, 2019 at 07:37:41AM +0000, Peng Fan wrote:
> > Hi Jassi,
> > > > I think there could be channel for TEE, and channel for Linux.
> > > > For virtualization case, there could be dedicated channel for each VM.
> > > >
> > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > both be active at the same time, right?
> >
> > If I get your point correctly,
> > On UP, both could not be active. On SMP, tx/rx could be both active,
> > anyway this depends on secure firmware and Linux firmware design.
> >
> 
> Just to confirm, we can't have SMC/HVC based Rx channel as there's no
> *architectural* way to achieve it. So it can be based on some interrupt from
> secure side and hence will be a *different* type of channel/controller.
> 
> Sorry to make this point repeatedly, but juts to be absolutely clear:
> as it stands, SMC/HVC can be used only for Tx today.

Since interrupt notification was dropped in v5, I need to drop RX description
in v6.

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep

[PATCH] clk: imx8mn: fix int pll clk gate

[peng . fan]

From: Peng Fan 

To Frac pll, the gate shift is 13, however to Int PLL the gate shift
is 11.

Cc: 
Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Peng Fan 
Reviewed-by: Jacky Bai 
---
 drivers/clk/imx/clk-imx8mn.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index ecd1062f6847..c5838710e1d8 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -436,12 +436,12 @@ static int imx8mn_clocks_probe(struct platform_device 
*pdev)
clks[IMX8MN_AUDIO_PLL2_OUT] = imx_clk_gate("audio_pll2_out", 
"audio_pll2_bypass", base + 0x14, 13);
clks[IMX8MN_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out", 
"video_pll1_bypass", base + 0x28, 13);
clks[IMX8MN_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out", 
"dram_pll_bypass", base + 0x50, 13);
-   clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", 
"gpu_pll_bypass", base + 0x64, 13);
-   clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", 
"vpu_pll_bypass", base + 0x74, 13);
-   clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", 
"arm_pll_bypass", base + 0x84, 13);
-   clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", 
"sys_pll1_bypass", base + 0x94, 13);
-   clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", 
"sys_pll2_bypass", base + 0x104, 13);
-   clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", 
"sys_pll3_bypass", base + 0x114, 13);
+   clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", 
"gpu_pll_bypass", base + 0x64, 11);
+   clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", 
"vpu_pll_bypass", base + 0x74, 11);
+   clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", 
"arm_pll_bypass", base + 0x84, 11);
+   clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", 
"sys_pll1_bypass", base + 0x94, 11);
+   clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", 
"sys_pll2_bypass", base + 0x104, 11);
+   clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", 
"sys_pll3_bypass", base + 0x114, 11);
 
/* SYS PLL fixed output */
clks[IMX8MN_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", 
"sys_pll1_out", 1, 20);
-- 
2.16.4

[PATCH V2 2/4] clk: imx: clk-pll14xx: unbypass PLL by default

[Peng Fan]

From: Peng Fan 

When registering the PLL, unbypass the PLL.
The PLL has two bypass control bit, BYPASS and EXT_BYPASS.
we will expose EXT_BYPASS to clk driver for mux usage, and keep
BYPASS inside pll14xx usage. The PLL has a restriction that
when M/P change, need to RESET/BYPASS pll to avoid glitch, so
we could not expose BYPASS.

To make it easy for clk driver usage, unbypass PLL which does
not hurt current function.

Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V2:
 New patch

 drivers/clk/imx/clk-pll14xx.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 656f48b002dd..7a815ec76aa5 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -368,6 +368,7 @@ struct clk *imx_clk_pll14xx(const char *name, const char 
*parent_name,
struct clk_pll14xx *pll;
struct clk *clk;
struct clk_init_data init;
+   u32 val;
 
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
@@ -399,6 +400,10 @@ struct clk *imx_clk_pll14xx(const char *name, const char 
*parent_name,
pll->rate_table = pll_clk->rate_table;
pll->rate_count = pll_clk->rate_count;
 
+   val = readl_relaxed(pll->base + GNRL_CTL);
+   val &= ~BYPASS_MASK;
+   writel_relaxed(val, pll->base + GNRL_CTL);
+
clk = clk_register(NULL, &pll->hw);
if (IS_ERR(clk)) {
pr_err("%s: failed to register pll %s %lu\n",
-- 
2.16.4

[PATCH V2 1/4] clk: imx: pll14xx: avoid glitch when set rate

[Peng Fan]

From: Peng Fan 

According to PLL1443XA and PLL1416X spec,
"When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
output unstable clock until lock time passes. PLL1416X/PLL1443XA may
generate a glitch at FOUT."

So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
In the end of set rate, BYPASS will be cleared.

When prepare clock, also need to take care to avoid glitch. So
we also follow Spec to set BYPASS before RESETB changed from 0 to 1.
And add a check if the RESETB is already 0, directly return 0;

Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V2:
  Avoid glitch when prepare
  update commit log

 drivers/clk/imx/clk-pll14xx.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b7213023b238..656f48b002dd 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw, 
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
 
+   /* Enable BYPASS */
+   tmp |= BYPASS_MASK;
+   writel(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -250,6 +254,10 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw, 
unsigned long drate,
tmp &= ~RST_MASK;
writel_relaxed(tmp, pll->base);
 
+   /* Enable BYPASS */
+   tmp |= BYPASS_MASK;
+   writel_relaxed(tmp, pll->base);
+
div_val = (rate->mdiv << MDIV_SHIFT) | (rate->pdiv << PDIV_SHIFT) |
(rate->sdiv << SDIV_SHIFT);
writel_relaxed(div_val, pll->base + 0x4);
@@ -283,16 +291,28 @@ static int clk_pll14xx_prepare(struct clk_hw *hw)
 {
struct clk_pll14xx *pll = to_clk_pll14xx(hw);
u32 val;
+   int ret;
 
/*
 * RESETB = 1 from 0, PLL starts its normal
 * operation after lock time
 */
val = readl_relaxed(pll->base + GNRL_CTL);
+   if (val & RST_MASK)
+   return 0;
+   val |= BYPASS_MASK;
+   writel_relaxed(val, pll->base + GNRL_CTL);
val |= RST_MASK;
writel_relaxed(val, pll->base + GNRL_CTL);
 
-   return clk_pll14xx_wait_lock(pll);
+   ret = clk_pll14xx_wait_lock(pll);
+   if (ret)
+   return ret;
+
+   val &= ~BYPASS_MASK;
+   writel_relaxed(val, pll->base + GNRL_CTL);
+
+   return 0;
 }
 
 static int clk_pll14xx_is_prepared(struct clk_hw *hw)
-- 
2.16.4

[PATCH V2 3/4] clk: imx: imx8mm: fix pll mux bit

[Peng Fan]

From: Peng Fan 

pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.

So use EXT_BYPASS bit here.

And drop uneeded set parent, because EXT_BYPASS default is 0.

Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Suggested-by: Jacky Bai 
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V2:
 New patch

 drivers/clk/imx/clk-imx8mm.c | 32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 2758e3f0d15d..067ab876911d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -408,28 +408,16 @@ static int imx8mm_clocks_probe(struct platform_device 
*pdev)
clks[IMX8MM_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", 
base + 0x114, &imx8mm_sys_pll);
 
/* PLL bypass out */
-   clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass", 
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass", 
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MM_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass", 
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), 
CLK_SET_RATE_PARENT);
-
-   /* unbypass all the plls */
-   clk_set_parent(clks[IMX8MM_AUDIO_PLL1_BYPASS], clks[IMX8MM_AUDIO_PLL1]);
-   clk_set_parent(clks[IMX8MM_AUDIO_PLL2_BYPASS], clks[IMX8MM_AUDIO_PLL2]);
-   clk_set_parent(clks[IMX8MM_VIDEO_PLL1_BYPASS], clks[IMX8MM_VIDEO_PLL1]);
-   clk_set_parent(clks[IMX8MM_DRAM_PLL_BYPASS], clks[IMX8MM_DRAM_PLL]);
-   clk_set_parent(clks[IMX8MM_GPU_PLL_BYPASS], clks[IMX8MM_GPU_PLL]);
-   clk_set_parent(clks[IMX8MM_VPU_PLL_BYPASS], clks[IMX8MM_VPU_PLL]);
-   clk_set_parent(clks[IMX8MM_ARM_PLL_BYPASS], clks[IMX8MM_ARM_PLL]);
-   clk_set_parent(clks[IMX8MM_SYS_PLL1_BYPASS], clks[IMX8MM_SYS_PLL1]);
-   clk_set_parent(clks[IMX8MM_SYS_PLL2_BYPASS], clks[IMX8MM_SYS_PLL2]);
-   clk_set_parent(clks[IMX8MM_SYS_PLL3_BYPASS], clks[IMX8MM_SYS_PLL3]);
+   clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MM_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass

[PATCH V2 4/4] clk: imx: imx8mn: fix pll mux bit

[Peng Fan]

From: Peng Fan 

pll BYPASS bit should be kept inside pll driver for glitchless freq
setting following spec. If exposing the bit, that means pll driver and
clk driver has two paths to touch this bit, which is wrong.

So use EXT_BYPASS bit here.

And drop uneeded set parent, because EXT_BYPASS default is 0.

Suggested-by: Jacky Bai 
Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---

V2:
 New patch

 drivers/clk/imx/clk-imx8mn.c | 32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index f41116d59749..f767d18679ea 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -421,28 +421,16 @@ static int imx8mn_clocks_probe(struct platform_device 
*pdev)
clks[IMX8MN_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", 
base + 0x114, &imx8mn_sys_pll);
 
/* PLL bypass out */
-   clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 4, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 4, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 4, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 4, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 4, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 4, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_SYS_PLL1_BYPASS] = imx_clk_mux_flags("sys_pll1_bypass", 
base + 0x94, 4, 1, sys_pll1_bypass_sels, ARRAY_SIZE(sys_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_SYS_PLL2_BYPASS] = imx_clk_mux_flags("sys_pll2_bypass", 
base + 0x104, 4, 1, sys_pll2_bypass_sels, ARRAY_SIZE(sys_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
-   clks[IMX8MN_SYS_PLL3_BYPASS] = imx_clk_mux_flags("sys_pll3_bypass", 
base + 0x114, 4, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), 
CLK_SET_RATE_PARENT);
-
-   /* unbypass all the plls */
-   clk_set_parent(clks[IMX8MN_AUDIO_PLL1_BYPASS], clks[IMX8MN_AUDIO_PLL1]);
-   clk_set_parent(clks[IMX8MN_AUDIO_PLL2_BYPASS], clks[IMX8MN_AUDIO_PLL2]);
-   clk_set_parent(clks[IMX8MN_VIDEO_PLL1_BYPASS], clks[IMX8MN_VIDEO_PLL1]);
-   clk_set_parent(clks[IMX8MN_DRAM_PLL_BYPASS], clks[IMX8MN_DRAM_PLL]);
-   clk_set_parent(clks[IMX8MN_GPU_PLL_BYPASS], clks[IMX8MN_GPU_PLL]);
-   clk_set_parent(clks[IMX8MN_VPU_PLL_BYPASS], clks[IMX8MN_VPU_PLL]);
-   clk_set_parent(clks[IMX8MN_ARM_PLL_BYPASS], clks[IMX8MN_ARM_PLL]);
-   clk_set_parent(clks[IMX8MN_SYS_PLL1_BYPASS], clks[IMX8MN_SYS_PLL1]);
-   clk_set_parent(clks[IMX8MN_SYS_PLL2_BYPASS], clks[IMX8MN_SYS_PLL2]);
-   clk_set_parent(clks[IMX8MN_SYS_PLL3_BYPASS], clks[IMX8MN_SYS_PLL3]);
+   clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", 
base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_mux_flags("audio_pll2_bypass", 
base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_VIDEO_PLL1_BYPASS] = imx_clk_mux_flags("video_pll1_bypass", 
base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_mux_flags("dram_pll_bypass", 
base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_GPU_PLL_BYPASS] = imx_clk_mux_flags("gpu_pll_bypass", base 
+ 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_VPU_PLL_BYPASS] = imx_clk_mux_flags("vpu_pll_bypass", base 
+ 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_ARM_PLL_BYPASS] = imx_clk_mux_flags("arm_pll_bypass", base 
+ 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), 
CLK_SET_RATE_PARENT);
+   clks[IMX8MN_SYS_PLL1_BYPASS] = imx_clk_mux_flag

[PATCH] clk: imx: lpcg: write twice when writing lpcg regs

[Peng Fan]

From: Peng Fan 

There is hardware issue that:
The output clock the LPCG cell will not turn back on as expected,
even though a read of the IPG registers in the LPCG indicates that
the clock should be enabled.

The software workaround is to write twice to enable the LPCG clock
output.

Signed-off-by: Peng Fan 
---
 drivers/clk/imx/clk-lpcg-scu.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/imx/clk-lpcg-scu.c b/drivers/clk/imx/clk-lpcg-scu.c
index a73a799fb777..7391d0668ec4 100644
--- a/drivers/clk/imx/clk-lpcg-scu.c
+++ b/drivers/clk/imx/clk-lpcg-scu.c
@@ -54,6 +54,11 @@ static int clk_lpcg_scu_enable(struct clk_hw *hw)
 
reg |= val << clk->bit_idx;
writel(reg, clk->reg);
+   /*
+* There is hardware bug. When enabling the LPCG clock
+* output, SW can write the enabling value twice
+*/
+   writel(reg, clk->reg);
 
spin_unlock_irqrestore(&imx_lpcg_scu_lock, flags);
 
@@ -71,6 +76,11 @@ static void clk_lpcg_scu_disable(struct clk_hw *hw)
reg = readl_relaxed(clk->reg);
reg &= ~(CLK_GATE_SCU_LPCG_MASK << clk->bit_idx);
writel(reg, clk->reg);
+   /*
+* There is hardware bug. When enabling the LPCG clock
+* output, SW can write the enabling value twice
+*/
+   writel(reg, clk->reg);
 
spin_unlock_irqrestore(&imx_lpcg_scu_lock, flags);
 }
-- 
2.16.4

RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64

[Peng Fan]

Ping again..

+Julien

> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> 
> Hi Russell, Stefano
> 
> > Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> 
> Any comments?
> 
> >
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, need use __GFP_DMA32.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm/xen/mm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > e1d44b903dfc..a95e76d18bf9 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> int
> > order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0x) {
> > -   flags |= __GFP_DMA;
> > +   flags |= __GFP_DMA | __GFP_DMA32;
> > break;
> > }
> > }
> 
> Thanks,
> Peng.

Thanks,
Peng.

> 
> > --
> > 2.16.4

[PATCH v4 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

From: Peng Fan 

V4:
yaml fix for num-chans in patch 1/2.

V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
 
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.

[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi

Peng Fan (2):
  dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.yaml   | 126 
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 215 +
 4 files changed, 350 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.16.4

[PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

From: Peng Fan 

The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Peng Fan 
---
 .../devicetree/bindings/mailbox/arm-smc.yaml   | 126 +
 1 file changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml 
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..ae677e0c0910
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+  - Peng Fan 
+
+description: |
+  This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+  call) instruction to trigger a mailbox-connected activity in firmware,
+  executing on the very same core as the caller. By nature this operation
+  is synchronous and this mailbox provides no way for asynchronous messages
+  to be delivered the other way round, from firmware to the OS, but
+  asynchronous notification could also be supported. However the value of
+  r0/w0/x0 the firmware returns after the smc call is delivered as a received
+  message to the mailbox framework, so a synchronous communication can be
+  established, for a asynchronous notification, no value will be returned.
+  The exact meaning of both the action the mailbox triggers as well as the
+  return value is defined by their users and is not subject to this binding.
+
+  One use case of this mailbox is the SCMI interface, which uses shared memory
+  to transfer commands and parameters, and a mailbox to trigger a function
+  call. This allows SoCs without a separate management processor (or when
+  such a processor is not available or used) to use this standardized
+  interface anyway.
+
+  This binding describes no hardware, but establishes a firmware interface.
+  Upon receiving an SMC using one of the described SMC function identifiers,
+  the firmware is expected to trigger some mailbox connected functionality.
+  The communication follows the ARM SMC calling convention.
+  Firmware expects an SMC function identifier in r0 or w0. The supported
+  identifiers are passed from consumers, or listed in the the arm,func-ids
+  properties as described below. The firmware can return one value in
+  the first SMC result register, it is expected to be an error value,
+  which shall be propagated to the mailbox client.
+
+  Any core which supports the SMC or HVC instruction can be used, as long as
+  a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+  compatible:
+const: arm,smc-mbox
+
+  "#mbox-cells":
+const: 1
+
+  arm,num-chans:
+description: The number of channels supported.
+items:
+ minimum: 1
+ maximum: 4096 # Should be enough?
+
+  method:
+items:
+  - enum:
+  - smc
+  - hvc
+
+  transports:
+items:
+  - enum:
+  - mem
+  - reg
+
+  arm,func-ids:
+description: |
+  An array of 32-bit values specifying the function IDs used by each
+  mailbox channel. Those function IDs follow the ARM SMC calling
+  convention standard [1].
+
+  There is one identifier per channel and the number of supported
+  channels is determined by the length of this array.
+minItems: 0
+maxItems: 4096   # Should be enough?
+
+required:
+  - compatible
+  - "#mbox-cells"
+  - arm,num-chans
+  - transports
+  - method
+
+examples:
+  - |
+sram@91 {
+  compatible = "mmio-sram";
+  reg = <0x0 0x93f000 0x0 0x1000>;
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges = <0 0x0 0x93f000 0x1000>;
+
+cpu_scp_lpri: scp-shmem@0 {
+  compatible = "arm,scmi-shmem";
+  reg = <0x0 0x200>;
+};
+
+cpu_scp_hpri: scp-shmem@200 {
+  compatible = "arm,scmi-shmem";
+  reg = <0x200 0x200>;
+};
+};
+
+firmware {
+  smc_mbox: mailbox {
+#mbox-cells = <1>;
+compatible = "arm,smc-mbox";
+method = "smc";
+arm,num-chans = <0x2>;
+transports = "mem";
+/* Optional */
+arm,func-ids = <0xc2fe>, <0xc2ff>;
+  };
+
+  scmi {
+compatible = "arm,scmi";
+mboxes = <&mailbox 0 &mailbox 1>;
+mbox-names = "tx", "rx";
+shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+  };
+};
+
+...
-- 
2.16.4

[PATCH v4 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

From: Peng Fan 

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Cc: Andre Przywara 
Signed-off-by: Peng Fan 
---
 drivers/mailbox/Kconfig   |   7 ++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 215 ++
 3 files changed, 224 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+   u32 function_id;
+   u32 chan_id;
+   u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+   unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   unsigned long ret;
+   u32 function_id;
+   u32 chan_id;
+
+   if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+   if (chan_data->function_id != UINT_MAX)
+   function_id = chan_data->function_id;
+   else
+   function_id = cmd->a0;
+   chan_id = chan_data->chan_id;
+   ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+0, 0);
+   } else {
+   ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+   }
+
+   mbox_chan_received_data(link, (void *)ret);
+
+   return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &res);
+   return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &am

RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64

[Peng Fan]

Hi Robin,

> Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> 
> On 09/07/2019 09:22, Peng Fan wrote:
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, need use __GFP_DMA32.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >   arch/arm/xen/mm.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > e1d44b903dfc..a95e76d18bf9 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0x) {
> > -   flags |= __GFP_DMA;
> > +   flags |= __GFP_DMA | __GFP_DMA32;
> 
> Given the definition of GFP_ZONE_BAD, I'm not sure this combination of flags
> is strictly valid, but rather is implicitly reliant on only one of those 
> zones ever
> actually existing. As such, it seems liable to blow up if the plans to add
> ZONE_DMA to arm64[1] go ahead.

How about this, or do you have any suggestions?
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..f61c29a4430f 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)

for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0x) {
+#ifdef CONFIG_ARM64
+   flags |= __GFP_DMA32;
+#else
flags |= __GFP_DMA;
+#endif
break;
}
}

Thanks,
Peng.

> 
> Robin.
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-arm-kernel%2F20190820145821.27214-1-nsaenzjulienne%
> 40suse.de%2F&data=02%7C01%7Cpeng.fan%40nxp.com%7C5d2a641b1
> e3f449562f908d72ae95d85%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637025054169859035&sdata=1ZPGH0gZnvgmlMpX7VrjUNME
> XbEjiv4%2FZ9pYwTQTWxY%3D&reserved=0
> 
> > break;
> > }
> > }
> >

RE: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

Hi Rob,

> Subject: Re: [PATCH v4 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
> 
> On Tue, Aug 27, 2019 at 4:51 AM Peng Fan  wrote:
> >
> > From: Peng Fan 
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception 
> > levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  .../devicetree/bindings/mailbox/arm-smc.yaml   | 126
> +
> >  1 file changed, 126 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index ..ae677e0c0910
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,126 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C0e905f3fe89b4dc9ee0608d72af06e30%7C686ea1d
> 3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C0%7C637025084458964761&sdata=p8
> EeFkU5pW3
> > +D8bzpZu9IHCoFD%2F2ZBcSr6WyCsIK9LqU%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C0e905f3fe89b4dc9ee0608d72af06e30%7C686ea1d3bc2b4c6
> fa92cd9
> >
> +9c5c301635%7C0%7C0%7C637025084458964761&sdata=JFhz7meFyG
> ozMLnt4Jb
> > +RGneYty6cBSCKyxHpl26TAsI%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > +  - Peng Fan 
> > +
> > +description: |
> > +  This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > +  call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > +  executing on the very same core as the caller. By nature this
> > +operation
> > +  is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > +  to be delivered the other way round, from firmware to the OS, but
> > +  asynchronous notification could also be supported. However the
> > +value of
> > +  r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received
> > +  message to the mailbox framework, so a synchronous communication
> > +can be
> > +  established, for a asynchronous notification, no value will be returned.
> > +  The exact meaning of both the action the mailbox triggers as well
> > +as the
> > +  return value is defined by their users and is not subject to this 
> > binding.
> > +
> > +  One use case of this mailbox is the SCMI interface, which uses
> > + shared memory  to transfer commands and parameters, and a mailbox
> to
> > + trigger a function  call. This allows SoCs without a separate
> > + management processor (or when  such a processor is not available or
> > + used) to use this standardized  interface anyway.
> > +
> > +  This binding describes no hardware, but establishes a firmware
> interface.
> > +  Upon receiving an SMC using one of the described SMC function
> > + identifiers,  the firmware is expected to trigger some mailbox connected
> functionality.
> > +  The communication follows the ARM SMC calling convention.
> > +  Firmware expects an SMC function identifier in r0 or w0. The
> > + supported  identifiers are passed from consumers, or listed in the
> > + the arm,func-ids  properties as described below. The firmware can
> > + return one value in  the first SMC result register, it is expected
> > + to be an error value,  which shall be propagated to the mailbox client.
> > +
> > +  Any core which supports the SMC or HVC instruction can be used, as
> > + long as  a firmware component running in EL3 or EL2 is handling these
> calls.
> > +
> > +properties:
> > +  compatible:
> > +const: arm,smc-mbox
> > +
> > +  "#mbox-cells":
> > +const: 1
> > +
> > +  arm,num-chans:
> > +description: The number of channels supported.
> > +items:
> > + minimum: 1

[PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

From: Peng Fan 

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Cc: Andre Przywara 
Signed-off-by: Peng Fan 
---
 drivers/mailbox/Kconfig   |   7 ++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/arm-smc-mailbox.c | 215 ++
 3 files changed, 224 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..76a2ae11ee4d
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
+
+struct arm_smc_chan_data {
+   u32 function_id;
+   u32 chan_id;
+   u32 flags;
+};
+
+struct arm_smccc_mbox_cmd {
+   unsigned long a0, a1, a2, a3, a4, a5, a6, a7;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long,
+   unsigned long, unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   unsigned long ret;
+   u32 function_id;
+   u32 chan_id;
+
+   if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
+   if (chan_data->function_id != UINT_MAX)
+   function_id = chan_data->function_id;
+   else
+   function_id = cmd->a0;
+   chan_id = chan_data->chan_id;
+   ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
+0, 0);
+   } else {
+   ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
+cmd->a4, cmd->a5, cmd->a6, cmd->a7);
+   }
+
+   mbox_chan_received_data(link, (void *)ret);
+
+   return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &res);
+   return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned long function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5,
+unsigned long arg6)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, arg6, &am

[PATCH v5 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

From: Peng Fan 

V5:
yaml fix

V4:
yaml fix for num-chans in patch 1/2.
https://patchwork.kernel.org/cover/6521/

V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
 
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.

[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi

Peng Fan (2):
  dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.yaml   | 125 
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 215 +
 4 files changed, 349 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c

-- 
2.16.4

[PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox

[Peng Fan]

From: Peng Fan 

The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Peng Fan 
---
 .../devicetree/bindings/mailbox/arm-smc.yaml   | 125 +
 1 file changed, 125 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml 
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..f8eb28d5e307
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+  - Peng Fan 
+
+description: |
+  This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+  call) instruction to trigger a mailbox-connected activity in firmware,
+  executing on the very same core as the caller. By nature this operation
+  is synchronous and this mailbox provides no way for asynchronous messages
+  to be delivered the other way round, from firmware to the OS, but
+  asynchronous notification could also be supported. However the value of
+  r0/w0/x0 the firmware returns after the smc call is delivered as a received
+  message to the mailbox framework, so a synchronous communication can be
+  established, for a asynchronous notification, no value will be returned.
+  The exact meaning of both the action the mailbox triggers as well as the
+  return value is defined by their users and is not subject to this binding.
+
+  One use case of this mailbox is the SCMI interface, which uses shared memory
+  to transfer commands and parameters, and a mailbox to trigger a function
+  call. This allows SoCs without a separate management processor (or when
+  such a processor is not available or used) to use this standardized
+  interface anyway.
+
+  This binding describes no hardware, but establishes a firmware interface.
+  Upon receiving an SMC using one of the described SMC function identifiers,
+  the firmware is expected to trigger some mailbox connected functionality.
+  The communication follows the ARM SMC calling convention.
+  Firmware expects an SMC function identifier in r0 or w0. The supported
+  identifiers are passed from consumers, or listed in the the arm,func-ids
+  properties as described below. The firmware can return one value in
+  the first SMC result register, it is expected to be an error value,
+  which shall be propagated to the mailbox client.
+
+  Any core which supports the SMC or HVC instruction can be used, as long as
+  a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+  compatible:
+const: arm,smc-mbox
+
+  "#mbox-cells":
+const: 1
+
+  arm,num-chans:
+description: The number of channels supported.
+items:
+  minimum: 1
+  maximum: 4096 # Should be enough?
+
+  method:
+- enum:
+- smc
+- hvc
+
+  transports:
+- enum:
+- mem
+- reg
+
+  arm,func-ids:
+description: |
+  An array of 32-bit values specifying the function IDs used by each
+  mailbox channel. Those function IDs follow the ARM SMC calling
+  convention standard [1].
+
+  There is one identifier per channel and the number of supported
+  channels is determined by the length of this array.
+$ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 0
+maxItems: 4096   # Should be enough?
+
+required:
+  - compatible
+  - "#mbox-cells"
+  - arm,num-chans
+  - transports
+  - method
+
+examples:
+  - |
+sram@91 {
+  compatible = "mmio-sram";
+  reg = <0x0 0x93f000 0x0 0x1000>;
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges = <0 0x0 0x93f000 0x1000>;
+
+  cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+  };
+
+  cpu_scp_hpri: scp-shmem@200 {
+compatible = "arm,scmi-shmem";
+reg = <0x200 0x200>;
+  };
+};
+
+firmware {
+  smc_mbox: mailbox {
+#mbox-cells = <1>;
+compatible = "arm,smc-mbox";
+method = "smc";
+arm,num-chans = <0x2>;
+transports = "mem";
+/* Optional */
+arm,func-ids = <0xc2fe>, <0xc2ff>;
+  };
+
+  scmi {
+compatible = "arm,scmi";
+mboxes = <&smc_mbox 0>, <&smc_mbox 1>;
+mbox-names = "tx", "rx";
+shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
+  };
+};
+
+...
-- 
2.16.4

[PATCH] clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out

[Peng Fan]

There is no audio_pll2_clk registered, it should be audio_pll2_out.

Cc: 
Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan 
---
 drivers/clk/imx/clk-imx8mm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1ef8438e3d6d..3a889846a05c 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -325,7 +325,7 @@ static const char *imx8mm_dsi_dbi_sels[] = {"osc_24m", 
"sys_pll1_266m", "sys_pll
"sys_pll2_1000m", "sys_pll3_out", 
"audio_pll2_out", "video_pll1_out", };
 
 static const char *imx8mm_usdhc3_sels[] = {"osc_24m", "sys_pll1_400m", 
"sys_pll1_800m", "sys_pll2_500m",
-  "sys_pll3_out", "sys_pll1_266m", 
"audio_pll2_clk", "sys_pll1_100m", };
+  "sys_pll3_out", "sys_pll1_266m", 
"audio_pll2_out", "sys_pll1_100m", };
 
 static const char *imx8mm_csi1_core_sels[] = {"osc_24m", "sys_pll1_266m", 
"sys_pll2_250m", "sys_pll1_800m",
  "sys_pll2_1000m", "sys_pll3_out", 
"audio_pll2_out", "video_pll1_out", };
@@ -361,11 +361,11 @@ static const char *imx8mm_pdm_sels[] = {"osc_24m", 
"sys_pll2_100m", "audio_pll1_
"sys_pll2_1000m", "sys_pll3_out", 
"clk_ext3", "audio_pll2_out", };
 
 static const char *imx8mm_vpu_h1_sels[] = {"osc_24m", "vpu_pll_out", 
"sys_pll1_800m", "sys_pll2_1000m",
-  "audio_pll2_clk", "sys_pll2_125m", 
"sys_pll3_clk", "audio_pll1_out", };
+  "audio_pll2_out", "sys_pll2_125m", 
"sys_pll3_clk", "audio_pll1_out", };
 
 static const char *imx8mm_dram_core_sels[] = {"dram_pll_out", "dram_alt_root", 
};
 
-static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m", 
"osc_27m", "sys_pll1_200m", "audio_pll2_clk",
+static const char *imx8mm_clko1_sels[] = {"osc_24m", "sys_pll1_800m", 
"osc_27m", "sys_pll1_200m", "audio_pll2_out",
 "vpu_pll", "sys_pll1_80m", };
 
 static struct clk *clks[IMX8MM_CLK_END];
-- 
2.16.4

[PATCH V3 RESEND 4/4] arm64: dts: imx: add i.MX8QXP ocotp support

[Peng Fan]

Add i.MX8QXP ocotp node

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: Anson Huang 
Cc: Daniel Baluta 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---

V3:
 Add R-b tag
V2:
 move address/size-cells below compatible, add "scu"

 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2a48ae..725d341ee160 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -141,6 +141,12 @@
compatible = "fsl,imx8qxp-iomuxc";
};
 
+   ocotp: imx8qx-ocotp {
+   compatible = "fsl,imx8qxp-scu-ocotp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd";
#power-domain-cells = <1>;
-- 
2.16.4

[PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU octop driver

[Peng Fan]

Build in CONFIG_NVMEM_IMX_OCOTP_SCU.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Shawn Guo 
Cc: Andy Gross 
Cc: Maxime Ripard 
Cc: Olof Johansson 
Cc: Jagan Teki 
Cc: Bjorn Andersson 
Cc: Leonard Crestez 
Cc: Marc Gonzalez 
Cc: Enric Balletbo i Serra 
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---

V3:
 No change
V2:
 rename patch title, add review tag

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 979a95c915b6..32b85102b857 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y
 CONFIG_QCOM_L2_PMU=y
 CONFIG_QCOM_L3_PMU=y
 CONFIG_NVMEM_IMX_OCOTP=y
+CONFIG_NVMEM_IMX_OCOTP_SCU=y
 CONFIG_QCOM_QFPROM=y
 CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_UNIPHIER_EFUSE=y
-- 
2.16.4

[PATCH V3 RESEND 1/4] dt-bindings: fsl: scu: add ocotp binding

[Peng Fan]

NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller(SCU), the ocotp controller is being controlled
by the SCU, so Linux need use RPC to SCU for ocotp handling. This
patch adds binding doc for i.MX8 SCU OCOTP driver.

Cc: Mark Rutland 
Cc: Shawn Guo 
Cc: Ulf Hansson 
Cc: Stephen Boyd 
Cc: Anson Huang 
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring 
Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---

V3:
 Add R-b tag
V2:
 Move OCOTP to end, add example, add "scu"

 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 5d7dbabbb784..f378922906f6 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -133,6 +133,18 @@ RTC bindings based on SCU Message Protocol
 Required properties:
 - compatible: should be "fsl,imx8qxp-sc-rtc";
 
+OCOTP bindings based on SCU Message Protocol
+
+Required properties:
+- compatible:  Should be "fsl,imx8qxp-scu-ocotp"
+- #address-cells:  Must be 1. Contains byte index
+- #size-cells: Must be 1. Contains byte length
+
+Optional Child nodes:
+
+- Data cells of ocotp:
+  Detailed bindings are described in bindings/nvmem/nvmem.txt
+
 Example (imx8qxp):
 -
 aliases {
@@ -177,6 +189,16 @@ firmware {
...
};
 
+   ocotp: imx8qx-ocotp {
+   compatible = "fsl,imx8qxp-scu-ocotp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   fec_mac0: mac@2c4 {
+   reg = <0x2c4 8>;
+   };
+   };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
-- 
2.16.4

[PATCH V3 RESEND 2/4] nvmem: imx: add i.MX8 nvmem driver

[Peng Fan]

This patch adds i.MX8 nvmem ocotp driver to access fuse via
RPC to i.MX8 system controller.

Cc: Srinivas Kandagatla 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Peng Fan 
---

V3:
 Use imx_sc_msg_misc_fuse_read for req/resp
 Drop uneccessary check
 Drop the unnecessary type conversion
 Minor fixes according to v2 comments

V2:
 Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes

 drivers/nvmem/Kconfig |   7 ++
 drivers/nvmem/Makefile|   2 +
 drivers/nvmem/imx-ocotp-scu.c | 161 ++
 3 files changed, 170 insertions(+)
 create mode 100644 drivers/nvmem/imx-ocotp-scu.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 530d570724c9..79afe44195a1 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
  This driver can also be built as a module. If so, the module
  will be called nvmem-imx-ocotp.
 
+config NVMEM_IMX_OCOTP_SCU
+   tristate "i.MX8 SCU On-Chip OTP Controller support"
+   depends on IMX_SCU
+   help
+ This is a driver for the SCU On-Chip OTP Controller (OCOTP)
+ available on i.MX8 SoCs.
+
 config NVMEM_LPC18XX_EEPROM
tristate "NXP LPC18XX EEPROM Memory Support"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 2ece8dda..30d653d34e57 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM)   += nvmem-imx-iim.o
 nvmem-imx-iim-y:= imx-iim.o
 obj-$(CONFIG_NVMEM_IMX_OCOTP)  += nvmem-imx-ocotp.o
 nvmem-imx-ocotp-y  := imx-ocotp.o
+obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU)  += nvmem-imx-ocotp-scu.o
+nvmem-imx-ocotp-scu-y  := imx-ocotp-scu.o
 obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
 nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
 obj-$(CONFIG_NVMEM_LPC18XX_OTP)+= nvmem_lpc18xx_otp.o
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
new file mode 100644
index ..d9dc482ecb2f
--- /dev/null
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 OCOTP fusebox driver
+ *
+ * Copyright 2019 NXP
+ *
+ * Peng Fan 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum ocotp_devtype {
+   IMX8QXP,
+};
+
+struct ocotp_devtype_data {
+   int devtype;
+   int nregs;
+};
+
+struct ocotp_priv {
+   struct device *dev;
+   const struct ocotp_devtype_data *data;
+   struct imx_sc_ipc *nvmem_ipc;
+};
+
+struct imx_sc_msg_misc_fuse_read {
+   struct imx_sc_rpc_msg hdr;
+   u32 word;
+} __packed;
+
+static struct ocotp_devtype_data imx8qxp_data = {
+   .devtype = IMX8QXP,
+   .nregs = 800,
+};
+
+static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
+u32 *val)
+{
+   struct imx_sc_msg_misc_fuse_read msg;
+   struct imx_sc_rpc_msg *hdr = &msg.hdr;
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_MISC;
+   hdr->func = IMX_SC_MISC_FUNC_OTP_FUSE_READ;
+   hdr->size = 2;
+
+   msg.word = word;
+
+   ret = imx_scu_call_rpc(ipc, &msg, true);
+   if (ret)
+   return ret;
+
+   *val = msg.word;
+
+   return 0;
+}
+
+static int imx_scu_ocotp_read(void *context, unsigned int offset,
+ void *val, size_t bytes)
+{
+   struct ocotp_priv *priv = context;
+   u32 count, index, num_bytes;
+   u32 *buf;
+   void *p;
+   int i, ret;
+
+   index = offset >> 2;
+   num_bytes = round_up((offset % 4) + bytes, 4);
+   count = num_bytes >> 2;
+
+   if (count > (priv->data->nregs - index))
+   count = priv->data->nregs - index;
+
+   p = kzalloc(num_bytes, GFP_KERNEL);
+   if (!p)
+   return -ENOMEM;
+
+   buf = p;
+
+   for (i = index; i < (index + count); i++) {
+   if (priv->data->devtype == IMX8QXP) {
+   if ((i > 271) && (i < 544)) {
+   *buf++ = 0;
+   continue;
+   }
+   }
+
+   ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
+   if (ret) {
+   kfree(p);
+   return ret;
+   }
+   buf++;
+   }
+
+   memcpy(val, (u8 *)p + offset % 4, bytes);
+
+   kfree(p);
+
+   return 0;
+}
+
+static struct nvmem_config imx_scu_ocotp_nvmem_config = {
+   .name = "imx-scu-ocotp",
+   .read_only = true,
+   .word_size

RE: [PATCH V3 2/4] nvmem: imx: add i.MX8 nvmem driver

[Peng Fan]

Hi Srinivas,

> Subject: Re: [PATCH V3 2/4] nvmem: imx: add i.MX8 nvmem driver
> 
> 
> 
> On 15/05/2019 08:53, Peng Fan wrote:
> > This patch adds i.MX8 nvmem ocotp driver to access fuse via RPC to
> > i.MX8 system controller.
> >
> > Cc: Srinivas Kandagatla 
> > Cc: Shawn Guo 
> > Cc: Sascha Hauer 
> > Cc: Pengutronix Kernel Team 
> > Cc: Fabio Estevam 
> > Cc: NXP Linux Team 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Peng Fan 
> 
> I don't see any dt-binding patches in my list. May be you forgot to add me in
> CC.
> 
> Can You please make sure that you add me to the cc of the dt-bindings patch
> so that I can take the driver and dt-bindings together via nvmem tree.
> I will not be able to apply any driver patches without dt-bindings.

Sorry. Forgot to add you in that patch. Resent the whole v3 patchset with
you in To list just now.

Thanks,
Peng.

> 
> Thanks,
> srini
> > ---
> >
> > V3:
> >   Use imx_sc_msg_misc_fuse_read for req/resp
> >   Drop uneccessary check
> >   Drop the unnecessary type conversion
> >   Minor fixes according to v2 comments
> >
> > V2:
> >   Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes
> >
> >   drivers/nvmem/Kconfig |   7 ++
> >   drivers/nvmem/Makefile|   2 +
> >   drivers/nvmem/imx-ocotp-scu.c | 161
> ++
> >   3 files changed, 170 insertions(+)
> >   create mode 100644 drivers/nvmem/imx-ocotp-scu.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig index
> > 530d570724c9..79afe44195a1 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
> >   This driver can also be built as a module. If so, the module
> >   will be called nvmem-imx-ocotp.
> >
> > +config NVMEM_IMX_OCOTP_SCU
> > +   tristate "i.MX8 SCU On-Chip OTP Controller support"
> > +   depends on IMX_SCU
> > +   help
> > + This is a driver for the SCU On-Chip OTP Controller (OCOTP)
> > + available on i.MX8 SoCs.
> > +
> >   config NVMEM_LPC18XX_EEPROM
> > tristate "NXP LPC18XX EEPROM Memory Support"
> > depends on ARCH_LPC18XX || COMPILE_TEST diff --git
> > a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile index
> > 2ece8dda..30d653d34e57 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM)   +=
> nvmem-imx-iim.o
> >   nvmem-imx-iim-y   := imx-iim.o
> >   obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
> >   nvmem-imx-ocotp-y := imx-ocotp.o
> > +obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU)  += nvmem-imx-ocotp-scu.o
> > +nvmem-imx-ocotp-scu-y  := imx-ocotp-scu.o
> >   obj-$(CONFIG_NVMEM_LPC18XX_EEPROM)+=
> nvmem_lpc18xx_eeprom.o
> >   nvmem_lpc18xx_eeprom-y    := lpc18xx_eeprom.o
> >   obj-$(CONFIG_NVMEM_LPC18XX_OTP)   += nvmem_lpc18xx_otp.o
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c new file mode 100644 index
> > ..d9dc482ecb2f
> > --- /dev/null
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -0,0 +1,161 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 OCOTP fusebox driver
> > + *
> > + * Copyright 2019 NXP
> > + *
> > + * Peng Fan 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +enum ocotp_devtype {
> > +   IMX8QXP,
> > +};
> > +
> > +struct ocotp_devtype_data {
> > +   int devtype;
> > +   int nregs;
> > +};
> > +
> > +struct ocotp_priv {
> > +   struct device *dev;
> > +   const struct ocotp_devtype_data *data;
> > +   struct imx_sc_ipc *nvmem_ipc;
> > +};
> > +
> > +struct imx_sc_msg_misc_fuse_read {
> > +   struct imx_sc_rpc_msg hdr;
> > +   u32 word;
> > +} __packed;
> > +
> > +static struct ocotp_devtype_data imx8qxp_data = {
> > +   .devtype = IMX8QXP,
> > +   .nregs = 800,
> > +};
> > +
> > +static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > +u32 *val)
> > +{
> > +   struct imx_sc_msg_misc_fuse_read msg;
> > +   struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > +   int ret;
> > +
> > +   hdr->ver = IMX_SC_RPC_VERSION;
> > +   hdr-

[PATCH] firmware: arm_scmi: clock: set rate_discrete

[Peng Fan]

The rate_discrete needs to be assigned to clk->rate_discrete,
then scmi_clk_round_rate could get the value.

Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock 
protocol")
Signed-off-by: Peng Fan 
---
 drivers/firmware/arm_scmi/clock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/firmware/arm_scmi/clock.c 
b/drivers/firmware/arm_scmi/clock.c
index 30fc04e28431..0a194af92438 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -185,6 +185,8 @@ scmi_clock_describe_rates_get(const struct scmi_handle 
*handle, u32 clk_id,
if (rate_discrete)
clk->list.num_rates = tot_rate_cnt;
 
+   clk->rate_discrete = rate_discrete;
+
 err:
scmi_xfer_put(handle, t);
return ret;
-- 
2.16.4

[PATCH 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/

Cc: Andre Przywara 
Signed-off-by: Peng Fan 
---
 drivers/mailbox/Kconfig |   7 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/arm-smc-mailbox.c   | 154 
 include/linux/mailbox/arm-smc-mailbox.h |  10 +++
 4 files changed, 173 insertions(+)
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smc-mailbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 595542bfae85..c3bd0f1ddcd8 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -15,6 +15,13 @@ config ARM_MHU
  The controller has 3 mailbox channels, the last of which can be
  used in Secure mode only.
 
+config ARM_SMC_MBOX
+   tristate "Generic ARM smc mailbox"
+   depends on OF && HAVE_ARM_SMCCC
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
 config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
 
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
 obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c 
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..f4da1061f7f0
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARM_SMC_MBOX_USE_HVC   BIT(0)
+
+struct arm_smc_chan_data {
+   u32 function_id;
+   u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   struct arm_smccc_mbox_cmd *cmd = data;
+   struct arm_smccc_res res;
+   u32 function_id;
+
+   if (chan_data->function_id != UINT_MAX)
+   function_id = chan_data->function_id;
+   else
+   function_id = cmd->a0;
+
+   if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+   arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, &res);
+   else
+   arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ cmd->a5, cmd->a6, cmd->a7, &res);
+
+   mbox_chan_received_data(link, (void *)res.a0);
+
+   return 0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+   .send_data  = arm_smc_send_data,
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct mbox_controller *mbox;
+   struct arm_smc_chan_data *chan_data;
+   const char *method;
+   bool use_hvc = false;
+   int ret, i;
+   u32 val;
+
+   if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
+   if (val < 1 || val > INT_MAX) {
+   dev_err(dev, "invalid arm,num-chans value %u of 
%pOFn\n", val, pdev->dev.of_node);
+   return -EINVAL;
+   }
+   }
+
+   if (!of_property_read_string(dev->of_node, "method", &method)) {
+   if (!strcmp("hvc", method)) {
+   use_hvc = true;
+   } else if (!strcmp("smc", method)) {
+   use_hvc = false;
+   } else {
+   dev_warn(dev, "invalid \"method\" property: %s\n",
+method);
+
+   return -EINVAL;
+   }
+   }
+
+   mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+   if (!mbox)
+   return -ENOMEM;
+
+   mbox->num_chans =

[PATCH 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox

[Peng Fan]

The ARM SMC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.

Signed-off-by: Peng Fan 
---

V1:
arm,func-ids is still kept as an optional property, because there is no
defined SMC funciton id passed from SCMI. So in my test, I still use
arm,func-ids for ARM SIP service.

 .../devicetree/bindings/mailbox/arm-smc.txt| 96 ++
 1 file changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt 
b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index ..12fc5997933d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,96 @@
+ARM SMC Mailbox Interface
+=
+
+This mailbox uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware, executing on the very same
+core as the caller. By nature this operation is synchronous and this
+mailbox provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0/x0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+The exact meaning of both the action the mailbox triggers as well as the
+return value is defined by their users and is not subject to this binding.
+
+One use case of this mailbox is the SCMI interface, which uses shared memory
+to transfer commands and parameters, and a mailbox to trigger a function
+call. This allows SoCs without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+This binding describes no hardware, but establishes a firmware interface.
+Upon receiving an SMC using one of the described SMC function identifiers,
+the firmware is expected to trigger some mailbox connected functionality.
+The communication follows the ARM SMC calling convention[1].
+Firmware expects an SMC function identifier in r0 or w0. The supported
+identifiers are passed from consumers, or listed in the the arm,func-ids
+properties as described below. The firmware can return one value in
+the first SMC result register, it is expected to be an error value,
+which shall be propagated to the mailbox client.
+
+Any core which supports the SMC or HVC instruction can be used, as long as
+a firmware component running in EL3 or EL2 is handling these calls.
+
+Mailbox Device Node:
+
+
+This node is expected to be a child of the /firmware node.
+
+Required properties:
+
+- compatible:  Shall be "arm,smc-mbox"
+- #mbox-cells  Shall be 1 - the index of the channel needed.
+- arm,num-chansThe number of channels supported.
+- method:  A string, either:
+   "hvc": if the driver shall use an HVC call, or
+   "smc": if the driver shall use an SMC call.
+
+Optional properties:
+- arm,func-ids An array of 32-bit values specifying the function
+   IDs used by each mailbox channel. Those function IDs
+   follow the ARM SMC calling convention standard [1].
+   There is one identifier per channel and the number
+   of supported channels is determined by the length
+   of this array.
+
+Example:
+
+
+   sram@91 {
+   compatible = "mmio-sram";
+   reg = <0x0 0x93f000 0x0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x0 0x93f000 0x1000>;
+
+   cpu_scp_lpri: scp-shmem@0 {
+   compatible = "arm,scmi-shmem";
+   reg = <0x0 0x200>;
+   };
+
+   cpu_scp_hpri: scp-shmem@200 {
+   compatible = "arm,scmi-shmem";
+   reg = <0x200 0x200>;
+   };
+   };
+
+   smc_mbox: mailbox {
+   #mbox-cells = <1>;
+   compatible = "arm,smc-mbox";
+   method = "smc";
+   arm,num-chans = <0x2>;
+   /* Optional */
+   arm,func-ids = <0xc2fe>, <0xc2ff>;
+   };
+
+   firmware {
+   scmi {
+   compatible = "arm,scmi";
+   mboxes = <&mailbox 0 &mailbox 1>;
+   mbox-names = "tx", "rx";
+   shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+   };
+   };
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
-- 
2.16.4

[PATCH 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.

The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.

The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.

This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.

This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.

Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.

Please note that this driver just provides a generic mailbox mechanism,
though this is synchronous and one-way only (triggered by the OS only,
without providing an asynchronous way of triggering request from the
firmware).
And while providing SCMI services was the reason for this exercise, this
driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.

[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi

Peng Fan (2):
  DT: mailbox: add binding doc for the ARM SMC mailbox
  mailbox: introduce ARM SMC based mailbox

 .../devicetree/bindings/mailbox/arm-smc.txt|  96 +
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/arm-smc-mailbox.c  | 154 +
 include/linux/mailbox/arm-smc-mailbox.h|  10 ++
 5 files changed, 269 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/arm-smc-mailbox.c
 create mode 100644 include/linux/mailbox/arm-smc-mailbox.h

-- 
2.16.4

[PATCH V3 RESEND AGAIN 2/2] arm64: dts: imx: add i.MX8QXP ocotp support

[peng . fan]

From: Peng Fan 

Add i.MX8QXP ocotp node

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: Anson Huang 
Cc: Daniel Baluta 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---

V3:
 Add R-b tag
V2:
 move address/size-cells below compatible, add "scu"

 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2a48ae..725d341ee160 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -141,6 +141,12 @@
compatible = "fsl,imx8qxp-iomuxc";
};
 
+   ocotp: imx8qx-ocotp {
+   compatible = "fsl,imx8qxp-scu-ocotp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd";
#power-domain-cells = <1>;
-- 
2.16.4

[PATCH V3 RESEND AGAIN 1/2] defconfig: arm64: enable i.MX8 SCU octop driver

[peng . fan]

From: Peng Fan 

Build in CONFIG_NVMEM_IMX_OCOTP_SCU.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Shawn Guo 
Cc: Andy Gross 
Cc: Maxime Ripard 
Cc: Olof Johansson 
Cc: Jagan Teki 
Cc: Bjorn Andersson 
Cc: Leonard Crestez 
Cc: Marc Gonzalez 
Cc: Enric Balletbo i Serra 
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---

V3:
 No change
V2:
 rename patch title, add review tag

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 979a95c915b6..32b85102b857 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y
 CONFIG_QCOM_L2_PMU=y
 CONFIG_QCOM_L3_PMU=y
 CONFIG_NVMEM_IMX_OCOTP=y
+CONFIG_NVMEM_IMX_OCOTP_SCU=y
 CONFIG_QCOM_QFPROM=y
 CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_UNIPHIER_EFUSE=y
-- 
2.16.4

RE: [PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU octop driver

[Peng Fan]

Hi Shawn,

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: 2019年5月23日 20:53
> To: Peng Fan 
> Cc: srinivas.kandaga...@linaro.org; robh...@kernel.org;
> s.ha...@pengutronix.de; feste...@gmail.com; dl-linux-imx
> ; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> van.free...@gmail.com; Catalin Marinas ; Will
> Deacon ; Shawn Guo ; Andy
> Gross ; Maxime Ripard
> ; Olof Johansson ; Jagan Teki
> ; Bjorn Andersson
> ; Leonard Crestez ;
> Marc Gonzalez ; Enric Balletbo i Serra
> 
> Subject: Re: [PATCH V3 RESEND 3/4] defconfig: arm64: enable i.MX8 SCU
> octop driver
> 
> On Wed, May 22, 2019 at 01:47:05AM +, Peng Fan wrote:
> > Build in CONFIG_NVMEM_IMX_OCOTP_SCU.
> >
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Shawn Guo 
> > Cc: Andy Gross 
> > Cc: Maxime Ripard 
> > Cc: Olof Johansson 
> > Cc: Jagan Teki 
> > Cc: Bjorn Andersson 
> > Cc: Leonard Crestez 
> > Cc: Marc Gonzalez 
> > Cc: Enric Balletbo i Serra 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Reviewed-by: Dong Aisheng 
> > Signed-off-by: Peng Fan 
> 
> Please do not use base64 encoding for patch posting.

Since Srinivas picked up patch 1/4 and 2/4, so just resend the
patch 3/4 and patch 4/4.

https://patchwork.kernel.org/patch/10959149/
https://patchwork.kernel.org/patch/10959151/

Thanks,
Peng.
> 
> Shawn
> 
> > ---
> >
> > V3:
> >  No change
> > V2:
> >  rename patch title, add review tag
> >
> >  arch/arm64/configs/defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig
> > b/arch/arm64/configs/defconfig index 979a95c915b6..32b85102b857
> 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y
> >  CONFIG_QCOM_L2_PMU=y
> >  CONFIG_QCOM_L3_PMU=y
> >  CONFIG_NVMEM_IMX_OCOTP=y
> > +CONFIG_NVMEM_IMX_OCOTP_SCU=y
> >  CONFIG_QCOM_QFPROM=y
> >  CONFIG_ROCKCHIP_EFUSE=y
> >  CONFIG_UNIPHIER_EFUSE=y
> > --
> > 2.16.4
> >

[PATCH] clk: imx: pll14xx: drop unused variable

[Peng Fan]

It does not make sense to only get value from pll->base and assign
to a local variable when recalc_rate.

Signed-off-by: Peng Fan 
---
 drivers/clk/imx/clk-pll14xx.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 1acfa3e3cfb4..12e584185daf 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -74,10 +74,9 @@ static unsigned long clk_pll1416x_recalc_rate(struct clk_hw 
*hw,
  unsigned long parent_rate)
 {
struct clk_pll14xx *pll = to_clk_pll14xx(hw);
-   u32 mdiv, pdiv, sdiv, pll_gnrl, pll_div;
+   u32 mdiv, pdiv, sdiv, pll_div;
u64 fvco = parent_rate;
 
-   pll_gnrl = readl_relaxed(pll->base);
pll_div = readl_relaxed(pll->base + 4);
mdiv = (pll_div & MDIV_MASK) >> MDIV_SHIFT;
pdiv = (pll_div & PDIV_MASK) >> PDIV_SHIFT;
@@ -93,11 +92,10 @@ static unsigned long clk_pll1443x_recalc_rate(struct clk_hw 
*hw,
  unsigned long parent_rate)
 {
struct clk_pll14xx *pll = to_clk_pll14xx(hw);
-   u32 mdiv, pdiv, sdiv, pll_gnrl, pll_div_ctl0, pll_div_ctl1;
+   u32 mdiv, pdiv, sdiv, pll_div_ctl0, pll_div_ctl1;
short int kdiv;
u64 fvco = parent_rate;
 
-   pll_gnrl = readl_relaxed(pll->base);
pll_div_ctl0 = readl_relaxed(pll->base + 4);
pll_div_ctl1 = readl_relaxed(pll->base + 8);
mdiv = (pll_div_ctl0 & MDIV_MASK) >> MDIV_SHIFT;
-- 
2.16.4

RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi Jassi,

> -Original Message-
> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
> Sent: 2019年6月21日 0:50
> To: Peng Fan 
> Cc: Rob Herring ; Mark Rutland
> ; Sudeep Holla ; Florian
> Fainelli ; , Sascha Hauer ;
> dl-linux-imx ; Shawn Guo ;
> feste...@gmail.com; Devicetree List ; Linux
> Kernel Mailing List ;
> linux-arm-ker...@lists.infradead.org; Andre Przywara
> ; van.free...@gmail.com
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Mon, Jun 3, 2019 at 3:28 AM  wrote:
> >
> > From: Peng Fan 
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966462272457978&sdata=Hzgeu43m5
> ZkeRMtL8Bx
> > gUm3%2B6FBObib1OPHPlSccE%2B0%3D&reserved=0
> >
> > Cc: Andre Przywara 
> > Signed-off-by: Peng Fan 
> > ---
> >
> > V2:
> >  Add interrupts notification support.
> >
> >  drivers/mailbox/Kconfig |   7 ++
> >  drivers/mailbox/Makefile|   2 +
> >  drivers/mailbox/arm-smc-mailbox.c   | 190
> 
> >  include/linux/mailbox/arm-smc-mailbox.h |  10 ++
> >  4 files changed, 209 insertions(+)
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> >   The controller has 3 mailbox channels, the last of which can be
> >   used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > +   tristate "Generic ARM smc mailbox"
> > +   depends on OF && HAVE_ARM_SMCCC
> > +   help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> >  config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST diff --git
> > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
> >
> >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include  #include
> > +
> > +#include 
> > +#include 
> > +
> > +#define ARM_SMC_MBOX_USE_HVC   BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ   BIT(1)
> > +
> IRQ bit is unused (and unnecessary IMO)

This will be removed in next version.

> 
> > +struct arm_smc_chan_data {
> > +   u32 function_id;
> > +   u32 flags;
> > +   int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > +   struct arm_smc_chan_data *chan_data = link->con_priv;
> > +   struct arm_smccc_mbox_cmd *cmd = data;
> > +

RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi Sudeep,

> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Thu, Jun 20, 2019 at 10:21:09AM +0000, Peng Fan wrote:
> > Hi Sudeep,
> >
> > > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> > >
> > > On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng@nxp.com wrote:
> > > > From: Peng Fan 
> > > >
> > > > This mailbox driver implements a mailbox which signals transmitted
> > > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > > receiver is implemented in firmware and can synchronously return
> > > > data when it returns execution to the non-secure world again.
> > > > An asynchronous receive path is not implemented.
> > > > This allows the usage of a mailbox to trigger firmware actions on
> > > > SoCs which either don't have a separate management processor or on
> > > > which such a core is not available. A user of this mailbox could
> > > > be the SCP interface.
> > > >
> > > > Modified from Andre Przywara's v2 patch https://lore
> > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C0
> 1%7
> > > Cpeng.fa
> > > >
> > >
> n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> > > c6fa92cd
> > > >
> > >
> 99c5c301635%7C0%7C0%7C636966193913988679&sdata=UNM4MTPs
> > > brqoMqWStEy
> > > > YzzwMEWTmX7hHO3TeNEz%2BOAw%3D&reserved=0
> > > >
> > > > Cc: Andre Przywara 
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >
> > > > V2:
> > > >  Add interrupts notification support.
> > > >
> > > >  drivers/mailbox/Kconfig |   7 ++
> > > >  drivers/mailbox/Makefile|   2 +
> > > >  drivers/mailbox/arm-smc-mailbox.c   | 190
> > > 
> > > >  include/linux/mailbox/arm-smc-mailbox.h |  10 ++
> > > >  4 files changed, 209 insertions(+)
> > > >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create
> mode
> > > > 100644 include/linux/mailbox/arm-smc-mailbox.h
> > > >
> > > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > > > 595542bfae85..c3bd0f1ddcd8 100644
> > > > --- a/drivers/mailbox/Kconfig
> > > > +++ b/drivers/mailbox/Kconfig
> > > > @@ -15,6 +15,13 @@ config ARM_MHU
> > > >   The controller has 3 mailbox channels, the last of which can 
> > > > be
> > > >   used in Secure mode only.
> > > >
> > > > +config ARM_SMC_MBOX
> > > > +   tristate "Generic ARM smc mailbox"
> > > > +   depends on OF && HAVE_ARM_SMCCC
> > > > +   help
> > > > + Generic mailbox driver which uses ARM smc calls to call into
> > > > + firmware for triggering mailboxes.
> > > > +
> > > >  config IMX_MBOX
> > > > tristate "i.MX Mailbox"
> > > > depends on ARCH_MXC || COMPILE_TEST
> > > > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > > > c22fad6f696b..93918a84c91b 100644
> > > > --- a/drivers/mailbox/Makefile
> > > > +++ b/drivers/mailbox/Makefile
> > > > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
> > > >
> > > >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> > > >
> > > > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > > > +
> > > >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> > > >
> > > >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> > > armada-37xx-rwtm-mailbox.o
> > > > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > > > b/drivers/mailbox/arm-smc-mailbox.c
> > > > new file mode 100644
> > > > index ..fef6e38d8b98
> > > > --- /dev/null
> > > > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > > > @@ -0,0 +1,190 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (C) 2016,2017 ARM Ltd.
> > > > + * Copyright 2019 NXP
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include  #include
> > > > +

RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi Jassi

> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Mon, Jun 3, 2019 at 3:28 AM  wrote:
> >
> > From: Peng Fan 
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966462272457978&sdata=Hzgeu43m5
> ZkeRMtL8Bx
> > gUm3%2B6FBObib1OPHPlSccE%2B0%3D&reserved=0
> >
> > Cc: Andre Przywara 
> > Signed-off-by: Peng Fan 
> > ---
> >
> > V2:
> >  Add interrupts notification support.
> >
> >  drivers/mailbox/Kconfig |   7 ++
> >  drivers/mailbox/Makefile|   2 +
> >  drivers/mailbox/arm-smc-mailbox.c   | 190
> 
> >  include/linux/mailbox/arm-smc-mailbox.h |  10 ++
> >  4 files changed, 209 insertions(+)
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> >   The controller has 3 mailbox channels, the last of which can be
> >   used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > +   tristate "Generic ARM smc mailbox"
> > +   depends on OF && HAVE_ARM_SMCCC
> > +   help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> >  config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST diff --git
> > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
> >
> >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include  #include
> > +
> > +#include 
> > +#include 
> > +
> > +#define ARM_SMC_MBOX_USE_HVC   BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ   BIT(1)
> > +
> IRQ bit is unused (and unnecessary IMO)
> 
> > +struct arm_smc_chan_data {
> > +   u32 function_id;
> > +   u32 flags;
> > +   int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > +   struct arm_smc_chan_data *chan_data = link->con_priv;
> > +   struct arm_smccc_mbox_cmd *cmd = data;
> > +   struct arm_smccc_res res;
> > +   u32 function_id;
> > +
> > +   if (chan_data->function_id != UINT_MAX)
> > +   function_id = chan_data->function_id;
> > +   else
> > +   function_id = cmd->a0;
> > +
> Not sure about chan_data->function_id.  Why restrict from DT?
> 'a0' is the function_id register, let the user pass func-id via the 'a0' like 
> other
> values via '

RE: [PATCH 1/2] ARM: imx: drop uneccessary of_platform_default_populate

[Peng Fan]

Hi Aisheng,

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年3月15日 18:17
> To: Peng Fan ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> dl-linux-imx ; Anson Huang ;
> a...@arndb.de; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Cc: van.free...@gmail.com
> Subject: RE: [PATCH 1/2] ARM: imx: drop uneccessary
> of_platform_default_populate
> 
> > From: Peng Fan
> >
> > "arch_initcall_sync(of_platform_default_populate_init);" could be used
> > to populate the device tree, there is no need to call
> > of_platform_default_populate in machine code.
> >
> > Tested on i.MX6Q-SDB i.MX6SL-EVK i.MX6UL-EVK board.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm/mach-imx/mach-imx6q.c  | 2 --
> > arch/arm/mach-imx/mach-imx6sl.c | 2 --
> > arch/arm/mach-imx/mach-imx6sx.c | 2 --
> > arch/arm/mach-imx/mach-imx6ul.c | 1 -
> >  4 files changed, 7 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/mach-imx6q.c
> > b/arch/arm/mach-imx/mach-imx6q.c index 7d80a0ae723c..655398c20256
> > 100644
> > --- a/arch/arm/mach-imx/mach-imx6q.c
> > +++ b/arch/arm/mach-imx/mach-imx6q.c
> > @@ -278,8 +278,6 @@ static void __init imx6q_init_machine(void)
> >
> > imx6q_enet_phy_init();
> >
> > -   of_platform_default_populate(NULL, NULL, parent);
> > -
> 
> This slightly change the device register sequence as well as possible driver
> probe sequence as a consequence.

This patch is inspired from patch:

commit 850bea2335e42780a0752a75860d3fbcc3d12d6e
Author: Kefeng Wang 
Date:   Wed Jun 1 14:52:56 2016 +0800

arm: Remove unnecessary of_platform_populate with default match table

After patch "of/platform: Add common method to populate default bus",
it is possible for arch code to remove unnecessary callers of
of_platform_populate with default match table.

> 
> Originally devices are registered in arch_initcall. Now it will be a bit 
> later in
> arch_initcall_sync and this may cause a bit risk if the code under the
> default_populate want to access the device service provided by early probe.
> 
> Probably it's more safe to leave as it is unless you can double confirm 
> there're
> no such code depends on accessing early probed devices as follows before we
> can make the change.

This has been boot tested on 6Q-SDB/6UL-EVK/6SL-EVK board.
For i.MX, I only see pinctrl driver use arch_initcall from the link,
https://elixir.bootlin.com/linux/latest/ident/arch_initcall

From my boot test, the pinctrl driver probe will be delayed a bit, but I do
not see issues.

The common code is introduced by this patch, one thing need to consider
is the of_iommu_init and swiotlb_late_init on aarch64. My patch
is only for i.MX6/7, so I think there is no such issue.
commit 44a7185c2ae6383c88ff5b1ef2e2969f35d7b8b7
Author: Kefeng Wang 
Date:   Wed Jun 1 14:52:54 2016 +0800

of/platform: Add common method to populate default bus

The arch code calls of_platform_populate() with default match table
when it wants to populate default bus.

This patch introduce a new of_platform_default_populate_init() and make it
arch_initcall_sync(it should be later than some iommu configration, eg,
of_iommu_init() and swiotlb_late_init in arm64), then we can finish above
job in common method.

In order to avoid the default bus being populated twice, simply checking
the flag of bus node whether has be set OF_POPULATED_BUS or not.

After that, we can safely remove the caller in arch code.

Btw, add debug print in of_platform_populate(), and use __func__ to
print function's name of of_platform_bus_create().


Thanks,
Peng.

> 
> > imx_anatop_init();
> > cpu_is_imx6q() ?  imx6q_pm_init() : imx6dl_pm_init();
> > imx6q_1588_init();
> 
> Regards
> Dong Aisheng
> 
> > diff --git a/arch/arm/mach-imx/mach-imx6sl.c
> > b/arch/arm/mach-imx/mach-imx6sl.c index 99be4225297a..9743bdbb68fa
> > 100644
> > --- a/arch/arm/mach-imx/mach-imx6sl.c
> > +++ b/arch/arm/mach-imx/mach-imx6sl.c
> > @@ -56,8 +56,6 @@ static void __init imx6sl_init_machine(void)
> > if (parent == NULL)
> > pr_warn("failed to initialize soc device\n");
> >
> > -   of_platform_default_populate(NULL, NULL, parent);
> > -
> > if (cpu_is_imx6sl())
> > imx6sl_fec_init();
> > imx_anatop_init();
> > diff --git a/arch/arm/mach-imx/mach-imx6sx.c
> > b/arch/arm/mach-imx/mach-imx6sx.c index 7f52d9b1e8a4..19b9f2dd309e
> > 100644
> > --- a/arch/arm/mach-imx/mach-imx6sx.c
> > +++ b/arch/arm/mach-imx/mach-imx6sx.c
> &g

RE: [PATCH 2/2] ARM: imx: mach-imx7ulp: warn when imx_soc_device_init fail

[Peng Fan]

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年3月15日 18:22
> To: Peng Fan ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> dl-linux-imx ; Anson Huang ;
> a...@arndb.de; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Cc: van.free...@gmail.com
> Subject: RE: [PATCH 2/2] ARM: imx: mach-imx7ulp: warn when
> imx_soc_device_init fail
> 
> > From: Peng Fan
> >
> > [PATCH 2/2] ARM: imx: mach-imx7ulp: warn when imx_soc_device_init fail
> 
> ARM: imx: imx7ulp: ...

Ok.
> 
> > Follow other i.MX6/7 machince code to check return value of
> > imx_soc_device_init and warn when fail.
> >
> > Also drop of_platform_default_populate, because
> > "arch_initcall_sync(of_platform_default_populate_init);" could be used
> > to populate the device tree.
> >
> 
> This could be in separate patch.

I'll do it in v2 after we agree the change in the first patch.

> 
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm/mach-imx/mach-imx7ulp.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-imx/mach-imx7ulp.c
> > b/arch/arm/mach-imx/mach-imx7ulp.c
> > index 11ac71aaf965..6d823f05d9aa 100644
> > --- a/arch/arm/mach-imx/mach-imx7ulp.c
> > +++ b/arch/arm/mach-imx/mach-imx7ulp.c
> > @@ -53,11 +53,16 @@ static void __init imx7ulp_set_revision(void)
> >
> >  static void __init imx7ulp_init_machine(void)  {
> > +   struct device *soc_dev;
> > +
> > +   soc_dev = imx_soc_device_init();
> > +   if (soc_dev == NULL)
> > +   pr_warn("failed to initialize soc device\n");
> > +
> 
> Should this be under set revision?

Just follow other i.MX6/7 platforms practice, I could move
this under set revision in v2 if you prefer.

Thanks,
Peng.

> 
> Regards
> Dong Aisheng
> 
> > imx7ulp_pm_init();
> >
> > mxc_set_cpu_type(MXC_CPU_IMX7ULP);
> > imx7ulp_set_revision();
> > -   of_platform_default_populate(NULL, NULL, imx_soc_device_init());
> >  }
> >
> >  static const char *const imx7ulp_dt_compat[] __initconst = {
> > --
> > 2.16.4

RE: [PATCH 1/2] ARM: imx: drop uneccessary of_platform_default_populate

[Peng Fan]

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年3月15日 21:39
> To: Peng Fan ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> dl-linux-imx ; Anson Huang ;
> a...@arndb.de; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Cc: van.free...@gmail.com
> Subject: RE: [PATCH 1/2] ARM: imx: drop uneccessary
> of_platform_default_populate
> 
> [...]
> 
> > > Originally devices are registered in arch_initcall. Now it will be a
> > > bit later in arch_initcall_sync and this may cause a bit risk if the
> > > code under the default_populate want to access the device service
> > > provided
> > by early probe.
> > >
> > > Probably it's more safe to leave as it is unless you can double
> > > confirm there're no such code depends on accessing early probed
> > > devices as follows before we can make the change.
> >
> > This has been boot tested on 6Q-SDB/6UL-EVK/6SL-EVK board.
> > For i.MX, I only see pinctrl driver use arch_initcall from the link,
> > https://elixir.bootlin.com/linux/latest/ident/arch_initcall
> >
> > From my boot test, the pinctrl driver probe will be delayed a bit, but
> > I do not see issues.
> >
> 
> From what I saw, imx6q_1588_init() and imx6q_axi_init() will use syscon which
> is registered with postcore_initcall. Without having syscon devices populated,
> I wonder those calls may fall.
> Can you double check it?

I do not see failure in imx6q_1588_init by adding a return value check of
regmap_update_bits, But the imx6q_pm_init will find ocram device for
suspend usage, postpone the device population will make imx6q_pm_init
fail, so drop this patch and leave the code as it is.

Thanks,
Peng.

> 
> Regards
> Dong Aisheng

RE: [PATCH] arm: use memblocks_present

[Peng Fan]

Hi Russell,

> -Original Message-
> From: Russell King - ARM Linux admin [mailto:li...@armlinux.org.uk]
> Sent: 2019年2月13日 1:27
> To: Peng Fan 
> Cc: a...@arndb.de; r...@linux.vnet.ibm.com; r...@kernel.org;
> f.faine...@gmail.com; a...@linux-foundation.org; mho...@suse.com;
> rost...@goodmis.org; nicolas.pi...@linaro.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> van.free...@gmail.com
> Subject: Re: [PATCH] arm: use memblocks_present
> 
> On Mon, Feb 11, 2019 at 01:04:59PM +, Peng Fan wrote:
> > arm_memory_present is doing same thing as memblocks_present, so let's
> > use common code memblocks_present instead of platform specific
> > arm_memory_present.
> >
> > Signed-off-by: Peng Fan 
> 
> Looks good, please put it in the patch system, thanks.  Details in my
> signature.

Would you apply this patch? I do not find this patch in your tree.

Thanks,
Peng.

> 
> > ---
> >  arch/arm/mm/init.c | 17 +
> >  1 file changed, 1 insertion(+), 16 deletions(-)
> >
> > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index
> > 478ea8b7db87..6c50dd407ba8 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -182,21 +182,6 @@ int pfn_valid(unsigned long pfn)
> > EXPORT_SYMBOL(pfn_valid);  #endif
> >
> > -#ifndef CONFIG_SPARSEMEM
> > -static void __init arm_memory_present(void) -{ -} -#else -static void
> > __init arm_memory_present(void) -{
> > -   struct memblock_region *reg;
> > -
> > -   for_each_memblock(memory, reg)
> > -   memory_present(0, memblock_region_memory_base_pfn(reg),
> > -  memblock_region_memory_end_pfn(reg));
> > -}
> > -#endif
> > -
> >  static bool arm_memblock_steal_permitted = true;
> >
> >  phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t
> > align) @@ -292,7 +277,7 @@ void __init bootmem_init(void)
> >  * Sparsemem tries to allocate bootmem in memory_present(),
> >  * so must be done after the fixed reservations
> >  */
> > -   arm_memory_present();
> > +   memblocks_present();
> >
> > /*
> >  * sparse_init() needs the bootmem allocator up and running.
> > --
> > 2.16.4
> >
> >
> 
> --
> RMK's Patch system:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cpe
> ng.fan%40nxp.com%7Cb710ce9f14c942463c7b08d6910f548a%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636855892359986096&sdat
> a=7yqUJVZrNl5lxUwn7g0CzgF9yg764AIeiVG7wIk%2Fgt0%3D&reserved=
> 0
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps
> up According to speedtest.net: 11.9Mbps down 500kbps up

RE: [PATCH 2/2] ARM: imx: mach-imx7ulp: warn when imx_soc_device_init fail

[Peng Fan]

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年3月15日 21:40
> To: Peng Fan ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> dl-linux-imx ; Anson Huang ;
> a...@arndb.de; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Cc: van.free...@gmail.com
> Subject: RE: [PATCH 2/2] ARM: imx: mach-imx7ulp: warn when
> imx_soc_device_init fail
> 
> [...]
> 
> > > > Follow other i.MX6/7 machince code to check return value of
> > > > imx_soc_device_init and warn when fail.
> > > >
> > > > Also drop of_platform_default_populate, because
> > > > "arch_initcall_sync(of_platform_default_populate_init);" could be
> > > > used to populate the device tree.
> > > >
> > >
> > > This could be in separate patch.
> >
> > I'll do it in v2 after we agree the change in the first patch.
> >
> 
> I think imx7ulp does not have the issue in patch 1.

Missed to reply you.
So do you agree to split this patch into two
patches ? or leave the code as it is?

The first is follow other i.mx6/7 to check return value of
imx_soc_device_init. 
The second is drop the call to of_platform_default_populate.

Thanks,
Peng

> 
> Regards
> Dong Aisheng
> 
> > >
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >  arch/arm/mach-imx/mach-imx7ulp.c | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-imx/mach-imx7ulp.c
> > > > b/arch/arm/mach-imx/mach-imx7ulp.c
> > > > index 11ac71aaf965..6d823f05d9aa 100644
> > > > --- a/arch/arm/mach-imx/mach-imx7ulp.c
> > > > +++ b/arch/arm/mach-imx/mach-imx7ulp.c
> > > > @@ -53,11 +53,16 @@ static void __init imx7ulp_set_revision(void)
> > > >
> > > >  static void __init imx7ulp_init_machine(void)  {
> > > > +   struct device *soc_dev;
> > > > +
> > > > +   soc_dev = imx_soc_device_init();
> > > > +   if (soc_dev == NULL)
> > > > +   pr_warn("failed to initialize soc device\n");
> > > > +
> > >
> > > Should this be under set revision?
> >
> > Just follow other i.MX6/7 platforms practice, I could move this under
> > set revision in v2 if you prefer.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > Regards
> > > Dong Aisheng
> > >
> > > > imx7ulp_pm_init();
> > > >
> > > > mxc_set_cpu_type(MXC_CPU_IMX7ULP);
> > > > imx7ulp_set_revision();
> > > > -   of_platform_default_populate(NULL, NULL, imx_soc_device_init());
> > > >  }
> > > >
> > > >  static const char *const imx7ulp_dt_compat[] __initconst = {
> > > > --
> > > > 2.16.4

RE: [PATCH] arm: use memblocks_present

[Peng Fan]

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年3月19日 21:14
> To: Peng Fan 
> Cc: Russell King - ARM Linux admin ;
> nicolas.pi...@linaro.org; r...@kernel.org; mho...@suse.com;
> a...@arndb.de; linux-kernel@vger.kernel.org; rost...@goodmis.org;
> r...@linux.vnet.ibm.com; van.free...@gmail.com; f.faine...@gmail.com;
> a...@linux-foundation.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] arm: use memblocks_present
> 
> Hi Peng,
> 
> On Tue, Mar 19, 2019 at 9:31 AM Peng Fan  wrote:
> 
> > > Looks good, please put it in the patch system, thanks.  Details in
> > > my signature.
> >
> > Would you apply this patch? I do not find this patch in your tree.
> 
> Have you put it in Russell's patch system

Thanks for reminding me, just added
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8850/1

Thanks,
Peng.

> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cpeng.
> fan%40nxp.com%7C4491585dd8f442ae0f8508d6ac6cd313%7C686ea1d3bc2
> b4c6fa92cd99c5c301635%7C0%7C0%7C636885980729920657&sdata=
> SH%2FCKbq7swWUyn2DxhxkX5hpF%2FYSD8NfC9c6bc%2FM6XM%3D&r
> eserved=0) ?

RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi Sudeep,

> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng@nxp.com wrote:
> > From: Peng Fan 
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966193913988679&sdata=UNM4MTPs
> brqoMqWStEy
> > YzzwMEWTmX7hHO3TeNEz%2BOAw%3D&reserved=0
> >
> > Cc: Andre Przywara 
> > Signed-off-by: Peng Fan 
> > ---
> >
> > V2:
> >  Add interrupts notification support.
> >
> >  drivers/mailbox/Kconfig |   7 ++
> >  drivers/mailbox/Makefile|   2 +
> >  drivers/mailbox/arm-smc-mailbox.c   | 190
> 
> >  include/linux/mailbox/arm-smc-mailbox.h |  10 ++
> >  4 files changed, 209 insertions(+)
> >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> >   The controller has 3 mailbox channels, the last of which can be
> >   used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > +   tristate "Generic ARM smc mailbox"
> > +   depends on OF && HAVE_ARM_SMCCC
> > +   help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> >  config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  += mailbox-test.o
> >
> >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include  #include
> > +
> > +#include 
> > +#include 
> > +
> > +#define ARM_SMC_MBOX_USE_HVC   BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ   BIT(1)
> > +
> > +struct arm_smc_chan_data {
> > +   u32 function_id;
> > +   u32 flags;
> > +   int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > +   struct arm_smc_chan_data *chan_data = link->con_priv;
> > +   struct arm_smccc_mbox_cmd *cmd = data;
> > +   struct arm_smccc_res res;
> > +   u32 function_id;
> > +
> > +   if (chan_data->function_id != UINT_MAX)
> > +   function_id = chan_data->function_id;
> > +   else
> > +   function_id = cmd->a0;
> > +
> > +   if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > +   arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3,
> cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, &res);
> > +   else
> > +   arm_smccc_smc(functi

RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

[Peng Fan]

Hi All,

> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> 
> On Tue, Jun 25, 2019 at 2:30 AM Peng Fan  wrote:
> >
> > Hi Jassi
> >
> > > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> > >
> > > On Mon, Jun 3, 2019 at 3:28 AM  wrote:
> > > >
> > > > From: Peng Fan 
> > > >
> > > > This mailbox driver implements a mailbox which signals transmitted
> > > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > > receiver is implemented in firmware and can synchronously return
> > > > data when it returns execution to the non-secure world again.
> > > > An asynchronous receive path is not implemented.
> > > > This allows the usage of a mailbox to trigger firmware actions on
> > > > SoCs which either don't have a separate management processor or on
> > > > which such a core is not available. A user of this mailbox could
> > > > be the SCP interface.
> > > >
> > > > Modified from Andre Przywara's v2 patch https://lore
> > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C0
> 1%7
> > > Cpeng.fa
> > > >
> > >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> > > c6fa92cd
> > > >
> > >
> 99c5c301635%7C0%7C0%7C636966462272457978&sdata=Hzgeu43m5
> > > ZkeRMtL8Bx
> > > > gUm3%2B6FBObib1OPHPlSccE%2B0%3D&reserved=0
> > > >
> > > > Cc: Andre Przywara 
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >
> > > > V2:
> > > >  Add interrupts notification support.
> > > >
> > > >  drivers/mailbox/Kconfig |   7 ++
> > > >  drivers/mailbox/Makefile|   2 +
> > > >  drivers/mailbox/arm-smc-mailbox.c   | 190
> > > 
> > > >  include/linux/mailbox/arm-smc-mailbox.h |  10 ++
> > > >  4 files changed, 209 insertions(+)
> > > >  create mode 100644 drivers/mailbox/arm-smc-mailbox.c  create
> mode
> > > > 100644 include/linux/mailbox/arm-smc-mailbox.h
> > > >
> > > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > > > 595542bfae85..c3bd0f1ddcd8 100644
> > > > --- a/drivers/mailbox/Kconfig
> > > > +++ b/drivers/mailbox/Kconfig
> > > > @@ -15,6 +15,13 @@ config ARM_MHU
> > > >   The controller has 3 mailbox channels, the last of which can
> be
> > > >   used in Secure mode only.
> > > >
> > > > +config ARM_SMC_MBOX
> > > > +   tristate "Generic ARM smc mailbox"
> > > > +   depends on OF && HAVE_ARM_SMCCC
> > > > +   help
> > > > + Generic mailbox driver which uses ARM smc calls to call into
> > > > + firmware for triggering mailboxes.
> > > > +
> > > >  config IMX_MBOX
> > > > tristate "i.MX Mailbox"
> > > > depends on ARCH_MXC || COMPILE_TEST diff --git
> > > > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > > > c22fad6f696b..93918a84c91b 100644
> > > > --- a/drivers/mailbox/Makefile
> > > > +++ b/drivers/mailbox/Makefile
> > > > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)  +=
> mailbox-test.o
> > > >
> > > >  obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
> > > >
> > > > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > > > +
> > > >  obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> > > >
> > > >  obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> > > armada-37xx-rwtm-mailbox.o
> > > > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > > > b/drivers/mailbox/arm-smc-mailbox.c
> > > > new file mode 100644
> > > > index ..fef6e38d8b98
> > > > --- /dev/null
> > > > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > > > @@ -0,0 +1,190 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (C) 2016,2017 ARM Ltd.
> > > > + * Copyright 2019 NXP
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include  #include
> > > > +
> > > > +

RE: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property

[Peng Fan]

Hi Rob,

> Subject: Re: [RFC 1/2] dt-bindings: imx-ocotp: Add fusable-node property
> 
> On Mon, May 20, 2019 at 03:06:35AM +0000, Peng Fan wrote:
> > Introduce fusable-node property for i.MX OCOTP driver.
> > The property will only be used by Firmware(eg. U-Boot) to runtime
> > disable the nodes.
> >
> > Take i.MX6ULL for example, there are several parts that only have
> > limited modules enabled controlled by OCOTP fuse. It is not flexible
> > to provide several dts for the serval parts, instead we could provide
> > one device tree and let Firmware to runtime disable the device tree
> > nodes for those modules that are disable(fused).
> >
> > Signed-off-by: Peng Fan 
> > ---
> >
> > Currently NXP vendor use U-Boot to set status to disabled for devices
> > that could not function,
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Ftree%2Farch%2Far
> m%2Fm
> >
> ach-imx%2Fmx6%2Fmodule_fuse.c%3Fh%3Dimx_v2018.03_4.14.98_2.0.0_g
> a%23n1
> >
> 49&data=02%7C01%7Cpeng.fan%40nxp.com%7Ceb74876c943c4471d7f
> f08d6f05
> >
> 2fffb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63696063660
> 6051306&
> >
> amp;sdata=MrjCP0ufBu3uTb1ehTEu2g5eSQuYcho4UxuR9KUFEOA%3D&
> reserved=
> > 0 But this approach is will not work if kernel dts node path changed.
> 
> Why would the path change? The DT should be stable.

It changes sometimes, such as
efb9adb27475 ("ARM: dts: imx6ul: Remove leading zeroes from unit addresses"),

in bootloader, we are using node path, so if the node name changes, the 
bootloader
will fail to disable the node.

Thanks,
Peng.

> 
> Rob

RE: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox

[Peng Fan]

Hi Jassi,

> Subject: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox

Are you fine with this patch set?

Thanks,
Peng.

> 
> From: Peng Fan 
> 
> V10:
>  - Add R-b tag from Andre, Rob and Florian
>  - Two minor fixes
>   - Drop "passed from consumers" in patch 1/2 per Andre's comments
>   - Drop interrupts.h in patch 2/2 per Andre's comments
> 
> V9:
>  - Add Florian's R-b tag in patch 1/2
>  - Mark arm,func-id as a required property per Andre's comments in patch
> 1/2.
>  - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's
>comments in pach 2/2
>  - Include linux/types.h in arm-smccc-mbox.h in patch 2/2
>  - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT
>in patch 2/2/.
> 
>Andre,
> I have marked arm,func-id as a required property and dropped
> function-id
> from client, please see whether you are happy with the patchset.
> Hope we could finalize and get patches land in.
> 
>Thanks,
>Peng.
> 
> V8:
> Add missed arm-smccc-mbox.h
> 
> V7:
> Typo fix
> #mbox-cells changed to 0
> Add a new header file arm-smccc-mbox.h
> Use ARM_SMCCC_IS_64
> 
> Andre,
>   The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id
> property is optional, so clients could pass function_id to mbox driver.
> 
> V6:
> Switch to per-channel a mbox controller
> Drop arm,num-chans, transports, method
> Add arm,hvc-mbox compatible
> Fix smc/hvc args, drop client id and use correct type.
> https://patchwork.kernel.org/cover/11146641/
> 
> V5:
> yaml fix
> https://patchwork.kernel.org/cover/7741/
> 
> V4:
> yaml fix for num-chans in patch 1/2.
> https://patchwork.kernel.org/cover/6521/
> 
> V3:
> Drop interrupt
> Introduce transports for mem/reg usage
> Add chan-id for mem usage
> Convert to yaml format
> https://patchwork.kernel.org/cover/11043541/
> 
> V2:
> This is a modified version from Andre Przywara's patch series
> https://lore.kernel.org/patchwork/cover/812997/.
> The modification are mostly:
> Introduce arm,num-chans
> Introduce arm_smccc_mbox_cmd
> txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as
> an optional property.
> Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
> Introduce interrupts notification.
> 
> [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use
> smc as mailbox, power/clk is included, but only part of clk has been
> implemented to work with hardware, power domain only supports get name
> for now.
> 
> The traditional Linux mailbox mechanism uses some kind of dedicated
> hardware IP to signal a condition to some other processing unit, typically a
> dedicated management processor.
> This mailbox feature is used for instance by the SCMI protocol to signal a
> request for some action to be taken by the management processor.
> However some SoCs does not have a dedicated management core to provide
> those services. In order to service TEE and to avoid linux shutdown power and
> clock that used by TEE, need let firmware to handle power and clock, the
> firmware here is ARM Trusted Firmware that could also run SCMI service.
> 
> The existing SCMI implementation uses a rather flexible shared memory
> region to communicate commands and their parameters, it still requires a
> mailbox to actually trigger the action.
> 
> This patch series provides a Linux mailbox compatible service which uses smc
> calls to invoke firmware code, for instance taking care of SCMI requests.
> The actual requests are still communicated using the standard SCMI way of
> shared memory regions, but a dedicated mailbox hardware IP can be replaced
> via this new driver.
> 
> This simple driver uses the architected SMC calling convention to trigger
> firmware services, also allows for using "HVC" calls to call into hypervisors 
> or
> firmware layers running in the EL2 exception level.
> 
> Patch 1 contains the device tree binding documentation, patch 2 introduces
> the actual mailbox driver.
> 
> Please note that this driver just provides a generic mailbox mechanism, It
> could support synchronous TX/RX, or synchronous TX with asynchronous RX.
> And while providing SCMI services was the reason for this exercise, this 
> driver
> is in no way bound to this use case, but can be used generically where the OS
> wants to signal a mailbox condition to firmware or a hypervisor.
> Also the driver is in no way meant to replace any existing firmware interface,
> but actually to complement existing interfaces.
> 
> [1] https://github.com/MrVan/arm-trusted-firmware/tree/sc

RE: [PATCH 2/4] firmware: imx: add resource management api

[Peng Fan]

> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
> 
> > From: Peng Fan 
> > Sent: Monday, June 1, 2020 8:40 PM
> > >
> > > > From: Peng Fan 
> > > > Sent: Friday, April 24, 2020 9:12 AM
> > > > >
> > > > > > From: Peng Fan 
> > > > > > Sent: Thursday, April 23, 2020 6:57 PM
> > > > > > > > From: Peng Fan 
> > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM
> > > > > > > >
> > > > > > > > Add resource management API, when we have multiple
> > > > > > > > partition running together, resources not owned to current
> > > > > > > > partition should not be
> > > > > used.
> > > > > > > >
> > > > > > > > Reviewed-by: Leonard Crestez 
> > > > > > > > Signed-off-by: Peng Fan 
> > > > > > >
> > > > > > > Right now I'm still not quite understand if we really need this.
> > > > > > > As current resource is bound to power domains, if it's not
> > > > > > > owned by one specific SW execution environment, power on
> > > > > > > will also
> > fail.
> > > > > > > Can you clarify if any exceptions?
> > > > > >
> > > > > > There will be lots of failures when boot Linux domu if no check.
> > > > > >
> > > > >
> > > > > What kind of features did you mean?
> > > > > Could you clarify a bit more? I'd like to understand this issue 
> > > > > better.
> > > >
> > > > When supporting hypervisor with dual Linux running, 1st Linux and
> > > > the 2nd Linux will have their own dedicated resources.
> > > >
> > > > If no resource check, that means 1st/2nd Linux will register all
> > > > the resources, then both will see fail logs when register
> > > > resources not owned to
> > > itself.
> > > >
> > > > Same to partitioned m4 case.
> > > >
> > > > Would it be better without the failure log?
> > > >
> > >
> > > Is it power up failure?
> > > If yes, it's expected because we actually use power up to check if
> > > resources are owned by this partition. It functions the same as
> > > calling resource check API.
> > > That's current design.
> > >
> > > Or it's other failures? Log?
> > Sorry for long late reply.
> >
> > Part of my XEN DomU log, there are lots of failure log. I think better
> > not have such logs by add a resource own check.
> 
> Those error logs are intended.
> Resource owner check actually behaves the same as power up.

If resource is not owned, it will not register the power domain.

Without resource own check, it will continue register the power domain
and hook it into genpd list.

I prefer we not expose the power domain not owned to current
partition and keep the err msg for people to easy
see where it goes wrong.

Regards,
Peng.
> So not quite necessary to add a double check.
> If we're concerning about the error log, we can change it to dev_dbg().
> 
> BTW, as resource management will be needed by seco drivers later, So I will
> continue to review the patch.
> 
> Regards
> Aisheng
> 
> >
> > [2.034774] imx6q-pcie 5f00.pcie:IO 0x6ff8..0x6ff8 ->
> > 0x
> > [2.034801] imx6q-pcie 5f00.pcie:   MEM 0x6000..0x6fef
> ->
> > 0x6000
> > [2.035072]  sdhc1: failed to power up resource 249 ret -13
> > [2.035619]  sdhc2: failed to power up resource 250 ret -13
> > [2.036126]  enet0: failed to power up resource 251 ret -13
> > [2.036584]  enet1: failed to power up resource 252 ret -13
> > [2.037040]  mlb0: failed to power up resource 253 ret -13
> > [2.037495]  nand: failed to power up resource 265 ret -13
> > [2.037951]  nand: failed to power up resource 265 ret -13
> > [2.038416]  pwm0: failed to power up resource 191 ret -13
> > [2.038868]  pwm1: failed to power up resource 192 ret -13
> > [2.039320]  pwm2: failed to power up resource 193 ret -13
> > [2.039786]  pwm3: failed to power up resource 194 ret -13
> > [2.040239]  pwm4: failed to power up resource 195 ret -13
> > [2.040692]  pwm5: failed to power up resource 196 ret -13
> > [2.041142]  pwm6: failed to power up resource 197 ret -13
> > [  

RE: [PATCH 2/4] firmware: imx: add resource management api

[Peng Fan]

> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
> 
> > From: Peng Fan 
> > Sent: Thursday, April 23, 2020 3:00 PM
> >
> > Add resource management API, when we have multiple partition running
> > together, resources not owned to current partition should not be used.
> >
> > Reviewed-by: Leonard Crestez 
> > Signed-off-by: Peng Fan 
> > ---
> >  drivers/firmware/imx/Makefile   |  2 +-
> >  drivers/firmware/imx/rm.c   | 40 +
> >  include/linux/firmware/imx/sci.h|  1 +
> >  include/linux/firmware/imx/svc/rm.h | 69
> > +
> >  4 files changed, 111 insertions(+), 1 deletion(-)  create mode 100644
> > drivers/firmware/imx/rm.c  create mode 100644
> > include/linux/firmware/imx/svc/rm.h
> >
> > diff --git a/drivers/firmware/imx/Makefile
> > b/drivers/firmware/imx/Makefile index 08bc9ddfbdfb..17ea3613e142
> > 100644
> > --- a/drivers/firmware/imx/Makefile
> > +++ b/drivers/firmware/imx/Makefile
> > @@ -1,4 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_IMX_DSP)  += imx-dsp.o
> > -obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o
> > +obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o rm.o
> >  obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
> > diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new
> > file mode 100644 index ..7b0334de5486
> > --- /dev/null
> > +++ b/drivers/firmware/imx/rm.c
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + *
> > + * File containing client-side RPC functions for the RM service.
> > +These
> > + * function are ported to clients that communicate to the SC.
> > + */
> > +
> > +#include 
> > +
> > +struct imx_sc_msg_rm_rsrc_owned {
> > +   struct imx_sc_rpc_msg hdr;
> > +   u16 resource;
> > +} __packed __aligned(4);
> > +
> > +/*
> > + * This function check @resource is owned by current partition or not
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in] resourceresource the control is associated with
> > + *
> > + * @return Returns 0 for success and < 0 for errors.
> > + */
> > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > +resource) {
> > +   struct imx_sc_msg_rm_rsrc_owned msg;
> > +   struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > +
> > +   hdr->ver = IMX_SC_RPC_VERSION;
> > +   hdr->svc = IMX_SC_RPC_SVC_RM;
> > +   hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > +   hdr->size = 2;
> > +
> > +   msg.resource = resource;
> > +
> > +   imx_scu_call_rpc(ipc, &msg, true);
> 
> No need check err return?

No. it use hdr->func as the resource owner bool.
However imx_scu_call_rpc also use hdr->func
to check error value or not.

When hdr->func is 1, imx_sc_to_linux_errno
will report it -EINVAL. However here 1 means
not owned.

> 
> > +
> > +   return hdr->func;
> > +}
> > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > diff --git a/include/linux/firmware/imx/sci.h
> > b/include/linux/firmware/imx/sci.h
> > index 17ba4e405129..b5c5a56f29be 100644
> > --- a/include/linux/firmware/imx/sci.h
> > +++ b/include/linux/firmware/imx/sci.h
> > @@ -15,6 +15,7 @@
> >
> >  #include   #include
> > 
> > +#include 
> >
> >  int imx_scu_enable_general_irq_channel(struct device *dev);  int
> > imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> > a/include/linux/firmware/imx/svc/rm.h
> > b/include/linux/firmware/imx/svc/rm.h
> > new file mode 100644
> > index ..fc6ea62d9d0e
> > --- /dev/null
> > +++ b/include/linux/firmware/imx/svc/rm.h
> > @@ -0,0 +1,69 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017-2019 NXP
> 
> Update copyright

ok

> 
> > + *
> > + * Header file containing the public API for the System Controller
> > +(SC)
> > + * Power Management (PM) function. This includes functions for power
> > +state
> > + * control, clock control, reset control, and wake-up event control.
> 
> Fix the code comments
> 
> Otherwise, I'm fine with this patch.
Ok.

Thanks,
Peng.

> 
> Regards
> Aisheng
> 
> > + *
> > + * RM_SVC (SVC) Resource Management Service
> > + *
> > + * Module fo

RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M

[Peng Fan]

Hi Oleksij,

> Subject: Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
> 
> On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng@nxp.com wrote:
> > From: Peng Fan 
> >
> > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
> >
> > Reviewed-by: Dong Aisheng 
> > Signed-off-by: Peng Fan 
> > ---
> >  Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > index 26b7a88c2fea..906377acf2cd 100644
> > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> >  Required properties:
> >  ---
> >  - compatible : should be "fsl,-mu", the supported chips include
> > -   imx6sx, imx7s, imx8qxp, imx8qm.
> > +   imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> > +   imx8mp.
> > The "fsl,imx6sx-mu" compatible is seen as generic and should
> > be included together with SoC specific compatible.
> > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> > --
> > 2.16.4
> >
> >
> 
> Hi Peng,
> 
> The fsl,mu.yaml was already taken by Rob, so one or other patch will break by
> merge. I assume you should drop this change.

Yes. I'll rebase this patch based on Rob's tree. Thanks for reminding me.

Thanks,
Peng.

> 
> 
> Regards,
> Oleksij
> --
> Pengutronix e.K.   |
> |
> Steuerwalder Str. 21   |
> http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone:
> +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:
> +49-5121-206917- |

RE: [PATCH 2/4] firmware: imx: add resource management api

[Peng Fan]

> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
> 
> > From: Peng Fan 
> > Sent: Tuesday, June 2, 2020 12:51 PM
> > >
> > > > From: Peng Fan 
> > > > Sent: Monday, June 1, 2020 8:40 PM
> > > > >
> > > > > > From: Peng Fan 
> > > > > > Sent: Friday, April 24, 2020 9:12 AM
> > > > > > >
> > > > > > > > From: Peng Fan 
> > > > > > > > Sent: Thursday, April 23, 2020 6:57 PM
> > > > > > > > > > From: Peng Fan 
> > > > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM
> > > > > > > > > >
> > > > > > > > > > Add resource management API, when we have multiple
> > > > > > > > > > partition running together, resources not owned to
> > > > > > > > > > current partition should not be
> > > > > > > used.
> > > > > > > > > >
> > > > > > > > > > Reviewed-by: Leonard Crestez 
> > > > > > > > > > Signed-off-by: Peng Fan 
> > > > > > > > >
> > > > > > > > > Right now I'm still not quite understand if we really need 
> > > > > > > > > this.
> > > > > > > > > As current resource is bound to power domains, if it's
> > > > > > > > > not owned by one specific SW execution environment,
> > > > > > > > > power on will also
> > > > fail.
> > > > > > > > > Can you clarify if any exceptions?
> > > > > > > >
> > > > > > > > There will be lots of failures when boot Linux domu if no check.
> > > > > > > >
> > > > > > >
> > > > > > > What kind of features did you mean?
> > > > > > > Could you clarify a bit more? I'd like to understand this issue
> better.
> > > > > >
> > > > > > When supporting hypervisor with dual Linux running, 1st Linux
> > > > > > and the 2nd Linux will have their own dedicated resources.
> > > > > >
> > > > > > If no resource check, that means 1st/2nd Linux will register
> > > > > > all the resources, then both will see fail logs when register
> > > > > > resources not owned to
> > > > > itself.
> > > > > >
> > > > > > Same to partitioned m4 case.
> > > > > >
> > > > > > Would it be better without the failure log?
> > > > > >
> > > > >
> > > > > Is it power up failure?
> > > > > If yes, it's expected because we actually use power up to check
> > > > > if resources are owned by this partition. It functions the same
> > > > > as calling resource check API.
> > > > > That's current design.
> > > > >
> > > > > Or it's other failures? Log?
> > > > Sorry for long late reply.
> > > >
> > > > Part of my XEN DomU log, there are lots of failure log. I think
> > > > better not have such logs by add a resource own check.
> > >
> > > Those error logs are intended.
> > > Resource owner check actually behaves the same as power up.
> >
> > If resource is not owned, it will not register the power domain.
> >
> > Without resource own check, it will continue register the power domain
> > and hook it into genpd list.
> >
> 
> That's the intended behavior to save the resource owner checking as it's very
> time cost to send SCU cmd for each domain during booting which benefits
> nothing except not exposing them in genpd list.
> 
> > I prefer we not expose the power domain not owned to current partition
> > and keep the err msg for people to easy see where it goes wrong.
> 
> If we really want to to do, I wonder probably another better approach is
> trying to re-use the partition Information built by bootloader as uboot 
> already
> did that one time, not necessary to re-do It again for kernel as it's time 
> cost.
> e.g. introduce a resource partition property in dt and initialized and passed 
> by
> bootloarder to kernel to use later.

This will not work for hypervisor based VM runtime partition create and resource
assignment.

> Then we can still save those huge number of r

RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M

[Peng Fan]

> Subject: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M

I'll drop this patch for yaml update, since https://lkml.org/lkml/2020/6/1/370
includes imx8mq/mm/n/p.

Thanks,
Peng.

> 
> From: Peng Fan 
> 
> Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
> 
> Reviewed-by: Dong Aisheng 
> Signed-off-by: Peng Fan 
> ---
>  Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> index 26b7a88c2fea..906377acf2cd 100644
> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> @@ -18,7 +18,8 @@ Messaging Unit Device Node:
>  Required properties:
>  ---
>  - compatible :   should be "fsl,-mu", the supported chips include
> - imx6sx, imx7s, imx8qxp, imx8qm.
> + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> + imx8mp.
>   The "fsl,imx6sx-mu" compatible is seen as generic and should
>   be included together with SoC specific compatible.
>   There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> --
> 2.16.4

[PATCH V2 0/3] firmware: imx: fix/update cm4 and add resource check

[peng . fan]

From: Peng Fan 

V2:
 Add R-b tag
 Drop patch 3/4 from V1
 Add comments and update Copyright for patch 2/3
 keep code consistency in Patch 3/3

V1:
 https://patchwork.kernel.org/cover/11505045/

Fix cm40 power domain, update to add more cm4 resources
Add resource owner check, to not register if not owned by Linux.


Peng Fan (3):
  firmware: imx: scu-pd: fix cm40 power domain
  firmware: imx: add resource management api
  firmware: imx: scu-pd: add more cm4 resources

 drivers/firmware/imx/Makefile   |  2 +-
 drivers/firmware/imx/rm.c   | 45 
 drivers/firmware/imx/scu-pd.c   | 14 ++--
 include/linux/firmware/imx/sci.h|  1 +
 include/linux/firmware/imx/svc/rm.h | 69 +
 5 files changed, 128 insertions(+), 3 deletions(-)
 create mode 100644 drivers/firmware/imx/rm.c
 create mode 100644 include/linux/firmware/imx/svc/rm.h

-- 
2.16.4

[PATCH V2 2/3] firmware: imx: add resource management api

[peng . fan]

From: Peng Fan 

Add resource management API, when we have multiple
partition running together, resources not owned to current
partition should not be used.

Reviewed-by: Leonard Crestez 
Signed-off-by: Peng Fan 
---
 drivers/firmware/imx/Makefile   |  2 +-
 drivers/firmware/imx/rm.c   | 45 
 include/linux/firmware/imx/sci.h|  1 +
 include/linux/firmware/imx/svc/rm.h | 69 +
 4 files changed, 116 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/imx/rm.c
 create mode 100644 include/linux/firmware/imx/svc/rm.h

diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 08bc9ddfbdfb..17ea3613e142 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_IMX_DSP)  += imx-dsp.o
-obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o
+obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o rm.o
 obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c
new file mode 100644
index ..a12db6ff323b
--- /dev/null
+++ b/drivers/firmware/imx/rm.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ *
+ * File containing client-side RPC functions for the RM service. These
+ * function are ported to clients that communicate to the SC.
+ */
+
+#include 
+
+struct imx_sc_msg_rm_rsrc_owned {
+   struct imx_sc_rpc_msg hdr;
+   u16 resource;
+} __packed __aligned(4);
+
+/*
+ * This function check @resource is owned by current partition or not
+ *
+ * @param[in] ipc IPC handle
+ * @param[in] resourceresource the control is associated with
+ *
+ * @return Returns 0 for not owned and 1 for owned.
+ */
+bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
+{
+   struct imx_sc_msg_rm_rsrc_owned msg;
+   struct imx_sc_rpc_msg *hdr = &msg.hdr;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_RM;
+   hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
+   hdr->size = 2;
+
+   msg.resource = resource;
+
+   /*
+* SCU firmware only returns value 0 or 1
+* for resource owned check which means not owned or owned.
+* So it is always successful.
+*/
+   imx_scu_call_rpc(ipc, &msg, true);
+
+   return hdr->func;
+}
+EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
diff --git a/include/linux/firmware/imx/sci.h b/include/linux/firmware/imx/sci.h
index 3fa418a4ca67..3c459f54a88f 100644
--- a/include/linux/firmware/imx/sci.h
+++ b/include/linux/firmware/imx/sci.h
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 
 int imx_scu_enable_general_irq_channel(struct device *dev);
 int imx_scu_irq_register_notifier(struct notifier_block *nb);
diff --git a/include/linux/firmware/imx/svc/rm.h 
b/include/linux/firmware/imx/svc/rm.h
new file mode 100644
index ..9924216f3e45
--- /dev/null
+++ b/include/linux/firmware/imx/svc/rm.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2020 NXP
+ *
+ * Header file containing the public API for the System Controller (SC)
+ * Power Management (PM) function. This includes functions for power state
+ * control, clock control, reset control, and wake-up event control.
+ *
+ * RM_SVC (SVC) Resource Management Service
+ *
+ * Module for the Resource Management (RM) service.
+ */
+
+#ifndef _SC_RM_API_H
+#define _SC_RM_API_H
+
+#include 
+
+/*
+ * This type is used to indicate RPC RM function calls.
+ */
+enum imx_sc_rm_func {
+   IMX_SC_RM_FUNC_UNKNOWN = 0,
+   IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
+   IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
+   IMX_SC_RM_FUNC_PARTITION_FREE = 2,
+   IMX_SC_RM_FUNC_GET_DID = 26,
+   IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
+   IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
+   IMX_SC_RM_FUNC_GET_PARTITION = 5,
+   IMX_SC_RM_FUNC_SET_PARENT = 6,
+   IMX_SC_RM_FUNC_MOVE_ALL = 7,
+   IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
+   IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
+   IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
+   IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
+   IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
+   IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
+   IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
+   IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
+   IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
+   IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
+   IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
+   IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
+   IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
+   IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
+   IMX_SC_RM_FUNC_MEMREG_FREE = 18,
+   IMX_SC_RM_FUNC_FIND_MEMREG = 30,
+   IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
+   IMX_SC_RM_FUNC_SET_

[PATCH V2 3/3] firmware: imx: scu-pd: add more cm4 resources

[peng . fan]

From: Peng Fan 

Add more cm4 resources, then linux could use cm4's i2c/lpuart and
could kick cm4 core.

Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---
 drivers/firmware/imx/scu-pd.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index d1b313fa7b96..af3d6d9ead28 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -167,8 +167,18 @@ static const struct imx_sc_pd_range 
imx8qxp_scu_pd_ranges[] = {
{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
 
/* CM40 SS */
-   { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
-   { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
+   { "cm40-i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
+   { "cm40-intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
+   { "cm40-pid", IMX_SC_R_M4_0_PID0, 5, true, 0},
+   { "cm40-mu-a1", IMX_SC_R_M4_0_MU_1A, 1, false, 0},
+   { "cm40-lpuart", IMX_SC_R_M4_0_UART, 1, false, 0},
+
+   /* CM41 SS */
+   { "cm41-i2c", IMX_SC_R_M4_1_I2C, 1, false, 0 },
+   { "cm41-intmux", IMX_SC_R_M4_1_INTMUX, 1, false, 0 },
+   { "cm41-pid", IMX_SC_R_M4_1_PID0, 5, true, 0},
+   { "cm41-mu-a1", IMX_SC_R_M4_1_MU_1A, 1, false, 0},
+   { "cm41-lpuart", IMX_SC_R_M4_1_UART, 1, false, 0},
 };
 
 static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
-- 
2.16.4

[PATCH V2 1/3] firmware: imx: scu-pd: fix cm40 power domain

[peng . fan]

From: Peng Fan 

The postfix needs to be false. Alought compiler use 0 for postfix now,
and take start_from as 0, it is better we add explicit false to postfix.

Fixes: 705dcca91d0a("firmware: imx: scu-pd: add power domain for I2C and INTMUX 
in CM40 SS")
Signed-off-by: Peng Fan 
Reviewed-by: Dong Aisheng 
---
 drivers/firmware/imx/scu-pd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index fb5523aa16ee..d1b313fa7b96 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -167,8 +167,8 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] 
= {
{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
 
/* CM40 SS */
-   { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, 0 },
-   { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, 0 },
+   { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
+   { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
 };
 
 static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
-- 
2.16.4

[PATCH V4 0/2] imx8m: add mu support

[peng . fan]

From: Peng Fan 

V4:
 Drop patch 1/3, since https://lkml.org/lkml/2020/6/1/370 already
 has the yaml changes

V3:
 Add R-b tag
 Remove undocumented property

V2:
 Add dt-bindings
 Merge dts changes into one patch, since all is to add mu node

Add mu dt bindings
Add mu node
Add i.MX8MP mu root clk

Peng Fan (2):
  arm64: dts: imx8m: add mu node
  clk: imx8mp: add mu root clk

 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8 
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 
 drivers/clk/imx/clk-imx8mp.c  | 1 +
 5 files changed, 33 insertions(+)

-- 
2.16.4

[PATCH V4 1/2] arm64: dts: imx8m: add mu node

[peng . fan]

From: Peng Fan 

Add mu node to let A53 could communicate with M Core.

Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8 
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 
 4 files changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71101a1..d9e787ea246f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -775,6 +775,14 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MM_CLK_MU_ROOT>;
+   #mbox-cells = <2>;
+   };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mm-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a267d4..3dca1fb34ea3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -675,6 +675,14 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MN_CLK_MU_ROOT>;
+   #mbox-cells = <2>;
+   };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mn-usdhc", 
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 45e2c0a4e889..1bc14bb44d90 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -621,6 +621,14 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MP_CLK_MU_ROOT>;
+   #mbox-cells = <2>;
+   };
+
i2c5: i2c@30ad {
compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..3e762919d61f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -959,6 +959,14 @@
status = "disabled";
};
 
+   mu: mailbox@30aa {
+   compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
+   reg = <0x30aa 0x1>;
+   interrupts = ;
+   clocks = <&clk IMX8MQ_CLK_MU_ROOT>;
+   #mbox-cells = <2>;
+   };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mq-usdhc",
 "fsl,imx7d-usdhc";
-- 
2.16.4

[PATCH V4 2/2] clk: imx8mp: add mu root clk

[peng . fan]

From: Peng Fan 

Add mu root clk for mu mailbox usage.

Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---
 drivers/clk/imx/clk-imx8mp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b4d9db9d5bf1..ca747712400f 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -680,6 +680,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
hws[IMX8MP_CLK_I2C2_ROOT] = imx_clk_hw_gate4("i2c2_root_clk", "i2c2", 
ccm_base + 0x4180, 0);
hws[IMX8MP_CLK_I2C3_ROOT] = imx_clk_hw_gate4("i2c3_root_clk", "i2c3", 
ccm_base + 0x4190, 0);
hws[IMX8MP_CLK_I2C4_ROOT] = imx_clk_hw_gate4("i2c4_root_clk", "i2c4", 
ccm_base + 0x41a0, 0);
+   hws[IMX8MP_CLK_MU_ROOT] = imx_clk_hw_gate4("mu_root_clk", "ipg_root", 
ccm_base + 0x4210, 0);
hws[IMX8MP_CLK_OCOTP_ROOT] = imx_clk_hw_gate4("ocotp_root_clk", 
"ipg_root", ccm_base + 0x4220, 0);
hws[IMX8MP_CLK_PCIE_ROOT] = imx_clk_hw_gate4("pcie_root_clk", 
"pcie_aux", ccm_base + 0x4250, 0);
hws[IMX8MP_CLK_PWM1_ROOT] = imx_clk_hw_gate4("pwm1_root_clk", "pwm1", 
ccm_base + 0x4280, 0);
-- 
2.16.4

[PATCH] soc: imx: scu: use devm_kasprintf

[peng . fan]

From: Peng Fan 

Use devm_kasprintf to simplify code

Signed-off-by: Peng Fan 
---
 drivers/soc/imx/soc-imx-scu.c | 37 +++--
 1 file changed, 11 insertions(+), 26 deletions(-)

diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
index 20d37eaeb5f2..92448ca9a6f8 100644
--- a/drivers/soc/imx/soc-imx-scu.c
+++ b/drivers/soc/imx/soc-imx-scu.c
@@ -115,43 +115,28 @@ static int imx_scu_soc_probe(struct platform_device *pdev)
 
/* format soc_id value passed from SCU firmware */
val = id & 0x1f;
-   soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x", val);
+   soc_dev_attr->soc_id = devm_kasprintf(&pdev->dev, GFP_KERNEL, "0x%x", 
val);
if (!soc_dev_attr->soc_id)
return -ENOMEM;
 
/* format revision value passed from SCU firmware */
val = (id >> 5) & 0xf;
val = (((val >> 2) + 1) << 4) | (val & 0x3);
-   soc_dev_attr->revision = kasprintf(GFP_KERNEL,
-  "%d.%d",
-  (val >> 4) & 0xf,
-  val & 0xf);
-   if (!soc_dev_attr->revision) {
-   ret = -ENOMEM;
-   goto free_soc_id;
-   }
+   soc_dev_attr->revision = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%d.%d",
+   (val >> 4) & 0xf, val & 0xf);
+   if (!soc_dev_attr->revision)
+   return -ENOMEM;
 
-   soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX", uid);
-   if (!soc_dev_attr->serial_number) {
-   ret = -ENOMEM;
-   goto free_revision;
-   }
+   soc_dev_attr->serial_number = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+"%016llX", uid);
+   if (!soc_dev_attr->serial_number)
+   return -ENOMEM;
 
soc_dev = soc_device_register(soc_dev_attr);
-   if (IS_ERR(soc_dev)) {
-   ret = PTR_ERR(soc_dev);
-   goto free_serial_number;
-   }
+   if (IS_ERR(soc_dev))
+   return PTR_ERR(soc_dev);
 
return 0;
-
-free_serial_number:
-   kfree(soc_dev_attr->serial_number);
-free_revision:
-   kfree(soc_dev_attr->revision);
-free_soc_id:
-   kfree(soc_dev_attr->soc_id);
-   return ret;
 }
 
 static struct platform_driver imx_scu_soc_driver = {
-- 
2.16.4

[PATCH 1/3] arm64: dts: imx8qxp: add alias for lsio MU

[peng . fan]

From: Peng Fan 

Add lsio mu alias for all lsio MUs that could communicate with SCU,
imx_scu_enable_general_irq_channel will parse the alias to get
the mu resource id, if using other MU, not MU1, the `mu_resource_id`
is not what we expect, so add alias to fix this issue.

Signed-off-by: Peng Fan 
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index d1c3c98e4b39..33363c127478 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -30,7 +30,11 @@
mmc0 = &usdhc1;
mmc1 = &usdhc2;
mmc2 = &usdhc3;
+   mu0 = &lsio_mu0;
mu1 = &lsio_mu1;
+   mu2 = &lsio_mu2;
+   mu3 = &lsio_mu3;
+   mu4 = &lsio_mu4;
serial0 = &adma_lpuart0;
serial1 = &adma_lpuart1;
serial2 = &adma_lpuart2;
-- 
2.16.4

[PATCH 0/3] arm64: dts: imx8qxp: dtb aliases fix/update

[peng . fan]

From: Peng Fan 

Minor patchset to fix and update alias for i.MX8QXP

Peng Fan (3):
  arm64: dts: imx8qxp: add alias for lsio MU
  arm64: dts: imx8qxp: add i2c aliases
  arm64: dts: imx8qxp: Add ethernet alias

 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 10 ++
 1 file changed, 10 insertions(+)

-- 
2.16.4