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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 94BEAC43602 for ; Mon, 6 Jul 2026 14:42:33 +0000 (UTC) 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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QYAMjn0x/ylNh3NWi/g2kz1+RQ5VfLxIvlEZoOvow08=; b=181AKErN+N/z71 ouzphh1FcM3c5tmiAt25VXjS7U0wIL5cJHx0CrvWEZ4keWZd6iuckcTRlzqVaSVkmBaFSSDsmpUf+ fcPEpZznLkNQGH63OKLsKi1HsG1l96uUBTdg3Jg3SUMFwc2yIN2B9FKmgIfJWW9Llza6qpjSXVo9o paAtjTRyh/G9FGBvYcIEbfs23aFumXcIQx/BBN0mFoBYLizSEuAgpQxtAxObhBlH77llH4QtAWiEq smvWBH2Gz6zqEfO24FWnNhhBJkF3a+FwPzxEiYD6AyHEh/vZTtcFhFFzypDv7ilRumiwOQFbOo9Aw I3y9iTuLQgLfWcWWQeVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgkWl-0000000Cmd8-3Z4Y; Mon, 06 Jul 2026 14:42:31 +0000 Received: from smtpout-03.galae.net ([185.246.85.4]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgkWi-0000000Cmci-26t4 for linux-mtd@lists.infradead.org; Mon, 06 Jul 2026 14:42:30 +0000 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id BF9574E40CB4; Mon, 6 Jul 2026 14:42:25 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 91FDE601A2; Mon, 6 Jul 2026 14:42:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9AD0B11BBA42D; Mon, 6 Jul 2026 16:42:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1783348944; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=9S6JUkNd7tEQQ570HblFbe1x5CYX/+kx5Sg029EJZYI=; b=mmAwpS/o6e/t/IuGRCLGVMC0hpbEhsm/aB1rAJrSfy85oGyILbzuFfbnS3x56EKHJkM7VH RPvUAyYjsjn9kdm/Ore5gKqIK4AnIYMYLN+xvGsP+NHuqhhsDqH4ox8ud8dsYuXmF25gMB DK4IZq8jroh3tyz1Fe+ix+PTG04853qpCetpk3el7lcfZWStSpfmY+vbgfmJQcbewqInnW yTDbLqh+f266pScqhWEO4zqW18gqZbhFtmkIKNcS/Se5pd0Xd6ZBDrMeF6ZmAGrN7QAhYP 9Fxrq5ySIp7af3c8HjFaUSa57otHb8IkXL8TDecMalOHJnGDUzDPvfi+ZyoOeg== From: Miquel Raynal To: Manivannan Sadhasivam Cc: Stephan Gerhold , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] mtd: rawnand: qcom: Add MDM9607 In-Reply-To: (Manivannan Sadhasivam's message of "Mon, 6 Jul 2026 16:19:04 +0200") References: <20260608-qcom-nandc-mdm9607-v1-0-4639a0492274@linaro.org> <4kdjxrn3bxg7rhkdovidxv2b2f6evnknng7gjtbz7pahyqaakh@qkgxaz6xlav2> <875x2smf39.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Mon, 06 Jul 2026 16:42:21 +0200 Message-ID: <87y0foji2a.fsf@bootlin.com> MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260706_074228_839718_6EBAEF8F X-CRM114-Status: GOOD ( 44.30 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org T24gMDYvMDcvMjAyNiBhdCAxNjoxOTowNCArMDIsIE1hbml2YW5uYW4gU2FkaGFzaXZhbSA8bWFu aUBrZXJuZWwub3JnPiB3cm90ZToKCj4gT24gTW9uLCBKdWwgMDYsIDIwMjYgYXQgMDM6MjY6MThQ TSArMDIwMCwgU3RlcGhhbiBHZXJob2xkIHdyb3RlOgo+PiBPbiBNb24sIEp1bCAwNiwgMjAyNiBh dCAwMzoxODoxOFBNICswMjAwLCBNaXF1ZWwgUmF5bmFsIHdyb3RlOgo+PiA+IE9uIDA2LzA3LzIw MjYgYXQgMTQ6NTU6MjYgKzAyLCBTdGVwaGFuIEdlcmhvbGQgPHN0ZXBoYW4uZ2VyaG9sZEBsaW5h cm8ub3JnPiB3cm90ZToKPj4gPiA+IE9uIE1vbiwgSnVuIDI5LCAyMDI2IGF0IDA1OjQ2OjU3UE0g KzAyMDAsIE1hbml2YW5uYW4gU2FkaGFzaXZhbSB3cm90ZToKPj4gPiA+PiBPbiBNb24sIEp1biAw OCwgMjAyNiBhdCAwMzoyMDoyMVBNICswMjAwLCBTdGVwaGFuIEdlcmhvbGQgd3JvdGU6Cj4+ID4g Pj4gPiBNRE05NjA3IGhhcyBRUElDIHYxLjUgdGhhdCBzdXBwb3J0cyB0aGUgT1BfUEFHRV9SRUFE X09ORklfUkVBRCBjb21tYW5kLCBidXQKPj4gPiA+PiA+IGlzIG1pc3NpbmcgdGhlIHJlc3Qgb2Yg dGhlIGhhcmR3YXJlIGNoYW5nZXMgaW4gUVBJQyB2Mi4gVGhlcmUgaXMgYWxzbyBvbmx5Cj4+ID4g Pj4gPiBhIHNpbmdsZSBjbG9jayB0aGF0IGNhbiBiZSBjb250cm9sbGVkIHVzaW5nIHRoZSBSUE0g ZmlybXdhcmUuIERvY3VtZW50IGFuZAo+PiA+ID4+ID4gYWRkIHRoZSBuZXcgcWNvbSxtZG05NjA3 LW5hbmQgY29tcGF0aWJsZSBmb3IgdGhpcyBzZXR1cC4KPj4gPiA+PiA+IAo+PiA+ID4+ID4gU2ln bmVkLW9mZi1ieTogU3RlcGhhbiBHZXJob2xkIDxzdGVwaGFuLmdlcmhvbGRAbGluYXJvLm9yZz4K Pj4gPiA+PiAKPj4gPiA+PiBZb3UgY291bGQgYW1tZW5kIHBhdGNoIDEncyBjb21taXQgbWVzc2Fn ZSB3aXRoIHRoZSBpbmZvcm1hdGlvbiBJIHNoYXJlZCBpbiB0aGUKPj4gPiA+PiByZXBseS4gQnV0 IG5ldmVydGhlbGVzczoKPj4gPiA+PiAKPj4gPiA+PiBSZXZpZXdlZC1ieTogTWFuaXZhbm5hbiBT YWRoYXNpdmFtIDxtYW5pQGtlcm5lbC5vcmc+Cj4+ID4gPj4gCj4+ID4gPgo+PiA+ID4gRG8geW91 IHdhbnQgbWUgdG8gcmVzZW5kIHRoZSBzZXJpZXMgd2l0aCBwYXRjaCAxIGNvbW1pdCBtZXNzYWdl Cj4+ID4gPiBhZGp1c3RlZD8gVGhlcmUgd2VyZSBubyBvdGhlciBjaGFuZ2VzIHJlcXVlc3RlZCBh cyBmYXIgYXMgSSBjYW4gdGVsbC4KPj4gPiAKPj4gPiBJIHdhcyBtb3N0bHkgd2FpdGluZyBmb3Ig YW5zd2VycyBvbiBteSBxdWVzdGlvbnMgZnJvbSB0aGUgRFQgYmluZGluZwo+PiA+IG1haW50YWlu ZXJzLCBidXQgSSB1bmRlcnN0YW5kIHRoZXkgbXVzdCBiZSB0b28gbG9hZGVkIGF0IHRoZSBtb21l bnQuCj4+ID4gCj4+ID4gPiBJIHRoaW5rIHRoZSBjdXJyZW50IGNvbW1pdCBtZXNzYWdlIHRoZXJl IGlzIGZpbmUsIGVzcGVjaWFsbHkgaWYgeW91IGFkZAo+PiA+ID4gdGhlIExpbms6IHRhZyBkdXJp bmcgYXBwbHlpbmcuIFRoZSBleHRyYSBjb250ZXh0IHdpbGwgYmUgdGhlcmUuCj4+ID4gPgo+PiA+ ID4gSWYgeW91IHdhbnQgbWUgdG8gcmVzZW5kLCBJIHdvdWxkIGp1c3QgcmVwbGFjZSB0aGUgc2Vj b25kIHBhcmFncmFwaCBpbgo+PiA+ID4gcGF0Y2ggMSB3aXRoIHRoZSBmb2xsb3dpbmc6Cj4+ID4g Pgo+PiA+ID4gLS0tCj4+ID4gPiBPbiBNRE05NjA3IGFuZCBvdGhlciByZWNlbnQgU29DcywgdGhl IFFQSUMgaGFyZHdhcmUgcmVxdWlyZXMgMyBjbG9ja3MKPj4gPiA+IChhaGIsIGNvcmUsIGFvbiku IEhvd2V2ZXIsIHRoZSBhY2Nlc3MgdG8gdGhlc2UgY2xvY2tzIGlzIHJlc3RyaWN0ZWQgdG8KPj4g PiA+IHRoZSBSUE0gZmlybXdhcmUgdGhhdCBjb250cm9scyB0aGUgc2hhcmVkIHBvd2VyIHJlc291 cmNlcyBmb3IgdGhlIHdob2xlCj4+ID4gPiBTb0MuIFRoZSBjbG9ja3MgY2Fubm90IGJlIGNvbnRy b2xsZWQgc2VwYXJhdGVseSwgdGhlcmUgaXMgb25seSBhIHNpbmdsZQo+PiA+ID4gUlBNX1NNRF9R UElDX0NMSyBjbG9jayB0aGF0IGltcGxpY2l0bHkgZW5hYmxlcyBhbGwgb2YgdGhlIDMgY2xvY2tz Lgo+PiA+ID4gVGhlIG9ubHkgZXhjZXB0aW9uIHRvIHRoaXMgYXJlIHNvbWUgSVBRKiBTb0MgdGhh dCBhcmUgbm90IHVzaW5nIFJQTSwKPj4gPiA+IHRoZXJlIHRoZSBjbG9ja3MgYXJlIGRpcmVjdGx5 IGNvbnRyb2xsZWQgYnkgdGhlIGtlcm5lbCB2aWEgdGhlIGNsb2NrCj4+ID4gPiBjb250cm9sbGVy IChHQ0MpLiBSZXF1aXJlIG9ubHkgb25lIGNsb2NrIGluIHRoZSBkdC1iaW5kaW5ncyBmb3IgTURN OTYwNwo+PiA+ID4gdG8gYXZvaWQgaGF2aW5nIHRvIGRlZmluZSBkdW1teSBjbG9jayBlbnRyaWVz Lgo+PiA+IAo+PiA+IEkgYW0gc29ycnkgYnV0IHRoaXMgaXMgc3RpbGwgaW5jb3JyZWN0LiBZb3Ug ZG9uJ3QgaGF2ZSB0byBkZWZpbmUgMiBkdW1teQo+PiA+IGNsb2Nrcy4gWW91IHdvdWxkIGhhdmUg dG8gZGVmaW5lIDMgdGltZXMgdGhlIHNhbWUgY2xvY2sgKGFuZCB0aGF0J3Mgbm90Cj4+ID4gYSBw cm9ibGVtKS4gSSBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGUgY29uY2VwdCBvZiBjbG9jayBuZXh1 cyB3aGljaAo+PiA+IG1heSBzb2x2ZSB0aGlzIGtpbmQgb2YgaXNzdWUgaW4gYSByYXRoZXIgZWxl Z2FudCB3YXkgYnV0IHRoYXQncyBub3QKPj4gPiByZWFkeSB5ZXQuCj4+ID4gCj4+ID4gSW4gbXkg b3BpbmlvbiB0aGUgYmluZGluZyB0aGF0IHlvdSB3YW50IHRvIHB1c2ggKGEgc2luZ2xlIGNsb2Nr KSBpcwo+PiA+IHdyb25nLCBidXQgc2luY2UgSSd2ZSBiZWVuIGV4cGxhaW5pbmcgdGhpcyBmb3Ig c2V2ZXJhbCB3ZWVrcyBhbHJlYWR5LAo+PiA+IHBsZWFzZSBhdCBsZWFzdCBmaXggdGhlIGNvbW1p dCBtZXNzYWdlIGFuZCBJIHdpbGwgdGFrZSBpdCBhcyB5b3Ugd2FudC4KPj4gPiAKPj4gCj4+IFRo YW5rcyBmb3IgeW91ciBmZWVkYmFjayEKPj4gCj4+IEVpdGhlciB3YXkgd29ya3MgZm9yIG1lIHBl cnNvbmFsbHksIGJ1dCBub3cgd2UgaGF2ZSBhIGNvbmZsaWN0IGJldHdlZW4KPj4geW91ciByZXF1 ZXN0ZWQgY2hhbmdlcyBhbmQgdGhlIGZlZWRiYWNrIGZyb20gTWFuaSwgd2hvIG1haW50YWlucyB0 aGlzCj4+IGRyaXZlci4gOi0pCj4+IAo+PiBATWFuaTogV291bGQgeW91IGFsc28gYmUgZmluZSB3 aXRoIGRlZmluaW5nIGFsbCAzIGNsb2NrcyBpbiB0aGUgRFQKPj4gKCJhaGIiLCAiY29yZSIsICJh b24iKSBhbmQgdGhlbiBhc3NpZ25pbmcgdGhlIFJQTV9TTURfUVBJQ19DTEsgdG8gYWxsIG9mCj4+ IHRoZW0/Cj4+IAo+Cj4gQUZBSVUsIGRldmljZXRyZWUgYmluZGluZyBzaG91bGQgZGVzY3JpYmUg dGhlICJPUyB2aWV3IG9mIHRoZQo+IGhhcmR3YXJlIiwgbm90IHRoZQoKTGlrZSBHZWVydCBwb2lu dGVkIG91dCBpbiB0aGUgYmVsb3cgdGhyZWFkLCBJIGFtIGVxdWFsbHkgc3VycHJpc2VkIGJ5CnRo aXMgc2hpZnQgYnV0IEkgZ3Vlc3MgU29DIGNvbXBsZXhpdHkgcmVxdWlyZXMgYWRhcHRhdGlvbnMu Cgo+IGhhcmR3YXJlIGl0c2VsZi4gV2UgaGF2ZSBtYW55IHByZWRlY2VudHMgdG8gdGhpcyBydWxl LiBPbmUgb2YgdGhlbSBpcyB0aGUgU0NNSQo+IGJhc2VkIHJlc291cmNlIGNvbnRyb2wgaW4gUWNv bSBBdXRvbW90aXZlIFNvQ3MsIHdoZXJlIGNsb2Nrcy9yZWd1bGF0b3JzIHRvCj4gaW5kaXZpZHVh bCBJUHMgYXJlIGNvbnRyb2xsZWQgYnkgdGhlIFNDTUkgc2VydmVyIGFuZCBPUyBqdXN0IHNlZXMg YSBzaW5nbGUgU0NNSQo+IHBvd2VyLWRvbWFpbiBmb3IgdGhlIElQLiBTbyB3ZSBvbmx5IGRlc2Ny aWJlIHRoZSBTQ01JIHBvd2VyLWRvbWFpbiBpbiB0aGUKPiBiaW5kaW5nIGFuZCBub3QgdGhlIHBo eXNpY2FsIGNsb2Nrcy9yZWd1bGF0b3JzIHJlY2VpdmVkIGJ5IHRoZSBJUCBpbiBoYXJkd2FyZS4K Pgo+IFdlIGhhZCBhIHJlY2VudCBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgc2FtZSB0b3BpYyBhbmQg eW91IGNhbiBzZWUgdGhlIHJlcGx5IGZyb20KPiBLcnprIGhlcmU6IGh0dHBzOi8vbG9yZS5rZXJu ZWwub3JnL2FsbC9jODNjYTQ4NS0xZTJlLTQ2YmEtYmQxNS0xMTY4YWE4OTU1ZDNAa2VybmVsLm9y Zwo+Cj4gU28gaGVyZSBhbHNvLCB0aGUgaGFyZHdhcmUgcmVjZWl2ZXMgMyBjbG9ja3MgcGh5c2lj YWxseSwgYnV0IE9TIGNhbm5vdCBjb250cm9sCj4gYWxsIDMgb2YgdGhlbSwgYnV0IGp1c3QgYSBz aW5nbGUgY2xvY2sgZnJvbSBSUE1oIHdoaWNoIGNvbnRyb2xzIHRoZSAzIHJlYWwKPiBjbG9ja3Mu IE1vcmVvdmVyLCBhc3NpZ25pbmcgdGhlIHNhbWUgY2xvY2sgdG8gMyBkaWZmZXJlbnQgY2xvY2sg c291cmNlcyBkb2Vzbid0Cj4gYWNjdXJhdGVseSBkZXNjcmliZSB0aGUgaGFyZHdhcmUgZWl0aGVy LCBiZWNhdXNlIHRob3NlIDMgY2xvY2tzIG9wZXJhdGUgb24KPiBkaWZmZXJlbnQgZnJlcXVlbmNp ZXMKCkFoLCB0aGlzIGlzIGEgcG9pbnQgdGhhdCB3YXMgbWlzc2luZyB0byBteSB1bmRlcnN0YW5k aW5nLiBZb3UgYWN0dWFsbHkKaGF2ZSB0aHJlZSAqZGlmZmVyZW50KiBjbG9ja3MsIGFuZCB5b3Ug Y29udHJvbCBhbGwgb2YgdGhlbSB0aHJvdWdoIHNvbWUKa2luZCBvZiBmaXJtd2FyZSBwcm94eSBj YWxsZWQgUlBNaCB3aXRoIGEgc2luZ2xlIGhhbmRsZS4gU28gYmFzaWNhbGx5CnRoZSBrZXJuZWwg anVzdCBlbmFibGVzIG9uZSBjbG9jayBhbmQgdGhlIGZpcm13YXJlIGVuYWJsZXMvY29uZmlndXJl cwp0d28gb3RoZXIgY2xvY2tzIGRpZmZlcmVudGx5IGF1dG9tYXRpY2FsbHkuIElzIHRoYXQgaXQ/ IEZlZWxzIGxpa2UgeW91CmFsbW9zdCBuZWVkIGEgcG93ZXIgZG9tYWluIGhlcmUuCgo+IGFuZCBp ZiB0aGUgZHJpdmVyIHF1ZXJpZXMgdGhlIGZyZXF1ZW5jeSBvZgo+IFJQTV9TTURfUVBJQ19DTEss IGl0IHdvdWxkIGp1c3QgcmV0dXJuIHRoZSBzYW1lIGZyZXF1ZW5jeS4gVGhpcyBpcyB3aGVyZSB0 aGUKPiBkdW1teSBjbG9jayBjb21lcyBoYW5keSBhcyBpdCBhdGxlYXN0IHByb3ZpZGVzIGEgdmFs aWQgY2xvY2sgZnJlcXVlbmN5IHRvIHRoZQo+IGRyaXZlci4gQnV0IEknbSBub3QgYWR2b2NhdGlu ZyBmb3IgaXRzIHVzYWdlIGhlcmUgYW55bW9yZS4KPgo+IEhlbmNlIElNTywgYXNzaWduaW5nIHRo ZSBzYW1lIFJQTV9TTURfUVBJQ19DTEsgdG8gYWxsIDMgY2xvY2tzIGlzIG5vdCB0aGUgcmlnaHQK PiBhcHByb2FjaCBhbmQgd2Ugc2hvdWxkIGJlIGFzc2lnbmluZyBhIHNpbmdsZSBSUE1fU01EX1FQ SUNfQ0xLIHRvCj4gJ2NvcmUnIGNsay4KCllvdSBzYWlkIHVzaW5nIHRocmVlIHRpbWVzIHRoZSBz YW1lIGNsb2NrIHdvdWxkIGJlIHdyb25nIGJlY2F1c2Ugd2UKd291bGQgZ2V0IHRocmVlIHRpbWVz IHRoZSBzYW1lIHJhdGUgd2hlcmVhcyBpbiBwcmFjdGljZSBpdCdzIHdyb25nLiBUaGlzCm1lYW5z IHRoZSBPUyBoYXMgYWNjZXNzIHRvIHRoZXNlIGNsb2NrcyBzb21laG93LCBzbyBpZiB3ZSBuZWVk IHRvCmRlc2NyaWJlIHdoYXQgdGhlIE9TIHNlZXMgb2YgdGhlIGhhcmR3YXJlLCBhcyB5b3Ugc2F5 LCBkZWZpbmluZyBhIHNpbmdsZQpjbG9jayBpcyBpbmNvbXBsZXRlLgoKQWdhaW4sIEkgYW0gbm90 IHRvdGFsbHkgb3Bwb3NlZCB0byB0aGUgc2luZ2xlIGNsb2NrIGlkZWEgaWYgeW91IGFsbCBmZWVs Cmxpa2UgdGhpcyBpcyB0aGUgd2F5IGZvcndhcmQuIFlldCwgaXQgc291bmRzIGEgYml0IGhhY2tp c2guCgo+IEBrcnprOiBDYW4geW91IHNoYXJlIHlvdXIgb3Bpbmlvbj8KClRoYW5rcywKTWlxdcOo bAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcgbGlzdApodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10ZC8K From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4168740A953; Mon, 6 Jul 2026 14:42:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783348949; cv=none; b=RwRxnfLxkDQFjpPq1mGcxzzoR9HRuWK2BHBiRJyvp4wtEVM9fGHU7QwjNHPUeR60fRqMmesICIUHSVWEHbJUlCUFWpXtMS5m3JZSirjUl0Qbc+dKA/e8Z3NnnZXJI6JPcp2Y7W/S7gv1NfusZGR3k44KmjuThq/2RRctbNVVfAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783348949; c=relaxed/simple; bh=9S6JUkNd7tEQQ570HblFbe1x5CYX/+kx5Sg029EJZYI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lW0ASLK49yl8hbZqGYPg02fnR2Pz6buhhT6oCSiE9ThyAJpqMxyBMvE9rvhQBPoI4m2w6HXCuMrkYKDFLwX+1KeQ8Bz2fhlYxeNHva7rjPRjZQTrZM6A91n6f+dRV1/q8ARt3j0wJe+JNYYqmYWNbT9ng2btfVKYjDjIqQ2Sr/4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=mmAwpS/o; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="mmAwpS/o" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id BF9574E40CB4; Mon, 6 Jul 2026 14:42:25 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 91FDE601A2; Mon, 6 Jul 2026 14:42:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9AD0B11BBA42D; Mon, 6 Jul 2026 16:42:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1783348944; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=9S6JUkNd7tEQQ570HblFbe1x5CYX/+kx5Sg029EJZYI=; b=mmAwpS/o6e/t/IuGRCLGVMC0hpbEhsm/aB1rAJrSfy85oGyILbzuFfbnS3x56EKHJkM7VH RPvUAyYjsjn9kdm/Ore5gKqIK4AnIYMYLN+xvGsP+NHuqhhsDqH4ox8ud8dsYuXmF25gMB DK4IZq8jroh3tyz1Fe+ix+PTG04853qpCetpk3el7lcfZWStSpfmY+vbgfmJQcbewqInnW yTDbLqh+f266pScqhWEO4zqW18gqZbhFtmkIKNcS/Se5pd0Xd6ZBDrMeF6ZmAGrN7QAhYP 9Fxrq5ySIp7af3c8HjFaUSa57otHb8IkXL8TDecMalOHJnGDUzDPvfi+ZyoOeg== From: Miquel Raynal To: Manivannan Sadhasivam Cc: Stephan Gerhold , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] mtd: rawnand: qcom: Add MDM9607 In-Reply-To: (Manivannan Sadhasivam's message of "Mon, 6 Jul 2026 16:19:04 +0200") References: <20260608-qcom-nandc-mdm9607-v1-0-4639a0492274@linaro.org> <4kdjxrn3bxg7rhkdovidxv2b2f6evnknng7gjtbz7pahyqaakh@qkgxaz6xlav2> <875x2smf39.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Mon, 06 Jul 2026 16:42:21 +0200 Message-ID: <87y0foji2a.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 On 06/07/2026 at 16:19:04 +02, Manivannan Sadhasivam wrot= e: > On Mon, Jul 06, 2026 at 03:26:18PM +0200, Stephan Gerhold wrote: >> On Mon, Jul 06, 2026 at 03:18:18PM +0200, Miquel Raynal wrote: >> > On 06/07/2026 at 14:55:26 +02, Stephan Gerhold wrote: >> > > On Mon, Jun 29, 2026 at 05:46:57PM +0200, Manivannan Sadhasivam wrot= e: >> > >> On Mon, Jun 08, 2026 at 03:20:21PM +0200, Stephan Gerhold wrote: >> > >> > MDM9607 has QPIC v1.5 that supports the OP_PAGE_READ_ONFI_READ co= mmand, but >> > >> > is missing the rest of the hardware changes in QPIC v2. There is = also only >> > >> > a single clock that can be controlled using the RPM firmware. Doc= ument and >> > >> > add the new qcom,mdm9607-nand compatible for this setup. >> > >> >=20 >> > >> > Signed-off-by: Stephan Gerhold >> > >>=20 >> > >> You could ammend patch 1's commit message with the information I sh= ared in the >> > >> reply. But nevertheless: >> > >>=20 >> > >> Reviewed-by: Manivannan Sadhasivam >> > >>=20 >> > > >> > > Do you want me to resend the series with patch 1 commit message >> > > adjusted? There were no other changes requested as far as I can tell. >> >=20 >> > I was mostly waiting for answers on my questions from the DT binding >> > maintainers, but I understand they must be too loaded at the moment. >> >=20 >> > > I think the current commit message there is fine, especially if you = add >> > > the Link: tag during applying. The extra context will be there. >> > > >> > > If you want me to resend, I would just replace the second paragraph = in >> > > patch 1 with the following: >> > > >> > > --- >> > > On MDM9607 and other recent SoCs, the QPIC hardware requires 3 clocks >> > > (ahb, core, aon). However, the access to these clocks is restricted = to >> > > the RPM firmware that controls the shared power resources for the wh= ole >> > > SoC. The clocks cannot be controlled separately, there is only a sin= gle >> > > RPM_SMD_QPIC_CLK clock that implicitly enables all of the 3 clocks. >> > > The only exception to this are some IPQ* SoC that are not using RPM, >> > > there the clocks are directly controlled by the kernel via the clock >> > > controller (GCC). Require only one clock in the dt-bindings for MDM9= 607 >> > > to avoid having to define dummy clock entries. >> >=20 >> > I am sorry but this is still incorrect. You don't have to define 2 dum= my >> > clocks. You would have to define 3 times the same clock (and that's not >> > a problem). I have been working on the concept of clock nexus which >> > may solve this kind of issue in a rather elegant way but that's not >> > ready yet. >> >=20 >> > In my opinion the binding that you want to push (a single clock) is >> > wrong, but since I've been explaining this for several weeks already, >> > please at least fix the commit message and I will take it as you want. >> >=20 >>=20 >> Thanks for your feedback! >>=20 >> Either way works for me personally, but now we have a conflict between >> your requested changes and the feedback from Mani, who maintains this >> driver. :-) >>=20 >> @Mani: Would you also be fine with defining all 3 clocks in the DT >> ("ahb", "core", "aon") and then assigning the RPM_SMD_QPIC_CLK to all of >> them? >>=20 > > AFAIU, devicetree binding should describe the "OS view of the > hardware", not the Like Geert pointed out in the below thread, I am equally surprised by this shift but I guess SoC complexity requires adaptations. > hardware itself. We have many predecents to this rule. One of them is the= SCMI > based resource control in Qcom Automotive SoCs, where clocks/regulators to > individual IPs are controlled by the SCMI server and OS just sees a singl= e SCMI > power-domain for the IP. So we only describe the SCMI power-domain in the > binding and not the physical clocks/regulators received by the IP in hard= ware. > > We had a recent discussion around the same topic and you can see the repl= y from > Krzk here: https://lore.kernel.org/all/c83ca485-1e2e-46ba-bd15-1168aa8955= d3@kernel.org > > So here also, the hardware receives 3 clocks physically, but OS cannot co= ntrol > all 3 of them, but just a single clock from RPMh which controls the 3 real > clocks. Moreover, assigning the same clock to 3 different clock sources d= oesn't > accurately describe the hardware either, because those 3 clocks operate on > different frequencies Ah, this is a point that was missing to my understanding. You actually have three *different* clocks, and you control all of them through some kind of firmware proxy called RPMh with a single handle. So basically the kernel just enables one clock and the firmware enables/configures two other clocks differently automatically. Is that it? Feels like you almost need a power domain here. > and if the driver queries the frequency of > RPM_SMD_QPIC_CLK, it would just return the same frequency. This is where = the > dummy clock comes handy as it atleast provides a valid clock frequency to= the > driver. But I'm not advocating for its usage here anymore. > > Hence IMO, assigning the same RPM_SMD_QPIC_CLK to all 3 clocks is not the= right > approach and we should be assigning a single RPM_SMD_QPIC_CLK to > 'core' clk. You said using three times the same clock would be wrong because we would get three times the same rate whereas in practice it's wrong. This means the OS has access to these clocks somehow, so if we need to describe what the OS sees of the hardware, as you say, defining a single clock is incomplete. Again, I am not totally opposed to the single clock idea if you all feel like this is the way forward. Yet, it sounds a bit hackish. > @krzk: Can you share your opinion? Thanks, Miqu=C3=A8l