- Linux-stable-mirror - lists.linaro.org

Patch "Input: ar1021_i2c - fix too long name in driver's device table" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: ar1021_i2c - fix too long name in driver's device table 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-ar1021_i2c-fix-too-long-name-in-driver-s-device-table.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 Mar 22 15:16:04 CET 2018 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Mon, 12 Dec 2016 15:32:57 -0800 Subject: Input: ar1021_i2c - fix too long name in driver's device table From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> [ Upstream commit 95123fc43560d6f4a60e74f72836e63cd8848f76 ] The name field in structure i2c_device_id is 20 characters, and we expect it to be NULL-terminated, however we are trying to stuff it with 21 bytes and thus NULL-terminator is lost. This causes issues when one creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C", and automatic module loading by alias does not work as result. The -I2C suffix in the device name is superfluous, we know what bus we are dealing with, so let's drop it. Also, no other driver uses capitals, and the manufacturer name is normally not included, except in very rare cases of incompatible name collisions. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211 Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen") Reviewed-By: Christian Gmeiner <christian.gmeiner(a)gmail.com> Tested-by: Martin Kepplinger <martin.kepplinger(a)ginzinger.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/touchscreen/ar1021_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/touchscreen/ar1021_i2c.c +++ b/drivers/input/touchscreen/ar1021_i2c.c @@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_res static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume); static const struct i2c_device_id ar1021_i2c_id[] = { - { "MICROCHIP_AR1021_I2C", 0 }, + { "ar1021", 0 }, { }, }; MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id); Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-3.18/input-ar1021_i2c-fix-too-long-name-in-driver-s-device-table.patch

7 years, 6 months

1
0
0 0

Patch "IB/ipoib: Update broadcast object if PKey value was changed in index 0" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Update broadcast object if PKey value was changed in index 0 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-update-broadcast-object-if-pkey-value-was-changed-in-index-0.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 Mar 22 15:16:04 CET 2018 From: Feras Daoud <ferasda(a)mellanox.com> Date: Sun, 19 Mar 2017 11:18:54 +0200 Subject: IB/ipoib: Update broadcast object if PKey value was changed in index 0 From: Feras Daoud <ferasda(a)mellanox.com> [ Upstream commit 9a9b8112699d78e7f317019b37f377e90023f3ed ] Update the broadcast address in the priv->broadcast object when the Pkey value changes in index 0, otherwise the multicast GID value will keep the previous value of the PKey, and will not be updated. This leads to interface state down because the interface will keep the old PKey value. For example, in SR-IOV environment, if the PF changes the value of PKey index 0 for one of the VFs, then the VF receives PKey change event that triggers heavy flush. This flush calls update_parent_pkey that update the broadcast object and its relevant members. If in this case the multicast GID will not be updated, the interface state will be down. Fixes: c2904141696e ("IPoIB: Fix pkey change flow for virtualization environments") 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> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c @@ -955,6 +955,19 @@ static inline int update_parent_pkey(str */ priv->dev->broadcast[8] = priv->pkey >> 8; priv->dev->broadcast[9] = priv->pkey & 0xff; + + /* + * Update the broadcast address in the priv->broadcast object, + * in case it already exists, otherwise no one will do that. + */ + if (priv->broadcast) { + spin_lock_irq(&priv->lock); + memcpy(priv->broadcast->mcmember.mgid.raw, + priv->dev->broadcast + 4, + sizeof(union ib_gid)); + spin_unlock_irq(&priv->lock); + } + return 0; } Patches currently in stable-queue which might be from ferasda(a)mellanox.com are queue-3.18/ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch

7 years, 6 months

1
0
0 0

Patch "IB/ipoib: Avoid memory leak if the SA returns a different DGID" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Avoid memory leak if the SA returns a different DGID 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-avoid-memory-leak-if-the-sa-returns-a-different-dgid.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 Mar 22 15:16:04 CET 2018 From: Erez Shitrit <erezsh(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:53 +0200 Subject: IB/ipoib: Avoid memory leak if the SA returns a different DGID From: Erez Shitrit <erezsh(a)mellanox.com> [ Upstream commit 439000892ee17a9c92f1e4297818790ef8bb4ced ] The ipoib path database is organized around DGIDs from the LLADDR, but the SA is free to return a different GID when asked for path. This causes a bug because the SA's modified DGID is copied into the database key, even though it is no longer the correct lookup key, causing a memory leak and other malfunctions. Ensure the database key does not change after the SA query completes. Demonstration of the bug is as follows ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it creates new record in the DB with that gid as a key, and issues a new request to the SM. Now, the SM from some reason returns path-record with other SGID (for example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local subnet prefix) now ipoib will overwrite the current entry with the new one, and if new request to the original GID arrives ipoib will not find it in the DB (was overwritten) and will create new record that in its turn will also be overwritten by the response from the SM, and so on till the driver eats all the device memory. Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -488,6 +488,22 @@ static void path_rec_completion(int stat spin_lock_irqsave(&priv->lock, flags); if (!IS_ERR_OR_NULL(ah)) { + /* + * pathrec.dgid is used as the database key from the LLADDR, + * it must remain unchanged even if the SA returns a different + * GID to use in the AH. + */ + if (memcmp(pathrec->dgid.raw, path->pathrec.dgid.raw, + sizeof(union ib_gid))) { + ipoib_dbg( + priv, + "%s got PathRec for gid %pI6 while asked for %pI6\n", + dev->name, pathrec->dgid.raw, + path->pathrec.dgid.raw); + memcpy(pathrec->dgid.raw, path->pathrec.dgid.raw, + sizeof(union ib_gid)); + } + path->pathrec = *pathrec; old_ah = path->ah; Patches currently in stable-queue which might be from erezsh(a)mellanox.com are queue-3.18/ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch queue-3.18/ib-ipoib-avoid-memory-leak-if-the-sa-returns-a-different-dgid.patch

7 years, 6 months

1
0
0 0

Patch "ia64: fix module loading for gcc-5.4" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ia64: fix module loading for gcc-5.4 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: ia64-fix-module-loading-for-gcc-5.4.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 Mar 22 15:16:04 CET 2018 From: Sergei Trofimovich <slyfox(a)gentoo.org> Date: Mon, 1 May 2017 11:51:55 -0700 Subject: ia64: fix module loading for gcc-5.4 From: Sergei Trofimovich <slyfox(a)gentoo.org> [ Upstream commit a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ] Starting from gcc-5.4+ gcc generates MLX instructions in more cases to refer local symbols: https://gcc.gnu.org/PR60465 That caused ia64 module loader to choke on such instructions: fuse: invalid slot number 1 for IMM64 The Linux kernel used to handle only case where relocation pointed to slot=2 instruction in the bundle. That limitation was fixed in linux by commit 9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler") See http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433 This change lifts the slot=2 restriction from the kernel module loader. Tested on 'fuse' and 'btrfs' kernel modules. Cc: Markus Elfring <elfring(a)users.sourceforge.net> Cc: H J Lu <hjl.tools(a)gmail.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Bug: https://bugs.gentoo.org/601014 Tested-by: Émeric MASCHINO <emeric.maschino(a)gmail.com> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/ia64/kernel/module.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/ia64/kernel/module.c +++ b/arch/ia64/kernel/module.c @@ -153,7 +153,7 @@ slot (const struct insn *insn) static int apply_imm64 (struct module *mod, struct insn *insn, uint64_t val) { - if (slot(insn) != 2) { + if (slot(insn) != 1 && slot(insn) != 2) { printk(KERN_ERR "%s: invalid slot number %d for IMM64\n", mod->name, slot(insn)); return 0; @@ -165,7 +165,7 @@ apply_imm64 (struct module *mod, struct static int apply_imm60 (struct module *mod, struct insn *insn, uint64_t val) { - if (slot(insn) != 2) { + if (slot(insn) != 1 && slot(insn) != 2) { printk(KERN_ERR "%s: invalid slot number %d for IMM60\n", mod->name, slot(insn)); return 0; Patches currently in stable-queue which might be from slyfox(a)gentoo.org are queue-3.18/ia64-fix-module-loading-for-gcc-5.4.patch

7 years, 6 months

1
0
0 0

Patch "i2c: i2c-scmi: add a MS HID" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i2c: i2c-scmi: add a MS HID 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: i2c-i2c-scmi-add-a-ms-hid.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 Mar 22 15:16:04 CET 2018 From: Edgar Cherkasov <echerkasov(a)dev.rtsoft.ru> Date: Tue, 4 Apr 2017 19:18:27 +0300 Subject: i2c: i2c-scmi: add a MS HID From: Edgar Cherkasov <echerkasov(a)dev.rtsoft.ru> [ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ] Description of the problem: - i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM"; - the fist HID (SMBUS01) is clearly defined in "SMBus Control Method Interface Specification, version 1.0": "Each device must specify 'SMBUS01' as its _HID and use a unique _UID value"; - unfortunately, BIOS vendors (like AMI) seem to ignore this requirement and implement "SMB0001" HID instead of "SMBUS01"; - I speculate that they do this because only "SMB0001" is hard coded in Windows SMBus driver produced by Microsoft. This leads to following situation: - SMBus works out of box in Windows but not in Linux; - board vendors are forced to add correct "SMBUS01" HID to BIOS to make SMBus work in Linux. Moreover the same board vendors complain that tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier and produce errors. So they need to constantly patch the compiler for each new version of BIOS. As it is very unlikely that BIOS vendors implement a correct HID in future, I would propose to consider whether it is possible to work around the problem by adding MS HID to the Linux i2c-scmi driver. v2: move the definition of the new HID to the driver itself. Signed-off-by: Edgar Cherkasov <echerkasov(a)dev.rtsoft.ru> Signed-off-by: Michael Brunner <Michael.Brunner(a)kontron.com> Acked-by: Viktor Krasnov <vkrasnov(a)dev.rtsoft.ru> Reviewed-by: Jean Delvare <jdelvare(a)suse.de> Reviewed-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/i2c/busses/i2c-scmi.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/i2c/busses/i2c-scmi.c +++ b/drivers/i2c/busses/i2c-scmi.c @@ -18,6 +18,9 @@ #define ACPI_SMBUS_HC_CLASS "smbus" #define ACPI_SMBUS_HC_DEVICE_NAME "cmi" +/* SMBUS HID definition as supported by Microsoft Windows */ +#define ACPI_SMBUS_MS_HID "SMB0001" + ACPI_MODULE_NAME("smbus_cmi"); struct smbus_methods_t { @@ -51,6 +54,7 @@ static const struct smbus_methods_t ibm_ static const struct acpi_device_id acpi_smbus_cmi_ids[] = { {"SMBUS01", (kernel_ulong_t)&smbus_methods}, {ACPI_SMBUS_IBM_HID, (kernel_ulong_t)&ibm_smbus_methods}, + {ACPI_SMBUS_MS_HID, (kernel_ulong_t)&smbus_methods}, {"", 0} }; MODULE_DEVICE_TABLE(acpi, acpi_smbus_cmi_ids); Patches currently in stable-queue which might be from echerkasov(a)dev.rtsoft.ru are queue-3.18/i2c-i2c-scmi-add-a-ms-hid.patch

7 years, 6 months

1
0
0 0

Patch "HSI: ssi_protocol: double free in ssip_pn_xmit()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HSI: ssi_protocol: double free in ssip_pn_xmit() 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: hsi-ssi_protocol-double-free-in-ssip_pn_xmit.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 Mar 22 15:16:04 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Fri, 21 Apr 2017 13:39:09 +0300 Subject: HSI: ssi_protocol: double free in ssip_pn_xmit() From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 3026050179a3a9a6f5c892c414b5e36ecf092081 ] If skb_pad() fails then it frees skb and we don't need to free it again at the end of the function. Fixes: dc7bf5d7 ("HSI: Introduce driver for SSI Protocol") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Sebastian Reichel <sre(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hsi/clients/ssi_protocol.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/hsi/clients/ssi_protocol.c +++ b/drivers/hsi/clients/ssi_protocol.c @@ -976,7 +976,7 @@ static int ssip_pn_xmit(struct sk_buff * goto drop; /* Pad to 32-bits - FIXME: Revisit*/ if ((skb->len & 3) && skb_pad(skb, 4 - (skb->len & 3))) - goto drop; + goto inc_dropped; /* * Modem sends Phonet messages over SSI with its own endianess... @@ -1028,8 +1028,9 @@ static int ssip_pn_xmit(struct sk_buff * drop2: hsi_free_msg(msg); drop: - dev->stats.tx_dropped++; dev_kfree_skb(skb); +inc_dropped: + dev->stats.tx_dropped++; return 0; } Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-3.18/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-3.18/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-3.18/cifs-small-underflow-in-cnvrtdosunixtm.patch

7 years, 6 months

1
0
0 0

Patch "genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs 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: genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.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 Mar 22 15:16:04 CET 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sat, 15 Apr 2017 12:08:31 +0200 Subject: genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ] When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction flags get filled with the trigger type from the irq_data: if (!(new->flags & IRQF_TRIGGER_MASK)) new->flags |= irqd_get_trigger_type(&desc->irq_data); On the first setup_irq() the trigger type in irq_data is NONE when the above code executes, then the irq is started up for the first time and then the actual trigger type gets established, but that's too late to fix up new->flags. When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE its irqaction's triggertype gets set to the actual trigger type and the following check fails: if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK)) Resulting in the request_irq failing with -EBUSY even though both users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE Fix this by comparing the new irqaction's trigger type to the trigger type stored in the irq_data which correctly reflects the actual trigger type being used for the irq. Suggested-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Marc Zyngier <marc.zyngier(a)arm.com> Link: http://lkml.kernel.org/r/20170415100831.17073-1-hdegoede@redhat.com Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/irq/manage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1058,8 +1058,10 @@ __setup_irq(unsigned int irq, struct irq * set the trigger type must match. Also all must * agree on ONESHOT. */ + unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data); + if (!((old->flags & new->flags) & IRQF_SHARED) || - ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) || + (oldtype != (new->flags & IRQF_TRIGGER_MASK)) || ((old->flags ^ new->flags) & IRQF_ONESHOT)) goto mismatch; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-3.18/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-3.18/x86-i8259-export-legacy_pic-symbol.patch

7 years, 6 months

1
0
0 0

Patch "Fix driver usage of 128B WQEs when WQ_CREATE is V1." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Fix driver usage of 128B WQEs when WQ_CREATE is V1. 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: fix-driver-usage-of-128b-wqes-when-wq_create-is-v1.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 Mar 22 15:16:04 CET 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Fri, 21 Apr 2017 16:04:56 -0700 Subject: Fix driver usage of 128B WQEs when WQ_CREATE is V1. From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 3f247de750b8dd8f50a2c1390e2a1238790a9dff ] There are two versions of a structure for queue creation and setup that the driver shares with FW. The driver was only treating as version 0. Verify WQ_CREATE with 128B WQEs in V0 and V1. Code review of another bug showed the driver passing 128B WQEs and 8 pages in WQ CREATE and V0. Code inspection/instrumentation showed that the driver uses V0 in WQ_CREATE and if the caller passes queue->entry_size 128B, the driver sets the hdr_version to V1 so all is good. When I tested the V1 WQ_CREATE, the mailbox failed causing the driver to unload. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_sli.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -13469,6 +13469,9 @@ lpfc_wq_create(struct lpfc_hba *phba, st case LPFC_Q_CREATE_VERSION_1: bf_set(lpfc_mbx_wq_create_wqe_count, &wq_create->u.request_1, wq->entry_count); + bf_set(lpfc_mbox_hdr_version, &shdr->request, + LPFC_Q_CREATE_VERSION_1); + switch (wq->entry_size) { default: case 64: Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-3.18/fix-driver-usage-of-128b-wqes-when-wq_create-is-v1.patch

7 years, 6 months

1
0
0 0

Patch "e1000e: fix timing for 82579 Gigabit Ethernet controller" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: fix timing for 82579 Gigabit Ethernet controller 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: e1000e-fix-timing-for-82579-gigabit-ethernet-controller.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 Mar 22 15:16:04 CET 2018 From: Bernd Faust <berndfaust(a)gmail.com> Date: Thu, 16 Feb 2017 19:42:07 +0100 Subject: e1000e: fix timing for 82579 Gigabit Ethernet controller From: Bernd Faust <berndfaust(a)gmail.com> [ Upstream commit 5313eeccd2d7f486be4e5c7560e3e2be239ec8f7 ] After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost four times as big as before the kernel upgrade. The difference is that after the upgrade the driver sets the clock frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel confirmed that the correct frequency for this network adapter is 96MHz. Signed-off-by: Bernd Faust <berndfaust(a)gmail.com> Acked-by: Sasha Neftin <sasha.neftin(a)intel.com> Acked-by: Jacob Keller <jacob.e.keller(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -3507,6 +3507,12 @@ s32 e1000e_get_base_timinca(struct e1000 switch (hw->mac.type) { case e1000_pch2lan: + /* Stable 96MHz frequency */ + incperiod = INCPERIOD_96MHz; + incvalue = INCVALUE_96MHz; + shift = INCVALUE_SHIFT_96MHz; + adapter->cc.shift = shift + INCPERIOD_SHIFT_96MHz; + break; case e1000_pch_lpt: /* On I217, the clock frequency is 25MHz or 96MHz as * indicated by the System Clock Frequency Indication Patches currently in stable-queue which might be from berndfaust(a)gmail.com are queue-3.18/e1000e-fix-timing-for-82579-gigabit-ethernet-controller.patch

7 years, 6 months

1
0
0 0

Patch "drm/omap: DMM: Check for DMM readiness after successful transaction commit" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/omap: DMM: Check for DMM readiness after successful transaction commit 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-omap-dmm-check-for-dmm-readiness-after-successful-transaction-commit.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 Mar 22 15:16:04 CET 2018 From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Date: Fri, 29 Sep 2017 14:49:49 +0300 Subject: drm/omap: DMM: Check for DMM readiness after successful transaction commit From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> [ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ] Check the status of the DMM engine after it is reported that the transaction was completed as in rare cases the engine might not reached a working state. The wait_status() will print information in case the DMM is not reached the expected state and the dmm_txn_commit() will return with an error code to make sure that we are not continuing with a broken setup. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -280,7 +280,12 @@ static int dmm_txn_commit(struct dmm_txn msecs_to_jiffies(1)) <= 0) { dev_err(dmm->dev, "timed out waiting for done\n"); ret = -ETIMEDOUT; + goto cleanup; } + + /* Check the engine status before continue */ + ret = wait_status(engine, DMM_PATSTATUS_READY | + DMM_PATSTATUS_VALID | DMM_PATSTATUS_DONE); } cleanup: Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are queue-3.18/drm-omap-dmm-check-for-dmm-readiness-after-successful-transaction-commit.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror