All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support
Date: Wed, 25 Jun 2014 08:08:23 +0200	[thread overview]
Message-ID: <201406250808.23420.marex@denx.de> (raw)
In-Reply-To: <CAFp+6iE0fMGK2y68sVUdk__3FRfEbAGxWYMs0EtC-AH7V8DCDQ@mail.gmail.com>

On Wednesday, June 25, 2014 at 07:11:42 AM, Vivek Gautam wrote:
> Hi Marek,
> 
> On Tue, Jun 24, 2014 at 7:56 PM, Marek Vasut <marex@denx.de> wrote:
> > On Tuesday, June 24, 2014 at 04:10:20 PM, Vivek Gautam wrote:
> >> Hi Marek,
> >> 
> >> It's been very long since we had discussion for introducing the wrapper
> >> layer to enable using multiple usb controller types.
> >> Its been unfortunate that i had been busy with other tasks, and couldn't
> >> look into this.
> >> Now that i got sometime, i have prepared a simple RFC patch which right
> >> now supports APIs translation for submit_control_msg(),
> >> submit_bulk_msg(), submit_int_msg(), and usb_lowlevel_init() as well as
> >> usb_lowlevel_stop(). This was the simplest approach that could
> >> differentiate between controller types.
> >> 
> >> I had thought of another approach too, wherein there's a 'list' passed
> >> by the usb core layer, which would be filled with 'host_controller_drv'
> >> structure, that would contain information about the driver. And then
> >> each host controller driver will register certain callbacks that can be
> >> called from the upper layers. If you say i will send an RFC for this
> >> approach.
> > 
> > I think this approach in this patchset will not play well with the driver
> > model. Instead, I'd love to see a mean to instantiate each *HCI
> > controller and have a USB core which would track those instances. The
> > USB core would then be able to call whatever generic ops on those
> > instances as needed. Does that make sense please ?
> 
> True, i understand your point here. I think the second approach i was
> talking of, goes in this direction.
> I think i could not put it well in words there.
> 
> I will prepare an RFC patch for that, and post it as soon as its
> ready, so that you can have
> a look.

Ah, this would be so very appreciated! Thank you!

Best regards,
Marek Vasut

  reply	other threads:[~2014-06-25  6:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 14:10 [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support Vivek Gautam
2014-06-24 14:10 ` [U-Boot] [PATCH 1/2] usb: Rename usb_submit_int_msg() API to usb_int_msg() Vivek Gautam
2014-06-24 14:10 ` [U-Boot] [PATCH 2/2] RFC: usb: host: Introduce host translational layer Vivek Gautam
2014-06-24 14:26 ` [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support Marek Vasut
2014-06-25  5:11   ` Vivek Gautam
2014-06-25  6:08     ` Marek Vasut [this message]
2014-06-25  6:27       ` Simon Glass
2014-06-25  8:33         ` Marek Vasut
2014-06-26  2:30           ` Simon Glass
2014-06-26  4:34             ` Vivek Gautam
2014-06-26  4:46               ` Vivek Gautam
2014-06-26  9:21                 ` Marek Vasut
2014-07-07 22:46                   ` Simon Glass

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=201406250808.23420.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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.