Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754096AbdFVWtq (ORCPT ); Thu, 22 Jun 2017 18:49:46 -0400 Received: from ale.deltatee.com ([207.54.116.67]:55137 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754068AbdFVWtc (ORCPT ); Thu, 22 Jun 2017 18:49:32 -0400 To: Allen Hubbe , "'Jon Mason'" References: <20170615203729.9009-1-logang@deltatee.com> <20170619200659.GA20437@kudzu.us> <9615f074-5b81-210b-eb88-218a59d65198@deltatee.com> <000001d2eb85$daecdea0$90c69be0$@dell.com> <8a1ff94c-8689-0d4c-cc33-7b495daa065a@deltatee.com> <000101d2eba4$b45b1e40$1d115ac0$@dell.com> <000201d2eba8$dade4ac0$909ae040$@dell.com> Cc: linux-ntb@googlegroups.com, linux-kernel@vger.kernel.org, "'Dave Jiang'" , "'Serge Semin'" , "'Kurt Schwemmer'" , "'Stephen Bates'" , "'Greg Kroah-Hartman'" From: Logan Gunthorpe Message-ID: <4d932597-3592-2ce1-5a5f-cb5ba36a3a93@deltatee.com> Date: Thu, 22 Jun 2017 16:49:16 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <000201d2eba8$dade4ac0$909ae040$@dell.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: gregkh@linuxfoundation.org, sbates@raithlin.com, kurt.schwemmer@microsemi.com, fancer.lancer@gmail.com, dave.jiang@intel.com, linux-kernel@vger.kernel.org, linux-ntb@googlegroups.com, jdmason@kudzu.us, Allen.Hubbe@dell.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: New NTB API Issue X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1364 Lines: 26 On 6/22/2017 4:42 PM, Allen Hubbe wrote: > From: Logan Gunthorpe >> Any thoughts on changing the semantics of mw_get_align so it must be >> called with the link up? > > The intention of these is that these calls return information from the local port. The calls themselves don't reach across the link to the peer, but the information returned from the local port needs to be communicated for setting up the translation end-to-end. Ok, well if it's from the local port, then splitting up mw_get_range into peer_mw_get_addr and mw_get_align is confusing because one has the peer designation and the other doesn't. And all the clients apply the alignments to the remote bar so they'd technically need to transfer them across the link somehow. > I would like to understand why this hardware needs link up. Are there registers on the local port that are only valid after link up? We only need the link up if we are trying to find the alignment requirements (and max_size) of the peer's bar. In theory, switchtec could have different sizes of bars on both sides of the link and different alignment requirements. Though, in practice, this is probably unlikely. > Can you post snippets of how ntb_mw_get_align and ntb_peer_mw_get_addr might be implemented for the Switchtec? Hmm, yes, but lets sort out my confusion on the semantics per above first. Logan