search for: 510,11

...u/drm/cirrus/cirrus.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c index a9d789a56536..6ac0286810ec 100644 --- a/drivers/gpu/drm/cirrus/cirrus.c +++ b/drivers/gpu/drm/cirrus/cirrus.c @@ -510,11 +510,15 @@ static const struct drm_mode_config_funcs cirrus_mode_config_funcs = { .atomic_commit = drm_atomic_helper_commit, }; -static void cirrus_mode_config_init(struct cirrus_device *cirrus) +static int cirrus_mode_config_init(struct cirrus_device *cirrus) { struct drm_device *dev =...

...u/drm/cirrus/cirrus.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c index a9d789a56536..bd8784ea9d64 100644 --- a/drivers/gpu/drm/cirrus/cirrus.c +++ b/drivers/gpu/drm/cirrus/cirrus.c @@ -510,11 +510,15 @@ static const struct drm_mode_config_funcs cirrus_mode_config_funcs = { .atomic_commit = drm_atomic_helper_commit, }; -static void cirrus_mode_config_init(struct cirrus_device *cirrus) +static int cirrus_mode_config_init(struct cirrus_device *cirrus) { struct drm_device *dev =...

This patch introduces support for two new parameters in libxl: smbios_firmware=<path_to_smbios_structures_file> acpi_firmware=<path_to_acpi_tables_file> The changes are primarily in the domain building code where the firmware files are read and passed to libxc for loading into the new guest. After the domain building call to libxc, the addresses for the loaded blobs are returned and

This patch introduces support for two new parameters in libxl: smbios_firmware=<path_to_smbios_structures_file> acpi_firmware=<path_to_acpi_tables_file> The changes are primarily in the domain building code where the firmware files are read and passed to libxc for loading into the new guest. After the domain building call to libxc, the addresses for the loaded blobs are returned and

...@@ -17,6 +17,11 @@ RCSID("$OpenBSD: sshconnect.c,v 1.126 20 #include <openssl/bn.h> +#ifdef HASH_KNOWN_HOSTS +#include <openssl/sha.h> +#include "uuencode.h" +#endif + #include "ssh.h" #include "xmalloc.h" #include "rsa.h" @@ -505,6 +510,11 @@ check_host_key(char *host, struct sockad char msg[1024]; int len, host_line, ip_line; const char *host_file = NULL, *ip_file = NULL; +#ifdef HASH_KNOWN_HOSTS + unsigned char md[SHA_DIGEST_LENGTH]; + char uu[SHA_DIGEST_LENGTH*2]; +#endif + /* * Force accepting of the...

...uct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file > for WC mapping of resources */ > #ifdef CONFIG_PCI_MSI > - struct list_head msi_list; > + struct msi_irqs *msi; > const struct attribute_group **msi_irq_groups; > #endif > struct pci_vpd *vpd; > @@ -510,11 +508,14 @@ static inline struct pci_dev *pci_upstream_bridge(struct > pci_dev *dev) > static inline bool pci_dev_msi_enabled(struct pci_dev *pci_dev, int type) > { > bool enabled = 0; > + > + if (!pci_dev->msi) > + return false; > > if (type & MSI_TYPE)...

...uct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file > for WC mapping of resources */ > #ifdef CONFIG_PCI_MSI > - struct list_head msi_list; > + struct msi_irqs *msi; > const struct attribute_group **msi_irq_groups; > #endif > struct pci_vpd *vpd; > @@ -510,11 +508,14 @@ static inline struct pci_dev *pci_upstream_bridge(struct > pci_dev *dev) > static inline bool pci_dev_msi_enabled(struct pci_dev *pci_dev, int type) > { > bool enabled = 0; > + > + if (!pci_dev->msi) > + return false; > > if (type & MSI_TYPE)...

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

...i <= IO_BITMAP_LONGS; i++) > + t->io_bitmap[i] = ~0UL; > +#else > + t->x86_tss.io_bitmap_base = INVALID_IO_BITMAP_OFFSET; > +#endif > +} > + > /* > * Save the original ist values for checking stack pointers during debugging > */ > @@ -510,11 +534,13 @@ struct thread_struct { > unsigned int saved_fs; > unsigned int saved_gs; > #endif > +#ifdef CONFIG_X86_IOPORT > /* IO permissions: */ > unsigned long *io_bitmap_ptr; > unsigned long...

...bits beyond the end of the IO permission bitmap. + */ + for (i = 0; i <= IO_BITMAP_LONGS; i++) + t->io_bitmap[i] = ~0UL; +#else + t->x86_tss.io_bitmap_base = INVALID_IO_BITMAP_OFFSET; +#endif +} + /* * Save the original ist values for checking stack pointers during debugging */ @@ -510,11 +534,13 @@ struct thread_struct { unsigned int saved_fs; unsigned int saved_gs; #endif +#ifdef CONFIG_X86_IOPORT /* IO permissions: */ unsigned long *io_bitmap_ptr; unsigned long iopl; /* Max allowed port in the bitmap, in bytes: */ unsigned io_bitmap_max; +#endif /* CONFIG_X...

...bits beyond the end of the IO permission bitmap. + */ + for (i = 0; i <= IO_BITMAP_LONGS; i++) + t->io_bitmap[i] = ~0UL; +#else + t->x86_tss.io_bitmap_base = INVALID_IO_BITMAP_OFFSET; +#endif +} + /* * Save the original ist values for checking stack pointers during debugging */ @@ -510,11 +534,13 @@ struct thread_struct { unsigned int saved_fs; unsigned int saved_gs; #endif +#ifdef CONFIG_X86_IOPORT /* IO permissions: */ unsigned long *io_bitmap_ptr; unsigned long iopl; /* Max allowed port in the bitmap, in bytes: */ unsigned io_bitmap_max; +#endif /* CONFIG_X...

...E]; /* sysfs file for resources */ struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file for WC mapping of resources */ #ifdef CONFIG_PCI_MSI - struct list_head msi_list; + struct msi_irqs *msi; const struct attribute_group **msi_irq_groups; #endif struct pci_vpd *vpd; @@ -510,11 +508,14 @@ static inline struct pci_dev *pci_upstream_bridge(struct pci_dev *dev) static inline bool pci_dev_msi_enabled(struct pci_dev *pci_dev, int type) { bool enabled = 0; + + if (!pci_dev->msi) + return false; if (type & MSI_TYPE) - enabled |= pci_dev->msi_enabled; + e...

....pushbuf; + struct nvc0_screen *screen = NULL; + struct nouveau_pushbuf *push; + + screen = container_of(mgr, screen, base.fence); + push = screen->base.pushbuf; /* we need to do it after possible flush in MARK_RING */ *sequence = ++screen->base.fence.sequence; @@ -507,9 +510,11 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 *sequence) } static u32 -nvc0_screen_fence_update(struct pipe_screen *pscreen) +nvc0_screen_fence_update(struct nouveau_fence_mgr *mgr) { - struct nvc0_screen *screen = nvc0_screen(pscreen); + struct nvc0_screen *screen = NU...

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

...ase.pushbuf; + struct nvc0_screen *screen = NULL; + struct nouveau_pushbuf *push; + + screen = container_of(mgr, screen, base.fence); + push = screen->base.pushbuf; /* we need to do it after possible flush in MARK_RING */ *sequence = ++screen->base.fence.sequence; @@ -507,9 +510,11 @@ nvc0_screen_fence_emit(struct pipe_screen *pscreen, u32 *sequence) } static u32 -nvc0_screen_fence_update(struct pipe_screen *pscreen) +nvc0_screen_fence_update(struct nouveau_fence_mgr *mgr) { - struct nvc0_screen *screen = nvc0_screen(pscreen); + struct nvc0_screen *screen = NULL;...

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place