Re: [PATCH 1/1] fpga: m10bmc-sec: Add support for N6000

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023-01-31 at 17:13:13 +0000, Lee Jones wrote:
> On Tue, 31 Jan 2023, Xu Yilun wrote:
> 
> > On 2023-01-31 at 12:16:44 +0000, Lee Jones wrote:
> > > On Tue, 31 Jan 2023, Greg KH wrote:
> > > 
> > > > On Tue, Jan 31, 2023 at 10:58:23AM +0000, Lee Jones wrote:
> > > > > On Tue, 31 Jan 2023, Xu Yilun wrote:
> > > > > 
> > > > > > On 2023-01-31 at 09:08:35 +0000, Lee Jones wrote:
> > > > > > > On Tue, 31 Jan 2023, Xu Yilun wrote:
> > > > > > > 
> > > > > > > > From: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
> > > > > > > > 
> > > > > > > > Add support for PMCI-based flash access path and N6000 sec update
> > > > > > > > support. Access to flash staging area is different for N6000 from that
> > > > > > > > of the SPI interfaced counterparts.
> > > > > > > > 
> > > > > > > > Introduce intel_m10bmc_flash_bulk_ops to allow interface specific
> > > > > > > > differentiations for the flash access path for sec update and make
> > > > > > > > m10bmc_sec_read/write() in sec update driver to use the new operations.
> > > > > > > > The .flash_mutex serializes read/read. Flash update (erase+write) must
> > > > > > > > use ->lock/unlock_write() to prevent reads during update (reads would
> > > > > > > > timeout on setting flash MUX as BMC will prevent it).
> > > > > > > > 
> > > > > > > > Create a type specific RSU status reg handler for N6000 because the
> > > > > > > > field has moved from doorbell to auth result register.
> > > > > > > > 
> > > > > > > > If a failure is detected while altering the flash MUX, it seems safer
> > > > > > > > to try to set it back and doesn't seem harmful. Likely there are enough
> > > > > > > > troubles in that case anyway so setting it back fails too (which is
> > > > > > > > harmless sans the small extra delay) or just confirms that the value
> > > > > > > > wasn't changed.
> > > > > > > > 
> > > > > > > > Co-developed-by: Tianfei zhang <tianfei.zhang@xxxxxxxxx>
> > > > > > > > Signed-off-by: Tianfei zhang <tianfei.zhang@xxxxxxxxx>
> > > > > > > > Co-developed-by: Russ Weight <russell.h.weight@xxxxxxxxx>
> > > > > > > > Signed-off-by: Russ Weight <russell.h.weight@xxxxxxxxx>
> > > > > > > > Acked-by: Xu Yilun <yilun.xu@xxxxxxxxx>
> > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
> > > > > > > > Signed-off-by: Lee Jones <lee@xxxxxxxxxx>
> > > > > > > > Link: https://lore.kernel.org/r/20230116100845.6153-12-ilpo.jarvinen@xxxxxxxxxxxxxxx
> > > > > > > > ---
> > > > > > > >  drivers/fpga/intel-m10-bmc-sec-update.c |  51 ++++-
> > > > > > > >  drivers/mfd/intel-m10-bmc-pmci.c        | 242 +++++++++++++++++++++++-
> > > > > > > >  include/linux/mfd/intel-m10-bmc.h       |  51 +++++
> > > > > > > >  3 files changed, 336 insertions(+), 8 deletions(-)
> > > > > > > 
> > > > > > > I'm confused, what are you trying to achieve?
> > > > > > 
> > > > > > I'm trying to submit the last patch to Greg's char-misc-next for
> > > > > > v6.3-rc1. The first 10 patches in this series have been accepted by him
> > > > > > in this cycle.
> > > > > > 
> > > > > > This is the only one patch so I just send it rather than making an extra
> > > > > > pull request.
> > > > > 
> > > > > That doesn't work with commits being routed in via multiple subsystems
> > > > > simultaneously.  You'll end up with complications due to differing
> > > > > commit SHAs.
> > > > > 
> > > > > If you really need this patch to be applied to FPGA (hint: I don't think
> > > > > it matters), then Greg will need to pull v2 [0] of the immutable topic
> > 
> > It doesn't matter.
> > 
> > When I received the pull request v1, I thought Lee want the immutable topic
> > branch be merged to fpga tree. So I pulled and submitted them to Greg
> > along with other fpga patches. Sorry for the misunderstanding.
> 
> Maintainer => maintainer pull-requests are optional.  They're super
> useful if you want to keep developing a particular driver that has been
> changed elsewhere, since they ensure the avoidance of merge-conflicts at
> merge time.
> 
> If you're not attempting to make further changes, there shouldn't be any
> requirement to pull them.

OK. Thanks for your explanation.

Yilun

>  
> > I'm not sure if this makes trouble for Greg to pull v2 or MFD tree.
> 
> Honesty, I'd just leave it as it is.  It would have been more
> problematic if a patch which appears earlier in the set was missing,
> since this may hurt bisectability or render a tree un-buildable.  As it
> stands, it's the last patch, which no other patch in the series should
> depend on.
> 
> -- 
> Lee Jones [李琼斯]



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux