On Mon, May 14, 2012 at 04:28:23PM +0300, Alexander Shishkin wrote: > Felipe Balbi <balbi@xxxxxx> writes: > > > On Mon, May 14, 2012 at 04:00:28PM +0300, Alexander Shishkin wrote: > >> Felipe Balbi <balbi@xxxxxx> writes: > >> > >> > Hi, > >> > > >> > On Mon, May 14, 2012 at 12:58:24PM +0300, Alexander Shishkin wrote: > >> >> Now that the ChipIdea driver has support for role switching, describe > >> >> it in the Documentation/ABI as a "testing" interface. > >> >> > >> >> Signed-off-by: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> > >> >> --- > >> >> Documentation/ABI/testing/sysfs-driver-chipidea | 11 +++++++++++ > >> >> 1 file changed, 11 insertions(+) > >> >> create mode 100644 Documentation/ABI/testing/sysfs-driver-chipidea > >> >> > >> >> diff --git a/Documentation/ABI/testing/sysfs-driver-chipidea b/Documentation/ABI/testing/sysfs-driver-chipidea > >> >> new file mode 100644 > >> >> index 0000000..e96fb71 > >> >> --- /dev/null > >> >> +++ b/Documentation/ABI/testing/sysfs-driver-chipidea > >> >> @@ -0,0 +1,11 @@ > >> >> +What: /sys/bus/platform/drivers/ci_hdrc/role > >> >> +Date: May, 2012 > >> >> +KernelVersion: 3.5 > >> >> +Contact: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> > >> >> +Description: ChipIdea USB High-speed Dual Role Controller allows for > >> >> + manual switching of roles, which is useful on boards or > >> >> + platforms that have the ID pin fixed (like SheevaPlug). > >> >> + This file can be used for forcing the driver into one > >> >> + of the two modes, by writing "host" or "gadget" to it. > >> >> + Both these roles need to be enabled in the kernel config > >> >> + in order for this switch to work. > >> >> -- > >> >> 1.7.10 > >> > > >> > I would like to see it under debugfs. Greg, should you take this anyway > >> > considering Alexander has to move this to debugfs ?? > >> > >> I tried to provide an elaborate explanation as to why I think it belongs > >> in sysfs and not in debugfs. Let me try again: on some systems, this > >> will be the only way to switch to device mode and I don't think forcing > >> them to compile in debugfs just to have that is fair, since it's not > >> really related to debugging. What do you say? > > > > It depends on why "some systems" won't be able to change based on ID pin > > as they should. To me, that's a pretty messed up HW. Can you elaborate ? > > In the context of chipidea, I know of sheevaplug, which seems it have > its ID pin grounded (it only has type-a socket). Generally, I suspect then that board is hard-wired to host operation. You can't change that. Forcing the IP to work in device mode is a debugging feature which the board wasn't designed to support. > that some devices out there are sold with ID pin disconnected to avoid > having to go through certification with otg functionality. I don't have > any evidence of that in connection to chipidea, though. If you want to support device mode, ID pin has to be floating, the cable decides the roles. Now the trick is: if board only has micro/mini-b receptable, it's not wired to support host if board only has Standard A receptacle, it's not wired to support device if board has micro/mini-AB receptacle, it was wired to support both roles with or without the OTG additions. Now, if you want to use one of the *unsupported* modes with a particular board, that's clearly a debugging/development feature which should not get out of the lab, thus debugfs seems the right place. -- balbi
Attachment:
signature.asc
Description: Digital signature
