All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jon Hunter" <jonathanh@nvidia.com>
Cc: olteanv@gmail.com, conor+dt@kernel.org,
	devicetree@vger.kernel.org, neil.armstrong@linaro.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org, robh@kernel.org
Subject: Re: [PATCH v2 3/3] phy: tegra: Add support for Tegra238 XUSB pad controller
Date: Thu, 01 Oct 2026 13:38:33 +0000	[thread overview]
Message-ID: <20261001133833.9E0DE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001-tegra-phy-v2-3-3e453b1fb271@nvidia.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] phy: tegra: missing Makefile entry causes link failure for TEGRA_238
- [Low] phy: tegra: missing declarations cause compiler warnings
--

commit 7c86bdb1c8a3759375a713aae859eac18c35bda9
Author: Jon Hunter <jonathanh@nvidia.com>

phy: tegra: Add support for Tegra238 XUSB pad controller

This commit adds support for the Tegra238 XUSB pad controller by populating
the specific SoC data. It drops compile-time guards around Tegra186 port ops
and Tegra194 supplies to reuse them for Tegra238.

> diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
> index 0635f0d82c963..89ce9ac873006 100644
> --- a/drivers/phy/tegra/xusb.c
> +++ b/drivers/phy/tegra/xusb.c
[ ... ]
> @@ -78,6 +78,12 @@ static const struct of_device_id tegra_xusb_padctl_of_match[] = {
>  		.data = &tegra234_xusb_padctl_soc,
>  	},
>  #endif
> +#if defined(CONFIG_ARCH_TEGRA_238_SOC)
> +	{
> +		.compatible = "nvidia,tegra238-xusb-padctl",
> +		.data = &tegra238_xusb_padctl_soc,
> +	},
> +#endif

[Severity: Low]
Will this result in a link failure if a kernel is configured with only
CONFIG_ARCH_TEGRA_238_SOC enabled?

The tegra238_xusb_padctl_soc structure is defined in xusb-tegra186.c, but it
does not appear that drivers/phy/tegra/Makefile was updated to compile
xusb-tegra186.o when CONFIG_ARCH_TEGRA_238_SOC is set. If the other Tegra SoCs
are disabled, the object file might be omitted, leaving this symbol undefined
during linking.

> diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
> index d8d799d9e7522..b9de4f3b57815 100644
> --- a/drivers/phy/tegra/xusb.h
> +++ b/drivers/phy/tegra/xusb.h
[ ... ]
> @@ -514,6 +514,9 @@ extern const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc;
>  #if defined(CONFIG_ARCH_TEGRA_234_SOC)
>  extern const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc;
>  #endif
> +#if defined(CONFIG_ARCH_TEGRA_238_SOC)
> +extern const struct tegra_xusb_padctl_soc tegra238_xusb_padctl_soc;
> +#endif

[Severity: Low]
Could this cause a -Wmissing-declarations warning when building
xusb-tegra186.c with CONFIG_ARCH_TEGRA_238_SOC disabled?

Since tegra238_xusb_padctl_soc is now defined and exported unconditionally in
xusb-tegra186.c, hiding its extern declaration behind this config guard will
leave the exported symbol without a visible prototype whenever the C file is
compiled for other SoCs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001-tegra-phy-v2-0-3e453b1fb271@nvidia.com?part=3

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Jon Hunter" <jonathanh@nvidia.com>
Cc: olteanv@gmail.com, conor+dt@kernel.org,
	devicetree@vger.kernel.org, neil.armstrong@linaro.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org, robh@kernel.org
Subject: Re: [PATCH v2 3/3] phy: tegra: Add support for Tegra238 XUSB pad controller
Date: Thu, 01 Oct 2026 13:38:33 +0000	[thread overview]
Message-ID: <20261001133833.9E0DE1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001-tegra-phy-v2-3-3e453b1fb271@nvidia.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] phy: tegra: missing Makefile entry causes link failure for TEGRA_238
- [Low] phy: tegra: missing declarations cause compiler warnings
--

commit 7c86bdb1c8a3759375a713aae859eac18c35bda9
Author: Jon Hunter <jonathanh@nvidia.com>

phy: tegra: Add support for Tegra238 XUSB pad controller

This commit adds support for the Tegra238 XUSB pad controller by populating
the specific SoC data. It drops compile-time guards around Tegra186 port ops
and Tegra194 supplies to reuse them for Tegra238.

> diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
> index 0635f0d82c963..89ce9ac873006 100644
> --- a/drivers/phy/tegra/xusb.c
> +++ b/drivers/phy/tegra/xusb.c
[ ... ]
> @@ -78,6 +78,12 @@ static const struct of_device_id tegra_xusb_padctl_of_match[] = {
>  		.data = &tegra234_xusb_padctl_soc,
>  	},
>  #endif
> +#if defined(CONFIG_ARCH_TEGRA_238_SOC)
> +	{
> +		.compatible = "nvidia,tegra238-xusb-padctl",
> +		.data = &tegra238_xusb_padctl_soc,
> +	},
> +#endif

[Severity: Low]
Will this result in a link failure if a kernel is configured with only
CONFIG_ARCH_TEGRA_238_SOC enabled?

The tegra238_xusb_padctl_soc structure is defined in xusb-tegra186.c, but it
does not appear that drivers/phy/tegra/Makefile was updated to compile
xusb-tegra186.o when CONFIG_ARCH_TEGRA_238_SOC is set. If the other Tegra SoCs
are disabled, the object file might be omitted, leaving this symbol undefined
during linking.

> diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
> index d8d799d9e7522..b9de4f3b57815 100644
> --- a/drivers/phy/tegra/xusb.h
> +++ b/drivers/phy/tegra/xusb.h
[ ... ]
> @@ -514,6 +514,9 @@ extern const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc;
>  #if defined(CONFIG_ARCH_TEGRA_234_SOC)
>  extern const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc;
>  #endif
> +#if defined(CONFIG_ARCH_TEGRA_238_SOC)
> +extern const struct tegra_xusb_padctl_soc tegra238_xusb_padctl_soc;
> +#endif

[Severity: Low]
Could this cause a -Wmissing-declarations warning when building
xusb-tegra186.c with CONFIG_ARCH_TEGRA_238_SOC disabled?

Since tegra238_xusb_padctl_soc is now defined and exported unconditionally in
xusb-tegra186.c, hiding its extern declaration behind this config guard will
leave the exported symbol without a visible prototype whenever the C file is
compiled for other SoCs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001-tegra-phy-v2-0-3e453b1fb271@nvidia.com?part=3

  reply	other threads:[~2026-10-01 13:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 13:28 [PATCH v2 0/3] phy: tegra: xusb: Add Tegra238 support Jon Hunter
2026-10-01 13:28 ` Jon Hunter
2026-10-01 13:28 ` [PATCH v2 1/3] dt-bindings: phy: tegra194: Add compatible for Tegra238 Jon Hunter
2026-10-01 13:28   ` Jon Hunter
2026-10-01 13:28 ` [PATCH v2 2/3] phy: tegra: xusb: Use dev_err_probe() Jon Hunter
2026-10-01 13:28   ` Jon Hunter
2026-10-01 13:28 ` [PATCH v2 3/3] phy: tegra: Add support for Tegra238 XUSB pad controller Jon Hunter
2026-10-01 13:28   ` Jon Hunter
2026-10-01 13:38   ` sashiko-bot [this message]
2026-10-01 13:38     ` sashiko-bot
2026-10-03 14:31 ` [PATCH v2 0/3] phy: tegra: xusb: Add Tegra238 support Vinod Koul
2026-10-03 14:31   ` Vinod Koul
2026-10-07 14:46   ` Jon Hunter
2026-10-07 14:46     ` Jon Hunter

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=20261001133833.9E0DE1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /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.