linux-kernel - 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-next>] [day] [month] [year] [list]

Date:	Thu, 10 Oct 2013 21:21:36 +0200
From:	Arokux X <arokux@...il.com>
To:	Felipe Balbi <balbi@...com>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg KH <gregkh@...uxfoundation.org>, kishon@...com
Cc:	linux-usb@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: When USB PHY framework should be used?

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)."

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].

Thank you in advance,
Arokux

[1] https://github.com/arokux/linux/commits/sunxi-next-usb
[2] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be
[3] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R89
[4] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R104
--
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/