> Are you saying that FreeBSD has a different set of bindings for the
> same hardware?
Yes. I was not even aware FreeBSD was using DT until somebody
mentioned it in Edinburgh.
As an example:
http://fxr.watson.org/fxr/source/boot/fdt/dts/sheevaplug.dts
compared with
http://lxr.linux.no/linux+v
On Monday 06 January 2014, Andrew Lunn wrote:
> This raises the question, should mainline try to support any random
> dtb blob, or only those that have ever shipped with mainline?
It should support any dtb that conforms to the binding.
> There are some older mainline DT blobs which won't have PCI
On 01/06/2014 03:39 AM, Jingoo Han wrote:
> Use devm_*() functions to make cleanup paths simpler.
>
> Signed-off-by: Jingoo Han
> ---
> Changes since V1:
> - Use devm_ioremap_resource() to make the code simpler, per Wolfram Sang.
>
> drivers/i2c/busses/i2c-pnx.c | 60
> ++
On 05/01/2014 15:25, Arnd Bergmann wrote:
> On Friday 03 January 2014, Gregory CLEMENT wrote:
>> All the mvebu SoCs have information related to their variant and
>> revision that can be read from the PCI control register.
>>
>> This patch adds support for Armada XP and Armada 370. This reading of
>
On 06/01/2014 10:55, Gregory CLEMENT wrote:
> Hi Andrew,
>
> On 06/01/2014 01:17, Andrew Lunn wrote:
> Does that power down really disable reading from PCIe controller
> registers or is it just PHY power down?
I haven't experimented with it, but every block that has a clock gate
Hi Andrew,
On 06/01/2014 01:17, Andrew Lunn wrote:
Does that power down really disable reading from PCIe controller
registers or is it just PHY power down?
>>>
>>> I haven't experimented with it, but every block that has a clock gate
>>> has a power down, so I doubt it is just a phy powe
Hi Arnd,
On 05/01/2014 15:33, Arnd Bergmann wrote:
> On Friday 03 January 2014, Gregory CLEMENT wrote:
>> The first variants of Armada XP SoCs (A0 stepping) have issues related
>> to the i2c controller which prevent to use the offload mechanism and
>> lead to a kernel hang during boot.
>>
>> The d
