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] [day] [month] [year] [list]
Date: Thu, 27 Jun 2024 22:43:19 +0200
From: Borislav Petkov <bp@...en8.de>
To: Serge Semin <fancer.lancer@...il.com>
Cc: Dinh Nguyen <dinguyen@...nel.org>, Michal Simek <michal.simek@....com>,
	Alexander Stein <alexander.stein@...tq-group.com>,
	Tony Luck <tony.luck@...el.com>, James Morse <james.morse@....com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Robert Richter <rric@...nel.org>,
	Manish Narani <manish.narani@...inx.com>,
	Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@...inx.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-arm-kernel@...ts.infradead.org, linux-edac@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 02/20] EDAC/synopsys: Fix generic device type
 detection procedure

On Tue, Jun 11, 2024 at 07:57:26PM +0300, Serge Semin wrote:
> Well, I see it otherwise. If you posses the databook then by using the
> references you can find the info there straight away with no need in
> struggling through the _1.5K_ pages file. If you don't have one, then
> you can just skip that part of the log.
> 
> So I'd rather leave the refs be in the log.

Sorry, we don't do elitist logs: only for the people who have access to some
specs behind a paywall or whatnot.

If those are not available freely, then you should paraphrase the relevant
information into the commit message so that it explains the problem fully and
people don't need to have access to those databooks and then state that the
docs you reference to not publicly available. And you're doing former so I can
fixup latter.

> > Nope, that's up to the maintainer to decide.
> 
> ... and the review committee,

There's a review committee? 

I must've missed the PSA. :-P

> and the linux-kernel list members may participate in the discussion too. But
> that's not the point here, right?

No, that's exactly the point - the maintainer and the submitter decide that
- not stable people or your "committee".

If someone gives a good reason why a patch should go to stable, sure, but also
the maintainer's decision in the end.

You know why? Because in reality the maintainer gets to mop it up after
everybody and fix shit.

> It's up to the maintainers to decide.

Yes, what I said.

As to the reason whether a patch qualifies for stable, read this here:

Documentation/process/stable-kernel-rules.rst

> As you can see, I do and of two IP-core major versions (and plenty of
> the DW uMCTL2 IP-core databooks). So should you need some help with
> testing the bits coming for the Synopsys DW uMCTL2 EDAC driver, just
> send a ping to me. I'll test them out.a

You can also add yourself as a reviewer for that driver and get CCed on code
submissions and test them.

I can surely use the help.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ