46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
...
-47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
+49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is not 47,
I've not been able to reproduce it since, but I know others (BCC'ed
on
this note) have seen it and might prod them to come forth with
details
(and broken .config files)
In my case, disabling CPU_FREQ_PMAC made the failure go away.
After reverting this patch, CPU_FREQ_PMAC is once again
I've not been able to reproduce it since, but I know others (BCC'ed
on
this note) have seen it and might prod them to come forth with
details
(and broken .config files)
In my case, disabling CPU_FREQ_PMAC made the failure go away.
After reverting this patch, CPU_FREQ_PMAC is once again
46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
...
-47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
+49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is not 47,
I thought the motivation for div64() was that a 64:32->32 divide could
be done a lot faster on a number of platforms (including the important
x86) than a generic 64:64->64 divide, but gcc doesn't handle the
devolution automatically -- there is no such libgcc function.
That there's no such
And check that we didn't end up stupidly having the initrd share a page
with something else ... (like not aligned end or such thingy).
David tested that yesterday, it's not the case. Too bad,
would have been too easy ;-)
Segher
-
To unsubscribe from this list: send the line "unsubscribe
And check that we didn't end up stupidly having the initrd share a page
with something else ... (like not aligned end or such thingy).
David tested that yesterday, it's not the case. Too bad,
would have been too easy ;-)
Segher
-
To unsubscribe from this list: send the line unsubscribe
I thought the motivation for div64() was that a 64:32-32 divide could
be done a lot faster on a number of platforms (including the important
x86) than a generic 64:64-64 divide, but gcc doesn't handle the
devolution automatically -- there is no such libgcc function.
That there's no such
I just got an answer from the hypervisor architects. It turns out
that the hardware _does_ prevent the device from sending MSI messages
to another partition. The OS _can_ write whatever it likes to the MSI
address and data registers. It can potentially lose interrupts (or, I
expect, get the
I just got an answer from the hypervisor architects. It turns out
that the hardware _does_ prevent the device from sending MSI messages
to another partition. The OS _can_ write whatever it likes to the MSI
address and data registers. It can potentially lose interrupts (or, I
expect, get the
CC [M] drivers/kvm/vmx.o
{standard input}: Assembler messages:
{standard input}:3257: Error: bad register name `%sil'
make[2]: *** [drivers/kvm/vmx.o] Error 1
make[1]: *** [drivers/kvm] Error 2
make: *** [drivers] Error 2
Am I missing something or this is a real problem?
What's on (and
CC [M] drivers/kvm/vmx.o
{standard input}: Assembler messages:
{standard input}:3257: Error: bad register name `%sil'
make[2]: *** [drivers/kvm/vmx.o] Error 1
make[1]: *** [drivers/kvm] Error 2
make: *** [drivers] Error 2
Am I missing something or this is a real problem?
What's on (and
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or
non-callback.
It is still being tested.
It currently only hooks up OLPC, and I don't have any of
those [hint hint], so I need external testers. I'll send
the patch
It's unlikely that this driver will ever be of any use on other
architectures.
It's already being used, for example, the AMD8111 is used
one some PowerPC systems (some with IDE connected even).
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Yeah. The >(...) syntax in my example provides such a file;
of
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Yeah. The (...) syntax in my example provides such a file;
of
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or
non-callback.
It is still being tested.
It currently only hooks up OLPC, and I don't have any of
those [hint hint], so I need external testers. I'll send
the patch
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the
It's unlikely that this driver will ever be of any use on other
architectures.
It's already being used, for example, the AMD8111 is used
one some PowerPC systems (some with IDE connected even).
Segher
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)
Segher
-
To
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
objcopy -j .rodata.uts -O binary vmlinux (the-checker-script)
Segher
-
To
There's an extra tab in that last line. Could you also
please fix the indenting (use a tab, not spaces) -- I know
it was there originally, but since there are only a few
lines in that file like that... :-)
how's this one?
I meant fix all the wrongly indented lines in that file (there
are
-#define setcc(cc) ({ \
+#define setcc(cc) do { \
partial_status &= ~(SW_C0|SW_C1|SW_C2|SW_C3); \
- partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); })
+ partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); \
+ } while (0)
There's an extra tab in that last line. Could you also
I want this:
char v[4];
...
memcmp(v, "abcd", 4) == 0
compile to single cmpl on i386. This (gcc 4.1.1) is ridiculous:
callmemcmp
i686-linux-gcc (GCC) 4.2.0 20060410 (experimental)
movl$4, %ecx#, tmp65
cld
movl$v, %esi#,
setcc() in math-emu is written as a gcc extension statement expression
macro that returns a value. However, it's not used that way and it's
not needed like that, so just make it a do-while non-extension macro
so that we don't use an extension when it's not needed.
Looks fine, except
-#define
setcc() in math-emu is written as a gcc extension statement expression
macro that returns a value. However, it's not used that way and it's
not needed like that, so just make it a do-while non-extension macro
so that we don't use an extension when it's not needed.
Looks fine, except
-#define
I want this:
char v[4];
...
memcmp(v, abcd, 4) == 0
compile to single cmpl on i386. This (gcc 4.1.1) is ridiculous:
callmemcmp
i686-linux-gcc (GCC) 4.2.0 20060410 (experimental)
movl$4, %ecx#, tmp65
cld
movl$v, %esi#,
-#define setcc(cc) ({ \
+#define setcc(cc) do { \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
- partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); })
+ partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); \
+ } while (0)
There's an extra tab in that last line. Could you also
please
There's an extra tab in that last line. Could you also
please fix the indenting (use a tab, not spaces) -- I know
it was there originally, but since there are only a few
lines in that file like that... :-)
how's this one?
I meant fix all the wrongly indented lines in that file (there
are
For a different mailing list indeed; let me just point
out
that for certain important quite common cases it's an
~50%
overall speedup.
Hmm, what code was that? 'signed int does not wrap around' does not
seem to provide _that_ much info...
One of the recent huge threads on the GCC dev list has
For a different mailing list indeed; let me just point
out
that for certain important quite common cases it's an
~50%
overall speedup.
Hmm, what code was that? 'signed int does not wrap around' does not
seem to provide _that_ much info...
One of the recent huge threads on the GCC dev list has
The largest value we use here is 0x0200. Perhaps v4l2_std_id
shouldn't
be 64-bit?
Too late to change it to 32 bits. It is at V4L2 userspace API since
kernel 2.6.0. We can, however use this approach as a workaround, with
the proper documentation.
Maybe with a BUG_ON(id > UINT_MAX) ?
If
The largest value we use here is 0x0200. Perhaps v4l2_std_id
shouldn't
be 64-bit?
Too late to change it to 32 bits. It is at V4L2 userspace API since
kernel 2.6.0. We can, however use this approach as a workaround, with
the proper documentation.
Maybe with a BUG_ON(id UINT_MAX) ?
If
(in which case, nearly all real-world code is broken)
Not "nearly all" -- but lots of code, yes.
I wouldn't say "lots of code". I would say "all real projects".
All projects that tell the compiler they're written in ISO C,
while they're not, can easily break, sure. You can't say this
is
I'll happily turn off compiler features that are "clever optimizations
that never actually matter in practice, but are just likely to possible
cause problems".
The "signed wrap is undefined" thing doesn't fit in this category
though:
-- It is an important optimisation for loops with a signed
Lack of the flag does not break any valid C code, only code
making unwarranted assumptions (i.e., buggy code).
Right, if "C" means "strictly conforming ISO C" to you.
Without any further qualification, it of course does, yes.
(in which case, nearly all real-world code is broken)
Not
Adjusting gcc flags to eliminate optimizations is another way to go.
Adding -fwrapv would be an excellent start. Lack of this flag breaks
most code which checks for integer wrap-around.
Lack of the flag does not break any valid C code, only code
making unwarranted assumptions (i.e., buggy
Adjusting gcc flags to eliminate optimizations is another way to go.
Adding -fwrapv would be an excellent start. Lack of this flag breaks
most code which checks for integer wrap-around.
Lack of the flag does not break any valid C code, only code
making unwarranted assumptions (i.e., buggy
Lack of the flag does not break any valid C code, only code
making unwarranted assumptions (i.e., buggy code).
Right, if C means strictly conforming ISO C to you.
Without any further qualification, it of course does, yes.
(in which case, nearly all real-world code is broken)
Not nearly
I'll happily turn off compiler features that are clever optimizations
that never actually matter in practice, but are just likely to possible
cause problems.
The signed wrap is undefined thing doesn't fit in this category
though:
-- It is an important optimisation for loops with a signed
(in which case, nearly all real-world code is broken)
Not nearly all -- but lots of code, yes.
I wouldn't say lots of code. I would say all real projects.
All projects that tell the compiler they're written in ISO C,
while they're not, can easily break, sure. You can't say this
is GCC's
One would also expect that cache scrubbing requires hardware
support.
You could just write-back invalidate the whole cache
periodically if there is no explicit hardware support
for cache scrubbing. Less efficient, sure :-)
Signed-off-by: doug thompson <[EMAIL PROTECTED]>
Shouldn't
Across different boots using the same 2.6.19 kernel on a quad-core xeon
I see huge variance in the migration_cost being reported during boot.
-migration_cost=39,3940
+migration_cost=25,4941
This CPU has a very large cache which could be key here...
L1 Instruction cache: 32KB, 8-way
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It simply
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
Hopefully this patch should solve steve's issue too.
Sure looks like it.
o Older binutils required explicit flags to mark a section allocatable
and executable(AX). Newer binutils automatically mark a section AX if
the name starts with .text.
More exactly, since 2.15 more section names
Across different boots using the same 2.6.19 kernel on a quad-core xeon
I see huge variance in the migration_cost being reported during boot.
-migration_cost=39,3940
+migration_cost=25,4941
This CPU has a very large cache which could be key here...
L1 Instruction cache: 32KB, 8-way
Hopefully this patch should solve steve's issue too.
Sure looks like it.
o Older binutils required explicit flags to mark a section allocatable
and executable(AX). Newer binutils automatically mark a section AX if
the name starts with .text.
More exactly, since 2.15 more section names
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It simply
One would also expect that cache scrubbing requires hardware
support.
You could just write-back invalidate the whole cache
periodically if there is no explicit hardware support
for cache scrubbing. Less efficient, sure :-)
Signed-off-by: doug thompson [EMAIL PROTECTED]
Shouldn't you
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, "fix"
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
The comment used to be inside the "if" block, is this
change correct?
You'd prefer an empty line in there?
Obviously, you should change the comment to include the
conditional, if that is what is needed.
[And, do we want all these changes anyway? I don't care
either way, both sides have
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes & properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits,
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that "that's what the
current ports do"?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a
static void __devinit vio_dev_release(struct device *dev)
{
- if (dev->archdata.of_node) {
- /* XXX should free TCE table */
- of_node_put(dev->archdata.of_node);
- }
+ /* XXX should free TCE table */
+ of_node_put(dev->archdata.of_node);
Segher had suggested to use .section command to specifically mark
.text.head section as AX (allocatable and executable) to solve the
problem.
Great to hear it works in real life too.
Here, have a From: line (or how should this patch history be
encoded?) :-)
From: Segher Boessenkool <[EM
Simple system tools should not need to interpret binary data in
order to provide access to simple structured data like this, that's
just stupid.
I would agree with you if the data was properly typed in the first
place
but it's not,
OF device tree properties are "properly typed" just fine --
IMHO, the directory entries in the filesystem
should be in the form "[EMAIL PROTECTED]" (eg: /[EMAIL PROTECTED],0,
"pci" is the node name, "@" is the separator character defined
by IEEE 1275, and "1f,0" is the unit-address,
which are always guaranteed to be unique.
They should be. The problem
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for everything, heh.
We have well defined interfaces to access that
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something like drivers/of1394 maybe.
1394? :-)
Thus if i386 is going to
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a different matter, we created
that for the sake of kexec and embedded devices
There is one big problem: text representation is useless
(to scripts etc.) unless it can be transformed back to binary;
i.e., it has to be possible to reliably detect _how_ some
property is represented into text, something that cannot be
done with how openpromfs handles it.
Text is text is text
It has proved a good idea in general as I can easily get an exact
device-tree dump from users by asking for a tarball of
/proc/device-tree
and in some case, the data in there -is- binary (For example, the EDID
properties for monitors left by video drivers, or things like that).
Yes and with
It has proved a good idea in general as I can easily get an exact
device-tree dump from users by asking for a tarball of
/proc/device-tree
and in some case, the data in there -is- binary (For example, the EDID
properties for monitors left by video drivers, or things like that).
Yes and with
There is one big problem: text representation is useless
(to scripts etc.) unless it can be transformed back to binary;
i.e., it has to be possible to reliably detect _how_ some
property is represented into text, something that cannot be
done with how openpromfs handles it.
Text is text is text
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a different matter, we created
that for the sake of kexec and embedded devices
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something like drivers/of1394 maybe.
1394? :-)
Thus if i386 is going to
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for everything, heh.
We have well defined interfaces to access that
IMHO, the directory entries in the filesystem
should be in the form [EMAIL PROTECTED] (eg: /[EMAIL PROTECTED],0,
pci is the node name, @ is the separator character defined
by IEEE 1275, and 1f,0 is the unit-address,
which are always guaranteed to be unique.
They should be. The problem is buggy
Simple system tools should not need to interpret binary data in
order to provide access to simple structured data like this, that's
just stupid.
I would agree with you if the data was properly typed in the first
place
but it's not,
OF device tree properties are properly typed just fine --
Segher had suggested to use .section command to specifically mark
.text.head section as AX (allocatable and executable) to solve the
problem.
Great to hear it works in real life too.
Here, have a From: line (or how should this patch history be
encoded?) :-)
From: Segher Boessenkool [EMAIL
static void __devinit vio_dev_release(struct device *dev)
{
- if (dev-archdata.of_node) {
- /* XXX should free TCE table */
- of_node_put(dev-archdata.of_node);
- }
+ /* XXX should free TCE table */
+ of_node_put(dev-archdata.of_node);
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that that's what the
current ports do?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a good
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF
The comment used to be inside the if block, is this
change correct?
You'd prefer an empty line in there?
Obviously, you should change the comment to include the
conditional, if that is what is needed.
[And, do we want all these changes anyway? I don't care
either way, both sides have their
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, fix
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device tree
If you *really* want (the option of) showing things as text
in the filesystem, you better make it so that there is a
one-to-one translation back to binary. For example, what
does this mean, is it a text string or two bytes:
01.02
Yes you as a user can guess, but scripts can't (reliably).
We
If people want to return something from a ({ }) construct, they should
do it
explicitly, e.g.
#define setcc(cc) ({ \
partial_status &= ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status; \
})
No, they generally should use
Not the same exact thing -- using a text representation for
the property contents is a very different thing (and completely
braindead).
The filesystem bit is for groveling around and getting information
from the shell prompt, or shell scripts. Text processing.
If you want the binary bits,
Not the same exact thing -- using a text representation for
the property contents is a very different thing (and completely
braindead).
The filesystem bit is for groveling around and getting information
from the shell prompt, or shell scripts. Text processing.
If you want the binary bits,
If people want to return something from a ({ }) construct, they should
do it
explicitly, e.g.
#define setcc(cc) ({ \
partial_status = ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) (SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status; \
})
No, they generally should use
If you *really* want (the option of) showing things as text
in the filesystem, you better make it so that there is a
one-to-one translation back to binary. For example, what
does this mean, is it a text string or two bytes:
01.02
Yes you as a user can guess, but scripts can't (reliably).
We
#define setcc(cc) ({ \
partial_status &= ~(SW_C0|SW_C1|SW_C2|SW_C3); \
partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); })
This _does_ return a value though, bad example.
Where does it return a value?
partial_status |=
I don't see any uses of it
Ah, that's a separate thing
Some comments, mostly coding style:
- 0xb0 - 0x13f Free. Add more parameters here if you really need them.
+ 0xb0 16 bytes Open Firmware information (magic, version, callback,
idt)
Is there an OF ISA binding for x86 somewhere? And don't
point me to the source code, I'd like to
I would not exactly call what we have for powerpc
"exporting the OFW device tree". I don't quite know
what it is, but it isn't as simple as exporting the
OFW device tree. I don't think we really wanted to
get into any of that here.
The Linux PowerPC port uses an OF-like device tree on
*every*
+A regular file in ofwfs contains the exact byte sequence that
+comprises the OFW property value. Properties are not reformatted
+into text form, so numeric property values appear as binary
+integers. While this is inconvenient for viewing, it is generally
+easier for programs that read
701 - 800 of 836 matches
Mail list logo
