i2c_hid_command() returns non-zero in error cases (the actual
errno). Error handling in for I2C_HID_QUIRK_RESEND_REPORT_DESCR
case in i2c_hid_resume() had the check inverted; fix that.
MAP_SYNC is a nop for device-dax. Allow MAP_SYNC to succeed on device-dax
to eliminate special casing between device-dax and fs-dax as to when the
flag can be specified. Device-dax users already implicitly assume that they do
not need to call fsync(), and this enables them to explicitly check for this
capability.
Cc: <email address hidden>
Fixes: b6fb293f2497 ("mm: Define MAP_SYNC and VM_SYNC flags")
Signed-off-by: Dave Jiang <email address hidden>
Reviewed-by: Dan Williams <email address hidden>
Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Brad Figg <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
The new support for the standard _LSR and _LSW methods neglected to also
update the nvdimm_init_config_data() and nvdimm_set_config_data() to
return the translated error code from failed commands. This precision is
necessary because the locked status that was previously returned on
ND_CMD_GET_CONFIG_SIZE commands is now returned on
ND_CMD_{GET,SET}_CONFIG_DATA commands.
If the kernel misses this indication it can inadvertently fall back to
label-less mode when it should otherwise avoid all access to locked
regions.
Cc: <email address hidden>
Fixes: 4b27db7e26cd ("acpi, nfit: add support for the _LSI, _LSR, and...")
Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Brad Figg <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356
Author: Imre Deak <email address hidden>
Date: Wed Aug 16 17:46:07 2017 +0300
drm/i915/gen9+: Set same power state before hibernation image
save/restore
during hibernation/suspend the power domain functionality got disabled,
after which resume could leave it incorrectly disabled if the ACPI
target state was S0 during suspend and i915 was not loaded by the loader
kernel.
This was caused by not considering if we resumed from hibernation as the
condition for power domains reiniting.
Fix this by simply tracking if we suspended power domains during system
suspend and reinit power domains accordingly during resume. This will
result in reiniting power domains always when resuming from hibernation,
regardless of the platform and whether or not i915 is loaded by the
loader kernel.
The reason we didn't catch this earlier is that the enabled/disabled
state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform
and kernel config dependent: on my SKL the target state is S4
during PMSG_FREEZE and (with the driver loaded in the loader kernel)
S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during
PMSG_FREEZE but (contrary to this) power domains are not initialized
during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or
it's loaded but without the DMC firmware being available.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196
Reported-and-tested-by: <email address hidden>
Fixes: dd9f31c7a388 ("drm/i915/gen9+: Set same power state before hibernation image save/restore")
Cc: <email address hidden>
Cc: Ville Syrjälä <email address hidden>
Cc: <email address hidden>
Signed-off-by: Imre Deak <email address hidden>
Reviewed-by: Ville Syrjälä <email address hidden>
Link: https://patchwork<email address hidden>
(cherry picked from commit 0f90603c33bdf6575cfdc81edd53f3f13ba166fb)
Signed-off-by: Joonas Lahtinen <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Brad Figg <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
734fce8...
by
Heiko Carstens <email address hidden>
Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to
control PWM4 or PWM5 are distinct from the other PWMs, whose wrong
programming on PWM hardware causes waveform cannot be output as expected.
Thus, the patch adds the extra condition for fixing up the weird case to
let PWM4 or PWM5 able to work on MT7623.
v1 -> v2: use pwm45_fixup naming instead of pwm45_quirk
v2 -> v3: add more tags for Reviewed-by, Fixes, and Cc stable
