> >> + strlcpy(reserved_client->name, I2C_DUMMY_DRV_NAME, sizeof(client->name)); > > Any strong reason for not giving the device a more informative name? Yes, sadly... > Reading "dummy" in several /sys/bus/i2c/devices/?-????/name files is not > helping. Using the 'name' string that is passed to > i2c_new_ancillary_device() would be way better, perhaps prefixed by > dev->name. But this opens the question of why not doing it in ... I never liked the plain "dummy" name as well. However, because 'name' is what we need to bind to a driver we can't have a more descriptive or run-time generated name at that place. > i2c_new_dummy_device() as well, which currently receives no "name" > parameter. I thought about it but discarded the idea because then you still have no connection to the driver which created the dummy device. My favourite idea so far is to advertise i2c_new_ancillary_device() instead of i2c_new_dummy_device(), because there we already have access to the client structure. With that, we could add another link in sysfs to the main address and vice-versa. > Of course this is not strictly related to this patch and can be done in > a later step. Exactly.
Attachment:
signature.asc
Description: PGP signature
