Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Am 29.03.2016 um 23:43 schrieb Pavel Machek: > Hi! > >>> First, please Cc me on RGB color support. >>> Add generic support for RGB Color LED's. Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Am 29.03.2016 um 23:43 schrieb Pavel Machek: > Hi! > >>> First, please Cc me on RGB color support. >>> Add generic support for RGB Color LED's. Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color

[lkp] [mm] 39a1aa8e19: will-it-scale.per_process_ops +5.2% improvement

FYI, we noticed that will-it-scale.per_process_ops +5.2% improvement with your commit. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 39a1aa8e194ab67983de3b9d0b204ccee12e689a ("mm: deduplicate memory overcommitment code")

[lkp] [mm] 39a1aa8e19: will-it-scale.per_process_ops +5.2% improvement

FYI, we noticed that will-it-scale.per_process_ops +5.2% improvement with your commit. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 39a1aa8e194ab67983de3b9d0b204ccee12e689a ("mm: deduplicate memory overcommitment code")

[lkp] [drm/i915] 946ec703e5: No primary change, piglit.time.elapsed_time -59.2% improvement

linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/linux-headers.cgz" repeat_to: 2 kernel: "/pkg/linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/vmlinuz-4.5.0-rc7-01401-g946ec70" dequeue_time: 2016-03-30 07:50:42.174878631 +08:00 job_state: finished l

[lkp] [drm/i915] 946ec703e5: No primary change, piglit.time.elapsed_time -59.2% improvement

linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/linux-headers.cgz" repeat_to: 2 kernel: "/pkg/linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/vmlinuz-4.5.0-rc7-01401-g946ec70" dequeue_time: 2016-03-30 07:50:42.174878631 +08:00 job_state: finished l

[PATCH] tpm: remove redundant code from self-test functions

Self-test functions construct PCR read calls by ad hoc, which is only a waste space. Use instead tpm_pcr_read_dev (renamed as tpm1_pcr_read() by this commit) in tpm_do_selftest and tpm2_pcr_read() in tpm2_do_selftest() functions in order to remove the duplicate code. Patch can be tested easily

[PATCH] tpm: remove redundant code from self-test functions

Self-test functions construct PCR read calls by ad hoc, which is only a waste space. Use instead tpm_pcr_read_dev (renamed as tpm1_pcr_read() by this commit) in tpm_do_selftest and tpm2_pcr_read() in tpm2_do_selftest() functions in order to remove the duplicate code. Patch can be tested easily

Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data

On 30-03-16, 04:00, Rafael J. Wysocki wrote: > +static int sugov_init(struct cpufreq_policy *policy) > +{ > + struct sugov_policy *sg_policy; > + struct sugov_tunables *tunables; > + unsigned int lat; > + int ret = 0; > + > + /* State should be equivalent to EXIT */ > + if

Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data

On 30-03-16, 04:00, Rafael J. Wysocki wrote: > +static int sugov_init(struct cpufreq_policy *policy) > +{ > + struct sugov_policy *sg_policy; > + struct sugov_tunables *tunables; > + unsigned int lat; > + int ret = 0; > + > + /* State should be equivalent to EXIT */ > + if

Re: [PATCH 06/16] wcn36xx: Fetch private sta data from sta entry instead of from vif

Bjorn Andersson writes: >> All error/warnings (new ones prefixed by >>): >> >>drivers/net/wireless/ath/wcn36xx/main.c: In function 'wcn36xx_set_key': >> >> drivers/net/wireless/ath/wcn36xx/main.c:389:9: error: implicit >> >> declaration of function

Re: [PATCH 06/16] wcn36xx: Fetch private sta data from sta entry instead of from vif

Bjorn Andersson writes: >> All error/warnings (new ones prefixed by >>): >> >>drivers/net/wireless/ath/wcn36xx/main.c: In function 'wcn36xx_set_key': >> >> drivers/net/wireless/ath/wcn36xx/main.c:389:9: error: implicit >> >> declaration of function 'wcn36xx_sta_to_priv' >> >>

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

On 30/03/2016 1:01 PM, Yong Li wrote: Or another method is using the below to convert the u8 to u16: cpu_to_le16(get_unaligned((u16 *) val)), compared with the i2c_smbus_write_byte_data method, which one is better? G'day Yong, I'd go with the cpu_to_le16(get_unaligned((u16 *) val)) --

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

On 30/03/2016 1:01 PM, Yong Li wrote: Or another method is using the below to convert the u8 to u16: cpu_to_le16(get_unaligned((u16 *) val)), compared with the i2c_smbus_write_byte_data method, which one is better? G'day Yong, I'd go with the cpu_to_le16(get_unaligned((u16 *) val)) --

Re: [GIT PULL] bcm2835 clk changes for 4.6 maybe

Stephen Boyd writes: > On 03/17, Eric Anholt wrote: >> This is late, so feel free to drop it, but I figured I'd send it to >> you in case you were still open to merges. I've pounded on it a bit >> today (modesets to all sorts of resolutions on HDMI, used it for >> testing

Re: [GIT PULL] bcm2835 clk changes for 4.6 maybe

Stephen Boyd writes: > On 03/17, Eric Anholt wrote: >> This is late, so feel free to drop it, but I figured I'd send it to >> you in case you were still open to merges. I've pounded on it a bit >> today (modesets to all sorts of resolutions on HDMI, used it for >> testing the DPI panel support

Re: [Update][PATCH v7 6/7] cpufreq: Support for fast frequency switching

On 30-03-16, 03:47, Rafael J. Wysocki wrote: > Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c > @@ -843,6 +883,7 @@ static int acpi_cpufreq_cpu_exit(struct > pr_debug("acpi_cpufreq_cpu_exit\n"); > > if (data) { > + policy->fast_switch_possible = false; Is this done just

Re: [Update][PATCH v7 6/7] cpufreq: Support for fast frequency switching

On 30-03-16, 03:47, Rafael J. Wysocki wrote: > Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c > @@ -843,6 +883,7 @@ static int acpi_cpufreq_cpu_exit(struct > pr_debug("acpi_cpufreq_cpu_exit\n"); > > if (data) { > + policy->fast_switch_possible = false; Is this done just

Re: [PATCH v2 0/6] MIPS seccomp_bpf self test and fixups

On Tue, Mar 29, 2016 at 1:35 AM, Matt Redfearn wrote: > These patches imporve seccomp support on MIPS. > > Firstly support is added for building the seccomp_bpf self test for > MIPS. The > initial results of these tests were: > > 32bit kernel O32 userspace before: 48 /

Re: [PATCH v2 0/6] MIPS seccomp_bpf self test and fixups

On Tue, Mar 29, 2016 at 1:35 AM, Matt Redfearn wrote: > These patches imporve seccomp support on MIPS. > > Firstly support is added for building the seccomp_bpf self test for > MIPS. The > initial results of these tests were: > > 32bit kernel O32 userspace before: 48 / 48 pass > 64bit kernel O32

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

Or another method is using the below to convert the u8 to u16: cpu_to_le16(get_unaligned((u16 *) val)), compared with the i2c_smbus_write_byte_data method, which one is better? Thanks, Yong 2016-03-30 10:43 GMT+08:00 Yong Li : > If use the get_unaligned, below is the code

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

Or another method is using the below to convert the u8 to u16: cpu_to_le16(get_unaligned((u16 *) val)), compared with the i2c_smbus_write_byte_data method, which one is better? Thanks, Yong 2016-03-30 10:43 GMT+08:00 Yong Li : > If use the get_unaligned, below is the code example, but we cannot

[lkp] [x86/mm] 729ed6fc97: BUG: spinlock bad magic on CPU#0, v86d/194

FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/pcid commit 729ed6fc971182a09c0869dbf8007ae5e538a04a ("x86/mm: Hold a spinlock when propagating TLB flushes") As below, the log "BUG: spinlock bad magic on CPU#0, v86d/194" showed with your

[lkp] [x86/mm] 729ed6fc97: BUG: spinlock bad magic on CPU#0, v86d/194

FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/pcid commit 729ed6fc971182a09c0869dbf8007ae5e538a04a ("x86/mm: Hold a spinlock when propagating TLB flushes") As below, the log "BUG: spinlock bad magic on CPU#0, v86d/194" showed with your

[PATCH] mm/highmem: simplify is_highmem()

The is_highmem() is can be simplified by use of is_highmem_idx(). This patch removes redundant code and will make it easier to maintain if the zone policy is changed or a new zone is added. Signed-off-by: Chanho Min --- include/linux/mmzone.h |5 + 1 file changed, 1

[PATCH] mm/highmem: simplify is_highmem()

The is_highmem() is can be simplified by use of is_highmem_idx(). This patch removes redundant code and will make it easier to maintain if the zone policy is changed or a new zone is added. Signed-off-by: Chanho Min --- include/linux/mmzone.h |5 + 1 file changed, 1 insertion(+), 4

[PATCH] cpufreq: acpi: policy->driver_data can't be NULL in ->exit()

Its always set by ->init() and so it will always be there in ->exit(). There is no need to have a special check for just that. Signed-off-by: Viresh Kumar --- drivers/cpufreq/acpi-cpufreq.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git

[PATCH] cpufreq: acpi: policy->driver_data can't be NULL in ->exit()

Its always set by ->init() and so it will always be there in ->exit(). There is no need to have a special check for just that. Signed-off-by: Viresh Kumar --- drivers/cpufreq/acpi-cpufreq.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git

Re: [PATCH 2/2] mfd: remove dependency on HAS_IOMEM

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring wrote: > Lots of drivers select MFD_SYSCON which depends on HAS_IOMEM and causes > this kbuild warning if HAS_IOMEM is not enabled: > > warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && > DWMAC_ROCKCHIP &&

Re: [PATCH 2/2] mfd: remove dependency on HAS_IOMEM

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring wrote: > Lots of drivers select MFD_SYSCON which depends on HAS_IOMEM and causes > this kbuild warning if HAS_IOMEM is not enabled: > > warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && > DWMAC_ROCKCHIP && DWMAC_SOCFPGA &&

Re: [PATCH v2 1/5] block, dax: pass blk_dax_ctl through to drivers

Hi Dan, [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] [also build test ERROR on v4.6-rc1 next-20160329] [cannot apply to xfs/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 1/5] block, dax: pass blk_dax_ctl through to drivers

Hi Dan, [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] [also build test ERROR on v4.6-rc1 next-20160329] [cannot apply to xfs/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux

Re: [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring wrote: > Drivers shouldn't have to care about HAS_IOMEM to compile and having to > causes a Kconfig mess: > > warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) > selects I2C_MUX which has unmet direct dependencies

Re: [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring wrote: > Drivers shouldn't have to care about HAS_IOMEM to compile and having to > causes a Kconfig mess: > > warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) > selects I2C_MUX which has unmet direct dependencies (I2C &&

Re: [PATCH 1/8] phy: Fix phy-hi6220-usb dependencies

On Sat, Mar 26, 2016 at 7:40 AM, Richard Weinberger wrote: > This driver needs io memory. > > Fixes the following Kconfig warning: > warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && > DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW &&

Re: [PATCH 1/8] phy: Fix phy-hi6220-usb dependencies

On Sat, Mar 26, 2016 at 7:40 AM, Richard Weinberger wrote: > This driver needs io memory. > > Fixes the following Kconfig warning: > warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && > DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP > &&

[PATCH v2] sched/fair: Initiate a new task's util avg to a bounded value

Hi Peter, It looks like this patch is left last year. I fixed a bug - it did not init task group's entities. And I started this new thread to attend to it. Please refer to the link for the previous version and some data experimented: http://article.gmane.org/gmane.linux.kernel/2117689 Would

[PATCH v2] sched/fair: Initiate a new task's util avg to a bounded value

Hi Peter, It looks like this patch is left last year. I fixed a bug - it did not init task group's entities. And I started this new thread to attend to it. Please refer to the link for the previous version and some data experimented: http://article.gmane.org/gmane.linux.kernel/2117689 Would

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

On 29-03-16, 14:58, Rafael J. Wysocki wrote: > On Monday, March 28, 2016 02:33:33 PM Viresh Kumar wrote: > > Its gonna be same for all policies sharing tunables .. > > The value will be the same, but the cacheline won't. Fair enough. So this information is replicated for each policy for

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

On 29-03-16, 14:58, Rafael J. Wysocki wrote: > On Monday, March 28, 2016 02:33:33 PM Viresh Kumar wrote: > > Its gonna be same for all policies sharing tunables .. > > The value will be the same, but the cacheline won't. Fair enough. So this information is replicated for each policy for

Re: [PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

On 30.03.2016 11:19, Andy Yan wrote: > Add device tree bindings document for reboot-mode driver. > > Signed-off-by: Andy Yan > Acked-by: Rob Herring > > --- > > Changes in v7: > - fix some spelling mistakes > - declare that the mode magic should be

Re: [PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

On 30.03.2016 11:19, Andy Yan wrote: > Add device tree bindings document for reboot-mode driver. > > Signed-off-by: Andy Yan > Acked-by: Rob Herring > > --- > > Changes in v7: > - fix some spelling mistakes > - declare that the mode magic should be none-zero value > > Changes in v6: > - fix

Re: [PATCH v7 2/4] power: reset: add reboot mode driver

On 30.03.2016 11:20, Andy Yan wrote: > This driver parses the reboot commands like "reboot bootloader" > and "reboot recovery" to get a boot mode described in the > device tree , then call the write interfae to store the boot > mode in some place like special register or sram, which can > be read

Re: [PATCH v7 2/4] power: reset: add reboot mode driver

On 30.03.2016 11:20, Andy Yan wrote: > This driver parses the reboot commands like "reboot bootloader" > and "reboot recovery" to get a boot mode described in the > device tree , then call the write interfae to store the boot > mode in some place like special register or sram, which can > be read

Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210

Hi Thierry & Stephen, The driver patches in this series were taken by Eduardo, so do know who can take these tow dts patches 13 and 14? Thanks. Wei. On 2016年03月29日 23:16, Eduardo Valentin wrote: > On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote: >> Adds soctherm node for Tegra210, and add

Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210

Hi Thierry & Stephen, The driver patches in this series were taken by Eduardo, so do know who can take these tow dts patches 13 and 14? Thanks. Wei. On 2016年03月29日 23:16, Eduardo Valentin wrote: > On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote: >> Adds soctherm node for Tegra210, and add

Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

On 29-03-16, 21:45, Arnd Bergmann wrote: > Regarding new platforms, I'd hope that we could manage to define an extension > to the oppv2 binding that marks a machine as compatible with opp, so we can The extension of oppv2 binding or compatible string is for platforms that really need extend oppv2

Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

On 29-03-16, 21:45, Arnd Bergmann wrote: > Regarding new platforms, I'd hope that we could manage to define an extension > to the oppv2 binding that marks a machine as compatible with opp, so we can The extension of oppv2 binding or compatible string is for platforms that really need extend oppv2

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

Hi Vishal, [auto build test WARNING on linux-nvdimm/libnvdimm-for-next] [also build test WARNING on v4.6-rc1 next-20160329] [cannot apply to xfs/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

Hi Vishal, [auto build test WARNING on linux-nvdimm/libnvdimm-for-next] [also build test WARNING on v4.6-rc1 next-20160329] [cannot apply to xfs/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Hi, On 03/29/2016 06:49 PM, kbuild test robot wrote: > Hi Tadeusz, > > [auto build test ERROR on v4.6-rc1] > [also build test ERROR on next-20160329] > [cannot apply to crypto/master] > [if your patch is applied to the wrong git tree, please drop us a note to > help

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Hi, On 03/29/2016 06:49 PM, kbuild test robot wrote: > Hi Tadeusz, > > [auto build test ERROR on v4.6-rc1] > [also build test ERROR on next-20160329] > [cannot apply to crypto/master] > [if your patch is applied to the wrong git tree, please drop us a note to > help

Re: [PATCH v3 0/4] thermal: hisilicon: enable power allocator for Hi6220

On Tue, Mar 29, 2016 at 08:45:59AM -0700, Eduardo Valentin wrote: > On Tue, Mar 29, 2016 at 07:27:11PM +0800, Leo Yan wrote: > > Hi6220 has octa-core so it has quite high power consumption when run > > benchmark and introduces high temperature for SoC. So need enable > > thermal governor to

Re: [PATCH v3 0/4] thermal: hisilicon: enable power allocator for Hi6220

On Tue, Mar 29, 2016 at 08:45:59AM -0700, Eduardo Valentin wrote: > On Tue, Mar 29, 2016 at 07:27:11PM +0800, Leo Yan wrote: > > Hi6220 has octa-core so it has quite high power consumption when run > > benchmark and introduces high temperature for SoC. So need enable > > thermal governor to

RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

> -Original Message- > From: Baolin Wang [mailto:baolin.w...@linaro.org] > Sent: Tuesday, March 29, 2016 5:49 PM > To: Jun Li > Cc: Peter Chen ; Felipe Balbi ; > Greg KH ; Sebastian Reichel

Re: [PATCH v2 2/2] ASoC: codecs: add support for TAS5720 digital amplifier

Hi Mark, thanks for taking time reviewing the driver. Some comments below... On Mon, Mar 28, 2016 at 08:01:43PM +0100, Mark Brown wrote: > On Mon, Mar 21, 2016 at 12:08:27PM -0500, Andreas Dannenberg wrote: > > > +static int tas5720_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id, > > +

RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

> -Original Message- > From: Baolin Wang [mailto:baolin.w...@linaro.org] > Sent: Tuesday, March 29, 2016 5:49 PM > To: Jun Li > Cc: Peter Chen ; Felipe Balbi ; > Greg KH ; Sebastian Reichel ; > Dmitry Eremin-Solenikov ; David Woodhouse > ; Peter Chen ; Alan Stern > ;

Re: [PATCH v2 2/2] ASoC: codecs: add support for TAS5720 digital amplifier

Hi Mark, thanks for taking time reviewing the driver. Some comments below... On Mon, Mar 28, 2016 at 08:01:43PM +0100, Mark Brown wrote: > On Mon, Mar 21, 2016 at 12:08:27PM -0500, Andreas Dannenberg wrote: > > > +static int tas5720_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id, > > +

Re: [PATCH v2] thermal: add sysfs_notify on some attributes

On 03/28/2016 06:35 PM, Eduardo Valentin wrote: On Tue, Mar 15, 2016 at 11:08:00PM +, Pandruvada, Srinivas wrote: On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: Add a sysfs_notify on thermal_zone*/temp and cooling_device*/ cur_state whenever any trip is triggered or cur

Re: [PATCH v2] thermal: add sysfs_notify on some attributes

On 03/28/2016 06:35 PM, Eduardo Valentin wrote: On Tue, Mar 15, 2016 at 11:08:00PM +, Pandruvada, Srinivas wrote: On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: Add a sysfs_notify on thermal_zone*/temp and cooling_device*/ cur_state whenever any trip is triggered or cur

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Hi Tadeusz, [auto build test ERROR on v4.6-rc1] [also build test ERROR on next-20160329] [cannot apply to crypto/master] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Hi Tadeusz, [auto build test ERROR on v4.6-rc1] [also build test ERROR on next-20160329] [cannot apply to crypto/master] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

If use the get_unaligned, below is the code example, but we cannot detect if it is big endian or little endian. I would like to use the same write logic as PCA957X_TYPE: use the i2c_smbus_write_byte_data API to write two times. How do you think about it? if (big_endian) value =

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

If use the get_unaligned, below is the code example, but we cannot detect if it is big endian or little endian. I would like to use the same write logic as PCA957X_TYPE: use the i2c_smbus_write_byte_data API to write two times. How do you think about it? if (big_endian) value =

Re: [GIT PULL] Ceph fixes for -rc7

On Wed, Mar 30 2016, Yan, Zheng wrote: > On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown wrote: >> On Fri, Mar 25 2016, Ilya Dryomov wrote: >> >>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown wrote: On Sun, Mar 06 2016, Sage Weil wrote: > Hi Linus, >

Re: [GIT PULL] Ceph fixes for -rc7

On Wed, Mar 30 2016, Yan, Zheng wrote: > On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown wrote: >> On Fri, Mar 25 2016, Ilya Dryomov wrote: >> >>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown wrote: On Sun, Mar 06 2016, Sage Weil wrote: > Hi Linus, > > Please pull the following

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

On 2016/3/30 10:28, Wangnan (F) wrote: On 2016/3/29 22:04, Peter Zijlstra wrote: On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote: Could you maybe write a perf/tests thingy for this so that _some_ userspace exists that exercises this new code? int perf_output_begin(struct

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

On 2016/3/30 10:28, Wangnan (F) wrote: On 2016/3/29 22:04, Peter Zijlstra wrote: On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote: Could you maybe write a perf/tests thingy for this so that _some_ userspace exists that exercises this new code? int perf_output_begin(struct

Re: [PATCH] perf jit: genelf makes assumptions about endian

On Tue, 2016-03-29 at 17:59 +1100, Anton Blanchard wrote: > Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support") > incorrectly assumed that PowerPC is big endian only. > > Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking > for __BYTE_ORDER ==

Re: [PATCH] perf jit: genelf makes assumptions about endian

On Tue, 2016-03-29 at 17:59 +1100, Anton Blanchard wrote: > Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support") > incorrectly assumed that PowerPC is big endian only. > > Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking > for __BYTE_ORDER ==

Re: [GIT PULL] Ceph fixes for -rc7

On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown wrote: > On Fri, Mar 25 2016, Ilya Dryomov wrote: > >> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown wrote: >>> On Sun, Mar 06 2016, Sage Weil wrote: >>> Hi Linus, Please pull the following Ceph patch from

Re: [PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

Hi Duson, On Wed, Mar 30, 2016 at 10:02:02AM +0800, DusonLin wrote: > Only ABS_DISTANCE is not enough for upper OS to distiguish hover event > be triggered from object form faraway to and close touchpad surface or from > object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to

Re: [GIT PULL] Ceph fixes for -rc7

On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown wrote: > On Fri, Mar 25 2016, Ilya Dryomov wrote: > >> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown wrote: >>> On Sun, Mar 06 2016, Sage Weil wrote: >>> Hi Linus, Please pull the following Ceph patch from

Re: [PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

Hi Duson, On Wed, Mar 30, 2016 at 10:02:02AM +0800, DusonLin wrote: > Only ABS_DISTANCE is not enough for upper OS to distiguish hover event > be triggered from object form faraway to and close touchpad surface or from > object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

On 2016/3/29 22:04, Peter Zijlstra wrote: On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote: Could you maybe write a perf/tests thingy for this so that _some_ userspace exists that exercises this new code? int perf_output_begin(struct perf_output_handle *handle,

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

On 2016/3/29 22:04, Peter Zijlstra wrote: On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote: Could you maybe write a perf/tests thingy for this so that _some_ userspace exists that exercises this new code? int perf_output_begin(struct perf_output_handle *handle,

Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

On Wed, Mar 30, 2016 at 09:39:35AM +0800, Ming Lei wrote: > On Wed, Mar 30, 2016 at 12:42 AM, Shaohua Li wrote: > > bio_alloc_bioset() allocates bvecs from bvec_slabs which can only > > allocate maximum 256 bvec (eg, 1M for 4k pages). We can't bump > > BLK_DEF_MAX_SECTORS to exceed

Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

On Wed, Mar 30, 2016 at 09:39:35AM +0800, Ming Lei wrote: > On Wed, Mar 30, 2016 at 12:42 AM, Shaohua Li wrote: > > bio_alloc_bioset() allocates bvecs from bvec_slabs which can only > > allocate maximum 256 bvec (eg, 1M for 4k pages). We can't bump > > BLK_DEF_MAX_SECTORS to exceed this value

[PATCH v7 4/4] ARM64: dts: rockchip: add syscon-reboot-mode DT node

Add syscon-reboot-mode driver DT node for rk3368 platform Tested-by: Caesar Wang Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: - descirbe all reboot mode as

[PATCH v7 4/4] ARM64: dts: rockchip: add syscon-reboot-mode DT node

Add syscon-reboot-mode driver DT node for rk3368 platform Tested-by: Caesar Wang Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: - descirbe all reboot mode as property instead of subnode Changes in v2: - make this

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Hi Tadeusz, [auto build test ERROR on v4.6-rc1] [also build test ERROR on next-20160329] [cannot apply to crypto/master] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Hi Tadeusz, [auto build test ERROR on v4.6-rc1] [also build test ERROR on next-20160329] [cannot apply to crypto/master] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto

[PATCH v7 3/4] ARM: dts: rockchip: add syscon-reboot-mode DT node

Rockchip platform use a SYSCON mapped register store the reboot mode magic value for bootloader to use when system reboot. So add syscon-reboot-mode driver DT node for rk3xxx/rk3036/rk3288 based platform Reviewed-by: Matthias Brugger Signed-off-by: Andy Yan

[PATCH v7 3/4] ARM: dts: rockchip: add syscon-reboot-mode DT node

Rockchip platform use a SYSCON mapped register store the reboot mode magic value for bootloader to use when system reboot. So add syscon-reboot-mode driver DT node for rk3xxx/rk3036/rk3288 based platform Reviewed-by: Matthias Brugger Signed-off-by: Andy Yan --- Changes in v7: None Changes in

[PATCH v7 2/4] power: reset: add reboot mode driver

This driver parses the reboot commands like "reboot bootloader" and "reboot recovery" to get a boot mode described in the device tree , then call the write interfae to store the boot mode in some place like special register or sram, which can be read by the bootloader after system reboot, then the

[PATCH v7 2/4] power: reset: add reboot mode driver

This driver parses the reboot commands like "reboot bootloader" and "reboot recovery" to get a boot mode described in the device tree , then call the write interfae to store the boot mode in some place like special register or sram, which can be read by the bootloader after system reboot, then the

[PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

Add device tree bindings document for reboot-mode driver. Signed-off-by: Andy Yan Acked-by: Rob Herring --- Changes in v7: - fix some spelling mistakes - declare that the mode magic should be none-zero value Changes in v6: - fix a typo with

[PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

Add device tree bindings document for reboot-mode driver. Signed-off-by: Andy Yan Acked-by: Rob Herring --- Changes in v7: - fix some spelling mistakes - declare that the mode magic should be none-zero value Changes in v6: - fix a typo with "property" - describe property "mask" more clear

[PATCH v7 0/4] add reboot mode driver

This driver parses the reboot commands like "reboot bootloader" and "reboot recovery" to get a boot mode described in the device tree , then call the corresponding write interfae to store the boot mode in some place like special register or ram, which can be read by the bootloader after system

[PATCH v7 0/4] add reboot mode driver

This driver parses the reboot commands like "reboot bootloader" and "reboot recovery" to get a boot mode described in the device tree , then call the corresponding write interfae to store the boot mode in some place like special register or ram, which can be read by the bootloader after system

Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class

On March 30, 2016 8:28:21 AM GMT+09:00, Taeung Song wrote: >Hi, Arnaldo and Namhyung > >On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote: >> Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu: >>> This infrastructure code was designed for >>> upcoming

Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class

On March 30, 2016 8:28:21 AM GMT+09:00, Taeung Song wrote: >Hi, Arnaldo and Namhyung > >On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote: >> Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu: >>> This infrastructure code was designed for >>> upcoming features of perf-config.

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote: > On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote: > > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote: > > > > > I am afraid I still not find the user (udc driver) for this framework, > > > > I would > > > > like

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote: > On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote: > > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote: > > > > > I am afraid I still not find the user (udc driver) for this framework, > > > > I would > > > > like

[PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

Only ABS_DISTANCE is not enough for upper OS to distiguish hover event be triggered from object form faraway to and close touchpad surface or from object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help it. Object_at_faraway object_at_hover_area

[PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

Only ABS_DISTANCE is not enough for upper OS to distiguish hover event be triggered from object form faraway to and close touchpad surface or from object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help it. Object_at_faraway object_at_hover_area

[PATCH v2 0/5] dax: handling of media errors

Until now, dax has been disabled if media errors were found on any device. This series attempts to address that. The first three patches from Dan re-enable dax even when media errors are present. The fourth patch from Matthew removes the zeroout path from dax entirely, making zeroout operations

[PATCH v2 3/5] dax: enable dax in the presence of known media errors (badblocks)

From: Dan Williams 1/ If a mapping overlaps a bad sector fail the request. 2/ Do not opportunistically report more dax-capable capacity than is requested when errors present. [vishal: fix a conflict with system RAM collision patches] Signed-off-by: Dan Williams

[PATCH v2 0/5] dax: handling of media errors

Until now, dax has been disabled if media errors were found on any device. This series attempts to address that. The first three patches from Dan re-enable dax even when media errors are present. The fourth patch from Matthew removes the zeroout path from dax entirely, making zeroout operations

[PATCH v2 3/5] dax: enable dax in the presence of known media errors (badblocks)

From: Dan Williams 1/ If a mapping overlaps a bad sector fail the request. 2/ Do not opportunistically report more dax-capable capacity than is requested when errors present. [vishal: fix a conflict with system RAM collision patches] Signed-off-by: Dan Williams --- block/ioctl.c |

  1   2   3   4   5   6   7   8   9   10   >