linux-kernel - Re: [PATCH 0/3] capebus moving omap

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: <509391CA.9040408@ti.com>
Date:	Fri, 2 Nov 2012 10:26:34 +0100
From:	"Cousson, Benoit" <b-cousson@...com>
To:	Jason Kridner <jkridner@...gleboard.org>
CC:	Tony Lindgren <tony@...mide.com>,
	Koen Kooi <koen@...inion.thruhere.net>, <paul@...an.com>,
	<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	"Porter, Matt" <mporter@...com>, Russ Dill <russ.dill@...il.com>,
	<khilman@...com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

Hi Jason,

On 11/1/2012 7:50 PM, Jason Kridner wrote:
> My apologies for starting a new thread, but I don't have this thread
> in my Inbox.
>
> http://www.spinics.net/lists/linux-omap/msg81034.html
>
> Tony Lindgren wrote:
>
>> * Pantelis Antoniou <panto@...xxxxxxxxxxxxxxxxxxxx> [121031 15:02]:
>>>
>>> So when device's node is 'disabled' of_platform_device_create_pdata()
>>> will not create the device.
>>>
>>> Now, of course it is possible to re-trigger the platform's probe method
>>> to be called, and in fact I do so in the capebus patches.
>>
>> You should fix this in generic way then rather than working
>> around it in capebus. The same problem exists changing
>> between different functionality for the shared pins,
>> let's say between USB pins and UART pins if you want a
>> serial debug console on some phone.
>
> The current capebus solution goes a long way to fixing a huge issue
> for BeagleBone users and I don't understand what seems to be a
> push-back on principle. On BeagleBone capes, these conflicts cannot be
> resolved early.

I don't think there is any push-back on the principle. It is a very 
valid problem that does not have any solution today.

The comments are more on the implementation.

> Do you have suggestions on some more generic method? It seems to me
> the proposed capebus approach strikes a good balance.

Well, yeah, that's a generic DT issue, not a beagle-cape issue.
We should not necessarily handle it by introducing some fake bus and 
some new binding like spi-dt / i2c-dt that does not mean anything in 
term of HW.

DT is about pure HW representation. Introducing some fake hierarchy to 
make SW life easier is not necessarily the good approach.

Adding the version information in the nodes is potentially a good idea, 
but should clearly be well thought and part of the DT core.

Regards,
Benoit

--
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/