[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<MW4PR18MB5244E888BB8195D94A6E2EC2A6CD2@MW4PR18MB5244.namprd18.prod.outlook.com>
Date: Mon, 17 Jun 2024 12:55:54 +0000
From: Vamsi Krishna Attunuru <vattunuru@...vell.com>
To: Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman
<gregkh@...uxfoundation.org>
CC: Jerin Jacob <jerinj@...vell.com>, Srujana Challa <schalla@...vell.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [EXTERNAL] Re: [PATCH v7 1/1] misc: mrvl-cn10k-dpi: add Octeon
CN10K DPI administrative driver
> -----Original Message-----
> From: Arnd Bergmann <arnd@...db.de>
> Sent: Saturday, June 8, 2024 2:12 PM
> To: Vamsi Krishna Attunuru <vattunuru@...vell.com>; Greg Kroah-Hartman
> <gregkh@...uxfoundation.org>
> Cc: Jerin Jacob <jerinj@...vell.com>; Srujana Challa <schalla@...vell.com>;
> linux-kernel@...r.kernel.org
> Subject: Re: [EXTERNAL] Re: [PATCH v7 1/1] misc: mrvl-cn10k-dpi: add
> Octeon CN10K DPI administrative driver
>
> 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.
>
Yes Arnd, understood your point. I am thing le64_get_bits() would solve the problem here. Can you please confirm.?, I will avoid bit fields and use mask scheme to extract the fields.
Thanks
Vamsi
> Arnd
Powered by blists - more mailing lists