![](https://secure.gravatar.com/avatar/27e13d82e8a3459b0a0f14ebc68ab78a.jpg?s=120&d=mm&r=g)
On 2021-09-20 23:29, Mark Brown wrote:
On Mon, Sep 20, 2021 at 09:37:37PM +0200, Peter Rosin wrote:
compare if the update was needed at all. But marking volatile wasn't enough. I also tried to set both a default and mark as volatile, but it seems every read fails with -16 (EBUSY). I don't get why, to me it almost feels like a regmap issue of some sort (probably the regmap config is bad in some way), but I'm not fluent in regmap...
Having a default for a volatile register isn't really a sensible configuration since the whole point with volatile registers is that they change underneath us, I'd not be surprised if we had some error checking code in there that was trying to tell you there was a problem though it does seem like it should at least be more verbose about it since returning -EBUSY isn't exactly helpful by itself.
I totally agree that it's not a sensible config to set up a register with a default when it's marked as volatile. That was just a wild attempt.
I expected it to just work to mark the register as readable and do without the default value (i.e. the way it was before my patch). What I don't understand is why regmap returns -EBUSY in that case. That doesn't make sense to me. Perhaps that -EBUSY is propagated from the I2C layer, but in that case, why is it then ok to do a write to another register at the same spot in the code? So, why -EBUSY?
Something is going on that is not understood. At least not by me.
Cheers, Peter