diff mbox series

[v2] i2c: tegra-bpmp: ignore DMA safe buffer flag

Message ID 20210111155816.3656820-1-mperttunen@nvidia.com
State Superseded
Headers show
Series [v2] i2c: tegra-bpmp: ignore DMA safe buffer flag | expand

Commit Message

Mikko Perttunen Jan. 11, 2021, 3:58 p.m. UTC 
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(+)

Comments

Wolfram Sang Jan. 11, 2021, 9:42 p.m. UTC | #1 
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.
Mikko Perttunen Jan. 12, 2021, 10:19 a.m. UTC | #2 
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
Wolfram Sang Jan. 12, 2021, 10:26 a.m. UTC | #3 
> > 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.
Mikko Perttunen Jan. 12, 2021, 10:27 a.m. UTC | #4 
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
diff mbox series

Patch

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;
 }