[GIT PULL] EDAC updates for v6.4

[GIT PULL] EDAC updates for v6.4

[Borislav Petkov]

Hi Linus,

please pull the latest lineup of EDAC changes for v6.4.

For some stupid reason (juggling gazillion things at the same time,
probably) I have based the edac-amd64 branch *not* ontop of plain
v6.3-rc3 but there are a couple more of your merges ontop.

I.e., the actual base is v6.3-rc3-12-g17214b70a159, as it says below.

The branch is otherwise fine, those merges are unrelated, it has
passed testing and has been in linux-next for almost a month now.

I didn't want to rebase to have a clean base because that would've
altered commit IDs and that's a no-no.

So pls lemme know if there's something I need to do or whether that
looks ok this way.

Thanks and sorry.

---
The following changes since commit 17214b70a159c6547df9ae204a6275d983146f6b:

  Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux (2023-03-20 15:20:33 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_updates_for_v6.4

for you to fetch changes up to ce8ac91130b96f651cf6b5245668dfa4969c9c42:

  Merge branches 'edac-drivers', 'edac-amd64' and 'edac-misc' into edac-updates (2023-04-24 09:14:30 +0200)

----------------------------------------------------------------
- skx_edac: Fix overflow when decoding 32G DIMM ranks

- i10nm_edac: Add Sierra Forest support

- amd64_edac: Split driver code between legacy and SMCA systems. The
  final goal is adding support for more hw, like GPUs

- The usual minor cleanups and fixes

----------------------------------------------------------------
Borislav Petkov (AMD) (2):
      EDAC: Sanitize MODULE_AUTHOR strings
      Merge branches 'edac-drivers', 'edac-amd64' and 'edac-misc' into edac-updates

Deepak R Varma (1):
      EDAC/altera: Remove redundant error logging

Jonathan Neuschäfer (1):
      EDAC/amd81[13]1: Remove trailing newline from MODULE_AUTHOR

Jongwoo Han (1):
      EDAC/i5100: Fix typo in comment

Muralidhara M K (11):
      EDAC/amd64: Merge struct amd64_family_type into struct amd64_pvt
      EDAC/amd64: Split prep_chip_selects() into dct/umc functions
      EDAC/amd64: Split read_base_mask() into dct/umc functions
      EDAC/amd64: Split determine_memory_type() into dct/umc functions
      EDAC/amd64: Split read_mc_regs() into dct/umc functions
      EDAC/amd64: Split ecc_enabled() into dct/umc functions
      EDAC/amd64: Split setup_mci_misc_attrs() into dct/umc functions
      EDAC/amd64: Split determine_edac_cap() into dct/umc functions
      EDAC/amd64: Split init_csrows() into dct/umc functions
      EDAC/amd64: Split dump_misc_regs() into dct/umc functions
      EDAC/amd64: Add get_err_info() to pvt->ops

Nick Alcock (1):
      EDAC/altera: Remove MODULE_LICENSE in non-module

Qiuxu Zhuo (2):
      EDAC/skx: Fix overflows on the DRAM row address mapping arrays
      EDAC/i10nm: Add Intel Sierra Forest server support

Yang Li (1):
      EDAC/amd64: Fix indentation in umc_determine_edac_cap()

Yazen Ghannam (6):
      EDAC/amd64: Rename debug_display_dimm_sizes()
      EDAC/amd64: Split get_csrow_nr_pages() into dct/umc functions
      EDAC/amd64: Drop dbam_to_cs() for Family 17h and later
      EDAC/amd64: Do not discover ECC symbol size for Family 17h and later
      EDAC/amd64: Rework hw_info_{get,put}
      EDAC/amd64: Rename f17h_determine_edac_ctl_cap()

 drivers/edac/altera_edac.c     |   10 +-
 drivers/edac/amd64_edac.c      | 1020 ++++++++++++++++++----------------------
 drivers/edac/amd64_edac.h      |   67 +--
 drivers/edac/amd8111_edac.c    |    2 +-
 drivers/edac/amd8131_edac.c    |    2 +-
 drivers/edac/e752x_edac.c      |    2 +-
 drivers/edac/e7xxx_edac.c      |    3 +-
 drivers/edac/i10nm_base.c      |    1 +
 drivers/edac/i5000_edac.c      |    7 +-
 drivers/edac/i5100_edac.c      |    5 +-
 drivers/edac/i82860_edac.c     |    3 +-
 drivers/edac/layerscape_edac.c |    3 +-
 drivers/edac/mpc85xx_edac.c    |    3 +-
 drivers/edac/r82600_edac.c     |    3 +-
 drivers/edac/skx_base.c        |    4 +-
 15 files changed, 490 insertions(+), 645 deletions(-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] EDAC updates for v6.4

[Linus Torvalds]

On Mon, Apr 24, 2023 at 12:28 AM Borislav Petkov <bp@alien8.de> wrote:
>
> For some stupid reason (juggling gazillion things at the same time,
> probably) I have based the edac-amd64 branch *not* ontop of plain
> v6.3-rc3 but there are a couple more of your merges ontop.

It's fine. Mistakes happen, and honestly, the "base your work on top
of a stable point" is - like almost everything else in life - a
recommendation for everybody's sanity, rather than any kind of
black-and-white rule.

And it comes mainly from people actively mis-using git, and merging
random upstream state without thought, and trying to set that kind of
behavior right, and have people _think_ about it.

IOW, it's not some "this gets enforced" thing - it's more of a "you
did something else horribly wrong, so let's clarify what the 'good
thoughtful git behavior' should be".

Sometimes starting at a random point can even be a feature - random
cleanups that depend on some helper that was added last release, and
it's just much more convenient to start at point X ratherr than wait
for the next -rc.

Now, the thing I do hope that people actively try to avoid is picking
a "kernel of the day" during the merge window to start on, but even
that is less about "well-defined starting point" and more about just
the fact that the merge window kernel *can* be really unstable and is
a really bad base.

But some "rc3+" kernel is certainly not that kind of _horribly_ bad
kernel to start at. It's probably better than starting at a rc1
release in practice.

So the "try to use a reasonably stable starting point" really is a
general recommendation, and mostly a reaction against people who tend
to do more of a mindless "rebase/merge to today's kernels without any
thought" kind of workflow.

So I'm not asking for surgical precision. I'm asking for "reasonable
workflow", where people avoid doing pointlessly silly things.

                 Linus

Re: [GIT PULL] EDAC updates for v6.4

[Borislav Petkov]

On Tue, Apr 25, 2023 at 09:55:14AM -0700, Linus Torvalds wrote:
> So I'm not asking for surgical precision. I'm asking for "reasonable
> workflow", where people avoid doing pointlessly silly things.

As always, I really appreciate elaborating on the whole reasoning behind
this.

While we're on the topic: when we send you tip urgent fixes, we base
each branch off of the current -rc, put the urgent fixes ontop, test,
... and send them to you in a week's time, roughly.

Now, after you've pulled, we could fast-forward the urgent branch to the
next -rc where new fixes come - and I do that most of the time - or we
could not do that because of, as you say, if there's no really good
reason to fast-forward (important other fix, new functionality from the
newest -rc a patch needs, yadda yadda) then those urgent branches do not
necessarily have to be fast-forwarded but simply get more fixes applied
ontop.

Right, that makes sense.

Oh, and I'm sure if a branch is based on what looks like a random point
but there's a good explanation accompanying it why it is based on that
random point, then I guess that's perfectly fine too.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] EDAC updates for v6.4

[Linus Torvalds]

On Tue, Apr 25, 2023 at 10:35 AM Borislav Petkov <bp@alien8.de> wrote:
>
> While we're on the topic: when we send you tip urgent fixes, we base
> each branch off of the current -rc, put the urgent fixes ontop, test,
> ... and send them to you in a week's time, roughly.
>
> Now, after you've pulled, we could fast-forward the urgent branch to the
> next -rc where new fixes come - and I do that most of the time - or we
> could not do that because of, as you say, if there's no really good
> reason to fast-forward (important other fix, new functionality from the
> newest -rc a patch needs, yadda yadda) then those urgent branches do not
> necessarily have to be fast-forwarded but simply get more fixes applied
> ontop.

That sounds right. Do the fast-forward thing if you want to update to
a newer rc for some other reason, but if there's no major other thing
going on, you can easily just continue on top of your existing fixes
branch.

There's no reason to actively seek a new base if you already had a
stable base that you were on.

So whatever works best for you.

(Of course, at some point "that base is just _really_ old" becomes a
reason in itself, and then fast-forwarding to have a newer base to do
your fixes on top just becomes a convenience)

> Oh, and I'm sure if a branch is based on what looks like a random point
> but there's a good explanation accompanying it why it is based on that
> random point, then I guess that's perfectly fine too.

Absolutely. Things that look wrong when I look at the pull request
result may have good reasons for them. If you know there's something
odd going on but you had a particular reason to do it that way, just
mention it.

For example - I can get quite upset when I see that all the commits
are very recent and have clearly not had a lot of testing. But if that
isn't your usual pattern, and you had a clear *reason* for the commits
all being shiny and new ("I had to rebase to remove a completely
broken commit"), please mention it.

Of course, if that particular reason keeps on happening, and there' sa
continual stream of "I know I did things wrong, but it was because of
X", then maybe that "X" is a huge problem and should be fixed?

So the occasional oddity with explanations is perfectly fine. But a
consistent _pattern_ of oddities is a problem, explanations
notwithstanding.

              Linus

Re: [GIT PULL] EDAC updates for v6.4

[pr-tracker-bot]

The pull request you sent on Mon, 24 Apr 2023 09:28:36 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_updates_for_v6.4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e94ee641f9cef2502adfe5e0c264b271420c7ab5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html