From: Ping-Ke Shih <pkshih@realtek.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: "kvalo@kernel.org" <kvalo@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel@gpiccoli.net" <kernel@gpiccoli.net>,
"kernel-dev@igalia.com" <kernel-dev@igalia.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com"
<syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com>
Subject: RE: [PATCH] wifi: rtlwifi: Drastically reduce the attempts to read efuse bytes in case of failures
Date: Mon, 28 Oct 2024 01:44:21 +0000 [thread overview]
Message-ID: <ed8114c231d1423893d3c90c458f35f3@realtek.com> (raw)
In-Reply-To: <20241025150226.896613-1-gpiccoli@igalia.com>
Guilherme G. Piccoli <gpiccoli@igalia.com> wrote:
>
> This procedure for reading efuse bytes relies in a loop that performs an
> I/O read up to *10k* times in case of failures. We measured the time of
> the loop inside read_efuse_byte() alone, and in this reproducer (which
> involves the dummy_hcd emulation layer), it takes 15 seconds each.
The I/O read of 10k times is to polling if efuse is ready, and then following
statement is to actually read efuse content back. For USB devices, I/O is
slow, so it might be fine to reduce retry times. But For PCIE devices,
I think this will be risky without testing with real hardware.
Possible way is to use "rtlhal->interface == INTF_PCI" to keep original times
for PCIE devices, and only reduce retry times for USB devices. But USB can
operate on USB-2/-3 modes, so maybe still need experiments with real hardware
to get reasonable retry times.
next prev parent reply other threads:[~2024-10-28 1:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 15:02 [PATCH] wifi: rtlwifi: Drastically reduce the attempts to read efuse bytes in case of failures Guilherme G. Piccoli
2024-10-28 1:44 ` Ping-Ke Shih [this message]
2024-10-28 14:39 ` Guilherme G. Piccoli
2024-10-29 0:50 ` Ping-Ke Shih
2024-10-29 13:20 ` Bitterblue Smith
2024-10-29 13:31 ` Guilherme G. Piccoli
2024-10-29 16:55 ` Bitterblue Smith
2024-10-29 17:58 ` Guilherme G. Piccoli
2024-10-30 13:17 ` Bitterblue Smith
2024-10-30 14:16 ` Guilherme G. Piccoli
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=ed8114c231d1423893d3c90c458f35f3@realtek.com \
--to=pkshih@realtek.com \
--cc=gpiccoli@igalia.com \
--cc=kernel-dev@igalia.com \
--cc=kernel@gpiccoli.net \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.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.