Nearly identical to the previous set of patches related to Microsoft
Surface Keyboards.
Removes Surface Pro 3 generation TypeCover support from hid-microsoft
so proper multitouch data can be reported from the touchpad.
Signed-off-by: Dennis Chen
---
drivers/hid/hid-core.c | 8
Removes trailing whitespace in hid-core.c and usbhid/hid-quirks.c
Signed-off-by: Dennis Chen
---
drivers/hid/hid-core.c | 2 +-
drivers/hid/usbhid/hid-quirks.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index
Hi,
This should be the last related patch for the Surface Pro
Type Covers.
Sincerely,
Dennis Chen
>8--8<
Nearly identical to the previous set of patches related to Microsoft
Surface Keyboards.
Removes Surface Pro 3 generation Typ
Hi Tomasz,
On Tue, Sep 06, 2016 at 11:08:51AM +0200, Tomasz Nowicki wrote:
[...]
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> +u32 *rid_out)
> +{
> + /* Single mapping does not care for input id */
> + if (map->flags & ACPI_IORT_ID_
On Thu, Aug 18, 2016 at 12:14:20PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Aug 18, 2016 at 06:55:50PM +0800, Dennis Chen wrote:
>
> [...]
>
> > > +static struct acpi_iort_node *
> > > +iort_scan_node(enum acpi_iort_node_type type,
> > > +iort_fin
Hi Tomasz,
On Thu, Aug 11, 2016 at 12:06:31PM +0200, Tomasz Nowicki wrote:
> IORT shows representation of IO topology for ARM based systems.
> It describes how various components are connected together on
> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
> http://infocenter.arm.
Hi Lorenzo,
On Mon, Aug 15, 2016 at 04:23:34PM +0100, Lorenzo Pieralisi wrote:
> In ARM ACPI systems, IOMMU components are specified through static
> IORT table entries. In order to create platform devices for the
> corresponding ARM SMMU components, IORT kernel code should be made
> able to parse
On Mon, Jul 25, 2016 at 09:36:41AM +0100, Lorenzo Pieralisi wrote:
> On Mon, Jul 25, 2016 at 01:53:32PM +0800, Dennis Chen wrote:
> > Hi
> > On Wed, Jul 20, 2016 at 12:23:22PM +0100, Lorenzo Pieralisi wrote:
> > > This RFC patch series is v3 of a previous posting:
>
Hi
On Wed, Jul 20, 2016 at 12:23:22PM +0100, Lorenzo Pieralisi wrote:
> This RFC patch series is v3 of a previous posting:
>
> https://lkml.org/lkml/2016/6/7/523
>
> v2 -> v3
> - Rebased on top of dependencies series [1][2][3](v4.7-rc3)
> - Added back reliance on ACPI early probing in
On Wed, Jul 20, 2016 at 01:03:00PM +0200, Auger Eric wrote:
> Hi Dennis
> On 20/07/2016 11:56, Dennis Chen wrote:
> > Hi Eric,
> >
> > On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote:
> >> This series introduces the msi-iommu api used to:
> >&
Hi Eric,
Some small questions/comments below:
On Tue, Jul 19, 2016 at 12:55:07PM +, Eric Auger wrote:
> iommu_get/put_msi_cookie allocates/frees the resource used to store
> and ref count the MSI doorbell mappings. iommu_msi_set_aperture
> initializes the iova domain used for MSI IOVA allocati
Hi Eric,
On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote:
> This series introduces the msi-iommu api used to:
>
> - allocate/free resources for MSI IOMMU mapping
> - set the MSI iova window aperture
> - map/unmap physical addresses onto MSI IOVAs.
> - determine whether an msi needs to
Commit-ID: c75343972b79ef5bd44c498a63b326e37470bbfc
Gitweb: http://git.kernel.org/tip/c75343972b79ef5bd44c498a63b326e37470bbfc
Author: Dennis Chen
AuthorDate: Tue, 31 May 2016 11:23:44 +0100
Committer: Ingo Molnar
CommitDate: Fri, 3 Jun 2016 09:57:36 +0200
efi/arm: Fix the format of
inded with other patches in
> Hanjun Guo's original set, removed get_mpidr_in_madt() and use
> acpi_map_madt_entry() instead.]
> Signed-off-by: David Daney
> ---
I've tested this patch on Juno board with home made SRAT and SLIT
table, so feel free to add:
Tested-by: Dennis Chen
--
Regards,
Dennis
On 25 May 2016 at 06:35, David Daney wrote:
> From: David Daney
>
> As noted by Dennis Chen, we don't want to print "No NUMA configuration
> found" if NUMA was forced off from the command line.
>
> Change the type of numa_off to bool, and clean up printing code.
Hi Hanjun,
Thanks for the clarification and some little comments ;-)
On 27 April 2016 at 12:04, Hanjun Guo wrote:
> Hi Dennis, David,
>
> Sorry for the late reply, please see my comments below.
>
>
> On 2016/4/27 9:14, David Daney wrote:
>>
>> On 04/21/20
On 20 April 2016 at 09:40, David Daney wrote:
> From: Hanjun Guo
>
> Introduce a new file to hold ACPI based NUMA information parsing from
> SRAT and SLIT.
>
> SRAT includes the CPU ACPI ID to Proximity Domain mappings and memory
> ranges to Proximity Domain mapping. SLIT has the information of
On 20 April 2016 at 09:40, David Daney wrote:
> From: Hanjun Guo
>
> Introduce a new file to hold ACPI based NUMA information parsing from
> SRAT and SLIT.
>
> SRAT includes the CPU ACPI ID to Proximity Domain mappings and memory
> ranges to Proximity Domain mapping. SLIT has the information of
On Mon, Nov 02, 2015 at 09:51:46AM -0600, Suravee Suthikulanit wrote:
> Hi Dennis / Hanjun,
>
> On 11/2/2015 5:58 AM, Hanjun Guo wrote:
> >Hi Dennis,
> >
> >On 11/02/2015 12:02 PM, Dennis Chen wrote:
> >>On Thu, Oct 29, 2015 at 6:50 AM, Suravee Suthikulpanit
On Thu, Oct 29, 2015 at 6:50 AM, Suravee Suthikulpanit
wrote:
> From: Jeremy Linton
>
> ACPI configurations can now mark devices as noncoherent,
> support that choice.
>
> NOTE: This is required to support USB on ARM Juno Development Board.
>
> Signed-off-by: Jeremy Linton
> Signed-off-by: S
On Fri, Aug 28, 2015 at 03:39:43PM +0100, Lorenzo Pieralisi wrote:
> Hi Dennis,
>
> You should CC linux-...@vger.kernel.org and the PCI subsystem
> maintainer next time.
>
>
Good reminder! Thanks, mate ;-)
> On Fri, Aug 28, 2015 at 01:49:23PM +0100, Dennis Chen wrote:
>
This patch will fall back to ACPI MCFG table if _CBA method fails
to get the configuration base address of ECAM. Firmware on ARM
platform uses MCFG table instead of _CBA method. This is needed
to scan the PCIe root complex for ARM SoC.
Signed-off-by: Dennis Chen
---
drivers/pci/pci-acpi.c | 102
> Could you please send me the output of 'lsusb -v -d 045e:07be' and
> 'lsusb -v -
> d 045e:07bf' (running as root if possible) ?
Bus 001 Device 004: ID 045e:07bf Microsoft Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClas
> Is this needed ? Looking at the patch your cameras are UVC-compliant
> and
> should thus be picked by the uvcvideo driver without any change to
> the code.
The cameras are UVC-compliant but are not recognized by the uvc driver.
The patch forces the uvc driver to pick up the camera if present.
Add support for the Microsoft Surface Pro 3 Cameras.
Signed-off-by: Dennis Chen
---
drivers/media/usb/uvc/uvc_driver.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 5970dd6..ec5a407 100644
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>From 843d038eec5ac2c59d3138f19ae52828098c7d50 Mon Sep 17 00:00:00 2001
From: Dennis Chen
Date: Fri, 5 Jun 2015 15:42:37 -0700
Subject: [PATCH] Staging: comedi: daqboard2000: fixed whitespace coding style
issue
Fixed whitespace coding style issue.
Signed-off-by: Dennis Chen
---
driv
On Mon, Aug 25, 2014 at 10:04 PM, Gleb Natapov wrote:
> On Mon, Aug 25, 2014 at 11:16:34AM +0800, Dennis Chen wrote:
>> On Sun, Aug 24, 2014 at 5:38 PM, Gleb Natapov wrote:
>> > On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
>> >> This patch is use
pe
check, any comments, guys?
> On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
>>This patch is used to construct the eptp in vmx mode with values
>>readed from MSR according to the intel x86 software developer's
>>manual.
>>
>>Signed-off-by: Denn
On Sun, Aug 24, 2014 at 5:38 PM, Gleb Natapov wrote:
> On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
>> This patch is used to construct the eptp in vmx mode with values
>> readed from MSR according to the intel x86 software developer's
>> manual.
>&g
CC'ing Avi and Paolo...
Avi/Paolo, any comments?--Den
On Sun, Aug 24, 2014 at 11:54 AM, Dennis Chen wrote:
> This patch is used to construct the eptp in vmx mode with values
> readed from MSR according to the intel x86 software developer's
> manual.
>
> S
This patch is used to construct the eptp in vmx mode with values
readed from MSR according to the intel x86 software developer's
manual.
Signed-off-by: Dennis Chen
---
arch/x86/include/asm/vmx.h |1 +
arch/x86/kvm/vmx.c | 21 +
2 files changed, 18 inser
On 07/26/2013 09:38 PM, Tejun Heo wrote:
Hello,
On Fri, Jul 26, 2013 at 05:59:00PM +0800, Dennis Chen wrote:
On 07/26/2013 05:49 PM, Dennis Chen wrote:
The patch is trying its best to avoid creating a dir under a parent dir which
is removing from
the system:
PATH0 (create a dir under
On 07/26/2013 05:49 PM, Dennis Chen wrote:
The patch is trying its best to avoid creating a dir under a parent dir which
is removing from
the system:
PATH0 (create a dir under 'PARENT/...') PATH1 (remove the
'PARENT/...')
PATH0 think it has a valid
parent_sd which
can be freed by PATH1 in the followed, refer to the comments in the patch.
Maybe we need
to figure out a perfect solution to solve the race condition, although the
codes in question are
in slow path...
Signed-off-by: Dennis Chen
Cc: Greg Kroah-Hartman
On 07/23/2013 04:12 PM, Dennis Chen wrote:
This patch is try to fix a potential NULL function pointer dereference in the
exported
vfs_kern_mount() function which can be triggered by following kernel module
code piece:
static struct vfsmount *npfs_mnt;
static struct file_system_type np_fs_type
ent a (*mount)() function in the np_fs_type
instance which
is buggy definitely, but as an exported function to the outside, kernel should
not suppose
the caller will always take the right action. In this scenario, I have to
reboot my machine
to clean the loaded kernel module.
Signed-off-by: Dennis
Any body can be help about this or a little bit clues? Thanks!
On Mon, Oct 8, 2012 at 3:01 PM, Dennis Chen wrote:
> Hi All,
>
> I am confused by the following observed scenario:
>
> In my 4-CPU (KVM supported, 2 core with 2 thread for each) host
> machine box, I create only
Hi All,
I am confused by the following observed scenario:
In my 4-CPU (KVM supported, 2 core with 2 thread for each) host
machine box, I create only one VM with 3-vCPU through virsh/libvirt
tools and also I pin this VM process to the physical processor 3. I
guess the CPU utilization for the proce
39 matches
Mail list logo
