public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Dmitry Torokhov <dtor_core@ameritech.net>,
	Lee Revell <rlrevell@joe-job.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Rumen Ivanov Zarev <rzarev@its.caltech.edu>
Subject: Re: [PATCH] PCI: Unhide SMBus on Compaq Evo N620c
Date: Wed, 7 Sep 2005 20:12:12 +0200	[thread overview]
Message-ID: <20050907201212.5ade5d6c.khali@linux-fr.org> (raw)
In-Reply-To: <d120d500050906160158912aaa@mail.gmail.com>

Hi Dmitry, Lee, Rumen, all,

> > Should unlikely() be used for cases where the conditional will be
> > true iff a specific piece of hardware is present?  Seems like we'd
> > always lose.
> 
> I would say that we should definitely not use [un]likely for code that
> is executed once during boot.

I think that the point of using unlikely in pci/quirks is more political
than technical. PCI quirks are only needed because some manufacturers
don't play fair on purpose or are simply too bad to write a proper BIOS
init sequence. This shouldn't slow down the boot process for owners of
decent hardware that do not need such quirks, or at least should it slow
it down as little as possible. So it's only fair that the worst slowdown
happens when the quirks-needing hardware is actually found.

This consideration left apart, each test looking for a specific piece of
hardware, considered individually, is more likely to fail than succeed
on a random machine, so anyway the use of unlikely makes sense. Whether
or not we think it is worth the additional code is a different matter (I
do, but I know not everybody does.)

Thanks,
-- 
Jean Delvare

      reply	other threads:[~2005-09-07 18:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 20:39 [PATCH] PCI: Unhide SMBus on Compaq Evo N620c Rumen Ivanov Zarev
2005-09-06 22:43 ` Lee Revell
2005-09-06 22:59   ` Rumen Zarev
2005-09-06 23:01   ` Dmitry Torokhov
2005-09-07 18:12     ` Jean Delvare [this message]

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=20050907201212.5ade5d6c.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=dtor_core@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    --cc=rzarev@its.caltech.edu \
    /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