Hello.
I didn't really intend to reply off-lists, so including the original
recepients now...
Daniel Mack wrote:
diff --git a/drivers/usb/otg/isp1504.c b/drivers/usb/otg/isp1504.c
new file mode 100644
index 0000000..8a449db
--- /dev/null
+++ b/drivers/usb/otg/isp1504.c
@@ -0,0 +1,108 @@
+/*
+ * isp1504 - NXP ISP 1504 USB transceiver
Since this driver only uses the standard UPLI registers, shouldn't it
be called ulpi.c instead?
I don't have the full ULPI specification unfortunately,
So I thought. Here it is:
http://www.smsc.com/media/Downloads_Public/usb/ulpi_v1_1.zip
(found by googling for "ULPI specification").
so I can't
really tell. But as far as I understand, especially these registers are
outside the ULPI standard and hence they are device specific.
No, they are not -- see the spec...
+static int isp1504_set_vbus(struct otg_transceiver *otg, bool on)
+{
+ if (on)
+ return otg_io_write(otg, DRV_VBUS_EXT | DRV_VBUS |
Why do you think that (optional) external supply should always be used?
That made it work for many boards. What would your proposal be? Add a
parameter to the API to decide that?
No, probably that should be initialized in the init() method or in
board specific code.
+ USE_EXT_VBUS_IND | CHRG_VBUS,
Likewise, why do you think that external Vbus indicator should always
be used?
Also, isn't Vbus charging that you're enabling here a part of SRP
protocol?
Not that I know of. Maybe we should discuss the generic API and then
change the implementation accordingly.
As it stands, the series work well for the ISP1504 transceiver, but I'm
willing to make it more generic in the first place if anyone has an idea
of how a sane interface could look like.
Daniel
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
