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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 14730CD128A for ; Mon, 1 Apr 2024 23:26:46 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id AA9B522A7; Tue, 2 Apr 2024 01:26:34 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz AA9B522A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1712014004; bh=TYFrh8R3nTiyToRdkESyl4gieU1pHZ8UGJd8cNvp/TY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=XdCj/gpbZh9gzE56pIhD5/OtcOM+ak3U405uAXMqipP8vqpuMYKixlKjRQdNfdV4j k+tlNiaoQM68M/sMPv94Emr5JoB7u60fvSr8dGF0XXQut6f2sJanonSG+YtqHAoyVX yxf9k6TKHLx8lTy0appHfAd7eHsyToJhkErpZqQQ= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 536D1F80114; Tue, 2 Apr 2024 01:26:13 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 9E559F80114; Tue, 2 Apr 2024 01:26:12 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 1A9EFF80236; Tue, 2 Apr 2024 01:26:09 +0200 (CEST) Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 1F680F8016E for ; Tue, 2 Apr 2024 01:26:02 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 1F680F8016E Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.a=rsa-sha256 header.s=pandora-2019 header.b=T2pw0fHK DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=guUDnSYIdm+CRxSVwpXNejFQYIKdd6y2c+GWOdz8YnU=; b=T2pw0fHKkZ1xiQWfIlpxTCXmc4 0C/KuI6OBD9pYrulLafINnNwbIcpdk3Xd45l+HlXkteQ0wDnj96wc8si32rkFA+0AcBu4DJEOEgfz ULfkzSc9EWtq8BlXcZ3fywrdAuvB90MVh80BcwtodDDfYOaOmyOCvzXToBunv4EW0IUU5VkfL87Db NJo/rJ1rSK/xG23EKVeFCbmUy0HfFb9djxPCp/8RQJplmHVuRi9AzTJXTTOY3pQKWM2vjxZ126794 Vi5cesfT3DCBC3Zz8OQ7H7azypblOYIR+IVAsd2d6sfUt2cBnITCxOkFjHTn1K9aQlpxNDMgxMioQ E7P08KRw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35504) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rrR2M-0005SX-1Q; Tue, 02 Apr 2024 00:25:58 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rrR2L-0005ym-On; Tue, 02 Apr 2024 00:25:57 +0100 Date: Tue, 2 Apr 2024 00:25:57 +0100 From: "Russell King (Oracle)" To: Oswald Buddenhagen Cc: alsa-devel@alsa-project.org, Takashi Iwai , Jaroslav Kysela Subject: Re: [PATCH] ALSA: aaci: report FIFO size in frames Message-ID: References: <20240401101339.506625-1-oswald.buddenhagen@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) Message-ID-Hash: ERXBF2QFD6FO24CP2AZS4ZGIK6AJH72U X-Message-ID-Hash: ERXBF2QFD6FO24CP2AZS4ZGIK6AJH72U X-MailFrom: linux+alsa-devel=alsa-project.org@armlinux.org.uk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Apr 02, 2024 at 01:01:24AM +0200, Oswald Buddenhagen wrote: > On Mon, Apr 01, 2024 at 09:59:10PM +0100, Russell King (Oracle) wrote: > > On Mon, Apr 01, 2024 at 04:17:53PM +0200, Oswald Buddenhagen wrote: > > > i think that speculative/rfc patches are a perfectly fine way to get > > > things clarified, and the linux kernel is no exception to that. > > > > This wasn't a "speculative/rfc" patch. Such patches get marked with > > "RFC" in the tag. > > > putting an obvious disclaimer/question section after a three-dash line > is a perfectly sufficient way to mark such a patch. at least if the > receiver is actually interested in cooperation rather than harping on > formalities. Convention is it goes in the subject line, so patch automation such as patchwork can identify the patches that aren't to be applied. It's not just a formality as you suggest. > > > > Comments are not always correct. > > > > > > > so how about taking the opportunity to fix this one? > > > > I don't think this comment is incorrect. > > > > "ALSA wants the byte-size of the FIFOs." > > > > That is a fact when the flag you refer to is not set. > > > yet the formulation also suggests that this is something that just is, > rather than something that the code has control over. Eh what are you going on about. The fact that SNDRV_PCM_INFO_FIFO_IN_FRAMES is not set means fifo_size is in bytes. That's a fact. This flag was introduced in commit 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling") which was part of v2.6.31-rc1. The driver you are modifying was introduced in v2.6.13-rc1 *before* this flag was available, and thus from a time when fifo_size was _only_ _ever_ specifyable in bytes. Maybe the author of the patch introducing the ability to provide fifo_size in frames should have gone through every driver checking to see whether there were any comments to be updated? > > [...] > > At some point, knowledge has to be assumed. > > > the problem is the omission of specific information that is in this > context at least as pertinent as the information that _was_ supplied. > > the code is also somewhat special in that it implements an interface, > which makes it more likely to be "visited" by outsiders than some > implementation details. it makes sense to take that into account in > related comments. The code is not "somewhat special". The code does what it does and has done so since before specifying fifo_size in frames was possible. I think it is your understanding of ALSA that is the problem, and you've decided that passing fifo_size as bytes is now "somewhat special". It isn't. I am still left wondering if this is some perverse April Fool's joke on your part, designed to provoke a negative reaction. You clearly don't believe in doing any research. You don't follow the process described in submitting-patches.rst. You just create broken patches and send them in a form where they could well be picked up and merged into mainline causing breakage. This makes you dangerous, which is why I'm calling you out for it. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!