Hi All,
Just booting up v5.5.11 on a Freescale T2080RDB and I'm seeing the
following mesage.
kern.warning linuxbox kernel: Argh, can't find dcache properties !
kern.warning linuxbox kernel: Argh, can't find icache properties !
This was changed from DBG() to pr_warn() in commit 3b9176e9a874
("pow
Hi Christophe,
On Wed, 2020-02-05 at 12:03 +, Christophe Leroy wrote:
> [0.00] ioremap() called early from
> find_legacy_serial_ports+0x3cc/0x474. Use early_ioremap() instead
>
I was just about to dig into this error message and found you patch. I
applied it to a v5.5 base.
> find_l
On Tue, 2020-03-24 at 15:47 +1100, Michael Ellerman wrote:
> Chris Packham writes:
> > Hi All,
> >
> > Just booting up v5.5.11 on a Freescale T2080RDB and I'm seeing the
> > following mesage.
> >
> > kern.warning linuxbox kernel: Argh, can't f
Add the d-cache/i-cache properties for the T208x SoCs. The L1 cache on
these SoCs is 32KiB and is split into 64 byte blocks (lines).
Signed-off-by: Chris Packham
---
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc
On Tue, 2020-03-24 at 21:08 -0500, Scott Wood wrote:
> On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> > Chris Packham writes:
> > > Add the d-cache/i-cache properties for the T208x SoCs. The L1
> > > cache on
> > > these SoCs is 32KiB and
On Wed, 2020-03-25 at 15:38 +1300, Chris Packham wrote:
> On Tue, 2020-03-24 at 21:08 -0500, Scott Wood wrote:
> > On Wed, 2020-03-25 at 12:59 +1100, Michael Ellerman wrote:
> > > Chris Packham writes:
> > > > Add the d-cache/i-cache properties for the T208x
If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, use
the block-size value for both. Per the devicetree spec cache-line-size
is only needed if it differs from the block size.
Signed-off-by: Chris Packham
---
It looks as though the bsizep = lsizep is not required per the spec but
Hi All,
On Fri, 2019-08-02 at 06:40 +0200, Christophe Leroy wrote:
>
> Le 02/08/2019 à 00:50, Chris Packham a écrit :
> > Bring powerpc in line with other architectures that support extending or
> > overriding the bootloader provided command line.
> >
> > The
Hi All,
On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote:
> If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not,
> use
> the block-size value for both. Per the devicetree spec cache-line-
> size
> is only needed if it differs from the block size.
>
>
On Thu, 2020-04-16 at 21:43 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> > Hi All,
> >
> > On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote:
> > > If {i,d}-cache-block-size is set and {i,d}-cache-line-size is
> > > not,
> > >
cache block vs. cache line")
Signed-off-by: Chris Packham
---
It looks as though the bsizep = lsizep is not required per the spec but it's
probably safer to retain it.
Changes in v3:
- Rebase against 5.7.0-rc1
- Add Fixes tag
- Add more information to commit message
Changes in v2:
- Scott p
Hi,
I'm in the process of updating our products from a 4.4 based kernel to
5.1 (and probably 5.2 since that release is imminent).
On one product which uses a Freescale/NXP P2041 CPU, IDT pcie bridge and
Marvell switch chip[1].
Annoyingly the hardware has a reset line that holds the switch chip
-off-by: Chris Packham
---
arch/powerpc/Kconfig | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d8dcd8820369..cd9b3974aa36 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -851,6 +851,11 @@ config CMDLINE
Hi Christophe,
On Tue, 2019-07-30 at 09:02 +0200, Christophe Leroy wrote:
>
> Le 24/07/2019 à 07:33, Chris Packham a écrit :
> >
> > Device tree aware platforms can make use of CMDLINE_EXTEND to
> > extend the
> > kernel command line provided by the bootlo
On Wed, 2019-07-31 at 09:23 +0200, Christophe Leroy wrote:
>
> Le 30/07/2019 à 23:10, Chris Packham a écrit :
> >
> > Hi Christophe,
> >
> > On Tue, 2019-07-30 at 09:02 +0200, Christophe Leroy wrote:
> > >
> > >
&g
CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND can
be used to append the CMDLINE from the kernel config to the one provided
by the bootloader.
Signed-off-by: Chris Packham
---
While I'm at it does anyone think it's worth getting rid of the default CMDLINE
value if CMDLINE_BOOL and maybe CMDLINE_B
On Thu, 2019-08-01 at 08:14 +0200, Christophe Leroy wrote:
>
> Le 01/08/2019 à 04:12, Chris Packham a écrit :
> >
> > Bring powerpc in line with other architectures that support
> > extending or
> > overriding the bootloader provided command line.
> >
&g
CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND can
be used to append the CMDLINE from the kernel config to the one provided
by the bootloader.
Signed-off-by: Chris Packham
---
Changes in v3:
- don't use BUG_ON in prom_strlcat
- rearrange things to eliminate prom_strlcpy
Changes in v2:
- incorporate ideas
t
CONFIG_CMDLINE_BOOL=y also set CONFIG_CMDLINE to something else. For
these reasons remove the inaccessible default.
Signed-off-by: Chris Packham
---
This should be independent of http://patchwork.ozlabs.org/patch/1140811/ but
I've generated this patch on a stream that has it applied locally.
On Fri, 2019-08-02 at 07:18 +0200, Christophe Leroy wrote:
>
> Le 02/08/2019 à 07:02, Chris Packham a écrit :
> >
> > Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef
> > mess")
> > CONFIG_CMDLINE has always had a value regardless of
&g
Hi All,
I have a custom board that uses the Freescale/NXP T2080 SoC.
The board boots fine using v4.19.60 but when I use v5.1.21 it locks up
waiting for the other CPUs to come online (earlyprintk output below).
If I set maxcpus=0 then the system boots all the way through to
userland. The same thin
On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> Hi All,
>
> I have a custom board that uses the Freescale/NXP T2080 SoC.
>
> The board boots fine using v4.19.60 but when I use v5.1.21 it locks
> up
> waiting for the other CPUs to come online (earlyprintk outp
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> > >
> > > Hi All,
> > >
> > > I have a custom board that uses the Freescale/NXP T2080 SoC.
&
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> > >
> > > Chris Packham writes:
> > > >
> > > > On Mon, 2019-08-05 at 14:06 +1200
which was
> marked __maybe_used remained.
>
> Since commit ed1cd6deb013 ("powerpc: Activate
> CONFIG_THREAD_INFO_IN_TASK") thread_info cannot be reached before mmu
> is properly set up.
>
> Drop this stale call to smp_processor_id() which make SMP hang
> when C
Hi All,
On Fri, 2019-08-02 at 06:40 +0200, Christophe Leroy wrote:
>
> Le 02/08/2019 à 00:50, Chris Packham a écrit :
> > Bring powerpc in line with other architectures that support extending or
> > overriding the bootloader provided command line.
> >
> > The
On 16/04/24 08:54, Andi Shyti wrote:
> Hi Abhinav,
>
>> /* Enable I2C interrupts for mpc5121 */
>> -node_ctrl = of_find_compatible_node(NULL, NULL,
>> -"fsl,mpc5121-i2c-ctrl");
>> +struct device_node *node_ctrl __free(device_node) =
> How have y
On 1/09/20 6:14 pm, Nicholas Piggin wrote:
> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>>> On 30.08.2020 23:59, Chris Packham wrote:
>>>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
>&
On 2/09/20 11:29 am, Chris Packham wrote:
>
> On 1/09/20 6:14 pm, Nicholas Piggin wrote:
>> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>>> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>>>> On 30.08.2020 23:59, Chris Packham wr
On 1/09/20 6:14 pm, Nicholas Piggin wrote:
> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>>> On 30.08.2020 23:59, Chris Packham wrote:
>>>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
>&
pc/64:
Implement soft interrupt replay in C").
Signed-off-by: Chris Packham
Cc: sta...@vger.kernel.org
---
Notes:
I've tested this on a T2080RDB and a custom board using the T2081 SoC. With
this change I don't see any spurious instances of the "Transfer done but
(resend as something decided to insert html, some context stripped)
On 5/09/20 5:23 am, Heiner Kallweit wrote:
> On Fri 4. Sep 2020 at 01:58, Chris Packham
> <mailto:chris.pack...@alliedtelesis.co.nz>> wrote:
>
>
>
>
> I tried ftrace but I really wasn
On 5/09/20 5:23 am, Heiner Kallweit wrote:
On Fri 4. Sep 2020 at 01:58, Chris Packham
mailto:chris.pack...@alliedtelesis.co.nz>>
wrote:
On 1/09/20 6:14 pm, Nicholas Piggin wrote:
> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>> On 1/09/20 12:33
Hi All,
On 4/09/20 12:28 pm, Chris Packham wrote:
> The SPIE register contains counts for the TX FIFO so any time the irq
> handler was invoked we would attempt to process the RX/TX fifos. Use the
> SPIM value to mask the events so that we only process interrupts that
> were expect
On 24/09/20 8:27 am, Heiner Kallweit wrote:
> On 04.09.2020 02:28, Chris Packham wrote:
>> The SPIE register contains counts for the TX FIFO so any time the irq
>> handler was invoked we would attempt to process the RX/TX fifos. Use the
>> SPIM value to mask the events so
Hi,
I've got a system using a PowerPC T2080 SoC and among other things has
an LM81 hwmon chip.
Under a high CPU load we see errant readings from the LM81 as well as
actual failures. It's the errant readings that cause the most concern
since we can easily ignore the read errors in our monitorin
On 8/03/21 1:31 pm, Guenter Roeck wrote:
> On 3/7/21 2:52 PM, Chris Packham wrote:
>> Hi,
>>
>> I've got a system using a PowerPC T2080 SoC and among other things has
>> an LM81 hwmon chip.
>>
>> Under a high CPU load we see errant readings from the
On 8/03/21 3:27 pm, Chris Packham wrote:
>
> On 8/03/21 1:31 pm, Guenter Roeck wrote:
>> On 3/7/21 2:52 PM, Chris Packham wrote:
>>> Hi,
>>>
>>> I've got a system using a PowerPC T2080 SoC and among other things has
>>> an LM81 hwmon chip.
>
On 8/03/21 5:59 pm, Guenter Roeck wrote:
> On 3/7/21 8:37 PM, Chris Packham wrote:
> [ ... ]
>>> That's from -ENXIO which is used in only one place in i2c-mpc.c. I'll
>>> enable some debug and see what we get.
>> For the errant readings there was nothing ab
On 8/03/21 5:59 pm, Guenter Roeck wrote:
> On 3/7/21 8:37 PM, Chris Packham wrote:
> [ ... ]
>>> That's from -ENXIO which is used in only one place in i2c-mpc.c. I'll
>>> enable some debug and see what we get.
>> For the errant readings there was nothing ab
On 9/03/21 11:10 am, Chris Packham wrote:
>
> On 8/03/21 5:59 pm, Guenter Roeck wrote:
>> On 3/7/21 8:37 PM, Chris Packham wrote:
>> [ ... ]
>>>> That's from -ENXIO which is used in only one place in i2c-mpc.c. I'll
>>>> enable some debug and se
On 8/03/21 1:31 pm, Guenter Roeck wrote:
> On 3/7/21 2:52 PM, Chris Packham wrote:
>> Fundamentally I think this is a problem with the fact that the LM81 is
>> an SMBus device but the T2080 (and other Freescale SoCs) uses i2c and we
>> emulate SMBus. I suspect the errant
On 9/03/21 9:27 am, Chris Packham wrote:
> On 8/03/21 5:59 pm, Guenter Roeck wrote:
>> Other than that, the only other real idea I have would be to monitor
>> the i2c bus.
> I am in the fortunate position of being able to go into the office and
> even happen to have the e
On 10/03/21 6:06 pm, Guenter Roeck wrote:
> On 3/9/21 6:19 PM, Chris Packham wrote:
>> On 9/03/21 9:27 am, Chris Packham wrote:
>>> On 8/03/21 5:59 pm, Guenter Roeck wrote:
>>>> Other than that, the only other real idea I have would be to monitor
>>>&
On 11/03/21 9:18 pm, Wolfram Sang wrote:
>> Bummer. What is really weird is that you see clock stretching under
>> CPU load. Normally clock stretching is triggered by the device, not
>> by the host.
> One example: Some hosts need an interrupt per byte to know if they
> should send ACK or NACK. If
On 12/03/21 10:34 am, Guenter Roeck wrote:
> On 3/11/21 1:17 PM, Chris Packham wrote:
>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>> Bummer. What is really weird is that you see clock stretching under
>>>> CPU load. Normally clock stretching is triggered by
On 12/03/21 1:07 pm, Guenter Roeck wrote:
> On 3/11/21 3:47 PM, Chris Packham wrote:
>> On 12/03/21 10:34 am, Guenter Roeck wrote:
>>> On 3/11/21 1:17 PM, Chris Packham wrote:
>>>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>>>> Bummer. What is rea
On 12/03/21 10:25 pm, David Laight wrote:
> From: Linuxppc-dev Guenter Roeck
>> Sent: 11 March 2021 21:35
>>
>> On 3/11/21 1:17 PM, Chris Packham wrote:
>>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>>> Bummer. What is really weird is that you see cl
On 12/03/21 10:34 am, Guenter Roeck wrote:
> On 3/11/21 1:17 PM, Chris Packham wrote:
>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>> Bummer. What is really weird is that you see clock stretching under
>>>> CPU load. Normally clock stretching is triggered by
On 5/05/22 01:44, Andy Shevchenko wrote:
> Switch mpc5xxx_get_bus_frequency() to use fwnode in order to help
> cleaning up other parts of the kernel from OF specific code.
>
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/powerpc/include/asm/mpc5xxx.h
message is gone and I still
get console output.
Tested-by: Chris Packham
> arch/powerpc/kernel/legacy_serial.c | 33 +
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c
> b/arch/powerpc/kernel/leg
Document the fsl,i2c-erratum-a004447 flag which indicates the presence
of an i2c erratum on some QorIQ SoCs.
Signed-off-by: Chris Packham
---
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c
devicetree to
decide when the alternative mechanism is needed.
Chris Packham (3):
dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c
controllers
i2c: mpc: implement erratum A-004447 workaround
.../devicetree/bindings/i2c/i2c
The P2040/P2041 has an erratum where the normal i2c recovery mechanism
does not work. Implement the alternative recovery mechanism documented
in the P2040 Chip Errata Rev Q.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 88 +++-
1 file changed
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q (latest available at the time of writing).
Signed-off-by: Chris Packham
---
arch
On 6/05/21 8:03 pm, Andy Shevchenko wrote:
On Thursday, May 6, 2021, Chris Packham
mailto:chris.pack...@alliedtelesis.co.nz>>
wrote:
The P2040/P2041 has an erratum where the normal i2c recovery mechanism
does not work. Implement the alternative recovery mechanism documented
in the P204
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q (latest available at the time of writing).
Signed-off-by: Chris Packham
---
arch
devicetree to
decide when the alternative mechanism is needed.
Chris Packham (3):
dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c
controllers
i2c: mpc: implement erratum A-004447 workaround
.../devicetree/bindings/i2c/i2c
Document the fsl,i2c-erratum-a004447 flag which indicates the presence
of an i2c erratum on some QorIQ SoCs.
Signed-off-by: Chris Packham
---
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c
The P2040/P2041 has an erratum where the normal i2c recovery mechanism
does not work. Implement the alternative recovery mechanism documented
in the P2040 Chip Errata Rev Q.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- Use readb_poll_timeout instead of open-coded loop
On 8/05/21 9:49 am, Rob Herring wrote:
> On Fri, May 07, 2021 at 12:40:45PM +1200, Chris Packham wrote:
>> Document the fsl,i2c-erratum-a004447 flag which indicates the presence
>> of an i2c erratum on some QorIQ SoCs.
>>
>> Signed-off-by: Chris Packham
>>
On 7/05/21 8:24 pm, Joakim Tjernlund wrote:
> On Fri, 2021-05-07 at 10:04 +0200, Joakim Tjernlund wrote:
>> On Fri, 2021-05-07 at 12:40 +1200, Chris Packham wrote:
>>> The i2c controllers on the P2040/P2041 have an erratum where the
>>> documented scheme for i2c bu
The P2040/P2041 has an erratum where the normal i2c recovery mechanism
does not work. Implement the alternative recovery mechanism documented
in the P2040 Chip Errata Rev Q.
Signed-off-by: Chris Packham
---
Notes:
Changes in v3:
- Further code reduction in i2c_mpc_wait_sr()
Changes
devicetree to
decide when the alternative mechanism is needed.
Chris Packham (4):
dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c
controllers
powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c
controllers
i2c: mpc
The i2c controllers on the P2040/P2041 have an erratum where the
documented scheme for i2c bus recovery will not work (A-004447). A
different mechanism is needed which is documented in the P2040 Chip
Errata Rev Q (latest available at the time of writing).
Signed-off-by: Chris Packham
---
arch
The i2c controllers on the P1010 have an erratum where the documented
scheme for i2c bus recovery will not work (A-004447). A different
mechanism is needed which is documented in the P1010 Chip Errata Rev L.
Signed-off-by: Chris Packham
---
Notes:
Changes in v3:
- New
arch/powerpc
Document the fsl,i2c-erratum-a004447 flag which indicates the presence
of an i2c erratum on some QorIQ SoCs.
Signed-off-by: Chris Packham
Acked-by: Rob Herring
---
Notes:
Changes in v3:
- Add Ack from Rob
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 7 +++
1 file changed
On 12/05/21 10:10 am, Joakim Tjernlund wrote:
> On Wed, 2021-05-12 at 09:20 +1200, Chris Packham wrote:
>> The P2040/P2041 has an erratum where the i2c recovery scheme
>> documented in the reference manual (and currently implemented
>> in the i2c-mpc.c driver) does not work
On 13/05/21 3:01 am, w...@kernel.org wrote:
>>> I've been doing my recent work with a P2040 and prior to that I did test
>>> out the recovery on a T2081 (which isn't documented to have this
>>> erratum) when I was re-working the driver. The "new" recovery actually
>>> seems better but I don't hav
On 4/06/21 12:42 pm, Michael Ellerman wrote:
> Sasha Levin writes:
>> From: Chris Packham
>>
>> [ Upstream commit 7adc7b225cddcfd0f346d10144fd7a3d3d9f9ea7 ]
>>
>> The i2c controllers on the P2040/P2041 have an erratum where the
>> documented scheme for i
Hi,
I've just fired up linux kernel v5.7 on a p2040 based system and I'm
getting the following new warning
OF: Can't handle multiple dma-ranges with different offsets on
node(/pcie@ffe202000)
OF: Can't handle multiple dma-ranges with different offsets on
node(/pcie@ffe202000)
The warning itse
On 22/07/20 4:19 pm, Chris Packham wrote:
> Hi,
>
> I've just fired up linux kernel v5.7 on a p2040 based system and I'm
> getting the following new warning
>
> OF: Can't handle multiple dma-ranges with different offsets on
> node(/pcie@ffe202000)
> OF
On 23/07/20 10:11 am, Chris Packham wrote:
>
> On 22/07/20 4:19 pm, Chris Packham wrote:
>> Hi,
>>
>> I've just fired up linux kernel v5.7 on a p2040 based system and I'm
>> getting the following new warning
>>
>> OF: Can't handle mul
On 24/03/20 10:54 am, Chris Packham wrote:
> Hi Christophe,
>
> On Wed, 2020-02-05 at 12:03 +, Christophe Leroy wrote:
>> [0.00] ioremap() called early from
>> find_legacy_serial_ports+0x3cc/0x474. Use early_ioremap() instead
>>
> I was just about to d
Hi,
I'm seeing a problem with accessing spi-nor after upgrading a T2081
based system to linux v5.7.15
For this board u-boot and the u-boot environment live on spi-nor.
When I use fw_setenv from userspace I get the following kernel logs
# fw_setenv foo=1
fsl_espi ffe11.spi: Transfer done bu
On 14/08/20 6:19 pm, Heiner Kallweit wrote:
> On 14.08.2020 04:48, Chris Packham wrote:
>> Hi,
>>
>> I'm seeing a problem with accessing spi-nor after upgrading a T2081
>> based system to linux v5.7.15
>>
>> For this board u-boot and the u-boot e
Hi Again,
On 17/08/20 9:09 am, Chris Packham wrote:
>
> On 14/08/20 6:19 pm, Heiner Kallweit wrote:
>> On 14.08.2020 04:48, Chris Packham wrote:
>>> Hi,
>>>
>>> I'm seeing a problem with accessing spi-nor after upgrading a T2081
>>> based syst
On 19/08/20 6:15 pm, Heiner Kallweit wrote:
> On 19.08.2020 00:44, Chris Packham wrote:
>> Hi Again,
>>
>> On 17/08/20 9:09 am, Chris Packham wrote:
>>
>>> On 14/08/20 6:19 pm, Heiner Kallweit wrote:
>>>> On 14.08.2020 04:48, Chris Packham wrote:
On 20/08/20 9:08 am, Chris Packham wrote:
>
> On 19/08/20 6:15 pm, Heiner Kallweit wrote:
>> On 19.08.2020 00:44, Chris Packham wrote:
>>> Hi Again,
>>>
>>> On 17/08/20 9:09 am, Chris Packham wrote:
>>>
>>>> On 14/08/20 6:19 pm, Hei
On 25/08/20 10:04 am, Chris Packham wrote:
>
> On 20/08/20 9:08 am, Chris Packham wrote:
>>
>> On 19/08/20 6:15 pm, Heiner Kallweit wrote:
>>> On 19.08.2020 00:44, Chris Packham wrote:
>>>> Hi Again,
>>>>
>>>> On 17/08/20 9:09
On 25/08/20 7:22 pm, Heiner Kallweit wrote:
> I've been staring at spi-fsl-espi.c for while now and I think I've
>> identified a couple of deficiencies that may or may not be related to my
>> issue.
>>
>> First I think the 'Transfer done but SPIE_DON isn't set' message can be
>> generated spuriou
On 26/08/20 10:22 am, Chris Packham wrote:
> On 25/08/20 7:22 pm, Heiner Kallweit wrote:
>
>
>> I've been staring at spi-fsl-espi.c for while now and I think I've
>>> identified a couple of deficiencies that may or may not be related
>>> to my
>>
On 26/08/20 1:48 pm, Chris Packham wrote:
>
> On 26/08/20 10:22 am, Chris Packham wrote:
>> On 25/08/20 7:22 pm, Heiner Kallweit wrote:
>>
>>
>>> I've been staring at spi-fsl-espi.c for while now and I think I've
>>>> identified a couple of
(adding Nicholas)
On 26/08/20 6:38 pm, Heiner Kallweit wrote:
> On 26.08.2020 08:07, Chris Packham wrote:
>> On 26/08/20 1:48 pm, Chris Packham wrote:
>>> On 26/08/20 10:22 am, Chris Packham wrote:
>>>> On 25/08/20 7:22 pm, Heiner Kallweit wrote:
>>>>
On 27/08/20 7:12 pm, Nicholas Piggin wrote:
> Excerpts from Heiner Kallweit's message of August 26, 2020 4:38 pm:
>> On 26.08.2020 08:07, Chris Packham wrote:
>>> On 26/08/20 1:48 pm, Chris Packham wrote:
>>>> On 26/08/20 10:22 am, Chris Packham wrote:
>>
On 31/08/20 12:30 am, Nicholas Piggin wrote:
> Excerpts from Chris Packham's message of August 28, 2020 8:07 am:
>> I've also now seen the RX FIFO not empty error on the T2080RDB
>>
>> fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set!
>> fsl_espi ffe11.spi: Trans
On 31/08/20 9:41 am, Heiner Kallweit wrote:
> On 30.08.2020 23:00, Chris Packham wrote:
>> On 31/08/20 12:30 am, Nicholas Piggin wrote:
>>> Excerpts from Chris Packham's message of August 28, 2020 8:07 am:
>>
>>
>>>>>>>> I&#
On 1/09/20 12:33 am, Heiner Kallweit wrote:
> On 30.08.2020 23:59, Chris Packham wrote:
>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
>>> On 30.08.2020 23:00, Chris Packham wrote:
>>>> On 31/08/20 12:30 am, Nicholas Piggin wrote:
>>>>> Excerpts from
On 1/09/20 12:33 am, Heiner Kallweit wrote:
> On 30.08.2020 23:59, Chris Packham wrote:
>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
>>> On 30.08.2020 23:00, Chris Packham wrote:
>>>> On 31/08/20 12:30 am, Nicholas Piggin wrote:
>>>>> Excerpts from
This was added in commit ce973b141dfa ("[PATCH] Freescale QE UCC gigabit
ethernet driver") but doesn't appear to have been used. Remove it now.
Signed-off-by: Chris Packham
---
drivers/net/ethernet/freescale/ucc_geth.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drive
CONFIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONFIG_CMDLINE_BOOL' ineffective.
$ ./scripts/config --enable CONFIG_CMDLINE_BOOL
$ cat .config
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Remove CONFIG_CMDLINE_BOOL and the inaccessible default.
Sig
On 11/06/20 5:46 pm, Christophe Leroy wrote:
>
>
> Le 11/06/2020 à 05:41, Chris Packham a écrit :
>> Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
>> CONFIG_CMDLINE has always had a value regardless of CONFIG_CMDLINE_BOOL.
>>
>&g
This series cleans up the config options related to the boot command line.
Chris Packham (2):
powerpc: Remove inaccessible CMDLINE default
powerpc: configs: remove CMDLINE_BOOL
arch/powerpc/Kconfig | 6 +-
arch/powerpc/configs/44x/akebono_defconfig | 2
CONFIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONFIG_CMDLINE_BOOL' ineffective.
$ ./scripts/config --enable CONFIG_CMDLINE_BOOL
$ cat .config
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Remove CONFIG_CMDLINE_BOOL and the inaccessible default.
Sig
Regenerate defconfigs to remove CONFIG_CMDLINE_BOOL and the default
CONFIG_CMDLINE where applicable.
Signed-off-by: Chris Packham
---
Changes in v3:
- new
arch/powerpc/configs/44x/akebono_defconfig | 2 --
arch/powerpc/configs/44x/arches_defconfig | 2 --
arch/powerpc/configs/44x
Hi,
I've just attempted to build a powerpc kernel from 4.11-rc2 using a
custom defconfig (available on request) and I'm hitting the following
error in the early stages of compilation.
:1325:2: error: #warning syscall statx not implemented [-Werror=cpp]
Same thing seems to happen with mpc85xx_b
On 13/03/17 21:52, Chandan Rajendra wrote:
> On Monday, March 13, 2017 03:33:07 AM Chris Packham wrote:
>> Hi,
>>
>> I've just attempted to build a powerpc kernel from 4.11-rc2 using a
>> custom defconfig (available on request) and I'm hitting the foll
On 15/03/17 00:57, Michael Ellerman wrote:
> Chris Packham writes:
>
>> On 13/03/17 21:52, Chandan Rajendra wrote:
>>> On Monday, March 13, 2017 03:33:07 AM Chris Packham wrote:
>>>> Hi,
>>>>
>>>> I've just attempted to build a powerpc
aintain.
> Maybe someone has some insights...
>
> On Fri, May 12, 2017 at 04:20:02PM +1200, Chris Packham wrote:
>> To allow this driver to be used on non-powerpc platforms it needs to use
>> io accessors suitable for all platforms.
>>
>> Signed-off-by: Chris P
Change this from mpc85xx_pci_err to mv64x60_pci_err. The former is
likely a hangover from when this driver was created.
Signed-off-by: Chris Packham
---
drivers/edac/mv64x60_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac
1 - 100 of 118 matches
Mail list logo
