summaryrefslogtreecommitdiff
path: root/rust
diff options
context:
space:
mode:
authorHugo Villeneuve <hvilleneuve@dimonoff.com>2024-01-17 00:29:59 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-01-28 06:09:10 +0300
commit93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 (patch)
treed28548f0ee12feea6a183cf6dfe83a02097a097f /rust
parent0419373333c2f2024966d36261fd82a453281e80 (diff)
downloadlinux-93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965.tar.xz
serial: max310x: improve crystal stable clock detection
Some people are seeing a warning similar to this when using a crystal: max310x 11-006c: clock is not stable yet The datasheet doesn't mention the maximum time to wait for the clock to be stable when using a crystal, and it seems that the 10ms delay in the driver is not always sufficient. Jan Kundrát reported that it took three tries (each separated by 10ms) to get a stable clock. Modify behavior to check stable clock ready bit multiple times (20), and waiting 10ms between each try. Note: the first draft of the driver originally used a 50ms delay, without checking the clock stable bit. Then a loop with 1000 retries was implemented, each time reading the clock stable bit. Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") Cc: stable@vger.kernel.org Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'rust')
0 files changed, 0 insertions, 0 deletions