From: Mohan Kumar D <mkumard@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: vkoul@kernel.org, jonathanh@nvidia.com,
dmaengine@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v3 1/2] dmaengine: tegra210-adma: Fix build error due to 64-by-32 division
Date: Tue, 4 Feb 2025 22:13:09 +0530 [thread overview]
Message-ID: <84382200-e793-4e9a-b25a-8dc43e7a8bd0@nvidia.com> (raw)
In-Reply-To: <dsxaisxdpsxecyna527cifixyurmkgo3cfaiheau5jjdl5qysp@64qquncxdmof>
On 04-02-2025 21:06, Thierry Reding wrote:
> On Thu, Jan 16, 2025 at 09:50:32PM +0530, Mohan Kumar D wrote:
>> Kernel test robot reported the build errors on 32-bit platforms due to
>> plain 64-by-32 division. Following build erros were reported.
>>
>> "ERROR: modpost: "__udivdi3" [drivers/dma/tegra210-adma.ko] undefined!
>> ld: drivers/dma/tegra210-adma.o: in function `tegra_adma_probe':
>> tegra210-adma.c:(.text+0x12cf): undefined reference to `__udivdi3'"
>>
>> This can be fixed by using lower_32_bits() for the adma address space as
>> the offset is constrained to the lower 32 bits
>>
>> Fixes: 68811c928f88 ("dmaengine: tegra210-adma: Support channel page")
>> Cc: stable@vger.kernel.org
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202412250204.GCQhdKe3-lkp@intel.com/
>> Signed-off-by: Mohan Kumar D <mkumard@nvidia.com>
>> ---
>> drivers/dma/tegra210-adma.c | 14 +++++++++++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
>> index 6896da8ac7ef..258220c9cb50 100644
>> --- a/drivers/dma/tegra210-adma.c
>> +++ b/drivers/dma/tegra210-adma.c
>> @@ -887,7 +887,8 @@ static int tegra_adma_probe(struct platform_device *pdev)
>> const struct tegra_adma_chip_data *cdata;
>> struct tegra_adma *tdma;
>> struct resource *res_page, *res_base;
>> - int ret, i, page_no;
>> + unsigned int page_no, page_offset;
>> + int ret, i;
>>
>> cdata = of_device_get_match_data(&pdev->dev);
>> if (!cdata) {
>> @@ -914,9 +915,16 @@ static int tegra_adma_probe(struct platform_device *pdev)
>>
>> res_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "global");
>> if (res_base) {
>> - page_no = (res_page->start - res_base->start) / cdata->ch_base_offset;
>> - if (page_no <= 0)
>> + if (WARN_ON(lower_32_bits(res_page->start) <=
>> + lower_32_bits(res_base->start)))
> Don't we technically also want to check that
>
> res_page->start <= res_base->start
>
> because otherwise people might put in something that's completely out of
> range? I guess maybe you could argue that the DT is then just broken,
> but since we're checking anyway, might as well check for all corner
> cases.
>
> Thierry
ADMA Address range for all Tegra chip falls within 32bit range. Do you
think still we need to have this extra check which seems like redundant
for now.
>
>> + return -EINVAL;
>> +
>> + page_offset = lower_32_bits(res_page->start) -
>> + lower_32_bits(res_base->start);
>> + page_no = page_offset / cdata->ch_base_offset;
>> + if (page_no == 0)
>> return -EINVAL;
>> +
>> tdma->ch_page_no = page_no - 1;
>> tdma->base_addr = devm_ioremap_resource(&pdev->dev, res_base);
>> if (IS_ERR(tdma->base_addr))
>> --
>> 2.25.1
>>
next prev parent reply other threads:[~2025-02-04 16:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 16:20 [PATCH v3 0/2] Tegra ADMA fixes Mohan Kumar D
2025-01-16 16:20 ` [PATCH v3 1/2] dmaengine: tegra210-adma: Fix build error due to 64-by-32 division Mohan Kumar D
2025-01-17 14:52 ` Jon Hunter
2025-02-04 15:36 ` Thierry Reding
2025-02-04 16:43 ` Mohan Kumar D [this message]
2025-02-04 17:03 ` Thierry Reding
2025-02-04 17:18 ` Jon Hunter
2025-02-04 17:58 ` Thierry Reding
2025-02-05 3:31 ` Mohan Kumar D
2025-01-16 16:20 ` [PATCH v3 2/2] dmaengine: tegra210-adma: check for adma max page Mohan Kumar D
2025-01-17 14:54 ` Jon Hunter
2025-02-02 1:14 ` [PATCH v3 0/2] Tegra ADMA fixes Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84382200-e793-4e9a-b25a-8dc43e7a8bd0@nvidia.com \
--to=mkumard@nvidia.com \
--cc=dmaengine@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lkp@intel.com \
--cc=stable@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox