There are two functions that do a bunch of 'free_irq' on
the per_cpu IRQ. Instead of having duplicate code just move
it to one function.
This is just code movement.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fix to return -ENOENT in the pcistub_device_find() and pci_get_drvdata()
error handling case instead of 0(overwrite to 0 by str_to_slot()), as done
elsewhere in this function.
Acked-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
With the introduction of ACPI scan handlers, ACPI device objects
with an ACPI scan handler attached to them must not be bound to
by ACPI drivers any more. Unfortunately, however, the ACPI video
driver attempts to do just that if there is a _ROM ACPI control
method defined under a device object with an ACPI scan handler.
Prevent that from happening by making the video driver's "add"
routine check if the device object already has an ACPI scan handler
attached to it and return an error code in that case.
That is not sufficient, though, because acpi_bus_driver_init() would
then clear the device object's driver_data that may be set by its
scan handler, so for the fix to work acpi_bus_driver_init() has to be
modified to leave driver_data as is on errors.
References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Bisected-and-tested-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
Reported-and-tested-by: Jason Cassell <bluesloth600@gmail.com>
Tracked-down-by: Aaron Lu <aaron.lu@intel.com>
Cc: 3.9+ <stable@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
This patch increases the amount of output produced by the
irq_domain_mapping debugfs file by first listing all of the registered
irq domains at the beginning of the output, and then by including all
mapped IRQs in the output, not just the active ones. It is very useful
when debugging irqdomain issues to be able to see the entire list of
mapped irqs, not just the ones that happen to be connected to devices.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
After refactoring the irqdomain code, there are a number of API
functions that are merely empty wrappers around core code. Drop those
wrappers out of the C file and replace them with static inlines in the
header.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
The NOMAP irq_domain type is only used by a handful of interrupt
controllers and it unnecessarily complicates the code by adding special
cases on how to look up mappings and different revmap functions are used
for each type which need to validate the correct type is passed to it
before performing the reverse map. Eliminating the revmap_type and
making a single reverse mapping function simplifies the code. It also
shouldn't be any slower than having separate revmap functions because
the type of the revmap needed to be checked anyway.
The linear and tree revmap types were already merged in a previous
patch. This patch rolls the NOMAP or direct mapping behaviour into the
same domain code making is possible for an irq domain to do any mapping
type; linear, tree or direct; and that the mapping will be transparent
to the interrupt controller driver.
With this change, direct mappings will get stored in the linear or tree
mapping for consistency. Reverse mapping from the hwirq to virq will go
through the normal lookup process. However, any controller using a
direct mapping can take advantage of knowing that hwirq==virq for any
mapped interrupts skip doing a revmap lookup when handling IRQs.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Keeping them separate makes irq_domain more complex and adds a lot of
code (as proven by the diffstat). Merging them simplifies the whole
scheme. This change makes it so both the tree and linear methods can be
used by the same irq_domain instance. If the hwirq is less than the
->linear_size, then the linear map is used to reverse map the hwirq.
Otherwise the radix tree is used. The test for which map to use is no
more expensive that the existing code, so the performance of fast path
is preserved.
It also means that complex interrupt controllers can use both the
linear map and a tree in the same domain. This may be useful for an
interrupt controller with a base set of core irqs and a large number
of GPIOs which might be used as irqs. The linear map could cover the
core irqs, and the tree used for thas irqs. The linear map could
cover the core irqs, and the tree used for the gpios.
v2: Drop reorganization of revmap data
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rob Herring <rob.herring@calxeda.com>
This patch adds a name field to the irq_domain structure to help mere
mortals understand the mappings between irq domains and virqs. It also
converts a number of places that have open-coded some kind of fudging
an irqdomain name to use the new field. This means a more consistent
display of names in irq domain log messages and debugfs output.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
The LEGACY mapping unnecessarily complicates the irqdomain code and
can easily be implemented with a linear mapping. By ripping it out
and replacing it with the LINEAR mapping the object size of
irqdomain.c shrinks by about 330 bytes (ARMv7) which offsets the
additional allocation required by the linear map. It also makes it
possible for current LEGACY map users to pre-allocate irq_descs for a
subset of the hwirqs and dynamically allocate the rest as needed.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rob Herring <rob.herring@calxeda.com>
Commit 98aa468e, "irqdomain: Support for static IRQ mapping and
association" introduced an API for directly associating blocks of hwirqs
to linux irqs. However, if any irq in that block failed to map (say if
the mapping functions returns an error because the irq is already
mapped) then the whole thing will fail and roll back. This is probably
too aggressive since there are valid reasons why a mapping may fail.
ie. Firmware may have a particular IRQ marked as unusable.
This patch drops the error path out of irq_domain_associate(). If a
mapping fails, then it is simply skipped. There is no reason to fail the
entire allocation.
v2: Still output an information message on failed mappings and make sure
attempted mapping gets cleared out of the irq_data structure.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
The allocated object should be the size of what the pointer is pointing
to and not the size of the pointer itself.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
'!' has higher precedence than comparisons so the original condition
is equivalent to "if (xspi->remaining_bytes == 0)". This makes the
static checkers complain.
xspi->remaining_bytes is signed and from looking at the code
briefly, I think it might be able to go negative. I suspect that
going negative may cause a bug, but I don't have the hardware and
can't test.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
On a mx6qsabrelite board the following error happens on probe:
sgtl5000: probe of 0-000a failed with error -5
imx-sgtl5000 sound.13: ASoC: CODEC (null) not registered
imx-sgtl5000 sound.13: snd_soc_register_card failed (-517)
platform sound.13: Driver imx-sgtl5000 requests probe defer
Prior to reading the codec ID we need to turn the SYS_MCLK clock, so let's
enable the codec clock inside sgtl5000_i2c_probe().
Also remove the codec clock enable/disable functions from the machine driver.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
As we discussed in mailing list, non-DT for EXYNOS SoCs will not be
supported from v3.11. This patch removes regarding files for non-DT
including board files and defconfig.
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
ODROID-X board have a max77686 PMIC on i2c channel 0. The properties of used
LDO and BUCK are defined according the schematic.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
RTC is a basic feature of EXYNOS5440. But it was disabled
by issue that comes from EXYNOS5250. (commit id: 522ccdb6)
That issue only applies to EXYNOS5250 not EXYNOS5440. So,
there is no issue with enabled RTC on EXYNOS5440. This
change was tested on EXYNOS5440.
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Adds clock provider information for DP controller required by CCF.
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add DT node for DP controller to exynos5250 based Arndale Board
Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
These nodes have separately been added to 4212 and 4412 dtsi
files by commit 30269ddff1 ("ARM: exynos: add missing properties
for combiner IRQs"). The existing node also contained a few
incorrect entries.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add max8997 regulator device node for exynos4210-origen board and list
all the supported regulators.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Tested-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Added keypad node entries to Exynos4412 based Origen board DT file.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Keypad pins/lines are board specific and should be added to respective
board dts files.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Adding DWC3 device tree node for Exynos5250 needed to
parse device tree data.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Document device tree binding information as required by the
Samsung' USB 3.0 controller.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Adding usb3.0 phy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
In
commit 53d3b4d777
Author: Egbert Eich <eich@suse.de>
Date: Tue Jun 4 17:13:21 2013 +0200
drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
Egbert Eich fixed a long-standing bug where we simply used a
non-working i2c controller to read the EDID for SDVO-LVDS panels.
Unfortunately some machines seem to not be able to cope with the mode
provided in the EDID. Specifically they seem to not be able to cope
with a 4x pixel mutliplier instead of a 2x one, which seems to have
been worked around by slightly changing the panels native mode in the
VBT so that the dotclock is just barely above 50MHz.
Since it took forever to notice the breakage it's fairly safe to
assume that at least for SDVO-LVDS panels the VBT contains fairly sane
data. So just switch around the order and use VBT modes first.
v2: Also add EDID modes just in case, and spell Egbert correctly.
v3: Elaborate a bit more about what's going on on Chris' machine.
Cc: Egbert Eich <eich@suse.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
Cc: stable@vger.kernel.org
Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hotplug_mask is no longer used as the hpd interrupt setup is now
handled in the core.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
sdvo->hotplug_active is initialised during intel_sdvo_setup_outputs(),
and so we never enabled the hotplug interrupts on SDVO as we were
checking too early.
This regression has been introduced somewhere in the hpd rework for
the storm detection and handling starting with
commit 1d843f9de4
Author: Egbert Eich <eich@suse.de>
Date: Mon Feb 25 12:06:49 2013 -0500
DRM/I915: Add enum hpd_pin to intel_encoder.
and the follow-up patches to use the new encoder->hpd_pin variable for
the different irq setup functions.
The problem is that encoder->hpd_pin was set up _before_ the output
setup was done and so before we could assess the hotplug capabilities
of the outputs on an sdvo encoder.
Reported-by: Alex Fiestas <afiestas@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A broken conditional would lead to SDVOC waiting upon hotplug events on
SDVOB - and so miss all activity on its SDVO port.
This regression has been introduced in
commit 1d843f9de4
Author: Egbert Eich <eich@suse.de>
Date: Mon Feb 25 12:06:49 2013 -0500
DRM/I915: Add enum hpd_pin to intel_encoder.
References: https://bugs.freedesktop.org/show_bug.cgi?id=58405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bridge loop avoidance has a hook to handle address updates of the
originator. These should not be handled when bridge loop avoidance is
disabled - it might send some bridge loop avoidance packets which should
not appear if bla is disabled.
Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
When a packet is received from another node first and later from the
best next hop, this packet is dropped. However the first OGM was sent
with the BATADV_NOT_BEST_NEXT_HOP flag and thus dropped by neighbors.
The late OGM from the best neighbor is then dropped because it is a
duplicate.
If this situation happens constantly, a node might end up not forwarding
the "valid" OGMs anymore, and nodes behind will starve from not getting
valid OGMs.
Fix this by refining the duplicate checking behaviour: The actions
should depend on whether it was a duplicate for a neighbor only or for
the originator. OGMs which are not duplicates for a specific neighbor
will now be considered in batadv_iv_ogm_forward(), but only actually
forwarded for the best next hop. Therefore, late OGMs from the best
next hop are forwarded now and not dropped as duplicates anymore.
Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
The rtnl_lock in batadv_store_mesh_iface has been converted to a rtnl_trylock
some time ago to avoid a possible deadlock between rtnl and s_active on removal
of the sysfs nodes.
The behaviour introduced by that was quite confusing as it could lead to the
sysfs store to fail, making batman-adv setup scripts unreliable. As recently the
sysfs removal was postponed to a worker not running with the rtnl taken, the
deadlock can't occur any more and it is safe to change the trylock back to a
lock to make the sysfs store reliable again.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Reviewed-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
If userspace requests current KEY-state, they very likely assume that no
such events are pending in the output queue of the evdev device.
Otherwise, they will parse events which they already handled via
EVIOCGKEY(). For XKB applications this can cause irreversible keyboard
states if a modifier is locked multiple times because a CTRL-DOWN event is
handled once via EVIOCGKEY() and once from the queue via read(), even
though it should handle it only once.
Therefore, lets do the only logical thing and flush the evdev queue
atomically during this ioctl. We only flush events that are affected by
the given ioctl.
This only affects boolean events like KEY, SND, SW and LED. ABS, REL and
others are not affected as duplicate events can be handled gracefully by
user-space.
Note: This actually breaks semantics of the evdev ABI. However,
investigations showed that userspace already expects the new semantics and
we end up fixing at least all XKB applications.
All applications that are aware of this race-condition mirror the KEY
state for each open-file and detect/drop duplicate events. Hence, they do
not care whether duplicates are posted or not and work fine with this fix.
Also note that we need proper locking to guarantee atomicity and avoid
dead-locks. event_lock must be locked before queue_lock (see input-core).
However, we can safely release event_lock while flushing the queue. This
allows the input-core to proceed with pending events and only stop if it
needs our queue_lock to post new events.
This should guarantee that we don't block event-dispatching for too long
while flushing a single event queue.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
As part of the transition to DT, no board files will be used
for OMAP5. The hwmod data is gradually being transitioned
away from arch/arm/mach-omap2: IRQ, DMA, and memory map data
has been moved to DT. Hopefully the dev_attr and clock role
data will be the next step.
Basic test logs are available here, although not for OMAP5,
since I don't have an OMAP5 board:
http://www.pwsan.com/omap/testlogs/omap5_v3.10/20130608130949/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRs41aAAoJEMePsQ0LvSpLdqgP/REPum/zLgTkFF7WRFXGN/A5
Wmyb26qgoeOsc+0NAQEiTEVsddv4VJYRAShtrSL3S3aOIgNwo5b576hF3VKTObel
+nTl18ID8Ylqv1cfTFkcNgQoRXfELBP4HvbjgKjvVda73A6jy4NOt6NtP7aRW8Wk
nPIzdExv0T6g6+PT/lQ0WwO3C2vrQ4EmRQsKus+DmSXfpnGEJZpE9ql0w298nH/2
eQoi1zt804wx+h1i/vnXKj2VyjXC+jPh2cRotr8vqfiLNMhfV0aCZ33UrXPwKz69
E7gJyIqLBAI8QTiwJ6jRM+M+1nQ44XBAcMiDkCz4Yg6GLrVsLh7sE/BR8nZkc7tS
rA9mlW0kT2nd/AH9s6gtUE1C+SsX27tnovjmpjAYXAFJkgTkjD+cQh7ex5oKLIVb
LIkdsQdW610ZM9IAlnxAL3SW9te61wTWeFbIdvWPSHbBxZzOPVMLM+t4VncRE9m0
YzaD/IGdOC+RCQBQp8JRCbJQMNkNdwXGT4GSHWsMl3pwbQDoWrdyNJGXSIUDhHWs
G5Y4Ca0zBdBycnmhSR9aFe9FAmWB2K3GMg1ICdk3+WP5tNvOHlHt2ndkFbBW6UfY
53o31B0HXV1XSyORPfbUTcmQzieP8YFxJRtOKaDYZnoQVh9SXdUSU5dENZDZ4K8Z
RceJOyILgj86qIKr7hnM
=2r+V
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-a-for-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.11/omap5
Add support for the OMAP5 SoC family.
As part of the transition to DT, no board files will be used
for OMAP5. The hwmod data is gradually being transitioned
away from arch/arm/mach-omap2: IRQ, DMA, and memory map data
has been moved to DT. Hopefully the dev_attr and clock role
data will be the next step.
Basic test logs are available here, although not for OMAP5,
since I don't have an OMAP5 board:
http://www.pwsan.com/omap/testlogs/omap5_v3.10/20130608130949/
