This attempts to produce a comparison between native getpid() and a
RET_ALLOW-filtered getpid(), to measure the overhead cost of using
seccomp().
Signed-off-by: Kees Cook <keescook@chromium.org>
This exposes the battery conservation mode present on some (?) IdeaPads.
The mode is set by calling ACPI method SBMC with argument 3 (on) or
5 (off). Status is reported in bit 5 of the return value of ACPI method
GBMD.
Signed-off-by: Hao Wei Tee <angelsl@in04.sg>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The PCA955x family of chips are I2C LED blinkers whose pins not used
to control LEDs can be used as general purpose I/Os (GPIOs).
The following adds such a support by defining different operation
modes for the pins (See bindings documentation for more details). The
pca955x driver is then extended with a gpio_chip when some of pins are
operating as GPIOs. The default operating mode is to behave as a LED.
The GPIO support is conditioned by CONFIG_LEDS_PCA955X_GPIO.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This lets us remove the loop doing the cleanup in case of failure and
also the remove handler of the i2c_driver.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
It will be used in a following patch to define different operation
modes for each pin.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Pull MD fixes from Shaohua Li:
"Fix several bugs:
- fix a rcu stall issue introduced in 4.12 (Neil Brown)
- fix two raid5 cache race conditions (Song Liu)"
* tag 'md/4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md:
MD: not clear ->safemode for external metadata array
md/r5cache: fix io_unit handling in r5l_log_endio()
md/r5cache: call mddev_lock/unlock() in r5c_journal_mode_set
md: fix test in md_write_start()
md: always clear ->safemode when md_check_recovery gets the mddev lock.
Before I skipped null checks when the master is in the STOP state; this
fixes that.
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Acked-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: f327c686d3 ("i2c: aspeed: added driver for Aspeed I2C")
24xx BMCs have larger clock divider granularity which can cause problems
when trying to set them as 25xx clock dividers; this adds clock setting
code specific to 24xx.
This also fixes a potential issue where clock dividers were rounded down
instead of up.
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-i2c@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: linux-i2c@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: linux-i2c@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Commit a53e35db70 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Use api pair of request_mem_region and release_mem_region
instead of release_resource.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
I2C drivers were required to have an I2C device ID table even if were for
devices that would only be registered using a specific firmware interface
(e.g: OF or ACPI).
But commit da10c06a04 ("i2c: Make I2C ID tables non-mandatory for DT'ed
devices") changed the I2C core to relax the requirement and allow drivers
to avoid defining this table.
Unfortunately it only took into account drivers for OF-only devices and
forgot about ACPI-only ones, and this was fixed by commit c64ffff7a9
("i2c: core: Allow empty id_table in ACPI case as well").
But the latter didn't update the original comment, so it doesn't reflect
what the code does now.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This adds tests for using only ptrace to perform syscall changes, just
to validate matching behavior between seccomp events and ptrace events.
Signed-off-by: Kees Cook <keescook@chromium.org>
Export all the available status registers through debugfs. This is
useful for hardware diagnostics, especially on multi-page pmbus devices,
as user-space access of the i2c space could corrupt the pmbus page
accounting.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Code sets bit DW_IC_CON_SPEED_FAST (0x4) always when configuring the slave
mode. This results incorrect register value DW_IC_CON_SPEED_HIGH (0x6)
when OR'ed together with DW_IC_CON_SPEED_STD (0x2).
Remove this and let the code set the speed mode bits according to clock
frequency or default to fast mode.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
When i2c-designware is initialized in slave mode the
i2c-designware-slave.c: i2c_dw_irq_handler_slave() can hit a NULL
pointer dereference when I2C slave backend is not registered but code is
accessing the struct dw_i2c_dev.slave without testing is it NULL.
We might get spurious interrupts from other devices or from IRQ core
during unloading the driver when CONFIG_DEBUG_SHIRQ is set. Existing
check for enable and IRQ status is not enough since device can be power
gated and those bits may read 1.
Fix this by handling the interrupt only when also struct dw_i2c_dev.slave
is set.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The commit 8503ff1665 ("i2c: designware: Avoid unnecessary resuming
during system suspend"), may suggest to the PM core to try out the so
called direct_complete path for system sleep. In this path, the PM core
treats a runtime suspended device as it's already in a proper low power
state for system sleep, which makes it skip calling the system sleep
callbacks for the device, except for the ->prepare() and the ->complete()
callbacks.
However, the PM core may unset the direct_complete flag for a parent
device, in case its child device are being system suspended before. In this
scenario, the PM core invokes the system sleep callbacks, no matter if the
device is runtime suspended or not.
Particularly in cases of an existing i2c slave device, the above path is
triggered, which breaks the assumption that the i2c device is always
runtime resumed whenever the dw_i2c_plat_suspend() is being called.
More precisely, dw_i2c_plat_suspend() calls clk_core_disable() and
clk_core_unprepare(), for an already disabled/unprepared clock, leading to
a splat in the log about clocks calls being wrongly balanced and breaking
system sleep.
To still allow the direct_complete path in cases when it's possible, but
also to keep the fix simple, let's runtime resume the i2c device in the
->suspend() callback, before continuing to put the device into low power
state.
Note, in cases when the i2c device is attached to the ACPI PM domain, this
problem doesn't occur, because ACPI's ->suspend() callback, assigned to
acpi_subsys_suspend(), already calls pm_runtime_resume() for the device.
It should also be noted that this change does not fix commit 8503ff1665
("i2c: designware: Avoid unnecessary resuming during system suspend").
Because for the non-ACPI case, the system sleep support was already broken
prior that point.
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull crypto fixes from Herbert Xu:
"Fix an error path bug in ixp4xx as well as a read overrun in
sha1-avx2"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: x86/sha1 - Fix reads beyond the number of blocks passed
crypto: ixp4xx - Fix error handling path in 'aead_perform()'
Add camera support to N900 dts. Also add a note about MMC & debugging.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
dra76-evm is a board based on TI's dra76 processor targeting
for infotainment systems. Adding support for this platform.
dra76-evm and dra7-evm has a similar layout except with few differences.
So create a dra7-evm-common.dtsi with similarities on dra76-evm and
dra7-evm. Include this common dtsi in both dra7-evm.dts and dra76-evm.dts
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
dra76 family is a high-performance, infotainment application
device, based on OMAP architecture on a 28-nm technology.
This contains most of the subsystems, peripherals that are
available on dra74, dra72 family. This SoC mainly features
Subsystems:
- 2 x Cortex-A15 with max speed of 1.8GHz
- 2 X DSP
- 2 X Cortex-M4 IPU
- ISS
- CAL
- DSS
- VPE
- VIP
Connectivity peripherals:
- 1 USB3.0 and 3 USB2.0 subsystems
- 2 x SATA
- 2 x PCI Express Gen2
- 3-port Gigabit ethernet switch
- 2 x CAN
- MCAN
Adding basic dts support for DRA76 family while reusing the
data available in dra7.dtsi, dra74x.dtsi.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add pcie1 dt node in order for the controller to operate in
endpoint mode. However since none of the dra7 based boards have
slots configured to operate in endpoint mode, keep EP mode
disabled.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add support for Moxa UC-8100-ME-T open platform
The UC-8100-ME-T computing platform is designed
for embedded data acquisition industrial applications
The features of UC-8100-ME-T series are:
* eMMC
* SPI flash
* SD slot
* 2x LAN
* 2 RS-232/422/485 ports, software-selectable
* Mini PCIe form factor with USB signal
* USB host
* EEPROM
* TPM
* Watchdog
* RTC
* User gpio-keys
* User LEDs
* User button
Signed-off-by: SZ Lin <sz.lin@moxa.com>
Acked-by: Rob Herring <robh@kernel.org>
[tony@atomide.com: fix unit adress as suggested by Rob]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently the default method of prefetch polled shows the highest
possible read and write speed when minimal non NAND background
activity is being done. But it is also very CPU intensive to reach
these high speeds (CPU load of 99% via mtd performance tests). While
DMA prefetch only uses 50% of the CPU to achieve around 23% less in
top read and write performance.
However, as the non NAND CPU load increases the read and write
performance takes a large hit when using polled prefetch. Therefore,
prefetch dma mode ends up outperforming prefetch polled in general
"system level" test. So switch to using dma prefetch by default since
it is likely what most users would prefer.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently the default method of prefetch polled shows the highest
possible read and write speed when minimal non NAND background
activity is being done. But it is also very CPU intensive to reach
these high speeds (CPU load of 99% via mtd performance tests). While
DMA prefetch only uses 50% of the CPU to achieve around 23% less in
top read and write performance.
However, as the non NAND CPU load increases the read and write
performance takes a large hit when using polled prefetch. Therefore,
prefetch dma mode ends up outperforming prefetch polled in general
"system level" test. So switch to using dma prefetch by default since
it is likely what most users would prefer.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently the default method of prefetch polled shows the highest
possible read and write speed when minimal non NAND background
activity is being done. But it is also very CPU intensive to reach
these high speeds (CPU load of 99% via mtd performance tests). While
DMA prefetch only uses 50% of the CPU to achieve around 23% less in
top read and write performance.
However, as the non NAND CPU load increases the read and write
performance takes a large hit when using polled prefetch. Therefore,
prefetch dma mode ends up outperforming prefetch polled in general
"system level" test. So switch to using dma prefetch by default since
it is likely what most users would prefer.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add vibrator to Droid4's device tree.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Set default mode for vaudio, which may be left in standby mode
if the system is booted via kexec from Android.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
All nodes inhert "interrupt-parent" property from root
node. Removed the aforementioned property from usbhsohci,
usbhsehci, ssi_port1, ssi_port2 nodes to avoid duplication.
Signed-off-by: Karthik Tummala <karthik@techveda.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Devices using an external encoder, ESD protection and level shifter
such as tpd12s015 or ip4791cz12 have the CEC pull in the encoder
chip. And on var-som-om44, there is external pull up resistor R30.
So the internal CEC pull-up resistor needs to be disabled as otherwise
the external and internal pull are parallel making the pull value
much smaller than intended. This leads into the CEC not working as
reported by Hans Verkuil <hverkuil@xs4all.nl>.
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add support for onboard gpio buzzer. It works using
the gpio-beeper driver. Pinmux entries for GPIO
controlling the buzzer are also added.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
In the function msg_reverse(), we reverse the header while trying to
reuse the original buffer whenever possible. Those rejected/returned
messages are always transmitted as unicast, but the msg_non_seq field
is not explicitly set to zero as it should be.
We have seen cases where multicast senders set the message type to
"NOT dest_droppable", meaning that a multicast message shorter than
one MTU will be returned, e.g., during receive buffer overflow, by
reusing the original buffer. This has the effect that even the
'msg_non_seq' field is inadvertently inherited by the rejected message,
although it is now sent as a unicast message. This again leads the
receiving unicast link endpoint to steer the packet toward the broadcast
link receive function, where it is dropped. The affected unicast link is
thereafter (after 100 failed retransmissions) declared 'stale' and
reset.
We fix this by unconditionally setting the 'msg_non_seq' flag to zero
for all rejected/returned messages.
Reported-by: Canh Duc Luu <canh.d.luu@dektech.com.au>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On L2 bearers, the TIPC broadcast function is sending out packets using
the corresponding L2 broadcast address. At reception, we filter such
packets under the assumption that they will also be delivered as
broadcast packets.
This assumption doesn't always hold true. Under high load, we have seen
that a switch may convert the destination address and deliver the packet
as a PACKET_MULTICAST, something leading to inadvertently dropped
packets and a stale and reset broadcast link.
We fix this by extending the reception filtering to accept packets of
type PACKET_MULTICAST.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ohad Oz says:
====================
Enable Mellanox switch device in I2C mode
The following patch set updates global to Mellanox Kconfig files to support
configuration of Mellanox Switch (mlxsw) without PCI and with I2C only.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Mellanox switches (mlxsw) supports I2C systems without PCI, in order to
give the ability to the users to use such functionality, there is need
to update Kconfig.
Signed-off-by: Ohad Oz <ohado@mellanox.com>
Acked-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Using tabs instead of space for indentation.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Pirko says:
====================
mlxsw: spectrum_router: Increase VRF scale
Ido says:
The purpose of this set is to increase the maximum number of supported VRF
devices on top of the Spectrum ASIC under different workloads.
This is achieved by sharing the same LPM tree across all the virtual
routers for a given L3 protocol (IPv4 / IPv6). The change is explained in
detail in the third patch. First two patches are small changes to make
review easier.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The number of LPM trees available for lookup is much smaller than the
number of virtual routers, which are used to implement VRFs. In
addition, an LPM tree can only be used by one protocol - either IPv4 or
IPv6.
Therefore, in order to increase the number of supported virtual routers
to the maximum we need to be able to share LPM trees across virtual
routers instead of trying to find an optimized tree for each.
Do that by allocating one LPM tree for each protocol, but make sure it
will only include prefixes that are actually used, so as to not perform
unnecessary lookups.
Since changing the structure of a bound tree isn't recommended, whenever
a new tree it required, it's first created and then bound to each
virtual router, replacing the old one.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on the LPM tree to be assigned to the virtual router
before binding the two, lets pass it explicitly.
This will later allow us to return upon binding error instead of having
to perform a rollback of the assignment.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no point in returning a value from function whose return value
is never checked.
Even if the return value was checked, there wouldn't be anything to do
about it, as these functions are either called from error or deletion
paths.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the missing 32-bit enable method for SMP on BCM2836 and
BCM2837. The BCM2837 already has an enabled method, but this one only
works for 64-bit.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Eric Anholt <eric@anholt.net>
This adds a compatible string "brcm,bcm2836-smp" for Broadcom's
BCM2836 and BCM2837 to the 32 bit ARM CPU device tree binding.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
