>[оверквотинг удален]
> Кажется да.
> Если кратко: массив ool_workarounds (см. drivers/clocksource/arm_arch_timer.c) содержит
> записи со всеми доступными хуками. Каждая запись содержит в себе данные
> для сличения с devicetree и идентификаторы функций (содержаться в том же
> файле). Когда будет производится инициализация таймера, массив ool_workarounds будет
> прокручен в цикле, и каждая запись будет (по очереди) проверена на
> предмет соответствия данным из devicetree. И если соответствующая запись будет найдена,
> то в качестве хуков будут установлены те функции, которые в ней
> обозначены. Это если очень просто. Я сам не то, чтобы профессиональный
> разработчик ядра, мог напутать с терминологией.

В эти дебри я вообще не вникал за ненадобностью. arch_timer_iterate_errata() вызывается 1 раз (код я привёл выше) и, судя по имени функции, результат применяется только для проблемного железа.

Для беспроблемного железа (определённая модель телефона, одноплатника и т.п.) можно вообще это всё убрать из ядра конфигом.

> Короче, ребятки приняли devicetree как источник информации о необходимости применения
> хуков, в т.ч. к системным вызовам. В случае с таймером всё
> ещё +/- нормально, так как это действо происходит только при инициализации
> таймера.

Насколько понимаю, это обычная практика. Точно так же на IA/AMD64 из ACPI, DMI и VID/PID определяется, надо ли применять qurks для другого оборудования.

>[оверквотинг удален]
>   _retries--;      \
>  } while (((_val + 1) & GENMASK(8, 0)) <= 1 &&
> _retries); \
>          \
>  WARN_ON_ONCE(!_retries);     \
>  _val;        \
> })
>
> Вот с таким кодом только о производительности таймера и рассуждать. И об
> предсказуемости времени получения с него корректных результатов.

Так если в каком-то частном случае с железом есть проблема, её приходится обходить, что бы хоть как-то работало.