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

[PATCH] drm/amd/display: Disable CRTC if primary plane has no FB

by Harry Wentland

This commit teaches DM to deal with a change of behavior with drm_atomic_remove_fb. It no longer disable CRTC with NULL FB on their primary plane: (846c7dfc1193 drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.) DC/DM is currently not fully setup to simply stop scanout from the primary plane (and blank the crtc), so we'll disable the CRTC in this case. Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) 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 6f92a19bebd6..c1b1c5931a01 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4683,6 +4683,7 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, struct amdgpu_dm_connector *aconnector = NULL; struct drm_connector_state *new_con_state = NULL; struct dm_connector_state *dm_conn_state = NULL; + struct drm_plane_state *new_plane_state = NULL; new_stream = NULL; @@ -4736,6 +4737,11 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, if (dm_old_crtc_state->freesync_enabled != dm_new_crtc_state->freesync_enabled) new_crtc_state->mode_changed = true; + new_plane_state = drm_atomic_get_new_plane_state(state, new_crtc_state->crtc->primary); + + if (new_plane_state && !new_plane_state->fb) + new_crtc_state->mode_changed = true; + if (!drm_atomic_crtc_needs_modeset(new_crtc_state)) goto next_crtc; @@ -4783,6 +4789,9 @@ static int dm_update_crtcs_state(struct amdgpu_display_manager *dm, if (!aconnector || (!aconnector->dc_sink && aconnector->mst_port)) goto next_crtc; + if (new_plane_state && !new_plane_state->fb) + goto next_crtc; + if (modereset_required(new_crtc_state)) goto next_crtc; @@ -4894,7 +4903,7 @@ static int dm_update_planes_state(struct dc *dc, if (!dm_old_crtc_state->stream) continue; - DRM_DEBUG_DRIVER("Disabling DRM plane: %d on DRM crtc %d\n", + DRM_DEBUG_ATOMIC("Disabling DRM plane: %d on DRM crtc %d\n", plane->base.id, old_plane_crtc->base.id); if (!dc_remove_plane_from_context( -- 2.17.0

7 years, 8 months

1
0
0 0

kernel 4.14.x crash around fsnotify_mark_connector

by Pavlos Parissis

Hi, In one of our production servers where we run kernel version 4.14.32, I noticed the following: ---- [138630.417246] cache_from_obj: Wrong slab cache. fsnotify_mark_connector but object is from kmalloc-2048(361:anycast-healthchecker.service) [138630.477075] ------------[ cut here ]------------ [138630.500028] WARNING: CPU: 14 PID: 26002 at mm/slab.h:377 kmem_cache_free+0x133/0x1c0 [138630.538130] Modules linked in: netconsole binfmt_misc sctp_diag sctp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag cfg80211 rfkill 8021q garp mrp xfs loop x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd iTCO_wdt intel_cstate hpwdt hpilo iTCO_vendor_support sg intel_rapl_perf ipmi_si pcspkr ioatdma shpchp lpc_ich i2c_i801 ipmi_devintf dca mfd_core wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 i2c_algo_bit sd_mod drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm bnx2x serio_raw mdio libcrc32c crc32c_intel hpsa ptp drm scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod dax [138630.871763] CPU: 14 PID: 26002 Comm: kworker/u66:3 Not tainted 4.14.32-1.el7.x86_64 #1 [138630.910864] Hardware name: HP ProLiant BL460c Gen9, BIOS I36 10/25/2017 [138630.943498] Workqueue: events_unbound fsnotify_connector_destroy_workfn [138630.976569] task: ffff88203b62ae80 task.stack: ffffc90008a20000 [138631.005895] RIP: 0010:kmem_cache_free+0x133/0x1c0 [138631.029230] RSP: 0018:ffffc90008a23e20 EFLAGS: 00010246 [138631.055217] RAX: 000000000000007c RBX: ffff882000000000 RCX: 0000000000000000 [138631.091346] RDX: 0000000000000000 RSI: ffff88203f3969d8 RDI: ffff88203f3969d8 [138631.127139] RBP: ffffc90008a23e38 R08: 0000000000000001 R09: 000000000000057d [138631.162575] R10: ffff88102b906cf0 R11: ffff88102b913ea0 R12: ffff88103f579980 [138631.198018] R13: ffff88203bd57c00 R14: ffff88203bd63f00 R15: ffffffff82128388 [138631.233371] FS: 0000000000000000(0000) GS:ffff88203f380000(0000) knlGS:0000000000000000 [138631.273426] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [138631.301980] CR2: 0000000003600fd8 CR3: 000000000200a006 CR4: 00000000003606e0 [138631.338783] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [138631.374525] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [138631.409797] Call Trace: [138631.422387] fsnotify_connector_destroy_workfn+0x68/0x80 [138631.448516] process_one_work+0x15c/0x380 [138631.468352] worker_thread+0x4d/0x3e0 [138631.486705] kthread+0x10c/0x140 [138631.503091] ? max_active_store+0x80/0x80 [138631.523217] ? __kthread_parkme+0x70/0x70 [138631.543338] ? do_syscall_64+0x79/0x1b0 [138631.562518] ret_from_fork+0x35/0x40 [138631.580199] Code: 4c 3b a7 d8 00 00 00 0f 84 11 ff ff ff 48 8b 4f 60 49 8b 54 24 60 48 c7 c6 c0 19 c3 81 48 c7 c7 c0 9c e7 81 31 c0 e8 90 a5 eb ff <0f> 0b4c 89 e7 e9 e9 fe ff ff 65 8b 05 2c 3c de 7e 89 c0 48 0f [138631.672489] ---[ end trace 6748d86d682915c2 ]--- [138631.695691] cache_from_obj: Wrong slab cache. fsnotify_mark_connector but object is from kmalloc-2048(361:anycast-healthchecker.service) --- The kernel was fine and server was responsive. A coworker mentioned that it may come from https://github.com/torvalds/linux/blob/master/fs/notify/mark.c#L160 and commit 08991e83b728 ("fsnotify: Free fsnotify_mark_connector when there is no mark attached") arrived with 4.12-rc1 may be the cause of it. I am wondering if it is related to the issue I reported https://lkml.org/lkml/2018/4/16/506. But, that issue causes the whole server to crash, which is not the case for above kernel dump. Cheers, Pavlos

7 years, 8 months

2
4
0 0

[PATCH 2/2] MIPS: memset.S: Fix return of __clear_user from Lpartial_fixup

by Matt Redfearn

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the memset_partial block, the value loaded into a2 on return is meaningless. The label .Lpartial_fixup\@ is jumped to on page fault. Currently it masks the remaining count of bytes (a2) with STORMASK, meaning that the least significant 2 (32bit) or 3 (64bit) bits of the remaining count are always clear. Secondly, .Lpartial_fixup\@ expects t1 to contain the end address of the copy. This is set up by the initial block: PTR_ADDU t1, a0 /* end address */ However, the .Lmemset_partial\@ block then reuses register t1 to calculate a jump through a block of word copies. This leaves it no longer containing the end address of the copy operation if a page fault occurs, and the remaining bytes calculation is incorrect. Fix these issues by removing the and of a2 with STORMASK, and replace t1 with register t2 in the .Lmemset_partial\@ block. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com> --- arch/mips/lib/memset.S | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 90bcdf1224ee..3257dca58cad 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -161,19 +161,19 @@ .Lmemset_partial\@: R10KCBARRIER(0(ra)) - PTR_LA t1, 2f /* where to start */ + PTR_LA t2, 2f /* where to start */ #ifdef CONFIG_CPU_MICROMIPS LONG_SRL t7, t0, 1 #endif #if LONGSIZE == 4 - PTR_SUBU t1, FILLPTRG + PTR_SUBU t2, FILLPTRG #else .set noat LONG_SRL AT, FILLPTRG, 1 - PTR_SUBU t1, AT + PTR_SUBU t2, AT .set at #endif - jr t1 + jr t2 PTR_ADDU a0, t0 /* dest ptr */ .set push @@ -250,7 +250,6 @@ .Lpartial_fixup\@: PTR_L t0, TI_TASK($28) - andi a2, STORMASK LONG_L t0, THREAD_BUADDR(t0) LONG_ADDU a2, t1 jr ra -- 2.7.4

7 years, 8 months

2
5
0 0

[REGRESSION] [v2] ACPI / video: Default lcd_only to true on Win8 ready and newer machines

by James Hogan

On Sat, Dec 23, 2017 at 07:41:47PM +0100, Hans de Goede wrote: > We're seeing a lot of bogus backlight interfaces on newer machines without > a LCD such as desktops, servers and HDMI sticks. This causes userspace to > show a non-functional brightness slider in e.g. the GNOME3 system menu, > which is undesirable. More in general we should simply just not register > a non functional backlight interface. > > Checking the lcd flag causes the bogus acpi_video backlight interfaces to > go away (on the machines this was tested on). > > This commit enables the lcd_only option by default on any machines which > are win8 ready, fixing this. > > This is not entirely without risk of regressions, but video_detect.c > already prefers native-backlight interfaces over the acpi_video one > on win8 ready machines, calling acpi_video_unregister_backlight() as soon > as a native interface shows up. This is done because the acpi backlight > interface often is broken on win8 ready machines, because win8 does not > seem to actually use it. This patch (in the form of commit 965736ee654d ("ACPI / video: Default lcd_only to true on Win8-ready and newer machines") in stable v4.15.17), breaks backlight control on my 2013 XPS13 laptop. It normally uses the acpi backlight device, but after this patch that device no longer shows up in sysfs. This isn't the first time the backlight has gotton broken on this system, though I think last time it was because the intel backlight driver got used instead of the ACPI one and that didn't work properly with it, so it needed a quirk to make it use ACPI instead. Is some other quirk needed around here too? Cheers James

7 years, 8 months

2
5
0 0

[PATCH] target: Fix Fortify_panic kernel exception

by Bryant G. Ly

[ 496.212783] ------------[ cut here ]------------ [ 496.212784] kernel BUG at /build/linux-hwe-edge-ojNirv/linux-hwe-edge-4.15.0/lib/string.c:1052! [ 496.212789] Oops: Exception in kernel mode, sig: 5 [#1] [ 496.212791] LE SMP NR_CPUS=2048 NUMA pSeries [ 496.212795] Modules linked in: hvcs(OE) hvcserver dm_snapshot dm_bufio rpadlpar_io rpaphp ip6table_raw xt_CT xt_mac xt_tcpudp xt_comment xt_physdev xt_set ip_set_hash_net ip_set iptable_raw dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag target_core_pscsi(OE) target_core_file(OE) target_core_iblock(OE) iscsi_target_mod(OE) vxlan ip6_udp_tunnel udp_tunnel openvswitch nsh nf_nat_ipv6 target_core_user(OE) uio binfmt_misc xt_conntrack nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 nbd ipt_REJECT nf_reject_ipv4 ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 pseries_rng nf_nat ibmvmc(OE) nf_conntrack libcrc32c vmx_crypto crct10dif_vpmsum iptable_mangle iptable_filter [ 496.212854] ip_tables ip6table_filter ip6_tables ebtables x_tables br_netfilter bridge stp llc ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 mlx4_en ses enclosure scsi_transport_sas uas usb_storage ibmvscsis(OE) target_core_mod(OE) ibmveth(OE) mlx5_core mlx4_core mlxfw crc32c_vpmsum be2net tg3 ipr devlink [ 496.212888] CPU: 1 PID: 2587 Comm: kworker/1:2 Tainted: G OE 4.15.0-15-generic #16~16.04.1-Ubuntu [ 496.212897] Workqueue: ibmvscsis3000000f ibmvscsis_scheduler [ibmvscsis] [ 496.212900] NIP: c000000000cbbf00 LR: c000000000cbbefc CTR: 0000000000655170 [ 496.212903] REGS: c0000007e58e3580 TRAP: 0700 Tainted: G OE (4.15.0-15-generic) [ 496.212906] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 286c2222 XER: 20000003 [ 496.212915] CFAR: c00000000018d634 SOFTE: 1 GPR00: c000000000cbbefc c0000007e58e3800 c0000000016bae00 0000000000000022 GPR04: c0000007fe94ce18 c0000007fe964368 0000000000000003 ffffffffffffffff GPR08: 0000000000000007 c000000001193a74 00000007fd7c0000 0000000000003986 GPR12: 0000000000002200 c00000000fa80b00 c00000000013a308 c0000007f48adb00 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 fffffffffffffef7 0000000000000402 GPR24: 0000000000000000 f000000001a8cb40 00000000000003f0 0000000000648010 GPR28: c0000005a360a570 c0000007f4095880 c0000000fc9e7e00 c0000007f1f56000 [ 496.212952] NIP [c000000000cbbf00] fortify_panic+0x28/0x38 [ 496.212956] LR [c000000000cbbefc] fortify_panic+0x24/0x38 [ 496.212958] Call Trace: [ 496.212960] [c0000007e58e3800] [c000000000cbbefc] fortify_panic+0x24/0x38 (unreliable) [ 496.212965] [c0000007e58e3860] [d00000000f150c28] iblock_execute_write_same+0x3b8/0x3c0 [target_core_iblock] [ 496.212976] [c0000007e58e3910] [d000000006c737d4] __target_execute_cmd+0x54/0x150 [target_core_mod] [ 496.212982] [c0000007e58e3940] [d000000006d32ce4] ibmvscsis_write_pending+0x74/0xe0 [ibmvscsis] [ 496.212991] [c0000007e58e39b0] [d000000006c74fc8] transport_generic_new_cmd+0x318/0x370 [target_core_mod] [ 496.213001] [c0000007e58e3a30] [d000000006c75084] transport_handle_cdb_direct+0x64/0xd0 [target_core_mod] [ 496.213011] [c0000007e58e3aa0] [d000000006c75298] target_submit_cmd_map_sgls+0x1a8/0x320 [target_core_mod] [ 496.213021] [c0000007e58e3b30] [d000000006c75458] target_submit_cmd+0x48/0x60 [target_core_mod] [ 496.213026] [c0000007e58e3bd0] [d000000006d34c20] ibmvscsis_scheduler+0x370/0x600 [ibmvscsis] [ 496.213031] [c0000007e58e3c90] [c00000000013135c] process_one_work+0x1ec/0x580 [ 496.213035] [c0000007e58e3d20] [c000000000131798] worker_thread+0xa8/0x600 [ 496.213039] [c0000007e58e3dc0] [c00000000013a468] kthread+0x168/0x1b0 [ 496.213044] [c0000007e58e3e30] [c00000000000b528] ret_from_kernel_thread+0x5c/0xb4 [ 496.213047] Instruction dump: [ 496.213049] 7c0803a6 4e800020 3c4c00a0 3842ef28 7c0802a6 f8010010 f821ffa1 7c641b78 [ 496.213055] 3c62ff94 3863dc00 4b4d16f1 60000000 <0fe00000> 00000000 00000000 00000000 [ 496.213062] ---[ end trace 4c7e8c92043f3868 ]--- [ 654.577815] ibmvscsis 3000000f: connection lost with outstanding work The patch fixes the above trace where the size passed into memcmp is greater than the size of the data passed in from ptr1 or ptr2 then a fortify_panic is posted. Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") Signed-off-by: Bryant G. Ly <bryantly(a)linux.vnet.ibm.com> Reviewed-by: Steven Royer <seroyer(a)linux.vnet.ibm.com> Tested-by: Taylor Jakobson <tjakobs(a)us.ibm.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Nicholas Bellinger <nab(a)linux-iscsi.org> Cc: <stable(a)vger.kernel.org> --- drivers/target/target_core_iblock.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c index 07c814c..6042901 100644 --- a/drivers/target/target_core_iblock.c +++ b/drivers/target/target_core_iblock.c @@ -427,8 +427,8 @@ iblock_execute_zero_out(struct block_device *bdev, struct se_cmd *cmd) { struct se_device *dev = cmd->se_dev; struct scatterlist *sg = &cmd->t_data_sg[0]; - unsigned char *buf, zero = 0x00, *p = &zero; - int rc, ret; + unsigned char *buf, *not_zero; + int ret; buf = kmap(sg_page(sg)) + sg->offset; if (!buf) @@ -437,10 +437,10 @@ iblock_execute_zero_out(struct block_device *bdev, struct se_cmd *cmd) * Fall back to block_execute_write_same() slow-path if * incoming WRITE_SAME payload does not contain zeros. */ - rc = memcmp(buf, p, cmd->data_length); + not_zero = memchr_inv(buf, 0x00, cmd->data_length); kunmap(sg_page(sg)); - if (rc) + if (not_zero) return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE; ret = blkdev_issue_zeroout(bdev, -- 2.7.2

7 years, 8 months

2
3
0 0

FAILED: patch "[PATCH] ovl: set lower layer st_dev only if setting lower st_ino" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 9f99e50d460ac7fd5f6c9b97aad0088c28c8656d Mon Sep 17 00:00:00 2001 From: Amir Goldstein <amir73il(a)gmail.com> Date: Wed, 11 Apr 2018 20:09:29 +0300 Subject: [PATCH] ovl: set lower layer st_dev only if setting lower st_ino For broken hardlinks, we do not return lower st_ino, so we should also not return lower pseudo st_dev. Fixes: a0c5ad307ac0 ("ovl: relax same fs constraint for constant st_ino") Cc: <stable(a)vger.kernel.org> #v4.15 Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index 4689716f23d8..1d75b2e96c96 100644 --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -118,13 +118,10 @@ int ovl_getattr(const struct path *path, struct kstat *stat, */ if (ovl_test_flag(OVL_INDEX, d_inode(dentry)) || (!ovl_verify_lower(dentry->d_sb) && - (is_dir || lowerstat.nlink == 1))) + (is_dir || lowerstat.nlink == 1))) { stat->ino = lowerstat.ino; - - if (samefs) - WARN_ON_ONCE(stat->dev != lowerstat.dev); - else stat->dev = ovl_get_pseudo_dev(dentry); + } } if (samefs) { /*

7 years, 8 months

3
2
0 0

FAILED: patch "[PATCH] Documentation/sphinx: Fix Directive import error" failed to apply to 4.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.16-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 41387bb7d869e96df4b870e1880ad49f053cc755 Mon Sep 17 00:00:00 2001 From: Matthew Wilcox <mawilcox(a)microsoft.com> Date: Fri, 2 Mar 2018 10:40:14 -0800 Subject: [PATCH] Documentation/sphinx: Fix Directive import error Sphinx 1.7 removed sphinx.util.compat.Directive so people who have upgraded cannot build the documentation. Switch to docutils.parsers.rst.Directive which has been available since docutils 0.5 released in 2009. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 Co-developed-by: Takashi Iwai <tiwai(a)suse.de> Acked-by: Jani Nikula <jani.nikula(a)intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com> Signed-off-by: Jonathan Corbet <corbet(a)lwn.net> diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index 39aa9e8697cc..fbedcc39460b 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -36,8 +36,7 @@ import glob from docutils import nodes, statemachine from docutils.statemachine import ViewList -from docutils.parsers.rst import directives -from sphinx.util.compat import Directive +from docutils.parsers.rst import directives, Directive from sphinx.ext.autodoc import AutodocReporter __version__ = '1.0'

7 years, 8 months

3
2
0 0

Please apply commit 0c4c5860e998 to v4.4.y, v4.9.y, v4.14.y, v4.15.y

by Guenter Roeck

Hi Greg, Upstream commit 0c4c5860e998 ("hwmon: (ina2xx) Fix access to uninitialized mutex") fixes commit 5d389b125186 ("hwmon: (ina2xx) Make calibration register value fixed"), which has found its way into v4.4.y, v4.9.y, v4.14.y, and v4.15.y. Please apply commit 0c4c5860e998 to all affected releases to fix the resulting regression. Maybe Sasha's script could be improved to look for Fixes: tags when suggesting to apply patches to older releases. Thanks, Guenter

7 years, 8 months

2
3
0 0

Re: refine xhci-plat-Fix-xhci_plat-shutdown-sequence

by leiwan＠codeaurora.org

在 2018-04-17 18:32，Greg KH 写道： > On Tue, Apr 17, 2018 at 11:32:42AM +0800, leiwan(a)codeaurora.org wrote: >> >> xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE >> before accessing any register. This should avoid hung with access >> controllers which support runtime suspend >> >> This can fix for issue of https://patchwork.kernel.org/patch/10339317/ >> corresponding upload in CAF: >> https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LV.HB.1.1.5-… >> >> full patch refer attachment. >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index 9b27798..bdf914d 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd) >> usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev)); >> >> spin_lock_irq(&xhci->lock); >> + if (!HCD_HW_ACCESSIBLE(hcd)) { >> + spin_unlock_irq(&xhci->lock); >> + return; >> + } >> xhci_halt(xhci); > > A blank line after the if statement? > >> [lei]yes > What about all of the other places in this driver that you should also > check for this? Look at the other host controllers, shouldn't you > mirror what they are doing? > >> [lei]I checked other usb host module shutdown and suspend workflow. >> All usb host driver need to check hw accessable before >> read/write usb register especially in runtime PM case.. > And this needs a Fixes: tag, along with a cc: stable so as to properly > get backported as this is broken in some stable kernels right now. > >> [lei] Added by v2 patch > thanks, > > greg k-h From c03697fa259ab38d1002598ec2ccfac37607ca0b Mon Sep 17 00:00:00 2001 From: Lei wang <leiwan(a)codeaurora.org> Date: Tue, 17 Apr 2018 10:55:35 +0800 Subject: [PATCH v2] xhci: plat: Fix xhci_plat shutdown hung xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE before accessing any register. This should avoid hung with access controllers which support runtime suspend Fixes: b07c12517f2a ("xhci: plat: Register shutdown for xhci_plat") Cc: <stable(a)vger.kernel.org> Signed-off-by: Lei wang <leiwan(a)codeaurora.org> --- drivers/usb/host/xhci.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 9b27798..bdf914d 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd) usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev)); spin_lock_irq(&xhci->lock); + if (!HCD_HW_ACCESSIBLE(hcd)) { + spin_unlock_irq(&xhci->lock); + return; + } xhci_halt(xhci); /* Workaround for spurious wakeups at shutdown with HSW */ if (xhci->quirks & XHCI_SPURIOUS_WAKEUP) -- 1.9.1

7 years, 8 months

2
1
0 0

WTF: patch "[PATCH] kvm: x86: fix a compile warning" was seriously submitted to be applied to the 4.16-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 4.16-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3140c156e919b0f5fad5c5f6cf7876c39d1d4f06 Mon Sep 17 00:00:00 2001 From: Peng Hao <peng.hao2(a)zte.com.cn> Date: Mon, 2 Apr 2018 09:15:32 +0800 Subject: [PATCH] kvm: x86: fix a compile warning fix a "warning: no previous prototype". Cc: stable(a)vger.kernel.org Signed-off-by: Peng Hao <peng.hao2(a)zte.com.cn> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 8f108131d85d..b2ff74b12ec4 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7943,7 +7943,7 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16 tss_selector, int idt_index, } EXPORT_SYMBOL_GPL(kvm_task_switch); -int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs) +static int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs) { if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG)) { /*

7 years, 8 months

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror