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=-17.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 843C1C433EF for ; Thu, 23 Sep 2021 09:03:10 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 470B761152 for ; Thu, 23 Sep 2021 09:03:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 470B761152 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.193532.344717 (Exim 4.92) (envelope-from ) id 1mTKdA-0005xd-DC; Thu, 23 Sep 2021 09:03:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 193532.344717; Thu, 23 Sep 2021 09:03:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTKdA-0005xW-AJ; Thu, 23 Sep 2021 09:03:00 +0000 Received: by outflank-mailman (input) for mailman id 193532; Thu, 23 Sep 2021 09:02:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTKd9-0005xI-N1 for xen-devel@lists.xenproject.org; Thu, 23 Sep 2021 09:02:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mTKd9-0003oW-ER; Thu, 23 Sep 2021 09:02:59 +0000 Received: from [202.153.84.92] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mTKd9-0000Ap-4Q; Thu, 23 Sep 2021 09:02:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=HfN1IGFIrJppc5fvqGb+ktVGm+nPKJ2a+PRtFdhGhM4=; b=pKDkULY9qDol/kEkgunI2Lfgce Sn6I5076r1Czj87o0mIlxkHCH87ytn5GBxVuMi8fc8XK6xv2tBZXeDrU6CziueC6oXoShp8oPC1ey aupHcQtbdrrripkKwkM9AifBUn0gqNezLpMt5tUIaTEnD8fq/xlc8SSGohLuhODJJYrA=; Subject: Re: [PATCH v2 13/17] xen:arm: Implement pci access functions To: Stefano Stabellini , Rahul Singh Cc: xen-devel@lists.xenproject.org, bertrand.marquis@arm.com, andre.przywara@arm.com, Volodymyr Babchuk References: From: Julien Grall Message-ID: Date: Thu, 23 Sep 2021 14:02:54 +0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Hi Stefano, On 23/09/2021 07:23, Stefano Stabellini wrote: > Subject should have xen/arm > > > On Wed, 22 Sep 2021, Rahul Singh wrote: >> Implement generic pci access functions to read/write the configuration >> space. >> >> Signed-off-by: Rahul Singh >> --- >> Change in v2: Fixed comments >> --- >> xen/arch/arm/pci/pci-access.c | 58 ++++++++++++++++++++++++++++++ >> xen/arch/arm/pci/pci-host-common.c | 19 ++++++++++ >> xen/include/asm-arm/pci.h | 2 ++ >> 3 files changed, 79 insertions(+) >> >> diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c >> index 04fe9fbf92..45500cec2a 100644 >> --- a/xen/arch/arm/pci/pci-access.c >> +++ b/xen/arch/arm/pci/pci-access.c >> @@ -16,6 +16,7 @@ >> #include >> >> #define INVALID_VALUE (~0U) >> +#define PCI_ERR_VALUE(len) GENMASK(0, len * 8) >> >> int pci_generic_config_read(struct pci_host_bridge *bridge, uint32_t sbdf, >> uint32_t reg, uint32_t len, uint32_t *value) >> @@ -72,6 +73,63 @@ int pci_generic_config_write(struct pci_host_bridge *bridge, uint32_t sbdf, >> return 0; >> } >> >> +static uint32_t pci_config_read(pci_sbdf_t sbdf, unsigned int reg, >> + unsigned int len) >> +{ >> + uint32_t val = PCI_ERR_VALUE(len); >> + > > No blank line > > >> + struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg, sbdf.bus); >> + >> + if ( unlikely(!bridge) ) >> + return val; >> + >> + if ( unlikely(!bridge->ops->read) ) >> + return val; >> + >> + bridge->ops->read(bridge, (uint32_t) sbdf.sbdf, reg, len, &val); > > The more I look at these casts the less I like them :-D I really dislike them. This is kind of defeating the purpose of trying to be more typesafe. > > One idea is to move the definition of pci_sbdf_t somewhere else > entirely, for instance xen/include/xen/types.h, then we can use > pci_sbdf_t everywhere AFAIU, the problem is the prototype helpers are defined in asm/pci.h which is included by xen/pci.h before defining sbdf_t. Is it correct? If so there are two options: 1) define sbdf_t and then include asm/pci.h. 2) Name the union and then pre-declare it. Option 1 is probably nicer is we have more types in the future that are used by arch specific but defined in the common headers. We have a few places that uses this approach. Cheers, -- Julien Grall