When FUNCTIONFS_EVENTFD flag is set, __ffs_data_got_descs reads a 32bits,
little-endian value right after the fixed structure header, and passes it
to eventfd_ctx_fdget. Document this.

Also, rephrase a comment to be affirmative about the role of string
descriptor at index 0. Ref: USB 2.0 spec paragraph "9.6.7 String", and
also checked to still be current in USB 3.0 spec paragraph "9.6.9 String".
Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

By convention (according to doc) if function does not provide
get_alt() callback composite framework should assume that it has only
altsetting 0 and should respond with error if host tries to set
other one.

After commit dd4dff8b ("USB: composite: Fix bug: should test
set_alt function pointer before use it")
we started checking set_alt() callback instead of get_alt().
This check is useless as we check if set_alt() is set inside
usb_add_function() and fail if it's NULL.

Let's fix this check and move comment about why we check the get
method instead of set a little bit closer to prevent future false
fixes.

Fixes: dd4dff8b ("USB: composite: Fix bug: should test set_alt function pointer before use it")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NKrzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

usb_get_dr_mode() expects the device-property to be spelled
"dr_mode" not "dr-mode".

Spelling it properly fixes the following warning showing up in dmesg:
[ 8704.500545] dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget

Signed-off-by: Hans de Goede <hdegoede@redhat.com
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we're handling so many transfers at a time
and for some dwc3 revisions LPM events *must* be
enabled, we can fall into a situation where too many
events fire and we start receiving Overflow events.

Let's do what XHCI does and allocate a full page for
the Event Ring, this will avoid any future issues.

Cc: <stable@vger.kernel.org> # v4.9
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

commit 0416e494 ("usb: dwc3: ep0: correct cache
sync issue in case of ep0_bounced") introduced a bug
where we would leak DMA resources which would cause
us to starve the system of them resulting in failing
DMA transfers.

Fix the bug by making sure that we always unmap EP0
requests since those are *always* mapped.

Fixes: 0416e494 ("usb: dwc3: ep0: correct cache
	sync issue in case of ep0_bounced")
Cc: <stable@vger.kernel.org>
Tested-by: NTomasz Medrek <tomaszx.medrek@intel.com>
Reported-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

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.

Cc: <stable@vger.kernel.org>
Reported-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

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 0416e494
("usb: dwc3: ep0: correct cache sync issue in case
of ep0_bounced") and further worsened by commit
c0bd5456 ("usb: dwc3: ep0: handle non maxpacket
aligned transfers > 512")

Cc: <stable@vger.kernel.org>
Reported-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The current default for gadget DMA descriptor results on bcm2835 in a
unnecessary error message:

  Invalid value 1 for param gadget-dma-desc

So fix this by using hw->dma_desc_enable as default value.

Fixes: dec4b556 ("usb: dwc2: gadget: Add descriptor DMA parameter")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The current defaults for DMA results on a non-DMA platform in a unnecessary
error message:

  Invalid value 0 for param gadget-dma

So fix this by using dma_capable as default value.

Fixes: 9962b62f ("usb: dwc2: Deprecate g-use-dma binding")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

According to the Devicetree ePAPR [1] the datatypes u8 and u16 are
not defined. So using device_property_read_u16() would result in
a partial read of a 32-bit big-endian integer which is not intended.
So we better read the complete 32-bit value. This fixes a regression
on bcm2835 where the values for g-rx-fifo-size and g-np-tx-fifo-size
always read as zero:

  Invalid value 0 for param g-rx-fifo-size
  Invalid value 0 for param g-np-tx-fifo-size

[1] - http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf

Fixes: 05ee799f ("usb: dwc2: Move gadget settings into core_params")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Since commit "usb: dwc2: Improve handling of host and device hwparams" the
host mode specific hardware parameter aren't initialized in peripheral mode
from the register settings anymore. So we better do not set them in this
case which avoids the following warnings on bcm2835:

  256 invalid for host_nperio_tx_fifo_size. Check HW configuration.
  512 invalid for host_perio_tx_fifo_size. Check HW configuration.

Fixes: 55e1040e ("usb: dwc2: Improve handling of host and device hwparams")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of
OR together with MII_WRITE.
Signed-off-by: NKweh, Hock Leong <hock.leong.kweh@intel.com>
Acked-By: NJoao Pinto <jpinto@synopsys.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This chip is the same as RTL8168, but its device id is 0x8161.
Signed-off-by: NChun-Hao Lin <hau@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit beb0babf ("korina: disable napi on close and restart")
introduced calls to napi_disable() that were missing before,
unfortunately this leaves a small window during which NAPI has a chance
to run, yet we just freed resources since korina_free_ring() has been
called:

Fix this by disabling NAPI first then freeing resource, and make sure
that we also cancel the restart task before doing the resource freeing.

Fixes: beb0babf ("korina: disable napi on close and restart")
Reported-by: NAlexandros C. Couloumbis <alex@ozo.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The timer type simplifications caused a new gcc warning:

  drivers/base/power/domain.c: In function ‘genpd_runtime_suspend’:
  drivers/base/power/domain.c:562:14: warning: ‘time_start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));

despite the actual use of "time_start" not having changed in any way.
It appears that simply changing the type of ktime_t from a union to a
plain scalar type made gcc check the use.

The variable wasn't actually used uninitialized, but gcc apparently
failed to notice that the conditional around the use was exactly the
same as the conditional around the initialization of that variable.

Add an unnecessary initialization just to shut up the compiler.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ktime_set(S,N) was required for the timespec storage type and is still
useful for situations where a Seconds and Nanoseconds part of a time value
needs to be converted. For anything where the Seconds argument is 0, this
is pointless and can be replaced with a simple assignment.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>

ktime is a union because the initial implementation stored the time in
scalar nanoseconds on 64 bit machine and in a endianess optimized timespec
variant for 32bit machines. The Y2038 cleanup removed the timespec variant
and switched everything to scalar nanoseconds. The union remained, but
become completely pointless.

Get rid of the union and just keep ktime_t as simple typedef of type s64.

The conversion was done with coccinelle and some manual mopping up.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>

There is no point in having an extra type for extra confusion. u64 is
unambiguous.

Conversion was done with the following coccinelle script:

@rem@
@@
-typedef u64 cycle_t;

@fix@
typedef cycle_t;
@@
-cycle_t
+u64
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: John Stultz <john.stultz@linaro.org>

The mpic is either the main interrupt controller or is cascaded behind a
GIC. The mpic is single instance and the modes are mutually exclusive, so
there is no reason to have seperate cpu hotplug states.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/20161221192112.333161745@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Even if both drivers are compiled in only one instance can run on a given
system depending on the available GIC version.

So having seperate hotplug states for them is pointless.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20161221192112.252416267@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Even if both drivers are compiled in only one instance can run on a given
system depending on the available tracer cell.

So having seperate hotplug states for them is pointless.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: http://lkml.kernel.org/r/20161221192112.162765484@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

When the state names got added a script was used to add the extra argument
to the calls. The script basically converted the state constant to a
string, but the cleanup to convert these strings into meaningful ones did
not happen.

Replace all the useless strings with 'subsys/xxx/yyy:state' strings which
are used in all the other places already.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Install the callbacks via the state machine. No functional change.
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: devel@driverdev.osuosl.org
Cc: Andreas Dilger <andreas.dilger@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: rt@linutronix.de
Cc: lustre-devel@lists.lustre.org
Link: http://lkml.kernel.org/r/20161202110027.htzzeervzkoc4muv@linutronix.de
Link: http://lkml.kernel.org/r/20161221192111.922872524@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Install the callbacks via the state machine. No functional change.

This is the minimal fixup so we can remove the hotplug notifier mess
completely.

The real rework of this driver to use work queues is still stuck in
review/testing on the SCSI mailing list.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Chad Dupuis <chad.dupuis@qlogic.com>
Cc: QLogic-Storage-Upstream@qlogic.com
Cc: Johannes Thumshirn <jth@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Link: http://lkml.kernel.org/r/20161221192111.836895753@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Install the callbacks via the state machine. No functional change.

This is the minimal fixup so we can remove the hotplug notifier mess
completely.

The real rework of this driver to use work queues is still stuck in
review/testing on the SCSI mailing list.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Chad Dupuis <chad.dupuis@qlogic.com>
Cc: QLogic-Storage-Upstream@qlogic.com
Cc: Johannes Thumshirn <jth@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Link: http://lkml.kernel.org/r/20161221192111.757309869@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

In case the driver registration fails, the hotplug callback is leaked.

Not fatal, because it's never invoked as there are no instances registered,
but wrong nevertheless.

Fixes: fdc15a36 ("bus/arm-ccn: Convert to hotplug statemachine")
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>

The CPU hotplug code is a trainwreck. It leaks a notifier in case of driver
registration error and the per cpu loop is racy against cpu hotplug. Aside
of that the driver should have been written and merged with the new state
machine interfaces in the first place.

Mop up the mess and Convert it to the hotplug state machine.
Signed-off-by: NThomas Grumpy Gleixner <tglx@linutronix.de>
Cc: Nilesh Javali <nilesh.javali@cavium.com>
Cc: Adheer Chandravanshi <adheer.chandravanshi@qlogic.com>
Cc: Chad Dupuis <chad.dupuis@cavium.com>
Cc: Saurav Kashyap <saurav.kashyap@cavium.com>
Cc: Arun Easi <arun.easi@cavium.com>
Cc: Manish Rangankar <manish.rangankar@cavium.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>

This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>'
  sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.
Requested-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The user prio field is wrong (and overflows) in the XDP forward
flow.
This is a result of a bad value for num_tx_rings_p_up, which should
account all XDP TX rings, as they operate for the same user prio.
Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
Reported-by: NMartin KaFai Lau <kafai@fb.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In an IPvlan setup when master is set in loopback mode e.g.

  ethtool -K eth0 set loopback on

  where eth0 is master device for IPvlan setup.

The failure is caused by the faulty logic that determines if the
packet is from TX-path vs. RX-path by just looking at the mac-
addresses on the packet while processing multicast packets.

In the loopback-mode where this crash was happening, the packets
that are sent out are reflected by the NIC and are processed on
the RX path, but mac-address check tricks into thinking this
packet is from TX path and falsely uses dev_forward_skb() to pass
packets to the slave (virtual) devices.

This patch records the path while queueing packets and eliminates
logic of looking at mac-addresses for the same decision.

------------[ cut here ]------------
kernel BUG at include/linux/skbuff.h:1737!
Call Trace:
 [<ffffffff921fbbc2>] dev_forward_skb+0x92/0xd0
 [<ffffffffc031ac65>] ipvlan_process_multicast+0x395/0x4c0 [ipvlan]
 [<ffffffffc031a9a7>] ? ipvlan_process_multicast+0xd7/0x4c0 [ipvlan]
 [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
 [<ffffffff91cdff09>] process_one_work+0x1a9/0x660
 [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
 [<ffffffff91ce086d>] worker_thread+0x11d/0x360
 [<ffffffff91ce0750>] ? rescuer_thread+0x350/0x350
 [<ffffffff91ce960b>] kthread+0xdb/0xe0
 [<ffffffff91c05c70>] ? _raw_spin_unlock_irq+0x30/0x50
 [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
 [<ffffffff92348b7a>] ret_from_fork+0x9a/0xd0
 [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0

Fixes: ba35f858 ("ipvlan: Defer multicast / broadcast processing to a work-queue")
Signed-off-by: NMahesh Bandewar <maheshb@google.com>
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

1) netif_rx() / dev_forward_skb() should not be called from process
context.

2) ipvlan_count_rx() should be called with preemption disabled.

3) We should check if ipvlan->dev is up before feeding packets
to netif_rx()

4) We need to prevent device from disappearing if some packets
are in the multicast backlog.

5) One kfree_skb() should be a consume_skb() eventually

Fixes: ba35f858 ("ipvlan: Defer multicast / broadcast processing to
a work-queue")
Signed-off-by: NEric Dumazet <edumazet@google.com>
Cc: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The results were previously ignored, anyway.
Signed-off-by: NSteve Wahl <Steve.Wahl@dell.com>
Fixes: e26a5843Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

'request_irq()' and 'free_irq()' should have the same 'dev_id'.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

The offsets for the SZ registers are wrong. Updated.
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Reported-by: NSandeep Mann <sandeep@purestorage.com>
Tested-by: NZachary Ross <zacharyx.ross@intel.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

When the underlying NTB H/W driver advertises more memory windows
than the number of scratchpads available to setup MW's, it is likely
that we may end up filling the remaining memory windows with garbage.
So to avoid that, lets limit the memory windows that transport driver
can setup based on the available scratchpads.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

Due to incorrect limit and translation register values, NTB link was
going down when the memory window was setup. Made appropriate changes
as per spec.

Fix limit register values for BAR1, which was overlapping
with the BAR23 address.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

AMD NTB support hotplug under B2B mode. NTB will trigger link
up/down interrupt event when doing plug add/remove, this patch
implements the two interrupt event to support B2B hotplug function.
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

The Skylake Xeon NTB hardware has made some changes to the register name,
offset, and the way doorbells work. Adding driver support for the new
hardware.
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>

Commit f600b690 ("virtio_net: Add XDP support") leaves the case of
small receive buffer untouched. This will confuse the user who want to
set XDP but use small buffers. Other than forbid XDP in small buffer
mode, let's make it work. XDP then can only work at skb->data since
virtio-net create skbs during refill, this is sub optimal which could
be optimized in the future.

Cc: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now we in fact don't allow XDP for big packets, remove its codes.

Cc: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>