The arch_timer_evtstrm_enable hooks in arm and arm64 are substantially
similar, the only difference being a CONFIG_COMPAT-conditional section
which is relevant only for arm64.  Copy the arm64 version to the
driver, removing the arch-specific hooks.
Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NWill Deacon <will.deacon@arm.com>

The only difference between arm and arm64's implementations of
arch_counter_set_user_access is that 32-bit ARM does not enable user
access to the virtual counter.  We want to enable this access for the
32-bit ARM VDSO, so copy the arm64 version to the driver itself, and
remove the arch-specific implementations.
Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NWill Deacon <will.deacon@arm.com>

The arm and arm64 VDSOs need CP15 access to the architected counter.
If this is unavailable (which is allowed by ARM v7), indicate this by
changing the clocksource name to "arch_mem_counter" before registering
the clocksource.

Suggested by Stephen Boyd.
Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NWill Deacon <will.deacon@arm.com>

According to HW spec, we have to disable the counter before setting
it, if we don't this, in pressure test, sometimes the timer might
not generate interrupt any more.

And this patch also fixes a typo for register set by changing 0x7
to 0x3. 0x7 is loop mode in HW, but here we are using oneshot 0x3.
Signed-off-by: NHao Liu <Hao.Liu@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

New TTCs support 32bit mode. Older versions support
only 16bit modes. Keep 16bit mode as default
and 32bit optional.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

The clock is not unprepared in case of the request IRQ fails.

Also update to request_irq.
Signed-off-by: NGaël PORTAY <gael.portay@gmail.com>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

Currently we wait until both cp15 and mem timers are probed if we
have both timer device nodes present in the device tree without
checking if the device is actually available. If one of the timer
device node present is disabled, the system locks up on the boot
as no timer gets registered.

This patch adds the check for the availability of the timer device
so that unavailable timers are discarded correctly. It also adds
the missing of_node_put.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

In order to avoid waking up the system in a low power mode, the
clocksource should not generate interrupts anymore. Disable the PIT
timer interrupt when changing into the CLOCK_EVT_MODE_SHUTDOWN mode.

[dlezcano] : remove superfluous empty line
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NBill Pringlemeir <bpringlemeir@nbsps.com>

Meson6 SoCs are equipped with 5 32-bit timers, called TIMER_A, TIMER_B,
TIMER_C, TIMER_D and TIMER_E.

The driver is providing clocksource support for the 32-bit counter using
TIMER_E. Clockevents are also supported using TIMER_A.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NCarlo Caione <carlo@caione.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: NMatthias Brugger <matthias.bgg@gmail.com>

A message warning a user about wrong vc value was printing
out port instead.
Reported-by: NDrew Richardson <drew.richardson@arm.com>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Test for definedness of the macro which is actually defined (the
change is hard to see: it is s/SSS/SSA/).
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Nothing defines _ASM_GENERIC_INT_L64_H, it is a weird way to check for
64 bit longs, and u64 should be printed using %llx anyway.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Hidden away in the last 8 bytes of the buffer_list page is a solitary
statistic. It needs to be byte swapped or else ethtool -S will
produce numbers that terrify the user.

Since we do this in multiple places, create a helper function with a
comment explaining what is going on.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A NULL pointer dereference is possible for the argument ring->buf_pool
which is passed to xgene_enet_free_desc_ring(), as ring could be NULL.

And now since NULL pointers are being checked for before the calls to
xgene_enet_free_desc_ring(), might as well take advantage of them and
not call the function if the argument would be NULL.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NIyappan Subramanian <isubramanian@apm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current kernel hang on i.MX6SX with rootfs mount from MMC.
The root cause is that ptp uses a periodic timer to access enet register
even if ipg clock is disabled.

FEC ptp driver start one period timer to read 1588 counter register in the
ptp init function that is called after FEC driver is probed.

To save power, after FEC probe finish, FEC driver disable all clocks including
ipg clock that is needed for register access.

i.MX5x, i.MX6q/dl/sl FEC register access don't cause system hang when ipg clock
is disabled, just return zero value. But for i.MX6sx SOC, it cause system hang.

To avoid the issue, we need to check ptp clock status before ptp timer count access.
Signed-off-by: NFugang Duan <B38611@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

spin_is_locked() always returns false for uniprocessor configurations
in several architectures, so do not use WARN_ON with it.
Use lockdep_assert_held() instead to also reduce overhead in
non-debug kernels.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Description of problem:
The NIC card is not reporting back to the driver the transmitted skbs,
so they get stuck in the TX ring causing issues with reference
counters in other kernel components.

Developed a new Automatic Egress Queue Update firmware facility to slowly tick
through Egress Queues and send back any outstanding CIDX Updates which are
laying around.

Based on original work by Casey Leedom <leedom@chelsio.com>
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is a possible race condition when we unregister the PCI Driver and then
flush/destroy the global "workq". This could lead to situations where there
are tasks on the Work Queue with references to now deleted adapter data
structures. Instead, have per-adapter Work Queues which were instantiated and
torn down in init_one() and remove_one(), respectively.

v2: Remove unnecessary call to flush_workqueue() before destroy_workqueue()
Signed-off-by: NAnish Bhatt <anish@chelsio.com>
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently the sh-intc driver is compiled on all SuperH and
non-multiplatform SH-Mobile platforms, while it's only used on a limited
number of platforms:
  - SuperH: SH2(A), SH3(A), SH4(A)(L) (all but SH5)
  - ARM: sh7372, sh73a0

Drop the "default y" on SH_INTC, make all CPU platforms that use it
select it, and protect all sub-options by "if SH_INTC" to fix this.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NMagnus Damm <damm+renesas@opensource.se>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Commit 91ebb929 ("bnx2x: Add support for Multi-Function UNDI") [which was
later supposedly fixed by de682941 ("bnx2x: Fix UNDI driver unload")]
introduced a bug in which in some [yet-to-be-determined] scenarios the
alternative flushing mechanism which was to guarantee the Rx buffers are
empty before resetting them during device probe will fail.
If this happens, when device will be loaded once more a fatal attention will
occur; Since this most likely happens in boot from SAN scenarios, the machine
will fail to load.

Notice this may occur not only in the 'Multi-Function' scenario but in the
regular scenario as well, i.e., this introduced a regression in the driver's
ability to perform boot from SAN.

The patch reverts the mechanism and applies the old scheme to multi-function
devices as well as to single-function devices.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Firmware binary file is in little endian. On big-endian architecture, while
writing this binary FW file to adapters memory, writel() swaps the data resulting into
corruption of FW image. So, swap the data before writing into adapters memory.
Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Firmware dump template header is read from adapter using
readl() which swaps the data. So, adjust structure
element on the boundary of 32bit dword.
Signed-off-by: NRajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Application expects flash data in little endian, but driver reads/writes
flash data using readl()/writel() APIs which swaps data on big endian machine.
So, swap the data after reading from and before writing to flash memory.
Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, macvlan code restricts multicast and unicast
filter setting only to passthru devices.  As a result,
if a guest using macvtap wants to receive multicast
traffic, it has to set IFF_ALLMULTI or IFF_PROMISC.

This patch makes it possible to use the fdb interface
to add multicast addresses to the filter thus allowing
a guest to receive only targeted multicast traffic.

CC: John Fastabend <john.r.fastabend@intel.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.

Cc: stable@vger.kernel.org
Reported-by: NBen Hawkes <hawkes@google.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

device_index is a char type and the size of paired_dj_deivces is 7
elements, therefore proper bounds checking has to be applied to
device_index before it is used.

We are currently performing the bounds checking in
logi_dj_recv_add_djhid_device(), which is too late, as malicious device
could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the
problem in one of the report forwarding functions called from
logi_dj_raw_event().

Fix this by performing the check at the earliest possible ocasion in
logi_dj_raw_event().

Cc: stable@vger.kernel.org
Reported-by: NBen Hawkes <hawkes@google.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request()
is wrong; the current check doesn't make any sense -- the report allocated
by HID core in hid_hw_raw_request() can be much larger than
DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't
handle this properly at all.

Fix the check by actually trimming down the report size properly if it is
too large.

Cc: stable@vger.kernel.org
Reported-by: NBen Hawkes <hawkes@google.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: NJerome Blin <jerome.blin@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Once the CAN-bus is open and a packet is sent, the controller switches
into the PASSIVE state. Once the BUS is closed again it goes the back
err-warning. The TX error counter goes 0 -> 0x80 -> 0x7f.
This patch makes sure that the user learns about this state chang
(CAN_STATE_ERROR_WARNING => CAN_STATE_ERROR_PASSIVE)
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NMatthias Klein <matthias.klein@optimeas.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

In case we don't have FLEXCAN_HAS_BROKEN_ERR_STATE and the user set
CAN_CTRLMODE_BERR_REPORTING once it can not be unset again until reboot.
So in case neither hardware nor user wants the error interrupt disable
the bit.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

devm_ioremap() returns NULL on error, not an ERR_PTR().

Fixes: 33cf7565 ('can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource()')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: linux-stable <stable@vger.kernel.org> # >= v3.11
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

When sja1000 is not compiled as module the SJA1000 chip is only
initialized during device registration on kernel boot. Should the chip
get a hardware reset there is no way to reinitialize it without re-
booting the Linux kernel.

This patch adds a check in sja1000_start if the chip is initialized, if
not we initialize it.
Signed-off-by: NMirza Krak <mirza.krak@hostmobility.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This reverts commit bdc3ae72.
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

The latest kernel fails to boot qemu arm images when using scsi
for disk access. Boot gets stuck after the following messages.

brd: module loaded
sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi host0: sym-2.2.3

Bisect points to commit 71e75c97 ("scsi: convert device_busy to
atomic_t"). Code inspection shows the following suspicious change
in scsi_request_fn.

out_delay:
-       if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
+       if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
		blk_delay_queue(q, SCSI_QUEUE_DELAY);
	}

'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
meaning the logic was reversed. Changing this expression to
'!atomic_read(&sdev->device_busy)' fixes the problem.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Acked-by: NJens Axboe <axboe@fb.com>
Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com>
Reviewed-by: NWebb Scales <webbnh@hp.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 1490434f.

Several people have reported regressions with this patch on kabini.

Need to initialize the mask to 0 on init, otherwise it
keeps increasing.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=82581

v2: also fix cu count
v3: split count fix into separate patch
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org

This fixes the CU count reported to userspace for
OpenCL.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=82581Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org

Now that the PFP and ME synchronization is fixed, we
can enable this again reliably.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>

Fixes lockups due to CP read GPUVM faults when running piglit on Cape
Verde.

v2 (chk): apply the fix to R600+ as well, on CIK only the GFX CP has
	  a PFP, add more comments to R600 code, enable flushing again
v3: (agd5f): only apply to 7xx+.  r6xx does not have the packet.
v4: (agd5f): split flush change into a separate patch, fix formatting
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>