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

patch "tty: serial: owl: add "much needed" clk_prepare_enable()" 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: owl: add "much needed" clk_prepare_enable() 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 abf42d2f333b21bf8d33b2fbb8a85fa62037ac01 Mon Sep 17 00:00:00 2001 From: Amit Singh Tomar <amittomer25(a)gmail.com> Date: Fri, 17 Apr 2020 01:41:57 +0530 Subject: tty: serial: owl: add "much needed" clk_prepare_enable() commit 8ba92cf59335 ("arm64: dts: actions: s700: Add Clock Management Unit") breaks the UART on Cubieboard7-lite (based on S700 SoC), This is due to the fact that generic clk routine clk_disable_unused() disables the gate clks, and that in turns disables OWL UART (but UART driver never enables it). To prove this theory, Andre suggested to use "clk_ignore_unused" in kernel commnd line and it worked (Kernel happily lands into RAMFS world :)). This commit fix this up by adding clk_prepare_enable(). Fixes: 8ba92cf59335 ("arm64: dts: actions: s700: Add Clock Management Unit") Signed-off-by: Amit Singh Tomar <amittomer25(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/1587067917-1400-1-git-send-email-amittomer25@gmai… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/owl-uart.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c index 42c8cc93b603..c149f8c30007 100644 --- a/drivers/tty/serial/owl-uart.c +++ b/drivers/tty/serial/owl-uart.c @@ -680,6 +680,12 @@ static int owl_uart_probe(struct platform_device *pdev) return PTR_ERR(owl_port->clk); } + ret = clk_prepare_enable(owl_port->clk); + if (ret) { + dev_err(&pdev->dev, "could not enable clk\n"); + return ret; + } + owl_port->port.dev = &pdev->dev; owl_port->port.line = pdev->id; owl_port->port.type = PORT_OWL; @@ -712,6 +718,7 @@ static int owl_uart_remove(struct platform_device *pdev) uart_remove_one_port(&owl_uart_driver, &owl_port->port); owl_uart_ports[pdev->id] = NULL; + clk_disable_unprepare(owl_port->clk); return 0; } -- 2.26.2

5 years, 8 months

1
0
0 0

patch "vt: don't use kmalloc() for the unicode screen buffer" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vt: don't use kmalloc() for the unicode screen buffer 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 9a98e7a80f95378c9ee0c644705e3b5aa54745f1 Mon Sep 17 00:00:00 2001 From: Nicolas Pitre <nico(a)fluxnic.net> Date: Sat, 28 Mar 2020 22:25:11 -0400 Subject: vt: don't use kmalloc() for the unicode screen buffer Even if the actual screen size is bounded in vc_do_resize(), the unicode buffer is still a little more than twice the size of the glyph buffer and may exceed MAX_ORDER down the kmalloc() path. This can be triggered from user space. Since there is no point having a physically contiguous buffer here, let's avoid the above issue as well as reducing pressure on high order allocations by using vmalloc() instead. Signed-off-by: Nicolas Pitre <nico(a)fluxnic.net> Cc: <stable(a)vger.kernel.org> Acked-by: Sam Ravnborg <sam(a)ravnborg.org> Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.2003282214210.2671@knanqh.ubzr Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/vt/vt.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 309a39197be0..3272759b1f3c 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -81,6 +81,7 @@ #include <linux/errno.h> #include <linux/kd.h> #include <linux/slab.h> +#include <linux/vmalloc.h> #include <linux/major.h> #include <linux/mm.h> #include <linux/console.h> @@ -350,7 +351,7 @@ static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows) /* allocate everything in one go */ memsize = cols * rows * sizeof(char32_t); memsize += rows * sizeof(char32_t *); - p = kmalloc(memsize, GFP_KERNEL); + p = vmalloc(memsize); if (!p) return NULL; @@ -366,7 +367,7 @@ static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows) static void vc_uniscr_set(struct vc_data *vc, struct uni_screen *new_uniscr) { - kfree(vc->vc_uni_screen); + vfree(vc->vc_uni_screen); vc->vc_uni_screen = new_uniscr; } -- 2.26.2

5 years, 8 months

1
0
0 0

stable-rc/linux-4.4.y boot: 64 boots: 3 failed, 53 passed with 6 offline, 2 untried/unknown (v4.4.219-101-gacb152478366)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 64 boots: 3 failed, 53 passed with 6 offline, 2 untried/unknown (v4.4.219-101-gacb152478366) 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.219-101… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.219-101-gacb152478366 Git Commit: acb1524783663f011864b65a135442403625d4b8 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 41 unique boards, 15 SoC families, 16 builds out of 190 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.4.219-83-g20fbd20eb91a) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.4.219-83-g20fbd20eb91a) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 74 days (last pass: v4.4.212-56-g758a39807529 - first fail: v4.4.213-28-ga3b43e6eae91) i386: i386_defconfig: gcc-8: qemu_i386: lab-collabora: new failure (last pass: v4.4.219-83-g20fbd20eb91a) Boot Failures Detected: arm: multi_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab imx_v4_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab i386: i386_defconfig: gcc-8: qemu_i386: 1 failed lab Offline Platforms: arm: qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable-rc/linux-4.4.y build: 23 builds: 0 failed, 23 passed (v4.4.219-100-gb7353bd580c0)

by kernelci.org bot

stable-rc/linux-4.4.y build: 23 builds: 0 failed, 23 passed (v4.4.219-100-gb7353bd580c0) Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.219-100… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.219-100-gb7353bd580c0 Git Commit: b7353bd580c08b4aef6e29998477a8c6c44e0e4b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Built: 4 unique architectures ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- acs5k_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- axs103_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- axs103_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- bcm47xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- bcm63xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- cerfcube_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- cns3420vb_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- em_x270_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- imx_v6_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- iop13xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- ls1b_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- lubbock_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- malta_kvm_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- maltasmvp_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- maltaup_xpa_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- markeins_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- multi_v5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- mv78xx0_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- qcom_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- s5pv210_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- socfpga_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- sunxi_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

patch "USB: sisusbvga: Change port variable from signed to unsigned" 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: sisusbvga: Change port variable from signed to unsigned 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 2df7405f79ce1674d73c2786fe1a8727c905d65b Mon Sep 17 00:00:00 2001 From: Changming Liu <liu.changm(a)northeastern.edu> Date: Mon, 20 Apr 2020 23:41:25 -0400 Subject: USB: sisusbvga: Change port variable from signed to unsigned Change a bunch of arguments of wrapper functions which pass signed integer to an unsigned integer which might cause undefined behaviors when sign integer overflow. Signed-off-by: Changming Liu <liu.changm(a)northeastern.edu> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/BL0PR06MB45482D71EA822D75A0E60A2EE5D50@BL0PR06MB4… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/sisusbvga/sisusb.c | 20 ++++++++++---------- drivers/usb/misc/sisusbvga/sisusb_init.h | 14 +++++++------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/usb/misc/sisusbvga/sisusb.c b/drivers/usb/misc/sisusbvga/sisusb.c index 2ab9600d0898..fc8a5da4a07c 100644 --- a/drivers/usb/misc/sisusbvga/sisusb.c +++ b/drivers/usb/misc/sisusbvga/sisusb.c @@ -1199,18 +1199,18 @@ static int sisusb_read_mem_bulk(struct sisusb_usb_data *sisusb, u32 addr, /* High level: Gfx (indexed) register access */ #ifdef CONFIG_USB_SISUSBVGA_CON -int sisusb_setreg(struct sisusb_usb_data *sisusb, int port, u8 data) +int sisusb_setreg(struct sisusb_usb_data *sisusb, u32 port, u8 data) { return sisusb_write_memio_byte(sisusb, SISUSB_TYPE_IO, port, data); } -int sisusb_getreg(struct sisusb_usb_data *sisusb, int port, u8 *data) +int sisusb_getreg(struct sisusb_usb_data *sisusb, u32 port, u8 *data) { return sisusb_read_memio_byte(sisusb, SISUSB_TYPE_IO, port, data); } #endif -int sisusb_setidxreg(struct sisusb_usb_data *sisusb, int port, +int sisusb_setidxreg(struct sisusb_usb_data *sisusb, u32 port, u8 index, u8 data) { int ret; @@ -1220,7 +1220,7 @@ int sisusb_setidxreg(struct sisusb_usb_data *sisusb, int port, return ret; } -int sisusb_getidxreg(struct sisusb_usb_data *sisusb, int port, +int sisusb_getidxreg(struct sisusb_usb_data *sisusb, u32 port, u8 index, u8 *data) { int ret; @@ -1230,7 +1230,7 @@ int sisusb_getidxreg(struct sisusb_usb_data *sisusb, int port, return ret; } -int sisusb_setidxregandor(struct sisusb_usb_data *sisusb, int port, u8 idx, +int sisusb_setidxregandor(struct sisusb_usb_data *sisusb, u32 port, u8 idx, u8 myand, u8 myor) { int ret; @@ -1245,7 +1245,7 @@ int sisusb_setidxregandor(struct sisusb_usb_data *sisusb, int port, u8 idx, } static int sisusb_setidxregmask(struct sisusb_usb_data *sisusb, - int port, u8 idx, u8 data, u8 mask) + u32 port, u8 idx, u8 data, u8 mask) { int ret; u8 tmp; @@ -1258,13 +1258,13 @@ static int sisusb_setidxregmask(struct sisusb_usb_data *sisusb, return ret; } -int sisusb_setidxregor(struct sisusb_usb_data *sisusb, int port, +int sisusb_setidxregor(struct sisusb_usb_data *sisusb, u32 port, u8 index, u8 myor) { return sisusb_setidxregandor(sisusb, port, index, 0xff, myor); } -int sisusb_setidxregand(struct sisusb_usb_data *sisusb, int port, +int sisusb_setidxregand(struct sisusb_usb_data *sisusb, u32 port, u8 idx, u8 myand) { return sisusb_setidxregandor(sisusb, port, idx, myand, 0x00); @@ -2785,8 +2785,8 @@ static loff_t sisusb_lseek(struct file *file, loff_t offset, int orig) static int sisusb_handle_command(struct sisusb_usb_data *sisusb, struct sisusb_command *y, unsigned long arg) { - int retval, port, length; - u32 address; + int retval, length; + u32 port, address; /* All our commands require the device * to be initialized. diff --git a/drivers/usb/misc/sisusbvga/sisusb_init.h b/drivers/usb/misc/sisusbvga/sisusb_init.h index 1782c759c4ad..ace09985dae4 100644 --- a/drivers/usb/misc/sisusbvga/sisusb_init.h +++ b/drivers/usb/misc/sisusbvga/sisusb_init.h @@ -812,17 +812,17 @@ static const struct SiS_VCLKData SiSUSB_VCLKData[] = { int SiSUSBSetMode(struct SiS_Private *SiS_Pr, unsigned short ModeNo); int SiSUSBSetVESAMode(struct SiS_Private *SiS_Pr, unsigned short VModeNo); -extern int sisusb_setreg(struct sisusb_usb_data *sisusb, int port, u8 data); -extern int sisusb_getreg(struct sisusb_usb_data *sisusb, int port, u8 * data); -extern int sisusb_setidxreg(struct sisusb_usb_data *sisusb, int port, +extern int sisusb_setreg(struct sisusb_usb_data *sisusb, u32 port, u8 data); +extern int sisusb_getreg(struct sisusb_usb_data *sisusb, u32 port, u8 * data); +extern int sisusb_setidxreg(struct sisusb_usb_data *sisusb, u32 port, u8 index, u8 data); -extern int sisusb_getidxreg(struct sisusb_usb_data *sisusb, int port, +extern int sisusb_getidxreg(struct sisusb_usb_data *sisusb, u32 port, u8 index, u8 * data); -extern int sisusb_setidxregandor(struct sisusb_usb_data *sisusb, int port, +extern int sisusb_setidxregandor(struct sisusb_usb_data *sisusb, u32 port, u8 idx, u8 myand, u8 myor); -extern int sisusb_setidxregor(struct sisusb_usb_data *sisusb, int port, +extern int sisusb_setidxregor(struct sisusb_usb_data *sisusb, u32 port, u8 index, u8 myor); -extern int sisusb_setidxregand(struct sisusb_usb_data *sisusb, int port, +extern int sisusb_setidxregand(struct sisusb_usb_data *sisusb, u32 port, u8 idx, u8 myand); void sisusb_delete(struct kref *kref); -- 2.26.2

5 years, 8 months

1
0
0 0

[RESEND PATCH v2 1/2] driver core: platform: Initialize dma_parms for platform devices

by Ulf Hansson

It's currently the platform driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The benefit with this approach allows us to avoid the initialization and to not waste memory for the struct device_dma_parameters, as this can be decided on a case by case basis. However, it has turned out that this approach is not very practical. Not only does it lead to open coding, but also to real errors. In principle callers of dma_set_max_seg_size() doesn't check the error code, but just assumes it succeeds. For these reasons, let's do the initialization from the common platform bus at the device registration point. This also follows the way the PCI devices are being managed, see pci_device_add(). Suggested-by: Christoph Hellwig <hch(a)lst.de> Cc: <stable(a)vger.kernel.org> Tested-by: Haibo Chen <haibo.chen(a)nxp.com> Reviewed-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> --- drivers/base/platform.c | 2 ++ include/linux/platform_device.h | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 5255550b7c34..b27d0f6c18c9 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -380,6 +380,8 @@ struct platform_object { */ static void setup_pdev_dma_masks(struct platform_device *pdev) { + pdev->dev.dma_parms = &pdev->dma_parms; + if (!pdev->dev.coherent_dma_mask) pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); if (!pdev->dev.dma_mask) { diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index bdc35753ef7c..77a2aada106d 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -25,6 +25,7 @@ struct platform_device { bool id_auto; struct device dev; u64 platform_dma_mask; + struct device_dma_parameters dma_parms; u32 num_resources; struct resource *resource; -- 2.20.1

5 years, 8 months

3
2
0 0

patch "USB: hub: Revert commit bd0e6c9614b9 ("usb: hub: try old enumeration" 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: hub: Revert commit bd0e6c9614b9 ("usb: hub: try old enumeration 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 3155f4f40811c5d7e3c686215051acf504e05565 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 22 Apr 2020 16:13:08 -0400 Subject: USB: hub: Revert commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") Commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") changed the way the hub driver enumerates high-speed devices. Instead of using the "new" enumeration scheme first and switching to the "old" scheme if that doesn't work, we start with the "old" scheme. In theory this is better because the "old" scheme is slightly faster -- it involves resetting the device only once instead of twice. However, for a long time Windows used only the "new" scheme. Zeng Tao said that Windows 8 and later use the "old" scheme for high-speed devices, but apparently there are some devices that don't like it. William Bader reports that the Ricoh webcam built into his Sony Vaio laptop not only doesn't enumerate under the "old" scheme, it gets hung up so badly that it won't then enumerate under the "new" scheme! Only a cold reset will fix it. Therefore we will revert the commit and go back to trying the "new" scheme first for high-speed devices. Reported-and-tested-by: William Bader <williambader(a)hotmail.com> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207219 Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") CC: Zeng Tao <prime.zeng(a)hisilicon.com> CC: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221611230.11262-100000@iolant… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/admin-guide/kernel-parameters.txt | 3 +-- drivers/usb/core/hub.c | 4 +--- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f2a93c8679e8..7bc83f3d9bdf 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5187,8 +5187,7 @@ usbcore.old_scheme_first= [USB] Start with the old device initialization - scheme, applies only to low and full-speed devices - (default 0 = off). + scheme (default 0 = off). usbcore.usbfs_memory_mb= [USB] Memory limit (in MB) for buffers allocated by diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 83549f009ced..2b6565c06c23 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2728,13 +2728,11 @@ static bool use_new_scheme(struct usb_device *udev, int retry, { int old_scheme_first_port = port_dev->quirks & USB_PORT_QUIRK_OLD_SCHEME; - int quick_enumeration = (udev->speed == USB_SPEED_HIGH); if (udev->speed >= USB_SPEED_SUPER) return false; - return USE_NEW_SCHEME(retry, old_scheme_first_port || old_scheme_first - || quick_enumeration); + return USE_NEW_SCHEME(retry, old_scheme_first_port || old_scheme_first); } /* Is a USB 3.0 port in the Inactive or Compliance Mode state? -- 2.26.2

5 years, 8 months

1
0
0 0

patch "usb-storage: Add unusual_devs entry for JMicron JMS566" 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-storage: Add unusual_devs entry for JMicron JMS566 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 94f9c8c3c404ee1f7aaff81ad4f24aec4e34a78b Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 22 Apr 2020 16:14:57 -0400 Subject: usb-storage: Add unusual_devs entry for JMicron JMS566 Cyril Roelandt reports that his JMicron JMS566 USB-SATA bridge fails to handle WRITE commands with the FUA bit set, even though it claims to support FUA. (Oddly enough, a later version of the same bridge, version 2.03 as opposed to 1.14, doesn't claim to support FUA. Also oddly, the bridge _does_ support FUA when using the UAS transport instead of the Bulk-Only transport -- but this device was blacklisted for uas in commit bc3bdb12bbb3 ("usb-storage: Disable UAS on JMicron SATA enclosure") for apparently unrelated reasons.) This patch adds a usb-storage unusual_devs entry with the BROKEN_FUA flag. This allows the bridge to work properly with usb-storage. Reported-and-tested-by: Cyril Roelandt <tipecaml(a)gmail.com> Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> CC: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221613110.11262-100000@iolant… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/storage/unusual_devs.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index 1880f3e13f57..f6c3681fa2e9 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -2323,6 +2323,13 @@ UNUSUAL_DEV( 0x3340, 0xffff, 0x0000, 0x0000, USB_SC_DEVICE,USB_PR_DEVICE,NULL, US_FL_MAX_SECTORS_64 ), +/* Reported by Cyril Roelandt <tipecaml(a)gmail.com> */ +UNUSUAL_DEV( 0x357d, 0x7788, 0x0114, 0x0114, + "JMicron", + "USB to ATA/ATAPI Bridge", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_BROKEN_FUA ), + /* Reported by Andrey Rahmatullin <wrar(a)altlinux.org> */ UNUSUAL_DEV( 0x4102, 0x1020, 0x0100, 0x0100, "iRiver", -- 2.26.2

5 years, 8 months

1
0
0 0

patch "USB: hub: Fix handling of connect changes during sleep" 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: hub: Fix handling of connect changes during sleep 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 9f952e26295d977dbfc6fedeaf8c4f112c818d37 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 22 Apr 2020 16:09:51 -0400 Subject: USB: hub: Fix handling of connect changes during sleep Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") wasn't very well conceived. The problem it tried to fix was that if a connect-change event occurred while the system was asleep (such as a device disconnecting itself from the bus when it is suspended and then reconnecting when it resumes) requiring a reset-resume during the system wakeup transition, the hub port's change_bit entry would remain set afterward. This would cause the hub driver to believe another connect-change event had occurred after the reset-resume, which was wrong and would lead the driver to send unnecessary requests to the device (which could interfere with a firmware update). The commit tried to fix this by not setting the change_bit during the wakeup. But this was the wrong thing to do; it means that when a device is unplugged while the system is asleep, the hub driver doesn't realize anything has happened: The change_bit flag which would tell it to handle the disconnect event is clear. The commit needs to be reverted and the problem fixed in a different way. Fortunately an alternative solution was noted in the commit's Changelog: We can continue to set the change_bit entry in hub_activate() but then clear it when a reset-resume occurs. That way the the hub driver will see the change_bit when a device is disconnected but won't see it when the device is still present. That's what this patch does. Reported-and-tested-by: Peter Chen <peter.chen(a)nxp.com> Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") Tested-by: Paul Zimmerman <pauldzim(a)gmail.com> CC: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221602480.11262-100000@iolant… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/hub.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 54cd8ef795ec..83549f009ced 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1223,6 +1223,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) #ifdef CONFIG_PM udev->reset_resume = 1; #endif + /* Don't set the change_bits when the device + * was powered off. + */ + if (test_bit(port1, hub->power_bits)) + set_bit(port1, hub->change_bits); } else { /* The power session is gone; tell hub_wq */ @@ -3088,6 +3093,15 @@ static int check_port_resume_type(struct usb_device *udev, if (portchange & USB_PORT_STAT_C_ENABLE) usb_clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_C_ENABLE); + + /* + * Whatever made this reset-resume necessary may have + * turned on the port1 bit in hub->change_bits. But after + * a successful reset-resume we want the bit to be clear; + * if it was on it would indicate that something happened + * following the reset-resume. + */ + clear_bit(port1, hub->change_bits); } return status; -- 2.26.2

5 years, 8 months

1
0
0 0

Fwd: Re: [PATCH AUTOSEL 5.6 082/129] compiler.h: fix error in BUILD_BUG_ON() reporting

by Vegard Nossum

Hi, There is no point in taking this patch on any stable kernel as it's just improving a build error diagnostic message. Vegard On 4/15/20 1:33 PM, Sasha Levin wrote: > From: Vegard Nossum <vegard.nossum(a)oracle.com> > > [ Upstream commit af9c5d2e3b355854ff0e4acfbfbfadcd5198a349 ] > > compiletime_assert() uses __LINE__ to create a unique function name. This > means that if you have more than one BUILD_BUG_ON() in the same source > line (which can happen if they appear e.g. in a macro), then the error > message from the compiler might output the wrong condition. > > For this source file: > > #include <linux/build_bug.h> > > #define macro() \ > BUILD_BUG_ON(1); \ > BUILD_BUG_ON(0); > > void foo() > { > macro(); > } > > gcc would output: > > ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_9' declared with attribute error: BUILD_BUG_ON failed: 0 > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > > However, it was not the BUILD_BUG_ON(0) that failed, so it should say 1 > instead of 0. With this patch, we use __COUNTER__ instead of __LINE__, so > each BUILD_BUG_ON() gets a different function name and the correct > condition is printed: > > ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_0' declared with attribute error: BUILD_BUG_ON failed: 1 > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Reviewed-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> > Reviewed-by: Daniel Santos <daniel.santos(a)pobox.com> > Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> > Cc: Ian Abbott <abbotti(a)mev.co.uk> > Cc: Joe Perches <joe(a)perches.com> > Link: http://lkml.kernel.org/r/20200331112637.25047-1-vegard.nossum@oracle.com > Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > --- > include/linux/compiler.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index 5e88e7e33abec..034b0a644efcc 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -347,7 +347,7 @@ static inline void *offset_to_ptr(const int *off) > * compiler has support to do so. > */ > #define compiletime_assert(condition, msg) \ > - _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > + _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > > #define compiletime_assert_atomic_type(t) \ > compiletime_assert(__native_word(t), \ >

5 years, 8 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror