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 6BE14D1812B for ; Mon, 14 Oct 2024 16:01:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C5C56B0085; Mon, 14 Oct 2024 12:01:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0761B6B0088; Mon, 14 Oct 2024 12:01:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E59506B0089; Mon, 14 Oct 2024 12:01:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C66406B0085 for ; Mon, 14 Oct 2024 12:01:42 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1505FC10A1 for ; Mon, 14 Oct 2024 16:01:34 +0000 (UTC) X-FDA: 82672673160.28.6DB4A56 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf02.hostedemail.com (Postfix) with ESMTP id D2B2080026 for ; Mon, 14 Oct 2024 16:01:28 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B6WqEIQh; spf=pass (imf02.hostedemail.com: domain of broonie@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728921512; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5hJv2Q9ziar+mpo6edj5QDnPbqkJoV1qQbgAGXvTRQM=; b=mWrwDexCpVleRAKH/Kir56JO0c8SYXY3YCr0xhUgrlWsRSfRJbi+8tvCFiD7zS9KoiNtNt M4vaqzwopPTMN9q1hmaL4pGY7jFjVZrvH6X/rdcA5auXdjsZXY2+mu6hYG6r0yT24UDS37 1Bv8DpjCIpaM97553/RfcOgO22n9oIk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B6WqEIQh; spf=pass (imf02.hostedemail.com: domain of broonie@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728921512; a=rsa-sha256; cv=none; b=SUgSop27K0B6gZpDfYitvW3EH9i25K9R22VPBU++q8rDleP0zkbhNqYRad/gLGDiUyCDMO HEOz9+HnLOcfPpVTRE6y+g6V2PEb6A24FuNfsRgw/ruoZWrIZ2vFD9ydsqDu9uxkplvvcC I18MGWSd1TZGUtw5EGYAXKQwzS47v3g= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1DCC3A424EC; Mon, 14 Oct 2024 16:01:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7F7BC4CEC3; Mon, 14 Oct 2024 16:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728921699; bh=/LxBb/XpJeYTRjuQxo2hPSUULibUtnh60pBYguxgPOw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B6WqEIQhvd1zimAbUe+3tMHiLGy7AdQ8uq4due8CME0s9V7+dL+JNyvTYZu0LhZR6 H8s8+v5nWSvdZv7eQWthiBwQVkxJoFuCIBb8w8qd3wNkTigXdmVOe9oKAbbqXQEKTm yoH7SmoEiAEmM9KnKXd95bpNw0BcFxIsgxbd2tp2M/JCz51GWHhcxYPefhc//9f8XY NIOlCCEuIiBh6L+pEWJTWS2bwTwrMkmivYbxdoKanAGnb1odK5IIO+5wq+gocIuZf8 tnOTPmHtHx42oyxq2rSZKXyEfb8Ev6/m7RrscJ8X/VUwJ6VKqxXvsIkqyUq1JKVv5e /zVYto9VrB24Q== Date: Mon, 14 Oct 2024 17:01:28 +0100 From: Mark Brown To: Ryan Roberts 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 Subject: Re: [RFC PATCH v1 22/57] sound: Remove PAGE_SIZE compile-time constant assumption Message-ID: 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YQ5NQwwWvL7pQhlB" Content-Disposition: inline In-Reply-To: <6926988e-5532-457f-9e1a-135b03585c5d@arm.com> X-Cookie: Editing is a rewording activity. X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D2B2080026 X-Stat-Signature: 16d8kzis33tduweigapuejm7qg1j3ktk X-Rspam-User: X-HE-Tag: 1728921688-972652 X-HE-Meta: U2FsdGVkX1/bdwSBqvHa0rEYT94uOOdHMlDnn27MpengJoOux5dxb7x2yLzV+47GjQdzqn+9E5dwan5tz3VKmL2U3Cz8rdSWVQbS84R7iXy1zwxFy3xTpzCORhWC2Q4vbVWXOV+p4U2+8jb5x7U4QF/XI2qjnD3FMUaqYQoFrL6Sl8xvVVqmV0pdZTRN4aKFgqVuSxT5yh3/GzbueOW/a+pWLM0yhK9Wh4PiBgX0JH5dRBgwdq8WkY+K1otUBtoOdpgLHPPI9NDjL7l3hza8aaWsf1EXZiQrcrtnHLB0NEHWKAamE4JD/MueNhqYFBw/O25dSyZJpUtXaDCQ6skUOqJERz3MJrMtheTJRxZiKR1H7dW4a138BcVWcOOglby1XuzvIw0l+45oZvlFyUhv/kVLCPe9CplSYIdWd+b+1i71Gz/B62ttAwo2FWBEhWM0wIYCGnaCrwXCHRcPdb6IYR2e1F2UaSl7xyP6/eflFnabKMunuxRbxRC5TFcEnL7iRv5JYtD97/CrnErLPtoDzsstuUXDlO5zuftQypNY6O6IwZQDTk2uen3ywpAYRO7H0EbZCn88GrNjkeWAfmVh2y1vCIsFDmIkVafKVLjYgBeXhwTweE4orTm/bsfycJ9fqjiuPGjgzeHT0HgS1ZmIZ6C/7jJETf2Oz0+Tsp9xRocDYr/iufRiHSDkQT+QxOKAVQvYx7I9j7KmB3eczTHuLLN3fKKGFgHzvhJeZONs3AkFkDfmtjONf8FvGrzJkv4XZAAEFMpCW0q4+WScFizLi1PslBG8DqEYdq0z/0l7bel0CFl0qAn38yBqbg2g7xiQUUcefGZuQ4IJg8Qf7AybXc7T7Z2c0gNdAEpA7UPMhBPeDeiMOE4mMIXrH4mcK6sYvmFGwM2CVY5AB4+q0o/woh+hff4I4rkisdIwbQgjfb81AamBmaaeZy57OTj1spbFO3mEHTFA1qM6j4eMVvX SDmtIinW B6mPh0s2iJFW+aBh8oXkGhNsNFx6Lw6XqT1bbrkXwTFP6qawRE21GDRo1dLG+dj000jWDvJoDPxMGb+3bcIpJTU6u6FchMwM2081Ee65v7JeQcmeO4yt12VNcaCSUjwgCOB5eFuMvxHivkpfAvXvT0DhQpeQhfJqeH4H1TcBxt/55HRFjebXa8nKknTRz3BHFksnup2uTi2qRFjUd5hDEVlbEtYGPqD7qYdtqAIFl11D1duwwkiNlZ3AHJUjISzjSw3zaOYYMUqKfMYCwqaZCUb7jFD8xR3Y/30FzPY3zMh02rQmhMWHAMLhQCGF3yEzbMqP+/o8HhjklfQb8Y2EAxdh8y0ySp6/QdN1RBsc9l9Mtil6NoTrMVwI1Z9FA039x/NPSBYXLvK6sNHgTBEIX6GSQsjjZMAqNHtyU6l26AKH39WbLTLv3j03P3QN+LgSU07JD 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: --YQ5NQwwWvL7pQhlB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 cont= ext: > >> https://lore.kernel.org/all/20241014105514.3206191-1-ryan.roberts@arm.= com/ > > As documented in submitting-patches.rst please send patches to the=20 > > 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 l= ists > 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. 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 =3D 128*1024, > .period_bytes_min =3D PAGE_SIZE_MAX, <<<<< > .period_bytes_max =3D PAGE_SIZE_MAX*2, <<<<< > .periods_min =3D 2, > .periods_max =3D 128, > It's not really clear to me how all the parameters interact; the buffer s= ize > 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 ap= ply 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. --YQ5NQwwWvL7pQhlB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmcNQFUACgkQJNaLcl1U h9C0BQgAgLqixHC2HmBLzE8BtScypVWosu4/llyhlnVLHix+5KCjWH4yMIAcDIkm jSFLEZw+OQkiVYFGEmM/QkODuq0/yw1Fj9xAh8n5Po4KNj86ffwVuVtgmg8MXlIX ze+ysOH4IaGnEzu1ppJLCNNtrOftI1Fm7mDwkGUEB2ZMfP4JoY+q+OnXpZlpqVIf t1uQWnUb2bhLR6J9awpzY+fRSoz5x0CJF540oKfBMU3Jo6mhJH0sLc1zZmxwCYIn YGFPJVjIjJ0VaXa5+XFXSDvlcLvPiegwSR9Ys3rmEWJNpb/uWdSEDy8+tus4OH2/ SQF5XoYZF2SEAD1WU+LcRqS3+yzikQ== =ZFCZ -----END PGP SIGNATURE----- --YQ5NQwwWvL7pQhlB--