a few weeks ago i already asked this here but never got a definitive answer, so here's another attempt: what is the recommended way for drivers to propagate e-h errors to their consumers? should they bubble up each individual error type or should they just wrap it up in a generic "hardware said no" error as the consumer likely anyway can't do anything about it? even more so if it's about GPIO pins which are infallible in 99.x% of the cases.
it's about [this PR](https://github.com/rust-embedded-community/tb6612fng-rs/pull/37) from ripytide which i'd finally like to get merged (either as it is or by adapting it to a single generic error type)

i think there should be a general guideline/recommendation for this as it affects all `embedded-hal` based drivers.

(sorry, i had wanted to bring this up in yesterday's meeting but then couldn't make it)