Apply suggestions from code review

Co-authored-by: Diego Barrios Romero <[email protected]>

Author: Dirbaio

embedded-hal/src/i2c.rs

@@ -40,16 +40,16 @@
 //!
 //! # For driver authors
 //!
-//! Drivers can be generic over `I2c<SevenBitAddress>` or `I2c<TenBitAddress>` depending
-//! on the kind of address supported by the target device. If it can use either, the driver can
+//! Drivers can select the adequate address length with `I2c<SevenBitAddress>` or `I2c<TenBitAddress>` depending
+//! on the target device. If it can use either, the driver can
 //! be generic over the address kind as well, though this is rare.
 //!
 //! Drivers should take the `I2c` instance as an argument to `new()`, and store it in their
 //! struct. They **should not** take `&mut I2c`, the trait has a blanket impl for all `&mut T`
 //! so taking just `I2c` ensures the user can still pass a `&mut`, but is not forced to.
 //!
 //! Drivers **should not** try to enable bus sharing by taking `&mut I2c` at every method.
-//! This is much less ergonomic than owning the `I2c`, and allowing the user to pass an
+//! This is much less ergonomic than owning the `I2c`, which still allows the user to pass an
 //! implementation that does sharing behind the scenes
 //! (from [`embedded-hal-bus`](https://docs.rs/embedded-hal-bus), or others).
 //!
@@ -111,8 +111,8 @@
 //! supports sharing, such as Linux or some RTOSs.)
 //!
 //! Here is an example of an embedded-hal implementation of the `I2C` trait
-//! for both modes. All trait methods have have default implementations in terms of `transaction`,
-//! so that's the only one that requires implementing.
+//! for both addressing modes. All trait methods have have default implementations in terms of `transaction`.
+//! As such, that is the only method that requires implementation in the HAL.
 //!
 //! ```
 //! use embedded_hal::i2c::{self, SevenBitAddress, TenBitAddress, I2c, Operation};