public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: nick <xerofoify@gmail.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	ulf.hansson@linaro.org, ben.dooks@codethink.co.uk,
	ykaneko0929@gmail.com, laurent.pinchart+renesas@ideasonboard.com,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2] mmc:Add pointer cast to uintptr_t for slave_id_rx and tx in the function, sh_mmcif_request_dma_one
Date: Tue, 23 Jun 2015 17:54:33 -0700	[thread overview]
Message-ID: <1435107273.2504.43.camel@perches.com> (raw)
In-Reply-To: <5589FD65.7040807@gmail.com>

On Tue, 2015-06-23 at 20:44 -0400, nick wrote:
> 
> On 2015-06-23 08:40 PM, Joe Perches wrote:
> > On Wed, 2015-06-24 at 00:24 +0000, Kuninori Morimoto wrote:
> >> Hi Joe, Nick
> >>
> >>>>>> This adds a cast to the variables,slave_id_rx and slave_id_rx
> >>>>>> to uintptr_t before casting to void* in order to avoid build
> >>>>>> warning on 64bit platforms for the function, sh_mmcif_request_dma_one.
> >>>> []
> >>>>>> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> >>>> []
> >>>>>> @@ -398,8 +398,8 @@ sh_mmcif_request_dma_one(struct sh_mmcif_host *host,
> >>>>>>  
> >>>>>>  	if (pdata)
> >>>>>>  		slave_data = direction == DMA_MEM_TO_DEV ?
> >>>>>> -			(void *)pdata->slave_id_tx :
> >>>>>> -			(void *)pdata->slave_id_rx;
> >>>>>> +			(void *)(uintptr_t)pdata->slave_id_tx :
> >>>>>> +			(void *)(uintptr_t)pdata->slave_id_rx;
> >>>>
> >>>> It's far more common (~10:1) in the kernel to cast using
> >>>> 	(<type> *)(unsigned long)<foo>
> >>>> than
> >>>> 	(<type> *)(uintptr_t)<foo>
> >>>>
> >>> Joe,
> >>> I agree it's more common in the kernel but one of the maintainers when I sent
> >>> this patch a month ago requested I use uintpr_t instead of unsigned long for
> >>> the casting. Otherwise I would have done the cast to fix the build warning
> >>> with unsigned long instead.
> >>
> >> This mail
> >> http://thread.gmane.org/gmane.linux.kernel.mmc/32304
> > 
> > uintptr_t was introduced to avoid ptrdiff_t misuse in
> > commit 142956af5250 ("fix abuses of ptrdiff_t") by Al Viro.
> > 
> > unsigned long is preponderant, long is used about 1/4 as
> > often as unsigned long, uintptr_t is relatively uncommon.
> > 
> > If someone wants to go and convert the 800 or so casts to
> > long or unsigned long to uintptr_t so that's the style most
> > frequently used, that'd be different.  I'm not going to
> > submit any patches for that.
> > 
> > 
> I am not disagreeing it was just easier to listen to the maintainer rather
> then get in a technical argument over which type is better for the cast.

Ulf Hansson is the maintainer.

Laurent has authored a couple patches to that file and he gave
you his opinion about using uintptr_t.

I'm giving an opinion too, just with a little statistics.

I think it's better to use the style that the kernel generally
uses.

I'll stop replying now.



  parent reply	other threads:[~2015-06-24  0:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1431366550-22045-1-git-send-email-xerofoify@gmail.com>
2015-05-12  0:18 ` [PATCHv2] mmc:Add pointer cast to uintptr_t for slave_id_rx and tx in the function, sh_mmcif_request_dma_one Kuninori Morimoto
2015-06-23 23:54 ` Kuninori Morimoto
2015-06-24  0:07   ` Joe Perches
     [not found]     ` <5589F6D8.5090107@gmail.com>
2015-06-24  0:24       ` Kuninori Morimoto
2015-06-24  0:40         ` Joe Perches
     [not found]           ` <5589FD65.7040807@gmail.com>
2015-06-24  0:54             ` Joe Perches [this message]
2015-06-24  7:16               ` Arnd Bergmann
     [not found]                 ` <55953D85.3000507@gmail.com>
2015-07-20 14:21                   ` Ulf Hansson
     [not found]                     ` <55AD07E6.1060209@gmail.com>
2015-07-21  7:41                       ` Ulf Hansson

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=1435107273.2504.43.camel@perches.com \
    --to=joe@perches.com \
    --cc=ben.dooks@codethink.co.uk \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=xerofoify@gmail.com \
    --cc=ykaneko0929@gmail.com \
    /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