5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit 98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream.
Currently we deal with single codec and suspend codec callbacks for
all S3, S4 and runtime PM handling. But it turned
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit 98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream.
Currently we deal with single codec and suspend codec callbacks for
all S3, S4 and runtime PM handling. But it turned
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit 98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream.
Currently we deal with single codec and suspend codec callbacks for
all S3, S4 and runtime PM handling. But it turned
often recently that I somehow
thought it was common and started using it myself.
Guenter
> > Overall the implementation does seem a bit suspicious to me. I don't really
> > understand why the platform driver handles suspend/resume for the cards.
> > But that may just be my lack
n't think there is a UAF involved - I built the
> test image with KASAN enabled and it did not barf at me.
What is a "UAF"?
> Overall the implementation does seem a bit suspicious to me. I don't really
> understand why the platform driver handles suspend/resume for the cards.
>
On Mon, Mar 25, 2019 at 09:18:04AM -0400, Pierre-Louis Bossart wrote:
> On 3/25/19 8:12 AM, Mark Brown wrote:
> > These are driver specific issues not device model issues as far as I can
> > see? The issue fixed by this as is that you're storing a pointer in the
> > ASoC level (not device model
me memory
or reference count leak. But that would be a different problem.
Overall the implementation does seem a bit suspicious to me. I don't really
understand why the platform driver handles suspend/resume for the cards.
But that may just be my lack of understanding. However, either case, I think the
Haswe
From: Robin Gong
To support pinctl hog restore after LPSR resume back,
add suspend/resume in pinctrl driver.
Signed-off-by: Robin Gong
Signed-off-by: Abel Vesa
---
Changes since v1:
* fixed Robin's email
drivers/pinctrl/freescale/pinctrl-imx.c | 20
drivers/pinctrl
On Mon, Mar 25, 2019 at 3:49 PM Abel Vesa wrote:
>
> From: Robin Gong
Please fix Robin's email.
From: Robin Gong
To support pinctl hog restore after LPSR resume back,
add suspend/resume in pinctrl driver.
Signed-off-by: Robin Gong
Signed-off-by: Abel Vesa
---
drivers/pinctrl/freescale/pinctrl-imx.c | 20
drivers/pinctrl/freescale/pinctrl-imx.h | 3 +++
2 files
On 3/25/19 8:12 AM, Mark Brown wrote:
On Sat, Mar 23, 2019 at 09:55:46AM -0400, Pierre-Louis Bossart wrote:
I'd like to highlight that there is a fundamental flaw in the way the
machine drivers are handled. Since we don't have a hook for the machine
driver in the BIOS, the DSP driver creates a
The patch
ASoC: intel: Fix crash at suspend/resume after failed codec registration
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime
On Sat, Mar 23, 2019 at 09:55:46AM -0400, Pierre-Louis Bossart wrote:
> I'd like to highlight that there is a fundamental flaw in the way the
> machine drivers are handled. Since we don't have a hook for the machine
> driver in the BIOS, the DSP driver creates a platform_device which will
>
On Fri, Mar 22, 2019 at 03:39:48PM -0700, Guenter Roeck wrote:
> general protection fault: [#1] PREEMPT SMP KASAN PTI
> CPU: 1 PID: 2811 Comm: cat Tainted: GW 4.19.30 #15
> Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014
> RIP:
On 3/22/19 6:39 PM, Guenter Roeck wrote:
If codec registration fails after the ASoC Intel SST driver has been probed,
the kernel will Oops and crash at suspend/resume.
general protection fault: [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 2811 Comm: cat Tainted: GW 4.19.30 #15
If codec registration fails after the ASoC Intel SST driver has been probed,
the kernel will Oops and crash at suspend/resume.
general protection fault: [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 2811 Comm: cat Tainted: GW 4.19.30 #15
Hardware name: GOOGLE Clapper, BIOS
From: Roger Quadros
Pin state might have changed during suspend/resume while
our interrupts were disabled and if device doesn't support wakeup.
Scan for change during resume for such case.
Signed-off-by: Roger Quadros
Signed-off-by: Chanwoo Choi
(cherry picked from commit
continue suspending the
> system and then another suspend callback fails the suspend process and
> "unwinds" the previously suspended drivers by calling their resume
> callbacks. When we get back to resuming this RTC driver, we'll call
> disable_irq_wake() on an IRQ that hasn't been config
In order to suspend-resume CPU with Trusted Foundations firmware being
present on Tegra30, the LP1/LP2 boot vectors and CPU caches need to be
set up using the firmware calls and then suspend code shall avoid
re-disabling parts that were disabled by the firmware.
Tested-by: Robert Yang
Tested
This patch fixes the implementation of suspend/resume of the device so that
upon resume of the device, the host won't crash due to PCI completion
timeout.
Upon suspend, the device is being reset due to PERST. Therefore, upon
resume, the driver must initialize the PCI controller as if the driver
Q that hasn't been configured for wake.
>
> Let's just fail suspend/resume here if we can't configure the system to
> wake and the user has chosen to wakeup with this device. This fixes this
> warning and makes the code more robust in case there are systems out
> there that can
winds" the previously suspended drivers by calling their resume
callbacks. When we get back to resuming this RTC driver, we'll call
disable_irq_wake() on an IRQ that hasn't been configured for wake.
Let's just fail suspend/resume here if we can't configure the system to
wake and the user has chosen
The patch
spi: spi-mem: stm32-qspi: add suspend/resume support
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours
Ville Syrjälä wrote on Thu [2019-Mar-14
17:31:29 +0200]:
> On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> > During a suspend cycle the atomic state is saved to be used during the
> > restore cycle.
> >
> > However the current state duplication logic does not duplicate private
.kernel.org; linux-arm-ker...@lists.infradead.org
> Cc: dl-linux-imx
> Subject: [PATCH] mailbox: imx: keep MU irq working during suspend/resume
>
> During noirq suspend phase, mailbox MU irq will be masked but many
> drivers still need to communicate with system controller
From: Ludovic Barre
This patch adds suspend and resume support for spi-stm32-qspi
drivers.
Signed-off-by: Ludovic Barre
---
drivers/spi/spi-stm32-qspi.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-stm32-qspi.c
From: Antoine Tenart
Date: Fri, 1 Mar 2019 12:00:44 +0100
> This series implements the suspend/resume callbacks in the marvell10g
> PHY driver:
>
> - When the PHY isn't used, it is set in low power mode.
> - At boot time we might now know the PHY status (as it's depending on
&
In order to suspend-resume CPU with Trusted Foundations firmware being
present on Tegra30, the LP1/LP2 boot vectors and CPU caches need to be
set up using the firmware calls and then suspend code shall avoid
re-disabling parts that were disabled by the firmware.
Tested-by: Robert Yang
Tested
On Fri, Mar 01, 2019 at 12:00:45PM +0100, Antoine Tenart wrote:
> This patch adds the suspend/resume callbacks for Marvell 10G PHYs. The
> three PCS (base-t, base-r and 1000base-x) are set in low power (the PCS
> are powered down) when the PHY isn't used.
>
> Signed-off-by:
On Fri, Mar 01, 2019 at 12:00:46PM +0100, Antoine Tenart wrote:
> When the 88x2110 PHY support was added, the suspend and resume callbacks
> were forgotten. This patch adds them to the 88x2110 PHY callback
> definition.
>
> Signed-off-by: Antoine Tenart
Reviewed-by: Andrew Lunn
Andrew
This patch adds the suspend/resume callbacks for Marvell 10G PHYs. The
three PCS (base-t, base-r and 1000base-x) are set in low power (the PCS
are powered down) when the PHY isn't used.
Signed-off-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 14 ++
1 file changed, 14
When the 88x2110 PHY support was added, the suspend and resume callbacks
were forgotten. This patch adds them to the 88x2110 PHY callback
definition.
Signed-off-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c
Hello,
This series implements the suspend/resume callbacks in the marvell10g
PHY driver:
- When the PHY isn't used, it is set in low power mode.
- At boot time we might now know the PHY status (as it's depending on
the hardware configuration, or on what the previous stages
configured
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. This patch does the same by switching off the net device,
suspending phy and performing necessary cleanup of interrupts and BDs.
Upon resume, all
In order to suspend-resume CPU with Trusted Foundations firmware being
present on Tegra30, the LP1/LP2 boot vectors and CPU caches need to be
set up using the firmware calls and then suspend code shall avoid
re-disabling parts that were disabled by the firmware.
Tested-by: Robert Yang
Tested
Hello,
This series implements the suspend/resume callbacks in the marvell10g
PHY driver:
- When the PHY isn't used, it is set in low power mode.
- At boot time we might now know the PHY status (as it's depending on
the hardware configuration, or on what the previous stages
configured
This patch adds the suspend/resume callbacks for Marvell 10G PHYs. The
three PCS (base-t, base-r and 1000base-x) are set in low power (the PCS
are powered down) when the PHY isn't used.
Signed-off-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 24
1 file changed
When the 88x2110 PHY support was added, the suspend and resume callbacks
were forgotten. This patch adds them to the 88x2110 PHY callback
definition.
Signed-off-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c
In order to suspend-resume CPU with Trusted Foundations firmware being
present on Tegra30, the LP1/LP2 boot vectors and CPU caches need to be
set up using the firmware calls and then suspend code shall avoid
re-disabling parts that were disabled by the firmware.
Tested-by: Robert Yang
Tested
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
commit d04ca383860bef90a0dab4eb397907f7f05e839e upstream.
We need to reset MCU and do other initializations on resume otherwise
MT7610U device will fail to initialize, what
In order to suspend-resume CPU with Trusted Foundations firmware being
present on Tegra30, the LP1/LP2 boot vectors and CPU caches need to be
set up using the firmware calls and then suspend code shall avoid
re-disabling parts that were disabled by the firmware.
Signed-off-by: Dmitry Osipenko
22.02.2019 20:59, Dmitry Osipenko пишет:
> In order to resume CPU from suspend via trusted Foundations firmware,
> the LP1/LP2 boot vectors and CPU caches need to be set up using the
> firmware calls.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/mach-tegra/pm.c| 53
In order to resume CPU from suspend via trusted Foundations firmware,
the LP1/LP2 boot vectors and CPU caches need to be set up using the
firmware calls.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c| 53 ++---
On Fri, Feb 22, Paolo Bonzini wrote:
> On 22/02/19 12:44, Thomas Gleixner wrote:
> >> The specific usecase I have is a workload within VMs that makes heavy
> >> use of TSC. The kernel is booted with 'clocksource=tsc highres=off
> >> nohz=off'
> >> because only this clocksource gives enough
a
bulk save/restore of all registers during system suspend/resume.
drivers/iommu/ipmmu-vmsa.c | 52 +-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 92a766dd8b459f0c
On 22/02/19 12:44, Thomas Gleixner wrote:
>> The specific usecase I have is a workload within VMs that makes heavy
>> use of TSC. The kernel is booted with 'clocksource=tsc highres=off nohz=off'
>> because only this clocksource gives enough granularity. The default
>> paravirtualized clock will
Am Fri, 22 Feb 2019 12:44:39 +0100 (CET)
schrieb Thomas Gleixner :
> Whether that is accurate enough or not to make NTP happy, I can't tell, but
> it's definitely worth a try.
Thanks Thomas, I will look into the suggestions.
Olaf
pgpKvKEGb9vSF.pgp
Description: Digitale Signatur von OpenPGP
On Fri, 22 Feb 2019, Olaf Hering wrote:
> Is there a way to recalibrate the x86 TSC during a suspend/resume cycle?
No.
> While the frequency will remain the same on a Laptop, it may (or rather:
> it definitly will) differ if a VM is migrated from one host to another.
> The hyperviso
Is there a way to recalibrate the x86 TSC during a suspend/resume cycle?
While the frequency will remain the same on a Laptop, it may (or rather:
it definitly will) differ if a VM is migrated from one host to another.
The hypervisor may choose to emulate the expected TSC frequency
p;& CONFIG_ARM_PSCI_FW */
> > >> +
> > >> static struct platform_driver ipmmu_driver = {
> > >> .driver = {
> > >> .name = "ipmmu-vmsa",
> > >> .of_match_table = of_match_ptr(ipmmu_of_ids),
>
; >> This patch takes a different approach than the BSP, which implements a
> >> bulk save/restore of all registers during system suspend/resume.
> >
> > I like this approach better too.
>
> Thanks ;-)
>
> >> --- a/drivers/iommu/ipmmu-vmsa.c
&
> > build time dependency on sleep and PSCI support, and a runtime
> > dependency on PSCI.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > This patch takes a different approach than the BSP, which implements a
> > bulk save/restore of all registers duri
dency on PSCI.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> This patch takes a different approach than the BSP, which implements a
> bulk save/restore of all registers during system suspend/resume.
I like this approach better too.
> drivers/iommu/ipmmu-vmsa.c | 52
registers during system suspend/resume.
drivers/iommu/ipmmu-vmsa.c | 52 +-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 92a766dd8b459f0c..5d22139914e8f033 100644
--- a/drivers/iommu/ipmmu
Hi Jörg, Magnus,
On R-Car Gen3 systems with PSCI, PSCI may power down the SoC during
system suspend, thus losing all IOMMU state. Hence after s2ram, devices
behind an IPMMU (e.g. SATA), and configured to use it, will fail to
complete their I/O operations.
This patch series adds suspend
This patch series hooks up proper support for USB suspend and resume to the
Atmel UDC.
Jonas Bonn (3):
usb: gadget: atmel_usba_udc: simplify setting of interrupt-enabled
mask
usb: gadget: atmel: support USB suspend
usb: gadget: atmel: tie wake lock to running clock
4.19-stable review patch. If anyone has any objections, please let me know.
--
commit 1a5287a3dbc34cd0c02c8f64c9131bd23cdfe2bb upstream.
During noirq suspend/resume phase, GPIO irq could arrive
and its registers like IMR will be changed by irq handle
process, to make the GPIO
4.20-stable review patch. If anyone has any objections, please let me know.
--
commit 1a5287a3dbc34cd0c02c8f64c9131bd23cdfe2bb upstream.
During noirq suspend/resume phase, GPIO irq could arrive
and its registers like IMR will be changed by irq handle
process, to make the GPIO
In order to resume CPU from suspend via trusted Foundations firmware,
the LP1/LP2 boot vectors shall be specified using the firmware calls.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c| 14 ++
arch/arm/mach-tegra/reset-handler.S | 26
E events. Since the devfreq
> > core itself generates these events and invokes the governor's event
> > handler the suspend/resume of the load monitoring can be done in the
> > common code.
> >
> > Call devfreq_monitor_suspend/resume() when the governor reports a
> &g
Hi Matthias,
2019년 2월 14일 (목) 오후 7:16, Matthias Kaehlcke 님이 작성:
>
> devfreq expects governors to call devfreq_monitor_suspend/resume()
> in response to DEVFREQ_GOV_SUSPEND/RESUME events. Since the devfreq
> core itself generates these events and invokes the governor's event
> hand
devfreq expects governors to call devfreq_monitor_suspend/resume()
in response to DEVFREQ_GOV_SUSPEND/RESUME events. Since the devfreq
core itself generates these events and invokes the governor's event
handler the suspend/resume of the load monitoring can be done in the
common code.
Call
On Wed, Feb 13, 2019 at 10:53:01AM +0530, Vidya Sagar wrote:
> On 2/12/2019 4:25 AM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > Latency Tolerance Reporting (LTR) allows Endpoints and Switch Upstream
> > Ports to report their latency requirements to upstream components. If ASPM
> > L1
On 2/12/2019 4:25 AM, Bjorn Helgaas wrote:
From: Bjorn Helgaas
Latency Tolerance Reporting (LTR) allows Endpoints and Switch Upstream
Ports to report their latency requirements to upstream components. If ASPM
L1 PM substates are enabled, the LTR information helps determine when a
Link
is NOT working as GIC
driver does NOT have .irq_set_wake implemented, so to
support suspend/resume, just make imx mailbox driver NOT
suspend, since MU is always a wakeup source on i.MX platforms
with system controller inside, and its power/clock is
maintained by system controller, mailbox driver no need
From: Bjorn Helgaas
Latency Tolerance Reporting (LTR) allows Endpoints and Switch Upstream
Ports to report their latency requirements to upstream components. If ASPM
L1 PM substates are enabled, the LTR information helps determine when a
Link enters L1.2 [1].
Software must set the maximum
Hi,
Lately we (Intel) have got a few bugs on suspend / resume. The
complaint is that our device becomes unavailable after suspend / resume
cycle. The bug on which we have most data is [1].
The original submitter reported a regression since commit
9ab105deb60fa76d66cae5548819b4e8703d2056:
PCI
On Tue, 2019-01-22 at 21:41 -0500, Martin K. Petersen wrote:
> Ching,
>
> > This patch series are against to mkp's 5.1/scsi-queue.
>
> Applied to 5.1/scsi-queue. Thank you.
>
> PS. Your file permissions are odd. I always have to change your diffs
> from 755 to 644 before applying.
>
Thanks
Ching,
> This patch series are against to mkp's 5.1/scsi-queue.
Applied to 5.1/scsi-queue. Thank you.
PS. Your file permissions are odd. I always have to change your diffs
from 755 to 644 before applying.
--
Martin K. Petersen Oracle Linux Engineering
>
> At this point, you should be able to pass traffic between lan1 and
> lan2.
>
> bridge fdb add 00:42:42:42:42:42 lan1
> bridge fdb add 00:24:24:24:24:24 lan2
>
> That adds two static forwarding database entries. You can show these using
>
> bridge fdb show
>
bridge fdb show
There are likely to be additional dynamic FDB entries. It is O.K. to
loose the dynamic entries over a suspend/resume cycle, but the static
ones must remain.
> This looks pretty similar. Maybe the ports setup are set to default
> values while I should save some parameter
atches (adding port_disable/enable()
> > in dsa_slave_suspend/resume()) and keep the driver as-is or do you want
> > me to manually call port_disable/enable() from the mv88e6xxx driver?
>
> Up to you guys, the only thing that I an tell you is that my platform
> loses its regi
2019-01-17 at 10:59 +0300, Dan Carpenter wrote:
> > > > > On Thu, Jan 17, 2019 at 11:45:03AM +0800, Ching Huang wrote:
> > > > > > >From Ching Huang
> > > > > >
> > > > > > Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2.
&
n 17, 2019 at 11:45:03AM +0800, Ching Huang wrote:
> > > > > >From Ching Huang
> > > > >
> > > > > Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2.
> > > > >
> > > >
> > > > What does this look like from a user
On 1/18/2019 9:23 AM, Guenter Roeck wrote:
On 1/17/19 6:58 PM, Sai Prakash Ranjan wrote:
On 1/17/2019 11:46 PM, Guenter Roeck wrote:
On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep
On 1/17/19 6:58 PM, Sai Prakash Ranjan wrote:
On 1/17/2019 11:46 PM, Guenter Roeck wrote:
On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active
>From Ching Huang
For ACB_ADAPTER_TYPE_B controller, the read/write after hibernate and resume may
got 'isr get an illegal ccb command' in log/messages sometimes. This patch fix
it.
Signed-off-by: Ching Huang
---
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
On 1/17/2019 11:46 PM, Guenter Roeck wrote:
On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
This patch series are against to mkp's 5.1/scsi-queue.
1. Due to dma_zalloc_coherent will be phase out, so use dma_alloc_coherent
instead.
2. For ACB_ADAPTER_TYPE_B controller, the read/write after hibernate and resume
may
got 'isr get an illegal ccb command' in log/messages sometimes. This
> > > +
> > > > + return 0;
> > > > +}
> > >
> > > This looks fairly generic. For example, the Mediatek driver also stops
> > > and starts (but also pings after starting). Grepping for 'active' in
> > > drivers/watchdog/ finds more examples
ctive' in
> > drivers/watchdog/ finds more examples. Could there be some functions in
> > watchdog core that do the common things like watchdog_stop() and
> > watchdog_start() and watchdog_start_and_ping()? Or maybe a bit can be
> > set during registration so that the 'str
stops
> and starts (but also pings after starting). Grepping for 'active' in
> drivers/watchdog/ finds more examples. Could there be some functions in
> watchdog core that do the common things like watchdog_stop() and
> watchdog_start() and watchdog_start_and_ping()? Or maybe a bit can b
a_slave_suspend/resume()) and keep the driver as-is or do you want
> > me to manually call port_disable/enable() from the mv88e6xxx driver?
>
> Up to you guys, the only thing that I an tell you is that my platform
> loses its register contents during suspend/resume, therefore yo
chdog_start() and watchdog_start_and_ping()? Or maybe a bit can be
set during registration so that the 'struct class watchdog_class' can
get PM ops to stop and start on suspend/resume of the watchdog character
device?
Nothing is wrong with the patch, I'm just bemoaning the amount of code
duplication here.
On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:
> This adds the support for qcom watchdog suspend and resume
> when entering and exiting deep sleep states. Otherwise
> having watchdog active after suspend would result in unwanted
> crashes/resets if resume happens after a long
ally could be
>>> in the core.
>>
>> Indeed that is!
>
> So, shall I wait for Vivien's patches (adding port_disable/enable()
> in dsa_slave_suspend/resume()) and keep the driver as-is or do you want
> me to manually call port_disable/enable() from the mv88e6xxx driver?
U
Hi Andrew, Vivien,
Vivien Didelot wrote on Thu, 17 Jan 2019
10:46:41 -0500:
> Hi,
>
> On Wed, 16 Jan 2019 23:23:29 +0100, Andrew Lunn wrote:
> > Hi Florian
> >
> > > A possible approach could be to call the port_disable, port_enable
> > > callbacks from dsa_slave_suspend() and
Hi,
On Wed, 16 Jan 2019 23:23:29 +0100, Andrew Lunn wrote:
> Hi Florian
>
> > A possible approach could be to call the port_disable, port_enable
> > callbacks from dsa_slave_suspend() and dsa_slave_resume(), I might have
> > some patches doing that already somewhere.
>
> I expect it is also on
On 1/17/2019 8:49 PM, Sai Prakash Ranjan wrote:
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.
Signed-off-by: Sai
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.
Signed-off-by: Sai Prakash Ranjan
---
v2:
* Use __maybe_unused
Hi Guenter,
On 1/17/2019 8:00 PM, Guenter Roeck wrote:
I personally very much prefer __maybe_unused over #ifdef, for the reasons
stated above. Other maintainers may think differently.
Thanks for making your preference clear. I will post the second version
soon with the changes.
- Sai
--
config is disabled? We could just discard it. We would just
It is beneficial to know that a future change in the conditional code,
or an infrastructure change affecting it, doesn't cause a build error,
even if the person submitting the change didn't bother compiling with
PM_SLEEP=y.
> increase the b
build time with this attribute (although for this case it
would be negligible but say we compile with PM_SLEEP disabled for all
those suspend/resume functions with maybe_unused attribute).
Looking at previous discussions in LKML[1] as to why the pm
suspend/resume functions used __maybe_unu
On Thu, Jan 17, 2019 at 04:08:52PM +0530, Sai Prakash Ranjan wrote:
> On 1/17/2019 3:01 PM, Brian Masney wrote:
> >
> > You can use the __maybe_unused attribute to remove the #ifdef:
> >
> > static int __maybe_unused qcom_wdt_suspend(struct device *dev)
> >
>
> Thanks for looking into this.
>
Hi Brian,
On 1/17/2019 3:01 PM, Brian Masney wrote:
You can use the __maybe_unused attribute to remove the #ifdef:
static int __maybe_unused qcom_wdt_suspend(struct device *dev)
Thanks for looking into this.
As for __maybe_unused, I think it's better to keep #ifdef rather than
this
Ching Huang
> > > >
> > > > Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2.
> > > >
> > >
> > > What does this look like from a user perspective? Does it fail every
> > > time or does it only fail sometimes?
> > >
> >
On Thu, Jan 17, 2019 at 02:45:55PM +0530, Sai Prakash Ranjan wrote:
> +#ifdef CONFIG_PM_SLEEP
> +static int qcom_wdt_suspend(struct device *dev)
> +{
> + struct qcom_wdt *wdt = dev_get_drvdata(dev);
> +
> + if (watchdog_active(>wdd))
> + qcom_wdt_stop(>wdd);
> +
> + return
On Thu, Jan 17, 2019 at 04:47:07PM +0800, Ching Huang wrote:
> On Thu, 2019-01-17 at 10:59 +0300, Dan Carpenter wrote:
> > On Thu, Jan 17, 2019 at 11:45:03AM +0800, Ching Huang wrote:
> > > >From Ching Huang
> > >
> > > Fix suspend/resume of ACB_ADAPTER_T
This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.
Signed-off-by: Sai Prakash Ranjan
---
drivers/watchdog/qcom-wdt.c |
On Thu, 2019-01-17 at 10:59 +0300, Dan Carpenter wrote:
> On Thu, Jan 17, 2019 at 11:45:03AM +0800, Ching Huang wrote:
> > >From Ching Huang
> >
> > Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2.
> >
>
> What does this look like from a user perspective
701 - 800 of 7895 matches
Mail list logo
