public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jack Stone <jwjstone@fastmail.fm>
To: Margarita Olaya <magi@slimlogic.co.uk>
Cc: linux-kernel@vger.kernel.org, Liam Girdwood <lrg@slimlogic.co.uk>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	sameo@linux.intel.com
Subject: Re: [PATCHv2 1/4] mfd: tps65912: Add new mfd device
Date: Sat, 14 May 2011 10:53:47 +0100	[thread overview]
Message-ID: <4DCE512B.50701@fastmail.fm> (raw)
In-Reply-To: <BANLkTi=X23M+8_qDc5N25dVSfnuwWAPXUQ@mail.gmail.com>

On 13/05/2011 21:53, Margarita Olaya wrote:
>>> +static int tps65912_spi_read(struct tps65912 *tps65912, u8 addr,
>>> +                                                     int bytes, void *dest)
>>> +{
>>> +     struct spi_device *spi = tps65912->spi_device;
>>> +
>>> +     unsigned long spi_data = 0 << 23 | addr << 15;
>>
>> Is the 0 << 23 meant to be 1 << 23? Like the write function.
>>
> No, It should be zero, I will remove.

Is it a read vs write bit?

You don't have to remove it but a comment explaining that bit 23 is the
read bit would help.

> 
>>> +     struct spi_transfer xfer;
>>> +     struct spi_message msg;
>>> +     int ret;
>>> +     u8 *data = (u8 *) dest;
>> Shouldn't need to cast a void *
>>
>>> +     u32 tx_buf = 0, rx_buf = 0;
>> These are initialized below.
>>
>>> +     tx_buf = spi_data;
>>> +     rx_buf = 0;
>>> +
>>> +     xfer.tx_buf     = &tx_buf;
>>> +     xfer.rx_buf     = &rx_buf;
>>> +     xfer.len        = sizeof(unsigned long);
>>> +     xfer.bits_per_word = 24;
>>> +
>>> +     spi_message_init(&msg);
>>> +     spi_message_add_tail(&xfer, &msg);
>>> +
>>> +     if (spi == NULL)
>>> +             return 0;
>>> +
>>> +     ret = spi_sync(spi, &msg);
>>> +     if (ret == 0)
>>> +             *data = (u8) (rx_buf & 0xFF);
>>> +     return ret;
>>> +}
>>> +
>> The spi read/write functions both ignore the bytes argument and only
>> transfer one byte, whereas the i2c versions appear to read/write
>> multiple bytes. Which one is correct?
>>
> Both are correct, I'm passing bytes argument to spi read/write to make
> it compatible with the declaration of tps65912_read/write functions
> pointer.
> 

But if anyone ever calls the tps65912_read/write functions with bytes !=
1 then this will fail, but only on the SPI case.

If they are only ever called with bytes == 1 then you can simply remove
the bytes argument.

Thanks,

Jack

      reply	other threads:[~2011-05-14  9:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-12 18:42 [PATCHv2 1/4] mfd: tps65912: Add new mfd device Margarita Olaya
2011-05-12 19:46 ` Jack Stone
2011-05-13 20:53   ` Margarita Olaya
2011-05-14  9:53     ` Jack Stone [this message]

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=4DCE512B.50701@fastmail.fm \
    --to=jwjstone@fastmail.fm \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=magi@slimlogic.co.uk \
    --cc=sameo@linux.intel.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