December 2020 - Linux-stable-mirror

patch "iio:magnetometer:mag3110: Fix alignment and data leak issues." added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:magnetometer:mag3110: Fix alignment and data leak issues. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 staging-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 89deb1334252ea4a8491d47654811e28b0790364 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:37 +0100 Subject: iio:magnetometer:mag3110: Fix alignment and data leak issues. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data. This data is allocated with kzalloc() so no data can leak apart from previous readings. The explicit alignment of ts is not necessary in this case but does make the code slightly less fragile so I have included it. Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org --- drivers/iio/magnetometer/mag3110.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/iio/magnetometer/mag3110.c b/drivers/iio/magnetometer/mag3110.c index 838b13c8bb3d..c96415a1aead 100644 --- a/drivers/iio/magnetometer/mag3110.c +++ b/drivers/iio/magnetometer/mag3110.c @@ -56,6 +56,12 @@ struct mag3110_data { int sleep_val; struct regulator *vdd_reg; struct regulator *vddio_reg; + /* Ensure natural alignment of timestamp */ + struct { + __be16 channels[3]; + u8 temperature; + s64 ts __aligned(8); + } scan; }; static int mag3110_request(struct mag3110_data *data) @@ -387,10 +393,9 @@ static irqreturn_t mag3110_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct mag3110_data *data = iio_priv(indio_dev); - u8 buffer[16]; /* 3 16-bit channels + 1 byte temp + padding + ts */ int ret; - ret = mag3110_read(data, (__be16 *) buffer); + ret = mag3110_read(data, data->scan.channels); if (ret < 0) goto done; @@ -399,10 +404,10 @@ static irqreturn_t mag3110_trigger_handler(int irq, void *p) MAG3110_DIE_TEMP); if (ret < 0) goto done; - buffer[6] = ret; + data->scan.temperature = ret; } - iio_push_to_buffers_with_timestamp(indio_dev, buffer, + iio_push_to_buffers_with_timestamp(indio_dev, &data->scan, iio_get_time_ns(indio_dev)); done: -- 2.29.2

3 years, 7 months

1
0
0 0

patch "iio:light:st_uvis25: Fix timestamp alignment and prevent data leak." added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:light:st_uvis25: Fix timestamp alignment and prevent data leak. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 staging-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 d837a996f57c29a985177bc03b0e599082047f27 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:36 +0100 Subject: iio:light:st_uvis25: Fix timestamp alignment and prevent data leak. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() This data is allocated with kzalloc() so no data can leak apart from previous readings. A local unsigned int variable is used for the regmap call so it is clear there is no potential issue with writing into the padding of the structure. Fixes: 3025c8688c1e ("iio: light: add support for UVIS25 sensor") Reported-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Acked-by: Lorenzo Bianconi <lorenzo(a)kernel.org> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org --- drivers/iio/light/st_uvis25.h | 5 +++++ drivers/iio/light/st_uvis25_core.c | 8 +++++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/iio/light/st_uvis25.h b/drivers/iio/light/st_uvis25.h index 78bc56aad129..283086887caf 100644 --- a/drivers/iio/light/st_uvis25.h +++ b/drivers/iio/light/st_uvis25.h @@ -27,6 +27,11 @@ struct st_uvis25_hw { struct iio_trigger *trig; bool enabled; int irq; + /* Ensure timestamp is naturally aligned */ + struct { + u8 chan; + s64 ts __aligned(8); + } scan; }; extern const struct dev_pm_ops st_uvis25_pm_ops; diff --git a/drivers/iio/light/st_uvis25_core.c b/drivers/iio/light/st_uvis25_core.c index a18a82e6bbf5..1055594b2276 100644 --- a/drivers/iio/light/st_uvis25_core.c +++ b/drivers/iio/light/st_uvis25_core.c @@ -232,17 +232,19 @@ static const struct iio_buffer_setup_ops st_uvis25_buffer_ops = { static irqreturn_t st_uvis25_buffer_handler_thread(int irq, void *p) { - u8 buffer[ALIGN(sizeof(u8), sizeof(s64)) + sizeof(s64)]; struct iio_poll_func *pf = p; struct iio_dev *iio_dev = pf->indio_dev; struct st_uvis25_hw *hw = iio_priv(iio_dev); + unsigned int val; int err; - err = regmap_read(hw->regmap, ST_UVIS25_REG_OUT_ADDR, (int *)buffer); + err = regmap_read(hw->regmap, ST_UVIS25_REG_OUT_ADDR, &val); if (err < 0) goto out; - iio_push_to_buffers_with_timestamp(iio_dev, buffer, + hw->scan.chan = val; + + iio_push_to_buffers_with_timestamp(iio_dev, &hw->scan, iio_get_time_ns(iio_dev)); out: -- 2.29.2

3 years, 7 months

1
0
0 0

patch "iio:light:rpr0521: Fix timestamp alignment and prevent data leak." added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:light:rpr0521: Fix timestamp alignment and prevent data leak. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 staging-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 a61817216bcc755eabbcb1cf281d84ccad267ed1 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 20 Sep 2020 12:27:35 +0100 Subject: iio:light:rpr0521: Fix timestamp alignment and prevent data leak. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv(). This data is allocated with kzalloc() so no data can leak apart from previous readings and in this case the status byte from the device. The forced alignment of ts is not necessary in this case but it potentially makes the code less fragile. >From personal communications with Mikko: We could probably split the reading of the int register, but it would mean a significant performance cost of 20 i2c clock cycles. Fixes: e12ffd241c00 ("iio: light: rpr0521 triggered buffer") Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: Mikko Koivunen <mikko.koivunen(a)fi.rohmeurope.com> Cc: <Stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org --- drivers/iio/light/rpr0521.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/iio/light/rpr0521.c b/drivers/iio/light/rpr0521.c index aa2972b04833..31224a33bade 100644 --- a/drivers/iio/light/rpr0521.c +++ b/drivers/iio/light/rpr0521.c @@ -194,6 +194,17 @@ struct rpr0521_data { bool pxs_need_dis; struct regmap *regmap; + + /* + * Ensure correct naturally aligned timestamp. + * Note that the read will put garbage data into + * the padding but this should not be a problem + */ + struct { + __le16 channels[3]; + u8 garbage; + s64 ts __aligned(8); + } scan; }; static IIO_CONST_ATTR(in_intensity_scale_available, RPR0521_ALS_SCALE_AVAIL); @@ -449,8 +460,6 @@ static irqreturn_t rpr0521_trigger_consumer_handler(int irq, void *p) struct rpr0521_data *data = iio_priv(indio_dev); int err; - u8 buffer[16]; /* 3 16-bit channels + padding + ts */ - /* Use irq timestamp when reasonable. */ if (iio_trigger_using_own(indio_dev) && data->irq_timestamp) { pf->timestamp = data->irq_timestamp; @@ -461,11 +470,11 @@ static irqreturn_t rpr0521_trigger_consumer_handler(int irq, void *p) pf->timestamp = iio_get_time_ns(indio_dev); err = regmap_bulk_read(data->regmap, RPR0521_REG_PXS_DATA, - &buffer, + data->scan.channels, (3 * 2) + 1); /* 3 * 16-bit + (discarded) int clear reg. */ if (!err) iio_push_to_buffers_with_timestamp(indio_dev, - buffer, pf->timestamp); + &data->scan, pf->timestamp); else dev_err(&data->client->dev, "Trigger consumer can't read from sensor.\n"); -- 2.29.2

3 years, 7 months

1
0
0 0

patch "iio: buffer: Fix demux update" added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: buffer: Fix demux update to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 staging-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 19ef7b70ca9487773c29b449adf0c70f540a0aab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nuno=20S=C3=A1?= <nuno.sa(a)analog.com> Date: Thu, 12 Nov 2020 15:43:22 +0100 Subject: iio: buffer: Fix demux update MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When updating the buffer demux, we will skip a scan element from the device in the case `in_ind != out_ind` and we enter the while loop. in_ind should only be refreshed with `find_next_bit()` in the end of the loop. Note, to cause problems we need a situation where we are skippig over an element (channel not enabled) that happens to not have the same size as the next element. Whilst this is a possible situation we haven't actually identified any cases in mainline where it happens as most drivers have consistent channel storage sizes with the exception of the timestamp which is the last element and hence never skipped over. Fixes: 5ada4ea9be16 ("staging:iio: add demux optionally to path from device to buffer") Signed-off-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20201112144323.28887-1-nuno.sa@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/industrialio-buffer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c index 9663dec3dcf3..2f7426a2f47c 100644 --- a/drivers/iio/industrialio-buffer.c +++ b/drivers/iio/industrialio-buffer.c @@ -853,12 +853,12 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev, indio_dev->masklength, in_ind + 1); while (in_ind != out_ind) { - in_ind = find_next_bit(indio_dev->active_scan_mask, - indio_dev->masklength, - in_ind + 1); length = iio_storage_bytes_for_si(indio_dev, in_ind); /* Make sure we are aligned */ in_loc = roundup(in_loc, length) + length; + in_ind = find_next_bit(indio_dev->active_scan_mask, + indio_dev->masklength, + in_ind + 1); } length = iio_storage_bytes_for_si(indio_dev, in_ind); out_loc = roundup(out_loc, length); -- 2.29.2

3 years, 7 months

1
0
0 0

patch "iio: ad_sigma_delta: Don't put SPI transfer buffer on the stack" added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: ad_sigma_delta: Don't put SPI transfer buffer on the stack to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-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 staging-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 0fb6ee8d0b5e90b72f870f76debc8bd31a742014 Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Tue, 24 Nov 2020 14:38:07 +0200 Subject: iio: ad_sigma_delta: Don't put SPI transfer buffer on the stack Use a heap allocated memory for the SPI transfer buffer. Using stack memory can corrupt stack memory when using DMA on some systems. This change moves the buffer from the stack of the trigger handler call to the heap of the buffer of the state struct. The size increases takes into account the alignment for the timestamp, which is 8 bytes. The 'data' buffer is split into 'tx_buf' and 'rx_buf', to make a clearer separation of which part of the buffer should be used for TX & RX. Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Link: https://lore.kernel.org/r/20201124123807.19717-1-alexandru.ardelean@analog.… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad_sigma_delta.c | 18 ++++++++---------- include/linux/iio/adc/ad_sigma_delta.h | 6 +++++- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c index 86039e9ecaca..3a6f239d4acc 100644 --- a/drivers/iio/adc/ad_sigma_delta.c +++ b/drivers/iio/adc/ad_sigma_delta.c @@ -57,7 +57,7 @@ EXPORT_SYMBOL_GPL(ad_sd_set_comm); int ad_sd_write_reg(struct ad_sigma_delta *sigma_delta, unsigned int reg, unsigned int size, unsigned int val) { - uint8_t *data = sigma_delta->data; + uint8_t *data = sigma_delta->tx_buf; struct spi_transfer t = { .tx_buf = data, .len = size + 1, @@ -99,7 +99,7 @@ EXPORT_SYMBOL_GPL(ad_sd_write_reg); static int ad_sd_read_reg_raw(struct ad_sigma_delta *sigma_delta, unsigned int reg, unsigned int size, uint8_t *val) { - uint8_t *data = sigma_delta->data; + uint8_t *data = sigma_delta->tx_buf; int ret; struct spi_transfer t[] = { { @@ -146,22 +146,22 @@ int ad_sd_read_reg(struct ad_sigma_delta *sigma_delta, { int ret; - ret = ad_sd_read_reg_raw(sigma_delta, reg, size, sigma_delta->data); + ret = ad_sd_read_reg_raw(sigma_delta, reg, size, sigma_delta->rx_buf); if (ret < 0) goto out; switch (size) { case 4: - *val = get_unaligned_be32(sigma_delta->data); + *val = get_unaligned_be32(sigma_delta->rx_buf); break; case 3: - *val = get_unaligned_be24(&sigma_delta->data[0]); + *val = get_unaligned_be24(sigma_delta->rx_buf); break; case 2: - *val = get_unaligned_be16(sigma_delta->data); + *val = get_unaligned_be16(sigma_delta->rx_buf); break; case 1: - *val = sigma_delta->data[0]; + *val = sigma_delta->rx_buf[0]; break; default: ret = -EINVAL; @@ -395,11 +395,9 @@ static irqreturn_t ad_sd_trigger_handler(int irq, void *p) struct iio_poll_func *pf = p; struct iio_dev *indio_dev = pf->indio_dev; struct ad_sigma_delta *sigma_delta = iio_device_get_drvdata(indio_dev); + uint8_t *data = sigma_delta->rx_buf; unsigned int reg_size; unsigned int data_reg; - uint8_t data[16]; - - memset(data, 0x00, 16); reg_size = indio_dev->channels[0].scan_type.realbits + indio_dev->channels[0].scan_type.shift; diff --git a/include/linux/iio/adc/ad_sigma_delta.h b/include/linux/iio/adc/ad_sigma_delta.h index a3a838dcf8e4..7199280d89ca 100644 --- a/include/linux/iio/adc/ad_sigma_delta.h +++ b/include/linux/iio/adc/ad_sigma_delta.h @@ -79,8 +79,12 @@ struct ad_sigma_delta { /* * DMA (thus cache coherency maintenance) requires the * transfer buffers to live in their own cache lines. + * 'tx_buf' is up to 32 bits. + * 'rx_buf' is up to 32 bits per sample + 64 bit timestamp, + * rounded to 16 bytes to take into account padding. */ - uint8_t data[4] ____cacheline_aligned; + uint8_t tx_buf[4] ____cacheline_aligned; + uint8_t rx_buf[16] __aligned(8); }; static inline int ad_sigma_delta_set_channel(struct ad_sigma_delta *sd, -- 2.29.2

3 years, 7 months

1
0
0 0

Re: [PATCH] scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()

by Thomas Lamprecht

> The be_fill_queue() function can only fail when "eq_vaddress" is NULL > and since it's non-NULL here that means the function call can't fail. > But imagine if it could, then in that situation we would want to store > the "paddr" so that dma memory can be released. > > Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3") > Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> This came in here through the stable 5.4 tree with v5.4.74, and we have some users of ours report that it results in kernel oopses and delayed boot on their HP DL 380 Gen 9 (and other Gen 9, FWICT) servers: > systemd-udevd D 0 501 1 0x80000000 > Call Trace: > __schedule+0x2e6/0x6f0 > schedule+0x33/0xa0 > schedule_timeout+0x205/0x330 > wait_for_completion+0xb7/0x140 > ? wake_up_q+0x80/0x80 > __flush_work+0x131/0x1e0 > ? worker_detach_from_pool+0xb0/0xb0 > work_on_cpu+0x6d/0x90 > ? workqueue_congested+0x80/0x80 > ? pci_device_shutdown+0x60/0x60 > pci_device_probe+0x190/0x1b0 > really_probe+0x1c8/0x3e0 > driver_probe_device+0xbb/0x100 > device_driver_attach+0x58/0x60 > __driver_attach+0x8f/0x150 > ? device_driver_attach+0x60/0x60 > bus_for_each_dev+0x79/0xc0 > ? kmem_cache_alloc_trace+0x1a0/0x230 > driver_attach+0x1e/0x20 > bus_add_driver+0x154/0x1f0 > ? 0xffffffffc0453000 > driver_register+0x70/0xc0 > ? 0xffffffffc0453000 > __pci_register_driver+0x57/0x60 > beiscsi_module_init+0x62/0x1000 [be2iscsi] > do_one_initcall+0x4a/0x1fa > ? _cond_resched+0x19/0x30 > ? kmem_cache_alloc_trace+0x1a0/0x230 > do_init_module+0x60/0x230 > load_module+0x231b/0x2590 > __do_sys_finit_module+0xbd/0x120 > ? __do_sys_finit_module+0xbd/0x120 > __x64_sys_finit_module+0x1a/0x20 > do_syscall_64+0x57/0x190 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7f00aca06f59 > Code: Bad RIP value. > RSP: 002b:00007ffc14380858 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 > RAX: ffffffffffffffda RBX: 0000558c726262e0 RCX: 00007f00aca06f59 > RDX: 0000000000000000 RSI: 00007f00ac90bcad RDI: 000000000000000e > RBP: 00007f00ac90bcad R08: 0000000000000000 R09: 0000000000000000 > R10: 000000000000000e R11: 0000000000000246 R12: 0000000000000000 > R13: 0000558c725f6030 R14: 0000000000020000 R15: 0000558c726262e0 Blacklisting the be2iscsi module or reverting this commit helps, I did not get around to look further into the mechanics at play and figured you would be faster at that, or that this info at least helps someone else when searching for the same symptoms. cheers, Thomas

3 years, 7 months

4
4
0 0

[PATCH] ARM: dts: at91: sama5d2: fix CAN message ram offset and size

by nicolas.ferre＠microchip.com

From: Nicolas Ferre <nicolas.ferre(a)microchip.com> CAN0 and CAN1 instances share the same message ram configured at 0x210000 on sama5d2 Linux systems. According to current configuration of CAN0, we need 0x1c00 bytes so that the CAN1 don't overlap its message ram: 64 x RX FIFO0 elements => 64 x 72 bytes 32 x TXE (TX Event FIFO) elements => 32 x 8 bytes 32 x TXB (TX Buffer) elements => 32 x 72 bytes So a total of 7168 bytes (0x1C00). Fix offset to match this needed size. Make the CAN0 message ram ioremap match exactly this size so that is easily understandable. Adapt CAN1 size accordingly. Reported-by: Dan Sneddon <dan.sneddon(a)microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> Tested-by: Cristian Birsan <cristian.birsan(a)microchip.com> Fixes: bc6d5d7666b7 ("ARM: dts: at91: sama5d2: add m_can nodes") Cc: stable(a)vger.kernel.org # v4.13+ --- arch/arm/boot/dts/sama5d2.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi index 2ddc85dff8ce..8f3c40e5b7ca 100644 --- a/arch/arm/boot/dts/sama5d2.dtsi +++ b/arch/arm/boot/dts/sama5d2.dtsi @@ -724,7 +724,7 @@ AT91_XDMAC_DT_PERID(31))>, can0: can@f8054000 { compatible = "bosch,m_can"; - reg = <0xf8054000 0x4000>, <0x210000 0x4000>; + reg = <0xf8054000 0x4000>, <0x210000 0x1c00>; reg-names = "m_can", "message_ram"; interrupts = <56 IRQ_TYPE_LEVEL_HIGH 7>, <64 IRQ_TYPE_LEVEL_HIGH 7>; @@ -1130,7 +1130,7 @@ AT91_XDMAC_DT_PERID(33))>, can1: can@fc050000 { compatible = "bosch,m_can"; - reg = <0xfc050000 0x4000>, <0x210000 0x4000>; + reg = <0xfc050000 0x4000>, <0x210000 0x3800>; reg-names = "m_can", "message_ram"; interrupts = <57 IRQ_TYPE_LEVEL_HIGH 7>, <65 IRQ_TYPE_LEVEL_HIGH 7>; @@ -1140,7 +1140,7 @@ can1: can@fc050000 { assigned-clocks = <&pmc PMC_TYPE_GCK 57>; assigned-clock-parents = <&pmc PMC_TYPE_CORE PMC_UTMI>; assigned-clock-rates = <40000000>; - bosch,mram-cfg = <0x1100 0 0 64 0 0 32 32>; + bosch,mram-cfg = <0x1c00 0 0 64 0 0 32 32>; status = "disabled"; }; -- 2.29.2

3 years, 7 months

2
1
0 0

[PATCH v7 1/7] mtd: spi-nor: sst: fix BPn bits for the SST25VF064C

by Michael Walle

This flash part actually has 4 block protection bits. Reported-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Cc: stable(a)vger.kernel.org # v5.7+ Signed-off-by: Michael Walle <michael(a)walle.cc> --- I didn't add the Fixes: tag because we depend on the 4bit BP support which was introduced in 5.7. changes since v6: - new patch drivers/mtd/spi-nor/sst.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c index e0af6d25d573..0ab07624fb73 100644 --- a/drivers/mtd/spi-nor/sst.c +++ b/drivers/mtd/spi-nor/sst.c @@ -18,7 +18,8 @@ static const struct flash_info sst_parts[] = { SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) }, - { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) }, + { "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, + SECT_4K | SPI_NOR_4BIT_BP) }, { "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1, SECT_4K | SST_WRITE) }, { "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2, -- 2.20.1

3 years, 7 months

3
6
0 0

[PATCH] PCI: cadence: Fix cdns_pcie_host_setup() error path

by Mian Yousaf Kaukab

commit 19abcd790b51 ("PCI: cadence: Fix cdns_pcie_{host|ep}_setup() error path") removed pm_runtime_put_sync() call from the error path in cdns_pcie_{host|ep}_setup(). However, the hunk in cdns_pcie_host_setup() got lost. Fix error path in cdns_pcie_host_setup() by removing pm_runtime_put_sync() call. Fixes: 24344226f66b ("PCI: cadence: Use struct pci_host_bridge.windows list directly") Cc: stable(a)vger.kernel.org Signed-off-by: Mian Yousaf Kaukab <ykaukab(a)suse.de> --- drivers/pci/controller/cadence/pcie-cadence-host.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c index 811c1cb2e8de..6e2557653943 100644 --- a/drivers/pci/controller/cadence/pcie-cadence-host.c +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c @@ -471,14 +471,5 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc) if (!bridge->ops) bridge->ops = &cdns_pcie_host_ops; - ret = pci_host_probe(bridge); - if (ret < 0) - goto err_init; - - return 0; - - err_init: - pm_runtime_put_sync(dev); - - return ret; + return pci_host_probe(bridge); } -- 2.26.2

3 years, 7 months

1
0
0 0

[PATCH AUTOSEL 4.4 1/3] ARC: stack unwinding: don't assume non-current task is sleeping

by Sasha Levin

From: Vineet Gupta <vgupta(a)synopsys.com> [ Upstream commit e42404fa10fd11fe72d0a0e149a321d10e577715 ] To start stack unwinding (SP, PC and BLINK) are needed. When the explicit execution context (pt_regs etc) is not available, unwinder assumes the task is sleeping (in __switch_to()) and fetches SP and BLINK from kernel mode stack. But this assumption is not true, specially in a SMP system, when top runs on 1 core, there may be active running processes on all cores. So when unwinding non courrent tasks, ensure they are NOT running. And while at it, handle the self unwinding case explicitly. This came out of investigation of a customer reported hang with rcutorture+top Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/31 Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arc/kernel/stacktrace.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c index 5401e2bab3da2..054511f571dfd 100644 --- a/arch/arc/kernel/stacktrace.c +++ b/arch/arc/kernel/stacktrace.c @@ -39,15 +39,15 @@ #ifdef CONFIG_ARC_DW2_UNWIND -static void seed_unwind_frame_info(struct task_struct *tsk, - struct pt_regs *regs, - struct unwind_frame_info *frame_info) +static int +seed_unwind_frame_info(struct task_struct *tsk, struct pt_regs *regs, + struct unwind_frame_info *frame_info) { /* * synchronous unwinding (e.g. dump_stack) * - uses current values of SP and friends */ - if (tsk == NULL && regs == NULL) { + if (regs == NULL && (tsk == NULL || tsk == current)) { unsigned long fp, sp, blink, ret; frame_info->task = current; @@ -66,11 +66,15 @@ static void seed_unwind_frame_info(struct task_struct *tsk, frame_info->call_frame = 0; } else if (regs == NULL) { /* - * Asynchronous unwinding of sleeping task - * - Gets SP etc from task's pt_regs (saved bottom of kernel - * mode stack of task) + * Asynchronous unwinding of a likely sleeping task + * - first ensure it is actually sleeping + * - if so, it will be in __switch_to, kernel mode SP of task + * is safe-kept and BLINK at a well known location in there */ + if (tsk->state == TASK_RUNNING) + return -1; + frame_info->task = tsk; frame_info->regs.r27 = TSK_K_FP(tsk); @@ -104,6 +108,8 @@ static void seed_unwind_frame_info(struct task_struct *tsk, frame_info->regs.r63 = regs->ret; frame_info->call_frame = 0; } + + return 0; } #endif @@ -117,7 +123,8 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs, unsigned int address; struct unwind_frame_info frame_info; - seed_unwind_frame_info(tsk, regs, &frame_info); + if (seed_unwind_frame_info(tsk, regs, &frame_info)) + return 0; while (1) { address = UNW_PC(&frame_info); -- 2.27.0

3 years, 7 months

1
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2020