All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb <linux-usb@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH 1/1] usb: typec: tcpm: remove unused static variable 'tcpm_altmode_ops'
Date: Thu, 8 Apr 2021 11:28:09 +0300	[thread overview]
Message-ID: <YG6+mfqIc15rc9H1@kuha.fi.intel.com> (raw)
In-Reply-To: <20210407091540.2815-1-thunder.leizhen@huawei.com>

On Wed, Apr 07, 2021 at 05:15:40PM +0800, Zhen Lei wrote:
> Fixes the following W=1 kernel build warning:
> 
> drivers/usb/typec/tcpm/tcpm.c:2107:39: warning: ‘tcpm_altmode_ops’ defined but not used [-Wunused-const-variable=]
> 
> The reference to the variable 'tcpm_altmode_ops' is deleted by the
> commit a079973f462a ("usb: typec: tcpm: Remove tcpc_config configuration
> mechanism").
> 
> By the way, the static functions referenced only by the variable
> 'tcpm_altmode_ops' are deleted accordingly.
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>

Oh, I thought this was already fixed. Should this go into the stable
trees as well?

Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

> ---
>  drivers/usb/typec/tcpm/tcpm.c | 60 -------------------------------------------
>  1 file changed, 60 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index ce7af398c7c1c1f..2f89bae29c0c297 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1365,14 +1365,6 @@ static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header,
>  	mod_vdm_delayed_work(port, 0);
>  }
>  
> -static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header,
> -				    const u32 *data, int cnt)
> -{
> -	mutex_lock(&port->lock);
> -	tcpm_queue_vdm(port, header, data, cnt);
> -	mutex_unlock(&port->lock);
> -}
> -
>  static void svdm_consume_identity(struct tcpm_port *port, const u32 *p, int cnt)
>  {
>  	u32 vdo = p[VDO_INDEX_IDH];
> @@ -1705,8 +1697,6 @@ static void tcpm_handle_vdm_request(struct tcpm_port *port,
>  	 *
>  	 * And we also have this ordering:
>  	 * 1. alt-mode driver takes the alt-mode's lock
> -	 * 2. alt-mode driver calls tcpm_altmode_enter which takes the
> -	 *    tcpm port lock
>  	 *
>  	 * Dropping our lock here avoids this.
>  	 */
> @@ -2060,56 +2050,6 @@ static int tcpm_validate_caps(struct tcpm_port *port, const u32 *pdo,
>  	return 0;
>  }
>  
> -static int tcpm_altmode_enter(struct typec_altmode *altmode, u32 *vdo)
> -{
> -	struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> -	int svdm_version;
> -	u32 header;
> -
> -	svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
> -	if (svdm_version < 0)
> -		return svdm_version;
> -
> -	header = VDO(altmode->svid, vdo ? 2 : 1, svdm_version, CMD_ENTER_MODE);
> -	header |= VDO_OPOS(altmode->mode);
> -
> -	tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0);
> -	return 0;
> -}
> -
> -static int tcpm_altmode_exit(struct typec_altmode *altmode)
> -{
> -	struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> -	int svdm_version;
> -	u32 header;
> -
> -	svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
> -	if (svdm_version < 0)
> -		return svdm_version;
> -
> -	header = VDO(altmode->svid, 1, svdm_version, CMD_EXIT_MODE);
> -	header |= VDO_OPOS(altmode->mode);
> -
> -	tcpm_queue_vdm_unlocked(port, header, NULL, 0);
> -	return 0;
> -}
> -
> -static int tcpm_altmode_vdm(struct typec_altmode *altmode,
> -			    u32 header, const u32 *data, int count)
> -{
> -	struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> -
> -	tcpm_queue_vdm_unlocked(port, header, data, count - 1);
> -
> -	return 0;
> -}
> -
> -static const struct typec_altmode_ops tcpm_altmode_ops = {
> -	.enter = tcpm_altmode_enter,
> -	.exit = tcpm_altmode_exit,
> -	.vdm = tcpm_altmode_vdm,
> -};
> -
>  /*
>   * PD (data, control) command handling functions
>   */
> -- 
> 1.8.3
> 

-- 
heikki

  reply	other threads:[~2021-04-08  8:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07  9:15 [PATCH 1/1] usb: typec: tcpm: remove unused static variable 'tcpm_altmode_ops' Zhen Lei
2021-04-08  8:28 ` Heikki Krogerus [this message]
2021-04-08  8:38   ` Greg Kroah-Hartman
2021-04-08  8:44     ` Heikki Krogerus
2021-04-08 13:55   ` Guenter Roeck
2021-04-08 17:14     ` Hans de Goede
2021-04-09  9:37       ` Heikki Krogerus
2021-04-08  9:10 ` Hans de Goede
2021-04-08  9:25   ` Heikki Krogerus
2021-04-08  9:36     ` Hans de Goede
2021-04-07 21:00 kernel test robot

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=YG6+mfqIc15rc9H1@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=thunder.leizhen@huawei.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.