Escribir un driver USB: usb_driver, probe y disconnect

Escribir un driver USB no es programar el bus: es firmar un contrato con usbcore. Declaras una tabla que dice qué dispositivos reclamas y dos funciones, una para cuando aparece uno y otra para cuando se va. El núcleo hace por ti la enumeración, el arbitraje y el DMA; a ti te entrega una interfaz ya enlazada y esperas que la vuelvas útil. Todo el peso del driver se concentra en esos dos callbacks, y en una disciplina que no perdona: la desconexión puede llegar en cualquier instante.

La id_table: a quién reclamo

El primer trozo de todo driver USB es la tabla que declara qué dispositivos captura. Cada entrada usa una macro que rellena los campos de struct usb_device_id y las banderas de coincidencia (match_flags) por ti: USB_DEVICE empareja por fabricante y producto, mientras que USB_INTERFACE_INFO captura toda una clase de dispositivos con independencia de quién los fabrique. La tabla termina siempre en una entrada vacía, el centinela que marca el final.

#include <linux/usb.h>

static const struct usb_device_id skel_ids[] = {
	{ USB_DEVICE(0x0525, 0xa4a5) },               /* por vendor y product */
	{ USB_INTERFACE_INFO(USB_CLASS_HID, 0, 0) },  /* o por clase de interfaz */
	{ }                                           /* centinela terminador */
};
MODULE_DEVICE_TABLE(usb, skel_ids);

MODULE_DEVICE_TABLE no es decorativa: exporta la tabla a los metadatos del módulo (modalias), y gracias a ella udev en espacio de usuario sabe cargar tu módulo automáticamente cuando se conecta un dispositivo que encaja. Sin esa línea tendrías que hacer modprobe a mano cada vez.

struct usb_driver y el registro

El driver propiamente dicho es una struct usb_driver que enlaza la tabla con los callbacks. Se registra con la macro module_usb_driver, que genera por ti el module_init y el module_exit llamando a usb_register y usb_deregister (el mismo patrón module_*_driver que viste en char devices, nivel 13).

static struct usb_driver skel_driver = {
	.name       = "usb-skel",
	.id_table   = skel_ids,
	.probe      = skel_probe,
	.disconnect = skel_disconnect,
	.suspend    = skel_suspend,     /* opcional: gestion de energia */
	.resume     = skel_resume,
	.supports_autosuspend = 1,
};
module_usb_driver(skel_driver);

Recuerda la lección de arquitectura: usbcore enlaza drivers a interfaces, no a dispositivos. Por eso .probe recibe una struct usb_interface y no una usb_device, y por eso una webcam puede tener tres drivers distintos activos a la vez sobre el mismo aparato físico.

probe: reclamar y preparar

.probe se ejecuta una vez que el dispositivo ya está enumerado y configurado. Su misión: decidir si reclamas la interfaz (devolviendo 0) o la rechazas (devolviendo un -errno), y si la reclamas, reservar tu estado privado, localizar los endpoints y anclar ese estado a la interfaz con usb_set_intfdata.

static int skel_probe(struct usb_interface *intf,
		      const struct usb_device_id *id)
{
	struct usb_device *udev = interface_to_usbdev(intf);
	struct usb_endpoint_descriptor *bulk_in, *bulk_out;
	struct usb_skel *dev;
	int ret;

	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
	if (!dev)
		return -ENOMEM;

	kref_init(&dev->kref);                 /* conteo propio, ver disconnect */
	dev->udev = usb_get_dev(udev);         /* +1 referencia al dispositivo */
	dev->intf = intf;

	ret = usb_find_common_endpoints(intf->cur_altsetting,
					&bulk_in, &bulk_out, NULL, NULL);
	if (ret) {
		dev_err(&intf->dev, "faltan los endpoints bulk esperados\n");
		goto error;
	}
	dev->bulk_in_addr  = bulk_in->bEndpointAddress;
	dev->bulk_out_addr = bulk_out->bEndpointAddress;

	usb_set_intfdata(intf, dev);           /* estado privado por interfaz */
	dev_info(&intf->dev, "usb-skel enlazado\n");
	return 0;

error:
	usb_put_dev(dev->udev);
	kfree(dev);
	return ret;                            /* rechaza la interfaz */
}

Si tu dispositivo debe aparecer en /dev, aquí añadirías usb_register_dev con una struct usb_class_driver para que el núcleo te reserve un minor y cree el nodo, tal como hace drivers/usb/usb-skeleton.c. La usb_get_dev incrementa el refcount del dispositivo para que la estructura no se libere mientras la usas.

disconnect: la simetría bajo fuego

.disconnect es la contraparte de .probe, pero se ejecuta en la circunstancia más hostil del kernel: el usuario ya ha arrancado el cable. El hardware puede haber desaparecido físicamente mientras tú tenías transferencias en vuelo. Tu deber es cortar toda E/S pendiente, soltar tus referencias y no volver a tocar el dispositivo jamás.

static void skel_disconnect(struct usb_interface *intf)
{
	struct usb_skel *dev = usb_get_intfdata(intf);

	usb_set_intfdata(intf, NULL);
	usb_kill_urb(dev->bulk_urb);        /* aborta E/S en vuelo (nivel 31.4) */
	usb_put_dev(dev->udev);             /* suelta la referencia de probe */
	kref_put(&dev->kref, skel_delete);  /* libera cuando el ultimo fd cierre */
	dev_info(&intf->dev, "usb-skel desenlazado\n");
}

El detalle fino es el conteo de referencias. Si expones un nodo en /dev, un programa puede tener el archivo abierto en el momento de la desconexión. No puedes liberar tu estado bajo sus pies: por eso se usa un kref que probe inicializa, cada open incrementa y cada release decrementa; la memoria se libera solo cuando cae la última referencia. Es el patrón kref del nivel 14 aplicado a la vida y muerte de un dispositivo físico.