usb: dwc: fix lockdep false positive

Os wrapper function for spinlock init causes lockdep to show this
false positive splat during boot:
[    3.789851] =============================================
[    3.796603] [ INFO: possible recursive locking detected ]
[    3.803320] 3.16.1+ #5 Not tainted
[    3.808015] ---------------------------------------------
[    3.814730] khubd/18 is trying to acquire lock:
[    3.820537]  (&(sl)->rlock){-.-...}, at: [<c0357168>] DWC_SPINLOCK_IRQSAVE+0xc/0x14
[    3.830932]
[    3.830932] but task is already holding lock:
[    3.839274]  (&(sl)->rlock){-.-...}, at: [<c0357168>] DWC_SPINLOCK_IRQSAVE+0xc/0x14
[    3.849704]
[    3.849704] other info that might help us debug this:
[    3.858826]  Possible unsafe locking scenario:
[    3.858826]
[    3.867334]        CPU0
[    3.871052]        ----
[    3.874721]   lock(&(sl)->rlock);
[    3.879302]   lock(&(sl)->rlock);
[    3.883815]
[    3.883815]  *** DEADLOCK ***
[    3.883815]
[    3.892869]  May be due to missing lock nesting notation
[    3.892869]
[    3.901736] 4 locks held by khubd/18:
[    3.906438]  #0:  (&dev->mutex){......}, at: [<c0321da8>] hub_thread+0x98/0x1000
[    3.916026]  #1:  (&port_dev->status_lock){+.+.+.}, at: [<c032234c>] hub_thread+0x63c/0x1000
[    3.926847]  #2:  (&bus->usb_address0_mutex){+.+.+.}, at: [<c031f164>] hub_port_init+0x5c/0xb24
[    3.938015]  #3:  (&(sl)->rlock){-.-...}, at: [<c0357168>] DWC_SPINLOCK_IRQSAVE+0xc/0x14
[    3.948730]
[    3.948730] stack backtrace:
[    3.955457] CPU: 0 PID: 18 Comm: khubd Not tainted 3.16.1+ #5
[    3.962541] [<c00137e4>] (unwind_backtrace) from [<c0011530>] (show_stack+0x10/0x14)
[    3.972998] [<c0011530>] (show_stack) from [<c005985c>] (__lock_acquire+0x1420/0x1ae0)
[    3.983910] [<c005985c>] (__lock_acquire) from [<c005a6c8>] (lock_acquire+0x6c/0x8c)
[    3.994908] [<c005a6c8>] (lock_acquire) from [<c04a872c>] (_raw_spin_lock_irqsave+0x50/0x64)
[    4.006756] [<c04a872c>] (_raw_spin_lock_irqsave) from [<c0357168>] (DWC_SPINLOCK_IRQSAVE+0xc/0x14)
[    4.019382] [<c0357168>] (DWC_SPINLOCK_IRQSAVE) from [<c034ba9c>] (dwc_otg_hcd_select_transactions+0x20c/0x368)
[    4.033064] [<c034ba9c>] (dwc_otg_hcd_select_transactions) from [<c034c0f8>] (dwc_otg_hcd_urb_enqueue+0x158/0x1ec)
[    4.047017] [<c034c0f8>] (dwc_otg_hcd_urb_enqueue) from [<c034d8a0>] (dwc_otg_urb_enqueue+0x1a8/0x2e0)
[    4.059889] [<c034d8a0>] (dwc_otg_urb_enqueue) from [<c03258e4>] (usb_hcd_submit_urb+0xb8/0x870)
[    4.072316] [<c03258e4>] (usb_hcd_submit_urb) from [<c03276a0>] (usb_start_wait_urb+0x44/0xbc)
[    4.084786] [<c03276a0>] (usb_start_wait_urb) from [<c03277cc>] (usb_control_msg+0xb4/0xec)
[    4.097045] [<c03277cc>] (usb_control_msg) from [<c031f528>] (hub_port_init+0x420/0xb24)
[    4.109018] [<c031f528>] (hub_port_init) from [<c0322360>] (hub_thread+0x650/0x1000)
[    4.120667] [<c0322360>] (hub_thread) from [<c003ec3c>] (kthread+0xc8/0xe4)
[    4.129668] [<c003ec3c>] (kthread) from [<c000e128>] (ret_from_fork+0x14/0x2c)

This is false positive because the lockdep uses the lock variable name
to keep track of locks. To fix this, the spin_lock_init function can't be in a
wrapper function for spinlock name to recorder correctly. I noticed similar fix
was already made for mutex debugging so used similar approach and added extra
macro to be used to spinlock allocation when spinlock debugging is on.

Signed-off-by: Kari Suvanto <karis79@gmail.com>