This is a note to let you know that I've just added the patch titled
i40iw: Fix sequence number for the first partial FPDU
to the 4.15-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:
i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Shiraz Saleem <shiraz.saleem(a)intel.com>
Date: Fri, 22 Dec 2017 09:46:59 -0600
Subject: i40iw: Fix sequence number for the first partial FPDU
From: Shiraz Saleem <shiraz.saleem(a)intel.com>
[ Upstream commit df8b13a1b23356d01dfc4647a5629cdb0f4ce566 ]
Partial FPDU processing is broken as the sequence number
for the first partial FPDU is wrong due to incorrect
Q2 buffer offset. The offset should be 64 rather than 16.
Fixes: 786c6adb3a94 ("i40iw: add puda code")
Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/i40iw/i40iw_d.h | 1 +
drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/hw/i40iw/i40iw_d.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_d.h
@@ -97,6 +97,7 @@
#define RDMA_OPCODE_MASK 0x0f
#define RDMA_READ_REQ_OPCODE 1
#define Q2_BAD_FRAME_OFFSET 72
+#define Q2_FPSN_OFFSET 64
#define CQE_MAJOR_DRV 0x8000
#define I40IW_TERM_SENT 0x01
--- a/drivers/infiniband/hw/i40iw/i40iw_puda.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c
@@ -1378,7 +1378,7 @@ static void i40iw_ieq_handle_exception(s
u32 *hw_host_ctx = (u32 *)qp->hw_host_ctx;
u32 rcv_wnd = hw_host_ctx[23];
/* first partial seq # in q2 */
- u32 fps = qp->q2_buf[16];
+ u32 fps = *(u32 *)(qp->q2_buf + Q2_FPSN_OFFSET);
struct list_head *rxlist = &pfpdu->rxlist;
struct list_head *plist;
Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are
queue-4.15/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch
queue-4.15/i40iw-correct-q1-xf-object-count-equation.patch
queue-4.15/i40iw-validate-correct-ird-ord-connection-parameters.patch
This is a note to let you know that I've just added the patch titled
i40iw: Correct Q1/XF object count equation
to the 4.15-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:
i40iw-correct-q1-xf-object-count-equation.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Shiraz Saleem <shiraz.saleem(a)intel.com>
Date: Fri, 22 Dec 2017 09:46:56 -0600
Subject: i40iw: Correct Q1/XF object count equation
From: Shiraz Saleem <shiraz.saleem(a)intel.com>
[ Upstream commit fe99afd1febd74e0ef1fed7e3283f09effe1f4f0 ]
Lower Inbound RDMA Read Queue (Q1) object count by a factor of 2
as it is incorrectly doubled. Also, round up Q1 and Transmit FIFO (XF)
object count to power of 2 to satisfy hardware requirement.
Fixes: 86dbcd0f12e9 ("i40iw: add file to handle cqp calls")
Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
@@ -3928,8 +3928,10 @@ enum i40iw_status_code i40iw_config_fpm_
hmc_info->hmc_obj[I40IW_HMC_IW_APBVT_ENTRY].cnt = 1;
hmc_info->hmc_obj[I40IW_HMC_IW_MR].cnt = mrwanted;
- hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt = I40IW_MAX_WQ_ENTRIES * qpwanted;
- hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt = 4 * I40IW_MAX_IRD_SIZE * qpwanted;
+ hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt =
+ roundup_pow_of_two(I40IW_MAX_WQ_ENTRIES * qpwanted);
+ hmc_info->hmc_obj[I40IW_HMC_IW_Q1].cnt =
+ roundup_pow_of_two(2 * I40IW_MAX_IRD_SIZE * qpwanted);
hmc_info->hmc_obj[I40IW_HMC_IW_XFFL].cnt =
hmc_info->hmc_obj[I40IW_HMC_IW_XF].cnt / hmc_fpm_misc->xf_block_size;
hmc_info->hmc_obj[I40IW_HMC_IW_Q1FL].cnt =
Patches currently in stable-queue which might be from shiraz.saleem(a)intel.com are
queue-4.15/i40iw-fix-sequence-number-for-the-first-partial-fpdu.patch
queue-4.15/i40iw-correct-q1-xf-object-count-equation.patch
queue-4.15/i40iw-validate-correct-ird-ord-connection-parameters.patch
This is a note to let you know that I've just added the patch titled
hwmon: (ina2xx) Make calibration register value fixed
to the 4.15-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:
hwmon-ina2xx-make-calibration-register-value-fixed.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Maciej Purski <m.purski(a)samsung.com>
Date: Wed, 22 Nov 2017 16:32:15 +0100
Subject: hwmon: (ina2xx) Make calibration register value fixed
From: Maciej Purski <m.purski(a)samsung.com>
[ Upstream commit 5d389b125186cf254ad5b8015763ac07c151aea4 ]
Calibration register is used for calculating current register in
hardware according to datasheet:
current = shunt_volt * calib_register / 2048 (ina 226)
current = shunt_volt * calib_register / 4096 (ina 219)
Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in
order to avoid truncation error and provide best precision allowed
by shunt_voltage measurement. Make current scale value follow changes
of shunt_resistor from sysfs as calib_register value is now fixed.
Power_lsb value should also follow shunt_resistor changes as stated in
datasheet:
power_lsb = 25 * current_lsb (ina 226)
power_lsb = 20 * current_lsb (ina 219)
Signed-off-by: Maciej Purski <m.purski(a)samsung.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/ina2xx.c | 87 ++++++++++++++++++++++++++++---------------------
1 file changed, 50 insertions(+), 37 deletions(-)
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -95,18 +95,20 @@ enum ina2xx_ids { ina219, ina226 };
struct ina2xx_config {
u16 config_default;
- int calibration_factor;
+ int calibration_value;
int registers;
int shunt_div;
int bus_voltage_shift;
int bus_voltage_lsb; /* uV */
- int power_lsb; /* uW */
+ int power_lsb_factor;
};
struct ina2xx_data {
const struct ina2xx_config *config;
long rshunt;
+ long current_lsb_uA;
+ long power_lsb_uW;
struct mutex config_lock;
struct regmap *regmap;
@@ -116,21 +118,21 @@ struct ina2xx_data {
static const struct ina2xx_config ina2xx_config[] = {
[ina219] = {
.config_default = INA219_CONFIG_DEFAULT,
- .calibration_factor = 40960000,
+ .calibration_value = 4096,
.registers = INA219_REGISTERS,
.shunt_div = 100,
.bus_voltage_shift = 3,
.bus_voltage_lsb = 4000,
- .power_lsb = 20000,
+ .power_lsb_factor = 20,
},
[ina226] = {
.config_default = INA226_CONFIG_DEFAULT,
- .calibration_factor = 5120000,
+ .calibration_value = 2048,
.registers = INA226_REGISTERS,
.shunt_div = 400,
.bus_voltage_shift = 0,
.bus_voltage_lsb = 1250,
- .power_lsb = 25000,
+ .power_lsb_factor = 25,
},
};
@@ -169,12 +171,16 @@ static u16 ina226_interval_to_reg(int in
return INA226_SHIFT_AVG(avg_bits);
}
+/*
+ * Calibration register is set to the best value, which eliminates
+ * truncation errors on calculating current register in hardware.
+ * According to datasheet (eq. 3) the best values are 2048 for
+ * ina226 and 4096 for ina219. They are hardcoded as calibration_value.
+ */
static int ina2xx_calibrate(struct ina2xx_data *data)
{
- u16 val = DIV_ROUND_CLOSEST(data->config->calibration_factor,
- data->rshunt);
-
- return regmap_write(data->regmap, INA2XX_CALIBRATION, val);
+ return regmap_write(data->regmap, INA2XX_CALIBRATION,
+ data->config->calibration_value);
}
/*
@@ -187,10 +193,6 @@ static int ina2xx_init(struct ina2xx_dat
if (ret < 0)
return ret;
- /*
- * Set current LSB to 1mA, shunt is in uOhms
- * (equation 13 in datasheet).
- */
return ina2xx_calibrate(data);
}
@@ -268,15 +270,15 @@ static int ina2xx_get_value(struct ina2x
val = DIV_ROUND_CLOSEST(val, 1000);
break;
case INA2XX_POWER:
- val = regval * data->config->power_lsb;
+ val = regval * data->power_lsb_uW;
break;
case INA2XX_CURRENT:
- /* signed register, LSB=1mA (selected), in mA */
- val = (s16)regval;
+ /* signed register, result in mA */
+ val = regval * data->current_lsb_uA;
+ val = DIV_ROUND_CLOSEST(val, 1000);
break;
case INA2XX_CALIBRATION:
- val = DIV_ROUND_CLOSEST(data->config->calibration_factor,
- regval);
+ val = regval;
break;
default:
/* programmer goofed */
@@ -304,9 +306,32 @@ static ssize_t ina2xx_show_value(struct
ina2xx_get_value(data, attr->index, regval));
}
-static ssize_t ina2xx_set_shunt(struct device *dev,
- struct device_attribute *da,
- const char *buf, size_t count)
+/*
+ * In order to keep calibration register value fixed, the product
+ * of current_lsb and shunt_resistor should also be fixed and equal
+ * to shunt_voltage_lsb = 1 / shunt_div multiplied by 10^9 in order
+ * to keep the scale.
+ */
+static int ina2xx_set_shunt(struct ina2xx_data *data, long val)
+{
+ unsigned int dividend = DIV_ROUND_CLOSEST(1000000000,
+ data->config->shunt_div);
+ if (val <= 0 || val > dividend)
+ return -EINVAL;
+
+ mutex_lock(&data->config_lock);
+ data->rshunt = val;
+ data->current_lsb_uA = DIV_ROUND_CLOSEST(dividend, val);
+ data->power_lsb_uW = data->config->power_lsb_factor *
+ data->current_lsb_uA;
+ mutex_unlock(&data->config_lock);
+
+ return 0;
+}
+
+static ssize_t ina2xx_store_shunt(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
{
unsigned long val;
int status;
@@ -316,18 +341,9 @@ static ssize_t ina2xx_set_shunt(struct d
if (status < 0)
return status;
- if (val == 0 ||
- /* Values greater than the calibration factor make no sense. */
- val > data->config->calibration_factor)
- return -EINVAL;
-
- mutex_lock(&data->config_lock);
- data->rshunt = val;
- status = ina2xx_calibrate(data);
- mutex_unlock(&data->config_lock);
+ status = ina2xx_set_shunt(data, val);
if (status < 0)
return status;
-
return count;
}
@@ -387,7 +403,7 @@ static SENSOR_DEVICE_ATTR(power1_input,
/* shunt resistance */
static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR,
- ina2xx_show_value, ina2xx_set_shunt,
+ ina2xx_show_value, ina2xx_store_shunt,
INA2XX_CALIBRATION);
/* update interval (ina226 only) */
@@ -448,10 +464,7 @@ static int ina2xx_probe(struct i2c_clien
val = INA2XX_RSHUNT_DEFAULT;
}
- if (val <= 0 || val > data->config->calibration_factor)
- return -ENODEV;
-
- data->rshunt = val;
+ ina2xx_set_shunt(data, val);
ina2xx_regmap_config.max_register = data->config->registers;
Patches currently in stable-queue which might be from m.purski(a)samsung.com are
queue-4.15/hwmon-ina2xx-make-calibration-register-value-fixed.patch
This is a note to let you know that I've just added the patch titled
gpio: thunderx: fix error return code in thunderx_gpio_probe()
to the 4.15-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:
gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Wed, 10 Jan 2018 14:37:13 +0000
Subject: gpio: thunderx: fix error return code in thunderx_gpio_probe()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
[ Upstream commit 76e28f5ffed82b1e81a86c4eb8d0420515765620 ]
Fix to return error code -ENOMEM from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 5a2a30024d8c ("gpio: Add gpio driver support for ThunderX and OCTEON-TX")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Acked-by: David Daney <david.daney(a)cavium.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-thunderx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -553,8 +553,10 @@ static int thunderx_gpio_probe(struct pc
txgpio->irqd = irq_domain_create_hierarchy(irq_get_irq_data(txgpio->msix_entries[0].vector)->domain,
0, 0, of_node_to_fwnode(dev->of_node),
&thunderx_gpio_irqd_ops, txgpio);
- if (!txgpio->irqd)
+ if (!txgpio->irqd) {
+ err = -ENOMEM;
goto out;
+ }
/* Push on irq_data and the domain for each line. */
for (i = 0; i < ngpio; i++) {
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.15/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch
queue-4.15/irqchip-ompic-fix-return-value-check-in-ompic_of_init.patch
This is a note to let you know that I've just added the patch titled
gpiolib: don't dereference a desc before validation
to the 4.15-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:
gpiolib-don-t-dereference-a-desc-before-validation.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Vladimir Zapolskiy <vz(a)mleia.com>
Date: Thu, 21 Dec 2017 18:37:24 +0200
Subject: gpiolib: don't dereference a desc before validation
From: Vladimir Zapolskiy <vz(a)mleia.com>
[ Upstream commit 30322bcf82d74cad0d6e1cf9ba7fa7fa48c7a026 ]
The fix restores a proper validation of an input gpio desc, which
might be needed to deal with optional GPIOs correctly.
Fixes: 02e479808b5d ("gpio: Alter semantics of *raw* operations to actually be raw")
Signed-off-by: Vladimir Zapolskiy <vz(a)mleia.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2468,7 +2468,7 @@ EXPORT_SYMBOL_GPL(gpiod_direction_output
*/
int gpiod_direction_output(struct gpio_desc *desc, int value)
{
- struct gpio_chip *gc = desc->gdev->chip;
+ struct gpio_chip *gc;
int ret;
VALIDATE_DESC(desc);
@@ -2485,6 +2485,7 @@ int gpiod_direction_output(struct gpio_d
return -EIO;
}
+ gc = desc->gdev->chip;
if (test_bit(FLAG_OPEN_DRAIN, &desc->flags)) {
/* First see if we can enable open drain in hardware */
ret = gpio_set_drive_single_ended(gc, gpio_chip_hwgpio(desc),
Patches currently in stable-queue which might be from vz(a)mleia.com are
queue-4.15/gpiolib-don-t-dereference-a-desc-before-validation.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem
to the 4.15-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:
f2fs-fix-lock-dependency-in-between-dio_rwsem-i_mmap_sem.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Chao Yu <yuchao0(a)huawei.com>
Date: Thu, 23 Nov 2017 23:26:52 +0800
Subject: f2fs: fix lock dependency in between dio_rwsem & i_mmap_sem
From: Chao Yu <yuchao0(a)huawei.com>
[ Upstream commit 21020812c9e1ab593367fad9ce579f842a0b406d ]
test/generic/208 reports a potential deadlock as below:
Chain exists of:
&mm->mmap_sem --> &fi->i_mmap_sem --> &fi->dio_rwsem[WRITE]
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fi->dio_rwsem[WRITE]);
lock(&fi->i_mmap_sem);
lock(&fi->dio_rwsem[WRITE]);
lock(&mm->mmap_sem);
This patch changes the lock dependency as below in fallocate() to
fix this issue:
- dio_rwsem
- i_mmap_sem
Fixes: bb06664a534b ("f2fs: avoid race in between GC and block exchange")
Signed-off-by: Chao Yu <yuchao0(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/file.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1186,14 +1186,14 @@ static int f2fs_collapse_range(struct in
pg_start = offset >> PAGE_SHIFT;
pg_end = (offset + len) >> PAGE_SHIFT;
+ /* avoid gc operation during block exchange */
+ down_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
+
down_write(&F2FS_I(inode)->i_mmap_sem);
/* write out all dirty pages from offset */
ret = filemap_write_and_wait_range(inode->i_mapping, offset, LLONG_MAX);
if (ret)
- goto out;
-
- /* avoid gc operation during block exchange */
- down_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
+ goto out_unlock;
truncate_pagecache(inode, offset);
@@ -1212,9 +1212,8 @@ static int f2fs_collapse_range(struct in
if (!ret)
f2fs_i_size_write(inode, new_size);
out_unlock:
- up_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
-out:
up_write(&F2FS_I(inode)->i_mmap_sem);
+ up_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
return ret;
}
@@ -1385,6 +1384,9 @@ static int f2fs_insert_range(struct inod
f2fs_balance_fs(sbi, true);
+ /* avoid gc operation during block exchange */
+ down_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
+
down_write(&F2FS_I(inode)->i_mmap_sem);
ret = truncate_blocks(inode, i_size_read(inode), true);
if (ret)
@@ -1395,9 +1397,6 @@ static int f2fs_insert_range(struct inod
if (ret)
goto out;
- /* avoid gc operation during block exchange */
- down_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
-
truncate_pagecache(inode, offset);
pg_start = offset >> PAGE_SHIFT;
@@ -1425,10 +1424,9 @@ static int f2fs_insert_range(struct inod
if (!ret)
f2fs_i_size_write(inode, new_size);
-
- up_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
out:
up_write(&F2FS_I(inode)->i_mmap_sem);
+ up_write(&F2FS_I(inode)->dio_rwsem[WRITE]);
return ret;
}
Patches currently in stable-queue which might be from yuchao0(a)huawei.com are
queue-4.15/f2fs-fix-lock-dependency-in-between-dio_rwsem-i_mmap_sem.patch
This is a note to let you know that I've just added the patch titled
gpio: label descriptors using the device name
to the 4.15-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:
gpio-label-descriptors-using-the-device-name.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Thu, 4 Jan 2018 22:31:11 +0100
Subject: gpio: label descriptors using the device name
From: Linus Walleij <linus.walleij(a)linaro.org>
[ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ]
Some GPIO lines appear named "?" in the lsgpio dump due to their
requesting drivers not passing a reasonable label.
Most typically this happens if a device tree node just defines
gpios = <...> and not foo-gpios = <...>, the former gets named
"foo" and the latter gets named "?".
However the struct device passed in is always valid so let's
just label the GPIO with dev_name() on the device if no proper
label was passed.
Cc: Reported-by: Jason Kridner <jkridner(a)beagleboard.org>
Reported-by: Jason Kridner <jkridner(a)beagleboard.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3647,7 +3647,8 @@ struct gpio_desc *__must_check gpiod_get
return desc;
}
- status = gpiod_request(desc, con_id);
+ /* If a connection label was passed use that, else use the device name as label */
+ status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
if (status < 0)
return ERR_PTR(status);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.15/gpio-label-descriptors-using-the-device-name.patch
queue-4.15/gpio-thunderx-fix-error-return-code-in-thunderx_gpio_probe.patch
queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch
queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch
queue-4.15/gpiolib-don-t-dereference-a-desc-before-validation.patch
This is a note to let you know that I've just added the patch titled
drm/msm: Fix NULL deref in adreno_load_gpu
to the 4.15-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:
drm-msm-fix-null-deref-in-adreno_load_gpu.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Archit Taneja <architt(a)codeaurora.org>
Date: Fri, 22 Dec 2017 15:41:13 +0530
Subject: drm/msm: Fix NULL deref in adreno_load_gpu
From: Archit Taneja <architt(a)codeaurora.org>
[ Upstream commit 9dcfbc182f1aac0aa5ea194733d21e67dd2ba1fd ]
The msm/kms driver should work even if there is no GPU device specified
in DT. Currently, we get a NULL dereference crash in adreno_load_gpu
since the driver assumes that priv->gpu_pdev is non-NULL.
Perform an additional check on priv->gpu_pdev before trying to retrieve
the msm_gpu pointer from it.
v2: Incorporate Jordan's comments:
- Simplify the check to share the same error message.
- Use dev_err_once() to avoid an error message every time we open the
drm device fd.
Fixes: eec874ce5ff1 (drm/msm/adreno: load gpu at probe/bind time)
Signed-off-by: Archit Taneja <architt(a)codeaurora.org>
Acked-by: Jordan Crouse <jcrouse(a)codeaurora.org>
Signed-off-by: Rob Clark <robdclark(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -125,11 +125,14 @@ struct msm_gpu *adreno_load_gpu(struct d
{
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
- struct msm_gpu *gpu = platform_get_drvdata(priv->gpu_pdev);
+ struct msm_gpu *gpu = NULL;
int ret;
+ if (pdev)
+ gpu = platform_get_drvdata(pdev);
+
if (!gpu) {
- dev_err(dev->dev, "no adreno device\n");
+ dev_err_once(dev->dev, "no GPU device was found\n");
return NULL;
}
Patches currently in stable-queue which might be from architt(a)codeaurora.org are
queue-4.15/drm-msm-fix-null-deref-in-adreno_load_gpu.patch
This is a note to let you know that I've just added the patch titled
drm/amd/powerplay: fix memory leakage when reload (v2)
to the 4.15-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:
drm-amd-powerplay-fix-memory-leakage-when-reload-v2.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Yintian Tao <yttao(a)amd.com>
Date: Thu, 4 Jan 2018 11:45:23 +0800
Subject: drm/amd/powerplay: fix memory leakage when reload (v2)
From: Yintian Tao <yttao(a)amd.com>
[ Upstream commit a25513e7b9b15c318ec44113682e988829aef746 ]
add smu_free_memory when smu fini to prevent memory leakage
v2: squash in typo fix (Yintian) and warning (Harry)
Signed-off-by: Yintian Tao <yttao(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -648,6 +648,12 @@ int smu7_init(struct pp_hwmgr *hwmgr)
int smu7_smu_fini(struct pp_hwmgr *hwmgr)
{
+ struct smu7_smumgr *smu_data = (struct smu7_smumgr *)(hwmgr->smu_backend);
+
+ smu_free_memory(hwmgr->device, (void *) smu_data->header_buffer.handle);
+ if (!cgs_is_virtualization_enabled(hwmgr->device))
+ smu_free_memory(hwmgr->device, (void *) smu_data->smu_buffer.handle);
+
kfree(hwmgr->smu_backend);
hwmgr->smu_backend = NULL;
cgs_rel_firmware(hwmgr->device, CGS_UCODE_ID_SMU);
Patches currently in stable-queue which might be from yttao(a)amd.com are
queue-4.15/drm-amd-powerplay-fix-memory-leakage-when-reload-v2.patch
This is a note to let you know that I've just added the patch titled
EDAC, mv64x60: Fix an error handling path
to the 4.15-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:
edac-mv64x60-fix-an-error-handling-path.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 10:16:32 CEST 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 7 Jan 2018 21:54:00 +0100
Subject: EDAC, mv64x60: Fix an error handling path
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 68fa24f9121c04ef146b5158f538c8b32f285be5 ]
We should not call edac_mc_del_mc() if a corresponding call to
edac_mc_add_mc() has not been performed yet.
So here, we should go to err instead of err2 to branch at the right
place of the error handling path.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20180107205400.14068-1-christophe.jaillet@wanadoo.…
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/mv64x60_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -758,7 +758,7 @@ static int mv64x60_mc_err_probe(struct p
/* Non-ECC RAM? */
printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__);
res = -ENODEV;
- goto err2;
+ goto err;
}
edac_dbg(3, "init mci\n");
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.15/edac-mv64x60-fix-an-error-handling-path.patch
queue-4.15/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch