On Thu Aug 29, 2024 at 7:17 PM BST, Stephen Boyd wrote: > Quoting Greg Kroah-Hartman (2024-08-28 00:10:46) > > On Tue, Aug 27, 2024 at 04:40:52PM -0700, Stephen Boyd wrote: > > > Quoting Harry Austen (2024-08-27 12:08:52) > > > > On Mon Aug 26, 2024 at 2:11 PM BST, Greg Kroah-Hartman wrote: > > > > > 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. > > > > > 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
