On 10.04.2013 20:54, Peter Korsgaard wrote:
>>>>>> "Daniel" == Daniel Mack <zonque@xxxxxxxxx> writes:
>
> Daniel> The musb struct is currently allocated along with the hcd, which makes
> Daniel> it difficult to build a driver that only acts as gadget device.
>
> Daniel> Fix this by allocating musb directly, and keep the hcd around as
> Daniel> a pointer in the musb struct.
>
> Daniel> struct hc_driver musb_hc_driver can now also be static to musb_host.c,
> Daniel> and the macro musb_to_hcd() is just a pointer dereferencer for now, and
> Daniel> will be eliminated later.
>
> Daniel> Signed-off-by: Daniel Mack <zonque@xxxxxxxxx>
> Daniel> Acked-by: Peter Korsgaard <jacmet@xxxxxxxxxx>
> Daniel> ---
> Daniel> drivers/usb/musb/musb_core.c | 40 ++++++++++++++++----------------
> Daniel> drivers/usb/musb/musb_core.h | 1 +
> Daniel> drivers/usb/musb/musb_host.c | 54 ++++++++++++++++++++++++++++++++++++++------
> Daniel> drivers/usb/musb/musb_host.h | 19 +++++++---------
> Daniel> 4 files changed, 75 insertions(+), 39 deletions(-)
>
>
> Daniel> +struct musb_hcd_link {
> Daniel> + struct musb *musb;
> Daniel> +};
> Daniel> +
> Daniel> +struct musb *hcd_to_musb(struct usb_hcd *hcd)
> Daniel> +{
> Daniel> + struct musb_hcd_link *link = (struct musb_hcd_link *) hcd->hcd_priv;
> Daniel> + return link->musb;
> Daniel> +}
> Daniel> +
>
> Sorry, I missed this first time around - But why the indirection with
> musb_hcd_link? Why not simply directly store a pointer to struct musb in
> hcd_priv?
Well, that's also possible. I just thought it's nicer (more readable)
that way. But I can as well rework it so the struct isn't needed. It
won't safe us any binary size or anything though. So I'm not sure.
Any particular reason why you don't like the struct? :)
Daniel
--
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
