Re: [PATCH 04/12] i2c: mux: populate the new *_atomic callbacks

From: Peter Rosin
Date: Wed Apr 03 2019 - 11:17:20 EST


On 2019-04-03 14:40, Wolfram Sang wrote:
> If the parent adapter has atomic_xfer callbacks, populate them for the
> mux adapter as well. We can use the same translation function as for the
> non-atomic xfer callback.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
> ---
> drivers/i2c/i2c-mux.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index f330690b4125..603252fa1284 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -310,12 +310,18 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
> else
> priv->algo.master_xfer = __i2c_mux_master_xfer;
> }
> + if (parent->algo->master_xfer_atomic)
> + priv->algo.master_xfer_atomic = priv->algo.master_xfer;
> +
> if (parent->algo->smbus_xfer) {
> if (muxc->mux_locked)
> priv->algo.smbus_xfer = i2c_mux_smbus_xfer;
> else
> priv->algo.smbus_xfer = __i2c_mux_smbus_xfer;
> }
> + if (parent->algo->smbus_xfer_atomic)
> + priv->algo.smbus_xfer_atomic = priv->algo.smbus_xfer;
> +
> priv->algo.functionality = i2c_mux_functionality;
>
> /* Now fill out new adapter structure */
>

Hmmm, what happens if a driver implements .master_xfer and relies on
emulation for SMBus, and then someone implements .smbus_xfer_atomic
to handle some corner case at power-down?

Then someone hides the power-down device behind a mux. That would end
with xfers destined for .smbus_xfer_atomic being emulated by the
non-atomic .master_xfer, no?

Maybe too weird to care about?

I guess the question is if it is allowed to have .master_xfer_atomic
but not .master_xfer (and similarly for .smbus_xfer{,_atomic})? Maybe
that decision should be made explicit? And perhaps enforced?

I don't care deeply about the above though, so feel free to do
something about it, or

Reviewed-by: Peter Rosin <peda@xxxxxxxxxx>

Cheers,
Peter