i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

Without proper alias kernel module is not loaded for rtc-efi driver.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Cc: dann frazier <dannf@dannf.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If adapter->dev.parent == NULL there is a NULL pointer dereference in
acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.

This is present since introduction of this code:
36604751 "i2c: rework kernel config I2C_ACPI" or even
da3c6647 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI"

The adapter->dev.parent == NULL case is valid for the i2c_stub,
so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops.
This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif.

Fix by checking whether it is null before calling ACPI_HANDLE.
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 5d98e61d ("I2C/ACPI: Add i2c ACPI operation region support")
renamed the i2c-core module. This may cause regressions for
distributions, so put the ACPI code back into the core.
Reported-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NLan Tianyu <tianyu.lan@intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In cases where board has below memory DT node

memory{
	device_type = "memory";
	reg = <0x80000000 0x80000000>;
};

Check on the memory range in fdt.c will always fail because it is
comparing MAX_PHYS_ADDR with base + size, in fact it should compare
it with base + size - 1.

This issue was originally noticed on Qualcomm IFC6410 board.
Without this patch kernel shows up noticed unnecessary warnings

[    0.000000] Machine model: Qualcomm APQ8064/IFC6410
[    0.000000] Ignoring memory range 0xffffffff - 0x100000000
[    0.000000] cma: Reserved 64 MiB at ab800000

as a result the size get reduced to 0x7fffffff which looks wrong.

This patch fixes the check involved in generating this warning and
as a result it also fixes the wrong size calculation.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
[grant.likely: adjust new size calculation also]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

We need to add this module to the nomux table to be able to detect the
touchpad.

Cc: stablevger.kernel.org
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Fix code when the operation region callback is for an gpio, which
is not at index 0 and for partial pins in a GPIO definition.
For example:
Name (GMOD, ResourceTemplate ()
{
	//3 Outputs that define the Power mode of the device
	GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12}
	})
}

If opregion callback calls is for:
- Set pin 10, then address = 0 and bit length = 1
- Set pin 11, then address = 1 and bit length = 1
- Set for both pin 11 and pin 12, then address = 1, bit length = 2

This change requires updated ACPICA gpio operation handler code to
send the pin index and bit length.

Fixes: 473ed7be (gpio / ACPI: Add support for ACPI GPIO operation regions)
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 75ec6e55 ACPICA: Update to GPIO region handler interface.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Changes to correct several GPIO issues:

1) The update_rule in a GPIO field definition is now ignored;
a read-modify-write operation is never performed for GPIO fields.
(Internally, this means that the field assembly/disassembly
code is completely bypassed for GPIO.)

2) The Address parameter passed to a GPIO region handler is
now the bit offset of the field from a previous Connection()
operator. Thus, it becomes a "Pin Number Index" into the
Connection() resource descriptor.

3) The bit_width parameter passed to a GPIO region handler is
now the exact bit width of the GPIO field. Thus, it can be
interpreted as "number of pins".

Overall, we can now say that the region handler interface
to GPIO handlers is a raw "bit/pin" addressed interface, not
a byte-addressed interface like the system_memory handler interface.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On some systems (Asus T100 in particular) there are strict ordering
dependencies between LPSS devices with respect to power management
that break if they suspend/resume asynchronously.

In theory it should be possible to follow those dependencies in the
async suspend/resume case too (the ACPI tables tell as that the
dependencies are there), but since we're missing infrastructure
for that at the moment, disable async suspend/resume for all of
the LPSS devices for the time being.

Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2
Fixes: 8ce62f85 (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices)
Signed-off-by: NLi Aubrey <aubrey.li@linux.intel.com>
Signed-off-by: NFu Zhonghui <zhonghui.fu@linux.intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is possibility with misconfigured pins that interrupt occurs instantly
after setting irq_set_chained_handler() in gpiochip_set_chained_irqchip().
Now if handler gets called before irq_set_handler_data() the handler gets
NULL handler data.

Fix this by moving irq_set_handler_data() call before
irq_set_chained_handler() in gpiochip_set_chained_irqchip().

Cc: Stable <stable@vger.kernel.org> # 3.15+
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>

GPIO direction flags are not getting set because
an 'if' statement is the wrong way around.

Cc: Stable <stable@vger.kernel.org> # 3.15+
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If the ccp is built as a built-in module, then ccp-crypto (whether
built as a module or a built-in module) will be able to load and
it will register its crypto algorithms.  If the system does not have
a CCP this will result in -ENODEV being returned whenever a command
is attempted to be queued by the registered crypto algorithms.

Add an API, ccp_present(), that checks for the presence of a CCP
on the system.  The ccp-crypto module can use this to determine if it
should register it's crypto alogorithms.

Cc: stable@vger.kernel.org
Reported-by: NScot Doyle <lkml14@scotdoyle.com>
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Tested-by: NScot Doyle <lkml14@scotdoyle.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

since commit 31964ffe ("tty: serial: msm: Remove direct access to GSBI")'
serial hangs if earlyprintk are enabled.

This hang is noticed only when the GSBI driver is probed and all the
earlyprintks before gsbi probe are seen on the console.
The reason why it hangs is because GSBI driver disables hclk in its
probe function without realizing that the serial IP might be in use by
a bootconsole. As gsbi driver disables the clock in probe the
bootconsole locks up.

Turning off hclk's could be dangerous if there are system components
like earlyprintk using the hclk.

This patch fixes the issue by delegating the clock management to
probe and remove functions in gsbi rather than disabling the clock in probe.

More detailed problem description can be found here:
http://www.spinics.net/lists/linux-arm-msm/msg10589.htmlTested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
dependencies to <asm/efi.h>") as well as the x86 parts of commit
f4f75ad5 ("efi: efistub: Convert into static library").

The road leading to these two reverts is long and winding.

The above two commits were merged during the v3.17 merge window and
turned the common EFI boot stub code into a static library. This
necessitated making some symbols global in the x86 boot stub which
introduced new entries into the early boot GOT.

The problem was that we weren't fixing up the newly created GOT entries
before invoking the EFI boot stub, which sometimes resulted in hangs or
resets. This failure was reported by Maarten on his Macbook pro.

The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
boot code paths"). However, that caused issues for Linus when booting
his Sony Vaio Pro 11. It was subsequently reverted in commit
f3670394.

So that leaves us back with Maarten's Macbook pro not booting.

At this stage in the release cycle the least risky option is to revert
the x86 EFI boot stub to the pre-merge window code structure where we
explicitly #include efi-stub-helper.c instead of linking with the static
library. The arm64 code remains unaffected.

We can take another swing at the x86 parts for v3.18.

Conflicts:
	arch/x86/include/asm/efi.h
Tested-by: NJosh Boyer <jwboyer@fedoraproject.org>
Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

In the brcmf_count_20mhz_channels function we are looping through a list
of channels received from firmware. Since the index of the first channel
is 0 the condition leads to an off by one bug. This is causing us to hit
the WARN_ON_ONCE(1) calls in the brcmu_d11n_decchspec function, which is
how I discovered the bug.

Introduced by:
commit b48d8916
("brcmfmac: rework wiphy structure setup")
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise we may fail to init the second compute ring.
Noticed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Check the correct bit for audio. Seems like a copy-paste error from the
start:

commit 9ed109a7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 24 23:54:52 2014 +0200

    drm/i915: Track has_audio in the pipe config
Reported-by: NMartin Andersen <martin.x.andersen@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756
Cc: stable@vger.kernel.org # 3.16+
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When the audio stream is paused or suspended we stop the sDMA and when it
is unpaused/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears the link configuration when we pause the dma, but
it is not setting it back on start. This will result only one audio buffer
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Add mb() call to resume path to ensure the necessary barrier.
Resume can happen after waking up from suspend for example.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Ring init and cleanup are not balanced because we re-init the rings on
resume without having cleaned them up on suspend. This leads to the
driver leaking the parser's hash tables with a kmemleak signature such
as this:

unreferenced object 0xffff880405960980 (size 32):
  comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s)
  hex dump (first 32 bytes):
    d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00  ..F.............
    98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00  .`(.............
  backtrace:
    [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0
    [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915]
    [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915]
    [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915]
    [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915]
    [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915]
    [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915]
    [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm]
    [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm]
    [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915]
    [<ffffffff81436725>] local_pci_probe+0x45/0xa0
    [<ffffffff81437a69>] pci_device_probe+0xd9/0x130
    [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0
    [<ffffffff815252d3>] __driver_attach+0x93/0xa0
    [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0

This patch extends the current convention of checking whether a
resource is already allocated before allocating it during ring init.
Longer term it might make sense to only init the rings once.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794Tested-by: NKari Suvanto <kari.tj.suvanto@gmail.com>
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

pcie_poll_cmd() take msecs instead of jiffies, so convert timeout to msecs.

Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We should not be manipulaging the DMA_CTRL registers directly by writing
0 to them to disable DMA. This is an operation that needs to be timed to
make sure the DMA engines have been properly stopped since their state
machine stops on a packet boundary, not immediately.

Make sure that tha bcmgenet_fini_dma() calls bcmgenet_dma_teardown() to
ensure a proper DMA engine state. As a result, we need to reorder the
function bodies to resolve the use dependency.

Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The GENET driver supports SKB fragments, and succeeds in transmitting
them properly, but when reclaiming these transmitted fragments, we will
only update the count of free buffer descriptors by 1, even for SKBs
with fragments. This leads to the networking stack thinking it has more
room than the hardware has when pushing new SKBs, and backing off
consequently because we return NETDEV_TX_BUSY.

Fix this by accounting for the SKB nr_frags plus one (itself) and update
ring->free_bds accordingly with that value for each iteration loop in
__bcmgenet_tx_reclaim().

Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Seems to have problems turning the dGPU on/off.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=51381Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Only the acpi backlight seems to work.  Using the
radeon backlight controller causes the backlight to
go off.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=81382Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add a module parameter to disable the radeon GPU backlight
controller to override the automatic detection.  Some
laptops seems to indicate that they use the integrated
controller, but appear to actually use an external
controller.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=81382

v2: fix module parameter description
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This might decrease the chance of IH ring buffer overflows.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use the same format for all ring indices, and fix the calculation of the
post-overflow RPTR.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Otherwise the bit remains set in rdev->ih.rptr, so the wptr can never
match that and we still have an infinite loop.

This fix allows me to successfully recover from an IH ring buffer
overflow.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In one error condition dm9000_parse_dt() returns NULL, however the
return value is checked using IS_ERR() in dm9000_probe(), leading to the
error not being properly propagated if CONFIG_OF is not enabled or the
device tree data is not available. Fix this by also returning an
ERR_PTR() in this case.

Fixes: 0b8bf1ba (net: dm9000: Allow instantiation using device tree)
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ah struct might not have been initialized when
interrupt comes so check for it.
Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is an extra semi-colon so __rtl8169_set_features() is called every
time.

Fixes: 929a031d ('r8169: adjust __rtl8169_set_features')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: Hayes Wang <hayeswang@realtek.com>--
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the hw is in ALDPS mode, the hw may have no response for accessing
the most registers. Therefore, the ALDPS should be disabled before
accessing the hw in rtl_ops.init(), rtl_ops.disable(), rtl_ops.up(),
and rtl_ops.down(). Regardless of rtl_ops.enable(), because the hw
wouldn't enter ALDPS mode when linking on. The hw would enter the
ALDPS mode after several seconds when link down occurs and the ALDPS
is enabled.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To catch future errors sooner.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

TG3 appears to have an issue performing TSO and checksum offloading
correclty when the frame has been vlan encapsulated (non-accelrated).
In these cases, tcp checksum is not correctly updated.

This patch attempts to work around this issue.  After the patch,
802.1ad vlans start working correctly over tg3 devices.

CC: Prashant Sreedharan <prashant@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

tmp103 temperature sensor driver registers with the hwmon framework by calling
hwmon_device_register_with_groups but does not have a .remove method to call
hwmon_device_unregister to unregister from the framework when the device is no
longer needed. Fix this by calling devm_hwmon_device_register_with_groups.
Signed-off-by: NSundar J Dev <sundarjayakumardev@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Since commit 412ca155 ("macvlan: Move broadcasts into a work queue"), the
driver uses tx_queue_len of the master device as the limit of packets enqueuing.
Problem is that virtual drivers have this value set to 0, thus all broadcast
packets were rejected.
Because tx_queue_len was arbitrarily chosen, I replace it with a static limit
of 1000 (also arbitrarily chosen).

CC: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: NThibaut Collet <thibaut.collet@6wind.com>
Suggested-by: NThibaut Collet <thibaut.collet@6wind.com>
Tested-by: NThibaut Collet <thibaut.collet@6wind.com>
Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes the following randconfig build failure:

> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c: In function
> ‘pch_ptp_match’:
> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c:130:2: error:
> implicit declaration of function ‘ptp_classify_raw’
> [-Werror=implicit-function-declaration]
>   if (ptp_classify_raw(skb) == PTP_CLASS_NONE)
>   ^
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.o] Error 1
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

LIBFC depends upon SCSI_FC_ATTRS and select's CRC32C.

The only alternative would be to 'select' CRC32C and all of
SCSI_FC_ATTRS direct and indirect dependencies in the Kconfig section
for every LIBFCOE user which makes little sense.

Subsequently, use 'depends' instead of 'select' for LIBFCOE too.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We had several problems here.  First, a race condition on QP1 mac
handling between mlx4_ib_update_qps and mlx4_ib_modify_qp, which is
fixed by taking the qp mutex in mlx4_ib_update_qps.

Also, qp->pri.smac_port was not updated in mlx4_ib_update_qps.

Last, in __mlx4_ib_modify_qp we did not properly handle the case where
the mac is zero, but port is non-zero.
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>