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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92E87D16252 for ; Mon, 14 Oct 2024 12:24:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08F016B0082; Mon, 14 Oct 2024 08:24:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 017AB6B0083; Mon, 14 Oct 2024 08:24:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFB146B0085; Mon, 14 Oct 2024 08:24:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BD0516B0082 for ; Mon, 14 Oct 2024 08:24:11 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 305F11C5EBF for ; Mon, 14 Oct 2024 12:24:02 +0000 (UTC) X-FDA: 82672124892.25.5CD2899 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id E4BE61C0017 for ; Mon, 14 Oct 2024 12:23:56 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728908602; a=rsa-sha256; cv=none; b=QgMZvPfHvNRz3BYEP+4hlTTWEtL1WE7xw84hL8gWkA9zbaOZTCJyF90+hXOipXKuJNx+BN XGcouyHAAUwsWEAWR3mj1gMHXuyZeb6SwS35dSLXWcXBt3f3zQ41yKwyRbLMtHx9aMqSnj JcYgZXeiIiJc5auJJ/U+CeTDIuNloaU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728908602; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GfF0GZS8hhsSSZGnaTqA1IXocAERehzTaRTyT3GDOvw=; b=Qz/GlXRMKNMt4f6E+tTsQ819Ojq4psUbIdwlkhjvMcjETbRTQ3oIr9ubF7sfS1/hHFLAe+ Qlf+xpJ7r6kQOn0bBTzA0ex9ag9QShUPWZYmgPgvBdN1oRfpwdiD9iuTfU+GKAPWfZ6Tl3 iB8Or1c/G3dco+Dahkff2VBhBqttSEs= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 322411007; Mon, 14 Oct 2024 05:24:37 -0700 (PDT) Received: from [10.57.86.130] (unknown [10.57.86.130]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2053C3F71E; Mon, 14 Oct 2024 05:24:03 -0700 (PDT) Message-ID: <6926988e-5532-457f-9e1a-135b03585c5d@arm.com> Date: Mon, 14 Oct 2024 13:24:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 22/57] sound: Remove PAGE_SIZE compile-time constant assumption Content-Language: en-GB To: Mark Brown Cc: Andrew Morton , Anshuman Khandual , Ard Biesheuvel , Catalin Marinas , David Hildenbrand , Greg Marsden , Ivan Ivanov , Jaroslav Kysela , Kalesh Singh , Marc Zyngier , Mark Rutland , Matthias Brugger , Miroslav Benes , Takashi Iwai , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-sound@vger.kernel.org References: <20241014105514.3206191-1-ryan.roberts@arm.com> <20241014105912.3207374-1-ryan.roberts@arm.com> <20241014105912.3207374-22-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: E4BE61C0017 X-Rspamd-Server: rspam01 X-Stat-Signature: 93z8ms4nffsg4szu44xocdo8fainiiy3 X-HE-Tag: 1728908636-526882 X-HE-Meta: U2FsdGVkX1/UQ1yNDCk39593/BPmj2GL8RvRI0WfK+WK2Q5K3sXaQ322m9s9EGfjeNTL4u36sAicDvP12lmpvOez4eoaFIJt2kIgqxJKagZIc48JeRCRMKDQCvriexWEvk1RnA7VmAvM3lt1yoCn9U5KhxXaQrZb+m1syWSeSImsMPDJHbkOfZaYYV9Da4eksMFpEDP7yEO9u+k2XcSRaqEb2XGZUOmOEqfmby6eY7+SKAonwvCBBmWtaV0aNUvFYWbs8RSyX5xlurqP+seGiuS36l7BDbLeOCbLMybiCEGqpAZwofuEjDZV1CWKxM3oX/HKMBCs9hRNQvaOrKzuOIEK7Lkyk6TPyLONKU0rqHzbr2W2Y/l6Z9un7Vey627ndezunoCxeeACfbEGTFkviD+uqpAEFoNF3fOodocUOUeio08SH7HqdVSfhDo+8PM3GpCrJVeHWuowpMHe9bnlWGx+kUU6+Yg1hhA7QUEo6AbEg77646ESh3lMcc1AX1nbXn4z49UK2KXSZ21NNHdgRJeAnv0GMl3WE6EThMz+pzu2Q8wy2Jam2xPfPbPKr/RsKlF0HYyf2tOmbJ/fn2mYCQgy4M89DIgcrs4vix2rLlh2KutcC8pOJbVb1GA6hfhoT5FmewxpTQzZ2hvWk8B+2AlQEotFopbZbsOB+t4BVGYPLyHW80i6IcrKkYn7ZeA2imzi8ktGlJsgizPYS4CfTgY20Zj1cnhFvZLaGlzpC6tt5Fmg9mcBEsOsr2oFSLEi11XWs86I16jWiPKcldPQvdPGGszI6ImYqWuTTWqaZkmuF4vF75pwhjHwXkuCmnyjSHs9tGRc1+XEcoYK6mSZ2gTUJ0A/PNR0n+cqPCOUF7VZrapnPVL1Hc492qpencwWMrHSaxZMBzKMv0QZX1duGLjXFBDwo4ViN6WaRb7UfNo/L9sPAfs5XWwH+ISSiEkp0WzeOsHi5xOyFXPSoGl LC/tfZxN 8XwHvoQC9OUyBAPGn2I06bDymYhh4/4NFCfS0DrIRP1Wt7kuyOEoGtt+hz/nekj5vi7hMfhAVBqp6qPQ7TCqwLqk7q8r1kLtBe5vVc7t26zumt6DD1Y/FHeGMIRC+Ef2A/YQJplFN/gXlWcJUNJkklj/aMkNsJb4TiSMcrMSol1dgM0Mtffop2FIF/JA1TyatEFn0dqboSNEVefdKjwfasn3hTwqRJkkPcQkd04d4YyhQtZM6/IKo4CmQ2S7W6ofAtbgERxRW0YETdcZB9euddP9A9w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 14/10/2024 12:38, Mark Brown wrote: > On Mon, Oct 14, 2024 at 11:58:29AM +0100, Ryan Roberts wrote: >> To prepare for supporting boot-time page size selection, refactor code >> to remove assumptions about PAGE_SIZE being compile-time constant. Code >> intended to be equivalent when compile-time page size is active. > > Please submit patches using subject lines reflecting the style for the > subsystem, this makes it easier for people to identify relevant patches. > Look at what existing commits in the area you're changing are doing and > make sure your subject lines visually resemble what they're doing. > There's no need to resubmit to fix this alone. No problem, will fix this in the next round (where I anticipate sending more targetted serieses to maintainers). > >> ***NOTE*** >> Any confused maintainers may want to read the cover note here for context: >> https://lore.kernel.org/all/20241014105514.3206191-1-ryan.roberts@arm.com/ > > As documented in submitting-patches.rst please send patches to the > maintainers for the code you would like to change. The normal kernel > workflow is that people apply patches from their inboxes, if they aren't > copied they are likely to not see the patch at all and it is much more > difficult to apply patches. Sure. I think you're implying that you would have liked to be in To: for this patch? I went to quite a lot of trouble to ensure all maintainers were at least in the To: field for patches touching their code. But get_maintainer.pl lists you as a supporter, not a maintainer when I ran this patch through. Could you clarify what would have been the correct thing to do? I could include all reviewers and supporters as well as maintainers but then I'd be banging up against the limits for some of the patches. Or perhaps I've misunderstood the point you're making here. > >> -static const struct snd_pcm_hardware dummy_dma_hardware = { >> +static DEFINE_GLOBAL_PAGE_SIZE_VAR_CONST(struct snd_pcm_hardware, dummy_dma_hardware, { >> /* Random values to keep userspace happy when checking constraints */ >> .info = SNDRV_PCM_INFO_INTERLEAVED | >> SNDRV_PCM_INFO_BLOCK_TRANSFER, >> @@ -107,7 +107,7 @@ static const struct snd_pcm_hardware dummy_dma_hardware = { >> .period_bytes_max = PAGE_SIZE*2, >> .periods_min = 2, >> .periods_max = 128, >> -}; >> +}); > > It's probably better to just use PAGE_SIZE_MAX here and avoid the > deferred patching, like the comment says we don't particularly care what > the value actually is here given that it's a dummy. OK, so would that be: .buffer_bytes_max = 128*1024, .period_bytes_min = PAGE_SIZE_MAX, <<<<< .period_bytes_max = PAGE_SIZE_MAX*2, <<<<< .periods_min = 2, .periods_max = 128, ? It's not really clear to me how all the parameters interact; the buffer size 128K, which, if PAGE_SIZE_MAX is 64K, would hold 1 period of the maximum size. But periods_min is 2. So not sure that works? Or perhaps I'm trying to apply too much meaning to the param names... Thanks, Ryan