[PATCH v13 06/10] arm64: Treat all entry code as non-kprobe-able

From: Pratyush Anand Entry symbols are not kprobe safe. So blacklist them for kprobing. Signed-off-by: Pratyush Anand Signed-off-by: David A. Long --- arch/arm64/kernel/entry.S | 3 +++ arch/arm64/kernel/kprobes.c | 26

[PATCH v13 00/10] arm64: Add kernel probes (kprobes) support

From: "David A. Long" This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, first seen in October 2013. This version attempts to address concerns raised by reviewers and also fixes problems discovered during testing. This patchset adds support for kernel probes(kprobes),

[PATCH v13 04/10] arm64: Blacklist non-kprobe-able symbol

From: Pratyush Anand Add all function symbols which are called from do_debug_exception under NOKPROBE_SYMBOL, as they can not kprobed. Signed-off-by: Pratyush Anand --- arch/arm64/kernel/arm64ksyms.c | 2 ++ arch/arm64/kernel/debug-monitors.c | 18 ++

[PATCH v13 06/10] arm64: Treat all entry code as non-kprobe-able

From: Pratyush Anand Entry symbols are not kprobe safe. So blacklist them for kprobing. Signed-off-by: Pratyush Anand Signed-off-by: David A. Long --- arch/arm64/kernel/entry.S | 3 +++ arch/arm64/kernel/kprobes.c | 26 ++ arch/arm64/kernel/vmlinux.lds.S |

Re: [PATCH V2 2/2] cpufreq: Optimize cpufreq_frequency_table_target()

On 02-06-16, 11:28, Steve Muckle wrote: > Shouldn't we be able to avoid extra function calls through the use of > macros/inlines? Otherwise this is making things slower for schedutil > than it is today. > > Actually cpufreq_driver_resolve_freq() shouldn't require any calls from > schedutil when

Re: [PATCH V2 2/2] cpufreq: Optimize cpufreq_frequency_table_target()

On 02-06-16, 11:28, Steve Muckle wrote: > Shouldn't we be able to avoid extra function calls through the use of > macros/inlines? Otherwise this is making things slower for schedutil > than it is today. > > Actually cpufreq_driver_resolve_freq() shouldn't require any calls from > schedutil when

Re: [PATCH][RESEND v2] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

Hi Rob Should I re-send this patch ? It still no response... > From: Kuninori Morimoto > > commit 93c667ca2598bd84f1bd3f2fa176af69707699fe > ("of: *node argument to of_parse_phandle_with_args should be const") > changed to const for struct device node *np, >

Re: [PATCH][RESEND v2] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

Hi Rob Should I re-send this patch ? It still no response... > From: Kuninori Morimoto > > commit 93c667ca2598bd84f1bd3f2fa176af69707699fe > ("of: *node argument to of_parse_phandle_with_args should be const") > changed to const for struct device node *np, > but it cares CONFIG_OF case only,

Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On 03-06-16, 03:43, Rafael J. Wysocki wrote: > On Friday, June 03, 2016 05:31:34 AM Viresh Kumar wrote: > > So, yeah, I get your overall concern. What about this: > > - A single patchset to make sure the current policy->freq_table is > > always sorted in Ascending order of frequencies. > > Be

Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On 03-06-16, 03:43, Rafael J. Wysocki wrote: > On Friday, June 03, 2016 05:31:34 AM Viresh Kumar wrote: > > So, yeah, I get your overall concern. What about this: > > - A single patchset to make sure the current policy->freq_table is > > always sorted in Ascending order of frequencies. > > Be

Re: [PATCH] block: correctly fallback for zeroout

> "Christoph" == Christoph Hellwig writes: Christoph> As part of that I also removed the strange EOPNOTSUPP ignore, Christoph> but Mike reverted it just because it changed something in the Christoph> dm testsuite. Mike? Christoph> I still believe we should never ignore

Re: [PATCH] block: correctly fallback for zeroout

> "Christoph" == Christoph Hellwig writes: Christoph> As part of that I also removed the strange EOPNOTSUPP ignore, Christoph> but Mike reverted it just because it changed something in the Christoph> dm testsuite. Mike? Christoph> I still believe we should never ignore it in this helper,

Re: [PATCH 4/4] powerpc/mm/radix: Implement tlb mmu gather flush efficiently

Andrew Morton writes: > On Thu, 2 Jun 2016 15:09:49 +0530 "Aneesh Kumar K.V" > wrote: > >> Now that we track page size in mmu_gather, we can use address based >> tlbie format when doing a tlb_flush(). We don't do this if we are >>

Re: [PATCH 4/4] powerpc/mm/radix: Implement tlb mmu gather flush efficiently

Andrew Morton writes: > On Thu, 2 Jun 2016 15:09:49 +0530 "Aneesh Kumar K.V" > wrote: > >> Now that we track page size in mmu_gather, we can use address based >> tlbie format when doing a tlb_flush(). We don't do this if we are >> invalidating the full address space. >> >> ... >> >> void

Re: [PATCH] block: correctly fallback for zeroout

> "Sitsofe" == Sitsofe Wheeler writes: Sitsofe> The original SCSI WRITE SAME has overloaded semantics - not Sitsofe> only does it mean "write this data multiple times" but it can Sitsofe> also be used to mean "discard this range" too. If the kernel's Sitsofe> command was

Re: [PATCH] block: correctly fallback for zeroout

> "Sitsofe" == Sitsofe Wheeler writes: Sitsofe> The original SCSI WRITE SAME has overloaded semantics - not Sitsofe> only does it mean "write this data multiple times" but it can Sitsofe> also be used to mean "discard this range" too. If the kernel's Sitsofe> command was modelled on the SCSI

RE: [PATCH 2/2] crypto : async implementation for sha1-mb

-Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Thursday, June 2, 2016 5:33 PM To: Dey, Megha Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux-cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Yu, Fenghua

RE: [PATCH 2/2] crypto : async implementation for sha1-mb

-Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Thursday, June 2, 2016 5:33 PM To: Dey, Megha Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux-cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Yu, Fenghua Subject: Re: [PATCH 2/2] crypto :

[PATCH V2 1/2] crypto: sha1-mb - stylistic cleanup

From: Megha Dey Currently there are several checkpatch warnings in the sha1_mb.c file: 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the syntax of some multi-line comments are not correct. This patch fixes these issues. Signed-off-by: Megha Dey

[PATCH V2 2/2] crypto : async implementation for sha1-mb

From: Megha Dey Herbert wants the sha1-mb algorithm to have an async implementation: https://lkml.org/lkml/2016/4/5/286. Currently, sha1-mb uses an async interface for the outer algorithm and a sync interface for the inner algorithm. This patch introduces a async

[PATCH V2 1/2] crypto: sha1-mb - stylistic cleanup

From: Megha Dey Currently there are several checkpatch warnings in the sha1_mb.c file: 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the syntax of some multi-line comments are not correct. This patch fixes these issues. Signed-off-by: Megha Dey Signed-off-by: Herbert Xu ---

[PATCH V2 2/2] crypto : async implementation for sha1-mb

From: Megha Dey Herbert wants the sha1-mb algorithm to have an async implementation: https://lkml.org/lkml/2016/4/5/286. Currently, sha1-mb uses an async interface for the outer algorithm and a sync interface for the inner algorithm. This patch introduces a async interface for even the inner

[PATCH V2 0/2] Implementation of an async interface for sha1-mb

From: Megha Dey Currently, sha1-mb uses an async interface for the outer algorithm and a sync interface for the inner algorithm. Herbert wants the sha1-mb algorithm to have an async implementation: https://lkml.org/lkml/2016/4/5/286. This patch introduces a async

[PATCH V2 0/2] Implementation of an async interface for sha1-mb

From: Megha Dey Currently, sha1-mb uses an async interface for the outer algorithm and a sync interface for the inner algorithm. Herbert wants the sha1-mb algorithm to have an async implementation: https://lkml.org/lkml/2016/4/5/286. This patch introduces a async interface for even the inner

[PATCH v4 net-next 04/13] net: hisilicon: add support of acpi for hns-mdio

From: Kejian Yan hns-mdio needs to register itself to mii-bus. The info of the device can be read by both DT and ACPI. HNS tries to call Linux PHY driver to help access PHY-devices, the HNS hardware topology is as below. The MDIO controller may control several PHY-devices,

[PATCH v4 net-next 03/13] net: hisilicon: cleanup to prepare for other cases

From: Kejian Yan Hns-mdio only supports DT case now. do some cleanup to prepare for introducing other cases later, no functional change. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v4: mii-id

[PATCH v4 net-next 00/13] net: hns: add support of ACPI

From: Kejian Yan This series adds HNS support of acpi. The routine will call some ACPI helper functions, like acpi_dev_found() and acpi_evaluate_dsm(), which are not included in other cases. In order to make system compile successfully in other cases except ACPI, it needs

[PATCH v4 net-next 07/13] net: hns: enet specify a reference to dsaf by fwnode_handle

From: Kejian Yan As device_node is only used by DT case, it is expected to find uniform ways. So fwnode_handle is the suitable method. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v2: remove the

[PATCH v4 net-next 12/13] net: hns: implement the miscellaneous operation by asl

From: Kejian Yan The miscellaneous operation is implemented in BIOS, the kernel can call _DSM method help to call the implementation in ACPI case. Here is a patch to do that. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang

[PATCH v4 net-next 07/13] net: hns: enet specify a reference to dsaf by fwnode_handle

From: Kejian Yan As device_node is only used by DT case, it is expected to find uniform ways. So fwnode_handle is the suitable method. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v2: remove the redundant line v1: first submit link:

[PATCH v4 net-next 12/13] net: hns: implement the miscellaneous operation by asl

From: Kejian Yan The miscellaneous operation is implemented in BIOS, the kernel can call _DSM method help to call the implementation in ACPI case. Here is a patch to do that. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v2: use a serial function to implement the

[PATCH v4 net-next 04/13] net: hisilicon: add support of acpi for hns-mdio

From: Kejian Yan hns-mdio needs to register itself to mii-bus. The info of the device can be read by both DT and ACPI. HNS tries to call Linux PHY driver to help access PHY-devices, the HNS hardware topology is as below. The MDIO controller may control several PHY-devices, and each PHY-device

[PATCH v4 net-next 03/13] net: hisilicon: cleanup to prepare for other cases

From: Kejian Yan Hns-mdio only supports DT case now. do some cleanup to prepare for introducing other cases later, no functional change. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v4: mii-id gets from dev_name instead of address v3: first submit Link:

[PATCH v4 net-next 00/13] net: hns: add support of ACPI

From: Kejian Yan This series adds HNS support of acpi. The routine will call some ACPI helper functions, like acpi_dev_found() and acpi_evaluate_dsm(), which are not included in other cases. In order to make system compile successfully in other cases except ACPI, it needs to add relative stub

[PATCH v4 net-next 06/13] net: hns: use platform_get_irq instead of irq_of_parse_and_map

From: Kejian Yan As irq_of_parse_and_map is only used by DT case, it is excepted to use a uniform interface. So it is used platform_get_irq() instead. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang ---

[PATCH v4 net-next 09/13] net: hns: add dsaf misc operation method

From: Kejian Yan The misc operation for different hw platform may be different, if using current implementation, it will add a new branch on each function for every new hw platform, so we add a method for this operation. Signed-off-by: Kejian Yan

[PATCH v4 net-next 06/13] net: hns: use platform_get_irq instead of irq_of_parse_and_map

From: Kejian Yan As irq_of_parse_and_map is only used by DT case, it is excepted to use a uniform interface. So it is used platform_get_irq() instead. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 5 ++--- 1 file changed, 2

[PATCH v4 net-next 09/13] net: hns: add dsaf misc operation method

From: Kejian Yan The misc operation for different hw platform may be different, if using current implementation, it will add a new branch on each function for every new hw platform, so we add a method for this operation. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang ---

[PATCH v4 net-next 11/13] net: hns: register phy device in each mac initial sequence

From: Kejian Yan In ACPI case, there is no interface to register phy device to mdio-bus. Phy device has to be registered itself to mdio-bus, and then enet can get the phy device's info so that it can config the phy-device to help to trasmit and receive data. HNS hardware

Re: [PATCH v2 1/6] power: Introduce Broadcom kona reset driver

Hi Florian, On Sat, May 21, 2016 at 10:09:07AM -0700, Florian Fainelli wrote: > Le 11/05/2016 14:36, Chris Brand a écrit : > > This driver supports reset on both BCM21664 and BCM23550. > > Code is being moved from arch/arm/mach-bcm/board_bcm21664.c > > > > Signed-off-by: Chris Brand

[PATCH v4 net-next 11/13] net: hns: register phy device in each mac initial sequence

From: Kejian Yan In ACPI case, there is no interface to register phy device to mdio-bus. Phy device has to be registered itself to mdio-bus, and then enet can get the phy device's info so that it can config the phy-device to help to trasmit and receive data. HNS hardware topology is as below.

Re: [PATCH v2 1/6] power: Introduce Broadcom kona reset driver

Hi Florian, On Sat, May 21, 2016 at 10:09:07AM -0700, Florian Fainelli wrote: > Le 11/05/2016 14:36, Chris Brand a écrit : > > This driver supports reset on both BCM21664 and BCM23550. > > Code is being moved from arch/arm/mach-bcm/board_bcm21664.c > > > > Signed-off-by: Chris Brand >

[PATCH v4 net-next 08/13] net: hns: add uniform interface for phy connection

From: Kejian Yan As device_node is only used by DT case, HNS needs to treat the other cases including ACPI. It needs to use uniform ways to handle both of DT and ACPI. This patch chooses phy_device, and of_phy_connect and of_phy_attach are only used by DT case. It needs to

[PATCH v4 net-next 10/13] net: hns: dsaf adds support of acpi

From: Kejian Yan Dsaf needs to get configuration parameter by ACPI, so this patch add support of ACPI. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v2: 1. use dev_of_node() instead of IS_ENABLED()

[PATCH v4 net-next 10/13] net: hns: dsaf adds support of acpi

From: Kejian Yan Dsaf needs to get configuration parameter by ACPI, so this patch add support of ACPI. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v2: 1. use dev_of_node() instead of IS_ENABLED() to check if it is in DT case, 2. split a new patch to implement

[PATCH v4 net-next 08/13] net: hns: add uniform interface for phy connection

From: Kejian Yan As device_node is only used by DT case, HNS needs to treat the other cases including ACPI. It needs to use uniform ways to handle both of DT and ACPI. This patch chooses phy_device, and of_phy_connect and of_phy_attach are only used by DT case. It needs to use uniform interface

[PATCH v4 net-next 13/13] net: hns: net: hns: enet adds support of acpi

From: Kejian Yan Enet needs to get configration parameter by acpi. This patch adds support of ACPI for enet. The configuration parameter will be configed in BIOS. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang ---

[PATCH v4 net-next 01/13] ACPI: bus: add stub acpi_dev_found() to linux/acpi.h

From: Kejian Yan acpi_dev_found() will be used to detect if a given ACPI device is in the system. It will be compiled in non-ACPI case, but the function is in acpi_bus.h and acpi_bus.h can only be used in ACPI case, so this patch add the stub function to linux/acpi.h to

[PATCH v4 net-next 01/13] ACPI: bus: add stub acpi_dev_found() to linux/acpi.h

From: Kejian Yan acpi_dev_found() will be used to detect if a given ACPI device is in the system. It will be compiled in non-ACPI case, but the function is in acpi_bus.h and acpi_bus.h can only be used in ACPI case, so this patch add the stub function to linux/acpi.h to make compiled

[PATCH v4 net-next 13/13] net: hns: net: hns: enet adds support of acpi

From: Kejian Yan Enet needs to get configration parameter by acpi. This patch adds support of ACPI for enet. The configuration parameter will be configed in BIOS. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- change log: v2: 1. use acpi_dev_found() instead of

[PATCH v4 net-next 02/13] ACPI: bus: add stub acpi_evaluate_dsm() to linux/acpi.h

From: Kejian Yan acpi_evaluate_dsm() will be used to handle the _DSM method in ACPI case. It will be compiled in non-ACPI case, but the function is in acpi_bus.h and acpi_bus.h can only be used in ACPI case, so this patch add the stub function to linux/acpi.h to make

[PATCH v4 net-next 02/13] ACPI: bus: add stub acpi_evaluate_dsm() to linux/acpi.h

From: Kejian Yan acpi_evaluate_dsm() will be used to handle the _DSM method in ACPI case. It will be compiled in non-ACPI case, but the function is in acpi_bus.h and acpi_bus.h can only be used in ACPI case, so this patch add the stub function to linux/acpi.h to make compiled successfully in

[PATCH v4 net-next 05/13] net: hns: use device_* APIs instead of of_* APIs

From: Kejian Yan OF series functions can be used only for DT case. Use unified device property function instead to support both DT and ACPI. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang ---

[PATCH v4 net-next 05/13] net: hns: use device_* APIs instead of of_* APIs

From: Kejian Yan OF series functions can be used only for DT case. Use unified device property function instead to support both DT and ACPI. Signed-off-by: Kejian Yan Signed-off-by: Yisen Zhuang --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 9 +

Re: [RESEND PATCH v2 0/6] vfio-pci: Add support for mmapping MSI-X table

Hi, Alex On 2016/6/2 21:11, Alex Williamson wrote: AFAICT, you posted this *3* days ago, has something changed here or is this just expedited nagging for review? This also depends on a non-upstream series and crosses multiple functional areas, all of which make it difficult for maintainers to

Re: [RESEND PATCH v2 0/6] vfio-pci: Add support for mmapping MSI-X table

Hi, Alex On 2016/6/2 21:11, Alex Williamson wrote: AFAICT, you posted this *3* days ago, has something changed here or is this just expedited nagging for review? This also depends on a non-upstream series and crosses multiple functional areas, all of which make it difficult for maintainers to

Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote: >Hi, > >On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote: >> FYI, we noticed pixz.throughput -9.1% regression due to commit: >> >> commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd >> watermarks in

Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote: >Hi, > >On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote: >> FYI, we noticed pixz.throughput -9.1% regression due to commit: >> >> commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd >> watermarks in

[UPDATE PATCH] ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC

(Email addresses in the SOB section are fixed) According to the Windows probing result, during the table loading, the EC device described in the ECDT should be used. And the ECDT EC is also effective during the period the namespace objects are initialized (we can see a separate process executing

[UPDATE PATCH] ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC

(Email addresses in the SOB section are fixed) According to the Windows probing result, during the table loading, the EC device described in the ECDT should be used. And the ECDT EC is also effective during the period the namespace objects are initialized (we can see a separate process executing

Re: [RESEND v2] power: reset: keystone: Enable COMPILE_TEST

Hi, On Mon, May 23, 2016 at 08:12:31AM +0200, Krzysztof Kozlowski wrote: > On Fri, Apr 15, 2016 at 4:27 PM, Sebastian Reichel wrote: > > Hi, > > > > On Wed, Mar 30, 2016 at 09:49:48AM +0900, Krzysztof Kozlowski wrote: > >> Enable the COMPILE_TEST to get build coverage, except on

Re: [RESEND v2] power: reset: keystone: Enable COMPILE_TEST

Hi, On Mon, May 23, 2016 at 08:12:31AM +0200, Krzysztof Kozlowski wrote: > On Fri, Apr 15, 2016 at 4:27 PM, Sebastian Reichel wrote: > > Hi, > > > > On Wed, Mar 30, 2016 at 09:49:48AM +0900, Krzysztof Kozlowski wrote: > >> Enable the COMPILE_TEST to get build coverage, except on platforms > >>

Good News

You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact (qpedro...@gmail.com) for claims.

Good News

You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact (qpedro...@gmail.com) for claims.

RE: [Linaro-mm-sig] [RFC][PATCH 1/3] staging: ion: Move away from the DMA APIs for cache flushing

Hi Laura, It seems that outer cache is needed to be handled after __cpuc_flush_dcache_area() for ARM platform. Please correct me if I am wrong. Thanks Xiaoquan -Original Message- From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf Of Laura Abbott Sent:

RE: [Linaro-mm-sig] [RFC][PATCH 1/3] staging: ion: Move away from the DMA APIs for cache flushing

Hi Laura, It seems that outer cache is needed to be handled after __cpuc_flush_dcache_area() for ARM platform. Please correct me if I am wrong. Thanks Xiaoquan -Original Message- From: Linaro-mm-sig [mailto:linaro-mm-sig-boun...@lists.linaro.org] On Behalf Of Laura Abbott Sent:

Re: [PATCH 1/3] iio: adc: ina3221: Add DT binding details

On Wed, Jun 01, 2016 at 06:04:12PM +0530, Laxman Dewangan wrote: > The INA3221 is a three-channel, high-side current and bus voltage monitor > with an I2C interface from Texas Instruments. The INA3221 monitors both > shunt voltage drops and bus supply voltages in addition to having > programmable

[PATCH] mm: add NR_ZSMALLOC to vmstat

Now, zram is very popular for some of embedded world(e.g., TV, mobile phone). On those system, zsmalloc consumed memory size is never trivial (one of example from real product system, total memory: 800M, zsmalloc consumed: 150M), so we have used this out of tree patch to monitor system memory

Re: [PATCH 1/3] iio: adc: ina3221: Add DT binding details

On Wed, Jun 01, 2016 at 06:04:12PM +0530, Laxman Dewangan wrote: > The INA3221 is a three-channel, high-side current and bus voltage monitor > with an I2C interface from Texas Instruments. The INA3221 monitors both > shunt voltage drops and bus supply voltages in addition to having > programmable

[PATCH] mm: add NR_ZSMALLOC to vmstat

Now, zram is very popular for some of embedded world(e.g., TV, mobile phone). On those system, zsmalloc consumed memory size is never trivial (one of example from real product system, total memory: 800M, zsmalloc consumed: 150M), so we have used this out of tree patch to monitor system memory

Re: [PATCH] hwmon: ina2xx: Document compatible for INA231

On Wed, Jun 01, 2016 at 11:43:12AM +0200, Krzysztof Kozlowski wrote: > Document the compatible for INA231 sensor. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/hwmon/ina2xx.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob

Re: [PATCH] hwmon: ina2xx: Document compatible for INA231

On Wed, Jun 01, 2016 at 11:43:12AM +0200, Krzysztof Kozlowski wrote: > Document the compatible for INA231 sensor. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/hwmon/ina2xx.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote: > Some devices need real hard-reset by cutting the power. During power > sequence turn off and on the regulator, if it is provided. > > Additionally add support for instantiating the pwrseq-simple device on a > generic property

Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote: > Some devices need real hard-reset by cutting the power. During power > sequence turn off and on the regulator, if it is provided. > > Additionally add support for instantiating the pwrseq-simple device on a > generic property

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

On Thu, Jun 02, 2016 at 06:32:42PM +, mario_limoncie...@dell.com wrote: > > And you want to check this for all Dell devices? Please be model > > specific, I doubt a bunch of Dell servers wants to run this code... > > > > Tracking model specific is really going to turn into a giant list

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

On Thu, Jun 02, 2016 at 06:32:42PM +, mario_limoncie...@dell.com wrote: > > And you want to check this for all Dell devices? Please be model > > specific, I doubt a bunch of Dell servers wants to run this code... > > > > Tracking model specific is really going to turn into a giant list

Re: [PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

On Wed, Jun 01, 2016 at 12:29:59PM +0800, Wenyou Yang wrote: > In order to the save power consumption, as a workaround, suspend > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI > Interrupt Configuration Register in the SFRs while OHCI USB suspend. > > This suspend operation

Re: [PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

On Wed, Jun 01, 2016 at 12:29:59PM +0800, Wenyou Yang wrote: > In order to the save power consumption, as a workaround, suspend > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI > Interrupt Configuration Register in the SFRs while OHCI USB suspend. > > This suspend operation

Re: [PATCH v2] mtd: brcmnand: Add v7.2 controller support

On Tue, May 31, 2016 at 10:23:02AM -0700, Florian Fainelli wrote: > The 7.2 controller differs in a few area compared to its predecssor (7.1): > > - NAND scrambler, which we are not using just yet > - higher ECC levels (up to 120 bits) per 1KB data blocks, also not supported > yet > - up to 128B

Re: [PATCH v2] mtd: brcmnand: Add v7.2 controller support

On Tue, May 31, 2016 at 10:23:02AM -0700, Florian Fainelli wrote: > The 7.2 controller differs in a few area compared to its predecssor (7.1): > > - NAND scrambler, which we are not using just yet > - higher ECC levels (up to 120 bits) per 1KB data blocks, also not supported > yet > - up to 128B

Re: [PATCH v2 6/7] Binding:PHY: Binding doc for NS2 PCIe PHYs.

On Tue, May 31, 2016 at 07:06:40PM +0530, Pramod Kumar wrote: > Binding doc for NS2 PCIe PHYs. > > Signed-off-by: Jon Mason > Signed-off-by: Pramod Kumar > --- > .../bindings/phy/brcm,mdio-mux-bus-pci.txt | 27 > ++

Re: [PATCH v2 6/7] Binding:PHY: Binding doc for NS2 PCIe PHYs.

On Tue, May 31, 2016 at 07:06:40PM +0530, Pramod Kumar wrote: > Binding doc for NS2 PCIe PHYs. > > Signed-off-by: Jon Mason > Signed-off-by: Pramod Kumar > --- > .../bindings/phy/brcm,mdio-mux-bus-pci.txt | 27 > ++ > 1 file changed, 27 insertions(+) > create mode

Re: [PATCH v2 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer

On Tue, May 31, 2016 at 07:06:37PM +0530, Pramod Kumar wrote: > Add DT binding doc for Broadcom MDIO bus mutiplexer driver. > > Signed-off-by: Pramod Kumar > --- > .../bindings/net/brcm,mdio-mux-iproc.txt | 60 > ++ > 1 file changed, 60

Re: [PATCH v2 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer

On Tue, May 31, 2016 at 07:06:37PM +0530, Pramod Kumar wrote: > Add DT binding doc for Broadcom MDIO bus mutiplexer driver. > > Signed-off-by: Pramod Kumar > --- > .../bindings/net/brcm,mdio-mux-iproc.txt | 60 > ++ > 1 file changed, 60 insertions(+) > create

Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On Friday, June 03, 2016 05:31:34 AM Viresh Kumar wrote: > On 02-06-16, 22:35, Rafael J. Wysocki wrote: > > Quoting from this very cover letter "This change allows us to remove > > the (duplicate) sorted-freq-table, which > > was added by following series:", so why to add it in the first place? >

Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On Friday, June 03, 2016 05:31:34 AM Viresh Kumar wrote: > On 02-06-16, 22:35, Rafael J. Wysocki wrote: > > Quoting from this very cover letter "This change allows us to remove > > the (duplicate) sorted-freq-table, which > > was added by following series:", so why to add it in the first place? >

[PATCH net] ethernet/sfc: report supported link speeds on SFP connections

My solarflare cards connected to a 10GbE switch with an SFP+ module/cable don't currently report any supported link speeds: $ ethtool ens4f0 Settings for ens4f0: Supported ports: [ FIBRE ] Supported link modes: Not reported Supported pause frame use: Symmetric

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

On Fri, 2016-06-03 at 11:32 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote: > > > > Base code to enable qspinlock on powerpc. this patch add some > > #ifdef > > here and there. Although there is no paravirt related code, we can > > successfully build a

[PATCH net] ethernet/sfc: report supported link speeds on SFP connections

My solarflare cards connected to a 10GbE switch with an SFP+ module/cable don't currently report any supported link speeds: $ ethtool ens4f0 Settings for ens4f0: Supported ports: [ FIBRE ] Supported link modes: Not reported Supported pause frame use: Symmetric

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

On Fri, 2016-06-03 at 11:32 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote: > > > > Base code to enable qspinlock on powerpc. this patch add some > > #ifdef > > here and there. Although there is no paravirt related code, we can > > successfully build a

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote: > Base code to enable qspinlock on powerpc. this patch add some #ifdef > here and there. Although there is no paravirt related code, we can > successfully build a qspinlock kernel after apply this patch. This is missing the IO_SYNC stuff ... It

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote: > Base code to enable qspinlock on powerpc. this patch add some #ifdef > here and there. Although there is no paravirt related code, we can > successfully build a qspinlock kernel after apply this patch. This is missing the IO_SYNC stuff ... It

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On (06/03/16 10:00), Sergey Senozhatsky wrote: > a good find by Vlastimil. > > Ebru, can you also re-visit __collapse_huge_page_swapin()? it's called > from collapse_huge_page() under the down_read(>mmap_sem), is there > any reason to do the nested down_read(>mmap_sem)? > > collapse_huge_page()

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On (06/03/16 10:00), Sergey Senozhatsky wrote: > a good find by Vlastimil. > > Ebru, can you also re-visit __collapse_huge_page_swapin()? it's called > from collapse_huge_page() under the down_read(>mmap_sem), is there > any reason to do the nested down_read(>mmap_sem)? > > collapse_huge_page()

[RESEND] [PATCH] mm: Do not discard partial pages with POSIX_FADV_DONTNEED

From: Oleg Drokin I noticed that if the logic in fadvise64_64 syscall is incorrect for partial pages. While first page of the region is correctly skipped if it is partial, the last page of the region is mistakenly discarded. This leads to problems for applications that read

Re: [PATCH 2/2] clk: rockchip: remove ROCKCHIP_SOFTRST_HIWORD_MASK for rockchip platform

Hi Shawn, On 2016年06月03日 08:54, Shawn Lin wrote: I check all the Socs including RK2928/3000/3066/3028X/316X/312X/ 3190/3188/3228/3368/3399/3036, and find all of them use high 16-bit as write mask. Obviously we don't need ROCKCHIP_SOFTRST_HIWORD_MASK any more(actually I don't know why we need it

[RESEND] [PATCH] mm: Do not discard partial pages with POSIX_FADV_DONTNEED

From: Oleg Drokin I noticed that if the logic in fadvise64_64 syscall is incorrect for partial pages. While first page of the region is correctly skipped if it is partial, the last page of the region is mistakenly discarded. This leads to problems for applications that read data in

Re: [PATCH 2/2] clk: rockchip: remove ROCKCHIP_SOFTRST_HIWORD_MASK for rockchip platform

Hi Shawn, On 2016年06月03日 08:54, Shawn Lin wrote: I check all the Socs including RK2928/3000/3066/3028X/316X/312X/ 3190/3188/3228/3368/3399/3036, and find all of them use high 16-bit as write mask. Obviously we don't need ROCKCHIP_SOFTRST_HIWORD_MASK any more(actually I don't know why we need it

[PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is attached to the EC, rather than the main host SoC. The API provides functionality-based (e.g., keyboard light, backlight) or index-based addressing of the PWM(s). Duty cycles are represented by a 16-bit value, where 0 maps to

[PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is attached to the EC, rather than the main host SoC. The API provides functionality-based (e.g., keyboard light, backlight) or index-based addressing of the PWM(s). Duty cycles are represented by a 16-bit value, where 0 maps to

<    1   2   3   4   5   6   7   8   9   10   >