@dev parameter of qca_suspend()/qca_resume() represents
serdev_device, but it is mistook for hci_dev and causes
succedent unexpected memory access.
Fix by taking @dev as serdev_device.
Signed-off-by: Zijun Hu
---
drivers/bluetooth/hci_qca.c | 12
1 file changed, 8 insertions(+), 4
Gentle ping...
> Subject: RE: [PATCH] mailbox: imx: Add context save/restore for
> suspend/resume
>
>
>
> > Subject: RE: [PATCH] mailbox: imx: Add context save/restore for
> > suspend/resume
> >
> > > From: Anson Huang
> > > Sent: Friday
On Fri, 22 May 2020 17:57:24 +0800, Shengjiu Wang wrote:
> With dedicated power domain for asrc, power can be disabled after
> probe and pm runtime suspend, then the value of all registers need to
> be restored in pm runtime resume. So we can merge suspend/resume function
> to run
g the
>>> i2c_client.
>> Just one more comment. The devices without i2c_client structure are the
>> i2c 'devices' associated with the respective i2c bus. They are visible
>> in /sys:
>>
>> ls -l /sys/bus/i2c/devices/i2c-*
>>
>> I wonder if t
e more comment. The devices without i2c_client structure are the
> i2c 'devices' associated with the respective i2c bus. They are visible
> in /sys:
>
> ls -l /sys/bus/i2c/devices/i2c-*
>
> I wonder if this patch has been ever tested with system suspend/resume,
> as thos
On Mon, May 25, 2020 at 10:18:16AM +0200, Nicolas Ferre wrote:
> On 07/05/2020 at 12:03, Nicolas Ferre wrote:
> > On 06/05/2020 at 22:18, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the content is safe
> > >
> > > On Wed, 6 May 2020 13:
On 07/05/2020 at 12:03, Nicolas Ferre wrote:
On 06/05/2020 at 22:18, Jakub Kicinski wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
On Wed, 6 May 2020 13:37:37 +0200 nicolas.fe...@microchip.com wrote:
From: Nicolas Ferre
Use the proper struc
On Mon, May 25, 2020 at 02:11:18PM +0800, Shengjiu Wang wrote:
> > > @@ -1135,6 +1137,24 @@ static int fsl_asrc_runtime_resume(struct device
> > > *dev)
> > > goto disable_asrck_clk;
> > > }
> > >
> > > + /* Stop all pairs provisionally */
> > > + regmap_read(as
On Fri, May 22, 2020 at 05:57:24PM +0800, Shengjiu Wang wrote:
> With dedicated power domain for asrc, power can be disabled after
> probe and pm runtime suspend, then the value of all registers need to
> be restored in pm runtime resume. So we can merge suspend/resume func
e restored in pm runtime resume. So we can merge suspend/resume function
> > to runtime_suspend/resume function and enable regcache only in end of
> > probe.
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/fsl/fsl_asrc.c | 70 --
On Fri, May 22, 2020 at 05:57:24PM +0800, Shengjiu Wang wrote:
> With dedicated power domain for asrc, power can be disabled after
> probe and pm runtime suspend, then the value of all registers need to
> be restored in pm runtime resume. So we can merge suspend/resume func
On 08/04/2020 11:05, Michael Kao wrote:
> From: Louis Yu
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
> Signed-off-by: Loui
ore comment. The devices without i2c_client structure are the
> i2c 'devices' associated with the respective i2c bus. They are visible
> in /sys:
>
> ls -l /sys/bus/i2c/devices/i2c-*
>
> I wonder if this patch has been ever tested with system suspend/resume,
> as
They are visible
in /sys:
ls -l /sys/bus/i2c/devices/i2c-*
I wonder if this patch has been ever tested with system suspend/resume,
as those devices are always available in the system...
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
apter")
Signed-off-by: Marek Szyprowski
---
This fixes suspend/resume issue observed on various board with linux-next
from 20200521.
---
drivers/i2c/i2c-core-base.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/driv
With dedicated power domain for asrc, power can be disabled after
probe and pm runtime suspend, then the value of all registers need to
be restored in pm runtime resume. So we can merge suspend/resume function
to runtime_suspend/resume function and enable regcache only in end of
probe.
Signed-off
Thanks. Looks like send an old one without fix. Did resend the patch again.
On Tue, 2020-05-19 at 23:26 +, Anchal Agarwal wrote:
> Signed-off--by: Thomas Gleixner
The Signed-off-by line needs to be fixed (hint: you have --)
Balbir Singh
On Tue, 2020-05-19 at 23:26 +, Anchal Agarwal wrote:
> Signed-off--by: Thomas Gleixner
The Signed-off-by line needs to be fixed (hint: you have --)
Balbir Singh
t all interrupts connected
to it are handled this way. This is pretty much in line with the other
interrupt chip specific quirks, e.g. IRQCHIP_MASK_ON_SUSPEND.
Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
it the core interrupt suspend/resume paths.
Signed-off-by: Anchal Agarwal
S
From: Thierry Reding
commit 0534d40160cb9505073b0ecf5e7210daee319a66 upstream.
When the XUDC device is idle (i.e. powergated), care must be taken not
to access any registers because that would lead to a crash.
Move the call to tegra_xudc_device_mode_off() into the same conditional
as the tegra_
From: Alex Elder
Date: Fri, 15 May 2020 15:07:29 -0500
> This series permits suspend/resume to work for the IPA driver
> on the Qualcomm SC7180 SoC. The IPA version on this SoC requires
> interrupts to be enabled when the suspend and resume callbacks are
> made, and the first patc
This series permits suspend/resume to work for the IPA driver
on the Qualcomm SC7180 SoC. The IPA version on this SoC requires
interrupts to be enabled when the suspend and resume callbacks are
made, and the first patch moves away from using the noirq variants.
The second patch fixes a problem
Use the suspend and resume callbacks rather than suspend_noirq and
resume_noirq. With IPA v4.2, we use the CHANNEL_STOP command to
implement a suspend, and without interrupts enabled, that command
won't complete.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_main.c | 4 ++--
1 file changed,
On Fri, 15 May 2020 at 08:19, Jisheng Zhang wrote:
>
> Add dwcmshc specific system-level suspend and resume support.
>
> Signed-off-by: Jisheng Zhang
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 43 +
> 1 file changed,
Add dwcmshc specific system-level suspend and resume support.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 43 +
1 file changed, 43 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index a
Add suspend and resume callback function for
Realtek DHC SoC pinctrl driver.
Signed-off-by: TY Chang
---
drivers/pinctrl/realtek/pinctrl-rtd.c | 39 +
drivers/pinctrl/realtek/pinctrl-rtd1195.h | 33 +++
drivers/pinctrl/realtek/pinctrl-rtd1295.h | 67 ++
On Wed, 2020-04-08 at 17:05 +0800, Michael Kao (高振翔) wrote:
> From: Louis Yu
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
>
On Tue, May 12, 2020 at 06:01:53PM +0200, Vitaly Kuznetsov wrote:
> Errors during hibernation with reenlightenment notifications enabled were
> reported:
>
> [ 51.730435] PM: hibernation entry
> [ 51.737435] PM: Syncing filesystems ...
> ...
> [ 54.102216] Disabling non-boot CPUs ...
>
On 5/13/2020 12:01 AM, Vitaly Kuznetsov wrote:
Errors during hibernation with reenlightenment notifications enabled were
reported:
[ 51.730435] PM: hibernation entry
[ 51.737435] PM: Syncing filesystems ...
...
[ 54.102216] Disabling non-boot CPUs ...
[ 54.106633] smpboot: CPU
> From: Vitaly Kuznetsov
> Sent: Tuesday, May 12, 2020 9:02 AM
> To: linux-hyp...@vger.kernel.org
> Cc: Wei Liu ; x...@kernel.org;
> linux-kernel@vger.kernel.org; k...@vger.kernel.org; Michael Kelley
> ; Dexuan Cui ; Tianyu Lan
>
> Subject: [PATCH] x86/hyperv:
Errors during hibernation with reenlightenment notifications enabled were
reported:
[ 51.730435] PM: hibernation entry
[ 51.737435] PM: Syncing filesystems ...
...
[ 54.102216] Disabling non-boot CPUs ...
[ 54.106633] smpboot: CPU 1 is now offline
[ 54.110006] unchecked MSR access
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be h
From: Nick Dyer
This patch reports failures in suspend/resume
Signed-off-by: Nick Dyer
(cherry picked from ndyer/linux/for-upstream commit 93a57575403d)
[gdavis: Resolve forward port conflicts due to applying upstream
commit 96a938aa214e ("Input: atmel_mxt_ts - remove pla
On 06/05/2020 at 22:18, Jakub Kicinski wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
On Wed, 6 May 2020 13:37:37 +0200 nicolas.fe...@microchip.com wrote:
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
a
On Wed, 6 May 2020 13:37:37 +0200 nicolas.fe...@microchip.com wrote:
> From: Nicolas Ferre
>
> Use the proper struct device pointer to check if the wakeup flag
> and wakeup source are positioned.
> Use the one passed by function call which is equivalent to
> &bp->dev->dev.parent.
>
> It's preven
On Fri, Apr 17, 2020 at 07:05:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> When the XUDC device is idle (i.e. powergated), care must be taken not
> to access any registers because that would lead to a crash.
>
> Move the call to tegra_xudc_device_mode_off() into the same conditio
From: Nicolas Ferre
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Signed-o
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
&bp->dev->dev.parent.
It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.
Fi
there is any active L2 guest.
Fixes: 05bd330a7fd8 ("x86/hyperv: Suspend/resume the hypercall page for
hibernation")
Cc: sta...@vger.kernel.org
Signed-off-by: Dexuan Cui
Link:
https://lore.kernel.org/r/1587437171-2472-1-git-send-email-de...@microsoft.com
Signed-off-by: Wei Liu
Signed-off-
From: Nicolas Ferre
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Cc: Clau
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
&bp->dev->dev.parent.
It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.
Fi
From: Shengjiu Wang
commit 1e060a453c8604311fb45ae2f84f67ed673329b4 upstream.
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock rate
From: Krzysztof Kozlowski
commit ec21bdc6dd16d74b3674ef1fd12ae8e4e7418603 upstream.
Commit 450312b640f9 ("ASoC: soc-core: remove DAI suspend/resume")
removed the DAI side suspend/resume hooks and switched entirely to
component suspend/resume. However the Samsung SoC s3c-i2s-v2 driv
From: Shengjiu Wang
commit 1e060a453c8604311fb45ae2f84f67ed673329b4 upstream.
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock rate
From: Shengjiu Wang
commit 1e060a453c8604311fb45ae2f84f67ed673329b4 upstream.
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock rate
From: Shengjiu Wang
[ Upstream commit 1e060a453c8604311fb45ae2f84f67ed673329b4 ]
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock
From: Shengjiu Wang
[ Upstream commit 1e060a453c8604311fb45ae2f84f67ed673329b4 ]
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock
From: Shengjiu Wang
[ Upstream commit 1e060a453c8604311fb45ae2f84f67ed673329b4 ]
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock
From: Krzysztof Kozlowski
[ Upstream commit ec21bdc6dd16d74b3674ef1fd12ae8e4e7418603 ]
Commit 450312b640f9 ("ASoC: soc-core: remove DAI suspend/resume")
removed the DAI side suspend/resume hooks and switched entirely to
component suspend/resume. However the Samsung SoC s3c-i2s-v2
From: Biao Huang
Date: Tue, 15 Oct 2019 11:24:44 +0800
> disable ptp_ref_clk in suspend flow, and enable it in resume flow.
>
> Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and
> stmmac_rst to platform structure")
> Signed-off-by: Biao Huang
Applied and queued up for -stab
disable ptp_ref_clk in suspend flow, and enable it in resume flow.
Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst
to platform structure")
Signed-off-by: Biao Huang
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12
1 file changed, 8 inserti
changes in v2:
1. add Fixes in commit message
2. replace clk_disable/clk_enable with
clk_disable_unprepare/clk_prepare_enable
to ensure the source pll can be closed/open in suspend/resume for power
saving.
Biao Huang (1):
net: stmmac: disable/enable ptp_ref_clk in
On 09/10/2019 11:35, michael@mediatek.com wrote:
> From: Louis Yu
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
> Si
Appreciate your comments!
On Thu, 2019-10-10 at 16:01 -0700, Jakub Kicinski wrote:
> On Wed, 9 Oct 2019 16:56:49 +0800, Biao Huang wrote:
> > disable ptp_ref_clk in suspend flow, and enable it in resume flow.
> >
> > Signed-off-by: Biao Huang
> > ---
> > drivers/net/ethernet/stmicro/stmmac/stmm
On Wed, 9 Oct 2019 16:56:49 +0800, Biao Huang wrote:
> disable ptp_ref_clk in suspend flow, and enable it in resume flow.
>
> Signed-off-by: Biao Huang
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/stm
From: Louis Yu
Add suspend/resume callback to disable/enable Mediatek thermal sensor
respectively. Since thermal power domain is off in suspend, thermal driver
needs re-initialization during resume.
Signed-off-by: Louis Yu
Signed-off-by: Michael Kao
---
This patch series base on these patches
disable ptp_ref_clk in suspend flow, and enable it in resume flow.
Signed-off-by: Biao Huang
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmm
ated with the private mutex
> held already, which causes a deadlock during suspend.
>
> Fix this by moving the phylink configuration updates out of the region
> of code protected by the private mutex.
>
> Fixes: 19e13cb27b99 ("net: stmmac: Hold rtnl lock in suspend/resume
x this by moving the phylink configuration updates out of the region
of code protected by the private mutex.
Fixes: 19e13cb27b99 ("net: stmmac: Hold rtnl lock in suspend/resume callbacks")
Suggested-by: Bitan Biswas
Signed-off-by: Thierry Reding
---
drivers/net/ethernet/stmicro/stmmac/st
> From: Vitaly Kuznetsov
> Sent: Friday, September 27, 2019 2:05 AM
> To: Dexuan Cui
>
> Dexuan Cui writes:
> ...
> > So, I'm pretty sure no IPI can happen between hv_suspend() and
> hv_resume().
> > self-IPI is not supposed to happen either, since interrupts are disabled.
> >
> > IMO TLB flush
Dexuan Cui writes:
>> From: Vitaly Kuznetsov
>> Sent: Thursday, September 26, 2019 3:44 AM
>> > [...]
>> > +static int hv_suspend(void)
>> > +{
>> > + union hv_x64_msr_hypercall_contents hypercall_msr;
>> > +
>> > + /* Reset the hypercall page */
>> > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_
> From: Vitaly Kuznetsov
> Sent: Thursday, September 26, 2019 3:44 AM
> > [...]
> > +static int hv_suspend(void)
> > +{
> > + union hv_x64_msr_hypercall_contents hypercall_msr;
> > +
> > + /* Reset the hypercall page */
> > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > + hyp
> From: Daniel Lezcano
> Sent: Thursday, September 26, 2019 6:17 AM
> >>
> >> I can take this patch if needed.
> >
> > Thanks, Daniel! Usually tglx takes care of the patches, but it looks
> > recently he
> > may be too busy to handle the 3 patches.
> >
> > I guess you can take the patch, if tglx
el@vger.kernel.org; mi...@redhat.com; sas...@kernel.org; Stephen
>> Hemminger ; t...@linutronix.de; x...@kernel.org;
>> Michael Kelley ; Sasha Levin
>>
>> Cc: linux-a...@vger.kernel.org
>> Subject: Re: [PATCH v5 3/3] clocksource/drivers: Suspend/resume Hyper-V
>>
Dexuan Cui writes:
> This is needed for hibernation, e.g. when we resume the old kernel, we need
> to disable the "current" kernel's hypercall page and then resume the old
> kernel's.
>
> Signed-off-by: Dexuan Cui
> Reviewed-by: Michael Kelley
> ---
> arch/x86/hyperv/hv_init.c | 33 +++
en
> Hemminger ; t...@linutronix.de; x...@kernel.org;
> Michael Kelley ; Sasha Levin
>
> Cc: linux-a...@vger.kernel.org
> Subject: Re: [PATCH v5 3/3] clocksource/drivers: Suspend/resume Hyper-V
> clocksource for hibernation
>
> On 06/09/2019 00:47, Dexuan Cui wrote:
> &
On 06/09/2019 00:47, Dexuan Cui wrote:
> This is needed for hibernation, e.g. when we resume the old kernel, we need
> to disable the "current" kernel's TSC page and then resume the old kernel's.
>
> Signed-off-by: Dexuan Cui
> Reviewed-by: Michael Kelley
I can take this patch if needed.
> ---
On Tue 17 Sep 2019 at 10:12, Jose Abreu wrote:
> From: Loys Ollivier
> Date: Sep/17/2019, 11:02:36 (UTC+00:00)
>
>> rtnl_lock needs to be taken before calling phylink_start/stop to lock the
>> network stack.
>> Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
>>
>> Fixes: 7
brcmfmac assumed the wifi device always remains powered on and thus
hardcoded the MMC_PM_KEEP_POWER flag expecting the wifi device to
remain on even during suspend/resume cycles.
This is not always the case, some appliances cut power to everything
connected via SDIO for efficiency reasons and
From: Jose Abreu
[ Upstream commit 19e13cb27b998ff49f07e399b5871bfe5ba7e3f0 ]
We need to hold rnl lock in suspend and resume callbacks because phylink
requires it. Otherwise we will get a WARN() in suspend and resume.
Also, move phylink start and stop callbacks to inside device's internal
lock
Add suspend and resume hooks used to refresh the CPU clock tree
when resuming from suspend, in the case where the PSCI firmware
alters the clock tree.
In the Amlogic G12A suspend/resume case, the PSCI firmware will
alter the Fixed PLL dyn tree when entering with the CPU clock from
this same tree
From: Loys Ollivier
Date: Sep/17/2019, 11:02:36 (UTC+00:00)
> rtnl_lock needs to be taken before calling phylink_start/stop to lock the
> network stack.
> Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
>
> Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove ph
rtnl_lock needs to be taken before calling phylink_start/stop to lock the
network stack.
Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Loys Ollivier
---
drivers/net/ethernet/stm
From: Nick Dyer
(cherry picked from ndyer/linux/for-upstream commit
93a57575403de4dd07cd64807d3c2ed7f2cca262)
[gdavis: Resolve forward port conflicts due to applying upstream
commit 96a938aa214e ("Input: atmel_mxt_ts - remove platform
data support").]
Signed-off-by: George G. D
From: Jose Abreu
Date: Fri, 13 Sep 2019 11:50:32 +0200
> We need to hold rnl lock in suspend and resume callbacks because phylink
> requires it. Otherwise we will get a WARN() in suspend and resume.
>
> Also, move phylink start and stop callbacks to inside device's internal
> lock so that we pre
We need to hold rnl lock in suspend and resume callbacks because phylink
requires it. Otherwise we will get a WARN() in suspend and resume.
Also, move phylink start and stop callbacks to inside device's internal
lock so that we prevent concurrent HW accesses.
Fixes: 74371272f97f ("net: stmmac: Co
Hi,
On Sun, Sep 8, 2019 at 3:12 AM Ulf Hansson wrote:
>
> System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
> MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
> behaviour. Some problems have been taken care of so far, but more issu
System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
behaviour. Some problems have been taken care of so far, but more issues
remains.
For example, calling the ->ack_sdio_irq() callback to let h
On Fri, 6 Sep 2019 at 01:48, Doug Anderson wrote:
>
> Hi,
>
> On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson wrote:
> >
> > System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
> > MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from
On Thu, 5 Sep 2019 at 20:43, Matthias Kaehlcke wrote:
>
> On Tue, Sep 03, 2019 at 04:22:04PM +0200, Ulf Hansson wrote:
> > System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
> > MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
&
Hi,
On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson wrote:
>
> System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
> MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
> behaviour. Some problems have been taken care of so far, but more issu
The high-level VSC drivers will implement device-specific callbacks.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
drivers/hv/vmbus_drv.c | 46 ++
include/linux/hyperv.h | 3 +++
2 files changed, 49 insertions(+)
diff --git a/drivers/hv/
Before Linux enters hibernation, it sends the CHANNELMSG_UNLOAD message to
the host so all the offers are gone. After hibernation, Linux needs to
re-negotiate with the host using the same vmbus protocol version (which
was in use before hibernation), and ask the host to re-offer the vmbus
devices.
This is needed when we resume the old kernel from the "current" kernel.
Note: when hv_synic_suspend() and hv_synic_resume() run, all the
non-boot CPUs have been offlined, and interrupts are disabled on CPU0.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
drivers/hv/vmbus_drv.c | 46
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's TSC page and then resume the old kernel's.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
drivers/clocksource/hyperv_timer.c | 25 +
1 file changed, 2
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's hypercall page and then resume the old
kernel's.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
arch/x86/hyperv/hv_init.c | 33 +
1 file chang
> From: Sasha Levin
> Sent: Thursday, September 5, 2019 8:44 AM
> On Tue, Sep 03, 2019 at 12:23:16AM +, Dexuan Cui wrote:
> >This is needed for hibernation, e.g. when we resume the old kernel, we need
> >to disable the "current" kernel's hypercall page and then resume the old
> >kernel's.
>
>
On Tue, Sep 03, 2019 at 04:22:04PM +0200, Ulf Hansson wrote:
> System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
> MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
> behaviour. Some problems have been taken care of so far, but more issues
On Tue, Sep 03, 2019 at 12:23:16AM +, Dexuan Cui wrote:
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's hypercall page and then resume the old
kernel's.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Hi Dexuan,
When se
From: Gary R Hook
commit 5871cd93692c8071fb9358daccb715b5081316ac upstream.
If a CCP is unconfigured (e.g. there are no available queues) then
there will be no data structures allocated for the device. Thus, we
must check for validity of a pointer before trying to access structure
members.
Fixe
From: Gary R Hook
commit 5871cd93692c8071fb9358daccb715b5081316ac upstream.
If a CCP is unconfigured (e.g. there are no available queues) then
there will be no data structures allocated for the device. Thus, we
must check for validity of a pointer before trying to access structure
members.
Fixe
From: Gary R Hook
commit 5871cd93692c8071fb9358daccb715b5081316ac upstream.
If a CCP is unconfigured (e.g. there are no available queues) then
there will be no data structures allocated for the device. Thus, we
must check for validity of a pointer before trying to access structure
members.
Fixe
_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
and the quirk mechanism ensures that, once resumed from suspend,
the MSRs indicated by these IDs will be restored to their
original, pre-suspend values.
Since both 64-bit and 32-bit kernels are affected, this patch
covers the common 64/32-bit suspend/resume code
System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
behaviour. Some problems have been taken care of so far, but more issues
remains.
For example, calling the ->ack_sdio_irq() callback to let h
The high-level VSC drivers will implement device-specific callbacks.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
drivers/hv/vmbus_drv.c | 46 ++
include/linux/hyperv.h | 3 +++
2 files changed, 49 insertions(+)
diff --git a/drivers/hv/
This is needed when we resume the old kernel from the "current" kernel.
Note: when hv_synic_suspend() and hv_synic_resume() run, all the
non-boot CPUs have been offlined, and interrupts are disabled on CPU0.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
drivers/hv/vmbus_drv.c | 46
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's TSC page and then resume the old kernel's.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
drivers/clocksource/hyperv_timer.c | 25 +
1 file changed, 2
Before Linux enters hibernation, it sends the CHANNELMSG_UNLOAD message to
the host so all the offers are gone. After hibernation, Linux needs to
re-negotiate with the host using the same vmbus protocol version (which
was in use before hibernation), and ask the host to re-offer the vmbus
devices.
This is needed for hibernation, e.g. when we resume the old kernel, we need
to disable the "current" kernel's hypercall page and then resume the old
kernel's.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
---
arch/x86/hyperv/hv_init.c | 34 ++
1 file chan
On Tue, 2019-08-27 at 18:13 -0400, Shengjiu Wang wrote:
> Use force_suspend/resume to make sure clocks are disabled/enabled
> accordingly during system suspend/resume.
>
> Signed-off-by: Dong Aisheng
> Signed-off-by: Shengjiu Wang
Reviewed-by: Daniel Baluta
> ---
> sou
401 - 500 of 2929 matches
Mail list logo
