From 6c9d9f7dfa711db0ff662f6467eda8b056dc51c8 Mon Sep 17 00:00:00 2001
From: Robin Mueller <robin.mueller.m@gmail.com>
Date: Thu, 11 Nov 2021 18:18:40 +0100
Subject: [PATCH] smaller tweaks and updates

---
 src/gpio/mod.rs  |  8 ++++----
 src/gpio/pins.rs | 17 ++++-------------
 2 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/src/gpio/mod.rs b/src/gpio/mod.rs
index 69e49df..fd4f8de 100644
--- a/src/gpio/mod.rs
+++ b/src/gpio/mod.rs
@@ -3,10 +3,10 @@
 //! The implementation of this GPIO module is heavily based on the
 //! [ATSAMD HAL implementation](https://docs.rs/atsamd-hal/0.13.0/atsamd_hal/gpio/v2/index.html).
 //!
-//! This API provides two different submodules, [`pin`] and [`dynpin`],
-//! representing two different ways to handle GPIO pins. The default, [`pin`],
+//! This API provides two different submodules, [`pins`] and [`dynpins`],
+//! representing two different ways to handle GPIO pins. The default, [`pins`],
 //! is a type-level API that tracks the state of each pin at compile-time. The
-//! alternative, [`dynpin`] is a type-erased, value-level API that tracks the
+//! alternative, [`dynpins`] is a type-erased, value-level API that tracks the
 //! state of each pin at run-time.
 //!
 //! The type-level API is strongly preferred. By representing the state of each
@@ -14,7 +14,7 @@
 //! compile-time. Furthermore, the type-level API has absolutely zero run-time
 //! cost.
 //!
-//! If needed, [`dynpin`] can be used to erase the type-level differences
+//! If needed, [`dynpins`] can be used to erase the type-level differences
 //! between pins. However, by doing so, pins must now be tracked at run-time,
 //! and each pin has a non-zero memory footprint.
 //!
diff --git a/src/gpio/pins.rs b/src/gpio/pins.rs
index 681c1cd..6656087 100644
--- a/src/gpio/pins.rs
+++ b/src/gpio/pins.rs
@@ -84,15 +84,8 @@
 //! This module also provides additional, type-level tools to work with GPIO
 //! pins.
 //!
-//! The [`OptionalPinId`] and [`OptionalPin`] traits use the [`OptionalKind`]
-//! pattern to act as type-level versions of [`Option`] for `PinId` and `Pin`
-//! respectively. And the [`AnyPin`] trait defines an [`AnyKind`] type class
+//! The [`AnyPin`] trait defines an [`AnyKind`] type class
 //! for all `Pin` types.
-//!
-//! [type classes]: crate::typelevel#type-classes
-//! [type-level enum]: crate::typelevel#type-level-enum
-//! [`OptionalKind`]: crate::typelevel#optionalkind-trait-pattern
-//! [`AnyKind`]: crate::typelevel#anykind-trait-pattern
 
 use super::dynpins::{DynAlternate, DynGroup, DynInput, DynOutput, DynPinId, DynPinMode};
 use super::reg::RegisterInterface;
@@ -115,14 +108,12 @@ pub enum PinState {
 }
 
 /// GPIO error type
-///
-/// [`DynPin`]s are not tracked and verified at compile-time, so run-time
-/// operations are fallible. This `enum` represents the corresponding errors.
 #[derive(Debug, PartialEq)]
 pub enum PinError {
-    /// The pin did not have the correct ID or mode for the requested operation
+    /// The pin did not have the correct ID or mode for the requested operation.
+    /// [`DynPin`](crate::gpio::DynPin)s are not tracked and verified at compile-time, so run-time
+    /// operations are fallible.
     InvalidPinType,
-    InputDisabledForOutput,
     IsMasked,
 }