On Fri, May 13, 2016 at 03:08:55AM +0000, Scott Wood wrote: > On 05/09/2016 05:29 AM, Mark Brown wrote: > > Yes, if you find bugs in generic frameworks you should fix them rather > > than just open coding something. > That's often true, but using regmap to handle endianness is like > swatting flies with a sledgehammer. Regmap's code is quite (over?) > complicated (e.g. the (user-visible!) difference between > reg_format_endian and val_format_endian is quite confusing) and ideally This is the register map API, not the register API - many buses, including MMIO, have different endiannesses for their values and addresses so of course we need to let users control that. > people who aren't getting actual value from a buggy and/or awkward > subsystem shouldn't be forced to use/fix it. We're not talking about > massive duplication here. We're talking about a set of simple I/O > wrappers (something that many drivers do) with an if-statement. As far as I am aware any issues have been fixed by other users who reported the problems they were seeing (which hasn't happened here). When we encounter problems it is not OK to just bodge around the issue in a driver without reporting them. That doesn't help other users and makes everything more fragile. If there were some history or other indication of real problems here the story would be different but if that's been happening it hasn't ever been communicated. As it is it looks like people have been using the diagnostic tools (max_register is specified) and clock management provided by regmap and the way this has been communicated is causing me concern.
Attachment:
signature.asc
Description: PGP signature
