linux-kernel - Re: [PATCH] usb: gadget: fsl: check vbus presence on probe

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: <20140508153845.GA3876@home.lan>
Date:	Thu, 8 May 2014 19:38:45 +0400
From:	Paul Fertser <fercerpav@...il.com>
To:	"suresh.gupta@...escale.com" <suresh.gupta@...escale.com>
Cc:	"balbi@...com" <balbi@...com>,
	"LeoLi@...escale.com" <LeoLi@...escale.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: gadget: fsl: check vbus presence on probe

Hi,

On Thu, May 08, 2014 at 02:30:39PM +0000, suresh.gupta@...escale.com wrote:
> As per my limited knowledge, the purpose of
> OTGSC_STS_B_SESSION_VALID bit is to tell either VBUS is above the B
> session valid threshold and which comes only Host is attached.

Yes, that matches the datasheet I've read.

> And Host might be attach after system bootup or after driver
> initialization. So putting this check in probe will not help much.

If the host is attached after the driver was initialised, the
interrupt will trigger and the driver will get notified that VBUS
appeared and everything will go smooth, at least that's how it should
work (I do not have any board handy to real-life check that, but
AFAICT that's the intent of the current code).

I actually do not have any iMX demoboards at all, I've only got some
custom-designed i.MX25 boards where I can't control VBUS, it's
permanently pulled up.

But I was fixing the problem that was clearly, 100% reproducibly
happening when VBUS was applied before the interrupt was
configured. So what exactly do you mean here? Do you mean this check
I've added doesn't fix the bug? Or do you mean this bug should be
fixed somehow else? Or do you mean there's no bug in the first place
and my board doesn't work because of something else?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...il.com
--
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/