linux-kernel - Re: [PATCH 4/4] eeprom: at24: Add OF device ID table

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: <21663b26-8581-b8d6-7bab-7e7b65798a6a@osg.samsung.com>
Date:   Thu, 16 Mar 2017 12:39:29 -0300
From:   Javier Martinez Canillas <javier@....samsung.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-i2c@...r.kernel.org, Lee Jones <lee.jones@...aro.org>,
        Kieran Bingham <kieranbingham@...il.com>
Subject: Re: [PATCH 4/4] eeprom: at24: Add OF device ID table

Hello Wolfram,

On 03/16/2017 12:05 PM, Wolfram Sang wrote:
> 
>>> Rob into the boat if he is OK with updating all DTS files having such an
>>> EEPROM.
>>>
>>
>> Agreed, are you going to take care of that?
> 
> Nope, sorry, no bandwidth. You might ask Lee, he was very interested in
> getting proper I2C OF support upstream.
>

Ok, understandable. Adding Lee and Kieran to cc who were also interested on this.
 
>> up on this task, it has been a big time sink and I had to explain over and over
>> to different people what the problem is with the I2C modalias uevent reporting.
> 
> Next time, maybe do a wiki page and point people to it? That being said,
> we should probably create a wiki page on the I2C wiki anyhow.
> Documenting the current state of affairs. That I would do when I finally
> get around to brush up I2C wiki.
> 

Agreed, I can help writing such a wiki page if you want. I've already requested for
an account at https://i2c.wiki.kernel.org.

>> But it seems that for many maintainers this is just an unnecessary churn and they
>> don't think there's an issue with the current behaviour. So it feels I'm causing
>> more harm than good by keep pushing this.
> 
> I understand somehow. They probably were reluctant to change something

Yes, I don't blame them. It's kind of corner case that most people don't hit it.

One problem though is that this implementation detail leaks into the DTS and DT
binding documents, as we saw people using compatible strings without a vendor
prefix just because they could.

> that is working, even if it is not pretty. I'm not saying it's not worth
> it, yet one needs energy and motivation to push it through.
> 

Yeah, I think I've the energy and motivation but unfortunately also not enough
time :) And likely to have even less time in the near future.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America