Re: [PATCH 2/2] cxl: Move opcode reporting from dev_dbg() to traceevent

[Ira Weiny <ira.weiny@intel.com>]

Alison Schofield wrote:
> On Fri, Sep 15, 2023 at 01:13:55PM -0700, Dave Jiang wrote:
> > Alison has reported that against certain hardware devices the opcode
> > discovery dev_dbg() can emit several hundred "unsupported by driver"
> > messages while parsing the CEL. Move the emission to traceevent to reduce
> > dmesg spamming and let software parse the output if there are interested
> > parties.
> 
> Thanks for reducing the spew Dave.
> 
> Considering that tracing may or may not be 'on' can we just not
> spew anything at this point - no dev_dbg(), no trace. Let the user
> ask for the opcode list at their leisure, at which time we'd dump
> it to trace log.
> 
> Is there a mechanism in place for user to ask for logs?
> (cxl list -m mem1 'show me my opcodes')
> Barring that, I'm assuming users can do a pass thru of this cmd
> and get whatever they want.
> 
> Counterpoint - is there a subset of opcodes that we'd really like
> to dev_dbg() about at this point in time?  ie missing opcodes that
> are going to make the device useless.

IMO any command which fails and is fatal to the device coming up should
trigger a dev_err() somewhere.

I don't think that is a guarantee currently though.  Even something which
we expect but does not fail the device is IMO a candidate for dev_err()
because it is unexpected behavior.

Does anyone oppose removing the dev_dbg()'s in this series?  Is anyone
looking at the list of opcodes this way?

Ira