The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some toggling operation in xHCI driver still use conditional toggling:
ring->cycle_state = (ring->cycle_state ? 0 : 1);
Use XOR to invert the cycle state instead of a conditional toggle to unify
cycle state toggling operation in xHCI driver.
Signed-off-by: Lin Wang <lin.x.wang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
this patch fixes following sparse warning:
sl811-hcd.c:1804:24: warning: symbol 'sl811h_driver' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds runtime power management support for otg fsm mode, since
A-device in a_idle state cannot detect data pulse irq after suspended, here
enable wakeup by connection before suspend to make it can be resumed by DP;
and handle wakeup from that state like SRP.
Signed-off-by: Li Jun <jun.li@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If CI_HDRC_TURN_VBUS_EARLY_ON is set, turn on vbus before adding hcd, so it
will not set reg_vbus of ehci_ci_priv, then vbus will not be handled by ehci core.
Signed-off-by: Li Jun <jun.li@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some usb PHYs need power supply from vbus to make it work, eg mxs-phy, if
there is no vbus, USB PHY will not in correct state when the controller starts
to work, for host, this requires vbus should be turned on before setting port
power(PP) of ehci, to work with this kind of USB PHY design, this patch adds
a flag CI_HDRC_TURN_VBUS_EARLY_ON, can be checked by host driver to turn on
vbus while start host.
Signed-off-by: Li Jun <jun.li@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since PHY for ChipIdea is optional (not all SoCs having PHY for ChipIdea should
be programmed), we register 'nop' PHY for platforms that do not have
programmable PHY.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For chipidea, its resume sequence is not-EHCI compatible, see
below description for FPR at portsc. So in order to send SoF in
time for remote wakeup sequence(within 3ms), the RUN/STOP bit must
be set before the resume signal is ended, but the usb resume
code may run after resume signal is ended, so we had to set it
at suspend path.
Force Port Resume - RW. Default = 0b.
1= Resume detected/driven on port.
0=No resume (K-state) detected/driven on port.
Host mode:
Software sets this bit to one to drive resume signaling. The Controller sets this bit to '1' if
a J-to-K transition is detected while the port is in the Suspend state. When this bit
transitions to a '1' because a J-to-K transition is detected, the Port Change Detect bit in
the USBSTS register is also set to '1'. This bit will automatically change to '0' after the
resume sequence is complete. This behavior is different from EHCI where the controller
driver is required to set this bit to a '0' after the resume duration is timed in the driver.
Note that when the controller owns the port, the resume sequence follows the defined
sequence documented in the USB Specification Revision 2.0. The resume signaling
(Full-speed 'K') is driven on the port as long as this bit remains a '1'. This bit will remain
a '1' until the port has switched to idle. Writing a '0' has no affect because the port
controller will time the resume operation, clear the bit and the port control state switches
to HS or FS idle.
This field is '0' if Port Power(PP) is '0' in host mode.
This bit is not-EHCI compatible.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PORTSC_PFSC is not set on entering host mode which means the USB OTG
controller will attempt to enumerate USB devices at high speed even when the
CI_HDRC_FORCE_FULLSPEED flag is set in the platform data.
This patch ensures it is set right before host mode operations begin if needed.
Signed-off-by: Daniel Tang <dt.tangr@gmail.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At chipidea revision 2.40a, there is a below errata:
9000531823 B2-Medium Adding a dTD to a Primed Endpoint May Not Get Recognized
Title: Adding a dTD to a Primed Endpoint May Not Get Recognized
Impacted Configuration: All device mode configurations.
Description:
There is an issue with the add dTD tripwire semaphore (ATDTW bit in USBCMD register)
that can cause the controller to ignore a dTD that is added to a primed endpoint.
When this happens, the software can read the tripwire bit and the status bit at '1'
even though the endpoint is unprimed.
After executing a dTD, the device controller endpoint state machine executes a final
read of the dTD terminate bit to check if the application added a dTD to the linked
list at the last moment. This read is done in the finpkt_read_latest_next_td (44) state.
After the read is performed, if the terminate bit is still set, the state machine moves
to unprime the endpoint. The decision to unprime the endpoint is done in the
checkqh_decision (59) state, based on the value of the terminate bit.
Before reaching the checkqh_decision state, the state machine traverses the
writeqhtd_status (57), writeqh_status (56), and release_prime_mask (42) states.
As shown in the waveform, the ep_addtd_tripwire_clr signal is not set to clear
the tripwire bit in these states.
Workaround:
The software must implement a periodic poll cycle, and check for each dTD
pending on execution (Active = 1), if the enpoint is primed. It can do this by reading
the corresponding bits in the ENDPTPRIME and ENDPTSTAT registers. If these bits are
read at 0, the software needs to re-prime the endpoint by writing 1 to the corresponding
bit in the ENDPTPRIME register. This can be done for every microframe, every frame or
with a larger interval, depending on the urgency of transfer execution for the application.
Tested-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Define ci_get_revision API to know the controller revision
information according to chipidea 1.1a, 2.0a and 2.5a spec.
Besides, add one entry at struct ci_hdrc to indicate revision
information, it can be used for adding different code for
revisions, eg kinds of errata.
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using hw_write_id_reg and hw_read_id_reg to write and read identification
registers contents, they can be used to get controller information, change
some system configurations, and so on.
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Except the same process with earlier imx6, it has below two features:
- Choose which vbus voltage as vbus wakeup source
We choose B_SESSION_VALID as vbus wakeup source since when the system
goes to suspend, the vbus comparator can't compare the vbus voltage
for VBUS_VALID.
- Disable dp/dm (linestate) change as wakeup source at device mode
when the vbus is not there, we don't expect dp/dm change waking up
usb controller at this situation.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need to do it for all otg capable controller, not only peripheral
featured otg capable controller, otherwise, the host-only role, but
otg capable controller may be responded by otg interrupt.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the example for how to enable USB as system wakeup source.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable USB as system wakeup source, and each platform needs to implement
imx_usbmisc_set_wakeup in usbmisc_imx.c to support.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB signal can be system wakeup source, this patch add the
support, for how to enable it, see Documentation/usb/chipidea.txt.
Since USB wakeup enable logic is vendor/platform specific, the
glue layer needs to implement it to support this feature.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add runtime pm support for imx, only imx6 series are supported and tested.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This API is used to enable/disable usb wakeup, only imx6 series are
added, since I don't have other imx hardware on hand. Other imx users
can add their API according to reference manual after testing.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move struct imx_usbmisc_data NULL pointer judgement from caller to
each API, it can simplify the caller.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All imx usb controller's non core registers uses the same clock gate with
core registers, the usbmisc_imx is the library for imx glue driver, the
glue keeps clock on when it calls usbmisc_imx API to change non-core register.
Besides, we will support runtime pm in the future, it also needs to
close this clock when the usb is not in use.
Philipp Zabel also verifies it at imx6q platform, see
http://www.spinics.net/lists/linux-usb/msg118491.html
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is meaningless the glue layer driver has its own platform flag
which is the same meaning with common platform flag.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some gadget driver (like uac1) will try to enable endpoint again even
the ep is not empty, it will cause the ep reset again and may affect
the dTD list which has already queued.
It returns -EBUSY immediately, and indicate the endpoint is in use.
In this way, the ep's behavior will not be affected, and the gadget
driver is also notified.
Cc: Xuebing Wang <xbing6@gmail.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We should signal connect (pull up dp) after we have already
at peripheral mode, otherwise, the dp may be toggled due to
we reset controller or do disconnect during the initialization
for peripheral, then, the host may be confused during the
enumeration, eg, it finds the reset can't succeed, but the
device is still there, see below error message.
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: cannot reset port 1 (err = -32)
hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
hub 1-0:1.0: unable to enumerate USB device on port 1
Fixes: the issue existed when the otg fsm code was added.
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A new uas compatible controller has shown up in some people's devices from
the manufacturer Initio Corporation, this controller needs the US_FL_NO_ATA_1X
quirk to work properly with uas, so add it to the uas quirks table.
Reported-and-tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false. It only took effect when buffers
were validated later. It also seemed to regress suspend
and resume on some systems possibly due to it not
taking effect in radeon_bo_create().
radeon_bo_create() and radeon_ttm_placement_from_domain()
need to be reworked substantially for this to be optimally
effective. Re-enable it at that point.
Noticed-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The EHCI IP only needs the UTMI/UPLL (uclk) and the peripheral (iclk)
clocks to work properly. Remove the useless system clock (fclk).
Avoid calling set_rate on the fixed rate UTMI/IPLL clock and remove
useless IS_ENABLED(CONFIG_COMMON_CLK) tests (all at91 platforms have been
moved to the CCF).
This patch also fixes a bug introduced by 3440ef1 (ARM: at91/dt: fix USB
high-speed clock to select UTMI), which was leaving the usb clock
uninitialized and preventing the OHCI driver from setting the usb clock
rate to 48MHz.
This bug was caused by several things:
1/ usb clock drivers set the CLK_SET_RATE_GATE flag, which means the rate
cannot be changed once the clock is prepared
2/ The EHCI driver was retrieving and preparing/enabling the uhpck
clock which was in turn preparing its parent clock (the usb clock),
thus preventing any rate change because of 1/
Fixes: 3440ef1691 ("ARM: at91/dt: fix USB high-speed clock to select UTMI")
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
use of the enabled flag, which means that the code may attempt to call
win_enable on a NULL crtc. This results in the following oops on
Arndale:
[ 1.673479] Unable to handle kernel NULL pointer dereference at virtual address 00000368
[ 1.681500] pgd = c0004000
[ 1.684154] [00000368] *pgd=00000000
[ 1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 1.693012] Modules linked in:
[ 1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
3.19.0-07545-g57485fa #1907
[ 1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
(....)
[ 2.014803] [<c02f9cfc>] (exynos_plane_destroy) from [<c02e61b4>] (drm_mode_config_cleanup+0x168/0x20c)
[ 2.024178] [<c02e61b4>] (drm_mode_config_cleanup) from [<c02f66fc>] (exynos_drm_load+0xac/0x12c)
This patch adds in a check to ensure exynos_crtc is not NULL before it
is dereferenced.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Replace inline asm statement in __get_cpu_architecture() with equivalent
macro invocation, i.e. read_cpuid_ext(CPUID_EXT_MMFR0);
As an added bonus, this squashes a potential bug, described by Paul
Walmsley in commit 067e710b9a ("ARM: 7801/1: prevent gcc 4.5 from
reordering extended CP15 reads above is_smp() test").
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The set_memory_* functions currently only support module
addresses. The addresses are validated using is_module_addr.
That function is special though and relies on internal state
in the module subsystem to work properly. At the time of
module initialization and calling set_memory_*, it's too early
for is_module_addr to work properly so it always returns
false. Rather than be subject to the whims of the module state,
just bounds check against the module virtual address range.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Allow prefetch settings overriding by device tree, in case
l2x0_cache_size_of_parse() returns value, prefetch tuning
properties are silently ignored. E.g. arm,double-linefill* and
arm,prefetch*.
This happens for example, when "cache-size" or "cache-sets"
properties haven't been filled in l2c dt node.
Comments from Fabrice Gasnier:
Allow device tree to override the L2C prefetch settings, even when
l2x0_cache_size_of_parse() fails to parse the cache geometry due to (eg)
missing "cache-size" or "cache-sets" properties.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On sun4i-a10, when GPIOs are configured as external interrupt the value for
them in the data register does not seem to get updated, so set their mux to
input (and restore afterwards) when reading the pin.
Missed edges seem to be buffered, so this does not introduce a race
condition.
I've also tested this on sun5i-a13 and sun7i-a20 and those do not seem to
be affected, the input value representation in the data register does seem
to correctly get updated to the actual pin value while in irq mode there.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
After importing multi-lower layer support, users could mount a r/o
partition as the left most lowerdir instead of using it as upperdir.
And a r/o upperdir may cause an error like
overlayfs: failed to create directory ./workdir/work
during mount.
This patch check the *s_flags* of upper fs and return an error if
it is a r/o partition. The checking of *upper_mnt->mnt_sb->s_flags*
can be removed now.
This patch also remove
/* FIXME: workdir is not needed for a R/O mount */
from ovl_fill_super() because:
1) for upper fs r/o case
Setting a r/o partition as upper is prevented, no need to care about
workdir in this case.
2) for "mount overlay -o ro" with a r/w upper fs case
Users could remount overlayfs to r/w in this case, so workdir should
not be omitted.
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Recently multi-lower layer mount support allow upperdir and workdir
to be omitted, then cause overlayfs can be mount with only one
lowerdir directory. This action make no sense and have potential risk.
This patch check the total number of lower directories to prevent
mounting overlayfs with only one directory.
Also, an error message is added to indicate lower directories exceed
OVL_MAX_STACK limit.
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Overlayfs should print an error message if an incorrect mount option
is caught like other filesystems.
After this patch, improper option input could be clearly known.
Reported-by: Fabian Sturm <fabian.sturm@aduu.de>
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.
Refuse to read out the fb state when the primary plane isn't enabled.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Reference: http://mid.gmane.org/20150203191507.GA2374@crion86
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Revisiting commit d23b8ad8ab ("tc: add BPF based action") with regards
to eBPF support, I was thinking that it might be better to improve
return semantics from a BPF program invoked through BPF_PROG_RUN().
Currently, in case filter_res is 0, we overwrite the default action
opcode with TC_ACT_SHOT. A default action opcode configured through tc's
m_bpf can be: TC_ACT_RECLASSIFY, TC_ACT_PIPE, TC_ACT_SHOT, TC_ACT_UNSPEC,
TC_ACT_OK.
In cls_bpf, we have the possibility to overwrite the default class
associated with the classifier in case filter_res is _not_ 0xffffffff
(-1).
That allows us to fold multiple [e]BPF programs into a single one, where
they would otherwise need to be defined as a separate classifier with
its own classid, needlessly redoing parsing work, etc.
Similarly, we could do better in act_bpf: Since above TC_ACT* opcodes
are exported to UAPI anyway, we reuse them for return-code-to-tc-opcode
mapping, where we would allow above possibilities. Thus, like in cls_bpf,
a filter_res of 0xffffffff (-1) means that the configured _default_ action
is used. Any unkown return code from the BPF program would fail in
tcf_bpf() with TC_ACT_UNSPEC.
Should we one day want to make use of TC_ACT_STOLEN or TC_ACT_QUEUED,
which both have the same semantics, we have the option to either use
that as a default action (filter_res of 0xffffffff) or non-default BPF
return code.
All that will allow us to transparently use tcf_bpf() for both BPF
flavours.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
The gpiochip_lock_as_irq call can fail and return an error,
while the irq_startup is not expected to fail (returns an
unsigned int which is not checked by irq core code).
irq_request/release_resources functions have been created
to address this problem.
Move gpiochip_lock/unlock_as_irq calls into
irq_request/release_resources functions to prevent using a
gpio as an irq if the gpiochip_lock_as_irq call failed.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is a typo here so we deadlock.
Fixes: dd1f1f391d ('rtc: at91rm9200: rework wakeup and interrupt handling')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: David Dueck <davidcdueck@googlemail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We are keeping track of how many extents we need to reserve properly based on
the amount we want to write, but we were still incrementing outstanding_extents
if we wrote less than what we requested. This isn't quite right since we will
be limited to our max extent size. So instead lets do something horrible! Keep
track of how many outstanding_extents we reserved, and decrement each time we
allocate an extent. If we use our entire reserve make sure to jack up
outstanding_extents on the inode so the accounting works out properly. Thanks,
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
I introduced a regression wrt outstanding_extents accounting. These are tricky
areas that aren't easily covered by xfstests as we could change MAX_EXTENT_SIZE
at any time. So add sanity tests to cover the various conditions that are
tricky in order to make sure we don't introduce regressions in the future.
Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
