* [PATCH 3/8] Remove unused pte_offset variable
From: Michael Ellerman @ 2008-02-27 7:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4108415683edeb799fd4880a8dba3e9f27a34415.1204097262.git.michael@ellerman.id.au>
The cell IOMMU code no longer needs to save the pte_offset variable
separately, it is incorporated into tbl->it_offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 4e75919..555d264 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -123,7 +123,6 @@ struct iommu_window {
struct cbe_iommu *iommu;
unsigned long offset;
unsigned long size;
- unsigned long pte_offset;
unsigned int ioid;
struct iommu_table table;
};
@@ -475,13 +474,11 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
window->size = size;
window->ioid = ioid;
window->iommu = iommu;
- window->pte_offset = pte_offset;
window->table.it_blocksize = 16;
window->table.it_base = (unsigned long)iommu->ptab;
window->table.it_index = iommu->nid;
- window->table.it_offset = (offset >> IOMMU_PAGE_SHIFT) +
- window->pte_offset;
+ window->table.it_offset = (offset >> IOMMU_PAGE_SHIFT) + pte_offset;
window->table.it_size = size >> IOMMU_PAGE_SHIFT;
iommu_init_table(&window->table, iommu->nid);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/8] Use it_offset not pte_offset in cell IOMMU code
From: Michael Ellerman @ 2008-02-27 7:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4108415683edeb799fd4880a8dba3e9f27a34415.1204097262.git.michael@ellerman.id.au>
The cell IOMMU tce build and free routines use pte_offset to convert
the index passed from the generic IOMMU code into a page table offset.
This takes into account the SPIDER_DMA_OFFSET which sets the top bit
of every DMA address.
However it doesn't cater for the IOMMU window starting at a non-zero
address, as the base of the window is not incorporated into pte_offset
at all.
As it turns out tbl->it_offset already contains the value we need, it
takes into account the base of the window and also pte_offset. So use
it instead!
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index bbe8389..4e75919 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -200,7 +200,7 @@ static void tce_build_cell(struct iommu_table *tbl, long index, long npages,
(window->ioid & IOPTE_IOID_Mask);
#endif
- io_pte = (unsigned long *)tbl->it_base + (index - window->pte_offset);
+ io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
for (i = 0; i < npages; i++, uaddr += IOMMU_PAGE_SIZE)
io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
@@ -232,7 +232,7 @@ static void tce_free_cell(struct iommu_table *tbl, long index, long npages)
| (window->ioid & IOPTE_IOID_Mask);
#endif
- io_pte = (unsigned long *)tbl->it_base + (index - window->pte_offset);
+ io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
for (i = 0; i < npages; i++)
io_pte[i] = pte;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 1/8] Clearup cell IOMMU fixed mapping terminology
From: Michael Ellerman @ 2008-02-27 7:28 UTC (permalink / raw)
To: linuxppc-dev
It's called the fixed mapping, not the static mapping.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index edab631..bbe8389 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -549,7 +549,7 @@ static void cell_dma_dev_setup_iommu(struct device *dev)
archdata->dma_data = &window->table;
}
-static void cell_dma_dev_setup_static(struct device *dev);
+static void cell_dma_dev_setup_fixed(struct device *dev);
static void cell_dma_dev_setup(struct device *dev)
{
@@ -557,7 +557,7 @@ static void cell_dma_dev_setup(struct device *dev)
/* Order is important here, these are not mutually exclusive */
if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
- cell_dma_dev_setup_static(dev);
+ cell_dma_dev_setup_fixed(dev);
else if (get_pci_dma_ops() == &dma_iommu_ops)
cell_dma_dev_setup_iommu(dev);
else if (get_pci_dma_ops() == &dma_direct_ops)
@@ -858,7 +858,7 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
return 0;
}
-static void cell_dma_dev_setup_static(struct device *dev)
+static void cell_dma_dev_setup_fixed(struct device *dev)
{
struct dev_archdata *archdata = &dev->archdata;
u64 addr;
@@ -894,7 +894,7 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
for (i = fbase; i < fbase + fsize; i++, uaddr += IOMMU_PAGE_SIZE) {
/* Don't touch the dynamic region */
if (i >= dbase && i < (dbase + dsize)) {
- pr_debug("iommu: static/dynamic overlap, skipping\n");
+ pr_debug("iommu: fixed/dynamic overlap, skipping\n");
continue;
}
io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* dtc: Implement checks for the format of node and property names
From: David Gibson @ 2008-02-27 2:45 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch adds checks to the checking framework to verify that node
and property names contain only legal characters, and in the case of
node names there is at most one '@'.
At present when coming from dts input, this is mostly already ensured
by the grammer, however putting the check later means its easier to
generate helpful error messages rather than just "syntax error". For
dtb input, these checks replace the older similar check built into
flattree.c.
Testcases for the checks are also implemented.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
checks.c | 37 +++++++++++++++++++++++++++++++++++++
flattree.c | 28 +++++-----------------------
tests/dumptrees.c | 1 +
tests/run_tests.sh | 3 +++
tests/testdata.h | 3 +++
tests/trees.S | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 97 insertions(+), 23 deletions(-)
Index: dtc/checks.c
===================================================================
--- dtc.orig/checks.c 2008-02-27 13:25:08.000000000 +1100
+++ dtc/checks.c 2008-02-27 13:29:05.000000000 +1100
@@ -242,6 +242,42 @@
}
NODE_CHECK(duplicate_property_names, NULL, ERROR);
+#define LOWERCASE "abcdefghijklmnopqrstuvwxyz"
+#define UPPERCASE "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
+#define DIGITS "0123456789"
+#define PROPNODECHARS LOWERCASE UPPERCASE DIGITS ",._+*#?-"
+
+static void check_node_name_chars(struct check *c, struct node *dt,
+ struct node *node)
+{
+ int n = strspn(node->name, c->data);
+
+ if (n < strlen(node->name))
+ FAIL(c, "Bad character '%c' in node %s",
+ node->name[n], node->fullpath);
+}
+NODE_CHECK(node_name_chars, PROPNODECHARS "@", ERROR);
+
+static void check_node_name_format(struct check *c, struct node *dt,
+ struct node *node)
+{
+ if (strchr(get_unitname(node), '@'))
+ FAIL(c, "Node %s has multiple '@' characters in name",
+ node->fullpath);
+}
+NODE_CHECK(node_name_format, NULL, ERROR, &node_name_chars);
+
+static void check_property_name_chars(struct check *c, struct node *dt,
+ struct node *node, struct property *prop)
+{
+ int n = strspn(prop->name, c->data);
+
+ if (n < strlen(prop->name))
+ FAIL(c, "Bad character '%c' in property name \"%s\", node %s",
+ prop->name[n], prop->name, node->fullpath);
+}
+PROP_CHECK(property_name_chars, PROPNODECHARS, ERROR);
+
static void check_explicit_phandles(struct check *c, struct node *root,
struct node *node)
{
@@ -498,6 +534,7 @@
static struct check *check_table[] = {
&duplicate_node_names, &duplicate_property_names,
+ &node_name_chars, &node_name_format, &property_name_chars,
&name_is_string, &name_properties,
&explicit_phandles,
&phandle_references, &path_references,
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2008-02-27 13:25:08.000000000 +1100
+++ dtc/tests/trees.S 2008-02-27 13:28:33.000000000 +1100
@@ -136,3 +136,51 @@
truncated_property_strings_end:
truncated_property_end:
+
+
+ TREE_HDR(bad_node_char)
+ EMPTY_RSVMAP(bad_node_char)
+
+bad_node_char_struct:
+ BEGIN_NODE("")
+ BEGIN_NODE("sub$node")
+ END_NODE
+ END_NODE
+ FDTLONG(FDT_END)
+bad_node_char_struct_end:
+
+bad_node_char_strings:
+bad_node_char_strings_end:
+bad_node_char_end:
+
+
+ TREE_HDR(bad_node_format)
+ EMPTY_RSVMAP(bad_node_format)
+
+bad_node_format_struct:
+ BEGIN_NODE("")
+ BEGIN_NODE("subnode@1@2")
+ END_NODE
+ END_NODE
+ FDTLONG(FDT_END)
+bad_node_format_struct_end:
+
+bad_node_format_strings:
+bad_node_format_strings_end:
+bad_node_format_end:
+
+
+ TREE_HDR(bad_prop_char)
+ EMPTY_RSVMAP(bad_prop_char)
+
+bad_prop_char_struct:
+ BEGIN_NODE("")
+ PROP_INT(bad_prop_char, prop, TEST_VALUE_1)
+ END_NODE
+ FDTLONG(FDT_END)
+bad_prop_char_struct_end:
+
+bad_prop_char_strings:
+ STRING(bad_prop_char, prop, "prop$erty")
+bad_prop_char_strings_end:
+bad_prop_char_end:
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2008-02-27 13:25:08.000000000 +1100
+++ dtc/flattree.c 2008-02-27 13:41:06.000000000 +1100
@@ -729,29 +729,14 @@
return strdup(lslash+1);
}
-static const char PROPCHAR[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789,._+*#?-";
-static const char UNITCHAR[] = "0123456789abcdef,";
-
-static int check_node_name(const char *name)
+static int find_basenamelen(const char *name)
{
- const char *atpos;
- int basenamelen;
-
- atpos = strrchr(name, '@');
+ const char *atpos = strchr(name, '@');
if (atpos)
- basenamelen = atpos - name;
+ return atpos - name;
else
- basenamelen = strlen(name);
-
- if (strspn(name, PROPCHAR) < basenamelen)
- return -1;
-
- if (atpos
- && ((basenamelen + 1 + strspn(atpos+1, UNITCHAR)) < strlen(name)))
- return -1;
-
- return basenamelen;
+ return strlen(name);
}
static struct node *unflatten_tree(struct inbuf *dtbuf,
@@ -775,10 +760,7 @@
node->fullpath = join_path(parent_path, node->name);
}
- node->basenamelen = check_node_name(node->name);
- if (node->basenamelen < 0) {
- fprintf(stderr, "Warning \"%s\" has incorrect format\n", node->name);
- }
+ node->basenamelen = find_basenamelen(node->name);
do {
struct property *prop;
Index: dtc/tests/dumptrees.c
===================================================================
--- dtc.orig/tests/dumptrees.c 2008-02-27 13:25:08.000000000 +1100
+++ dtc/tests/dumptrees.c 2008-02-27 13:25:09.000000000 +1100
@@ -37,6 +37,7 @@
} trees[] = {
#define TREE(name) { &_##name, #name ".dtb" }
TREE(test_tree1),
+ TREE(bad_node_char), TREE(bad_node_format), TREE(bad_prop_char),
};
#define NUM_TREES (sizeof(trees) / sizeof(trees[0]))
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2008-02-27 13:25:08.000000000 +1100
+++ dtc/tests/run_tests.sh 2008-02-27 13:25:09.000000000 +1100
@@ -189,6 +189,9 @@
run_test dtc-checkfails.sh ranges_format -- -I dts -O dtb bad-empty-ranges.dts
run_test dtc-checkfails.sh avoid_default_addr_size -- -I dts -O dtb default-addr-size.dts
run_test dtc-checkfails.sh obsolete_chosen_interrupt_controller -- -I dts -O dtb obsolete-chosen-interrupt-controller.dts
+ run_test dtc-checkfails.sh node_name_chars -- -I dtb -O dtb bad_node_char.dtb
+ run_test dtc-checkfails.sh node_name_format -- -I dtb -O dtb bad_node_format.dtb
+ run_test dtc-checkfails.sh prop_name_chars -- -I dtb -O dtb bad_prop_char.dtb
}
while getopts "vt:m" ARG ; do
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2008-02-27 13:25:08.000000000 +1100
+++ dtc/tests/testdata.h 2008-02-27 13:25:09.000000000 +1100
@@ -33,4 +33,7 @@
#ifndef __ASSEMBLY__
extern struct fdt_header _test_tree1;
extern struct fdt_header _truncated_property;
+extern struct fdt_header _bad_node_char;
+extern struct fdt_header _bad_node_format;
+extern struct fdt_header _bad_prop_char;
#endif /* ! __ASSEMBLY */
--
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: Patches added to master & powerpc-next branches of powerpc.git
From: Paul Mackerras @ 2008-02-27 1:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <12F84CB4-8344-4F70-A89F-4A1FF590C35C@kernel.crashing.org>
Kumar Gala writes:
> How do you plan on managing the powerpc-next branch in the future?
> For example, I assume at some point linus will pull it into what would
> be 2.6.26. Would you rebase this branch? etc.
Yes, it is basically the for-2.6.26 branch. I will try very hard not
to rebase it, but I don't promise that I will never rebase it.
I'm expecting to get requests to pull your tree into it, as well as
Josh's, Grant's, etc., once you have stuff that you are reasonably
confident should go in to the next release and won't need to be
rebased.
Paul.
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Benjamin Herrenschmidt @ 2008-02-27 0:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18372.45605.265760.646342@cargo.ozlabs.ibm.com>
On Wed, 2008-02-27 at 11:43 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> > > Benjamin Herrenschmidt (1):
> > > [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
> > >
> >
> > Any reason why this isn't going into .25 ?
>
> I thought you said nothing uses it.
I'm worried some out of tree stuff might...
But if not, yeah, it's fine.
Ben.
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Paul Mackerras @ 2008-02-27 0:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1204070815.15052.194.camel@pasglop>
Benjamin Herrenschmidt writes:
> On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> > Benjamin Herrenschmidt (1):
> > [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
> >
>
> Any reason why this isn't going into .25 ?
I thought you said nothing uses it.
Paul.
^ permalink raw reply
* Re: Patches added to master & powerpc-next branches of powerpc.git
From: Benjamin Herrenschmidt @ 2008-02-27 0:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18371.65529.312001.673609@cargo.ozlabs.ibm.com>
On Tue, 2008-02-26 at 23:03 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt (1):
> [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
>
Any reason why this isn't going into .25 ?
Ben.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Josh Boyer @ 2008-02-26 23:53 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus, sfr
In-Reply-To: <20080226.144423.138965691.davem@davemloft.net>
On Tue, 26 Feb 2008 14:44:23 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 27 Feb 2008 08:45:37 +1100
>
> > I doubt we do that. Properties that contain things like ranges, or "reg"
> > properties are expected to be of a size that is a multiple of
> > #size-cells/#address-cells and I'm not sure that won't break things here
> > or there if they suddenly get one more byte..
> >
> > Or do you mean you/we are appending that-without- changing the length
> > field ?
>
> Right, simply don't change the length field. Put the zero byte
> at offset "length + 1"
>
> It's stupid to validate NULL termination everywhere when we
> can make it an invariant in one spot.
I don't mind fixing up the function to use strncmp and checking for a 0
length from of_get_property. However, I'm almost certain that other
places in the code have the same issue so what you're saying here seems
to make sense.
josh
^ permalink raw reply
* Re: copy_from_user problem
From: Benjamin Herrenschmidt @ 2008-02-26 23:22 UTC (permalink / raw)
To: maynardj; +Cc: linuxppc-dev
In-Reply-To: <47C426F8.7070203@us.ibm.com>
On Tue, 2008-02-26 at 08:49 -0600, Maynard Johnson wrote:
> 2. Compile C program as 32-bit; then run it. While the program is
> waiting for input, obtain its PID and do 'cat /proc/<pid>/maps' to
> get
> the address of where libc is loaded.
> 3. From the dir where you build the uaccess_test kernel module:
> 'insmod ./uaccess_test.ko lib_addr=0x<mem_loc_libc>'
> This should succeed. dmesg to verify.
> 4. Unload the module.
> 5. Recompile your C program with -m64; start it up and obtain the
> address of libc again (now a 64-bit address).
> 6. Load the uaccess_test kernel module and pass
> 'lib_addr=0x<mem_loc_libc>'. Note that this time, the load fails.
> dmesg to see debug printk's.
Sounds to me that your kernel module will try to copy_from_user() from
the user context of ... insmod :-)
You need to do your copy_from_user() from within the context of the
program you try to access the memory from !
If you need to access another context than the current one, you then
need to use a different mechanism, such as get_user_pages(), though
beware that you can only do that for memory, not SPE local store or
register mappings.
Ben.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Benjamin Herrenschmidt @ 2008-02-26 22:58 UTC (permalink / raw)
To: David Miller; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20080226.144423.138965691.davem@davemloft.net>
On Tue, 2008-02-26 at 14:44 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 27 Feb 2008 08:45:37 +1100
>
> > I doubt we do that. Properties that contain things like ranges, or "reg"
> > properties are expected to be of a size that is a multiple of
> > #size-cells/#address-cells and I'm not sure that won't break things here
> > or there if they suddenly get one more byte..
> >
> > Or do you mean you/we are appending that-without- changing the length
> > field ?
>
> Right, simply don't change the length field. Put the zero byte
> at offset "length + 1"
>
> It's stupid to validate NULL termination everywhere when we
> can make it an invariant in one spot.
Fair enough.
Ben.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: David Miller @ 2008-02-26 22:44 UTC (permalink / raw)
To: benh; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <1204062337.15052.160.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 27 Feb 2008 08:45:37 +1100
> I doubt we do that. Properties that contain things like ranges, or "reg"
> properties are expected to be of a size that is a multiple of
> #size-cells/#address-cells and I'm not sure that won't break things here
> or there if they suddenly get one more byte..
>
> Or do you mean you/we are appending that-without- changing the length
> field ?
Right, simply don't change the length field. Put the zero byte
at offset "length + 1"
It's stupid to validate NULL termination everywhere when we
can make it an invariant in one spot.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Benjamin Herrenschmidt @ 2008-02-26 21:45 UTC (permalink / raw)
To: David Miller; +Cc: sfr, paulus, linuxppc-dev
In-Reply-To: <20080226.133430.41760910.davem@davemloft.net>
On Tue, 2008-02-26 at 13:34 -0800, David Miller wrote:
> From: Paul Mackerras <paulus@samba.org>
> Date: Tue, 26 Feb 2008 20:04:12 +1100
>
> > It would probably be good to defend against the possibility that the
> > property isn't null-terminated (for example if its length is zero).
>
> FWIW, when I pull in the device tree on sparc I eliminate any need for
> those kinds of checks by putting a '\0' at the end of every property
> blob.
>
> I copied a lot of this code from you guys, so it wouldn't surprise
> me if ppc does this too. :-)
I doubt we do that. Properties that contain things like ranges, or "reg"
properties are expected to be of a size that is a multiple of
#size-cells/#address-cells and I'm not sure that won't break things here
or there if they suddenly get one more byte..
Or do you mean you/we are appending that-without- changing the length
field ?
Ben.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: David Miller @ 2008-02-26 21:34 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, sfr
In-Reply-To: <18371.54796.174623.988521@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Tue, 26 Feb 2008 20:04:12 +1100
> It would probably be good to defend against the possibility that the
> property isn't null-terminated (for example if its length is zero).
FWIW, when I pull in the device tree on sparc I eliminate any need for
those kinds of checks by putting a '\0' at the end of every property
blob.
I copied a lot of this code from you guys, so it wouldn't surprise
me if ppc does this too. :-)
^ permalink raw reply
* Porting ISP1760 USB host controller driver to Virtex ppc405 arch linux
From: alex_snippet @ 2008-02-26 21:04 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody, how to port ISP1760 USB host controller driver to Virtex ppc405
arch linux?
It has been ported to blackfin arch
http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?action=browse&path=%2Ftrunk%2Fdrivers%2Fusb%2Fhost%2Fpehcd%2Fhost%2F&pathrev=2763
--
View this message in context: http://www.nabble.com/Porting-ISP1760-USB-host-controller-driver-to-Virtex-ppc405-arch-linux-tp15699965p15699965.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Define CONFIG_PPC_NEW_BINDING
From: Scott Wood @ 2008-02-26 18:57 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-dev
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AAF2@xmb-sjc-212.amer.cisco.com>
On Tue, Feb 26, 2008 at 10:31:21AM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi All,
> In order to define CONFIG_PPC_NEW_BINDING, which kernel configuration
> parameters should be selected (i.e. .config file)?
The kconfig entry for your board should contain the line
"select PPC_CPM_NEW_BINDING".
-Scott
^ permalink raw reply
* Re: [patch 0/6] pasemi_mac updates for 2.6.26
From: Olof Johansson @ 2008-02-26 18:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, pasemi-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <47C4588C.5060904@pobox.com>
On Tue, Feb 26, 2008 at 01:21:00PM -0500, Jeff Garzik wrote:
> Olof Johansson wrote:
> > On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
> >> What route do you think these should take upstream? I'm happy to take
> >> them if Jeff is OK with that.
> >
> > I've sent them through Jeff in the past, that's been convenient when
> > there's been churn in the network APIs. I'm not sure if there's much of
> > that for .26 though.
> >
> > If Jeff prefers to ACK, I'll just add it to my git and ask you to pull
> > that. But I was originally planning to just feed it through him.
> >
> > (Note: I'll repost the patch set later today or tomorrow with a couple
> > of tweaks).
>
> Not much networking churn for 2.6.26, and IMO this patchset have
> above-average ppc changes/dependencies, so.... ACK
Ok, thanks Jeff.
Paul: I'll commit to my tree and ask you to pull later.
-Olof
^ permalink raw reply
* Define CONFIG_PPC_NEW_BINDING
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-26 18:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
Hi All,
In order to define CONFIG_PPC_NEW_BINDING, which kernel configuration
parameters should be selected (i.e. .config file)?
Thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 811 bytes --]
^ permalink raw reply
* Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
From: Adrian Bunk @ 2008-02-26 18:25 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linuxppc-dev, sam, Linux Kernel Mailing List, linux-kbuild
In-Reply-To: <47C457F5.4080902@linux.vnet.ibm.com>
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
> Adrian Bunk wrote:
> > On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
> >> the .config has been attached.
> >> ...
> >
> > Builds fine here.
> >
> > Local problem (e.g. disk full) on your machine?
> >
> > cu
> > Adrian
> >
> Hi Adrain,
Hi Kamalseh, ;)
> It Builds fine on another powerpc box with the same .config file, the problem seems to be with the gcc
> on that box, the reported build failure might have been the side effect of the same.
>
>
> drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
> drivers/md/raid6int8.c:185: error: unable to find a register to spill in class `FLOAT_REGS'
> drivers/md/raid6int8.c:185: error: this is the insn:
> (insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI (reg/v/f:DI 122 [ p ])
> (reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
> (reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
> (expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
> (nil)))
> drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
> make[2]: *** [drivers/md/raid6int8.o] Error 1
> make[1]: *** [drivers/md] Error 2
> make: *** [drivers] Error 2
>
> # gcc --version
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
this means your quite old vendor gcc has a bug.
> Thanks & Regards,
> Kamalesh Babulal,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [patch 0/6] pasemi_mac updates for 2.6.26
From: Jeff Garzik @ 2008-02-26 18:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, pasemi-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <20080226141624.GB22572@lixom.net>
Olof Johansson wrote:
> On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
>> Olof Johansson writes:
>>
>>> Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
>>> the dma_lib in the platform code as well, but it's easier if it's all
>>> merged through netdev to avoid dependencies.
>>>
>>> Major highlights are jumbo frame support and ethtool basics, the rest
>>> is mostly minor plumbing around it.
>> What route do you think these should take upstream? I'm happy to take
>> them if Jeff is OK with that.
>
> I've sent them through Jeff in the past, that's been convenient when
> there's been churn in the network APIs. I'm not sure if there's much of
> that for .26 though.
>
> If Jeff prefers to ACK, I'll just add it to my git and ask you to pull
> that. But I was originally planning to just feed it through him.
>
> (Note: I'll repost the patch set later today or tomorrow with a couple
> of tweaks).
Not much networking churn for 2.6.26, and IMO this patchset have
above-average ppc changes/dependencies, so.... ACK
^ permalink raw reply
* Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
From: Kamalesh Babulal @ 2008-02-26 18:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, sam, Linux Kernel Mailing List, linux-kbuild
In-Reply-To: <20080226151512.GA10717@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
>> Hi,
>>
>> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
>> the .config has been attached.
>> ...
>
> Builds fine here.
>
> Local problem (e.g. disk full) on your machine?
>
> cu
> Adrian
>
Hi Adrain,
It Builds fine on another powerpc box with the same .config file, the problem seems to be with the gcc
on that box, the reported build failure might have been the side effect of the same.
drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
drivers/md/raid6int8.c:185: error: unable to find a register to spill in class `FLOAT_REGS'
drivers/md/raid6int8.c:185: error: this is the insn:
(insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI (reg/v/f:DI 122 [ p ])
(reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
(reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
(expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
(nil)))
drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
make[2]: *** [drivers/md/raid6int8.o] Error 1
make[1]: *** [drivers/md] Error 2
make: *** [drivers] Error 2
# gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* MMC over SPI on Virtex-4
From: Brian Silverman @ 2008-02-26 16:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Hello all,
I'm attempting to get MMC over xilinx_spi working on a custom Xilinx
Virtex-4 board (that has a working SD/SPI interface, tested with a
standalone app).
I'm having issues mounting the device, and after doing a bit of
debugging, I'm confused about how things are supposed to work. I'm
using 2.6.24-rc8-xlnx from git.xilinx.com, with some patches (for the
uartlite (Grant Likely), and other minor things). In addition, I'm
using some of a patch from Andrei Konovalov (
<list?person=202&id=11577>http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11577)
for Xilinx SPI support in virtex_devices.c (BTW, will this patch hit the
main git.xilinx.com tree at some point?)
Here's what I do, and what I see:
- Create a block device: "mknod /dev/m0 b 179 0"
- Access that device ("cat /dev/m0")
- I see the calls into the kernel:
blkdev_open()
do_open()
get_gendisk()
kobj_lookup(bdev_map, ...)
- The device is not found (bdev_map has been initialized, but the only
"probe" at major 179 is base_probe().
- kobj_lookup() returns NULL, and the open returns ENXIO (No such device
or address).
Here's what I don't understand: In order for kobj_lookup to
successfully return non-NULL, a "probe" has to have been added to
bdev_map using kobj_map(). But, kobj_map(bdev_map,...) is called only
by blk_register_region(), which is never called by the MMC driver.
I'm clearly missing something here. Has anyone successfully used MMC
over SPI or xilinx_spi? How is the MMC driver supposed to work in
regards to opening a device?
Also, for reference:
I've added the following configs:
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_BITBANG=y
CONFIG_SPI_XILINX=y
CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_MMC_SPI=y
And, /proc/devices does report the mmc device:
# cat /proc/devices
Character devices:
1 mem
4 /dev/vc/0
4 tty
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
128 ptm
136 pts
204 ttyUL
Block devices:
1 ramdisk
179 mmc
--
Brian Silverman
Concept X, LLC
[-- Attachment #2: Type: text/html, Size: 2816 bytes --]
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-26 17:26 UTC (permalink / raw)
To: jdl, linuxppc-dev
In-Reply-To: <20080226003955.GA24382@localhost.localdomain>
On Tue, Feb 26, 2008 at 11:39:55AM +1100, David Gibson wrote:
> > diff --git a/Makefile b/Makefile
> > index 8a47c34..d4d935c 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -16,7 +16,7 @@ LOCAL_VERSION =
> > CONFIG_LOCALVERSION =
> >
> > CPPFLAGS = -I libfdt
> > -CFLAGS = -Wall -g -Os
> > +CFLAGS = -Wall -g -Os -D_FILE_OFFSET_BITS=64
>
> Is this portable?
It seems fairly widespread, but I don't know if it's specified by any
standards. Some googling shows that _LARGE_FILES and _LARGEFILE64_SOURCE
are used in some environments.
> > d.len = len;
> > - fread(d.val, len, 1, f);
> > + if (fread(d.val, len, 1, f) != 1) {
> > + yyerrorf("Couldn't read %zu bytes from file: %s",
> > + len, feof(f) ? "end-of-file" : strerror(errno));
> > + return empty_data;
>
> Ugh.
> 1) Error messages direct to the user really don't belong in
> data.c's low-level support routines. This does mean we might need to
> substantially change this function so there's some other way of
> reporting the error to the caller who can report it.
Any suggestions on a mechanism that doesn't throw away information by
condensing everything down to a single error number?
> 2) The horrid name 'yyerror()' exists only to match what bison
> expects. It should never be used outside the parse code (we probably
> should create more generally usable error/warning functions, though).
Fine, so suggest a name.
> 3) Is %zu portable?
I believe it's part of C99.
> > + }
> > +
> > + return d;
> > +}
> > +
> > +struct data data_copy_file_all(FILE *f)
>
> It should be possible to combine these two functions.
Probably.
> > + d = data_grow_for(d, ret);
> > + memcpy(d.val + d.len, buf, ret);
> > +
> > + if (d.len + ret < d.len) {
> > + yyerror("Binary include too large");
>
> Hrm. A test which will cover this case should go into
> data_grow_for(), I think.
Agreed.
-Scott
^ permalink raw reply
* Re: copy_from_user problem
From: Maynard Johnson @ 2008-02-26 15:36 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080226150138.GD16241@localdomain>
Nathan Lynch wrote:
> Maynard Johnson wrote:
>> static long lib_addr;
>> module_param(lib_addr, long, 0);
> ^^^^
> Should be unsigned long?
Right. I switched this to 'ulong', but that didn't make a difference in
my test results.
>
^ permalink raw reply
* Re: copy_from_user problem
From: Nathan Lynch @ 2008-02-26 15:30 UTC (permalink / raw)
To: Maynard Johnson; +Cc: linuxppc-dev
In-Reply-To: <20080226150138.GD16241@localdomain>
Nathan Lynch wrote:
> Maynard Johnson wrote:
> >
> > static long lib_addr;
> > module_param(lib_addr, long, 0);
> ^^^^
> Should be unsigned long?
ulong, rather, but that doesn't fix it.
In any case, lib_addr is a user virtual address; doesn't the kernel
need to do get_user_pages or some such to get at arbitrary process
memory?
^ permalink raw reply
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