On Thu, May 03, 2012 at 05:00:40PM +0200, Johan Hovold wrote:
On Thu, May 03, 2012 at 12:38:02PM +0100, Mark Brown wrote:
quoted
This is one of the reasons why we currently use tracepoints (they just
don't have this issue as they're trivial to filter), though
adding some sort of infrastructure for it ought not to be too difficult
even if it's just at the regmap level.
So a /sys/kernel/debug/regmap/<device>/io_printk attribute (with a
better name) to enable debug printks in io paths
(regmap*{read,write,update} outside of mutex) in regmap.c would be
acceptable?
Yes, that'd be totally fine for me - it's debugfs so we can always drop
it later if someone comes up with a better idea or something.
quoted
Actually, the other question I had but forgot to ask (or I think punted
on for your response) was why these are in sysfs at all - things like
which things are connected to the backlight are going to be a property
of the board design so should be defined by the machine not tweaked from
userspace.
I agree with you and the reason is the same as for the max_current
attribute (discussed in the other thread) -- it was an explicit request
from the end customer.
I could replace the boost attributes with a platform_data entry where it
really belongs.
I really think this is much better for mainline.
There is a use case (beyond testing/integration) for keeping the (lvled)
outputs configurable from userspace, in that it provides a way to
synchronise LED activity such as blinking. So I still want to keep those,
at least for the lvleds.
I'm not sure exactly which control that is?