From: Wen Gu <guwen@linux.alibaba.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: richardcochran@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, xuanzhuo@linux.alibaba.com,
dust.li@linux.alibaba.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2] ptp: add Alibaba CIPU PTP clock driver
Date: Mon, 30 Jun 2025 20:45:33 +0800 [thread overview]
Message-ID: <b13fd9f0-6f65-404b-9625-e431ee45ed17@linux.alibaba.com> (raw)
In-Reply-To: <0b0d3dad-3fe2-4b3a-a018-35a3603f8c10@lunn.ch>
On 2025/6/27 15:57, Andrew Lunn wrote:
>> +#define PTP_CIPU_LOG_SUB(dev, level, type, event, fmt, ...) \
>> +({ \
>> + static DEFINE_RATELIMIT_STATE(_rs, \
>> + DEFAULT_RATELIMIT_INTERVAL, \
>> + DEFAULT_RATELIMIT_BURST); \
>> + if (__ratelimit(&_rs)) \
>> + dev_printk(level, dev, "[%02x:%02x]: " fmt, \
>> + type, event, ##__VA_ARGS__); \
>> +})
>
> Please don't use such wrappers. Just use dev_dbg_ratelimited() etc.
>
Agree. This was for compatibility with older kernels, I should
change it to new helpers.. Will fix in next version. Thanks!
>> +static int cipu_iowrite8_and_check(void __iomem *addr,
>> + u8 value, u8 *res)
>> +{
>> + iowrite8(value, addr);
>> + if (value != ioread8(addr))
>> + return -EIO;
>> + *res = value;
>> + return 0;
>> +}
>
> This probably needs a comment. I assume the hardware is broken and
> sometimes writes don't work? You should state that.
>
Yes, If the cloud device thinks the written value is not what it
expected, the write will fail. I will add a comment about that, thanks.
>> +static void ptp_cipu_print_dev_events(struct ptp_cipu_ctx *ptp_ctx,
>> + int event)
>> +{
>> + struct device *dev = &ptp_ctx->pdev->dev;
>> + int type = PTP_CIPU_EVT_TYPE_DEV;
>> +
>> + switch (event) {
>> + case PTP_CIPU_EVT_H_CLK_ABN:
>> + PTP_CIPU_LOG_SUB(dev, KERN_ERR, type, event,
>> + "Atomic Clock Error Detected\n");
>> + break;
>> + case PTP_CIPU_EVT_H_CLK_ABN_REC:
>> + PTP_CIPU_LOG_SUB(dev, KERN_INFO, type, event,
>> + "Atomic Clock Error Recovered\n");
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_MT:
>> + PTP_CIPU_LOG_SUB(dev, KERN_ERR, type, event,
>> + "Maintenance Exception Detected\n");
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_MT_REC:
>> + PTP_CIPU_LOG_SUB(dev, KERN_INFO, type, event,
>> + "Maintenance Exception Recovered\n");
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_MT_TOUT:
>> + PTP_CIPU_LOG_SUB(dev, KERN_INFO, type, event,
>> + "Maintenance Exception Failed to Recover "
>> + "within %d us\n", ptp_ctx->regs.mt_tout_us);
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_BUSY:
>> + PTP_CIPU_LOG_SUB(dev, KERN_ERR, type, event,
>> + "PHC Busy Detected\n");
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_BUSY_REC:
>> + PTP_CIPU_LOG_SUB(dev, KERN_INFO, type, event,
>> + "PHC Busy Recovered\n");
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_ERR:
>> + PTP_CIPU_LOG_SUB(dev, KERN_ERR, type, event,
>> + "PHC Error Detected\n");
>> + break;
>> + case PTP_CIPU_EVT_H_DEV_ERR_REC:
>> + PTP_CIPU_LOG_SUB(dev, KERN_INFO, type, event,
>> + "PHC Error Recovered\n");
>
> Are these fatal? Or can the device still be used after these errors
> occur?
The clock can't work as expected if these events happened.
The gettime operation will get an invalid timestamp whose
PTP_CIPU_M_TS_ABN bit is set and return -EIO.
>
>> +static int ptp_cipu_enable(struct ptp_clock_info *info,
>> + struct ptp_clock_request *request, int on)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int ptp_cipu_settime(struct ptp_clock_info *p,
>> + const struct timespec64 *ts)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int ptp_cipu_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static int ptp_cipu_adjtime(struct ptp_clock_info *ptp, s64 delta)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>
> I've not looked at the core. Are these actually required? Or if they
> are missing, does the core default to -EOPNOTSUPP?
>
See reply to Vadim :)
>> +static ssize_t register_snapshot_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct ptp_cipu_ctx *ctx = pci_get_drvdata(to_pci_dev(dev));
>> + struct ptp_cipu_regs *regs = &ctx->regs;
>> +
>> + return sysfs_emit(buf, "%s 0x%x %s 0x%x %s 0x%x %s 0x%x "
>> + "%s 0x%x %s 0x%x %s 0x%x %s 0x%x %s 0x%x "
>> + "%s 0x%x %s 0x%x %s 0x%x\n",
>> + "device_features", regs->dev_feat,
>> + "guest_features", regs->gst_feat,
>> + "driver_version", regs->drv_ver,
>> + "environment_version", regs->env_ver,
>> + "device_status", regs->dev_stat,
>> + "sync_status", regs->sync_stat,
>> + "time_precision(ns)", regs->tm_prec_ns,
>> + "epoch_base(years)", regs->epo_base_yr,
>> + "leap_second(s)", regs->leap_sec,
>> + "max_latency(ns)", regs->max_lat_ns,
>> + "maintenance_timeout(us)", regs->mt_tout_us,
>> + "offset_threshold(us)", regs->thresh_us);
>> +}
>
> Is this debug? Maybe it should be placed in debugfs, rather than
> sysfs.
These are considered attributes of the CIPU ptp device, so I perfer
to put them in sysfs.
But I found sysfs prefers only one value per file [1]. The format
here may need to be improved.
[1] https://docs.kernel.org/filesystems/sysfs.html
Thank you for these comments!
Wen Gu
>
> Andrew
prev parent reply other threads:[~2025-06-30 12:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 7:29 [PATCH net-next v2] ptp: add Alibaba CIPU PTP clock driver Wen Gu
2025-06-27 7:46 ` Andrew Lunn
2025-06-30 9:04 ` Wen Gu
2025-06-27 7:57 ` Andrew Lunn
2025-06-27 10:59 ` Vadim Fedorenko
2025-06-30 11:23 ` Wen Gu
2025-06-30 13:42 ` Richard Cochran
2025-06-30 12:45 ` Wen Gu [this message]
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=b13fd9f0-6f65-404b-9625-e431ee45ed17@linux.alibaba.com \
--to=guwen@linux.alibaba.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=xuanzhuo@linux.alibaba.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.