Received-SPF: pass (google.com: domain of linux-kernel+bounces-206952-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-497-g97f96844c-fm-20240526.001-g97f96844
Precedence: bulk
MIME-Version: 1.0
Message-Id: <4a4b1675-3244-4032-ae64-82ca8872288f@app.fastmail.com>
In-Reply-To: 
 <MW4PR18MB524422223AC92181942C75E2A6FA2@MW4PR18MB5244.namprd18.prod.outlook.com>
References: <2024042950-refurbish-duckbill-77b4@gregkh>
 <20240520110630.2568767-1-vattunuru@marvell.com>
 <2024060412-amulet-unflawed-f37a@gregkh>
 <SJ0PR18MB52462AA2A9F15103D5198CC5A6F82@SJ0PR18MB5246.namprd18.prod.outlook.com>
 <MW4PR18MB524422223AC92181942C75E2A6FA2@MW4PR18MB5244.namprd18.prod.outlook.com>
Date: Sat, 08 Jun 2024 10:42:02 +0200
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Vamsi Attunuru" <vattunuru@marvell.com>,
 "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: "Jerin Jacob" <jerinj@marvell.com>,
 "Srujana Challa" <schalla@marvell.com>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH v7 1/1] misc: mrvl-cn10k-dpi: add Octeon CN10K DPI
 administrative driver
Content-Type: text/plain

On Thu, Jun 6, 2024, at 18:42, Vamsi Krishna Attunuru wrote:
>> -----Original Message-----
>> > -----Original Message-----

>> > The ifdef is cute, but not correct, sorry.  Please use bit shifts to
>> > handle this properly without any #ifdef needed at all.
>> >
>> Ack, will fix it next version. Thanks for the suggestion.
>> 
>
> Hi Greg, the ARM64 cores on the Octeon CN10K hardware platform always 
> run in LE mode and this CN10K DPI PF driver is only supported on Octeon 
> CN10K platforms as the DPI PF device is an onboard PCIe device. Can I 
> remove the BE format and only define the LE format for the 
> dpi_mbox_message structure?, other HW device drivers of Octeon CN10K 
> platform also only support LE format.

Isn't this a regular Neoverse-N2 core? That means the hardware does
support big-endian in principle, though it's usually only used
in VM guests, not on bare bare metal and the driver is fairly
safe.

In general, I would always suggest writing portable code, as
you never know who is going to copy from your driver into
something else. Writing this portably is not that hard or
less readable than using bit fields.

      Arnd