[v9,0/8] EDAC drivers for Armada XP L2 and DDR

Message

Chris Packham July 12, 2019, 3:48 a.m. UTC

Hi,

I still seem to be struggling to get this on anyone's radar.

The Reviews/Acks have been given so this should be good to go in via the ARM
tree as planned.

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html

This series adds drivers for the L2 cache and DDR RAM ECC functionality as
found on the MV78230/MV78x60 SoCs. Jan has tested these changes with the
MV78460 (on a custom board with a DDR3 ECC DIMM), Chris has tested these
changes with 88F6820 and 98dx3236 (both a custom boards with fixed DDR3 + ECC).

Also contained in this series is an additional debugfs wrapper.

Compared to the previous v8 series this has been rebased against
v5.2-5628-g753c8d9b7d81 to avoid some conflicts related to debugfs API changes.

Compared to the previous v7 series this has been rebased against 5.1 requiring
some changes in the devicetree binding documentation.

Compared to the previous v6 series I've dropped the marvell,ecc-disable
property.

Compared to the previous v5 series I've split the dt-binding documentation into
its own patch and updated armada_xp_edac.c to use a SPDX license.

Compared to the previous v4 series I've added my s-o-b to some of Jan's
patches and rebased against v4.19.0.

Compared to the previous v3 series, the following changes have been made:
- Use shorter names for the AURORA ECC and parity registers
- Numerous formatting changes to edac/armada_xp.c (as requested by Boris)
- Added support for Armada-38x and 98dx3236 SoCs

Compared to the previous v2 series, the following changes have been made:
- Allocate EDAC structures later during probing and drop devres support
  patches (requested by Boris)
- Make drvdata->width usage consistent according to the comment (suggested by
  Chris)

Compared to the previous v1 series, the following changes have been made:
- Add the aurora-l2 register defines earlier in the series (suggested by
  Russell King and Gregory CLEMENT )
- Changed the DT vendor prefix from "arm" to "marvell" for the ecc-enable/disable
  properties on the aurora-l2 (suggested by Russell King)
- Fix some warnings reported by checkpatch

Compared to the original RFC series, the following changes have been made:
- Integrated Chris' patches for parity and ECC configuration via DT
- Merged the DDR RAM and L2 cache drivers (as requested by Boris, analogous
  to fsl_ddr_edac.c and mpc85xx_edac.c)
- Added myself to MAINTAINERS (requested by Boris)
- L2 cache: Track the msg size and use snprintf (review comment by Chris)
- L2 cache: Split error injection from the check function (review comment by
  Chris)
- DDR RAM: Allow 16 bit width in addition to 32 and 64 bit (review comment by
  Chris)
- Use of_match_ptr() (review comments by Chris)
- Minor checkpatch cleanups


Chris Packham (4):
  ARM: l2x0: support parity-enable/disable on aurora
  dt-bindings: ARM: document marvell,ecc-enable binding
  ARM: l2x0: add marvell,ecc-enable property for aurora
  EDAC: armada_xp: Add support for more SoCs

Jan Luebbe (4):
  ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  ARM: aurora-l2: add defines for parity and ECC registers
  EDAC: Add missing debugfs_create_x32 wrapper
  EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

 .../devicetree/bindings/arm/l2c2x0.yaml       |   4 +
 MAINTAINERS                                   |   6 +
 .../include/asm/hardware/cache-aurora-l2.h    |  50 +-
 arch/arm/mm/cache-l2x0.c                      |  16 +-
 drivers/edac/Kconfig                          |   7 +
 drivers/edac/Makefile                         |   1 +
 drivers/edac/armada_xp_edac.c                 | 635 ++++++++++++++++++
 drivers/edac/debugfs.c                        |  11 +
 drivers/edac/edac_module.h                    |   4 +
 9 files changed, 731 insertions(+), 3 deletions(-)
 create mode 100644 drivers/edac/armada_xp_edac.c

Comments

James Morse July 26, 2019, 2:53 p.m. UTC | #1

Hi Chris,

On 12/07/2019 04:48, Chris Packham wrote:
> I still seem to be struggling to get this on anyone's radar.

Whose radar does it need to cross?


> The Reviews/Acks have been given so this should be good to go in via the ARM
> tree as planned.
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html

For your v8 I took this to mean this series was done!

If nothing has changed with Boris and Russell's decision (it was two years ago....),
details of the patch system are here:

https://lore.kernel.org/linux-arm-kernel/[e-mail]/


Thanks,

James

Chris Packham July 28, 2019, 8:33 p.m. UTC | #2

On Fri, 2019-07-26 at 15:53 +0100, James Morse wrote:
> Hi Chris,
> 
> On 12/07/2019 04:48, Chris Packham wrote:
> > 
> > I still seem to be struggling to get this on anyone's radar.
> Whose radar does it need to cross?
> 

That's a good question. The last solid guidance I had was that this
series was going in via the ARM tree. But as you say below that was two
years ago.

I only realised recently that the ARM core seems to have a different
workflow to other kernel subsystems.

> 
> > 
> > The Reviews/Acks have been given so this should be good to go in
> > via the ARM
> > tree as planned.
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/5
> > 25561.html
> For your v8 I took this to mean this series was done!
> 
> If nothing has changed with Boris and Russell's decision (it was two
> years ago....),
> details of the patch system are here:
> 
> https://lore.kernel.org/linux-arm-kernel/20190624142346.pxljv3m4npatd
> [e-mail]/
> 

Thanks for the link. I would have never found that. I did try to follow
what I could find on https://www.armlinux.org.uk/developer/ but a lot
of that seems to be out of date.

I did manage to submit v9  to the ARM patch tracker but naturally I
messed it up the first time https://www.armlinux.org.uk/developer/patch
es/viewpatch.php?id=8877/1 and I'm not sure I got the second attempt
right either https://www.armlinux.org.uk/developer/patches/viewpatch.ph
p?id=8885/1


> Thanks,
> 
> James