Four cpufreq-like governors are provided as examples.

powersave: use the lowest frequency possible. The user (device) should
set the polling_ms as 0 because polling is useless for this governor.

performance: use the highest freqeuncy possible. The user (device)
should set the polling_ms as 0 because polling is useless for this
governor.

userspace: use the user specified frequency stored at
devfreq.user_set_freq. With sysfs support in the following patch, a user
may set the value with the sysfs interface.

simple_ondemand: simplified version of cpufreq's ondemand governor.

When a user updates OPP entries (enable/disable/add), OPP framework
automatically notifies devfreq to update operating frequency
accordingly. Thus, devfreq users (device drivers) do not need to update
devfreq manually with OPP entry updates or set polling_ms for powersave
, performance, userspace, or any other "static" governors.

Note that these are given only as basic examples for governors and any
devices with devfreq may implement their own governors with the drivers
and use them.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMike Turquette <mturquette@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Device specific sysfs interface /sys/devices/.../power/devfreq_*
- governor	R: name of governor
- cur_freq	R: current frequency
- polling_interval	R: polling interval in ms given with devfreq profile
			W: update polling interval.
- central_polling	R: 1 if polling is managed by devfreq framework
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMike Turquette <mturquette@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
--
 Documentation/ABI/testing/sysfs-class-devfreq |   44 ++++++++++++++++
 drivers/devfreq/devfreq.c                     |   69 ++++++++++++++++++++++++++
 2 files changed, 113 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-devfreq

With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.

This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.

The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq.  However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.

Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.

When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMike Turquette <mturquette@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The patch enables to register notifier_block for an OPP-device in order
to get notified for any changes in the availability of OPPs of the
device. For example, if a new OPP is inserted or enable/disable status
of an OPP is changed, the notifier is executed.

This enables the usage of opp_add, opp_enable, and opp_disable to
directly take effect with any connected entities such as cpufreq or
devfreq.
Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMike Turquette <mturquette@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Commit b7ab83ed (PM: Use spinlock instead of mutex in clock
management functions) introduced a regression causing clocks_mutex
to be acquired under a spinlock.  This happens because
pm_clk_suspend() and pm_clk_resume() call pm_clk_acquire() under
pcd->lock, but pm_clk_acquire() executes clk_get() which causes
clocks_mutex to be acquired.  Similarly, __pm_clk_remove(),
executed under pcd->lock, calls clk_put(), which also causes
clocks_mutex to be acquired.

To fix those problems make pm_clk_add() call pm_clk_acquire(), so
that pm_clk_suspend() and pm_clk_resume() don't have to do that.
Change pm_clk_remove() and pm_clk_destroy() to separate
modifications of the pcd->clock_list list from the actual removal of
PM clock entry objects done by __pm_clk_remove().
Reported-and-tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If CPM mode is not used, the fsl_dummy_rx variable is never allocated.  When
the cleanup attempts to free it, the reference count is zero and a WARN is
generated.  The same CPM mode check used in the initialize is applied to the
free as well.

Tested on 2.6.33 with the previous spi_mpc8xxx driver.  The renamed
spi-fsl-spi driver looks to have the same problem.
Signed-off-by: NJeff Harris <jeff_harris@kentrox.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

sector_t can be different types, so cast it to its largest possible
type.

  drivers/scsi/qla2xxx/qla_isr.c:1509:5: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'sector_t'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

SCSI_ISCI needs to select SCSI_SAS_HOST_SMP to ensure that all
needed symbols are available to it.

Fixes this build error:

  ERROR: "try_test_sas_gpio_gp_bit" [drivers/scsi/isci/isci.ko] undefined!
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The only caller of the function obtained the pointer solely for the
purpose of passing it to this function, while it can be easily
determined from the struct platform_device * parameter also passed.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

These arrays won't ever be written to, so protect them from
unintentional modification.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

... as that has the potential to conflict with (particularly soft) CPU
hot removal and re-adding.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
[guenter.roeck@ericsson.com: use platform device ID as physical CPU id]
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

DVOOutputControl checks the value of of bios scratch reg 3
on some tables and assumes the encoder is already enabled
if the DFP2_ACTIVE bit is set.  Clear that bit so the table
sets the DDIA enable bit properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit 18b4fada.

This code was correct, apologies to anyone who noticed things broke.

revert contents are different due to another commit in between.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since the buffer might contain security related data it might be a good idea to
zero the buffer after we have copied it to userspace.

This got assigned CVE-2011-1162.
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: NJames Morris <jmorris@namei.org>

This patch changes the call of tpm_transmit by supplying the size of the
userspace buffer instead of TPM_BUFSIZE.

This got assigned CVE-2011-1161.

[The first hunk didn't make sense given one could expect
 way less data than TPM_BUFSIZE, so added tpm_transmit boundary
 check over bufsiz instead
 The last parameter of tpm_transmit() reflects the amount
 of data expected from the device, and not the buffer size
 being supplied to it. It isn't ideal to parse it directly,
 so we just set it to the maximum the input buffer can handle
 and let the userspace API to do such job.]
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: NJames Morris <jmorris@namei.org>

platform_device_unregister() will release all resources
and remove it from the subsystem, then drop reference count by
calling platform_device_put().

We should not call kfree(pdev) after platform_device_unregister(pdev).
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

On m68k, I get:

drivers/char/tpm/tpm_atmel.h: In function ‘atmel_get_base_addr’:
drivers/char/tpm/tpm_atmel.h:129: error: implicit declaration of function ‘ioport_map’
drivers/char/tpm/tpm_atmel.h:129: warning: return makes pointer from integer without a cast

The code in tpm_atmel.h supports PPC64 (using the device tree and ioremap())
and "anything else" (using ioport_map()). However, ioportmap() is only
available on platforms that set HAS_IOPORT.

Although PC64 seems to have HAS_IOPORT, a "depends on HAS_IOPORT" should work,
but I think it's better to expose the special PPC64 handling explicit using
"depends on PPC64 || HAS_IOPORT".
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

As the Amiga Zorro II address space is limited to 8.5 MiB and Zorro
devices can contain only one BAR, several Amiga Zorro II expansion
boards (mainly graphics cards) contain multiple Zorro devices: a small
one for the control registers and one (or more) for the graphics memory.

The conversion of cirrusfb to the new driver framework introduced a
regression: the driver contains a zorro_driver for the first Zorro
device, and uses the (old) zorro_find_device() call to find the second
Zorro device.

However, as the Zorro core calls device_register() as soon as a Zorro
device is identified, it may not have identified the second Zorro device
belonging to the same physical Zorro expansion card.  Hence cirrusfb
could no longer find the second part of the Picasso II graphics card,
causing a NULL pointer dereference.

Defer the registration of Zorro devices with the driver framework until
all Zorro devices have been identified to fix this.

Note that the alternative solution (modifying cirrusfb to register a
zorro_driver for all Zorro devices belonging to a graphics card, instead
of only for the first one, and adding a synchronization mechanism to
defer initialization until all have been found), is not an option, as on
some cards one device may be optional (e.g.  the second bank of 2 MiB of
graphics memory on the Picasso IV in Zorro II mode).
Reported-by: NIngo Jürgensmann <ij@2011.bluespice.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed (negative) temperatures were not handled correctly.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: stable@kernel.org # v2.6.38+

gcc -Wextra warns "register is not at beginning of declaration" because the
compiler thinks the parameter has been marked as a 'register' variable, but
the function prototype intended to name the parameter "register" (which is a
reserved keyword).
Signed-off-by: NChris Peterson <cpeterso@cpeterso.com>
Acked-by: NMarc Hulsman <m.hulsman@tudelft.nl>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

With commit c814a4c7, the meaning of tempX_max
was changed. It no longer returns the value of bits 8:15 of
MSR_IA32_TEMPERATURE_TARGET, but instead returns the value of CPU threshold
register T1. tempX_max_hyst was added to reflect the value of temperature
threshold register T0.

As it turns out, T0 and T1 are used on some systems, presumably by the BIOS.
Also, T0 and T1 don't have a well defined meaning. The thresholds may be used
as upper or lower limits, and it is not guaranteed that T0 <= T1. Thus, the new
attribute mapping does not reflect the actual usage of the threshold registers.
Also, register contents are changed during runtime by an entity other than the
hwmon driver, meaning the values cached by the driver do not reflect actual
register contents.

Revert most of c814a4c7 to address the problem.
Support for T0 and T1 will be added back in with a separate commit, using new
attribute names.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Acked-by: NJean Delvare <khali@linux-fr.org>

On old CPUs (and even some recent Atom CPUs) TjMax can't be read from
the CPU registers, so it is guessed by the driver using a complex
heuristic which isn't reliable. So let users who know their CPU's
TjMax pass it as a module parameter.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: "R, Durgadoss" <durgadoss.r@intel.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

Function get_pkg_tjmax is a simplified copy of get_tjmax. Drop it and
always use get_tjmax, result is the same and this avoids code
duplication.

Also make get_tjmax less verbose: don't warn about MSR read failure
when failure was expected, and don't report TjMax in the logs unless
debugging is enabled.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Acked-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

When no floppy is found the module code can be released while a timer
function is pending or about to be executed.

CPU0                                  CPU1
				      floppy_init()
timer_softirq()
   spin_lock_irq(&base->lock);
   detach_timer();
   spin_unlock_irq(&base->lock);
   -> Interrupt
					del_timer();
				        return -ENODEV;
                                      module_cleanup();
   <- EOI
   call_timer_fn();
   OOPS

Use del_timer_sync() to prevent this.
Signed-off-by: NCarsten Emde <C.Emde@osadl.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

It seems that at least one PPC machine would occasionally give a (valid) 0 as
the return value from dma_map, this caused the ixgbe code to not work
correctly.  A fix is pending in the PPC tree to not return 0 from dma map, but
we can also fix the driver to make sure we don't mess up in other arches as
well.

This patch is applicable to all current stable kernels.

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=683611Reported-by: NNeil Horman <nhorman@redhat.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: stable@kernel.org
Tested-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 92cd3a17
    tg3: Simplify tx bd assignments

broke VLAN tagging on outbound packets.
It ifdef'ed BCM_KERNEL_SUPPORTS_8021Q, but this
is not set anywhere. So vlan never gets set, and
all packets are sent with vlan=0.

v2: We can just remove the test. vlan_tx_tag_present
is valid regardless of whether the 802.1q module
is built.

Tested on BCM5721 rev 11.
Signed-off-by: NKasper Pedersen <kernel@kasperkp.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commit c5f5c4db ("staging: zcache: fix crash on high memory
swap") cleancache crashes on the first successful get.  This was caused
by a remaining virt_to_page() call in zcache_pampd_get_data_and_free()
that only gets run in the cleancache path.

The patch converts the virt_to_page() to struct page casting like was
done for other instances in c5f5c4db.
Signed-off-by: NSeth Jennings <sjenning@linux.vnet.ibm.com>
Tested-By: NValdis Kletnieks <valdis.kletnieks@vt.edu>
Acked-by: NDan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit a6b7a407 removed
linux/interrupt.h from netdevice.h. This fixes below build failure

drivers/net/pxa168_eth.c: In function 'pxa168_eth_collect_events':
drivers/net/pxa168_eth.c:866: error: 'IRQ_NONE' undeclared (first use in this function)
drivers/net/pxa168_eth.c:866: error: (Each undeclared identifier is reported only once
drivers/net/pxa168_eth.c:866: error: for each function it appears in.)
drivers/net/pxa168_eth.c: At top level:
drivers/net/pxa168_eth.c:913: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pxa168_eth_int_handler'
drivers/net/pxa168_eth.c: In function 'pxa168_eth_open':
drivers/net/pxa168_eth.c:1133: error: implicit declaration of function 'request_irq'
drivers/net/pxa168_eth.c:1133: error: 'pxa168_eth_int_handler' undeclared (first use in this function)
drivers/net/pxa168_eth.c:1134: error: 'IRQF_DISABLED' undeclared (first use in this function)
drivers/net/pxa168_eth.c:1160: error: implicit declaration of function 'free_irq'
Signed-off-by: NTanmay Upadhyay <tanmay.upadhyay@einfochips.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 88491d81(drivers/net: Kconfig & Makefile cleanup) causes a
regression that netconsole does not work if netconsole and network
device driver are build into kernel, because netconsole is linked
before network device driver.

Andrew Morton suggested to fix this with initcall ordering.
Fixes it by switching init_netconsole() to late_initcall.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This function may currently fill one entry beyond the end of the
array it is given.  It also doesn't return an error code in case
it does detect overflow.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When using MLPPP, the maximum size of a fragment is incorrectly
calculated with an offset of -2.
This patch reverses the changes in the patch found here:
http://marc.info/?l=linux-netdev&m=123541324010539&w=2

The value of hdrlen includes the size of both the 2-byte PPP protocol
field and the 2- or 4-byte multilink header (2+4=6 for long sequence
numbers, 2+2=4 for short sequence numbers). Section 2 of RFC1661 says
that the MRU that is negotiated (i.e., the MTU of the sending system)
includes only the PPP payload but not the protocol field, thus the
correct MTU should be the link's MTU minus the multilink header (mtu -
(hdrlen-2)).

The incorrect calculation causes Linux to fragment packets to a size two
bytes smaller than the allowed MTU. While not technically illegal, this
behaviour confounds MRU-tuning to avoid PPP-layer fragmentation.
Signed-off-by: NHenry Wong <henry@stuffedcow.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The GRETH GBIT core does not do checksum offloading for IP
segmentation. This patch adds a check in the xmit function to
determine if the stack has calculated the checksum for us.
Signed-off-by: NDaniel Hellstrom <daniel@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDaniel Hellstrom <daniel@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

The enable function was using the global timeout variable for local operations.
This resulted in the value of the global variable being corrupted, thus
breaking the code.
Signed-off-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NThomas Langer <thomas.langer@lantiq.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog@vger.kernel.org
Cc: linux-mips@linux-mips.org

On platforms with no iCRU support don't print two, (possibly conflicting),
"NMI occurred" messages when the firmware is unable to source the NMI.

Please note that one of the enhancements to the v1.3.0 hpwdt driver is to panic and allow
KDUMP to succeed even on NMIs that are unknown to the platform firmware.
Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
Reviewed-by: NThomas Mingarelli <thomas.mingarelli@hp.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Use the passed watchdog_device instead of the static global variable when
testing and setting the status in watchdog_ping, watchdog_start, and
watchdog_stop.  Note that the callers of these functions are actually
passing the static global variable.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.

Currently xhci driver handles MSE event in the following ways:

1. When encounter a MSE event, set ep->skip flag, update event ring
   dequeue pointer and return.

2. When encounter the next event on this ep, the driver will run the
   do-while loop, fetch td from ep's td_list to find the td
   corresponding to this event.  All tds missed are marked as short
   transfer(-EXDEV).

The do-while loop will end in two ways:

1. If the td pointed by the event trb is found;

2. If the ep ring's td_list is empty.

However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.

Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop.  During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list.  This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.

To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds.  This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sometimes, when a USB 3.0 device is disconnected, the Intel Panther
Point xHCI host controller will report a link state change with the
state set to "SS.Inactive".  This causes the xHCI host controller to
issue a warm port reset, which doesn't finish before the USB core times
out while waiting for it to complete.

When the warm port reset does complete, and the xHC gives back a port
status change event, the xHCI driver kicks khubd.  However, it fails to
set the bit indicating there is a change event for that port because the
logic in xhci-hub.c doesn't check for the warm port reset bit.

After that, the warm port status change bit is never cleared by the USB
core, and the xHC stops reporting port status change bits.  (The xHCI
spec says it shouldn't report more port events until all change bits are
cleared.) This means any port changes when a new device is connected
will never be reported, and the port will seem "dead" until the xHCI
driver is unloaded and reloaded, or the computer is rebooted.  Fix this
by making the xHCI driver set the port change bit when a warm port reset
change bit is set.

A better solution would be to make the USB core handle warm port reset
in differently, merging the current code with the standard port reset
code that does an incremental backoff on the timeout, and tries to
complete the port reset two more times before giving up.  That more
complicated fix will be merged next window, and this fix will be
backported to stable.

This should be backported to kernels as old as 3.0, since that was the
first kernel with commit a11496eb ("xHCI: warm reset support").
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix build when CONFIG_ISA_DMA_API is enabled but
CONFIG_COMEDI_PCI[_DRIVERS] is not enabled.

Fixes these build errors:

  drivers/staging/comedi/drivers/ni_labpc.c: In function 'labpc_ai_cmd':
  drivers/staging/comedi/drivers/ni_labpc.c:1351: error: implicit declaration of function 'labpc_suggest_transfer_size'
  drivers/staging/comedi/drivers/ni_labpc.c: At top level:
  drivers/staging/comedi/drivers/ni_labpc.c:1802: error: conflicting types for 'labpc_suggest_transfer_size'
  drivers/staging/comedi/drivers/ni_labpc.c:1351: note: previous implicit declaration of 'labpc_suggest_transfer_size' was here
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>