All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [PATCH] Add Micro-Star as a PCI VENDOR
Date: Mon, 29 Jan 2007 08:32:20 +0000	[thread overview]
Message-ID: <20070129093220.30efba22.khali@linux-fr.org> (raw)
In-Reply-To: <c1cd85210701241715p29fb437dy9400e74afaf8bbf7@mail.gmail.com>

Hi Gordon,

On Mon, 29 Jan 2007 16:52:34 +1100, Gordon Stanton wrote:
> Hi Jean,
> Firstly, sorry for the personal reply. I thought it might be better though.

For what reason? First you send your message to 6 mailing lists, then
replies go to just one person? I'm adding the relevant lists and
persons to Cc again.

> On 1/25/07, Jean Delvare <khali at linux-fr.org> wrote:
> > Posting to 6 mailing-lists at once, are you mad?
> > I kept only the relevant ones.
> 
> SMBus on PCI with ACPI crosses many areas.

I fail to see how it is related to ACPI at all.

> I'ts fixes a PCI quirk.(linux-pci)
> The fix will unhide the SMBus like ASUS needs.(acpi4asus)

Irrelevant. Asus were the first ones to do it, but half a dozen vendors
do it by now. And the Asus system users certainly couldn't care less
that yet another system needs it.

> Hopefully enabling some more sensors (like fans) to be
> seen.(linux-acpi,lm-sensors)

"Hopefully?" You'd better make sure first. We're not going to add an
unhiding quirk if there's nothing useful on the SMBus in question.

> > I would suggest PCI_VENDOR_ID_MSI, that's how people know them.
> 
> I thought of that but MSI in relation to PCI means "Message Signaled
> Interrupt" so I would rather go with PCI_VENDOR_MICRO_STAR which also

Come on, the symbol is named PCI_VENDOR_ID_<something>, it's pretty
clear what it stands for. If someone really thinks that
PCI_VENDOR_ID_MSI could be related to message-signaled interrupts, that
person better doesn't touch the kernel code at all.

We already have 62 two- or three-letter PCI vendor ID symbols in
pci_ids.h, one more really isn't a problem.

> tabs in the source code nicely. Although in truth it probably should

"Tabs in the source code nicely"? What do you mean?

> be PCI_VENDOR_MICRO_STAR_INTL but that is just getting too long.

That I couldn't agree more.

-- 
Jean Delvare


      parent reply	other threads:[~2007-01-29  8:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25  1:15 [PATCH] Add Micro-Star as a PCI VENDOR Gordon Stanton
2007-01-25  1:15 ` [lm-sensors] " Gordon Stanton
2007-01-25  1:26 ` Greg KH
2007-01-25  1:26   ` [lm-sensors] " Greg KH
2007-01-25  8:07 ` Jean Delvare
2007-01-29  8:32 ` 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=20070129093220.30efba22.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@vger.kernel.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.