linux-kernel - Re: [PATCH 1/4] i2c: busses: i2c-st: Add ST I2C controller

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] [day] [month] [year] [list]

Message-ID: <524C2617.5070401@st.com>
Date:	Wed, 2 Oct 2013 15:56:39 +0200
From:	Maxime COQUELIN <maxime.coquelin@...com>
To:	Pawel Moll <pawel.moll@....com>
Cc:	Wolfram Sang <wsa@...-dreams.de>,
	Stephen Warren <swarren@...dotorg.org>,
	Srinivas KANDAGATLA <srinivas.kandagatla@...com>,
	Rob Herring <rob.herring@...xeda.com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Landley <rob@...dley.net>,
	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	Stephen GALLIMORE <stephen.gallimore@...com>,
	Stuart MENEFY <stuart.menefy@...com>,
	Lee Jones <lee.jones@...aro.org>,
	Gabriel FERNANDEZ <gabriel.fernandez@...com>,
	"kernel@...inux.com" <kernel@...inux.com>
Subject: Re: [PATCH 1/4] i2c: busses: i2c-st: Add ST I2C controller

Hi Pawel,

On 10/02/2013 11:35 AM, Maxime Coquelin wrote:
>
> On 10/02/2013 11:02 AM, Wolfram Sang wrote:
>>>>> +Optional properties :
>>>>> +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width 
>>>>> that is allowed
>>>>> +  through the deglitch circuit. In units of us.
>>>>> +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width 
>>>>> that is allowed
>>>>> +  through the deglitch circuit. In units of us.
>>>> Are those properties specific to this binding, or intended to be
>>>> generic? If specific to this binding, a vendor prefix should be 
>>>> present
>>>> in the property name. If not, you probably want to document the
>>>> properties in some common file.
>>> Ok.
>>> In last revision, I put this properties as specific to this binding.
>>> Wolfram proposed to make this generic, but it looks like this IP is the
>>> only one
>>> needing such properties.
>>>
>>> Wolfram, what would you advise?
>> It might be the only SoC now, but I could imagine that other will have
>> something similar in the future. I am not perfectly sure, though. So, I
>> asked for opinions from DT experts when I suggested those bindings. We
>> could start with vendor specific bindings and generalize them later if
>> similar ones appear. Yet my experience is that old drivers rarely get
>> converted to the new bindings.
> Ok.
> But if I start with vendor specific bindings, we will have to support it
> forever, right?
I would be glad to have your opinion on this.

Since there are no other vendors currently having this feature,
should we put these properties vendor specific?
Or put them generic in case of someone has the same feature in the future?

Thanks,
Maxime

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/