WIP: Update embedded-hal to version 1.0.0-alpha.6

[caemor]

The delay update is pretty straightforward.

The error update is more difficult: The current implementation creates a new struct including a single element: the upstream linux error, and implement the e-h error trait for it. I've got two issues with this.
Is creating a new struct the best way to do this?
For matching the e-h trait kind: Currently I just matched everything to Other because I couldn't find any good matches when taking a quick glance. Is there something that should be matched?
The creation of a central error enum for linux e-h would be an other alternative way to solve this.

[rust-highfive]

r? @ryankurte

(rust-highfive has picked a reviewer for you, use r? to override)

[eldruin]

Nice, thank you for this PR!
The important part would be extracting information from the underlying nix/io errors in the embedded_hal::*::Error implementations so that they can be converted to a meaningful embedded_hal::*::ErrorKind.
Converting all errors to Other would render all drivers unable to act on things like i2c::NoAcknowledge.
For this one needs to dig a bit into the Linux kernel, and so on, though.

As for the error struct itself, in order to be able to implement the traits you already highlighted the possibilities:

1. Wrapper struct with the error instance.
2. Wrapper tuple with the error instance.
3. Central enum.
   3.1. With variants per protocol
   3.2. Flat with all variants in one level

I think 2 looks simpler than 1 but the code would look weirder with the .0s so I think 1 would read better. Whether the inner element should be called err error, inner or something else, I am not sure. Probably any.
I think 3 would be more complex to implement.
3.1. Would definitely more cumbersome to match for the user, as non-relevant variants would need to be matched as well (e.g. spi error variant on i2c operations).
3.2. Seems very unpractical and confusing to match for the user.
All in all, I think the current 2 approach is the right one.

[caemor]

If someone else wants to take over, go for it. I am currently missing the time to finish this.

[ryankurte]

it doesn't look to me like any of the IoErrorKinds have great correspondence with our ErrorKinds except for I2C, see changes here to match. i'd be happy to merge this then that and keep moving forward, any other opinions @rust-embedded/embedded-linux ?

[eldruin]

Ok, Let's merge this then and I will create an issue about improving the match.
@caemor could you resolve the conflict?

[eldruin]

Thank you!
bors r+

[bors]

Build succeeded:

• CI (1.46.0, x86_64-unknown-linux-gnu)
• CI (stable, armv7-unknown-linux-gnueabihf)
• CI (stable, x86_64-unknown-linux-gnu)

[ryankurte]

thanks folks! @eldruin what do you think of another alpha release to keep up with e-h?

[eldruin]

Sure. I would prefer doing #74 beforehand, though.