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

Patch "vfio/powerpc/spapr_tce: Enforce IOMMU type compatibility check" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfio/powerpc/spapr_tce: Enforce IOMMU type compatibility check to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vfio-powerpc-spapr_tce-enforce-iommu-type-compatibility-check.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Alexey Kardashevskiy <aik(a)ozlabs.ru> Date: Fri, 24 Mar 2017 17:44:06 +1100 Subject: vfio/powerpc/spapr_tce: Enforce IOMMU type compatibility check From: Alexey Kardashevskiy <aik(a)ozlabs.ru> [ Upstream commit 1282ba7fc28dbc66c3f0e4aaafaaa228361d1ae5 ] The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually picks the v2. Normally the userspace would create a container, attach an IOMMU group to it and only then set the IOMMU type (which would normally be v2). However a specific IOMMU group may not support v2, in other words it may not implement set_window/unset_window/take_ownership/ release_ownership and such a group should not be attached to a v2 container. This adds extra checks that a new group can do what the selected IOMMU type suggests. The userspace can then test the return value from ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try VFIO_SPAPR_TCE_IOMMU. Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/vfio/vfio_iommu_spapr_tce.c +++ b/drivers/vfio/vfio_iommu_spapr_tce.c @@ -1332,8 +1332,16 @@ static int tce_iommu_attach_group(void * if (!table_group->ops || !table_group->ops->take_ownership || !table_group->ops->release_ownership) { + if (container->v2) { + ret = -EPERM; + goto unlock_exit; + } ret = tce_iommu_take_ownership(container, table_group); } else { + if (!container->v2) { + ret = -EPERM; + goto unlock_exit; + } ret = tce_iommu_take_ownership_ddw(container, table_group); if (!tce_groups_attached(container) && !container->tables[0]) container->def_window_pending = true; Patches currently in stable-queue which might be from aik(a)ozlabs.ru are queue-4.9/vfio-spapr_tce-check-kzalloc-return-when-preregistering-memory.patch queue-4.9/vfio-powerpc-spapr_tce-enforce-iommu-type-compatibility-check.patch

7 years, 4 months

1
0
0 0

Patch "veth: set peer GSO values" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled veth: set peer GSO values to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: veth-set-peer-gso-values.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Thu, 7 Dec 2017 15:40:20 -0800 Subject: veth: set peer GSO values From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ] When new veth is created, and GSO values have been configured on one device, clone those values to the peer. For example: # ip link add dev vm1 gso_max_size 65530 type veth peer name vm2 This should create vm1 <--> vm2 with both having GSO maximum size set to 65530. Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/veth.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -425,6 +425,9 @@ static int veth_newlink(struct net *src_ if (ifmp && (dev->ifindex != 0)) peer->ifindex = ifmp->ifi_index; + peer->gso_max_size = dev->gso_max_size; + peer->gso_max_segs = dev->gso_max_segs; + err = register_netdevice(peer); put_net(net); net = NULL; Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.9/veth-set-peer-gso-values.patch queue-4.9/netem-apply-correct-delay-when-rate-throttling.patch

7 years, 4 months

1
0
0 0

Patch "[media] v4l: vsp1: Register pipe with output WPF" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] v4l: vsp1: Register pipe with output WPF to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: v4l-vsp1-register-pipe-with-output-wpf.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Date: Mon, 27 Feb 2017 10:40:34 -0300 Subject: [media] v4l: vsp1: Register pipe with output WPF From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> [ Upstream commit 1531a208ed861e4bd287444f9466ffcf98383de2 ] The DRM object does not register the pipe with the WPF object. This is used internally throughout the driver as a means of accessing the pipe. As such this breaks operations which require access to the pipe from WPF interrupts. Register the pipe inside the WPF object after it has been declared as the output. Fixes: ff7e97c94d9f ("[media] v4l: vsp1: Store pipeline pointer in rwpf") Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/vsp1/vsp1_drm.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -596,6 +596,7 @@ int vsp1_drm_init(struct vsp1_device *vs pipe->bru = &vsp1->bru->entity; pipe->lif = &vsp1->lif->entity; pipe->output = vsp1->wpf[0]; + pipe->output->pipe = pipe; return 0; } Patches currently in stable-queue which might be from kieran.bingham+renesas(a)ideasonboard.com are queue-4.9/v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch queue-4.9/v4l-vsp1-register-pipe-with-output-wpf.patch queue-4.9/media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch

7 years, 4 months

1
0
0 0

Patch "[media] v4l: vsp1: Prevent multiple streamon race commencing pipeline early" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] v4l: vsp1: Prevent multiple streamon race commencing pipeline early to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Date: Fri, 6 Jan 2017 10:15:28 -0200 Subject: [media] v4l: vsp1: Prevent multiple streamon race commencing pipeline early From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> [ Upstream commit 4461c84b52b4a952c657505ef7e4e06b016783df ] With multiple inputs through the BRU it is feasible for the streams to race each other at stream-on. Multiple VIDIOC_STREAMON calls racing each other could have process N-1 skipping over the pipeline setup section and then start the pipeline early, if videobuf2 has already enqueued buffers to the driver for process N but not called the .start_streaming() operation yet In the case of the video pipelines, this can present two serious issues. 1) A null-dereference if the pipe->dl is committed at the same time as the vsp1_video_setup_pipeline() is processing 2) A hardware hang, where a display list is committed without having called vsp1_video_setup_pipeline() first Repair this issue, by ensuring that only the stream which configures the pipeline is able to start it. Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/vsp1/vsp1_video.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/drivers/media/platform/vsp1/vsp1_video.c +++ b/drivers/media/platform/vsp1/vsp1_video.c @@ -792,6 +792,7 @@ static int vsp1_video_start_streaming(st { struct vsp1_video *video = vb2_get_drv_priv(vq); struct vsp1_pipeline *pipe = video->rwpf->pipe; + bool start_pipeline = false; unsigned long flags; int ret; @@ -802,11 +803,23 @@ static int vsp1_video_start_streaming(st mutex_unlock(&pipe->lock); return ret; } + + start_pipeline = true; } pipe->stream_count++; mutex_unlock(&pipe->lock); + /* + * vsp1_pipeline_ready() is not sufficient to establish that all streams + * are prepared and the pipeline is configured, as multiple streams + * can race through streamon with buffers already queued; Therefore we + * don't even attempt to start the pipeline until the last stream has + * called through here. + */ + if (!start_pipeline) + return 0; + spin_lock_irqsave(&pipe->irqlock, flags); if (vsp1_pipeline_ready(pipe)) vsp1_video_pipeline_run(pipe); Patches currently in stable-queue which might be from kieran.bingham+renesas(a)ideasonboard.com are queue-4.9/v4l-vsp1-prevent-multiple-streamon-race-commencing-pipeline-early.patch queue-4.9/v4l-vsp1-register-pipe-with-output-wpf.patch queue-4.9/media-vsp1-prevent-suspending-and-resuming-drm-pipelines.patch

7 years, 4 months

1
0
0 0

Patch "userns: Don't fail follow_automount based on s_user_ns" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled userns: Don't fail follow_automount based on s_user_ns to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: userns-don-t-fail-follow_automount-based-on-s_user_ns.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 29 Nov 2017 17:29:20 -0600 Subject: userns: Don't fail follow_automount based on s_user_ns From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit bbc3e471011417598e598707486f5d8814ec9c01 ] When vfs_submount was added the test to limit automounts from filesystems that with s_user_ns != &init_user_ns accidentially left in follow_automount. The test was never about any security concerns and was always about how do we implement this for filesystems whose s_user_ns != &init_user_ns. At the moment this check makes no difference as there are no filesystems that both set FS_USERNS_MOUNT and implement d_automount. Remove this check now while I am thinking about it so there will not be odd booby traps for someone who does want to make this combination work. vfs_submount still needs improvements to allow this combination to work, and vfs_submount contains a check that presents a warning. The autofs4 filesystem could be modified to set FS_USERNS_MOUNT and it would need not work on this code path, as userspace performs the mounts. Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts") Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds") Acked-by: Ian Kent <raven(a)themaw.net> Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 3 --- 1 file changed, 3 deletions(-) --- a/fs/namei.c +++ b/fs/namei.c @@ -1121,9 +1121,6 @@ static int follow_automount(struct path path->dentry->d_inode) return -EISDIR; - if (path->dentry->d_sb->s_user_ns != &init_user_ns) - return -EACCES; - nd->total_link_count++; if (nd->total_link_count >= 40) return -ELOOP; Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.9/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch

7 years, 4 months

1
0
0 0

Patch "usb: misc: lvs: fix race condition in disconnect handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: misc: lvs: fix race condition in disconnect handling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-misc-lvs-fix-race-condition-in-disconnect-handling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Oliver Neukum <oneukum(a)suse.com> Date: Tue, 14 Mar 2017 12:05:07 +0100 Subject: usb: misc: lvs: fix race condition in disconnect handling From: Oliver Neukum <oneukum(a)suse.com> [ Upstream commit c4ba329cabca7c839ab48fb58b5bcc2582951a48 ] There is a small window during which the an URB may remain active after disconnect has returned. If in that case already freed memory may be accessed and executed. The fix is to poison the URB befotre the work is flushed. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/lvstest.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/misc/lvstest.c +++ b/drivers/usb/misc/lvstest.c @@ -433,6 +433,7 @@ static void lvs_rh_disconnect(struct usb struct lvs_rh *lvs = usb_get_intfdata(intf); sysfs_remove_group(&intf->dev.kobj, &lvs_attr_group); + usb_poison_urb(lvs->urb); /* used in scheduled work */ flush_work(&lvs->rh_work); usb_free_urb(lvs->urb); } Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-4.9/usb-misc-lvs-fix-race-condition-in-disconnect-handling.patch

7 years, 4 months

1
0
0 0

Patch "usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Yuyang Du <yuyang.du(a)intel.com> Date: Fri, 24 Mar 2017 04:06:11 +0800 Subject: usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control() From: Yuyang Du <yuyang.du(a)intel.com> [ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ] This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support"). In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yuyang Du <yuyang.du(a)intel.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -2103,16 +2103,13 @@ static int dummy_hub_control( } break; case USB_PORT_FEAT_POWER: - if (hcd->speed == HCD_USB3) { - if (dum_hcd->port_status & USB_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - } else - if (dum_hcd->port_status & - USB_SS_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - /* FALLS THROUGH */ + dev_dbg(dummy_dev(dum_hcd), "power-off\n"); + if (hcd->speed == HCD_USB3) + dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER; + else + dum_hcd->port_status &= ~USB_PORT_STAT_POWER; + set_link_state(dum_hcd); + break; default: dum_hcd->port_status &= ~(1 << wValue); set_link_state(dum_hcd); @@ -2283,14 +2280,13 @@ static int dummy_hub_control( if ((dum_hcd->port_status & USB_SS_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } } else if ((dum_hcd->port_status & USB_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } + set_link_state(dum_hcd); } break; case GetPortErrorCount: Patches currently in stable-queue which might be from yuyang.du(a)intel.com are queue-4.9/usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch

7 years, 4 months

1
0
0 0

Patch "usb: dwc3: make sure UX_EXIT_PX is cleared" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: make sure UX_EXIT_PX is cleared to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc3-make-sure-ux_exit_px-is-cleared.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Felipe Balbi <felipe.balbi(a)linux.intel.com> Date: Wed, 3 Aug 2016 14:16:15 +0300 Subject: usb: dwc3: make sure UX_EXIT_PX is cleared From: Felipe Balbi <felipe.balbi(a)linux.intel.com> [ Upstream commit 1966b8657d058ecb95031809b607bf3fd1e01c10 ] This bit is only supposed to be used with known buggy PHYs, however some platforms might erroneously set it. In order to avoid it, let's make sure this bit is always cleared. If some PHY needs this, we will need to add a quirk flag. Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/core.c | 6 ++++++ drivers/usb/dwc3/core.h | 1 + 2 files changed, 7 insertions(+) --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -464,6 +464,12 @@ static int dwc3_phy_setup(struct dwc3 *d reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); /* + * Make sure UX_EXIT_PX is cleared as that causes issues with some + * PHYs. Also, this bit is not supposed to be used in normal operation. + */ + reg &= ~DWC3_GUSB3PIPECTL_UX_EXIT_PX; + + /* * Above 1.94a, it is recommended to set DWC3_GUSB3PIPECTL_SUSPHY * to '0' during coreConsultant configuration. So default value * will be '0' when the core is reset. Application needs to set it --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -223,6 +223,7 @@ #define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 << 31) #define DWC3_GUSB3PIPECTL_U2SSINP3OK (1 << 29) #define DWC3_GUSB3PIPECTL_DISRXDETINP3 (1 << 28) +#define DWC3_GUSB3PIPECTL_UX_EXIT_PX (1 << 27) #define DWC3_GUSB3PIPECTL_REQP1P2P3 (1 << 24) #define DWC3_GUSB3PIPECTL_DEP1P2P3(n) ((n) << 19) #define DWC3_GUSB3PIPECTL_DEP1P2P3_MASK DWC3_GUSB3PIPECTL_DEP1P2P3(7) Patches currently in stable-queue which might be from felipe.balbi(a)linux.intel.com are queue-4.9/usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch queue-4.9/usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch queue-4.9/usb-dwc3-make-sure-ux_exit_px-is-cleared.patch

7 years, 4 months

1
0
0 0

Patch "usb: dwc2: Make sure we disconnect the gadget state" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc2: Make sure we disconnect the gadget state to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: John Stultz <john.stultz(a)linaro.org> Date: Mon, 13 Feb 2017 20:08:08 -0800 Subject: usb: dwc2: Make sure we disconnect the gadget state From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ] I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear. Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected. So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared. With it, the gadget interface initializes properly on every plug in. Cc: Wei Xu <xuwei5(a)hisilicon.com> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Amit Pundir <amit.pundir(a)linaro.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: John Youn <johnyoun(a)synopsys.com> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Chen Yu <chenyu56(a)huawei.com> Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Acked-by: John Youn <johnyoun(a)synopsys.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc2/hcd.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -3220,6 +3220,7 @@ static void dwc2_conn_id_status_change(s dwc2_core_init(hsotg, false); dwc2_enable_global_interrupts(hsotg); spin_lock_irqsave(&hsotg->lock, flags); + dwc2_hsotg_disconnect(hsotg); dwc2_hsotg_core_init_disconnected(hsotg, false); spin_unlock_irqrestore(&hsotg->lock, flags); dwc2_hsotg_core_connect(hsotg); Patches currently in stable-queue which might be from john.stultz(a)linaro.org are queue-4.9/usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch queue-4.9/sysrq-reset-the-watchdog-timers-while-displaying-high-resolution-timers.patch queue-4.9/timers-sched_clock-update-timeout-for-clock-wrap.patch

7 years, 4 months

1
0
0 0

Patch "tty: amba-pl011: Fix spurious TX interrupts" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: amba-pl011: Fix spurious TX interrupts to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-amba-pl011-fix-spurious-tx-interrupts.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Jayachandran C <jnair(a)caviumnetworks.com> Date: Sat, 1 Apr 2017 19:42:09 +0000 Subject: tty: amba-pl011: Fix spurious TX interrupts From: Jayachandran C <jnair(a)caviumnetworks.com> [ Upstream commit 7d05587c9e0e4611650bb403812e2d492c178a9f ] On SMP systems, we see a lot of spurious TX interrupts when a program generates a steady stream of output to the pl011 UART. The problem can be easily seen when one CPU generates the output while another CPU handles the pl011 interrupts, and the rate of output is low enough not to fill the TX FIFO. The problem seems to be: -- CPU a -- -- CPU b -- (take port lock) pl011_start_tx pl011_start_tx_pio enable TXIM in REG_IMSC -> causes uart tx intr (pl011_int) pl011_tx_chars pl011_int ...tx chars, all done... (wait for port lock) pl011_stop_tx . disable TXIM . (release port lock) -> (take port lock) check for TXIM, not enabled (release port lock) return IRQ_NONE Enabling the TXIM in pl011_start_tx_pio() causes the interrupt to be generated and delivered to CPU b, even though pl011_tx_chars() is able to complete the TX and then disable the tx interrupt. Fix this by enabling TXIM only after pl011_tx_chars, if it is needed. pl011_tx_chars will return a boolean indicating whether the TX interrupts have to be enabled. Debugged-by: Vijaya Kumar <Vijaya.Kumar(a)cavium.com> Signed-off-by: Jayachandran C <jnair(a)caviumnetworks.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/amba-pl011.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -1302,14 +1302,15 @@ static void pl011_stop_tx(struct uart_po pl011_dma_tx_stop(uap); } -static void pl011_tx_chars(struct uart_amba_port *uap, bool from_irq); +static bool pl011_tx_chars(struct uart_amba_port *uap, bool from_irq); /* Start TX with programmed I/O only (no DMA) */ static void pl011_start_tx_pio(struct uart_amba_port *uap) { - uap->im |= UART011_TXIM; - pl011_write(uap->im, uap, REG_IMSC); - pl011_tx_chars(uap, false); + if (pl011_tx_chars(uap, false)) { + uap->im |= UART011_TXIM; + pl011_write(uap->im, uap, REG_IMSC); + } } static void pl011_start_tx(struct uart_port *port) @@ -1389,25 +1390,26 @@ static bool pl011_tx_char(struct uart_am return true; } -static void pl011_tx_chars(struct uart_amba_port *uap, bool from_irq) +/* Returns true if tx interrupts have to be (kept) enabled */ +static bool pl011_tx_chars(struct uart_amba_port *uap, bool from_irq) { struct circ_buf *xmit = &uap->port.state->xmit; int count = uap->fifosize >> 1; if (uap->port.x_char) { if (!pl011_tx_char(uap, uap->port.x_char, from_irq)) - return; + return true; uap->port.x_char = 0; --count; } if (uart_circ_empty(xmit) || uart_tx_stopped(&uap->port)) { pl011_stop_tx(&uap->port); - return; + return false; } /* If we are using DMA mode, try to send some characters. */ if (pl011_dma_tx_irq(uap)) - return; + return true; do { if (likely(from_irq) && count-- == 0) @@ -1422,8 +1424,11 @@ static void pl011_tx_chars(struct uart_a if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) uart_write_wakeup(&uap->port); - if (uart_circ_empty(xmit)) + if (uart_circ_empty(xmit)) { pl011_stop_tx(&uap->port); + return false; + } + return true; } static void pl011_modem_status(struct uart_amba_port *uap) Patches currently in stable-queue which might be from jnair(a)caviumnetworks.com are queue-4.9/tty-amba-pl011-fix-spurious-tx-interrupts.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror