1. 18 Oct, 2015 14 commits
    • Peter Hurley's avatar
      tty: r3964: Replace/remove bogus tty lock use · aba24888
      Peter Hurley authored
      The tty lock is strictly for serializing tty lifetime events
      (open/close/hangup), and not for line discipline serialization.
      
      The tty core already provides serialization of concurrent writes
      to the same tty, and line discipline lifetime management (by ldisc
      references), so pinning the tty via tty_lock() is unnecessary and
      counter-productive; remove tty lock use.
      
      However, the line discipline is responsible for serializing reads
      (if required by the line discipline); add read_lock mutex to
      serialize calls of r3964_read().
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aba24888
    • Peter Hurley's avatar
      tty: r3964: Use tty->read_wait waitqueue · 9b9ab1b3
      Peter Hurley authored
      The tty core provides read_wait waitqueue specifically for line
      disciplines to wait readers; otherwise, the line discipline may
      miss wakeups generated by the tty core.
      
      NB: The tty core already provides serialization for the line discipline's
      close() method, and guarantees no readers or writers will be using the
      closing instance of the line discipline. Completely remove that wakeup.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b9ab1b3
    • Peter Hurley's avatar
      tty: Remove tty_port::close_wait · cc2aaabf
      Peter Hurley authored
      With the removal of tty_wait_until_sent_from_close(), tty drivers
      no longer wait during open for parallel closes to complete (instead,
      the tty core waits before calling the driver open() method). Thus,
      the close_wait waitqueue is no longer used for waiting.
      
      Remove struct tty_port::close_wait.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc2aaabf
    • Peter Hurley's avatar
      usb: gadget: gserial: Privatize close_wait · b140dfe6
      Peter Hurley authored
      close_wait is no longer needed or provided by the tty core.
      Move close_wait to struct gs_port.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b140dfe6
    • Peter Hurley's avatar
      tty: Remove ASYNC_CLOSING checks in open()/hangup() methods · fef062cb
      Peter Hurley authored
      Since at least before 2.6.30, tty drivers that do not drop the tty lock
      while closing cannot observe ASYNC_CLOSING set while holding the
      tty lock; this includes the tty driver's open() and hangup() methods,
      since the tty core calls these methods holding the tty lock.
      
      For these drivers, waiting for ASYNC_CLOSING to clear while opening
      is not required, since this condition cannot occur. Similarly, even
      when the open() method drops and reacquires the tty lock after
      blocking, ASYNC_CLOSING cannot be set (again, for drivers that
      do not drop the tty lock while closing).
      
      Now that tty port drivers no longer drop the tty lock while closing
      (since 'tty: Remove tty_wait_until_sent_from_close()'), the same
      conditions apply: waiting for ASYNC_CLOSING to clear while opening
      is not required, nor is re-checking ASYNC_CLOSING after dropping and
      reacquiring the tty lock while blocking (eg., in *_block_til_ready()).
      
      Note: The ASYNC_CLOSING flag state is still maintained since several
      bitrotting drivers use it for (dubious) other purposes.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fef062cb
    • Peter Hurley's avatar
      tty: Remove tty_wait_until_sent_from_close() · 79c1faa4
      Peter Hurley authored
      tty_wait_until_sent_from_close() drops the tty lock while waiting
      for the tty driver to finish sending previously accepted data (ie.,
      data remaining in its write buffer and transmit fifo).
      
      tty_wait_until_sent_from_close() was added by commit a57a7bf3
      ("TTY: define tty_wait_until_sent_from_close") to prevent the entire
      tty subsystem from being unable to open new ttys while waiting for
      one tty to close while output drained.
      
      However, since commit 0911261d ("tty: Don't take tty_mutex for tty
      count changes"), holding a tty lock while closing does not prevent other
      ttys from being opened/closed/hung up, but only prevents lifetime event
      changes for the tty under lock.
      
      Holding the tty lock while waiting for output to drain does prevent
      parallel non-blocking opens (O_NONBLOCK) from advancing or returning
      while the tty lock is held. However, all parallel opens _already_
      block even if the tty lock is dropped while closing and the parallel
      open advances. Blocking in open has been in mainline since at least 2.6.29
      (see tty_port_block_til_ready(); note the test for O_NONBLOCK is _after_
      the wait while ASYNC_CLOSING).
      
      IOW, before this patch a non-blocking open will sleep anyway for the
      _entire_ duration of a parallel hardware shutdown, and when it wakes, the
      error return will cause a release of its tty, and it will restart with
      a fresh attempt to open. Similarly with a blocking open that is already
      waiting; when it's woken, the hardware shutdown has already completed
      to ASYNC_INITIALIZED is not set, which forces a release and restart as
      well.
      
      So, holding the tty lock across the _entire_ close (which is what this
      patch does), even while waiting for output to drain, is equivalent to
      the current outcome wrt parallel opens.
      
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: David Laight <David.Laight@aculab.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Karsten Keil <isdn@linux-pingi.de>
      CC: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79c1faa4
    • Jon Hunter's avatar
      serial: tegra: Add helper function for handling RX buffer · 32ede4a5
      Jon Hunter authored
      In the tegra UART driver there are three places where the RX DMA buffer
      is handled and pushed up to the tty layer. In all three instances the
      same functions are called and so instead of duplicating the code in three
      places, move this code to a new helper function and use this new function.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32ede4a5
    • Jon Hunter's avatar
      serial: tegra: Remove redundant code and check in tegra_uart_stop_rx() · b0e066cc
      Jon Hunter authored
      The serial-tegra driver always uses DMA and hence the driver always
      allocates DMA channels. Therefore, the test to see if the RX DMA channel
      is initialised in tegra_uart_stop_rx() is unnecessary and so remove
      the test and the code that corresponds to the case where the RX DMA
      channel is not initialised. Please note that the call to
      tegra_uart_stop_rx() should always be before the call to
      tegra_uart_shutdown() which will uninitialise the RX DMA channel.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0e066cc
    • Jon Hunter's avatar
      serial: tegra: Remove unnecessary return statements · 2230a947
      Jon Hunter authored
      Some functions in the serial-tegra driver have unnecessary return
      statements at the end of a void function and so remove them.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2230a947
    • Jon Hunter's avatar
      serial: tegra: Handle another RX race condition · 2a24bb28
      Jon Hunter authored
      Commit 853a6997 ("serial: tegra: handle race condition on uart rx
      side") attempted to fix a race condition between the RX end of
      transmission interrupt and RX DMA completion callback. Despite this
      fix there is still another case where these two paths can race and
      result in duplicated data. The race condition is as follows:
      
      1. DMA completion interrupt occurs and schedules tasklet to call DMA
         callback.
      2. DMA callback for the UART driver starts to execute. This will copy
         the data from the DMA buffer and restart the DMA. This is done under
         uart port spinlock.
      3. During the callback, UART interrupt is raised for end of receive. The
         UART ISR runs and waits to acquire port spinlock held by the DMA
         callback.
      4. DMA callback gives up spinlock after copying the data, but before
         restarting DMA.
      5. UART ISR acquires the spin lock and reads the same DMA buffer because
         DMA has not been restarted yet.
      
      The release of the spinlock during the DMA callback was introduced by
      commit 9b88748b ("tty: serial: tegra: drop uart_port->lock before
      calling tty_flip_buffer_push()") to fix a spinlock lock-up issue when
      calling tty_flip_buffer_push(). However, since then commit a9c3f68f
      ("tty: Fix low_latency BUG") migrated tty_flip_buffer_push() to always
      use a workqueue, allowing tty_flip_buffer_push() to be called from
      within atomic sections. Therefore, we can remove the unlocking of the
      spinlock from the DMA callback and UART ISR and this will ensure that
      the race condition no longer occurs.
      Reported-by: default avatarChristopher Freeman <cfreeman@nvidia.com>
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a24bb28
    • Peter Hurley's avatar
      serial: 8250_omap: Remove RTS clear · 0abcc6df
      Peter Hurley authored
      Clearing UART_MCR_RTS or UART_MCR_XONANY is unnecessary; these bits
      are never set in the shadow mcr. The RTS clear is especially confusing.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0abcc6df
    • Scott Wood's avatar
      serial: Enable Freescale 16550 workaround on arm · d43b54d2
      Scott Wood authored
      The same serial hardware is present on LS2080A which is arm64, and
      LS1021A which is arm32, so don't limit the workaround to PPC.
      
      Unlike PPC which uses arch/powerpc/kernel/legacy_serial.c, the ARM
      targets use drivers/tty/serial/of_serial.c, so add the handle_irq
      override check there as well.
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d43b54d2
    • Andreas Werner's avatar
      tty: serial: men_z135_uart.c: use mcb memory region size instead of hardcoded one · 37f06799
      Andreas Werner authored
      There is no need to hardcode the MEN_Z135_MEM_SIZE. The MCB subsystem
      already knowns the size which is located in the chameleon table.
      MCB parse the chameleon table to get the resources of each IP and provide
      the mcb_request_mem function to get those resources.
      
      Use mcb_request_mem to get the resources. This function also takes care of
      the memory region naming allocated by the driver for each of the instances.
      Signed-off-by: default avatarAndreas Werner <andy@wernerandy.de>
      Acked-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37f06799
    • Andre Przywara's avatar
      serial: atmel: fix compiler warning on address cast · 270c2ade
      Andre Przywara authored
      Turning on KVM and LPAE support on top of a multi_v7_defconfig will
      produce a compiler warning in the Atmel serial driver:
      drivers/tty/serial/atmel_serial.c: In function 'atmel_verify_port':
      drivers/tty/serial/atmel_serial.c:2299:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
        if ((void *)port->mapbase != ser->iomem_base)
            ^
      
      Fix that by using the cast on the right hand side instead, as similar
      code already does in other drivers.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      270c2ade
  2. 12 Oct, 2015 1 commit
  3. 11 Oct, 2015 8 commits
  4. 10 Oct, 2015 12 commits
  5. 09 Oct, 2015 5 commits
    • Linus Torvalds's avatar
      Merge tag 'dm-4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 04445556
      Linus Torvalds authored
      Pull dm fixes from Mike Snitzer:
       "Three stable fixes:
      
         - DM core AB-BA deadlock fix in the device destruction path (vs
           device creation's DM table swap).
      
         - DM raid fix to properly round up the region_size to the next
           power-of-2.
      
         - DM cache fix for a NULL pointer seen while switching from the
           "cleaner" cache policy.
      
        Two fixes for regressions introduced during the 4.3 merge:
      
         - request-based DM error propagation regressed due to incorrect
           changes introduced when adding the bi_error field to bio.
      
         - DM snapshot fix to only support snapshots that overflow if the
           client (e.g. lvm2) is prepared to deal with the associated
           snapshot status interface change"
      
      * tag 'dm-4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm snapshot: add new persistent store option to support overflow
        dm cache: fix NULL pointer when switching from cleaner policy
        dm: fix request-based dm error reporting
        dm raid: fix round up of default region size
        dm: fix AB-BA deadlock in __dm_destroy()
      04445556
    • Linus Torvalds's avatar
      Merge branch 'for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 175d58cf
      Linus Torvalds authored
      Pull btrfs fixes from Chris Mason:
       "These are small and assorted.  Neil's is the oldest, I dropped the
        ball thinking he was going to send it in"
      
      * 'for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: support NFSv2 export
        Btrfs: open_ctree: Fix possible memory leak
        Btrfs: fix deadlock when finalizing block group creation
        Btrfs: update fix for read corruption of compressed and shared extents
        Btrfs: send, fix corner case for reference overwrite detection
      175d58cf
    • Linus Torvalds's avatar
      Merge tag 'nfsd-4.3-1' of git://linux-nfs.org/~bfields/linux · 38aa0a59
      Linus Torvalds authored
      Pull nfsd bugfix from Bruce Fields:
       "Just one RDMA bugfix"
      
      * tag 'nfsd-4.3-1' of git://linux-nfs.org/~bfields/linux:
        svcrdma: handle rdma read with a non-zero initial page offset
      38aa0a59
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 5163ac76
      Linus Torvalds authored
      Pull ARM SoC fixes from Arnd Bergmann:
       "The fixes for this week include one small patch that was years in the
        making and that finally fixes using all eight CPUs on exynos542x.
      
        The rest are lots of minor changes for sunxi, imx, exynos and shmobile
      
         - fixing the minimum voltage for Allwinner A20
         - thermal boot issue on SMDK5250.
         - invalid clock used for FIMD IOMMU.
         - audio on Renesas r8a7790/r8a7791
         - invalid clock used for FIMD IOMMU
         - LEDs on exynos5422-odroidxu3-common
         - usb pin control for imx-rex
         - imx53: fix PMIC interrupt level
         - a Makefile typo"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420
        ARM: dts: Fix bootup thermal issue on smdk5250
        ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain for sound
        ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain for sound
        arm-cci500: Don't enable PMU driver by default
        ARM: dts: fix usb pin control for imx-rex dts
        ARM: imx53: qsrb: fix PMIC interrupt level
        ARM: imx53: include IRQ dt-bindings header
        ARM: dts: add suspend opp to exynos4412
        ARM: dts: Fix LEDs on exynos5422-odroidxu3
        ARM: EXYNOS: reset Little cores when cpu is up
        ARM: dts: Fix Makefile target for sun4i-a10-itead-iteaduino-plus
        ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications
      5163ac76
    • Mike Snitzer's avatar
      dm snapshot: add new persistent store option to support overflow · b0d3cc01
      Mike Snitzer authored
      Commit 76c44f6d introduced the possibly for "Overflow" to be reported
      by the snapshot device's status.  Older userspace (e.g. lvm2) does not
      handle the "Overflow" status response.
      
      Fix this incompatibility by requiring newer userspace code, that can
      cope with "Overflow", request the persistent store with overflow support
      by using "PO" (Persistent with Overflow) for the snapshot store type.
      Reported-by: default avatarZdenek Kabelac <zkabelac@redhat.com>
      Fixes: 76c44f6d ("dm snapshot: don't invalidate on-disk image on snapshot write overflow")
      Reviewed-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      b0d3cc01