From: christian pellegrin <chripell@fsfe.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: feng.tang@intel.com, akpm@linux-foundation.org, greg@kroah.com,
david-b@pacbell.net, alan@lxorguk.ukuu.org.uk,
spi-devel-general@lists.sourceforge.net,
linux-serial@vger.kernel.org
Subject: Re: [PATCH 3/3] max3100: adds console support for MAX3100
Date: Sun, 21 Mar 2010 08:47:22 +0100 [thread overview]
Message-ID: <cabda6421003210047i1d4545aasf8969bb70d48ceb9@mail.gmail.com> (raw)
In-Reply-To: <fa686aa41003191231w54d7489ds917c3cd2de0bea52@mail.gmail.com>
On Fri, Mar 19, 2010 at 8:31 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> +config SERIAL_MAX3100_CONSOLE_N
>> + int "Number of MAX3100 chips to wait before registering console"
>> + depends on SERIAL_MAX3100_CONSOLE=y
>> + default "1"
>> + help
>> + Unfortunately due to the async nature of Linux boot we must
>> + know in advance when to register the console. If we do it
>> + too early not all the MAX3100 chips are known to the system
>> + yet. And we just cannot know how many MAX3100 will be in the
>> + system so it's impossible to wait for the last one. If you
>> + just want to have the console on the first MAX3100 chip
>> + probed (ttyMAX0) it's safe to leave this to 1.
>
> This seems wrong and fragile. It certainly isn't multiplatform safe
> to have it as a CONFIG setting because every board will have a
> different number of devices that it needs to wait for. I don't know
> the console code very well though, but it seems to me that there
> should be a way to register the console regardless and then be able to
> hold off output until the actual backing device shows up.
>
> Anybody know the right thing to do here?
I'll try to dig in the console code, any suggestion from others if
more than welcome.
>> + else {
>> + u16 tx, rx;
>
> inconsistent braces. If you use {} on the else side, then please use
> {} on the if side too.
ack, strange checkpatch.pl didin't catch these.
>> + IRQF_TRIGGER_FALLING, "max3100", s) < 0) {
>
> try to avoid unrelated whitespace changes, it adds noise when reviewing.
>
ack
>> + parity |= MAX3100_PARITY_ON;
>
> s->parity?
>
huh, well spotted. ack
>> + } else {
>> + tx &= ~MAX3100_PE;
>> + parity &= ~MAX3100_PARITY_ON;
>> + }
>> +
>> + if (parity == 'o')
>> + parity |= MAX3100_PARITY_ODD;
>> + else
>> + parity &= ~MAX3100_PARITY_ODD;
>
> ditto?
ack
>
>
> Also, these blocks are really verbose; maybe do this:
ack, I'll reorganize this chunk of code.
>
>> +
>> + msleep(50);
>
> Why the sleep? Shouldn't the console driver be able to handle the SPI
> device not being ready yet?
it's for the max3100 to settle. I'll double check the needed time and
add a comment.
>> + max3100_sr(max3100s[i], tx, &rx);
>> + }
>
> Same comment on braces as for above.
>
ack
Thanks again for the review.
--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-03-21 7:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cabda6421003190139h344bc172h3556fca78e4b25cb@mail.gmail.com>
2010-03-19 8:38 ` [PATCH 1/3] max3100: added raise_threaded_irq Christian Pellegrin
2010-03-19 8:39 ` [PATCH 2/3] max3100: moved to threaded interrupt Christian Pellegrin
2010-03-19 8:39 ` [PATCH 3/3] max3100: adds console support for MAX3100 Christian Pellegrin
[not found] ` <1268987934-22690-1-git-send-email-chripell@fsfe.org>
2010-03-19 17:48 ` [PATCH 1/3] max3100: added raise_threaded_irq Grant Likely
2010-03-21 7:31 ` christian pellegrin
[not found] ` <1268987973-22719-1-git-send-email-chripell@fsfe.org>
2010-03-19 17:58 ` [PATCH 2/3] max3100: moved to threaded interrupt Grant Likely
2010-03-21 7:34 ` christian pellegrin
[not found] ` <1268987997-22746-1-git-send-email-chripell@fsfe.org>
2010-03-19 19:31 ` [PATCH 3/3] max3100: adds console support for MAX3100 Grant Likely
2010-03-21 7:47 ` christian pellegrin [this message]
[not found] ` <cabda6421003210047i1d4545aasf8969bb70d48ceb9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-21 16:28 ` David Brownell
2010-03-22 1:31 ` Feng Tang
2010-03-22 7:03 ` christian pellegrin
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=cabda6421003210047i1d4545aasf8969bb70d48ceb9@mail.gmail.com \
--to=chripell@fsfe.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=david-b@pacbell.net \
--cc=feng.tang@intel.com \
--cc=grant.likely@secretlab.ca \
--cc=greg@kroah.com \
--cc=linux-serial@vger.kernel.org \
--cc=spi-devel-general@lists.sourceforge.net \
/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).