Re: Gadget driver & virtual hub

[Alan Stern]

On Fri, 9 Jun 2017, Benjamin Herrenschmidt wrote:

> On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote:
> > On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
> > 
> > > Another question ...
> > > 
> > > Do i need to support dequeue() on EP0 ?
> > 
> > Yes.  I don't know if any drivers ever dequeue requests from ep0, but 
> > it should be supported.
> 
> Talking of which... what is the expected "semantic" of dequeue of
> an active request ? (Either on EP0 or another EP, but on EP0 a queued
> request becomes active pretty much right away).
> 
> By active I mean the request has started transferring.
> 
> I assume I should interrupt it on a packet boundary... do I also need
> to finish with a short packet for a IN request or leave the pipe alone
> in whatever half-baked state it is ?

This is unspecified in the API.  You can do pretty much whatever you 
want; a transfer that gets cancelled in the middle is going to need 
some sort of error recovery on the host side no matter what.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote:
> On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
> 
> > Another question ...
> > 
> > Do i need to support dequeue() on EP0 ?
> 
> Yes.  I don't know if any drivers ever dequeue requests from ep0, but 
> it should be supported.

Talking of which... what is the expected "semantic" of dequeue of
an active request ? (Either on EP0 or another EP, but on EP0 a queued
request becomes active pretty much right away).

By active I mean the request has started transferring.

I assume I should interrupt it on a packet boundary... do I also need
to finish with a short packet for a IN request or leave the pipe alone
in whatever half-baked state it is ?

Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote:
> On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
> 
> > Another question ...
> > 
> > Do i need to support dequeue() on EP0 ?
> 
> Yes.  I don't know if any drivers ever dequeue requests from ep0, but 
> it should be supported.
> 
> There is one other special requirement for ep0.  When a new setup
> packet arrives, any previously queued requests should be cancelled
> automatically.

Yup. It also doesn't stay stalled and only supports a single request in
the queue, in that regard I have just "copied" other drivers ;-)

Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Alan Stern]

On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:

> Another question ...
> 
> Do i need to support dequeue() on EP0 ?

Yes.  I don't know if any drivers ever dequeue requests from ep0, but 
it should be supported.

There is one other special requirement for ep0.  When a new setup
packet arrives, any previously queued requests should be cancelled
automatically.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Greg KH]

On Thu, Jun 08, 2017 at 07:39:15PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2017-06-08 at 08:12 +0200, Greg KH wrote:
> > On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote:
> > > And another one :-)
> > > 
> > > So the virtual hub needs a vendor/device ID.
> > > 
> > > What is the policy here ? Can I get one from LF for it ?
> > 
> > Yes, just ask me and I'll give you one.  I just need to know exactly
> > what this device is (virtual gadget hub?)
> 
> Ah yes, so this is the "UDC" controller in the Aspeed SoC. Those SoC
> act as BMC in a lot of server platforms.
> 
> The UDC is a bit special as it simulates a hub with up to 5 devices
> behind it. So I need to make up descriptors for the hub portion of it.
> 
> It's thus sort-of a virtual gadget hub.
> 
> I think it's probably ok to use the same product ID for the USB1 and
> the USB2 mode with a different speed, so one should be enough.

Sure, one should be fine.  I've now reserved you device id 0x0107 for a
"Embedded HUB Gadget", and you can use the vendor id of 0x1d6b.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Thu, 2017-06-08 at 08:12 +0200, Greg KH wrote:
> On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote:
> > And another one :-)
> > 
> > So the virtual hub needs a vendor/device ID.
> > 
> > What is the policy here ? Can I get one from LF for it ?
> 
> Yes, just ask me and I'll give you one.  I just need to know exactly
> what this device is (virtual gadget hub?)

Ah yes, so this is the "UDC" controller in the Aspeed SoC. Those SoC
act as BMC in a lot of server platforms.

The UDC is a bit special as it simulates a hub with up to 5 devices
behind it. So I need to make up descriptors for the hub portion of it.

It's thus sort-of a virtual gadget hub.

I think it's probably ok to use the same product ID for the USB1 and
the USB2 mode with a different speed, so one should be enough.

Thanks !

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Greg KH]

On Thu, Jun 08, 2017 at 06:38:40PM +1000, Benjamin Herrenschmidt wrote:
> Alan, do you know the process to get one of the LF IDs ? Is that a
> reasonable request ?

Again, just ask me for one, I'm the one that give them out :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Thu, 2017-06-08 at 10:18 +0200, Bjørn Mork wrote:
> Benjamin Herrenschmidt  writes:
> 
> > And another one :-)
> > 
> > So the virtual hub needs a vendor/device ID.
> > 
> > What is the policy here ? Can I get one from LF for it ? Or should the
> > HW vendor provide one here ? (I'm not sure they have one, I will have
> > to ask).
> > 
> > I will provide a way to override it but I need a sane default.
> 
> 
> In case you're interested... This is the hub as implemented by the
> firmware coming with the Asus ASMB8-iKVM.  Looks like the firmware
> vendor provides the ID here, so getting one from LF is probably best:

Yes, FW vendors provide the IDs. AMI it's their own ID, for SMC they
use another one (I forgot which), etc...

One option is to mandate having IDs in the device-tree but that leaves
open the question of what to put for the Aspeed eval board since Aspeed
themselves doesn't have a USB ID :-)

Alan, do you know the process to get one of the LF IDs ? Is that a
reasonable request ?

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Bjørn Mork]

Benjamin Herrenschmidt  writes:

> And another one :-)
>
> So the virtual hub needs a vendor/device ID.
>
> What is the policy here ? Can I get one from LF for it ? Or should the
> HW vendor provide one here ? (I'm not sure they have one, I will have
> to ask).
>
> I will provide a way to override it but I need a sane default.


In case you're interested... This is the hub as implemented by the
firmware coming with the Asus ASMB8-iKVM.  Looks like the firmware
vendor provides the ID here, so getting one from LF is probably best:


Bus 001 Device 005: ID 046b:ff01 American Megatrends, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x046b American Megatrends, Inc.
  idProduct  0xff01 
  bcdDevice1.00
  iManufacturer   1 American Megatrends Inc.
  iProduct2 Virtual Hub
  iSerial 3 serial
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4 Self-powered
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  5 7-port Hub
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval  12
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 5
  wHubCharacteristic 0x0069
Per-port power switching
Per-port overcurrent protection
TT think time 32 FS bits
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent100 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0503 highspeed power enable connect
   Port 2: .0503 highspeed power enable connect
   Port 3: .0503 highspeed power enable connect
   Port 4: .0303 lowspeed power enable connect
   Port 5: .0100 power
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered




Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Greg KH]

On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote:
> And another one :-)
> 
> So the virtual hub needs a vendor/device ID.
> 
> What is the policy here ? Can I get one from LF for it ?

Yes, just ask me and I'll give you one.  I just need to know exactly
what this device is (virtual gadget hub?)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

And another one :-)

So the virtual hub needs a vendor/device ID.

What is the policy here ? Can I get one from LF for it ? Or should the
HW vendor provide one here ? (I'm not sure they have one, I will have
to ask).

I will provide a way to override it but I need a sane default.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

Another question ...

Do i need to support dequeue() on EP0 ?

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Felipe Balbi]

Hi,

Benjamin Herrenschmidt  writes:
>> Benjamin Herrenschmidt  writes:
>> > So another question :-)
>> > 
>> > Is it legal to break down a bulk (or ISO) IN request into packets that
>> > are *smaller* than the Max EP size ?
>> 
>> it depends if they are *supposed* to be two smaller packets or should be
>> two parts of a single one.
>> 
>> > For example, I have a max EP size of 512 bytes and the gadget gives me
>> > an SG list where that's broken up into two segments (for example 2x256
>> > bytes).
>> > 
>> > Now, I'm still trying to confirm with the vendor what happens here, but
>> > I *suspect* that if I create 2 descriptors, the HW will break it down
>> > into 2 packets smaller than the max EP size on the wire.
>> 
>> If that's the case, then your HW can't handle SG lists. I suspect there
>> will be some "chain" bit somewhere in the DMA descriptor which you can
>> use to tell DMA that these two segments are part of a single transfer.
>
> No, there isn't, sadly. I've confirmed with the HW vendor. I might
> still enable SG with a fallback to bounce buffering to a pre-allocated
> packet buffer if I hit such a situation... It shouldn't be common for
> mass storage (though do we use sglists for the mass storage gadget ?),

UASP does use it ;-)

> it might be more with networking if our network function does
> fragmented sends, I haven't checked.

Well, even networking gadget is using a linear buffer. Nobody
implemented support for sg lists yet.

>> > I do have vague memories of seeing "client" drivers in the past with
>> > make assumptions that some "replies" are fully contained in a single
>> > packet, so I'm tempted to say that this won't work, and thus should
>> > bounce such packets through a linear buffer but I'd like confirmation.
>> 
>> yeah, USB makes that assumption. If host side requests 512 bytes and you
>> end up breaking that into two packets, host will receive only the first
>> 256 bytes, as short packets terminate transfers.
>
> Yup, that was indeed my assumption. Thanks for confirming.

np

-- 
balbi


signature.asc
Description: PGP signature

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Mon, 2017-06-05 at 09:02 +0300, Felipe Balbi wrote:
> Hi,
> 
> Benjamin Herrenschmidt  writes:
> > So another question :-)
> > 
> > Is it legal to break down a bulk (or ISO) IN request into packets that
> > are *smaller* than the Max EP size ?
> 
> it depends if they are *supposed* to be two smaller packets or should be
> two parts of a single one.
> 
> > For example, I have a max EP size of 512 bytes and the gadget gives me
> > an SG list where that's broken up into two segments (for example 2x256
> > bytes).
> > 
> > Now, I'm still trying to confirm with the vendor what happens here, but
> > I *suspect* that if I create 2 descriptors, the HW will break it down
> > into 2 packets smaller than the max EP size on the wire.
> 
> If that's the case, then your HW can't handle SG lists. I suspect there
> will be some "chain" bit somewhere in the DMA descriptor which you can
> use to tell DMA that these two segments are part of a single transfer.

No, there isn't, sadly. I've confirmed with the HW vendor. I might
still enable SG with a fallback to bounce buffering to a pre-allocated
packet buffer if I hit such a situation... It shouldn't be common for
mass storage (though do we use sglists for the mass storage gadget ?),
it might be more with networking if our network function does
fragmented sends, I haven't checked.

> > I do have vague memories of seeing "client" drivers in the past with
> > make assumptions that some "replies" are fully contained in a single
> > packet, so I'm tempted to say that this won't work, and thus should
> > bounce such packets through a linear buffer but I'd like confirmation.
> 
> yeah, USB makes that assumption. If host side requests 512 bytes and you
> end up breaking that into two packets, host will receive only the first
> 256 bytes, as short packets terminate transfers.

Yup, that was indeed my assumption. Thanks for confirming.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Felipe Balbi]

Hi,

Benjamin Herrenschmidt  writes:
> So another question :-)
>
> Is it legal to break down a bulk (or ISO) IN request into packets that
> are *smaller* than the Max EP size ?

it depends if they are *supposed* to be two smaller packets or should be
two parts of a single one.

> For example, I have a max EP size of 512 bytes and the gadget gives me
> an SG list where that's broken up into two segments (for example 2x256
> bytes).
>
> Now, I'm still trying to confirm with the vendor what happens here, but
> I *suspect* that if I create 2 descriptors, the HW will break it down
> into 2 packets smaller than the max EP size on the wire.

If that's the case, then your HW can't handle SG lists. I suspect there
will be some "chain" bit somewhere in the DMA descriptor which you can
use to tell DMA that these two segments are part of a single transfer.

> I do have vague memories of seeing "client" drivers in the past with
> make assumptions that some "replies" are fully contained in a single
> packet, so I'm tempted to say that this won't work, and thus should
> bounce such packets through a linear buffer but I'd like confirmation.

yeah, USB makes that assumption. If host side requests 512 bytes and you
end up breaking that into two packets, host will receive only the first
256 bytes, as short packets terminate transfers.

-- 
balbi


signature.asc
Description: PGP signature

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

So another question :-)

Is it legal to break down a bulk (or ISO) IN request into packets that
are *smaller* than the Max EP size ?

For example, I have a max EP size of 512 bytes and the gadget gives me
an SG list where that's broken up into two segments (for example 2x256
bytes).

Now, I'm still trying to confirm with the vendor what happens here, but
I *suspect* that if I create 2 descriptors, the HW will break it down
into 2 packets smaller than the max EP size on the wire.

I do have vague memories of seeing "client" drivers in the past with
make assumptions that some "replies" are fully contained in a single
packet, so I'm tempted to say that this won't work, and thus should
bounce such packets through a linear buffer but I'd like confirmation.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Alan Stern]

On Fri, 2 Jun 2017, Benjamin Herrenschmidt wrote:

> On Fri, 2017-06-02 at 15:13 +1000, Benjamin Herrenschmidt wrote:
> > On Sat, 2017-05-27 at 21:58 -0400, Alan Stern wrote:
> > > The interfaces required for a UDC driver are explained to some extent 
> > > by the kerneldoc in include/linux/usb/gadget.h.  For anything you still 
> > > don't understand, feel free to ask on this mailing list.
> > 
> > It's missing docs for the udc callbacks :-)

Yeah, the file could use a few additions.

> > One quick question: ->set_halt, when called for clearing a stall (when
> > does that happen btw ? I though only the host would do that), should

See the kerneldoc for usb_ep_set_wedge() in udc/core.c.  The USB Mass 
Storage Bulk-Only Transport spec says that under certain conditions, 
a bulk endpoint must be halted and must remain halted even if the host 
issues a Clear-Feature(Halt) request.  The wedge operation was 
introduced to fulfill this requirement.

The only way to un-wedge an endpoint is for the gadget driver to tell
->set_halt to clear it.

> > it also reset the data toggle like a CLEAR_FEATURE would do 

Yes.

> Also, a SET_FEATURE setting a stall, should that nuke pending
> queued request ?

No, the requests should remain on the queue until the gadget driver
dequeues them or until the halt feature is cleared and they complete
normally (or something else causes them to be dequeued, such as the
endpoint being disabled or the gadget being disconnected from the
host).

> What about things like setting configuration, alt settings etc... all
> these things are supposed to cleanup endpoint data toggles, should
> probably nuke all pending requests etc UDC drivers don't seem to
> do it and the "core" doesn't seem to have any kind of tracking of
> these things...

Those things are handled by the gadget driver (or for modern gadgets,
by the composite core), not by the UDC driver.  The gadget driver
disables the endpoints for the old config/altsetting and then enables
the endpoints for the new one.  Disabling an endpoint should clean up
all the state associated with it.

> It looks like if the interface driver wants to do the right thing,
> it needs ->set_halt() to also reset the toggle then ... 

That's right.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Fri, 2017-06-02 at 15:13 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2017-05-27 at 21:58 -0400, Alan Stern wrote:
> > The interfaces required for a UDC driver are explained to some extent 
> > by the kerneldoc in include/linux/usb/gadget.h.  For anything you still 
> > don't understand, feel free to ask on this mailing list.
> 
> It's missing docs for the udc callbacks :-)
> 
> One quick question: ->set_halt, when called for clearing a stall (when
> does that happen btw ? I though only the host would do that), should
> it also reset the data toggle like a CLEAR_FEATURE would do 

Also, a SET_FEATURE setting a stall, should that nuke pending
queued request ?

What about things like setting configuration, alt settings etc... all
these things are supposed to cleanup endpoint data toggles, should
probably nuke all pending requests etc UDC drivers don't seem to
do it and the "core" doesn't seem to have any kind of tracking of
these things...

It looks like if the interface driver wants to do the right thing,
it needs ->set_halt() to also reset the toggle then ... 

Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Sat, 2017-05-27 at 21:58 -0400, Alan Stern wrote:
> The interfaces required for a UDC driver are explained to some extent 
> by the kerneldoc in include/linux/usb/gadget.h.  For anything you still 
> don't understand, feel free to ask on this mailing list.

It's missing docs for the udc callbacks :-)

One quick question: ->set_halt, when called for clearing a stall (when
does that happen btw ? I though only the host would do that), should
it also reset the data toggle like a CLEAR_FEATURE would do ?

Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Benjamin Herrenschmidt]

On Sat, 2017-05-27 at 21:58 -0400, Alan Stern wrote:
> Vbus is the +5V power provided on the USB bus by the host controller.  
> Bus-powered devices use it as their sole power source, and self-powered
> devices may use it in conjunction with their own alternative power
> source.
> 
> If a UDC driver sees that vbus isn't present then it can assume the UDC
> isn't connected to anything.  (There are some odd exceptions involving 
> USB OTG ("On-The-Go"), where the host and peripheral can swap roles -- 
> normally you don't have to worry about that.)  That's how the driver 
> detects a disconnection.

Ok so this controller has no specific detection of VBUS, in fact the
eval board has it unwired. (It's meant to be a BMC with a permanent
connection to the host). I can control the "connection" to the host via
a register, so I've plumbed that into my pullup() callback, I assume
that's the right thing to do at this stage.

> The interfaces required for a UDC driver are explained to some extent 
> by the kerneldoc in include/linux/usb/gadget.h.  For anything you still 
> don't understand, feel free to ask on this mailing list.

Ah I had missed some of those explanations for some reason, thanks :-)

I'll leave the virtual hub aside for now until I have "single device"
mode working.

Once I resume work on this, the "interesting" bit will be how to
allocate the 15 "generic" endpoints to the 5 devices. I'm thinking of a
rather static layout, possibly via the device-tree. That or I'll add a
custom configfs interface to the UDC driver...

Cheers,
Ben.
 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadget driver & virtual hub

[Alan Stern]

On Sun, 28 May 2017, Benjamin Herrenschmidt wrote:

> Hi !
> 
> So I'm toying a bit with the gadget subsystem, writing an UDC driver
> for the Aspeed BMC SoC.
> 
> One thing this HW does (which I'm not yet enabling) is that it can
> show as a virtual hub with up to 5 devices underneath.
> 
> The hub and each device has independent EP0's, and there's a pool
> of 15 "generic" endpoints that can be assigned to them otherwise.
> 
> There's additional HW support for the hub's EP1 to be mostly operating
> autonomously in HW, returning the virtual hub port status.
> 
> However, all of the hub EP0 needs to be done in SW (descriptors
> etc...).
> 
> So my question is how would you guys recommend I should structure this
> in my driver ? The "dumb" option is to implement all of the hub stuff
> locally in my driver, including the responses to all the descriptor
> request etc... and expose effectively 5 UDC gadget "slots" for the
> user to hookup gadget drivers to.

That's what I would do.

> Another approach would be to try to have a gadget "slot" for the hub
> itself that is somewhat hard-wired to a hub function (which I would
> implement separately).
> 
> The latter "sounds" nicer, however there is a need for a back channel
> between the main driver and the hub function unless we lift the
> abstraction to contain hub controls which I'm not sure is worthwhile.

There are no "hub" gadget drivers.  I suppose one could be written in
some sort of generic way, but there would be little point since there's
essentially no hub gadget hardware.  Yours is the only example I've
heard of.  After all, there's no reason for a hub to be programmable -- 
it serves only one function and that can be handled perfectly well by 
fixed firmware.

> Also, can somebody enlighten me a bit more on what the "vbus" stuff
> is about ? I haven't quite figured it out. There seem to be no
> documentation (unless I missed it) on the various interfaces and UDC
> driver is supposed to provide.

Vbus is the +5V power provided on the USB bus by the host controller.  
Bus-powered devices use it as their sole power source, and self-powered
devices may use it in conjunction with their own alternative power
source.

If a UDC driver sees that vbus isn't present then it can assume the UDC
isn't connected to anything.  (There are some odd exceptions involving 
USB OTG ("On-The-Go"), where the host and peripheral can swap roles -- 
normally you don't have to worry about that.)  That's how the driver 
detects a disconnection.

The interfaces required for a UDC driver are explained to some extent 
by the kerneldoc in include/linux/usb/gadget.h.  For anything you still 
don't understand, feel free to ask on this mailing list.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Gadget driver & virtual hub

[Benjamin Herrenschmidt]

Hi !

So I'm toying a bit with the gadget subsystem, writing an UDC driver
for the Aspeed BMC SoC.

One thing this HW does (which I'm not yet enabling) is that it can
show as a virtual hub with up to 5 devices underneath.

The hub and each device has independent EP0's, and there's a pool
of 15 "generic" endpoints that can be assigned to them otherwise.

There's additional HW support for the hub's EP1 to be mostly operating
autonomously in HW, returning the virtual hub port status.

However, all of the hub EP0 needs to be done in SW (descriptors
etc...).

So my question is how would you guys recommend I should structure this
in my driver ? The "dumb" option is to implement all of the hub stuff
locally in my driver, including the responses to all the descriptor
request etc... and expose effectively 5 UDC gadget "slots" for the
user to hookup gadget drivers to.

Another approach would be to try to have a gadget "slot" for the hub
itself that is somewhat hard-wired to a hub function (which I would
implement separately).

The latter "sounds" nicer, however there is a need for a back channel
between the main driver and the hub function unless we lift the
abstraction to contain hub controls which I'm not sure is worthwhile.

Also, can somebody enlighten me a bit more on what the "vbus" stuff
is about ? I haven't quite figured it out. There seem to be no
documentation (unless I missed it) on the various interfaces and UDC
driver is supposed to provide.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html