]> git.proxmox.com Git - mirror_ubuntu-artful-kernel.git/log
mirror_ubuntu-artful-kernel.git
7 years agoDrivers: hv: utils: fix a race on userspace daemons registration
Vitaly Kuznetsov [Fri, 10 Jun 2016 00:08:57 +0000 (17:08 -0700)]
Drivers: hv: utils: fix a race on userspace daemons registration

BugLink: http://bugs.launchpad.net/bugs/1650059
Background: userspace daemons registration protocol for Hyper-V utilities
drivers has two steps:
1) daemon writes its own version to kernel
2) kernel reads it and replies with module version
at this point we consider the handshake procedure being completed and we
do hv_poll_channel() transitioning the utility device to HVUTIL_READY
state. At this point we're ready to handle messages from kernel.

When hvutil_transport is in HVUTIL_TRANSPORT_CHARDEV mode we have a
single buffer for outgoing message. hvutil_transport_send() puts to this
buffer and till the buffer is cleared with hvt_op_read() returns -EFAULT
to all consequent calls. Host<->guest protocol guarantees there is no more
than one request at a time and we will not get new requests till we reply
to the previous one so this single message buffer is enough.

Now to the race. When we finish negotiation procedure and send kernel
module version to userspace with hvutil_transport_send() it goes into the
above mentioned buffer and if the daemon is slow enough to read it from
there we can get a collision when a request from the host comes, we won't
be able to put anything to the buffer so the request will be lost. To
solve the issue we need to know when the negotiation is really done (when
the version message is read by the daemon) and transition to HVUTIL_READY
state after this happens. Implement a callback on read to support this.
Old style netlink communication is not affected by the change, we don't
really know when these messages are delivered but we don't have a single
message buffer there.

Reported-by: Barry Davis <barry_davis@stormagic.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e0fa3e5e7df61eb2c339c9f0067c202c0cdeec2c)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoDrivers: hv: get rid of timeout in vmbus_open()
Vitaly Kuznetsov [Fri, 10 Jun 2016 00:08:56 +0000 (17:08 -0700)]
Drivers: hv: get rid of timeout in vmbus_open()

BugLink: http://bugs.launchpad.net/bugs/1650059
vmbus_teardown_gpadl() can result in infinite wait when it is called on 5
second timeout in vmbus_open(). The issue is caused by the fact that gpadl
teardown operation won't ever succeed for an opened channel and the timeout
isn't always enough. As a guest, we can always trust the host to respond to
our request (and there is nothing we can do if it doesn't).

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 396e287fa2ff46e83ae016cdcb300c3faa3b02f6)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoDrivers: hv: don't leak memory in vmbus_establish_gpadl()
Vitaly Kuznetsov [Sat, 4 Jun 2016 00:09:24 +0000 (17:09 -0700)]
Drivers: hv: don't leak memory in vmbus_establish_gpadl()

BugLink: http://bugs.launchpad.net/bugs/1650059
In some cases create_gpadl_header() allocates submessages but we never
free them.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7cc80c98070ccc7940fc28811c92cca0a681015d)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoDrivers: hv: get rid of redundant messagecount in create_gpadl_header()
Vitaly Kuznetsov [Sat, 4 Jun 2016 00:09:23 +0000 (17:09 -0700)]
Drivers: hv: get rid of redundant messagecount in create_gpadl_header()

BugLink: http://bugs.launchpad.net/bugs/1650059
We use messagecount only once in vmbus_establish_gpadl() to check if
it is safe to iterate through the submsglist. We can just initialize
the list header in all cases in create_gpadl_header() instead.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4d63763296ab7865a98bc29cc7d77145815ef89f)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: add ethtool statistics for tx packet issues
Stephen Hemminger [Tue, 23 Aug 2016 19:17:57 +0000 (12:17 -0700)]
hv_netvsc: add ethtool statistics for tx packet issues

BugLink: http://bugs.launchpad.net/bugs/1650059
Printing console messages is not helpful when system is out of memory;
and can be disastrous with netconsole. Instead keep statistics
of these anomalous conditions.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4323b47cf8edfe95bd58e20965667e71121c866e)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: report vmbus name in ethtool
Stephen Hemminger [Tue, 23 Aug 2016 19:17:56 +0000 (12:17 -0700)]
hv_netvsc: report vmbus name in ethtool

BugLink: http://bugs.launchpad.net/bugs/1650059
Make netvsc on vmbus behave more like PCI.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e3f74b841d482e962b9f5a907eeb25eeeb09aa60)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: make variable local
Stephen Hemminger [Tue, 23 Aug 2016 19:17:55 +0000 (12:17 -0700)]
hv_netvsc: make variable local

BugLink: http://bugs.launchpad.net/bugs/1650059
The variable m_ret is only used in one basic block.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6c4c137e5035e0e17fa40c223fa0a3167e0f65fa)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: make netvsc_destroy_buf void
Stephen Hemminger [Tue, 23 Aug 2016 19:17:54 +0000 (12:17 -0700)]
hv_netvsc: make netvsc_destroy_buf void

BugLink: http://bugs.launchpad.net/bugs/1650059
No caller checks the return value.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7a2a0a84fda33062200decf5e201b182591bf0ec)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: refactor completion function
Stephen Hemminger [Tue, 23 Aug 2016 19:17:53 +0000 (12:17 -0700)]
hv_netvsc: refactor completion function

BugLink: http://bugs.launchpad.net/bugs/1650059
Break the different cases, code is cleaner if broken up

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit bc304dd3b4444b84082c483534a8dcac7a22cb9d)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: rearrange start_xmit
Stephen Hemminger [Tue, 23 Aug 2016 19:17:52 +0000 (12:17 -0700)]
hv_netvsc: rearrange start_xmit

BugLink: http://bugs.launchpad.net/bugs/1650059
Rearrange the transmit routine to eliminate goto's and unnecessary
boolean variables. Use standard functions to test for vlan tag.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 0ab05141f97de2ac954c267c27b256ebd241e762)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: init completion during alloc
Stephen Hemminger [Tue, 23 Aug 2016 19:17:51 +0000 (12:17 -0700)]
hv_netvsc: init completion during alloc

BugLink: http://bugs.launchpad.net/bugs/1650059
Move initialization to allocate where other fields are initialized.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit fd612602d6a7919982779fda914bd521e5778593)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: make device_remove void
Stephen Hemminger [Tue, 23 Aug 2016 19:17:50 +0000 (12:17 -0700)]
hv_netvsc: make device_remove void

BugLink: http://bugs.launchpad.net/bugs/1650059
Always returns 0 and no callers check.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e08f3ea586d4145e36c77f0dd1602374b5d7e928)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: use ARRAY_SIZE() for NDIS versions
Stephen Hemminger [Tue, 23 Aug 2016 19:17:49 +0000 (12:17 -0700)]
hv_netvsc: use ARRAY_SIZE() for NDIS versions

BugLink: http://bugs.launchpad.net/bugs/1650059
Don't hard code size of array of NDIS versions.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e5a78fad4f1eb49064e4c35d0a4263424b12124c)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: make inline functions static
Stephen Hemminger [Tue, 23 Aug 2016 19:17:48 +0000 (12:17 -0700)]
hv_netvsc: make inline functions static

BugLink: http://bugs.launchpad.net/bugs/1650059
Several new functions were introduced into hyperv.h but only used in one file.
Move them and let compiler decide on inline.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 30d1de08c87ddde6f73936c3350e7e153988fe02)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: style cleanups
Stephen Hemminger [Tue, 23 Aug 2016 19:17:47 +0000 (12:17 -0700)]
hv_netvsc: style cleanups

BugLink: http://bugs.launchpad.net/bugs/1650059
Fix most of the complaints about the style of the code.
Things like extra blank lines and return statements.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 796cc88c32c1bd1f833d596448ac785a8736e57c)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: use kcalloc
Stephen Hemminger [Tue, 23 Aug 2016 19:17:46 +0000 (12:17 -0700)]
hv_netvsc: use kcalloc

BugLink: http://bugs.launchpad.net/bugs/1650059
Better to use kcalloc rather than kzalloc and multiply for an array.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e53a9c2a5a8cd0a3a8b3c0f9b7a3ad9bc6a28867)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: make RSS hash key static
Stephen Hemminger [Tue, 23 Aug 2016 19:17:45 +0000 (12:17 -0700)]
hv_netvsc: make RSS hash key static

BugLink: http://bugs.launchpad.net/bugs/1650059
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 9477386687354f2aa8f4843170b7093c6dd1eb37)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: fix rtnl locking in callback
Stephen Hemminger [Tue, 23 Aug 2016 19:17:44 +0000 (12:17 -0700)]
hv_netvsc: fix rtnl locking in callback

BugLink: http://bugs.launchpad.net/bugs/1650059
The function get_netvsc_net_device had conditional locking. This was
unnecessary, incorrect, but harmless. It was unnecessary since the
code is only called from netlink netdev event callback where RTNL
is always acquired before the callbacks are run. It was incorrect
because of use of trylock and then continuing.
Fix by replacing with proper assertion.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8737caafd16790c654f1fb8564abcf6e1f3ffe19)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoPCI: hv: Use list_move_tail() instead of list_del() + list_add_tail()
Wei Yongjun [Thu, 28 Jul 2016 16:16:48 +0000 (16:16 +0000)]
PCI: hv: Use list_move_tail() instead of list_del() + list_add_tail()

BugLink: http://bugs.launchpad.net/bugs/1650059
Use list_move_tail() instead of list_del() + list_add_tail().  No
functional change intended

Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
(cherry picked from commit 4f1cb01a7892582d18483986fbc268cdef1b1dee)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: Implement batching of receive completions
Haiyang Zhang [Fri, 19 Aug 2016 21:47:09 +0000 (14:47 -0700)]
hv_netvsc: Implement batching of receive completions

BugLink: http://bugs.launchpad.net/bugs/1650059
The existing code uses busy retry when unable to send out receive
completions due to full ring buffer. It also gives up retrying after limit
is reached, and causes receive buffer slots not being recycled.
This patch implements batching of receive completions. It also prevents
dropping receive completions due to full ring buffer.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c0b558e5a393b77d2fe53335b5e07ca0e77178f8)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: Add handler for physical link speed change
Haiyang Zhang [Thu, 4 Aug 2016 17:42:15 +0000 (10:42 -0700)]
hv_netvsc: Add handler for physical link speed change

BugLink: http://bugs.launchpad.net/bugs/1650059
On Hyper-V host 2016 and later, VMs gets an event message of the physical
link speed when vSwitch is changed. This patch handles this message, so
the updated link speed can be reported by ethtool.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7f5d5af0b2f859f09b3dcb16a00b800fa48d9288)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohv_netvsc: Add query for initial physical link speed
Haiyang Zhang [Thu, 4 Aug 2016 17:42:14 +0000 (10:42 -0700)]
hv_netvsc: Add query for initial physical link speed

BugLink: http://bugs.launchpad.net/bugs/1650059
The physical link speed value will be reported by ethtool command.
The real speed is available from Windows 2016 host or later.

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b37879e6ca7079943542048da37f00a386c30cee)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agomemory-hotplug: add automatic onlining policy for the newly added memory
Vitaly Kuznetsov [Tue, 15 Mar 2016 21:56:48 +0000 (14:56 -0700)]
memory-hotplug: add automatic onlining policy for the newly added memory

BugLink: http://bugs.launchpad.net/bugs/1650059
Currently, all newly added memory blocks remain in 'offline' state
unless someone onlines them, some linux distributions carry special udev
rules like:

  SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"

to make this happen automatically.  This is not a great solution for
virtual machines where memory hotplug is being used to address high
memory pressure situations as such onlining is slow and a userspace
process doing this (udev) has a chance of being killed by the OOM killer
as it will probably require to allocate some memory.

Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/auto_online_blocks file with two possible
values: "offline" which preserves the current behavior and "online"
which causes all newly added memory blocks to go online as soon as
they're added.  The default is "offline".

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Xishi Qiu <qiuxishi@huawei.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoibmveth: calculate gso_segs for large packets
Thomas Falcon [Tue, 10 Jan 2017 22:02:24 +0000 (15:02 -0700)]
ibmveth: calculate gso_segs for large packets

BugLink: http://bugs.launchpad.net/bugs/1655420
Include calculations to compute the number of segments
that comprise an aggregated large packet.

Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Jonathan Maxwell <jmaxwell37@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 94acf164dc8f1184e8d0737be7125134c2701dbe)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoibmveth: set correct gso_size and gso_type
Thomas Falcon [Tue, 10 Jan 2017 22:02:23 +0000 (15:02 -0700)]
ibmveth: set correct gso_size and gso_type

BugLink: http://bugs.launchpad.net/bugs/1655420
This patch is based on an earlier one submitted
by Jon Maxwell with the following commit message:

"We recently encountered a bug where a few customers using ibmveth on the
same LPAR hit an issue where a TCP session hung when large receive was
enabled. Closer analysis revealed that the session was stuck because the
one side was advertising a zero window repeatedly.

We narrowed this down to the fact the ibmveth driver did not set gso_size
which is translated by TCP into the MSS later up the stack. The MSS is
used to calculate the TCP window size and as that was abnormally large,
it was calculating a zero window, even although the sockets receive buffer
was completely empty."

We rely on the Virtual I/O Server partition in a pseries
environment to provide the MSS through the TCP header checksum
field. The stipulation is that users should not disable checksum
offloading if rx packet aggregation is enabled through VIOS.

Some firmware offerings provide the MSS in the RX buffer.
This is signalled by a bit in the RX queue descriptor.

Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Pradeep Satyanarayana <pradeeps@linux.vnet.ibm.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Jonathan Maxwell <jmaxwell37@gmail.com>
Reviewed-by: David Dai <zdai@us.ibm.com>
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7b5967389f5a8dfb9d32843830f5e2717e20995d)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonetfilter: x_tables: pack percpu counter allocations
Florian Westphal [Tue, 10 Jan 2017 13:32:17 +0000 (08:32 -0500)]
netfilter: x_tables: pack percpu counter allocations

BugLink: https://bugs.launchpad.net/bugs/1640786
instead of allocating each xt_counter individually, allocate 4k chunks
and then use these for counter allocation requests.

This should speed up rule evaluation by increasing data locality,
also speeds up ruleset loading because we reduce calls to the percpu
allocator.

As Eric points out we can't use PAGE_SIZE, page_allocator would fail on
arches with 64k page size.

Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(backported from commit ae0ac0ed6fcf5af3be0f63eb935f483f44a402d2)
Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonetfilter: x_tables: pass xt_counters struct to counter allocator
Florian Westphal [Tue, 10 Jan 2017 13:32:16 +0000 (08:32 -0500)]
netfilter: x_tables: pass xt_counters struct to counter allocator

BugLink: https://bugs.launchpad.net/bugs/1640786
Keeps some noise away from a followup patch.

Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(backported from commit f28e15bacedd444608e25421c72eb2cf4527c9ca)
Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonetfilter: x_tables: pass xt_counters struct instead of packet counter
Florian Westphal [Tue, 10 Jan 2017 13:32:15 +0000 (08:32 -0500)]
netfilter: x_tables: pass xt_counters struct instead of packet counter

BugLink: https://bugs.launchpad.net/bugs/1640786
On SMP we overload the packet counter (unsigned long) to contain
percpu offset.  Hide this from callers and pass xt_counters address
instead.

Preparation patch to allocate the percpu counters in page-sized batch
chunks.

Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(backported from commit 4d31eef5176df06f218201bc9c0ce40babb41660)
Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoUBUNTU: [Config] Add IBM power drivers to the inclusion list
Tim Gardner [Mon, 9 Jan 2017 22:59:18 +0000 (15:59 -0700)]
UBUNTU: [Config] Add IBM power drivers to the inclusion list

BugLink: http://bugs.launchpad.net/bugs/1655002
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoLinux 4.4.43
Greg Kroah-Hartman [Sun, 15 Jan 2017 12:41:49 +0000 (13:41 +0100)]
Linux 4.4.43

BugLink: http://bugs.launchpad.net/bugs/1656876
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agomm/init: fix zone boundary creation
Oliver O'Halloran [Tue, 26 Jul 2016 22:22:17 +0000 (15:22 -0700)]
mm/init: fix zone boundary creation

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 90cae1fe1c3540f791d5b8e025985fa5e699b2bb upstream.

As a part of memory initialisation the architecture passes an array to
free_area_init_nodes() which specifies the max PFN of each memory zone.
This array is not necessarily monotonic (due to unused zones) so this
array is parsed to build monotonic lists of the min and max PFN for each
zone.  ZONE_MOVABLE is special cased here as its limits are managed by
the mm subsystem rather than the architecture.  Unfortunately, this
special casing is broken when ZONE_MOVABLE is the not the last zone in
the zone list.  The core of the issue is:

if (i == ZONE_MOVABLE)
continue;
arch_zone_lowest_possible_pfn[i] =
arch_zone_highest_possible_pfn[i-1];

As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will
be set to zero.  This patch fixes this bug by adding explicitly tracking
where the next zone should start rather than relying on the contents
arch_zone_highest_possible_pfn[].

Thie is low priority.  To get bitten by this you need to enable a zone
that appears after ZONE_MOVABLE in the zone_type enum.  As far as I can
tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled,
so I can't see this affecting too many people.

I only noticed this because I've been fiddling with ZONE_DEVICE on
powerpc and 4.6 broke my test kernel.  This bug, in conjunction with the
changes in Taku Izumi's kernelcore=mirror patch (d91749c1dda71) and
powerpc being the odd architecture which initialises max_zone_pfn[] to
~0ul instead of 0 caused all of system memory to be placed into
ZONE_DEVICE at boot, followed a panic since device memory cannot be used
for kernel allocations.  I've already submitted a patch to fix the
powerpc specific bits, but I figured this should be fixed too.

Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.com
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoALSA: usb-audio: Add a quirk for Plantronics BT600
Dennis Kadioglu [Mon, 9 Jan 2017 16:10:46 +0000 (17:10 +0100)]
ALSA: usb-audio: Add a quirk for Plantronics BT600

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 2e40795c3bf344cfb5220d94566205796e3ef19a upstream.

Plantronics BT600 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1" and "cannot get freq at
ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and
avoids those error messages.

Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agospi: mvebu: fix baudrate calculation for armada variant
Uwe Kleine-König [Thu, 8 Dec 2016 16:37:08 +0000 (17:37 +0100)]
spi: mvebu: fix baudrate calculation for armada variant

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 7243e0b20729d372e97763617a7a9c89f29b33e1 upstream.

The calculation of SPR and SPPR doesn't round correctly at several
places which might result in baud rates that are too big. For example
with tclk_hz = 250000001 and target rate 25000000 it determined a
divider of 10 which is wrong.

Instead of fixing all the corner cases replace the calculation by an
algorithm without a loop which should even be quicker to execute apart
from being correct.

Fixes: df59fa7f4bca ("spi: orion: support armada extended baud rates")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoARM: OMAP4+: Fix bad fallthrough for cpuidle
Tony Lindgren [Mon, 7 Nov 2016 23:50:11 +0000 (16:50 -0700)]
ARM: OMAP4+: Fix bad fallthrough for cpuidle

BugLink: http://bugs.launchpad.net/bugs/1656876
commit cbf2642872333547b56b8c4d943f5ed04ac9a4ee upstream.

We don't want to fall through to a bunch of errors for retention
if PM_OMAP4_CPU_OSWR_DISABLE is not configured for a SoC.

Fixes: 6099dd37c669 ("ARM: OMAP5 / DRA7: Enable CPU RET on suspend")
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoARM: zynq: Reserve correct amount of non-DMA RAM
Kyle Roeschley [Mon, 31 Oct 2016 16:26:17 +0000 (11:26 -0500)]
ARM: zynq: Reserve correct amount of non-DMA RAM

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 7a3cc2a7b2c723aa552028f4e66841cec183756d upstream.

On Zynq, we haven't been reserving the correct amount of DMA-incapable
RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
the first 512k). In older kernels, this was masked by the
memblock_reserve call in arm_memblock_init(). Now, reserve the correct
amount excplicitly rather than relying on swapper_pg_dir, which is an
address and not a size anyway.

Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the kernel")
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
Tested-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agopowerpc: Fix build warning on 32-bit PPC
Larry Finger [Fri, 23 Dec 2016 03:06:53 +0000 (21:06 -0600)]
powerpc: Fix build warning on 32-bit PPC

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.

I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:

    AS      arch/powerpc/kernel/misc_32.o
  arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef]

This problem is evident after commit 989cea5c14be ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created.  That was with commit 9994a33865f4 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S").

The offending line does not make a lot of sense.  This error does not
seem to cause any errors in the executable, thus I am not recommending
that it be applied to any stable versions.

Thanks to Nicholas Piggin for suggesting this solution.

Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoALSA: firewire-tascam: Fix to handle error from initialization of stream data
Takashi Sakamoto [Tue, 3 Jan 2017 02:58:33 +0000 (11:58 +0900)]
ALSA: firewire-tascam: Fix to handle error from initialization of stream data

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 6a2a2f45560a9cb7bc49820883b042e44f83726c upstream.

This module has a bug not to return error code in a case that data
structure for transmitted packets fails to be initialized.

This commit fixes the bug.

Fixes: 35efa5c489de ("ALSA: firewire-tascam: add streaming functionality")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoHID: hid-cypress: validate length of report
Greg Kroah-Hartman [Fri, 6 Jan 2017 14:33:36 +0000 (15:33 +0100)]
HID: hid-cypress: validate length of report

BugLink: http://bugs.launchpad.net/bugs/1656876
commit 1ebb71143758f45dc0fa76e2f48429e13b16d110 upstream.

Make sure we have enough of a report structure to validate before
looking at it.

Reported-by: Benoit Camredon <benoit.camredon@airbus.com>
Tested-by: Benoit Camredon <benoit.camredon@airbus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet: vrf: do not allow table id 0
David Ahern [Tue, 10 Jan 2017 23:22:25 +0000 (15:22 -0800)]
net: vrf: do not allow table id 0

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 24c63bbc18e25d5d8439422aa5fd2d66390b88eb ]

Frank reported that vrf devices can be created with a table id of 0.
This breaks many of the run time table id checks and should not be
allowed. Detect this condition at create time and fail with EINVAL.

Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
Reported-by: Frank Kellermann <frank.kellermann@atos.net>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet: ipv4: Fix multipath selection with vrf
David Ahern [Tue, 10 Jan 2017 22:37:35 +0000 (14:37 -0800)]
net: ipv4: Fix multipath selection with vrf

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 7a18c5b9fb31a999afc62b0e60978aa896fc89e9 ]

fib_select_path does not call fib_select_multipath if oif is set in the
flow struct. For VRF use cases oif is always set, so multipath route
selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif
check similar to what is done in fib_table_lookup.

Add saddr and proto to the flow struct for the fib lookup done by the
VRF driver to better match hash computation for a flow.

Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agogro: Disable frag0 optimization on IPv6 ext headers
Herbert Xu [Tue, 10 Jan 2017 20:24:15 +0000 (12:24 -0800)]
gro: Disable frag0 optimization on IPv6 ext headers

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 57ea52a865144aedbcd619ee0081155e658b6f7d ]

The GRO fast path caches the frag0 address.  This address becomes
invalid if frag0 is modified by pskb_may_pull or its variants.
So whenever that happens we must disable the frag0 optimization.

This is usually done through the combination of gro_header_hard
and gro_header_slow, however, the IPv6 extension header path did
the pulling directly and would continue to use the GRO fast path
incorrectly.

This patch fixes it by disabling the fast path when we enter the
IPv6 extension header path.

Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
Reported-by: Slava Shwartsman <slavash@mellanox.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agogro: use min_t() in skb_gro_reset_offset()
Eric Dumazet [Wed, 11 Jan 2017 03:52:43 +0000 (19:52 -0800)]
gro: use min_t() in skb_gro_reset_offset()

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 7cfd5fd5a9813f1430290d20c0fead9b4582a307 ]

On 32bit arches, (skb->end - skb->data) is not 'unsigned int',
so we shall use min_t() instead of min() to avoid a compiler error.

Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom")
Reported-by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agogro: Enter slow-path if there is no tailroom
Herbert Xu [Tue, 10 Jan 2017 20:24:01 +0000 (12:24 -0800)]
gro: Enter slow-path if there is no tailroom

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 1272ce87fa017ca4cf32920764d879656b7a005a ]

The GRO path has a fast-path where we avoid calling pskb_may_pull
and pskb_expand by directly accessing frag0.  However, this should
only be done if we have enough tailroom in the skb as otherwise
we'll have to expand it later anyway.

This patch adds the check by capping frag0_len with the skb tailroom.

Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull")
Reported-by: Slava Shwartsman <slavash@mellanox.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agor8152: fix rx issue for runtime suspend
hayeswang [Tue, 10 Jan 2017 09:04:07 +0000 (17:04 +0800)]
r8152: fix rx issue for runtime suspend

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 75dc692eda114cb234a46cb11893a9c3ea520934 ]

Pause the rx and make sure the rx fifo is empty when the autosuspend
occurs.

If the rx data comes when the driver is canceling the rx urb, the host
controller would stop getting the data from the device and continue
it after next rx urb is submitted. That is, one continuing data is
split into two different urb buffers. That let the driver take the
data as a rx descriptor, and unexpected behavior happens.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agor8152: split rtl8152_suspend function
hayeswang [Tue, 10 Jan 2017 09:04:06 +0000 (17:04 +0800)]
r8152: split rtl8152_suspend function

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 8fb280616878b81c0790a0c33acbeec59c5711f4 ]

Split rtl8152_suspend() into rtl8152_system_suspend() and
rtl8152_rumtime_suspend().

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoipv4: Do not allow MAIN to be alias for new LOCAL w/ custom rules
Alexander Duyck [Mon, 2 Jan 2017 21:32:54 +0000 (13:32 -0800)]
ipv4: Do not allow MAIN to be alias for new LOCAL w/ custom rules

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 5350d54f6cd12eaff623e890744c79b700bd3f17 ]

In the case of custom rules being present we need to handle the case of the
LOCAL table being intialized after the new rule has been added.  To address
that I am adding a new check so that we can make certain we don't use an
alias of MAIN for LOCAL when allocating a new table.

Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
Reported-by: Oliver Brunel <jjk@jjacky.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoigmp: Make igmp group member RFC 3376 compliant
Michal Tesar [Mon, 2 Jan 2017 13:38:36 +0000 (14:38 +0100)]
igmp: Make igmp group member RFC 3376 compliant

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 7ababb782690e03b78657e27bd051e20163af2d6 ]

5.2. Action on Reception of a Query

 When a system receives a Query, it does not respond immediately.
 Instead, it delays its response by a random amount of time, bounded
 by the Max Resp Time value derived from the Max Resp Code in the
 received Query message.  A system may receive a variety of Queries on
 different interfaces and of different kinds (e.g., General Queries,
 Group-Specific Queries, and Group-and-Source-Specific Queries), each
 of which may require its own delayed response.

 Before scheduling a response to a Query, the system must first
 consider previously scheduled pending responses and in many cases
 schedule a combined response.  Therefore, the system must be able to
 maintain the following state:

 o A timer per interface for scheduling responses to General Queries.

 o A per-group and interface timer for scheduling responses to Group-
   Specific and Group-and-Source-Specific Queries.

 o A per-group and interface list of sources to be reported in the
   response to a Group-and-Source-Specific Query.

 When a new Query with the Router-Alert option arrives on an
 interface, provided the system has state to report, a delay for a
 response is randomly selected in the range (0, [Max Resp Time]) where
 Max Resp Time is derived from Max Resp Code in the received Query
 message.  The following rules are then used to determine if a Report
 needs to be scheduled and the type of Report to schedule.  The rules
 are considered in order and only the first matching rule is applied.

 1. If there is a pending response to a previous General Query
    scheduled sooner than the selected delay, no additional response
    needs to be scheduled.

 2. If the received Query is a General Query, the interface timer is
    used to schedule a response to the General Query after the
    selected delay.  Any previously pending response to a General
    Query is canceled.
--8<--

Currently the timer is rearmed with new random expiration time for
every incoming query regardless of possibly already pending report.
Which is not aligned with the above RFE.
It also might happen that higher rate of incoming queries can
postpone the report after the expiration time of the first query
causing group membership loss.

Now the per interface general query timer is rearmed only
when there is no pending report already scheduled on that interface or
the newly selected expiration time is before the already pending
scheduled report.

Signed-off-by: Michal Tesar <mtesar@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agodrop_monitor: consider inserted data in genlmsg_end
Reiter Wolfgang [Tue, 3 Jan 2017 00:39:10 +0000 (01:39 +0100)]
drop_monitor: consider inserted data in genlmsg_end

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 3b48ab2248e61408910e792fe84d6ec466084c1a ]

Final nlmsg_len field update must reflect inserted net_dm_drop_point
data.

This patch depends on previous patch:
"drop_monitor: add missing call to genlmsg_end"

Signed-off-by: Reiter Wolfgang <wr0112358@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agodrop_monitor: add missing call to genlmsg_end
Reiter Wolfgang [Sat, 31 Dec 2016 20:11:57 +0000 (21:11 +0100)]
drop_monitor: add missing call to genlmsg_end

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 4200462d88f47f3759bdf4705f87e207b0f5b2e4 ]

Update nlmsg_len field with genlmsg_end to enable userspace processing
using nlmsg_next helper. Also adds error handling.

Signed-off-by: Reiter Wolfgang <wr0112358@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet/mlx5: Avoid shadowing numa_node
Eli Cohen [Wed, 28 Dec 2016 12:58:34 +0000 (14:58 +0200)]
net/mlx5: Avoid shadowing numa_node

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit d151d73dcc99de87c63bdefebcc4cb69de1cdc40 ]

Avoid using a local variable named numa_node to avoid shadowing a public
one.

Fixes: db058a186f98 ('net/mlx5_core: Set irq affinity hints')
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet/mlx5: Check FW limitations on log_max_qp before setting it
Noa Osherovich [Wed, 28 Dec 2016 12:58:32 +0000 (14:58 +0200)]
net/mlx5: Check FW limitations on log_max_qp before setting it

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 883371c453b937f9eb581fb4915210865982736f ]

When setting HCA capabilities, set log_max_qp to be the minimum
between the selected profile's value and the HCA limitation.

Fixes: 938fe83c8dcb ('net/mlx5_core: New device capabilities...')
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet: stmmac: Fix race between stmmac_drv_probe and stmmac_open
Florian Fainelli [Wed, 28 Dec 2016 02:23:06 +0000 (18:23 -0800)]
net: stmmac: Fix race between stmmac_drv_probe and stmmac_open

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 5701659004d68085182d2fd4199c79172165fa65 ]

There is currently a small window during which the network device registered by
stmmac can be made visible, yet all resources, including and clock and MDIO bus
have not had a chance to be set up, this can lead to the following error to
occur:

[  473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                stmmac_dvr_probe: warning: cannot get CSR clock
[  473.919382] stmmaceth 0000:01:00.0: no reset control found
[  473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42
[  473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported
[  473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported
[  473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported
[  473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                Enable RX Mitigation via HW Watchdog Timer
[  473.921395] libphy: PHY stmmac-1:00 not found
[  473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY
[  473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to
                PHY (error: -19)
[  473.959710] libphy: stmmac: probed
[  473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL
                (stmmac-1:00) active
[  473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL
                (stmmac-1:01)
[  473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL
                (stmmac-1:02)
[  473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL
                (stmmac-1:03)

Fix this by making sure that register_netdev() is the last thing being done,
which guarantees that the clock and the MDIO bus are available.

Fixes: 4bfcbd7abce2 ("stmmac: Move the mdio_register/_unregister in probe/remove")
Reported-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet, sched: fix soft lockup in tc_classify
Daniel Borkmann [Wed, 21 Dec 2016 17:04:11 +0000 (18:04 +0100)]
net, sched: fix soft lockup in tc_classify

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 628185cfddf1dfb701c4efe2cfd72cf5b09f5702 ]

Shahar reported a soft lockup in tc_classify(), where we run into an
endless loop when walking the classifier chain due to tp->next == tp
which is a state we should never run into. The issue only seems to
trigger under load in the tc control path.

What happens is that in tc_ctl_tfilter(), thread A allocates a new
tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
with it. In that classifier callback we had to unlock/lock the rtnl
mutex and returned with -EAGAIN. One reason why we need to drop there
is, for example, that we need to request an action module to be loaded.

This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning
after we loaded and found the requested action, we need to redo the
whole request so we don't race against others. While we had to unlock
rtnl in that time, thread B's request was processed next on that CPU.
Thread B added a new tp instance successfully to the classifier chain.
When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN
and destroying its tp instance which never got linked, we goto replay
and redo A's request.

This time when walking the classifier chain in tc_ctl_tfilter() for
checking for existing tp instances we had a priority match and found
the tp instance that was created and linked by thread B. Now calling
again into tp->ops->change() with that tp was successful and returned
without error.

tp_created was never cleared in the second round, thus kernel thinks
that we need to link it into the classifier chain (once again). tp and
*back point to the same object due to the match we had earlier on. Thus
for thread B's already public tp, we reset tp->next to tp itself and
link it into the chain, which eventually causes the mentioned endless
loop in tc_classify() once a packet hits the data path.

Fix is to clear tp_created at the beginning of each request, also when
we replay it. On the paths that can cause -EAGAIN we already destroy
the original tp instance we had and on replay we really need to start
from scratch. It seems that this issue was first introduced in commit
12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining
and avoid kernel panic when we use cls_cgroup").

Fixes: 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup")
Reported-by: Shahar Klein <shahark@mellanox.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Tested-by: Shahar Klein <shahark@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoipv6: handle -EFAULT from skb_copy_bits
Dave Jones [Thu, 22 Dec 2016 16:16:22 +0000 (11:16 -0500)]
ipv6: handle -EFAULT from skb_copy_bits

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit a98f91758995cb59611e61318dddd8a6956b52c3 ]

By setting certain socket options on ipv6 raw sockets, we can confuse the
length calculation in rawv6_push_pending_frames triggering a BUG_ON.

RIP: 0010:[<ffffffff817c6390>] [<ffffffff817c6390>] rawv6_sendmsg+0xc30/0xc40
RSP: 0018:ffff881f6c4a7c18  EFLAGS: 00010282
RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002
RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00
RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009
R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030
R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80

Call Trace:
 [<ffffffff8118ba23>] ? unmap_page_range+0x693/0x830
 [<ffffffff81772697>] inet_sendmsg+0x67/0xa0
 [<ffffffff816d93f8>] sock_sendmsg+0x38/0x50
 [<ffffffff816d982f>] SYSC_sendto+0xef/0x170
 [<ffffffff816da27e>] SyS_sendto+0xe/0x10
 [<ffffffff81002910>] do_syscall_64+0x50/0xa0
 [<ffffffff817f7cbc>] entry_SYSCALL64_slow_path+0x25/0x25

Handle by jumping to the failure path if skb_copy_bits gets an EFAULT.

Reproducer:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define LEN 504

int main(int argc, char* argv[])
{
int fd;
int zero = 0;
char buf[LEN];

memset(buf, 0, LEN);

fd = socket(AF_INET6, SOCK_RAW, 7);

setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, &zero, 4);
setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN);

sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110);
}

Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet: vrf: Drop conntrack data after pass through VRF device on Tx
David Ahern [Wed, 14 Dec 2016 22:31:11 +0000 (14:31 -0800)]
net: vrf: Drop conntrack data after pass through VRF device on Tx

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit eb63ecc1706b3e094d0f57438b6c2067cfc299f2 ]

Locally originated traffic in a VRF fails in the presence of a POSTROUTING
rule. For example,

    $ iptables -t nat -A POSTROUTING -s 11.1.1.0/24  -j MASQUERADE
    $ ping -I red -c1 11.1.1.3
    ping: Warning: source address might be selected on device other than red.
    PING 11.1.1.3 (11.1.1.3) from 11.1.1.2 red: 56(84) bytes of data.
    ping: sendmsg: Operation not permitted

Worse, the above causes random corruption resulting in a panic in random
places (I have not seen a consistent backtrace).

Call nf_reset to drop the conntrack info following the pass through the
VRF device.  The nf_reset is needed on Tx but not Rx because of the order
in which NF_HOOK's are hit: on Rx the VRF device is after the real ingress
device and on Tx it is is before the real egress device. Connection
tracking should be tied to the real egress device and not the VRF device.

Fixes: 8f58336d3f78a ("net: Add ethernet header for pass through VRF device")
Fixes: 35402e3136634 ("net: Add IPv6 support to VRF device")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoser_gigaset: return -ENOMEM on error instead of success
Dan Carpenter [Wed, 7 Dec 2016 11:22:03 +0000 (14:22 +0300)]
ser_gigaset: return -ENOMEM on error instead of success

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit 93a97c50cbf1c007caf12db5cc23e0d5b9c8473c ]

If we can't allocate the resources in gigaset_initdriver() then we
should return -ENOMEM instead of zero.

Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonetvsc: reduce maximum GSO size
stephen hemminger [Tue, 6 Dec 2016 21:43:54 +0000 (13:43 -0800)]
netvsc: reduce maximum GSO size

BugLink: http://bugs.launchpad.net/bugs/1656876
[ Upstream commit a50af86dd49ee1851d1ccf06dd0019c05b95e297 ]

Hyper-V (and Azure) support using NVGRE which requires some extra space
for encapsulation headers. Because of this the largest allowed TSO
packet is reduced.

For older releases, hard code a fixed reduced value.  For next release,
there is a better solution which uses result of host offload
negotiation.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoLinux 4.4.42
Greg Kroah-Hartman [Thu, 12 Jan 2017 10:23:02 +0000 (11:23 +0100)]
Linux 4.4.42

BugLink: http://bugs.launchpad.net/bugs/1655969
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agousb: gadget: composite: always set ep->mult to a sensible value
Felipe Balbi [Wed, 28 Sep 2016 09:33:31 +0000 (12:33 +0300)]
usb: gadget: composite: always set ep->mult to a sensible value

BugLink: http://bugs.launchpad.net/bugs/1655969
commit eaa496ffaaf19591fe471a36cef366146eeb9153 upstream.

ep->mult is supposed to be set to Isochronous and
Interrupt Endapoint's multiplier value. This value
is computed from different places depending on the
link speed.

If we're dealing with HighSpeed, then it's part of
bits [12:11] of wMaxPacketSize. This case wasn't
taken into consideration before.

While at that, also make sure the ep->mult defaults
to one so drivers can use it unconditionally and
assume they'll never multiply ep->maxpacket to zero.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoRevert "usb: gadget: composite: always set ep->mult to a sensible value"
Greg Kroah-Hartman [Thu, 12 Jan 2017 07:54:43 +0000 (08:54 +0100)]
Revert "usb: gadget: composite: always set ep->mult to a sensible value"

BugLink: http://bugs.launchpad.net/bugs/1655969
This reverts commit c53af76d5de1af844a71e673ae4a02f1786c1b9c which is
commit eaa496ffaaf19591fe471a36cef366146eeb9153 upstream as it was
incorrect.

Reported-by: Bin Liu <b-liu@ti.com>
Cc: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agotick/broadcast: Prevent NULL pointer dereference
Thomas Gleixner [Thu, 15 Dec 2016 11:10:37 +0000 (12:10 +0100)]
tick/broadcast: Prevent NULL pointer dereference

BugLink: http://bugs.launchpad.net/bugs/1655969
commit c1a9eeb938b5433947e5ea22f89baff3182e7075 upstream.

When a disfunctional timer, e.g. dummy timer, is installed, the tick core
tries to setup the broadcast timer.

If no broadcast device is installed, the kernel crashes with a NULL pointer
dereference in tick_broadcast_setup_oneshot() because the function has no
sanity check.

Reported-by: Mason <slash.tmp@free.fr>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: Richard Cochran <rcochran@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Cc: Sebastian Frias <sf84@laposte.net>
Cc: Thibaud Cornic <thibaud_cornic@sigmadesigns.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Link: http://lkml.kernel.org/r/1147ef90-7877-e4d2-bb2b-5c4fa8d3144b@free.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agodrm/radeon: Always store CRTC relative radeon_crtc->cursor_x/y values
Michel Dänzer [Thu, 27 Oct 2016 06:37:44 +0000 (15:37 +0900)]
drm/radeon: Always store CRTC relative radeon_crtc->cursor_x/y values

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 4349bd775cc8fd75cb648e3a2036a690f497de5c upstream.

We were storing viewport relative coordinates for AVIVO/DCE display
engines. However, radeon_crtc_cursor_set2 and radeon_cursor_reset pass
radeon_crtc->cursor_x/y as the x/y parameters of
radeon_cursor_move_locked, which would break if the CRTC isn't located
at (0, 0).

Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocx23885-dvb: move initialization of a8293_pdata
Mauro Carvalho Chehab [Fri, 18 Dec 2015 16:22:21 +0000 (14:22 -0200)]
cx23885-dvb: move initialization of a8293_pdata

BugLink: http://bugs.launchpad.net/bugs/1655969
commit f0b0faff78c2c2e8efe843de55405a1f0470b8c4 upstream.

Smatch complains about where the au8293_data is placed:

drivers/media/pci/cx23885/cx23885-dvb.c:2174 dvb_register() info: 'a8293_pdata' is not actually initialized (unreached code).

It is not actually expected to have such initialization at

switch {
foo = bar;

case:
...
}

Not really sure how gcc does that, but this is something that I would
expect that different compilers would do different things.

David Howells checked with the compiler people: it's not really expected to
initialise as expected.

So, move the initialization outside the switch(), making smatch to
shut up one warning.

Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet: vxge: avoid unused function warnings
Arnd Bergmann [Fri, 29 Jan 2016 11:39:13 +0000 (12:39 +0100)]
net: vxge: avoid unused function warnings

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 57e7c8cef224af166b8ec932b5e383641418c005 upstream.

When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
in the vxge driver:

drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]

We could add another #ifdef here, but it's nicer to avoid those warnings
for good by converting the existing #ifdef to if(IS_ENABLED()), which has
the same effect but provides better compile-time coverage in general,
and lets the compiler understand better when the function is intentionally
unused.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agonet: ti: cpmac: Fix compiler warning due to type confusion
Paul Burton [Fri, 2 Sep 2016 14:22:48 +0000 (15:22 +0100)]
net: ti: cpmac: Fix compiler warning due to type confusion

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 2f5281ba2a8feaf6f0aee93356f350855bb530fc upstream.

cpmac_start_xmit() used the max() macro on skb->len (an unsigned int)
and ETH_ZLEN (a signed int literal). This led to the following compiler
warning:

  In file included from include/linux/list.h:8:0,
                   from include/linux/module.h:9,
                   from drivers/net/ethernet/ti/cpmac.c:19:
  drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit':
  include/linux/kernel.h:748:17: warning: comparison of distinct pointer
  types lacks a cast
    (void) (&_max1 == &_max2);  \
                   ^
  drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max'
    len = max(skb->len, ETH_ZLEN);
          ^

On top of this, it assigned the result of the max() macro to a signed
integer whilst all further uses of it result in it being cast to varying
widths of unsigned integer.

Fix this up by using max_t to ensure the comparison is performed as
unsigned integers, and for consistency change the type of the len
variable to unsigned int.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocred/userns: define current_user_ns() as a function
Arnd Bergmann [Tue, 22 Mar 2016 21:27:11 +0000 (14:27 -0700)]
cred/userns: define current_user_ns() as a function

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 0335695dfa4df01edff5bb102b9a82a0668ee51e upstream.

The current_user_ns() macro currently returns &init_user_ns when user
namespaces are disabled, and that causes several warnings when building
with gcc-6.0 in code that compares the result of the macro to
&init_user_ns itself:

  fs/xfs/xfs_ioctl.c: In function 'xfs_ioctl_setattr_check_projid':
  fs/xfs/xfs_ioctl.c:1249:22: error: self-comparison always evaluates to true [-Werror=tautological-compare]
    if (current_user_ns() == &init_user_ns)

This is a legitimate warning in principle, but here it isn't really
helpful, so I'm reprasing the definition in a way that shuts up the
warning.  Apparently gcc only warns when comparing identical literals,
but it can figure out that the result of an inline function can be
identical to a constant expression in order to optimize a condition yet
not warn about the fact that the condition is known at compile time.
This is exactly what we want here, and it looks reasonable because we
generally prefer inline functions over macros anyway.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agostaging: comedi: dt282x: tidy up register bit defines
H Hartley Sweeten [Thu, 17 Mar 2016 17:10:40 +0000 (10:10 -0700)]
staging: comedi: dt282x: tidy up register bit defines

BugLink: http://bugs.launchpad.net/bugs/1655969
commit f6b1160eb27f990cc1c48b67a5f83cb63115284e upstream.

Arnd Bergmann pointed out that gcc-6 warns about passing negative signed
integer into swab16() due to the macro expansion of 'outw'.

It appears that the register map constants are causing the warnings.
Actually, it might just be the (1 << 15) ones...

Convert all the constants as suggested by checkpatch.pl:
CHECK: Prefer using the BIT macro

The BIT() macro will make all the constants explicitly 'unsigned', which
helps to avoid the warning.

Fix the, unsused, DT2821_CHANCSR_PRESLA() macro. The "Present List
Address" (PRESLA) bits in the CHANCSR register are read only. This
define was meant to extract the bits from the read value.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agopowerpc/pci/rpadlpar: Fix device reference leaks
Johan Hovold [Tue, 1 Nov 2016 15:26:03 +0000 (16:26 +0100)]
powerpc/pci/rpadlpar: Fix device reference leaks

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream.

Make sure to drop any device reference taken by vio_find_node() when
adding and removing virtual I/O slots.

Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agomd: MD_RECOVERY_NEEDED is set for mddev->recovery
Shaohua Li [Thu, 8 Dec 2016 23:48:18 +0000 (15:48 -0800)]
md: MD_RECOVERY_NEEDED is set for mddev->recovery

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 82a301cb0ea2df8a5c88213094a01660067c7fb4 upstream.

Fixes: 90f5f7ad4f38("md: Wait for md_check_recovery before attempting device
removal.")

Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/aes-ce - fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:13 +0000 (19:15 +0100)]
crypto: arm64/aes-ce - fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 1803b9a52c4e5a5dbb8a27126f6bc06939359753 upstream.

The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.

Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/aes-xts-ce: fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:19 +0000 (19:15 +0100)]
crypto: arm64/aes-xts-ce: fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit caf4b9e2b326cc2a5005a5c557274306536ace61 upstream.

Emit the XTS tweak literal constants in the appropriate order for a
single 128-bit scalar literal load.

Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/sha1-ce - fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:15 +0000 (19:15 +0100)]
crypto: arm64/sha1-ce - fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit ee71e5f1e7d25543ee63a80451871f8985b8d431 upstream.

The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.

Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/aes-neon - fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:18 +0000 (19:15 +0100)]
crypto: arm64/aes-neon - fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit a2c435cc99862fd3d165e1b66bf48ac72c839c62 upstream.

The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.

Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/aes-ccm-ce: fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:17 +0000 (19:15 +0100)]
crypto: arm64/aes-ccm-ce: fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 56e4e76c68fcb51547b5299e5b66a135935ff414 upstream.

The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.

Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm/aes-ce - fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:20 +0000 (19:15 +0100)]
crypto: arm/aes-ce - fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 58010fa6f71c9577922b22e46014b95a4ec80fa0 upstream.

The AES key schedule generation is mostly endian agnostic, with the
exception of the rotation and the incorporation of the round constant
at the start of each round. So implement a big endian specific version
of that part to make the whole routine big endian compatible.

Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/ghash-ce - fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:14 +0000 (19:15 +0100)]
crypto: arm64/ghash-ce - fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 9c433ad5083fd4a4a3c721d86cbfbd0b2a2326a5 upstream.

The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.

Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocrypto: arm64/sha2-ce - fix for big endian
Ard Biesheuvel [Tue, 11 Oct 2016 18:15:16 +0000 (19:15 +0100)]
crypto: arm64/sha2-ce - fix for big endian

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 174122c39c369ed924d2608fc0be0171997ce800 upstream.

The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.

Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agos390/crypto: unlock on error in prng_tdes_read()
Dan Carpenter [Fri, 18 Nov 2016 11:11:00 +0000 (14:11 +0300)]
s390/crypto: unlock on error in prng_tdes_read()

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 9e6e7c74315095fd40f41003850690c711e44420 upstream.

We added some new locking but forgot to unlock on error.

Fixes: 57127645d79d ("s390/zcrypt: Introduce new SHA-512 based Pseudo Random Generator.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agommc: mmc_test: Uninitialized return value
Dan Carpenter [Mon, 14 Nov 2016 11:31:34 +0000 (14:31 +0300)]
mmc: mmc_test: Uninitialized return value

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 16652a936e96f5dae53c3fbd38a570497baadaa8 upstream.

We never set "ret" to RESULT_OK.

Fixes: 9f9c4180f88d ("mmc: mmc_test: add test for non-blocking transfers")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoPM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend
Tony Lindgren [Tue, 6 Dec 2016 00:38:16 +0000 (16:38 -0800)]
PM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend

BugLink: http://bugs.launchpad.net/bugs/1655969
commit bed570307ed78f21b77cb04a1df781dee4a8f05a upstream.

I noticed some wakeirq flakeyness with consumer drivers not using
autosuspend. For drivers not using autosuspend, the wakeirq may never
get unmasked in rpm_suspend() because of irq desc->depth.

We are configuring dedicated wakeirqs to start with IRQ_NOAUTOEN as we
naturally don't want them running until rpm_suspend() is called.

However, when a consumer driver initially calls pm_runtime_get(), we
now wrongly start with disable_irq_nosync() call on the dedicated
wakeirq that is disabled to start with.

This causes desc->depth to toggle between 1 and 2 instead of the usual
0 and 1. This can prevent enable_irq() from unmasking the wakeirq as
that only happens at desc->depth 1.

This does not necessarily show up with drivers using autosuspend as
there is time for disable_irq_nosync() before rpm_suspend() gets called
after the autosuspend timeout.

Let's fix the issue by adding wirq->status that lazily gets set on
the first rpm_suspend(). We also need PM runtime core private functions
for dev_pm_enable_wake_irq_check() and dev_pm_disable_wake_irq_check()
so we can enable the dedicated wakeirq on the first rpm_suspend().

While at it, let's also fix the comments for dev_pm_enable_wake_irq()
and dev_pm_disable_wake_irq(). Those can still be used by the consumer
drivers as needed because the IRQ core manages the interrupt usecount
for us.

Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoirqchip/bcm7038-l1: Implement irq_cpu_offline() callback
Florian Fainelli [Mon, 31 Oct 2016 21:17:35 +0000 (14:17 -0700)]
irqchip/bcm7038-l1: Implement irq_cpu_offline() callback

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 34c535793bcbf9263cf22f8a52101f796cdfab8e upstream.

We did not implement an irq_cpu_offline callback for our irqchip, yet we
support setting a given IRQ's affinity. This resulted in interrupts
whose affinity mask included CPUs being taken offline not to work
correctly once the CPU had been put offline.

Fixes: 5f7f0317ed28 ("IRQCHIP: Add new driver for BCM7038-style level 1 interrupt controllers")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Cc: cernekee@gmail.com
Cc: jaedon.shin@gmail.com
Cc: ralf@linux-mips.org
Cc: justinpopo6@gmail.com
Link: http://lkml.kernel.org/r/1477948656-12966-2-git-send-email-f.fainelli@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agotarget/iscsi: Fix double free in lio_target_tiqn_addtpg()
Dan Carpenter [Tue, 13 Dec 2016 12:27:04 +0000 (15:27 +0300)]
target/iscsi: Fix double free in lio_target_tiqn_addtpg()

BugLink: http://bugs.launchpad.net/bugs/1655969
commit a91918cd3ea11f91c68e08e1e8ce1b560447a80e upstream.

This iscsit_tpg_add_portal_group() function is only called from
lio_target_tiqn_addtpg().  Both functions free the "tpg" pointer on
error so it's a double free bug.  The memory is allocated in the caller
so it should be freed in the caller and not here.

Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
[ bvanassche: Added "Fix" at start of patch title ]
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoscsi: mvsas: fix command_active typo
Arnd Bergmann [Wed, 16 Nov 2016 15:08:34 +0000 (16:08 +0100)]
scsi: mvsas: fix command_active typo

BugLink: http://bugs.launchpad.net/bugs/1655969
commit af15769ffab13d777e55fdef09d0762bf0c249c4 upstream.

gcc-7 notices that the condition in mvs_94xx_command_active looks
suspicious:

drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active':
drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]

This was introduced when the mv_printk() statement got added, and leads
to the condition being ignored. This is probably harmless.

Changing '&&' to '&' makes the code look reasonable, as we check the
command bit before setting and printing it.

Fixes: a4632aae8b66 ("[SCSI] mvsas: Add new macros and functions")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoASoC: samsung: i2s: Fixup last IRQ unsafe spin lock call
Charles Keepax [Fri, 21 Oct 2016 13:18:48 +0000 (14:18 +0100)]
ASoC: samsung: i2s: Fixup last IRQ unsafe spin lock call

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 5faf071d08ddd1c1be66deaa93a09ccf43f5b538 upstream.

Unfortunately, I seem to have missed a case where an IRQ safe spinlock was
required, in samsung_i2s_dai_remove, when I fixed up the other calls in
this patch:

316fa9e09ad7 ("ASoC: samsung: Use IRQ safe spin lock calls")

This causes a lockdep warning when unbinding and rebinding the audio card:

[  104.357664]        CPU0                    CPU1
[  104.362174]        ----                    ----
[  104.366692]   lock(&(&pri_dai->spinlock)->rlock);
[  104.371372]                                local_irq_disable();
[  104.377283]                                lock(&(&substream->self_group.lock)->rlock);
[  104.385259]                                lock(&(&pri_dai->spinlock)->rlock);
[  104.392469]   <Interrupt>
[  104.395072]     lock(&(&substream->self_group.lock)->rlock);
[  104.400710]
[  104.400710]  *** DEADLOCK ***

Fixes: ce8bcdbb61d9 ("ASoC: samsung: i2s: Protect more registers with a spinlock")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoiommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped
Xunlei Pang [Mon, 5 Dec 2016 12:09:07 +0000 (20:09 +0800)]
iommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped

BugLink: http://bugs.launchpad.net/bugs/1655969
commit aec0e86172a79eb5e44aff1055bb953fe4d47c59 upstream.

We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
under kdump, it can be steadily reproduced on several different machines,
the dmesg log is like:
HP HPSA Driver (v 3.4.16-0)
hpsa 0000:02:00.0: using doorbell to reset controller
hpsa 0000:02:00.0: board ready after hard reset.
hpsa 0000:02:00.0: Waiting for controller to respond to no-op
DMAR: Setting identity map for device 0000:02:00.0 [0xe8000 - 0xe8fff]
DMAR: Setting identity map for device 0000:02:00.0 [0xf4000 - 0xf4fff]
DMAR: Setting identity map for device 0000:02:00.0 [0xbdf6e000 - 0xbdf6efff]
DMAR: Setting identity map for device 0000:02:00.0 [0xbdf6f000 - 0xbdf7efff]
DMAR: Setting identity map for device 0000:02:00.0 [0xbdf7f000 - 0xbdf82fff]
DMAR: Setting identity map for device 0000:02:00.0 [0xbdf83000 - 0xbdf84fff]
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read] Request device [02:00.0] fault addr fffff000 [fault reason 06] PTE Read access is not set
hpsa 0000:02:00.0: controller message 03:00 timed out
hpsa 0000:02:00.0: no-op failed; re-trying

After some debugging, we found that the fault addr is from DMA initiated at
the driver probe stage after reset(not in-flight DMA), and the corresponding
pte entry value is correct, the fault is likely due to the old iommu caches
of the in-flight DMA before it.

Thus we need to flush the old cache after context mapping is setup for the
device, where the device is supposed to finish reset at its driver probe
stage and no in-flight DMA exists hereafter.

I'm not sure if the hardware is responsible for invalidating all the related
caches allocated in the iommu hardware before, but seems not the case for hpsa,
actually many device drivers have problems in properly resetting the hardware.
Anyway flushing (again) by software in kdump kernel when the device gets context
mapped which is a quite infrequent operation does little harm.

With this patch, the problematic machine can survive the kdump tests.

CC: Myron Stowe <myron.stowe@gmail.com>
CC: Joseph Szczypek <jszczype@redhat.com>
CC: Don Brace <don.brace@microsemi.com>
CC: Baoquan He <bhe@redhat.com>
CC: Dave Young <dyoung@redhat.com>
Fixes: 091d42e43d21 ("iommu/vt-d: Copy translation tables from old kernel")
Fixes: dbcd861f252d ("iommu/vt-d: Do not re-use domain-ids from the old kernel")
Fixes: cf484d0e6939 ("iommu/vt-d: Mark copied context entries")
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Tested-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoiommu/vt-d: Fix pasid table size encoding
Jacob Pan [Tue, 6 Dec 2016 18:14:23 +0000 (10:14 -0800)]
iommu/vt-d: Fix pasid table size encoding

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 65ca7f5f7d1cdde6c25172fe6107cd16902f826f upstream.

Different encodings are used to represent supported PASID bits
and number of PASID table entries.
The current code assigns ecap_pss directly to extended context
table entry PTS which is wrong and could result in writing
non-zero bits to the reserved fields. IOMMU fault reason
11 will be reported when reserved bits are nonzero.
This patch converts ecap_pss to extend context entry pts encoding
based on VT-d spec. Chapter 9.4 as follows:
 - number of PASID bits = ecap_pss + 1
 - number of PASID table entries = 2^(pts + 5)
Software assigned limit of pasid_max value is also respected to
match the allocation limitation of PASID table.

cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
cc: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Tested-by: Mika Kuoppala <mika.kuoppala@intel.com>
Fixes: 2f26e0a9c9860 ('iommu/vt-d: Add basic SVM PASID support')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoiommu/amd: Fix the left value check of cmd buffer
Huang Rui [Mon, 12 Dec 2016 12:28:26 +0000 (07:28 -0500)]
iommu/amd: Fix the left value check of cmd buffer

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 432abf68a79332282329286d190e21fe3ac02a31 upstream.

The generic command buffer entry is 128 bits (16 bytes), so the offset
of tail and head pointer should be 16 bytes aligned and increased with
0x10 per command.

When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE.

So when left space of cmd buf should be able to store only two
command, we should be issued one COMPLETE_WAIT additionally to wait
all older commands completed. Then the left space should be increased
after IOMMU fetching from cmd buf.

So left check value should be left <= 0x20 (two commands).

Signed-off-by: Huang Rui <ray.huang@amd.com>
Fixes: ac0ea6e92b222 ('x86/amd-iommu: Improve handling of full command buffer')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoiommu/amd: Missing error code in amd_iommu_init_device()
Dan Carpenter [Thu, 24 Nov 2016 11:05:44 +0000 (14:05 +0300)]
iommu/amd: Missing error code in amd_iommu_init_device()

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 24c790fbf5d8f54c8c82979db11edea8855b74bf upstream.

We should set "ret" to -EINVAL if iommu_group_get() fails.

Fixes: 55c99a4dc50f ("iommu/amd: Use iommu_attach_group()")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoclk: imx31: fix rewritten input argument of mx31_clocks_init()
Vladimir Zapolskiy [Mon, 26 Sep 2016 00:03:42 +0000 (03:03 +0300)]
clk: imx31: fix rewritten input argument of mx31_clocks_init()

BugLink: http://bugs.launchpad.net/bugs/1655969
commit bae203d58b7dce89664071b3fafe20cedaa3e4f6 upstream.

Function mx31_clocks_init() is called during clock intialization on
legacy boards with reference clock frequency passed as its input
argument, this can be verified by examination of the function
declaration found in arch/arm/mach-imx/common.h and actual function
users which include that header file.

Inside CCF driver the function ignores its input argument, by chance
the used value in the function body is the same as input arguments on
side of all callers.

Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoclk: clk-wm831x: fix a logic error
Pan Bian [Thu, 1 Dec 2016 06:25:44 +0000 (14:25 +0800)]
clk: clk-wm831x: fix a logic error

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 20979202ee6e4c68dab7bcf408787225a656d18e upstream.

Fix bug https://bugzilla.kernel.org/show_bug.cgi?id=188561. Function
wm831x_clkout_is_prepared() returns "true" when it fails to read
CLOCK_CONTROL_1. "true" means the device is already prepared. So
return "true" on the read failure seems improper.

Signed-off-by: Pan Bian <bianpan2016@163.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Fixes: f05259a6ffa4 ("clk: wm831x: Add initial WM831x clock driver")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohwmon: (g762) Fix overflows and crash seen when writing limit attributes
Guenter Roeck [Sun, 11 Dec 2016 21:27:42 +0000 (13:27 -0800)]
hwmon: (g762) Fix overflows and crash seen when writing limit attributes

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 4fccd4a1e8944033bcd7693ea4e8fb478cd2059a upstream.

Fix overflows seen when writing into fan speed limit attributes.
Also fix crash due to division by zero, seen when certain very
large values (such as 2147483648, or 0x80000000) are written
into fan speed limit attributes.

Fixes: 594fbe713bf60 ("Add support for GMT G762/G763 PWM fan controllers")
Cc: Arnaud Ebalard <arno@natisbad.org>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohwmon: (nct7802) Fix overflows seen when writing into limit attributes
Guenter Roeck [Mon, 5 Dec 2016 02:15:25 +0000 (18:15 -0800)]
hwmon: (nct7802) Fix overflows seen when writing into limit attributes

BugLink: http://bugs.launchpad.net/bugs/1655969
commit c0d04e9112ad59d73f23f3b0f6726c5e798dfcbf upstream.

Fix overflows seen when writing voltage and temperature limit attributes.

The value passed to DIV_ROUND_CLOSEST() needs to be clamped, and the
value parameter passed to nct7802_write_fan_min() is an unsigned long.

Also, writing values larger than 2700000 into a fan limit attribute results
in writing 0 into the chip's limit registers. The exact behavior when
writing this value is unspecified. For consistency, report a limit of
1350000 if the chip register reads 0. This may be wrong, and the chip
behavior should be verified with the actual chip, but it is better than
reporting a value of 0 (which, when written, results in writing a value
of 0x1fff into the chip register).

Fixes: 3434f3783580 ("hwmon: Driver for Nuvoton NCT7802Y")
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohwmon: (ds620) Fix overflows seen when writing temperature limits
Guenter Roeck [Sun, 20 Nov 2016 18:37:39 +0000 (10:37 -0800)]
hwmon: (ds620) Fix overflows seen when writing temperature limits

BugLink: http://bugs.launchpad.net/bugs/1655969
commit e36ce99ee0815d7919a7b589bfb66f3de50b6bc7 upstream.

Module test reports:

temp1_max: Suspected overflow: [160000 vs. 0]
temp1_min: Suspected overflow: [160000 vs. 0]

This is seen because the values passed when writing temperature limits
are unbound.

Reviewed-by: Jean Delvare <jdelvare@suse.de>
Fixes: 6099469805c2 ("hwmon: Support for Dallas Semiconductor DS620")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohwmon: (amc6821) sign extension temperature
Jared Bents [Sat, 19 Nov 2016 04:20:38 +0000 (22:20 -0600)]
hwmon: (amc6821) sign extension temperature

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 4538bfbf2d9f1fc48c07ac0cc0ee58716fe7fe96 upstream.

Converts the unsigned temperature values from the i2c read
to be sign extended as defined in the datasheet so that
negative temperatures are properly read.

Fixes: 28e6274d8fa67 ("hwmon: (amc6821) Avoid forward declaration")
Signed-off-by: Jared Bents <jared.bents@rockwellcollins.com>
Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
[groeck: Dropped unnecessary continuation line]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agohwmon: (scpi) Fix module autoload
Javier Martinez Canillas [Mon, 7 Nov 2016 20:31:44 +0000 (17:31 -0300)]
hwmon: (scpi) Fix module autoload

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 13edb767aa609b6efb7c0c2b57fbd72a6ded0eed upstream.

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/hwmon/scpi-hwmon.ko | grep alias
$

After this patch:

$ modinfo drivers/hwmon/scpi-hwmon.ko | grep alias
alias:          of:N*T*Carm,scpi-sensorsC*
alias:          of:N*T*Carm,scpi-sensors

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Fixes: ea98b29a05e9c ("hwmon: Support sensors exported via ARM SCP interface")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agocris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected
Guenter Roeck [Sun, 30 Oct 2016 16:09:18 +0000 (09:09 -0700)]
cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 328cf6927bb72cadefddebbc9a23c793108147a2 upstream.

If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image
object file is empty. With recent versions of binutils, this results
in the following build error.

cris-linux-objcopy: error:
the input file 'arch/cris/boot/rescue/rescue.o' has no sections

This is seen, for example, when trying to build cris:allnoconfig
with recently generated toolchains.

Since it does not make sense to build a flash rescue image if there is
no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Fixes: 66ab3a74c5ce ("CRIS: Merge machine dependent boot/compressed ..")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agoath10k: use the right length of "background"
Nicolas Iooss [Sat, 29 Oct 2016 11:17:37 +0000 (13:17 +0200)]
ath10k: use the right length of "background"

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 31b239824ece321c09bdb8e61e1d14814eaba38b upstream.

The word "background" contains 10 characters so the third argument of
strncmp() need to be 10 in order to match this prefix correctly.

Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Fixes: 855aed1220d2 ("ath10k: add spectral scan feature")
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agostable-fixup: hotplug: fix unused function warning
Arnd Bergmann [Mon, 9 Jan 2017 10:47:50 +0000 (11:47 +0100)]
stable-fixup: hotplug: fix unused function warning

BugLink: http://bugs.launchpad.net/bugs/1655969
[resolves a messed up backport, so no matching upstream commit]

The backport of upstream commit 777c6e0daebb ("hotplug: Make
register and unregister notifier API symmetric") to linux-4.4.y
introduced a harmless warning in 'allnoconfig' builds as spotted by
kernelci.org:

kernel/cpu.c:226:13: warning: 'cpu_notify_nofail' defined but not used [-Wunused-function]

So far, this is the only stable tree that is affected, as linux-4.6 and
higher contain commit 984581728eb4 ("cpu/hotplug: Split out cpu down functions")
that makes the function used in all configurations, while older longterm
releases so far don't seem to have a backport of 777c6e0daebb.

The fix for the warning is trivial: move the unused function back
into the #ifdef section where it was before.

Link: https://kernelci.org/build/id/586fcacb59b514049ef6c3aa/logs/
Fixes: 1c0f4e0ebb79 ("hotplug: Make register and unregister notifier API symmetric") in v4.4.y
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agousb: dwc3: ep0: explicitly call dwc3_ep0_prepare_one_trb()
Felipe Balbi [Tue, 20 Dec 2016 12:08:48 +0000 (14:08 +0200)]
usb: dwc3: ep0: explicitly call dwc3_ep0_prepare_one_trb()

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 19ec31230eb3084431bc2e565fd085f79f564274 upstream.

Let's call dwc3_ep0_prepare_one_trb() explicitly
because there are occasions where we will need more
than one TRB to handle an EP0 transfer.

A follow-up patch will fix one bug related to
multiple-TRB Data Phases when it comes to
mapping/unmapping requests for DMA.

Reported-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7 years agousb: dwc3: ep0: add dwc3_ep0_prepare_one_trb()
Felipe Balbi [Tue, 20 Dec 2016 11:57:32 +0000 (13:57 +0200)]
usb: dwc3: ep0: add dwc3_ep0_prepare_one_trb()

BugLink: http://bugs.launchpad.net/bugs/1655969
commit 7931ec86c1b738e4e90e58c6d95e5f720d45ee56 upstream.

For now this is just a cleanup patch, no functional
changes. We will be using the new function to fix a
bug introduced long ago by commit 0416e494ce7d
("usb: dwc3: ep0: correct cache sync issue in case
of ep0_bounced") and further worsened by commit
c0bd5456a470 ("usb: dwc3: ep0: handle non maxpacket
aligned transfers > 512")

Reported-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>