linux-kernel - Re: [PATCHv6 01/19] usb: otg: Rename otg_transceiver to usb

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: <20111108120635.GA2531@xps8300>
Date:	Tue, 8 Nov 2011 14:06:35 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	"ABRAHAM, KISHON VIJAY" <kishon@...com>
Cc:	Felipe Balbi <balbi@...com>, Greg KH <gregkh@...e.de>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: [PATCHv6 01/19] usb: otg: Rename otg_transceiver to usb_phy

Hi,

On Tue, Nov 08, 2011 at 11:27:12AM +0530, ABRAHAM, KISHON VIJAY wrote:
> Hi Heikki,
> 
> I tend to defer with your opinion of renaming otg_transceiver to
> usb_phy. According to me otg_transceiver should program hardware
> mechanisms associated to VBUS, ID lines, etc.. and phy is responsible
> for transmitting data over differential data lines (with its own
> programming of phy_init, phy_shutdown, setting phy clocks etc..). So
> in my opinion otg_transceiver and usb_phy should be two different and
> separate entities.

Maybe I'm misunderstanding you, but sounds like you are still marrying
OTG with transceivers. The struct usb_phy is independent of OTG.

Things like the otg_transceiver are dropped. The idea is to have the
OTG utility independent of any hardware. OTG does not need to be tied
to a transceiver or to a controller.

On most platforms the controller is perfectly capable of handling any
OTG related function without any need for the software to program the
PHY, so functions like "drive VBUS" will in practice be implemented by
the controller driver. There may not be PHY driver at all but OTG is
still supported.

If on your platform the PHY needs to be programmed in order to drive
VBUS, or handle some other OTG function, then your PHY driver will
fill the hooks in your struct usb_otg. The utility does not need to
care which driver implements these hooks.

> I would have preferred to rename otg_transceiver as usb_otg as the
> first step. (this differs from your implementation where you rename
> otg_transceiver to usb_phy and create a new structure usb_otg to
> separate otg members from usb_phy).
> 
> But it should have been first  rename otg_transceiver as usb_otg. Then
> create a new structure usb_phy to move all the phy specific
> implementation there. This kind of implementation will also help when
> we want to have independent phy drivers.

This would not have changed the outcome.

Oh, and keep in mind that this really is only the first step in this
rework. After this the idea is to provide support for multiple
transceivers and move USB PHY structures and functions into separate
files from OTG. The final step, and my ultimate goal, is implementing
a generic OTG state machine for the OTG utility.

Br,

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