linux-kernel - Re: [PATCH 2/3] EDAC, amd64_edac: Extend scrub rate programmability feature for F15hM60h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Sep 2015 18:33:14 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>
Cc:	mchehab@....samsung.com, dougthompson@...ssion.com,
	linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] EDAC, amd64_edac: Extend scrub rate programmability
 feature for F15hM60h

On Thu, Sep 24, 2015 at 11:15:08AM -0500, Aravind Gopalakrishnan wrote:
> I was thinking it's a little better from readability POV to separate out the
> for loop which does the job of finding the scrub value to program;
> And __set_scrub_rate() writes the value to the appropriate register.
> 
> Maybe I am making it too modular?

Yeah, you are.

The function is perfectly readable the way it is, it even fits on the
half of my screen :)

Also, it didn't really make things better - it added that *scrub_bw
argument which is a second output argument. AFAIR, it even used to be
like that at some point in time...

And that's ugly - I much prefer having input arguments being input only
and return values being return values only. If it can be helped, that
is. And in this case, it is not necessary.

> I realize it's unrelated to the patch and it's not doing something useful;
> But I was thinking I'll fix the above indentation issues to keep indent
> rules consistent and since I was touching the file anyway.
> Can remove those in a V2..

Yeah, I believe we've talked about this before: a patch should do one
logical change and one logical change *only* - no other unrelated hunks
belong in it.

Otherwise, they make reviewing it harder by making me wonder why is that
hunk there and what does it have to do with the scrub rate changes.
Unrelated hunks can - further down the road - complicate bisection and
cherry-picking for other kernels.

So please try to restrain yourself to do solely the one logical change
your patch addresses.

If you feel that some more work needs to be done on the file or the
whole driver, you can always send *separate* patches ontop which we can
discuss.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/