linux-kernel - Re: [PATCH 04/12] i2c: mux: populate the new *

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <59d32414-3859-d614-dc41-cc0a1bc63301@axentia.se>
Date:   Wed, 3 Apr 2019 15:17:12 +0000
From:   Peter Rosin <peda@...ntia.se>
To:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
CC:     "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Stefan Lengfeld <contact@...fanchrist.eu>,
        "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH 04/12] i2c: mux: populate the new *_atomic callbacks

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@...g-engineering.com>
> ---
>  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@...ntia.se>

Cheers,
Peter