From: Muhammed Fazal mfazale@nvidia.com
Ignore I2C_M_DMA_SAFE flag as it does not make a difference for bpmp-i2c, but causes -EINVAL to be returned for valid transactions.
Signed-off-by: Muhammed Fazal mfazale@nvidia.com Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikko Perttunen mperttunen@nvidia.com --- v2: - Remove unnecessary check for if the bit is set --- drivers/i2c/busses/i2c-tegra-bpmp.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/i2c/busses/i2c-tegra-bpmp.c b/drivers/i2c/busses/i2c-tegra-bpmp.c index ec7a7e917edd..aa6685cabde3 100644 --- a/drivers/i2c/busses/i2c-tegra-bpmp.c +++ b/drivers/i2c/busses/i2c-tegra-bpmp.c @@ -80,6 +80,8 @@ static int tegra_bpmp_xlate_flags(u16 flags, u16 *out) flags &= ~I2C_M_RECV_LEN; }
+ flags &= ~I2C_M_DMA_SAFE; + return (flags != 0) ? -EINVAL : 0; }
On Mon, Jan 11, 2021 at 05:58:16PM +0200, Mikko Perttunen wrote:
From: Muhammed Fazal mfazale@nvidia.com
Ignore I2C_M_DMA_SAFE flag as it does not make a difference for bpmp-i2c, but causes -EINVAL to be returned for valid transactions.
I wonder if bailing out on an unknown flag shouldn't be revisited in general? I mean this will happen again when a new I2C_M_* flag is introduced.
On 1/11/21 11:42 PM, Wolfram Sang wrote:
On Mon, Jan 11, 2021 at 05:58:16PM +0200, Mikko Perttunen wrote:
From: Muhammed Fazal mfazale@nvidia.com
Ignore I2C_M_DMA_SAFE flag as it does not make a difference for bpmp-i2c, but causes -EINVAL to be returned for valid transactions.
I wonder if bailing out on an unknown flag shouldn't be revisited in general? I mean this will happen again when a new I2C_M_* flag is introduced.
If it's guaranteed that any new flags are optional to handle by the driver, than that is certainly better. I'll post a v3 with that approach.
thanks, Mikko
I wonder if bailing out on an unknown flag shouldn't be revisited in general? I mean this will happen again when a new I2C_M_* flag is introduced.
If it's guaranteed that any new flags are optional to handle by the driver, than that is certainly better. I'll post a v3 with that approach.
If there will be a new flag, it is highly likely that it will handle some corner case which only gets applied when there is a I2C_FUNC_* flag guarding it. If the new flag turns out to be mandatory, the (poor) author needs to check with all existing drivers anyhow.
On 1/12/21 12:26 PM, Wolfram Sang wrote:
I wonder if bailing out on an unknown flag shouldn't be revisited in general? I mean this will happen again when a new I2C_M_* flag is introduced.
If it's guaranteed that any new flags are optional to handle by the driver, than that is certainly better. I'll post a v3 with that approach.
If there will be a new flag, it is highly likely that it will handle some corner case which only gets applied when there is a I2C_FUNC_* flag guarding it. If the new flag turns out to be mandatory, the (poor) author needs to check with all existing drivers anyhow.
Yep, I suppose that is true :)
I just sent out the v3.
thanks! Mikko
linux-stable-mirror@lists.linaro.org
-
Mikko Perttunen -
Mikko Perttunen -
Wolfram Sang