Received-SPF: pass (google.com: domain of linux-kernel+bounces-33980-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 22 Jan 2024 15:24:36 -0300
From: =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado <nfraprado@collabora.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Tzung-Bi Shih <tzungbi@kernel.org>, kernel@collabora.com,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>,
	Abhijit Gangurde <abhijit.gangurde@amd.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	Nipun Gupta <nipun.gupta@amd.com>,
	Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>,
	Umang Jain <umang.jain@ideasonboard.com>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] firmware: coreboot: Generate aliases for coreboot
 modules
Message-ID: <1ab1c936-2423-431b-bb54-49983e64fb98@notapiano>
References: <20240111151226.842603-1-nfraprado@collabora.com>
 <20240111151226.842603-3-nfraprado@collabora.com>
 <ZaQU_QqGXwkSgU_Y@smile.fi.intel.com>
 <49b42da1-a74b-433c-b018-0742f850f680@notapiano>
 <Za0Q-em5R2_9cX7q@smile.fi.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Za0Q-em5R2_9cX7q@smile.fi.intel.com>

On Sun, Jan 21, 2024 at 02:41:29PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 17, 2024 at 09:53:23AM -0300, N?colas F. R. A. Prado wrote:
> > On Sun, Jan 14, 2024 at 07:08:13PM +0200, Andy Shevchenko wrote:
> > > On Thu, Jan 11, 2024 at 12:11:47PM -0300, N?colas F. R. A. Prado wrote:
> > > > Generate aliases for coreboot modules to allow automatic module probing.
> 
> ...
> 
> > > > +/**
> > > > + * struct coreboot_device_id - Identifies a coreboot table entry
> > > > + * @tag: tag ID
> > > > + */
> > > > +struct coreboot_device_id {
> > > > +	__u32 tag;
> > > > +};
> > > 
> > > Don't you want to have a driver data or so associated with this?
> > 
> > There's no need for it currently in any driver. This struct is being created
> > simply to allow auto modprobe. So it seems reasonable to leave it out and add it
> > later when/if needed.
> 
> The problem is that you introduce a kinda ABI here, how do you handle this later?

Sorry, but I don't follow. What ABI is there to guarantee stability for here?
This header is not exported to userspace (not under uapi/). Only kernel code
will make use of this struct and it can be updated whenever this struct is
changed without anything breaking.

Thanks,
N?colas