| Message ID | 20180802103425.3053-4-o.rempel@pengutronix.de (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | provide power off support for iMX6 with external PMIC | expand |
On Thu, Aug 02, 2018 at 12:34:22PM +0200, Oleksij Rempel wrote: > Export pm_power_off_prepare. It is needed to implement power off on > Freescale/NXP iMX6 based boards with external power management > integrated circuit (PMIC). I thought we'd got an ack for this from Raphael on a previous version or am I mistaken?
On 02.08.2018 12:44, Mark Brown wrote: > On Thu, Aug 02, 2018 at 12:34:22PM +0200, Oleksij Rempel wrote: >> Export pm_power_off_prepare. It is needed to implement power off on >> Freescale/NXP iMX6 based boards with external power management >> integrated circuit (PMIC). > > I thought we'd got an ack for this from Raphael on a previous version or > am I mistaken? > No, we got an: "Anyway, I have no particular problems with exporting pm_power_off_prepare via EXPORT_SYMBOL_GPL()." Should i see it as ACK?
On Thu, Aug 02, 2018 at 12:47:27PM +0200, Oleksij Rempel wrote: > On 02.08.2018 12:44, Mark Brown wrote: > > I thought we'd got an ack for this from Raphael on a previous version or > > am I mistaken? > No, we got an: > "Anyway, I have no particular problems with exporting > pm_power_off_prepare via EXPORT_SYMBOL_GPL()." > Should i see it as ACK? It's probably good enough.
On Thu, Aug 02, 2018 at 12:35:52PM +0100, Mark Brown wrote: > On Thu, Aug 02, 2018 at 12:47:27PM +0200, Oleksij Rempel wrote: > > On 02.08.2018 12:44, Mark Brown wrote: > > > > I thought we'd got an ack for this from Raphael on a previous version or > > > am I mistaken? > > > No, we got an: > > "Anyway, I have no particular problems with exporting > > pm_power_off_prepare via EXPORT_SYMBOL_GPL()." > > > Should i see it as ACK? Mark, Can you ACK on those two regulator patches, so that I can queue this series up on IMX tree? Shawn
On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > Can you ACK on those two regulator patches, so that I can queue this > series up on IMX tree? I was expecting to get a pull request with the precursor patches in it - the regulator driver seems to get a moderate amount of development so there's a reasonable risk of conflicts.
Hi Mark, On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > > > Can you ACK on those two regulator patches, so that I can queue this > > series up on IMX tree? > > I was expecting to get a pull request with the precursor patches in it - > the regulator driver seems to get a moderate amount of development so > there's a reasonable risk of conflicts. Are there any thing I can or should do?
On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > > > Can you ACK on those two regulator patches, so that I can queue this > > series up on IMX tree? > > I was expecting to get a pull request with the precursor patches in it - > the regulator driver seems to get a moderate amount of development so > there's a reasonable risk of conflicts. What about you create a stable topic branch for regulator patches and I pull it into IMX tree? Shawn
On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote: > On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > > I was expecting to get a pull request with the precursor patches in it - > > the regulator driver seems to get a moderate amount of development so > > there's a reasonable risk of conflicts. > What about you create a stable topic branch for regulator patches and I > pull it into IMX tree? Sure, I can send a pull request back but the first two patches in the series are ARM ones - are you OK with me just applying them and sending them in the pull request or do you want to apply them first?
On Mon, Sep 10, 2018 at 04:19:26PM +0100, Mark Brown wrote: > On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote: > > On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > > > > I was expecting to get a pull request with the precursor patches in it - > > > the regulator driver seems to get a moderate amount of development so > > > there's a reasonable risk of conflicts. > > > What about you create a stable topic branch for regulator patches and I > > pull it into IMX tree? > > Sure, I can send a pull request back but the first two patches in the > series are ARM ones - are you OK with me just applying them and sending > them in the pull request or do you want to apply them first? I just took another look at the series. It seems that there is no build-time dependency between regulator and platform patches. So I think we can handle the series like: - You apply patch #3, #4 and #5 on regulator tree; - I apply the reset on IMX tree. There shouldn't be any build or run time regression on either tree, and the feature that the series adds will be available when both trees get merged together on -next or Linus tree. @Oleksij Is my understanding above correct? Shawn
Hi Shawn, On 11.09.2018 03:53, Shawn Guo wrote: > On Mon, Sep 10, 2018 at 04:19:26PM +0100, Mark Brown wrote: >> On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote: >>> On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: >> >>>> I was expecting to get a pull request with the precursor patches in it - >>>> the regulator driver seems to get a moderate amount of development so >>>> there's a reasonable risk of conflicts. >> >>> What about you create a stable topic branch for regulator patches and I >>> pull it into IMX tree? >> >> Sure, I can send a pull request back but the first two patches in the >> series are ARM ones - are you OK with me just applying them and sending >> them in the pull request or do you want to apply them first? > > I just took another look at the series. It seems that there is no > build-time dependency between regulator and platform patches. So I > think we can handle the series like: > > - You apply patch #3, #4 and #5 on regulator tree; > - I apply the reset on IMX tree. > > There shouldn't be any build or run time regression on either tree, and > the feature that the series adds will be available when both trees get > merged together on -next or Linus tree. > > @Oleksij Is my understanding above correct? Yes.
On Tue, Sep 11, 2018 at 09:53:21AM +0800, Shawn Guo wrote: > There shouldn't be any build or run time regression on either tree, and > the feature that the series adds will be available when both trees get > merged together on -next or Linus tree. The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/pfuze100-poweroff for you to fetch changes up to c29daffa322ad36978cbce487f8ebcd9c3c3f7c0: regulator: pfuze100-regulator: provide pm_power_off_prepare handler (2018-09-11 16:15:57 +0100) ---------------------------------------------------------------- regulator: pfuze100: Power off support The pfuze100 has some innovative and creative power off support which requires some cross tree work to handle; this tag is the regualtor bits of that work. ---------------------------------------------------------------- Oleksij Rempel (3): kernel/reboot.c: export pm_power_off_prepare regulator: pfuze100: add fsl,pmic-stby-poweroff property regulator: pfuze100-regulator: provide pm_power_off_prepare handler .../devicetree/bindings/regulator/pfuze100.txt | 5 ++ drivers/regulator/pfuze100-regulator.c | 91 ++++++++++++++++++++++ kernel/reboot.c | 1 + 3 files changed, 97 insertions(+)
diff --git a/kernel/reboot.c b/kernel/reboot.c index e4ced883d8de..83810d726f3e 100644 --- a/kernel/reboot.c +++ b/kernel/reboot.c @@ -49,6 +49,7 @@ int reboot_force; */ void (*pm_power_off_prepare)(void); +EXPORT_SYMBOL_GPL(pm_power_off_prepare); /** * emergency_restart - reboot the system
Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+)