- 18 Feb, 2014 4 commits
-
-
Matt Porter authored
The readsl and writesl I/O accessors are only defined on some architectures. The driver currently depends on CONFIG_ARM because the build breaks on x86, in particular. Switch to use of ioread32_rep and iowrite32_rep to fix build on all architectures and remove the CONFIG_ARM dependency. Also update printk formatting to handle a long long dma_addr_t to avoid warnings on !32-bit architectures. Signed-off-by: Matt Porter <mporter@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
George Cherian authored
In case of ISOCH transfers the hrtimer workaround for the hardware issue is not very reliable. Instead of checking musb_is_tx_fifo_empty() in hrtimer routine, schedule a completion work and check the same in completion work. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
George Cherian authored
Enable CPPI to handle high bandwidth transfers, especially to support webcam captures. Use a single bd to get the whole of the data in case of high bandwidth transfers. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
George Cherian authored
Enable the isochrounous IN handling for AM335x HOST. Reprogram CPPI to receive consecutive ISOCH frames in the same URB. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
- 15 Feb, 2014 5 commits
-
-
Hans de Goede authored
include/phy/phy.h has stub code in there for when building without the phy-core enabled. This is useful for generic drivers such as ahci-platform, ehci-platoform and ohci-platform which have support for driving an optional phy passed to them through the devicetree. Since on some boards this phy functionality is not needed, being able to disable the phy subsystem without needing a lot of #ifdef magic in the driver using it is quite useful. However this breaks when the module using the phy subsystem is build-in and the phy-core is not, which leads to the build failing with missing symbol errors in the linking stage of the zImage. Which leads to gems such as this being added to the Kconfig for achi_platform: depends on GENERIC_PHY || !GENERIC_PHY Rather then duplicating this code in a lot of places using the phy-core, I believe it is better to simply not allow the phy-core to be built as a module. The phy core is quite small and has no external dependencies, so always building it in when enabling it should not be an issue. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christian Vogel authored
The "Webmail Notifier" is a USB controlled LED that appears as a HID device. When trying to change the LED via hidraw it returns malformed reports. As "usbled" supports it, we blacklist it in usbhid. Signed-off-by: Christian Vogel <vogelchr@vogel.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Zimmerman authored
In a couple of places, we were checking qtd->urb for NULL after we had already dereferenced it. Fix this by moving the check to before the dereference. Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
This brings the xhci-platform bindings in sync with what we've done for the ohci- and ehci-platform drivers. As discussed there using platform as a postfix is a bit weird as the platform bus is a Linux specific thing and the bindings are supposed to be OS agnostic. Note that the old xhci-platform compatible string is kept around for, well, compatibility reasons. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
This brings the uhci-platform bindings in sync with what we've done for the ohci- and ehci-platform drivers. As discussed there using platform as a prefix is a bit weird as the platform bus is a Linux specific thing and the bindings are supposed to be OS agnostic. Note that the old platform-uhci compatible string is kept around for, well, compatibility reasons. While at it rename the bindings txt file to match the name of all the other ?hci-platform bindings docs. 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>
-
- 11 Feb, 2014 7 commits
-
-
Christian Vogel authored
Add support for the "Webmail Notifier" (USB powered LED for signaling new emails) made by Riso Kagaku Corp. which displays 7 distinct colors. USB Protocol initially reverse engineered by https://code.google.com/p/usbmailnotifier/. Signed-off-by: Christian Vogel <vogelchr@vogel.cx> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Bolle authored
The Kconfig entries for USB_U132_HCD and USB_FTDI_ELAN default to (uppercase) "M". But in Kconfig (lowercase) "m" is a magic symbol. "M" is an ordinary symbol. As "M" is never set these Kconfig symbols will also not be set by default. Since I'm not aware of a reason why these driver should be set by default, let's just drop these lines (that basically do nothing). Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Richard Weinberger authored
The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
The ohci-platform driver checks for misconfigurations in cases where the Device Tree data specifies big-endian registers or descriptors but the corresponding driver config settings have not been enabled. As Jonas Gorski suggested, we may as well apply the same check to general platform data too. This requires moving the code that sets the big-endian quirk flags from the ohci_platform_reset() routine into ohci_platform_probe(), and moving the checks out of the DT-specific "if" statement clause. The patch also changes the text of the error messages in an attempt to make the nature of the error more clear. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Jonas Gorski <jogo@openwrt.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
The ehci-platform driver checks for misconfigurations in cases where the Device Tree data specifies big-endian registers or descriptors but the corresponding driver config settings have not been enabled. As Jonas Gorski suggested, we may as well apply the same check to general platform data too. This requires moving the code that sets the big-endian quirk flags from the ehci_platform_reset() routine into ehci_platform_probe(), and moving the checks out of the DT-specific "if" statement clause. The patch also changes the text of the error messages in an attempt to make the nature of the error more clear. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Jonas Gorski <jogo@openwrt.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
The initial versions of the devicetree enablement patches for ehci-platform used "ehci-platform" as compatible string. However this was disliked by various reviewers because the platform bus is a Linux invention and devicetree is supposed to be OS agnostic. After much discussion I gave up, added a: "depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms and went with the generic usb-ehci as requested. In retro-spect I should have chosen something different, the dts files for many existing boards already claim to be compatible with "usb-ehci", ie they have: compatible = "ti,ehci-omap", "usb-ehci"; In theory this should not be a problem since the "ti,ehci-omap" entry takes presedence, but in practice using a conflicting compatible string is an issue, because it makes which driver gets used depend on driver registration order. This patch changes the compatible string claimed by ehci-platform to "generic-ehci", avoiding the driver registration / module loading ordering problems, and removes the "depends on !PPC_OF" workaround. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
The initial versions of the devicetree enablement patches for ohci-platform used "ohci-platform" as compatible string. However this was disliked by various reviewers because the platform bus is a Linux invention and devicetree is supposed to be OS agnostic. After much discussion I gave up and went with the generic usb-ohci as requested. In retro-spect I should have chosen something different, the dts files for many existing boards already claim to be compatible with "usb-ohci", ie they have: compatible = "ti,ohci-omap3", "usb-ohci"; In theory this should not be a problem since the "ti,ohci-omap3" entry takes presedence, but in practice using a conflicting compatible string is an issue, because it makes which driver gets used depend on driver registration order. This patch changes the compatible string claimed by ohci-platform to "generic-ohci", avoiding the driver registration / module loading ordering problems. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Kevin Hilman <khilman@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 Feb, 2014 8 commits
-
-
Shaibal Dutta authored
Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
Free "motog" on error. This is more to appease the static checkers than a real worry. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dinh Nguyen authored
According to the spec for the DWC2 controller, when the PRTINT interrupt fires, the application must clear the appropriate status bit in the Host Port Control and Status register to clear this bit. When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, but only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0 register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly clear the GINTSTS_PRTINT interrupt. I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode and is never cleared. This patch adds the function to read the HPRT0 register when the PRTINT fires and the dwc2 IP has already transitioned to device mode. This function is only clearing the HPRT0_ENACHG bit for now, but can be modified to handle more. Signed-off-by: Dinh Nguyen <dinguyen@altera.com> [ paulz: modified patch to preserve HPRT0_ENA bit ] Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
This uses the already documented devicetree booleans for this, see: Documentation/devicetree/bindings/usb/usb-ehci.txt Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
Note this commit uses the same devicetree booleans for this as the ones already existing in the usb-ehci bindings, see: Documentation/devicetree/bindings/usb/usb-ehci.txt Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
Currently ehci-platform is only used in combination with devicetree when used with some Via socs. By extending it to (optionally) get clks and a phy from devicetree, and enabling / disabling those on power_on / off, it can be used more generically. Specifically after this commit it can be used for the ehci controller on Allwinner sunxi SoCs. Since ehci-platform is intended to handle any generic enough non pci ehci device, add a "usb-ehci" compatibility string. There already is a usb-ehci device-tree bindings document, update this with clks and phy bindings info. Although actually quite generic so far the via,vt8500 compatibilty string had its own bindings document. Somehow we even ended up with 2 of them. Since these provide no extra information over the generic usb-ehci documentation, this patch removes them. The ehci-ppc-of.c driver also claims the usb-ehci compatibility string, even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid 2 drivers claiming the same compatibility string getting build on ppc. 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>
-
Hans de Goede authored
Add support for ohci-platform instantiation from devicetree, including optionally getting clks and a phy from devicetree, and enabling / disabling those on power_on / off. This should allow using ohci-platform from devicetree in various cases. Specifically after this commit it can be used for the ohci controller found on Allwinner sunxi SoCs. 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>
-
Bjørn Mork authored
This modifies the probing order so that any matching dynamic entry always will be used, even if the driver has a matching static entry. It is sometimes useful to dynamically update existing device entries. With the new ability to set the dynamic entry driver_info field, this can be used to test new additions to class driver exception lists or proposed changes to existing static per-device driver_info entries. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 Feb, 2014 10 commits
-
-
Alan Stern authored
People sometimes create their own custom-configured kernels and forget to enable CONFIG_SCSI_MULTI_LUN. This causes problems when they plug in a USB storage device (such as a card reader) with more than one LUN. Fortunately, we can tell fairly easily when a storage device claims to have more than one LUN. When that happens, this patch asks the SCSI layer to probe all the LUNs automatically, regardless of the config setting. The patch also updates the Kconfig help text for usb-storage, explaining that CONFIG_SCSI_MULTI_LUN may be necessary. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Thomas Raschbacher <lordvan@lordvan.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> CC: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kristóf Ralovich authored
Add support for ANT USB-m Stick from Dynastream Innovations, by listing USB pid [34366.944805] usb 6-1: New USB device found, idVendor=0fcf, idProduct=1009 [34366.944817] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [34366.944824] usb 6-1: Product: ANT USB-m Stick [34366.944831] usb 6-1: Manufacturer: Dynastream Innovations Device reported (https://code.google.com/p/antpm/issues/detail?id=5) to work through: $ modprobe usbserial vendor=0x0fcf product=0x1009 Signed-off-by: Kristóf Ralovich <kristof.ralovich@gmail.com> Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
This patch adds an unusual-devs entry for the BlackBerry 9000. This fixes Bugzilla #22442. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Tested-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
The Cypress ATACB unusual-devs entry for the Super Top SATA bridge causes problems. Although it was originally reported only for bcdDevice = 0x160, its range was much larger. This resulted in a bug report for bcdDevice 0x220, so the range was capped at 0x219. Now Milan reports errors with bcdDevice 0x150. Therefore this patch restricts the range to just 0x160. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Milan Svoboda <milan.svoboda@centrum.cz> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Josh Boyer authored
the PHY layer is supposed to be optional, considering some PHY have no control bus for SW to poke around. After commit 1ae5799e (usb: hcd: Initialize USB phy if needed) any HCD which didn't provide a PHY driver would emit annoying error messages. In this patch we're decreasing those messages to debugging only and we also add a PHY prefix or use dev_dbg so we know where they're coming from. Reported-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bjørn Mork authored
Cc: stable <stable@vger.kernel.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Zimmerman authored
The move from the staging tree to the main tree exposed a longstanding memory corruption bug in the dwc2 driver. The reordering of the driver initialization caused the dwc2 driver to corrupt the initialization data of the sdhci driver on the Raspberry Pi platform, which made the bug show up. The error is in calling to_usb_device(hsotg->dev), since ->dev is not a member of struct usb_device. The easiest fix is to just remove the offending code, since it is not really needed. Thanks to Stephen Warren for tracking down the cause of this. Reported-by: Andre Heider <a.heider@gmail.com> Tested-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Zimmerman authored
Commit beb7e592 "staging: dwc2: add check on dwc2_core_reset return" broke the B -> A role switching on OTG-enabled platforms. This commit fixes it. Reported-by: Dinh Nguyen <dinguyen@altera.com> Tested-by: Dinh Nguyen <dinguyen@altera.com> Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andre Heider authored
Add usb_disabled() check to prevent kernel oops when booting with "nousb" in the cmdline: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at bus_add_device+0xe0/0x18c LR is at device_add_groups+0x1c/0x20 ... [<c02191c0>] (bus_add_device) from [<c0217130>] (device_add+0x41c/0x538) [<c0217130>] (device_add) from [<c023b1d4>] (usb_new_device+0x270/0x35c) [<c023b1d4>] (usb_new_device) from [<c0241174>] (usb_add_hcd+0x4fc/0x760) [<c0241174>] (usb_add_hcd) from [<c0254ce0>] (dwc2_hcd_init+0x434/0x510) [<c0254ce0>] (dwc2_hcd_init) from [<c02594f4>] (dwc2_driver_probe+0x130/0x170) [<c02594f4>] (dwc2_driver_probe) from [<c021bbd0>] (platform_drv_probe+0x28/0x58) Signed-off-by: Andre Heider <a.heider@gmail.com> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Merge tag 'for-usb-linus-2014-02-04' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus Sarah writes: xhci: Fix some regressions introduced in 3.14. Hi Greg, Here's four patches for 3.14. One of them adds an xHCI host quirk, and the other three of them fix regressions introduced in 3.14. One regression causes USB 3.0 Link PM to be enabled on all xHCI hosts (even those that may not support it), which causes some USB 3.0 devices to not enumerate. A second regression causes some xHCI hosts that don't support 64-bit addressing to stop responding to commands and die. Note, these patches don't fix the recent usbfs regression that was caused by commit 35773dac "usb: xhci: Link TRB must not occur within a USB payload burst". I'm waiting for those patches to be tested. Please pull usb-linus into usb-next, as I have feature patches that rely on 140e3026 Revert "usbcore: set lpm_capable field for LPM capable root hubs" Sarah Sharp
-
- 03 Feb, 2014 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc updates from Helge Deller: "The three major changes in this patchset is a implementation for flexible userspace memory maps, cache-flushing fixes (again), and a long-discussed ABI change to make EWOULDBLOCK the same value as EAGAIN. parisc has been the only platform where we had EWOULDBLOCK != EAGAIN to keep HP-UX compatibility. Since we will probably never implement full HP-UX support, we prefer to drop this compatibility to make it easier for us with Linux userspace programs which mostly never checked for both values. We don't expect major fall-outs because of this change, and if we face some, we will simply rebuild the necessary applications in the debian archives" * 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: add flexible mmap memory layout support parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc parisc: convert uapi/asm/stat.h to use native types only parisc: wire up sched_setattr and sched_getattr parisc: fix cache-flushing parisc/sti_console: prefer Linux fonts over built-in ROM fonts
-
Mikulas Patocka authored
HPFS needs to load 4 consecutive 512-byte sectors when accessing the directory nodes or bitmaps. We can't switch to 2048-byte block size because files are allocated in the units of 512-byte sectors. Previously, the driver would allocate a 2048-byte area using kmalloc, copy the data from four buffers to this area and eventually copy them back if they were modified. In the current implementation of the buffer cache, buffers are allocated in the pagecache. That means that 4 consecutive 512-byte buffers are stored in consecutive areas in the kernel address space. So, we don't need to allocate extra memory and copy the content of the buffers there. This patch optimizes the code to avoid copying the buffers. It checks if the four buffers are stored in contiguous memory - if they are not, it falls back to allocating a 2048-byte area and copying data there. Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Mikulas Patocka authored
Previously, hpfs scanned all bitmaps each time the user asked for free space using statfs. This patch changes it so that hpfs scans the bitmaps only once, remembes the free space and on next invocation of statfs it returns the value instantly. New versions of wine are hammering on the statfs syscall very heavily, making some games unplayable when they're stored on hpfs, with load times in minutes. This should be backported to the stable kernels because it fixes user-visible problem (excessive level load times in wine). Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 02 Feb, 2014 2 commits
-
-
Helge Deller authored
Add support for the flexible mmap memory layout (as described in http://lwn.net/Articles/91829). This is especially very interesting on parisc since we currently only support 32bit userspace (even with a 64bit Linux kernel). Signed-off-by: Helge Deller <deller@gmx.de>
-
Guy Martin authored
On Linux, only parisc uses a different value for EWOULDBLOCK which causes a lot of troubles for applications not checking for both values. Since the hpux compat is long dead, make EWOULDBLOCK behave the same as all other architectures. Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> Signed-off-by: Helge Deller <deller@gmx.de>
-