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
next prev parent 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).