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 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. Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
