On Mon, 2013-03-18 at 12:59 -0600, Alex Williamson wrote:
> On Mon, 2013-03-18 at 19:25 +0100, Bjørn Mork wrote:
> > Alex Williamson wrote:
> >
> > >On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote:
> > >> Alex Williamson writes:
> > >>
> > >> > At least for KVM the kernel fix is the additio
On Tue, 2013-03-19 at 10:57 -0600, Myron Stowe wrote:
> On Mon, 2013-03-18 at 12:59 -0600, Alex Williamson wrote:
> > On Mon, 2013-03-18 at 19:25 +0100, Bjørn Mork wrote:
> > > Alex Williamson wrote:
> > >
> > > >On Mon, 2013-03-18 at 18:20 +0100, Bjø
s capabilities - say for UIO drivers or such - then, depending on the
tact taken, we'll need this solution, or something like it, as part of
that overall strategy.
Reference(s):
[1] https://lkml.org/lkml/2013/3/7/242
[2] https://lkml.org/lkml/2013/3/16/168
---
Myron Stowe (2):
PCI,
hat do no meet the device's restrictions, letting a device
specific method intervene and decide how to progress.
Reported-by: Xiangliang Yu
Signed-off-by: Myron Stowe
---
drivers/pci/pci-sysfs.c | 11 +++
drivers/pci/pci.h | 13 +
drivers/pci/quirks.c| 70 +++
With the 0x1b4b vendor ID #define in place, convert hard-coded ID values.
Also, unify the previous SCSI specific use of this vendor ID to the new
macro.
Signed-off-by: Myron Stowe
---
drivers/ata/ahci.c | 10 +-
drivers/scsi/mvsas/mv_init.c |6 +++---
drivers/scsi
From: Xiangliang Yu
Define PCI_VENDOR_ID_MARVELL_EXT macro for 0x1b4b vendor ID
Signed-off-by: Xiangliang Yu
Signed-off-by: Myron Stowe
---
include/linux/pci_ids.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
On Mon, Mar 11, 2013 at 11:23 PM, Andrew Cooks wrote:
> On Fri, Mar 8, 2013 at 12:24 AM, Bjorn Helgaas wrote:
>> On Thu, Mar 7, 2013 at 7:28 AM, wrote:
>>> From: Xiangliang Yu
>>>
>>> Define PCI_VENDOR_MARVELL_ID_EXT macro for 0x1b4b vendor ID
>>
>> "PCI_VENDOR_MARVELL_ID_EXT" is not actually
On Sat, Mar 16, 2013 at 6:13 PM, Myron Stowe wrote:
> On Thu, Mar 14, 2013 at 9:03 AM, Myron Stowe wrote:
>> On Wed, Mar 13, 2013 at 3:40 AM, Xiangliang Yu wrote:
>>> Hi, Bjorn
>>>
>>>> >> > Now, the situation is like this:
>>>> >&g
On Mon, 2013-01-28 at 14:09 -0700, 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 at https://patchwork.kernel.org/patch/1946851/,
> >> there's no value in supporting CONFIG_
xiting
early if a given device in not PCIe, check whether or not the device's
parent has link_state allocated. This enables 'pcie_aspm_exit_link_state'
to properly clean up parent link_state when the last function in a slot
might not be PCIe.
Reported-by: Joe Lawrence
Signed-off-by:
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.
Reference: https://lkml.org/lkml/2012/8/1/253
---
M
Provide an accessor to retrieve the PCI Express device's Capabilities
Register.
Signed-off-by: Myron Stowe
---
include/linux/pci.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 15472d6..78581e1 100644
Use PCI Express Capability access functions to simplify device
Capabilities Register usages.
Signed-off-by: Myron Stowe
---
drivers/pci/access.c|4 ++--
drivers/pci/pcie/portdrv_core.c |2 +-
include/linux/pci.h |2 +-
3 files changed, 4 insertions(+), 4
On Wed, Mar 13, 2013 at 10:16 PM, Robert Hancock wrote:
> On 03/08/2013 09:18 PM, Myron Stowe wrote:
>>
>> On Thu, Mar 7, 2013 at 11:51 PM, Xiangliang Yu
>> wrote:
>>>
>>> Hi, Bjorn
>>>
>>>>>>> Fix system hang issue: if first
On Wed, Mar 13, 2013 at 3:40 AM, Xiangliang Yu wrote:
> Hi, Bjorn
>
>> >> > 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
>> >
ers/pci/pci-sysfs.c::pci_create_attr()).
[3] The kernel's sysfs documentation states: "Attributes should be ASCII
text files..." (./Documentation/filesystems/sysfs.txt). I wonder if
this is just out-of-date infomation as sysfs obviously supports
creating binary files
tional
'resource' entries that correspond to a PCI device's BARs.
Reported-by: Xiangliang Yu
Signed-off-by: Myron Stowe
---
src/udevadm-info.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/udevadm-info.c b/src/udevadm-info.c
index ee9b59f..298a
On Sat, 2013-03-16 at 15:11 -0700, 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
> &
On Thu, Mar 14, 2013 at 9:03 AM, Myron Stowe wrote:
> On Wed, Mar 13, 2013 at 3:40 AM, Xiangliang Yu wrote:
>> Hi, Bjorn
>>
>>> >> > Now, the situation is like this:
>>> >> > I captured the PCIE trace with analyzer and found that 1st BE is 0x
On Sat, 2013-03-16 at 18:03 -0700, Greg KH wrote:
> On Sat, Mar 16, 2013 at 05:50:53PM -0600, Myron Stowe wrote:
> > On Sat, 2013-03-16 at 15:11 -0700, Greg KH wrote:
> > > On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
> > > > Sysfs includes entr
On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
> On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
> wrote:
> > I'm assuming that the device only breaks because udevadm is dumping the
> > full I/O port register space of the device and that if an actual driver
> > was interacting with it thro
On Sun, 2013-03-17 at 07:38 -0600, Alex Williamson wrote:
> On Sat, 2013-03-16 at 22:36 -0700, Greg KH wrote:
> > On Sat, Mar 16, 2013 at 10:11:22PM -0600, Alex Williamson wrote:
> > > On Sat, 2013-03-16 at 18:03 -0700, Greg KH wrote:
> > > > On Sat, Mar 16, 2013 at
On Sun, 2013-03-17 at 15:29 +0100, Kay Sievers wrote:
> On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe wrote:
> > On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
> >> On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
> >> wrote:
> >> > I'm assuming
With the driver now setup for default 32-bit DMA capabilities, remove the
64-bit DMA related dead code.
Signed-off-by: Myron Stowe
---
drivers/scsi/megaraid.c | 45 +
drivers/scsi/megaraid.h |1 -
2 files changed, 9 insertions(+), 37 deletions
With the driver now setup for default 32-bit DMA capabilities, remove the
broken make_local_pdev() implementation and usages.
Signed-off-by: Myron Stowe
---
drivers/scsi/megaraid.c | 98 ---
1 files changed, 16 insertions(+), 82 deletions(-)
diff
ill be 32-bit restricted from
that point onward regardless of whether they are internal commands or
otherwise.
This patch fixes the issue by removing the setup of DMA_BIT_MASK to 64 in
megaraid_probe_one(), leaving the driver setup for default 32-bit DMA
capabilities, as it currently ends up
they are internal
commands or otherwise.
This patch fixes the issue by removing the setup of DMA_BIT_MASK to 64 in
megaraid_probe_one(), leaving the driver with default 32-bit DMA
capabilities, as it currently ends up in such a state anyway after any
internal commands are initiated.
[1] It
Remove unused 'pci_mem_start' variable.
CC: Mikael Starvik
CC: Jesper Nilsson
Signed-off-by: Myron Stowe
---
arch/cris/include/asm/pci.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
index 146da9
Remove unused 'pci_mem_start' variable.
CC: David Howells
CC: Koichi Yasutake
Signed-off-by: Myron Stowe
---
arch/mn10300/include/asm/pci.h |1 -
arch/mn10300/kernel/setup.c|3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/mn10300/include/a
is targeting the 3.9 merge window. I expect that after
3.8-rc1 is released, a -v2 of this series will be required due to Bill
Pemberton's "[PATCH 000/493] remove CONFIG_HOTPLUG as an option" series.
That said, I wanted to go ahead and get this out now in order to solicit
feedback.
R
remove_bridge
-v5: put back support for acpiphp support for slots just on root bus.
-v6: change some functions to *_p2p_* to make it more clean.
-v7: split hot_added change out.
Signed-off-by: Yinghai Lu
Signed-off-by: Myron Stowe
---
drivers/acpi/Makefile |1
drivers/acpi
This patch collapses the initialization call chain of "acpiphp" by calling
acpiphp_glue_init() directly within acphphp_init(), removing the
intervening init_acpi() call.
No functional change.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/acpiphp_core.c | 24 +++--
This patch renames, and changes to external function types, add_bridge()
and remove_bridge() so that they can used directly as the add and remove
interfaces of "acpiphp".
No functional change.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/acpiphp.h |3 +++
drivers/p
This patch collapses the initialization call chain of "acpiphp" by calling
acpi_pci_[un]register_driver() directly within acpiphp_{init,exit}(),
removing the intervening acpiphp_glue_{init,exit}() call.
No functional change.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug
pci_root" driver.
Signed-off-by: Myron Stowe
---
drivers/acpi/pci_root.c|2 ++
drivers/pci/hotplug/acpiphp.h |3 ---
drivers/pci/hotplug/acpiphp_core.c | 23 ---
drivers/pci/hotplug/acpiphp_glue.c |5 -
include/linux/pci-acpi.h
acpiphp_add_bridge() always returns 0. This patch changes the return
type from an 'int' to 'void'.
No functional change.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/acpiphp_glue.c |8 +++-
include/linux/pci-acpi.h |4 ++--
2 files changed
acpi_pci_slot_add+0xe0/0x137
[] acpi_pci_root_start+0x3e/0x59
This patch fixes this latent issue by moving up pci_bus_add_devices() so
that the refcount will be initialized before subsequent references, via
driver additions from the 'acpi_pci_drivers' list, occur.
Signed-off-by: Myro
tly sequencing the addition of such
functionality.
Signed-off-by: Myron Stowe
---
drivers/acpi/Kconfig |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 119d58d..988bb13 100644
--- a/drivers/acpi/Kconfig
+++ b/dr
This patch moves the call of dmi_check_system() from acpi_pci_slot_init()
to acpi_pci_slot_add(). This is in preparation for converting the
"pci_slot" sub-driver to being statically built into the kernel.
No functional change.
Signed-off-by: Myron Stowe
---
drivers/acpi/pci_slo
root" driver.
Signed-off-by: Myron Stowe
---
drivers/acpi/pci_root.c |2 ++
drivers/acpi/pci_slot.c | 27 ++-
include/linux/pci-acpi.h |8
3 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci
'struct
acpi_pci_driver' list based infrastructure. This patch removes it.
Signed-off-by: Myron Stowe
---
drivers/acpi/pci_root.c | 42 +-
include/linux/acpi.h|9 -
2 files changed, 1 insertions(+), 50 deletions(-)
diff --g
acpiphp_glue_init() always returns 0. This patch changes the return
type from an 'int' to 'void'.
No functional change.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/acpiphp.h |2 +-
drivers/pci/hotplug/acpiphp_core.c |4 +++-
drivers/pci/hotplug/a
plicitly sequencing the addition of such
functionality.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/Kconfig |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/hotplug/Kconfig b/drivers/pci/hotplug/Kconfig
index b0e46de..3bf2b82 100644
--- a/drivers/pc
etween the function names and
open parenthesis '('.
No functional change.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/acpiphp.h | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp.h b/drivers/pci/hotplug/acp
urrently implemented, the sub-driver may unregister itself during its
initialization. This patch changes that behavior so that the sub-driver
remains registered and in place.
Signed-off-by: Myron Stowe
---
drivers/pci/hotplug/acpiphp.h |1 -
drivers/pci/hotplug/a
On Thu, 2012-12-06 at 22:48 -0800, Yinghai Lu wrote:
> On Thu, Dec 6, 2012 at 10:25 PM, Myron Stowe wrote:
> > The "ACPI Hot Plug PCI Controller ("acpiphp")" sub-driver may be compiled
> > as a module. Kernel modules are instantiated somewhat randomly - the
&g
' output:
System Information
Manufacturer: Stratus
Product Name: ftServer 6400
[1] https://bugzilla.kernel.org/show_bug.cgi?id=51331
[2] PCI Express specification, r3.0, Section 7.3.1
Reported-by: Fadeeva Marina
Signed-off-by: Myron Stowe
---
arch/x86/pci/common.c |3
All:
We would like to hold a combined ACPI/PM, PCI focused microconference
as part of this year's Linux Plumbers conference but first we need to
show that there is enough interest and material that needs covered.
There is a lot of activity in these subsystems so please respond by
submitting prese
Bump. Any comments?
I think there is a real issue here so I'd like some confirmation on
that at least.
On Fri, Jun 7, 2013 at 10:23 AM, Myron Stowe wrote:
> While the megaraid device itself may be 64-bit DMA capable, 32-bit address
> restricted DMA buffers are apparently required fo
With the driver now setup for default 32-bit DMA capabilities, remove the
64-bit DMA related dead code.
Signed-off-by: Myron Stowe
---
drivers/scsi/megaraid.c | 45 +
drivers/scsi/megaraid.h |1 -
2 files changed, 9 insertions(+), 37 deletions
With the driver now setup for default 32-bit DMA capabilities, remove the
broken make_local_pdev() implementation and usages.
Signed-off-by: Myron Stowe
---
drivers/scsi/megaraid.c | 98 ---
1 files changed, 16 insertions(+), 82 deletions(-)
diff
ill be 32-bit restricted from
that point onward regardless of whether they are internal commands or
otherwise.
This patch fixes the issue by removing the setup of DMA_BIT_MASK to 64 in
megaraid_probe_one(), leaving the driver setup for default 32-bit DMA
capabilities, as it currently ends up
leaving the driver with default 32-bit DMA
capabilities, as it currently ends up in such a state anyway after any
internal commands are initiated.
[1] It seems strange that both mega_buffer/buf_dma_handle and
make_local_pdev() both exist for internal commands but this has been
the cas
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,
>> providi
On Fri, Mar 22, 2013 at 9:55 AM, Robert Hancock wrote:
> On Fri, Mar 22, 2013 at 9:39 AM, Myron Stowe wrote:
>> 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 me
Linux Plumbers has approved an ACPI/PM, PCI microconference. The
overview page is here:
http://wiki.linuxplumbersconf.org/2013:pci_subsystem
We would like to start receiving volunteers for presenting topics of
interest. There is a lot of activity in these subsystems so please
respond by submitti
Well??? I responded yesterday but I still don't see it on the list so
at the expense of some getting a double response I'll try again ...
On Mon, Jul 22, 2013 at 6:27 PM, adam radford wrote:
> On Tue, Jul 9, 2013 at 11:10 PM, James Bottomley
> wrote:
>> On Tue, 2013-07-09 at 15:12 -0700, adam r
Time is passing quickly and there are still a few topic areas that we
would like discussed during the microconference but still do not have
any proposals/knowledgable speakers for.
For the following people I'm specifically picking on: Are you going to
plumbers, would you be willing to cover the fo
Please feel free to forward this invitation on to any others, or
relevant lists, that seem appropriate.
Thanks,
Bjorn Helgaas and Myron Stowe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Thu, Mar 7, 2013 at 11:51 PM, Xiangliang Yu wrote:
> Hi, Bjorn
>
>> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
>> >> > BAR4, system will hang after executing lspci command
>> >>
>> >> This needs more explanation. We've already read the BARs by the time
>> >> header q
On Sat, Mar 9, 2013 at 1:49 PM, Neil Horman wrote:
> On Mon, Mar 04, 2013 at 02:04:19PM -0500, 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 an
On Sat, Mar 9, 2013 at 7:49 AM, Xiangliang Yu wrote:
> Hi, Bjorn
>
>>> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
>>> >> > BAR4, system will hang after executing lspci command
>>> >>
>>> >> This needs more explanation. We've already read the BARs by the
>>> >> time head
On Mon, Mar 11, 2013 at 3:15 AM, Xiangliang Yu wrote:
> Hi, Myron
>
>> >>> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
>> >>> >> > BAR4, system will hang after executing lspci command
>> >
>> > Any question? Thanks!
>>
>> Googling and looking at the PCI IDs data base I se
It's a bit ugly that we have two possible call sites for the quirk: either
inside do_one_fixup_debug() or directly in pci_do_fixups().
This patch restructures pci_do_fixups()'s quirk invocations in the style
of initcall_debug_start() and initcall_debug_report().
Signed-off-by: M
__nv_msi_ht_cap_quirk() acquires a temporary reference via
'pci_get_bus_and_slot()' that is never released.
This patch releases the temporary reference.
Signed-off-by: Myron Stowe
---
drivers/pci/quirks.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git
PCI's quirk types 'pci_fixup_enable', 'pci_fixup_resume',
'pci_fixup_suspend', and 'pci_fixup_resume_early' can not be __init or
__devinit; they must be in normal text because they can be called at any
time.
This patch removes the '__init' s
i/rescan", it is possible to remove a
PCI bus during run time and have it rediscovered which will require the
call of the fixups again in order for the device to function properly.
This patch prepares specific quirk(s) for use with hot-plug events.
Signed-off-by: Myron Stowe
---
arch/mi
i/rescan", it is possible to remove a
PCI bus during run time and have it rediscovered which will require the
call of the fixups again in order for the device to function properly.
This patch prepares specific quirk(s) for use with hot-plug events.
Signed-off-by: Myron Stowe
---
arch/x
i/rescan", it is possible to remove a
PCI bus during run time and have it rediscovered which will require the
call of the fixups again in order for the device to function properly.
This patch prepares specific quirk(s) for use with hot-plug events.
Signed-off-by: Myron Stowe
---
drivers/p
ying final quirks
by:
o removing 'fs_initcall_sync(pci_apply_final_quirks);',
o removing the global variable 'pci_fixup_final_inited' and all
of its usages,
o renaming, and moving, the 'pci_cache_line_size' related code
currently embedded in
i/rescan", it is possible to remove a
PCI bus during run time and have it rediscovered which will require the
call of the fixups again in order for the device to function properly.
This patch prepares specific quirk(s) for use with hot-plug events.
Signed-off-by: Myron Stowe
---
arch/alpha/k
ng, the 'pci_cache_line_size' related code
currently embedded in 'pci_apply_final_quirks()'.
Note: I do not have a cross-compile environment so I have only tested x86.
---
Myron Stowe (8):
PCI: Integrate 'pci_fixup_final' quirks into hot-plug paths
PCI:
On Thu, Jul 12, 2012 at 10:11 AM, Randy Dunlap wrote:
> On 07/11/2012 11:03 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120710:
>>
>>
>> The pci tree lost its conflicts.
>
>
> on x86_64:
>
> drivers/built-in.o: In function `pci_bus_add_device':
> (.text+0x4f62): undefined refere
[+cc Yinghai]
On Wed, 2013-01-09 at 13:44 -0700, Bjorn Helgaas wrote:
> [+cc Myron]
>
> On Wed, Jan 9, 2013 at 1:19 PM, Rafael J. Wysocki wrote:
> > On Thursday, January 10, 2013 12:58:25 AM Jiang Liu wrote:
> >> Hi Rafael,
> >> Thanks for your great efforts to review the patch.
> >>
> >>
D_INTEL, 0x6f60, pci_bdwep_bar);
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_bdwep_bar);
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_bdwep_bar);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, pci_invalid_bar);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
>
Acked-by: Myron Stowe
On Wed, Aug 31, 2016 at 11:12 AM, Prarit Bhargava wrote:
> On 08/31/2016 12:46 PM, Myron Stowe wrote:
>> On Wed, Aug 31, 2016 at 9:50 AM, Bjorn Helgaas wrote:
>>> The Haswell Power Control Unit has a non-PCI register (CONFIG_TDP_NOMINAL)
>>> where BAR 0 is supposed to
Here it is a year later and there has basically been no progress on
this ongoing situation. I still often encounter bugs raised against
the kernel w.r.t. unmet resource allocations - here is the most recent
example, I'll attach the 'dmesg' log from the platform at
https://bugzilla.kernel.org/show_
unctional change intended.
Signed-off-by: Myron Stowe
---
drivers/net/ethernet/mellanox/mlx5/core/main.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 0c123d5..8a4e292
On Thu, 2015-04-09 at 16:44 +0800, l...@kernel.org wrote:
> From: Myron Stowe
>
> 3.4.107-rc1 review patch. If anyone has any objections, please let me know.
No objections, but I think you want 06cf35f903aa ("PCI: Handle
read-only BARs on AMD CS553x devices"
ch
https://lkml.org/lkml/2012/7/12/338 Randy's catch
Reported-by: rdun...@xenotime.net
Signed-off-by: Myron Stowe
---
drivers/pci/bus.c|4 +---
drivers/pci/quirks.c | 20
2 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/bus.c b/dr
On Thu, Jul 12, 2012 at 10:11 AM, Randy Dunlap wrote:
> On 07/11/2012 11:03 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120710:
>>
>>
>> The pci tree lost its conflicts.
>
>
> on x86_64:
>
> drivers/built-in.o: In function `pci_bus_add_device':
> (.text+0x4f62): undefined refere
Based on Bjorn's latest response it looks as if pci_acpi_scan_root()
is only used as a fallback when the platform's BIOS has not put a
proper ACPI SRAT table and/or _PXM method in place. It will be
interesting to see if the 'dmesg' log and 'acpidump' information ends
up proving this out.
Regardle
On Mon, Nov 18, 2013 at 10:57 PM, Adam Lee wrote:
> On Mon, Nov 18, 2013 at 10:38:17AM -0700, Bjorn Helgaas wrote:
>> [+cc Myron, Amos, Thomas, Ben]
>>
>> On Mon, Nov 18, 2013 at 2:40 AM, Adam Lee wrote:
>> > This patch adds the PCI_EXP_FLAGS_SLOT check back before setting
>> > hotplug bridge, wh
atic inline bool pcie_cap_has_rtctl(const struct
> pci_dev *dev)
> {
> int type = pci_pcie_type(dev);
>
> - return pcie_cap_version(dev) > 1 ||
> - type == PCI_EXP_TYPE_ROOT_PORT ||
> + return type == PCI_EXP_TYPE_ROOT_PORT ||
>
> - pcie_caps_reg(dev) & PCI_EXP_FLAGS_SLOT);
> + return (type == PCI_EXP_TYPE_ROOT_PORT ||
> + type == PCI_EXP_TYPE_DOWNSTREAM) &&
> + pcie_caps_reg(dev) & PCI_EXP_FLAGS_SLOT;
> }
>
> static inline bool pcie_cap_has_rtctl(const
Yinghai:
Would you please consider *not* bundling unrelated, or at least
non-dependent, patches together in one series. As a distrobution
subsystem maintainer, this type of bundling really complicates trying
to identify and isolate key material for bringing in. It also makes
trying to identify t
On Sun, Apr 20, 2014 at 1:59 AM, Borislav Petkov wrote:
> Drop Andreas' old email address from CC as it keeps bouncing.
>
> On Sat, Apr 19, 2014 at 03:52:20PM +0200, Borislav Petkov wrote:
>> > -static void __init pci_enable_pci_io_ecs(void)
>> > +static void __init pci_enable_pci_io_ecs(u8 bus, u
On Sat, Apr 19, 2014 at 5:31 AM, Borislav Petkov wrote:
> On Fri, Apr 18, 2014 at 08:53:16PM -0600, Myron Stowe wrote:
>> From: Suravee Suthikulpanit
>>
>> AMD hostbridges gnenerally show up as PCI device 0:18.0. This patch adds
>> logic to automatically probe the
On Sat, Apr 19, 2014 at 7:52 AM, Borislav Petkov wrote:
> On Fri, Apr 18, 2014 at 08:53:23PM -0600, Myron Stowe wrote:
>> From: Suravee Suthikulpanit
>>
>> This patch adds supports for additional MMIO ranges (16 ranges). Also,
>> each MMIO base/limit can now support
On Sun, Apr 20, 2014 at 2:02 AM, Borislav Petkov wrote:
> On Fri, Apr 18, 2014 at 08:53:31PM -0600, Myron Stowe wrote:
>> From: Suravee Suthikulpanit
>>
>> * Refactoring of the early_fill_mp_bus_info function into multiple helper
>> functions since it is getting lo
On Sun, Apr 20, 2014 at 4:21 AM, Borislav Petkov wrote:
> On Fri, Apr 18, 2014 at 08:53:39PM -0600, Myron Stowe wrote:
>> The vast majority of platforms are not supplying ACPI _PXM (proximity)
>> information corresponding to host bridge (PNP0A03/PNP0A08) devices
>> resultin
On Sun, Apr 20, 2014 at 4:54 AM, Borislav Petkov wrote:
> On Fri, Apr 18, 2014 at 08:53:46PM -0600, Myron Stowe wrote:
>> With the amd_bus.c updates to support additional AMD processors (11h, 12h,
>> 14h 15h and 16h) 'quirk_amd_nb_node' seems to be redundant.
On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote:
> On Tue, Apr 29, 2014 at 10:16:57AM -0500, Suravee Suthikulanit wrote:
>> In the new code, the IO ECS was needed to retrieve the
>> AMD_NB_F1_MMIO_BASE_LIMIT_HI_REG (offset 0x180) during the early
>> initialization as part of (2) logic. Howe
On Wed, Apr 30, 2014 at 1:00 AM, Robert Richter wrote:
> On 29.04.14 15:40:28, Myron Stowe wrote:
>> On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote:
>> > So sounds to me like we want to get rid of the whole IO ECS deal
>> > altogether then.
>> >
>&
On Thu, May 8, 2014 at 9:37 AM, Robert Richter wrote:
> On 08.05.14 10:21:07, Suravee Suthikulanit wrote:
>> The reason I put it all these comments here is because it took us a while to
>> discuss what to do with this file going forward. There were some confusions.
>> Therefore, I just want to doc
On Tue, Jun 17, 2014 at 3:07 PM, Bjorn Helgaas wrote:
> On Tue, Jun 17, 2014 at 1:27 PM, Myron Stowe wrote:
>> During PCIe hot-plug initialization - pciehp_probe - data structures
>> related to slot capabilities are set up. As part of this set up, ISRs are
>> put in place
On Tue, Jul 1, 2014 at 1:29 PM, Bjorn Helgaas wrote:
> On Mon, Jun 30, 2014 at 10:49 AM, Myron Stowe wrote:
>> On Tue, Jun 17, 2014 at 3:07 PM, Bjorn Helgaas wrote:
>>> On Tue, Jun 17, 2014 at 1:27 PM, Myron Stowe wrote:
>>>> During PCIe hot-plug initialization -
o Added a warn if we "guess" a hostbridge's node value (patch 4),
o I believe with the additional Family support that
'quirk_amd_nb_node' is now redundant so I added patch 5 which
removes it.
Reference:
https://bugzilla.kernel.org/show_bu
D18F1x[DC,D4,CC,C4] IO-Space Limit,
42301 Rev 3.12 - October 11, 2012.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Myron Stowe
Tested-by: Aravind Gopalakrishnan
---
arch/x86/pci/amd_bus.c | 126 +++-
1 files changed, 103 insertions(+
AT, etc.) and some from amd_bus.c, there's no
reason to believe they will be compatible.
This patch warns when this situation occurs:
pci_root PNP0A08:00: [Firmware Bug]: No _PXM; guessing node number 0
[1] https://bugzilla.kernel.org/show_bug.cgi?id=72051
Signed-off-by: Myron Stowe
1 - 100 of 134 matches
Mail list logo
