Since commit a6d7514b ("tty: serial: lpuart: add a more accurate baud
rate calculation method") the baud rate is now calculated inside the
lpuart32_serial_setbrg() function, so we no longer need to read the
UARTBAUD register inside lpuart32_set_termios().

The 'bd' variable can be simply removed.

This fixes the following build warning with W=1:

drivers/tty/serial/fsl_lpuart.c: In function 'lpuart32_set_termios':
drivers/tty/serial/fsl_lpuart.c:1652:32: warning: variable 'bd' set but not used [-Wunused-but-set-variable]

Fixes: a6d7514b ("tty: serial: lpuart: add a more accurate baud rate calculation method")
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to avoid code duplication and to be more consistent with the
other error handling paths in this function, we should 'goto errout'.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use bsearch library function instead of duplicated functionality.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make this const as it is only stored in the const field 'ops' of an
uart_port structure. It is not referenced in any other file and therefore
make it static too.

Done using Coccinelle.
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix some minor typo spotted in comments:
- s/wit ha/with a/
- s/doestroyed/destroyed/
Signed-off-by: NAntonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This dirver try to implement the Magic SysRq support[1] for
Amlogic Inc's meson platfo
>From the hardware perspective, the UART IP can't detect the 'BREAK' command
clearly via the status register. Instead, we rely on the combination of
'FRAME_ERR bit && ch == 0', and it works fine.

[1] Documentation/admin-guide/sysrq.rst
Signed-off-by: NYixun Lan <dlan@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 5620a0d1 ("firmware: delete in-kernel firmware") removed the
entire firmware directory.  Unfortunately it thereby also removed the
support for built-in firmware.

This restores the ability to build firmware directly into the kernel by
pruning the original Makefile to the necessary minimum.  The default for
EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/.

Fixes: 5620a0d1 ("firmware: delete in-kernel firmware")
Signed-off-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Acked-by: NGreg K-H <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The driver doesn't support events from address families other than IPv4
and IPv6, so ignore them. Otherwise, we risk queueing a work item before
it's initialized.

This can happen in case a VRF is configured when MROUTE_MULTIPLE_TABLES
is enabled, as the VRF driver will try to add an l3mdev rule for the
IPMR family.

Fixes: 65e65ec1 ("mlxsw: spectrum_router: Don't ignore IPv6 notifications")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Reported-by: NAndreas Rammhold <andreas@rammhold.de>
Reported-by: NFlorian Klink <flokli@flokli.de>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The default receive buffer size was reduced by recent change
to a value which was appropriate for 10G and Windows Server 2016.
But the value is too small for full performance with 40G on Azure.
Increase the default back to maximum supported by host.

Fixes: 8b532797 ("netvsc: allow controlling send/recv buffer size")
Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the network interface is kept running during suspend, the net core
may call net_device_ops.ndo_start_xmit() while the Ethernet device is
still suspended, which may lead to a system crash.

E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
driven by a PM controlled clock.  If the Ethernet registers are accessed
while the clock is not running, the system will crash with an imprecise
external abort.

As this is a race condition with a small time window, it is not so easy
to trigger at will.  Using pm_test may increase your chances:

    # echo 0 > /sys/module/printk/parameters/console_suspend
    # echo platform > /sys/power/pm_test
    # echo mem > /sys/power/state

To fix this, make sure the network interface is quietened during
suspend.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We can enter a deadlock situation because there is no sufficient protection
when ndo_get_stats64() runs in process context to guard against RX or TX NAPI
contexts running in softirq, this can lead to the following lockdep splat and
actual deadlock was experienced as well with an iperf session in the background
and a while loop doing ifconfig + ethtool.

[    5.780350] ================================
[    5.784679] WARNING: inconsistent lock state
[    5.789011] 4.13.0-rc7-02179-g32fae27c725d #70 Not tainted
[    5.794561] --------------------------------
[    5.798890] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[    5.804971] swapper/0/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
[    5.810175]  (&syncp->seq#2){+.?...}, at: [<c0768a28>] bcm_sysport_tx_reclaim+0x30/0x54
[    5.818327] {SOFTIRQ-ON-W} state was registered at:
[    5.823278]   bcm_sysport_get_stats64+0x17c/0x258
[    5.828053]   dev_get_stats+0x38/0xac
[    5.831776]   rtnl_fill_stats+0x30/0x118
[    5.835761]   rtnl_fill_ifinfo+0x538/0xe24
[    5.839921]   rtmsg_ifinfo_build_skb+0x6c/0xd8
[    5.844430]   rtmsg_ifinfo_event.part.5+0x14/0x44
[    5.849201]   rtmsg_ifinfo+0x20/0x28
[    5.852837]   register_netdevice+0x628/0x6b8
[    5.857171]   register_netdev+0x14/0x24
[    5.861051]   bcm_sysport_probe+0x30c/0x438
[    5.865280]   platform_drv_probe+0x50/0xb0
[    5.869418]   driver_probe_device+0x2e8/0x450
[    5.873817]   __driver_attach+0x104/0x120
[    5.877871]   bus_for_each_dev+0x7c/0xc0
[    5.881834]   bus_add_driver+0x1b0/0x270
[    5.885797]   driver_register+0x78/0xf4
[    5.889675]   do_one_initcall+0x54/0x190
[    5.893646]   kernel_init_freeable+0x144/0x1d0
[    5.898135]   kernel_init+0x8/0x110
[    5.901665]   ret_from_fork+0x14/0x2c
[    5.905363] irq event stamp: 24263
[    5.908804] hardirqs last  enabled at (24262): [<c08eecf0>] net_rx_action+0xc4/0x4e4
[    5.916624] hardirqs last disabled at (24263): [<c0a7da00>] _raw_spin_lock_irqsave+0x1c/0x98
[    5.925143] softirqs last  enabled at (24258): [<c022a7fc>] irq_enter+0x84/0x98
[    5.932524] softirqs last disabled at (24259): [<c022a918>] irq_exit+0x108/0x16c
[    5.939985]
[    5.939985] other info that might help us debug this:
[    5.946576]  Possible unsafe locking scenario:
[    5.946576]
[    5.952556]        CPU0
[    5.955031]        ----
[    5.957506]   lock(&syncp->seq#2);
[    5.960955]   <Interrupt>
[    5.963604]     lock(&syncp->seq#2);
[    5.967227]
[    5.967227]  *** DEADLOCK ***
[    5.967227]
[    5.973222] 1 lock held by swapper/0/0:
[    5.977092]  #0:  (&(&ring->lock)->rlock){..-...}, at: [<c0768a18>] bcm_sysport_tx_reclaim+0x20/0x54

So just remove the u64_stats_update_begin()/end() pair in ndo_get_stats64()
since it does not appear to be useful for anything. No inconsistency was
observed with either ifconfig or ethtool, global TX counts equal the sum of
per-queue TX counts on a 32-bit architecture.

Fixes: 10377ba7 ("net: systemport: Support 64bit statistics")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When building an allmodconfig kernel with gcc-4.6, we get a rather
odd warning:

drivers/net/vrf.c: In function ‘vrf_ip6_input_dst’:
drivers/net/vrf.c:964:3: error: initialized field with side-effects overwritten [-Werror]
drivers/net/vrf.c:964:3: error: (near initialization for ‘fl6’) [-Werror]

I have no idea what this warning is even trying to say, but it does
seem like a false positive. Reordering the initialization in to match
the structure definition gets rid of the warning, and might also avoid
whatever gcc thinks is wrong here.

Fixes: 9ff74384 ("net: vrf: Handle ipv6 multicast and link-local addresses")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

call to memset to assign 0 value immediately after allocating
memory with kzalloc is unnecesaary as kzalloc allocates the memory
filled with 0 value.

Semantic patch used to resolve this issue:

@@
expression e,e2; constant c;
statement S;
@@

  e = kzalloc(e2, c);
  if(e == NULL) S
- memset(e, 0, e2);
Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: NHimanshu Jha <himanshujha199640@gmail.com>
Acked-by: NSudarsana Kalluru <sudarsana.kalluru@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Similar to other Gigabyte laptops, the touchpad on P57 requires a
keyboard reset to detect Elantech touchpad correctly.

BugLink: https://bugs.launchpad.net/bugs/1594214Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 40f11adc.

Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon,
gen4:

  iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
  iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
  iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
  iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
  iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
  ...
  iwlwifi 0000:04:00.0: Failed to load firmware chunk!
  iwlwifi 0000:04:00.0: Could not load the [0] uCode section
  iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
  iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110

He bisected it to 40f11adc ("PCI: Avoid race while enabling upstream
bridges").  Revert that commit to fix the regression.

Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6574@kernel.dk
Fixes: 40f11adc ("PCI: Avoid race while enabling upstream bridges")
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Srinath Mannam <srinath.mannam@broadcom.com>
CC: Jens Axboe <axboe@kernel.dk>
CC: Luca Coelho <luca@coelho.fi>
CC: Johannes Berg <johannes@sipsolutions.net>
CC: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

tnapi is being initialized and then immediately updated and
hence the initialiation is redundant.  Clean up the warning
by moving the declaration and initialization to the inside
of the for-loop.

Cleans up clang scan-build warning:
warning: Value stored to 'tnapi' during its initialization is never read
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds initial support for the STM32F7 I2C controller.
Signed-off-by: NM'boumba Cedric Madianga <cedric.madianga@gmail.com>
Signed-off-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch uses a more generic definition of speed enum for i2c-stm32f4
driver.
Signed-off-by: NM'boumba Cedric Madianga <cedric.madianga@gmail.com>
Signed-off-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com>
Reviewed-by: NLudovic BARRE <ludovic.barre@st.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

... and __initconst if applicable.

Based on similar work for an older kernel in the Grsecurity patch.

[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJean Delvare <jdelvare@suse.de>

GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived
and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
primary motivation was to allow users to tell that an allocation is
short lived and so the allocator can try to place such allocations close
together and prevent long term fragmentation.  As much as this sounds
like a reasonable semantic it becomes much less clear when to use the
highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
context holding that memory sleep? Can it take locks? It seems there is
no good answer for those questions.

The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
__GFP_RECLAIMABLE which in itself is tricky because basically none of
the existing caller provide a way to reclaim the allocated memory.  So
this is rather misleading and hard to evaluate for any benefits.

I have checked some random users and none of them has added the flag
with a specific justification.  I suspect most of them just copied from
other existing users and others just thought it might be a good idea to
use without any measuring.  This suggests that GFP_TEMPORARY just
motivates for cargo cult usage without any reasoning.

I believe that our gfp flags are quite complex already and especially
those with highlevel semantic should be clearly defined to prevent from
confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
replace all existing users to simply use GFP_KERNEL.  Please note that
SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
so they will be placed properly for memory fragmentation prevention.

I can see reasons we might want some gfp flag to reflect shorterm
allocations but I propose starting from a clear semantic definition and
only then add users with proper justification.

This was been brought up before LSF this year by Matthew [1] and it
turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
seems to be a heuristic without any measured advantage for most (if not
all) its current users.  The follow up discussion has revealed that
opinions on what might be temporary allocation differ a lot between
developers.  So rather than trying to tweak existing users into a
semantic which they haven't expected I propose to simply remove the flag
and start from scratch if we really need a semantic for short term
allocations.

[1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org

[akpm@linux-foundation.org: fix typo]
[akpm@linux-foundation.org: coding-style fixes]
[sfr@canb.auug.org.au: drm/i915: fix up]
  Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NMel Gorman <mgorman@suse.de>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Neil Brown <neilb@suse.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gcc-7 points out that a negative port_num value would overflow the
string buffer:

  drivers/infiniband/hw/mlx4/sysfs.c: In function 'mlx4_ib_device_register_sysfs':
  drivers/infiniband/hw/mlx4/sysfs.c:251:16: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
  drivers/infiniband/hw/mlx4/sysfs.c:251:2: note: 'sprintf' output between 2 and 11 bytes into a destination of size 10
  drivers/infiniband/hw/mlx4/sysfs.c:303:17: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
  drivers/infiniband/hw/mlx4/sysfs.c:303:3: note: 'sprintf' output between 2 and 11 bytes into a destination of size 10

While we should be able to assume that port_num is positive here, making
the buffer one byte longer has no downsides and avoids the warning.

Fixes: c1e7e466 ("IB/mlx4: Add iov directory in sysfs under the ib device")
Link: http://lkml.kernel.org/r/20170714120720.906842-23-arnd@arndb.deSigned-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gcc-4.4.4 has issues with initialization of anonymous unions:

  drivers/media/cec/cec-adap.c: In function 'cec_queue_msg_fh':
  drivers/media/cec/cec-adap.c:184: error: unknown field 'lost_msgs' specified in initializer

work around this.

Fixes: 6b2bbb08 ("media: cec: rework the cec event handling")
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add driver support for the Altera I2C Controller. The I2C
controller is soft IP for use in FPGAs.
Signed-off-by: NThor Thayer <thor.thayer@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The control process (NSP) may take some time to complete its
initialization.  This is not a problem on most servers, but
on very fast-booting machines it may not be ready for operation
when driver probes the device.  There is also a version of the
flash in the wild where NSP tries to train the links as part
of init.  To wait for NSP initialization we should make sure
its resource has already been added to the resource table.
NSP adds itself there as last step of init.
Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Board state informs us which low-level initialization stages the card
has completed.  We should wait for the card to be fully initialized
before trying to communicate with it, not only before we configure
passing traffic.
Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Previously we did not check the flow dissector against a list of allowed
and supported flow key dissectors. This patch introduces such a list and
correctly rejects unsupported flow keys.

Fixes: 43f84b72 ("nfp: add metadata to each flow offload")
Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: NSimon Horman <simon.horman@netronome.com>
Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Trivial fix to spelling mistake in ubi_err error message
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

In build.c, the following pr_err calls should be terminated with
a new-line to avoid other messages being concatenated onto the end.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

In ubi_attach_mtd_dev() the pr_err() calls should have their
messgaes terminated with a new-line to avoid other messages
being concatenated onto the end.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

The ubi_init() function has a few error paths that use the
pr_err() to output errors. These should have new lines on
them as pr_err() does not automatically do this.

This fixes issues where if multiple mtd fail to bind to
ubi the console output starts wrapping around.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NRichard Weinberger <richard@nod.at>

IPv6 TSO requests with extension hdrs are a problem to the
Lancer and BEx chips. Workaround is to disable TSO6 feature
for such packets.

Also in Lancer chips, MSS less than 256 was resulting in TX stall.
Fix this by disabling GSO when MSS less than 256.
Signed-off-by: NSuresh Reddy <suresh.reddy@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A randconfig build caused a compile failure:

drivers/net/ethernet/nuvoton/w90p910_ether.c: In function 'w90p910_ether_close':
drivers/net/ethernet/nuvoton/w90p910_ether.c:580:2: error: implicit declaration of function 'free_irq'; did you mean 'free_uid'? [-Werror=implicit-function-declaration]

Adding the correct include fixes the problem.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 8b426dc5 ("bonding: remove hardcoded value") changed the
default value for tlb_dynamic_lb which lead to either broken ALB mode
(since tlb_dynamic_lb can be changed only in TLB) or setting TLB mode
with tlb_dynamic_lb equal to 0.
The first issue was recently fixed by setting tlb_dynamic_lb to 1 always
when switching to ALB mode, but the default value is still wrong and
we'll enter TLB mode with tlb_dynamic_lb equal to 0 if the mode is
changed via netlink or sysfs. In order to restore the previous behaviour
and default value simply remove the mode check around the default param
initialization for tlb_dynamic_lb which will always set it to 1 as
before.

Fixes: 8b426dc5 ("bonding: remove hardcoded value")
Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: NMahesh Bandewar <maheshb@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When removing the offloading of mirred actions under
matchall classifiers, mlxsw would find the destination port
associated with the offloaded action and utilize it for undoing
the configuration.

Depending on the order by which ports are removed, it's possible that
the destination port would get removed before the source port.
In such a scenario, when actions would be flushed for the source port
mlxsw would perform an illegal dereference as the destination port is
no longer listed.

Since the only item necessary for undoing the configuration on the
destination side is the port-id and that in turn is already maintained
by mlxsw on the source-port, simply stop trying to access the
destination port and use the port-id directly instead.

Fixes: 763b4b70 ("mlxsw: spectrum: Add support in matchall mirror TC offloading")
Signed-off-by: NYuval Mintz <yuvalm@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Configure pause time to 0xffff when tx flow control enabled

Set pause time to 0xffff in the pause frame to indicate the
partner to stop sending the packets. When RX buffer frees up,
the device sends pause frame with pause time zero for partner to
resume transmission.

Fixes: 2f7ca802 ("Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
Signed-off-by: NNisar Sayed <Nisar.Sayed@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 10e709cb.

The patch doesn't work at all:
1. The CS can still be blocked because of amdgpu_ctx_add_fence().
2. The order of submission isn't correct any more.
3. We could end up using freed up memory because we now drop the
   ctx reference to early.

This needs to be fixed cleanly by doing the context handling after the BO
handling, but this is a larger task just avoid the obvious crashes for now.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Monk Liu monk.liu@amd.com
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We should only see devices with interrupt endpoints. Ignore any other
endpoints that we find, so we don't send try to send them interrupt URBs
and trigger a WARN down in the USB stack.
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org> # c01b5e74 Input: xpad - don't depend on endpoint order
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The touchpad in the Asus laptop models X505BA/BP and X542BA/BP is
unresponsive after suspend/resume. The following error appears during
resume:

  i2c_hid i2c-ELAN1300:00: failed to reset device.

The problem here is that i2c_hid does not notice the interrupt being
generated at this point, because the GPIO is no longer configured
for interrupts.

Fix this by saving pinctrl-amd pin registers during suspend and
restoring them at resume time.

Based on code from pinctrl-intel.

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since commit dc749a09 ("gpiolib: allow gpio irqchip to map irqs
dynamically"), the irqs for gpio are not statically allocated during in
gpiochip_irqchip_add.

This driver was based on this assumption for initializing the mask
associated to each interrupt this led to a NULL pointer crash in the
kernel:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
Mem abort info:
  Exception class = DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
Data abort info:
  ISV = 0, ISS = 0x00000068
  CM = 0, WnR = 1
[0000000000000000] user address but active_mm is swapper
Internal error: Oops: 96000044 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-06657-g3b9f8ed2 #576
Hardware name: Marvell Armada 3720 Development Board DB-88F3720-DDR3 (DT)
task: ffff80001d908000 task.stack: ffff000008068000
PC is at armada_37xx_pinctrl_probe+0x5f8/0x670
LR is at armada_37xx_pinctrl_probe+0x5e8/0x670
pc : [<ffff000008e25cdc>] lr : [<ffff000008e25ccc>] pstate: 60000045
sp : ffff00000806bb80
x29: ffff00000806bb80 x28: 0000000000000024
x27: 000000000000000c x26: 0000000000000001
x25: ffff80001efee760 x24: 0000000000000000
x23: ffff80001db6f570 x22: ffff80001db6f438
x21: 0000000000000000 x20: ffff80001d9f4810
x19: ffff80001db6f418 x18: 0000000000000000
x17: 0000000000000001 x16: 0000000000000019
x15: ffffffffffffffff x14: 0140000000000000
x13: 0000000000000000 x12: 0000000000000030
x11: 0101010101010101 x10: 0000000000000040
x9 : ffff000009923580 x8 : ffff80001d400248
x7 : ffff80001d400270 x6 : 0000000000000000
x5 : ffff80001d400248 x4 : ffff80001d400270
x3 : 0000000000000000 x2 : 0000000000000001
x1 : 0000000000000001 x0 : 0000000000000000
Process swapper/0 (pid: 1, stack limit = 0xffff000008068000)
Call trace:
Exception stack(0xffff00000806ba40 to 0xffff00000806bb80)
ba40: 0000000000000000 0000000000000001 0000000000000001 0000000000000000
ba60: ffff80001d400270 ffff80001d400248 0000000000000000 ffff80001d400270
ba80: ffff80001d400248 ffff000009923580 0000000000000040 0101010101010101
baa0: 0000000000000030 0000000000000000 0140000000000000 ffffffffffffffff
bac0: 0000000000000019 0000000000000001 0000000000000000 ffff80001db6f418
bae0: ffff80001d9f4810 0000000000000000 ffff80001db6f438 ffff80001db6f570
bb00: 0000000000000000 ffff80001efee760 0000000000000001 000000000000000c
bb20: 0000000000000024 ffff00000806bb80 ffff000008e25ccc ffff00000806bb80
bb40: ffff000008e25cdc 0000000060000045 ffff00000806bb60 ffff0000081189b8
bb60: ffffffffffffffff ffff00000811cf1c ffff00000806bb80 ffff000008e25cdc
[<ffff000008e25cdc>] armada_37xx_pinctrl_probe+0x5f8/0x670
[<ffff00000859d8c8>] platform_drv_probe+0x58/0xb8
[<ffff00000859bb44>] driver_probe_device+0x22c/0x2d8
[<ffff00000859bcac>] __driver_attach+0xbc/0xc0
[<ffff000008599c84>] bus_for_each_dev+0x4c/0x98
[<ffff00000859b440>] driver_attach+0x20/0x28
[<ffff00000859af90>] bus_add_driver+0x1b8/0x228
[<ffff00000859c648>] driver_register+0x60/0xf8
[<ffff00000859df64>] __platform_driver_probe+0x74/0x130
[<ffff000008e256dc>] armada_37xx_pinctrl_driver_init+0x20/0x28
[<ffff000008083980>] do_one_initcall+0x38/0x128
[<ffff000008e00cf4>] kernel_init_freeable+0x188/0x22c
[<ffff0000089b56e8>] kernel_init+0x10/0x100
[<ffff000008084bb0>] ret_from_fork+0x10/0x18
Code: f9403fa2 12001341 1100075a 9ac12041 (b9000001)
---[ end trace 8b0f4e05e1603208 ]---

This patch moves the initialization of the mask field in the irq_startup
function. However some callbacks such as irq_set_type and irq_set_wake
could be called before irq_startup. For those functions the mask is
computed at each call which is not a issue as these functions are not
located in a hot path but are used sporadically for configuration.

Fixes: dc749a09 ("gpiolib: allow gpio irqchip to map irqs
dynamically")
Cc: <stable@vger.kernel.org>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>