* Re: Badness with the kernel version 2.6.35-rc1-git1 running on P6 box
From: David Miller @ 2010-07-18 21:51 UTC (permalink / raw)
To: eric.dumazet
Cc: sachinp, netdev, linux-kernel, linuxppc-dev, ossthema, dipraksh
In-Reply-To: <1279282842.2549.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 16 Jul 2010 14:20:42 +0200
> Le vendredi 16 juillet 2010 =E0 11:56 +0200, Eric Dumazet a =E9crit :=
> =
>> [PATCH] ehea: ehea_get_stats() should use GFP_KERNEL
>> =
>> ehea_get_stats() is called in process context and should use GFP_KER=
NEL
>> allocation instead of GFP_ATOMIC.
>> =
>> Clearing stats at beginning of ehea_get_stats() is racy in case of
>> concurrent stat readers.
>> =
>> get_stats() can also use netdev net_device_stats, instead of a priva=
te
>> copy.
>> =
>> Reported-by: divya <dipraksh@linux.vnet.ibm.com>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> ---
>> drivers/net/ehea/ehea.h | 1 -
>> drivers/net/ehea/ehea_main.c | 6 ++----
>> 2 files changed, 2 insertions(+), 5 deletions(-)
>> =
>> =
> =
> Hmm, net-next-2.6 contains following patch :
If people think ehea usage is ubiquitous enough to deserve a backport
of this to net-2.6, fine. But personally I don't think it's worth it.
Can someone close the kernel bugzilla 16406 created for this bug? This=
patch we have already obviously would fix this issue.
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Benjamin Herrenschmidt @ 2010-07-18 23:41 UTC (permalink / raw)
To: Grant Likely; +Cc: Matthew McClintock, Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <AANLkTimiM1Ky7aIYoQ3efhivypV90LFG-BpueuaPaiPf@mail.gmail.com>
On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock <msm@freescale.com> wrote:
> > To build a proper flat device tree for kexec we need to know which
> > memreserve region was used for the device tree for the currently
> > running kernel, so we can remove it and replace it with the new
> > memreserve for the kexec'ed kernel
> >
> > Signed-off-by: Matthew McClintock <msm@freescale.com>
>
> Hi Matthew.
>
> I don't understand. Why does userspace need to know about the old
> memreserve sections? Doesn't kexec tear down all of the old
> allocations anyway? How are they relevant for constructing the dtb
> for the kexec kernel? I'll need a lot more details before I consider
> merging this.
>
> Also, please cc: me and Ben Herrenschmidt on powerpc related device
> tree changes.
I admit to be the victim of a similar misunderstanding...
Care to explain in more details ? (with examples)
Cheers,
Ben.
> Cheers,
> g.
>
> > ---
> > V4: Fixed misspelling
> >
> > V3: Remove unneeded cast, and fixed indentation screw up
> >
> > V2: messed up changes
> >
> > arch/powerpc/kernel/prom.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 45 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> > index fd9359a..ff3e240 100644
> > --- a/arch/powerpc/kernel/prom.c
> > +++ b/arch/powerpc/kernel/prom.c
> > @@ -32,6 +32,7 @@
> > #include <linux/debugfs.h>
> > #include <linux/irq.h>
> > #include <linux/lmb.h>
> > +#include <linux/bootmem.h>
> >
> > #include <asm/prom.h>
> > #include <asm/rtas.h>
> > @@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
> > }
> > __initcall(export_flat_device_tree);
> > #endif
> > +
> > +#ifdef CONFIG_KEXEC
> > +static phys_addr_t flat_dt_start;
> > +static phys_addr_t flat_dt_end;
> > +
> > +static struct property flat_dt_start_prop = {
> > + .name = "linux,devicetree-start",
> > + .length = sizeof(phys_addr_t),
> > + .value = &flat_dt_start,
> > +};
> > +
> > +static struct property flat_dt_end_prop = {
> > + .name = "linux,devicetree-end",
> > + .length = sizeof(phys_addr_t),
> > + .value = &flat_dt_end,
> > +};
> > +
> > +static int __init export_flat_device_tree_phys_addr(void)
> > +{
> > + struct property *prop;
> > + struct device_node *node;
> > +
> > + node = of_find_node_by_path("/chosen");
> > + if (!node)
> > + return -ENOENT;
> > +
> > + prop = of_find_property(node, "linux,devicetree-start", NULL);
> > + if (prop)
> > + prom_remove_property(node, prop);
> > +
> > + prop = of_find_property(node, "linux,devicetree-end", NULL);
> > + if (prop)
> > + prom_remove_property(node, prop);
> > +
> > + flat_dt_start = virt_to_phys(initial_boot_params);
> > + flat_dt_end = virt_to_phys(initial_boot_params)
> > + + initial_boot_params->totalsize;
> > + prom_add_property(node, &flat_dt_start_prop);
> > + prom_add_property(node, &flat_dt_end_prop);
> > +
> > + return 0;
> > +}
> > +__initcall(export_flat_device_tree_phys_addr);
> > +#endif
> > --
> > 1.6.6.1
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code
From: Benjamin Herrenschmidt @ 2010-07-19 0:00 UTC (permalink / raw)
To: Christian Dietrich
Cc: Randy Dunlap, linuxppc-dev, Alexander Kurz, Paul Mackerras,
John Linn, David Brown, Ladislav Michl, Solomon Peachy, vamos-dev,
Mike Frysinger, Florian Fainelli, Artem Bityutskiy, Nicolas Pitre,
Jiri Kosina, linux-kernel, Milton Miller, netdev, Joe Perches,
linux-mtd, David Woodhouse, David S. Miller
In-Reply-To: <ca1bb25d203618c3548748f5efb6f125a96c89e0.1279282865.git.qy03fugy@stud.informatik.uni-erlangen.de>
On Fri, 2010-07-16 at 14:29 +0200, Christian Dietrich wrote:
> The config options for REDWOOD_[456] were commented out in the powerpc
> Kconfig. The ifdefs referencing this options therefore are dead and all
> references to this can be removed (Also dependencies in other KConfig
> files).
>
> Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/40x/Kconfig | 16 -------------
> drivers/mtd/maps/Kconfig | 2 +-
> drivers/mtd/maps/redwood.c | 43 ------------------------------------
> drivers/net/Kconfig | 2 +-
> drivers/net/smc91x.h | 37 -------------------------------
> 5 files changed, 2 insertions(+), 98 deletions(-)
>
> diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
> index ec64264..b721764 100644
> --- a/arch/powerpc/platforms/40x/Kconfig
> +++ b/arch/powerpc/platforms/40x/Kconfig
> @@ -71,22 +71,6 @@ config MAKALU
> help
> This option enables support for the AMCC PPC405EX board.
>
> -#config REDWOOD_5
> -# bool "Redwood-5"
> -# depends on 40x
> -# default n
> -# select STB03xxx
> -# help
> -# This option enables support for the IBM STB04 evaluation board.
> -
> -#config REDWOOD_6
> -# bool "Redwood-6"
> -# depends on 40x
> -# default n
> -# select STB03xxx
> -# help
> -# This option enables support for the IBM STBx25xx evaluation board.
> -
> #config SYCAMORE
> # bool "Sycamore"
> # depends on 40x
> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> index f22bc9f..6629d09 100644
> --- a/drivers/mtd/maps/Kconfig
> +++ b/drivers/mtd/maps/Kconfig
> @@ -321,7 +321,7 @@ config MTD_CFI_FLAGADM
>
> config MTD_REDWOOD
> tristate "CFI Flash devices mapped on IBM Redwood"
> - depends on MTD_CFI && ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
> + depends on MTD_CFI
> help
> This enables access routines for the flash chips on the IBM
> Redwood board. If you have one of these boards and would like to
> diff --git a/drivers/mtd/maps/redwood.c b/drivers/mtd/maps/redwood.c
> index 933c0b6..d2c9db0 100644
> --- a/drivers/mtd/maps/redwood.c
> +++ b/drivers/mtd/maps/redwood.c
> @@ -22,8 +22,6 @@
>
> #include <asm/io.h>
>
> -#if !defined (CONFIG_REDWOOD_6)
> -
> #define WINDOW_ADDR 0xffc00000
> #define WINDOW_SIZE 0x00400000
>
> @@ -69,47 +67,6 @@ static struct mtd_partition redwood_flash_partitions[] = {
> }
> };
>
> -#else /* CONFIG_REDWOOD_6 */
> -/* FIXME: the window is bigger - armin */
> -#define WINDOW_ADDR 0xff800000
> -#define WINDOW_SIZE 0x00800000
> -
> -#define RW_PART0_OF 0
> -#define RW_PART0_SZ 0x400000 /* 4 MiB data */
> -#define RW_PART1_OF RW_PART0_OF + RW_PART0_SZ
> -#define RW_PART1_SZ 0x10000 /* 64K VPD */
> -#define RW_PART2_OF RW_PART1_OF + RW_PART1_SZ
> -#define RW_PART2_SZ 0x400000 - (0x10000 + 0x20000)
> -#define RW_PART3_OF RW_PART2_OF + RW_PART2_SZ
> -#define RW_PART3_SZ 0x20000
> -
> -static struct mtd_partition redwood_flash_partitions[] = {
> - {
> - .name = "Redwood filesystem",
> - .offset = RW_PART0_OF,
> - .size = RW_PART0_SZ
> - },
> - {
> - .name = "Redwood OpenBIOS Vital Product Data",
> - .offset = RW_PART1_OF,
> - .size = RW_PART1_SZ,
> - .mask_flags = MTD_WRITEABLE /* force read-only */
> - },
> - {
> - .name = "Redwood kernel",
> - .offset = RW_PART2_OF,
> - .size = RW_PART2_SZ
> - },
> - {
> - .name = "Redwood OpenBIOS",
> - .offset = RW_PART3_OF,
> - .size = RW_PART3_SZ,
> - .mask_flags = MTD_WRITEABLE /* force read-only */
> - }
> -};
> -
> -#endif /* CONFIG_REDWOOD_6 */
> -
> struct map_info redwood_flash_map = {
> .name = "IBM Redwood",
> .size = WINDOW_SIZE,
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index ce2fcdd..313d306 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -913,7 +913,7 @@ config SMC91X
> tristate "SMC 91C9x/91C1xxx support"
> select CRC32
> select MII
> - depends on ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || \
> + depends on ARM || M32R || SUPERH || \
> MIPS || BLACKFIN || MN10300 || COLDFIRE
> help
> This is a driver for SMC's 91x series of Ethernet chipsets,
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 8d2772c..ee74791 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -83,43 +83,6 @@ static inline void SMC_outw(u16 val, void __iomem *ioaddr, int reg)
> }
> }
>
> -#elif defined(CONFIG_REDWOOD_5) || defined(CONFIG_REDWOOD_6)
> -
> -/* We can only do 16-bit reads and writes in the static memory space. */
> -#define SMC_CAN_USE_8BIT 0
> -#define SMC_CAN_USE_16BIT 1
> -#define SMC_CAN_USE_32BIT 0
> -#define SMC_NOWAIT 1
> -
> -#define SMC_IO_SHIFT 0
> -
> -#define SMC_inw(a, r) in_be16((volatile u16 *)((a) + (r)))
> -#define SMC_outw(v, a, r) out_be16((volatile u16 *)((a) + (r)), v)
> -#define SMC_insw(a, r, p, l) \
> - do { \
> - unsigned long __port = (a) + (r); \
> - u16 *__p = (u16 *)(p); \
> - int __l = (l); \
> - insw(__port, __p, __l); \
> - while (__l > 0) { \
> - *__p = swab16(*__p); \
> - __p++; \
> - __l--; \
> - } \
> - } while (0)
> -#define SMC_outsw(a, r, p, l) \
> - do { \
> - unsigned long __port = (a) + (r); \
> - u16 *__p = (u16 *)(p); \
> - int __l = (l); \
> - while (__l > 0) { \
> - /* Believe it or not, the swab isn't needed. */ \
> - outw( /* swab16 */ (*__p++), __port); \
> - __l--; \
> - } \
> - } while (0)
> -#define SMC_IRQ_FLAGS (0)
> -
> #elif defined(CONFIG_SA1100_PLEB)
> /* We can only do 16-bit reads and writes in the static memory space. */
> #define SMC_CAN_USE_8BIT 1
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Benjamin Herrenschmidt @ 2010-07-19 0:09 UTC (permalink / raw)
To: Grant Likely; +Cc: Matthew McClintock, Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <AANLkTikIGXBNU7NQEL7riZYB-BJU3jhxauzGo6XhUF3t@mail.gmail.com>
On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
> What is your starting point? Where does the device tree (and
> memreserve list) come from
> that you're passing to kexec? My first impression is that if you have
> to scrub the memreserve list, then the source being used to
> obtain the memreserves is either faulty or unsuitable to the task.
The kernel should ultimately pass the thing to userspace I reckon, with
an appropriate hook for platform code to insert/recover reserved
regions.
Ben.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (powerpc related)
From: Benjamin Herrenschmidt @ 2010-07-19 0:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martyn Welch, linuxppc-dev, linux-next, Paul Mackerras,
linux-kernel
In-Reply-To: <20100716171920.51ce1b88.sfr@canb.auug.org.au>
On Fri, 2010-07-16 at 17:19 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allmodconfig) failed like this:
>
> ERROR: "of_i8042_kbd_irq" [drivers/input/serio/i8042.ko] undefined!
> ERROR: "of_i8042_aux_irq" [drivers/input/serio/i8042.ko] undefined!
>
> Presumably missing EXPORT_SYMBOLs ..
Thanks. I'll fix that up.
Cheers,
Ben.
^ permalink raw reply
* Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings while Building a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
From: Benjamin Herrenschmidt @ 2010-07-19 1:11 UTC (permalink / raw)
To: subrata
Cc: sachinp, Alexander Graf, linux-kernel, Kamalesh Babulal,
Linuxppc-dev, Paul Mackerras, Paul Mackerras, divya.vikas
In-Reply-To: <1279193743.10707.5.camel@subratamodak.linux.ibm.com>
On Thu, 2010-07-15 at 17:05 +0530, Subrata Modak wrote:
> commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem for
> 2.6.34-rc6. However some other bad relocation warnings generated against
> 2.6.35-rc5 on Power7/ppc64 below:
>
> MODPOST 2004 modules^M
> WARNING: 2 bad relocations^M
> c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
> c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
I think this is KVM + CONFIG_RELOCATABLE. Caused by:
.global kvmppc_trampoline_lowmem
kvmppc_trampoline_lowmem:
.long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
.global kvmppc_trampoline_enter
kvmppc_trampoline_enter:
.long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
Alex, can you turn these into 64-bit on ppc64 so the relocator
can grok them ?
Cheers,
Ben.
> Config file attached.
>
> Regards--
> Subrata
>
> On Fri, 2010-05-07 at 15:40 +1000, Paul Mackerras wrote:
> > On Wed, May 05, 2010 at 05:20:51PM +0530, Subrata Modak wrote:
> >
> > > I built 2.6.34-rc6 with the attached Fedora Config file
> > > (config-2.6.33.1-19.fc13.ppc64) on my P5 Fedora Box and got the
> > > following warning. Is the following expected ?
> > >
> > > CALL arch/powerpc/relocs_check.pl
> > > Building modules, stage 2.
> > > WARNING: 4 bad relocations
> > > c00000000007216e R_PPC64_ADDR16_HIGHEST __ksymtab+0x00000000009dcec8
> > > c000000000072172 R_PPC64_ADDR16_HIGHER __ksymtab+0x00000000009dcec8
> > > c00000000007217a R_PPC64_ADDR16_HI __ksymtab+0x00000000009dcec8
> > > c00000000007217e R_PPC64_ADDR16_LO __ksymtab+0x00000000009dcec8
> >
> > No, it's not expected. It's in iSeries code, so you could avoid it
> > just by disabling CONFIG_ISERIES (I don't think any distro still
> > supports legacy iSeries). I'll post a patch to fix the problem
> > properly.
> >
> > Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Re: hi, i have two flashs, but my kernel can only find one , how cani write the dts?
From: hacklu @ 2010-07-19 3:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimXGTg41XHChzcnn75Px_pitC8sPKOY-OlPNIe1@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2122 bytes --]
thanks very much! it works well now~~
but i found in my system,if i add the 0x prefix it will cause a syntax error
2010-07-19
hacklu
发件人： Grant Likely
发送时间： 2010-07-17 05:46:59
收件人： hacklu
抄送： linuxppc-dev
主题： Re: hi, i have two flashs, but my kernel can only find one , how cani write the dts?
On Fri, Jul 16, 2010 at 2:34 AM, hacklu <embedway.test@gmail.com> wrote:
> this is my dts file:
> flash@0,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "cfi-flash";
> probe-type = "CFI";
> reg = <0 0 1000000>;
> bank-width = <2>;
> device-width = <1>;
> hrcw@0 {
> label = "hrcw";
> reg = <0 40000>;
> };
> jffs@40000 {
> label = "jffs";
> reg = <40000 200000>;
> };
> jffs2@240000 {
> label = "uimage";
> reg = <240000 d80000>;
> };
> };
> flash@1,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "cfi-flash";
> probe-type = "CFI";
> reg = <1000000 0 1000000>;
This looks wrong. If you're second flash is on chip select 1 as the
node name suggests, then this should be (first cell is CS#, second is
offset, and third is size. Alos you're missing the 0x prefix):
reg = <1 0 0x1000000>;
If your second flash is on chip select 0 with the first flash, but
offset by 0x1000000, then reg should be:
reg = <0 0x1000000 0x1000000>;
and the name should be:
flash@0,1000000 { ... };
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[-- Attachment #1.2: Type: text/html, Size: 9255 bytes --]
[-- Attachment #2: 14.gif --]
[-- Type: image/gif, Size: 1662 bytes --]
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-19 4:24 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Kumar Gala, Mitch Bradley, linuxppc-dev, Timur Tabi, David Gibson
In-Reply-To: <1E87551E-BD4C-4B0B-A603-908C7D9C1D5F@kernel.crashing.org>
On Jul 17, 2010, at 11:41 AM, Segher Boessenkool wrote:
>>>>> Yes. Where would we get a list of memreserve sections?
>>>>=20
>>>> I would say the list of reserves that are not under the control of
>>>> Linux should be explicitly described in the device tree proper. =
For
>>>> instance, if you have a region that firmware depends on, then have =
a
>>>> node for describing the firmware and a property stating the memory
>>>> regions that it depends on. The memreserve regions can be =
generated
>>>> from that.
>>>=20
>>> Ok, so we could traverse the tree node-by-bode for a
>>> persistent-memreserve property and add them to the /memreserve/ list =
in
>>> the kexec user space tools?
>>=20
>> I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
>> David Gibson, and other device tree experts on whether or not that
>> exact property naming is a good one.
>=20
> Let's take a step back: what exactly _are_ "memreserve sections", what
> are they used for, who (kernel, firmware, bootloader, etc.) holds what
> responsibility wrt them?
>=20
On the platform I'm working on (mpc85xx) they can be the following:
1) Boot page (aka cpu-release-addr) - always present on MP
2) Flat Device Tree - always present
3) Initrd - optional
When kexec'ing a kernel, we will provide new memory regions for the flat =
device tree and the initrd (if present). However, all others will not be =
replaced by kexec and should either be tossed or preserved. The question =
is how to decide what to do... save them all by default? Save none of =
them? If we save them all at a minimum we need to remove/replace the =
device tree and initrd regions as well. So we need a way to identify =
which regions correspond to these.
Grant and I talked and though a property that lives in the device tree =
describing a persistant-memreseve might work. And Mitch talked about an =
available memory property to go along with the current one which could =
be used to determine which ranges were invalid and need a memreserve =
for...
-Matthew
>=20
> Segher
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-19 4:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <1279496491.10390.1725.camel@pasglop>
On Jul 18, 2010, at 6:41 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
>> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock =
<msm@freescale.com> wrote:
>>> To build a proper flat device tree for kexec we need to know which
>>> memreserve region was used for the device tree for the currently
>>> running kernel, so we can remove it and replace it with the new
>>> memreserve for the kexec'ed kernel
>>>=20
>>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>>=20
>> Hi Matthew.
>>=20
>> I don't understand. Why does userspace need to know about the old
>> memreserve sections? Doesn't kexec tear down all of the old
>> allocations anyway? How are they relevant for constructing the dtb
>> for the kexec kernel? I'll need a lot more details before I consider
>> merging this.
>>=20
>> Also, please cc: me and Ben Herrenschmidt on powerpc related device
>> tree changes.
>=20
> I admit to be the victim of a similar misunderstanding...
>=20
> Care to explain in more details ? (with examples)
>=20
Upon first examining the details of getting kexec working on our =
platform I noticed our device tree passed from u-boot contained an =
additional memreserve section for the boot page. Subsequently, I've been =
trying to preserve the ones passed in for the kexec'ed kernel thinking =
anyone could add anything they wanted for their own particular needs and =
would quite possibly need those regions preserved across reboots.
Recently, I've discovered the boot page address is given in the device =
tree as a property. So, for our platform (mpc85xx) in particular, I'm =
back to not needing the read the old memreserve sections... I can =
completely reconstruct the appropriate memreserve regions for kexec'ing =
from the information passed in the device tree.
That isn't to say there might not be more memreserve regions that are =
not there for some valid reason. I'm not sure if we need to attempt to =
address another scenario where there are other memreserve regions. So =
this would be a good time to address this issue if anyone believes it is =
a worthwhile pursuit to have a mechanism to have memreserve regions =
persistent across kexec'ing - or any other reboot.
-Matthew
> Cheers,
> Ben.
>=20
>> Cheers,
>> g.
>>=20
>>> ---
>>> V4: Fixed misspelling
>>>=20
>>> V3: Remove unneeded cast, and fixed indentation screw up
>>>=20
>>> V2: messed up changes
>>>=20
>>> arch/powerpc/kernel/prom.c | 45 =
++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 45 insertions(+), 0 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>>> index fd9359a..ff3e240 100644
>>> --- a/arch/powerpc/kernel/prom.c
>>> +++ b/arch/powerpc/kernel/prom.c
>>> @@ -32,6 +32,7 @@
>>> #include <linux/debugfs.h>
>>> #include <linux/irq.h>
>>> #include <linux/lmb.h>
>>> +#include <linux/bootmem.h>
>>>=20
>>> #include <asm/prom.h>
>>> #include <asm/rtas.h>
>>> @@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
>>> }
>>> __initcall(export_flat_device_tree);
>>> #endif
>>> +
>>> +#ifdef CONFIG_KEXEC
>>> +static phys_addr_t flat_dt_start;
>>> +static phys_addr_t flat_dt_end;
>>> +
>>> +static struct property flat_dt_start_prop =3D {
>>> + .name =3D "linux,devicetree-start",
>>> + .length =3D sizeof(phys_addr_t),
>>> + .value =3D &flat_dt_start,
>>> +};
>>> +
>>> +static struct property flat_dt_end_prop =3D {
>>> + .name =3D "linux,devicetree-end",
>>> + .length =3D sizeof(phys_addr_t),
>>> + .value =3D &flat_dt_end,
>>> +};
>>> +
>>> +static int __init export_flat_device_tree_phys_addr(void)
>>> +{
>>> + struct property *prop;
>>> + struct device_node *node;
>>> +
>>> + node =3D of_find_node_by_path("/chosen");
>>> + if (!node)
>>> + return -ENOENT;
>>> +
>>> + prop =3D of_find_property(node, "linux,devicetree-start", =
NULL);
>>> + if (prop)
>>> + prom_remove_property(node, prop);
>>> +
>>> + prop =3D of_find_property(node, "linux,devicetree-end", =
NULL);
>>> + if (prop)
>>> + prom_remove_property(node, prop);
>>> +
>>> + flat_dt_start =3D virt_to_phys(initial_boot_params);
>>> + flat_dt_end =3D virt_to_phys(initial_boot_params)
>>> + + initial_boot_params->totalsize;
>>> + prom_add_property(node, &flat_dt_start_prop);
>>> + prom_add_property(node, &flat_dt_end_prop);
>>> +
>>> + return 0;
>>> +}
>>> +__initcall(export_flat_device_tree_phys_addr);
>>> +#endif
>>> --
>>> 1.6.6.1
>>>=20
>>>=20
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>=20
>>=20
>>=20
>>=20
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Grant Likely @ 2010-07-19 4:32 UTC (permalink / raw)
To: Matthew McClintock; +Cc: Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <8388D248-51F3-4F36-BBE0-CDE9E278E65E@freescale.com>
On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock <msm@freescale.com> wr=
ote:
> On Jul 18, 2010, at 6:41 PM, Benjamin Herrenschmidt wrote:
>> On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
>>> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock <msm@freescale.com>=
wrote:
>>>> To build a proper flat device tree for kexec we need to know which
>>>> memreserve region was used for the device tree for the currently
>>>> running kernel, so we can remove it and replace it with the new
>>>> memreserve for the kexec'ed kernel
>>>>
>>>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>>>
>>> Hi Matthew.
>>>
>>> I don't understand. =A0Why does userspace need to know about the old
>>> memreserve sections? =A0Doesn't kexec tear down all of the old
>>> allocations anyway? =A0How are they relevant for constructing the dtb
>>> for the kexec kernel? =A0I'll need a lot more details before I consider
>>> merging this.
>>>
>>> Also, please cc: me and Ben Herrenschmidt on powerpc related device
>>> tree changes.
>>
>> I admit to be the victim of a similar misunderstanding...
>>
>> Care to explain in more details ? (with examples)
>>
>
> Upon first examining the details of getting kexec working on our platform=
I noticed our device tree passed from u-boot contained an additional memre=
serve section for the boot page. Subsequently, I've been trying to preserve=
the ones passed in for the kexec'ed kernel thinking anyone could add anyth=
ing they wanted for their own particular needs and would quite possibly nee=
d those regions preserved across reboots.
>
> Recently, I've discovered the boot page address is given in the device tr=
ee as a property. So, for our platform (mpc85xx) in particular, I'm back to=
not needing the read the old memreserve sections... I can completely recon=
struct the appropriate memreserve regions for kexec'ing from the informatio=
n passed in the device tree.
>
> That isn't to say there might not be more memreserve regions that are not=
there for some valid reason. I'm not sure if we need to attempt to address=
another scenario where there are other memreserve regions. So this would b=
e a good time to address this issue if anyone believes it is a worthwhile p=
ursuit to have a mechanism to have memreserve regions persistent across kex=
ec'ing - or any other reboot.
No, we haven't needed anything to date, so no sense trying to design a
solution for a theoretical need. Leave it be for now.
g.
^ permalink raw reply
* Re: Re: hi, i have two flashs, but my kernel can only find one , how cani write the dts?
From: Grant Likely @ 2010-07-19 4:33 UTC (permalink / raw)
To: hacklu; +Cc: linuxppc-dev
In-Reply-To: <201007191156288194097@gmail.com>
On Sun, Jul 18, 2010 at 9:56 PM, hacklu <embedway.test@gmail.com> wrote:
>
> thanks very much! it works well now~~
> but i found in my system,if i add the 0x prefix it will cause=A0a syntax =
error
Ah, your dts file is in the old version 0 format. You must be on an
older kernel, or at least haven't updated your dts file to the new
format after upgrading.
g.
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-19 4:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <1279498153.10390.1764.camel@pasglop>
On Jul 18, 2010, at 7:09 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
>> What is your starting point? Where does the device tree (and
>> memreserve list) come from
>> that you're passing to kexec? My first impression is that if you =
have
>> to scrub the memreserve list, then the source being used to
>> obtain the memreserves is either faulty or unsuitable to the task.
>=20
> The kernel should ultimately pass the thing to userspace I reckon, =
with
> an appropriate hook for platform code to insert/recover reserved
> regions.
>=20
Or possibly in the device tree itself? As I mentioned in my previous =
email - my particular case can already be handled by the information =
passed in the device tree (as I recently discovered), is this something =
we would want to make generic for the device tree or add platform code =
to expose these memreserve regions?
-Matthew
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-19 5:20 UTC (permalink / raw)
To: Jamie Lokier
Cc: Daniel Walker, linux-kbuild, Tony Lindgren, Nicolas Pitre,
linux-kernel, linuxppc-dev, linux-arm-kernel,
Uwe Kleine-König, Linus Torvalds, Russell King
In-Reply-To: <20100716234918.GA31060@shareable.org>
On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier <jamie@shareable.org> wrote:
> Daniel Walker wrote:
>> > But all the rest is arbitrary and could be part of common shared
>> > profiles or the like in defconfig format.
>>
>> I'm sure most people will want to have a config isolated to their
>> specific device. That to me seems reasonable because everyone wants the
>> smallest possible kernel they can get for their given device.
Just to be clear (specifically for me as a maintainer) the purpose of
defconfigs is not to provide the best optimized kernel configuration
for each given board. defconfigs are useful as a reasonable working
starting point, and to provide build coverage testing.
> Indeed, but people who want the smallest possible kernel for their
> specific device _in a particular use context_ tend to want:
>
> =A0- To disable support for parts of the device they aren't using.
> =A0 =A0For example, an SoC with integrated ethernet that isn't actually
> =A0 =A0wired up on their board, or where they're using an external ethern=
et
> =A0 =A0chip instead for some reason.
>
> =A0- To choose what's modular and what isn't, even for integrated
> =A0 =A0parts. =A0For example to control the bootup sequence, they might
> =A0 =A0want to delay integrated USB and IDE initialisation, which is done=
by
> =A0 =A0making those modular and loading them after bringing up a splash
> =A0 =A0screen earlier in the boot scripts.
>
> So there is still a need to be able to override the drivers and
> settings, but it's still incredibly useful to have defaults which
> describe the SoC or board accurately.
Yes. The defconfig is only a starting point. Maintaining the actual
config for the shipped kernel is the job of the distribution vendor
and I have zero interest in maintaining those configurations in the
kernel tree.
g.
^ permalink raw reply
* Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings while Building a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
From: Alexander Graf @ 2010-07-19 7:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sachinp, linux-kernel, Kamalesh Babulal, Linuxppc-dev,
Paul Mackerras, Paul Mackerras, subrata, divya.vikas
In-Reply-To: <1279501889.10390.1834.camel@pasglop>
On 19.07.2010, at 03:11, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-15 at 17:05 +0530, Subrata Modak wrote:
>> commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem =
for
>> 2.6.34-rc6. However some other bad relocation warnings generated =
against
>> 2.6.35-rc5 on Power7/ppc64 below:
>>=20
>> MODPOST 2004 modules^M
>> WARNING: 2 bad relocations^M
>> c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
>> c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
>=20
> I think this is KVM + CONFIG_RELOCATABLE. Caused by:
>=20
> .global kvmppc_trampoline_lowmem
> kvmppc_trampoline_lowmem:
> .long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
>=20
> .global kvmppc_trampoline_enter
> kvmppc_trampoline_enter:
> .long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
>=20
> Alex, can you turn these into 64-bit on ppc64 so the relocator
> can grok them ?
If I turn them into 64-bit, will the values be > RMA? In that case =
things would break anyways. How does relocation work on PPC? Are the =
first few megs copied over to low memory? Would I have to mask anything =
in the above code to make sure I use the real values?
Alex
^ permalink raw reply
* Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings while Building a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
From: Subrata Modak @ 2010-07-19 8:56 UTC (permalink / raw)
To: Michael Neuling
Cc: sachinp, linux-kernel, Kamalesh Babulal, Linuxppc-dev,
Paul Mackerras, Paul Mackerras, divya.vikas
In-Reply-To: <4635.1279245899@neuling.org>
On Fri, 2010-07-16 at 12:04 +1000, Michael Neuling wrote:
> > commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem for
> > 2.6.34-rc6. However some other bad relocation warnings generated against
> > 2.6.35-rc5 on Power7/ppc64 below:
> >
> > MODPOST 2004 modules^M
> > WARNING: 2 bad relocations^M
> > c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
> > c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
>
> I can't replicate this with your config with gcc 4.4.4 and binutils
> 2.20. What are you using?
Well, i also have the following GCC (from Fedora 13 Rawhide)
# gcc --version
gcc (GCC) 4.4.4 20100611 (Red Hat 4.4.4-8)
Copyright (C) 2010 Free Software Foundation, Inc.
and binutils-2.20.51.0.2-22.fc13.ppc,
Regards--
Subrata
>
> Mikey
>
> >
> > Config file attached.
> >
> > Regards--
> > Subrata
> >
> > On Fri, 2010-05-07 at 15:40 +1000, Paul Mackerras wrote:
> > > On Wed, May 05, 2010 at 05:20:51PM +0530, Subrata Modak wrote:
> > >
> > > > I built 2.6.34-rc6 with the attached Fedora Config file
> > > > (config-2.6.33.1-19.fc13.ppc64) on my P5 Fedora Box and got the
> > > > following warning. Is the following expected ?
> > > >
> > > > CALL arch/powerpc/relocs_check.pl
> > > > Building modules, stage 2.
> > > > WARNING: 4 bad relocations
> > > > c00000000007216e R_PPC64_ADDR16_HIGHEST __ksymtab+0x00000000009dcec8
> > > > c000000000072172 R_PPC64_ADDR16_HIGHER __ksymtab+0x00000000009dcec8
> > > > c00000000007217a R_PPC64_ADDR16_HI __ksymtab+0x00000000009dcec8
> > > > c00000000007217e R_PPC64_ADDR16_LO __ksymtab+0x00000000009dcec8
> > >
> > > No, it's not expected. It's in iSeries code, so you could avoid it
> > > just by disabling CONFIG_ISERIES (I don't think any distro still
> > > supports legacy iSeries). I'll post a patch to fix the problem
> > > properly.
> > >
> > > Paul.
^ permalink raw reply
* Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings whileBuilding a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
From: Milton Miller @ 2010-07-19 11:23 UTC (permalink / raw)
To: Alexander Graf; +Cc: Subrata Modak, linuxppc-dev, linux-kernel
In-Reply-To: <8C4BCF61-7F5D-4C80-A311-93CF8521FBF5@suse.de>
On Mon Jul 19 2010 at about 03:36:51 EST, Alexander Graf wrote:
> On 19.07.2010, at 03:11, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2010-07-15 at 17:05 +0530, Subrata Modak wrote:
> > > commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem for
> > > 2.6.34-rc6. However some other bad relocation warnings generated against
> > > 2.6.35-rc5 on Power7/ppc64 below:
> > >
> > > MODPOST 2004 modules^M
> > > WARNING: 2 bad relocations^M
> > > c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
> > > c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
> >
> > I think this is KVM + CONFIG_RELOCATABLE. Caused by:
> >
> > .global kvmppc_trampoline_lowmem
> > kvmppc_trampoline_lowmem:
> > .long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
> >
> > .global kvmppc_trampoline_enter
> > kvmppc_trampoline_enter:
> > .long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
> >
> > Alex, can you turn these into 64-bit on ppc64 so the relocator
> > can grok them ?
>
> If I turn them into 64-bit, will the values be > RMA? In that case
> things would break anyways. How does relocation work on PPC? Are the
> first few megs copied over to low memory? Would I have to mask anything
> in the above code to make sure I use the real values?
>
> Alex
>
You can still do the subtraction, but you have to allocate 64 bits for
storage. Relocatable ppc64 kernels work by adjusting PPC64_RELOC_RELATIVE
entries during early boot (reloc in reloc_64.S called from head_64.S).
The code purposely only supports 64 bit relative addressing.
milton
^ permalink raw reply
* Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings whileBuilding a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
From: Milton Miller @ 2010-07-19 11:35 UTC (permalink / raw)
To: Alexander Graf; +Cc: Subrata Modak, linuxppc-dev, linux-kernel
In-Reply-To: <reloc-2010-07-19@mdm.bga.com>
I wrote:
> On Mon Jul 19 2010 at about 03:36:51 EST, Alexander Graf wrote:
> > On 19.07.2010, at 03:11, Benjamin Herrenschmidt wrote:
> >
> > > On Thu, 2010-07-15 at 17:05 +0530, Subrata Modak wrote:
> > > > commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem for
> > > > 2.6.34-rc6. However some other bad relocation warnings generated against
> > > > 2.6.35-rc5 on Power7/ppc64 below:
> > > >
> > > > MODPOST 2004 modules^M
> > > > WARNING: 2 bad relocations^M
> > > > c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
> > > > c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
> > >
> > > I think this is KVM + CONFIG_RELOCATABLE. Caused by:
> > >
> > > .global kvmppc_trampoline_lowmem
> > > kvmppc_trampoline_lowmem:
> > > .long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
> > >
> > > .global kvmppc_trampoline_enter
> > > kvmppc_trampoline_enter:
> > > .long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
> > >
> > > Alex, can you turn these into 64-bit on ppc64 so the relocator
> > > can grok them ?
> >
> > If I turn them into 64-bit, will the values be > RMA? In that case
> > things would break anyways. How does relocation work on PPC? Are the
> > first few megs copied over to low memory? Would I have to mask anything
> > in the above code to make sure I use the real values?
> >
> > Alex
> >
>
> You can still do the subtraction, but you have to allocate 64 bits for
> storage. Relocatable ppc64 kernels work by adjusting PPC64_RELOC_RELATIVE
> entries during early boot (reloc in reloc_64.S called from head_64.S).
>
> The code purposely only supports 64 bit relative addressing.
Oh yea, and for book-3s, the code copies from 0x100 to __end_interrupts
in arch/powerpc/kernel/exceptions-64s.h down to the real 0, but the rest
of the kernel is at some disjointed address. The interrupt will go to
the copy at the real zero. Any references to code outside that region
must be done via a full indrect branch (not a relative one), simiar to
the secondary startup (via following the function pointer in a descriptor
set in very low memory), or syscall entry and exception vectors via paca.
Book-3e (64 and 32 bit) are different. I forget how classic 32 bit works,
it may still have a < 32MB limitation.
milton
^ permalink raw reply
* Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings whileBuilding a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled
From: Alexander Graf @ 2010-07-19 12:00 UTC (permalink / raw)
To: Milton Miller; +Cc: Subrata Modak, linuxppc-dev, linux-kernel
In-Reply-To: <reloc-2010-07-19-2@mdm.bga.com>
Milton Miller wrote:
> I wrote:
>
>> On Mon Jul 19 2010 at about 03:36:51 EST, Alexander Graf wrote:
>>
>>> On 19.07.2010, at 03:11, Benjamin Herrenschmidt wrote:
>>>
>>>
>>>> On Thu, 2010-07-15 at 17:05 +0530, Subrata Modak wrote:
>>>>
>>>>> commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem for
>>>>> 2.6.34-rc6. However some other bad relocation warnings generated against
>>>>> 2.6.35-rc5 on Power7/ppc64 below:
>>>>>
>>>>> MODPOST 2004 modules^M
>>>>> WARNING: 2 bad relocations^M
>>>>> c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
>>>>> c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
>>>>>
>>>> I think this is KVM + CONFIG_RELOCATABLE. Caused by:
>>>>
>>>> .global kvmppc_trampoline_lowmem
>>>> kvmppc_trampoline_lowmem:
>>>> .long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
>>>>
>>>> .global kvmppc_trampoline_enter
>>>> kvmppc_trampoline_enter:
>>>> .long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
>>>>
>>>> Alex, can you turn these into 64-bit on ppc64 so the relocator
>>>> can grok them ?
>>>>
>>> If I turn them into 64-bit, will the values be > RMA? In that case
>>> things would break anyways. How does relocation work on PPC? Are the
>>> first few megs copied over to low memory? Would I have to mask anything
>>> in the above code to make sure I use the real values?
>>>
>>> Alex
>>>
>>>
>> You can still do the subtraction, but you have to allocate 64 bits for
>> storage. Relocatable ppc64 kernels work by adjusting PPC64_RELOC_RELATIVE
>> entries during early boot (reloc in reloc_64.S called from head_64.S).
>>
>> The code purposely only supports 64 bit relative addressing.
>>
>
> Oh yea, and for book-3s, the code copies from 0x100 to __end_interrupts
> in arch/powerpc/kernel/exceptions-64s.h down to the real 0, but the rest
> of the kernel is at some disjointed address. The interrupt will go to
> the copy at the real zero. Any references to code outside that region
> must be done via a full indrect branch (not a relative one), simiar to
> the secondary startup (via following the function pointer in a descriptor
> set in very low memory), or syscall entry and exception vectors via paca.
>
That would still break on normal PPC boxes, as any address accessed in
real mode has to be inside the RMA. And the #include for
kvm/book3s_rmhandlers.S happens after __end_interrupts. So I'd end up
with code that gets executed outside of the RMA after a relocation, right?
Alex
^ permalink raw reply
* [PATCH] KVM: PPC: Make long relocations be ulong
From: Alexander Graf @ 2010-07-19 14:54 UTC (permalink / raw)
To: kvm-ppc; +Cc: Linuxppc-dev, subrata, kvm
On Book3S KVM we directly expose some asm pointers to C code as
variables. These need to be relocated and thus break on relocatable
kernels.
To make sure we can at least build, let's mark them as long instead
of u32 where 64bit relocations don't work.
This fixes the following build error:
WARNING: 2 bad relocations
> c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460
> c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598
Please keep in mind that actually using KVM on a relocated kernel
might still break. This only fixes the compile problem.
Reported-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
I'm not sure which tree this should go through. Avi and Ben, please
coordinate this.
---
arch/powerpc/include/asm/kvm_book3s.h | 4 ++--
arch/powerpc/kvm/book3s_rmhandlers.S | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index b5b1961..b3d763d 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -131,8 +131,8 @@ extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
extern void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr);
extern int kvmppc_emulate_paired_single(struct kvm_run *run, struct kvm_vcpu *vcpu);
-extern u32 kvmppc_trampoline_lowmem;
-extern u32 kvmppc_trampoline_enter;
+extern ulong kvmppc_trampoline_lowmem;
+extern ulong kvmppc_trampoline_enter;
extern void kvmppc_rmcall(ulong srr0, ulong srr1);
extern void kvmppc_load_up_fpu(void);
extern void kvmppc_load_up_altivec(void);
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
index 506d5c3..20eb908 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -242,10 +242,10 @@ define_load_up(vsx)
.global kvmppc_trampoline_lowmem
kvmppc_trampoline_lowmem:
- .long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
+ PPC_LONG kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
.global kvmppc_trampoline_enter
kvmppc_trampoline_enter:
- .long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
+ PPC_LONG kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
#include "book3s_segment.S"
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: Make long relocations be ulong
From: Avi Kivity @ 2010-07-19 15:30 UTC (permalink / raw)
To: Alexander Graf; +Cc: Linuxppc-dev, subrata, kvm, kvm-ppc
In-Reply-To: <1279551293-32473-1-git-send-email-agraf@suse.de>
On 07/19/2010 05:54 PM, Alexander Graf wrote:
> I'm not sure which tree this should go through. Avi and Ben, please
> coordinate this.
> ---
> arch/powerpc/include/asm/kvm_book3s.h | 4 ++--
> arch/powerpc/kvm/book3s_rmhandlers.S | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
>
The diffstat suggests kvm.git.
Is this broken in Linus' tree, or just kvm.git?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Make long relocations be ulong
From: Alexander Graf @ 2010-07-19 15:33 UTC (permalink / raw)
To: Avi Kivity; +Cc: Linuxppc-dev, subrata, kvm, kvm-ppc
In-Reply-To: <4C446FA0.8050403@redhat.com>
Avi Kivity wrote:
> On 07/19/2010 05:54 PM, Alexander Graf wrote:
>> I'm not sure which tree this should go through. Avi and Ben, please
>> coordinate this.
>> ---
>> arch/powerpc/include/asm/kvm_book3s.h | 4 ++--
>> arch/powerpc/kvm/book3s_rmhandlers.S | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>>
>
> The diffstat suggests kvm.git.
>
> Is this broken in Linus' tree, or just kvm.git?
I got the bug report through linuxppc-dev, so I assume it's broken in
Linus' tree. In fact, that code has been around for a while already, so
it should even be in 2.6.24.
Alex
^ permalink raw reply
* Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready
From: Scott Wood @ 2010-07-19 15:36 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTikyHvocHW6YzBPtxDrC9M5mih4ZpSoqo0mg6M1E@mail.gmail.com>
On Fri, 16 Jul 2010 17:30:01 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:
> >> > My RCCR=3D0x1, meaning the first 512B is for microcode. So the data =
and
> >> > the TxBD should really be starting at 0xfa202200? Then my muram data=
's
> >> > reg should be <0x200 ?>? What size shall I specify?
> >>
> >> After the muram data's reg is changed to <0x200 0x1a00>, the cpm_uart
> >> driver works properly and the kernel messages are printed on the
> >> serial port.
> >
> > The muram node is supposed to show the portions of DPRAM that are
> > usable by the OS. =A0If some portion has been taken up by microcode (or
> > anything else not under the OS's control) before the OS has started,
> > then it must be excluded from the muram node.
>=20
> It would be nicer that the initialization code could query the RCCR
> value and adjust the base address.
Is that the only thing that could possibly conflict with OS usage of
DPRAM? It seemed simpler to just specify the usable chunks.
Before the kernel supported allocating CPM2 SMC parameter RAM, that was
another thing that firmware allocated that had to be kept out of the
muram node.
> It took me quite a while to understand the design.
Sorry...
This constraint is described in the MURAM section of
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt, though.
-Scott
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: Scott Wood @ 2010-07-19 16:57 UTC (permalink / raw)
To: Grant Likely; +Cc: Matthew McClintock, Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <AANLkTimJwnmf1YTPIy7OqdjseiUspzlxwRcjPMQ6Vv6j@mail.gmail.com>
On Sun, 18 Jul 2010 22:32:38 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock <msm@freescale.com> wrote:
> > Upon first examining the details of getting kexec working on our platform I noticed our device tree passed from u-boot contained an additional memreserve section for the boot page. Subsequently, I've been trying to preserve the ones passed in for the kexec'ed kernel thinking anyone could add anything they wanted for their own particular needs and would quite possibly need those regions preserved across reboots.
> >
> > Recently, I've discovered the boot page address is given in the device tree as a property. So, for our platform (mpc85xx) in particular, I'm back to not needing the read the old memreserve sections... I can completely reconstruct the appropriate memreserve regions for kexec'ing from the information passed in the device tree.
> >
> > That isn't to say there might not be more memreserve regions that are not there for some valid reason. I'm not sure if we need to attempt to address another scenario where there are other memreserve regions. So this would be a good time to address this issue if anyone believes it is a worthwhile pursuit to have a mechanism to have memreserve regions persistent across kexec'ing - or any other reboot.
>
> No, we haven't needed anything to date, so no sense trying to design a
> solution for a theoretical need. Leave it be for now.
So why do we have memreserve at all?
If we honor it on the first boot, seems like we should keep that
information around on subsequent boots. I wouldn't want to be the one
to have to debug when that theoretical need becomes actual. :-(
Or am I misunderstanding what this is trying to do?
-Scott
^ permalink raw reply
* [RFC][PATCH] kconfig: implement select with values
From: Stephen Rothwell @ 2010-07-19 18:37 UTC (permalink / raw)
To: Michal Marek
Cc: Nir Tzachar, Francis Galiegue, Andi Kleen, Catalin Marinas,
Sam Ravnborg, linux-kbuild, ppc-dev, Li Zefan, LKML,
Steven Rostedt, Josh Triplett, Vadim Bendebury, Cheng Renquan,
Trevor Keith, Jiri Kosina, Andrew Morton, Linus
This is a fairly brute force approach to allowing a Kconfig "select"
to specify an excplicit value for the selected config sybmol.
The syntax of select is changed to:
"select" <symbol> [<expr>] ["if" expr]
The approach taken is to add a list of <value, dependency expression>
pairs to the symbol and check them whenever the reverse depends (from
a current-style select) are checked.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
Documentation/kbuild/kconfig-language.txt | 7 +-
scripts/kconfig/expr.h | 9 +
scripts/kconfig/lkc.h | 1 +
| 70 +++++-
scripts/kconfig/symbol.c | 88 +++++++-
scripts/kconfig/zconf.tab.c_shipped | 352 +++++++++++++++--------------
scripts/kconfig/zconf.y | 17 ++-
7 files changed, 356 insertions(+), 188 deletions(-)
This is a work in progress, though it is possible to set values. I have
not done a great deal of testing.
I would like comments on the approach (and the actual code as the kconfig
code is pretty dense :-)).
This is built on top of the kbuild tree that is in linux-next
(git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git#for-next)
merged with Linus' tree of a few days ago (commit
2f7989efd4398d92b8adffce2e07dd043a0895fe "Merge
master.kernel.org:/home/rmk/linux-2.6-arm").
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index b472e4e..b1fb180 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -95,14 +95,15 @@ applicable everywhere (see syntax).
bool "foo"
default y
-- reverse dependencies: "select" <symbol> ["if" <expr>]
+- reverse dependencies: "select" <symbol> [<expr>] ["if" <expr>]
While normal dependencies reduce the upper limit of a symbol (see
below), reverse dependencies can be used to force a lower limit of
another symbol. The value of the current menu symbol is used as the
minimal value <symbol> can be set to. If <symbol> is selected multiple
times, the limit is set to the largest selection.
- Reverse dependencies can only be used with boolean or tristate
- symbols.
+ Reverse dependencies without the optional <expr> can only be used with
+ boolean or tristate symbols. If the optional <expr> is supplied,
+ the <symbol> will be set to that value if possible.
Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 75a31e4..7217c6d 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -56,6 +56,13 @@ struct expr_value {
tristate tri;
};
+struct expr_select_value {
+ struct expr *expr;
+ tristate tri;
+ struct expr *value;
+ struct expr_select_value *next;
+};
+
struct symbol_value {
void *val;
tristate tri;
@@ -85,6 +92,7 @@ struct symbol {
struct property *prop;
struct expr_value dir_dep;
struct expr_value rev_dep;
+ struct expr_select_value *val_dep;
};
#define for_all_symbols(i, sym) for (i = 0; i < SYMBOL_HASHSIZE; i++) for (sym = symbol_hash[i]; sym; sym = sym->next) if (sym->type != S_OTHER)
@@ -146,6 +154,7 @@ struct property {
* P_PROMPT, P_DEFAULT, P_MENU, P_COMMENT */
struct file *file; /* what file was this property defined */
int lineno; /* what lineno was this property defined */
+ struct expr *value; /* the optional P_SELECT value */
};
#define for_all_properties(sym, st, tok) \
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index ce6549c..5176657 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -95,6 +95,7 @@ struct property *menu_add_prop(enum prop_type type, char *prompt, struct expr *e
struct property *menu_add_prompt(enum prop_type type, char *prompt, struct expr *dep);
void menu_add_expr(enum prop_type type, struct expr *expr, struct expr *dep);
void menu_add_symbol(enum prop_type type, struct symbol *sym, struct expr *dep);
+void menu_add_select(struct symbol *sym, struct expr *value, struct expr *dep);
void menu_add_option(int token, char *arg);
void menu_finalize(struct menu *parent);
void menu_set_type(int type);
--git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 1179989..f1211f3 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -161,6 +161,14 @@ void menu_add_symbol(enum prop_type type, struct symbol *sym, struct expr *dep)
menu_add_prop(type, NULL, expr_alloc_symbol(sym), dep);
}
+void menu_add_select(struct symbol *sym, struct expr *value, struct expr *dep)
+{
+ struct property *p;
+
+ p = menu_add_prop(P_SELECT, NULL, expr_alloc_symbol(sym), dep);
+ p->value = value;
+}
+
void menu_add_option(int token, char *arg)
{
struct property *prop;
@@ -207,13 +215,22 @@ static void sym_check_prop(struct symbol *sym)
prop_warn(prop,
"config symbol '%s' uses select, but is "
"not boolean or tristate", sym->name);
- else if (sym2->type != S_UNKNOWN &&
+ else if (prop->value == NULL &&
+ sym2->type != S_UNKNOWN &&
sym2->type != S_BOOLEAN &&
sym2->type != S_TRISTATE)
prop_warn(prop,
- "'%s' has wrong type. 'select' only "
- "accept arguments of boolean and "
- "tristate type", sym2->name);
+ "'%s' has wrong type. 'select' without a "
+ "value only accepts arguments of boolean "
+ "and tristate type", sym2->name);
+ else if (prop->value != NULL &&
+ (sym2->type == S_INT ||
+ sym2->type == S_HEX ||
+ sym2->type == S_STRING) &&
+ prop->value->type != E_SYMBOL)
+ prop_warn(prop,
+ "select value for config symbol '%s'"
+ " must be a single symbol", sym2->name);
break;
case P_RANGE:
if (sym->type != S_INT && sym->type != S_HEX)
@@ -229,6 +246,25 @@ static void sym_check_prop(struct symbol *sym)
}
}
+static void finalize_select(struct symbol *sym, struct property *prop,
+ struct expr *dep)
+{
+ struct symbol *es = prop_get_symbol(prop);
+ struct expr_select_value *esv;
+
+ if (prop->value) {
+ esv = malloc(sizeof *esv);
+ esv->expr = expr_alloc_and(expr_alloc_symbol(sym),
+ expr_copy(dep));
+ esv->value = prop->value;
+ esv->next = es->val_dep;
+ es->val_dep = esv;
+ } else {
+ es->rev_dep.expr = expr_alloc_or(es->rev_dep.expr,
+ expr_alloc_and(expr_alloc_symbol(sym), expr_copy(dep)));
+ }
+}
+
void menu_finalize(struct menu *parent)
{
struct menu *menu, *last_menu;
@@ -279,11 +315,8 @@ void menu_finalize(struct menu *parent)
if (menu->sym && menu->sym->type != S_TRISTATE)
dep = expr_trans_bool(dep);
prop->visible.expr = dep;
- if (prop->type == P_SELECT) {
- struct symbol *es = prop_get_symbol(prop);
- es->rev_dep.expr = expr_alloc_or(es->rev_dep.expr,
- expr_alloc_and(expr_alloc_symbol(menu->sym), expr_copy(dep)));
- }
+ if (prop->type == P_SELECT)
+ finalize_select(menu->sym, prop, dep);
}
}
for (menu = parent->list; menu; menu = menu->next)
@@ -389,9 +422,15 @@ void menu_finalize(struct menu *parent)
}
if (sym && !sym_is_optional(sym) && parent->prompt) {
+ struct expr_select_value *esv;
+
sym->rev_dep.expr = expr_alloc_or(sym->rev_dep.expr,
expr_alloc_and(parent->prompt->visible.expr,
expr_alloc_symbol(&symbol_mod)));
+ for (esv = sym->val_dep; esv; esv = esv->next)
+ esv->expr = expr_alloc_or(esv->expr,
+ expr_alloc_and(parent->prompt->visible.expr,
+ expr_alloc_symbol(&symbol_mod)));
}
}
@@ -509,6 +548,7 @@ void get_symbol_str(struct gstr *r, struct symbol *sym)
{
bool hit;
struct property *prop;
+ struct expr_select_value *esv;
if (sym && sym->name) {
str_printf(r, "Symbol: %s [=%s]\n", sym->name,
@@ -533,6 +573,11 @@ void get_symbol_str(struct gstr *r, struct symbol *sym)
} else
str_printf(r, " && ");
expr_gstr_print(prop->expr, r);
+ if (prop->value) {
+ str_printf(r, " (value=");
+ expr_gstr_print(prop->value, r);
+ str_printf(r, ")");
+ }
}
if (hit)
str_append(r, "\n");
@@ -541,6 +586,13 @@ void get_symbol_str(struct gstr *r, struct symbol *sym)
expr_gstr_print(sym->rev_dep.expr, r);
str_append(r, "\n");
}
+ for (esv = sym->val_dep; esv; esv = esv->next) {
+ str_append(r, " Selected by: ");
+ expr_gstr_print(esv->expr, r);
+ str_append(r, " with value: ");
+ expr_gstr_print(esv->value, r);
+ str_append(r, "\n");
+ }
str_append(r, "\n\n");
}
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index c127fa3..8fbfc15 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -190,6 +190,7 @@ static void sym_calc_visibility(struct symbol *sym)
{
struct property *prop;
tristate tri;
+ struct expr_select_value *esv;
/* any prompt visible? */
tri = no;
@@ -224,6 +225,15 @@ static void sym_calc_visibility(struct symbol *sym)
sym->rev_dep.tri = tri;
sym_set_changed(sym);
}
+ for (esv = sym->val_dep; esv; esv = esv->next) {
+ tri = expr_calc_value(esv->expr);
+ if (tri == mod && sym_get_type(sym) == S_BOOLEAN)
+ tri = yes;
+ if (esv->tri != tri) {
+ esv->tri = tri;
+ sym_set_changed(sym);
+ }
+ }
}
static struct symbol *sym_calc_choice(struct symbol *sym)
@@ -268,6 +278,8 @@ void sym_calc_value(struct symbol *sym)
struct symbol_value newval, oldval;
struct property *prop;
struct expr *e;
+ struct expr_select_value *esv;
+ int got_sel_val;
if (!sym)
return;
@@ -321,6 +333,9 @@ void sym_calc_value(struct symbol *sym)
}
if (sym->rev_dep.tri != no)
sym->flags |= SYMBOL_WRITE;
+ for (esv = sym->val_dep; esv; esv = esv->next)
+ if (esv->tri != no)
+ sym->flags |= SYMBOL_WRITE;
if (!sym_is_choice(sym)) {
prop = sym_get_default_prop(sym);
if (prop) {
@@ -330,15 +345,34 @@ void sym_calc_value(struct symbol *sym)
}
}
calc_newval:
- if (sym->dir_dep.tri == no && sym->rev_dep.tri != no) {
- fprintf(stderr, "warning: (");
- expr_fprint(sym->rev_dep.expr, stderr);
- fprintf(stderr, ") selects %s which has unmet direct dependencies (",
- sym->name);
- expr_fprint(sym->dir_dep.expr, stderr);
- fprintf(stderr, ")\n");
+ if (sym->dir_dep.tri == no) {
+ if (sym->rev_dep.tri != no) {
+ fprintf(stderr, "warning: (");
+ expr_fprint(sym->rev_dep.expr, stderr);
+ fprintf(stderr, ") selects %s which has unmet direct dependencies (",
+ sym->name);
+ expr_fprint(sym->dir_dep.expr, stderr);
+ fprintf(stderr, ")\n");
+ }
+ for (esv = sym->val_dep; esv; esv = esv->next) {
+ if ((esv->tri != no) &&
+ (expr_calc_value(esv->value) != no)) {
+ fprintf(stderr, "warning: (");
+ expr_fprint(esv->expr, stderr);
+ fprintf(stderr, ") selects %s (with value ",
+ sym->name);
+ expr_fprint(esv->value, stderr);
+ fprintf(stderr, ") which has unmet direct dependencies (");
+ expr_fprint(sym->dir_dep.expr, stderr);
+ fprintf(stderr, ")\n");
+ }
+ }
}
newval.tri = EXPR_OR(newval.tri, sym->rev_dep.tri);
+ for (esv = sym->val_dep; esv; esv = esv->next)
+ if (esv->tri != no)
+ newval.tri = EXPR_OR(newval.tri,
+ expr_calc_value(esv->value));
}
if (newval.tri == mod && sym_get_type(sym) == S_BOOLEAN)
newval.tri = yes;
@@ -353,6 +387,23 @@ void sym_calc_value(struct symbol *sym)
break;
}
}
+ got_sel_val = 0;
+ for (esv = sym->val_dep; esv; esv = esv->next) {
+ if (esv->tri != no) {
+ struct symbol *ss = esv->value->left.sym;
+
+ if (got_sel_val) {
+ /* warn of more than one value selected */
+ } else {
+ sym->flags |= SYMBOL_WRITE;
+ sym_calc_value(ss);
+ newval.val = ss->curr.val;
+ got_sel_val = 1;
+ }
+ }
+ }
+ if (got_sel_val)
+ break;
prop = sym_get_default_prop(sym);
if (prop) {
struct symbol *ds = prop_get_symbol(prop);
@@ -432,6 +483,8 @@ void sym_set_all_changed(void)
bool sym_tristate_within_range(struct symbol *sym, tristate val)
{
int type = sym_get_type(sym);
+ struct expr_select_value *esv;
+ tristate tri;
if (sym->visible == no)
return false;
@@ -441,11 +494,14 @@ bool sym_tristate_within_range(struct symbol *sym, tristate val)
if (type == S_BOOLEAN && val == mod)
return false;
- if (sym->visible <= sym->rev_dep.tri)
+ tri = sym->rev_dep.tri;
+ for (esv = sym->val_dep; esv; esv = esv->next)
+ tri = EXPR_OR(tri, esv->tri);
+ if (sym->visible <= tri)
return false;
if (sym_is_choice_value(sym) && sym->visible == yes)
return val == yes;
- return val >= sym->rev_dep.tri && val <= sym->visible;
+ return val >= tri && val <= sym->visible;
}
bool sym_set_tristate_value(struct symbol *sym, tristate val)
@@ -666,7 +722,13 @@ const char *sym_get_string_value(struct symbol *sym)
bool sym_is_changable(struct symbol *sym)
{
- return sym->visible > sym->rev_dep.tri;
+ tristate tri = sym->rev_dep.tri;
+ struct expr_select_value *esv;
+
+ for (esv = sym->val_dep; esv; esv = esv->next)
+ tri = EXPR_OR(tri, esv->tri);
+
+ return sym->visible > tri;
}
static unsigned strhash(const char *s)
@@ -819,10 +881,16 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym)
{
struct symbol *sym2;
struct property *prop;
+ struct expr_select_value *esv;
sym2 = sym_check_expr_deps(sym->rev_dep.expr);
if (sym2)
return sym2;
+ for (esv = sym->val_dep; esv; esv = esv->next) {
+ sym2 = sym_check_expr_deps(esv->expr);
+ if (sym2)
+ return sym2;
+ }
for (prop = sym->prop; prop; prop = prop->next) {
if (prop->type == P_CHOICE || prop->type == P_SELECT)
diff --git a/scripts/kconfig/zconf.tab.c_shipped b/scripts/kconfig/zconf.tab.c_shipped
index 32a9eef..307bf23 100644
--- a/scripts/kconfig/zconf.tab.c_shipped
+++ b/scripts/kconfig/zconf.tab.c_shipped
@@ -419,16 +419,16 @@ union yyalloc
/* YYFINAL -- State number of the termination state. */
#define YYFINAL 3
/* YYLAST -- Last index in YYTABLE. */
-#define YYLAST 259
+#define YYLAST 268
/* YYNTOKENS -- Number of terminals. */
#define YYNTOKENS 35
/* YYNNTS -- Number of nonterminals. */
#define YYNNTS 46
/* YYNRULES -- Number of rules. */
-#define YYNRULES 110
+#define YYNRULES 111
/* YYNRULES -- Number of states. */
-#define YYNSTATES 180
+#define YYNSTATES 183
/* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX. */
#define YYUNDEFTOK 2
@@ -480,14 +480,14 @@ static const yytype_uint16 yyprhs[] =
28, 33, 37, 39, 41, 43, 45, 47, 49, 51,
53, 55, 57, 59, 61, 63, 67, 70, 74, 77,
81, 84, 85, 88, 91, 94, 97, 100, 103, 107,
- 112, 117, 122, 128, 132, 133, 137, 138, 141, 145,
- 148, 150, 154, 155, 158, 161, 164, 167, 170, 175,
- 179, 182, 187, 188, 191, 195, 197, 201, 202, 205,
- 208, 211, 215, 218, 220, 224, 225, 228, 231, 234,
- 238, 242, 245, 248, 251, 252, 255, 258, 261, 266,
- 267, 270, 272, 274, 277, 280, 283, 285, 288, 289,
- 292, 294, 298, 302, 306, 309, 313, 317, 319, 321,
- 322
+ 112, 117, 122, 128, 134, 138, 139, 143, 144, 147,
+ 151, 154, 156, 160, 161, 164, 167, 170, 173, 176,
+ 181, 185, 188, 193, 194, 197, 201, 203, 207, 208,
+ 211, 214, 217, 221, 224, 226, 230, 231, 234, 237,
+ 240, 244, 248, 251, 254, 257, 258, 261, 264, 267,
+ 272, 273, 276, 278, 280, 283, 286, 289, 291, 294,
+ 295, 298, 300, 304, 308, 312, 315, 319, 323, 325,
+ 327, 328
};
/* YYRHS -- A `-1'-separated list of the rules' RHS. */
@@ -505,27 +505,27 @@ static const yytype_int8 yyrhs[] =
-1, 45, 72, -1, 45, 70, -1, 45, 40, -1,
45, 30, -1, 19, 73, 30, -1, 18, 74, 77,
30, -1, 20, 78, 77, 30, -1, 21, 25, 77,
- 30, -1, 22, 79, 79, 77, 30, -1, 23, 48,
- 30, -1, -1, 48, 25, 49, -1, -1, 33, 74,
- -1, 7, 80, 30, -1, 50, 54, -1, 75, -1,
- 51, 56, 52, -1, -1, 54, 55, -1, 54, 72,
- -1, 54, 70, -1, 54, 30, -1, 54, 40, -1,
- 18, 74, 77, 30, -1, 19, 73, 30, -1, 17,
- 30, -1, 20, 25, 77, 30, -1, -1, 56, 39,
- -1, 14, 78, 76, -1, 75, -1, 57, 60, 58,
- -1, -1, 60, 39, -1, 60, 64, -1, 60, 53,
- -1, 4, 74, 30, -1, 61, 71, -1, 75, -1,
- 62, 65, 63, -1, -1, 65, 39, -1, 65, 64,
- -1, 65, 53, -1, 6, 74, 30, -1, 9, 74,
- 30, -1, 67, 71, -1, 12, 30, -1, 69, 13,
- -1, -1, 71, 72, -1, 71, 30, -1, 71, 40,
- -1, 16, 24, 78, 30, -1, -1, 74, 77, -1,
- 25, -1, 26, -1, 5, 30, -1, 8, 30, -1,
- 15, 30, -1, 30, -1, 76, 30, -1, -1, 14,
- 78, -1, 79, -1, 79, 33, 79, -1, 79, 27,
- 79, -1, 29, 78, 28, -1, 34, 78, -1, 78,
- 31, 78, -1, 78, 32, 78, -1, 25, -1, 26,
- -1, -1, 25, -1
+ 30, -1, 21, 25, 78, 77, 30, -1, 22, 79,
+ 79, 77, 30, -1, 23, 48, 30, -1, -1, 48,
+ 25, 49, -1, -1, 33, 74, -1, 7, 80, 30,
+ -1, 50, 54, -1, 75, -1, 51, 56, 52, -1,
+ -1, 54, 55, -1, 54, 72, -1, 54, 70, -1,
+ 54, 30, -1, 54, 40, -1, 18, 74, 77, 30,
+ -1, 19, 73, 30, -1, 17, 30, -1, 20, 25,
+ 77, 30, -1, -1, 56, 39, -1, 14, 78, 76,
+ -1, 75, -1, 57, 60, 58, -1, -1, 60, 39,
+ -1, 60, 64, -1, 60, 53, -1, 4, 74, 30,
+ -1, 61, 71, -1, 75, -1, 62, 65, 63, -1,
+ -1, 65, 39, -1, 65, 64, -1, 65, 53, -1,
+ 6, 74, 30, -1, 9, 74, 30, -1, 67, 71,
+ -1, 12, 30, -1, 69, 13, -1, -1, 71, 72,
+ -1, 71, 30, -1, 71, 40, -1, 16, 24, 78,
+ 30, -1, -1, 74, 77, -1, 25, -1, 26, -1,
+ 5, 30, -1, 8, 30, -1, 15, 30, -1, 30,
+ -1, 76, 30, -1, -1, 14, 78, -1, 79, -1,
+ 79, 33, 79, -1, 79, 27, 79, -1, 29, 78,
+ 28, -1, 34, 78, -1, 78, 31, 78, -1, 78,
+ 32, 78, -1, 25, -1, 26, -1, -1, 25, -1
};
/* YYRLINE[YYN] -- source line where rule number YYN was defined. */
@@ -535,14 +535,14 @@ static const yytype_uint16 yyrline[] =
117, 121, 125, 125, 125, 125, 125, 125, 125, 129,
130, 131, 132, 133, 134, 138, 139, 145, 153, 159,
167, 177, 179, 180, 181, 182, 183, 184, 187, 195,
- 201, 211, 217, 223, 226, 228, 239, 240, 245, 254,
- 259, 267, 270, 272, 273, 274, 275, 276, 279, 285,
- 296, 302, 312, 314, 319, 327, 335, 338, 340, 341,
- 342, 347, 354, 359, 367, 370, 372, 373, 374, 377,
- 385, 392, 399, 405, 412, 414, 415, 416, 419, 427,
- 429, 434, 435, 438, 439, 440, 444, 445, 448, 449,
- 452, 453, 454, 455, 456, 457, 458, 461, 462, 465,
- 466
+ 201, 211, 217, 223, 229, 232, 234, 245, 246, 251,
+ 260, 265, 273, 276, 278, 279, 280, 281, 282, 285,
+ 291, 302, 308, 318, 320, 325, 333, 341, 344, 346,
+ 347, 348, 353, 360, 365, 373, 376, 378, 379, 380,
+ 383, 391, 398, 405, 411, 418, 420, 421, 422, 425,
+ 433, 435, 440, 441, 444, 445, 446, 450, 451, 454,
+ 455, 458, 459, 460, 461, 462, 463, 464, 467, 468,
+ 471, 472
};
#endif
@@ -590,14 +590,14 @@ static const yytype_uint8 yyr1[] =
37, 37, 38, 38, 38, 38, 38, 38, 38, 39,
39, 39, 39, 39, 39, 40, 40, 41, 42, 43,
44, 45, 45, 45, 45, 45, 45, 45, 46, 46,
- 46, 46, 46, 47, 48, 48, 49, 49, 50, 51,
- 52, 53, 54, 54, 54, 54, 54, 54, 55, 55,
- 55, 55, 56, 56, 57, 58, 59, 60, 60, 60,
- 60, 61, 62, 63, 64, 65, 65, 65, 65, 66,
- 67, 68, 69, 70, 71, 71, 71, 71, 72, 73,
- 73, 74, 74, 75, 75, 75, 76, 76, 77, 77,
- 78, 78, 78, 78, 78, 78, 78, 79, 79, 80,
- 80
+ 46, 46, 46, 46, 47, 48, 48, 49, 49, 50,
+ 51, 52, 53, 54, 54, 54, 54, 54, 54, 55,
+ 55, 55, 55, 56, 56, 57, 58, 59, 60, 60,
+ 60, 60, 61, 62, 63, 64, 65, 65, 65, 65,
+ 66, 67, 68, 69, 70, 71, 71, 71, 71, 72,
+ 73, 73, 74, 74, 75, 75, 75, 76, 76, 77,
+ 77, 78, 78, 78, 78, 78, 78, 78, 79, 79,
+ 80, 80
};
/* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN. */
@@ -607,14 +607,14 @@ static const yytype_uint8 yyr2[] =
4, 3, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 3, 2, 3, 2, 3,
2, 0, 2, 2, 2, 2, 2, 2, 3, 4,
- 4, 4, 5, 3, 0, 3, 0, 2, 3, 2,
- 1, 3, 0, 2, 2, 2, 2, 2, 4, 3,
- 2, 4, 0, 2, 3, 1, 3, 0, 2, 2,
- 2, 3, 2, 1, 3, 0, 2, 2, 2, 3,
- 3, 2, 2, 2, 0, 2, 2, 2, 4, 0,
- 2, 1, 1, 2, 2, 2, 1, 2, 0, 2,
- 1, 3, 3, 3, 2, 3, 3, 1, 1, 0,
- 1
+ 4, 4, 5, 5, 3, 0, 3, 0, 2, 3,
+ 2, 1, 3, 0, 2, 2, 2, 2, 2, 4,
+ 3, 2, 4, 0, 2, 3, 1, 3, 0, 2,
+ 2, 2, 3, 2, 1, 3, 0, 2, 2, 2,
+ 3, 3, 2, 2, 2, 0, 2, 2, 2, 4,
+ 0, 2, 1, 1, 2, 2, 2, 1, 2, 0,
+ 2, 1, 3, 3, 3, 2, 3, 3, 1, 1,
+ 0, 1
};
/* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
@@ -622,31 +622,32 @@ static const yytype_uint8 yyr2[] =
means the default is an error. */
static const yytype_uint8 yydefact[] =
{
- 3, 0, 0, 1, 0, 0, 0, 0, 0, 109,
+ 3, 0, 0, 1, 0, 0, 0, 0, 0, 110,
0, 0, 0, 0, 0, 0, 12, 16, 13, 14,
18, 15, 17, 0, 19, 0, 4, 31, 22, 31,
- 23, 52, 62, 5, 67, 20, 84, 75, 6, 24,
- 84, 21, 8, 11, 91, 92, 0, 0, 93, 0,
- 110, 0, 94, 0, 0, 0, 107, 108, 0, 0,
- 0, 100, 95, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 96, 7, 71, 79, 48, 80, 27,
- 29, 0, 104, 0, 0, 64, 0, 0, 9, 10,
- 0, 0, 0, 0, 89, 0, 0, 0, 44, 0,
- 37, 36, 32, 33, 0, 35, 34, 0, 0, 89,
- 0, 56, 57, 53, 55, 54, 63, 51, 50, 68,
- 70, 66, 69, 65, 86, 87, 85, 76, 78, 74,
- 77, 73, 97, 103, 105, 106, 102, 101, 26, 82,
- 0, 98, 0, 98, 98, 98, 0, 0, 0, 83,
- 60, 98, 0, 98, 0, 0, 0, 38, 90, 0,
- 0, 98, 46, 43, 25, 0, 59, 0, 88, 99,
- 39, 40, 41, 0, 0, 45, 58, 61, 42, 47
+ 23, 53, 63, 5, 68, 20, 85, 76, 6, 24,
+ 85, 21, 8, 11, 92, 93, 0, 0, 94, 0,
+ 111, 0, 95, 0, 0, 0, 108, 109, 0, 0,
+ 0, 101, 96, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 97, 7, 72, 80, 49, 81, 27,
+ 29, 0, 105, 0, 0, 65, 0, 0, 9, 10,
+ 0, 0, 0, 0, 90, 0, 0, 0, 45, 0,
+ 37, 36, 32, 33, 0, 35, 34, 0, 0, 90,
+ 0, 57, 58, 54, 56, 55, 64, 52, 51, 69,
+ 71, 67, 70, 66, 87, 88, 86, 77, 79, 75,
+ 78, 74, 98, 104, 106, 107, 103, 102, 26, 83,
+ 0, 99, 0, 99, 99, 99, 0, 0, 0, 84,
+ 61, 99, 0, 99, 0, 0, 0, 38, 91, 0,
+ 0, 99, 99, 47, 44, 25, 0, 60, 0, 89,
+ 100, 39, 40, 41, 0, 0, 0, 46, 59, 62,
+ 42, 43, 48
};
/* YYDEFGOTO[NTERM-NUM]. */
static const yytype_int16 yydefgoto[] =
{
-1, 1, 2, 25, 26, 101, 27, 28, 29, 30,
- 65, 102, 103, 147, 175, 31, 32, 117, 33, 67,
+ 65, 102, 103, 147, 177, 31, 32, 117, 33, 67,
113, 68, 34, 121, 35, 69, 36, 37, 129, 38,
71, 39, 40, 41, 104, 105, 70, 106, 142, 143,
42, 74, 156, 60, 61, 51
@@ -661,65 +662,67 @@ static const yytype_int16 yypact[] =
33, -1, 27, 40, -3, 38, -80, -80, -80, -80,
-80, -80, -80, 71, -80, 77, -80, -80, -80, -80,
-80, -80, -80, -80, -80, -80, -80, -80, -80, -80,
- -80, -80, -80, -80, -80, -80, 57, 61, -80, 63,
- -80, 76, -80, 87, 101, 133, -80, -80, -3, -3,
- 195, -6, -80, 136, 149, 39, 104, 65, 150, 5,
- 194, 5, 167, -80, 176, -80, -80, -80, -80, -80,
- -80, 68, -80, -3, -3, 176, 72, 72, -80, -80,
- 177, 187, 78, -1, -1, -3, 196, 72, -80, 222,
- -80, -80, -80, -80, 221, -80, -80, 205, -1, -1,
- 211, -80, -80, -80, -80, -80, -80, -80, -80, -80,
+ -80, -80, -80, -80, -80, -80, 57, 63, -80, 76,
+ -80, 87, -80, 101, 115, 128, -80, -80, -3, -3,
+ 209, -6, -80, 137, 162, 39, 104, 65, 208, 5,
+ 196, 5, 169, -80, 166, -80, -80, -80, -80, -80,
+ -80, 68, -80, -3, -3, 166, 72, 72, -80, -80,
+ 168, 178, 78, -1, -1, -3, 184, 72, -80, 219,
+ -80, -80, -80, -80, 211, -80, -80, 195, -1, -1,
+ 205, -80, -80, -80, -80, -80, -80, -80, -80, -80,
-80, -80, -80, -80, -80, -80, -80, -80, -80, -80,
- -80, -80, -80, -80, 206, -80, -80, -80, -80, -80,
- -3, 223, 209, 223, 197, 223, 72, 7, 210, -80,
- -80, 223, 212, 223, 201, -3, 213, -80, -80, 214,
- 215, 223, 208, -80, -80, 216, -80, 217, -80, 113,
- -80, -80, -80, 218, -1, -80, -80, -80, -80, -80
+ -80, -80, -80, -80, 199, -80, -80, -80, -80, -80,
+ -3, 220, 206, 220, 201, 130, 72, 7, 217, -80,
+ -80, 220, 218, 220, 212, -3, 221, -80, -80, 222,
+ 223, 201, 220, 216, -80, -80, 224, -80, 225, -80,
+ 150, -80, -80, -80, 226, 227, -1, -80, -80, -80,
+ -80, -80, -80
};
/* YYPGOTO[NTERM-NUM]. */
static const yytype_int16 yypgoto[] =
{
- -80, -80, -80, -80, 122, -34, -80, -80, -80, -80,
- 220, -80, -80, -80, -80, -80, -80, -80, 59, -80,
- -80, -80, -80, -80, -80, -80, -80, -80, -80, 125,
- -80, -80, -80, -80, -80, 183, 219, 22, 142, -5,
- 147, 192, 69, -54, -79, -80
+ -80, -80, -80, -80, 92, -34, -80, -80, -80, -80,
+ 229, -80, -80, -80, -80, -80, -80, -80, 59, -80,
+ -80, -80, -80, -80, -80, -80, -80, -80, -80, 124,
+ -80, -80, -80, -80, -80, 183, 228, 22, 151, -5,
+ 97, 202, 84, -54, -79, -80
};
/* YYTABLE[YYPACT[STATE-NUM]]. What to do in state STATE-NUM. If
positive, shift that token. If negative, reduce the rule which
number is the opposite. If zero, do what YYDEFACT says.
If YYTABLE_NINF, syntax error. */
-#define YYTABLE_NINF -82
+#define YYTABLE_NINF -83
static const yytype_int16 yytable[] =
{
46, 47, 3, 49, 81, 82, 53, 136, 137, 6,
7, 8, 9, 10, 11, 12, 13, 43, 146, 14,
15, 86, 56, 57, 44, 45, 58, 87, 48, 134,
- 135, 59, 162, 112, 50, 24, 125, 163, 125, -28,
+ 135, 59, 163, 112, 50, 24, 125, 164, 125, -28,
90, 144, -28, -28, -28, -28, -28, -28, -28, -28,
-28, 91, 54, -28, -28, 92, -28, 93, 94, 95,
- 96, 97, 98, 52, 99, 55, 90, 161, 62, 100,
- -49, -49, 63, -49, -49, -49, -49, 91, 64, -49,
- -49, 92, 107, 108, 109, 110, 154, 73, 141, 115,
- 99, 75, 126, 76, 126, 111, 133, 56, 57, 83,
- 84, 169, 140, 151, -30, 90, 77, -30, -30, -30,
- -30, -30, -30, -30, -30, -30, 91, 78, -30, -30,
+ 96, 97, 98, 52, 99, 55, 90, 162, 62, 100,
+ -50, -50, 63, -50, -50, -50, -50, 91, 64, -50,
+ -50, 92, 107, 108, 109, 110, 154, 73, 141, 115,
+ 99, 161, 126, 75, 126, 111, 133, 56, 57, 83,
+ 84, 170, 140, 151, -30, 90, 76, -30, -30, -30,
+ -30, -30, -30, -30, -30, -30, 91, 77, -30, -30,
92, -30, 93, 94, 95, 96, 97, 98, 120, 99,
- 128, 79, -2, 4, 100, 5, 6, 7, 8, 9,
- 10, 11, 12, 13, 83, 84, 14, 15, 16, 17,
- 18, 19, 20, 21, 22, 7, 8, 23, 10, 11,
- 12, 13, 24, 80, 14, 15, 88, -81, 90, 179,
- -81, -81, -81, -81, -81, -81, -81, -81, -81, 89,
- 24, -81, -81, 92, -81, -81, -81, -81, -81, -81,
- 116, 119, 99, 127, 122, 90, 130, 124, -72, -72,
- -72, -72, -72, -72, -72, -72, 132, 138, -72, -72,
- 92, 155, 158, 159, 160, 118, 123, 139, 131, 99,
- 165, 145, 167, 148, 124, 73, 83, 84, 83, 84,
- 173, 168, 83, 84, 149, 150, 153, 155, 84, 157,
- 164, 174, 166, 170, 171, 172, 176, 177, 178, 66,
- 114, 152, 85, 0, 0, 0, 0, 0, 0, 72
+ 128, 78, -2, 4, 100, 5, 6, 7, 8, 9,
+ 10, 11, 12, 13, 155, 79, 14, 15, 16, 17,
+ 18, 19, 20, 21, 22, 56, 57, 23, 80, 58,
+ 116, 119, 24, 127, 59, 118, 123, 88, 131, -82,
+ 90, 182, -82, -82, -82, -82, -82, -82, -82, -82,
+ -82, 83, 84, -82, -82, 92, -82, -82, -82, -82,
+ -82, -82, 89, 122, 99, 130, 132, 90, 138, 124,
+ -73, -73, -73, -73, -73, -73, -73, -73, 139, 145,
+ -73, -73, 92, 7, 8, 155, 10, 11, 12, 13,
+ 148, 99, 14, 15, 149, 150, 124, 158, 159, 160,
+ 153, 84, 83, 84, 155, 166, 157, 168, 24, 73,
+ 83, 84, 169, 83, 84, 174, 175, 165, 167, 176,
+ 114, 171, 172, 173, 178, 179, 180, 181, 66, 0,
+ 152, 0, 85, 0, 0, 0, 0, 0, 72
};
static const yytype_int16 yycheck[] =
@@ -733,23 +736,24 @@ static const yytype_int16 yycheck[] =
21, 22, 23, 30, 25, 25, 1, 146, 30, 30,
5, 6, 1, 8, 9, 10, 11, 12, 1, 14,
15, 16, 17, 18, 19, 20, 140, 30, 93, 67,
- 25, 30, 70, 30, 72, 30, 28, 25, 26, 31,
+ 25, 145, 70, 30, 72, 30, 28, 25, 26, 31,
32, 155, 24, 108, 0, 1, 30, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12, 30, 14, 15,
16, 17, 18, 19, 20, 21, 22, 23, 69, 25,
71, 30, 0, 1, 30, 3, 4, 5, 6, 7,
- 8, 9, 10, 11, 31, 32, 14, 15, 16, 17,
- 18, 19, 20, 21, 22, 5, 6, 25, 8, 9,
- 10, 11, 30, 30, 14, 15, 30, 0, 1, 174,
- 3, 4, 5, 6, 7, 8, 9, 10, 11, 30,
- 30, 14, 15, 16, 17, 18, 19, 20, 21, 22,
- 68, 69, 25, 71, 69, 1, 71, 30, 4, 5,
- 6, 7, 8, 9, 10, 11, 30, 30, 14, 15,
- 16, 14, 143, 144, 145, 68, 69, 30, 71, 25,
- 151, 25, 153, 1, 30, 30, 31, 32, 31, 32,
- 161, 30, 31, 32, 13, 30, 25, 14, 32, 30,
- 30, 33, 30, 30, 30, 30, 30, 30, 30, 29,
- 67, 109, 60, -1, -1, -1, -1, -1, -1, 40
+ 8, 9, 10, 11, 14, 30, 14, 15, 16, 17,
+ 18, 19, 20, 21, 22, 25, 26, 25, 30, 29,
+ 68, 69, 30, 71, 34, 68, 69, 30, 71, 0,
+ 1, 176, 3, 4, 5, 6, 7, 8, 9, 10,
+ 11, 31, 32, 14, 15, 16, 17, 18, 19, 20,
+ 21, 22, 30, 69, 25, 71, 30, 1, 30, 30,
+ 4, 5, 6, 7, 8, 9, 10, 11, 30, 25,
+ 14, 15, 16, 5, 6, 14, 8, 9, 10, 11,
+ 1, 25, 14, 15, 13, 30, 30, 143, 144, 145,
+ 25, 32, 31, 32, 14, 151, 30, 153, 30, 30,
+ 31, 32, 30, 31, 32, 161, 162, 30, 30, 33,
+ 67, 30, 30, 30, 30, 30, 30, 30, 29, -1,
+ 109, -1, 60, -1, -1, -1, -1, -1, 40
};
/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
@@ -772,8 +776,9 @@ static const yytype_uint8 yystos[] =
64, 75, 30, 28, 78, 78, 79, 79, 30, 30,
24, 74, 73, 74, 78, 25, 79, 48, 1, 13,
30, 74, 73, 25, 78, 14, 77, 30, 77, 77,
- 77, 79, 25, 30, 30, 77, 30, 77, 30, 78,
- 30, 30, 30, 77, 33, 49, 30, 30, 30, 74
+ 77, 78, 79, 25, 30, 30, 77, 30, 77, 30,
+ 78, 30, 30, 30, 77, 77, 33, 49, 30, 30,
+ 30, 30, 74
};
#define yyerrok (yyerrstatus = 0)
@@ -1719,7 +1724,7 @@ yyreduce:
case 41:
{
- menu_add_symbol(P_SELECT, sym_lookup((yyvsp[(2) - (4)].string), 0), (yyvsp[(3) - (4)].expr));
+ menu_add_select(sym_lookup((yyvsp[(2) - (4)].string), 0), NULL, (yyvsp[(3) - (4)].expr));
printd(DEBUG_PARSE, "%s:%d:select\n", zconf_curname(), zconf_lineno());
;}
break;
@@ -1727,12 +1732,20 @@ yyreduce:
case 42:
{
+ menu_add_select(sym_lookup((yyvsp[(2) - (5)].string), 0), (yyvsp[(3) - (5)].expr), (yyvsp[(4) - (5)].expr));
+ printd(DEBUG_PARSE, "%s:%d:select with value\n", zconf_curname(), zconf_lineno());
+;}
+ break;
+
+ case 43:
+
+ {
menu_add_expr(P_RANGE, expr_alloc_comp(E_RANGE,(yyvsp[(2) - (5)].symbol), (yyvsp[(3) - (5)].symbol)), (yyvsp[(4) - (5)].expr));
printd(DEBUG_PARSE, "%s:%d:range\n", zconf_curname(), zconf_lineno());
;}
break;
- case 45:
+ case 46:
{
struct kconf_id *id = kconf_id_lookup((yyvsp[(2) - (3)].string), strlen((yyvsp[(2) - (3)].string)));
@@ -1744,17 +1757,17 @@ yyreduce:
;}
break;
- case 46:
+ case 47:
{ (yyval.string) = NULL; ;}
break;
- case 47:
+ case 48:
{ (yyval.string) = (yyvsp[(2) - (2)].string); ;}
break;
- case 48:
+ case 49:
{
struct symbol *sym = sym_lookup((yyvsp[(2) - (3)].string), SYMBOL_CHOICE);
@@ -1765,14 +1778,14 @@ yyreduce:
;}
break;
- case 49:
+ case 50:
{
(yyval.menu) = menu_add_menu();
;}
break;
- case 50:
+ case 51:
{
if (zconf_endtoken((yyvsp[(1) - (1)].id), T_CHOICE, T_ENDCHOICE)) {
@@ -1782,7 +1795,7 @@ yyreduce:
;}
break;
- case 58:
+ case 59:
{
menu_add_prompt(P_PROMPT, (yyvsp[(2) - (4)].string), (yyvsp[(3) - (4)].expr));
@@ -1790,7 +1803,7 @@ yyreduce:
;}
break;
- case 59:
+ case 60:
{
if ((yyvsp[(1) - (3)].id)->stype == S_BOOLEAN || (yyvsp[(1) - (3)].id)->stype == S_TRISTATE) {
@@ -1803,7 +1816,7 @@ yyreduce:
;}
break;
- case 60:
+ case 61:
{
current_entry->sym->flags |= SYMBOL_OPTIONAL;
@@ -1811,7 +1824,7 @@ yyreduce:
;}
break;
- case 61:
+ case 62:
{
if ((yyvsp[(1) - (4)].id)->stype == S_UNKNOWN) {
@@ -1823,7 +1836,7 @@ yyreduce:
;}
break;
- case 64:
+ case 65:
{
printd(DEBUG_PARSE, "%s:%d:if\n", zconf_curname(), zconf_lineno());
@@ -1833,7 +1846,7 @@ yyreduce:
;}
break;
- case 65:
+ case 66:
{
if (zconf_endtoken((yyvsp[(1) - (1)].id), T_IF, T_ENDIF)) {
@@ -1843,7 +1856,7 @@ yyreduce:
;}
break;
- case 71:
+ case 72:
{
menu_add_entry(NULL);
@@ -1852,14 +1865,14 @@ yyreduce:
;}
break;
- case 72:
+ case 73:
{
(yyval.menu) = menu_add_menu();
;}
break;
- case 73:
+ case 74:
{
if (zconf_endtoken((yyvsp[(1) - (1)].id), T_MENU, T_ENDMENU)) {
@@ -1869,7 +1882,7 @@ yyreduce:
;}
break;
- case 79:
+ case 80:
{
printd(DEBUG_PARSE, "%s:%d:source %s\n", zconf_curname(), zconf_lineno(), (yyvsp[(2) - (3)].string));
@@ -1877,7 +1890,7 @@ yyreduce:
;}
break;
- case 80:
+ case 81:
{
menu_add_entry(NULL);
@@ -1886,14 +1899,14 @@ yyreduce:
;}
break;
- case 81:
+ case 82:
{
menu_end_entry();
;}
break;
- case 82:
+ case 83:
{
printd(DEBUG_PARSE, "%s:%d:help\n", zconf_curname(), zconf_lineno());
@@ -1901,14 +1914,14 @@ yyreduce:
;}
break;
- case 83:
+ case 84:
{
current_entry->help = (yyvsp[(2) - (2)].string);
;}
break;
- case 88:
+ case 89:
{
menu_add_dep((yyvsp[(3) - (4)].expr));
@@ -1916,84 +1929,84 @@ yyreduce:
;}
break;
- case 90:
+ case 91:
{
menu_add_prompt(P_PROMPT, (yyvsp[(1) - (2)].string), (yyvsp[(2) - (2)].expr));
;}
break;
- case 93:
+ case 94:
{ (yyval.id) = (yyvsp[(1) - (2)].id); ;}
break;
- case 94:
+ case 95:
{ (yyval.id) = (yyvsp[(1) - (2)].id); ;}
break;
- case 95:
+ case 96:
{ (yyval.id) = (yyvsp[(1) - (2)].id); ;}
break;
- case 98:
+ case 99:
{ (yyval.expr) = NULL; ;}
break;
- case 99:
+ case 100:
{ (yyval.expr) = (yyvsp[(2) - (2)].expr); ;}
break;
- case 100:
+ case 101:
{ (yyval.expr) = expr_alloc_symbol((yyvsp[(1) - (1)].symbol)); ;}
break;
- case 101:
+ case 102:
{ (yyval.expr) = expr_alloc_comp(E_EQUAL, (yyvsp[(1) - (3)].symbol), (yyvsp[(3) - (3)].symbol)); ;}
break;
- case 102:
+ case 103:
{ (yyval.expr) = expr_alloc_comp(E_UNEQUAL, (yyvsp[(1) - (3)].symbol), (yyvsp[(3) - (3)].symbol)); ;}
break;
- case 103:
+ case 104:
{ (yyval.expr) = (yyvsp[(2) - (3)].expr); ;}
break;
- case 104:
+ case 105:
{ (yyval.expr) = expr_alloc_one(E_NOT, (yyvsp[(2) - (2)].expr)); ;}
break;
- case 105:
+ case 106:
{ (yyval.expr) = expr_alloc_two(E_OR, (yyvsp[(1) - (3)].expr), (yyvsp[(3) - (3)].expr)); ;}
break;
- case 106:
+ case 107:
{ (yyval.expr) = expr_alloc_two(E_AND, (yyvsp[(1) - (3)].expr), (yyvsp[(3) - (3)].expr)); ;}
break;
- case 107:
+ case 108:
{ (yyval.symbol) = sym_lookup((yyvsp[(1) - (1)].string), 0); free((yyvsp[(1) - (1)].string)); ;}
break;
- case 108:
+ case 109:
{ (yyval.symbol) = sym_lookup((yyvsp[(1) - (1)].string), SYMBOL_CONST); free((yyvsp[(1) - (1)].string)); ;}
break;
- case 109:
+ case 110:
{ (yyval.string) = NULL; ;}
break;
@@ -2387,6 +2400,15 @@ static void print_symbol(FILE *out, struct menu *menu)
case P_SELECT:
fputs( " select ", out);
expr_fprint(prop->expr, out);
+ if (prop->value) {
+ fputs(" (value=", out);
+ expr_fprint(prop->value, out);
+ fputc(')', out);
+ }
+ if (!expr_is_yes(prop->visible.expr)) {
+ fputs(" if ", out);
+ expr_fprint(prop->visible.expr, out);
+ }
fputc('\n', out);
break;
case P_RANGE:
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 23dfd3b..5f2a413 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -210,10 +210,16 @@ config_option: T_DEFAULT expr if_expr T_EOL
config_option: T_SELECT T_WORD if_expr T_EOL
{
- menu_add_symbol(P_SELECT, sym_lookup($2, 0), $3);
+ menu_add_select(sym_lookup($2, 0), NULL, $3);
printd(DEBUG_PARSE, "%s:%d:select\n", zconf_curname(), zconf_lineno());
};
+config_option: T_SELECT T_WORD expr if_expr T_EOL
+{
+ menu_add_select(sym_lookup($2, 0), $3, $4);
+ printd(DEBUG_PARSE, "%s:%d:select with value\n", zconf_curname(), zconf_lineno());
+};
+
config_option: T_RANGE symbol symbol if_expr T_EOL
{
menu_add_expr(P_RANGE, expr_alloc_comp(E_RANGE,$2, $3), $4);
@@ -642,6 +648,15 @@ static void print_symbol(FILE *out, struct menu *menu)
case P_SELECT:
fputs( " select ", out);
expr_fprint(prop->expr, out);
+ if (prop->value) {
+ fputs(" (value=", out);
+ expr_fprint(prop->value, out);
+ fputc(')', out);
+ }
+ if (!expr_is_yes(prop->visible.expr)) {
+ fputs(" if ", out);
+ expr_fprint(prop->visible.expr, out);
+ }
fputc('\n', out);
break;
case P_RANGE:
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH] math-emu: correct test for downshifting fraction in _FP_FROM_INT()
From: Mikael Pettersson @ 2010-07-19 22:12 UTC (permalink / raw)
To: Mikael Pettersson
Cc: linux-s390, linux-sh, linux-kernel, linuxppc-dev, linux-alpha,
sparclinux
In-Reply-To: <19524.51858.992299.119315@pilspetsen.it.uu.se>
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 4700 bytes --]
Mikael Pettersson writes:
> The kernel's math-emu code contains a macro _FP_FROM_INT() which is
> used to convert an integer to a raw normalized floating-point value.
> It does this basically in three steps:
>
> 1. Compute the exponent from the number of leading zero bits.
> 2. Downshift large fractions to put the MSB in the right position
> for normalized fractions.
> 3. Upshift small fractions to put the MSB in the right position.
>
> There is an boundary error in step 2, causing a fraction with its
> MSB exactly one bit above the normalized MSB position to not be
> downshifted. This results in a non-normalized raw float, which when
> packed becomes a massively inaccurate representation for that input.
>
> The impact of this depends on a number of arch-specific factors,
> but it is known to have broken emulation of FXTOD instructions
> on UltraSPARC III, which was originally reported as GCC bug 44631
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631>.
>
> Any arch which uses math-emu to emulate conversions from integers to
> same-size floats may be affected.
>
> The fix is simple: the exponent comparison used to determine if the
> fraction should be downshifted must be "<=" not "<".
>
> I'm sending a kernel module to test this as a reply to this message.
> There are also SPARC user-space test cases in the GCC bug entry.
And here's the test module.
To illustrate the bug it uses math-emu to convert a series of
single-bit power-of-two ints to corresponding floats and back,
and prints the intermediate representations and the differences
between the original values and the final ones. These ints all
have exact float representations so there should be no differences.
But for 0x08000000 the conversion goes wrong. The test case
then converts a few more numbers near this one and up to the next
power-of-two which did convert Ok.
With an unpatched kernel you get the following kernel messages
after insmod:
mathemu_test: init
test_itof: 0x40000000 -> 0x4e800000 -> 0x40000000, diff 0
test_itof: 0x20000000 -> 0x4e000000 -> 0x20000000, diff 0
test_itof: 0x10000000 -> 0x4d800000 -> 0x10000000, diff 0
test_itof: 0x08000000 -> 0x4d800000 -> 0x10000000, diff 134217728
test_itof: 0x04000000 -> 0x4c800000 -> 0x04000000, diff 0
test_itof: 0x02000000 -> 0x4c000000 -> 0x02000000, diff 0
test_itof: 0x01000000 -> 0x4b800000 -> 0x01000000, diff 0
test_itof: 0x00800000 -> 0x4b000000 -> 0x00800000, diff 0
test_itof: 0x0f000000 -> 0x4de00000 -> 0x1c000000, diff 218103808
test_itof: 0x0e000000 -> 0x4dc00000 -> 0x18000000, diff 167772160
test_itof: 0x0d000000 -> 0x4da00000 -> 0x14000000, diff 117440512
test_itof: 0x0c000000 -> 0x4d800000 -> 0x10000000, diff 67108864
test_itof: 0x0b000000 -> 0x4de00000 -> 0x1c000000, diff 285212672
test_itof: 0x0a000000 -> 0x4dc00000 -> 0x18000000, diff 234881024
test_itof: 0x09000000 -> 0x4da00000 -> 0x14000000, diff 184549376
test_itof: 0x08000000 -> 0x4d800000 -> 0x10000000, diff 134217728
test_itof: 0x07000000 -> 0x4ce00000 -> 0x07000000, diff 0
With the patch applied, you instead get this:
mathemu_test: init
test_itof: 0x40000000 -> 0x4e800000 -> 0x40000000, diff 0
test_itof: 0x20000000 -> 0x4e000000 -> 0x20000000, diff 0
test_itof: 0x10000000 -> 0x4d800000 -> 0x10000000, diff 0
test_itof: 0x08000000 -> 0x4d000000 -> 0x08000000, diff 0
test_itof: 0x04000000 -> 0x4c800000 -> 0x04000000, diff 0
test_itof: 0x02000000 -> 0x4c000000 -> 0x02000000, diff 0
test_itof: 0x01000000 -> 0x4b800000 -> 0x01000000, diff 0
test_itof: 0x00800000 -> 0x4b000000 -> 0x00800000, diff 0
test_itof: 0x0f000000 -> 0x4d700000 -> 0x0f000000, diff 0
test_itof: 0x0e000000 -> 0x4d600000 -> 0x0e000000, diff 0
test_itof: 0x0d000000 -> 0x4d500000 -> 0x0d000000, diff 0
test_itof: 0x0c000000 -> 0x4d400000 -> 0x0c000000, diff 0
test_itof: 0x0b000000 -> 0x4d300000 -> 0x0b000000, diff 0
test_itof: 0x0a000000 -> 0x4d200000 -> 0x0a000000, diff 0
test_itof: 0x09000000 -> 0x4d100000 -> 0x09000000, diff 0
test_itof: 0x08000000 -> 0x4d000000 -> 0x08000000, diff 0
test_itof: 0x07000000 -> 0x4ce00000 -> 0x07000000, diff 0
Unfortunately it seems difficult to write a generic module
which uses math-emu:
- <math-emu/soft-fp.h> includes <asm/sfp-machine.h>,
but only a handful of archs have it
- <asm/sfp-machine.h> isn't always self-contained and may depend
on various $arch-specific declarations being present
The given test module works on sparc64 and ppc64, where it uses
the kernel's sfp-machine.h, and on x86 where it uses a stub
sfp-machine.h supplied by itself. I tried to cross-compile it
for alpha, but that failed due to its sfp-machine.h not being
self-contained. I didn't try sh or s390.
/Mikael
[-- Attachment #2: math-emu test module --]
[-- Type: application/octet-stream, Size: 1656 bytes --]
^ 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