Re: [PATCH 2/5] swiotlb: fix compile warning

Becky Bruce
2009-03-25T13:05:00Z

On Mar 25, 2009, at 7:45 AM, Ingo Molnar wrote:

>
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>
>> On Tue, 24 Mar 2009 22:42:33 -0500
>> Becky Bruce <beckyb@kernel.crashing.org> wrote:
>>
>>>
>>> On Mar 24, 2009, at 9:58 PM, FUJITA Tomonori wrote:
>>>
>>>> On Tue, 24 Mar 2009 16:28:43 -0500
>>>> Becky Bruce <beckyb@kernel.crashing.org> wrote:
>>>>
>>>>> Squash a build warning seen on 32-bit powerpc caused by calling
>>>>> min()
>>>>> with 2 different types. Cast the first arg to size_t, which is
>>>>> the
>>>>> type of the second, and should be portable across architectures.
>>>>>
>>>>> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
>>>>> ---
>>>>> lib/swiotlb.c | 2 +-
>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
>>>>> index f59cf30..62f5f75 100644
>>>>> --- a/lib/swiotlb.c
>>>>> +++ b/lib/swiotlb.c
>>>>> @@ -341,7 +341,7 @@ static void swiotlb_bounce(phys_addr_t phys,
>>>>> char *dma_addr, size_t size,
>>>>> unsigned long flags;
>>>>>
>>>>> while (size) {
>>>>> - sz = min(PAGE_SIZE - offset, size);
>>>>> + sz = min((size_t)(PAGE_SIZE - offset), size);
>>>>>
>>>>> local_irq_save(flags);
>>>>> buffer = kmap_atomic(pfn_to_page(pfn),
>>>>
>>>> ?
>>>>
>>>> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
>>>> index f59cf30..fa62498 100644
>>>> --- a/lib/swiotlb.c
>>>> +++ b/lib/swiotlb.c
>>>> @@ -341,7 +341,7 @@ static void swiotlb_bounce(phys_addr_t phys,
>>>> char *dma_addr, size_t size,
>>>> unsigned long flags;
>>>>
>>>> while (size) {
>>>> - sz = min(PAGE_SIZE - offset, size);
>>>> + sz = min_t(size_t, PAGE_SIZE - offset, size);
>>>>
>>>> local_irq_save(flags);
>>>> buffer = kmap_atomic(pfn_to_page(pfn),
>>>
>>> OK, we're clearly pointed at different trees here, and it looks like
>>> I'm behind - this patch is based on Ingo's master. Which tree has
>>> this change?
>>
>> I also use tip/master. I think that we are on the same page. No
>> tree has this change. I just send it because I'm not sure why you
>> don't use min_t().
>
> yes, min_t() is safer and cleaner than min()+cast.

Ahh, then, that's just an oversight on my part, and I'll fix it. I'll
send out a respun set of patches as soon as I'm out of today's endless
set of meetings.

Thanks,
Becky