linux-kernel - Re: [PATCH] i2c: tegra: Fix i2c-tegra DMA config option processing

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] [day] [month] [year] [list]

Message-ID: <2702e51d-1e7e-a71b-f07b-ab224b9eff31@connecttech.com>
Date:   Mon, 14 Aug 2023 15:54:56 +0000
From:   Parker Newman <pnewman@...necttech.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Andi Shyti <andi.shyti@...nel.org>
CC:     Laxman Dewangan <ldewangan@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c: tegra: Fix i2c-tegra DMA config option processing

On 2023-08-14 11:25, Dmitry Osipenko wrote:
> 05.08.2023 00:49, Andi Shyti пишет:
>> Hi Laxman and/or Dmitry,
>>
>> On Thu, Aug 03, 2023 at 05:10:02PM +0000, Parker Newman wrote:
>>>
>>> This patch fixes the Tegra DMA config option processing in the
>>> i2c-tegra driver.
>>>
>>> Tegra processors prior to Tegra186 used APB DMA for I2C requiring
>>> CONFIG_TEGRA20_APB_DMA=y while Tegra186 and later use GPC DMA requiring
>>> CONFIG_TEGRA186_GPC_DMA=y.
>>>
>>> The check for if the processor uses APB DMA is inverted and so the wrong
>>> DMA config options are checked.
>>>
>>> This means if CONFIG_TEGRA20_APB_DMA=y but CONFIG_TEGRA186_GPC_DMA=n
>>> with a Tegra186 or later processor the driver will incorrectly think DMA is
>>> enabled and attempt to request DMA channels that will never be availible,
>>> leaving the driver in a perpetual EPROBE_DEFER state.
>>>
>>> Signed-off-by: Parker Newman <pnewman@...necttech.com>
>>> ---
>>>  drivers/i2c/busses/i2c-tegra.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>> index bcbbf23aa530..dc6ed3a8d69e 100644
>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>> @@ -442,7 +442,7 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>>>     if (IS_VI(i2c_dev))
>>>         return 0;
>>>
>>> -   if (!i2c_dev->hw->has_apb_dma) {
>>> +   if (i2c_dev->hw->has_apb_dma) {
>>>         if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
>>>             dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
>>>             return 0;
>>
>> Can I have your opinion here, please?
> 
> The patch looks good, thanks Parker for fixing it. I'll be able to test
> it only sometime later and let you all know if there will be any
> problem. Previously I haven't noticed any Tegra I2C regressions, maybe
> we should change that dev_dbg to dev_warn.
> 

Hi Dmitry,

You will not notice any issues if both options are set (or not set) as it 
will fall through and configure the DMA or skip DMA setup as expected. 

I only noticed the issue after I enabled CONFIG_TEGRA20_APB_DMA which is a 
KConfig requirement for the Tegra HS-UART driver and my I2C stopped working. 

Which now as I write this I realize is possibly another "bug"... As far as I know
the HS UARTs also use GPC DMA on T186 or later? I would need to look into that.

I don't think the print needs to be a warning, not having DMA enabled
is a valid option, it just needed the correct CONFIG options to be checked for 
the DMA type (APB versus GPC).

-Parker