* Re: [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: David Gibson @ 2007-10-17 0:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071016213107.14117.3858.stgit@trillian.cg.shawcable.net>
On Tue, Oct 16, 2007 at 03:31:07PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Add the 'set -e' command to the wrapper script so that if any command
> fails then the script will automatically exit
Ah.. this will conflict with my patch to merge dtc (because that
touches the line invoking dtc to change the path to 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: DTC Updates
From: David Gibson @ 2007-10-17 0:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IhmXN-0003CC-39@jdl.com>
On Tue, Oct 16, 2007 at 08:32:45AM -0500, Jon Loeliger wrote:
>
> Guys and Dolls,
>
> I pushed out all of David's recent DTC and libfdt patches.
> I also jammed the following patch into the mix as well.
>
> HTH,
> jdl
>
>
>
> commit 9e32930ebcacfcf7cb7c1c2b8e776eb3957cf6cb
> Author: Jon Loeliger <jdl@freescale.com>
> Date: Tue Oct 16 07:35:38 2007 -0500
>
> Restore warning message about bison expected output.
Heh, the removal was kind of deliberate, since I didn't think it was
actually all that much use. But I don't really care much one way or
the other.
I really wish bison would suppress these warnings in glr-parser mode.
>
> It was dropped in ad9593f229362782b953da4b805df713e8468df0.
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> diff --git a/Makefile b/Makefile
> index 84f0efe..d7d1af5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -207,6 +207,7 @@ 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:
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: David Gibson @ 2007-10-17 0:37 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20071016211939.250c2da4@hyperion.delvare>
On Tue, Oct 16, 2007 at 09:19:39PM +0200, Jean Delvare wrote:
> On Mon, 15 Oct 2007 22:21:38 -0600, Grant Likely wrote:
> > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > In fact I think it may be acceptle to do the idx++ thing in this
> > > situation. Bus numbers are ugly, but it's not the worst ugliness in
> > > the horrible mess that is the Linux i2c subsystem. It means that bus
> > > numbers are theoretically unstable, but that's increasingly true of
> > > devices of all sorts - it's up to udev to assign meaningful labels at
> > > the user level.
>
> David, after such a rant against the Linux i2c subsystem, I sure hope
> that you're going to contribute patches to make it better (whatever you
> think needs to be improved, as you didn't say.)
I've frequently contemplated it. In the unlikely event that it ever
bubbles to the top of my priorities, I might well.
> > I think the real problem here comes into play when there are 2 types
> > of i2c busses in the system. If they both maintain their own idx++
> > values; then they will conflict. If an auto assigned bus number is
> > used; then it needs to be assigned by the i2c infrastructure; not by
> > the driver.
>
> Very true. If you aren't going to define the i2c bus numbers at
> platform data level, then you shouldn't be defining them _at all_.
> Don't use i2c_add_numbered_adapter, use i2c_add_adapter and let
> i2c-core choose an appropriate a bus number.
--
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] net: Fix new EMAC driver for NAPI changes
From: Jeff Garzik @ 2007-10-17 1:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, netdev, Roland Dreier, David S. Miller,
shemminger
In-Reply-To: <1192513250.19073.10.camel@pasglop>
Benjamin Herrenschmidt wrote:
> net: Fix new EMAC driver for NAPI changes
>
> This fixes the new EMAC driver for the NAPI updates. The previous patch
> by Roland Dreier (already applied) to do that doesn't actually work. This
> applies on top of it makes it work on my test Ebony machine.
>
> This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
> posted previously.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> The old EMAC driver does things a bit differently (doesn't do useful
> locking :-) and seems to work with Roland patch. So I'm not going to
> touch it unless somebody reports me that it has problems
applied
^ permalink raw reply
* dtc: Restore missing code for testcases
From: David Gibson @ 2007-10-17 1:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Recent commits 333542fabf8720b881e992a5abca32ef4bcb841a and
fd1bf3a5ae46962528ef89a824261a88830758a2 added new testcases to dtc.
However, although the testcases were added to the Makefile and
run_tests.sh, one of the .c files for the testcase was omitted from
the patch in each case.
This patch restores the missing testcase code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Oops, I suck. Screwed up my quilting, somehow. jdl, you should
really run a "make check" before committing my patches...
Index: dtc/tests/get_mem_rsv.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/get_mem_rsv.c 2007-10-17 11:19:06.000000000 +1000
@@ -0,0 +1,49 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_get_mem_rsv() and fdt_num_mem_rsv()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int rc;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ rc = fdt_num_mem_rsv(fdt);
+ if (rc < 0)
+ FAIL("fdt_num_mem_rsv(): %s", fdt_strerror(rc));
+ if (rc != 2)
+ FAIL("fdt_num_mem_rsv() returned %d instead of 2", rc);
+
+ check_mem_rsv(fdt, 0, TEST_ADDR_1, TEST_SIZE_1);
+ check_mem_rsv(fdt, 1, TEST_ADDR_2, TEST_SIZE_2);
+ PASS();
+}
Index: dtc/tests/node_check_compatible.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/node_check_compatible.c 2007-10-17 11:19:32.000000000 +1000
@@ -0,0 +1,62 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_node_check_compatible()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_compatible(const void *fdt, const char *path, const char *compat)
+{
+ int offset, err;
+
+ offset = fdt_path_offset(fdt, path);
+ if (offset < 0)
+ FAIL("fdt_path_offset(%s): %s", path, fdt_strerror(offset));
+
+ err = fdt_node_check_compatible(fdt, offset, compat);
+ if (err < 0)
+ FAIL("fdt_node_check_compatible(%s): %s", path,
+ fdt_strerror(err));
+ if (err != 0)
+ FAIL("%s is not compatible with \"%s\"", path, compat);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_compatible(fdt, "/", "test_tree1");
+ check_compatible(fdt, "/subnode@1/subsubnode", "subsubnode1");
+ check_compatible(fdt, "/subnode@1/subsubnode", "subsubnode");
+ check_compatible(fdt, "/subnode@2/subsubnode", "subsubnode2");
+ check_compatible(fdt, "/subnode@2/subsubnode", "subsubnode");
+
+ PASS();
+}
--
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] net: Fix new EMAC driver for NAPI changes
From: Benjamin Herrenschmidt @ 2007-10-17 1:46 UTC (permalink / raw)
To: Jeff Garzik
Cc: linuxppc-dev list, netdev, Roland Dreier, David S. Miller,
shemminger
In-Reply-To: <47156258.5010800@garzik.org>
On Tue, 2007-10-16 at 21:16 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > net: Fix new EMAC driver for NAPI changes
> >
> > This fixes the new EMAC driver for the NAPI updates. The previous patch
> > by Roland Dreier (already applied) to do that doesn't actually work. This
> > applies on top of it makes it work on my test Ebony machine.
> >
> > This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
> > posted previously.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > The old EMAC driver does things a bit differently (doesn't do useful
> > locking :-) and seems to work with Roland patch. So I'm not going to
> > touch it unless somebody reports me that it has problems
>
> applied
Beware that the depend patch for __napi_synchronize() is still being
discussed :-)
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Josh Boyer @ 2007-10-17 1:49 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071016232404.5F4D51130091@mail133-blu.bigfish.com>
On Tue, 2007-10-16 at 16:23 -0700, Stephen Neuendorffer wrote:
> It occurs to me that the 'compatible' bindings should probably be the
> name of the preferred driver for the device.
>
> > + l) Xilinx ML300 Framebuffer
> > + - compatible : Must include "xilinx,ml300-fb"
> Should probably be 'xilinxfb', and probably shouldn't reference ML300 at
> all.
>
> > + n) Xilinx EMAC and Xilinx TEMAC
> > +
> > + Xilinx Ethernet devices. Uses common properties from
> > other Ethernet
> > + devices with the following constraints:
> > +
> > + Required properties:
> > + - compatible : Must include one of: "xilinx,plb-temac",
> > + "xilinx,plb-emac", "xilinx-opb-emac"
> Should probably be just 'emac' and 'temac'.
You mean xilinx,emac and xilinx,temac, right? emac and temac are too
generic by themselves.
josh
^ permalink raw reply
* Re: [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: Grant Likely @ 2007-10-17 2:10 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, paulus, Scott Wood
In-Reply-To: <20071017003331.GA28260@localhost.localdomain>
On 10/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Oct 16, 2007 at 03:31:07PM -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Add the 'set -e' command to the wrapper script so that if any command
> > fails then the script will automatically exit
>
> Ah.. this will conflict with my patch to merge dtc (because that
> touches the line invoking dtc to change the path to it).
No worries; I can respin this one easily after the dtc stuff is sorted out.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 2:31 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071016232404.5F4D51130091@mail133-blu.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> It occurs to me that the 'compatible' bindings should probably be the
> name of the preferred driver for the device.
>
> > + l) Xilinx ML300 Framebuffer
> > + - compatible : Must include "xilinx,ml300-fb"
> Should probably be 'xilinxfb', and probably shouldn't reference ML300 at
> all.
Actually, I don't think xilinx,ml300-fb is not specific enough (as
opposed to not general enough). Given that the device tree is
supposed to describe the hardware as uniquely as possible, compatible
should probably contain a value like "xilinx,plb-tft-cntlr-ref-1.00.c"
(<vendor>,<ip core>,<version>).
A design with a modified fb core might specify:
compatible = "acme,super-tft-1.3","xilinx,plb-tft-cntlr-ref-1.00.c";
Which indicates that it is a different part, but it provides the same
interface as the preexisting plb-tft-cntrl-ref ip core. Similarly, a
newer reference design which uses a new version of the tft core should
specifiy:
compatible =
"xilinx,plb-tft-cntrl-ref-1.00.d","xilinx,plb-tft-cntlr-ref-1.00.c";
That way the exact type of device is specified; but it is *compatible*
with the older device. If the newer device has a greater feature set,
then a driver that can match against the leftmost compatible value can
make use of the extra features.
>
> > + n) Xilinx EMAC and Xilinx TEMAC
> > +
> > + Xilinx Ethernet devices. Uses common properties from
> > other Ethernet
> > + devices with the following constraints:
> > +
> > + Required properties:
> > + - compatible : Must include one of: "xilinx,plb-temac",
> > + "xilinx,plb-emac", "xilinx-opb-emac"
> Should probably be just 'emac' and 'temac'.
Actually; looking at the available ip cores; it should probably be:
"xilinx,opb-ethernet-1.02.a" for an emac driver
"xilinx,plb-temac-3.00.a" for a temac.
We should probably use the exact names of the ip core. Less ambiguity that way.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 2:35 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071017002156.289E2B58056@mail41-cpk.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
>
> > -----Original Message-----
> > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > Behalf Of Grant Likely
> > Sent: Tuesday, October 16, 2007 12:36 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;
> > microblaze-uclinux@itee.uq.edu.au
> > Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
> >
> > On 10/16/07, Stephen Neuendorffer
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >
> > > > + n) Xilinx EMAC and Xilinx TEMAC
> > > > +
> > > > + Xilinx Ethernet devices. Uses common properties from
> > > > other Ethernet
> > > > + devices with the following constraints:
> > > > +
> > > > + Required properties:
> > > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > > == scatter gather)
> > >
> > > I think it's going to be a significant headache to remap
> > things like the
> > > dma-mode from the xilinx configurations to something else, and then
> > > interpret them correctly in the drivers.
> > >
> > > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > > something like:
> > >
> > > Ethernet_MAC {
> > > xilinx,C_DMA_PRESENT = <1>;
> > > ...
> > > }
> > >
> > > (which happens to correspond to "none" above)
> >
> > Ugh. Can't say I'm thrilled about this....
> >
> > But in this case is might be a necessity. The IP core is already
> > parameterized and the best way to describe the device is to use the
> > existing parameter names.
>
> I don't really like it either, expecially after thinking about it more.
> The problem is that a single IP core might correspond to multiple
> logical devices. The parameters actually need to be from the point of
> view of the drivers. That is, they need to be names like in the
> xparameters:
>
> xilinx,DMA_PRESENT = <1>;
Hmm, not bad. It does still get a little harry when one IP core
implements multiple logical devices, but maybe the IP core should
create a node and the logical devices can be sub nodes with the
appropriate properties needed to describe which logical device it is.
>
> In this case, the translation looks simple, but it is currently
> implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
> future, this *could* be simple code, but in the short term, it won't be
> any simpler than having pretty names. Furthermore, the best driver code
> that I can come up with for using this essentially looks like:
>
> static int __devinit xenet_of_probe(struct of_device *ofdev, const
> struct of_device_id *match)
> {
> struct xemac_platform_data pdata_struct;
> struct resource r_irq_struct;
> struct resource r_mem_struct;
>
> struct resource *r_irq = &r_irq_struct; /* Interrupt resources
> */
> struct resource *r_mem = &r_mem_struct; /* IO mem resources */
> struct xemac_platform_data *pdata = &pdata_struct;
> int rc = 0;
>
> printk(KERN_ERR "Device Tree Probing \'%s\'\n",
> ofdev->node->name);
>
> /* Get iospace for the device */
> rc = of_address_to_resource(ofdev->node, 0, r_mem);
> if(rc) {
> dev_warn(&ofdev->dev, "invalid address\n");
> return rc;
> }
>
> /* Get IRQ for the device */
> rc = of_irq_to_resource(ofdev->node, 0, r_irq);
> if(rc == NO_IRQ) {
> dev_warn(&ofdev->dev, "no IRQ found.\n");
> return rc;
> }
>
> pdata_struct.dma_mode = get_u32(ofdev,
> "C_DMA_PRESENT");
> pdata_struct.has_mii = get_u32(ofdev, "C_MII_EXIST");
> pdata_struct.has_cam = get_u32(ofdev, "C_CAM_EXIST");
> pdata_struct.has_err_cnt = get_u32(ofdev,
> "C_ERR_COUNT_EXIST");
> pdata_struct.has_jumbo = get_u32(ofdev,
> "C_JUMBO_EXIST");
> pdata_struct.tx_dre = get_u32(ofdev,
> "C_TX_DRE_TYPE");
> pdata_struct.rx_dre = get_u32(ofdev,
> "C_RX_DRE_TYPE");
> pdata_struct.tx_hw_csum = get_u32(ofdev,
> "C_TX_INCLUDE_CSUM");
> pdata_struct.rx_hw_csum = get_u32(ofdev,
> "C_RX_INCLUDE_CSUM");
> memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
> 6);
>
> return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
> }
>
> Where probe_initialization contains shares code with the platform_device
> version of probe. This means that the string is still translated into
> another name anyway. Anybody have any better ideas for doing this?
That's pretty close to what I've done on the sysace, uartlite and
xilinxfb drivers.
> > I want to be careful though. Parameters can change from one version
> > of an IP core to another. The driver needs to be able to determine
> > what version of the IP core is used so that the parameters make sense.
> > I'm also nervous about adding every possible C_ value to the device
> > node for each xilinx IP-core; that could make the device tree quite
> > large. (on the other hand; maybe that doesn't matter... It is
> > probably a bigger deal for microblaze than powerpc too.).
>
> Using the xparameters set of values could solve this problem, since only
> things that make sense to the driver are actually set.
I've thought about this more since I wrote the above paragraph. The
compatible property was designed to solve that exact problem. We'll
just embed the version in the compatible list.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* dtc: Improve -Odts output
From: David Gibson @ 2007-10-17 2:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch makes improvements to the way properties are printed when
in dtc is producing dts output.
- Characters which need escaping are now properly handled when
printing properties as strings
- The heuristics for what format to use for a property are
improved so that 'compatible' properties will be displayed as
expected.
- escapes.dts is altered to better demonstrate the changes,
and the string_escapes testcase is adjusted accordingly.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2007-10-17 10:27:35.000000000 +1000
+++ dtc/treesource.c 2007-10-17 11:43:18.000000000 +1000
@@ -56,22 +56,31 @@
PROP_BYTES,
};
+int isstring(char c)
+{
+ return (isprint(c)
+ || (c == '\0')
+ || strchr("\a\b\t\n\v\f\r", c));
+}
+
static enum proptype guess_type(struct property *prop)
{
int len = prop->val.len;
char *p = prop->val.val;
- int nnoprint = 0;
+ int nnotstring = 0, nnul = 0;
int i;
if (len == 0)
return PROP_EMPTY;
for (i = 0; i < len; i++) {
- if (! isprint(p[i]))
- nnoprint++;
+ if (! isstring(p[i]))
+ nnotstring++;
+ if (p[i] == '\0')
+ nnul++;
}
- if ((nnoprint == 1) && (p[len-1] == '\0'))
+ if ((p[len-1] == '\0') && (nnotstring == 0) && (nnul < (len-nnul)))
return PROP_STRING;
else if ((len % sizeof(cell_t)) == 0)
return PROP_CELLS;
@@ -79,6 +88,87 @@
return PROP_BYTES;
}
+static void write_propval_string(FILE *f, struct data val)
+{
+ char *str = val.val;
+ int i;
+
+ assert(str[val.len-1] == '\0');
+
+ fprintf(f, " = \"");
+ for (i = 0; i < (val.len-1); i++) {
+ char c = str[i];
+
+ switch (c) {
+ case '\a':
+ fprintf(f, "\\a");
+ break;
+ case '\b':
+ fprintf(f, "\\b");
+ break;
+ case '\t':
+ fprintf(f, "\\t");
+ break;
+ case '\n':
+ fprintf(f, "\\n");
+ break;
+ case '\v':
+ fprintf(f, "\\v");
+ break;
+ case '\f':
+ fprintf(f, "\\f");
+ break;
+ case '\r':
+ fprintf(f, "\\r");
+ break;
+ case '\\':
+ fprintf(f, "\\\\");
+ break;
+ case '\"':
+ fprintf(f, "\\\"");
+ break;
+ case '\0':
+ fprintf(f, "\", \"");
+ break;
+ default:
+ if (isprint(c))
+ fprintf(f, "%c", c);
+ else
+ fprintf(f, "\\x%02hhx", c);
+ }
+ }
+ fprintf(f, "\";\n");
+}
+
+static void write_propval_cells(FILE *f, struct data val)
+{
+ void *propend = val.val + val.len;
+ cell_t *cp = (cell_t *)val.val;
+
+ fprintf(f, " = <");
+ for (;;) {
+ fprintf(f, "%x", be32_to_cpu(*cp++));
+ if ((void *)cp >= propend)
+ break;
+ fprintf(f, " ");
+ }
+ fprintf(f, ">;\n");
+}
+
+static void write_propval_bytes(FILE *f, struct data val)
+{
+ void *propend = val.val + val.len;
+ char *bp = val.val;
+
+ fprintf(f, " = [");
+ for (;;) {
+ fprintf(f, "%02hhx", *bp++);
+ if ((void *)bp >= propend)
+ break;
+ fprintf(f, " ");
+ }
+ fprintf(f, "];\n");
+}
static void write_tree_source_node(FILE *f, struct node *tree, int level)
{
@@ -92,15 +182,11 @@
fprintf(f, "/ {\n");
for_each_property(tree, prop) {
- cell_t *cp;
- char *bp;
- void *propend;
enum proptype type;
write_prefix(f, level);
fprintf(f, "\t%s", prop->name);
type = guess_type(prop);
- propend = prop->val.val + prop->val.len;
switch (type) {
case PROP_EMPTY:
@@ -108,31 +194,15 @@
break;
case PROP_STRING:
- fprintf(f, " = \"%s\";\n", (char *)prop->val.val);
+ write_propval_string(f, prop->val);
break;
case PROP_CELLS:
- fprintf(f, " = <");
- cp = (cell_t *)prop->val.val;
- for (;;) {
- fprintf(f, "%x", be32_to_cpu(*cp++));
- if ((void *)cp >= propend)
- break;
- fprintf(f, " ");
- }
- fprintf(f, ">;\n");
+ write_propval_cells(f, prop->val);
break;
case PROP_BYTES:
- fprintf(f, " = [");
- bp = prop->val.val;
- for (;;) {
- fprintf(f, "%02hhx", *bp++);
- if ((void *)bp >= propend)
- break;
- fprintf(f, " ");
- }
- fprintf(f, "];\n");
+ write_propval_bytes(f, prop->val);
break;
}
}
Index: dtc/tests/escapes.dts
===================================================================
--- dtc.orig/tests/escapes.dts 2007-10-17 11:36:37.000000000 +1000
+++ dtc/tests/escapes.dts 2007-10-17 12:32:27.000000000 +1000
@@ -1,4 +1,5 @@
/ {
compatible = "test_string_escapes";
- escape-str = "nastystring: \a\b\t\n\v\f\r\\\"\xff";
+ escape-str = "nastystring: \a\b\t\n\v\f\r\\\"";
+ escape-str-2 = "\xde\xad\xbe\xef";
};
Index: dtc/tests/string_escapes.c
===================================================================
--- dtc.orig/tests/string_escapes.c 2007-10-17 12:31:56.000000000 +1000
+++ dtc/tests/string_escapes.c 2007-10-17 12:32:04.000000000 +1000
@@ -37,6 +37,8 @@
check_getprop(fdt, 0, "escape-str",
strlen(TEST_STRING_2)+1, TEST_STRING_2);
+ check_getprop(fdt, 0, "escape-str-2",
+ strlen(TEST_STRING_3)+1, TEST_STRING_3);
PASS();
}
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2007-10-17 12:28:50.000000000 +1000
+++ dtc/tests/testdata.h 2007-10-17 12:31:45.000000000 +1000
@@ -24,7 +24,8 @@
#define TEST_VALUE_2 cell_to_fdt(0xabcd1234)
#define TEST_STRING_1 "hello world"
-#define TEST_STRING_2 "nastystring: \a\b\t\n\v\f\r\\\"\xff"
+#define TEST_STRING_2 "nastystring: \a\b\t\n\v\f\r\\\""
+#define TEST_STRING_3 "\xde\xad\xbe\xef"
#ifndef __ASSEMBLY__
extern struct fdt_header _test_tree1;
--
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/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 2:50 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
In-Reply-To: <20071016115318.0fc36af3@freepuppy.rosehill>
napi: use non-interruptible sleep in napi_disable
The current napi_disable() uses msleep_interruptible() but doesn't
(and can't) exit in case there's a signal, thus ending up doing a
hot spin without a cpu_relax. Use uninterruptible sleep instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:16.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-17 12:45:00.000000000 +1000
@@ -390,7 +390,7 @@ static inline void napi_complete(struct
static inline void napi_disable(struct napi_struct *n)
{
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
- msleep_interruptible(1);
+ msleep(1);
}
/**
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 2:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
In-Reply-To: <20071016115318.0fc36af3@freepuppy.rosehill>
net: Add __napi_synchronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Switched to do a cpu_relax() spin instead and only on SMP. Not that
we have an smp_mb() in there which synchronize_irq() lacks. I believe
this is a bug in synchronize_irq() which I'll handle separately.
Note: unfortunately, Jeff already picked up the EMAC patch without
waiting for this to be sorted out (oops...). So if you agree with
this patch, it would be nice to have it go in quickly or maybe via
Jeff's tree to avoid breakage ? Not terribly important tho.
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:40.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-17 12:40:59.000000000 +1000
@@ -394,6 +394,23 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+#ifdef CONFIG_SMP
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ cpu_relax();
+#endif /* CONFIG_SMP */
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 3:03 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <fa686aa40710161935p2aef36efx6154071b0055698f@mail.gmail.com>
On 10/16/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > > Behalf Of Grant Likely
> > > Sent: Tuesday, October 16, 2007 12:36 PM
> > > To: Stephen Neuendorffer
> > > Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;
> > > microblaze-uclinux@itee.uq.edu.au
> > > Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
> > >
> > > On 10/16/07, Stephen Neuendorffer
> > > <stephen.neuendorffer@xilinx.com> wrote:
> > > >
> > > > > + n) Xilinx EMAC and Xilinx TEMAC
> > > > > +
> > > > > + Xilinx Ethernet devices. Uses common properties from
> > > > > other Ethernet
> > > > > + devices with the following constraints:
> > > > > +
> > > > > + Required properties:
> > > > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > > > == scatter gather)
> > > >
> > > > I think it's going to be a significant headache to remap
> > > things like the
> > > > dma-mode from the xilinx configurations to something else, and then
> > > > interpret them correctly in the drivers.
> > > >
> > > > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > > > something like:
> > > >
> > > > Ethernet_MAC {
> > > > xilinx,C_DMA_PRESENT = <1>;
> > > > ...
> > > > }
> > > >
> > > > (which happens to correspond to "none" above)
> > >
> > > Ugh. Can't say I'm thrilled about this....
> > >
> > > But in this case is might be a necessity. The IP core is already
> > > parameterized and the best way to describe the device is to use the
> > > existing parameter names.
> >
> > I don't really like it either, expecially after thinking about it more.
> > The problem is that a single IP core might correspond to multiple
> > logical devices. The parameters actually need to be from the point of
> > view of the drivers. That is, they need to be names like in the
> > xparameters:
> >
> > xilinx,DMA_PRESENT = <1>;
>
> Hmm, not bad. It does still get a little harry when one IP core
> implements multiple logical devices, but maybe the IP core should
> create a node and the logical devices can be sub nodes with the
> appropriate properties needed to describe which logical device it is.
>
> >
> > In this case, the translation looks simple, but it is currently
> > implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
> > future, this *could* be simple code, but in the short term, it won't be
> > any simpler than having pretty names. Furthermore, the best driver code
> > that I can come up with for using this essentially looks like:
> >
> > static int __devinit xenet_of_probe(struct of_device *ofdev, const
> > struct of_device_id *match)
> > {
> > struct xemac_platform_data pdata_struct;
> > struct resource r_irq_struct;
> > struct resource r_mem_struct;
> >
> > struct resource *r_irq = &r_irq_struct; /* Interrupt resources
> > */
> > struct resource *r_mem = &r_mem_struct; /* IO mem resources */
> > struct xemac_platform_data *pdata = &pdata_struct;
> > int rc = 0;
> >
> > printk(KERN_ERR "Device Tree Probing \'%s\'\n",
> > ofdev->node->name);
> >
> > /* Get iospace for the device */
> > rc = of_address_to_resource(ofdev->node, 0, r_mem);
> > if(rc) {
> > dev_warn(&ofdev->dev, "invalid address\n");
> > return rc;
> > }
> >
> > /* Get IRQ for the device */
> > rc = of_irq_to_resource(ofdev->node, 0, r_irq);
> > if(rc == NO_IRQ) {
> > dev_warn(&ofdev->dev, "no IRQ found.\n");
> > return rc;
> > }
> >
> > pdata_struct.dma_mode = get_u32(ofdev,
> > "C_DMA_PRESENT");
> > pdata_struct.has_mii = get_u32(ofdev, "C_MII_EXIST");
> > pdata_struct.has_cam = get_u32(ofdev, "C_CAM_EXIST");
> > pdata_struct.has_err_cnt = get_u32(ofdev,
> > "C_ERR_COUNT_EXIST");
> > pdata_struct.has_jumbo = get_u32(ofdev,
> > "C_JUMBO_EXIST");
> > pdata_struct.tx_dre = get_u32(ofdev,
> > "C_TX_DRE_TYPE");
> > pdata_struct.rx_dre = get_u32(ofdev,
> > "C_RX_DRE_TYPE");
> > pdata_struct.tx_hw_csum = get_u32(ofdev,
> > "C_TX_INCLUDE_CSUM");
> > pdata_struct.rx_hw_csum = get_u32(ofdev,
> > "C_RX_INCLUDE_CSUM");
> > memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
> > 6);
> >
> > return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
> > }
> >
> > Where probe_initialization contains shares code with the platform_device
> > version of probe. This means that the string is still translated into
> > another name anyway. Anybody have any better ideas for doing this?
>
> That's pretty close to what I've done on the sysace, uartlite and
> xilinxfb drivers.
>
> > > I want to be careful though. Parameters can change from one version
> > > of an IP core to another. The driver needs to be able to determine
> > > what version of the IP core is used so that the parameters make sense.
> > > I'm also nervous about adding every possible C_ value to the device
> > > node for each xilinx IP-core; that could make the device tree quite
> > > large. (on the other hand; maybe that doesn't matter... It is
> > > probably a bigger deal for microblaze than powerpc too.).
> >
> > Using the xparameters set of values could solve this problem, since only
> > things that make sense to the driver are actually set.
>
> I've thought about this more since I wrote the above paragraph. The
> compatible property was designed to solve that exact problem. We'll
> just embed the version in the compatible list.
And, yes, you're right. Using the xparams value set is probably the
place to start for choosing which properties to put in the device
tree. I'll document this stuff up and respin my patch.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Dan Malek @ 2007-10-17 2:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <4714E44F.7030909@freescale.com>
On Oct 16, 2007, at 12:18 PM, Scott Wood wrote:
> Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
> think there's any device tree support for 8xx yet,
Have you tried it? Works for me. In fact, most
of the development you see today was done
by Pantelis on the 8xx.
-- Dan
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Jeff Garzik @ 2007-10-17 3:16 UTC (permalink / raw)
To: benh
Cc: netdev, Roland Dreier, Stephen Hemminger, David S. Miller,
linuxppc-dev list
In-Reply-To: <1192589522.11899.130.camel@pasglop>
Benjamin Herrenschmidt wrote:
> net: Add __napi_synchronize() to sync with napi poll
>
> The EMAC driver which needs to handle multiple devices with one
> NAPI instance implements its own per-channel disable bit. However,
> when setting such a bit, it needs to synchronize with the poller
> (that is make sure that any pending poller instance has completed,
> or is started late enough to see that disable bit).
>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Switched to do a cpu_relax() spin instead and only on SMP. Not that
> we have an smp_mb() in there which synchronize_irq() lacks. I believe
> this is a bug in synchronize_irq() which I'll handle separately.
>
> Note: unfortunately, Jeff already picked up the EMAC patch without
> waiting for this to be sorted out (oops...). So if you agree with
> this patch, it would be nice to have it go in quickly or maybe via
> Jeff's tree to avoid breakage ? Not terribly important tho.
Sorry, I thought that was the way everybody was headed. With the driver
broken /anyway/, I just sorta threw it into the pile of fixes.
It's upstream now, so let me know if you want to revert or move forward
from here...
Jeff
^ permalink raw reply
* PPC440EPx GPIO control help
From: Dell Query @ 2007-10-17 3:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Hi,
I am a Linux and PPC newbie.
I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand.
Could anyone show me any tutorial or some sample codes?
Thanks,
Dell
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.
[-- Attachment #2: Type: text/html, Size: 639 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 3:24 UTC (permalink / raw)
To: Jeff Garzik
Cc: netdev, Roland Dreier, Stephen Hemminger, David S. Miller,
linuxppc-dev list
In-Reply-To: <47157EA4.1000500@garzik.org>
\
> > Note: unfortunately, Jeff already picked up the EMAC patch without
> > waiting for this to be sorted out (oops...). So if you agree with
> > this patch, it would be nice to have it go in quickly or maybe via
> > Jeff's tree to avoid breakage ? Not terribly important tho.
>
>
> Sorry, I thought that was the way everybody was headed. With the driver
> broken /anyway/, I just sorta threw it into the pile of fixes.
>
> It's upstream now, so let me know if you want to revert or move forward
> from here...
Let's just move forward. I can always re-fix the driver :-)
Ben.
^ permalink raw reply
* PPC440EPx GPIO control help
From: Dell Query @ 2007-10-17 3:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Hi,
I am a Linux and PPC newbie.
I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand.
Could anyone show me any tutorial or some sample codes?
Thanks,
Dell
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
[-- Attachment #2: Type: text/html, Size: 884 bytes --]
^ permalink raw reply
* [PATCH 1/2] [SPARC/64] Consolidate of_register_driver
From: Stephen Rothwell @ 2007-10-17 3:41 UTC (permalink / raw)
To: David S. Miller; +Cc: sparclinux, ppc-dev, wli
Also of_unregister_driver. These will be shortly also used by the
PowerPC code.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/kernel/of_device.c | 20 --------------------
arch/sparc64/kernel/of_device.c | 20 --------------------
drivers/of/platform.c | 21 +++++++++++++++++++++
include/asm-sparc/of_platform.h | 5 +----
include/asm-sparc64/of_platform.h | 5 +----
include/linux/of_platform.h | 4 ++++
6 files changed, 27 insertions(+), 48 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
index fb2caef..3ea000d 100644
--- a/arch/sparc/kernel/of_device.c
+++ b/arch/sparc/kernel/of_device.c
@@ -585,24 +585,6 @@ static int __init of_debug(char *str)
__setup("of_debug=", of_debug);
-int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
-{
- /* initialize common driver fields */
- if (!drv->driver.name)
- drv->driver.name = drv->name;
- if (!drv->driver.owner)
- drv->driver.owner = drv->owner;
- drv->driver.bus = bus;
-
- /* register with core */
- return driver_register(&drv->driver);
-}
-
-void of_unregister_driver(struct of_platform_driver *drv)
-{
- driver_unregister(&drv->driver);
-}
-
struct of_device* of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
@@ -628,6 +610,4 @@ struct of_device* of_platform_device_create(struct device_node *np,
return dev;
}
-EXPORT_SYMBOL(of_register_driver);
-EXPORT_SYMBOL(of_unregister_driver);
EXPORT_SYMBOL(of_platform_device_create);
diff --git a/arch/sparc64/kernel/of_device.c b/arch/sparc64/kernel/of_device.c
index 42d7798..fc5c0cc 100644
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -869,26 +869,6 @@ static int __init of_debug(char *str)
__setup("of_debug=", of_debug);
-int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
-{
- /* initialize common driver fields */
- if (!drv->driver.name)
- drv->driver.name = drv->name;
- if (!drv->driver.owner)
- drv->driver.owner = drv->owner;
- drv->driver.bus = bus;
-
- /* register with core */
- return driver_register(&drv->driver);
-}
-EXPORT_SYMBOL(of_register_driver);
-
-void of_unregister_driver(struct of_platform_driver *drv)
-{
- driver_unregister(&drv->driver);
-}
-EXPORT_SYMBOL(of_unregister_driver);
-
struct of_device* of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 864f09f..b47bb2d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -12,6 +12,7 @@
*
*/
#include <linux/errno.h>
+#include <linux/module.h>
#include <linux/device.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
@@ -94,3 +95,23 @@ int of_bus_type_init(struct bus_type *bus, const char *name)
bus->resume = of_platform_device_resume;
return bus_register(bus);
}
+
+int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
+{
+ /* initialize common driver fields */
+ if (!drv->driver.name)
+ drv->driver.name = drv->name;
+ if (!drv->driver.owner)
+ drv->driver.owner = drv->owner;
+ drv->driver.bus = bus;
+
+ /* register with core */
+ return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL(of_register_driver);
+
+void of_unregister_driver(struct of_platform_driver *drv)
+{
+ driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL(of_unregister_driver);
diff --git a/include/asm-sparc/of_platform.h b/include/asm-sparc/of_platform.h
index 64a2300..d638737 100644
--- a/include/asm-sparc/of_platform.h
+++ b/include/asm-sparc/of_platform.h
@@ -18,12 +18,9 @@
extern struct bus_type ebus_bus_type;
extern struct bus_type sbus_bus_type;
-extern struct bus_type of_platform_bus_type;
+
#define of_bus_type of_platform_bus_type /* for compatibility */
-extern int of_register_driver(struct of_platform_driver *drv,
- struct bus_type *bus);
-extern void of_unregister_driver(struct of_platform_driver *drv);
extern struct of_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
diff --git a/include/asm-sparc64/of_platform.h b/include/asm-sparc64/of_platform.h
index f7c1f17..f15cfa7 100644
--- a/include/asm-sparc64/of_platform.h
+++ b/include/asm-sparc64/of_platform.h
@@ -19,12 +19,9 @@
extern struct bus_type isa_bus_type;
extern struct bus_type ebus_bus_type;
extern struct bus_type sbus_bus_type;
-extern struct bus_type of_platform_bus_type;
+
#define of_bus_type of_platform_bus_type /* for compatibility */
-extern int of_register_driver(struct of_platform_driver *drv,
- struct bus_type *bus);
-extern void of_unregister_driver(struct of_platform_driver *drv);
extern struct of_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 448f70b..a8efcfe 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -48,6 +48,10 @@ struct of_platform_driver
#define to_of_platform_driver(drv) \
container_of(drv,struct of_platform_driver, driver)
+extern int of_register_driver(struct of_platform_driver *drv,
+ struct bus_type *bus);
+extern void of_unregister_driver(struct of_platform_driver *drv);
+
#include <asm/of_platform.h>
extern struct of_device *of_find_device_by_node(struct device_node *np);
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] Use of_register_driver to implement of_register_platform_driver
From: Stephen Rothwell @ 2007-10-17 3:43 UTC (permalink / raw)
To: paulus; +Cc: sparclinux, ppc-dev, David S. Miller, wli
In-Reply-To: <20071017134123.cfe10b79.sfr@canb.auug.org.au>
Also of_unregister{,_platform}_driver.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/of_platform.c | 20 --------------------
include/asm-powerpc/of_platform.h | 10 ++++++++--
2 files changed, 8 insertions(+), 22 deletions(-)
This depends on the Sparc part (patch 1/2) being in the tree first.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
index eca8ccc..9b01602 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -67,26 +67,6 @@ static int __init of_bus_driver_init(void)
postcore_initcall(of_bus_driver_init);
-int of_register_platform_driver(struct of_platform_driver *drv)
-{
- /* initialize common driver fields */
- if (!drv->driver.name)
- drv->driver.name = drv->name;
- if (!drv->driver.owner)
- drv->driver.owner = drv->owner;
- drv->driver.bus = &of_platform_bus_type;
-
- /* register with core */
- return driver_register(&drv->driver);
-}
-EXPORT_SYMBOL(of_register_platform_driver);
-
-void of_unregister_platform_driver(struct of_platform_driver *drv)
-{
- driver_unregister(&drv->driver);
-}
-EXPORT_SYMBOL(of_unregister_platform_driver);
-
static void of_platform_make_bus_id(struct of_device *dev)
{
struct device_node *node = dev->node;
diff --git a/include/asm-powerpc/of_platform.h b/include/asm-powerpc/of_platform.h
index 80e6fad..d20a4cd 100644
--- a/include/asm-powerpc/of_platform.h
+++ b/include/asm-powerpc/of_platform.h
@@ -15,8 +15,14 @@
#include <linux/of_platform.h>
/* Platform drivers register/unregister */
-extern int of_register_platform_driver(struct of_platform_driver *drv);
-extern void of_unregister_platform_driver(struct of_platform_driver *drv);
+static inline int of_register_platform_driver(struct of_platform_driver *drv)
+{
+ return of_register_driver(drv, &of_platform_bus_type);
+}
+static inline void of_unregister_platform_driver(struct of_platform_driver *drv)
+{
+ of_unregister_driver(drv);
+}
/* Platform devices and busses creation */
extern struct of_device *of_platform_device_create(struct device_node *np,
--
1.5.3.4
^ permalink raw reply related
* Re: Tx Command of MPC8280 hangs the kernel
From: Misbah khan @ 2007-10-17 4:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e5eb93010710111728y6ef1e12che0cec8303c30d64d@mail.gmail.com>
Can u send the part of the code for better understanding
-Misbah
suresh suresh wrote:
>
> Hi,
>
> I am facing kernel hang when ATM Tx command is issued. I am using SUSE
> linux. Does anyone have any idea why it is happening?
>
>
> Regards,
> Suresh
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/Tx-Command-of-MPC8280-hangs-the-kernel-tf4610753.html#a13246766
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: David Hawkins @ 2007-10-17 4:15 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <400754.83957.qm@web45604.mail.sp1.yahoo.com>
Hi Dell,
> I am a Linux and PPC newbie.
Ok.
> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
> What I would want to do is to control (write and read values to) its
> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
> inportb(0x378) to read. I read the PPC440EPx manual but I find it
> difficult to understand.
>
> Could anyone show me any tutorial or some sample codes?
I copied the code below from some test code I wrote for a TS7300
board (uses an ARM EP9302 processor). However, since its user-space
code it should work fine.
Generally for manipulating I/Os you write a custom driver. However,
when getting to know a processor, it sometimes helps to cheat and
just write to registers directly.
The code below uses /dev/mem to map a page or more of the processor
address space into your process. Go find the byte address of your
GPIO registers and pass that as the argument.
Google for /dev/mem and you'll find lots of code that looks more
or less like this. This code just gives you a minimal console so
that you can mess with multiple registers.
BTW, you can really screw yourself if you mess with registers
you shouldn't, eg. memory controller settings etc. So be careful.
From the looks of the code, it provides options for
32-bit access or 8-bit access.
Cheers,
Dave
/*
* mem_debug.c
*
* 5/10/07 D. W. Hawkins (dwh@ovro.caltech.edu)
*
* A debug console for read/write access to /dev/mem mapped
* areas.
*/
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <sys/mman.h>
#include <stdlib.h>
#include <unistd.h>
void display_help();
void change_mem(char *cmd);
void display_mem(char *cmd);
void process_command(char *cmd);
/* Mapped address and size */
static char *mem_addr = NULL;
static unsigned int mem_phys = 0;
static unsigned int mem_pages = 0;
static unsigned int mem_size = 0;
static void show_usage()
{
printf("\nUsage: mem_debug -a <address> -n <pages>\n"\
" -h Help (this message)\n"\
" -a <address> Hex address to start the map\n"\
" -n <pages> Number of pages to map\n\n");
}
int main(int argc, char *argv[])
{
int opt; /* getopt processing */
int fd; /* /dev/mem file descriptor */
char buf[200]; /* command processing buffer */
int len = 200;
int page_size = getpagesize();
int status;
while ((opt = getopt(argc, argv, "a:hn:")) != -1) {
switch (opt) {
case 'a':
status = sscanf(optarg, "%X", &mem_phys);
if (status != 1) {
printf("Parse error for -a option\n");
show_usage();
return -1;
}
break;
case 'h':
show_usage();
return -1;
case 'n':
mem_pages = atoi(optarg);
break;
default:
show_usage();
return -1;
}
}
if (mem_phys != (mem_phys/page_size)*page_size) {
printf("Error: the address must be page-aligned (0x%X)\n",
page_size);
return -1;
}
if (mem_pages == 0) {
mem_pages = 1;
}
mem_size = mem_pages*page_size;
/* Startup */
printf("\n------------------------\n");
printf("/dev/mem debug interface\n");
printf("========================\n\n");
/* Open /dev/mem and map it */
printf(" * open /dev/mem\n");
fd = open("/dev/mem", O_RDWR | O_SYNC);
if (fd < 0) {
printf("Open /dev/mem failed - %s\n",
strerror(errno));
return -1;
}
printf(" * map %d page(s) (%d-bytes) at address 0x%.8X\n",
mem_pages, mem_size, mem_phys);
mem_addr = (char *)mmap(
0,
mem_size,
PROT_READ|PROT_WRITE,
MAP_SHARED,
fd,
mem_phys);
if (mem_addr == (char *)MAP_FAILED) {
printf("Error: mmap failed\n");
close(fd);
return -1;
}
/* Display help */
display_help();
/* Process commands */
while (1) {
printf("CMD> ");
fflush(stdout);
fgets(buf,len,stdin);
process_command(buf);
}
/* Cleanup */
munmap((void *)mem_addr, mem_pages*page_size);
close(fd);
return 0;
}
/*--------------------------------------------------------------------
* User interface
*--------------------------------------------------------------------
*/
void display_help()
{
printf("\n ? Help\n");
printf(" dw addr len Display len words starting from addr\n");
printf(" db addr len Display len bytes starting from addr\n");
printf(" cw addr val Change word at addr to val\n");
printf(" cb addr val Change byte at addr to val\n");
printf(" q Quit\n");
printf("\n Notes:\n");
printf(" * addr, len, and val are interpreted as hex values\n");
printf(" * addresses are always byte based\n");
printf(" * addresses are offsets relative to the base address\n\n");
}
void process_command(char *cmd)
{
if (cmd[0] == '\0') {
return;
}
switch (cmd[0]) {
case '?':
display_help();
break;
case 'd':
case 'D':
display_mem(cmd);
break;
case 'c':
case 'C':
change_mem(cmd);
break;
case 'q':
case 'Q':
exit(0);
default:
break;
}
return;
}
void display_mem(char *cmd)
{
char width = 0;
int addr = 0;
int len = 0;
int status;
int i, data;
/* d, db, dw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &len);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
if (len > mem_size) {
len = mem_size;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
for (i = 0; i < len; i++) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = (int)(mem_addr[addr+i]) & 0xFF;
printf("%.02X ", data);
}
printf("\n");
break;
default:
for (i = 0; i < len; i+=4) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = *(int *)(mem_addr + addr + i);
printf("%.08X ", data);
}
printf("\n");
break;
}
printf("\n");
return;
}
void change_mem(char *cmd)
{
char width = 0;
int addr = 0;
int data = 0;
int status;
/* c, cb, cw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &data);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
mem_addr[addr] = data & 0xFF;
break;
default:
*(int *)(mem_addr + addr) = data;
break;
}
return;
}
^ permalink raw reply
* Re: current -git adbhid.c build error
From: Paul Mackerras @ 2007-10-17 4:19 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linuxppc-dev, Dmitry Torokhov
In-Reply-To: <20071016181644.GA9337@nineveh.local>
Joseph Fannin writes:
> Commit b981d8b3f5e008ff10d993be633ad00564fc22cd in Linus's git tree
> did this:
>
>
> @@ -374,9 +373,9 @@ adbhid_input_keycode(int id, int scancode, int repeat)
> #endif /* CONFIG_PPC_PMAC */
> }
>
> - if (adbhid[id]->keycode[keycode]) {
> - input_report_key(adbhid[id]->input,
> - adbhid[id]->keycode[keycode],
> adbhid[id]->!up_flag);
> + key = adbhid[id]->keycode[keycode];
> + if (key) {
> + input_report_key(adbhid[id]->input, key, !up_flag);
> input_sync(adbhid[id]->input);
> } else
> printk(KERN_INFO "Unhandled ADB key (scancode %#02x)
> %s.\n", keycode,
>
> ... but did not define "key":
It was a mis-merge between 555ddbb4, which made that change and *did*
add the declaration of key, and 9a402b64, which deleted the line that
the declaration of key was added to.
We need the patch below. Dmitry, will you push it or will I?
Paul.
[PATCH] Restore declaration of key in adbhid_input_keycode.
Merge commit b981d8b3f5e008ff10d993be633ad00564fc22cd lost the
declaration of `key' that 555ddbb4e2191c8823df2d61525218ac39481385
added, resulting in failure to compile. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index 8cce016..2766e4f 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -282,7 +282,7 @@ static void
adbhid_input_keycode(int id, int scancode, int repeat)
{
struct adbhid *ahid = adbhid[id];
- int keycode, up_flag;
+ int keycode, up_flag, key;
keycode = scancode & 0x7f;
up_flag = scancode & 0x80;
^ permalink raw reply related
* [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Benjamin Herrenschmidt @ 2007-10-17 4:23 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jakub Jelinek, linuxppc-dev list, Andrew Haley, Alan Modra,
Deepak Bhole
The current DWARF info for CR are incorrect causing the gcc unwinder to
go to lunch if taking a segfault in the vdso. This patch fixes it.
Problem identified by Andrew Haley, and fix provided by Jakub Jelinek
(thanks !).
Unfortunately, a bug in gcc cause it to not quite work either, but that
is being fixed separately with something around the lines of:
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/arch/powerpc/kernel/vdso64/sigtramp.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:32:49.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:34:18.000000000 +1000
@@ -134,13 +134,16 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
9:
/* This is where the pt_regs pointer can be found on the stack. */
-#define PTREGS 128+168+56
+#define PTREGS 128+168+56
/* Size of regs. */
-#define RSIZE 8
+#define RSIZE 8
+
+/* Size of CR reg in DWARF unwind info. */
+#define CRSIZE 4
/* This is the offset of the VMX reg pointer. */
-#define VREGS 48*RSIZE+33*8
+#define VREGS 48*RSIZE+33*8
/* Describe where general purpose regs are saved. */
#define EH_FRAME_GEN \
@@ -178,7 +181,7 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
rsave (31, 31*RSIZE); \
rsave (67, 32*RSIZE); /* ap, used as temp for nip */ \
rsave (65, 36*RSIZE); /* lr */ \
- rsave (70, 38*RSIZE) /* cr */
+ rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) /* cr */
/* Describe where the FP regs are saved. */
#define EH_FRAME_FP \
^ 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