linux-kernel - RE: [PATCH V18 4/6] i2c: tegra: Add DMA support

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:   Mon, 11 Feb 2019 16:26:04 +0000
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Wolfram Sang <wsa@...-dreams.de>,
        Dmitry Osipenko <digetx@...il.com>
CC:     "thierry.reding@...il.com" <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Mantravadi Karthik <mkarthik@...dia.com>,
        "Shardar Mohammed" <smohammed@...dia.com>,
        Timo Alho <talho@...dia.com>,
        "peda@...ntia.se" <peda@...ntia.se>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: RE: [PATCH V18 4/6] i2c: tegra: Add DMA support

> > > I am not sure if you are aware of this document, so I mention it:
> > > 
> > > Documentation/i2c/DMA-considerations
> > > 
> > > I am not pushing you to use the i2c_get_dma_safe_msg_buf() helpers, 
> > > just wanted to make sure you know about them. I am also fine with an 
> > > incremental patch on top of this if you want to add usage of those 
> > > helpers somewhen later.
> > 
> > At least I was not aware of those helpers. It looks to me that the 
> > approach of having a statically allocated buffer is more optimal than 
> > having to allocate and map the buffer on each transfer.
>
> Can be argued, yes.
>
> > >>  /* Match table for of_platform binding */  static const struct 
> > >> of_device_id tegra_i2c_of_match[] = {
> > >>  	{ .compatible = "nvidia,tegra194-i2c", .data = &tegra194_i2c_hw, 
> > >> },
> > >> +	{ .compatible = "nvidia,tegra186-i2c", .data = &tegra186_i2c_hw, 
> > >> +},
> > >>  	{ .compatible = "nvidia,tegra210-i2c", .data = &tegra210_i2c_hw, },
> > >>  	{ .compatible = "nvidia,tegra124-i2c", .data = &tegra124_i2c_hw, },
> > >>  	{ .compatible = "nvidia,tegra114-i2c", .data = &tegra114_i2c_hw, 
> > >> },
> > > 
> > > Shouldn't this be a seperate patch?
> > 
> > I asked for this change and no, it shouldn't be a separate patch as it 
> > adds "has_apb_dma = false" property for T186 that older Tegra's have 
> > as "true". Without this change T186 uses tegra_i2c_hw_feature of T210, 
> > see [0]. Hence this change is absolutely correct and appropriate for 
> > this patch.
>
> Then please update the patch description to contain this information.
>
Will update commit message about the reason for adding has_apb_dma
>
>
> > > This should definately be a seperate patch. While I am all for 
> > > taking it, are you sure it does not regress on older Tegra platforms?
> > > 
> > 
> > All the patches are tested on older Tegra's (T20/T30 specifically by
> > me) and we fixed several bugs that were regressing them over the few 
> > versions of the patchset. I specifically asked for this change for 
> > older Tegra's because the APBDMA driver (T20-T210) is getting 
> > registered from the module-init level and hence I2C driver probe is 
> > always getting deferred. I'm not sure that it's worth to factor out 
> > this hunk into a separate patch as it's directly related to the DMA 
> > support addition, maybe worth to mention why this is needed in the 
> > commit message.
>
> At least, this, yes.
>
Will update commit message to reflect this...
>
>