Received-SPF: pass (google.com: domain of linux-kernel+bounces-203918-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Vamsi Krishna Attunuru <vattunuru@marvell.com>
To: Arnd Bergmann <arnd@arndb.de>,
        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
Thread-Topic: [EXTERNAL] Re: [PATCH v7 1/1] misc: mrvl-cn10k-dpi: add Octeon
 CN10K DPI administrative driver
Thread-Index: AQHaqqXUeJduCBvv+0e3+QVunpJsgbG32TAAgAAF9zCAAUqAgIABXmcQ
Date: Thu, 6 Jun 2024 08:58:36 +0000
Message-ID: 
 <SJ0PR18MB5246ECDF962BD0AFE138E38AA6FA2@SJ0PR18MB5246.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>
 <93cf15d9-6709-4f64-880b-efb178b7bf01@app.fastmail.com>
In-Reply-To: <93cf15d9-6709-4f64-880b-efb178b7bf01@app.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?PUKRTaylaTC8SL9LfBE9S0HsSBrAVCGy8BRcpul9/fBkjPRt3xk9Fg+8q34B?=
 =?us-ascii?Q?czyi075bKmXuHg4ywjfdCzK1WUKfRiXypepfLkG8cZOP6Fcxz10Re9SemcYM?=
 =?us-ascii?Q?AyF1PzCaH3BztfN01YEUgAotWrkbz6LEFOBeMOc1oLfJwG/6gMcY91iMFfY8?=
 =?us-ascii?Q?P4TEwahDgPmG12nOUhCl6pNc53zHuXJ91Hjt1KkIwMq3LUADKlTh3B4YXyHL?=
 =?us-ascii?Q?Xh9sqt9rKlbmB0AlQwwapaVP51SSIjj7HsVPa9rEnnJ1JCI4rz8iHj/m/VHm?=
 =?us-ascii?Q?JdjAyborHPNY+Rq8Zap55M4hXUHIHlBvNtqc76PhH1O+peutrquhajedOE+v?=
 =?us-ascii?Q?HKMffJ+9h47vO0y1cFxc7YYNOdQz7kSSdoD3yWTAxyUlsiqaSXlGuTEqm2ib?=
 =?us-ascii?Q?6aZ1WHBVv8vBSY3yR+MBFeHeEApxFL65MmK9cWMoMWMlCfoLY+899GZOqEFl?=
 =?us-ascii?Q?8jEtBv7azJVSmp/CVEd/imGzJksZKMpf1CS3N4qCB86/u9dBOKKg/2Bto4a2?=
 =?us-ascii?Q?ILnsAK9MuFKZ3FkYme9DQMC4iHt3xBTVoAatu6lqA7/Ge+cMUnRcwHHDaRJ3?=
 =?us-ascii?Q?dzOitZxEczN1DtyHW7TmGAJ7M1j4mnYLyjBnJ3NGGH8vWA19JzDQQGYTZD37?=
 =?us-ascii?Q?DvqdT+kdmXZYWN2IfPFX6xutC7//Hogmn+k7499oD8MIMRl20DQpdeMIJ4p2?=
 =?us-ascii?Q?6MgxPzpYMIzO/xl+EdFOfwfiis4sQrvYiRow4Dfh169I8Da7HHWHZlC8swtZ?=
 =?us-ascii?Q?GEyZvcJpTK0YO0ea6fKjIQuExZiqqfzcEn2H7JGNPC46LaTq4RnzbzJgm9iF?=
 =?us-ascii?Q?slKoOINTiZW7Z5R5Y9o7GtIDdvOVkdkG3dkHh74ABsFfdhW1/s4dRBdKIoT3?=
 =?us-ascii?Q?REihXfwy5nXW07PRbmpxjjQBk/miaB9n3cYxotLFVxkXNkrS9Et28xKRps/w?=
 =?us-ascii?Q?j7zudw8ByKgs68VSIjQ2WJG/Y1yvIs1JqSp6qRAM36KFB9Mz8EpnIrbBjxmr?=
 =?us-ascii?Q?XZXY/nhxas5b/QKAiaC4IIo4eLQFM8hYWvuQythxdtWqj09BLZyPf1vLW6Q1?=
 =?us-ascii?Q?KE1+mKPoWOamQ9PBYYXN7OdnUWMs/emDLzjwISrzzgrJxHAx8ukcfWLAFjsh?=
 =?us-ascii?Q?Gq9byqGGqUXkhWq/W9hgWEPS5Vq9KjiieNpsrOyyp0l0uQhbftbS2uGhuOE8?=
 =?us-ascii?Q?P/kBfNTzI48YNirNXqifcB7/tB9JpRqceyav5p2APTK+yTDArmFxfv3DRbNg?=
 =?us-ascii?Q?WZjQf6QvLtyXqH59r3jJvamVGA4MqVMlBPv0DLyIYO8EEgUlP8ZNqQIKfw3m?=
 =?us-ascii?Q?/mN1tna2oW3e/ncUmiUaW4/VfycxKh9iP8S+m5EWrAa+LwHUgOMXYd8zjwPA?=
 =?us-ascii?Q?hVh9EjkESmdFxtTXRiCm80XoW7K3X4fPEyPz1j167ge71ndLdJ8q3XZoV9eW?=
 =?us-ascii?Q?jbTLdGWtdyf3uUzOaXmqPxl4LfeiKd22n+2gmLmtG7KOR2316S+vP+z9S9vv?=
 =?us-ascii?Q?P7UPHNjZdE9U3MJTguFu2Pd8rfq+HXRIwA63pn654HO1VJmqEO4hPzbZshGA?=
 =?us-ascii?Q?689POL1UZ4AR6SIl2ruMilXE/hVY4T2XLalEt1Za?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: marvell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR18MB5246.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f58abd2-53d2-4dd2-07dc-08dc8606d9cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2024 08:58:36.1284
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wRHKFQD1YeDH2w2Ild1O81nlxTfmNu3zKJP7rkPMR8guhDB3O/3OQjiHFl7wPGPxslfQLG03uO0wnMm/5uHqiQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR18MB5371
X-Proofpoint-ORIG-GUID: HbI-eY69Lk7n31V25tBo3_giY-64R5Fc
X-Proofpoint-GUID: HbI-eY69Lk7n31V25tBo3_giY-64R5Fc
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-06-06_01,2024-06-06_02,2024-05-17_01


> -----Original Message-----
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: Wednesday, June 5, 2024 5:27 PM
> To: Vamsi Krishna 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
> Subject: Re: [EXTERNAL] Re: [PATCH v7 1/1] misc: mrvl-cn10k-dpi: add
> Octeon CN10K DPI administrative driver
>=20
> On Tue, Jun 4, 2024, at 18:21, Vamsi Krishna Attunuru wrote:
> >> From: Greg KH <gregkh@linuxfoundation.org>
>=20
> >> > +static inline void dpi_reg_write(struct dpipf *dpi, u64 offset,
> >> > +u64
> >> > +val) {
> >> > +	writeq(val, dpi->reg_base + offset);
> >>
> >> No read needed after a write to ensure the write made it to the
> >> hardware properly?
> >
> > Yes, as it's an onboard PCIe device, writes will happen properly. I
> > will modify it as write followed by a write barrier to avoid any
> > reordering.
>=20
> I don't think a write barrier after the I/O is what you want here, they d=
on't
> just make I/O finish before the next instruction or unlock.
>=20
> When you have like
>=20
> 	mutex_lock(&mbox->lock);
> 	msg.word[0] =3D readq(mbox->vf_pf_data_reg); ...
> 	writeq(DPI_MBOX_TYPE_RSP_ACK, mbox->pf_vf_data_reg);
> 	mutex_unlock(&mbox->lock);
>=20
> there is no guarantee that the writeq() completes before the
> mutex_unlock(), regardless of what barriers you put after it:
> even if the device is synchronous, the CPU itself does not wait for the s=
tore
> on device memory to complete.
>=20
> If you actually need the writeq() to be serialized with the lock, a dummy
> readq() is usually the safe option, though for arm64 specific code, you c=
an
> use ioremap_np() in place of ioremap() to turn the readq() into a non-pos=
ted
> store.

Writeq() & readq() are already having the barriers internally (arch/arm64/i=
nclude/asm/io.h). Below commit describes the requirement.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?=
id=3D22ec71615d824f4f11d38d0e55a88d8956b7e45f

If the driver needs to make sure writes are done then driver can read back =
at appropriate places.

>=20
>      Arnd