Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > A recent patch removed many 'inline' annotations for static > functions in this file, which has caused warnings for functions > that are not used in a given configuration, in particular when > CONFIG_NF_CONNTRACK_EVENTS is disabled:

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > A recent patch removed many 'inline' annotations for static > functions in this file, which has caused warnings for functions > that are not used in a given configuration, in particular when > CONFIG_NF_CONNTRACK_EVENTS is disabled:

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

On Mon, 18 Apr 2016, Ralf Baechle wrote: > I extracted a rather simple test case: > > $ echo >> testcase .s << EOF > .setmips3 > dli $2, 0x90008000 > EOF > $ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s > testcase.s: Assembler messages: >

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

On Mon, 18 Apr 2016, Ralf Baechle wrote: > I extracted a rather simple test case: > > $ echo >> testcase .s << EOF > .setmips3 > dli $2, 0x90008000 > EOF > $ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s > testcase.s: Assembler messages: >

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:42:38AM -0700, John Stultz wrote: > On Mon, Apr 18, 2016 at 10:32 AM, Shaohua Li wrote: > > On Mon, Apr 18, 2016 at 10:05:22AM -0700, John Stultz wrote: > >> On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > >> > Calvin found 'perf record

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:42:38AM -0700, John Stultz wrote: > On Mon, Apr 18, 2016 at 10:32 AM, Shaohua Li wrote: > > On Mon, Apr 18, 2016 at 10:05:22AM -0700, John Stultz wrote: > >> On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > >> > Calvin found 'perf record -a --call-graph dwarf --

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On Mon, 2016-04-18 at 19:15 +0200, Sebastian Andrzej Siewior wrote: > take 2. There is this else case in pin_current_cpu() where I take > hp_lock. I didn't manage to get in there. So I *think* we can get rid of > the lock now. Since there is no lock (or will be) we can drop the whole >

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On Mon, 2016-04-18 at 19:15 +0200, Sebastian Andrzej Siewior wrote: > take 2. There is this else case in pin_current_cpu() where I take > hp_lock. I didn't manage to get in there. So I *think* we can get rid of > the lock now. Since there is no lock (or will be) we can drop the whole >

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:48 AM, Shaohua Li wrote: > On Mon, Apr 18, 2016 at 10:42:38AM -0700, John Stultz wrote: >> I'm sort of on the edge of just adding a blacklist entry for the HPET >> on this hardware. I'm not sure its something that can be easily >> handled generically. I

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:48 AM, Shaohua Li wrote: > On Mon, Apr 18, 2016 at 10:42:38AM -0700, John Stultz wrote: >> I'm sort of on the edge of just adding a blacklist entry for the HPET >> on this hardware. I'm not sure its something that can be easily >> handled generically. I *hope* you

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

Le lundi 18 avril 2016 à 16:22 +0800, tiffany lin a écrit : > > > We are plaining to remove m2m framework in th feature, although > we think > >  > > Remove it for just the decoder driver or both encoder and decoder? > >  > Remove it from decoder driver. Did you look at how CODA handle it

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

Le lundi 18 avril 2016 à 16:22 +0800, tiffany lin a écrit : > > > We are plaining to remove m2m framework in th feature, although > we think > >  > > Remove it for just the decoder driver or both encoder and decoder? > >  > Remove it from decoder driver. Did you look at how CODA handle it

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 11:40 AM, Christoph Hellwig wrote: > On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote: >> I was looking at the code. I don't see how removing virt_to_page + vmap >> would solve the issue. >> >> The code is trying to access the buffer space with direct.buf member >> from the

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 11:40 AM, Christoph Hellwig wrote: > On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote: >> I was looking at the code. I don't see how removing virt_to_page + vmap >> would solve the issue. >> >> The code is trying to access the buffer space with direct.buf member >> from the

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

On 4/18/16 1:20 PM, Florian Margaine wrote: > On Mon, 2016-04-18 at 11:20 -0400, Eric Sandeen wrote: >> > >> > On 4/14/16 10:17 PM, Dave Chinner wrote: >>> > > On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote: > > > This lets userland get the filesystem freezing status, aka

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

On 4/18/16 1:20 PM, Florian Margaine wrote: > On Mon, 2016-04-18 at 11:20 -0400, Eric Sandeen wrote: >> > >> > On 4/14/16 10:17 PM, Dave Chinner wrote: >>> > > On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote: > > > This lets userland get the filesystem freezing status, aka

Re: [PATCH v2 1/2] clk: bcm2835: Fix compiler warnings on 64-bit builds

Stephen Boyd writes: > On 04/13, Eric Anholt wrote: >> Signed-off-by: Eric Anholt >> --- > > Acked-by: Stephen Boyd > > Or can I merge this? It wasn't addressed To: me so who knows. Yeah, please merge it. signature.asc

Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On Monday 18 April 2016 11:01 PM, Jonathan Cameron wrote: On 18 April 2016 17:49:39 BST, Laxman Dewangan wrote: On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote: On 14/04/16 15:41, Laxman Dewangan wrote: +static int gadc_thermal_read_channel(struct

Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On Monday 18 April 2016 11:01 PM, Jonathan Cameron wrote: On 18 April 2016 17:49:39 BST, Laxman Dewangan wrote: On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote: On 14/04/16 15:41, Laxman Dewangan wrote: +static int gadc_thermal_read_channel(struct gadc_thermal_info *gti, int *val)

Re: [PATCH v2 1/2] clk: bcm2835: Fix compiler warnings on 64-bit builds

Stephen Boyd writes: > On 04/13, Eric Anholt wrote: >> Signed-off-by: Eric Anholt >> --- > > Acked-by: Stephen Boyd > > Or can I merge this? It wasn't addressed To: me so who knows. Yeah, please merge it. signature.asc Description: PGP signature

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:32 AM, Shaohua Li wrote: > On Mon, Apr 18, 2016 at 10:05:22AM -0700, John Stultz wrote: >> On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: >> > Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making >> > clocksource >> >

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:32 AM, Shaohua Li wrote: > On Mon, Apr 18, 2016 at 10:05:22AM -0700, John Stultz wrote: >> On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: >> > Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making >> > clocksource >> > switching to hpet. We found

Re: [patch -next] udp: fix if statement in SIOCINQ ioctl

From: Dan Carpenter Date: Mon, 18 Apr 2016 11:44:49 +0300 > We deleted a line of code and accidentally made the "return put_user()" > part of the if statement when it's supposed to be unconditional. > > Fixes: 9f9a45beaa96 ('udp: do not expect udp headers on ioctl

Re: [patch -next] udp: fix if statement in SIOCINQ ioctl

From: Dan Carpenter Date: Mon, 18 Apr 2016 11:44:49 +0300 > We deleted a line of code and accidentally made the "return put_user()" > part of the if statement when it's supposed to be unconditional. > > Fixes: 9f9a45beaa96 ('udp: do not expect udp headers on ioctl SIOCINQ') > Signed-off-by: Dan

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Mon, Apr 18, 2016 at 06:09:09AM -0700, Christoph Hellwig wrote: > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote: > > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote: > > > This patch series removes the write() interface for user access in favor > > > of an

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Mon, Apr 18, 2016 at 06:09:09AM -0700, Christoph Hellwig wrote: > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote: > > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote: > > > This patch series removes the write() interface for user access in favor > > > of an

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:05:22AM -0700, John Stultz wrote: > On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > > Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making > > clocksource > > switching to hpet. We found similar symptom in another machine. Here is an >

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 18, 2016 at 10:05:22AM -0700, John Stultz wrote: > On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > > Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making > > clocksource > > switching to hpet. We found similar symptom in another machine. Here is an > > example: >

Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On 18 April 2016 17:49:39 BST, Laxman Dewangan wrote: > >On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote: >> On 14/04/16 15:41, Laxman Dewangan wrote: >> +static int gadc_thermal_read_channel(struct gadc_thermal_info *gti, >int *val) >> +{ >> +int ret; >> + >>

Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On 18 April 2016 17:49:39 BST, Laxman Dewangan wrote: > >On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote: >> On 14/04/16 15:41, Laxman Dewangan wrote: >> +static int gadc_thermal_read_channel(struct gadc_thermal_info *gti, >int *val) >> +{ >> +int ret; >> + >> +ret =

Re: [RFC 2/2] time: double check if watchdog clocksource is correct

On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > We use watchdog clocksource to detect unstable clocksource. This assumes > watchdog clocksource is correct. But it's possible watchdog clocksource > is crappy, please see previous patch. Double check if watchdog interval > is too

Re: [RFC 2/2] time: double check if watchdog clocksource is correct

On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > We use watchdog clocksource to detect unstable clocksource. This assumes > watchdog clocksource is correct. But it's possible watchdog clocksource > is crappy, please see previous patch. Double check if watchdog interval > is too long and

[PATCH v11 0/4] Multi-instance vTPM proxy driver

The following series of patches implements a multi-instance vTPM proxy driver that can dynamically create TPM 'server' and client device pairs. Using an ioctl on the provided /dev/vtpmx, a client-side vTPM device and a server side file descriptor is created. The file descriptor must be passed to

[PATCH v11 0/4] Multi-instance vTPM proxy driver

The following series of patches implements a multi-instance vTPM proxy driver that can dynamically create TPM 'server' and client device pairs. Using an ioctl on the provided /dev/vtpmx, a client-side vTPM device and a server side file descriptor is created. The file descriptor must be passed to

[PATCH v11 1/4] tpm: Remove all uses of drvdata from the TPM Core

From: Jason Gunthorpe The final thing preventing this was the way the sysfs files were attached to the pdev. Follow the approach developed for ppi and move the sysfs files to the chip->dev with symlinks from the pdev for compatibility. Everything in the core now

[PATCH v11 1/4] tpm: Remove all uses of drvdata from the TPM Core

From: Jason Gunthorpe The final thing preventing this was the way the sysfs files were attached to the pdev. Follow the approach developed for ppi and move the sysfs files to the chip->dev with symlinks from the pdev for compatibility. Everything in the core now sanely uses container_of to get

[PATCH v11 4/4] tpm: Add documentation for the tpm_vtpm_proxy device driver

Add documentation for the tpm_vtpm device driver that implements support for providing TPM functionality to Linux containers. Parts of this documentation were recycled from the Xen vTPM device driver documentation. Update the documentation for the ioctl numbers. Signed-off-by: Stefan Berger

[PATCH v11 2/4] tpm: Introduce TPM_CHIP_FLAG_VIRTUAL

Introduce TPM_CHIP_FLAG_VIRTUAL to be used when the chip device has no parent device. Prevent sysfs entries requiring a parent device from being created. Signed-off-by: Stefan Berger Reviewed-by: Jason Gunthorpe ---

[PATCH v11 3/4] tpm: Proxy driver for supporting multiple emulated TPMs

This patch implements a proxy driver for supporting multiple emulated TPMs in a system. The driver implements a device /dev/vtpmx that is used to created a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that is accessed using a file descriptor returned by an ioctl. The device

[PATCH v11 4/4] tpm: Add documentation for the tpm_vtpm_proxy device driver

Add documentation for the tpm_vtpm device driver that implements support for providing TPM functionality to Linux containers. Parts of this documentation were recycled from the Xen vTPM device driver documentation. Update the documentation for the ioctl numbers. Signed-off-by: Stefan Berger

[PATCH v11 2/4] tpm: Introduce TPM_CHIP_FLAG_VIRTUAL

Introduce TPM_CHIP_FLAG_VIRTUAL to be used when the chip device has no parent device. Prevent sysfs entries requiring a parent device from being created. Signed-off-by: Stefan Berger Reviewed-by: Jason Gunthorpe --- drivers/char/tpm/tpm-chip.c | 7 +-- drivers/char/tpm/tpm.h | 1 + 2

[PATCH v11 3/4] tpm: Proxy driver for supporting multiple emulated TPMs

This patch implements a proxy driver for supporting multiple emulated TPMs in a system. The driver implements a device /dev/vtpmx that is used to created a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that is accessed using a file descriptor returned by an ioctl. The device

Re: [RESEND PATCH 1/3] power: charger-manager: Replace deprecatd API of extcon

On Fri, Apr 15, 2016 at 04:13:18PM +0200, Sebastian Reichel wrote: > Hi, > > On Fri, Apr 15, 2016 at 09:43:34AM +0900, Chanwoo Choi wrote: > > This patch removes the deprecated notifier API of extcon framework and then > > use > > the new extcon API[2] with the unique id[1] to indicate the each

Re: [RESEND PATCH 1/3] power: charger-manager: Replace deprecatd API of extcon

On Fri, Apr 15, 2016 at 04:13:18PM +0200, Sebastian Reichel wrote: > Hi, > > On Fri, Apr 15, 2016 at 09:43:34AM +0900, Chanwoo Choi wrote: > > This patch removes the deprecated notifier API of extcon framework and then > > use > > the new extcon API[2] with the unique id[1] to indicate the each

Re: [PATCH v4] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver

On Mon, Apr 18, 2016 at 08:43:39PM +0800, PC Liao wrote: > +Optional properties: > +- sound-dai: audio codec dai on capture path > + < 0> : Default setting. Connect rt5650 I2S1 for capture. (dai_name > = rt5645-aif1) > + < 1> : Connect rt5650 I2S2 for capture. (dai_name = rt5645-aif2)

Re: [PATCH v4] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver

On Mon, Apr 18, 2016 at 08:43:39PM +0800, PC Liao wrote: > +Optional properties: > +- sound-dai: audio codec dai on capture path > + < 0> : Default setting. Connect rt5650 I2S1 for capture. (dai_name > = rt5645-aif1) > + < 1> : Connect rt5650 I2S2 for capture. (dai_name = rt5645-aif2)

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

On Mon, 2016-04-18 at 11:20 -0400, Eric Sandeen wrote: > > On 4/14/16 10:17 PM, Dave Chinner wrote: > > On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote: > > > This lets userland get the filesystem freezing status, aka > > > whether the > > > filesystem is frozen or not. This is

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

On Mon, 2016-04-18 at 11:20 -0400, Eric Sandeen wrote: > > On 4/14/16 10:17 PM, Dave Chinner wrote: > > On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote: > > > This lets userland get the filesystem freezing status, aka > > > whether the > > > filesystem is frozen or not. This is

Re: [PATCH 3/3] gpio: tegra: Add support for gpio debounce

On Monday 18 April 2016 10:08 PM, Stephen Warren wrote: On 04/18/2016 02:46 AM, Laxman Dewangan wrote: + +/* There is only one debounce count register per port and hence + * set the maximum of current and requested debounce time. + */ +max_dbc =

Re: [PATCH 3/3] gpio: tegra: Add support for gpio debounce

On Monday 18 April 2016 10:08 PM, Stephen Warren wrote: On 04/18/2016 02:46 AM, Laxman Dewangan wrote: + +/* There is only one debounce count register per port and hence + * set the maximum of current and requested debounce time. + */ +max_dbc =

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

* Mike Galbraith | 2016-04-08 18:49:28 [+0200]: >On Fri, 2016-04-08 at 16:51 +0200, Sebastian Andrzej Siewior wrote: > >> Is there anything you can hand me over? > >Sure, I'll send it offline (yup, that proud of my scripting;) > > -Mike take 2. There is this else case in pin_current_cpu()

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

* Mike Galbraith | 2016-04-08 18:49:28 [+0200]: >On Fri, 2016-04-08 at 16:51 +0200, Sebastian Andrzej Siewior wrote: > >> Is there anything you can hand me over? > >Sure, I'll send it offline (yup, that proud of my scripting;) > > -Mike take 2. There is this else case in pin_current_cpu()

[PATCH v2] mm: SLAB freelist randomization

mes kmalloc(128)/kfree -> 127 cycles 1 times kmalloc(256)/kfree -> 119 cycles 1 times kmalloc(512)/kfree -> 112 cycles 1 times kmalloc(1024)/kfree -> 112 cycles 1 times kmalloc(2048)/kfree -> 112 cycles 10000 times kmalloc(4096)/kfree -> 112 cycles 1 times

[PATCH v2] mm: SLAB freelist randomization

mes kmalloc(128)/kfree -> 127 cycles 1 times kmalloc(256)/kfree -> 119 cycles 1 times kmalloc(512)/kfree -> 112 cycles 1 times kmalloc(1024)/kfree -> 112 cycles 1 times kmalloc(2048)/kfree -> 112 cycles 1 times kmalloc(4096)/kfree -> 1

Re: [PATCH RFC] I2C: i2c-smbus: add device tree support

On Mon, Apr 18, 2016 at 6:44 PM, Rob Herring wrote: > On Mon, Apr 18, 2016 at 8:35 AM, Andrea Merello > wrote: >> On Thu, Apr 14, 2016 at 6:10 PM, Rob Herring wrote: >>> On Wed, Apr 13, 2016 at 10:36:31AM +0200, Andrea Merello wrote:

Re: [PATCH RFC] I2C: i2c-smbus: add device tree support

On Mon, Apr 18, 2016 at 6:44 PM, Rob Herring wrote: > On Mon, Apr 18, 2016 at 8:35 AM, Andrea Merello > wrote: >> On Thu, Apr 14, 2016 at 6:10 PM, Rob Herring wrote: >>> On Wed, Apr 13, 2016 at 10:36:31AM +0200, Andrea Merello wrote: According to Documentation/i2c/smbus-protocol, a smbus

Re: [PATCH 2/3] gpio: tegra: Remove the need of keeping device handle for gpio driver

On Monday 18 April 2016 09:59 PM, Stephen Warren wrote: On 04/18/2016 02:46 AM, Laxman Dewangan wrote: Remove the file static device handle variable as this is just required for prints. The required handle can be stored in tegra_gpio_chip and hence it become redundancy. This seems fine as

Re: [PATCH 2/3] gpio: tegra: Remove the need of keeping device handle for gpio driver

On Monday 18 April 2016 09:59 PM, Stephen Warren wrote: On 04/18/2016 02:46 AM, Laxman Dewangan wrote: Remove the file static device handle variable as this is just required for prints. The required handle can be stored in tegra_gpio_chip and hence it become redundancy. This seems fine as

Re: [PATCH v2] carl9170: Clarify kconfig text

On Monday, April 18, 2016 06:47:44 PM Xose Vazquez Perez wrote: > Christian Lamparter wrote: > > > Sure, but this could be a different patch then. I think Intel devices > > (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download > > firmware from this device from our homepage here"

Re: [PATCH v2] carl9170: Clarify kconfig text

On Monday, April 18, 2016 06:47:44 PM Xose Vazquez Perez wrote: > Christian Lamparter wrote: > > > Sure, but this could be a different patch then. I think Intel devices > > (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download > > firmware from this device from our homepage here"

Re: [PATCH v2] carl9170: Clarify kconfig text

On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote: > Christian Lamparter writes: > > > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote: > >> Lauri Kasanen writes: > >> > >> > --- a/drivers/net/wireless/ath/carl9170/Kconfig > >> > +++

Re: [PATCH v2] carl9170: Clarify kconfig text

On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote: > Christian Lamparter writes: > > > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote: > >> Lauri Kasanen writes: > >> > >> > --- a/drivers/net/wireless/ath/carl9170/Kconfig > >> > +++ b/drivers/net/wireless/ath/carl9170/Kconfig > >>

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making clocksource > switching to hpet. We found similar symptom in another machine. Here is an > example: > > [8224517.520885] timekeeping watchdog: Marking clocksource

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Mon, Apr 18, 2016 at 9:54 AM, John Stultz wrote: > On Thu, Apr 7, 2016 at 11:02 PM, Baolin Wang wrote: >> security_settime() uses a timespec, which is not year 2038 safe >> on 32bit systems. Thus this patch introduces the security_settime64() >>

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Mon, Apr 18, 2016 at 9:54 AM, John Stultz wrote: > On Thu, Apr 7, 2016 at 11:02 PM, Baolin Wang wrote: >> security_settime() uses a timespec, which is not year 2038 safe >> on 32bit systems. Thus this patch introduces the security_settime64() >> function with timespec64 type. We also convert

Re: [RFC 1/2] time: workaround crappy hpet

On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li wrote: > Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making clocksource > switching to hpet. We found similar symptom in another machine. Here is an > example: > > [8224517.520885] timekeeping watchdog: Marking clocksource 'tsc' as

Re: [PATCH v2] regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs

Hello Krzysztof, On 04/18/2016 09:33 AM, Krzysztof Kozlowski wrote: > Driver did not provide default value for ramp delay for LDOs which lead > to warning in dmesg, e.g. on Odroid XU4: > > [1.486076] vdd_ldo9: ramp_delay not set > [1.506875] vddq_mmc2: ramp_delay not set > [1.523766]

Re: [PATCH v2] regulator: s2mps11: Set default ramp delay for S2MPS11 LDOs

Hello Krzysztof, On 04/18/2016 09:33 AM, Krzysztof Kozlowski wrote: > Driver did not provide default value for ramp delay for LDOs which lead > to warning in dmesg, e.g. on Odroid XU4: > > [1.486076] vdd_ldo9: ramp_delay not set > [1.506875] vddq_mmc2: ramp_delay not set > [1.523766]

Re: [PATCH 3/6] regulator: rk808: Make rk808 generic, rename rk808-regulator.c

On Mon, Apr 18, 2016 at 09:25:57AM +0200, Wadim Egorov wrote: > It seems this topic has been already discussed here [1]. > So the right solution is just to rename the rk808 struct in rk808.h, > don't touch the driver names and config options and naming the > additional RK818 PMIC in the Kconfig?

Re: [PATCH 3/6] regulator: rk808: Make rk808 generic, rename rk808-regulator.c

On Mon, Apr 18, 2016 at 09:25:57AM +0200, Wadim Egorov wrote: > It seems this topic has been already discussed here [1]. > So the right solution is just to rename the rk808 struct in rk808.h, > don't touch the driver names and config options and naming the > additional RK818 PMIC in the Kconfig?

Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote: On 14/04/16 15:41, Laxman Dewangan wrote: +static int gadc_thermal_read_channel(struct gadc_thermal_info *gti, int *val) +{ + int ret; + + ret = iio_read_channel_processed(gti->channel, val); + if (ret < 0) +

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On Mon, Apr 18, 2016 at 03:53:36AM +0100, Alexey Klimov wrote: > This patch creates new driver that supports StreamLabs usb watchdog > device. This device plugs into 9-pin usb header and connects to > reset pin and reset button on common PC. > > USB commands used to communicate with device were

[PATCH v2] mm: SLAB freelist randomization

mes kmalloc(128)/kfree -> 127 cycles 1 times kmalloc(256)/kfree -> 119 cycles 1 times kmalloc(512)/kfree -> 112 cycles 1 times kmalloc(1024)/kfree -> 112 cycles 1 times kmalloc(2048)/kfree -> 112 cycles 10000 times kmalloc(4096)/kfree -> 112 cycles 1 times

Re: [PATCH V3 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

On Sunday 17 April 2016 04:24 PM, Jonathan Cameron wrote: On 14/04/16 15:41, Laxman Dewangan wrote: +static int gadc_thermal_read_channel(struct gadc_thermal_info *gti, int *val) +{ + int ret; + + ret = iio_read_channel_processed(gti->channel, val); + if (ret < 0) +

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On Mon, Apr 18, 2016 at 03:53:36AM +0100, Alexey Klimov wrote: > This patch creates new driver that supports StreamLabs usb watchdog > device. This device plugs into 9-pin usb header and connects to > reset pin and reset button on common PC. > > USB commands used to communicate with device were

[PATCH v2] mm: SLAB freelist randomization

mes kmalloc(128)/kfree -> 127 cycles 1 times kmalloc(256)/kfree -> 119 cycles 1 times kmalloc(512)/kfree -> 112 cycles 1 times kmalloc(1024)/kfree -> 112 cycles 1 times kmalloc(2048)/kfree -> 112 cycles 1 times kmalloc(4096)/kfree -> 1

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

On Tue, Apr 12, 2016 at 06:22:25PM -0700, Tai Nguyen wrote: > Documentation: Add documentation for APM X-Gene SoC PMU DTS binding > > Signed-off-by: Tai Nguyen > --- > .../devicetree/bindings/perf/apm-xgene-pmu.txt | 116 > + > 1 file changed, 116

Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Mon, 2016-04-18 at 16:52 +, KY Srinivasan wrote: [] > > > +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw) > > > +{ > > > +   if (hw->mbx.ops.check_for_msg == NULL) > > > +   return true; > > > +   else > > > +   return false; > > > +} trivia: bool func(...) {

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

On Tue, Apr 12, 2016 at 06:22:25PM -0700, Tai Nguyen wrote: > Documentation: Add documentation for APM X-Gene SoC PMU DTS binding > > Signed-off-by: Tai Nguyen > --- > .../devicetree/bindings/perf/apm-xgene-pmu.txt | 116 > + > 1 file changed, 116 insertions(+) >

Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Mon, 2016-04-18 at 16:52 +, KY Srinivasan wrote: [] > > > +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw) > > > +{ > > > +   if (hw->mbx.ops.check_for_msg == NULL) > > > +   return true; > > > +   else > > > +   return false; > > > +} trivia: bool func(...) {

Re: [PATCH] mips: pistachio: Determine SoC revision during boot

Hello. On 04/18/2016 05:24 PM, James Hartley wrote: Now that there are different revisions of the Pistachio SoC in circulation, add this information to the boot log to make it easier for users to determine which hardware they have. Signed-off-by: James Hartley

Re: [PATCH] mips: pistachio: Determine SoC revision during boot

Hello. On 04/18/2016 05:24 PM, James Hartley wrote: Now that there are different revisions of the Pistachio SoC in circulation, add this information to the boot log to make it easier for users to determine which hardware they have. Signed-off-by: James Hartley Signed-off-by: Ionela Voinescu

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Thu, Apr 7, 2016 at 11:02 PM, Baolin Wang wrote: > security_settime() uses a timespec, which is not year 2038 safe > on 32bit systems. Thus this patch introduces the security_settime64() > function with timespec64 type. We also convert the cap_settime() helper >

Re: [PATCH 1/5] regulator: st-flashss: Add DT binding documentation for flashss regulator.

On Tue, Apr 12, 2016 at 04:16:40PM +0100, Peter Griffin wrote: > This patch adds the DT doc for the flashss regulator driver which is > found in stih407 based silicon. > > Signed-off-by: Peter Griffin > --- > .../devicetree/bindings/regulator/st-flashss.txt | 43 >

Re: [PATCH 1/5] regulator: st-flashss: Add DT binding documentation for flashss regulator.

On Tue, Apr 12, 2016 at 04:16:40PM +0100, Peter Griffin wrote: > This patch adds the DT doc for the flashss regulator driver which is > found in stih407 based silicon. > > Signed-off-by: Peter Griffin > --- > .../devicetree/bindings/regulator/st-flashss.txt | 43 > ++ > 1

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Thu, Apr 7, 2016 at 11:02 PM, Baolin Wang wrote: > security_settime() uses a timespec, which is not year 2038 safe > on 32bit systems. Thus this patch introduces the security_settime64() > function with timespec64 type. We also convert the cap_settime() helper > function to use the 64bit

Re: [PATCH] ARM: dts: exynos: Remove unsupported s2mps11 regulator bindings from Exynos5420 boards

Hello Krzysztof, On 04/18/2016 03:44 AM, Krzysztof Kozlowski wrote: > The bindings like s2mps11,buck6-ramp-enable or s2mps11,buck2-ramp-delay > where ignored. They were never parse by s2mps11 regulator driver. Also > the values used in these bindings were equal to default reset values of >

Re: [PATCH] ARM: dts: exynos: Remove unsupported s2mps11 regulator bindings from Exynos5420 boards

Hello Krzysztof, On 04/18/2016 03:44 AM, Krzysztof Kozlowski wrote: > The bindings like s2mps11,buck6-ramp-enable or s2mps11,buck2-ramp-delay > where ignored. They were never parse by s2mps11 regulator driver. Also > the values used in these bindings were equal to default reset values of >

RE: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: Alexander Duyck [mailto:alexander.du...@gmail.com] > Sent: Monday, April 18, 2016 9:18 AM > To: KY Srinivasan > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; >

RE: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: Alexander Duyck [mailto:alexander.du...@gmail.com] > Sent: Monday, April 18, 2016 9:18 AM > To: KY Srinivasan > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot > ; Jason Wang ; >

Re: [PATCH v5 04/21] x86, boot: Move compressed kernel to end of decompression buffer

On Fri, Apr 15, 2016 at 1:09 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> From: Yinghai Lu >> >> This change makes later calculations about where the kernel is located >> easier to reason about. To better understand this change,

Re: [PATCH v5 04/21] x86, boot: Move compressed kernel to end of decompression buffer

On Fri, Apr 15, 2016 at 1:09 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> From: Yinghai Lu >> >> This change makes later calculations about where the kernel is located >> easier to reason about. To better understand this change, we must first >> clarify what VO and ZO are. They were

Re: [PATCH v2] carl9170: Clarify kconfig text

Christian Lamparter wrote: > Sure, but this could be a different patch then. I think Intel devices > (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download > firmware from this device from our homepage here" too. So if we want, > we can remove them altogether? linux-firmware.git

Re: [PATCH v2] carl9170: Clarify kconfig text

Christian Lamparter wrote: > Sure, but this could be a different patch then. I think Intel devices > (iwlwifi, iwlegacy and ipw2x00) have a similar text about "download > firmware from this device from our homepage here" too. So if we want, > we can remove them altogether? linux-firmware.git

Re: [PATCH RFC] I2C: i2c-smbus: add device tree support

On Mon, Apr 18, 2016 at 8:35 AM, Andrea Merello wrote: > On Thu, Apr 14, 2016 at 6:10 PM, Rob Herring wrote: >> On Wed, Apr 13, 2016 at 10:36:31AM +0200, Andrea Merello wrote: >>> According to Documentation/i2c/smbus-protocol, a smbus controller driver

Re: [PATCH RFC] I2C: i2c-smbus: add device tree support

On Mon, Apr 18, 2016 at 8:35 AM, Andrea Merello wrote: > On Thu, Apr 14, 2016 at 6:10 PM, Rob Herring wrote: >> On Wed, Apr 13, 2016 at 10:36:31AM +0200, Andrea Merello wrote: >>> According to Documentation/i2c/smbus-protocol, a smbus controller driver >>> that wants to hook-in smbus extensions

Re: [PATCH 3/5] clocksource/drivers/mtk_timer: add __init attribute

On Mon, Apr 18, 2016 at 04:55:36PM +0200, Julia Lawall wrote: > Add __init attribute on a function that is only called from other __init > functions and that is not inlined, at least with gcc version 4.8.4 on an > x86 machine with allyesconfig. Currently, the function is put in the >

Re: [PATCH 3/5] clocksource/drivers/mtk_timer: add __init attribute

On Mon, Apr 18, 2016 at 04:55:36PM +0200, Julia Lawall wrote: > Add __init attribute on a function that is only called from other __init > functions and that is not inlined, at least with gcc version 4.8.4 on an > x86 machine with allyesconfig. Currently, the function is put in the >

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