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

[PATCH 1/2] xhci: workaround CSS timeout on AMD SNPS 3.0 xHC

by Mathias Nyman

From: Sandeep Singh <sandeep.singh(a)amd.com> Occasionally AMD SNPS 3.0 xHC does not respond to CSS when set, also it does not flag anything on SRE and HCE to point the internal xHC errors on USBSTS register. This stalls the entire system wide suspend and there is no point in stalling just because of xHC CSS is not responding. To work around this problem, if the xHC does not flag anything on SRE and HCE, we can skip the CSS timeout and allow the system to continue the suspend. Once the system resume happens we can internally reset the controller using XHCI_RESET_ON_RESUME quirk Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k(a)amd.com> Signed-off-by: Sandeep Singh <Sandeep.Singh(a)amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah(a)amd.com> Cc: <stable(a)vger.kernel.org> Tested-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-pci.c | 4 ++++ drivers/usb/host/xhci.c | 26 ++++++++++++++++++++++---- drivers/usb/host/xhci.h | 3 +++ 3 files changed, 29 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index a951526..a9ec705 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -139,6 +139,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) pdev->device == 0x43bb)) xhci->quirks |= XHCI_SUSPEND_DELAY; + if (pdev->vendor == PCI_VENDOR_ID_AMD && + (pdev->device == 0x15e0 || pdev->device == 0x15e1)) + xhci->quirks |= XHCI_SNPS_BROKEN_SUSPEND; + if (pdev->vendor == PCI_VENDOR_ID_AMD) xhci->quirks |= XHCI_TRUST_TX_LENGTH; diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index c928dbb..c20b85e 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -968,6 +968,7 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup) unsigned int delay = XHCI_MAX_HALT_USEC; struct usb_hcd *hcd = xhci_to_hcd(xhci); u32 command; + u32 res; if (!hcd->state) return 0; @@ -1021,11 +1022,28 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup) command = readl(&xhci->op_regs->command); command |= CMD_CSS; writel(command, &xhci->op_regs->command); + xhci->broken_suspend = 0; if (xhci_handshake(&xhci->op_regs->status, STS_SAVE, 0, 10 * 1000)) { - xhci_warn(xhci, "WARN: xHC save state timeout\n"); - spin_unlock_irq(&xhci->lock); - return -ETIMEDOUT; + /* + * AMD SNPS xHC 3.0 occasionally does not clear the + * SSS bit of USBSTS and when driver tries to poll + * to see if the xHC clears BIT(8) which never happens + * and driver assumes that controller is not responding + * and times out. To workaround this, its good to check + * if SRE and HCE bits are not set (as per xhci + * Section 5.4.2) and bypass the timeout. + */ + res = readl(&xhci->op_regs->status); + if ((xhci->quirks & XHCI_SNPS_BROKEN_SUSPEND) && + (((res & STS_SRE) == 0) && + ((res & STS_HCE) == 0))) { + xhci->broken_suspend = 1; + } else { + xhci_warn(xhci, "WARN: xHC save state timeout\n"); + spin_unlock_irq(&xhci->lock); + return -ETIMEDOUT; + } } spin_unlock_irq(&xhci->lock); @@ -1078,7 +1096,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) set_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags); spin_lock_irq(&xhci->lock); - if (xhci->quirks & XHCI_RESET_ON_RESUME) + if ((xhci->quirks & XHCI_RESET_ON_RESUME) || xhci->broken_suspend) hibernated = true; if (!hibernated) { diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 260b259..c3515ba 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1850,6 +1850,7 @@ struct xhci_hcd { #define XHCI_ZERO_64B_REGS BIT_ULL(32) #define XHCI_DEFAULT_PM_RUNTIME_ALLOW BIT_ULL(33) #define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34) +#define XHCI_SNPS_BROKEN_SUSPEND BIT_ULL(35) unsigned int num_active_eps; unsigned int limit_active_eps; @@ -1879,6 +1880,8 @@ struct xhci_hcd { void *dbc; /* platform-specific data -- must come last */ unsigned long priv[0] __aligned(sizeof(s64)); + /* Broken Suspend flag for SNPS Suspend resume issue */ + u8 broken_suspend; }; /* Platform specific overrides to generic XHCI hc_driver ops */ -- 2.7.4

6 years, 9 months

1
0
0 0

[git:media_tree/master] media: imx274: fix stack corruption in imx274_read_reg

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: imx274: fix stack corruption in imx274_read_reg Author: Luca Ceresoli <luca(a)lucaceresoli.net> Date: Mon Nov 26 11:35:07 2018 -0500 imx274_read_reg() takes a u8 pointer ("reg") and casts it to pass it to regmap_read(), which takes an unsigned int pointer. This results in a corrupted stack and random crashes. Fixes: 0985dd306f72 ("media: imx274: V4l2 driver for Sony imx274 CMOS sensor") Cc: stable(a)vger.kernel.org # for 4.15 and up Signed-off-by: Luca Ceresoli <luca(a)lucaceresoli.net> Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/i2c/imx274.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c index 11c69281692e..95a0e7d9851a 100644 --- a/drivers/media/i2c/imx274.c +++ b/drivers/media/i2c/imx274.c @@ -619,16 +619,19 @@ static int imx274_write_table(struct stimx274 *priv, const struct reg_8 table[]) static inline int imx274_read_reg(struct stimx274 *priv, u16 addr, u8 *val) { + unsigned int uint_val; int err; - err = regmap_read(priv->regmap, addr, (unsigned int *)val); + err = regmap_read(priv->regmap, addr, &uint_val); if (err) dev_err(&priv->client->dev, "%s : i2c read failed, addr = %x\n", __func__, addr); else dev_dbg(&priv->client->dev, "%s : addr 0x%x, val=0x%x\n", __func__, - addr, *val); + addr, uint_val); + + *val = uint_val; return err; }

6 years, 9 months

1
0
0 0

[RESEND PATCH v3] drm/msm: Move fence put to where failure occurs

by Robert Foss

If dma_fence_wait fails to wait for a supplied in-fence in msm_ioctl_gem_submit, make sure we release that in-fence. Also remove this dma_fence_put() from the 'out' label. Signed-off-by: Robert Foss <robert.foss(a)collabora.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/msm/msm_gem_submit.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index a90aedd6883a..d5e6665a4c8f 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, struct msm_file_private *ctx = file->driver_priv; struct msm_gem_submit *submit; struct msm_gpu *gpu = priv->gpu; - struct dma_fence *in_fence = NULL; struct sync_file *sync_file = NULL; struct msm_gpu_submitqueue *queue; struct msm_ringbuffer *ring; @@ -444,6 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, ring = gpu->rb[queue->prio]; if (args->flags & MSM_SUBMIT_FENCE_FD_IN) { + struct dma_fence *in_fence; + in_fence = sync_file_get_fence(args->fence_fd); if (!in_fence) @@ -453,11 +454,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, * Wait if the fence is from a foreign context, or if the fence * array contains any fence from a foreign context. */ - if (!dma_fence_match_context(in_fence, ring->fctx->context)) { + ret = 0; + if (!dma_fence_match_context(in_fence, ring->fctx->context)) ret = dma_fence_wait(in_fence, true); - if (ret) - return ret; - } + + dma_fence_put(in_fence); + if (ret) + return ret; } ret = mutex_lock_interruptible(&dev->struct_mutex); @@ -583,8 +586,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, } out: - if (in_fence) - dma_fence_put(in_fence); submit_cleanup(submit); if (ret) msm_gem_submit_free(submit); -- 2.17.1

6 years, 9 months

2
2
0 0

[PATCH] USB: serial: console: fix reported terminal settings

by Johan Hovold

The USB-serial console implementation has never reported the actual terminal settings used. Despite storing the corresponding cflags in its struct console, this was never honoured on later tty open() where the tty termios would be left initialised to the driver defaults. Unlike the serial console implementation, the USB-serial code calls subdriver open() already at console setup. While calling set_termios() before open() looks like it could work for some USB-serial drivers, others definitely do not expect this, so modelling this after serial core is going to be intrusive, if at all possible. Instead, use a (renamed) tty helper to save the termios data used at console setup, so that the tty termios reflects the actual terminal settings after a subsequent tty open(). Note that the calls to tty_init_termios() (tty_driver_install()) and tty_save_termios() are serialised using the disconnect mutex. This specifically fixes a regression that was triggered by a recent change adding software flow control to the pl2303 driver: a getty trying to disable flow control while leaving the baud rate unchanged would now also set the baud rate to the driver default (prior to the flow-control change this had been a noop). Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control") Cc: stable <stable(a)vger.kernel.org> # 4.18 Reported-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> Cc: Florian Zumbiehl <florz(a)florz.de> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/tty/tty_io.c | 11 +++++++++-- drivers/usb/serial/console.c | 2 +- include/linux/tty.h | 1 + 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index ee80dfbd5442..687250ec8032 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1373,7 +1373,13 @@ struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx) return ERR_PTR(retval); } -static void tty_free_termios(struct tty_struct *tty) +/** + * tty_save_termios() - save tty termios data in driver table + * @tty: tty whose termios data to save + * + * Locking: Caller guarantees serialisation with tty_init_termios(). + */ +void tty_save_termios(struct tty_struct *tty) { struct ktermios *tp; int idx = tty->index; @@ -1392,6 +1398,7 @@ static void tty_free_termios(struct tty_struct *tty) } *tp = tty->termios; } +EXPORT_SYMBOL_GPL(tty_save_termios); /** * tty_flush_works - flush all works of a tty/pty pair @@ -1491,7 +1498,7 @@ static void release_tty(struct tty_struct *tty, int idx) WARN_ON(!mutex_is_locked(&tty_mutex)); if (tty->ops->shutdown) tty->ops->shutdown(tty); - tty_free_termios(tty); + tty_save_termios(tty); tty_driver_remove_tty(tty->driver, tty); tty->port->itty = NULL; if (tty->link) diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c index 17940589c647..7d289302ff6c 100644 --- a/drivers/usb/serial/console.c +++ b/drivers/usb/serial/console.c @@ -101,7 +101,6 @@ static int usb_console_setup(struct console *co, char *options) cflag |= PARENB; break; } - co->cflag = cflag; /* * no need to check the index here: if the index is wrong, console @@ -164,6 +163,7 @@ static int usb_console_setup(struct console *co, char *options) serial->type->set_termios(tty, port, &dummy); tty_port_tty_set(&port->port, NULL); + tty_save_termios(tty); tty_kref_put(tty); } tty_port_set_initialized(&port->port, 1); diff --git a/include/linux/tty.h b/include/linux/tty.h index 414db2bce715..392138fe59b6 100644 --- a/include/linux/tty.h +++ b/include/linux/tty.h @@ -556,6 +556,7 @@ extern struct tty_struct *tty_init_dev(struct tty_driver *driver, int idx); extern void tty_release_struct(struct tty_struct *tty, int idx); extern int tty_release(struct inode *inode, struct file *filp); extern void tty_init_termios(struct tty_struct *tty); +extern void tty_save_termios(struct tty_struct *tty); extern int tty_standard_install(struct tty_driver *driver, struct tty_struct *tty); -- 2.19.2

6 years, 9 months

3
8
0 0

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, 9 months

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, 9 months

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, 9 months

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, 9 months

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, 9 months

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, 9 months

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, 9 months

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, 9 months

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, 9 months

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, 9 months

3
3
0 0

patch "staging: rtl8712: Fix possible buffer overrun" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8712: Fix possible buffer overrun to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 300cd664865bed5d50ae0a42fb4e3a6f415e8a10 Mon Sep 17 00:00:00 2001 From: Young Xiao <YangX92(a)hotmail.com> Date: Wed, 28 Nov 2018 08:06:53 +0000 Subject: staging: rtl8712: Fix possible buffer overrun In commit 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun") we fix a potential off by one by making the limit smaller. The better fix is to make the buffer larger. This makes it match up with the similar code in other drivers. Fixes: 8b7a13c3f404 ("staging: r8712u: Fix possible buffer overrun") Signed-off-by: Young Xiao <YangX92(a)hotmail.com> Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8712/mlme_linux.c | 2 +- drivers/staging/rtl8712/rtl871x_mlme.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8712/mlme_linux.c b/drivers/staging/rtl8712/mlme_linux.c index 9d156efbc9ed..4d473f008aa4 100644 --- a/drivers/staging/rtl8712/mlme_linux.c +++ b/drivers/staging/rtl8712/mlme_linux.c @@ -146,7 +146,7 @@ void r8712_report_sec_ie(struct _adapter *adapter, u8 authmode, u8 *sec_ie) p = buff; p += sprintf(p, "ASSOCINFO(ReqIEs="); len = sec_ie[1] + 2; - len = (len < IW_CUSTOM_MAX) ? len : IW_CUSTOM_MAX - 1; + len = (len < IW_CUSTOM_MAX) ? len : IW_CUSTOM_MAX; for (i = 0; i < len; i++) p += sprintf(p, "%02x", sec_ie[i]); p += sprintf(p, ")"); diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c b/drivers/staging/rtl8712/rtl871x_mlme.c index a7374006a9fb..986a1d526918 100644 --- a/drivers/staging/rtl8712/rtl871x_mlme.c +++ b/drivers/staging/rtl8712/rtl871x_mlme.c @@ -1346,7 +1346,7 @@ sint r8712_restruct_sec_ie(struct _adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_len) { u8 authmode = 0, match; - u8 sec_ie[255], uncst_oui[4], bkup_ie[255]; + u8 sec_ie[IW_CUSTOM_MAX], uncst_oui[4], bkup_ie[255]; u8 wpa_oui[4] = {0x0, 0x50, 0xf2, 0x01}; uint ielength, cnt, remove_cnt; int iEntry; -- 2.19.2

6 years, 9 months

1
0
0 0

patch "Revert commit ef9209b642f "staging: rtl8723bs: Fix indenting errors" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert commit ef9209b642f "staging: rtl8723bs: Fix indenting errors to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 87e4a5405f087427fbf8b437d2796283dce2b38f Mon Sep 17 00:00:00 2001 From: Young Xiao <YangX92(a)hotmail.com> Date: Tue, 27 Nov 2018 09:12:20 +0000 Subject: Revert commit ef9209b642f "staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c" pstapriv->max_num_sta is always <= NUM_STA, since max_num_sta is either set in _rtw_init_sta_priv() or rtw_set_beacon(). Fixes: ef9209b642f1 ("staging: rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c") Signed-off-by: Young Xiao <YangX92(a)hotmail.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c index 69c7abc0e3a5..8445d516c93d 100644 --- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c +++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c @@ -1565,7 +1565,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame) if (pstat->aid > 0) { DBG_871X(" old AID %d\n", pstat->aid); } else { - for (pstat->aid = 1; pstat->aid < NUM_STA; pstat->aid++) + for (pstat->aid = 1; pstat->aid <= NUM_STA; pstat->aid++) if (pstapriv->sta_aid[pstat->aid - 1] == NULL) break; -- 2.19.2

6 years, 9 months

1
0
0 0

[to-be-updated] panic-avoid-the-extra-noise-dmesg.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: panic: Avoid the extra noise dmesg has been removed from the -mm tree. Its filename was panic-avoid-the-extra-noise-dmesg.patch This patch was dropped because an updated version will be merged ------------------------------------------------------ From: Feng Tang <feng.tang(a)intel.com> Subject: panic: Avoid the extra noise dmesg When kernel panic happens, it will first print the panic call stack, then the ending msg like: [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception [ 35.749975] ------------[ cut here ]------------ The above message are very useful for debugging. But if system is configured to not reboot on panic, say the "panic_timeout" parameter equals 0, it will likely print out many noisy message like WARN() call stack for each and every CPU except the panic one, messages like below: WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190 Call Trace: <IRQ> try_to_wake_up default_wake_function autoremove_wake_function __wake_up_common __wake_up_common_lock __wake_up wake_up_klogd_work_func irq_work_run_list irq_work_tick update_process_times tick_sched_timer __hrtimer_run_queues hrtimer_interrupt smp_apic_timer_interrupt apic_timer_interrupt For people working in console mode, the screen will first show the panic call stack, but immediately overridded by these noisy extra messages, which makes debugging much more difficult, as the original context gets lost on screen. Also these noisy messages will confuse some users, as I have seen many bug reporters posted the noisy message into bugzilla, instead of the real panic call stack and context. Removing the "local_irq_enable" will avoid the noisy message. The justification for the removing is: when code runs to this point, it means user has chosed to not reboot, or do any special handling by using the panic notifier method, no much point in re-enabling the interrupt. Link: http://lkml.kernel.org/r/1543902228-23834-1-git-send-email-feng.tang@intel.… Signed-off-by: Feng Tang <feng.tang(a)intel.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Kees Cook <keescook(a)chromium.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Petr Mladek <pmladek(a)suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/kernel/panic.c~panic-avoid-the-extra-noise-dmesg +++ a/kernel/panic.c @@ -322,7 +322,6 @@ void panic(const char *fmt, ...) } #endif pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf); - local_irq_enable(); for (i = 0; ; i += PANIC_TIMER_STEP) { touch_softlockup_watchdog(); if (i >= i_next) { _ Patches currently in -mm which might be from feng.tang(a)intel.com are panic-add-options-to-print-system-info-when-panic-happens.patch kernel-sysctl-add-panic_print-into-sysctl.patch

6 years, 9 months

1
0
0 0

[PATCH] gfs2: Fix loop in gfs2_rbm_find

by Andreas Gruenbacher

In gfs2_rbm_find, fix the resource group wrap-around logic that commit e579ed4f44 broke. Without this fix, gfs2_rbm_find can end up in an infinite loop in the worst case. Fixes: e579ed4f44 ("GFS2: Introduce rbm field bii") Cc: stable(a)vger.kernel.org # v3.13+ Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Bob Peterson <rpeterso(a)redhat.com> --- fs/gfs2/rgrp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index b08a530433adf..8d79165703621 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -1780,9 +1780,9 @@ static int gfs2_rbm_find(struct gfs2_rbm *rbm, u8 state, u32 *minext, goto next_iter; } if (ret == -E2BIG) { + n += rbm->bii - initial_bii; rbm->bii = 0; rbm->offset = 0; - n += (rbm->bii - initial_bii); goto res_covered_end_of_rgrp; } return ret; -- 2.19.1.546.g028f9c799.dirty

6 years, 9 months

1
0
0 0

[PATCH] clk: aspeed: Mark lclk (LPC) and espiclk (eSPI) as critical

by Jae Hyun Yoo

These interfaces are used by host to talk to BMC, and the clock source is from the host, usually from PCH. So this commit marks the lclk as critical to make it able to be enabled. Also, it marks espiclk too because eSPI is sharing the same interface with LPC. Fixes: 15ed8ce5f84e ("clk: aspeed: Register gated clocks") Cc: stable(a)vger.kernel.org Cc: Joel Stanley <joel(a)jms.id.au> Cc: Andrew Jeffery <andrew(a)aj.id.au> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo(a)linux.intel.com> --- drivers/clk/clk-aspeed.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c index 596136793fc4..01633ad85683 100644 --- a/drivers/clk/clk-aspeed.c +++ b/drivers/clk/clk-aspeed.c @@ -95,7 +95,7 @@ static const struct aspeed_gate_data aspeed_gates[] = { [ASPEED_CLK_GATE_DCLK] = { 5, -1, "dclk-gate", NULL, CLK_IS_CRITICAL }, /* DAC */ [ASPEED_CLK_GATE_REFCLK] = { 6, -1, "refclk-gate", "clkin", CLK_IS_CRITICAL }, [ASPEED_CLK_GATE_USBPORT2CLK] = { 7, 3, "usb-port2-gate", NULL, 0 }, /* USB2.0 Host port 2 */ - [ASPEED_CLK_GATE_LCLK] = { 8, 5, "lclk-gate", NULL, 0 }, /* LPC */ + [ASPEED_CLK_GATE_LCLK] = { 8, 5, "lclk-gate", NULL, CLK_IS_CRITICAL }, /* LPC */ [ASPEED_CLK_GATE_USBUHCICLK] = { 9, 15, "usb-uhci-gate", NULL, 0 }, /* USB1.1 (requires port 2 enabled) */ [ASPEED_CLK_GATE_D1CLK] = { 10, 13, "d1clk-gate", NULL, 0 }, /* GFX CRT */ [ASPEED_CLK_GATE_YCLK] = { 13, 4, "yclk-gate", NULL, 0 }, /* HAC */ @@ -103,7 +103,7 @@ static const struct aspeed_gate_data aspeed_gates[] = { [ASPEED_CLK_GATE_UART1CLK] = { 15, -1, "uart1clk-gate", "uart", 0 }, /* UART1 */ [ASPEED_CLK_GATE_UART2CLK] = { 16, -1, "uart2clk-gate", "uart", 0 }, /* UART2 */ [ASPEED_CLK_GATE_UART5CLK] = { 17, -1, "uart5clk-gate", "uart", 0 }, /* UART5 */ - [ASPEED_CLK_GATE_ESPICLK] = { 19, -1, "espiclk-gate", NULL, 0 }, /* eSPI */ + [ASPEED_CLK_GATE_ESPICLK] = { 19, -1, "espiclk-gate", NULL, CLK_IS_CRITICAL }, /* eSPI */ [ASPEED_CLK_GATE_MAC1CLK] = { 20, 11, "mac1clk-gate", "mac", 0 }, /* MAC1 */ [ASPEED_CLK_GATE_MAC2CLK] = { 21, 12, "mac2clk-gate", "mac", 0 }, /* MAC2 */ [ASPEED_CLK_GATE_RSACLK] = { 24, -1, "rsaclk-gate", NULL, 0 }, /* RSA */ -- 2.7.4

6 years, 9 months

2
2
0 0

stable-rc/linux-4.14.y boot: 122 boots: 0 failed, 120 passed with 2 offline (v4.14.85-149-ga5c883b384be)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 122 boots: 0 failed, 120 passed with 2 offline (v4.14.85-149-ga5c883b384be) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.85-14… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.85-149-ga5c883b384be Git Commit: a5c883b384be3a583f2875dc44c9ec3941803121 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 61 unique boards, 23 SoC families, 15 builds out of 197 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab arm64: defconfig: meson-gxl-s905x-p212: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 9 months

1
0
0 0

stable-rc/linux-4.4.y boot: 99 boots: 1 failed, 97 passed with 1 offline (v4.4.166-21-g9caf29c799ac)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 99 boots: 1 failed, 97 passed with 1 offline (v4.4.166-21-g9caf29c799ac) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.166-21-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.166-21-g9caf29c799ac Git Commit: 9caf29c799ac405d81f6a60921ea58fd9e33356c Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 20 SoC families, 15 builds out of 187 Boot Failure Detected: arm64: defconfig qcom-qdf2400: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 9 months

1
0
0 0

stable-rc/linux-4.14.y boot: 120 boots: 0 failed, 118 passed with 2 offline (v4.14.85-147-g2bfd08691add)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 120 boots: 0 failed, 118 passed with 2 offline (v4.14.85-147-g2bfd08691add) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.85-14… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.85-147-g2bfd08691add Git Commit: 2bfd08691add5955f6d58006360c4a78edce64d0 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 59 unique boards, 23 SoC families, 14 builds out of 197 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab arm64: defconfig: meson-gxl-s905x-p212: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 9 months

1
0
0 0

[PATCH] ASoC: intel: cht_bsw_max98090_ti: Add pmc_plt_clk_0 quirk for Chromebook Clapper

by Hans de Goede

The Clapper model Chromebook uses pmc_plt_clk_0 instead of pmc_plt_clk_3 for the mclk, just like the Swanky model. This commit adds a DMI based quirk for this. This fixing audio no longer working on these devices after commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") that commit fixes us unnecessary keeping unused clocks on, but in case of the Clapper that was breaking audio support since we were not using the right clock in the cht_bsw_max98090_ti machine driver. Cc: stable(a)vger.kernel.org Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/boards/cht_bsw_max98090_ti.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/intel/boards/cht_bsw_max98090_ti.c b/sound/soc/intel/boards/cht_bsw_max98090_ti.c index 9d9f6e41d81c..ad0c98383853 100644 --- a/sound/soc/intel/boards/cht_bsw_max98090_ti.c +++ b/sound/soc/intel/boards/cht_bsw_max98090_ti.c @@ -389,6 +389,13 @@ static struct snd_soc_card snd_soc_card_cht = { }; static const struct dmi_system_id cht_max98090_quirk_table[] = { + { + /* Clapper model Chromebook */ + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "Clapper"), + }, + .driver_data = (void *)QUIRK_PMC_PLT_CLK_0, + }, { /* Swanky model Chromebook (Toshiba Chromebook 2) */ .matches = { -- 2.19.1

6 years, 9 months

3
2
0 0

stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 117 passed with 2 offline, 1 untried/unknown (v4.19.6-140-g987a6da5152c)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 117 passed with 2 offline, 1 untried/unknown (v4.19.6-140-g987a6da5152c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.6-140… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.6-140-g987a6da5152c Git Commit: 987a6da5152c29e37cc11de9a2d10a23a48015c9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 62 unique boards, 23 SoC families, 15 builds out of 202 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab arm64: defconfig: meson-gxl-s905x-p212: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 9 months

1
0
0 0

[PATCH v1 1/5] dmaengine: dw: Fix FIFO size for Intel Merrifield

by Andy Shevchenko

Intel Merrifield has a reduced size of FIFO used in iDMA 32-bit controller, i.e. 512 bytes instead of 1024. Fix this by partitioning it as 64 bytes per channel. Note, in the future we might switch to 'fifo-size' property instead of hard coded value. Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/dma/dw/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c index d0c3e50b39fb..e85b078fc207 100644 --- a/drivers/dma/dw/core.c +++ b/drivers/dma/dw/core.c @@ -1059,12 +1059,12 @@ static void dwc_issue_pending(struct dma_chan *chan) /* * Program FIFO size of channels. * - * By default full FIFO (1024 bytes) is assigned to channel 0. Here we + * By default full FIFO (512 bytes) is assigned to channel 0. Here we * slice FIFO on equal parts between channels. */ static void idma32_fifo_partition(struct dw_dma *dw) { - u64 value = IDMA32C_FP_PSIZE_CH0(128) | IDMA32C_FP_PSIZE_CH1(128) | + u64 value = IDMA32C_FP_PSIZE_CH0(64) | IDMA32C_FP_PSIZE_CH1(64) | IDMA32C_FP_UPDATE; u64 fifo_partition = 0; -- 2.19.2

6 years, 9 months

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror