[v8,0/4] clk: ralink: make system controller a reset provider

Message

Sergio Paracuellos Jan. 10, 2022, 11:49 a.m. UTC

Hi all,

This patch series add minimal change to provide mt7621 resets properly
defining them in the 'mediatek,mt7621-sysc' node which is the system
controller of the SoC and is already providing clocks to the rest of
the world.

There is shared architecture code for all ralink platforms in 'reset.c'
file located in 'arch/mips/ralink' but the correct thing to do to align
hardware with software seems to define and add related reset code to the
already mainlined clock driver.

After this changes, we can get rid of the useless reset controller node
in the device tree and use system controller node instead where the property
'#reset-cells' has been added. Binding documentation for this nodeq has
been updated with the new property accordly.

This series also provide a bindings include header where all related
reset bits for the MT7621 SoC are defined.

Also, please take a look to this review [0] to understand better motivation
for this series.

Regarding the way of merging this:
 - I'd like patches 1 and 4 which are related going through staging tree.
 - The other two (patches 2 and 3) can perfectly go through the clock tree.

Thanks in advance for your feedback.

Changes in v8:
 - PATCH 3/4: with .of_xlate set, the driver needs to check whether id < nr_resets
   on its own.

Changes in v7:
 - PATCH 3/4: make use of '.of_xlate' callback as per Philipp v6 review.

Changes in v6:
 - Rebased on the top of last changes of staging-testing to properly
   update dtsi file (PATCH 4/4).
 - Send a copy of this to reset provider maintainer Philipp as per Stephen's sugestion
   to get changes added through the clk tree (Philipp, thanks in advance for reviewing
   this).

Changes in v5:
 - Move platform driver init process into 'arch_initcall' to be sure the
   rest of the world can get the resets available when needed (since PCIe
   controller driver has been moved from staging into 'drivers/pci/controller'
   is probed earlier and reset was not available so it was returning 
   -EPROBE_DEFER on firt try. Moving into 'arch_initcall' avoids the 'a bit
   anoying' PCI first failed log trace.

Changes in v4:
 - I sent wrong patch 3 accidentaly so now include the good version, sorry.

Changes in v3:
 - Collect Rob's Acked-by for patches 1 and 2. 
 - Rebase on the top of staging-next since there were already many
   changes there and PATCH 4 of the series didn't apply cleanly.

Changes in v2:
 - Address review comments of Dan Carpenter [1]:
 - Avoid 'inline' in function definition.
 - Return proper error codes (-EINVAL) instead of '-1'.
 - Make use of 'devm_kzalloc' instead of 'kzalloc'.

[0]: https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[e-mail]/

Best regards,
   Sergio Paracuellos

Sergio Paracuellos (4):
  dt-bindings: reset: add dt binding header for Mediatek MT7621 resets
  dt-bindings: clock: mediatek,mt7621-sysc: add '#reset-cells' property
  clk: ralink: make system controller node a reset provider
  staging: mt7621-dts: align resets with binding documentation

 .../bindings/clock/mediatek,mt7621-sysc.yaml  | 12 +++
 drivers/clk/ralink/clk-mt7621.c               | 92 ++++++++++++++++++-
 drivers/staging/mt7621-dts/mt7621.dtsi        | 21 ++---
 include/dt-bindings/reset/mt7621-reset.h      | 37 ++++++++
 4 files changed, 149 insertions(+), 13 deletions(-)
 create mode 100644 include/dt-bindings/reset/mt7621-reset.h

Comments

Arınç ÜNAL Jan. 19, 2022, 1:27 p.m. UTC | #1

This series fixes the SPI & MDIO probing issues we were having with our 
mt7621 board.

Tested-by: Arınç ÜNAL <[e-mail]>

Cheers.
Arınç

Sergio Paracuellos Jan. 19, 2022, 1:55 p.m. UTC | #2

On Wed, Jan 19, 2022 at 2:27 PM Arınç ÜNAL <[e-mail]> wrote:
>
> This series fixes the SPI & MDIO probing issues we were having with our
> mt7621 board.
>
> Tested-by: Arınç ÜNAL <[e-mail]>

Thanks for testing this!

Best regards,
    Sergio Paracuellos
>
> Cheers.
> Arınç
>

Greg Kroah-Hartman Jan. 26, 2022, 12:06 p.m. UTC | #3

On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> Hi all,
> 
> This patch series add minimal change to provide mt7621 resets properly
> defining them in the 'mediatek,mt7621-sysc' node which is the system
> controller of the SoC and is already providing clocks to the rest of
> the world.
> 
> There is shared architecture code for all ralink platforms in 'reset.c'
> file located in 'arch/mips/ralink' but the correct thing to do to align
> hardware with software seems to define and add related reset code to the
> already mainlined clock driver.
> 
> After this changes, we can get rid of the useless reset controller node
> in the device tree and use system controller node instead where the property
> '#reset-cells' has been added. Binding documentation for this nodeq has
> been updated with the new property accordly.
> 
> This series also provide a bindings include header where all related
> reset bits for the MT7621 SoC are defined.
> 
> Also, please take a look to this review [0] to understand better motivation
> for this series.
> 
> Regarding the way of merging this:
>  - I'd like patches 1 and 4 which are related going through staging tree.

Patches 1 and 4 now in the staging tree, thanks.

greg k-h

Sergio Paracuellos Jan. 26, 2022, 12:08 p.m. UTC | #4

On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
>
> On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > Hi all,
> >
> > This patch series add minimal change to provide mt7621 resets properly
> > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > controller of the SoC and is already providing clocks to the rest of
> > the world.
> >
> > There is shared architecture code for all ralink platforms in 'reset.c'
> > file located in 'arch/mips/ralink' but the correct thing to do to align
> > hardware with software seems to define and add related reset code to the
> > already mainlined clock driver.
> >
> > After this changes, we can get rid of the useless reset controller node
> > in the device tree and use system controller node instead where the property
> > '#reset-cells' has been added. Binding documentation for this nodeq has
> > been updated with the new property accordly.
> >
> > This series also provide a bindings include header where all related
> > reset bits for the MT7621 SoC are defined.
> >
> > Also, please take a look to this review [0] to understand better motivation
> > for this series.
> >
> > Regarding the way of merging this:
> >  - I'd like patches 1 and 4 which are related going through staging tree.
>
> Patches 1 and 4 now in the staging tree, thanks.

Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
also a dependency... Can we get all of them through the same tree,
then? I am ok with both CLK or staging trees.

Thanks,
    Sergio Paracuellos
>
> greg k-h
>

Greg Kroah-Hartman Jan. 26, 2022, 12:14 p.m. UTC | #5

On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> >
> > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > Hi all,
> > >
> > > This patch series add minimal change to provide mt7621 resets properly
> > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > controller of the SoC and is already providing clocks to the rest of
> > > the world.
> > >
> > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > hardware with software seems to define and add related reset code to the
> > > already mainlined clock driver.
> > >
> > > After this changes, we can get rid of the useless reset controller node
> > > in the device tree and use system controller node instead where the property
> > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > been updated with the new property accordly.
> > >
> > > This series also provide a bindings include header where all related
> > > reset bits for the MT7621 SoC are defined.
> > >
> > > Also, please take a look to this review [0] to understand better motivation
> > > for this series.
> > >
> > > Regarding the way of merging this:
> > >  - I'd like patches 1 and 4 which are related going through staging tree.
> >
> > Patches 1 and 4 now in the staging tree, thanks.
> 
> Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> also a dependency... Can we get all of them through the same tree,
> then? I am ok with both CLK or staging trees.

That's fine with me if they all go through the CLK tree, but there will
be a merge issue that I already fixed up in my tree.  If you want me to
drop them, just let me know.

thanks,

greg k-h

Sergio Paracuellos Jan. 26, 2022, 12:45 p.m. UTC | #6

On Wed, Jan 26, 2022 at 1:14 PM Greg KH <[e-mail]> wrote:
>
> On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> > On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> > >
> > > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > > Hi all,
> > > >
> > > > This patch series add minimal change to provide mt7621 resets properly
> > > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > > controller of the SoC and is already providing clocks to the rest of
> > > > the world.
> > > >
> > > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > > hardware with software seems to define and add related reset code to the
> > > > already mainlined clock driver.
> > > >
> > > > After this changes, we can get rid of the useless reset controller node
> > > > in the device tree and use system controller node instead where the property
> > > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > > been updated with the new property accordly.
> > > >
> > > > This series also provide a bindings include header where all related
> > > > reset bits for the MT7621 SoC are defined.
> > > >
> > > > Also, please take a look to this review [0] to understand better motivation
> > > > for this series.
> > > >
> > > > Regarding the way of merging this:
> > > >  - I'd like patches 1 and 4 which are related going through staging tree.
> > >
> > > Patches 1 and 4 now in the staging tree, thanks.
> >
> > Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> > also a dependency... Can we get all of them through the same tree,
> > then? I am ok with both CLK or staging trees.
>
> That's fine with me if they all go through the CLK tree, but there will
> be a merge issue that I already fixed up in my tree.  If you want me to
> drop them, just let me know.

Stephen, what do you prefer? Is it better all going through staging-tree then?

Best regards,
    Sergio Paracuellos
>
> thanks,
>
> greg k-h

Stephen Boyd Feb. 5, 2022, 2:55 a.m. UTC | #7

Quoting Sergio Paracuellos (2022-01-26 04:45:31)
> On Wed, Jan 26, 2022 at 1:14 PM Greg KH <[e-mail]> wrote:
> >
> > On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> > > On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> > > >
> > > > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > > > Hi all,
> > > > >
> > > > > This patch series add minimal change to provide mt7621 resets properly
> > > > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > > > controller of the SoC and is already providing clocks to the rest of
> > > > > the world.
> > > > >
> > > > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > > > hardware with software seems to define and add related reset code to the
> > > > > already mainlined clock driver.
> > > > >
> > > > > After this changes, we can get rid of the useless reset controller node
> > > > > in the device tree and use system controller node instead where the property
> > > > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > > > been updated with the new property accordly.
> > > > >
> > > > > This series also provide a bindings include header where all related
> > > > > reset bits for the MT7621 SoC are defined.
> > > > >
> > > > > Also, please take a look to this review [0] to understand better motivation
> > > > > for this series.
> > > > >
> > > > > Regarding the way of merging this:
> > > > >  - I'd like patches 1 and 4 which are related going through staging tree.
> > > >
> > > > Patches 1 and 4 now in the staging tree, thanks.
> > >
> > > Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> > > also a dependency... Can we get all of them through the same tree,
> > > then? I am ok with both CLK or staging trees.
> >
> > That's fine with me if they all go through the CLK tree, but there will
> > be a merge issue that I already fixed up in my tree.  If you want me to
> > drop them, just let me know.
> 
> Stephen, what do you prefer? Is it better all going through staging-tree then?
> 

Sure take them through staging tree.

Acked-by: Stephen Boyd <[e-mail]>

Sergio Paracuellos Feb. 5, 2022, 7:31 a.m. UTC | #8

On Sat, Feb 5, 2022 at 3:55 AM Stephen Boyd <[e-mail]> wrote:
>
> Quoting Sergio Paracuellos (2022-01-26 04:45:31)
> > On Wed, Jan 26, 2022 at 1:14 PM Greg KH <[e-mail]> wrote:
> > >
> > > On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> > > > On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> > > > >
> > > > > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > This patch series add minimal change to provide mt7621 resets properly
> > > > > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > > > > controller of the SoC and is already providing clocks to the rest of
> > > > > > the world.
> > > > > >
> > > > > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > > > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > > > > hardware with software seems to define and add related reset code to the
> > > > > > already mainlined clock driver.
> > > > > >
> > > > > > After this changes, we can get rid of the useless reset controller node
> > > > > > in the device tree and use system controller node instead where the property
> > > > > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > > > > been updated with the new property accordly.
> > > > > >
> > > > > > This series also provide a bindings include header where all related
> > > > > > reset bits for the MT7621 SoC are defined.
> > > > > >
> > > > > > Also, please take a look to this review [0] to understand better motivation
> > > > > > for this series.
> > > > > >
> > > > > > Regarding the way of merging this:
> > > > > >  - I'd like patches 1 and 4 which are related going through staging tree.
> > > > >
> > > > > Patches 1 and 4 now in the staging tree, thanks.
> > > >
> > > > Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> > > > also a dependency... Can we get all of them through the same tree,
> > > > then? I am ok with both CLK or staging trees.
> > >
> > > That's fine with me if they all go through the CLK tree, but there will
> > > be a merge issue that I already fixed up in my tree.  If you want me to
> > > drop them, just let me know.
> >
> > Stephen, what do you prefer? Is it better all going through staging-tree then?
> >
>
> Sure take them through staging tree.
>
> Acked-by: Stephen Boyd <[e-mail]>

Thanks, Stephen.

Greg, can you please take remaining patches 2 and 3 through your tree, then?

Thanks in advance for your time.

Best regards,
    Sergio Paracuellos

Sergio Paracuellos Feb. 10, 2022, 6:44 a.m. UTC | #9

Hi Greg,

On Sat, Feb 5, 2022 at 8:31 AM Sergio Paracuellos
<[e-mail]> wrote:
>
> On Sat, Feb 5, 2022 at 3:55 AM Stephen Boyd <[e-mail]> wrote:
> >
> > Quoting Sergio Paracuellos (2022-01-26 04:45:31)
> > > On Wed, Jan 26, 2022 at 1:14 PM Greg KH <[e-mail]> wrote:
> > > >
> > > > On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> > > > > On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> > > > > >
> > > > > > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > This patch series add minimal change to provide mt7621 resets properly
> > > > > > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > > > > > controller of the SoC and is already providing clocks to the rest of
> > > > > > > the world.
> > > > > > >
> > > > > > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > > > > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > > > > > hardware with software seems to define and add related reset code to the
> > > > > > > already mainlined clock driver.
> > > > > > >
> > > > > > > After this changes, we can get rid of the useless reset controller node
> > > > > > > in the device tree and use system controller node instead where the property
> > > > > > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > > > > > been updated with the new property accordly.
> > > > > > >
> > > > > > > This series also provide a bindings include header where all related
> > > > > > > reset bits for the MT7621 SoC are defined.
> > > > > > >
> > > > > > > Also, please take a look to this review [0] to understand better motivation
> > > > > > > for this series.
> > > > > > >
> > > > > > > Regarding the way of merging this:
> > > > > > >  - I'd like patches 1 and 4 which are related going through staging tree.
> > > > > >
> > > > > > Patches 1 and 4 now in the staging tree, thanks.
> > > > >
> > > > > Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> > > > > also a dependency... Can we get all of them through the same tree,
> > > > > then? I am ok with both CLK or staging trees.
> > > >
> > > > That's fine with me if they all go through the CLK tree, but there will
> > > > be a merge issue that I already fixed up in my tree.  If you want me to
> > > > drop them, just let me know.
> > >
> > > Stephen, what do you prefer? Is it better all going through staging-tree then?
> > >
> >
> > Sure take them through staging tree.
> >
> > Acked-by: Stephen Boyd <[e-mail]>
>
> Thanks, Stephen.
>
> Greg, can you please take remaining patches 2 and 3 through your tree, then?
>
> Thanks in advance for your time.

Please, let me know if you prefer me to resend the remaining two
patches with tags added to make this easier for you.

Best regards,
    Sergio Paracuellos

>
> Best regards,
>     Sergio Paracuellos

Greg Kroah-Hartman Feb. 10, 2022, 6:55 a.m. UTC | #10

On Thu, Feb 10, 2022 at 07:44:33AM +0100, Sergio Paracuellos wrote:
> Hi Greg,
> 
> On Sat, Feb 5, 2022 at 8:31 AM Sergio Paracuellos
> <[e-mail]> wrote:
> >
> > On Sat, Feb 5, 2022 at 3:55 AM Stephen Boyd <[e-mail]> wrote:
> > >
> > > Quoting Sergio Paracuellos (2022-01-26 04:45:31)
> > > > On Wed, Jan 26, 2022 at 1:14 PM Greg KH <[e-mail]> wrote:
> > > > >
> > > > > On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> > > > > > On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > This patch series add minimal change to provide mt7621 resets properly
> > > > > > > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > > > > > > controller of the SoC and is already providing clocks to the rest of
> > > > > > > > the world.
> > > > > > > >
> > > > > > > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > > > > > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > > > > > > hardware with software seems to define and add related reset code to the
> > > > > > > > already mainlined clock driver.
> > > > > > > >
> > > > > > > > After this changes, we can get rid of the useless reset controller node
> > > > > > > > in the device tree and use system controller node instead where the property
> > > > > > > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > > > > > > been updated with the new property accordly.
> > > > > > > >
> > > > > > > > This series also provide a bindings include header where all related
> > > > > > > > reset bits for the MT7621 SoC are defined.
> > > > > > > >
> > > > > > > > Also, please take a look to this review [0] to understand better motivation
> > > > > > > > for this series.
> > > > > > > >
> > > > > > > > Regarding the way of merging this:
> > > > > > > >  - I'd like patches 1 and 4 which are related going through staging tree.
> > > > > > >
> > > > > > > Patches 1 and 4 now in the staging tree, thanks.
> > > > > >
> > > > > > Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> > > > > > also a dependency... Can we get all of them through the same tree,
> > > > > > then? I am ok with both CLK or staging trees.
> > > > >
> > > > > That's fine with me if they all go through the CLK tree, but there will
> > > > > be a merge issue that I already fixed up in my tree.  If you want me to
> > > > > drop them, just let me know.
> > > >
> > > > Stephen, what do you prefer? Is it better all going through staging-tree then?
> > > >
> > >
> > > Sure take them through staging tree.
> > >
> > > Acked-by: Stephen Boyd <[e-mail]>
> >
> > Thanks, Stephen.
> >
> > Greg, can you please take remaining patches 2 and 3 through your tree, then?
> >
> > Thanks in advance for your time.
> 
> Please, let me know if you prefer me to resend the remaining two
> patches with tags added to make this easier for you.

Please do so, as I can't seem to dig up the remaining ones...

thanks,

greg k-h

Sergio Paracuellos Feb. 10, 2022, 9:52 a.m. UTC | #11

On Thu, Feb 10, 2022 at 7:55 AM Greg KH <[e-mail]> wrote:
>
> On Thu, Feb 10, 2022 at 07:44:33AM +0100, Sergio Paracuellos wrote:
> > Hi Greg,
> >
> > On Sat, Feb 5, 2022 at 8:31 AM Sergio Paracuellos
> > <[e-mail]> wrote:
> > >
> > > On Sat, Feb 5, 2022 at 3:55 AM Stephen Boyd <[e-mail]> wrote:
> > > >
> > > > Quoting Sergio Paracuellos (2022-01-26 04:45:31)
> > > > > On Wed, Jan 26, 2022 at 1:14 PM Greg KH <[e-mail]> wrote:
> > > > > >
> > > > > > On Wed, Jan 26, 2022 at 01:08:52PM +0100, Sergio Paracuellos wrote:
> > > > > > > On Wed, Jan 26, 2022 at 1:06 PM Greg KH <[e-mail]> wrote:
> > > > > > > >
> > > > > > > > On Mon, Jan 10, 2022 at 12:49:26PM +0100, Sergio Paracuellos wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > This patch series add minimal change to provide mt7621 resets properly
> > > > > > > > > defining them in the 'mediatek,mt7621-sysc' node which is the system
> > > > > > > > > controller of the SoC and is already providing clocks to the rest of
> > > > > > > > > the world.
> > > > > > > > >
> > > > > > > > > There is shared architecture code for all ralink platforms in 'reset.c'
> > > > > > > > > file located in 'arch/mips/ralink' but the correct thing to do to align
> > > > > > > > > hardware with software seems to define and add related reset code to the
> > > > > > > > > already mainlined clock driver.
> > > > > > > > >
> > > > > > > > > After this changes, we can get rid of the useless reset controller node
> > > > > > > > > in the device tree and use system controller node instead where the property
> > > > > > > > > '#reset-cells' has been added. Binding documentation for this nodeq has
> > > > > > > > > been updated with the new property accordly.
> > > > > > > > >
> > > > > > > > > This series also provide a bindings include header where all related
> > > > > > > > > reset bits for the MT7621 SoC are defined.
> > > > > > > > >
> > > > > > > > > Also, please take a look to this review [0] to understand better motivation
> > > > > > > > > for this series.
> > > > > > > > >
> > > > > > > > > Regarding the way of merging this:
> > > > > > > > >  - I'd like patches 1 and 4 which are related going through staging tree.
> > > > > > > >
> > > > > > > > Patches 1 and 4 now in the staging tree, thanks.
> > > > > > >
> > > > > > > Stephen wanted all to go through the CLK tree since PATCH 3 and 1 were
> > > > > > > also a dependency... Can we get all of them through the same tree,
> > > > > > > then? I am ok with both CLK or staging trees.
> > > > > >
> > > > > > That's fine with me if they all go through the CLK tree, but there will
> > > > > > be a merge issue that I already fixed up in my tree.  If you want me to
> > > > > > drop them, just let me know.
> > > > >
> > > > > Stephen, what do you prefer? Is it better all going through staging-tree then?
> > > > >
> > > >
> > > > Sure take them through staging tree.
> > > >
> > > > Acked-by: Stephen Boyd <[e-mail]>
> > >
> > > Thanks, Stephen.
> > >
> > > Greg, can you please take remaining patches 2 and 3 through your tree, then?
> > >
> > > Thanks in advance for your time.
> >
> > Please, let me know if you prefer me to resend the remaining two
> > patches with tags added to make this easier for you.
>
> Please do so, as I can't seem to dig up the remaining ones...

Ok, done. Please check:
https://lore.kernel.org/linux-staging/[e-mail]/T/#t

Best regards,
    Sergio Paracuellos

>
> thanks,
>
> greg k-h