The first call to pci_get_device() in i82875p_probe1() is useless. The
result is immediately reset at the beginning of
i82875p_setup_overfl_dev(), which then issues the same
pci_get_device() call. Dropping the redundant call avoids a device
reference leak.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224160316.60e55fb6@endymion.delvare
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
pvt->bridge_ck always points to the same device as pvt->dev_d0f1, so
get rid of the former and only use the latter.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Tested-by: Aristeu Rozanski <aris@redhat.com>
Link: http://lkml.kernel.org/r/20140224151544.16ba28a0@endymion.delvare
Cc: Mark Gross <mark.gross@intel.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
pci_get_device() decrements the reference count of "from" (last
argument) so when we break off the loop successfully we have only one
device reference - and we don't know which device we have. If we want
a reference to each device, we must take them explicitly and let
the pci_get_device() walk complete to avoid duplicate references.
This is serious, as over-putting device references will cause
the device to eventually disappear. Without this fix, the kernel
crashes after a few insmod/rmmod cycles.
Tested on an Intel S7000FC4UR system with a 7300 chipset.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: stable@vger.kernel.org
Signed-off-by: Borislav Petkov <bp@suse.de>
These variable clocks have nothing to do with MSTP gating, probably a
copy&paste leftover.
Signed-off-by: Wolfram Sang <wsa@sang-engineering.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
The reference count changes done by pci_get_device can be a little
misleading when the usage diverges from the most common scheme. The
reference count of the device passed as the last parameter is always
decreased, even if the function returns no new device. So if we are
going to try alternative device IDs, we must manually increment the
device reference count before each retry. If we don't, we end up
decreasing the reference count, and after a few modprobe/rmmod cycles
the PCI devices will vanish.
In other words and as Alan put it: without this fix the EDAC code
corrupts the PCI device list.
This fixes kernel bug #50491:
https://bugzilla.kernel.org/show_bug.cgi?id=50491
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvare
Reviewed-by: Alan Cox <alan@linux.intel.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: stable@vger.kernel.org
Signed-off-by: Borislav Petkov <bp@suse.de>
The GPIO line used for the mute LED control on Lenovo Yxx0 laptops is
cleared unexpectedly when the codec goes to D3, typically by
power-saving. For avoiding it, add a power filter in the fixup.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16373
Signed-off-by: Takashi Iwai <tiwai@suse.de>
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
HP Folio 13 may have a broken BIOS that doesn't set up the mute LED
GPIO properly, and the driver guesses it wrongly, too. Add a new
fixup entry for setting the GPIO pin statically for this laptop.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70991
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tunnel endpoints of the xfrm_state we got from the xfrm_lookup
must match the tunnel endpoints of the vti interface. This patch
ensures this matching.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
With this patch we can tunnel ipv6 traffic via a vti4
interface. A vti4 interface can now have an ipv6 address
and ipv6 traffic can be routed via a vti4 interface.
The resulting traffic is xfrm transformed and tunneled
throuhg ipv4 if matching IPsec policies and states are
present.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
We need to be protocol family indepenent to support
inter addresss family tunneling with vti. So use a
dst_entry instead of the ipv4 rtable in vti_tunnel_xmit.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
This was used from vti and is replaced by the IPsec protocol
multiplexer hooks. It is now unused, so remove it.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
With this patch, vti uses the IPsec protocol multiplexer to
register it's own receive side hooks for ESP, AH and IPCOMP.
Vti now does the following on receive side:
1. Do an input policy check for the IPsec packet we received.
This is required because this packet could be already
prosecces by IPsec, so an inbuond policy check is needed.
2. Mark the packet with the i_key. The policy and the state
must match this key now. Policy and state belong to the outer
namespace and policy enforcement is done at the further layers.
3. Call the generic xfrm layer to do decryption and decapsulation.
4. Wait for a callback from the xfrm layer to properly clean the
skb to not leak informations on namespace and to update the
device statistics.
On transmit side:
1. Mark the packet with the o_key. The policy and the state
must match this key now.
2. Do a xfrm_lookup on the original packet with the mark applied.
3. Check if we got an IPsec route.
4. Clean the skb to not leak informations on namespace
transitions.
5. Attach the dst_enty we got from the xfrm_lookup to the skb.
6. Call dst_output to do the IPsec processing.
7. Do the device statistics.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Vti uses the o_key to mark packets that were transmitted or received
by a vti interface. Unfortunately we can't apply different marks
to in and outbound packets with only one key availabe. Vti interfaces
typically use wildcard selectors for vti IPsec policies. On forwarding,
the same output policy will match for both directions. This generates
a loop between the IPsec gateways until the ttl of the packet is
exceeded.
The gre i_key/o_key are usually there to find the right gre tunnel
during a lookup. When vti uses the i_key to mark packets, the tunnel
lookup does not work any more because vti does not use the gre keys
as a hash key for the lookup.
This patch workarounds this my not including the i_key when comupting
the hash for the tunnel lookup in case of vti tunnels.
With this we have separate keys available for the transmitting and
receiving side of the vti interface.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
IPsec vti_rcv needs to remind the tunnel pointer to
check it later at the vti_rcv_cb callback. So add
this pointer to the IPsec common buffer, initialize
it and check it to avoid transport state matching of
a tunneled packet.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
This patch add an IPsec protocol multiplexer. With this
it is possible to add alternative protocol handlers as
needed for IPsec virtual tunnel interfaces.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Ensure clk->kref is dereferenced only when clk is not NULL.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Enable build support for Baytrail SST DSP platform and byt-rt5640 machine
drivers.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add Baytrail SST descriptor with the byt-rt5640 machine driver to sst-acpi
loader.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add machine driver for Baytrail SST DSP platform with RT5640 audio codec.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This adds the Baytrail SST DSP PCM platform driver. It registers itself with
the ALSA SoC layer and uses Intel Baytrail SST DSP IPC for DSP control.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Add support for Baytrail SST DSP IPC. This provides mechanism to communicate
with the DSP firmware.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
This adds basic functionality for Baytrail SST DSP initialization and
firmware loading.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
While the SHIM register addresses in Baytrail are the same than Haswell and
Broadwell their register size is 64-bit and some bits are different.
This patch adds the SST device ID for Baytrail and Baytrail specific
SHIM bit definitions.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The codec->control_data contains a pointer to the device's regmap struct. But
wm8994_bulk_write() expects a pointer to the parent wm8998 device.
The issue was introduced in commit d9a7666f ("ASoC: Remove ASoC-specific
WM8994 I/O code").
Fixes: d9a7666f ("ASoC: Remove ASoC-specific WM8994 I/O code")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
With the ongoing component-ization of the ASoC framework and the continuing
migration to using regmap for IO the control_data field of the snd_soc_codec
struct will eventually be removed. Prepare the wm8962 driver for this by using
wm8962->regmap instead of accessing the CODEC's control_data field.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
With the ongoing component-ization of the ASoC framework and the continuing
migration to using regmap for IO the control_data field of the snd_soc_codec
struct will eventually be removed. Prepare the wm8996 driver for this by using
wm8996->regmap instead of accessing the CODEC's control_data field.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Commit 88b5bdfd (ASoC: wm8993: drop regulator_bulk_free of devm_ allocated
data) eliminated the last user of driver data pointer 'wm8993' in function
wm8993_remove() - Thus remove it. Detected by Coverity: CID 1186208.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Mark Brown <broonie@linaro.org>
With the ongoing component-ization of the ASoC framework and the continuing
migration to using regmap for IO the control_data field of the snd_soc_codec
struct will eventually be removed. Prepare the da732x driver for this by using
da732x->regmap instead of accessing the CODEC's control_data field.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The compatible string of the Broadcom Capri pinctrl driver is renamed to
"brcm,bcm11351-pinctrl" to match the machine binding here:
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Matt Porter <mporter@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Christian Daudt <bcm@fixthebug.org>
Bring the driver in line with the bcm-based dt name for pinctrl.
This is being done to keep consistency with other Broadcom mobile
SoC drivers.
Signed-off-by: Christian Daudt <bcm@fixthebug.org>
Reviewed-by: Matt Porter <mporter@linaro.org>
This commit updates bcm11351.dtsi with the new compatible string for
the same driver.
Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Matt Porter <mporter@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Christian Daudt <bcm@fixthebug.org>
Move the bcm2835 board file into the mach-bcm directory. This allows us
to get rid of the mach-bcm2835 directory with the associated Kconfig
and Makefile.
Signed-off-by: Markus Mayer <markus.mayer@linaro.org>
[swarren, adjust defconfig so ARCH_BCM2835 still gets enabled]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
DT nodes should be named according to the type of object that they
represent rather than the identity. DT nodes that contain a reg
property should include a unit address in their name. Fix these issues.
Add clock-output-names properties to the nodes so that the clocks get
named something meaningful. This works around the fact that the fixed
clock driver names clocks after the short node name, i.e. not including
the unit address.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Define the Koelsch board dependent part of the Ether device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Define the generic R8A7791 part of the Ether device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Define the Lager board dependent part of the Ether device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Define the generic R8A7790 part of the Ether device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Boris reports he's seeing:
> [ 9.195943] INFO: trying to register non-static key.
> [ 9.196031] the code is fine but needs lockdep annotation.
> [ 9.196031] turning off the locking correctness validator.
> [ 9.196031] CPU: 1 PID: 933 Comm: modprobe Not tainted 3.14.0-rc4+ #1
with the r8169 driver.
These are occuring because the seqcount embedded in u64_stats_sync on
32-bit SMP is uninitialized which is making lockdep unhappy.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are many places where ops->disable is called directly. Instead we
should use _regulator_do_disable() which also handles gpio regulators.
To be able to use the wrapper function from _regulator_force_disable(),
I moved the _notifier_call_chain() call from _regulator_do_disable() to
_regulator_disable(). This way, _regulator_force_disable() can use
different flags for _notifier_call_chain() without calling it twice.
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
There are some direct ops->enable in the regulator core driver. This is
a potential issue as the function _regulator_do_enable() handles gpio
regulators and the normal ops->enable calls. These gpio regulators are
simply ignored when ops->enable is called directly.
One possible bug is that boot-on and always-on gpio regulators are not
enabled on registration.
This patch replaces all ops->enable calls by _regulator_do_enable.
[Handle missing enable operations -- broonie]
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: Handle invalid enable operation for always/boot on regulators
Signed-off-by: Mark Brown <broonie@linaro.org>
bh_lock spinlock is unused, remove it from the private driver structure.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
