public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stanley Chang[昌育德]" <stanley_chang@realtek.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Ray Chi <raychi@google.com>,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	Eugeniu Rosca <erosca@de.adit-jv.com>,
	Michael Grzeschik <m.grzeschik@pengutronix.de>,
	Matthias Kaehlcke <mka@chromium.org>,
	Flavio Suligoi <f.suligoi@asem.it>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Bhuvanesh Surachari <Bhuvanesh_Surachari@mentor.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Linus Walleij <linus.walleij@linaro.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: RE: [PATCH v1 2/3] usb: phy: Add driver for the Realtek SoC USB 2.0/3.0 PHY
Date: Fri, 19 May 2023 10:40:59 +0000	[thread overview]
Message-ID: <6b415b1157ca4724a6e94657dff918b2@realtek.com> (raw)
In-Reply-To: <ed53d7d6-78e7-45af-a441-1c87fba4d420@app.fastmail.com>

Hi Arnd,

> > +#ifdef CONFIG_DEBUG_FS
> > +     struct dentry *debug_dir;
> > +#endif
> > +};
> 
> I'd avoid the #ifdefs here and just leave the debugfs code in unconditionally in
> favor of readability. When debugfs is disabled, everything except for the one
> pointer value should get optimized out.

I will remove this #ifdef.

> > +#define phy_read(addr) __raw_readl(addr) #define phy_write(addr, val)
> > +do { \
> > +     /* Do smp_wmb */ \
> > +     smp_wmb(); __raw_writel(val, addr); \ } while (0)
> 
> Using __raw_readl()/__raw_writel() in a driver is almost never the right
> interface, it does not guarantee atomicity of the access, has the wrong
> byte-order on big-endian kernels and misses the barriers to serialize against
> DMA accesses. smp_wmb() should have no effect here since this only serializes
> access to memory against another CPU if it's paired with an smp_rmb(), but
> not on MMIO registers.

I will try using readl/writel directly.

> > +#define PHY_IO_TIMEOUT_MSEC          (50)
> > +
> > +static inline int utmi_wait_register(void __iomem *reg, u32 mask, u32
> > result)
> > +{
> > +     unsigned long timeout = jiffies +
> > msecs_to_jiffies(PHY_IO_TIMEOUT_MSEC);
> > +
> > +     while (time_before(jiffies, timeout)) {
> > +             /* Do smp_rmb */
> > +             smp_rmb();
> > +             if ((phy_read(reg) & mask) == result)
> > +                     return 0;
> > +             udelay(100);
> > +     }
> > +     pr_err("\033[0;32;31m can't program USB phy \033[m\n");
> > +
> > +     return -ETIMEDOUT;
> > +}
> 
> This should just use read_poll_timeout() or possibly
> read_poll_timeout_atomic(), but not an open-coded version.
> 
I've tried using read_poll_timeout() instead and it works.

> I don't think I've seen escape sequences in a printk in any other driver, so
> please don't start that now.

Okay. I will remove it.

> > +#define DEFAULT_CHIP_REVISION 0xA00
> > +#define MAX_CHIP_REVISION 0xC00
> > +
> > +static inline int __get_chip_revision(void) {
> > +     int chip_revision = 0xFFF;
> > +     char revision[] = "FFF";
> > +     struct soc_device_attribute soc_att[] = {{.revision = revision},
> > +{}};
> 
> You should probably check that you are actually on the right SoC type here as
> well, not just the right revision of an arbitrary chip.
> 
> Ideally I think the revision check should be based off a DT proporty if that's
> possible, so you can have this code in the boot loader.

In this case I just care in the chip version number.
Because the revision number is not recorded in the DTB.

> > +#define RTK_USB2PHY_NAME "rtk-usb2phy"
> 
> Better avoid hiding the driver name like this, it makes it harder to grep the
> source tree for particular driver names.

I will remove this coding style.

> > +     /* rmb for reg read */
> > +     smp_rmb();
> > +     regVal = phy_read(reg_gusb2phyacc0);
> 
> I would expect that you don't need barriers like this, especially if you change
> the phy_read() helper to use the proper readl().
> 
> If you do need to serialize against other CPUs, still, there should be a longer
> explanation about that, since it's so unexpected.

I will use readl to instead the phy_read and remove smp_rmb.

> > +
> > +static void do_rtk_usb2_phy_toggle(struct rtk_usb_phy *rtk_phy,
> > +         int index, bool isConnect);
> 
> It's best to sort your function definitions in a way that avoids forward
> declarations. This makes it easier to read and shows that there are no obvious
> recursions in the source. If you do have an intentional recursion, make sure that
> there is a way to prevent unbounded stack usage, and explain that in a
> comment.

Ok, I'll move this function to just before the first use.


> > +     regAddr = &((struct reg_addr *)rtk_phy->reg_addr)[index];
> > +     phy_data = &((struct phy_data *)rtk_phy->phy_data)[index];

> Why do you need the casts here? It looks like regAddr should be an __iomem
> pointer. Please build your driver with 'make C=1'
> to see if there are any incorrect address space annotations.

I define member reg_addr as
void *reg_addr
So I have to convert it to "struct reg_addr" and use it as array.
And I ran "make C=1" with no error or warning.

> > +static int __get_phy_parameter_by_efuse(struct rtk_usb_phy *rtk_phy,
> > +         struct phy_data *phy_data, int index) {
> > +     u8 value = 0;
> > +     struct nvmem_cell *cell;
> > +     struct soc_device_attribute rtk_soc_groot[] = {
> > +                     { .family = "Realtek Groot",},
> > +                     { /* empty */ }
> > +             };
> > +     struct soc_device_attribute rtk_soc_hank[] = {
> > +                     { .family = "Realtek Hank",},
> > +                     { /* empty */ }
> > +             };
> > +     struct soc_device_attribute rtk_soc_efuse_v1[] = {
> > +                     { .family = "Realtek Phoenix",},
> > +                     { .family = "Realtek Kylin",},
> > +                     { .family = "Realtek Hercules",},
> > +                     { .family = "Realtek Thor",},
> > +                     { .family = "Realtek Hank",},
> > +                     { .family = "Realtek Groot",},
> > +                     { .family = "Realtek Stark",},
> > +                     { .family = "Realtek Parker",},
> > +                     { /* empty */ }
> > +             };
> > +     struct soc_device_attribute rtk_soc_dis_level_at_page0[] = {
> > +                     { .family = "Realtek Phoenix",},
> > +                     { .family = "Realtek Kylin",},
> > +                     { .family = "Realtek Hercules",},
> > +                     { .family = "Realtek Thor",},
> > +                     { .family = "Realtek Hank",},
> > +                     { .family = "Realtek Groot",},
> > +                     { /* empty */ }
> > +             };
> > +
> > +     if (soc_device_match(rtk_soc_efuse_v1)) {
> > +             dev_dbg(rtk_phy->dev, "Use efuse v1 to updated phy
> parameter\n");
> > +             phy_data->check_efuse_version = CHECK_EFUSE_V1;
> 
> I'm not entirely sure what you are trying to do here, but it looks the purpose is
> to tell the difference between implementations of the phy device by looking at
> which SoC it's in. You should only need that very rarely when this information
> cannot be passed through the DT, but you literally already have the per-SoC
> compatible strings below, so just use those, or add other DT properties in the
> binding for specific quirks or capabilities.

My purpose is to judge different SoCs and set different parameters.
The DTS property might be a good way to go, I'll check to see if it's a good fit.

> Remove that of_match_ptr() and ifdef CONFIG_OF check here, new drivers
> should no longer use static platform device definitions and just assume that
> CONFIG_OF is used.
> 
Ok, I will remove it.

Thanks,
Stanley

  reply	other threads:[~2023-05-19 10:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19  4:58 [PATCH v1 1/3] usb: phy: add usb phy notify port status API Stanley Chang
2023-05-19  4:58 ` [PATCH v1 2/3] usb: phy: Add driver for the Realtek SoC USB 2.0/3.0 PHY Stanley Chang
2023-05-19  6:28   ` Arnd Bergmann
2023-05-19 10:40     ` Stanley Chang[昌育德] [this message]
2023-05-19  8:16   ` Paul Cercueil
2023-05-19 10:58     ` Stanley Chang[昌育德]
2023-05-19 11:01       ` Arnd Bergmann
2023-05-19 17:40         ` Vinod Koul
2023-05-20  5:18           ` Stanley Chang[昌育德]
2023-05-20  5:10         ` Stanley Chang[昌育德]
2023-05-20  9:04   ` kernel test robot
2023-05-19  4:58 ` [PATCH v1 3/3] dt-bindings: phy: realtek: Add the doc about " Stanley Chang

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=6b415b1157ca4724a6e94657dff918b2@realtek.com \
    --to=stanley_chang@realtek.com \
    --cc=Bhuvanesh_Surachari@mentor.com \
    --cc=arnd@arndb.de \
    --cc=bagasdotme@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=erosca@de.adit-jv.com \
    --cc=f.suligoi@asem.it \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=mathias.nyman@linux.intel.com \
    --cc=mka@chromium.org \
    --cc=paul@crapouillou.net \
    --cc=raychi@google.com \
    --cc=robh+dt@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox