[was iio: tmp006: Set correct iio name] how to support multiple instances of same device type

[Gregor Boirie <gregor.boirie@parrot.com>]

Just to let you know that I'm facing a problem to support multiple 
instances of
the ms5607 barometer onto the same board.

Referencing (i2c) id->name from indio_dev->name is not suitable in this 
case as
libiio and kernel iio tools such as generic_buffer all rely upon a 
unique iio
name to distinguish devices. Here is why.

generic_buffer expects a device name passed as argument to -n option
to get a reference to a device. In this case, it is not possible to
distinguish between devices holding the same name.

When libiio based apps use iio_context_find_device() to get a reference
to a device (by name), names should be unique across devices as above.
When retrieving a device reference by index through iio_context_get_device()
it is not possible to uniquely identify devices in a consistent way either.
Indeed, as indices assignment is automatically done at boot time, it is 
highly
dependent on module / driver loading ordering, devices / daughter board 
presence,
etc...
As a result, apps cannot assume indices are persistent across reboots.

Hence, using dev_name(&client->dev) to name a device is most certainly 
an acceptable
option despites inconsistencies it introduces with i2c name space.

I re-use device tree names to do the job. However, it will not work if 
not compiled
in (and needs patching). What would be a robust and generic naming 
solution then ?

On 05/01/2016 09:34 PM, Jonathan Cameron wrote:
> On 28/04/16 15:19, Lars-Peter Clausen wrote:
>> On 04/28/2016 03:30 PM, Peter Meerwald-Stadler wrote:
>>>>> It's clearly wrong. But the problem is there might be an application that
>>>>> depends on the wrong behavior, the driver has been around for 2.5 years. So
>>>>> it's difficult to fix. We might just go ahead in this case and take the
>>>>> chance that nobody will complain. But if somebody complains this will bring
>>>>> us the wrath of the Linus.
>>>> Not if you put it into next, test it, then into a new release as early as
>>>> possible (for -rc1), clearly document that it's got a user visible change
>>>> that should not matter with instructions if anyone hits this as a
>>>> bisection for their app failing to email so you know and can revert it.
>>> is this the only driver doing it wrong?
>>>
>>> pmeerw@pmeerw:/var/git/linux/drivers/iio$ rgrep "indio_dev->name = dev_name" .
>>> ./imu/inv_mpu6050/inv_mpu_core.c:		indio_dev->name = dev_name(dev);
>>> ./light/lm3533-als.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./dac/vf610_dac.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./dac/stx104.c:	indio_dev->name = dev_name(dev);
>>> ./dac/lpc18xx_dac.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/mcp3422.c:	indio_dev->name = dev_name(&client->dev);
>>> ./adc/at91-sama5d2_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/vf610_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/ti_am335x_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/nau7802.c:	indio_dev->name = dev_name(&client->dev);
>>> ./adc/da9150-gpadc.c:	indio_dev->name = dev_name(dev);
>>> ./adc/lpc18xx_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/rockchip_saradc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/imx7d_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/cc10001_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/berlin2-adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./adc/exynos_adc.c:	indio_dev->name = dev_name(&pdev->dev);
>>> ./temperature/tmp006.c:	indio_dev->name = dev_name(&client->dev);
>>> ./chemical/ams-iaq-core.c:	indio_dev->name = dev_name(&client->dev);
>>> ./chemical/vz89x.c:	indio_dev->name = dev_name(&client->dev);
>>> ./humidity/si7005.c:	indio_dev->name = dev_name(&client->dev);
>>> ./humidity/hdc100x.c:	indio_dev->name = dev_name(&client->dev);
>>> ./humidity/si7020.c:	indio_dev->name = dev_name(&client->dev);
>> Yes, they are all wrong. Mostly of it is just copy'n'paste. We need to be
>> more careful to catch these in the future.
>>
> <expletive deleted>  Lars is unfortunately right, I don't think
> we can unwind this mess now.  If it had been just one driver I'd
> have crossed my fingers and taken it - unfortunately this is way
> too many.
>
> Only way we could clean this up would be define new ABI with the
> intended value and deprecate the old one over a very very long time.
> Do we want to do this?
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html