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=-4.1 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,URIBL_BLOCKED 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 94C83C433EF for ; Tue, 7 Sep 2021 21:08:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 5995461102 for ; Tue, 7 Sep 2021 21:08:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5995461102 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rosenzweig.io Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NWq+j7cYUo83gYbRYBvdgqax7uJlhioKd70xmZBqon0=; b=qeDme0XNBOLodp woHWFk32+/HI9PwzoXgeUPX8kkJZ2bFfihIOcQeR1FvE8LKLB/0nRTCVKmTfQWRZjaU5UBcttVYTD RmmvQqdQVxNV0HC2TcLk3E1rbwWNacsCRd+AYbLdLG5EZtxqMKSWnyzxnj4e46XFItddGXQTIV70l beO6WiuQ3qMflU2rO5/B9DwcPwPXY+b/rQcPNm/WHFmfPBrCYSRYdro26Yj5+OWwuVnSkkrWbnc1w LzZ6j4nvuLva8iwQFbnn9+aZpseDrqp7BPgaivAWrr3wOVESrHwdlvi+QKCpTYtuJKk/+rgToNX5d Swxle3Qb1nKxCctMSt9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNiJE-004joU-LE; Tue, 07 Sep 2021 21:07:12 +0000 Received: from rosenzweig.io ([138.197.143.207]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNiJ0-004jmb-Mn for linux-arm-kernel@lists.infradead.org; Tue, 07 Sep 2021 21:07:00 +0000 Date: Tue, 7 Sep 2021 17:06:48 -0400 From: Alyssa Rosenzweig To: Sven Peter Cc: Jassi Brar , Rob Herring , Mark Kettenis , Hector Martin , Mohamed Mediouni , Stan Skowronek , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] mailbox: apple: Add driver for Apple mailboxes Message-ID: References: <20210907145501.69161-1-sven@svenpeter.dev> <20210907145501.69161-4-sven@svenpeter.dev> <39b92560-b236-4abb-9de0-ac3a3fa3a506@www.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <39b92560-b236-4abb-9de0-ac3a3fa3a506@www.fastmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210907_140658_869736_4CA6599E X-CRM114-Status: GOOD ( 60.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org PiA+ID4gKyAqIEJvdGggdGhlIG1haW4gQ1BVIGFuZCB0aGUgY28tcHJvY2Vzc29yIHNlZSB0aGUg c2FtZSBzZXQgb2YgcmVnaXN0ZXJzIGJ1dAo+ID4gPiArICogdGhlIGZpcnN0IEZJRk8gKEEySSkg aXMgYWx3YXlzIHVzZWQgdG8gdHJhbnNmZXIgbWVzc2FnZXMgZnJvbSB0aGUgYXBwbGljYXRpb24K PiA+ID4gKyAqIHByb2Nlc3NvciAodXMpIHRvIHRoZSBJL08gcHJvY2Vzc29yIGFuZCB0aGUgc2Vj b25kIG9uZSAoSTJBKSBmb3IgdGhlCj4gPiA+ICsgKiBvdGhlciBkaXJlY3Rpb24uCj4gPiAKPiA+ IERvIHdlIGFjdHVhbGx5IGtub3cgd2hhdCB0aGUgY29wcm8gc2Vlcz8gSXQgc2VlbXMgb2J2aW91 cywgYnV0ICprbm93Kj8KPiAKPiBZZXMsIEkga25vdy4gVGhleSBzZWUgdGhlIGV4YWN0IHNhbWUg c2V0IG9mIHJlZ2lzdGVycy4gSSB3b3VsZG4ndCBoYXZlIHdyaXR0ZW4KPiBpdCBsaWtlIHRoYXQg b3RoZXJ3aXNlLgoKQWNrLgoKPiA+ID4gK3N0cnVjdCBhcHBsZV9tYm94IHsKPiA+ID4gKwl2b2lk IF9faW9tZW0gKnJlZ3M7Cj4gPiA+ICsJY29uc3Qgc3RydWN0IGFwcGxlX21ib3hfaHcgKmh3Owo+ ID4gPiArICAgICAuLi4KPiA+ID4gK307Cj4gPiAKPiA+IFRoaXMgcmVxdWlyZXMgYSBsb3Qgb2Yg cG9pbnRlciBjaGFzaW5nIHRvIHNlbmQvcmVjZWl2ZSBtZXNzYWdlcy4gV2lsbAo+ID4gdGhpcyBi ZWNvbWUgYSBwZXJmIGlzc3VlIGluIGFueSBjYXNlPyBJdCdkIGJlIGdvb2QgdG8gZ2V0IGJhbGxw YXJrcyBvbgo+ID4gaG93IG9mdGVuIHRoZXNlIG1ib3hlcyBhcmUgdXNlZC4gKEZvciBEQ1AsIGl0 IGRvZXNuJ3QgbWF0dGVyLCBvbmx5IGEgZmV3Cj4gPiBodW5kcmVkIG1lc3NhZ2VzIHBlciBzZWNv bmQuIE90aGVyIGNvcHJvcyBtYXkgaGF2ZSBkaWZmZXJlbnQgYmVoYXZpb3VyKQo+IAo+IElmIHRo aXMgYWN0dWFsbHkgYmVjb21lcyBhIHByb2JsZW0gSSdtIGhhcHB5IHRvIGZpeCBpdCBidXQgcmln aHQgbm93Cj4gdGhpcyBmZWVscyBsaWtlIHByZW1hdHVyZSBvcHRpbWl6YXRpb24gdG8gbWUuIERD UCBpcyBnb2luZyB0byBiZSB0aGUKPiB3b3JzdCBvZmZlbmRlciBmb2xsb3dlZCBieSBTTUMgKGF0 IG1vc3QgYSBmZXcgcGVyIHNlY29uZCB3aGVuIGl0J3MgcmVhbGx5Cj4gYnVzeSBkdXJpbmcgYm9v dCB0aW1lKSBhbmQgU0VQIChJJ3ZlIGFsc28gbmV2ZXIgc2VlbiBtb3JlIHRoYW4gYSBmZXcgcGVy Cj4gc2Vjb25kIGhlcmUpLiBUaGUgcmVzdCBvZiB0aGVtIGFyZSBtb3N0bHkgcXVpZXQgYWZ0ZXIg dGhleSBoYXZlIGJvb3RlZC4KCkdvb2QgZW5vdWdoIGZvciBtZSAtLSBpdCB3b24ndCBtYXR0ZXIg Zm9yIERDUCwgc28gaWYgaXQgZG9lc24ndCBnZXQgYW55CndvcnNlIHRoYW4gRENQIHRoZXJlJ3Mg bm8gcG9pbnQgaW4gb3B0aW1pemluZyB0aGlzLgoKPiA+ID4gK3N0YXRpYyBib29sIGFwcGxlX21i b3hfaHdfY2FuX3NlbmQoc3RydWN0IGFwcGxlX21ib3ggKmFwcGxlX21ib3gpCj4gPiA+ICt7Cj4g PiA+ICsJdTMyIG1ib3hfY3RybCA9Cj4gPiA+ICsJCXJlYWRsX3JlbGF4ZWQoYXBwbGVfbWJveC0+ cmVncyArIGFwcGxlX21ib3gtPmh3LT5hMmlfY29udHJvbCk7Cj4gPiA+ICsKPiA+ID4gKwlyZXR1 cm4gIShtYm94X2N0cmwgJiBhcHBsZV9tYm94LT5ody0+Y29udHJvbF9mdWxsKTsKPiA+ID4gK30K PiA+IAo+ID4gSWYgeW91IGRvIHRoZSBwb2ludGVyIGNoYXNpbmcsIEkgc3VzcGVjdCB5b3Ugd2Fu dCBhY2Nlc3Nvcgo+ID4gZnVuY3Rpb25zL21hY3JvcyBhdCBsZWFzdCB0byBtYWtlIGl0IGxlc3Mg aW50cnVzaXZlLi4uCj4gCj4gVGhlcmUncyByZWdtYXAgYnV0IHRoYXQgY2FuJ3QgZWFzaWx5IGJl IHVzZWQgaGVyZSBiZWNhdXNlIEkgbmVlZCAzMmJpdAo+IGFuZCA2NGJpdCB3cml0ZXMuIEkgYWxz byBkb24ndCByZWFsbHkgc2VlIHRoZSBhZHZhbnRhZ2Ugb2YgcmVwbGFjaW5nCj4gdGhpcyB3aXRo IHNvbWUgY3VzdG9tIGZ1bmN0aW9ucyBsaWtlIGUuZy4KPiAKPiAJbWJveF9jdHJsID0gYXBwbGVf bWJveF9od19yZWFkbChhcHBsZV9tYm94LCBhcHBsZV9tYm94LT5ody0+YTJpX2NvbnRyb2wpOwo+ IAo+IHdoaWNoIGlzIGFsbW9zdCBhcyBsb25nLiBBbmQgaWYgSSBpbnRyb2R1Y2UgYSBzZXBhcmF0 ZSBmdW5jdGlvbiBqdXN0IHRvIHJlYWQgdGhlCj4gY29udHJvbCByZWcgdGhpcyBqdXN0IGJlY29t ZXMgYSBsb3Qgb2YgYm9pbGVycGxhdGUgYW5kIGhhcmRlciB0byBmb2xsb3cuCj4gCj4gT3IgZGlk IHlvdSBoYXZlIGFueXRoaW5nIGVsc2UgaW4gbWluZD8KCkkgd2FzIGVudmlzaW9uaW5nIGEgbWFj cm86Cgo+CSNkZWZpbmUgYXBwbGVfbWJveF9yZWFkbChtYm94LCBuYW1lKSBcCj4JCXJlYWRsX3Jl bGF4ZWQobWJveC0+cmVncyArIG1ib3gtPmh3LT4gIyMgbmFtZSkKPgo+IAltYm94X2N0cmwgPSBh cHBsZV9tYm94X3JlYWRsKGFwcGxlX21ib3gsIGEyaV9jb250cm9sKTsKCk5vdyB0aGF0IEkndmUg dHlwZWQgaXQgb3V0LCBob3dldmVyLCBpdCBzZWVtcyBhIGJpdCB0b28gbWFnaWNhbCB0bwpqdXN0 aWZ5IHRoZSBtaW5vciBzcGFjZSBzYXZpbmdzLiBBbmQgZ2l2ZW4geW91IG5lZWQgYm90aCAzMmIg YW5kIDY0Ygp0aGVyZSB3b3VsZCBiZSB+NCBzdWNoIG1hY3JvcyB3aGljaCBpcyBhbHNvIGEgbG90 IG9mIGJvaWxlcnBsYXRlLgoKSXQncyBub3QgYSBodWdlIGRlYWwgZWl0aGVyIHdheSBidXQgSSB0 aG91Z2h0IEknZCByYWlzZSBpdC4KCj4gPiA+ICsJZGV2X2RiZyhhcHBsZV9tYm94LT5kZXYsICI+ IFRYICUwMTZsbHggJTA4eFxuIiwgbXNnLT5tc2cwLCBtc2ctPm1zZzEpOwo+ID4gCj4gPiBJc24n dCAiVFgiIHJlZHVuZGFudCBoZXJlPwo+IAo+IFN1cmUsIGJ1dCBpdCBhbHNvIGRvZXNuJ3QgaHVy dCBpbiBhIGRlYnVnIG1lc3NhZ2UuIEkgY2FuIHNwb3QgdGhlIFRYIGVhc2llcgo+IGJ1dCBJJ20g c3VyZSB0aGVyZSBhcmUgcGVvcGxlIHdobyBwcmVmZXIgPi4KCkZhaXIgZW5vdWdoLgoKPiA+ID4g KwlkZXZfZGJnKGFwcGxlX21ib3gtPmRldiwgImdvdCBGSUZPIGVtcHR5IElSUVxuIik7Cj4gPiAK PiA+IEkgcmVhbGl6ZSBpdCdzIGEgZGV2X2RiZyBidXQgdGhpcyBzdGlsbCBzZWVtcyB1bm5lY2Vz c2FyaWx5IG5vaXN5Lgo+IAo+IFRoaXMgY29kZSBwYXRoIGlzIGFsbW9zdCBuZXZlciByZWFjaGVk LiBJJ3ZlIG9ubHkgYmVlbiBhYmxlIHRvIHRyaWdnZXIKPiBpdCBieSBmb3JjaW5nIHNlbmRfbWVz c2FnZSB0byByZXR1cm4gRUJVU1kgZXZlbiB3aGVuIGl0IGNvdWxkIHN0aWxsCj4gbW92ZSBtZXNz YWdlcyB0byB0aGUgRklGTyB0byB0ZXN0IHRoaXMgcGF0aC4KPiBUaGlzIGFsc28gY2FuJ3QgYmUg dHJpZ2dlcmVkIG1vcmUgb2Z0ZW4gdGhhbiB0aGUgVFggZGVidWcgbWVzc2FnZS4KPiBJZiB0aGlz IHRyaWdnZXJzIG1vcmUgb2Z0ZW4gdGhlcmUncyBhIGJ1ZyBzb21ld2hlcmUgdGhhdCBrZXB0IHRo ZSBpbnRlcnJ1cHQKPiBlbmFibGVkIGFuZCB0aGVuIHRoZSB3aG9sZSBtYWNoaW5lIHdpbGwgaGFu ZyBkdWUgYW4gaW50ZXJydXB0IHN0b3JtIGFueXdheS4gSW4KPiB0aGF0IGNhc2UgSSdkIHByZWZl ciB0byBoYXZlIHRoaXMgYXMgbm9pc3kgYXMgcG9zc2libGUuCgpBaCEgU3VyZSwgbWFrZXMgc2Vu c2UuIElzIGl0IHdvcnRoIGFkZGluZyBhIGZldyB3b3JkcyB0byB0aGUgZnVuY3Rpb25zCmNvbW1l bnRzIGluZGljYXRpbmcgdGhpcyByYXJlbHkgb2NjdXJzIGluIGdvb2QgY29uZGl0aW9ucz8KCj4g PiA+ICtzdGF0aWMgaXJxcmV0dXJuX3QgYXBwbGVfbWJveF9yZWN2X2lycShpbnQgaXJxLCB2b2lk ICpkYXRhKQo+ID4gPiArewo+ID4gPiArCXN0cnVjdCBhcHBsZV9tYm94ICphcHBsZV9tYm94ID0g ZGF0YTsKPiA+ID4gKwlzdHJ1Y3QgYXBwbGVfbWJveF9tc2cgbXNnOwo+ID4gPiArCj4gPiA+ICsJ d2hpbGUgKGFwcGxlX21ib3hfaHdfY2FuX3JlY3YoYXBwbGVfbWJveCkpIHsKPiA+ID4gKwkJYXBw bGVfbWJveF9od19yZWN2KGFwcGxlX21ib3gsICZtc2cpOwo+ID4gPiArCQltYm94X2NoYW5fcmVj ZWl2ZWRfZGF0YSgmYXBwbGVfbWJveC0+Y2hhbiwgKHZvaWQgKikmbXNnKTsKPiA+ID4gKwl9Cj4g PiBgYGAKPiA+IAo+ID4gQSBjb21tZW50IGlzIHdhcnJhbnRlZCB3aHkgdGhpcyBsb29wIGlzIHNh ZmUgYW5kIHdpbGwgYWx3YXlzIHRlcm1pbmF0ZSwKPiA+IGVzcGVjaWFsbHkgZ2l2ZW4gdGhpcyBp cyBhbiBJUlEgY29udGV4dC4gKEFoLi4uIGNhbiBhIG1hbGljaW91cwo+ID4gY29wcm9jZXNzb3Ig RG9TIHRoZSBBUCBieSBzZW5kaW5nIG1lc3NhZ2VzIGZhc3RlciB0aGFuIHRoZSBBUCBjYW4KPiA+ IHByb2Nlc3MgdGhlbT8gZnJlZXppbmcgdGhlIHN5c3RlbSBzaW5jZSBwcmVlbXB0aW9uIG1pZ2h0 IGJlIGRpc2FibGVkCj4gPiBoZXJlPyBJIHN1cHBvc2UgdGhlZSdzIG5vIGdvb2Qgd2F5IHRvIHBy b3RlY3QgYWdhaW5zdCB0aGF0IGxldmVsIG9mCj4gPiBnb29meS4pCj4gCj4gVGhlIG9ubHkgd2F5 IHRoaXMgY2FuJ3QgdGVybWluYXRlIGlzIGlmIHRoZSBjby1wcm9jZXNzb3IgdHJpZXMgdG8gc3Rh bGwKPiB1cyB3aXRoIG1lc3NhZ2VzLCBidXQgd2hhdCdzIHlvdXIgdGhyZWF0IG1vZGVsIGhlcmU/ IElmIHRoZSBjby1wcm9jZXNzb3Igd2FudHMKPiB0byBiZSBldmlsIGl0IHVzdWFsbHkgaGFzIG1h bnkgb3RoZXIgd2F5cyB0byBhbm5veSB1cyAoZS5nLiBBTlMgY291bGQganVzdCBkaXNhYmxlCj4g TlZNZSwgU01DIGNvdWxkIGp1c3QgdHJpZ2dlciBhIHNodXRkb3duLCBldGMuKQo+IAo+IEkgY291 bGQgbW92ZSB0aGlzIHRvIHRocmVhZGVkIGludGVycnVwdCBjb250ZXh0IHRob3VnaCB3aGljaCB3 b3VsZCBtYWtlIHRoYXQgYSBiaXQKPiBoYXJkZXIgdG8gcHVsbCBvZmYgYXQgdGhlIGNvc3Qgb2Yg YSBiaXQgbW9yZSBsYXRlbmN5IGZyb20gaW5jb21pbmcgbWVzc2FnZXMuCj4gTm90IHN1cmUgdGhh dCdzIHdvcnRoIGl0IHRob3VnaC4KClByb2JhYmx5IG5vdCB3b3J0aCBpdCwgbm8uCgo+ID4gCj4g PiA+ICsJICogVGhlcmUncyBubyByYWNlIGlmIGEgbWVzc2FnZSBjb21lcyBpbiBiZXR3ZWVuIHRo ZSBjaGVjayBpbiB0aGUgd2hpbGUKPiA+ID4gKwkgKiBsb29wIGFib3ZlIGFuZCB0aGUgYWNrIGJl bG93OiBJZiBhIG5ldyBtZXNzYWdlcyBhcnJpdmVzIGluYmV0d2Vlbgo+ID4gPiArCSAqIHRob3Nl IHR3byB0aGUgaW50ZXJydXB0IHdpbGwganVzdCBmaXJlIGFnYWluIGltbWVkaWF0ZWx5IGFmdGVy IHRoZQo+ID4gPiArCSAqIGFjayBzaW5jZSBpdCdzIGxldmVsIHNlbnNpdGl2ZS4KPiA+IAo+ID4g SSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHRoZSByZWFzb25pbmcuIFdoeSBoYXZlIElSUSBjb250 cm9scyBhdCBhbGwKPiA+IHRoZW4gb24gdGhlIE0zPwo+IAo+IFJlLXJlYWQgdGhlIHR3byBsaW5l cyBqdXN0IGFib3ZlIHRoaXMgb25lLiBJZiB0aGUgaW50ZXJydXB0IGlzIG5vdCBhY2tlZCBoZXJl Cj4gaXQgd2lsbCBrZWVwIGZpcmluZyBldmVuIHdoZW4gdGhlcmUgYXJlIG5vIG5ldyBtZXNzYWdl cy4KPiBCdXQgaXQncyBmaW5lIHRvIGFjayBpdCBldmVuIHdoZW4gdGhlcmUgYXJlIG1lc3NhZ2Ug YXZhaWxhYmxlIHNpbmNlIGl0IHdpbGwKPiBqdXN0IHRyaWdnZXIgYWdhaW4gaW1tZWRpYXRlbHku CgpHb3QgaXQsIHRoYW5rcy4KCj4gPiA+ICsJLyoKPiA+ID4gKwkgKiBPbmx5IHNvbWUgdmFyaWFu dHMgb2YgdGhpcyBtYWlsYm94IEhXIHByb3ZpZGUgaW50ZXJydXB0IGNvbnRyb2wKPiA+ID4gKwkg KiBhdCB0aGUgbWFpbGJveCBsZXZlbC4gV2UgdGhlcmVmb3JlIG5lZWQgdG8gaGFuZGxlIGVuYWJs aW5nL2Rpc2FibGluZwo+ID4gPiArCSAqIGludGVycnVwdHMgYXQgdGhlIG1haW4gaW50ZXJydXB0 IGNvbnRyb2xsZXIgYW55d2F5IGZvciBoYXJkd2FyZSB0aGF0Cj4gPiA+ICsJICogZG9lc24ndC4g SnVzdCBhbHdheXMga2VlcCB0aGUgaW50ZXJydXB0cyB3ZSBjYXJlIGFib3V0IGVuYWJsZWQgYXQK PiA+ID4gKwkgKiB0aGUgbWFpbGJveCBsZXZlbCBzbyB0aGF0IGJvdGggaGFyZHdhcmUgcmV2aXNp b25zIGJlaGF2ZSBhbG1vc3QKPiA+ID4gKwkgKiB0aGUgc2FtZS4KPiA+ID4gKwkgKi8KPiA+IAo+ ID4gQ3V0ZS4gRG9lcyBtYWNPUyBkbyB0aGlzPyBBcmUgdGhlcmUgYW55IHRyYWRlb2Zmcz8KPiAK PiBOb3Qgc3VyZSBpZiBtYWNPUyBkb2VzIGlzIGFuZCBJIGFsc28gZG9uJ3Qgc2VlIGEgcmVhc29u IHRvIGNhcmUgd2hhdCBpdAo+IGRvZXMgZXhhY3RseS4gSSd2ZSB2ZXJpZmllZCB0aGF0IHRoaXMg d29ya3Mgd2l0aCB0aGUgTTMgbWFpbGJveGVzLgo+IEkgYWxzbyBkb24ndCBzZWUgd2h5IHRoZXJl IHdvdWxkIHRoZXJlIGJlIGFueSB0cmFkZW9mZnMuCj4gRG8geW91IGhhdmUgYW55dGhpbmcgc3Bl Y2lmaWMgaW4gbWluZD8KPiAKPiBJIHN1c3BlY3QgdGhpcyBIVyB3YXMgdXNlZCBpbiBwcmV2aW91 cyBTb0NzIHdoZXJlIGFsbCBmb3VyIGludGVycnVwdHMKPiBzaGFyZWQgYSBzaW5nbGUgbGluZSBh bmQgcmVxdWlyZWQgdGhpcyBjaGFpbmVkIGludGVycnVwdCBjb250cm9sbGVyCj4gYXQgdGhlIG1h aWxib3ggbGV2ZWwuIEJ1dCBzaW5jZSB0aGV5IGFyZSBhbGwgc2VwYXJhdGUgb24gdGhlIE0xIGl0 J3MKPiBqdXN0IGEgbnVpc2FuY2Ugd2UgaGF2ZSB0byBkZWFsIHdpdGggLSBlc3BlY2lhbGx5IHNp bmNlIHRoZSBBU0MKPiB2YXJpYW50IGdvdCByaWQgb2YgdGhlIGludGVycnVwdCBjb250cm9scy4K Ck1ha2VzIHNlbnNlIGZvciBhIGxlZ2FjeSBibG9jayDwn5GNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlz dApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 5C6E0C433F5 for ; Tue, 7 Sep 2021 21:06:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 43E3E61090 for ; Tue, 7 Sep 2021 21:06:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346873AbhIGVID (ORCPT ); Tue, 7 Sep 2021 17:08:03 -0400 Received: from rosenzweig.io ([138.197.143.207]:46240 "EHLO rosenzweig.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346428AbhIGVIC (ORCPT ); Tue, 7 Sep 2021 17:08:02 -0400 Date: Tue, 7 Sep 2021 17:06:48 -0400 From: Alyssa Rosenzweig To: Sven Peter Cc: Jassi Brar , Rob Herring , Mark Kettenis , Hector Martin , Mohamed Mediouni , Stan Skowronek , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] mailbox: apple: Add driver for Apple mailboxes Message-ID: References: <20210907145501.69161-1-sven@svenpeter.dev> <20210907145501.69161-4-sven@svenpeter.dev> <39b92560-b236-4abb-9de0-ac3a3fa3a506@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <39b92560-b236-4abb-9de0-ac3a3fa3a506@www.fastmail.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org > > > + * Both the main CPU and the co-processor see the same set of registers but > > > + * the first FIFO (A2I) is always used to transfer messages from the application > > > + * processor (us) to the I/O processor and the second one (I2A) for the > > > + * other direction. > > > > Do we actually know what the copro sees? It seems obvious, but *know*? > > Yes, I know. They see the exact same set of registers. I wouldn't have written > it like that otherwise. Ack. > > > +struct apple_mbox { > > > + void __iomem *regs; > > > + const struct apple_mbox_hw *hw; > > > + ... > > > +}; > > > > This requires a lot of pointer chasing to send/receive messages. Will > > this become a perf issue in any case? It'd be good to get ballparks on > > how often these mboxes are used. (For DCP, it doesn't matter, only a few > > hundred messages per second. Other copros may have different behaviour) > > If this actually becomes a problem I'm happy to fix it but right now > this feels like premature optimization to me. DCP is going to be the > worst offender followed by SMC (at most a few per second when it's really > busy during boot time) and SEP (I've also never seen more than a few per > second here). The rest of them are mostly quiet after they have booted. Good enough for me -- it won't matter for DCP, so if it doesn't get any worse than DCP there's no point in optimizing this. > > > +static bool apple_mbox_hw_can_send(struct apple_mbox *apple_mbox) > > > +{ > > > + u32 mbox_ctrl = > > > + readl_relaxed(apple_mbox->regs + apple_mbox->hw->a2i_control); > > > + > > > + return !(mbox_ctrl & apple_mbox->hw->control_full); > > > +} > > > > If you do the pointer chasing, I suspect you want accessor > > functions/macros at least to make it less intrusive... > > There's regmap but that can't easily be used here because I need 32bit > and 64bit writes. I also don't really see the advantage of replacing > this with some custom functions like e.g. > > mbox_ctrl = apple_mbox_hw_readl(apple_mbox, apple_mbox->hw->a2i_control); > > which is almost as long. And if I introduce a separate function just to read the > control reg this just becomes a lot of boilerplate and harder to follow. > > Or did you have anything else in mind? I was envisioning a macro: > #define apple_mbox_readl(mbox, name) \ > readl_relaxed(mbox->regs + mbox->hw-> ## name) > > mbox_ctrl = apple_mbox_readl(apple_mbox, a2i_control); Now that I've typed it out, however, it seems a bit too magical to justify the minor space savings. And given you need both 32b and 64b there would be ~4 such macros which is also a lot of boilerplate. It's not a huge deal either way but I thought I'd raise it. > > > + dev_dbg(apple_mbox->dev, "> TX %016llx %08x\n", msg->msg0, msg->msg1); > > > > Isn't "TX" redundant here? > > Sure, but it also doesn't hurt in a debug message. I can spot the TX easier > but I'm sure there are people who prefer >. Fair enough. > > > + dev_dbg(apple_mbox->dev, "got FIFO empty IRQ\n"); > > > > I realize it's a dev_dbg but this still seems unnecessarily noisy. > > This code path is almost never reached. I've only been able to trigger > it by forcing send_message to return EBUSY even when it could still > move messages to the FIFO to test this path. > This also can't be triggered more often than the TX debug message. > If this triggers more often there's a bug somewhere that kept the interrupt > enabled and then the whole machine will hang due an interrupt storm anyway. In > that case I'd prefer to have this as noisy as possible. Ah! Sure, makes sense. Is it worth adding a few words to the functions comments indicating this rarely occurs in good conditions? > > > +static irqreturn_t apple_mbox_recv_irq(int irq, void *data) > > > +{ > > > + struct apple_mbox *apple_mbox = data; > > > + struct apple_mbox_msg msg; > > > + > > > + while (apple_mbox_hw_can_recv(apple_mbox)) { > > > + apple_mbox_hw_recv(apple_mbox, &msg); > > > + mbox_chan_received_data(&apple_mbox->chan, (void *)&msg); > > > + } > > ``` > > > > A comment is warranted why this loop is safe and will always terminate, > > especially given this is an IRQ context. (Ah... can a malicious > > coprocessor DoS the AP by sending messages faster than the AP can > > process them? freezing the system since preemption might be disabled > > here? I suppose thee's no good way to protect against that level of > > goofy.) > > The only way this can't terminate is if the co-processor tries to stall > us with messages, but what's your threat model here? If the co-processor wants > to be evil it usually has many other ways to annoy us (e.g. ANS could just disable > NVMe, SMC could just trigger a shutdown, etc.) > > I could move this to threaded interrupt context though which would make that a bit > harder to pull off at the cost of a bit more latency from incoming messages. > Not sure that's worth it though. Probably not worth it, no. > > > > > + * There's no race if a message comes in between the check in the while > > > + * loop above and the ack below: If a new messages arrives inbetween > > > + * those two the interrupt will just fire again immediately after the > > > + * ack since it's level sensitive. > > > > I don't quite understand the reasoning. Why have IRQ controls at all > > then on the M3? > > Re-read the two lines just above this one. If the interrupt is not acked here > it will keep firing even when there are no new messages. > But it's fine to ack it even when there are message available since it will > just trigger again immediately. Got it, thanks. > > > + /* > > > + * Only some variants of this mailbox HW provide interrupt control > > > + * at the mailbox level. We therefore need to handle enabling/disabling > > > + * interrupts at the main interrupt controller anyway for hardware that > > > + * doesn't. Just always keep the interrupts we care about enabled at > > > + * the mailbox level so that both hardware revisions behave almost > > > + * the same. > > > + */ > > > > Cute. Does macOS do this? Are there any tradeoffs? > > Not sure if macOS does is and I also don't see a reason to care what it > does exactly. I've verified that this works with the M3 mailboxes. > I also don't see why there would there be any tradeoffs. > Do you have anything specific in mind? > > I suspect this HW was used in previous SoCs where all four interrupts > shared a single line and required this chained interrupt controller > at the mailbox level. But since they are all separate on the M1 it's > just a nuisance we have to deal with - especially since the ASC > variant got rid of the interrupt controls. Makes sense for a legacy block 👍