From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1F02E34BA20 for ; Wed, 11 Mar 2026 08:24:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773217452; cv=none; b=DneDZWSR5fB4FDDT1ktK4ma9EM25S9BOIyqFcCCIA3lvY8n+Vmd9Zdq/R3WOOs/KGyxfU+x69xJVrAYhvV/Cv8KOafaZYTNjEyWI2TJo7oVNWmzENGmokTOZ3tAAtG2Sr0nKO/IZvmBo0pTkJKIfRekuu2x0i9pV7B+ct1jx9yo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773217452; c=relaxed/simple; bh=dv8CapPcHU2C+UPdJ63rwR82PJQ9Lvi9bsHcC34LSxA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r7uA6HGZru2zsz6nMaY8+6AQ62eTdpCc+NxT51WEkDQ4SGXG3QcRcfIg3MEqgZA7nJHWJMv9XYEKnAx2kOw/InmC++rsy+2MQYmWd5/w/b0mDdY3k4i4uvYSFUSSZyxPITBumxMJc19ZPAP/4xRuV+ZmErQUoM8XYOivayffRrs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=eeqNaROk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="eeqNaROk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 643C5C4CEF7; Wed, 11 Mar 2026 08:24:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1773217451; bh=dv8CapPcHU2C+UPdJ63rwR82PJQ9Lvi9bsHcC34LSxA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eeqNaROkc36vhuZZvSHJDPoiwMb29CQf/insgW+qVaDb/gFgmswjWF2SZd+7L8z8L kx11nJQ0ipmrz0Hjp4oRfs24ig+jQpI2SjsdFFEDe3tPIhX+AQB4NGDdQJd0VisiKj LYNOD37oD2DdiJsPkp0zAjFb0lQ0vnKa3bT0UonE= Date: Wed, 11 Mar 2026 09:23:55 +0100 From: Greg KH To: Jori Koolstra Cc: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Haren Myneni , Srikar Dronamraju , Jonathan Greental , Kees Cook , Shrikanth Hegde , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , open list Subject: Re: [PATCH v2] powerpc: vas-api: constify dynamic struct class in coproc api register Message-ID: <2026031154-labored-frivolous-154b@gregkh> References: <20260308214634.1215051-1-jkoolstra@xs4all.nl> <2026030924-penniless-hermit-ffc0@gregkh> <1304966204.915283.1773053337271@kpc.webmail.kpnmail.nl> 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: <1304966204.915283.1773053337271@kpc.webmail.kpnmail.nl> On Mon, Mar 09, 2026 at 11:48:57AM +0100, Jori Koolstra wrote: > My bad, the earlier email went out to soon. > > > Op 09-03-2026 07:01 CET schreef Greg KH : > > > arch/powerpc/platforms/book3s/vas-api.c | 34 +++++++++++++++++++------ > > > 1 file changed, 26 insertions(+), 8 deletions(-) > > > > > > diff --git a/arch/powerpc/platforms/book3s/vas-api.c b/arch/powerpc/platforms/book3s/vas-api.c > > > index ea4ffa63f043..e377981fd533 100644 > > > --- a/arch/powerpc/platforms/book3s/vas-api.c > > > +++ b/arch/powerpc/platforms/book3s/vas-api.c > > > @@ -45,7 +45,7 @@ static struct coproc_dev { > > > struct device *device; > > > char *name; > > > dev_t devt; > > > - struct class *class; > > > + const struct class *class; > > > enum vas_cop_type cop_type; > > > const struct vas_user_win_ops *vops; > > > } coproc_device; > > > @@ -599,6 +599,21 @@ static struct file_operations coproc_fops = { > > > .unlocked_ioctl = coproc_ioctl, > > > }; > > > > > > +static const struct class nx_gzip_class = { > > > + .name = "nx-gzip", > > > + .devnode = coproc_devnode > > > +}; > > > + > > > +static const struct class* cop_to_class(enum vas_cop_type cop) > > > +{ > > > + switch (cop) { > > > + case VAS_COP_TYPE_GZIP: return &nx_gzip_class; > > > + default: > > > + pr_err("No device class defined for cop type %d\n", cop); > > > + return NULL; > > > + } > > > +} > > > + > > > /* > > > * Supporting only nx-gzip coprocessor type now, but this API code > > > * extended to other coprocessor types later. > > > @@ -609,6 +624,10 @@ int vas_register_coproc_api(struct module *mod, enum vas_cop_type cop_type, > > > { > > > int rc = -EINVAL; > > > dev_t devno; > > > + const struct class* class = cop_to_class(cop_type); > > > + > > > + if (!class) > > > + return rc; > > > > How can this happen? > > > > This feels odd, are different types of devices being registered here? I > > don't see where VAS_COP_TYPE_GZIP was being tested in the original code, > > why add this additional logic? > > > > My line of thought is this: > > There is a function vas_register_coproc_api() that does some kind of registering > for different coprocessor types. It has the following comment above: > > /* > * Supporting only nx-gzip coprocessor type now, but this API code > * extended to other coprocessor types later. > */ I guess "later" never happened :( > If you look at where this function is eventually triggered it is indeed only ever > passed VAS_COP_TYPE_GZIP. For instance, line 1238 of drivers/crypto/nx/nx-common-series.c > has the call > > ret = vas_register_api_pseries(THIS_MODULE, VAS_COP_TYPE_GZIP, > "nx-gzip"); > > (which immediately calls vas_register_coproc_api()) > > It also passes a hard-coded name for the device ("nx-gzip"), and this name is also > used as the device class name. Now, this is a problem if we want to get rid of > class_create(). Somehow "nx-gzip" needs to get linked to the appropriate const struct > class. I figured it is better to use the cop_type, and a cop_to_class() function to > set this link. However, since the other co-processor types are not implemented (yet) > it would seem silly to already assign struct classes for these, hence the NULL return. > It is meant to signal: not implemented. Then again, if ever a new co-processor was added > you must update the cop_to_class()... but at least this is my line of thought. > > There is also a function static char *cop_to_str(int cop) that strangely takes > an int instead of an enum vas_cop_type, and also misses an option I think. Ok, I'll defer to the maintainer here, as it's their code, and seems to not follow the "normal" style of handling classes. thanks, greg k-h