On Tue, Dec 07, 2010 at 10:09:06AM -0500, Richard Retanubun wrote:
> 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.
How are these devices "hotswapable"?
The bus that the devices are on that is swapable is responsible for the
notification and all of that stuff. Like PCI is for the "common" HCD
controllers.
So work on creating that bus, then making your driver be a device on
that bus and it should all work.
> - 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?
> */
It depends on the bus that your device is on.
As people will have this chip on different types of devices, stick with
the basic 'struct device' as that will provide the driver model, and
sysfs, with the needed information about parents and the whole heirachy.
good luck,
greg k-h
--
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
