Comment les pilotes I2C doivent-ils être adaptés dans l'ACPI avec HID PRP0001 ?

Question

J'essaie d'instancier ce capteur dans l'ACPI en utilisant des données spécifiques à l'appareil, c'est-à-dire, avec Name (_DSD, ...) et avec une chaîne compatible, par exemple avec l'extrait ASL suivant :

Device (TOF1) {
    Name (_HID, "PRP0001")
    Name (_DDN, "STMicroelectronics VL53L0X laser rangefinder")
    Name (_CRS, ResourceTemplate () {
        I2cSerialBus (
            0x29,
            ControllerInitiated,
            I2C_SPEED,
            AddressingMode7Bit,
            "\\_SB.PCI0.I2C1.MUX2.CH01",
            0x00,
            ResourceConsumer,,)
    })
    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () {"compatible", "st,vl53l0x"},
        }
    })
}

J'avais l'impression que si je spécifiais mes périphériques comme je l'ai fait dans l'ASL ci-dessus, je n'aurais pas besoin de modifier le pilote (par exemple, en ajoutant une table de correspondance ACPI) et je pourrais faire correspondre le périphérique en utilisant la table de correspondance OF existante dans le pilote. Cependant, cela ne semble que partiellement vrai. Le capteur ne parvient pas à sonder en raison de cette vérification dans le noyau en i2c-core-base.c :

if (!driver->id_table &&
    !i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
    !i2c_of_match_device(dev->driver->of_match_table, client))
    return -ENODEV;

Mon interprétation de cette déclaration est que le pilote du périphérique doit avoir soit (i) une table d'identification, soit (ii) une table d'identification ACPI correspondante, soit (iii) une table d'identification OF correspondante. Le VL53L0X n'a pas de table d'identification ni de table de correspondance ACPI, je me fie donc à la correspondance en utilisant la table OF.

Il y a deux choses qui me laissent perplexe. Premièrement, je peux printk(KERN_ERR "%s", dev->driver->driver.name) et je vois que je suis en effet déjà en train de regarder le bon pilote, alors pourquoi exactement vérifions-nous si le pilote correspond à nouveau ?

Deuxièmement, si i2c_of_match_device(dev->driver->of_match_table, client) n'arrive pas à correspondre, qu'est-ce qui a été mis en correspondance en premier lieu et qui a permis à l'entreprise d'être en mesure d'obtenir des informations sur l'état de santé de ses clients ? printk(KERN_ERR "%s", dev->driver->driver.name) et voir le nom correct du conducteur ?

Answer 1

Ce n'est pas vraiment une réponse à la question ci-dessus, mais un moyen de contourner ce problème est d'ajouter la table ID au pilote.

static const struct i2c_device_id vl53l0x_id[] = {
    { "vl53l0x", 0 },
    { }
};
MODULE_DEVICE_TABLE(i2c, vl53l0x_id);

static struct i2c_driver vl53l0x_driver = {
    .driver = {
        .name = "vl53l0x-i2c",
        .of_match_table = st_vl53l0x_dt_match,
    },
    .probe_new = vl53l0x_probe,
    .id_table = vl53l0x_id,
};
module_i2c_driver(vl53l0x_driver);

Le contrôle de la question est alors ignoré. Ce n'est pas une très bonne solution car la table des identifiants I2C n'est pas transmise à probe_new Cependant, cela fonctionne pour ce pilote puisqu'il n'y a pas d'autre configuration à faire.

Il semble cependant que l'appariement de dispositifs i2c comme celui-ci soit déprécié, comme le montrent les commentaires et les correctifs autour de l'introduction de probe_new .