El emparejamiento por compatible: cómo el nodo encuentra su driver

Tenemos un nodo del device tree que dice ser una acme,uart-9000 y tenemos un driver capaz de manejar esa familia. Falta el casamentero: el mecanismo que empareja ambos y dispara probe. En el mundo de PCI ese emparejamiento era numérico, por vendor:device id. En el device tree es textual: una cadena en la propiedad compatible del nodo contra una tabla de cadenas en el driver. Esa cadena es toda la superficie de contacto entre el silicio y el código, y entender cómo se compara es entender cómo Linux arranca en hardware que nunca vio antes.

compatible: la clave del emparejamiento

La propiedad compatible es una lista ordenada de cadenas, de la más específica a la más genérica. Un nodo puede declarar:

uart0: serial@50000000 {
	compatible = "acme,uart-9000", "acme,uart-generic";
	reg = <0x50000000 0x1000>;
	interrupts = <0 42 4>;
};

Esto significa: soy exactamente una acme,uart-9000, pero si no hay un driver para ese modelo concreto, soy compatible con el genérico acme,uart-generic. El kernel busca driver para la primera cadena; si nadie la reclama, prueba la siguiente. Ese fallback es lo que permite que un driver genérico maneje hardware que salió al mercado después de escribirse, siempre que el fabricante prometa compatibilidad en la lista. La convención fabricante,modelo evita colisiones: el prefijo identifica al fabricante en un registro común.

of_match_table y of_device_id

El driver publica las cadenas que sabe manejar en una tabla de struct of_device_id, terminada por un centinela vacío, y la enlaza en .driver.of_match_table. El macro MODULE_DEVICE_TABLE(of, ...) copia esas cadenas a los metadatos del módulo para que depmod construya el mapa que permite el autoload: cuando aparece un nodo con ese compatible, udev carga el módulo correcto sin intervención.

static const struct of_device_id acme_of_match[] = {
	{ .compatible = "acme,uart-9000" },
	{ .compatible = "acme,uart-generic" },
	{ /* centinela: el bucle de comparacion para al ver .compatible nulo */ }
};
MODULE_DEVICE_TABLE(of, acme_of_match);   /* habilita el autoload por udev */

static struct platform_driver acme_driver = {
	.probe  = acme_probe,
	.remove = acme_remove,
	.driver = {
		.name           = "acme-uart",
		.of_match_table = acme_of_match,
	},
};

El baile del match: quién empareja con quién

Cuando aparece un nuevo platform_device —o un nuevo driver— el bus recorre el otro lado buscando pareja, y para cada candidato llama a platform_match. Esta función encierra el orden de prioridad exacto del kernel, y merece leerse tal cual está en drivers/base/platform.c:

static int platform_match(struct device *dev, const struct device_driver *drv)
{
	struct platform_device *pdev = to_platform_device(dev);
	struct platform_driver *pdrv = to_platform_driver(drv);

	/* 1. anulacion manual desde el usuario (driver_override) */
	if (pdev->driver_override)
		return !strcmp(pdev->driver_override, drv->name);

	/* 2. por device tree: compara compatible contra of_match_table */
	if (of_driver_match_device(dev, drv))
		return 1;

	/* 3. por ACPI, para el hardware no enumerable de x86 */
	if (acpi_driver_match_device(dev, drv))
		return 1;

	/* 4. por la id_table del propio platform driver */
	if (pdrv->id_table)
		return platform_match_id(pdrv->id_table, pdev) != NULL;

	/* 5. ultimo recurso: por nombre, el metodo de los board files */
	return !strcmp(pdev->name, drv->name);
}

El orden no es casual. Primero manda la anulación explícita del usuario. Luego el device tree, la vía moderna. Después ACPI, su equivalente en x86. Solo si nada de eso aplica se recurre a la id_table y, en último extremo, a la comparación de nombres cruda que heredamos de los board files. of_driver_match_device recorre la of_match_table del driver y, por cada entrada, comprueba si alguna de las cadenas compatible del nodo coincide, prefiriendo siempre la coincidencia más específica.

flowchart TB
NODO[Nodo del device tree con compatible] -->|aparece en el platform bus| BUS[platform_match]
DRV[platform_driver con of_match_table] -->|se registra| BUS
BUS -->|of_driver_match_device compara cadenas| DEC[Alguna compatible coincide]
DEC -->|si| PROBE[El core llama a probe del driver]
DEC -->|no| SIG[Sigue probando otros drivers]

De la tabla a probe: of_device_get_match_data

El emparejamiento por device tree ofrece un regalo que la comparación por nombre no puede: llevar datos por variante hasta probe. Cada of_device_id tiene un campo .data opaco donde puedes colgar una estructura de configuración por modelo. En probe, of_device_get_match_data te devuelve el .data de la entrada que casó, y así un mismo driver ajusta su comportamiento según qué variante de hardware describió el nodo, sin una sola cadena de if comparando modelos.

struct acme_config {
	unsigned int	fifo_depth;
	bool		tiene_dma;
};

static const struct acme_config cfg_9000 = { .fifo_depth = 16, .tiene_dma = false };
static const struct acme_config cfg_9100 = { .fifo_depth = 64, .tiene_dma = true  };

static const struct of_device_id acme_of_match[] = {
	{ .compatible = "acme,uart-9000", .data = &cfg_9000 },
	{ .compatible = "acme,uart-9100", .data = &cfg_9100 },
	{ }
};
MODULE_DEVICE_TABLE(of, acme_of_match);

static int acme_probe(struct platform_device *pdev)
{
	const struct acme_config *cfg;

	cfg = of_device_get_match_data(&pdev->dev);   /* el .data de la entrada que caso */
	if (!cfg)
		return -ENODEV;

	dev_info(&pdev->dev, "fifo de %u entradas, dma=%d\n",
		 cfg->fifo_depth, cfg->tiene_dma);
	return 0;
}