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 5C16DE92FF1 for ; Fri, 6 Oct 2023 07:43:14 +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:References:In-Reply-To: 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=EbnbjfBbqGFKV7fjVNzwXypoM1tkWOgciHPxn8GT7Ok=; b=VvWACpp3p1t/N3 prCSNSC1m60xJMteR0xBJwAP2j35gO/CDe/f+SaFhnQPM5BkWmhvG0vP9FiqBt10rybeExr+oNyI3 L8mzXL9SYNP/SGCeYqCWAu/JG6wqnjamXDRRdx598KBD3+p0g1b3kD5U9rdKL/Yz1fS802kmBnHTC Fgoz7UvyRbL7fywuQn7HthFRrgfKT+N/n1pHQJ9j4W2cLPHqXVbaugGxZwESmI1JyWlhbqrP3PoJb rGKygiGm2j0ab7hPz2kdS3TN6HGUXXv8GDfp0eDwf3Hzi39ROmObZSHc9idgeLnm3CJIDo/LRMAb4 bYqQSzHAoLRCXuEeSFHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qofUB-005CBS-2L; Fri, 06 Oct 2023 07:42:59 +0000 Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qofU7-005CAv-1i for linux-mtd@lists.infradead.org; Fri, 06 Oct 2023 07:42:58 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3A4A91C0008; Fri, 6 Oct 2023 07:42:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1696578170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KQFwrUeYJEDlw/TSLgMcUD55L/pInUxyhSLEs5AXqms=; b=VJLR3AQC9+1xKQjLSwdQ3raBHu845I2YoP2u6Ky5XHpnYjv9gz2yDZOTA2zeNg2Ha+mlSy nn9CdZ7cU8OXPxk9ga5Iw8dH+anBW82dAHFHiS9fCWJ5dUe0zFXn6DMCNN4s/H1loT+RKo vk1rOFzpcUJ9X6AC+JxF7TvGKfAl5RIpvgdf5bIXvkqj5U7fcWz0CvutHgQp9ZLzzUb9ad 0+ZmBBpPlUS4W+xepzpoDXTcUk7oCg4hoif52eV7dDNo01pkzoA6a1dqU2Fk1US/dvykxX SY2xAMQbak5GwswsSADneVcE8RN3bSNS5o4tvsYSxMB7DCnbBm7sM5XAcuI+ng== Date: Fri, 6 Oct 2023 09:42:45 +0200 From: Miquel Raynal To: William Zhang Cc: dregan@mail.com, bcm-kernel-feedback-list@broadcom.com, linux-mtd@lists.infradead.org, f.fainelli@gmail.com, rafal@milecki.pl, joel.peshkin@broadcom.com, computersforpeace@gmail.com, dan.beygelman@broadcom.com, frieder.schrempf@kontron.de, linux-kernel@vger.kernel.org, vigneshr@ti.com, richard@nod.at, bbrezillon@kernel.org, kdasu.kdev@gmail.com Subject: Re: [PATCH v2] mtd: rawnand: brcmnand: Initial exec_op implementation Message-ID: <20231006094245.6cc24e03@xps-13> In-Reply-To: <0c72dbb4-8ee5-c9b0-b029-9689e9d72f5e@broadcom.com> References: <20230922162424.4a7b27ec@xps-13> <20231002143527.4ccf254a@xps-13> <04350e70-6ef0-4998-664f-20b96b63b0f4@broadcom.com> <20231003112819.53707d54@xps-13> <37416f2e-f150-cc8f-76bd-3d54f9e25d08@broadcom.com> <20231004005525.3f406823@xps-13> <0f6bd61c-19ed-8153-1763-eef2498726c7@broadcom.com> <0c72dbb4-8ee5-c9b0-b029-9689e9d72f5e@broadcom.com> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231006_004255_872076_67DDB7DD X-CRM114-Status: GOOD ( 55.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 SGkgV2lsbGlhbSwKCndpbGxpYW0uemhhbmdAYnJvYWRjb20uY29tIHdyb3RlIG9uIFRodSwgNSBP Y3QgMjAyMyAxNzo0MjoyMSAtMDcwMDoKCj4gSGkgTWlxdWVsLAo+IAo+IE9uIDEwLzAzLzIwMjMg MDk6NDcgUE0sIFdpbGxpYW0gWmhhbmcgd3JvdGU6Cj4gPiAKPiA+IAo+ID4gT24gMTAvMDMvMjAy MyAwMzo1NSBQTSwgTWlxdWVsIFJheW5hbCB3cm90ZTogIAo+ID4+IEhpIFdpbGxpYW0sCj4gPj4K PiA+PiB3aWxsaWFtLnpoYW5nQGJyb2FkY29tLmNvbSB3cm90ZSBvbiBUdWUsIDMgT2N0IDIwMjMg MTE6NDY6MjUgLTA3MDA6Cj4gPj4gIAo+ID4+PiBIaSBNaXF1ZWwsCj4gPj4+Cj4gPj4+IE9uIDEw LzAzLzIwMjMgMDI6MjggQU0sIE1pcXVlbCBSYXluYWwgd3JvdGU6ICAKPiA+Pj4+IEhpIFdpbGxp YW0sCj4gPj4+Pgo+ID4+Pj4gd2lsbGlhbS56aGFuZ0Bicm9hZGNvbS5jb20gd3JvdGUgb24gTW9u LCAyIE9jdCAyMDIzIDEyOjU3OjAxIC0wNzAwOiAgCj4gPj4+Pj4gSGkgTWlxdWVsLAo+ID4+Pj4+ Cj4gPj4+Pj4gT24gMTAvMDIvMjAyMyAwNTozNSBBTSwgTWlxdWVsIFJheW5hbCB3cm90ZTogIAo+ ID4+Pj4+PiBIaSBEYXZpZCwKPiA+Pj4+Pj4KPiA+Pj4+Pj4gZHJlZ2FuQG1haWwuY29tIHdyb3Rl IG9uIFNhdCwgMzAgU2VwIDIwMjMgMDM6NTc6MzUgKzAyMDA6Cj4gPj4+Pj4+IMKgwqDCoCA+Pj4+ IEluaXRpYWwgZXhlY19vcCBpbXBsZW1lbnRhdGlvbiBmb3IgQnJvYWRjb20gU1RCLCA+Pj4+Pj4g QnJvYWRiYW5kIGFuZCBpUHJvYyBTb0MgIAo+ID4+Pj4+Pj4gVGhpcyBhZGRzIGV4ZWNfb3AgYW5k IHJlbW92ZXMgdGhlIGxlZ2FjeSBpbnRlcmZhY2UuCj4gPj4+Pj4+Pgo+ID4+Pj4+Pj4gU2lnbmVk LW9mZi1ieTogRGF2aWQgUmVnYW4gPGRyZWdhbkBtYWlsLmNvbT4KPiA+Pj4+Pj4+IFJldmlld2Vk LWJ5OiBXaWxsaWFtIFpoYW5nIDx3aWxsaWFtLnpoYW5nQGJyb2FkY29tLmNvbT4KPiA+Pj4+Pj4+ Cj4gPj4+Pj4+PiAtLS0KPiA+Pj4+Pj4+IMKgwqAgPj4+ICAKPiA+Pj4+Pj4gLi4uCj4gPj4+Pj4+ IMKgwqDCoCA+Pj4+ICtzdGF0aWMgaW50IGJyY21uYW5kX3BhcnNlcl9leGVjX21hdGNoZWRfb3Ao c3RydWN0ID4+Pj4+PiBuYW5kX2NoaXAgKmNoaXAsICAKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbnN0IHN0cnVjdCBuYW5kX3N1Ym9wICpzdWJv cCkKPiA+Pj4+Pj4+ICt7Cj4gPj4+Pj4+PiArwqDCoMKgIHN0cnVjdCBicmNtbmFuZF9ob3N0ICpo b3N0ID0gbmFuZF9nZXRfY29udHJvbGxlcl9kYXRhKGNoaXApOwo+ID4+Pj4+Pj4gK8KgwqDCoCBz dHJ1Y3QgYnJjbW5hbmRfY29udHJvbGxlciAqY3RybCA9IGhvc3QtPmN0cmw7Cj4gPj4+Pj4+PiAr wqDCoMKgIHN0cnVjdCBtdGRfaW5mbyAqbXRkID0gbmFuZF90b19tdGQoY2hpcCk7Cj4gPj4+Pj4+ PiArwqDCoMKgIGNvbnN0IHN0cnVjdCBuYW5kX29wX2luc3RyICppbnN0ciA9ICZzdWJvcC0+aW5z dHJzWzBdOwo+ID4+Pj4+Pj4gK8KgwqDCoCB1bnNpZ25lZCBpbnQgaTsKPiA+Pj4+Pj4+ICvCoMKg wqAgaW50IHJldCA9IDA7Cj4gPj4+Pj4+PiArCj4gPj4+Pj4+PiArwqDCoMKgIGZvciAoaSA9IDA7 IGkgPCBzdWJvcC0+bmluc3RyczsgaSsrKSB7Cj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqAgaW5z dHIgPSAmc3Vib3AtPmluc3Ryc1tpXTsKPiA+Pj4+Pj4+ICsKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKg wqDCoCBpZiAoKGluc3RyLT50eXBlID09IE5BTkRfT1BfQ01EX0lOU1RSKSAmJgo+ID4+Pj4+Pj4g K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKGluc3RyLT5jdHguY21kLm9wY29kZSA9PSBOQU5EX0NN RF9TVEFUVVMpKQo+ID4+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY3RybC0+c3RhdHVz X2NtZCA9IDE7Cj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqAgZWxzZSBpZiAoY3RybC0+c3RhdHVz X2NtZCAmJiAoaW5zdHItPnR5cGUgPT0gPj4+Pj4+PiBOQU5EX09QX0RBVEFfSU5fSU5TVFIpKSB7 Cj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAvKgo+ID4+Pj4+Pj4gK8KgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAqIG5lZWQgdG8gZmFrZSB0aGUgbmFuZCBkZXZpY2Ugd3JpdGUgcHJv dGVjdCA+Pj4+Pj4+IGJlY2F1c2UgbmFuZF9iYXNlIGRvZXMgYQo+ID4+Pj4+Pj4gK8KgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAqIG5hbmRfY2hlY2tfd3Agd2hpY2ggY2FsbHMgbmFuZF9zdGF0dXNf b3AgPj4+Pj4+PiBOQU5EX0NNRF9TVEFUVVMgd2hpY2ggY2hlY2tzCj4gPj4+Pj4+PiArwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgICogdGhhdCB0aGUgbmFuZCBpcyBub3Qgd3JpdGUgcHJvdGVjdGVk IGJlZm9yZSBhbiA+Pj4+Pj4+IG9wZXJhdGlvbiBzdGFydHMuCj4gPj4+Pj4+PiArwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgICogVGhlIHByb2JsZW0gd2l0aCB0aGlzIGlzIGl0J3MgZG9uZSBvdXRz aWRlID4+Pj4+Pj4gZXhlY19vcCBzbyB0aGUgbmFuZCBpcwo+ID4+Pj4+Pj4gK8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCAqIHdyaXRlIHByb3RlY3RlZCBhbmQgdGhpcyBjaGVjayB3aWxsIGZhaWwg dW50aWwgPj4+Pj4+PiB0aGUgd3JpdGUgb3IgZXJhc2UKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKiBvciB3cml0ZSBiYWNrIG9wZXJhdGlvbiBhY3R1YWxseSBoYXBwZW5zIHdo ZXJlIHdlID4+Pj4+Pj4gdHVybiBvZmYgd3AuCj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgICovCj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB1OCAqaW47Cj4gPj4+ Pj4+PiArCj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjdHJsLT5zdGF0dXNfY21k ID0gMDsKPiA+Pj4+Pj4+ICsKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGluc3Ry ID0gJnN1Ym9wLT5pbnN0cnNbaV07Cj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBp biA9IGluc3RyLT5jdHguZGF0YS5idWYuaW47Cj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBpblswXSA9IGJyY21uYW5kX3N0YXR1cyhob3N0KSB8IE5BTkRfU1RBVFVTX1dQOyAvKiA+ Pj4+Pj4+IGhpZGUgV1Agc3RhdHVzICovICAKPiA+Pj4+Pj4KPiA+Pj4+Pj4gSSBkb24ndCB1bmRl cnN0YW5kIHdoeSB5b3UgYXJlIGZha2luZyB0aGUgV1AgYml0LiBJZiBpdCdzIHNldCwKPiA+Pj4+ Pj4gYnJjbW5hbmRfc3RhdHVzKCkgc2hvdWxkIHJldHVybiBpdCBhbmQgeW91IHNob3VsZCBub3Qg Y2FyZSBhYm91dCA+Pj4+Pj4gaXQuIElmCj4gPj4+Pj4+IGl0J3Mgbm90IGhvd2V2ZXIsIGNhbiB5 b3UgcGxlYXNlIGdpdmUgbWUgdGhlIHBhdGggdXNlZCB3aGVuIHdlIGhhdmUKPiA+Pj4+Pj4gdGhp cyBpc3N1ZT8gRWl0aGVyIHdlIG5lZWQgdG8gbW9kaWZ5IHRoZSBjb3JlIG9yIHdlIG5lZWQgdG8g cHJvdmlkZQo+ID4+Pj4+PiBhZGRpdGlvbmFsIGhlbHBlcnMgaW4gdGhpcyBkcml2ZXIgdG8gY2ly Y3VtdmVudCB0aGUgZmF1bHR5IHBhdGguICAKPiA+Pj4+Pgo+ID4+Pj4+IFRoZSByZWFzb24gd2Ug aGF2ZSB0byBoaWRlIHdwIHN0YXR1cyBmb3Igc3RhdHVzIGNvbW1hbmQgaXMgYmVjYXVzZQo+ID4+ Pj4+IG5hbmRfYmFzZSBjYWxscyBuYW5kX2NoZWNrX3dwIGF0IHRoZSB2ZXJ5IGJlZ2lubmluZyBv ZiB3cml0ZSBhbmQgZXJhc2UKPiA+Pj4+PiBmdW5jdGlvbi4gVGhpcyBhcHBsaWVzIHRvIGJvdGgg ZXhlY19vcCBwYXRoIGFuZCBsZWdhY3kgcGF0aC4gV2l0aAo+ID4+Pj4+IEJyb2FkY29tIG5hbmQg Y29udHJvbGxlciBhbmQgbW9zdCBvZiBvdXIgYm9hcmQgZGVzaWduIHVzaW5nIHRoZSBXUCBwaW4K PiA+Pj4+PiBhbmQgaGF2ZSBpdCBhc3NlcnRlZCBieSBkZWZhdWx0LCB0aGUgbmFuZF9jaGVja193 cCBmdW5jdGlvbiB3aWxsIGZhaWwKPiA+Pj4+PiBhbmQgd3JpdGUvZXJhc2UgYWJvcnRzLsKgIFRo aXMgd29ya2Fyb3VuZCBoYXMgYmVlbiB0aGVyZSBiZWZvcmUgdGhpcwo+ID4+Pj4+IGV4ZWNfb3Ag cGF0Y2guCj4gPj4+Pj4KPiA+Pj4+PiBJIGFncmVlIGl0IGlzIHVnbHkgYW5kIGJldHRlciB0byBi ZSBhZGRyZXNzZWQgaW4gdGhlIG5hbmQgYmFzZSA+Pj4+PiBjb2RlLiBBbmQKPiA+Pj4+PiBJIHVu ZGVyc3RhbmQgQnJvYWRjb20ncyBXUCBhcHByb2FjaCBtYXkgc291bmQgYSBiaXQgb3ZlciBjYXV0 aW91cyA+Pj4+PiBidXQgd2UKPiA+Pj4+PiB3YW50IHRvIG1ha2Ugc3VyZSBubyBzcHVyaW91cyBl cmFzZS93cml0ZSBjYW4gaGFwcGVuIHVuZGVyIGFueQo+ID4+Pj4+IGNpcmN1bXN0YW5jZSBleGNl cHQgc29mdHdhcmUgZXhwbGljaXRseSB3YW50IHRvIHdyaXRlIGFuZCBlcmFzZS4gID4+Pj4+IFdQ IGlzCj4gPj4+Pj4gc3RhbmRhcmQgbmFuZCBjaGlwIHBpbiBhbmQgSSB0aGluayBtb3N0IHRoZSBu YW5kIGNvbnRyb2xsZXIgaGFzIHRoYXQKPiA+Pj4+PiB0aGF0IHBpbiBpbiB0aGUgZGVzaWduIHRv byBidXQgaXQgaXMgcG9zc2libGUgaXQgaXMgbm90IHVzZWQgYW5kCj4gPj4+Pj4gYm9vdGxvYWRl ciBjYW4gZGUtYXNzZXJ0IHRoZSBwaW4gYW5kIGhhdmUgYSBhbHdheXMtd3JpdGFibGUgbmFuZCBm bGFzaAo+ID4+Pj4+IGZvciBsaW51eC4gU28gbWF5YmUgd2UgY2FuIGFkZCBuYW5kIGNvbnRyb2xs ZXIgZHRzIG9wdGlvbiA+Pj4+PiAibmFuZC11c2Utd3AiLgo+ID4+Pj4+IElmIHRoaXMgcHJvcGVy dHkgZXhpc3QgYW5kIHNldCB0byAxLMKgIHdwIGNvbnRyb2wgaXMgaW4gdXNlIGFuZCBuYW5kCj4g Pj4+Pj4gZHJpdmVyIG5lZWQgdG8gY29udHJvbCB0aGUgcGluIG9uL2ZmIGFzIG5lZWRlZCB3aGVu IGRvaW5nIHdyaXRlIGFuZAo+ID4+Pj4+IGVyYXNlIGZ1bmN0aW9uLiBBbHNvIG5hbmQgYmFzZSBj b2RlIHNob3VsZCBub3QgY2FsbCBuYW5kX2NoZWNrX3dwIHdoZW4KPiA+Pj4+PiB3cCBpcyBpbiB1 c2UuIFRoZW4gd2UgY2FuIHJlbW92ZSB0aGUgZmFraW5nIFdQIHN0YXR1cyB3b3JrYXJvdW5kLiAg Cj4gPj4+Pj4+IMKgwqDCoCA+Pj4+ICvCoMKgwqDCoMKgwqDCoCB9IGVsc2UgaWYgKGluc3RyLT50 eXBlID09IE5BTkRfT1BfV0FJVFJEWV9JTlNUUikgeyAgCj4gPj4+Pj4+PiArwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCByZXQgPSBiY21uYW5kX2N0cmxfcG9sbF9zdGF0dXMoaG9zdCwgTkFORF9DVFJM X1JEWSwgPj4+Pj4+PiBOQU5EX0NUUkxfUkRZLCAwKTsKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIGlmIChjdHJsLT53cF9jbWQpIHsKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgY3RybC0+d3BfY21kID0gMDsKPiA+Pj4+Pj4+ICvCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgYnJjbW5hbmRfd3AobXRkLCAxKTsgIAo+ID4+Pj4+Pgo+ID4+Pj4+ PiBUaGlzIGlkZWFsbHkgc2hvdWxkIGRpc2FwcGVhci4KPiA+Pj4+Pj4gwqDCoMKgID4+IE1heWJl IHdlIGNhbiBoYXZlIHRoZSBkZXN0cnVjdGl2ZSBvcGVyYXRpb24gcGF0Y2ggZnJvbSBCb3JyaXMu ICAKPiA+Pj4+PiBDb250cm9sbGVyIGRyaXZlciBzdGlsbCBuZWVkIHRvIGFzc2VydC9kZWFzc2Vy dCB0aGUgcGluIGlmIGl0IHVzZXMgPj4+Pj4gbmFuZAo+ID4+Pj4+IHdwIGZlYXR1cmUgYnV0IGF0 IGxlYXN0IGl0IGRvZXMgbm90IG5lZWQgdG8gZ3Vlc3MgdGhlIG9wIGNvZGUuICAKPiA+Pj4+Cj4g Pj4+PiBBaCwgeWVhaCwgSSBnZXQgaXQuCj4gPj4+Pgo+ID4+Pj4gUGxlYXNlIGJlIG15IGd1ZXN0 LCB5b3UgY2FuIHJldml2ZSB0aGlzIHBhdGNoIHNlcmllcyAobWlnaHQgbmVlZCBsaWdodAo+ID4+ Pj4gdHdlYWtpbmcsIG5vdGhpbmcgYmlnKSBhbmQgYWxzbyB0YWtlIGluc3BpcmF0aW9uIGZyb20g aXQgaWYgbmVjZXNzYXJ5Ogo+ID4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2JicmV6aWxsb24vbGlu dXgvY29tbWl0L2U2MTJlMWYyYzY5YTMzYWM1ZjJjOTFkMTM2NjlmMGYxNzJkNTg3MTcgPj4+Pgo+ ID4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2JicmV6aWxsb24vbGludXgvY29tbWl0LzRlYzZmOGQ4 ZDgzZjVhYWNhNWQxODc3ZjAyZDQ4ZGE5NmQ0MWZjYmEgPj4+Pgo+ID4+Pj4gaHR0cHM6Ly9naXRo dWIuY29tL2JicmV6aWxsb24vbGludXgvY29tbWl0LzExYjRhY2ZmZDc2MWM0OTI4NjUyZDcwMjhk MTlmY2Q2ZjQ1ZTQ2OTYgPj4+PiAgCj4gPj4+IFN1cmUgd2Ugd2lsbCBpbmNvcnBvcmF0ZSB0aGUg ZGVzdHJ1Y3RpdmUgb3BlcmF0aW9uIHBhdGNoIGFuZCBwcm92aWRlIGEKPiA+Pj4gbmV3IHJldmlz aW9uLgo+ID4+Pgo+ID4+PiBUaGUgV1Agc3RhdHVzIHdvcmthcm91bmQgd2lsbCBzdGF5IGF0IGxl YXN0IGZvciB0aGlzIGNoYW5nZS4gSWYgeW91Cj4gPj4+IHRoaW5rIG15IHN1Z2dlc3Rpb24gdXNp bmcgYSBkdHMgc2V0dGluZyBhYm92ZSBpcyBva2F5LCB3ZSBjYW4gcHJvdmlkZSBhCj4gPj4+IHBh dGNoIGZvciB0aGF0IGFzIHdlbGwuwqAgT3IgaWYgeW91IGhhdmUgYW55IG90aGVyIGlkZWEgb3Ig c3VnZ2VzdGlvbiwKPiA+Pj4gd2UnZCBsaWtlIHRvIGhlYXIgdG9vLiAgCj4gPj4KPiA+PiBJIHRo b3VnaHQgdGhpcyB3YXMgbm90IG5lZWRlZCBhcyBCb3JpcyBpbml0aWFsIGNvbnZlcnNpb24gZGlk IG5vdCBuZWVkCj4gPj4gaXQuIFRoZSBnb2FsIGlzIHRvIGdldCByaWQgb2YgdGhpcyB3b3JrYXJv dW5kLgo+ID4+IEJvcmlzJyBpbml0aWFsIHBhdGNoIGRpZCByZW1vdmUgdGhhdCB3b3JrYXJvdW5k IGJ1dCBpdCB3aWxsIGJyZWFrIHRoZSAgCj4gPiBib2FyZCB0aGF0IHVzZXMgV1AgcGluIGJlY2F1 c2UgdGhlIG5hbmRfY2hlY2tfd3AgcnVuIGJlZm9yZSB0aGUgZXhlY19vcCA+IGFuZCBzdGF0dXMg cmV0dXJuZWQgaXMgd3JpdGUtcHJvdGVjdGVkIGluIHRoZSBlcmFzZSBhbmQgd3JpdGUgZnVuY3Rp b24uCj4gPiBJIGV4cGxhaW5lZCB0aGF0IGFib3ZlIGFuZCB5b3UgY2FuIHNlZSB0aGUgY29kZSBo ZXJlOgo+ID4gaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgvdjYuNi1yYzQvc291cmNl L2RyaXZlcnMvbXRkL25hbmQvcmF3L25hbmRfYmFzZS5jI0w0NTk5ID4gPiAKPiA+IEkgYWdyZWUg d2l0aCB5b3VyIGdvYWwgdG8gcmVtb3ZlIHRoaXMgd29ya2Fyb3VuZCBhbmQgd2UgaGF2ZSBzdWdn ZXN0ZWQKPiA+IG9uZSBwb3NzaWJsZSBmaXggYnV0IHdlIGFyZSBhbHNvIG9wZW4gdG8gYW55IG90 aGVyIHNvbHV0aW9uLgo+ID4gICAKPiBXZSBoYXZlIGludGVncmF0ZWQgdGhlIGRlc3RydWN0aXZl IG9wZXJhdGlvbiBwYXRjaCBhbmQgYXJlIHJlYWR5IGZvciB0aGUKPiB2My4gIElmIHlvdSBkb24n dCB0aGluayBteSBwcm9wb3NhbCBvbiB0aGUgV1Agc3RhdHVzIGZpeCBpcyBhIGdvb2QgaWRlYSwK PiBjYW4gd2UgZ2V0IHRoaXMgZXhjZV9vcCBjb252ZXJzaW9uIHBhdGNoIHNlcmllcyBnb2luZyBm aXJzdD8gIEFmdGVyIGFsbCwKPiB3ZSBkb24ndCBtb2RpZnkgdGhlIFdQIHN0YXR1cyBoYW5kbGlu ZyBiZWhhdmlvciBpbiB0aGlzIHBhdGNoLiBXZSBjYW4KPiBmaXggaXQgaW4gYW5vdGhlciBwYXRj aCB3aGVuZXZlciB3ZSBhZ3JlZSBvbiBhIHNvbHV0aW9uLiAgUGxlYXNlIGxldCBtZQo+IGtub3cg YW5kIHRoYW5rcyBhIGxvdCBmb3IgYWxsIHlvdXIgY29tbWVudHMgYW5kIHRob3VnaHRzLgoKVGhl IE5BTkQgY29yZSBoYXMgYmVlbiBhIHBsYXlncm91bmQgZm9yIGNvZGluZyBob3Jyb3JzIHNvbWV0 aW1lcywgYW5kCnRoaXMgLT5leGVjX29wKCkgY29udmVyc2lvbiBpcyB1cyB0aGUgd2F5IHRvIGEg Y2xlYW5lciBhbmQgbWFzdGVyZWQKYXBwcm9hY2gsIEkgYW0gbm90IHdpbGxpbmcgdG8gbGV0IHNv bWV0aGluZyB0aGF0IG9idmlvdXMgZ2V0IGluLCBJJ20Kc29ycnkuIEZvciB5b3UgaXQncyBqdXN0 IGEgd29ya2Fyb3VuZCwgZm9yIG1lIGl0IG1lYW5zIGFueSBjaGFuZ2UgaW4KdGhlIGNvcmUgd2ls bCBqdXN0IGJyZWFrIHdpdGggdGhpcyBjb250cm9sbGVyLgoKVGhpcyBpcyBvZiBjb3Vyc2Ugbm90 IGFnYWluc3QgeW91IG9yIHlvdXIgd29yaywgcGVyaGFwcyBJIHNob3VsZAplbXBoYXNpemUgdGhh dCBJIHN0cm9uZ2x5IGFwcHJlY2lhdGUgeW91ciBlZmZvcnRzIGFuZCwgYmVzaWRlcyB0aGlzCndv cmthcm91bmQgdGhlIGNvZGUgaXMgY2xlYW4uCgpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBXUCBw aW4gY2FuIGJlIHVzZWQgaW4gdHdvIGRpZmZlcmVudCB3YXlzOgppbnRlcm5hbGx5IGFuZCBleHRl cm5hbGx5LiBXaGVuIGl0J3MgdXNlZCBleHRlcm5hbGx5LCB5b3UgZXhwZWN0IGl0CnRvIGJlIGRl YXNzZXJ0ZWQgYmVmb3JlIHlvdSBzdGFydCBhIGRlc3RydWN0aXZlIG9wZXJhdGlvbi4gV2hlbiB5 b3UgdXNlCml0IGludGVybmFsbHksIHlvdSBleHBlY3QgaXQgdG8gYmUgZGVhc3NlcnRlZCBkdXJp bmcgdGhlIGRlc3RydWN0aXZlCm9wZXJhdGlvbi4KClRoZSBmaW5hbCBzb2x1dGlvbiBuZWVkcyB0 byBiZSBhcHByb3ZlZCBieSBjb21wYXJpbmcgd2l0aApzaW1pbGFyIGRyaXZlcnMgd2hpY2ggcGVy Zm9ybSB0aGlzIGludGVybmFsIHByb2NlZHVyZSB0aGVtc2VsdmVzCmFzIHdlbGwuIE1heWJlIHdl IGNvdWxkIGFkZCBhIGZsYWcgc29tZXdoZXJlIGluIHRoZSBjb3JlJ3MgY29udHJvbGxlcgpzdHJ1 Y3R1cmUgdG8gdGVsbCB0aGUgY29yZSBub3QgdG8gcGVyZm9ybSB0aGVzZSBjaGVja3MgYXMgd2Ug bWFzdGVyIHRoZQpoYW5kbGluZyBvZiB0aGUgV1AgcGluLCB0ZWxsaW5nIHRoZSBjb250cm9sbGVy IHdpbGwgaGFuZGxlIGl0CmNvcnJlY3RseSBhcyBsb25nIGFzIHRoZSBkZXN0cnVjdGl2ZSBmbGFn IGlzIHBhc3NlZC4KClRoYW5rcywgTWlxdcOobAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcg bGlzdApodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10 ZC8K 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33654E92FF4 for ; Fri, 6 Oct 2023 07:50:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230393AbjJFHuX (ORCPT ); Fri, 6 Oct 2023 03:50:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230384AbjJFHuN (ORCPT ); Fri, 6 Oct 2023 03:50:13 -0400 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84A66FC for ; Fri, 6 Oct 2023 00:42:51 -0700 (PDT) Received: by mail.gandi.net (Postfix) with ESMTPSA id 3A4A91C0008; Fri, 6 Oct 2023 07:42:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1696578170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KQFwrUeYJEDlw/TSLgMcUD55L/pInUxyhSLEs5AXqms=; b=VJLR3AQC9+1xKQjLSwdQ3raBHu845I2YoP2u6Ky5XHpnYjv9gz2yDZOTA2zeNg2Ha+mlSy nn9CdZ7cU8OXPxk9ga5Iw8dH+anBW82dAHFHiS9fCWJ5dUe0zFXn6DMCNN4s/H1loT+RKo vk1rOFzpcUJ9X6AC+JxF7TvGKfAl5RIpvgdf5bIXvkqj5U7fcWz0CvutHgQp9ZLzzUb9ad 0+ZmBBpPlUS4W+xepzpoDXTcUk7oCg4hoif52eV7dDNo01pkzoA6a1dqU2Fk1US/dvykxX SY2xAMQbak5GwswsSADneVcE8RN3bSNS5o4tvsYSxMB7DCnbBm7sM5XAcuI+ng== Date: Fri, 6 Oct 2023 09:42:45 +0200 From: Miquel Raynal To: William Zhang Cc: dregan@mail.com, bcm-kernel-feedback-list@broadcom.com, linux-mtd@lists.infradead.org, f.fainelli@gmail.com, rafal@milecki.pl, joel.peshkin@broadcom.com, computersforpeace@gmail.com, dan.beygelman@broadcom.com, frieder.schrempf@kontron.de, linux-kernel@vger.kernel.org, vigneshr@ti.com, richard@nod.at, bbrezillon@kernel.org, kdasu.kdev@gmail.com Subject: Re: [PATCH v2] mtd: rawnand: brcmnand: Initial exec_op implementation Message-ID: <20231006094245.6cc24e03@xps-13> In-Reply-To: <0c72dbb4-8ee5-c9b0-b029-9689e9d72f5e@broadcom.com> References: <20230922162424.4a7b27ec@xps-13> <20231002143527.4ccf254a@xps-13> <04350e70-6ef0-4998-664f-20b96b63b0f4@broadcom.com> <20231003112819.53707d54@xps-13> <37416f2e-f150-cc8f-76bd-3d54f9e25d08@broadcom.com> <20231004005525.3f406823@xps-13> <0f6bd61c-19ed-8153-1763-eef2498726c7@broadcom.com> <0c72dbb4-8ee5-c9b0-b029-9689e9d72f5e@broadcom.com> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi William, william.zhang@broadcom.com wrote on Thu, 5 Oct 2023 17:42:21 -0700: > Hi Miquel, >=20 > On 10/03/2023 09:47 PM, William Zhang wrote: > >=20 > >=20 > > On 10/03/2023 03:55 PM, Miquel Raynal wrote: =20 > >> Hi William, > >> > >> william.zhang@broadcom.com wrote on Tue, 3 Oct 2023 11:46:25 -0700: > >> =20 > >>> Hi Miquel, > >>> > >>> On 10/03/2023 02:28 AM, Miquel Raynal wrote: =20 > >>>> Hi William, > >>>> > >>>> william.zhang@broadcom.com wrote on Mon, 2 Oct 2023 12:57:01 -0700: = =20 > >>>>> Hi Miquel, > >>>>> > >>>>> On 10/02/2023 05:35 AM, Miquel Raynal wrote: =20 > >>>>>> Hi David, > >>>>>> > >>>>>> dregan@mail.com wrote on Sat, 30 Sep 2023 03:57:35 +0200: > >>>>>> =C2=A0=C2=A0=C2=A0 >>>> Initial exec_op implementation for Broadco= m STB, >>>>>> Broadband and iProc SoC =20 > >>>>>>> This adds exec_op and removes the legacy interface. > >>>>>>> > >>>>>>> Signed-off-by: David Regan > >>>>>>> Reviewed-by: William Zhang > >>>>>>> > >>>>>>> --- > >>>>>>> =C2=A0=C2=A0 >>> =20 > >>>>>> ... > >>>>>> =C2=A0=C2=A0=C2=A0 >>>> +static int brcmnand_parser_exec_matched_o= p(struct >>>>>> nand_chip *chip, =20 > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const struct nand= _subop *subop) > >>>>>>> +{ > >>>>>>> +=C2=A0=C2=A0=C2=A0 struct brcmnand_host *host =3D nand_get_contr= oller_data(chip); > >>>>>>> +=C2=A0=C2=A0=C2=A0 struct brcmnand_controller *ctrl =3D host->ct= rl; > >>>>>>> +=C2=A0=C2=A0=C2=A0 struct mtd_info *mtd =3D nand_to_mtd(chip); > >>>>>>> +=C2=A0=C2=A0=C2=A0 const struct nand_op_instr *instr =3D &subop-= >instrs[0]; > >>>>>>> +=C2=A0=C2=A0=C2=A0 unsigned int i; > >>>>>>> +=C2=A0=C2=A0=C2=A0 int ret =3D 0; > >>>>>>> + > >>>>>>> +=C2=A0=C2=A0=C2=A0 for (i =3D 0; i < subop->ninstrs; i++) { > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 instr =3D &subop->ins= trs[i]; > >>>>>>> + > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ((instr->type =3D= =3D NAND_OP_CMD_INSTR) && > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 (instr->ctx.cmd.opcode =3D=3D NAND_CMD_STATUS)) > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ctrl->status_cmd =3D 1; > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else if (ctrl->status= _cmd && (instr->type =3D=3D >>>>>>> NAND_OP_DATA_IN_INSTR)) { > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 /* > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 * need to fake the nand device write protect >>>>>>> because nand= _base does a > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 * nand_check_wp which calls nand_status_op >>>>>>> NAND_CMD_STATU= S which checks > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 * that the nand is not write protected before an >>>>>>> operatio= n starts. > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 * The problem with this is it's done outside >>>>>>> exec_op so t= he nand is > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 * write protected and this check will fail until >>>>>>> the writ= e or erase > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 * or write back operation actually happens where we >>>>>>> turn = off wp. > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 */ > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 u8 *in; > >>>>>>> + > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ctrl->status_cmd =3D 0; > >>>>>>> + > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 instr =3D &subop->instrs[i]; > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 in =3D instr->ctx.data.buf.in; > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 in[0] =3D brcmnand_status(host) | NAND_STATUS_WP; /* >>>>>>> hide WP st= atus */ =20 > >>>>>> > >>>>>> I don't understand why you are faking the WP bit. If it's set, > >>>>>> brcmnand_status() should return it and you should not care about >= >>>>> it. If > >>>>>> it's not however, can you please give me the path used when we have > >>>>>> this issue? Either we need to modify the core or we need to provide > >>>>>> additional helpers in this driver to circumvent the faulty path. = =20 > >>>>> > >>>>> The reason we have to hide wp status for status command is because > >>>>> nand_base calls nand_check_wp at the very beginning of write and er= ase > >>>>> function. This applies to both exec_op path and legacy path. With > >>>>> Broadcom nand controller and most of our board design using the WP = pin > >>>>> and have it asserted by default, the nand_check_wp function will fa= il > >>>>> and write/erase aborts.=C2=A0 This workaround has been there before= this > >>>>> exec_op patch. > >>>>> > >>>>> I agree it is ugly and better to be addressed in the nand base >>>>= > code. And > >>>>> I understand Broadcom's WP approach may sound a bit over cautious >= >>>> but we > >>>>> want to make sure no spurious erase/write can happen under any > >>>>> circumstance except software explicitly want to write and erase. >= >>>> WP is > >>>>> standard nand chip pin and I think most the nand controller has that > >>>>> that pin in the design too but it is possible it is not used and > >>>>> bootloader can de-assert the pin and have a always-writable nand fl= ash > >>>>> for linux. So maybe we can add nand controller dts option >>>>> "na= nd-use-wp". > >>>>> If this property exist and set to 1,=C2=A0 wp control is in use and= nand > >>>>> driver need to control the pin on/ff as needed when doing write and > >>>>> erase function. Also nand base code should not call nand_check_wp w= hen > >>>>> wp is in use. Then we can remove the faking WP status workaround. = =20 > >>>>>> =C2=A0=C2=A0=C2=A0 >>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 } else if (instr->type =3D=3D NAND_OP_WAITRDY_INSTR) { =20 > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ret =3D bcmnand_ctrl_poll_status(host, NAND_CTRL_RDY, >>>>>>> NAND_CTRL= _RDY, 0); > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 if (ctrl->wp_cmd) { > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ctrl->wp_cmd =3D 0; > >>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 brcmnand_wp(mtd, 1); =20 > >>>>>> > >>>>>> This ideally should disappear. > >>>>>> =C2=A0=C2=A0=C2=A0 >> Maybe we can have the destructive operation = patch from Borris. =20 > >>>>> Controller driver still need to assert/deassert the pin if it uses = >>>>> nand > >>>>> wp feature but at least it does not need to guess the op code. =20 > >>>> > >>>> Ah, yeah, I get it. > >>>> > >>>> Please be my guest, you can revive this patch series (might need lig= ht > >>>> tweaking, nothing big) and also take inspiration from it if necessar= y: > >>>> https://github.com/bbrezillon/linux/commit/e612e1f2c69a33ac5f2c91d13= 669f0f172d58717 >>>> > >>>> https://github.com/bbrezillon/linux/commit/4ec6f8d8d83f5aaca5d1877f0= 2d48da96d41fcba >>>> > >>>> https://github.com/bbrezillon/linux/commit/11b4acffd761c4928652d7028= d19fcd6f45e4696 >>>> =20 > >>> Sure we will incorporate the destructive operation patch and provide a > >>> new revision. > >>> > >>> The WP status workaround will stay at least for this change. If you > >>> think my suggestion using a dts setting above is okay, we can provide= a > >>> patch for that as well.=C2=A0 Or if you have any other idea or sugges= tion, > >>> we'd like to hear too. =20 > >> > >> I thought this was not needed as Boris initial conversion did not need > >> it. The goal is to get rid of this workaround. > >> Boris' initial patch did remove that workaround but it will break the = =20 > > board that uses WP pin because the nand_check_wp run before the exec_op= > and status returned is write-protected in the erase and write function. > > I explained that above and you can see the code here: > > https://elixir.bootlin.com/linux/v6.6-rc4/source/drivers/mtd/nand/raw/n= and_base.c#L4599 > >=20 > > I agree with your goal to remove this workaround and we have suggested > > one possible fix but we are also open to any other solution. > > =20 > We have integrated the destructive operation patch and are ready for the > v3. If you don't think my proposal on the WP status fix is a good idea, > can we get this exce_op conversion patch series going first? After all, > we don't modify the WP status handling behavior in this patch. We can > fix it in another patch whenever we agree on a solution. Please let me > know and thanks a lot for all your comments and thoughts. The NAND core has been a playground for coding horrors sometimes, and this ->exec_op() conversion is us the way to a cleaner and mastered approach, I am not willing to let something that obvious get in, I'm sorry. For you it's just a workaround, for me it means any change in the core will just break with this controller. This is of course not against you or your work, perhaps I should emphasize that I strongly appreciate your efforts and, besides this workaround the code is clean. The problem is that the WP pin can be used in two different ways: internally and externally. When it's used externally, you expect it to be deasserted before you start a destructive operation. When you use it internally, you expect it to be deasserted during the destructive operation. The final solution needs to be approved by comparing with similar drivers which perform this internal procedure themselves as well. Maybe we could add a flag somewhere in the core's controller structure to tell the core not to perform these checks as we master the handling of the WP pin, telling the controller will handle it correctly as long as the destructive flag is passed. Thanks, Miqu=C3=A8l