Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On Fri, 2016-08-05 at 21:20 +, york sun wrote: > On 08/05/2016 02:09 PM, Scott Wood wrote: > > > > On Fri, 2016-08-05 at 20:29 +, york sun wrote: > > > > > > On 08/04/2016 08:43 PM, Michael Ellerman wrote: > > > > > > > > > > > > Does the driver really need to use these routines?

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On Fri, 2016-08-05 at 21:20 +, york sun wrote: > On 08/05/2016 02:09 PM, Scott Wood wrote: > > > > On Fri, 2016-08-05 at 20:29 +, york sun wrote: > > > > > > On 08/04/2016 08:43 PM, Michael Ellerman wrote: > > > > > > > > > > > > Does the driver really need to use these routines?

RE: [PATCH] vmxnet3: Move PCI Id to pci_ids.h

On Fri, Aug 05, 2016 11:23:41AM -0700, Bjorn Helgaas wrote: > On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > > driver. Moved it to the shared location in pci_ids.h and updated the > >

RE: [PATCH] vmxnet3: Move PCI Id to pci_ids.h

On Fri, Aug 05, 2016 11:23:41AM -0700, Bjorn Helgaas wrote: > On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > > driver. Moved it to the shared location in pci_ids.h and updated the > > driver version. > > >

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On 08/05/2016 02:09 PM, Scott Wood wrote: > On Fri, 2016-08-05 at 20:29 +, york sun wrote: >> On 08/04/2016 08:43 PM, Michael Ellerman wrote: >>> >>> Does the driver really need to use these routines? They're meant for use >>> early in boot, before PCI is setup. >>> >>> AFAICS this is just a

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On 08/05/2016 02:09 PM, Scott Wood wrote: > On Fri, 2016-08-05 at 20:29 +, york sun wrote: >> On 08/04/2016 08:43 PM, Michael Ellerman wrote: >>> >>> Does the driver really need to use these routines? They're meant for use >>> early in boot, before PCI is setup. >>> >>> AFAICS this is just a

[PATCH 3/3] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

From: Michael Ellerman lkdtm_rodata_do_nothing() is an empty function which is generated in order to test the non-executability of rodata. Currently if function tracing is enabled then an mcount callsite will be generated for lkdtm_rodata_do_nothing(), and it will appear in

[PATCH 3/3] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

From: Michael Ellerman lkdtm_rodata_do_nothing() is an empty function which is generated in order to test the non-executability of rodata. Currently if function tracing is enabled then an mcount callsite will be generated for lkdtm_rodata_do_nothing(), and it will appear in the list of

[PATCH 1/3] lkdtm: fix false positive warning from -Wmaybe-uninitialized

The variable in use here doesn't matter (it's just used to exercise taking up stack space), but this changes its use to pass its address instead, to avoid a compiler warning: drivers/misc/lkdtm_usercopy.c:54:15: warning: 'bad_stack' may be used uninitialized in this function

[PATCH 1/3] lkdtm: fix false positive warning from -Wmaybe-uninitialized

The variable in use here doesn't matter (it's just used to exercise taking up stack space), but this changes its use to pass its address instead, to avoid a compiler warning: drivers/misc/lkdtm_usercopy.c:54:15: warning: 'bad_stack' may be used uninitialized in this function

[PATCH 2/3] lkdtm: Fix targets for objcopy usage

The targets for lkdtm's objcopy were missing which caused them to always be rebuilt. This corrects the problem. Reported-by: Linus Torvalds Signed-off-by: Kees Cook --- drivers/misc/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH 2/3] lkdtm: Fix targets for objcopy usage

The targets for lkdtm's objcopy were missing which caused them to always be rebuilt. This corrects the problem. Reported-by: Linus Torvalds Signed-off-by: Kees Cook --- drivers/misc/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/misc/Makefile

[PATCH 0/3] lkdtm: fixes for v4.8-rc1

Hi Greg! As requested, here's a patch series for 3 small fixes for lkdtm for v4.8 (instead of as a pull request). Thanks! -Kees Kees Cook (2): lkdtm: fix false positive warning from -Wmaybe-uninitialized lkdtm: Fix

[PATCH 0/3] lkdtm: fixes for v4.8-rc1

Hi Greg! As requested, here's a patch series for 3 small fixes for lkdtm for v4.8 (instead of as a pull request). Thanks! -Kees Kees Cook (2): lkdtm: fix false positive warning from -Wmaybe-uninitialized lkdtm: Fix

[GIT PULL] Block fixes for 4.8-rc1

Hi Linus, Here's the 2nd round of block updates for this merge window. It's a mix of fixes for changes that went in previously in this round, and fixes in general. This pull request contains: - Fixes for loop from Christoph - A bdi vs gendisk lifetime fix from Dan, worth two cookies. - A

[GIT PULL] Block fixes for 4.8-rc1

Hi Linus, Here's the 2nd round of block updates for this merge window. It's a mix of fixes for changes that went in previously in this round, and fixes in general. This pull request contains: - Fixes for loop from Christoph - A bdi vs gendisk lifetime fix from Dan, worth two cookies. - A

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On Fri, 2016-08-05 at 20:29 +, york sun wrote: > On 08/04/2016 08:43 PM, Michael Ellerman wrote: > > > > Does the driver really need to use these routines? They're meant for use > > early in boot, before PCI is setup. > > > > AFAICS this is just a regular driver, so when it's probed the PCI

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On Fri, 2016-08-05 at 20:29 +, york sun wrote: > On 08/04/2016 08:43 PM, Michael Ellerman wrote: > > > > Does the driver really need to use these routines? They're meant for use > > early in boot, before PCI is setup. > > > > AFAICS this is just a regular driver, so when it's probed the PCI

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On 08/04/2016 08:43 PM, Michael Ellerman wrote: > York Sun writes: > >> Two symbols are missing if mpc85xx_edac driver is compiled as module. >> >> Signed-off-by: York Sun >> >> --- >> Change log >> v3: Change subject tag >> v2: no change >> >>

Re: [Patch v3 01/11] arch/powerpc/pci: Fix compiling error for mpc85xx_edac

On 08/04/2016 08:43 PM, Michael Ellerman wrote: > York Sun writes: > >> Two symbols are missing if mpc85xx_edac driver is compiled as module. >> >> Signed-off-by: York Sun >> >> --- >> Change log >> v3: Change subject tag >> v2: no change >> >> arch/powerpc/kernel/pci-common.c | 2 ++ >> 1

[PATCH] asus-laptop: get rid of parse_arg()

parse_arg() duplicates the funcionality of kstrtoint() so use the latter function instead. There is no funcionality change except that in the case of input being too big -ERANGE will be returned instead of -EINVAL which is not bad because -ERANGE makes more sense here. The check for !count is

[PATCH] asus-laptop: get rid of parse_arg()

parse_arg() duplicates the funcionality of kstrtoint() so use the latter function instead. There is no funcionality change except that in the case of input being too big -ERANGE will be returned instead of -EINVAL which is not bad because -ERANGE makes more sense here. The check for !count is

Re: [linux-mm] Drastic increase in application memory usage with Kernel version upgrade

On Fri 2016-08-05 20:17:36, PINTU KUMAR wrote: > Hi, > > On Fri, Aug 05, 2016 at 10:26:37AM +0530, PINTU KUMAR wrote: > > > Hi All, > > > > > > For one of our ARM embedded product, we recently updated the Kernel > > > version from > > > 3.4 to 3.18 and we noticed that the same application memory

Re: [linux-mm] Drastic increase in application memory usage with Kernel version upgrade

On Fri 2016-08-05 20:17:36, PINTU KUMAR wrote: > Hi, > > On Fri, Aug 05, 2016 at 10:26:37AM +0530, PINTU KUMAR wrote: > > > Hi All, > > > > > > For one of our ARM embedded product, we recently updated the Kernel > > > version from > > > 3.4 to 3.18 and we noticed that the same application memory

Re: [PATCH v2 3/3] kexec: extend kexec_file_load system call

Hi, Am Dienstag, 26 Juli 2016, 21:24:29 schrieb Thiago Jung Bauermann: > Notes: > This is a new version of the last patch in this series which adds > a function where each architecture can verify if the DTB is safe > to load: > > int __weak arch_kexec_verify_buffer(enum

Re: [PATCH v2 3/3] kexec: extend kexec_file_load system call

Hi, Am Dienstag, 26 Juli 2016, 21:24:29 schrieb Thiago Jung Bauermann: > Notes: > This is a new version of the last patch in this series which adds > a function where each architecture can verify if the DTB is safe > to load: > > int __weak arch_kexec_verify_buffer(enum

menuconfig very unfriendly with MEDIA_SUBDRV_AUTOSELECT=y

Hi! I was trying to enable a driver (trivial task, right) and spent like 10 minutes scratching my hand. menuconfig is nice, because you can search with '/' and it tells you the dependencies, and the path to the config option. What is not nice is that you have to write down the path, and then

menuconfig very unfriendly with MEDIA_SUBDRV_AUTOSELECT=y

Hi! I was trying to enable a driver (trivial task, right) and spent like 10 minutes scratching my hand. menuconfig is nice, because you can search with '/' and it tells you the dependencies, and the path to the config option. What is not nice is that you have to write down the path, and then

Re: NVME regression in all kernels after 4.4.x for NVME in M2 slot for laptop?

On Fri, Aug 05, 2016 at 12:03:23PM -0700, Marc MERLIN wrote: > Would this patch make sense as being the reason why I can't S3 sleep > anymore and would you have a test patch against 4.5, 4.6, or 4.7 I can > try to see if it fixes the problem? Hi Marc, It might be blk-mq's hot cpu notifier is

Re: NVME regression in all kernels after 4.4.x for NVME in M2 slot for laptop?

On Fri, Aug 05, 2016 at 12:03:23PM -0700, Marc MERLIN wrote: > Would this patch make sense as being the reason why I can't S3 sleep > anymore and would you have a test patch against 4.5, 4.6, or 4.7 I can > try to see if it fixes the problem? Hi Marc, It might be blk-mq's hot cpu notifier is

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

On Tue, Aug 2, 2016 at 8:29 PM, Damien Le Moal wrote: > Hannes, Shaun, > > Let me add some more comments. > >> On Aug 2, 2016, at 23:35, Hannes Reinecke wrote: >> >> On 08/01/2016 07:07 PM, Shaun Tancheff wrote: >>> On Mon, Aug 1, 2016 at 4:41 AM, Christoph

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

On Tue, Aug 2, 2016 at 8:29 PM, Damien Le Moal wrote: > Hannes, Shaun, > > Let me add some more comments. > >> On Aug 2, 2016, at 23:35, Hannes Reinecke wrote: >> >> On 08/01/2016 07:07 PM, Shaun Tancheff wrote: >>> On Mon, Aug 1, 2016 at 4:41 AM, Christoph Hellwig wrote: Can you

[PATCH 1/1] brcmfmac: fix pmksa->bssid usage

The struct cfg80211_pmksa defines its bssid field as: const u8 *bssid; contrary to struct brcmf_pmksa, which uses: u8 bssid[ETH_ALEN]; Therefore in brcmf_cfg80211_del_pmksa(), >bssid takes the address of this field (of type u8**), not the one of its content (which would be u8*).

[PATCH 1/1] brcmfmac: fix pmksa->bssid usage

The struct cfg80211_pmksa defines its bssid field as: const u8 *bssid; contrary to struct brcmf_pmksa, which uses: u8 bssid[ETH_ALEN]; Therefore in brcmf_cfg80211_del_pmksa(), >bssid takes the address of this field (of type u8**), not the one of its content (which would be u8*).

Re: [PATCH 1/1] RDS: add __printf format attribute to error reporting functions

On 8/5/2016 1:11 PM, Nicolas Iooss wrote: This is helpful to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- OK. Acked-by: Santosh Shilimkar

Re: [PATCH 1/1] RDS: add __printf format attribute to error reporting functions

On 8/5/2016 1:11 PM, Nicolas Iooss wrote: This is helpful to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- OK. Acked-by: Santosh Shilimkar

[GIT PULL] More USB driver patches for 4.8-rc1

The following changes since commit e65805251f2db69c9f67ed8062ab82526be5a374: Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2016-07-25 21:35:03 -0700) are available in the git repository at:

[GIT PULL] More USB driver patches for 4.8-rc1

The following changes since commit e65805251f2db69c9f67ed8062ab82526be5a374: Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2016-07-25 21:35:03 -0700) are available in the git repository at:

[GIT PULL] NTB bug fixes for v4.8

Hello Linus, Here are a few NTB improvements and bug fixes for 4.8. Please consider pulling them. Thanks, Jon The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e: Linux 4.7 (2016-07-24 12:23:50 -0700) are available in the git repository at:

[GIT PULL] NTB bug fixes for v4.8

Hello Linus, Here are a few NTB improvements and bug fixes for 4.8. Please consider pulling them. Thanks, Jon The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e: Linux 4.7 (2016-07-24 12:23:50 -0700) are available in the git repository at:

Re: The timer softirq on the RT kernel

On Fri, 05 Aug 2016 04:36:23 +0200 Mike Galbraith wrote: > On Thu, 2016-08-04 at 17:36 -0700, yunhong jiang wrote: > > Hi,Mike & Steven > > On https://lkml.org/lkml/2015/3/24/1178, the patch of > > "timers: do not raise softirq unconditionally" is reverted. Thanks >

Re: The timer softirq on the RT kernel

On Fri, 05 Aug 2016 04:36:23 +0200 Mike Galbraith wrote: > On Thu, 2016-08-04 at 17:36 -0700, yunhong jiang wrote: > > Hi,Mike & Steven > > On https://lkml.org/lkml/2015/3/24/1178, the patch of > > "timers: do not raise softirq unconditionally" is reverted. Thanks > > for Steven's > >

[PATCH] Staging: rtl8723au: rtw_ieee80211: Fixed operators spacing style issues

Fixed spaces around operators to fix their coding style issues. Signed-off-by: Shiva Kerdel --- drivers/staging/rtl8723au/core/rtw_ieee80211.c | 80 +- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git

[PATCH] Staging: rtl8723au: rtw_ieee80211: Fixed operators spacing style issues

Fixed spaces around operators to fix their coding style issues. Signed-off-by: Shiva Kerdel --- drivers/staging/rtl8723au/core/rtw_ieee80211.c | 80 +- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/drivers/staging/rtl8723au/core/rtw_ieee80211.c

Re: [PATCH] Fix sysrq emergency thaw

On Wed 2016-07-20 16:11:16, Charles Gong wrote: > "SYSRQ + J" triggers a call to emergency_thaw_all(). Currently, this > is an infinite loop. Once we trigger it, we'll need to do a hard > power-cycle. There are users reporting this bug from 2012 to 2016, for > example, at

Re: [PATCH] Fix sysrq emergency thaw

On Wed 2016-07-20 16:11:16, Charles Gong wrote: > "SYSRQ + J" triggers a call to emergency_thaw_all(). Currently, this > is an infinite loop. Once we trigger it, we'll need to do a hard > power-cycle. There are users reporting this bug from 2012 to 2016, for > example, at

[PATCH 1/1] RDS: add __printf format attribute to error reporting functions

This is helpful to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- net/rds/ib.h | 1 + net/rds/rds.h | 1 + 2 files changed, 2 insertions(+) diff --git a/net/rds/ib.h b/net/rds/ib.h index 046f7508c06b..45ac8e8e58f4 100644

[PATCH 1/1] RDS: add __printf format attribute to error reporting functions

This is helpful to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- net/rds/ib.h | 1 + net/rds/rds.h | 1 + 2 files changed, 2 insertions(+) diff --git a/net/rds/ib.h b/net/rds/ib.h index 046f7508c06b..45ac8e8e58f4 100644 --- a/net/rds/ib.h +++

Re: [PATCH v5 4/8] char: rpmb: provide a user space interface

On Mon 2016-07-18 23:27:49, Tomas Winkler wrote: > The user space API is achieved via two synchronous IOCTL. IOCTLs? > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD where > the whole RPMB sequence

Re: [PATCH v5 4/8] char: rpmb: provide a user space interface

On Mon 2016-07-18 23:27:49, Tomas Winkler wrote: > The user space API is achieved via two synchronous IOCTL. IOCTLs? > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD where > the whole RPMB sequence

Re: [PATCH v5 0/8] Replay Protected Memory Block (RPMB) subsystem

Hi! > Few storage technologies such is EMMC, UFS, and NVMe support RPMB > hardware partition with common protocol and frame layout. > The RPMB partition cannot be accessed via standard block layer, but by a > set of specific commands: WRITE, READ, GET_WRITE_COUNTER, and > PROGRAM_KEY. > Such a

Re: [PATCH v5 0/8] Replay Protected Memory Block (RPMB) subsystem

Hi! > Few storage technologies such is EMMC, UFS, and NVMe support RPMB > hardware partition with common protocol and frame layout. > The RPMB partition cannot be accessed via standard block layer, but by a > set of specific commands: WRITE, READ, GET_WRITE_COUNTER, and > PROGRAM_KEY. > Such a

Re: [RFC] User-defined leds

On Fri 2016-08-05 14:54:33, David Lechner wrote: > On 08/05/2016 02:51 PM, Pavel Machek wrote: > > > >Could the device tree be used to bind LED driver to otherwise unused > >gpio? > > There is already a leds-gpio driver that does this. > >

Re: [RFC] User-defined leds

On Fri 2016-08-05 14:54:33, David Lechner wrote: > On 08/05/2016 02:51 PM, Pavel Machek wrote: > > > >Could the device tree be used to bind LED driver to otherwise unused > >gpio? > > There is already a leds-gpio driver that does this. > >

Re: [RFC] User-defined leds

On 08/05/2016 02:51 PM, Pavel Machek wrote: Could the device tree be used to bind LED driver to otherwise unused gpio? Pavel There is already a leds-gpio driver that does this.

Re: [RFC] User-defined leds

On 08/05/2016 02:51 PM, Pavel Machek wrote: Could the device tree be used to bind LED driver to otherwise unused gpio? Pavel There is already a leds-gpio driver that does this.

Re: [RFC] User-defined leds

Hi! > > short version: I have a use case for leds where I want to be able to use > > the triggers in the leds subsystem without having a physical hardware led. > > > > long version: I am working on a program to make one embedded system > > (http://fatcatlab.com/product/evb/) compatible with

Re: [RFC] User-defined leds

Hi! > > short version: I have a use case for leds where I want to be able to use > > the triggers in the leds subsystem without having a physical hardware led. > > > > long version: I am working on a program to make one embedded system > > (http://fatcatlab.com/product/evb/) compatible with

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 12:52:09PM +0200, Peter Zijlstra wrote: > > > > Currently overflow_handler is set at event alloc time. If we start > > > > changing it on the fly with atomic xchg(), afaik things shouldn't > > > > break, since each overflow_handler is run to completion and doesn't > > > >

Re: [PATCH v2 1/3] perf/core: Add a tracepoint for perf sampling

On Fri, Aug 05, 2016 at 12:52:09PM +0200, Peter Zijlstra wrote: > > > > Currently overflow_handler is set at event alloc time. If we start > > > > changing it on the fly with atomic xchg(), afaik things shouldn't > > > > break, since each overflow_handler is run to completion and doesn't > > > >

Re: [GIT PULL] Please pull NFS client updates for 4.8

On Sat 2016-07-30 16:32:32, Linus Torvalds wrote: > On Sat, Jul 30, 2016 at 3:36 PM, Trond Myklebust > wrote: > > > > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.8-1 > > Hmm. That machine is being very very slow. It's responding to pings, >

Re: [GIT PULL] Please pull NFS client updates for 4.8

On Sat 2016-07-30 16:32:32, Linus Torvalds wrote: > On Sat, Jul 30, 2016 at 3:36 PM, Trond Myklebust > wrote: > > > > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.8-1 > > Hmm. That machine is being very very slow. It's responding to pings, > but the whole "git pull"

NVME regression in all kernels after 4.4.x for NVME in M2 slot for laptop?

I've been stuck on 4.4.x for a while (currently 4.4.5) because any subsequent kernel would fail to suspend or resume (S3 sleep) on my Thinkpad P70. Due to lack of time, I only got around to doing a git bisect now (sorry), and did it between 4.4.0 and 4.5.0 It's my first bisect, but I hope I did

NVME regression in all kernels after 4.4.x for NVME in M2 slot for laptop?

I've been stuck on 4.4.x for a while (currently 4.4.5) because any subsequent kernel would fail to suspend or resume (S3 sleep) on my Thinkpad P70. Due to lack of time, I only got around to doing a git bisect now (sorry), and did it between 4.4.0 and 4.5.0 It's my first bisect, but I hope I did

Re: [PATCH v3 2/9] usb: gadget: align buffer size when allocating for OUT endpoint

Hi Felipe, [auto build test ERROR on balbi-usb/next] [also build test ERROR on v4.7 next-20160805] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Felipe-F-Tonello/Gadget-endpoint-request

Re: [PATCH v3 2/9] usb: gadget: align buffer size when allocating for OUT endpoint

Hi Felipe, [auto build test ERROR on balbi-usb/next] [also build test ERROR on v4.7 next-20160805] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Felipe-F-Tonello/Gadget-endpoint-request

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 08:11:36PM +0200, Johannes Stezenbach wrote: > On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > > On Fri, Aug 05, 2016 at 12:35:44PM +0200, Johannes Stezenbach wrote: > > > On Wed, Aug 03, 2016 at 05:50:26PM +0300, Török Edwin wrote: > > > > I have just

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 08:11:36PM +0200, Johannes Stezenbach wrote: > On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > > On Fri, Aug 05, 2016 at 12:35:44PM +0200, Johannes Stezenbach wrote: > > > On Wed, Aug 03, 2016 at 05:50:26PM +0300, Török Edwin wrote: > > > > I have just

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > diff --git a/include/asm-generic/vmlinux.lds.h > > b/include/asm-generic/vmlinux.lds.h > > index 0ec807d69f18..7a3ad269fa23 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h >

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > diff --git a/include/asm-generic/vmlinux.lds.h > > b/include/asm-generic/vmlinux.lds.h > > index 0ec807d69f18..7a3ad269fa23 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h >

Re: [PATCH 2/4] tools lib traceevent: Use USECS_PER_SEC instead of hardcoded number

On Fri, 5 Aug 2016 15:36:55 -0300 Arnaldo Carvalho de Melo wrote: > [acme@jouet linux]$ cat tools/include/linux/time64.h > #ifndef _TOOLS_LINUX_TIME64_H > #define _TOOLS_LINUX_TIME64_H > > #define MSEC_PER_SEC 1000L > #define USEC_PER_MSEC 1000L > #define NSEC_PER_USEC 1000L

Re: [PATCH 2/4] tools lib traceevent: Use USECS_PER_SEC instead of hardcoded number

On Fri, 5 Aug 2016 15:36:55 -0300 Arnaldo Carvalho de Melo wrote: > [acme@jouet linux]$ cat tools/include/linux/time64.h > #ifndef _TOOLS_LINUX_TIME64_H > #define _TOOLS_LINUX_TIME64_H > > #define MSEC_PER_SEC 1000L > #define USEC_PER_MSEC 1000L > #define NSEC_PER_USEC 1000L > #define

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

Only nits from me...(see below) On 08/05/2016 01:30 PM, Sukadev Bhattiprolu wrote: Here is an updated patch to fix the build when CONFIG_PPC_PSERIES=n. --- From d4f77a6ca7b6ea83f6588e7d541cc70bf001ae85 Mon Sep 17 00:00:00 2001 From: root Date: Thu, 4 Aug 2016

Re: pcieport AER error spam on Intel Skylake

On Fri, Aug 5, 2016 at 11:15 AM, Daniel Drake wrote: > Hi Alexander, > > Reviving an old topic here... > > We are seeing this "problem" on an increasing number of units from the > vendor, and searching around it can also be seen on Dell and HP > products. Always with the same

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

On Wed, Jul 27, 2016 at 6:50 AM, Kyle Walker wrote: > On Tue, Jul 26, 2016 at 5:36 PM, John Stultz wrote: >> The logic here is confusing as well. So.. if the override is not HRT >> compatible, we check if its stable or not? Once we're in HRT there's

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

On Wed, Jul 27, 2016 at 6:50 AM, Kyle Walker wrote: > On Tue, Jul 26, 2016 at 5:36 PM, John Stultz wrote: >> The logic here is confusing as well. So.. if the override is not HRT >> compatible, we check if its stable or not? Once we're in HRT there's >> not much likelyhood of us going into non

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

Only nits from me...(see below) On 08/05/2016 01:30 PM, Sukadev Bhattiprolu wrote: Here is an updated patch to fix the build when CONFIG_PPC_PSERIES=n. --- From d4f77a6ca7b6ea83f6588e7d541cc70bf001ae85 Mon Sep 17 00:00:00 2001 From: root Date: Thu, 4 Aug 2016 23:13:37 -0400 Subject: [PATCH

Re: pcieport AER error spam on Intel Skylake

On Fri, Aug 5, 2016 at 11:15 AM, Daniel Drake wrote: > Hi Alexander, > > Reviving an old topic here... > > We are seeing this "problem" on an increasing number of units from the > vendor, and searching around it can also be seen on Dell and HP > products. Always with the same Realtek b723 wifi

Re: [PATCH v2 1/2] soc: qcom: provide mechanism for drivers to access L2 registers

On 8/5/2016 06:00 AM, Mark Rutland wrote: > On Thu, Aug 04, 2016 at 05:11:10PM -0400, Neil Leeder wrote: >> L2 registers are accessed using a select register and data >> register pair. To prevent multiple concurrent writes to the >> select register by independent drivers, the write to the >>

Re: [PATCH v2 1/2] soc: qcom: provide mechanism for drivers to access L2 registers

On 8/5/2016 06:00 AM, Mark Rutland wrote: > On Thu, Aug 04, 2016 at 05:11:10PM -0400, Neil Leeder wrote: >> L2 registers are accessed using a select register and data >> register pair. To prevent multiple concurrent writes to the >> select register by independent drivers, the write to the >>

Re: pcieport AER error spam on Intel Skylake

On Fri, Aug 05, 2016 at 12:15:53PM -0600, Daniel Drake wrote: > Hi Alexander, > > Reviving an old topic here... > > We are seeing this "problem" on an increasing number of units from the > vendor, and searching around it can also be seen on Dell and HP > products. Always with the same Realtek

Re: pcieport AER error spam on Intel Skylake

On Fri, Aug 05, 2016 at 12:15:53PM -0600, Daniel Drake wrote: > Hi Alexander, > > Reviving an old topic here... > > We are seeing this "problem" on an increasing number of units from the > vendor, and searching around it can also be seen on Dell and HP > products. Always with the same Realtek

Re: mfd: dm355evm_msp: Refactoring for add_child()

> I'm unsure if you're not re-submitting because you're waiting for an > answer for me or not. I found your five commits (on 2016-06-29) for this patch series sufficient in principle.

Re: mfd: dm355evm_msp: Refactoring for add_child()

> I'm unsure if you're not re-submitting because you're waiting for an > answer for me or not. I found your five commits (on 2016-06-29) for this patch series sufficient in principle.

[PATCH v3 1/9] usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align

USB spec specifies wMaxPacketSize to be little endian (as other properties), so when using this variable in the driver we should convert to the current CPU endianness if necessary. This patch also introduces usb_ep_align() which does always returns the aligned buffer size for an endpoint. This is

[PATCH v3 1/9] usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align

USB spec specifies wMaxPacketSize to be little endian (as other properties), so when using this variable in the driver we should convert to the current CPU endianness if necessary. This patch also introduces usb_ep_align() which does always returns the aligned buffer size for an endpoint. This is

[PATCH v3 2/9] usb: gadget: align buffer size when allocating for OUT endpoint

Using usb_ep_align() makes sure that the buffer size for OUT endpoints is always aligned with wMaxPacketSize (512 usually). This makes sure that no buffer has the wrong size, which can cause nasty bugs. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/u_f.c | 3

[PATCH v3 2/9] usb: gadget: align buffer size when allocating for OUT endpoint

Using usb_ep_align() makes sure that the buffer size for OUT endpoints is always aligned with wMaxPacketSize (512 usually). This makes sure that no buffer has the wrong size, which can cause nasty bugs. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/u_f.c | 3 +++

[PATCH v3 3/9] usb: gadget: f_midi: remove alignment code for OUT endpoint

The new version of alloc_ep_req() already aligns the buffer size to wMaxPacketSize on OUT endpoints. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_midi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[PATCH v3 3/9] usb: gadget: f_midi: remove alignment code for OUT endpoint

The new version of alloc_ep_req() already aligns the buffer size to wMaxPacketSize on OUT endpoints. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_midi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/f_midi.c

[PATCH v3 5/9] usb: gadget: f_midi: refactor state machine

This refactor results in a cleaner state machine code and promotes consistency, readability, and maintanability of this driver. This refactor state machine was well tested and it is currently running in production code and devices. Signed-off-by: Felipe F. Tonello ---

[PATCH v3 5/9] usb: gadget: f_midi: refactor state machine

This refactor results in a cleaner state machine code and promotes consistency, readability, and maintanability of this driver. This refactor state machine was well tested and it is currently running in production code and devices. Signed-off-by: Felipe F. Tonello ---

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

Good evening John, On Wed, Jul 27, 2016 at 10:29 AM, Kyle Walker wrote: > The issue I'm running into is that the override is not HRT compatible yet. > Though it will be later in the boot process, unless the clocksource watchdog > marks the clocksource as unstable. > > The

Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

Good evening John, On Wed, Jul 27, 2016 at 10:29 AM, Kyle Walker wrote: > The issue I'm running into is that the override is not HRT compatible yet. > Though it will be later in the boot process, unless the clocksource watchdog > marks the clocksource as unstable. > > The issue with the current

[PATCH v3 6/9] usb: gadget: f_midi: drop substreams when disabling endpoint

This change makes sure that the ALSA buffers are cleaned if an endpoint becomes disabled. Before this change, if the internal ALSA buffer did overflow, the MIDI function would stop sending MIDI to the host. Signed-off-by: Felipe F. Tonello ---

[PATCH v3 6/9] usb: gadget: f_midi: drop substreams when disabling endpoint

This change makes sure that the ALSA buffers are cleaned if an endpoint becomes disabled. Before this change, if the internal ALSA buffer did overflow, the MIDI function would stop sending MIDI to the host. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_midi.c | 27

[PATCH v3 7/9] usb: gadget: remove useless parameter in alloc_ep_req()

The default_length parameter of alloc_ep_req was not really necessary and gadget drivers would almost always create an inline function to pass the same value to len and default_len. So this patch also removes duplicate code from few drivers. Signed-off-by: Felipe F. Tonello

[PATCH v3 7/9] usb: gadget: remove useless parameter in alloc_ep_req()

The default_length parameter of alloc_ep_req was not really necessary and gadget drivers would almost always create an inline function to pass the same value to len and default_len. So this patch also removes duplicate code from few drivers. Signed-off-by: Felipe F. Tonello ---

[PATCH v3 0/9] Gadget endpoint request allocation and MIDI

As discussed with Baolin Wang, Michal Nazarewicz and Felipe Balbi. I propose the forced buffer alignment of OUT endpoints USB requests. This is implemented by patches #1 and #2. That not just simplifies the driver code, but it also prevents nasty bugs when buflen is not aligned or even less than

[PATCH v3 0/9] Gadget endpoint request allocation and MIDI

As discussed with Baolin Wang, Michal Nazarewicz and Felipe Balbi. I propose the forced buffer alignment of OUT endpoints USB requests. This is implemented by patches #1 and #2. That not just simplifies the driver code, but it also prevents nasty bugs when buflen is not aligned or even less than

  1   2   3   4   5   6   7   8   9   >