From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C1133A963A for ; Mon, 13 Jul 2026 09:02:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783933360; cv=none; b=GpMRZnZj6GrFs9JvEt/8JRKGLAoj7DVwJ9oN3i/0iLY8qrHaAFiEMs4X1DY6GnrMA3hoipgofcc1vLs3TuiXDBYOBlYMrfQWFMRQgoUUqPDFbBfIZoHuHqt69zdoFE7vLyM/bD6Qs+PZw/JgZlhfqixoJASqfAeb8FvzDfXL2sw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783933360; c=relaxed/simple; bh=cqhH9o7bhyjahLAkf0iFgK41Z5YFmSxwbMiZXh6SVIA=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NRBptnuflc1CGOhMbo5x+eELC9bC/jj8i3D7q3QKyQjYHHY0KVsyLYEODr4dbhgV5UDGmJqXAKg93wGob+BuoIlENvmLWqUiYnJ+bVN6oxXLDzt0C6BjXpJ0SgMT01CFr36XoMknuuXZnmVs9kVs005ibExW+Xe9JB4ASPITaoI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ElRy5naM; arc=none smtp.client-ip=95.215.58.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ElRy5naM" Date: Mon, 13 Jul 2026 11:02:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783933356; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uY1+6zKnm0ARhtZsH7l5IzaCBkmhtObZOzg1HXZhMHs=; b=ElRy5naMRQNjss5+AFd8wI8IVcJUp7Cjm7HttQULJ3v5tiRz6jFJWtQJOtjfgRGaCGfpPK PcBGrjhsp1ajgiA64Vsw6f70/l3S5ehSppnMNJRmJlB2xap1mtPxoDANdagdvS3VrtJe3Z LTFRaAE8IwP8hiCtQsUQCbXrzUqDzCY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Thorsten Blum To: Geoff Levand , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] powerpc/ps3: Remove unused struct table in setup_areas() Message-ID: References: <20260712151300.3664-3-thorsten.blum@linux.dev> <20260713134356.62f55781-f6-amachhiw@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260713134356.62f55781-f6-amachhiw@linux.ibm.com> X-Migadu-Flow: FLOW_OUT On Mon, Jul 13, 2026 at 01:59:02PM +0530, Amit Machhiwal wrote: > On 2026/07/12 05:13 PM, Thorsten Blum wrote: > > The local table structure is not used - remove it. > > > > Remove % in the comment while at it. > > > > Signed-off-by: Thorsten Blum > > --- > > arch/powerpc/platforms/ps3/spu.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c > > index e817def7f424..c904f9fa1caa 100644 > > --- a/arch/powerpc/platforms/ps3/spu.c > > +++ b/arch/powerpc/platforms/ps3/spu.c > > @@ -185,13 +185,11 @@ static void spu_unmap(struct spu *spu) > > * The current HV requires the spu shadow regs to be mapped with the > > * PTE page protection bits set as read-only. > > * > > - * Returns: %0 on success or -errno on error. > > + * Returns: 0 on success or -errno on error. > > The % prefix should actually be kept here I think. Per the kernel-doc > documentation [1]: > > %CONST > Name of a constant. (No cross-referencing, just formatting.) > > Examples: > > %0 %NULL %-1 %-EFAULT %-EINVAL %-ENOMEM > > So %0 is valid and intentional kernel-doc markup that renders the > constant 0 with proper formatting. Interesting - not sure I have seen this style before and plain 0 seems to be far more common. There has been some discussion around it here: https://lore.kernel.org/all/87ilamz4j5.fsf@meer.lwn.net/ I guess I'll send a v2 without the %0 change. Thanks, Thorsten