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