Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1611121 > unrolled thread

[GIT PULL] mfd: exynos-lpass: Pinctrl dependency

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [GIT PULL] mfd: exynos-lpass: Pinctrl dependency Krzysztof Kozlowski <krzk@kernel.org> - 2017-03-28 17:50 +0200
    Re: [GIT PULL] mfd: exynos-lpass: Pinctrl dependency Lee Jones <lee.jones@linaro.org> - 2017-04-03 12:20 +0200
      Re: [GIT PULL] mfd: exynos-lpass: Pinctrl dependency Krzysztof Kozlowski <krzk@kernel.org> - 2017-04-04 10:30 +0200
        Re: [GIT PULL] mfd: exynos-lpass: Pinctrl dependency Lee Jones <lee.jones@linaro.org> - 2017-04-04 12:00 +0200
          Re: [GIT PULL] mfd: exynos-lpass: Pinctrl dependency Krzysztof Kozlowski <krzk@kernel.org> - 2017-04-04 12:10 +0200

#1611121 — [GIT PULL] mfd: exynos-lpass: Pinctrl dependency

Hi Lee,


This is dependency for mfd/exynos-lpass driver changes from Marek Szyprowski.
That's a material for v4.12 and I will be pushing this later to Linus Walleij.


Best regards,
Krzysztof



The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git tags/samsung-pinctrl-retention-4.12

for you to fetch changes up to e1d7eb0c8fc9c33ef60ac31172fb0fbb78c24271:

  pinctrl: samsung: Add support for pad retention control for Exynos5433 SoCs (2017-03-23 21:07:02 +0200)

----------------------------------------------------------------
Add retention control to Exynos5433 pinctrl driver, necessary for proper
handling of runtime Power Management of Exynos Audio SubSystem and effectively
allowing to power down the domain.

----------------------------------------------------------------
Marek Szyprowski (2):
      pinctrl: samsung: Ensure that pad retention is disabled on driver init
      pinctrl: samsung: Add support for pad retention control for Exynos5433 SoCs

 drivers/pinctrl/samsung/pinctrl-exynos.c | 63 ++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

[toc] | [next] | [standalone]

#1615062

On Tue, 28 Mar 2017, Krzysztof Kozlowski wrote:

> 
> Hi Lee,
> 
> 
> This is dependency for mfd/exynos-lpass driver changes from Marek Szyprowski.
> That's a material for v4.12 and I will be pushing this later to Linus Walleij.

This does not work, and *may* still break.

The only way to guarantee the order of the patches is to have them
*all* as part of the pull-request.  Not just some of them.

> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> 
>   Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git tags/samsung-pinctrl-retention-4.12
> 
> for you to fetch changes up to e1d7eb0c8fc9c33ef60ac31172fb0fbb78c24271:
> 
>   pinctrl: samsung: Add support for pad retention control for Exynos5433 SoCs (2017-03-23 21:07:02 +0200)
> 
> ----------------------------------------------------------------
> Add retention control to Exynos5433 pinctrl driver, necessary for proper
> handling of runtime Power Management of Exynos Audio SubSystem and effectively
> allowing to power down the domain.
> 
> ----------------------------------------------------------------
> Marek Szyprowski (2):
>       pinctrl: samsung: Ensure that pad retention is disabled on driver init
>       pinctrl: samsung: Add support for pad retention control for Exynos5433 SoCs
> 
>  drivers/pinctrl/samsung/pinctrl-exynos.c | 63 ++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [prev] | [next] | [standalone]

#1615775

On Mon, Apr 3, 2017 at 12:18 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 28 Mar 2017, Krzysztof Kozlowski wrote:
>
>>
>> Hi Lee,
>>
>>
>> This is dependency for mfd/exynos-lpass driver changes from Marek Szyprowski.
>> That's a material for v4.12 and I will be pushing this later to Linus Walleij.
>
> This does not work, and *may* still break.
>
> The only way to guarantee the order of the patches is to have them
> *all* as part of the pull-request.  Not just some of them.

What do you mean exactly? If these two patches come through my tree
first, then everything will work fine because they do not break any
other stuff.

If you pull it and apply the rest on top, then it should also work
without problems because your history will contain everything needed
in proper order.

In both cases bisectability is preserved. Did I missed something?

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1615843

On Tue, 04 Apr 2017, Krzysztof Kozlowski wrote:

> On Mon, Apr 3, 2017 at 12:18 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Tue, 28 Mar 2017, Krzysztof Kozlowski wrote:
> >
> >>
> >> Hi Lee,
> >>
> >>
> >> This is dependency for mfd/exynos-lpass driver changes from Marek Szyprowski.
> >> That's a material for v4.12 and I will be pushing this later to Linus Walleij.
> >
> > This does not work, and *may* still break.
> >
> > The only way to guarantee the order of the patches is to have them
> > *all* as part of the pull-request.  Not just some of them.
> 
> What do you mean exactly? If these two patches come through my tree
> first, then everything will work fine because they do not break any
> other stuff.
> 
> If you pull it and apply the rest on top, then it should also work
> without problems because your history will contain everything needed
> in proper order.
> 
> In both cases bisectability is preserved. Did I missed something?

Okay, so you're suggesting that I rebase MFD *on-top* of your PR.  That
does work for me because I insist on being able to re-work my tree at
any time.  However, be aware that some Maintainers do not work this
way, thus *normally* you will have to send PR containing all of the
dependant patches.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [prev] | [next] | [standalone]

#1615854

On Tue, Apr 04, 2017 at 10:50:54AM +0100, Lee Jones wrote:
> On Tue, 04 Apr 2017, Krzysztof Kozlowski wrote:
> 
> > On Mon, Apr 3, 2017 at 12:18 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > > On Tue, 28 Mar 2017, Krzysztof Kozlowski wrote:
> > >
> > >>
> > >> Hi Lee,
> > >>
> > >>
> > >> This is dependency for mfd/exynos-lpass driver changes from Marek Szyprowski.
> > >> That's a material for v4.12 and I will be pushing this later to Linus Walleij.
> > >
> > > This does not work, and *may* still break.
> > >
> > > The only way to guarantee the order of the patches is to have them
> > > *all* as part of the pull-request.  Not just some of them.
> > 
> > What do you mean exactly? If these two patches come through my tree
> > first, then everything will work fine because they do not break any
> > other stuff.
> > 
> > If you pull it and apply the rest on top, then it should also work
> > without problems because your history will contain everything needed
> > in proper order.
> > 
> > In both cases bisectability is preserved. Did I missed something?
> 
> Okay, so you're suggesting that I rebase MFD *on-top* of your PR.  That
> does work for me because I insist on being able to re-work my tree at
> any time.  However, be aware that some Maintainers do not work this
> way, thus *normally* you will have to send PR containing all of the
> dependant patches.

You could either rebased on top of this PR or merge it before applying
rest of patches. It does not matter because in both cases all dependant
patches will be after the dependency. Also in both cases you will be
sending them in your PR.

You can then rebase your stuff as well, keeping only the external
commits untouced and merged.

Really, that does not differ from all your stable immutable branches you
have been providing for other folks.


Best regards,
Krzysztof

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web