On Sat, Mar 16, 2013 at 4:11 PM, Greg KH wrote:
> On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
>> Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
>> Port space and MMIO. This memory regions correspond to the device's
>> internal status and control registe
On Wed, Aug 29, 2012 at 10:36 AM, Yinghai Lu wrote:
> On Wed, Aug 29, 2012 at 8:57 AM, Yinghai Lu wrote:
>> also have another version for probe_resource, please check attached version
>> -v8.
>>
>
> sorry, v8 forget removing two lines.
>
> please -v9 instead.
>
> -v8: Linus said: allocation/retu
On Thu, Aug 30, 2012 at 1:16 PM, Toshi Kani wrote:
> Added acpi_lookup_driver(), which looks up an associated driver
> for the notified ACPI device object by walking through the list
> of ACPI drivers.
>
> Signed-off-by: Toshi Kani
> ---
> drivers/acpi/scan.c | 65
> ++
On Mon, Sep 10, 2012 at 7:29 PM, Stephen Rothwell wrote:
> Hi Bjorn,
>
> After merging the pci tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/powernv/pci-ioda.c: In function
> 'pnv_pci_window_alignment':
> arch/powerpc/platforms/powernv/pci
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> There's a typical usage pattern to search a PCI device under a specific
> PCI bus (domian, busno) as below:
> struct pci_bus *pci_bus = pci_find_bus(domain, busno);
> struct pci_dev *pci_dev = pci_get_slot(pci_bus, devfn);
>
> The above code has
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> Trivial cleanups for drivers/pci/remove.c:
> 1) move the comment for pci_stop_and_remove_bus_device() to the right place
> 2) rename __pci_remove_behind_bridge() to pci_remove_behind_bridge()
This seems fine, but I think my pci/bjorn-cleanup-rem
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> According to device model documentation, the way to add/remove device
> object should be symmetric.
>
> /**
> * device_del - delete device from system.
> * @dev: device.
> *
> * This is the first part of the device unregistration
> * sequenc
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> Currently there's no mechanism to protect the global pci_root_buses list
> from dynamic change at runtime. That means, PCI root bridge hotplug
> operations, which dynamically change the pci_root_buses list, may cause
> invalid memory accesses.
>
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> This patch uses PCI bus lock mechanism to avoid race conditions when doing
> PCI device hotplug through eeepc driver.
> It also fixes a PCI device reference
> count leakage issue because acpi_get_pci_dev() holds a reference to the
> device retur
On Tue, Aug 7, 2012 at 10:11 AM, Jiang Liu wrote:
> Now all Archs have been converted to the new PCI bus lock mechanism,
> so clean up unused code.
When you say "all arches," do you really mean "x86 and ia64"? I
assume all the other architectures have similar issues. Or is this
somehow ACPI-spe
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> This patch turns on PCI bus lock mechanism for x86 platforms. It also
> enhances x86 specific PCI implementation to support PCI bus lock.
>
> Signed-off-by: Jiang Liu
> ---
> arch/x86/pci/acpi.c |6 +-
> arch/x86/pci/common.c | 12 +
On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
> There are multiple ways to trigger concurrent PCI hotplug operations for
> a specific PCI bus, but we have no way to serialize those PCI hotplug
> operations yet and thus breaks the PCI hotplug logic. This patch introduces
> a bus lock mechanism
On Tue, Sep 4, 2012 at 5:11 PM, Jiang Wang wrote:
> When CONFIG_PCI_IOV is enabled, the kernel will call sriov_init().
> This function tries to allocate virtual resources even if the
> virtual function of a PCI devive is not enabled by the BIOS.
>
> This sometimes causes following warning messages
On Wed, Sep 12, 2012 at 9:42 AM, Jiang Liu wrote:
> On 09/12/2012 06:57 AM, Bjorn Helgaas wrote:
>> On Tue, Aug 7, 2012 at 10:10 AM, Jiang Liu wrote:
>>> Currently there's no mechanism to protect the global pci_root_buses list
>>> from dynamic change at runt
On Tue, Sep 11, 2012 at 4:04 PM, Sedat Dilek wrote:
> On Tue, Sep 11, 2012 at 8:29 PM, Sedat Dilek wrote:
>> On Tue, Sep 11, 2012 at 8:12 PM, Sedat Dilek wrote:
>>> On Tue, Sep 11, 2012 at 8:31 AM, Stephen Rothwell
>>> wrote:
Hi all,
Changes since 201209010:
New tree:
On Fri, Sep 7, 2012 at 4:42 PM, Bjorn Helgaas wrote:
> On Fri, Sep 7, 2012 at 9:33 AM, Stephen Hemminger
> wrote:
>> This is a trivial patch to make PCI error handler function
>> tables const. Split into pieces so that core changes are first.
>
> I put all four of these
On Thu, Sep 13, 2012 at 12:11 PM, Peter Simons wrote:
> Hi guys,
>
> I've recently updated my machine to Linux kernel 3.5. Ever since then, I
> experience frequent kernel panics in the I/O system. The output from
> dmesg shows the following warning, which earlier version of the kernel
> did not sh
On Thu, Aug 23, 2012 at 3:35 PM, Tejun Heo wrote:
> pci_call_probe() uses work_on_cpu(), which creates and tears down a
> full kthread on each call, to invoke ->probe() on node local CPU for
> allocation affinity.
>
> The same goal can easily be achieved using a work item. This patch
> rewrites p
+cc Greg KH
On Fri, Sep 14, 2012 at 2:44 PM, Thierry Reding
wrote:
> In order to keep pci_fixup_irqs() around after init (e.g. for hotplug),
> mark it __devinit instead of __init. This requires the same change for
> the implementation of the pcibios_update_irq() function on all
> architectures.
>
On Thursday 31 January 2008 05:50:13 pm Linus Torvalds wrote:
> On Thu, 31 Jan 2008, Robert Hancock wrote:
> >
> > I think so. There was one objection that it introduced a dependency on
> > pnpacpi
> > loading after PCI bus enumeration, though.
> >
> > Linus also suggested that pnpacpi could be
On Monday 04 February 2008 11:18:09 am Linus Torvalds wrote:
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> >
> > I think the problem here is that the PCI BAR is bigger and spans the
> > region reported by ACPI:
>
> Ok, then it doesn't help that it's not busy.
On Monday 04 February 2008 02:16:52 pm Linus Torvalds wrote:
>
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> >
> So where in this would you put the
>
> pcibios_init() -> pcibios_resource_survey()
>
> call (it's a subsys_initcall)?
>
> THAT is
On Mon, Oct 1, 2012 at 9:04 PM, Jeff Garzik wrote:
> On 10/01/2012 04:13 AM, Alexander Gordeev wrote:
>>
>> Take advantage of multiple MSIs implementation on x86 - on systems with
>> IRQ remapping AHCI ports not only get assigned separate MSI vectors -
>> but also separate IRQs. As result, interru
with the warning a little longer.
> Signed-off-by: Arnd Bergmann
> Cc: Bjorn Helgaas
> Cc: Lennert Buytenhek
> Cc: Dan Williams
> ---
> arch/arm/mach-iop13xx/pci.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-iop13xx/
he
uncore/memory controller/etc stuff where this is a problem. Those
devices don't have BARs, so
this line is probably the only information about them in dmesg.
> Cc: Bjorn Helgaas
> Cc: Jesse Barnes
>
> Signed-off-by: Nathan Zimmer
> ---
> drivers/pci/probe.c |4 ++-
nk we should change the boot-time order to match that, i.e.,
we should register pci_root.c *before* enumerating ACPI devices.
I realize that this will require changes in the way we bind PCI and ACPI
devices. I pointed that out in a previous response, appended below for
convenience:
On Tue, Oct 2
On Thu, Oct 4, 2012 at 12:36 PM, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 10:47 AM, Bjorn Helgaas wrote:
>> On Wed, Oct 03, 2012 at 04:00:10PM -0700, Yinghai Lu wrote:
>> This is a fundamental difference: at boot-time, all the ACPI devices below
>> the
>> host brid
On Thu, Oct 4, 2012 at 2:14 PM, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 12:44 PM, Bjorn Helgaas wrote:
>>
>> To answer your specific question, yes, I do think drivers that are
>> statically built in probably should be registered before devices are
>> enumerated. T
On Fri, Oct 5, 2012 at 8:54 AM, Nathan Zimmer wrote:
> On 10/05/2012 09:14 AM, Joe Perches wrote:
>>
>> On Fri, 2012-10-05 at 08:55 -0500, Nathan Zimmer wrote:
>>>
>>> On 10/04/2012 11:37 AM, Joe Perches wrote:
On Thu, 2012-10-04 at 11:02 -0500, Nathan Zimmer wrote:
>
> At many o
On Fri, Sep 28, 2012 at 1:40 AM, Zhang Rui wrote:
> From 9a851d177794129a89f720c7122cb39fd163126b Mon Sep 17 00:00:00 2001
> From: Zhang Rui
> Date: Fri, 28 Sep 2012 08:34:05 +0800
> Subject: [RFC PATCH 3/6] ACPI: introduce acpi_get_generic_resources
>
> Introduce acpi_get_generic_resources() to
device is a container device.
>
> Signed-off-by: Tang Chen
> Signed-off-by: Yasuaki Ishimatsu
Looks good to me, but is_container_device() should be of type "bool",
not type "int".
With that change,
Reviewed-by: Bjorn Helgaas
> ---
> drivers/acpi/contai
On Wed, Oct 24, 2012 at 11:14 AM, Toshi Kani wrote:
> On Wed, 2012-10-24 at 14:05 +0800, Tang Chen wrote:
>> + result = container_device_remove(device);
>> + if (result) {
>> + printk(KERN_WARNING "Failed to remove container\n");
>
> Please use pr_warn(
device is a container device.
>
> change log v2 -> v3:
>
> 1. change the is_container_device()'s return value type from int to bool.
No need to keep this level of detail in the permanent git changelogs.
> Signed-off-by: Tang Chen
> Signed-off-by: Yasuaki Ishimatsu
On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett wrote:
> V3 just fixes all the casting issues and incorporates David's change in
> search ordering.
I think there's still a section mismatch issue with these patches, so
I haven't merged them yet.
I rebased my pci/mjg-pci-roms-from-efi branch to
I think there's a latent bug in a DRM error path, at least when used
by i915. In the scenario below, if dev->driver->bus->agp_init()
fails, we call drm_lastclose(). At least in i915_driver_lastclose(),
this dereferences dev->dev_private (at "1" below).
But dev->dev_private isn't initialized unti
[+cc Chris, also a few comments below]
On Fri, Oct 26, 2012 at 12:59 AM, Cyberman Wu wrote:
> After we upgrade to MDE 4.1.0 from Tilera, we encounter a problem that
> only on HighPoint 2680 card works, I've
> tried to fix it, but since most time I'm working in user space, I'm
> not sure my fix is
On Thu, Oct 18, 2012 at 2:50 PM, Yinghai Lu wrote:
> From: Jiang Liu
>
> The code in pci_root_hp.c depends on function acpi_is_root_bridge()
> to check whether an ACPI object is a PCI host bridge or not.
> If an ACPI device hasn't been created for the ACPI object yet,
> function acpi_is_root_brid
On Fri, Oct 26, 2012 at 3:01 AM, Cyberman Wu wrote:
> We're not using 3.6.x, we're using is from MDE-4.1.0 from Tilera and
> it patch 3.0.38.
That's fine, but you sent the email to the linux-pci and linux-kernel
lists, and on those lists, we're only concerned with the upstream
Linux kernels, e.g.
On Friday 01 February 2008 11:08:23 am Siddha, Suresh B wrote:
> On Fri, Feb 01, 2008 at 01:17:14PM +0100, Andi Kleen wrote:
> > "Jike Song" <[EMAIL PROTECTED]> writes:
> >
> > > On 2/1/08, Rijndael Cosque <[EMAIL PROTECTED]> wrote:
> > >> Hi all,
> > >>
> > >> I found the x2APIC spec via
> > >>
On Tuesday 05 February 2008 01:12:46 pm Bjorn Helgaas wrote:
> On Tuesday 05 February 2008 11:15:12 am Linus Torvalds wrote:
> > No, you don't need any quirks: you just do an "insert_resource()" and
> > ignore the error return. If the (bogus) PnP resource clashes wi
On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> >
> > Sorry for the delay. I did work on this, but I don't see how this
> > can work. pcibios_init() marks its reservations as not busy, so the
> >
On Thursday 14 February 2008 01:26:59 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
>
> > On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
> > >
> > > It *shouldn't* fail.
> > >
> > > Things should
On Thursday 14 February 2008 02:37:15 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> >
> > That means the PNP system driver has to be registered after the PCI
> > driver.
>
> After the PCI *subsystem*
>
> Here's the actual pr
On Thursday 14 February 2008 04:14:45 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Linus Torvalds wrote:
> >
> > It should insert the resource to the root resource (or a bridge resource),
> > or not at all. If somebody else has already inserted a real device
> > resource, we already know a
On Wed, Oct 24, 2012 at 7:36 PM, Huang Ying wrote:
> In
>
> https://bugzilla.kernel.org/show_bug.cgi?id=48981
>
> Peter reported that /proc/bus/pci/??/??.? does not works for 3.6.
> This is This is because the device configuration space registers will
> be not accessible if the corresponding par
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying wrote:
> If a PCI device and its parents are put into D3cold, unbinding the
> device will trigger deadlock as follow:
>
> - driver_unbind
> - device_release_driver
> - device_lock(dev) <--- previous lock here
> - __dev
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying wrote:
> Some actions during shutdown need device to be in D0 state, such as
> MSI shutdown etc, so resume device before shutdown.
Is there a problem report or bugzilla for this issue? What are the
symptoms by which a user could figure out that he nee
On Fri, Nov 2, 2012 at 11:05 PM, Huang Ying wrote:
> On Fri, 2012-11-02 at 10:52 -0600, Bjorn Helgaas wrote:
>> On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying wrote:
>> > Some actions during shutdown need device to be in D0 state, such as
>> > MSI shutdown etc, so re
On Fri, Nov 2, 2012 at 11:06 PM, Huang Ying wrote:
> On Fri, 2012-11-02 at 10:50 -0600, Bjorn Helgaas wrote:
>> On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying wrote:
>> > If a PCI device and its parents are put into D3cold, unbinding the
>> > device will
On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
wrote:
> ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
> configure the SPI slave devices behind the SPI controller. This patch adds
> support for this to the SPI core.
>
> In addition we bind ACPI nodes to SPI devices. This
On Mon, Nov 5, 2012 at 3:31 AM, Rafael J. Wysocki wrote:
> On Saturday, November 03, 2012 09:59:28 PM Rafael J. Wysocki wrote:
>> On Saturday, November 03, 2012 10:13:10 PM Mika Westerberg wrote:
>> > On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
>> >
On Sat, Nov 3, 2012 at 2:39 PM, Rafael J. Wysocki wrote:
> On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
>> On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
>> wrote:
>> > ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
>
On Mon, Nov 5, 2012 at 10:12 AM, Mika Westerberg
wrote:
> On Mon, Nov 05, 2012 at 04:19:20PM +0100, Jean Delvare wrote:
>> On Mon, 5 Nov 2012 16:53:15 +0200, Mika Westerberg wrote:
>> > On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
>> > >
>> > > In the ACPI namespace we have d
On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu wrote:
> Modern high-end servers may support advanced RAS features, such as
> system device dynamic reconfiguration. On x86 and IA64 platforms,
> system device means processor(CPU), memory device, PCI host bridge
> and even computer node.
>
> The ACPI spe
On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu wrote:
> An ACPI hotplug slot is an abstraction of receptacles, where a group of
> system devices could be connected to. This patch implements the skeleton
> of the ACPI system device hotplug slot enumerator. On loading, it scans
> the whole ACPI namespac
On Fri, Nov 2, 2012 at 2:25 PM, Rafael J. Wysocki wrote:
> On Friday, November 02, 2012 10:38:43 AM Bjorn Helgaas wrote:
>> On Wed, Oct 24, 2012 at 7:36 PM, Huang Ying wrote:
>> > In
>> >
>> > https://bugzilla.kernel.org/show_bug.cgi?id=48981
>>
On Sat, Nov 3, 2012 at 9:38 PM, Huang Ying wrote:
> On Sat, 2012-11-03 at 11:22 -0600, Bjorn Helgaas wrote:
>> On Fri, Nov 2, 2012 at 11:06 PM, Huang Ying wrote:
>> > On Fri, 2012-11-02 at 10:50 -0600, Bjorn Helgaas wrote:
>> >> On Wed, Oct 24, 2012 at 12:54 AM, H
On Fri, Oct 26, 2012 at 5:18 AM, Rafael J. Wysocki wrote:
> On Friday, October 26, 2012 01:07:51 PM Huang Ying wrote:
>> There are comments on why PME poll support is necessary for PCI
>> devices, but not for PCIe devices. That may lead to misunderstanding
>> that PME poll is only necessary for P
On Sun, Oct 28, 2012 at 2:05 AM, Joe Perches wrote:
> dev_ calls take less code than dev_printk(KERN_
> and reducing object size is good.
> Coalesce formats for easier grep.
>
> Signed-off-by: Joe Perches
I applied this to my pci/misc branch as v3.8 material. Thanks!
> ---
> drivers/pci/irq.c
On Tue, Sep 18, 2012 at 12:51 PM, Joe Perches wrote:
> Get the compiler to verify the argument type of struct pci_dev *.
>
> Signed-off-by: Joe Perches
I applied this to my pci/misc branch as v3.8 material. Thanks!
> ---
>
> Another possible improvement is to range check index.
>
> include/li
On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> This patch introduces acpi_pr_(), where is a kernel
> message level such as err/warn/info, to support improved logging
> messages for ACPI, esp. in hotplug operations. acpi_pr_()
> appends "ACPI" prefix and ACPI object path to the messages. T
On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> Updated CPU hotplug log messages with acpi_pr_(),
> dev_() and pr_(). Some messages are also
> changed for clarity.
>
> Signed-off-by: Toshi Kani
> Tested-by: Vijay Mohan Pandarathil
> ---
> drivers/acpi/processor_driver.c | 36 +++
On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> Updated Memory hotplug log messages with acpi_pr_()
> and pr_().
>
> Signed-off-by: Toshi Kani
> ---
> drivers/acpi/acpi_memhotplug.c | 24
> 1 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/driver
On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> Updated Container hotplug log messages with acpi_pr_()
> and pr_().
>
> Signed-off-by: Toshi Kani
> ---
> drivers/acpi/container.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/container.c b/dr
On Thu, Jul 26, 2012 at 02:58:50PM -0600, Toshi Kani wrote:
> On Thu, 2012-07-26 at 13:22 -0600, Bjorn Helgaas wrote:
> > On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> > > This patch introduces acpi_pr_(), where is a kernel
> > > message level such as err/war
On Thu, Jul 26, 2012 at 3:43 PM, Joe Perches wrote:
> On Thu, 2012-07-26 at 15:37 -0600, Bjorn Helgaas wrote:
>> PNP0C01:00: new device for \_SB_.PCI0.ISA_.MBIO
>>
>> I fiddled with this a while ago; it would look something like this:
> []
>> +stat
On Thu, Jul 26, 2012 at 8:39 PM, Toshi Kani wrote:
> On Thu, 2012-07-26 at 13:23 -0600, Bjorn Helgaas wrote:
>> On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
>> > @@ -560,8 +565,7 @@ static int __cpuinit acpi_processor_add(struct
>> > acpi_device *device)
>&
On Sun, Jul 29, 2012 at 6:26 PM, Jon Mason wrote:
> A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
> connecting 2 systems, providing electrical isolation between the two
> subsystems.
> A non-transparent bridge is functionally similar to a transparent bridge
> except
> t
> I was pointed to https://bugzilla.kernel.org/show_bug.cgi?id=43238.
> I tried the modifications to the DSDT that where proposed there and
> voilŕ, the 3c905c started to work :)
I don't know where to go with this. We do have some _PRT quirks in
drivers/acpi/pci_irq.c, but since Windows 7 works f
On Thu, Jul 19, 2012 at 1:19 PM, Lance Ortiz wrote:
> When an AER event occurs not all of the print notifications are at the
> same log level. This can cause an incomplete AER log from the users
> point of view when monitoring the console output.
>
> The completion message in do_recovery() is cur
On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason wrote:
> On Mon, Jul 30, 2012 at 10:50:13AM -0600, Bjorn Helgaas wrote:
>> On Sun, Jul 29, 2012 at 6:26 PM, Jon Mason wrote:
>> > A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
>> > connecting 2 sy
On Tue, Jul 31, 2012 at 10:02 AM, chetan loke wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas wrote:
>> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason wrote:
>>>
>>> I've tried to make it all generic enough that non-Intel NTBs should plug in
>>>
On Thu, Sep 20, 2012 at 7:51 PM, Yinghai Lu wrote:
> On Thu, Sep 20, 2012 at 4:59 PM, Bjorn Helgaas wrote:
>> On Thu, Sep 20, 2012 at 2:38 PM, Yinghai Lu wrote:
>>> in that case, VFs are stopped before PF, so they are not in device
>>> tree anymore.
>>> so
On Wed, Sep 19, 2012 at 12:54 PM, Yinghai Lu wrote:
> when __ARCH_HAS_VGA_DEFAULT_DEVICE is not defined, aka EFIFB is not used,
> for static path, vga_default setting is through vga_arbiter_add_pci_device.
> and later x86 pci_fixup_video, will skip setting again.
> - subsys_initcall(vga_arb_device
On Wed, Aug 22, 2012 at 9:16 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp
> ignore root bridges using PCIe native hotplug) added code that made the
> acpiphp driver completely ignore PCIe root complexes for which the kernel
>
On Sat, Sep 22, 2012 at 8:11 AM, Yinghai Lu wrote:
> On Sat, Sep 22, 2012 at 1:10 AM, Fengguang Wu wrote:
>>
>>> > Please check attached patch that should fix the problem.
>>>
>>> updated more aggressive version. two patches.
>>
>> Yes they work nicely. Thank you very much!
>
> Thanks.
>
> v2 bre
uldn't turn on the MEM or IO
decode bit unless *all* of the corresponding BARs have been set, but
in your case, I think there is only one MEM BAR that is an issue.
Bjorn
commit 9038dd3b3c4c9e4c7ca0118c8df398c4c646ab58
Author: Bjorn Helgaas
Date: Mon Sep 24 17:16:28 2012 -0600
Matthew Garrett
Acked-by: Bjorn Helgaas
I've never directly applied PNP patches; I've always sent them through
Len's ACPI tree (cc'd), so let me know if you want me to do more than
ack this.
> ---
> drivers/pnp/system.c | 30 ++
> 1
On Tue, Sep 25, 2012 at 7:25 AM, Matthew Garrett wrote:
> ACPIPNP devices may have two levels of ID - the HID (a single string
> defining the hardware) and the CIDs (zero or more strings defining
> interfaces compatible with the hardware). If a driver matching a CID is
> bound first, it will be im
On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf wrote:
> Cyberman: it seems like your bias hack is working for you. But, as Bjorn
> says, this sounds like a driver bug. What happens if you just revert your
> changes, but then in mvsas.c change the "if (!res_start || !res_len)" to
> just say "if
On Fri, Oct 26, 2012 at 7:39 PM, Cyberman Wu wrote:
> On Sat, Oct 27, 2012 at 12:28 AM, Bjorn Helgaas wrote:
>> On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf wrote:
>>
>>> Cyberman: it seems like your bias hack is working for you. But, as Bjorn
>>> says, thi
On Tue, Aug 27, 2013 at 10:11 AM, Stephen Warren wrote:
> On 08/27/2013 02:14 AM, Thierry Reding wrote:
>> On Mon, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote:
>>> On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding
>>> wrote:
>>>> On Mon, Aug 19,
the slot before we run _OSC, so pciehp doesn't claim it, even
though _OSC did grant us control over native PCIe hotplug.
> Fix is pretty simple, just defer the scan until after the osc flags have been
> set on the device. Tested by myself and it seems to work well.
>
> Signe
On Fri, Aug 23, 2013 at 3:41 PM, Skidmore, Donald C
wrote:
>> -Original Message-
>> From: Bjorn Helgaas [mailto:bhelg...@google.com]
>> Sent: Friday, August 23, 2013 1:43 PM
>> To: Skidmore, Donald C
>> Cc: e1000-de...@lists.sourceforge.net; linux-...@
On Tue, Aug 27, 2013 at 12:03 PM, Bjorn Helgaas wrote:
>> On 08/27/2013 02:14 AM, Thierry Reding wrote:
>>> If Stephen's fine with it I suppose we could take pci-tegra.c
>>> driver changes through the Tegra tree. But I think it'd be good if
>>> we could
On Tue, Aug 27, 2013 at 5:43 PM, Neil Horman wrote:
> On Tue, Aug 27, 2013 at 03:34:11PM -0600, Bjorn Helgaas wrote:
>> [+cc Stefan]
>>
>> On Mon, Aug 26, 2013 at 9:39 AM, Neil Horman wrote:
>> > Somewhere between 3.9 and 3.10 it seems the order in which pcie and ac
[+cc another email addr for Adam from git logs]
On Wed, Aug 28, 2013 at 9:46 AM, Jiri Kosina wrote:
> On Tue, 27 Aug 2013, Jiri Kosina wrote:
>
>> On Tue, 27 Aug 2013, Jiri Kosina wrote:
>>
>> > Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize a
>> > pci device") makes MSIs
e osc flags have been
> set on the device. Tested by myself and it seems to work well.
>
> Signed-off-by: Neil Horman
> CC: Len Brown
> CC: "Rafael J. Wysocki"
> CC: Bjorn Helgaas
> CC: linux-a...@vger.kernel.org
> CC: linux-...@vger.kernel.org
>
> ---
&g
On Sat, Aug 10, 2013 at 07:48:11PM -0700, Yinghai Lu wrote:
> ioapic hotplug should be built-in like pci root bus hotplug.
>
> Also need to make it depends on X86_IO_APIC.
>
> Signed-off-by: Yinghai Lu
Hi Yinghai,
What's the status of these? It looks like the last three or four
could go via m
On Mon, Sep 23, 2013 at 12:15 AM, Alexey Neyman wrote:
> [Resending due to no response to the original message in a week]
>
> Hi all,
>
> I have a board with a BIOS bug that reports the following I/O port regions in
> _CRS on one of the host bridges:
>
> 0x-0x03af // #0
> 0x03e0-0x0cf7 // #1
>
ly disable irq remapping, theres no need to contiue making Abrt
>> jump
>> at this problem
>>
>> Signed-off-by: Neil Horman
>> CC: Joerg Roedel
>> CC: Bjorn Helgaas
>> CC: Andy Lutomirski
>> CC: Konrad Rzeszutek Wilk
>> CC: Sebastian Andrzej Si
On Wed, Oct 2, 2013 at 2:41 PM, Russell King - ARM Linux
wrote:
> On Mon, Sep 30, 2013 at 10:53:46PM -0700, Bjorn Helgaas wrote:
>> I think the current kobject delayed release is too aggressive,
>
> I don't agree with that statement, but the rest of the sentence I do:
I th
On Sat, Sep 28, 2013 at 01:13:07PM -0700, Yinghai Lu wrote:
> BenH found:
> | 928bea964827d7824b548c1f8e06eccbbc4d0d7d
> | PCI: Delay enabling bridges until they're needed
>
> break PCI on powerpc. The reason is that the PCIe port driver will
> call pci_enable_device() on the bridge, so device en
On Thu, Oct 3, 2013 at 5:35 PM, Yinghai Lu wrote:
> On Thu, Oct 3, 2013 at 3:06 PM, Bjorn Helgaas wrote:
>> On Sat, Sep 28, 2013 at 01:13:07PM -0700, Yinghai Lu wrote:
>>> @@ -1156,8 +1156,14 @@ static void pci_enable_bridge(struct pci
>>>
>>>
On Sat, Sep 28, 2013 at 3:37 PM, Veaceslav Falico wrote:
> On Thu, Sep 26, 2013 at 11:59:51AM +0200, Veaceslav Falico wrote:
>>
>> Currently, we first do kobject_put(&entry->kobj) and the kfree(entry),
>> however kobject_put() doesn't guarantee us that it was the last reference
>> and that the kob
Cc: daniel.pr...@gmail.com
> Cc: thierry.red...@gmail.com
> Cc: linux-kernel@vger.kernel.org
> Cc: ja...@lakedaemon.net
> Cc: x...@kernel.org
FWIW,
Acked-by: Bjorn Helgaas
x86 maintainers, I assume you'll pick this up. Let me know if you
want me to do it.
Bjorn
--
To unsu
On Tue, Sep 10, 2013 at 4:46 AM, Chuansheng Liu
wrote:
>
> Commit(88d2613) removed the pm_runtime_put_sync() from pci_pm_complete()
> to PM core code device_complete().
>
> Here the pci_pm_complete() is doing the same work which can be done in
> device_complete(), so we can remove it directly.
>
>
On Sat, Sep 28, 2013 at 11:55 AM, Myron Stowe wrote:
> Remove unused 'pci_mem_start' variable.
>
> CC: Mikael Starvik
> CC: Jesper Nilsson
> Signed-off-by: Myron Stowe
Applied to pci/misc, thanks!
It'd be nice if we could someday get rid of PCIBIOS_MIN_IO and
PCIBIOS_MIN_MEM, too. They're re
On Sat, Sep 28, 2013 at 11:59 AM, Myron Stowe wrote:
> Remove unused 'pci_mem_start' variable.
>
> CC: David Howells
> CC: Koichi Yasutake
> Signed-off-by: Myron Stowe
Applied to pci/misc with David's ack. Thanks!
Bjorn
> ---
>
> arch/mn10300/include/asm/pci.h |1 -
> arch/mn10300/kern
[-cc unrelated folks, +cc Alex, Christian]
On Mon, Sep 9, 2013 at 7:13 AM, Yijing Wang wrote:
> Use pcie_get_readrq() and pcie_set_readrq() functions to simplify code.
>
> Signed-off-by: Yijing Wang
I believe the following patch is correct, and I'd be happy to merge it
via the PCI tree along wi
101 - 200 of 6731 matches
Mail list logo
