[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dda576ad-d3ca-814b-f0cf-478cbb61adf2@deltatee.com>
Date: Tue, 1 Aug 2017 16:26:57 -0600
From: Logan Gunthorpe <logang@...tatee.com>
To: Jon Mason <jdmason@...zu.us>
Cc: linux-ntb@...glegroups.com, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, Dave Jiang <dave.jiang@...el.com>,
Allen Hubbe <Allen.Hubbe@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kurt Schwemmer <kurt.schwemmer@...rosemi.com>,
Stephen Bates <sbates@...thlin.com>,
Serge Semin <fancer.lancer@...il.com>
Subject: Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers
On 01/08/17 01:10 PM, Jon Mason wrote:
> It would probaly be better if I remarked about the SPADs in the actual
> patch about the SPADS :)
>
> The whole point of using the SPADs in the NTB driver was to workaround
> the problems establishing a connection between the two sides of the
> NTB and where everything lives. So, using a MW to get around the
> SPADs is sort of backwards (and slightly funny). I realize you are
> trying to use the existing transport with minimal changes to enable
> your hardware, and thus this makes logical sense to you. However, if
> the SPADs are not really needed, then we should either remove them
> from the transport (or use them for something else).
>
> Per my comment in the other patch, I'm amenable to take this series
> as-is, assuming you are willing to address this design issue in the
> near future. Thoughts?
Yes, I agree. I'd be willing to help but it seems the clients are
written the way they are for the other drivers, so it's their needs
(which I'm not fully aware of) that have to be considered.
I've also made all the other changes you sent as well as the file rename
Dave requested. Once I see the bug fix patch you were going to pull hit
ntb-next I'll rebase, test and resubmit.
Thanks,
Logan
Powered by blists - more mailing lists