| Age | Commit message (Collapse) | Author |
|---|
|
Most places which allocate an r10_bio zero the ->state, some don't.
As the r10_bio comes from a mempool, and the allocation function uses
kzalloc it is often zero anyway. But sometimes it isn't and it is
best to be safe.
I only noticed this because of the bug fixed by an earlier patch
where the r10_bios allocated for a reshape were left around to
be used by a subsequent resync. In that case the R10BIO_IsReshape
flag caused problems.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
If raid10 reshape fails to find somewhere to read a block
from, it returns without freeing memory...
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
When a raid10 commences a resync/recovery/reshape it allocates
some buffer space.
When a resync/recovery completes the buffer space is freed. But not
when the reshape completes.
This can result in a small memory leak.
There is a subtle side-effect of this bug. When a RAID10 is reshaped
to a larger array (more devices), the reshape is immediately followed
by a "resync" of the new space. This "resync" will use the buffer
space which was allocated for "reshape". This can cause problems
including a "BUG" in the SCSI layer. So this is suitable for -stable.
Cc: stable@vger.kernel.org (v3.5+)
Fixes: 3ea7daa5d7fde47cd41f4d56c2deb949114da9d6
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
raid10 reshape clears unwanted bits from a bio->bi_flags using
a method which, while clumsy, worked until 3.10 when BIO_OWNS_VEC
was added.
Since then it clears that bit but shouldn't. This results in a
memory leak.
So change to used the approved method of clearing unwanted bits.
As this causes a memory leak which can consume all of memory
the fix is suitable for -stable.
Fixes: a38352e0ac02dbbd4fa464dc22d1352b5fbd06fd
Cc: stable@vger.kernel.org (v3.10+)
Reported-by: mdraid.pkoch@dfgh.net (Peter Koch)
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Check for the ->map and not the ->unmap pointer.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Crucial M550 may cause data corruption on queued trims and is
blacklisted. The pattern used for it fails to match 1TB one as the
capacity section will be four chars instead of three. Widen the
pattern.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Charles Reiss <woggling@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81071
Cc: stable@vger.kernel.org
|
|
It isn't necessary for command streams generated by the kernel (at least
not while we aren't storing ring or indirect buffers in VRAM).
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Instead of hard coding the value properly document
that this is an userspace interface.
No intended functional change.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD->DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Note that runtime suspend doesn't have the same problem, since there the
RPM ref held by VDD provides already the needed serialization.
v2:
- add note to commit message about the runtime suspend path (Ville)
- use edp_panel_vdd_off_sync(), so we can keep the WARN in
edp_panel_vdd_off() (Ville)
v3:
- rebased on -fixes (for_each_intel_encoder()->list_for_each_entry())
(Imre)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Cc: stable@vger.kernel.org (3.16+)
[Jani: fix sparse warning reported by Fengguang Wu]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref itself provides for the needed serialization.
v2:
- fix the order of canceling dig_port_work wrt. hotplug_work (Ville)
- zero out {long,short}_hpd_port_mask and hpd_event_bits for speed
(Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.
Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.
v2-3:
- unchanged
v4:
- use proper API for changing the expiration time for an already pending
delayed work (Jani)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: stable@vger.kernel.org (3.16+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
scc_bus_softreset not necessarily should return zero.
Propagate the error code.
Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
|
|
radeon fixes for 3.17, kind of all over the place (dpm, GPUVM, etc.)
* 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: Remove duplicate include from Makefile
drm/radeon/dpm: select the appropriate vce power state for KV/KB/ML
drm/radeon: Add ability to get and change dpm state when radeon PX card is turned off
drm/radeon: Add missing lines to ci_set_thermal_temperature_range
drm/radeon: Always flush VM again on < CIK
drm/radeon: add a check for allocation failure (v2)
drm/radeon: use pfp for all vm_flush related updates
drm/radeon: add bapm module parameter
|
|
My static checker complains that the ">" should be ">=" or else we go
beyond the end of the cb->irq_map[] array on the next line.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
This is only really needed for gic_write_sgi1r in the !SMP case since it
is only referenced in the SMP initialisation code but it seems better to
have these functions all next to each other and declared consistently.
Signed-off-by: Mark Brown <broonie@linaro.org>
Link: https://lkml.kernel.org/r/1406748194-21094-1-git-send-email-broonie@kernel.org
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
When multiple devices are detached in __detach_device, they
are also removed from the domains dev_list. This makes it
unsafe to use list_for_each_entry_safe, as the next pointer
might also not be in the list anymore after __detach_device
returns. So just repeatedly remove the first element of the
list until it is empty.
Cc: stable@vger.kernel.org
Tested-by: Marti Raudsepp <marti@juffo.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
When the BUS_NOTIFY_DEL_DEVICE event is received the device
might still be attached to a driver. In this case the domain
can't be released as the mappings might still be in use.
Defer the domain removal in this case until we receivce the
BUS_NOTIFY_UNBOUND_DRIVER event.
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: stable@vger.kernel.org # v3.15, v3.16
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Added support to the ftdi_sio driver for ekey Converter USB which
uses an FT232BM chip.
Signed-off-by: Jaša Bartelj <jasa.bartelj@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This adds a new device id to the pl2303 driver for the ZTEK device.
Reported-by: Mike Chu <Mike-Chu@prolific.com.tw>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add device id for Basic Micro ATOM Nano USB2Serial adapters.
Reported-by: Nicolas Alt <n.alt@mytum.de>
Tested-by: Nicolas Alt <n.alt@mytum.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Remove dublicate Qualcom PID 0x3197 which is already handled by the
moto-modem driver since commit 6986a978eec7 ("USB: add new moto_modem
driver for some Morotola phones").
Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Remove dublicate Gobi PID 0x9008 which is already handled by the
qcserial driver since commit f05932c0caf4 ("USB: qcserial: Add extra
device IDs").
Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This reverts commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE
CDMA devices to zte_ev").
Move the IDs of the devices that were previously driven by the option
driver back to that driver.
As several users have reported, the zte_ev driver is causing random
disconnects as well as reconnect failures.
A closer analysis of the zte_ev setup code reveals that it consists of
standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE)
but unfortunately fails to get some of those right. In particular, as
reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears
that the control requests lack the interface argument.
Note that the zte_ev driver is based on code (once) distributed by ZTE
that still appears to originally have been reverse-engineered and bolted
onto the generic driver.
Since line control is already handled properly by the option driver, and
the SET/GET_LINE_CODING requests appears to be redundant (amounts to a
SET 9600 8N1), this is a first step in ultimately removing the redundant
zte_ev driver.
Note that AC2726 had already been moved back to option, and that some
IDs were in the device table of both drivers prior to the commit being
reverted.
Reported-by: Lei Liu <liu.lei78@zte.com.cn>
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This VIA Telecom baseband processor is used is used by by u-blox in both the
FW2770 and FW2760 products and may be used in others as well.
This patch has been tested on both of these modem versions.
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Do not log normal interrupt-urb shutdowns as errors.
The option driver has always been logging any nonzero interrupt-urb
status as an error, including when the urb is killed during normal
operation.
Commit 9096f1fbba91 ("USB: usb_wwan: fix potential NULL-deref at
resume") moved the interrupt urb submission from port probe and release
to open and close, thus potentially increasing the number of these
false-positive error messages dramatically.
Reported-by: Ed Butler <ressy66@ausics.net>
Tested-by: Ed Butler <ressy66@ausics.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
If pwm_get() finds a look-up entry with a perfect match (both dev_id and
con_id match), the loop is aborted, and "p" still points to the correct
struct pwm_lookup.
If only an entry with a matching dev_id or con_id is found, the loop
terminates after traversing the whole list, and "p" now points to
arbitrary memory, not part of the pwm_lookup list.
Then pwm_set_period() and pwm_set_polarity() will set random values for
period resp. polarity.
To fix this, save period and polarity when finding a new best match,
just like is done for chip (for the provider) and index.
This fixes the LCD backlight on r8a7740/armadillo-legacy, which was fed
period 0 and polarity -1068821144 instead of 33333 resp. 1.
Fixes: 3796ce1d4d4b ("pwm: add period and polarity to struct pwm_lookup")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Make sure the cursor gets fully clipped when enabling it on a disabled
crtc via setplane. This will prevent the lower level code from
attempting to enable the cursor in hardware.
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
During suspend we turn off the crtcs, but leave the staged config in
place so that we can restore the display(s) to their previous state on
resume.
During resume when we attempt to apply the force pipe A quirk we use the
load detect mechanism. That doesn't check whether there was an already
staged configuration for the crtc since that's not even possible during
normal runtime load detection. But during resume it is possible, and if
we just blindly go and overwrite the staged crtc configuration for the
load detection we can no longer restore the display to the correct
state.
Even worse, we don't even clear all the staged connector->encoder->crtc
links so we may end up using a cloned setup for the load detection, and
after we're done we just clear the links related to the VGA output
leaving the links for the other outputs in place. This will eventually
result in calling intel_set_mode() with mode==NULL but with valid
connector->encoder->crtc links which will result in dereferencing the
NULL mode since the code thinks it will have to a modeset.
To avoid these problems don't use any crtc with new_enabled==true for
load detection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (for 3.16)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_enable_pipe_a() gets called with all the modeset locks already
held (by drm_modeset_lock_all()), so trying to grab the same
locks using another drm_modeset_acquire_ctx is going to fail miserably.
Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
out from intel_{get,release}_load_detect_pipe() into the callers
(intel_{crt,tv}_detect()). Only the actual locking and backoff
handling is left in intel_get_load_detect_pipe(). And in
intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
drm_modeset_lock_all() which is already holding all the relevant locks.
It's perfectly legal to lock the same ww_mutex multiple times using the
same ww_acquire_ctx. drm_modeset_lock() will convert the returned
-EALREADY into 0, so the caller doesn't need to do antyhing special.
Fixes a hang on resume on my 830.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
During recovery of a double-degraded RAID6 it is possible for
some blocks not to be recovered properly, leading to corruption.
If a write happens to one block in a stripe that would be written to a
missing device, and at the same time that stripe is recovering data
to the other missing device, then that recovered data may not be written.
This patch skips, in the double-degraded case, an optimisation that is
only safe for single-degraded arrays.
Bug was introduced in 2.6.32 and fix is suitable for any kernel since
then. In an older kernel with separate handle_stripe5() and
handle_stripe6() functions the patch must change handle_stripe6().
Cc: stable@vger.kernel.org (2.6.32+)
Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8
Cc: Yuri Tikhonov <yur@emcraft.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reported-by: "Manibalan P" <pmanibalan@amiindia.co.in>
Tested-by: "Manibalan P" <pmanibalan@amiindia.co.in>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
|
|
If a stripe in a raid6 array received a write to each data block while
the array is degraded, and if any of these writes to a missing device
are not page-aligned, then a live-lock happens.
In this case the P and Q blocks need to be read so that the part of
the missing block which is *not* being updated by the write can be
constructed. Due to a logic error, these blocks are not loaded, so
the update cannot proceed and the stripe is 'handled' repeatedly in an
infinite loop.
This bug is unlikely as most writes are page aligned. However as it
can lead to a livelock it is suitable for -stable. It was introduced
in 3.16.
Cc: stable@vger.kernel.org (v3.16)
Fixed: 67f455486d2ea20b2d94d6adf5b9b783d079e321
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
We get the following error when built as a module. Though the general fix
would be in this case to export the below mentioned symbols, considering
that dw_pcie_host_init() is marked with __init and other PCI drivers do not
support modular build, I have disabled building this driver as a module
too.
ERROR: "dw_pcie_host_init" [drivers/pci/host/pcie-spear13xx.ko] undefined!
ERROR: "dw_handle_msi_irq" [drivers/pci/host/pcie-spear13xx.ko] undefined!
ERROR: "dw_pcie_msi_init" [drivers/pci/host/pcie-spear13xx.ko] undefined!
ERROR: "dw_pcie_cfg_write" [drivers/pci/host/pcie-spear13xx.ko] undefined!
ERROR: "dw_pcie_cfg_read" [drivers/pci/host/pcie-spear13xx.ko] undefined!
ERROR: "dw_pcie_setup_rc" [drivers/pci/host/pcie-spear13xx.ko] undefined!
ERROR: "dw_pcie_link_up" [drivers/pci/host/pcie-spear13xx.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
If building with CONFIG_SMP disbled (for example, with allnoconfig) then
GCC complains that the static function gic_peek_irq() is defined but not
used since the only reference is in the SMP initialisation code. Fix this
by moving the function definition inside the ifdef.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1406480224-24628-1-git-send-email-broonie@kernel.org
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
The prefix suggests the number should be printed in hex, so use
the %x specifier to do that.
Found by using regex suggested by Joe Perches.
Signed-off-by: Hans Wennborg <hans@hanshq.net>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
pctldev can't be NULL at this stage so remove the check
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
There is a cut and paste bug so we test the wrong variable. "err" is
never less than zero at this point.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This shoudld be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
Fixes: dc0a39386687 ('pinctrl: Add NVIDIA Tegra XUSB pad controller support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
On rk3288, for gpio bank 0, the registers which configure pull-up,
iomux, and drive strength don't implement the enable bits in the upper
half of the register, unlike the other gpio configuration registers,
and so the kernel must perform a read-modify-write of the register to
update a particular gpio in that bank.
The current code is actually clobbering the contents of the register,
so this fixes it by using regmap_update_bits and masking out only the
bits which require updating. In the case of bank0 on rk3288 the upper
enable bits will just get ignored, and the other configurations won't
get clobbered.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
I had made last-minute changes before submitting the patch "sh-pfc: r8a7791:
add CAN pin groups"; now I'm seeing that they weren't complete: I had missed
update to the pin group names in pin[01]_groups[]. Drop the "_a" suffixes there.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Memory allocated by kstrdup should be freed.
CC: Brian Swetland <swetland@google.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Seunghun Lee <waydi1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
null-terminate after strncpy call
Added a guaranteed null-terminate after call to strncpy.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Of_node_put supports NULL as its argument, so the initial test is not
necessary.
Suggested by Uwe Kleine-König.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
@@
-if (e)
of_node_put(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The Zynq GPIO interrupt handling code as two main issues:
1) It does not support IRQF_ONESHOT interrupt since it uses handle_simple_irq()
for the interrupt handler. handle_simple_irq() does not do masking and unmasking
of the IRQ that is required for this chip to be able to support IRQF_ONESHOT
IRQs, causing the CPU to lock up in a interrupt storm if such a interrupt is
requested.
2) Interrupts are acked after the primary interrupt handlers for all asserted
interrupts in a bank have been called. For edge triggered interrupt this is to
late and may cause a interrupt to be missed. For level triggered oneshot
interrupts this is to early and causes the interrupt handler to run twice per
interrupt.
This patch addresses the issue by updating the driver to use the correct IRQ
chip handler functions that are appropriate for this kind of IRQ controller.
The following diagram gives an overview of how the interrupt detection circuit
works, it is not necessarily a accurate depiction of the real hardware though.
INT_POL/INT_ON_ANY
|
| +---+ INT_STATUS
`-| | |
| E |-. |
,---| | \ |\ +----+ | +---+
| +---+ `----| | ,-------|S | ,*--| |
GPIO_IN -* | |- | Q|- | & |-- IRQ_OUT
| +---+ ,-----| | ,-|R | ,o| |
`---| | / |/ | +----+ | +---+
| = |- | | |
,-| | INT_TYPE ACK INT_MASK
| +---+
|
INT_POL
GPIO_IN is the raw signal level connected to the hardware pin. This signal is
routed to a edge detector and to a level detector. The edge detector can be
configured to either detect a rising or falling edge or both edges. The level
detector can detect either a level high or level low event. Depending on the
setting of the INT_TYPE register either the edge or level event will be
propagated to the INT_STATUS register. As long as a interrupt condition is
detected the INT_STATUS register will be set to 1. It can be cleared to 0 if
(and only if) the interrupt condition is no longer detected and software
acknowledges the interrupt by writing a 1 to the address of the INT_STATUS
register. There is also the INT_MASK register which can be used to disable the
propagation of the INT_STATUS signal to the upstream IRQ controller. What is
important to note is that the interrupt detection logic itself can not be
disabled, only the propagation of the INT_STATUS register can be delayed. This
means that for level type interrupts the interrupt must only be acknowledged
after the interrupt source has been cleared otherwise it will stay asserted and
the interrupt handler will be run a second time. For IRQF_ONESHOT interrupts
this means that the IRQ must only be acknowledged after the threaded interrupt
has finished running. If a second interrupt comes in between handling the first
interrupt and acknowledging it the external interrupt will be asserted, which
means trying to acknowledge the first interrupt will not clear the INT_STATUS
register and the interrupt handler will be run a second time when the IRQ is
unmasked, so no interrupts will be lost. The handle_fasteoi_irq() handler in
combination with the IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED flags will
have the desired behavior. For edge triggered interrupts a slightly different
strategy is necessary. For edge triggered interrupts the interrupt condition is
only true when the edge itself is detected, this means this is the only time the
INT_STATUS register is set, acknowledging the interrupt any time after that will
clear the INT_STATUS register until the next interrupt happens. This means in
order to not loose any interrupts the interrupt needs to be acknowledged before
running the interrupt handler. If a second interrupt occurs after the first
interrupt handler has finished but before the interrupt is unmasked the
INT_STATUS register will be re-asserted and the interrupt handler runs a second
time once the interrupt is unmasked. This means with this flow handling strategy
no interrupts are lost for edge triggered interrupts. The handle_level_irq()
handler will have the desired behavior. (Note: The handle_edge_irq() only needs
to be used for edge triggered interrupts where the controller stops detecting
the interrupt event when the interrupt is masked, for this controller the
detection logic still works, while only the propagation is delayed when the
interrupt is masked.)
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Correct typo in the name of the type given to sizeof. Because it is the
size of a pointer that is wanted, the typo has no impact on compilation or
execution.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The
semantic patch used can be found in message 0 of this patch series.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
initialisation
Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed
before it is initialised, by:
- letting et131x_mii_write() take a phydev address, instead of using the one
stored in adapter by default. This is so et131x_mdio_write() can use it's own
addr value.
- removing implementation of et131x_mdio_reset(), as it's not needed.
- moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses
phydev->addr, until after the mdiobus has been registered.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121
Cc: stable@vger.kernel.org
Signed-off-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The following patch fixes a build error on sparc32. I think it should go to
stable 3.16.
Remove a circular dependency on atomic.h header file which leads to compilation
failure on sparc32 as reported here:
http://kisskb.ellerman.id.au/kisskb/buildresult/11340509/
The specific dependency is as follows:
In file included from arch/sparc/include/asm/smp_32.h:24:0,
from arch/sparc/include/asm/smp.h:6,
from arch/sparc/include/asm/switch_to_32.h:4,
from arch/sparc/include/asm/switch_to.h:6,
from arch/sparc/include/asm/ptrace.h:84,
from arch/sparc/include/asm/processor_32.h:16,
from arch/sparc/include/asm/processor.h:6,
from arch/sparc/include/asm/barrier_32.h:4,
from arch/sparc/include/asm/barrier.h:6,
from arch/sparc/include/asm/atomic_32.h:17,
from arch/sparc/include/asm/atomic.h:6,
from drivers/staging/lustre/lustre/obdclass/class_obd.c:38
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Before this patch, the driver included <linux/tegra-powergate.h>,
which was effectively renamed to <soc/tegra/pmc.h> at about the same
time the ahci_tegra series landed. Fix the include path so that the
driver compiles.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Change return type to signed int since it could be
a negative errno.
Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
