From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E17A0C433E0 for ; Tue, 22 Dec 2020 08:39:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A608B23333 for ; Tue, 22 Dec 2020 08:39:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726365AbgLVIjK (ORCPT ); Tue, 22 Dec 2020 03:39:10 -0500 Received: from Mailgw01.mediatek.com ([1.203.163.78]:21857 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726016AbgLVIjJ (ORCPT ); Tue, 22 Dec 2020 03:39:09 -0500 X-UUID: 64f217b91d514130a255023e82a56a98-20201222 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=YLfMy68wBB6UlNustrhsqE6gJYC3N0UvKOcE4aN9Y+k=; b=VaN4Cy8Rsgdt8m3E+NW3DBk5X+RJNigwT5q0LkDBbPNHO6Fn/wEt1LIvYhyI8zzwfbAwoUHFX/ULirsOEcUGiCC2A72ajK0Y8VQqwOz2WhLbo5Xp8VeKTm4rbFXt5qPbY6tvnquxpz1jT8UmkfVS4bx4kPJNi62d1foZQW/nWFI=; X-UUID: 64f217b91d514130a255023e82a56a98-20201222 Received: from mtkcas34.mediatek.inc [(172.27.4.253)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1489639674; Tue, 22 Dec 2020 16:38:20 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 16:38:16 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 22 Dec 2020 16:38:15 +0800 Message-ID: <1608626297.14736.113.camel@mhfsdcap03> Subject: Re: [v5,2/3] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192 From: Jianjun Wang To: Nicolas Boichat CC: , Devicetree List , Lorenzo Pieralisi , , Chuanjia Liu , Mauro Carvalho Chehab , , lkml , Rob Herring , "Bjorn Helgaas" , Sj Huang , Ryder Lee , "moderated list:ARM/Mediatek SoC support" , Philipp Zabel , Matthias Brugger , , "David S . Miller" , linux-arm Mailing List Date: Tue, 22 Dec 2020 16:38:17 +0800 In-Reply-To: References: <20201202133813.6917-1-jianjun.wang@mediatek.com> <20201202133813.6917-3-jianjun.wang@mediatek.com> <1608608319.14736.97.camel@mhfsdcap03> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 00173604EC7CD22A602B7873EB32C70165C8892601EF854DADCCF59B40BAB8542000:8 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org T24gVHVlLCAyMDIwLTEyLTIyIGF0IDExOjU1ICswODAwLCBOaWNvbGFzIEJvaWNoYXQgd3JvdGU6 DQo+IE9uIFR1ZSwgRGVjIDIyLCAyMDIwIGF0IDExOjM4IEFNIEppYW5qdW4gV2FuZyA8amlhbmp1 bi53YW5nQG1lZGlhdGVrLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBPbiBNb24sIDIwMjAtMTItMjEg YXQgMTA6MTggKzA4MDAsIE5pY29sYXMgQm9pY2hhdCB3cm90ZToNCj4gPiA+IE9uIFdlZCwgRGVj IDIsIDIwMjAgYXQgOTozOSBQTSBKaWFuanVuIFdhbmcgPGppYW5qdW4ud2FuZ0BtZWRpYXRlay5j b20+IHdyb3RlOg0KPiA+ID4gPiBbc25pcF0NCj4gPiA+ID4gK3N0YXRpYyBpcnFfaHdfbnVtYmVy X3QgbXRrX3BjaWVfbXNpX2dldF9od2lycShzdHJ1Y3QgbXNpX2RvbWFpbl9pbmZvICppbmZvLA0K PiA+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbXNp X2FsbG9jX2luZm9fdCAqYXJnKQ0KPiA+ID4gPiArew0KPiA+ID4gPiArICAgICAgIHN0cnVjdCBt c2lfZGVzYyAqZW50cnkgPSBhcmctPmRlc2M7DQo+ID4gPiA+ICsgICAgICAgc3RydWN0IG10a19w Y2llX3BvcnQgKnBvcnQgPSBpbmZvLT5jaGlwX2RhdGE7DQo+ID4gPiA+ICsgICAgICAgaW50IGh3 aXJxOw0KPiA+ID4gPiArDQo+ID4gPiA+ICsgICAgICAgbXV0ZXhfbG9jaygmcG9ydC0+bG9jayk7 DQo+ID4gPiA+ICsNCj4gPiA+ID4gKyAgICAgICBod2lycSA9IGJpdG1hcF9maW5kX2ZyZWVfcmVn aW9uKHBvcnQtPm1zaV9pcnFfaW5fdXNlLCBQQ0lFX01TSV9JUlFTX05VTSwNCj4gPiA+ID4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9yZGVyX2Jhc2VfMihlbnRyeS0+ bnZlY191c2VkKSk7DQo+ID4gPiA+ICsgICAgICAgaWYgKGh3aXJxIDwgMCkgew0KPiA+ID4gPiAr ICAgICAgICAgICAgICAgbXV0ZXhfdW5sb2NrKCZwb3J0LT5sb2NrKTsNCj4gPiA+ID4gKyAgICAg ICAgICAgICAgIHJldHVybiAtRU5PU1BDOw0KPiA+ID4gPiArICAgICAgIH0NCj4gPiA+ID4gKw0K PiA+ID4gPiArICAgICAgIG11dGV4X3VubG9jaygmcG9ydC0+bG9jayk7DQo+ID4gPiA+ICsNCj4g PiA+ID4gKyAgICAgICByZXR1cm4gaHdpcnE7DQo+ID4gPg0KPiA+ID4gQ29kZSBpcyBnb29kLCBi dXQgSSBoYWQgdG8gbG9vayB0d2ljZSB0byBtYWtlIHN1cmUgdGhlIG11dGV4IGlzDQo+ID4gPiB1 bmxvY2tlZC4gSXMgdGhlIGZvbGxvd2luZyBtYXJnaW5hbGx5IGJldHRlcj8NCj4gPiA+DQo+ID4g PiBod2lycSA9IC4uLjsNCj4gPiA+DQo+ID4gPiBtdXRleF91bmxvY2soJnBvcnQtPmxvY2spOw0K PiA+ID4NCj4gPiA+IGlmIChod2lycSA8IDApDQo+ID4gPiAgICByZXR1cm4gLUVOT1NQQzsNCj4g PiA+DQo+ID4gPiByZXR1cm4gaHdpcnE7DQo+ID4NCj4gPiBJbXByZXNzaXZlLCBJIHdpbGwgZml4 IGl0IGluIHRoZSBuZXh0IHZlcnNpb24sIGFuZCBJIHRoaW5rIHRoZSBod2lycSBjYW4NCj4gPiBi ZSByZXR1cm5lZCBkaXJlY3RseSBzaW5jZSBpdCB3aWxsIGJlIGEgbmVnYXRpdmUgdmFsdWUgaWYN Cj4gPiBiaXRtYXBfZmluZF9mcmVlX3JlZ2lvbiBpcyBmYWlsZWQuIFRoZSBjb2RlIHdpbGwgYmUg bGlrZSB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gaHdpcnEgPSAuLi47DQo+ID4NCj4gPiBtdXRl eF91bmxvY2soJnBvcnQtPmxvY2spOw0KPiA+DQo+ID4gcmV0dXJuIGh3aXJxOw0KPiANCj4gU0cs IGFzIGxvbmcgYXMgeW91J3JlIG9rYXkgd2l0aCByZXR1cm5pbmcgLUVOT01FTSBpbnN0ZWFkIG9m IC1FTk9TUEMuDQo+IA0KPiBCdXQgbm93IEknbSBoYXZpbmcgZG91YnQgaWYgbmVnYXRpdmUgcmV0 dXJuIHZhbHVlcyBhcmUgb2ssIGFzDQo+IGlycV9od19udW1iZXJfdCBpcyB1bnNpZ25lZCBsb25n Lg0KPiANCj4gbXNpX2RvbWFpbl9hbGxvYw0KPiAoaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20v bGludXgvbGF0ZXN0L3NvdXJjZS9rZXJuZWwvaXJxL21zaS5jI0wxNDMpDQo+IHVzZXMgaXQgdG8g Y2FsbCBpcnFfZmluZF9tYXBwaW5nDQo+IChodHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51 eC9sYXRlc3Qvc291cmNlL2tlcm5lbC9pcnEvaXJxZG9tYWluLmMjTDg4MikNCj4gd2l0aG91dCBj aGVjaywgYW5kIEknbSBub3QgY29udmluY2VkIGlycV9maW5kX21hcHBpbmcgd2lsbCBlcnJvciBv dXQNCj4gZ3JhY2VmdWxseS4uLg0KPiANCkkgc2VlLCBpdCBzZWVtcyB0aGUgbXNpX2RvbWFpbl9h bGxvYyBmdW5jdGlvbiBhc3N1bWUgdGhlIGdldF9od2lycQ0KY2FsbGJhY2sgYWx3YXlzIHN1Y2Nl c3MsIG1heWJlIEkgc2hvdWxkIGFsbG9jYXRlIHRoZSByZWFsIGh3aXJxIGluIHRoZQ0KbXNpX3By ZXBhcmUNCihodHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51eC9sYXRlc3Qvc291cmNlL2tl cm5lbC9pcnEvbXNpLmMjTDMwNCkNCmFuZCBzZXQgaXQgdG8gYXJnLT5od2lycSwgYW5kIG92ZXJy aWRlIHRoZSBzZXRfZGVzYw0KKGh0dHBzOi8vZWxpeGlyLmJvb3RsaW4uY29tL2xpbnV4L2xhdGVz dC9zb3VyY2UvZHJpdmVycy9wY2kvbXNpLmMjTDE0MDUpDQp0byBwcmV2ZW50IHRoZSBtb2RpZnkg b2YgYXJnLT5od2lycS4NCg0KPiA+ID4NCj4gPiA+ID4gK30NCj4gPiA+ID4gKw0KPiA+ID4gPiBb c25pcF0NCj4gPiA+ID4gK3N0YXRpYyB2b2lkIG10a19wY2llX21zaV9oYW5kbGVyKHN0cnVjdCBp cnFfZGVzYyAqZGVzYykNCj4gPiA+ID4gK3sNCj4gPiA+ID4gKyAgICAgICBzdHJ1Y3QgbXRrX3Bj aWVfbXNpICptc2lfaW5mbyA9IGlycV9kZXNjX2dldF9oYW5kbGVyX2RhdGEoZGVzYyk7DQo+ID4g PiA+ICsgICAgICAgc3RydWN0IGlycV9jaGlwICppcnFjaGlwID0gaXJxX2Rlc2NfZ2V0X2NoaXAo ZGVzYyk7DQo+ID4gPiA+ICsgICAgICAgdW5zaWduZWQgbG9uZyBtc2lfZW5hYmxlLCBtc2lfc3Rh dHVzOw0KPiA+ID4gPiArICAgICAgIHVuc2lnbmVkIGludCB2aXJxOw0KPiA+ID4gPiArICAgICAg IGlycV9od19udW1iZXJfdCBiaXQsIGh3aXJxOw0KPiA+ID4gPiArDQo+ID4gPiA+ICsgICAgICAg Y2hhaW5lZF9pcnFfZW50ZXIoaXJxY2hpcCwgZGVzYyk7DQo+ID4gPiA+ICsNCj4gPiA+ID4gKyAg ICAgICBtc2lfZW5hYmxlID0gcmVhZGwobXNpX2luZm8tPmJhc2UgKyBQQ0lFX01TSV9FTkFCTEVf T0ZGU0VUKTsNCj4gPiA+ID4gKyAgICAgICB3aGlsZSAoKG1zaV9zdGF0dXMgPSByZWFkbChtc2lf aW5mby0+YmFzZSArIFBDSUVfTVNJX1NUQVRVU19PRkZTRVQpKSkgew0KPiA+ID4gPiArICAgICAg ICAgICAgICAgbXNpX3N0YXR1cyAmPSBtc2lfZW5hYmxlOw0KPiA+ID4NCj4gPiA+IEkgZG9uJ3Qg a25vdyBtdWNoIGFib3V0IE1TSSwgYnV0IHdoYXQgaGFwcGVucyBpZiB5b3UgaGF2ZSBhIGJpdCB0 aGF0DQo+ID4gPiBpcyBzZXQgaW4gUENJRV9NU0lfU1RBVFVTX09GRlNFVCByZWdpc3RlciwgYnV0 IG5vdCBpbiBtc2lfZW5hYmxlPw0KPiA+DQo+ID4gSWYgdGhlIGJpdCB0aGF0IGluIFBDSUVfTVNJ X1NUQVRVU19PRkZTRVQgcmVnaXN0ZXIgaXMgc2V0IGJ1dCBub3QgaW4NCj4gPiBtc2lfZW5hYmxl LCBpdCBtdXN0IGJlIGFuIGFibm9ybWFsIHVzYWdlIG9mIE1TSSBvciBzb21ldGhpbmcgZ29lcyB3 cm9uZywNCj4gPiBpdCBzaG91bGQgYmUgaWdub3JlZCBpbiBjYXNlIHdlIGNhbiBub3QgZmluZCB0 aGUgY29ycmVzcG9uZGluZyBoYW5kbGVyLg0KPiA+DQo+ID4gPiBTb3VuZHMgbGlrZSB5b3UnbGwg anVzdCBzcGluLWxvb3AgZm9yZXZlciB3aXRob3V0IGFja25vd2xlZGdpbmcgdGhlDQo+ID4gPiBp bnRlcnJ1cHQuDQo+ID4NCj4gPiBUaGUgaW50ZXJydXB0IHdpbGwgYmUgYWNrbm93bGVkZ2VkIGlu IHRoZSBpcnFfYWNrIGNhbGxiYWNrIG9mDQo+ID4gbXRrX21zaV9pcnFfY2hpcCwgd2hpY2ggYmVs b25ncyB0byB0aGUgbXNpX2RvbWFpbi4NCj4gDQo+IExldCdzIHRyeSB0byBnbyB0aHJvdWdoIGl0 IChhbmQgcGxlYXNlIGV4cGxhaW4gdG8gbWUgaWYgSSBnZXQgdGhpcyB3cm9uZykuDQo+IA0KPiBT YXkgd2UgaGF2ZToNCj4gDQo+IG1zaV9lbmFibGUgPSBbUENJRV9NU0lfRU5BQkxFX09GRlNFVF0g PSAweDE7DQo+IA0KPiB3aGlsZSBsb29wOg0KPiANCj4gbXNpX3N0YXR1cyA9IFtQQ0lFX01TSV9T VEFUVVNfT0ZGU0VUXSA9IDB4MzsNCj4gbXNpX3N0YXR1cyAmPSBtc2lfZW5hYmxlID0+IG1zaV9z dGF0dXMgPSAweDMgJiAweDEgPSAweDE7DQo+IGZvcl9lYWNoX3NldF9iaXQobXNpX3N0YXR1cykg ew0KPiAgICBkbyBzb21ldGhpbmcgdGhhdCBwcmVzdW1hYmx5IHdpbGwgZGlzYWJsZSB0aGUgTVNJ IGludGVycnVwdCBzdGF0dXM/DQoNClllcywgdGhlIGNvcnJlc3BvbmRpbmcgaW50ZXJydXB0IHN0 YXR1cyB3aWxsIGJlIGNsZWFyZWQuDQoNCj4gfQ0KPiAobmV4dCBsb29wIGl0ZXJhdGlvbikNCj4g DQo+IG1zaV9zdGF0dXMgPSBbUENJRV9NU0lfU1RBVFVTX09GRlNFVF0gPSAweDI7DQo+IG1zaV9z dGF0dXMgJj0gbXNpX2VuYWJsZSA9PiBtc2lfc3RhdHVzID0gMHgyICYgMHgxID0gMHgwOw0KPiBm b3JfZWFjaF9zZXRfYml0KG1zaV9zdGF0dXMpID0+IGRvZXMgbm90aGluZy4NCj4gDQo+IG1zaV9z dGF0dXMgPSBbUENJRV9NU0lfU1RBVFVTX09GRlNFVF0gPSAweDI7DQo+IChpbmZpbml0ZSBsb29w KQ0KPiANCj4gQmFzaWNhbGx5LCBJJ20gd29uZGVyaW5nIGlmIHlvdSBzaG91bGQgcmVwbGFjZSB0 aGUgd2hpbGUgY29uZGl0aW9uDQo+IHN0YXRlbWVudCB3aXRoOg0KPiANCj4gd2hpbGUgKChtc2lf c3RhdHVzID0gcmVhZGwobXNpX2luZm8tPmJhc2UgKyBQQ0lFX01TSV9TVEFUVVNfT0ZGU0VUKSAm DQo+IG1zaV9lbmFibGUpKQ0KPiANCg0KWWVzLCBpdCB3aWxsIGJlIGEgZGVhZCBsb29wIGlmIHdl IHJlY2VpdmUgYW4gYWJub3JtYWwgaW50ZXJydXB0IHN0YXR1cywNCkkgd2lsbCBmaXggaXQgaW4g dGhlIG5leHQgdmVyc2lvbiwgdGhhbmtzIGZvciB5b3VyIGtpbmRseSByZXZpZXcuDQoNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTGludXgtbWVk aWF0ZWsgbWFpbGluZyBsaXN0DQo+IExpbnV4LW1lZGlhdGVrQGxpc3RzLmluZnJhZGVhZC5vcmcN Cj4gaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1tZWRp YXRlaw0KDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9B69C433E0 for ; Tue, 22 Dec 2020 08:42:58 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6D8E4229CA for ; Tue, 22 Dec 2020 08:42:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D8E4229CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PVSrGXkxdMXYW3AkeFrmZEd/h65cRvat71iUaYzt/3M=; b=hjM4JrPTgElqFbo/VO14j5lwG QieHUJYOzY8+iWQPrP44glEayrGhfghMdbVAAqOfN01YtS7eBuyZzOyOkAnpLYqtU7TNHhkrKqPUT LFN4ZsW+Sz0wOrOBXb51uMEwlkZn11Ng8RG+OMpTbmPW9B6CzrrQVnlK8zNVTSoYfRZjHXq78ddOr gjOLY6b23qxMWdSaZEN2meghFDD1uLlUSr4bAzUOHIxtGIAWcAGqoqRi7QOFCGuBEKFCOhZesvKl+ GCFH0ToSQJ/k8RH90bqqD6enmQNNBmARz9ch7o2noSmYTU3EIFaE/wBE7rzFS8QU4FZaPqQC/QjD8 0i6Qfe0sw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1krdFk-0003FS-Hr; Tue, 22 Dec 2020 08:42:44 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1krdFi-0003E5-87; Tue, 22 Dec 2020 08:42:43 +0000 X-UUID: cd3a09e6bd6a431ba82881450e3b3e26-20201222 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=YLfMy68wBB6UlNustrhsqE6gJYC3N0UvKOcE4aN9Y+k=; b=VaN4Cy8Rsgdt8m3E+NW3DBk5X+RJNigwT5q0LkDBbPNHO6Fn/wEt1LIvYhyI8zzwfbAwoUHFX/ULirsOEcUGiCC2A72ajK0Y8VQqwOz2WhLbo5Xp8VeKTm4rbFXt5qPbY6tvnquxpz1jT8UmkfVS4bx4kPJNi62d1foZQW/nWFI=; X-UUID: cd3a09e6bd6a431ba82881450e3b3e26-20201222 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1386259301; Tue, 22 Dec 2020 00:42:32 -0800 Received: from MTKMBS31DR.mediatek.inc (172.27.6.102) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 00:38:22 -0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 16:38:16 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 22 Dec 2020 16:38:15 +0800 Message-ID: <1608626297.14736.113.camel@mhfsdcap03> Subject: Re: [v5,2/3] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192 From: Jianjun Wang To: Nicolas Boichat Date: Tue, 22 Dec 2020 16:38:17 +0800 In-Reply-To: References: <20201202133813.6917-1-jianjun.wang@mediatek.com> <20201202133813.6917-3-jianjun.wang@mediatek.com> <1608608319.14736.97.camel@mhfsdcap03> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 00173604EC7CD22A602B7873EB32C70165C8892601EF854DADCCF59B40BAB8542000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201222_034242_432183_DD216F40 X-CRM114-Status: GOOD ( 34.51 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: youlin.pei@mediatek.com, Devicetree List , Lorenzo Pieralisi , qizhong.cheng@mediatek.com, Chuanjia Liu , Mauro Carvalho Chehab , linux-pci@vger.kernel.org, lkml , Ryder Lee , Sj Huang , Rob Herring , "moderated list:ARM/Mediatek SoC support" , Philipp Zabel , Bjorn Helgaas , sin_jieyang@mediatek.com, "David S . Miller" , linux-arm Mailing List , Matthias Brugger Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Tue, 2020-12-22 at 11:55 +0800, Nicolas Boichat wrote: > On Tue, Dec 22, 2020 at 11:38 AM Jianjun Wang wrote: > > > > On Mon, 2020-12-21 at 10:18 +0800, Nicolas Boichat wrote: > > > On Wed, Dec 2, 2020 at 9:39 PM Jianjun Wang wrote: > > > > [snip] > > > > +static irq_hw_number_t mtk_pcie_msi_get_hwirq(struct msi_domain_info *info, > > > > + msi_alloc_info_t *arg) > > > > +{ > > > > + struct msi_desc *entry = arg->desc; > > > > + struct mtk_pcie_port *port = info->chip_data; > > > > + int hwirq; > > > > + > > > > + mutex_lock(&port->lock); > > > > + > > > > + hwirq = bitmap_find_free_region(port->msi_irq_in_use, PCIE_MSI_IRQS_NUM, > > > > + order_base_2(entry->nvec_used)); > > > > + if (hwirq < 0) { > > > > + mutex_unlock(&port->lock); > > > > + return -ENOSPC; > > > > + } > > > > + > > > > + mutex_unlock(&port->lock); > > > > + > > > > + return hwirq; > > > > > > Code is good, but I had to look twice to make sure the mutex is > > > unlocked. Is the following marginally better? > > > > > > hwirq = ...; > > > > > > mutex_unlock(&port->lock); > > > > > > if (hwirq < 0) > > > return -ENOSPC; > > > > > > return hwirq; > > > > Impressive, I will fix it in the next version, and I think the hwirq can > > be returned directly since it will be a negative value if > > bitmap_find_free_region is failed. The code will be like the following: > > > > hwirq = ...; > > > > mutex_unlock(&port->lock); > > > > return hwirq; > > SG, as long as you're okay with returning -ENOMEM instead of -ENOSPC. > > But now I'm having doubt if negative return values are ok, as > irq_hw_number_t is unsigned long. > > msi_domain_alloc > (https://elixir.bootlin.com/linux/latest/source/kernel/irq/msi.c#L143) > uses it to call irq_find_mapping > (https://elixir.bootlin.com/linux/latest/source/kernel/irq/irqdomain.c#L882) > without check, and I'm not convinced irq_find_mapping will error out > gracefully... > I see, it seems the msi_domain_alloc function assume the get_hwirq callback always success, maybe I should allocate the real hwirq in the msi_prepare (https://elixir.bootlin.com/linux/latest/source/kernel/irq/msi.c#L304) and set it to arg->hwirq, and override the set_desc (https://elixir.bootlin.com/linux/latest/source/drivers/pci/msi.c#L1405) to prevent the modify of arg->hwirq. > > > > > > > +} > > > > + > > > > [snip] > > > > +static void mtk_pcie_msi_handler(struct irq_desc *desc) > > > > +{ > > > > + struct mtk_pcie_msi *msi_info = irq_desc_get_handler_data(desc); > > > > + struct irq_chip *irqchip = irq_desc_get_chip(desc); > > > > + unsigned long msi_enable, msi_status; > > > > + unsigned int virq; > > > > + irq_hw_number_t bit, hwirq; > > > > + > > > > + chained_irq_enter(irqchip, desc); > > > > + > > > > + msi_enable = readl(msi_info->base + PCIE_MSI_ENABLE_OFFSET); > > > > + while ((msi_status = readl(msi_info->base + PCIE_MSI_STATUS_OFFSET))) { > > > > + msi_status &= msi_enable; > > > > > > I don't know much about MSI, but what happens if you have a bit that > > > is set in PCIE_MSI_STATUS_OFFSET register, but not in msi_enable? > > > > If the bit that in PCIE_MSI_STATUS_OFFSET register is set but not in > > msi_enable, it must be an abnormal usage of MSI or something goes wrong, > > it should be ignored in case we can not find the corresponding handler. > > > > > Sounds like you'll just spin-loop forever without acknowledging the > > > interrupt. > > > > The interrupt will be acknowledged in the irq_ack callback of > > mtk_msi_irq_chip, which belongs to the msi_domain. > > Let's try to go through it (and please explain to me if I get this wrong). > > Say we have: > > msi_enable = [PCIE_MSI_ENABLE_OFFSET] = 0x1; > > while loop: > > msi_status = [PCIE_MSI_STATUS_OFFSET] = 0x3; > msi_status &= msi_enable => msi_status = 0x3 & 0x1 = 0x1; > for_each_set_bit(msi_status) { > do something that presumably will disable the MSI interrupt status? Yes, the corresponding interrupt status will be cleared. > } > (next loop iteration) > > msi_status = [PCIE_MSI_STATUS_OFFSET] = 0x2; > msi_status &= msi_enable => msi_status = 0x2 & 0x1 = 0x0; > for_each_set_bit(msi_status) => does nothing. > > msi_status = [PCIE_MSI_STATUS_OFFSET] = 0x2; > (infinite loop) > > Basically, I'm wondering if you should replace the while condition > statement with: > > while ((msi_status = readl(msi_info->base + PCIE_MSI_STATUS_OFFSET) & > msi_enable)) > Yes, it will be a dead loop if we receive an abnormal interrupt status, I will fix it in the next version, thanks for your kindly review. > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4A68C433E0 for ; Tue, 22 Dec 2020 08:44:08 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7422A2311D for ; Tue, 22 Dec 2020 08:44:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7422A2311D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7MEw2Ape+K5X0l4yzMSRq027YdDiYw/wn84DjfvE5/k=; b=QOUrps/XMYC57UiBIMdd2mwZh NpPZDGgQmqksA3dTE+Y+qt8bgSDYzcTY6abdQs4ZeNZJHbjwJ3RgO6760iId7I5NQZNGjcbTmT3N3 tw7BFbXCm+C0f+NlQXCZ8llWNHVqyRVOLlOGuubr3m84p/ETh+UXaQv+BalH9BssgIEMbxcg96eF8 7V5RwJdJMPBu66HpZSLyUiGSnsY0yVzzTtPcgvfw2Tpffsa89heyUz0E1RF/kYnzabgp5PaPqzge4 NB8Wqdw/5jwnBzPKCbvY3TOIdg/BXUuNrtDrMm5VxB5ueF6RZ2MAQT4GGFOgyCU/8ewVXlSAH3Qnv If80RaX3w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1krdFl-0003Fl-Gf; Tue, 22 Dec 2020 08:42:45 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1krdFi-0003E5-87; Tue, 22 Dec 2020 08:42:43 +0000 X-UUID: cd3a09e6bd6a431ba82881450e3b3e26-20201222 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=YLfMy68wBB6UlNustrhsqE6gJYC3N0UvKOcE4aN9Y+k=; b=VaN4Cy8Rsgdt8m3E+NW3DBk5X+RJNigwT5q0LkDBbPNHO6Fn/wEt1LIvYhyI8zzwfbAwoUHFX/ULirsOEcUGiCC2A72ajK0Y8VQqwOz2WhLbo5Xp8VeKTm4rbFXt5qPbY6tvnquxpz1jT8UmkfVS4bx4kPJNi62d1foZQW/nWFI=; X-UUID: cd3a09e6bd6a431ba82881450e3b3e26-20201222 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1386259301; Tue, 22 Dec 2020 00:42:32 -0800 Received: from MTKMBS31DR.mediatek.inc (172.27.6.102) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 00:38:22 -0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 16:38:16 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 22 Dec 2020 16:38:15 +0800 Message-ID: <1608626297.14736.113.camel@mhfsdcap03> Subject: Re: [v5,2/3] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192 From: Jianjun Wang To: Nicolas Boichat Date: Tue, 22 Dec 2020 16:38:17 +0800 In-Reply-To: References: <20201202133813.6917-1-jianjun.wang@mediatek.com> <20201202133813.6917-3-jianjun.wang@mediatek.com> <1608608319.14736.97.camel@mhfsdcap03> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 00173604EC7CD22A602B7873EB32C70165C8892601EF854DADCCF59B40BAB8542000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201222_034242_432183_DD216F40 X-CRM114-Status: GOOD ( 34.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: youlin.pei@mediatek.com, Devicetree List , Lorenzo Pieralisi , qizhong.cheng@mediatek.com, Chuanjia Liu , Mauro Carvalho Chehab , linux-pci@vger.kernel.org, lkml , Ryder Lee , Sj Huang , Rob Herring , "moderated list:ARM/Mediatek SoC support" , Philipp Zabel , Bjorn Helgaas , sin_jieyang@mediatek.com, "David S . Miller" , linux-arm Mailing List , Matthias Brugger Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 2020-12-22 at 11:55 +0800, Nicolas Boichat wrote: > On Tue, Dec 22, 2020 at 11:38 AM Jianjun Wang wrote: > > > > On Mon, 2020-12-21 at 10:18 +0800, Nicolas Boichat wrote: > > > On Wed, Dec 2, 2020 at 9:39 PM Jianjun Wang wrote: > > > > [snip] > > > > +static irq_hw_number_t mtk_pcie_msi_get_hwirq(struct msi_domain_info *info, > > > > + msi_alloc_info_t *arg) > > > > +{ > > > > + struct msi_desc *entry = arg->desc; > > > > + struct mtk_pcie_port *port = info->chip_data; > > > > + int hwirq; > > > > + > > > > + mutex_lock(&port->lock); > > > > + > > > > + hwirq = bitmap_find_free_region(port->msi_irq_in_use, PCIE_MSI_IRQS_NUM, > > > > + order_base_2(entry->nvec_used)); > > > > + if (hwirq < 0) { > > > > + mutex_unlock(&port->lock); > > > > + return -ENOSPC; > > > > + } > > > > + > > > > + mutex_unlock(&port->lock); > > > > + > > > > + return hwirq; > > > > > > Code is good, but I had to look twice to make sure the mutex is > > > unlocked. Is the following marginally better? > > > > > > hwirq = ...; > > > > > > mutex_unlock(&port->lock); > > > > > > if (hwirq < 0) > > > return -ENOSPC; > > > > > > return hwirq; > > > > Impressive, I will fix it in the next version, and I think the hwirq can > > be returned directly since it will be a negative value if > > bitmap_find_free_region is failed. The code will be like the following: > > > > hwirq = ...; > > > > mutex_unlock(&port->lock); > > > > return hwirq; > > SG, as long as you're okay with returning -ENOMEM instead of -ENOSPC. > > But now I'm having doubt if negative return values are ok, as > irq_hw_number_t is unsigned long. > > msi_domain_alloc > (https://elixir.bootlin.com/linux/latest/source/kernel/irq/msi.c#L143) > uses it to call irq_find_mapping > (https://elixir.bootlin.com/linux/latest/source/kernel/irq/irqdomain.c#L882) > without check, and I'm not convinced irq_find_mapping will error out > gracefully... > I see, it seems the msi_domain_alloc function assume the get_hwirq callback always success, maybe I should allocate the real hwirq in the msi_prepare (https://elixir.bootlin.com/linux/latest/source/kernel/irq/msi.c#L304) and set it to arg->hwirq, and override the set_desc (https://elixir.bootlin.com/linux/latest/source/drivers/pci/msi.c#L1405) to prevent the modify of arg->hwirq. > > > > > > > +} > > > > + > > > > [snip] > > > > +static void mtk_pcie_msi_handler(struct irq_desc *desc) > > > > +{ > > > > + struct mtk_pcie_msi *msi_info = irq_desc_get_handler_data(desc); > > > > + struct irq_chip *irqchip = irq_desc_get_chip(desc); > > > > + unsigned long msi_enable, msi_status; > > > > + unsigned int virq; > > > > + irq_hw_number_t bit, hwirq; > > > > + > > > > + chained_irq_enter(irqchip, desc); > > > > + > > > > + msi_enable = readl(msi_info->base + PCIE_MSI_ENABLE_OFFSET); > > > > + while ((msi_status = readl(msi_info->base + PCIE_MSI_STATUS_OFFSET))) { > > > > + msi_status &= msi_enable; > > > > > > I don't know much about MSI, but what happens if you have a bit that > > > is set in PCIE_MSI_STATUS_OFFSET register, but not in msi_enable? > > > > If the bit that in PCIE_MSI_STATUS_OFFSET register is set but not in > > msi_enable, it must be an abnormal usage of MSI or something goes wrong, > > it should be ignored in case we can not find the corresponding handler. > > > > > Sounds like you'll just spin-loop forever without acknowledging the > > > interrupt. > > > > The interrupt will be acknowledged in the irq_ack callback of > > mtk_msi_irq_chip, which belongs to the msi_domain. > > Let's try to go through it (and please explain to me if I get this wrong). > > Say we have: > > msi_enable = [PCIE_MSI_ENABLE_OFFSET] = 0x1; > > while loop: > > msi_status = [PCIE_MSI_STATUS_OFFSET] = 0x3; > msi_status &= msi_enable => msi_status = 0x3 & 0x1 = 0x1; > for_each_set_bit(msi_status) { > do something that presumably will disable the MSI interrupt status? Yes, the corresponding interrupt status will be cleared. > } > (next loop iteration) > > msi_status = [PCIE_MSI_STATUS_OFFSET] = 0x2; > msi_status &= msi_enable => msi_status = 0x2 & 0x1 = 0x0; > for_each_set_bit(msi_status) => does nothing. > > msi_status = [PCIE_MSI_STATUS_OFFSET] = 0x2; > (infinite loop) > > Basically, I'm wondering if you should replace the while condition > statement with: > > while ((msi_status = readl(msi_info->base + PCIE_MSI_STATUS_OFFSET) & > msi_enable)) > Yes, it will be a dead loop if we receive an abnormal interrupt status, I will fix it in the next version, thanks for your kindly review. > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel