linux-kernel - Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg

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]

Message-ID: <20190308112919.GA1674@kunai>
Date:   Fri, 8 Mar 2019 12:29:19 +0100
From:   Wolfram Sang <wsa@...-dreams.de>
To:     Hsin-Yi Wang <hsinyi@...omium.org>
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()

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)