From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Pavan Chebbi <pavan.chebbi@broadcom.com>,
Vadim Fedorenko <vadfed@meta.com>
Cc: Michael Chan <michael.chan@broadcom.com>,
Jakub Kicinski <kuba@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org,
Richard Cochran <richardcochran@gmail.com>
Subject: Re: [PATCH net-next] bnxt_en: add unlocked version of bnxt_refclk_read
Date: Thu, 7 Nov 2024 11:17:34 +0000 [thread overview]
Message-ID: <90aea4dd-cb37-4dab-99ef-d45915514787@linux.dev> (raw)
In-Reply-To: <CALs4sv1VTT7L9t+BjuvW8naO7fm5Wq0qKgVkv2DW4nrNe1bucA@mail.gmail.com>
On 07/11/2024 04:30, Pavan Chebbi wrote:
> On Thu, Nov 7, 2024 at 3:02 AM Vadim Fedorenko <vadfed@meta.com> wrote:
>>
>> Serialization of PHC read with FW reset mechanism uses ptp_lock which
>> also protects timecounter updates. This means we cannot grab it when
>> called from bnxt_cc_read(). Let's move locking into different function.
>>
>> Fixes: 6c0828d00f07 ("bnxt_en: replace PTP spinlock with seqlock")
>> Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
>> ---
>> drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 29 ++++++++++++-------
>> 1 file changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
>> index f74afdab4f7d..5395f125b601 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
>> @@ -73,19 +73,15 @@ static int bnxt_ptp_settime(struct ptp_clock_info *ptp_info,
>> return 0;
>> }
>>
>> -static int bnxt_refclk_read(struct bnxt *bp, struct ptp_system_timestamp *sts,
>> - u64 *ns)
>> +/* Caller holds ptp_lock */
>> +static int __bnxt_refclk_read(struct bnxt *bp, struct ptp_system_timestamp *sts,
>> + u64 *ns)
>> {
>> struct bnxt_ptp_cfg *ptp = bp->ptp_cfg;
>> u32 high_before, high_now, low;
>> - unsigned long flags;
>>
>> - /* We have to serialize reg access and FW reset */
>> - read_seqlock_excl_irqsave(&ptp->ptp_lock, flags);
>> - if (test_bit(BNXT_STATE_IN_FW_RESET, &bp->state)) {
>> - read_sequnlock_excl_irqrestore(&ptp->ptp_lock, flags);
>> + if (test_bit(BNXT_STATE_IN_FW_RESET, &bp->state))
>> return -EIO;
>> - }
>>
>> high_before = readl(bp->bar0 + ptp->refclk_mapped_regs[1]);
>> ptp_read_system_prets(sts);
>> @@ -97,12 +93,25 @@ static int bnxt_refclk_read(struct bnxt *bp, struct ptp_system_timestamp *sts,
>> low = readl(bp->bar0 + ptp->refclk_mapped_regs[0]);
>> ptp_read_system_postts(sts);
>> }
>> - read_sequnlock_excl_irqrestore(&ptp->ptp_lock, flags);
>> *ns = ((u64)high_now << 32) | low;
>>
>> return 0;
>> }
>>
>> +static int bnxt_refclk_read(struct bnxt *bp, struct ptp_system_timestamp *sts,
>> + u64 *ns)
>> +{
>> + struct bnxt_ptp_cfg *ptp = bp->ptp_cfg;
>> + unsigned long flags;
>> + int rc;
>> +
>> + /* We have to serialize reg access and FW reset */
>> + read_seqlock_excl_irqsave(&ptp->ptp_lock, flags);
>> + rc = __bnxt_refclk_read(bp, sts, ns);
>> + read_sequnlock_excl_irqrestore(&ptp->ptp_lock, flags);
>> + return rc;
>> +}
>> +
>> static void bnxt_ptp_get_current_time(struct bnxt *bp)
>> {
>> struct bnxt_ptp_cfg *ptp = bp->ptp_cfg;
>> @@ -674,7 +683,7 @@ static u64 bnxt_cc_read(const struct cyclecounter *cc)
>> struct bnxt_ptp_cfg *ptp = container_of(cc, struct bnxt_ptp_cfg, cc);
>> u64 ns = 0;
>>
>> - bnxt_refclk_read(ptp->bp, NULL, &ns);
>> + __bnxt_refclk_read(ptp->bp, NULL, &ns);
>
> With this change, bnxt_cc_read() is executed without protection during
> timecounter_init(), right?
> I think we should hold the ptp_lock inside bnxt_ptp_timecounter_init()
> just like we do in bnxt_ptp_init_rtc()
Well, yes, that's correct. Technically we have to hold this lock (and I
will add it in v2), but if think a bit wider, do we expect
bnxt_fw_reset()/bnxt_force_fw_reset() to be called during device init
phase? If yes, we have proper time frame between bnxt_ptp_cfg allocation
in __bnxt_hwrm_ptp_qcfg() (which assigns it to bp->ptp) and spinlock
initialization in bnxt_ptp_init(), during which spinlock must not be
accessed. And if we imagine the situation when fw_reset request can be
initiated during initialization, the next flow can happen:
CPU0: CPU1:
__bnxt_hwrm_ptp_qcfg()
ptp_cfg = kzalloc()
bp->ptp = ptp_cfg
bnxt_force_fw_reset()
if (bp->ptp)
spin_lock_irqsave(bp->ptp->ptp_lock)
bnxt_ptp_init()
spinlock_init(ptp_lock)
So we either should not have an option of resetting FW during init
phase (and then there will be no need to use lock), or we have to
re-think FW reset serialization completley. WDYT?
>> return ns;
>> }
>>
>> --
>> 2.43.5
>>
next prev parent reply other threads:[~2024-11-07 11:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 21:32 [PATCH net-next] bnxt_en: add unlocked version of bnxt_refclk_read Vadim Fedorenko
2024-11-07 4:30 ` Pavan Chebbi
2024-11-07 11:17 ` Vadim Fedorenko [this message]
2024-11-07 13:11 ` Pavan Chebbi
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=90aea4dd-cb37-4dab-99ef-d45915514787@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=richardcochran@gmail.com \
--cc=vadfed@meta.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).