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: <8ee77b5f79ee0c0c5ead1f0acbe95bda@kernel.crashing.org>
Date:	Fri, 29 Jun 2007 11:05:56 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	"Zhang Wei-r63237" <Wei.Zhang@...escale.com>
Cc:	<linux-kernel@...r.kernel.org>, <mporter@...nel.crashing.org>,
	<paulus@...ba.org>, <linuxppc-dev@...abs.org>
Subject: Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.

>>> +    - #address-cells : Address representation for
>> "rapidio" devices.
>>> +      This field represents the number of cells needed to represent
>>> +      the RapidIO address of the registers.  For
>> supporting more than
>>> +      32-bits RapidIO address, this field should be <2>.
>>> +      See 1) above for more details on defining #address-cells.
>>
>> What does the RapidIO standard say about number of address
>> bits?  You want to follow that, so all RapidIO devices can
>> use the same #address-cells, not just the FSL ones.  Also,
>> are there different kinds of address spaces on the bus, or
>> is it just one big memory-like space?
>
> I've checked the specification of RapidIO. The supporting of RapidIO
> extended address modes are 66, 50 and 34 bit.

These three are all two bits more than some "regular" size --
do those two extra bits have some special meaning perhaps,
like an address space identifier or something?

> The Freescale's silicons is only support 34 bit address now.
> Do you mean I should not use words -- 'should be <2>'?
> The #address-cells should be assigned according the address mode
> supported by silicon.

No.  The #address-cells is determined by the bus binding,
so that all RapidIO busses on the planet can be represented
in a similar way in the OF device tree.  Take for example
the PCI binding, which gives you three address cells -- one
to distinguish between different address spaces (configuration
space, legacy I/O space, memory mapped space) and to contain
some flags (prefetchable vs. non-prefetchable, etc.); the
other two 32-bit cells contain a 64-bit address, although
config and legacy I/O never are more than 32 bit, and many
PCI devices can't do 64-bit addressing at all.

Now, there is no OF binding for RapidIO yet of course, but
it would be good to start thinking about one while doing
the binding for your specific controller -- it will make
life easier down the line for everyone, including yourself.


Segher

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ