[PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
0 and msg->len is also 0, function makes zero-length allocation, which returns
a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
code to fail. Modify the threshold to > 0 so the function returns NULL pointer.

Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
 drivers/i2c/busses/i2c-mt65xx.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index a74ef76705e0..2bb4d20ead32 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -503,7 +503,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CON_RX, i2c->pdmabase + OFFSET_CON);
 
-		dma_rd_buf = i2c_get_dma_safe_msg_buf(msgs, 0);
+		dma_rd_buf = i2c_get_dma_safe_msg_buf(msgs, 1);
 		if (!dma_rd_buf)
 			return -ENOMEM;
 
@@ -526,7 +526,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CON_TX, i2c->pdmabase + OFFSET_CON);
 
-		dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 0);
+		dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 1);
 		if (!dma_wr_buf)
 			return -ENOMEM;
 
@@ -549,7 +549,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_CON);
 
-		dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 0);
+		dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 1);
 		if (!dma_wr_buf)
 			return -ENOMEM;
 
@@ -561,7 +561,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 			return -ENOMEM;
 		}
 
-		dma_rd_buf = i2c_get_dma_safe_msg_buf((msgs + 1), 0);
+		dma_rd_buf = i2c_get_dma_safe_msg_buf((msgs + 1), 1);
 		if (!dma_rd_buf) {
 			dma_unmap_single(i2c->dev, wpaddr,
 					 msgs->len, DMA_TO_DEVICE);
-- 
2.18.1

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
> 0 and msg->len is also 0, function makes zero-length allocation, which returns
> a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
> code to fail. Modify the threshold to > 0 so the function returns NULL pointer.
> 
> Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>

Right. But we need to fix i2c_get_dma_safe_msg_buf(), so it will be
handled for all callers. Do you want to add a check if msg->len is 0 or
shall I? Both fine for me.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

Ok, I can add a check in another patch. Should we return NULL pointer
if msg->len is 0 or print out some warnings? Thanks.

On Fri, Feb 15, 2019 at 5:10 PM Wolfram Sang <wsa@the-dreams.de> wrote:
>
> On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> > i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
> > 0 and msg->len is also 0, function makes zero-length allocation, which returns
> > a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
> > code to fail. Modify the threshold to > 0 so the function returns NULL pointer.
> >
> > Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
>
> Right. But we need to fix i2c_get_dma_safe_msg_buf(), so it will be
> handled for all callers. Do you want to add a check if msg->len is 0 or
> shall I? Both fine for me.
>

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

On Fri, Feb 15, 2019 at 05:17:27PM +0800, Hsin-Yi Wang wrote:
> Ok, I can add a check in another patch. Should we return NULL pointer
> if msg->len is 0 or print out some warnings? Thanks.

No warning, msg->len == 0 is a valid setting. But interesting question:
I was about to say NULL, but your driver would assume ENOMEM there and
discard the message which is also not correct since msg->len == 0 is a
valid setting. So, should we just return msg->buf then? Will this work
with your driver? Can it handle zero-length transfers?

> On Fri, Feb 15, 2019 at 5:10 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> >
> > On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> > > i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
> > > 0 and msg->len is also 0, function makes zero-length allocation, which returns
> > > a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
> > > code to fail. Modify the threshold to > 0 so the function returns NULL pointer.
> > >
> > > Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> >
> > Right. But we need to fix i2c_get_dma_safe_msg_buf(), so it will be
> > handled for all callers. Do you want to add a check if msg->len is 0 or
> > shall I? Both fine for me.
> >

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]


>> > Ok, I can add a check in another patch. Should we return NULL pointer
>> > if msg->len is 0 or print out some warnings? Thanks.
>> 
>> No warning, msg->len == 0 is a valid setting. But interesting question:
>> I was about to say NULL, but your driver would assume ENOMEM there and
>> discard the message which is also not correct since msg->len == 0 is a
>> valid setting. So, should we just return msg->buf then? Will this work
>> with your driver? Can it handle zero-length transfers?
> 
> dma_map_single(i2c->dev, msg->buf , msgs->len, DMA_TO_DEVICE); breaks
> kernel if msgs->len is 0, so I think it doesn't handle zero-length transfer.

Please don't drop the lists.

Then, the correct solution is to forbid those transfer with this
controller. Check I2C_AQ_NO_ZERO_LEN. Also, update the functionality
like this .. (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK).


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

Thanks for the solution.
Previously we were testing if the driver can handle zero-length
transfer, but it turns out it will timeout. (Also checked this from
mtk's datasheet)
Adding original owner qii.wang to verify that. We'll apply this after
verification.

On Sat, Feb 16, 2019 at 12:36 AM Wolfram Sang <wsa@the-dreams.de> wrote:
>
>
> >> > Ok, I can add a check in another patch. Should we return NULL pointer
> >> > if msg->len is 0 or print out some warnings? Thanks.
> >>
> >> No warning, msg->len == 0 is a valid setting. But interesting question:
> >> I was about to say NULL, but your driver would assume ENOMEM there and
> >> discard the message which is also not correct since msg->len == 0 is a
> >> valid setting. So, should we just return msg->buf then? Will this work
> >> with your driver? Can it handle zero-length transfers?
> >
> > dma_map_single(i2c->dev, msg->buf , msgs->len, DMA_TO_DEVICE); breaks
> > kernel if msgs->len is 0, so I think it doesn't handle zero-length transfer.
>
> Please don't drop the lists.
>
> Then, the correct solution is to forbid those transfer with this
> controller. Check I2C_AQ_NO_ZERO_LEN. Also, update the functionality
> like this .. (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK).
>

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On Fri, Feb 22, 2019 at 02:04:11PM +0800, Hsin-Yi Wang wrote:
> Thanks for the solution.
> Previously we were testing if the driver can handle zero-length
> transfer, but it turns out it will timeout. (Also checked this from
> mtk's datasheet)
> Adding original owner qii.wang to verify that. We'll apply this after
> verification.

I just checked this issue again and concluded that both are reasonable,
the suggestion from me below with the adapter quirk AND your original
patch setting the threshold to 1. With my suggestion the core will
prevent 0-length messages. But still, we should set the threshold to 1
because 0 is a value the HW is not capable of.

> 
> On Sat, Feb 16, 2019 at 12:36 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> >
> >
> > >> > Ok, I can add a check in another patch. Should we return NULL pointer
> > >> > if msg->len is 0 or print out some warnings? Thanks.
> > >>
> > >> No warning, msg->len == 0 is a valid setting. But interesting question:
> > >> I was about to say NULL, but your driver would assume ENOMEM there and
> > >> discard the message which is also not correct since msg->len == 0 is a
> > >> valid setting. So, should we just return msg->buf then? Will this work
> > >> with your driver? Can it handle zero-length transfers?
> > >
> > > dma_map_single(i2c->dev, msg->buf , msgs->len, DMA_TO_DEVICE); breaks
> > > kernel if msgs->len is 0, so I think it doesn't handle zero-length transfer.
> >
> > Please don't drop the lists.
> >
> > Then, the correct solution is to forbid those transfer with this
> > controller. Check I2C_AQ_NO_ZERO_LEN. Also, update the functionality
> > like this .. (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK).
> >

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

On Fri, Mar 8, 2019 at 7:29 PM Wolfram Sang <wsa@the-dreams.de> wrote:
>
> On Fri, Feb 22, 2019 at 02:04:11PM +0800, Hsin-Yi Wang wrote:
> > Thanks for the solution.
> > Previously we were testing if the driver can handle zero-length
> > transfer, but it turns out it will timeout. (Also checked this from
> > mtk's datasheet)
> > Adding original owner qii.wang to verify that. We'll apply this after
> > verification.
>
> I just checked this issue again and concluded that both are reasonable,
> the suggestion from me below with the adapter quirk AND your original
> patch setting the threshold to 1. With my suggestion the core will
> prevent 0-length messages. But still, we should set the threshold to 1
> because 0 is a value the HW is not capable of.
>
I think quirk might be better, since mediatek said they might have some ICs
that can handle zero-length transfer in the future, so flags might be
more clear if they want to restore functionality.
> >
> > On Sat, Feb 16, 2019 at 12:36 AM Wolfram Sang <wsa@the-dreams.de> wrote:
> > >
> > >
> > > >> > Ok, I can add a check in another patch. Should we return NULL pointer
> > > >> > if msg->len is 0 or print out some warnings? Thanks.
> > > >>
> > > >> No warning, msg->len == 0 is a valid setting. But interesting question:
> > > >> I was about to say NULL, but your driver would assume ENOMEM there and
> > > >> discard the message which is also not correct since msg->len == 0 is a
> > > >> valid setting. So, should we just return msg->buf then? Will this work
> > > >> with your driver? Can it handle zero-length transfers?
> > > >
> > > > dma_map_single(i2c->dev, msg->buf , msgs->len, DMA_TO_DEVICE); breaks
> > > > kernel if msgs->len is 0, so I think it doesn't handle zero-length transfer.
> > >
> > > Please don't drop the lists.
> > >
> > > Then, the correct solution is to forbid those transfer with this
> > > controller. Check I2C_AQ_NO_ZERO_LEN. Also, update the functionality
> > > like this .. (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK).
> > >

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


> > I just checked this issue again and concluded that both are reasonable,
> > the suggestion from me below with the adapter quirk AND your original
> > patch setting the threshold to 1. With my suggestion the core will
> > prevent 0-length messages. But still, we should set the threshold to 1
> > because 0 is a value the HW is not capable of.
> >
> I think quirk might be better, since mediatek said they might have some ICs
> that can handle zero-length transfer in the future, so flags might be
> more clear if they want to restore functionality.

But I guess you don't want to do the zero-length transfer with DMA then?
With that in mind, raising the threshold still makes sense to me.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

On Fri, Mar 8, 2019 at 10:52 PM Wolfram Sang <wsa@the-dreams.de> wrote:
>
>
> > > I just checked this issue again and concluded that both are reasonable,
> > > the suggestion from me below with the adapter quirk AND your original
> > > patch setting the threshold to 1. With my suggestion the core will
> > > prevent 0-length messages. But still, we should set the threshold to 1
> > > because 0 is a value the HW is not capable of.
> > >
> > I think quirk might be better, since mediatek said they might have some ICs
> > that can handle zero-length transfer in the future, so flags might be
> > more clear if they want to restore functionality.
>
> But I guess you don't want to do the zero-length transfer with DMA then?
> With that in mind, raising the threshold still makes sense to me.
>
Yes. Then I think this patch is okay for merge?

And since the mt8183 patches are still under reviewing, we'll upload adapter
quirk patch after those are merged.

Thanks

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
> 0 and msg->len is also 0, function makes zero-length allocation, which returns
> a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
> code to fail. Modify the threshold to > 0 so the function returns NULL pointer.
> 
> Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>

Reworded commit message to "HW doesn't support 0 length" and applied to
for-current, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]