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

Patch "mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs to the 4.14-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: mmc-dw_mmc-fix-falling-from-idmac-to-pio-mode-when-dw_mci_reset-occurs.patch and it can be found in the queue-4.14 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 47b7de2f6c18f75d1f2716efe752cba43f32a626 Mon Sep 17 00:00:00 2001 From: Evgeniy Didin <Evgeniy.Didin(a)synopsys.com> Date: Wed, 14 Mar 2018 22:30:51 +0300 Subject: mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs From: Evgeniy Didin <Evgeniy.Didin(a)synopsys.com> commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream. It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeout overflow calculation failure: 1. soft-reset is called 2. driver restarts dma 3. descriptors states are checked, one of descriptor is owned by the IDMAC. 4. driver can't use DMA and then switches to PIO mode. Failure was already fixed in: https://www.spinics.net/lists/linux-mmc/msg48125.html. Behaviour while soft-reset is not something we except or even want to happen. So we switch from dw_mci_idmac_reset to dw_mci_idmac_init, so descriptors are cleaned before starting dma. And while at it explicitly zero des0 which otherwise might contain garbage as being allocated by dmam_alloc_coherent(). Signed-off-by: Evgeniy Didin <Evgeniy.Didin(a)synopsys.com> Cc: Jaehoon Chung <jh80.chung(a)samsung.com> Cc: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> Cc: Shawn Lin <shawn.lin(a)rock-chips.com> Cc: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Cc: linux-snps-arc(a)lists.infradead.org Cc: <stable(a)vger.kernel.org> # 4.4+ Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/dw_mmc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -564,6 +564,7 @@ static int dw_mci_idmac_init(struct dw_m (sizeof(struct idmac_desc_64addr) * (i + 1))) >> 32; /* Initialize reserved and buffer size fields to "0" */ + p->des0 = 0; p->des1 = 0; p->des2 = 0; p->des3 = 0; @@ -586,6 +587,7 @@ static int dw_mci_idmac_init(struct dw_m i++, p++) { p->des3 = cpu_to_le32(host->sg_dma + (sizeof(struct idmac_desc) * (i + 1))); + p->des0 = 0; p->des1 = 0; } @@ -1801,8 +1803,8 @@ static bool dw_mci_reset(struct dw_mci * } if (host->use_dma == TRANS_MODE_IDMAC) - /* It is also recommended that we reset and reprogram idmac */ - dw_mci_idmac_reset(host); + /* It is also required that we reinit idmac */ + dw_mci_idmac_init(host); ret = true; Patches currently in stable-queue which might be from Evgeniy.Didin(a)synopsys.com are queue-4.14/mmc-dw_mmc-fix-the-dto-cto-timeout-overflow-calculation-for-32-bit-systems.patch queue-4.14/mmc-dw_mmc-fix-falling-from-idmac-to-pio-mode-when-dw_mci_reset-occurs.patch

7 years, 5 months

1
0
0 0

Patch "mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433 to the 4.14-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: mmc-dw_mmc-exynos-fix-the-suspend-resume-issue-for-exynos5433.patch and it can be found in the queue-4.14 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 e22842dd64bf86753d3f2b6ea474d73fc1e6ca24 Mon Sep 17 00:00:00 2001 From: Jaehoon Chung <jh80.chung(a)samsung.com> Date: Fri, 9 Mar 2018 15:10:21 +0900 Subject: mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433 From: Jaehoon Chung <jh80.chung(a)samsung.com> commit e22842dd64bf86753d3f2b6ea474d73fc1e6ca24 upstream. Before enabling the clock, dwmmc exynos driver is trying to access the register. Then the kernel panic can be occurred. Signed-off-by: Jaehoon Chung <jh80.chung(a)samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi(a)samsung.com> Tested-by: Chanwoo Choi <cw00.choi(a)samsung.com> Cc: stable(a)vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/dw_mmc-exynos.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/drivers/mmc/host/dw_mmc-exynos.c +++ b/drivers/mmc/host/dw_mmc-exynos.c @@ -165,9 +165,15 @@ static void dw_mci_exynos_set_clksel_tim static int dw_mci_exynos_runtime_resume(struct device *dev) { struct dw_mci *host = dev_get_drvdata(dev); + int ret; + + ret = dw_mci_runtime_resume(dev); + if (ret) + return ret; dw_mci_exynos_config_smu(host); - return dw_mci_runtime_resume(dev); + + return ret; } /** Patches currently in stable-queue which might be from jh80.chung(a)samsung.com are queue-4.14/mmc-dw_mmc-fix-the-dto-cto-timeout-overflow-calculation-for-32-bit-systems.patch queue-4.14/mmc-dw_mmc-exynos-fix-the-suspend-resume-issue-for-exynos5433.patch queue-4.14/mmc-dw_mmc-fix-falling-from-idmac-to-pio-mode-when-dw_mci_reset-occurs.patch

7 years, 5 months

1
0
0 0

Patch "mmc: core: Fix tracepoint print of blk_addr and blksz" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: core: Fix tracepoint print of blk_addr and blksz to the 4.14-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: mmc-core-fix-tracepoint-print-of-blk_addr-and-blksz.patch and it can be found in the queue-4.14 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 c658dc58c7eaa8569ceb0edd1ddbdfda84fe8aa5 Mon Sep 17 00:00:00 2001 From: Adrian Hunter <adrian.hunter(a)intel.com> Date: Thu, 15 Mar 2018 11:22:28 +0200 Subject: mmc: core: Fix tracepoint print of blk_addr and blksz From: Adrian Hunter <adrian.hunter(a)intel.com> commit c658dc58c7eaa8569ceb0edd1ddbdfda84fe8aa5 upstream. Swap the positions of blk_addr and blksz in the tracepoint print arguments so that they match the print format. Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Fixes: d2f82254e4e8 ("mmc: core: Add members to mmc_request and mmc_data for CQE's") Cc: <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/trace/events/mmc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/trace/events/mmc.h +++ b/include/trace/events/mmc.h @@ -86,8 +86,8 @@ TRACE_EVENT(mmc_request_start, __entry->stop_flags, __entry->stop_retries, __entry->sbc_opcode, __entry->sbc_arg, __entry->sbc_flags, __entry->sbc_retries, - __entry->blocks, __entry->blk_addr, - __entry->blksz, __entry->data_flags, __entry->tag, + __entry->blocks, __entry->blksz, + __entry->blk_addr, __entry->data_flags, __entry->tag, __entry->can_retune, __entry->doing_retune, __entry->retune_now, __entry->need_retune, __entry->hold_retune, __entry->retune_period) Patches currently in stable-queue which might be from adrian.hunter(a)intel.com are queue-4.14/mmc-core-fix-tracepoint-print-of-blk_addr-and-blksz.patch

7 years, 5 months

1
0
0 0

Patch "mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards to the 4.14-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: mmc-core-disable-hpi-for-certain-micron-numonyx-emmc-cards.patch and it can be found in the queue-4.14 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 dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4 Mon Sep 17 00:00:00 2001 From: Dirk Behme <dirk.behme(a)de.bosch.com> Date: Wed, 14 Mar 2018 14:50:09 +0000 Subject: mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards From: Dirk Behme <dirk.behme(a)de.bosch.com> commit dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4 upstream. Certain Micron eMMC v4.5 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. In U-Boot, these cards are reported as Manufacturer: Micron (ID: 0xFE) OEM: 0x4E Name: MMC32G Revision: 19 (0x13) Serial: 959241022 Manufact. date: 8/2015 (0x82) CRC: 0x00 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.5 High Capacity: Yes Capacity: 29.1 GiB Boot Partition Size: 16 MiB Bus Width: 8-bit According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by Micron. Signed-off-by: Dirk Behme <dirk.behme(a)de.bosch.com> Signed-off-by: Mark Craske <Mark_Craske(a)mentor.com> Cc: <stable(a)vger.kernel.org> # 4.8+ Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/core/card.h | 1 + drivers/mmc/core/quirks.h | 6 ++++++ 2 files changed, 7 insertions(+) --- a/drivers/mmc/core/card.h +++ b/drivers/mmc/core/card.h @@ -82,6 +82,7 @@ struct mmc_fixup { #define CID_MANFID_APACER 0x27 #define CID_MANFID_KINGSTON 0x70 #define CID_MANFID_HYNIX 0x90 +#define CID_MANFID_NUMONYX 0xFE #define END_FIXUP { NULL } --- a/drivers/mmc/core/quirks.h +++ b/drivers/mmc/core/quirks.h @@ -109,6 +109,12 @@ static const struct mmc_fixup mmc_ext_cs */ MMC_FIXUP_EXT_CSD_REV(CID_NAME_ANY, CID_MANFID_HYNIX, 0x014a, add_quirk, MMC_QUIRK_BROKEN_HPI, 5), + /* + * Certain Micron (Numonyx) eMMC 4.5 cards might get broken when HPI + * feature is used so disable the HPI feature for such buggy cards. + */ + MMC_FIXUP_EXT_CSD_REV(CID_NAME_ANY, CID_MANFID_NUMONYX, + 0x014e, add_quirk, MMC_QUIRK_BROKEN_HPI, 6), END_FIXUP }; Patches currently in stable-queue which might be from dirk.behme(a)de.bosch.com are queue-4.14/mmc-core-disable-hpi-for-certain-micron-numonyx-emmc-cards.patch

7 years, 5 months

1
0
0 0

Patch "mmc: block: fix updating ext_csd caches on ioctl call" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: block: fix updating ext_csd caches on ioctl call to the 4.14-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: mmc-block-fix-updating-ext_csd-caches-on-ioctl-call.patch and it can be found in the queue-4.14 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 e74ef2194b41ba5e511fab29fe5ff00e72d2f42a Mon Sep 17 00:00:00 2001 From: Bastian Stender <bst(a)pengutronix.de> Date: Thu, 8 Mar 2018 15:08:11 +0100 Subject: mmc: block: fix updating ext_csd caches on ioctl call From: Bastian Stender <bst(a)pengutronix.de> commit e74ef2194b41ba5e511fab29fe5ff00e72d2f42a upstream. PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the currently active partition in mmc_blk_data->part_curr. These caches do not always reflect changes if the ioctl call modifies the PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE. Write the PARTITION_CONFIG value extracted from the ioctl call to the cache and update the currently active partition accordingly. This ensures that the user space cannot change the values behind the kernel's back. The next call to mmc_blk_part_switch() will operate on the data set by the ioctl and reflect the changes appropriately. Signed-off-by: Bastian Stender <bst(a)pengutronix.de> Signed-off-by: Jan Luebbe <jlu(a)pengutronix.de> Cc: stable(a)vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/core/block.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -65,6 +65,7 @@ MODULE_ALIAS("mmc:block"); #define MMC_BLK_TIMEOUT_MS (10 * 60 * 1000) /* 10 minute timeout */ #define MMC_SANITIZE_REQ_TIMEOUT 240000 #define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16) +#define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8) #define mmc_req_rel_wr(req) ((req->cmd_flags & REQ_FUA) && \ (rq_data_dir(req) == WRITE)) @@ -539,6 +540,24 @@ static int __mmc_blk_ioctl_cmd(struct mm } /* + * Make sure the cache of the PARTITION_CONFIG register and + * PARTITION_ACCESS bits is updated in case the ioctl ext_csd write + * changed it successfully. + */ + if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_PART_CONFIG) && + (cmd.opcode == MMC_SWITCH)) { + struct mmc_blk_data *main_md = dev_get_drvdata(&card->dev); + u8 value = MMC_EXTRACT_VALUE_FROM_ARG(cmd.arg); + + /* + * Update cache so the next mmc_blk_part_switch call operates + * on up-to-date data. + */ + card->ext_csd.part_config = value; + main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK; + } + + /* * According to the SD specs, some commands require a delay after * issuing the command. */ Patches currently in stable-queue which might be from bst(a)pengutronix.de are queue-4.14/mmc-block-fix-updating-ext_csd-caches-on-ioctl-call.patch

7 years, 5 months

1
0
0 0

Patch "MIPS: ralink: Remove ralink_halt()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: ralink: Remove ralink_halt() to the 4.14-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: mips-ralink-remove-ralink_halt.patch and it can be found in the queue-4.14 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 891731f6a5dbe508d12443175a7e166a2fba616a Mon Sep 17 00:00:00 2001 From: NeilBrown <neil(a)brown.name> Date: Tue, 20 Mar 2018 19:29:51 +1100 Subject: MIPS: ralink: Remove ralink_halt() From: NeilBrown <neil(a)brown.name> commit 891731f6a5dbe508d12443175a7e166a2fba616a upstream. ralink_halt() does nothing that machine_halt() doesn't already do, so it adds no value. It actually causes incorrect behaviour due to the "unreachable()" at the end. This tells the compiler that the end of the function will never be reached, which isn't true. The compiler responds by not adding a 'return' instruction, so control simply moves on to whatever bytes come afterwards in memory. In my tested, that was the ralink_restart() function. This means that an attempt to 'halt' the machine would actually cause a reboot. So remove ralink_halt() so that a 'halt' really does halt. Fixes: c06e836ada59 ("MIPS: ralink: adds reset code") Signed-off-by: NeilBrown <neil(a)brown.name> Cc: John Crispin <john(a)phrozen.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 3.9+ Patchwork: https://patchwork.linux-mips.org/patch/18851/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ralink/reset.c | 7 ------- 1 file changed, 7 deletions(-) --- a/arch/mips/ralink/reset.c +++ b/arch/mips/ralink/reset.c @@ -96,16 +96,9 @@ static void ralink_restart(char *command unreachable(); } -static void ralink_halt(void) -{ - local_irq_disable(); - unreachable(); -} - static int __init mips_reboot_setup(void) { _machine_restart = ralink_restart; - _machine_halt = ralink_halt; return 0; } Patches currently in stable-queue which might be from neil(a)brown.name are queue-4.14/mips-ralink-fix-booting-on-mt7621.patch queue-4.14/mips-ralink-remove-ralink_halt.patch

7 years, 5 months

1
0
0 0

Patch "MIPS: ralink: Fix booting on MT7621" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: ralink: Fix booting on MT7621 to the 4.14-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: mips-ralink-fix-booting-on-mt7621.patch and it can be found in the queue-4.14 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 a63d706ea719190a79a6c769e898f70680044d3e Mon Sep 17 00:00:00 2001 From: NeilBrown <neil(a)brown.name> Date: Wed, 21 Mar 2018 14:02:10 +1100 Subject: MIPS: ralink: Fix booting on MT7621 From: NeilBrown <neil(a)brown.name> commit a63d706ea719190a79a6c769e898f70680044d3e upstream. Since commit 3af5a67c86a3 ("MIPS: Fix early CM probing") the MT7621 has not been able to boot. This commit caused mips_cm_probe() to be called before mt7621.c::proc_soc_init(). prom_soc_init() has a comment explaining that mips_cm_probe() "wipes out the bootloader config" and means that configuration registers are no longer available. It has some code to re-enable this config. Before this re-enable code is run, the sysc register cannot be read, so when SYSC_REG_CHIP_NAME0 is read, a garbage value is returned and panic() is called. If we move the config-repair code to the top of prom_soc_init(), the registers can be read and boot can proceed. Very occasionally, the first register read after the reconfiguration returns garbage, so add a call to __sync(). Fixes: 3af5a67c86a3 ("MIPS: Fix early CM probing") Signed-off-by: NeilBrown <neil(a)brown.name> Reviewed-by: Matt Redfearn <matt.redfearn(a)mips.com> Cc: John Crispin <john(a)phrozen.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.5+ Patchwork: https://patchwork.linux-mips.org/patch/18859/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ralink/mt7621.c | 42 ++++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 20 deletions(-) --- a/arch/mips/ralink/mt7621.c +++ b/arch/mips/ralink/mt7621.c @@ -170,6 +170,28 @@ void prom_soc_init(struct ralink_soc_inf u32 n1; u32 rev; + /* Early detection of CMP support */ + mips_cm_probe(); + mips_cpc_probe(); + + if (mips_cps_numiocu(0)) { + /* + * mips_cm_probe() wipes out bootloader + * config for CM regions and we have to configure them + * again. This SoC cannot talk to pamlbus devices + * witout proper iocu region set up. + * + * FIXME: it would be better to do this with values + * from DT, but we need this very early because + * without this we cannot talk to pretty much anything + * including serial. + */ + write_gcr_reg0_base(MT7621_PALMBUS_BASE); + write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE | + CM_GCR_REGn_MASK_CMTGT_IOCU0); + __sync(); + } + n0 = __raw_readl(sysc + SYSC_REG_CHIP_NAME0); n1 = __raw_readl(sysc + SYSC_REG_CHIP_NAME1); @@ -194,26 +216,6 @@ void prom_soc_init(struct ralink_soc_inf rt2880_pinmux_data = mt7621_pinmux_data; - /* Early detection of CMP support */ - mips_cm_probe(); - mips_cpc_probe(); - - if (mips_cps_numiocu(0)) { - /* - * mips_cm_probe() wipes out bootloader - * config for CM regions and we have to configure them - * again. This SoC cannot talk to pamlbus devices - * witout proper iocu region set up. - * - * FIXME: it would be better to do this with values - * from DT, but we need this very early because - * without this we cannot talk to pretty much anything - * including serial. - */ - write_gcr_reg0_base(MT7621_PALMBUS_BASE); - write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE | - CM_GCR_REGn_MASK_CMTGT_IOCU0); - } if (!register_cps_smp_ops()) return; Patches currently in stable-queue which might be from neil(a)brown.name are queue-4.14/mips-ralink-fix-booting-on-mt7621.patch queue-4.14/mips-ralink-remove-ralink_halt.patch

7 years, 5 months

1
0
0 0

Patch "MIPS: lantiq: Fix Danube USB clock" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: lantiq: Fix Danube USB clock to the 4.14-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: mips-lantiq-fix-danube-usb-clock.patch and it can be found in the queue-4.14 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 214cbc14734958fe533916fdb4194f5983ad4bc4 Mon Sep 17 00:00:00 2001 From: Mathias Kresin <dev(a)kresin.me> Date: Fri, 16 Mar 2018 21:27:28 +0100 Subject: MIPS: lantiq: Fix Danube USB clock From: Mathias Kresin <dev(a)kresin.me> commit 214cbc14734958fe533916fdb4194f5983ad4bc4 upstream. On Danube the USB0 controller registers are at 1e101000 and the USB0 PHY register is at 1f203018 similar to all other lantiq SoCs. Activate the USB controller gating clock thorough the USB controller driver and not the PHY. This fixes a problem introduced in a previous commit. Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module") Signed-off-by: Mathias Kresin <dev(a)kresin.me> Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de> Acked-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: John Crispin <john(a)phrozen.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.14+ Patchwork: https://patchwork.linux-mips.org/patch/18816/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/lantiq/xway/sysctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/lantiq/xway/sysctrl.c +++ b/arch/mips/lantiq/xway/sysctrl.c @@ -562,7 +562,7 @@ void __init ltq_soc_init(void) } else { clkdev_add_static(ltq_danube_cpu_hz(), ltq_danube_fpi_hz(), ltq_danube_fpi_hz(), ltq_danube_pp32_hz()); - clkdev_add_pmu("1f203018.usb2-phy", "ctrl", 1, 0, PMU_USB0); + clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0); clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P); clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO); clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU); Patches currently in stable-queue which might be from dev(a)kresin.me are queue-4.14/mips-lantiq-ase-enable-mfd_syscon.patch queue-4.14/mips-lantiq-enable-ahb-bus-for-usb.patch queue-4.14/mips-lantiq-fix-danube-usb-clock.patch

7 years, 5 months

1
0
0 0

Patch "MIPS: lantiq: Enable AHB Bus for USB" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: lantiq: Enable AHB Bus for USB to the 4.14-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: mips-lantiq-enable-ahb-bus-for-usb.patch and it can be found in the queue-4.14 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 3223a5a7d3a606dcb7d9190a788b9544a45441ee Mon Sep 17 00:00:00 2001 From: Mathias Kresin <dev(a)kresin.me> Date: Fri, 16 Mar 2018 21:27:29 +0100 Subject: MIPS: lantiq: Enable AHB Bus for USB From: Mathias Kresin <dev(a)kresin.me> commit 3223a5a7d3a606dcb7d9190a788b9544a45441ee upstream. On Danube and AR9 the USB core is connected though a AHB bus to the main system cross bar, hence we need to enable the gating clock of the AHB Bus as well to make the USB controller work. Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module") Signed-off-by: Mathias Kresin <dev(a)kresin.me> Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de> Acked-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: John Crispin <john(a)phrozen.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.14+ Patchwork: https://patchwork.linux-mips.org/patch/18814/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/lantiq/xway/sysctrl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/mips/lantiq/xway/sysctrl.c +++ b/arch/mips/lantiq/xway/sysctrl.c @@ -551,9 +551,9 @@ void __init ltq_soc_init(void) clkdev_add_static(ltq_ar9_cpu_hz(), ltq_ar9_fpi_hz(), ltq_ar9_fpi_hz(), CLOCK_250M); clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P); - clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0); + clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0 | PMU_AHBM); clkdev_add_pmu("1f203034.usb2-phy", "phy", 1, 0, PMU_USB1_P); - clkdev_add_pmu("1e106000.usb", "otg", 1, 0, PMU_USB1); + clkdev_add_pmu("1e106000.usb", "otg", 1, 0, PMU_USB1 | PMU_AHBM); clkdev_add_pmu("1e180000.etop", "switch", 1, 0, PMU_SWITCH); clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO); clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU); @@ -562,7 +562,7 @@ void __init ltq_soc_init(void) } else { clkdev_add_static(ltq_danube_cpu_hz(), ltq_danube_fpi_hz(), ltq_danube_fpi_hz(), ltq_danube_pp32_hz()); - clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0); + clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0 | PMU_AHBM); clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P); clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO); clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU); Patches currently in stable-queue which might be from dev(a)kresin.me are queue-4.14/mips-lantiq-ase-enable-mfd_syscon.patch queue-4.14/mips-lantiq-enable-ahb-bus-for-usb.patch queue-4.14/mips-lantiq-fix-danube-usb-clock.patch

7 years, 5 months

1
0
0 0

Patch "lockdep: fix fs_reclaim warning" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lockdep: fix fs_reclaim warning to the 4.14-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: lockdep-fix-fs_reclaim-warning.patch and it can be found in the queue-4.14 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 2e517d681632326ed98399cb4dd99519efe3e32c Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Date: Thu, 22 Mar 2018 16:17:10 -0700 Subject: lockdep: fix fs_reclaim warning From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> commit 2e517d681632326ed98399cb4dd99519efe3e32c upstream. Dave Jones reported fs_reclaim lockdep warnings. ============================================ WARNING: possible recursive locking detected 4.15.0-rc9-backup-debug+ #1 Not tainted -------------------------------------------- sshd/24800 is trying to acquire lock: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30 but task is already holding lock: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(fs_reclaim); lock(fs_reclaim); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by sshd/24800: #0: (sk_lock-AF_INET6){+.+.}, at: [<000000001a069652>] tcp_sendmsg+0x19/0x40 #1: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30 stack backtrace: CPU: 3 PID: 24800 Comm: sshd Not tainted 4.15.0-rc9-backup-debug+ #1 Call Trace: dump_stack+0xbc/0x13f __lock_acquire+0xa09/0x2040 lock_acquire+0x12e/0x350 fs_reclaim_acquire.part.102+0x29/0x30 kmem_cache_alloc+0x3d/0x2c0 alloc_extent_state+0xa7/0x410 __clear_extent_bit+0x3ea/0x570 try_release_extent_mapping+0x21a/0x260 __btrfs_releasepage+0xb0/0x1c0 btrfs_releasepage+0x161/0x170 try_to_release_page+0x162/0x1c0 shrink_page_list+0x1d5a/0x2fb0 shrink_inactive_list+0x451/0x940 shrink_node_memcg.constprop.88+0x4c9/0x5e0 shrink_node+0x12d/0x260 try_to_free_pages+0x418/0xaf0 __alloc_pages_slowpath+0x976/0x1790 __alloc_pages_nodemask+0x52c/0x5c0 new_slab+0x374/0x3f0 ___slab_alloc.constprop.81+0x47e/0x5a0 __slab_alloc.constprop.80+0x32/0x60 __kmalloc_track_caller+0x267/0x310 __kmalloc_reserve.isra.40+0x29/0x80 __alloc_skb+0xee/0x390 sk_stream_alloc_skb+0xb8/0x340 tcp_sendmsg_locked+0x8e6/0x1d30 tcp_sendmsg+0x27/0x40 inet_sendmsg+0xd0/0x310 sock_write_iter+0x17a/0x240 __vfs_write+0x2ab/0x380 vfs_write+0xfb/0x260 SyS_write+0xb6/0x140 do_syscall_64+0x1e5/0xc05 entry_SYSCALL64_slow_path+0x25/0x25 This warning is caused by commit d92a8cfcb37e ("locking/lockdep: Rework FS_RECLAIM annotation") which replaced the use of lockdep_{set,clear}_current_reclaim_state() in __perform_reclaim() and lockdep_trace_alloc() in slab_pre_alloc_hook() with fs_reclaim_acquire()/ fs_reclaim_release(). Since __kmalloc_reserve() from __alloc_skb() adds __GFP_NOMEMALLOC | __GFP_NOWARN to gfp_mask, and all reclaim path simply propagates __GFP_NOMEMALLOC, fs_reclaim_acquire() in slab_pre_alloc_hook() is trying to grab the 'fake' lock again when __perform_reclaim() already grabbed the 'fake' lock. The /* this guy won't enter reclaim */ if ((current->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC)) return false; test which causes slab_pre_alloc_hook() to try to grab the 'fake' lock was added by commit cf40bd16fdad ("lockdep: annotate reclaim context (__GFP_NOFS)"). But that test is outdated because PF_MEMALLOC thread won't enter reclaim regardless of __GFP_NOMEMALLOC after commit 341ce06f69ab ("page allocator: calculate the alloc_flags for allocation only once") added the PF_MEMALLOC safeguard ( /* Avoid recursion of direct reclaim */ if (p->flags & PF_MEMALLOC) goto nopage; in __alloc_pages_slowpath()). Thus, let's fix outdated test by removing __GFP_NOMEMALLOC test and allow __need_fs_reclaim() to return false. Link: http://lkml.kernel.org/r/201802280650.FJC73911.FOSOMLJVFFQtHO@I-love.SAKURA… Fixes: d92a8cfcb37ecd13 ("locking/lockdep: Rework FS_RECLAIM annotation") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: Dave Jones <davej(a)codemonkey.org.uk> Tested-by: Dave Jones <davej(a)codemonkey.org.uk> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Nick Piggin <npiggin(a)gmail.com> Cc: Ingo Molnar <mingo(a)elte.hu> Cc: Nikolay Borisov <nborisov(a)suse.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: <stable(a)vger.kernel.org> [4.14+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3532,7 +3532,7 @@ static bool __need_fs_reclaim(gfp_t gfp_ return false; /* this guy won't enter reclaim */ - if ((current->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC)) + if (current->flags & PF_MEMALLOC) return false; /* We're only interested __GFP_FS allocations for now */ Patches currently in stable-queue which might be from penguin-kernel(a)I-love.SAKURA.ne.jp are queue-4.14/lockdep-fix-fs_reclaim-warning.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror