linux-kernel - Re: [PATCH 3/3] IIO: st_accel.h: sync DT and I2C device ID table strings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1807020925290.31768@fox.voss.local>
Date:   Mon, 2 Jul 2018 09:32:46 +0200 (CEST)
From:   Nikolaus Voss <nikolaus.voss@...wensteinmedical.de>
To:     Jonathan Cameron <jic23@...nel.org>
cc:     Nikolaus Voss <nv@...n.de>, Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Lorenzo Bianconi <lorenzo.bianconi83@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Xiongfeng Wang <xiongfeng.wang@...aro.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] IIO: st_accel.h: sync DT and I2C device ID table
 strings

On Sat, 30 Jun 2018, Jonathan Cameron wrote:

> On Fri, 29 Jun 2018 10:45:54 +0200
> Nikolaus Voss <nikolaus.voss@...wensteinmedical.de> wrote:
>
>> I2C device ID table strings should really match the DT compatible
>> strings (without the manufacturer prefix) to avoid confusion. This is
>> especially reasonable when using ACPI PRP0001 HID /DT compatibility
>> entries along with the DT compatible property in DSD which is
>> used as a modalias (with manufacturer prefix stripped off) by the ACPI
>> layer and thus as i2c_board_info->type by the I2C layer.
>>
>> Signed-off-by: Nikolaus Voss <nikolaus.voss@...wensteinmedical.de>
>
> Nice to have I agree.  However, it's an ABI change as this is exposed
> via
> /sys/bus/iio/devices/iio:\deviceN/name and is used by lots of scripts
> etc to identify the device.  So we are stuck with it.
>
> There is a reason we've kept this mess here for quite some time.

Ok, I feared there could be some reason ;-). Tell me, if you want me to 
respin anything...

Niko