linux-kernel - Re: [PATCH] Allow MUSB DSPS to use "force host" mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <528F8F62.7000801@newflow.co.uk>
Date:	Fri, 22 Nov 2013 17:07:46 +0000
From:	Mark Jackson <mpfj-list@...flow.co.uk>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC:	linux-usb@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>,
	Greg KH <gregkh@...uxfoundation.org>, jkosina@...e.cz,
	anatol.pomozov@...il.com,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	Bin Liu <binmlist@...il.com>
Subject: Re: [PATCH] Allow MUSB DSPS to use "force host" mode

On 22/11/13 17:01, Sebastian Andrzej Siewior wrote:
> On 11/22/2013 05:49 PM, Mark Jackson wrote:
>>> and the ID pin not on ground or 3.3V?
>>> What are the side effects? I remember correctly Bin wanted to avoid
>>> settings this if it could be avoided.
>>
>> Yes ... we have a host only USB port and an unconnected ID pin.
> 
> Is it too late to connect that pin?

Unfortunately, yes.

The USB portion of the CPU board has not been needed until now, and
although I did know about the unconnected pin, I also knew it could be
fixed in s/w, so I wasn't too concerned.

>> AFAIK it defaults to device mode so I can't see any devices that get
>> plugged into the USB port.
>>
>> If I tweak the s/w to "force" host mode on, then everything appears to
>> work okay.
>>
>> I guess it's more of a hardware oversight that we left the pin floating
>> but in the real world, I guess someone may want this feature to they
>> can change the usb port type ?
> 
> This is something I would prefer to avoid if possible. We have the
> dr_mode attribute in DT. Based on that one we act as a device or host.
> Now if you decide (via dr_mode) either for host or device that means we
> have to set that bit. Where I feel a little uncomfortable is when
> someone having OTG runs in hostmode and attaches a host.
> 
>>
>> Either way, I need to fix the current h/w (which can be done via s/w)
>> hence the patch.
> I've seen many projects where this pin has been forgotten and it could
> not be changed in SW and they patched the HW. Usually this is noticed
> in the early phase and a wire is just soldered and the redesign has it
> fixed. So I don't think that this is a big issue.
> Do you insists on having this change merged upstream?

No ... I didn't think it would be such an issue, so I'm happy to keep this
as a local patch if that's any better.

Mark J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/