* Problem with 64-bit variables on ppc405
From: Mirek23 @ 2007-11-19 20:37 UTC (permalink / raw)
To: linuxppc-embedded
Dear All,
I have successfully build crosstools (gcc-4.0.2-glibc-2.3.2) for my ppc 405
processor (part of xilinx virtex-4). I have compiled the Linux kernel
2.6.23rc2 and busy box 1.4.2.
All together works fin but I am facing the problem with the variables
declared in C as double and long long.
Doubles and long long are 8 bytes long but the byte order
differs on my host linux Intel PC from this what I have on the target linux
ppc 405.
double , long long byte order looks like below:
linux intel x86 ppc405
1,2,3,4,5,6,7,8 5,6,7,8,1,2,3,4
int and long types in 'C' (4 byte variables) have the same byte order on
both platforms.
It seems to be that 64-bit variables have different order. I do not know if
it comes from:
1. the configuration of the crosstools (ie. the way how the gcc and glibc is
built)
2. the kernel configuration.
The ppc 405 does not have the FPU built in so I have set in the kernel:
processor->math emulation
I did not set anything concerning FPU in Crosstools.
The Crosstools configuration file demo-powerpc-405.sh looks like:
#!/bin/sh
# This script has one line for each known working toolchain
# for this architecture. Uncomment the one you want.
# Generated by generate-demo.pl from buildlogs/all.dats.txt
set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES
# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP
eval `cat powerpc-405.dat gcc-4.0.2-glibc-2.3.2.dat` sh all.sh --notest
Does anybody have an idea how to sort out this problem to have byte order
for
64-bit variables on ppc405 the same as for linux on intel x86.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Problem-with-64-bit-variables-on-ppc405-tf4839313.html#a13844837
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Problem with 64-bit variables on ppc405
From: David Hawkins @ 2007-11-19 20:46 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <13844837.post@talk.nabble.com>
Hi Mirek,
> Doubles and long long are 8 bytes long but the byte order differs
> on my host linux Intel PC from this what I have on the target
> linux ppc 405.
That would be due to the difference in endianness of the
processors.
http://en.wikipedia.org/wiki/Endianness
If you want to work on data on both an Intel machine, and a
PowerPC, then you have to transfer the data between the machines
using a machine-independent binary format.
There are several around:
1. Network byte order = big-endian.
2. XDR
http://en.wikipedia.org/wiki/External_Data_Representation
used by NFS,
3. Common Data Representation
http://en.wikipedia.org/wiki/Common_Data_Representation
Which is implemented in the ACE C++ library.
The nice thing about CDR is that the 'reader makes right',
so its only when the endianness of the reader is different
that it has to use CPU cycles to reformat the data.
Its not only processors that have subtle endian issues.
I use little-endian x86 host CPUs in a little-endian PCI
backplane talking to big-endian PowerPC processors.
Data transferred between the processors is first encoded
into a CDR data stream and then decoded. I write binary
data files using the same stream formatters, and then
use mex routines written in C++ to pull the data into
MATLAB data structures.
MATLAB data files are also an example of a machine independent
binary format. But I don't use them.
Cheers,
Dave
^ permalink raw reply
* Re: Problem with uboot on lite5200
From: Wolfgang Denk @ 2007-11-19 21:13 UTC (permalink / raw)
To: Clemens Koller; +Cc: Leo Hendrawan, linuxppc-embedded
In-Reply-To: <47403C73.9040506@anagramm.de>
In message <47403C73.9040506@anagramm.de> you wrote:
>
> How should people get a glue what's current, when in the section
> "Latest News" at http://sourceforge.net/projects/u-boot/ the people
> still find a more or less official looking "u-boot-1.1.5" release.
Maybe by reading the very first two lines on the SF page:
...
NOTE: current source code is available from DENX git
repository and FTP server; see http://www.denx.de/en/Software/GIT
or by looking at the project page http://u-boot.sourceforge.net/ which
redirects you to http://www.denx.de/wiki/UBoot which has all the
significant information?
The problem is that you cannot really "shut down" a SourceForge
project (please correct me if I'm wrong).
> (And they don't want to use scm repositories because they are afraid
> of using anything unstable.)
I guess there is no real cure for this. [Same people will happily
download any temproray test version from a FTP server, though.]
> > Current U-Boot is 1.3.0-rc4. Please wake up.
>
> Well... maybe it's better to remove all references to the old
> releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/
Can you please teach me how to do that?
> instead. Btw. 1.3.0-rc4 isn't there as well. :-P
Indeed. But there is a "snapshot" link on the gitweb page...
And 1.3.0 will be out in less than 2 hours from now :-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I am an atheist, thank God!
^ permalink raw reply
* Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-11-19 21:26 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
to pick up a few bug fixes for 2.6.24. The AC97 change is fairly
harmless and is required to get AC97 working on Virtex boards.
josh
Joachim Foerster (1):
[POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus
Jon Loeliger (1):
[POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platfo
Josh Boyer (1):
[POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
Roel Kluin (1):
[POWERPC] 4xx: balance ioremap/ioumap calls for Yucca
Valentine Barshak (1):
[POWERPC] 4xx: UIC add mask_ack callback
arch/powerpc/platforms/40x/walnut.c | 3 ++-
arch/powerpc/platforms/44x/bamboo.c | 3 ++-
arch/powerpc/platforms/44x/ebony.c | 3 ++-
arch/powerpc/platforms/44x/sequoia.c | 3 ++-
arch/powerpc/sysdev/uic.c | 18 +++++++++++++++++-
arch/ppc/kernel/setup.c | 7 +++++++
arch/ppc/platforms/4xx/yucca.c | 1 +
arch/ppc/syslib/virtex_devices.c | 31 +++++++++++++++++++++++++++++++
8 files changed, 64 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 22:37 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741BDA7.8020106@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Now how do I pick which fabric driver to initialize?
>
> I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
> that works.
I believe that is your only choice on v1. V1 is not set up to
correctly handle for device trees. It is fixed in v2 except for the
problem with how to load the fabric; no one has address that problem
yet. The sound portion of the code is pretty much the same between v1
and v2, it is all the driver setup code that has been reworked.
>
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Christoph Lameter @ 2007-11-19 22:50 UTC (permalink / raw)
To: root
Cc: Trond Myklebust, Peter Zijlstra, LKML, Torsten Kaiser,
Kamalesh Babulal, linuxppc-dev, nfs, Ingo Molnar, Jan Blunck,
Andrew Morton, Balbir Singh
In-Reply-To: <20071117230049.GA25905@dyad>
On Sun, 18 Nov 2007, root wrote:
> @@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
> {
> struct page *page;
> struct kmem_cache_node *n;
> + unsigned long flags;
>
> BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
>
Well local_irq_save is a bit of an overkill. We know that interrupts are
enabled during this phase of the boot sequence.
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-19 23:36 UTC (permalink / raw)
To: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, 5 Nov 2007 12:15:30 -0600
Kim Phillips <kim.phillips@freescale.com> wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
>
Kumar, Leo,
re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
issued his Tested-by.
Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
to go through netdev?
Kim
^ permalink raw reply
* Re: 2.6 kernel hangs after loading device tree
From: abhi_linux @ 2007-11-20 0:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa84b3da0708290938l40d8f543oc0e34fa9bea806a4@mail.gmail.com>
Hello
Did u get a solution to this? I have similar issues. How do u enable
debugging in UBoot?
Thanks
charanya venkatraman wrote:
>
> Hi all
> Sorry about the previous mail.Got sent by mistake.
>
> Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom
> board.Mykernel hangs after loading the device tree in both the
> processors .There is
> no output on the serial port after loading the device tree.Am using U-boot
> 1.2.0 as the bootloader.After enabling debug in u-boot i could see that
> the
> control is getting transferred to the kernel after which it hangs.Earlier
> i
> tried using 2.6.21 which also hangs at the same point.The config files
> used
> were MPC8540ADS_defconfig and MPC8560ADS_defconfig under powerpc
> directory.
> The changes that were made to the device tree are:
> 1.The reg and ranges properties of the soc node have been changed to
> account
> for the change in CCSRBAR of my board.
> 2.Removed the PCI,mdio nodes and ethernet nodes since i dont need support
> for these as of now.
>
> I have tried the following console arguments:
> MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200
> MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200
>
> Any help on this issue??
>
> Thanks.
> Charanya.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/2.6-kernel-hangs-after-loading-device-tree-tf4348921.html#a13848328
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <f334e85d77c624ef0112437a4049a3cd@kernel.crashing.org>
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote:
> > Matt, the various properties you list do not mean what you think they
> > mean.
> >
> > name - should be named according to the generic names convention.
> > It's pretty much arbitrary, meant for human readability of the device
> > tree. Drivers should not depend on it (some do, historically, but new
> > drivers and trees should not).
>
> It is not arbitrary, there is a single well-defined name for every
> common
> "class" of device. It _is_ machine-readable (but shouldn't be used for
> driver matching, indeed -- it says nothing about the programming model).
Sorry, that was an (over?) simplification on my part. Yes, there are
conventions as to what devices should be called by class (usually, but
not universally observed), yes they can be used machine-readable under
some circumstances.
My point is that since driver matching is *not* done off name, and
machine-readable uses are not common, the name tends not to matter
very much. Plus if an incorrect name is used, it's usually not too
bad to fix.
> > device_type - indicates the open firmware method interface for the
> > device.
>
> Not "method interface", just "interface".
Right, I say "method interface" just to emphasise the fact that we're
talking about the runtime OF-call interface, rather than
register-level or other programming interface.
> > Therefore, meaningless in flattened trees.
>
> Even in flat trees, a "device_type" of for example "block" indicates the
> node will have the required properties for that device type, for example
> "block-size". Such properties are perfectly useful. OTOH, it isn't
> very
> useful to search for device with a specific device type from within the
> kernel, since it currently has no firmware interaction to speak of (flat
> trees don't interact, and the kernel kills "real" OF dead as soon as
> possible).
Uh... it was you who convinced me that device_type was not appropriate
for new flat-tree devices.
> > No new driver should use this.
>
> Not without very good rationalisation, anyway.
>
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
> >
> > model - usually just for debugging / diagnosis / human-readable
> > purposes, describes exact model / revision of the hardware. It can be
> > used to enable driver quirks / workarounds for when various devices
> > are supposed to be compatible (as encoded in 'compatible') but
> > aren't, due to hardware bugs. However, you should never aim to use it
> > this way in design.
>
> Yeah. Any non-workaround value a driver would derive from "model" is
> usually better described using a separate property.
Well, yes, if the need for the workaround is known when the device
tree is created. But by their nature workarounds tend not to be
planned, so from the driver's perspective it's legitimate to use *any*
reliable-in-practice information to activate a workaround (even if
it's not reliable in theory, if there's no other option). That
includes both everything in the device tree, and any information the
driver can probe from the hardware.
My point above is that iIt's reasonably common in such cases for
"model" to be a decent choice.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:33 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741BA7D.10608@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> David Gibson wrote:
> > On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> >
> > Gah! For the benefit of others on this list who may be misled.
> >
> > *Neither* of you correctly understands the device tree, what I've seen
> > of *both* your suggested approaches is crap.
> >
> > The device tree describes the _hardware_. If you start reasoning
> > about how to lay out the device tree based on your driver model,
> > you're already wrong.
> >
> > Matt, the various properties you list do not mean what you think they
> > mean.
>
> No, David, I understand exactly what they mean, in the context of a
> guy who works on Open Firmware, real Open Firmware, as was
> standardised 12 years ago.
No, you really don't. Either your knowledge of OF is out of date, or
you've forgotten what you thought you knew.
> Not your whacky newspeak device trees, which to be fair, are a good
> idea, but it seems you all have tried to change something for the
> sake of changing something.
With a couple of tiny exceptions, everything I've said applies equally
to real OF trees.
[snip]
> > device_type - indicates the open firmware method interface for the
> > device. Therefore, meaningless in flattened trees. No new driver
> > should use this.
>
> .. you seem to think you must only design for the guys making Linux
> flattened device trees. I'm sorry, but I am not one of those guys and
> I am much more concerned with how this will affect the OF device tree
> and the usage for anyone else.
No, which is exactly why it's wrong to organize the device tree so
that it's convenient for loading this "fabric driver" thing (which
AFAICT is a Linux-specific driver model limitation).
> Meaningless in flattened device trees, but useful information in real
> OF device trees, do you implement it or not? I'd say, yes. Even if
> you don't agree with "real firmware", you can't just ignore it, shrug
> it away and say it doesn't matter.
Useful information in a real OF tree *if* an OF runtime interface for
the device is defined and implemented.
[snip]
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
>
> Compatible is meant to list alternative, compatible devices as a
> *supplement* to device_type. device_type is your "primary" and
> compatible is your "secondary". In this case, device_type is
> exactly what Jon wants, something to mark out that the audio device
> is his board design and requires special work (it is not merely an
> i2s bus that you can just "use" - although throwing PCM data at it
> would work, who knows what mixer it goes to, and what controls are
> needed to define the bitrate or other features)
No, as Segher explains, that's Just Plain Wrong. Originally "name"
did perform the function you think device_type had. But the generic
names convention, which has been very well established for a long time
now means that the register-level (or equivalent) programming
interface is described by "compatible". Period.
> > model - usually just for debugging / diagnosis / human-readable
> > purposes, describes exact model / revision of the hardware. It can be
> > used to enable driver quirks / workarounds for when various devices
> > are supposed to be compatible (as encoded in 'compatible') but
> > aren't, due to hardware bugs. However, you should never aim to use it
> > this way in design.
>
> I don't see why "model" can't encode the particular revision of the
> hardware in this way when it comes to the audio group of features on
> his board. After all, if you are looking at a "digispeaker,flinger"
> (I made that name up) then you need to know depending on the board
> or even based on weird configurability options of the board, what
> certain things may be - Apple used layout-id and a number. Why NOT
> encode the "model" in the "model"?
>
> Why choose some magical, new property, which then has to be further
> standardised for no reason?
>
> I also think that specifying an audio codec - after all the Open
> Firmware standard defines an audio interface and device tree
> requirements for it, even if they are methods that we don't
> implement and you don't care about - as a function of it's
> control interface is so backwards it doesn't bare thinking about.
Sure, it's fine for a firmware to implement the OF method interface
and put in the relevant device_type for audio in the appropriate place
(although with complex sound systems with many components, the right
place may be non-obvious or even not well defined). It's *not* fine
to make up random new device_type values because you think it's
convenient.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Looking for small form factor with HDLC
From: Kenneth Porter @ 2007-11-20 0:20 UTC (permalink / raw)
To: linuxppc-embedded
I'm attempting to create a middleware system that talks to one of my
vendor's motion control products. My vendor has an FPGA capable of perhaps
10 megabit performance, and RS485 full-duplex tranceivers. I want to be
able to send commands and receive events and bulk data efficiently. I'll
also add electrical isolation, possibly with suitable 485 transceivers.
I'm thinking that HDLC is a natural fit for the bit-level protocol, so I'm
looking for an SBC and Linux OS with natural HDLC support. Ideally the SBC
would fit in a 3"x3"x1" volume, and include Ethernet. It will go on a
backplane along with the motion control box.
The Freescale chips look like many have the hardware to do HDLC, so I'm
wondering what's available for boards and drivers.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:59 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711191128i59245403g3e15e3b6c545b6ee@mail.gmail.com>
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > You might be stuck with using either a platform_device or an
> > > of_platform_device as a stepping stone to creating the device on the
> > > ALSA fabric driver.
> >
> > I also concluded that I need a of_platform stepping stone.
> >
> > There are several ways this could be done, which one is the right one?
> > a) fabric is global, create a global device node for it and implement
> > it as a of_platform device
>
> This is really board level description stuff. I'd make the node
> global off the root myself and use whatever linkage you think
> appropriate to get you to the codec nodes (phandle's most likely)
No. I think this is the whole damn point we've been spiralling
around.
An of_platform device is appropriate *only* if there is an OF node for
the device. There should be an OF node for the device only if it it
really is a well-defined hardware component which implements it.
As far as I can understand, the "fabric" driver is really just a
catchall to cover whatever various interconnections there are between
audio components on the board.
Those interconnections could (and probably should) be described in the
OF tree. But that description would be to describe each of those
interconnections individually e.g. codecs have links to "sound PHY"
devices (speakers) or whatever, codecs, i2s AC97 and so forth devices
have links between them appropriate to the type of device. Not as
some imaginary "fabric device".
Therefore the fabric driver cannot be instantiated as an of_platfornm
device.
Therfore arch code will have to instantiate the fabric driver some
other way. There are a couple of options here:
1) We have a "universal" device-tree-based fabric driver which
parses all the above-described interconnection information in the
device tree and handles any situation. Cool, but probably a lot of
work and fiddly to get right.
2) Or, the platform code instantiates an appopriate fabric
driver for the board (which will probably make assumptions about how
things are interconnected). Platform code can optionally examine
board level model properties or other device information to select the
correct fabric driver and/or options. The fabric driver can
optionally look at some parts of the device tree information to
configure details of its operation.
Option (2) is a hack, but it's a reasonably well-contained hack. It
works for now, and doesn't preclude switching to option (1) later -
without changes to the device tree, and on a board-by-board basis. It
can also handle the (almost inevitable) case of device trees with
missing or incorrect detailed audio interconnection information.
The basic thing is that we have a mismatch between the Linux driver
model and the device tree model. Rather than hacking the device tree
to match the Linux model, we should provide whatever glue code is
necessary to instantiate the necessary Linux drivers from the device
tree information we have. This is, essentially, the exact purpose for
which platform code exists.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
From: Kim Phillips @ 2007-11-20 1:04 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev; +Cc: Li Yang, peter.vanackeren
currently the board-level PHY reset code for the mpc832x MDS messes with
reset configuration words source settings which is plain wrong (it
looks like this board code was cut-n-pasted from the mpc8360 mds code,
which has the PHY reset bits in a different BCSR); this patch points
the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR.
Signed-off-by: Peter Van Ackeren <peter.vanackeren@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..9e3bfcc 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -90,10 +90,11 @@ static void __init mpc832x_sys_setup_arch(void)
if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
!= NULL){
- /* Reset the Ethernet PHY */
- bcsr_regs[9] &= ~0x20;
+ /* Reset the Ethernet PHYs */
+#define BCSR8_FETH_RST 0x50
+ bcsr_regs[8] &= ~BCSR8_FETH_RST;
udelay(1000);
- bcsr_regs[9] |= 0x20;
+ bcsr_regs[8] |= BCSR8_FETH_RST;
iounmap(bcsr_regs);
of_node_put(np);
}
--
1.5.2.2
^ permalink raw reply related
* [PATCH v3] [POWERPC] vdso: Fixes for cache block sizes
From: Olof Johansson @ 2007-11-20 1:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, dwmw2
In-Reply-To: <20071119042519.GA28872@lixom.net>
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cache blocks,
which are only used on IBM's 64-bit processors.
Convert it to get the blocks sizes out of vdso_data instead, similar
to how the ppc64 in-kernel cache flush does it.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Added back the crclr instructions that got removed by mistake when moving over
the in-kernel functions.
-Olof
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 2c8e756..d67bcd8 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -284,6 +284,10 @@ int main(void)
DEFINE(CFG_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32));
DEFINE(WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec));
DEFINE(WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec));
+ DEFINE(CFG_ICACHE_BLOCKSZ, offsetof(struct vdso_data, icache_block_size));
+ DEFINE(CFG_DCACHE_BLOCKSZ, offsetof(struct vdso_data, dcache_block_size));
+ DEFINE(CFG_ICACHE_LOGBLOCKSZ, offsetof(struct vdso_data, icache_log_block_size));
+ DEFINE(CFG_DCACHE_LOGBLOCKSZ, offsetof(struct vdso_data, dcache_log_block_size));
#ifdef CONFIG_PPC64
DEFINE(CFG_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64));
DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec));
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 2322ba5..3702df7 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -699,11 +699,22 @@ static int __init vdso_init(void)
vdso_data->icache_size = ppc64_caches.isize;
vdso_data->icache_line_size = ppc64_caches.iline_size;
+ /* XXXOJN: Blocks should be added to ppc64_caches and used instead */
+ vdso_data->dcache_block_size = ppc64_caches.dline_size;
+ vdso_data->icache_block_size = ppc64_caches.iline_size;
+ vdso_data->dcache_log_block_size = ppc64_caches.log_dline_size;
+ vdso_data->icache_log_block_size = ppc64_caches.log_iline_size;
+
/*
* Calculate the size of the 64 bits vDSO
*/
vdso64_pages = (&vdso64_end - &vdso64_start) >> PAGE_SHIFT;
DBG("vdso64_kbase: %p, 0x%x pages\n", vdso64_kbase, vdso64_pages);
+#else
+ vdso_data->dcache_block_size = L1_CACHE_BYTES;
+ vdso_data->dcache_log_block_size = L1_CACHE_SHIFT;
+ vdso_data->icache_block_size = L1_CACHE_BYTES;
+ vdso_data->icache_log_block_size = L1_CACHE_SHIFT;
#endif /* CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S
index 9cb3199..1ba6feb 100644
--- a/arch/powerpc/kernel/vdso32/cacheflush.S
+++ b/arch/powerpc/kernel/vdso32/cacheflush.S
@@ -23,29 +23,46 @@
*
* Flushes the data cache & invalidate the instruction cache for the
* provided range [start, end[
- *
- * Note: all CPUs supported by this kernel have a 128 bytes cache
- * line size so we don't have to peek that info from the datapage
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
- li r5,127
- andc r6,r3,r5 /* round low to line bdy */
+ mflr r12
+ .cfi_register lr,r12
+ mr r11,r3
+ bl __get_datapage@local
+ mtlr r12
+ mr r10,r3
+
+ lwz r7,CFG_DCACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
- srwi. r8,r8,7 /* compute line count */
+ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
crclr cr0*4+so
beqlr /* nothing to do? */
mtctr r8
- mr r3,r6
-1: dcbst 0,r3
- addi r3,r3,128
+1: dcbst 0,r6
+ add r6,r6,r7
bdnz 1b
sync
+
+/* Now invalidate the instruction cache */
+
+ lwz r7,CFG_ICACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
+ subf r8,r6,r4 /* compute length */
+ add r8,r8,r5
+ lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
+ crclr cr0*4+so
+ beqlr /* nothing to do? */
mtctr r8
-1: icbi 0,r6
- addi r6,r6,128
- bdnz 1b
+2: icbi 0,r6
+ add r6,r6,r7
+ bdnz 2b
isync
li r3,0
blr
diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S
index 66a36d3..69c5af2 100644
--- a/arch/powerpc/kernel/vdso64/cacheflush.S
+++ b/arch/powerpc/kernel/vdso64/cacheflush.S
@@ -23,29 +23,46 @@
*
* Flushes the data cache & invalidate the instruction cache for the
* provided range [start, end[
- *
- * Note: all CPUs supported by this kernel have a 128 bytes cache
- * line size so we don't have to peek that info from the datapage
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
- li r5,127
- andc r6,r3,r5 /* round low to line bdy */
+ mflr r12
+ .cfi_register lr,r12
+ mr r11,r3
+ bl V_LOCAL_FUNC(__get_datapage)
+ mtlr r12
+ mr r10,r3
+
+ lwz r7,CFG_DCACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
- srwi. r8,r8,7 /* compute line count */
+ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
crclr cr0*4+so
beqlr /* nothing to do? */
mtctr r8
- mr r3,r6
-1: dcbst 0,r3
- addi r3,r3,128
+1: dcbst 0,r6
+ add r6,r6,r7
bdnz 1b
sync
+
+/* Now invalidate the instruction cache */
+
+ lwz r7,CFG_ICACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
+ subf r8,r6,r4 /* compute length */
+ add r8,r8,r5
+ lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
+ crclr cr0*4+so
+ beqlr /* nothing to do? */
mtctr r8
-1: icbi 0,r6
- addi r6,r6,128
- bdnz 1b
+2: icbi 0,r6
+ add r6,r6,r7
+ bdnz 2b
isync
li r3,0
blr
diff --git a/include/asm-powerpc/vdso_datapage.h b/include/asm-powerpc/vdso_datapage.h
index 8a94f0e..f013932 100644
--- a/include/asm-powerpc/vdso_datapage.h
+++ b/include/asm-powerpc/vdso_datapage.h
@@ -77,6 +77,10 @@ struct vdso_data {
/* those additional ones don't have to be located anywhere
* special as they were not part of the original systemcfg
*/
+ __u32 dcache_block_size; /* L1 d-cache block size */
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
__s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
@@ -99,6 +103,10 @@ struct vdso_data {
__s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
+ __u32 dcache_block_size; /* L1 d-cache block size */
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
};
#endif /* CONFIG_PPC64 */
^ permalink raw reply related
* [PATCH] powerpc: fix os-term usage on kernel panic
From: Linas Vepstas @ 2007-11-20 1:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The rtas_os_term() routine was being called at the wrong time.
The actual rtas call "os-term" will not ever return, and so
calling it from the panic notifier is too early. Instead,
call it from the machine_reset() call.
The patch splits the rtas_os_term() routine into two: one
part to capture the kernel panic message, invoked during
the panic notifier, and another part that is invoked during
machine_reset().
Prior to this patch, the os-term call was never being made,
because panic_timeout was always non-zero. Calling os-term
helps keep the hypervisor happy! We have to keep the hypervisor
happy to avoid service, dump and error reporting problems.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
One could make a strong argument to move all of this code
from kernel/rtas.c to platforms/pseries/setup.c I did not
do this, just so as to make the changes minimal.
arch/powerpc/kernel/rtas.c | 12 ++++++------
arch/powerpc/platforms/pseries/setup.c | 3 ++-
include/asm-powerpc/rtas.h | 3 ++-
3 files changed, 10 insertions(+), 8 deletions(-)
Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19 18:58:53.000000000 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c 2007-11-19 19:01:10.000000000 -0600
@@ -631,18 +631,18 @@ void rtas_halt(void)
/* Must be in the RMO region, so we place it here */
static char rtas_os_term_buf[2048];
-void rtas_os_term(char *str)
+void rtas_panic_msg(char *str)
{
- int status;
+ snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
+}
- if (panic_timeout)
- return;
+void rtas_os_term(void)
+{
+ int status;
if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
return;
- snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
-
do {
status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
__pa(rtas_os_term_buf));
Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c 2007-11-19 18:58:53.000000000 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c 2007-11-19 19:01:10.000000000 -0600
@@ -507,7 +507,8 @@ define_machine(pseries) {
.restart = rtas_restart,
.power_off = pSeries_power_off,
.halt = rtas_halt,
- .panic = rtas_os_term,
+ .panic = rtas_panic_msg,
+ .machine_shutdown = rtas_os_term,
.get_boot_time = rtas_get_boot_time,
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
===================================================================
--- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19 18:58:53.000000000 -0600
+++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h 2007-11-19 19:01:10.000000000 -0600
@@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
extern void rtas_restart(char *cmd);
extern void rtas_power_off(void);
extern void rtas_halt(void);
-extern void rtas_os_term(char *str);
+extern void rtas_panic_msg(char *str);
+extern void rtas_os_term(void);
extern int rtas_get_sensor(int sensor, int index, int *state);
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Jeff Garzik @ 2007-11-20 1:30 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, Li Yang, paulus, linuxppc-dev
In-Reply-To: <20071119173652.55e385b2.kim.phillips@freescale.com>
Kim Phillips wrote:
> On Mon, 5 Nov 2007 12:15:30 -0600
> Kim Phillips <kim.phillips@freescale.com> wrote:
>
>> Hello all,
>>
>> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
>> according to erratum #2 (erratum text included below). Basically the
>> most intrusive part is the addition of two new RGMII Internal Delay
>> modes; one for TX delay only, and the other for RX delay only (i.e, not
>> both at the same time).
>>
>> Please review, and since this affects both netdev and powerpc trees,
>> one maintainer should ack them for the other to push upstream (i.e,
>> Kumar acks them, and Leo picks them up to go through netdev or the
>> other way around; either way is fine with me). I'm hoping they're
>> trivial enough to go in 2.6.24.
>>
> Kumar, Leo,
>
> re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
> issued his Tested-by.
>
> Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
> to go through netdev?
FWIW I just got back from vacation... I'm grabbing what DaveM has
collected into davem/netdev-2.6.git, and then going from there...
Jeff
^ permalink raw reply
* Please pull from 'for-2.6.24' branch of pasemi tree
From: Olof Johansson @ 2007-11-20 1:34 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.24
For the following bugfix for 2.6.24:
Olof Johansson (1):
[POWERPC] pasemi: Don't reset mpic at boot
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Thanks,
Olof
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 1:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741C0C4.4070502@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:58:44PM +0000, Matt Sealey wrote:
> Segher Boessenkool wrote:
> >> And I forgot the rant you guys usually get - for god's sake, why isn't
> >> anyone using the "model" property?
> >
> > Probably because it isn't useful all that often.
> >
> >> sound@0 {
> >> \\ this is our magic audio fabric
> >> device_type = "digispeaker,flinger";
> >
> > This is wrong in so many ways; see David's mail for a start.
>
> Why? I'm sorry but I am living in the real world where we have real
> firmwares and real dynamic device trees here. You can't just say
> "this is wrong because it has a device_type".
It's not wrong because it has a device_type, it's wrong because the
device_type value is some random made-up thing that doesn't have an OF
binding behind it. Nor do you suggest an OF binding. Nor should
driver selection be based off device_type.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 04/59] arch/ppc: Add missing "space"
From: Joe Perches @ 2007-11-20 1:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <ee1678e1bc8b80b7ae420059fffc7241486ea91a.1195454434.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/ppc/platforms/ev64260.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/platforms/ev64260.c b/arch/ppc/platforms/ev64260.c
index 976270d..c1f77e1 100644
--- a/arch/ppc/platforms/ev64260.c
+++ b/arch/ppc/platforms/ev64260.c
@@ -336,7 +336,7 @@ ev64260_early_serial_map(void)
#endif
if (early_serial_setup(&port) != 0)
- printk(KERN_WARNING "Early serial init of port 0"
+ printk(KERN_WARNING "Early serial init of port 0 "
"failed\n");
first_time = 0;
@@ -388,7 +388,7 @@ ev64260_setup_arch(void)
ev64260_early_serial_map();
#endif
- printk(KERN_INFO "%s %s port (C) 2001 MontaVista Software, Inc."
+ printk(KERN_INFO "%s %s port (C) 2001 MontaVista Software, Inc. "
"(source@mvista.com)\n", BOARD_VENDOR, BOARD_MACHINE);
if (ppc_md.progress)
--
1.5.3.5.652.gf192c
^ permalink raw reply related
* [PATCH 03/59] arch/powerpc: Add missing "space"
From: Joe Perches @ 2007-11-20 1:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, anton, Paul Mackerras, Anton Blanchard, paulus
In-Reply-To: <ee1678e1bc8b80b7ae420059fffc7241486ea91a.1195454434.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/kernel/isa-bridge.c | 4 ++--
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 2 +-
arch/powerpc/platforms/celleb/io-workarounds.c | 2 +-
arch/powerpc/platforms/celleb/scc_epci.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index f0f49d1..965bfcc 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -108,7 +108,7 @@ static void __devinit pci_process_ISA_OF_ranges(struct device_node *isa_node,
if (size > 0x10000)
size = 0x10000;
- printk(KERN_ERR "no ISA IO ranges or unexpected isa range,"
+ printk(KERN_ERR "no ISA IO ranges or unexpected isa range, "
"mapping 64k\n");
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
@@ -116,7 +116,7 @@ static void __devinit pci_process_ISA_OF_ranges(struct device_node *isa_node,
return;
inval_range:
- printk(KERN_ERR "no ISA IO ranges or unexpected isa range,"
+ printk(KERN_ERR "no ISA IO ranges or unexpected isa range, "
"mapping 64k\n");
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
0x10000, _PAGE_NO_CACHE|_PAGE_GUARDED);
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8135da0..10dda22 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -189,7 +189,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
return SIGSEGV;
/* in_atomic() in user mode is really bad,
as is current->mm == NULL. */
- printk(KERN_EMERG "Page fault in user mode with"
+ printk(KERN_EMERG "Page fault in user mode with "
"in_atomic() = %d mm = %p\n", in_atomic(), mm);
printk(KERN_EMERG "NIP = %lx MSR = %lx\n",
regs->nip, regs->msr);
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
index d35eda8..ba645c2 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -120,7 +120,7 @@ void __init mpc8xx_calibrate_decr(void)
ppc_tb_freq /= 16;
ppc_proc_freq = 50000000;
if (!get_freq("clock-frequency", &ppc_proc_freq))
- printk(KERN_ERR "WARNING: Estimating processor frequency"
+ printk(KERN_ERR "WARNING: Estimating processor frequency "
"(not found)\n");
printk("Decrementer Frequency = 0x%lx\n", ppc_tb_freq);
diff --git a/arch/powerpc/platforms/celleb/io-workarounds.c b/arch/powerpc/platforms/celleb/io-workarounds.c
index 2b91214..32b9cec 100644
--- a/arch/powerpc/platforms/celleb/io-workarounds.c
+++ b/arch/powerpc/platforms/celleb/io-workarounds.c
@@ -256,7 +256,7 @@ int __init celleb_pci_workaround_init(void)
celleb_dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!celleb_dummy_page_va) {
- printk(KERN_ERR "Celleb: dummy read disabled."
+ printk(KERN_ERR "Celleb: dummy read disabled. "
"Alloc celleb_dummy_page_va failed\n");
return 1;
}
diff --git a/arch/powerpc/platforms/celleb/scc_epci.c b/arch/powerpc/platforms/celleb/scc_epci.c
index 9d07642..a3c7cfb 100644
--- a/arch/powerpc/platforms/celleb/scc_epci.c
+++ b/arch/powerpc/platforms/celleb/scc_epci.c
@@ -95,7 +95,7 @@ void __init epci_workaround_init(struct pci_controller *hose)
private->dummy_page_da = dma_map_single(hose->parent,
celleb_dummy_page_va, PAGE_SIZE, DMA_FROM_DEVICE);
if (private->dummy_page_da == DMA_ERROR_CODE) {
- printk(KERN_ERR "EPCI: dummy read disabled."
+ printk(KERN_ERR "EPCI: dummy read disabled. "
"Map dummy page failed.\n");
return;
}
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 33df4c3..87e58e0 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -222,7 +222,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
}
- printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx."
+ printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
"Firmware bus number: %d->%d\n",
(unsigned long long)rsrc.start, hose->first_busno,
hose->last_busno);
--
1.5.3.5.652.gf192c
^ permalink raw reply related
* libfdt: Abolish _typed() variants, add _cell() variants
From: David Gibson @ 2007-11-20 2:35 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In a number of places through libfdt and its tests, we have *_typed()
macro variants on functions which use gcc's typeof and statement
expression extensions to allow passing literals where the underlying
function takes a buffer and size.
These seemed like a good idea at the time, but in fact they have some
problems. They use typeof and statement expressions, extensions I'd
prefer to avoid for portability. Plus, they have potential gotchas -
although they'll deal with the size of the thing passed, they won't
deal with other representation issues (like endianness) and results
could be very strange if the type of the expression passed isn't what
you think it is.
In fact, the only users of these _typed() macros were when the value
passed is a single cell (32-bit integer). Therefore, this patch
removes all these _typed() macros and replaces them with explicit
_cell() variants which handle a single 32-bit integer, and which also
perform endian convesions as appropriate.
With this in place, it now becomes easy to use standardized big-endian
representation for integer valued properties in the testcases,
regardless of the platform we're running on. We therefore do that,
which has the additional advantage that all the example trees created
during a test run are now byte-for-byte identical regardless of
platform.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-11-20 13:04:09.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-11-20 13:05:24.000000000 +1100
@@ -657,12 +657,12 @@ int fdt_node_offset_by_compatible(const
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
-
-#define fdt_setprop_inplace_typed(fdt, nodeoffset, name, val) \
- ({ \
- typeof(val) x = val; \
- fdt_setprop_inplace(fdt, nodeoffset, name, &x, sizeof(x)); \
- })
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+ const char *name, uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
int fdt_nop_node(void *fdt, int nodeoffset);
@@ -676,11 +676,11 @@ int fdt_add_reservemap_entry(void *fdt,
int fdt_finish_reservemap(void *fdt);
int fdt_begin_node(void *fdt, const char *name);
int fdt_property(void *fdt, const char *name, const void *val, int len);
-#define fdt_property_typed(fdt, name, val) \
- ({ \
- typeof(val) x = (val); \
- fdt_property((fdt), (name), &x, sizeof(x)); \
- })
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_property(fdt, name, &val, sizeof(val));
+}
#define fdt_property_string(fdt, name, str) \
fdt_property(fdt, name, str, strlen(str)+1)
int fdt_end_node(void *fdt);
@@ -698,11 +698,12 @@ int fdt_del_mem_rsv(void *fdt, int n);
int fdt_setprop(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
-#define fdt_setprop_typed(fdt, nodeoffset, name, val) \
- ({ \
- typeof(val) x = (val); \
- fdt_setprop((fdt), (nodeoffset), (name), &x, sizeof(x)); \
- })
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+ uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
#define fdt_setprop_string(fdt, nodeoffset, name, str) \
fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
int fdt_delprop(void *fdt, int nodeoffset, const char *name);
Index: dtc/tests/setprop_inplace.c
===================================================================
--- dtc.orig/tests/setprop_inplace.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/setprop_inplace.c 2007-11-20 13:05:55.000000000 +1100
@@ -42,14 +42,14 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("Old int value was 0x%08x\n", *intp);
- err = fdt_setprop_inplace_typed(fdt, 0, "prop-int", ~TEST_VALUE_1);
+ err = fdt_setprop_inplace_cell(fdt, 0, "prop-int", ~TEST_VALUE_1);
if (err)
FAIL("Failed to set \"prop-int\" to 0x08%x: %s",
~TEST_VALUE_1, fdt_strerror(err));
- intp = check_getprop_typed(fdt, 0, "prop-int", ~TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", ~TEST_VALUE_1);
verbose_printf("New int value is 0x%08x\n", *intp);
strp = check_getprop(fdt, 0, "prop-str", strlen(TEST_STRING_1)+1,
Index: dtc/tests/del_node.c
===================================================================
--- dtc.orig/tests/del_node.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/del_node.c 2007-11-20 13:04:09.000000000 +1100
@@ -48,19 +48,19 @@ int main(int argc, char *argv[])
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode@1\": %s",
fdt_strerror(subnode1_offset));
- check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
+ check_getprop_cell(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_del_node(fdt, subnode1_offset);
if (err)
@@ -76,13 +76,13 @@ int main(int argc, char *argv[])
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_del_node(fdt, subnode2_offset);
if (err)
Index: dtc/tests/del_property.c
===================================================================
--- dtc.orig/tests/del_property.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/del_property.c 2007-11-20 13:04:09.000000000 +1100
@@ -45,7 +45,7 @@ int main(int argc, char *argv[])
oldsize = fdt_totalsize(fdt);
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("int value was 0x%08x\n", *intp);
err = fdt_delprop(fdt, 0, "prop-int");
Index: dtc/tests/find_property.c
===================================================================
--- dtc.orig/tests/find_property.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/find_property.c 2007-11-20 13:04:09.000000000 +1100
@@ -35,7 +35,7 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_property_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ check_property_cell(fdt, 0, "prop-int", TEST_VALUE_1);
check_property(fdt, 0, "prop-str", strlen(TEST_STRING_1)+1, TEST_STRING_1);
PASS();
Index: dtc/tests/getprop.c
===================================================================
--- dtc.orig/tests/getprop.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/getprop.c 2007-11-20 13:04:09.000000000 +1100
@@ -36,7 +36,7 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
check_getprop(fdt, 0, "prop-str", strlen(TEST_STRING_1)+1, TEST_STRING_1);
PASS();
Index: dtc/tests/node_offset_by_prop_value.c
===================================================================
--- dtc.orig/tests/node_offset_by_prop_value.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/node_offset_by_prop_value.c 2007-11-20 13:04:09.000000000 +1100
@@ -67,9 +67,9 @@ void check_search_str(void *fdt, const c
va_end(ap);
}
-#define check_search_val(fdt, propname, propval, ...) \
+#define check_search_cell(fdt, propname, propval, ...) \
{ \
- typeof(propval) val = (propval); \
+ uint32_t val = cpu_to_fdt32(propval); \
check_search((fdt), (propname), &val, sizeof(val), \
##__VA_ARGS__); \
}
@@ -92,17 +92,17 @@ int main(int argc, char *argv[])
|| (subsubnode1_offset < 0) || (subsubnode2_offset < 0))
FAIL("Can't find required nodes");
- check_search_val(fdt, "prop-int", TEST_VALUE_1, 0, subnode1_offset,
- subsubnode1_offset, -FDT_ERR_NOTFOUND);
+ check_search_cell(fdt, "prop-int", TEST_VALUE_1, 0, subnode1_offset,
+ subsubnode1_offset, -FDT_ERR_NOTFOUND);
- check_search_val(fdt, "prop-int", TEST_VALUE_2, subnode2_offset,
- subsubnode2_offset, -FDT_ERR_NOTFOUND);
+ check_search_cell(fdt, "prop-int", TEST_VALUE_2, subnode2_offset,
+ subsubnode2_offset, -FDT_ERR_NOTFOUND);
check_search_str(fdt, "prop-str", TEST_STRING_1, 0, -FDT_ERR_NOTFOUND);
check_search_str(fdt, "prop-str", "no such string", -FDT_ERR_NOTFOUND);
- check_search_val(fdt, "prop-int", TEST_VALUE_1+1, -FDT_ERR_NOTFOUND);
+ check_search_cell(fdt, "prop-int", TEST_VALUE_1+1, -FDT_ERR_NOTFOUND);
check_search(fdt, "no-such-prop", NULL, 0, -FDT_ERR_NOTFOUND);
Index: dtc/tests/nop_node.c
===================================================================
--- dtc.orig/tests/nop_node.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/nop_node.c 2007-11-20 13:04:09.000000000 +1100
@@ -43,19 +43,19 @@ int main(int argc, char *argv[])
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode1\": %s",
fdt_strerror(subnode1_offset));
- check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
+ check_getprop_cell(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_nop_node(fdt, subnode1_offset);
if (err)
@@ -71,13 +71,13 @@ int main(int argc, char *argv[])
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_nop_node(fdt, subnode2_offset);
if (err)
Index: dtc/tests/nop_property.c
===================================================================
--- dtc.orig/tests/nop_property.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/nop_property.c 2007-11-20 13:04:09.000000000 +1100
@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("int value was 0x%08x\n", *intp);
err = fdt_nop_property(fdt, 0, "prop-int");
Index: dtc/tests/rw_tree1.c
===================================================================
--- dtc.orig/tests/rw_tree1.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/rw_tree1.c 2007-11-20 13:04:09.000000000 +1100
@@ -73,27 +73,25 @@ int main(int argc, char *argv[])
CHECK(fdt_add_mem_rsv(fdt, TEST_ADDR_2, TEST_SIZE_2));
CHECK(fdt_setprop_string(fdt, 0, "compatible", "test_tree1"));
- CHECK(fdt_setprop_typed(fdt, 0, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_setprop_cell(fdt, 0, "prop-int", TEST_VALUE_1));
CHECK(fdt_setprop_string(fdt, 0, "prop-str", TEST_STRING_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@1"));
CHECK(fdt_setprop_string(fdt, offset, "compatible", "subnode1"));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
CHECK(fdt_setprop(fdt, offset, "compatible",
"subsubnode1\0subsubnode", 23));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@2"));
- CHECK(fdt_setprop_typed(fdt, offset, "linux,phandle",
- cpu_to_fdt32(PHANDLE_1)));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_setprop_cell(fdt, offset, "linux,phandle", PHANDLE_1));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_2));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode@0"));
- CHECK(fdt_setprop_typed(fdt, offset, "linux,phandle",
- cpu_to_fdt32(PHANDLE_2)));
+ CHECK(fdt_setprop_cell(fdt, offset, "linux,phandle", PHANDLE_2));
CHECK(fdt_setprop(fdt, offset, "compatible",
"subsubnode2\0subsubnode", 23));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_2));
CHECK(fdt_pack(fdt));
Index: dtc/tests/setprop.c
===================================================================
--- dtc.orig/tests/setprop.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/setprop.c 2007-11-20 13:04:09.000000000 +1100
@@ -52,7 +52,7 @@ int main(int argc, char *argv[])
fdt = buf;
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("Old int value was 0x%08x\n", *intp);
err = fdt_setprop_string(fdt, 0, "prop-int", NEW_STRING);
Index: dtc/tests/subnode_offset.c
===================================================================
--- dtc.orig/tests/subnode_offset.c 2007-11-20 13:04:09.000000000 +1100
+++ dtc/tests/subnode_offset.c 2007-11-20 13:04:09.000000000 +1100
@@ -70,16 +70,16 @@ int main(int argc, char *argv[])
if (subnode1_offset == subnode2_offset)
FAIL("Different subnodes have same offset");
- check_property_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- check_property_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_cell(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
+ check_property_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
- check_property_typed(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
- check_property_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
- check_property_typed(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
+ check_property_cell(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
+ check_property_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_cell(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
if (subsubnode2_offset != subsubnode2_offset2)
FAIL("Different offsets with and without unit address");
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/sw_tree1.c 2007-11-20 13:04:09.000000000 +1100
@@ -55,27 +55,27 @@ int main(int argc, char *argv[])
CHECK(fdt_begin_node(fdt, ""));
CHECK(fdt_property_string(fdt, "compatible", "test_tree1"));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_property_string(fdt, "prop-str", TEST_STRING_1));
CHECK(fdt_begin_node(fdt, "subnode@1"));
CHECK(fdt_property_string(fdt, "compatible", "subnode1"));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property(fdt, "compatible", "subsubnode1\0subsubnode",
23));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
CHECK(fdt_begin_node(fdt, "subnode@2"));
- CHECK(fdt_property_typed(fdt, "linux,phandle", cpu_to_fdt32(PHANDLE_1)));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_property_cell(fdt, "linux,phandle", PHANDLE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_begin_node(fdt, "subsubnode@0"));
- CHECK(fdt_property_typed(fdt, "linux,phandle", cpu_to_fdt32(PHANDLE_2)));
+ CHECK(fdt_property_cell(fdt, "linux,phandle", PHANDLE_2));
CHECK(fdt_property(fdt, "compatible", "subsubnode2\0subsubnode",
23));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/testdata.h 2007-11-20 13:04:09.000000000 +1100
@@ -20,8 +20,8 @@
#define TEST_ADDR_2 ASM_CONST_LL(123456789)
#define TEST_SIZE_2 ASM_CONST_LL(010000)
-#define TEST_VALUE_1 cell_to_fdt(0xdeadbeef)
-#define TEST_VALUE_2 cell_to_fdt(123456789)
+#define TEST_VALUE_1 0xdeadbeef
+#define TEST_VALUE_2 123456789
#define PHANDLE_1 0x2000
#define PHANDLE_2 0x2001
Index: dtc/tests/tests.h
===================================================================
--- dtc.orig/tests/tests.h 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/tests.h 2007-11-20 13:04:09.000000000 +1100
@@ -112,18 +112,18 @@ void check_mem_rsv(void *fdt, int n, uin
void check_property(void *fdt, int nodeoffset, const char *name,
int len, const void *val);
-#define check_property_typed(fdt, nodeoffset, name, val) \
+#define check_property_cell(fdt, nodeoffset, name, val) \
({ \
- typeof(val) x = val; \
+ uint32_t x = cpu_to_fdt32(val); \
check_property(fdt, nodeoffset, name, sizeof(x), &x); \
})
const void *check_getprop(void *fdt, int nodeoffset, const char *name,
int len, const void *val);
-#define check_getprop_typed(fdt, nodeoffset, name, val) \
+#define check_getprop_cell(fdt, nodeoffset, name, val) \
({ \
- typeof(val) x = val; \
+ uint32_t x = cpu_to_fdt32(val); \
check_getprop(fdt, nodeoffset, name, sizeof(x), &x); \
})
#define check_getprop_string(fdt, nodeoffset, name, s) \
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/trees.S 2007-11-20 13:04:09.000000000 +1100
@@ -50,8 +50,7 @@ tree##_rsvmap_end: ;
#define PROP_INT(tree, name, val) \
PROPHDR(tree, name, 4) \
- /* For ease of testing the property values go in native-endian */ \
- .long val ;
+ FDTLONG(val) ;
#define PROP_STR(tree, name, str) \
PROPHDR(tree, name, 55f - 54f) \
@@ -100,11 +99,11 @@ test_tree1_struct:
END_NODE
BEGIN_NODE("subnode@2")
- PROP_INT(test_tree1, phandle, cell_to_fdt(PHANDLE_1))
+ PROP_INT(test_tree1, phandle, PHANDLE_1)
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
BEGIN_NODE("subsubnode@0")
- PROP_INT(test_tree1, phandle, cell_to_fdt(PHANDLE_2))
+ PROP_INT(test_tree1, phandle, PHANDLE_2)
PROP_STR(test_tree1, compatible, "subsubnode2\0subsubnode")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
END_NODE
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] fix scaled time accounting possible divide by zero
From: Michael Neuling @ 2007-11-20 3:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Balbir Singh
This fixes a problem noticed by Balbir Singh
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Paulus: can we send this up for 2.6.24?
arch/powerpc/kernel/time.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -244,8 +244,9 @@ void account_system_vtime(struct task_st
/* deltascaled includes both user and system time.
* Hence scale it based on the purr ratio to estimate
* the system time */
- deltascaled = deltascaled * get_paca()->system_time /
- (get_paca()->system_time + get_paca()->user_time);
+ if (get_paca()->user_time)
+ deltascaled = deltascaled * get_paca()->system_time /
+ (get_paca()->system_time + get_paca()->user_time);
delta += get_paca()->system_time;
get_paca()->system_time = 0;
}
^ permalink raw reply
* Re: [PATCH v2] PMU: replace information ioctls and schedule for removal
From: Paul Mackerras @ 2007-11-20 3:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1194981108.6695.11.camel@johannes.berg>
Johannes Berg writes:
> This patch adds sysfs attributes to the PMU to allow getting
> the information on the PMU type and whether adb is present from
> there instead of via the ioctl. The ioctl is made optional and
> scheduled for removal.
I don't see any reason to ever remove the ioctls. We're talking about
just 4 lines of code here. Sure we can add the sysfs attributes -
even though that adds an order of magnitude more lines of code
(thanks sysfs :) but I don't see any good reason to remove the
existing interface.
Paul.
^ permalink raw reply
* [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-20 3:36 UTC (permalink / raw)
To: linuxppc-dev
isel (Integer Select) is a new user space instruction in the
PowerISA 2.04 spec. Not all processors implement it so lets emulate
to ensure code built with isel will run everywhere.
---
arch/powerpc/kernel/traps.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
In my git tree for 2.6.25.
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 59c464e..cad6484 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -622,6 +622,9 @@ static void parse_fpe(struct pt_regs *regs)
#define INST_POPCNTB 0x7c0000f4
#define INST_POPCNTB_MASK 0xfc0007fe
+#define INST_ISEL 0x7c00001e
+#define INST_ISEL_MASK 0xfc00003e
+
static int emulate_string_inst(struct pt_regs *regs, u32 instword)
{
u8 rT = (instword >> 21) & 0x1f;
@@ -707,6 +710,23 @@ static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
return 0;
}
+static int emulate_isel(struct pt_regs *regs, u32 instword)
+{
+ u8 rT = (instword >> 21) & 0x1f;
+ u8 rA = (instword >> 16) & 0x1f;
+ u8 rB = (instword >> 11) & 0x1f;
+ u8 BC = (instword >> 6) & 0x1f;
+ u8 bit;
+ unsigned long tmp;
+
+ tmp = (rA == 0) ? 0 : regs->gpr[rA];
+ bit = (regs->ccr >> (31 - BC)) & 0x1;
+
+ regs->gpr[rT] = bit ? tmp : regs->gpr[rB];
+
+ return 0;
+}
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -749,6 +769,11 @@ static int emulate_instruction(struct pt_regs *regs)
return emulate_popcntb_inst(regs, instword);
}
+ /* Emulate isel (Integer Select) instruction */
+ if ((instword & INST_ISEL_MASK) == INST_ISEL) {
+ return emulate_isel(regs, instword);
+ }
+
return -EINVAL;
}
--
1.5.3.4
^ permalink raw reply related
* [PATCH] ibm_newemac: Fix possible lockup on close
From: Benjamin Herrenschmidt @ 2007-11-20 3:50 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
It's a bad idea to call flush_scheduled_work from within a
netdev->stop because the linkwatch will occasionally take the
rtnl lock from a workqueue context, and thus that can deadlock.
This reworks things a bit in that area to avoid the problem.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 31 ++++++++++++++++++++-----------
drivers/net/ibm_newemac/core.h | 1 +
2 files changed, 21 insertions(+), 11 deletions(-)
Index: linux-work/drivers/net/ibm_newemac/core.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-20 14:42:50.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-20 14:46:51.000000000 +1100
@@ -642,9 +642,11 @@ static void emac_reset_work(struct work_
DBG(dev, "reset_work" NL);
mutex_lock(&dev->link_lock);
- emac_netif_stop(dev);
- emac_full_tx_reset(dev);
- emac_netif_start(dev);
+ if (dev->opened) {
+ emac_netif_stop(dev);
+ emac_full_tx_reset(dev);
+ emac_netif_start(dev);
+ }
mutex_unlock(&dev->link_lock);
}
@@ -1063,10 +1065,9 @@ static int emac_open(struct net_device *
dev->rx_sg_skb = NULL;
mutex_lock(&dev->link_lock);
+ dev->opened = 1;
- /* XXX Start PHY polling now. Shouldn't wr do like sungem instead and
- * always poll the PHY even when the iface is down ? That would allow
- * things like laptop-net to work. --BenH
+ /* Start PHY polling now.
*/
if (dev->phy.address >= 0) {
int link_poll_interval;
@@ -1145,9 +1146,11 @@ static void emac_link_timer(struct work_
int link_poll_interval;
mutex_lock(&dev->link_lock);
-
DBG2(dev, "link timer" NL);
+ if (!dev->opened)
+ goto bail;
+
if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
/* Get new link parameters */
@@ -1170,13 +1173,14 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_OFF;
}
schedule_delayed_work(&dev->link_work, link_poll_interval);
-
+ bail:
mutex_unlock(&dev->link_lock);
}
static void emac_force_link_update(struct emac_instance *dev)
{
netif_carrier_off(dev->ndev);
+ smp_rmb();
if (dev->link_polling) {
cancel_rearming_delayed_work(&dev->link_work);
if (dev->link_polling)
@@ -1191,11 +1195,14 @@ static int emac_close(struct net_device
DBG(dev, "close" NL);
- if (dev->phy.address >= 0)
+ if (dev->phy.address >= 0) {
+ dev->link_polling = 0;
cancel_rearming_delayed_work(&dev->link_work);
-
+ }
+ mutex_lock(&dev->link_lock);
emac_netif_stop(dev);
- flush_scheduled_work();
+ dev->opened = 0;
+ mutex_unlock(&dev->link_lock);
emac_rx_disable(dev);
emac_tx_disable(dev);
@@ -2756,6 +2763,8 @@ static int __devexit emac_remove(struct
unregister_netdev(dev->ndev);
+ flush_scheduled_work();
+
if (emac_has_feature(dev, EMAC_FTR_HAS_TAH))
tah_detach(dev->tah_dev, dev->tah_port);
if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII))
Index: linux-work/drivers/net/ibm_newemac/core.h
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2007-11-20 14:42:50.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/core.h 2007-11-20 14:46:51.000000000 +1100
@@ -258,6 +258,7 @@ struct emac_instance {
int stop_timeout; /* in us */
int no_mcast;
int mcast_pending;
+ int opened;
struct work_struct reset_work;
spinlock_t lock;
};
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox