So far drop monitor supported only one alert mode in which a summary of
locations in which packets were recently dropped was sent to user space.
This alert mode is sufficient in order to understand that packets were
dropped, but lacks information to perform a more detailed analysis.
Add a new alert mode in which the dropped packet itself is passed to
user space along with metadata: The drop location (as program counter
and resolved symbol), ingress netdevice and drop timestamp. More
metadata can be added in the future.
To avoid performing expensive operations in the context in which
kfree_skb() is invoked (can be hard IRQ), the dropped skb is cloned and
queued on per-CPU skb drop list. Then, in process context the netlink
message is allocated, prepared and finally sent to user space.
The per-CPU skb drop list is limited to 1000 skbs to prevent exhausting
the system's memory. Subsequent patches will make this limit
configurable and also add a counter that indicates how many skbs were
tail dropped.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The next patch is going to add another alert mode in which the dropped
packet is notified to user space, instead of only a summary of recent
drops.
Abstract the differences between the modes by adding alert mode
operations. The operations are selected based on the currently
configured mode and associated with the probes and the work item just
before tracing starts.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the configure command does not do anything but return an
error. Subsequent patches will enable the command to change various
configuration options such as alert mode and packet truncation.
Similar to other netlink-based configuration channels, make sure only
users with the CAP_NET_ADMIN capability set can execute this command.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The function reset_per_cpu_data() allocates and prepares a new skb for
the summary netlink alert message ('NET_DM_CMD_ALERT'). The new skb is
stored in the per-CPU 'data' variable and the old is returned.
The function is invoked during module initialization and from the
workqueue, before an alert is sent. This means that it is possible to
receive an alert with stale data, if we stopped tracing when the
hysteresis timer ('data->send_timer') was pending.
Instead of invoking the function during module initialization, invoke it
just before we start tracing and ensure we get a fresh skb.
This also allows us to remove the calls to initialize the timer and the
work item from the module initialization path, since both could have
been triggered by the error paths of reset_per_cpu_data().
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The timer and work item are currently initialized once during module
init, but subsequent patches will need to associate different functions
with the work item, based on the configured alert mode.
Allow subsequent patches to make that change by initializing and
de-initializing these objects during tracing enable and disable.
This also guarantees that once the request to disable tracing returns,
no more netlink notifications will be generated.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Subsequent patches will need to enable / disable tracing based on the
configured alerting mode.
Reduce the nesting level and prepare for the introduction of this
functionality by splitting the tracing enable / disable operations into
two different functions.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before we start upon our great GT interrupt refactor, throw out the
cruft! In this case, it is an unloved debugfs showing the current ips
status, a fairly meaningless bunch of numbers that we are not checking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190810090329.6966-1-chris@chris-wilson.co.uk
Convert the remainder of hi8435_probe() to use devres and get rid of
hi8435_remove().
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: Chris Healy <cphealy@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
I need to store address and lvr value for I2C devices without static definition
in DT. This allows secondary master to transmit DEFSLVS command properly.
Main changes between v4 and v5:
- Change in defslvs to use addr and lvr from i2c_dev_desc structure
- Change in CDNS and DW drivers to use addr and lvr from i2c_dev_desc structure
Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Use gpiod_set_value_cansleep() instead of gpiod_set_value() to support
the case when reset pin is connected to a GPIO expander. See ZII VF610
SCU4 AIB for one such example.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Chris Healy <cphealy@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This simplifies and standardizes slot manipulation code
by using for_each_set_bit() library function.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Each iteration of for_each_available_childe_of_node puts the previous
node, but in the case of a return from the middle of the loop, there
is no put, thus causing a memory leak. Add an of_node_put before the
return.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
This patch is removing the buffer allocation at each buffer enable.
We just allocate enough memory in the main structure during probe
to cover maximum size needed (that anyway is pretty small) [16bytes].
Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Pull NVMe fixes from Sagi:
"Few nvme fixes for the next rc round.
- detect capacity changes on the mpath disk from Anthony
- probe/remove fix from Keith
- various fixes to pass blktests from Logan
- deadlock in reset/scan race fix
- nvme-rdma use-after-free fix
- deadlock fix when passthru commands race mpath disk info update"
* 'nvme-5.3-rc' of git://git.infradead.org/nvme:
nvme-pci: Fix async probe remove race
nvme: fix controller removal race with scan work
nvme-rdma: fix possible use-after-free in connect error flow
nvme: fix a possible deadlock when passthru commands sent to a multipath device
nvme-core: Fix extra device_put() call on error path
nvmet-file: fix nvmet_file_flush() always returning an error
nvmet-loop: Flush nvme_delete_wq when removing the port
nvmet: Fix use-after-free bug when a port is removed
nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns
A few minor RISC-V updates for v5.3-rc4:
- Remove __udivdi3() from the 32-bit Linux port, converting the only
upstream user to use do_div(), per Linux policy
- Convert the RISC-V standard clocksource away from per-cpu data structures,
since only one is used by Linux, even on a multi-CPU system
- A set of DT binding updates that remove an obsolete text binding in
favor of a YAML binding, fix a bogus compatible string in the schema
(thus fixing a "make dtbs_check" warning), and clarifies the future
values expected in one of the RISC-V CPU properties
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElRDoIDdEz9/svf2Kx4+xDQu9KksFAl1PO50ACgkQx4+xDQu9
Kks+aA//d2HVbYpsQT4dnK9HHySTEN8COpxAtXEyprqEqFvhGWiXHf/o5DZJS+KA
J0T4tnfajUxNzN+/B+Wvg8QRZyojad1gPQ8WpKGsRjVMtSZJuvo/knW1aVJPFr5S
28AjXyR5XVugvt5mNSNJTrPBeJ/bzNSZOLfat+gCsHBblNipdWwZhOwcM4mi3sQM
9fc8R5Mg0LHwNF0yVoA47WEwWgjXINkOE5ntvgNydiwoTc4noB046gy0ciZF04WS
YZMNRmr3BCL30zGZv6Ewu7xvcRYf84wjhIvPFkuaJHfxBzwAd4gulsytqGCQmFIC
Na7/5HOtzXpsS27hSev+1SGljv81p3rlKIBVxB2E1OH/eDl1U+yhm/AtM0wbXkpD
2UMHmKoSL/oYIXKOXwpWSKTGxNJbF1c56q4lwDVjq/kvg88GhFXQV/cQV1pS2Aao
KkqKl8AfxzoG3KNGKNJD42ztMW+3a3Wp215pGbrVVAwVOD8kFgCiM9RtqH2pTZrA
AjD/wpAaH9glGkCcwPovzOJ1XA9VKLy4nWLowv5zB9To1wbbAuYRj/7pUNm6LTWF
kcU0E6Yza5b2kKvwSzLdZa4W837XQrf3fRKMTTgH+fcjwma+GlLwx+f6Yk8AmTpP
TMSpV9C6M5RKLVqdzNWUT7q4dzTsNPXse5DhhhnMh3cBPHIGlzQ=
=DIhv
-----END PGP SIGNATURE-----
Merge tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V updates from Paul Walmsley:
"A few minor RISC-V updates for v5.3-rc4:
- Remove __udivdi3() from the 32-bit Linux port, converting the only
upstream user to use do_div(), per Linux policy
- Convert the RISC-V standard clocksource away from per-cpu data
structures, since only one is used by Linux, even on a multi-CPU
system
- A set of DT binding updates that remove an obsolete text binding in
favor of a YAML binding, fix a bogus compatible string in the
schema (thus fixing a "make dtbs_check" warning), and clarifies the
future values expected in one of the RISC-V CPU properties"
* tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
dt-bindings: riscv: fix the schema compatible string for the HiFive Unleashed board
dt-bindings: riscv: remove obsolete cpus.txt
RISC-V: Remove udivdi3
riscv: delay: use do_div() instead of __udivdi3()
dt-bindings: Update the riscv,isa string description
RISC-V: Remove per cpu clocksource
Pull x86 fixes from Thomas Gleixner:
"A few fixes for x86:
- Don't reset the carefully adjusted build flags for the purgatory
and remove the unwanted flags instead. The 'reset all' approach led
to build fails under certain circumstances.
- Unbreak CLANG build of the purgatory by avoiding the builtin
memcpy/memset implementations.
- Address missing prototype warnings by including the proper header
- Fix yet more fall-through issues"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/lib/cpu: Address missing prototypes warning
x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
x86/purgatory: Do not use __builtin_memcpy and __builtin_memset
x86: mtrr: cyrix: Mark expected switch fall-through
x86/ptrace: Mark expected switch fall-through
Pull perf tooling fixes from Thomas Gleixner:
"Perf tooling fixes all over the place:
- Fix the selection of the main thread COMM in db-export
- Fix the disassemmbly display for BPF in annotate
- Fix cpumap mask setup in perf ftrace when only one CPU is present
- Add the missing 'cpu_clk_unhalted.core' event
- Fix CPU 0 bindings in NUMA benchmarks
- Fix the module size calculations for s390
- Handle the gap between kernel end and module start on s390
correctly
- Build and typo fixes"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf pmu-events: Fix missing "cpu_clk_unhalted.core" event
perf annotate: Fix s390 gap between kernel end and module start
perf record: Fix module size on s390
perf tools: Fix include paths in ui directory
perf tools: Fix a typo in a variable name in the Documentation Makefile
perf cpumap: Fix writing to illegal memory in handling cpumap mask
perf ftrace: Fix failure to set cpumask when only one cpu is present
perf db-export: Fix thread__exec_comm()
perf annotate: Fix printing of unaugmented disassembled instructions from BPF
perf bench numa: Fix cpu0 binding
Pull scheduler fixes from Thomas Gleixner:
"Three fixlets for the scheduler:
- Avoid double bandwidth accounting in the push & pull code
- Use a sane FIFO priority for the Pressure Stall Information (PSI)
thread.
- Avoid permission checks when setting the scheduler params for the
PSI thread"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/psi: Do not require setsched permission from the trigger creator
sched/psi: Reduce psimon FIFO priority
sched/deadline: Fix double accounting of rq/running bw in push & pull
Pull irq fix from Thomas Gleixner:
"A small fix for the affinity spreading code.
It failed to handle situations where a single vector was requested
either due to only one CPU being available or vector exhaustion
causing only a single interrupt to be granted.
The fix is to simply remove the requirement in the affinity spreading
code for more than one interrupt being available"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
genirq/affinity: Create affinity mask for single vector
Pull objtool warning fix from Thomas Gleixner:
"The recent objtool fixes/enhancements unearthed a unbalanced CLAC in
the i915 driver.
Chris asked me to pick the fix up and route it through"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
Greg Kroah-Hartman says:
====================
Networking driver debugfs cleanups
There is no need to test the result of any debugfs call anymore. The
debugfs core warns the user if something fails, and the return value of
a debugfs call can always be fed back into another debugfs call with no
problems.
Also, debugfs is for debugging, so if there are problems with debugfs
(i.e. the system is out of memory) the rest of the kernel should not
change behavior, so testing for debugfs calls is pointless and not the
goal of debugfs at all.
This series cleans up a lot of networking drivers and some wimax code
that was calling debugfs and trying to do something with the return
value that it didn't need to. Removing this logic makes the code
smaller, easier to understand, and use less run-time memory in some
cases, all good things.
The series is against net-next, and have no dependancies between any of
them if they want to go through any random tree/order. Or, if wanted,
I can take them through my driver-core tree where other debugfs cleanups
are being slowly fed during major merge windows.
v3: fix build warning in i2400m, I thought I had caught them all :(
add acks from some reviewers
v2: fix up build warnings, it's as if I never even built these. Ugh, so
sorry for wasting people's time with the v1 series. I need to stop
relying on 0-day as it isn't working well anymore :(
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Harry Morris <h.morris@cascoda.com>
Cc: linux-wpan@vger.kernel.org
Cc: netdev@vger.kernel.org
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Nathan Huckleberry <nhuck@google.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Mirko Lindner <mlindner@marvell.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Michael Heimpold <michael.heimpold@i2se.com>
Cc: Yangtao Li <tiny.windzz@gmail.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't care about the individual files, we can remove the
stored dentry for the files, as they are not needed to be kept track of
at all.
Cc: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't care about the individual files, we can remove the
stored dentry for the files, as they are not needed to be kept track of
at all.
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Edwin Peer <edwin.peer@netronome.com>
Cc: Yangtao Li <tiny.windzz@gmail.com>
Cc: Simon Horman <simon.horman@netronome.com>
Cc: oss-drivers@netronome.com
Cc: netdev@vger.kernel.org
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
If a debugfs call fails, it will properly warn in the syslog, there's no
need for all individual drivers to also print a message, so that is one
more reason to not care about checking the return values.
Cc: Vishal Kulkarni <vishal@chelsio.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Casey Leedom <leedom@chelsio.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs
files, making all of this much simpler and easier to understand.
Cc: Michael Chan <michael.chan@broadcom.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs
files, making all of this much simpler and easier to understand.
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs
files, making all of this much simpler and easier to understand as we
don't need to keep the dentries saved anymore.
Cc: Saeed Mahameed <saeedm@mellanox.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The debugfs core now will print a message if this function fails, so
don't duplicate that logic. Also, no need to change the code logic if
the call fails either, as no debugfs calls should interrupt normal
kernel code for any reason.
Cc: Jay Vosburgh <j.vosburgh@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs wimax
files, making all of this much simpler and easier to understand.
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: linux-wimax@intel.com
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
A compilation -Wimplicit-fallthrough warning was enabled by commit
a035d552a9 ("Makefile: Globally enable fall-through warning")
Even though clang 10.0.0 does not currently support this warning without
a patch, clang currently does not support a value for this option.
Link: https://bugs.llvm.org/show_bug.cgi?id=39382
The gcc default for this warning is 3 so removing the =3 has no effect
for gcc and enables the warning for patched versions of clang.
Also remove the =3 from an existing use in a parisc Makefile:
arch/parisc/math-emu/Makefile
Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-and-tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Here are some small char/misc driver fixes for 5.3-rc4.
Two of these are for the habanalabs driver for issues found when running
on a big-endian system (are they still alive?) The others are tiny
fixes reported by people, and a MAINTAINERS update about the location of
the fpga development tree.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXU6uwA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymBrQCfRh8brBuZ4ZoeP9aVgjkPDhwdBLkAn38RdH6c
96J1xGLZf1+CN7GVLnFD
=YUWU
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes Greg KH:
"Here are some small char/misc driver fixes for 5.3-rc4.
Two of these are for the habanalabs driver for issues found when
running on a big-endian system (are they still alive?) The others are
tiny fixes reported by people, and a MAINTAINERS update about the
location of the fpga development tree.
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
MAINTAINERS: Move linux-fpga tree to new location
nvmem: Use the same permissions for eeprom as for nvmem
habanalabs: fix host memory polling in BE architecture
habanalabs: fix F/W download in BE architecture
Here are 2 small fixes for some driver core issues that have been
reported. There is also a kernfs "fix" here, which was then reverted
because it was found to cause problems in linux-next.
The driver core fixes both resolve reported issues, one with gpioint
stuff that showed up in 5.3-rc1, and the other finally (and hopefully)
resolves a very long standing race when removing glue directories. It's
nice to get that issue finally resolved and the developers involved
should be applauded for the persistence it took to get this patch
finally accepted.
All of these have been in linux-next for a while with no reported
issues. Well, the one reported issue, hence the revert :)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXU6t8Q8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yk1YgCgy7Mw/CYLBK5It+fItRuAWLdyzMkAoIyo8Qen
GS7FeSwM237JlWhC/Jqc
=IMyo
-----END PGP SIGNATURE-----
Merge tag 'driver-core-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg KH:
"Here are two small fixes for some driver core issues that have been
reported. There is also a kernfs "fix" here, which was then reverted
because it was found to cause problems in linux-next.
The driver core fixes both resolve reported issues, one with gpioint
stuff that showed up in 5.3-rc1, and the other finally (and hopefully)
resolves a very long standing race when removing glue directories.
It's nice to get that issue finally resolved and the developers
involved should be applauded for the persistence it took to get this
patch finally accepted.
All of these have been in linux-next for a while with no reported
issues. Well, the one reported issue, hence the revert :)"
* tag 'driver-core-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
Revert "kernfs: fix memleak in kernel_ops_readdir()"
kernfs: fix memleak in kernel_ops_readdir()
driver core: Fix use-after-free and double free on glue directory
driver core: platform: return -ENXIO for missing GpioInt
Here is a single tty kgdb fix for 5.3-rc4.
It fixes an annoying log message that has caused kdb to become useless.
It's another fallout from ddde3c18b7 ("vt: More locking checks") which
tries to enforce locking checks more strictly in the tty layer,
unfortunatly when kdb is stopped, there's no need for locks :)
This patch has been linux-next for a while with no reported issues
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXU6sCg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykBNwCgwbxPP9bmqcyCW+0gx3SfpHAxAAYAn19DGKgV
o5Es4DDBbXkspoW7ck7D
=dcGv
-----END PGP SIGNATURE-----
Merge tag 'tty-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty fix from Greg KH:
"Here is a single tty kgdb fix for 5.3-rc4.
It fixes an annoying log message that has caused kdb to become
useless. It's another fallout from commit ddde3c18b7 ("vt: More
locking checks") which tries to enforce locking checks more strictly
in the tty layer, unfortunatly when kdb is stopped, there's no need
for locks :)
This patch has been linux-next for a while with no reported issues"
* tag 'tty-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
kgdboc: disable the console lock when in kgdb
Here are some small staging and IIO driver fixes for 5.3-rc4.
Nothing major, just resolutions for a number of small reported issues,
full details in the shortlog.
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXU6s+Q8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymESgCgx89m2wjVxWJIvqpnUWwzSRdfE7sAnjOl5MG+
oHxph0/GU8f1NZQ3ZOYF
=pRYy
-----END PGP SIGNATURE-----
Merge tag 'staging-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging / IIO driver fixes from Greg KH:
"Here are some small staging and IIO driver fixes for 5.3-rc4.
Nothing major, just resolutions for a number of small reported issues,
full details in the shortlog.
All have been in linux-next for a while with no reported issues"
* tag 'staging-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
iio: adc: gyroadc: fix uninitialized return code
docs: generic-counter.rst: fix broken references for ABI file
staging: android: ion: Bail out upon SIGKILL when allocating memory.
Staging: fbtft: Fix GPIO handling
staging: unisys: visornic: Update the description of 'poll_for_irq()'
staging: wilc1000: flush the workqueue before deinit the host
staging: gasket: apex: fix copy-paste typo
Staging: fbtft: Fix reset assertion when using gpio descriptor
Staging: fbtft: Fix probing of gpio descriptor
iio: imu: mpu6050: add missing available scan masks
iio: cros_ec_accel_legacy: Fix incorrect channel setting
IIO: Ingenic JZ47xx: Set clock divider on probe
iio: adc: max9611: Fix misuse of GENMASK macro
Here are some small USB fixes for 5.3-rc4.
The "biggest" one here is moving code from one file to another in order
to fix a long-standing race condition with the creation of sysfs files
for USB devices. Turns out that there are now userspace tools out there
that are hitting this long-known bug, so it's time to fix them.
Thankfully the tool-maker in this case fixed the issue :)
The other patches in here are all fixes for reported issues. Now that
syzbot knows how to fuzz USB drivers better, and is starting to now fuzz
the userspace facing side of them at the same time, there will be more
and more small fixes like these coming, which is a good thing.
All of these have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXU6vag8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynNZgCgs6tk3zfjbsiA1YuLtQ5PIazQFwsAn00qRiKi
0MIt5mRc7lEsG1yJgvEQ
=fb5s
-----END PGP SIGNATURE-----
Merge tag 'usb-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 5.3-rc4.
The "biggest" one here is moving code from one file to another in
order to fix a long-standing race condition with the creation of sysfs
files for USB devices. Turns out that there are now userspace tools
out there that are hitting this long-known bug, so it's time to fix
them. Thankfully the tool-maker in this case fixed the issue :)
The other patches in here are all fixes for reported issues. Now that
syzbot knows how to fuzz USB drivers better, and is starting to now
fuzz the userspace facing side of them at the same time, there will be
more and more small fixes like these coming, which is a good thing.
All of these have been in linux-next with no reported issues"
* tag 'usb-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: setup authorized_default attributes using usb_bus_notify
usb: iowarrior: fix deadlock on disconnect
Revert "USB: rio500: simplify locking"
usb: usbfs: fix double-free of usb memory upon submiturb error
usb: yurex: Fix use-after-free in yurex_delete
usb: typec: tcpm: Ignore unsupported/unknown alternate mode requests
xhci: Fix NULL pointer dereference at endpoint zero reset.
usb: host: xhci-rcar: Fix timeout in xhci_suspend()
usb: typec: ucsi: ccg: Fix uninitilized symbol error
usb: typec: tcpm: remove tcpm dir if no children
usb: typec: tcpm: free log buf memory when remove debug file
usb: typec: tcpm: Add NULL check before dereferencing config
Simple buddy allocator. We want to allocate properly aligned
power-of-two blocks to promote usage of huge-pages for the GTT, so 64K,
2M and possibly even 1G. While we do support allocating stuff at a
specific offset, it is more intended for preallocating portions of the
address space, say for an initial framebuffer, for other uses drm_mm is
probably a much better fit. Anyway, hopefully this can all be thrown
away if we eventually move to having the core MM manage device memory.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190809202926.14545-2-matthew.auld@intel.com
We can already clear an object with the blt, so try to do the same to
support copying from one object backing store to another. Really this is
just object -> object, which is not that useful yet, what we really want
is two backing stores, but that will require some vma rework first,
otherwise we are stuck with "tmp" objects.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190810174338.19810-1-chris@chris-wilson.co.uk
All the way back to introducing dma_common_mmap we've defaulted to mark
the pages as uncached. But this is wrong for DMA coherent devices.
Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
flag is only treated special on the alloc side for non-coherent devices.
Introduce a new dma_pgprot helper that deals with the check for coherent
devices so that only the remapping cases ever reach arch_dma_mmap_pgprot
and we thus ensure no aliasing of page attributes happens, which makes
the powerpc version of arch_dma_mmap_pgprot obsolete and simplifies the
remaining ones.
Note that this means arch_dma_mmap_pgprot is a bit misnamed now, but
we'll phase it out soon.
Fixes: 64ccc9c033 ("common: dma-mapping: add support for generic dma_mmap_* calls")
Reported-by: Shawn Anastasio <shawn@anastas.io>
Reported-by: Gavin Li <git@thegavinli.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com> # arm64
The dma required_mask needs to reflect the actual addressing capabilities
needed to handle the whole system RAM. When truncated down to the bus
addressing capabilities dma_addressing_limited() will incorrectly signal
no limitations for devices which are restricted by the bus_dma_mask.
Fixes: b4ebe60632 (dma-direct: implement complete bus_dma_mask handling)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
