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

2019-06-04 Thread Li Yang
On Mon, May 13, 2019 at 6:17 AM Rasmus Villemoes
 wrote:
>
> This small series consists of some small cleanups and simplifications
> of the QUICC engine driver, and introduces a new DT binding that makes
> it much easier to support other variants of the QUICC engine IP block
> that appears in the wild: There's no reason to expect in general that
> the number of valid SNUMs uniquely determines the set of such, so it's
> better to simply let the device tree specify the values (and,
> implicitly via the array length, also the count).
>
> Which tree should this go through?
>
> v3:
> - Move example from commit log into binding document (adapting to
>   MPC8360 which the existing example pertains to).
> - Add more review tags.
> - Fix minor style issue.
>
> v2:
> - Address comments from Christophe Leroy
> - Add his Reviewed-by to 1/6 and 3/6
> - Split DT binding update to separate patch as per
>   Documentation/devicetree/bindings/submitting-patches.txt
>
> Rasmus Villemoes (6):
>   soc/fsl/qe: qe.c: drop useless static qualifier
>   soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
>   soc/fsl/qe: qe.c: introduce qe_get_device_node helper
>   dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
>   soc/fsl/qe: qe.c: support fsl,qe-snums property
>   soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init

Series applied to soc/fsl for-next.  Thanks!

Regards,
Leo

>
>  .../devicetree/bindings/soc/fsl/cpm_qe/qe.txt |  13 +-
>  drivers/soc/fsl/qe/qe.c   | 163 +++---
>  2 files changed, 77 insertions(+), 99 deletions(-)
>
> --
> 2.20.1
>


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

2019-06-03 Thread Rasmus Villemoes
On 13/05/2019 13.14, Rasmus Villemoes wrote:
> This small series consists of some small cleanups and simplifications
> of the QUICC engine driver, and introduces a new DT binding that makes
> it much easier to support other variants of the QUICC engine IP block
> that appears in the wild: There's no reason to expect in general that
> the number of valid SNUMs uniquely determines the set of such, so it's
> better to simply let the device tree specify the values (and,
> implicitly via the array length, also the count).
> 
> Which tree should this go through?

Ping? These patches should be ready to go in, but I don't know who is
supposed to pick them up.

Thanks,
Rasmus


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

2019-06-03 Thread Leo Li


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

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

Regards,
Leo


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

2019-05-13 Thread Rasmus Villemoes
This small series consists of some small cleanups and simplifications
of the QUICC engine driver, and introduces a new DT binding that makes
it much easier to support other variants of the QUICC engine IP block
that appears in the wild: There's no reason to expect in general that
the number of valid SNUMs uniquely determines the set of such, so it's
better to simply let the device tree specify the values (and,
implicitly via the array length, also the count).

Which tree should this go through?

v3:
- Move example from commit log into binding document (adapting to
  MPC8360 which the existing example pertains to).
- Add more review tags.
- Fix minor style issue.

v2:
- Address comments from Christophe Leroy
- Add his Reviewed-by to 1/6 and 3/6
- Split DT binding update to separate patch as per
  Documentation/devicetree/bindings/submitting-patches.txt

Rasmus Villemoes (6):
  soc/fsl/qe: qe.c: drop useless static qualifier
  soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
  soc/fsl/qe: qe.c: introduce qe_get_device_node helper
  dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
  soc/fsl/qe: qe.c: support fsl,qe-snums property
  soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init

 .../devicetree/bindings/soc/fsl/cpm_qe/qe.txt |  13 +-
 drivers/soc/fsl/qe/qe.c   | 163 +++---
 2 files changed, 77 insertions(+), 99 deletions(-)

-- 
2.20.1