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

[Linux-stable-mirror] Patch "MIPS: AR7: ensure the port type's FCR value is used" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: AR7: ensure the port type's FCR value is used to the 4.4-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-ar7-ensure-the-port-type-s-fcr-value-is-used.patch and it can be found in the queue-4.4 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 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001 From: Jonas Gorski <jonas.gorski(a)gmail.com> Date: Sun, 29 Oct 2017 16:27:21 +0100 Subject: MIPS: AR7: ensure the port type's FCR value is used From: Jonas Gorski <jonas.gorski(a)gmail.com> commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream. Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers"), the port's default FCR value isn't used in serial8250_do_set_termios anymore, but copied over once in serial8250_config_port and then modified as needed. Unfortunately, serial8250_config_port will never be called if the port is shared between kernel and userspace, and the port's flag doesn't have UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well. This causes garbled output from userspace: [ 5.220000] random: procd urandom read with 49 bits of entropy available ers [kee Fix this by forcing it to be configured on boot, resulting in the expected output: [ 5.250000] random: procd urandom read with 50 bits of entropy available Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers") Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17544/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Cc: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -576,7 +576,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; - uart_port.flags = UPF_FIXED_TYPE; + uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are queue-4.4/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: ensure the port type's FCR value is used" 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: AR7: ensure the port type's FCR value is used 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-ar7-ensure-the-port-type-s-fcr-value-is-used.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 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001 From: Jonas Gorski <jonas.gorski(a)gmail.com> Date: Sun, 29 Oct 2017 16:27:21 +0100 Subject: MIPS: AR7: ensure the port type's FCR value is used From: Jonas Gorski <jonas.gorski(a)gmail.com> commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream. Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers"), the port's default FCR value isn't used in serial8250_do_set_termios anymore, but copied over once in serial8250_config_port and then modified as needed. Unfortunately, serial8250_config_port will never be called if the port is shared between kernel and userspace, and the port's flag doesn't have UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well. This causes garbled output from userspace: [ 5.220000] random: procd urandom read with 49 bits of entropy available ers [kee Fix this by forcing it to be configured on boot, resulting in the expected output: [ 5.250000] random: procd urandom read with 50 bits of entropy available Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers") Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17544/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Cc: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -575,7 +575,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; - uart_port.flags = UPF_FIXED_TYPE; + uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are queue-4.14/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH RFC 3/3] MIPS: AR7: ensure the port type's FCR value is used

by Greg Kroah-Hartman

On Mon, Jan 22, 2018 at 01:07:19PM +0000, James Hogan wrote: > Hi stable maintainers, > > On Sun, Oct 29, 2017 at 04:27:21PM +0100, Jonas Gorski wrote: > > Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt > > trigger I/F of FIFO buffers"), the port's default FCR value isn't used > > in serial8250_do_set_termios anymore, but copied over once in > > serial8250_config_port and then modified as needed. > > > > Unfortunately, serial8250_config_port will never be called if the port > > is shared between kernel and userspace, and the port's flag doesn't have > > UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well. > > > > This causes garbled output from userspace: > > > > [ 5.220000] random: procd urandom read with 49 bits of entropy available > > ers > > [kee > > > > Fix this by forcing it to be configured on boot, resulting in the > > expected output: > > > > [ 5.250000] random: procd urandom read with 50 bits of entropy available > > Press the [f] key and hit [enter] to enter failsafe mode > > Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level > > > > Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers") > > Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> > > Please can this patch be applied to stable branches 3.17+. It is now > merged into mainline as commit 0a5191efe06b ("MIPS: AR7: ensure the port > type's FCR value is used"). > > Commit b084116f8587 ("MIPS: AR7: Ensure that serial ports are properly > set up") is a prerequisite for it to apply cleanly, but is already > tagged for stable. Now snuck into this round of stable -rc review :) thanks, greg k-h

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: ensure the port type's FCR value is used" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: AR7: ensure the port type's FCR value is used to the 3.18-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-ar7-ensure-the-port-type-s-fcr-value-is-used.patch and it can be found in the queue-3.18 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 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001 From: Jonas Gorski <jonas.gorski(a)gmail.com> Date: Sun, 29 Oct 2017 16:27:21 +0100 Subject: MIPS: AR7: ensure the port type's FCR value is used From: Jonas Gorski <jonas.gorski(a)gmail.com> commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream. Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers"), the port's default FCR value isn't used in serial8250_do_set_termios anymore, but copied over once in serial8250_config_port and then modified as needed. Unfortunately, serial8250_config_port will never be called if the port is shared between kernel and userspace, and the port's flag doesn't have UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well. This causes garbled output from userspace: [ 5.220000] random: procd urandom read with 49 bits of entropy available ers [kee Fix this by forcing it to be configured on boot, resulting in the expected output: [ 5.250000] random: procd urandom read with 50 bits of entropy available Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers") Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17544/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Cc: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -581,7 +581,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; - uart_port.flags = UPF_FIXED_TYPE; + uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are queue-3.18/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] patch "serial: 8250_dw: Revert "Improve clock rate setting"" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_dw: Revert "Improve clock rate setting" 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-testing 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 be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From c14b65feac9ebed649d6fe79c6b6d64d21d0287d Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Fri, 19 Jan 2018 18:02:05 +0200 Subject: serial: 8250_dw: Revert "Improve clock rate setting" The commit de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting") obviously tries to cure symptoms, and not a root cause. The root cause is the non-flexible rate calculation inside the corresponding clock driver. What we need is to provide maximum UART divisor value to the clock driver to allow it do the job transparently to the caller. Since from the initial commit message I have got no clue which clock driver actually needs to be amended, I leave this exercise to the people who know better the case. Moreover, it seems [1] the fix introduced a regression. And possible even one more [2]. Taking above, revert the commit de9e33bdfa22 for now. [1]: https://www.spinics.net/lists/linux-serial/msg28872.html [2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782 Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting") Cc: stable <stable(a)vger.kernel.org> # 4.15 Cc: Ed Blake <ed.blake(a)sondrel.com> Cc: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Cc: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_dw.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index bda75d317d24..cd1b94a0f451 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -252,31 +252,25 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios, struct ktermios *old) { unsigned int baud = tty_termios_baud_rate(termios); - unsigned int target_rate, min_rate, max_rate; struct dw8250_data *d = p->private_data; long rate; - int i, ret; + int ret; if (IS_ERR(d->clk) || !old) goto out; - /* Find a clk rate within +/-1.6% of an integer multiple of baudx16 */ - target_rate = baud * 16; - min_rate = target_rate - (target_rate >> 6); - max_rate = target_rate + (target_rate >> 6); - - for (i = 1; i <= UART_DIV_MAX; i++) { - rate = clk_round_rate(d->clk, i * target_rate); - if (rate >= i * min_rate && rate <= i * max_rate) - break; - } - if (i <= UART_DIV_MAX) { - clk_disable_unprepare(d->clk); + clk_disable_unprepare(d->clk); + rate = clk_round_rate(d->clk, baud * 16); + if (rate < 0) + ret = rate; + else if (rate == 0) + ret = -ENOENT; + else ret = clk_set_rate(d->clk, rate); - clk_prepare_enable(d->clk); - if (!ret) - p->uartclk = rate; - } + clk_prepare_enable(d->clk); + + if (!ret) + p->uartclk = rate; out: p->status &= ~UPSTAT_AUTOCTS; -- 2.16.0

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH v6] RFT: mmc: sdhci: Implement an SDHCI-specific bounce buffer

by Linus Walleij

The bounce buffer is gone from the MMC core, and now we found out that there are some (crippled) i.MX boards out there that have broken ADMA (cannot do scatter-gather), and also broken PIO so they must use SDMA. Closer examination shows a less significant slowdown also on SDMA-only capable Laptop hosts. SDMA sets down the number of segments to one, so that each segment gets turned into a singular request that ping-pongs to the block layer before the next request/segment is issued. Apparently it happens a lot that the block layer send requests that include a lot of physically discontigous segments. My guess is that this phenomenon is coming from the file system. These devices that cannot handle scatterlists in hardware can see major benefits from a DMA-contigous bounce buffer. This patch accumulates those fragmented scatterlists in a physically contigous bounce buffer so that we can issue bigger DMA data chunks to/from the card. When tested with thise PCI-integrated host (1217:8221) that only supports SDMA: 0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS SD/MMC Card Reader Controller (rev 05) This patch gave ~1Mbyte/s improved throughput on large reads and writes when testing using iozone than without the patch. dmesg: sdhci-pci 0000:0b:00.0: SDHCI controller found [1217:8221] (rev 5) mmc0 bounce up to 128 segments into one, max segment size 65536 bytes mmc0: SDHCI controller on PCI [0000:0b:00.0] using DMA On the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35 the patch restores the performance to what it was before we removed the bounce buffers, and then some: performance is better than ever because we now allocate a bounce buffer the size of the maximum single request the SDMA engine can handle. On the PCI laptop this is 256K, whereas with the old bounce buffer code it was 64K max. Cc: Benjamin Beckmeyer <beckmeyer.b(a)rittal.de> Cc: Pierre Ossman <pierre(a)ossman.eu> Cc: Benoît Thébaudeau <benoit(a)wsystem.com> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: stable(a)vger.kernel.org Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling") Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- ChangeLog v5->v6: - Again switch back to explicit sync of buffers. I want to get this solution to work because it gives more control and it's more elegant. - Update host->max_req_size as noted by Adrian, hopefully this fixes the i.MX. I was just lucky on my Intel laptop I guess: the block stack never requested anything bigger than 64KB and that was why it worked even if max_req_size was bigger than what would fit in the bounce buffer. - Copy the number of bytes in the mmc_data instead of the number of bytes in the bounce buffer. For RX this is blksize * blocks and for TX this is bytes_xfered. - Break out a sdhci_sdma_address() for getting the DMA address for either the raw sglist or the bounce buffer depending on configuration. - Add some explicit bounds check for the data so that we do not attempt to copy more than the bounce buffer size even if the block layer is erroneously configured. - Move allocation of bounce buffer out to its own function. - Use pr_[info|err] throughout so all debug prints from the driver come out in the same manner and style. - Use unsigned int for the bounce buffer size. - Re-tested with iozone: we still get the same nice performance improvements. - Request a text on i.MX (hi Benjamin) ChangeLog v4->v5: - Go back to dma_alloc_coherent() as this apparently works better. - Keep the other changes, cap for 64KB, fall back to single segments. - Requesting a test of this on i.MX. (Sorry Benjamin.) ChangeLog v3->v4: - Cap the bounce buffer to 64KB instead of the biggest segment as we experience diminishing returns with buffers > 64KB. - Instead of using dma_alloc_coherent(), use good old devm_kmalloc() and issue dma_sync_single_for*() to explicitly switch ownership between CPU and the device. This way we exercise the cache better and may consume less CPU. - Bail out with single segments if we cannot allocate a bounce buffer. - Tested on the PCI SDHCI on my laptop: requesting a new test on i.MX from Benjamin. (Please!) ChangeLog v2->v3: - Rewrite the commit message a bit - Add Benjamin's Tested-by - Add Fixes and stable tags ChangeLog v1->v2: - Skip the remapping and fiddling with the buffer, instead use dma_alloc_coherent() and use a simple, coherent bounce buffer. - Couple kernel messages to ->parent of the mmc_host as it relates to the hardware characteristics. --- drivers/mmc/host/sdhci.c | 162 ++++++++++++++++++++++++++++++++++++++++++++--- drivers/mmc/host/sdhci.h | 3 + 2 files changed, 157 insertions(+), 8 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index e9290a3439d5..26b93d72f56d 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -21,6 +21,7 @@ #include <linux/dma-mapping.h> #include <linux/slab.h> #include <linux/scatterlist.h> +#include <linux/sizes.h> #include <linux/swiotlb.h> #include <linux/regulator/consumer.h> #include <linux/pm_runtime.h> @@ -502,8 +503,35 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host, if (data->host_cookie == COOKIE_PRE_MAPPED) return data->sg_count; - sg_count = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len, - mmc_get_dma_dir(data)); + /* Bounce write requests to the bounce buffer */ + if (host->bounce_buffer) { + unsigned int length = data->blksz * data->blocks; + + if (length > host->bounce_buffer_size) { + pr_err("%s: asked for transfer of %u bytes exceeds bounce buffer %u bytes\n", + mmc_hostname(host->mmc), length, + host->bounce_buffer_size); + return -EIO; + } + if (mmc_get_dma_dir(data) == DMA_TO_DEVICE) { + /* Copy the data to the bounce buffer */ + sg_copy_to_buffer(data->sg, data->sg_len, + host->bounce_buffer, + length); + } + /* Switch ownership to the DMA */ + dma_sync_single_for_device(host->mmc->parent, + host->bounce_addr, + host->bounce_buffer_size, + DMA_TO_DEVICE); + /* Just a dummy value */ + sg_count = 1; + } else { + /* Just access the data directly from memory */ + sg_count = dma_map_sg(mmc_dev(host->mmc), + data->sg, data->sg_len, + mmc_get_dma_dir(data)); + } if (sg_count == 0) return -ENOSPC; @@ -858,8 +886,13 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd) SDHCI_ADMA_ADDRESS_HI); } else { WARN_ON(sg_cnt != 1); - sdhci_writel(host, sg_dma_address(data->sg), - SDHCI_DMA_ADDRESS); + /* Bounce buffer goes to work */ + if (host->bounce_buffer) + sdhci_writel(host, host->bounce_addr, + SDHCI_DMA_ADDRESS); + else + sdhci_writel(host, sg_dma_address(data->sg), + SDHCI_DMA_ADDRESS); } } @@ -2248,7 +2281,12 @@ static void sdhci_pre_req(struct mmc_host *mmc, struct mmc_request *mrq) mrq->data->host_cookie = COOKIE_UNMAPPED; - if (host->flags & SDHCI_REQ_USE_DMA) + /* + * No pre-mapping in the pre hook if we're using the bounce buffer, + * for that we would need two bounce buffers since one buffer is + * in flight when this is getting called. + */ + if (host->flags & SDHCI_REQ_USE_DMA && !host->bounce_buffer) sdhci_pre_dma_transfer(host, mrq->data, COOKIE_PRE_MAPPED); } @@ -2352,8 +2390,38 @@ static bool sdhci_request_done(struct sdhci_host *host) struct mmc_data *data = mrq->data; if (data && data->host_cookie == COOKIE_MAPPED) { - dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, - mmc_get_dma_dir(data)); + if (host->bounce_buffer) { + /* + * On reads, copy the bounced data into the + * sglist + */ + if (mmc_get_dma_dir(data) == DMA_FROM_DEVICE) { + unsigned int length = data->bytes_xfered; + + if (length > host->bounce_buffer_size) { + pr_err("%s: bounce buffer is %u bytes but DMA claims to have transferred %u bytes\n", + mmc_hostname(host->mmc), + host->bounce_buffer_size, + data->bytes_xfered); + /* Cap it down and continue */ + length = host->bounce_buffer_size; + } + dma_sync_single_for_cpu( + host->mmc->parent, + host->bounce_addr, + host->bounce_buffer_size, + DMA_FROM_DEVICE); + sg_copy_from_buffer(data->sg, + data->sg_len, + host->bounce_buffer, + length); + } + } else { + /* Unmap the raw data */ + dma_unmap_sg(mmc_dev(host->mmc), data->sg, + data->sg_len, + mmc_get_dma_dir(data)); + } data->host_cookie = COOKIE_UNMAPPED; } } @@ -2543,6 +2611,14 @@ static void sdhci_adma_show_error(struct sdhci_host *host) } } +static u32 sdhci_sdma_address(struct sdhci_host *host) +{ + if (host->bounce_buffer) + return host->bounce_addr; + else + return sg_dma_address(host->data->sg); +} + static void sdhci_data_irq(struct sdhci_host *host, u32 intmask) { u32 command; @@ -2636,7 +2712,8 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask) */ if (intmask & SDHCI_INT_DMA_END) { u32 dmastart, dmanow; - dmastart = sg_dma_address(host->data->sg); + + dmastart = sdhci_sdma_address(host); dmanow = dmastart + host->data->bytes_xfered; /* * Force update to the next DMA block boundary. @@ -3217,6 +3294,68 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1) } EXPORT_SYMBOL_GPL(__sdhci_read_caps); +static int sdhci_allocate_bounce_buffer(struct sdhci_host *host) +{ + struct mmc_host *mmc = host->mmc; + unsigned int max_blocks; + unsigned int bounce_size; + int ret; + + /* + * Cap the bounce buffer at 64KB. Using a bigger bounce buffer + * has diminishing returns, this is probably because SD/MMC + * cards are usually optimized to handle this size of requests. + */ + bounce_size = SZ_64K; + /* + * Adjust downwards to maximum request size if this is less + * than our segment size, else hammer down the maximum + * request size to the maximum buffer size. + */ + if (mmc->max_req_size < bounce_size) + bounce_size = mmc->max_req_size; + max_blocks = bounce_size / 512; + + /* + * When we just support one segment, we can get significant + * speedups by the help of a bounce buffer to group scattered + * reads/writes together. + */ + host->bounce_buffer = devm_kmalloc(mmc->parent, + bounce_size, + GFP_KERNEL); + if (!host->bounce_buffer) { + pr_err("%s: failed to allocate %u bytes for bounce buffer, falling back to single segments\n", + mmc_hostname(mmc), + bounce_size); + /* + * Exiting with zero here makes sure we proceed with + * mmc->max_segs == 1. + */ + return 0; + } + + host->bounce_addr = dma_map_single(mmc->parent, + host->bounce_buffer, + bounce_size, + DMA_BIDIRECTIONAL); + ret = dma_mapping_error(mmc->parent, host->bounce_addr); + if (ret) + /* Again fall back to max_segs == 1 */ + return 0; + host->bounce_buffer_size = bounce_size; + + /* Lie about this since we're bouncing */ + mmc->max_segs = max_blocks; + mmc->max_seg_size = bounce_size; + mmc->max_req_size = bounce_size; + + pr_info("%s bounce up to %u segments into one, max segment size %u bytes\n", + mmc_hostname(mmc), max_blocks, bounce_size); + + return 0; +} + int sdhci_setup_host(struct sdhci_host *host) { struct mmc_host *mmc; @@ -3713,6 +3852,13 @@ int sdhci_setup_host(struct sdhci_host *host) */ mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535; + if (mmc->max_segs == 1) { + /* This may alter mmc->*_blk_* parameters */ + ret = sdhci_allocate_bounce_buffer(host); + if (ret) + return ret; + } + return 0; unreg: diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index 54bc444c317f..1d7d61e25dbf 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -440,6 +440,9 @@ struct sdhci_host { int irq; /* Device IRQ */ void __iomem *ioaddr; /* Mapped address */ + char *bounce_buffer; /* For packing SDMA reads/writes */ + dma_addr_t bounce_addr; + unsigned int bounce_buffer_size; const struct sdhci_ops *ops; /* Low level hw interface */ -- 2.14.3

7 years, 5 months

2
6
0 0

[Linux-stable-mirror] Patch "arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls to the 3.18-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: arm64-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch and it can be found in the queue-3.18 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 acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 16 Jan 2018 10:23:47 +0000 Subject: arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls From: Marc Zyngier <marc.zyngier(a)arm.com> commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd upstream. KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/kvm/handle_exit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -34,7 +34,7 @@ static int handle_hvc(struct kvm_vcpu *v ret = kvm_psci_call(vcpu); if (ret < 0) { - kvm_inject_undefined(vcpu); + *vcpu_reg(vcpu, 0) = ~0UL; return 1; } @@ -43,7 +43,7 @@ static int handle_hvc(struct kvm_vcpu *v static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run) { - kvm_inject_undefined(vcpu); + *vcpu_reg(vcpu, 0) = ~0UL; return 1; } Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-3.18/arm64-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls to the 3.18-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: arm64-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch and it can be found in the queue-3.18 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 acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 16 Jan 2018 10:23:47 +0000 Subject: arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls From: Marc Zyngier <marc.zyngier(a)arm.com> commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd upstream. KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1 must be returned to the caller when getting an unknown function number. Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/kvm/handle_exit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -34,7 +34,7 @@ static int handle_hvc(struct kvm_vcpu *v ret = kvm_psci_call(vcpu); if (ret < 0) { - kvm_inject_undefined(vcpu); + vcpu_set_reg(vcpu, 0, ~0UL); return 1; } @@ -43,7 +43,7 @@ static int handle_hvc(struct kvm_vcpu *v static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run) { - kvm_inject_undefined(vcpu); + vcpu_set_reg(vcpu, 0, ~0UL); return 1; } Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-3.18/arm64-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] Patch "x86/retpoline: Optimize inline assembler for vmexit_fill_RSB" 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 x86/retpoline: Optimize inline assembler for vmexit_fill_RSB 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: x86-retpoline-optimize-inline-assembler-for-vmexit_fill_rsb.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 3f7d875566d8e79c5e0b2c9a413e91b2c29e0854 Mon Sep 17 00:00:00 2001 From: Andi Kleen <ak(a)linux.intel.com> Date: Wed, 17 Jan 2018 14:53:28 -0800 Subject: x86/retpoline: Optimize inline assembler for vmexit_fill_RSB From: Andi Kleen <ak(a)linux.intel.com> commit 3f7d875566d8e79c5e0b2c9a413e91b2c29e0854 upstream. The generated assembler for the C fill RSB inline asm operations has several issues: - The C code sets up the loop register, which is then immediately overwritten in __FILL_RETURN_BUFFER with the same value again. - The C code also passes in the iteration count in another register, which is not used at all. Remove these two unnecessary operations. Just rely on the single constant passed to the macro for the iterations. Signed-off-by: Andi Kleen <ak(a)linux.intel.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Acked-by: David Woodhouse <dwmw(a)amazon.co.uk> Cc: dave.hansen(a)intel.com Cc: gregkh(a)linuxfoundation.org Cc: torvalds(a)linux-foundation.org Cc: arjan(a)linux.intel.com Link: https://lkml.kernel.org/r/20180117225328.15414-1-andi@firstfloor.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/nospec-branch.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -206,16 +206,17 @@ extern char __indirect_thunk_end[]; static inline void vmexit_fill_RSB(void) { #ifdef CONFIG_RETPOLINE - unsigned long loops = RSB_CLEAR_LOOPS / 2; + unsigned long loops; asm volatile (ANNOTATE_NOSPEC_ALTERNATIVE ALTERNATIVE("jmp 910f", __stringify(__FILL_RETURN_BUFFER(%0, RSB_CLEAR_LOOPS, %1)), X86_FEATURE_RETPOLINE) "910:" - : "=&r" (loops), ASM_CALL_CONSTRAINT - : "r" (loops) : "memory" ); + : "=r" (loops), ASM_CALL_CONSTRAINT + : : "memory" ); #endif } + #endif /* __ASSEMBLY__ */ #endif /* __NOSPEC_BRANCH_H__ */ Patches currently in stable-queue which might be from ak(a)linux.intel.com are queue-4.9/perf-tools-fix-build-with-arch-x86_64.patch queue-4.9/kprobes-x86-disable-optimizing-on-the-function-jumps-to-indirect-thunk.patch queue-4.9/module-add-retpoline-tag-to-vermagic.patch queue-4.9/kprobes-x86-blacklist-indirect-thunk-functions-for-kprobes.patch queue-4.9/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch queue-4.9/x86-retpoline-add-lfence-to-the-retpoline-rsb-filling-rsb-macros.patch queue-4.9/x86-retpoline-optimize-inline-assembler-for-vmexit_fill_rsb.patch queue-4.9/retpoline-introduce-start-end-markers-of-indirect-thunk.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/mce: Make machine check speculation protected" 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 x86/mce: Make machine check speculation protected 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: x86-mce-make-machine-check-speculation-protected.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 6f41c34d69eb005e7848716bbcafc979b35037d5 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Thu, 18 Jan 2018 16:28:26 +0100 Subject: x86/mce: Make machine check speculation protected From: Thomas Gleixner <tglx(a)linutronix.de> commit 6f41c34d69eb005e7848716bbcafc979b35037d5 upstream. The machine check idtentry uses an indirect branch directly from the low level code. This evades the speculation protection. Replace it by a direct call into C code and issue the indirect call there so the compiler can apply the proper speculation protection. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by:Borislav Petkov <bp(a)alien8.de> Reviewed-by: David Woodhouse <dwmw(a)amazon.co.uk> Niced-by: Peter Zijlstra <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801181626290.1847@nanos Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64.S | 2 +- arch/x86/include/asm/traps.h | 1 + arch/x86/kernel/cpu/mcheck/mce.c | 5 +++++ 3 files changed, 7 insertions(+), 1 deletion(-) --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1064,7 +1064,7 @@ idtentry async_page_fault do_async_page_ #endif #ifdef CONFIG_X86_MCE -idtentry machine_check has_error_code=0 paranoid=1 do_sym=*machine_check_vector(%rip) +idtentry machine_check do_mce has_error_code=0 paranoid=1 #endif /* --- a/arch/x86/include/asm/traps.h +++ b/arch/x86/include/asm/traps.h @@ -92,6 +92,7 @@ dotraplinkage void do_simd_coprocessor_e #ifdef CONFIG_X86_32 dotraplinkage void do_iret_error(struct pt_regs *, long); #endif +dotraplinkage void do_mce(struct pt_regs *, long); static inline int get_si_code(unsigned long condition) { --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -1754,6 +1754,11 @@ static void unexpected_machine_check(str void (*machine_check_vector)(struct pt_regs *, long error_code) = unexpected_machine_check; +dotraplinkage void do_mce(struct pt_regs *regs, long error_code) +{ + machine_check_vector(regs, error_code); +} + /* * Called for each booted CPU to set up machine checks. * Must be called with preempt off: Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.9/futex-prevent-overflow-by-strengthen-input-validation.patch queue-4.9/x86-mce-make-machine-check-speculation-protected.patch queue-4.9/x86-pti-document-fix-wrong-index.patch queue-4.9/timers-unconditionally-check-deferrable-base.patch queue-4.9/x86-apic-vector-fix-off-by-one-in-error-path.patch queue-4.9/objtool-improve-error-message-for-bad-file-argument.patch queue-4.9/kprobes-x86-disable-optimizing-on-the-function-jumps-to-indirect-thunk.patch queue-4.9/x86-mm-pkeys-fix-fill_sig_info_pkey.patch queue-4.9/x86-tsc-fix-erroneous-tsc-rate-on-skylake-xeon.patch queue-4.9/sched-deadline-zero-out-positive-runtime-after-throttling-constrained-tasks.patch queue-4.9/module-add-retpoline-tag-to-vermagic.patch queue-4.9/kprobes-x86-blacklist-indirect-thunk-functions-for-kprobes.patch queue-4.9/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch queue-4.9/x86-retpoline-add-lfence-to-the-retpoline-rsb-filling-rsb-macros.patch queue-4.9/x86-retpoline-optimize-inline-assembler-for-vmexit_fill_rsb.patch queue-4.9/retpoline-introduce-start-end-markers-of-indirect-thunk.patch queue-4.9/x86-cpufeature-move-processor-tracing-out-of-scattered-features.patch queue-4.9/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror