From: Javier Martinez Canillas javierm@redhat.com
[ Upstream commit 94dc3471d1b2b58b3728558d0e3f264e9ce6ff59 ]
The strlen() function returns a size_t which is an unsigned int on 32-bit arches and an unsigned long on 64-bit arches. But in the drm_copy_field() function, the strlen() return value is assigned to an 'int len' variable.
Later, the len variable is passed as copy_from_user() third argument that is an unsigned long parameter as well.
In theory, this can lead to an integer overflow via type conversion. Since the assignment happens to a signed int lvalue instead of a size_t lvalue.
In practice though, that's unlikely since the values copied are set by DRM drivers and not controlled by userspace. But using a size_t for len is the correct thing to do anyways.
Signed-off-by: Javier Martinez Canillas javierm@redhat.com Tested-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Thomas Zimmermann tzimmermann@suse.de Link: https://patchwork.freedesktop.org/patch/msgid/20220705100215.572498-2-javier... Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/drm_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index ce26e8fea9c2..335fad8b209a 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -437,7 +437,7 @@ EXPORT_SYMBOL(drm_invalid_op); */ static int drm_copy_field(char __user *buf, size_t *buf_len, const char *value) { - int len; + size_t len;
/* don't overflow userbuf */ len = strlen(value);
From: Javier Martinez Canillas javierm@redhat.com
[ Upstream commit f6ee30407e883042482ad4ad30da5eaba47872ee ]
There are some struct drm_driver fields that are required by drivers since drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.
But it can be possible that a driver has a bug and did not set some of the fields, which leads to drm_copy_field() attempting to copy a NULL pointer:
[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ +0.010955] Mem abort info: [ +0.002835] ESR = 0x0000000096000004 [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits [ +0.005395] SET = 0, FnV = 0 [ +0.003113] EA = 0, S1PTW = 0 [ +0.003182] FSC = 0x04: level 0 translation fault [ +0.004964] Data abort info: [ +0.002919] ISV = 0, ISS = 0x00000004 [ +0.003886] CM = 0, WnR = 0 [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000 [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ +0.006925] Internal error: Oops: 96000004 [#1] SMP ... [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.007061] pc : __pi_strlen+0x14/0x150 [ +0.003895] lr : drm_copy_field+0x30/0x1a4 [ +0.004156] sp : ffff8000094b3a50 [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040 [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040 [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000 [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000 [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40 [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8 [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141 [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000 [ +0.007240] Call trace: [ +0.002475] __pi_strlen+0x14/0x150 [ +0.003537] drm_version+0x84/0xac [ +0.003448] drm_ioctl_kernel+0xa8/0x16c [ +0.003975] drm_ioctl+0x270/0x580 [ +0.003448] __arm64_sys_ioctl+0xb8/0xfc [ +0.003978] invoke_syscall+0x78/0x100 [ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4 [ +0.004767] do_el0_svc+0x38/0x4c [ +0.003357] el0_svc+0x34/0x100 [ +0.003185] el0t_64_sync_handler+0x11c/0x150 [ +0.004418] el0t_64_sync+0x190/0x194 [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02) [ +0.006180] ---[ end trace 0000000000000000 ]---
Reported-by: Peter Robinson pbrobinson@gmail.com Signed-off-by: Javier Martinez Canillas javierm@redhat.com Acked-by: Thomas Zimmermann tzimmermann@suse.de Link: https://patchwork.freedesktop.org/patch/msgid/20220705100215.572498-3-javier... Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/drm_ioctl.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 335fad8b209a..73dcf03e7e8c 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -439,6 +439,12 @@ static int drm_copy_field(char __user *buf, size_t *buf_len, const char *value) { size_t len;
+ /* don't attempt to copy a NULL pointer */ + if (WARN_ONCE(!value, "BUG: the value to copy was not set!")) { + *buf_len = 0; + return 0; + } + /* don't overflow userbuf */ len = strlen(value); if (len > *buf_len)
From: Mateusz Kwiatkowski kfyatek+publicgit@gmail.com
[ Upstream commit 30d7565be96b3946c18a1ce3fd538f7946839092 ]
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards.
Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively.
Signed-off-by: Mateusz Kwiatkowski kfyatek+publicgit@gmail.com Acked-by: Noralf Trønnes noralf@tronnes.org Signed-off-by: Maxime Ripard maxime@cerno.tech Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-propert... Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/vc4/vc4_vec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c index 3a9a302247a2..bcf7880f84a8 100644 --- a/drivers/gpu/drm/vc4/vc4_vec.c +++ b/drivers/gpu/drm/vc4/vc4_vec.c @@ -291,7 +291,7 @@ static void vc4_vec_ntsc_j_mode_set(struct vc4_vec *vec) static const struct drm_display_mode ntsc_mode = { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500, 720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0, - 480, 480 + 3, 480 + 3 + 3, 480 + 3 + 3 + 16, 0, + 480, 480 + 7, 480 + 7 + 6, 525, 0, DRM_MODE_FLAG_INTERLACE) };
@@ -313,7 +313,7 @@ static void vc4_vec_pal_m_mode_set(struct vc4_vec *vec) static const struct drm_display_mode pal_mode = { DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500, 720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0, - 576, 576 + 2, 576 + 2 + 3, 576 + 2 + 3 + 20, 0, + 576, 576 + 4, 576 + 4 + 6, 625, 0, DRM_MODE_FLAG_INTERLACE) };
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit c5b94f5b7819348c59f9949b2b75c341a114cdd4 ]
Some Toshibas have a broken acpi-video interface for brightness control and need a special firmware call on resume to turn the panel back on. So far these have been using the disable_backlight_sysfs_if workaround to deal with this.
The recent x86/acpi backlight refactoring has broken this workaround: 1. This workaround relies on acpi_video_get_backlight_type() returning acpi_video so that the acpi_video code actually runs; and 2. this relies on the actual native GPU driver to offer the sysfs backlight interface to userspace.
After the refactor this breaks since the native driver will no longer register its backlight-device if acpi_video_get_backlight_type() does not return native and making it return native breaks 1.
Keeping the acpi_video backlight handling on resume active, while not using it to set the brightness, is necessary because it does a _BCM call on resume which is necessary to turn the panel back on on resume.
Looking at the DSDT shows that this _BCM call results in a Toshiba HCI_SET HCI_LCD_BRIGHTNESS call, which turns the panel back on.
This kind of special vendor specific handling really belongs in the vendor specific acpi driver. An earlier patch in this series modifies toshiba_acpi to make the necessary HCI_SET call on resume on affected models.
With toshiba_acpi taking care of the HCI_SET call on resume, the acpi_video code no longer needs to call _BCM on resume.
So instead of using the (now broken) disable_backlight_sysfs_if workaround, simply setting acpi_backlight=native to disable the broken apci-video interface is sufficient fix things now.
After this there are no more users of the disable_backlight_sysfs_if flag and as discussed above the flag also no longer works as intended, so remove the disable_backlight_sysfs_if flag entirely.
Acked-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Tested-by: Arvid Norlander lkml@vorpal.se Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/acpi/acpi_video.c | 48 ------------------------------------- drivers/acpi/video_detect.c | 35 +++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 48 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 5a69260edf80..324be2a29d68 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -63,9 +63,6 @@ module_param(brightness_switch_enabled, bool, 0644); static bool allow_duplicates; module_param(allow_duplicates, bool, 0644);
-static int disable_backlight_sysfs_if = -1; -module_param(disable_backlight_sysfs_if, int, 0444); - #define REPORT_OUTPUT_KEY_EVENTS 0x01 #define REPORT_BRIGHTNESS_KEY_EVENTS 0x02 static int report_key_events = -1; @@ -397,14 +394,6 @@ static int video_set_bqc_offset(const struct dmi_system_id *d) return 0; }
-static int video_disable_backlight_sysfs_if( - const struct dmi_system_id *d) -{ - if (disable_backlight_sysfs_if == -1) - disable_backlight_sysfs_if = 1; - return 0; -} - static int video_set_device_id_scheme(const struct dmi_system_id *d) { device_id_scheme = true; @@ -477,40 +466,6 @@ static const struct dmi_system_id video_dmi_table[] = { }, },
- /* - * Some machines have a broken acpi-video interface for brightness - * control, but still need an acpi_video_device_lcd_set_level() call - * on resume to turn the backlight power on. We Enable backlight - * control on these systems, but do not register a backlight sysfs - * as brightness control does not work. - */ - { - /* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ - .callback = video_disable_backlight_sysfs_if, - .ident = "Toshiba Portege R700", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), - DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"), - }, - }, - { - /* https://bugs.freedesktop.org/show_bug.cgi?id=82634 */ - .callback = video_disable_backlight_sysfs_if, - .ident = "Toshiba Portege R830", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), - DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R830"), - }, - }, - { - /* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ - .callback = video_disable_backlight_sysfs_if, - .ident = "Toshiba Satellite R830", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), - DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE R830"), - }, - }, /* * Some machine's _DOD IDs don't have bit 31(Device ID Scheme) set * but the IDs actually follow the Device ID Scheme. @@ -1772,9 +1727,6 @@ static void acpi_video_dev_register_backlight(struct acpi_video_device *device) if (result) return;
- if (disable_backlight_sysfs_if > 0) - return; - name = kasprintf(GFP_KERNEL, "acpi_video%d", count); if (!name) return; diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 490ae990bd3c..62975cfcce68 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -447,6 +447,41 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"), }, }, + /* + * These Toshibas have a broken acpi-video interface for brightness + * control. They also have an issue where the panel is off after + * suspend until a special firmware call is made to turn it back + * on. This is handled by the toshiba_acpi kernel module, so that + * module must be enabled for these models to work correctly. + */ + { + /* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ + .callback = video_detect_force_native, + /* Toshiba Portégé R700 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"), + }, + }, + { + /* Portégé: https://bugs.freedesktop.org/show_bug.cgi?id=82634 */ + /* Satellite: https://bugzilla.kernel.org/show_bug.cgi?id=21012 */ + .callback = video_detect_force_native, + /* Toshiba Satellite/Portégé R830 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "R830"), + }, + }, + { + .callback = video_detect_force_native, + /* Toshiba Satellite/Portégé Z830 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "Z830"), + }, + }, + /* * Desktops which falsely report a backlight and which our heuristics * for this do not catch.
Hi,
On 10/10/22 01:58, Sasha Levin wrote:
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit c5b94f5b7819348c59f9949b2b75c341a114cdd4 ]
Some Toshibas have a broken acpi-video interface for brightness control and need a special firmware call on resume to turn the panel back on. So far these have been using the disable_backlight_sysfs_if workaround to deal with this.
The recent x86/acpi backlight refactoring has broken this workaround:
- This workaround relies on acpi_video_get_backlight_type() returning acpi_video so that the acpi_video code actually runs; and
- this relies on the actual native GPU driver to offer the sysfs backlight interface to userspace.
After the refactor this breaks since the native driver will no longer register its backlight-device if acpi_video_get_backlight_type() does not return native and making it return native breaks 1.
Keeping the acpi_video backlight handling on resume active, while not using it to set the brightness, is necessary because it does a _BCM call on resume which is necessary to turn the panel back on on resume.
Looking at the DSDT shows that this _BCM call results in a Toshiba HCI_SET HCI_LCD_BRIGHTNESS call, which turns the panel back on.
This kind of special vendor specific handling really belongs in the vendor specific acpi driver. An earlier patch in this series modifies toshiba_acpi to make the necessary HCI_SET call on resume on affected models.
With toshiba_acpi taking care of the HCI_SET call on resume, the acpi_video code no longer needs to call _BCM on resume.
So instead of using the (now broken) disable_backlight_sysfs_if workaround, simply setting acpi_backlight=native to disable the broken apci-video interface is sufficient fix things now.
After this there are no more users of the disable_backlight_sysfs_if flag and as discussed above the flag also no longer works as intended, so remove the disable_backlight_sysfs_if flag entirely.
Acked-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Tested-by: Arvid Norlander lkml@vorpal.se Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org
This patch goes hand in hand with:
commit 3cb1f40dfdc3 ("drivers/platform: toshiba_acpi: Call HCI_PANEL_POWER_ON on resume on some models")
and without that commit also being present it will cause a regression on the quirked Toshiba models.
This really is part of the big x86/ACPI backlight handling refactor which has landed in 6.1 and as such is not intended for older kernels, please drop this from the stable series.
Regards,
Hans
drivers/acpi/acpi_video.c | 48 ------------------------------------- drivers/acpi/video_detect.c | 35 +++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 48 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 5a69260edf80..324be2a29d68 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -63,9 +63,6 @@ module_param(brightness_switch_enabled, bool, 0644); static bool allow_duplicates; module_param(allow_duplicates, bool, 0644); -static int disable_backlight_sysfs_if = -1; -module_param(disable_backlight_sysfs_if, int, 0444);
#define REPORT_OUTPUT_KEY_EVENTS 0x01 #define REPORT_BRIGHTNESS_KEY_EVENTS 0x02 static int report_key_events = -1; @@ -397,14 +394,6 @@ static int video_set_bqc_offset(const struct dmi_system_id *d) return 0; } -static int video_disable_backlight_sysfs_if(
- const struct dmi_system_id *d)
-{
- if (disable_backlight_sysfs_if == -1)
disable_backlight_sysfs_if = 1;- return 0;
-}
static int video_set_device_id_scheme(const struct dmi_system_id *d) { device_id_scheme = true; @@ -477,40 +466,6 @@ static const struct dmi_system_id video_dmi_table[] = { }, },
- /*
* Some machines have a broken acpi-video interface for brightness* control, but still need an acpi_video_device_lcd_set_level() call* on resume to turn the backlight power on. We Enable backlight* control on these systems, but do not register a backlight sysfs* as brightness control does not work.*/- {
/* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */.callback = video_disable_backlight_sysfs_if,.ident = "Toshiba Portege R700",.matches = {DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"),},- },
- {
/* https://bugs.freedesktop.org/show_bug.cgi?id=82634 */.callback = video_disable_backlight_sysfs_if,.ident = "Toshiba Portege R830",.matches = {DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R830"),},- },
- {
/* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */.callback = video_disable_backlight_sysfs_if,.ident = "Toshiba Satellite R830",.matches = {DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE R830"),},- }, /*
- Some machine's _DOD IDs don't have bit 31(Device ID Scheme) set
- but the IDs actually follow the Device ID Scheme.
@@ -1772,9 +1727,6 @@ static void acpi_video_dev_register_backlight(struct acpi_video_device *device) if (result) return;
- if (disable_backlight_sysfs_if > 0)
return;- name = kasprintf(GFP_KERNEL, "acpi_video%d", count); if (!name) return;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 490ae990bd3c..62975cfcce68 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -447,6 +447,41 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"), }, },
- /*
* These Toshibas have a broken acpi-video interface for brightness* control. They also have an issue where the panel is off after* suspend until a special firmware call is made to turn it back* on. This is handled by the toshiba_acpi kernel module, so that* module must be enabled for these models to work correctly.*/- {
/* https://bugzilla.kernel.org/show_bug.cgi?id=21012 */.callback = video_detect_force_native,/* Toshiba Portégé R700 */.matches = {DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R700"),},- },
- {
/* Portégé: https://bugs.freedesktop.org/show_bug.cgi?id=82634 *//* Satellite: https://bugzilla.kernel.org/show_bug.cgi?id=21012 */.callback = video_detect_force_native,/* Toshiba Satellite/Portégé R830 */.matches = {DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),DMI_MATCH(DMI_PRODUCT_NAME, "R830"),},- },
- {
.callback = video_detect_force_native,/* Toshiba Satellite/Portégé Z830 */.matches = {DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),DMI_MATCH(DMI_PRODUCT_NAME, "Z830"),},- },
- /*
- Desktops which falsely report a backlight and which our heuristics
- for this do not catch.
On Mon, Oct 10, 2022 at 09:37:16AM +0200, Hans de Goede wrote:
Hi,
On 10/10/22 01:58, Sasha Levin wrote:
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit c5b94f5b7819348c59f9949b2b75c341a114cdd4 ]
Some Toshibas have a broken acpi-video interface for brightness control and need a special firmware call on resume to turn the panel back on. So far these have been using the disable_backlight_sysfs_if workaround to deal with this.
The recent x86/acpi backlight refactoring has broken this workaround:
- This workaround relies on acpi_video_get_backlight_type() returning acpi_video so that the acpi_video code actually runs; and
- this relies on the actual native GPU driver to offer the sysfs backlight interface to userspace.
After the refactor this breaks since the native driver will no longer register its backlight-device if acpi_video_get_backlight_type() does not return native and making it return native breaks 1.
Keeping the acpi_video backlight handling on resume active, while not using it to set the brightness, is necessary because it does a _BCM call on resume which is necessary to turn the panel back on on resume.
Looking at the DSDT shows that this _BCM call results in a Toshiba HCI_SET HCI_LCD_BRIGHTNESS call, which turns the panel back on.
This kind of special vendor specific handling really belongs in the vendor specific acpi driver. An earlier patch in this series modifies toshiba_acpi to make the necessary HCI_SET call on resume on affected models.
With toshiba_acpi taking care of the HCI_SET call on resume, the acpi_video code no longer needs to call _BCM on resume.
So instead of using the (now broken) disable_backlight_sysfs_if workaround, simply setting acpi_backlight=native to disable the broken apci-video interface is sufficient fix things now.
After this there are no more users of the disable_backlight_sysfs_if flag and as discussed above the flag also no longer works as intended, so remove the disable_backlight_sysfs_if flag entirely.
Acked-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Tested-by: Arvid Norlander lkml@vorpal.se Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org
This patch goes hand in hand with:
commit 3cb1f40dfdc3 ("drivers/platform: toshiba_acpi: Call HCI_PANEL_POWER_ON on resume on some models")
and without that commit also being present it will cause a regression on the quirked Toshiba models.
This really is part of the big x86/ACPI backlight handling refactor which has landed in 6.1 and as such is not intended for older kernels, please drop this from the stable series.
Will do, thanks!
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit 2a2565272a3628e45d61625e36ef17af7af4e3de ]
On a MSI S270 with Fedora 37 x86_64 / systemd-251.4 the module does not properly autoload.
This is likely caused by issues with how systemd-udevd handles the single quote char (') which is part of the sys_vendor / chassis_vendor strings on this laptop. As a workaround remove the single quote char + everything behind it from the sys_vendor + chassis_vendor matches. This fixes the module not autoloading.
Link: https://github.com/systemd/systemd/issues/24715 Signed-off-by: Hans de Goede hdegoede@redhat.com Link: https://lore.kernel.org/r/20220917210407.647432-1-hdegoede@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/platform/x86/msi-laptop.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/msi-laptop.c b/drivers/platform/x86/msi-laptop.c index d5bfcc602090..3ad6ab5d2113 100644 --- a/drivers/platform/x86/msi-laptop.c +++ b/drivers/platform/x86/msi-laptop.c @@ -609,11 +609,10 @@ static const struct dmi_system_id msi_dmi_table[] __initconst = { { .ident = "MSI S270", .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "MICRO-STAR INT'L CO.,LTD"), + DMI_MATCH(DMI_SYS_VENDOR, "MICRO-STAR INT"), DMI_MATCH(DMI_PRODUCT_NAME, "MS-1013"), DMI_MATCH(DMI_PRODUCT_VERSION, "0131"), - DMI_MATCH(DMI_CHASSIS_VENDOR, - "MICRO-STAR INT'L CO.,LTD") + DMI_MATCH(DMI_CHASSIS_VENDOR, "MICRO-STAR INT") }, .driver_data = &quirk_old_ec_model, .callback = dmi_check_cb @@ -646,8 +645,7 @@ static const struct dmi_system_id msi_dmi_table[] __initconst = { DMI_MATCH(DMI_SYS_VENDOR, "NOTEBOOK"), DMI_MATCH(DMI_PRODUCT_NAME, "SAM2000"), DMI_MATCH(DMI_PRODUCT_VERSION, "0131"), - DMI_MATCH(DMI_CHASSIS_VENDOR, - "MICRO-STAR INT'L CO.,LTD") + DMI_MATCH(DMI_CHASSIS_VENDOR, "MICRO-STAR INT") }, .driver_data = &quirk_old_ec_model, .callback = dmi_check_cb
From: hongao hongao@uniontech.com
[ Upstream commit 4bb71fce58f30df3f251118291d6b0187ce531e6 ]
This got lost somewhere along the way, This fixes audio not working until set_property was called.
Signed-off-by: hongao hongao@uniontech.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c index 0894bb98dc51..be3a384cc1cf 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c @@ -1678,10 +1678,12 @@ amdgpu_connector_add(struct amdgpu_device *adev, adev->mode_info.dither_property, AMDGPU_FMT_DITHER_DISABLE);
- if (amdgpu_audio != 0) + if (amdgpu_audio != 0) { drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.audio_property, AMDGPU_AUDIO_AUTO); + amdgpu_connector->audio = AMDGPU_AUDIO_AUTO; + }
subpixel_order = SubPixelHorizontalRGB; connector->interlace_allowed = true; @@ -1786,6 +1788,7 @@ amdgpu_connector_add(struct amdgpu_device *adev, drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.audio_property, AMDGPU_AUDIO_AUTO); + amdgpu_connector->audio = AMDGPU_AUDIO_AUTO; } drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.dither_property, @@ -1834,6 +1837,7 @@ amdgpu_connector_add(struct amdgpu_device *adev, drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.audio_property, AMDGPU_AUDIO_AUTO); + amdgpu_connector->audio = AMDGPU_AUDIO_AUTO; } drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.dither_property, @@ -1879,6 +1883,7 @@ amdgpu_connector_add(struct amdgpu_device *adev, drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.audio_property, AMDGPU_AUDIO_AUTO); + amdgpu_connector->audio = AMDGPU_AUDIO_AUTO; } drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.dither_property,
linux-stable-mirror@lists.linaro.org
-
Hans de Goede -
Sasha Levin