linux-kernel - Re: [PATCH 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]

Message-ID: <bc717da6-0bac-b198-3047-293165e65925@deltatee.com>
Date:   Thu, 29 Jun 2017 12:33:21 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Allen Hubbe <Allen.Hubbe@...l.com>, linux-ntb@...glegroups.com,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     'Jon Mason' <jdmason@...zu.us>,
        '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 14/16] switchtec_ntb: implement scratchpad registers

On 6/29/2017 12:11 PM, Allen Hubbe wrote:
> This could get in the way of letting the driver support more than two ports later on.  Is there already a plan to change this to support more than two ports?

Well, as I mentioned this patchset is only to support 2 ports. Future 
work will expand this and remove the restriction. The core concept of 
the emulated spads doesn't get in the way but will need some further 
consideration.

But multi-port support will need a lot more work in the ntb clients 
anyway. There's no sense having support in my driver until I can 
actually test things. And I'll probably be fine doing some of the client 
work once we get there.

> This is also not the only hardware to lack scratchpads, but does have memory windows.  Wouldn't it be better for a software substitute like this to be done in a way that it is not tied to a specific hardware driver?

Yeah, we discussed this previously. Some of this is kind of hardware 
dependent though. In this case we are using a small fixed size LUT 
window. If the other hardware doesn't have similar support, using up one 
of the BAR memory windows (which are a very limited resource) for this 
might not make sense.

The switchtec driver also uses this special memory window to negotiate 
link status.

Anyway, I'm happy to collaborate to making what common parts we can 
possible with the IDT driver but Serge seemed against the whole concept 
of emulation.

Logan