[+cc Dan]
On Mon, Nov 26, 2012 at 2:42 PM, Bruno Prémont
wrote:
> Hi Justin,
>
> On Sat, 24 November 2012 "Justin Piszcz" wrote:
>> Is the following normal on an X9SRL-F board (bios 1.0a)?
>>
>> In the manual it states:
>>
>> Data Direct I/O
>> Select Enabled to enable Intel I/OAT (I/O Accelerati
[Try Dan's current email address; sorry Dan]
On Mon, Nov 26, 2012 at 5:56 PM, Bjorn Helgaas wrote:
> [+cc Dan]
>
> On Mon, Nov 26, 2012 at 2:42 PM, Bruno Prémont
> wrote:
>> Hi Justin,
>>
>> On Sat, 24 November 2012 "Justin Piszcz" wrote:
>>
On Mon, Nov 26, 2012 at 6:00 PM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Monday, November 26, 2012 8:00 PM
> To: Bruno Prémont
> Cc: Justin Piszcz; supp...@supermicro.com; linux-kernel@vger.kerne
t;
>
> v3:
> - Fixed a checkpatch/build issue
>
> v2:
> - Made changes so that all devices in the subtree have the error
> state set correctly.
>
>
> Reviewed-by: Linas Vepstas gmail.com>
> Reviewed-by: Myron Stowe redhat.com>
> Reviewed-by: Bjorn Helga
On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying wrote:
> For unbound PCI devices, what we need is:
>
> - Always in D0 state, because some devices does not work again after
>being put into D3 by the PCI bus.
>
> - In SUSPENDED state if allowed, so that the parent devices can still
>be put int
On Wed, Nov 21, 2012 at 1:39 AM, Daniel J Blueman
wrote:
> Add NumaChip-specific PCI access mechanism via MMCONFIG cycles, but
> preventing access to AMD Northbridges which shouldn't respond.
>
> v2: Use PCI_DEVFN in precomputed constant limit; drop unneeded includes
>
> Signed-off-by: Daniel J Bl
On Tue, Nov 27, 2012 at 6:49 AM, Justin Piszcz wrote:
>
>> It looks like maybe you don't have CONFIG_PCI_MMCONFIG turned on?
>
> ===> FOR I/OAT DMA
> Latest status, it _appears_ its working on the X9SRL-F now, thank you!
>
> 1) Supermicro X9SRL-F (GOOD)
> [0.738510] ioatdma: Intel(R) QuickData
On Tue, Nov 27, 2012 at 7:35 AM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Tuesday, November 27, 2012 8:56 AM
> To: 'Bjorn Helgaas'
> Cc: 'Bruno Prémont'; supp...@supermicro.
On Thu, Nov 29, 2012 at 1:55 AM, Justin Piszcz wrote:
>
>
> -Original Message-
> From: Robert Hancock [mailto:hancock...@gmail.com]
> Sent: Wednesday, November 28, 2012 7:55 PM
> To: Justin Piszcz
> Cc: Bjorn Helgaas; Bruno Prémont; supp...@supermicro.com;
> linu
[+cc Jeff, linux-ide, David, Joerg, iommu]
On Thu, Nov 29, 2012 at 7:39 PM, Robert Hancock wrote:
> On Thu, Nov 29, 2012 at 12:16 PM, Bjorn Helgaas wrote:
>> On Thu, Nov 29, 2012 at 1:55 AM, Justin Piszcz
>> wrote:
>>>
>>>
>>> -Orig
On Sun, Feb 3, 2013 at 1:18 PM, Rafael J. Wysocki wrote:
> On Monday, January 28, 2013 02:09:22 PM Bjorn Helgaas wrote:
>> On Sun, Jan 20, 2013 at 5:01 PM, Rafael J. Wysocki wrote:
>> > On Saturday, January 19, 2013 12:07:42 AM Jiang Liu wrote:
>> >> A
On Mon, Feb 4, 2013 at 3:20 PM, Khalid Aziz wrote:
> On Mon, 2013-02-04 at 15:55 +0400, Konstantin Khlebnikov wrote:
>> Matthew Garrett and Alan Cox said (see LKML link below) that clearing
>> bus-master
>> for all PCI devices may lead to unpredictable consequences, some devices
>> ignores
>> th
On Tue, Feb 5, 2013 at 8:28 AM, Khalid Aziz wrote:
> On Mon, 2013-02-04 at 16:13 -0700, Bjorn Helgaas wrote:
>> On Mon, Feb 4, 2013 at 3:20 PM, Khalid Aziz wrote:
>> > On Mon, 2013-02-04 at 15:55 +0400, Konstantin Khlebnikov wrote:
>> >> Matthew Garrett and Alan
On Tue, Feb 5, 2013 at 4:55 PM, Yinghai Lu wrote:
> On Sat, Feb 2, 2013 at 9:05 PM, Yinghai Lu wrote:
>
>>> Your solution is to introduce for_each_pci_host_bridge() as an
>>> iterator through the known host bridges. There are two scenarios
>>> where we use something like this:
>>>
>>> 1) We want
On Wed, Feb 6, 2013 at 1:53 AM, Mauro Carvalho Chehab
wrote:
> Em Tue, 5 Feb 2013 16:47:10 -0800
> Yinghai Lu escreveu:
>
>> On Tue, Feb 5, 2013 at 4:19 PM, Bjorn Helgaas wrote:
>> >
>> > Maybe. I'd rather not introduce for_each_pci_host_bridge() at all,
On Tue, Feb 5, 2013 at 5:47 PM, Yinghai Lu wrote:
> On Tue, Feb 5, 2013 at 4:19 PM, Bjorn Helgaas wrote:
>>
>> Maybe. I'd rather not introduce for_each_pci_host_bridge() at all, if
>> we can avoid it. Every place it's used is a place we have to audit to
>&g
On Wed, Feb 6, 2013 at 11:59 AM, Yinghai Lu wrote:
> On Wed, Feb 6, 2013 at 9:54 AM, Bjorn Helgaas wrote:
>> I think you're missing the point.
>>
>> Search the tree for uses of "for_each_pci_dev()." Almost every
>> occurrence is a bug because that co
On Wed, Feb 6, 2013 at 3:05 PM, Rafael J. Wysocki wrote:
> On Wednesday, February 06, 2013 01:53:50 PM Yinghai Lu wrote:
>> On Wed, Feb 6, 2013 at 1:43 PM, Rafael J. Wysocki wrote:
>> > On Wednesday, February 06, 2013 01:28:27 PM Yinghai Lu wrote:
>> >> so you still did not answer you want 1 or 2
On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu wrote:
> For physical hot plug should be ok, but for remove/rescan path will
> need us to disable that.
>
> otherwise rescan mmio resource for pci ioapic device will not be
> sized and allocated, aka skiped.
When we scan other PCI devices, we can size m
On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu wrote:
> We need to have ioapic setup before normal pci drivers.
> otherwise other pci driver can not setup irq.
>
> Make ioapic built-in, so can call add/remove during host-bridge add/remove
> the same as the booting path.
>
> Also need to make it depen
On Fri, Feb 8, 2013 at 3:33 PM, Yinghai Lu wrote:
> On Fri, Feb 8, 2013 at 1:14 PM, Bjorn Helgaas wrote:
>> On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu wrote:
>>> For physical hot plug should be ok, but for remove/rescan path will
>>> need us to disable that.
&g
[+cc Rafael, since you mentioned the ACPI tree]
On Mon, Feb 11, 2013 at 12:34 AM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/include/asm/processor.h: Assembler messages:
> arch/sparc/include/
[+cc Rafael]
On Mon, Feb 11, 2013 at 10:08 AM, Daniel J Blueman wrote:
> On 11 February 2013 21:03, Daniel J Blueman wrote:
>> With 3.8-rc7, when unplugging the Thunderbolt ethernet adapter (bus 0a
>> [1]) on a Macbook Pro 10,1, we see the PCIe port correctly released:
>>
>> pciehp :06:03.0:
[+cc linux-acpi, linux-pci]
On Mon, Feb 11, 2013 at 01:06:27PM -0800, Yinghai Lu wrote:
> On Mon, Feb 11, 2013 at 11:57 AM, Yinghai Lu wrote:
> >>
> >> Bjorn, Rafael,
> >>
> >> acpi_pci_irq_add_prt need to be called after pci bridge get scanned,
> >> so we can not call it from pci_acpi_setup, aft
On Mon, Feb 4, 2013 at 1:23 PM, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 03:55:47 PM Konstantin Khlebnikov wrote:
>> This patchset contains some fixes for e1000e diver (broken since v2.6.35)
>> and some related fixes and useful debug for PCI code.
>>
>> All together this fixes my re
On Mon, Feb 11, 2013 at 5:34 PM, Bjorn Helgaas wrote:
> On Mon, Feb 4, 2013 at 1:23 PM, Rafael J. Wysocki wrote:
>> On Monday, February 04, 2013 03:55:47 PM Konstantin Khlebnikov wrote:
>>> This patchset contains some fixes for e1000e diver (broken since v2.6.35)
>>>
ke[4]: *** [drivers/gpu/drm/drm_pci.o] Error 1
This one is my fault. I sent the following patch to Dave to fix it up.
commit ed0708e69f71fab656afc1c891f3c54c9b105664
Author: Bjorn Helgaas
Date: Fri Feb 8 15:18:35 2013 -0700
drm/pci: define drm_pcie_get_speed_cap_mask() only when CONFIG_PCI=
On Mon, Apr 1, 2013 at 6:03 PM, Yinghai Lu wrote:
> On Mon, Apr 1, 2013 at 4:52 PM, Bjorn Helgaas wrote:
>> On Fri, Mar 29, 2013 at 11:04:48AM -0700, Yinghai Lu wrote:
>>> attatched -v3 again
>>>
>>> > Please check attached -v3.
>>
>> It'
On Mon, Apr 1, 2013 at 11:47 AM, Matthew Garrett
wrote:
> On Mon, 2013-04-01 at 11:39 -0600, Bjorn Helgaas wrote:
>
>> Chris still has problems (see
>> https://bugzilla.redhat.com/show_bug.cgi?id=927451), but I don't know
>> whether they are related to these patches o
CI config space no longer available after that.
>>
>> Link: https://lkml.org/lkml/2013/3/12/529
>> Signed-off-by: Konstantin Khlebnikov
>> Reported-and-Tested-by: Vivek Goyal
>> Cc: Bjorn Helgaas
>> Cc: Rafael J. Wysocki
>> ---
>> drivers/pci/p
On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The runtime PM of PCIe ports turns out to be quite fragile, as in
> some cases things work while in some other cases they don't and we
> don't seem to have a good way to determine whether or not they are
> goi
On Thu, Mar 28, 2013 at 3:07 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
>
> It turns out that the _Lxx control methods provided by some BIOSes
> clear the PME Status bit of PCI devices they handle, which means t
[+cc Bob for spec typo question]
On Wed, Mar 27, 2013 at 10:28 PM, Yinghai Lu wrote:
> Found problem on system that firmware that could handle pci aer.
> Firmware get error reporting after pci injecting error, before os boots.
> But after os boots, firmware can not get report anymore, even pci=no
As such, it would be good to
> give them a reminder that their systems are vulnurable to this problem.
>
> Signed-off-by: Neil Horman
> CC: Prarit Bhargava
> CC: Don Zickus
> CC: Don Dutile
> CC: Bjorn Helgaas
> CC: Asit Mallick
> CC: linux-...@vger.kernel.org
>
>
On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
>> On Wed, 2013-04-03 at 17:53 -0600, Bjorn Helgaas wrote:
>> > );
>> > > +
>> > > + if ((revision == 0x13) && irq_re
On Thu, Apr 4, 2013 at 9:39 AM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 08:57:06AM -0600, Bjorn Helgaas wrote:
>> On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman wrote:
>> > On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
>> >> On Wed, 2013-04-03
On Thu, Mar 21, 2013 at 6:51 PM, Robert Hancock wrote:
> On 03/20/2013 10:35 PM, Myron Stowe wrote:
>>
>> Sysfs includes entries to memory regions that back a PCI device's BARs.
>> The pci-sysfs entries backing I/O Port BARs can be accessed by userspace,
>> providing direct access to the device's
On Thu, Mar 7, 2013 at 7:35 PM, Andrew Cooks wrote:
> This patch creates a quirk to allow the Intel IOMMU to be enabled for devices
> that use incorrect tags during DMA. It is similar to the quirk for Ricoh
> devices, but allows mapping multiple functions and mapping of 'ghost'
> functions that do
On Mon, Jan 28, 2013 at 9:34 PM, Huang Ying wrote:
> [PATCH 1/4] PCI/ACPI: Add target state as parameter to
> pci_platform_pm_ops->run_wake
> [PATCH 2/4] PCI: Rename pci_dev->runtime_d3cold to pci_dev->set_d3cold
> [PATCH 3/4] PCI/PM: Set pci_dev->set_d3cold in pci_set_power_state
> [PATCH 4/4] P
On Thu, Apr 4, 2013 at 11:51 AM, Neil Horman wrote:
> Oh, you want the bug report that I'm fixing this against? Sure, I can do
> that.
> I thought you wanted me to include a url in the WARN_TAINT, with which user
> could report occurances of this bug. Yeah, the bug that this is reported in
>
On Thu, Apr 4, 2013 at 2:04 PM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 10:40:07AM -0700, Yinghai Lu wrote:
>> On Thu, Apr 4, 2013 at 10:27 AM, Don Dutile wrote:
>> >> You need to move the quirk to early_quirk to append nointremap to
>> >> avoid extra rebooting.
>> >>
>> > The pci-dev's of a
On Wed, Mar 13, 2013 at 5:28 PM, Yinghai Lu wrote:
> After they are put in add-on resources, they will be safely claimed later.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/quirks.c | 155
> +++---
> 1 file changed, 70 insertions(+), 85 deletion
On Wed, Mar 13, 2013 at 5:27 PM, Yinghai Lu wrote:
> Use resource pointer to get index in pci resources array/list.
>
> -v2: export symbol for acpiphp compiling error, found by
>Steven Newbury
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/probe.c |9 +
> include/linux/pc
On Wed, Mar 13, 2013 at 5:27 PM, Yinghai Lu wrote:
> From: Ram Pai
>
> Currently pci_dev structure holds an array of 17 PCI resources; six base
> BARs, one ROM BAR, four BRIDGE BARs, six sriov BARs. This is wasteful.
> A bridge device just needs the 4 bridge resources. A non-bridge device
> just
On Wed, Mar 13, 2013 at 5:27 PM, Yinghai Lu wrote:
> According to resource pointer find out if the resource is some type resource
> like bridge, sriov, or std.
>
> Signed-off-by: Yinghai Lu
> ---
> include/linux/pci.h | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --
On Fri, Apr 5, 2013 at 2:31 PM, Chris Murphy wrote:
>
> On Apr 2, 2013, at 2:10 PM, Bjorn Helgaas wrote:
>
>> On Mon, Apr 1, 2013 at 11:47 AM, Matthew Garrett
>> wrote:
>>> On Mon, 2013-04-01 at 11:39 -0600, Bjorn Helgaas wrote:
>>>
>&g
On Fri, Apr 5, 2013 at 1:31 PM, Neil Horman wrote:
> A few years back intel published a spec update:
> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>
> For the 5520 and 5500 chipsets which contained an errata (specificially errata
> 5
[+cc linux-kernel]
On Fri, Apr 5, 2013 at 7:31 PM, Bjorn Helgaas wrote:
> Hi Linus,
>
> Here are some fixes for v3.9. They include fixes for an ASPM problem
> that affects pre-1.1 PCIe devices, a kexec problem, the platform ROM
> image problem, a couple hotplug issues related t
On Mon, Jan 28, 2013 at 3:00 PM, Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 1:52 PM, Bjorn Helgaas wrote:
>> On Mon, Jan 28, 2013 at 2:29 PM, Yinghai Lu wrote:
> ...
>>> If bios have messed up slot name or idx, we will get strange 1-1
>>> other crazy name.
>
[+cc Rafael, author of patch you cited]
On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
wrote:
> Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
> ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
>
> Signed-off-by: Konstantin Khlebnikov
> Cc: e
+ "Cannot re-enable PCI device after suspend.\n");
> + return err;
> + }
Reviewed-by: Bjorn Helgaas
Seems right to me, and the other users I looked at (igb, azx,
virtio_pci) call pci_disable_device() in .suspend() and call
pci_enable_de
used a regression on your
e1000e device? If so, I guess we should revert it unless you and Dave
can figure out a better patch that fixes both your e1000e device and
the Optimus issue.
> Signed-off-by: Konstantin Khlebnikov
> Cc: linux-...@vger.kernel.org
> Cc: Bjorn Helgaas
>
l.
>
> Seems like pci_clear_master() must be used here instead of
> pci_disable_device(),
> because it disables Bus Muster unconditionally and doesn't changes enable_cnt.
>
> Signed-off-by: Konstantin Khlebnikov
> Cc: linux-...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc:
[+cc Khalid new email addr]
On Mon, Jan 28, 2013 at 4:40 PM, Bjorn Helgaas wrote:
> On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
> wrote:
>> comment in commit b566a22c23327f18ce941ffad0ca907e50a53d41
>> ("PCI: disable Bus Master on PCI device shutdown"
[+cc Rafael @sisk.pl]
On Mon, Jan 28, 2013 at 4:09 PM, Bjorn Helgaas wrote:
> [+cc Rafael]
>
> On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
> wrote:
>> __e1000_shutdown() calls pci_disable_device() at the end, thus
>> __e1000_resume()
>> should call p
On Mon, Jan 28, 2013 at 7:45 PM, Jiang Liu wrote:
> On 2013-1-29 10:21, Yinghai Lu wrote:
>> On Mon, Jan 28, 2013 at 6:07 PM, Jiang Liu wrote:
>>> Could we use quirk to auto-disable PCIe native hotplug for
>>> problematic platforms?
>>
>> that is some kind of boot command line way?
> We c
On Tue, Jan 29, 2013 at 1:28 PM, Borislav Petkov wrote:
> Hi,
>
> this is rc5 + tip/master from 2 days ago, when resuming I get this fun
> message:
>
> ...
> [15117.684975] Restarting tasks ... done.
> [15117.687201] video LNXVIDEO:00: Restoring backlight state
> [15117.720469] ehci-pci :00:1d
Dimitri and Robin have taken over GRU maintenance.
Linux on Altix is no longer maintained except as part of ia64, and
there's already a separate IA64 maintainer entry.
Signed-off-by: Bjorn Helgaas
---
MAINTAINERS | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --
pci_bus_type, the bus_type exists but the list
does not, so mach_reboot_fixups() trips over a null pointer and panics
again:
mach_reboot_fixups
pci_get_device
..
bus_find_device(&pci_bus_type, ...)
bus->p is NULL
Signed-off-by: Bjorn Helgaas
---
drive
On Tue, Jan 29, 2013 at 4:44 PM, Bjorn Helgaas wrote:
> A bus_type has a list of devices (klist_devices), but the list and the
> subsys_private structure that contains it are not initialized until the
> bus_type is registered with bus_register().
>
> The panic/reboot path has fixu
On Wed, Jan 30, 2013 at 1:09 AM, Greg Kroah-Hartman
wrote:
> On Tue, Jan 29, 2013 at 04:47:13PM -0700, Bjorn Helgaas wrote:
>> On Tue, Jan 29, 2013 at 4:44 PM, Bjorn Helgaas wrote:
>> > A bus_type has a list of devices (klist_devices), but the list and the
>> > su
On Tue, Jan 29, 2013 at 8:42 PM, Borislav Petkov wrote:
> On Tue, Jan 29, 2013 at 02:32:56PM -0700, Bjorn Helgaas wrote:
>> Konstantin has some fixes for an e1000e power management issue related
>> to suspend/resume that he observed on an x220. He didn't see an NMI,
>>
On Fri, Jan 18, 2013 at 4:37 AM, Andrew Murray wrote:
> Continuing from discussion with Thierry (lkml.org/lkml/2013/1/18/107) perhaps
> this will be useful to fold into your patchset.
> ---
> This patch provides pci_bus_fixup_irqs which performs the same
> function as pci_fixup_irqs but only to de
On Fri, Jan 25, 2013 at 5:55 PM, Myron Stowe wrote:
> This series is a minor extension to Jiang Liu's recent efforts - [PATCH v3
> 00/32] provide interfaces to access PCIe capabilities registers - which
> adds an additional PCI Express accessor for obtaining a device's
> Capabilities Register.
>
>
[+cc Rafael]
On Mon, Jan 28, 2013 at 3:00 AM, Paul Bolle wrote:
> In each suspend and resume cycle my laptop prints these messages at
> KERN_INFO level:
> pciehp :00:1c.1:pcie04: pciehp_suspend ENTRY
> pciehp :00:1c.0:pcie04: pciehp_suspend ENTRY
>
> and
> pciehp :00:1c.0:
On Wed, Jan 23, 2013 at 5:29 AM, Yijing Wang wrote:
> Document pci hotplug resource reservation parameters hpiosize
> and hpmemsize into Documentation/kernel-parameters.txt.
> The two parameters can override default hotplug io size(256 bytes)
> and default mem size(2M).
>
> Signed-off-by: Yijing W
d add MPS and MRRS
> explanation suggested by Joe Lawrence and Randy Dunlap.
> v2->v3: Update some semantic problems and the description
> of pcie_bus_safe and pcie_bus_peer2peer suggested
> by Bjorn Helgaas.
> v3->v4: Update pcie_bus_safe description s
On Fri, Feb 1, 2013 at 12:55 PM, Joe Lawrence wrote:
> On Thu, 31 Jan 2013, Myron Stowe wrote:
>> PCI: ASPM exit link state code is skipping devices
>>
>> From: Myron Stowe
>>
>> On PCI bus hotplug removal, 'pcie_aspm_exit_link_state' can potentially
>> skip parent devices that have link_state a
On Fri, Feb 1, 2013 at 9:13 AM, Jiang Liu wrote:
> On 01/29/2013 10:04 AM, Jiang Liu wrote:
>> On 2013-1-29 8:34, Rafael J. Wysocki wrote:
>>> On Monday, January 28, 2013 01:56:33 PM Bjorn Helgaas wrote:
>>>> On Fri, Jan 18, 2013 at 9:07 AM, Jiang Liu wrote:
&g
On Thu, Jan 31, 2013 at 11:35 AM, Paul Bolle wrote:
> In each suspend and resume cycle my laptop prints these messages at
> KERN_INFO level:
> pciehp :00:1c.1:pcie04: pciehp_suspend ENTRY
> pciehp :00:1c.0:pcie04: pciehp_suspend ENTRY
>
> and
> pciehp :00:1c.0:pcie04: pcieh
On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
> early as possible", companion ACPI devices should be created before
> creating correspoding PCI devices, otherwise it will break the ACPI
> PCI binding logic
On Fri, Feb 1, 2013 at 4:06 PM, Bjorn Helgaas wrote:
> On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu wrote:
>> From: Jiang Liu
>>
>> With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as
>> early as possible", companion ACPI devices should be create
On Wed, Jan 30, 2013 at 9:10 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> Commit 668192b678201d2fff27c "PCI: acpiphp: Move host bridge hotplug
> to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp
> to pci_root, but there is still PCI host bridge hotplug related
> dead code left in
On Fri, Dec 28, 2012 at 6:50 AM, Joonsoo Kim wrote:
> During early boot phase, PCI bus subsystem is not yet initialized.
> If panic is occured in early boot phase and panic_timeout is set,
> code flow go into emergency_restart() and hit mach_reboot_fixups(), then
> encounter another panic. When se
On Thu, Dec 27, 2012 at 12:42 AM, Lin Feng wrote:
> There is a potential deadlock situation when we manipulate the pci-sysfs user
> interfaces from different bus hierarchy simultaneously, described as
> following:
>
> path1: sysfs remove device: | path2: sysfs rescan device:
> sysfs_s
[+cc Greg for driver core]
On Fri, Jan 25, 2013 at 10:13:03AM +0900, Joonsoo Kim wrote:
> Hello, Bjorn.
>
> On Thu, Jan 24, 2013 at 10:45:13AM -0700, Bjorn Helgaas wrote:
> > On Fri, Dec 28, 2012 at 6:50 AM, Joonsoo Kim wrote:
> > > During early boot phase, PCI
On Thu, Jan 24, 2013 at 9:14 PM, Greg Kroah-Hartman
wrote:
> On Thu, Jan 24, 2013 at 07:59:01PM -0700, Bjorn Helgaas wrote:
>> [+cc Greg for driver core]
>>
>> On Fri, Jan 25, 2013 at 10:13:03AM +0900, Joonsoo Kim wrote:
>> > Hello, Bjorn.
>> >
>> >
On Fri, Dec 28, 2012 at 1:55 AM, Lin Feng wrote:
>
>
> On 12/28/2012 03:45 PM, Yinghai Lu wrote:
>> On Thu, Dec 27, 2012 at 11:31 PM, Lin Feng wrote:
>>> pci_reassigndev_resource_alignment() potentially calls
>>> pci_specified_resource_alignment() twice, which is redundant.
>>>
>>> pci_is_reassig
[+cc Jon, can you make sure this documentation is accurate?]
On Wed, Jan 23, 2013 at 7:58 PM, Yijing Wang wrote:
> v0->v1: Update MPS parameters as non-arch and add MRRS
> description into pcie_bus_perf parameter suggested
> by Andrew Murray.
> v1->v2: Update some
[+cc Yinghai]
On Fri, Jan 25, 2013 at 3:02 AM, Gu Zheng wrote:
> Hi Bjorn,
> Thanks for your review and comments! Please refer to inlined comments
> below.
>
> On 01/25/2013 07:12 AM, Bjorn Helgaas wrote:
>
>> On Thu, Dec 27, 2012 at 12:42 AM, Lin Feng wrote:
On Fri, Jan 25, 2013 at 11:57 AM, Yinghai Lu wrote:
> On Fri, Jan 25, 2013 at 9:44 AM, Bjorn Helgaas wrote:
>> [+cc Yinghai]
>>
>> On Fri, Jan 25, 2013 at 3:02 AM, Gu Zheng
>
> Hi, Gu,
>
> Can you check if two patches in
>
> http://git.kernel.org/?p=linux
On Tue, Jan 22, 2013 at 3:19 PM, Yinghai Lu wrote:
> On Tue, Jan 22, 2013 at 2:09 PM, Rafael J. Wysocki wrote:
>> On Monday, January 21, 2013 01:20:41 PM Yinghai Lu wrote:
>>> It includes
>>> 1. preparing patches for pci root bus hotadd/hotremove support
>>> 2. move root bus hotadd from acpiphp t
On Wed, Jan 9, 2013 at 1:43 PM, Thierry Reding
wrote:
> This patch series contains an almost complete rewrite of the Tegra PCIe
> driver. The code is moved to the drivers/pci/host directory and turned
> into a proper platform driver, adding MSI and DT support while at it.
> Other PCI host controll
On Fri, Jan 18, 2013 at 9:07 AM, Jiang Liu wrote:
> This is an RFC patchset to address review comments in thread at:
> https://patchwork.kernel.org/patch/1946851/. The patch just pasts
> compilation. If no objection to the new implementation, I will
> go on to modify acpiphp driver and conduct tes
e Kconfig and code to only support building pci_slot as
>> built-in driver.
>>
>> Signed-off-by: Jiang Liu
>
> Acked-by: Rafael J. Wysocki
Acked-by: Bjorn Helgaas
I think we should eventually get rid of acpi_pci_register_driver() and
do this initialization directly
On Mon, Jan 28, 2013 at 2:29 PM, Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 1:09 PM, Bjorn Helgaas wrote:
>> On Sun, Jan 20, 2013 at 5:01 PM, Rafael J. Wysocki wrote:
>>> On Saturday, January 19, 2013 12:07:42 AM Jiang Liu wrote:
>>>> As discussed in thread a
ges (Paul Bolle)
- Make pci_slot built-in only (not a module) (Jiang Liu)
- Remove unused PCI/ACPI bind ops (Jiang Liu)
- Removed used pci_root_bus (Bjorn Helgaas)
Alex Williamson (1):
PCI: Fix PCI Express Capabilit
On Mon, Feb 25, 2013 at 9:37 AM, Shuah Khan wrote:
> On Wed, 2013-02-20 at 18:19 -0700, Bjorn Helgaas wrote:
>> On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
>> > pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
>> > it doesn't have
On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
> pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> (AMD IOMMU, and AER) implement module specific definitions for PCI_BUS()
> and AMD_IOMMU driver
On Tue, Feb 19, 2013 at 9:22 AM, Alan Stern wrote:
> On Tue, 12 Feb 2013, Bjorn Helgaas wrote:
>
>> [+cc linux-pci, Rafael, Alan]
>>
>> [https://bugzilla.kernel.org/show_bug.cgi?id=53551]
>>
>> On Tue, Feb 12, 2013 at 1:13 PM, Artem S. Tashkinov
>> w
On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote:
> Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>>
>>Where are we at with this, Artem? I assume it's still a problem.
>>
>
> Yes, it is, Bjorn.
>
> In order to eliminate this problem I switched bac
[+cc Andy]
On Wed, Feb 20, 2013 at 11:53 PM, Hannes Reinecke wrote:
> On 02/20/2013 05:57 PM, Yinghai Lu wrote:
>>
>> On Tue, Feb 19, 2013 at 11:58 PM, Hannes Reinecke wrote:
>>> Apparently this device is meant to use MSI _only_ so the BIOS developer
>>> didn't feel the need to assign
On Fri, Feb 15, 2013 at 6:37 PM, Yinghai Lu wrote:
> On Fri, Feb 15, 2013 at 5:26 PM, Yinghai Lu wrote:
>> On Fri, Feb 15, 2013 at 4:39 PM, Bjorn Helgaas wrote:
>>> On Thu, Feb 14, 2013 at 5:50 PM, Yinghai Lu wrote:
>>>> On Tue, Feb 12, 2013 at 12:22 PM, Rafa
On Tue, Feb 19, 2013 at 11:34 AM, Jiri Slaby wrote:
> Hi,
>
> so I hit that one:
> + dev_WARN_ONCE(&dev->dev, atomic_read(&dev->enable_cnt) <= 0,
> + "disabling already-disabled device");
>
> during suspend (to ram):
> WARNING: at drivers/pci/pci.c:1397 pci_disable_device
On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke wrote:
> The PCI config space reseves a byte for the interrupt line,
> so irq 255 actually refers to 'not set'.
> However, the 'irq' field for struct pci_dev is an integer,
> so the original meaning is lost, causing the system to
> assign an interru
On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
> pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> (AMD IOMMU, and AER) implement module specific definitions for PCI_BUS()
> and AMD_IOMMU driver
On Tue, Mar 12, 2013 at 3:22 AM, Xiangliang Yu wrote:
> Hi, Myron
>> > Now, the situation is like this:
>> > I captured the PCIE trace with analyzer and found that 1st BE is 0x
>> > when
>> > accessing IO port space. But 9125 spec has some limitation, and the BE
>> > must
>> > be
>> > 0x0100,
On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton wrote:
> Hi Bjorn,
>
>
> On 03/08/13 22:57, Bjorn Helgaas wrote:
>>
>> [+cc Rafael, in case the _OSC thing rings a bell with him]
>>
>> On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton
>> wrote:
>
On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas wrote:
> On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton
> wrote:
>> On 03/08/13 22:57, Bjorn Helgaas wrote:
>>> Thanks. I opened this bug report:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
On Sat, Mar 16, 2013 at 7:50 AM, Joe Perches wrote:
> Instead of converting the 800 or so uses of seq_printf with
> a constant format (without a % substitution) to seq_puts,
> maybe there's another way to slightly speed up these outputs.
>
> Taking a similar approach to commit abd84d60eb
> ("traci
1 - 100 of 6731 matches
Mail list logo
