From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93BBDC07E9C for ; Mon, 12 Jul 2021 19:56:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B8E1611CB for ; Mon, 12 Jul 2021 19:56:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236695AbhGLT7R (ORCPT ); Mon, 12 Jul 2021 15:59:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:38888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234152AbhGLT7O (ORCPT ); Mon, 12 Jul 2021 15:59:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2F0B061248; Mon, 12 Jul 2021 19:56:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626119786; bh=1/iV0tWnFbbXO0GEHBAo7CuxKn/rRuPYJSACK0eLi3Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dQfSsq1jx3lPxRdhODpiKgtXXpCGYxn7qC7Mp6Qgn9xJMpqM7nyemeJpfKs2Q57Vo GtZsmsqTa2/1W0MjFg2D3M4LmiYHFOWnRikS8R0iq8MpMoE2NU78hsgZfql/OyAyU0 s/OSvAhCsvY5bs5x3cE+wvD4ujHlTSJ4imynk8zcG5eFybGJbkqo5sYqc5w9UgDjnV PU933Js1WfIABFGPFg9jvh5Sd750+2vO9p8N5Maf1nvDmnXMd0wtUJQQ4RQiavownL puxNnd78xJitKg4Lo4ErrYooveUSMSVETo9JVilH/lxlWnIfY2Q37vbFjZw1ASBdr7 mJMxypxtJw/IA== Received: by mail-ej1-f43.google.com with SMTP id dt7so7078571ejc.12; Mon, 12 Jul 2021 12:56:26 -0700 (PDT) X-Gm-Message-State: AOAM533DyzXIDJyZufyWEIzOqya6l51g1u5NEcFHfgc4HUDABt8GGeM/ yI//I552HnjlHw/mcwYtUmkVb+h+hT9htzHywg== X-Google-Smtp-Source: ABdhPJzQP4XLVaKnqd28Ulh5L6F8VcTh8R/AfPyMs7r6K12YgTls+lWlluw/s3Hp7usHqSXhQeJH8grhlH9YOxbSMiM= X-Received: by 2002:a17:906:b18d:: with SMTP id w13mr816201ejy.341.1626119784749; Mon, 12 Jul 2021 12:56:24 -0700 (PDT) MIME-Version: 1.0 References: <20210630034653.10260-1-manivannan.sadhasivam@linaro.org> <20210712075302.GA8113@workstation> In-Reply-To: <20210712075302.GA8113@workstation> From: Rob Herring Date: Mon, 12 Jul 2021 13:56:12 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/3] Add Qualcomm PCIe Endpoint driver support To: Manivannan Sadhasivam Cc: Kishon Vijay Abraham I , Lorenzo Pieralisi , Bjorn Helgaas , devicetree@vger.kernel.org, PCI , "linux-kernel@vger.kernel.org" , linux-arm-msm , hemantk@codeaurora.org, Siddartha Mohanadoss , Bjorn Andersson , Sriharsha Allenki , skananth@codeaurora.org, vpernami@codeaurora.org, Veerabhadrarao Badiganti Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Mon, Jul 12, 2021 at 1:53 AM Manivannan Sadhasivam wrote: > > On Thu, Jul 01, 2021 at 09:25:01AM -0600, Rob Herring wrote: > > On Tue, Jun 29, 2021 at 9:47 PM Manivannan Sadhasivam > > wrote: > > > > > > Hello, > > > > > > This series adds support for Qualcomm PCIe Endpoint controller found > > > in platforms like SDX55. The Endpoint controller is based on the designware > > > core with additional Qualcomm wrappers around the core. > > > > > > The driver is added separately unlike other Designware based drivers that > > > combine RC and EP in a single driver. This is done to avoid complexity and > > > to maintain this driver autonomously. > > > > > > The driver has been validated with an out of tree MHI function driver on > > > SDX55 based Telit FN980 EVB connected to x86 host machine over PCIe. > > > > > > Thanks, > > > Mani > > > > > > Changes in v5: > > > > > > * Removed the DBI register settings that are not needed > > > * Used the standard definitions available in pci_regs.h > > > * Added defines for all the register fields > > > * Removed the left over code from previous iteration > > > > > > Changes in v4: > > > > > > * Removed the active_config settings needed for IPA integration > > > * Switched to writel for couple of relaxed versions that sneaked in > > > > I thought we resolved this discussion. Use _relaxed variants unless > > you need the stronger ones. > > > > I thought the discussion was resolved in favor of using read/writel. Here > is the last reply from Bjorn: > > "I think we came to the conclusion that writel() was better > than incorrect use of writel_relaxed() followed by wmb(). And in this > particular case it's definitely not happening in a hot code path..." Certainly if you're needing wmb(), then you shouldn't be using _relaxed() variants. > IMO, it is safer to use readl/writel calls than the relaxed variants. Sure, and it's safer to have one big lock than it is to have no locks or lots of small locks. > And so far the un-written rule I assumed is, only consider using the > relaxed variants if the code is in hot path (but somehow I used the > relaxed version in v1 :P ) If you want any real conclusion, then best to fix the 'un-written' part. But what I say for every PCI review, is use the _relaxed() variants. Rob