On Tuesday 24 July 2012, Stephen Warren wrote:
> > One would think that, but the of_address handling code actually treats
> > empty ranges the same as missing ranges, in violation of the spec,
> > and as a workaround to deal with some powermac machines that required
> > this.
> >
> > I'd rather fi
On 07/24/2012 12:48 PM, Arnd Bergmann wrote:
> On Tuesday 24 July 2012, Stephen Warren wrote:
>>
>> That makes the child nodes' reg property slightly more complex since I
>> don't get to elide the size cell, but does mean that we don't have to
>> change anything (code or bindings) at all to make it
On Tuesday 24 July 2012, Stephen Warren wrote:
>
> That makes the child nodes' reg property slightly more complex since I
> don't get to elide the size cell, but does mean that we don't have to
> change anything (code or bindings) at all to make it work. I guess the
> lack of any ranges property w
I don't recall us getting any real conclusion out of this thread. How
about I drop the enumerated-bus concept and just use simple-bus, and
have reg be 2 cells (addr, size) in the child nodes:
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
On 07/03/2012 01:02 PM, Mitch Bradley wrote:
> On 7/3/2012 5:45 AM, Stephen Warren wrote:
>> On 07/03/2012 09:43 AM, Segher Boessenkool wrote:
> There is still no reason for the fake bus node to have a "compatible"
> property though. What could it possibly mean? "This bus does not
> e
On 7/3/2012 5:45 AM, Stephen Warren wrote:
On 07/03/2012 09:43 AM, Segher Boessenkool wrote:
There is still no reason for the fake bus node to have a "compatible"
property though. What could it possibly mean? "This bus does not
exist at all but you access it in bla bla bla way"? That just doe
On 07/03/2012 09:43 AM, Segher Boessenkool wrote:
>>> There is still no reason for the fake bus node to have a "compatible"
>>> property though. What could it possibly mean? "This bus does not
>>> exist at all but you access it in bla bla bla way"? That just doesn't
>>> make sense. It doesn't e
On 07/03/2012 08:00 AM, Segher Boessenkool wrote:
>>> Why would you want to instantiate devices that you cannot address
>>> at all anyway? The only driver that can know what to do with the
>>> device node is the driver for the device that has the phandle
>>> reference to it; it can instantiate it.
There is still no reason for the fake bus node to have a "compatible"
property though. What could it possibly mean? "This bus does not
exist at all but you access it in bla bla bla way"? That just
doesn't
make sense. It doesn't exist, you do not access it, it has no
programming model, it ha
On Tue, Jul 03, 2012 at 04:00:37PM +0200, Segher Boessenkool wrote:
> So you *can* address the device, you just don't want to show that
> in the device tree (I don't blame you, it's quite impossible to
> design a sane addressing scheme for this, all this stuff is so
> ad-hoc). I see. You could m
Why would you want to instantiate devices that you cannot address
at all anyway? The only driver that can know what to do with the
device node is the driver for the device that has the phandle
reference to it; it can instantiate it.
It's not a single device referencing it, it's multiple devices
On Tue, Jul 03, 2012 at 02:27:15AM +0200, Segher Boessenkool wrote:
> Why would you want to instantiate devices that you cannot address
> at all anyway? The only driver that can know what to do with the
> device node is the driver for the device that has the phandle
> reference to it; it can inst
So what is the issue? You have some node (the "bus node") under
which
you have the "regulator@0", "frobnicator@1" etc. nodes. You refer to
these device nodes by phandle always, you cannot programmatically
control those devices (otherwise, they should be child node of a
*real*
bus node). Th
On 07/02/2012 04:37 PM, Grant Likely wrote:
> On Mon, Jul 2, 2012 at 4:28 PM, Stephen Warren wrote:
>> On 07/02/2012 03:43 PM, Grant Likely wrote:
>>> On Mon, Jul 2, 2012 at 9:59 AM, Stephen Warren
>>> wrote:
On 07/01/2012 04:03 PM, Grant Likely wrote:
...
> Besides; if they are en
On Mon, Jul 2, 2012 at 4:28 PM, Stephen Warren wrote:
> On 07/02/2012 03:43 PM, Grant Likely wrote:
>> On Mon, Jul 2, 2012 at 9:59 AM, Stephen Warren wrote:
>>> On 07/01/2012 04:03 PM, Grant Likely wrote:
>>> ...
Besides; if they are enumerated, non-memory mapped devices, then is it
rea
On 07/02/2012 03:43 PM, Grant Likely wrote:
> On Mon, Jul 2, 2012 at 9:59 AM, Stephen Warren wrote:
>> On 07/01/2012 04:03 PM, Grant Likely wrote:
>> ...
>>> Besides; if they are enumerated, non-memory mapped devices, then is it
>>> really appropriate to use platform_{device,driver}? I don't think
On 07/02/2012 03:44 PM, Segher Boessenkool wrote:
>> But don't get too hung up on regulators; there are plenty of other
>> devices that can exist in DT that aren't memory-mapped; GPIO-keys,
>> aggregate sound complexes, perhaps WiFi/rfkill nodes, etc. All are
>> affected by the same DT representati
On Mon, Jul 2, 2012 at 1:41 PM, Stephen Warren wrote:
> On 07/02/2012 12:36 PM, Mitch Bradley wrote:
>> On 7/2/2012 7:43 AM, Stephen Warren wrote:
>>> On 07/02/2012 11:23 AM, Mitch Bradley wrote:
On 7/2/2012 5:59 AM, Stephen Warren wrote:
> On 07/01/2012 01:36 PM, Rob Herring wrote:
>
But don't get too hung up on regulators; there are plenty of other
devices that can exist in DT that aren't memory-mapped; GPIO-keys,
aggregate sound complexes, perhaps WiFi/rfkill nodes, etc. All are
affected by the same DT representation issue.
So what is the issue? You have some node (the "b
On Mon, Jul 2, 2012 at 9:59 AM, Stephen Warren wrote:
> On 07/01/2012 01:36 PM, Rob Herring wrote:
>> On 06/28/2012 06:05 PM, Stephen Warren wrote:
>>> From: Stephen Warren
>>>
>>> An "enumerated" bus is one that is not memory-mapped, hence hence
>>> typically has #address-cells=1, and #size-cell
On 07/02/2012 12:36 PM, Mitch Bradley wrote:
> On 7/2/2012 7:43 AM, Stephen Warren wrote:
>> On 07/02/2012 11:23 AM, Mitch Bradley wrote:
>>> On 7/2/2012 5:59 AM, Stephen Warren wrote:
On 07/01/2012 01:36 PM, Rob Herring wrote:
> On 06/28/2012 06:05 PM, Stephen Warren wrote:
>> From: S
On 7/2/2012 7:43 AM, Stephen Warren wrote:
On 07/02/2012 11:23 AM, Mitch Bradley wrote:
On 7/2/2012 5:59 AM, Stephen Warren wrote:
On 07/01/2012 01:36 PM, Rob Herring wrote:
On 06/28/2012 06:05 PM, Stephen Warren wrote:
From: Stephen Warren
An "enumerated" bus is one that is not memory-mapp
On 07/02/2012 11:23 AM, Mitch Bradley wrote:
> On 7/2/2012 5:59 AM, Stephen Warren wrote:
>> On 07/01/2012 01:36 PM, Rob Herring wrote:
>>> On 06/28/2012 06:05 PM, Stephen Warren wrote:
From: Stephen Warren
An "enumerated" bus is one that is not memory-mapped, hence hence
typic
On 7/2/2012 5:59 AM, Stephen Warren wrote:
On 07/01/2012 01:36 PM, Rob Herring wrote:
On 06/28/2012 06:05 PM, Stephen Warren wrote:
From: Stephen Warren
An "enumerated" bus is one that is not memory-mapped, hence hence
typically has #address-cells=1, and #size-cells=0. Such buses would be
use
On 07/01/2012 01:36 PM, Rob Herring wrote:
> On 06/28/2012 06:05 PM, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> An "enumerated" bus is one that is not memory-mapped, hence hence
>> typically has #address-cells=1, and #size-cells=0. Such buses would be
>> used to group related non-memory-m
On Sun, Jul 1, 2012 at 1:36 PM, Rob Herring wrote:
> On 06/28/2012 06:05 PM, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> An "enumerated" bus is one that is not memory-mapped, hence hence
>> typically has #address-cells=1, and #size-cells=0. Such buses would be
>> used to group related non
On 06/28/2012 06:05 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> An "enumerated" bus is one that is not memory-mapped, hence hence
> typically has #address-cells=1, and #size-cells=0. Such buses would be
> used to group related non-memory-mapped nodes together, often just under
> the top-
From: Stephen Warren
An "enumerated" bus is one that is not memory-mapped, hence hence
typically has #address-cells=1, and #size-cells=0. Such buses would be
used to group related non-memory-mapped nodes together, often just under
the top-level of the device tree. The ability to group nodes into
28 matches
Mail list logo
