On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote:
> On 02/21/2017 10:45 AM, Juergen Gross wrote:
> > On 21/02/17 16:31, Dan Streetman wrote:
> >> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
> >> wrote:
> >>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
>
odified case.
>
> Cc: bhelg...@google.com
> Cc: linux-...@vger.kernel.org
>
> Signed-off-by: Juergen Gross
Acked-by: Bjorn Helgaas
I assume this will be merged with the rest of the series via some tree
other than mine.
> ---
> drivers/pci/xen-pcifront.c | 6 ++
>
On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC
Hi Jayachandran,
On Fri, Jan 29, 2016 at 02:35:40PM +0530, Jayachandran C wrote:
> Add a simple ACPI based PCI host controller under config option
> ACPI_PCI_HOST_GENERIC. This is done by providing an implementation
> of pci_acpi_scan_root().
>
> The pci_mmcfg_list handling is done by the ACPI co
Hi Ingo,
On Wed, Jul 22, 2015 at 10:38:45AM +0200, Ingo Molnar wrote:
>
> * Bjorn Helgaas wrote:
>
> > > > > Let me know if these are OK or if there are any questions.
> > > > >
> > > > > [0] http://lkml.kernel.org/r/20150625204703
On Tue, Jul 21, 2015 at 10:52:52AM +0200, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
>
> > On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez"
> > >
> > > Ingo,
> > >
> > > Boris is on vacation, he picked up these patches on his bp#tip-mm
On Fri, Jun 19, 2015 at 4:06 PM, Luis R. Rodriguez
wrote:
> I hope to have provided a bit of new information to help you
> reconsider this series to go through you but since you seem to be fine
> for this to go through another tree and since I failed to notice that
> I should also get Arnd's Ack
On Tue, Jun 16, 2015 at 2:16 PM, Luis R. Rodriguez
wrote:
> On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
> wrote:
>> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
>>> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>>>> On Fri,
a different data type). If it is not the case, an incorrect
> pointer (or a piece of data that is not a pointer at all) will be
> passed to ACPI_COMPANION_SET() and that may cause interesting
> breakage to happen going forward.
>
> To work around this problem use the observati
On Tue, Apr 28, 2015 at 05:32:33PM +0800, Yijing Wang wrote:
> From: Arnd Bergmann
>
> Use pci_scan_root_bus() instead of deprecated function
> pci_scan_bus_parented().
>
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Yijing Wang
> CC: Konrad Rzeszutek Wilk
> CC: xen-de...@lists.xenproject.o
On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
> On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> >
> > I tentatively put this (and the rest of the series) on a pci/resource
> > branch. I'm hoping you'll propose some clarificat
c442ed2a ("x86 PAT: fix
performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
and pci_mmap_page_range()")
[bhelgaas: changelog]
Link:
http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcg.
On Wed, May 20, 2015 at 04:08:10PM -0700, Luis R. Rodriguez wrote:
> ...
> --- a/lib/pci_iomap.c
> +++ b/lib/pci_iomap.c
> @@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
> EXPORT_SYMBOL(pci_iomap_range);
>
> /**
> + * pci_iomap_wc_range - create a virtual WC mapping cooki
On Tue, May 19, 2015 at 04:45:30PM -0700, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 4:29 PM, David Airlie wrote:
> >
> >> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas wrote:
> >> > [-cc Venkatesh (bouncing)
> >> >
> >> > On Tue, Ma
rt to remove instances of
> 32-bit timekeeping variables (timeval, time_t and timespec)
> from the kernel.
>
> Signed-off-by: Tina Ruchandani
> Suggested-by: Arnd Bergmann
Acked-by: Bjorn Helgaas
This isn't PCI-related, so I expect Konrad, Boris, or David will merge this
[-cc Venkatesh (bouncing)
On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
wrote:
> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas wrote:
>> Acked-by: Bjorn Helgaas
>
> Thanks! Who's tree should this go through?
I don't know. This is the only patch that went to lin
minus for ioremap(), ioremap_nocache() and
>pci_mmap_page_range()")
>
> [0] https://lkml.org/lkml/2015/4/21/714
>
> Cc: Toshi Kani
> Cc: Andy Lutomirski
> Cc: Suresh Siddha
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Juergen Gross
> Cc: Daniel Vetter
On Thu, Apr 30, 2015 at 07:27:23PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 30, 2015 at 11:26:47AM -0500, Bjorn Helgaas wrote:
> > I don't see users of either pcim_iomap_wc() or pcim_iomap_wc_regions() so
> > far. Did I miss them, or do you just expect them in the n
[+cc linux-pci]
Hi Luis,
On Wed, Apr 29, 2015 at 02:36:09PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Now that we have pci_iomap_wc() add the respective devres helpers.
I guess I'm still confused about the relationship between pci_iomap_wc()
and arch_phys_wc_add().
Do yo
[+cc linux-pci]
Hi Luis,
On Wed, Apr 29, 2015 at 02:36:08PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This allows drivers to take advantage of write-combining
> when possible. Ideally we'd have pci_read_bases() just
> peg an IORESOURCE_WC flag for us
This makes it sound
[-cc Venkatesh, Suresh]
On Thu, Apr 2, 2015 at 3:55 PM, Luis R. Rodriguez wrote:
> On Thu, Apr 02, 2015 at 03:21:22PM -0500, Bjorn Helgaas wrote:
>> On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
>> wrote:
>> > From: "Luis R. Rodriguez"
>> > Thi
On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez wrote:
> ---
> It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT
> and end up with a system with MTRR functionality disabled
> PAT functionality enabled.
This is missing a conjunction or something in "MTRR functionality
disabled PAT functio
On Thu, Apr 2, 2015 at 3:20 PM, Luis R. Rodriguez wrote:
> On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote:
>>
>> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote:
>>
>> > I'll rephrase this to:
>> >
>> > ---
>> > It is
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> Ideally on systems using PAT we can expect a swift
> transition away from MTRR. There can be a few exceptions
> to this, one is where device drivers are known to exist
> on PATs with errata,
This probably m
On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote:
> I'll rephrase this to:
>
> ---
> It is possible to enable CONFIG_MTRR and up with it
> disabled at run time and yet CONFIG_X86_PAT continues
> to kick through with all functionally enabled. This
> can happen for instance on Xen where MTR
On Tue, Mar 24, 2015 at 5:27 PM, Michael D Labriola wrote:
> Bjorn Helgaas wrote on 03/24/2015 01:27:02 PM:
>> Thanks for the report, Michael, and sorry for the inconvenience. I
> think
>> the patch below will fix it, but I don't think it's the right fix either
>
21/0x30
> > [] ? flush_kthread_worker+0xa0/0xa0
> > Code: 03 10 00 00 eb 0e 46 83 c2 04 4b 85 db 75 b9 c6 02 00 31 c0 5b 5e 5f
> > 5d c3 89 c2 8d 40 ff 83 f8 fd 76 06 a1 2c 32 c1 c0 c3 31 c0 <80> 7a 04 0f
> > 0f 44 c2 c3 83 ec 10 83 f8 1d 76 24 89 44 24 0c c7
> > EIP
Hi Luis,
This seems OK to me, but I'm curious about a few things.
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> This allows drivers to take advantage of write-combining
> when possible. Ideally we'd have pci_read_bases() just
> peg an IORESOURCE_WC fl
On Fri, Mar 13, 2015 at 9:01 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Mar 13, 2015 at 08:24:58AM -0500, Bjorn Helgaas wrote:
>> On Thu, Mar 12, 2015 at 9:36 PM, Yijing Wang wrote:
>> >>>>> + pci_add_resource(&resources, &ioport_resource);
&
On Thu, Mar 12, 2015 at 9:36 PM, Yijing Wang wrote:
> + pci_add_resource(&resources, &ioport_resource);
> + pci_add_resource(&resources, &iomem_resource);
> + pci_add_resource(&resources, &busn_resource);
Since I don't want to export busn_resource, you might have to alloca
On Thu, Mar 12, 2015 at 07:46:45PM +0800, Yijing Wang wrote:
> >>struct pci_bus *b;
> >> + LIST_HEAD(resources);
> >>struct pcifront_sd *sd = NULL;
> >>struct pci_bus_entry *bus_entry = NULL;
> >>int err = 0;
> >> @@ -470,17 +472,21 @@ static int pcifront_scan_root(struct pcifront_
g
> CC: linuxppc-...@lists.ozlabs.org
> CC: linux-s...@vger.kernel.org
> CC: linux...@vger.kernel.org
> CC: sparcli...@vger.kernel.org
> CC: xen-de...@lists.xenproject.org
> Signed-off-by: Bjorn Helgaas
> ---
> arch/alpha/kernel/pci.c |5 +++--
> arch/al
zutek Wilk
> CC: xen-de...@lists.xenproject.org
> Signed-off-by: Bjorn Helgaas
> ---
> drivers/pci/xen-pcifront.c | 12 +---
> 1 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index b1ffebe..9e7c28b 100644
&g
On Thu, Feb 26, 2015 at 04:11:57PM +0800, Yijing Wang wrote:
> From: Arnd Bergmann
>
> Use pci_scan_root_bus() instead of deprecated function
> pci_scan_bus_parented().
>
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Yijing Wang
> CC: Konrad Rzeszutek Wilk
> CC: xen-de...@lists.xenproject.o
cache
The PCI core sets resource flags to zero when it can't assign space for the
resource (see reset_resource()). There are also some cases where it sets
the IORESOURCE_UNSET flag, e.g., pci_reassigndev_resource_alignment(),
pci_assign_resource(), etc. So we must check for both cas
On Thu, Jan 29, 2015 at 7:15 AM, Jan Beulich wrote:
On 29.01.15 at 04:54, wrote:
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev
>> *dev, unsigned nr_entries)
>> {
>> resource_size_t phys_addr;
>>
On Wed, Jan 28, 2015 at 3:05 PM, Boris Ostrovsky
wrote:
> On 01/28/2015 01:13 PM, Bjorn Helgaas wrote:
>>
>>
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index fd60806..c3e7dfc 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>&
[+cc Konrad, Boris, David, xen-devel, Alex, kvm]
On Wed, Jan 28, 2015 at 09:52:17AM +0800, Yijing Wang wrote:
> Sometimes, a pci bridge device BAR was not assigned
> properly. After we call pci_bus_assign_resources(), the
> resource of the BAR would be reseted. So if we try to
> enable msix for th
his patch makes it possible to use this function.
>
> CC: Bjorn Helgaas
> Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Bjorn Helgaas
I assume you'll merge this whole series through your tree. Let me
know if you want me to do anything else.
> ---
> drivers/pci/pci.c | 5 ++
[+cc Sebastian, linux-s390, David, Konrad, xen-devel]
On Mon, Oct 27, 2014 at 10:44:35AM +0800, Yijing Wang wrote:
>
> Yijing Wang (3):
> x86/xen: Introduce a global flag to fix the MSI mask bug
> x86/xen: Revert "PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()"
> s390/MSI: Use __msi_ma
On Tue, Nov 11, 2014 at 10:45:38AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 10, 2014 at 05:04:56PM -0700, Bjorn Helgaas wrote:
> > On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> > > Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() a
On Sun, Nov 02, 2014 at 04:12:30PM +0100, SF Markus Elfring wrote:
> The functions pci_dev_put(), pci_pme_wakeup_bus() and put_device() test
> whether their argument is NULL and then return immediately. Thus the test
> around the call is not needed.
>
> This issue was detected by using the Coccine
On Mon, Oct 27, 2014 at 10:44:36AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> fixed MSI mask bug which may cause kernel crash. But the commit
> made MSI code complex. Introduce a new global flag "pci_msi_ignore_mask"
> to ignore MSI/MSI
43 matches
Mail list logo