* [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag
@ 2021-01-11 15:58 Mikko Perttunen
2021-01-11 21:42 ` Wolfram Sang
0 siblings, 1 reply; 5+ messages in thread
From: Mikko Perttunen @ 2021-01-11 15:58 UTC (permalink / raw)
To: thierry.reding, jonathanh
Cc: talho, linux-i2c, linux-tegra, linux-kernel, Muhammed Fazal,
stable, Mikko Perttunen
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;
}
--
2.30.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag
2021-01-11 15:58 [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag Mikko Perttunen
@ 2021-01-11 21:42 ` Wolfram Sang
2021-01-12 10:19 ` Mikko Perttunen
0 siblings, 1 reply; 5+ messages in thread
From: Wolfram Sang @ 2021-01-11 21:42 UTC (permalink / raw)
To: Mikko Perttunen
Cc: thierry.reding, jonathanh, talho, linux-i2c, linux-tegra,
linux-kernel, Muhammed Fazal, stable
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag
2021-01-11 21:42 ` Wolfram Sang
@ 2021-01-12 10:19 ` Mikko Perttunen
2021-01-12 10:26 ` Wolfram Sang
0 siblings, 1 reply; 5+ messages in thread
From: Mikko Perttunen @ 2021-01-12 10:19 UTC (permalink / raw)
To: Wolfram Sang, Mikko Perttunen, thierry.reding, jonathanh, talho,
linux-i2c, linux-tegra, linux-kernel, Muhammed Fazal, stable
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag
2021-01-12 10:19 ` Mikko Perttunen
@ 2021-01-12 10:26 ` Wolfram Sang
2021-01-12 10:27 ` Mikko Perttunen
0 siblings, 1 reply; 5+ messages in thread
From: Wolfram Sang @ 2021-01-12 10:26 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Mikko Perttunen, thierry.reding, jonathanh, talho, linux-i2c,
linux-tegra, linux-kernel, Muhammed Fazal, stable
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
> > 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag
2021-01-12 10:26 ` Wolfram Sang
@ 2021-01-12 10:27 ` Mikko Perttunen
0 siblings, 0 replies; 5+ messages in thread
From: Mikko Perttunen @ 2021-01-12 10:27 UTC (permalink / raw)
To: Wolfram Sang, Mikko Perttunen, thierry.reding, jonathanh, talho,
linux-i2c, linux-tegra, linux-kernel, Muhammed Fazal, stable
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-12 10:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-11 15:58 [PATCH v2] i2c: tegra-bpmp: ignore DMA safe buffer flag Mikko Perttunen
2021-01-11 21:42 ` Wolfram Sang
2021-01-12 10:19 ` Mikko Perttunen
2021-01-12 10:26 ` Wolfram Sang
2021-01-12 10:27 ` Mikko Perttunen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).