From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A93A9A0524; Sun, 14 Mar 2021 11:05:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BE2B8160931; Sun, 14 Mar 2021 11:05:42 +0100 (CET) Received: from mail.anongoth.pl (mail.anongoth.pl [46.248.190.61]) by mails.dpdk.org (Postfix) with ESMTP id 3A4964014D for ; Fri, 12 Mar 2021 01:33:38 +0100 (CET) Received: from anongoth.pl (unknown [192.168.1.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: pkubaj@anongoth.pl) by mail.anongoth.pl (Postfix) with ESMTPSA id 54C97BDC53; Fri, 12 Mar 2021 01:33:36 +0100 (CET) Date: Fri, 12 Mar 2021 01:33:35 +0100 From: Piotr Kubaj To: Ajit Khaparde Cc: dev@dpdk.org Message-ID: References: <20210311233033.67152-1-ajit.khaparde@broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jrXxDVVyMnqflAoD" Content-Disposition: inline In-Reply-To: <20210311233033.67152-1-ajit.khaparde@broadcom.com> X-Mailman-Approved-At: Sun, 14 Mar 2021 11:05:37 +0100 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH] net/bnxt: rename a member to avoid conflict X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" --jrXxDVVyMnqflAoD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I may have been unclear. This affects ppc64le overall. The reason is that vector is a keyword on ppc64(le). For some reason, GCC does not have an issue with it, but some future versio= n might. So the current issues happen when using clang (with glibc or not). The issue that happens when attempting to build without glibc is about the = lack of function to read TBR on other libc's. This issue is resolved further in the code and does not affect bnxt. On 21-03-11 15:30:33, Ajit Khaparde wrote: > Address build issues with Clang and without glibc on ppc64le. > Vector can be a keyword and should not be used in code. > Renaming it to avoid conflict. >=20 > Reported-by: Piotr Kubaj > Signed-off-by: Ajit Khaparde > --- > drivers/net/bnxt/bnxt_irq.c | 2 +- > drivers/net/bnxt/bnxt_irq.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/drivers/net/bnxt/bnxt_irq.c b/drivers/net/bnxt/bnxt_irq.c > index a29ac28590..8abbadb3d1 100644 > --- a/drivers/net/bnxt/bnxt_irq.c > +++ b/drivers/net/bnxt/bnxt_irq.c > @@ -151,7 +151,7 @@ int bnxt_setup_int(struct bnxt *bp) > sizeof(struct bnxt_irq), 0); > if (bp->irq_tbl) { > for (i =3D 0; i < total_vecs; i++) { > - bp->irq_tbl[i].vector =3D i; > + bp->irq_tbl[i].vector_idx =3D i; > snprintf(bp->irq_tbl[i].name, len, > "%s-%d", bp->eth_dev->device->name, i); > bp->irq_tbl[i].handler =3D bnxt_int_handler; > diff --git a/drivers/net/bnxt/bnxt_irq.h b/drivers/net/bnxt/bnxt_irq.h > index 7b02f30973..53d9198858 100644 > --- a/drivers/net/bnxt/bnxt_irq.h > +++ b/drivers/net/bnxt/bnxt_irq.h > @@ -8,7 +8,7 @@ > =20 > struct bnxt_irq { > rte_intr_callback_fn handler; > - unsigned int vector; > + unsigned int vector_idx; > uint8_t requested; > char name[RTE_ETH_NAME_MAX_LEN + 2]; > }; > --=20 > 2.21.1 (Apple Git-122.3) >=20 --jrXxDVVyMnqflAoD--