All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Alejandro Lucero Palau <alucerop@amd.com>
Cc: <alejandro.lucero-palau@amd.com>, <linux-cxl@vger.kernel.org>,
	<netdev@vger.kernel.org>, <dan.j.williams@intel.com>,
	<edward.cree@amd.com>, <davem@davemloft.net>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <edumazet@google.com>,
	<dave.jiang@intel.com>,
	"Ben Cheatham" <benjamin.cheatham@amd.com>
Subject: Re: [PATCH v12 05/23] cxl: add function for type2 cxl regs setup
Date: Tue, 15 Apr 2025 17:34:27 +0100	[thread overview]
Message-ID: <20250415173427.00001dfc@huawei.com> (raw)
In-Reply-To: <320c4b16-2029-4792-9288-8ccf99bf07cd@amd.com>


> 
> >> +	 */
> >> +	if (rc == -ENODEV)
> >> +		return 0;  
> > Hmm. I don't mind hugely but I'd expect the -ENODEV handler in the
> > clearly accelerator specific code that follows not here.
> >
> > That would require cxl_map_device_regs() to definitely not return
> > -ENODEV though which is a bit ugly so I guess this is ok.
> >
> > I'm not entirely convinced this helper makes sense though given
> > the 2 parts of the component regs are just done inline in
> > cxl_pci_accel_setup_regs() and if you did that then this
> > accelerator specific 'carry on anyway' would be in the function
> > with accel in the name.
> >
> > 	You'd need a
> > 	rc = cxl_pci_setup_regs(pdev, CXL_REGLOC_RBI_MEMDEV, &map, caps);
> > 	if (rc) {
> > 		if (rc != -ENODEV)
> > 			return rc;
> > 	} else {
> > 		rc = cxl_map_device_regs();
> > 		if (rc)
> > 			return rc;	
> > 	}	
> > though which is a little messy.  
> 
> 
> That messiness is the reason I added the other function keeping, I 
> think, the code clearer.
> 
> Note that other function is only used by accel code, but I can change 
> the name for making it more visible:
> 
> 
> cxl_pci_setup_memdev_regs  ---> cxl_accel_setup_memdev_regs
That works.

> 
> 
> >> +
> >> +	if (rc)
> >> +		return rc;
> >> +
> >> +	return cxl_map_device_regs(&map, &cxlds->regs.device_regs);
> >> +}
> >> +
> >> +int cxl_pci_accel_setup_regs(struct pci_dev *pdev, struct cxl_dev_state *cxlds,
> >> +			      unsigned long *caps)
> >> +{
> >> +	int rc;
> >> +
> >> +	rc = cxl_pci_setup_memdev_regs(pdev, cxlds, caps);
> >> +	if (rc)
> >> +		return rc;
> >> +
> >> +	rc = cxl_pci_setup_regs(pdev, CXL_REGLOC_RBI_COMPONENT,
> >> +				&cxlds->reg_map, caps);
> >> +	if (rc) {
> >> +		dev_warn(&pdev->dev, "No component registers (%d)\n", rc);
> >> +		return rc;
> >> +	}
> >> +
> >> +	if (!caps || !test_bit(CXL_CM_CAP_CAP_ID_RAS, caps))  
> > As before. Why not just mandate caps?  If someone really doesn't
> > care they can provide a bitmap and ignore it.  Seems like a simpler
> > interface to me.  
> 
> 
> Not sure what you meant here. This is not just about knowing by the 
> caller the capabilities but also mapping the related structures if present.

I meant the !caps variable not being NULL. Just mandate that there must be a caps
bitmap passed in always.  Caller can throw away the value if it doesn't want it.

> 
> The now returned caps is useful for dealing with mandatory vs optional 
> caps which the current code targeting Type3-only can not. In other 
> words, the core code can not know if a cap missing is an error or not.
Not that. Was a much more mundane point ;)

> 
> 
> >> +		return 0;
> >> +
> >> +	rc = cxl_map_component_regs(&cxlds->reg_map,
> >> +				    &cxlds->regs.component,
> >> +				    BIT(CXL_CM_CAP_CAP_ID_RAS));
> >> +	if (rc)
> >> +		dev_dbg(&pdev->dev, "Failed to map RAS capability.\n");
> >> +
> >> +	return rc;
> >> +}
> >> +EXPORT_SYMBOL_NS_GPL(cxl_pci_accel_setup_regs, "CXL");  


  reply	other threads:[~2025-04-15 16:34 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 14:45 [PATCH v12 00/23] cxl: add type2 device basic support alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 01/23] " alejandro.lucero-palau
2025-04-01 17:36   ` Alejandro Lucero Palau
2025-04-04 15:24   ` Jonathan Cameron
2025-04-07  9:50     ` Alejandro Lucero Palau
2025-04-10  8:12       ` Alejandro Lucero Palau
2025-04-07 16:55   ` Dave Jiang
2025-03-31 14:45 ` [PATCH v12 02/23] sfc: add cxl support alejandro.lucero-palau
2025-03-31 18:31   ` Simon Horman
2025-04-07 13:59     ` Alejandro Lucero Palau
2025-04-04 15:29   ` Jonathan Cameron
2025-03-31 14:45 ` [PATCH v12 03/23] cxl: move pci generic code alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 04/23] cxl: move register/capability check to driver alejandro.lucero-palau
2025-04-04 15:47   ` Jonathan Cameron
2025-04-07 13:40     ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 05/23] cxl: add function for type2 cxl regs setup alejandro.lucero-palau
2025-03-31 18:33   ` Simon Horman
2025-04-07 14:00     ` Alejandro Lucero Palau
2025-04-04 16:03   ` Jonathan Cameron
2025-04-07 10:04     ` Alejandro Lucero Palau
2025-04-15 16:34       ` Jonathan Cameron [this message]
2025-03-31 14:45 ` [PATCH v12 06/23] sfc: make regs setup with checking and set media ready alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 07/23] cxl: support dpa initialization without a mailbox alejandro.lucero-palau
2025-04-04 16:05   ` Jonathan Cameron
2025-04-07 10:53     ` Alejandro Lucero Palau
2025-04-10 11:37       ` Alejandro Lucero Palau
2025-04-04 16:11   ` Jonathan Cameron
2025-04-07 10:56     ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 08/23] sfc: initialize dpa alejandro.lucero-palau
2025-04-04 16:12   ` Jonathan Cameron
2025-04-07 11:01     ` Alejandro Lucero Palau
2025-04-10 11:48       ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 09/23] cxl: prepare memdev creation for type2 alejandro.lucero-palau
2025-03-31 18:34   ` Simon Horman
2025-04-07 14:01     ` Alejandro Lucero Palau
2025-04-04 16:25   ` Jonathan Cameron
2025-04-11 21:07   ` Dave Jiang
2025-03-31 14:45 ` [PATCH v12 10/23] sfc: create type2 cxl memdev alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 11/23] cxl: define a driver interface for HPA free space enumeration alejandro.lucero-palau
2025-04-04 16:37   ` Jonathan Cameron
2025-04-07 13:25     ` Alejandro Lucero Palau
2025-04-11 21:30   ` Dave Jiang
2025-04-14 13:14     ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 12/23] sfc: obtain root decoder with enough HPA free space alejandro.lucero-palau
2025-04-04 16:38   ` Jonathan Cameron
2025-04-07 11:02     ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 13/23] cxl: define a driver interface for DPA allocation alejandro.lucero-palau
2025-04-04 16:41   ` Jonathan Cameron
2025-04-11 22:41   ` Dave Jiang
2025-04-14 13:28     ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 14/23] sfc: get endpoint decoder alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 15/23] cxl: make region type based on endpoint type alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 16/23] cxl/region: factor out interleave ways setup alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 17/23] cxl/region: factor out interleave granularity setup alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 18/23] cxl: allow region creation by type2 drivers alejandro.lucero-palau
2025-04-04 16:45   ` Jonathan Cameron
2025-04-07 11:03     ` Alejandro Lucero Palau
2025-04-11 23:18   ` Dave Jiang
2025-04-14 13:52     ` Alejandro Lucero Palau
2025-03-31 14:45 ` [PATCH v12 19/23] cxl: add region flag for precluding a device memory to be used for dax alejandro.lucero-palau
2025-04-11 23:25   ` Dave Jiang
2025-03-31 14:45 ` [PATCH v12 20/23] sfc: create cxl region alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 21/23] cxl: add function for obtaining region range alejandro.lucero-palau
2025-04-11 23:32   ` Dave Jiang
2025-03-31 14:45 ` [PATCH v12 22/23] sfc: update MCDI protocol headers alejandro.lucero-palau
2025-03-31 14:45 ` [PATCH v12 23/23] sfc: support pio mapping based on cxl alejandro.lucero-palau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250415173427.00001dfc@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alejandro.lucero-palau@amd.com \
    --cc=alucerop@amd.com \
    --cc=benjamin.cheatham@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=edward.cree@amd.com \
    --cc=kuba@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.