From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"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 11:39:42 -0300 [thread overview]
Message-ID: <61aae4ff-8f80-252e-447a-cd8a51a325a1@igalia.com> (raw)
In-Reply-To: <ed8114c231d1423893d3c90c458f35f3@realtek.com>
On 27/10/2024 22:44, Ping-Ke Shih wrote:
> 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.
>
Thanks a bunch for the review and extra details Ping-Ke Shih!
The idea of guarding with "rtlhal->interface == INTF_PCI" is very good
and I can implement in a V2.
But can you help me on finding a USB adapter that runs this path? If you
know a commodity model that uses this specific driver, could you point
me so I can buy one for testing?
Meanwhile I'll try to find a model based on some kernel reports online,
hope I can!
Cheers,
Guilherme
next prev parent reply other threads:[~2024-10-28 14:39 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
2024-10-28 14:39 ` Guilherme G. Piccoli [this message]
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=61aae4ff-8f80-252e-447a-cd8a51a325a1@igalia.com \
--to=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=pkshih@realtek.com \
--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.