| Age | Commit message (Collapse) | Author |
|---|
|
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
|
|
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an error status.
If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.
For example, usb_reset_and_verify_device calls into hub_port_init in a
loop. Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers. Then the port will be disabled, but the udev will remain in
tact. usb_reset_and_verify_device will call into hub_port_init again.
On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command. This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail. The port will be disabled, and
the device won't be able to enumerate.
Fix this by ignoring the return value of the HCD reset_device callback.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
|
|
USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset. In that case, the warm reset change bit
will be set, and the link state change bit may also be set. Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs. If these bits are not cleared, we may lose port change events
from the roothub.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
|
|
A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK. If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).
The xHCI code to compute the NAK interval does not handle the special
case of zero properly. The current code unconditionally subtracts one
from bInterval and uses it as an exponent. This causes a very large
bInterval to be used, and warning messages like these will be printed:
usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.
This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".
Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
|
|
nfs_open_permission_mask() should only check MAY_EXEC for files that
are opened with __FMODE_EXEC.
Also fix NFSv4 access-in-open path in a similar way -- openflags must be
used because fmode will not always have FMODE_EXEC set.
This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=49101
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pinctrl fixes from Linus Walleij:
"A first round of pinctrl fixes for v3.8:
- i.MX5 register configuration
- Swap a kfree to devm_kfree() to avoid memory corruption in the at91
driver
- Add the missing device tree binding doc for the SIRF pin controller
- Enable the SIRF GPIO pull up/down configuration from the device
tree, it was previously retired from the hard-coded approach.
- NULL check for the prcm_base in the Nomadik pin controller.
- Provide the prcm_base from the device tree in the DT boot path for
the Nomadik pin controller."
* tag 'pinctrl-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
ARM: ux500: add pinctrl address resources
pinctrl: nomadik: return if prcm_base is NULL
pinctrl: sirf: enable GPIO pullup/down configuration from dts
pinctrl: sirf: add missing DT-binding document
pinctrl: fix comment mistake
drivers/pinctrl/pinctrl-at91.c: convert kfree to devm_kfree
pinctrl: imx5: fix GPIO_8 pad CAN1_RXCAN configuration
|
|
DDC information can be accessed using AUX CH
Fixes failure to probe monitors on some systems with
DP bridge chips.
agd5f: minor fixes
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
Pull f2fs bug fixes from Jaegeuk Kim:
"This patch-set includes two major bug fixes:
- incorrect IUsed provided by *df -i*, and
- lookup failure of parent inodes in corner cases.
[Other Bug Fixes]
- Fix error handling routines
- Trigger recovery process correctly
- Resolve build failures due to missing header files
[Etc]
- Add a MAINTAINERS entry for f2fs
- Fix and clean up variables, functions, and equations
- Avoid warnings during compilation"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs:
f2fs: unify string length declarations and usage
f2fs: clean up unused variables and return values
f2fs: clean up the start_bidx_of_node function
f2fs: remove unneeded variable from f2fs_sync_fs
f2fs: fix fsync_inode list addition logic and avoid invalid access to memory
f2fs: remove unneeded initialization of nr_dirty in dirty_seglist_info
f2fs: handle error from f2fs_iget_nowait
f2fs: fix equation of has_not_enough_free_secs()
f2fs: add MAINTAINERS entry
f2fs: return a default value for non-void function
f2fs: invalidate the node page if allocation is failed
f2fs: add missing #include <linux/prefetch.h>
f2fs: do f2fs_balance_fs in front of dir operations
f2fs: should recover orphan and fsync data
f2fs: fix handling errors got by f2fs_write_inode
f2fs: fix up f2fs_get_parent issue to retrieve correct parent inode number
f2fs: fix wrong calculation on f_files in statfs
f2fs: remove set_page_dirty for atomic f2fs_end_io_write
|
|
Pull GFS2 fixes from Steven Whitehouse:
"Here are four small bug fixes for GFS2. There is no common theme here
really, just a few items that were fixed recently.
The first fixes lock name generation when the glock number is 0. The
second fixes a race allocating reservation structures and the final
two fix a performance issue by making small changes in the allocation
code."
* git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
GFS2: Reset rd_last_alloc when it reaches the end of the rgrp
GFS2: Stop looking for free blocks at end of rgrp
GFS2: Fix race in gfs2_rs_alloc
GFS2: Initialize hex string to '0'
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc fixes from Ben Herrenschmidt:
"Here are a couple of small powerpc fixes. They aren't new bugs (and
they are both CCed to stable) but I didn't see the point of sitting on
the fixes any longer."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Add missing NULL terminator to avoid boot panic on PPC40x
powerpc/vdso: Remove redundant locking in update_vsyscall_tz()
|
|
All boards, except Amstrad E3, mark USB config with __initdata.
As a result, when you compile USB into modules, they will try to refer
already released platform data and the behaviour is undefined. For example
on Nokia 770, I get the following kernel panic when modprobing ohci-hcd:
[ 3.462158] Unable to handle kernel paging request at virtual address e7fddef0
[ 3.477050] pgd = c3434000
[ 3.487365] [e7fddef0] *pgd=00000000
[ 3.498535] Internal error: Oops: 80000005 [#1] ARM
[ 3.510955] Modules linked in: ohci_hcd(+)
[ 3.522705] CPU: 0 Not tainted (3.7.0-770_tiny+ #5)
[ 3.535552] PC is at 0xe7fddef0
[ 3.546508] LR is at ohci_omap_init+0x5c/0x144 [ohci_hcd]
[ 3.560272] pc : [<e7fddef0>] lr : [<bf003140>] psr: a0000013
[ 3.560272] sp : c344bdb0 ip : c344bce0 fp : c344bdcc
[ 3.589782] r10: 00000001 r9 : 00000000 r8 : 00000000
[ 3.604553] r7 : 00000026 r6 : 000000de r5 : c0227300 r4 : c342d620
[ 3.621032] r3 : e7fddef0 r2 : c048b880 r1 : 00000000 r0 : 0000000a
[ 3.637786] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 3.655822] Control: 0005317f Table: 13434000 DAC: 00000015
[ 3.672790] Process modprobe (pid: 425, stack limit = 0xc344a1b8)
[ 3.690643] Stack: (0xc344bdb0 to 0xc344c000)
[ 3.707031] bda0: bf0030e4 c342d620 00000000 c049e62c
[ 3.727905] bdc0: c344be04 c344bdd0 c0150ff0 bf0030f4 bf001b88 00000000 c048a4ac c345b020
[ 3.748870] bde0: c342d620 00000000 c048a468 bf003968 00000001 bf006000 c344be34 c344be08
[ 3.769836] be00: bf001bf0 c0150e48 00000000 c344be18 c00b9bfc c048a478 c048a4ac bf0037f8
[ 3.790985] be20: c012ca04 c000e024 c344be44 c344be38 c012d968 bf001a84 c344be64 c344be48
[ 3.812164] be40: c012c8ac c012d95c 00000000 c048a478 c048a4ac bf0037f8 c344be84 c344be68
[ 3.833740] be60: c012ca74 c012c80c 20000013 00000000 c344be88 bf0037f8 c344beac c344be88
[ 3.855468] be80: c012b038 c012ca14 c38093cc c383ee10 bf0037f8 c35be5a0 c049d5e8 00000000
[ 3.877166] bea0: c344bebc c344beb0 c012c40c c012aff4 c344beec c344bec0 c012bfc0 c012c3fc
[ 3.898834] bec0: bf00378c 00000000 c344beec bf0037f8 00067f39 00000000 00005c44 c000e024
[ 3.920837] bee0: c344bf14 c344bef0 c012cd54 c012befc c04ce080 00067f39 00000000 00005c44
[ 3.943023] bf00: c000e024 bf006000 c344bf24 c344bf18 c012db14 c012ccc0 c344bf3c c344bf28
[ 3.965423] bf20: bf00604c c012dad8 c344a000 bf003834 c344bf7c c344bf40 c00087ac bf006010
[ 3.987976] bf40: 0000000f bf003834 00067f39 00000000 00005c44 bf003834 00067f39 00000000
[ 4.010711] bf60: 00005c44 c000e024 c344a000 00000000 c344bfa4 c344bf80 c004c35c c0008720
[ 4.033569] bf80: c344bfac c344bf90 01422192 01427ea0 00000000 00000080 00000000 c344bfa8
[ 4.056518] bfa0: c000dec0 c004c2f0 01422192 01427ea0 01427ea0 00005c44 00067f39 00000000
[ 4.079406] bfc0: 01422192 01427ea0 00000000 00000080 b6e11008 014221aa be941fcc b6e1e008
[ 4.102569] bfe0: b6ef6300 be941758 0000e93c b6ef6310 60000010 01427ea0 00000000 00000000
[ 4.125946] Backtrace:
[ 4.143463] [<bf0030e4>] (ohci_omap_init+0x0/0x144 [ohci_hcd]) from [<c0150ff0>] (usb_add_hcd+0x1b8/0x61c)
[ 4.183898] r6:c049e62c r5:00000000 r4:c342d620 r3:bf0030e4
[ 4.205596] [<c0150e38>] (usb_add_hcd+0x0/0x61c) from [<bf001bf0>] (ohci_hcd_omap_drv_probe+0x17c/0x224 [ohci_hcd])
[ 4.248138] [<bf001a74>] (ohci_hcd_omap_drv_probe+0x0/0x224 [ohci_hcd]) from [<c012d968>] (platform_drv_probe+0x1c/0x20)
[ 4.292144] r8:c000e024 r7:c012ca04 r6:bf0037f8 r5:c048a4ac r4:c048a478
[ 4.316192] [<c012d94c>] (platform_drv_probe+0x0/0x20) from [<c012c8ac>] (driver_probe_device+0xb0/0x208)
[ 4.360168] [<c012c7fc>] (driver_probe_device+0x0/0x208) from [<c012ca74>] (__driver_attach+0x70/0x94)
[ 4.405548] r6:bf0037f8 r5:c048a4ac r4:c048a478 r3:00000000
[ 4.429809] [<c012ca04>] (__driver_attach+0x0/0x94) from [<c012b038>] (bus_for_each_dev+0x54/0x90)
[ 4.475708] r6:bf0037f8 r5:c344be88 r4:00000000 r3:20000013
[ 4.500366] [<c012afe4>] (bus_for_each_dev+0x0/0x90) from [<c012c40c>] (driver_attach+0x20/0x28)
[ 4.528442] r7:00000000 r6:c049d5e8 r5:c35be5a0 r4:bf0037f8
[ 4.553466] [<c012c3ec>] (driver_attach+0x0/0x28) from [<c012bfc0>] (bus_add_driver+0xd4/0x228)
[ 4.581878] [<c012beec>] (bus_add_driver+0x0/0x228) from [<c012cd54>] (driver_register+0xa4/0x134)
[ 4.629730] r8:c000e024 r7:00005c44 r6:00000000 r5:00067f39 r4:bf0037f8
[ 4.656738] [<c012ccb0>] (driver_register+0x0/0x134) from [<c012db14>] (platform_driver_register+0x4c/0x60)
[ 4.706542] [<c012dac8>] (platform_driver_register+0x0/0x60) from [<bf00604c>] (ohci_hcd_mod_init+0x4c/0x8c [ohci_hcd])
[ 4.757843] [<bf006000>] (ohci_hcd_mod_init+0x0/0x8c [ohci_hcd]) from [<c00087ac>] (do_one_initcall+0x9c/0x174)
[ 4.808990] r4:bf003834 r3:c344a000
[ 4.832641] [<c0008710>] (do_one_initcall+0x0/0x174) from [<c004c35c>] (sys_init_module+0x7c/0x194)
[ 4.881530] [<c004c2e0>] (sys_init_module+0x0/0x194) from [<c000dec0>] (ret_fast_syscall+0x0/0x2c)
[ 4.930664] r7:00000080 r6:00000000 r5:01427ea0 r4:01422192
[ 4.956481] Code: bad PC value
[ 4.978729] ---[ end trace 58280240f08342c4 ]---
[ 5.002258] Kernel panic - not syncing: Fatal exception
Fix this by taking a copy of the data. Also mark Amstrad E3's data with
__initdata to save some memory with multi-board kernels.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8-rc2/fixes
Some OMAP PRCM and sparse fixes against v3.8-rc1. A basic set of test
logs are available here:
http://www.pwsan.com/omap/testlogs/prcm_fixes_b_3.8-rc/20130102120724/
The 3730 Beagle XM here has an intermittent failure mounting SD root,
but the suspicion right now is that this is due to a failing SD card,
rather than any change introduced by these patches.
This second version includes a few changes requested by Tony Lindgren.
|
|
Linux was granted a new system call to load modules by file descriptor
in commit 34e1169d996a ("module: add syscall to load module from fd").
Wire it up for ia64 (ready for the Chrome port :-)
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This try to reset the dma engine when performing gpu reset. Hopefully
bringing back the gpu dma engine in sane state.
v2: agd5f: fix dma reset on cayman/TN, add support for SI
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To help debug dma related lockup.
v2: agd5f: update SI as well
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Print 32dword before last know rptr as problem most likely comes
from previous command. Also small cosmetic change to the printing.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
count must be a multiple of 2. Fixes crashes on
R6xx chips reported by a number of people.
Cc: Borislav Petkov <bp@alien8.de>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Tested-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Apple cards do not provide data tables in the vbios
so we have to hard code the connector parameters
in the driver.
Reported-by: Albrecht Dreß <albrecht.dress@arcor.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
By accident, commit eb6476441bc2fecf6232a87d0313a85f8e3da7f4
("iwlwifi: protect use_ict with irq_lock") changed the return
value of the iwl_pcie_isr() function in case it handles an
interrupt -- it now returns IRQ_NONE instead of IRQ_HANDLED.
Put back the correct return value.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Support the Creative BT-D1 Bluetooth USB audio device. Before this
patch, Linux had trouble finding the correct USB descriptors and bailed
out with these messages:
no or invalid class specific endpoint descriptor
Now it still prints these messages on hotplug:
snd-usb-audio: probe of ...:1.0 failed with error -5
snd-usb-audio: probe of ...:1.2 failed with error -5
snd-usb-audio: probe of ...:1.3 failed with error -5
But the device works correctly, including the HID support.
The patch is diff'ed against 3.8-rc1 but should apply to older kernels
as well.
Signed-off-by: Alexander Schremmer <alex@alexanderweb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The vmaster hook sends 1 for enabled/unmuted and 0 for disabled/muted,
but "Mute-LED Mode" being "On" refers to the LED being on, not the
volume being on.
Therefore "On" and "Off" should be switched.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add finit_module syscall to the syscall list.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
regulator_register() does not return 0 on success, fix the comment.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Since commit 2aacdff entitled "cpufreq: Move common part from governors
to separate file", whenever the drivers that depend on this new file
(cpufreq_ondemand or cpufreq_conservative) are built as modules, a new
module named cpufreq_governor is created because the Makefile includes
cpufreq_governor.o twice. As drivers/cpufreq/cpufreq_governor.c contains no
MODULE directives, the resulting module has no license specified, which
results in logging of a "module license 'unspecified' taints kernel". In
addition, a number of globals are exported GPL only, and are therefore
not available. This fix establishes a new boolean configuration variable
that forces cpufreq_governor.o to be linked into the kernel whenever
either cpufreq_ondemand or cpufreq_conservative is selected.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This is only solution I can think of. User decides if he wants this
driver on his machine. I don't have enough knowledge and time to find
the reason why same code works on some machines and doesn't on others
which use the same, or very similar, chipset and processor.
Signed-off-by: Rafał Bilski <rafalbilski@interia.pl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch forces complete struct cpufreq_stats allocation for all cpus before
registering CPUFREQ_TRANSITION_NOTIFIER notifier, otherwise in some conditions
cpufreq_stat_notifier_trans() can be called in the middle of stats allocation,
in this case cpufreq_stats_table already exists, but stat->freq_table is NULL.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit bf4d1b5 (cpuidle: support multiple drivers) introduced
locking in cpuidle_get_cpu_driver(), which is used in the
idle_call() function.
This leads to a contention problem with a large number of CPUs,
because they all try to run the idle routine at the same time.
The lock can be safely removed because of how is used the cpuidle
API. Namely, cpuidle_register_driver() is called first, but the
cpuidle idle function is not entered before cpuidle_register_device()
is called, because the cpuidle device is not enabled then. Moreover,
cpuidle_unregister_driver(), which would reset the driver value to
NULL, is not called before cpuidle_unregister_device().
All of the cpuidle drivers use the API in the same way.
In general, a cleanup around the lock is necessary and a proper
refcounting mechanism should be used to ensure the consistency in the
API (for example, cpuidle_unregister_driver() should fail if the
driver's refcount is not 0). However, these modifications will require
some code reorganization and rewrite which will be too intrusive for
a fix.
For this reason, fix the contention problem introduced by commit
bf4d1b5 by simply removing the locking from cpuidle_get_cpu_driver(),
which restores the original behavior of that routine.
[rjw: Changelog.]
Reported-and-tested-by: Russ Anderson <rja@sgi.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When debug kernel, the the below information is found:
intel_idle: unaware of model 0x1a MWAIT 4 please contact lenb@kernel.orgACPI: Device input0 -> No ACPI support
so this patch separates it.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ready_waiting_counts atomic variable is compared against the wrong
online cpu count. The latter is computed incorrectly using logical-OR
instead of bit-OR. This patch fixes that.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Colin Cross <ccross@android.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since cpuidle_state.power_usage is a signed value, use INT_MAX (instead
of -1) to init the local copies so that functions that tries to find
cpuidle states with minimum power usage works correctly even if they use
non-negative values.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The patch copies the flags masked by IORESOURCE_BITS from a resource's
template. This is necessary because the resource settings require proper
IORESOURCE_BITS which are not known during the definition of these resources
using the "/sys/bus/pnp/*/*/resources" interface. (In fact, they should not
be set by the user as the resource templates define the proper settings.)
If the patch is not applied, the resource flags are not initialized properly
and obscure messages in the kernel log have been seen ("invalid flags").
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch factors out the setting of PNP resources into one function which is
then reused for all PNP resource types. This makes the code more concise and
avoids duplication. The parameters "type" and "flags" are not used at the
moment but may be used by follow-up patches. Placeholders for these patches
can be found in the comment lines that contain the "TBD" marker.
As the code does not make any changes to the ABI, no regressions are expected.
NB: While at it, support for bus type resources is added.
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After commit 71fbad6 (PCI/ACPI: Notify PCI devices when their power
resource is turned on) made acpi_pci_bind() call
acpi_power_resource_register_device(), the debug message at the end
of the latter appears in the kernel log for every PCI device that
doesn't happen to have power resources assigned (which is the vast
majority of them). However, this message is totally useless, because
it doesn't even say which device it is about. Moreover, it is
misleading, because it only means that the given device has no power
resources, which isn't exceptional at all.
Remove that useless message altogether and simplify
acpi_power_resource_register_device() slightly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Currently these DBG statements are emitted at KERN_DEFAULT.
Change the macro to emit at KERN_DEBUG.
This can help avoid unexpected message interleaving.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since the return value of acpi_bus_get_device() is not of type
acpi_status, ACPI_SUCCESS() should not be used for checking its
return value. Fix that.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
When memory hotadd, acpi_memory_enable_device has already been done
at drv->ops.add (acpi_memory_device_add), no need to do it again
at notify callback.
At acpi_memory_enable_device, acpi_memory_get_device_resources
is also a redundant action, since it has been done at drv->ops.add.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
If the persistent store is empty initially, the function 'erst_dbg_read'
returns a nonzero value. The better way is to return a zero indicating the
read operation reaches EOF.
Tested on two different servers.
Signed-off-by: Adrian Huang <adrian.huang@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The mini-C library implementation is used by the embedded ACPICA users
other than Linux. It was added to the kernel source to make it easier
to incorporate future ACPICA changes, but as it turns our we can avoid
carrying it thanks to some ACPICA release process tweaks, so remove
drivers/acpi/acpica/utclib.c from the kernel source tree.
[rjw: Modified the changelog slightly.]
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The maximum MTU shouldn't take the headers into account,
the maximum MSDU size is exactly the maximum MTU.
Signed-off-by: T Krishna Chaitanya <chaitanyatk@posedge.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When AP's SSID is hidden the BSS can appear several times in
cfg80211's BSS list: once with a zero-length SSID that comes
from the beacon, and once for each SSID from probe reponses.
Since the mac80211 stores its data in ieee80211_bss which
is embedded into cfg80211_bss, mac80211's data will be
duplicated too.
This becomes a problem when a driver needs the dtim_period
since this data exists only in the beacon's instance in
cfg80211 bss table which isn't the instance that is used
when associating.
Remove the DTIM period from the BSS table and track it
explicitly to avoid this problem.
Cc: stable@vger.kernel.org
Tested-by: Efi Tubul <efi.tubul@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This is a very old bug, but there's nothing that prevents the
timer from running while the module is being removed when we
only do del_timer() instead of del_timer_sync().
The timer should normally not be running at this point, but
it's not clearly impossible (or we could just remove this.)
Cc: stable@vger.kernel.org
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Unfortunately, commit b22cfcfcae5b, intended to speed up roaming
by avoiding the synchronize_rcu() broke AP/mesh modes as it moved
some code into that work item that will still call into the driver
at a time where it's no longer expected to handle this: after the
AP or mesh has been stopped.
To fix this problem remove the per-station work struct, maintain a
station cleanup list instead and flush this list when stations are
flushed. To keep this patch smaller for stable, do this when the
stations are flushed (sta_info_flush()). This unfortunately brings
back the original roaming delay; I'll fix that again in a separate
patch.
Also, Ben reported that the original commit could sometimes (with
many interfaces) cause long delays when an interface is set down,
due to blocking on flush_workqueue(). Since we now maintain the
cleanup list, this particular change of the original patch can be
reverted.
Cc: stable@vger.kernel.org [3.7]
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The array of rmc_entrys is redundant since only the
list_head is used. Make this an array of list_heads
instead and save ~6k per vif at runtime :D
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Make AP_VLAN type interfaces track the AP master channel
context so they have one assigned for the various lookups.
Don't give them their own refcount etc. since they're just
slaves to the AP master.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
[change to flush stations with AP flush in second loop]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this
can trigger Microcode errors on iwlwifi and iwlegacy drivers.
Also rename ieee80211_request_internal_scan() function since it is only
used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss().
This patch should address:
https://bugzilla.redhat.com/show_bug.cgi?id=883414
https://bugzilla.kernel.org/show_bug.cgi?id=49411
Reported-by: Jesse Kahtava <jesse_kahtava@f-m.fm>
Reported-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This should be the part of this patch:
"highmem: kill all __kmap_atomic()"
(sha1: a24401bcf4a67c8fe17e649e74eeb09b08b79ef5)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
All files which uses user unified macros from uaccess.h
(get_user/put_user/clear_user/copy_tofrom_user/
strnlen_user and strncpy_user) generate this
warning messages:
Assembler messages:
Warning: ignoring changed section attributes for .discard
Setting up discard executable section flang for __EX_TABLE_SECTION
macro removed all these warnings.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
