Re: Problem with full speed devices on PowerPC MPC5121 host port
On 22.12.2011 18:39, Greg KH wrote: On Thu, Dec 22, 2011 at 12:48:45PM +0100, Matthias Fuchs wrote: Hi, I ran into trouble when using the MPC5121 with full speed USB devices. I've seen the issue with USB serial converters based on FTDI and Prolific chips. After connecting the device they first work fine. But when I stress the converter communications stalls. I can even force this behavior when doing a flood ping against the device. Then it only takes a few seconds until USB gets weird. After some time and several CTRL-C to stop the application that uses the ttyUSBx port I get a kernel message: ftdi_sio ttyUSB0: error from flowcontrol urb The only thing that reanimates the USB port is doing a reboot. Not removing and inserting the device again? unloading the ftdi_sio driver and reloading it? Right. First I used a monolithic kernel with ftdi_sio and ehci_hcd build in. Now I did the test again with fsl_mph_dr_of, ehci_hcd, usbserial and ftdi_sio loaded as modules. After the error occured, I removed the device and unloaded the modules. After reloading them USB is still weird. usb 1-1: new full-speed USB device number 2 using fsl-ehci usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -110 usb 1-1: new full-speed USB device number 3 using fsl-ehci usb 1-1: device descriptor read/64, error -110 If you look at the data using usbmon, does anything look odd? As long as everything works fine usbmon outputs data like this. It stops a short time after I started the flood ping to the board. df9c16c0 697164417 C Bi:1:002:1 0 2 = 0160 df9c16c0 697164436 S Bi:1:002:1 -115 512 df9c16c0 697165417 C Bi:1:002:1 0 2 = 0160 df9c16c0 697165441 S Bi:1:002:1 -115 512 df9c16c0 697166417 C Bi:1:002:1 0 2 = 0160 df9c16c0 697166435 S Bi:1:002:1 -115 512 df9c16c0 697167417 C Bi:1:002:1 0 9 = 01605f54 48452051 55 df9c16c0 697167450 S Bi:1:002:1 -115 512 df9c16c0 697168417 C Bi:1:002:1 0 14 = 01604943 4b204252 4f574e20 464f df9c16c0 697168450 S Bi:1:002:1 -115 512 df9c16c0 697169420 C Bi:1:002:1 0 13 = 01605820 4a554d50 53204f56 45 df9c16c0 697169453 S Bi:1:002:1 -115 512 df9c16c0 697170418 C Bi:1:002:1 0 14 = 01605220 54484520 4c415a59 2044 df9c16c0 697170451 S Bi:1:002:1 -115 512 df9c16c0 697171417 C Bi:1:002:1 0 14 = 01604f47 20313233 34353637 3839 df9c16c0 697171450 S Bi:1:002:1 -115 512 Then I try to abort my application. This result in df9c1340 712766944 S Co:1:002:0 s 40 02 0 df9c1340 717776208 C Co:1:002:0 -2 0 df9c1340 717776503 S Co:1:002:0 s 40 01 0300 0 df9c1340 722786213 C Co:1:002:0 -2 8 df9c16c0 722796202 C Bi:1:002:1 -2 0 And finally I try to restart my application: df9c12c0 791192447 S Co:1:002:0 s 40 00 0 df9c12c0 796202240 C Co:1:002:0 -2 0 df9c12c0 796203289 S Co:1:002:0 s 40 02 0 df9c12c0 801213213 C Co:1:002:0 -2 0 df9c16c0 801213518 S Bi:1:002:1 -115 512 df9c12c0 801213560 S Co:1:002:0 s 40 01 0303 0 df9c12c0 806223208 C Co:1:002:0 -2 0 df9c12c0 806223411 S Co:1:002:0 s 40 02 0 df9c12c0 811233210 C Co:1:002:0 -2 0 df9c1440 821344904 S Co:1:002:0 s 40 02 0 df9c1440 826354209 C Co:1:002:0 -2 8 df9c1440 826354515 S Co:1:002:0 s 40 01 0300 0 df9c1440 831364204 C Co:1:002:0 -2 0 df9c16c0 831374203 C Bi:1:002:1 -2 0 And what kernel version are you using here? Now I switched to 3.2.0 with only minimal changes for our hardware. But (as expected) I get the same problems. For my eyes it does not really look like a general USB issue. It looks like a problem with the Freescale EHCI implementation that is influenced by high interrupt or internal bus load caused by the flood ping. I put linuxppc-dev on CC. Perhaps soneone in that community can double check it on a Freescale evaluation board. Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 0/9] Remove useless on_each_cpu return value
On Tue, 2012-01-03 at 16:19 +0200, Gilad Ben-Yossef wrote: on_each_cpu() returns as its own return value the return value of smp_call_function(). smp_call_function() in turn returns a hard coded value of zero. Some callers to on_each_cpu() waste cycles and bloat code space by checking the return value to on_each_cpu(), probably for historical reasons. hysterical raisins,, yumm! :-) This patch set refactors callers to not test on_each_cpu() (fixed) return value and then refactors on_each_cpu to return void to avoid confusing future users. Seems sane enough, fwiw: Acked-by: Peter Zijlstra a.p.zijls...@chello.nl ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
On 01/05/12 19:22, Scott Wood wrote: On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote: thanks for your response. not setting MSR_POW gives same result. OK, so you're not getting an interrupt regardless of low-power state. Check whether the interrupt is getting masked during standby preparation. Does the interrupt handler run when you're not trying to enter standby? The GPIO/UART interrupt nor the PMC interrupt are being masked during standby preperation. The GPIO/UART interrupt works fine in operational mode. The PMC interrupt I do not know, is it possible to to get PMC interrupt without going to standby or deep-sleep ? In anyway there is no PMC interrupt for NAP mode (if kernel.powersave-nap=1). if I set kernel.powersave-nap=1 it works fine, What is it? Do you mean that powersave-nap doesn't break things, or that standby works when you specify that? I mean powersave-nap itself seems to work and does not break things. so apparently NAP/DOZE mode does work (if CPU is idle). This saves almost no power though. Standby mode saves about 300-500 mW. The problem could well be our board though, today I learned it does work by connecting an (inactive) JTAG debugger. Also, on another board it always works. You mean connecting a JTAG but not doing anything with it made wake-from-standby work? There was a bug like that on early revisions of the mpc8313erdb board -- though in that case if you had a bad board the system would hang whenever you access any PMC register. I'm not sure what the mechanism of failure was; IIRC the fix was adding a resistor. yes, connecting a JTAG but not doing anything with it makes wake-from-standby work. I don't know what's wrong with (some of) our boards... it looks like external interrupts are blocked and/or core stays in reset.. I doubt there's a SW PMC race/deadlock that causes this. --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with full speed devices on PowerPC MPC5121 host port
On Fri, 6 Jan 2012, Matthias Fuchs wrote: For my eyes it does not really look like a general USB issue. It looks like a problem with the Freescale EHCI implementation that is influenced by high interrupt or internal bus load caused by the flood ping. Indeed, it might be a problem with the built-in Transaction Translator. That would explain why it affect full-speed devices. However, I would expect the resetting the controller hardware (which happens when you reload the ehci-fsl driver) would fix any such issues. It's hard to imagine how a problem could survive a reset like that. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH/RFC] gianfar: Add support for byte queue limits.
Add support for byte queue limits (BQL), based on the similar
modifications made to intel/igb/igb_main.c from Eric Dumazet
in commit bdbc063129e811264cd6c311d8c2d9b95de01231.
A local variable for tx_queue-qindex was introduced in
gfar_clean_tx_ring, since it is now used often enough to warrant it,
and it cleans up the readability somewhat as well.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
[Too late for 3.3, but I figured I might as well get feedback from people
in the interim. Passes basic boot test with NFS root on sbc8548 board.]
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index e01cdaa..7d86d38 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1755,9 +1755,12 @@ static void free_skb_resources(struct gfar_private *priv)
/* Go through all the buffer descriptors and free their data buffers */
for (i = 0; i priv-num_tx_queues; i++) {
+ struct netdev_queue *txq;
tx_queue = priv-tx_queue[i];
+ txq = netdev_get_tx_queue(tx_queue-dev, tx_queue-qindex);
if(tx_queue-tx_skbuff)
free_skb_tx_queue(tx_queue);
+ netdev_tx_reset_queue(txq);
}
for (i = 0; i priv-num_rx_queues; i++) {
@@ -2204,6 +2207,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
lstatus |= BD_LFLAG(TXBD_CRC | TXBD_READY) | skb_headlen(skb);
}
+ netdev_tx_sent_queue(txq, skb-len);
+
/*
* We can work in parallel with gfar_clean_tx_ring(), except
* when modifying num_txbdfree. Note that we didn't grab the lock
@@ -2447,6 +2452,7 @@ static void gfar_align_skb(struct sk_buff *skb)
static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
{
struct net_device *dev = tx_queue-dev;
+ struct netdev_queue *txq;
struct gfar_private *priv = netdev_priv(dev);
struct gfar_priv_rx_q *rx_queue = NULL;
struct txbd8 *bdp, *next = NULL;
@@ -2458,10 +2464,13 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q
*tx_queue)
int frags = 0, nr_txbds = 0;
int i;
int howmany = 0;
+ int tqi = tx_queue-qindex;
+ unsigned int bytes_sent = 0;
u32 lstatus;
size_t buflen;
- rx_queue = priv-rx_queue[tx_queue-qindex];
+ rx_queue = priv-rx_queue[tqi];
+ txq = netdev_get_tx_queue(dev, tqi);
bdp = tx_queue-dirty_tx;
skb_dirtytx = tx_queue-skb_dirtytx;
@@ -2519,6 +2528,8 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q
*tx_queue)
bdp = next_txbd(bdp, base, tx_ring_size);
}
+ bytes_sent += skb-len;
+
/*
* If there's room in the queue (limit it to rx_buffer_size)
* we add this skb back into the pool, if it's the right size
@@ -2543,13 +2554,15 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q
*tx_queue)
}
/* If we freed a buffer, we can restart transmission, if necessary */
- if (__netif_subqueue_stopped(dev, tx_queue-qindex)
tx_queue-num_txbdfree)
- netif_wake_subqueue(dev, tx_queue-qindex);
+ if (__netif_subqueue_stopped(dev, tqi) tx_queue-num_txbdfree)
+ netif_wake_subqueue(dev, tqi);
/* Update dirty indicators */
tx_queue-skb_dirtytx = skb_dirtytx;
tx_queue-dirty_tx = bdp;
+ netdev_tx_completed_queue(txq, howmany, bytes_sent);
+
return howmany;
}
--
1.7.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote: On 01/05/12 19:22, Scott Wood wrote: On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote: thanks for your response. not setting MSR_POW gives same result. OK, so you're not getting an interrupt regardless of low-power state. Check whether the interrupt is getting masked during standby preparation. Does the interrupt handler run when you're not trying to enter standby? The GPIO/UART interrupt nor the PMC interrupt are being masked during standby preperation. The GPIO/UART interrupt works fine in operational mode. The PMC interrupt I do not know, is it possible to to get PMC interrupt without going to standby or deep-sleep ? The PMC interrupt is mainly of interest when running as a PCI agent, to be notified when the host changed the desired suspend state in config space. What changes from operational mode to the test where you omit setting MSR_POW? Try dumping SIPNR/SIMSR and GPIER/GPIMR/GPDAT at various points. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix kernel log of oops/panic instruction dump
A kernel oops/panic prints an instruction dump showing several
instructions before and after the instruction which caused the
oops/panic.
The code intended that the faulting instruction be enclosed in angle
brackets, however a bug caused the faulting instruction to be
interpreted by printk() as the message log level.
To fix this, the KERN_CONT log level is added before the actualy text of
the printed message.
=== Before the patch ===
[ 1081.587266] Instruction dump:
[ 1081.590236] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003 4e800020
3801
[ 1081.598034] 3d20c03a 9009a114 7c0004ac 3920
[ 1081.602500] 4e800020 3803ffd0 2b89
4[ 1081.587266] Instruction dump:
4[ 1081.590236] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
4[ 1081.598034] 3d20c03a 9009a114 7c0004ac 3920
9809[ 1081.602500] 4e800020 3803ffd0 2b89
=== After the patch ===
[ 51.385216] Instruction dump:
[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003 4e800020
3801
[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 9809 4e800020 3803ffd0
2b89
4[ 51.385216] Instruction dump:
4[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
4[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 9809 4e800020
3803ffd0 2b89
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
Cc: Paul Mackerras pau...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org
---
In the above examples, the first block is what is shown on the serial
console as the machine dies. The second block is the dump as captured by
mtdoops.
arch/powerpc/kernel/process.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 6457574..271f809 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -566,12 +566,12 @@ static void show_instructions(struct pt_regs *regs)
*/
if (!__kernel_text_address(pc) ||
__get_user(instr, (unsigned int __user *)pc)) {
- printk( );
+ printk(KERN_CONT );
} else {
if (regs-nip == pc)
- printk(%08x , instr);
+ printk(KERN_CONT %08x , instr);
else
- printk(%08x , instr);
+ printk(KERN_CONT %08x , instr);
}
pc += sizeof(int);
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix kernel log of oops/panic instruction dump
On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote:
A kernel oops/panic prints an instruction dump showing several
instructions before and after the instruction which caused the
oops/panic.
The code intended that the faulting instruction be enclosed in angle
brackets, however a bug caused the faulting instruction to be
interpreted by printk() as the message log level.
To fix this, the KERN_CONT log level is added before the actualy text of
the printed message.
Nice one, thanks.
Cheers,
Ben.
=== Before the patch ===
[ 1081.587266] Instruction dump:
[ 1081.590236] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003 4e800020
3801
[ 1081.598034] 3d20c03a 9009a114 7c0004ac 3920
[ 1081.602500] 4e800020 3803ffd0 2b89
4[ 1081.587266] Instruction dump:
4[ 1081.590236] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
4[ 1081.598034] 3d20c03a 9009a114 7c0004ac 3920
9809[ 1081.602500] 4e800020 3803ffd0 2b89
=== After the patch ===
[ 51.385216] Instruction dump:
[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003 4e800020
3801
[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 9809 4e800020
3803ffd0 2b89
4[ 51.385216] Instruction dump:
4[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
4[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 9809 4e800020
3803ffd0 2b89
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
Cc: Paul Mackerras pau...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org
---
In the above examples, the first block is what is shown on the serial
console as the machine dies. The second block is the dump as captured by
mtdoops.
arch/powerpc/kernel/process.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 6457574..271f809 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -566,12 +566,12 @@ static void show_instructions(struct pt_regs *regs)
*/
if (!__kernel_text_address(pc) ||
__get_user(instr, (unsigned int __user *)pc)) {
- printk( );
+ printk(KERN_CONT );
} else {
if (regs-nip == pc)
- printk(%08x , instr);
+ printk(KERN_CONT %08x , instr);
else
- printk(%08x , instr);
+ printk(KERN_CONT %08x , instr);
}
pc += sizeof(int);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix kernel log of oops/panic instruction dump
On Sat, Jan 07, 2012 at 09:50:10AM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote:
A kernel oops/panic prints an instruction dump showing several
instructions before and after the instruction which caused the
oops/panic.
The code intended that the faulting instruction be enclosed in angle
brackets, however a bug caused the faulting instruction to be
interpreted by printk() as the message log level.
To fix this, the KERN_CONT log level is added before the actualy text of
If you could fix the text above to say 'actual' (instead of 'actualy')
when you commit this, that would be great. Darn typos. :)
the printed message.
Nice one, thanks.
Cheers,
Ben.
=== Before the patch ===
[ 1081.587266] Instruction dump:
[ 1081.590236] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
[ 1081.598034] 3d20c03a 9009a114 7c0004ac 3920
[ 1081.602500] 4e800020 3803ffd0 2b89
4[ 1081.587266] Instruction dump:
4[ 1081.590236] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
4[ 1081.598034] 3d20c03a 9009a114 7c0004ac 3920
9809[ 1081.602500] 4e800020 3803ffd0 2b89
=== After the patch ===
[ 51.385216] Instruction dump:
[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 9809 4e800020
3803ffd0 2b89
4[ 51.385216] Instruction dump:
4[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
4[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 9809 4e800020
3803ffd0 2b89
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
Cc: Paul Mackerras pau...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org
---
In the above examples, the first block is what is shown on the serial
console as the machine dies. The second block is the dump as captured by
mtdoops.
arch/powerpc/kernel/process.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 6457574..271f809 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -566,12 +566,12 @@ static void show_instructions(struct pt_regs *regs)
*/
if (!__kernel_text_address(pc) ||
__get_user(instr, (unsigned int __user *)pc)) {
- printk( );
+ printk(KERN_CONT );
} else {
if (regs-nip == pc)
- printk(%08x , instr);
+ printk(KERN_CONT %08x , instr);
else
- printk(%08x , instr);
+ printk(KERN_CONT %08x , instr);
}
pc += sizeof(int);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] of: Change logic to overwrite cmd_line with CONFIG_CMDLINE
I know this is a long-dead thread, but I was a little curious about the motivation here. I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM Kconfig) in this function and don't know in which cases I should look at the CONFIG_CMDLINE and in which cases I should use whatever happened to be in data before the function was called. Here's the definition in the KConfig: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=arch/arm/Kconfig;h=24626b0419ee97e963e68329a8eb6769360b46ea;hb=HEAD#l1984 Which case do you have CONFIG_CMDLINE defined but not CMDLINE_FORCE? In those cases, do you happen to have CONFIG_CMDLINE_EXTEND or CMDLINE_FROM_BOOTLOADER defined? Thanks much! -Doug --- On Mon, Sep 19, 2011 at 9:55 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Sep 20, 2011 at 02:50:15PM +1000, Benjamin Herrenschmidt wrote: We used to overwrite with CONFIG_CMDLINE if we found a chosen node but failed to get bootargs out of it or they were empty, unless CONFIG_CMDLINE_FORCE is set. Instead change that to overwrite if data is non empty after the bootargs check. It allows arch code to have other mechanisms to retrieve the command line prior to parsing the device-tree. Note: CONFIG_CMDLINE_FORCE case should ideally be handled elsewhere as it won't work as it-is if the device-tree has no /chosen node Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org CC: devicetree-disc...@lists-ozlabs.org CC: Grant Likely grant.lik...@secretlab.ca Looks okay to me. Acked-by: Grant Likely grant.lik...@secretlab.ca --- drivers/of/fdt.c | 7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) v2. Use data instead of cmd_line so it works on archs like mips who don't pass cmd_line to that function to start with, also add a comment explaining the mechanism. (resent with right list address as well while at it) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 65200af..323b722 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -681,9 +681,14 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname, if (p != NULL l 0) strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE)); + /* + * CONFIG_CMDLINE is meant to be a default in case nothing else + * managed to set the command line, unless CONFIG_CMDLINE_FORCE + * is set in which case we override whatever was found earlier. + */ #ifdef CONFIG_CMDLINE #ifndef CONFIG_CMDLINE_FORCE - if (p == NULL || l == 0 || (l == 1 (*p) == 0)) + if (!data[0]) #endif strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE); #endif /* CONFIG_CMDLINE */ -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
