Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751595AbdGRO0H (ORCPT ); Tue, 18 Jul 2017 10:26:07 -0400 Received: from mail-eopbgr00065.outbound.protection.outlook.com ([40.107.0.65]:22400 "EHLO EUR02-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751489AbdGRO0F (ORCPT ); Tue, 18 Jul 2017 10:26:05 -0400 From: Laurentiu Tudor To: Arnd Bergmann CC: gregkh , Stuart Yoder , "devel@driverdev.osuosl.org" , "Linux Kernel Mailing List" , Marc Zyngier , Alexander Graf , Robin Murphy , Ioana Ciornei , "Ruxandra Ioana Radulescu" , Bharat Bhushan , Catalin Horghidan , "Leo Li" , Roy Pledge , Linux ARM Subject: Re: [PATCH v2 6/8] staging: fsl-mc: don't use raw device io functions Thread-Topic: [PATCH v2 6/8] staging: fsl-mc: don't use raw device io functions Thread-Index: AQHS/8sUgA3nsTl2rUGZcaroruT8GqJZodSAgAACIoA= Date: Tue, 18 Jul 2017 14:26:00 +0000 Message-ID: <596E1A77.4030204@nxp.com> References: <20170718133723.12709-1-laurentiu.tudor@nxp.com> <20170718133723.12709-7-laurentiu.tudor@nxp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arndb.de; dkim=none (message not signed) header.d=none;arndb.de; dmarc=none action=none header.from=nxp.com; x-originating-ip: [192.88.146.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0401MB1726;7:ciT9mT4y2y5uC0tLuEG9CtQ9aJwCfSA3EiycxcMLFD0+w9QXUpyAIWrOntWhVcxFaLacAkx8xJKvq8+B5gMrIA/jN3iqRVbcP4qdhtptR61j4oedbz4L8qhYnMmuROcFosdCGkxahh14HUIuVf2gY296i3Tb1YGqngRie3pcbk9TRm4XZROEcOW+qVVXtsbQ50G9zt/wZD32SPYA2ccqIFO1rQRxXb1QP6XL/PKDM7qAdI/R6PHcbgMFa8qm8Sa02x/MkFmoORIgWg23gMxw1yMjk2PX7dAtBTiT2y7t3mjOlR8wMKgw1mTWqE0G8Aw0jQNCOTjyubNsZdiEEimYL4ziwuJPu7oqI0BwMlMM/kH2bwVnEofBD8H2rm2iMxqF9ZxhTTD+f4nnDYPnUHALXyKfPqs7c3KzClJxNDZd+P40dEhPldrLp0tZfgxwYLlme+AqB7X4bcDxmbidixLwC92wW26wntjmK0GpEgbXv/xU5yLTHqB+Ny/3mrVLIhjc2axuBX4L4AtXvZ6tOVo0FGAzeMuakhIqBkPzGewOcGNcPKS8OSzktzCWKkKaiP2jwC8m5jqlHt/+YICVl01WY8nIGW/bRMYb1bViSB6KpH8PWeqKZscL0qA70886MhfYKMBJVXpUhL7JVBJRAop/xmI9LhJNQk0Iui7k9TCi9baQrk3I+TQTOzBN2dBKuYRuq8H7nmcgTUOCwRSlKMHD0rM7MPclDXjC6EEQIcfLCtoD5S42n242obaI9cYSGlV9myiGvrvQbE4qJalVJREd8mTW3XL5jlNTpwWY6vEURKA= x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39450400003)(39850400002)(39840400002)(39410400002)(39400400002)(39860400002)(43544003)(377454003)(24454002)(5660300001)(50986999)(76176999)(87266999)(54356999)(65816999)(5250100002)(305945005)(33656002)(8676002)(8936002)(81166006)(3280700002)(2950100002)(575784001)(86362001)(6916009)(66066001)(3660700001)(189998001)(2906002)(59896002)(229853002)(6486002)(2900100001)(478600001)(39060400002)(3846002)(36756003)(110136004)(102836003)(6116002)(6506006)(6436002)(6246003)(53546010)(38730400002)(6512007)(6306002)(80316001)(14454004)(54906002)(99286003)(53936002)(966005)(7736002)(4326008)(45080400002)(25786009);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB1726;H:VI1PR0401MB1856.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-ms-office365-filtering-correlation-id: 99ead5f5-51d5-4e7d-05d2-08d4cde8e9d6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:VI1PR0401MB1726; x-ms-traffictypediagnostic: VI1PR0401MB1726: x-exchange-antispam-report-test: UriScan:(236129657087228)(189930954265078)(185117386973197)(45079756050767)(275809806118684)(164587983369549); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:VI1PR0401MB1726;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:VI1PR0401MB1726; x-forefront-prvs: 037291602B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 14:26:00.3431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB1726 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v6IEQBTP006924 Content-Length: 3129 Lines: 69 Hi Arnd, On 07/18/2017 05:18 PM, Arnd Bergmann wrote: > On Tue, Jul 18, 2017 at 3:37 PM, wrote: >> From: Laurentiu Tudor >> >> As raw device io functions are not portable and don't handle byte-order >> (triggering suspicion that endianness isn't handled well) switch to >> using the standard api. >> Since MC expects LE byte-order and the upper layers already take care >> of that, we need to trick the device io api by doing a LE -> CPU >> conversion just before calling it. This way, the CPU -> LE conversion >> done in the api puts the data back in the right byte-order. Obviously, >> for reads the extra step is mirrored: there's a CPU -> LE conversion >> following the API call. >> >> Signed-off-by: Laurentiu Tudor >> --- >> Notes: >> -v2 >> -new patch replacing https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2017%2F7%2F17%2F419&data=01%7C01%7Claurentiu.tudor%40nxp.com%7C77381272b4914c9ac64708d4cde7d94e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=FTVLKox6T4i9OFmb%2B5BkSEDQrDrafXznY6nsJ0dgFSk%3D&reserved=0 >> >> drivers/staging/fsl-mc/bus/mc-sys.c | 21 +++++++++++++++------ >> 1 file changed, 15 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/staging/fsl-mc/bus/mc-sys.c b/drivers/staging/fsl-mc/bus/mc-sys.c >> index 195d9f3..8a6dc47 100644 >> --- a/drivers/staging/fsl-mc/bus/mc-sys.c >> +++ b/drivers/staging/fsl-mc/bus/mc-sys.c >> @@ -126,12 +126,15 @@ static inline void mc_write_command(struct mc_command __iomem *portal, >> >> /* copy command parameters into the portal */ >> for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++) >> - __raw_writeq(cmd->params[i], &portal->params[i]); >> - /* ensure command params are committed before submitting it */ >> - wmb(); >> + /* >> + * Data is already in the expected LE byte-order. Do an >> + * extra LE -> CPU conversion so that the CPU -> LE done in >> + * the device io write api puts it back in the right order. >> + */ >> + writeq_relaxed(le64_to_cpu(cmd->params[i]), &portal->params[i]); >> >> /* submit the command by writing the header */ >> - __raw_writeq(cmd->header, &portal->header); >> + writeq(le64_to_cpu(cmd->header), &portal->header); >> } > > Looks good, but just to be sure this is what you intended: > > On 32-bit systems, this will now write val>>32 to cmd->header+4, > followed by writing val&0xffffffff to cmd->header. Right. That's how it should happen. > You said earlier that the command is triggered when the final > four bytes are written, but it looks like the order is wrong now. > > Should you use io-64-nonatomic-lo-hi.h instead of > io-64-nonatomic-hi-lo.h then? > Maybe i made an error in my previous emails, but the hi-lo variant is the correct one. The command execution is triggered when the _first_ 32-bit half of the header (header&0xffffffff) is written, so that's why it must be written last. --- Thanks & Best Regards, Laurentiu