All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg@redhat.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Don Zickus <dzickus@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Prarit Bhargava <prarit@redhat.com>,
	linux-kernel@vger.kernel.org,
	Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [PATCH v3] Add TAINT_HARDWARE_UNSUPPORTED flag
Date: Wed, 23 Jun 2010 04:30:47 +0100	[thread overview]
Message-ID: <20100623033047.GA32644@srcf.ucam.org> (raw)
In-Reply-To: <20100623030637.GA30139@linux-sh.org>

On Wed, Jun 23, 2010 at 12:06:38PM +0900, Paul Mundt wrote:

> What exactly is the use case supposed to be? If drivers are supposed to
> call in to it for specific devices then they already have all of the
> information they need for constructing a device blacklist and providing
> more detailed information. If it's a configuration issue then we have
> device quirks, which could also be extended to other busses as needed. In
> either case, the context ought to be fairly explicit. I would much rather
> see a message from the bus code stating that a specific device has been
> disabled and skip the probe path entirely rather than trying to bolt on a
> system-wide unsupported hardware state.

Hardware may work, it may just not work well enough that a software 
vendor (eg, Red Hat) wants to deal with problem reports (eg, oopses 
caused by a network card DMAing to the wrong place) from systems with 
specific bits of hardware (eg, network cards that enjoy DMAing to the 
wrong place occasionally). It may not even be down to technical issues - 
the vendor may just have chosen to refuse to support systems with old 
CPU families. It'd be straightforward to make the kernel simply refuse 
to boot on them, but it seems more elegant to let it boot and alert the 
user to the situation.

I don't think it's a flag that would ever be used in mainline, and 
Alan's suggestion to just keep a range of taint flags as vendor-specific 
would avoid the risk of collisions in future. But there's a minor 
incentive to maintain standardisation over these things in order to 
encourage commonality of report code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2010-06-23  3:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17 13:54 [PATCH] Add TAINT_HARDWARE_UNSUPPORTED flag Prarit Bhargava
2010-06-17 16:13 ` Randy Dunlap
2010-06-17 19:54   ` Prarit Bhargava
2010-06-17 20:28     ` Randy Dunlap
2010-06-21 19:21     ` Andrew Morton
2010-06-21 19:45       ` Don Zickus
2010-06-21 20:00         ` Andrew Morton
2010-06-21 20:46           ` Don Zickus
2010-06-22 15:34           ` [PATCH v3] " Don Zickus
2010-06-22 15:48             ` Alan Cox
2010-06-22 16:38               ` Matthew Garrett
2010-06-22 16:57                 ` Alan Cox
2010-06-22 17:04                   ` Matthew Garrett
2010-06-23  3:06                     ` Paul Mundt
2010-06-23  3:30                       ` Matthew Garrett [this message]
2010-06-23 20:00                         ` Don Zickus
2010-06-22 18:58               ` [PATCH v4] " Don Zickus
2010-07-06 20:33                 ` Don Zickus
2010-07-06 22:18                   ` Alan Cox
2010-06-19  8:40 ` [PATCH] " Andi Kleen
2010-06-19  9:30 ` Alan Cox
2010-06-21 13:26   ` Don Zickus

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=20100623033047.GA32644@srcf.ucam.org \
    --to=mjg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dzickus@redhat.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=randy.dunlap@oracle.com \
    /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.