linux-kernel - Re: [PATCH 09/14] i2c: Add Device Tree support to the Nomadik I2C driver

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]

Date:	Wed, 13 Jun 2012 08:01:01 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linus.walleij@...ricsson.com, arnd@...db.de,
	grant.likely@...retlab.ca, linux-i2c@...r.kernel.org
Subject: Re: [PATCH 09/14] i2c: Add Device Tree support to the Nomadik I2C
 driver

On 13/06/12 06:40, Linus Walleij wrote:
> On Tue, Jun 12, 2012 at 9:34 AM, Lee Jones<lee.jones@...aro.org>  wrote:
>> On 11/06/12 21:37, Linus Walleij wrote:
>>>
>>> So why don't we create proper device tree bindings for the above platform
>>> data?
>>> (...)
>>> This looks to me like a way to push the burden of doing the real
>>> device tree binding for the above to the next user.
>>> (Which will likely be me, so therefore I care a bit ...)
>>
>>
>> On the contrary. This will avoid any added Device Tree complexity and ensure
>> that no extra vendor specific bindings are required. When a new user wishes
>> to use the driver, all they (you) have to do is create a new struct with the
>> platform specific information and add the entry to nmk_gpio_match[],
>> simples.
>>
>> I've even added the logic to extract any information you provide via
>> nmk_gpio_match[] for use as platform data. This keeps it both out of
>> platform code and the Device Tree binary. Everyone's a winner. :)
>
> No. You assume that the platform data is a chip-specific property,
> and that it will be the same for all busses on the chip. But it
> isn't.
>
> The above platform data is *board specific*, it depends on
> what devices have been connected to each bus.
>
> For example the max frequency: this depends on the maximum
> frequency any of the devices connected to one very bus
> can support.
>
> The other platforms have put this frequency into their device
> trees for a reason, and this is it.
>
> So for the four different i2c busses there may need to be
> four different platform data sets. How are you going to
> distinguish between the four buses?
>
> This is thus broken and needs to have proper bindings.

Board specific is fine, as the data is protected by a board specific 
property. Do you mean that the properties are *bus specific*? In which 
case I see your point and will apply the correct bindings.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/