hether adding a struct pci_driver pointer is a
> better long-term solution.
>
> Greg, Jesse, others, chime in if you have any thoughts.
I thought we had one already... /me digs around. Ah just for AER and
platform error handling.
I do like the idea of a driver hook here; I think there a
On Wed, 29 Feb 2012 03:11:24 +
"Hao, Xudong" wrote:
> For IvyBridge Mobile platform, a system hang may occur if a
> FLR(Function Level Reset) is asserted to internal graphics.
>
> This quirk patch is workaround for the IVB FLR errata issue.
> We are disabling the FLR reset handshake between
gic constants and offsets and document what the FLR
quirk is actually trying to do? IIRC it had something to do with
waiting for the PCH acknowledge for the display portion of the reset...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
No looks fine, just applied to my linux-next branch. Thanks.
Jesse
On Tue, 20 Dec 2011 18:15:42 +0800
"Hao, Xudong" wrote:
> Hi, Jesse
> Do you have any comments for this fix patch?
>
> Thanks,
> -Xudong
>
> > -Original Message-
> > From: Hao, Xudong
> > Sent: Saturday, December 17,
her iomap changes... I didn't
check your latest tree; do you just add another patch on top for the
virtio changes now?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
aising a BUG.
>
> Adaptions of the ipr driver were originally written by Brian King.
Applied this series to linux-next, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
On Thu, 01 Dec 2011 13:04:15 +0100
Jan Kiszka wrote:
> On 2011-11-04 09:45, Jan Kiszka wrote:
> > [ Rebase of v1 over yesterday's linux-next ]
> >
> > This series tries to heal the currently broken locking scheme
> > around PCI config space accesses.
> >
> > We have an interface lock out access
as well...
Given the arch constraints, it's probably not possible to get rid of
the min/max args in favor of a simple offset/len pair like we have for
ioremap. But if we could that would be even better.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
aising a BUG.
>
> Adaptions of the ipr driver were originally written by Brian King.
Sorry to ask you to refresh these after so long, Jan, but can you
respin against my linux-next branch?
My inbox is a poor substitute for patchwork, but that's no excuse for
leaving you hanging so l
he agreed upon way of handling it? If so, can I get some
Reviewed/Acked-bys from people?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
On Tue, 10 May 2011 10:02:11 -0600
Alex Williamson wrote:
> This will allow us to store and load it later.
>
> Signed-off-by: Alex Williamson
> ---
>
> drivers/pci/pci.c | 12 +++-
> include/linux/pci.h | 11 ---
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> d
aming makes it harder
to read than it ought to be.
So we have a pci_cap_saved_state, which implies capability info, and
that's fine.
But pci_cap_saved doesn't communicate much; maybe pci_cap_data or
pci_cap_saved_data would be better?
Thanks,
--
Jesse Barnes, Intel Open Source Technology
p;subdevice,
> &class, &class_mask);
>
Applied to my linux-next branch, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 11 Nov 2010 15:46:55 +0800
Sheng Yang wrote:
> Then we can use it instead of magic number 1.
>
> Reviewed-by: Hidetoshi Seto
> Cc: Matthew Wilcox
> Cc: Jesse Barnes
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Sheng Yang
> ---
> drivers/pci/msi.c
d already via sysfs, so exporting them as GPL
symbols to another module is fine).
So you can add my Acked-by: Jesse Barnes to
the PCI parts, but don't take it as an endorsement of VFIO in
general! :)
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this li
were too weak in
the beginning and allowed userspace bugs (like walking all of sysfs and
reading every file) to scare us into putting weird enable flags and
checks like this in...
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
but I have no idea if it's right. I've applied
> it, and hope Jesse will comment if there's something wrong with it.
Nope, nothing wrong with that afaict.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ace
> process wants to reset the device when the guest is reset,
> to emulate machine reboot as closely as possible.
>
> Signed-off-by: Michael S. Tsirkin
Applied to my linux-next branch, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this lis
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > OK. I think, however, that it's better to avoid probing the function
> > on cleanup path just to figure out whether the file needs to be
> > removed. Can this info be stored in struct
his driver in the future. Possibilities are:
> > > > mmap for device resources, MSI/MSI-X, eventfd (to interface
> > > > with kvm), iommu.
> > >
> > > Thanks for adding the docs! Looks alright to me.
> > >
> > > Thanks,
> > &
> be added to this driver in the future. Possibilities are: mmap for
> > device resources, MSI/MSI-X, eventfd (to interface with kvm), iommu.
>
> Well, I'm not enough of a PCI expert to tell whether your 2.3-test
> works or not (can it have side effects, e.g. trigger an inter
2.6.31 please?
Applied this one to my linux-next branch; hopefully Rusty won't mind
too much. :)
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
These ones can go through David's tree. You can add my:
Acked-by: Jesse Barnes
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo
the PCI tree, right? It looks like it's seen some review from Grant,
David and Matthew but I don't see any Reviewed-by or Acked-by tags in
there... Anyone willing to provide those?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send th
On Sat, 21 Mar 2009 22:05:11 +0800
Yu Zhao wrote:
> On Sat, Mar 21, 2009 at 01:54:09AM +0800, Jesse Barnes wrote:
> > On Fri, 20 Mar 2009 11:25:11 +0800
> > Yu Zhao wrote:
> >
> > > If a device has the SR-IOV capability, initialize it (set the ARI
> > > C
this took about 6 months to get banged into shape,
thanks for staying on it, Yu!
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
TSR in DMA Remapping Reporting Structure
> VT-d: add queue invalidation fault status support
> VT-d: add device IOTLB invalidation support
> VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
> VT-d: support the device IOTLB
Um nevermind, this should go through the IOMMU tree (D
TSR in DMA Remapping Reporting Structure
> VT-d: add queue invalidation fault status support
> VT-d: add device IOTLB invalidation support
> VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
> VT-d: support the device IOTLB
Is this one ready too, Yu? Care to send a respin
*vpd;
> > + struct pci_sriov *sriov;/* SR-IOV capability
> > related */
>
> Should be ifdeffed?
Ok Yu, I'm ready to apply this set, can you send an updated one with
the fixes Matthew mentioned?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
000:00:19.0 > /sys/bus/pci/drivers/pci-stub/bind
>
> Guest uses device
>
> # echo "8086 10f5" > /sys/bus/pci/drivers/pci-stub/remove_id
> # echo :00:19.0 > /sys/bus/pci/drivers_probe
>
> Signed-off-by: Chris Wright
Applied to linux-next, thanks Chris.
-Hartman
Applied to my for-linus tree, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
an have an ack from Jesse for the PCI bits (which is basically
> this patch), I'll take the whole lot through my iommu tree. OK?
Yep, looks fine.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsub
ke the other bits.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, December 17, 2008 11:51 am Greg KH wrote:
> On Wed, Dec 17, 2008 at 11:42:54AM -0800, Jesse Barnes wrote:
> > I really don't want the SR-IOV stuff to sit out another merge cycle
> > though... Arg.
>
> Why, is there some rush to get it in? As there is no
On Wednesday, December 17, 2008 11:05 am Rose, Gregory V wrote:
> -Original Message-
> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
>
> On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
> > As noted in the attached email to the netdev list, we
On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote:
> As noted in the attached email to the netdev list, we (e1000_devel) will
> support the API.
Do you think you'll have those changes ready for 2.6.29? Would merging core
SR-IOV support now make that any more likely?
Thanks,
Jesse
--
elieve, and I think that is not
> an optimal solution. Yu, do you have an opinion on how this would be
> realized?
That's a good point, Yu?
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a
On Wednesday, December 17, 2008 6:15 am Matthew Wilcox wrote:
> On Tue, Dec 16, 2008 at 03:23:53PM -0800, Jesse Barnes wrote:
> > I applied 1-9 to my linux-next branch; and at least patch #10 needs a
> > respin,
>
> I still object to #2. We should have the flexibility to have
d interface sitting around for who knows how many
releases. Is that reasonable? Do you know if any of the corresponding PF/VF
driver bits are ready yet?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm"
#x27;s probe function does take a device reference,
which should get called from driver_register when the driver calls
pci_register_driver... Is that not happening in the virtio case?
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "uns
; Cc: Jean Delvare <[EMAIL PROTECTED]>
> Cc: Milton Miller <[EMAIL PROTECTED]>
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Applied these to my linux-next branch, thanks Chris.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send t
+{
> + /* MSI/MSI-X list */
> + pci_msi_init_pci_dev(dev);
> +
> + /* Power Management */
> + pci_pm_init(dev);
> +
> + /* Vital Product Data */
> + pci_vpd_pci22_init(dev);
> +}
> +
These capabilities changes look good, care to se
On Saturday, September 27, 2008 1:28 am Zhao, Yu wrote:
> Add Alternative Routing-ID Interpretation (ARI) support.
>
> Cc: Jesse Barnes <[EMAIL PROTECTED]>
> Cc: Randy Dunlap <[EMAIL PROTECTED]>
> Cc: Grant Grundler <[EMAIL PROTECTED]>
> Cc: Alex Chiang <
o used to describe a specific pci device in short
> form - * @vend: the vendor name
> - * @dev: the 16 bit PCI Device ID
> + * @vendor: the vendor name
> + * @device: the 16 bit PCI Device ID
> *
> * This macro is used to create a struct pci_device_id that matches a
> * spe
On Saturday, September 13, 2008 5:46 pm Avi Kivity wrote:
> Amit Shah wrote:
> > Sorry for the resends; this one fixes two compile errors introduced by me
> > and a warning.
>
> Applied both, thanks.
You can add my s-o-b to the IOMMU patch if you want Avi, it's fine with me if
you push those part
On Monday, September 22, 2008 2:58 pm Jesse Barnes wrote:
> On Monday, September 22, 2008 12:52 pm Andrew Morton wrote:
> > On Mon, 22 Sep 2008 11:19:47 -0700
> >
> > Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PRO
On Monday, September 22, 2008 12:52 pm Andrew Morton wrote:
> On Mon, 22 Sep 2008 11:19:47 -0700
>
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Mon, 22 Sep 2008 01:38:58 -0700 [EMAIL PROTECTED] wrote:
> > > The mm-of-the-moment snapshot 2008-09-22-01-36 has been uploaded to
> > >
> > >http:
lete mode 100644 drivers/pci/iova.h
> > create mode 100644 include/linux/intel-iommu.h
> > create mode 100644 include/linux/iova.h
>
> Please resend with git's -M option, so we can review the file moves.
I assume the KVM bits depend on this patch. I can take it (after
you'll have to re-send to my personal account ([EMAIL PROTECTED])
since this one got whitespace mangled by Outlook/Exchange.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
49 matches
Mail list logo
