On Wednesday 11 July 2007 01:40:07 pm Luca wrote:
> On 7/9/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Monday 09 July 2007 11:30:59 am Luca wrote:
> > > On 7/9/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > > If you turn off
> > > &g
On Wednesday 30 May 2007 10:48:59 pm Andrew Morton wrote:
> On Wed, 30 May 2007 21:36:41 -0700 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
>
> > On 5/30/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > > On 5/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > On Tue, 29 May 2007 18:43:59 -0700 Yingh
On Thursday 31 May 2007 10:32:42 am Yinghai Lu wrote:
> On 5/31/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Wednesday 30 May 2007 10:48:59 pm Andrew Morton wrote:
> > > You could require that the architecture implement some specific function
> > > for m
I noticed a number of minor formatting issues:
- often missing a space before "{", e.g., "struct ioport_res_list{",
"if (foo){", "else{"
- use "} else {" rather than "else" on a new line
- no space between function name and "(", e.g., "dprintk ("
- block comments missing leadi
On Friday 13 July 2007 06:58:12 am Thomas Renninger wrote:
> This patch should:
> a) Identify machines where potentially ACPI interference can happen and
>tell the user which legacy drivers are affected.
> b) Identify drivers/HW where we might need an ACPI driver in future
> c) If it works out
APNP does limit the number of resources a device can use.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm1/drivers/pnp/isapnp/core.c
===
--- work-mm1.orig/drivers/pnp/isapnp/core.c 2005-08-09 10:07:45.0
On Wednesday 18 July 2007 02:21:14 am Thomas Renninger wrote:
> On Tue, 2007-07-17 at 09:49 -0600, Bjorn Helgaas wrote:
> > On Monday 16 July 2007 08:21:07 am Thomas Renninger wrote:
> > > PNP0C02 devices normally have a lot more IO port declarations than
> > > curren
On Wednesday 18 July 2007 11:50:38 am Thomas Renninger wrote:
> On Fri, 2007-07-13 at 10:56 -0600, Bjorn Helgaas wrote:
> > The PNP core does not request resources for devices that are active
> > at boot. Those resources currently don't get requested until a driver
> > c
On Tuesday 15 May 2007 10:17:50 pm Yinghai Lu wrote:
> for early_uart_console, I have some ideas:
> 1. merged that into early_serial_console in
> arch/x86_64/kernel/early_printk.c, and
> move early_printk.c to kernel/, --- make it understand
> earlyprintk=uart,io,0x3f8,9600n8
> earlyprint
On Wednesday 16 May 2007 10:29:11 am Yinghai Lu wrote:
> On 5/16/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Tuesday 15 May 2007 10:17:50 pm Yinghai Lu wrote:
> > > for early_uart_console, I have some ideas:
> > > 1. merged that into early_serial_co
On Wednesday 16 May 2007 11:09:14 am Maciej W. Rozycki wrote:
> On Wed, 16 May 2007, Bjorn Helgaas wrote:
>
> > > for early_uart_console, I have some ideas:
> > > 1. merged that into early_serial_console in
> > > arch/x86_64/kernel/early_printk.c, and
&g
On Thursday 17 May 2007 03:45:36 am Maciej W. Rozycki wrote:
> On Wed, 16 May 2007, Bjorn Helgaas wrote:
> > > Given the generic name of "uart" I am assuming this will work with any
> > > UART driver making use of the serial_core.c core -- am I correct?
> >
y related scripts?
If all else fails, you could try git-bisect to isolate a changeset
that broke it. That's tedious but usually effective.
Bjorn
> On 4/13/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Thursday 15 March 2007 13:06, Andrew Morton wrote:
> > > >
On Sunday 03 June 2007 02:16:05 am Andrey Borzenkov wrote:
> On Sunday 03 June 2007, Andrey Borzenkov wrote:
> > Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
> > Nothing was changed in setup except kernel version.
> >
> > 2.6.21:
> >
> > Detected unconfigured Toshiba lapt
On Tuesday 05 June 2007 05:57:30 am Linus Walleij (LD/EAB) wrote:
> You don't need to alter the defaults for the Toshiba ALi, the
> preconfigure will respect the settings from the commandline,
> e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8.
>
> BUT this value just won't work: we don't
On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
> On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> > Something's wrong with this strategy. The BIOS is telling us that an
> > SMCf010 device is present, active, and responds at io ports 0x100-0x107
> > and 0x2e
On Thursday 07 June 2007 06:23:58 am Linus Walleij (LD/EAB) wrote:
> Björn wrote:
> > Something's wrong with this strategy. The BIOS is telling us
> > that an SMCf010 device is present, active, and responds at io
> > ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens
> > to be on the
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
> On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> > On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
> > > On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> > > > Something's wrong with
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
> I am beginning to doubt whether drier
> works on my system at all (i.e. before PnP change); have to find time to
> test.
In 2.6.21, smsc-ircc2 at least found the device. So we definitely have
a problem because in 2.6.22-rc, we don'
Andrey,
Can you try the following patch? It applies on top of the previous
two patches, and it is enough to make the driver find the device on
my Portege 4000. Unfortunately, I can't tell whether it really works
because I don't have a clue about how to make two IR devices talk
to each other.
Bj
the device, and "irattach irda0 -s && irdadump" shows transmitted and
received packets.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"
I tested this on a Portege 4000. The smsc-ircc2 driver correctly detects
the device, and "irattach irda0 -s && irdadump" shows transmitted and
received packets.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTEC
d. We assign I/O ports originally assigned to the SMCf010 to a
PCMCIA device instead. We enable the SMCf010, configuring it to use
disjoint ports, but _SRS doesn't work correctly, so the device doesn't
work.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/i
Andrew, can you apply the patch below for 2.6.22? It reverts
smsc-ircc2 to the old blind probing behavior. There's a lot of
infrastructure work I need to do before the PNP probe will be
reliable.
Thanks,
Bjorn
On Sunday 01 July 2007 01:08:16 am Andrey Borzenkov wrote:
> Bjorn Helga
On Monday 21 May 2007 04:42:21 am Andi Kleen wrote:
> On Sun, May 20, 2007 at 08:23:32PM -0700, Andrew Morton wrote:
> > I'll queue this up for some testing, but I'd be a bit reluctant to send it
> > into Linus due to my poor understanding of what it actually does. What
> > _is_ an early console,
On Monday 21 May 2007 04:42:21 am Andi Kleen wrote:
> On Sun, May 20, 2007 at 08:23:32PM -0700, Andrew Morton wrote:
> > I'll queue this up for some testing, but I'd be a bit reluctant to send it
> > into Linus due to my poor understanding of what it actually does. What
> > _is_ an early console,
On Monday 21 May 2007 12:56:37 am Yinghai Lu wrote:
> Bjorn,
> I can not find fixmap.h for ia64.hope you can use ioremap instead,
> then we can create one dummy fixmap.h in include/asm-ia64
ia64 ioremap should work early enough, so it doesn't have fixmap.
Seems like in this case, maybe bt_iore
On Monday 21 May 2007 11:36:58 am Yinghai Lu wrote:
> On 5/21/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > earlycon=uart,io,0x3f8,9600n8
> > > earlycon=uart,io,0x3f8,9600n8 console=tty0
> > > earlycon=uart,mmio,0xff5e,115200n8
> >
> >
On Monday 21 May 2007 02:36:16 pm Yinghai Lu wrote:
> On 5/21/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > with console=uart, you need to call early_serial_console_init
> > > explictly in your arch setup_arch to get early console.
> >
> > Can'
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
p
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
> Please try the following patch from Yasunori Goto.
> ...
> --- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
> +++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
> @@ -707,7 +707,7 @@ int move_freep
On Wednesday 14 March 2007 10:13, Mel Gorman wrote:
> Ok. This looks like another case of HOLES_IN_ZONE hilarity with page_zone().
> As I take a new look at the BUG_ON check in move_freepages(), it isn't even
> necessary as move_freepages_block() already checks the zone boundaries. At a
> later da
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
> Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
> Can you
> also apply the following patch and boot with loglevel=8 please? The
> patch moves the check for pfn_valid() before PageBuddy() is called.
B
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
> >
> > Virtual mem_map starts at 0xa0007fffc720
> > Zone PFN ranges:
>
> Total aside, a message should have been printed out here with
> "sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
> could work out PFNs from th
On Thursday 28 September 2006 10:36, Jesse Barnes wrote:
> On Wednesday, September 27, 2006 9:55 pm, [EMAIL PROTECTED]
> wrote:
> > pci_fixup_video turns into generic code because there are many platforms
> > need this fixup for embedded VGA as well as x86. The Video BIOS
> > integrates into Syste
On Friday 02 March 2007 07:03, Jean Delvare wrote:
> ... The primary issue is the concurrent access
> to resources, which cause lots of trouble which are hard to investigate.
> If ACPI reserves the ports, then the SMBus or hardware monitoring
> drivers (or any other conflicting driver) will cleanly
On Friday 13 April 2007 14:07, Pavel Machek wrote:
> > > ... The primary issue is the concurrent access
> > > to resources, which cause lots of trouble which are hard to investigate.
> > > If ACPI reserves the ports, then the SMBus or hardware monitoring
> > > drivers (or any other conflicting driv
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
> On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
> > Of course, there are always BIOS defects. But if we could make a
> > case that a BIOS that doesn't declare the resources used by the AML
> > is defecti
On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
> On 4/15/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > But I missed the details, such as the specific devices in question,
> > which ports they use, how they are described in ACPI, which AML
> > methods use thos
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
> It seems that Asus exposes monitorining data using "ATK0110" (enumerated
> in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D)
> (they have different methods though). Another motherboard with the same
> device may actually
without PNPBIOS or ACPI.
+ * Data taken from include/asm-i386/serial.h.
+ *
+ * (c) Copyright 2006 Hewlett-Packard Development Company, L.P.
+ * Bjorn Helgaas <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Ge
On Wednesday 21 March 2007 10:37, Russell King wrote:
> On Wed, Mar 21, 2007 at 10:35:38AM -0600, Bjorn Helgaas wrote:
> > On Tuesday 20 March 2007 08:32, Bjorn Helgaas wrote:
> > > On Tuesday 20 March 2007 00:46, Keith Owens wrote:
> > > > Booting with 'co
On Tuesday 20 March 2007 08:32, Bjorn Helgaas wrote:
> On Tuesday 20 March 2007 00:46, Keith Owens wrote:
> > Booting with 'console=tty console=ttyS0,9600'. The serial console on
> > ttyS0 (0x3f8, irq 4) is probed twice, once from serial8250_init() and
> > again
On Wednesday 21 March 2007 22:23, Keith Owens wrote:
> The aim of the patch looks sensible, but it will not compile for
> 2.6.21-rc4. 8250_x86.c tests pnp_platform_devices, which does not
> exist. Also the combination of CONFIG_SERIAL_8250_X86=y and
> CONFIG_SERIAL_8250_PNP=m would result in 8250
This series converts i386 and x86_64 legacy serial ports to be platform
devices and prevents probing for them if we have PNP.
This prevents double discovery, where a device was found both by the
legacy probe and by 8250_pnp.
This also prevents the serial driver from claiming IRDA devices (unless
Some HP/Compaq firmware reports via ACPI that the SMCF010 IR device is
enabled, but in fact, it leaves the device partly disabled.
HP nw8240 BIOS 68DTV Ver. F.0F, released 9/15/2005 is one BIOS that has
this problem.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/pnp/qu
If we can discover devices using PNP, we can skip some legacy probes.
This flag ("pnp_platform_devices") indicates that PNPBIOS or PNPACPI
is enabled and should tell us about builtin devices.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/dr
/personal/Jean_Tourrilhes/IrDA/ir260_smsc_pnp.diff
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-04-04 13:45:18.0
-0600
+++ w/drivers/
To determine whether the user specified a module parameter, use some #defines
instead of checking for bare magic numbers.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/d
oke legacy UART
stuff back in. On Debian, "dpkg-reconfigure setserial" with the "kernel"
option does this.
To force the old legacy probe behavior even when we have PNPBIOS or
ACPI, load the new legacy_serial module (or build 8250 static) with
the "legacy_serial.force&quo
On Wednesday 04 April 2007 17:16, Randy Dunlap wrote:
> On Wed, 04 Apr 2007 16:45:40 -0600 Bjorn Helgaas wrote:
> > +static int smsc_nopnp;
> > +module_param_named(nopnp, smsc_nopnp, bool, 0);
> > +MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller sett
On Wednesday 21 March 2007 22:23, Keith Owens wrote:
> The aim of the patch looks sensible, but it will not compile for
> 2.6.21-rc4. 8250_x86.c tests pnp_platform_devices, which does not
> exist. Also the combination of CONFIG_SERIAL_8250_X86=y and
> CONFIG_SERIAL_8250_PNP=m would result in 8250
ned-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: cciss/drivers/block/cciss.c
===
--- cciss.orig/drivers/block/cciss.c2007-04-10 09:46:09.0 -0600
+++ cciss/drivers/block/cciss.c 2007-04-10 10:11:06.0 -0600
@@
We used to warn unless the EFI system table major revision was exactly 1.
But EFI 2.00 firmware is starting to appear, and the 2.00 changes don't
affect anything in Linux.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/include/
On Saturday 31 March 2007 03:12, Petr Vandrovec wrote:
> Hello,
> today I noticed that kernel with 64bit I/O resources reports
> incorrect /proc/iomem due to resource_size_t => int => resource_size_t
> conversion in drivers/pnp/system.c, turning addresses 2-4GB into
> very huge addresses at the t
On Monday 26 March 2007 21:29, Eric W. Biederman wrote:
> "Luck, Tony" <[EMAIL PROTECTED]> writes:
>
> >> What I'm proposing we do is move the irq allocation code out of
> >> pci_enable_device and the irq freeing code out of pci_disable_device
> >> in the future.
> >
> > Sounds rational ... in a w
On Monday 02 April 2007 09:38, Bjorn Helgaas wrote:
> The main reason we wait until pci_enable_device() to allocate an
> IRQ number is that ia64 currently only has about 180 device vectors,
> and there are machines with more PCI slots than that.
Sigh, that didn't make much sense, d
On Monday 02 April 2007 09:37, Christoph Lameter wrote:
> On Sun, 1 Apr 2007, Andi Kleen wrote:
> > Hmm, this means there is at least 2MB worth of struct page on every node?
> > Or do you have overlaps with other memory (I think you have)
> > In that case you have to handle the overlap in change_pa
On Thu, Jun 02, 2016 at 10:41:00AM +0200, Tomasz Nowicki wrote:
> This series bases on pending ACPI PCI support for ARM64:
> https://lkml.org/lkml/2016/5/30/468
>
> Quirk handling relies on an idea of matching MCFG OEM ID and OEM revision
> (the ones from standard header of MCFG table). Linker sec
On Mon, Jun 13, 2016 at 02:05:26PM -0500, Bjorn Helgaas wrote:
> This is a slightly different proposal for the PTM support Jonathan
> proposed here:
>
>
> http://lkml.kernel.org/r/1462956446-27361-2-git-send-email-jonathan.y...@intel.com
>
> I split this into three piec
apping.
> In order to plug IORT into MSI infrastructure we are adding ACPI
> equivalents for finding PCI device domain and its RID translation
> (pci_msi_domain_get_msi_rid and pci_msi_domain_get_msi_rid calls).
>
> Signed-off-by: Tomasz Nowicki
> Acked-by: Marc Zyngier
Acked-by:
On Mon, Jul 18, 2016 at 01:00:33PM +0300, Amir Levy wrote:
> This is version 4 of Thunderbolt(TM) driver for non-Apple hardware.
>
> Changes since v3:
> - Moved new Thunderbolt device IDs from pci_ids.h to icm_nhi.h.
> - Cleanup and added some comments in code.
>
> These patches were pushed to
ridge_buggy' was not
> declared. Should it be static?
>
> Signed-off-by: Ben Dooks
Applied to pci/misc for v4.8, thanks, Ben!
> ---
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>
On Mon, Jul 18, 2016 at 08:32:45AM -0600, Alex Williamson wrote:
> Just like the 3405 quirk added in commit d3d2ab43ddae ("PCI: Add DMA
> alias quirk for Adaptec 3405").
>
> Signed-off-by: Alex Williamson
> Link: https://www.redhat.com/archives/vfio-users/2016-July/msg00046.html
Applied to pci/v
Hi Christoph,
This thread looks like it might be a typo. It doesn't use any of the
new PCI MSI stuff. Looks like the cover letter from the PCI MSI
patches, but the actual patches are from a different series?
On Thu, Jul 21, 2016 at 04:30:20PM +0200, Christoph Hellwig wrote:
> This series adds a
On Tue, Jul 12, 2016 at 06:20:13PM +0900, Christoph Hellwig wrote:
> This series adds a new set of functions that transparently use the right
> type of interrupt (MSI-X, MSI, legacy interrupt line) for a PCI device,
> and if multiple vectors are supported automatically spreads the irq
> routing to
Hi Bharat,
On Fri, Jul 22, 2016 at 09:24:22AM +, Bharat Kumar Gogada wrote:
> Hi,
>
> I'm observing that on x86 BIOS successfully assigns memory if an End point
> requests
> BAR of size 16byte.
>
> But as per Spec:
> The minimum memory address range requested by a BAR is 128 bytes.
Can you
On Fri, Jul 22, 2016 at 10:15:46AM -0500, Bjorn Helgaas wrote:
> Hi Bharat,
>
> On Fri, Jul 22, 2016 at 09:24:22AM +, Bharat Kumar Gogada wrote:
> > Hi,
> >
> > I'm observing that on x86 BIOS successfully assigns memory if an End point
> > requests
&
[+cc perf folks]
On Fri, Jul 22, 2016 at 05:59:51PM +0530, Muni Sekhar wrote:
> Hi All,
>
>
> We have xilinx PCIe endpoint with DMA reference block.
>
>
> The DMA-REF block provides a mechanism to DMA(also supports
> Scatter-Gather DMA) transfer data at the maximum rate between host
> (CPU) me
On Tue, Jun 21, 2016 at 04:53:11PM +0800, Ley Foon Tan wrote:
> This 2 patches fix the issue before and after retrain link.
>
> Ley Foon Tan (2):
> PCI: altera: check link status before retrain link
> PCI: altera: Polling for link up status after retrain the link
>
> drivers/pci/host/pcie-al
-email-paul.gortma...@windriver.com
>
> ---
>
> [vs v1 in [1] above, I tweaked the subjects slightly to match the
> format used by most PCI commits, i.e drop the "driver/" prefix. ]
>
> Cc: Alexandre Courbot
> Cc: Bjorn Helgaas
> Cc: David Daney
> Cc: Gabrie
onditionally set for
> PCI/MSI. When set, this flag forces the programming of the end-point
> as soon as the MSIs are allocated.
>
> A consequence of this is that we have an extra activate in
> irq_startup, but that should be without much consequence.
>
> Reported-by: Bharat
On Mon, Jul 04, 2016 at 01:46:32AM +0900, Yoshinori Sato wrote:
> This is an alternative SH7751 PCI driver.
> Existing driver (arch/sh/drivers/pci/pci-sh7751) uses SH specific interface.
> But this driver uses common PCI interface. It is more modern and generic.
I'd like some details here about wh
On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> compliant with ECAM standard. It uses non-standard configuration space
> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
> (se
On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
> thunder-pem driver stands for being ACPI based PCI host controller.
> However, there is no standard way to describe its PEM-specific register
> ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
> to obtain hardcode
rom: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> > Sent: Wednesday, September 14, 2016 1:30 PM
> > To: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org; Lance Ortiz ; Betty Dall
> > ; Hidetoshi Seto ;
>
Hi Duc,
On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote:
> PCIe controller in X-Gene SoCs is not ECAM compliant: software
> needs to configure additional concontroller register to address
> device at bus:dev:function.
>
> This patch depends on "ECAM quirks handling for ARM64 platforms"
>
On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 17:45, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> >>ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> >>compliant with
[+cc Rafael (maybe already cc'd; I didn't recognize raf...@kernel.org, Duc]
On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 20:09, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
> >>thunder-pem
Hi Ard,
On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote:
> On 20 September 2016 at 14:33, Bjorn Helgaas wrote:
> > [+cc Rafael (maybe already cc'd; I didn't recognize raf...@kernel.org, Duc]
> >
> > On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz No
On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
> On 20 September 2016 at 15:05, Bjorn Helgaas wrote:
> > Hi Ard,
> >
> > On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote:
> >> On 20 September 2016 at 14:33, Bjorn Helgaas wrote:
>
On Fri, Sep 09, 2016 at 09:24:02PM +0200, Tomasz Nowicki wrote:
> Quirk handling relies on an idea of simple static array which contains
> quirk enties. Each entry consists of identification information (IDs from
> standard header of MCFG table) along with custom pci_ecam_ops structure and
> confi
On Wed, Sep 14, 2016 at 03:14:44PM -0600, Tyler Baicar wrote:
> AER severity handling has two issues that cause the AER information to
> be printed incorrectly. The first issue is that the function to calculate
> the AER severity is called twice in the code path to print the AER
> information. The
he PCIe port driver. I meant that Dongdong's
suggestion of adding this:
if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
return;
to your quirk made sense to me.
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent:
On Tue, Sep 20, 2016 at 09:15:14PM -0400, c...@codeaurora.org wrote:
> Hi Bjorn, Thomasz,
>
> On 2016-09-20 15:26, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:02PM +0200, Tomasz Nowicki wrote:
> >>Quirk handling relies on an idea of simple static array which c
On Wed, Sep 21, 2016 at 10:07:36AM -0400, Sinan Kaya wrote:
> On 9/21/2016 9:11 AM, Bjorn Helgaas wrote:
> > On Tue, Sep 20, 2016 at 09:15:14PM -0400, c...@codeaurora.org wrote:
> >> Hi Bjorn, Thomasz,
> >>
>
> >>
> >> Did you delete this be
On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
> > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
>
> [...]
>
> > > None of these platforms can be fixed enti
On Wed, Sep 21, 2016 at 02:10:55PM +, Gabriele Paoloni wrote:
> Hi Bjorn
>
> [...]
>
>
> >
> > If future hardware is completely ECAM-compliant and we don't need any
> > more MCFG quirks, that would be great.
> >
> > But we'll still need to describe that memory-mapped config space
> > somew
On Wed, Sep 21, 2016 at 11:58:22AM -0700, Duc Dang wrote:
> On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas wrote:
> > On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> > The existing x86 practice is to use PNP0C02 devices for this purpose,
> > and I
On Mon, Sep 19, 2016 at 06:07:37PM -0700, Duc Dang wrote:
> On Mon, Sep 19, 2016 at 1:06 PM, Bjorn Helgaas wrote:
> > On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote:
> This patch only adds the ability for X-Gene PCIe controller to be
> probable in ACPI boot mode. All t
On Wed, Sep 21, 2016 at 06:51:55AM +, Po Liu wrote:
> Hi Bjorn,
>
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Wednesday, September 21, 2016 4:47 AM
> > To: Po Liu
> > Cc: Roy Zang; Arnd Bergmann; devi
On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> maybe there is interrupt line for aer pme etc. Search the interrupt
> number in the fdt file. Then
On Mon, Jun 20, 2016 at 02:56:58AM +0200, Niklas Cassel wrote:
>
> On 06/13/2016 03:33 PM, Bjorn Helgaas wrote:
> > On Mon, Jun 13, 2016 at 03:12:13PM +0200, Niklas Cassel wrote:
> >> On 06/10/2016 12:41 AM, Bjorn Helgaas wrote:
> >>> On Mon, May 09, 2016 at 01:4
On Mon, Jun 20, 2016 at 05:45:41PM +0200, Arnd Bergmann wrote:
> Host drivers can be loadable modules, so we might run into this
> build error with the new interface:
>
> ERROR: devm_request_pci_bus_resources [drivers/pci/host/pcie-iproc.ko]
> undefined!
>
> This adds an EXPORT_SYMBOL_GPL() line
On Mon, Jun 20, 2016 at 11:52:13AM +1000, Stephen Rothwell wrote:
> Hi Bjorn,
>
> After merging the pci tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> drivers/pci/host/pci-host-common.c: In function 'gen_pci_init':
> drivers/pci/host/pci-host-common.c:88:10
[+cc Sinan]
On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote:
> You should CC the linux-pci too (done now)
>
> On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote:
> > L.S.
> > up to vanilla kernel-4.6.2 sound was working fine.
> > Switching to kernel-4.7.0-rc3 made sound di
On Mon, Jun 20, 2016 at 8:08 PM, Stephen Rothwell wrote:
> Hi Bjorn,
>
> On Mon, 20 Jun 2016 14:11:36 -0500 Bjorn Helgaas wrote:
>>
>> On Mon, Jun 20, 2016 at 11:52:13AM +1000, Stephen Rothwell wrote:
>> > Hi Bjorn,
>> >
>> > After mer
On Thu, Jun 02, 2016 at 01:46:48PM +0800, Yongji Xie wrote:
> The resource_alignment will releases memory resources allocated
> by firmware so that kernel can reassign new resources later on.
> But this will cause the problem that no resources can be
> allocated by kernel if PCI_PROBE_ONLY was set,
On Thu, Jun 02, 2016 at 01:46:50PM +0800, Yongji Xie wrote:
> When using resource_alignment kernel parameter, the current
> implement reassigns the alignment by changing resources' size
> which can potentially break some drivers. For example, the driver
> uses the size to locate some register whose
On Thu, Jun 02, 2016 at 01:46:49PM +0800, Yongji Xie wrote:
> Now we use the IORESOURCE_STARTALIGN to identify bridge resources
> in __assign_resources_sorted(). That's quite fragile. We can't
> make sure that the PCI devices' resources will not use
> IORESOURCE_STARTALIGN any more.
Can you explai
1001 - 1100 of 6735 matches
Mail list logo
