commit e1bf1687740ce1a3598a1c5e452b852ff2190682 upstream.
This reverts commit 870190a9ec9075205c0fa795a09fa931694a3ff1.
It was not a good idea. The custom hash table was a much better
fit for this purpose.
A fast lookup is not essential, in fact for most cases there is no lookup
at all because original tuple is not taken and can be used as-is.
What needs to be fast is insertion and deletion.
rhlist removal however requires a rhlist walk.
We can have thousands of entries in such a list if source port/addresses
are reused for multiple flows, if this happens removal requests are so
expensive that deletions of a few thousand flows can take several
seconds(!).
The advantages that we got from rhashtable are:
1) table auto-sizing
2) multiple locks
1) would be nice to have, but it is not essential as we have at
most one lookup per new flow, so even a million flows in the bysource
table are not a problem compared to current deletion cost.
2) is easy to add to custom hash table.
I tried to add hlist_node to rhlist to speed up rhltable_remove but this
isn't doable without changing semantics. rhltable_remove_fast will
check that the to-be-deleted object is part of the table and that
requires a list walk that we want to avoid.
Furthermore, using hlist_node increases size of struct rhlist_head, which
in turn increases nf_conn size.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196821
Reported-by: Ivan Babrou <ibobrik(a)gmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
---
Hi Greg,
this is a 4.9.y backport of the same revert that already went into 4.13.y;
please consider applying this.
Note: you need to 'git cherry-pick 6e699867f84c0f358fed233fe6162173aca28e04'
first, else this won't apply (and cause crash if newly allocated conntrack is
dropped right away).
include/net/netfilter/nf_conntrack.h | 3 +-
include/net/netfilter/nf_nat.h | 1 -
net/netfilter/nf_nat_core.c | 134 +++++++++++++++--------------------
3 files changed, 57 insertions(+), 81 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index d9d52c020a70..9ae819e27940 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -17,7 +17,6 @@
#include <linux/bitops.h>
#include <linux/compiler.h>
#include <linux/atomic.h>
-#include <linux/rhashtable.h>
#include <linux/netfilter/nf_conntrack_tcp.h>
#include <linux/netfilter/nf_conntrack_dccp.h>
@@ -101,7 +100,7 @@ struct nf_conn {
possible_net_t ct_net;
#if IS_ENABLED(CONFIG_NF_NAT)
- struct rhlist_head nat_bysource;
+ struct hlist_node nat_bysource;
#endif
/* all members below initialized via memset */
u8 __nfct_init_offset[0];
diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h
index c327a431a6f3..02515f7ed4cc 100644
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -1,6 +1,5 @@
#ifndef _NF_NAT_H
#define _NF_NAT_H
-#include <linux/rhashtable.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netfilter/nf_nat.h>
#include <net/netfilter/nf_conntrack_tuple.h>
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index e9fcb58d4eba..624d6e4dcd5c 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -30,19 +30,17 @@
#include <net/netfilter/nf_conntrack_zones.h>
#include <linux/netfilter/nf_nat.h>
+static DEFINE_SPINLOCK(nf_nat_lock);
+
static DEFINE_MUTEX(nf_nat_proto_mutex);
static const struct nf_nat_l3proto __rcu *nf_nat_l3protos[NFPROTO_NUMPROTO]
__read_mostly;
static const struct nf_nat_l4proto __rcu **nf_nat_l4protos[NFPROTO_NUMPROTO]
__read_mostly;
-struct nf_nat_conn_key {
- const struct net *net;
- const struct nf_conntrack_tuple *tuple;
- const struct nf_conntrack_zone *zone;
-};
-
-static struct rhltable nf_nat_bysource_table;
+static struct hlist_head *nf_nat_bysource __read_mostly;
+static unsigned int nf_nat_htable_size __read_mostly;
+static unsigned int nf_nat_hash_rnd __read_mostly;
inline const struct nf_nat_l3proto *
__nf_nat_l3proto_find(u8 family)
@@ -121,17 +119,19 @@ int nf_xfrm_me_harder(struct net *net, struct sk_buff *skb, unsigned int family)
EXPORT_SYMBOL(nf_xfrm_me_harder);
#endif /* CONFIG_XFRM */
-static u32 nf_nat_bysource_hash(const void *data, u32 len, u32 seed)
+/* We keep an extra hash for each conntrack, for fast searching. */
+static inline unsigned int
+hash_by_src(const struct net *n, const struct nf_conntrack_tuple *tuple)
{
- const struct nf_conntrack_tuple *t;
- const struct nf_conn *ct = data;
+ unsigned int hash;
+
+ get_random_once(&nf_nat_hash_rnd, sizeof(nf_nat_hash_rnd));
- t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
/* Original src, to ensure we map it consistently if poss. */
+ hash = jhash2((u32 *)&tuple->src, sizeof(tuple->src) / sizeof(u32),
+ tuple->dst.protonum ^ nf_nat_hash_rnd ^ net_hash_mix(n));
- seed ^= net_hash_mix(nf_ct_net(ct));
- return jhash2((const u32 *)&t->src, sizeof(t->src) / sizeof(u32),
- t->dst.protonum ^ seed);
+ return reciprocal_scale(hash, nf_nat_htable_size);
}
/* Is this tuple already taken? (not by us) */
@@ -187,28 +187,6 @@ same_src(const struct nf_conn *ct,
t->src.u.all == tuple->src.u.all);
}
-static int nf_nat_bysource_cmp(struct rhashtable_compare_arg *arg,
- const void *obj)
-{
- const struct nf_nat_conn_key *key = arg->key;
- const struct nf_conn *ct = obj;
-
- if (!same_src(ct, key->tuple) ||
- !net_eq(nf_ct_net(ct), key->net) ||
- !nf_ct_zone_equal(ct, key->zone, IP_CT_DIR_ORIGINAL))
- return 1;
-
- return 0;
-}
-
-static struct rhashtable_params nf_nat_bysource_params = {
- .head_offset = offsetof(struct nf_conn, nat_bysource),
- .obj_hashfn = nf_nat_bysource_hash,
- .obj_cmpfn = nf_nat_bysource_cmp,
- .nelem_hint = 256,
- .min_size = 1024,
-};
-
/* Only called for SRC manip */
static int
find_appropriate_src(struct net *net,
@@ -219,26 +197,22 @@ find_appropriate_src(struct net *net,
struct nf_conntrack_tuple *result,
const struct nf_nat_range *range)
{
+ unsigned int h = hash_by_src(net, tuple);
const struct nf_conn *ct;
- struct nf_nat_conn_key key = {
- .net = net,
- .tuple = tuple,
- .zone = zone
- };
- struct rhlist_head *hl, *h;
-
- hl = rhltable_lookup(&nf_nat_bysource_table, &key,
- nf_nat_bysource_params);
- rhl_for_each_entry_rcu(ct, h, hl, nat_bysource) {
- nf_ct_invert_tuplepr(result,
- &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
- result->dst = tuple->dst;
-
- if (in_range(l3proto, l4proto, result, range))
- return 1;
+ hlist_for_each_entry_rcu(ct, &nf_nat_bysource[h], nat_bysource) {
+ if (same_src(ct, tuple) &&
+ net_eq(net, nf_ct_net(ct)) &&
+ nf_ct_zone_equal(ct, zone, IP_CT_DIR_ORIGINAL)) {
+ /* Copy source part from reply tuple. */
+ nf_ct_invert_tuplepr(result,
+ &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
+ result->dst = tuple->dst;
+
+ if (in_range(l3proto, l4proto, result, range))
+ return 1;
+ }
}
-
return 0;
}
@@ -411,6 +385,7 @@ nf_nat_setup_info(struct nf_conn *ct,
const struct nf_nat_range *range,
enum nf_nat_manip_type maniptype)
{
+ struct net *net = nf_ct_net(ct);
struct nf_conntrack_tuple curr_tuple, new_tuple;
struct nf_conn_nat *nat;
@@ -452,19 +427,16 @@ nf_nat_setup_info(struct nf_conn *ct,
}
if (maniptype == NF_NAT_MANIP_SRC) {
- struct nf_nat_conn_key key = {
- .net = nf_ct_net(ct),
- .tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
- .zone = nf_ct_zone(ct),
- };
- int err;
-
- err = rhltable_insert_key(&nf_nat_bysource_table,
- &key,
- &ct->nat_bysource,
- nf_nat_bysource_params);
- if (err)
- return NF_DROP;
+ unsigned int srchash;
+
+ srchash = hash_by_src(net,
+ &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+ spin_lock_bh(&nf_nat_lock);
+ /* nf_conntrack_alter_reply might re-allocate extension aera */
+ nat = nfct_nat(ct);
+ hlist_add_head_rcu(&ct->nat_bysource,
+ &nf_nat_bysource[srchash]);
+ spin_unlock_bh(&nf_nat_lock);
}
/* It's done. */
@@ -572,9 +544,10 @@ static int nf_nat_proto_clean(struct nf_conn *ct, void *data)
* Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack()
* will delete entry from already-freed table.
*/
+ spin_lock_bh(&nf_nat_lock);
+ hlist_del_rcu(&ct->nat_bysource);
ct->status &= ~IPS_NAT_DONE_MASK;
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ spin_unlock_bh(&nf_nat_lock);
/* don't delete conntrack. Although that would make things a lot
* simpler, we'd end up flushing all conntracks on nat rmmod.
@@ -699,9 +672,11 @@ EXPORT_SYMBOL_GPL(nf_nat_l3proto_unregister);
/* No one using conntrack by the time this called. */
static void nf_nat_cleanup_conntrack(struct nf_conn *ct)
{
- if (ct->status & IPS_SRC_NAT_DONE)
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ if (ct->status & IPS_SRC_NAT_DONE) {
+ spin_lock_bh(&nf_nat_lock);
+ hlist_del_rcu(&ct->nat_bysource);
+ spin_unlock_bh(&nf_nat_lock);
+ }
}
static struct nf_ct_ext_type nat_extend __read_mostly = {
@@ -836,13 +811,16 @@ static int __init nf_nat_init(void)
{
int ret;
- ret = rhltable_init(&nf_nat_bysource_table, &nf_nat_bysource_params);
- if (ret)
- return ret;
+ /* Leave them the same for the moment. */
+ nf_nat_htable_size = nf_conntrack_htable_size;
+
+ nf_nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size, 0);
+ if (!nf_nat_bysource)
+ return -ENOMEM;
ret = nf_ct_extend_register(&nat_extend);
if (ret < 0) {
- rhltable_destroy(&nf_nat_bysource_table);
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
printk(KERN_ERR "nf_nat_core: Unable to register extension\n");
return ret;
}
@@ -866,7 +844,7 @@ static int __init nf_nat_init(void)
return 0;
cleanup_extend:
- rhltable_destroy(&nf_nat_bysource_table);
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
nf_ct_extend_unregister(&nat_extend);
return ret;
}
@@ -886,8 +864,8 @@ static void __exit nf_nat_cleanup(void)
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
-
- rhltable_destroy(&nf_nat_bysource_table);
+ synchronize_net();
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
}
MODULE_LICENSE("GPL");
--
2.13.6
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: rc: sir_ir: detect presence of port
Author: Sean Young <sean(a)mess.org>
Date: Wed Nov 8 16:19:45 2017 -0500
Without this test, sir_ir clumsy claims resources for a device which
does not exist.
The 0-day kernel test robot reports the following errors (in a loop):
sir_ir sir_ir.0: Trapped in interrupt
genirq: Flags mismatch irq 4. 00000000 (ttyS0) vs. 00000000 (sir_ir)
When sir_ir is loaded with the default io and irq, the following happens:
- sir_ir claims irq 4
- user space opens /dev/ttyS0
- in serial8250_do_startup(), some setup is done for ttyS0, which causes
irq 4 to fire (in THRE test)
- sir_ir does not realise it was not for it, and spins until the "trapped
in interrupt"
- now serial driver calls setup_irq() and fails and we get the
"Flags mismatch" error.
There is no port present at 0x3e8 so simply check for the presence of a
port, as suggested by Linus.
Reported-by: kbuild test robot <fengguang.wu(a)intel.com>
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Cc: <stable(a)vger.kernel.org> # 4.12+
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/rc/sir_ir.c | 40 ++++++++++++++++++++++++++++++++++++----
1 file changed, 36 insertions(+), 4 deletions(-)
---
diff --git a/drivers/media/rc/sir_ir.c b/drivers/media/rc/sir_ir.c
index 76120664b700..9ee2c9196b4d 100644
--- a/drivers/media/rc/sir_ir.c
+++ b/drivers/media/rc/sir_ir.c
@@ -57,7 +57,7 @@ static void add_read_queue(int flag, unsigned long val);
static irqreturn_t sir_interrupt(int irq, void *dev_id);
static void send_space(unsigned long len);
static void send_pulse(unsigned long len);
-static void init_hardware(void);
+static int init_hardware(void);
static void drop_hardware(void);
/* Initialisation */
@@ -263,11 +263,36 @@ static void send_pulse(unsigned long len)
}
}
-static void init_hardware(void)
+static int init_hardware(void)
{
+ u8 scratch, scratch2, scratch3;
unsigned long flags;
spin_lock_irqsave(&hardware_lock, flags);
+
+ /*
+ * This is a simple port existence test, borrowed from the autoconfig
+ * function in drivers/tty/serial/8250/8250_port.c
+ */
+ scratch = sinp(UART_IER);
+ soutp(UART_IER, 0);
+#ifdef __i386__
+ outb(0xff, 0x080);
+#endif
+ scratch2 = sinp(UART_IER) & 0x0f;
+ soutp(UART_IER, 0x0f);
+#ifdef __i386__
+ outb(0x00, 0x080);
+#endif
+ scratch3 = sinp(UART_IER) & 0x0f;
+ soutp(UART_IER, scratch);
+ if (scratch2 != 0 || scratch3 != 0x0f) {
+ /* we fail, there's nothing here */
+ spin_unlock_irqrestore(&hardware_lock, flags);
+ pr_err("port existence test failed, cannot continue\n");
+ return -ENODEV;
+ }
+
/* reset UART */
outb(0, io + UART_MCR);
outb(0, io + UART_IER);
@@ -285,6 +310,8 @@ static void init_hardware(void)
/* turn on UART */
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2, io + UART_MCR);
spin_unlock_irqrestore(&hardware_lock, flags);
+
+ return 0;
}
static void drop_hardware(void)
@@ -334,14 +361,19 @@ static int sir_ir_probe(struct platform_device *dev)
pr_err("IRQ %d already in use.\n", irq);
return retval;
}
+
+ retval = init_hardware();
+ if (retval) {
+ del_timer_sync(&timerlist);
+ return retval;
+ }
+
pr_info("I/O port 0x%.4x, IRQ %d.\n", io, irq);
retval = devm_rc_register_device(&sir_ir_dev->dev, rcdev);
if (retval < 0)
return retval;
- init_hardware();
-
return 0;
}
Hi Mark,
On 15-11-2017 10:54, Mark Brown wrote:
> On Wed, Nov 15, 2017 at 02:45:45AM +0000, alexander.levin(a)verizon.com wrote:
>
>> We can no longer rely on the return value of
>> devm_snd_dmaengine_pcm_register(...) to check if the DMA
>> handle is declared in the DT.
>> Previously this check activated PIO mode but currently
>> dma_request_chan returns either a valid channel or -EPROBE_DEFER.
> So when did the corresponding change to the dmaengine API go in?
Looks like this was introduced in a8135d0d79e9 ("dmaengine: core:
Introduce new, universal API to request a channel") but looking
at soc-generic-dmaengine-pcm.c I see that this would never work
anyway because dmaengine_pcm_request_chan_of() also returns
either zero or -EPROBE_DEFER.
>
>> In order to activate PIO mode check instead if the interrupt
>> line is declared. This reflects better what is documented in
>> the DT bindings (see Documentation/devicetree/bindings/sound/
>> designware-i2s.txt).
>> Also, initialize use_pio variable which was never being set
>> causing PIO mode to never work.
> Though if PIO mode never worked presumably this isn't that urgent...
Yeah, and we also have this. Its my fault, I was using a
different tree for testing at the time. But if we could backport
this it would be nice because we and our clients use this PIO
driver in ARC AXS101 Development Platform. (A side note is that
the DT bindings were only recently introduced but I think its
more easier to add the bindings instead of fixing this driver ...).
Best Regards,
Jose Miguel Abreu
The snd_usb_copy_string_desc() retrieves the usb string corresponding to
the index number thought the usb_string(). And for NULL-terminated, insert
'0' by using the return value of usb_string() as the index of buffer to
hold the string.
The problem is that the usb_string() also returns the length of the string
read(>= 0), but it can also return a negative value, the error or status
value of usb_control_msg(). If iClockSource is '0' as shown below,
usb_string() will return -EINVAL. This will result in '0' being inserted
into buf[-22], and the following KASAN out-of-bound error message will be
output.
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 1
bmAttributes 0x07 Internal programmable Clock (synced to SOF)
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 0
To fix out-of-bound error, insert 0 only if the return value of
usb_string() is greater than 0.
==================================================================
BUG: KASAN: stack-out-of-bounds in parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
Write of size 1 at addr ffff88007e66735a by task systemd-udevd/18376
CPU: 0 PID: 18376 Comm: systemd-udevd Not tainted 4.13.0+ #3
Hardware name: LG Electronics 15N540-RFLGL/White Tip Mountain, BIOS 15N5
Call Trace:
dump_stack+0x63/0x8d
print_address_description+0x70/0x290
? parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
kasan_report+0x265/0x350
__asan_store1+0x4a/0x50
parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
? save_stack+0xb5/0xd0
? save_stack_trace+0x1b/0x20
? save_stack+0x46/0xd0
? kasan_kmalloc+0xad/0xe0
? kmem_cache_alloc_trace+0xff/0x230
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? usb_probe_interface+0x1f5/0x440
? driver_probe_device+0x3ed/0x660
? build_feature_ctl+0xb10/0xb10 [snd_usb_audio]
? save_stack_trace+0x1b/0x20
? init_object+0x69/0xa0
? snd_usb_find_csint_desc+0xa8/0xf0 [snd_usb_audio]
snd_usb_mixer_controls+0x1dc/0x370 [snd_usb_audio]
? build_audio_procunit+0x890/0x890 [snd_usb_audio]
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? kmem_cache_alloc_trace+0xff/0x230
? usb_ifnum_to_if+0xbd/0xf0
snd_usb_create_mixer+0x25b/0x4b0 [snd_usb_audio]
? snd_usb_create_stream+0x255/0x2c0 [snd_usb_audio]
usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? snd_usb_autosuspend.part.7+0x30/0x30 [snd_usb_audio]
? __pm_runtime_idle+0x90/0x90
? kernfs_activate+0xa6/0xc0
? usb_match_one_id_intf+0xdc/0x130
? __pm_runtime_set_status+0x2d4/0x450
usb_probe_interface+0x1f5/0x440
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jaejoong Kim <climbbb.kim(a)gmail.com>
---
The AudioControl Interface Descriptor in commit message is from
lsusb output with real usb audio DAC.
The usb audio product causing the OOB are as follows:
http://www.lg.com/uk/lg-friends/lg-AFD-1200
It only prints OOB error and usb audio works well. :)
sound/usb/mixer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index e630813..5a83c2c 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -204,7 +204,8 @@ static int snd_usb_copy_string_desc(struct mixer_build *state,
int index, char *buf, int maxlen)
{
int len = usb_string(state->chip->dev, index, buf, maxlen - 1);
- buf[len] = 0;
+ if (len > 0)
+ buf[len] = 0;
return len;
}
--
2.7.4
From: Bob Moore <robert.moore(a)intel.com>
[ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ]
ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1
ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a
ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e
The declared buffer length must be the same as the length of the
byte initializer list, otherwise not a valid resource descriptor.
Link: https://github.com/acpica/acpica/commit/9f76de2d
Link: https://github.com/acpica/acpica/commit/b2e89d72
Link: https://github.com/acpica/acpica/commit/23b5bbe6
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
Signed-off-by: Lv Zheng <lv.zheng(a)intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
drivers/acpi/acpica/utresrc.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c
index 5cd017c7ac0e..94b3ee013761 100644
--- a/drivers/acpi/acpica/utresrc.c
+++ b/drivers/acpi/acpica/utresrc.c
@@ -421,8 +421,10 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
ACPI_FUNCTION_TRACE(ut_walk_aml_resources);
- /* The absolute minimum resource template is one end_tag descriptor */
-
+ /*
+ * The absolute minimum resource template is one end_tag descriptor.
+ * However, we will treat a lone end_tag as just a simple buffer.
+ */
if (aml_length < sizeof(struct aml_resource_end_tag)) {
return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG);
}
@@ -454,9 +456,8 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
/* Invoke the user function */
if (user_function) {
- status =
- user_function(aml, length, offset, resource_index,
- context);
+ status = user_function(aml, length, offset,
+ resource_index, context);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
@@ -480,6 +481,12 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
*context = aml;
}
+ /* Check if buffer is defined to be longer than the resource length */
+
+ if (aml_length > (offset + length)) {
+ return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG);
+ }
+
/* Normal exit */
return_ACPI_STATUS(AE_OK);
--
2.11.0
From: Bob Moore <robert.moore(a)intel.com>
[ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ]
ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1
ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a
ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e
The declared buffer length must be the same as the length of the
byte initializer list, otherwise not a valid resource descriptor.
Link: https://github.com/acpica/acpica/commit/9f76de2d
Link: https://github.com/acpica/acpica/commit/b2e89d72
Link: https://github.com/acpica/acpica/commit/23b5bbe6
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
Signed-off-by: Lv Zheng <lv.zheng(a)intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
drivers/acpi/acpica/utresrc.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c
index b3505dbc715e..3f903f4855db 100644
--- a/drivers/acpi/acpica/utresrc.c
+++ b/drivers/acpi/acpica/utresrc.c
@@ -421,8 +421,10 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
ACPI_FUNCTION_TRACE(ut_walk_aml_resources);
- /* The absolute minimum resource template is one end_tag descriptor */
-
+ /*
+ * The absolute minimum resource template is one end_tag descriptor.
+ * However, we will treat a lone end_tag as just a simple buffer.
+ */
if (aml_length < sizeof(struct aml_resource_end_tag)) {
return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG);
}
@@ -454,9 +456,8 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
/* Invoke the user function */
if (user_function) {
- status =
- user_function(aml, length, offset, resource_index,
- context);
+ status = user_function(aml, length, offset,
+ resource_index, context);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
@@ -480,6 +481,12 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
*context = aml;
}
+ /* Check if buffer is defined to be longer than the resource length */
+
+ if (aml_length > (offset + length)) {
+ return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG);
+ }
+
/* Normal exit */
return_ACPI_STATUS(AE_OK);
--
2.11.0
Fix child node-lookup during probe, which ended up searching the whole
device tree depth-first starting at parent rather than just matching on
its children.
Note that the original premature free of the parent node has already
been fixed separately, but that fix was apparently never backported to
stable.
Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)")
Fixes: 660e15519399 ("clk: ti: dra7-atl-clock: Fix of_node reference counting")
Cc: stable <stable(a)vger.kernel.org> # 3.16: 660e15519399
Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/clk/ti/clk-dra7-atl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
index 13eb04f72389..148815470431 100644
--- a/drivers/clk/ti/clk-dra7-atl.c
+++ b/drivers/clk/ti/clk-dra7-atl.c
@@ -274,8 +274,7 @@ static int of_dra7_atl_clk_probe(struct platform_device *pdev)
/* Get configuration for the ATL instances */
snprintf(prop, sizeof(prop), "atl%u", i);
- of_node_get(node);
- cfg_node = of_find_node_by_name(node, prop);
+ cfg_node = of_get_child_by_name(node, prop);
if (cfg_node) {
ret = of_property_read_u32(cfg_node, "bws",
&cdesc->bws);
--
2.15.0
The patch titled
Subject: mm: fix device-dax pud write-faults triggered by get_user_pages()
has been added to the -mm tree. Its filename is
mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-fix-device-dax-pud-write-faults…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-fix-device-dax-pud-write-faults…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Dan Williams <dan.j.williams(a)intel.com>
Subject: mm: fix device-dax pud write-faults triggered by get_user_pages()
Currently only get_user_pages_fast() can safely handle the writable gup
case due to its use of pud_access_permitted() to check whether the pud
entry is writable. In the gup slow path pud_write() is used instead of
pud_access_permitted() and to date it has been unimplemented, just calls
BUG_ON().
kernel BUG at ./include/linux/hugetlb.h:244!
[..]
RIP: 0010:follow_devmap_pud+0x482/0x490
[..]
Call Trace:
follow_page_mask+0x28c/0x6e0
__get_user_pages+0xe4/0x6c0
get_user_pages_unlocked+0x130/0x1b0
get_user_pages_fast+0x89/0xb0
iov_iter_get_pages_alloc+0x114/0x4a0
nfs_direct_read_schedule_iovec+0xd2/0x350
? nfs_start_io_direct+0x63/0x70
nfs_file_direct_read+0x1e0/0x250
nfs_file_read+0x90/0xc0
For now this just implements a simple check for the _PAGE_RW bit similar
to pmd_write. However, this implies that the gup-slow-path check is
missing the extra checks that the gup-fast-path performs with
pud_access_permitted. Later patches will align all checks to use the
'access_permitted' helper if the architecture provides it. Note that the
generic 'access_permitted' helper fallback is the simple _PAGE_RW check on
architectures that do not define the 'access_permitted' helper(s).
Link: http://lkml.kernel.org/r/151043109938.2842.14834662818213616199.stgit@dwill…
Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/arm64/include/asm/pgtable.h | 1 +
arch/sparc/include/asm/pgtable_64.h | 1 +
arch/x86/include/asm/pgtable.h | 6 ++++++
include/asm-generic/pgtable.h | 9 +++++++++
include/linux/hugetlb.h | 8 --------
5 files changed, 17 insertions(+), 8 deletions(-)
diff -puN arch/arm64/include/asm/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages arch/arm64/include/asm/pgtable.h
--- a/arch/arm64/include/asm/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/arch/arm64/include/asm/pgtable.h
@@ -340,6 +340,7 @@ static inline int pmd_protnone(pmd_t pmd
#define pfn_pmd(pfn,prot) (__pmd(((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)))
#define mk_pmd(page,prot) pfn_pmd(page_to_pfn(page),prot)
+#define __HAVE_ARCH_PUD_WRITE
#define pud_write(pud) pte_write(pud_pte(pud))
#define pud_pfn(pud) (((pud_val(pud) & PUD_MASK) & PHYS_MASK) >> PAGE_SHIFT)
diff -puN arch/sparc/include/asm/pgtable_64.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages arch/sparc/include/asm/pgtable_64.h
--- a/arch/sparc/include/asm/pgtable_64.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/arch/sparc/include/asm/pgtable_64.h
@@ -723,6 +723,7 @@ static inline unsigned long pmd_write(pm
return pte_write(pte);
}
+#define __HAVE_ARCH_PUD_WRITE
#define pud_write(pud) pte_write(__pte(pud_val(pud)))
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff -puN arch/x86/include/asm/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages arch/x86/include/asm/pgtable.h
--- a/arch/x86/include/asm/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/arch/x86/include/asm/pgtable.h
@@ -1088,6 +1088,12 @@ static inline void pmdp_set_wrprotect(st
clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp);
}
+#define __HAVE_ARCH_PUD_WRITE
+static inline int pud_write(pud_t pud)
+{
+ return pud_flags(pud) & _PAGE_RW;
+}
+
/*
* clone_pgd_range(pgd_t *dst, pgd_t *src, int count);
*
diff -puN include/asm-generic/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/include/asm-generic/pgtable.h
@@ -812,6 +812,15 @@ static inline int pmd_write(pmd_t pmd)
return 0;
}
#endif /* __HAVE_ARCH_PMD_WRITE */
+
+#ifndef __HAVE_ARCH_PUD_WRITE
+static inline int pud_write(pud_t pud)
+{
+ BUG();
+ return 0;
+}
+#endif /* __HAVE_ARCH_PUD_WRITE */
+
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#if !defined(CONFIG_TRANSPARENT_HUGEPAGE) || \
diff -puN include/linux/hugetlb.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages include/linux/hugetlb.h
--- a/include/linux/hugetlb.h~mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages
+++ a/include/linux/hugetlb.h
@@ -239,14 +239,6 @@ static inline int pgd_write(pgd_t pgd)
}
#endif
-#ifndef pud_write
-static inline int pud_write(pud_t pud)
-{
- BUG();
- return 0;
-}
-#endif
-
#define HUGETLB_ANON_FILE "anon_hugepage"
enum {
_
Patches currently in -mm which might be from dan.j.williams(a)intel.com are
mm-fix-device-dax-pud-write-faults-triggered-by-get_user_pages.patch
mm-replace-pud_write-with-pud_access_permitted-in-fault-gup-paths.patch
mm-replace-pmd_write-with-pmd_access_permitted-in-fault-gup-paths.patch
mm-replace-pte_write-with-pte_access_permitted-in-fault-gup-paths.patch
On Tue, Nov 14, 2017 at 11:17:38AM +0000, James Hogan wrote:
> On Tue, Nov 14, 2017 at 10:52:54AM +0000, Matt Redfearn wrote:
> > Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
> > enabled building the Indy watchdog driver when COMPILE_TEST is enabled.
> > However, the driver makes reference to symbols that are only defined for
> > certain platforms are selected in the config. These platforms select
> > SGI_HAS_INDYDOG. Without this, link time errors result, for example
> > when building a MIPS allyesconfig.
> >
> > drivers/watchdog/indydog.o: In function `indydog_write':
> > indydog.c:(.text+0x18): undefined reference to `sgimc'
> > indydog.c:(.text+0x1c): undefined reference to `sgimc'
> > drivers/watchdog/indydog.o: In function `indydog_start':
> > indydog.c:(.text+0x54): undefined reference to `sgimc'
> > indydog.c:(.text+0x58): undefined reference to `sgimc'
> > drivers/watchdog/indydog.o: In function `indydog_stop':
> > indydog.c:(.text+0xa4): undefined reference to `sgimc'
> > drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined
> > references to `sgimc' follow
> > make: *** [Makefile:1005: vmlinux] Error 1
> >
> > Fix this by ensuring that CONFIG_INDIDOG can only be selected when the
> > necessary dependent platform symbols are built in.
> >
> > Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
> > Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
> > Cc: <stable(a)vger.kernel.org> # 4.11 +
> > ---
> >
> > drivers/watchdog/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index ca200d1f310a..d96e2e7544fc 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -1451,7 +1451,7 @@ config RC32434_WDT
> >
> > config INDYDOG
> > tristate "Indy/I2 Hardware Watchdog"
> > - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST)
> > + depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG)
>
> (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG) implies SGI_HAS_INDYDOG
>
> So I think you can just do:
> - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST)
> + depends on SGI_HAS_INDYDOG
>
> I.e. COMPILE_TEST isn't of any value in this case.
I agree, due to the references to sgimc this driver will only compile for
the platforms which set SGI_HAS_INDYDOG; MIPS as the dependency is too
generic.
Updated patch for the watchdog maintainers' ease below.
Ralf
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Reported-by: Matt Redfearn <matt.redfearn(a)mips.com>
Suggested-by: James Hogan <james.hogan(a)mips.com>
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c722cbfdc7e6..3ece1335ba84 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1451,7 +1451,7 @@ config RC32434_WDT
config INDYDOG
tristate "Indy/I2 Hardware Watchdog"
- depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST)
+ depends on SGI_HAS_INDYDOG
help
Hardware driver for the Indy's/I2's watchdog. This is a
watchdog timer that will reboot the machine after a 60 second
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.
Cc: stable(a)vger.kernel.org
Reported-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Imre Deak <imre.deak(a)intel.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/intel_uncore.c | 6 ++++++
drivers/gpu/drm/i915/intel_uncore.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e7e9e061073b..cdff9825a3da 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2627,6 +2627,8 @@ static int intel_runtime_resume(struct device *kdev)
ret = vlv_resume_prepare(dev_priv, true);
}
+ intel_uncore_runtime_resume(dev_priv);
+
/*
* No point of rolling back things in case of an error, as the best
* we can do is to hope that things will still work (and disable RPM).
diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index dbc5cc309cbc..9567ba385f41 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -557,6 +557,12 @@ void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
i915_check_and_clear_faults(dev_priv);
}
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv)
+{
+ iosf_mbi_register_pmic_bus_access_notifier(
+ &dev_priv->uncore.pmic_bus_access_nb);
+}
+
void intel_uncore_sanitize(struct drm_i915_private *dev_priv)
{
i915_modparams.enable_rc6 =
diff --git a/drivers/gpu/drm/i915/intel_uncore.h b/drivers/gpu/drm/i915/intel_uncore.h
index 582771251b57..9ce079b5dd0d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -134,6 +134,7 @@ bool intel_uncore_arm_unclaimed_mmio_detection(struct drm_i915_private *dev_priv
void intel_uncore_fini(struct drm_i915_private *dev_priv);
void intel_uncore_suspend(struct drm_i915_private *dev_priv);
void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv);
u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
--
2.14.3
From: K. Y. Srinivasan <kys(a)microsoft.com>
The current rescind processing code will not correctly handle
the case where the host immediately rescinds a channel that has
been offerred. In this case, we could be blocked in the open call and
since the channel is rescinded, the host will not respond and we could
be blocked forever in the vmbus open call.i Fix this problem.
Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com>
Cc: stable(a)vger.kernel.org
---
drivers/hv/channel.c | 10 ++++++++--
drivers/hv/channel_mgmt.c | 7 ++++---
include/linux/hyperv.h | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 19f0cf3..ba0a092 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -659,22 +659,28 @@ void vmbus_close(struct vmbus_channel *channel)
*/
return;
}
- mutex_lock(&vmbus_connection.channel_mutex);
/*
* Close all the sub-channels first and then close the
* primary channel.
*/
list_for_each_safe(cur, tmp, &channel->sc_list) {
cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
- vmbus_close_internal(cur_channel);
if (cur_channel->rescind) {
+ wait_for_completion(&cur_channel->rescind_event);
+ mutex_lock(&vmbus_connection.channel_mutex);
+ vmbus_close_internal(cur_channel);
hv_process_channel_removal(
cur_channel->offermsg.child_relid);
+ } else {
+ mutex_lock(&vmbus_connection.channel_mutex);
+ vmbus_close_internal(cur_channel);
}
+ mutex_unlock(&vmbus_connection.channel_mutex);
}
/*
* Now close the primary.
*/
+ mutex_lock(&vmbus_connection.channel_mutex);
vmbus_close_internal(channel);
mutex_unlock(&vmbus_connection.channel_mutex);
}
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index ec5454f..c21020b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -333,6 +333,7 @@ bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp,
return NULL;
spin_lock_init(&channel->lock);
+ init_completion(&channel->rescind_event);
INIT_LIST_HEAD(&channel->sc_list);
INIT_LIST_HEAD(&channel->percpu_list);
@@ -898,6 +899,7 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)
/*
* Now wait for offer handling to complete.
*/
+ vmbus_rescind_cleanup(channel);
while (READ_ONCE(channel->probe_done) == false) {
/*
* We wait here until any channel offer is currently
@@ -913,7 +915,6 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)
if (channel->device_obj) {
if (channel->chn_rescind_callback) {
channel->chn_rescind_callback(channel);
- vmbus_rescind_cleanup(channel);
return;
}
/*
@@ -922,7 +923,6 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)
*/
dev = get_device(&channel->device_obj->device);
if (dev) {
- vmbus_rescind_cleanup(channel);
vmbus_device_unregister(channel->device_obj);
put_device(dev);
}
@@ -936,13 +936,14 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)
* 2. Then close the primary channel.
*/
mutex_lock(&vmbus_connection.channel_mutex);
- vmbus_rescind_cleanup(channel);
if (channel->state == CHANNEL_OPEN_STATE) {
/*
* The channel is currently not open;
* it is safe for us to cleanup the channel.
*/
hv_process_channel_removal(rescind->child_relid);
+ } else {
+ complete(&channel->rescind_event);
}
mutex_unlock(&vmbus_connection.channel_mutex);
}
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index f3e97c5..6c93366 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -708,6 +708,7 @@ struct vmbus_channel {
u8 monitor_bit;
bool rescind; /* got rescind msg */
+ struct completion rescind_event;
u32 ringbuffer_gpadlhandle;
--
1.7.1
The mvneta controller provides a 8-bit register to update the pending
Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be
added at once. In the current code the mvneta_txq_pend_desc_add function
assumes the caller takes care of this limit. But it is not the case. In
some situations (xmit_more flag), more than 255 descriptors are added.
When this happens, the Tx descriptor counter register is updated with a
wrong value, which breaks the whole Tx queue management.
This patch fixes the issue by allowing the mvneta_txq_pend_desc_add
function to process more than 255 Tx descriptors.
Fixes: 2a90f7e1d5d0 ("net: mvneta: add xmit_more support")
Cc: stable(a)vger.kernel.org # 4.11+
Signed-off-by: Simon Guinot <simon.guinot(a)sequanux.org>
---
drivers/net/ethernet/marvell/mvneta.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 64a04975bcf8..027c08ce4e5d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -816,11 +816,14 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
{
u32 val;
- /* Only 255 descriptors can be added at once ; Assume caller
- * process TX desriptors in quanta less than 256
- */
- val = pend_desc + txq->pending;
- mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
+ pend_desc += txq->pending;
+
+ /* Only 255 Tx descriptors can be added at once */
+ while (pend_desc > 0) {
+ val = min(pend_desc, 255);
+ mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
+ pend_desc -= val;
+ }
txq->pending = 0;
}
@@ -2413,8 +2416,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
if (txq->count >= txq->tx_stop_threshold)
netif_tx_stop_queue(nq);
- if (!skb->xmit_more || netif_xmit_stopped(nq) ||
- txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK)
+ if (!skb->xmit_more || netif_xmit_stopped(nq))
mvneta_txq_pend_desc_add(pp, txq, frags);
else
txq->pending += frags;
--
2.9.3
Function devm_gpiod_get_optional() returns an ERR_PTR on failure. Its
return value should not be validated by a NULL check. Instead, use IS_ERR.
Signed-off-by: Pan Bian <bianpan2016(a)163.com>
---
drivers/net/dsa/lan9303-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index b471413..6d3fc8f 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -828,7 +828,7 @@ static void lan9303_probe_reset_gpio(struct lan9303 *chip,
chip->reset_gpio = devm_gpiod_get_optional(chip->dev, "reset",
GPIOD_OUT_LOW);
- if (!chip->reset_gpio) {
+ if (IS_ERR(chip->reset_gpio)) {
dev_dbg(chip->dev, "No reset GPIO defined\n");
return;
}
--
1.9.1
Hi Doug,
Here is the latest set of patches I have that we'd like to land in 4.15. There
are some driver fixes, including a qib that is marked as stable. We also have
a CM and SA patch thrown in the mix.
As always patches available for browsing at:
https://github.com/ddalessa/kernel/tree/for-4.15
---
Dennis Dalessandro (1):
IB/hfi1: Initialize bth1 in 16B rc ack builder
Don Hiatt (2):
IB/hfi1: Mask the path bits with the LMC for 16B RC Acks
IB/CM: Change sgid to IB GID when handling CM request
Jan Sokolowski (1):
IB/hfi1: Use 4096 for default active MTU in query_qp
Mike Marciniszyn (1):
IB/qib: Fix comparison error with qperf compare/swap test
Venkata Sandeep Dhanalakota (1):
IB/SA: Check dlid before SA agent queries for ClassPortInfo
drivers/infiniband/core/cm.c | 38 ++++++++++++++++++++++++++++++++++--
drivers/infiniband/core/sa_query.c | 10 +++++++++
drivers/infiniband/hw/hfi1/rc.c | 10 +++++----
drivers/infiniband/hw/hfi1/verbs.c | 2 +-
drivers/infiniband/hw/qib/qib_rc.c | 6 +++---
5 files changed, 55 insertions(+), 11 deletions(-)
--
-Denny
On Fri, 2017-10-13 at 04:36:41 UTC, Shriya wrote:
> The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which
> returns the last frequency requested by the kernel, but may not
> reflect the actual frequency the processor is running at.
> This patch makes a call to cpufreq_get() instead which returns the
> current frequency reported by the hardware.
>
> Fixes : commit fb5153d05a7d ("powerpc: powernv: Implement
> ppc_md.get_proc_freq()")
> Cc: stable(a)vger.kernel.org
>
> Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cd77b5ce208c153260ed7882d8910f
cheers
Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
enabled building the Indy watchdog driver when COMPILE_TEST is enabled.
However, the driver makes reference to symbols that are only defined for
certain platforms are selected in the config. These platforms select
SGI_HAS_INDYDOG. Without this, link time errors result, for example
when building a MIPS allyesconfig.
drivers/watchdog/indydog.o: In function `indydog_write':
indydog.c:(.text+0x18): undefined reference to `sgimc'
indydog.c:(.text+0x1c): undefined reference to `sgimc'
drivers/watchdog/indydog.o: In function `indydog_start':
indydog.c:(.text+0x54): undefined reference to `sgimc'
indydog.c:(.text+0x58): undefined reference to `sgimc'
drivers/watchdog/indydog.o: In function `indydog_stop':
indydog.c:(.text+0xa4): undefined reference to `sgimc'
drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined
references to `sgimc' follow
make: *** [Makefile:1005: vmlinux] Error 1
Fix this by ensuring that CONFIG_INDIDOG can only be selected when the
necessary dependent platform symbols are built in.
Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com>
Cc: <stable(a)vger.kernel.org> # 4.11 +
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ca200d1f310a..d96e2e7544fc 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1451,7 +1451,7 @@ config RC32434_WDT
config INDYDOG
tristate "Indy/I2 Hardware Watchdog"
- depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST)
+ depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG)
help
Hardware driver for the Indy's/I2's watchdog. This is a
watchdog timer that will reboot the machine after a 60 second
--
2.7.4
Hi,
commit 9029679f66d976f8c720eb03c4898274803c9923 upstream.
the patch "brcmfmac: remove setting IBSS mode when stopping AP" fixes a
recurring warning[1] when we run our wifi in AP mode after we
stopped an AP on the same card.
We are using the 4.9 stable tree. But every kernel < 4.13 and >= 3.9 is
affected by this problem.
Best regards
Philipp
[1] The warning message with backtrace:
[ 517.577475] brcmfmac: brcmf_update_bss_info: wl dtim_assoc failed (-23)
[ 517.584567] ------------[ cut here ]------------
[ 517.594906] WARNING: CPU: 0 PID: 963 at /home/ilu/src/linux/net/wireless/sme.c:738 __cfg80211_connect_result+0x2dc/0x400 [cfg80211]
[ 517.610126] Modules linked in: brcmfmac brcmutil cfg80211
[ 517.615752] CPU: 0 PID: 963 Comm: kworker/u2:2 Tainted: G W 4.9.56-sde-00010-g3b9115e #18
[ 517.627723] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 517.634647] Workqueue: cfg80211 cfg80211_event_work [cfg80211]
[ 517.642070] [<c010f270>] (unwind_backtrace) from [<c010c4f0>] (show_stack+0x10/0x14)
[ 517.652696] [<c010c4f0>] (show_stack) from [<c011cab4>] (__warn+0xe8/0x100)
[ 517.661193] [<c011cab4>] (__warn) from [<c011cb7c>] (warn_slowpath_null+0x20/0x28)
[ 517.670507] [<c011cb7c>] (warn_slowpath_null) from [<bf02f6a4>] (__cfg80211_connect_result+0x2dc/0x400 [cfg80211])
[ 517.682888] [<bf02f6a4>] (__cfg80211_connect_result [cfg80211]) from [<bf00564c>] (cfg80211_process_wdev_events+0x178/0x1f8 [cfg80211])
[ 517.696985] [<bf00564c>] (cfg80211_process_wdev_events [cfg80211]) from [<bf0056f8>] (cfg80211_process_rdev_events+0x2c/0x60 [cfg80211])
[ 517.711110] [<bf0056f8>] (cfg80211_process_rdev_events [cfg80211]) from [<bf00027c>] (cfg80211_event_work+0x14/0x1c [cfg80211])
[ 517.724539] [<bf00027c>] (cfg80211_event_work [cfg80211]) from [<c01358cc>] (process_one_work+0x12c/0x518)
[ 517.735875] [<c01358cc>] (process_one_work) from [<c0135cf0>] (worker_thread+0x38/0x5d8)
[ 517.745234] [<c0135cf0>] (worker_thread) from [<c013b32c>] (kthread+0xf0/0x108)
[ 517.754090] [<c013b32c>] (kthread) from [<c0108498>] (ret_from_fork+0x14/0x3c)
[ 517.762967] ---[ end trace f68728a0d3053b54 ]---
[ 517.770431] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote:
> On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote:
> > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote:
> > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote:
> > > > When there's a fatal signal pending, arm64's do_page_fault()
> > > > implementation returns 0. The intent is that we'll return to the
> > > > faulting userspace instruction, delivering the signal on the way.
> > > >
> > > > However, if we take a fatal signal during fixing up a uaccess, this
> > > > results in a return to the faulting kernel instruction, which will be
> > > > instantly retried, resulting in the same fault being taken forever. As
> > > > the task never reaches userspace, the signal is not delivered, and the
> > > > task is left unkillable. While the task is stuck in this state, it can
> > > > inhibit the forward progress of the system.
> > > >
> > > > To avoid this, we must ensure that when a fatal signal is pending, we
> > > > apply any necessary fixup for a faulting kernel instruction. Thus we
> > > > will return to an error path, and it is up to that code to make forward
> > > > progress towards delivering the fatal signal.
> > > >
> > > > Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
> > > > Reviewed-by: Steve Capper <steve.capper(a)arm.com>
> > > > Tested-by: Steve Capper <steve.capper(a)arm.com>
> > > > Cc: Catalin Marinas <catalin.marinas(a)arm.com>
> > > > Cc: James Morse <james.morse(a)arm.com>
> > > > Cc: Laura Abbott <labbott(a)redhat.com>
> > > > Cc: Will Deacon <will.deacon(a)arm.com>
> > > > Cc: stable(a)vger.kernel.org
> > > > ---
> > > > arch/arm64/mm/fault.c | 5 ++++-
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > > > index 37b95df..3952d5e 100644
> > > > --- a/arch/arm64/mm/fault.c
> > > > +++ b/arch/arm64/mm/fault.c
> > > > @@ -397,8 +397,11 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
> > > > * signal first. We do not need to release the mmap_sem because it
> > > > * would already be released in __lock_page_or_retry in mm/filemap.c.
> > > > */
> > > > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> > > > + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
> > > > + if (!user_mode(regs))
> > > > + goto no_context;
> > > > return 0;
> > > > + }
> > >
> > > This will need rebasing at -rc1 (take a look at current HEAD).
> > >
> > > Also, I think it introduces a weird corner case where we take a page fault
> > > when writing the signal frame to the user stack to deliver a SIGSEGV. If
> > > we end up with VM_FAULT_RETRY and somebody has sent a SIGKILL to the task,
> > > then we'll fail setup_sigframe and force an un-handleable SIGSEGV instead
> > > of SIGKILL.
> > >
> > > The end result (task is killed) is the same, but the fatal signal is wrong.
> >
> > That doesn't seem to be the case, testing on v4.13-rc5.
> >
> > I used sigaltstack() to use the userfaultfd region as signal stack,
> > registerd a SIGSEGV handler, and dereferenced NULL. The task locks up,
> > but when killed with a SIGINT or SIGKILL, the exit status reflects that
> > signal, rather than the SIGSEGV.
> >
> > If I move the SIGINT handler onto the userfaultfd-monitored stack, then
> > delivering SIGINT hangs, but can be killed with SIGKILL, and the exit
> > status reflects that SIGKILL.
> >
> > As you say, it does look like we'd try to set up a deferred SIGSEGV for
> > the failed signal delivery.
> >
> > I haven't yet figured out exactly how that works; I'll keep digging.
>
> The SEGV makes it all the way into do_group_exit, but then signal_group_exit
> is set and the exit_code is overridden with SIGKILL at the last minute (see
> complete_signal).
Unfortunately, this last minute is too late for print-fatal-signals.
With print-fatal-signals enabled, this patch leads to misleading
"potentially unexpected fatal signal 11" warnings if a process is
SIGKILL'd at the right time.
I've seen it without userfaultfd, but it's easiest reproduced by
patching Mark's original test code [1] with the following patch and
simply running "pkill -WINCH foo; pkill -KILL foo". This results in:
foo: potentially unexpected fatal signal 11.
CPU: 1 PID: 1793 Comm: foo Not tainted 4.9.58-devel #3
task: b3534780 task.stack: b4b7c000
PC is at 0x76effb60
LR is at 0x4227f4
pc : [<76effb60>] lr : [<004227f4>] psr: 600b0010
sp : 7eaf7bb4 ip : 00000000 fp : 00000000
r10: 00000001 r9 : 00000003 r8 : 76fcd000
r7 : 0000001d r6 : 76fd0cf0 r5 : 7eaf7c08 r4 : 00000000
r3 : 00000000 r2 : 00000000 r1 : 7eaf7a88 r0 : fffffffc
Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 10c5387d Table: 3357404a DAC: 00000055
CPU: 1 PID: 1793 Comm: foo Not tainted 4.9.58-devel #3
[<801113f0>] (unwind_backtrace) from [<8010cfb0>] (show_stack+0x18/0x1c)
[<8010cfb0>] (show_stack) from [<8039725c>] (dump_stack+0x84/0x98)
[<8039725c>] (dump_stack) from [<8012f448>] (get_signal+0x384/0x684)
[<8012f448>] (get_signal) from [<8010c2ec>] (do_signal+0xcc/0x470)
[<8010c2ec>] (do_signal) from [<8010c868>] (do_work_pending+0xb8/0xc8)
[<8010c868>] (do_work_pending) from [<801086d4>] (slow_work_pending+0xc/0x20)
This is ARM and I haven't tested ARM64, but the same problem even exists
on x86.
--- foo.c.orig 2017-11-13 23:45:47.802167284 +0100
+++ foo.c 2017-11-14 07:16:13.906363466 +0100
@@ -6,6 +6,11 @@
#include <sys/syscall.h>
#include <sys/vfs.h>
#include <unistd.h>
+#include <signal.h>
+
+static void handler(int sig)
+{
+}
int main(int argc, char *argv[])
{
@@ -47,13 +52,17 @@
if (ret < 0)
return errno;
+ sigaltstack(&(stack_t){.ss_sp = mem, .ss_size = pagesz}, NULL);
+ sigaction(SIGWINCH, &(struct sigaction){ .sa_handler = handler, .sa_flags = SA_ONSTACK, }, NULL);
+
/*
* Force an arbitrary uaccess to memory monitored by the userfaultfd.
* This will block, but when a SIGKILL is sent, will consume all
* available CPU time without being killed, and may inhibit forward
* progress of the system.
*/
- ret = fstatfs(0, (struct statfs *)mem);
+ // ret = fstatfs(0, (struct statfs *)mem);
+ pause();
return 0;
}
[1] https://lkml.kernel.org/r/1499782590-31366-1-git-send-email-mark.rutland@ar…
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.
These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.
Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.
Cc: stable(a)vger.kernel.org
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 0ebf3f283b87..810b1147a0ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -998,7 +998,8 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
return crtc->config->cpu_transcoder;
}
-static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
+static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv,
+ enum pipe pipe, bool stopped)
{
i915_reg_t reg = PIPEDSL(pipe);
u32 line1, line2;
@@ -1013,7 +1014,7 @@ static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
msleep(5);
line2 = I915_READ(reg) & line_mask;
- return line1 == line2;
+ return (line1 == line2) == stopped;
}
/*
@@ -1048,11 +1049,21 @@ static void intel_wait_for_pipe_off(struct intel_crtc *crtc)
WARN(1, "pipe_off wait timed out\n");
} else {
/* Wait for the display line to settle */
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
+ if (wait_for(pipe_dsl_stopped(dev_priv, pipe, true), 100))
WARN(1, "pipe_off wait timed out\n");
}
}
+static void intel_wait_for_pipe_on(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Wait for the display line to start moving */
+ if (wait_for(pipe_dsl_stopped(dev_priv, pipe, false), 100))
+ WARN(1, "pipe_on wait timed out\n");
+}
+
/* Only for pre-ILK configs */
void assert_pll(struct drm_i915_private *dev_priv,
enum pipe pipe, bool state)
@@ -1935,15 +1946,14 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
POSTING_READ(reg);
/*
- * Until the pipe starts DSL will read as 0, which would cause
- * an apparent vblank timestamp jump, which messes up also the
- * frame count when it's derived from the timestamps. So let's
- * wait for the pipe to start properly before we call
- * drm_crtc_vblank_on()
+ * Until the pipe starts DSL can give a bogus value, which cause
+ * an apparent vblank timestamp jump when the DSL resets to its
+ * proper value, which messes up also the frame count when it's
+ * derived from the timestamps. So let's wait for the pipe to
+ * start properly before we call drm_crtc_vblank_on()
*/
- if (dev->max_vblank_count == 0 &&
- wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50))
- DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe));
+ if (dev->max_vblank_count == 0)
+ intel_wait_for_pipe_on(crtc);
}
/**
@@ -14707,7 +14717,7 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
I915_WRITE(PIPECONF(pipe), 0);
POSTING_READ(PIPECONF(pipe));
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
+ if (wait_for(pipe_dsl_stopped(dev_priv, pipe, true), 100))
DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe));
I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
--
2.13.6
On Thu, 2017-10-19 at 15:49 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me
> know.
>
> ------------------
>
> From: Milan Broz <gmazyland(a)gmail.com>
>
>
> [ Upstream commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 ]
>
> Since the
> Â Â Â commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> Â Â Â crypto: xts - Convert to skcipher
That commit went into 4.10, and not any stable branches. So this fix
doesn't appear to be appropriate for the older branches it was applied
to.
Ben.
> the XTS mode is based on ECB, so the mode must select
> ECB otherwise it can fail to initialize.
>
> Signed-off-by: Milan Broz <gmazyland(a)gmail.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>
> ---
> Â crypto/Kconfig |Â Â Â Â 1 +
> Â 1 file changed, 1 insertion(+)
>
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -343,6 +343,7 @@ config CRYPTO_XTS
> Â select CRYPTO_BLKCIPHER
> Â select CRYPTO_MANAGER
> Â select CRYPTO_GF128MUL
> + select CRYPTO_ECB
> Â help
> Â Â Â XTS: IEEE1619/D16 narrow block cipher use with aes-xts-
> plain,
> Â Â Â key size 256, 384 or 512 bits. This implementation
> currently
>
>
>
--
Ben Hutchings
Software Developer, Codethink Ltd.
On Thu, 2017-10-19 at 15:49 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: "Dmitry V. Levin" <ldv(a)altlinux.org>
>
>
> [ Upstream commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 ]
>
> Consistently use types from linux/types.h to fix the following
> linux/rds.h userspace compilation errors:
[...]
> --- a/include/uapi/linux/rds.h
> +++ b/include/uapi/linux/rds.h
> @@ -35,6 +35,7 @@
> Â #define _LINUX_RDS_H
> Â
> Â #include <linux/types.h>
> +#include <linux/socket.h> /* For __kernel_sockaddr_storage. */
> Â
> Â #define RDS_IB_ABI_VERSION 0x301
> Â
> @@ -223,7 +224,7 @@ struct rds_get_mr_args {
> Â };
> Â
> Â struct rds_get_mr_for_dest_args {
> - struct sockaddr_storage dest_addr;
> + struct __kernel_sockaddr_storage dest_addr;
>  struct rds_iovec vec;
> Â uint64_t cookie_addr;
> Â uint64_t flags;
This is a valid fix but not the one that the commit message and
upstream commit hash refer to. This diff matches:
commit 1786dbf3702e33ce3afd2d3dbe630bd04b1d2e58
Author: Dmitry V. Levin <ldv(a)altlinux.org>
Date:Â Â Â Thu Feb 16 18:05:45 2017 +0300
    uapi: fix linux/rds.h userspace compilation error
which has almost the same subject line.
Maybe you should cherry-pick commit
feb0869d90e51ce8b6fd8a46588465b1b5a26d09 for real as well (in all
branches).
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
commit ec0aef9881d18aa781268ec9cba8eba5b202f5b4 upstream.
The crypto engines found on the cp110 master and slave are dma coherent.
This patch adds the relevant property to their dt nodes.
Cc: stable(a)vger.kernel.org # v4.12+
Fixes: 973020fd9498 ("arm64: marvell: dts: add crypto engine description for 7k/8k")
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
---
Hi,
This patch did not apply to the 4.12-stable tree. Since the original
patch made it to Linus tree, this is a version which applies nicely
to the 4.12-stable tree.
Thanks,
Antoine
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 1 +
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index b4bc42ece754..4e81130ae84a 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -240,6 +240,7 @@
interrupt-names = "mem", "ring0", "ring1",
"ring2", "ring3", "eip";
clocks = <&cpm_syscon0 1 26>;
+ dma-coherent;
status = "disabled";
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6e2058847ddc..b987565107f3 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -230,6 +230,7 @@
interrupt-names = "mem", "ring0", "ring1",
"ring2", "ring3", "eip";
clocks = <&cps_syscon0 1 26>;
+ dma-coherent;
status = "disabled";
};
};
--
2.14.3
From: Simon Guinot <simon.guinot(a)sequanux.org>
Date: Mon, 13 Nov 2017 15:51:15 +0100
> IIUC the driver stops the queue if a threshold of 316 Tx descriptors is
> reached (default and worst value).
That's a lot of latency.
This is the start of the stable review cycle for the 4.13.13 release.
There are 33 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Nov 15 12:55:46 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.13-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.13.13-rc1
Borislav Petkov <bp(a)suse.de>
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
Pavel Tatashin <pasha.tatashin(a)oracle.com>
x86/smpboot: Make optimization of delay calibration work correctly
Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
x86/debug: Handle warnings before the notifier chain, to fix KGDB crash
Richard Schütz <rschuetz(a)uni-koblenz.de>
can: c_can: don't indicate triple sampling support for D_CAN
Marek Vasut <marex(a)denx.de>
can: ifi: Fix transmitter delay calculation
Stephane Grosjean <s.grosjean(a)peak-system.com>
can: peak: Add support for new PCIe/M2 CAN FD interfaces
Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
can: sun4i: handle overrun in RX FIFO
Linus Torvalds <torvalds(a)linux-foundation.org>
Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"
Sinclair Yeh <syeh(a)vmware.com>
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
Ilya Dryomov <idryomov(a)gmail.com>
rbd: use GFP_NOIO for parent stat and data requests
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Input: elan_i2c - add ELAN060C to the ACPI table
Paul Mackerras <paulus(a)ozlabs.org>
KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates
Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
MIPS: AR7: Ensure that serial ports are properly set up
Jonas Gorski <jonas.gorski(a)gmail.com>
MIPS: AR7: Defer registration of GPIO
Jaedon Shin <jaedon.shin(a)gmail.com>
MIPS: BMIPS: Fix missing cbr address
Paul Burton <paul.burton(a)mips.com>
MIPS: Fix CM region target definitions
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Avoid invalid lockdep class warning
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix OSS sysex delivery in OSS emulation
Hui Wang <hui.wang(a)canonical.com>
ALSA: hda - fix headset mic problem for Dell machines with alc274
Jussi Laako <jussi(a)sonarnerd.net>
ALSA: usb-audio: support new Amanero Combo384 firmware version
Takashi Iwai <tiwai(a)suse.de>
ALSA: timer: Limit max instances per timer
Mark Rutland <mark.rutland(a)arm.com>
ARM: 8720/1: ensure dump_instr() checks addr_limit
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
ACPI / scan: Enable GPEs before scanning the namespace
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
ACPICA: Make it possible to enable runtime GPEs earlier
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
ACPICA: Dispatch active GPEs at init time
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360
Eric Biggers <ebiggers(a)google.com>
KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]
Andrey Ryabinin <aryabinin(a)virtuozzo.com>
crypto: x86/sha256-mb - fix panic due to unaligned access
Andrey Ryabinin <aryabinin(a)virtuozzo.com>
crypto: x86/sha1-mb - fix panic due to unaligned access
Romain Izard <romain.izard.pro(a)gmail.com>
crypto: ccm - preserve the IV buffer
Li Bin <huawei.libin(a)huawei.com>
workqueue: Fix NULL pointer dereference
Anatole Denis <anatole(a)rezel.net>
netfilter: nft_set_hash: disable fast_ops for 2-len keys
Florian Westphal <fw(a)strlen.de>
netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
-------------
Diffstat:
Makefile | 4 +-
arch/arm/kernel/traps.c | 28 +++--
arch/mips/ar7/platform.c | 5 +
arch/mips/ar7/prom.c | 2 -
arch/mips/include/asm/mips-cm.h | 4 +-
arch/mips/kernel/smp-bmips.c | 4 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 10 ++
arch/powerpc/kvm/book3s_hv.c | 29 +++--
arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 12 +-
.../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 12 +-
arch/x86/kernel/cpu/Makefile | 2 +-
arch/x86/kernel/cpu/aperfmperf.c | 11 +-
arch/x86/kernel/cpu/proc.c | 4 +-
arch/x86/kernel/smpboot.c | 11 +-
arch/x86/kernel/traps.c | 10 +-
arch/x86/kernel/tsc.c | 8 +-
arch/x86/oprofile/op_model_ppro.c | 4 +-
crypto/ccm.c | 4 +-
drivers/acpi/acpica/evgpeblk.c | 30 +++--
drivers/acpi/acpica/evxfgpe.c | 8 ++
drivers/acpi/scan.c | 6 +-
drivers/acpi/sleep.c | 28 +++++
drivers/block/rbd.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/input/mouse/elan_i2c_core.c | 1 +
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +-
drivers/net/can/peak_canfd/peak_pciefd_main.c | 14 ++-
drivers/net/can/sun4i_can.c | 12 +-
include/acpi/actypes.h | 3 +-
include/net/netfilter/nf_conntrack.h | 3 +-
include/net/netfilter/nf_nat.h | 1 -
include/sound/seq_kernel.h | 3 +-
include/sound/timer.h | 2 +
kernel/workqueue_internal.h | 3 +-
lib/asn1_decoder.c | 4 +-
net/netfilter/nf_nat_core.c | 130 +++++++++------------
net/netfilter/nft_set_hash.c | 1 -
sound/core/hrtimer.c | 1 +
sound/core/seq/oss/seq_oss_midi.c | 4 +-
sound/core/seq/oss/seq_oss_readq.c | 29 +++++
sound/core/seq/oss/seq_oss_readq.h | 2 +
sound/core/timer.c | 67 ++++++++---
sound/pci/hda/patch_realtek.c | 5 +
sound/usb/quirks.c | 1 +
46 files changed, 343 insertions(+), 193 deletions(-)
On Fri, Nov 10, 2017 at 04:44:00PM +0000, Mark Brown wrote:
>On Fri, Nov 10, 2017 at 05:36:32PM +0100, gregkh(a)linuxfoundation.org wrote:
>> On Fri, Nov 10, 2017 at 04:04:22PM +0000, alexander.levin(a)verizon.com wrote:
>
>> > - 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
>> > avoids conflicts later.
>
>> This commit claims the hardware is now supported by a different driver.
>> Is that support in 4.9? I couldn't figure it out :(
>From what I can tell its that way since 3.11.
>I suspect this isn't worth the effort - it's defintely more than a
>simple quirk anyway.
But as Mark points out, this is getting a bit too complicated and
risky.
--
Thanks,
Sasha
Tree/Branch: v3.2.95
Git describe: v3.2.95
Commit: 8518814021 Linux 3.2.95
Build Time: 0 min 3 sec
Passed: 0 / 4 ( 0.00 %)
Failed: 4 / 4 (100.00 %)
Errors: 6
Warnings: 20
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm-allmodconfig
19 warnings 0 mismatches : arm-allnoconfig
-------------------------------------------------------------------------------
Errors summary: 6
2 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
2 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
Warnings Summary: 20
2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
Warnings:
/home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.16.50
Git describe: v3.16.50
Commit: 2447a018c3 Linux 3.16.50
Build Time: 31 min 1 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 7
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
1 warnings 0 mismatches : arm64-allnoconfig
2 warnings 0 mismatches : arm64-allmodconfig
1 warnings 0 mismatches : arm-multi_v5_defconfig
1 warnings 0 mismatches : arm-multi_v7_defconfig
1 warnings 0 mismatches : x86_64-defconfig
4 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm-allnoconfig
1 warnings 0 mismatches : x86_64-allnoconfig
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 7
7 ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
2 ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
2 ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
1 ../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/media/platform/davinci/vpfe_capture.c:291:12: warning: 'vpfe_get_ccdc_image_format' defined but not used [-Wunused-function]
1 ../drivers/media/platform/davinci/vpfe_capture.c:1718:1: warning: label 'unlock_out' defined but not used [-Wunused-label]
1 ../arch/x86/kernel/cpu/common.c:961:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
../drivers/media/platform/davinci/vpfe_capture.c:1718:1: warning: label 'unlock_out' defined but not used [-Wunused-label]
../drivers/media/platform/davinci/vpfe_capture.c:291:12: warning: 'vpfe_get_ccdc_image_format' defined but not used [-Wunused-function]
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
-------------------------------------------------------------------------------
arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
x86_64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../arch/x86/kernel/cpu/common.c:961:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
On Mon, Nov 13, 2017 at 08:30:53AM +0100, H. Nikolaus Schaller wrote:
> Hi Johan,
>
> > Am 11.11.2017 um 16:43 schrieb Johan Hovold <johan(a)kernel.org>:
> >
> > Fix child-node lookup during probe, which ended up searching the whole
> > device tree depth-first starting at parent rather than just matching on
> > its children.
> >
> > Later sanity checks on node properties (which would likely be missing)
> > should prevent this from causing much trouble however, especially as the
> > original premature free of the parent node has already been fixed
> > separately (but that "fix" was apparently never backported to stable).
> >
> > Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support")
> > Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management")
> > Cc: stable <stable(a)vger.kernel.org> # 3.6
> > Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
> > Cc: H. Nikolaus Schaller <hns(a)goldelico.com>
> > Signed-off-by: Johan Hovold <johan(a)kernel.org>
>
> Tested-By: H. Nikolaus Schaller <hns(a)goldelico.com> (on Pyra OMAP5 hardware)
>
> I also tested your twl4030-vibra patch on GTA04.
>
> No regressions observed.
Thanks for testing.
Johan
This is a note to let you know that I've just added the patch titled
x86/smpboot: Make optimization of delay calibration work correctly
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:
x86-smpboot-make-optimization-of-delay-calibration-work-correctly.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 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b Mon Sep 17 00:00:00 2001
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Date: Fri, 27 Oct 2017 20:11:00 -0400
Subject: x86/smpboot: Make optimization of delay calibration work correctly
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
commit 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b upstream.
If the TSC has constant frequency then the delay calibration can be skipped
when it has been calibrated for a package already. This is checked in
calibrate_delay_is_known(), but that function is buggy in two aspects:
It returns 'false' if
(!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC)
which is obviously the reverse of the intended check and the check for the
sibling mask cannot work either because the topology links have not been
set up yet.
Correct the condition and move the call to set_cpu_sibling_map() before
invoking calibrate_delay() so the sibling check works correctly.
[ tglx: Rewrote changelong ]
Fixes: c25323c07345 ("x86/tsc: Use topology functions")
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: peterz(a)infradead.org
Cc: bob.picco(a)oracle.com
Cc: steven.sistare(a)oracle.com
Cc: daniel.m.jordan(a)oracle.com
Link: https://lkml.kernel.org/r/20171028001100.26603-1-pasha.tatashin@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/smpboot.c | 11 ++++++-----
arch/x86/kernel/tsc.c | 8 +++-----
2 files changed, 9 insertions(+), 10 deletions(-)
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -181,6 +181,12 @@ static void smp_callin(void)
smp_store_cpu_info(cpuid);
/*
+ * The topology information must be up to date before
+ * calibrate_delay() and notify_cpu_starting().
+ */
+ set_cpu_sibling_map(raw_smp_processor_id());
+
+ /*
* Get our bogomips.
* Update loops_per_jiffy in cpu_data. Previous call to
* smp_store_cpu_info() stored a value that is close but not as
@@ -190,11 +196,6 @@ static void smp_callin(void)
cpu_data(cpuid).loops_per_jiffy = loops_per_jiffy;
pr_debug("Stack at about %p\n", &cpuid);
- /*
- * This must be done before setting cpu_online_mask
- * or calling notify_cpu_starting.
- */
- set_cpu_sibling_map(raw_smp_processor_id());
wmb();
notify_cpu_starting(cpuid);
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1382,12 +1382,10 @@ void __init tsc_init(void)
unsigned long calibrate_delay_is_known(void)
{
int sibling, cpu = smp_processor_id();
- struct cpumask *mask = topology_core_cpumask(cpu);
+ int constant_tsc = cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC);
+ const struct cpumask *mask = topology_core_cpumask(cpu);
- if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC))
- return 0;
-
- if (!mask)
+ if (tsc_disabled || !constant_tsc || !mask)
return 0;
sibling = cpumask_any_but(mask, cpu);
Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are
queue-4.9/x86-smpboot-make-optimization-of-delay-calibration-work-correctly.patch
This is a note to let you know that I've just added the patch titled
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
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:
x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Tue, 7 Nov 2017 18:53:07 +0100
Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
From: Borislav Petkov <bp(a)suse.de>
commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.
The warning below says it all:
BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
caller is __this_cpu_preempt_check
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
Call Trace:
dump_stack
check_preemption_disabled
? do_early_param
__this_cpu_preempt_check
arch_perfmon_init
op_nmi_init
? alloc_pci_root_info
oprofile_arch_init
oprofile_init
do_one_initcall
...
These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>
Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Robert Richter <rric(a)kernel.org>
Cc: x86(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/op_model_ppro.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/oprofile/op_model_ppro.c
+++ b/arch/x86/oprofile/op_model_ppro.c
@@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters(
eax.full = cpuid_eax(0xa);
/* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */
- if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 &&
- __this_cpu_read(cpu_info.x86_model) == 15) {
+ if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 &&
+ boot_cpu_data.x86_model == 15) {
eax.split.version_id = 2;
eax.split.num_counters = 2;
eax.split.bit_width = 40;
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.9/edac-amd64-add-x86cpuid-sanity-check-during-init.patch
queue-4.9/edac-amd64-save-and-return-err-code-from-probe_one_instance.patch
queue-4.9/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch
This is a note to let you know that I've just added the patch titled
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
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:
x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Tue, 7 Nov 2017 18:53:07 +0100
Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
From: Borislav Petkov <bp(a)suse.de>
commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.
The warning below says it all:
BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
caller is __this_cpu_preempt_check
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
Call Trace:
dump_stack
check_preemption_disabled
? do_early_param
__this_cpu_preempt_check
arch_perfmon_init
op_nmi_init
? alloc_pci_root_info
oprofile_arch_init
oprofile_init
do_one_initcall
...
These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>
Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Robert Richter <rric(a)kernel.org>
Cc: x86(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/op_model_ppro.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/oprofile/op_model_ppro.c
+++ b/arch/x86/oprofile/op_model_ppro.c
@@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters(
eax.full = cpuid_eax(0xa);
/* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */
- if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 &&
- __this_cpu_read(cpu_info.x86_model) == 15) {
+ if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 &&
+ boot_cpu_data.x86_model == 15) {
eax.split.version_id = 2;
eax.split.num_counters = 2;
eax.split.bit_width = 40;
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.4/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch
This is a note to let you know that I've just added the patch titled
PKCS#7: fix unitialized boolean 'want'
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:
pkcs-7-fix-unitialized-boolean-want.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 06aae592425701851e02bb850cb9f4997f0ae163 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Sat, 27 Feb 2016 12:45:26 +0000
Subject: PKCS#7: fix unitialized boolean 'want'
From: Colin Ian King <colin.king(a)canonical.com>
commit 06aae592425701851e02bb850cb9f4997f0ae163 upstream.
The boolean want is not initialized and hence garbage. The default should
be false (later it is only set to true on tne sinfo->authattrs check).
Found with static analysis using CoverityScan
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/pkcs7_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -87,7 +87,7 @@ EXPORT_SYMBOL_GPL(pkcs7_free_message);
static int pkcs7_check_authattrs(struct pkcs7_message *msg)
{
struct pkcs7_signed_info *sinfo;
- bool want;
+ bool want = false;
sinfo = msg->signed_infos;
if (!sinfo)
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.4/pkcs-7-fix-unitialized-boolean-want.patch
This is a note to let you know that I've just added the patch titled
x86/smpboot: Make optimization of delay calibration work correctly
to the 4.13-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:
x86-smpboot-make-optimization-of-delay-calibration-work-correctly.patch
and it can be found in the queue-4.13 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 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b Mon Sep 17 00:00:00 2001
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Date: Fri, 27 Oct 2017 20:11:00 -0400
Subject: x86/smpboot: Make optimization of delay calibration work correctly
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
commit 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b upstream.
If the TSC has constant frequency then the delay calibration can be skipped
when it has been calibrated for a package already. This is checked in
calibrate_delay_is_known(), but that function is buggy in two aspects:
It returns 'false' if
(!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC)
which is obviously the reverse of the intended check and the check for the
sibling mask cannot work either because the topology links have not been
set up yet.
Correct the condition and move the call to set_cpu_sibling_map() before
invoking calibrate_delay() so the sibling check works correctly.
[ tglx: Rewrote changelong ]
Fixes: c25323c07345 ("x86/tsc: Use topology functions")
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: peterz(a)infradead.org
Cc: bob.picco(a)oracle.com
Cc: steven.sistare(a)oracle.com
Cc: daniel.m.jordan(a)oracle.com
Link: https://lkml.kernel.org/r/20171028001100.26603-1-pasha.tatashin@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/smpboot.c | 11 ++++++-----
arch/x86/kernel/tsc.c | 8 +++-----
2 files changed, 9 insertions(+), 10 deletions(-)
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -194,6 +194,12 @@ static void smp_callin(void)
smp_store_cpu_info(cpuid);
/*
+ * The topology information must be up to date before
+ * calibrate_delay() and notify_cpu_starting().
+ */
+ set_cpu_sibling_map(raw_smp_processor_id());
+
+ /*
* Get our bogomips.
* Update loops_per_jiffy in cpu_data. Previous call to
* smp_store_cpu_info() stored a value that is close but not as
@@ -203,11 +209,6 @@ static void smp_callin(void)
cpu_data(cpuid).loops_per_jiffy = loops_per_jiffy;
pr_debug("Stack at about %p\n", &cpuid);
- /*
- * This must be done before setting cpu_online_mask
- * or calling notify_cpu_starting.
- */
- set_cpu_sibling_map(raw_smp_processor_id());
wmb();
notify_cpu_starting(cpuid);
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1346,12 +1346,10 @@ void __init tsc_init(void)
unsigned long calibrate_delay_is_known(void)
{
int sibling, cpu = smp_processor_id();
- struct cpumask *mask = topology_core_cpumask(cpu);
+ int constant_tsc = cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC);
+ const struct cpumask *mask = topology_core_cpumask(cpu);
- if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC))
- return 0;
-
- if (!mask)
+ if (tsc_disabled || !constant_tsc || !mask)
return 0;
sibling = cpumask_any_but(mask, cpu);
Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are
queue-4.13/x86-smpboot-make-optimization-of-delay-calibration-work-correctly.patch
This is a note to let you know that I've just added the patch titled
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
to the 4.13-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:
x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch
and it can be found in the queue-4.13 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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Tue, 7 Nov 2017 18:53:07 +0100
Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
From: Borislav Petkov <bp(a)suse.de>
commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.
The warning below says it all:
BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
caller is __this_cpu_preempt_check
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
Call Trace:
dump_stack
check_preemption_disabled
? do_early_param
__this_cpu_preempt_check
arch_perfmon_init
op_nmi_init
? alloc_pci_root_info
oprofile_arch_init
oprofile_init
do_one_initcall
...
These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>
Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Robert Richter <rric(a)kernel.org>
Cc: x86(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/op_model_ppro.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/oprofile/op_model_ppro.c
+++ b/arch/x86/oprofile/op_model_ppro.c
@@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters(
eax.full = cpuid_eax(0xa);
/* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */
- if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 &&
- __this_cpu_read(cpu_info.x86_model) == 15) {
+ if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 &&
+ boot_cpu_data.x86_model == 15) {
eax.split.version_id = 2;
eax.split.num_counters = 2;
eax.split.bit_width = 40;
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-4.13/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch
This is a note to let you know that I've just added the patch titled
x86/debug: Handle warnings before the notifier chain, to fix KGDB crash
to the 4.13-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:
x86-debug-handle-warnings-before-the-notifier-chain-to-fix-kgdb-crash.patch
and it can be found in the queue-4.13 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 b8347c2196492f4e1cccde3d92fda1cc2cc7de7e Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Date: Mon, 24 Jul 2017 13:04:28 +0300
Subject: x86/debug: Handle warnings before the notifier chain, to fix KGDB crash
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
commit b8347c2196492f4e1cccde3d92fda1cc2cc7de7e upstream.
Commit:
9a93848fe787 ("x86/debug: Implement __WARN() using UD0")
turned warnings into UD0, but the fixup code only runs after the
notify_die() chain. This is a problem, in particular, with kgdb,
which kicks in as if it was a BUG().
Fix this by running the fixup code before the notifier chain in
the invalid op handler path.
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Tested-by: Ilya Dryomov <idryomov(a)gmail.com>
Acked-by: Daniel Thompson <daniel.thompson(a)linaro.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Jason Wessel <jason.wessel(a)windriver.com>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Richard Weinberger <richard.weinberger(a)gmail.com>
Link: http://lkml.kernel.org/r/20170724100428.19173-1-alexander.shishkin@linux.in…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/traps.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -221,9 +221,6 @@ do_trap_no_signal(struct task_struct *ts
if (fixup_exception(regs, trapnr))
return 0;
- if (fixup_bug(regs, trapnr))
- return 0;
-
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = trapnr;
die(str, regs, error_code);
@@ -304,6 +301,13 @@ static void do_error_trap(struct pt_regs
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
+ /*
+ * WARN*()s end up here; fix them up before we call the
+ * notifier chain.
+ */
+ if (!user_mode(regs) && fixup_bug(regs, trapnr))
+ return;
+
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
cond_local_irq_enable(regs);
Patches currently in stable-queue which might be from alexander.shishkin(a)linux.intel.com are
queue-4.13/x86-debug-handle-warnings-before-the-notifier-chain-to-fix-kgdb-crash.patch
Please cherry-pick this fix for 4.4 and later stable branches:
commit 06aae592425701851e02bb850cb9f4997f0ae163
Author: Colin Ian King <colin.king(a)canonical.com>
Date:Â Â Â Sat Feb 27 12:45:26 2016 +0000
    PKCS#7: fix unitialized boolean 'want'
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
This is a note to let you know that I've just added the patch titled
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
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:
x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp(a)suse.de>
Date: Tue, 7 Nov 2017 18:53:07 +0100
Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
From: Borislav Petkov <bp(a)suse.de>
commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.
The warning below says it all:
BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
caller is __this_cpu_preempt_check
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
Call Trace:
dump_stack
check_preemption_disabled
? do_early_param
__this_cpu_preempt_check
arch_perfmon_init
op_nmi_init
? alloc_pci_root_info
oprofile_arch_init
oprofile_init
do_one_initcall
...
These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>
Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Robert Richter <rric(a)kernel.org>
Cc: x86(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/op_model_ppro.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/oprofile/op_model_ppro.c
+++ b/arch/x86/oprofile/op_model_ppro.c
@@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters(
eax.full = cpuid_eax(0xa);
/* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */
- if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 &&
- __this_cpu_read(cpu_info.x86_model) == 15) {
+ if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 &&
+ boot_cpu_data.x86_model == 15) {
eax.split.version_id = 2;
eax.split.num_counters = 2;
eax.split.bit_width = 40;
Patches currently in stable-queue which might be from bp(a)suse.de are
queue-3.18/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch
This is a note to let you know that I've just added the patch titled
netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
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:
netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.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 e1bf1687740ce1a3598a1c5e452b852ff2190682 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Wed, 6 Sep 2017 14:39:51 +0200
Subject: netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
From: Florian Westphal <fw(a)strlen.de>
commit e1bf1687740ce1a3598a1c5e452b852ff2190682 upstream.
This reverts commit 870190a9ec9075205c0fa795a09fa931694a3ff1.
It was not a good idea. The custom hash table was a much better
fit for this purpose.
A fast lookup is not essential, in fact for most cases there is no lookup
at all because original tuple is not taken and can be used as-is.
What needs to be fast is insertion and deletion.
rhlist removal however requires a rhlist walk.
We can have thousands of entries in such a list if source port/addresses
are reused for multiple flows, if this happens removal requests are so
expensive that deletions of a few thousand flows can take several
seconds(!).
The advantages that we got from rhashtable are:
1) table auto-sizing
2) multiple locks
1) would be nice to have, but it is not essential as we have at
most one lookup per new flow, so even a million flows in the bysource
table are not a problem compared to current deletion cost.
2) is easy to add to custom hash table.
I tried to add hlist_node to rhlist to speed up rhltable_remove but this
isn't doable without changing semantics. rhltable_remove_fast will
check that the to-be-deleted object is part of the table and that
requires a list walk that we want to avoid.
Furthermore, using hlist_node increases size of struct rhlist_head, which
in turn increases nf_conn size.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196821
Reported-by: Ivan Babrou <ibobrik(a)gmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/netfilter/nf_conntrack.h | 3
include/net/netfilter/nf_nat.h | 1
net/netfilter/nf_nat_core.c | 131 ++++++++++++++---------------------
3 files changed, 56 insertions(+), 79 deletions(-)
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -17,7 +17,6 @@
#include <linux/bitops.h>
#include <linux/compiler.h>
#include <linux/atomic.h>
-#include <linux/rhashtable.h>
#include <linux/netfilter/nf_conntrack_tcp.h>
#include <linux/netfilter/nf_conntrack_dccp.h>
@@ -101,7 +100,7 @@ struct nf_conn {
possible_net_t ct_net;
#if IS_ENABLED(CONFIG_NF_NAT)
- struct rhlist_head nat_bysource;
+ struct hlist_node nat_bysource;
#endif
/* all members below initialized via memset */
u8 __nfct_init_offset[0];
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -1,6 +1,5 @@
#ifndef _NF_NAT_H
#define _NF_NAT_H
-#include <linux/rhashtable.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netfilter/nf_nat.h>
#include <net/netfilter/nf_conntrack_tuple.h>
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -30,19 +30,17 @@
#include <net/netfilter/nf_conntrack_zones.h>
#include <linux/netfilter/nf_nat.h>
+static DEFINE_SPINLOCK(nf_nat_lock);
+
static DEFINE_MUTEX(nf_nat_proto_mutex);
static const struct nf_nat_l3proto __rcu *nf_nat_l3protos[NFPROTO_NUMPROTO]
__read_mostly;
static const struct nf_nat_l4proto __rcu **nf_nat_l4protos[NFPROTO_NUMPROTO]
__read_mostly;
-struct nf_nat_conn_key {
- const struct net *net;
- const struct nf_conntrack_tuple *tuple;
- const struct nf_conntrack_zone *zone;
-};
-
-static struct rhltable nf_nat_bysource_table;
+static struct hlist_head *nf_nat_bysource __read_mostly;
+static unsigned int nf_nat_htable_size __read_mostly;
+static unsigned int nf_nat_hash_rnd __read_mostly;
inline const struct nf_nat_l3proto *
__nf_nat_l3proto_find(u8 family)
@@ -121,17 +119,19 @@ int nf_xfrm_me_harder(struct net *net, s
EXPORT_SYMBOL(nf_xfrm_me_harder);
#endif /* CONFIG_XFRM */
-static u32 nf_nat_bysource_hash(const void *data, u32 len, u32 seed)
+/* We keep an extra hash for each conntrack, for fast searching. */
+static inline unsigned int
+hash_by_src(const struct net *n, const struct nf_conntrack_tuple *tuple)
{
- const struct nf_conntrack_tuple *t;
- const struct nf_conn *ct = data;
+ unsigned int hash;
+
+ get_random_once(&nf_nat_hash_rnd, sizeof(nf_nat_hash_rnd));
- t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
/* Original src, to ensure we map it consistently if poss. */
+ hash = jhash2((u32 *)&tuple->src, sizeof(tuple->src) / sizeof(u32),
+ tuple->dst.protonum ^ nf_nat_hash_rnd ^ net_hash_mix(n));
- seed ^= net_hash_mix(nf_ct_net(ct));
- return jhash2((const u32 *)&t->src, sizeof(t->src) / sizeof(u32),
- t->dst.protonum ^ seed);
+ return reciprocal_scale(hash, nf_nat_htable_size);
}
/* Is this tuple already taken? (not by us) */
@@ -187,28 +187,6 @@ same_src(const struct nf_conn *ct,
t->src.u.all == tuple->src.u.all);
}
-static int nf_nat_bysource_cmp(struct rhashtable_compare_arg *arg,
- const void *obj)
-{
- const struct nf_nat_conn_key *key = arg->key;
- const struct nf_conn *ct = obj;
-
- if (!same_src(ct, key->tuple) ||
- !net_eq(nf_ct_net(ct), key->net) ||
- !nf_ct_zone_equal(ct, key->zone, IP_CT_DIR_ORIGINAL))
- return 1;
-
- return 0;
-}
-
-static struct rhashtable_params nf_nat_bysource_params = {
- .head_offset = offsetof(struct nf_conn, nat_bysource),
- .obj_hashfn = nf_nat_bysource_hash,
- .obj_cmpfn = nf_nat_bysource_cmp,
- .nelem_hint = 256,
- .min_size = 1024,
-};
-
/* Only called for SRC manip */
static int
find_appropriate_src(struct net *net,
@@ -219,26 +197,22 @@ find_appropriate_src(struct net *net,
struct nf_conntrack_tuple *result,
const struct nf_nat_range *range)
{
+ unsigned int h = hash_by_src(net, tuple);
const struct nf_conn *ct;
- struct nf_nat_conn_key key = {
- .net = net,
- .tuple = tuple,
- .zone = zone
- };
- struct rhlist_head *hl, *h;
-
- hl = rhltable_lookup(&nf_nat_bysource_table, &key,
- nf_nat_bysource_params);
- rhl_for_each_entry_rcu(ct, h, hl, nat_bysource) {
- nf_ct_invert_tuplepr(result,
- &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
- result->dst = tuple->dst;
+ hlist_for_each_entry_rcu(ct, &nf_nat_bysource[h], nat_bysource) {
+ if (same_src(ct, tuple) &&
+ net_eq(net, nf_ct_net(ct)) &&
+ nf_ct_zone_equal(ct, zone, IP_CT_DIR_ORIGINAL)) {
+ /* Copy source part from reply tuple. */
+ nf_ct_invert_tuplepr(result,
+ &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
+ result->dst = tuple->dst;
- if (in_range(l3proto, l4proto, result, range))
- return 1;
+ if (in_range(l3proto, l4proto, result, range))
+ return 1;
+ }
}
-
return 0;
}
@@ -411,6 +385,7 @@ nf_nat_setup_info(struct nf_conn *ct,
const struct nf_nat_range *range,
enum nf_nat_manip_type maniptype)
{
+ struct net *net = nf_ct_net(ct);
struct nf_conntrack_tuple curr_tuple, new_tuple;
struct nf_conn_nat *nat;
@@ -452,19 +427,16 @@ nf_nat_setup_info(struct nf_conn *ct,
}
if (maniptype == NF_NAT_MANIP_SRC) {
- struct nf_nat_conn_key key = {
- .net = nf_ct_net(ct),
- .tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
- .zone = nf_ct_zone(ct),
- };
- int err;
-
- err = rhltable_insert_key(&nf_nat_bysource_table,
- &key,
- &ct->nat_bysource,
- nf_nat_bysource_params);
- if (err)
- return NF_DROP;
+ unsigned int srchash;
+
+ srchash = hash_by_src(net,
+ &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+ spin_lock_bh(&nf_nat_lock);
+ /* nf_conntrack_alter_reply might re-allocate extension aera */
+ nat = nfct_nat(ct);
+ hlist_add_head_rcu(&ct->nat_bysource,
+ &nf_nat_bysource[srchash]);
+ spin_unlock_bh(&nf_nat_lock);
}
/* It's done. */
@@ -578,9 +550,10 @@ static int nf_nat_proto_clean(struct nf_
* Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack()
* will delete entry from already-freed table.
*/
+ spin_lock_bh(&nf_nat_lock);
+ hlist_del_rcu(&ct->nat_bysource);
ct->status &= ~IPS_NAT_DONE_MASK;
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ spin_unlock_bh(&nf_nat_lock);
/* don't delete conntrack. Although that would make things a lot
* simpler, we'd end up flushing all conntracks on nat rmmod.
@@ -710,8 +683,11 @@ static void nf_nat_cleanup_conntrack(str
if (!nat)
return;
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ NF_CT_ASSERT(ct->status & IPS_SRC_NAT_DONE);
+
+ spin_lock_bh(&nf_nat_lock);
+ hlist_del_rcu(&ct->nat_bysource);
+ spin_unlock_bh(&nf_nat_lock);
}
static struct nf_ct_ext_type nat_extend __read_mostly = {
@@ -846,13 +822,16 @@ static int __init nf_nat_init(void)
{
int ret;
- ret = rhltable_init(&nf_nat_bysource_table, &nf_nat_bysource_params);
- if (ret)
- return ret;
+ /* Leave them the same for the moment. */
+ nf_nat_htable_size = nf_conntrack_htable_size;
+
+ nf_nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size, 0);
+ if (!nf_nat_bysource)
+ return -ENOMEM;
ret = nf_ct_extend_register(&nat_extend);
if (ret < 0) {
- rhltable_destroy(&nf_nat_bysource_table);
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
printk(KERN_ERR "nf_nat_core: Unable to register extension\n");
return ret;
}
@@ -876,7 +855,7 @@ static int __init nf_nat_init(void)
return 0;
cleanup_extend:
- rhltable_destroy(&nf_nat_bysource_table);
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
nf_ct_extend_unregister(&nat_extend);
return ret;
}
@@ -896,8 +875,8 @@ static void __exit nf_nat_cleanup(void)
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
-
- rhltable_destroy(&nf_nat_bysource_table);
+ synchronize_net();
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
}
MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.9/netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch
Sometimes, a processor might execute an instruction while another
processor is updating the page tables for that instruction's code page,
but before the TLB shootdown completes. The interesting case happens
if the page is in the TLB.
In general, the processor will succeed in executing the instruction and
nothing bad happens. However, what if the instruction is an MMIO access?
If *that* happens, KVM invokes the emulator, and the emulator gets the
updated page tables. If the update side had marked the code page as non
present, the page table walk then will fail and so will x86_decode_insn.
Unfortunately, even though kvm_fetch_guest_virt is correctly returning
X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as
a fatal error if the instruction cannot simply be reexecuted (as is the
case for MMIO). And this in fact happened sometimes when rebooting
Windows 2012r2 guests. Just checking ctxt->have_exception and injecting
the exception if true is enough to fix the case.
Thanks to Eduardo Habkost for helping in the debugging of this issue.
Reported-by: Yanan Fu <yfu(a)redhat.com>
Cc: Eduardo Habkost <ehabkost(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
arch/x86/kvm/x86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 34c85aa2e2d1..6dbed9022797 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5722,6 +5722,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu,
if (reexecute_instruction(vcpu, cr2, write_fault_to_spt,
emulation_type))
return EMULATE_DONE;
+ if (ctxt->have_exception && inject_emulated_exception(vcpu))
+ return EMULATE_DONE;
if (emulation_type & EMULTYPE_SKIP)
return EMULATE_FAIL;
return handle_emulation_failure(vcpu);
--
1.8.3.1
Hi Ben,
On Tue, Nov 07, 2017 at 01:42:35PM +0000, Ben Hutchings wrote:
> That function didn't exist in 3.16 (at least not under that name).
Ah, you're right, back then the netlink interface did not
exist in batman-adv yet, only the debugfs one.
batadv_tt_global_print_entry would be the equivalent function
for debugfs. But not worth the effort now, in my opinion.
I'm fine with this proposed patch for 3.16 now. Thanks for the
clarification! And I'm happy to see this patch backported.
Regards, Linus
This is a note to let you know that I've just added the patch titled
can: sun4i: handle overrun in RX FIFO
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:
can-sun4i-handle-overrun-in-rx-fifo.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 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 Mon Sep 17 00:00:00 2001
From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
Date: Mon, 6 Nov 2017 18:16:56 +0100
Subject: can: sun4i: handle overrun in RX FIFO
From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream.
SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not
drained fast enough (overrun) it's getting mangled. Already received
frames are dropped - the data can't be restored.
Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/sun4i_can.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/net/can/sun4i_can.c
+++ b/drivers/net/can/sun4i_can.c
@@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi
}
stats->rx_over_errors++;
stats->rx_errors++;
+
+ /* reset the CAN IP by entering reset mode
+ * ignoring timeout error
+ */
+ set_reset_mode(dev);
+ set_normal_mode(dev);
+
/* clear bit */
sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG);
}
@@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(i
netif_wake_queue(dev);
can_led_event(dev, CAN_LED_EVENT_TX);
}
- if (isrc & SUN4I_INT_RBUF_VLD) {
- /* receive interrupt */
+ if ((isrc & SUN4I_INT_RBUF_VLD) &&
+ !(isrc & SUN4I_INT_DATA_OR)) {
+ /* receive interrupt - don't read if overrun occurred */
while (status & SUN4I_STA_RBUF_RDY) {
/* RX buffer is not empty */
sun4i_can_rx(dev);
Patches currently in stable-queue which might be from info(a)gerhard-bertelsmann.de are
queue-4.9/can-sun4i-handle-overrun-in-rx-fifo.patch
This is a note to let you know that I've just added the patch titled
can: ifi: Fix transmitter delay calculation
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:
can-ifi-fix-transmitter-delay-calculation.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 4f7116757b4bd99e4ef2636c7d957a6d63035d11 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex(a)denx.de>
Date: Fri, 10 Nov 2017 11:22:39 +0100
Subject: can: ifi: Fix transmitter delay calculation
From: Marek Vasut <marex(a)denx.de>
commit 4f7116757b4bd99e4ef2636c7d957a6d63035d11 upstream.
The CANFD transmitter delay calculation formula was updated in the
latest software drop from IFI and improves the behavior of the IFI
CANFD core during bitrate switching. Use the new formula to improve
stability of the CANFD operation.
Signed-off-by: Marek Vasut <marex(a)denx.de>
Cc: Markus Marb <markus(a)marb.org>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -670,9 +670,9 @@ static void ifi_canfd_set_bittiming(stru
priv->base + IFI_CANFD_FTIME);
/* Configure transmitter delay */
- tdc = (dbt->brp * (dbt->phase_seg1 + 1)) & IFI_CANFD_TDELAY_MASK;
- writel(IFI_CANFD_TDELAY_EN | IFI_CANFD_TDELAY_ABS | tdc,
- priv->base + IFI_CANFD_TDELAY);
+ tdc = dbt->brp * (dbt->prop_seg + dbt->phase_seg1);
+ tdc &= IFI_CANFD_TDELAY_MASK;
+ writel(IFI_CANFD_TDELAY_EN | tdc, priv->base + IFI_CANFD_TDELAY);
}
static void ifi_canfd_set_filter(struct net_device *ndev, const u32 id,
Patches currently in stable-queue which might be from marex(a)denx.de are
queue-4.9/can-ifi-fix-transmitter-delay-calculation.patch
This is a note to let you know that I've just added the patch titled
can: c_can: don't indicate triple sampling support for D_CAN
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:
can-c_can-don-t-indicate-triple-sampling-support-for-d_can.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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de>
Date: Sun, 29 Oct 2017 13:03:22 +0100
Subject: can: c_can: don't indicate triple sampling support for D_CAN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Richard Schütz <rschuetz(a)uni-koblenz.de>
commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream.
The D_CAN controller doesn't provide a triple sampling mode, so don't set
the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling
triple sampling is a no-op.
Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
2 files changed, 2 deletions(-)
--- a/drivers/net/can/c_can/c_can_pci.c
+++ b/drivers/net/can/c_can/c_can_pci.c
@@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_de
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
break;
default:
ret = -EINVAL;
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platf
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
priv->read_reg32 = d_can_plat_read_reg32;
Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are
queue-4.9/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch
This is a note to let you know that I've just added the patch titled
can: sun4i: handle overrun in RX FIFO
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:
can-sun4i-handle-overrun-in-rx-fifo.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 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 Mon Sep 17 00:00:00 2001
From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
Date: Mon, 6 Nov 2017 18:16:56 +0100
Subject: can: sun4i: handle overrun in RX FIFO
From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream.
SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not
drained fast enough (overrun) it's getting mangled. Already received
frames are dropped - the data can't be restored.
Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/sun4i_can.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/net/can/sun4i_can.c
+++ b/drivers/net/can/sun4i_can.c
@@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi
}
stats->rx_over_errors++;
stats->rx_errors++;
+
+ /* reset the CAN IP by entering reset mode
+ * ignoring timeout error
+ */
+ set_reset_mode(dev);
+ set_normal_mode(dev);
+
/* clear bit */
sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG);
}
@@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(i
netif_wake_queue(dev);
can_led_event(dev, CAN_LED_EVENT_TX);
}
- if (isrc & SUN4I_INT_RBUF_VLD) {
- /* receive interrupt */
+ if ((isrc & SUN4I_INT_RBUF_VLD) &&
+ !(isrc & SUN4I_INT_DATA_OR)) {
+ /* receive interrupt - don't read if overrun occurred */
while (status & SUN4I_STA_RBUF_RDY) {
/* RX buffer is not empty */
sun4i_can_rx(dev);
Patches currently in stable-queue which might be from info(a)gerhard-bertelsmann.de are
queue-4.4/can-sun4i-handle-overrun-in-rx-fifo.patch
This is a note to let you know that I've just added the patch titled
can: c_can: don't indicate triple sampling support for D_CAN
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:
can-c_can-don-t-indicate-triple-sampling-support-for-d_can.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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de>
Date: Sun, 29 Oct 2017 13:03:22 +0100
Subject: can: c_can: don't indicate triple sampling support for D_CAN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Richard Schütz <rschuetz(a)uni-koblenz.de>
commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream.
The D_CAN controller doesn't provide a triple sampling mode, so don't set
the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling
triple sampling is a no-op.
Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
2 files changed, 2 deletions(-)
--- a/drivers/net/can/c_can/c_can_pci.c
+++ b/drivers/net/can/c_can/c_can_pci.c
@@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_de
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
break;
default:
ret = -EINVAL;
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platf
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
priv->read_reg32 = d_can_plat_read_reg32;
Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are
queue-4.4/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch
This is a note to let you know that I've just added the patch titled
can: sun4i: handle overrun in RX FIFO
to the 4.13-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:
can-sun4i-handle-overrun-in-rx-fifo.patch
and it can be found in the queue-4.13 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 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 Mon Sep 17 00:00:00 2001
From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
Date: Mon, 6 Nov 2017 18:16:56 +0100
Subject: can: sun4i: handle overrun in RX FIFO
From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream.
SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not
drained fast enough (overrun) it's getting mangled. Already received
frames are dropped - the data can't be restored.
Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/sun4i_can.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/net/can/sun4i_can.c
+++ b/drivers/net/can/sun4i_can.c
@@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi
}
stats->rx_over_errors++;
stats->rx_errors++;
+
+ /* reset the CAN IP by entering reset mode
+ * ignoring timeout error
+ */
+ set_reset_mode(dev);
+ set_normal_mode(dev);
+
/* clear bit */
sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG);
}
@@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(i
netif_wake_queue(dev);
can_led_event(dev, CAN_LED_EVENT_TX);
}
- if (isrc & SUN4I_INT_RBUF_VLD) {
- /* receive interrupt */
+ if ((isrc & SUN4I_INT_RBUF_VLD) &&
+ !(isrc & SUN4I_INT_DATA_OR)) {
+ /* receive interrupt - don't read if overrun occurred */
while (status & SUN4I_STA_RBUF_RDY) {
/* RX buffer is not empty */
sun4i_can_rx(dev);
Patches currently in stable-queue which might be from info(a)gerhard-bertelsmann.de are
queue-4.13/can-sun4i-handle-overrun-in-rx-fifo.patch
This is a note to let you know that I've just added the patch titled
can: ifi: Fix transmitter delay calculation
to the 4.13-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:
can-ifi-fix-transmitter-delay-calculation.patch
and it can be found in the queue-4.13 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 4f7116757b4bd99e4ef2636c7d957a6d63035d11 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex(a)denx.de>
Date: Fri, 10 Nov 2017 11:22:39 +0100
Subject: can: ifi: Fix transmitter delay calculation
From: Marek Vasut <marex(a)denx.de>
commit 4f7116757b4bd99e4ef2636c7d957a6d63035d11 upstream.
The CANFD transmitter delay calculation formula was updated in the
latest software drop from IFI and improves the behavior of the IFI
CANFD core during bitrate switching. Use the new formula to improve
stability of the CANFD operation.
Signed-off-by: Marek Vasut <marex(a)denx.de>
Cc: Markus Marb <markus(a)marb.org>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -670,9 +670,9 @@ static void ifi_canfd_set_bittiming(stru
priv->base + IFI_CANFD_FTIME);
/* Configure transmitter delay */
- tdc = (dbt->brp * (dbt->phase_seg1 + 1)) & IFI_CANFD_TDELAY_MASK;
- writel(IFI_CANFD_TDELAY_EN | IFI_CANFD_TDELAY_ABS | tdc,
- priv->base + IFI_CANFD_TDELAY);
+ tdc = dbt->brp * (dbt->prop_seg + dbt->phase_seg1);
+ tdc &= IFI_CANFD_TDELAY_MASK;
+ writel(IFI_CANFD_TDELAY_EN | tdc, priv->base + IFI_CANFD_TDELAY);
}
static void ifi_canfd_set_filter(struct net_device *ndev, const u32 id,
Patches currently in stable-queue which might be from marex(a)denx.de are
queue-4.13/can-ifi-fix-transmitter-delay-calculation.patch
This is a note to let you know that I've just added the patch titled
can: peak: Add support for new PCIe/M2 CAN FD interfaces
to the 4.13-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:
can-peak-add-support-for-new-pcie-m2-can-fd-interfaces.patch
and it can be found in the queue-4.13 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 4cbdd0ee67191481ec57ceed94febdfef95c9f25 Mon Sep 17 00:00:00 2001
From: Stephane Grosjean <s.grosjean(a)peak-system.com>
Date: Thu, 9 Nov 2017 14:42:14 +0100
Subject: can: peak: Add support for new PCIe/M2 CAN FD interfaces
From: Stephane Grosjean <s.grosjean(a)peak-system.com>
commit 4cbdd0ee67191481ec57ceed94febdfef95c9f25 upstream.
This adds support for the following PEAK-System CAN FD interfaces:
PCAN-cPCIe FD CAN FD Interface for cPCI Serial (2 or 4 channels)
PCAN-PCIe/104-Express CAN FD Interface for PCIe/104-Express (1, 2 or 4 ch.)
PCAN-miniPCIe FD CAN FD Interface for PCIe Mini (1, 2 or 4 channels)
PCAN-PCIe FD OEM CAN FD Interface for PCIe OEM version (1, 2 or 4 ch.)
PCAN-M.2 CAN FD Interface for M.2 (1 or 2 channels)
Like the PCAN-PCIe FD interface, all of these boards run the same IP Core
that is able to handle CAN FD (see also http://www.peak-system.com).
Signed-off-by: Stephane Grosjean <s.grosjean(a)peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/peak_canfd/peak_pciefd_main.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/net/can/peak_canfd/peak_pciefd_main.c
+++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c
@@ -29,14 +29,19 @@
#include "peak_canfd_user.h"
MODULE_AUTHOR("Stephane Grosjean <s.grosjean(a)peak-system.com>");
-MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCIe FD family cards");
-MODULE_SUPPORTED_DEVICE("PEAK PCAN PCIe FD CAN cards");
+MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCIe/M.2 FD family cards");
+MODULE_SUPPORTED_DEVICE("PEAK PCAN PCIe/M.2 FD CAN cards");
MODULE_LICENSE("GPL v2");
#define PCIEFD_DRV_NAME "peak_pciefd"
#define PEAK_PCI_VENDOR_ID 0x001c /* The PCI device and vendor IDs */
#define PEAK_PCIEFD_ID 0x0013 /* for PCIe slot cards */
+#define PCAN_CPCIEFD_ID 0x0014 /* for Compact-PCI Serial slot cards */
+#define PCAN_PCIE104FD_ID 0x0017 /* for PCIe-104 Express slot cards */
+#define PCAN_MINIPCIEFD_ID 0x0018 /* for mini-PCIe slot cards */
+#define PCAN_PCIEFD_OEM_ID 0x0019 /* for PCIe slot OEM cards */
+#define PCAN_M2_ID 0x001a /* for M2 slot cards */
/* PEAK PCIe board access description */
#define PCIEFD_BAR0_SIZE (64 * 1024)
@@ -203,6 +208,11 @@ struct pciefd_board {
/* supported device ids. */
static const struct pci_device_id peak_pciefd_tbl[] = {
{PEAK_PCI_VENDOR_ID, PEAK_PCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PCAN_CPCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PCAN_PCIE104FD_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PCAN_MINIPCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PCAN_PCIEFD_OEM_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PCAN_M2_ID, PCI_ANY_ID, PCI_ANY_ID,},
{0,}
};
Patches currently in stable-queue which might be from s.grosjean(a)peak-system.com are
queue-4.13/can-peak-add-support-for-new-pcie-m2-can-fd-interfaces.patch
This is a note to let you know that I've just added the patch titled
can: c_can: don't indicate triple sampling support for D_CAN
to the 4.13-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:
can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch
and it can be found in the queue-4.13 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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de>
Date: Sun, 29 Oct 2017 13:03:22 +0100
Subject: can: c_can: don't indicate triple sampling support for D_CAN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Richard Schütz <rschuetz(a)uni-koblenz.de>
commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream.
The D_CAN controller doesn't provide a triple sampling mode, so don't set
the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling
triple sampling is a no-op.
Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
2 files changed, 2 deletions(-)
--- a/drivers/net/can/c_can/c_can_pci.c
+++ b/drivers/net/can/c_can/c_can_pci.c
@@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_de
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
break;
default:
ret = -EINVAL;
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platf
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
priv->read_reg32 = d_can_plat_read_reg32;
Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are
queue-4.13/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch
This is a note to let you know that I've just added the patch titled
can: c_can: don't indicate triple sampling support for D_CAN
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:
can-c_can-don-t-indicate-triple-sampling-support-for-d_can.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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de>
Date: Sun, 29 Oct 2017 13:03:22 +0100
Subject: can: c_can: don't indicate triple sampling support for D_CAN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Richard Schütz <rschuetz(a)uni-koblenz.de>
commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream.
The D_CAN controller doesn't provide a triple sampling mode, so don't set
the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling
triple sampling is a no-op.
Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
2 files changed, 2 deletions(-)
--- a/drivers/net/can/c_can/c_can_pci.c
+++ b/drivers/net/can/c_can/c_can_pci.c
@@ -177,7 +177,6 @@ static int c_can_pci_probe(struct pci_de
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
break;
default:
ret = -EINVAL;
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -257,7 +257,6 @@ static int c_can_plat_probe(struct platf
break;
case BOSCH_D_CAN:
priv->regs = reg_map_d_can;
- priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
priv->read_reg32 = d_can_plat_read_reg32;
Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are
queue-3.18/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch
Commit e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs
entries") tried to make MTD related debugfs stuff consistent across the
MTD framework by creating a root <debugfs>/mtd/ directory containing
one directory per MTD device.
The problem is that, by default, the MTD layer only registers the
master device if no partitions are defined for this master. This
behavior breaks all drivers that expect mtd->dbg.dfs_dir to be filled
correctly after calling mtd_device_register() in order to add their own
debugfs entries.
The only way we can force all MTD masters to be registered no matter if
they expose partitions or not is by enabling the
CONFIG_MTD_PARTITIONED_MASTER option.
In such situations, there's no other solution but to accept skipping
debugfs initialization when dbg.dfs_dir is invalid, and when this
happens, inform the user that he should consider enabling
CONFIG_MTD_PARTITIONED_MASTER.
Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries")
Cc: <stable(a)vger.kernel.org>
Cc: Mario J. Rugiero <mrugiero(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
---
drivers/mtd/devices/docg3.c | 7 ++++++-
drivers/mtd/nand/nandsim.c | 13 +++++++++----
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index 84b16133554b..0806f72102c0 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1814,8 +1814,13 @@ static void __init doc_dbg_register(struct mtd_info *floor)
struct dentry *root = floor->dbg.dfs_dir;
struct docg3 *docg3 = floor->priv;
- if (IS_ERR_OR_NULL(root))
+ if (IS_ERR_OR_NULL(root)) {
+ if (IS_ENABLED(CONFIG_DEBUG_FS) &&
+ !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER))
+ dev_warn(floor->dev.parent,
+ "CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n");
return;
+ }
debugfs_create_file("docg3_flashcontrol", S_IRUSR, root, docg3,
&flashcontrol_fops);
diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c
index 246b4393118e..44322a363ba5 100644
--- a/drivers/mtd/nand/nandsim.c
+++ b/drivers/mtd/nand/nandsim.c
@@ -520,11 +520,16 @@ static int nandsim_debugfs_create(struct nandsim *dev)
struct dentry *root = nsmtd->dbg.dfs_dir;
struct dentry *dent;
- if (!IS_ENABLED(CONFIG_DEBUG_FS))
+ /*
+ * Just skip debugfs initialization when the debugfs directory is
+ * missing.
+ */
+ if (IS_ERR_OR_NULL(root)) {
+ if (IS_ENABLED(CONFIG_DEBUG_FS) &&
+ !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER))
+ NS_WARN("CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n");
return 0;
-
- if (IS_ERR_OR_NULL(root))
- return -1;
+ }
dent = debugfs_create_file("nandsim_wear_report", S_IRUSR,
root, dev, &dfs_fops);
--
2.11.0
Fix bus-node lookup during registration, which ended up searching the whole
device tree depth-first starting at the parent (or grand parent) rather
than just matching on its children.
To make things worse, the parent (or grand-parent) node could end being
prematurely freed as well.
Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
Reported-by: Peter Robinson <pbrobinson(a)gmail.com>
Reported-by: Stephen Boyd <sboyd(a)codeaurora.org>
Cc: stable <stable(a)vger.kernel.org> # 4.10
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/usb/common/ulpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 8b351444cc40..9a2ab6751a23 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -180,9 +180,9 @@ static int ulpi_of_register(struct ulpi *ulpi)
/* Find a ulpi bus underneath the parent or the grandparent */
parent = ulpi->dev.parent;
if (parent->of_node)
- np = of_find_node_by_name(parent->of_node, "ulpi");
+ np = of_get_child_by_name(parent->of_node, "ulpi");
else if (parent->parent && parent->parent->of_node)
- np = of_find_node_by_name(parent->parent->of_node, "ulpi");
+ np = of_get_child_by_name(parent->parent->of_node, "ulpi");
if (!np)
return 0;
--
2.15.0
Commit e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs
entries") tried to make MTD related debugfs stuff consistent across the
MTD framework by creating a root <debugfs>/mtd/ directory containing
one directory per MTD device.
The problem is that, by default, the MTD layer only registers the
master device if no partitions are defined for this master. This
behavior breaks all drivers that expect mtd->dbg.dfs_dir to be filled
correctly after calling mtd_device_register() in order to add their own
debugfs entries.
The only way we can force all MTD masters to be registered no matter if
they expose partitions or not is by enabling the
CONFIG_MTD_PARTITIONED_MASTER option.
In such situations, there's no other solution but to accept skipping
debugfs initialization when dbg.dfs_dir is invalid, and when this
happens, inform the user that he should consider enabling
CONFIG_MTD_PARTITIONED_MASTER.
Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries")
Cc: <stable(a)vger.kernel.org>
Cc: Mario J. Rugiero <mrugiero(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
---
drivers/mtd/devices/docg3.c | 7 ++++++-
drivers/mtd/nand/nandsim.c | 12 +++++++++---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index 84b16133554b..0806f72102c0 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1814,8 +1814,13 @@ static void __init doc_dbg_register(struct mtd_info *floor)
struct dentry *root = floor->dbg.dfs_dir;
struct docg3 *docg3 = floor->priv;
- if (IS_ERR_OR_NULL(root))
+ if (IS_ERR_OR_NULL(root)) {
+ if (IS_ENABLED(CONFIG_DEBUG_FS) &&
+ !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER))
+ dev_warn(floor->dev.parent,
+ "CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n");
return;
+ }
debugfs_create_file("docg3_flashcontrol", S_IRUSR, root, docg3,
&flashcontrol_fops);
diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c
index 246b4393118e..a22f4d7ca1cb 100644
--- a/drivers/mtd/nand/nandsim.c
+++ b/drivers/mtd/nand/nandsim.c
@@ -520,11 +520,17 @@ static int nandsim_debugfs_create(struct nandsim *dev)
struct dentry *root = nsmtd->dbg.dfs_dir;
struct dentry *dent;
- if (!IS_ENABLED(CONFIG_DEBUG_FS))
- return 0;
+ if (IS_ENABLED(CONFIG_DEBUG_FS) &&
+ !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER) &&
+ dev->nbparts)
+ NS_WARN("CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n");
+ /*
+ * Just skip debugfs initialization when the debugfs directory is
+ * missing.
+ */
if (IS_ERR_OR_NULL(root))
- return -1;
+ return 0;
dent = debugfs_create_file("nandsim_wear_report", S_IRUSR,
root, dev, &dfs_fops);
--
2.11.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
This is a note to let you know that I've just added the patch titled
drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally
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:
drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.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 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 16 Jan 2017 16:52:50 -0800
Subject: drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally
From: John Stultz <john.stultz(a)linaro.org>
commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream.
In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.
This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.
Cc: David Airlie <airlied(a)linux.ie>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com>
Cc: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: dri-devel(a)lists.freedesktop.org
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Archit Taneja <architt(a)codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-em…
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -325,7 +325,7 @@ static void adv7511_set_link_config(stru
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
}
-static void adv7511_power_on(struct adv7511 *adv7511)
+static void __adv7511_power_on(struct adv7511 *adv7511)
{
adv7511->current_edid_segment = -1;
@@ -354,6 +354,11 @@ static void adv7511_power_on(struct adv7
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
ADV7511_REG_POWER2_HPD_SRC_MASK,
ADV7511_REG_POWER2_HPD_SRC_NONE);
+}
+
+static void adv7511_power_on(struct adv7511 *adv7511)
+{
+ __adv7511_power_on(adv7511);
/*
* Most of the registers are reset during power down or when HPD is low.
@@ -362,21 +367,23 @@ static void adv7511_power_on(struct adv7
if (adv7511->type == ADV7533)
adv7533_dsi_power_on(adv7511);
-
adv7511->powered = true;
}
-static void adv7511_power_off(struct adv7511 *adv7511)
+static void __adv7511_power_off(struct adv7511 *adv7511)
{
/* TODO: setup additional power down modes */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
ADV7511_POWER_POWER_DOWN,
ADV7511_POWER_POWER_DOWN);
regcache_mark_dirty(adv7511->regmap);
+}
+static void adv7511_power_off(struct adv7511 *adv7511)
+{
+ __adv7511_power_off(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_off(adv7511);
-
adv7511->powered = false;
}
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.patch
queue-4.9/drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.patch
queue-4.9/drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
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:
drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.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 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 16 Jan 2017 16:52:51 -0800
Subject: drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
From: John Stultz <john.stultz(a)linaro.org>
commit 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c upstream.
Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls instead of duplciating
logic.
This does change behavior slightly as it adds the HPD signal
pulse to the EDID probe path, but Archit has had a patch to
add HPD signal pulse to the EDID probe path before, so this
should address the cases where that helped. Another difference
is that regcache_mark_dirty() is also called in the power off
path once EDID is probed.
Cc: David Airlie <airlied(a)linux.ie>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com>
Cc: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: dri-devel(a)lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Archit Taneja <architt(a)codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-6-git-send-em…
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -573,24 +573,13 @@ static int adv7511_get_modes(struct adv7
unsigned int count;
/* Reading the EDID only works if the device is powered */
- if (!adv7511->powered) {
- regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
- ADV7511_POWER_POWER_DOWN, 0);
- if (adv7511->i2c_main->irq) {
- regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
- ADV7511_INT0_EDID_READY);
- regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
- ADV7511_INT1_DDC_ERROR);
- }
- adv7511->current_edid_segment = -1;
- }
+ if (!adv7511->powered)
+ __adv7511_power_on(adv7511);
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
if (!adv7511->powered)
- regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
- ADV7511_POWER_POWER_DOWN,
- ADV7511_POWER_POWER_DOWN);
+ __adv7511_power_off(adv7511);
kfree(adv7511->edid);
adv7511->edid = edid;
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.patch
queue-4.9/drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.patch
queue-4.9/drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: adv7511: Re-write the i2c address before EDID probing
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:
drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.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 3587c856675c45809010c2cee5b21096f6e8e938 Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 16 Jan 2017 16:52:52 -0800
Subject: drm/bridge: adv7511: Re-write the i2c address before EDID probing
From: John Stultz <john.stultz(a)linaro.org>
commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
HiKey.
Investigating further, it turns out that some of the register
state in hardware is getting lost, as the device registers are
reset when the chip is powered down.
Thus this patch simply re-writes the i2c address to the
ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set
before we try to read the EDID data.
Cc: David Airlie <airlied(a)linux.ie>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com>
Cc: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: dri-devel(a)lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Archit Taneja <architt(a)codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-em…
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -573,9 +573,17 @@ static int adv7511_get_modes(struct adv7
unsigned int count;
/* Reading the EDID only works if the device is powered */
- if (!adv7511->powered)
+ if (!adv7511->powered) {
+ unsigned int edid_i2c_addr =
+ (adv7511->i2c_main->addr << 1) + 4;
+
__adv7511_power_on(adv7511);
+ /* Reset the EDID_I2C_ADDR register as it might be cleared */
+ regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+ edid_i2c_addr);
+ }
+
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
if (!adv7511->powered)
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.patch
queue-4.9/drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.patch
queue-4.9/drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.patch
This is a note to let you know that I've just added the patch titled
rbd: use GFP_NOIO for parent stat and data requests
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:
rbd-use-gfp_noio-for-parent-stat-and-data-requests.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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001
From: Ilya Dryomov <idryomov(a)gmail.com>
Date: Mon, 6 Nov 2017 11:33:36 +0100
Subject: rbd: use GFP_NOIO for parent stat and data requests
From: Ilya Dryomov <idryomov(a)gmail.com>
commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.
rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.
Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Reviewed-by: David Disseldorp <ddiss(a)suse.de>
[idryomov(a)gmail.com: backport to < 4.9: context]
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/rbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2736,7 +2736,7 @@ static int rbd_img_obj_parent_read_full(
* from the parent.
*/
page_count = (u32)calc_pages_for(0, length);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages)) {
result = PTR_ERR(pages);
pages = NULL;
@@ -2863,7 +2863,7 @@ static int rbd_img_obj_exists_submit(str
*/
size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32);
page_count = (u32)calc_pages_for(0, size);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages))
return PTR_ERR(pages);
Patches currently in stable-queue which might be from idryomov(a)gmail.com are
queue-4.4/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch
This is a note to let you know that I've just added the patch titled
rbd: use GFP_NOIO for parent stat and data requests
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:
rbd-use-gfp_noio-for-parent-stat-and-data-requests.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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001
From: Ilya Dryomov <idryomov(a)gmail.com>
Date: Mon, 6 Nov 2017 11:33:36 +0100
Subject: rbd: use GFP_NOIO for parent stat and data requests
From: Ilya Dryomov <idryomov(a)gmail.com>
commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.
rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.
Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Reviewed-by: David Disseldorp <ddiss(a)suse.de>
[idryomov(a)gmail.com: backport to < 4.9: context]
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/rbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2700,7 +2700,7 @@ static int rbd_img_obj_parent_read_full(
* from the parent.
*/
page_count = (u32)calc_pages_for(0, length);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages)) {
result = PTR_ERR(pages);
pages = NULL;
@@ -2827,7 +2827,7 @@ static int rbd_img_obj_exists_submit(str
*/
size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32);
page_count = (u32)calc_pages_for(0, size);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages))
return PTR_ERR(pages);
Patches currently in stable-queue which might be from idryomov(a)gmail.com are
queue-3.18/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch
This is a note to let you know that I've just added the patch titled
KEYS: trusted: fix writing past end of buffer in trusted_read()
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:
keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.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 a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 2 Nov 2017 00:47:12 +0000
Subject: KEYS: trusted: fix writing past end of buffer in trusted_read()
From: Eric Biggers <ebiggers(a)google.com>
commit a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream.
When calling keyctl_read() on a key of type "trusted", if the
user-supplied buffer was too small, the kernel ignored the buffer length
and just wrote past the end of the buffer, potentially corrupting
userspace memory. Fix it by instead returning the size required, as per
the documentation for keyctl_read().
We also don't even fill the buffer at all in this case, as this is
slightly easier to implement than doing a short read, and either
behavior appears to be permitted. It also makes it match the behavior
of the "encrypted" key type.
Fixes: d00a1c72f7f4 ("keys: add new trusted key-type")
Reported-by: Ben Hutchings <ben(a)decadent.org.uk>
Cc: <stable(a)vger.kernel.org> # v2.6.38+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/keys/trusted.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -1065,20 +1065,21 @@ static long trusted_read(const struct ke
p = rcu_dereference_key(key);
if (!p)
return -EINVAL;
- if (!buffer || buflen <= 0)
- return 2 * p->blob_len;
- ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL);
- if (!ascii_buf)
- return -ENOMEM;
- bufp = ascii_buf;
- for (i = 0; i < p->blob_len; i++)
- bufp = hex_byte_pack(bufp, p->blob[i]);
- if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) {
+ if (buffer && buflen >= 2 * p->blob_len) {
+ ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL);
+ if (!ascii_buf)
+ return -ENOMEM;
+
+ bufp = ascii_buf;
+ for (i = 0; i < p->blob_len; i++)
+ bufp = hex_byte_pack(bufp, p->blob[i]);
+ if (copy_to_user(buffer, ascii_buf, 2 * p->blob_len) != 0) {
+ kzfree(ascii_buf);
+ return -EFAULT;
+ }
kzfree(ascii_buf);
- return -EFAULT;
}
- kzfree(ascii_buf);
return 2 * p->blob_len;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/keys-trusted-sanitize-all-key-material.patch
queue-3.18/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch
queue-3.18/keys-fix-null-pointer-dereference-during-asn.1-parsing.patch
Hi stable,
Please apply the following backport of 1e37f2f84680 ("rbd: use GFP_NOIO
for parent stat and data requests") to 4.4, 4.1 and earlier kernels.
Thanks,
Ilya
This is a note to let you know that I've just added the patch titled
rbd: use GFP_NOIO for parent stat and data requests
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:
rbd-use-gfp_noio-for-parent-stat-and-data-requests.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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001
From: Ilya Dryomov <idryomov(a)gmail.com>
Date: Mon, 6 Nov 2017 11:33:36 +0100
Subject: rbd: use GFP_NOIO for parent stat and data requests
From: Ilya Dryomov <idryomov(a)gmail.com>
commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.
rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.
Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Reviewed-by: David Disseldorp <ddiss(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/rbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2788,7 +2788,7 @@ static int rbd_img_obj_parent_read_full(
* from the parent.
*/
page_count = (u32)calc_pages_for(0, length);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages)) {
result = PTR_ERR(pages);
pages = NULL;
@@ -2922,7 +2922,7 @@ static int rbd_img_obj_exists_submit(str
*/
size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32);
page_count = (u32)calc_pages_for(0, size);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages)) {
ret = PTR_ERR(pages);
goto fail_stat_request;
Patches currently in stable-queue which might be from idryomov(a)gmail.com are
queue-4.9/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch
This is a note to let you know that I've just added the patch titled
MIPS: BMIPS: Fix missing cbr address
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:
mips-bmips-fix-missing-cbr-address.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 ea4b3afe1eac8f88bb453798a084fba47a1f155a Mon Sep 17 00:00:00 2001
From: Jaedon Shin <jaedon.shin(a)gmail.com>
Date: Fri, 16 Jun 2017 20:03:01 +0900
Subject: MIPS: BMIPS: Fix missing cbr address
From: Jaedon Shin <jaedon.shin(a)gmail.com>
commit ea4b3afe1eac8f88bb453798a084fba47a1f155a upstream.
Fix NULL pointer access in BMIPS3300 RAC flush.
Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code")
Signed-off-by: Jaedon Shin <jaedon.shin(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Kevin Cernekee <cernekee(a)gmail.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16423/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/smp-bmips.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -587,11 +587,11 @@ void __init bmips_cpu_setup(void)
/* Flush and enable RAC */
cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG);
- __raw_writel(cfg | 0x100, BMIPS_RAC_CONFIG);
+ __raw_writel(cfg | 0x100, cbr + BMIPS_RAC_CONFIG);
__raw_readl(cbr + BMIPS_RAC_CONFIG);
cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG);
- __raw_writel(cfg | 0xf, BMIPS_RAC_CONFIG);
+ __raw_writel(cfg | 0xf, cbr + BMIPS_RAC_CONFIG);
__raw_readl(cbr + BMIPS_RAC_CONFIG);
cfg = __raw_readl(cbr + BMIPS_RAC_ADDRESS_RANGE);
Patches currently in stable-queue which might be from jaedon.shin(a)gmail.com are
queue-4.9/mips-bmips-fix-missing-cbr-address.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Ensure that serial ports are properly set up
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:
mips-ar7-ensure-that-serial-ports-are-properly-set-up.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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Date: Sun, 29 Oct 2017 16:27:20 +0100
Subject: MIPS: AR7: Ensure that serial ports are properly set up
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.
Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
never copied, resulting in a dead port.
Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type")
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
[jonas.gorski: add Fixes tag]
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17543/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -576,6 +576,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
+ uart_port.flags = UPF_FIXED_TYPE;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are
queue-4.9/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Defer registration of GPIO
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:
mips-ar7-defer-registration-of-gpio.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 e6b03ab63b4d270e0249f96536fde632409dc1dc Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:19 +0100
Subject: MIPS: AR7: Defer registration of GPIO
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream.
When called from prom init code, ar7_gpio_init() will fail as it will
call gpiochip_add() which relies on a working kmalloc() to alloc
the gpio_desc array and kmalloc is not useable yet at prom init time.
Move ar7_gpio_init() to ar7_register_devices() (a device_initcall)
where kmalloc works.
Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17542/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 4 ++++
arch/mips/ar7/prom.c | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -654,6 +654,10 @@ static int __init ar7_register_devices(v
u32 val;
int res;
+ res = ar7_gpio_init();
+ if (res)
+ pr_warn("unable to register gpios: %d\n", res);
+
res = ar7_register_uarts();
if (res)
pr_err("unable to setup uart(s): %d\n", res);
--- a/arch/mips/ar7/prom.c
+++ b/arch/mips/ar7/prom.c
@@ -246,8 +246,6 @@ void __init prom_init(void)
ar7_init_cmdline(fw_arg0, (char **)fw_arg1);
ar7_init_env((struct env_var *)fw_arg2);
console_config();
-
- ar7_gpio_init();
}
#define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4)))
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-4.9/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
queue-4.9/mips-ar7-defer-registration-of-gpio.patch
This is a note to let you know that I've just added the patch titled
Input: elan_i2c - add ELAN060C to the ACPI table
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:
input-elan_i2c-add-elan060c-to-the-acpi-table.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 cdea6a30c2689cc33b34c6691b57cca277f0c5dc Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 7 Nov 2017 16:19:24 -0800
Subject: Input: elan_i2c - add ELAN060C to the ACPI table
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream.
ELAN060C touchpad uses elan_i2c as its driver. It can be
found on Lenovo ideapad 320-14AST.
BugLink: https://bugs.launchpad.net/bugs/1727544
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1240,6 +1240,7 @@ static const struct acpi_device_id elan_
{ "ELAN0605", 0 },
{ "ELAN0609", 0 },
{ "ELAN060B", 0 },
+ { "ELAN060C", 0 },
{ "ELAN0611", 0 },
{ "ELAN1000", 0 },
{ }
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.9/input-elan_i2c-add-elan060c-to-the-acpi-table.patch
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
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:
drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.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 cef75036c40408ba3bc308bcb00a3d440da713fc Mon Sep 17 00:00:00 2001
From: Sinclair Yeh <syeh(a)vmware.com>
Date: Wed, 1 Nov 2017 10:47:05 -0700
Subject: drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
From: Sinclair Yeh <syeh(a)vmware.com>
commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream.
This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work
around mode set failure in 2D VMs")
With Wayland desktop and atomic mode set, during the mode setting
process there is a moment when two framebuffer sized surfaces
are being pinned. This was not an issue with Xorg.
Since this only happens during a mode change, there should be no
performance impact by increasing allowable mem_size.
Signed-off-by: Sinclair Yeh <syeh(a)vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -721,7 +721,7 @@ static int vmw_driver_load(struct drm_de
* allocation taken by fbdev
*/
if (!(dev_priv->capabilities & SVGA_CAP_3D))
- mem_size *= 2;
+ mem_size *= 3;
dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE;
dev_priv->prim_bb_mem =
Patches currently in stable-queue which might be from syeh(a)vmware.com are
queue-4.9/drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch
This is a note to let you know that I've just added the patch titled
ASoC: sun4i-spdif: remove legacy dapm components
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:
asoc-sun4i-spdif-remove-legacy-dapm-components.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 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf Mon Sep 17 00:00:00 2001
From: Marcus Cooper <codekipper(a)gmail.com>
Date: Tue, 20 Dec 2016 15:49:13 +0100
Subject: ASoC: sun4i-spdif: remove legacy dapm components
From: Marcus Cooper <codekipper(a)gmail.com>
commit 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf upstream.
The dapm components are now handled by the ALSA SoC SPDIF DIT driver
so can be removed.
Signed-off-by: Marcus Cooper <codekipper(a)gmail.com>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sunxi/sun4i-spdif.c | 8 --------
1 file changed, 8 deletions(-)
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -403,14 +403,6 @@ static struct snd_soc_dai_driver sun4i_s
.name = "spdif",
};
-static const struct snd_soc_dapm_widget dit_widgets[] = {
- SND_SOC_DAPM_OUTPUT("spdif-out"),
-};
-
-static const struct snd_soc_dapm_route dit_routes[] = {
- { "spdif-out", NULL, "Playback" },
-};
-
static const struct of_device_id sun4i_spdif_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-spdif", },
{ .compatible = "allwinner,sun6i-a31-spdif", },
Patches currently in stable-queue which might be from codekipper(a)gmail.com are
queue-4.9/asoc-sun4i-spdif-remove-legacy-dapm-components.patch
queue-4.9/asoc-sunxi-add-bindings-for-sun8i-to-spdif.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Ensure that serial ports are properly set up
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:
mips-ar7-ensure-that-serial-ports-are-properly-set-up.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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Date: Sun, 29 Oct 2017 16:27:20 +0100
Subject: MIPS: AR7: Ensure that serial ports are properly set up
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.
Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
never copied, resulting in a dead port.
Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type")
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
[jonas.gorski: add Fixes tag]
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17543/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -576,6 +576,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
+ uart_port.flags = UPF_FIXED_TYPE;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are
queue-4.4/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Defer registration of GPIO
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:
mips-ar7-defer-registration-of-gpio.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 e6b03ab63b4d270e0249f96536fde632409dc1dc Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:19 +0100
Subject: MIPS: AR7: Defer registration of GPIO
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream.
When called from prom init code, ar7_gpio_init() will fail as it will
call gpiochip_add() which relies on a working kmalloc() to alloc
the gpio_desc array and kmalloc is not useable yet at prom init time.
Move ar7_gpio_init() to ar7_register_devices() (a device_initcall)
where kmalloc works.
Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17542/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 4 ++++
arch/mips/ar7/prom.c | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -654,6 +654,10 @@ static int __init ar7_register_devices(v
u32 val;
int res;
+ res = ar7_gpio_init();
+ if (res)
+ pr_warn("unable to register gpios: %d\n", res);
+
res = ar7_register_uarts();
if (res)
pr_err("unable to setup uart(s): %d\n", res);
--- a/arch/mips/ar7/prom.c
+++ b/arch/mips/ar7/prom.c
@@ -246,8 +246,6 @@ void __init prom_init(void)
ar7_init_cmdline(fw_arg0, (char **)fw_arg1);
ar7_init_env((struct env_var *)fw_arg2);
console_config();
-
- ar7_gpio_init();
}
#define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4)))
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-4.4/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
queue-4.4/mips-ar7-defer-registration-of-gpio.patch
This is a note to let you know that I've just added the patch titled
Input: elan_i2c - add ELAN060C to the ACPI table
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:
input-elan_i2c-add-elan060c-to-the-acpi-table.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 cdea6a30c2689cc33b34c6691b57cca277f0c5dc Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 7 Nov 2017 16:19:24 -0800
Subject: Input: elan_i2c - add ELAN060C to the ACPI table
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream.
ELAN060C touchpad uses elan_i2c as its driver. It can be
found on Lenovo ideapad 320-14AST.
BugLink: https://bugs.launchpad.net/bugs/1727544
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1240,6 +1240,7 @@ static const struct acpi_device_id elan_
{ "ELAN0605", 0 },
{ "ELAN0609", 0 },
{ "ELAN060B", 0 },
+ { "ELAN060C", 0 },
{ "ELAN0611", 0 },
{ "ELAN1000", 0 },
{ }
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.4/input-elan_i2c-add-elan060c-to-the-acpi-table.patch
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
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-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.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 cef75036c40408ba3bc308bcb00a3d440da713fc Mon Sep 17 00:00:00 2001
From: Sinclair Yeh <syeh(a)vmware.com>
Date: Wed, 1 Nov 2017 10:47:05 -0700
Subject: drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
From: Sinclair Yeh <syeh(a)vmware.com>
commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream.
This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work
around mode set failure in 2D VMs")
With Wayland desktop and atomic mode set, during the mode setting
process there is a moment when two framebuffer sized surfaces
are being pinned. This was not an issue with Xorg.
Since this only happens during a mode change, there should be no
performance impact by increasing allowable mem_size.
Signed-off-by: Sinclair Yeh <syeh(a)vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -708,7 +708,7 @@ static int vmw_driver_load(struct drm_de
* allocation taken by fbdev
*/
if (!(dev_priv->capabilities & SVGA_CAP_3D))
- mem_size *= 2;
+ mem_size *= 3;
dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE;
dev_priv->prim_bb_mem =
Patches currently in stable-queue which might be from syeh(a)vmware.com are
queue-4.4/drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch
This is a note to let you know that I've just added the patch titled
Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"
to the 4.13-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:
revert-x86-cpu-fix-up-cpu-mhz-in-proc-cpuinfo.patch
and it can be found in the queue-4.13 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 ea0ee33988778fb73e4f45e7c73fb735787e2f32 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Fri, 10 Nov 2017 11:19:11 -0800
Subject: Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit ea0ee33988778fb73e4f45e7c73fb735787e2f32 upstream.
This reverts commit 941f5f0f6ef5338814145cf2b813cf1f98873e2f.
Sadly, it turns out that we really can't just do the cross-CPU IPI to
all CPU's to get their proper frequencies, because it's much too
expensive on systems with lots of cores.
So we'll have to revert this for now, and revisit it using a smarter
model (probably doing one system-wide IPI at open time, and doing all
the frequency calculations in parallel).
Reported-by: WANG Chao <chao.wang(a)ucloud.cn>
Reported-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Rafael J Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/Makefile | 2 +-
arch/x86/kernel/cpu/aperfmperf.c | 11 ++++-------
arch/x86/kernel/cpu/proc.c | 4 +---
3 files changed, 6 insertions(+), 11 deletions(-)
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -21,7 +21,7 @@ obj-y += common.o
obj-y += rdrand.o
obj-y += match.o
obj-y += bugs.o
-obj-y += aperfmperf.o
+obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -42,6 +42,10 @@ static void aperfmperf_snapshot_khz(void
s64 time_delta = ktime_ms_delta(now, s->time);
unsigned long flags;
+ /* Don't bother re-computing within the cache threshold time. */
+ if (time_delta < APERFMPERF_CACHE_THRESHOLD_MS)
+ return;
+
local_irq_save(flags);
rdmsrl(MSR_IA32_APERF, aperf);
rdmsrl(MSR_IA32_MPERF, mperf);
@@ -70,7 +74,6 @@ static void aperfmperf_snapshot_khz(void
unsigned int arch_freq_get_on_cpu(int cpu)
{
- s64 time_delta;
unsigned int khz;
if (!cpu_khz)
@@ -79,12 +82,6 @@ unsigned int arch_freq_get_on_cpu(int cp
if (!static_cpu_has(X86_FEATURE_APERFMPERF))
return 0;
- /* Don't bother re-computing within the cache threshold time. */
- time_delta = ktime_ms_delta(ktime_get(), per_cpu(samples.time, cpu));
- khz = per_cpu(samples.khz, cpu);
- if (khz && time_delta < APERFMPERF_CACHE_THRESHOLD_MS)
- return khz;
-
smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1);
khz = per_cpu(samples.khz, cpu);
if (khz)
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -77,11 +77,9 @@ static int show_cpuinfo(struct seq_file
seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
if (cpu_has(c, X86_FEATURE_TSC)) {
- unsigned int freq = arch_freq_get_on_cpu(cpu);
+ unsigned int freq = cpufreq_quick_get(cpu);
if (!freq)
- freq = cpufreq_quick_get(cpu);
- if (!freq)
freq = cpu_khz;
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
freq / 1000, (freq % 1000));
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.13/revert-x86-cpu-fix-up-cpu-mhz-in-proc-cpuinfo.patch
This is a note to let you know that I've just added the patch titled
rbd: use GFP_NOIO for parent stat and data requests
to the 4.13-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:
rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch
and it can be found in the queue-4.13 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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001
From: Ilya Dryomov <idryomov(a)gmail.com>
Date: Mon, 6 Nov 2017 11:33:36 +0100
Subject: rbd: use GFP_NOIO for parent stat and data requests
From: Ilya Dryomov <idryomov(a)gmail.com>
commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.
rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.
Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Reviewed-by: David Disseldorp <ddiss(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/rbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2692,7 +2692,7 @@ static int rbd_img_obj_parent_read_full(
* from the parent.
*/
page_count = (u32)calc_pages_for(0, length);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages)) {
result = PTR_ERR(pages);
pages = NULL;
@@ -2827,7 +2827,7 @@ static int rbd_img_obj_exists_submit(str
*/
size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32);
page_count = (u32)calc_pages_for(0, size);
- pages = ceph_alloc_page_vector(page_count, GFP_KERNEL);
+ pages = ceph_alloc_page_vector(page_count, GFP_NOIO);
if (IS_ERR(pages)) {
ret = PTR_ERR(pages);
goto fail_stat_request;
Patches currently in stable-queue which might be from idryomov(a)gmail.com are
queue-4.13/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch
This is a note to let you know that I've just added the patch titled
MIPS: BMIPS: Fix missing cbr address
to the 4.13-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:
mips-bmips-fix-missing-cbr-address.patch
and it can be found in the queue-4.13 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 ea4b3afe1eac8f88bb453798a084fba47a1f155a Mon Sep 17 00:00:00 2001
From: Jaedon Shin <jaedon.shin(a)gmail.com>
Date: Fri, 16 Jun 2017 20:03:01 +0900
Subject: MIPS: BMIPS: Fix missing cbr address
From: Jaedon Shin <jaedon.shin(a)gmail.com>
commit ea4b3afe1eac8f88bb453798a084fba47a1f155a upstream.
Fix NULL pointer access in BMIPS3300 RAC flush.
Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code")
Signed-off-by: Jaedon Shin <jaedon.shin(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Kevin Cernekee <cernekee(a)gmail.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16423/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/smp-bmips.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/mips/kernel/smp-bmips.c
+++ b/arch/mips/kernel/smp-bmips.c
@@ -589,11 +589,11 @@ void __init bmips_cpu_setup(void)
/* Flush and enable RAC */
cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG);
- __raw_writel(cfg | 0x100, BMIPS_RAC_CONFIG);
+ __raw_writel(cfg | 0x100, cbr + BMIPS_RAC_CONFIG);
__raw_readl(cbr + BMIPS_RAC_CONFIG);
cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG);
- __raw_writel(cfg | 0xf, BMIPS_RAC_CONFIG);
+ __raw_writel(cfg | 0xf, cbr + BMIPS_RAC_CONFIG);
__raw_readl(cbr + BMIPS_RAC_CONFIG);
cfg = __raw_readl(cbr + BMIPS_RAC_ADDRESS_RANGE);
Patches currently in stable-queue which might be from jaedon.shin(a)gmail.com are
queue-4.13/mips-bmips-fix-missing-cbr-address.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Ensure that serial ports are properly set up
to the 4.13-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:
mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
and it can be found in the queue-4.13 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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Date: Sun, 29 Oct 2017 16:27:20 +0100
Subject: MIPS: AR7: Ensure that serial ports are properly set up
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.
Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
never copied, resulting in a dead port.
Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type")
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
[jonas.gorski: add Fixes tag]
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17543/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -575,6 +575,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
+ uart_port.flags = UPF_FIXED_TYPE;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are
queue-4.13/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Defer registration of GPIO
to the 4.13-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:
mips-ar7-defer-registration-of-gpio.patch
and it can be found in the queue-4.13 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 e6b03ab63b4d270e0249f96536fde632409dc1dc Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:19 +0100
Subject: MIPS: AR7: Defer registration of GPIO
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream.
When called from prom init code, ar7_gpio_init() will fail as it will
call gpiochip_add() which relies on a working kmalloc() to alloc
the gpio_desc array and kmalloc is not useable yet at prom init time.
Move ar7_gpio_init() to ar7_register_devices() (a device_initcall)
where kmalloc works.
Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17542/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 4 ++++
arch/mips/ar7/prom.c | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -653,6 +653,10 @@ static int __init ar7_register_devices(v
u32 val;
int res;
+ res = ar7_gpio_init();
+ if (res)
+ pr_warn("unable to register gpios: %d\n", res);
+
res = ar7_register_uarts();
if (res)
pr_err("unable to setup uart(s): %d\n", res);
--- a/arch/mips/ar7/prom.c
+++ b/arch/mips/ar7/prom.c
@@ -246,8 +246,6 @@ void __init prom_init(void)
ar7_init_cmdline(fw_arg0, (char **)fw_arg1);
ar7_init_env((struct env_var *)fw_arg2);
console_config();
-
- ar7_gpio_init();
}
#define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4)))
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-4.13/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch
queue-4.13/mips-ar7-defer-registration-of-gpio.patch
This is a note to let you know that I've just added the patch titled
KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates
to the 4.13-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:
kvm-ppc-book3s-hv-fix-exclusion-between-hpt-resizing-and-other-hpt-updates.patch
and it can be found in the queue-4.13 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 38c53af853069adf87181684370d7b8866d6387b Mon Sep 17 00:00:00 2001
From: Paul Mackerras <paulus(a)ozlabs.org>
Date: Wed, 8 Nov 2017 14:44:04 +1100
Subject: KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates
From: Paul Mackerras <paulus(a)ozlabs.org>
commit 38c53af853069adf87181684370d7b8866d6387b upstream.
Commit 5e9859699aba ("KVM: PPC: Book3S HV: Outline of KVM-HV HPT resizing
implementation", 2016-12-20) added code that tries to exclude any use
or update of the hashed page table (HPT) while the HPT resizing code
is iterating through all the entries in the HPT. It does this by
taking the kvm->lock mutex, clearing the kvm->arch.hpte_setup_done
flag and then sending an IPI to all CPUs in the host. The idea is
that any VCPU task that tries to enter the guest will see that the
hpte_setup_done flag is clear and therefore call kvmppc_hv_setup_htab_rma,
which also takes the kvm->lock mutex and will therefore block until
we release kvm->lock.
However, any VCPU that is already in the guest, or is handling a
hypervisor page fault or hypercall, can re-enter the guest without
rechecking the hpte_setup_done flag. The IPI will cause a guest exit
of any VCPUs that are currently in the guest, but does not prevent
those VCPU tasks from immediately re-entering the guest.
The result is that after resize_hpt_rehash_hpte() has made a HPTE
absent, a hypervisor page fault can occur and make that HPTE present
again. This includes updating the rmap array for the guest real page,
meaning that we now have a pointer in the rmap array which connects
with pointers in the old rev array but not the new rev array. In
fact, if the HPT is being reduced in size, the pointer in the rmap
array could point outside the bounds of the new rev array. If that
happens, we can get a host crash later on such as this one:
[91652.628516] Unable to handle kernel paging request for data at address 0xd0000000157fb10c
[91652.628668] Faulting instruction address: 0xc0000000000e2640
[91652.628736] Oops: Kernel access of bad area, sig: 11 [#1]
[91652.628789] LE SMP NR_CPUS=1024 NUMA PowerNV
[91652.628847] Modules linked in: binfmt_misc vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables ses enclosure scsi_transport_sas i2c_opal ipmi_powernv ipmi_devintf i2c_core ipmi_msghandler powernv_op_panel nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc kvm_hv kvm_pr kvm scsi_dh_alua dm_service_time dm_multipath tg3 ptp pps_core [last unloaded: stap_552b612747aec2da355051e464fa72a1_14259]
[91652.629566] CPU: 136 PID: 41315 Comm: CPU 21/KVM Tainted: G O 4.14.0-1.rc4.dev.gitb27fc5c.el7.centos.ppc64le #1
[91652.629684] task: c0000007a419e400 task.stack: c0000000028d8000
[91652.629750] NIP: c0000000000e2640 LR: d00000000c36e498 CTR: c0000000000e25f0
[91652.629829] REGS: c0000000028db5d0 TRAP: 0300 Tainted: G O (4.14.0-1.rc4.dev.gitb27fc5c.el7.centos.ppc64le)
[91652.629932] MSR: 900000010280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 44022422 XER: 00000000
[91652.630034] CFAR: d00000000c373f84 DAR: d0000000157fb10c DSISR: 40000000 SOFTE: 1
[91652.630034] GPR00: d00000000c36e498 c0000000028db850 c000000001403900 c0000007b7960000
[91652.630034] GPR04: d0000000117fb100 d000000007ab00d8 000000000033bb10 0000000000000000
[91652.630034] GPR08: fffffffffffffe7f 801001810073bb10 d00000000e440000 d00000000c373f70
[91652.630034] GPR12: c0000000000e25f0 c00000000fdb9400 f000000003b24680 0000000000000000
[91652.630034] GPR16: 00000000000004fb 00007ff7081a0000 00000000000ec91a 000000000033bb10
[91652.630034] GPR20: 0000000000010000 00000000001b1190 0000000000000001 0000000000010000
[91652.630034] GPR24: c0000007b7ab8038 d0000000117fb100 0000000ec91a1190 c000001e6a000000
[91652.630034] GPR28: 00000000033bb100 000000000073bb10 c0000007b7960000 d0000000157fb100
[91652.630735] NIP [c0000000000e2640] kvmppc_add_revmap_chain+0x50/0x120
[91652.630806] LR [d00000000c36e498] kvmppc_book3s_hv_page_fault+0xbb8/0xc40 [kvm_hv]
[91652.630884] Call Trace:
[91652.630913] [c0000000028db850] [c0000000028db8b0] 0xc0000000028db8b0 (unreliable)
[91652.630996] [c0000000028db8b0] [d00000000c36e498] kvmppc_book3s_hv_page_fault+0xbb8/0xc40 [kvm_hv]
[91652.631091] [c0000000028db9e0] [d00000000c36a078] kvmppc_vcpu_run_hv+0xdf8/0x1300 [kvm_hv]
[91652.631179] [c0000000028dbb30] [d00000000c2248c4] kvmppc_vcpu_run+0x34/0x50 [kvm]
[91652.631266] [c0000000028dbb50] [d00000000c220d54] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm]
[91652.631351] [c0000000028dbbd0] [d00000000c2139d8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
[91652.631433] [c0000000028dbd40] [c0000000003832e0] do_vfs_ioctl+0xd0/0x8c0
[91652.631501] [c0000000028dbde0] [c000000000383ba4] SyS_ioctl+0xd4/0x130
[91652.631569] [c0000000028dbe30] [c00000000000b8e0] system_call+0x58/0x6c
[91652.631635] Instruction dump:
[91652.631676] fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ffa1 2fa70000 793d0020 e9432110
[91652.631814] 7bbf26e4 7c7e1b78 7feafa14 409e0094 <807f000c> 786326e4 7c6a1a14 93a40008
[91652.631959] ---[ end trace ac85ba6db72e5b2e ]---
To fix this, we tighten up the way that the hpte_setup_done flag is
checked to ensure that it does provide the guarantee that the resizing
code needs. In kvmppc_run_core(), we check the hpte_setup_done flag
after disabling interrupts and refuse to enter the guest if it is
clear (for a HPT guest). The code that checks hpte_setup_done and
calls kvmppc_hv_setup_htab_rma() is moved from kvmppc_vcpu_run_hv()
to a point inside the main loop in kvmppc_run_vcpu(), ensuring that
we don't just spin endlessly calling kvmppc_run_core() while
hpte_setup_done is clear, but instead have a chance to block on the
kvm->lock mutex.
Finally we also check hpte_setup_done inside the region in
kvmppc_book3s_hv_page_fault() where the HPTE is locked and we are about
to update the HPTE, and bail out if it is clear. If another CPU is
inside kvm_vm_ioctl_resize_hpt_commit) and has cleared hpte_setup_done,
then we know that either we are looking at a HPTE
that resize_hpt_rehash_hpte() has not yet processed, which is OK,
or else we will see hpte_setup_done clear and refuse to update it,
because of the full barrier formed by the unlock of the HPTE in
resize_hpt_rehash_hpte() combined with the locking of the HPTE
in kvmppc_book3s_hv_page_fault().
Fixes: 5e9859699aba ("KVM: PPC: Book3S HV: Outline of KVM-HV HPT resizing implementation")
Reported-by: Satheesh Rajendran <satheera(a)in.ibm.com>
Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 10 ++++++++++
arch/powerpc/kvm/book3s_hv.c | 29 +++++++++++++++++++----------
2 files changed, 29 insertions(+), 10 deletions(-)
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -645,6 +645,16 @@ int kvmppc_book3s_hv_page_fault(struct k
hnow_v = hpte_new_to_old_v(hnow_v, hnow_r);
hnow_r = hpte_new_to_old_r(hnow_r);
}
+
+ /*
+ * If the HPT is being resized, don't update the HPTE,
+ * instead let the guest retry after the resize operation is complete.
+ * The synchronization for hpte_setup_done test vs. set is provided
+ * by the HPTE lock.
+ */
+ if (!kvm->arch.hpte_setup_done)
+ goto out_unlock;
+
if ((hnow_v & ~HPTE_V_HVLOCK) != hpte[0] || hnow_r != hpte[1] ||
rev->guest_rpte != hpte[2])
/* HPTE has been changed under us; let the guest retry */
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2688,11 +2688,14 @@ static noinline void kvmppc_run_core(str
* Hard-disable interrupts, and check resched flag and signals.
* If we need to reschedule or deliver a signal, clean up
* and return without going into the guest(s).
+ * If the hpte_setup_done flag has been cleared, don't go into the
+ * guest because that means a HPT resize operation is in progress.
*/
local_irq_disable();
hard_irq_disable();
if (lazy_irq_pending() || need_resched() ||
- recheck_signals(&core_info)) {
+ recheck_signals(&core_info) ||
+ (!kvm_is_radix(vc->kvm) && !vc->kvm->arch.hpte_setup_done)) {
local_irq_enable();
vc->vcore_state = VCORE_INACTIVE;
/* Unlock all except the primary vcore */
@@ -3061,7 +3064,7 @@ out:
static int kvmppc_run_vcpu(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
- int n_ceded, i;
+ int n_ceded, i, r;
struct kvmppc_vcore *vc;
struct kvm_vcpu *v;
@@ -3115,6 +3118,20 @@ static int kvmppc_run_vcpu(struct kvm_ru
while (vcpu->arch.state == KVMPPC_VCPU_RUNNABLE &&
!signal_pending(current)) {
+ /* See if the HPT and VRMA are ready to go */
+ if (!kvm_is_radix(vcpu->kvm) &&
+ !vcpu->kvm->arch.hpte_setup_done) {
+ spin_unlock(&vc->lock);
+ r = kvmppc_hv_setup_htab_rma(vcpu);
+ spin_lock(&vc->lock);
+ if (r) {
+ kvm_run->exit_reason = KVM_EXIT_FAIL_ENTRY;
+ kvm_run->fail_entry.hardware_entry_failure_reason = 0;
+ vcpu->arch.ret = r;
+ break;
+ }
+ }
+
if (vc->vcore_state == VCORE_PREEMPT && vc->runner == NULL)
kvmppc_vcore_end_preempt(vc);
@@ -3232,13 +3249,6 @@ static int kvmppc_vcpu_run_hv(struct kvm
/* Order vcpus_running vs. hpte_setup_done, see kvmppc_alloc_reset_hpt */
smp_mb();
- /* On the first time here, set up HTAB and VRMA */
- if (!kvm_is_radix(vcpu->kvm) && !vcpu->kvm->arch.hpte_setup_done) {
- r = kvmppc_hv_setup_htab_rma(vcpu);
- if (r)
- goto out;
- }
-
flush_all_to_thread(current);
/* Save userspace EBB and other register values */
@@ -3286,7 +3296,6 @@ static int kvmppc_vcpu_run_hv(struct kvm
}
mtspr(SPRN_VRSAVE, user_vrsave);
- out:
vcpu->arch.state = KVMPPC_VCPU_NOTREADY;
atomic_dec(&vcpu->kvm->arch.vcpus_running);
return r;
Patches currently in stable-queue which might be from paulus(a)ozlabs.org are
queue-4.13/kvm-ppc-book3s-hv-fix-exclusion-between-hpt-resizing-and-other-hpt-updates.patch
This is a note to let you know that I've just added the patch titled
Input: elan_i2c - add ELAN060C to the ACPI table
to the 4.13-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-elan_i2c-add-elan060c-to-the-acpi-table.patch
and it can be found in the queue-4.13 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 cdea6a30c2689cc33b34c6691b57cca277f0c5dc Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Tue, 7 Nov 2017 16:19:24 -0800
Subject: Input: elan_i2c - add ELAN060C to the ACPI table
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream.
ELAN060C touchpad uses elan_i2c as its driver. It can be
found on Lenovo ideapad 320-14AST.
BugLink: https://bugs.launchpad.net/bugs/1727544
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1253,6 +1253,7 @@ static const struct acpi_device_id elan_
{ "ELAN0605", 0 },
{ "ELAN0609", 0 },
{ "ELAN060B", 0 },
+ { "ELAN060C", 0 },
{ "ELAN0611", 0 },
{ "ELAN1000", 0 },
{ }
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.13/input-elan_i2c-add-elan060c-to-the-acpi-table.patch
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
to the 4.13-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-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch
and it can be found in the queue-4.13 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 cef75036c40408ba3bc308bcb00a3d440da713fc Mon Sep 17 00:00:00 2001
From: Sinclair Yeh <syeh(a)vmware.com>
Date: Wed, 1 Nov 2017 10:47:05 -0700
Subject: drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
From: Sinclair Yeh <syeh(a)vmware.com>
commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream.
This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work
around mode set failure in 2D VMs")
With Wayland desktop and atomic mode set, during the mode setting
process there is a moment when two framebuffer sized surfaces
are being pinned. This was not an issue with Xorg.
Since this only happens during a mode change, there should be no
performance impact by increasing allowable mem_size.
Signed-off-by: Sinclair Yeh <syeh(a)vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -722,7 +722,7 @@ static int vmw_driver_load(struct drm_de
* allocation taken by fbdev
*/
if (!(dev_priv->capabilities & SVGA_CAP_3D))
- mem_size *= 2;
+ mem_size *= 3;
dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE;
dev_priv->prim_bb_mem =
Patches currently in stable-queue which might be from syeh(a)vmware.com are
queue-4.13/drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: Ensure that serial ports are properly set up
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:
mips-ar7-ensure-that-serial-ports-are-properly-set-up.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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Date: Sun, 29 Oct 2017 16:27:20 +0100
Subject: MIPS: AR7: Ensure that serial ports are properly set up
From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.
Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
never copied, resulting in a dead port.
Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type")
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
[jonas.gorski: add Fixes tag]
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17543/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -581,6 +581,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
+ uart_port.flags = UPF_FIXED_TYPE;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are
queue-3.18/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch