aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/generate_rust_target.rs
diff options
context:
space:
mode:
authorHugo Villeneuve <[email protected]>2024-01-16 21:29:59 +0000
committerGreg Kroah-Hartman <[email protected]>2024-01-28 03:09:10 +0000
commit93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 (patch)
treed28548f0ee12feea6a183cf6dfe83a02097a097f /scripts/generate_rust_target.rs
parentserial: max310x: set default value when reading clock ready bit (diff)
downloadkernel-93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965.tar.gz
kernel-93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965.zip
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: [email protected] Suggested-by: Jan Kundrát <[email protected]> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Link: https://lore.kernel.org/all/[email protected]/raw Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a Signed-off-by: Hugo Villeneuve <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions