Age | Commit message (Collapse) | Author |
|
The driver handles wakeup irq correctly using irq_set_irq_wake. There's
no need to use IRQF_NO_SUSPEND while registering the interrupt.
This patch removes the use of IRQF_NO_SUSPEND flag.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
This patch solves:
on x86_64:
when CONFIG_ACPI is not enabled:
../drivers/mfd/intel_soc_pmic_bxtwc.c: In function 'bxtwc_probe':
../drivers/mfd/intel_soc_pmic_bxtwc.c:342:2:
error: implicit declaration of function 'acpi_evaluate_integer' [-Werror=implicit-function-declaration]
status = acpi_evaluate_integer(handle, "_HRV", NULL, &hrv);
^
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Some EC implementations include a small nvram space used to store
verified boot context data. This boolean property lets us indicate
whether this space is available or not on a specific EC implementation.
Signed-off-by: Emilio López <emilio.lopez@collabora.co.uk>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
The lpc_ich_cells array gives the wrong impression about the
relationship between the watchdog and GPIO devices. They are
completely distinct devices, so this patch separates the
array into distinct mfd_cell structs per device.
A side effect of removing the array, is that the lpc_cells enum
is no longer needed.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Add MFD core driver for Intel Broxton Whiskey Cove PMIC,
which is specially accessed by hardware IPC, not a generic
I2C device
Signed-off-by: Qipeng Zha <qipeng.zha@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
IRQ control registers of Intel Broxton Whisky Cove PMIC are
separated in two parts, so add secondary IRQ chip.
And the new member of device will be used in PMC IPC regmap APIs.
Signed-off-by: Qipeng Zha <qipeng.zha@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
no need to initialise static variable with 0, hence correcting it.
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
This worked before the dw-hdmi bridge code was changed to validate
the setup data more strictly. Add back support for modes with a
pixel clock up to 216MHz. Even higher clocks should work, but we
are missing the required setup data for now.
Also change the mode validate callbacks to disallow modes with
higher pixelclocks, so we don't end up failing the modeset later
on.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The variable can be negative.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Enable the MEDIA_BUS_FMT_Y8_1X8 format.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch allows to use the ARGB4444 color format on planes.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch adds support for the ARGB4444 color format.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch allows to use the RGBX and RGBA 8:8:8:8 formats.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch adds support for the RGBA8888, RGBX8888, BGRA8888, and
BGRX8888 in-memory formats.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch enables the ARGB1555, ABGR1555, RGBA5551,
and BGRA5551 formats to be used on planes.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch adds support for ARGB1555, ABGR1555, RGBA5551, and BGRA5551
in-memory formats.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The ipu-v3 core driver is maintained in and merged through
the same trees as the imx-drm drivers that are using it.
This patch adds the drivers/gpu/ipu-v3/ directory to the
i.MX DRM driver section.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Bool initializations should use true and false. Bool tests don't need
comparisons. Based on contributions from Joe Perches, Rusty Russell
and Bruce W Allan.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/boolinit.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Make sure that the task scheduler domain hierarchy is set-up correctly
on systems with single or multi-cluster topology.
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Now that we added special handling to the C files in libstub, move
the one remaining arm64 specific EFI stub C file to libstub as
well, so that it gets the same treatment. This should prevent future
changes from resulting in binaries that may execute incorrectly in
UEFI context.
With efi-entry.S the only remaining EFI stub source file under
arch/arm64, we can also simplify the Makefile logic somewhat.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
This was introduced by mistake in commit 0f7d9052fb70 ("drm/tegra: Use
new drm_fb_helper functions"). Remove it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Use devm_ioremap_resource() in order to make the code simpler,
and remove redundant return value check of platform_get_resource()
because this value is alreadytaken care by devm_ioremap_resource()
Signed-off-by: Sanjeev Sharma <sanjeev_sharma@mentor.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
|
|
NCT6792 and NCT6793 are mostly register compatible to NCT6791, but
temperature sources are different and difficult to manage with a single
temperature label array. Introduce separate temperature label arrays
for those chips to reflect the differences.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Both NCT6791D and NCT6792D permit selection of a 'virtual' temperature
register as temperature source. The virtual temperature registers are
registers 0xea to 0xef in bank 0 and can be written by software.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The sizeof() is invoked on an incorrect variable, likely due to some
copy-paste error, and this might result in memory corruption. Fix this.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: netdev@vger.kernel.org
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Fix I/O offset for multiple host bridges.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
|
|
On ARM64, setting the root bus number to -1 causes probe failure.
Moreover, we should use the bus number specified in the DT as we could have
multiple PCIe controllers with different bus ranges.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The R-Car PCIe host controller driver uses pci_common_init_dev(), which is
ARM-specific and requires the ARM struct hw_pci. The part of
pci_common_init_dev() that is needed is limited and can be done here
without using hw_pci.
Note that the ARM pcibios functions expect the PCI sysdata to be a pointer
to a struct pci_sys_data. Add a struct pci_sys_data as the first element
in struct gen_pci so that when we use a gen_pci pointer as sysdata, it is
also a pointer to a struct pci_sys_data.
Create and scan the root bus directly without using the ARM
pci_common_init_dev() interface.
Based on 499733e0cc1a ("PCI: generic: Remove dependency on ARM-specific
struct hw_pci").
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Make PCI aware of the I/O resources.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The pcie-rcar.c driver (controlled by PCI_RCAR_GEN2_PCIE) uses struct
pci_sys_data and pci_ioremap_io(), which only exist on ARM. Building it on
other arches, e.g., arm64/shmobile, causes errors like this:
drivers/pci/host/pcie-rcar.c:138:52: warning: 'struct pci_sys_data' declared inside parameter list
drivers/pci/host/pcie-rcar.c:380:4: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
Build pcie-rcar.c only on ARM.
[bhelgaas: changelog, split to separate pci-rcar-gen2 from pcie-rcar]
Reported-by: Wolfram Sang <wsa@the-dreams.de> (pci_ioremap_io())
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The pci-rcar-gen2.c driver (controlled by PCI_RCAR_GEN2) uses struct
pci_sys_data, which only exists on ARM. Building it on other arches, e.g.,
arm64/shmobile, causes errors like this:
drivers/pci/host/pci-rcar-gen2.c: In function 'rcar_pci_cfg_base': drivers/pci/host/pci-rcar-gen2.c:112:34: error: dereferencing pointer to incomplete type
struct rcar_pci_priv *priv = sys->private_data;
^
Build pci-rcar-gen2.c only on ARM.
[bhelgaas: changelog, split to separate pci-rcar-gen2 from pcie-rcar]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next
Steffen Klassert says:
====================
pull request (net-next): ipsec-next 2015-10-30
1) The flow cache is limited by the flow cache limit which
depends on the number of cpus and the xfrm garbage collector
threshold which is independent of the number of cpus. This
leads to the fact that on systems with more than 16 cpus
we hit the xfrm garbage collector limit and refuse new
allocations, so new flows are dropped. On systems with 16
or less cpus, we hit the flowcache limit. In this case, we
shrink the flow cache instead of refusing new flows.
We increase the xfrm garbage collector threshold to INT_MAX
to get the same behaviour, independent of the number of cpus.
2) Fix some unaligned accesses on sparc systems.
From Sowmini Varadhan.
3) Fix some header checks in _decode_session4. We may call
pskb_may_pull with a negative value converted to unsigened
int from pskb_may_pull. This can lead to incorrect policy
lookups. We fix this by a check of the data pointer position
before we call pskb_may_pull.
4) Reload skb header pointers after calling pskb_may_pull
in _decode_session4 as this may change the pointers into
the packet.
5) Add a missing statistic counter on inner mode errors.
Please pull or let me know if there are problems.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
iwlwifi
* bug fix for TDLS
* fixes and cleanups in scan
* support of several scan plans
* improvements in FTM
* fixes in FW API
* improvements in the failure paths when the bus is dead
* other various small things here and there
ath10k
* add QCA9377 support
* fw_stats support for 10.4 firmware
ath6kl
* report antenna configuration to user space
* implement ethtool stats
ssb
* add Kconfig SSB_HOST_SOC for compiling SoC related code
* move functions specific to SoC hosted bus to separated file
* pick PCMCIA host code support from b43 driver
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
snd_cs46xx_suspend() is missing snd_pcm_suspend_all calls for pcm_rear,
pcm_center_lfe and pcm_iec958.
There's also a copy/paste bug in snd_cs46xx_pcm_iec958(), overwriting
pcm_rear in struct snd_cs46xx, leaving pcm_iec958 unused.
Fix all this to allow all channels to survive suspend/resume.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently, the Duplicate front control is enabled only for two specific
revisions of CS4294.
Enable it for all CS4294 and CS4298 codecs instead.
This fixes rear output on my VC-4620N sound card
(CS4620 + CS4298 rev.5).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fixes: 4d429c5dd ("switchdev: introduce possibility to defer obj_add/del")
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When adding vlans with multiple IFLA_BRIDGE_VLAN_INFO attrs set in AFSPEC,
we would wipe the vlan obj struct after the first IFLA_BRIDGE_VLAN_INFO.
Fix this by only clearing what's necessary on each IFLA_BRIDGE_VLAN_INFO
iteration.
Fixes: 9e8f4a54 ("switchdev: push object ID back to object structure")
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next
Samuel Ortiz says:
====================
NFC 4.4 pull request
This is the NFC pull request for 4.4.
It's a bit bigger than usual, the 3 main culprits being:
- A new driver for Intel's Fields Peak NCI chipset. In order to
support this chipset we had to export a few NCI routines and
extend the driver NCI ops to not only support proprietary
commands but also core ones.
- Support for vendor commands for both STM drivers, st-nci
and st21nfca. Those vendor commands allow to run factory tests
through the NFC netlink interface.
- New i2c and SPI support for the Marvell driver, together with
firmware download support for this driver's core.
Besides that we also have:
- A few file renames in the STM drivers, to keep the naming
consistent between drivers.
- Some improvements and fixes on the NCI HCI layer, mostly to
properly reach a secure element over a legacy HCI link.
- A few fixes for the s3fwrn5 and trf7970a drivers.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2015-10-28
Here are a some more Bluetooth patches for 4.4 which collected up during
the past week. The most important ones are from Kuba Pawlak for fixing
locking issues with SCO sockets. There's also a fix from Alexander Aring
for 6lowpan, a memleak fix from Julia Lawall for the btmrvl driver and
some cleanup patches from Marcel.
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Supplying pinmux configuration for e.g. gpio pins leads to deferred
probes because the pinctrl device is probed much later than gpio.
Move the init call to a much earlier stage so it probes before the
devices that may need it.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Tested-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Add William Breathitt Gray as the maintainer of the ACCES 104-IDIO-16
GPIO driver.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Our IRQ storm detection works when an interrupt handler returns
IRQ_NONE for thousands of consecutive interrupts in a second. It
doesn't hurt to occasionally return IRQ_NONE when the interrupt is
actually genuine.
Drivers should only be returning IRQ_HANDLED if they have actually
*done* something to stop an interrupt from happening — it doesn't just
mean "this really *was* my device".
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: davem@davemloft.net
Link: http://lkml.kernel.org/r/1446016471.3405.201.camel@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
This change makes it so that we reinitialize the interface if the MTU is
increased back above IPV6_MIN_MTU and the interface is up.
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
New features:
- Allow passing C language eBPF scriptlets via --event in all tools,
so that it gets built using clang and then pass it to the kernel via
sys_bpf(). (Wang Nan)
- Wire up the loaded ebpf object file with associated kprobes, so that
it can determine if the kprobes will be filtered or not. (Wang Nan)
User visible changes:
- Add cmd string table to decode sys_bpf first arg in 'trace'. (Arnaldo Carvalho de Melo)
- Enable printing of branch stack in 'perf script'. (Stephane Eranian)
- Pass the right file with debug info to libunwind. (Rabin Vincent)
Build Fixes:
- Make sure fixdep is built before libbpf, fixing a race. (Jiri Olsa)
- Fix libiberty feature detection. (Rabin Vincent)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Contexts may be skipped over for cleanup in situations where contention
for the adapter's table-list mutex is experienced in the presence of a
signal during the execution of the release handler.
This can lead to two known issues:
- A hang condition on remove as that path tries to wait for users to
cleanup - something that will never complete should this scenario play
out as the user has already cleaned up from their perspective.
- An Oops in the unmap_mapping_range() call that is made as part of
the user waiting mechanism that is invoked on remove when contexts
are found to still exist.
The root cause of this issue can be found in get_context() and how the
table-list mutex is acquired. As this code path is shared by several
different access points within the driver, a decision was made during
the development cycle to acquire this mutex in this location using the
interruptible version of the mutex locking service. In almost all of
the use-cases and environmental scenarios this holds up, even when the
mutex is contended. However, for critical system threads (such as the
release handler), failing to acquire the mutex and bailing with the
intention of the user being able to try again later is unacceptable.
In such a scenario, the context _must_ be derived as it is on an
irreversible path to being freed. Without being able to derive the
context, the code mistakenly assumes that it has already been freed
and proceeds to free up the underlying CXL context resources. From
this point on, any usage of [the now stale] CXL context resources
will result in undefined behavior. This is root cause of the Oops
mentioned as the second known issue as the mapping passed to the
unmap_mapping_range() service is owned by the CXL context.
To fix this problem, acquisition of the table-list mutex within
get_context() is simply changed to use the uninterruptible version
of the mutex locking service. This is safe as the timing windows for
holding this mutex are short and also protected against blocking.
Signed-off-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Acked-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
When running with lock instrumentation (e.g. lockdep), some of the
instrumentation can become disabled at probe time for a cxlflash
adapter. This is due to a missing lock registration for the tmf_slock.
The fix is to call spin_lock_init() for the tmf_slock during probe.
Signed-off-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Acked-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
The port selection mask of a LUN can be corrupted when the manage LUN
ioctl (DK_CXLFLASH_MANAGE_LUN) is issued more than once for any device.
This mask indicates to the AFU which port[s] can be used for a data
transfer to/from a particular LUN. The mask is critical to ensuring the
correct behavior when using the virtual LUN function of this adapter.
When the mask is configured for both ports, an I/O may be sent to either
port as the AFU assumes that each port has access to the same physical
device (specified by LUN ID in the port LUN table).
In a situation where the mask becomes incorrectly configured to reflect
access to both ports when in fact there is only access through a single
port, an I/O can be targeted to the wrong physical device. This can lead
to data corruption among other ill effects (e.g. security leaks).
The cause for this corruption is the assumption that the ioctl will only
be called a second time for a LUN when it is being configured for access
via a second port. A boolean 'newly_created' variable is used to
differentiate between a LUN that was created (and subsequently configured
for single port access) and one that is destined for access across both
ports. While initially set to 'true', this sticky boolean is toggled to
the 'false' state during a lookup on any next ioctl performed on a device
with a matching WWN/WWID. The code fails to realize that the match could
in fact be the same device calling in again. From here, an assumption is
made that any LUN with 'newly_created' set to 'false' is configured for
access over both ports and the port selection mask is set to reflect this.
Any future attempts to use this LUN for hosting a virtual LUN will result
in the port LUN table being incorrectly programmed.
As a remedy, the 'newly_created' concept was removed entirely and replaced
with code that always constructs the port selection mask based upon the
SCSI channel of the LUN being accessed. The bits remain sticky, therefore
allowing for a device to be accessed over both ports when that is in fact
the correct physical configuration.
Also included in this commit are a few minor related changes to enhance
the fix and provide better debug information for port selection mask and
port LUN table bugs in the future. These include renaming refresh_local()
to lookup_local(), tracing the WWN/WWID as a big-endian entity, and
tracing the port selection mask, SCSI channel, and LUN ID each time the
port LUN table is programmed.
Signed-off-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Acked-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
A 'login timed out' asynchronous error interrupt is generated if no
response is seen to a FLOGI within 2 seconds. If the time out error
is not escalated to a LINK_RESET the port will not be available for
use. This fix provides the required escalation.
Signed-off-by: Manoj N. Kumar <manoj@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
When running with an unsupported AFU, the cxlflash driver fails
the probe. When the driver is removed, the following Oops is
encountered on a show_interrupts() thread:
Call Trace:
[c000001fba5a7a10] [0000000000000003] 0x3 (unreliable)
[c000001fba5a7a60] [c00000000053dcf4] vsnprintf+0x204/0x4c0
[c000001fba5a7ae0] [c00000000030045c] seq_vprintf+0x5c/0xd0
[c000001fba5a7b20] [c00000000030051c] seq_printf+0x4c/0x60
[c000001fba5a7b50] [c00000000013e140] show_interrupts+0x370/0x4f0
[c000001fba5a7c10] [c0000000002ff898] seq_read+0xe8/0x530
[c000001fba5a7ca0] [c00000000035d5c0] proc_reg_read+0xb0/0x110
[c000001fba5a7cf0] [c0000000002ca74c] __vfs_read+0x6c/0x180
[c000001fba5a7d90] [c0000000002cb464] vfs_read+0xa4/0x1c0
[c000001fba5a7de0] [c0000000002cc51c] SyS_read+0x6c/0x110
[c000001fba5a7e30] [c000000000009204] system_call+0x38/0xb4
The Oops is due to not cleaning up correctly on the unsupported
AFU error path, leaving various allocated and registered resources.
In this case, interrupts are in a semi-allocated/registered state,
which the show_interrupts() thread attempts to use.
To fix, the cleanup logic in init_afu() is consolidated to error
gates at the bottom of the function and the appropriate goto is
added to each error path. As a mini side fix while refactoring
in this routine, the else statement following the AFU version
evaluation is eliminated as it is not needed.
Signed-off-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Acked-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|