The read functions have a mpu9150_results_t* argument which is a
struct with 3 int16_t members. Thus we should cast res->val instead of
just res.

The read functions have a mma8x5x_data_t* argument which is a
struct with 3 int16_t members. Thus we should cast res->val instead of
just res.

The read functions have a mag3110_data_t* argument which is a
struct with 3 int16_t members. Thus we should cast res->val instead of
just res.

The read functions have a mma7660_data_t* argument which is a
struct with 3 int16_t members. Thus we should cast res->val instead of
just res.

This follows the usual convention of having the whole params in the device
struct instead of a pointer-to. This also eliminates the need to cast a
const to a non-const pointer in the init function.

The read functions have a lsm303dlhc_3d_data_t* argument which is a
struct with 3 int16_t members. Thus we should cast res->val instead of
just res.

Converting phydat_t* to lsm6dsl_3d_data_t* is not correct, but it happened
to just work because the first struct member of phydat_t will be used.

Furthermore, casting &res[0] to int16_t* is wrong. Again, it just happened
to work.

A helper variable is added, and now all type casts are not needed anymore.

The i2c address when the pin is high/low are swapped.
This swaps them to match the datasheet and changes the default to low.

Some drivers return on netdev_driver_t::recv() not the actual frame size, but
an upper bound estimation of it. The upper layer code is already prepared to
handle that. This brings the doc in sync with the code.

Clarified in the documentation how netdev_driver_t::recv() should behave in case
the size of the buffer in parameter buf (indicated by parameter len) is to small
to fit the received frame.

netdev_driver_t::recv does on of three things:
 - Receive the frame
 - Drop it
 - Get (an estimation of) the size of the frame

The brief section of the documentation was changed to reflect this. (And it
starts with the least obvious thing in the hope readers of the API stumble upon
it...)

Removed the invalid precondition in netdev_driver_t::recv that the buffer never
NULL and the length positive. (In the "get message size" case both is wrong, in
the drop message case the first part is wrong.)

* drivers/ccs811: fix types in debug messages

* drivers/driver_ccs811_full: fix unused variable build error

With ace5db70 the IID may be gotten from
the device again. However, following the current refactoring efforts
regarding the `netdev_ieee802154` layer, the devices don't necessarily
store the address in the `netdev_ieee802154_t` struct anymore. So we
need to access the address using the driver's `get` function here
instead.

This modification changes the netdev::set function for the kw2xrf to not
propagate the NETOPT_CHANNEL to the generic netdev_ieee802154 code

This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver

This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver

This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver

This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver

This commit adds the reset of the PAN ID to the generic ieee802154 reset
function.