linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Jim Lin <jilin@nvidia.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Petlozu Pravareshwar <petlozup@nvidia.com>,
	"mathias.nyman@intel.com" <mathias.nyman@intel.com>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	Jui Chang Kuo <jckuo@nvidia.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v5 3/3] xhci: tegra: USB2 pad power controls
Date: Fri, 28 Oct 2022 08:07:03 +0200	[thread overview]
Message-ID: <Y1txh6keM4AQJDB3@kroah.com> (raw)
In-Reply-To: <2e26a4a16122ca9129f02e03600b088f3effae47.camel@nvidia.com>

On Fri, Oct 28, 2022 at 03:11:31AM +0000, Jim Lin wrote:
> On Thu, 2022-10-27 at 16:00 +0200, Greg KH wrote:
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Thu, Oct 27, 2022 at 09:31:27PM +0800, Jim Lin wrote:
> > > Program USB2 pad PD controls during port connect/disconnect, port
> > > suspend/resume, and test mode, to reduce power consumption on
> > > disconnect or suspend.
> > > 
> > > Signed-off-by: Petlozu Pravareshwar <petlozup@nvidia.com>
> > > Signed-off-by: JC Kuo <jckuo@nvidia.com>
> > > Signed-off-by: Jim Lin <jilin@nvidia.com>
> > 
> > Who is the author here?  These do not seem to be in the correct order
> > if
> > you are the author, right?
> > > This is an old patch. Each time went with some small modification.
> 
> 
> Petlozu is author for local Kernel 3.18
> 
> Then JC for local Kernel 4.4
> Now my turn for Kernel 5.xx

Then you all need to figure out how to proper document this (hint, read
the documentation for how to do that...)

> > > ---
> > > v2: Fix issue that wrong tegra->phys[] may be accessed on tegra124
> > > v3: No change on copyright
> > > v4: Remove hcd_to_tegra_xusb() function which is used only once.
> > > v5: Update .hub_control in tegra_xhci_overrides (xhci-tegra.c)
> > >     Invoke xhci_hub_control() directly (xhci-tegra.c)
> > > 
> > >  drivers/usb/host/xhci-tegra.c | 131
> > > +++++++++++++++++++++++++++++++++-
> > >  1 file changed, 130 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-
> > > tegra.c
> > > index c8af2cd2216d..f685bb7459ba 100644
> > > --- a/drivers/usb/host/xhci-tegra.c
> > > +++ b/drivers/usb/host/xhci-tegra.c
> > > @@ -189,6 +189,13 @@ struct tegra_xusb_context_soc {
> > >       } fpci;
> > >  };
> > > 
> > > +enum tegra_xhci_phy_type {
> > > +     USB3_PHY,
> > > +     USB2_PHY,
> > > +     HSIC_PHY,
> > > +     MAX_PHY_TYPES,
> > > +};
> > > +
> > >  struct tegra_xusb_soc {
> > >       const char *firmware;
> > >       const char * const *supply_names;
> > > @@ -274,6 +281,7 @@ struct tegra_xusb {
> > > 
> > >       bool suspended;
> > >       struct tegra_xusb_context context;
> > > +     u32 enable_utmi_pad_after_lp0_exit;
> > 
> > This is a bitfield, how do we know it will fit in a u32?  What is the
> > range you are putting in here?
> > 
> > thanks,
> > 
> > greg k-h
> static void tegra_xhci_program_utmi_power_lp0_exit(struct tegra_xusb
> *tegra)
> {
> 	unsigned int i;
> 
> 	for (i = 0; i < tegra->soc->phy_types[USB2_PHY].num; i++) {
> 		if (!is_host_mode_phy(tegra, USB2_PHY, i))
> 			continue;
> 		/* USB2 */
> 		if (tegra->enable_utmi_pad_after_lp0_exit & BIT(i))
> :
> How many bits to be used is based on tegra->soc-
> >phy_types[USB2_PHY].num which is defined like
> 
> static const struct tegra_xusb_phy_type tegra210_phy_types[] = {
> :
> 	{ .name = "usb2", .num = 4, },
> :
> };
> 
> static const struct tegra_xusb_phy_type tegra194_phy_types[] = {
> :
> 	{ .name = "usb2", .num = 4, },
> };
> , so far at most 4.
> 
> Therefore u8 for enable_utmi_pad_after_lp0_exit is long enough.

I am sorry, I do not understand.  If you are needing to treat this as a
bitfield, then properly define it that way so it is obvious what is
happening.

As it is, this is very confusing and I do not understand what is going
on at all.  What is the relationship to "num" and the bit being set?
Why set a bit at all?

thanks,

greg k-h

  reply	other threads:[~2022-10-28  6:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 13:31 [PATCH v5 0/3] xhci: tegra: USB2 pad power controls Jim Lin
2022-10-27 13:31 ` [PATCH v5 1/3] xhci: hub: export symbol on xhci_hub_control Jim Lin
2022-10-27 13:58   ` Greg KH
2022-10-28  5:36     ` Jim Lin
2022-10-28  6:04       ` gregkh
2022-10-28  9:50         ` Thierry Reding
2022-10-28 10:37           ` gregkh
2022-10-28 11:08             ` Thierry Reding
2022-10-27 13:31 ` [PATCH v5 2/3] xhci: Add hub_control to xhci_driver_overrides Jim Lin
2022-10-27 13:31 ` [PATCH v5 3/3] xhci: tegra: USB2 pad power controls Jim Lin
2022-10-27 14:00   ` Greg KH
2022-10-28  3:11     ` Jim Lin
2022-10-28  6:07       ` gregkh [this message]
2022-10-28 11:03   ` Thierry Reding

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=Y1txh6keM4AQJDB3@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jckuo@nvidia.com \
    --cc=jilin@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=petlozup@nvidia.com \
    --cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).