From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Subject: Re: RFC on writel and writel_relaxed Date: Wed, 21 Mar 2018 14:40:47 +1100 Message-ID: References: <3611eabe-2999-1482-b2b4-6d216bbe4762@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <3611eabe-2999-1482-b2b4-6d216bbe4762@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Sinan Kaya Cc: "linux-rdma@vger.kernel.org" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" List-Id: linux-rdma@vger.kernel.org On Wed, Mar 21, 2018 at 2:07 PM, Sinan Kaya wrote: > Hi PPC Maintainers, > > We are seeking feedback on the status of relaxed write API implementation. > What is the motivation for not implementing the relaxed API? Hmm, good question. Looks like we've implemented the relaxed_* variants by aliasing them to the normal version since the dawn of time. There's a comment in io.h saying something about us not having the expected semantics for the relaxed variants, but I don't see what the issue is... Ben? > I see that network drivers are working around the issue by calling > __raw_write() API directly but this also breaks other architectures > like SPARC since the semantics of __raw_writel() seems to be system dependent. Yeah that's pretty gross. Which drivers are doing this? > This is putting drivers into a tight position and they cannot achieve true > multi-arch enablement and are forced into calling __raw APIs flavors > directly with #ifdef BIG_ENDIAN ugliness. > > Sinan > > -- > Sinan Kaya > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 405bDf4rxrzF1Tw for ; Wed, 21 Mar 2018 14:40:49 +1100 (AEDT) Received: by mail-it0-x241.google.com with SMTP id z7-v6so14798635iti.1 for ; Tue, 20 Mar 2018 20:40:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <3611eabe-2999-1482-b2b4-6d216bbe4762@codeaurora.org> References: <3611eabe-2999-1482-b2b4-6d216bbe4762@codeaurora.org> From: Oliver Date: Wed, 21 Mar 2018 14:40:47 +1100 Message-ID: Subject: Re: RFC on writel and writel_relaxed To: Sinan Kaya Cc: "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "linux-rdma@vger.kernel.org" , Benjamin Herrenschmidt Content-Type: text/plain; charset="UTF-8" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Mar 21, 2018 at 2:07 PM, Sinan Kaya wrote: > Hi PPC Maintainers, > > We are seeking feedback on the status of relaxed write API implementation. > What is the motivation for not implementing the relaxed API? Hmm, good question. Looks like we've implemented the relaxed_* variants by aliasing them to the normal version since the dawn of time. There's a comment in io.h saying something about us not having the expected semantics for the relaxed variants, but I don't see what the issue is... Ben? > I see that network drivers are working around the issue by calling > __raw_write() API directly but this also breaks other architectures > like SPARC since the semantics of __raw_writel() seems to be system dependent. Yeah that's pretty gross. Which drivers are doing this? > This is putting drivers into a tight position and they cannot achieve true > multi-arch enablement and are forced into calling __raw APIs flavors > directly with #ifdef BIG_ENDIAN ugliness. > > Sinan > > -- > Sinan Kaya > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.