Re: [LINUX PATCH] iio: xadc: fix for extended name remains same issue

[Ranjit Abhimanyu Waghmode <ranjit.waghmode@xilinx.com>]

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]



On 11/24/2015 1:14 PM, Lars-Peter Clausen wrote:
> On 11/24/2015 07:17 AM, Ranjit Waghmode wrote: >> If we read channel details based on the device tree entry; channel’s scan_index >> and channel’s address were overwritten by scan_index and address of channel >> based on device tree. But extended name were remaining same because of which >> sysfs entry names were continuous. > > I don't understand this part. Those channels don't have a extended name, > they are always NULL. Those are added as part of this patch as well, but the > patch description makes it sound like it is a fix for a existing issue. > >

Sorry about the confusing description.

Actually when we try to enable the external channels in XADC by adding
entries in dts, we can see that the channel numbers are not considered
and they are taken as entries.

For e.g if we have entries in device tree like below:

xlnx,channels {
    #address-cells = <1>;
    #size-cells = <0>;

    channel@3 {
        reg = <3>;
    };
    channel@1 {
        reg = <1>;
    };
    channel@4 {
        reg = <4>;
    };
    channel@5 {
        reg = <5>;
    };
    channel@7 {
        reg = <7>;
    };
    channel@8 {
        reg = <8>;
    };
    channel@9 {
        reg = <9>;
    };
};


Then here observed that channel's scan_index and channel's address are
getting overwritten by scan_index of channel based on the device tree
entry. But the extended name remains same that is why it shows names are
continuous. It seems difficult to follow the VPVN and AUX channel
entries in sysfs entries.

>> >> So this patch takes care of the above issue by updating 'channels' structure >> inside xadc_parse_dt() function with the help of 'xadc_channels' structure >> so that every channel's parameters will be updated properly. Also for the >> sake of simplicity this patch updates default values for extend_name. > > We can't really do that, that would break existing applications. And to be > honest I don't think regular channels should have a extended name. >

So based on the above description of problem I tried to update the code.
But if you feel that it is not the ideal way of doing then can you please
help me in understanding how could I overcome this issue.

Regards,
Ranjit


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


[-- Attachment #2: Type: text/html, Size: 3796 bytes --]