GPIO: If a common Instance trait is used for multiple peripherals, those traits should not have any logic implemented in them.

[bugadani]

This mostly covers the different Pin traits, I believe.

[tom-borcin]

Hide all pin trait methods

[bugadani]

The only relevant trait with methods is Pin. Pasting here the rustdoc output, we have these:

pub trait Pin: Sealed {
    // Required method
    fn number(&self) -> u8;

    // Provided method
    fn degrade(self) -> AnyPin
       where Self: Sized { ... }
}
pub trait InputPin:
    Pin
    + Into<AnyPin>
    + 'static { }
pub trait OutputPin:
    Pin
    + Into<AnyPin>
    + 'static { }

I think in terms of public functions, this is reasonable. The other traits are intended to be hidden by #2693

[MabezDev]

I think the only question is should number and degrade be inherent impls on each gpio struct, instead of in the trait?

I can see a world where a user uses our traits to be generic over some i/o pins and might want to access something like pin number. It's whether we expose it now, or not. We also have to be careful to not put the kitchen sink in the trait methods over the long term (this guideline should prevent us from doing this, in theory).

[bugadani]

I guess degrade is questionable - InputPin and OutputPin both implement Into<AnyPin>. fn number is as close to a GPIO fn info() as possible right now, and we don't really publish those currently, so one could argue that we can hide that as well for the sake of consistency.