December 2018 - Linux-stable-mirror

patch "tty: serial: 8250_mtk: always resume the device in probe." added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: serial: 8250_mtk: always resume the device in probe. to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 Mon Sep 17 00:00:00 2001 From: Peter Shih <pihsun(a)chromium.org> Date: Tue, 27 Nov 2018 12:49:50 +0800 Subject: tty: serial: 8250_mtk: always resume the device in probe. serial8250_register_8250_port calls uart_config_port, which calls config_port on the port before it tries to power on the port. So we need the port to be on before calling serial8250_register_8250_port. Change the code to always do a runtime resume in probe before registering port, and always do a runtime suspend in remove. This basically reverts the change in commit 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling"), but still use pm_runtime callbacks. Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling") Signed-off-by: Peter Shih <pihsun(a)chromium.org> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_mtk.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c index dd5e1cede2b5..c3f933d10295 100644 --- a/drivers/tty/serial/8250/8250_mtk.c +++ b/drivers/tty/serial/8250/8250_mtk.c @@ -213,17 +213,17 @@ static int mtk8250_probe(struct platform_device *pdev) platform_set_drvdata(pdev, data); - pm_runtime_enable(&pdev->dev); - if (!pm_runtime_enabled(&pdev->dev)) { - err = mtk8250_runtime_resume(&pdev->dev); - if (err) - return err; - } + err = mtk8250_runtime_resume(&pdev->dev); + if (err) + return err; data->line = serial8250_register_8250_port(&uart); if (data->line < 0) return data->line; + pm_runtime_set_active(&pdev->dev); + pm_runtime_enable(&pdev->dev); + return 0; } @@ -234,13 +234,11 @@ static int mtk8250_remove(struct platform_device *pdev) pm_runtime_get_sync(&pdev->dev); serial8250_unregister_port(data->line); + mtk8250_runtime_suspend(&pdev->dev); pm_runtime_disable(&pdev->dev); pm_runtime_put_noidle(&pdev->dev); - if (!pm_runtime_status_suspended(&pdev->dev)) - mtk8250_runtime_suspend(&pdev->dev); - return 0; } -- 2.19.2

6 years

1
0
0 0

[PATCH] Revert "mfd: cros_ec: Use devm_kzalloc for private data"

by Enric Balletbo i Serra

This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e. That commit triggered a new WARN when unloading the module (see at the end of the commit message). When a class_dev is embedded in a structure then that class_dev is the thing that controls the lifetime of that structure, for that reason device managed allocations can't be used here. See Documentation/kobject.txt. Revert the above patch, so the struct is allocated using kzalloc and we have a release function for it that frees the allocated memory, otherwise it is broken. ------------[ cut here ]------------ Device 'cros_ec' does not have a release() function, it is broken and must be fixed. WARNING: CPU: 3 PID: 3675 at drivers/base/core.c:895 device_release+0x80/0x90 Modules linked in: btusb btrtl btintel btbcm bluetooth ... CPU: 3 PID: 3675 Comm: rmmod Not tainted 4.20.0-rc4 #76 Hardware name: Google Kevin (DT) pstate: 40000005 (nZcv daif -PAN -UAO) pc : device_release+0x80/0x90 lr : device_release+0x80/0x90 sp : ffff00000c47bc70 x29: ffff00000c47bc70 x28: ffff8000e86b0d40 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000056000000 x24: 0000000000000015 x23: ffff8000f0bbf860 x22: ffff000000d320a0 x21: ffff8000ee93e100 x20: ffff8000ed931428 x19: ffff8000ed931418 x18: 0000000000000020 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000400 x14: 0000000000000143 x13: 0000000000000000 x12: 0000000000000400 x11: 0000000000000157 x10: 0000000000000960 x9 : ffff00000c47b9b0 x8 : ffff8000e86b1700 x7 : 0000000000000000 x6 : ffff8000f7d520b8 x5 : ffff8000f7d520b8 x4 : 0000000000000000 x3 : ffff8000f7d58e68 x2 : ffff8000e86b0d40 x1 : 37d859939c964800 x0 : 0000000000000000 Call trace: device_release+0x80/0x90 kobject_put+0x74/0xe8 device_unregister+0x20/0x30 ec_device_remove+0x34/0x48 [cros_ec_dev] platform_drv_remove+0x28/0x48 device_release_driver_internal+0x1a8/0x240 driver_detach+0x40/0x80 bus_remove_driver+0x54/0xa8 driver_unregister+0x2c/0x58 platform_driver_unregister+0x10/0x18 cros_ec_dev_exit+0x1c/0x2d8 [cros_ec_dev] __arm64_sys_delete_module+0x16c/0x1f8 el0_svc_common+0x84/0xd8 el0_svc_handler+0x2c/0x80 el0_svc+0x8/0xc ---[ end trace a57c4625f3c60ae8 ]--- Cc: stable(a)vger.kernel.org Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data") Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- drivers/mfd/cros_ec_dev.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c index 8f9d6964173e..b99a194ce5a4 100644 --- a/drivers/mfd/cros_ec_dev.c +++ b/drivers/mfd/cros_ec_dev.c @@ -263,6 +263,11 @@ static const struct file_operations fops = { #endif }; +static void cros_ec_class_release(struct device *dev) +{ + kfree(to_cros_ec_dev(dev)); +} + static void cros_ec_sensors_register(struct cros_ec_dev *ec) { /* @@ -395,7 +400,7 @@ static int ec_device_probe(struct platform_device *pdev) int retval = -ENOMEM; struct device *dev = &pdev->dev; struct cros_ec_platform *ec_platform = dev_get_platdata(dev); - struct cros_ec_dev *ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL); + struct cros_ec_dev *ec = kzalloc(sizeof(*ec), GFP_KERNEL); if (!ec) return retval; @@ -417,6 +422,7 @@ static int ec_device_probe(struct platform_device *pdev) ec->class_dev.devt = MKDEV(ec_major, pdev->id); ec->class_dev.class = &cros_class; ec->class_dev.parent = dev; + ec->class_dev.release = cros_ec_class_release; retval = dev_set_name(&ec->class_dev, "%s", ec_platform->ec_name); if (retval) { -- 2.19.1

6 years

4
3
0 0

Re: [PATCH v2] drm/meson: Fixes for drm_crtc_vblank_on/off support

by Neil Armstrong

Hi Stable team, On 22/11/2018 17:01, Neil Armstrong wrote: > Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get > a warning when ctrc is disabled : > " driver forgot to call drm_crtc_vblank_off()" > > But, the vsync IRQ was not totally disabled due the transient hardware > state and specific interrupt line, thus adding proper IRQ masking from > the HHI system control registers. > > The last change fixes a race condition introduced by calling the added > drm_crtc_vblank_on/off when an HPD event occurs from the HDMI connector, > triggering a WARN_ON() in the _atomic_begin() callback when the CRTC > is disabled, thus also triggering a WARN_ON() in drm_vblank_put() : > > WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/meson/meson_crtc.c:157 meson_crtc_atomic_begin+0x78/0x80 > [...] > Call trace: > meson_crtc_atomic_begin+0x78/0x80 > drm_atomic_helper_commit_planes+0x140/0x218 > drm_atomic_helper_commit_tail+0x38/0x80 > commit_tail+0x7c/0x80 > drm_atomic_helper_commit+0xdc/0x150 > drm_atomic_commit+0x54/0x60 > restore_fbdev_mode_atomic+0x198/0x238 > restore_fbdev_mode+0x6c/0x1c0 > drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xf0 > drm_fb_helper_set_par+0x34/0x60 > drm_fb_helper_hotplug_event.part.28+0xb8/0xc8 > drm_fbdev_client_hotplug+0xa4/0xe0 > drm_client_dev_hotplug+0x90/0xe0 > drm_kms_helper_hotplug_event+0x3c/0x48 > drm_helper_hpd_irq_event+0x134/0x168 > dw_hdmi_top_thread_irq+0x3c/0x50 > [...] > WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/drm_vblank.c:1026 drm_vblank_put+0xb4/0xc8 > [...] > Call trace: > drm_vblank_put+0xb4/0xc8 > drm_crtc_vblank_put+0x24/0x30 > drm_atomic_helper_wait_for_vblanks.part.9+0x130/0x2b8 > drm_atomic_helper_commit_tail+0x68/0x80 > [...] > > The issue is that vblank need to be enabled in any occurence of : > - atomic_enable() > - atomic_begin() and state->enable == true, which was not the case > > Moving the CRTC enable code to a common function and calling in one > of these occurence solves this race condition and makes sure vblank > is enabled in each call to _atomic_begin() from the HPD event leading > to drm_atomic_helper_commit_planes(). > > To Summarize : > - Make sure that the CRTC code will call the drm_crtc_vblank_on()/off() > - *Really* mask the Vsync IRQ > - Initialize and enable vblank at the first _atomic_begin()/_atomic_enable() This fix hit linux master as commit id 2bcd3ecab773f73211c45bb1430bb52ac641f271 Coult it be applied on the Linux 4.19 stable tree ? Thanks, Neil > > Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> > --- > drivers/gpu/drm/meson/meson_crtc.c | 27 +++++++++++++++++++++++++-- > drivers/gpu/drm/meson/meson_venc.c | 3 +++ > 2 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/meson/meson_crtc.c b/drivers/gpu/drm/meson/meson_crtc.c > index d78168f979db..75d97f1b2e8f 100644 > --- a/drivers/gpu/drm/meson/meson_crtc.c > +++ b/drivers/gpu/drm/meson/meson_crtc.c > @@ -46,6 +46,7 @@ struct meson_crtc { > struct drm_crtc base; > struct drm_pending_vblank_event *event; > struct meson_drm *priv; > + bool enabled; > }; > #define to_meson_crtc(x) container_of(x, struct meson_crtc, base) > > @@ -81,8 +82,7 @@ static const struct drm_crtc_funcs meson_crtc_funcs = { > > }; > > -static void meson_crtc_atomic_enable(struct drm_crtc *crtc, > - struct drm_crtc_state *old_state) > +static void meson_crtc_enable(struct drm_crtc *crtc) > { > struct meson_crtc *meson_crtc = to_meson_crtc(crtc); > struct drm_crtc_state *crtc_state = crtc->state; > @@ -106,6 +106,22 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc, > writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE, > priv->io_base + _REG(VPP_MISC)); > > + drm_crtc_vblank_on(crtc); > + > + meson_crtc->enabled = true; > +} > + > +static void meson_crtc_atomic_enable(struct drm_crtc *crtc, > + struct drm_crtc_state *old_state) > +{ > + struct meson_crtc *meson_crtc = to_meson_crtc(crtc); > + struct meson_drm *priv = meson_crtc->priv; > + > + DRM_DEBUG_DRIVER("\n"); > + > + if (!meson_crtc->enabled) > + meson_crtc_enable(crtc); > + > priv->viu.osd1_enabled = true; > } > > @@ -117,6 +133,8 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc, > > DRM_DEBUG_DRIVER("\n"); > > + drm_crtc_vblank_off(crtc); > + > priv->viu.osd1_enabled = false; > priv->viu.osd1_commit = false; > > @@ -135,6 +153,8 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc, > > crtc->state->event = NULL; > } > + > + meson_crtc->enabled = false; > } > > static void meson_crtc_atomic_begin(struct drm_crtc *crtc, > @@ -143,6 +163,9 @@ static void meson_crtc_atomic_begin(struct drm_crtc *crtc, > struct meson_crtc *meson_crtc = to_meson_crtc(crtc); > unsigned long flags; > > + if (crtc->state->enable && !meson_crtc->enabled) > + meson_crtc_enable(crtc); > + > if (crtc->state->event) { > WARN_ON(drm_crtc_vblank_get(crtc) != 0); > > diff --git a/drivers/gpu/drm/meson/meson_venc.c b/drivers/gpu/drm/meson/meson_venc.c > index 9be0376e0329..ab72ddda242d 100644 > --- a/drivers/gpu/drm/meson/meson_venc.c > +++ b/drivers/gpu/drm/meson/meson_venc.c > @@ -71,6 +71,7 @@ > */ > > /* HHI Registers */ > +#define HHI_GCLK_MPEG2 0x148 /* 0x52 offset in data sheet */ > #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */ > #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */ > #define HHI_HDMI_PHY_CNTL0 0x3a0 /* 0xe8 offset in data sheet */ > @@ -1663,10 +1664,12 @@ unsigned int meson_venci_get_field(struct meson_drm *priv) > void meson_venc_enable_vsync(struct meson_drm *priv) > { > writel_relaxed(2, priv->io_base + _REG(VENC_INTCTRL)); > + regmap_update_bits(priv->hhi, HHI_GCLK_MPEG2, BIT(25), BIT(25)); > } > > void meson_venc_disable_vsync(struct meson_drm *priv) > { > + regmap_update_bits(priv->hhi, HHI_GCLK_MPEG2, BIT(25), 0); > writel_relaxed(0, priv->io_base + _REG(VENC_INTCTRL)); > } > >

6 years

1
0
0 0

[PATCH AUTOSEL 3.18 01/26] ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup

by Sasha Levin

From: Nathan Chancellor <natechancellor(a)gmail.com> [ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ] When building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from the function omap44xx_prm_late_init() to the function .init.text:omap44xx_prm_enable_io_wakeup() The function omap44xx_prm_late_init() references the function __init omap44xx_prm_enable_io_wakeup(). This is often because omap44xx_prm_late_init lacks a __init annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong. Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there is no more mismatch. Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mach-omap2/prm44xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 0958d070d3db..46e29afe1c09 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -333,7 +333,7 @@ void omap44xx_prm_reconfigure_io_chain(void) * to occur, WAKEUPENABLE bits must be set in the pad mux registers, and * omap44xx_prm_reconfigure_io_chain() must be called. No return value. */ -static void __init omap44xx_prm_enable_io_wakeup(void) +static void omap44xx_prm_enable_io_wakeup(void) { s32 inst = omap4_prmst_get_prm_dev_inst(); -- 2.17.1

6 years

1
25
0 0

[PATCH AUTOSEL 4.4 01/33] ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup

by Sasha Levin

From: Nathan Chancellor <natechancellor(a)gmail.com> [ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ] When building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from the function omap44xx_prm_late_init() to the function .init.text:omap44xx_prm_enable_io_wakeup() The function omap44xx_prm_late_init() references the function __init omap44xx_prm_enable_io_wakeup(). This is often because omap44xx_prm_late_init lacks a __init annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong. Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there is no more mismatch. Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mach-omap2/prm44xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 30768003f854..8c505284bc0c 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -344,7 +344,7 @@ static void omap44xx_prm_reconfigure_io_chain(void) * to occur, WAKEUPENABLE bits must be set in the pad mux registers, and * omap44xx_prm_reconfigure_io_chain() must be called. No return value. */ -static void __init omap44xx_prm_enable_io_wakeup(void) +static void omap44xx_prm_enable_io_wakeup(void) { s32 inst = omap4_prmst_get_prm_dev_inst(); -- 2.17.1

6 years

1
32
0 0

[PATCH AUTOSEL 4.9 01/45] ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup

by Sasha Levin

From: Nathan Chancellor <natechancellor(a)gmail.com> [ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ] When building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from the function omap44xx_prm_late_init() to the function .init.text:omap44xx_prm_enable_io_wakeup() The function omap44xx_prm_late_init() references the function __init omap44xx_prm_enable_io_wakeup(). This is often because omap44xx_prm_late_init lacks a __init annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong. Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there is no more mismatch. Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mach-omap2/prm44xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 30768003f854..8c505284bc0c 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -344,7 +344,7 @@ static void omap44xx_prm_reconfigure_io_chain(void) * to occur, WAKEUPENABLE bits must be set in the pad mux registers, and * omap44xx_prm_reconfigure_io_chain() must be called. No return value. */ -static void __init omap44xx_prm_enable_io_wakeup(void) +static void omap44xx_prm_enable_io_wakeup(void) { s32 inst = omap4_prmst_get_prm_dev_inst(); -- 2.17.1

6 years

1
44
0 0

[PATCH AUTOSEL 4.14 01/69] ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup

by Sasha Levin

From: Nathan Chancellor <natechancellor(a)gmail.com> [ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ] When building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from the function omap44xx_prm_late_init() to the function .init.text:omap44xx_prm_enable_io_wakeup() The function omap44xx_prm_late_init() references the function __init omap44xx_prm_enable_io_wakeup(). This is often because omap44xx_prm_late_init lacks a __init annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong. Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there is no more mismatch. Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mach-omap2/prm44xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 1c0c1663f078..5affa9f5300b 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -344,7 +344,7 @@ static void omap44xx_prm_reconfigure_io_chain(void) * to occur, WAKEUPENABLE bits must be set in the pad mux registers, and * omap44xx_prm_reconfigure_io_chain() must be called. No return value. */ -static void __init omap44xx_prm_enable_io_wakeup(void) +static void omap44xx_prm_enable_io_wakeup(void) { s32 inst = omap4_prmst_get_prm_dev_inst(); -- 2.17.1

6 years

1
68
0 0

patch "usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 2f2dde6ba89b1ef1fe23c1138131b315d9aa4019 Mon Sep 17 00:00:00 2001 From: Harry Pan <harry.pan(a)intel.com> Date: Thu, 29 Nov 2018 00:40:41 +0800 Subject: usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is in 0781:5591, will aggressively request LPM of U1/U2 during runtime, when using this thumb drive as the OS installation key we found the device will generate failure during U1 exit path making it dropped from the USB bus, this causes a corrupted installation in system at the end. i.e., [ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004 [ 166.918327] usb usb2-port2: link state change [ 166.918337] usb usb2-port2: do warm reset [ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms [ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms [ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s [ 167.276050] usb 2-2: USB disconnect, device number 2 [ 167.276058] usb 2-2: unregistering device [ 167.276060] usb 2-2: unregistering interface 2-2:1.0 [ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk [ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00 ... Analyzed the USB trace in the link layer we realized it is because of the 6-ms timer of tRecoveryConfigurationTimeout which documented on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from Recovery.Configuration"; device initiates U1 exit -> Recovery.Active -> Recovery.Configuration, then the host timer timeout makes the link transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset. Interestingly, the other higher volume of SanDisk Ultra Flair sharing the same VID:PID, such as 64GB, would not request LPM during runtime, it sticks at U0 always, thus disabling LPM does not affect those thumb drives at all. The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583. Signed-off-by: Harry Pan <harry.pan(a)intel.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/quirks.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 0690fcff0ea2..514c5214ddb2 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -333,6 +333,10 @@ static const struct usb_device_id usb_quirk_list[] = { /* Midiman M-Audio Keystation 88es */ { USB_DEVICE(0x0763, 0x0192), .driver_info = USB_QUIRK_RESET_RESUME }, + /* SanDisk Ultra Fit and Ultra Flair */ + { USB_DEVICE(0x0781, 0x5583), .driver_info = USB_QUIRK_NO_LPM }, + { USB_DEVICE(0x0781, 0x5591), .driver_info = USB_QUIRK_NO_LPM }, + /* M-Systems Flash Disk Pioneers */ { USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME }, -- 2.19.2

6 years

1
0
0 0

patch "usb: appledisplay: Add 27" Apple Cinema Display" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: appledisplay: Add 27" Apple Cinema Display to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From d7859905301880ad3e16272399d26900af3ac496 Mon Sep 17 00:00:00 2001 From: Alexander Theissen <alex.theissen(a)me.com> Date: Tue, 4 Dec 2018 23:43:35 +0100 Subject: usb: appledisplay: Add 27" Apple Cinema Display Add another Apple Cinema Display to the list of supported displays. Signed-off-by: Alexander Theissen <alex.theissen(a)me.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/appledisplay.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c index 85b48c6ddc7e..39ca31b4de46 100644 --- a/drivers/usb/misc/appledisplay.c +++ b/drivers/usb/misc/appledisplay.c @@ -51,6 +51,7 @@ static const struct usb_device_id appledisplay_table[] = { { APPLEDISPLAY_DEVICE(0x921c) }, { APPLEDISPLAY_DEVICE(0x921d) }, { APPLEDISPLAY_DEVICE(0x9222) }, + { APPLEDISPLAY_DEVICE(0x9226) }, { APPLEDISPLAY_DEVICE(0x9236) }, /* Terminating entry */ -- 2.19.2

6 years

1
0
0 0

Re: [PATCH v2] usb: dwc2: host: use hrtimer for NAK retries

by Doug Anderson

Hi, On Sun, Sep 9, 2018 at 9:24 PM Terin Stock <terin(a)terinstock.com> wrote: > > Modify the wait delay utilize the high resolution timer API to allow for > more precisely scheduled callbacks. > > A previous commit added a 1ms retry delay after multiple consecutive > NAKed transactions using jiffies. On systems with a low timer interrupt > frequency, this delay may be significantly longer than specified, > resulting in misbehavior with some USB devices. > > This scenario was reached on a Raspberry Pi 3B with a Macally FDD-USB > floppy drive (identified as 0424:0fdc Standard Microsystems Corp. > Floppy, based on the USB97CFDC USB FDC). With the relay delay, the drive > would be unable to mount a disk, replying with NAKs until the device was > reset. > > Using ktime, the delta between starting the timer (in dwc2_hcd_qh_add) > and the callback function can be determined. With the original delay > implementation, this value was consistently approximately 12ms. (output > in us). > > <idle>-0 [000] ..s. 1600.559974: dwc2_wait_timer_fn: wait_timer delta: 11976 > <idle>-0 [000] ..s. 1600.571974: dwc2_wait_timer_fn: wait_timer delta: 11977 > <idle>-0 [000] ..s. 1600.583974: dwc2_wait_timer_fn: wait_timer delta: 11976 > <idle>-0 [000] ..s. 1600.595974: dwc2_wait_timer_fn: wait_timer delta: 11977 > > After converting the relay delay to using a higher resolution timer, the > delay was much closer to 1ms. > > <idle>-0 [000] d.h. 1956.553017: dwc2_wait_timer_fn: wait_timer delta: 1002 > <idle>-0 [000] d.h. 1956.554114: dwc2_wait_timer_fn: wait_timer delta: 1002 > <idle>-0 [000] d.h. 1957.542660: dwc2_wait_timer_fn: wait_timer delta: 1004 > <idle>-0 [000] d.h. 1957.543701: dwc2_wait_timer_fn: wait_timer delta: 1002 > > The floppy drive operates properly with delays up to approximately 5ms, > and sends NAKs for any delays that are longer. > > Fixes: 38d2b5fb75c1 ("usb: dwc2: host: Don't retry NAKed transactions right away") > Signed-off-by: Terin Stock <terin(a)terinstock.com> > --- > drivers/usb/dwc2/hcd.h | 2 +- > drivers/usb/dwc2/hcd_queue.c | 19 ++++++++++++------- > 2 files changed, 13 insertions(+), 8 deletions(-) Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Cc: stable(a)vger.kernel.org

6 years

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2018