<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/usb/chipidea, branch linux-3.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>usb: chipidea: otg: change workqueue ci_otg as freezable</title>
<updated>2016-03-09T23:33:27+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@nxp.com</email>
</author>
<published>2016-02-24T03:05:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d01312328cd48d97f6a02e184017eb9568dd8fc6'/>
<id>d01312328cd48d97f6a02e184017eb9568dd8fc6</id>
<content type='text'>
commit d144dfea8af7108f613139623e63952ed7e69c0c upstream.

If we use USB ID pin as wakeup source, and there is a USB block
device on this USB OTG (ID) cable, the system will be deadlock
after system resume.

The root cause for this problem is: the workqueue ci_otg may try
to remove hcd before the driver resume has finished, and hcd will
disconnect the device on it, then, it will call device_release_driver,
and holds the device lock "dev-&gt;mutex", but it is never unlocked since
it waits workqueue writeback to run to flush the block information, but
the workqueue writeback is freezable, it is not thawed before driver
resume has finished.

When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it
tries to get its device lock "dev-&gt;mutex", but it can't get it forever,
then the deadlock occurs. Below call stacks show the situation.

So, in order to fix this problem, we need to change workqueue ci_otg
as freezable, then the work item in this workqueue will be run after
driver's resume, this workqueue will not be blocked forever like above
case since the workqueue writeback has been thawed too.

Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb.

[  555.178869] kworker/u2:13   D c07de74c     0   826      2 0x00000000
[  555.185310] Workqueue: ci_otg ci_otg_work
[  555.189353] Backtrace:
[  555.191849] [&lt;c07de4fc&gt;] (__schedule) from [&lt;c07dec6c&gt;] (schedule+0x48/0xa0)
[  555.198912]  r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4
[  555.206867]  r4:ee470000
[  555.209453] [&lt;c07dec24&gt;] (schedule) from [&lt;c07e2fc4&gt;] (schedule_timeout+0x15c/0x1e0)
[  555.217212]  r4:7fffffff r3:edc2b000
[  555.220862] [&lt;c07e2e68&gt;] (schedule_timeout) from [&lt;c07df6c8&gt;] (wait_for_common+0x94/0x144)
[  555.229140]  r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff
[  555.235980] [&lt;c07df634&gt;] (wait_for_common) from [&lt;c07df790&gt;] (wait_for_completion+0x18/0x1c)
[  555.244430]  r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00
[  555.252383]  r4:00000000
[  555.254970] [&lt;c07df778&gt;] (wait_for_completion) from [&lt;c0043cb8&gt;] (flush_work+0x19c/0x234)
[  555.263177] [&lt;c0043b1c&gt;] (flush_work) from [&lt;c0043fac&gt;] (flush_delayed_work+0x48/0x4c)
[  555.271106]  r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c
[  555.277958] [&lt;c0043f64&gt;] (flush_delayed_work) from [&lt;c00eae18&gt;] (bdi_unregister+0x84/0xec)
[  555.286236]  r4:eea43520 r3:20000153
[  555.289885] [&lt;c00ead94&gt;] (bdi_unregister) from [&lt;c02c2154&gt;] (blk_cleanup_queue+0x180/0x29c)
[  555.298250]  r5:eea43808 r4:eea43400
[  555.301909] [&lt;c02c1fd4&gt;] (blk_cleanup_queue) from [&lt;c0417914&gt;] (__scsi_remove_device+0x48/0xb8)
[  555.310623]  r7:00000000 r6:20000153 r5:ededa950 r4:ededa800
[  555.316403] [&lt;c04178cc&gt;] (__scsi_remove_device) from [&lt;c0415e90&gt;] (scsi_forget_host+0x64/0x68)
[  555.325028]  r5:ededa800 r4:ed5b5000
[  555.328689] [&lt;c0415e2c&gt;] (scsi_forget_host) from [&lt;c0409828&gt;] (scsi_remove_host+0x78/0x104)
[  555.337054]  r5:ed5b5068 r4:ed5b5000
[  555.340709] [&lt;c04097b0&gt;] (scsi_remove_host) from [&lt;c04cdfcc&gt;] (usb_stor_disconnect+0x50/0xb4)
[  555.349247]  r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008
[  555.355025] [&lt;c04cdf7c&gt;] (usb_stor_disconnect) from [&lt;c04b3bc8&gt;] (usb_unbind_interface+0x78/0x25c)
[  555.363997]  r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c
[  555.371892] [&lt;c04b3b50&gt;] (usb_unbind_interface) from [&lt;c03dc248&gt;] (__device_release_driver+0x8c/0x118)
[  555.381213]  r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c
[  555.389167]  r4:edd3c020
[  555.391752] [&lt;c03dc1bc&gt;] (__device_release_driver) from [&lt;c03dc2fc&gt;] (device_release_driver+0x28/0x34)
[  555.401071]  r5:edd3c020 r4:edd3c054
[  555.404721] [&lt;c03dc2d4&gt;] (device_release_driver) from [&lt;c03db304&gt;] (bus_remove_device+0xe0/0x110)
[  555.413607]  r5:edd3c020 r4:ef17f04c
[  555.417253] [&lt;c03db224&gt;] (bus_remove_device) from [&lt;c03d8128&gt;] (device_del+0x114/0x21c)
[  555.425270]  r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000
[  555.431045] [&lt;c03d8014&gt;] (device_del) from [&lt;c04b1560&gt;] (usb_disable_device+0xa4/0x1e8)
[  555.439061]  r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00
[  555.445906] [&lt;c04b14bc&gt;] (usb_disable_device) from [&lt;c04a8e54&gt;] (usb_disconnect+0x74/0x224)
[  555.454271]  r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001
[  555.462156] [&lt;c04a8de0&gt;] (usb_disconnect) from [&lt;c04a8fb8&gt;] (usb_disconnect+0x1d8/0x224)
[  555.470259]  r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400
[  555.478213]  r4:00000001
[  555.480797] [&lt;c04a8de0&gt;] (usb_disconnect) from [&lt;c04ae5ec&gt;] (usb_remove_hcd+0xa0/0x1ac)
[  555.488813]  r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0
[  555.496765]  r4:eded8000
[  555.499351] [&lt;c04ae54c&gt;] (usb_remove_hcd) from [&lt;c04d4158&gt;] (host_stop+0x28/0x64)
[  555.506847]  r6:eeb50010 r5:eded8000 r4:eeb51010
[  555.511563] [&lt;c04d4130&gt;] (host_stop) from [&lt;c04d09b8&gt;] (ci_otg_work+0xc4/0x124)
[  555.518885]  r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130
[  555.524665] [&lt;c04d08f4&gt;] (ci_otg_work) from [&lt;c00454f0&gt;] (process_one_work+0x194/0x420)
[  555.532682]  r6:ef086000 r5:eeb502a0 r4:edc44480
[  555.537393] [&lt;c004535c&gt;] (process_one_work) from [&lt;c00457b0&gt;] (worker_thread+0x34/0x514)
[  555.545496]  r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498
[  555.553450]  r4:ef086000
[  555.556032] [&lt;c004577c&gt;] (worker_thread) from [&lt;c004bab4&gt;] (kthread+0xdc/0xf8)
[  555.563268]  r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0
[  555.571221]  r4:00000000
[  555.573804] [&lt;c004b9d8&gt;] (kthread) from [&lt;c000fef0&gt;] (ret_from_fork+0x14/0x24)
[  555.581040]  r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0

[  553.429383] sh              D c07de74c     0   694    691 0x00000000
[  553.435801] Backtrace:
[  553.438295] [&lt;c07de4fc&gt;] (__schedule) from [&lt;c07dec6c&gt;] (schedule+0x48/0xa0)
[  553.445358]  r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153
[  553.453313]  r4:eddda000
[  553.455896] [&lt;c07dec24&gt;] (schedule) from [&lt;c07deff8&gt;] (schedule_preempt_disabled+0x10/0x14)
[  553.464261]  r4:edd3c058 r3:0000000a
[  553.467910] [&lt;c07defe8&gt;] (schedule_preempt_disabled) from [&lt;c07e0bbc&gt;] (mutex_lock_nested+0x1a0/0x3e8)
[  553.477254] [&lt;c07e0a1c&gt;] (mutex_lock_nested) from [&lt;c03e927c&gt;] (dpm_complete+0xc0/0x1b0)
[  553.485358]  r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020
[  553.493313]  r4:edd3c0d0
[  553.495896] [&lt;c03e91bc&gt;] (dpm_complete) from [&lt;c03e9388&gt;] (dpm_resume_end+0x1c/0x20)
[  553.503652]  r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010
[  553.511544] [&lt;c03e936c&gt;] (dpm_resume_end) from [&lt;c0079894&gt;] (suspend_devices_and_enter+0x158/0x504)
[  553.520604]  r4:00000000 r3:c1334efc
[  553.524250] [&lt;c007973c&gt;] (suspend_devices_and_enter) from [&lt;c0079e74&gt;] (pm_suspend+0x234/0x2cc)
[  553.532961]  r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8
[  553.540914]  r4:00000003
[  553.543493] [&lt;c0079c40&gt;] (pm_suspend) from [&lt;c0078a6c&gt;] (state_store+0x6c/0xc0)

[  555.703684] 7 locks held by kworker/u2:13/826:
[  555.708140]  #0:  ("%s""ci_otg"){++++.+}, at: [&lt;c0045484&gt;] process_one_work+0x128/0x420
[  555.716277]  #1:  ((&amp;ci-&gt;work)){+.+.+.}, at: [&lt;c0045484&gt;] process_one_work+0x128/0x420
[  555.724317]  #2:  (usb_bus_list_lock){+.+.+.}, at: [&lt;c04ae5e4&gt;] usb_remove_hcd+0x98/0x1ac
[  555.732626]  #3:  (&amp;dev-&gt;mutex){......}, at: [&lt;c04a8e28&gt;] usb_disconnect+0x48/0x224
[  555.740403]  #4:  (&amp;dev-&gt;mutex){......}, at: [&lt;c04a8e28&gt;] usb_disconnect+0x48/0x224
[  555.748179]  #5:  (&amp;dev-&gt;mutex){......}, at: [&lt;c03dc2f4&gt;] device_release_driver+0x20/0x34
[  555.756487]  #6:  (&amp;shost-&gt;scan_mutex){+.+.+.}, at: [&lt;c04097d0&gt;] scsi_remove_host+0x20/0x104

Cc: Jun Li &lt;jun.li@nxp.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d144dfea8af7108f613139623e63952ed7e69c0c upstream.

If we use USB ID pin as wakeup source, and there is a USB block
device on this USB OTG (ID) cable, the system will be deadlock
after system resume.

The root cause for this problem is: the workqueue ci_otg may try
to remove hcd before the driver resume has finished, and hcd will
disconnect the device on it, then, it will call device_release_driver,
and holds the device lock "dev-&gt;mutex", but it is never unlocked since
it waits workqueue writeback to run to flush the block information, but
the workqueue writeback is freezable, it is not thawed before driver
resume has finished.

When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it
tries to get its device lock "dev-&gt;mutex", but it can't get it forever,
then the deadlock occurs. Below call stacks show the situation.

So, in order to fix this problem, we need to change workqueue ci_otg
as freezable, then the work item in this workqueue will be run after
driver's resume, this workqueue will not be blocked forever like above
case since the workqueue writeback has been thawed too.

Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb.

[  555.178869] kworker/u2:13   D c07de74c     0   826      2 0x00000000
[  555.185310] Workqueue: ci_otg ci_otg_work
[  555.189353] Backtrace:
[  555.191849] [&lt;c07de4fc&gt;] (__schedule) from [&lt;c07dec6c&gt;] (schedule+0x48/0xa0)
[  555.198912]  r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4
[  555.206867]  r4:ee470000
[  555.209453] [&lt;c07dec24&gt;] (schedule) from [&lt;c07e2fc4&gt;] (schedule_timeout+0x15c/0x1e0)
[  555.217212]  r4:7fffffff r3:edc2b000
[  555.220862] [&lt;c07e2e68&gt;] (schedule_timeout) from [&lt;c07df6c8&gt;] (wait_for_common+0x94/0x144)
[  555.229140]  r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff
[  555.235980] [&lt;c07df634&gt;] (wait_for_common) from [&lt;c07df790&gt;] (wait_for_completion+0x18/0x1c)
[  555.244430]  r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00
[  555.252383]  r4:00000000
[  555.254970] [&lt;c07df778&gt;] (wait_for_completion) from [&lt;c0043cb8&gt;] (flush_work+0x19c/0x234)
[  555.263177] [&lt;c0043b1c&gt;] (flush_work) from [&lt;c0043fac&gt;] (flush_delayed_work+0x48/0x4c)
[  555.271106]  r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c
[  555.277958] [&lt;c0043f64&gt;] (flush_delayed_work) from [&lt;c00eae18&gt;] (bdi_unregister+0x84/0xec)
[  555.286236]  r4:eea43520 r3:20000153
[  555.289885] [&lt;c00ead94&gt;] (bdi_unregister) from [&lt;c02c2154&gt;] (blk_cleanup_queue+0x180/0x29c)
[  555.298250]  r5:eea43808 r4:eea43400
[  555.301909] [&lt;c02c1fd4&gt;] (blk_cleanup_queue) from [&lt;c0417914&gt;] (__scsi_remove_device+0x48/0xb8)
[  555.310623]  r7:00000000 r6:20000153 r5:ededa950 r4:ededa800
[  555.316403] [&lt;c04178cc&gt;] (__scsi_remove_device) from [&lt;c0415e90&gt;] (scsi_forget_host+0x64/0x68)
[  555.325028]  r5:ededa800 r4:ed5b5000
[  555.328689] [&lt;c0415e2c&gt;] (scsi_forget_host) from [&lt;c0409828&gt;] (scsi_remove_host+0x78/0x104)
[  555.337054]  r5:ed5b5068 r4:ed5b5000
[  555.340709] [&lt;c04097b0&gt;] (scsi_remove_host) from [&lt;c04cdfcc&gt;] (usb_stor_disconnect+0x50/0xb4)
[  555.349247]  r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008
[  555.355025] [&lt;c04cdf7c&gt;] (usb_stor_disconnect) from [&lt;c04b3bc8&gt;] (usb_unbind_interface+0x78/0x25c)
[  555.363997]  r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c
[  555.371892] [&lt;c04b3b50&gt;] (usb_unbind_interface) from [&lt;c03dc248&gt;] (__device_release_driver+0x8c/0x118)
[  555.381213]  r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c
[  555.389167]  r4:edd3c020
[  555.391752] [&lt;c03dc1bc&gt;] (__device_release_driver) from [&lt;c03dc2fc&gt;] (device_release_driver+0x28/0x34)
[  555.401071]  r5:edd3c020 r4:edd3c054
[  555.404721] [&lt;c03dc2d4&gt;] (device_release_driver) from [&lt;c03db304&gt;] (bus_remove_device+0xe0/0x110)
[  555.413607]  r5:edd3c020 r4:ef17f04c
[  555.417253] [&lt;c03db224&gt;] (bus_remove_device) from [&lt;c03d8128&gt;] (device_del+0x114/0x21c)
[  555.425270]  r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000
[  555.431045] [&lt;c03d8014&gt;] (device_del) from [&lt;c04b1560&gt;] (usb_disable_device+0xa4/0x1e8)
[  555.439061]  r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00
[  555.445906] [&lt;c04b14bc&gt;] (usb_disable_device) from [&lt;c04a8e54&gt;] (usb_disconnect+0x74/0x224)
[  555.454271]  r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001
[  555.462156] [&lt;c04a8de0&gt;] (usb_disconnect) from [&lt;c04a8fb8&gt;] (usb_disconnect+0x1d8/0x224)
[  555.470259]  r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400
[  555.478213]  r4:00000001
[  555.480797] [&lt;c04a8de0&gt;] (usb_disconnect) from [&lt;c04ae5ec&gt;] (usb_remove_hcd+0xa0/0x1ac)
[  555.488813]  r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0
[  555.496765]  r4:eded8000
[  555.499351] [&lt;c04ae54c&gt;] (usb_remove_hcd) from [&lt;c04d4158&gt;] (host_stop+0x28/0x64)
[  555.506847]  r6:eeb50010 r5:eded8000 r4:eeb51010
[  555.511563] [&lt;c04d4130&gt;] (host_stop) from [&lt;c04d09b8&gt;] (ci_otg_work+0xc4/0x124)
[  555.518885]  r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130
[  555.524665] [&lt;c04d08f4&gt;] (ci_otg_work) from [&lt;c00454f0&gt;] (process_one_work+0x194/0x420)
[  555.532682]  r6:ef086000 r5:eeb502a0 r4:edc44480
[  555.537393] [&lt;c004535c&gt;] (process_one_work) from [&lt;c00457b0&gt;] (worker_thread+0x34/0x514)
[  555.545496]  r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498
[  555.553450]  r4:ef086000
[  555.556032] [&lt;c004577c&gt;] (worker_thread) from [&lt;c004bab4&gt;] (kthread+0xdc/0xf8)
[  555.563268]  r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0
[  555.571221]  r4:00000000
[  555.573804] [&lt;c004b9d8&gt;] (kthread) from [&lt;c000fef0&gt;] (ret_from_fork+0x14/0x24)
[  555.581040]  r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0

[  553.429383] sh              D c07de74c     0   694    691 0x00000000
[  553.435801] Backtrace:
[  553.438295] [&lt;c07de4fc&gt;] (__schedule) from [&lt;c07dec6c&gt;] (schedule+0x48/0xa0)
[  553.445358]  r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153
[  553.453313]  r4:eddda000
[  553.455896] [&lt;c07dec24&gt;] (schedule) from [&lt;c07deff8&gt;] (schedule_preempt_disabled+0x10/0x14)
[  553.464261]  r4:edd3c058 r3:0000000a
[  553.467910] [&lt;c07defe8&gt;] (schedule_preempt_disabled) from [&lt;c07e0bbc&gt;] (mutex_lock_nested+0x1a0/0x3e8)
[  553.477254] [&lt;c07e0a1c&gt;] (mutex_lock_nested) from [&lt;c03e927c&gt;] (dpm_complete+0xc0/0x1b0)
[  553.485358]  r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020
[  553.493313]  r4:edd3c0d0
[  553.495896] [&lt;c03e91bc&gt;] (dpm_complete) from [&lt;c03e9388&gt;] (dpm_resume_end+0x1c/0x20)
[  553.503652]  r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010
[  553.511544] [&lt;c03e936c&gt;] (dpm_resume_end) from [&lt;c0079894&gt;] (suspend_devices_and_enter+0x158/0x504)
[  553.520604]  r4:00000000 r3:c1334efc
[  553.524250] [&lt;c007973c&gt;] (suspend_devices_and_enter) from [&lt;c0079e74&gt;] (pm_suspend+0x234/0x2cc)
[  553.532961]  r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8
[  553.540914]  r4:00000003
[  553.543493] [&lt;c0079c40&gt;] (pm_suspend) from [&lt;c0078a6c&gt;] (state_store+0x6c/0xc0)

[  555.703684] 7 locks held by kworker/u2:13/826:
[  555.708140]  #0:  ("%s""ci_otg"){++++.+}, at: [&lt;c0045484&gt;] process_one_work+0x128/0x420
[  555.716277]  #1:  ((&amp;ci-&gt;work)){+.+.+.}, at: [&lt;c0045484&gt;] process_one_work+0x128/0x420
[  555.724317]  #2:  (usb_bus_list_lock){+.+.+.}, at: [&lt;c04ae5e4&gt;] usb_remove_hcd+0x98/0x1ac
[  555.732626]  #3:  (&amp;dev-&gt;mutex){......}, at: [&lt;c04a8e28&gt;] usb_disconnect+0x48/0x224
[  555.740403]  #4:  (&amp;dev-&gt;mutex){......}, at: [&lt;c04a8e28&gt;] usb_disconnect+0x48/0x224
[  555.748179]  #5:  (&amp;dev-&gt;mutex){......}, at: [&lt;c03dc2f4&gt;] device_release_driver+0x20/0x34
[  555.756487]  #6:  (&amp;shost-&gt;scan_mutex){+.+.+.}, at: [&lt;c04097d0&gt;] scsi_remove_host+0x20/0x104

Cc: Jun Li &lt;jun.li@nxp.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: msm: Initialize PHY on reset event</title>
<updated>2014-10-05T21:52:14+00:00</updated>
<author>
<name>Ivan T. Ivanov</name>
<email>iivanov@mm-sol.com</email>
</author>
<published>2014-09-11T00:19:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ed487b7fb054a5adcbbf2d38d97b9fc0237489e1'/>
<id>ed487b7fb054a5adcbbf2d38d97b9fc0237489e1</id>
<content type='text'>
commit 233c7daf4eecd1e992dc42591182cd4a892e687c upstream.

Initialize USB PHY after every Link controller reset

Cc: Tim Bird &lt;tbird20d@gmail.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Ivan T. Ivanov &lt;iivanov@mm-sol.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 233c7daf4eecd1e992dc42591182cd4a892e687c upstream.

Initialize USB PHY after every Link controller reset

Cc: Tim Bird &lt;tbird20d@gmail.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Ivan T. Ivanov &lt;iivanov@mm-sol.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: msm: Use USB PHY API to control PHY state</title>
<updated>2014-10-05T21:52:14+00:00</updated>
<author>
<name>Ivan T. Ivanov</name>
<email>iivanov@mm-sol.com</email>
</author>
<published>2014-09-11T00:18:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9703d02767a7ecf5960f7fe6c65acc18b13abfc6'/>
<id>9703d02767a7ecf5960f7fe6c65acc18b13abfc6</id>
<content type='text'>
commit ea290056d7c46f7781ff13801048ed957b96d1a5 upstream.

PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.

Cc: Tim Bird &lt;tbird20d@gmail.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Ivan T. Ivanov &lt;iivanov@mm-sol.com&gt;
Acked-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ea290056d7c46f7781ff13801048ed957b96d1a5 upstream.

PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.

Cc: Tim Bird &lt;tbird20d@gmail.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Ivan T. Ivanov &lt;iivanov@mm-sol.com&gt;
Acked-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: udc: Disable auto ZLP generation on ep0</title>
<updated>2014-07-28T15:05:56+00:00</updated>
<author>
<name>Abbas Raza</name>
<email>Abbas_Raza@mentor.com</email>
</author>
<published>2014-07-17T11:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3b5e2408ca94673c8b1d61d388ca67d282c12fd1'/>
<id>3b5e2408ca94673c8b1d61d388ca67d282c12fd1</id>
<content type='text'>
commit 953c66469735aed8d2ada639a72b150f01dae605 upstream.

There are 2 methods for ZLP (zero-length packet) generation:
1) In software
2) Automatic generation by device controller

1) is implemented in UDC driver and it attaches ZLP to IN packet if
   descriptor-&gt;size &lt; wLength
2) can be enabled/disabled by setting ZLT bit in the QH

When gadget ffs is connected to ubuntu host, the host sends
get descriptor request and wLength in setup packet is 255 while the
size of descriptor which will be sent by gadget in IN packet is
64 byte. So the composite driver sets req-&gt;zero = 1.
In UDC driver following code will be executed then

        if (hwreq-&gt;req.zero &amp;&amp; hwreq-&gt;req.length
            &amp;&amp; (hwreq-&gt;req.length % hwep-&gt;ep.maxpacket == 0))
                add_td_to_list(hwep, hwreq, 0);

Case-A:
So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
ubuntu host will request 255 byte in IN request, gadget will send 64 byte
with ZLP and host will come to know that there is no more data.
But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
automatically generate the ZLP which blocks enumeration for ~6 seconds due
to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)

Case-B:
In case when gadget ffs is connected to Apple device, Apple device sends
setup packet with wLength=64. So descriptor-&gt;size = 64 and wLength=64
therefore req-&gt;zero = 0 and UDC driver will not attach any ZLP to the
IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
further request for IN data. But ZLT=0 by default for endpoint 0 so
hardware tries to automatically generate the ZLP which blocks enumeration
for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
requests (OUT/PING)

According to USB2.0 specs:

    8.5.3.2 Variable-length Data Stage
    A control pipe may have a variable-length data phase in which the
    host requests more data than is contained in the specified data
    structure. When all of the data structure is returned to the host,
    the function should indicate that the Data stage is ended by
    returning a packet that is shorter than the MaxPacketSize for the
    pipe. If the data structure is an exact multiple of wMaxPacketSize
    for the pipe, the function will return a zero-length packet to indicate
    the end of the Data stage.

In Case-A mentioned above:
If we disable software ZLP generation &amp; ZLT=0 for endpoint 0 OR if software
ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
enumeration doesn't block for 6 seconds.

In Case-B mentioned above:
If we disable software ZLP generation &amp; ZLT=0 for endpoint then enumeration
still blocks due to ZLP automatically generated by hardware and host not needing
it. But if we keep software ZLP generation enabled but we set ZLT=1 for
endpoint 0 then enumeration doesn't block for 6 seconds.

So the proper solution for this issue seems to disable automatic ZLP generation
by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
handle the ZLP generation based on req-&gt;zero field.

Signed-off-by: Abbas Raza &lt;Abbas_Raza@mentor.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 953c66469735aed8d2ada639a72b150f01dae605 upstream.

There are 2 methods for ZLP (zero-length packet) generation:
1) In software
2) Automatic generation by device controller

1) is implemented in UDC driver and it attaches ZLP to IN packet if
   descriptor-&gt;size &lt; wLength
2) can be enabled/disabled by setting ZLT bit in the QH

When gadget ffs is connected to ubuntu host, the host sends
get descriptor request and wLength in setup packet is 255 while the
size of descriptor which will be sent by gadget in IN packet is
64 byte. So the composite driver sets req-&gt;zero = 1.
In UDC driver following code will be executed then

        if (hwreq-&gt;req.zero &amp;&amp; hwreq-&gt;req.length
            &amp;&amp; (hwreq-&gt;req.length % hwep-&gt;ep.maxpacket == 0))
                add_td_to_list(hwep, hwreq, 0);

Case-A:
So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
ubuntu host will request 255 byte in IN request, gadget will send 64 byte
with ZLP and host will come to know that there is no more data.
But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
automatically generate the ZLP which blocks enumeration for ~6 seconds due
to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)

Case-B:
In case when gadget ffs is connected to Apple device, Apple device sends
setup packet with wLength=64. So descriptor-&gt;size = 64 and wLength=64
therefore req-&gt;zero = 0 and UDC driver will not attach any ZLP to the
IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
further request for IN data. But ZLT=0 by default for endpoint 0 so
hardware tries to automatically generate the ZLP which blocks enumeration
for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
requests (OUT/PING)

According to USB2.0 specs:

    8.5.3.2 Variable-length Data Stage
    A control pipe may have a variable-length data phase in which the
    host requests more data than is contained in the specified data
    structure. When all of the data structure is returned to the host,
    the function should indicate that the Data stage is ended by
    returning a packet that is shorter than the MaxPacketSize for the
    pipe. If the data structure is an exact multiple of wMaxPacketSize
    for the pipe, the function will return a zero-length packet to indicate
    the end of the Data stage.

In Case-A mentioned above:
If we disable software ZLP generation &amp; ZLT=0 for endpoint 0 OR if software
ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
enumeration doesn't block for 6 seconds.

In Case-B mentioned above:
If we disable software ZLP generation &amp; ZLT=0 for endpoint then enumeration
still blocks due to ZLP automatically generated by hardware and host not needing
it. But if we keep software ZLP generation enabled but we set ZLT=1 for
endpoint 0 then enumeration doesn't block for 6 seconds.

So the proper solution for this issue seems to disable automatic ZLP generation
by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
handle the ZLP generation based on req-&gt;zero field.

Signed-off-by: Abbas Raza &lt;Abbas_Raza@mentor.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: udc: delete td from req's td list at ep_dequeue</title>
<updated>2014-07-09T18:18:24+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@freescale.com</email>
</author>
<published>2014-07-02T04:16:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0d845a46caab134b9ffc05e86d1acacdde353c34'/>
<id>0d845a46caab134b9ffc05e86d1acacdde353c34</id>
<content type='text'>
commit e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a upstream.

We need to delete un-finished td from current request's td list
at ep_dequeue API, otherwise, this non-user td will be remained
at td list before this request is freed. So if we do ep_queue-&gt;
ep_dequeue-&gt;ep_queue sequence, when the complete interrupt for
the second ep_queue comes, we search td list for this request,
the first td (added by the first ep_queue) will be handled, and
its status is still active, so we will consider the this transfer
still not be completed, but in fact, it has completed. It causes
the peripheral side considers it never receives current data for
this transfer.

We met this problem when do "Error Recovery Test - Device Configured"
test item for USBCV2 MSC test, the host has never received ACK for
the IN token for CSW due to peripheral considers it does not get this
CBW, the USBCV test log like belows:

--------------------------------------------------------------------------
INFO
Issuing BOT MSC Reset, reset should always succeed
INFO
Retrieving status on CBW endpoint
INFO
CBW endpoint status = 0x0
INFO
Retrieving status on CSW endpoint
INFO
CSW endpoint status = 0x0
INFO
Issuing required command (Test Unit Ready) to verify device has recovered
INFO
Issuing CBW (attempt #1):
INFO
|----- CBW LUN                  = 0x0
INFO
|----- CBW Flags                = 0x0
INFO
|----- CBW Data Transfer Length = 0x0
INFO
|----- CBW CDB Length           = 0x6
INFO
|----- CBW CDB-00 = 0x0
INFO
|----- CBW CDB-01 = 0x0
INFO
|----- CBW CDB-02 = 0x0
INFO
|----- CBW CDB-03 = 0x0
INFO
|----- CBW CDB-04 = 0x0
INFO
|----- CBW CDB-05 = 0x0
INFO
Issuing CSW : try 1
INFO
CSW Bulk Request timed out!
ERROR
Failed CSW phase : should have been success or stall
FAIL
(5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
ERROR
BOTCommonMSCRequest failed:  error=80004000

Cc: Andrzej Pietrasiewicz &lt;andrzej.p@samsung.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a upstream.

We need to delete un-finished td from current request's td list
at ep_dequeue API, otherwise, this non-user td will be remained
at td list before this request is freed. So if we do ep_queue-&gt;
ep_dequeue-&gt;ep_queue sequence, when the complete interrupt for
the second ep_queue comes, we search td list for this request,
the first td (added by the first ep_queue) will be handled, and
its status is still active, so we will consider the this transfer
still not be completed, but in fact, it has completed. It causes
the peripheral side considers it never receives current data for
this transfer.

We met this problem when do "Error Recovery Test - Device Configured"
test item for USBCV2 MSC test, the host has never received ACK for
the IN token for CSW due to peripheral considers it does not get this
CBW, the USBCV test log like belows:

--------------------------------------------------------------------------
INFO
Issuing BOT MSC Reset, reset should always succeed
INFO
Retrieving status on CBW endpoint
INFO
CBW endpoint status = 0x0
INFO
Retrieving status on CSW endpoint
INFO
CSW endpoint status = 0x0
INFO
Issuing required command (Test Unit Ready) to verify device has recovered
INFO
Issuing CBW (attempt #1):
INFO
|----- CBW LUN                  = 0x0
INFO
|----- CBW Flags                = 0x0
INFO
|----- CBW Data Transfer Length = 0x0
INFO
|----- CBW CDB Length           = 0x6
INFO
|----- CBW CDB-00 = 0x0
INFO
|----- CBW CDB-01 = 0x0
INFO
|----- CBW CDB-02 = 0x0
INFO
|----- CBW CDB-03 = 0x0
INFO
|----- CBW CDB-04 = 0x0
INFO
|----- CBW CDB-05 = 0x0
INFO
Issuing CSW : try 1
INFO
CSW Bulk Request timed out!
ERROR
Failed CSW phase : should have been success or stall
FAIL
(5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
ERROR
BOTCommonMSCRequest failed:  error=80004000

Cc: Andrzej Pietrasiewicz &lt;andrzej.p@samsung.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: need to mask when writting endptflush and endptprime</title>
<updated>2014-02-21T20:34:45+00:00</updated>
<author>
<name>Matthieu CASTET</name>
<email>matthieu.castet@parrot.com</email>
</author>
<published>2014-02-19T05:46:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5bf5dbeda2454296f1984adfbfc8e6f5965ac389'/>
<id>5bf5dbeda2454296f1984adfbfc8e6f5965ac389</id>
<content type='text'>
ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.

Cc: stable &lt;stable@vger.kernel.org&gt; # 3.11+
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Matthieu CASTET &lt;matthieu.castet@parrot.com&gt;
Tested-by: Michael Grzeschik &lt;mgrzeschik@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.

Cc: stable &lt;stable@vger.kernel.org&gt; # 3.11+
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Matthieu CASTET &lt;matthieu.castet@parrot.com&gt;
Tested-by: Michael Grzeschik &lt;mgrzeschik@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX</title>
<updated>2014-01-13T23:55:19+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@freescale.com</email>
</author>
<published>2014-01-10T05:51:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a'/>
<id>2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a</id>
<content type='text'>
We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is "Transaction Error".

The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.

We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).

Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.

For stable tree: 3.11+.

Cc: stable &lt;stable@vger.kernel.org&gt;
Cc: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Reported-by: Matthieu Vanin &lt;b47495@freescale.com&gt;
Tested-by: Matthieu Vanin &lt;b47495@freescale.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is "Transaction Error".

The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.

We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).

Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.

For stable tree: 3.11+.

Cc: stable &lt;stable@vger.kernel.org&gt;
Cc: Michael Grzeschik &lt;m.grzeschik@pengutronix.de&gt;
Reported-by: Matthieu Vanin &lt;b47495@freescale.com&gt;
Tested-by: Matthieu Vanin &lt;b47495@freescale.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: need to mask INT_STATUS when write otgsc</title>
<updated>2014-01-13T23:55:19+00:00</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@freescale.com</email>
</author>
<published>2014-01-10T05:51:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5332ff1fb63c46588656e4208201bc131627c878'/>
<id>5332ff1fb63c46588656e4208201bc131627c878</id>
<content type='text'>
For otgsc, both enable bits and status bits are in it. So we need
to make sure the status bits are not be cleared when write enable
bits. It can fix one bug that we plug in/out Micro AB cable fast,
and sometimes, the IDIS will be cleared wrongly when handle last
ID interrupt (ID 0-&gt;1), so the current interrupt will not occur.

For stable tree: 3.12+

Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For otgsc, both enable bits and status bits are in it. So we need
to make sure the status bits are not be cleared when write enable
bits. It can fix one bug that we plug in/out Micro AB cable fast,
and sometimes, the IDIS will be cleared wrongly when handle last
ID interrupt (ID 0-&gt;1), so the current interrupt will not occur.

For stable tree: 3.12+

Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: put hw_phymode_configure before ci_usb_phy_init</title>
<updated>2014-01-13T23:55:19+00:00</updated>
<author>
<name>Chris Ruehl</name>
<email>chris.ruehl@gtsys.com.hk</email>
</author>
<published>2014-01-10T05:51:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cd0b42c2a6d2a74244f0053f8960f5dad5842278'/>
<id>cd0b42c2a6d2a74244f0053f8960f5dad5842278</id>
<content type='text'>
hw_phymode_configure configures the PORTSC registers and allow the
following phy_inits to operate on the right parameters. This fix a problem
where the UPLI (ISP1504) could not be detected, because the Viewport was not
available and read the viewport return 0's only.

Signed-off-by: Chris Ruehl &lt;chris.ruehl@gtsys.com.hk&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
hw_phymode_configure configures the PORTSC registers and allow the
following phy_inits to operate on the right parameters. This fix a problem
where the UPLI (ISP1504) could not be detected, because the Viewport was not
available and read the viewport return 0's only.

Signed-off-by: Chris Ruehl &lt;chris.ruehl@gtsys.com.hk&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag</title>
<updated>2014-01-13T23:55:19+00:00</updated>
<author>
<name>Chris Ruehl</name>
<email>chris.ruehl@gtsys.com.hk</email>
</author>
<published>2014-01-10T05:51:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3b5d3e6845bfe68777d069886b0d1cd5f23b9d58'/>
<id>3b5d3e6845bfe68777d069886b0d1cd5f23b9d58</id>
<content type='text'>
* init the sts flag to 0 (missed)
* fix write the real bit not sts value
* Set PORTCS_STS and DEVLC_STS only if sts = 1

[Peter Chen: This one and the next patch fix the problem occurred imx27
and imx31, and imx27 and imx31 usb support are enabled until 3.14, so
these two patches isn't needed for -stable]

Signed-off-by: Chris Ruehl &lt;chris.ruehl@gtsys.com.hk&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* init the sts flag to 0 (missed)
* fix write the real bit not sts value
* Set PORTCS_STS and DEVLC_STS only if sts = 1

[Peter Chen: This one and the next patch fix the problem occurred imx27
and imx31, and imx27 and imx31 usb support are enabled until 3.14, so
these two patches isn't needed for -stable]

Signed-off-by: Chris Ruehl &lt;chris.ruehl@gtsys.com.hk&gt;
Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
