June 2019 - Linux-stable-mirror

[PATCH] mtd: rawnand: ingenic: Fix ingenic_ecc dependency

by Paul Cercueil

If MTD_NAND_JZ4780 is y and MTD_NAND_JZ4780_BCH is m, which select CONFIG_MTD_NAND_INGENIC_ECC to m, building fails: drivers/mtd/nand/raw/ingenic/ingenic_nand.o: In function `ingenic_nand_remove': ingenic_nand.c:(.text+0x177): undefined reference to `ingenic_ecc_release' drivers/mtd/nand/raw/ingenic/ingenic_nand.o: In function `ingenic_nand_ecc_correct': ingenic_nand.c:(.text+0x2ee): undefined reference to `ingenic_ecc_correct' To fix that, the ingenic_nand and ingenic_ecc modules have been fused into one single module. - The ingenic_ecc.c code is now compiled in only if $(CONFIG_MTD_NAND_INGENIC_ECC) is set. This is now a boolean instead of tristate. - To avoid changing the module name, the ingenic_nand.c file is moved to ingenic_nand_drv.c. Then the module name is still ingenic_nand. - Since ingenic_ecc.c is no more a module, the module-specific macros have been dropped, and the functions are no more exported for use by the ingenic_nand driver. Fixes: 15de8c6efd0e ("mtd: rawnand: ingenic: Separate top-level and SoC specific code") Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reported-by: Arnd Bergmann <arnd(a)arndb.de> Reported-by: Hulk Robot <hulkci(a)huawei.com> Cc: YueHaibing <yuehaibing(a)huawei.com> Cc: stable(a)vger.kernel.org --- drivers/mtd/nand/raw/ingenic/Kconfig | 2 +- drivers/mtd/nand/raw/ingenic/Makefile | 4 +++- drivers/mtd/nand/raw/ingenic/ingenic_ecc.c | 9 --------- .../raw/ingenic/{ingenic_nand.c => ingenic_nand_drv.c} | 0 4 files changed, 4 insertions(+), 11 deletions(-) rename drivers/mtd/nand/raw/ingenic/{ingenic_nand.c => ingenic_nand_drv.c} (100%) diff --git a/drivers/mtd/nand/raw/ingenic/Kconfig b/drivers/mtd/nand/raw/ingenic/Kconfig index 19a96ce515c1..66b7cffdb0c2 100644 --- a/drivers/mtd/nand/raw/ingenic/Kconfig +++ b/drivers/mtd/nand/raw/ingenic/Kconfig @@ -16,7 +16,7 @@ config MTD_NAND_JZ4780 if MTD_NAND_JZ4780 config MTD_NAND_INGENIC_ECC - tristate + bool config MTD_NAND_JZ4740_ECC tristate "Hardware BCH support for JZ4740 SoC" diff --git a/drivers/mtd/nand/raw/ingenic/Makefile b/drivers/mtd/nand/raw/ingenic/Makefile index 1ac4f455baea..b63d36889263 100644 --- a/drivers/mtd/nand/raw/ingenic/Makefile +++ b/drivers/mtd/nand/raw/ingenic/Makefile @@ -2,7 +2,9 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_JZ4780) += ingenic_nand.o -obj-$(CONFIG_MTD_NAND_INGENIC_ECC) += ingenic_ecc.o +ingenic_nand-y += ingenic_nand_drv.o +ingenic_nand-$(CONFIG_MTD_NAND_INGENIC_ECC) += ingenic_ecc.o + obj-$(CONFIG_MTD_NAND_JZ4740_ECC) += jz4740_ecc.o obj-$(CONFIG_MTD_NAND_JZ4725B_BCH) += jz4725b_bch.o obj-$(CONFIG_MTD_NAND_JZ4780_BCH) += jz4780_bch.o diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c b/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c index d3e085c5685a..c954189606f6 100644 --- a/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c +++ b/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c @@ -30,7 +30,6 @@ int ingenic_ecc_calculate(struct ingenic_ecc *ecc, { return ecc->ops->calculate(ecc, params, buf, ecc_code); } -EXPORT_SYMBOL(ingenic_ecc_calculate); /** * ingenic_ecc_correct() - detect and correct bit errors @@ -51,7 +50,6 @@ int ingenic_ecc_correct(struct ingenic_ecc *ecc, { return ecc->ops->correct(ecc, params, buf, ecc_code); } -EXPORT_SYMBOL(ingenic_ecc_correct); /** * ingenic_ecc_get() - get the ECC controller device @@ -111,7 +109,6 @@ struct ingenic_ecc *of_ingenic_ecc_get(struct device_node *of_node) } return ecc; } -EXPORT_SYMBOL(of_ingenic_ecc_get); /** * ingenic_ecc_release() - release the ECC controller device @@ -122,7 +119,6 @@ void ingenic_ecc_release(struct ingenic_ecc *ecc) clk_disable_unprepare(ecc->clk); put_device(ecc->dev); } -EXPORT_SYMBOL(ingenic_ecc_release); int ingenic_ecc_probe(struct platform_device *pdev) { @@ -159,8 +155,3 @@ int ingenic_ecc_probe(struct platform_device *pdev) return 0; } EXPORT_SYMBOL(ingenic_ecc_probe); - -MODULE_AUTHOR("Alex Smith <alex(a)alex-smith.me.uk>"); -MODULE_AUTHOR("Harvey Hunt <harveyhuntnexus(a)gmail.com>"); -MODULE_DESCRIPTION("Ingenic ECC common driver"); -MODULE_LICENSE("GPL v2"); diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand.c b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c similarity index 100% rename from drivers/mtd/nand/raw/ingenic/ingenic_nand.c rename to drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c -- 2.21.0.593.g511ec345e18

4 years, 10 months

2
3
0 0

[PATCH 3.16 00/10] 3.16.69-rc1 review

by Ben Hutchings

This is the start of the stable review cycle for the 3.16.69 release. There are 10 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jun 20 14:27:59 UTC 2019. Anything received after that time might be too late. All the patches have also been committed to the linux-3.16.y-rc branch of https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-rc.git . A shortlog and diffstat can be found below. Ben. ------------- Dan Carpenter (1): drivers/virt/fsl_hypervisor.c: prevent integer overflow in ioctl [6a024330650e24556b8a18cc654ad00cfecf6c6c] Eric Dumazet (4): tcp: add tcp_min_snd_mss sysctl [5f3e2bf008c2221478101ee72f5cb4654b9fc363] tcp: enforce tcp_min_snd_mss in tcp_mtu_probing() [967c05aee439e6e5d7d805e195b3a20ef5c433d6] tcp: limit payload size of sacked skbs [3b4929f65b0d8249f19a50245cd88ed1a2f78cff] tcp: tcp_fragment() should apply sane memory limits [f070ef2ac66716357066b683fb0baf55f8191a2e] Jason Yan (1): scsi: megaraid_sas: return error when create DMA pool failed [bcf3b67d16a4c8ffae0aa79de5853435e683945c] Jiri Kosina (1): mm/mincore.c: make mincore() more conservative [134fca9063ad4851de767d1768180e5dede9a881] Oleg Nesterov (1): mm: introduce vma_is_anonymous(vma) helper [b5330628546616af14ff23075fbf8d4ad91f6e25] Sriram Rajagopalan (1): ext4: zero out the unused memory region in the extent tree block [592acbf16821288ecdc4192c47e3774a4c48bb64] Young Xiao (1): Bluetooth: hidp: fix buffer overflow [a1616a5ac99ede5d605047a9012481ce7ff18b16] Documentation/networking/ip-sysctl.txt | 8 ++++++++ Makefile | 4 ++-- drivers/scsi/megaraid/megaraid_sas_base.c | 1 + drivers/virt/fsl_hypervisor.c | 3 +++ fs/ext4/extents.c | 17 +++++++++++++++-- include/linux/mm.h | 5 +++++ include/linux/tcp.h | 3 +++ include/net/tcp.h | 3 +++ include/uapi/linux/snmp.h | 1 + mm/memory.c | 8 ++++---- mm/mincore.c | 21 +++++++++++++++++++++ net/bluetooth/hidp/sock.c | 1 + net/ipv4/proc.c | 1 + net/ipv4/sysctl_net_ipv4.c | 11 +++++++++++ net/ipv4/tcp.c | 1 + net/ipv4/tcp_input.c | 27 ++++++++++++++++++++++----- net/ipv4/tcp_output.c | 9 +++++++-- net/ipv4/tcp_timer.c | 1 + 18 files changed, 110 insertions(+), 15 deletions(-) -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett

4 years, 10 months

3
14
0 0

[PATCH] dmaengine: qcom: bam_dma: Fix completed descriptors count

by Sricharan R

One space is left unused in circular FIFO to differentiate 'full' and 'empty' cases. So take that in to account while counting for the descriptors completed. Fixes the issue reported here, https://lkml.org/lkml/2019/6/18/669 Cc: stable(a)vger.kernel.org Reported-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Sricharan R <sricharan(a)codeaurora.org> --- drivers/dma/qcom/bam_dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c index 4b43844..8e90a40 100644 --- a/drivers/dma/qcom/bam_dma.c +++ b/drivers/dma/qcom/bam_dma.c @@ -799,6 +799,9 @@ static u32 process_channel_irqs(struct bam_device *bdev) /* Number of bytes available to read */ avail = CIRC_CNT(offset, bchan->head, MAX_DESCRIPTORS + 1); + if (offset < bchan->head) + avail--; + list_for_each_entry_safe(async_desc, tmp, &bchan->desc_list, desc_node) { /* Not enough data to read */ -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

4 years, 10 months

3
2
0 0

[PATCH v2] dmaengine: imx-sdma: remove BD_INTR for channel0

by yibin.gong＠nxp.com

From: Robin Gong <yibin.gong(a)nxp.com> It is possible for an irq triggered by channel0 to be received later after clks are disabled once firmware loaded during sdma probe. If that happens then clearing them by writing to SDMA_H_INTR won't work and the kernel will hang processing infinite interrupts. Actually, don't need interrupt triggered on channel0 since it's pollling SDMA_H_STATSTOP to know channel0 done rather than interrupt in current code, just clear BD_INTR to disable channel0 interrupt to avoid the above case. This issue was brought by commit 1d069bfa3c78 ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") which didn't take care the above case. Fixes: 1d069bfa3c78 ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") Cc: stable(a)vger.kernel.org #5.0+ Signed-off-by: Robin Gong <yibin.gong(a)nxp.com> Reported-by: Sven Van Asbroeck <thesven73(a)gmail.com> Tested-by: Sven Van Asbroeck <thesven73(a)gmail.com> --- drivers/dma/imx-sdma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index deea9aa..b5a1ee2 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -742,7 +742,7 @@ static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size, spin_lock_irqsave(&sdma->channel_0_lock, flags); bd0->mode.command = C0_SETPM; - bd0->mode.status = BD_DONE | BD_INTR | BD_WRAP | BD_EXTD; + bd0->mode.status = BD_DONE | BD_WRAP | BD_EXTD; bd0->mode.count = size / 2; bd0->buffer_addr = buf_phys; bd0->ext_buffer_addr = address; @@ -1064,7 +1064,7 @@ static int sdma_load_context(struct sdma_channel *sdmac) context->gReg[7] = sdmac->watermark_level; bd0->mode.command = C0_SETDM; - bd0->mode.status = BD_DONE | BD_INTR | BD_WRAP | BD_EXTD; + bd0->mode.status = BD_DONE | BD_WRAP | BD_EXTD; bd0->mode.count = sizeof(*context) / 4; bd0->buffer_addr = sdma->context_phys; bd0->ext_buffer_addr = 2048 + (sizeof(*context) / 4) * channel; -- 2.7.4

4 years, 10 months

6
6
0 0

[PATCH] filesystem-dax: Disable PMD support

by Dan Williams

Ever since the conversion of DAX to the Xarray a RocksDB benchmark has been encountering intermittent lockups. The backtraces always include the filesystem-DAX PMD path, multi-order entries have been a source of bugs in the past, and disabling the PMD path allows a test that fails in minutes to run for an hour. The regression has been bisected to "dax: Convert page fault handlers to XArray", but little progress has been made on the root cause debug. Unless / until root cause can be identified mark CONFIG_FS_DAX_PMD broken to preclude intermittent lockups. Reverting the Xarray conversion also works, but that change is too big to backport. The implementation is committed to Xarray at this point. Link: https://lore.kernel.org/linux-fsdevel/CAPcyv4hwHpX-MkUEqxwdTj7wCCZCN4RV-L4j… Fixes: b15cd800682f ("dax: Convert page fault handlers to XArray") Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Jan Kara <jack(a)suse.cz> Cc: <stable(a)vger.kernel.org> Reported-by: Robert Barror <robert.barror(a)intel.com> Reported-by: Seema Pandit <seema.pandit(a)intel.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- fs/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/Kconfig b/fs/Kconfig index f1046cf6ad85..85eecd0d4c5d 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -66,6 +66,9 @@ config FS_DAX_PMD depends on FS_DAX depends on ZONE_DEVICE depends on TRANSPARENT_HUGEPAGE + # intermittent lockups since commit b15cd800682f "dax: Convert + # page fault handlers to XArray" + depends on BROKEN # Selected by DAX drivers that do not expect filesystem DAX to support # get_user_pages() of DAX mappings. I.e. "limited" indicates no support

4 years, 10 months

4
23
0 0

[PATCH AUTOSEL 5.1 01/51] HID: i2c-hid: add iBall Aer3 to descriptor override

by Sasha Levin

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit eb6964fa6509b4f1152313f1e0bb67f0c54a6046 ] This device uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. BugLink: https://bugs.launchpad.net/bugs/1825718 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c index fd1b6eea6d2f..75078c83be1a 100644 --- a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c +++ b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c @@ -354,6 +354,14 @@ static const struct dmi_system_id i2c_hid_dmi_desc_override_table[] = { }, .driver_data = (void *)&sipodev_desc }, + { + .ident = "iBall Aer3", + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "iBall"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Aer3"), + }, + .driver_data = (void *)&sipodev_desc + }, { } /* Terminate list */ }; -- 2.20.1

4 years, 10 months

3
66
0 0

[4.19.y PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request()

by Guilherme G. Piccoli

----------------------------------------------------------------- This patch is not on mainline and is meant to 4.19 stable *only*. After the patch description there's a reasoning about that. ----------------------------------------------------------------- Commit 37f9579f4c31 ("blk-mq: Avoid that submitting a bio concurrently with device removal triggers a crash") introduced a NULL pointer dereference in generic_make_request(). The patch sets q to NULL and enter_succeeded to false; right after, there's an 'if (enter_succeeded)' which is not taken, and then the 'else' will dereference q in blk_queue_dying(q). This patch just moves the 'q = NULL' to a point in which it won't trigger the oops, although the semantics of this NULLification remains untouched. A simple test case/reproducer is as follows: a) Build kernel v4.19.56-stable with CONFIG_BLK_CGROUP=n. b) Create a raid0 md array with 2 NVMe devices as members, and mount it with an ext4 filesystem. c) Run the following oneliner (supposing the raid0 is mounted in /mnt): (dd of=/mnt/tmp if=/dev/zero bs=1M count=999 &); sleep 0.3; echo 1 > /sys/block/nvme1n1/device/device/remove (whereas nvme1n1 is the 2nd array member) This will trigger the following oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI RIP: 0010:generic_make_request+0x32b/0x400 Call Trace: submit_bio+0x73/0x140 ext4_io_submit+0x4d/0x60 ext4_writepages+0x626/0xe90 do_writepages+0x4b/0xe0 [...] This patch has no functional changes and preserves the md/raid0 behavior when a member is removed before kernel v4.17. ---------------------------- Why this is not on mainline? ---------------------------- The patch was originally submitted upstream in linux-raid and linux-block mailing-lists - it was initially accepted by Song Liu, but Christoph Hellwig[0] observed that there was a clean-up series ready to be accepted from Ming Lei[1] that fixed the same issue. The accepted patches from Ming's series in upstream are: commit 47cdee29ef9d ("block: move blk_exit_queue into __blk_release_queue") and commit fe2008640ae3 ("block: don't protect generic_make_request_checks with blk_queue_enter"). Those patches basically do a clean-up in the block layer involving: 1) Putting back blk_exit_queue() logic into __blk_release_queue(); that path was changed in the past and the logic from blk_exit_queue() was added to blk_cleanup_queue(). 2) Removing the guard/protection in generic_make_request_checks() with blk_queue_enter(). The problem with Ming's series for -stable is that it relies in the legacy request IO path removal. So it's "backport-able" to v5.0+, but doing that for early versions (like 4.19) would incur in complex code changes. Hence, it was suggested by Christoph and Song Liu that this patch was submitted to stable only; otherwise merging it upstream would add code to fix a path removed in a subsequent commit. [0] lore.kernel.org/linux-block/20190521172258.GA32702@infradead.org [1] lore.kernel.org/linux-block/20190515030310.20393-1-ming.lei@redhat.com Cc: Christoph Hellwig <hch(a)lst.de> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Song Liu <songliubraving(a)fb.com> Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Tested-by: Eric Ren <renzhengeek(a)gmail.com> Fixes: 37f9579f4c31 ("blk-mq: Avoid that submitting a bio concurrently with device removal triggers a crash") Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)canonical.com> --- block/blk-core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 6eed5d84c2ef..682bc561b77b 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -2445,10 +2445,8 @@ blk_qc_t generic_make_request(struct bio *bio) flags = 0; if (bio->bi_opf & REQ_NOWAIT) flags = BLK_MQ_REQ_NOWAIT; - if (blk_queue_enter(q, flags) < 0) { + if (blk_queue_enter(q, flags) < 0) enter_succeeded = false; - q = NULL; - } } if (enter_succeeded) { @@ -2479,6 +2477,7 @@ blk_qc_t generic_make_request(struct bio *bio) bio_wouldblock_error(bio); else bio_io_error(bio); + q = NULL; } bio = bio_list_pop(&bio_list_on_stack[0]); } while (bio); -- 2.22.0

4 years, 10 months

4
5
0 0

[PATCH] usb: dwc2: use a longer AHB idle timeout in dwc2_core_reset()

by Martin Blumenstingl

Use a 10000us AHB idle timeout in dwc2_core_reset() and make it consistent with the other "wait for AHB master IDLE state" ocurrences. This fixes a problem for me where dwc2 would not want to initialize when updating to 4.19 on a MIPS Lantiq VRX200 SoC. dwc2 worked fine with 4.14. Testing on my board shows that it takes 180us until AHB master IDLE state is signalled. The very old vendor driver for this SoC (ifxhcd) used a 1 second timeout. Use the same timeout that is used everywhere when polling for GRSTCTL_AHBIDLE instead of using a timeout that "works for one board" (180us in my case) to have consistent behavior across the dwc2 driver. Cc: linux-stable <stable(a)vger.kernel.org> # 4.19+ Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> --- drivers/usb/dwc2/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index 8b499d643461..8e41d70fd298 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -531,7 +531,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait) } /* Wait for AHB master IDLE state */ - if (dwc2_hsotg_wait_bit_set(hsotg, GRSTCTL, GRSTCTL_AHBIDLE, 50)) { + if (dwc2_hsotg_wait_bit_set(hsotg, GRSTCTL, GRSTCTL_AHBIDLE, 10000)) { dev_warn(hsotg->dev, "%s: HANG! AHB Idle timeout GRSTCTL GRSTCTL_AHBIDLE\n", __func__); return -EBUSY; -- 2.22.0

4 years, 10 months

3
4
0 0

[STABLE 4.19] fixes for xfs memory and fs corruption

by Amir Goldstein

Darrick, Can I have your blessing on the choice of these upstream commits as stable candidates? I did not observe any xfstests regressions when testing v4.19.55 with these patches applied. Sasha, Can you run these patches though your xfstests setup? They fix nasty bugs. Make sure to update xfsprogs to very latest, because generic/530 used to blow up (OOM) my test machine... > > The first patch fixes a memory corruption that syzkaller found in the > attr listent code; 3b50086f0c0d xfs: don't overflow xattr listent buffer > see "generic: posix acl extended attribute memory > corruption test" for the relevant regression test. Fixed generic/529 > > Patches 2 fixes problems found in XFS's unlinked inode recovery code > that were unearthed by some new testcases. We're logging nlink==1 temp > files on the iunlinked list (and then the vfs sets nlink to 0 without > telling us) which means that we leak them in recovery if we crash > immediately after the committing the creation of the temp file. > > Patch 3 fixes the problem that ifree during recovery can expand the > finobt but we need to force the ifree code to reserve blocks for the > transaction because perag reservations aren't set up yet. e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list > > See "[PATCH v2 2/2] generic: check the behavior of programs opening a > lot of O_TMPFILE files" for the regression test. > Fixes generic/530 Thanks, Amir.

4 years, 10 months

3
3
0 0

[PATCH 1/2] regulator: s2mps11: Fix buck7 and buck8 wrong voltages

by Krzysztof Kozlowski

On S2MPS11 device, the buck7 and buck8 regulator voltages start at 750 mV, not 600 mV. Using wrong minimal value caused shifting of these regulator values by 150 mV (e.g. buck7 usually configured to v1.35 V was reported as 1.2 V). On most of the boards these regulators are left in default state so this was only affecting reported voltage. However if any driver wanted to change them, then effectively it would set voltage 150 mV higher than intended. Cc: <stable(a)vger.kernel.org> Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver") Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- drivers/regulator/s2mps11.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c index a215cfe20555..8f3c8730dc0d 100644 --- a/drivers/regulator/s2mps11.c +++ b/drivers/regulator/s2mps11.c @@ -479,8 +479,8 @@ static const struct regulator_desc s2mps11_regulators[] = { regulator_desc_s2mps11_buck1_4(4), regulator_desc_s2mps11_buck5, regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV), - regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV), - regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV), + regulator_desc_s2mps11_buck67810(7, MIN_750_MV, STEP_12_5_MV), + regulator_desc_s2mps11_buck67810(8, MIN_750_MV, STEP_12_5_MV), regulator_desc_s2mps11_buck9, regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV), }; -- 2.17.1

4 years, 10 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2019