[net-next PATCH] net: freescale: ucc_geth: remove unused SKB_ALLOC_TIMEOUT

2020-11-29 Thread Chris Packham
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

Re: [PATCH] spi: fsl-espi: Only process interrupts for expected events

2020-09-23 Thread Chris Packham
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

Re: [PATCH] spi: fsl-espi: Only process interrupts for expected events

2020-09-13 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-09-06 Thread Chris Packham
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,

Re: fsl_espi errors on v5.7.15

2020-09-06 Thread Chris Packham
(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

[PATCH] spi: fsl-espi: Only process interrupts for expected events

2020-09-03 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-09-03 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-09-01 Thread Chris Packham
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:

Re: fsl_espi errors on v5.7.15

2020-09-01 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-31 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-31 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-30 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-30 Thread Chris Packham
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:

Re: fsl_espi errors on v5.7.15

2020-08-27 Thread Chris Packham
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: >>>

Re: fsl_espi errors on v5.7.15

2020-08-26 Thread Chris Packham
(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: >>>>

Re: fsl_espi errors on v5.7.15

2020-08-26 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-25 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-25 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-24 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-24 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-19 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-18 Thread Chris Packham
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

Re: fsl_espi errors on v5.7.15

2020-08-16 Thread Chris Packham
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

fsl_espi errors on v5.7.15

2020-08-13 Thread Chris Packham
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

Re: [PATCH] powerpc/legacy_serial: Use early_ioremap()

2020-08-09 Thread Chris Packham
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

Re: OF: Can't handle multiple dma-ranges with different offsets

2020-07-30 Thread Chris Packham
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

Re: OF: Can't handle multiple dma-ranges with different offsets

2020-07-22 Thread Chris Packham
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

OF: Can't handle multiple dma-ranges with different offsets

2020-07-21 Thread Chris Packham
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

[PATCH v3 2/2] powerpc: configs: remove CMDLINE_BOOL

2020-06-11 Thread Chris Packham
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

[PATCH v3 1/2] powerpc: Remove inaccessible CMDLINE default

2020-06-11 Thread Chris Packham
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

[PATCH v3 0/2] powerpc: CMDLINE config cleanup

2020-06-11 Thread Chris Packham
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

Re: [PATCH v2] powerpc: Remove inaccessible CMDLINE default

2020-06-11 Thread Chris Packham
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

[PATCH v2] powerpc: Remove inaccessible CMDLINE default

2020-06-10 Thread Chris Packham
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

[PATCH v3] powerpc/setup_64: Set cache-line-size based on cache-block-size

2020-04-16 Thread Chris Packham
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

Re: [PATCH v2] powerpc/setup_64: Set cache-line-size based on cache-block-size

2020-04-16 Thread Chris Packham
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, > > &

Re: [PATCH v2] powerpc/setup_64: Set cache-line-size based on cache-block-size

2020-04-15 Thread Chris Packham
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. > >

[PATCH v2] powerpc/setup_64: Set cache-line-size based on cache-block-size

2020-03-24 Thread Chris Packham
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

Re: [PATCH] powerpc/fsl: Add cache properties for T2080/T2081

2020-03-24 Thread Chris Packham
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

Re: [PATCH] powerpc/fsl: Add cache properties for T2080/T2081

2020-03-24 Thread Chris Packham
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

[PATCH] powerpc/fsl: Add cache properties for T2080/T2081

2020-03-24 Thread Chris Packham
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

Re: Argh, can't find dcache properties !

2020-03-24 Thread Chris Packham
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

Re: [PATCH] powerpc/legacy_serial: Use early_ioremap()

2020-03-23 Thread Chris Packham
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. >

Argh, can't find dcache properties !

2020-03-22 Thread Chris Packham
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

Re: [PATCH v3] powerpc: Support CMDLINE_EXTEND

2019-11-06 Thread Chris Packham
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

Re: [PATCH v3] powerpc: Support CMDLINE_EXTEND

2019-09-26 Thread Chris Packham
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

Re: [PATCH] powerpc/64e: drop stale call to smp_processor_id() which hangs SMP startup

2019-08-08 Thread Chris Packham
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

Re: SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)

2019-08-06 Thread Chris Packham
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

Re: SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)

2019-08-06 Thread Chris Packham
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

Re: SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)

2019-08-05 Thread Chris Packham
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

SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)

2019-08-04 Thread Chris Packham
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

Re: [PATCH] powerpc: Remove inaccessible CMDLINE default

2019-08-04 Thread Chris Packham
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

[PATCH] powerpc: Remove inaccessible CMDLINE default

2019-08-01 Thread Chris Packham
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

[PATCH v3] powerpc: Support CMDLINE_EXTEND

2019-08-01 Thread Chris Packham
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

Re: [PATCH v2] powerpc: Support CMDLINE_EXTEND

2019-08-01 Thread Chris Packham
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

[PATCH v2] powerpc: Support CMDLINE_EXTEND

2019-07-31 Thread Chris Packham
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

Re: [PATCH] powerpc: Support CMDLINE_EXTEND

2019-07-31 Thread Chris Packham
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

Re: [PATCH] powerpc: Support CMDLINE_EXTEND

2019-07-30 Thread Chris Packham
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

[PATCH] powerpc: Support CMDLINE_EXTEND

2019-07-23 Thread Chris Packham
-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

pci memory resources not being assigned to bridge

2019-07-03 Thread Chris Packham
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

Re: [PATCH] EDAC, mv64x60: Remove some code duplication

2018-01-14 Thread Chris Packham
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

Re: [PATCH v3 1/3] EDAC: mv64x60: check driver registration success

2017-06-06 Thread Chris Packham
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

EDAC: simplify total memory calculation

2017-06-06 Thread Chris Packham
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

[PATCH v2 3/3] EDAC: cpc925: simplify calculation of total memory

2017-06-06 Thread Chris Packham
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 ++

[PATCH v2 2/3] EDAC: altera: simplify calculation of total memory

2017-06-06 Thread Chris Packham
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 -

[PATCH v2 1/3] EDAC: mv64x60: calculate memory size correctly

2017-06-06 Thread Chris Packham
The #address-cells and #size-cells properties need to be accounted for when dealing with the "memory" device tree node. Use of_address_to_resource() and resource_size() to retrieve the size of the memory node which will automatically take the #cells into account. Signed-off-by: Chr

[PATCH v3 3/3] EDAC: mv64x60: replace in_le32/out_le32 with readl/writel

2017-05-29 Thread Chris Packham
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 Packham <chris.pack...@alliedtelesis.co.nz> --- Changes in v2: - use readl/writel as suggested. Changes in v3: - None drivers/edac/mv64x60_edac.

[PATCH v3 1/3] EDAC: mv64x60: check driver registration success

2017-05-29 Thread Chris Packham
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...@alliedtelesis.co.nz> --- Changes in v3: - catch the

[PATCH v3 2/3] EDAC: mv64x60: Fix pdata->name

2017-05-29 Thread Chris Packham
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 <chris.pack...@alliedtelesis.co.nz> --- Changes in v3: - None drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH v3 0/3] EDAC: mv64x60: updates

2017-05-29 Thread Chris Packham
set of changes for this driver but this first set is just a series of cleanups. Chris Packham (3): EDAC: mv64x60: check driver registration success EDAC: mv64x60: Fix pdata->name EDAC: mv64x60: replace in_le32/out_le32 with readl/writel drivers/edac/mv64x60_edac.c |

[PATCH v2 3/3] EDAC: mv64x60: replace in_le32/out_le32 with readl/writel

2017-05-18 Thread Chris Packham
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 Packham <chris.pack...@alliedtelesis.co.nz> --- Notes: Changes in v2: - use readl/writel as suggested. drivers/edac/mv64x60_edac.

[PATCH v2 0/3] EDAC: mv64x60: updates

2017-05-18 Thread Chris Packham
set of changes for this driver but this first set is just a series of cleanups. Chris Packham (3): EDAC: mv64x60: remove unused variable EDAC: mv64x60: Fix pdata->name EDAC: mv64x60: replace in_le32/out_le32 with readl/writel drivers/edac/mv64x60_edac.c |

[PATCH v2 1/3] EDAC: mv64x60: remove unused variable

2017-05-18 Thread Chris Packham
Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz> --- drivers/edac/mv64x60_edac.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c index 14b7e7b71eaa..454e1e26ee7c 100644 --- a/drivers/edac/mv64x60_edac.c +++ b/d

[PATCH v2 2/3] EDAC: mv64x60: Fix pdata->name

2017-05-18 Thread Chris Packham
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 <chris.pack...@alliedtelesis.co.nz> --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/d

Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

2017-05-17 Thread Chris Packham
s... > > 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 Packham

Re: syscall statx not implemented on powerpc

2017-03-14 Thread Chris Packham
On 15/03/17 00:57, Michael Ellerman wrote: > Chris Packham <chris.pack...@alliedtelesis.co.nz> writes: > >> On 13/03/17 21:52, Chandan Rajendra wrote: >>> On Monday, March 13, 2017 03:33:07 AM Chris Packham wrote: >>>> Hi, >>>> >>>> I'

Re: syscall statx not implemented on powerpc

2017-03-13 Thread Chris Packham
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 following &

syscall statx not implemented on powerpc

2017-03-12 Thread Chris Packham
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

[PATCH] Documentation: powerpc/fsl: Update compatible for l2cache binding

2017-02-02 Thread Chris Packham
List all the current valid compatible strings for the l2cache binding. This should stop checkpatch.pl from complaining and will hopefully save someone from having to debug a typo in their dts. Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz> --- .../devicetree/bindings/p

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

2017-02-02 Thread Chris Packham
On 03/02/17 12:55, Michael Ellerman wrote: > Chris if you want to send a patch to add the compatible string to the > l2cache.txt I would merge that, but honestly it doesn't achieve much > other than possibly catching a typo in the compatible name. I think catching a typo might be worthwhile. It's

Re: [PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

2017-02-01 Thread Chris Packham
On 02/02/17 12:28, Borislav Petkov wrote: > On Thu, Feb 02, 2017 at 12:16:24PM +1300, Chris Packham wrote: >> The l2-cache controller on the T2080 SoC has similar capabilities to the >> others already supported by the mpc85xx_edac driver. Add it to the list >> of compatible

[PATCH v2] EDAC: mpc85xx: Add T2080 l2-cache support

2017-02-01 Thread Chris Packham
The l2-cache controller on the T2080 SoC has similar capabilities to the others already supported by the mpc85xx_edac driver. Add it to the list of compatible devices. Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz> Acked-by: Johannes Thumshirn <j...@k

[PATCH] EDAC: mpc85xx: Add T2080 l2-cache support

2016-11-28 Thread Chris Packham
The l2-cache controller on the T2080 SoC has similar capabilities to the others already supported by the mpc85xx_edac driver. Add it to the list of compatible devices. Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz> --- arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 1 + d