On Tue, 22 Feb 2022 09:42:12 +0200 Nandor Han <nandor.han@xxxxxxxxxxx> wrote: > On 2/20/22 15:18, Jonathan Cameron wrote: > > On Wed, 16 Feb 2022 15:56:04 +0200 > > Nandor Han <nandor.han@xxxxxxxxxxx> wrote: > > > > Thanks for reviewing the patch and provide feed back. > > >> The label property is used to correctly identify the same IIO device > >> over reboots. The implementation requires that a value will be provided > >> through device-tree. This sometime could requires many changes to > >> device-trees when multiple devices want to use the label property. > >> In order to prevent this, we could use the device-tree node > >> name as default value. The device-tree node name is unique and > >> also reflects the device which makes it a good choice as default value. > >> This change is backward compatible since doesn't affect the users that > >> do configure a label using the device-tree or the ones that are not > >> using the labels at all. > >> > >> Use the device-tree node name as a default value for `label` property, > >> in case there isn't one configured through device-tree. > > > > Interesting idea. However a few concerns come to mind. > > 1) If we start having a default for this, then it will get used as ABI > > and if a label is applied later to the DT then we will end up breaking > > userspace scripts. > > When a label is explicitly configured means that the userspace expects > to have that value available. Therefore, I don't see this as ABI change, > given that this affects the property label content and not for example > the property name. The potential issue is that with this userspace code may rely on the common option (matches device tree node name) and then get confused on it changing. If it wasn't there previously and appears (which is what happens when a label is added currently) userspace is unlikely to have in some fashion depended on it not being there... If someone modifies an existing label they can reasonably expect to break compatibility because they made something 'go away'. > > > 2) If we do this it should be firmware agnostics (we need to fix > > the existing code to be such as well). > > Not sure I understand this. If you could explain a bit more I would > really appriciate. Typo in that didn't help. (agnostic). Anyhow, basically it has to work for ACPI as well. > > > 3) Is the node name always unique (think multiple accelerometers on > > different i2c masters)? > > 3) I'm fairly sure this information is readily available anyway. > > either via the of_node link for the iio\:deviceX > > So why not have your usespace use that instead of label? > > I'm not a fan of duplicating information that is readily available > > anyway - be it as name and reg in the of_node directory. > > > > The node name supposed to be unique AFAIK and you're right it is > available already in the userspace. It's not unique. As per https://elinux.org/Device_Tree_Usage, "sibling nodes are expected to be unique". If you have multiple i2c masters and the same device under each of them with the same i2c address they are not siblings (different parents) and will have the same node name. > My point with this patch is to provide a default value for the label > content and I'm open to suggestions related to content. The of_node name > was something that I thought that is unique and easy to use, but if > somebody has better suggestions I'm really open to these. I don't see why we want a default label. If it's not provided it's not there (no file) and userspace can go use something else for it's unique naming. Note that for older kernels they need to do that anyway because label never existed. So userspace will need to work with possibility of it being absent. As userspace is going to do that today, why add another option so we have: 1) No label attribute. 2) Label attribute == node name 3) Label attribute something else vs having to handle 2 cases. 1) No label attribute 2) Label attribute present. So adding a default makes userspace code more complex, not less. Jonathan > > > Thanks, > > > > Jonathan > > > > <snip> > > > Thanks again and regards, > Nandor
