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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 25 Oct 2007 08:04:38 -0400
From:	"Mark M. Hoffman" <mhoffman@...htlink.com>
To:	Thomas Renninger <trenn@...e.de>
Cc:	linux-acpi <linux-acpi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>, Andrew Morton <akpm@...l.org>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources

Hi Thomas:

I recently told someone in private that ACPI vs. hwmon conflicts are the
biggest open problems for the hwmon subsystem.  Thank you (and Jean) for
doing this.

* Thomas Renninger <trenn@...e.de> [2007-10-24 16:31:59 +0200]:
> Hi,
> 
> it seems Len's test tree and Linus tree diverged a bit, at least with
> this patch set things do not apply cleanly.
> 
> Therefore I post these for discussion whether and in which kernel tree
> they should end up before doing work for nothing.
> If they are still a candidate for 2.6.24 (rather unintrusive), pls tell
> me whether and when I should base them against Len's test/release branch
> or whatever other tree.
> If not, it would be great if they can be included into the -mm tree and
> I can rebase them against this one.

Andrew has already picked this series; I vote for extended time in -mm.  On the
hwmon side, there is almost guaranteed to be fallout from this that may take
time to resolve.

> (...)

> A boot parameter acpi_enforce_resources=strict/lax/no is provided, which
> is default set to lax:
>   - strict: let conflicting drivers fail to load with an error message
>   - lax:    let conflicting driver work normal with a warning message
>   - no:     no functional change at all
> Depending on the feedback and the kind of interferences we see, this
> should be set to strict at later time.

As long as it's in -mm, you may as well default to =strict right away.  This
will force people to report.  Open the floodgates; I hope I don't drown.

Regards,

-- 
Mark M. Hoffman
mhoffman@...htlink.com

-
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/