linux-kernel - Re: When USB PHY framework should be used?

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: <20131011014239.GC14116@shlinux1.ap.freescale.net>
Date:	Fri, 11 Oct 2013 09:42:40 +0800
From:	Peter Chen <peter.chen@...escale.com>
To:	Arokux X <arokux@...il.com>
CC:	Felipe Balbi <balbi@...com>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg KH <gregkh@...uxfoundation.org>, <kishon@...com>,
	<linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: When USB PHY framework should be used?

On Thu, Oct 10, 2013 at 09:21:36PM +0200, Arokux X wrote:
> Hi,
> 
> recently I have been working on mainlining a simple bus glue driver
> for the USB EHCI for the Allwinner family of the ARM SoCs aka sunxi.
> The patches are almost ready and can be found at [1] and will be
> submitted once completely ready. The most interesting patch is [2]
> which is a driver itself.
> 
> Currently everything works. Recently Maxime Ripard brought the reset
> framework to my attention which I am going to use, since each of the
> PHYs has a reset bit. Right now those bits are treated as clocks.
> 
> Later I am going to add the OHCI support. OHCI and EHCI will be
> different drivers in different modules but they will share the same
> PHY. I do not quite understand how can I correctly use reset framework
> in the case of the common PHY. Imagine a situation if EHCI and OHCI
> drivers got loaded and deassert the (same) reset bit. Then a user
> decides to rmmod one of the drivers. This will cause it to assert the
> reset bit, which will make the other driver to fail. So it is clear
> there is a need for some central manager for the reset bit which is
> going to be poked by both EHCI and OHCI.
> 
> Maxime Ripard also brought to my attention the new USB phy framework
> which was merged into usb-next. However I'm not sure it should be used
> in my driver since as far as I understand a PHY of a USB Host
> Controller I'm dealing with is built into the controller itself. The
> only parts of the driver that touche a PHY are reset bits (different
> for each controller) and some initialization bits [3]. In addition the
> in the doc file phy.txt I read
> 
> "This framework will be of use only to devices that use external PHY
> (PHY functionality is not embedded within the controller)."

More exactly, it your PHY is not the same register mapping with controller's
you can use it.

> 
> So can you please give me some hints about the possibilities to share
> single reset bit? Should I use PHY framework, or create some kind of a
> common module that is going to be used by EHCI and OHCI. In addition I
> wanted to ask where I should normally put a common code like [4].

For your situation, you may need to create a controller driver, and call
ehci, ohci, and phy init at this probe routine, in that way, your ohci
and ehci controller will need to be unloaded together.

-- 

Best Regards,
Peter Chen

--
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/