linux-kernel - Re: [PATCH v3 7/9] uio: add Xilinx user clock monitor support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1bd17a02bab46391872e4934895b83e8.sboyd@kernel.org>
Date: Thu, 29 Aug 2024 11:17:30 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Harry Austen <hpausten@...tonmail.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Michael Turquette <mturquette@...libre.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Michal Simek <michal.simek@....com>, Shubhrajyoti Datta <shubhrajyoti.datta@....com>, Dave Ertman <david.m.ertman@...el.com>, Ira Weiny <ira.weiny@...el.com>, linux-clk@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 7/9] uio: add Xilinx user clock monitor support

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?