A few more doc cleanups

Author: nyurik

embedded-hal-bus/src/i2c/critical_section.rs

@@ -4,7 +4,7 @@ use embedded_hal::i2c::{ErrorType, I2c};
 
 /// `critical-section`-based shared bus [`I2c`] implementation.
 ///
-/// Sharing is implemented with a `critical-section` [`Mutex`](critical_section::Mutex). A critical section is taken for
+/// Sharing is implemented with a `critical-section` [`Mutex`]. A critical section is taken for
 /// the entire duration of a transaction. This allows sharing a single bus across multiple threads (interrupt priority levels).
 /// The downside is critical sections typically require globally disabling interrupts, so `CriticalSectionDevice` will likely
 /// negatively impact real-time properties, such as interrupt latency. If you can, prefer using

embedded-hal-bus/src/i2c/mutex.rs

@@ -3,7 +3,7 @@ use std::sync::Mutex;
 
 /// `std` `Mutex`-based shared bus [`I2c`] implementation.
 ///
-/// Sharing is implemented with an `std` [`Mutex`](std::sync::Mutex). It allows a single bus across multiple threads,
+/// Sharing is implemented with an `std` [`Mutex`]. It allows a single bus across multiple threads,
 /// with finer-grained locking than [`CriticalSectionDevice`](super::CriticalSectionDevice). The downside is that
 /// it is only available in `std` targets.
 #[cfg_attr(docsrs, doc(cfg(feature = "std")))]

embedded-hal-bus/src/spi/critical_section.rs

@@ -8,10 +8,10 @@ use super::DeviceError;
 
 /// `critical-section`-based shared bus [`SpiDevice`] implementation.
 ///
-/// This allows for sharing an [`SpiBus`](embedded_hal::spi::SpiBus), obtaining multiple [`SpiDevice`] instances,
+/// This allows for sharing an [`SpiBus`], obtaining multiple [`SpiDevice`] instances,
 /// each with its own `CS` pin.
 ///
-/// Sharing is implemented with a `critical-section` [`Mutex`](critical_section::Mutex). A critical section is taken for
+/// Sharing is implemented with a `critical-section` [`Mutex`]. A critical section is taken for
 /// the entire duration of a transaction. This allows sharing a single bus across multiple threads (interrupt priority levels).
 /// The downside is critical sections typically require globally disabling interrupts, so `CriticalSectionDevice` will likely
 /// negatively impact real-time properties, such as interrupt latency. If you can, prefer using

embedded-hal-bus/src/spi/exclusive.rs

@@ -13,7 +13,7 @@ use super::DeviceError;
 
 /// [`SpiDevice`] implementation with exclusive access to the bus (not shared).
 ///
-/// This is the most straightforward way of obtaining an [`SpiDevice`] from an [`SpiBus`](embedded_hal::spi::SpiBus),
+/// This is the most straightforward way of obtaining an [`SpiDevice`] from an [`SpiBus`],
 /// ideal for when no sharing is required (only one SPI device is present on the bus).
 pub struct ExclusiveDevice<BUS, CS, D> {
     bus: BUS,

embedded-hal-bus/src/spi/mutex.rs

@@ -7,10 +7,10 @@ use super::DeviceError;
 
 /// `std` `Mutex`-based shared bus [`SpiDevice`] implementation.
 ///
-/// This allows for sharing an [`SpiBus`](embedded_hal::spi::SpiBus), obtaining multiple [`SpiDevice`] instances,
+/// This allows for sharing an [`SpiBus`], obtaining multiple [`SpiDevice`] instances,
 /// each with its own `CS` pin.
 ///
-/// Sharing is implemented with a `std` [`Mutex`](std::sync::Mutex). It allows a single bus across multiple threads,
+/// Sharing is implemented with a `std` [`Mutex`]. It allows a single bus across multiple threads,
 /// with finer-grained locking than [`CriticalSectionDevice`](super::CriticalSectionDevice). The downside is
 /// it is only available in `std` targets.
 #[cfg_attr(docsrs, doc(cfg(feature = "std")))]

embedded-hal-bus/src/spi/refcell.rs

@@ -7,7 +7,7 @@ use super::DeviceError;
 
 /// `RefCell`-based shared bus [`SpiDevice`] implementation.
 ///
-/// This allows for sharing an [`SpiBus`](embedded_hal::spi::SpiBus), obtaining multiple [`SpiDevice`] instances,
+/// This allows for sharing an [`SpiBus`], obtaining multiple [`SpiDevice`] instances,
 /// each with its own `CS` pin.
 ///
 /// Sharing is implemented with a `RefCell`. This means it has low overhead, but `RefCellDevice` instances are not `Send`,