From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B42D5CA0EE8 for ; Fri, 30 Aug 2024 07:34:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:From: To:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6kiAh4bj1vs16SDTRN/mniIbskGshVQ5j+jHnyQ258s=; b=ir/pxSrIh3RfiimorB7IatpxBF 4B46C+/c6g3ESybZ85EW+D5tcgpcFDOiMvY0Bp8/IaLik+/BooxUKX6j+Oq/Mio2zTZgw56Rb/gC6 rpcR2RtwImESbJXqDqqjhRFFrBIuybwVRkBuProaQCBJUyGJ2GJgUCaZ4Orf4FVQTjrJG4dxJAGaM JqhHgwcTaP+UiQTghn3wnUap8qDp4SCYa0N/Vujae9mWY41f4BryRr4Wak1T/jCywUMSHzW+HzJrG 3/saw8AOSpmwVnOLlqWdkGa729QKI39X7xYy+A42L3UHIQoPH7qv0yH1rMdszag435JpPs74NKzcS HZ6ybYMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjw8x-0000000596c-1ehL; Fri, 30 Aug 2024 07:34:03 +0000 Received: from mail-40131.protonmail.ch ([185.70.40.131]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjw6o-000000058SN-47SP for linux-arm-kernel@lists.infradead.org; Fri, 30 Aug 2024 07:31:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1725003106; x=1725262306; bh=6kiAh4bj1vs16SDTRN/mniIbskGshVQ5j+jHnyQ258s=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=YWd8JOrGT43CBpBDVGf0Fr486nZesQcxj6LDNh+Wo/Nt3lPts5WwvFRWO2jUReyzT WCXMt4Z8Lx06BtPEkCgBp9jK0D2DjBinC7UsT/sVxbrxJqucxloRNPrHo+dQpo0Klq 9FA9nJ63ECM9Bi1c8JQdm374rUicMW/I6Ra4cV+z3vApNO5r6t1n+NGZJYReDbLn7v /OM8HDL3baQ7rgvQEYcnOPYaos8biYH9S8dPICeTd1k1dDWq5VK/yp921pErVgOyjp +ixhqCwxK5YAPsRgNt34ISIL6mbVpxd3iw4IoHBoSJ6Ejx7cYgQOfXYOqxGa7SP626 piMPIWanXS+8Q== Date: Fri, 30 Aug 2024 07:31:42 +0000 To: Stephen Boyd , Greg Kroah-Hartman From: Harry Austen Cc: Michael Turquette , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michal Simek , Shubhrajyoti Datta , Dave Ertman , Ira Weiny , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 7/9] uio: add Xilinx user clock monitor support Message-ID: In-Reply-To: <1bd17a02bab46391872e4934895b83e8.sboyd@kernel.org> References: <20240826123602.1872-1-hpausten@protonmail.com> <20240826123602.1872-8-hpausten@protonmail.com> <2024082655-cubicle-flashily-6ab3@gregkh> <2024082824-emphasis-thwarting-4ef4@gregkh> <1bd17a02bab46391872e4934895b83e8.sboyd@kernel.org> Feedback-ID: 53116287:user:proton X-Pm-Message-ID: 58d99f953b29a2aa5d149b4943e6a5e13f41cd38 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240830_003151_191841_EE178712 X-CRM114-Status: GOOD ( 21.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 cod= e 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 glitc= hed) 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 drive= r > > > 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 separa= te patchset, so that can be merged separately first. Will do that next. Thanks for the review! Harry