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

[PATCH v3 1/2] cpufreq: ti-cpufreq: Fix an incorrect error return value

by Suman Anna

Commit 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when failure") has fixed a memory leak in the failure path, however the patch returned a positive value on get_cpu_device() failure instead of the previous negative value. Fix this incorrect error return value properly. Fixes: 05829d9431df ("cpufreq: ti-cpufreq: kfree opp_data when failure") Cc: Zumeng Chen <zumeng.chen(a)gmail.com> Cc: <stable(a)vger.kernel.org> # v4.14+ Signed-off-by: Suman Anna <s-anna(a)ti.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/ti-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c index 6ba709b6f095..896caba5dfe5 100644 --- a/drivers/cpufreq/ti-cpufreq.c +++ b/drivers/cpufreq/ti-cpufreq.c @@ -226,7 +226,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev) opp_data->cpu_dev = get_cpu_device(0); if (!opp_data->cpu_dev) { pr_err("%s: Failed to get device for CPU0\n", __func__); - ret = ENODEV; + ret = -ENODEV; goto free_opp_data; } -- 2.17.0

7 years, 6 months

1
0
0 0

[PATCH] MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

by Maciej W. Rozycki

Use 64-bit accesses for 64-bit floating-point general registers with PTRACE_PEEKUSR, removing the truncation of their upper halves in the FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context access"), which inadvertently switched them to using 32-bit accesses. The PTRACE_POKEUSR side is fine as it's never been broken and continues using 64-bit accesses. Cc: <stable(a)vger.kernel.org> # 3.19+ Fixes: bbd426f542cb ("MIPS: Simplify FP context access") Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> --- Hi, Here's another one, spotted in the course of GDB PR gdb/22286 regression testing with the n64 ABI. Please apply. Maciej --- arch/mips/kernel/ptrace.c | 2 +- arch/mips/kernel/ptrace32.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) linux-mips-ptrace-peekusr-fp64.diff Index: linux/arch/mips/kernel/ptrace.c =================================================================== --- linux.orig/arch/mips/kernel/ptrace.c 2018-05-15 17:44:25.000000000 +0100 +++ linux/arch/mips/kernel/ptrace.c 2018-05-16 11:22:00.714605000 +0100 @@ -1070,7 +1070,7 @@ long arch_ptrace(struct task_struct *chi break; } #endif - tmp = get_fpr32(&fregs[addr - FPR_BASE], 0); + tmp = get_fpr64(&fregs[addr - FPR_BASE], 0); break; case PC: tmp = regs->cp0_epc; Index: linux/arch/mips/kernel/ptrace32.c =================================================================== --- linux.orig/arch/mips/kernel/ptrace32.c 2018-05-15 17:45:16.000000000 +0100 +++ linux/arch/mips/kernel/ptrace32.c 2018-05-16 11:22:16.313698000 +0100 @@ -109,7 +109,7 @@ long compat_arch_ptrace(struct task_stru addr & 1); break; } - tmp = get_fpr32(&fregs[addr - FPR_BASE], 0); + tmp = get_fpr64(&fregs[addr - FPR_BASE], 0); break; case PC: tmp = regs->cp0_epc;

7 years, 6 months

3
4
0 0

[PATCH] MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests

by Maciej W. Rozycki

Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e. Status.FR) is not supported as the lone purpose of Config5.FRE is to emulate Status.FR=0 handling on FPU hardware that has Status.FR=1 hardwired[1][2]. Also we do not handle this case elsewhere, and assume throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot be set both at once for a task, leading to inconsistent behaviour if this does happen. Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear. This corresponds to modes allowed by `mips_set_personality_fp'. References: [1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32 Privileged Resource Architecture", Imagination Technologies, Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69 "Config5 Register Field Descriptions", p. 262 [2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64 Privileged Resource Architecture", Imagination Technologies, Document Number: MD00091, Revision 6.03, December 22, 2015, Table 9.72 "Config5 Register Field Descriptions", p. 288 Cc: stable(a)vger.kernel.org # 4.0+ Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> --- arch/mips/kernel/process.c | 4 ++++ 1 file changed, 4 insertions(+) linux-mips-set-process-fp-mode-fr-fre.diff Index: linux/arch/mips/kernel/process.c =================================================================== --- linux.orig/arch/mips/kernel/process.c 2018-05-12 22:52:11.000000000 +0100 +++ linux/arch/mips/kernel/process.c 2018-05-12 23:07:15.147112000 +0100 @@ -721,6 +721,10 @@ int mips_set_process_fp_mode(struct task if (value & ~known_bits) return -EOPNOTSUPP; + /* Setting FRE without FR is not supported. */ + if ((value & (PR_FP_MODE_FR | PR_FP_MODE_FRE)) == PR_FP_MODE_FRE) + return -EOPNOTSUPP; + /* Avoid inadvertently triggering emulation */ if ((value & PR_FP_MODE_FR) && raw_cpu_has_fpu && !(raw_current_cpu_data.fpu_id & MIPS_FPIR_F64))

7 years, 6 months

3
3
0 0

[PATCH 03/18] drm/amd/display: Make atomic-check validate underscan changes

by Harry Wentland

From: David Francis <David.Francis(a)amd.com> When the underscan state was changed, atomic-check was triggering a validation but passing the old underscan values. This change adds a somewhat hacky check in dm_update_crtcs_state that will update the stream if old and newunderscan values are different. This was causing 4k on Fiji to allow underscan when it wasn't permitted. Signed-off-by: David Francis <David.Francis(a)amd.com> Reviewed-by: David Francis <David.Francis(a)amd.com> Acked-by: Harry Wentland <harry.wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++++++++++++------ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 07f4793a945f..e7ecddf359da 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4679,8 +4679,8 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) { struct amdgpu_crtc *acrtc = NULL; struct amdgpu_dm_connector *aconnector = NULL; - struct drm_connector_state *new_con_state = NULL; - struct dm_connector_state *dm_conn_state = NULL; + struct drm_connector_state *drm_new_conn_state = NULL, *drm_old_conn_state = NULL; + struct dm_connector_state *dm_new_conn_state = NULL, *dm_old_conn_state = NULL; struct drm_plane_state *new_plane_state = NULL; new_stream = NULL; @@ -4701,19 +4701,24 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, /* TODO This hack should go away */ if (aconnector && enable) { // Make sure fake sink is created in plug-in scenario - new_con_state = drm_atomic_get_connector_state(state, + drm_new_conn_state = drm_atomic_get_new_connector_state(state, &aconnector->base); + drm_old_conn_state = drm_atomic_get_old_connector_state(state, + &aconnector->base); + - if (IS_ERR(new_con_state)) { - ret = PTR_ERR_OR_ZERO(new_con_state); + + if (IS_ERR(drm_new_conn_state)) { + ret = PTR_ERR_OR_ZERO(drm_new_conn_state); break; } - dm_conn_state = to_dm_connector_state(new_con_state); + dm_new_conn_state = to_dm_connector_state(drm_new_conn_state); + dm_old_conn_state = to_dm_connector_state(drm_old_conn_state); new_stream = create_stream_for_sink(aconnector, &new_crtc_state->mode, - dm_conn_state); + dm_new_conn_state); /* * we can have no stream on ACTION_SET if a display @@ -4729,7 +4734,7 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, } set_freesync_on_stream(dm, dm_new_crtc_state, - dm_conn_state, new_stream); + dm_new_conn_state, new_stream); if (dc_is_stream_unchanged(new_stream, dm_old_crtc_state->stream) && dc_is_stream_scaling_unchanged(new_stream, dm_old_crtc_state->stream)) { @@ -4837,6 +4842,11 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, */ BUG_ON(dm_new_crtc_state->stream == NULL); + /* Scaling or underscan settings */ + if (is_scaling_state_different(dm_old_conn_state, dm_new_conn_state)) + update_stream_scaling_settings( + &new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream); + /* Color managment settings */ if (dm_new_crtc_state->base.color_mgmt_changed) { ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state); -- 2.17.0

7 years, 6 months

2
1
0 0

[PATCH 1/3] orangefs: set i_size on new symlink

by Martin Brandenburg

As long as a symlink inode remains in-core, the destination (and therefore size) will not be re-fetched from the server, as it cannot change. The original implementation of the attribute cache assumed that setting the expiry time in the past was sufficient to cause a re-fetch of all attributes on the next getattr. That does not work in this case. The bug manifested itself as follows. When the command sequence touch foo; ln -s foo bar; ls -l bar is run, the output was lrwxrwxrwx. 1 fedora fedora 4906 Apr 24 19:10 bar -> foo However, after a re-mount, ls -l bar produces lrwxrwxrwx. 1 fedora fedora 3 Apr 24 19:10 bar -> foo After this commit, even before a re-mount, the output is lrwxrwxrwx. 1 fedora fedora 3 Apr 24 19:10 bar -> foo Reported-by: Becky Ligon <ligon(a)clemson.edu> Signed-off-by: Martin Brandenburg <martin(a)omnibond.com> Fixes: 71680c18c8f2 ("orangefs: Cache getattr results.") Cc: stable(a)vger.kernel.org Cc: hubcap(a)omnibond.com --- fs/orangefs/namei.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/orangefs/namei.c b/fs/orangefs/namei.c index 6e3134e6d98a..bfc4b1028701 100644 --- a/fs/orangefs/namei.c +++ b/fs/orangefs/namei.c @@ -327,6 +327,13 @@ static int orangefs_symlink(struct inode *dir, ret = PTR_ERR(inode); goto out; } + /* + * This is necessary because orangefs_inode_getattr will not + * re-read symlink size as it is impossible for it to change. + * Invalidating the cache does not help. orangefs_new_inode + * does not set the correct size (it does not know symname). + */ + inode->i_size = strlen(symname); gossip_debug(GOSSIP_NAME_DEBUG, "Assigned symlink inode new number of %pU\n", -- 2.14.3

7 years, 6 months

1
1
0 0

[PATCH v2] libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk

by Hans de Goede

Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs. This has lead to several reports of users of that SSD where LPM was working fine and who know have a significantly increased idle power consumption on their laptops. Likely there is another problem on the T450s from the original reporter which gets exposed by the uncore reaching deeper sleep states (higher PC-states) due to LPM being enabled. The problem as reported, a hardfreeze about once a day, already did not sound like it would be caused by LPM and the reports of the SSD working fine confirm this. The original reporter is ok with dropping the quirk. A X250 user has reported the same hard freeze problem and for him the problem went away after unrelated updates, I suspect some GPU driver stack changes fixed things. TL;DR: The original reporters problem were triggered by LPM but not an LPM issue, so drop the quirk for the SSD in question. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207 Cc: stable(a)vger.kernel.org Cc: Richard W.M. Jones <rjones(a)redhat.com> Cc: Lorenzo Dalrio <lorenzo.dalrio(a)gmail.com> Reported-by: Lorenzo Dalrio <lorenzo.dalrio(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: -Rebase on 4.17-rc7 --- drivers/ata/libata-core.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 346b163f6e89..9bfd2f7e4542 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4557,9 +4557,6 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { { "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM, }, { "SAMSUNG SSD PM830 mSATA *", "CXM13D1Q", ATA_HORKAGE_NOLPM, }, - /* Sandisk devices which are known to not handle LPM well */ - { "SanDisk SD7UB3Q*G1001", NULL, ATA_HORKAGE_NOLPM, }, - /* devices that don't properly handle queued TRIM commands */ { "Micron_M500IT_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, -- 2.17.0

7 years, 6 months

3
3
0 0

[PATCH v8 0/5] mtd: cfi_cmdset_0002: Change write and erase functions

by Tokunori Ikegami

The changes are to make sure to check the operation status. Actually the flash write and erase error behavior is caused on our products. The flash is Macronix flash device MX29GL512FHT2I-11G used by our products. The patch series was separated for changes of flash write and erase. Since those were not depended each other at the time. But by additional changes the changes are related more as same way currently. So combine patch series for the flash write and erase changes as v6. Signed-off-by: Tokunori Ikegami <ikegami(a)allied-telesis.co.jp> Reviewed-by: Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> Cc: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Cc: Brian Norris <computersforpeace(a)gmail.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: Boris Brezillon <boris.brezillon(a)free-electrons.com> Cc: Marek Vasut <marek.vasut(a)gmail.com> Cc: Richard Weinberger <richard(a)nod.at> Cc: Cyrille Pitchen <cyrille.pitchen(a)wedev4u.fr> Cc: linux-mtd(a)lists.infradead.org Cc: stable(a)vger.kernel.org Tokunori Ikegami (5): mtd: cfi_cmdset_0002: Change write buffer to check correct value mtd: cfi_cmdset_0002: Change definition naming to retry write operation mtd: cfi_cmdset_0002: Change erase functions to retry for error mtd: cfi_cmdset_0002: Change erase functions to check chip good only mtd: cfi_cmdset_0002: Change erase one block to enable XIP once drivers/mtd/chips/cfi_cmdset_0002.c | 36 +++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-) -- 2.16.1

7 years, 6 months

2
5
0 0

[PATCH 08/18] drm/amd/display: Update color props when modeset is required

by Harry Wentland

From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com> This fixes issues where color management properties don't persist over DPMS on/off, or when the CRTC is moved across connectors. Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index b6020a83cdb0..29176d2c5d6e 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4848,8 +4848,12 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, update_stream_scaling_settings( &new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream); - /* Color managment settings */ - if (dm_new_crtc_state->base.color_mgmt_changed) { + /* + * Color management settings. We also update color properties + * when a modeset is needed, to ensure it gets reprogrammed. + */ + if (dm_new_crtc_state->base.color_mgmt_changed || + drm_atomic_crtc_needs_modeset(new_crtc_state)) { ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state); if (ret) goto fail; -- 2.17.0

7 years, 6 months

1
0
0 0

[PATCH 05/18] drm/amd/display: Fix BUG_ON during CRTC atomic check update

by Harry Wentland

From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com> For cases where the CRTC is inactive (DPMS off), where a modeset is not required, yet the CRTC is still in the atomic state, we should not attempt to update anything on it. Previously, we were relying on the modereset_required() helper to check the above condition. However, the function returns false immediatly if a modeset is not required, ignoring the CRTC's enable/active state flags. The correct way to filter is by looking at these flags instead. Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e7ecddf359da..b6020a83cdb0 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4830,15 +4830,16 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, * We want to do dc stream updates that do not require a * full modeset below. */ - if (!enable || !aconnector || modereset_required(new_crtc_state)) + if (!(enable && aconnector && new_crtc_state->enable && + new_crtc_state->active)) continue; /* * Given above conditions, the dc state cannot be NULL because: - * 1. We're attempting to enable a CRTC. Which has a... - * 2. Valid connector attached, and - * 3. User does not want to reset it (disable or mark inactive, - * which can happen on a CRTC that's already disabled). - * => It currently exists. + * 1. We're in the process of enabling CRTCs (just been added + * to the dc context, or already is on the context) + * 2. Has a valid connector attached, and + * 3. Is currently active and enabled. + * => The dc stream state currently exists. */ BUG_ON(dm_new_crtc_state->stream == NULL); -- 2.17.0

7 years, 6 months

1
0
0 0

[PATCH v4] xpad: Add GPD Win 2 Controller USB IDs

by flibitijibibo＠gmail.com

From: Ethan Lee <flibitijibibo(a)gmail.com> GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp Tested on a unit from the first production run sent to Indiegogo backers Signed-off-by: Ethan Lee <flibitijibibo(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/input/joystick/xpad.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c index 06e9650b3b30..a89b81b35932 100644 --- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -123,6 +123,7 @@ static const struct xpad_device { u8 mapping; u8 xtype; } xpad_device[] = { + { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 }, { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX }, @@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = { static const struct usb_device_id xpad_table[] = { { USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */ + XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */ XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */ XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */ XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */ -- 2.13.6

7 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror