From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] USB: Add driver for NXP ISP1301 USB transceiver
Date: Mon, 16 Apr 2012 14:14:14 +0000 [thread overview]
Message-ID: <201204161414.14624.arnd@arndb.de> (raw)
In-Reply-To: <1334582166-5485-1-git-send-email-stigge@antcom.de>
On Monday 16 April 2012, Roland Stigge wrote:
> This very-lowlevel driver registers the NXP ISP1301 chip via the I2C subsystem.
> The chip is the USB transceiver shared by ohci-nxp, lpc32xx_udc (gadget) and
> isp1301_omap.
>
> Following patches let the respective USB host and gadget drivers use this
> driver, instead of duplicating ISP1301 handling.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
All three patches:
Acked-by: Arnd Bergmann <arnd@arndb.de>
> This driver needs to be probe()d before the respective USB driver using it. For
> modules, this is handled via the module dependency. When linking statically, it
> is done via linking order in the Makefile (misc/ before host/ and the gadget/).
You can easily avoid the link order restriction now by returning -EPROBE_DEFER
from the probe function of the device that needs this one.
> Currently, only one ISP1301 chip is supported. To support multiple instances,
> we would need a mechanism to identify the respective chips via DT (and static
> resources or platform data) to be referenced by the higher level USB driver at
> isp1301_get_client(). Any suggestions?
Put a phandle into the usb device node, like:
isp1301: usb-transceiver at 23 {
compatible = "nxp,isp1301";
reg = <23>;
};
usbd at 31020000 {
compatible = "nxp,lpc32xx-udc";
reg = <0x31020000 0x300>;
interrupt-parent = <&mic>;
interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
transceiver = <&isp1301>;
status = "disable";
};
Then add a device_node argument to the isp1301_get_client() function
and change the function to use bus_find_device() with a match function
that compares the driver pointer.
Alternatively (and much more complex), you could add a generic usb-transceiver
abstraction that does this and also hides the register accesses behind
hardware independent function calls.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Roland Stigge <stigge@antcom.de>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, kevin.wells@nxp.com,
srinivas.bakki@nxp.com, stern@rowland.harvard.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/3] USB: Add driver for NXP ISP1301 USB transceiver
Date: Mon, 16 Apr 2012 14:14:14 +0000 [thread overview]
Message-ID: <201204161414.14624.arnd@arndb.de> (raw)
In-Reply-To: <1334582166-5485-1-git-send-email-stigge@antcom.de>
On Monday 16 April 2012, Roland Stigge wrote:
> This very-lowlevel driver registers the NXP ISP1301 chip via the I2C subsystem.
> The chip is the USB transceiver shared by ohci-nxp, lpc32xx_udc (gadget) and
> isp1301_omap.
>
> Following patches let the respective USB host and gadget drivers use this
> driver, instead of duplicating ISP1301 handling.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
All three patches:
Acked-by: Arnd Bergmann <arnd@arndb.de>
> This driver needs to be probe()d before the respective USB driver using it. For
> modules, this is handled via the module dependency. When linking statically, it
> is done via linking order in the Makefile (misc/ before host/ and the gadget/).
You can easily avoid the link order restriction now by returning -EPROBE_DEFER
from the probe function of the device that needs this one.
> Currently, only one ISP1301 chip is supported. To support multiple instances,
> we would need a mechanism to identify the respective chips via DT (and static
> resources or platform data) to be referenced by the higher level USB driver at
> isp1301_get_client(). Any suggestions?
Put a phandle into the usb device node, like:
isp1301: usb-transceiver@23 {
compatible = "nxp,isp1301";
reg = <23>;
};
usbd@31020000 {
compatible = "nxp,lpc32xx-udc";
reg = <0x31020000 0x300>;
interrupt-parent = <&mic>;
interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
transceiver = <&isp1301>;
status = "disable";
};
Then add a device_node argument to the isp1301_get_client() function
and change the function to use bus_find_device() with a match function
that compares the driver pointer.
Alternatively (and much more complex), you could add a generic usb-transceiver
abstraction that does this and also hides the register accesses behind
hardware independent function calls.
Arnd
next prev parent reply other threads:[~2012-04-16 14:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 13:16 [PATCH v2 1/3] USB: Add driver for NXP ISP1301 USB transceiver Roland Stigge
2012-04-16 13:16 ` Roland Stigge
2012-04-16 13:16 ` [PATCH v2 2/3] USB: gadget driver for LPC32xx Roland Stigge
2012-04-16 13:16 ` Roland Stigge
2012-04-16 13:16 ` [PATCH v2 3/3] USB: ohci-nxp: Use isp1301 driver Roland Stigge
2012-04-16 13:16 ` Roland Stigge
2012-04-16 14:14 ` Arnd Bergmann [this message]
2012-04-16 14:14 ` [PATCH v2 1/3] USB: Add driver for NXP ISP1301 USB transceiver Arnd Bergmann
2012-04-16 15:40 ` Roland Stigge
2012-04-16 15:40 ` Roland Stigge
2012-04-16 15:09 ` Alan Stern
2012-04-16 15:09 ` Alan Stern
2012-04-16 15:52 ` Roland Stigge
2012-04-16 15:52 ` Roland Stigge
2012-04-16 15:58 ` Greg KH
2012-04-16 15:58 ` Greg KH
2012-04-16 16:02 ` Alan Stern
2012-04-16 16:02 ` Alan Stern
2012-04-16 16:12 ` Roland Stigge
2012-04-16 16:12 ` Roland Stigge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201204161414.14624.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.