RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-24 17:17:42 +00:00
Code Issues Activity Actions

Kernel: Fix m_ready_timeout calculation in NVMe

Browse source 
The CAP.TO is 0 based. Even though I don't see that mentioned in the
spec explicitly, all major OSs such as Linux, FreeBSD add 1 to the
CAP.TO while calculating the timeout.
This commit is contained in:
Pankaj Raghav 2022-01-16 09:58:59 +05:30 • committed by Idan Horowitz
parent 3441eac960
commit ba7846647c
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
Kernel/Storage/NVMe/NVMeController.cpp
View file

@ -48,7 +48,7 @@ UNMAP_AFTER_INIT ErrorOr<void> NVMeController::initialize()
m_controller_regs = TRY(Memory::map_typed_writable<volatile ControllerRegister>(PhysicalAddress(m_bar))); m_controller_regs = TRY(Memory::map_typed_writable<volatile ControllerRegister>(PhysicalAddress(m_bar)));
auto caps = m_controller_regs->cap; auto caps = m_controller_regs->cap;
m_ready_timeout = Time::from_milliseconds(CAP_TO(caps) * 500); // CAP.TO is in 500ms units m_ready_timeout = Time::from_milliseconds((CAP_TO(caps) + 1) * 500); // CAP.TO is in 500ms units
calculate_doorbell_stride(); calculate_doorbell_stride();
TRY(create_admin_queue(irq)); TRY(create_admin_queue(irq));
@ -69,7 +69,7 @@ UNMAP_AFTER_INIT ErrorOr<void> NVMeController::initialize()
bool NVMeController::wait_for_ready(bool expected_ready_bit_value) bool NVMeController::wait_for_ready(bool expected_ready_bit_value)
{ {
static constexpr size_t one_ms_io_delay = 1000; static constexpr size_t one_ms_io_delay = 1000;
auto wait_iterations = max(1, m_ready_timeout.to_milliseconds()); auto wait_iterations = m_ready_timeout.to_milliseconds();
u32 expected_rdy = expected_ready_bit_value ? 1 : 0; u32 expected_rdy = expected_ready_bit_value ? 1 : 0;
while (((m_controller_regs->csts >> CSTS_RDY_BIT) & 0x1) != expected_rdy) { while (((m_controller_regs->csts >> CSTS_RDY_BIT) & 0x1) != expected_rdy) {