Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Castano Giovanni

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Castano Giovanni

RE: EHCI

Hi, > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Saturday, March 18, 2017 12:44 AM > To: Lipengcheng > Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: EHCI > > On Fri, 17 Mar 2017, Lipengcheng

RE: EHCI

Hi, > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Saturday, March 18, 2017 12:44 AM > To: Lipengcheng > Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: EHCI > > On Fri, 17 Mar 2017, Lipengcheng

[PATCH v3 2/5] platform/x86: intel_pmc_ipc: Add pmc gcr read/write/update api's

This patch adds API's to read/write/update PMC GC registers. PMC dependent devices like iTCO_WDT, Telemetry has requirement to acces GCR registers. These API's can be used for this purpose. Signed-off-by: Kuppuswamy Sathyanarayanan ---

[PATCH v3 2/5] platform/x86: intel_pmc_ipc: Add pmc gcr read/write/update api's

This patch adds API's to read/write/update PMC GC registers. PMC dependent devices like iTCO_WDT, Telemetry has requirement to acces GCR registers. These API's can be used for this purpose. Signed-off-by: Kuppuswamy Sathyanarayanan --- arch/x86/include/asm/intel_pmc_ipc.h | 21 ++

Re: [HMM 2/2] hmm: heterogeneous memory management documentation

> On 03/17/2017 12:27 PM, Jérôme Glisse wrote: > > This add documentation for HMM (Heterogeneous Memory Management). It > > presents the motivation behind it, the features necessary for it to > > be usefull and and gives an overview of how this is implemented. > > For this patch, I will leave it

Re: [HMM 2/2] hmm: heterogeneous memory management documentation

> On 03/17/2017 12:27 PM, Jérôme Glisse wrote: > > This add documentation for HMM (Heterogeneous Memory Management). It > > presents the motivation behind it, the features necessary for it to > > be usefull and and gives an overview of how this is implemented. > > For this patch, I will leave it

[PATCH 1/3] firmware: qcom: scm: Expose secure IO service

The secure IO service provides operations for reading and writing secure memory from non-secure mode, expose this API through SCM. Signed-off-by: Bjorn Andersson --- 32-bit version is untested. drivers/firmware/qcom_scm-32.c | 11 +++

[PATCH 3/3] arm64: dts: qcom: msm8996: Specify dload address

On some msm8996 boards a secure io-write is used to write the magic for selecting "download mode", specify this address in the DeviceTree. Signed-off-by: Bjorn Andersson --- arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 1/3] firmware: qcom: scm: Expose secure IO service

The secure IO service provides operations for reading and writing secure memory from non-secure mode, expose this API through SCM. Signed-off-by: Bjorn Andersson --- 32-bit version is untested. drivers/firmware/qcom_scm-32.c | 11 +++ drivers/firmware/qcom_scm-64.c | 31

[PATCH 3/3] arm64: dts: qcom: msm8996: Specify dload address

On some msm8996 boards a secure io-write is used to write the magic for selecting "download mode", specify this address in the DeviceTree. Signed-off-by: Bjorn Andersson --- arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 2/3] firmware: qcom: scm: Expose download-mode control

In order to aid post-mortem debugging the Qualcomm platforms provides a "memory download mode", where the boot loader will provide an interface for custom tools to "download" the content of RAM to a host machine. The mode is triggered by writing a magic value somehwere in RAM, that is read in the

[PATCH 2/3] firmware: qcom: scm: Expose download-mode control

In order to aid post-mortem debugging the Qualcomm platforms provides a "memory download mode", where the boot loader will provide an interface for custom tools to "download" the content of RAM to a host machine. The mode is triggered by writing a magic value somehwere in RAM, that is read in the

[RFC PATCHv2 04/21] staging: android: ion: Remove alignment from allocation field

The align field was supposed to be used to specify the alignment of the allocation. Nobody actually does anything with it except to check if the alignment specified is out of bounds. Since this has no effect on the actual allocation, just remove it. Signed-off-by: Laura Abbott

[RFC PATCHv2 04/21] staging: android: ion: Remove alignment from allocation field

The align field was supposed to be used to specify the alignment of the allocation. Nobody actually does anything with it except to check if the alignment specified is out of bounds. Since this has no effect on the actual allocation, just remove it. Signed-off-by: Laura Abbott ---

[PATCH] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

Commit 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes") replaced xfs_zero_remaining_bytes() with calls to iomap helpers. Unfortunately the new iomap helpers don't enforce that [pos,count) lies strictly on [0,i_size). This causes fallocate(mode=PUNCH_HOLE|KEEP_SIZE) calls touching [i_size &

[PATCH] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

Commit 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes") replaced xfs_zero_remaining_bytes() with calls to iomap helpers. Unfortunately the new iomap helpers don't enforce that [pos,count) lies strictly on [0,i_size). This causes fallocate(mode=PUNCH_HOLE|KEEP_SIZE) calls touching [i_size &

XArray version 2

Here's version 2 of the XArray patch. Compared to version 1, I fixed a lot of bugs. 0day has finally stopped whinging about the various things I've done wrong, so I have some level of confidence in it. You can get a git tree here if you're interested. I rebase occasionally.

XArray version 2

Here's version 2 of the XArray patch. Compared to version 1, I fixed a lot of bugs. 0day has finally stopped whinging about the various things I've done wrong, so I have some level of confidence in it. You can get a git tree here if you're interested. I rebase occasionally.

[RFC PATCHv2 21/21] staging: android: ion: Set query return value

This never got set in the ioctl. Properly set a return value of 0 on success. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index

[RFC PATCHv2 21/21] staging: android: ion: Set query return value

This never got set in the ioctl. Properly set a return value of 0 on success. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 64c652b..8bd90ce

[RFC PATCHv2 15/21] staging: android: ion: Break the ABI in the name of forward progress

To: Sumit Semwal To: Riley Andrews Cc: rom...@google.com To: a...@android.com To: Riley Andrews Cc: de...@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: Greg Kroah-Hartman

[RFC PATCHv2 15/21] staging: android: ion: Break the ABI in the name of forward progress

To: Sumit Semwal To: Riley Andrews Cc: rom...@google.com To: a...@android.com To: Riley Andrews Cc: de...@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: Greg Kroah-Hartman Cc: linux-arm-ker...@lists.infradead.org Cc: linux-me...@vger.kernel.org Cc:

Re: [PATCH 1/7] net, netfilter: convert ip_vs_conn.refcnt from atomic_t to refcount_t

Hi Elena, [auto build test ERROR on nf-next/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/7] net, netfilter: convert ip_vs_conn.refcnt from atomic_t to refcount_t

Hi Elena, [auto build test ERROR on nf-next/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

> Fix this by reintroducing the checks xfs_zero_remaining_bytes() did > against i_size into xfs_zero_range(). Sorry this is wrong: I missed that xfs_zero_range() has another caller that depends on the behavior I'm changing. I'll send a v2 with the same hunk at the bottom of xfs_free_file_space()

Re: [PATCH] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

> Fix this by reintroducing the checks xfs_zero_remaining_bytes() did > against i_size into xfs_zero_range(). Sorry this is wrong: I missed that xfs_zero_range() has another caller that depends on the behavior I'm changing. I'll send a v2 with the same hunk at the bottom of xfs_free_file_space()

[RFC PATCHv2 10/21] staging: android: ion: Remove import interface

With the expansion of dma-buf and the move for Ion to be come just an allocator, the import mechanism is mostly useless. There isn't a kernel component to Ion anymore and handles are private to Ion. Remove this interface. Signed-off-by: Laura Abbott ---

[RFC PATCHv2 03/21] staging: android: ion: Remove dmap_cnt

The reference counting of dma_map calls was removed. Remove the associated counter field as well. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion_priv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_priv.h

[RFC PATCHv2 10/21] staging: android: ion: Remove import interface

With the expansion of dma-buf and the move for Ion to be come just an allocator, the import mechanism is mostly useless. There isn't a kernel component to Ion anymore and handles are private to Ion. Remove this interface. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c

[RFC PATCHv2 03/21] staging: android: ion: Remove dmap_cnt

The reference counting of dma_map calls was removed. Remove the associated counter field as well. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion_priv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_priv.h

[RFC PATCHv2 07/21] staging: android: ion: Remove page faulting support

The new method of syncing with dma_map means that the page faulting sync implementation is no longer applicable. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 117 -- 1 file changed, 117 deletions(-) diff

[RFC PATCHv2 07/21] staging: android: ion: Remove page faulting support

The new method of syncing with dma_map means that the page faulting sync implementation is no longer applicable. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 117 -- 1 file changed, 117 deletions(-) diff --git

[PATCH net-next v4 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[PATCH net-next v4 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

Re: [PATCH net-next v3 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

[Posting a v4 patch-set shortly based on additional code review comments received in internal review, please disregard the v3 patches] On Thu, Mar 16, 2017 at 9:33 PM, R. Parameswaran wrote: > > > In existing kernel code, when setting up the L2TP interface, all of the

Re: [PATCH net-next v3 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

[Posting a v4 patch-set shortly based on additional code review comments received in internal review, please disregard the v3 patches] On Thu, Mar 16, 2017 at 9:33 PM, R. Parameswaran wrote: > > > In existing kernel code, when setting up the L2TP interface, all of the > tunnel encapsulation

[PATCH v3 3/5] watchdog: iTCO_wdt: Add PMC specific noreboot update api

In some SOCs, setting noreboot bit needs modification to PMC GC registers. But not all PMC drivers allow other drivers to memory map their GC region. This could create mem request conflict in watchdog driver. So this patch adds facility to allow PMC drivers to pass noreboot update function to

[PATCH v3 3/5] watchdog: iTCO_wdt: Add PMC specific noreboot update api

In some SOCs, setting noreboot bit needs modification to PMC GC registers. But not all PMC drivers allow other drivers to memory map their GC region. This could create mem request conflict in watchdog driver. So this patch adds facility to allow PMC drivers to pass noreboot update function to

Re: [PATCH v3 7/7] mmc: Only descend into mmc directory when CONFIG_MMC is set

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v3 7/7] mmc: Only descend into mmc directory when CONFIG_MMC is set

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH v3 4/5] platform/x86: intel_pmc_ipc: Fix iTCO GCS memory mapping failure

iTCO watchdog driver need access to PMC_CFG GCR register to modify the no reboot setting. Currently, this is done by passing PMC_CFG reg address as memory resource to watchdog driver and allowing it directly modify the PMC_CFG register. But currently PMC driver also has requirement to memory map

[PATCH v3 5/5] platform/x86: intel_pmc_ipc: use gcr mem base for S0ix counter read

To maintain the uniformity in accessing GCR registers, this patch modifies the S0ix counter read function to use GCR address base instead of ipc address base. Signed-off-by: Kuppuswamy Sathyanarayanan --- arch/x86/include/asm/intel_pmc_ipc.h | 2 ++

[PATCH v3 4/5] platform/x86: intel_pmc_ipc: Fix iTCO GCS memory mapping failure

iTCO watchdog driver need access to PMC_CFG GCR register to modify the no reboot setting. Currently, this is done by passing PMC_CFG reg address as memory resource to watchdog driver and allowing it directly modify the PMC_CFG register. But currently PMC driver also has requirement to memory map

[PATCH v3 5/5] platform/x86: intel_pmc_ipc: use gcr mem base for S0ix counter read

To maintain the uniformity in accessing GCR registers, this patch modifies the S0ix counter read function to use GCR address base instead of ipc address base. Signed-off-by: Kuppuswamy Sathyanarayanan --- arch/x86/include/asm/intel_pmc_ipc.h | 2 ++ drivers/platform/x86/intel_pmc_ipc.c | 10

[PATCH v3 1/5] platform/x86: intel_pmc_ipc: fix gcr offset

According to the PMC spec, gcr offset from ipc mem region is 0x1000(4K). But currently this driver uses 0x1008 as gcr offset. This patch fixes this issue. Signed-off-by: Kuppuswamy Sathyanarayanan --- drivers/platform/x86/intel_pmc_ipc.c | 2 +- 1

[PATCH v3 1/5] platform/x86: intel_pmc_ipc: fix gcr offset

According to the PMC spec, gcr offset from ipc mem region is 0x1000(4K). But currently this driver uses 0x1008 as gcr offset. This patch fixes this issue. Signed-off-by: Kuppuswamy Sathyanarayanan --- drivers/platform/x86/intel_pmc_ipc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought

[RFC PATCHv2 11/21] staging: android: ion: Remove duplicate ION_IOC_MAP

ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two identical interfaces. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c | 1 - drivers/staging/android/ion/ion-ioctl.c | 1 - drivers/staging/android/uapi/ion.h |

[RFC PATCHv2 11/21] staging: android: ion: Remove duplicate ION_IOC_MAP

ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two identical interfaces. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c | 1 - drivers/staging/android/ion/ion-ioctl.c | 1 - drivers/staging/android/uapi/ion.h | 10 -- 3

[RFC PATCHv2 20/21] staging: android: ion: Remove ion_handle and ion_client

ion_handle was introduced as an abstraction to represent a reference to a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf emerged as the preferred standard for use in the kernel. This has made the ion_handle an unnecessary abstraction and prone to race conditions.

[RFC PATCHv2 20/21] staging: android: ion: Remove ion_handle and ion_client

ion_handle was introduced as an abstraction to represent a reference to a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf emerged as the preferred standard for use in the kernel. This has made the ion_handle an unnecessary abstraction and prone to race conditions.

[RFC PATCHv2 02/21] cma: Introduce cma_for_each_area

Frameworks (e.g. Ion) may want to iterate over each possible CMA area to allow for enumeration. Introduce a function to allow a callback. Signed-off-by: Laura Abbott --- include/linux/cma.h | 2 ++ mm/cma.c| 14 ++ 2 files changed, 16 insertions(+)

[RFC PATCHv2 02/21] cma: Introduce cma_for_each_area

Frameworks (e.g. Ion) may want to iterate over each possible CMA area to allow for enumeration. Introduce a function to allow a callback. Signed-off-by: Laura Abbott --- include/linux/cma.h | 2 ++ mm/cma.c| 14 ++ 2 files changed, 16 insertions(+) diff --git

[PATCH] cpufreq: intel_pstate: Fix policy data management in passive mode

From: Rafael J. Wysocki The policy->cpuinfo.max_freq and policy->max updates in intel_cpufreq_turbo_update() are excessive as they are done for no good reason and may lead to problems in principle, so drop them. Moreover, fix intel_cpufreq_verify_policy() so that it

[PATCH] cpufreq: intel_pstate: Fix policy data management in passive mode

From: Rafael J. Wysocki The policy->cpuinfo.max_freq and policy->max updates in intel_cpufreq_turbo_update() are excessive as they are done for no good reason and may lead to problems in principle, so drop them. Moreover, fix intel_cpufreq_verify_policy() so that it checks global.no_turbo in

[PATCH v2] sched/core: Fix rq lock pinning warning after call balance callbacks

From: Wanpeng Li This can be reproduced by running rt-migrate-test: WARNING: CPU: 2 PID: 2195 at kernel/locking/lockdep.c:3670 lock_unpin_lock+0x172/0x180 unpinning an unpinned lock CPU: 2 PID: 2195 Comm: rt-migrate-test Tainted: GW 4.11.0-rc2+ #1

[PATCH v2] sched/core: Fix rq lock pinning warning after call balance callbacks

From: Wanpeng Li This can be reproduced by running rt-migrate-test: WARNING: CPU: 2 PID: 2195 at kernel/locking/lockdep.c:3670 lock_unpin_lock+0x172/0x180 unpinning an unpinned lock CPU: 2 PID: 2195 Comm: rt-migrate-test Tainted: GW 4.11.0-rc2+ #1 Call Trace:

Re: [HMM 2/2] hmm: heterogeneous memory management documentation

On 03/17/2017 12:27 PM, Jérôme Glisse wrote: This add documentation for HMM (Heterogeneous Memory Management). It presents the motivation behind it, the features necessary for it to be usefull and and gives an overview of how this is implemented. For this patch, I will leave it to others to

Re: [HMM 2/2] hmm: heterogeneous memory management documentation

On 03/17/2017 12:27 PM, Jérôme Glisse wrote: This add documentation for HMM (Heterogeneous Memory Management). It presents the motivation behind it, the features necessary for it to be usefull and and gives an overview of how this is implemented. For this patch, I will leave it to others to

[RFC PATCHv2 14/21] staging: android: ion: Stop butchering the DMA address

Now that we have proper caching, stop setting the DMA address manually. It should be set after properly calling dma_map. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 17 + 1 file changed, 1 insertion(+), 16 deletions(-) diff --git

[RFC PATCHv2 14/21] staging: android: ion: Stop butchering the DMA address

Now that we have proper caching, stop setting the DMA address manually. It should be set after properly calling dma_map. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 17 + 1 file changed, 1 insertion(+), 16 deletions(-) diff --git

[RFC PATCHv2 18/21] staging: android: ion: Rework heap registration/enumeration

The current model of Ion heap registration is based on the outdated model of board files. The replacement for board files (devicetree) isn't a good replacement for what Ion wants to do. In actuality, Ion wants to show what memory is available in the system for something else to figure out what

[RFC PATCHv2 18/21] staging: android: ion: Rework heap registration/enumeration

The current model of Ion heap registration is based on the outdated model of board files. The replacement for board files (devicetree) isn't a good replacement for what Ion wants to do. In actuality, Ion wants to show what memory is available in the system for something else to figure out what

Re: [PATCH 1/2] gpio: omap: return error if requested debounce time is not possible

On 03/17/2017 03:50 PM, David Rivshin wrote: On Fri, 17 Mar 2017 13:54:28 -0500 Grygorii Strashko wrote: On 03/17/2017 12:54 PM, David Rivshin wrote: Hi Grygorii, On Fri, 17 Mar 2017 11:45:56 -0500 Grygorii Strashko wrote: On

Re: [PATCH 1/2] gpio: omap: return error if requested debounce time is not possible

On 03/17/2017 03:50 PM, David Rivshin wrote: On Fri, 17 Mar 2017 13:54:28 -0500 Grygorii Strashko wrote: On 03/17/2017 12:54 PM, David Rivshin wrote: Hi Grygorii, On Fri, 17 Mar 2017 11:45:56 -0500 Grygorii Strashko wrote: On 03/16/2017 07:57 PM, David Rivshin wrote: From: David

[RFC PATCHv2 00/21] Ion clean in preparation for moving out of staging

Hi, This is v2 of the series to do some serious Ion clean up in preparation for moving out of staging. I got good feedback last time so this series mostly attempts to address that feedback and do more still more cleanup. Highlights: - All calls to DMA APIs should now be with a real actual

[RFC PATCHv2 00/21] Ion clean in preparation for moving out of staging

Hi, This is v2 of the series to do some serious Ion clean up in preparation for moving out of staging. I got good feedback last time so this series mostly attempts to address that feedback and do more still more cleanup. Highlights: - All calls to DMA APIs should now be with a real actual

Re: [PATCH v2] perf probe: Return errno when does not hit any event

On Fri, 17 Mar 2017 16:16:32 +0800 Kefeng Wang wrote: > On old perf, when using perf probe -d to delete an inexistent event, > it return errno, eg, > > -bash-4.3# perf probe -d xxx || echo $? > Info: Event "*:xxx" does not exist. > Error: Failed to delete events.

Re: [PATCH v2] perf probe: Return errno when does not hit any event

On Fri, 17 Mar 2017 16:16:32 +0800 Kefeng Wang wrote: > On old perf, when using perf probe -d to delete an inexistent event, > it return errno, eg, > > -bash-4.3# perf probe -d xxx || echo $? > Info: Event "*:xxx" does not exist. > Error: Failed to delete events. > 255 > > But now

[PATCH v5 2/2] mmc: host: s3cmci: allow probing from device tree

Allows configuring Samsung S3C24XX MMC/SD/SDIO controller using a device tree. Signed-off-by: Sergio Prado --- drivers/mmc/host/s3cmci.c | 257 +++--- 1 file changed, 126 insertions(+), 131 deletions(-) diff --git

[PATCH v5 2/2] mmc: host: s3cmci: allow probing from device tree

Allows configuring Samsung S3C24XX MMC/SD/SDIO controller using a device tree. Signed-off-by: Sergio Prado --- drivers/mmc/host/s3cmci.c | 257 +++--- 1 file changed, 126 insertions(+), 131 deletions(-) diff --git a/drivers/mmc/host/s3cmci.c

[PATCH v5 0/2] mmc: host: s3cmci: add device tree support

This series adds support for configuring Samsung's S3C24XX MMC/SD/SDIO controller via device tree. Tested on FriendlyARM mini2440, based on s3c2440 SoC. Changes since v4 (as suggested by Jaehoon Chung): - using just a flag as a data structure for the driver to check for s3c2400 compatibility

[PATCH v5 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller

Adds the device tree bindings description for Samsung S3C24XX MMC/SD/SDIO controller, used as a connectivity interface with external MMC, SD and SDIO storage mediums. Acked-by: Rob Herring Signed-off-by: Sergio Prado ---

[PATCH v5 0/2] mmc: host: s3cmci: add device tree support

This series adds support for configuring Samsung's S3C24XX MMC/SD/SDIO controller via device tree. Tested on FriendlyARM mini2440, based on s3c2440 SoC. Changes since v4 (as suggested by Jaehoon Chung): - using just a flag as a data structure for the driver to check for s3c2400 compatibility

[PATCH v5 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller

Adds the device tree bindings description for Samsung S3C24XX MMC/SD/SDIO controller, used as a connectivity interface with external MMC, SD and SDIO storage mediums. Acked-by: Rob Herring Signed-off-by: Sergio Prado --- .../devicetree/bindings/mmc/samsung,s3cmci.txt | 42

[PATCH] bitops.h: use BITS_PER_LONG to simplify BITS_TO_LONGS

The second parameter is the number of bits for type "long", which is already defined in header file. This patch replace the calculation with macro to make it more readable. Signed-off-by: Wei Yang --- include/linux/bitops.h | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] bitops.h: use BITS_PER_LONG to simplify BITS_TO_LONGS

The second parameter is the number of bits for type "long", which is already defined in header file. This patch replace the calculation with macro to make it more readable. Signed-off-by: Wei Yang --- include/linux/bitops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v1 3/3] blk-mq: start to freeze queue just after setting dying

On Fri, Mar 17, 2017 at 11:26:26PM +, Bart Van Assche wrote: > On Fri, 2017-03-17 at 17:57 +0800, Ming Lei wrote: > > Given blk_set_queue_dying() is always called in remove path > > of block device, and queue will be cleaned up later, we don't > > need to worry about undoing the counter. > >

Re: [PATCH v3 7/7] mmc: Only descend into mmc directory when CONFIG_MMC is set

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v1 3/3] blk-mq: start to freeze queue just after setting dying

On Fri, Mar 17, 2017 at 11:26:26PM +, Bart Van Assche wrote: > On Fri, 2017-03-17 at 17:57 +0800, Ming Lei wrote: > > Given blk_set_queue_dying() is always called in remove path > > of block device, and queue will be cleaned up later, we don't > > need to worry about undoing the counter. > >

Re: [PATCH v3 7/7] mmc: Only descend into mmc directory when CONFIG_MMC is set

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[RFC PATCHv2 05/21] staging: android: ion: Duplicate sg_table

Ion currently returns a single sg_table on each dma_map call. This is incorrect for later usage. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git

[RFC PATCHv2 09/21] staging: android: ion: Remove custom ioctl interface

Ion is now moving towards a unified interfact. This makes the custom ioctl interface unneeded. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c | 40 drivers/staging/android/ion/ion-ioctl.c | 11 -

[RFC PATCHv2 05/21] staging: android: ion: Duplicate sg_table

Ion currently returns a single sg_table on each dma_map call. This is incorrect for later usage. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git

[RFC PATCHv2 09/21] staging: android: ion: Remove custom ioctl interface

Ion is now moving towards a unified interfact. This makes the custom ioctl interface unneeded. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c | 40 drivers/staging/android/ion/ion-ioctl.c | 11 -

[RFC PATCHv2 17/21] staging: android: ion: Collapse internal header files

Ion current has ion_priv.h and ion.h as header files. ion.h was intended to be used for public APIs but Ion never ended up really having anything public. Combine the two headers so there is only one internal header. Signed-off-by: Laura Abbott ---

[RFC PATCHv2 17/21] staging: android: ion: Collapse internal header files

Ion current has ion_priv.h and ion.h as header files. ion.h was intended to be used for public APIs but Ion never ended up really having anything public. Combine the two headers so there is only one internal header. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion-ioctl.c

[RFC PATCHv2 13/21] staging: android: ion: Use CMA APIs directly

When CMA was first introduced, its primary use was for DMA allocation and the only way to get CMA memory was to call dma_alloc_coherent. This put Ion in an awkward position since there was no device structure readily available and setting one up messed up the coherency model. These days, CMA can

[RFC PATCHv2 12/21] staging: android: ion: Remove old platform support

Device specific platform support has been haphazard for Ion. There have been several independent attempts and there are still objections to what bindings exist right now. Just remove everything for a fresh start. Signed-off-by: Laura Abbott ---

[RFC PATCHv2 13/21] staging: android: ion: Use CMA APIs directly

When CMA was first introduced, its primary use was for DMA allocation and the only way to get CMA memory was to call dma_alloc_coherent. This put Ion in an awkward position since there was no device structure readily available and setting one up messed up the coherency model. These days, CMA can

[RFC PATCHv2 12/21] staging: android: ion: Remove old platform support

Device specific platform support has been haphazard for Ion. There have been several independent attempts and there are still objections to what bindings exist right now. Just remove everything for a fresh start. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/Kconfig

[RFC PATCHv2 16/21] staging: android: ion: Get rid of ion_phys_addr_t

Once upon a time, phys_addr_t was not everywhere in the kernel. These days it is used enough places that having a separate Ion type doesn't make sense. Remove the extra type and just use phys_addr_t directly. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.h

[RFC PATCHv2 16/21] staging: android: ion: Get rid of ion_phys_addr_t

Once upon a time, phys_addr_t was not everywhere in the kernel. These days it is used enough places that having a separate Ion type doesn't make sense. Remove the extra type and just use phys_addr_t directly. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.h | 12

[RFC PATCHv2 19/21] staging: android: ion: Drop ion_map_kernel interface

Nobody uses this interface externally. Drop it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 59 --- 1 file changed, 59 deletions(-) diff --git a/drivers/staging/android/ion/ion.c

[RFC PATCHv2 19/21] staging: android: ion: Drop ion_map_kernel interface

Nobody uses this interface externally. Drop it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 59 --- 1 file changed, 59 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index

[RFC PATCHv2 08/21] staging: android: ion: Remove crufty cache support

Now that we call dma_map in the dma_buf API callbacks there is no need to use the existing cache APIs. Remove the sync ioctl and the existing bad dma_sync calls. Explicit caching can be handled with the dma_buf sync API. Signed-off-by: Laura Abbott ---

[RFC PATCHv2 08/21] staging: android: ion: Remove crufty cache support

Now that we call dma_map in the dma_buf API callbacks there is no need to use the existing cache APIs. Remove the sync ioctl and the existing bad dma_sync calls. Explicit caching can be handled with the dma_buf sync API. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c

  1   2   3   4   5   6   7   8   9   10   >