mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mike Frysinger" <vapier.adi@gmail.com>
To: "Jiri Slaby" <jirislaby@gmail.com>
Cc: "Bryan Wu" <cooloney@kernel.org>,
	sam@ravnborg.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] Blackfin OTP Char Driver: add writing support of OTP
Date: Mon, 13 Oct 2008 06:07:34 -0400	[thread overview]
Message-ID: <8bd0f97a0810130307i29e76f6w62f9797b561b4c6f@mail.gmail.com> (raw)
In-Reply-To: <48F31BF9.6030109@gmail.com>

On Mon, Oct 13, 2008 at 05:59, Jiri Slaby wrote:
> On 10/13/2008 11:43 AM, Mike Frysinger wrote:
>> On Mon, Oct 13, 2008 at 05:37, Jiri Slaby wrote:
>>> On 10/13/2008 11:13 AM, Bryan Wu wrote:
>>>> @@ -123,18 +132,95 @@ static ssize_t bfin_otp_write(struct file *filp, const char __user *buff, size_t
>>>>       if (mutex_lock_interruptible(&bfin_otp_lock))
>>>>               return -ERESTARTSYS;
>>>>
>>>> -     /* need otp_init() documentation before this can be implemented */
>>>> +     stampit();
>>>> +
>>>> +     timing = bfin_otp_init_timing();
>>>> +     if (timing == 0) {
>>>> +             mutex_unlock(&bfin_otp_lock);
>>>> +             return -EIO;
>>>> +     }
>>>> +
>>>> +     base_flags = OTP_CHECK_FOR_PREV_WRITE;
>>>> +
>>>> +     bytes_done = 0;
>>>> +     page = *pos / (sizeof(u64) * 2);
>>>> +     while (bytes_done < count) {
>>>> +             flags = base_flags | (*pos % (sizeof(u64) * 2) ? OTP_UPPER_HALF : OTP_LOWER_HALF);
>>>> +             stamp("processing page %i (0x%x:%s) from %p", page, flags,
>>>> +                     (flags & OTP_UPPER_HALF ? "upper" : "lower"), buff + bytes_done);
>>>> +             if (copy_from_user(&content, buff + bytes_done, sizeof(content))) {
>>>> +                     bytes_done = -EFAULT;
>>>> +                     break;
>>>> +             }
>>>> +             ret = bfrom_OtpWrite(page, flags, &content);
>>>> +             if (ret & OTP_MASTER_ERROR) {
>>>> +                     stamp("error from otp: 0x%x", ret);
>>>> +                     bytes_done = -EIO;
>>>> +                     break;
>>>> +             }
>>>> +             if (flags & OTP_UPPER_HALF)
>>>> +                     ++page;
>>>> +             bytes_done += sizeof(content);
>>>> +             *pos += sizeof(content);
>>>
>>> What happens to pos if it fails later?
>>
>> there is no state maintained in the hardware.  the pos gets updated
>> only when a half-page actually gets processed.  so there is no
>> "later".
>
> Sure there is. Next iteration of the loop. I.e. what happens if bfrom_OtpWrite
> fails for the second time?

the pos gets updated every time a half-page gets processed.  so if you
call write() and tell it to write 128 bytes, but you get an error half
way through, the pos points right at the place where the error
occurred.  i dont get what you're asking.

>>> You should change (and check) allow_writes under the mutex anyway.
>>
>> not really.  the mutex is to restrict access to the OTP hardware, not
>> driver state.  because there is none.  access to allow_writes is
>> atomic in the hardware anyways.
>
> Yeah, the assignment/check is.
>
> But is this OK to you:
> PROCESS 1                       PROCESS 2
> lock
>  set allow_writes
> write
>   check allow_writes
>   be interrupted
>                                whatever
>                                unlock
>                                    unset allow_writes
>                                sleep
>   mutex lock
>   the processing...

i dont see a problem here.  there is no loss of data, hardware
failure, software crashes, etc...  in other words, there is no
misbehavior.
-mike

  reply	other threads:[~2008-10-13 10:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-13  9:13 Bryan Wu
2008-10-13  9:37 ` Jiri Slaby
2008-10-13  9:43   ` Mike Frysinger
2008-10-13  9:59     ` Jiri Slaby
2008-10-13 10:07       ` Mike Frysinger [this message]
2008-10-13 10:35         ` Jiri Slaby
2008-10-13 10:44           ` Mike Frysinger
2009-09-23 17:38 ` [PATCH v2] bfin-otp: add writing support Mike Frysinger

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=8bd0f97a0810130307i29e76f6w62f9797b561b4c6f@mail.gmail.com \
    --to=vapier.adi@gmail.com \
    --cc=cooloney@kernel.org \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /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

all inboxes | Powered by JetHome®