yyerror() is used by both dtc-parser.y and dtc-lexer.l, so move
the declaration to srcpos.h.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
eliminates implicit declaration warning.
Index: dtc/dtc-parser.y
===
---
Change the grow_data_for function to copy struct data and
modifiy the fields it is updating instead of storing all
fields individually to a stack allocated struct.
This reduces maintence for future enhancements as now all
instances of struct data are created by modifying a copy
of an existing
When writing the memory reserve table in assembly output,
emit both halves of each 64 bit number on a single .long
statement. This results in two lines per memory reserve
slot instead of four, each line contains one field (start
or size).
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
Create a source file with labels for use as a testcase
to check parsing dts files.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
I started with the existing test01.dts and added labels and
a labeled subnode.
The labels could instead be added to that file if desired,
but that would mean
On Sat, Jul 07, 2007 at 01:49:00PM +0400, Vitaly Bordug wrote:
This updates relevant platform code
(freescale mpc8349itx target) to make the CompactFlash
work in TrueIDE mode.
Shouldn't you be writing a PCMCIA driver instead for the CF, so it
handles other devices as well? Then you get
Hello.
Vitaly Bordug wrote:
This updates relevant platform code
(freescale mpc8349itx target) to make the CompactFlash
work in TrueIDE mode.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
It would have been good if you tried to actualy
The bootwrapper already handles a 'reg-shift' property on serial ports
and does the right thing. However, these ports really shouldn't be
claiming to be compatible with 'ns16550'. Introduce a new 'sparse16550'
type for them instead.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git
Hello.
David Woodhouse wrote:
Given the existence of the boards, it looks correct to do this.
However, I wonder if it was correct for the MV64660 to claim
compatibily witn ns16550 if the programming model is not exactly
the same. The official OF serial port bindings don't mention the
reg-shift
On Saturday 07 July 2007, Sergei Shtylyov wrote:
the reg-shift property. I'll send a patch shortly, and I'll reorder the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Certainly. BTW, was there really ns8250 -- 8250 is
On Saturday 07 July 2007, David Woodhouse wrote:
Can we add properties to indicate the common high-speed modes too? The
Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not
Hello.
Vitaly Bordug wrote:
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
[...]
diff --git a/drivers/ide/legacy/mmio-ide.c b/drivers/ide/legacy/mmio-ide.c
new
On Saturday 07 July 2007, Sergei Shtylyov wrote:
Arnd Bergmann wrote:
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
Hmm, are we still adding new IDE drivers? Do
On Sat, 07 Jul 2007 13:48:52 +0400
Vitaly Bordug [EMAIL PROTECTED] wrote:
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Really we should be working towards libata support for all new devices.
This looks like a candidate for the existing (or a little enhanced)
Ah yes, my mistake. Does it require a repost then ?
Thanks,
Manish
Linas Vepstas wrote:
You want to say its a patch in the subject line.
--linas
On Fri, Jul 06, 2007 at 04:59:55PM -0500, Manish Ahuja wrote:
Found 2 instances of return one right after each other in
arch_add_memory().
Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
the reg-shift property. I'll send a patch shortly, and I'll reorder
the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Can we add properties to indicate
Given the existence of the boards, it looks correct to do this.
However, I wonder if it was correct for the MV64660 to claim
compatibily witn ns16550 if the programming model is not exactly
the same. The official OF serial port bindings don't mention the
reg-shift property, so it maybe would
No, you're right. http://playground.sun.com/1275/proposals/Closed/
Accepted/384-it.txt
actually mentions that the the name should be i8250. It also
mentions
that the compatible property should contain pnpPNP,501 for
ns16450 and
higher,
16550 and higher
and pnpPNP,500 for all serial
Can we add properties to indicate the common high-speed modes too?
The
Natsemi baud-base thing could be autodetected by 8250.c if you'd
let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not have enough understanding about the
On 7/6/07, Grant Likely [EMAIL PROTECTED] wrote:
On 7/6/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Saturday 07 July 2007, Grant Likely wrote:
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -63,6 +63,8 @@ static void __init
On Sat, 2007-07-07 at 21:02 +0100, Alan Cox wrote:
You could also make it an of_platform_driver at the same time
instead of adding more cruft to fsl_soc.c. Since we're already
about to add the electra_ide.c driver in 2.6.23, I guess there
should really be _one_ driver that is able to
20 matches
Mail list logo
