Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] When a device binds via `driver_override`, the PCI core passes a generic `pci_device_id_any` struct with `driver_data` set to 0. Passing this NULL pointer to the `%s` format specifier results in an unhandled `(null)` log output. --
commit cefd4bbcd02b1f8d8a6df6f9aa562b23cee64272 Author: Gary Guo <[email protected]> agp/via: don't rely on address of pci_device_id Address of pci_device_id cannot be relied on due to presence of dynamic ID and driver_override. Use driver_data instead. > diff --git a/drivers/char/agp/via-agp.c b/drivers/char/agp/via-agp.c > index 8b19a5d1a09b4..ab3b73dd080af 100644 > --- a/drivers/char/agp/via-agp.c > +++ b/drivers/char/agp/via-agp.c [ ... ] > @@ -437,17 +239,14 @@ static void check_via_agp3 (struct agp_bridge_data > *bridge) > > static int agp_via_probe(struct pci_dev *pdev, const struct pci_device_id > *ent) > { > - struct agp_device_ids *devs = via_agp_device_ids; > struct agp_bridge_data *bridge; > - int j = 0; > u8 cap_ptr; > > cap_ptr = pci_find_capability(pdev, PCI_CAP_ID_AGP); > if (!cap_ptr) > return -ENODEV; > > - j = ent - agp_via_pci_table; > - printk (KERN_INFO PFX "Detected VIA %s chipset\n", > devs[j].chipset_name); > + dev_info(&pdev->dev, "Detected VIA %s chipset\n", (const char > *)ent->driver_data); [Severity: Low] Could this result in printing a (null) value to the kernel log? If an administrator forces binding of the driver to a device using the sysfs driver_override feature, the PCI core passes a generic pci_device_id_any struct with driver_data set to 0. Passing this NULL pointer to the %s format specifier in dev_info() would print (null) in the kernel logs instead of a valid string. Is it possible to check ent->driver_data for NULL before attempting to print it, or fall back to a default string? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
