From: Marek Vasut <marex@denx.de>
To: Sourav Poddar <sourav.poddar@ti.com>
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 16:27:33 +0100 [thread overview]
Message-ID: <201310291627.34003.marex@denx.de> (raw)
In-Reply-To: <526FC153.1020004@ti.com>
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.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2013-10-29 15:27 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 [this message]
2013-10-29 16:52 ` Sourav Poddar
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=201310291627.34003.marex@denx.de \
--to=marex@denx.de \
--cc=balbi@ti.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sourav.poddar@ti.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;
as well as URLs for NNTP newsgroup(s).