* Re: [PATCH v4 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens
From: Andy Shevchenko @ 2017-10-05 8:49 UTC (permalink / raw)
To: Mario Limonciello
Cc: dvhart@infradead.org, LKML, Platform Driver, Andy Lutomirski,
quasisec, Pali Rohár, Rafael J. Wysocki, mjg59,
Christoph Hellwig, Greg KH
In-Reply-To: <0af6d03ee32bd5c1529a38de008aa94c03331d7e.1507156392.git.mario.limonciello@dell.com>
On Thu, Oct 5, 2017 at 1:48 AM, Mario Limonciello
<mario.limonciello@dell.com> wrote:
> Currently userspace tools can access system tokens via the dcdbas
> kernel module and a SMI call that will cause the platform to execute
> SMM code.
>
> With a goal in mind of deprecating the dcdbas kernel module a different
> method for accessing these tokens from userspace needs to be created.
>
> This is intentionally marked to only be readable as root as it can
> contain sensitive information about the platform's configuration.
>
> MAINTAINERS was missing for this driver. Add myself and Pali to
> maintainers list for it.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
To be clear I just suggested the output format in ->show() callback.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Patch "drm/amdkfd: fix improper return value on error" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: bianpan2016, alexander.levin, gregkh, oded.gabbay; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/amdkfd: fix improper return value on error
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=summary
The filename of the patch is:
drm-amdkfd-fix-improper-return-value-on-error.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Pan Bian <bianpan2016@163.com>
Date: Thu, 1 Dec 2016 16:10:42 +0800
Subject: drm/amdkfd: fix improper return value on error
From: Pan Bian <bianpan2016@163.com>
[ Upstream commit 8bf793883da213864efc50c274d2b38ec0ca58b2 ]
In function kfd_wait_on_events(), when the call to copy_from_user()
fails, the value of return variable ret is 0. 0 indicates success, which
is inconsistent with the execution status. This patch fixes the bug by
assigning "-EFAULT" to ret when copy_from_user() returns an unexpected
value.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
@@ -739,8 +739,10 @@ int kfd_wait_on_events(struct kfd_proces
struct kfd_event_data event_data;
if (copy_from_user(&event_data, &events[i],
- sizeof(struct kfd_event_data)))
+ sizeof(struct kfd_event_data))) {
+ ret = -EFAULT;
goto fail;
+ }
ret = init_event_waiter(p, &event_waiters[i],
event_data.event_id, i);
Patches currently in stable-queue which might be from bianpan2016@163.com are
queue-4.4/team-fix-memory-leaks.patch
queue-4.4/drm-amdkfd-fix-improper-return-value-on-error.patch
^ permalink raw reply
* Patch "[media] exynos-gsc: Do not swap cb/cr for semi planar formats" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: thibault.saunier, alexander.levin, gregkh, javier, mchehab,
nicolas.dufresne, s.nawrocki
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] exynos-gsc: Do not swap cb/cr for semi planar formats
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=summary
The filename of the patch is:
exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
Date: Wed, 1 Feb 2017 18:05:21 -0200
Subject: [media] exynos-gsc: Do not swap cb/cr for semi planar formats
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
[ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ]
In the case of semi planar formats cb and cr are in the same plane
in memory, meaning that will be set to 'cb' whatever the format is,
and whatever the (packed) order of those components are.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -849,9 +849,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx
if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M))
swap(addr->cb, addr->cr);
Patches currently in stable-queue which might be from thibault.saunier@osg.samsung.com are
queue-4.4/exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.patch
^ permalink raw reply
* Patch "extcon: axp288: Use vbus-valid instead of -present to determine cable presence" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: hdegoede, alexander.levin, cw00.choi, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
extcon: axp288: Use vbus-valid instead of -present to determine cable presence
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=summary
The filename of the patch is:
extcon-axp288-use-vbus-valid-instead-of-present-to-determine-cable-presence.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Hans de Goede <hdegoede@redhat.com>
Date: Mon, 19 Dec 2016 01:13:11 +0100
Subject: extcon: axp288: Use vbus-valid instead of -present to determine cable presence
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 5757aca10146061befd168dab37fb0db1ccd8f73 ]
The vbus-present bit in the power status register also gets set to 1
when a usb-host cable (id-pin shorted to ground) is plugged in and a 5v
boost converter is supplying 5v to the otg usb bus.
This causes a "disconnect or unknown or ID event" warning in dmesg as
well as the extcon device to report the last detected charger cable
type as being connected even though none is connected.
This commit switches to checking the vbus-valid bit instead, which is
only 1 when both vbus is present and the vbus-path is enabled in the
vbus-path control register (the vbus-path gets disabled when a usb-host
cable is detected, to avoid the pmic drawing power from the 5v boost
converter).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/extcon/extcon-axp288.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -168,7 +168,7 @@ static int axp288_handle_chrg_det_event(
return ret;
}
- vbus_attach = (pwr_stat & PS_STAT_VBUS_PRESENT);
+ vbus_attach = (pwr_stat & PS_STAT_VBUS_VALID);
if (!vbus_attach)
goto notify_otg;
Patches currently in stable-queue which might be from hdegoede@redhat.com are
queue-4.4/iio-adc-axp288-drop-bogus-axp288_adc_ts_pin_ctrl-register-modifications.patch
queue-4.4/extcon-axp288-use-vbus-valid-instead-of-present-to-determine-cable-presence.patch
^ permalink raw reply
* Patch "hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: linux, alexander.levin, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
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=summary
The filename of the patch is:
hwmon-gl520sm-fix-overflows-and-crash-seen-when-writing-into-limit-attributes.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Guenter Roeck <linux@roeck-us.net>
Date: Tue, 27 Dec 2016 14:15:07 -0800
Subject: hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
From: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very large values are
written and the fan divider is larger than 1.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/gl520sm.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/drivers/hwmon/gl520sm.c
+++ b/drivers/hwmon/gl520sm.c
@@ -208,11 +208,13 @@ static ssize_t get_cpu_vid(struct device
}
static DEVICE_ATTR(cpu0_vid, S_IRUGO, get_cpu_vid, NULL);
-#define VDD_FROM_REG(val) (((val) * 95 + 2) / 4)
-#define VDD_TO_REG(val) clamp_val((((val) * 4 + 47) / 95), 0, 255)
-
-#define IN_FROM_REG(val) ((val) * 19)
-#define IN_TO_REG(val) clamp_val((((val) + 9) / 19), 0, 255)
+#define VDD_FROM_REG(val) DIV_ROUND_CLOSEST((val) * 95, 4)
+#define VDD_CLAMP(val) clamp_val(val, 0, 255 * 95 / 4)
+#define VDD_TO_REG(val) DIV_ROUND_CLOSEST(VDD_CLAMP(val) * 4, 95)
+
+#define IN_FROM_REG(val) ((val) * 19)
+#define IN_CLAMP(val) clamp_val(val, 0, 255 * 19)
+#define IN_TO_REG(val) DIV_ROUND_CLOSEST(IN_CLAMP(val), 19)
static ssize_t get_in_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -349,8 +351,13 @@ static SENSOR_DEVICE_ATTR(in4_max, S_IRU
#define DIV_FROM_REG(val) (1 << (val))
#define FAN_FROM_REG(val, div) ((val) == 0 ? 0 : (480000 / ((val) << (div))))
-#define FAN_TO_REG(val, div) ((val) <= 0 ? 0 : \
- clamp_val((480000 + ((val) << ((div)-1))) / ((val) << (div)), 1, 255))
+
+#define FAN_BASE(div) (480000 >> (div))
+#define FAN_CLAMP(val, div) clamp_val(val, FAN_BASE(div) / 255, \
+ FAN_BASE(div))
+#define FAN_TO_REG(val, div) ((val) == 0 ? 0 : \
+ DIV_ROUND_CLOSEST(480000, \
+ FAN_CLAMP(val, div) << (div)))
static ssize_t get_fan_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -513,9 +520,9 @@ static SENSOR_DEVICE_ATTR(fan2_div, S_IR
static DEVICE_ATTR(fan1_off, S_IRUGO | S_IWUSR,
get_fan_off, set_fan_off);
-#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
-#define TEMP_TO_REG(val) clamp_val(((((val) < 0 ? \
- (val) - 500 : (val) + 500) / 1000) + 130), 0, 255)
+#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
+#define TEMP_CLAMP(val) clamp_val(val, -130000, 125000)
+#define TEMP_TO_REG(val) (DIV_ROUND_CLOSEST(TEMP_CLAMP(val), 1000) + 130)
static ssize_t get_temp_input(struct device *dev, struct device_attribute *attr,
char *buf)
Patches currently in stable-queue which might be from linux@roeck-us.net are
queue-4.4/hwmon-gl520sm-fix-overflows-and-crash-seen-when-writing-into-limit-attributes.patch
^ permalink raw reply
* Re: [PATCH v4 04/15] x86: implement data structure and CPU init flow for MBA
From: Jan Beulich @ 2017-10-05 8:49 UTC (permalink / raw)
To: Yi Sun; +Cc: andrew.cooper3, xen-devel, wei.liu2, chao.p.peng, roger.pau
In-Reply-To: <20171005044247.GG11006@yi.y.sun>
>>> On 05.10.17 at 06:42, <yi.y.sun@linux.intel.com> wrote:
> On 17-10-03 23:52:09, Jan Beulich wrote:
>> >>> Yi Sun <yi.y.sun@linux.intel.com> 09/29/17 3:55 AM >>>
>> >On 17-09-28 05:00:09, Jan Beulich wrote:
>> >> >>> On 23.09.17 at 11:48, <yi.y.sun@linux.intel.com> wrote:
>> >> > @@ -1410,6 +1496,7 @@ static void psr_cpu_init(void)
>> >> > unsigned int socket, cpu = smp_processor_id();
>> >> > struct feat_node *feat;
>> >> > struct cpuid_leaf regs;
>> >> > + uint32_t ebx;
>> >>
>> >> Is this local variable really a big help? To me it looks like it only
>> >> makes the patch larger without actually improving anything,
>> >> and without being related to the subject of the patch.
>> >>
>> >IMHO, it can avoid the 'cpuid_count_leaf()' being repeatedly called. Without it,
>> >we have to call 'cpuid_count_leaf()' for 2 more times.
>>
>> Hmm, didn't you simply replace regs.b uses with ebx? Or did I overlook a place
>> where regs is being overwritten before the last of these regs.b uses (in which case
>> I think your change is fine)?
>>
> The regs is overwritten when a feature presents. The old codes are below
>
> cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, ®s);
> if ( regs.b & PSR_RESOURCE_TYPE_L3 )
> {
> cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, ®s); //It is overwritten here.
> ......
> }
>
> cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, ®s); //So, we have to call cpuid to get regs again.
> if ( regs.b & PSR_RESOURCE_TYPE_L2 )
> {
> cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 2, ®s);
> ......
>
> Because above reason, I defined this ebx local variable to avoid calling cpuid
> again for next feature.
I see. But then please give the variable a better name, reflecting
the data it holds.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Patch "i2c: meson: fix wrong variable usage in meson_i2c_put_data" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: hkallweit1, alexander.levin, gregkh, jbrunet, wsa; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
i2c: meson: fix wrong variable usage in meson_i2c_put_data
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=summary
The filename of the patch is:
i2c-meson-fix-wrong-variable-usage-in-meson_i2c_put_data.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 7 Mar 2017 21:06:38 +0100
Subject: i2c: meson: fix wrong variable usage in meson_i2c_put_data
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 3b0277f198ac928f323c42e180680d2f79aa980d ]
Most likely a copy & paste error.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller")
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-meson.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -175,7 +175,7 @@ static void meson_i2c_put_data(struct me
wdata1 |= *buf++ << ((i - 4) * 8);
writel(wdata0, i2c->regs + REG_TOK_WDATA0);
- writel(wdata0, i2c->regs + REG_TOK_WDATA1);
+ writel(wdata1, i2c->regs + REG_TOK_WDATA1);
dev_dbg(i2c->dev, "%s: data %08x %08x len %d\n", __func__,
wdata0, wdata1, len);
Patches currently in stable-queue which might be from hkallweit1@gmail.com are
queue-4.4/mmc-sdio-fix-alignment-issue-in-struct-sdio_func.patch
queue-4.4/i2c-meson-fix-wrong-variable-usage-in-meson_i2c_put_data.patch
^ permalink raw reply
* Patch "GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: dan.carpenter, alexander.levin, gregkh, rpeterso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
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=summary
The filename of the patch is:
gfs2-fix-reference-to-err_ptr-in-gfs2_glock_iter_next.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 14 Dec 2016 08:02:03 -0600
Subject: GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 14d37564fa3dc4e5d4c6828afcd26ac14e6796c5 ]
This patch fixes a place where function gfs2_glock_iter_next can
reference an invalid error pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/gfs2/glock.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1798,16 +1798,18 @@ void gfs2_glock_exit(void)
static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi)
{
- do {
- gi->gl = rhashtable_walk_next(&gi->hti);
+ while ((gi->gl = rhashtable_walk_next(&gi->hti))) {
if (IS_ERR(gi->gl)) {
if (PTR_ERR(gi->gl) == -EAGAIN)
continue;
gi->gl = NULL;
+ return;
}
- /* Skip entries for other sb and dead entries */
- } while ((gi->gl) && ((gi->sdp != gi->gl->gl_name.ln_sbd) ||
- __lockref_is_dead(&gi->gl->gl_lockref)));
+ /* Skip entries for other sb and dead entries */
+ if (gi->sdp == gi->gl->gl_name.ln_sbd &&
+ !__lockref_is_dead(&gi->gl->gl_lockref))
+ return;
+ }
}
static void *gfs2_glock_seq_start(struct seq_file *seq, loff_t *pos)
Patches currently in stable-queue which might be from dan.carpenter@oracle.com are
queue-4.4/gfs2-fix-reference-to-err_ptr-in-gfs2_glock_iter_next.patch
queue-4.4/asoc-dapm-fix-some-pointer-error-handling.patch
^ permalink raw reply
* Patch "IB/ipoib: Replace list_del of the neigh->list with list_del_init" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex,
yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Replace list_del of the neigh->list with list_del_init
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=summary
The filename of the patch is:
ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:27 +0200
Subject: IB/ipoib: Replace list_del of the neigh->list with list_del_init
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
In order to resolve a situation where a few process delete
the same list element in sequence and cause panic, list_del
is replaced with list_del_init. In this case if the first
process that calls list_del releases the lock before acquiring
it again, other processes who can acquire the lock will call
list_del_init.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1239,7 +1239,7 @@ static void __ipoib_reap_neigh(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1406,7 +1406,7 @@ void ipoib_neigh_free(struct ipoib_neigh
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
return;
} else {
@@ -1491,7 +1491,7 @@ void ipoib_del_neighs_by_gid(struct net_
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1533,7 +1533,7 @@ static void ipoib_flush_neighs(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
}
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.4/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.4/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.4/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "IB/ipoib: Fix deadlock over vlan_mutex" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Fix deadlock over vlan_mutex
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=summary
The filename of the patch is:
ib-ipoib-fix-deadlock-over-vlan_mutex.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:22 +0200
Subject: IB/ipoib: Fix deadlock over vlan_mutex
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 1c3098cdb05207e740715857df7b0998e372f527 ]
This patch fixes Deadlock while executing ipoib_vlan_delete.
The function takes the vlan_rwsem semaphore and calls
unregister_netdevice. The later function calls
ipoib_mcast_stop_thread that cause workqueue flush.
When the queue has one of the ipoib_ib_dev_flush_xxx events,
a deadlock occur because these events also tries to catch the
same vlan_rwsem semaphore.
To fix, unregister_netdevice should be called after releasing
the semaphore.
Fixes: cbbe1efa4972 ("IPoIB: Fix deadlock between ipoib_open() and child interface create")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -185,7 +185,6 @@ int ipoib_vlan_delete(struct net_device
list_for_each_entry_safe(priv, tpriv, &ppriv->child_intfs, list) {
if (priv->pkey == pkey &&
priv->child_type == IPOIB_LEGACY_CHILD) {
- unregister_netdevice(priv->dev);
list_del(&priv->list);
dev = priv->dev;
break;
@@ -193,6 +192,11 @@ int ipoib_vlan_delete(struct net_device
}
up_write(&ppriv->vlan_rwsem);
+ if (dev) {
+ ipoib_dbg(ppriv, "delete child vlan %s\n", dev->name);
+ unregister_netdevice(dev);
+ }
+
rtnl_unlock();
if (dev) {
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.4/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.4/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.4/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "IB/ipoib: rtnl_unlock can not come after free_netdev" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon,
ogerlitz, yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: rtnl_unlock can not come after free_netdev
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=summary
The filename of the patch is:
ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:24 +0200
Subject: IB/ipoib: rtnl_unlock can not come after free_netdev
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 89a3987ab7a923c047c6dec008e60ad6f41fac22 ]
The ipoib_vlan_add function calls rtnl_unlock after free_netdev,
rtnl_unlock not only releases the lock, but also calls netdev_run_todo.
The latter function browses the net_todo_list array and completes the
unregistration of all its net_device instances. If we call free_netdev
before rtnl_unlock, then netdev_run_todo call over the freed device causes
panic.
To fix, move rtnl_unlock call before free_netdev call.
Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -160,11 +160,11 @@ int ipoib_vlan_add(struct net_device *pd
out:
up_write(&ppriv->vlan_rwsem);
+ rtnl_unlock();
+
if (result)
free_netdev(priv->dev);
- rtnl_unlock();
-
return result;
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.4/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.4/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.4/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: hdegoede, alexander.levin, gregkh, jic23, wens; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
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=summary
The filename of the patch is:
iio-adc-axp288-drop-bogus-axp288_adc_ts_pin_ctrl-register-modifications.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 14 Dec 2016 14:55:25 +0100
Subject: iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit fa2849e9649b5180ffc4cb3c3b005261c403093a ]
For some reason the axp288_adc driver was modifying the
AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on
whether the GP_ADC channel or another channel was written.
These bits control when a bias current is send to the TS_PIN, the
GP_ADC has its own pin and a separate bit in another register to
control the bias current.
Not only does changing when to enable the TS_PIN bias current
(always or only when sampling) when reading the GP_ADC make no sense
at all, the code is modifying these bits is writing the entire register,
assuming that all the other bits have their default value.
So if the firmware has configured a different bias-current for either
pin, then that change gets clobbered by the write, likewise if the
firmware has set bit 2 to indicate that the battery has no thermal sensor,
this will get clobbered by the write.
This commit fixes all this, by simply removing all writes to the
AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the
GP_ADC pin, and can actually be harmful.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/axp288_adc.c | 32 +-------------------------------
1 file changed, 1 insertion(+), 31 deletions(-)
--- a/drivers/iio/adc/axp288_adc.c
+++ b/drivers/iio/adc/axp288_adc.c
@@ -28,8 +28,6 @@
#include <linux/iio/driver.h>
#define AXP288_ADC_EN_MASK 0xF1
-#define AXP288_ADC_TS_PIN_GPADC 0xF2
-#define AXP288_ADC_TS_PIN_ON 0xF3
enum axp288_adc_id {
AXP288_ADC_TS,
@@ -123,16 +121,6 @@ static int axp288_adc_read_channel(int *
return IIO_VAL_INT;
}
-static int axp288_adc_set_ts(struct regmap *regmap, unsigned int mode,
- unsigned long address)
-{
- /* channels other than GPADC do not need to switch TS pin */
- if (address != AXP288_GP_ADC_H)
- return 0;
-
- return regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, mode);
-}
-
static int axp288_adc_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val, int *val2, long mask)
@@ -143,16 +131,7 @@ static int axp288_adc_read_raw(struct ii
mutex_lock(&indio_dev->mlock);
switch (mask) {
case IIO_CHAN_INFO_RAW:
- if (axp288_adc_set_ts(info->regmap, AXP288_ADC_TS_PIN_GPADC,
- chan->address)) {
- dev_err(&indio_dev->dev, "GPADC mode\n");
- ret = -EINVAL;
- break;
- }
ret = axp288_adc_read_channel(val, chan->address, info->regmap);
- if (axp288_adc_set_ts(info->regmap, AXP288_ADC_TS_PIN_ON,
- chan->address))
- dev_err(&indio_dev->dev, "TS pin restore\n");
break;
default:
ret = -EINVAL;
@@ -162,15 +141,6 @@ static int axp288_adc_read_raw(struct ii
return ret;
}
-static int axp288_adc_set_state(struct regmap *regmap)
-{
- /* ADC should be always enabled for internal FG to function */
- if (regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, AXP288_ADC_TS_PIN_ON))
- return -EIO;
-
- return regmap_write(regmap, AXP20X_ADC_EN1, AXP288_ADC_EN_MASK);
-}
-
static const struct iio_info axp288_adc_iio_info = {
.read_raw = &axp288_adc_read_raw,
.driver_module = THIS_MODULE,
@@ -199,7 +169,7 @@ static int axp288_adc_probe(struct platf
* Set ADC to enabled state at all time, including system suspend.
* otherwise internal fuel gauge functionality may be affected.
*/
- ret = axp288_adc_set_state(axp20x->regmap);
+ ret = regmap_write(info->regmap, AXP20X_ADC_EN1, AXP288_ADC_EN_MASK);
if (ret) {
dev_err(&pdev->dev, "unable to enable ADC device\n");
return ret;
Patches currently in stable-queue which might be from hdegoede@redhat.com are
queue-4.4/iio-adc-axp288-drop-bogus-axp288_adc_ts_pin_ctrl-register-modifications.patch
queue-4.4/extcon-axp288-use-vbus-valid-instead-of-present-to-determine-cable-presence.patch
^ permalink raw reply
* Patch "igb: re-assign hw address pointer on reset after PCI error" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: gpiccoli, aaron.f.brown, ahthai, alexander.levin, gregkh,
hathyaga, jeffrey.t.kirsher
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
igb: re-assign hw address pointer on reset after PCI error
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=summary
The filename of the patch is:
igb-re-assign-hw-address-pointer-on-reset-after-pci-error.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Date: Thu, 10 Nov 2016 16:46:43 -0200
Subject: igb: re-assign hw address pointer on reset after PCI error
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
[ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ]
Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0xFFFFFFFF), it will detach the
net_device, clear the hw_addr pointer and warn to the user that adapter's
link is lost - those steps happen on igb_rd32().
In case a PCI error happens on Power architecture, there's a recovery
mechanism called EEH, that will reset the PCI slot and call driver's
handlers to reset the adapter and network functionality as well.
We observed that once hw_addr is NULL after the error is detected on
igb_rd32(), it's never assigned back, so in the process of resetting
the network functionality we got a NULL pointer dereference in both
igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid
such bug, this patch re-assigns the hw_addr value in the slot_reset
handler.
Reported-by: Anthony H Thai <ahthai@us.ibm.com>
Reported-by: Harsha Thyagaraja <hathyaga@in.ibm.com>
Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -7658,6 +7658,11 @@ static pci_ers_result_t igb_io_slot_rese
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
+ /* In case of PCI error, adapter lose its HW address
+ * so we should re-assign it here.
+ */
+ hw->hw_addr = adapter->io_addr;
+
igb_reset(adapter);
wr32(E1000_WUS, ~0);
result = PCI_ERS_RESULT_RECOVERED;
Patches currently in stable-queue which might be from gpiccoli@linux.vnet.ibm.com are
queue-4.4/igb-re-assign-hw-address-pointer-on-reset-after-pci-error.patch
^ permalink raw reply
* Patch "iommu/io-pgtable-arm: Check for leaf entry before dereferencing it" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: oleksandr_tyshchenko, alexander.levin, gregkh, robin.murphy,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iommu/io-pgtable-arm: Check for leaf entry before dereferencing it
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=summary
The filename of the patch is:
iommu-io-pgtable-arm-check-for-leaf-entry-before-dereferencing-it.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date: Mon, 27 Feb 2017 14:30:25 +0200
Subject: iommu/io-pgtable-arm: Check for leaf entry before dereferencing it
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
[ Upstream commit ed46e66cc1b3d684042f92dfa2ab15ee917b4cac ]
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/io-pgtable-arm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -335,8 +335,12 @@ static int __arm_lpae_map(struct arm_lpa
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
pte |= ARM_LPAE_PTE_NSTABLE;
__arm_lpae_set_pte(ptep, pte, cfg);
- } else {
+ } else if (!iopte_leaf(pte, lvl)) {
cptep = iopte_deref(pte, data);
+ } else {
+ /* We require an unmap first */
+ WARN_ON(!selftest_running);
+ return -EEXIST;
}
/* Rinse, repeat */
Patches currently in stable-queue which might be from oleksandr_tyshchenko@epam.com are
queue-4.4/iommu-io-pgtable-arm-check-for-leaf-entry-before-dereferencing-it.patch
^ permalink raw reply
* Patch "iio: adc: hx711: Add DT binding for avia,hx711" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: ak, alexander.levin, gregkh, jic23, robh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: adc: hx711: Add DT binding for avia,hx711
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=summary
The filename of the patch is:
iio-adc-hx711-add-dt-binding-for-avia-hx711.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Andreas Klinger <ak@it-klinger.de>
Date: Thu, 5 Jan 2017 18:51:36 +0100
Subject: iio: adc: hx711: Add DT binding for avia,hx711
From: Andreas Klinger <ak@it-klinger.de>
[ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 18 +++++++++++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,18 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+ - avdd-supply: Definition of the regulator used as analog supply
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ avdd-suppy = <&avdd>;
+};
+
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -31,6 +31,7 @@ asahi-kasei Asahi Kasei Corp.
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
bosch Bosch Sensortec GmbH
Patches currently in stable-queue which might be from ak@it-klinger.de are
queue-4.4/iio-adc-hx711-add-dt-binding-for-avia-hx711.patch
^ permalink raw reply
* Patch "md/raid10: submit bio directly to replacement disk" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: shli, alexander.levin, gregkh, neilb; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
md/raid10: submit bio directly to replacement disk
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=summary
The filename of the patch is:
md-raid10-submit-bio-directly-to-replacement-disk.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Shaohua Li <shli@fb.com>
Date: Thu, 23 Feb 2017 12:26:41 -0800
Subject: md/raid10: submit bio directly to replacement disk
From: Shaohua Li <shli@fb.com>
[ Upstream commit 6d399783e9d4e9bd44931501948059d24ad96ff8 ]
Commit 57c67df(md/raid10: submit IO from originating thread instead of
md thread) submits bio directly for normal disks but not for replacement
disks. There is no point we shouldn't do this for replacement disks.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid10.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1414,11 +1414,24 @@ retry_write:
mbio->bi_private = r10_bio;
atomic_inc(&r10_bio->remaining);
+
+ cb = blk_check_plugged(raid10_unplug, mddev,
+ sizeof(*plug));
+ if (cb)
+ plug = container_of(cb, struct raid10_plug_cb,
+ cb);
+ else
+ plug = NULL;
spin_lock_irqsave(&conf->device_lock, flags);
- bio_list_add(&conf->pending_bio_list, mbio);
- conf->pending_count++;
+ if (plug) {
+ bio_list_add(&plug->pending, mbio);
+ plug->pending_cnt++;
+ } else {
+ bio_list_add(&conf->pending_bio_list, mbio);
+ conf->pending_count++;
+ }
spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!mddev_check_plugged(mddev))
+ if (!plug)
md_wakeup_thread(mddev->thread);
}
}
Patches currently in stable-queue which might be from shli@fb.com are
queue-4.4/md-raid10-submit-bio-directly-to-replacement-disk.patch
^ permalink raw reply
* Patch "libata: transport: Remove circular dependency at free time" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: gwendal, alexander.levin, gregkh, tedheadster, tj; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
libata: transport: Remove circular dependency at free time
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=summary
The filename of the patch is:
libata-transport-remove-circular-dependency-at-free-time.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Gwendal Grignou <gwendal@chromium.org>
Date: Fri, 3 Mar 2017 09:00:09 -0800
Subject: libata: transport: Remove circular dependency at free time
From: Gwendal Grignou <gwendal@chromium.org>
[ Upstream commit d85fc67dd11e9a32966140677d4d6429ca540b25 ]
Without this patch, failed probe would not free resources like irq.
ata port tdev object currently hold a reference to the ata port
object. Therefore the ata port object release function will not get
called until the ata_tport_release is called. But that would never
happen, releasing the last reference of ata port dev is done by
scsi_host_release, which is called by ata_host_release when the ata
port object is released.
The ata device objects actually do not need to explicitly hold a
reference to their real counterpart, given the transport objects are
the children of these objects and device_add() is call for each child.
We know the parent will not be deleted until we call the child's
device_del().
Reported-by: Matthew Whitehead <tedheadster@gmail.com>
Tested-by: Matthew Whitehead <tedheadster@gmail.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-transport.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -224,7 +224,6 @@ static DECLARE_TRANSPORT_CLASS(ata_port_
static void ata_tport_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -284,7 +283,7 @@ int ata_tport_add(struct device *parent,
device_initialize(dev);
dev->type = &ata_port_type;
- dev->parent = get_device(parent);
+ dev->parent = parent;
dev->release = ata_tport_release;
dev_set_name(dev, "ata%d", ap->print_id);
transport_setup_device(dev);
@@ -348,7 +347,6 @@ static DECLARE_TRANSPORT_CLASS(ata_link_
static void ata_tlink_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -410,7 +408,7 @@ int ata_tlink_add(struct ata_link *link)
int error;
device_initialize(dev);
- dev->parent = get_device(&ap->tdev);
+ dev->parent = &ap->tdev;
dev->release = ata_tlink_release;
if (ata_is_host_link(link))
dev_set_name(dev, "link%d", ap->print_id);
@@ -588,7 +586,6 @@ static DECLARE_TRANSPORT_CLASS(ata_dev_c
static void ata_tdev_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -661,7 +658,7 @@ static int ata_tdev_add(struct ata_devic
int error;
device_initialize(dev);
- dev->parent = get_device(&link->tdev);
+ dev->parent = &link->tdev;
dev->release = ata_tdev_release;
if (ata_is_host_link(link))
dev_set_name(dev, "dev%d.%d", ap->print_id,ata_dev->devno);
Patches currently in stable-queue which might be from gwendal@chromium.org are
queue-4.4/libata-transport-remove-circular-dependency-at-free-time.patch
^ permalink raw reply
* Patch "MIPS: Ensure bss section ends on a long-aligned address" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:49 UTC (permalink / raw)
To: paul.burton, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: Ensure bss section ends on a long-aligned address
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=summary
The filename of the patch is:
mips-ensure-bss-section-ends-on-a-long-aligned-address.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Paul Burton <paul.burton@imgtec.com>
Date: Mon, 7 Nov 2016 11:52:19 +0000
Subject: MIPS: Ensure bss section ends on a long-aligned address
From: Paul Burton <paul.burton@imgtec.com>
[ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ]
When clearing the .bss section in kernel_entry we do so using LONG_S
instructions, and branch whilst the current write address doesn't equal
the end of the .bss section minus the size of a long integer. The .bss
section always begins at a long-aligned address and we always increment
the write pointer by the size of a long integer - we therefore rely upon
the .bss section ending at a long-aligned address. If this is not the
case then the long-aligned write address can never be equal to the
non-long-aligned end address & we will continue to increment past the
end of the .bss section, attempting to zero the rest of memory.
Despite this requirement that .bss end at a long-aligned address we pass
0 as the end alignment requirement to the BSS_SECTION macro and thus
don't guarantee any particular alignment, allowing us to hit the error
condition described above.
Fix this by instead passing 8 bytes as the end alignment argument to
the BSS_SECTION macro, ensuring that the end of the .bss section is
always at least long-aligned.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14526/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -159,7 +159,7 @@ SECTIONS
* Force .bss to 64K alignment so that .bss..swapper_pg_dir
* gets that alignment. .sbss should be empty, so there will be
* no holes after __init_end. */
- BSS_SECTION(0, 0x10000, 0)
+ BSS_SECTION(0, 0x10000, 8)
_end = . ;
Patches currently in stable-queue which might be from paul.burton@imgtec.com are
queue-4.4/mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
queue-4.4/mips-ensure-bss-section-ends-on-a-long-aligned-address.patch
^ permalink raw reply
* Patch "MIPS: IRQ Stack: Unwind IRQ stack onto task stack" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: matt.redfearn, akpm, alexander.levin, cmetcalf, gregkh,
james.hogan, jason, marcin.nowakowski, mingo, paul.burton,
pbonzini, ralf, standby24x7
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: IRQ Stack: Unwind IRQ stack onto task stack
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=summary
The filename of the patch is:
mips-irq-stack-unwind-irq-stack-onto-task-stack.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Matt Redfearn <matt.redfearn@imgtec.com>
Date: Tue, 21 Mar 2017 14:52:25 +0000
Subject: MIPS: IRQ Stack: Unwind IRQ stack onto task stack
From: Matt Redfearn <matt.redfearn@imgtec.com>
[ Upstream commit db8466c581cca1a08b505f1319c3ecd246f16fa8 ]
When the separate IRQ stack was introduced, stack unwinding only
proceeded as far as the top of the IRQ stack, leading to kernel
backtraces being less useful, lacking the trace of what was interrupted.
Fix this by providing a means for the kernel to unwind the IRQ stack
onto the interrupted task stack. The processor state is saved to the
kernel task stack on interrupt. The IRQ_STACK_START macro reserves an
unsigned long at the top of the IRQ stack where the interrupted task
stack pointer can be saved. After the active stack is switched to the
IRQ stack, save the interrupted tasks stack pointer to the reserved
location.
Fix the stack unwinding code to look for the frame being the top of the
IRQ stack and if so get the next frame from the saved location. The
existing test does not work with the separate stack since the ra is no
longer pointed at ret_from_{irq,exception}.
The test to stop unwinding the stack 32 bytes from the top of a stack
must be modified to allow unwinding to continue up to the location of
the saved task stack pointer when on the IRQ stack. The low / high marks
of the stack are set depending on whether the sp is on an irq stack or
not.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: Masanari Iida <standby24x7@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jason A. Donenfeld <jason@zx2c4.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15788/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/include/asm/irq.h | 15 ++++++++++
arch/mips/kernel/asm-offsets.c | 1
arch/mips/kernel/genex.S | 8 ++++-
arch/mips/kernel/process.c | 56 +++++++++++++++++++++++++++--------------
4 files changed, 60 insertions(+), 20 deletions(-)
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -18,9 +18,24 @@
#include <irq.h>
#define IRQ_STACK_SIZE THREAD_SIZE
+#define IRQ_STACK_START (IRQ_STACK_SIZE - sizeof(unsigned long))
extern void *irq_stack[NR_CPUS];
+/*
+ * The highest address on the IRQ stack contains a dummy frame put down in
+ * genex.S (handle_int & except_vec_vi_handler) which is structured as follows:
+ *
+ * top ------------
+ * | task sp | <- irq_stack[cpu] + IRQ_STACK_START
+ * ------------
+ * | | <- First frame of IRQ context
+ * ------------
+ *
+ * task sp holds a copy of the task stack pointer where the struct pt_regs
+ * from exception entry can be found.
+ */
+
static inline bool on_irq_stack(int cpu, unsigned long sp)
{
unsigned long low = (unsigned long)irq_stack[cpu];
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -102,6 +102,7 @@ void output_thread_info_defines(void)
DEFINE(_THREAD_SIZE, THREAD_SIZE);
DEFINE(_THREAD_MASK, THREAD_MASK);
DEFINE(_IRQ_STACK_SIZE, IRQ_STACK_SIZE);
+ DEFINE(_IRQ_STACK_START, IRQ_STACK_START);
BLANK();
}
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -216,9 +216,11 @@ NESTED(handle_int, PT_SIZE, sp)
beq t0, t1, 2f
/* Switch to IRQ stack */
- li t1, _IRQ_STACK_SIZE
+ li t1, _IRQ_STACK_START
PTR_ADD sp, t0, t1
+ /* Save task's sp on IRQ stack so that unwinding can follow it */
+ LONG_S s1, 0(sp)
2:
jal plat_irq_dispatch
@@ -326,9 +328,11 @@ NESTED(except_vec_vi_handler, 0, sp)
beq t0, t1, 2f
/* Switch to IRQ stack */
- li t1, _IRQ_STACK_SIZE
+ li t1, _IRQ_STACK_START
PTR_ADD sp, t0, t1
+ /* Save task's sp on IRQ stack so that unwinding can follow it */
+ LONG_S s1, 0(sp)
2:
jalr v0
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -483,31 +483,52 @@ unsigned long notrace unwind_stack_by_ad
unsigned long pc,
unsigned long *ra)
{
+ unsigned long low, high, irq_stack_high;
struct mips_frame_info info;
unsigned long size, ofs;
+ struct pt_regs *regs;
int leaf;
- extern void ret_from_irq(void);
- extern void ret_from_exception(void);
if (!stack_page)
return 0;
/*
- * If we reached the bottom of interrupt context,
- * return saved pc in pt_regs.
+ * IRQ stacks start at IRQ_STACK_START
+ * task stacks at THREAD_SIZE - 32
*/
- if (pc == (unsigned long)ret_from_irq ||
- pc == (unsigned long)ret_from_exception) {
- struct pt_regs *regs;
- if (*sp >= stack_page &&
- *sp + sizeof(*regs) <= stack_page + THREAD_SIZE - 32) {
- regs = (struct pt_regs *)*sp;
- pc = regs->cp0_epc;
- if (!user_mode(regs) && __kernel_text_address(pc)) {
- *sp = regs->regs[29];
- *ra = regs->regs[31];
- return pc;
- }
+ low = stack_page;
+ if (!preemptible() && on_irq_stack(raw_smp_processor_id(), *sp)) {
+ high = stack_page + IRQ_STACK_START;
+ irq_stack_high = high;
+ } else {
+ high = stack_page + THREAD_SIZE - 32;
+ irq_stack_high = 0;
+ }
+
+ /*
+ * If we reached the top of the interrupt stack, start unwinding
+ * the interrupted task stack.
+ */
+ if (unlikely(*sp == irq_stack_high)) {
+ unsigned long task_sp = *(unsigned long *)*sp;
+
+ /*
+ * Check that the pointer saved in the IRQ stack head points to
+ * something within the stack of the current task
+ */
+ if (!object_is_on_stack((void *)task_sp))
+ return 0;
+
+ /*
+ * Follow pointer to tasks kernel stack frame where interrupted
+ * state was saved.
+ */
+ regs = (struct pt_regs *)task_sp;
+ pc = regs->cp0_epc;
+ if (!user_mode(regs) && __kernel_text_address(pc)) {
+ *sp = regs->regs[29];
+ *ra = regs->regs[31];
+ return pc;
}
return 0;
}
@@ -528,8 +549,7 @@ unsigned long notrace unwind_stack_by_ad
if (leaf < 0)
return 0;
- if (*sp < stack_page ||
- *sp + info.frame_size > stack_page + THREAD_SIZE - 32)
+ if (*sp < low || *sp + info.frame_size > high)
return 0;
if (leaf)
Patches currently in stable-queue which might be from matt.redfearn@imgtec.com are
queue-4.4/mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
^ permalink raw reply
* Patch "MIPS: ralink: Fix incorrect assignment on ralink_soc" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: colin.king, alexander.levin, gregkh, john, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: ralink: Fix incorrect assignment on ralink_soc
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=summary
The filename of the patch is:
mips-ralink-fix-incorrect-assignment-on-ralink_soc.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Colin Ian King <colin.king@canonical.com>
Date: Thu, 22 Dec 2016 23:52:58 +0000
Subject: MIPS: ralink: Fix incorrect assignment on ralink_soc
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit 08d90c81b714482dceb5323d14f6617bcf55ee61 ]
ralink_soc sould be assigned to RT3883_SOC, replace incorrect
comparision with assignment.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Fixes: 418d29c87061 ("MIPS: ralink: Unify SoC id handling")
Cc: John Crispin <john@phrozen.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14903/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/ralink/rt3883.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/ralink/rt3883.c
+++ b/arch/mips/ralink/rt3883.c
@@ -144,5 +144,5 @@ void prom_soc_init(struct ralink_soc_inf
rt2880_pinmux_data = rt3883_pinmux_data;
- ralink_soc == RT3883_SOC;
+ ralink_soc = RT3883_SOC;
}
Patches currently in stable-queue which might be from colin.king@canonical.com are
queue-4.4/mips-ralink-fix-incorrect-assignment-on-ralink_soc.patch
^ permalink raw reply
* Re: [PATCH v4 0/6] perf report/script: Support percent and multiple range in --time option
From: Jiri Olsa @ 2017-10-05 8:50 UTC (permalink / raw)
To: Jin Yao
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <1507040558-20344-1-git-send-email-yao.jin@linux.intel.com>
On Tue, Oct 03, 2017 at 10:22:32PM +0800, Jin Yao wrote:
> v4:
> ---
> 1. Use perf script time style for timestamp printing. Also add with
> the printing of sample duration. For example:
>
> perf report --header
>
> time of first sample : 5276531.323099
> time of last sample : 5276555.345625
> sample duration : 24022.526 ms
>
> 2. Fix an invalid time string issue. For example,
>
> perf script --time 10%/10x12321xsdfdasfdsafdsafdsa
>
> Now in code, it uses strtol to replace atoi.
for the patchset:
Acked-by: Jiri Olsa <jolsa@kernel.org>
thanks,
jirka
^ permalink raw reply
* Patch "mmc: sdio: fix alignment issue in struct sdio_func" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: hkallweit1, alexander.levin, gregkh, hgkr.klein, ulf.hansson
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
mmc: sdio: fix alignment issue in struct sdio_func
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=summary
The filename of the patch is:
mmc-sdio-fix-alignment-issue-in-struct-sdio_func.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 29 Mar 2017 20:54:37 +0200
Subject: mmc: sdio: fix alignment issue in struct sdio_func
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Helmut Klein <hgkr.klein@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/sdio_bus.c | 12 +++++++++++-
include/linux/mmc/sdio_func.h | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -266,7 +266,7 @@ static void sdio_release_func(struct dev
sdio_free_func_cis(func);
kfree(func->info);
-
+ kfree(func->tmpbuf);
kfree(func);
}
@@ -281,6 +281,16 @@ struct sdio_func *sdio_alloc_func(struct
if (!func)
return ERR_PTR(-ENOMEM);
+ /*
+ * allocate buffer separately to make sure it's properly aligned for
+ * DMA usage (incl. 64 bit DMA)
+ */
+ func->tmpbuf = kmalloc(4, GFP_KERNEL);
+ if (!func->tmpbuf) {
+ kfree(func);
+ return ERR_PTR(-ENOMEM);
+ }
+
func->card = card;
device_initialize(&func->dev);
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -53,7 +53,7 @@ struct sdio_func {
unsigned int state; /* function state */
#define SDIO_STATE_PRESENT (1<<0) /* present in sysfs */
- u8 tmpbuf[4]; /* DMA:able scratch buffer */
+ u8 *tmpbuf; /* DMA:able scratch buffer */
unsigned num_info; /* number of info strings */
const char **info; /* info strings */
Patches currently in stable-queue which might be from hkallweit1@gmail.com are
queue-4.4/mmc-sdio-fix-alignment-issue-in-struct-sdio_func.patch
queue-4.4/i2c-meson-fix-wrong-variable-usage-in-meson_i2c_put_data.patch
^ permalink raw reply
* Patch "MIPS: Lantiq: Fix another request_mem_region() return code check" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: arnd, alexander.levin, gregkh, john, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: Lantiq: Fix another request_mem_region() return code check
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=summary
The filename of the patch is:
mips-lantiq-fix-another-request_mem_region-return-code-check.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 17 Jan 2017 16:18:40 +0100
Subject: MIPS: Lantiq: Fix another request_mem_region() return code check
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 98ea51cb0c8ce009d9da1fd7b48f0ff1d7a9bbb0 ]
Hauke already fixed a couple of them, but one instance remains
that checks for a negative integer when it should check
for a NULL pointer:
arch/mips/lantiq/xway/sysctrl.c: In function 'ltq_soc_init':
arch/mips/lantiq/xway/sysctrl.c:473:19: error: ordered comparison of pointer with integer zero [-Werror=extra]
Fixes: 6e807852676a ("MIPS: Lantiq: Fix check for return value of request_mem_region()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: John Crispin <john@phrozen.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15043/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/lantiq/xway/sysctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/mips/lantiq/xway/sysctrl.c
+++ b/arch/mips/lantiq/xway/sysctrl.c
@@ -469,8 +469,8 @@ void __init ltq_soc_init(void)
panic("Failed to load xbar nodes from devicetree");
if (of_address_to_resource(np_xbar, 0, &res_xbar))
panic("Failed to get xbar resources");
- if (request_mem_region(res_xbar.start, resource_size(&res_xbar),
- res_xbar.name) < 0)
+ if (!request_mem_region(res_xbar.start, resource_size(&res_xbar),
+ res_xbar.name))
panic("Failed to get xbar resources");
ltq_xbar_membase = ioremap_nocache(res_xbar.start,
Patches currently in stable-queue which might be from arnd@arndb.de are
queue-4.4/mips-lantiq-fix-another-request_mem_region-return-code-check.patch
^ permalink raw reply
* Patch "net/packet: check length in getsockopt() called with PACKET_HDRLEN" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: glider, alexander.levin, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
net/packet: check length in getsockopt() called with PACKET_HDRLEN
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=summary
The filename of the patch is:
net-packet-check-length-in-getsockopt-called-with-packet_hdrlen.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Alexander Potapenko <glider@google.com>
Date: Tue, 25 Apr 2017 18:51:46 +0200
Subject: net/packet: check length in getsockopt() called with PACKET_HDRLEN
From: Alexander Potapenko <glider@google.com>
[ Upstream commit fd2c83b35752f0a8236b976978ad4658df14a59f ]
In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
|val| remains uninitialized and the syscall may behave differently
depending on its value, and even copy garbage to userspace on certain
architectures. To fix this we now return -EINVAL if optlen is too small.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3802,6 +3802,8 @@ static int packet_getsockopt(struct sock
case PACKET_HDRLEN:
if (len > sizeof(int))
len = sizeof(int);
+ if (len < sizeof(int))
+ return -EINVAL;
if (copy_from_user(&val, optval, len))
return -EFAULT;
switch (val) {
Patches currently in stable-queue which might be from glider@google.com are
queue-4.4/net-packet-check-length-in-getsockopt-called-with-packet_hdrlen.patch
^ permalink raw reply
* Patch "net: core: Prevent from dereferencing null pointer when releasing SKB" has been added to the 4.4-stable tree
From: gregkh @ 2017-10-05 8:50 UTC (permalink / raw)
To: mhjungk, alexander.levin, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
net: core: Prevent from dereferencing null pointer when releasing SKB
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=summary
The filename of the patch is:
net-core-prevent-from-dereferencing-null-pointer-when-releasing-skb.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@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:49:14 CEST 2017
From: Myungho Jung <mhjungk@gmail.com>
Date: Tue, 25 Apr 2017 11:58:15 -0700
Subject: net: core: Prevent from dereferencing null pointer when releasing SKB
From: Myungho Jung <mhjungk@gmail.com>
[ Upstream commit 9899886d5e8ec5b343b1efe44f185a0e68dc6454 ]
Added NULL check to make __dev_kfree_skb_irq consistent with kfree
family of functions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2338,6 +2338,9 @@ void __dev_kfree_skb_irq(struct sk_buff
{
unsigned long flags;
+ if (unlikely(!skb))
+ return;
+
if (likely(atomic_read(&skb->users) == 1)) {
smp_rmb();
atomic_set(&skb->users, 0);
Patches currently in stable-queue which might be from mhjungk@gmail.com are
queue-4.4/net-core-prevent-from-dereferencing-null-pointer-when-releasing-skb.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.