Trace where wil6210_disconnect() is called from.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Provide info for [add|del]_key.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

refactor module parameter debug_fw to act as "fw debug mode",
where driver do nothing but allow card memory access.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

bnx2x's 'disable_tpa=1' module option is not respected properly and TPA
(transparent packet aggregation) remains enabled. Even though the
module option causes LRO to be disabled, TPA is enabled in GRO mode.

Additionally, disabling GRO via ethtool then has no effect. One can
still observe tpa_* statistics increase and large packets being received
in tcpdump.

The bug was an unintended consequence of commit aebf6244 "bnx2x: Be
more forgiving toward SW GRO".

Fix it by following the bp->disable_tpa flag when initializing fp's.
Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fix spelling typo in printk.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mlx4_en_check_rxfh_func() was checking for hardware support before
setting a known RSS hash function, but didn't do any check before
setting unknown RSS hash function. Need to make it fail on such values.
In this occasion, moved the actual setting of the new value from the
check function into mlx4_en_set_rxfh().

Fixes: 947cbb0a ("net/mlx4_en: Support for configurable RSS hash function")
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the new gpiod_get_array and gpiod_put_array functions
(added to mainline in the v4.1 merge window) for obtaining and
disposing of GPIO descriptors.

Cc: David Miller <davem@davemloft.net>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Until now only a single fixed tx rate or nss was
allowed to be set.

The patch attempts to improve this by allowing
most bitrate masks. The limitation is VHT MCS
rates cannot be expressed separately using
existing firmware interfaces and only the
following VHT MCS ranges are supported: none, 0-7,
0-8, and 0-9.

This keeps the old behaviour when requesting
single tx rate or single nss. The new bitrate mask
logic is only applied to other cases that would
return -EINVAL until now.

Depending on firmware revisions some combinations
may crash firmware so use with care, please.

This depends on "ath10k: don't use reassoc flag".
Without it key cache would effectively be
invalidated upon bitrate change leading to
communication being no longer possible.

These work:

  iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3
  iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9
  iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9

These won't work:

  iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
  iw wlan0 set bitrates vht-mcs-5 2:7-9

(note the invalid VHT MCS ranges)
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

When PPP is used over a link which does not guarantee packet ordering,
we might get late MPPE packets. This is a problem because MPPE must be
kept synchronized and the current implementation does not drop them and
rekey 4095 times instead of 0, which is wrong.

In order to prevent rekeying about a whole count space times (~ 4095
times), drop packets which are not within the forward 4096/2 window and
increase sanity error counter.
Signed-off-by: NSylvain Rochet <sylvain.rochet@finsecur.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We are going to need sanity error path a little further, rework to be
able to use the sanity error path anywhere in decompressor.
Signed-off-by: NSylvain Rochet <sylvain.rochet@finsecur.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The bonding modules currently defines four macros with
general names that pollute the global namespace:
DRV_VERSION
DRV_RELDATE
DRV_NAME
DRV_DESCRIPTION

Fixing that by defining a private bonding_priv.h
header files which includes those defines.
Signed-off-by: NMatan Barak <matanb@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for fixed-links in configurations without PHY.
(e.g. connection to a switch, SGMII point to point, SFPs)

Check: Documentation/devicetree/bindings/net/fixed-link.txt.
Signed-off-by: NAndreas Oetken <ennoerlangen@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 43d3ddf8 ("net: pxa168_eth: add device tree support") starts
to use managed resources by adding devm_clk_get() and
devm_ioremap_resource(), but it leaves explicit iounmap() and clock_put()
in pxa168_eth_remove() and in failure handling code of pxa168_eth_probe().
As a result double free can happen.

The patch removes explicit resource deallocation. Also it converts
clk_disable() to clk_disable_unprepare() to make it symmetrical with
clk_prepare_enable().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch resolves false errors from MSGDMA in TX mSGDMA MM to ST
mode, and is a continuation of the patch recently submitted by Andrea
Oetken. The MSGDMA had a logic bug that masked detection of this issue
prior to Quartus 14.1/Build 164. When the MSGDMA logic bug was addressed
in Quartus 14.1/Build 164, the driver problem was exposed.

The problem is corrected by making sure MSGDMA_DESC_CTL_TR_ERR_IRQ is not
set for any of the transmit DMA descriptors, and only used for receive
descriptors.

Fixes: 71cd26e7 altera tse: Error-Bit on tx-avalon-stream always set.
Signed-off-by: NChee Nouk Phoon <cnphoon@altera.com>
Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>a
Cc: Andreas Oetken <ennoerlangen@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The recent commit to only register the EHEA memory hotplug hooks on
adapter probe has a few problems.

Firstly the reference counting is wrong for multiple adapters, in that
the hooks are registered multiple times. Secondly the check in the tear
down path is backward. Finally the error path doesn't decrement the
count.

The multiple registration of the hooks is the biggest problem, as it
leads to oopses when the system is rebooted, and/or errors during memory
hotplug, eg:

  $ ./mem-on-off-test.sh -r 2
  ...
  ehea: memory is going offline
  ehea: LPAR memory changed - re-initializing driver
  ehea: re-initializing driver complete
  ehea: memory is going offline
  ehea: LPAR memory changed - re-initializing driver
  ehea: opcode=26c ret=fffffffffffffffc arg1=8000000003000003 arg2=0 arg3=700000060000d600 arg4=3fded0000 arg5=200 arg6=0 arg7=0
  ehea: register_rpage_mr failed
  ehea: registering mr failed
  ehea: register MR failed - driver inoperable!
  ehea: memory is going offline

Fixes: aa183323 ("ehea: Register memory hotplug, reboot and crash hooks on adapter probe")
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When having permanent EEH error, the PCI device will be removed
from the system. For this case, we shouldn't set pcierr_recovery
to true wrongly, which blocks the driver to release the allocated
interrupts and their handlers. Eventually, we can't disable MSI
or MSIx successfully because of the MSI or MSIx interrupts still
have associated interrupt actions, which is turned into following
stack dump.

Oops: Exception in kernel mode, sig: 5 [#1]
        :
[c0000000003b76a8] .free_msi_irqs+0x80/0x1a0 (unreliable)
[c00000000039f388] .pci_remove_bus_device+0x98/0x110
[c0000000000790f4] .pcibios_remove_pci_devices+0x9c/0x128
[c000000000077b98] .handle_eeh_events+0x2d8/0x4b0
[c0000000000782d0] .eeh_event_handler+0x130/0x1c0
[c000000000022bd4] .kernel_thread+0x54/0x70
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NPrashant Sreedharan <prashant@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The new Atmel MXT driver expects i2c client's address contain the
primary (main address) of the chip, and calculates the expected
bootloader address form the primary address. Unfortunately chrome_laptop
does probe the devices and if touchpad (or touchscreen, or both) comes
up in bootloader mode the i2c device gets instantiated with the
bootloader address which confuses the driver.

To work around this issue let's probe the primary address first. If the
device is not detected at the primary address we'll probe alternative
addresses as "dummy" devices. If any of them are found, destroy the
dummy client and instantiate client with proper name at primary address
still.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

commit a39f46df ("toshiba_acpi: Fix regression caused by backlight extra
check code") causes the backlight to no longer work on the Toshiba Z30,
reverting that commit fixes this but restores the original issue fixed
by that commit.

Looking at the toshiba_acpi backlight code for a fix for this I noticed that
the toshiba code is the only code under platform/x86 which unconditionally
registers a vendor acpi backlight interface, without checking for acpi_video
backlight support first.

This commit adds the necessary checks bringing toshiba_acpi in line with the
other drivers, and fixing the Z30 regression without needing to revert the
commit causing it.

Chances are that there will be some Toshiba models which have a non working
acpi-video implementation while the toshiba vendor backlight interface does
work, this commit adds an empty dmi_id table where such systems can be added,
this is identical to how other drivers handle such systems.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-and-tested-by: NAzael Avalos <coproscefalo@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Some systems using mdio-gpio may use gpio on message based busses, which
require sleeping (e.g. gpio from an I2C I/O expander).

Since this driver does not use IRQ handler, it is safe to use the
_cansleep suffixed gpio accessors.
Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After d75b1ade ("net: less interrupt masking in NAPI") polling
function has to return whole budget when it wants NAPI to call it again.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: Felix Fietkau <nbd@openwrt.org>
Fixes: eb64e292 ("bgmac: leave interrupts disabled as long as there is work to do")
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If NO_DMA=y:

    drivers/built-in.o: In function `img_hash_write_via_dma_stop':
    img-hash.c:(.text+0xa2b822): undefined reference to `dma_unmap_sg'
    drivers/built-in.o: In function `img_hash_xmit_dma':
    img-hash.c:(.text+0xa2b8d8): undefined reference to `dma_map_sg'
    img-hash.c:(.text+0xa2b948): undefined reference to `dma_unmap_sg'

Also move the "depends" section below the "tristate" line while we're at
it.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If the special PRP0001 device ID is present in the given device's list
of ACPI/PNP IDs and the device has a valid "compatible" property in
the _DSD, it should be enumerated using the default mechanism,
unless some scan handlers match the IDs preceding PRP0001 in the
device's list of ACPI/PNP IDs.  In addition to that, no scan handlers
matching the IDs following PRP0001 in that list should be attached
to the device.

To make that happen, define a scan handler that will match PRP0001
and trigger the default enumeration for the matching devices if the
"compatible" property is present for them.

Since that requires the check for platform_id and device->handler
to be removed from acpi_default_enumeration(), move the fallback
invocation of acpi_default_enumeration() to acpi_bus_attach()
(after it's checked if there's a matching ACPI driver for the
device), which is a better place to call it, and do the platform_id
check in there too (device->handler is guaranteed to be unset at
the point where the function is looking for a matching ACPI driver).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>

acpi_scan_is_offline() may be called under the physical_node_lock
lock of the given device object's parent, so prevent lockdep from
complaining about that by annotating that instance with
SINGLE_DEPTH_NESTING.

Fixes: caa73ea1 (ACPI / hotplug / driver core: Handle containers in a special way)
Reported-and-tested-by: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
suspend/resume, so fix this.

This was introduced in

commit ddeea5b0
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon May 5 15:19:56 2014 +0300

    drm/i915: vlv: add runtime PM support

I noticed this only by reading the code. To my knowledge it shouldn't
cause any real problems at the moment, since the power well backing this
register remains on across a runtime s/r. This may change once
system-wide s0ix functionality is enabled in the kernel.

v2:
- resend after a missing git add -u :/

Cc: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.

Add two extra MI_NOOP instructions at the end of each request, but keep
the requests tail pointing before the MI_NOOPs. We may not need to
executed them, and this is why request->tail is sampled before adding
these extra instructions.

If we submit a context to the ELSP which has previously been submitted,
move the tail pointer past the MI_NOOPs. This ensures HEAD!=TAIL.

v2: Move overallocation to gen8_emit_request, and added note about
sampling request->tail in commit message (Chris).

v3: Remove redundant request->tail assignment in __i915_add_request, in
lrc mode this is already set in execlists_context_queue.
Do not add wa implementation details inside gem (Chris).

v4: Apply the wa whenever the req has been resubmitted and update
comment (Chris).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The hardware, according to the specs, is limited to 256 byte transfers,
and current driver has no protections in case users attempt to do larger
transfers. The code will just stomp over status register and mayhem
ensues.

Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on Pixel 1 function properly (it hasn't since commit
9d8dc3e5 "Input: atmel_mxt_ts -
implement T44 message handling" which tries to consume multiple
touchscreen/touchpad reports in a single transaction).

Cc: stable@vger.kernel.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.

Cc: Hyong-Youb Kim <hykim@myri.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: netdev@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If NO_DMA=y:

    drivers/built-in.o: In function `grcan_free_dma_buffers':
    grcan.c:(.text+0x2d7716): undefined reference to `dma_free_coherent'
    drivers/built-in.o: In function `grcan_allocate_dma_buffers':
    grcan.c:(.text+0x2d779c): undefined reference to `dma_alloc_coherent'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If NO_DMA=y:

    drivers/built-in.o: In function `arc_emac_tx_clean':
    emac_main.c:(.text+0x2decde): undefined reference to `dma_unmap_single'
    drivers/built-in.o: In function `arc_emac_rx':
    emac_main.c:(.text+0x2dee1c): undefined reference to `dma_unmap_single'
    emac_main.c:(.text+0x2dee72): undefined reference to `dma_map_single'
    emac_main.c:(.text+0x2dee7e): undefined reference to `dma_mapping_error'
    drivers/built-in.o: In function `arc_emac_probe':
    (.text+0x2df2ee): undefined reference to `dmam_alloc_coherent'
    drivers/built-in.o: In function `arc_emac_open':
    emac_main.c:(.text+0x2df6d8): undefined reference to `dma_map_single'
    emac_main.c:(.text+0x2df6e4): undefined reference to `dma_mapping_error'
    drivers/built-in.o: In function `arc_emac_tx':
    emac_main.c:(.text+0x2df9e4): undefined reference to `dma_map_single'
    emac_main.c:(.text+0x2df9f0): undefined reference to `dma_mapping_error'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If NO_DMA=y:

    drivers/built-in.o: In function `xgbe_probe':
    xgbe-main.c:(.text+0x2def0a): undefined reference to `dma_set_mask'
    xgbe-main.c:(.text+0x2def20): undefined reference to `dma_supported'
    drivers/built-in.o: In function `xgbe_rx_poll':
    xgbe-drv.c:(.text+0x2e0320): undefined reference to `dma_sync_single_for_cpu'
    xgbe-drv.c:(.text+0x2e035e): undefined reference to `dma_sync_single_for_cpu'
    drivers/built-in.o: In function `xgbe_unmap_rdata':
    xgbe-desc.c:(.text+0x2e5fe4): undefined reference to `dma_unmap_page'
    xgbe-desc.c:(.text+0x2e5ffa): undefined reference to `dma_unmap_single'
    xgbe-desc.c:(.text+0x2e604a): undefined reference to `dma_unmap_page'
    xgbe-desc.c:(.text+0x2e6084): undefined reference to `dma_unmap_page'
    drivers/built-in.o: In function `xgbe_alloc_pages':
    xgbe-desc.c:(.text+0x2e6156): undefined reference to `dma_map_page'
    xgbe-desc.c:(.text+0x2e6164): undefined reference to `dma_mapping_error'
    drivers/built-in.o: In function `xgbe_free_ring':
    xgbe-desc.c:(.text+0x2e63d4): undefined reference to `dma_unmap_page'
    xgbe-desc.c:(.text+0x2e640e): undefined reference to `dma_unmap_page'
    xgbe-desc.c:(.text+0x2e644a): undefined reference to `dma_free_coherent'
    drivers/built-in.o: In function `xgbe_init_ring':
    xgbe-desc.c:(.text+0x2e64d4): undefined reference to `dma_alloc_coherent'
    drivers/built-in.o: In function `xgbe_map_tx_skb':
    xgbe-desc.c:(.text+0x2e6628): undefined reference to `dma_map_single'
    xgbe-desc.c:(.text+0x2e6638): undefined reference to `dma_mapping_error'
    xgbe-desc.c:(.text+0x2e66b2): undefined reference to `dma_map_single'
    xgbe-desc.c:(.text+0x2e66c2): undefined reference to `dma_mapping_error'
    xgbe-desc.c:(.text+0x2e6762): undefined reference to `dma_map_page'
    xgbe-desc.c:(.text+0x2e6772): undefined reference to `dma_mapping_error'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The driver uses pinctrl directly and thus should include the appropriate
header. Sort the headers while we are here to have a better view what is
included and what is not.
Reported-by: NPascal Huerst <pascal.huerst@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Those symlinks are created for the mux_dev, so we need to remove it from
there. Currently, it breaks for muxes where the mux_dev is not the device
of the parent adapter like this:

[   78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78()
[   78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0'

Remove confusing comments while we are here.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Fixes: c9449aff
Cc: stable@kernel.org

And sort them to prevent this from happening again.
Reported-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 523c5b89 ("i2c: Remove support for legacy PM") removed the PM
ops from the bus type, which causes the pm operations on the s3c2410
adapter device to fail (-ENOSUPP in rpm_callback). The adapter device
doesn't get bound to a driver and as such can't have its own pm_runtime
callbacks. Previously this was fine as the bus callbacks would have been
used, but now this can cause devices which use PM runtime and are
attached over I2C to fail to resume.

This commit fixes this issue by marking all adapter devices with
pm_runtime_no_callbacks, since they can't have any.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: NBeata Michalska <b.michalska@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Fixes: 523c5b89
Cc: stable@kernel.org

My Pengutronix address is not valid anymore, redirect people to the Pengutronix
kernel team.
Reported-by: NHarald Geyer <harald@ccbib.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NRobert Schwebel <r.schwebel@pengutronix.de>

My Pengutronix address is not valid anymore, redirect people to the Pengutronix
kernel team.
Reported-by: NHarald Geyer <harald@ccbib.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NRobert Schwebel <r.schwebel@pengutronix.de>

master_xfer() method should return number of i2c messages transferred,
but on Rockchip we were usually returning just 1, which caused trouble
with users that actually check number of transferred messages vs.
checking for negative error codes.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

AFAIK the PAPR document which defines the virtual device interface used by
the ibmveth driver doesn't specify a specific maximum MTU.  So, in the
ibmveth driver, the maximum allowed MTU is determined by the maximum
allocated buffer size of 64k (corresponding to one page in the common case)
minus the per-buffer overhead IBMVETH_BUFF_OH (which has value 22 for 14
bytes of ethernet header, plus 8 bytes for an opaque handle).

This suggests a maximum allowable MTU of 65514 bytes, but in fact the
driver only permits a maximum MTU of 65513.  This is because there is a <
instead of an <= in ibmveth_change_mtu(), which only permits an MTU which
is strictly smaller than the buffer size, rather than allowing the buffer
to be completely filled.

This patch fixes the buglet.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For platforms that don't support DT, some early MFD modules can register
lookup tables. Remove the __init annotation so that this works. This is
similar to gpio_add_lookup_table() which allows late additions.

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>