All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J.D. Bakker" <bakker@thorgal.et.tudelft.nl>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Cc: "J.D. Bakker" <bakker@thorgal.et.tudelft.nl>
Subject: Re: Handling multiple NAND chips
Date: Sun, 27 Jul 2003 15:58:44 +0200	[thread overview]
Message-ID: <a05200f0ebb49894ef8cf@[130.161.115.44]> (raw)
In-Reply-To: <1059313332.9895.3.camel@lapdancer.baythorne.internal>

At 9:42 -0400 27-07-2003, David Woodhouse wrote:
>On Sun, 2003-07-27 at 08:54, J.D. Bakker wrote:
>>  What is the return value for select_chip supposed to be ? Current CVS
>>  is a bit ambiguous in this regard (understandably, considering the
>>  newness).
>
>Currently void -- I can't imagine cases where it could fail. I suppose
>I'll probably turn out to be wrong though...

I was wondering what to do when 'chip' is larger than the maximum 
number of NANDs. Currently I silently deselect all devices when that 
happens.

>  > Style question: unsigned char, __u8, u_char, u_int8_t or uint8_t ?
>>  The kernel part of CVS uses all five in different places.
>
>unsigned char, uint8_t and u_char are the only ones I'd want to see --
>and the latter only if it's already in use. One of the former two in new
>code, please -- preferably 'unsigned char' I think.

unsigned char it is then.

>I reserve the right to do otherwise, and to change my mind -- not
>necessarily in that order.

HEY! I resemble that remark !

Thanks,

JDB
[just tried to insmod my first cut of the lartcan NAND driver -- blew 
up with 'partition extends beyond the end of device "<NULL>"' and a 
bunch of divisions by zero. Back to the drawing board...]
-- 
Your eyes are weary from staring at the CRT. You feel sleepy. Notice 
how restful it is to watch the cursor blink. Close your eyes. The 
opinions stated above are yours. You cannot imagine why you ever felt 
otherwise.

  reply	other threads:[~2003-07-27 13:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-25 15:12 Handling multiple NAND chips J.D. Bakker
2003-07-25 15:36 ` David Woodhouse
2003-07-25 15:51   ` J.D. Bakker
2003-07-25 15:56     ` David Woodhouse
2003-07-26 10:22       ` J.D. Bakker
2003-07-26 11:39         ` Thomas Gleixner
2003-07-26 15:08           ` David Woodhouse
2003-07-26 17:20             ` Thomas Gleixner
2003-07-26 15:06         ` David Woodhouse
2003-07-26 18:20           ` J.D. Bakker
2003-07-26 19:05             ` David Woodhouse
2003-07-27 12:54       ` J.D. Bakker
2003-07-27 13:42         ` David Woodhouse
2003-07-27 13:58           ` J.D. Bakker [this message]
2003-07-27 16:28             ` David Woodhouse
2003-07-25 15:51 ` David Woodhouse
2003-07-26  0:27 ` Charles Manning
2003-07-26 10:32   ` J.D. Bakker

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='a05200f0ebb49894ef8cf@[130.161.115.44]' \
    --to=bakker@thorgal.et.tudelft.nl \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.