Re: [PATCH v6 2/5] powerpc/pseries/eeh: Add RTAS error injection helpers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] powerpc/pseries/eeh: static RTAS helpers defined without callers
--

commit 8b171281b038661dc89a614c1b95db68271706f4
Author: Narayana Murty N <nnmlinux@linux.ibm.com>

powerpc/pseries/eeh: Add RTAS error injection helpers

This patch adds static RTAS error injection helper functions,
pseries_eeh_type_to_rtas() and validate_addr_mask_in_pe(), to prepare
the pSeries EEH backend for RTAS-based error injection.

Closes: https://lore.kernel.org/oe-kbuild-all/202512101130.EYUo0oZx-lkp@intel.com/

> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
> index b12ef382fec70..28b1fd19e8bcd 100644
> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c

[ ... ]

> @@ -786,6 +789,137 @@ static int pseries_notify_resume(struct eeh_dev *edev)
>  }
>  #endif
>  
> +/*
> + * RTAS firmware error-type encodings (PAPR).  These are pseries-private;
> + * user-space sees only the generic EEH_ERR_TYPE_* values from eeh.h.
> + * Only IOA bus-error types are supported; other PAPR encodings are not
> + * reachable through the generic EEH_ERR_TYPE_* UAPI.
> + */
> +#define RTAS_ERR_TYPE_IOA_BUS_ERROR		0x07
> +#define RTAS_ERR_TYPE_IOA_BUS_ERROR_64		0x0f
> +
> +/* Size of the ibm,errinjct work buffer as defined by PAPR */
> +#define RTAS_ERRINJCT_BUF_SIZE			SZ_1K
> +
> +/**
> + * pseries_eeh_type_to_rtas - Map generic EEH error type to RTAS encoding
> + * @type: generic EEH error type (EEH_ERR_TYPE_32, EEH_ERR_TYPE_64)
> + *
> + * Translates the generic VFIO/EEH error type passed from userspace into
> + * the RTAS-specific ibm,errinjct error type encoding defined by PAPR.
> + *
> + * Return: RTAS error type on success, -EINVAL for unknown types.
> + */
> +static int pseries_eeh_type_to_rtas(int type)
> +{
> +	switch (type) {
> +	case EEH_ERR_TYPE_32:
> +		return RTAS_ERR_TYPE_IOA_BUS_ERROR;
> +	case EEH_ERR_TYPE_64:
> +		return RTAS_ERR_TYPE_IOA_BUS_ERROR_64;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +/**
> + * validate_addr_mask_in_pe - Validate addr against PCI bus BAR addresses in PE
> + * @pe:   EEH PE containing one or more PCI devices
> + * @addr: PCI bus address to validate
> + * @mask: address mask (passed to firmware unchanged)
> + *
> + * RTAS IOA bus-error injection uses PCI bus addresses.  Linux PCI resources
> + * are CPU/resource addresses and may differ on pseries due to PHB window
> + * translation.  Convert each BAR resource to PCI bus address space before
> + * validating @addr.
> + *
> + * Zero addr and mask are accepted without BAR lookup (no-address injection).
> + *
> + * Return: 0 if valid, -EINVAL on invalid input.
> + */
> +static int validate_addr_mask_in_pe(struct eeh_pe *pe, unsigned long addr,
> +				    unsigned long mask)

[Severity: Low]
Does defining pseries_eeh_type_to_rtas() and validate_addr_mask_in_pe() in
arch/powerpc/platforms/pseries/eeh_pseries.c without callers or
__maybe_unused cause a -Werror=unused-function build failure at this commit?

The commit message notes that validate_errinjct_args() and
prepare_errinjct_buffer() were deferred to the next patch ("powerpc/pseries/eeh:
Implement RTAS-based EEH error injection") and that pseries_eeh_err_inject()
retains its existing MMIO body here so each intermediate commit builds
cleanly with CONFIG_WERROR:

arch/powerpc/platforms/pseries/eeh_pseries.c:pseries_eeh_err_inject() {
	struct	eeh_dev	*pdev;

	/* Check on PCI error type */
	if (type != EEH_ERR_TYPE_32 && type != EEH_ERR_TYPE_64)
		return -EINVAL;
    ...
}

However, those deferred functions and the updated pseries_eeh_err_inject() are
the only callers of pseries_eeh_type_to_rtas() and validate_addr_mask_in_pe().
When building with CONFIG_PPC_PSERIES=y and CONFIG_PPC_WERROR=y (in
arch/powerpc/Kbuild) or CONFIG_WERROR=y (in scripts/Makefile.warn), won't
this commit fail to compile with -Werror=unused-function until the follow-up
patch adds their callers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023073642.59657-1-nnmlinux@linux.ibm.com?part=2