1. 09 3月, 2015 3 次提交
    • S
      usb: isp1760: add peripheral/device controller chip id · 1998adab
      Sudeep Holla 提交于
      As per the SAF1761 data sheet[0], the DcChipID register represents
      the hardware version number (0001h) and the chip ID (1582h) for the
      Peripheral Controller.
      
      However as per the ISP1761 data sheet[1], the DcChipID register
      represents the hardware version number (0015h) and the chip ID (8210h)
      for the Peripheral Controller.
      
      This patch adds support for both the chip ID values.
      
      [0] http://www.nxp.com/documents/data_sheet/SAF1761.pdf
      [1] http://pdf.datasheetcatalog.com/datasheets2/74/742102_1.pdfAcked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1998adab
    • V
      usb: isp1760: set IRQ flags properly · 80b4a0f8
      Valentin Rothberg 提交于
      The IRQF_DISABLED is a NOOP and scheduled to be removed.  According to
      commit e58aa3d2 ("genirq: Run irq handlers with interrupts
      disabled") running IRQ handlers with interrupts enabled can cause stack
      overflows when the interrupt line of the issuing device is still active.
      
      This patch removes using this deprecated flag and additionally removes
      redundantly setting IRQF_SHARED for isp1760_udc_register().
      Signed-off-by: NValentin Rothberg <Valentin.Rothberg@lip6.fr>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      80b4a0f8
    • S
      usb: isp1760: fix possible deadlock in isp1760_udc_irq · 79852397
      Sudeep Holla 提交于
      Use spin_{un,}lock_irq{save,restore} in isp1760_udc_{start,stop} to
      prevent following potentially deadlock scenario between
      isp1760_udc_{start,stop} and isp1760_udc_irq :
      
      =================================
      [ INFO: inconsistent lock state ]
      4.0.0-rc2-00004-gf7bb2ef60173 #51 Not tainted
      ---------------------------------
      inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
      in:imklog/2118 [HC1[1]:SC0[0]:HE0:SE1] takes:
       (&(&udc->lock)->rlock){?.+...}, at: [<c0397a93>] isp1760_udc_irq+0x367/0x9dc
      {HARDIRQ-ON-W} state was registered at:
        [<c05135b3>] _raw_spin_lock+0x23/0x30
        [<c0396b87>] isp1760_udc_start+0x23/0xf8
        [<c039dc21>] udc_bind_to_driver+0x71/0xb0
        [<c039de4f>] usb_gadget_probe_driver+0x53/0x9c
        [<bf80d0df>] usb_composite_probe+0x8a/0xa4 [libcomposite]
        [<bf8311a7>] 0xbf8311a7
        [<c00088c5>] do_one_initcall+0x8d/0x17c
        [<c050b92d>] do_init_module+0x49/0x148
        [<c0087323>] load_module+0xb7f/0xbc4
        [<c0087471>] SyS_finit_module+0x51/0x74
        [<c000d8c1>] ret_fast_syscall+0x1/0x68
      irq event stamp: 4966
      hardirqs last  enabled at (4965): [<c05137df>] _raw_spin_unlock_irq+0x1f/0x24
      hardirqs last disabled at (4966): [<c00110b3>] __irq_svc+0x33/0x64
      softirqs last  enabled at (4458): [<c0023475>] __do_softirq+0x23d/0x2d0
      softirqs last disabled at (4389): [<c002380b>] irq_exit+0xef/0x15c
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&udc->lock)->rlock);
        <Interrupt>
          lock(&(&udc->lock)->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by in:imklog/2118:
       #0:  (&f->f_pos_lock){+.+.+.}, at: [<c010a101>] __fdget_pos+0x31/0x34
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      79852397
  2. 27 1月, 2015 3 次提交