Return-path: Received: from mail-lb0-f177.google.com ([209.85.217.177]:64395 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754048Ab3EQFtE (ORCPT ); Fri, 17 May 2013 01:49:04 -0400 MIME-Version: 1.0 In-Reply-To: <20130516225535.GA27962@google.com> References: <20130510225257.GA10847@google.com> <1725435.3DlCxYF2FV@vostro.rjw.lan> <1368303730.2425.47.camel@x230> <20130516225535.GA27962@google.com> Date: Fri, 17 May 2013 08:49:01 +0300 Message-ID: (sfid-20130517_074928_785008_9A3EC458) Subject: Re: is L1 really disabled in iwlwifi From: Emmanuel Grumbach To: Bjorn Helgaas Cc: Matthew Garrett , "Rafael J. Wysocki" , Stanislaw Gruszka , "linux-pci@vger.kernel.org" , linux-wireless , John Linville , Roman Yepishev , "Guy, Wey-Yi" , Mike Miller , "iss_storagedev@hp.com" , Guo-Fu Tseng , "netdev@vger.kernel.org" , Francois Romieu , "nic_swsd@realtek.com" , "aacraid@adaptec.com" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: > > I couldn't imagine that silently ignoring the request to disable ASPM > would be the right thing, but I spent a long time experimenting with > Windows on qemu, and I think you're right. Windows 7 also seems to > ignore the "PciASPMOptOut" directive when we don't have permission > to manage ASPM. All the gory details are at > https://bugzilla.kernel.org/show_bug.cgi?id=57331 > > The current behavior is definitely confusing. I hate to rename or change > pci_disable_link_state() because it's exported and we'd have to maintain > the old interface for a while anyway. And I don't really want to return > failure to drivers, because I think that would encourage people to fiddle > with the Link Control register directly in the driver, which doesn't seem > like a good idea. > > And you're also right that (as far as I know) there's not an actual > problem with the current behavior other than the confusion it causes. > > So, how about something like the following patch, which just prints a > warning when we can't do what the driver requested? I suppose this may > also be a nuisance, because users will be worried, but they can't actually > *do* anything about it. Maybe it should be dev_info() instead. > Good for me - now I would be notified that something wrong happened.