Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759106AbbGHU4F (ORCPT ); Wed, 8 Jul 2015 16:56:05 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:59690 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759071AbbGHU4B (ORCPT ); Wed, 8 Jul 2015 16:56:01 -0400 Date: Wed, 8 Jul 2015 22:55:23 +0200 (CEST) From: Stefan Wahren Reply-To: Stefan Wahren To: maitysanchayan@gmail.com Cc: stefan@agner.ch, srinivas.kandagatla@linaro.org, kernel@pengutronix.de, linux-kernel@vger.kernel.org, shawn.guo@linaro.org, maxime.ripard@free-electrons.com, linux-arm-kernel@lists.infradead.org Message-ID: <24856127.49152.1436388923583.JavaMail.open-xchange@oxbsltgw04.schlund.de> In-Reply-To: <20150708053920.GA4089@Sanchayan-Arch.toradex.int> References: <9593ca1f925aff20a6671262efd2f45e256ea676.1435574288.git.maitysanchayan@gmail.com> <1877493336.206622.1436177794342.JavaMail.open-xchange@oxbsltgw01.schlund.de> <20150707051953.GA3712@Sanchayan-Arch.toradex.int> <1488361449.258303.1436273347081.JavaMail.open-xchange@oxbsltgw01.schlund.de> <20150708053920.GA4089@Sanchayan-Arch.toradex.int> Subject: Re: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev18 X-Originating-Client: com.openexchange.ox.gui.dhtml X-Provags-ID: V03:K0:MTCIzIzupE3VB3mG1/xYRj2vDKu5QbAqBgrbKs+EfAcMnKo8iDA 1rPrPpeT/ipwqnbX2J93PQGBCjuH4gxq1y0azZmhqHQxFKT9DDiFeO7dMPRmy53V7EynI5R 6tcum6mAxTuUKA7Hhx5yN6iIcr8GyHLmD8FEa9CyRZFHbOoP9SU+S7FGYM9J9k+EEBqzXIH oQTscqpXAV1to3wP+ueEg== X-UI-Out-Filterresults: notjunk:1;V01:K0:JVKHG5IpqHA=:+TIVR1gzGRLoDLElPBlzv/ C30zU4TcqnX7Pv4OHCRtrIzjINmEfZvRzYo+Lrts+wpvkXKxOJrigB4jcL1pfX7mgxgIWbvWz FAmAsag+Lcq93klvoLuuMplY0cgP+3vvnJATu7EXN3cCHZaG+y3dLvo2AwI/AdtY4RwUs5N6T 1oj6Taf95APaKWtiuBjVVPoitvkxX+vzstwv2/pV7x8aHVytVjabmZq+pf1v+lg1VJLAwcdT0 33vb4srR7AzpK3GIy/o1VPdcf7so/nnZaLTqGQ2PImDwarACf+cS+iDshrP+9mUGgcG25/k31 9uuu69TRfiQwJKXOrjhYUcnymJ6xrYNpcwMpEQOYFnHWtZlecKwuEiW/csilKTo9CsTxjK7EP DjCIVRNUgwD+V/MWpGFM/0UcLdOJJNPFmQD6FoUrqEf/jYqUMwKTbRrGu3xYGbzYNOaiiI8BX XZrrg3R1iBjd9wyh8goOptLSp3cgET9MBuR2wxgSmJ0u8abpE5RUYKhmJqz89zN62HI3wZaf1 JOQGZIZ0yywJsUlOmuQEuFzTte7es5cQNzLrE3m82F6yHoHKdw/u4QmsjeiEyCQ2P7y9yIqca LLQbQzwHmaNrYNYGW8JPrQkiv23a+zIrvBZvEi74+JvBymPGSb1MQefJzGUseks5hZ8eXWBhr TJmX8i7bNqh5C1vA9HAJj/UdvoLvtQFlQ7ESe2K+20U9yRg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2499 Lines: 74 Hi Sanchayan, > maitysanchayan@gmail.com hat am 8. Juli 2015 um 07:39 geschrieben: > > > [...] > > > > > > > > Looking at valid_fuse_addr shows me 0x3F as last valid register. So the > > > > rest > > > > of the buffer ( 0xD00 - sizeof(valid_fuse_addr) ) in case of raw access > > > > could be > > > > uninitializied. > > > > > > Sorry I did not exactly get you here. The intention behind using the > > > valid_fuse_addr > > > is to allow reading only from valid fuse addresses and avoid reading from > > > all > > > other > > > locations as per the Fuse map address table 35-1. > > > > Yes, i got your intention. But from my unterstand the read function should > > fill > > up > > the complete buffer with defined values. My MXS OCOTP driver have the same > > problem > > and fill up the invalid registers with zero. > > I must admit I had not thought of that. Thats a valid point. I dont know at > the > moment however what would be the correct approach here. Perhaps filling > locations > other than the valid fuse addresses as per the fuse map table with 0xBADABADA > is > the right thing? Anyways that's what is going to be returned if we were to > read > a location which is read locked or reserved. since we are operating in userspace the behavior shouldn't be specific to the device. It would be good when all drivers behave the same. But i think it would be much better as the nvmem framework take care of it and preinit the buffer with a defined value. > > However since the fuse address and base address mapping is not exactly linear, > this would require some additional logic than the simple thing I did. I defined a regmap_access_table for valid read registers in my case. But i think in your case an implementation of the readable_reg callback in the regmap_config would be more elegant. You can validate your implementation under /sys/kernel/debug/regmap/ Sorry, i'm a newbie to regmap. Stefan > Also OCOTP requires the fuse address to be written. May be using the nvmem > consumer DT property > gets something?! Not sure atm. > > - Sanchayan. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/