linux-kernel - Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported

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: <bf3672db-0013-4696-940d-87bd68e7518c@nvidia.com>
Date: Tue, 28 Oct 2025 10:41:54 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Akhil R <akhilrajeev@...dia.com>
Cc: andi.shyti@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
 digetx@...il.com, kkartik@...dia.com, krzk+dt@...nel.org,
 ldewangan@...dia.com, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org, robh@...nel.org,
 thierry.reding@...il.com
Subject: Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported


On 28/10/2025 10:00, Akhil R wrote:
> On Fri, 24 Oct 2025 16:20:09 +0100, Jon Hunter wrote:
>> On 01/10/2025 07:47, Kartik Rajput wrote:
>>>> On Tegra264, not all I2C controllers have the necessary interface to
>>> GPC DMA, this causes failures when function tegra_i2c_init_dma()
>>> is called.
>>>
>>> Ensure that "dmas" device-tree property is present before initializing
>>> DMA in function tegra_i2c_init_dma().
>>>
>>> Signed-off-by: Kartik Rajput <kkartik@...dia.com>
>>> ---
>>> v4 -> v9: Moved the condition down to have all dma checks together.
>>> v2 -> v4:
>>>           * Add debug print if DMA is not supported by the I2C controller.
>>> v1 -> v2:
>>>           * Update commit message to clarify that some I2C controllers may
>>>             not have the necessary interface to GPC DMA.
>>> ---
>>>    drivers/i2c/busses/i2c-tegra.c | 5 +++++
>>>    1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>> index e533460bccc3..aa7c0d8c0941 100644
>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>>>         if (IS_VI(i2c_dev))
>>>                 return 0;
>>>   
>>> +     if (!of_property_present(i2c_dev->dev->of_node, "dmas")) {
>>> +             dev_dbg(i2c_dev->dev, "DMA not available, falling back to PIO\n");
>>> +             return 0;
>>> +     }
>>> +
>>>         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");
>>
>> What about ACPI based devices?
> 
> The of_ function returns false if using ACPI. Since these DMA drivers does
> not support ACPI enumeration currently, we would not require to proceed
> further anyway. But if required we can add an additional check with
> acpi_dma_supported() or similar. Do you suggest adding a check for ACPI?

I was just wondering if it is better to use fwnode_property_present() 
instead.

Jon

-- 
nvpublic