aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-05-07mfd: adp5520: Restore mode bits on resumeLars-Peter Clausen
commit c6cc25fda58da8685ecef3f179adc7b99c8253b2 upstream. The adp5520 unfortunately also clears the BL_EN bit when the nSTNDBY bit is cleared. So we need to make sure to restore it during resume if it was set before suspend. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07mmc: atmel-mci: pio hang on block errorsTerry Barnaby
commit bdbc5d0c60f3e9de3eeccf1c1a18bdc11dca62cc upstream. The driver is doing, by default, multi-block reads. When a block error occurs, card/block.c instigates a single block read: "mmcblk0: retrying using single block read". It leaves the sg chain intact and just changes the length attribute for the first sg entry and the overall sg_len parameter. When atmci_read_data_pio is called to read the single block of data it ignores the sg_len and expects to read more than 512 bytes as it sees there are multiple items in the sg list. No more data comes as the controller has only been commanded to get one block. Signed-off-by: Terry Barnaby <terry@beam.ltd.uk> Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07mmc: core: Fix bit width test failing on old eMMC cardsPhilip Rakity
commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream. PARTITION_SUPPORT needs to be set before doing the compare on version number so the bit width test does not get invalid data. Before this patch, a Sandisk iNAND eMMC card would detect 1-bit width although the hardware supports 4-bit. Only affects old emmc devices - pre 4.4 devices. Reported-by: Elad Yi <elad.yi@gmail.com> Signed-off-by: Philip Rakity <prakity@yahoo.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07mmc: at91/avr32/atmel-mci: fix DMA-channel leak on module unloadJohan Hovold
commit 91cf54feecf815bec0b6a8d6d9dbd0e219f2f2cc upstream. Fix regression introduced by commit 796211b7953 ("mmc: atmel-mci: add pdc support and runtime capabilities detection") which removed the need for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the compile guards around dma_release_channel() in remove(). Consequently, DMA is always enabled (if supported), but the DMA-channel is not released on module unload unless the DMA-config option is selected. Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely. Signed-off-by: Johan Hovold <jhovold@gmail.com> Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07ixgbe: fix EICR write in ixgbe_msix_otherJacob Keller
commit d87d830720a1446403ed38bfc2da268be0d356d1 upstream. Previously, the ixgbe_msix_other was writing the full 32bits of the set interrupts, instead of only the ones which the ixgbe_msix_other is handling. This resulted in a loss of performance when the X540's PPS feature is enabled due to sometimes clearing queue interrupts which resulted in the driver not getting the interrupt for cleaning the q_vector rings often enough. The fix is to simply mask the lower 16bits off so that this handler does not write them in the EICR, which causes them to remain high and be properly handled by the clean_rings interrupt routine as normal. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07MD: ignore discard request for hard disks of hybid raid1/raid10 arrayShaohua Li
commit 32f9f570d04461a41bdcd5c1d93b41ebc5ce182a upstream. In SSD/hard disk hybid storage, discard request should be ignored for hard disk. We used to be doing this way, but the unplug path forgets it. This is suitable for stable tree since v3.6. Reported-and-tested-by: Markus <M4rkusXXL@web.de> Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07md: bad block list should default to disabled.NeilBrown
commit 486adf72ccc0c235754923d47a2270c5dcb0c98b upstream. Maintenance of a bad-block-list currently defaults to 'enabled' and is then disabled when it cannot be supported. This is backwards and causes problem for dm-raid which didn't know to disable it. So fix the defaults, and only enabled for v1.x metadata which explicitly has bad blocks enabled. The problem with dm-raid has been present since badblock support was added in v3.1, so this patch is suitable for any -stable from 3.1 onwards. Reported-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07sata_highbank: Rename proc_name to the module nameRobert Richter
commit 2cc1144a31f76d4a9fb48bec5d6ba1359f980813 upstream. mkinitrd looks at /sys/class/scsi_host/host$hostnum/proc_name to find the module name of a disk driver. Current name is "highbank-ahci" but the module is "sata_highbank". Rename it to match the module name. Signed-off-by: Robert Richter <robert.richter@calxeda.com> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip ↵Zhang Rui
points commit 94a409319561ec1847fd9bf996a2d5843ad00932 upstream. Commit 4ae46be "Thermal: Introduce thermal_zone_trip_update()" introduced a regression causing the fan to be always on even when the system is idle. My original idea in that commit is that: - when the current temperature is above the trip point, keep the fan on, even if the temperature is dropping. - when the current temperature is below the trip point, turn on the fan when the temperature is raising, turn off the fan when the temperature is dropping. But this is what the code actually does: - when the current temperature is above the trip point, the fan keeps on. - when the current temperature is below the trip point, the fan is always on because thermal_get_trend() in driver/acpi/thermal.c returns THERMAL_TREND_RAISING. Thus the fan keeps running even if the system is idle. Fix this in drivers/acpi/thermal.c. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=56591 References: https://bugzilla.kernel.org/show_bug.cgi?id=56601 References: https://bugzilla.kernel.org/show_bug.cgi?id=50041#c45 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Matthias <morpheusxyz123@yahoo.de> Tested-by: Ville Syrjälä <syrjala@sci.fi> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07ACPI: Fix wrong parameter passed to memblock_reserveWang YanQing
commit a6432ded299726f123b93d0132fead200551535c upstream. Commit 53aac44 (ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas) introduced acpi_initrd_override() that passes a wrong value as the second argument to memblock_reserve(). Namely, the second argument of memblock_reserve() is the size of the region, not the address of the top of it, so make acpi_initrd_override() pass the size in there as appropriate. [rjw: Changelog] Signed-off-by: Wang YanQing <udknight@gmail.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07libata: acpi: make ata_ap_acpi_handle not blockAaron Lu
commit d66af4df0837f21bf267305dc5ccab2d29e24d86 upstream. Since commit 30dcf76acc, ata_ap_acpi_handle will always do a namespace walk, which requires acquiring an acpi namespace mutex. This made it impossible to be used when calling path has held a spinlock. For example, it can occur in the following code path for pata_acpi: ata_scsi_queuecmd (ap->lock is acquired) __ata_scsi_queuecmd ata_scsi_translate ata_qc_issue pacpi_qc_issue ata_acpi_stm ata_ap_acpi_handle acpi_get_child acpi_walk_namespace acpi_ut_acquire_mutex (acquire mutex while holding lock) This caused scheduling while atomic bug, as reported in bug #56781. Actually, ata_ap_acpi_handle doesn't have to walk the namespace every time it is called, it can simply return the bound acpi handle on the corresponding SCSI host. The reason previously it is not done this way is, ata_ap_acpi_handle is used in the binding function ata_acpi_bind_host by ata_acpi_gtm when the handle is not bound to the SCSI host yet. Since we already have the ATA port's handle in its binding function, we can simply use it instead of calling ata_ap_acpi_handle there. So introduce a new function __ata_acpi_gtm, where it will receive an acpi handle param in addition to the ATA port which is solely used for debug statement. With this change, we can make ata_ap_acpi_handle simply return the bound handle for SCSI host instead of walking the acpi namespace now. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=56781 Reported-and-tested-by: <kenzopl@o2.pl> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07drivers/rtc/rtc-cmos.c: don't disable hpet emulation on suspendDerek Basehore
commit e005715efaf674660ae59af83b13822567e3a758 upstream. There's a bug where rtc alarms are ignored after the rtc cmos suspends but before the system finishes suspend. Since hpet emulation is disabled and it still handles the interrupts, a wake event is never registered which is done from the rtc layer. This patch reverts commit d1b2efa83fbf ("rtc: disable hpet emulation on suspend") which disabled hpet emulation. To fix the problem mentioned in that commit, hpet_rtc_timer_init() is called directly on resume. Signed-off-by: Derek Basehore <dbasehore@chromium.org> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07TPM: Retry SaveState command in suspend pathDuncan Laurie
commit 32d33b29ba077d6b45de35f2181e0a7411b162f4 upstream. If the TPM has already been sent a SaveState command before the driver is loaded it may have problems sending that same command again later. This issue is seen with the Chromebook Pixel due to a firmware bug in the legacy mode boot path which is sending the SaveState command before booting the kernel. More information is available at http://crbug.com/203524 This change introduces a retry of the SaveState command in the suspend path in order to work around this issue. A future firmware update should fix this but this is also a trivial workaround in the driver that has no effect on systems that do not show this problem. When this does happen the TPM responds with a non-fatal TPM_RETRY code that is defined in the specification: The TPM is too busy to respond to the command immediately, but the command could be resubmitted at a later time. The TPM MAY return TPM_RETRY for any command at any time. It can take several seconds before the TPM will respond again. I measured a typical time between 3 and 4 seconds and the timeout is set at a safe 5 seconds. It is also possible to reproduce this with commands via /dev/tpm0. The bug linked above has a python script attached which can be used to test for this problem. I tested a variety of TPMs from Infineon, Nuvoton, Atmel, and STMicro but was only able to reproduce this with LPC and I2C TPMs from Infineon. The TPM specification only loosely defines this behavior: TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState: The TPM MAY declare all preserved values invalid in response to any command other than TPM_Init. TCG PC Client BIOS Spec 1.21 section 8.3.1. After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM commands before transitioning to S3 without issuing another TPM_SaveState command. TCG PC Client TIS 1.21, section 4. Power Management: The TPM_SaveState command allows a Static OS to indicate to the TPM that the platform may enter a low power state where the TPM will be required to enter into the D3 power state. The use of the term "may" is significant in that there is no requirement for the platform to actually enter the low power state after sending the TPM_SaveState command. The software may, in fact, send subsequent commands after sending the TPM_SaveState command. Change-Id: I52b41e826412688e5b6c8ddd3bb16409939704e9 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com> Cc: Dirk Hohndel <dirk@hohndel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07rt2x00: Fix transmit power troubles on some Ralink RT30xx cardsAlex A. Mihaylov
commit 7e9dafd873034dd64ababcb858be424c4780ae13 upstream. Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN value in them EEPROM/EFUSE. In this case, we must use default value, but always used EEPROM/EFUSE value. As result we have tranmitt power range from -10dBm to +6dBm instead 0dBm to +16dBm. Correctly value in EEPROM/EFUSE is one or more for RT3070 and two or more for other RT30xx chips. Tested on Canyon CNP-WF518N1 usb Wi-Fi dongle and Jorjin WN8020 usb embedded Wi-Fi module. Signed-off-by: Alex A. Mihaylov <minimumlaw@rambler.ru> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07PCI/PM: Fix fallback to PCI_D0 in pci_platform_power_transition()Rafael J. Wysocki
commit 769ba7212f2059ca9fe0c73371e3d415c8c1c529 upstream. Commit b51306c (PCI: Set device power state to PCI_D0 for device without native PM support) modified pci_platform_power_transition() by adding code causing dev->current_state for devices that don't support native PCI PM but are power-manageable by the platform to be changed to PCI_D0 regardless of the value returned by the preceding platform_pci_set_power_state(). In particular, that also is done if the platform_pci_set_power_state() has been successful, which causes the correct power state of the device set by pci_update_current_state() in that case to be overwritten by PCI_D0. Fix that mistake by making the fallback to PCI_D0 only happen if the platform_pci_set_power_state() has returned an error. [bhelgaas: folded in Yinghai's simplification, added URL & stable info] Reference: http://lkml.kernel.org/r/27806FC4E5928A408B78E88BBC67A2306F466BBA@ORSMSX101.amr.corp.intel.com Reported-by: Chris J. Benenati <chris.j.benenati@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07PCI / ACPI: Don't query OSC support with all possible controlsYinghai Lu
commit 545d6e189a41c94c11f55045a771118eccc9d9eb upstream. Found problem on system that firmware that could handle pci aer. Firmware get error reporting after pci injecting error, before os boots. But after os boots, firmware can not get report anymore, even pci=noaer is passed. Root cause: BIOS _OSC has problem with query bit checking. It turns out that BIOS vendor is copying example code from ACPI Spec. In ACPI Spec 5.0, page 290: If (Not(And(CDW1,1))) // Query flag clear? { // Disable GPEs for features granted native control. If (And(CTRL,0x01)) // Hot plug control granted? { Store(0,HPCE) // clear the hot plug SCI enable bit Store(1,HPCS) // clear the hot plug SCI status bit } ... } When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffffffe. So it will get into code path that should be for control set only. BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))" Current kernel code is using _OSC query to notify firmware about support from OS and then use _OSC to set control bits. During query support, current code is using all possible controls. So will execute code that should be only for control set stage. That will have problem when pci=noaer or aer firmware_first is used. As firmware have that control set for os aer already in query support stage, but later will not os aer handling. We should avoid passing all possible controls, just use osc_control_set instead. That should workaround BIOS bugs with affected systems on the field as more bios vendors are copying sample code from ACPI spec. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07i2c: xiic: must always write 16-bit words to TX_FIFOSteven A. Falco
commit c39e8e4354ce4daf23336de5daa28a3b01f00aa6 upstream. The TX_FIFO register is 10 bits wide. The lower 8 bits are the data to be written, while the upper two bits are flags to indicate stop/start. The driver apparently attempted to optimize write access, by only writing a byte in those cases where the stop/start bits are zero. However, we have seen cases where the lower byte is duplicated onto the upper byte by the hardware, which causes inadvertent stop/starts. This patch changes the write access to the transmit FIFO to always be 16 bits wide. Signed off by: Steven A. Falco <sfalco@harris.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07fbcon: when font is freed, clear also vc_font.dataMika Kuoppala
commit e6637d5427d2af9f3f33b95447bfc5347e5ccd85 upstream. commit ae1287865f5361fa138d4d3b1b6277908b54eac9 Author: Dave Airlie <airlied@redhat.com> Date: Thu Jan 24 16:12:41 2013 +1000 fbcon: don't lose the console font across generic->chip driver switch uses a pointer in vc->vc_font.data to load font into the new driver. However if the font is actually freed, we need to clear the data so that we don't reload font from dangling pointer. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07tty: fix up atime/mtime mess, take threeLinus Torvalds
commit b0b885657b6c8ef63a46bc9299b2a7715d19acde upstream. We first tried to avoid updating atime/mtime entirely (commit b0de59b5733d: "TTY: do not update atime/mtime on read/write"), and then limited it to only update it occasionally (commit 37b7f3c76595: "TTY: fix atime/mtime regression"), but it turns out that this was both insufficient and overkill. It was insufficient because we let people attach to the shared ptmx node to see activity without even reading atime/mtime, and it was overkill because the "only once a minute" means that you can't really tell an idle person from an active one with 'w'. So this tries to fix the problem properly. It marks the shared ptmx node as un-notifiable, and it lowers the "only once a minute" to a few seconds instead - still long enough that you can't time individual keystrokes, but short enough that you can tell whether somebody is active or not. Reported-by: Simon Kirby <sim@hostway.ca> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07gianfar: do not advertise any alarm capability.Richard Cochran
commit cd4baaaa04b4aaa3b0ec4d13a6f3d203b92eadbd upstream. An early draft of the PHC patch series included an alarm in the gianfar driver. During the review process, the alarm code was dropped, but the capability removal was overlooked. This patch fixes the issue by advertising zero alarms. This patch should be applied to every 3.x stable kernel. Signed-off-by: Richard Cochran <richardcochran@gmail.com> Reported-by: Chris LaRocque <clarocq@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07serial_core.c: add put_device() after device_find_child()Federico Vaga
commit 5a65dcc04cda41f4122aacc37a5a348454645399 upstream. The serial core uses device_find_child() but does not drop the reference to the retrieved child after using it. This patch add the missing put_device(). What I have done to test this issue. I used a machine with an AMBA PL011 serial driver. I tested the patch on next-20120408 because the last branch [next-20120415] does not boot on this board. For test purpose, I added some pr_info() messages to print the refcount after device_find_child() (lines: 1937,2009), and after put_device() (lines: 1947, 2021). Boot the machine *without* put_device(). Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 87.058575] uart_suspend_port:1937 refcount 4 [ 87.058582] uart_suspend_port:1947 refcount 4 [ 87.098083] uart_resume_port:2009refcount 5 [ 87.098088] uart_resume_port:2021 refcount 5 echo disk > /sys/power/state [ 103.055574] uart_suspend_port:1937 refcount 6 [ 103.055580] uart_suspend_port:1947 refcount 6 [ 103.095322] uart_resume_port:2009 refcount 7 [ 103.095327] uart_resume_port:2021 refcount 7 echo disk > /sys/power/state [ 252.459580] uart_suspend_port:1937 refcount 8 [ 252.459586] uart_suspend_port:1947 refcount 8 [ 252.499611] uart_resume_port:2009 refcount 9 [ 252.499616] uart_resume_port:2021 refcount 9 The refcount continuously increased. Boot the machine *with* this patch. Then: echo reboot > /sys/power/disk echo disk > /sys/power/state [ 159.333559] uart_suspend_port:1937 refcount 4 [ 159.333566] uart_suspend_port:1947 refcount 3 [ 159.372751] uart_resume_port:2009 refcount 4 [ 159.372755] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 185.713614] uart_suspend_port:1937 refcount 4 [ 185.713621] uart_suspend_port:1947 refcount 3 [ 185.752935] uart_resume_port:2009 refcount 4 [ 185.752940] uart_resume_port:2021 refcount 3 echo disk > /sys/power/state [ 207.458584] uart_suspend_port:1937 refcount 4 [ 207.458591] uart_suspend_port:1947 refcount 3 [ 207.498598] uart_resume_port:2009 refcount 4 [ 207.498605] uart_resume_port:2021 refcount 3 The refcount correctly handled. Signed-off-by: Federico Vaga <federico.vaga@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07s390/memory hotplug: prevent offline of active memory incrementsHeiko Carstens
commit 94c163663fc1dcfc067a5fb3cc1446b9469975ce upstream. In case a machine supports memory hotplug all active memory increments present at IPL time have been initialized with a "usecount" of 1. This is wrong if the memory increment size is larger than the memory section size of the memory hotplug code. If that is the case the usecount must be initialized with the number of memory sections that fit into one memory increment. Otherwise it is possible to put a memory increment into standby state even if there are still active sections. Afterwards addressing exceptions might happen which cause the kernel to panic. However even worse, if a memory increment was put into standby state and afterwards into active state again, it's contents would have been zeroed, leading to memory corruption. This was only an issue for machines that support standby memory and have at least 256GB memory. This is broken since commit fdb1bb15 "[S390] sclp/memory hotplug: fix initial usecount of increments". Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07usb-storage: CY7C68300A chips do not support Cypress ATACBTormod Volden
commit 671b4b2ba9266cbcfe7210a704e9ea487dcaa988 upstream. Many cards based on CY7C68300A/B/C use the USB ID 04b4:6830 but only the B and C variants (EZ-USB AT2LP) support the ATA Command Block functionality, according to the data sheets. The A variant (EZ-USB AT2) locks up if ATACB is attempted, until a typical 30 seconds timeout runs out and a USB reset is performed. https://bugs.launchpad.net/bugs/428469 It seems that one way to spot a CY7C68300A (at least where the card manufacturer left Cypress' EEPROM default vaules, against Cypress' recommendations) is to look at the USB string descriptor indices. A http://media.digikey.com/pdf/Data%20Sheets/Cypress%20PDFs/CY7C68300A.pdf B http://www.farnell.com/datasheets/43456.pdf C http://www.cypress.com/?rID=14189 Note that a CY7C68300B/C chip appears as CY7C68300A if it is running in Backward Compatibility Mode, and if ATACB would be supported in this case there is anyway no way to tell which chip it really is. For 5 years my external USB drive has been locking up for half a minute when plugged in and ata_id is run by udev, or anytime hdparm or similar is run on it. Finally looking at the /correct/ datasheet I think I found the reason. I am aware the quirk in this patch is a bit hacky, but the hardware manufacturers haven't made it easy for us. Signed-off-by: Tormod Volden <debian.tormod@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07usb: remove redundant tdi_resetShengzhou Liu
commit 61ac6ac8d662ac7ac67c864954d39d1b19948354 upstream. We remove the redundant tdi_reset in ehci_setup since there is already it in ehci_reset. It was observed that the duplicated tdi_reset was causing the PHY_CLK_VALID bit unstable. Reported-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07usb: chipidea: udc: fix memory leak in _ep_nukeMichael Grzeschik
commit 7ca2cd291fd84ae499390f227a255ccba2780a81 upstream. In hardware_enqueue code adds one extra td with dma_pool_alloc if mReq->req.zero is true. When _ep_nuke will be called for that endpoint, dma_pool_free will not be called to free that memory again. That patch fixes this. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07usb: chipidea: udc: fix memory access of shared memory on armv5 machinesMichael Grzeschik
commit a9c174302b1590ef3ead485d804a303c5f89174b upstream. The udc uses an shared dma memory space between hard and software. This memory layout is described in ci13xxx_qh and ci13xxx_td which are marked with the attribute ((packed)). The compiler currently does not know about the alignment of the memory layout, and will create strb and ldrb operations. The Datasheet of the synopsys core describes, that some operations on the mapped memory need to be atomic double word operations. I.e. the next pointer addressing in the qhead, as otherwise the hardware will read wrong data and totally stuck. This is also possible while working with the current active td queue, and preparing the td->ptr.next in software while the hardware is still working with the current active td which is supposed to be changed: writeb(0xde, &td->ptr.next + 0x0); /* strb */ writeb(0xad, &td->ptr.next + 0x1); /* strb */ <----- hardware reads value of td->ptr.next and get stuck! writeb(0xbe, &td->ptr.next + 0x2); /* strb */ writeb(0xef, &td->ptr.next + 0x3); /* strb */ This appeares on armv5 machines where the hardware does not support unaligned 32bit operations. This patch adds the attribute ((aligned(4))) to the structures to tell the compiler to use 32bit operations. It also adds an wmb() for the prepared TD data before it gets enqueued into the qhead. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07usbfs: Always allow ctrl requests with USB_RECIP_ENDPOINT on the ctrl epHans de Goede
commit 1361bf4b9f9ef45e628a5b89e0fd9bedfdcb7104 upstream. When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip, which for a request with USB_RECIP_ENDPOINT tries to map this to an interface to see if this interface is claimed, except for ctrl-requests with a type of USB_TYPE_VENDOR. When trying to use this device: http://www.akaipro.com/eiepro redirected to a Windows vm running on qemu on top of Linux. The windows driver makes a ctrl-req with USB_TYPE_CLASS and USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to the interface fails since ep 0 is the ctrl endpoint and thus never is part of an interface. This patch fixes this ctrl-req failing by skipping the checkintf call for USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint. Reported-by: Dave Stikkolorum <d.r.stikkolorum@hhs.nl> Tested-by: Dave Stikkolorum <d.r.stikkolorum@hhs.nl> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07USB: ftdi_sio: enable two UART ports on ST Microconnect LiteAdrian Thomasset
commit 71d9a2b95fc9c9474d46d764336efd7a5a805555 upstream. The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports. The first two ports are reserved for the JTAG interface. We enable by default ports 2 and 3 as UARTs (where port 2 is a conventional RS-232 UART) Signed-off-by: Adrian Thomasset <adrian.thomasset@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07USB: ftdi_sio: correct ST Micro Connect Lite PIDsAdrian Thomasset
commit 9f06d15f8db6946e41f73196a122b84a37938878 upstream. The current ST Micro Connect Lite uses the FT4232H hi-speed quad USB UART FTDI chip. It is also possible to drive STM reference targets populated with an on-board JTAG debugger based on the FT2232H chip with the same STMicroelectronics tools. For this reason, the ST Micro Connect Lite PIDs should be ST_STMCLT_2232_PID: 0x3746 ST_STMCLT_4232_PID: 0x3747 Signed-off-by: Adrian Thomasset <adrian.thomasset@st.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07USB: add ftdi_sio USB ID for GDM Boost V1.xStefani Seibold
commit 58f8b6c4fa5a13cb2ddb400e26e9e65766d71e38 upstream. This patch add a missing usb device id for the GDMBoost V1.x device The patch is against 3.9-rc5 Signed-off-by: Stefani Seibold <stefani@seibold.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07usb/misc/appledisplay: Add 24" LED Cinema displayBen Jencks
commit e7d3b6e22c871ba36d052ca99bc8ceca4d546a60 upstream. Add the Apple 24" LED Cinema display to the supported devices. Signed-off-by: Ben Jencks <ben@bjencks.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07mwifiex: Call pci_release_region after calling pci_disable_deviceYogesh Ashok Powar
commit 5b0d9b218b74042ff72bf4bfda6eeb2e4bf98397 upstream. "drivers should call pci_release_region() AFTER calling pci_disable_device()" Please refer section 3.2 Request MMIO/IOP resources in Documentation/PCI/pci.txt Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07mwifiex: Use pci_release_region() instead of a pci_release_regions()Yogesh Ashok Powar
commit c380aafb77b7435d010698fe3ca6d3e1cd745fde upstream. PCI regions are associated with the device using pci_request_region() call. Hence use pci_release_region() instead of pci_release_regions(). Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07iwlwifi: dvm: don't send zeroed LQ cmdEmmanuel Grumbach
commit 63b77bf489881747c5118476918cc8c29378ee63 upstream. When the stations are being restored because of unassoc RXON, the LQ cmd may not have been initialized because it is initialized only after association. Sending zeroed LQ_CMD makes the fw unhappy: it raises SYSASSERT_2078. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> [move zero_lq and make static const] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07iwlwifi: fix freeing uninitialized pointerStanislaw Gruszka
commit 3309ccf7fcebceef540ebe90c65d2f94d745a45b upstream. If on iwl_dump_nic_event_log() error occurs before that function initialize buf, we process uninitiated pointer in iwl_dbgfs_log_event_read() and can hit "BUG at mm/slub.c:3409" Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=951241 Reported-by: ian.odette@eprize.com Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07staging: zsmalloc: Fix link error on ARMJoerg Roedel
commit d95abbbb291bf5bce078148f53603ce9c0aa1d44 upstream. Testing the arm chromebook config against the upstream kernel produces a linker error for the zsmalloc module from staging. The symbol flush_tlb_kernel_range is not available there. Fix this by removing the reimplementation of unmap_kernel_range in the zsmalloc module and using the function directly. The unmap_kernel_range function is not usable by modules, so also disallow building the driver as a module for now. Signed-off-by: Joerg Roedel <joro@8bytes.org> Acked-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07USB: option: add a D-Link DWM-156 variantBjørn Mork
commit a2a2d6c7f93e160b52a4ad0164db1f43f743ae0f upstream. Adding support for a Mediatek based device labelled as D-Link Model: DWM-156, H/W Ver: A7 Also adding two other device IDs found in the Debian(!) packages included on the embedded device driver CD. This is a composite MBIM + serial ports + card reader device: T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7d01 Rev= 3.00 S: Manufacturer=D-Link,Inc S: Product=D-Link DWM-156 C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-07USB: serial: option: Added support Olivetti Olicard 145Filippo Turato
commit d19bf5cedfd7d53854a3bd699c98b467b139833b upstream. This adds PID for Olivetti Olicard 145 in option.c Signed-off-by: Filippo Turato <nnj7585@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01net: cdc_mbim: remove bogus sizeof()Bjørn Mork
[ Upstream commit 32b161aa88aa40a83888a995c6e2ef81140219b1 ] The intention was to test against the constant, not the size of the constant. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01net: mvneta: fix improper tx queue usage in mvneta_tx()Willy Tarreau
[ Upstream commit ee40a116ebf139f900c3d2e6febb8388738e96d0 ] mvneta_tx() was using a static tx queue number causing crashes as soon as a little bit of traffic was sent via the interface, because it is normally expected that the same queue should be used as in dev_queue_xmit(). As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to get the proper Tx queue number, and use alloc_etherdev_mqs() instead of alloc_etherdev_mq() to create the queues. Both my Mirabox and my OpenBlocks AX3 used to crash without this patch and don't anymore with it. The issue appeared in 3.8 but became more visible after the fix allowing GSO to be enabled. Original work was done by Dmitri Epshtein and Thomas Petazzoni. I just adapted it to take care of Ben's comments. Signed-off-by: Willy Tarreau <w@1wt.eu> Cc: Dmitri Epshtein <dima@marvell.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: Ben Hutchings <bhutchings@solarflare.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01net: mvmdio: add select PHYLIBThomas Petazzoni
[ Upstream commit 2e0cbf2cc2c9371f0aa198857d799175ffe231a6 ] The mvmdio driver uses the phylib API, so it should select the PHYLIB symbol, otherwise, a build with mvmdio (but without mvneta) fails to build with undefined symbols such as mdiobus_unregister, mdiobus_free, etc. The mvneta driver does not use the phylib API directly, so it does not need to select PHYLIB. It already selects the mvmdio driver anyway. Historically, this problem is due to the fact that the PHY handling was originally part of mvneta, and was later moved to a separate driver, without updating the Kconfig select statements accordingly. And since there was no functional reason to use mvmdio without mvneta, this case was not tested. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01bonding: fix l23 and l34 load balancing in forwarding pathEric Dumazet
[ Upstream commit 4394542ca4ec9f28c3c8405063d200b1e7c347d7 ] Since commit 6b923cb7188d46 (bonding: support for IPv6 transmit hashing) bonding doesn't properly hash traffic in forwarding setups. Vitaly V. Bursov diagnosed that skb_network_header_len() returned 0 in this case. More generally, the transport header might not be in the skb head. Use pskb_may_pull() & skb_header_pointer() to get it right, and use proto_ports_offset() in bond_xmit_hash_policy_l34() to get support for more protocols than TCP and UDP. Reported-by: Vitaly V. Bursov <vitalyb@telenet.dn.ua> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jay Vosburgh <fubar@us.ibm.com> Cc: Andy Gospodarek <andy@greyhouse.net> Cc: John Eaglesham <linux@8192.net> Tested-by: Vitaly V. Bursov <vitalyb@telenet.dn.ua> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01bonding: IFF_BONDING is not stripped on enslave failurenikolay@redhat.com
[ Upstream commit b6a5a7b9a528a8b4c8bec940b607c5dd9102b8cc ] While enslaving a new device and after IFF_BONDING flag is set, in case of failure it is not stripped from the device's priv_flags while cleaning up, which could lead to other problems. Cleaning at err_close because the flag is set after dev_open(). v2: no change Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01bonding: fix bonding_masters race condition in bond unloadingnikolay@redhat.com
[ Upstream commit 69b0216ac255f523556fa3d4ff030d857eaaa37f ] While the bonding module is unloading, it is considered that after rtnl_link_unregister all bond devices are destroyed but since no synchronization mechanism exists, a new bond device can be created via bonding_masters before unregister_pernet_subsys which would lead to multiple problems (e.g. NULL pointer dereference, wrong RIP, list corruption). This patch fixes the issue by removing any bond devices left in the netns after bonding_masters is removed from sysfs. Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com> Acked-by: Veaceslav Falico <vfalico@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01atl1e: limit gso segment size to prevent generation of wrong ip length fieldsHannes Frederic Sowa
[ Upstream commit 31d1670e73f4911fe401273a8f576edc9c2b5fea ] The limit of 0x3c00 is taken from the windows driver. Suggested-by: Huang, Xiong <xiong@qca.qualcomm.com> Cc: Huang, Xiong <xiong@qca.qualcomm.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01TTY: fix atime/mtime regressionJiri Slaby
commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream. In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write") we removed timestamps from tty inodes to fix a security issue and waited if something breaks. Well, 'w', the utility to find out logged users and their inactivity time broke. It shows that users are inactive since the time they logged in. To revert to the old behaviour while still preventing attackers to guess the password length, we update the timestamps in one-minute intervals by this patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-01TTY: do not update atime/mtime on read/writeJiri Slaby
commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream. On http://vladz.devzero.fr/013_ptmx-timing.php, we can see how to find out length of a password using timestamps of /dev/ptmx. It is documented in "Timing Analysis of Keystrokes and Timing Attacks on SSH". To avoid that problem, do not update time when reading from/writing to a TTY. I am afraid of regressions as this is a behavior we have since 0.97 and apps may expect the time to be current, e.g. for monitoring whether there was a change on the TTY. Now, there is no change. So this would better have a lot of testing before it goes upstream. References: CVE-2013-0160 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-25vm: convert mtdchar mmap to vm_iomap_memory() helperLinus Torvalds
commit 8558e4a26b00225efeb085725bc319f91201b239 upstream. This is my example conversion of a few existing mmap users. The mtdchar case is actually disabled right now (and stays disabled), but I did it because it showed up on my "git grep", and I was familiar with the code due to fixing an overflow problem in the code in commit 9c603e53d380 ("mtdchar: fix offset overflow detection"). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-25vm: convert HPET mmap to vm_iomap_memory() helperLinus Torvalds
commit 2323036dfec8ce3ce6e1c86a49a31b039f3300d1 upstream. This is my example conversion of a few existing mmap users. The HPET case is simple, widely available, and easy to test (Clemens Ladisch sent a trivial test-program for it). Test-program-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-25vm: convert fb_mmap to vm_iomap_memory() helperLinus Torvalds
commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream. This is my example conversion of a few existing mmap users. The fb_mmap() case is a good example because it is a bit more complicated than some: fb_mmap() mmaps one of two different memory areas depending on the page offset of the mmap (but happily there is never any mixing of the two, so the helper function still works). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>