- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] [PATCH v2] drm/i915: Move init_clock_gating() back to where it was

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: stable(a)vger.kernel.org Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Oscar Mateo <oscar.mateo(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Reported-by: Mark Janes <mark.a.janes(a)intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++-- drivers/gpu/drm/i915/intel_pm.c | 44 +++++++++++++++--------------------- 2 files changed, 30 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 737de251d0f8..8174392acc18 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3676,6 +3676,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv) intel_pps_unlock_regs_wa(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup) @@ -14365,8 +14366,6 @@ void intel_modeset_init_hw(struct drm_device *dev) intel_update_cdclk(dev_priv); intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK"); dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw; - - intel_init_clock_gating(dev_priv); } /* @@ -15079,6 +15078,15 @@ intel_modeset_setup_hw_state(struct drm_device *dev, struct intel_encoder *encoder; int i; + if (IS_HASWELL(dev_priv)) { + /* + * WaRsPkgCStateDisplayPMReq:hsw + * System hang if this isn't done before disabling all planes! + */ + I915_WRITE(CHICKEN_PAR1_1, + I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); + } + intel_modeset_readout_hw_state(dev); /* HW state is read out, now we need to sanitize this mess. */ @@ -15176,6 +15184,8 @@ void intel_modeset_gem_init(struct drm_device *dev) intel_init_gt_powersave(dev_priv); + intel_init_clock_gating(dev_priv); + intel_setup_overlay(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 07118c0b69d3..b712ee30a06c 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5754,12 +5754,30 @@ void vlv_wm_sanitize(struct drm_i915_private *dev_priv) mutex_unlock(&dev_priv->wm.wm_mutex); } +/* + * FIXME should probably kill this and improve + * the real watermark readout/sanitation instead + */ +static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) +{ + I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); + + /* + * Don't touch WM1S_LP_EN here. + * Doing so could cause underruns. + */ +} + void ilk_wm_get_hw_state(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); struct ilk_wm_values *hw = &dev_priv->wm.hw; struct drm_crtc *crtc; + ilk_init_lp_watermarks(dev_priv); + for_each_crtc(dev, crtc) ilk_pipe_wm_get_hw_state(crtc); @@ -8213,18 +8231,6 @@ static void g4x_disable_trickle_feed(struct drm_i915_private *dev_priv) } } -static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) -{ - I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); - - /* - * Don't touch WM1S_LP_EN here. - * Doing so could cause underruns. - */ -} - static void ilk_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; @@ -8258,8 +8264,6 @@ static void ilk_init_clock_gating(struct drm_i915_private *dev_priv) (I915_READ(DISP_ARB_CTL) | DISP_FBC_WM_DIS)); - ilk_init_lp_watermarks(dev_priv); - /* * Based on the document from hardware guys the following bits * should be set unconditionally in order to enable FBC. @@ -8372,8 +8376,6 @@ static void gen6_init_clock_gating(struct drm_i915_private *dev_priv) I915_WRITE(GEN6_GT_MODE, _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4)); - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB)); @@ -8600,8 +8602,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv) I915_GTT_PAGE_SIZE_2M); enum pipe pipe; - ilk_init_lp_watermarks(dev_priv); - /* WaSwitchSolVfFArbitrationPriority:bdw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); @@ -8652,8 +8652,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv) static void hsw_init_clock_gating(struct drm_i915_private *dev_priv) { - ilk_init_lp_watermarks(dev_priv); - /* L3 caching of data atomics doesn't work -- disable it. */ I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE); I915_WRITE(HSW_ROW_CHICKEN3, @@ -8697,10 +8695,6 @@ static void hsw_init_clock_gating(struct drm_i915_private *dev_priv) /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); - /* WaRsPkgCStateDisplayPMReq:hsw */ - I915_WRITE(CHICKEN_PAR1_1, - I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); - lpt_init_clock_gating(dev_priv); } @@ -8708,8 +8702,6 @@ static void ivb_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t snpcr; - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE); /* WaDisableEarlyCull:ivb */ -- 2.13.6

6 years, 12 months

3
3
0 0

[Linux-stable-mirror] [PATCH 2/3] ASoC: sun8i-codec: Set the BCLK divider

by Maxime Ripard

While the current code was reporting to be able to work in master mode, it failed to do so because the BCLK divider wasn't programmed, meaning that the BCLK would run at the PLL's frequency no matter the sample rate. It was obviously a bit too fast. Add support to retrieve the divider to use, and set it. Since our PLL is not always able to generate a perfect multiple of the sample rate, we'll have to choose the closest divider that matches our setup. Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> --- sound/soc/sunxi/sun8i-codec.c | 53 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index 038107baf414..522546e6b153 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -73,6 +73,7 @@ #define SUN8I_SYS_SR_CTRL_AIF2_FS_MASK GENMASK(11, 8) #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK GENMASK(5, 4) #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK GENMASK(8, 6) +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK GENMASK(12, 9) struct sun8i_codec { struct device *dev; @@ -226,12 +227,57 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) return 0; } +struct sun8i_codec_clk_div { + u8 div; + u8 val; +}; + +static const struct sun8i_codec_clk_div sun8i_codec_bclk_div[] = { + { .div = 1, .val = 0 }, + { .div = 2, .val = 1 }, + { .div = 4, .val = 2 }, + { .div = 6, .val = 3 }, + { .div = 8, .val = 4 }, + { .div = 12, .val = 5 }, + { .div = 16, .val = 6 }, + { .div = 24, .val = 7 }, + { .div = 32, .val = 8 }, + { .div = 48, .val = 9 }, + { .div = 64, .val = 10 }, + { .div = 96, .val = 11 }, + { .div = 128, .val = 12 }, + { .div = 192, .val = 13 }, +}; + +static u8 sun8i_codec_get_bclk_div(struct sun8i_codec *scodec, + unsigned int rate, + unsigned int word_size) +{ + unsigned long clk_rate = clk_get_rate(scodec->clk_module); + unsigned int div = clk_rate / rate / word_size / 2; + unsigned int best_val = 0, best_diff = ~0; + int i; + + for (i = 0; i < ARRAY_SIZE(sun8i_codec_bclk_div); i++) { + const struct sun8i_codec_clk_div *bdiv = &sun8i_codec_bclk_div[i]; + unsigned int diff = abs(bdiv->div - div); + + if (diff < best_diff) { + best_diff = diff; + best_val = bdiv->val; + } + } + + return best_val; +} + static int sun8i_codec_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) { struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec); int sample_rate; + u8 bclk_div; /* * The CPU DAI handles only a sample of 16 bits. Configure the @@ -241,6 +287,13 @@ static int sun8i_codec_hw_params(struct snd_pcm_substream *substream, SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK, SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16); + bclk_div = sun8i_codec_get_bclk_div(scodec, params_rate(params), + params_width(params)); + + regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, + SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK, + bclk_div << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV); + regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK, SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16); -- 2.14.3

6 years, 12 months

2
1
0 0

[Linux-stable-mirror] v4.13.12 build: 0 failures 0 warnings (v4.13.12)

by Build bot for Mark Brown

Tree/Branch: v4.13.12 Git describe: v4.13.12 Commit: 0da74753f7 Linux 4.13.12 Build Time: 92 min 4 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Apparently some sinks look at the YQ bits even when receiving RGB, and they get somehow confused when they see a non-zero YQ value. So we can't just blindly follow CEA-861-F and set YQ to match the RGB range. Unfortunately there is no good way to tell whether the sink designer claims to have read CEA-861-F. The CEA extension block revision number has generally been stuck at 3 since forever, and even a very recently manufactured sink might be based on an old design so the manufacturing date doesn't seem like something we can use. In lieu of better information let's follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. The alternative would of course be to always set YQ=0. And if we ever encounter a HDMI 2.0+ sink with this bug that's what we'll probably have to do. Cc: stable(a)vger.kernel.org Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Eric Anholt <eric(a)anholt.net> Cc: Neil Kownacki <njkkow(a)gmail.com> Reported-by: Neil Kownacki <njkkow(a)gmail.com> Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639 Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_edid.c | 12 ++++++++++-- drivers/gpu/drm/i915/intel_hdmi.c | 3 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++- include/drm/drm_edid.h | 3 ++- 4 files changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 749d07a01772..8567890f47a7 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4838,7 +4838,8 @@ void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, enum hdmi_quantization_range rgb_quant_range, - bool rgb_quant_range_selectable) + bool rgb_quant_range_selectable, + bool is_hdmi2_sink) { /* * CEA-861: @@ -4862,8 +4863,15 @@ drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, * YQ-field to match the RGB Quantization Range being transmitted * (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, * set YQ=1) and the Sink shall ignore the YQ-field." + * + * Unfortunate certain sinks (eg. VIZ Model 67/E261VA) get confused + * by non-zero YQ when receiving RGB. There doesn't seem to be any + * good way to tell which version of CEA-861 the sink supports, so + * we limit non-zero YQ to HDMI 2.0 sinks only as HDMI 2.0 is based + * on on CEA-861-F. */ - if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) + if (!is_hdmi2_sink || + rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) frame->ycc_quantization_range = HDMI_YCC_QUANTIZATION_RANGE_LIMITED; else diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index fa1c793a21ef..2b23d3662eec 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -487,7 +487,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : HDMI_QUANTIZATION_RANGE_FULL, - intel_hdmi->rgb_quant_range_selectable); + intel_hdmi->rgb_quant_range_selectable, + is_hdmi2_sink); /* TODO: handle pixel repetition for YCBCR420 outputs */ intel_write_infoframe(encoder, crtc_state, &frame); diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 9a9a6b4acccf..d645df0c6d15 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -423,7 +423,8 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder) vc4_encoder->limited_rgb_range ? HDMI_QUANTIZATION_RANGE_LIMITED : HDMI_QUANTIZATION_RANGE_FULL, - vc4_encoder->rgb_range_selectable); + vc4_encoder->rgb_range_selectable, + false); vc4_hdmi_write_infoframe(encoder, &frame); } diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 9e4e23524840..58ffb68efdc5 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -361,7 +361,8 @@ void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, enum hdmi_quantization_range rgb_quant_range, - bool rgb_quant_range_selectable); + bool rgb_quant_range_selectable, + bool is_hdmi2_sink); /** * drm_eld_mnl - Get ELD monitor name length in bytes. -- 2.13.6

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2 1/2] alpha: osf_sys.c: fix put_tv32 regression

by Arnd Bergmann

There was a typo in the new version of put_tv32() that caused an unguarded access of a user space pointer, and failed to return the correct result in gettimeofday(), wait4(), usleep_thread() and old_adjtimex(). This fixes it to give the correct behavior again. Cc: stable(a)vger.kernel.org Fixes: 1cc6c4635e9f ("osf_sys.c: switch handling of timeval32/itimerval32 to copy_{to,from}_user()") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- v2: fix incorrect changelog description --- arch/alpha/kernel/osf_sys.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c index ce3a675c0c4b..75a5c35a2067 100644 --- a/arch/alpha/kernel/osf_sys.c +++ b/arch/alpha/kernel/osf_sys.c @@ -964,8 +964,8 @@ static inline long put_tv32(struct timeval32 __user *o, struct timeval *i) { return copy_to_user(o, &(struct timeval32){ - .tv_sec = o->tv_sec, - .tv_usec = o->tv_usec}, + .tv_sec = i->tv_sec, + .tv_usec = i->tv_usec}, sizeof(struct timeval32)); } -- 2.9.0

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] [PATCH] schedutil: Reset cached freq if it is not in sync with next_freq

by Viresh Kumar

'cached_raw_freq' is used to get the next frequency quickly but should always be in sync with sg_policy->next_freq. There is a case where it is not and in such cases it should be reset to avoid switching to incorrect frequencies. Consider this case for example: - policy->cur is 1.2 GHz (Max) - New request comes for 780 MHz and we store that in cached_raw_freq. - Based on 780 MHz, we calculate the effective frequency as 800 MHz. - We then see the CPU wasn't idle recently and choose to keep the next freq as 1.2 GHz. - Now we have cached_raw_freq is 780 MHz and sg_policy->next_freq is 1.2 GHz. - Now if the utilization doesn't change in then next request, then the next target frequency will still be 780 MHz and it will match with cached_raw_freq. But we will choose 1.2 GHz instead of 800 MHz here. Change-Id: I71bd31a1b59d27c26c0b4885301e4ba6155c2c51 Cc: <stable(a)vger.kernel.org> # 4.12 Fixes: b7eaf1aab9f8 ("cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely") Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- kernel/sched/cpufreq_schedutil.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index ba0da243fdd8..2f52ec0f1539 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -282,8 +282,12 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, * Do not reduce the frequency if the CPU has not been idle * recently, as the reduction is likely to be premature then. */ - if (busy && next_f < sg_policy->next_freq) + if (busy && next_f < sg_policy->next_freq) { next_f = sg_policy->next_freq; + + /* Reset cached freq as next_freq has changed */ + sg_policy->cached_raw_freq = 0; + } } sugov_update_commit(sg_policy, time, next_f); } -- 2.15.0.rc1.236.g92ea95045093

6 years, 12 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

by Rafael J. Wysocki

On Wed, Nov 8, 2017 at 12:06 AM, Rafael J. Wysocki <rjw(a)rjwysocki.net> wrote: > On Tuesday, November 7, 2017 11:47:54 PM CET Rafael J. Wysocki wrote: >> On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala >> <ville.syrjala(a)linux.intel.com> wrote: >> > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> >> > >> > acpi_remove_pm_notifier() ends up calling flush_workqueue() while >> > holding acpi_pm_notifier_lock, and that same lock is taken by >> > by the work via acpi_pm_notify_handler(). This can deadlock. >> >> OK, good catch! >> >> [cut] >> >> > >> > Cc: stable(a)vger.kernel.org >> > Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> >> > Cc: Len Brown <lenb(a)kernel.org> >> > Cc: Peter Zijlstra <peterz(a)infradead.org> >> > Cc: Tejun Heo <tj(a)kernel.org> >> > Cc: Ingo Molnar <mingo(a)kernel.org> >> > Fixes: c072530f391e ("ACPI / PM: Revork the handling of ACPI device wakeup notifications") >> > Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> >> > --- >> > drivers/acpi/device_pm.c | 21 ++++++++++++--------- >> > 1 file changed, 12 insertions(+), 9 deletions(-) >> > >> > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c >> > index fbcc73f7a099..18af71057b44 100644 >> > --- a/drivers/acpi/device_pm.c >> > +++ b/drivers/acpi/device_pm.c >> > @@ -387,6 +387,7 @@ EXPORT_SYMBOL(acpi_bus_power_manageable); >> > >> > #ifdef CONFIG_PM >> > static DEFINE_MUTEX(acpi_pm_notifier_lock); >> > +static DEFINE_MUTEX(acpi_pm_notifier_install_lock); >> > >> > void acpi_pm_wakeup_event(struct device *dev) >> > { >> > @@ -443,24 +444,25 @@ acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev, >> > if (!dev && !func) >> > return AE_BAD_PARAMETER; >> > >> > - mutex_lock(&acpi_pm_notifier_lock); >> > + mutex_lock(&acpi_pm_notifier_install_lock); >> > >> > if (adev->wakeup.flags.notifier_present) >> > goto out; >> > >> > - adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); >> > - adev->wakeup.context.dev = dev; >> > - adev->wakeup.context.func = func; >> > - >> >> But this doesn't look good to me. >> >> notifier_present should be checked under acpi_pm_notifier_lock. >> >> Actually, acpi_install_notify_handler() itself need not be called >> under the lock, because it does sufficient checks of its own. >> >> So say you do >> >> mutex_lock(&acpi_pm_notifier_lock); >> >> if (adev->wakeup.context.dev) >> goto out; >> >> adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); >> adev->wakeup.context.dev = dev; >> adev->wakeup.context.func = func; >> >> mutex_unlock(&acpi_pm_notifier_lock); >> >> > status = acpi_install_notify_handler(adev->handle, ACPI_SYSTEM_NOTIFY, >> > acpi_pm_notify_handler, NULL); >> > if (ACPI_FAILURE(status)) >> > goto out; >> > >> > + mutex_lock(&acpi_pm_notifier_lock); >> >> And here you just set notifier_present under acpi_pm_notifier_lock. >> >> > + adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); >> > + adev->wakeup.context.dev = dev; >> > + adev->wakeup.context.func = func; >> > adev->wakeup.flags.notifier_present = true; >> > + mutex_unlock(&acpi_pm_notifier_lock); >> > >> > out: >> > - mutex_unlock(&acpi_pm_notifier_lock); >> > + mutex_unlock(&acpi_pm_notifier_install_lock); >> > return status; >> > } >> >> Then on removal you can clear notifier_present first and drop the lock >> around the acpi_remove_notify_handler() call and nothing bad will >> happen. >> >> If you call acpi_add_pm_notifier() twice in parallel, the first >> instance will set context.dev and the second one will see it set and >> bail out. The first instance will then do the rest. >> >> If you call acpi_remove_pm_notifier() twice in a row, the first >> instance will see notifier_present set and will clear it, so the >> second one will see notifier_present unset and it will bail out. >> >> Now, if you call acpi_remove_pm_notifier() in parallel with >> acpi_add_pm_notifier(), either the former will see notifier_present >> unset and bail out, or the latter will see context.dev unset and bail >> out. >> >> It doesn't look like the outer lock is needed, or have I missed anything? > > So something like the below (totally untested) should work too, shouldn't it? There is a problem if a device is removed while acpi_add_pm_notifier() is still in progress, in which case with my patch the acpi_remove_pm_notifier() called from the removal path may bail out prematurely (that doesn't seem likely to happen, but still I don't see why it cannot happen), so I'll just use your patch. :-) Thanks, Rafael

6 years, 12 months

3
4
0 0

Re: [Linux-stable-mirror] [1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time

by Kalle Valo

Arnd Bergmann <arnd(a)arndb.de> wrote: > We set rtlhal->last_suspend_sec to an uninitialized stack variable, > but unfortunately gcc never warned about this, I only found it > while working on another patch. I opened a gcc bug for this. > > Presumably the value of rtlhal->last_suspend_sec is not all that > important, but it does get used, so we probably want the > patch backported to stable kernels. > > Cc: stable(a)vger.kernel.org > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839 > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> > Acked-by: Larry Finger <Larry.Finger(a)lwfinger.net> 3 patches applied to wireless-drivers-next.git, thanks. 3f2a162fab15 rtlwifi: fix uninitialized rtlhal->last_suspend_sec time 3c92d5517af8 rtlwifi: use ktime_get_real_seconds() for suspend time ac978dc79a91 rtlwifi: drop unused ppsc->last_wakeup_time -- https://patchwork.kernel.org/patch/10043505/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc…

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] v3.18.80 build: 0 failures 1 warnings (v3.18.80)

by Build bot for Mark Brown

Tree/Branch: v3.18.80 Git describe: v3.18.80 Commit: 943dc0b3ef Linux 3.18.80 Build Time: 54 min 50 sec Passed: 9 / 9 (100.00 %) Failed: 0 / 9 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : x86_64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 2 ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

6 years, 12 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] ACPI / PM: Fix acpi_pm_notifier_lock vs. flush_workqueue() deadlock

by Rafael J. Wysocki

On Tue, Nov 7, 2017 at 11:47 PM, Rafael J. Wysocki <rafael(a)kernel.org> wrote: > On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala > <ville.syrjala(a)linux.intel.com> wrote: >> From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> >> >> acpi_remove_pm_notifier() ends up calling flush_workqueue() while >> holding acpi_pm_notifier_lock, and that same lock is taken by >> by the work via acpi_pm_notify_handler(). This can deadlock. > > OK, good catch! > > [cut] > >> >> Cc: stable(a)vger.kernel.org >> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> >> Cc: Len Brown <lenb(a)kernel.org> >> Cc: Peter Zijlstra <peterz(a)infradead.org> >> Cc: Tejun Heo <tj(a)kernel.org> >> Cc: Ingo Molnar <mingo(a)kernel.org> >> Fixes: c072530f391e ("ACPI / PM: Revork the handling of ACPI device wakeup notifications") >> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> >> --- >> drivers/acpi/device_pm.c | 21 ++++++++++++--------- >> 1 file changed, 12 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c >> index fbcc73f7a099..18af71057b44 100644 >> --- a/drivers/acpi/device_pm.c >> +++ b/drivers/acpi/device_pm.c >> @@ -387,6 +387,7 @@ EXPORT_SYMBOL(acpi_bus_power_manageable); >> >> #ifdef CONFIG_PM >> static DEFINE_MUTEX(acpi_pm_notifier_lock); >> +static DEFINE_MUTEX(acpi_pm_notifier_install_lock); >> >> void acpi_pm_wakeup_event(struct device *dev) >> { >> @@ -443,24 +444,25 @@ acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev, >> if (!dev && !func) >> return AE_BAD_PARAMETER; >> >> - mutex_lock(&acpi_pm_notifier_lock); >> + mutex_lock(&acpi_pm_notifier_install_lock); >> >> if (adev->wakeup.flags.notifier_present) >> goto out; >> >> - adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); >> - adev->wakeup.context.dev = dev; >> - adev->wakeup.context.func = func; >> - > > But this doesn't look good to me. > > notifier_present should be checked under acpi_pm_notifier_lock. Well, not really, so the above is OK. However, I still would prefer to avoid adding the outer lock. Thanks, Rafael

6 years, 12 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror