Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp538217imu; Mon, 26 Nov 2018 14:38:31 -0800 (PST) X-Google-Smtp-Source: AFSGD/UvR6Gj6VHu3Gk/hQ/KdD/Q14eDeQFEPWszZYFgAlRHkBLXCMuImGRAubsg6muIfgsWedTV X-Received: by 2002:a63:1848:: with SMTP id 8mr26384683pgy.81.1543271911490; Mon, 26 Nov 2018 14:38:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543271911; cv=none; d=google.com; s=arc-20160816; b=FDHQoYQL17K2XorYSza7OAh/EHx2+UnvJlkml7jXcUyl3z9qwvWQSUkb0Rvdbk0mcK oeYEAKpI8NxiQpfUy3U7EE6KqNnJsG8mdg5hK7ZYcz95x2Rq5ue8nU7TyWn37XX5i7B9 QK9bqG/30lUhZUIStueQ2IttRQPUVT5W0os2ZEs93rkMrGTyOSN93Nwdy/tHc8af+fK9 cfWpmScdWJsZN2vxTi+7IwpKmjLtvi2cHpYIu5xe/86xO88AF8oyyP6251u89/KiUlDW lDtPM5Is4Bj4xCOxxnv5bnlluHzPu8nqopGXKtSnGuuGHXGUSSAne+rBHhg8APA1ESTs zArg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=zV3VA4JsIFI6WtiJNzVqX9wnDiH0VglQ5aI4pADp8KU=; b=MGdnd34AqwUcsHw4NXA3x6WBYJcAuKCXJNuwa5KN0OdEnPLpF9ZkUZL0bcAbZO4dGZ WQZoQf/jI9y8HcNv+pArLcEQVPEhzIYeDxwFu+OWQFPCmttyCI1PH0QEMz2RIsM/sj9I IQAXrCW0WH7MiFDS9kiWikNG2jKH/2psMYSd1aI62gelGeOrmF/FTcOe7gf63id4sIcm IzVEXL9q/44BLwR50OQW729gIb34HAE7uWAAPb8VlOZ6EA83/VRrfa0k4ThPKksngrqR NN1E3rV59JvbkEHTK46W07fTL0carHW2EsRYBKTdPWyO/TZLyy1v5dD6/DNc8bWKGdmQ vTzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t13si1582708pgm.175.2018.11.26.14.38.16; Mon, 26 Nov 2018 14:38:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727533AbeK0JdD (ORCPT + 99 others); Tue, 27 Nov 2018 04:33:03 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:52079 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726627AbeK0JdD (ORCPT ); Tue, 27 Nov 2018 04:33:03 -0500 Received: from 79.184.254.110.ipv4.supernova.orange.pl (79.184.254.110) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.157) id 035f868819a7f287; Mon, 26 Nov 2018 23:37:22 +0100 From: "Rafael J. Wysocki" To: Bjorn Helgaas Cc: LKML , Linux PCI , Patrick Talbert Subject: Re: [Bug] SD card reader in Acer Aspire S5 broken in 4.20-rc Date: Mon, 26 Nov 2018 23:37:20 +0100 Message-ID: <1675729.7aZxPkvRd8@aspire.rjw.lan> In-Reply-To: <2960808.4YCFhzuD0k@aspire.rjw.lan> References: <2960808.4YCFhzuD0k@aspire.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, November 26, 2018 7:03:58 PM CET Rafael J. Wysocki wrote: > Hi Bjorn, > > The SD card reader in my Acer Aspire S5 doesn't work with 4.20-rc. > > Here's what lspci -v says about it (in a bad kernel): > > 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader > (rev 01) > Subsystem: Acer Incorporated [ALI] Device 0704 > Flags: bus master, fast devsel, latency 0, IRQ 35 > Memory at d9001000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Device Serial Number 00-00-00-01-00-4c-e0-00 > Kernel driver in use: rtsx_pci > Kernel modules: rtsx_pci > > When it doesn't work, it doesn't generate any interrupts on device insertion > and removal and this seems to be reproducible 100% of the time. > > Bisection turned up > > commit de468b755464426c276df2daf1e54bcd64186020 > Merge: b1801bf05964 d6112f8def51 > Author: Bjorn Helgaas > Date: Sat Oct 20 11:45:28 2018 -0500 > > Merge branch 'pci/enumeration' > > - Remove x86 and arm64 node-local allocation for host bridge structures > (Punit Agrawal) > > - Pay attention to device-specific _PXM node values (Jonathan Cameron) > > - Support new Immediate Readiness bit (Felipe Balbi) > > * pci/enumeration: > PCI: Add support for Immediate Readiness > ACPI/PCI: Pay attention to device-specific _PXM node values > x86/PCI: Remove node-local allocation when initialising host controller > arm64: PCI: Remove node-local allocations when initialising host controller > > as the first bad commit, but the "PCI: Add support for Immediate Readiness" > one was tested as "good" (full bisect log is attached). > > I wonder if you have any ideas on what to check? So reverting 17c91487364f (PCI/ASPM: Do not initialize link state when aspm_disabled is set) on top of 4.20-rc4 makes the problem go away. I guess that the device in question needs pcie_aspm_cap_init() to be called for it even though the FADT says "NO_ASPM". Thanks, Rafael