1. 09 3月, 2015 2 次提交
    • A
      gadgetfs: really get rid of switching ->f_op · 96b62a57
      Alan Stern 提交于
      ... for ep0 as well
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      96b62a57
    • A
      gadgetfs: get rid of flipping ->f_op in ep_config() · d4461a60
      Al Viro 提交于
      Final methods start with get_ready_ep(), which will fail unless we have
      ->state == STATE_EP_ENABLED.  So they'd be failing just fine until that
      first write() anyway.  Let's do the following:
      	* get_ready_ep() gets a new argument - true when called from
      ep_write_iter(), false otherwise.
      	* make it quiet when it finds STATE_EP_READY (no printk, that is;
      the case won't be impossible after that change).
      	* when that new argument is true, treat STATE_EP_READY the same
      way as STATE_EP_ENABLED (i.e. return zero and do not unlock).
      	* in ep_write_iter(), after success of get_ready_ep() turn
      	if (!usb_endpoint_dir_in(&epdata->desc)) {
      into
      	if (epdata->state == STATE_EP_ENABLED &&
      	    !usb_endpoint_dir_in(&epdata->desc)) {
      - that logics only applies after config.
      	* have ep_config() take kernel-side buffer (i.e. use memcpy()
      instead of copy_from_user() in there) and in the "let's call ep_io or
      ep_aio" (again, in ep_write_iter()) add "... or ep_config() in case it's
      not configured yet"
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d4461a60
  2. 07 3月, 2015 3 次提交
    • J
      USB: serial: fix infinite wait_until_sent timeout · f528bf4f
      Johan Hovold 提交于
      Make sure to handle an infinite timeout (0).
      
      Note that wait_until_sent is currently never called with a 0-timeout
      argument due to a bug in tty_wait_until_sent.
      
      Fixes: dcf01050 ("USB: serial: add generic wait_until_sent
      implementation")
      Cc: stable <stable@vger.kernel.org>	# v3.10
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f528bf4f
    • M
      xhci: Workaround for PME stuck issues in Intel xhci · b8cb91e0
      Mathias Nyman 提交于
      The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
      workaround for a Stuck PME that might either block PME events in suspend,
      or create spurious PME events preventing runtime suspend.
      
      Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
      PMCTRL register at offset 0x80a4, in both suspend resume callbacks
      
      Without this, xhci connected usb devices might never be able to wake up the
      system from suspend, or prevent device from going to suspend (xhci d3)
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8cb91e0
    • A
      xhci: fix reporting of 0-sized URBs in control endpoint · 45ba2154
      Aleksander Morgado 提交于
      When a control transfer has a short data stage, the xHCI controller generates
      two transfer events: a COMP_SHORT_TX event that specifies the untransferred
      amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
      COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
      urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
      urb->actual_length was set already by a previous COMP_SHORT_TX event.
      
      The driver checks this by seeing whether urb->actual_length == 0, but this alone
      is the wrong test, as it is entirely possible for a short transfer to have an
      urb->actual_length = 0.
      
      This patch changes the xhci driver to rely on a new td->urb_length_set flag,
      which is set to true when a COMP_SHORT_TX event is received and the URB length
      updated at that stage.
      
      This fixes a bug which affected the HSO plugin, which relies on URBs with
      urb->actual_length == 0 to halt re-submitting the RX URB in the control
      endpoint.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45ba2154
  3. 03 3月, 2015 1 次提交
  4. 02 3月, 2015 1 次提交
    • N
      USB: ch341: set tty baud speed according to tty struct · aa91def4
      Nicolas PLANEL 提交于
      The ch341_set_baudrate() function initialize the device baud speed
      according to the value on priv->baud_rate. By default the ch341_open() set
      it to a hardcoded value (DEFAULT_BAUD_RATE 9600). Unfortunately, the
      tty_struct is not initialized with the same default value. (usually 56700)
      
      This means that the tty_struct and the device baud rate generator are not
      synchronized after opening the port.
      
      Fixup is done by calling ch341_set_termios() if tty exist.
      Remove unnecessary variable priv->baud_rate setup as it's already done by
      ch341_port_probe().
      Remove unnecessary call to ch341_set_{handshake,baudrate}() in
      ch341_open() as there already called in ch341_configure() and
      ch341_set_termios()
      Signed-off-by: NNicolas PLANEL <nicolas.planel@enovance.com>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      aa91def4
  5. 27 2月, 2015 10 次提交
  6. 25 2月, 2015 7 次提交
  7. 23 2月, 2015 15 次提交
  8. 18 2月, 2015 1 次提交