* Re: copy_from_user problem
From: Nathan Lynch @ 2008-02-26 15:01 UTC (permalink / raw)
To: Maynard Johnson; +Cc: linuxppc-dev
In-Reply-To: <47C426F8.7070203@us.ibm.com>
Maynard Johnson wrote:
>
> static long lib_addr;
> module_param(lib_addr, long, 0);
^^^^
Should be unsigned long?
^ permalink raw reply
* Re: [RFC][PATCH] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Josh Boyer @ 2008-02-26 15:02 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <47C41DBE.7090505@harris.com>
On Tue, 26 Feb 2008 09:10:06 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:
> When I saw Josh's question, I thought the irq save/restore was there to
> make the read-modify-write atomic; i.e. read SDR0_MFR, "AND" out some
> bits, then write it back without the possibility of anything else
> touching SDR0_MFR. I'm just starting to get familiar with the kernel,
That was probably the intention, yes.
> so if you have a chance, please help educate me. Does the irq lock in
> mtdcri protect the read-modify-write? Or maybe this R-M-W doesn't need
> protecting?
Nope, it doesn't. It is possible for something to come in between the
first call to mtdcri and the second call to mtdcri and modify the
value. The window would be quite small, but I suppose it's
theoretically possible.
Seems the code will do the right thing since everything is using
flags. I suppose my question can be withdrawn. It is slightly
confusing to do it that way though. Perhaps a function to do
read-modify-writes on DCRs would be welcome. dcr_modify anyone?
josh
^ permalink raw reply
* Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
From: Adrian Bunk @ 2008-02-26 15:15 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linuxppc-dev, sam, Linux Kernel Mailing List, linux-kbuild
In-Reply-To: <47C42234.6060906@linux.vnet.ibm.com>
On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
> the .config has been attached.
>...
Builds fine here.
Local problem (e.g. disk full) on your machine?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re:[PATCH] Fix wrapper platform for adder875, and combine
From: Rognlien Dag Kristian @ 2008-02-26 15:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <mailman.679.1203532411.17968.linuxppc-dev@ozlabs.org>
This patch from the 20th of February has not been taken into the latest
powerpc.git
Mvh,
Dag Rognlien=20
Date: Wed, 20 Feb 2008 12:33:38 -0600
From: Scott Wood <scottwood@freescale.com>
Subject: [PATCH] Fix wrapper platform for adder875, and combine
defconfigs.
To: galak@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Message-ID: <20080220183338.GA9282@loki.buserror.net>
Content-Type: text/plain; charset=3Dus-ascii
This fixes the following bug:
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051979.html
Separate defconfigs are no longer needed now that CONFIG_DEVICE_TREE is
gone.
Signed-off-by: Scott Wood <scottwood@freescale.com>
^ permalink raw reply
* Re: copy_from_user problem
From: Nathan Lynch @ 2008-02-26 15:30 UTC (permalink / raw)
To: Maynard Johnson; +Cc: linuxppc-dev
In-Reply-To: <20080226150138.GD16241@localdomain>
Nathan Lynch wrote:
> Maynard Johnson wrote:
> >
> > static long lib_addr;
> > module_param(lib_addr, long, 0);
> ^^^^
> Should be unsigned long?
ulong, rather, but that doesn't fix it.
In any case, lib_addr is a user virtual address; doesn't the kernel
need to do get_user_pages or some such to get at arbitrary process
memory?
^ permalink raw reply
* Re: copy_from_user problem
From: Maynard Johnson @ 2008-02-26 15:36 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080226150138.GD16241@localdomain>
Nathan Lynch wrote:
> Maynard Johnson wrote:
>> static long lib_addr;
>> module_param(lib_addr, long, 0);
> ^^^^
> Should be unsigned long?
Right. I switched this to 'ulong', but that didn't make a difference in
my test results.
>
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-26 17:26 UTC (permalink / raw)
To: jdl, linuxppc-dev
In-Reply-To: <20080226003955.GA24382@localhost.localdomain>
On Tue, Feb 26, 2008 at 11:39:55AM +1100, David Gibson wrote:
> > diff --git a/Makefile b/Makefile
> > index 8a47c34..d4d935c 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -16,7 +16,7 @@ LOCAL_VERSION =
> > CONFIG_LOCALVERSION =
> >
> > CPPFLAGS = -I libfdt
> > -CFLAGS = -Wall -g -Os
> > +CFLAGS = -Wall -g -Os -D_FILE_OFFSET_BITS=64
>
> Is this portable?
It seems fairly widespread, but I don't know if it's specified by any
standards. Some googling shows that _LARGE_FILES and _LARGEFILE64_SOURCE
are used in some environments.
> > d.len = len;
> > - fread(d.val, len, 1, f);
> > + if (fread(d.val, len, 1, f) != 1) {
> > + yyerrorf("Couldn't read %zu bytes from file: %s",
> > + len, feof(f) ? "end-of-file" : strerror(errno));
> > + return empty_data;
>
> Ugh.
> 1) Error messages direct to the user really don't belong in
> data.c's low-level support routines. This does mean we might need to
> substantially change this function so there's some other way of
> reporting the error to the caller who can report it.
Any suggestions on a mechanism that doesn't throw away information by
condensing everything down to a single error number?
> 2) The horrid name 'yyerror()' exists only to match what bison
> expects. It should never be used outside the parse code (we probably
> should create more generally usable error/warning functions, though).
Fine, so suggest a name.
> 3) Is %zu portable?
I believe it's part of C99.
> > + }
> > +
> > + return d;
> > +}
> > +
> > +struct data data_copy_file_all(FILE *f)
>
> It should be possible to combine these two functions.
Probably.
> > + d = data_grow_for(d, ret);
> > + memcpy(d.val + d.len, buf, ret);
> > +
> > + if (d.len + ret < d.len) {
> > + yyerror("Binary include too large");
>
> Hrm. A test which will cover this case should go into
> data_grow_for(), I think.
Agreed.
-Scott
^ permalink raw reply
* MMC over SPI on Virtex-4
From: Brian Silverman @ 2008-02-26 16:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Hello all,
I'm attempting to get MMC over xilinx_spi working on a custom Xilinx
Virtex-4 board (that has a working SD/SPI interface, tested with a
standalone app).
I'm having issues mounting the device, and after doing a bit of
debugging, I'm confused about how things are supposed to work. I'm
using 2.6.24-rc8-xlnx from git.xilinx.com, with some patches (for the
uartlite (Grant Likely), and other minor things). In addition, I'm
using some of a patch from Andrei Konovalov (
<list?person=202&id=11577>http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11577)
for Xilinx SPI support in virtex_devices.c (BTW, will this patch hit the
main git.xilinx.com tree at some point?)
Here's what I do, and what I see:
- Create a block device: "mknod /dev/m0 b 179 0"
- Access that device ("cat /dev/m0")
- I see the calls into the kernel:
blkdev_open()
do_open()
get_gendisk()
kobj_lookup(bdev_map, ...)
- The device is not found (bdev_map has been initialized, but the only
"probe" at major 179 is base_probe().
- kobj_lookup() returns NULL, and the open returns ENXIO (No such device
or address).
Here's what I don't understand: In order for kobj_lookup to
successfully return non-NULL, a "probe" has to have been added to
bdev_map using kobj_map(). But, kobj_map(bdev_map,...) is called only
by blk_register_region(), which is never called by the MMC driver.
I'm clearly missing something here. Has anyone successfully used MMC
over SPI or xilinx_spi? How is the MMC driver supposed to work in
regards to opening a device?
Also, for reference:
I've added the following configs:
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_BITBANG=y
CONFIG_SPI_XILINX=y
CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_MMC_SPI=y
And, /proc/devices does report the mmc device:
# cat /proc/devices
Character devices:
1 mem
4 /dev/vc/0
4 tty
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
128 ptm
136 pts
204 ttyUL
Block devices:
1 ramdisk
179 mmc
--
Brian Silverman
Concept X, LLC
[-- Attachment #2: Type: text/html, Size: 2816 bytes --]
^ permalink raw reply
* Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
From: Kamalesh Babulal @ 2008-02-26 18:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, sam, Linux Kernel Mailing List, linux-kbuild
In-Reply-To: <20080226151512.GA10717@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
>> Hi,
>>
>> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
>> the .config has been attached.
>> ...
>
> Builds fine here.
>
> Local problem (e.g. disk full) on your machine?
>
> cu
> Adrian
>
Hi Adrain,
It Builds fine on another powerpc box with the same .config file, the problem seems to be with the gcc
on that box, the reported build failure might have been the side effect of the same.
drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
drivers/md/raid6int8.c:185: error: unable to find a register to spill in class `FLOAT_REGS'
drivers/md/raid6int8.c:185: error: this is the insn:
(insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI (reg/v/f:DI 122 [ p ])
(reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
(reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
(expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
(nil)))
drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
make[2]: *** [drivers/md/raid6int8.o] Error 1
make[1]: *** [drivers/md] Error 2
make: *** [drivers] Error 2
# gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [patch 0/6] pasemi_mac updates for 2.6.26
From: Jeff Garzik @ 2008-02-26 18:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, pasemi-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <20080226141624.GB22572@lixom.net>
Olof Johansson wrote:
> On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
>> Olof Johansson writes:
>>
>>> Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
>>> the dma_lib in the platform code as well, but it's easier if it's all
>>> merged through netdev to avoid dependencies.
>>>
>>> Major highlights are jumbo frame support and ethtool basics, the rest
>>> is mostly minor plumbing around it.
>> What route do you think these should take upstream? I'm happy to take
>> them if Jeff is OK with that.
>
> I've sent them through Jeff in the past, that's been convenient when
> there's been churn in the network APIs. I'm not sure if there's much of
> that for .26 though.
>
> If Jeff prefers to ACK, I'll just add it to my git and ask you to pull
> that. But I was originally planning to just feed it through him.
>
> (Note: I'll repost the patch set later today or tomorrow with a couple
> of tweaks).
Not much networking churn for 2.6.26, and IMO this patchset have
above-average ppc changes/dependencies, so.... ACK
^ permalink raw reply
* Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
From: Adrian Bunk @ 2008-02-26 18:25 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linuxppc-dev, sam, Linux Kernel Mailing List, linux-kbuild
In-Reply-To: <47C457F5.4080902@linux.vnet.ibm.com>
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
> Adrian Bunk wrote:
> > On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
> >> the .config has been attached.
> >> ...
> >
> > Builds fine here.
> >
> > Local problem (e.g. disk full) on your machine?
> >
> > cu
> > Adrian
> >
> Hi Adrain,
Hi Kamalseh, ;)
> It Builds fine on another powerpc box with the same .config file, the problem seems to be with the gcc
> on that box, the reported build failure might have been the side effect of the same.
>
>
> drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
> drivers/md/raid6int8.c:185: error: unable to find a register to spill in class `FLOAT_REGS'
> drivers/md/raid6int8.c:185: error: this is the insn:
> (insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI (reg/v/f:DI 122 [ p ])
> (reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
> (reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
> (expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
> (nil)))
> drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
> make[2]: *** [drivers/md/raid6int8.o] Error 1
> make[1]: *** [drivers/md] Error 2
> make: *** [drivers] Error 2
>
> # gcc --version
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
this means your quite old vendor gcc has a bug.
> Thanks & Regards,
> Kamalesh Babulal,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Define CONFIG_PPC_NEW_BINDING
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-26 18:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
Hi All,
In order to define CONFIG_PPC_NEW_BINDING, which kernel configuration
parameters should be selected (i.e. .config file)?
Thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 811 bytes --]
^ permalink raw reply
* Re: [patch 0/6] pasemi_mac updates for 2.6.26
From: Olof Johansson @ 2008-02-26 18:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, pasemi-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <47C4588C.5060904@pobox.com>
On Tue, Feb 26, 2008 at 01:21:00PM -0500, Jeff Garzik wrote:
> Olof Johansson wrote:
> > On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
> >> What route do you think these should take upstream? I'm happy to take
> >> them if Jeff is OK with that.
> >
> > I've sent them through Jeff in the past, that's been convenient when
> > there's been churn in the network APIs. I'm not sure if there's much of
> > that for .26 though.
> >
> > If Jeff prefers to ACK, I'll just add it to my git and ask you to pull
> > that. But I was originally planning to just feed it through him.
> >
> > (Note: I'll repost the patch set later today or tomorrow with a couple
> > of tweaks).
>
> Not much networking churn for 2.6.26, and IMO this patchset have
> above-average ppc changes/dependencies, so.... ACK
Ok, thanks Jeff.
Paul: I'll commit to my tree and ask you to pull later.
-Olof
^ permalink raw reply
* Re: Define CONFIG_PPC_NEW_BINDING
From: Scott Wood @ 2008-02-26 18:57 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-dev
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AAF2@xmb-sjc-212.amer.cisco.com>
On Tue, Feb 26, 2008 at 10:31:21AM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi All,
> In order to define CONFIG_PPC_NEW_BINDING, which kernel configuration
> parameters should be selected (i.e. .config file)?
The kconfig entry for your board should contain the line
"select PPC_CPM_NEW_BINDING".
-Scott
^ permalink raw reply
* Porting ISP1760 USB host controller driver to Virtex ppc405 arch linux
From: alex_snippet @ 2008-02-26 21:04 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody, how to port ISP1760 USB host controller driver to Virtex ppc405
arch linux?
It has been ported to blackfin arch
http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?action=browse&path=%2Ftrunk%2Fdrivers%2Fusb%2Fhost%2Fpehcd%2Fhost%2F&pathrev=2763
--
View this message in context: http://www.nabble.com/Porting-ISP1760-USB-host-controller-driver-to-Virtex-ppc405-arch-linux-tp15699965p15699965.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: David Miller @ 2008-02-26 21:34 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, sfr
In-Reply-To: <18371.54796.174623.988521@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Tue, 26 Feb 2008 20:04:12 +1100
> It would probably be good to defend against the possibility that the
> property isn't null-terminated (for example if its length is zero).
FWIW, when I pull in the device tree on sparc I eliminate any need for
those kinds of checks by putting a '\0' at the end of every property
blob.
I copied a lot of this code from you guys, so it wouldn't surprise
me if ppc does this too. :-)
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Benjamin Herrenschmidt @ 2008-02-26 21:45 UTC (permalink / raw)
To: David Miller; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20080226.133430.41760910.davem@davemloft.net>
On Tue, 2008-02-26 at 13:34 -0800, David Miller wrote:
> From: Paul Mackerras <paulus@samba.org>
> Date: Tue, 26 Feb 2008 20:04:12 +1100
>
> > It would probably be good to defend against the possibility that the
> > property isn't null-terminated (for example if its length is zero).
>
> FWIW, when I pull in the device tree on sparc I eliminate any need for
> those kinds of checks by putting a '\0' at the end of every property
> blob.
>
> I copied a lot of this code from you guys, so it wouldn't surprise
> me if ppc does this too. :-)
I doubt we do that. Properties that contain things like ranges, or "reg"
properties are expected to be of a size that is a multiple of
#size-cells/#address-cells and I'm not sure that won't break things here
or there if they suddenly get one more byte..
Or do you mean you/we are appending that-without- changing the length
field ?
Ben.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: David Miller @ 2008-02-26 22:44 UTC (permalink / raw)
To: benh; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <1204062337.15052.160.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 27 Feb 2008 08:45:37 +1100
> I doubt we do that. Properties that contain things like ranges, or "reg"
> properties are expected to be of a size that is a multiple of
> #size-cells/#address-cells and I'm not sure that won't break things here
> or there if they suddenly get one more byte..
>
> Or do you mean you/we are appending that-without- changing the length
> field ?
Right, simply don't change the length field. Put the zero byte
at offset "length + 1"
It's stupid to validate NULL termination everywhere when we
can make it an invariant in one spot.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Benjamin Herrenschmidt @ 2008-02-26 22:58 UTC (permalink / raw)
To: David Miller; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20080226.144423.138965691.davem@davemloft.net>
On Tue, 2008-02-26 at 14:44 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 27 Feb 2008 08:45:37 +1100
>
> > I doubt we do that. Properties that contain things like ranges, or "reg"
> > properties are expected to be of a size that is a multiple of
> > #size-cells/#address-cells and I'm not sure that won't break things here
> > or there if they suddenly get one more byte..
> >
> > Or do you mean you/we are appending that-without- changing the length
> > field ?
>
> Right, simply don't change the length field. Put the zero byte
> at offset "length + 1"
>
> It's stupid to validate NULL termination everywhere when we
> can make it an invariant in one spot.
Fair enough.
Ben.
^ permalink raw reply
* Re: copy_from_user problem
From: Benjamin Herrenschmidt @ 2008-02-26 23:22 UTC (permalink / raw)
To: maynardj; +Cc: linuxppc-dev
In-Reply-To: <47C426F8.7070203@us.ibm.com>
On Tue, 2008-02-26 at 08:49 -0600, Maynard Johnson wrote:
> 2. Compile C program as 32-bit; then run it. While the program is
> waiting for input, obtain its PID and do 'cat /proc/<pid>/maps' to
> get
> the address of where libc is loaded.
> 3. From the dir where you build the uaccess_test kernel module:
> 'insmod ./uaccess_test.ko lib_addr=0x<mem_loc_libc>'
> This should succeed. dmesg to verify.
> 4. Unload the module.
> 5. Recompile your C program with -m64; start it up and obtain the
> address of libc again (now a 64-bit address).
> 6. Load the uaccess_test kernel module and pass
> 'lib_addr=0x<mem_loc_libc>'. Note that this time, the load fails.
> dmesg to see debug printk's.
Sounds to me that your kernel module will try to copy_from_user() from
the user context of ... insmod :-)
You need to do your copy_from_user() from within the context of the
program you try to access the memory from !
If you need to access another context than the current one, you then
need to use a different mechanism, such as get_user_pages(), though
beware that you can only do that for memory, not SPE local store or
register mappings.
Ben.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Josh Boyer @ 2008-02-26 23:53 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus, sfr
In-Reply-To: <20080226.144423.138965691.davem@davemloft.net>
On Tue, 26 Feb 2008 14:44:23 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 27 Feb 2008 08:45:37 +1100
>
> > I doubt we do that. Properties that contain things like ranges, or "reg"
> > properties are expected to be of a size that is a multiple of
> > #size-cells/#address-cells and I'm not sure that won't break things here
> > or there if they suddenly get one more byte..
> >
> > Or do you mean you/we are appending that-without- changing the length
> > field ?
>
> Right, simply don't change the length field. Put the zero byte
> at offset "length + 1"
>
> It's stupid to validate NULL termination everywhere when we
> can make it an invariant in one spot.
I don't mind fixing up the function to use strncmp and checking for a 0
length from of_get_property. However, I'm almost certain that other
places in the code have the same issue so what you're saying here seems
to make sense.
josh
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Benjamin Herrenschmidt @ 2008-02-27 0:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18371.65529.312001.673609@cargo.ozlabs.ibm.com>
On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt (1):
> [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
>
Any reason why this isn't going into .25 ?
Ben.
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Paul Mackerras @ 2008-02-27 0:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1204070815.15052.194.camel@pasglop>
Benjamin Herrenschmidt writes:
> On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> > Benjamin Herrenschmidt (1):
> > [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
> >
>
> Any reason why this isn't going into .25 ?
I thought you said nothing uses it.
Paul.
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Benjamin Herrenschmidt @ 2008-02-27 0:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18372.45605.265760.646342@cargo.ozlabs.ibm.com>
On Wed, 2008-02-27 at 11:43 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> > > Benjamin Herrenschmidt (1):
> > > [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
> > >
> >
> > Any reason why this isn't going into .25 ?
>
> I thought you said nothing uses it.
I'm worried some out of tree stuff might...
But if not, yeah, it's fine.
Ben.
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Paul Mackerras @ 2008-02-27 1:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <12F84CB4-8344-4F70-A89F-4A1FF590C35C@kernel.crashing.org>
Kumar Gala writes:
> How do you plan on managing the powerpc-next branch in the future?
> For example, I assume at some point linus will pull it into what would
> be 2.6.26. Would you rebase this branch? etc.
Yes, it is basically the for-2.6.26 branch. I will try very hard not
to rebase it, but I don't promise that I will never rebase it.
I'm expecting to get requests to pull your tree into it, as well as
Josh's, Grant's, etc., once you have stuff that you are reasonably
confident should go in to the next release and won't need to be
rebased.
Paul.
^ 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