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/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
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
cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages
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:
cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.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: Arjun Vynipadath <arjun(a)chelsio.com>
Date: Wed, 10 Jan 2018 12:02:13 +0530
Subject: cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages
From: Arjun Vynipadath <arjun(a)chelsio.com>
[ Upstream commit ea0a42109aee7b92e631c4eb3f2219fadf58acdd ]
We'd come in with SGE_FL_BUFFER_SIZE[0] and [1] both equal to 64KB and
the extant logic would flag that as an error. This was already fixed in
cxgb4 driver with "92ddcc7 cxgb4: Fix some small bugs in
t4_sge_init_soft() when our Page Size is 64KB".
Original Work by: Casey Leedom <leedom(a)chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun(a)chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr(a)chelsio.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -2619,8 +2619,8 @@ void t4vf_sge_stop(struct adapter *adapt
int t4vf_sge_init(struct adapter *adapter)
{
struct sge_params *sge_params = &adapter->params.sge;
- u32 fl0 = sge_params->sge_fl_buffer_size[0];
- u32 fl1 = sge_params->sge_fl_buffer_size[1];
+ u32 fl_small_pg = sge_params->sge_fl_buffer_size[0];
+ u32 fl_large_pg = sge_params->sge_fl_buffer_size[1];
struct sge *s = &adapter->sge;
/*
@@ -2628,9 +2628,20 @@ int t4vf_sge_init(struct adapter *adapte
* the Physical Function Driver. Ideally we should be able to deal
* with _any_ configuration. Practice is different ...
*/
- if (fl0 != PAGE_SIZE || (fl1 != 0 && fl1 <= fl0)) {
+
+ /* We only bother using the Large Page logic if the Large Page Buffer
+ * is larger than our Page Size Buffer.
+ */
+ if (fl_large_pg <= fl_small_pg)
+ fl_large_pg = 0;
+
+ /* The Page Size Buffer must be exactly equal to our Page Size and the
+ * Large Page Size Buffer should be 0 (per above) or a power of 2.
+ */
+ if (fl_small_pg != PAGE_SIZE ||
+ (fl_large_pg & (fl_large_pg - 1)) != 0) {
dev_err(adapter->pdev_dev, "bad SGE FL buffer sizes [%d, %d]\n",
- fl0, fl1);
+ fl_small_pg, fl_large_pg);
return -EINVAL;
}
if ((sge_params->sge_control & RXPKTCPLMODE_F) !=
@@ -2642,8 +2653,8 @@ int t4vf_sge_init(struct adapter *adapte
/*
* Now translate the adapter parameters into our internal forms.
*/
- if (fl1)
- s->fl_pg_order = ilog2(fl1) - PAGE_SHIFT;
+ if (fl_large_pg)
+ s->fl_pg_order = ilog2(fl_large_pg) - PAGE_SHIFT;
s->stat_len = ((sge_params->sge_control & EGRSTATUSPAGESIZE_F)
? 128 : 64);
s->pktshift = PKTSHIFT_G(sge_params->sge_control);
Patches currently in stable-queue which might be from arjun(a)chelsio.com are
queue-4.15/cxgb4vf-fix-sge-fl-buffer-initialization-logic-for-64k-pages.patch