When a new sampling rate is shorter than the current one, (e.g., 1 sec
--> 10 ms) regardless how short the new one is, the current ondemand
mechanism wait for the previously set timer to be expired.

For example, if the user has just expressed that the sampling rate
should be 10 ms from now and the previous was 1000 ms, the new rate may
become effective 999 ms later, which could be not acceptable for the
user if the user has intended to speed up sampling because the system is
expected to react to CPU load fluctuation quickly from __now__.

In order to address this issue, we need to cancel the previously set
timer (schedule_delayed_work) and reset the timer if resetting timer is
expected to trigger the delayed_work ealier.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The S3C2416/S3C2450 SoCs support two sources for the armclk.

The first source is the so called armdiv which divides the msysclk down
to provide necessary cpu rates. In this mode the core voltage must be
always at 1.3V. The frequency from the armdiv is not allowed to be
lower than the hclk frequency.

In the second mode the armclk can be sourced directly from the hclk in
the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv
isn't used at all. Also in this mode the core voltage may be lowered.
Existing hardware and tests with it suggest 1.0V as sufficient.

When changing the clock source to the armdiv from the hclk, the SoC
shows stability issues if the new frequency is higher than the current
hclk frequency. Hence the driver always forces the armdiv to the hclk
frequency before the source change and lets the cpufreq issue another
set_target call for higher frequencies.

To mark the hclk frequency as lower as the corresponding armdiv
frequency it is set 1MHz below the real frequency. This lets the cpufreq
framework change between 133MHz based on hclk and 133MHz based on armdiv
at will.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NAndrey Gusakov <dron0gus@gmail.com>
Signed-off-by: NDave Jones <davej@redhat.com>

exynos4210-cpufreq.c is not buildable on non-exynos builds, so it's
pointless allowing this option to be exposed.  Fix this by adding a
dependency on ARCH_EXYNOS.

drivers/cpufreq/exynos4210-cpufreq.c:20:29: error: mach/regs-clock.h: No such file or directory
drivers/cpufreq/exynos4210-cpufreq.c:21:26: error: mach/cpufreq.h: No such file or directory
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: cpufreq@vger.kernel.org
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

According to replacing the name of EXYNOS clock registers,
this patch updates exynos4210-cpufreq.c file where it is used.

Cc: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NDave Jones <davej@redhat.com>

As per definition, locking_frequency is the initial frequency which is
set by boot-loader. Hence the value is updated with the initial value
during boot time init call.

This code was present in exynos210-cpufreq.c before this consolidation
patch.
- a125a17f ([CPUFREQ] EXYNOS: Make EXYNOS common cpufreq driver).
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NInderpal Singh <inderpal.singh@linaro.org>
Signed-off-by: NDave Jones <davej@redhat.com>

We don't have any of the other code for VDDINT, including the variable
declaration, so don't try to get it as we can't build.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NDave Jones <davej@redhat.com>

The new is_compat_task() define for the !COMPAT case in
include/linux/compat.h conflicts with a similar define in
arch/s390/include/asm/compat.h.

This is the minimal patch which fixes the build issues.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

omap3isp depends on omap's iommu and will fail to probe if
initialized before it (which always happen if they are builtin).

Make omap's iommu subsys_initcall as an interim solution until
the probe deferral mechanism is merged.
Reported-by: NJames <angweiyang@gmail.com>
Debugged-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: stable <stable@vger.kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

When pre-allocating skbs for received packets, we set ip_summed =
CHECKSUM_UNNCESSARY.  We used to change it back to CHECKSUM_NONE when
the received packet had an incorrect checksum or unhandled protocol.

Commit bc8acf2c ('drivers/net: avoid
some skb->ip_summed initializations') mistakenly replaced the latter
assignment with a DEBUG-only assertion that ip_summed ==
CHECKSUM_NONE.  This assertion is always false, but it seems no-one
has exercised this code path in a DEBUG build.

Fix this by moving our assignment of CHECKSUM_UNNECESSARY into
efx_rx_packet_gro().
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>

This patch fixes a (mostly cosmetic) bug introduced by the patch
'ppp: Use SKB queue abstraction interfaces in fragment processing'
found here: http://www.spinics.net/lists/netdev/msg153312.html

The above patch rewrote and moved the code responsible for cleaning
up discarded fragments but the new code does not catch every case
where this is necessary.  This results in some discarded fragments
remaining in the queue, and triggering a 'bad seq' error on the
subsequent call to ppp_mp_reconstruct.  Fragments are discarded
whenever other fragments of the same frame have been lost.
This can generate a lot of unwanted and misleading log messages.

This patch also adds additional detail to the debug logging to
make it clearer which fragments were lost and which other fragments
were discarded as a result of losses. (Run pppd with 'kdebug 1'
option to enable debug logging.)
Signed-off-by: NBen McKeegan <ben@netservers.co.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Sparse complaints the endian bug.
Signed-off-by: NSantosh Nayak <santoshprasadnayak@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Temperature history is reset by writing 0x8000 into the peak temperature
register, not 0xffff.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NJean Delvare <khali@linux-fr.org>

Fix this:

root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[   62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
ss 0000001c
[   62.725708] pgd = e6240000
[   62.737091] [0000001c] *pgd=a7168831, *pte=00000000, *ppte=00000000
[   62.743682] Internal error: Oops: 17 [#1] SMP
[   62.743682] Modules linked in: omap_iommu_debug omap_iovmm virtio_rpmsg_bus o
map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
[   62.743682] CPU: 0    Not tainted  (3.3.0-rc1-00265-g382f84e-dirty #682)
[   62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
[   62.743682] LR is at 0x1004
[   62.777832] pc : [<bf033178>]    lr : [<00001004>]    psr: 60000013
[   62.777832] sp : e72c7f40  ip : c0763c00  fp : 00000001
[   62.777832] r10: 00000000  r9 : 00000000  r8 : e72c7f80
[   62.777832] r7 : e6ffdc08  r6 : bed1ac78  r5 : 00001000  r4 : e7276000
[   62.777832] r3 : e60f3460  r2 : 00000000  r1 : e60f38c0  r0 : 00000000
[   62.777832] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   62.816375] Control: 10c53c7d  Table: a624004a  DAC: 00000015
[   62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
[   62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
...
[   62.884185] [<bf033178>] (debug_read_mem+0x5c/0xac [omap_iommu_debug]) from [<c010e354>] (vfs_read+0xac/0x130)
[   62.884185] [<c010e354>] (vfs_read+0xac/0x130) from [<c010e4a8>] (sys_read+0x40/0x70)
[   62.884185] [<c010e4a8>] (sys_read+0x40/0x70) from [<c0014a00>] (ret_fast_syscall+0x0/0x3c)

Fix also its 'echo bla > /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Adapt omap-iommu-debug to the latest omap-iommu API changes, which
were introduced by commit fabdbca8 "iommu/omap: eliminate the public
omap_find_iommu_device() method".

In a nutshell, iommu users are not expected to provide the omap_iommu
handle anymore - instead, iommus are attached using their user's device
handle.

omap-iommu-debug is a hybrid beast though: it invokes both public and
private omap iommu API, so fix it as necessary (otherwise a crash
is imminent).

Note: omap-iommu-debug is a bit disturbing, as it fiddles with internal
omap iommu data and requires exposing API which is otherwise not needed.
It should better be more tightly coupled with omap-iommu, to prevent
further bit rot and avoid exposing redundant API. Naturally that's out
of scope for the -rc cycle, so for now just fix the obvious.
Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

This patch fixes a regression that was introduced by

commit 0a5f3846
davinci_emac: Add Carrier Link OK check in Davinci RX Handler

Said commit adds a check whether the carrier link is ok. If the link is
not ok, the skb is freed and no new dma descriptor added to the rx dma
channel. This causes trouble during initialization when the carrier
status has not yet been updated. If a lot of packets are received while
netif_carrier_ok returns false, all dma descriptors are freed and the
rx dma transfer is stopped.

The bug occurs when the board is connected to a network with lots of
traffic and the ifconfig down/up is done, e.g., when reconfiguring
the interface with DHCP.

The bug can be reproduced by flood pinging the davinci board while doing
ifconfig eth0 down
ifconfig eth0 up
on the board.

After that, the rx path stops working and the overrun value reported
by ifconfig is counting up.

This patch reverts commit 0a5f3846
and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.
Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
Cc: <stable@vger.kernel.org>
Cc: Hegde, Vinay <vinay.hegde@ti.com>
Cc: Cyril Chemparathy <cyril@ti.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: NRajashekhara, Sudhakar <sudhakar.raj@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds the PHY_HAS_INTERRUPT flag for IC+101 device series.
Also the patch does a simple dity-up to signal that
the driver actually is for IP101A LF and IP101G devices.
In fact, these are two similar PHYs that have the same IDs
and mainly differ for the EEE capability supported in the
G series.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The code for ip1001_config_init() was totally broken if you were not
using RGMII. Instead of returning an error code or zero it actually
returned the value in the IP1001_SPEC_CTRL_STATUS_2 register. It was
also trying to set the IP1001_APS_ON bit , but never actually wrote
back the register.

The error checking was also incorrect in both this function and the
reset function, so this patch fixes that up in a consistent fashion.
Signed-off-by: NDavid McKay <david.mckay@st.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

By hwmon sysfs interface convention, setting pwm_enable to zero sets a fan
to full speed.  In the f75375s driver, this need be done by enabling
manual fan control, plus duty mode for the F875387 chip, and then setting
the maximum duty cycle.  Fix a bug where the two necessary register writes
were swapped, effectively discarding the setting to full-speed.
Signed-off-by: NNikolaus Schulz <mail@microschulz.de>
Cc: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

An error while creating sysfs attribute files in the driver's probe function
results in an error abort, but already created files are not removed. This patch
fixes the problem.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: stable@vger.kernel.org # 3.0+
Cc: Dirk Eibach <eibach@gdsys.de>
Acked-by: NJean Delvare <khali@linux-fr.org>

At least on powerpc, it breaks the build if exported functions are
static.  Fix some static exported functions introduced with the mlx4
SR-IOV support added in 3.3-rc1.
Signed-off-by: NDoug Ledford <dledford@redhat.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>

In the current kernel implementation, the Logitech Harmony 900 remote
control is matched to the cdc_ether driver through the generic
USB_CDC_SUBCLASS_MDLM entry.  However, this device appears to be of the
pseudo-MDLM (Belcarra) type, rather than the standard one.  This patch
blacklists the Harmony 900 from the cdc_ether driver and whitelists it for
the pseudo-MDLM driver in zaurus.
Signed-off-by: NScott Talbert <talbert@techie.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The intent was to clear out the icount struct here, but we accidentally
clear stack memory instead.  It probably will lead to a NULL dereference
right away.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ip6_route_output() never returns NULL, so it is wrong to
check if the return value is NULL.
Signed-off-by: NRongQing.Li <roy.qing.li@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Set the RX FIFO flush watermark lower.
According to Federico and JMicron's reply,
setting it to 16QW would be stable on most platforms.
Otherwise, user might experience packet drop issue.

CC: stable@kernel.org
Reported-by: NFederico Quagliata <federico@quagliata.org>
Fixed-by: NFederico Quagliata <federico@quagliata.org>
Signed-off-by: NGuo-Fu Tseng <cooldavid@cooldavid.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes an unbalanced refcount issue.

Elevating the lock for both kref_put and also for controller node deletion.
Previously, controller deletion was protected but the not the kref_put. This
was causing the other thread to pick up the controller structure which was
already kref'd zero.

This was causing the following WARN_ON and also sometimes panic.

WARNING: at lib/kref.c:43 kref_get+0x2d/0x30() (Not tainted)
Hardware name: IBM System x3655 -[7985AC1]-
Modules linked in: fuse scsi_dh_rdac autofs4 nfs lockd fscache nfs_acl
auth_rpcgss sunrpc 8021q garp stp llc ipv6 ib_srp(U) scsi_transport_srp
scsi_tgt ib_cm(U) ib_sa(U) ib_uverbs(U) ib_umad(U) mlx4_ib(U) mlx4_core(U)
ib_mthca(U) ib_mad(U) ib_core(U) dm_mirror dm_region_hash dm_log dm_round_robin
dm_multipath uinput bnx2 ses enclosure sg ibmpex ibmaem ipmi_msghandler
serio_raw k8temp hwmon amd64_edac_mod edac_core edac_mce_amd shpchp i2c_piix4
ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif sata_svw pata_acpi ata_generic
pata_serverworks aacraid radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core
dm_mod [last unloaded: freq_table]
Pid: 13735, comm: srp_daemon Not tainted 2.6.32-71.el6.x86_64 #1
Call Trace:
[<ffffffff8106b857>] warn_slowpath_common+0x87/0xc0
[<ffffffff8106b8aa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8125c39d>] kref_get+0x2d/0x30
[<ffffffffa01b4029>] rdac_bus_attach+0x459/0x580 [scsi_dh_rdac]
[<ffffffff8135232a>] scsi_dh_handler_attach+0x2a/0x80
[<ffffffff81352c7b>] scsi_dh_notifier+0x9b/0xa0
[<ffffffff814cd7a5>] notifier_call_chain+0x55/0x80
[<ffffffff8109711a>] __blocking_notifier_call_chain+0x5a/0x80
[<ffffffff81097156>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff8132bec5>] device_add+0x515/0x640
[<ffffffff813329e4>] ? attribute_container_device_trigger+0xc4/0xe0
[<ffffffff8134f659>] scsi_sysfs_add_sdev+0x89/0x2c0
[<ffffffff8134d096>] scsi_probe_and_add_lun+0xea6/0xed0
[<ffffffff8134beb2>] ? scsi_alloc_target+0x292/0x2d0
[<ffffffff8134d1e1>] __scsi_scan_target+0x121/0x750
[<ffffffff811df806>] ? sysfs_create_file+0x26/0x30
[<ffffffff8132b759>] ? device_create_file+0x19/0x20
[<ffffffff81332838>] ? attribute_container_add_attrs+0x78/0x90
[<ffffffff814b008c>] ? klist_next+0x4c/0xf0
[<ffffffff81332e30>] ? transport_configure+0x0/0x20
[<ffffffff813329e4>] ? attribute_container_device_trigger+0xc4/0xe0
[<ffffffff8134df40>] scsi_scan_target+0xd0/0xe0
[<ffffffffa02f053a>] srp_create_target+0x75a/0x890 [ib_srp]
[<ffffffff8132a130>] dev_attr_store+0x20/0x30
[<ffffffff811df145>] sysfs_write_file+0xe5/0x170
[<ffffffff8116c818>] vfs_write+0xb8/0x1a0
[<ffffffff810d40a2>] ? audit_syscall_entry+0x272/0x2a0
[<ffffffff8116d251>] sys_write+0x51/0x90
[<ffffffff81013172>] system_call_fastpath+0x16/0x1b
Signed-off-by: NBabu Moger <babu.moger@netapp.com>
Acked-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

dpms bits not used on DCE4+
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If accel is not working many subsystem such as the ib pool might not be
initialized properly that can lead to segfault inside kernel when cs
ioctl is call with non working acceleration. To avoid this make sure
the accel working flag is false when an error in GPU startup happen and
return EBUSY from cs ioctl if accel is not working.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46274

Tested with a Cayman card in a Llano system: The additional files are created
and working for the Cayman card but not created for the CPU's built-in GPU.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We moved all our pSeries idle loops to the cpu idle framework
so we really want it to come up by default.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This provides unified readq()/writeq() helper functions for 32-bit
drivers.

For some cases, readq/writeq without atomicity is harmful, and order of
io access has to be specified explicitly.  So in this patch, new two
header files which contain non-atomic readq/writeq are added.

 - <asm-generic/io-64-nonatomic-lo-hi.h> provides non-atomic readq/
   writeq with the order of lower address -> higher address

 - <asm-generic/io-64-nonatomic-hi-lo.h> provides non-atomic readq/
   writeq with reversed order

This allows us to remove some readq()s that were added drivers when the
default non-atomic ones were removed in commit dbee8a0a ("x86:
remove 32-bit versions of readq()/writeq()")

The drivers which need readq/writeq but can do with the non-atomic ones
must add the line:

  #include <asm-generic/io-64-nonatomic-lo-hi.h> /* or hi-lo.h */

But this will be nop in 64-bit environments, and no other #ifdefs are
required.  So I believe that this patch can solve the problem of
 1. driver-specific readq/writeq
 2. atomicity and order of io access

This patch is tested with building allyesconfig and allmodconfig as
ARCH=x86 and ARCH=i386 on top of tip/master.

Cc: Kashyap Desai <Kashyap.Desai@lsi.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ravi Anand <ravi.anand@qlogic.com>
Cc: Vikas Chaudhary <vikas.chaudhary@qlogic.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Jason Uhlenkott <juhlenko@akamai.com>
Cc: James Bottomley <James.Bottomley@parallels.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: James Bottomley <jbottomley@parallels.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHitoshi Mitake <h.mitake@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NBruno Thomsen <bruno.thomsen@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This USB-serial cable with mini stereo jack enumerates as:
Bus 001 Device 004: ID 1a61:3410 Abbott Diabetes Care

It is a TI3410 inside.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1521b) fixes the interaction between usb-storage's
scanning thread and the freezer.  The current implementation has a
race: If the device is unplugged shortly after being plugged in and
just as a system sleep begins, the scanning thread may get frozen
before the khubd task.  Khubd won't be able to freeze until the
disconnect processing is complete, and the disconnect processing can't
proceed until the scanning thread finishes, so the sleep transition
will fail.

The implementation in the 3.2 kernel suffers from an additional
problem.  There the scanning thread calls set_freezable_with_signal(),
and the signals sent by the freezer will mess up the thread's I/O
delays, which are all interruptible.

The solution to both problems is the same: Replace the kernel thread
used for scanning with a delayed-work routine on the system freezable
work queue.  Freezable work queues have the nice property that you can
cancel a work item even while the work queue is frozen, and no signals
are needed.

The 3.2 version of this patch solves the problem in Bugzilla #42730.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NSeth Forshee <seth.forshee@canonical.com>
CC: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
be encoded as an exponent of two number of microframes.  The endpoint
descriptor has the NAK rate encoded in number of microframes.  We were
just copying the value from the endpoint descriptor into the endpoint
context interval field, which was not correct.  This lead to the VIA
host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
storage device.

The fix is to use the correct encoding.  Refactor the code to convert
number of frames to an exponential number of microframes, and make sure
we convert the number of microframes in HS bulk and control endpoints to
an exponent.

This should be back ported to kernels as old as 2.6.31, that contain the
commit dfa49c4a "USB: xhci - fix math
in xhci_get_endpoint_interval"
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NFelipe Contreras <felipe.contreras@gmail.com>
Suggested-by: NAndiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org

The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.

Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.

The patch should be backported to kernels as old as 2.6.39.
Signed-off-by: NElric Fu <elricfu1@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org

On some systems with an Intel Panther Point xHCI host controller, the
BIOS disables the xHCI PCI device during boot, and switches the xHCI
ports over to EHCI.  This allows the BIOS to access USB devices without
having xHCI support.

The downside is that the xHCI BIOS handoff mechanism will fail because
memory mapped I/O is not enabled for the disabled PCI device.
Jesse Barnes says this is expected behavior.  The PCI core will enable
BARs before quirks run, but it will leave it in an undefined state, and
it may not have memory mapped I/O enabled.

Make the generic USB quirk handler call pci_enable_device() to re-enable
MMIO, and call pci_disable_device() once the host-specific BIOS handoff
is finished.  This will balance the ref counts in the PCI core.  When
the PCI probe function is called, usb_hcd_pci_probe() will call
pci_enable_device() again.

This should be back ported to kernels as old as 2.6.31.  That was the
first kernel with xHCI support, and no one has complained about BIOS
handoffs failing due to memory mapped I/O being disabled on other hosts
(EHCI, UHCI, or OHCI).
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NOliver Neukum <oneukum@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org

Initialize PPR register for both channels, and set correct PPR register bits.
Also remove unnecessary variable initializations.
Signed-off-by: NChris D Schimp <silverchris@gmail.com>
[guenter.roeck@ericsson.com: Merged two patches into one]
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: stable@vger.kernel.org # 3.0+
Acked-by: NRoland Stigge <stigge@antcom.de>

RPM calculation from tachometer value does not depend on PPR.
Also, do not report negative RPM values.
Signed-off-by: NChris D Schimp <silverchris@gmail.com>
[guenter.roeck@ericsson.com: do not report negative RPM values]
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: stable@vger.kernel.org # 3.0+
Acked-by: NRoland Stigge <stigge@antcom.de>

In port type change flow, need to set the new port types only after
all interfaces have finished the unregister process.
Otherwise, during unregister, one of the interfaces might issue a SET_PORT
command with wrong port types, it can cause bad FW behavior.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>