Re: [PATCH v1] i2c: tegra: Remove suspend-resume

> Applied to for-next, thanks! I removed the stable tag, though. I am not 100% sure if there are not any side-effects for other users. If you still think it should go to stable, please mention this patch to stable@ after it was applied to linus tree. Maybe with a word or two about regression

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

> Applied to for-next, thanks! I removed the stable tag, though. I am not 100% sure if there are not any side-effects for other users. If you still think it should go to stable, please mention this patch to stable@ after it was applied to linus tree. Maybe with a word or two about regression

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

On Mon, May 14, 2018 at 12:13:47AM +0300, Dmitry Osipenko wrote: > Nothing prevents I2C clients to access I2C while Tegra's driver is being > suspended, this results in -EBUSY error returned to the clients and that > may have unfortunate consequences. In particular this causes problems > for the

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

On Mon, May 14, 2018 at 12:13:47AM +0300, Dmitry Osipenko wrote: > Nothing prevents I2C clients to access I2C while Tegra's driver is being > suspended, this results in -EBUSY error returned to the clients and that > may have unfortunate consequences. In particular this causes problems > for the

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

On Tuesday 29 May 2018 11:36 PM, Wolfram Sang wrote: Our I2C driver is based on the interrupt. So we have converted the suspend/resume to suspend_noirq and reseume_noirq so that we will not allow the transfer when system interrupt disabled in downstream

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

On Tuesday 29 May 2018 11:36 PM, Wolfram Sang wrote: Our I2C driver is based on the interrupt. So we have converted the suspend/resume to suspend_noirq and reseume_noirq so that we will not allow the transfer when system interrupt disabled in downstream

Re: [PATCH] mtd: atmel-quadspi: add suspend/resume hooks

On Wed, 23 May 2018 19:08:48 +0300 Claudiu Beznea wrote: > Implement suspend/resume hooks. > > Signed-off-by: Claudiu Beznea > --- > drivers/mtd/spi-nor/atmel-quadspi.c | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/mtd/spi-

Re: [PATCH] mtd: atmel-quadspi: add suspend/resume hooks

On Wed, 23 May 2018 19:08:48 +0300 Claudiu Beznea wrote: > Implement suspend/resume hooks. > > Signed-off-by: Claudiu Beznea > --- > drivers/mtd/spi-nor/atmel-quadspi.c | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/mtd/spi-

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

> > Our I2C driver is based on the interrupt. So we have converted the > > suspend/resume to suspend_noirq and reseume_noirq so that we will not allow > > the > > transfer when system interrupt disabled in downstream. > >   SET_NOIRQ_SYSTEM_

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

> > Our I2C driver is based on the interrupt. So we have converted the > > suspend/resume to suspend_noirq and reseume_noirq so that we will not allow > > the > > transfer when system interrupt disabled in downstream. > >   SET_NOIRQ_SYSTEM_

[PATCH 4.14 244/496] can: m_can: select pinctrl state in each suspend/resume function

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Bich HEMON <bich.he...@st.com> [ Upstream commit c9b3bce18da4a0aebc27853052dea39aa64b7d75 ] Make sure to apply the correct pin state in suspend/resume callbacks. Putting pins in sleep

[PATCH 4.14 244/496] can: m_can: select pinctrl state in each suspend/resume function

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Bich HEMON [ Upstream commit c9b3bce18da4a0aebc27853052dea39aa64b7d75 ] Make sure to apply the correct pin state in suspend/resume callbacks. Putting pins in sleep state saves power. Signed

[PATCH 4.16 082/272] dmaengine: rcar-dmac: Fix too early/late system suspend/resume callbacks

4.16-stable review patch. If anyone has any objections, please let me know. -- From: Geert Uytterhoeven [ Upstream commit 73dcc666d6bd0db56cd556010f93d8f04c1cc70c ] If serial console wake-up is enabled ("echo enabled > /sys/.../ttySC0/power/wakeup"),

[PATCH 4.16 082/272] dmaengine: rcar-dmac: Fix too early/late system suspend/resume callbacks

4.16-stable review patch. If anyone has any objections, please let me know. -- From: Geert Uytterhoeven [ Upstream commit 73dcc666d6bd0db56cd556010f93d8f04c1cc70c ] If serial console wake-up is enabled ("echo enabled > /sys/.../ttySC0/power/wakeup"), and any serial input is

[PATCH 4.9 26/96] usb: dwc3: omap: dont miss events during suspend/resume

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Roger Quadros <rog...@ti.com> [ Upstream commit c49f63055e252810e5d6c83a4943b18db16b3cd8 ] The USB cable state can change during suspend/resume so be sure to check and update the extcon

[PATCH 4.9 26/96] usb: dwc3: omap: dont miss events during suspend/resume

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Roger Quadros [ Upstream commit c49f63055e252810e5d6c83a4943b18db16b3cd8 ] The USB cable state can change during suspend/resume so be sure to check and update the extcon state. Signed-off

[PATCH 4.14 056/165] usb: dwc3: omap: dont miss events during suspend/resume

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Roger Quadros <rog...@ti.com> [ Upstream commit c49f63055e252810e5d6c83a4943b18db16b3cd8 ] The USB cable state can change during suspend/resume so be sure to check and update the extcon

[PATCH 4.14 056/165] usb: dwc3: omap: dont miss events during suspend/resume

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Roger Quadros [ Upstream commit c49f63055e252810e5d6c83a4943b18db16b3cd8 ] The USB cable state can change during suspend/resume so be sure to check and update the extcon state. Signed-off

[PATCH] mtd: atmel-quadspi: add suspend/resume hooks

Implement suspend/resume hooks. Signed-off-by: Claudiu Beznea <claudiu.bez...@microchip.com> --- drivers/mtd/spi-nor/atmel-quadspi.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c b/drivers/mtd/spi-nor/atmel-quadspi.c

[PATCH] mtd: atmel-quadspi: add suspend/resume hooks

Implement suspend/resume hooks. Signed-off-by: Claudiu Beznea --- drivers/mtd/spi-nor/atmel-quadspi.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c b/drivers/mtd/spi-nor/atmel-quadspi.c index 6c5708bacad8..85d7610fb920 100644

Re: [PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks

nter value and restores. This is needed in > >> modes like rtc+ddr in self-refresh not doing this stalls the time. > > > > I suspect this too should really happen with cpu_pm. > > I believe going by the previous set of patches this fits better with > suspend/resume? Y

Re: [PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks

>> modes like rtc+ddr in self-refresh not doing this stalls the time. > > > > I suspect this too should really happen with cpu_pm. > > I believe going by the previous set of patches this fits better with > suspend/resume? Yes if you don't need it for cpuidle and other SoC

Re: [PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks

r in self-refresh not doing this stalls the time. > > I suspect this too should really happen with cpu_pm. I believe going by the previous set of patches this fits better with suspend/resume? > >> --- a/arch/arm/mach-omap2/timer.c >> +++ b/arch/arm/mach-omap2/timer.c >>

Re: [PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks

this stalls the time. > > I suspect this too should really happen with cpu_pm. I believe going by the previous set of patches this fits better with suspend/resume? > >> --- a/arch/arm/mach-omap2/timer.c >> +++ b/arch/arm/mach-omap2/timer.c >> @@ -4

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

needs the > >> GPIO core to create the links. (but I've not looked into it at all). > > > > Not all APIs accept device as parameter to easily create links. But I > > wonder, for cases like this, if we could not simply move the device to > > the end of the dpm list a

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

gt;>> > >>> I am thinking a more generic solution might involve some more complex > >>> tracking of the provider <-> consumer, but there is room for breakage. > >> > >> That's what device connections are for. It probably just needs the > >> GPI

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

ust needs the >> GPIO core to create the links. (but I've not looked into it at all). > > Not all APIs accept device as parameter to easily create links. But I > wonder, for cases like this, if we could not simply move the device to > the end of the dpm list after successful b

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

PIO core to create the links. (but I've not looked into it at all). > > Not all APIs accept device as parameter to easily create links. But I > wonder, for cases like this, if we could not simply move the device to > the end of the dpm list after successful binding it to a driver. The >

Re: [PATCH v3 0/3] ti_am335x_tsc: Fix suspend/resume

On 24-Apr-18 11:57 AM, Vignesh R wrote: > This patch series fixes couple of issues wrt suspend/resume with TI AM335x > TSC driver. Disable and clear any pending IRQs before suspend, and > handle case where TSC wakeup would fail, if there were touch events > during suspend. >

Re: [PATCH v3 0/3] ti_am335x_tsc: Fix suspend/resume

On 24-Apr-18 11:57 AM, Vignesh R wrote: > This patch series fixes couple of issues wrt suspend/resume with TI AM335x > TSC driver. Disable and clear any pending IRQs before suspend, and > handle case where TSC wakeup would fail, if there were touch events > during suspend. >

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

el doesn't >>> support. >>> >>> Signed-off-by: Dmitry Osipenko <dig...@gmail.com> >>> Cc: <sta...@vger.kernel.org> >>> --- >>> drivers/i2c/busses/i2c-tegra.c | 33 --------- >>> 1 file changed, 33 deletions(-) >> >> Shardar

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

pport. >>> >>> Signed-off-by: Dmitry Osipenko >>> Cc: >>> --- >>> drivers/i2c/busses/i2c-tegra.c | 33 --------- >>> 1 file changed, 33 deletions(-) >> >> Shardar, Laxman, any thoughts on this? The is_

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

d, which upstream kernel doesn't >>> support. >>> >>> Signed-off-by: Dmitry Osipenko <dig...@gmail.com> >>> Cc: <sta...@vger.kernel.org> >>> --- >>>   drivers/i2c/busses/i2c-tegra.c | 33 ----- >>&g

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

using lowest power-mode during suspend, which upstream kernel doesn't >>> support. >>> >>> Signed-off-by: Dmitry Osipenko >>> Cc: >>> --- >>>   drivers/i2c/busses/i2c-tegra.c | 33 ----- >>>   1 file changed, 33 deletions(-) >> Shardar, Lax

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

sses/i2c-tegra.c | 33 - > > > 1 file changed, 33 deletions(-) > > Shardar, Laxman, any thoughts on this? The is_suspended thing looks to > > me like a workaround of some sort that may not be needed if clients have > > proper suspend/res

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

be only needed in a case of > > > using lowest power-mode during suspend, which upstream kernel doesn't > > > support. > > > > > > Signed-off-by: Dmitry Osipenko > > > Cc: > > > --- > > > drivers/i2c/busses/i2c-tegra.c | 33 --------

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

_suspended thing looks to me like a workaround of some sort that may not be needed if clients have proper suspend/resume implementations. Even without suspend/resume support in client drivers, the driver core should resume devices in the right order (I2C adapter before any of the clients), so I don

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

some sort that may not be needed if clients have proper suspend/resume implementations. Even without suspend/resume support in client drivers, the driver core should resume devices in the right order (I2C adapter before any of the clients), so I don't see any cases where the is_suspended logic would

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

t;sta...@vger.kernel.org> > > --- > > drivers/i2c/busses/i2c-tegra.c | 33 - > > 1 file changed, 33 deletions(-) > > Shardar, Laxman, any thoughts on this? The is_suspended thing looks to > me like a workaround of some sort that may not be n

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

t; drivers/i2c/busses/i2c-tegra.c | 33 - > > 1 file changed, 33 deletions(-) > > Shardar, Laxman, any thoughts on this? The is_suspended thing looks to > me like a workaround of some sort that may not be needed if clients have > proper suspend/resume implemen

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

houghts on this? The is_suspended thing looks to me like a workaround of some sort that may not be needed if clients have proper suspend/resume implementations. Even without suspend/resume support in client drivers, the driver core should resume devices in the right order (I2C adapter before any of th

Re: [PATCH v1] i2c: tegra: Remove suspend-resume

a workaround of some sort that may not be needed if clients have proper suspend/resume implementations. Even without suspend/resume support in client drivers, the driver core should resume devices in the right order (I2C adapter before any of the clients), so I don't see any cases where the is_suspended logic would be useful. Thierry signature.asc Description: PGP signature

[PATCH v1] i2c: tegra: Remove suspend-resume

Nothing prevents I2C clients to access I2C while Tegra's driver is being suspended, this results in -EBUSY error returned to the clients and that may have unfortunate consequences. In particular this causes problems for the TPS6586x MFD driver which emits hundreds of "failed to read interrupt

[PATCH v1] i2c: tegra: Remove suspend-resume

Nothing prevents I2C clients to access I2C while Tegra's driver is being suspended, this results in -EBUSY error returned to the clients and that may have unfortunate consequences. In particular this causes problems for the TPS6586x MFD driver which emits hundreds of "failed to read interrupt

Re: [PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

On Thursday, April 26, 2018 11:36:20 PM CEST Bjorn Helgaas wrote: > These are pretty minor cleanups to the suspend/resume diagnostic messages. > > The first two are trivial. The third may break scripts that parse dmesg > output. I looked at scripts/bootgraph.pl, and I

Re: [PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

On Thursday, April 26, 2018 11:36:20 PM CEST Bjorn Helgaas wrote: > These are pretty minor cleanups to the suspend/resume diagnostic messages. > > The first two are trivial. The third may break scripts that parse dmesg > output. I looked at scripts/bootgraph.pl, and I

Re: [PATCH 1/2] tpm: do not suspend/resume if power stays on

> > > > > > > commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream > > > > > > The suspend/resume behavior of the TPM can be controlled by setting > > > "powered-while-suspended" in the DTS. This is useful for the cases > > > when hardware

Re: [PATCH 1/2] tpm: do not suspend/resume if power stays on

0801a5ecbe958caa3d68b8eaee8 upstream > > > > > > The suspend/resume behavior of the TPM can be controlled by setting > > > "powered-while-suspended" in the DTS. This is useful for the cases > > > when hardware does not power-off the TPM.

Re: [PATCH 1/2] tpm: do not suspend/resume if power stays on

On Fri, May 04, 2018 at 07:27:13PM -0700, Greg KH wrote: > On Wed, May 02, 2018 at 05:38:28PM +0300, Jarkko Sakkinen wrote: > > From: Enric Balletbo i Serra <enric.balle...@collabora.com> > > > > commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream > >

Re: [PATCH 1/2] tpm: do not suspend/resume if power stays on

On Fri, May 04, 2018 at 07:27:13PM -0700, Greg KH wrote: > On Wed, May 02, 2018 at 05:38:28PM +0300, Jarkko Sakkinen wrote: > > From: Enric Balletbo i Serra > > > > commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream > > > > The suspend/resume beha

Re: [PATCH 1/2] tpm: do not suspend/resume if power stays on

On Wed, May 02, 2018 at 05:38:28PM +0300, Jarkko Sakkinen wrote: > From: Enric Balletbo i Serra <enric.balle...@collabora.com> > > commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream > > The suspend/resume behavior of the TPM can be controlled by setting >

Re: [PATCH 1/2] tpm: do not suspend/resume if power stays on

On Wed, May 02, 2018 at 05:38:28PM +0300, Jarkko Sakkinen wrote: > From: Enric Balletbo i Serra > > commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream > > The suspend/resume behavior of the TPM can be controlled by setting > "powered-while-suspended"

[PATCH 1/2] tpm: do not suspend/resume if power stays on

From: Enric Balletbo i Serra <enric.balle...@collabora.com> commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream The suspend/resume behavior of the TPM can be controlled by setting "powered-while-suspended" in the DTS. This is useful for the cases when hardware does not p

[PATCH 1/2] tpm: do not suspend/resume if power stays on

From: Enric Balletbo i Serra commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream The suspend/resume behavior of the TPM can be controlled by setting "powered-while-suspended" in the DTS. This is useful for the cases when hardware does not power-off the TPM. Signed-off-by:

Re: [RFC PATCH 4/5] net: macb: Add support for suspend/resume with full power down

t; + macb_reset_hw(bp); >>> + spin_unlock_irqrestore(>lock, flags); >> >> Wouldn't be simple to just call macb_close() here? > > >> >> Wouln't be simpler to call macb_open() here? > > No, I think that would be excessive for suspend.

Re: [RFC PATCH 4/5] net: macb: Add support for suspend/resume with full power down

pin_unlock_irqrestore(>lock, flags); >> >> Wouldn't be simple to just call macb_close() here? > > >> >> Wouln't be simpler to call macb_open() here? > > No, I think that would be excessive for suspend. This does just > enough to put the IP into suspend and cut

Re: [RFC PATCH 4/5] net: macb: Add support for suspend/resume with full power down

Hi Claudiu, On Thu, May 3, 2018 at 3:39 PM, Claudiu Beznea wrote: > > > On 22.03.2018 15:51, harinikatakamli...@gmail.com wrote: >> From: Harini Katakam >> >> When macb device is suspended and system is powered down, the clocks >> are removed

Re: [RFC PATCH 4/5] net: macb: Add support for suspend/resume with full power down

Hi Claudiu, On Thu, May 3, 2018 at 3:39 PM, Claudiu Beznea wrote: > > > On 22.03.2018 15:51, harinikatakamli...@gmail.com wrote: >> From: Harini Katakam >> >> When macb device is suspended and system is powered down, the clocks >> are removed and hence macb should be closed gracefully and

Re: [RFC PATCH 4/5] net: macb: Add support for suspend/resume with full power down

On 22.03.2018 15:51, harinikatakamli...@gmail.com wrote: > From: Harini Katakam > > When macb device is suspended and system is powered down, the clocks > are removed and hence macb should be closed gracefully and restored > upon resume. Is this a power saving mode which

Re: [RFC PATCH 4/5] net: macb: Add support for suspend/resume with full power down

On 22.03.2018 15:51, harinikatakamli...@gmail.com wrote: > From: Harini Katakam > > When macb device is suspended and system is powered down, the clocks > are removed and hence macb should be closed gracefully and restored > upon resume. Is this a power saving mode which shut down the core?

[PATCH 1/2] tpm: do not suspend/resume if power stays on

From: Enric Balletbo i Serra <enric.balle...@collabora.com> commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream The suspend/resume behavior of the TPM can be controlled by setting "powered-while-suspended" in the DTS. This is useful for the cases when hardware does not p

[PATCH 1/2] tpm: do not suspend/resume if power stays on

From: Enric Balletbo i Serra commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream The suspend/resume behavior of the TPM can be controlled by setting "powered-while-suspended" in the DTS. This is useful for the cases when hardware does not power-off the TPM. Signed-off-by:

Re: [PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

On Thu 2018-04-26 16:36:20, Bjorn Helgaas wrote: > These are pretty minor cleanups to the suspend/resume diagnostic messages. > > The first two are trivial. The third may break scripts that parse dmesg > output. I looked at scripts/bootgraph.pl, and I don't think it is > affected

Re: [PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

On Thu 2018-04-26 16:36:20, Bjorn Helgaas wrote: > These are pretty minor cleanups to the suspend/resume diagnostic messages. > > The first two are trivial. The third may break scripts that parse dmesg > output. I looked at scripts/bootgraph.pl, and I don't think it is > affected

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Tue, 24 Apr 2018, Imre Deak wrote: > On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > > Hi, > > > > > > > > while checking bug [1], I noticed that jiffies based

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Tue, 24 Apr 2018, Imre Deak wrote: > On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > > Hi, > > > > > > > > while checking bug [1], I noticed that jiffies based

[PATCH 3/3] PM / core: Use dev_printk() and symbols in suspend/resume diagnostics

From: Bjorn Helgaas <bhelg...@google.com> When we print diagnostic messages about suspend/resume, we have a device pointer, so use dev_printk() to match other device-related things. Add the function name, similar to initcall_debug output. E.g., - calling :01:00.0+ @ 998, parent: 0

[PATCH 3/3] PM / core: Use dev_printk() and symbols in suspend/resume diagnostics

From: Bjorn Helgaas When we print diagnostic messages about suspend/resume, we have a device pointer, so use dev_printk() to match other device-related things. Add the function name, similar to initcall_debug output. E.g., - calling :01:00.0+ @ 998, parent: :00:1c.0 + pci :01

[PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

These are pretty minor cleanups to the suspend/resume diagnostic messages. The first two are trivial. The third may break scripts that parse dmesg output. I looked at scripts/bootgraph.pl, and I don't think it is affected, but there may be others I don't know about. Let me know

[PATCH 0/3] PM / core: Clean up suspend/resume diagnostic messages

These are pretty minor cleanups to the suspend/resume diagnostic messages. The first two are trivial. The third may break scripts that parse dmesg output. I looked at scripts/bootgraph.pl, and I don't think it is affected, but there may be others I don't know about. Let me know

[PATCH 08/11] irqchip: stm32: add suspend/resume support for hierarchy domain

From: Ludovic Barre <ludovic.ba...@st.com> This patch adds suspend/resume feature for exti hierarchy domain. -suspend function sets wake_active into imr of each banks -resume function restores the mask_cache interrupt into imr of each banks Signed-off-by: Ludovic Barre <ludovic.ba.

[PATCH 08/11] irqchip: stm32: add suspend/resume support for hierarchy domain

From: Ludovic Barre This patch adds suspend/resume feature for exti hierarchy domain. -suspend function sets wake_active into imr of each banks -resume function restores the mask_cache interrupt into imr of each banks Signed-off-by: Ludovic Barre --- drivers/irqchip/irq-stm32-exti.c | 49

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 9:29:59 PM CEST Grygorii Strashko wrote: > > On 04/25/2018 02:10 PM, Grygorii Strashko wrote: > > > > > > On 04/25/2018 01:57 PM, Florian Fainelli wrote: > >> On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > >>> > >>> > >>> On 04/25/2018 01:29 PM, Florian Fainelli

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 9:29:59 PM CEST Grygorii Strashko wrote: > > On 04/25/2018 02:10 PM, Grygorii Strashko wrote: > > > > > > On 04/25/2018 01:57 PM, Florian Fainelli wrote: > >> On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > >>> > >>> > >>> On 04/25/2018 01:29 PM, Florian Fainelli

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 8:14:35 PM CEST Dmitry Torokhov wrote: > On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote: > > On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli > > wrote: > > > Hi Linus, Rafael, all > > > > > > Our GPIO controller driver:

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 8:14:35 PM CEST Dmitry Torokhov wrote: > On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote: > > On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli > > wrote: > > > Hi Linus, Rafael, all > > > > > > Our GPIO controller driver: gpio-brcmstb.c has a shutdown

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 02:10 PM, Grygorii Strashko wrote: On 04/25/2018 01:57 PM, Florian Fainelli wrote: On 04/25/2018 11:47 AM, Grygorii Strashko wrote: On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 02:10 PM, Grygorii Strashko wrote: On 04/25/2018 01:57 PM, Florian Fainelli wrote: On 04/25/2018 11:47 AM, Grygorii Strashko wrote: On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:57 PM, Florian Fainelli wrote: > On 04/25/2018 11:47 AM, Grygorii Strashko wrote: >> >> >> On 04/25/2018 01:29 PM, Florian Fainelli wrote: >>> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: > Hi Linus, Rafael,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:57 PM, Florian Fainelli wrote: > On 04/25/2018 11:47 AM, Grygorii Strashko wrote: >> >> >> On 04/25/2018 01:29 PM, Florian Fainelli wrote: >>> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: > Hi Linus, Rafael,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > > > On 04/25/2018 01:29 PM, Florian Fainelli wrote: >> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: >>> >>> >>> On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > > > On 04/25/2018 01:29 PM, Florian Fainelli wrote: >> On 04/25/2018 11:06 AM, Grygorii Strashko wrote: >>> >>> >>> On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 01:29 PM, Florian Fainelli wrote: On 04/25/2018 11:06 AM, Grygorii Strashko wrote: On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:06 AM, Grygorii Strashko wrote: > > > On 04/24/2018 05:58 PM, Florian Fainelli wrote: >> Hi Linus, Rafael, all >> >> Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which >> gets invoked when the system is brought into poweroff aka S5. So far so >> good,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/25/2018 11:06 AM, Grygorii Strashko wrote: > > > On 04/24/2018 05:58 PM, Florian Fainelli wrote: >> Hi Linus, Rafael, all >> >> Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which >> gets invoked when the system is brought into poweroff aka S5. So far so >> good,

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote: > On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli > wrote: > > Hi Linus, Rafael, all > > > > Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which > > gets invoked when the system is brought

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote: > On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli > wrote: > > Hi Linus, Rafael, all > > > > Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which > > gets invoked when the system is brought into poweroff aka S5.

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into poweroff aka S5. So far so good, except that we also wish to use gpio_keys.c as a possible wake-up

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On 04/24/2018 05:58 PM, Florian Fainelli wrote: Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into poweroff aka S5. So far so good, except that we also wish to use gpio_keys.c as a possible wake-up

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli wrote: > Hi Linus, Rafael, all > > Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which > gets invoked when the system is brought into poweroff aka S5. So far so > good, except that we also wish to use

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli wrote: > Hi Linus, Rafael, all > > Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which > gets invoked when the system is brought into poweroff aka S5. So far so > good, except that we also wish to use gpio_keys.c as a possible

[PATCH 4.14 161/183] ACPI / EC: Restore polling during noirq suspend/resume phases

4.14-stable review patch. If anyone has any objections, please let me know. -- From: "Rafael J. Wysocki" [ Upstream commit 3cd091a773936c54344a519f7ee1379ccb620bee ] Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) modified

[PATCH 4.14 161/183] ACPI / EC: Restore polling during noirq suspend/resume phases

4.14-stable review patch. If anyone has any objections, please let me know. -- From: "Rafael J. Wysocki" [ Upstream commit 3cd091a773936c54344a519f7ee1379ccb620bee ] Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) modified the ACPI EC driver so that

Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into poweroff aka S5. So far so good, except that we also wish to use gpio_keys.c as a possible wake-up source, so we may have a number of GPIO pins declared as

Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

Hi Linus, Rafael, all Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which gets invoked when the system is brought into poweroff aka S5. So far so good, except that we also wish to use gpio_keys.c as a possible wake-up source, so we may have a number of GPIO pins declared as

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Tue, Apr 24, 2018 at 05:07:41PM +0300, Imre Deak wrote: > On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > > Hi, > > > > > > > > while checking bug [1], I noticed

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Tue, Apr 24, 2018 at 05:07:41PM +0300, Imre Deak wrote: > On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > > Hi, > > > > > > > > while checking bug [1], I noticed

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > Hi, > > > > > > while checking bug [1], I noticed that jiffies based timing loops like > > > > > > expire = jiffies +

Re: Early timeouts due to inaccurate jiffies during system suspend/resume

On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote: > On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote: > > On Thu, 19 Apr 2018, Imre Deak wrote: > > > Hi, > > > > > > while checking bug [1], I noticed that jiffies based timing loops like > > > > > > expire = jiffies +

<    7   8   9   10   11   12   13   14   15   16   >