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=-1.0 required=3.0 tests=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 DDA76C433E0 for ; Wed, 24 Jun 2020 07:48:35 +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 9DC5F20768 for ; Wed, 24 Jun 2020 07:48:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Tt19eFwW"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lxrNaQhU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DC5F20768 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=T5rGT9+KFkdbzN0wKiwIApRCXSJETNXltOPSTVBvLqo=; b=Tt19eFwW8saKSQgy6XhtAjsoR OxfsYl0MWnIgLLdqVEV05vYWyCP4pqEdtWVcdbG+RcTITEancNC9yh0S1MnJ8Se+AfPO3RdtqVDWw nRVcp0Rr5CUGq7q3N97HxS6hxhs3ZjfHOHgYXSPISnBAy5KxyIvTfuXN6U8UEmODniPUwzowiw66t j1q5rD9lxk5A7wLhZJt9ku4qZwZPSI6ChowUaDq2rbTq0osieMUuBYd1mIKxTVT+mbKyllAnCleuq RR/2x5iztxDXf3avL6w60Do6e0vnXHhbDZYajSgWD6faXfajxyxSgUAYiQB6v8770kbp8HJERgGXl xaDjEsVuQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo07E-0001d3-NV; Wed, 24 Jun 2020 07:46:40 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo079-0001b7-Hv for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 07:46:37 +0000 Received: by mail-wm1-x344.google.com with SMTP id o8so1365508wmh.4 for ; Wed, 24 Jun 2020 00:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=epcuiGqVlmnY4nv0TpcFlJgIf53mrnQAjcQ2iWd8n20=; b=lxrNaQhURYbDOacetuAOB4rqihVjeFhPrFku/MctijJgTEB6swEolAYoXWCGDNjxfe Wqs5E39Z4cE5O8xnsPvjSQnheb8F7BeqLBrQXIDuYGW4zsGKcuaDlr79IHoHHGXa+lbr /s+ASmZCc2IP0khedmhvjUqUCjQrxrzXPqV4zNwdvVqM8NLJtk/d9wM3+8BaPdzCZTQi 6XscRwZ6rn9V4IGRq1poGAG1quK8yg9jVg204Ty4mC08Aswn2wjZZ0+4xJ4jo19C+9mA pAJ1NH/0KfUJ3tGf39JUt91YqNjjMP0dKcNOa9evgsbCCbiT1NuvKltfInrj9egcbCG6 H5IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=epcuiGqVlmnY4nv0TpcFlJgIf53mrnQAjcQ2iWd8n20=; b=fubrvCdV3trgirJ9D6qYmucKg0WsWiMdvbdUVJIW68LOsAr/RU5Eka1GvZ+Qem+EOJ ARJOMHOZsI90Rh4zouIKyeeiINQ0RgsH8+ihIXQufYQT57OaVYqOBokiXxbqsm14xuV4 swuxIL1x0FNVFfiwmv4kWnLfvQk14Wxc4I1wif++i31c7X3TOPNjlQvUFUnAcAxVt7OC g0w2xSd3ieleJBYFAMVuu9TI2dKfHPBW3PPrZlwn6xq+WhuJOFmTNv4NYlDFnv7t5DzH z6G+9VFY1edfRiL+mJVwbDip+ZQBtbztKDBshpsyKEVhJ4ZDLQU5bbipslKAHfPY8dvX GzqQ== X-Gm-Message-State: AOAM531m8oZTaobBWQZdCNlbVU/WO+62Bq2co3BP++1tipAPysh4h8Vb Rv5PQyon/R4zJ9mNwERA1XXPug== X-Google-Smtp-Source: ABdhPJwABrQgNhzh+ctnmNgoeNQCk2WyukwHXPTFPW0rrC3LNFzgwwXryqZIsCHShyMS5hYSJyHmHw== X-Received: by 2002:a1c:3bc2:: with SMTP id i185mr29006254wma.33.1592984794170; Wed, 24 Jun 2020 00:46:34 -0700 (PDT) Received: from dell ([2.27.35.144]) by smtp.gmail.com with ESMTPSA id x14sm25926377wrt.60.2020.06.24.00.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 00:46:33 -0700 (PDT) Date: Wed, 24 Jun 2020 08:46:31 +0100 From: Lee Jones To: Frank Rowand Subject: Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes Message-ID: <20200624074631.GE954398@dell> References: <20200622085009.GP954398@dell> <20200622151054.GW954398@dell> <037c0fd2-df35-5981-7ef2-c6199841650d@gmail.com> <20200622191133.GY954398@dell> <20200623064723.GZ954398@dell> <83f2be78-1548-fa2b-199a-2391b2eceb47@gmail.com> <20200623195905.GB954398@dell> <6684101d-1013-2964-c247-394f9b12a194@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6684101d-1013-2964-c247-394f9b12a194@gmail.com> 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, gregkh@linuxfoundation.org, broonie@kernel.org, michael@walle.cc, linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, andriy.shevchenko@linux.intel.com, robin.murphy@arm.com, linus.walleij@linaro.org, linux@roeck-us.net 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 T24gVHVlLCAyMyBKdW4gMjAyMCwgRnJhbmsgUm93YW5kIHdyb3RlOgoKPiBPbiAyMDIwLTA2LTIz IDE0OjU5LCBMZWUgSm9uZXMgd3JvdGU6Cj4gPiBTdWdnZXN0aW9uICMyCj4gPiAKPiA+Pj4+Pj4g MikgTW9kaWZ5IHBhdGNoIDEvMy4gIFRoZSBzbWFsbCBwYXJ0IG9mIHRoZSBwYXRjaCB0byBtb2Rp ZnkgaXM6Cj4gPj4+Pj4+Cj4gPj4+Pj4+ICtzdGF0aWMgaW50IG1mZF9tYXRjaF9vZl9ub2RlX3Rv X2RldihzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2LAo+ID4+Pj4+PiArCQkJCSAgICBzdHJ1 Y3QgZGV2aWNlX25vZGUgKm5wLAo+ID4+Pj4+PiArCQkJCSAgICBjb25zdCBzdHJ1Y3QgbWZkX2Nl bGwgKmNlbGwpCj4gPj4+Pj4+ICt7Cj4gPj4+Pj4+ICsJc3RydWN0IG1mZF9vZl9ub2RlX2VudHJ5 ICpvZl9lbnRyeTsKPiA+Pj4+Pj4gKwljb25zdCBfX2JlMzIgKnJlZzsKPiA+Pj4+Pj4gKwl1NjQg b2Zfbm9kZV9hZGRyOwo+ID4+Pj4+PiArCj4gPj4+Pj4+ICsJLyogU2tpcCBkZXZpY2VzICdkaXNh YmxlZCcgYnkgRGV2aWNlIFRyZWUgKi8KPiA+Pj4+Pj4gKwlpZiAoIW9mX2RldmljZV9pc19hdmFp bGFibGUobnApKQo+ID4+Pj4+PiArCQlyZXR1cm4gLUVOT0RFVjsKPiA+Pj4+Pj4gKwo+ID4+Pj4+ PiArCS8qIFNraXAgaWYgT0Ygbm9kZSBoYXMgcHJldmlvdXNseSBiZWVuIGFsbG9jYXRlZCB0byBh IGRldmljZSAqLwo+ID4+Pj4+PiArCWxpc3RfZm9yX2VhY2hfZW50cnkob2ZfZW50cnksICZtZmRf b2Zfbm9kZV9saXN0LCBsaXN0KQo+ID4+Pj4+Pgo+ID4+Pj4+PiBDaGFuZ2U6Cj4gPj4+Pj4+Cj4g Pj4+Pj4+ICsJCWlmIChvZl9lbnRyeS0+bnAgPT0gbnApCj4gPj4+Pj4+ICsJCQlyZXR1cm4gLUVB R0FJTjsKPiA+Pj4+Pj4KPiA+Pj4+Pj4gVG86Cj4gPj4+Pj4+Cj4gPj4+Pj4+ICsJCWlmIChvZl9l bnRyeS0+bnAgPT0gbnApIHsKPiA+Pj4+Pj4gKwkJCWlmICghY2VsbC0+dXNlX29mX3JlZykKPiA+ Pj4+Pj4gKwkJCQlyZXR1cm4gLUVJTlZBTDsKPiA+Pj4+Pj4gKwkJCWVsc2UKPiA+Pj4+Pj4gKwkJ CQlyZXR1cm4gLUVBR0FJTjsKPiA+Pj4+Pj4KPiA+Pj4+Pj4gVGhlcmUgbWF5IGJlIGEgYmV0dGVy IGNob2ljZSB0aGFuIEVJTlZBTCwgYnV0IEkgYW0ganVzdCBzaG93aW5nIHRoZSBtZXRob2QuCj4g Pj4+Pj4+Cj4gPj4+Pj4+IFlvdSBtYXkgYWxzbyB3YW50IHRvIHJlZmFjdG9yIHRoaXMgc2VjdGlv biBvZiB0aGUgcGF0Y2ggc2xpZ2h0bHkKPiA+Pj4+Pj4gZGlmZmVyZW50bHkgdG8gYWNoaWV2ZSB0 aGUgc2FtZSByZXN1bHQuICBJdCB3YXMganVzdCBlYXNpZXN0IHRvCj4gPj4+Pj4+IHNob3cgdGhl IHN1Z2dlc3RlZCBjaGFuZ2UgdGhlIHdheSBJIGRpZCBpdC4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gVGhl IHRlc3QgdGhhdCByZXR1cm5zIEVJTlZBTCBkZXRlY3RzIHRoZSBpc3N1ZSB0aGF0IHRoZSBGRFQg ZG9lcwo+ID4+Pj4+PiBub3QgbWF0Y2ggdGhlIGJpbmRpbmcgKHRoZXJlIGlzIG1vcmUgb25lIGNo aWxkIG5vZGUgd2l0aCB0aGUKPiA+Pj4+Pj4gInN0ZXJpY3Nzb24sYWI4NTAwLXB3bSIgY29tcGF0 aWJsZS4KPiA+IAo+ID4gTXkgcmVwbHkgdG8gc3VnZ2VzdGlvbiAjMgo+ID4gCj4gPj4+Pj4gU28g aGVyZSwgaW5zdGVhZCBvZiBqdXN0IGZhaWxpbmcgYSBzaW5nbGUgZGV2aWNlLCB3ZSBmYWlsIGV2 ZXJ5dGhpbmc/Cj4gPj4+Pj4gU291bmRzIGEgbG90IGxpa2UgdGhyb3dpbmcgdGhlIGJhYnkgb3V0 IHdpdGggdGhlIGJhdGggd2F0ZXIuICBIb3cgaXMKPiA+Pj4+PiB0aGF0IGFuIGltcHJvdmVtZW50 Pwo+IAo+IEkgY291bGQgaGF2ZSBzd29ybiB0aGF0IEkgaGFkIHJlcGxpZWQgd2l0aCBhIHNvbHV0 aW9uIHRvIHRoaXMgaXNzdWUuICBTbyBJCj4gc2VhcmNoZWQgYW5kIHNlYXJjaGVkIGFuZCBzZWFy Y2hlZCBteSBlbWFpbHMgaW4gdGhlIHRocmVhZC4gIEFuZCBjaGVja2VkIG15Cj4gZHJhZnRzIGVt YWlsIGZvbGRlci4gIFRoZW4gZmluYWxseSByZWFsaXplZCBJIGhhZCBtYWRlIGEgc3R1cGlkIG1p c3Rha2UuCj4gCj4gSSBkaWQgcmVwbHkgYWJvdXQgdGhpcywgYnV0IEkgaGFkIHB1dCBteSAiLUZy YW5rIiBzaWduYXR1cmUgYXQgdGhlIGVuZAo+IG9mIGEgY29tbWVudCBtdWNoIGhpZ2hlciBpbiB0 aGUgZW1haWwuICBTbyBvZiBjb3Vyc2UgSSBleHBlY3QgeW91IHN0b3BwZWQKPiByZWFkaW5nIGF0 IHRoYXQgcG9pbnQgYW5kIG5ldmVyIHNhdyBteSBhbnN3ZXIuICBNeSBhcG9sb2dpZXMhISEKPiAK PiBUaGUgZW1haWwgaW4gcXVlc3Rpb24gaXM6Cj4gCj4gICBodHRwczovL2xvcmUua2VybmVsLm9y Zy9saW51eC1kZXZpY2V0cmVlL2VhZTljYzAwLWU2N2EtY2I2YS0zN2MyLWYyMjM1NzgyZWQ3N0Bn bWFpbC5jb20vCj4gCj4gYW5kIHdoYXQgSSB3cm90ZSBhdCB0aGlzIHBvaW50IGluIHRoYXQgZW1h aWwgaXM6Cj4gCj4gICBZb3UgY2FuIG1vZGlmeSBtb3JlIGV4dGVuc2l2ZWx5IHRoYW4gbXkgc2lt cGxlIGV4YW1wbGUsIGNoYW5naW5nCj4gICBtZmRfYWRkX2RldmljZSgpIHRvIG1vcmUgZ3JhY2Vm dWxseSBoYW5kbGUgYW4gRUlOVkFMIHJldHVybmVkIGJ5Cj4gICBtZmRfbWF0Y2hfb2Zfbm9kZV90 b19kZXYoKS4KPiAKPiBUaHVzIGEgbW9kaWZpY2F0aW9uIHRvIG15IHN1Z2dlc3Rpb24gIzIgdG8g bWFrZSBpdCBfbm90XyBmYWlsCj4gZXZlcnl0aGluZy4KPiAKPiBJIGRpZG4ndCByZWFsbHkgZmxl c2ggb3V0IGFsbCB0aGF0ICJtb3JlIGdyYWNlZnVsbHkgaGFuZGxlIiBtZWFucy4KPiBBbW9uZyBv dGhlciB0aGluZ3MsIGl0IGNvdWxkIGluY2x1ZGUgYSBwcl93YXJuKCkgdGhhdCBwcm92aWRlcwo+ IGEgZmFpcmx5IHNwZWNpZmljIHBvc3NpYmxlIGNhdXNlIG9mIHRoZSBwcm9ibGVtIChlZyB0aGUg Y29ybmVyCj4gY2FzZSBtZW50aW9uZWQgbmVhciB0aGUgZW5kIG9mIHRoZSBwYXRjaCAxLzMgaGVh ZGVyIHRoYXQgc2hvd3MKPiBtaXhpbmcgT0ZfTUZEX0NFTEwoKSBhbmQgT0ZfTUZEX0NFTExfUkVH KCkgZm9yIHRoZSBzYW1lIGNvbXBhdGlibGUKPiB2YWx1ZS4gIEl0IG1heSBiZSB0cmlja3kgY29t aW5nIHVwIHdpdGggZ29vZCBwaHJhc2luZyBpbiBhIHByX3dhcm4oKQo+IHRoYXQgZGVzY3JpYmVz IHRoZSBnZW5lcmljIGlzc3VlIGluc3RlYWQgb2YgdGhlIHNwZWNpZmljIGV4YW1wbGUuCgpUaGUg Y3VycmVudCBzb2x1dGlvbiBhbHJlYWR5IHByb3ZpZGVzIGEgd2FybmluZyBpZiB3ZSBmYWlsIHRv IG1hdGNoIGEKZGV2aWNlIHdpdGggaXRzIHJlcXVlc3RlZCBPRiBub2RlLiAgSXQncyBhbHNvIHNl bWFudGljYWxseSBpbmNvcnJlY3QKdG8gZXJyb3Igb3V0IGp1c3QgYmVjYXVzZSBhIG5vZGUgd2l0 aCB0aGUgc2FtZSBjb21wYXRpYmxlIHN0cmluZyBpcwphbHJlYWR5IHRha2VuLCBzaW5jZSB0aGVy ZSBtYXliZSBhbm90aGVyIG9uZSBjb21pbmcgdXAgKHdoaWNoIHdpbGwgYmUKZm91bmQgb24gdGhl IG5leHQgaXRlcmF0aW9uIHBvc3QgcmV0dXJuIG9mIC1FQUdBSU4pLgoKUHJvdmlkaW5nIGEgbW9y ZSBhY2N1cmF0ZSB3YXJuaW5nIGRlc2NyaWJpbmcgKndoeSogYSBub2RlIHdhc24ndCBmb3VuZApp dCBhbHNvIG5vbi10cml2aWFsLCBmb3IgdGhlIHNhbWUgcmVhc29ucyBhcyBpdCdzIGhhcmQgdG8g ZG8gZHVyaW5nIGEKcHJlLXZhbGlkYXRpb24gcm91dGluZS4KCj4gPj4+IFswXQo+ID4+Cj4gPj4g SXMgIlswXSIgdGhlIHBhdGNoIHNlcmllcywgZXNwZWNpYWxseSBwYXRjaCAxLzM/Cj4gPiAKPiA+ IE5vLCB0aGlzIGlzIG15IHJlcGx5IHRvIHlvdXIgc3VnZ2VzdGlvbiAjMi4KPiA+IAo+ID4gVGhl IFswXSBpcyByZWZlcmVuY2VkIGZ1cnRoZXIgZG93bi4KPiA+IAo+ID4gWy4uLl0KPiA+IAo+ID4+ Pj4+ICAqIEZhbHNlIHBvc2l0aXZlcyBjYW4gb2NjdXIgYW5kIHdpbGwgZmFpbCBhcyBhIHJlc3Vs dAo+ID4+Pj4KPiA+Pj4+ICgoV2hhdCBpcyBhbiBleGFtcGxlIG9mIGEgZmFsc2UgcG9zaXRpdmU/ KSkgIE5ldmVyIG1pbmQsIG5vdyB0aGF0Cj4gPj4+PiBJIHNlZSB0aGF0IHRoZSBwcmV2aW91cyBp c3N1ZSBpcyBhIGZhdGFsIGZsYXcsIHRoaXMgYmVjb21lcwo+ID4+Pj4gYWNhZGVtaWMuCj4gPj4+ Cj4gPj4+IFRoYXQncyBva2F5LCBJIGRvbid0IG1pbmQgZGlzY3Vzc2luZy4KPiA+Pj4KPiA+Pj4g SXJvbmljYWxseSwgdGhlICdhYjg1MDAtcHdtJyBpcyBhIGdvb2QgZXhhbXBsZSBvZiBhIGZhbHNl IHBvc2l0aXZlLAo+ID4+PiBzaW5jZSBpdCdzIGZpbmUgZm9yIHRoZSBEVCBub2RlcyB0byBiZSBp ZGVudGljYWwuICBTbyBsb25nIGFzIHRoZXJlCj4gPj4+IGFyZSBub2RlcyBwcmVzZW50IGZvciBl YWNoIGluc3RhbmNlLCBpdCBkb2Vzbid0IG1hdHRlciB3aGljaCBvbmUgaXMKPiA+Pj4gYWxsb2Nh dGVkIHRvIHdoaWNoIGRldmljZSAuRm9yY2luZyBhICdyZWcnIHByb3BlcnR5IG9udG8gdGhlbSBm b3Igbm8+IGdvb2QgcmVhc29uIGl0IG5vdCBhIHZhbGlkIHNvbHV0aW9uIGhlcmUuCj4gPj4KPiAK PiBTdGFydCBvZiBteSBjb21tZW50IHRoYXQgSSB3cm90ZSB3aXRoICJ0b28gbWFueSBzaG9ydGN1 dHMiIChzZWUgYmVsb3cpOgo+IAo+ID4+IEkgdGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgcG9pbnRz IG9mIHRoaXMgcGF0Y2ggc2VyaWVzIHdhcyB0byBhZGQgYQo+ID4+ICJyZWciIHByb3BlcnR5IHRv IGFueSBtZmQgY2hpbGQgdGhhdCB3YXMgZGVzY3JpYmVkIGJ5IHRoZQo+ID4+IE9GX01GRF9DRUxM X1JFRygpIG1hY3JvLgo+ID4gCj4gPiBUaGUgT0ZfTUZEX0NFTExfUkVHKCkgbWFjcm8gZGlkbid0 IGV4aXN0IHVudGlsIHRoaXMgcGF0Y2gtc2V0Lgo+IAo+ICAgCj4gTWF5YmUgdGhlIHdheSBJIHdy b3RlIHRoYXQgdG9vayB0b28gbWFueSBzaG9ydGN1dHMuICBMZXQgbWUgcmUtcGhyYXNlLgo+IAo+ IEkgdGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgcG9pbnRzIG9mIHRoaXMgcGF0Y2ggc2V0IHdhcyB0 byBhZGQgdGhlCj4gb2ZfcmVnIGFuZCB1c2Vfb2ZfcmVnIGZpZWxkcyB0byBzdHJ1Y3QgbWZkX2Nl bGwuICBUaGUgZXhwZWN0ZWQgdXNlCj4gb2YgdGhlIG9mX3JlZyBhbmQgdXNlX29mX3JlZyBmaWVs ZHMgd2FzIHRvIGFsbG93IHRoZSBwcmVzZW5jZSBvZiBhCj4gInJlZyIgcHJvcGVydHkgaW4gYSBk ZXZpY2V0cmVlIG1mZCBjaGlsZCBub2RlIHRvIGJlIHVzZWQgdG8gbWF0Y2gKPiBzcGVjaWZpYyBj aGlsZCBub2RlcyB0byBzcGVjaWZpYyBlbGVtZW50cyBvZiB0aGUgbWZkX2FkZF9kZXZpY2VzKCkK PiBjZWxsIGFycmF5IHBhcmFtZXRlciwgd2l0aCB0aGUgbWF0Y2ggb2NjdXJyaW5nIHdoZW4gdGhl IGFycmF5IGVsZW1lbnRzCj4gYXJlIHByb2Nlc3NlZCAoY3VycmVudGx5IGluIG1mZF9tYXRjaF9v Zl9ub2RlX3RvX2RldigpLCB3aGljaCBpcwo+IGNhbGxlZCBieSBtZmRfYWRkX2RldmljZSgpKS4K PiAKPiBUaGUga2V5IHBvaW50IGJlaW5nIHRoZSBtYXRjaGluZyBzcGVjaWZpYyBkZXZpY2V0cmVl IG1mZCBjaGlsZCBub2Rlcwo+IHRvIHNwZWNpZmljIGNlbGwgYXJyYXkgbWVtYmVycy4KPiAKPiBU aGUgT0ZfTUZEX0NFTExfUkVHKCkgaXMgc2ltcGx5IGEgaGVscGVyIG1hY3JvIHJlbGF0ZWQgdG8g dGhlIGFib3ZlLgoKQ29ycmVjdCBzbyBmYXIuCgo+ID4gVGhlcmUgYXJlIGN1cnJlbnRseSBubyB1 c2Vycy4KPiAKPiBZZXMuICBBbmQgYXMgSSBwb2ludGVkIG91dCBlbHNld2hlcmUsIEkgd291bGQg ZXhwZWN0IGEgdXNlciBvZiBuZXcKPiBmdW5jdGlvbmFsaXR5IHRvIGJlIGFkZGVkIGFzIHBhcnQg b2YgYSBwYXRjaCBzZXJpZXMgdGhhdCBhZGRzIHRoZQo+IG5ldyBmdW5jdGlvbmFsaXR5LiAgT3Ig YXQgbGVhc3QgYSBtZW50aW9uIG9mIGEgc3BlY2lmaWMgcGxhbiB0bwo+IHVzZSB0aGUgZnVuY3Rp b25hbGl0eS4KClRoZXJlIGhhdmUgYmVlbiAyIHN1Y2ggdXNlLWNhc2VzIGluIHJlY2VudCBtb250 aHMuCgpUaGUgbW9zdCByZWNlbnQgaXMgTWljaGFlbCdzIChDQydlZCkgdXNlLWNhc2UuCgpNb3Jl b3ZlciwgdGhpcyBwYXRjaC1zZXQgYWN0dWFsbHkgZml4ZXMgc29tZXRoaW5nIHRoYXQgaGFzIGJl ZW4ga25vd24KdG8gYmUgYnJva2VuIChhY3R1YWxseSBub3QgYnJva2VuIHBlci1zYXksIGp1c3Qg J2xlc3MgZmVhdHVyZWZ1bCcpIGZvcgphIG51bWJlciBvZiB5ZWFycy4gIFNpbmNlIHRoZSBvcmln aW5hbCBzdXBwb3J0IHdhcyBhdXRob3JlZCwgb25seSAyCnBvdGVudGlhbCBpc3N1ZXMgaGF2ZSBh cmlzZW4uICBUaGUgZmlyc3QgdGltZSB3ZSBkZWVtZWQgaXQgYSBwcm9ibGVtCnRvbyBjb21wbGV4 IHRvIGZpeCAoSSBjYW4ndCwgZm9yIHRoZSBsaWZlIG9mIG1lIGZpbmQgdGhhdCB0aHJlYWQsIGJ1 dApJJ20gcHJldHR5IHN1cmUgaXQgaW52b2x2ZWQgUm9iaW4gZnJvbSBBcm0gW3doaWNoIGlzIHdo eSBoZSBpcwpDQydlZF0pLiAgTWljaGFlbCdzIHVzZS1jYXNlIGlzIHRoZSBzZWNvbmQuICBUaGlz IHRpbWUgSSB0aG91Z2h0IEknZApoYXZlIGEgc3RhYiBhdCBmaXhpbmcgKG9yIGF0IGxlYXN0IGJl dHRlcmluZykgaXQuCgo+IEkgaGFkIGJlZW4gYXNzdW1pbmcgdGhhdCB0aGUgaW50ZW5kZWQgdXNl ciB3YXMgdGhlIG9uZSB1c2UgY2FzZSB0aGF0Cj4gSSBoYWQgaWRlbnRpZmllZCwgYW5kIHRoYXQg eW91IGxldCBtZSBjb250aW51ZSB0byBhc3N1bWUgd2FzIHRoZSBvbmUKPiBleGlzdGluZyB1c2Ug Y2FzZS4KClNvcnJ5IGlmIHlvdSBmZWVsIG1pc2xlZCwgYnV0IHRoYXQgaXMgbm90IHRoZSBjYXNl LgoKPiA+PiBBbmQgdGhhdCB3YXMgbWVhbnQgdG8gZml4IHRoZSBwcm9ibGVtIHdoZXJlIG11bHRp cGxlIGluZGlzdGluZ3Vpc2hhYmxlCj4gPj4gY2hpbGRyZW4gZXhpc3RlZC4gIFRoZSBvbmx5IGlu c3RhbmNlIEkgZm91bmQgb2YgdGhhdCAodXNpbmcgdGhlCj4gPj4gd2VhayBzZWFyY2ggb24gT0Zf TUZEX0NFTEwoKSkgd2FzIG9mIGNvbXBhdGlibGUgInN0ZXJpY3Nzb24sYWI4NTAwLXB3bSIKPiA+ PiBpbiBkcml2ZXJzL21mZC9hYjg1MDAtY29yZS5jLiAgWW91IGFncmVlZCB3aXRoIG15IGVtYWls IHRoYXQKPiA+PiByZXBvcnRlZCB0aGF0Lgo+ID4gCj4gPiBObywgSSBhZ3JlZWQgd2l0aCB5b3Ug dGhhdCB0aGVyZSBpcyBhIGN1cnJlbnQgcHJvYmxlbSB3aXRoCj4gPiAic3Rlcmljc3NvbixhYjg1 MDAtcHdtIiwgYXMgaWRlbnRpZmllZCBieSBNaWNoYWVsLiAgSSBkaWRuJ3QgYWN0dWFsbHkKPiA+ IGtub3cgYWJvdXQgdGhpcyBpc3N1ZSB1bnRpbCAqYWZ0ZXIqIGRyYWZ0aW5nIHRoaXMgcGF0Y2gt c2V0LiAgVG8gYmUKPiA+IGNsZWFyIHRoZSAic3Rlcmljc3NvbixhYjg1MDAtcHdtIiBzY2VuYXJp byBpcyBub3QgdGhlIHJlYXNvbiBmb3IgdGhpcwo+ID4gc2V0J3MgZXhpc3RlbmNlLgo+IAo+IFNv IG5vdyBJIGtub3cgdGhhdCBkcml2ZXJzL21mZC9hYjg1MDAtY29yZS5jIGlzIHRvdGFsbHkgdW5y ZWxhdGVkIHRvCj4gdGhpcyBwYXRjaCBzZXJpZXMsIGFuZCBub3QgdGhlIGludGVuZGVkIHVzZXIg b2YgdGhlIG5ldyBmdW5jdGlvbmFsaXR5Lgo+IAo+ID4gCj4gPiBBbHNvLCBwbGVhc2UgZm9yZ2V0 IGFib3V0IHRoZSBPRl9NRkRfKiBtYWNyb3MsIHRoZXkgYXJlIHRvdGFsbHkKPiA+IGFnbm9zdGlj IHRvIHRoaXMgZWZmb3J0LiAgVGhlIG9ubHkgcmVsZXZhbmNlIHRoZXkgaGF2ZSBoZXJlIGlzIHRo ZQo+ID4gYWRkaXRpb24gb2YgMSBleHRyYSBtYWNybyB3aGljaCAqY291bGQqIGJlIHVzZWQgdG8g cHJvdmlkZSB0aGUgJ3JlZycKPiA+IHByb3BlcnR5IHdoZXJlIGFwcHJvcHJpYXRlLgo+IAo+IE15 IHBvaW50IHdhcyB0aGF0IG15IHNlYXJjaCBmb3IgdGhlIGRhdGEgdGhhdCBjb21wcmlzZWQgdGhl ICJjZWxsIgo+IHBhcmFtZXRlciBwYXNzZWQgdG8gbWZkX2FkZF9kZXZpY2VzKCkgd2FzIGluYWRl cXVhdGUsIGJlY2F1c2UgSQo+IHdhcyBzZWFyY2hpbmcgb24gT0ZfTUZEX0NFTEwoKSBpbnN0ZWFk IG9mIG1mZF9hZGRfZGV2aWNlcy4gIEkgd2FzCj4gYWRtaXR0aW5nIHRoYXQgcGFydCBvZiBteSBp Z25vcmFuY2Ugd2FzIGJlY2F1c2Ugb2YgdGhpcyBwb29yIHNlYXJjaC4KPiAKPiBJIHdhcyBzZWFy Y2hpbmcgZm9yIHdoZXJlIHRoZSBwcm9ibGVtIGNhc2UgYWN0dWFsbHkgb2NjdXJyZWQgaW4gdGhl Cj4ga2VybmVsLiAgTWF5YmUgeW91IGRpZCBub3QgcmVhbGl6ZSB0aGF0IEkgaGF2ZSBiZWVuIHRo aW5raW5nIHRoYXQKPiB0aGUgb25seSBwbGFjZSB3aGVyZSB0aGUgcHJvYmxlbSBjYXNlIG9jY3Vy cmVkIHdhcyB0aGUgc2luZ2xlIGNhc2UKPiBJIGZvdW5kIHdpdGggdGhpcyBpbnN1ZmZpY2llbnQg c2VhcmNoIG1ldGhvZC4KPiAKPiBJbiBzb21lIG9yIG1hbnkgb3IgYWxsIChJIGRvbid0IGtub3cs IEknbSBub3QgZ29pbmcgdG8gZ28gYmFjawo+IGFuZCBzZWFyY2ggZm9yIGFsbCBvZiB0aGVtKSB5 b3UgY2FuIHByb2JhYmx5IHJlcGxhY2UgbWVudGlvbgo+IG9mIHRoZSBPRl9NRkRfKiB3aXRoIGVp dGhlciBteSBzZWFyY2ggZm9yIGlucHV0IGRhdGEgdG8KPiBtZmRfYWRkX2RldmljZXMoKSBfb3Jf IGEgY29uY2lzZSByZWZlcmVuY2UgdG8gdGhlIG5ldyBvZl9yZWcKPiBhbmQgdXNlX29mX3JlZyBm aWVsZHMgb2Ygc3RydWN0IG1mZF9jZWxsIGFuZCB0aGUgdXNlIG9mIHRoZQo+IG5ldyBmaWVsZHMu Cj4gCj4gV2hlcmUgaXMgdGhlIHByb2JsZW0gdGhhdCB0aGUgcGF0Y2ggc2V0IHdhcyBpbnRlbmRl ZCB0byBmaXg/CgpGaXJzdGx5LCB0aGUgcHJvYmxlbSBpcyBwcmVzZW50LCBhcyBkZXNjcmliZWQg aW4gdGhlIGNvbW1pdCBtZXNzYWdlLgpJdCBpcyAqbm90IGNvcnJlY3QgdG8gcmUtbWF0Y2ggYW4g T0Ygbm9kZSB3aXRoIG11bHRpcGxlIGRldmljZXMuICBFdmVuCmlmIHRoZXJlIHdhc24ndCBhIGN1 cnJlbnQgKnJlYWwqIHVzZXIsIHRoaXMgcGF0Y2ggaXMgc3RpbGwgdGhlIHJpZ2h0CnRoaW5nIHRv IGRvLCBhcyBpdCBtYWtlcyB0aGUgc2l0dWF0aW9uICpzb29vKiBtdWNoIGJldHRlci4KCkhvd2V2 ZXIsIHRoZXJlIGlzIGEgcHJvc3BlY3RpdmUgdXNlciBhbHNvIFsxXS4KClsxXSBodHRwczovL2xv cmUua2VybmVsLm9yZy9saW51eC1hcm0ta2VybmVsLzIwMjAwNDIzMTc0NTQzLjE3MTYxLTEtbWlj aGFlbEB3YWxsZS5jYy8KCj4gPj4gU28gSSB0aG91Z2h0IHRoYXQgZHJpdmVycy9tZmQvYWI4NTAw LWNvcmUuYyB3b3VsZCBiZSBtb2RpZmllZCB0bwo+ID4+IHJlcGxhY2UgdGhlIG11bHRpcGxlIGlu c3RhbmNlcyBvZiBjb21wYXRpYmxlICJzdGVyaWNzc29uLGFiODUwMC1wd20iCj4gPj4gaW4gT0Zf TUZEX0NFTEwoKSB3aXRoIE9GX01GRF9DRUxMX1JFRygpLgo+ID4gCj4gPiBUaGF0IGlzIG5vdCBt eSB2aXNpb24uICBUaGVyZSBpcyBubyBuZWVkIGZvciAic3Rlcmljc3NvbixhYjg1MDAtcHdtIgo+ ID4gdG8gaGF2ZSAncmVnJyBwcm9wZXJ0aWVzIGFzIGZhciBhcyBJIHNlZSBpdC4KPiAKPiBJbiB0 aGF0IGNhc2UgdGhlIGJpbmRpbmcgZG9jdW1lbnQgZm9yIHRoZSBtZmQgY2hpbGQgbm9kZSB3aXRo Cj4gY29tcGF0aWJsZSAic3Rlcmljc3NvbixhYjg1MDAtcHdtIiBzaG91bGQgYmUgdXBkYXRlZCB0 byBzdGF0ZQo+IHRoYXQgaWYgdGhlcmUgYXJlIG11bHRpcGxlIHN1Y2ggY2hpbGQgbm9kZXMgd2l0 aCB0aGUgc2FtZSBwYXJlbnQKPiB0aGVuIHRoZXkgbXVzdCBjb250YWluIGV4YWN0bHkgdGhlIHNh bWUgc2V0IG9mIHByb3BlcnRpZXMgYW5kCj4gdmFsdWVzLgo+IAo+IE1heWJlIG5vdCB5b3VyIHBy b2JsZW0sIEkgaGF2ZSBubyBpZGVhIHdobyBpcyByZXNwb25zaWJsZSBmb3IKPiB0aGF0IHVwZGF0 ZS4KClRoaXMgaXMgdGhlIGNhc2UgZm9yIGFsbCBPRiBub2Rlcywgbm90IGp1c3QgJ2FiODUwMC1w d20nLgoKRmVsbCBmcmVlIHRvIHN1Ym1pdCBhIHBhdGNoLgoKPiBIb3dldmVyLCAKPiAKPiA+PiBU aGlzIGlzIGFub3RoZXIgcHJvYmxlbSB3aXRoIHRoZSBwYXRjaCBzZXJpZXM6IHRoZXJlIGlzIG5v IHVzZXIKPiA+PiBvZiBPRl9NRkRfQ0VMTF9SRUcoKS4gIFBsZWFzZSBhZGQgb25lIHRvIHRoZSBz ZXJpZXMuCj4gPiAKPiA+IFRoYXQncyBub3QgYSBwcm9ibGVtIHdpdGggdGhpcyBwYXRjaC1zZXQs IGl0J3MgYSBwcm9ibGVtIHdpdGggeW91cgo+ID4gdW5kZXJzdGFuZGluZyBvZiB0aGlzIHBhdGNo LXNldC4gOikKPiAKPiBJIGhhdmUgYWxyZWFkeSByZXNwb25kZWQgYWJvdmUgYWJvdXQgd2hldGhl ciB0aGVyZSBzaG91bGQgYmUgYSB1c2VyCj4gb2YgT0ZfTUZEX0NFTExfUkVHKCkgaW4gdGhlIHBh dGNoIHNldC4KCk5vIG5lZWQsIGFzIGl0J3MgaW5kZW50ZWQgZm9yICpmdXR1cmUqIHVzZXJzLgoK VGhhdCBzYWlkLCBvbmNlIGFwcGxpZWQsIEkgd2lsbCBoYXZlIGEgbG9vayBhcm91bmQgZm9yIHNv bWUgbW9yZQpwb3RlbnRpYWwgY3VycmVudCBpc3N1ZXMvdXNlcnMuICBNeSBwbGFuIGl0IHNvIGFs c28gc3RhcnQgY29udmVydGluZwp1c2VycyB0byBvdGhlciBPRl9NRkRfKiBtYWNyb3MuCgo+ID4g QXMgZmFyIGFzIEkga25vdywgdGhlcmUgYXJlbid0IGFueSBjdXJyZW50IHVzZXJzIHdobyB3b3Vs ZCBiZW5lZml0Cj4gPiBmcm9tIHRoaXMgd29yay4KPiAKPiBTaWdoLiAgRnJvbSB0aGUgb3JpZ2lu YWwgcGF0Y2ggMS8zIGhlYWRlcjoKPiAKPiAgICJDdXJyZW50bHksIHdoZW4gYSBjaGlsZCBwbGF0 Zm9ybSBkZXZpY2UgKHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyBhCj4gICBzdWItZGV2aWNlKSBp cyByZWdpc3RlcmVkIHZpYSB0aGUgTXVsdGktRnVuY3Rpb25hbCBEZXZpY2UgKE1GRCkgQVBJLAo+ ICAgdGhlIGZyYW1ld29yayBhdHRlbXB0cyB0byBtYXRjaCB0aGUgbmV3bHkgcmVnaXN0ZXJlZCBw bGF0Zm9ybSBkZXZpY2UKPiAgIHdpdGggaXRzIGFzc29jaWF0ZWQgRGV2aWNlIFRyZWUgKE9GKSBu b2RlLiAgVW50aWwgbm93LCB0aGUgZGV2aWNlIGhhcwo+ICAgYmVlbiBhbGxvY2F0ZWQgdGhlIGZp cnN0IG5vZGUgZm91bmQgd2l0aCBhbiBpZGVudGljYWwgT0YgY29tcGF0aWJsZQo+ICAgc3RyaW5n LiAgVW5mb3J0dW5hdGVseSwgaWYgdGhlcmUgYXJlLCBzYXkgZm9yIGV4YW1wbGUgJzMnIGRldmlj ZXMKPiAgIHdoaWNoIGFyZSB0byBiZSBoYW5kbGVkIGJ5IHRoZSBzYW1lIGRyaXZlciBhbmQgdGhl cmVmb3JlIGhhdmUgdGhlIHNhbWUKPiAgIGNvbXBhdGlibGUgc3RyaW5nLCBlYWNoIG9mIHRoZW0g d2lsbCBiZSBhbGxvY2F0ZWQgYSBwb2ludGVyIHRvIHRoZQo+ICAgKmZpcnN0KiBub2RlLiIKPiAK PiBUaGlzIGltcGxpZXMgdGhhdCB0aGVyZSBpcyBhIGN1cnJlbnQgaW5zdGFuY2Ugd2hlcmUgbXVs dGlwbGUgZGV2aWNlcwo+IGFyZSAiYWxsb2NhdGVkIGEgcG9pbnRlciB0byB0aGUgKmZpcnN0KiBu b2RlIi4KPiAKPiBJZiB0aGUgcGF0Y2ggaGVhZGVyIGhhZCBpbnN0ZWFkIHNhaWQgc29tZXRoaW5n IGxpa2U6Cj4gCj4gICBhZGRpbmcgdGhlIGFiaWxpdHkgZm9yIGFuIG1mZCBkZXZpY2UgdG8gaGF2 ZSBtdWx0aXBsZSBjaGlsZHJlbgo+ICAgd2l0aCB0aGUgc2FtZSB2YWx1ZSBvZiAiY29tcGF0aWJs ZSIgcHJvcGVydHkKPiAKPiB0aGVuIG15IHdob2xlIGFwcHJvYWNoIHRvIHRyeWluZyB0byBhbmFs eXplIGFuZCB1bmRlcnN0YW5kIHRoZQo+IHBhdGNoIHNlcmllcyB3b3VsZCBoYXZlIGJlZW4gZW50 aXJlbHkgZGlmZmVyZW50LiAgT25lIG9mIG15Cj4gZWFybHkgcmVwbGllcyBkZXNjcmliZWQgbXkg YXR0ZW1wdCB0byBmaW5kIHRoZSBjb2RlIHRoYXQgd2FzCj4gZW5jb3VudGVyaW5nIHRoZSBwcm9i bGVtIHRoYXQgdGhlIHBhdGNoIHNlcmllcyBjbGFpbWVkIHRvIGZpeC4KPiBPbmUgb2YgbXkgY29u Y2VybnMgd2FzIGhhbmRsaW5nIHBvdGVudGlhbCBjb21wYXRpYmlsaXR5IGlzc3Vlcwo+IHdpdGgg ZXhpc3RpbmcgRkRUcy4KPiAKPiBBbmQgbXkgdW5kZXJzdGFuZGluZyBvZiB5b3VyIHJlc3BvbnNl IHRvIG15IGFuYWx5c2lzIGFuZCBpbnZlc3RpZ2F0aW9uCj4gd2FzIHRoYXQgSSBoYWQgaW5kZWVk IGZvdW5kIGEgcHJvYmxlbSBjYXNlIGluIGV4aXN0aW5nIGNvZGUuICBCdXQgbm93Cj4geW91IHRl bGwgbWUgdGhhdCB0aGUgZHJpdmVyIGFuZCBtZmQgY2hpbGQgbm9kZSBjb21wYXRpYmxlIHZhbHVl IHRoYXQKPiBJIGlkZW50aWZpZWQgYXJlIG5vdCBhdCBhbGwgYSBwcm9ibGVtLgoKQWdhaW4sIEkn bSBzb3JyeSB0aGF0IHlvdSB0b29rIHRoYXQgcGF0aCwgYnV0IG15IHJlcGxpZXMgaGF2ZSBvbmx5 CmNvbnZleWVkIHRoZSBmYWN0cyBhcyBJIHNlZSB0aGVtLiAgVGhlIHNuaXBwZXQgdGhhdCB5b3Ug cXVvdGUgYWJvdmUKd2FzIGFuZCBpcyBzdGlsbCBhbiBhY2N1cmF0ZSBhbmQgcHJlY2lzZSBkZXNj cmlwdGlvbiBvZiB0aGUgaXNzdWUgd2l0aAp0aGUgY3VycmVudCBtYXRjaGluZyBjb2RlLgoKTWF5 YmUgbm93IHRoYXQgeW91IGhhdmUgaWRlbnRpZmllZCB5b3VyIGlzc3VlLCB3ZSBjYW4gbW92ZSBv bi4KCj4gPiBJbnN0ZWFkLCBpdCBpcyBkZXNpZ25lZCB0byBwcm92aWRlIGZ1dHVyZSBzdWJtaXR0 ZXJzCj4gPiB3aXRoIGFub3RoZXIgdG9vbCB0byBoZWxwIHRoZW0gbGluayB0aGVpciBjaGlsZCBk ZXZpY2VzIHRvIHRoZSBjb3JyZWN0Cj4gPiBPRiBub2Rlcy4KPiAKPiBBbmQgdGhhdCBpcyB3aGF0 IEkgd2FzIGxvb2tpbmcgZm9yIGFib3ZlIGluIHRoaXMgcmVwbHksIGxvb2tpbmcgZm9yCj4gYSB1 c2VyIG9mIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSBpbiB0aGUgcGF0Y2ggc2VyaWVzLCB3aGVyZSBJ IHN0YXRlZDoKPiAKPiAgICAiT3IgYXQgbGVhc3QgYSBtZW50aW9uIG9mIGEgc3BlY2lmaWMgcGxh biB0bwo+ICAgIHVzZSB0aGUgZnVuY3Rpb25hbGl0eS4iCgpPbmUgbW9yZSB0aW1lOyB0aGlzIHBh dGNoLXNldCBhZGRyZXNzZXMgYW4gcHJlc2VudCBpbi1rZXJuZWwgaXNzdWUuCgpUaGUgY3VycmVu dCBjb2RlIGRvZXMgaXQncyBiZXN0IHRvIG1hdGNoIGRldmljZSB3aXRoIE9GIG5vZGUsIGJ1dAp0 aGVyZSBhcmUgY29ybmVyLWNhc2VzIHdoZXJlIHRoZSBtYXRjaGluZyBzZW1hbnRpY3MgYXJlIG5v dApzdWZmaWNpZW50LiAgRXZlbiBpZiB0aGVyZSB3ZXJlbid0IGFueSBwcm9zcGVjdGl2ZSB1c2Vy cyAoYnV0IHRoZXJlCmFyZSksIGltcHJvdmluZyB0aGUgY3VycmVudCBtYXRjaGluZyBsb2dpYyBp cyBzb21ldGhpbmcgdGhhdCAqbXVzdCogYmUKc2VlbiBhcyBhIHBvc2l0aXZlIHN0ZXAgaW4gdGhl IHJpZ2h0IGRpcmVjdGlvbi4KCklmIHRoaXMgY29kZSB3YXMgYWxyZWFkeSBwcmVzZW50IHdoZW4g J2FiODUwMC1wd20nIHdhcyBPRiBlbmFibGVkLCBpdAp3b3VsZCBoYXZlIGlkZW50aWZpZWQgdGhl IHBvdGVudGlhbCBpc3N1ZSB3aGljaCB5b3UgKGFuZCBNaWNoYWVsKQpjb3JyZWN0bHkgaWRlbnRp ZmllZCB3aXRoIG1pc3NpbmcgT0Ygbm9kZXMuCgo+ID4gVGhhdCdzIG5vdCB0byBzYXkgdGhhdCBj dXJyZW50IHVzZXJzIGNhbid0IGFuZCB3b24ndAo+ID4gYmVuZWZpdCBmcm9tIHRoaXMuICBKdXN0 IHRoYXQgdGhleSBhcmUgbm90IHRoZSB0YXJnZXQgYXVkaWVuY2UuCj4gPiAKPiA+Pj4+PiBUaGUg YWJvdmUgYWN0dWFsbHkgbWFrZXMgdGhlIHNvbHV0aW9uIHdvcnNlLCBub3QgYmV0dGVyLgo+ID4+ Pj4+Cj4gPj4+Pgo+ID4+Pj4gUGF0Y2ggMS8zIHNpbGVudGx5IGZhaWxzIHRvIGRlYWwgd2l0aCBh IGJyb2tlbiBkZXZpY2V0cmVlLgo+ID4+Pj4gSXQgcmVzdWx0cyBvbiBvbmUgb2YgdGhlIHRocmVl IGFiODUwMC1wd20gY2hpbGQgbm9kZXMgaW4KPiA+Pj4+IHRoZSBoeXBvdGhldGljYWwgZGV2aWNl dHJlZSBzb3VyY2UgdHJlZSBub3QgYmVpbmcgYWRkZWQuCj4gPj4+Pgo+ID4+Pj4gVGhhdCBpcyBu b3QgYSBnb29kIHJlc3VsdCBlaXRoZXIuCj4gPj4+Cj4gPj4+IE5vIGl0IGRvZXNuJ3QuICBJbiB0 aGUgY2FzZSBvZiAnYWI4NTAwLXB3bScgdGhlIE9GIG5vZGUgaXMgbm90IHNldCBmb3IKPiA+Pj4g MiBvZiB0aGUgZGV2aWNlcyBhbmQgd2FybmluZ3MgYXJlIHByZXNlbnRlZCBpbiB0aGUga2VybmVs IGxvZy4KPiA+Pgo+ID4+IE9LLCBJIHdhcyB3cm9uZyBhYm91dCAic2lsZW50Ii4gIFRoZXJlIGlz IGEgd2FybmluZzoKPiA+PiAgICBwcl93YXJuKCIlczogRmFpbGVkIHRvIGxvY2F0ZSBvZl9ub2Rl IFtpZDogJWRdXG4iLAo+ID4+Cj4gPj4+IFRoZQo+ID4+PiBkZXZpY2Ugd2lsbCBjb250aW51ZSB0 byBwcm9iZSBhbmQgZnVuY3Rpb24gYXMgdXN1YWwuCj4gPj4KPiA+PiBJZiB0aGUgZGV2aWNlIHBy b2JlcyBhbmQgZnVuY3Rpb25zIGFzIHVzdWFsIHdpdGhvdXQgdGhlIGNoaWxkIG9mX25vZGUsCj4g Pj4gdGhlbiB3aHkgZG9lcyB0aGUgbm9kZSBoYXZlIGFueSBwcm9wZXJ0aWVzIChmb3IgdGhlIGNh c2VzIG9mCj4gPj4gYXJjaC9hcm0vYm9vdC9kdHMvc3RlLWFiODUwMC5kdHNpIGFuZCBhcmNoL2Fy bS9ib290L2R0cy9zdGUtYWI4NTA1LmR0c2kKPiA+PiB0aGUgcHJvcGVydGllcyAiY2xvY2tzIiBh bmQgImNsb2NrLW5hbWVzIikuCj4gPiAKPiA+IEJlY2F1c2UgRFQgaXMgbWVhbnQgdG8gZGVzY3Jp YmUgdGhlIGhhcmR3YXJlLCBub3QgdGhlIGltcGxlbWVudGF0aW9uLgo+ID4gCj4gPiBEVCBkb2Vz IG5vdCBrbm93LCBvciBjYXJlIHRoYXQgaW4gb3VyIGNhc2UgbW9zdCBvcGVyYXRpb25zIHRoYXQg aGFwcGVuCj4gPiBvbiB0aGUgcGxhdGZvcm0gYXJlIHBhc3NlZCBiYWNrIHZpYSBhbiBBUEkgdG8g YSBjZW50cmFsIGNvbnRyb2xsaW5nCj4gPiBsb2NhdGlvbi4gIE9yIHRoYXQgaW4gcmVhbGl0eSwg dGhlIE9GIG5vZGUgaW4gdGhpcyBzaXR1YXRpb24gaXMKPiA+IHN1cGVyZmx1b3VzLgo+ID4gCj4g PiBDYW4gd2UgcGxlYXNlIHN0b3AgdGFsa2luZyBhYm91dCB0aGUgQUI4NTAwLiAgSXQgZG9lc24n dCBoYXZlIGFueXRoaW5nCj4gPiB0byBkbyB3aXRoIHRoaXMgc2VyaWVzIGJlc2lkZXMgdGhlIGZh Y3QgdGhhdCBpZiBpdCAodGhpcyBzZXQpIGhhZAo+ID4gZXhpc3RlZCAqYmVmb3JlKiAnYWI4NTAw LXB3bScgd2FzIE9GIGVuYWJsZWQsIGl0IHdvdWxkbid0IG5vdyBiZQo+ID4gd29ua3kuCj4gCj4g T0suICBJIG5vdyB1bmRlcnN0YW5kIHRoYXQgeW91IGRvbid0IGV4cGVjdCB0aGUgbmV3IGZ1bmN0 aW9uYWxpdHkgb2YKPiB0aGUgb2ZfcmVnIGFuZCB1c2Vfb2ZfcmVnIGZpZWxkcyBvZiBzdHJ1Y3Qg bWZkX2NlbGwgdG8gYmUgdXNlZCBieQo+IGluIHJlbGF0aW9uIHRvICJhYjg1MDAtcHdtIiBhbmQg ZHJpdmVycy9tZmQvYWI4NTAwLWNvcmUuYy4gIEkgd2lsbAo+IGRyb3AgdGhlbSBmcm9tIHRoZSBk aXNjdXNzaW9uLgoKXG8vCgo+ID4+IERpZ2dpbmcgdGhyb3VnaCB0aGF0IGxlYWRzIHRvIHlldCBh bm90aGVyIHJlbGF0ZWQgcXVlc3Rpb24sIG9yIGFjdHVhbGx5Cj4gPj4gc29ydCBvZiB0aGUgc2Ft ZSBxdWVzdGlvbi4gIFdoeSBkbyB0aGUgY2hpbGQgbm9kZXMgd2l0aCBjb21wYXRpYmxlCj4gPj4g InN0ZXJpY3Nzb24sYWI4NTAwLXB3bSIgaGF2ZSB0aGUgcHJvcGVydGllcyAiY2xvY2tzIiBhbmQg ImNsb2NrLW5hbWVzIgo+ID4+IHNpbmNlIHRoZSBiaW5kaW5nIERvY3VtZW50YXRpb24vZGV2aWNl dHJlZS9iaW5kaW5ncy9tZmQvYWI4NTAwLnR4dAo+ID4+IGRvZXMgbm90IGxpc3QgdGhlbT8KPiA+ IAo+ID4gSWYgeW91IHdhbnQgdG8gdGFsayBhYm91dCB0aGUgQUI4NTAwLCBwbGVhc2Ugc3RhcnQg YSBuZXcgdGhyZWFkLgo+ID4gCj4gPj4+PiBPSywgc28gbXkgc29sdXRpb24gIzMgaXMgYSBubyBn by4gIEhvdyBhYm91dCBteSBzb2x1dGlvbiAjMiwKPiA+Pj4+IHdoaWNoIHlvdSBkaWQgbm90IGNv bW1lbnQgb24/Cj4gPj4+Cj4gPj4+IEkgZGlkIFswXS4gIFlvdSBtdXN0IGhhdmUgbWlzc2VkIGl0 LiA6KQo+ID4+Cj4gCj4gPj4gQnV0IHllcyBvciBubyB0byBteSBzb2x1dGlvbiAjMiAod2l0aCBz b21lIHNsaWdodCBjaGFuZ2VzIHRvCj4gPj4gbWFrZSBpdCBiZXR0ZXIgKG1vcmUgZ3JhY2lvdXMg aGFuZGxpbmcgb2YgdGhlIGRldGVjdGVkIGVycm9yKSBhcwo+ID4+IGRpc2N1c3NlZCBlbHNld2hl cmUgaW4gdGhlIGVtYWlsIHRocmVhZCk/Cj4gPiAKPiA+IFBsZWFzZSBzZWUgIlswXSIgYWJvdmUh Cj4gPiAKPiA+IEFGQUlDVCB5b3VyIHNvbHV0aW9uICMyIGludm9sdmVzIGJvbWJpbmcgb3V0ICph bGwqIGRldmljZXMgaWYgdGhlcmUgaXMKPiA+IGEgZHVwbGljYXRlIGNvbXBhdGlibGUgd2l0aCBu byAncmVnJyBwcm9wZXJ0eSB2YWx1ZS4gIFRoaXMgaXMgYSkKPiA+IG92ZXIta2lsbCBhbmQgYikg bm90IGFuIGVycm9yLCBhcyBJIG1lbnRpb25lZDoKPiAKPiBBcyBJIG1lbnRpb25lZCBhYm92ZSwg SSBzZXQgeW91IHVwIHRvIGhhdmUgdGhpcyBtaXN1bmRlcnN0YW5kaW5nIGJ5Cj4gYSBtaXN0YWtl IGluIG9uZSBvZiBteSBlYXJsaWVyIGVtYWlscy4gIFNvIG5vdyB0aGF0IEkgaGF2ZSBwb2ludGVk Cj4gb3V0IHdoYXQgSSBtZWFudCBoZXJlIGJ5ICJtb3JlIGdyYWNpb3VzIGhhbmRsaW5nIG9mIHRo ZSBkZXRlY3RlZAo+IGVycm9yIiwgd2hhdCBkbyB5b3UgdGhpbmsgb2YgbXkgYW1lbmRlZCBzb2x1 dGlvbiAjMj8KCkV4cGxhaW5lZCBhYm92ZSwgYnV0IHRoZSBMVDtEUiBpcyB0aGF0IGl0J3Mgbm90 IGNvcnJlY3QuCgo+ID4+PiBJdCBhbHNvIHN1ZmZlcnMgd2l0aCBmYWxzZSBwb3NpdGl2ZXMuCj4g PiAKPiAKPiBTb3JyeSBmb3IgdGhlIHZlcnkgbG9uZyByZXNwb25zZSwgYnV0IGl0IHNlZW1lZCB3 ZSB3ZXJlIG9wZXJhdGluZwo+IHVuZGVyIHNvbWUgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmdzIGFu ZCBJIGhvcGUgSSBoYXZlIGNsYXJpZmllZCBzb21lCj4gdGhpbmdzLgoKTGlrZXdpc2UuIDopCgot LSAKTGVlIEpvbmVzIFvmnY7nkLzmlq9dClNlbmlvciBUZWNobmljYWwgTGVhZCAtIERldmVsb3Bl ciBTZXJ2aWNlcwpMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQXJtIFNv Q3MKRm9sbG93IExpbmFybzogRmFjZWJvb2sgfCBUd2l0dGVyIHwgQmxvZwoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWls aW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 E4346C433E0 for ; Wed, 24 Jun 2020 07:46:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD22120768 for ; Wed, 24 Jun 2020 07:46:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lxrNaQhU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390148AbgFXHqi (ORCPT ); Wed, 24 Jun 2020 03:46:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389948AbgFXHqh (ORCPT ); Wed, 24 Jun 2020 03:46:37 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0943C061573 for ; Wed, 24 Jun 2020 00:46:35 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id f18so1531856wml.3 for ; Wed, 24 Jun 2020 00:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=epcuiGqVlmnY4nv0TpcFlJgIf53mrnQAjcQ2iWd8n20=; b=lxrNaQhURYbDOacetuAOB4rqihVjeFhPrFku/MctijJgTEB6swEolAYoXWCGDNjxfe Wqs5E39Z4cE5O8xnsPvjSQnheb8F7BeqLBrQXIDuYGW4zsGKcuaDlr79IHoHHGXa+lbr /s+ASmZCc2IP0khedmhvjUqUCjQrxrzXPqV4zNwdvVqM8NLJtk/d9wM3+8BaPdzCZTQi 6XscRwZ6rn9V4IGRq1poGAG1quK8yg9jVg204Ty4mC08Aswn2wjZZ0+4xJ4jo19C+9mA pAJ1NH/0KfUJ3tGf39JUt91YqNjjMP0dKcNOa9evgsbCCbiT1NuvKltfInrj9egcbCG6 H5IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=epcuiGqVlmnY4nv0TpcFlJgIf53mrnQAjcQ2iWd8n20=; b=hoGMigoLu41uHfSISGEucq5acUyEaFYkweVlmcfSD3T90cu6kZ6yhJnUEiaWqe9NVm dKCDeyf1MdQYXJej4LG8oZBUAqx2JrY4IoQqHvSU8NisH0NaA1z8ZfJByrP+nb6l4oyY D5cmLIWPDKe73SVAs2mED6Obz3KcyC92qmT+8AM/BoGfunsVX0LfJuzcEKEyXbhh2PU1 hkwgkxbD4lmEUxkB0QdXwJiZI2tz0VRwMEACvRgbQjMuA1WdmLHkzMynMynNQrVJoVr5 +NvycFrfR4r+CLZYohYM/W+wSRQ+VnDiI5KJ7zaY6Sd7DFGwWxdGkLIcCLRS/2uqkFuw ahIw== X-Gm-Message-State: AOAM530JRxfCN5pM4XYOWmjMsWnrE0Me7rZjZPxp0ClUITDWMrFhdMRJ /DMad61I9zGFlepUf0HKGK4nhw== X-Google-Smtp-Source: ABdhPJwABrQgNhzh+ctnmNgoeNQCk2WyukwHXPTFPW0rrC3LNFzgwwXryqZIsCHShyMS5hYSJyHmHw== X-Received: by 2002:a1c:3bc2:: with SMTP id i185mr29006254wma.33.1592984794170; Wed, 24 Jun 2020 00:46:34 -0700 (PDT) Received: from dell ([2.27.35.144]) by smtp.gmail.com with ESMTPSA id x14sm25926377wrt.60.2020.06.24.00.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 00:46:33 -0700 (PDT) Date: Wed, 24 Jun 2020 08:46:31 +0100 From: Lee Jones To: Frank Rowand Cc: andy.shevchenko@gmail.com, michael@walle.cc, robh+dt@kernel.org, broonie@kernel.org, devicetree@vger.kernel.org, linus.walleij@linaro.org, linux@roeck-us.net, andriy.shevchenko@linux.intel.com, robin.murphy@arm.com, gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes Message-ID: <20200624074631.GE954398@dell> References: <20200622085009.GP954398@dell> <20200622151054.GW954398@dell> <037c0fd2-df35-5981-7ef2-c6199841650d@gmail.com> <20200622191133.GY954398@dell> <20200623064723.GZ954398@dell> <83f2be78-1548-fa2b-199a-2391b2eceb47@gmail.com> <20200623195905.GB954398@dell> <6684101d-1013-2964-c247-394f9b12a194@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6684101d-1013-2964-c247-394f9b12a194@gmail.com> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 23 Jun 2020, Frank Rowand wrote: > On 2020-06-23 14:59, Lee Jones wrote: > > Suggestion #2 > > > >>>>>> 2) Modify patch 1/3. The small part of the patch to modify is: > >>>>>> > >>>>>> +static int mfd_match_of_node_to_dev(struct platform_device *pdev, > >>>>>> + struct device_node *np, > >>>>>> + const struct mfd_cell *cell) > >>>>>> +{ > >>>>>> + struct mfd_of_node_entry *of_entry; > >>>>>> + const __be32 *reg; > >>>>>> + u64 of_node_addr; > >>>>>> + > >>>>>> + /* Skip devices 'disabled' by Device Tree */ > >>>>>> + if (!of_device_is_available(np)) > >>>>>> + return -ENODEV; > >>>>>> + > >>>>>> + /* Skip if OF node has previously been allocated to a device */ > >>>>>> + list_for_each_entry(of_entry, &mfd_of_node_list, list) > >>>>>> > >>>>>> Change: > >>>>>> > >>>>>> + if (of_entry->np == np) > >>>>>> + return -EAGAIN; > >>>>>> > >>>>>> To: > >>>>>> > >>>>>> + if (of_entry->np == np) { > >>>>>> + if (!cell->use_of_reg) > >>>>>> + return -EINVAL; > >>>>>> + else > >>>>>> + return -EAGAIN; > >>>>>> > >>>>>> There may be a better choice than EINVAL, but I am just showing the method. > >>>>>> > >>>>>> You may also want to refactor this section of the patch slightly > >>>>>> differently to achieve the same result. It was just easiest to > >>>>>> show the suggested change the way I did it. > >>>>>> > >>>>>> The test that returns EINVAL detects the issue that the FDT does > >>>>>> not match the binding (there is more one child node with the > >>>>>> "stericsson,ab8500-pwm" compatible. > > > > My reply to suggestion #2 > > > >>>>> So here, instead of just failing a single device, we fail everything? > >>>>> Sounds a lot like throwing the baby out with the bath water. How is > >>>>> that an improvement? > > I could have sworn that I had replied with a solution to this issue. So I > searched and searched and searched my emails in the thread. And checked my > drafts email folder. Then finally realized I had made a stupid mistake. > > I did reply about this, but I had put my "-Frank" signature at the end > of a comment much higher in the email. So of course I expect you stopped > reading at that point and never saw my answer. My apologies!!! > > The email in question is: > > https://lore.kernel.org/linux-devicetree/eae9cc00-e67a-cb6a-37c2-f2235782ed77@gmail.com/ > > and what I wrote at this point in that email is: > > You can modify more extensively than my simple example, changing > mfd_add_device() to more gracefully handle an EINVAL returned by > mfd_match_of_node_to_dev(). > > Thus a modification to my suggestion #2 to make it _not_ fail > everything. > > I didn't really flesh out all that "more gracefully handle" means. > Among other things, it could include a pr_warn() that provides > a fairly specific possible cause of the problem (eg the corner > case mentioned near the end of the patch 1/3 header that shows > mixing OF_MFD_CELL() and OF_MFD_CELL_REG() for the same compatible > value. It may be tricky coming up with good phrasing in a pr_warn() > that describes the generic issue instead of the specific example. The current solution already provides a warning if we fail to match a device with its requested OF node. It's also semantically incorrect to error out just because a node with the same compatible string is already taken, since there maybe another one coming up (which will be found on the next iteration post return of -EAGAIN). Providing a more accurate warning describing *why* a node wasn't found it also non-trivial, for the same reasons as it's hard to do during a pre-validation routine. > >>> [0] > >> > >> Is "[0]" the patch series, especially patch 1/3? > > > > No, this is my reply to your suggestion #2. > > > > The [0] is referenced further down. > > > > [...] > > > >>>>> * False positives can occur and will fail as a result > >>>> > >>>> ((What is an example of a false positive?)) Never mind, now that > >>>> I see that the previous issue is a fatal flaw, this becomes > >>>> academic. > >>> > >>> That's okay, I don't mind discussing. > >>> > >>> Ironically, the 'ab8500-pwm' is a good example of a false positive, > >>> since it's fine for the DT nodes to be identical. So long as there > >>> are nodes present for each instance, it doesn't matter which one is > >>> allocated to which device .Forcing a 'reg' property onto them for no> good reason it not a valid solution here. > >> > > Start of my comment that I wrote with "too many shortcuts" (see below): > > >> I thought that one of the points of this patch series was to add a > >> "reg" property to any mfd child that was described by the > >> OF_MFD_CELL_REG() macro. > > > > The OF_MFD_CELL_REG() macro didn't exist until this patch-set. > > > Maybe the way I wrote that took too many shortcuts. Let me re-phrase. > > I thought that one of the points of this patch set was to add the > of_reg and use_of_reg fields to struct mfd_cell. The expected use > of the of_reg and use_of_reg fields was to allow the presence of a > "reg" property in a devicetree mfd child node to be used to match > specific child nodes to specific elements of the mfd_add_devices() > cell array parameter, with the match occurring when the array elements > are processed (currently in mfd_match_of_node_to_dev(), which is > called by mfd_add_device()). > > The key point being the matching specific devicetree mfd child nodes > to specific cell array members. > > The OF_MFD_CELL_REG() is simply a helper macro related to the above. Correct so far. > > There are currently no users. > > Yes. And as I pointed out elsewhere, I would expect a user of new > functionality to be added as part of a patch series that adds the > new functionality. Or at least a mention of a specific plan to > use the functionality. There have been 2 such use-cases in recent months. The most recent is Michael's (CC'ed) use-case. Moreover, this patch-set actually fixes something that has been known to be broken (actually not broken per-say, just 'less featureful') for a number of years. Since the original support was authored, only 2 potential issues have arisen. The first time we deemed it a problem too complex to fix (I can't, for the life of me find that thread, but I'm pretty sure it involved Robin from Arm [which is why he is CC'ed]). Michael's use-case is the second. This time I thought I'd have a stab at fixing (or at least bettering) it. > I had been assuming that the intended user was the one use case that > I had identified, and that you let me continue to assume was the one > existing use case. Sorry if you feel misled, but that is not the case. > >> And that was meant to fix the problem where multiple indistinguishable > >> children existed. The only instance I found of that (using the > >> weak search on OF_MFD_CELL()) was of compatible "stericsson,ab8500-pwm" > >> in drivers/mfd/ab8500-core.c. You agreed with my email that > >> reported that. > > > > No, I agreed with you that there is a current problem with > > "stericsson,ab8500-pwm", as identified by Michael. I didn't actually > > know about this issue until *after* drafting this patch-set. To be > > clear the "stericsson,ab8500-pwm" scenario is not the reason for this > > set's existence. > > So now I know that drivers/mfd/ab8500-core.c is totally unrelated to > this patch series, and not the intended user of the new functionality. > > > > > Also, please forget about the OF_MFD_* macros, they are totally > > agnostic to this effort. The only relevance they have here is the > > addition of 1 extra macro which *could* be used to provide the 'reg' > > property where appropriate. > > My point was that my search for the data that comprised the "cell" > parameter passed to mfd_add_devices() was inadequate, because I > was searching on OF_MFD_CELL() instead of mfd_add_devices. I was > admitting that part of my ignorance was because of this poor search. > > I was searching for where the problem case actually occurred in the > kernel. Maybe you did not realize that I have been thinking that > the only place where the problem case occurred was the single case > I found with this insufficient search method. > > In some or many or all (I don't know, I'm not going to go back > and search for all of them) you can probably replace mention > of the OF_MFD_* with either my search for input data to > mfd_add_devices() _or_ a concise reference to the new of_reg > and use_of_reg fields of struct mfd_cell and the use of the > new fields. > > Where is the problem that the patch set was intended to fix? Firstly, the problem is present, as described in the commit message. It is *not correct to re-match an OF node with multiple devices. Even if there wasn't a current *real* user, this patch is still the right thing to do, as it makes the situation *sooo* much better. However, there is a prospective user also [1]. [1] https://lore.kernel.org/linux-arm-kernel/20200423174543.17161-1-michael@walle.cc/ > >> So I thought that drivers/mfd/ab8500-core.c would be modified to > >> replace the multiple instances of compatible "stericsson,ab8500-pwm" > >> in OF_MFD_CELL() with OF_MFD_CELL_REG(). > > > > That is not my vision. There is no need for "stericsson,ab8500-pwm" > > to have 'reg' properties as far as I see it. > > In that case the binding document for the mfd child node with > compatible "stericsson,ab8500-pwm" should be updated to state > that if there are multiple such child nodes with the same parent > then they must contain exactly the same set of properties and > values. > > Maybe not your problem, I have no idea who is responsible for > that update. This is the case for all OF nodes, not just 'ab8500-pwm'. Fell free to submit a patch. > However, > > >> This is another problem with the patch series: there is no user > >> of OF_MFD_CELL_REG(). Please add one to the series. > > > > That's not a problem with this patch-set, it's a problem with your > > understanding of this patch-set. :) > > I have already responded above about whether there should be a user > of OF_MFD_CELL_REG() in the patch set. No need, as it's indented for *future* users. That said, once applied, I will have a look around for some more potential current issues/users. My plan it so also start converting users to other OF_MFD_* macros. > > As far as I know, there aren't any current users who would benefit > > from this work. > > Sigh. From the original patch 1/3 header: > > "Currently, when a child platform device (sometimes referred to as a > sub-device) is registered via the Multi-Functional Device (MFD) API, > the framework attempts to match the newly registered platform device > with its associated Device Tree (OF) node. Until now, the device has > been allocated the first node found with an identical OF compatible > string. Unfortunately, if there are, say for example '3' devices > which are to be handled by the same driver and therefore have the same > compatible string, each of them will be allocated a pointer to the > *first* node." > > This implies that there is a current instance where multiple devices > are "allocated a pointer to the *first* node". > > If the patch header had instead said something like: > > adding the ability for an mfd device to have multiple children > with the same value of "compatible" property > > then my whole approach to trying to analyze and understand the > patch series would have been entirely different. One of my > early replies described my attempt to find the code that was > encountering the problem that the patch series claimed to fix. > One of my concerns was handling potential compatibility issues > with existing FDTs. > > And my understanding of your response to my analysis and investigation > was that I had indeed found a problem case in existing code. But now > you tell me that the driver and mfd child node compatible value that > I identified are not at all a problem. Again, I'm sorry that you took that path, but my replies have only conveyed the facts as I see them. The snippet that you quote above was and is still an accurate and precise description of the issue with the current matching code. Maybe now that you have identified your issue, we can move on. > > Instead, it is designed to provide future submitters > > with another tool to help them link their child devices to the correct > > OF nodes. > > And that is what I was looking for above in this reply, looking for > a user of the new functionality in the patch series, where I stated: > > "Or at least a mention of a specific plan to > use the functionality." One more time; this patch-set addresses an present in-kernel issue. The current code does it's best to match device with OF node, but there are corner-cases where the matching semantics are not sufficient. Even if there weren't any prospective users (but there are), improving the current matching logic is something that *must* be seen as a positive step in the right direction. If this code was already present when 'ab8500-pwm' was OF enabled, it would have identified the potential issue which you (and Michael) correctly identified with missing OF nodes. > > That's not to say that current users can't and won't > > benefit from this. Just that they are not the target audience. > > > >>>>> The above actually makes the solution worse, not better. > >>>>> > >>>> > >>>> Patch 1/3 silently fails to deal with a broken devicetree. > >>>> It results on one of the three ab8500-pwm child nodes in > >>>> the hypothetical devicetree source tree not being added. > >>>> > >>>> That is not a good result either. > >>> > >>> No it doesn't. In the case of 'ab8500-pwm' the OF node is not set for > >>> 2 of the devices and warnings are presented in the kernel log. > >> > >> OK, I was wrong about "silent". There is a warning: > >> pr_warn("%s: Failed to locate of_node [id: %d]\n", > >> > >>> The > >>> device will continue to probe and function as usual. > >> > >> If the device probes and functions as usual without the child of_node, > >> then why does the node have any properties (for the cases of > >> arch/arm/boot/dts/ste-ab8500.dtsi and arch/arm/boot/dts/ste-ab8505.dtsi > >> the properties "clocks" and "clock-names"). > > > > Because DT is meant to describe the hardware, not the implementation. > > > > DT does not know, or care that in our case most operations that happen > > on the platform are passed back via an API to a central controlling > > location. Or that in reality, the OF node in this situation is > > superfluous. > > > > Can we please stop talking about the AB8500. It doesn't have anything > > to do with this series besides the fact that if it (this set) had > > existed *before* 'ab8500-pwm' was OF enabled, it wouldn't now be > > wonky. > > OK. I now understand that you don't expect the new functionality of > the of_reg and use_of_reg fields of struct mfd_cell to be used by > in relation to "ab8500-pwm" and drivers/mfd/ab8500-core.c. I will > drop them from the discussion. \o/ > >> Digging through that leads to yet another related question, or actually > >> sort of the same question. Why do the child nodes with compatible > >> "stericsson,ab8500-pwm" have the properties "clocks" and "clock-names" > >> since the binding Documentation/devicetree/bindings/mfd/ab8500.txt > >> does not list them? > > > > If you want to talk about the AB8500, please start a new thread. > > > >>>> OK, so my solution #3 is a no go. How about my solution #2, > >>>> which you did not comment on? > >>> > >>> I did [0]. You must have missed it. :) > >> > > >> But yes or no to my solution #2 (with some slight changes to > >> make it better (more gracious handling of the detected error) as > >> discussed elsewhere in the email thread)? > > > > Please see "[0]" above! > > > > AFAICT your solution #2 involves bombing out *all* devices if there is > > a duplicate compatible with no 'reg' property value. This is a) > > over-kill and b) not an error, as I mentioned: > > As I mentioned above, I set you up to have this misunderstanding by > a mistake in one of my earlier emails. So now that I have pointed > out what I meant here by "more gracious handling of the detected > error", what do you think of my amended solution #2? Explained above, but the LT;DR is that it's not correct. > >>> It also suffers with false positives. > > > > Sorry for the very long response, but it seemed we were operating > under some different understandings and I hope I have clarified some > things. Likewise. :) -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog