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
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
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
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
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
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
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
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
in the 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 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
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
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
>>
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
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
in the 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 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
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
in the 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
ge 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/
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 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 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: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 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.
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 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 hav
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 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 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 a
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 a
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 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 L
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
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/drivers/ne
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 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
> w
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 am,
(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
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
SPI
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:
>>&g
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 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 wrote:
>>>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
>>&g
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
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've als
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:
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:
>>>
(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 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 deficienci
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
>>> issue
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
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 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 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 w
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 syste
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 enviro
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
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
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 multiple dma-range
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: Can't ha
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
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
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.
Signed-off-by
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
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
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.
Signed-off-by
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
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,
> > &
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.
>
>
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
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 T2
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
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 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 find dcache
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.
>
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
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 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
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
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
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 So
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
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
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
G_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.
arch/powerpc/K
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 from
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
---
While I'm at it does anyone think it's worth getting rid of the default CMDLINE
value if CMDLINE_BOOL and maybe CMDLINE_BOOL? Every
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
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
-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,
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
Hi Christophe,
On 14/01/18 06:17, Christophe JAILLET wrote:
> Le 13/01/2018 à 15:22, Borislav Petkov a écrit :
>> + Chris Packham who's been fixing some stuff in here too.
>>
>> On Sat, Jan 13, 2018 at 08:28:21AM +0100, Christophe JAILLET wrote:
>>> Reorder th
Hi Borislav,
On 30/05/17 09:21, Chris Packham wrote:
> Check the return status of platform_driver_register() in
> mv64x60_edac_init(). Only output messages and initialise the
> edac_op_state if the registration is successful.
>
> Signed-off-by: Chris Packham <chris.pack...@a
and cpc925 this is just a cleanup.
Chris Packham (3):
EDAC: mv64x60: calculate memory size correctly
EDAC: altera: simplify calculation of total memory
EDAC: cpc925: simplify calculation of total memory
drivers/edac/altera_edac.c | 24
drivers/edac/cpc925_edac.c
Use of_address_to_resource() and resource_size() instead of manually
parsing the "reg" property from the "memory" node(s).
Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz>
---
Changes in v2:
- New
drivers/edac/cpc925_edac.c | 32 ++
Use of_address_to_resource() and resource_size() instead of manually
parsing the "reg" property from the "memory" node(s).
Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz>
---
Changes in v2:
- New
drivers/edac/altera_edac.c | 24 -
1 - 100 of 118 matches
Mail list logo
