This USB ID is for the WUBI-100GW 802.11g Wireless LAN USB Device that
uses p54usb.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Eduardo Costa <ecosta.tmp@gmail.com>
Cc: Stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes regression from a6963596a13e62f8e65b1cf3403a330ff2db407c,
that missed to set cached memory type in GTT entry.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Refresh rate nearness is not calculated or reset when nearest resolution
changes.
This patch resets the refresh rate differential measurement whenever a
new nearest resolution is discovered. This fixes two error cases;
first, wherein the first mode's refresh rate differential is never
calculated and second, when the closest refresh rate from a previous
nearest resolution is erroneously preserved.
Signed-off-by: Andrew Kephart <andrew.kephart@alereon.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Buffer transfer size is the number of transfers to be performed in
relation with the width of the _source_ interface.
So in the DMA_FROM_DEVICE case, it should be the register width that
should be taken into account.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The commit 111c182340cd22e238ab1cc6564df336c6ebd7cb (kgdboc: reset
input devices (keyboards) when exiting debugger) introduced a
regression in early debugging such that you get a kernel oops on
continue (with the go command) if you boot a kernel with:
earlyprintk=vga ekgdboc=kbd kgdbwait
The restore kgdboc_restore_input() routine schedules work for the
purpose of sending key release events for any keys that were in the
depressed state prior to entering the kernel debugger. A simple fix
to the crash is to not invoke the schedule_work() if the kernel
system_state is anything other than SYSTEM_RUNNING.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com>
The saving of the NVS memory area during suspend and restoring it
during resume causes problems to appear on Sony Vaio VGN-NW130D, so
blacklist that machine to avoid those problems.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=23002
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Adriano <adriano.vilela@yahoo.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fault handling is getting enabled after enabling the interrupt-remapping (as
the success of interrupt-remapping can affect the apic mode and hence the
fault handling mode).
Hence there can potentially be some faults between the window of enabling
interrupt-remapping in the vt-d and the fault-handling of the vt-d units.
Handle any previous faults after enabling the vt-d fault handling.
For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the
enable_intr_remapping() and see if we can enable fault handling along with
enabling intr-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <20101201062244.630417138@intel.com>
Cc: stable@kernel.org [v2.6.32+]
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
On platforms with Intel 7500 chipset, there were some reports of system
hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled.
During kdump, there is a window where the devices might be still using old
kernel's interrupt information, while the kdump kernel is coming up. This can
cause vt-d faults as the interrupt configuration from the old kernel map to
null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled,
we still have the same issue but in this case we will see benign spurious
interrupt hit the new kernel).
Based on platform config settings, these platforms seem to generate NMI/SMI
when a vt-d fault happens and there were reports that the resulting SMI causes
the system to hang.
Fix it by masking vt-d spec defined errors to platform error reporting logic.
VT-d spec related errors are already handled by the VT-d OS code, so need to
report the same error through other channels.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com>
Cc: stable@kernel.org [v2.6.32+]
Reported-by: Max Asbock <masbock@linux.vnet.ibm.com>
Reported-and-tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Fixed fsl dma slow issue by initializing dma mode register with
bandwidth control. It boosts dma performance and should works
with 85xx board.
Signed-off-by: Forrest Shi <b29237@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The code wants to check if there's a channel and it is not disabled,
but it used to check if channel is not NULL and accessed the channel
struct if this check failed.
Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ltc4215 driver used the chip's "power good" status bit to provide
the power1_alarm file. This is wrong: the chip is really reporting the
status of one of the monitored voltages.
Change the sysfs file from power1_alarm to in2_min_alarm instead. This
matches the voltage that the chip is raising an alarm for.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
__pppoe_xmit function return value was invalid resulting in
additional call to kfree_skb on already freed skb. This resulted in
memory corruption and consequent kernel panic after PPPoE peer
terminated the link.
This fixes commit 55c95e738da85373965cb03b4f975d0fd559865b.
Reported-by: Gorik Van Steenberge <gvs@zemos.net>
Reported-by: Daniel Kenzelmann <kernel.bugzilla@kenzelmann.dyndns.info>
Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Reported-by: Pawel Staszewski <pstaszewski@artcom.pl>
Diagnosed-by: Andrej Ota <andrej@ota.si>
Diagnosed-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Tested-by: Pawel Staszewski <pstaszewski@artcom.pl>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: Andrej Ota <andrej@ota.si>
Signed-off-by: David S. Miller <davem@davemloft.net>
We must not wake the TX queue without free TX descriptors.
sca_xmit() expects at least one free descriptor and BUGs otherwise.
Problem reported and fix tested by Bernie Innocenti and Ward Vandewege.
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bnx2x_src_init_t2() is used only when BCM_CNIC is defined.
So, to avoid a compilation warning, we won't define it unless
BCM_CNIC is defined.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make the LSO code work on BE platforms: parsing_data field of
a parsing BD (PBD) for 57712 was improperly composed which made FW read wrong
values for TCP header's length and offset and, as a result, the corresponding
PCI device was performing bad DMA reads triggering EEH.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Removing usage of rtnl_lock() to protect firmware interface registers.
These registers are accessed in some worker threads and can create a
deadlock if rtnl_lock is taken by upper layers while the worker is still
pending.
We remove rtnl_lock and use a driver mutex just while mailboxes are
accessed.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Agere FW643 rev 06, listed as "11c1:5901 (rev 06) (prog-if 10 [OHCI])",
produced SBP-2 I/O errors since kernel 2.6.36. Disabling MSI fixes it.
Since MSI work on Agere FW643-E (same vendor and device ID, but rev 07),
introduce a device revision field into firewire-ohci's quirks list so
that different quirks can be defined for older and newer revisions.
Reported-by: Jonathan Isom <jeisom@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org> # 2.6.36.y
"VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]"
does not generate any interrupts if Message Signaled Interrupts were
enabled. This is a regression since kernel 2.6.36 in which MSI support
was added to firewire-ohci. Hence blacklist MSI on all VIA controllers.
Reported-by: Robin Cook <rcook@wyrms.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org> # 2.6.36.y
Add the features struct and device table entry to enable yet another
version of Wacom Bamboo Pen (CTL460, Product ID 0xD4).
Signed-off-by: Kevin Granade <kevin.granade@gmail.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Properly const-, __init-, and __read_mostly-annotate this code.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When CONFIG_CPU_FREQ=n ...
drivers/acpi/processor_thermal.c:159:12: warning: ‘acpi_thermal_cpufreq_increase’ defined but not used
drivers/acpi/processor_thermal.c:163:12: warning: ‘acpi_thermal_cpufreq_decrease’ defined but not used
Remove unused declaration of ‘acpi_thermal_cpufreq_increase’ and
‘acpi_thermal_cpufreq_decrease’
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
WARNING: drivers/acpi/acpi.o(.text+0xeda): Section mismatch in reference from the function acpi_os_initialize1() to the function .init.text:set_osi_linux()
The function acpi_os_initialize1() references
the function __init set_osi_linux().
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ERST writing may be used in NMI or Machine Check Exception handler. So
it need to use raw spinlock instead of normal spinlock. This patch
fixes it.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced another regression that only one _OSI string can be added or
removed.
Now multiple _OSI strings can be added or removed, for example
acpi_osi=Linux acpi_osi=FreeBSD acpi_osi="!Windows 2006"
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced a regression that _OSI string setup fails.
There are 2 paths to setup _OSI string.
DMI:
acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI
string to osi_setup_string
Boot command line:
acpi_osi_setup -> copy _OSI string to osi_setup_string
Later, acpi_osi_setup_late will be called to handle osi_setup_string.
If _OSI string is "Linux" or "!Linux", then the call path is,
acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux ->
acpi_osi_setup -> copy _OSI string to osi_setup_string
This actually never installs _OSI string(acpi_install_interface not
called), but just copy the _OSI string to osi_setup_string.
This patch fixes the regression.
Reported-and-tested-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Was using L1_CACHE_BYTES for the Ingress Queue Entry Size but it really
needs to be 64 bytes in order to support the largest message sizes.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the IC+ IP1001 (Gigabit Ethernet Transceiver) driver.
I've had to add an additional delay (2ns) to adjust RX clock phase at
GMII/ RGMII interface (according to the PHY data-sheet). This helps to
have the RGMII working on some ST platforms.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The ATM subsystem was incorrectly creating the 'device' link for ATM
nodes in sysfs. This led to incorrect device/parent relationships
exposed by sysfs and udev. Instead of rolling the 'device' link by hand
in the generic ATM code, pass each ATM driver's bus device down to the
sysfs code and let sysfs do this stuff correctly.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pass reference to napi instead of enic device to the isr that services receive queue.
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since connector can be built as a module and uses netlink socket
to communicate. The module should have an alias to autoload when socket
of NETLINK_CONNECTOR type is requested.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
I noticed that one of the post-2.6.36 patches broke runtime PM of the
r8169 on my MSI Wind test machine in such a way that the link was not
brought up after reconnecting the network cable.
In the process of debugging the issue I realized that we only should
invoke the runtime PM functions in rtl8169_check_link_status() when
link change is reported and if we do so, the problem goes away.
Moreover, this allows rtl8169_runtime_idle() to be simplified quite
a bit.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is definitly a problem, that some option cards send up broken
IP pakets leading to corrupted IP packets. These corruptions aren't
detected, because the driver claims that the packets are already
checksummed. This change removes the CHECKSUM_UNNECESSARY option
and let IP detect broken data.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
A while back I made some changes to enable netpoll in the bonding driver. Among
them was a per-cpu flag that indicated we were in a path that held locks which
could cause the netpoll path to block in during tx, and as such the tx path
should queue the frame for later use. This appears to have given rise to a
regression. If one of those paths on which we hold the per-cpu flag yields the
cpu, its possible for us to come back on a different cpu, leading to us clearing
a different flag than we set. This results in odd netpoll drops, and BUG
backtraces appearing in the log, as we check to make sure that we only clear set
bits, and only set clear bits. I had though briefly about changing the
offending paths so that they wouldn't sleep, but looking at my origional work
more closely, it doesn't appear that a per-cpu flag is warranted. We alrady
gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
normal tx case anyway. And practically speaking, the normal use case for
netpoll is to only have one client anyway, so we're not going to erroneously
queue netpoll frames when its actually safe to do so. As such, lets just
convert that per-cpu flag to an atomic counter. It fixes the rescheduling bugs,
is equivalent from a performance perspective and actually eliminates some code
in the process.
Tested by the reporter and myself, successfully
Reported-by: Liang Zheng <lzheng@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PCI_DEVICE_ID_CISSF is defined as 323b in pci_ids.h but redefined as 3fff in
hpsa.c. The ID of 3fff will _never_ ship as a standalone controller. It is
intended only as part a complete storage solution. As such, this patch
removes the redefinition and the StorageWorks P1210m from the product table.
It also removes a duplicate line for the "unknown" controller support.
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Sometimes the Battery driver doesn't get notifications when it's
plugged/unplugged. And this results in the incorrect Battery
status reported by the power supply sysfs I/F.
Update Battery status first when querying from sysfs.
http://marc.info/?l=linux-acpi&m=128855015826728&w=2
Tested_by: Seblu <seblu@seblu.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
BIOSes. Can't live without them (apparently), definitely can't live with
them.
Reported-by: Ben Gamari <bgamari@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24312
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix two bugs with the port array setup.
The first bug will only show up with broken xHCI hosts with Extended
Capabilities registers that have duplicate port speed entries for the same
port. The idea with the original code was to set the port_array entry to
-1 if the duplicate port speed entry said the port was a different speed
than the original port speed entry. That would mean that later, the port
would not be exposed to the USB core. Unfortunately, I forgot a continue
statement, and the port_array entry would just be overwritten in the next
line.
The second bug would happen if there are conflicting port speed registers
(so that some entry in port_array is -1), or one of the hardware port
registers was not described in the port speed registers (so that some
entry in port_array is 0). The code that sets up the usb2_ports array
would accidentally claim those ports. That wouldn't really cause any
user-visible issues, but it is a bug.
This patch should go into the stable trees that have the port array and
USB 3.0 port disabling prevention patches.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
