This has been used by me and others for ages, let's stop calling it
experimental.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
As none of the callers of bond_update_speed_duplex (need to) check its
return value, there is little point in it returning anything.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In 3.3, gpio wakeup setting was broken. The call
enable_irq_wake() didn't set up the PXA gpio registers
(PWER, ...) anymore.
Fix it at least for pxa27x. The driver doesn't seem to be
used in pxa25x (weird ...), and the fix doesn't extend to
pxa3xx and pxa95x (which don't have a gpio_set_wake()
available).
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
We did a similar check for the P-states but did not do it for
the C-states. What we want to do is ignore cases where the DSDT
has definition for sixteen CPUs, but the machine only has eight
CPUs and we get:
xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
Reported-by: Tobias Geiger <tobias.geiger@vido.info>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Move the err_request_irq error label up to reflect that tasklet_init and
irq_of_parse_and_map have taken place.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
This patch fixes a race whereby a pointer to a buffer
would be overwritten while the buffer was in use leading
to a double free and a memory leak. This causes crashes.
This bug was introduced in 2.6.34
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull infiniband fixes from Roland Dreier:
"A few fixes for regressions introduced in 3.4-rc1:
- fix memory leak in mlx4
- fix two problems with new MAD response generation code"
* tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/mlx4: Fix memory leaks in ib_link_query_port()
IB/mad: Don't send response for failed MADs
IB/mad: Set 'D' bit in response for unhandled MADs
Pull a watchdog fix from Wim Van Sebroeck:
"It will fix the size when reading or writing to WD Timer port 0x72 in
the hpwdt driver."
* git://www.linux-watchdog.org/linux-watchdog:
hpwdt: Only BYTE reads/writes to WD Timer port 0x72
Merge fixes from Andrew Morton:
"13 fixes. The acerhdf patches aren't (really) fixes. But they've
been stuck in my tree for up to two years, sent to Matthew multiple
times and the developers are unhappy."
* emailed from Andrew Morton <akpm@linux-foundation.org>: (13 patches)
mm: fix NULL ptr dereference in move_pages
mm: fix NULL ptr dereference in migrate_pages
revert "proc: clear_refs: do not clear reserved pages"
drivers/rtc/rtc-ds1307.c: fix BUG shown with lock debugging enabled
arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file
hugetlbfs: lockdep annotate root inode properly
acerhdf: lowered default temp fanon/fanoff values
acerhdf: add support for new hardware
acerhdf: add support for Aspire 1410 BIOS v1.3314
fs/buffer.c: remove BUG() in possible but rare condition
mm: fix up the vmscan stat in vmstat
epoll: clear the tfile_check_list on -ELOOP
mm/hugetlb: fix warning in alloc_huge_page/dequeue_huge_page_vma
In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.
The reason is that the irq number is not always identical to the
pirq number so if we wrongly use the irq number to check the
pirq_eoi_map we are going to check for the wrong pirq to EOI.
As a consequence some interrupts might not be EOI'ed by the
guest correctly.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
[v1: Added some extra wording to git commit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Add a interface pinctrl_provide_dummies for platform to indicate
whether it needs use pinctrl dummy state.
ChangeLog v3->v4:
* remove dummy gpio support in pinctrl subsystem.
Let gpio driver decide whether it wants to use pinctrl gpio mux
function.
ChangeLog v2->v3:
* Also changed the missed pinctrl gpio APIs in v1.
ChangeLog v1->v2:
* Based on sascha's suggestion, drop using kconfig since it will hide
pinctrl errors on all other boards.
See: https://lkml.org/lkml/2012/4/18/282
It seemed both Linus and Stephen agreed with this way, so i'm ok
with it too.
* Add dummy gpio support.
pinctrl gpio in the same situation as state.
* Patch name changed.
Original is pinctrl: handle dummy state in core.
* Split removing old dt dummy interface into a separate patch
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are a few places in the api where the code simply returns -EINVAL when
it finds an error. An example is pinmux_map_to_setting() which now reports an
error if we try to match a group with a function that it does not support.
The reporting of errors in pinconf_check_ops and pinmux_check_ops now has the
same style and is located inside the according functions and not the calling
code.
When the map is found in the DT but the default state can not be selected we
get an error to know that the code at least tried.
The patch also removes a stray word from one comment and a "->" from another
for the sake of consistency.
Finally we replace a few pr_err/debug() calls with dev_err/dbg().
Thanks go to Stephen Warren for reviewing the patch and enhancing the reporting
inside pinmux_map_to_setting().
Signed-off-by: John Crispin <blogic@openwrt.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the VME core, VME board drivers, and VME bridge drivers out
of the drivers/staging/vme/ area to drivers/vme/.
The VME device drivers have not moved out yet due to some API questions
they are still working through, that should happen soon, hopefully.
Cc: Martyn Welch <martyn.welch@ge.com>
Cc: Manohar Vanga <manohar.vanga@cern.ch>
Cc: Vincent Bossier <vincent.bossier@gmail.com>
Cc: "Emilio G. Cota" <cota@braap.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current condition is always true, so everything uses
LOGICAL_DEV_CIR_REV2 (8). It should be that Fintek products
0x0408(F71809) and 0x0804(F71855) use logical device
LOGICAL_DEV_CIR_REV1 (5) and other chip ids use logical device 8.
In other words, this fixes hardware detection for 0x0408 and 0x0804.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This file has an implicit dependency on GPIO stuff, showing
up as the following build failure:
drivers/video/bfin-lq035q1-fb.c:369:6: error: 'GPIOF_OUT_INIT_LOW' undeclared
Other more global bfin build issues prevent an automated bisect, but
it really doesn't matter - simply add in the appropriate header.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Otherwise we get this link failure for frv's defconfig:
LD .tmp_vmlinux1
drivers/built-in.o: In function `pci_assign_resource':
(.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment'
drivers/built-in.o: In function `pci_setup':
pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt'
pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt'
make[1]: *** [.tmp_vmlinux1] Error 1
Cc: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
An early registration of an ISR was causing a crash to several users (for
example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
The reason was that IRQs were being triggered before a driver
initialisation was completed.
This patch fixes this by moving the invocation to request_irq() and to
request_region() to a later stage on the driver probe function.
Cc: <stable@vger.kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
One of the OLPC changes lost a little in its translation to mainline,
leading to build errors on the ARM architecture. Remove the offending
line, and all will be well.
Reported-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
"stat" is always zero here. The condition used to be needed, but we
shifted stuff around in 0f0b270f90 "[media] ngene: CXD2099AR Common
Interface driver".
This doesn't change how the code works, it's just a bit tidier.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The saa7164_vbi_stop_port() changes the SAA_ERR_ALREADY_STOPPED result
code to -EIO before returning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the situation by adding an explicit output_dtd to the sdvo
mode_set function and streamline the code-flow by moving the input and
output mode setting in the sdvo encode together.
Furthermore testing showed that the sdvo input timing needs the
unadjusted dotclock, the sdvo chip will automatically compute the
required pixel multiplier to get a dotclock above 100 MHz.
Fix this up when converting a drm mode to an sdvo dtd.
This regression was introduced in
commit c74696b9c8
Author: Pavel Roskin <proski@gnu.org>
Date: Thu Sep 2 14:46:34 2010 -0400
i915: revert some checks added by commit 32aad86f
particularly the following hunk:
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 093e914..62d22ae 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,
/* We have tried to get input timing in mode_fixup, and filled into
adjusted_mode */
- if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
- intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+ intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+ if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
- } else
- intel_sdvo_get_dtd_from_mode(&input_dtd, mode);
/* If it's a TV, we already set the output timing in mode_fixup.
* Otherwise, the output timing is equal to the input timing.
Due to questions raised in review, below a more elaborate analysis of
the bug at hand:
Sdvo seems to have two timings, one is the output timing which will be
sent over whatever is connected on the other side of the sdvo chip (panel,
hdmi screen, tv), the other is the input timing which will be generated by
the gmch pipe. It looks like sdvo is expected to scale between the two.
To make things slightly more complicated, we have a bunch of special
cases:
- For lvds panel we always use a fixed output timing, namely
intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
- Sdvo has an interface to generate a preferred input timing for a given
output timing. This is the confusing thing that I've tried to clear up
with the follow-on patches.
- A special requirement is that the input pixel clock needs to be between
100MHz and 200MHz (likely to keep it within the electromechanical design
range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
doubled/quadrupled.
The thing this patch tries to fix is that the pipe needs to be
explicitly instructed to double/quadruple the pixels and needs the
correspondingly higher pixel clock, whereas the sdvo adaptor seems to
do that itself and needs the unadjusted pixel clock. For the sdvo
encode side we already set the pixel mutliplier with a different
command (0x21).
This patch tries to fix this mess by:
- Keeping the output mode timing in the unadjusted plain mode, safe
for the lvds case.
- Storing the input timing in the adjusted_mode with the adjusted
pixel clock. This way we don't need to frob around with the core
crtc mode set code.
- Fixing up the pixelclock when constructing the sdvo dtd timing
struct. This is why the first hunk of the patch is an integral part
of the series.
- Dropping the is_tv special case because input_dtd is equivalent to
adjusted_mode after these changes. Follow-up patches clear this up
further (by simply ripping out intel_sdvo->input_dtd because it's
not needed).
v2: Extend commit message with an in-depth bug analysis.
Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If multiple clients are registered on a single camera host interface,
the user-space hot-plug software can try to access the one, that probed
first, before probing of the second one has completed. This can be
handled by individual host drivers, but it is even better to hold back
the user-space until all the probing on this host has completed. This
fixes a race on ecovec with two clients registered on the CEU1 host, which
otherwise triggers a BUG() in sh_mobile_ceu_remove_device().
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is to correct the use of the iLO port 0x72 usage.
The port 0x72 is a byte size write/read and hpwdt is currently
writing a WORD.
Signed-off by: Thomas Mingarelli <thomas.mingarelli@hp.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
With firmwares which do not support rsn capability override
(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE) from host would
cause 4-way handshake failure when HT cap is advertised.
To fix this, do not advertise HT cap with cfg80211 for
those fw.
kvalo: fix a checkpatch warning
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch enables all multicast packets in non suspend mode
and enable multicast filtering in wow suspend mode. This also
fixes a bug in multicast where the driver assumed disable
multicast-all command disabled/filtered all multicast
packets, which was wrong assumption, because firmware will
apply the programmed filter.
Multicast requirements
- Enable forward all multicast packets(no filtering) in
non suspend mode.
- Enable multicast filtering in wow suspend mode for both
AP and CLIENT.
kvalo: fix a checkpatch warning and drop unrelated newline removal
Signed-off-by: Naveen Gangadharan <ngangadh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Without this patch sysfs reports the cable as present
flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier
1
while it's not:
flag@flag-desktop:~$ sudo mii-tool eth0
eth0: no link
Tested on my Beagle XM.
v2: added mantainer to the list of recipient
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
The dl2k driver's rio_ioctl call has a few issues:
- No permissions checking
- Implements SIOCGMIIREG and SIOCGMIIREG using the SIOCDEVPRIVATE numbers
- Has a few ioctls that may have been used for debugging at one point
but have no place in the kernel proper.
This patch removes all but the MII ioctls, renumbers them to use the
standard ones, and adds the proper permission check for SIOCSMIIREG.
We can also get rid of the dl2k-specific struct mii_data in favor of
the generic struct mii_ioctl_data.
Since we have the phyid on hand, we can add the SIOCGMIIPHY ioctl too.
Most of the MII code for the driver could probably be converted to use
the generic MII library but I don't have a device to test the results.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fragmentation is usefull if multiple devices are connected to an E1
interface. Each fragment will have a subset of the available timeslots.
These devices require a cascde connection or a multiplexer.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
LEDs will show RED if layer 1 is disabled or fails.
LEDs will show GREEN if layer 1 is active.
LEDs will blink if traffic on D-channel.
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
We already have the flag for L1 active, so we should use it.
L2 will be solved in a later patch.
Signed-off-by: Andreas Eversberg <andreas@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Transmitted audio data was interrupted if a bridge was enabled or disabled.
Now transmission seamlessly continues during that action.
Fix in hfcmulti.ko
Signed-off-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mark Loard pointed out:
"For example, this beauty from rtc-mpc5121.c in the same update:
...
rtc->rtc = rtc_device_register("mpc5200-rtc", &op->dev,
&mpc5200_rtc_ops, THIS_MODULE);
...
rtc->rtc->uie_unsupported = 1; // <<<< Ooops NULL pointer >>>>
if (IS_ERR(rtc->rtc)) { // <<<< this needs to be earlier >>>>
err = PTR_ERR(rtc->rtc);
goto out_free_irq;
}
..."
This patch moves setting the uie_unsupported flag to after we validate
the rtc->rtc pointer to resolve this.
Reported by: Mark Lord <kernel@teksavvy.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/r/1335300215-21427-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit a4910b7444 has broken promiscuous
mode, which is never set. port->promisc just reflects the last setting
of PROMISCUOUS mode to avoid doing an extra hypercall when it's already
set.
However, since it may fail because of hypervisor permissions, we should
still respect the multicast settings and not simply exit after setting
promiscuous mode.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Cc: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There was a bug in the mask of regtype parameter for registering a
multicast filter. It was ignoring the scope bit, which was wrongly being
used for all filters. The SCOPE_ALL value adds a filter that allows all
multicast packets and ignores the MAC parameter, just what allmulticast
needs. The normals filters, however, should not use SCOPE_ALL.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
merge TXQ/RXQ/MAC start/enable code to one function as they
are started/enabled at the same time, just like stop/disable them
in the function of atl1c_stop_mac.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This function is used for suspend of S1/S3/S4 and driver remove.
It sets MAC/PHY based on the WoL configuation to get lower power
consumption.
atl1c_phy_power_saving is renamed to atl1c_phy_to_ps_link, this
function is just make PHY enter a link/speed mode to eat less
power.
REG_MAC_CTRL register is refined as well.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Many magic data are re-configured for PHY during its reset operation
based on chip type to get better compability and stability.
REG_PHY_CTRL register may be configured by BIOS before enter OS.
so, the driver can't directly write to it without any Read-Op.
this change also affect suspend and phy_disable routines.
PHY debug ports and extension registers are refined as well.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PHY polling code for FPGA is considered in every MDIO R/W API.
no need to add additional code to atl1c_open.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
