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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 22 Feb 2019 14:04:11 +0800
From:   Hsin-Yi Wang <hsinyi@...omium.org>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        Jun Gao <jun.gao@...iatek.com>,
        Ryder Lee <ryder.lee@...iatek.com>, linux-i2c@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        qii.wang@...iatek.com
Subject: Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

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@...-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).
>

Powered by blists - more mailing lists