Current code takes wrong parameter while calling max8649_list_voltage.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
This patch fixes a warning about unused function when CONFIG_PM_SLEEP
is not selected in the kernel config:
igb_main.c: warning: `igb_suspend` defined but not used [W-unused-function]
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The e1000_init_mac_params_XXX() functions (where XXX is one of the three
MAC-family types 80003es2lan, 82571 and ich8lan) was not meant to require a
pointer to the adapter struct but does require a pointer to the hw struct.
Pass that pointer in to the functions instead.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
v2 - replaced mac->autoneg_failed == false with !mac->autoneg_failed
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
...and convert some goto's which simply return to just return.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
warning: comparison of unsigned expression < 0 is always false
Remove an unnecessary test that is reported when compiling driver with W=1.
The test is unnecessary because Intel wired GbE hardware older (i.e. less)
than 82571 is not supported by this driver.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
"subbuf_size" and "n_subbufs" come from the user and they need to be
capped to prevent an integer overflow.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
On OMAP2420-based systems, the PM code ignores the state of the UART
functional clocks when determining what idle state to enter. This
breaks the serial port now that the UART driver's clock behavior can
be controlled via the PM autosuspend timeout.
To fix, remove the special-case idle handling for the UARTs in the
OMAP2420/2430 PM idle code added by commit
4af4016c53 ("OMAP3: PM: UART: disable
clocks when idle and off-mode support").
Tested on Nokia N800. This patch is a collaboration between Tony
Lindgren <tony@atomide.com> and Paul Walmsley <paul@pwsan.com>.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The patch "ARM: orion: Consolidate USB platform setup code.", commit
4fcd3f374a broke USB on TS-7800 and
other orion5x boards, because the wrong type of PHY was being passed
to the EHCI driver in the platform data. Orion5x needs EHCI_PHY_ORION
and all the others want EHCI_PHY_NA.
Allow the mach- code to tell the generic plat-orion code which USB PHY
enum to place into the platform data.
Version 2: Rebase to v3.3-rc2.
Reported-by: Ambroz Bizjak <ambrop7@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Ambroz Bizjak <ambrop7@gmail.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Patchset "ARM: orion: Refactor the MPP code common in the orion
platform" broke at least Orion5x based platforms. These platforms have
pins configured as GPIO when the selector is not 0x0. However the
common code assumes the selector is always 0x0 for a GPIO lines. It
then ignores the GPIO bits in the MPP definitions, resulting in that
Orion5x machines cannot correctly configure there GPIO lines.
The Fix removes the assumption that the selector is always 0x0.
In order that none GPIO configurations are correctly blocked,
Kirkwood and mv78xx0 MPP definitions are corrected to only set the
GPIO bits for GPIO configurations.
This third version, which does not contain any whitespace changes,
and is rebased on v3.3-rc2.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Since mc13xxx-regulator-core.c and the actual drivers can get built
into seperate modules, you have to export the DT support symbols
"mc13xxx_get_num_regulators_dt" and "mc13xxx_parse_regulators_dt"
otherwise the allmodconfig build fails on sparc64.
[Updated the subject; the same thing was previously reported and fixed
in -next but for some reason nobody noticed for some considerable time
after the issue was introduced -- broonie]
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80KZgACgkQMUfUDdst+yk0HgCeIdU3VTWqdxZDXp3G1sFIXZ1b
47YAnRAMAar+/aLaNhqGrcz7aa5y2cUU
=8sr8
-----END PGP SIGNATURE-----
Merge tag 'tty-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Serial/TTY fixes for the 3.3-rc3 tree
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'tty-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
m32r: relocate drivers back out of 8250 dir
tty: fix a build failure on sparc
serial: samsung: Add support for EXYNOS5250
serial: samsung: Add support for EXYNOS4212 and EXYNOS4412
drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer
Big things here is the deletion of the Android pmem driver, as it's
obsolete and no one uses it, the gma500 driver as it's already in the
drm portion of the kernel tree, and the pohmelfs filesystem as it's
obsolete and a rewritten version is being proposed for the fs/ section
of the kernel.
Other than that, a smattering of different bugfixes and regressions, and
some omap drm api merge fixups that were needed due to api changes in
the main portion of the drm tree, allowing this code to build properly
again.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80KLYACgkQMUfUDdst+ykhiwCg2ctSu4umygA1ErAedAA+sJkv
psYAn20OZQDyuBcBAIzL2L+Y/BUz8bXt
=xvyx
-----END PGP SIGNATURE-----
Merge tag 'staging-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Staging tree patches for 3.3-rc3
Big things here is the deletion of the Android pmem driver, as it's
obsolete and no one uses it, the gma500 driver as it's already in the
drm portion of the kernel tree, and the pohmelfs filesystem as it's
obsolete and a rewritten version is being proposed for the fs/ section
of the kernel.
Other than that, a smattering of different bugfixes and regressions, and
some omap drm api merge fixups that were needed due to api changes in
the main portion of the drm tree, allowing this code to build properly
again.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'staging-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (28 commits)
staging: pohmelfs: remove drivers/staging/pohmelfs
staging: android/ram_console: Don't build on arches w/o ioremap
staging: r8712u: Use asynchronous firmware loading
staging: usbip: fix to prevent potentially using uninitialized spinlock
staging: r8712u: Fix problem when CONFIG_R8712_AP is set
staging: tidspbridge: fix incorrect free to drv_datap
staging: tidspbridge: fix bridge_open memory leaks
staging: android: lowmemorykiller: Don't wait more than one second for a process to die
MAINTAINERS: staging: iio: add iio information
staging: zcache: fix serialization bug in zv stats
staging: fix go7007-usb license
Staging: android: binder: Fix crashes when sharing a binder file between processes
Staging: android: Remove pmem driver
Staging: asus_oled: fix NULL-ptr crash on unloading
Staging: asus_oled: fix image processing
Staging: android: binder: Don't call dump_stack in binder_vma_open
staging: r8712u: Add new Sitecom UsB ID
zcache: Set SWIZ_BITS to 8 to reduce tmem bucket lock contention.
zcache: fix deadlock condition
staging: drm/omap: fix locking issue
...
A few fixes for kobject warnings that have popped up in the cpu hotplug path,
and a regression fix for the speed of the hotplug memory code.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80J1cACgkQMUfUDdst+ylYfgCcClIeUw4njh3Tup9BpRrdBprr
fBsAoLKKhaZDsnma85PJRDAvtM2guoi7
=0TZ9
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Driver core fixes for the 3.3-rc3 tree.
A few fixes for kobject warnings that have popped up in the cpu hotplug path,
and a regression fix for the speed of the hotplug memory code.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'driver-core-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
driver-core: cpu: fix kobject warning when hotplugging a cpu
ACPI: remove duplicated lines of merging problems with acpi_processor_add
docbook: fix fatal errors in device-drivers docbook and add DMA Management section
drivers/base/memory.c: fix memory_dev_init() long delay
driver core: cpu: remove kernel warning when removing a cpu
Nothing big here, some Kconfig fixes for the MISC_DEVICES config option
that was being used incorrectly, and some other minor bug fixes.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80HSAACgkQMUfUDdst+ymFsQCghwKbV9B9z5fgUXYwFQJ/pD2j
GhsAn3J2mhhHN/vtSPQAN9Vu59Xb/tCi
=VZaE
-----END PGP SIGNATURE-----
Merge tag 'char-misc-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Minor char-misc fixes for 3.3-rc3
Nothing big here, some Kconfig fixes for the MISC_DEVICES config option
that was being used incorrectly, and some other minor bug fixes.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'char-misc-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
mmc: cb710 core: Add missing spin_lock_init for irq_lock of struct cb710_chip
cs5535-mfgpt: don't call __init function from __devinit
vmw_balloon: fix for a -Wuninitialized warning
drivers: misc: Remove MISC_DEVICES config option
c2port: fix build error for duramar2150 due to missing header.
Here are a few minor USB fixes and a bunch of device id updates for the
USB drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80Ki4ACgkQMUfUDdst+ymp3wCfUG2LtQOC2qpzpnl1bcivSA18
11gAn09DbcldfH4k12HyCr7PuBnjILQh
=vfEv
-----END PGP SIGNATURE-----
Merge tag 'usb-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
USB fixes for 3.3-rc3
Here are a few minor USB fixes and a bunch of device id updates for the
USB drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'usb-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: usbserial: add new PID number (0xa951) to the ftdi driver
usb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()
usb: musb: fix a build error on mips
uwb & wusb & usb wireless controllers: fix kconfig error & build errors
usb: Skip PCI USB quirk handling for Netlogic XLP
powerpc/usb: fix issue of CPU halt when missing USB PHY clock
usb: otg: mv_otg: Add dependence
usb: host: Distinguish Kconfig text for Freescale controllers
USB: add new zte 3g-dongle's pid to option.c
usb: ch9.h: usb_endpoint_maxp() uses __le16_to_cpu()
USB: qcserial: don't enable autosuspend
USB: qcserial: add several new serial devices
usb: otg: mv_otg: Add dependence
usb: gadget: zero: fix bug in loopback autoresume handling
The current error handling doesn't work because we flash_part is a u32
so the checks for negative error codes don't work. I considered making
things signed but I don't know the hardware enough to say if that's a
problem. Really, we don't use the error codes so just returning zero
for all problems is fine.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We use len to store the return value from eth_header(). eth_header()
can return -ETH_HLEN (-14). We want to pass this back instead of
truncating it to 65522 and returning that.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes problem where caller would think routine succeeded when it failed
leading to divide by zero panic.
Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
(->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
it.
the intilization of this read/write lock happens via the path
ieee80211_led_init (->) led_trigger_register, but we are doing
'ieee80211_led_init' after 'ieeee80211_if_add' where we
register netdev_ops.
so we access leddev_list_lock before initializing it and causes the
following bug in chrome laptops with AR928X cards with the following
script
while true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
done
BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
Call Trace:
[<8137b9df>] rwlock_bug+0x3d/0x47
[<81179830>] do_raw_read_lock+0x19/0x29
[<8137f063>] _raw_read_lock+0xd/0xf
[<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211]
[<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
[<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211]
[<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
[<f9076d97>] ieee80211_open+0x48/0x4c [mac80211]
[<812dbed8>] __dev_open+0x82/0xab
[<812dc0c9>] __dev_change_flags+0x9c/0x113
[<812dc1ae>] dev_change_flags+0x18/0x44
[<8132144f>] devinet_ioctl+0x243/0x51a
[<81321ba9>] inet_ioctl+0x93/0xac
[<812cc951>] sock_ioctl+0x1c6/0x1ea
[<812cc78b>] ? might_fault+0x20/0x20
[<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2
[<810a6ebb>] ? fget_light+0x2f/0x70
[<812ce549>] ? sys_recvmsg+0x3e/0x48
[<810b1f35>] sys_ioctl+0x46/0x69
[<8137fa77>] sysenter_do_call+0x12/0x2
Cc: <stable@vger.kernel.org>
Cc: Gary Morain <gmorain@google.com>
Cc: Paul Stewart <pstew@google.com>
Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Acked-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixes problem where caller would think routine succeeded when it failed
leading to divide by zero panic.
(This also reverts an earlier attempt, commit 42bc0c97 "rtlwifi: Return
correct failure code on error". -- JWL)
Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Treat pwmX as a measured value, not as a (mostly static) limit value, so
that it is updated more frequently from the device register.
Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
This will support the new VLAN attribute in the iSCSI iface file.
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
to speed up error recovery due to SPQ failures. The error flag will
expedite the recovery process by skipping the timeouts.
Signed-off-by: Jeffrey Huang <huangjw@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Just like skb->cb[], so that qdisc_skb_cb can be encapsulated inside
of other data structures.
This is intended to be used by IPoIB so that it can remember
addressing information stored at hard_header_ops->create() time that
it can fetch when the packet gets to the transmit routine.
Signed-off-by: David S. Miller <davem@davemloft.net>
The receive FIFO wakeup latency estimate in the omap-serial driver is
three orders of magnitude too small. This effectively prevents the
MPU from going to a low-power state when CONFIG_CPU_IDLE=y. This is a
major power management regression and masks some other FIFO-related
bugs in the driver.
Fix by correcting the most egregious problem in the RX wakeup latency
estimate. There are several other flaws in the estimator; these will
be fixed by a separate patch series intended for 3.4.
The difference in low-power states with this patch can be observed via
debugfs in pm_debug/count.
This estimate does not have any effect when CONFIG_CPU_IDLE=n.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prevent OMAP UARTs from going idle while they are still transferring
data in PIO mode. This works around an oversight in the OMAP UART
hardware present in OMAP34xx and earlier: an idle UART won't send a
wakeup when the TX FIFO threshold is reached. This causes long delays
during data transmission when the MPU powerdomain enters a low-power
mode. The MPU interrupt controller is not able to respond to
interrupts when it's in a low-power state, so the TX buffer is not
refilled until another wakeup event occurs.
This fix changes the erratum i291 DMA idle workaround. Rather than
toggling between force-idle and no-idle, it will toggle between
smart-idle and no-idle. The important part of the workaround is the
no-idle part, so this shouldn't result in any change in behavior.
This fix should work on all OMAP UARTs. Future patches intended for
the 3.4 merge window will make this workaround conditional on a
"feature" flag, and will use the OMAP36xx+ TX event wakeup support.
Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the (default) PIO mode, use a one-byte RX FIFO threshold. The OMAP
UART IP blocks do not appear to be capable of waking the system under
an RX timeout condition. Since the previous RX FIFO threshold was 16
bytes, this meant that omap-serial.c did not become aware of any
received data until all those bytes arrived or until another UART
interrupt occurred. This made the serial console and presumably other
serial applications (GPS, serial Bluetooth) unusable or extremely
slow. A 1-byte RX FIFO threshold also allows the MPU to enter a
low-power consumption state while waiting for the FIFO to fill.
This can be verified using the serial console by comparing the
behavior when "0123456789abcde" is pasted in from another window, with
the behavior when "0123456789abcdef" is pasted in. Since the former
string is less than sixteen bytes long, the string is not echoed for
some time, while the latter string is echoed immediately.
DMA operation is unaffected by this patch.
Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some
additional information on the standard behavior of the RX timeout
event, which was used to improve this commit description.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_parse_integer() does one or two division instructions (which are slow)
per digit parsed to perform the overflow check.
Furthermore, these are particularly expensive examples of division
instruction as the number of clock cycles required to complete them may
go up with the position of the most significant set bit in the dividend:
if (*res > div_u64(ULLONG_MAX - val, base))
which is as maximal as possible.
Worse, on 32-bit arches, more than one of these division instructions
may be required per digit.
So, assuming we don't support a base of more than 16, skip the check if the
top nibble of the result is not set at this point.
Signed-off-by: David Howells <dhowells@redhat.com>
[ Changed it to not dereference the pointer all the time - even if the
compiler can and does optimize it away, the code just looks cleaner.
And edited the top nybble test slightly to make the code generated on
x86-64 better in the loop - test against a hoisted constant instead of
shifting and testing the result ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit aeb5032b3f, a dependency on IRQ_DOMAIN was added, which causes
regressions on previously working setups: a previously working non-DT
kernel configuration now loses its PMIC support. The lack of PMIC
support in turn causes the loss of other functionality the kernel had.
This dependency was added because the driver now registers its
interrupts with the IRQ domain code, presumably to prevent a build error.
The result is that OMAP3 oopses in the vp.c code (fixed by a previous
commit) due to the lack of PMIC support.
However, even with IRQ_DOMAIN enabled, the driver oopses:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 1 Not tainted (3.3.0-rc2+ #271)
PC is at irq_domain_add+0x1c/0x134
LR is at twl_probe+0xd0/0x370
pc : [<c007bad0>] lr : [<c029baac>] psr: 00000113
sp : df843c48 ip : df843c68 fp : df843c64
r10: c02b93e4 r9 : 00000000 r8 : c029b9dc
r7 : df9d8a00 r6 : c03bef90 r5 : 00000000 r4 : c03f5240
r3 : 00000000 r2 : c03f5240 r1 : 00000015 r0 : c03f5240
Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 8000404a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xdf8422f0)
Stack: (0xdf843c48 to 0xdf844000)
3c40: 00000014 00000170 00000014 c03bef90 df843c9c df843c68
3c60: c029baac c007bac0 00000000 df9d8a20 00000001 c03cd238 c02b93e4 df9d8a20
3c80: df9d8a04 df9d8a00 c029b9dc df8cae08 df843cc4 df843ca0 c01eee70 c029b9e8
...
Backtrace:
[<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
r6:c03bef90 r5:00000014 r4:00000170
[<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4)
[<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x178)
r8:df8f0070 r7:c03cd238 r6:df9d8a20 r5:df9d8a20 r4:df9d8a20
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
r7:df843d18 r6:df9d8a20 r5:c03cd238 r4:df9d8a20
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d2148>] (__device_attach+0x44/0x48)
r5:df9d8a20 r4:c03cd238
[<c01d2104>] (__device_attach+0x0/0x48) from [<c01d0840>] (bus_for_each_drv+0x58/0x98)
r5:c01d2104 r4:00000000
[<c01d07e8>] (bus_for_each_drv+0x0/0x98) from [<c01d21f8>] (device_attach+0x80/0xac)
r7:df9d8a28 r6:df9d8a54 r5:c03cd978 r4:df9d8a20
[<c01d2178>] (device_attach+0x0/0xac) from [<c01d1430>] (bus_probe_device+0x34/0xa4)
r6:df9d8a20 r5:c03cd978 r4:df9d8a20
[<c01d13fc>] (bus_probe_device+0x0/0xa4) from [<c01cffb0>] (device_add+0x2a0/0x420)
r6:00000000 r5:df9d8a20 r4:df9d8a20
[<c01cfd10>] (device_add+0x0/0x420) from [<c01d0150>] (device_register+0x20/0x24)
r8:df9d8a00 r7:df9d8a04 r6:df8f0048 r5:df9d8a00 r4:df9d8a20
[<c01d0130>] (device_register+0x0/0x24) from [<c01ef8d4>] (i2c_new_device+0x118/0x180)
r4:df9d8a20
[<c01ef7bc>] (i2c_new_device+0x0/0x180) from [<c01efc88>] (i2c_register_adapter+0x140/0x204)
r8:c03cd970 r7:00000000 r6:df8f0070 r5:df8a6300 r4:df8f0048
[<c01efb48>] (i2c_register_adapter+0x0/0x204) from [<c01efe9c>] (i2c_add_numbered_adapter+0xb4/0xcc)
r8:df8a4c54 r7:df8cae00 r6:df843e2c r5:df8f0048 r4:00000000
[<c01efde8>] (i2c_add_numbered_adapter+0x0/0xcc) from [<c029ce1c>] (omap_i2c_probe+0x2f8/0x3b4)
r6:00000000 r5:df8f0000 r4:df8f0070
[<c029cb24>] (omap_i2c_probe+0x0/0x3b4) from [<c01d3484>] (platform_drv_probe+0x20/0x24)
[<c01d3464>] (platform_drv_probe+0x0/0x24) from [<c01d1f34>] (really_probe+0xa0/0x178)
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
r7:df843ef0 r6:c03cdb2c r5:c03cdb2c r4:df8cae08
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d20e0>] (__driver_attach+0x6c/0x90)
r5:df8cae3c r4:df8cae08
[<c01d2074>] (__driver_attach+0x0/0x90) from [<c01d08d8>] (bus_for_each_dev+0x58/0x98)
r6:c03cdb2c r5:c01d2074 r4:00000000
[<c01d0880>] (bus_for_each_dev+0x0/0x98) from [<c01d1d80>] (driver_attach+0x20/0x28)
r7:df880b80 r6:c03cdb2c r5:c03cdb2c r4:c0394f28
[<c01d1d60>] (driver_attach+0x0/0x28) from [<c01d115c>] (bus_add_driver+0xb4/0x230)
[<c01d10a8>] (bus_add_driver+0x0/0x230) from [<c01d278c>] (driver_register+0xc8/0x154)
[<c01d26c4>] (driver_register+0x0/0x154) from [<c01d37e4>] (platform_driver_register+0x4c/0x60)
r8:00000000 r7:00000013 r6:c00384c8 r5:c0395180 r4:c0394f28
[<c01d3798>] (platform_driver_register+0x0/0x60) from [<c038626c>] (omap_i2c_init_driver+0x14/0x1c)
[<c0386258>] (omap_i2c_init_driver+0x0/0x1c) from [<c00087b8>] (do_one_initcall+0x9c/0x164)
[<c000871c>] (do_one_initcall+0x0/0x164) from [<c036c2f4>] (kernel_init+0x90/0x138)
[<c036c264>] (kernel_init+0x0/0x138) from [<c00384c8>] (do_exit+0x0/0x2ec)
r5:c036c264 r4:00000000
<0>Code: e24dd004 e5903014 e1a04000 e5905010 (e5933000)
<4>---[ end trace 1b75b31a2719ed1c ]---
This happens because we try to register an IRQ domain with a NULL ops
structure, and the first thing irq_domain_add() does is try to
dereference this ops structure.
So, fix the problem by getting rid of the incorrect OF_IRQ ifdef and
wrapping the IRQ domain bits of the driver with an IRQ_DOMAIN ifdef
instead.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The ARM kernel uses undefined instructions to implement
BUG/BUG_ON(). This leads to problems where people don't read one
line above the Oops message and see the "kernel BUG at ..."
message and so they wrongly assume the kernel has hit an
undefined instruction.
Instead of printing:
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
print
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
This should prevent people from thinking the BUG_ON was an
undefined instruction when it was actually intentional.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
armv7's flush_cache_all() flushes caches via set/way. To
determine the cache attributes (line size, number of sets,
etc.) the assembly first writes the CSSELR register to select a
cache level and then reads the CCSIDR register. The CSSELR register
is banked per-cpu and is used to determine which cache level CCSIDR
reads. If the task is migrated between when the CSSELR is written and
the CCSIDR is read the CCSIDR value may be for an unexpected cache
level (for example L1 instead of L2) and incorrect cache flushing
could occur.
Disable interrupts across the write and read so that the correct
cache attributes are read and used for the cache flushing
routine. We disable interrupts instead of disabling preemption
because the critical section is only 3 instructions and we want
to call v7_dcache_flush_all from __v7_setup which doesn't have a
full kernel stack with a struct thread_info.
This fixes a problem we see in scm_call() when flush_cache_all()
is called from preemptible context and sometimes the L2 cache is
not properly flushed out.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With an admittedly exotic choice of configuration options
(CC_OPTIMIZE_FOR_SIZE, THUMB2, some other size-minimizing ones)
and compiler, the proc_info table can end up being misaligned,
and the kernel being unbootable (Error: unrecognized/unsupported
processor variant).
Forcing the alignement to 4 bytes in the linker script fixes the
issue.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
current fsi_pointer() calculation was not correct for FSI driver.
This patch fix it up.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Commit db0d4db22a ('ARM: gic: allow GIC to support non-banked setups)
requires a cpu-offset property to be specified for non-banked gic
controllers, which is the case for Exynos4.
Reported-and-Tested-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This commit brings exynos4-dt in line with recent changes to
mach-exynos tree, specifically:
- Fixes build break related to replacing plat/exynos4.h with
common.h in commit cc511b8d84 ("ARM: 7257/1: EXYNOS:
introduce arch/arm/mach-exynos/common.[ch]")
- Converts machine to use CONFIG_MULTI_IRQ_HANDLER as done for
other machines in commit 4e44d2cb95 ("ARM: exynos4: convert
to CONFIG_MULTI_IRQ_HANDLER")
- Adds restart specifier as done for other machines in commit
9eb4859564 ("ARM: 7262/1: restart: EXYNOS: use new restart hook")
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
If the number of tx/rx queues changes the ethtool ioctl
ETHTOOL_GSTATS may overrun the userspace buffer. This
occurs because the general practice in user space to
query stats is to issue a ETHTOOL_GSSET cmd to learn the
buffer size needed, allocate the buffer, then call
ETHTOOL_GSTIRNGS and ETHTOOL_GSTATS. If the number of
real_num_queues is changed or flow control attributes
are changed after ETHTOOL_GSSET but before the
ETHTOOL_GSTRINGS/ETHTOOL_GSTATS a user space buffer
overrun occurs.
To fix the overrun always return the max buffer size
needed from get_sset_count() then return all strings
and stats from get_strings()/get_ethtool_stats().
This _will_ change the output from the ioctl() call
which could break applications and script parsing in
theory. I believe these changes should not break existing
tools because the only changes will be more {tx|rx}_queues
and the {tx|rx}_pb_* stats will always be returned.
Existing scripts already need to handle changing number
of queues because this occurs today depending on system
and current features. The {tx|rx}_pb_* stats are at the
end of the output and should be handled by scripts today
regardless.
Finally get_ethtool_stats and get_strings are free-form
outputs tools parsing these outputs should be defensive
anyways. In the end these updates are better then
having a tool segfault because of a buffer overrun.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Users expect the up2tc mapping to be maintained across a DCB
enable/disable/enable transition. And since we maintain all
the other DCB attributes we should do this for up2tc mappings
as well just to be consistent. Also without this we break
user space applications that expect this to occur that
previously worked.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
If the netdev is already in NETREG_UNREGISTERING/_UNREGISTERED state, do not
update the real num tx queues. netdev_queue_update_kobjects() is already
called via remove_queue_kobjects() at NETREG_UNREGISTERING time. So, when
upper layer driver, e.g., FCoE protocol stack is monitoring the netdev
event of NETDEV_UNREGISTER and calls back to LLD ndo_fcoe_disable() to remove
extra queues allocated for FCoE, the associated txq sysfs kobjects are already
removed, and trying to update the real num queues would cause something like
below:
...
PID: 25138 TASK: ffff88021e64c440 CPU: 3 COMMAND: "kworker/3:3"
#0 [ffff88021f007760] machine_kexec at ffffffff810226d9
#1 [ffff88021f0077d0] crash_kexec at ffffffff81089d2d
#2 [ffff88021f0078a0] oops_end at ffffffff813bca78
#3 [ffff88021f0078d0] no_context at ffffffff81029e72
#4 [ffff88021f007920] __bad_area_nosemaphore at ffffffff8102a155
#5 [ffff88021f0079f0] bad_area_nosemaphore at ffffffff8102a23e
#6 [ffff88021f007a00] do_page_fault at ffffffff813bf32e
#7 [ffff88021f007b10] page_fault at ffffffff813bc045
[exception RIP: sysfs_find_dirent+17]
RIP: ffffffff81178611 RSP: ffff88021f007bc0 RFLAGS: 00010246
RAX: ffff88021e64c440 RBX: ffffffff8156cc63 RCX: 0000000000000004
RDX: ffffffff8156cc63 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88021f007be0 R8: 0000000000000004 R9: 0000000000000008
R10: ffffffff816fed00 R11: 0000000000000004 R12: 0000000000000000
R13: ffffffff8156cc63 R14: 0000000000000000 R15: ffff8802222a0000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffff88021f007be8] sysfs_get_dirent at ffffffff81178c07
#9 [ffff88021f007c18] sysfs_remove_group at ffffffff8117ac27
#10 [ffff88021f007c48] netdev_queue_update_kobjects at ffffffff813178f9
#11 [ffff88021f007c88] netif_set_real_num_tx_queues at ffffffff81303e38
#12 [ffff88021f007cc8] ixgbe_set_num_queues at ffffffffa0249763 [ixgbe]
#13 [ffff88021f007cf8] ixgbe_init_interrupt_scheme at ffffffffa024ea89 [ixgbe]
#14 [ffff88021f007d48] ixgbe_fcoe_disable at ffffffffa0267113 [ixgbe]
#15 [ffff88021f007d68] vlan_dev_fcoe_disable at ffffffffa014fef5 [8021q]
#16 [ffff88021f007d78] fcoe_interface_cleanup at ffffffffa02b7dfd [fcoe]
#17 [ffff88021f007df8] fcoe_destroy_work at ffffffffa02b7f08 [fcoe]
#18 [ffff88021f007e18] process_one_work at ffffffff8105d7ca
#19 [ffff88021f007e68] worker_thread at ffffffff81060513
#20 [ffff88021f007ee8] kthread at ffffffff810648b6
#21 [ffff88021f007f48] kernel_thread_helper at ffffffff813c40f4
Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch fixes an issue in which RSC will generate corrupted frames when
PAGE_SIZE is larger than 8K. Specifically it looks like that in 2.6.39 a
change was made so that GRO would always have at least 16 frags available
for coalescing, but the ixgbe RSC logic was not updated. As such the RSC
feature would generate a frame larger than 64K and then overflow the value
in the IP length field.
To correct that I am now basing things on the PAGE_SIZE.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
A check for the number of VFs allocated should have used a greater than
equal operator instead of just greater than. This caused allocation of
exactly 32 VFs to not enable the PF transmit and receive enables.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs. Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.
This bug exists in 3.2 stable as well as 3.3 release candidates.
CC: stable@vger.kernel.org
Reported-by: David Ahern <daahern@cisco.com>
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs. Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.
This is applicable to 3.2+ kernels.
CC: stable@vger.kernel.org
Reported-by: David Ahern <daahern@cisco.com>
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Commit d5bc77a223 broke Wake-on-LAN by
inadvertently dropping the enabling of DMA receives.
Restore the enabling of DMA receives for WoL.
This is applicable to 3.1+ stable trees.
CC: stable@vger.stable.org
Reported-by: Tobias Klausmann <klausman@schwarzvogel.de>
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Tested-by: Tobias Klausmann <klausman@schwarzvogel.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The new HP laptops turns off the mute LED with VREF50 or VREF80, but
not in HIZ unlike the previous models. Since VREF50 (also 80) works
with the previous models, let's use VREF50 for all.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
