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 58437CFC293 for ; Tue, 15 Oct 2024 11:35:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAB8E6B009B; Tue, 15 Oct 2024 07:35:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D33E16B009C; Tue, 15 Oct 2024 07:35:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD45E6B009D; Tue, 15 Oct 2024 07:35:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9BFC76B009B for ; Tue, 15 Oct 2024 07:35:31 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 876E816147B for ; Tue, 15 Oct 2024 11:35:21 +0000 (UTC) X-FDA: 82675631010.06.52CE915 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf18.hostedemail.com (Postfix) with ESMTP id 490631C0011 for ; Tue, 15 Oct 2024 11:35:26 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728992082; 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=qBDor41LRxsQeGPqy/gezFhtHrfWrgOlABs1ToVGbSg=; b=vJw2qGRHZWYMlqjJte1RCF17fuVHzEYr8TvsAchqP1u085amSz2bqIx3xAmyFymBPImDsx zR4yM4876kMfO8nGHflSqsGVNVRoszlNMVxWgnHYvYG8p24U8WYxV5MGF2v6/LZFj7DtXe ImRJQ0Wh8cHZ7uu852D3ADQEGKQBrC8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728992082; a=rsa-sha256; cv=none; b=y0gZ5LPsXkYch4XegEdTPWWMF+eEmk90UdhgFm0FvdH/WElMVIJK+yxzYUKT25kcAWHvWU g538jfof9FhiVBgOQ3ztCywWKP3d67WO7KEaZnD6CTqZf7kIvm3x70UYv392IpDwedtzdq 4/guc2iKAAPZU+9Ye81fQeiQdhlW/gE= 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 16B0B1007; Tue, 15 Oct 2024 04:35:58 -0700 (PDT) Received: from [10.57.86.207] (unknown [10.57.86.207]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE23D3F51B; Tue, 15 Oct 2024 04:35:24 -0700 (PDT) Message-ID: <6258fd24-e708-444b-88a3-792c14527817@arm.com> Date: Tue, 15 Oct 2024 12:35:23 +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> <6926988e-5532-457f-9e1a-135b03585c5d@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: smagy7mjh6rcknn5obysoe373rjuxgpc X-Rspamd-Queue-Id: 490631C0011 X-Rspamd-Server: rspam11 X-HE-Tag: 1728992126-724962 X-HE-Meta: U2FsdGVkX1/9+5nRvoQtAq1TpZ8NhqQtgGyulhTUbQCEzgIkVbZKBEgOHnmEKYGp6Wyo7HEKoCxWEpDA5arcWFv2ipv4D/amEfSnKg0qongjQjgYvvT5ZiiiWWnj+gQgIgykZadjg1NhDLE/Vffd9s3WlWL0RbHCoI4P0o1T9CdQOb7HzEalGsRCZGRvAJWyMPkMbfK06RhQtJcPTiEn1DidK1rF1UDqlN5n6yTgc9lGsi3Z1t9zPz3ROOdOQ0BLgkEoZZceDGPR8iWXJk8dLBehPbqtt5BLT/0C6eYkMlNf6z4krtsecsWL7NZSqh5YWk0JTTVWy/38qJRV5Xz6z2zhVNma+HpmYVLb/Hna8HZsoj/uCR0NdD4W5uz/azue7rf0zqBX/dZPLveIAFpYLJMn7FoviR0/bgH1Jty1WwS5oNnvsbtUksrdT2lLf5hqo2uBEbq/H7TFC2ElOuUBNDPS13MOTKOraSKUO4fvO2wZGeEPYm5X9/A81TAMP8T916ygy6TnPMq1K4NpOe4oXTvs3ozhFsSAlG6z436axX5Hg+YtjejSiziuzAxCW1HCJutkq+B9bLl+li4BcxgwLw1hyCKwEFX9rfY1nfZ1aTvjOLJT1+ahaTKMoVKhfRwmPucZpf4LQmO7Xg+hJK7sw8nCBem9YI97+zLmkiTl5e/7MR1HJg757rBmxIh7DXGdIv/KTOJpznsGg8fBAPK5390UhvYjfBQqRCHvF7yEm8ABBOdrRGqpcyyeRWY3EKqOsM8kkvvjm0Cdt91i6XM+GJWtZm5K4GZmxbLfpO121s6nv/+EBruYqgfRBH/SpkBZcpTZO2Go5tJF+PKUKfqzcJNe5P0c9N9aXIX++EibTSR59Y9Qf/14oXSBetnBaKpTZ9tWI/sGgRTvpBk2kW4KwVJlRuDvWqs6RywnX/0Q/0zkldcIVGyqLyeWasCFK22d1DIg0pQktFGRxEPzeo0 h+Y1XP3i h8Vtw6TocmgkDKKhGj5MxYI3U+4T1JZfKn/3zpMNC5WCTvdqsq3bafq2v/MoZk/jqP3MGOkN5Dwe88IgVFwvMJePpwrPVLq2zh5LO16sWK/lfIFKrVo0yfCEQzT0dD9bmoxMm2sJw/kVsrjGhRYJQ69QzBxog9PzbKQbojeLt0inMiyFlYN+ALTKzF2asReRVGOS22JsDw76i0PerZpCmvnDlB7udKKlOn3nSGB4qBXwIM0Y4JJBijof5slx+Z/9ugXOiDc/QzA/F82ja8VF51fX6AQ== 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 17:01, Mark Brown wrote: > On Mon, Oct 14, 2024 at 01:24:02PM +0100, Ryan Roberts wrote: >> On 14/10/2024 12:38, Mark Brown wrote: >>> On Mon, Oct 14, 2024 at 11:58:29AM +0100, Ryan Roberts wrote: > >>>> ***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. > > The entry in MAINTAINERS for me is a M:, supporter is just the usual > get_maintainers noise. Supported is exactly equivalent to a maintainer. Ugh, In my head I always thought "supporter" was somebody who engaged with the subsystem but did not have an official role (like a football supporter). But now that I've gone and read the MAINTAINERS file, I see it's actually referring to status (supported vs maintained). Sorry about this. Due to this buggy filtering, I've missed a few others off other patches in this series. I'll fix that by forwarding to them. > Generally if you're going to filter people you should be filtering less > specific matches out rather than more and if you're looking to filter > very aggressively look at who actually commits changes to whatever > you're trying to change, less specific maintainers will generally > delegate down to the more specific ones. > >>> 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... > > Like Takashi says just using absolute numbers here is probably just as > sensible, the numbers are there to stop userspace tripping over itself > but like I say it shouldn't ever get as far as actually using them for > anything. So long as we end up with some numbers that don't need any > late init patching the specifics aren't super important, the use of > PAGE_SIZE was kind of random. OK, I'll post a respin of this patch independently of the rest of the series, given it no longer has a dependency. Thanks, Ryan