Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Jean Delvare]

Dear stable kernel team,

In stable kernel 4.19.2, the following upstream commit was included:

commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
Author: Erik Schmauss
Date:   Wed Oct 17 14:09:35 2018 -0700

    ACPICA: AML interpreter: add region addresses in global list during initialization

This commit was tagged with:

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
    Tested-by: Jean-Marc Lenoir
    Cc: All applicable <stable@vger.kernel.org>

making it sound like it was fixing an actual bug. This is not the case.
The commit fixes a side issue discovered while investigating bug
#200011. It does NOT fix bug #200011 itself (as explicitly reported by
Jean-Marc at https://bugzilla.kernel.org/show_bug.cgi?id=200011#c65 ).

It does however cause regressions, despite what the commit message says. See:

https://bugzilla.kernel.org/show_bug.cgi?id=201721

and I expect more similar regressions, as ACPI resource conflicts are
very frequent.

This commit was not stable material to start with. It is intrusive,
presents a risk of side effects, and does not solve an actual bug that
is bothering users.

Please revert this commit from future stable kernels on all affected
branches (I think only 4.18.19 and 4.19.2 are affected at the moment,
but maybe other affected releases are in the works already).

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Greg KH]

On Tue, Nov 20, 2018 at 09:46:49AM +0100, Jean Delvare wrote:
> Dear stable kernel team,
> 
> In stable kernel 4.19.2, the following upstream commit was included:
> 
> commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
> Author: Erik Schmauss
> Date:   Wed Oct 17 14:09:35 2018 -0700
> 
>     ACPICA: AML interpreter: add region addresses in global list during initialization
> 
> This commit was tagged with:
> 
>     Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
>     Tested-by: Jean-Marc Lenoir
>     Cc: All applicable <stable@vger.kernel.org>
> 
> making it sound like it was fixing an actual bug. This is not the case.
> The commit fixes a side issue discovered while investigating bug
> #200011. It does NOT fix bug #200011 itself (as explicitly reported by
> Jean-Marc at https://bugzilla.kernel.org/show_bug.cgi?id=200011#c65 ).
> 
> It does however cause regressions, despite what the commit message says. See:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=201721
> 
> and I expect more similar regressions, as ACPI resource conflicts are
> very frequent.
> 
> This commit was not stable material to start with. It is intrusive,
> presents a risk of side effects, and does not solve an actual bug that
> is bothering users.
> 
> Please revert this commit from future stable kernels on all affected
> branches (I think only 4.18.19 and 4.19.2 are affected at the moment,
> but maybe other affected releases are in the works already).

Ok, I'll go revert this, but shouldn't it also be reverted in Linus's
tree as well?

thanks,

greg k-h

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Jean Delvare]

On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:
> On Tue, Nov 20, 2018 at 09:46:49AM +0100, Jean Delvare wrote:
> > Dear stable kernel team,
> > 
> > In stable kernel 4.19.2, the following upstream commit was included:
> > 
> > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
> > Author: Erik Schmauss
> > Date:   Wed Oct 17 14:09:35 2018 -0700
> > 
> >     ACPICA: AML interpreter: add region addresses in global list during initialization
> >
> > (...)
> > Please revert this commit from future stable kernels on all affected
> > branches (I think only 4.18.19 and 4.19.2 are affected at the moment,
> > but maybe other affected releases are in the works already).  
> 
> Ok, I'll go revert this, but shouldn't it also be reverted in Linus's
> tree as well?

No. As I understand it (with my limited knowledge of ACPICA), the
change itself is correct. The problem is that it will detect resource
conflicts which were unnoticed before, and that will prevent drivers
from loading. Some of them may be addressed with driver fixes or new
drivers. Others are false positives (due to bogus BIOS) which users
will have to work around with acpi_resource_conflicts=lax. We have been
through this before, nothing new really, but it takes years to address
such problems. This just can't be done in stable kernel series.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Greg KH]

On Tue, Nov 20, 2018 at 10:03:59AM +0100, Jean Delvare wrote:
> On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:
> > On Tue, Nov 20, 2018 at 09:46:49AM +0100, Jean Delvare wrote:
> > > Dear stable kernel team,
> > > 
> > > In stable kernel 4.19.2, the following upstream commit was included:
> > > 
> > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
> > > Author: Erik Schmauss
> > > Date:   Wed Oct 17 14:09:35 2018 -0700
> > > 
> > >     ACPICA: AML interpreter: add region addresses in global list during initialization
> > >
> > > (...)
> > > Please revert this commit from future stable kernels on all affected
> > > branches (I think only 4.18.19 and 4.19.2 are affected at the moment,
> > > but maybe other affected releases are in the works already).  
> > 
> > Ok, I'll go revert this, but shouldn't it also be reverted in Linus's
> > tree as well?
> 
> No. As I understand it (with my limited knowledge of ACPICA), the
> change itself is correct. The problem is that it will detect resource
> conflicts which were unnoticed before, and that will prevent drivers
> from loading. Some of them may be addressed with driver fixes or new
> drivers. Others are false positives (due to bogus BIOS) which users
> will have to work around with acpi_resource_conflicts=lax. We have been
> through this before, nothing new really, but it takes years to address
> such problems. This just can't be done in stable kernel series.

Fair enough, I have seen reports about this already.  Now reverted.

thanks,

greg k-h

RE: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Schmauss, Erik]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Tuesday, November 20, 2018 1:12 AM
> To: Jean Delvare <jdelvare@suse.de>
> Cc: stable@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>;
> Schmauss, Erik <erik.schmauss@intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki@intel.com>
> Subject: Re: Please revert "ACPICA: AML interpreter: add region addresses in
> global list during initialization"
> 
> On Tue, Nov 20, 2018 at 10:03:59AM +0100, Jean Delvare wrote:
> > On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:
> > > On Tue, Nov 20, 2018 at 09:46:49AM +0100, Jean Delvare wrote:
> > > > Dear stable kernel team,
> > > >
> > > > In stable kernel 4.19.2, the following upstream commit was included:
> > > >
> > > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
> > > > Author: Erik Schmauss
> > > > Date:   Wed Oct 17 14:09:35 2018 -0700
> > > >
> > > >     ACPICA: AML interpreter: add region addresses in global list
> > > > during initialization
> > > >
> > > > (...)
Hi,

> > > > Please revert this commit from future stable kernels on all
> > > > affected branches (I think only 4.18.19 and 4.19.2 are affected at
> > > > the moment, but maybe other affected releases are in the works
> already).
> > >
> > > Ok, I'll go revert this, but shouldn't it also be reverted in
> > > Linus's tree as well?
> >

Hello,
> > No. As I understand it (with my limited knowledge of ACPICA), the
> > change itself is correct. The problem is that it will detect resource
> > conflicts which were unnoticed before, and that will prevent drivers
> > from loading. Some of them may be addressed with driver fixes or new
> > drivers. Others are false positives (due to bogus BIOS) which users
> > will have to work around with acpi_resource_conflicts=lax. We have
> > been through this before, nothing new really, but it takes years to
> > address such problems. This just can't be done in stable kernel series.

I would like to give you more context.

There was a fairly complicated change that occurred in 4.17 and we
caused a regression by forgetting to add region addresses in a global list
during operation region initialization. We found the regression when bug
reporters tried to boot their macbook pro and asus laptop and saw that
there was a difference in behavior when drivers are being loaded

So what I am trying to say is that we have been emitting these errors for a
while before we caused the regression. The goal with this patch is to keep
the behavior the same as kernels older than 4.17  where warnings are
printed to dmesg due to resource conflicts.

Erik
> 
> Fair enough, I have seen reports about this already.  Now reverted.
> 
> thanks,
> 
> greg k-h

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Greg KH]

On Tue, Nov 20, 2018 at 06:30:22PM +0000, Schmauss, Erik wrote:
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Tuesday, November 20, 2018 1:12 AM
> > To: Jean Delvare <jdelvare@suse.de>
> > Cc: stable@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>;
> > Schmauss, Erik <erik.schmauss@intel.com>; Wysocki, Rafael J
> > <rafael.j.wysocki@intel.com>
> > Subject: Re: Please revert "ACPICA: AML interpreter: add region addresses in
> > global list during initialization"
> > 
> > On Tue, Nov 20, 2018 at 10:03:59AM +0100, Jean Delvare wrote:
> > > On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:
> > > > On Tue, Nov 20, 2018 at 09:46:49AM +0100, Jean Delvare wrote:
> > > > > Dear stable kernel team,
> > > > >
> > > > > In stable kernel 4.19.2, the following upstream commit was included:
> > > > >
> > > > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
> > > > > Author: Erik Schmauss
> > > > > Date:   Wed Oct 17 14:09:35 2018 -0700
> > > > >
> > > > >     ACPICA: AML interpreter: add region addresses in global list
> > > > > during initialization
> > > > >
> > > > > (...)
> Hi,
> 
> > > > > Please revert this commit from future stable kernels on all
> > > > > affected branches (I think only 4.18.19 and 4.19.2 are affected at
> > > > > the moment, but maybe other affected releases are in the works
> > already).
> > > >
> > > > Ok, I'll go revert this, but shouldn't it also be reverted in
> > > > Linus's tree as well?
> > >
> 
> Hello,
> > > No. As I understand it (with my limited knowledge of ACPICA), the
> > > change itself is correct. The problem is that it will detect resource
> > > conflicts which were unnoticed before, and that will prevent drivers
> > > from loading. Some of them may be addressed with driver fixes or new
> > > drivers. Others are false positives (due to bogus BIOS) which users
> > > will have to work around with acpi_resource_conflicts=lax. We have
> > > been through this before, nothing new really, but it takes years to
> > > address such problems. This just can't be done in stable kernel series.
> 
> I would like to give you more context.
> 
> There was a fairly complicated change that occurred in 4.17 and we
> caused a regression by forgetting to add region addresses in a global list
> during operation region initialization. We found the regression when bug
> reporters tried to boot their macbook pro and asus laptop and saw that
> there was a difference in behavior when drivers are being loaded
> 
> So what I am trying to say is that we have been emitting these errors for a
> while before we caused the regression. The goal with this patch is to keep
> the behavior the same as kernels older than 4.17  where warnings are
> printed to dmesg due to resource conflicts.

Ok, so does this mean it belongs in 4.19.y?  (4.18.y is about to go
end-of-life in a few hours)

Or does this mean it should just stay in 4.20?

confused,

greg k-h

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Jean Delvare]

Hi Erik,

On Tue, 20 Nov 2018 18:30:22 +0000, Schmauss, Erik wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Tuesday, November 20, 2018 1:12 AM
> > To: Jean Delvare <jdelvare@suse.de>
> > Cc: stable@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>;
> > Schmauss, Erik <erik.schmauss@intel.com>; Wysocki, Rafael J
> > <rafael.j.wysocki@intel.com>
> > Subject: Re: Please revert "ACPICA: AML interpreter: add region addresses in
> > global list during initialization"
> > 
> > On Tue, Nov 20, 2018 at 10:03:59AM +0100, Jean Delvare wrote:  
> > > On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:  
> > > > Ok, I'll go revert this, but shouldn't it also be reverted in
> > > > Linus's tree as well?  
> > >  
> > > No. As I understand it (with my limited knowledge of ACPICA), the
> > > change itself is correct. The problem is that it will detect resource
> > > conflicts which were unnoticed before, and that will prevent drivers
> > > from loading. Some of them may be addressed with driver fixes or new
> > > drivers. Others are false positives (due to bogus BIOS) which users
> > > will have to work around with acpi_resource_conflicts=lax. We have
> > > been through this before, nothing new really, but it takes years to
> > > address such problems. This just can't be done in stable kernel series.  
> 
> I would like to give you more context.
> 
> There was a fairly complicated change that occurred in 4.17 and we
> caused a regression by forgetting to add region addresses in a global list
> during operation region initialization. We found the regression when bug
> reporters tried to boot their macbook pro and asus laptop and saw that
> there was a difference in behavior when drivers are being loaded

Commit 4abb951b73ff0a8a979113ef185651aa3c8da19b has no Fixes tag. Which
commit introduced the regression? Can you point me to the associated
bug reports?

> So what I am trying to say is that we have been emitting these errors for a
> while before we caused the regression. The goal with this patch is to keep
> the behavior the same as kernels older than 4.17 where warnings are
> printed to dmesg due to resource conflicts.

Fine with me for upstream, but I still need to be convinced that it
belongs to stable series. For now, the only 2 related bugs I know of are
#200011 (which is NOT fixed by commit
4abb951b73ff0a8a979113ef185651aa3c8da19b) and #201721 (which is caused
by that commit). 1 vs 0, revert wins. If you want me to change my mind,
you must provide additional data points proving that commit
4abb951b73ff0a8a979113ef185651aa3c8da19b solves more functional
regressions than it causes.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

RE: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Schmauss, Erik]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, November 21, 2018 12:04 AM
> To: Schmauss, Erik <erik.schmauss@intel.com>
> Cc: Jean Delvare <jdelvare@suse.de>; stable@vger.kernel.org; Guenter Roeck
> <linux@roeck-us.net>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Moore,
> Robert <robert.moore@intel.com>
> Subject: Re: Please revert "ACPICA: AML interpreter: add region addresses in
> global list during initialization"
> 
> On Tue, Nov 20, 2018 at 06:30:22PM +0000, Schmauss, Erik wrote:
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@kroah.com]
> > > Sent: Tuesday, November 20, 2018 1:12 AM
> > > To: Jean Delvare <jdelvare@suse.de>
> > > Cc: stable@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>;
> > > Schmauss, Erik <erik.schmauss@intel.com>; Wysocki, Rafael J
> > > <rafael.j.wysocki@intel.com>
> > > Subject: Re: Please revert "ACPICA: AML interpreter: add region
> > > addresses in global list during initialization"
> > >
> > > On Tue, Nov 20, 2018 at 10:03:59AM +0100, Jean Delvare wrote:
> > > > On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:
> > > > > On Tue, Nov 20, 2018 at 09:46:49AM +0100, Jean Delvare wrote:
> > > > > > Dear stable kernel team,
> > > > > >
> > > > > > In stable kernel 4.19.2, the following upstream commit was included:
> > > > > >
> > > > > > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b
> > > > > > Author: Erik Schmauss
> > > > > > Date:   Wed Oct 17 14:09:35 2018 -0700
> > > > > >
> > > > > >     ACPICA: AML interpreter: add region addresses in global
> > > > > > list during initialization
> > > > > >
> > > > > > (...)
> > Hi,
> >
> > > > > > Please revert this commit from future stable kernels on all
> > > > > > affected branches (I think only 4.18.19 and 4.19.2 are
> > > > > > affected at the moment, but maybe other affected releases are
> > > > > > in the works
> > > already).
> > > > >
> > > > > Ok, I'll go revert this, but shouldn't it also be reverted in
> > > > > Linus's tree as well?
> > > >
> >
> > Hello,
> > > > No. As I understand it (with my limited knowledge of ACPICA), the
> > > > change itself is correct. The problem is that it will detect
> > > > resource conflicts which were unnoticed before, and that will
> > > > prevent drivers from loading. Some of them may be addressed with
> > > > driver fixes or new drivers. Others are false positives (due to
> > > > bogus BIOS) which users will have to work around with
> > > > acpi_resource_conflicts=lax. We have been through this before,
> > > > nothing new really, but it takes years to address such problems. This just
> can't be done in stable kernel series.
> >
> > I would like to give you more context.
> >
> > There was a fairly complicated change that occurred in 4.17 and we
> > caused a regression by forgetting to add region addresses in a global
> > list during operation region initialization. We found the regression
> > when bug reporters tried to boot their macbook pro and asus laptop and
> > saw that there was a difference in behavior when drivers are being
> > loaded
> >
> > So what I am trying to say is that we have been emitting these errors
> > for a while before we caused the regression. The goal with this patch
> > is to keep the behavior the same as kernels older than 4.17  where
> > warnings are printed to dmesg due to resource conflicts.
> 
> Ok, so does this mean it belongs in 4.19.y?  (4.18.y is about to go end-of-life in a
> few hours)

Yes, it should be in 4.19.y

Erik
> 
> Or does this mean it should just stay in 4.20?
> 
> confused,
> 
> greg k-h

RE: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Schmauss, Erik]

Snip
> > > >
> > > > On Tue, Nov 20, 2018 at 10:03:59AM +0100, Jean Delvare wrote:
> > > > > On Tue, 20 Nov 2018 09:54:19 +0100, Greg KH wrote:
> > > > > > Ok, I'll go revert this, but shouldn't it also be reverted in
> > > > > > Linus's tree as well?
> > > > > 

Hi Jean and Greg,

> > > > > No. As I understand it (with my limited knowledge of ACPICA),
> > > > > the change itself is correct. The problem is that it will detect
> > > > > resource conflicts which were unnoticed before, and that will
> > > > > prevent drivers from loading. Some of them may be addressed with
> > > > > driver fixes or new drivers. Others are false positives (due to
> > > > > bogus BIOS) which users will have to work around with
> > > > > acpi_resource_conflicts=lax. We have been through this before,
> > > > > nothing new really, but it takes years to address such problems.
> > > > > This just
> > can't be done in stable kernel series.
> > >
> > > I would like to give you more context.
> > >
> > > There was a fairly complicated change that occurred in 4.17 and we
> > > caused a regression by forgetting to add region addresses in a
> > > global list during operation region initialization. We found the
> > > regression when bug reporters tried to boot their macbook pro and
> > > asus laptop and saw that there was a difference in behavior when
> > > drivers are being loaded
> >
> > Commit 4abb951b73ff0a8a979113ef185651aa3c8da19b has no Fixes tag.
> > Which commit introduced the regression? Can you point me to the
> > associated bug reports?
> 
> Sorry about the missing fixed tag. It's supposed to fix
> 5a8361f7ecceaed64b4064000d16cb703462be49
>     ACPICA: Integrate package handling with module-level code
> 
> >
> > > So what I am trying to say is that we have been emitting these
> > > errors for a while before we caused the regression. The goal with
> > > this patch is to keep the behavior the same as kernels older than
> > > 4.17 where warnings are printed to dmesg due to resource conflicts.
> >
> > Fine with me for upstream, but I still need to be convinced that it
> > belongs to stable series. For now, the only 2 related bugs I know of
> > are
> > #200011 (which is NOT fixed by commit
> 
> This bug is kind of messy. It's like 2 bugs in 1 report. This patch fixes a part of
> their problem. Another part has to do with ECDT load order.
> 
> Would it help to open a separate bug report for this particular issue and close
> it?
> I think this might be a little confusing to someone who reads the commit
> message.
> 
> > 4abb951b73ff0a8a979113ef185651aa3c8da19b) and #201721 (which is
> caused
> 
> I did not know about this bug report.
> 
> > by that commit). 1 vs 0, revert wins. If you want me to change my
> > mind, you must provide additional data points proving that commit
> > 4abb951b73ff0a8a979113ef185651aa3c8da19b solves more functional
> > regressions than it causes.

Here's an additional data point from the discussion on bz201721.
The user started using fancontrol during the period where resource conflict
checking was unintentionally removed. If the reporter tries using fancontrol
on 4.18.13, they report that fancontrol does not work. So it was basically
always the case that he needed to use acpi_resource_conflicts=lax for a short
period of time.

I understand that this "breaks" this machine but we shouldn't be reverting
resource conflict checking for all other drivers just because of fancontrol. By
removing this check, we are suppressing warnings and changing the loading behavior
of other drivers as well.

Thanks,
Erik

> 
> If we do not have include this commit, then we are in a state where resource
> conflicts are not properly detected. These detections help kernels decide
> which drivers to load. However, I do see your point about this breaking the
> reporter's machine and it's possible that I may have missed something.
> 
> We should get the reporter's dmesg for older kernels.
> 
> It would be ideal to resolve this bug AND add region addresses in the global
> address list.
> I've asked the bug reporter in #201721 for more information. We can delay
> this patch for now and look at the reporter's issue more carefully.
> 
> Thanks for all of the information!
> 
> Erik
> >
> > Thanks,
> > --
> > Jean Delvare
> > SUSE L3 Support

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

[Jean Delvare]

Hi Erik, Greg,

On Wed, 28 Nov 2018 00:27:37 +0000, Schmauss, Erik wrote:
> Here's an additional data point from the discussion on bz201721.
> The user started using fancontrol during the period where resource conflict
> checking was unintentionally removed. If the reporter tries using fancontrol
> on 4.18.13, they report that fancontrol does not work. So it was basically
> always the case that he needed to use acpi_resource_conflicts=lax for a short
> period of time.
> 
> I understand that this "breaks" this machine but we shouldn't be reverting
> resource conflict checking for all other drivers just because of fancontrol. By
> removing this check, we are suppressing warnings and changing the loading behavior
> of other drivers as well.

I agree. The incorrect (or at the very least incomplete and confusing)
claims in bug #201721 made me think it was a regression from older
versions. As it turns out that this isn't the case, my request to
revert 4abb951b73ff0a8a979113ef185651aa3c8da19b from stable kernel
series was incorrect. I apologize for the noise and ask Greg to undo
the revert.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Please revert "ACPICA: AML interpreter: add region addresses in global list during initialization"

['Greg KH']

On Wed, Nov 28, 2018 at 09:56:27AM +0100, Jean Delvare wrote:
> Hi Erik, Greg,
> 
> On Wed, 28 Nov 2018 00:27:37 +0000, Schmauss, Erik wrote:
> > Here's an additional data point from the discussion on bz201721.
> > The user started using fancontrol during the period where resource conflict
> > checking was unintentionally removed. If the reporter tries using fancontrol
> > on 4.18.13, they report that fancontrol does not work. So it was basically
> > always the case that he needed to use acpi_resource_conflicts=lax for a short
> > period of time.
> > 
> > I understand that this "breaks" this machine but we shouldn't be reverting
> > resource conflict checking for all other drivers just because of fancontrol. By
> > removing this check, we are suppressing warnings and changing the loading behavior
> > of other drivers as well.
> 
> I agree. The incorrect (or at the very least incomplete and confusing)
> claims in bug #201721 made me think it was a regression from older
> versions. As it turns out that this isn't the case, my request to
> revert 4abb951b73ff0a8a979113ef185651aa3c8da19b from stable kernel
> series was incorrect. I apologize for the noise and ask Greg to undo
> the revert.

Ok, now added back, thanks.

greg k-h