lkml.org 
[lkml]   [2018]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
Date
| From: Steve Wise <swise@opengridcomputing.com>
| Sent: Thursday, March 22, 2018 9:28 AM
|
| | From: Sinan Kaya <okaya@codeaurora.org>
| | Date: Thursday, March 22, 2018 7:52 AM
| |
| | Isn't this a PowerPC problem? Why penalize other architectures?
|
| I worry it breaks PPC.

And all other architectures. Aparraently there isn't a formal API
description for writel_relaxed() and Co., nor __raw_writel(), etc. What I
think we need is a formal semantic definition of exactly what these APIs is
supposed to do and then we can make sure that they all do that. Till we
have a consistent definition/implementation, trying to use these APIs in
multi-platform code will be a problem.

For instance, and this is merely an example not a prescription of what I'm
talking about:

writel():
-- Ensures correct byte ordering.
-- Ensures no compiler reordering.
-- Ensures instruction level synchronization with respect
-- to previous and succeeding reads and writes.

writel_relaxed():
-- Ensures correct byte ordering.
-- Ensures no compiler reordering.
-- Ensures instruction level synchronization with respect
-- to previous writes.

__raw_writel():
-- Ensures correct byte ordering.
-- Ensures no compiler reordering.

| I appreciate you doing this.

As do I! I'm just worried that because the API semantic definitions don't
seem to be formalized for writel_relaxed() and Co., we're in danger of
getting wildly different results on one platform or another based on
differring implementation semantics.

Casey

\
 
 \ /
  Last update: 2018-03-22 20:46    [W:0.055 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site