Thread (18 messages) flat view 18 messages, 3 authors, 2014-08-05
STALE4434d

Revision v3 of 8 in this series.

Revisions (8)
  1. v1 [diff vs current]
  2. v2 [diff vs current]
  3. v3 [diff vs current]
  4. v3 [diff vs current]
  5. v3 [diff vs current]
  6. v3 [diff vs current]
  7. v3 [diff vs current]
  8. v3 current

[RESEND PATCH v3 2/4] usb: musb: Bugfix of_node assignment

From: Markus Pargmann <hidden>
Date: 2014-08-04 10:13:44

Hi Sebastian,

This thread was about the of_node assignment for the child device
musb-hdrc. Mainline commit:
	4fc4b274f9b3 (usb: musb: dsps: do not bind to "musb-hdrc")

On Mon, Nov 25, 2013 at 05:48:54PM +0100, Sebastian Andrzej Siewior wrote:
Is this fixing a bug? Commit 4fc4b2 ("usb: musb: dsps: do not bind to
"musb-hdrc") [0] should fix the problem that is described here.
ux500 is affected by the same problem as dsps but it is only visible on
dsps because we DEFER probe for few reasons there test the fail path.

So by just looking at it should fix the same problem as the change I
cited _but_ it would also cover ux500. Currently I can't think of any
side effects by assigning of_node if the musb_init_*() did not do it.
If we take this in I would suggest to remove the check I added (because
it does no longer serve any purpose) and the description (why we do
this, what is the problem exactly) is could be taken from my patch
since I think it is better described (it safe to assign a node to a
driver, it becomes unsafe if after platform_probe _also_ the DT probe
is executed which was not to designed to work like this).

In the long term I would suggest to move the DT probe over to the musb
core code and we wouldn't need the node assignment anymore?

[0] http://www.spinics.net/lists/linux-usb/msg94701.html
Really old thread but I just noticed that this solution does not work
for automatically parsed properties like 'default' pinctrl. I added
'default' pinctrl settings for the musb device node. They are
automatically setup by the driver core infrastracture as expected.

The problem is that the 'default' pincontrol settings will be applied
again for the musb-hdrc because they are extracted from the of_ndoe
data. This fails because they are already claimed by the 'musb-dsps'
driver. musb-hdrc continues probing, but there is a big error message
that it failed:

[    1.181912] pinctrl-single 44e10800.pinmux: pin 44e10a20.0 already requested by 47401c00.usb; cannot clai
m for musb-hdrc.1.auto
[    1.194053] pinctrl-single 44e10800.pinmux: pin-136 (musb-hdrc.1.auto) status -22
[    1.201930] pinctrl-single 44e10800.pinmux: could not request pin 136 (44e10a20.0) from group pinmux_usb1
_pins  on device pinctrl-single
[    1.214790] musb-hdrc musb-hdrc.1.auto: Error applying setting, reverse things back

Any ideas how to solve it for mainline?

Best regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140804/ed1f3e6a/attachment.sig>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help