* libfdt: Add some documenting comments in libfdt.h
From: David Gibson @ 2007-10-24 7:10 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch adds some internal documentation in libfdt.h, in the form
of comments on the error codes and some functions. Only a couple of
functions are covered so far, leaving the documentation still woefully
inadequate, but hey, it's a start.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-10-24 15:56:14.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-10-24 16:55:09.000000000 +1000
@@ -59,27 +59,64 @@
/* Error codes: informative error codes */
#define FDT_ERR_NOTFOUND 1
+ /* FDT_ERR_NOTFOUND: The requested node or property does not exist */
#define FDT_ERR_EXISTS 2
+ /* FDT_ERR_EXISTS: Attemped to create a node or property which
+ * already exists */
#define FDT_ERR_NOSPACE 3
+ /* FDT_ERR_NOSPACE: Operation needed to expand the device
+ * tree, but its buffer did not have sufficient space to
+ * contain the expanded tree. Use fdt_open_into() to move the
+ * device tree to a buffer with more space. */
/* Error codes: codes for bad parameters */
#define FDT_ERR_BADOFFSET 4
+ /* FDT_ERR_BADOFFSET: Function was passed a structure block
+ * offset which is out-of-bounds, or which points to an
+ * unsuitable part of the structure for the operation. */
#define FDT_ERR_BADPATH 5
+ /* FDT_ERR_BADPATH: Function was passed a badly formatted path
+ * (e.g. missing a leading / for a function which requires an
+ * absolute path) */
#define FDT_ERR_BADSTATE 6
+ /* FDT_ERR_BADSTATE: Function was passed an incomplete device
+ * tree created by the sequential-write functions, which is
+ * not sufficiently complete for the requested operation. */
/* Error codes: codes for bad device tree blobs */
#define FDT_ERR_TRUNCATED 7
+ /* FDT_ERR_TRUNCATED: Structure block of the given device tree
+ * ends without an FDT_END tag. */
#define FDT_ERR_BADMAGIC 8
+ /* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
+ * device tree at all - it is missing the flattened device
+ * tree magic number. */
#define FDT_ERR_BADVERSION 9
+ /* FDT_ERR_BADVERSION: Given device tree has a version which
+ * can't be handled by the requested operation. For
+ * read-write functions, this may mean that fdt_open_into() is
+ * required to convert the tree to the expected version. */
#define FDT_ERR_BADSTRUCTURE 10
+ /* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
+ * structure block or other serious error (e.g. misnested
+ * nodes, or subnodes preceding properties). */
#define FDT_ERR_BADLAYOUT 11
+ /* FDT_ERR_BADLAYOUT: For read-write functions, the given
+ * device tree has it's sub-blocks in an order that the
+ * function can't handle (memory reserve map, then structure,
+ * then strings). Use fdt_open_into() to reorganize the tree
+ * into a form suitable for the read-write operations. */
/* "Can't happen" error indicating a bug in libfdt */
#define FDT_ERR_INTERNAL 12
+ /* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
+ * Indicates a bug in libfdt itself. */
#define FDT_ERR_MAX 12
-/* Low-level functions (you probably don't need these) */
+/**********************************************************************/
+/* Low-level functions (you probably don't need these) */
+/**********************************************************************/
const void *fdt_offset_ptr(const void *fdt, int offset, int checklen);
static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
@@ -94,7 +131,10 @@ static inline void *fdt_offset_ptr_w(voi
uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
-/* General functions */
+/**********************************************************************/
+/* General functions */
+/**********************************************************************/
+
#define fdt_get_header(fdt, field) \
(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
#define fdt_magic(fdt) (fdt_get_header(fdt, magic))
@@ -111,15 +151,91 @@ uint32_t fdt_next_tag(const void *fdt, i
#define fdt_set_header(fdt, field, val) \
((struct fdt_header *)(fdt))->field = cpu_to_fdt32(val)
+/**
+ * fdt_check_header - sanity check a device tree or possible device tree
+ * @fdt: pointer to data which might be a flattened device tree
+ *
+ * fdt_check_header() checks that the given buffer contains what
+ * appears to be a flattened device tree with sane information in its
+ * header.
+ *
+ * returns:
+ * 0, if the buffer appears to contain a valid device tree
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE, standard meanings, as above
+ */
int fdt_check_header(const void *fdt);
+
+/**
+ * fdt_move - move a device tree around in memory
+ * @fdt: pointer to the device tree to move
+ * @buf: pointer to memory where the device is to be moved
+ * @bufsize: size of the memory space at buf
+ *
+ * fdt_move() relocates, if possible, the device tree blob located at
+ * fdt to the buffer at buf of size bufsize. The buffer may overlap
+ * with the existing device tree blob at fdt. Therefore,
+ * fdt_move(fdt, fdt, fdt_totalsize(fdt))
+ * should always succeed.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, bufsize is insufficient to contain the device tree
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE, standard meanings
+ */
int fdt_move(const void *fdt, void *buf, int bufsize);
-/* Read-only functions */
+/**********************************************************************/
+/* Read-only functions */
+/**********************************************************************/
+
+/**
+ * fdt_string - retreive a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ *
+ * fdt_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt.
+ *
+ * returns:
+ * a pointer to the string, on success
+ * NULL, if stroffset is out of bounds
+ */
const char *fdt_string(const void *fdt, int stroffset);
-int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+/**
+ * fdt_num_mem_rsv - retreive the number of memory reserve map entries
+ * @fdt: pointer to the device tree blob
+ *
+ * Returns the number of entries in the device tree blob's memory
+ * reservation map. This does not include the terminating 0,0 entry
+ * or any other (0,0) entries reserved for expansion.
+ *
+ * returns:
+ * the number of entries
+ */
int fdt_num_mem_rsv(const void *fdt);
+/**
+ * fdt_get_mem_rsv - retreive one memory reserve map entry
+ * @fdt: pointer to the device tree blob
+ * @address, @size: pointers to 64-bit variables
+ *
+ * On success, *address and *size will contain the address and size of
+ * the n-th reserve map entry from the device tree blob, in
+ * native-endian format.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
+
int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
const char *name, int namelen);
int fdt_subnode_offset(const void *fdt, int parentoffset, const char *name);
@@ -163,7 +279,10 @@ int fdt_node_check_compatible(const void
int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
const char *compatible);
-/* Write-in-place functions */
+/**********************************************************************/
+/* Write-in-place functions */
+/**********************************************************************/
+
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
@@ -176,7 +295,10 @@ int fdt_setprop_inplace(void *fdt, int n
int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
int fdt_nop_node(void *fdt, int nodeoffset);
-/* Sequential-write functions */
+/**********************************************************************/
+/* Sequential write functions */
+/**********************************************************************/
+
int fdt_create(void *buf, int bufsize);
int fdt_add_reservemap_entry(void *fdt, uint64_t addr, uint64_t size);
int fdt_finish_reservemap(void *fdt);
@@ -192,7 +314,10 @@ int fdt_property(void *fdt, const char *
int fdt_end_node(void *fdt);
int fdt_finish(void *fdt);
-/* Read-write functions */
+/**********************************************************************/
+/* Read-write functions */
+/**********************************************************************/
+
int fdt_open_into(void *fdt, void *buf, int bufsize);
int fdt_pack(void *fdt);
@@ -214,7 +339,10 @@ int fdt_add_subnode_namelen(void *fdt, i
int fdt_add_subnode(void *fdt, int parentoffset, const char *name);
int fdt_del_node(void *fdt, int nodeoffset);
-/* Extra functions */
+/**********************************************************************/
+/* Debugging / informational functions */
+/**********************************************************************/
+
const char *fdt_strerror(int errval);
#endif /* _LIBFDT_H */
--
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 01/11] [POWERPC] Add 'machine: ...' line to common show_cpuinfo()
From: Stephen Rothwell @ 2007-10-24 7:11 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071023231309.29359.20887.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 425 bytes --]
On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz <m8@semihalf.com> wrote:
>
> + root = of_find_node_by_path("/");
> + if (root)
> + model = of_get_property(root, "model", NULL);
> + of_node_put(root);
The paranoid part of me says:
if (model)
> + seq_printf(m, "machine\t\t: %s\n", model);
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 03/11] [POWERPC] Add common mpc52xx_setup_pci() routine
From: Stephen Rothwell @ 2007-10-24 7:16 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071023231321.29359.96506.stgit@hekate.izotz.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Wed, 24 Oct 2007 01:13:21 +0200 Marian Balakowicz <m8@semihalf.com> wrote:
>
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -155,11 +155,7 @@ static void __init lite5200_setup_arch(void)
> #endif
>
> #ifdef CONFIG_PCI
> - np = of_find_node_by_type(NULL, "pci");
> - if (np) {
> - mpc52xx_add_bridge(np);
> - of_node_put(np);
> - }
> + mpc52xx_setup_pci();
> #endif
Normally we would have no "#ifdef CONFIG_PCI" here but instead define a
static inline void mpc52xx_setup_pci(void) { }
in the header file for the non PCI case.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* PPC4xx 2x eth phy
From: - Reyneke @ 2007-10-24 7:26 UTC (permalink / raw)
To: linuxppc-embedded
Some quick feedback to the list. A few weeks ago I talked about the problem=
of the second ethernet connection not working when the first ethernet conn=
ection does not have a link.
Basically the problem is PHYs that don't generate a RX clock when no link i=
s present (i.e. ET1011. It turns out that in case of the 440Epx, there is s=
ome interdependency within the EMAC which means that when EMAC1 initialises=
, there MUST be a RX clock on EMAC0. If that is not the case, EMAC1 will NO=
T send/receive even though initialisation and auto-negotiation is successfu=
l.
There is some linux code for handling missing RX clocks, but this code does=
not extend to the scenario where one EMAC is dependent on another EMAC's P=
HY having a receive clock.
Regards
Jan Reyneke
> HI,
>
> We've run into a bit of an odd problem and we are not sure where to go an=
d
> look for the cause.
>
> We have some 440EPx based hardware with two GIG-Ethernet ports using RGMI=
I
> and 2x ET1011C PHY's. Problem is that eth1 will only initialise correctly
> (i.e. receive and transmit) if eth0 has a link. Eth0 always work OK,
> regardless of eth1 status. Eth1 will work OK if eth0 has a link (i.e.
> initialised) at time of setup. Once initialised, eth0 status is
> irrelevant.
> All this is during Linux boot process.
>
> Any ideas?
>
> We can access PHY registers via u-boot (mii commands). Same 1Gig link
> speed
> is used on both ports. Linux kernel is 2.6.19.
_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk=
^ permalink raw reply
* CPM microcode uploading and CPM reset on MPC8560
From: Vladislav Nyaykalo @ 2007-10-24 8:05 UTC (permalink / raw)
To: linuxppc-embedded
Hello to everyone,
I need to insert a function that uploads CPM microcode and resets CPM
somewhere during kernel initialization before UART is initialized. Could you
please suggest me the best suitable place.
Target platform: MPC8560
Kernel: 2.6.10
Regards,
Vlad
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
^ permalink raw reply
* [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-23 21:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev list, Paul Mackerras, Jens Axboe
Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
uses struct scatterlist->page which no longer exists since commit
18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
sg_page(sg) instead of sg->page.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
If it was fixed before please ignore, I just ran into this.
--- linux-2.6.orig/include/asm/dma-mapping.h 2007-10-23 22:55:33.551133142 +0200
+++ linux-2.6/include/asm/dma-mapping.h 2007-10-23 22:56:07.081133142 +0200
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct sc
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
+ sg->dma_address = page_to_bus(sg_page(sg)) + sg->offset;
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(s
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_devic
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-23 21:47 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev list, Paul Mackerras, Jens Axboe
In-Reply-To: <1193173222.7733.42.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
On Tue, 2007-10-23 at 23:00 +0200, Johannes Berg wrote:
> Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
> 78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
> uses struct scatterlist->page which no longer exists since commit
> 18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
> sg_page(sg) instead of sg->page.
This doesn't help though, when I boot I get a NULL-pointer dereference
that looks approximately like this:
NIP blk_rq_map_sg + 0x64/0x190
LR ide_map_sg + 0x38/?
Call trace:
cfq_remove_request + 0x168 (unreliable)
cfq_dispatch_request + 0x44
ide_build_sglist + 0x38?
pmac_ide_dma_setup + 0xa0?
ide_do_rw_disk? + ?
[...]
I can upload the picture I took but it's hardly readable (taken with my
crappy cell phone)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Jens Axboe @ 2007-10-24 9:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193176034.4097.3.camel@johannes.berg>
On Tue, Oct 23 2007, Johannes Berg wrote:
> On Tue, 2007-10-23 at 23:00 +0200, Johannes Berg wrote:
> > Commit 33ff910f0f466184ffc3514628f18403dcd86761 fixed commit
> > 78bdc3106a877cfa50439fa66b52acbc4e7868df but the code that got put in
> > uses struct scatterlist->page which no longer exists since commit
> > 18dabf473e15850c0dbc8ff13ac1e2806d542c15 which requires using
> > sg_page(sg) instead of sg->page.
>
> This doesn't help though, when I boot I get a NULL-pointer dereference
> that looks approximately like this:
>
> NIP blk_rq_map_sg + 0x64/0x190
> LR ide_map_sg + 0x38/?
> Call trace:
> cfq_remove_request + 0x168 (unreliable)
> cfq_dispatch_request + 0x44
> ide_build_sglist + 0x38?
> pmac_ide_dma_setup + 0xa0?
> ide_do_rw_disk? + ?
> [...]
>
> I can upload the picture I took but it's hardly readable (taken with my
> crappy cell phone)
I lost track - which kernel are you booting? This looks like something
that should be fixed, did you try 2.6.24-rc1?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:22 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071024091446.GL14671@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
> I lost track - which kernel are you booting? This looks like something
> that should be fixed, did you try 2.6.24-rc1?
No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
give it a try, but I don't think I can confirm it works before tomorrow.
I see the build failure got fixed with commit
5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:23 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217742.5715.6.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote:
> No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> give it a try, but I don't think I can confirm it works before tomorrow.
> I see the build failure got fixed with commit
> 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
Wait, now I lost track. This patch is identical to that commit 5edad...,
what I was thinking of was the oops I got.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 9:24 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217816.5715.8.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Wed, 2007-10-24 at 11:23 +0200, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:22 +0200, Johannes Berg wrote:
>
> > No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> > give it a try, but I don't think I can confirm it works before tomorrow.
> > I see the build failure got fixed with commit
> > 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
>
> Wait, now I lost track. This patch is identical to that commit 5edad...,
> what I was thinking of was the oops I got.
Nah, never mind. Apologies to everybody. I'm confused, Jens says the
oops was fixed. I'll verify that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Jens Axboe @ 2007-10-24 9:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <1193217742.5715.6.camel@johannes.berg>
On Wed, Oct 24 2007, Johannes Berg wrote:
> On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
>
> > I lost track - which kernel are you booting? This looks like something
> > that should be fixed, did you try 2.6.24-rc1?
>
> No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> give it a try, but I don't think I can confirm it works before tomorrow.
> I see the build failure got fixed with commit
> 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it
will break on IDE. I'm confident that a newer kernel will solve this
issue.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] taskstats scaled time cleanup
From: Balbir Singh @ 2007-10-24 9:52 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-s390, linux-kernel, linuxppc-dev, paulus, linux390, akpm
In-Reply-To: <8789.1193208897@neuling.org>
Michael Neuling wrote:
> This moves the ability to scale cputime into generic code. This
> allows us to fix the issue in kernel/timer.c (noticed by Balbir) where
> we could only add an unscaled value to the scaled utime/stime.
>
> This adds a cputime_to_scaled function. As before, the POWERPC
> version does the scaling based on the last SPURR/PURR ratio
> calculated. The generic and s390 (only other arch to implement
> asm/cputime.h) versions are both NOPs.
>
> Also moves the SPURR and PURR snapshots closer.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Looks good to me
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* [PATCH] ehea: fix port_napi_disable/enable
From: Jan-Bernd Themann @ 2007-10-24 9:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
napi_disable / napi_enable must be applied on all ehea queues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index b557bb4..4b4b74e 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0078"
+#define DRV_VERSION "EHEA_0079"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index fe5ffac..a8b05d2 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2329,7 +2329,7 @@ static void port_napi_disable(struct ehea_port *port)
{
int i;
- for (i = 0; i < port->num_def_qps; i++)
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
napi_disable(&port->port_res[i].napi);
}
@@ -2337,7 +2337,7 @@ static void port_napi_enable(struct ehea_port *port)
{
int i;
- for (i = 0; i < port->num_def_qps; i++)
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
napi_enable(&port->port_res[i].napi);
}
@@ -2373,8 +2373,6 @@ static int ehea_down(struct net_device *dev)
ehea_drop_multicast_list(dev);
ehea_free_interrupts(dev);
- port_napi_disable(port);
-
port->state = EHEA_PORT_DOWN;
ret = ehea_clean_all_portres(port);
@@ -2396,6 +2394,7 @@ static int ehea_stop(struct net_device *dev)
flush_scheduled_work();
down(&port->port_lock);
netif_stop_queue(dev);
+ port_napi_disable(port);
ret = ehea_down(dev);
up(&port->port_lock);
return ret;
--
1.5.2
^ permalink raw reply related
* [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 10:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a Geyser 1, and I'm a very annoyed that it was
applied. It causes appletouch to continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode)
because the Geyser 1 doesn't respond to that. The patch description also
states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24 12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820 +0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-24 11:19 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071023214000.424.qmail@farnsworth.org>
Dale Farnsworth wrote:
> Valentine wrote:
>> Actually I also don't see much reason for the
>> USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
>> Is this really needed?
>
> I think so. The SOC host controllers are BE and the PCI
> host controllers are LE. Or, do you have an alternative
> method of handling both types?
>
> -Dale
Yes, PCI controllers are LE, but do we really need user-selectable
USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
by default for USB_OHCI_HCD_PCI?
The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
I think it's useless. We should always enable
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
and the real LE/BE implementation should be selected by the
corresponding properties in the device tree.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-24 12:07 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <4718B287.20306@ru.mvista.com>
Hello, I wrote:
>>> The only thing I'm still unusre about is that deterministic accounting.
>>>Could you point me at the patch which deals with this (at least for System 390
>>See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
> Wait, how this is related to the hrtimer's event handlers not being able
> to call account_process_time() from arch/powerpc/kernel/time.c instead of
> update_process_timess()?
I've just realized that I've missed the call to account_process_time() in
the new timer_interrupt(). :-<
Anyway, this leads to each tick being accounted twice if the deterministic
accounting is not enabled -- first by timer_interrupt() and then by the
hrtimers core, doesn't it?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Dale Farnsworth @ 2007-10-24 12:08 UTC (permalink / raw)
To: Valentine Barshak; +Cc: Linuxppc-dev
In-Reply-To: <471F2A32.8030202@ru.mvista.com>
On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
> Dale Farnsworth wrote:
> >Valentine wrote:
> >>Actually I also don't see much reason for the
> >>USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
> >>Is this really needed?
> >
> >I think so. The SOC host controllers are BE and the PCI
> >host controllers are LE. Or, do you have an alternative
> >method of handling both types?
>
> Yes, PCI controllers are LE, but do we really need user-selectable
> USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
> by default for USB_OHCI_HCD_PCI?
> The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
> I think it's useless. We should always enable
> USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
> and the real LE/BE implementation should be selected by the
> corresponding properties in the device tree.
I agree that they don't need to be user selectable. It is far preferable
to deduce their values from existing information, if possible.
-Dale
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Dmitry Torokhov @ 2007-10-24 12:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
Hi Johannes,
On 10/24/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
> without testing on a Geyser 1,
My fault, sorry. However Anton's device has product ID of 90x30B which
is Geyser 1 as far as I understand... But yes, we should not expect
other geysers respond to Geyser 3-specific commands.
> and I'm a very annoyed that it was
> applied. It causes appletouch to continuously printk:
>
> drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode)
>
> because the Geyser 1 doesn't respond to that. The patch description also
> states:
>
> > if we see 10 empty packets the touchpad needs to be reset; good
> > touchpads should not send empty packets anyway.
>
> which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
> empty packets, the simply continuously send measurements. One look at
> the specification would have confirmed that.
>
Is there a way to "plug" these Geysers? Waking up the kernel
continuously is not nice.
--
Dmitry
^ permalink raw reply
* Re: libfdt: Rename and publish _fdt_check_header()
From: Jon Loeliger @ 2007-10-24 13:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071024002852.GG10595@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> It's potentially useful for users of libfdt to sanity check a device
> tree (or, rather, a blob of data which may or may not be a device
> tree) before processing it in more detail with libfdt.
>
> This patch renames the libfdt internal function _fdt_check_header() to
> fdt_check_header() and makes it a published function, so it can now be
> used for this purpose.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] fix powerpc breakage in sg chaining code (again)
From: Johannes Berg @ 2007-10-24 11:21 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071024092334.GM14671@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Wed, 2007-10-24 at 11:23 +0200, Jens Axboe wrote:
> On Wed, Oct 24 2007, Johannes Berg wrote:
> > On Wed, 2007-10-24 at 11:14 +0200, Jens Axboe wrote:
> >
> > > I lost track - which kernel are you booting? This looks like something
> > > that should be fixed, did you try 2.6.24-rc1?
> >
> > No, it came out after I pulled, I was on v2.6.23-6815-g0895e91. I'll
> > give it a try, but I don't think I can confirm it works before tomorrow.
> > I see the build failure got fixed with commit
> > 5edadbd0ae35d2daabaf6b44f2c58d67d4021ed2 too.
>
> 0895e91d60ef9bdef426d1ce14bb94bd5875870d is definitely too old, so it
> will break on IDE. I'm confident that a newer kernel will solve this
> issue.
It does indeed, 2.6.24-rc1 runs fine. Thanks.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* strataflash size and partitioning problem
From: Amin Farajian @ 2007-10-24 13:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 5317 bytes --]
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-24 11:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Wed, 2007-10-24 at 12:44 +0200, Johannes Berg wrote:
> The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
> without testing on a Geyser 1, and I'm a very annoyed that it was
> applied. It causes appletouch to continuously printk:
I spoke too soon, I don't have a Geyser 1 but rather a Fountain touchpad
on my powerbook.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH v2] appletouch: fix fountain touchpad breakage
From: Johannes Berg @ 2007-10-24 11:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linuxppc-dev list, Anton Ekblad, Sven Anders, Soeren Sonnenburg
In-Reply-To: <1193222676.4510.5.camel@johannes.berg>
The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a fountain touchpad. It causes appletouch to
continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device (Geyser 3 mode)
because the fountain touchpad doesn't respond to that. The patch description
also states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since fountain touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit, a better solution for geyser 1
touchpads must be found.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
What I'd advocate for 2.6.25 is to split appletouch into two drivers:
"appletouch" for fountain touchpads and maybe "appletouch2" for geyser
touchpads, this will get rid of many of the huge if statements in the
packet processing path and make sure that the macbook crowd will no
longer have to workaround the powerbook touchpads seeing that we seem to
hardly talk to each other.
Or maybe Soeren Sonnenburg's rewrite could be used for Geyser touchpads.
drivers/input/mouse/appletouch.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24 12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820 +0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
^ permalink raw reply
* ioctl32 unknown cmds with 2.6.24-rc1
From: Johannes Berg @ 2007-10-24 12:30 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
I've been getting these warnings (many more of them but this is a list
of unique ones) on my quad G5 with 32-bit userspace:
ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
Does anybody know whether this is expected?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox