On Wed, 15 Aug 2018 10:39:13 +0100
Will Deacon [off-list ref] wrote:

On Tue, Aug 14, 2018 at 01:42:27PM -0600, Mathieu Poirier wrote:

quoted

On Tue, 14 Aug 2018 at 11:09, Kim Phillips [off-list ref] wrote:

quoted

The other thing that's going on here is that I'm becoming numb to the
loathsome "failed to mmap with 12 (Cannot allocate memory)" being
returned no matter what the error is/was. E.g., an error that would
indicate a sense of non-implementation would be much better
appreciated than presumably what the above is doing, i.e., returning
-ENOMEM.  That, backed up with specific details in the form of human
readable text in dmesg would be *most* welcome.

As part of the refactoring of the code to support CPU-wide scenarios I
intend to emit better diagnostic messages from the driver.  Modifying
rb_alloc_aux() to propagate the error message generated by the
architecture specific PMUs doesn't look hard either and I _may_ get to
it as part of this work.

For the record, I will continue to oppose PMU drivers that dump diagnostics
about user-controlled input into dmesg, but the coresight drivers are yours
so it's up to you and I won't get in the way!

That sounds technically self-contradicting to me.  Why shouldn't
coresight share the same policies as those used for PMU drivers?  Or
why not allow the individual vendor PMU driver authors control the
level of user-friendliness of their own drivers?

That being said, Matheiu, would you accept patches that make coresight
more verbose in dmesg?

Kim