| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
John W. Linville says:
====================
On the NFC bits, Samuel says:
"With this one we have:
- A fix for properly decreasing socket ack log.
- A timer and works cleanup upon NFC device removal.
- A monitoroing socket cleanup round from llcp_socket_release.
- A proper error report to pending sockets upon NFC device removal."
Regarding the Bluetooth bits, Gustavo says:
"I have these two patches for 3.9, these add support for two more devices to
the bluetooth drivers."
Along with those, we have a few wireless driver fixes...
Bing Zhao provides an mwifiex to prevent an out-of-bounds memory
access.
John Crispin offers a Kconfig fix to enable some otherwise dead code
in rt2x00. The correct symbols were added in -rc1 through a different
tree, but the symbols for enabling the wireless driver didn't match.
Larry Finger brings an rtlwifi fix for a scheduling while atomic bug,
and another fix for a reassociation problem caused by failing to
clear the BSSID after a disconnect.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
cpdma_check_free_tx_desc()
Fix which was done in the following commit in cpsw driver has
to be taken forward to davinci emac driver as well.
commit d35162f89b8f00537d7b240b76d2d0e8b8d29aa0
Author: Daniel Mack <zonque@gmail.com>
Date: Tue Mar 12 06:31:19 2013 +0000
net: ethernet: cpsw: fix usage of cpdma_check_free_tx_desc()
Commit fae50823d0 ("net: ethernet: davinci_cpdma: Add boundary for rx
and tx descriptors") introduced a function to check the current
allocation state of tx packets. The return value is taken into account
to stop the netqork queue on the adapter in case there are no free
slots.
However, cpdma_check_free_tx_desc() returns 'true' if there is room in
the bitmap, not 'false', so the usage of the function is wrong.
Reported-by: Prabhakar Lad <prabhakar.csengg@gmail.com>
Tested-by: Prabhakar Lad <prabhakar.csengg@gmail.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The automated ARM build tests have shown that the tulip de4x5 driver
uses the old-style virt_to_bus() interface on some architectures.
Alpha, Sparc and PowerPC did not hit this problem, because they
use a different code path, and most other architectures actually
do provide VIRT_TO_BUS.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Grundler <grundler@parisc-linux.org>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Disabling CONFIG_VIRT_TO_BUS on ARM showed that the hisax netjet
driver depends on this deprecated functionality but is not
marked so in Kconfig.
Rather than adding ARM to the already long list of architectures
that this driver is broken on, this patch adds 'depends on
VIRT_TO_BUS' and removes the dependency on !SPARC, which is
also implied by that.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
commit bd329e1 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
introduced a new policy, preferring MBIM for dual NCM/MBIM functions if
the cdc_mbim driver was enabled. This caused a regression for users
wanting to use NCM.
Devices implementing NCM backwards compatibility according to section
3.2 of the MBIM v1.0 specification allow either NCM or MBIM on a single
USB function, using different altsettings. The cdc_ncm and cdc_mbim
drivers will both probe such functions, and must agree on a common
policy for selecting either MBIM or NCM. Until now, this policy has
been set at build time based on CONFIG_USB_NET_CDC_MBIM.
Use a module parameter to set the system policy at runtime, allowing the
user to prefer NCM on systems with the cdc_mbim driver.
Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Reported-by: Geir Haatveit <nospam@haatveit.nu>
Reported-by: Tommi Kyntola <kynde@ts.ray.fi>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54791
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Range/validity checks on rta_type in rtnetlink_rcv_msg() do
not account for flags that may be set. This causes the function
to return -EINVAL when flags are set on the type (for example
NLA_F_NESTED).
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Correct spelling typos in Documentation/sound/alsa
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
unconditionally"
This reverts commit 412ed94744d16806fbec3bd250fd94e71cde5a1f.
The commit is wrong as tiph points to the outer IPv4 header which is
installed at ipgre_header() and not the inner one which is protocol dependant.
This commit broke succesfully opennhrp which use PF_PACKET socket with
ETH_P_NHRP protocol. Additionally ssl_addr is set to the link-layer
IPv4 address. This address is written by ipgre_header() to the skb
earlier, and this is the IPv4 header tiph should point to - regardless
of the inner protocol payload.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Now we use ESID_BITS of kernel address to build proto vsid. So rename
USER_ESIT_BITS to ESID_BITS
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.8]
|
|
This patch change the kernel VSID range so that we limit VSID_BITS to 37.
This enables us to support 64TB with 65 bit VA (37+28). Without this patch
we have boot hangs on platforms that only support 65 bit VA.
With this patch we now have proto vsid generated as below:
We first generate a 37-bit "proto-VSID". Proto-VSIDs are generated
from mmu context id and effective segment id of the address.
For user processes max context id is limited to ((1ul << 19) - 5)
for kernel space, we use the top 4 context ids to map address as below
0x7fffc - [ 0xc000000000000000 - 0xc0003fffffffffff ]
0x7fffd - [ 0xd000000000000000 - 0xd0003fffffffffff ]
0x7fffe - [ 0xe000000000000000 - 0xe0003fffffffffff ]
0x7ffff - [ 0xf000000000000000 - 0xf0003fffffffffff ]
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Tested-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.8]
|
|
VSID_BITS and VSID_BITS_1T depends on the context bits and user esid
bits. Make the dependency explicit
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.8]
|
|
Our kernel is not much good without BINFMT_ELF and this fixes a build
warning on 64 bit allnoconfig builds:
warning: (COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
With some CONFIGS it's possible that in ppc_set_hwdebug, brk.len is
uninitialised before being used. It has been reported that GCC 4.2 will
produce the following error in this case:
arch/powerpc/kernel/ptrace.c:1479: warning: 'brk.len' is used uninitialized in this function
arch/powerpc/kernel/ptrace.c:1381: note: 'brk.len' was declared here
This patch corrects this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reported-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Spotted by Fenguan Wu's super build robot.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Changes in v2 include:
o Fixed spelling of guarantee.
o Fixed potential memory leak if slot reset fails out.
o Changed list_for_each_entry_safe with list_for_each_entry.
Signed-off-by: Philip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Both mci.mem_is_per_rank and mci.csbased denote the same thing: the
memory controller is csrows based. Merge both fields into one.
There's no need for the driver to actually fill it, as the core detects
it by checking if one of the layers has the csrows type as part of the
memory hierarchy:
if (layers[i].type == EDAC_MC_LAYER_CHIP_SELECT)
per_rank = true;
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
|
|
We were filling the csrow size with a wrong value. 16a528ee3975 ("EDAC:
Fix csrow size reported in sysfs") tried to address the issue. It fixed
the report with the old API but not with the new one. Correct it for the
new API too.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[ make it a per-csrow accounting regardless of ->channel_count ]
Signed-off-by: Borislav Petkov <bp@suse.de>
|
|
Users report that an extent map's list is still linked when it's actually
going to be freed from cache.
The story is that
a) when we're going to drop an extent map and may split this large one into
smaller ems, and if this large one is flagged as EXTENT_FLAG_LOGGING which means
that it's on the list to be logged, then the smaller ems split from it will also
be flagged as EXTENT_FLAG_LOGGING, and this is _not_ expected.
b) we'll keep ems from unlinking the list and freeing when they are flagged with
EXTENT_FLAG_LOGGING, because the log code holds one reference.
The end result is the warning, but the truth is that we set the flag
EXTENT_FLAG_LOGGING only during fsync.
So clear flag EXTENT_FLAG_LOGGING for extent maps split from a large one.
Reported-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Reported-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
Pull kbuild fix from Michal Marek:
"One fix for for make headers_install/headers_check to not require make
3.81. The requirement has been accidentally introduced in 3.7."
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: fix make headers_check with make 3.80
|
|
Pull OpenRISC bug fixes from Jonas Bonn:
- The GPIO descriptor work has exposed how broken the non-GPIOLIB bits
for OpenRISC were. We now require GPIOLIB as this is the preferred
way forward.
- The system.h split introduced a bug in llist.h for arches using
asm-generic/cmpxchg.h directly, which is currently only OpenRISC.
The patch here moves two defines from asm-generic/atomic.h to
asm-generic/cmpxchg.h to make things work as they should.
- The VIRT_TO_BUS selector was added for OpenRISC, but OpenRISC does
not have the virt_to_bus methods, so there's a patch to remove it
again.
* tag 'for-3.9-rc3' of git://openrisc.net/jonas/linux:
openrisc: remove HAVE_VIRT_TO_BUS
asm-generic: move cmpxchg*_local defs to cmpxchg.h
openrisc: require gpiolib
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc fixes from Greg Kroah-Hartman:
"Here are some tiny fixes for the w1 drivers and the final removal
patch for getting rid of CONFIG_EXPERIMENTAL (all users of it are now
gone from your tree, this just drops the Kconfig item itself.)
All have been in the linux-next tree for a while"
* tag 'char-misc-3.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
final removal of CONFIG_EXPERIMENTAL
w1: fix oops when w1_search is called from netlink connector
w1-gpio: fix unused variable warning
w1-gpio: remove erroneous __exit and __exit_p()
ARM: w1-gpio: fix erroneous gpio requests
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes, as expected for the middle rc:
- A couple of fixes for potential NULL dereferences and out-of-range
array accesses revealed by static code parsers
- A fix for the wrong error handling detected by trinity
- A regression fix for missing audio on some MacBooks
- CA0132 DSP loader fixes
- Fix for EAPD control of IDT codecs on machines w/o speaker
- Fix a regression in the HD-audio widget list parser code
- Workaround for the NuForce UDH-100 USB audio"
* tag 'sound-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix missing EAPD/GPIO setup for Cirrus codecs
sound: sequencer: cap array index in seq_chn_common_event()
ALSA: hda/ca0132 - Remove extra setting of dsp_state.
ALSA: hda/ca0132 - Check download state of DSP.
ALSA: hda/ca0132 - Check if dspload_image succeeded.
ALSA: hda - Disable IDT eapd_switch if there are no internal speakers
ALSA: hda - Fix snd_hda_get_num_raw_conns() to return a correct value
ALSA: usb-audio: add a workaround for the NuForce UDH-100
ALSA: asihpi - fix potential NULL pointer dereference
ALSA: seq: Fix missing error handling in snd_seq_timer_open()
|
|
git://git.linaro.org/people/mszyprowski/linux-dma-mapping
Pull DMA-mapping fix from Marek Szyprowski:
"An important fix for all ARM architectures which use ZONE_DMA.
Without it dma_alloc_* calls with GFP_ATOMIC flag might have allocated
buffers outsize DMA zone."
* 'fixes-for-3.9' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping:
ARM: DMA-mapping: add missing GFP_DMA flag for atomic buffer allocation
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes
Pull MFD fixes from Samuel Ortiz:
"This is the first batch of MFD fixes for 3.9.
With this one we have:
- An ab8500 build failure fix.
- An ab8500 device tree parsing fix.
- A fix for twl4030_madc remove routine to work properly (when
built-in).
- A fix for properly registering palmas interrupt handler.
- A fix for omap-usb init routine to actually write into the
hostconfig register.
- A couple of warning fixes for ab8500-gpadc and tps65912"
* tag 'mfd-fixes-3.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes:
mfd: twl4030-madc: Remove __exit_p annotation
mfd: ab8500: Kill "reg" property from binding
mfd: ab8500-gpadc: Complain if we fail to enable vtvout LDO
mfd: wm831x: Don't forward declare enum wm831x_auxadc
mfd: twl4030-audio: Fix argument type for twl4030_audio_disable_resource()
mfd: tps65912: Declare and use tps65912_irq_exit()
mfd: palmas: Provide irq flags through DT/platform data
mfd: Make AB8500_CORE select POWER_SUPPLY to fix build error
mfd: omap-usb-host: Actually update hostconfig
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
"Bug fixes for pmbus, ltc2978, and lineage-pem drivers
Added specific maintainer for some hwmon drivers"
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (pmbus/ltc2978) Fix temperature reporting
hwmon: (pmbus) Fix krealloc() misuse in pmbus_add_attribute()
hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes
MAINTAINERS: Add maintainer for MAX6697, INA209, and INA2XX drivers
|
|
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Richland APUs are a new version of the Trinity APUs
with performance and power management improvements.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Remove old comment and allow benchmarking moves within the
same memory domain for both dma and blit methods.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fixes a segfault on asics without a blit callback.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=62239
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Need to adjust the backend map depending on which RB is
enabled. This is the trinity equivalent of:
f7eb97300832f4fe5fe916c5d84cd2e25169330e
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57919
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
We weren't properly tearing down the VM sub-alloctor
on suspend leading to bogus VM PTs on resume.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60439
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Dmitry Cherkasov <Dmitrii.Cherkasov@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
The code in 8250.c for detecting ARM/XScale UARTs says:
* Try writing and reading the UART_IER_UUE bit (b6).
* If it works, this is probably one of the Xscale platform's
* internal UARTs.
If the above passes, it then goes on to:
* It's an Xscale.
* We'll leave the UART_IER_UUE bit set to 1 (enabled).
However, the CH352 uses the UART_IER_UUE as the LOWPOWER function,
so it is readable and writable. According to the datasheet:
"LOWPOWER:When the bit is 1, close the internal benchmark
clock of serial port to set into low-power status.
So it essentially gets mis-detected as Xscale, and gets
powered down in the process. The device in question where
this was seen is listed by lspci as:
Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
Re-using the 353 quirk which just sets flags to fixed and type
to 16550 is suitable for fixing the 352 as well.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Index of atmel_ports[ATMEL_MAX_UART] should be smaller
than ATMEL_MAX_UART.
Signed-off-by: Pawel Wieczorkiewicz <wpawel@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When sending between processes, we always schedule a work item. Our work info
struct has the message embedded in the middle, which means that we end up
overwriting subsequent fields when we copy the (variable-length) message into
it. Move it to the end of the struct.
Acked-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Andy King <acking@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus
Chanwoo writes:
extcon fixes for 3.9-rc3
This is small fixes against 3.9-rc2.
Fix to max77693 extcon driver:
- Set default value of MUIC register to bring up it.
Fix to max8997 extcon driver:
- Fix null pointer error duing probe when platform data
isn't used.
|
|
This patch (as1663) fixes a regression caused by commit
6e0c3339a6f19d748f16091d0a05adeb1e1f822b (USB: EHCI: unlink one async
QH at a time). In order to avoid keeping multiple QHs in an unusable
intermediate state, that commit changed unlink_empty_async() so that
it unlinks only one empty QH at a time.
However, when the EHCI root hub is suspended, _all_ async QHs need to
be unlinked. ehci_bus_suspend() used to do this by calling
unlink_empty_async(), but now this only unlinks one of the QHs, not
all of them.
The symptom is that when the root hub is resumed, USB communications
don't work for some period of time. This is because ehci-hcd doesn't
realize it needs to restart the async schedule; it assumes that
because some QHs are already on the schedule, the schedule must be
running.
The easiest way to fix the problem is add a new function that unlinks
all the async QHs when the root hub is suspended.
This patch should be applied to all kernels that have the 6e0c3339a6f1
commit.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Adrian Bassett <adrian.bassett@hotmail.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Device stucks on filesystem writes, unless following quirk is passed:
echo 04e8:5136:m > /sys/module/usb_storage/parameters/quirks
Add corresponding entry to unusual_devs.h
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
v3: Be careful to not break XHCI_BROKEN_MSI workaround (by trenn)
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Frederik Himpe <fhimpe@vub.ac.be>
Cc: David Haerdeman <david@hardeman.nu>
Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The vfio drivers call kmalloc or kzalloc, but do not
include <linux/slab.h>, which causes build errors on
ARM.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org
|
|
This fixes failure during initialization on Lynx Point LP devices.
ME driver needs to release the device from the reset
only after the FW has completed its flow and indicated
it by delivering an interrupt to the host.
This is the correct behavior for all the ME devices yet the
the previous versions are less susceptive to the implementation
that ignored FW reset completion indication.
We add mei_me_hw_reset_release function which is called
after reset from the interrupt thread or directly
from mei_reset during power down.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
mei_stop calls mei_reset with disabling the interrupts.
It will have the same effect as the open code it replaces in the mei_remove.
The reset sequence on remove is required for the Lynx Point LP devices
to clean the reset state.
mei_stop is called from mei_pci_suspend and mei_remove functions
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Make this depend on CONFIG_PM. This protection is necessary to not
cause any build errors with any combination of PM features especially
when supporting a new SoC where each PM features are being enabled
one-by-one during its depelopment.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
clock-event
With recent arm broadcast time clean-up from Mark Rutland, the dummy
broadcast device is always registered with timer subsystem. And since
the rating of the dummy clock event is very high, it may be preferred
over a real clock event.
This is a change in behavior from past and not an intended one. So
reduce the rating of the dummy clock-event so that real clock-event
device is selected when available.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add support for the AR9462 chip
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=0036 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Cc: <stable@vger.kernel.org>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
This patch fixes a kernel crash when using precise sampling (PEBS)
after a suspend/resume. Turns out the CPU notifier code is not invoked
on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly
by the kernel and keeps it power-on/resume value of 0 causing any PEBS
measurement to crash when running on CPU0.
The workaround is to add a hook in the actual resume code to restore
the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0,
the DS_AREA will be restored twice but this is harmless.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
There is an additional HSW CPU-id, 0x46,
which has C-states exactly like CPU-id 0x45.
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
There is an additional HSW CPU-id, 0x46,
which has C-states exactly like CPU-id 0x45.
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
git://git.pengutronix.de/git/imx/linux-2.6 into fixes
From Sascha Hauer <s.hauer@pengutronix.de>:
Two small ARM i.MX fixes for v3.9-rc
- Fix i.MX25 DT compilation
- Enable MAX clk on i.MX35
* tag 'arm-imx-fixes-for-3.9-rc' of git://git.pengutronix.de/git/imx/linux-2.6:
ARM: i.MX35: enable MAX clock
ARM: i.MX25: Fix DT compilation
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The i.MX35 has two bits per clock gate which are decoded as follows:
0b00 -> clock off
0b01 -> clock is on in run mode, off in wait/doze
0b10 -> clock is on in run/wait mode, off in doze
0b11 -> clock is always on
The reset value for the MAX clock is 0b10.
The MAX clock is needed by the SoC, yet unused in the Kernel, so the
common clock framework will disable it during late init time. It will
only disable clocks though which it detects as being turned on. This
detection is made depending on the lower bit of the gate. If the reset
value has been altered by the bootloader to 0b11 the clock framework
will detect the clock as turned on, yet unused, hence it will turn it
off and the system locks up.
This patch turns the MAX clock on unconditionally making the Kernel
independent of the bootloader.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
