Come devono essere abbinati i driver I2C in ACPI con HID PRP0001

Question

Sto cercando di istanziare questo sensore in ACPI utilizzando dati specifici del dispositivo, ovvero con Name (_DSD, ...)e con una stringa compatibile, ad es. Con il seguente estratto ASL:

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"},
        }
    })
}

Avevo l'impressione che se specifichi i miei dispositivi come ho nell'ASL sopra, non avrei bisogno di modificare il driver (ad esempio, aggiungendo una tabella delle corrispondenze ACPI) e potrei abbinare il dispositivo utilizzando la tabella delle corrispondenze OF esistente nella conducente. Tuttavia, questo sembra vero solo in parte. Il sensore non riesce a sondare a causa di questo controllo nel kernel in 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;

La mia interpretazione di questa affermazione è che il driver del dispositivo deve avere (i) una tabella ID o (ii) una tabella ID ACPI corrispondente o (iii) una tabella ID corrispondente. Il VL53L0X non ha una tabella ID né una tabella delle corrispondenze ACPI, quindi mi affido alla corrispondenza utilizzando la tabella OF.

Ora, ci sono due cose su cui sono confuso qui. In primo luogo, posso printk(KERN_ERR "%s", dev->driver->driver.name)e vedo che sto già guardando il driver corretto, quindi perché stiamo controllando esattamente se il driver corrisponde di nuovo?

In secondo luogo, se i2c_of_match_device(dev->driver->of_match_table, client)non riesce a corrispondere, cosa è stato trovato esattamente in primo luogo che ha portato alla possibilità di printk(KERN_ERR "%s", dev->driver->driver.name)vedere il nome corretto dell'autista?

Answer 1

Non è proprio una risposta alla domanda sopra, ma un trucco / soluzione per questo problema è semplicemente aggiungere la tabella ID al driver.

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);

In questo modo il controllo della domanda viene ignorato. Questa non è un'ottima soluzione poiché la tabella ID I2C non viene passata probe_new, tuttavia, funziona per questo driver poiché non è necessario eseguire ulteriori configurazioni.

Sembra tuttavia che la corrispondenza di dispositivi i2c come questo sia stata deprecata in base ai commenti e alle patch sull'introduzione di probe_new.