* Re: request_irq fails to get interrupt 12
From: Benjamin Herrenschmidt @ 2007-10-22 20:33 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710221255ubbe8c91pa09640f9b9cd0775@mail.gmail.com>
On Mon, 2007-10-22 at 13:55 -0600, Alan Bennett wrote:
> Ok, so what does it take to expose an interrupt vector on a pq2 PIC??
> -Alan
Also, if it's the default PIC or if you happen to have the PIC struct
irq_host pointer at hand, a quickish way for internal device interrupts
is to directly call irq_create_mapping() though using the device-tree is
nicer.
Ben.
> Current:
> /
> localbus{
> ...
> fundevice1 {
> interrupts = <c 8>;
> interrupt-parent = <&PIC>;
> };
> ...
> soc@e0000000 {
> PIC: interrupt-controller@10c00 {
> #interrupt-cells = <2>;
> interrupt-controller;
> reg = <10c00 80>;
> compatible = "fsl,mpc8248-pic", "fsl,pq2-pic";
> };
> Is the above device tree enough on its own?
> Do I have to write some platform code beyond:
> static void __init ep8248_pic_init(void)
> {
> struct device_node *np = of_find_compatible_node(NULL, NULL, "fsl,pq2-pic");
> if (!np) {
> printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
> return;
> }
>
> cpm2_pic_init(np);
> of_node_put(np);
> }
>
> -Alan
>
> Hello,
>
> > Freescale experts. Why on earth can't I request the IRQ for Timer1?
>
> Please consule my question on [1] and the answers.
>
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html
>
> bye
> Silvio Fricke
>
> --
> -- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
> Diplom-Informatiker (FH)
> Linux-Entwicklung
> ----------------------------------------------------------------------------
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] DTC: Remove the need for the GLR Parser.
From: Jon Loeliger @ 2007-10-22 21:13 UTC (permalink / raw)
To: linuxppc-dev
Previously, there were a few shift/reduce and reduce/reduce
errors in the grammar that were being handled by the not-so-popular
GLR Parser technique.
Flip a right-recursive stack-abusing rule into a left-recursive
stack-friendly rule and clear up three messes in one shot: No more
conflicts, no need for the GLR parser, and friendlier stackness.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Makefile | 1 -
dtc-parser.y | 5 ++---
2 files changed, 2 insertions(+), 4 deletions(-)
Both "make check" and the "compare all old and new DTB kernel files"
tests are happy with this change.
diff --git a/Makefile b/Makefile
index d7d1af5..84f0efe 100644
--- a/Makefile
+++ b/Makefile
@@ -207,7 +207,6 @@ clean: libfdt_clean tests_clean
%.tab.c %.tab.h %.output: %.y
@$(VECHO) BISON $@
- @$(VECHO) ---- Expect 2 s/r and 2 r/r. ----
$(BISON) -d $<
FORCE:
diff --git a/dtc-parser.y b/dtc-parser.y
index 4698793..0d140e5 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -18,7 +18,6 @@
* USA
*/
-%glr-parser
%locations
%{
@@ -123,9 +122,9 @@ nodedef:
;
proplist:
- propdef proplist
+ proplist propdef
{
- $$ = chain_property($1, $2);
+ $$ = chain_property($2, $1);
}
| /* empty */
{
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Benjamin Herrenschmidt @ 2007-10-22 21:24 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci,
David Miller
In-Reply-To: <20071022181336.GC4280@austin.ibm.com>
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote:
> On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote:
> >
> > On pseries there's a chance it will work for PCI error recovery, but if
> > so it's just lucky that firmware has left everything configured the same
> > way.
>
> ? The papr is quite clear that i is up to the OS to restore the msi
> state after an eeh error.
Via direct config space access or via firmware change-msi calls ?
> > Yes I think so. That way we can properly reconfigure via the firmware
> > interface. The other option would be to design some new arch hook to do
> > resume, but just doing a disable/enable seems simpler to me.
>
> Err, If you read the code for suspend/resume, it never actually calls
> disable/enable (and thus doesn't go to the firmware); it calls
> restore_msi_state() function!
>
> If suspend/resume needs to call firmware to restore the state, then,
> at the moment, suspend/resume is broken. As I mentioned earlier,
> I presumed that no powerpc laptops currently use msi-enabled devices,
> as otherwise, this would have been flushed out.
I don't know why you keep talking about powerpc laptops here ...
Ben.
^ permalink raw reply
* [PATCH] DTC: Minor grammar rule shuffle.
From: Jon Loeliger @ 2007-10-22 21:59 UTC (permalink / raw)
To: linuxppc-dev
I like to see the basis cases established early in
the rule sets, so place "empty" reduction first.
Purely cosmetic.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
dtc-parser.y | 62 +++++++++++++++++++++++++++++-----------------------------
1 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 0d140e5..c213526 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -86,13 +86,13 @@ sourcefile:
;
memreserves:
- memreserve memreserves
+ /* empty */
{
- $$ = chain_reserve_entry($1, $2);
+ $$ = NULL;
}
- | /* empty */
+ | memreserve memreserves
{
- $$ = NULL;
+ $$ = chain_reserve_entry($1, $2);
}
;
@@ -122,13 +122,13 @@ nodedef:
;
proplist:
- proplist propdef
+ /* empty */
{
- $$ = chain_property($2, $1);
+ $$ = NULL;
}
- | /* empty */
+ | proplist propdef
{
- $$ = NULL;
+ $$ = chain_property($2, $1);
}
;
@@ -164,7 +164,11 @@ propdata:
;
propdataprefix:
- propdata ','
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | propdata ','
{
$$ = $1;
}
@@ -172,10 +176,6 @@ propdataprefix:
{
$$ = data_add_label($1, $2);
}
- | /* empty */
- {
- $$ = empty_data;
- }
;
opt_cell_base:
@@ -187,7 +187,11 @@ opt_cell_base:
;
celllist:
- celllist opt_cell_base DT_CELL
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | celllist opt_cell_base DT_CELL
{
$$ = data_append_cell($1,
cell_from_string($3, $2));
@@ -200,14 +204,14 @@ celllist:
{
$$ = data_add_label($1, $2);
}
- | /* empty */
- {
- $$ = empty_data;
- }
;
bytestring:
- bytestring DT_BYTE
+ /* empty */
+ {
+ $$ = empty_data;
+ }
+ | bytestring DT_BYTE
{
$$ = data_append_byte($1, $2);
}
@@ -215,20 +219,16 @@ bytestring:
{
$$ = data_add_label($1, $2);
}
- | /* empty */
- {
- $$ = empty_data;
- }
;
subnodes:
- subnode subnodes
+ /* empty */
{
- $$ = chain_node($1, $2);
+ $$ = NULL;
}
- | /* empty */
+ | subnode subnodes
{
- $$ = NULL;
+ $$ = chain_node($1, $2);
}
;
@@ -251,13 +251,13 @@ nodename:
;
label:
- DT_LABEL
+ /* empty */
{
- $$ = $1;
+ $$ = NULL;
}
- | /* empty */
+ | DT_LABEL
{
- $$ = NULL;
+ $$ = $1;
}
;
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* [PATCH] DTC: Remove an unneeded %token definition.
From: Jon Loeliger @ 2007-10-22 22:00 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
dtc-parser.y | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index c213526..61ed250 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -55,7 +55,6 @@ extern struct boot_info *the_boot_info;
%token <str> DT_CELL
%token <byte> DT_BYTE
%token <data> DT_STRING
-%token <str> DT_UNIT
%token <str> DT_LABEL
%token <str> DT_REF
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* [PATCH] DTC: Rewrite the propdata and propdataprefix rules.
From: Jon Loeliger @ 2007-10-22 22:01 UTC (permalink / raw)
To: linuxppc-dev
After staring at these two rules for a bit, and not quite
groking them, I rewrote them into something I think is a
bit clearer. With any luck, it's the same language still.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
You be the judge too!
dtc-parser.y | 31 ++++++++++++++-----------------
1 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 61ed250..f0b0178 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -59,7 +59,6 @@ extern struct boot_info *the_boot_info;
%token <str> DT_REF
%type <data> propdata
-%type <data> propdataprefix
%type <re> memreserve
%type <re> memreserves
%type <cbase> opt_cell_base
@@ -143,37 +142,35 @@ propdef:
;
propdata:
- propdataprefix DT_STRING
+ DT_STRING
{
- $$ = data_merge($1, $2);
+ $$ = data_merge(empty_data, $1);
}
- | propdataprefix '<' celllist '>'
+ | '<' celllist '>'
{
- $$ = data_merge(data_append_align($1,
- sizeof(cell_t)), $3);
+ $$ = data_merge(data_append_align(empty_data,
+ sizeof(cell_t)), $2);
}
- | propdataprefix '[' bytestring ']'
+ | '[' bytestring ']'
{
- $$ = data_merge($1, $3);
+ $$ = data_merge(empty_data, $2);
}
| propdata DT_LABEL
{
$$ = data_add_label($1, $2);
}
- ;
-
-propdataprefix:
- /* empty */
+ | propdata ',' DT_STRING
{
- $$ = empty_data;
+ $$ = data_merge($1, $3);
}
- | propdata ','
+ | propdata ',' '<' celllist '>'
{
- $$ = $1;
+ $$ = data_merge(data_append_align($1,
+ sizeof(cell_t)), $4);
}
- | propdataprefix DT_LABEL
+ | propdata ',' '[' bytestring ']'
{
- $$ = data_add_label($1, $2);
+ $$ = data_merge($1, $4);
}
;
--
1.5.3.1.139.g9346b
^ permalink raw reply related
* Re: [PATCH] DTC: Rewrite the propdata and propdataprefix rules.
From: Jon Loeliger @ 2007-10-22 22:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <E1Ik5LQ-0000Ef-UF@jdl.com>
So, like, the other day Jon Loeliger mumbled:
>
> After staring at these two rules for a bit, and not quite
> groking them, I rewrote them into something I think is a
> bit clearer. With any luck, it's the same language still.
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
>
> You be the judge too!
Yeah, so, I botched this one. It's NOT the same
language, so don't apply it or think about it at all...
jdl
^ permalink raw reply
* [PATCH] Bugfix to commit 4f9a58d75bfe82ab2b8ba5b8506dfb190a267834
From: Grant Likely @ 2007-10-22 22:38 UTC (permalink / raw)
To: Olaf Hering, linux-kernel, Linus Torvalds, Paul Mackerras,
linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Commit 4f9a58d75bfe82ab2b8ba5b8506dfb190a267834 changes the size of
AT_VECTOR_SIZE from hard coded '44' to a calculation based on the value
of AT_VECTOR_SIZE_ARCH and AT_VECTOR_SIZE_BASE. The change works for
arch/powerpc, but it breaks arch/ppc because the needed
AT_VECTOR_SIZE_ARCH is not present in include/asm-ppc/system.h and a
default value of 0 is used instead. This results in AT_VECTOR_SIZE
being too small and it causes a kernel crash on loading init.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
I think this bug fix needs to go in ASAP. I cannot boot my Virtex ppc405
platform without it.
Olaf, do I have the correct solution here?
Thanks,
g.
include/asm-ppc/system.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/system.h b/include/asm-ppc/system.h
index cc45780..51df94c 100644
--- a/include/asm-ppc/system.h
+++ b/include/asm-ppc/system.h
@@ -33,6 +33,7 @@
#define set_mb(var, value) do { var = value; mb(); } while (0)
+#define AT_VECTOR_SIZE_ARCH 6 /* entries in ARCH_DLINFO */
#ifdef CONFIG_SMP
#define smp_mb() mb()
#define smp_rmb() rmb()
^ permalink raw reply related
* Please pull powerpc.git master branch
From: Paul Mackerras @ 2007-10-23 0:08 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
to get five more commits that fix some bugs for systems using the
Freescale embedded 52xx processors and enable them to restart
properly.
Thanks,
Paul.
.../powerpc/mpc52xx-device-tree-bindings.txt | 4 +
arch/powerpc/boot/dts/lite5200.dts | 26 +++----
arch/powerpc/boot/dts/lite5200b.dts | 26 +++----
arch/powerpc/platforms/52xx/lite5200.c | 4 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 71 +++++++++++++++++++-
arch/powerpc/sysdev/bestcomm/bestcomm.c | 9 ++-
drivers/watchdog/mpc5200_wdt.c | 3 +
include/asm-powerpc/mpc52xx.h | 9 +++
8 files changed, 109 insertions(+), 43 deletions(-)
Grant Likely (1):
[POWERPC] bestcomm: Restrict bus prefetch bugfix to original mpc5200 silicon.
Marian Balakowicz (4):
[POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
[POWERPC] Update device tree binding for mpc5200 gpt
[POWERPC] Add restart support for mpc52xx based platforms
[POWERPC] Enable restart support for lite5200 board
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Linas Vepstas @ 2007-10-23 0:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci,
David Miller
In-Reply-To: <1193088267.6745.108.camel@pasglop>
On Tue, Oct 23, 2007 at 07:24:27AM +1000, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote:
> > On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote:
> > >
> > > On pseries there's a chance it will work for PCI error recovery, but if
> > > so it's just lucky that firmware has left everything configured the same
> > > way.
> >
> > ? The papr is quite clear that i is up to the OS to restore the msi
> > state after an eeh error.
>
> Via direct config space access or via firmware change-msi calls ?
Direct config space access. It says that the OS is supposed to read the
MSI config (after its been set up), save it, and restore it, (via direct
config space writes) if the device is ever reset.
> I don't know why you keep talking about powerpc laptops here ...
Well, there are Apple laptops, right? Aren't those the "powermac"
platform? Now, I don't know if they support MSI, but if they do,
I get the impression that they might not restore msi state correctly,
after being put into hardware suspend. But perhaps I'm mistaken;
I was simply grepping for various msi-related functions in various
arch subdirectories, comparing x86 to other arches, and noticed
that code that would restore msi state seems to be missing for
most arches and most powerpc platforms.
--linas
^ permalink raw reply
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: David Miller @ 2007-10-23 0:23 UTC (permalink / raw)
To: linas; +Cc: netdev, mcarlson, linuxppc-dev, mchan, linux-pci
In-Reply-To: <20071022195451.GE4280@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Mon, 22 Oct 2007 14:54:52 -0500
> As discussed in the other thread, I'll try to set up a patch
> for an arch callback for restoring msi state.
Thank you.
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Benjamin Herrenschmidt @ 2007-10-23 0:29 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci,
David Miller
In-Reply-To: <20071023001307.GF4280@austin.ibm.com>
> > I don't know why you keep talking about powerpc laptops here ...
>
> Well, there are Apple laptops, right? Aren't those the "powermac"
> platform? Now, I don't know if they support MSI, but if they do,
> I get the impression that they might not restore msi state correctly,
> after being put into hardware suspend. But perhaps I'm mistaken;
> I was simply grepping for various msi-related functions in various
> arch subdirectories, comparing x86 to other arches, and noticed
> that code that would restore msi state seems to be missing for
> most arches and most powerpc platforms.
Ah ok, i see. Well, platforms that use write_msi_msg() shouldn't need
anything special right ? So only pSeries is an issue here....
PowerBooks don't indeed have MSI support, though G5's do and some people
have been toying around with suspend/resume on them (hibernation only at
that stage) but it doesn't matter at this stage. We are specifically
talking about pSeries which is the "special" case here.
Ben.
^ permalink raw reply
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Benjamin Herrenschmidt @ 2007-10-23 0:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, mcarlson, linuxppc-dev, mchan, linux-pci
In-Reply-To: <20071022.172332.112621497.davem@davemloft.net>
On Mon, 2007-10-22 at 17:23 -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Mon, 22 Oct 2007 14:54:52 -0500
>
> > As discussed in the other thread, I'll try to set up a patch
> > for an arch callback for restoring msi state.
>From what it looks like at this stage, pSeries might need to
differenciate restoring MSI state after a device reset (PCI error
recovery) from restoring MSI state after suspend/resume (if we ever
implement that one).
The former apparently require manual saving & restoring of the config
space bits. (Linas, do you have a pointer to the bit of PAPR spec that
specifies that we need to save & restore the MSI message ourselves ?)
For the later (suspend/resume), that will definitely not work, or at
least, will not be enough, especially with something like suspend to
disk, where we'll need to have the firmware reconfigure the MSIs for us
(to make sure, among others, that the interrupt controllers are properly
configured for MSIs etc...).
Ben.
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: David Gibson @ 2007-10-23 0:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IjwWf-0000dJ-45@jdl.com>
On Mon, Oct 22, 2007 at 07:36:57AM -0500, Jon Loeliger wrote:
> So, like, the other day Segher Boessenkool mumbled:
> > > Property names have been limited to start with
> > > characters from the set [a-zA-Z,._#?]. That is, the
> > > digits and the expression symbols have been removed.
> >
> > This cannot work; many property names start with a digit,
> > for example.
>
> Are any of those property names in use in any
> of our DTS files or b-w-o.txt? Not really, no.
> In fact, with this lexical change, all of our
> DTS files still produce byte-identical results.
>
> I really think this is one of those areas where
> we may need to stray from the other guideline.
>
> Is there a compelling reason somewhere? Really?
We may have deprecated te '64-bit' and '32-64-bridge' properties in
cpu nodes for the flattened tree, but it already exists in a great
number of Apple and IBM trees. It would be poor form for dtc to choke
on these trees.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: David Gibson @ 2007-10-23 0:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20071022115511.0b902044@weaponx.rchland.ibm.com>
On Mon, Oct 22, 2007 at 11:55:11AM -0500, Josh Boyer wrote:
> On Mon, 22 Oct 2007 11:50:52 -0500
> Jon Loeliger <jdl@jdl.com> wrote:
>
> > So, like, the other day David Gibson mumbled:
> > > On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote:
> > > > David Gibson <david@gibson.dropbear.id.au> writes:
> > > >
> > > > > What compiler/platform is this? I can't off the top of my head think
> > > > > of one where size_t shouldn't be promoted to int automatically.
> > > >
> > > > Only types narrower than int are subject to integer promotion.
> > >
> > > Duh, yes. Sorry.
> >
> > So, Hmm. You want the patch as I wrote it applied?
> > Or do you want to use %z in the format instead? It does
> > seem like there is precedent to do that (in the kernel):
> >
> > % grep -r '%z' arch/
> > arch/alpha/boot/tools/mkbb.c: fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
> > arch/alpha/boot/tools/mkbb.c: fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
> > arch/m68k/ifpsp060/src/itest.S: mulu.l (0x00.w,%a3,%za4.l*8),%d2:%d3
> > arch/m68k/ifpsp060/src/itest.S: mulu.l (-0x10.w,%za3,%a4.l*1),%d2:%d3
> > arch/m68k/ifpsp060/src/itest.S: mulu.l (ea_77_mem+0x00.w,%pc,%za4.l*8),%d2:%d3
> > ...
> > arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc,%zd4.l*1]),%d2:%d3
> > arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%pc],%zd4.l*8,0x20.l),%d2:%d3
> > arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc],%d4.l*8),%d2:%d3
> > arch/um/drivers/cow_user.c: /* Below, %zd is for a size_t value */
> > arch/um/drivers/cow_user.c: "limited to %zd characters\n", backing_file,
> > arch/x86/kernel/pci-nommu_64.c: "nommu_%s: overflow %Lx+%zu of device mask %Lx\n",
> >
> > Opinions?
>
> %z is fairly common now-a-days. The kernel janitors tend to LART
> people for not using it rather quickly.
Yes, I think %z is preferable. It used to be a glibc (et al)
extension, but I think it's now specified in C99 (we should double
check that).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] DTC: Minor grammar rule shuffle.
From: David Gibson @ 2007-10-23 0:35 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Ik5JJ-0000Cp-KT@jdl.com>
On Mon, Oct 22, 2007 at 04:59:45PM -0500, Jon Loeliger wrote:
> I like to see the basis cases established early in
> the rule sets, so place "empty" reduction first.
> Purely cosmetic.
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
As with the change of { } formatting, I don't really care much either
way on this one. So
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] DTC: Remove an unneeded %token definition.
From: David Gibson @ 2007-10-23 0:37 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Ik5K6-0000EE-DL@jdl.com>
On Mon, Oct 22, 2007 at 05:00:34PM -0500, Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Oops. Can't even remeber what that one was ever there for.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] DTC: Rewrite the propdata and propdataprefix rules.
From: David Gibson @ 2007-10-23 0:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Ik5uH-0000bV-6C@jdl.com>
On Mon, Oct 22, 2007 at 05:37:57PM -0500, Jon Loeliger wrote:
> So, like, the other day Jon Loeliger mumbled:
> >
> > After staring at these two rules for a bit, and not quite
> > groking them, I rewrote them into something I think is a
> > bit clearer. With any luck, it's the same language still.
> >
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> > ---
> >
> > You be the judge too!
>
> Yeah, so, I botched this one. It's NOT the same
> language, so don't apply it or think about it at all...
Yeah, I remember finding the whole propdataprefix confusing myself.
But the form was suggested by someone (forgotten whom now), and I
never did figure out a better way of doing it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: Segher Boessenkool @ 2007-10-23 0:57 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20071023003309.GE31839@localhost.localdomain>
>>>> Property names have been limited to start with
>>>> characters from the set [a-zA-Z,._#?]. That is, the
>>>> digits and the expression symbols have been removed.
>>>
>>> This cannot work; many property names start with a digit,
>>> for example.
>>
>> Are any of those property names in use in any
>> of our DTS files or b-w-o.txt? Not really, no.
>> In fact, with this lexical change, all of our
>> DTS files still produce byte-identical results.
>>
>> I really think this is one of those areas where
>> we may need to stray from the other guideline.
>>
>> Is there a compelling reason somewhere? Really?
>
> We may have deprecated te '64-bit' and '32-64-bridge' properties in
> cpu nodes for the flattened tree, but it already exists in a great
> number of Apple and IBM trees.
Huh? "64-bit" isn't deprecated I hope, just the "32-bit" thing
(that never was defined) is.
> It would be poor form for dtc to choke on these trees.
Yah. Small incompatibilities add up :-(
Segher
^ permalink raw reply
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: Segher Boessenkool @ 2007-10-23 1:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20071023002631.GB31839@localhost.localdomain>
> Yes, I think %z is preferable. It used to be a glibc (et al)
> extension, but I think it's now specified in C99 (we should double
> check that).
It is.
Segher
^ permalink raw reply
* Audio codec device tree entries
From: Jon Smirl @ 2007-10-23 1:59 UTC (permalink / raw)
To: PowerPC dev list
Is this what the device tree entries should look like?
First example is ac97 audio:
ac97@2000 { // PSC1
device_type = "sound";
compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
cell-index = <0>;
reg = <2000 100>;
interrupts = <2 1 0>;
interrupt-parent = <&mpc5200_pic>;
codec-handle = <&codec0>
};
pseudo-sound@0 { // use to trigger loading platform specific fabric driver
device_type = "pseudo-sound"
};
codec0:codec@0 {
device_type = "codec"
compatible = "stac9766\0ac97"
};
Second is i2s/i2c connected:
How do I link this to the i2c bus?
i2s@2000 { // PSC1
device_type = "sound";
compatible = "mpc5200b-psc-i2s\0mpc5200-psc-i2s";
cell-index = <0>;
reg = <2000 100>;
interrupts = <2 1 0>;
interrupt-parent = <&mpc5200_pic>;
codec-handle = <&codec0>
};
i2c@3d00 {
device_type = "i2c";
compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
};
pseudo-sound@0 { // use to trigger loading platform specific fabric driver
device_type = "pseudo-sound"
};
codec0:codec@0 {
device_type = "codec"
compatible = "tas5508"
};
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Allow sysfs_remove_group() to be called on non-added groups
From: Michael Ellerman @ 2007-10-23 2:02 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <096fae99bd9797c5484ed8f4b87b82e58737cdc0.1189657514.git.michael@ellerman.id.au>
On 9/13/07, Michael Ellerman <michael@ellerman.id.au> wrote:
> It would be nice to be able to do:
>
> for_each_thing(thing) {
> error = sysfs_create_group(&thing->kobj, attrs);
> if (error) {
> for_each_thing(thing)
> sysfs_remove_group(&thing->kobj, attrs);
> return error;
> }
> }
>
> But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
> were never added.
>
> As discussed here ...
> http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
>
> .. we should just return in that case instead of BUG'ing.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> fs/sysfs/group.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index f318b73..a256775 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
>
> if (grp->name) {
> sd = sysfs_get_dirent(dir_sd, grp->name);
> - BUG_ON(!sd);
> + if (!sd)
> + return;
> } else
> sd = sysfs_get(dir_sd);
>
>
Hi Greg,
I didn't see this in your series, any objections? AFAICT it still applies.
cheers
^ permalink raw reply
* Re: [PATCH] DTC: Remove the need for the GLR Parser.
From: David Gibson @ 2007-10-23 2:54 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Ik4aw-0007ud-Lu@jdl.com>
On Mon, Oct 22, 2007 at 04:13:54PM -0500, Jon Loeliger wrote:
> Previously, there were a few shift/reduce and reduce/reduce
> errors in the grammar that were being handled by the not-so-popular
> GLR Parser technique.
I haven't actually heard anyone whinge about glr-parser...
> Flip a right-recursive stack-abusing rule into a left-recursive
> stack-friendly rule and clear up three messes in one shot: No more
> conflicts, no need for the GLR parser, and friendlier stackness.
Ouch. I'm feeling a bit stupid now, I really thought our conflicts
were somewhere else. Specifically I thought the problem was that we
needed to look ahead more tokens that we were able to differentiate
between property and subnode definitions, i.e. between:
label propname =
and
label propname {
Except... I'm almost certain the conflicts first appeared when I added
labels, and I can't see how that would affect this. Well, colour me
baffled.
Especially since the comments and content of commit
4102d840d993e7cce7d5c5aea8ef696dc81236fc (second commit in the entire
history!) appear to back up my memory of this. I used to have a
lookahead hack in the lexer to remove the conflict.
But this patch certainly seems to make the conflicts go away, so I'm
confused.
Well, regardless of that, I have a few concerns.
First, a trivial one: I remember leaving this as a right-recursion,
despite the stack-nastiness, because that way the properties end up in
the same order as in the source. I think that behaviour is worth
preserving, but of course we can do it with left-recursion by changing
chain_property() to add to the end of the list instead of the
beginning. Also, if we're going to avoid right-recursion here, we
should do so for the 'subnodes' productions as well, which is
completely analogous.
More significantly, I don't know that we want to burn our bridges with
glr-parser. glr-parser is a beautiful algorithm which means we can
use essentially whatever form of grammar is the easiest to work with
without having to fiddle about to ensure it's LALR(1). This could
still be useful if we encounter some less easily finessable grammar
construct in future.
And even without glr-parser, I'm still uncomfortable with the
lexer<->parser execution ordering issues with the current
/dts-version/ proposal. It may now be true that the order is
guaranteed to be correct, but it's still not exactly obvious.
It seems to me that the version change introduces a lexical change to
the input format, and should therefore be handled at the lexical
level. And I think there are other potential advantages to parsing
the version identifier as a token, rather than as an integer (such as
being able to define entirely different grammars for different
versions, if we have to).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Audio codec device tree entries
From: David Gibson @ 2007-10-23 2:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710221859q6ea54810nba58907d5ddd966d@mail.gmail.com>
On Mon, Oct 22, 2007 at 09:59:00PM -0400, Jon Smirl wrote:
> Is this what the device tree entries should look like?
>
> First example is ac97 audio:
>
> ac97@2000 { // PSC1
> device_type = "sound";
Kill all these device_type values.
> compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
dtc now supports the more readable:
compatible = "mpc5200b-psc-ac97", "mpc5200-psc-ac97";
Use it.
> cell-index = <0>;
cell-index should only be present if the device is within a
system-on-chip *and* that device number is used to program some global
register somewhere.
> reg = <2000 100>;
> interrupts = <2 1 0>;
> interrupt-parent = <&mpc5200_pic>;
> codec-handle = <&codec0>
> };
>
> pseudo-sound@0 { // use to trigger loading platform specific fabric driver
> device_type = "pseudo-sound"
> };
This looks completely bogus. The device tree should represent actual
hardware.
> codec0:codec@0 {
Space after the : please.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: libfdt: Make fdt_string() return a const pointer
From: David Gibson @ 2007-10-23 3:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Ik0Hf-0002ws-2r@jdl.com>
On Mon, Oct 22, 2007 at 11:37:43AM -0500, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > Currently, fdt_string() returns a (non-const) char *, despite taking a
> > const void *fdt. This is inconsistent with all the other read-only
> > functions which all return const pointers into the blob.
> >
> > This patch fixes that.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
But apparently not pushed out to the public tree...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
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