public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* LOCK and UNLOCK functions
@ 2001-01-11 19:41 Alice Hennessy
  2001-01-11 20:03 ` David Woodhouse
  0 siblings, 1 reply; 5+ messages in thread
From: Alice Hennessy @ 2001-01-11 19:41 UTC (permalink / raw)
  To: mtd; +Cc: ahennessy

Hi,

I need to implement the lock and unlock functions in cfi_cmdset_0001.c.
for STRATA chips.
Most of the hooks are already there in mtdchar.c and mtdpart.c for these
2 functions.
I do need to fix the if statements in mtdpart.c that doesn't set the
slave->mtd.lock
and slave->mtd.unlock correctly.
But other than that, I have a few questions:

1. It doesn't appear to me that suspend affects the locking and
unlocking flowcharts -
only program and erase.   Is this a correct assumption?

2. The mtdchar.c ioctl call for MEMUNLOCK  passes the start and len
addresses.  The
unlock for the STRATA clears all the lock bits.  So I intend to include
logic to reinstate the
locked bits that are outside the desired range.   Sound reasonable?

Alice



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: LOCK and UNLOCK functions
  2001-01-11 19:41 LOCK and UNLOCK functions Alice Hennessy
@ 2001-01-11 20:03 ` David Woodhouse
  2001-01-11 20:38   ` Alice Hennessy
  0 siblings, 1 reply; 5+ messages in thread
From: David Woodhouse @ 2001-01-11 20:03 UTC (permalink / raw)
  To: Alice Hennessy; +Cc: mtd

On Thu, 11 Jan 2001, Alice Hennessy wrote:

> 1. It doesn't appear to me that suspend affects the locking and
> unlocking flowcharts - only program and erase.  Is this a correct
> assumption?

What do you mean? Suspend affects everything, because we're about to turn
off the chip (the oldstate stuff is a thinko). If we're in the middle of
telling the chip to lock/unlock then suspend has return failure till we're
finished.

> 2. The mtdchar.c ioctl call for MEMUNLOCK passes the start and len
> addresses.  The unlock for the STRATA clears all the lock bits.  So I
> intend to include logic to reinstate the locked bits that are outside
> the desired range.  Sound reasonable?

Hmmm. Better to design the API better so it can describe the capabilities
of the chip. You don't have to stick to what I threw together - I'm full
of crap half the time. Hadn't you realised that yet?

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: LOCK and UNLOCK functions
  2001-01-11 20:03 ` David Woodhouse
@ 2001-01-11 20:38   ` Alice Hennessy
  2001-01-11 20:51     ` Alice Hennessy
  2001-01-11 22:43     ` David Woodhouse
  0 siblings, 2 replies; 5+ messages in thread
From: Alice Hennessy @ 2001-01-11 20:38 UTC (permalink / raw)
  To: David Woodhouse; +Cc: mtd, ahennessy

David Woodhouse wrote:

> On Thu, 11 Jan 2001, Alice Hennessy wrote:
>
> > 1. It doesn't appear to me that suspend affects the locking and
> > unlocking flowcharts - only program and erase.  Is this a correct
> > assumption?
>
> What do you mean? Suspend affects everything, because we're about to turn
> off the chip (the oldstate stuff is a thinko). If we're in the middle of
> telling the chip to lock/unlock then suspend has return failure till we're
> finished.

I was referring to the "Block Erase, Program Suspend" command in the STRATA
spec
and was wondering  if I need to add checking for  FL_LOCKING  in
do_read_onechip() as we do for
FL_ERASING.   Should have been more specific :)
BTW: what does "thinko" mean?

>
>
> > 2. The mtdchar.c ioctl call for MEMUNLOCK passes the start and len
> > addresses.  The unlock for the STRATA clears all the lock bits.  So I
> > intend to include logic to reinstate the locked bits that are outside
> > the desired range.  Sound reasonable?
>
> Hmmm. Better to design the API better so it can describe the capabilities
> of the chip. You don't have to stick to what I threw together - I'm full
> of crap half the time. Hadn't you realised that yet?

Then my choice would be to keep it simple and let userland keep track of
what lock bits it has set in the past.

Alice

>
>
> --
> dwmw2



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: LOCK and UNLOCK functions
  2001-01-11 20:38   ` Alice Hennessy
@ 2001-01-11 20:51     ` Alice Hennessy
  2001-01-11 22:43     ` David Woodhouse
  1 sibling, 0 replies; 5+ messages in thread
From: Alice Hennessy @ 2001-01-11 20:51 UTC (permalink / raw)
  To: David Woodhouse, mtd, ahennessy

Alice Hennessy wrote:

> David Woodhouse wrote:
>
> > On Thu, 11 Jan 2001, Alice Hennessy wrote:
> >
> > > 1. It doesn't appear to me that suspend affects the locking and
> > > unlocking flowcharts - only program and erase.  Is this a correct
> > > assumption?
> >
> > What do you mean? Suspend affects everything, because we're about to turn
> > off the chip (the oldstate stuff is a thinko). If we're in the middle of
> > telling the chip to lock/unlock then suspend has return failure till we're
> > finished.
>
> I was referring to the "Block Erase, Program Suspend" command in the STRATA
> spec
> and was wondering  if I need to add checking for  FL_LOCKING  in
> do_read_onechip() as we do for
> FL_ERASING.   Should have been more specific :)
> BTW: what does "thinko" mean?

After thinking about it  :) this was a pointless  question since locking
doesn't have the time issue
that erase does and there is no good reason to interrupt it for read.

Alice

>
>
> >
> >
> > > 2. The mtdchar.c ioctl call for MEMUNLOCK passes the start and len
> > > addresses.  The unlock for the STRATA clears all the lock bits.  So I
> > > intend to include logic to reinstate the locked bits that are outside
> > > the desired range.  Sound reasonable?
> >
> > Hmmm. Better to design the API better so it can describe the capabilities
> > of the chip. You don't have to stick to what I threw together - I'm full
> > of crap half the time. Hadn't you realised that yet?
>
> Then my choice would be to keep it simple and let userland keep track of
> what lock bits it has set in the past.
>
> Alice
>
> >
> >
> > --
> > dwmw2



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: LOCK and UNLOCK functions
  2001-01-11 20:38   ` Alice Hennessy
  2001-01-11 20:51     ` Alice Hennessy
@ 2001-01-11 22:43     ` David Woodhouse
  1 sibling, 0 replies; 5+ messages in thread
From: David Woodhouse @ 2001-01-11 22:43 UTC (permalink / raw)
  To: Alice Hennessy; +Cc: mtd

On Thu, 11 Jan 2001, Alice Hennessy wrote:

> BTW: what does "thinko" mean?

Bit like a typo, only an error in thinking rather than an error in typing.

> Then my choice would be to keep it simple and let userland keep track of
> what lock bits it has set in the past.

Sensible. Return -EINVAL for any unlock command which doesn't address the
whole device. But need some way for uspace to know that's the case.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-01-11 22:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-11 19:41 LOCK and UNLOCK functions Alice Hennessy
2001-01-11 20:03 ` David Woodhouse
2001-01-11 20:38   ` Alice Hennessy
2001-01-11 20:51     ` Alice Hennessy
2001-01-11 22:43     ` David Woodhouse

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox