All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Roger Tseng <rogerable@realtek.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	Alex Dubov <oakad@yahoo.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"driverdev-devel@linuxdriverproject.org"
	<driverdev-devel@linuxdriverproject.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Wei_wang <wei_wang@realsil.com.cn>, Chris Ball <cjb@laptop.org>,
	Lee Jones <lee.jones@linaro.org>,
	Maxim Levitsky <maximlevitsky@gmail.com>
Subject: Re: [PATCH 1/3] mfd: Add realtek USB card reader driver
Date: Wed, 8 Jan 2014 16:03:06 +0300	[thread overview]
Message-ID: <20140108130305.GQ30234@mwanda> (raw)
In-Reply-To: <1121E117AD4ECE49880A389A396215BB939A5BD715@rtitmbs7.realtek.com.tw>

On Wed, Jan 08, 2014 at 03:56:05PM +0800, Roger Tseng wrote:
> Hi Dan,
> 
> >> +int rtsx_usb_ep0_write_register(struct rtsx_ucr *ucr, u16 addr,
> >> +             u8 mask, u8 data)
> >> +{
> >> +     u16 value = 0, index = 0;
> >> +
> >> +     value |= (u16)(3 & 0x03) << 14;
> >> +     value |= (u16)(addr & 0x3FFF);
> >
> >Don't do pointless things:
> >
> >        value |= 0x03 << 14;
> >        value |= addr & 0x3FFF;
> >
> >> +     value = ((value << 8) & 0xFF00) | ((value >> 8) & 0x00FF);
> >
> >This is an endian conversion?  It is buggy.  Use the kernel endian
> >conversion functions cpu_to_le16().
> 
> This is not a conversion for endianess with respect to CPU but for
> command format  of the device. It should always be performed
> regardless of platform.
> 
> In other words, it could be equivalent to:
>         value |= 0x03 << 6; // lower byte
>         value |= (addr & 0x3F00) >> 8; // lower byte
>         value |= (addr & 0xFF) << 8; //higher byte
> 
> We think the previous form is easier to read. Should we keep it or
> change to the later one?

To me it's really weird that the standard would specify that the address
is in byte swapped reversed CPU-endian order.  But if that's what it
says then I don't care about formatting details.  The original code is
fine.

regards,
dan carpenter

WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Roger Tseng <rogerable@realtek.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>, Chris Ball <cjb@laptop.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Alex Dubov <oakad@yahoo.com>,
	"driverdev-devel@linuxdriverproject.org" 
	<driverdev-devel@linuxdriverproject.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Wei_wang <wei_wang@realsil.com.cn>
Subject: Re: [PATCH 1/3] mfd: Add realtek USB card reader driver
Date: Wed, 8 Jan 2014 16:03:06 +0300	[thread overview]
Message-ID: <20140108130305.GQ30234@mwanda> (raw)
In-Reply-To: <1121E117AD4ECE49880A389A396215BB939A5BD715@rtitmbs7.realtek.com.tw>

On Wed, Jan 08, 2014 at 03:56:05PM +0800, Roger Tseng wrote:
> Hi Dan,
> 
> >> +int rtsx_usb_ep0_write_register(struct rtsx_ucr *ucr, u16 addr,
> >> +             u8 mask, u8 data)
> >> +{
> >> +     u16 value = 0, index = 0;
> >> +
> >> +     value |= (u16)(3 & 0x03) << 14;
> >> +     value |= (u16)(addr & 0x3FFF);
> >
> >Don't do pointless things:
> >
> >        value |= 0x03 << 14;
> >        value |= addr & 0x3FFF;
> >
> >> +     value = ((value << 8) & 0xFF00) | ((value >> 8) & 0x00FF);
> >
> >This is an endian conversion?  It is buggy.  Use the kernel endian
> >conversion functions cpu_to_le16().
> 
> This is not a conversion for endianess with respect to CPU but for
> command format  of the device. It should always be performed
> regardless of platform.
> 
> In other words, it could be equivalent to:
>         value |= 0x03 << 6; // lower byte
>         value |= (addr & 0x3F00) >> 8; // lower byte
>         value |= (addr & 0xFF) << 8; //higher byte
> 
> We think the previous form is easier to read. Should we keep it or
> change to the later one?

To me it's really weird that the standard would specify that the address
is in byte swapped reversed CPU-endian order.  But if that's what it
says then I don't care about formatting details.  The original code is
fine.

regards,
dan carpenter

  reply	other threads:[~2014-01-08 13:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-23  9:52 [PATCH 0/3] Add modules for realtek USB card reader rogerable
2013-12-23  9:52 ` rogerable
2013-12-23  9:52 ` [PATCH 1/3] mfd: Add realtek USB card reader driver rogerable
2013-12-23  9:52   ` rogerable
2014-01-02  9:47   ` Dan Carpenter
2014-01-02  9:47     ` Dan Carpenter
2014-01-08  7:56     ` Roger Tseng
2014-01-08  7:56       ` Roger Tseng
2014-01-08 13:03       ` Dan Carpenter [this message]
2014-01-08 13:03         ` Dan Carpenter
2014-01-10 12:42   ` Oliver Neukum
2013-12-23  9:52 ` [PATCH 2/3] mmc: Add realtek USB sdmmc host driver rogerable
2013-12-23  9:52   ` rogerable
2014-01-10 12:49   ` Oliver Neukum
2013-12-23  9:52 ` [PATCH 3/3] memstick: Add realtek USB memstick " rogerable
2013-12-23  9:52   ` rogerable
  -- strict thread matches above, loose matches on Subject: below --
2014-01-14  7:47 [PATCH v2 0/3] Add modules for realtek USB card reader rogerable
2014-01-14  7:47 ` [PATCH 1/3] mfd: Add realtek USB card reader driver rogerable
2014-01-14  7:47   ` rogerable
2014-01-14 13:04   ` Lee Jones
2014-01-14 13:46     ` Dan Carpenter
2014-01-14 13:46       ` Dan Carpenter
2014-01-14 13:55       ` Dan Carpenter
2014-01-14 14:15       ` Lee Jones
2014-01-14 14:15         ` Lee Jones
2014-01-16  8:54     ` Roger
2014-01-16  8:54       ` Roger
2014-01-16  9:35       ` Lee Jones
2014-01-16  9:35         ` Lee Jones
2014-01-20  8:55         ` Roger
2014-01-20  8:55           ` Roger
2014-01-20 21:18           ` Greg Kroah-Hartman
2014-01-14 15:20   ` Greg Kroah-Hartman

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=20140108130305.GQ30234@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=cjb@laptop.org \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=oakad@yahoo.com \
    --cc=rogerable@realtek.com \
    --cc=sameo@linux.intel.com \
    --cc=wei_wang@realsil.com.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.