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 0A6811D529;
	Tue, 19 Dec 2023 15:10:04 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ytz86OmW"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EE83C433C7;
	Tue, 19 Dec 2023 15:10:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1702998604;
	bh=YG1opOXiv2eFAz9+JFxAGHHuQKweCGIP9rMOp7rwHcg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=ytz86OmWaegIRsBA2unUSBkc6kLq8StD0r0jhGgzWrF62fM313/boELTJtKvyhIEw
	 lUM+8Ys08phuamymX4VWV80dLjSxAcdwzA9pmiN8tt06HZKjCZ2PtmcYk+f7w2PAuA
	 tYvdTOUZzBkoFpLy8HQaQukWkxcwslTBMJO5119s=
Date: Tue, 19 Dec 2023 16:10:02 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Marco Pagani <marpagan@redhat.com>
Cc: Moritz Fischer <mdf@kernel.org>, Wu Hao <hao.wu@intel.com>,
	Xu Yilun <yilun.xu@intel.com>, Tom Rix <trix@redhat.com>,
	linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org
Subject: Re: [RFC PATCH v3 2/2] fpga: set owner of fpga_manager_ops for
 existing low-level modules
Message-ID: <2023121924-extent-defender-fb06@gregkh>
References: <20231218202809.84253-1-marpagan@redhat.com>
 <20231218202809.84253-3-marpagan@redhat.com>
 <2023121829-zealous-prissy-99cc@gregkh>
 <9296941c-a3c8-4d55-9e52-f1277f1c3fc7@redhat.com>
Precedence: bulk
X-Mailing-List: linux-fpga@vger.kernel.org
List-Id: <linux-fpga.vger.kernel.org>
List-Subscribe: <mailto:linux-fpga+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-fpga+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9296941c-a3c8-4d55-9e52-f1277f1c3fc7@redhat.com>

On Tue, Dec 19, 2023 at 03:54:25PM +0100, Marco Pagani wrote:
> 
> 
> On 2023-12-18 21:33, Greg Kroah-Hartman wrote:
> > On Mon, Dec 18, 2023 at 09:28:09PM +0100, Marco Pagani wrote:
> >> This patch tentatively set the owner field of fpga_manager_ops to
> >> THIS_MODULE for existing fpga manager low-level control modules.
> >>
> >> Signed-off-by: Marco Pagani <marpagan@redhat.com>
> >> ---
> >>  drivers/fpga/altera-cvp.c             | 1 +
> >>  drivers/fpga/altera-pr-ip-core.c      | 1 +
> >>  drivers/fpga/altera-ps-spi.c          | 1 +
> >>  drivers/fpga/dfl-fme-mgr.c            | 1 +
> >>  drivers/fpga/ice40-spi.c              | 1 +
> >>  drivers/fpga/lattice-sysconfig.c      | 1 +
> >>  drivers/fpga/machxo2-spi.c            | 1 +
> >>  drivers/fpga/microchip-spi.c          | 1 +
> >>  drivers/fpga/socfpga-a10.c            | 1 +
> >>  drivers/fpga/socfpga.c                | 1 +
> >>  drivers/fpga/stratix10-soc.c          | 1 +
> >>  drivers/fpga/tests/fpga-mgr-test.c    | 1 +
> >>  drivers/fpga/tests/fpga-region-test.c | 1 +
> >>  drivers/fpga/ts73xx-fpga.c            | 1 +
> >>  drivers/fpga/versal-fpga.c            | 1 +
> >>  drivers/fpga/xilinx-spi.c             | 1 +
> >>  drivers/fpga/zynq-fpga.c              | 1 +
> >>  drivers/fpga/zynqmp-fpga.c            | 1 +
> >>  18 files changed, 18 insertions(+)
> >>
> >> diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c
> >> index 4ffb9da537d8..aeb913547dd8 100644
> >> --- a/drivers/fpga/altera-cvp.c
> >> +++ b/drivers/fpga/altera-cvp.c
> >> @@ -520,6 +520,7 @@ static const struct fpga_manager_ops altera_cvp_ops = {
> >>  	.write_init	= altera_cvp_write_init,
> >>  	.write		= altera_cvp_write,
> >>  	.write_complete	= altera_cvp_write_complete,
> >> +	.owner		= THIS_MODULE,
> > 
> > Note, this is not how to do this, force the compiler to set this for you
> > automatically, otherwise everyone will always forget to do it.  Look at
> > how functions like usb_register_driver() works.
> > 
> > Also, are you _sure_ that you need a module owner in this structure?  I
> > still don't know why...
> >
> 
> Do you mean moving the module owner field to the manager context and setting
> it during registration with a helper macro?

I mean set it during registration with a helper macro.

> Something like:
> 
> struct fpga_manager {
> 	...
> 	struct module *owner;
> };
> 
> #define fpga_mgr_register(parent, ...) \
> 	__fpga_mgr_register(parent,..., THIS_MODULE)
> 
> struct fpga_manager *
> __fpga_mgr_register(struct device *parent, ..., struct module *owner)
> {
> 	...
> 	mgr->owner = owner;
> }

Yes.

But again, is a module owner even needed?  I don't think you all have
proven that yet...

thanks,

greg k-h