From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mika Westerberg Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder Date: Fri, 30 Jun 2017 13:56:50 +0300 Message-ID: <20170630105650.GY629@lahna.fi.intel.com> References: <20170626204009.32607-1-lyude@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20170626204009.32607-1-lyude@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Lyude Cc: Jean Delvare , Wolfram Sang , Benjamin Tissoires , intel-gfx@lists.freedesktop.org, "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org, Jean Delvare List-Id: linux-acpi@vger.kernel.org T24gTW9uLCBKdW4gMjYsIDIwMTcgYXQgMDQ6NDA6MDhQTSAtMDQwMCwgTHl1ZGUgd3JvdGU6Cj4g VGhlcmUncyBxdWl0ZSBhIG51bWJlciBvZiBtYWNoaW5lcyBvbiB0aGUgbWFya2V0LCBtYWlubHkg TGVub3ZvCj4gVGhpbmtQYWRzLCB0aGF0IG1ha2UgdGhlIGhvcnJpYmxlIG1pc3Rha2UgaW4gdGhl aXIgZmlybXdhcmUgb2YgcmV1c2luZwo+IHRoZSBQQ0lCQVIgc3BhY2UgcmVzZXJ2ZWQgZm9yIHRo ZSBTTUJ1cyBmb3IgdGhpbmdzIHRoYXQgYXJlIGNvbXBsZXRlbHkKPiB1bnJlbGF0ZWQgdG8gdGhl IFNNQnVzIGNvbnRyb2xsZXIsIHN1Y2ggYXMgdGhlIE9wUmVnaW9uIHVzZWQgZm9yIGk5MTUuCj4g VGhpcyBpcyB2ZXJ5IGJhZCBhbmQgZW50aXJlbHkgZXZpbCwgYnV0IHdpdGggTGVub3ZvJ3MgaGlz dG9yaWNhbGx5IHBvb3IKPiB0cmFjayByZWNvcmQgb2YgZml4aW5nIHRoZWlyIGZpcm13YXJlLCBp dCBpcyBleHRyZW1lbHkgdW5saWtlbHkgdGhpcyBpcwo+IGV2ZXIgZ29pbmcgdG8gYmUgcHJvcGVy bHkgZml4ZWQuCj4gCj4gU28sIHdoaWxlIGl0IHdvdWxkIGJlIG5pY2UgaWYgd2UgY291bGQganVz dCBjdXQgb2ZmIHRoZSBTTUJ1cyBjb250cm9sbGVyCj4gYW5kIGNhbGwgaXQgYSBkYXkgdGhpcyB1 bmZvcnR1bmF0ZWx5IGJyZWFrcyBSTUk0IG1vZGUgY29tcGxldGVseSBmb3IKPiBtb3N0IG9mIHRo ZSBUaGlua1BhZHMuIEV2ZW4gdGhvdWdoIHRoaXMgYmVoYXZpb3IgaXMgZXh0cmVtZWx5IHdyb25n LCBmb3IKPiB3aGF0ZXZlciByZWFzb24gc2hhcmluZyB0aGUgUENJQkFSIGJldHdlZW4gdGhlIE9w UmVnaW9uIGFuZCBTTUJ1cyBzZWVtcwo+IHRvIGJlIGp1c3QgZmluZS4gUmVnYXJkbGVzcyBob3dl dmVyLCBJIHRoaW5rIGl0J3Mgc2FmZSB0byBhc3N1bWUgdGhhdAo+IHdoZW4gdGhlIEJJT1MgYWNj ZXNzZXMgdGhlIFBDSUJBUiBzcGFjZSBvZiB0aGUgU01CdXMgY29udHJvbGxlciBsaWtlCj4gdGhp cyB0aGF0IGl0J3MgdHJ5aW5nIHRvIGdldCB0byBzb21ldGhpbmcgZWxzZSB0aGF0IHdlIG1hcHBl ZCB0aGUgU01CdXMKPiBjb250cm9sbGVyIG92ZXIuCj4gCj4gT24gbXkgWDEgQ2FyYm9uLCB0aGlz IGFzc3VtcHRpb24gYXBwZWFycyB0byBiZSBjb3JyZWN0LiBJJ3ZlIHRyYWNlZCBkb3duCj4gdGhl IGZpcm13YXJlIGFjY2Vzc2VzIHRvIGJlaW5nIGNhdXNlZCBieSB0aGUgZmlybXdhcmUgbWlzdGFr ZW5seSBwbGFjaW5nCj4gdGhlIFNXU0NJIG1haWxib3ggZm9yIGk5MTUgb24gdG9wIG9mIHRoZSBT TUJ1cyBob3N0IGNvbnRyb2xsZXIgcmVnaW9uLgo+IEFuZCBpbmRlZWQsIGJsYWNrbGlzdGluZyBp OTE1IGNhdXNlcyB0aGUgZmlybXdhcmUgdG8gbmV2ZXIgYXR0ZW1wdCB0bwo+IHRvdWNoIHRoaXMg cmVnaW9uLgo+IAo+IFNvLCBpbiBvcmRlciB0byB0cnkgdG8gd29ya2Fyb3VuZCB0aGlzIGFuZCBu b3QgYnJlYWsgZWl0aGVyIFNNQnVzIG9yCj4gaTkxNSwgd2UgdGVtcG9yYXJpbHkgdW5tYXAgdGhl IFBDSSBkZXZpY2UgZm9yIHRoZSBTTUJ1cyBjb250cm9sbGVyLAo+IGRvIHRoZSB0aGluZyB0aGF0 IHRoZSBmaXJtd2FyZSB3YW50ZWQgdG8gZG8sIHRoZW4gcmVtYXAgdGhlIGRldmljZSBhbmQKPiBy ZXBvcnQgYSBmaXJtd2FyZSBidWcuCgpBcmUgdGhlIHJlZ2lzdGVycyBpdCB0cmllcyB0byBhY2Nl c3Mgc2VwYXJhdGUgZnJvbSBTTUJ1cyBvbmVzPyBXZQphbHJlYWR5IGhhdmUgVENPIHJlZ2lzdGVy cyBwbGFjZWQgdG8gdGhpcyBkZXZpY2Ugc3RhcnRpbmcgZnJvbSBTa3lsYWtlCnNvIHRoZXJlIG1p Z2h0IGJlIHNvbWV0aGluZyBlbHNlIGFzIHdlbGwuCgpQb2ludCBoZXJlIGlzIHRoYXQgaWYgdGhl IGFjY2VzcyBpcyBub3QgdG8gdGhlIFNNQnVzIHJlZ2lzdGVycyB3ZSBjYW4KcXVpcmsgaXQgaW4g dGhlIGRyaXZlciBhbmQgbGV0IHRoZSBhY2Nlc3MgaGFwcGVuIGJlY2F1c2UgaXQgZG9lcyBub3QK bWVzcyBvdXIgc3RhdGUuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9w Lm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVs LWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421AbdF3K5m (ORCPT ); Fri, 30 Jun 2017 06:57:42 -0400 Received: from mga07.intel.com ([134.134.136.100]:54119 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690AbdF3K44 (ORCPT ); Fri, 30 Jun 2017 06:56:56 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,286,1496127600"; d="scan'208";a="280584836" Date: Fri, 30 Jun 2017 13:56:50 +0300 From: Mika Westerberg To: Lyude Cc: intel-gfx@lists.freedesktop.org, "Rafael J . Wysocki" , Benjamin Tissoires , Jean Delvare , Wolfram Sang , Jean Delvare , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder Message-ID: <20170630105650.GY629@lahna.fi.intel.com> References: <20170626204009.32607-1-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626204009.32607-1-lyude@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote: > There's quite a number of machines on the market, mainly Lenovo > ThinkPads, that make the horrible mistake in their firmware of reusing > the PCIBAR space reserved for the SMBus for things that are completely > unrelated to the SMBus controller, such as the OpRegion used for i915. > This is very bad and entirely evil, but with Lenovo's historically poor > track record of fixing their firmware, it is extremely unlikely this is > ever going to be properly fixed. > > So, while it would be nice if we could just cut off the SMBus controller > and call it a day this unfortunately breaks RMI4 mode completely for > most of the ThinkPads. Even though this behavior is extremely wrong, for > whatever reason sharing the PCIBAR between the OpRegion and SMBus seems > to be just fine. Regardless however, I think it's safe to assume that > when the BIOS accesses the PCIBAR space of the SMBus controller like > this that it's trying to get to something else that we mapped the SMBus > controller over. > > On my X1 Carbon, this assumption appears to be correct. I've traced down > the firmware accesses to being caused by the firmware mistakenly placing > the SWSCI mailbox for i915 on top of the SMBus host controller region. > And indeed, blacklisting i915 causes the firmware to never attempt to > touch this region. > > So, in order to try to workaround this and not break either SMBus or > i915, we temporarily unmap the PCI device for the SMBus controller, > do the thing that the firmware wanted to do, then remap the device and > report a firmware bug. Are the registers it tries to access separate from SMBus ones? We already have TCO registers placed to this device starting from Skylake so there might be something else as well. Point here is that if the access is not to the SMBus registers we can quirk it in the driver and let the access happen because it does not mess our state.