From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226SEGG/V5xPS38OWVBJGr9/hoqxCzMRZl0FT00v208Y36gE7phMYr1F2xqfpoK/u8tjHGTN ARC-Seal: i=1; a=rsa-sha256; t=1516990311; cv=none; d=google.com; s=arc-20160816; b=yrjEI6yKgbEQ3WdkYBzwaOKa9HN8oM6rSVb/iVAJEZYVe76lIcmVJM6XRxyNGgD4Pw X62oIG1kHYd2cekYVCrpRqyp6r75rQm4Ph7fEnFKUzsZnrouEgyM31DZncIVnBfPEPDq aWu3FoU3Y5Roy+FMB1mYx59DLQMHnTW0dPOXy/clobmkdAx9EqdNomnhWKxl5k+GO1rl Y17H3x0C9YgUGgec4gQy8PkHpxexcxs8fomf49vUAv2nnwn4ZJP58dnn936pITj2f0yG rPNaV4iC1OmaWs6T54rNs3OJ5NTejQL0CacK/zbxT4xH84tDe0CXwixjZY7UGdkGPI/o 6xZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=Tup5+rUUq99TYrtBytv+VtlWVB6uVwuJc21Q6XHIPBo=; b=qke4q4XhD4TUV8QQGsubXdlT7QW+tNOkjy+82C2gim9GuIeMFXhVutX4LvmlopHiAJ 5/xpeEIKgayJxMh4HHoKUw2jm6YZ2K5R4lCkjOjboAOa58nu14bDH8T/G5CTdzK3hXIw qXE0hqx33/2uqZ9Vw/A0o+98xkrdEv4tE9xFnofcIiMxnPsCJhuu8eVttnMBKTUL5piD eVAM23jRhChY7J0iBUeUxLpeVDeT69SYxg06x5HbEtZXDrOC8xC36H6lezzEqUjVe4e5 m6mh+5PNygYepCd2pqpSI0ZcqO9TebWYJ1aM5ju11Ylrho4ZAX/GZ8w6Z5vPDACx+39x GDMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of will.deacon@arm.com designates 217.140.101.70 as permitted sender) smtp.mailfrom=will.deacon@arm.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of will.deacon@arm.com designates 217.140.101.70 as permitted sender) smtp.mailfrom=will.deacon@arm.com Date: Fri, 26 Jan 2018 18:11:49 +0000 From: Will Deacon To: Yury Norov Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, Al Viro , Andrew Morton , Andrew Pinski , Arnd Bergmann , Catalin Marinas , "David S . Miller" , Geethasowjanya Akula , Greg Kroah-Hartman , Ingo Molnar , Kees Cook , Laura Abbott , Nicholas Piggin , Sunil Goutham Subject: Re: [PATCH RFC 0/3] API for 128-bit IO access Message-ID: <20180126181149.GA17922@arm.com> References: <20180124090519.6680-1-ynorov@caviumnetworks.com> <20180124102212.GC20586@arm.com> <20180126090542.bsza7hqqinqwllcr@yury-thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180126090542.bsza7hqqinqwllcr@yury-thinkpad> User-Agent: Mutt/1.5.23 (2014-03-12) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590464072821012974?= X-GMAIL-MSGID: =?utf-8?q?1590679632453774447?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Jan 26, 2018 at 12:05:42PM +0300, Yury Norov wrote: > On Wed, Jan 24, 2018 at 10:22:13AM +0000, Will Deacon wrote: > > On Wed, Jan 24, 2018 at 12:05:16PM +0300, Yury Norov wrote: > > > This series adds API for 128-bit memory IO access and enables it for ARM64. > > > The original motivation for 128-bit API came from new Cavium network device > > > driver. The hardware requires 128-bit access to make things work. See > > > description in patch 3 for details. > > > > > > Also, starting from ARMv8.4, stp and ldp instructions become atomic, and > > > API for 128-bit access would be helpful in core arm64 code. > > > > Only for normal, cacheable memory, so they're not suitable for IO accesses > > as you're proposing here. > > Hi Will, > > Thanks for clarification. > > Could you elaborate, do you find 128-bit read/write API useless, or > you just correct my comment? > > I think that ordered uniform 128-bit access API would be helpful, even > if not atomic. Sorry, but I strongly disagree here. Having an IO accessor that isn't guaranteed to be atomic is a recipe for disaster if it's not called out explicitly. You're much better off implementing something along the lines of using 2x64-bit accessors like we already have for the 2x32-bit case. However, that doesn't solve your problem and is somewhat of a distraction. I'd suggest that in your case, where you have a device that relies on 128-bit atomic access that is assumedly tightly integrated into your SoC, then the driver just codes it's own local implementation of the accessor, given that there isn't a way to guarantee the atomicity architecturally (and even within your SoC it might not be atomic to all endpoints). Will