linux-kernel - RE: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers

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:   Wed, 2 Aug 2017 09:06:42 -0400
From:   "Allen Hubbe" <Allen.Hubbe@...l.com>
To:     "'Logan Gunthorpe'" <logang@...tatee.com>,
        "'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>,
        "'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

From: Logan Gunthorpe
> 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.

The proposed change, removing use of spads from transport, would not affect ntrdma.

> 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