The usbip_protocol.txt, a document which describes usbip's
inner workings is currently located in the projects source
directory (drivers/usb/usbip/...). This patch moves it to
Documentation/usb.

This discussion was brought up by Guy Harris [0] during the
review of the USBIP dissector I wrote. For anyone interested:
support is available with the latest wireshark master/dev tree.
Simply select a packet from the usbip's tcp-stream you are
intrested on and select the USBIP as the protocol in the
"Decode As" dialog box [1].
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>

[0] <https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12127#c2>
[1] <https://www.wireshark.org/docs/wsug_html_chunked/ChCustProtocolDissectionSection.html#ChAdvDecodeAs>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_autopm_put_interface() should be called regardless of what
idmouse_create_image() returns.
Signed-off-by: NJunjie Mao <junjie.mao@enight.me>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A typo of j for i led to a logic bug. To rule out future
confusion, the variable names are made meaningful.
Signed-off-by: NOliver Neukum <ONeukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure (of/i2c/platform)_device_id tables are NULL terminated

Generated by: scripts/coccinelle/misc/of_table.cocci
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add fallback compatibility strings for R-Car Gen2 and Gen3.

This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Avoid printing an error if adding the device failes with return
value EPROBE_DEFFER. This may happen e.g. due to missing GPIO for
the vbus-supply regulator.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

This reverts commit e765bfb7.

In the most of cases, we only use one transaction per frame and the
frame rate may be high, If the platforms want to support multiple
transactions but less frame rate cases like [1] and [2], it can set
"non-zero-ttctrl-ttha" at dts.

[1] http://www.spinics.net/lists/linux-usb/msg123125.html
[2] http://www.spinics.net/lists/linux-usb/msg118679.htmlSigned-off-by: NPeter Chen <peter.chen@nxp.com>

In chipidea IP RTL, there is a very limited design for siTD, the detail
like below:
There is no Max Packet Size at siTD, so it uses one constant for both
Max Packet Size for packet and the packet size for the last transaction
when considering schedule.
If the ttctrl.ttha does not match against Hub Address field in siTD,
this constant is 188 bytes, else this constant is 1023 bytes.

If the ttctrl.ttha is non-zero value, RTL will use 188 as this constant,
so it will lose the data if the packet size is larger than 188 bytes, eg,
if we playback a wav which format is 48khz, 16 bits, 2 channels, the
packet size will be 192bytes, but the controller will only send 188 bytes
for this packet, the noise will be heared using USB audio card.
The use case is single transaction, but higher frame rate.

If the ttctr.ttha is zero value, we can send 1023 bytes within one
transaction, but the controller will not accept the coming tranaction
if it considers the schedule time is less than 1023 bytes. So the
limitation is we can't schedule as many as transactions within frame.
If the total bytes is already 256 bytes for previous transactions within
frame, it can't accept another transaction. The use case is multiple
transactions, but less frame rate.
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

retval is assigned to be -EOVERFLOW but is overwritten later before
it's used, remove this unused value assignment.
Signed-off-by: NLi Jun <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Until now the imx23 uses the imx27 platform flag. But the
imx23 needs the flag CI_HDRC_TURN_VBUS_EARLY_ON, too. So
fix this by adding a separate platform flag.
Suggested-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Commit d07e2259 ("mm: mmap: add new /proc tunable for mmap_base
ASLR") added the ability to choose from a range of values to use for
entropy count in generating the random offset to the mmap_base address.

The maximum value on this range was set to 32 bits for 64-bit x86
systems, but this value could be increased further, requiring more than
the 32 bits of randomness provided by get_random_int(), as is already
possible for arm64.  Add a new function: get_random_long() which more
naturally fits with the mmap usage of get_random_int() but operates
exactly the same as get_random_int().

Also, fix the shifting constant in mmap_rnd() to be an unsigned long so
that values greater than 31 bits generate an appropriate mask without
overflow.  This is especially important on x86, as its shift instruction
uses a 5-bit mask for the shift operand, which meant that any value for
mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base
randomization.

Finally, replace calls to get_random_int() with get_random_long() where
appropriate.

This patch (of 2):

Add get_random_long().
Signed-off-by: NDaniel Cashman <dcashman@android.com>
Acked-by: NKees Cook <keescook@chromium.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Nick Kralevich <nnk@google.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This driver uses PCI glue that is only available on 32-bit ARM.  This used
to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively 32-bit,
but there's a patch in the pipe to make ARCH_MVEBU also available on 64-bit
ARM.

[bhelgaas: changelog; patch is coming but not merged yet]
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.

Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e5.  Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3.  In both cases booting with
"pci=routirq" is a workaround.

I think the problem is that after 991de2e5, we no longer call
pcibios_enable_irq() for upstream bridges.  Prior to 991de2e5, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e5, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.

Revert 991de2e5 to fix these driver regressions.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Reported-and-tested-by: NОлег Мороз <oleg.moroz@mcc.vniiem.ru>
Reported-by: NSunjin Yang <fan4326@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>

This can happen under some annoying circumstances, and is a quick fix
until more substantial changes can be made.

Fixed eDP mode changes on (at least) the Lenovo P50.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

The error cleanup paths aren't quite correct and will crash upon
deferred probe.

Cc: stable@vger.kernel.org # v4.3+
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

CONFIG_ARCH_SHMOBILE is not only enabled for Renesas ARM platforms
(which are DT based and multi-platform), but also on a select set of
Renesas SuperH platforms (SH7722/SH7723/SH7724/SH7343/SH7366). Hence
since commit 0ba58de2 ("drivers: sh: Get rid of
CONFIG_ARCH_SHMOBILE_MULTI"), the legacy clock domain is no longer
installed on these SuperH platforms, and module clocks may not be
enabled when needed, leading to driver failures.

To fix this, add an additional check for CONFIG_OF.

Fixes: 0ba58de2 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI").
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

That should make user space bugs more obvious.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

The event_data passed from pem_fini was not cleared upon initialization.
This caused NULL checks to pass and cast_const_phw_tonga_power_state to
attempt to dereference an invalid pointer. Clear the event_data in
pem_init and pem_fini before calling pem_handle_event.
Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NBradley Pankow <btpankow@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Revert commit b5bd0269 (ACPI, PCI, irq: remove interrupt count
restriction) that introduced a boot regression on some systems
where it caused kmalloc() to be used too early.

Link: http://marc.info/?l=linux-acpi&m=145580159209240&w=2Reported-by: NNalla, Ravikanth <ravikanth.nalla@hpe.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Revert commit 09716869 "ACPI / PCI: Simplify acpi_penalize_isa_irq()"
that depends on commit b5bd0269 (ACPI, PCI, irq: remove interrupt
count restriction) which introduced a regression and needs to be
reverted for this reason.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

A recent bugfix changed pfn_t to always be 64-bit wide, but did not
change the code in pmem.c, which is now broken on 32-bit architectures
as reported by gcc:

In file included from ../drivers/nvdimm/pmem.c:28:0:
drivers/nvdimm/pmem.c: In function 'pmem_alloc':
include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
 #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3))

This changes the intermediate pfn_flags in struct pmem_device to
be 64 bit wide as well, so they can store the flags correctly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: db78c222 ("mm: fix pfn_t vs highmem")
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The original format of these commands from the "NVDIMM DSM Interface
Example" [1] are superseded by the ACPI 6.1 definition of the "NVDIMM Root
Device _DSMs" [2].

[1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
[2]: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf
     "9.20.7 NVDIMM Root Device _DSMs"

Changes include:
1/ New 'restart' fields in ars_status, unfortunately these are
   implemented in the middle of the existing definition so this change
   is not backwards compatible.  The expectation is that shipping
   platforms will only ever support the ACPI 6.1 definition.

2/ New status values for ars_start ('busy') and ars_status ('overflow').

Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Linda Knippers <linda.knippers@hpe.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Commit ac33cdb1 ("usb: musb: Remove ifdefs for musb_host_rx in
musb_host.c part5") introduces a problem setting DMA host mode.

The musb_advance_schedule() is called immediately after receiving an
endpoint RX interrupt without waiting for the DMA transfer to complete.

As a consequence when the dma complete interrupt arrives the in_qh
member of hw_ep is already null an the musb_host_rx() exits on !urb
error case. Fix the done condition that advances the musb schedule.
Signed-off-by: NCristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: NJoshua Henderson <joshua.henderson@microchip.com>
Tested-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

When working in Dual Role Device mode, USB state machine is not kicked,
when host or gadget drivers are loaded. Fix this be explicitly triggering
state detection on client driver load.

Issue is that if the board is booted without micro usb cable and usb
device attached, kernel fails to populate the usb host and device.
The reason for this is that the state machine worker logic only checks
for USB_DR_MODE_PERIPHERAL and USB_DR_MODE_HOST modes to run worker
thread. However if the phy is configured in OTG mode it would fail
to run the state machine, resulting in failure to detect for very
first time.

This patch fixes the issue by removing the explicit checks.

Issue is noticed on Qualcomm Dragon board DB410C.

[srinivas.kandagatla@linaro.org: Added more details to log]
Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

This patch fixes the register offset used for super-speed connection's
max packet size. Without it using the 338x series of devices in enhanced
mode will only allow full or high speed operation to function correctly.
Signed-off-by: NSimon Appleby <simon.appleby@pickeringtest.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even
if it didn't register it earlier due to other failures. This patch fixes
this.
Reported-by: NVegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NVegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Retry gadget probe only if the probe result is -EPROBE_DEFER, not on
every probe error.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

As per the documentation of the devfreq_dev_profile.target callback, set
the freq argument to the new frequency before returning.

This caused endless messages like this after recent changes in the core:

devfreq 6000c800.actmon: Couldn't update frequency transition information.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reported-by: NTyler Baker <tyler.baker@linaro.org>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>

As the code in this file is being executed within irq context in some
cases, we must avoid the clk_get_rate which uses mutex internally.
Switch the code to use clk_hw_get_rate instead which is non-locking.

This fixes an issue where PM runtime will hang the system if enabled
with a serial console before a suspend-resume cycle.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Fixes: a53ad8ef ("clk: ti: Convert to clk_hw based provider APIs")
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

It has been observed that sometimes disabling the dc6 fails
and dc6 state pops back up, brief moment after disabling. This
has to be dmc save/restore timing issue or other bug in the
way dc states are handled.

Try to work around this issue as we don't have firmware fix
yet available. Verify that the value we wrote for the dmc sticks,
and also enforce it by rewriting it, if it didn't.

v2: Zero rereads on rewrite for extra paranoia (Imre)

Testcase: kms_flip/basic-flip-vs-dpms
References: https://bugs.freedesktop.org/show_bug.cgi?id=93768
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 779cb5d3)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The DMC can incorrectly run off and allow DC states on it's own. We
don't know the root-cause for this yet but this patch makes it more
visible.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 832dba88)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NJordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NJordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

I.e., doesn't make sense to change power states or check the
temperature when the asic is powered off.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Looks like a copy paste typo when we added powerplay
support.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Looks like a copy/paste typo.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Noticed-by: NDavid Panariti <David.Panariti@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Spotted-by: NMika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 4d800030)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com
(cherry picked from commit ecb24482)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com
(cherry picked from commit 5b092174)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com
(cherry picked from commit 3f3f42b8)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>