[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ed8114c231d1423893d3c90c458f35f3@realtek.com>
Date: Mon, 28 Oct 2024 01:44:21 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
CC: "kvalo@...nel.org" <kvalo@...nel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"kernel@...ccoli.net" <kernel@...ccoli.net>,
"kernel-dev@...lia.com" <kernel-dev@...lia.com>,
"stable@...r.kernel.org"
<stable@...r.kernel.org>,
"syzbot+edd9fe0d3a65b14588d5@...kaller.appspotmail.com"
<syzbot+edd9fe0d3a65b14588d5@...kaller.appspotmail.com>
Subject: RE: [PATCH] wifi: rtlwifi: Drastically reduce the attempts to read efuse bytes in case of failures
Guilherme G. Piccoli <gpiccoli@...lia.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.
Powered by blists - more mailing lists