> -----Original Message----- > From: Borislav Petkov <b...@alien8.de> > Sent: Friday, August 2, 2019 1:50 AM > To: Ghannam, Yazen <yazen.ghan...@amd.com> > Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 1/7] EDAC/amd64: Support more than two controllers for > chip selects handling > > On Tue, Jul 09, 2019 at 09:56:54PM +0000, Ghannam, Yazen wrote: > > From: Yazen Ghannam <yazen.ghan...@amd.com> > > > > The struct chip_select array that's used for saving chip select bases > > and masks is fixed at length of two. There should be one struct > > chip_select for each controller, so this array should be increased to > > support systems that may have more than two controllers. > > > > Increase the size of the struct chip_select array to eight, which is the > > largest number of controllers per die currently supported on AMD > > systems. > > > > Fix number of DIMMs and Chip Select bases/masks on Family17h, because AMD > > Family 17h systems support 2 DIMMs, 4 CS bases, and 2 CS masks per > > channel. > > > > Also, carve out the Family 17h+ reading of the bases/masks into a > > separate function. This effectively reverts the original bases/masks > > reading code to before Family 17h support was added. > > > > This is a second version of a commit that was reverted. > > > > Fixes: 07ed82ef93d6 ("EDAC, amd64: Add Fam17h debug output") > > Fixes: 8de9930a4618 ("Revert "EDAC/amd64: Support more than two controllers > > for chip select handling"") > > I'm not sure about those Fixes: tags you're slapping everywhere. First > of all, 8de9930a4618 is a revert so how can this be fixing a revert? If > anything, it should be fixing the original commit > > 0a227af521d6 ("EDAC/amd64: Support more than two controllers for chip > select handling") > > which tried the more-than-2-memory-controllers thing. > > But, it is not really a fix for that commit but a second attempt at it. > Which is not really a fix but hw enablement. > > So I'm dropping those tags here. If you want them in stable, pls > backport them properly and test them on the respective stable kernels > before sending them to stable. >
Okay, no problem. Should I drop the Fixes tags on any other of the patches in this set? Thanks, Yazen