Hi Dave,
--- On Mon, 12/6/10, Richard Retanubun<RichardRetanubun@xxxxxxxxxxxxx> wrote:
I am trying to model a hotplug usb host controller that
will cause a usb bus to appear/disappear
from the system on the fly
Why "model" when you can do the real thing?
Sorry, my VHDL dyslexia kicked in there, by "model" I mean "code it up" :)
Host controllers have hotplugged forever. The
simplest way to see this in action is to build
a host controller driver (maybe "ohci-hcd" if
you have OHCI hardware) as a module, and then use rmmod/modprobe.
You'll see the HCD's bus appear/modprobe or else
disappear/rmmod, and USB devices will enumerate.
>
If you have a hotpluggable host controller and
bus (Cardbus/PCI was the original platform) you
can try that too. Same process, except you'd
also be doing electrical hotplugging not just
the driver module dance.
- Dave
Thank you for both of you for taking the time to write back.
Here is the more detailed question:
- My linux baseline is 2.6.32-5
- I've ported the isp1763-hcd driver from isp1760-hcd driver
(and trying to mainline a unified one on a separate thread of work).
- The platform I am working on (MPC8360E CPU) will have isp1763 chips on both the main board
and some hotswap modules.
- For the mainboard one, things are simple, declare stuff in dtb and up it goes.
- For the hcd on the hostswap modules, some help from external program is needed to
realize a new module is plugged in and trigger calling usb_create_hcd and usb_add_hcd
for the driver (using generic netlink), modprobe with arguments may also work, but
generic netlink feels like a more structured approach.
- I am mostly wondering about the use of struct device *dev; In the examples I have looked at
most of these comes wrapped as a member of a larger struct (struct of_device, struct pci_dev,
struct usb_dev, struct platform_device) I don't know if it is legal to do something like this:
static int isp1763_genl_lmb_dev_add(struct sk_buff *skbuff, struct genl_info *info)
{
struct device dev; /* local device structure, initialize somehow */
struct usb_hcd *hcd;
/* Get mem resource and irq resource from genl_info fill it into hcd struct members */
hcd = usb_create_hcd(&isp1763_hc_driver, &dev, dev_name(&dev));
-----------------------------------------^^^^^^^^^^^^^^^^^^^^
/* Is passing a local (non-wrapped) device stucture here legal? is it a good practice?
* or is it better to use a static platform_device per driver instance?
*/
}
I can also create a local platform_device structure in the function above (or is it better that this be a static filescope structure?)
and use the struct device *dev that is included inside the struct platform_device but that feels awkward, and yet I haven't found another
way to cleanly remove the device later like this:
/* static filescope platform_device, filled in during isp1763_genl_lmb_dev_add */
static struct platform_device pdev;
static int isp1763_genl_lmb_dev_remove(struct sk_buff *skbuff, struct genl_info *info)
{
/* Get mem resource and irq resource from genl_info fill it into hcd struct members */
struct usb_hcd *hcd = platform_get_drvdata(pdev);
usb_remove_hcd(hcd);
/* Free memory and irq resources */
usb_put_hcd(hcd);
return 0;
}
The only driver I've found that does something similar (having a static struct platform_device) is /usb/host/sl811_cs.c
but I am not sure if there are some special pcmcia concepts I am missing,
for example it calls platform_device_register and platform_device_unregister.
Any comments is much appreciated.
- Richard
--
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
