linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sourav Poddar <sourav.poddar@ti.com>
To: Marek Vasut <marex@denx.de>
Cc: computersforpeace@gmail.com, linux-mtd@lists.infradead.org,
	balbi@ti.com, dedekind1@gmail.com
Subject: Re: [PATCH] drivers: mtd: m25p80: Add quad read support.
Date: Tue, 29 Oct 2013 22:22:09 +0530	[thread overview]
Message-ID: <526FE7B9.3000602@ti.com> (raw)
In-Reply-To: <201310291627.34003.marex@denx.de>

On Tuesday 29 October 2013 08:57 PM, Marek Vasut wrote:
> Dear Sourav Poddar,
>
>> Dear Marek Vasut,
>>
>> On Tuesday 29 October 2013 07:31 PM, Marek Vasut wrote:
>>> Dear Sourav Poddar,
>>>
>>>> Hi,
>>>>
>>>> On Sunday 27 October 2013 10:15 PM, Marek Vasut wrote:
>>>>> Dear Sourav Poddar,
>>>>>
>>>>> [...]
>>>>>
>>>>>> +static int macronix_quad_enable(struct m25p *flash)
>>>>>> +{
>>>>>> +	int ret, val;
>>>>>> +	u8 cmd[2];
>>>>>> +	cmd[0] = OPCODE_WRSR;
>>>>>> +
>>>>>> +	val = read_sr(flash);
>>>>>> +	cmd[1] = val | SR_QUAD_EN_MX;
>>>>>> +	write_enable(flash);
>>>>>> +
>>>>>> +	spi_write(flash->spi,&cmd, 2);
>>>>>> +
>>>>>> +	if (wait_till_ready(flash))
>>>>>> +		return 1;
>>>>>> +
>>>>>> +	ret = read_sr(flash);
>>>>> Maybe read_sr() and read_cr() shall be fixed to return retval only and
>>>>> the val shall be passed to them as an argument pointer? Aka. ret =
>>>>> read_sr(flash,&val);
>>>>>
>>>>> That way, this dangerous construct below could become:
>>>>>
>>>>> if (!(val&    SR_....)) {
>>>>>
>>>>> 	dev_err();
>>>>> 	ret = -EINVAL;
>>>>>
>>>>> }
>>>>>
>>>>> return ret;
>>>> I was trying to work on it and realise, we dont need to pass val
>>>> directly. We can continue returning the val and can still cleanup the
>>>> below code as u suggetsed above.
>>>> if (!(ret&   SR_....)) {
>>>>
>>>>        dev_err();
>>>>        ret = -EINVAL;
>>>>
>>>> }
>>> Uh oh, no. This doesn't seem right. I'd like to be able to clearly check
>>> if the function failed to read the register altogether OR if not, check
>>> the returned value of the register. Mixing these two together won't do
>>> us good. But maybe I just fail to understand your proposal, if so, then
>>> I appologize.
>> Yes, what I am trying to propose is to eliminate the return error check.
> But we want to be able to check if there is a failure :)
>
>> The check whether register read has happened correctly is embedded in
>> read_sr/read_cr function itself.
>>           if (retval<  0) {
>>                   dev_err(&flash->spi->dev, "error %d reading SR\n",
>>                                   (int) retval);
>>                   return retval;
>>           }
>> Same goes for read_cr.
>> So, if the above condition is not hit, we simply return the read value and
>> check it with the respective bits.
> Look here:
>
>   107 static int read_sr(struct m25p *flash)
>   108 {
>   109         ssize_t retval;
>   110         u8 code = OPCODE_RDSR;
>   111         u8 val;
>   112
>   113         retval = spi_write_then_read(flash->spi,&code, 1,&val, 1);
>   114
>   115         if (retval<  0) {
>   116                 dev_err(&flash->spi->dev, "error %d reading SR\n",
>   117                                 (int) retval);
>   118                 return retval;
>
> here you return error value IFF spi_write_then_read() fails for some reason.
>
>   119         }
>   120
>   121         return val;
>
> here you return actual value of the register.
>
>   122 }
>
> This is how I'd change the function to make it less error-prone:
>
> *107 static int read_sr(struct m25p *flash, u8 *rval)
>   108 {
>   109         ssize_t retval;
>   110         u8 code = OPCODE_RDSR;
>   111         u8 val;
>   112
>   113         retval = spi_write_then_read(flash->spi,&code, 1,&val, 1);
>   114
>   115         if (retval<  0) {
>   116                 dev_err(&flash->spi->dev, "error %d reading SR\n",
>   117                                 (int) retval);
>   118                 return retval;
>   119         }
> *120         *rval = val;
> *121         return 0;
>   122 }
>
> This way, you can check if the SPI read failed and if so, handle it in some way.
> The return value would only be valid if this function returned 0.
>
I got this, but do you think its necessary to have two checks for verifying
whether read passed. ?
If I go by your code above, after returning from above,
check for return value for successful read
and then check the respective bit set(SR_*). ?

> Best regards,
> Marek Vasut

  reply	other threads:[~2013-10-29 16:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25  9:25 [PATCH] drivers: mtd: m25p80: Add quad read support Sourav Poddar
2013-10-25 10:18 ` Huang Shijie
2013-10-25 10:19   ` Sourav Poddar
2013-10-27 16:45 ` Marek Vasut
2013-10-27 18:26   ` Sourav Poddar
2013-10-27 18:30     ` Marek Vasut
2013-10-27 18:37       ` Sourav Poddar
2013-10-27 18:47         ` Marek Vasut
2013-10-29  5:57   ` Sourav Poddar
2013-10-29 14:01     ` Marek Vasut
2013-10-29 14:08       ` Sourav Poddar
2013-10-29 15:27         ` Marek Vasut
2013-10-29 16:52           ` Sourav Poddar [this message]
2013-10-29 17:08             ` Marek Vasut
2013-10-29 17:12               ` Sourav Poddar
2013-10-29 18:24                 ` Marek Vasut
2013-10-29 18:34                 ` Sourav Poddar
2013-10-30  6:27                   ` Huang Shijie
2013-10-30  6:46                     ` Sourav Poddar
2013-10-30  6:54                       ` Huang Shijie
2013-10-30 10:11                   ` Marek Vasut
2013-11-12 18:13                     ` Brian Norris
  -- strict thread matches above, loose matches on Subject: below --
2013-09-24 12:10 Sourav Poddar
2013-09-25  3:06 ` Huang Shijie
2013-09-25  5:20   ` Sourav Poddar
2013-09-25  5:48 ` Huang Shijie
2013-09-25  5:51   ` Sourav Poddar
2013-09-25  5:54     ` Sourav Poddar
2013-09-25  5:56     ` Huang Shijie
2013-09-25  6:16 ` Huang Shijie
2013-09-25  6:24   ` Sourav Poddar

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=526FE7B9.3000602@ti.com \
    --to=sourav.poddar@ti.com \
    --cc=balbi@ti.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    /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;
as well as URLs for NNTP newsgroup(s).