This is a note to let you know that I've just added the patch titled
dt-bindings: Add vendor prefix for LEGO
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dt-bindings-add-vendor-prefix-for-lego.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 18:22:51 CET 2017
From: David Lechner <david(a)lechnology.com>
Date: Fri, 13 Jan 2017 13:03:39 -0600
Subject: dt-bindings: Add vendor prefix for LEGO
From: David Lechner <david(a)lechnology.com>
[ Upstream commit 7dcc31e2e68a386a29070384b51683ece80982bf ]
Add a vendor prefix for LEGO Systems A/S
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -126,6 +126,7 @@ keymile Keymile GmbH
kinetic Kinetic Technologies
lacie LaCie
lantiq Lantiq Semiconductor
+lego LEGO Systems A/S
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-4.4/dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.4/dt-bindings-add-vendor-prefix-for-lego.patch
This is a note to let you know that I've just added the patch titled
drm: drm_minor_register(): Clean up debugfs on failure
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-drm_minor_register-clean-up-debugfs-on-failure.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 18:22:51 CET 2017
From: Noralf Trønnes <noralf(a)tronnes.org>
Date: Thu, 26 Jan 2017 23:56:04 +0100
Subject: drm: drm_minor_register(): Clean up debugfs on failure
From: Noralf Trønnes <noralf(a)tronnes.org>
[ Upstream commit a67834f8bfa1e2f48bb27d07b9a552ba7c3af82a ]
Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.
Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -312,7 +312,7 @@ static int drm_minor_register(struct drm
ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
if (ret) {
DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
- return ret;
+ goto err_debugfs;
}
ret = device_add(minor->kdev);
Patches currently in stable-queue which might be from noralf(a)tronnes.org are
queue-4.4/drm-drm_minor_register-clean-up-debugfs-on-failure.patch
This is a note to let you know that I've just added the patch titled
ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 18:22:51 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Fri, 20 Jan 2017 12:13:19 -0800
Subject: ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ]
We have more than four uarts on some SoCs and that can cause
noise with errors while booting.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -221,6 +221,7 @@ CONFIG_SERIO=m
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
+CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.4/arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch
This is a note to let you know that I've just added the patch titled
crypto: vmx - disable preemption to enable vsx in aes_ctr.c
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-vmx-disable-preemption-to-enable-vsx-in-aes_ctr.c.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 18:22:51 CET 2017
From: Li Zhong <zhong(a)linux.vnet.ibm.com>
Date: Fri, 20 Jan 2017 16:35:33 +0800
Subject: crypto: vmx - disable preemption to enable vsx in aes_ctr.c
From: Li Zhong <zhong(a)linux.vnet.ibm.com>
[ Upstream commit 7dede913fc2ab9c0d3bff3a49e26fa9e858b0c13 ]
Some preemptible check warnings were reported from enable_kernel_vsx(). This
patch disables preemption in aes_ctr.c before enabling vsx, and they are now
consistent with other files in the same directory.
Signed-off-by: Li Zhong <zhong(a)linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/vmx/aes_ctr.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -80,11 +80,13 @@ static int p8_aes_ctr_setkey(struct cryp
int ret;
struct p8_aes_ctr_ctx *ctx = crypto_tfm_ctx(tfm);
+ preempt_disable();
pagefault_disable();
enable_kernel_altivec();
enable_kernel_vsx();
ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
pagefault_enable();
+ preempt_enable();
ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
return ret;
@@ -99,11 +101,13 @@ static void p8_aes_ctr_final(struct p8_a
u8 *dst = walk->dst.virt.addr;
unsigned int nbytes = walk->nbytes;
+ preempt_disable();
pagefault_disable();
enable_kernel_altivec();
enable_kernel_vsx();
aes_p8_encrypt(ctrblk, keystream, &ctx->enc_key);
pagefault_enable();
+ preempt_enable();
crypto_xor(keystream, src, nbytes);
memcpy(dst, keystream, nbytes);
@@ -132,6 +136,7 @@ static int p8_aes_ctr_crypt(struct blkci
blkcipher_walk_init(&walk, dst, src, nbytes);
ret = blkcipher_walk_virt_block(desc, &walk, AES_BLOCK_SIZE);
while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
+ preempt_disable();
pagefault_disable();
enable_kernel_altivec();
enable_kernel_vsx();
@@ -143,6 +148,7 @@ static int p8_aes_ctr_crypt(struct blkci
&ctx->enc_key,
walk.iv);
pagefault_enable();
+ preempt_enable();
/* We need to update IV mostly for last bytes/round */
inc = (nbytes & AES_BLOCK_MASK) / AES_BLOCK_SIZE;
Patches currently in stable-queue which might be from zhong(a)linux.vnet.ibm.com are
queue-4.4/crypto-vmx-disable-preemption-to-enable-vsx-in-aes_ctr.c.patch
queue-4.4/kvm-ppc-book-3s-xics-correct-the-real-mode-icp-rejecting-counter.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: imx53-qsb-common: fix FEC pinmux config
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 18:22:51 CET 2017
From: Patrick Bruenn <p.bruenn(a)beckhoff.com>
Date: Wed, 25 Jan 2017 06:25:48 +0100
Subject: ARM: dts: imx53-qsb-common: fix FEC pinmux config
From: Patrick Bruenn <p.bruenn(a)beckhoff.com>
[ Upstream commit 8b649e426336d7d4800ff9c82858328f4215ba01 ]
The pinmux configuration in device tree was different from manual
muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c
All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the
bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the
kernel tree, so it seems to be better to have the correct pinmuxing in
our files, too.
Signed-off-by: Patrick Bruenn <p.bruenn(a)beckhoff.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
+ MX53_PAD_FEC_MDC__FEC_MDC 0x4
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
>;
};
Patches currently in stable-queue which might be from p.bruenn(a)beckhoff.com are
queue-4.4/arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
This is a note to let you know that I've just added the patch titled
[media] adv7604: Initialize drive strength to default when using DT
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
adv7604-initialize-drive-strength-to-default-when-using-dt.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 18:22:51 CET 2017
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Tue, 29 Nov 2016 09:23:48 -0200
Subject: [media] adv7604: Initialize drive strength to default when using DT
From: Lars-Peter Clausen <lars(a)metafoo.de>
[ Upstream commit da8892d410db224d9a24104529794e6e37e0c100 ]
The adv7604 driver platform data contains fields for configuring the drive
strength of the output pins. When probing the driver through DT these
fields are not explicitly initialized, which means they are left at 0. This
is a reserved setting for the drive strength configuration though and can
cause signal integrity issues.
Whether these signal integrity issues are visible depends on the PCB
specifics (e.g. the higher the load capacitance for the output the more
visible the issue). But it has been observed on existing solutions at high
pixel clock rates.
Initialize the drive strength settings to the power-on-reset value of the
device when probing through devicetree to avoid this issue.
Fixes: 0e158be0162b ("adv7604: Add DT support")
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/i2c/adv7604.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2856,6 +2856,9 @@ static int adv76xx_parse_dt(struct adv76
state->pdata.alt_data_sat = 1;
state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0;
state->pdata.bus_order = ADV7604_BUS_ORDER_RGB;
+ state->pdata.dr_str_data = ADV76XX_DR_STR_MEDIUM_HIGH;
+ state->pdata.dr_str_clk = ADV76XX_DR_STR_MEDIUM_HIGH;
+ state->pdata.dr_str_sync = ADV76XX_DR_STR_MEDIUM_HIGH;
return 0;
}
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-4.4/adv7604-initialize-drive-strength-to-default-when-using-dt.patch
On Thu, Oct 19, 2017 at 1:22 AM, Jiri Kosina <jikos(a)kernel.org> wrote:
> On Wed, 18 Oct 2017, Jason Gerecke wrote:
>
>> The WACOM_PEN_FIELD macro is used to determine if a given HID field should be
>> associated with pen input. This field includes several known collection types
>> that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application
>> collection type is notably missing. This can result in fields within this
>> kind of collection being completely ignored by the `wacom_usage_mapping`
>> function, preventing the later '*_event' functions from being notified about
>> changes to their value.
>>
>> Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages")
>> Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch")
>> Cc: stable(a)vger.kernel.org
>> Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
>
> Applied to for-4.14/upstream-fixes
>
> --
> Jiri Kosina
> SUSE Labs
>
Was this branch ever sent to Linus? I don't see any mention of it (or
this patch) in the 4.14-rc8 history...
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
From: Roger Quadros <rogerq(a)ti.com>
[ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ]
extcon-palmas must be child of palmas and expects parent's
drvdata to be valid. Check for non NULL parent drvdata and
fail if it is NULL. Not doing so will result in a NULL
pointer dereference later in the probe() parent drvdata
is NULL (e.g. misplaced extcon-palmas node in device tree).
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
drivers/extcon/extcon-palmas.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 93c30a885740..aa2f6bb82b32 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -190,6 +190,11 @@ static int palmas_usb_probe(struct platform_device *pdev)
struct palmas_usb *palmas_usb;
int status;
+ if (!palmas) {
+ dev_err(&pdev->dev, "failed to get valid parent\n");
+ return -EINVAL;
+ }
+
palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL);
if (!palmas_usb)
return -ENOMEM;
--
2.11.0
This check has gone through several incompatible variations in commits
53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of
OS_DESC_EXT_COMPAT"), 354bc45bf329 ("usb: gadget: f_fs: Fix ExtCompat
descriptor validation") and 3ba534df815f ("Revert "usb: gadget: f_fs:
Fix ExtCompat descriptor validation"") after initially being introduced
in commit f0175ab51993 ("usb: gadget: f_fs: OS descriptors support").
The various changes make it impossible for a single userspace
implementation to work with different kernel versions, so let's just
drop the condition to avoid breaking userspace.
Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT")
Cc: stable(a)vger.kernel.org # v4.7+
Signed-off-by: John Keeping <john(a)metanate.com>
---
drivers/usb/gadget/function/f_fs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 652397eda6d6..0d9962834345 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2282,8 +2282,7 @@ static int __ffs_data_do_os_desc(enum ffs_os_desc_type type,
int i;
if (len < sizeof(*d) ||
- d->bFirstInterfaceNumber >= ffs->interfaces_count ||
- !d->Reserved1)
+ d->bFirstInterfaceNumber >= ffs->interfaces_count)
return -EINVAL;
for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i)
if (d->Reserved2[i])
--
2.15.0
We no longer use intel_crtc->wm.active for watermarks any more,
which was incorrect. But this uncovered a bug in sanitize_watermarks(),
which meant that we wrote the correct watermarks, but the next
update would still use the wrong hw watermarks for calculating.
This caused all further updates to fail with -EINVAL and the
log would reveal an error like the one below:
[ 10.043902] [drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0)
[ 10.043960] [drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid
[ 10.044030] [drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are possible
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Cc: stable(a)vger.kernel.org #v4.8+
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 84817ccc5305..17665ee06c9a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14442,6 +14442,8 @@ static void sanitize_watermarks(struct drm_device *dev)
cs->wm.need_postvbl_update = true;
dev_priv->display.optimize_watermarks(intel_state, cs);
+
+ to_intel_crtc_state(crtc->state)->wm = cs->wm;
}
put_state:
--
2.15.0
On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote:
>On Thu, Nov 09, 2017 at 10:09:10AM +0100, gregkh(a)linuxfoundation.org wrote:
>
>> This is a note to let you know that I've just added the patch titled
>>
>> ASoC: sunxi: Add bindings for sun8i to SPDIF
>
>> The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the
>> transmit fifo is at a different address.
>
>This doesn't seem like a good idea - note how the changelog says that
>the transmit FIFO is at a different address, I'd expect this means that
>people won't be able to use the new compatible without a corresponding
>code change.
Interesting. I keep trying to automate DT patch selection to deal with
issues as this, but it seems like there is always something...
I agree with Mark. I think it would make sense to pick 1bd92af877 as
well to deal with this issue.
--
Thanks,
Sasha
On Thu, Nov 09, 2017 at 12:40:36PM +0000, Ben Hutchings wrote:
> On Thu, 2017-11-09 at 13:21 +0100, Arnd Bergmann wrote:
> > On Thu, Nov 9, 2017 at 1:08 PM, Greg KH <greg(a)kroah.com> wrote:
> > > On Thu, Nov 09, 2017 at 12:55:30PM +0100, Arnd Bergmann wrote:
> [...]
> > > > I think if you upload the branch to the stable-rc git, that should produce
> > > > the automated build and boot results via email or via the
> > > > https://kernelci.org/job/ interface. Once there are some results
> > > > there, I'll go through the list once more to see what warnings
> > > > and failures remain.
> > >
> > > I don't know of a way to have others push to that tree/branch at the
> > > moment :(
> > >
> > > I'll go update that branch now...
> >
> > Thanks!
> >
> > With the arm-soc tree, we simply have a shared group-id on
> > gitolite.kernel.org and everyone in that group can push to it.
> >
> > If that is the only thing you need, it should be trivial to let Ben
> > and Sasha push to /pub/scm/linux/kernel/git/stable/*.git as well,
> > I'm sure helpdesk(a)kernel.org can arrange that. Of course if you are
> > worried about having multiple accounts with write access to all the
> > branches, then that wouldn't be enough.
>
> I think I'd rather send a pull request to Greg at the start of the
> review period.
>
If you change the trees I am supposed to pull from for my builders,
please let me know.
Guenter
Since commit 4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.
The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.
Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Cc: stable(a)vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index edd7d8127d19..c54806d08dd7 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
{
struct drm_encoder *encoder = &fsl_dev->encoder;
struct drm_connector *connector = &fsl_dev->connector.base;
- struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
int ret;
fsl_dev->connector.encoder = encoder;
@@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
if (ret < 0)
goto err_sysfs;
- drm_object_property_set_value(&connector->base,
- mode_config->dpms_property,
- DRM_MODE_DPMS_OFF);
-
ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
--
2.14.2
This is a note to let you know that I've just added the patch titled
USB: usbfs: compute urb->actual_length for isochronous
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Wed, 8 Nov 2017 12:23:17 -0500
Subject: USB: usbfs: compute urb->actual_length for isochronous
The USB kerneldoc says that the actual_length field "is read in
non-iso completion functions", but the usbfs driver uses it for all
URB types in processcompl(). Since not all of the host controller
drivers set actual_length for isochronous URBs, programs using usbfs
with some host controllers don't work properly. For example, Minas
reports that a USB camera controlled by libusb doesn't work properly
with a dwc2 controller.
It doesn't seem worthwhile to change the HCDs and the documentation,
since the in-kernel USB class drivers evidently don't rely on
actual_length for isochronous transfers. The easiest solution is for
usbfs to calculate the actual_length value for itself, by adding up
the lengths of the individual packets in an isochronous transfer.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Reported-and-tested-by: wlf <wulf(a)rock-chips.com>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/devio.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index c3aaafc25a04..2edb4e7b2ab8 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1820,6 +1820,18 @@ static int proc_unlinkurb(struct usb_dev_state *ps, void __user *arg)
return 0;
}
+static void compute_isochronous_actual_length(struct urb *urb)
+{
+ unsigned int i;
+
+ if (urb->number_of_packets > 0) {
+ urb->actual_length = 0;
+ for (i = 0; i < urb->number_of_packets; i++)
+ urb->actual_length +=
+ urb->iso_frame_desc[i].actual_length;
+ }
+}
+
static int processcompl(struct async *as, void __user * __user *arg)
{
struct urb *urb = as->urb;
@@ -1827,6 +1839,7 @@ static int processcompl(struct async *as, void __user * __user *arg)
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
goto err_out;
@@ -1995,6 +2008,7 @@ static int processcompl_compat(struct async *as, void __user * __user *arg)
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
return -EFAULT;
--
2.15.0
Tree/Branch: v4.1.46
Git describe: v4.1.46
Commit: 200d858d94 Linux 4.1.46
Build Time: 60 min 3 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 33
Section Mismatches: 1
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
22 warnings 3 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-multi_v7_defconfig
23 warnings 0 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm-multi_v5_defconfig
6 warnings 0 mismatches : x86_64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 33
8 ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
5 ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
2 ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../include/linux/ftrace.h:671:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
2 ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
2 ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
2 ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
2 ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
1 ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
1 ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/net/ethernet/dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined [-Wcpp]
1 ../drivers/net/ethernet/dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined! [-Wcpp]
1 ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/iommu/intel-iommu.c:3798:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
1 ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
1 ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../drivers/gpio/gpio-74xx-mmio.c:132:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
1 ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
Section Mismatch Summary: 1
3 WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 22 warnings, 3 section mismatches
Warnings:
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/gpio/gpio-74xx-mmio.c:132:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/ethernet/dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined [-Wcpp]
../drivers/net/ethernet/dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined! [-Wcpp]
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
Section Mismatches:
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 23 warnings, 0 section mismatches
Warnings:
../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
../include/linux/ftrace.h:671:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
../include/linux/ftrace.h:671:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
../drivers/iommu/intel-iommu.c:3798:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
arm64-defconfig
On Tue, Nov 7, 2017 at 12:02 AM, Ben Hutchings <ben(a)decadent.org.uk> wrote:
> This is the start of the stable review cycle for the 3.16.50 release.
> There are 294 patches in this series, which will be posted as responses
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Nov 08 18:00:00 UTC 2017.
> Anything received after that time might be too late.
>
> A combined patch relative to 3.16.49 will be posted as an additional
> response to this. A shortlog and diffstat can be found below.
I haven'tr tried building the proposed patches so far, as I was waiting for
the kernelci builds.
However, I see that the stable-rc/linux-3.16.y doesn't have the current
set, it still points to the old 3.16.35 release from last year.
I think if you upload the branch to the stable-rc git, that should produce
the automated build and boot results via email or via the
https://kernelci.org/job/ interface. Once there are some results
there, I'll go through the list once more to see what warnings
and failures remain.
I'm not in a hurry to fix the old warnings, and can do that pass after
the 3.16 release is out on git and in kernelci, but it would help to see
if the bots has caught any regressions.
Arnd
This is a note to let you know that I've just added the patch titled
USB: usbfs: compute urb->actual_length for isochronous
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Wed, 8 Nov 2017 12:23:17 -0500
Subject: USB: usbfs: compute urb->actual_length for isochronous
The USB kerneldoc says that the actual_length field "is read in
non-iso completion functions", but the usbfs driver uses it for all
URB types in processcompl(). Since not all of the host controller
drivers set actual_length for isochronous URBs, programs using usbfs
with some host controllers don't work properly. For example, Minas
reports that a USB camera controlled by libusb doesn't work properly
with a dwc2 controller.
It doesn't seem worthwhile to change the HCDs and the documentation,
since the in-kernel USB class drivers evidently don't rely on
actual_length for isochronous transfers. The easiest solution is for
usbfs to calculate the actual_length value for itself, by adding up
the lengths of the individual packets in an isochronous transfer.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Reported-and-tested-by: wlf <wulf(a)rock-chips.com>
CC: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/devio.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index c3aaafc25a04..2edb4e7b2ab8 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1820,6 +1820,18 @@ static int proc_unlinkurb(struct usb_dev_state *ps, void __user *arg)
return 0;
}
+static void compute_isochronous_actual_length(struct urb *urb)
+{
+ unsigned int i;
+
+ if (urb->number_of_packets > 0) {
+ urb->actual_length = 0;
+ for (i = 0; i < urb->number_of_packets; i++)
+ urb->actual_length +=
+ urb->iso_frame_desc[i].actual_length;
+ }
+}
+
static int processcompl(struct async *as, void __user * __user *arg)
{
struct urb *urb = as->urb;
@@ -1827,6 +1839,7 @@ static int processcompl(struct async *as, void __user * __user *arg)
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
goto err_out;
@@ -1995,6 +2008,7 @@ static int processcompl_compat(struct async *as, void __user * __user *arg)
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
return -EFAULT;
--
2.15.0
On Wed, Nov 01, 2017 at 03:37:22PM -0400, Vivek Goyal wrote:
> If ovl_check_origin() fails, we should put upperdentry. We have a reference
> on it by now. So goto out_put_upper instead of out.
>
> Fixes: a9d019573e88 ("ovl: lookup non-dir copy-up-origin by file handle")
> Cc: <stable(a)vger.kernel.org> #4.12
> Signed-off-by: Vivek Goyal <vgoyal(a)redhat.com>
Hi Amir, Miklos,
Does this patch look fine? I think its a simple bug fix and should go
in 4.15.
Vivek
> ---
> fs/overlayfs/namei.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
> index a12dc10bf726..bc6d5c5a3443 100644
> --- a/fs/overlayfs/namei.c
> +++ b/fs/overlayfs/namei.c
> @@ -630,7 +630,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry,
> err = ovl_check_origin(upperdentry, roe->lowerstack,
> roe->numlower, &stack, &ctr);
> if (err)
> - goto out;
> + goto out_put_upper;
> }
>
> if (d.redirect) {
> --
> 2.13.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
This is a note to let you know that I've just added the patch titled
xen/netback: set default upper limit of tx/rx queues to 8
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Juergen Gross <jgross(a)suse.com>
Date: Tue, 10 Jan 2017 14:32:52 +0100
Subject: xen/netback: set default upper limit of tx/rx queues to 8
From: Juergen Gross <jgross(a)suse.com>
[ Upstream commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ]
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module parameter if required.
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netback/netback.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -67,6 +67,7 @@ module_param(rx_drain_timeout_msecs, uin
unsigned int rx_stall_timeout_msecs = 60000;
module_param(rx_stall_timeout_msecs, uint, 0444);
+#define MAX_QUEUES_DEFAULT 8
unsigned int xenvif_max_queues;
module_param_named(max_queues, xenvif_max_queues, uint, 0644);
MODULE_PARM_DESC(max_queues,
@@ -2189,11 +2190,12 @@ static int __init netback_init(void)
if (!xen_domain())
return -ENODEV;
- /* Allow as many queues as there are CPUs if user has not
+ /* Allow as many queues as there are CPUs but max. 8 if user has not
* specified a value.
*/
if (xenvif_max_queues == 0)
- xenvif_max_queues = num_online_cpus();
+ xenvif_max_queues = min_t(unsigned int, MAX_QUEUES_DEFAULT,
+ num_online_cpus());
if (fatal_skb_slots < XEN_NETBK_LEGACY_SLOTS_MAX) {
pr_info("fatal_skb_slots too small (%d), bump it to XEN_NETBK_LEGACY_SLOTS_MAX (%d)\n",
Patches currently in stable-queue which might be from jgross(a)suse.com are
queue-3.18/xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.patch
This is a note to let you know that I've just added the patch titled
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: "Maciej W. Rozycki" <macro(a)linux-mips.org>
Date: Mon, 30 Jan 2017 17:39:48 +0100
Subject: video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
From: "Maciej W. Rozycki" <macro(a)linux-mips.org>
[ Upstream commit 879e5a0df626f39cbb3c61bb90373e56d67012c4 ]
Fix:
WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor()
The function pmagbafb_probe()
references the function __init pmagbafb_erase_cursor().
This is often because pmagbafb_probe lacks a __init
annotation or the annotation of pmagbafb_erase_cursor is wrong.
-- a fallout from a missed update from commit 9625b51350cc ("VIDEO:
PMAG-BA: Fix section mismatch") and then commit 48c68c4f1b54 ("Drivers:
video: remove __dev* attributes.")
Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/pmag-ba-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/pmag-ba-fb.c
+++ b/drivers/video/fbdev/pmag-ba-fb.c
@@ -129,7 +129,7 @@ static struct fb_ops pmagbafb_ops = {
/*
* Turn the hardware cursor off.
*/
-static void __init pmagbafb_erase_cursor(struct fb_info *info)
+static void pmagbafb_erase_cursor(struct fb_info *info)
{
struct pmagbafb_par *par = info->par;
Patches currently in stable-queue which might be from macro(a)linux-mips.org are
queue-3.18/video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.patch
This is a note to let you know that I've just added the patch titled
usb: hcd: initialize hcd->flags to 0 when rm hcd
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: William wu <wulf(a)rock-chips.com>
Date: Fri, 13 Jan 2017 11:04:22 +0800
Subject: usb: hcd: initialize hcd->flags to 0 when rm hcd
From: William wu <wulf(a)rock-chips.com>
[ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ]
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.
[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160
[173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28
[173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0
[173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8
[173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c
[173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c
[173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124
[173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44
[173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc
[173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
...
[173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8
[173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc
[173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94
[173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc
[173.604607] [<0000000000b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [<ffffffc000642084>] usb_hcd_irq
[173.604673] Disabling IRQ #228
Signed-off-by: William wu <wulf(a)rock-chips.com>
Acked-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hcd.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2927,6 +2927,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
usb_put_invalidate_rhdev(hcd);
+ hcd->flags = 0;
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
Patches currently in stable-queue which might be from wulf(a)rock-chips.com are
queue-3.18/usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Fix register offsets for the IRDA serial port
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
serial-sh-sci-fix-register-offsets-for-the-irda-serial-port.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Date: Wed, 11 Jan 2017 16:43:32 +0200
Subject: serial: sh-sci: Fix register offsets for the IRDA serial port
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
[ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ]
Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 -
drivers/tty/serial/sh-sci.c | 17 ++++++++---------
2 files changed, 8 insertions(+), 10 deletions(-)
--- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
+++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
@@ -165,7 +165,6 @@ static struct plat_sci_port scif2_platfo
.scscr = SCSCR_TE | SCSCR_RE,
.type = PORT_IRDA,
.ops = &sh770x_sci_port_ops,
- .regshift = 1,
};
static struct resource scif2_resources[] = {
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -171,18 +171,17 @@ static struct plat_sci_reg sci_regmap[SC
},
/*
- * Common definitions for legacy IrDA ports, dependent on
- * regshift value.
+ * Common definitions for legacy IrDA ports.
*/
[SCIx_IRDA_REGTYPE] = {
[SCSMR] = { 0x00, 8 },
- [SCBRR] = { 0x01, 8 },
- [SCSCR] = { 0x02, 8 },
- [SCxTDR] = { 0x03, 8 },
- [SCxSR] = { 0x04, 8 },
- [SCxRDR] = { 0x05, 8 },
- [SCFCR] = { 0x06, 8 },
- [SCFDR] = { 0x07, 16 },
+ [SCBRR] = { 0x02, 8 },
+ [SCSCR] = { 0x04, 8 },
+ [SCxTDR] = { 0x06, 8 },
+ [SCxSR] = { 0x08, 16 },
+ [SCxRDR] = { 0x0a, 8 },
+ [SCFCR] = { 0x0c, 8 },
+ [SCFDR] = { 0x0e, 16 },
[SCTFDR] = sci_reg_invalid,
[SCRFDR] = sci_reg_invalid,
[SCSPTR] = sci_reg_invalid,
Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are
queue-3.18/serial-sh-sci-fix-register-offsets-for-the-irda-serial-port.patch
This is a note to let you know that I've just added the patch titled
phy: increase size of MII_BUS_ID_SIZE and bus_id
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
phy-increase-size-of-mii_bus_id_size-and-bus_id.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com>
Date: Thu, 19 Jan 2017 17:05:04 +0100
Subject: phy: increase size of MII_BUS_ID_SIZE and bus_id
From: Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com>
[ Upstream commit 4567d686f5c6d955e57a3afa1741944c1e7f4033 ]
Some bus names are pretty long and do not fit into
17 chars. Increase therefore MII_BUS_ID_SIZE and
phy_fixup.bus_id to larger number. Now mii_bus.id
can host larger name.
Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com>
Signed-off-by: Magnus Öberg <magnus.oberg(a)westermo.se>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/phy.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -135,11 +135,7 @@ static inline const char *phy_modes(phy_
/* Used when trying to connect to a specific phy (mii bus id:phy device id) */
#define PHY_ID_FMT "%s:%02x"
-/*
- * Need to be a little smaller than phydev->dev.bus_id to leave room
- * for the ":%02x"
- */
-#define MII_BUS_ID_SIZE (20 - 3)
+#define MII_BUS_ID_SIZE 61
/* Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the 21 bit
IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy chips. */
@@ -573,7 +569,7 @@ struct phy_driver {
/* A Structure for boards to register fixups with the PHY Lib */
struct phy_fixup {
struct list_head list;
- char bus_id[20];
+ char bus_id[MII_BUS_ID_SIZE + 3];
u32 phy_uid;
u32 phy_uid_mask;
int (*run)(struct phy_device *phydev);
Patches currently in stable-queue which might be from volodymyr.bendiuga(a)gmail.com are
queue-3.18/phy-increase-size-of-mii_bus_id_size-and-bus_id.patch
This is a note to let you know that I've just added the patch titled
IPsec: do not ignore crypto err in ah4 input
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipsec-do-not-ignore-crypto-err-in-ah4-input.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Gilad Ben-Yossef <gilad(a)benyossef.com>
Date: Mon, 16 Jan 2017 13:17:55 +0200
Subject: IPsec: do not ignore crypto err in ah4 input
From: Gilad Ben-Yossef <gilad(a)benyossef.com>
[ Upstream commit ebd89a2d0675f1325c2be5b7576fd8cb7e8defd0 ]
ah4 input processing uses the asynchronous hash crypto API which
supplies an error code as part of the operation completion but
the error code was being ignored.
Treat a crypto API error indication as a verification failure.
While a crypto API reported error would almost certainly result
in a memcpy of the digest failing anyway and thus the security
risk seems minor, performing a memory compare on what might be
uninitialized memory is wrong.
Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ah4.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -270,6 +270,9 @@ static void ah_input_done(struct crypto_
int ihl = ip_hdrlen(skb);
int ah_hlen = (ah->hdrlen + 2) << 2;
+ if (err)
+ goto out;
+
work_iph = AH_SKB_CB(skb)->tmp;
auth_data = ah_tmp_auth(work_iph, ihl);
icv = ah_tmp_icv(ahp->ahash, auth_data, ahp->icv_trunc_len);
Patches currently in stable-queue which might be from gilad(a)benyossef.com are
queue-3.18/ipsec-do-not-ignore-crypto-err-in-ah4-input.patch
This is a note to let you know that I've just added the patch titled
Input: mpr121 - set missing event capability
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-mpr121-set-missing-event-capability.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Akinobu Mita <akinobu.mita(a)gmail.com>
Date: Sun, 15 Jan 2017 14:44:05 -0800
Subject: Input: mpr121 - set missing event capability
From: Akinobu Mita <akinobu.mita(a)gmail.com>
[ Upstream commit 9723ddc8fe0d76ce41fe0dc16afb241ec7d0a29d ]
This driver reports misc scan input events on the sensor's status
register changes. But the event capability for them was not set in the
device initialization, so these events were ignored.
This change adds the missing event capability.
Signed-off-by: Akinobu Mita <akinobu.mita(a)gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/keyboard/mpr121_touchkey.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/keyboard/mpr121_touchkey.c
+++ b/drivers/input/keyboard/mpr121_touchkey.c
@@ -235,6 +235,7 @@ static int mpr_touchkey_probe(struct i2c
input_dev->id.bustype = BUS_I2C;
input_dev->dev.parent = &client->dev;
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
+ input_set_capability(input_dev, EV_MSC, MSC_SCAN);
input_dev->keycode = mpr121->keycodes;
input_dev->keycodesize = sizeof(mpr121->keycodes[0]);
Patches currently in stable-queue which might be from akinobu.mita(a)gmail.com are
queue-3.18/input-mpr121-set-missing-event-capability.patch
queue-3.18/input-mpr121-handle-multiple-bits-change-of-status-register.patch
This is a note to let you know that I've just added the patch titled
Input: mpr121 - handle multiple bits change of status register
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-mpr121-handle-multiple-bits-change-of-status-register.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Akinobu Mita <akinobu.mita(a)gmail.com>
Date: Sun, 15 Jan 2017 14:44:30 -0800
Subject: Input: mpr121 - handle multiple bits change of status register
From: Akinobu Mita <akinobu.mita(a)gmail.com>
[ Upstream commit 08fea55e37f58371bffc5336a59e55d1f155955a ]
This driver reports input events on their interrupts which are triggered
by the sensor's status register changes. But only single bit change is
reported in the interrupt handler. So if there are multiple bits are
changed at almost the same time, other press or release events are ignored.
This fixes it by detecting all changed bits in the status register.
Signed-off-by: Akinobu Mita <akinobu.mita(a)gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/keyboard/mpr121_touchkey.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/drivers/input/keyboard/mpr121_touchkey.c
+++ b/drivers/input/keyboard/mpr121_touchkey.c
@@ -87,7 +87,8 @@ static irqreturn_t mpr_touchkey_interrup
struct mpr121_touchkey *mpr121 = dev_id;
struct i2c_client *client = mpr121->client;
struct input_dev *input = mpr121->input_dev;
- unsigned int key_num, key_val, pressed;
+ unsigned long bit_changed;
+ unsigned int key_num;
int reg;
reg = i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_1_ADDR);
@@ -105,18 +106,22 @@ static irqreturn_t mpr_touchkey_interrup
reg &= TOUCH_STATUS_MASK;
/* use old press bit to figure out which bit changed */
- key_num = ffs(reg ^ mpr121->statusbits) - 1;
- pressed = reg & (1 << key_num);
+ bit_changed = reg ^ mpr121->statusbits;
mpr121->statusbits = reg;
+ for_each_set_bit(key_num, &bit_changed, mpr121->keycount) {
+ unsigned int key_val, pressed;
- key_val = mpr121->keycodes[key_num];
+ pressed = reg & BIT(key_num);
+ key_val = mpr121->keycodes[key_num];
- input_event(input, EV_MSC, MSC_SCAN, key_num);
- input_report_key(input, key_val, pressed);
- input_sync(input);
+ input_event(input, EV_MSC, MSC_SCAN, key_num);
+ input_report_key(input, key_val, pressed);
+
+ dev_dbg(&client->dev, "key %d %d %s\n", key_num, key_val,
+ pressed ? "pressed" : "released");
- dev_dbg(&client->dev, "key %d %d %s\n", key_num, key_val,
- pressed ? "pressed" : "released");
+ }
+ input_sync(input);
out:
return IRQ_HANDLED;
Patches currently in stable-queue which might be from akinobu.mita(a)gmail.com are
queue-3.18/input-mpr121-set-missing-event-capability.patch
queue-3.18/input-mpr121-handle-multiple-bits-change-of-status-register.patch
This is a note to let you know that I've just added the patch titled
iio: trigger: free trigger resource correctly
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-trigger-free-trigger-resource-correctly.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Alison Schofield <amsfield22(a)gmail.com>
Date: Thu, 19 Jan 2017 19:47:38 -0800
Subject: iio: trigger: free trigger resource correctly
From: Alison Schofield <amsfield22(a)gmail.com>
[ Upstream commit 10e840dfb0b7fc345082dd9e5fff3c1c02e7690e ]
These stand-alone trigger drivers were using iio_trigger_put()
where they should have been using iio_trigger_free(). The
iio_trigger_put() adds a module_put which is bad since they
never did a module_get.
In the sysfs driver, module_get/put's are used as triggers are
added & removed. This extra module_put() occurs on an error path
in the probe routine (probably rare).
In the bfin-timer & interrupt trigger drivers, the module resources
are not explicitly managed, so it's doing a put on something that
was never get'd. It occurs on the probe error path and on the
remove path (not so rare).
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.
Signed-off-by: Alison Schofield <amsfield22(a)gmail.com>
Signed-off-by: Jonathan Cameron <jic23(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/trigger/iio-trig-interrupt.c | 8 ++++----
drivers/iio/trigger/iio-trig-sysfs.c | 2 +-
drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/iio/trigger/iio-trig-interrupt.c
+++ b/drivers/iio/trigger/iio-trig-interrupt.c
@@ -58,7 +58,7 @@ static int iio_interrupt_trigger_probe(s
trig_info = kzalloc(sizeof(*trig_info), GFP_KERNEL);
if (!trig_info) {
ret = -ENOMEM;
- goto error_put_trigger;
+ goto error_free_trigger;
}
iio_trigger_set_drvdata(trig, trig_info);
trig_info->irq = irq;
@@ -83,8 +83,8 @@ error_release_irq:
free_irq(irq, trig);
error_free_trig_info:
kfree(trig_info);
-error_put_trigger:
- iio_trigger_put(trig);
+error_free_trigger:
+ iio_trigger_free(trig);
error_ret:
return ret;
}
@@ -99,7 +99,7 @@ static int iio_interrupt_trigger_remove(
iio_trigger_unregister(trig);
free_irq(trig_info->irq, trig);
kfree(trig_info);
- iio_trigger_put(trig);
+ iio_trigger_free(trig);
return 0;
}
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -173,7 +173,7 @@ static int iio_sysfs_trigger_probe(int i
return 0;
out2:
- iio_trigger_put(t->trig);
+ iio_trigger_free(t->trig);
free_t:
kfree(t);
out1:
--- a/drivers/staging/iio/trigger/iio-trig-bfin-timer.c
+++ b/drivers/staging/iio/trigger/iio-trig-bfin-timer.c
@@ -258,7 +258,7 @@ out_free_irq:
out1:
iio_trigger_unregister(st->trig);
out:
- iio_trigger_put(st->trig);
+ iio_trigger_free(st->trig);
return ret;
}
@@ -271,7 +271,7 @@ static int iio_bfin_tmr_trigger_remove(s
peripheral_free(st->t->pin);
free_irq(st->irq, st);
iio_trigger_unregister(st->trig);
- iio_trigger_put(st->trig);
+ iio_trigger_free(st->trig);
return 0;
}
Patches currently in stable-queue which might be from amsfield22(a)gmail.com are
queue-3.18/iio-trigger-free-trigger-resource-correctly.patch
This is a note to let you know that I've just added the patch titled
IB/ipoib: Change list_del to list_del_init in the tx object
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-ipoib-change-list_del-to-list_del_init-in-the-tx-object.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Feras Daoud <ferasda(a)mellanox.com>
Date: Wed, 28 Dec 2016 14:47:28 +0200
Subject: IB/ipoib: Change list_del to list_del_init in the tx object
From: Feras Daoud <ferasda(a)mellanox.com>
[ Upstream commit 27d41d29c7f093f6f77843624fbb080c1b4a8b9c ]
Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function
belong to different work queues, they can run in parallel.
In this case if ipoib_cm_tx_reap calls list_del and release the
lock, ipoib_cm_tx_start may acquire it and call list_del_init
on the already deleted object.
Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem.
Fixes: 839fcaba355a ("IPoIB: Connected mode experimental support")
Signed-off-by: Feras Daoud <ferasda(a)mellanox.com>
Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com>
Reviewed-by: Alex Vesker <valex(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia(a)oracle.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1362,7 +1362,7 @@ static void ipoib_cm_tx_reap(struct work
while (!list_empty(&priv->cm.reap_list)) {
p = list_entry(priv->cm.reap_list.next, typeof(*p), list);
- list_del(&p->list);
+ list_del_init(&p->list);
spin_unlock_irqrestore(&priv->lock, flags);
netif_tx_unlock_bh(dev);
ipoib_cm_tx_destroy(p);
Patches currently in stable-queue which might be from ferasda(a)mellanox.com are
queue-3.18/ib-ipoib-change-list_del-to-list_del_init-in-the-tx-object.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: Add vendor prefix for LEGO
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dt-bindings-add-vendor-prefix-for-lego.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: David Lechner <david(a)lechnology.com>
Date: Fri, 13 Jan 2017 13:03:39 -0600
Subject: dt-bindings: Add vendor prefix for LEGO
From: David Lechner <david(a)lechnology.com>
[ Upstream commit 7dcc31e2e68a386a29070384b51683ece80982bf ]
Add a vendor prefix for LEGO Systems A/S
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -83,6 +83,7 @@ karo Ka-Ro electronics GmbH
keymile Keymile GmbH
lacie LaCie
lantiq Lantiq Semiconductor
+lego LEGO Systems A/S
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-3.18/dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-3.18/dt-bindings-add-vendor-prefix-for-lego.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: David Lechner <david(a)lechnology.com>
Date: Fri, 13 Jan 2017 13:03:40 -0600
Subject: dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
From: David Lechner <david(a)lechnology.com>
[ Upstream commit 21078ab174c99885ca83a5c32db0d33b1617745e ]
This adds the board level device tree specification for LEGO MINDSTORMS EV3
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++
1 file changed, 4 insertions(+)
--- a/Documentation/devicetree/bindings/arm/davinci.txt
+++ b/Documentation/devicetree/bindings/arm/davinci.txt
@@ -9,6 +9,10 @@ EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
+LEGO MINDSTORMS EV3 (AM1808 based)
+Required root node properties:
+ - compatible = "lego,ev3", "ti,da850";
+
Generic DaVinci Boards
----------------------
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-3.18/dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-3.18/dt-bindings-add-vendor-prefix-for-lego.patch
This is a note to let you know that I've just added the patch titled
drm: drm_minor_register(): Clean up debugfs on failure
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-drm_minor_register-clean-up-debugfs-on-failure.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Noralf Trønnes <noralf(a)tronnes.org>
Date: Thu, 26 Jan 2017 23:56:04 +0100
Subject: drm: drm_minor_register(): Clean up debugfs on failure
From: Noralf Trønnes <noralf(a)tronnes.org>
[ Upstream commit a67834f8bfa1e2f48bb27d07b9a552ba7c3af82a ]
Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.
Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -320,7 +320,7 @@ static int drm_minor_register(struct drm
ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
if (ret) {
DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
- return ret;
+ goto err_debugfs;
}
ret = device_add(minor->kdev);
Patches currently in stable-queue which might be from noralf(a)tronnes.org are
queue-3.18/drm-drm_minor_register-clean-up-debugfs-on-failure.patch
This is a note to let you know that I've just added the patch titled
ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Fri, 20 Jan 2017 12:13:19 -0800
Subject: ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ]
We have more than four uarts on some SoCs and that can cause
noise with errors while booting.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -169,6 +169,7 @@ CONFIG_INPUT_TWL4030_PWRBUTTON=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
+CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-3.18/arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: imx53-qsb-common: fix FEC pinmux config
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 10:19:57 CET 2017
From: Patrick Bruenn <p.bruenn(a)beckhoff.com>
Date: Wed, 25 Jan 2017 06:25:48 +0100
Subject: ARM: dts: imx53-qsb-common: fix FEC pinmux config
From: Patrick Bruenn <p.bruenn(a)beckhoff.com>
[ Upstream commit 8b649e426336d7d4800ff9c82858328f4215ba01 ]
The pinmux configuration in device tree was different from manual
muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c
All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the
bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the
kernel tree, so it seems to be better to have the correct pinmuxing in
our files, too.
Signed-off-by: Patrick Bruenn <p.bruenn(a)beckhoff.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
+ MX53_PAD_FEC_MDC__FEC_MDC 0x4
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
>;
};
Patches currently in stable-queue which might be from p.bruenn(a)beckhoff.com are
queue-3.18/arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
crypto_ahash_import() may be called either after
crypto_ahash_init() or without such call. Right now
we always internally call init() as part of
import(), thus leaking memory and mappings if the
user has already called init() herself.
Fix this by only calling init() internally if the
state is not already initialized.
Fixes: commit 454527d0d94f ("staging: ccree: fix hash import/export")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com>
---
drivers/staging/ccree/ssi_hash.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index d79090e..1799d3f 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1778,9 +1778,12 @@ static int ssi_ahash_import(struct ahash_request *req, const void *in)
}
in += sizeof(u32);
- rc = ssi_hash_init(state, ctx);
- if (rc)
- goto out;
+ /* call init() to allocate bufs if the user hasn't */
+ if (!state->digest_buff) {
+ rc = ssi_hash_init(state, ctx);
+ if (rc)
+ goto out;
+ }
dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
ctx->inter_digestsize, DMA_BIDIRECTIONAL);
--
2.7.4
This is a note to let you know that I've just added the patch titled
xen/netback: set default upper limit of tx/rx queues to 8
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Juergen Gross <jgross(a)suse.com>
Date: Tue, 10 Jan 2017 14:32:52 +0100
Subject: xen/netback: set default upper limit of tx/rx queues to 8
From: Juergen Gross <jgross(a)suse.com>
[ Upstream commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ]
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module parameter if required.
Signed-off-by: Juergen Gross <jgross(a)suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netback/netback.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -67,6 +67,7 @@ module_param(rx_drain_timeout_msecs, uin
unsigned int rx_stall_timeout_msecs = 60000;
module_param(rx_stall_timeout_msecs, uint, 0444);
+#define MAX_QUEUES_DEFAULT 8
unsigned int xenvif_max_queues;
module_param_named(max_queues, xenvif_max_queues, uint, 0644);
MODULE_PARM_DESC(max_queues,
@@ -1626,11 +1627,12 @@ static int __init netback_init(void)
if (!xen_domain())
return -ENODEV;
- /* Allow as many queues as there are CPUs if user has not
+ /* Allow as many queues as there are CPUs but max. 8 if user has not
* specified a value.
*/
if (xenvif_max_queues == 0)
- xenvif_max_queues = num_online_cpus();
+ xenvif_max_queues = min_t(unsigned int, MAX_QUEUES_DEFAULT,
+ num_online_cpus());
if (fatal_skb_slots < XEN_NETBK_LEGACY_SLOTS_MAX) {
pr_info("fatal_skb_slots too small (%d), bump it to XEN_NETBK_LEGACY_SLOTS_MAX (%d)\n",
Patches currently in stable-queue which might be from jgross(a)suse.com are
queue-4.9/xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.patch
This is a note to let you know that I've just added the patch titled
wcn36xx: Don't use the destroyed hal_mutex
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
wcn36xx-don-t-use-the-destroyed-hal_mutex.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Date: Wed, 11 Jan 2017 16:32:21 +0200
Subject: wcn36xx: Don't use the destroyed hal_mutex
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
[ Upstream commit d53628882255481b710641dd0118fbd80af6e983 ]
ieee80211_unregister_hw() might invoke operations to stop the interface,
that uses the hal_mutex. So don't destroy it until after we're done
using it.
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/wcn36xx/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1165,11 +1165,12 @@ static int wcn36xx_remove(struct platfor
wcn36xx_dbg(WCN36XX_DBG_MAC, "platform remove\n");
release_firmware(wcn->nv);
- mutex_destroy(&wcn->hal_mutex);
ieee80211_unregister_hw(hw);
iounmap(wcn->dxe_base);
iounmap(wcn->ccu_base);
+
+ mutex_destroy(&wcn->hal_mutex);
ieee80211_free_hw(hw);
return 0;
Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are
queue-4.9/wcn36xx-don-t-use-the-destroyed-hal_mutex.patch
This is a note to let you know that I've just added the patch titled
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: "Maciej W. Rozycki" <macro(a)linux-mips.org>
Date: Mon, 30 Jan 2017 17:39:48 +0100
Subject: video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
From: "Maciej W. Rozycki" <macro(a)linux-mips.org>
[ Upstream commit 879e5a0df626f39cbb3c61bb90373e56d67012c4 ]
Fix:
WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor()
The function pmagbafb_probe()
references the function __init pmagbafb_erase_cursor().
This is often because pmagbafb_probe lacks a __init
annotation or the annotation of pmagbafb_erase_cursor is wrong.
-- a fallout from a missed update from commit 9625b51350cc ("VIDEO:
PMAG-BA: Fix section mismatch") and then commit 48c68c4f1b54 ("Drivers:
video: remove __dev* attributes.")
Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/pmag-ba-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/pmag-ba-fb.c
+++ b/drivers/video/fbdev/pmag-ba-fb.c
@@ -129,7 +129,7 @@ static struct fb_ops pmagbafb_ops = {
/*
* Turn the hardware cursor off.
*/
-static void __init pmagbafb_erase_cursor(struct fb_info *info)
+static void pmagbafb_erase_cursor(struct fb_info *info)
{
struct pmagbafb_par *par = info->par;
Patches currently in stable-queue which might be from macro(a)linux-mips.org are
queue-4.9/video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.patch
This is a note to let you know that I've just added the patch titled
usb: hcd: initialize hcd->flags to 0 when rm hcd
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: William wu <wulf(a)rock-chips.com>
Date: Fri, 13 Jan 2017 11:04:22 +0800
Subject: usb: hcd: initialize hcd->flags to 0 when rm hcd
From: William wu <wulf(a)rock-chips.com>
[ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ]
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.
[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160
[173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28
[173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0
[173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8
[173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c
[173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c
[173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124
[173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44
[173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc
[173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
...
[173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8
[173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc
[173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94
[173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc
[173.604607] [<0000000000b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [<ffffffc000642084>] usb_hcd_irq
[173.604673] Disabling IRQ #228
Signed-off-by: William wu <wulf(a)rock-chips.com>
Acked-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hcd.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -3023,6 +3023,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
usb_put_invalidate_rhdev(hcd);
+ hcd->flags = 0;
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
Patches currently in stable-queue which might be from wulf(a)rock-chips.com are
queue-4.9/usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.patch
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Fix register offsets for the IRDA serial port
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
serial-sh-sci-fix-register-offsets-for-the-irda-serial-port.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Date: Wed, 11 Jan 2017 16:43:32 +0200
Subject: serial: sh-sci: Fix register offsets for the IRDA serial port
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
[ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ]
Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 -
drivers/tty/serial/sh-sci.c | 17 ++++++++---------
2 files changed, 8 insertions(+), 10 deletions(-)
--- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
+++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
@@ -165,7 +165,6 @@ static struct plat_sci_port scif2_platfo
.scscr = SCSCR_TE | SCSCR_RE,
.type = PORT_IRDA,
.ops = &sh770x_sci_port_ops,
- .regshift = 1,
};
static struct resource scif2_resources[] = {
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -193,18 +193,17 @@ static const struct plat_sci_reg sci_reg
},
/*
- * Common definitions for legacy IrDA ports, dependent on
- * regshift value.
+ * Common definitions for legacy IrDA ports.
*/
[SCIx_IRDA_REGTYPE] = {
[SCSMR] = { 0x00, 8 },
- [SCBRR] = { 0x01, 8 },
- [SCSCR] = { 0x02, 8 },
- [SCxTDR] = { 0x03, 8 },
- [SCxSR] = { 0x04, 8 },
- [SCxRDR] = { 0x05, 8 },
- [SCFCR] = { 0x06, 8 },
- [SCFDR] = { 0x07, 16 },
+ [SCBRR] = { 0x02, 8 },
+ [SCSCR] = { 0x04, 8 },
+ [SCxTDR] = { 0x06, 8 },
+ [SCxSR] = { 0x08, 16 },
+ [SCxRDR] = { 0x0a, 8 },
+ [SCFCR] = { 0x0c, 8 },
+ [SCFDR] = { 0x0e, 16 },
[SCTFDR] = sci_reg_invalid,
[SCRFDR] = sci_reg_invalid,
[SCSPTR] = sci_reg_invalid,
Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are
queue-4.9/serial-sh-sci-fix-register-offsets-for-the-irda-serial-port.patch
This is a note to let you know that I've just added the patch titled
sched/cputime, powerpc32: Fix stale scaled stime on context switch
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-cputime-powerpc32-fix-stale-scaled-stime-on-context-switch.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Frederic Weisbecker <fweisbec(a)gmail.com>
Date: Thu, 5 Jan 2017 18:11:41 +0100
Subject: sched/cputime, powerpc32: Fix stale scaled stime on context switch
From: Frederic Weisbecker <fweisbec(a)gmail.com>
[ Upstream commit 90d08ba2b9b4be4aeca6a5b5a4b09fbcde30194d ]
On context switch with powerpc32, the cputime is accumulated in the
thread_info struct. So the switching-in task must move forward its
start time snapshot to the current time in order to later compute the
delta spent in system mode.
This is what we do for the normal cputime by initializing the starttime
field to the value of the previous task's starttime which got freshly
updated.
But we are missing the update of the scaled cputime start time. As a
result we may be accounting too much scaled cputime later.
Fix this by initializing the scaled cputime the same way we do for
normal cputime.
Signed-off-by: Frederic Weisbecker <fweisbec(a)gmail.com>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Cc: Christian Borntraeger <borntraeger(a)de.ibm.com>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Cc: Michael Ellerman <mpe(a)ellerman.id.au>
Cc: Paul Mackerras <paulus(a)samba.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Stanislaw Gruszka <sgruszka(a)redhat.com>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: Wanpeng Li <wanpeng.li(a)hotmail.com>
Link: http://lkml.kernel.org/r/1483636310-6557-2-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -407,6 +407,7 @@ void arch_vtime_task_switch(struct task_
struct cpu_accounting_data *acct = get_accounting(current);
acct->starttime = get_accounting(prev)->starttime;
+ acct->startspurr = get_accounting(prev)->startspurr;
acct->system_time = 0;
acct->user_time = 0;
}
Patches currently in stable-queue which might be from fweisbec(a)gmail.com are
queue-4.9/sched-cputime-powerpc32-fix-stale-scaled-stime-on-context-switch.patch
This is a note to let you know that I've just added the patch titled
sched/core: Add missing update_rq_clock() call in sched_move_task()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-core-add-missing-update_rq_clock-call-in-sched_move_task.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Mon, 23 Jan 2017 16:05:55 +0100
Subject: sched/core: Add missing update_rq_clock() call in sched_move_task()
From: Peter Zijlstra <peterz(a)infradead.org>
[ Upstream commit 1b1d62254df0fe42a711eb71948f915918987790 ]
Bug was noticed via this warning:
WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80
rq->clock_update_flags < RQCF_ACT_SKIP
Modules linked in:
CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1
Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014
Call Trace:
dump_stack+0x4d/0x65
__warn+0xcb/0xf0
warn_slowpath_fmt+0x5f/0x80
detach_task_cfs_rq+0x8e8/0xb80
? allocate_cgrp_cset_links+0x59/0x80
task_change_group_fair+0x27/0x150
sched_change_group+0x48/0xf0
sched_move_task+0x53/0x150
cpu_cgroup_attach+0x36/0x70
cgroup_taskset_migrate+0x175/0x300
cgroup_migrate+0xab/0xd0
cgroup_attach_task+0xf0/0x190
__cgroup_procs_write+0x1ed/0x2f0
cgroup_procs_write+0x14/0x20
cgroup_file_write+0x3f/0x100
kernfs_fop_write+0x104/0x180
__vfs_write+0x37/0x140
vfs_write+0xb8/0x1b0
SyS_write+0x55/0xc0
do_syscall_64+0x61/0x170
entry_SYSCALL64_slow_path+0x25/0x25
Reported-by: Ingo Molnar <mingo(a)kernel.org>
Reported-by: Borislav Petkov <bp(a)alien8.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/core.c | 1 +
1 file changed, 1 insertion(+)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7961,6 +7961,7 @@ void sched_move_task(struct task_struct
struct rq *rq;
rq = task_rq_lock(tsk, &rf);
+ update_rq_clock(rq);
running = task_current(rq, tsk);
queued = task_on_rq_queued(tsk);
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.9/sched-core-add-missing-update_rq_clock-call-in-sched_move_task.patch
queue-4.9/sched-cputime-powerpc32-fix-stale-scaled-stime-on-context-switch.patch
This is a note to let you know that I've just added the patch titled
s390/topology: make "topology=off" parameter work
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
s390-topology-make-topology-off-parameter-work.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Thu, 29 Dec 2016 13:52:52 +0100
Subject: s390/topology: make "topology=off" parameter work
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
[ Upstream commit 68cc795d1933285705ced6d841ef66c00ce98cbe ]
The "topology=off" kernel parameter is supposed to prevent the kernel
to use hardware topology information to generate scheduling domains
etc.
For an unknown reason I implemented this in a very odd way back then:
instead of simply clearing the MACHINE_HAS_TOPOLOGY flag within the
lowcore I added a second variable which indicated that topology
information should not be used. This is more than suboptimal since it
partially doesn't work. For the fake NUMA case topology information
is still considered and scheduling domains will be created based on
this.
To fix this and to simplify the code get rid of the extra variable and
implement the "topology=off" case like it is done for other features.
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/kernel/early.c | 12 ++++++++++++
arch/s390/kernel/topology.c | 11 ++---------
2 files changed, 14 insertions(+), 9 deletions(-)
--- a/arch/s390/kernel/early.c
+++ b/arch/s390/kernel/early.c
@@ -363,6 +363,18 @@ static inline void save_vector_registers
#endif
}
+static int __init topology_setup(char *str)
+{
+ bool enabled;
+ int rc;
+
+ rc = kstrtobool(str, &enabled);
+ if (!rc && !enabled)
+ S390_lowcore.machine_flags &= ~MACHINE_HAS_TOPOLOGY;
+ return rc;
+}
+early_param("topology", topology_setup);
+
static int __init disable_vector_extension(char *str)
{
S390_lowcore.machine_flags &= ~MACHINE_FLAG_VX;
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -37,7 +37,6 @@ static void set_topology_timer(void);
static void topology_work_fn(struct work_struct *work);
static struct sysinfo_15_1_x *tl_info;
-static bool topology_enabled = true;
static DECLARE_WORK(topology_work, topology_work_fn);
/*
@@ -56,7 +55,7 @@ static cpumask_t cpu_group_map(struct ma
cpumask_t mask;
cpumask_copy(&mask, cpumask_of(cpu));
- if (!topology_enabled || !MACHINE_HAS_TOPOLOGY)
+ if (!MACHINE_HAS_TOPOLOGY)
return mask;
for (; info; info = info->next) {
if (cpumask_test_cpu(cpu, &info->mask))
@@ -71,7 +70,7 @@ static cpumask_t cpu_thread_map(unsigned
int i;
cpumask_copy(&mask, cpumask_of(cpu));
- if (!topology_enabled || !MACHINE_HAS_TOPOLOGY)
+ if (!MACHINE_HAS_TOPOLOGY)
return mask;
cpu -= cpu % (smp_cpu_mtid + 1);
for (i = 0; i <= smp_cpu_mtid; i++)
@@ -413,12 +412,6 @@ static const struct cpumask *cpu_drawer_
return &per_cpu(cpu_topology, cpu).drawer_mask;
}
-static int __init early_parse_topology(char *p)
-{
- return kstrtobool(p, &topology_enabled);
-}
-early_param("topology", early_parse_topology);
-
static struct sched_domain_topology_level s390_topology[] = {
{ cpu_thread_mask, cpu_smt_flags, SD_INIT_NAME(SMT) },
{ cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) },
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.9/s390-topology-make-topology-off-parameter-work.patch
queue-4.9/sched-cputime-powerpc32-fix-stale-scaled-stime-on-context-switch.patch
This is a note to let you know that I've just added the patch titled
s390/qeth: fix retrieval of vipa and proxy-arp addresses
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
s390-qeth-fix-retrieval-of-vipa-and-proxy-arp-addresses.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
Date: Thu, 12 Jan 2017 15:48:43 +0100
Subject: s390/qeth: fix retrieval of vipa and proxy-arp addresses
From: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
[ Upstream commit e48b9eaaa29a0a7d5da2df136b07eefa0180d584 ]
qeth devices in layer3 mode need a separate handling of vipa and proxy-arp
addresses. vipa and proxy-arp addresses processed by qeth can be read from
userspace. Introduced with commit 5f78e29ceebf ("qeth: optimize IP handling
in rx_mode callback") the retrieval of vipa and proxy-arp addresses is
broken, if more than one vipa or proxy-arp address are set.
The qeth code used local variable "int i" for 2 different purposes. This
patch now spends 2 separate local variables of type "int".
While touching these functions hash_for_each_safe() is converted to
hash_for_each(), since there is no removal of hash entries.
Signed-off-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
Reviewed-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Reference-ID: RQM 3524
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/net/qeth_l3_sys.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
--- a/drivers/s390/net/qeth_l3_sys.c
+++ b/drivers/s390/net/qeth_l3_sys.c
@@ -692,15 +692,15 @@ static ssize_t qeth_l3_dev_vipa_add_show
enum qeth_prot_versions proto)
{
struct qeth_ipaddr *ipaddr;
- struct hlist_node *tmp;
char addr_str[40];
+ int str_len = 0;
int entry_len; /* length of 1 entry string, differs between v4 and v6 */
- int i = 0;
+ int i;
entry_len = (proto == QETH_PROT_IPV4)? 12 : 40;
entry_len += 2; /* \n + terminator */
spin_lock_bh(&card->ip_lock);
- hash_for_each_safe(card->ip_htable, i, tmp, ipaddr, hnode) {
+ hash_for_each(card->ip_htable, i, ipaddr, hnode) {
if (ipaddr->proto != proto)
continue;
if (ipaddr->type != QETH_IP_TYPE_VIPA)
@@ -708,16 +708,17 @@ static ssize_t qeth_l3_dev_vipa_add_show
/* String must not be longer than PAGE_SIZE. So we check if
* string length gets near PAGE_SIZE. Then we can savely display
* the next IPv6 address (worst case, compared to IPv4) */
- if ((PAGE_SIZE - i) <= entry_len)
+ if ((PAGE_SIZE - str_len) <= entry_len)
break;
qeth_l3_ipaddr_to_string(proto, (const u8 *)&ipaddr->u,
addr_str);
- i += snprintf(buf + i, PAGE_SIZE - i, "%s\n", addr_str);
+ str_len += snprintf(buf + str_len, PAGE_SIZE - str_len, "%s\n",
+ addr_str);
}
spin_unlock_bh(&card->ip_lock);
- i += snprintf(buf + i, PAGE_SIZE - i, "\n");
+ str_len += snprintf(buf + str_len, PAGE_SIZE - str_len, "\n");
- return i;
+ return str_len;
}
static ssize_t qeth_l3_dev_vipa_add4_show(struct device *dev,
@@ -854,15 +855,15 @@ static ssize_t qeth_l3_dev_rxip_add_show
enum qeth_prot_versions proto)
{
struct qeth_ipaddr *ipaddr;
- struct hlist_node *tmp;
char addr_str[40];
+ int str_len = 0;
int entry_len; /* length of 1 entry string, differs between v4 and v6 */
- int i = 0;
+ int i;
entry_len = (proto == QETH_PROT_IPV4)? 12 : 40;
entry_len += 2; /* \n + terminator */
spin_lock_bh(&card->ip_lock);
- hash_for_each_safe(card->ip_htable, i, tmp, ipaddr, hnode) {
+ hash_for_each(card->ip_htable, i, ipaddr, hnode) {
if (ipaddr->proto != proto)
continue;
if (ipaddr->type != QETH_IP_TYPE_RXIP)
@@ -870,16 +871,17 @@ static ssize_t qeth_l3_dev_rxip_add_show
/* String must not be longer than PAGE_SIZE. So we check if
* string length gets near PAGE_SIZE. Then we can savely display
* the next IPv6 address (worst case, compared to IPv4) */
- if ((PAGE_SIZE - i) <= entry_len)
+ if ((PAGE_SIZE - str_len) <= entry_len)
break;
qeth_l3_ipaddr_to_string(proto, (const u8 *)&ipaddr->u,
addr_str);
- i += snprintf(buf + i, PAGE_SIZE - i, "%s\n", addr_str);
+ str_len += snprintf(buf + str_len, PAGE_SIZE - str_len, "%s\n",
+ addr_str);
}
spin_unlock_bh(&card->ip_lock);
- i += snprintf(buf + i, PAGE_SIZE - i, "\n");
+ str_len += snprintf(buf + str_len, PAGE_SIZE - str_len, "\n");
- return i;
+ return str_len;
}
static ssize_t qeth_l3_dev_rxip_add4_show(struct device *dev,
Patches currently in stable-queue which might be from ubraun(a)linux.vnet.ibm.com are
queue-4.9/s390-qeth-fix-retrieval-of-vipa-and-proxy-arp-addresses.patch
queue-4.9/s390-qeth-issue-startlan-as-first-ipa-command.patch
This is a note to let you know that I've just added the patch titled
rt2800usb: mark tx failure on timeout
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rt2800usb-mark-tx-failure-on-timeout.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Stanislaw Gruszka <sgruszka(a)redhat.com>
Date: Fri, 6 Jan 2017 14:05:16 +0100
Subject: rt2800usb: mark tx failure on timeout
From: Stanislaw Gruszka <sgruszka(a)redhat.com>
[ Upstream commit 1701221696764b6861d0ee66850812a8900b9b9b ]
If we do not get TX status in reasonable time, we most likely fail to
send frame hence mark it as so.
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -646,10 +646,9 @@ static void rt2800usb_txdone_nostatus(st
!test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
break;
- if (test_bit(ENTRY_DATA_IO_FAILED, &entry->flags))
+ if (test_bit(ENTRY_DATA_IO_FAILED, &entry->flags) ||
+ rt2800usb_entry_txstatus_timeout(entry))
rt2x00lib_txdone_noinfo(entry, TXDONE_FAILURE);
- else if (rt2800usb_entry_txstatus_timeout(entry))
- rt2x00lib_txdone_noinfo(entry, TXDONE_UNKNOWN);
else
break;
}
Patches currently in stable-queue which might be from sgruszka(a)redhat.com are
queue-4.9/rt2800usb-mark-tx-failure-on-timeout.patch
queue-4.9/sched-cputime-powerpc32-fix-stale-scaled-stime-on-context-switch.patch
This is a note to let you know that I've just added the patch titled
powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-corenet-explicitly-disable-the-sdhc-controller-on-kmcoge4.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Valentin Longchamp <valentin.longchamp(a)keymile.com>
Date: Thu, 15 Dec 2016 14:22:26 +0100
Subject: powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
From: Valentin Longchamp <valentin.longchamp(a)keymile.com>
[ Upstream commit a674c7d470bb47e82f4eb1fa944eadeac2f6bbaf ]
It is not implemented on the kmcoge4 hardware and if not disabled it
leads to error messages with the corenet32_smp_defconfig.
Signed-off-by: Valentin Longchamp <valentin.longchamp(a)keymile.com>
Signed-off-by: Scott Wood <oss(a)buserror.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
@@ -83,6 +83,10 @@
};
};
+ sdhc@114000 {
+ status = "disabled";
+ };
+
i2c@119000 {
status = "disabled";
};
Patches currently in stable-queue which might be from valentin.longchamp(a)keymile.com are
queue-4.9/powerpc-corenet-explicitly-disable-the-sdhc-controller-on-kmcoge4.patch
This is a note to let you know that I've just added the patch titled
PM / OPP: Error out on failing to add static OPPs for v1 bindings
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pm-opp-error-out-on-failing-to-add-static-opps-for-v1-bindings.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 9 09:48:01 CET 2017
From: Viresh Kumar <viresh.kumar(a)linaro.org>
Date: Mon, 2 Jan 2017 14:40:58 +0530
Subject: PM / OPP: Error out on failing to add static OPPs for v1 bindings
From: Viresh Kumar <viresh.kumar(a)linaro.org>
[ Upstream commit 04a86a84c42ca18f37ab446127dc619b41dd3b23 ]
The code adding static OPPs for V2 bindings already does so. Make the V1
bindings specific code behave the same.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Reviewed-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/power/opp/of.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -386,7 +386,7 @@ static int _of_add_opp_table_v1(struct d
{
const struct property *prop;
const __be32 *val;
- int nr;
+ int nr, ret;
prop = of_find_property(dev->of_node, "operating-points", NULL);
if (!prop)
@@ -409,9 +409,13 @@ static int _of_add_opp_table_v1(struct d
unsigned long freq = be32_to_cpup(val++) * 1000;
unsigned long volt = be32_to_cpup(val++);
- if (_opp_add_v1(dev, freq, volt, false))
- dev_warn(dev, "%s: Failed to add OPP %ld\n",
- __func__, freq);
+ ret = _opp_add_v1(dev, freq, volt, false);
+ if (ret) {
+ dev_err(dev, "%s: Failed to add OPP %ld (%d)\n",
+ __func__, freq, ret);
+ dev_pm_opp_of_remove_table(dev);
+ return ret;
+ }
nr -= 2;
}
Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are
queue-4.9/pm-opp-error-out-on-failing-to-add-static-opps-for-v1-bindings.patch