linux-kernel - Re: [PATCH] mfd: intel-m10-bmc: Change staging size to a variable

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: Tue, 2 Apr 2024 18:44:31 +0000
From: "Colberg, Peter" <peter.colberg@...el.com>
To: "russ.weight@...ux.dev" <russ.weight@...ux.dev>,
	"yilun.xu@...ux.intel.com" <yilun.xu@...ux.intel.com>
CC: "Xu, Yilun" <yilun.xu@...el.com>, "linux-fpga@...r.kernel.org"
	<linux-fpga@...r.kernel.org>, "lee@...nel.org" <lee@...nel.org>,
	"mdf@...nel.org" <mdf@...nel.org>, "Wu, Hao" <hao.wu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Pagani,
 Marco" <marpagan@...hat.com>, "russell.h.weight@...el.com"
	<russell.h.weight@...el.com>, "Rix, Tom" <trix@...hat.com>,
	"matthew.gerlach@...ux.intel.com" <matthew.gerlach@...ux.intel.com>,
	"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>
Subject: Re: [PATCH] mfd: intel-m10-bmc: Change staging size to a variable

On Tue, 2024-04-02 at 14:52 +0800, Xu Yilun wrote:
> On Mon, Apr 01, 2024 at 10:19:47AM -0700, Russ Weight wrote:
> > 
> > On Mon, Apr 01, 2024 at 10:09:05AM -0700, Russ Weight wrote:
> > > On Mon, Apr 01, 2024 at 05:46:29PM +0800, Xu Yilun wrote:
> > > > On Thu, Mar 28, 2024 at 07:35:59PM -0400, Peter Colberg wrote:
> > > > > From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> > > > > 
> > > > > The size of the staging area in FLASH for FPGA updates is dependent on the
> > > > > size of the FPGA. Currently, the staging size is defined as a constant.
> > > > > Larger FPGAs are coming soon and it will soon be necessary to support
> > > > 
> > > > Soon? When? You cannot add some feature without a user case. If you do
> > > > have a use case, put the patch in the same patchset.
> > > 
> > > There may never be an up-streamed use-case. This is a very small
> > > change intended to make it easier for a third-party vendor to
> > > build a card that requires a larger staging area in FLASH. They
> > > would have to add a new "struct m10bmc_csr_map", but they
> > > wouldn't have to refactor this code as part of the change
> 
> I'm OK with this description.
> 
> Peter, is that what you mean?

Yes.

> Or you do have a board type to follow, in
> which case you need to submit the new board type as well.
> 
> > > 
> > > This change does not introduce an unused function or variable.
> > > It is more of a clean-up, making the code more flexible.
> > > 
> > > Can it not be taken as is?
> > 
> > Would it be acceptable to just change the commit message to something
> > like:
> > 
> > Do not hardwire the staging size in the secure update driver. Move
> > the staging size to the m10bmc_csr_map structure to make the size
> > assignment more flexible.
> 
> That would be much better.

Thanks Russ, thanks Yilun, I will send a revised patch.

Peter

> 
> Thanks,
> Yilun