[PATCH] powerpc: excplictly copy elements of pt_regs
Gcc 4.3 produced this warning:
arch/powerpc/kernel/signal_64.c: In function 'restore_sigcontext':
arch/powerpc/kernel/signal_64.c:161: warning: array subscript is above array
bounds
This is caused by us copying to aliases of elements of the pt_regs
structure. Make those explicit.
This adds one extra __get_user and unrolls a loop.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/kernel/signal_64.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
This has been build tested for ppc64_defconfig.
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index da7c058..8af35c5 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -137,29 +137,29 @@ static long restore_sigcontext(struct pt_regs *regs,
sigset_t *set, int sig,
#endif
unsigned long err = 0;
unsigned long save_r13 = 0;
- elf_greg_t *gregs = (elf_greg_t *)regs;
unsigned long msr;
- int i;
/* If this is not a signal return, we preserve the TLS in r13 */
if (!sig)
save_r13 = regs-gpr[13];
- /* copy everything before MSR */
- err |= __copy_from_user(regs, sc-gp_regs,
- PT_MSR*sizeof(unsigned long));
-
+ /* copy the GPRs */
+ err |= __copy_from_user(regs-gpr, sc-gp_regs, sizeof(regs-gpr));
+ err |= __get_user(regs-nip, sc-gp_regs[PT_NIP]);
/* get MSR separately, transfer the LE bit if doing signal return */
err |= __get_user(msr, sc-gp_regs[PT_MSR]);
if (sig)
regs-msr = (regs-msr ~MSR_LE) | (msr MSR_LE);
-
+ err |= __get_user(regs-orig_gpr3, sc-gp_regs[PT_ORIG_R3]);
+ err |= __get_user(regs-ctr, sc-gp_regs[PT_CTR]);
+ err |= __get_user(regs-link, sc-gp_regs[PT_LNK]);
+ err |= __get_user(regs-xer, sc-gp_regs[PT_XER]);
+ err |= __get_user(regs-ccr, sc-gp_regs[PT_CCR]);
/* skip SOFTE */
- for (i = PT_MSR+1; i = PT_RESULT; i++) {
- if (i == PT_SOFTE)
- continue;
- err |= __get_user(gregs[i], sc-gp_regs[i]);
- }
+ err |= __get_user(regs-trap, sc-gp_regs[PT_TRAP]);
+ err |= __get_user(regs-dar, sc-gp_regs[PT_DAR]);
+ err |= __get_user(regs-dsisr, sc-gp_regs[PT_DSISR]);
+ err |= __get_user(regs-result, sc-gp_regs[PT_RESULT]);
if (!sig)
regs-gpr[13] = save_r13;
--
1.5.6
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/12] pata_mpc52xx: use linux/of_platform.h instead of asm
Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- drivers/ata/pata_mpc52xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I am not sure who wants to take this. diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c index bc79df6..a9e8273 100644 --- a/drivers/ata/pata_mpc52xx.c +++ b/drivers/ata/pata_mpc52xx.c @@ -16,10 +16,10 @@ #include linux/slab.h #include linux/delay.h #include linux/libata.h +#include linux/of_platform.h #include asm/types.h #include asm/prom.h -#include asm/of_platform.h #include asm/mpc52xx.h ACK. send it via an arch tree ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes entry of short packets
Hi benh,
Please find my comments inline.
On Tue, Jun 24, 2008 at 4:50 AM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Mon, 2008-06-23 at 14:55 +0200, Stefan Roese wrote:
From: Sathya Narayanan [EMAIL PROTECTED]
Short packets has to be discarded by the driver. So this patch addresses
the
issue of discarding the short packets of size lesser then ethernet header
size.
You are freeing the skb, why ? Shouldn't we just keep the skb in the
ring for further rx ?
Actually , short packets are not allowed to flow through the higher layers,
If any of the layer tried to use the extra room available may hit wit crash
.
Since it is a invalid packet it has to be dropped and freed in driver.
Actually if you see in code, the other invalid packets are also handelled
similar.
Signed-off-by: Sathya Narayanan [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c
b/drivers/net/ibm_newemac/core.c
index 6dfc2c9..aa407b2 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1652,6 +1652,13 @@ static int emac_poll_rx(void *param, int budget)
skb_put(skb, len);
push_packet:
+ if (skb-len ETH_HLEN) {
+ dev_kfree_skb(skb);
+ printk(KERN_WARNING %s: short packets dropped\n,
+dev-ndev-name);
+ ++dev-estats.rx_dropped_stack;
+ goto next;
+ }
skb-dev = dev-ndev;
skb-protocol = eth_type_trans(skb, dev-ndev);
emac_rx_csum(dev, skb, ctrl);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
Hi benh,
Please find my comments inline.
Thanks and regards,
SathyaNarayanan
On Tue, Jun 24, 2008 at 4:50 AM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Mon, 2008-06-23 at 14:54 +0200, Stefan Roese wrote:
From: Sathya Narayanan [EMAIL PROTECTED]
The descriptor pointers were not initialized to NIL values, so it was
poiniting to some random addresses which was completely invalid. This
fix takes care of initializing the descriptor to NIL values and clearing
the valid descriptors on clean ring operation.
Signed-off-by: Sathya Narayanan [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c
b/drivers/net/ibm_newemac/core.c
index 5d2108c..6dfc2c9 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1025,7 +1025,7 @@ static void emac_clean_tx_ring(struct emac_instance
*dev)
int i;
for (i = 0; i NUM_TX_BUFF; ++i) {
- if (dev-tx_skb[i]) {
+ if (dev-tx_skb[i] dev-tx_desc[i].data_ptr) {
Why changing the test above ?
The reason for changing this condition is , In any of the case if the
dev-tx_skb is not containing valid address, Then while clearing it you may
be resulted in address voilations. This additional condition ensures that
we are clearing the valid skbs.
Further this condition is not in general data flow, So this additional
condition should not have any impact on performance.
dev_kfree_skb(dev-tx_skb[i]);
dev-tx_skb[i] = NULL;
if (dev-tx_desc[i].ctrl MAL_TX_CTRL_READY)
@@ -2719,6 +2719,10 @@ static int __devinit emac_probe(struct of_device
*ofdev,
/* Clean rings */
memset(dev-tx_desc, 0, NUM_TX_BUFF * sizeof(struct
mal_descriptor));
memset(dev-rx_desc, 0, NUM_RX_BUFF * sizeof(struct
mal_descriptor));
+ for (i = 0; i = NUM_TX_BUFF; i++)
+ dev-tx_skb[i] = NULL;
+ for (i = 0; i = NUM_RX_BUFF; i++)
+ dev-rx_skb[i] = NULL;
Why not use memset here too ?
Yes, It was valid to use memset here. I can send the modified patch for
it.
/* Attach to ZMII, if needed */
if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
for (i = 0; i NUM_TX_BUFF; ++i) {
- if (dev-tx_skb[i]) {
+ if (dev-tx_skb[i]
dev-tx_desc[i].data_ptr) {
Why changing the test above ?
The reason for changing this condition is , In any of the case if
the dev-tx_skb is not containing valid address, Then while clearing
it you may be resulted in address voilations. This additional
condition ensures that we are clearing the valid skbs.
Further this condition is not in general data flow, So this additional
condition should not have any impact on performance.
Do you see -any- case where tx_skb[i] and dev-tx_desc[i].data_ptr would
be out of sync ? If that's the case, shouldn't we cleanup instead of
leaving some kind of stale entry in the ring ?
In addition, in pure theory, data_ptr == 0 is a valid DMA address :-) So
I think that part of the patch shouldn't be there.
dev_kfree_skb(dev-tx_skb[i]);
dev-tx_skb[i] = NULL;
if (dev-tx_desc[i].ctrl
MAL_TX_CTRL_READY)
@@ -2719,6 +2719,10 @@ static int __devinit
emac_probe(struct of_device *ofdev,
/* Clean rings */
memset(dev-tx_desc, 0, NUM_TX_BUFF * sizeof(struct
mal_descriptor));
memset(dev-rx_desc, 0, NUM_RX_BUFF * sizeof(struct
mal_descriptor));
+ for (i = 0; i = NUM_TX_BUFF; i++)
+ dev-tx_skb[i] = NULL;
+ for (i = 0; i = NUM_RX_BUFF; i++)
+ dev-rx_skb[i] = NULL;
Why not use memset here too ?
Yes, It was valid to use memset here. I can send the modified
patch for it.
Please do, thanks.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes entry of short packets
Actually , short packets are not allowed to flow through the higher layers, If any of the layer tried to use the extra room available may hit wit crash . Since it is a invalid packet it has to be dropped and freed in driver. Actually if you see in code, the other invalid packets are also handelled similar. My point is they should not. The rx skb should be kept in the ring for further rx (ie, the data ignored and re-use the skb). A bit like we do when we decide the packet is small enough to be copied to a new skb. Ie. Move you test above the threshold test and recycle the skb. We need to fix the usage of the dma operations in this driver anyway and this will make it easier as we'll be able to avoid re-mapping an skb we just recycle. (the current driver never unmaps which means it can't be used with an iommu, which is a problem on some cell based platforms). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 26/60] microblaze_v4: time support
On Thu, 26 Jun 2008, [EMAIL PROTECTED] wrote:
+
+static inline void udelay(unsigned long usec)
+{
+}
shouldnt this function be named zerodelay() ?
Thanks,
tglx
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree
On Friday 27 June 2008, John Rigby wrote:
On Thu, Jun 26, 2008 at 7:42 PM, David Gibson [EMAIL PROTECTED] wrote:
[snip]
[EMAIL PROTECTED] {
compatible = fsl,mpc5121-immr;
+ device_type = soc;
I realise we still need the unwanted device_type value on the soc in
some cases for backwards compatibility, but why are you adding it
where it wasn't before..?
Because get_immrbase in fsl_soc.c does not work without it.
I guess that's not much of a problem in the future any more, since with the
move to arch/powerpc, the few remaining drivers that still use it can
finally be converted to use of_iomap on the actual device instead of
the immrbase hack.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'powerpc-next' branch
Kumar Gala writes: Paul, any update on when we might see some of the various patches pulled into powerpc-next? This weekend assuming I get over this gastric flu-like lurgy that I have at the moment. I've got some work I'd like to see in .27 but it needs Michael's code patching patches. I thought you had some concerns about patches 5/14 and 12/14 of his series? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
On Fri, Jun 27, 2008 at 01:23:05AM +0200, Arnd Bergmann wrote: On Thursday 26 June 2008, Adrian Bunk wrote: Honestly, I do not completely like your approach of getting the microblaze port submitter to create the asm-generic files - I would personally prefer if the microblaze port would look exactly like all other ports and the (reasonable) changes you have in mind were not being discussed and done as part of the submission of a new port. But it works really well this way ;-). My point is that a new port should look just like all the other ports should have looked as well, not like they did. When it comes to the ABI, you cannot make incompatible changes after it's merged, so IMHO all ABI defining headers should go to asm-generic if possible. ... For the ABI it doesn't matter where the headers are. After all, it won't matter whether we'll unify resp. remove 22 or 23 files. That wasn't my idea. The logic was that if one more file exists in asm-generic that can be removed from the architectures, we get 22 more files to remove without anyone having to look at the big picture. When microblaze is in, Discussions of the big picture should be in an own thread, not as part of a merge of a new architecture. I am not an architecture maintainer, but I do not like the way you want to couple the microblaze merge with the move of stuff to asm-generic. They both make sense, but they are clearly separate issues. I can compile a list with asm-generic files that can be used to replace the architecture specific files, so the arch maintainers can decide on their own whether to clean their own stuff up or not. ... We need either all architectures changed or none at all - we do need the arch headers to become more similar, not more different. And this is why we need an agreement _before_ an asm-generic header gets added, not after it. Arnd 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH]: [MPC5200] (v2) Add ATA DMA support
Changes from previous version:
- Add FIFO status error checking code before a DMA transaction starts
and after it is completed.
- Fix an incorrect check in the previous patch causing spurious dma
table too small errors.
Tim
This patch adds MDMA/UDMA support (using BestComm for DMA) on the MPC5200
platform.
Based heavily on previous work by Freescale (Bernard Kuhn, John Rigby)
and Domen Puncer.
Using a SanDisk Extreme IV CF card I get read speeds of approximately
26.70 MB/sec.
The BestComm ATA task priority was changed to maximum in bestcomm_priv.h;
this fixes a deadlock issue I was experiencing when heavy DMA was
occuring on both the ATA and Ethernet BestComm tasks, e.g. when
downloading a large file over a LAN to disk.
There's also what I believe to be a hardware bug if you have high levels
of BestComm ATA DMA activity along with heavy LocalPlus Bus activity;
the address bus seems to sometimes get corrupted with ATA commands while
the LocalPlus Bus operation is still active (i.e. Chip Select is asserted).
I've asked Freescale about this but have not received a reply yet -- if
anybody from Freescale has any ideas please contact me; I can supply some
analyzer traces if needed. Therefore, for now, do not enable DMA if you
need reliable LocalPlus Bus unless you do a fixup in your driver as
follows:
Locking example:
while (test_and_set_bit(0, pata_mpc52xx_ata_dma_lock) != 0)
{
struct bcom_task_2 *tsk = pata_mpc52xx_ata_dma_task;
if(bcom_buffer_done_2(tsk))
return 1;
}
return 0;
(Save the return value to `flags`)
Unlocking example:
if(flags == 0)
clear_bit(0, pata_mpc52xx_ata_dma_lock);
Comments and testing would of course be very welcome.
Thanks,
Signed-off-by: Tim Yamin [EMAIL PROTECTED]
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/ata.h linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/ata.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/ata.h 2008-03-18 15:49:53.0 +
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/ata.h 2008-04-15 10:42:38.0 +0100
@@ -16,8 +16,8 @@
struct bcom_ata_bd {
u32 status;
- u32 dst_pa;
u32 src_pa;
+ u32 dst_pa;
};
extern struct bcom_task *
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c 2008-03-18 15:49:53.0 +
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c 2008-04-15 10:42:38.0 +0100
@@ -330,11 +330,10 @@
/* Init 'always' initiator */
out_8(bcom_eng-regs-ipr[BCOM_INITIATOR_ALWAYS], BCOM_IPR_ALWAYS);
- /* Disable COMM Bus Prefetch on the original 5200; it's broken */
- if ((mfspr(SPRN_SVR) MPC5200_SVR_MASK) == MPC5200_SVR) {
- regval = in_be16(bcom_eng-regs-PtdCntrl);
- out_be16(bcom_eng-regs-PtdCntrl, regval | 1);
- }
+ /* Disable COMM Bus Prefetch; ATA DMA does not work properly with it
+ enabled. */
+ regval = in_be16(bcom_eng-regs-PtdCntrl);
+ out_be16(bcom_eng-regs-PtdCntrl, regval | 1);
/* Init lock */
spin_lock_init(bcom_eng-lock);
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h 2008-03-18 15:49:53.0 +
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h 2008-04-15 10:42:38.0 +0100
@@ -17,6 +17,7 @@
#define __BESTCOMM_H__
struct bcom_bd; /* defined later on ... */
+struct bcom_bd_2;
/* */
@@ -49,6 +50,22 @@
void* priv;
};
+struct bcom_task_2 {
+ unsigned int tasknum;
+ unsigned int flags;
+ int irq;
+
+ struct bcom_bd_2 *bd;
+ phys_addr_t bd_pa;
+ void **cookie;
+ unsigned short index;
+ unsigned short outdex;
+ unsigned int num_bd;
+ unsigned int bd_size;
+
+ void* priv;
+};
+
#define BCOM_FLAGS_NONE 0xul
#define BCOM_FLAGS_ENABLE_TASK (1ul 0)
@@ -95,6 +112,11 @@
u32 data[1]; /* variable, but at least 1 */
};
+struct bcom_bd_2 {
+ u32 status;
+ u32 data[2]; /* variable, but at least 2 */
+};
+
#define BCOM_BD_READY 0x4000ul
/** _bcom_next_index - Get next input index.
@@ -108,6 +130,12 @@
return ((tsk-index + 1) == tsk-num_bd) ? 0 : tsk-index + 1;
}
+static inline int
+_bcom_next_index_2(struct bcom_task_2 *tsk)
+{
+ return ((tsk-index + 1) == tsk-num_bd) ? 0 : tsk-index + 1;
+}
+
/** _bcom_next_outdex - Get next output index.
* @tsk: pointer to task structure
*
@@ -129,6 +157,12 @@
return tsk-index == tsk-outdex;
}
+static inline int
+bcom_queue_empty_2(struct bcom_task_2 *tsk)
+{
+ return tsk-index == tsk-outdex;
+}
+
/**
* bcom_queue_full - Checks if a BestComm task BD queue is full
* @tsk: The BestComm task structure
@@ -151,6 +185,14 @@
return !(tsk-bd[tsk-outdex].status
Re: [RFC 1/3] powerpc: __copy_tofrom_user tweaked for Cell
Hi Paul, In my experience, dcbz slows down the hot-cache case because it adds a few cycles to the execution time of the inner loop, and on most 64-bit PowerPC implementations, it doesn't actually help even in the cold-cache case because the store queue does enough write combining I agree with you that on POWER the dcbz is probably not helping. On PowerPC my experience is different. From what I have seen DCBZ help enormously on 970,PA-Semi and CELL. Cheers Gunnar Paul Mackerras [EMAIL PROTECTED] To Gunnar von 24/06/2008 01:49 Boehn/Germany/Contr/[EMAIL PROTECTED] cc [EMAIL PROTECTED], Mark Nelson [EMAIL PROTECTED], linuxppc-dev@ozlabs.org, Michael Ellerman [EMAIL PROTECTED], [EMAIL PROTECTED], Arnd Bergmann [EMAIL PROTECTED] Subject Re: [RFC 1/3] powerpc: __copy_tofrom_user tweaked for Cell Gunnar von Boehn writes: Interesting points. Can you help me to understand where the negative effect of DCBZ does come from? In my experience, dcbz slows down the hot-cache case because it adds a few cycles to the execution time of the inner loop, and on most 64-bit PowerPC implementations, it doesn't actually help even in the cold-cache case because the store queue does enough write combining that the cache doesn't end up reading the line from memory. I don't know whether the Cell PPE can do that, but I could believe that it can't. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 0/3] sched: allow arch override of cpu power
Breno Leitao wrote: Nathan Lynch wrote: There is an interesting quality of POWER6 cores, which each have 2 hardware threads: assuming one thread on the core is idle, the primary thread is a little faster than the secondary thread. To illustrate: I found this feature interesting and decided to do some tests. After some tests I found that the example you post really runs fast in the first CPU, but a more elaborated application runs slower on the first CPU. Here is a small example: # taskset 0x1 time -f %e, %U, %S ./a.out ; taskset 0x2 time -f %e, %U, %S ./a.out 10.77, 10.72, 0.01 10.53, 10.48, 0.01 # taskset 0x2 time -f %e, %U, %S ./a.out ; taskset 0x1 time -f %e, %U, %S ./a.out 10.55, 10.50, 0.01 10.77, 10.72, 0.01 I've been able to duplicate your results, thanks for the testcase. Guess I'll need to understand what's going on before continuing with this... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 26/60] microblaze_v4: time support
+
+static inline void udelay(unsigned long usec)
+{
+}
shouldnt this function be named zerodelay() ?
Thanks,
tglx
I have prepared implementation of this function which sent me JW.
I did some changes which I test it because I found problem there.
M
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Address an assortment of portability problems
David Gibson wrote: On Thu, Jun 26, 2008 at 10:25:28AM -0500, Scott Wood wrote: On Thu, Jun 26, 2008 at 11:03:49AM +1000, David Gibson wrote: - the endian handling functions in libfdt_env.h, based on endian.h and byteswap.h are replaced with some portable open-coded versions. Unfortunately, these result in fairly crappy code when compiled, but as far as I can determine there doesn't seem to be any POSIX, SUS or de facto standard way of determining endianness at compile time, nor standard names for byteswapping functions. Since device-tree and network byte order happen to be the same, we could use ntohl/htonl. Not for the 64-bit version. Why? They operate on uint32_t despite the l in the name, and there are no 64-bit fields in the device tree... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
Hi Adrian and Arnd, After all, it won't matter whether we'll unify resp. remove 22 or 23 files. That wasn't my idea. The logic was that if one more file exists in asm-generic that can be removed from the architectures, we get 22 more files to remove without anyone having to look at the big picture. When microblaze is in, Discussions of the big picture should be in an own thread, not as part of a merge of a new architecture. I am not an architecture maintainer, but I do not like the way you want to couple the microblaze merge with the move of stuff to asm-generic. They both make sense, but they are clearly separate issues. I can compile a list with asm-generic files that can be used to replace the architecture specific files, so the arch maintainers can decide on their own whether to clean their own stuff up or not. ... We need either all architectures changed or none at all - we do need the arch headers to become more similar, not more different. And this is why we need an agreement _before_ an asm-generic header gets added, not after it. I moved some headers to asm-generic how Arnd recommended to me. The same style is applied to of files. If you think that is good idea to start with new topic what is necessary to move to asm-generic, I agree. For me is not hard to move these files back to asm-microblaze and then someone can do big patch among all archs. If you want to managed, please open new discussion about and cc me. Michal ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/booke: don't reinitialize time base
For some reason long ago I decided that we should zero out the time base when we calibrate the decrementer. The problem is that this can be harmful in SMP systems where the firmware has already synchronized the time bases on the various cores. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/kernel/time.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index c73fc33..eb93880 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -742,10 +742,6 @@ void __init generic_calibrate_decr(void) } #if defined(CONFIG_BOOKE) || defined(CONFIG_40x) - /* Set the time base to zero */ - mtspr(SPRN_TBWL, 0); - mtspr(SPRN_TBWU, 0); - /* Clear any pending timer interrupts */ mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS); -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'powerpc-next' branch
On Jun 27, 2008, at 6:27 AM, Paul Mackerras wrote: Kumar Gala writes: Paul, any update on when we might see some of the various patches pulled into powerpc-next? This weekend assuming I get over this gastric flu-like lurgy that I have at the moment. Uugh, that sucks. I've got some work I'd like to see in .27 but it needs Michael's code patching patches. I thought you had some concerns about patches 5/14 and 12/14 of his series? 5/14 needs some better comments but nothing that should hold up the acceptance and 12/14 or should be merged with 11/14 if he reposts the patch set. But again, nothing to hold things up. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
We need either all architectures changed or none at all - we do need the arch headers to become more similar, not more different. And this is why we need an agreement _before_ an asm-generic header gets added, not after it. We already have the agreement.. Files which are equal among archs should be in asm-generic. And there is simply no gain in adding files for an arch when can put them in asm-generic. When they are in asm-generic than we can fix the other archs one-by-one. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add 83xx and 86xx to 6xx Multiplatform
There isn't any reason at this point that we can't build 83xx 86xx support in with the other 6xx based boards. Twiddle the Kconfigs to allow this. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/platforms/83xx/Kconfig | 10 ++ arch/powerpc/platforms/86xx/Kconfig | 16 +++- arch/powerpc/platforms/Kconfig | 14 -- 3 files changed, 17 insertions(+), 23 deletions(-) diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index fe75b2a..27d9bf8 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -1,10 +1,12 @@ -menuconfig MPC83xx - bool 83xx Board Type - depends on PPC_83xx +menuconfig PPC_83xx + bool 83xx-based boards + depends on 6xx PPC_MULTIPLATFORM select PPC_UDBG_16550 select PPC_INDIRECT_PCI + select FSL_SOC + select IPIC -if MPC83xx +if PPC_83xx config MPC831x_RDB bool Freescale MPC831x RDB diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig index 053f49a..80a81e0 100644 --- a/arch/powerpc/platforms/86xx/Kconfig +++ b/arch/powerpc/platforms/86xx/Kconfig @@ -1,7 +1,13 @@ -choice - prompt 86xx Board Type - depends on PPC_86xx - default MPC8641_HPCN +config PPC_86xx +menuconfig PPC_86xx + bool 86xx-based boards + depends on 6xx PPC_MULTIPLATFORM + select FSL_SOC + select ALTIVEC + help + The Freescale E600 SoCs have 74xx cores. + +if PPC_86xx config MPC8641_HPCN bool Freescale MPC8641 HPCN @@ -24,7 +30,7 @@ config MPC8610_HPCD help This option enables support for the MPC8610 HPCD board. -endchoice +endif config MPC8641 bool diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 87454c5..3e2b645 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -16,20 +16,6 @@ config PPC_82xx bool Freescale 82xx depends on 6xx -config PPC_83xx - bool Freescale 83xx - depends on 6xx - select FSL_SOC - select MPC83xx - select IPIC - -config PPC_86xx - bool Freescale 86xx - depends on 6xx - select FSL_SOC - select ALTIVEC - help - The Freescale E600 SoCs have 74xx cores. endchoice config CLASSIC32 -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Hi Timur, Anyone know when of_i2c.c is going to come online replace what's in fsl_soc.c? There is a patch being prepared to convert i2c-mpc from a platform driver to an of_platform driver making the fsl_soc.c code obsolete. See: http://patchwork.ozlabs.org/linuxppc/patch?id=18898 Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
Hi Laurent, Is there any pending issue or can this be applied to powerpc-next ? Looks OK to me. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] Cc: Jochen Friedrich [EMAIL PROTECTED] Acked-by: Jochen Friedrich [EMAIL PROTECTED] Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] update crypto node definition and device tree instances
delete obsolete device-type property, delete model property (use compatible property instead), prepend fsl, to Freescale specific properties. Add nodes to device trees that are missing them, and fix broken property values in other trees. Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- changes from v1: b-w-of.txt: -- compatible : Should contain entries for all compatible SEC versions, - high to low, e.g., fsl,sec2.1, fsl,sec2.0 +- compatible : Should contain entries for this and backward compatible + SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 Documentation/powerpc/booting-without-of.txt | 51 +- arch/powerpc/boot/dts/mpc8272ads.dts | 21 --- arch/powerpc/boot/dts/mpc8313erdb.dts| 15 +++- arch/powerpc/boot/dts/mpc8315erdb.dts| 15 arch/powerpc/boot/dts/mpc832x_mds.dts| 15 +++- arch/powerpc/boot/dts/mpc832x_rdb.dts| 15 +++- arch/powerpc/boot/dts/mpc8349emitx.dts | 12 +++ arch/powerpc/boot/dts/mpc8349emitxgp.dts | 12 +++ arch/powerpc/boot/dts/mpc834x_mds.dts| 15 +++- arch/powerpc/boot/dts/mpc836x_mds.dts| 13 +++ arch/powerpc/boot/dts/mpc8377_mds.dts| 13 +++ arch/powerpc/boot/dts/mpc8377_rdb.dts| 14 +++ arch/powerpc/boot/dts/mpc8378_mds.dts| 13 +++ arch/powerpc/boot/dts/mpc8378_rdb.dts| 14 +++ arch/powerpc/boot/dts/mpc8379_mds.dts| 13 +++ arch/powerpc/boot/dts/mpc8379_rdb.dts| 14 +++ arch/powerpc/boot/dts/mpc8541cds.dts | 11 ++ arch/powerpc/boot/dts/mpc8544ds.dts | 11 ++ arch/powerpc/boot/dts/mpc8548cds.dts | 11 ++ arch/powerpc/boot/dts/mpc8555cds.dts | 11 ++ arch/powerpc/boot/dts/mpc8568mds.dts | 14 +++ arch/powerpc/boot/dts/mpc8572ds.dts | 12 ++ arch/powerpc/boot/dts/sbc8349.dts| 14 +++- arch/powerpc/boot/dts/sbc8548.dts| 11 ++ arch/powerpc/boot/dts/tqm8541.dts| 11 ++ arch/powerpc/boot/dts/tqm8555.dts| 11 ++ 26 files changed, 213 insertions(+), 169 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index b68684d..196e694 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -1472,9 +1472,8 @@ platforms are moved over to use the flattened-device-tree model. Required properties: -- device_type : Should be crypto -- model : Model of the device. Should be SEC1 or SEC2 -- compatible : Should be talitos +- compatible : Should contain entries for this and backward compatible + SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 - reg : Offset and length of the register set for the device - interrupts : a b where a is the interrupt number and b is a field that represents an encoding of the sense and level @@ -1483,27 +1482,29 @@ platforms are moved over to use the flattened-device-tree model. controller you have. - interrupt-parent : the phandle for the interrupt controller that services interrupts for this device. -- num-channels : An integer representing the number of channels +- fsl,num-channels : An integer representing the number of channels available. -- channel-fifo-len : An integer representing the number of +- fsl,channel-fifo-len : An integer representing the number of descriptor pointers each channel fetch fifo can hold. -- exec-units-mask : The bitmask representing what execution units +- fsl,exec-units-mask : The bitmask representing what execution units (EUs) are available. It's a single 32-bit cell. EU information should be encoded following the SEC's Descriptor Header Dword EU_SEL0 field documentation, i.e. as follows: -bit 0 = reserved - should be 0 -bit 1 = set if SEC has the ARC4 EU (AFEU) -bit 2 = set if SEC has the DES/3DES EU (DEU) -bit 3 = set if SEC has the message digest EU (MDEU) -bit 4 = set if SEC has the random number generator EU (RNG) -bit 5 = set if SEC has the public key EU (PKEU) -bit 6 = set if SEC has the AES EU (AESU) -bit 7 = set if SEC has the Kasumi EU (KEU) +bit 0 = reserved - should be 0 +bit 1 = set if SEC has the ARC4 EU (AFEU) +bit 2 = set if SEC has the DES/3DES EU (DEU) +bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A) +bit 4 = set if SEC has the random number generator EU (RNG) +bit 5 = set if SEC has the public key EU (PKEU) +bit 6 = set if SEC has the AES EU (AESU) +bit 7 = set if SEC has the Kasumi EU (KEU) +bit 8 = set if SEC has the CRC EU (CRCU) +bit 11 = set if SEC has the message digest EU extended
Re: Merging seperate FDT-blobs?
Hello David, On Mon, Jun 23, 2008 at 03:06:24PM +1000, David Gibson wrote: Hrm. I was assuming this would be handled by the code putting things together, rather than being encoded into the fragments. I envisaged something like: int fdt_graft(void *fdt, int parentoffset, const char *name, void *fragment); This would attach the tree fragment in the blob at 'fragment' into the tree 'fdt', with fragment's root gaining the name 'name' and being a child of the existing node at 'parentoffset'. This function is surely needed in every case I considered so far. I am just sceptical if the boot-loader can determine a correct parentoffset all alone (which one of the two I2C busses is the correct one?). This is why I added the property external-name as a helping hand. Meanwhile, I found your proposal about handling the aliases-node (http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045778.html) and think it will be a better alternative (as mentioned below). 2) How to deal with phandles? The fragment does not know anything about phandles from the main tree, so it cannot use them, although it needs to for a number of typical fdt-entries. Ah. This is harder. And there are two sub-pieces to this problem. First, how to ensure that any phandles for nodes in the fragment don't collide with phandles from the parent tree or other included fragments. Second, how to fixup phandle references in between initially separate fragments. As an asside, I think going through the grafted fragment and adjusting phandles to avoid collisions is a no-goer. Any new binding can potentially introduce a new property in which phandles appear, so we can't really know where to look for phandles and adjust. True. I didn't take into account that phandles may show up anywhere, even in a field of cells. Sigh, I wish phandles had some marker tag (no, I don't expect this to happen). So, for the first part, for now, I think the sanest way to handle this for now is simply to require that the fragments have non-overlapping phandles. For example by specifically allocating different ranges for different fragments when assembling a collection of such things. There are problems with this approach, and we may need something better, but I think it's where we need to start. At the moment that will require manually assigning all phandles, but we could extend dtc with a directive giving the range in which to assign phandles. So, if dtc has the possibility to specify a range for phandles, every fragment gets its own namespace for phandles. Handles which are clearly not leaving the namespace can still be referenced using the convenient phandle syntax. Every phandle which needs to be accessed from different namespaces, has to be hardcoded, preferably in their own hardcoded namespace (e.g. linux,phandle = 0xfxyz). Nice thing is, that it still can be assigned a dtc-label, so referencing inside the same source is also easy to maintain. Using macro features, one could even use #defines for the hardcoded values. Still, I sense some practical issues. I guess I need to sketch some more possible constellations to get an even bigger picture. Problem is as often: if you get generic, you get complexity. Hrm. I don't really follow the point of this scheme. It seems like you're encoding how to assemble the fragments into the master fragment. What I encoded using external-name is where possible fragments _could_ be added to. Something like a mount-point. The boot-loader decides if and what could be mounted there. As an /aliases node is already in use, I would favour to add such mount-points there. But the whole point of assembling fragments is that the master can encode several different trees depending what's included, which means something else needs to decide whether they're merged or not. I think just provide fdt_graft() as above, and leave the decisions about where and whether to the assembly code in the wrapper or bootloader. I assume the main tagret for this criticism is the externals-node I introduced at the very end. I agree that its functionality could be transferred to the boot-loader (e.g. give the boot-loader a list of addresses to check for potential eeproms). I wouldn't mind dropping the externals node; sounds in deed a bit cleaner. This doesn't work for properties which include phandles but are not simply a single phandle; 'interrupt-map' for example. Check mate :( We'll need property iteration for this, which we don't currently have. But I've been intending to implement that for a while anyway. I am quite sure it will come handy on the way nontheless. propname = property without 'phandle-for-'; name = fdt_getprop(external_fdt, cur_node, property); phandle_offset = fdt_node_offset_by_prop_value(main_fdt, external-name, name) phandle = fdt_get_phandle(main_fdt, phandle_offset);
Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapper targets
On Wed, Jun 25, 2008 at 01:21:04PM -0700, Grant Likely wrote: + zImage.%: Image usable by OpenFirmware. Image expects firmware + to provide the device tree using OpenFirmware + interfaces. Typically general purpose hardware uses + this image format. Is it really specific to Open Firmware? I'd say something like: Image format usable by the firmware natively shipped on the board, if not covered by another image type. A device tree is not embedded into the image. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add 83xx and 86xx to 6xx Multiplatform
On Fri, Jun 27, 2008 at 11:36:36AM -0500, Kumar Gala wrote: There isn't any reason at this point that we can't build 83xx 86xx support in with the other 6xx based boards. Twiddle the Kconfigs to allow this. Likewise with 82xx -- why don't we just get rid of the Machine type choice, and turn them all into bools? At the very least, change the misleading prompt and help text of PPC_MULTIPLATFORM before expanding the set of platforms that hide behind it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Add 82xx/83xx/86xx to 6xx Multiplatform
There isn't any reason at this point that we can't build 82xx, 83xx 86xx support in with the other 6xx based boards. Twiddle the Kconfigs to allow this. This allows us to remove the machine type selection for related to 6xx. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Added 82xx into multiplatform and removed Machine Type as a choice so there is only one choice now. arch/powerpc/platforms/82xx/Kconfig | 11 ++- arch/powerpc/platforms/83xx/Kconfig | 10 ++ arch/powerpc/platforms/86xx/Kconfig | 16 +++- arch/powerpc/platforms/Kconfig | 33 +++-- 4 files changed, 26 insertions(+), 44 deletions(-) diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig index 917ac88..1c8034b 100644 --- a/arch/powerpc/platforms/82xx/Kconfig +++ b/arch/powerpc/platforms/82xx/Kconfig @@ -1,7 +1,8 @@ -choice - prompt 82xx Board Type - depends on PPC_82xx - default MPC8272_ADS +menuconfig PPC_82xx + bool 82xx-based boards (PQ II) + depends on 6xx PPC_MULTIPLATFORM + +if PPC_82xx config MPC8272_ADS bool Freescale MPC8272 ADS @@ -36,7 +37,7 @@ config EP8248E This board is also resold by Freescale as the QUICCStart MPC8248 Evaluation System and/or the CWH-PPC-8248N-VE. -endchoice +endif config PQ2ADS bool diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index fe75b2a..27d9bf8 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -1,10 +1,12 @@ -menuconfig MPC83xx - bool 83xx Board Type - depends on PPC_83xx +menuconfig PPC_83xx + bool 83xx-based boards + depends on 6xx PPC_MULTIPLATFORM select PPC_UDBG_16550 select PPC_INDIRECT_PCI + select FSL_SOC + select IPIC -if MPC83xx +if PPC_83xx config MPC831x_RDB bool Freescale MPC831x RDB diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig index 053f49a..80a81e0 100644 --- a/arch/powerpc/platforms/86xx/Kconfig +++ b/arch/powerpc/platforms/86xx/Kconfig @@ -1,7 +1,13 @@ -choice - prompt 86xx Board Type - depends on PPC_86xx - default MPC8641_HPCN +config PPC_86xx +menuconfig PPC_86xx + bool 86xx-based boards + depends on 6xx PPC_MULTIPLATFORM + select FSL_SOC + select ALTIVEC + help + The Freescale E600 SoCs have 74xx cores. + +if PPC_86xx config MPC8641_HPCN bool Freescale MPC8641 HPCN @@ -24,7 +30,7 @@ config MPC8610_HPCD help This option enables support for the MPC8610 HPCD board. -endchoice +endif config MPC8641 bool diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 87454c5..690c1f4 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -1,36 +1,9 @@ menu Platform support -choice - prompt Machine type - depends on PPC64 || 6xx - default PPC_MULTIPLATFORM - config PPC_MULTIPLATFORM - bool Generic desktop/server/laptop - help - Select this option if configuring for an IBM pSeries or - RS/6000 machine, an Apple machine, or a PReP, CHRP, - Maple or Cell-based machine. - -config PPC_82xx - bool Freescale 82xx - depends on 6xx - -config PPC_83xx - bool Freescale 83xx - depends on 6xx - select FSL_SOC - select MPC83xx - select IPIC - -config PPC_86xx - bool Freescale 86xx - depends on 6xx - select FSL_SOC - select ALTIVEC - help - The Freescale E600 SoCs have 74xx cores. -endchoice + bool + depends on PPC64 || 6xx + default y config CLASSIC32 def_bool y -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add 83xx and 86xx to 6xx Multiplatform
On Friday 27 June 2008, Scott Wood wrote: On Fri, Jun 27, 2008 at 11:36:36AM -0500, Kumar Gala wrote: There isn't any reason at this point that we can't build 83xx 86xx support in with the other 6xx based boards. Â Twiddle the Kconfigs to allow this. Likewise with 82xx -- why don't we just get rid of the Machine type choice, and turn them all into bools? I started looking for possible problems with hardcoded settings for some of the platforms, and the only code that looked suspicious in this regard was CPM2, but it turned out that this was all because of code built without CONFIG_PPC_CPM_NEW_BINDING, which is practically gone in kumar's powerpc-next branch. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add 83xx and 86xx to 6xx Multiplatform
On Jun 27, 2008, at 2:35 PM, Arnd Bergmann wrote: On Friday 27 June 2008, Scott Wood wrote: On Fri, Jun 27, 2008 at 11:36:36AM -0500, Kumar Gala wrote: There isn't any reason at this point that we can't build 83xx 86xx support in with the other 6xx based boards. Twiddle the Kconfigs to allow this. Likewise with 82xx -- why don't we just get rid of the Machine type choice, and turn them all into bools? I started looking for possible problems with hardcoded settings for some of the platforms, and the only code that looked suspicious in this regard was CPM2, but it turned out that this was all because of code built without CONFIG_PPC_CPM_NEW_BINDING, which is practically gone in kumar's powerpc-next branch. I've posted patches to remove CONFIG_PPC_CPM_NEW_BINDING, and just holding off on the enet ones to see how merging goes w/Jeff. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add dma nodes to 83xx, 85xx and 86xx boards
Added DMA nodes for the elo/elo-plus DMA engines.
Renamed the interrupt controller alias in mpc832x_rdb.dts to ipic so that
its the same as all the other boards.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
In my powerpc-next branch.
- k
arch/powerpc/boot/dts/asp834x-redboot.dts | 37 -
arch/powerpc/boot/dts/ksi8560.dts | 41 ++
arch/powerpc/boot/dts/mpc8313erdb.dts | 37 -
arch/powerpc/boot/dts/mpc8315erdb.dts | 37 -
arch/powerpc/boot/dts/mpc832x_mds.dts | 35
arch/powerpc/boot/dts/mpc832x_rdb.dts | 71 ++--
arch/powerpc/boot/dts/mpc8349emitx.dts | 35
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 35
arch/powerpc/boot/dts/mpc834x_mds.dts | 35
arch/powerpc/boot/dts/mpc836x_mds.dts | 35
arch/powerpc/boot/dts/mpc836x_rdk.dts | 35
arch/powerpc/boot/dts/mpc8377_mds.dts | 70
arch/powerpc/boot/dts/mpc8377_rdb.dts | 35
arch/powerpc/boot/dts/mpc8378_mds.dts | 37 -
arch/powerpc/boot/dts/mpc8378_rdb.dts | 37 -
arch/powerpc/boot/dts/mpc8379_mds.dts | 37 -
arch/powerpc/boot/dts/mpc8379_rdb.dts | 37 -
arch/powerpc/boot/dts/mpc8540ads.dts | 41 ++
arch/powerpc/boot/dts/mpc8541cds.dts | 41 ++
arch/powerpc/boot/dts/mpc8548cds.dts | 41 ++
arch/powerpc/boot/dts/mpc8555cds.dts | 41 ++
arch/powerpc/boot/dts/mpc8560ads.dts | 41 ++
arch/powerpc/boot/dts/mpc8568mds.dts | 41 ++
arch/powerpc/boot/dts/mpc8572ds.dts| 82
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 41 ++
arch/powerpc/boot/dts/sbc8349.dts | 35
arch/powerpc/boot/dts/sbc8548.dts | 41 ++
arch/powerpc/boot/dts/sbc8560.dts | 41 ++
arch/powerpc/boot/dts/sbc8641d.dts | 41 ++
arch/powerpc/boot/dts/stx_gp3_8560.dts | 41 ++
arch/powerpc/boot/dts/tqm8540.dts | 41 ++
arch/powerpc/boot/dts/tqm8541.dts | 41 ++
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 41 ++
arch/powerpc/boot/dts/tqm8548.dts | 41 ++
arch/powerpc/boot/dts/tqm8555.dts | 41 ++
arch/powerpc/boot/dts/tqm8560.dts | 41 ++
36 files changed, 1440 insertions(+), 60 deletions(-)
diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts
b/arch/powerpc/boot/dts/asp834x-redboot.dts
index 972cf78..d140031 100644
--- a/arch/powerpc/boot/dts/asp834x-redboot.dts
+++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
@@ -53,7 +53,7 @@
fsl,pq2pro-localbus,
simple-bus;
reg = 0xff005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 47 0x8;
interrupt-parent = ipic;
ranges =
@@ -118,6 +118,41 @@
mode = cpu;
};
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8347-dma, fsl,elo-dma;
+ reg = 0x82a8 4;
+ ranges = 0 0x8100 0x1a8;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ cell-index = 0;
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x80 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x100 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x180 0x28;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ };
+
Re: [PATCH] POWERPC CPM: Minor cosmetic changes to udbg_putc
Nye Liu wrote: udbg_putc is a *function pointer* that is initialized during udbg_init_cpm. It might not be initialized properly when called from udbg_putc_cpm(), so (recursively) call udbg_putc_cpm() directly. ACK Printing an X on initialization is ugly. How about a \n instead? D'oh, that was a debugging leftover that I missed when cleaning things up. Just remove it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add dma nodes to 83xx, 85xx and 86xx boards
Kumar Gala wrote:
diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts
b/arch/powerpc/boot/dts/asp834x-redboot.dts
index 972cf78..d140031 100644
--- a/arch/powerpc/boot/dts/asp834x-redboot.dts
+++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
@@ -53,7 +53,7 @@
fsl,pq2pro-localbus,
simple-bus;
reg = 0xff005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 47 0x8;
interrupt-parent = ipic;
ranges =
This is wrong (LBC is IRQ 77; IRQ 47 is reserved), and wasn't mentioned
in the patch description...
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index e1f0dca..ae2c4aa 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -52,7 +52,7 @@
#size-cells = 1;
compatible = fsl,mpc8313-elbc, fsl,elbc, simple-bus;
reg = 0xe0005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 13 0x8;
interrupt-parent = ipic;
Likewise. 13 is the 1588 timer IRQ.
@@ -51,7 +51,7 @@
#size-cells = 1;
compatible = fsl,mpc8315-elbc, fsl,elbc, simple-bus;
reg = 0xe0005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 15 0x8;
I2C this time. :-P
@@ -303,6 +268,41 @@
};
};
+ [EMAIL PROTECTED] {
+ model = SEC3;
+ compatible = talitos;
+ reg = 0x3 0x1;
+ interrupts = 11 0x8;
+ interrupt-parent = ipic;
+ /* Rev. 3.0 geometry */
+ num-channels = 4;
+ channel-fifo-len = 24;
+ exec-units-mask = 0x01fe;
+ descriptor-types-mask = 0x03ab0ebf;
+ };
+
+ [EMAIL PROTECTED] {
+ model = eSDHC;
+ compatible = fsl,esdhc;
+ reg = 0x2e000 0x1000;
+ interrupts = 42 0x8;
+ interrupt-parent = ipic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8379-sata, fsl,pq-sata;
+ reg = 0x18000 0x1000;
+ interrupts = 44 0x8;
+ interrupt-parent = ipic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8379-sata, fsl,pq-sata;
+ reg = 0x19000 0x1000;
+ interrupts = 45 0x8;
+ interrupt-parent = ipic;
+ };
Doesn't match the changelog, and the crypto binding is old.
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts
b/arch/powerpc/boot/dts/mpc8378_mds.dts
index 1d6ea08..5d57f5d 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -52,7 +52,7 @@
#size-cells = 1;
compatible = fsl,mpc8378-elbc, fsl,elbc, simple-bus;
reg = 0xe0005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 78 0x8;
Another mangled localbus interrupt (and more after this).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: issue with kgdb on ppc
Hello I got the gianfar.c patch and enabled CONFIG_NETCONSOLE and now i'm able to connect kgdb and gdb. But when i try to cont in gdb, the system tries to load the rootfs but fails and trys to reboot. Can someone please provide some help on this. dump: (gdb) c Continuing. RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device ram=rw or unknown-block(2,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) total:used:free: shared: buffers: cached: Mem: 1060827136 226791424 8340357120 219955200 8192 Swap:000 MemTotal: 1035964 kB MemFree:814488 kB MemShared: 0 kB Buffers:214800 kB Cached: 8 kB SwapCached: 0 kB Active: 0 kB Inactive:0 kB HighTotal: 1035964 kB HighFree: 814488 kB LowTotal:0 kB LowFree: 0 kB SwapTotal:8192 kB SwapFree:0 kB [New Thread 1] Program received signal SIGTRAP, Trace/breakpoint trap. 0x8003c0d8 in breakpoint () at kernel/kgdb.c:1773 1773wmb(); (gdb) Thanks On Thu, Jun 26, 2008 at 2:53 PM, SEEMA pm [EMAIL PROTECTED] wrote: Hello I'm trying to get kgdb working on a mpc8540 based target machine. I took the latest patches which are for 2.6.13(mine is 2.6.11) and build and made changes to config by enabling : - Compile the kernel with debug info - KGDB: kernel debugging with remote gdb - KGDB: Console messages through gdb - Method for KGDB communication (KGDB: On ethernet - in kernel) I also added bootargs through uboot as: [EMAIL PROTECTED]/,[EMAIL PROTECTED]/00:0F:1F:6E:F3:30 kgdbwait Now, I'm getting the messages: netconsole: not configured, aborting kgdboe: eth0 doesn't support polling, aborting. kgdboe: netpoll_setup failed kgdboe failed And after some lines; kgdb: Defering I/O setup to kernel module. kgdb: Waiting for connection from remote gdb... But then it goes to load ramdisk. Can someone please provide some help on this thanks ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] FS_ENET: Don't attempt to set mii_speed when fec_inf is null
From: Nye Liu [EMAIL PROTECTED] When using CONFIG_FIXED_PHY, fec_inf (fep-phydev-bus-priv) is NULL in fs_enet/mac-fec.c restart(). Dereferencing fec_inf when trying to set the mii_speed causes a kernel oops. Signed-off-by: Nye Liu [EMAIL PROTECTED] --- diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c index 8a311d1..350bc73 100644 --- a/drivers/net/fs_enet/mac-fec.c +++ b/drivers/net/fs_enet/mac-fec.c @@ -328,7 +328,8 @@ static void restart(struct net_device *dev) /* * Set MII speed. */ - FW(fecp, mii_speed, fec_inf-mii_speed); + if (fec_inf) + FW(fecp, mii_speed, fec_inf-mii_speed); /* * Clear any outstanding interrupt. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC CPM: Minor cosmetic changes to udbg_putc
From: Nye Liu [EMAIL PROTECTED]
udbg_putc is a *function pointer* that is initialized during
udbg_init_cpm. It might not be initialized properly when called from
udbg_putc_cpm(), so (recursively) call udbg_putc_cpm() directly.
Printing an X on initialization is ugly. How about a \n instead?
Signed-off-by: Nye Liu [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..dcde743 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -37,7 +37,7 @@ static void udbg_putc_cpm(char c)
u8 __iomem *txbuf = (u8 __iomem __force *)in_be32(cpm_udbg_txdesc[1]);
if (c == '\n')
- udbg_putc('\r');
+ udbg_putc_cpm('\r');
while (in_be32(cpm_udbg_txdesc[0]) 0x8000)
;
@@ -53,7 +53,7 @@ void __init udbg_init_cpm(void)
setbat(1, 0xf000, 0xf000, 1024*1024, _PAGE_IO);
#endif
udbg_putc = udbg_putc_cpm;
- udbg_putc('X');
+ udbg_putc('\n');
}
}
#endif
--
Nye Liu
[EMAIL PROTECTED]
(818) 772-6235x248
(818) 772-0576 fax
Who would be stupid enough to quote a fictitious character?
-- Don Quixote
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] asm/ptrace.h userspace headers cleanup
That all looks fine to me, though I won't claim to have paid close attention to the nits in the various odd archs' files. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add dma nodes to 83xx, 85xx and 86xx boards
On Jun 27, 2008, at 3:28 PM, Scott Wood wrote:
Kumar Gala wrote:
diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts b/arch/
powerpc/boot/dts/asp834x-redboot.dts
index 972cf78..d140031 100644
--- a/arch/powerpc/boot/dts/asp834x-redboot.dts
+++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
@@ -53,7 +53,7 @@
fsl,pq2pro-localbus,
simple-bus;
reg = 0xff005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 47 0x8;
interrupt-parent = ipic;
ranges =
This is wrong (LBC is IRQ 77; IRQ 47 is reserved), and wasn't
mentioned in the patch description...
This was a search/replace mistake.
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/
boot/dts/mpc8313erdb.dts
index e1f0dca..ae2c4aa 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -52,7 +52,7 @@
#size-cells = 1;
compatible = fsl,mpc8313-elbc, fsl,elbc, simple-bus;
reg = 0xe0005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 13 0x8;
interrupt-parent = ipic;
Likewise. 13 is the 1588 timer IRQ.
@@ -51,7 +51,7 @@
#size-cells = 1;
compatible = fsl,mpc8315-elbc, fsl,elbc, simple-bus;
reg = 0xe0005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 15 0x8;
I2C this time. :-P
ditto, ditto. thanks for catching them.
@@ -303,6 +268,41 @@
};
};
+ [EMAIL PROTECTED] {
+ model = SEC3;
+ compatible = talitos;
+ reg = 0x3 0x1;
+ interrupts = 11 0x8;
+ interrupt-parent = ipic;
+ /* Rev. 3.0 geometry */
+ num-channels = 4;
+ channel-fifo-len = 24;
+ exec-units-mask = 0x01fe;
+ descriptor-types-mask = 0x03ab0ebf;
+ };
+
+ [EMAIL PROTECTED] {
+ model = eSDHC;
+ compatible = fsl,esdhc;
+ reg = 0x2e000 0x1000;
+ interrupts = 42 0x8;
+ interrupt-parent = ipic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8379-sata, fsl,pq-sata;
+ reg = 0x18000 0x1000;
+ interrupts = 44 0x8;
+ interrupt-parent = ipic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8379-sata, fsl,pq-sata;
+ reg = 0x19000 0x1000;
+ interrupts = 45 0x8;
+ interrupt-parent = ipic;
+ };
Doesn't match the changelog, and the crypto binding is old.
Its because diff doesn't like the fact that I moved the dma node up.
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/
boot/dts/mpc8378_mds.dts
index 1d6ea08..5d57f5d 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -52,7 +52,7 @@
#size-cells = 1;
compatible = fsl,mpc8378-elbc, fsl,elbc, simple-bus;
reg = 0xe0005000 0x1000;
- interrupts = 77 0x8;
+ interrupts = 78 0x8;
Another mangled localbus interrupt (and more after this).
I think I got them all.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Add dma nodes to 83xx, 85xx and 86xx boards
Added DMA nodes for the elo/elo-plus DMA engines.
Renamed the interrupt controller alias in mpc832x_rdb.dts to ipic so that
its the same as all the other boards.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Some copy/paste bugs are now fixed (thanks Scott for actually looking at the
patch).
- k
arch/powerpc/boot/dts/asp834x-redboot.dts | 35
arch/powerpc/boot/dts/ksi8560.dts | 41 ++
arch/powerpc/boot/dts/mpc8313erdb.dts | 35
arch/powerpc/boot/dts/mpc8315erdb.dts | 35
arch/powerpc/boot/dts/mpc832x_mds.dts | 35
arch/powerpc/boot/dts/mpc832x_rdb.dts | 71 ++--
arch/powerpc/boot/dts/mpc8349emitx.dts | 35
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 35
arch/powerpc/boot/dts/mpc834x_mds.dts | 35
arch/powerpc/boot/dts/mpc836x_mds.dts | 35
arch/powerpc/boot/dts/mpc836x_rdk.dts | 35
arch/powerpc/boot/dts/mpc8377_mds.dts | 70
arch/powerpc/boot/dts/mpc8377_rdb.dts | 35
arch/powerpc/boot/dts/mpc8378_mds.dts | 35
arch/powerpc/boot/dts/mpc8378_rdb.dts | 35
arch/powerpc/boot/dts/mpc8379_mds.dts | 35
arch/powerpc/boot/dts/mpc8379_rdb.dts | 35
arch/powerpc/boot/dts/mpc8540ads.dts | 41 ++
arch/powerpc/boot/dts/mpc8541cds.dts | 41 ++
arch/powerpc/boot/dts/mpc8548cds.dts | 41 ++
arch/powerpc/boot/dts/mpc8555cds.dts | 41 ++
arch/powerpc/boot/dts/mpc8560ads.dts | 41 ++
arch/powerpc/boot/dts/mpc8568mds.dts | 41 ++
arch/powerpc/boot/dts/mpc8572ds.dts| 82
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 41 ++
arch/powerpc/boot/dts/sbc8349.dts | 35
arch/powerpc/boot/dts/sbc8548.dts | 41 ++
arch/powerpc/boot/dts/sbc8560.dts | 41 ++
arch/powerpc/boot/dts/sbc8641d.dts | 41 ++
arch/powerpc/boot/dts/stx_gp3_8560.dts | 41 ++
arch/powerpc/boot/dts/tqm8540.dts | 41 ++
arch/powerpc/boot/dts/tqm8541.dts | 41 ++
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 41 ++
arch/powerpc/boot/dts/tqm8548.dts | 41 ++
arch/powerpc/boot/dts/tqm8555.dts | 41 ++
arch/powerpc/boot/dts/tqm8560.dts | 41 ++
36 files changed, 1433 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts
b/arch/powerpc/boot/dts/asp834x-redboot.dts
index 972cf78..8b1bb0e 100644
--- a/arch/powerpc/boot/dts/asp834x-redboot.dts
+++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
@@ -118,6 +118,41 @@
mode = cpu;
};
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8347-dma, fsl,elo-dma;
+ reg = 0x82a8 4;
+ ranges = 0 0x8100 0x1a8;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ cell-index = 0;
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x80 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x100 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8347-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x180 0x28;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ };
+
/* phy type (ULPI or SERIAL) are only types supported for MPH */
/* port = 0 or 1 */
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/ksi8560.dts
b/arch/powerpc/boot/dts/ksi8560.dts
index
Re: [PATCH] FS_ENET: Don't attempt to set mii_speed when fec_inf is null
Hello. Nye Liu wrote: From: Nye Liu [EMAIL PROTECTED] When using CONFIG_FIXED_PHY, fec_inf (fep-phydev-bus-priv) is NULL in fs_enet/mac-fec.c restart(). Dereferencing fec_inf when trying to set the mii_speed causes a kernel oops. Signed-off-by: Nye Liu [EMAIL PROTECTED] --- diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c index 8a311d1..350bc73 100644 --- a/drivers/net/fs_enet/mac-fec.c +++ b/drivers/net/fs_enet/mac-fec.c @@ -328,7 +328,8 @@ static void restart(struct net_device *dev) /* * Set MII speed. */ - FW(fecp, mii_speed, fec_inf-mii_speed); + if (fec_inf) + FW(fecp, mii_speed, fec_inf-mii_speed); Alas, Your patch is whitespace damaged. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] FS_ENET: Don't attempt to set mii_speed when fec_inf is null
Sorry! diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c index 8a311d1..7359068 100644 --- a/drivers/net/fs_enet/mac-fec.c +++ b/drivers/net/fs_enet/mac-fec.c @@ -328,7 +328,8 @@ static void restart(struct net_device *dev) /* * Set MII speed. */ - FW(fecp, mii_speed, fec_inf-mii_speed); + if (fec_inf) + FW(fecp, mii_speed, fec_inf-mii_speed); /* * Clear any outstanding interrupt. On Sat, Jun 28, 2008 at 01:29:16AM +0400, Sergei Shtylyov wrote: Hello. Nye Liu wrote: From: Nye Liu [EMAIL PROTECTED] When using CONFIG_FIXED_PHY, fec_inf (fep-phydev-bus-priv) is NULL in fs_enet/mac-fec.c restart(). Dereferencing fec_inf when trying to set the mii_speed causes a kernel oops. Signed-off-by: Nye Liu [EMAIL PROTECTED] --- diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c index 8a311d1..350bc73 100644 --- a/drivers/net/fs_enet/mac-fec.c +++ b/drivers/net/fs_enet/mac-fec.c @@ -328,7 +328,8 @@ static void restart(struct net_device *dev) /* * Set MII speed. */ - FW(fecp, mii_speed, fec_inf-mii_speed); + if (fec_inf) + FW(fecp, mii_speed, fec_inf-mii_speed); Alas, Your patch is whitespace damaged. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] FS_ENET: Don't attempt to set mii_speed when fec_inf is null
From: Nye Liu [EMAIL PROTECTED] When using CONFIG_FIXED_PHY, fec_inf (fep-phydev-bus-priv) is NULL in fs_enet/mac-fec.c restart(). Dereferencing fec_inf when trying to set the mii_speed causes a kernel oops. Signed-off-by: Nye Liu [EMAIL PROTECTED] --- diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c index 8a311d1..7359068 100644 --- a/drivers/net/fs_enet/mac-fec.c +++ b/drivers/net/fs_enet/mac-fec.c @@ -328,7 +328,8 @@ static void restart(struct net_device *dev) /* * Set MII speed. */ - FW(fecp, mii_speed, fec_inf-mii_speed); + if (fec_inf) + FW(fecp, mii_speed, fec_inf-mii_speed); /* * Clear any outstanding interrupt. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V2] Keep 3 high personality bytes across exec
Currently when a 32 bit process is exec'd on a powerpc 64 bit host the value
in the top three bytes of the personality is clobbered. This patch adds a
check in the SET_PERSONALITY macro that will carry all the values in the top
three bytes across the exec.
These three bytes currently carry flags to disable address randomisation,
limit the address space, force zeroing of an mmapped page, etc. Should an
application set any of these bits they will be maintained and honoured on
homogeneous environment but discarded and ignored on a heterogeneous
environment. So if an application requires all mmapped pages to be initialised
to zero and a wrapper is used to setup the personality and exec the target,
these flags will remain set on an all 32 or all 64 bit envrionment, but they
will be lost in the exec on a mixed 32/64 bit environment. Losing these bits
means that the same application would behave differently in different
environments. Tested on a POWER5+ machine with 64bit kernel and a mixed
64/32 bit user space.
Signed-off-by: Eric B Munson [EMAIL PROTECTED]
---
V2
Changes from V1:
Updated changelog with a better description of why this change is useful
Based on 2.6.26-rc6
include/asm-powerpc/elf.h |3 ++-
include/linux/personality.h |6 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index 9080d85..2f11a0e 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -257,7 +257,8 @@ do {
\
else\
clear_thread_flag(TIF_ABI_PENDING); \
if (personality(current-personality) != PER_LINUX32) \
- set_personality(PER_LINUX); \
+ set_personality(PER_LINUX | \
+ (current-personality PER_INHERIT)); \
} while (0)
/*
* An executable for which elf_read_implies_exec() returns TRUE will
diff --git a/include/linux/personality.h b/include/linux/personality.h
index a84e9ff..362eb90 100644
--- a/include/linux/personality.h
+++ b/include/linux/personality.h
@@ -36,6 +36,12 @@ enum {
ADDR_LIMIT_3GB =0x800,
};
+/* Mask for the above personality values */
+#define PER_INHERIT (ADDR_NO_RANDOMIZE|FDPIC_FUNCPTRS|MMAP_PAGE_ZERO| \
+ ADDR_COMPAT_LAYOUT|READ_IMPLIES_EXEC|ADDR_LIMIT_32BIT| \
+ SHORT_INODE|WHOLE_SECONDS|STICKY_TIMEOUTS| \
+ ADDR_LIMIT_3GB)
+
/*
* Security-relevant compatibility flags that must be
* cleared upon setuid or setgid exec:
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Address an assortment of portability problems
On Fri, Jun 27, 2008 at 09:53:03AM -0500, Scott Wood wrote: David Gibson wrote: On Thu, Jun 26, 2008 at 10:25:28AM -0500, Scott Wood wrote: On Thu, Jun 26, 2008 at 11:03:49AM +1000, David Gibson wrote: - the endian handling functions in libfdt_env.h, based on endian.h and byteswap.h are replaced with some portable open-coded versions. Unfortunately, these result in fairly crappy code when compiled, but as far as I can determine there doesn't seem to be any POSIX, SUS or de facto standard way of determining endianness at compile time, nor standard names for byteswapping functions. Since device-tree and network byte order happen to be the same, we could use ntohl/htonl. Not for the 64-bit version. Why? They operate on uint32_t despite the l in the name, and there are no 64-bit fields in the device tree... Yes there are. The memory reservations. We have and need fdt64_to_cpu(). -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/60] microblaze_v4: Kconfig patches
On Thu, Jun 26, 2008 at 02:29:30PM +0200, [EMAIL PROTECTED] wrote: +config HZ + int + default 100 + Consider using kernel/Kconfig.hz instead. +config DEFCONFIG_LIST + string + default arch/$ARCH/defconfig + init/Kconfig already has quite a few reasonable defaults for this, including the case you specify. You can kill this off. +source init/Kconfig + +source arch/microblaze/platform/Kconfig.platform + +menu Processor type and features + +config PREEMPT + bool Preemptible Kernel + help + This option reduces the latency of the kernel when reacting to + real-time or interactive events by allowing a low priority process to + be preempted even if it is in kernel mode executing a system call. + This allows applications to run more reliably even when the system is + under load. + + Say Y here if you are building a kernel for a desktop, embedded + or real-time system. Say N if you are unsure. + kernel/Kconfig.preempt +config LARGE_ALLOCS + bool Allow allocating large blocks ( 1MB) of memory + help + Allow the slab memory allocator to keep chains for very large + memory sizes - up to 32MB. You may need this if your system has + a lot of RAM, and you need to able to allocate very large + contiguous chunks. If unsure, say N. + Legacy bits, not used anywhere anymore. +comment Boot options + +config CMDLINE + string Default kernel command string + default + help + On some architectures there is currently no way for the boot loader + to pass arguments to the kernel. For these architectures, you should + supply some command-line options at build time by entering them + here. + +config CMDLINE_FORCE + bool Force default kernel command string + help + Set this to have arguments from the default kernel command string + override those passed by the boot loader. + Consider CMDLINE_BOOL/CMDLINE for consistency with other architectures. It doesn't make much sense to expose CMDLINE if you don't intend to use it. Especially when people wonder why their CMDLINE changes are being clobbered by the boot loader. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 24/60] microblaze_v4: asm-offsets
On Thu, Jun 26, 2008 at 02:29:53PM +0200, [EMAIL PROTECTED] wrote: +#include linux/stddef.h +#include linux/sched.h +#include linux/kernel_stat.h +#include linux/ptrace.h +#include linux/hardirq.h +#include linux/thread_info.h + +#define DEFINE(sym, val) asm volatile(\n- #sym %0 #val : : i (val)) +#define BLANK() asm volatile(\n- : :) + There are generic definitions for these these days, include linux/kbuild.h. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 25/60] microblaze_v4: process and init task function
On Thu, Jun 26, 2008 at 02:29:54PM +0200, [EMAIL PROTECTED] wrote:
+void (*pm_power_off)(void) = NULL;
+EXPORT_SYMBOL(pm_power_off);
+
+void cpu_idle(void)
+{
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
+ while (1) {
+ while (!need_resched())
+ cpu_relax();
+
+ preempt_enable_no_resched();
+ schedule();
+ preempt_disable();
+ }
+}
+
A couple things to note here. You have a pm_power_off, but no pm_idle.
You set TIF_POLLING_NRFLAG but don't have any explicit clearing and
resetting of it if the CPU is sleeping. In the cpu_relax() case this is
ok, but if you have a cpu_sleep() you will want to use in the SMP case,
you will need to handle it explicitly.
Beyond that, you may also want to stub in the
tick_nohz_stop_sched_tick()/tick_nohz_restart_sched_tick() calls, then
when you implement the generic clockevents you will already have the
tickless bits in place.
check_pgt_cache() is also helpful here for quicklist trimming, though you
may not care if you never plan to have an MMU.
You can look at arch/sh/kernel/process_32.c for examples.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 28/60] microblaze_v4: ptrace support
On Thu, Jun 26, 2008 at 02:29:57PM +0200, [EMAIL PROTECTED] wrote:
+long arch_ptrace(struct task_struct *child, long request, long addr, long
data)
+{
+ int rval;
+
+ switch (request) {
+ unsigned long val, copied;
+
+ case PTRACE_PEEKTEXT: /* read word at location addr. */
+ case PTRACE_PEEKDATA:
+ pr_debug(PEEKTEXT/PEEKDATA at %08lX\n, addr);
+ copied = access_process_vm(child, addr, val, sizeof(val), 0);
+ rval = -EIO;
+ if (copied != sizeof(val))
+ break;
+ rval = put_user(val, (unsigned long *)data);
+ goto out;
+
+ case PTRACE_POKETEXT: /* write the word at location addr. */
+ case PTRACE_POKEDATA:
+ pr_debug(POKETEXT/POKEDATA to %08lX\n, addr);
+ rval = 0;
+ if (access_process_vm(child, addr, data, sizeof(data), 1)
+ == sizeof(data))
+ break;
+ rval = -EIO;
+ goto out;
+
You can use generic_ptrace_peekdata()/generic_ptrace_pokedata() for
these. Or kill them off and let ptrace_request() handle it.
+ /* Continue and stop at next (return from) syscall */
+ case PTRACE_SYSCALL:
+ pr_debug(PTRACE_SYSCALL\n);
+ case PTRACE_SINGLESTEP:
+ pr_debug(PTRACE_SINGLESTEP\n);
+ /* Restart after a signal. */
+ case PTRACE_CONT:
+ pr_debug(PTRACE_CONT\n);
+ rval = -EIO;
+ if (!valid_signal(data))
+ break;
+
+ if (request == PTRACE_SYSCALL)
+ set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
+ else
+ clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
+
+ child-exit_code = data;
+ pr_debug(wakeup_process\n);
+ wake_up_process(child);
+ rval = 0;
+ break;
+
This is a reimplementation of ptrace_resume(), you can kill all of these
off as well, as they are also handled generically these days.
+ /*
+ * make the child exit. Best I can do is send it a sigkill.
+ * perhaps it should be put in the status that it wants to
+ * exit.
+ */
+ case PTRACE_KILL:
+ pr_debug(PTRACE_KILL\n);
+ rval = 0;
+ if (child-exit_state == EXIT_ZOMBIE) /* already dead */
+ break;
+ child-exit_code = SIGKILL;
+ wake_up_process(child);
+ break;
+
+ case PTRACE_DETACH: /* detach a process that was attached. */
+ pr_debug(PTRACE_DETACH\n);
+ rval = ptrace_detach(child, data);
+ break;
+
+ default:
+ rval = -EIO;
+ goto out;
+ }
+ out:
+ return rval;
+}
+
Or rather, they would be, if you defaulted to ptrace_request() for the
unhandled cases.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc/bootwrapper: Add documentation of boot wrapper targets
From: Grant Likely [EMAIL PROTECTED] There have been many questions on and off the mailing list about how exactly the bootwrapper is used for embedded targets. Add some documentation and help text to try and clarify the system. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- Documentation/powerpc/bootwrapper.txt | 141 + arch/powerpc/Makefile | 15 +++- arch/powerpc/boot/wrapper |4 + 3 files changed, 159 insertions(+), 1 deletions(-) diff --git a/Documentation/powerpc/bootwrapper.txt b/Documentation/powerpc/bootwrapper.txt new file mode 100644 index 000..a03d73c --- /dev/null +++ b/Documentation/powerpc/bootwrapper.txt @@ -0,0 +1,141 @@ +The PowerPC boot wrapper + +Copyright (C) Secret Lab Technologies Ltd. + +PowerPC image targets compresses and wraps the kernel image (vmlinux) with +a boot wrapper to make it usable by the system firmware. There is no +standard PowerPC firmware interface, so the boot wrapper is designed to +be adaptable for each kind of image that needs to be built. + +The boot wrapper can be found in the arch/powerpc/boot/ directory. The +Makefile in that directory has targets for all the available image types. +The different image types are used to support all of the various firmware +interfaces found on PowerPC platforms. OpenFirmware is the most commonly +used firmare type on general purpose PowerPC systems from Apple, IBM and +others. U-Boot is typically found on embedded PowerPC hardware, but there +are a handful of other firmware implementations which are also popular. Each +firmware interface requires a different image format. + +The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and +it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target +image. The details of the build system is discussed in the next section. +Currently, the following image format targets exist: + + cuImage.%: Backwards compatible uImage for older version of + U-Boot (for versions that don't understand the device + tree). This image embeds a device tree blob inside + the image. The bootwrapper, kernel and device tree + are all embedded inside the U-Boot uImage file format + with bootwrapper code that extracts data from the old + bd_info structure and loads the data into the device + tree before jumping into the kernel. + Because of the series of #ifdefs found in the + bd_info structure used in the old U-Boot interfaces, + cuImages are platform specific. Each specific + U-Boot platform has a different platform init file + which populates the embedded device tree with data + from the platform specific bd_info file. The platform + specific cuImage platform init code can be found in + arch/powerpc/boot/cuboot.*.c. Selection of the correct + cuImage init code for a specific board can be found in + the wrapper structure. + dtbImage.%: Similar to zImage, except device tree blob is embedded + inside the image instead of provided by firmware. The + output image file can be either an elf file or a flat + binary depending on the platform. + dtbImages are used on systems which do not have an + interface for passing a device tree directly. + dtbImages are similar to simpleImages except that + dtbImages have platform specific code for extracting + data from the board firmware, but simpleImages do not + talk to the firmware at all. + PlayStation 3 support uses dtbImage. So do Embedded + Planet boards using the PlanetCore firmware. Board + specific initialization code is typically found in a + file named arch/powerpc/boot/platform.c; but this + can be overridden by the wrapper script. + simpleImage.%: Firmware independent compressed image that does not + depend on any particular firmware interface and embeds + a device tree blob. This image is a flat binary that + can be loaded to any location in RAM and jumped to. + Firmware cannot pass any configuration data to the + kernel with this image type and it depends entirely on + the embedded device tree for all information. + The simpleImage is useful for booting
Re: [PATCH 29/60] microblaze_v4: traps support
On Thu, Jun 26, 2008 at 02:29:58PM +0200, [EMAIL PROTECTED] wrote:
+static int kstack_depth_to_print = 24;
+
x86 has a sysctl for this. It may be worth making this non-static and
generalizing the ifdef case. Plenty of other architectures could benefit
from this also.
+void show_trace(struct task_struct *task, unsigned long *stack)
+{
+ unsigned long addr;
+
+ if (!stack)
+ stack = (unsigned long *)stack;
+
+ printk(KERN_INFO Call Trace: );
+#ifdef CONFIG_KALLSYMS
+ printk(KERN_INFO \n);
+#endif
+ while (!kstack_end(stack)) {
+ addr = *stack++;
+ if (__kernel_text_address(addr)) {
+ printk(KERN_INFO [%08lx] , addr);
+ print_symbol(%s\n, addr);
Use print_ip_sym() here for future-proofing.
+ }
+ }
+ printk(KERN_INFO \n);
And here you can:
if (!tsk)
tsk = current;
debug_show_held_locks(tsk);
+}
+
for when you get around to implementing lockdep.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 30/60] microblaze_v4: support for a.out
On Thu, Jun 26, 2008 at 02:29:59PM +0200, [EMAIL PROTECTED] wrote: From: Michal Simek [EMAIL PROTECTED] Signed-off-by: Michal Simek [EMAIL PROTECTED] --- 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 include/asm-microblaze/a.out.h a.out is going away for the users that don't care, so you may wish to make sure all of your a.out references are also gone so you don't have to patch this a second time. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 59/60] microblaze_v4: syscall_table.S and unistd.h
On Thu, Jun 26, 2008 at 02:30:28PM +0200, [EMAIL PROTECTED] wrote: +#define __NR_semtimedop 325 +#define __NR_timerfd_settime 326 +#define __NR_timerfd_gettime 327 + +#ifdef __KERNEL__ + +#define __NR_syscalls327 + Off-by-1 on __NR_syscalls, this should be 328. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] update crypto node definition and device tree instances
On Fri, Jun 27, 2008 at 9:52 AM, Kim Phillips
[EMAIL PROTECTED] wrote:
delete obsolete device-type property, delete model property
(use compatible property instead), prepend fsl, to Freescale
specific properties. Add nodes to device trees that are missing them,
and fix broken property values in other trees.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
Are there any drivers in mainline which use this node? Do these
changes break backwards compatibility with already deployed boards?
(I know; this patch doesn't change any code; but I'm asking whether
the driver will need to support both old and new bindings).
---
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 46e2da3..9a3881d 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -226,22 +226,15 @@
compatible = fsl,mpc8272-pic, fsl,cpm2-pic;
};
-/* May need to remove if on a part without crypto engine */
[EMAIL PROTECTED] {
- device_type = crypto;
- model = SEC2;
- compatible = fsl,mpc8272-talitos-sec2,
-fsl,talitos-sec2,
-fsl,talitos,
-talitos;
+ compatible = fsl,sec1.0;
Should really be encoding the SoC model in the compatible property.
At the very least, compatible should be:
compatible = fsl,mpc8272-sec, fsl,sec1.0;
I'm really don't like fsl,sec1.0 or any of the variants as a
compatible property either because it can easily be abused (it's not
anchored to a specific physical part so the meaning can shift over
time); but that is another argument and it is well documented in other
email threads
(http://thread.gmane.org/gmane.linux.ports.ppc64.devel/38977/focus=39147)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/12] pata_mpc52xx: use linux/of_platform.h instead of asm
On Thu, Jun 26, 2008 at 11:37 PM, Jeff Garzik [EMAIL PROTECTED] wrote: Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- drivers/ata/pata_mpc52xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I am not sure who wants to take this. diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c index bc79df6..a9e8273 100644 --- a/drivers/ata/pata_mpc52xx.c +++ b/drivers/ata/pata_mpc52xx.c @@ -16,10 +16,10 @@ #include linux/slab.h #include linux/delay.h #include linux/libata.h +#include linux/of_platform.h #include asm/types.h #include asm/prom.h -#include asm/of_platform.h #include asm/mpc52xx.h ACK. send it via an arch tree I'll pick it up. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
On Thu, Jun 26, 2008 at 5:29 AM, [EMAIL PROTECTED] wrote: From: Michal Simek [EMAIL PROTECTED] Signed-off-by: Michal Simek [EMAIL PROTECTED] --- arch/microblaze/platform/generic/system.dts | 300 +++ 1 files changed, 300 insertions(+), 0 deletions(-) create mode 100644 arch/microblaze/platform/generic/system.dts Since this is a generated file, and entirely bitstream specific, does it make sense to include it in the kernel tree? If it does, then is it produced from one of the Xilinx reference designs? Can you add documentation to the header that specifies exactly which design version this .dts is for? diff --git a/arch/microblaze/platform/generic/system.dts b/arch/microblaze/platform/generic/system.dts new file mode 100644 index 000..724a037 --- /dev/null +++ b/arch/microblaze/platform/generic/system.dts @@ -0,0 +1,300 @@ +/* + * (C) Copyright 2007-2008 Xilinx, Inc. + * (C) Copyright 2007-2008 Michal Simek + * + * Michal SIMEK [EMAIL PROTECTED] If this is a generated file, then is this copyright notice even appropriate? + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program 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 General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA I don't this whole large legal block is necessary. Unless specified otherwise in the comment block, I believe GPL licencing is pretty much assumed and so the above three copyrights should be redundant. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
