linux-kernel - Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071026212306.40b4a12d@hyperion.delvare>
Date:	Fri, 26 Oct 2007 21:23:06 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	trenn@...e.de, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, lenb@...nel.org
Subject: Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with 
  ACPI Operation Region resources

Hi Andrew,

On Thu, 25 Oct 2007 13:24:10 -0700, Andrew Morton wrote:
> On Thu, 25 Oct 2007 15:51:35 +0200, Jean Delvare wrote:
> > Thanks for picking these patches, having them in -mm for some time is
> > exactly what we need. Let's see how many systems are affected by the
> > resource conflicts and how we can fix them
> 
> No probs.  The main thing is to ensure that we have sufficient debug
> support in that patch so that if a tester does report a problem, we (ie:
> you ;) can resolve it on the first pass.  So feel free to make it really
> noisy - we can always drop the debug stuff later on.

Well, I'm not exactly sure what we can do when people report conflicts,
except telling them "don't do that". I guess each case will be
different. We will have to ask reporters for their DSDT table, look at
it and... do something. I'll need (much) help from the ACPI developers.
At this point we are mainly trying to gather enough data to fully
understand how big the problem is. Solutions will come later.

> Also, please try to avoid adding anythig which would disrupt that tester
> from going on and testing all the other new code.  ie: try to fail
> gracefully and fall back to the old behaviour.

User will simply miss their SMBus controller or their hardware
monitoring device, it wont prevent them from using their systems, but
that should be enough to get them to report (I hope).

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/