On Tue, Apr 07, 2015 at 07:03:30PM +0100, Srinivas Kandagatla wrote:
On 07/04/15 18:46, Mark Brown wrote:
On Tue, Apr 07, 2015 at 06:35:49PM +0100, Srinivas Kandagatla wrote:
On 06/04/15 16:04, Matt Porter wrote:
On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote:
The generic binding could really use a "read-only" property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM
Correct me If am wrong.
Regarding write protection/read-only, regmap already has provisions to
support this feature. regmap would bail out with errors if any attempt to
write to non-writable regions. It all depends on the data providers how they
setup the regmap and the bindings for those are specific individual data
providers I think.
There is the ability to flag read/write permissions in regmap but I
think there's some suggestion that this should be exposed to userspace
so that it's easier for it to handle things rather than just writing
then coping with any errors.
Yes, That's possible if the data provider use the "read-only" generic
binding like MTD partitions which the eeprom framwork could use to set the
binary file mode appropriately.
Right, that's what Rob suggested as to how it should be exposed to
userspace. I think Mark is suggesting that it can also be done by
returning appropriately fine-grained error codes from a writeable
Just to clarify here, I brought this up because if we only allow
the writes to fail, there's not necessarily not enough information
available to know if they failed due to a real error (perhaps write
cycles for the underlying nvmem device have been exhausted) or is
it simply that the underlying device has been hardware write protected
(such as as the write protect pin hardwired that way or it's an OTP
device). The client, whether userspace or otherwise is going to need
to know this information to make informed policy decisions.
"read-only" property seems to be more generic for all types of data
I will give it a try and document this in the bindings too in next version.