1. 14 Feb, 2014 5 commits
    • Peter Hurley's avatar
      tty: Fix ref counting for port krefs · c0fdfb80
      Peter Hurley authored
      The tty core supports two models for handling tty_port lifetimes;
      the tty_port can use the kref supplied by tty_port (which will
      automatically destruct the tty_port when the ref count drops to
      zero) or it can destruct the tty_port manually.
      
      For tty drivers that choose to use the port kref to manage the
      tty_port lifetime, it is not possible to safely acquire a port
      reference conditionally. If the last reference is released after
      evaluating the condition but before acquiring the reference, a
      bogus reference will be held while the tty_port destruction
      commences.
      
      Rather, only acquire a port reference if the ref count is non-zero
      and allow the caller to distinguish if a reference has successfully
      been acquired.
      
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-By: default avatarAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c0fdfb80
    • Peter Hurley's avatar
      Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()" · f87c24e7
      Peter Hurley authored
      This reverts commit e228b633.
      
      This is the third of a 3-patch revert, together with
      Revert "Bluetooth: Remove rfcomm_carrier_raised()" and
      Revert "Bluetooth: Always wait for a connection on RFCOMM open()".
      
      Commit 4a2fb3ec,
      "Bluetooth: Always wait for a connection on RFCOMM open()" open-codes
      blocking on tty open(), rather than using the default behavior
      implemented by the tty port.
      
      The reasons for reverting that patch are detailed in that changelog;
      this patch restores required functionality for that revert.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Tested-By: default avatarAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f87c24e7
    • Peter Hurley's avatar
      Revert "Bluetooth: Always wait for a connection on RFCOMM open()" · 136c373b
      Peter Hurley authored
      This reverts commit 4a2fb3ec.
      
      This is the second of a 3-patch revert, together with
      Revert "Bluetooth: Remove rfcomm_carrier_raised()" and
      Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()".
      
      Before commit cad348a1,
        Bluetooth: Implement .activate, .shutdown and .carrier_raised methods,
      tty_port_block_til_ready() was open-coded in rfcomm_tty_install() as
      part of the RFCOMM tty open().
      
      Unfortunately, it did not implement non-blocking open nor CLOCAL open,
      but rather always blocked for carrier. This is not the expected or
      typical behavior for ttys, and prevents several common terminal
      programming idioms from working (eg., opening in non-blocking
      mode to initialize desired termios settings then re-opening for
      connection).
      
      Commit cad348a1,
        Bluetooth: Implement .activate, .shutdown and .carrier_raised methods,
      added the necessary tty_port methods to use the default tty_port_open().
      However, this triggered two important user-space regressions.
      
      The first regression involves the complicated mechanism for reparenting
      the rfcomm tty device to the ACL link device which represents an
      open link to a specific bluetooth host. This regression causes ModemManager
      to conclude the rfcomm tty device does not front a modem so it makes
      no attempt to initialize an attached modem. This regression is
      caused by the lack of a device_move() if the dlc is already open (and
      not specifically related to the open-coded block_til_ready()).
      
      A more appropriate solution is submitted in
      "Bluetooth: Fix unsafe RFCOMM device parenting" and
      "Bluetooth: Fix RFCOMM parent device for reused dlc"
      
      The second regression involves "rfcomm bind" and wvdial (a ppp dialer).
      rfcomm bind creates a device node for a /dev/rfcomm<n>. wvdial opens
      that device in non-blocking mode (because it expects the connection
      to have already been established). In addition, subsequent writes
      to the rfcomm tty device fail (because the link is not yet connected;
      rfcomm connection begins with the actual tty open()).
      
      However, restoring the original behavior (in the patch which
      this reverts) was undesirable.
      
      Firstly, the original reporter notes that a trivial userspace
      "workaround" already exists: rfcomm connect, which creates the
      device node and establishes the expected connection.
      
      Secondly, the failed writes occur because the rfcomm tty driver
      does not buffer writes to an unconnected device; this contrasts with
      the dozen of other tty drivers (in fact, all of them) that do just
      that. The submitted patch "Bluetooth: Don't fail RFCOMM tty writes"
      corrects this.
      
      Thirdly, it was a long-standing bug to block on non-blocking open,
      which is re-fixed by revert.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Tested-By: default avatarAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      136c373b
    • Peter Hurley's avatar
      Revert "Bluetooth: Remove rfcomm_carrier_raised()" · 7f717b91
      Peter Hurley authored
      This reverts commit f86772af.
      
      This is the first of a 3-patch revert, together with
      Revert "Bluetooth: Always wait for a connection on RFCOMM open()" and
      Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()".
      
      Commit 4a2fb3ec,
      "Bluetooth: Always wait for a connection on RFCOMM open()" open-codes
      blocking on tty open(), rather than using the default behavior
      implemented by the tty port.
      
      The reasons for reverting that patch are detailed in that changelog;
      this patch restores required functionality for that revert.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Tested-By: default avatarAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      7f717b91
    • Johan Hedberg's avatar
      Bluetooth: Enable LE L2CAP CoC support by default · 9b7655ea
      Johan Hedberg authored
      Now that the LE L2CAP Connection Oriented Channel support has undergone a
      decent amount of testing we can make it officially supported. This patch
      removes the enable_lecoc module parameter which was previously needed to
      enable support for LE L2CAP CoC.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9b7655ea
  2. 13 Feb, 2014 35 commits