February 2018 - Linux-stable-mirror

Patch "dmaengine: ioat: Fix error handling path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: ioat: Fix error handling path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-ioat-fix-error-handling-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Fri, 17 Nov 2017 22:37:53 +0100 Subject: dmaengine: ioat: Fix error handling path From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ] If the last test in 'ioat_dma_self_test()' fails, we must release all the allocated resources and not just part of them. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Acked-by: Dave Jiang <dave.jiang(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/ioat/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/dma/ioat/init.c +++ b/drivers/dma/ioat/init.c @@ -388,7 +388,7 @@ static int ioat_dma_self_test(struct ioa if (memcmp(src, dest, IOAT_TEST_SIZE)) { dev_err(dev, "Self-test copy failed compare, disabling\n"); err = -ENODEV; - goto free_resources; + goto unmap_dma; } unmap_dma: Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/dmaengine-ioat-fix-error-handling-path.patch

6 years, 10 months

1
0
0 0

Patch "btrfs: Fix possible off-by-one in btrfs_search_path_in_tree" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix possible off-by-one in btrfs_search_path_in_tree to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-possible-off-by-one-in-btrfs_search_path_in_tree.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Nikolay Borisov <nborisov(a)suse.com> Date: Fri, 1 Dec 2017 11:19:42 +0200 Subject: btrfs: Fix possible off-by-one in btrfs_search_path_in_tree From: Nikolay Borisov <nborisov(a)suse.com> [ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ] The name char array passed to btrfs_search_path_in_tree is of size BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes are in the range of [0, 4079]. Currently the code uses the define but this represents an off-by-one. Implications: Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be written to extra space, not some padding that could be provided by the allocator. btrfs-progs store the arguments on stack, but kernel does own copy of the ioctl buffer and the off-by-one overwrite does not affect userspace, but the ending 0 might be lost. Kernel ioctl buffer is allocated dynamically so we're overwriting somebody else's memory, and the ioctl is privileged if args.objectid is not 256. Which is in most cases, but resolving a subvolume stored in another directory will trigger that path. Before this patch the buffer was one byte larger, but then the -1 was not added. Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ added implications ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2244,7 +2244,7 @@ static noinline int btrfs_search_path_in if (!path) return -ENOMEM; - ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX]; + ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX - 1]; key.objectid = tree_id; key.type = BTRFS_ROOT_ITEM_KEY; Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.9/btrfs-fix-possible-off-by-one-in-btrfs_search_path_in_tree.patch

6 years, 10 months

1
0
0 0

Patch "clk: fix a panic error caused by accessing NULL pointer" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: fix a panic error caused by accessing NULL pointer to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-fix-a-panic-error-caused-by-accessing-null-pointer.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Cai Li <cai.li(a)spreadtrum.com> Date: Tue, 21 Nov 2017 17:24:38 +0800 Subject: clk: fix a panic error caused by accessing NULL pointer From: Cai Li <cai.li(a)spreadtrum.com> [ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ] In some cases the clock parent would be set NULL when doing re-parent, it will cause a NULL pointer accessing if clk_set trace event is enabled. This patch sets the parent as "none" if the input parameter is NULL. Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations) Signed-off-by: Cai Li <cai.li(a)spreadtrum.com> Signed-off-by: Chunyan Zhang <chunyan.zhang(a)spreadtrum.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/trace/events/clk.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/trace/events/clk.h +++ b/include/trace/events/clk.h @@ -134,12 +134,12 @@ DECLARE_EVENT_CLASS(clk_parent, TP_STRUCT__entry( __string( name, core->name ) - __string( pname, parent->name ) + __string( pname, parent ? parent->name : "none" ) ), TP_fast_assign( __assign_str(name, core->name); - __assign_str(pname, parent->name); + __assign_str(pname, parent ? parent->name : "none"); ), TP_printk("%s %s", __get_str(name), __get_str(pname)) Patches currently in stable-queue which might be from cai.li(a)spreadtrum.com are queue-4.9/clk-fix-a-panic-error-caused-by-accessing-null-pointer.patch

6 years, 10 months

1
0
0 0

Patch "brcmfmac: Avoid build error with make W=1" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled brcmfmac: Avoid build error with make W=1 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: brcmfmac-avoid-build-error-with-make-w-1.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 23 Nov 2017 17:57:04 +0200 Subject: brcmfmac: Avoid build error with make W=1 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> [ Upstream commit 51ef7925e10688c57186d438e784532e063492e4 ] When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for the first run, all next ones are okay. CC [M] drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union! scripts/Makefile.build:310: recipe for target 'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed Seems like something happened with W=1 and wrong kernel doc format. As a quick fix remove dubious /** in the code. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Arend van Spriel <arend.vanspriel(a)broadcom.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -2049,7 +2049,7 @@ static int brcmf_sdio_txpkt_hdalign(stru return head_pad; } -/** +/* * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for * bus layer usage. */ Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are queue-4.9/brcmfmac-avoid-build-error-with-make-w-1.patch

6 years, 10 months

1
0
0 0

Patch "ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Tony Lindgren <tony(a)atomide.com> Date: Mon, 27 Nov 2017 08:57:26 -0800 Subject: ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit d09220a887f70368afa79e850c95e74890c0a32d ] With the CMA changes from Joonsoo Kim <iamjoonsoo.kim(a)lge.com>, it was noticed that n900 stopped booting. After investigating it turned out that n900 save_secure_ram_context does some whacky virtual to physical address translation for the SRAM data address. As we now only have minimal parts of omap3 idle code copied to SRAM, running save_secure_ram_context() in SRAM is not needed. It only gets called on PM init. And it seems there's no need to ever call this from SRAM idle code. So let's just keep save_secure_ram_context() in DDR, and pass it the physical address of the parameters. We can do everything else in omap-secure.c like we already do for other secure code. And since we don't have any documentation, I still have no clue what the values for 0, 1 and 1 for the parameters might be. If somebody has figured it out, please do send a patch to add some comments. Debugged-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-omap2/omap-secure.c | 19 +++++++++++++++++++ arch/arm/mach-omap2/omap-secure.h | 4 ++++ arch/arm/mach-omap2/pm.h | 4 ---- arch/arm/mach-omap2/pm34xx.c | 13 ++++--------- arch/arm/mach-omap2/sleep34xx.S | 26 ++++---------------------- 5 files changed, 31 insertions(+), 35 deletions(-) --- a/arch/arm/mach-omap2/omap-secure.c +++ b/arch/arm/mach-omap2/omap-secure.c @@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base return omap_secure_memblock_base; } +u32 omap3_save_secure_ram(void __iomem *addr, int size) +{ + u32 ret; + u32 param[5]; + + if (size != OMAP3_SAVE_SECURE_RAM_SZ) + return OMAP3_SAVE_SECURE_RAM_SZ; + + param[0] = 4; /* Number of arguments */ + param[1] = __pa(addr); /* Physical address for saving */ + param[2] = 0; + param[3] = 1; + param[4] = 1; + + ret = save_secure_ram_context(__pa(param)); + + return ret; +} + /** * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls * @idx: The PPA API index --- a/arch/arm/mach-omap2/omap-secure.h +++ b/arch/arm/mach-omap2/omap-secure.h @@ -31,6 +31,8 @@ /* Maximum Secure memory storage size */ #define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K) +#define OMAP3_SAVE_SECURE_RAM_SZ 0x803F + /* Secure low power HAL API index */ #define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a #define OMAP4_HAL_SAVEHW_INDEX 0x1b @@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs); extern phys_addr_t omap_secure_ram_mempool_base(void); extern int omap_secure_ram_reserve_memblock(void); +extern u32 save_secure_ram_context(u32 args_pa); +extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size); extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs, u32 arg1, u32 arg2, u32 arg3, u32 arg4); --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz; /* ... and its pointer from SRAM after copy */ extern void (*omap3_do_wfi_sram)(void); -/* save_secure_ram_context function pointer and size, for copy to SRAM */ -extern int save_secure_ram_context(u32 *addr); -extern unsigned int save_secure_ram_context_sz; - extern void omap3_save_scratchpad_contents(void); #define PM_RTA_ERRATUM_i608 (1 << 0) --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -48,6 +48,7 @@ #include "prm3xxx.h" #include "pm.h" #include "sdrc.h" +#include "omap-secure.h" #include "sram.h" #include "control.h" #include "vc.h" @@ -66,7 +67,6 @@ struct power_state { static LIST_HEAD(pwrst_list); -static int (*_omap_save_secure_sram)(u32 *addr); void (*omap3_do_wfi_sram)(void); static struct powerdomain *mpu_pwrdm, *neon_pwrdm; @@ -121,8 +121,8 @@ static void omap3_save_secure_ram_contex * will hang the system. */ pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON); - ret = _omap_save_secure_sram((u32 *)(unsigned long) - __pa(omap3_secure_ram_storage)); + ret = omap3_save_secure_ram(omap3_secure_ram_storage, + OMAP3_SAVE_SECURE_RAM_SZ); pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state); /* Following is for error tracking, it should not happen */ if (ret) { @@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct po * * The minimum set of functions is pushed to SRAM for execution: * - omap3_do_wfi for erratum i581 WA, - * - save_secure_ram_context for security extensions. */ void omap_push_sram_idle(void) { omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz); - - if (omap_type() != OMAP2_DEVICE_TYPE_GP) - _omap_save_secure_sram = omap_sram_push(save_secure_ram_context, - save_secure_ram_context_sz); } static void __init pm_errata_configure(void) @@ -554,7 +549,7 @@ int __init omap3_pm_init(void) clkdm_add_wkdep(neon_clkdm, mpu_clkdm); if (omap_type() != OMAP2_DEVICE_TYPE_GP) { omap3_secure_ram_storage = - kmalloc(0x803F, GFP_KERNEL); + kmalloc(OMAP3_SAVE_SECURE_RAM_SZ, GFP_KERNEL); if (!omap3_secure_ram_storage) pr_err("Memory allocation failed when allocating for secure sram context\n"); --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -93,20 +93,13 @@ ENTRY(enable_omap3630_toggle_l2_on_resto ENDPROC(enable_omap3630_toggle_l2_on_restore) /* - * Function to call rom code to save secure ram context. This gets - * relocated to SRAM, so it can be all in .data section. Otherwise - * we need to initialize api_params separately. + * Function to call rom code to save secure ram context. + * + * r0 = physical address of the parameters */ - .data - .align 3 ENTRY(save_secure_ram_context) stmfd sp!, {r4 - r11, lr} @ save registers on stack - adr r3, api_params @ r3 points to parameters - str r0, [r3,#0x4] @ r0 has sdram address - ldr r12, high_mask - and r3, r3, r12 - ldr r12, sram_phy_addr_mask - orr r3, r3, r12 + mov r3, r0 @ physical address of parameters mov r0, #25 @ set service ID for PPA mov r12, r0 @ copy secure service ID in r12 mov r1, #0 @ set task id for ROM code in r1 @@ -120,18 +113,7 @@ ENTRY(save_secure_ram_context) nop nop ldmfd sp!, {r4 - r11, pc} - .align -sram_phy_addr_mask: - .word SRAM_BASE_P -high_mask: - .word 0xffff -api_params: - .word 0x4, 0x0, 0x0, 0x1, 0x1 ENDPROC(save_secure_ram_context) -ENTRY(save_secure_ram_context_sz) - .word . - save_secure_ram_context - - .text /* * ====================== Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.9/arm-dts-fix-elm-interrupt-compiler-warning.patch queue-4.9/arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch queue-4.9/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch queue-4.9/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch queue-4.9/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch queue-4.9/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch queue-4.9/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch queue-4.9/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch

6 years, 10 months

1
0
0 0

Patch "ASoC: rockchip: disable clock on error" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: rockchip: disable clock on error to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-rockchip-disable-clock-on-error.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> Date: Wed, 6 Dec 2017 16:03:24 +0100 Subject: ASoC: rockchip: disable clock on error From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> [ Upstream commit c7b92172a61b91936be985cb9bc499a4ebc6489b ] Disable the clocks in rk_spdif_probe when an error occurs after one of the clocks has been enabled previously. Found by Linux Driver Verification project (linuxtesting.org). Fixes: f874b80e1571 ASoC: rockchip: Add rockchip SPDIF transceiver driver Signed-off-by: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/rockchip/rockchip_spdif.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) --- a/sound/soc/rockchip/rockchip_spdif.c +++ b/sound/soc/rockchip/rockchip_spdif.c @@ -318,26 +318,30 @@ static int rk_spdif_probe(struct platfor spdif->mclk = devm_clk_get(&pdev->dev, "mclk"); if (IS_ERR(spdif->mclk)) { dev_err(&pdev->dev, "Can't retrieve rk_spdif master clock\n"); - return PTR_ERR(spdif->mclk); + ret = PTR_ERR(spdif->mclk); + goto err_disable_hclk; } ret = clk_prepare_enable(spdif->mclk); if (ret) { dev_err(spdif->dev, "clock enable failed %d\n", ret); - return ret; + goto err_disable_clocks; } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); regs = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(regs)) - return PTR_ERR(regs); + if (IS_ERR(regs)) { + ret = PTR_ERR(regs); + goto err_disable_clocks; + } spdif->regmap = devm_regmap_init_mmio_clk(&pdev->dev, "hclk", regs, &rk_spdif_regmap_config); if (IS_ERR(spdif->regmap)) { dev_err(&pdev->dev, "Failed to initialise managed register map\n"); - return PTR_ERR(spdif->regmap); + ret = PTR_ERR(spdif->regmap); + goto err_disable_clocks; } spdif->playback_dma_data.addr = res->start + SPDIF_SMPDR; @@ -369,6 +373,10 @@ static int rk_spdif_probe(struct platfor err_pm_runtime: pm_runtime_disable(&pdev->dev); +err_disable_clocks: + clk_disable_unprepare(spdif->mclk); +err_disable_hclk: + clk_disable_unprepare(spdif->hclk); return ret; } Patches currently in stable-queue which might be from Stefan.Potyra(a)elektrobit.com are queue-4.9/asoc-rockchip-disable-clock-on-error.patch

6 years, 10 months

1
0
0 0

Patch "ARM: dts: logicpd-somlv: Fix wl127x pinmux" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: logicpd-somlv: Fix wl127x pinmux to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Adam Ford <aford173(a)gmail.com> Date: Tue, 31 Oct 2017 13:45:59 -0500 Subject: ARM: dts: logicpd-somlv: Fix wl127x pinmux From: Adam Ford <aford173(a)gmail.com> [ Upstream commit cd7594ac3281722cb8f10d6f6c7e4287747c7a9d ] The pin assignment for the wl127x interrupt was incorrect. I am not sure how this every worked. This also eliminates a conflict with the SMC911x ethernet driver and properly moves pinmuxes for the related gpio to omap3_pmx_wkup from omap3_pmx_core. Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-som-lv.dtsi | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) --- a/arch/arm/boot/dts/logicpd-som-lv.dtsi +++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi @@ -121,7 +121,7 @@ &mmc3 { interrupts-extended = <&intc 94 &omap3_pmx_core2 0x46>; - pinctrl-0 = <&mmc3_pins>; + pinctrl-0 = <&mmc3_pins &wl127x_gpio>; pinctrl-names = "default"; vmmc-supply = <&wl12xx_vmmc>; non-removable; @@ -132,8 +132,8 @@ wlcore: wlcore@2 { compatible = "ti,wl1273"; reg = <2>; - interrupt-parent = <&gpio5>; - interrupts = <24 IRQ_TYPE_LEVEL_HIGH>; /* gpio 152 */ + interrupt-parent = <&gpio1>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; /* gpio 2 */ ref-clock-frequency = <26000000>; }; }; @@ -157,8 +157,6 @@ OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc2_dat5.sdmmc3_dat1 */ OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc2_dat6.sdmmc3_dat2 */ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc2_dat6.sdmmc3_dat3 */ - OMAP3_CORE1_IOPAD(0x2184, PIN_INPUT_PULLUP | MUX_MODE4) /* mcbsp4_clkx.gpio_152 */ - OMAP3_CORE1_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4) /* sys_boot1.gpio_3 */ OMAP3_CORE1_IOPAD(0x21d0, PIN_INPUT_PULLUP | MUX_MODE3) /* mcspi1_cs1.sdmmc3_cmd */ OMAP3_CORE1_IOPAD(0x21d2, PIN_INPUT_PULLUP | MUX_MODE3) /* mcspi1_cs2.sdmmc_clk */ >; @@ -228,6 +226,12 @@ OMAP3_WKUP_IOPAD(0x2a0e, PIN_OUTPUT | MUX_MODE4) /* sys_boot2.gpio_4 */ >; }; + wl127x_gpio: pinmux_wl127x_gpio_pin { + pinctrl-single,pins = < + OMAP3_WKUP_IOPAD(0x2a0c, PIN_INPUT | MUX_MODE4) /* sys_boot0.gpio_2 */ + OMAP3_WKUP_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4) /* sys_boot1.gpio_3 */ + >; + }; }; &omap3_pmx_core2 { Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.9/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch queue-4.9/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch

6 years, 10 months

1
0
0 0

Patch "ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Adam Ford <aford173(a)gmail.com> Date: Tue, 31 Oct 2017 13:42:13 -0500 Subject: ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet From: Adam Ford <aford173(a)gmail.com> [ Upstream commit 3c18bbf3d11d2005da08b57ff26f44ff1c2b12d0 ] This patch fixes and issue where the NAND and GPMC based ethernet controller stopped working. This also updates the GPMC settings to be consistent with the Logic PD Torpedo development from the commit listed above. Fixes: 44e4716499b8 ("ARM: dts: omap3: Fix NAND device nodes") Signed-off-by: Adam Ford <aford173(a)gmail.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts | 3 ++- arch/arm/boot/dts/logicpd-som-lv.dtsi | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts +++ b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts @@ -72,7 +72,8 @@ }; &gpmc { - ranges = <1 0 0x08000000 0x1000000>; /* CS1: 16MB for LAN9221 */ + ranges = <0 0 0x30000000 0x1000000 /* CS0: 16MB for NAND */ + 1 0 0x2c000000 0x1000000>; /* CS1: 16MB for LAN9221 */ ethernet@gpmc { pinctrl-names = "default"; --- a/arch/arm/boot/dts/logicpd-som-lv.dtsi +++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi @@ -37,7 +37,7 @@ }; &gpmc { - ranges = <0 0 0x00000000 0x1000000>; /* CS0: 16MB for NAND */ + ranges = <0 0 0x30000000 0x1000000>; /* CS0: 16MB for NAND */ nand@0,0 { compatible = "ti,omap2-nand"; Patches currently in stable-queue which might be from aford173(a)gmail.com are queue-4.9/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch queue-4.9/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch

6 years, 10 months

1
0
0 0

Patch "ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Tony Lindgren <tony(a)atomide.com> Date: Fri, 17 Nov 2017 08:56:58 -0800 Subject: ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ] There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4 for a while that happens after about 20 - 40 minutes on an idle system with some data feeding device being connected, like a USB GPS device or a cellular modem. This issue happens in cpuidle states C2 and C3 and does not happen if cpuidle is limited to C1 state only. The symptoms are that the whole system hangs and never wakes up from idle, and if a watchdog is configured the system reboots after a while. Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC interrupt controller directly as a parent instead of the WUGEN. We need to pass the interrupts through WUGEN to GIC to provide the wakeup events for the processor. Let's fix the issue by removing the gic interrupt-parent and use the default interrupt-parent wakeupgen instead. Note that omap5.dtsi had this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains") but we somehow missed omap4 at that point. Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains") Cc: Dave Gerlach <d-gerlach(a)ti.com> Cc: Nishanth Menon <nm(a)ti.com> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Reviewed-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/omap4.dtsi | 2 -- 1 file changed, 2 deletions(-) --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -859,14 +859,12 @@ usbhsohci: ohci@4a064800 { compatible = "ti,ohci-omap3"; reg = <0x4a064800 0x400>; - interrupt-parent = <&gic>; interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>; }; usbhsehci: ehci@4a064c00 { compatible = "ti,ehci-omap"; reg = <0x4a064c00 0x400>; - interrupt-parent = <&gic>; interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; }; }; Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.9/arm-dts-fix-elm-interrupt-compiler-warning.patch queue-4.9/arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch queue-4.9/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch queue-4.9/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch queue-4.9/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch queue-4.9/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch queue-4.9/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch queue-4.9/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch

6 years, 10 months

1
0
0 0

Patch "ARM: dts: am437x-cm-t43: Correct the dmas property of spi0" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: am437x-cm-t43: Correct the dmas property of spi0 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Fri Feb 23 11:48:40 CET 2018 From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Date: Wed, 1 Nov 2017 11:03:40 +0200 Subject: ARM: dts: am437x-cm-t43: Correct the dmas property of spi0 From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> [ Upstream commit ca41e244517d6d3f1600c229ff7ca615049c1e9c ] The DMA binding for eDMA needs 2 parameters, not 1. The second, missing parameter is the tptc to be used for the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/am437x-cm-t43.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/am437x-cm-t43.dts +++ b/arch/arm/boot/dts/am437x-cm-t43.dts @@ -301,8 +301,8 @@ status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; - dmas = <&edma 16 - &edma 17>; + dmas = <&edma 16 0 + &edma 17 0>; dma-names = "tx0", "rx0"; flash: w25q64cvzpig@0 { Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are queue-4.9/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch queue-4.9/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch

6 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2018