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.6 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 70CE7C433E2 for ; Mon, 13 Jul 2020 06:11:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C5282065F for ; Mon, 13 Jul 2020 06:11:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="FS11oL08" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729091AbgGMGLs (ORCPT ); Mon, 13 Jul 2020 02:11:48 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:5151 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727107AbgGMGLs (ORCPT ); Mon, 13 Jul 2020 02:11:48 -0400 X-UUID: 09583ab690804765a025f16a6515d568-20200713 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=4vEP1HF0Q3QvDpYB3OMoRNc2npFo0RTElHQW9KJ35Dc=; b=FS11oL08+hRTmcxJ6dQYj+ovay/NdyNli8ZllVhoC5r7Qitav/qNdbGubN/WcGlUyOHVf7I0bWeF0zgIYkJ5qFT0Mg5PGlJJ87i8hvZe02Kxmt9+9QbDO/TtnAOUsd4g54TlEeItGG/iS78NYVvZW+1EO0RYv2BpenIdSAdw61A=; X-UUID: 09583ab690804765a025f16a6515d568-20200713 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 729864613; Mon, 13 Jul 2020 14:11:39 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jul 2020 14:11:36 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 13 Jul 2020 14:11:36 +0800 Message-ID: <1594620698.22730.17.camel@mtkswgap22> Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6779 driver From: Neal Liu To: Matthias Brugger CC: Neal Liu , Rob Herring , , , lkml , "moderated list:ARM/Mediatek SoC support" , Date: Mon, 13 Jul 2020 14:11:38 +0800 In-Reply-To: <922d93be-0243-bd7e-81fd-e0068a90ef4b@gmail.com> References: <1594027693-19530-1-git-send-email-neal.liu@mediatek.com> <1594027693-19530-3-git-send-email-neal.liu@mediatek.com> <1594107170.20820.84.camel@mtkswgap22> <922d93be-0243-bd7e-81fd-e0068a90ef4b@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: A4163080B86FE9835E37A8AABD162877054BB17FBCB2ED198E917A5C279E90912000:8 X-MTK: N Content-Transfer-Encoding: base64 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org W3NuaXBdDQo+ID4+PiArLyoNCj4gPj4+ICsgKiBkZXZhcGNfdmlvbGF0aW9uX2lycSAtIHRoZSBk ZXZhcGMgSW50ZXJydXB0IFNlcnZpY2UgUm91dGluZSAoSVNSKSB3aWxsIGR1bXANCj4gPj4+ICsg KgkJCSAgdmlvbGF0aW9uIGluZm9ybWF0aW9uIGluY2x1ZGluZyB3aGljaCBtYXN0ZXIgdmlvbGF0 ZXMNCj4gPj4+ICsgKgkJCSAgYWNjZXNzIHNsYXZlLg0KPiA+Pj4gKyAqLw0KPiA+Pj4gK3N0YXRp YyBpcnFyZXR1cm5fdCBkZXZhcGNfdmlvbGF0aW9uX2lycShpbnQgaXJxX251bWJlciwNCj4gPj4+ ICsJCQkJCXN0cnVjdCBtdGtfZGV2YXBjX2NvbnRleHQgKmRldmFwY19jdHgpDQo+ID4+PiArew0K PiA+Pj4gKwljb25zdCBzdHJ1Y3QgbXRrX2RldmljZV9pbmZvICoqZGV2aWNlX2luZm8gPSBkZXZh cGNfY3R4LT5kZXZpY2VfaW5mbzsNCj4gPj4+ICsJaW50IHZpb19pZHggPSAtMTsNCj4gPj4+ICsJ aW50IGluZGV4ID0gLTE7DQo+ID4+PiArCWludCBzbGF2ZV90eXBlOw0KPiA+Pj4gKw0KPiA+Pj4g Kwlmb3IgKHNsYXZlX3R5cGUgPSAwOyBzbGF2ZV90eXBlIDwgU0xBVkVfVFlQRV9OVU07IHNsYXZl X3R5cGUrKykgew0KPiA+Pj4gKwkJaWYgKCFtdGtfZGV2YXBjX2R1bXBfdmlvX2RiZyhkZXZhcGNf Y3R4LCBzbGF2ZV90eXBlLCAmdmlvX2lkeCwNCj4gPj4+ICsJCQkJCSAgICAgJmluZGV4KSkNCj4g Pj4+ICsJCQljb250aW51ZTsNCj4gPj4+ICsNCj4gPj4+ICsJCS8qIEVuc3VyZSB0aGF0IHZpb2xh dGlvbiBpbmZvIGFyZSB3cml0dGVuIGJlZm9yZQ0KPiA+Pj4gKwkJICogZnVydGhlciBvcGVyYXRp b25zDQo+ID4+PiArCQkgKi8NCj4gPj4+ICsJCXNtcF9tYigpOw0KPiA+Pj4gKw0KPiA+Pj4gKwkJ bWFza19tb2R1bGVfaXJxKGRldmFwY19jdHgsIHNsYXZlX3R5cGUsIHZpb19pZHgsIHRydWUpOw0K PiA+Pj4gKw0KPiA+Pj4gKwkJY2xlYXJfdmlvX3N0YXR1cyhkZXZhcGNfY3R4LCBzbGF2ZV90eXBl LCB2aW9faWR4KTsNCj4gPj4+ICsNCj4gPj4+ICsJCXByX2luZm8oUEZYICJWaW9sYXRpb24gLSBz bGF2ZV90eXBlOjB4JXgsIHN5c19pbmRleDoweCV4LCBjdHJsX2luZGV4OjB4JXgsIHZpb19pbmRl eDoweCV4XG4iLA0KPiA+Pj4gKwkJCXNsYXZlX3R5cGUsDQo+ID4+PiArCQkJZGV2aWNlX2luZm9b c2xhdmVfdHlwZV1baW5kZXhdLnN5c19pbmRleCwNCj4gPj4+ICsJCQlkZXZpY2VfaW5mb1tzbGF2 ZV90eXBlXVtpbmRleF0uY3RybF9pbmRleCwNCj4gPj4+ICsJCQlkZXZpY2VfaW5mb1tzbGF2ZV90 eXBlXVtpbmRleF0udmlvX2luZGV4KTsNCj4gPj4NCj4gPj4gSG93IHdpbGwgdGhhdCB0aGVuIGJl IHVzZWQ/IFdpbGwgdGhlcmUgc29tZSBraW5kIG9mIHVzZXItc3BhY2UgZGFlbW9uIHdoaWNoIHdp bGwNCj4gPj4gcGFyc2UgdGhlIGtlcm5lbCBsb2cgdG8gc2VlIGlmIGEgdmlvbGF0aW9uIGhhcHBl bnM/IFdoYXQgd2lsbCBpdCBkbyB3aXRoIHRoaXMNCj4gPj4gaW5mb3JtYXRpb24/DQo+ID4+DQo+ ID4+IEkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgd2UgbmVlZCB0byBkbyB0aGF0IGluIHRo ZSBrZXJuZWwgaW5zdGVhZCBvZiBpbg0KPiA+PiBURi1BLiBDYW4geW91IHBsZWFzZSBleHBsYWlu Pw0KPiA+Pg0KPiA+IA0KPiA+IFdlIHdvdWxkIGRvIGRpZmZlcmVudCBleHRyYSBoYW5kbGUgZm9y IGRpZmZlcmVudCBidXMgbWFzdGVycyBpbnRlcm5hbGx5Lg0KPiANCj4gRG9lcyB0aGlzIG1lYW4g dGhhdCB0aGlzIGlzIG9ubHkgb25lIHBhcnQgb2YgdGhlIHdob2xlIHN0b3J5PyBBcmUgeW91IHBs YW5uaW5nIA0KPiB0byBob29rIGludG8gdGhhdCBjb2RlIGludGVybmFsbHkgdG8gaW1wbGVtZW50 IHRoZSBoYW5kbGluZz8NCj4gSW4gdGhhdCB3ZSB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgdGhlIHdo b2xlIHRoaW5nIGluIHVwc3RyZWFtLiBBbmQgdGhpcyBzb3VuZHMgDQo+IGxpa2UgeW91IHdpbGwg bmVlZCBhIG5ldyBzdWJzeXN0ZW0gZm9yIGJ1cyBmaXJld2FsbCAob3IgaG93IHlvdSB3YW50IHRv IG5hbWUgDQo+IGl0KS4gV2hpY2ggYWxsb3dzIHlvdSB0byBlYXNpbHkgYWRkIHN1cHBvcnQgZm9y IG90aGVyIHZlbmRvcnMgU29Dcy4NCj4gDQoNCk5vLCB0aGUgZXh0cmEgaGFuZGxpbmcgaXMgaW1w bGVtZW50ZWQgYnkgTWVkaWF0ZWsgcHJvcHJpZXRhcnkgZHJpdmVycw0Kd2hpY2ggaGFzIG5vIHBs YW4gdG8gdXBzdHJlYW0uIEFuZCB0aGVyZSBpcyBubyBuZWVkIGZvciBmaXJzdCBwYXRjaCBvZg0K bXRrLWRldmFwYyBkcml2ZXIuDQpXaHkgZG8geW91IHRoaW5rIGl0IG5lZWQgdG8gc3VwcG9ydD8g YW5kIHdoeSBpdCB3aWxsIG5lZWQgYSBuZXcNCnN1YnN5c3RlbT8NCg0KVGhlIGJhc2ljIGZ1bmN0 aW9uYWxpdHkgb2YgdGhpcyBkcml2ZXIgaXMgdGhhdCBpdCB3aWxsIGhhbmRsZSB2aW9sYXRpb24N CmludGVycnVwdCwgYW5kIHByaW50IHZpb2xhdGlvbiBpbmZvcm1hdGlvbiBsb2dzIGZvciBmdXJ0 aGVyIGFuYWx5c2lzLg0KRXh0cmEgaGFuZGxpbmcgaGVscHMgdXMgdG8gYW5hbHl6ZSB2aW9sYXRp b24gbW9yZSBlYXNpbHksIGJ1dCBpdCdzIG5vdCBhDQpiYXNpYyBmdW5jdGlvbmFsaXR5IG9mIGl0 Lg0KDQo+ID4gQmFzaWNhbGx5LCBkaWZmZXJlbnQgYnVzIG1hc3RlcnMgaGF2ZSBkaWZmZXJlbnQg ZGVidWcgbWVjaGFuaXNtLg0KPiA+IEFuZCBkaWZmZXJlbnQgY3VzdG9tZXJzIGhhdmUgZGlmZmVy ZW50IHNldmVyaXR5IGFib3V0IGRldmFwYyB2aW9sYXRpb24uDQo+ID4gRm9yIGV4YW1wbGUsIGtl cm5lbCBleGNlcHRpb24sIGV4dGVybmFsIGV4Y2VwdGlvbiwgd2FybmluZywgZG9uJ3QNCj4gPiBj YXJlLC4uLg0KPiA+IA0KPiA+IEkgbGlzdCAyIHJlYXNvbiB3aHkgSSBwdXQgaXQgaW4ga2VybmVs IGluc3RlYWQgb2YgQVRGLg0KPiA+IDEuIFJpY2ggT1Mgc3VjaCBhcyBMaW51eCBrZXJuZWwgaGFz IG1vcmUgZGVidWcgbWVjaGFuaXNtIGFuZCB0b29scyB0bw0KPiA+IGZpbmQgbXVyZGVyZXIuDQo+ IA0KPiBCdXQgeW91IGNhbiBhY2Nlc3MgcG9yZ3JhbSBjb3VudGVyIGZyb20gRUwzIGFzIHdlbGws IHNvIHlvdSBjb3VsZCBwcmludCBhbGwgdGhlIA0KPiBpbmZvIHlvdSBuZWVkIGluIFRGLUEuDQoN CkZvciBsZWFzdCBwcml2aWxlZ2UgcHJpbmNpcGxlLCB0aGVyZSBpcyBubyByZWFzb24gd2Ugc2hv dWxkIHByaW50IGFsbA0KdGhlIHZpb2xhdGlvbiBpbmZvcm1hdGlvbiBpbiBURi1BLg0KDQo+IA0K PiA+IDIuIElmIGludGVycnVwdCBoYXMgdG8gYmUgaGFuZGxlZCBpbiBBVEYsIEdJQyBpbnRyIHdv dWxkIGJlIHNldCBhcyBHMFMNCj4gPiAoR3JvdXAgMCBTZWN1cmUpLiBGb3Igb3VyIGludGVycnVw dCByb3V0aW5nLCBHMFMgaW50ciB3b3VsZCBiZSBmaXEuIFdoZW4NCj4gPiB3ZSBoYW5kbGUgaXQg aW4gRUwzLCBpdCB3b3VsZCBtYXNrIGFsbCBFTDEgaXJxIHRlbXBvcmFyaWx5LiBXZSBkbyBub3QN Cj4gPiB0cmVhdCBkZXZhcGMgaW50ZXJydXB0IGFzIHN1Y2ggY3JpdGljYWwuDQo+IA0KPiBCdXQg eW91IHNhaWQgInZpb2xhdGlvbiBzY2VuYXJpbyBpcyB1bmV4cGVjdGVkIiBzbyBhY3R1YWxseSB5 b3UgZG9uJ3QgZXhwZWN0IGl0IA0KPiB0byBoYXBwZW4uDQo+IA0KPiA+IA0KPiA+IERvZSBpdCBt YWtlIHNlbnNlPyBPciBkbyB5b3UgaGF2ZSBhbnkgcmVhc29uIHRoYXQgaXQgc2hvdWxkIGJlIGhh bmRsZWQNCj4gPiBpbiBBVEY/DQo+ID4gDQo+IA0KPiBNeSByZWFzb25pbmcgaXMgdGhhdCB5b3Ug YnJpbmcgYSBzZWN1cml0eSBtZWNoYW5pc20gaW50byB0aGUga2VybmVsLCB3aGljaCBpcyBpbiAN Cj4gbm9uZS1zZWN1cmUgc3RhdGUuIFRoYXQncyBhIGNvbnRyYWRpY3Rpb24uDQoNClRoZXJlIGFy ZSB0d28gZnVuY3Rpb25hbGl0eSBmb3IgTWVkaWF0ZWsgZGV2YXBjIGhhcmR3YXJlLg0KMS4gcGVy bWlzc2lvbiBjb250cm9sL3Byb3RlY3Rpb24NCjIuIHZpb2xhdGlvbiBpbmZvDQoNCllvdSBjYW4g c2VlIHRoYXQgMS4gaXMgc2VjdXJpdHkgbWVjaGFuaXNtIGZvciBzdXJlLCBhbmQgd2UgcHV0IGl0 IGluDQpURi1BLg0KQnV0IDIuIGlzIG5vdCAic2VjdXJpdHkiIGF0IGFsbC4gaXQncyBmb3IgZGVi dWdnaW5nIHB1cnBvc2UsIHdlIHRoaW5rDQppdCdzIG5vIGFueSBzZWN1cml0eSBjb25jZXJuIHRv IHB1dCBpdCBpbiBOUy1FTDEuDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IE1hdHRoaWFzDQo+IA0KW3Nu aXBdDQoNCg== 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.5 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 0A8B1C433E1 for ; Mon, 13 Jul 2020 06:25:10 +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 C2E0020674 for ; Mon, 13 Jul 2020 06:25:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fmOaubcI"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="FS11oL08" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2E0020674 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=Ehg4Toukh5iqGXAGAZH03lvgTZLlogBmcj+SaM2kS6Y=; b=fmOaubcIxVaPfaj9UuynhEUCN HjHCN2UZp1A1BqaG6RDnhYEIIjMKedqqLslXejQVFlD8XI3k8xcuQ8yF+OMgWorqTMPckCIRJvF0v hzPcpw+d4YUrq5hmW0HxF1tGIRQxWFc0mj77lMs3D/mnBoBin4fAiFSuSVmriJOCij5k17ocQIP5T dPD0pEsx25ys/bX1NpLFyZdV1RfFa0mTOf3XMk/n5+amLHMrdZuNpFqJ3AOk24ghD0SOWYFsG43KK vH8KgY9toG2BfnCl3fFLd19FVIO5hX1r8O2PtIJ1I6hXc8zajqqbT/MDrD8o9bWXxKdAEno6Y+t39 LtwT7uLfw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jurtc-0003Fg-S8; Mon, 13 Jul 2020 06:25:00 +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 1jurtL-00038l-MY; Mon, 13 Jul 2020 06:24:45 +0000 X-UUID: 810aec2b3ed44c79810a110a2aafab60-20200712 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=4vEP1HF0Q3QvDpYB3OMoRNc2npFo0RTElHQW9KJ35Dc=; b=FS11oL08+hRTmcxJ6dQYj+ovay/NdyNli8ZllVhoC5r7Qitav/qNdbGubN/WcGlUyOHVf7I0bWeF0zgIYkJ5qFT0Mg5PGlJJ87i8hvZe02Kxmt9+9QbDO/TtnAOUsd4g54TlEeItGG/iS78NYVvZW+1EO0RYv2BpenIdSAdw61A=; X-UUID: 810aec2b3ed44c79810a110a2aafab60-20200712 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1174071723; Sun, 12 Jul 2020 22:11:46 -0800 Received: from MTKMBS02N2.mediatek.inc (172.21.101.101) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 12 Jul 2020 23:11:43 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jul 2020 14:11:36 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 13 Jul 2020 14:11:36 +0800 Message-ID: <1594620698.22730.17.camel@mtkswgap22> Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6779 driver From: Neal Liu To: Matthias Brugger Date: Mon, 13 Jul 2020 14:11:38 +0800 In-Reply-To: <922d93be-0243-bd7e-81fd-e0068a90ef4b@gmail.com> References: <1594027693-19530-1-git-send-email-neal.liu@mediatek.com> <1594027693-19530-3-git-send-email-neal.liu@mediatek.com> <1594107170.20820.84.camel@mtkswgap22> <922d93be-0243-bd7e-81fd-e0068a90ef4b@gmail.com> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: A4163080B86FE9835E37A8AABD162877054BB17FBCB2ED198E917A5C279E90912000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200713_022443_986679_AE644258 X-CRM114-Status: GOOD ( 28.88 ) 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: devicetree@vger.kernel.org, wsd_upstream@mediatek.com, lkml , Rob Herring , "moderated list:ARM/Mediatek SoC support" , Neal Liu , linux-arm-kernel@lists.infradead.org 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 [snip] > >>> +/* > >>> + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will dump > >>> + * violation information including which master violates > >>> + * access slave. > >>> + */ > >>> +static irqreturn_t devapc_violation_irq(int irq_number, > >>> + struct mtk_devapc_context *devapc_ctx) > >>> +{ > >>> + const struct mtk_device_info **device_info = devapc_ctx->device_info; > >>> + int vio_idx = -1; > >>> + int index = -1; > >>> + int slave_type; > >>> + > >>> + for (slave_type = 0; slave_type < SLAVE_TYPE_NUM; slave_type++) { > >>> + if (!mtk_devapc_dump_vio_dbg(devapc_ctx, slave_type, &vio_idx, > >>> + &index)) > >>> + continue; > >>> + > >>> + /* Ensure that violation info are written before > >>> + * further operations > >>> + */ > >>> + smp_mb(); > >>> + > >>> + mask_module_irq(devapc_ctx, slave_type, vio_idx, true); > >>> + > >>> + clear_vio_status(devapc_ctx, slave_type, vio_idx); > >>> + > >>> + pr_info(PFX "Violation - slave_type:0x%x, sys_index:0x%x, ctrl_index:0x%x, vio_index:0x%x\n", > >>> + slave_type, > >>> + device_info[slave_type][index].sys_index, > >>> + device_info[slave_type][index].ctrl_index, > >>> + device_info[slave_type][index].vio_index); > >> > >> How will that then be used? Will there some kind of user-space daemon which will > >> parse the kernel log to see if a violation happens? What will it do with this > >> information? > >> > >> I still don't understand why we need to do that in the kernel instead of in > >> TF-A. Can you please explain? > >> > > > > We would do different extra handle for different bus masters internally. > > Does this mean that this is only one part of the whole story? Are you planning > to hook into that code internally to implement the handling? > In that we would need to support the whole thing in upstream. And this sounds > like you will need a new subsystem for bus firewall (or how you want to name > it). Which allows you to easily add support for other vendors SoCs. > No, the extra handling is implemented by Mediatek proprietary drivers which has no plan to upstream. And there is no need for first patch of mtk-devapc driver. Why do you think it need to support? and why it will need a new subsystem? The basic functionality of this driver is that it will handle violation interrupt, and print violation information logs for further analysis. Extra handling helps us to analyze violation more easily, but it's not a basic functionality of it. > > Basically, different bus masters have different debug mechanism. > > And different customers have different severity about devapc violation. > > For example, kernel exception, external exception, warning, don't > > care,... > > > > I list 2 reason why I put it in kernel instead of ATF. > > 1. Rich OS such as Linux kernel has more debug mechanism and tools to > > find murderer. > > But you can access porgram counter from EL3 as well, so you could print all the > info you need in TF-A. For least privilege principle, there is no reason we should print all the violation information in TF-A. > > > 2. If interrupt has to be handled in ATF, GIC intr would be set as G0S > > (Group 0 Secure). For our interrupt routing, G0S intr would be fiq. When > > we handle it in EL3, it would mask all EL1 irq temporarily. We do not > > treat devapc interrupt as such critical. > > But you said "violation scenario is unexpected" so actually you don't expect it > to happen. > > > > > Doe it make sense? Or do you have any reason that it should be handled > > in ATF? > > > > My reasoning is that you bring a security mechanism into the kernel, which is in > none-secure state. That's a contradiction. There are two functionality for Mediatek devapc hardware. 1. permission control/protection 2. violation info You can see that 1. is security mechanism for sure, and we put it in TF-A. But 2. is not "security" at all. it's for debugging purpose, we think it's no any security concern to put it in NS-EL1. > > Regards, > Matthias > [snip] _______________________________________________ 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.5 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 18BE7C433E4 for ; Mon, 13 Jul 2020 06:26:22 +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 DE6C720674 for ; Mon, 13 Jul 2020 06:26:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iDWDauQS"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="FS11oL08" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE6C720674 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=vFcVy/OgC2ciSfhXzIrXNeP5d7fgIOPQYW4dfimqMio=; b=iDWDauQSEiC+kEG0dp1aCj9ZD JoyaKvR7jU2/l705VWdWS6MANH7seGY5oUVobYZpkiZQvMtJbqpBzlVKlCC6Ahp6/d4tGGia8oa4g cASnj2WswOIInAuMh55Bwnpze5yvPjSWF1tBnArQpzNC32+iE7aIwNm7JKXKHm43O665vDOdR+VT7 lLAG6o7wk52XfS1/3JFXTEg6YgJBgS3YMKABMzB9rXHhWJ9//IH6ETnKLdSG/UBYOkSEdQNH8gnmI v+NqaavZGaxAfz6KRjkY0jBteCb+p/+fIG5+3QBC6zmsKI5bj+M8XVKrrvV3v4HA453pck/NBy/dt ytorVxYeg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jurtX-0003DJ-TX; Mon, 13 Jul 2020 06:24:56 +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 1jurtL-00038l-MY; Mon, 13 Jul 2020 06:24:45 +0000 X-UUID: 810aec2b3ed44c79810a110a2aafab60-20200712 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=4vEP1HF0Q3QvDpYB3OMoRNc2npFo0RTElHQW9KJ35Dc=; b=FS11oL08+hRTmcxJ6dQYj+ovay/NdyNli8ZllVhoC5r7Qitav/qNdbGubN/WcGlUyOHVf7I0bWeF0zgIYkJ5qFT0Mg5PGlJJ87i8hvZe02Kxmt9+9QbDO/TtnAOUsd4g54TlEeItGG/iS78NYVvZW+1EO0RYv2BpenIdSAdw61A=; X-UUID: 810aec2b3ed44c79810a110a2aafab60-20200712 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1174071723; Sun, 12 Jul 2020 22:11:46 -0800 Received: from MTKMBS02N2.mediatek.inc (172.21.101.101) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 12 Jul 2020 23:11:43 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jul 2020 14:11:36 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 13 Jul 2020 14:11:36 +0800 Message-ID: <1594620698.22730.17.camel@mtkswgap22> Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6779 driver From: Neal Liu To: Matthias Brugger Date: Mon, 13 Jul 2020 14:11:38 +0800 In-Reply-To: <922d93be-0243-bd7e-81fd-e0068a90ef4b@gmail.com> References: <1594027693-19530-1-git-send-email-neal.liu@mediatek.com> <1594027693-19530-3-git-send-email-neal.liu@mediatek.com> <1594107170.20820.84.camel@mtkswgap22> <922d93be-0243-bd7e-81fd-e0068a90ef4b@gmail.com> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: A4163080B86FE9835E37A8AABD162877054BB17FBCB2ED198E917A5C279E90912000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200713_022443_986679_AE644258 X-CRM114-Status: GOOD ( 28.88 ) 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: devicetree@vger.kernel.org, wsd_upstream@mediatek.com, lkml , Rob Herring , "moderated list:ARM/Mediatek SoC support" , Neal Liu , linux-arm-kernel@lists.infradead.org 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 [snip] > >>> +/* > >>> + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will dump > >>> + * violation information including which master violates > >>> + * access slave. > >>> + */ > >>> +static irqreturn_t devapc_violation_irq(int irq_number, > >>> + struct mtk_devapc_context *devapc_ctx) > >>> +{ > >>> + const struct mtk_device_info **device_info = devapc_ctx->device_info; > >>> + int vio_idx = -1; > >>> + int index = -1; > >>> + int slave_type; > >>> + > >>> + for (slave_type = 0; slave_type < SLAVE_TYPE_NUM; slave_type++) { > >>> + if (!mtk_devapc_dump_vio_dbg(devapc_ctx, slave_type, &vio_idx, > >>> + &index)) > >>> + continue; > >>> + > >>> + /* Ensure that violation info are written before > >>> + * further operations > >>> + */ > >>> + smp_mb(); > >>> + > >>> + mask_module_irq(devapc_ctx, slave_type, vio_idx, true); > >>> + > >>> + clear_vio_status(devapc_ctx, slave_type, vio_idx); > >>> + > >>> + pr_info(PFX "Violation - slave_type:0x%x, sys_index:0x%x, ctrl_index:0x%x, vio_index:0x%x\n", > >>> + slave_type, > >>> + device_info[slave_type][index].sys_index, > >>> + device_info[slave_type][index].ctrl_index, > >>> + device_info[slave_type][index].vio_index); > >> > >> How will that then be used? Will there some kind of user-space daemon which will > >> parse the kernel log to see if a violation happens? What will it do with this > >> information? > >> > >> I still don't understand why we need to do that in the kernel instead of in > >> TF-A. Can you please explain? > >> > > > > We would do different extra handle for different bus masters internally. > > Does this mean that this is only one part of the whole story? Are you planning > to hook into that code internally to implement the handling? > In that we would need to support the whole thing in upstream. And this sounds > like you will need a new subsystem for bus firewall (or how you want to name > it). Which allows you to easily add support for other vendors SoCs. > No, the extra handling is implemented by Mediatek proprietary drivers which has no plan to upstream. And there is no need for first patch of mtk-devapc driver. Why do you think it need to support? and why it will need a new subsystem? The basic functionality of this driver is that it will handle violation interrupt, and print violation information logs for further analysis. Extra handling helps us to analyze violation more easily, but it's not a basic functionality of it. > > Basically, different bus masters have different debug mechanism. > > And different customers have different severity about devapc violation. > > For example, kernel exception, external exception, warning, don't > > care,... > > > > I list 2 reason why I put it in kernel instead of ATF. > > 1. Rich OS such as Linux kernel has more debug mechanism and tools to > > find murderer. > > But you can access porgram counter from EL3 as well, so you could print all the > info you need in TF-A. For least privilege principle, there is no reason we should print all the violation information in TF-A. > > > 2. If interrupt has to be handled in ATF, GIC intr would be set as G0S > > (Group 0 Secure). For our interrupt routing, G0S intr would be fiq. When > > we handle it in EL3, it would mask all EL1 irq temporarily. We do not > > treat devapc interrupt as such critical. > > But you said "violation scenario is unexpected" so actually you don't expect it > to happen. > > > > > Doe it make sense? Or do you have any reason that it should be handled > > in ATF? > > > > My reasoning is that you bring a security mechanism into the kernel, which is in > none-secure state. That's a contradiction. There are two functionality for Mediatek devapc hardware. 1. permission control/protection 2. violation info You can see that 1. is security mechanism for sure, and we put it in TF-A. But 2. is not "security" at all. it's for debugging purpose, we think it's no any security concern to put it in NS-EL1. > > Regards, > Matthias > [snip] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel