CODEWITHSUNDEEP
clinuxusblinux-device-driver
Roosembert Palacios
Roosembert Palacios

Reputation: 41

{USB Composite Device Kernel Module Driver Programming} Multiple Interfaces management and "no endpoint" handling

I'm Trying to port Pololu's mini maestro USB Servo Controller driver into a Linux Kernel Module (This is my first try of writing a kenel module). Pololu's Linux Driver actually uses mono runtime environment, lots of what I think are compatibilization layers and It's written in C# (Unknown for me), so porting it to C for compiling this into a kernel module it's important because I want other programs to use pipes to communicate with the USB Module.

So, here's the deal, I used lsusb -vvv to list the Device Characteristics

But the last interface states:

 Interface Descriptor:
  bInterfaceNumber        4
  bNumEndpoints           0
  bInterfaceClass       255 Vendor Specific Class
  bInterfaceSubClass      4
  bInterfaceProtocol      1
  iInterface              2 Pololu Mini Maestro 18-Channel USB Servo Controller

What I can't figure out is:

From the Composite device itself:

Best Regards!

Upvotes: 0

Views: 1352

Answers (2)

Roosembert Palacios
Roosembert Palacios

Reputation: 41

So, I've digged in a couple of websites, and Asked on the Pololu forum And I got some answers, First at all thanks to @preston for his clues!

  • Can I handle it {the non-listed control endpoint} and how I can do it?

Yes, we can, via the usb_control_msg function, defined in line 132 of /drivers/usb/core/message.c

int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request, __u8 requesttype, __u16 value, __u16 index, void *data, __u16 size, int timeout)

  • A kernel driver instance is ran for each Interface?

As @preston Replyed, it is

  • How can I catch an interface and identify how to manage it?

We don't need to 'catch' the interface, the interface is sent to probe to the kernel module:

static int probe(struct usb_interface *interface, const struct usb_device_id *id)

  • How can I treat Interface Associations?

As I've been told I don't need to handle them in an special way, just recognize the Interface with the driver on the probe function

Upvotes: 0

Preston
Preston

Reputation: 2653

Here are some answers to your questions:

Is there a Non-listed Control endpoint that can be used for configuring Device mode? Can I handle it and how I can do it?

The control endpoint will always be endpoint 0, you simply direct your setup packets to this endpoint to communicate a control request to the device. Since there is only one endpoint per device you will need to see how Polulu specifies the interface for the specified control request, typically passed in as the wIndex value for the control transfer.

From the Composite device itself: A kernel driver instance is ran for each Interface? How can I catch an interface and identify how to manage it? How can I treat Interface Associations?

Each interface will present itself as some unique USB interface. Each one is independent and will have it's own behavior. For example you could have a composite device with 3 interfaces: an interface for a Mass Storage device, an interface for a USB Audio device and a Vendor Specific interface. Each one of these would load their own driver instances specifically for that interface. The first two will typically already be built in to modern OS and kernel versions since they are defined USB Classes. But the vendor specific device will probably have to do some VID/PID matching for a vendor specific driver. This is what will happen in your case if you need to talk to this particular interface you have shown above.

Upvotes: 1

Related Questions