On Thu Aug 29, 2024 at 7:17 PM BST, Stephen Boyd wrote:

Quoting Greg Kroah-Hartman (2024-08-28 00:10:46)

quoted

On Tue, Aug 27, 2024 at 04:40:52PM -0700, Stephen Boyd wrote:

quoted

Quoting Harry Austen (2024-08-27 12:08:52)

quoted

On Mon Aug 26, 2024 at 2:11 PM BST, Greg Kroah-Hartman wrote:

quoted

Why do you want a UIO api for a clock device?  What userspace code is
going to access the hardware this way?  Why not use the normal
kernel/user apis instead?

I was just trying to provide userspace access to these _unexpected_ clock
status event indications (clock stopped, underrun, overrun or glitched) and UIO

That is going to be a brand-new user/kernel api that isn't documented
anywhere and will be unique to this one device.  Please don't do that.

quoted

Maybe unexpected events can be indicated through the EDAC subsystem,
except that is usually about memory or cache errors, not device driver
issues.

If you all need a new way to report issues like this to userspace, then
let's create the correct api for it, don't require userspace to mmap a
random device and expect to poke around in it safely to get the
information.

Odds are that mmap will change with the next version of this device,
right?

Agreed. I'm wondering if we don't even need to invent anything new
though and can simply use devcoredump. Harry?

I am not familiar with devcoredump, so will experiment with it for the user
clock monitor support. Thanks for the suggestion! In the mean time, I think it
might make more sense to split out the other _tidyup_ patches into a separate
patchset, so that can be merged separately first. Will do that next.

Thanks for the review!
Harry