LKML Archive on
help / color / mirror / Atom feed
From: Haavard Skinnemoen <>
To: David Brownell <>
Cc: "Andrew Victor" <>,
	lkml <>,
	"Haavard Skinnemoen" <>,
	"Nicolas Ferre" <>
Subject: Re: [patch 2.6.28-rc2] atmel_serial: keep clock off when it's not needed
Date: Wed, 29 Oct 2008 11:08:45 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

David Brownell <> wrote:
> On Tuesday 28 October 2008, Andrew Victor wrote:
> > hi David,
> > 
> > > I verified it on AT91, where the console is normally DBGU and the
> > > other USARTs do get an open().
> > 
> > The DBGU is part of the system peripherals, which are clocked from MCK
> > and which is always enabled.
> Exactly.

Exactly what? That your patch has exactly zero effect on your test case?

> > Therefore I don't think this is a valid test-case.
> Not for the oddball case Haavard mentioned, no:  the console port
> being something the boot loader wasn't using, which couldn't show
> the early boot messages (before console setup) in any case.  Those
> kinds of systems aren't especially debuggable (it's JTAG or nothing).

Since when is it acceptable to lock up solid in "oddball" cases? Not to
mention that I don't think this is an "oddball" case at all -- the
bootloader has absolutely _no_ way of influencing the initial enable
count of the clock, so the kernel will turn it off as soon as it gets
the chance.

The oddball case is when the clock happens to be shared with
peripherals that are always enabled. Then it doesn't matter if the
clock management in atmel_serial is screwed up.

> I don't have any issue with getting that fixed too ... but unless
> someone has a platform that relies on that case (or can be made to
> do so, for testing), then it's hard for me to worry about it!

David, I can't believe you're taking such an easy attitude towards
basic correctness!

I agree that the clock management is already wrong, but keeping a
couple of clocks enabled when they could have been disabled is far less
of a problem than locking up the console.

I also understand if you don't want to fix the console issue I pointed
out, but I'm surprised that you aren't even willing to acknowledge the
problem, brushing it off with words like "normally" and "as a rule".


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

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-27 21:06 David Brownell
2008-10-28 11:45 ` Haavard Skinnemoen
2008-10-28 16:20   ` David Brownell
2008-10-28 16:37     ` Haavard Skinnemoen
2008-10-28 17:08       ` David Brownell
2008-10-28 17:48         ` Haavard Skinnemoen
2008-10-28 18:41     ` Andrew Victor
2008-10-28 19:51       ` David Brownell
2008-10-29 10:08         ` Haavard Skinnemoen [this message]
2008-10-29 15:54           ` David Brownell

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [patch 2.6.28-rc2] atmel_serial: keep clock off when it'\''s not needed' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).