Re: [RFC PATCH v1 12/38] coco: host: arm64: CCA host platform device driver

[Jonathan Cameron]

On Wed, 30 Jul 2025 14:28:55 +0530
Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxx> wrote:

> Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> writes:
> 
> > On Mon, 28 Jul 2025 19:21:49 +0530
> > "Aneesh Kumar K.V (Arm)" <aneesh.kumar@xxxxxxxxxx> wrote:
> >  
> 
> ...
> 
> >> +
> >> +#include "rmm-da.h"
> >> +
> >> +/* Number of streams that we can support at the hostbridge level */
> >> +#define CCA_HB_PLATFORM_STREAMS 4
> >> +
> >> +/* Total number of stream id supported at root port level */
> >> +#define MAX_STREAM_ID	256
> >> +
> >> +DEFINE_FREE(vfree, void *, if (!IS_ERR_OR_NULL(_T)) vfree(_T))
> >> +static struct pci_tsm *cca_tsm_pci_probe(struct pci_dev *pdev)
> >> +{
> >> +	int rc;
> >> +	struct pci_host_bridge *hb;
> >> +	struct cca_host_dsc_pf0 *dsc_pf0 __free(vfree) = NULL;  
> >
> > Read the stuff in cleanup.h and work out why this needs
> > changing to be inline below and not use this NULL pattern here
> > (unless you like grumpy Linus ;)
> >
> > Note that with the err_out, even if you do that you'll still be
> > breaking with the guidance doc (and actually causing undefined
> > behavior :)  Get rid of those gotos if you want to use __free()
> >
> >  
> 
> I’ve already fixed up similar cases by removing the goto based on cleanup.h
> docs in other functions.I must have missed this one.
> 
> By the way, isn't using the `NULL` pattern acceptable when there are
> no additional lock variables involved (ie, unwind order doesn't matter)?
> Or should we always follow the pattern below regardless?
> 
> 	struct cca_host_dsc_pf0 *dsc_pf0 __free(vfree) =
> 		vcalloc(sizeof(*dsc_pf0), GFP_KERNEL);

Always do this.  It's not really about what happens today but
more what we might break by failing to notice a future patch causes
problems.  Keeping the unwind ordering tightly couple with setup
means we basically can't get it wrong (famous last words ;)

Jonathan


> 
> -aneesh