Re: [PATCH] mm: ratelimit PFNs busy info message

On Wed, 2017-08-02 at 13:44 -0400, Jonathan Toppins wrote: > The RDMA subsystem can generate several thousand of these messages > per > second eventually leading to a kernel crash. Ratelimit these messages > to prevent this crash. > > Signed-off-by: Jonathan Toppins >

Re: [PATCH] mm: ratelimit PFNs busy info message

On Wed, 2017-08-02 at 13:44 -0400, Jonathan Toppins wrote: > The RDMA subsystem can generate several thousand of these messages > per > second eventually leading to a kernel crash. Ratelimit these messages > to prevent this crash. > > Signed-off-by: Jonathan Toppins > Reviewed-by: Doug Ledford

[PATCH v3 2/2] dm: allow device-mapper to operate without dax support

Rather than have device-mapper directly 'select DAX', let the fact that BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax support. We arrange for all the dax core routines to compile to nops when CONFIG_DAX=n. With that in place we can simply handle the alloc_dax() error as expected

[PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER

In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to 'select DAX', i.e. upgrade it from DAX=m

[PATCH v3 2/2] dm: allow device-mapper to operate without dax support

Rather than have device-mapper directly 'select DAX', let the fact that BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax support. We arrange for all the dax core routines to compile to nops when CONFIG_DAX=n. With that in place we can simply handle the alloc_dax() error as expected

[PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER

In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to 'select DAX', i.e. upgrade it from DAX=m

[PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper

Changes since v2 [1]: * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make sure dm_dax_flush() is called if device supports it" (kbuild robot) * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y (kbuild robot) [1]:

[PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper

Changes since v2 [1]: * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make sure dm_dax_flush() is called if device supports it" (kbuild robot) * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y (kbuild robot) [1]:

Re: [PATCH] staging: rtl8192e: Change fixed function names with "%s: ", __func__

On Thu, Aug 03, 2017 at 01:59:56AM +0800, vergilzhang wrote: > staging: rtl8192e: Fix coding style issue caught by checkpatch.pl related to > function name in debug print > > Signed-off-by: vergilzhang > --- > drivers/staging/rtl8192e/dot11d.c | 4 ++-- > 1 file

Re: [PATCH] staging: rtl8192e: Change fixed function names with "%s: ", __func__

On Thu, Aug 03, 2017 at 01:59:56AM +0800, vergilzhang wrote: > staging: rtl8192e: Fix coding style issue caught by checkpatch.pl related to > function name in debug print > > Signed-off-by: vergilzhang > --- > drivers/staging/rtl8192e/dot11d.c | 4 ++-- > 1 file changed, 2 insertions(+), 2

[PATCH] drm/fb: Fix pointer dereference before null check.

fb_crtc is used before a null check, so move the use after the null check. This was just identified by inspection. I haven't actually observed a crash here, so it is possible that the null check could be unnecessary. Signed-off-by: David Lechner ---

[PATCH] drm/fb: Fix pointer dereference before null check.

fb_crtc is used before a null check, so move the use after the null check. This was just identified by inspection. I haven't actually observed a crash here, so it is possible that the null check could be unnecessary. Signed-off-by: David Lechner --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1

[PATCH] thermal: intel_pch_thermal: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/thermal/intel_pch_thermal.c | 2 +- 1 file

[PATCH] thermal: intel_pch_thermal: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/thermal/intel_pch_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1

RE: [PATCH 0/3] constify char attribute_group structures

Why stop at these 3 users of attribute_group? --mark -Original Message- From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] Sent: Wednesday, August 2, 2017 4:19 AM To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark Cc: linux-kernel@vger.kernel.org

RE: [PATCH 0/3] constify char attribute_group structures

Why stop at these 3 users of attribute_group? --mark -Original Message- From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] Sent: Wednesday, August 2, 2017 4:19 AM To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark Cc: linux-kernel@vger.kernel.org Subject: [PATCH 0/3]

[PATCH 1/2] wlcore: add const to bin_attribute structure

Add const to bin_attribute structure as it is only passed to the functions sysfs_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structure to be const. Signed-off-by: Bhumika Goyal --- drivers/net/wireless/ti/wlcore/sysfs.c | 2 +- 1

[PATCH 2/2] qlcnic: add const to bin_attribute structure

Add const to bin_attribute structure as it is only passed to the functions sysfs_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structure to be const. Signed-off-by: Bhumika Goyal --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c

[PATCH 1/2] wlcore: add const to bin_attribute structure

Add const to bin_attribute structure as it is only passed to the functions sysfs_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structure to be const. Signed-off-by: Bhumika Goyal --- drivers/net/wireless/ti/wlcore/sysfs.c | 2 +- 1 file changed, 1

[PATCH 2/2] qlcnic: add const to bin_attribute structure

Add const to bin_attribute structure as it is only passed to the functions sysfs_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structure to be const. Signed-off-by: Bhumika Goyal --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +- 1 file

[PATCH] MAINTAINERS: openbmc mailing list is moderated

From: Randy Dunlap The openbmc mailing list is moderated for non-subscribers. Signed-off-by: Randy Dunlap Cc: Brendan Higgins Cc: Benjamin Herrenschmidt Cc: Joel Stanley ---

[PATCH] MAINTAINERS: openbmc mailing list is moderated

From: Randy Dunlap The openbmc mailing list is moderated for non-subscribers. Signed-off-by: Randy Dunlap Cc: Brendan Higgins Cc: Benjamin Herrenschmidt Cc: Joel Stanley --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-413-rc3.orig/MAINTAINERS +++

[PATCH 0/2] drivers/net: add const to bin_attribute structures

Declare bin_attribute structures as const. Bhumika Goyal (2): wlcore: add const to bin_attribute structure qlcnic: add const to bin_attribute structure drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +- drivers/net/wireless/ti/wlcore/sysfs.c| 2 +- 2 files changed, 2

[PATCH 0/2] drivers/net: add const to bin_attribute structures

Declare bin_attribute structures as const. Bhumika Goyal (2): wlcore: add const to bin_attribute structure qlcnic: add const to bin_attribute structure drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +- drivers/net/wireless/ti/wlcore/sysfs.c| 2 +- 2 files changed, 2

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

  Okay, here you go.  As you can tell, it's almost a trivial copy of the cxgb4 patch.     By the way, I realized that we have yet another hole which is likely not to be fixable.  If we're dealing with a problematic Root Complex, and we instantiate Virtual Functions and attach them to a Virtual

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

  Okay, here you go.  As you can tell, it's almost a trivial copy of the cxgb4 patch.     By the way, I realized that we have yet another hole which is likely not to be fixable.  If we're dealing with a problematic Root Complex, and we instantiate Virtual Functions and attach them to a Virtual

[PATCH] xfrm: policy: check policy direction value

The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used as an array index. This can lead to an out-of-bound access, kernel lockup and DoS. Add a check for the 'dir' value. This fixes CVE-2017-11600. References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928 Fixes:

[PATCH] xfrm: policy: check policy direction value

The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used as an array index. This can lead to an out-of-bound access, kernel lockup and DoS. Add a check for the 'dir' value. This fixes CVE-2017-11600. References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928 Fixes:

Re: [PATCH V6 2/2] PCI: handle CRS returned by device after FLR

On Wed, 2 Aug 2017 13:18:24 -0400 Sinan Kaya wrote: > An endpoint is allowed to issue Configuration Request Retry Status (CRS) > following a Function Level Reset (FLR) request to indicate that it is > not ready to accept new requests. CRS is defined in PCIe r3.1, sec

Re: [PATCH V6 2/2] PCI: handle CRS returned by device after FLR

On Wed, 2 Aug 2017 13:18:24 -0400 Sinan Kaya wrote: > An endpoint is allowed to issue Configuration Request Retry Status (CRS) > following a Function Level Reset (FLR) request to indicate that it is > not ready to accept new requests. CRS is defined in PCIe r3.1, sec 2.3.1. > Request Handling

Re: [PATCH v2 2/2] Implement sysfs based cpuinfo for x86 cpus.

On Wed, Aug 02, 2017 at 07:35:16PM +0200, Felix Schnizlein wrote: > Enable sysfs cpuinfo for x86 based cpus. Export often used cpu > information to sysfs. Stepping, cpu flags, cpu bugs, bogomips, > cpu family, vendor_id, model, and model_name are exported. > > Sysfs documentation is updated to

Re: [PATCH v2 2/2] Implement sysfs based cpuinfo for x86 cpus.

On Wed, Aug 02, 2017 at 07:35:16PM +0200, Felix Schnizlein wrote: > Enable sysfs cpuinfo for x86 based cpus. Export often used cpu > information to sysfs. Stepping, cpu flags, cpu bugs, bogomips, > cpu family, vendor_id, model, and model_name are exported. > > Sysfs documentation is updated to

Re: [PATCH tip/sched/core] swait: Remove the lockless swait_active() check in swake_up*()

On Wed, Aug 02, 2017 at 07:12:23PM +0200, Peter Zijlstra wrote: > On Wed, Aug 02, 2017 at 09:07:13AM -0700, Paul E. McKenney wrote: > > On Sun, Jul 30, 2017 at 09:47:35PM +0800, Boqun Feng wrote: > > > Steven Rostedt reported a potential race in RCU core because of > > > swake_up(): > > > > > >

Re: [PATCH tip/sched/core] swait: Remove the lockless swait_active() check in swake_up*()

On Wed, Aug 02, 2017 at 07:12:23PM +0200, Peter Zijlstra wrote: > On Wed, Aug 02, 2017 at 09:07:13AM -0700, Paul E. McKenney wrote: > > On Sun, Jul 30, 2017 at 09:47:35PM +0800, Boqun Feng wrote: > > > Steven Rostedt reported a potential race in RCU core because of > > > swake_up(): > > > > > >

[PATCH] xen-platform: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/xen/platform-pci.c | 2 +- 1 file changed, 1

[PATCH] xen-platform: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/xen/platform-pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

From: Hector Martin Date: Wed, 2 Aug 2017 00:45:44 +0900 > Signed-off-by: Hector Martin Applied.

Re: [PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

From: Hector Martin Date: Wed, 2 Aug 2017 00:45:44 +0900 > Signed-off-by: Hector Martin Applied.

[GIT PULL] Please pull JSON files for Power9 PMU events

Hi Arnaldo, Please pull some updates/cleanups to the POWER9 PMU events. The following changes since commit 81e3d8b2af2e7417f1d5164aab5c1a75955e8a5d: perf trace beautify ioctl: Beautify perf ioctl's 'cmd' arg (2017-08-01 13:33:50 -0300) are available in the git repository at:

[GIT PULL] Please pull JSON files for Power9 PMU events

Hi Arnaldo, Please pull some updates/cleanups to the POWER9 PMU events. The following changes since commit 81e3d8b2af2e7417f1d5164aab5c1a75955e8a5d: perf trace beautify ioctl: Beautify perf ioctl's 'cmd' arg (2017-08-01 13:33:50 -0300) are available in the git repository at:

Re: [PATCH] of: return of_get_cpu_node from of_cpu_device_node_get if CPUs are not registered

On 24/07/17 17:32, Sudeep Holla wrote: > > > On 24/07/17 17:00, Rob Herring wrote: >> On Mon, Jul 24, 2017 at 8:55 AM, Sudeep Holla wrote: >>> Instead of the callsites choosing between of_cpu_device_node_get if the >>> CPUs are registered as of_node is populated by then

Re: [PATCH] of: return of_get_cpu_node from of_cpu_device_node_get if CPUs are not registered

On 24/07/17 17:32, Sudeep Holla wrote: > > > On 24/07/17 17:00, Rob Herring wrote: >> On Mon, Jul 24, 2017 at 8:55 AM, Sudeep Holla wrote: >>> Instead of the callsites choosing between of_cpu_device_node_get if the >>> CPUs are registered as of_node is populated by then and of_get_cpu_node

[PATCH] mm: ratelimit PFNs busy info message

The RDMA subsystem can generate several thousand of these messages per second eventually leading to a kernel crash. Ratelimit these messages to prevent this crash. Signed-off-by: Jonathan Toppins Reviewed-by: Doug Ledford Tested-by: Doug Ledford

[PATCH] mm: ratelimit PFNs busy info message

The RDMA subsystem can generate several thousand of these messages per second eventually leading to a kernel crash. Ratelimit these messages to prevent this crash. Signed-off-by: Jonathan Toppins Reviewed-by: Doug Ledford Tested-by: Doug Ledford --- mm/page_alloc.c | 2 +- 1 file changed, 1

Re: [PATCH net-next] net: bcmgenet: drop COMPILE_TEST dependency

From: Arnd Bergmann Date: Tue, 1 Aug 2017 13:50:56 +0200 > The last patch added the dependency on 'OF && HAS_IOMEM' but left > COMPILE_TEST as an alternative, which kind of defeats the purpose > of adding the dependency, we still get randconfig build warnings: > > warning:

Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

Mimi Zohar writes: > On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote: >> --- a/security/integrity/ima/ima_appraise.c >> +++ b/security/integrity/ima/ima_appraise.c >> @@ -200,18 +200,40 @@ int ima_read_xattr(struct dentry *dentry, >> */ >> int

Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

Mimi Zohar writes: > On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote: >> --- a/security/integrity/ima/ima_appraise.c >> +++ b/security/integrity/ima/ima_appraise.c >> @@ -200,18 +200,40 @@ int ima_read_xattr(struct dentry *dentry, >> */ >> int ima_appraise_measurement(enum

Re: [PATCH net-next] net: bcmgenet: drop COMPILE_TEST dependency

From: Arnd Bergmann Date: Tue, 1 Aug 2017 13:50:56 +0200 > The last patch added the dependency on 'OF && HAS_IOMEM' but left > COMPILE_TEST as an alternative, which kind of defeats the purpose > of adding the dependency, we still get randconfig build warnings: > > warning: (NET_DSA_BCM_SF2 &&

Re: [PATCH v3 10/11] ARM64: dts: rockchip: Add gmac2phy node support for rk3328

On 08/01/2017 11:24 PM, David Wu wrote: > The gmac2phy controller of rk3328 is connected to internal phy > directly inside, add the node for the internal phy support. > > Signed-off-by: David Wu > --- > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 25

Re: [PATCH v3 10/11] ARM64: dts: rockchip: Add gmac2phy node support for rk3328

On 08/01/2017 11:24 PM, David Wu wrote: > The gmac2phy controller of rk3328 is connected to internal phy > directly inside, add the node for the internal phy support. > > Signed-off-by: David Wu > --- > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 25 + > 1 file changed,

Re: perf: bug in rdpmc/mmap accounting after exec

On Wed, Jul 26, 2017 at 03:39:01PM -0400, Vince Weaver wrote: > Hello > > so one last bug found by the PAPI testsuite. > > This one involves the rdpmc auto-disable on last unmap of an event > feature. > > Failing test case: > > fd=perf_event_open(); > addr=mmap(fd); > exec()

Re: perf: bug in rdpmc/mmap accounting after exec

On Wed, Jul 26, 2017 at 03:39:01PM -0400, Vince Weaver wrote: > Hello > > so one last bug found by the PAPI testsuite. > > This one involves the rdpmc auto-disable on last unmap of an event > feature. > > Failing test case: > > fd=perf_event_open(); > addr=mmap(fd); > exec()

Re: [PATCH v3 05/11] net: stmmac: dwmac-rk: Add internal phy support

On 08/01/2017 11:21 PM, David Wu wrote: > To make internal phy work, need to configure the phy_clock, > phy cru_reset and related registers. > > Signed-off-by: David Wu > --- > .../devicetree/bindings/net/rockchip-dwmac.txt | 6 +- >

Re: [PATCH v3 05/11] net: stmmac: dwmac-rk: Add internal phy support

On 08/01/2017 11:21 PM, David Wu wrote: > To make internal phy work, need to configure the phy_clock, > phy cru_reset and related registers. > > Signed-off-by: David Wu > --- > .../devicetree/bindings/net/rockchip-dwmac.txt | 6 +- > drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 81

Re: [PATCH 0/2] serial: 8250: add support for MediaTek BTIF controller

On Wed, 2017-08-02 at 20:14 +0300, Andy Shevchenko wrote: > On Thu, 2017-08-03 at 01:05 +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patchset introduces the support for MediaTek BTIF controller. > > > > MediaTek BTIF controller is the serial

Re: [PATCH 0/2] serial: 8250: add support for MediaTek BTIF controller

On Wed, 2017-08-02 at 20:14 +0300, Andy Shevchenko wrote: > On Thu, 2017-08-03 at 01:05 +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patchset introduces the support for MediaTek BTIF controller. > > > > MediaTek BTIF controller is the serial interface similar to UART

Re: [PATCH V2] hyperv: netvsc: Neaten netvsc_send_pkt by using a temporary

From: Joe Perches Date: Mon, 31 Jul 2017 10:30:54 -0700 > Repeated dereference of nvmsg.msg.v1_msg.send_rndis_pkt can be > shortened by using a temporary. Do so. > > No change in object code. > > Miscellanea: > > o Use * const for rpkt and nvchan > > Signed-off-by: Joe

Re: [PATCH V2] hyperv: netvsc: Neaten netvsc_send_pkt by using a temporary

From: Joe Perches Date: Mon, 31 Jul 2017 10:30:54 -0700 > Repeated dereference of nvmsg.msg.v1_msg.send_rndis_pkt can be > shortened by using a temporary. Do so. > > No change in object code. > > Miscellanea: > > o Use * const for rpkt and nvchan > > Signed-off-by: Joe Perches Applied to

Re: [PATCH -tip v8 3/4] irq: Make irqentry text section unconditional

Hi Masami, [auto build test ERROR on tip/x86/core] [also build test ERROR on v4.13-rc3 next-20170802] [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/Masami-Hiramatsu/kprobes-related-bugfix

Re: [PATCH -tip v8 3/4] irq: Make irqentry text section unconditional

Hi Masami, [auto build test ERROR on tip/x86/core] [also build test ERROR on v4.13-rc3 next-20170802] [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/Masami-Hiramatsu/kprobes-related-bugfix

Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

Hi Lorenzo, I ran a quick test and this seems to work for memory_address_limit < 64, however memory_address_limit == 64 yields a mask of 0x0. -Nate On 7/31/2017 11:23 AM, Lorenzo Pieralisi wrote: IORT named components provide firmware configuration describing how many address bits a given

Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

Hi Lorenzo, I ran a quick test and this seems to work for memory_address_limit < 64, however memory_address_limit == 64 yields a mask of 0x0. -Nate On 7/31/2017 11:23 AM, Lorenzo Pieralisi wrote: IORT named components provide firmware configuration describing how many address bits a given

Re: [PATCH RFC] arm64: introduce mm_context_t flags

On Wed, Aug 02, 2017 at 05:39:01PM +0100, Catalin Marinas wrote: > Hi Yury, > > On Mon, Jul 31, 2017 at 05:48:25PM +0300, Yury Norov wrote: > > In patch 06beb72fbe23e ("arm64: introduce mm context flag to keep 32 bit > > task > > information") you introduce the field flags but use it only for a

Re: [PATCH RFC] arm64: introduce mm_context_t flags

On Wed, Aug 02, 2017 at 05:39:01PM +0100, Catalin Marinas wrote: > Hi Yury, > > On Mon, Jul 31, 2017 at 05:48:25PM +0300, Yury Norov wrote: > > In patch 06beb72fbe23e ("arm64: introduce mm context flag to keep 32 bit > > task > > information") you introduce the field flags but use it only for a

Applied "ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk" to the asoc tree

The patch ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk" to the asoc tree

The patch ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk" to the asoc tree

The patch ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk" to the asoc tree

The patch ASoC: codecs: msm8916-wcd-digital: add support to set_sysclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: codecs: msm8916-wcd-digital: add CIC filter source selection path" to the asoc tree

The patch ASoC: codecs: msm8916-wcd-digital: add CIC filter source selection path has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "ASoC: qcom: apq8016-sbc: set default mclk rate" to the asoc tree

The patch ASoC: qcom: apq8016-sbc: set default mclk rate has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: codecs: msm8916-wcd-digital: add CIC filter source selection path" to the asoc tree

The patch ASoC: codecs: msm8916-wcd-digital: add CIC filter source selection path has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "ASoC: qcom: apq8016-sbc: set default mclk rate" to the asoc tree

The patch ASoC: qcom: apq8016-sbc: set default mclk rate has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

[PATCH 3/3] scsi: mptsas: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/message/fusion/mptsas.c | 2 +- 1 file changed, 1

[PATCH 1/3] scsi: mptfusion: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/message/fusion/mptspi.c | 2 +- 1 file changed, 1

[PATCH 3/3] scsi: mptsas: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/message/fusion/mptsas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 1/3] scsi: mptfusion: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/message/fusion/mptspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 2/3] scsi: mptfc: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/message/fusion/mptfc.c | 2 +- 1 file changed, 1

[PATCH 2/3] scsi: mptfc: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/message/fusion/mptfc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/3] constify scsi pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] scsi: mptfusion: constify pci_device_id. [PATCH 2/3] scsi: mptfc: constify

[PATCH 0/3] constify scsi pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] scsi: mptfusion: constify pci_device_id. [PATCH 2/3] scsi: mptfc: constify

Re: [PATCH V6 2/2] PCI: handle CRS returned by device after FLR

On 8/2/2017 1:18 PM, Sinan Kaya wrote: > pci_flr_wait() will keep > calling this function 60 times to allow up to 60 seconds to be consistent > with the rest of the kernel CRS timeout handling. I forgot to update the commit message. I'll wait until Bjorn/Alex reviews this version. -- Sinan Kaya

Re: [PATCH V6 2/2] PCI: handle CRS returned by device after FLR

On 8/2/2017 1:18 PM, Sinan Kaya wrote: > pci_flr_wait() will keep > calling this function 60 times to allow up to 60 seconds to be consistent > with the rest of the kernel CRS timeout handling. I forgot to update the commit message. I'll wait until Bjorn/Alex reviews this version. -- Sinan Kaya

Re: [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback

On 02/08/2017 19:08, John Stultz wrote: >> + bool (*read_with_stamp)(struct clocksource *cs, >> + u64 *cycles, u64 *cycles_stamp); >> u64 mask; > I'm not really fan of an interface that leaks magic data to users that > know enough. > > And its not clear

Re: [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback

On 02/08/2017 19:08, John Stultz wrote: >> + bool (*read_with_stamp)(struct clocksource *cs, >> + u64 *cycles, u64 *cycles_stamp); >> u64 mask; > I'm not really fan of an interface that leaks magic data to users that > know enough. > > And its not clear

[PATCH] drm/i915: add const to bin_attribute

Add const to bin_attribute structures as they are only passed to the functions sysfs_{remove/create}_bin_file or device_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structures to be const. Signed-off-by: Bhumika Goyal ---

[PATCH] drm/i915: add const to bin_attribute

Add const to bin_attribute structures as they are only passed to the functions sysfs_{remove/create}_bin_file or device_{remove/create}_bin_file. The corresponding arguments are of type const, so declare the structures to be const. Signed-off-by: Bhumika Goyal ---

Re: [PATCH 0/7] K2G: Add QSPI support

8/1/2017 10:52 PM, Vignesh R wrote: Hi, On Tuesday 01 August 2017 11:31 PM, Santosh Shilimkar wrote: On 7/31/2017 9:54 PM, Vignesh R wrote: This series adds support for Cadence QSPI for 66AK2G SoC. The first three patches enhance the cadence-quadspi driver to support loopback clock and

Re: [PATCH 0/7] K2G: Add QSPI support

8/1/2017 10:52 PM, Vignesh R wrote: Hi, On Tuesday 01 August 2017 11:31 PM, Santosh Shilimkar wrote: On 7/31/2017 9:54 PM, Vignesh R wrote: This series adds support for Cadence QSPI for 66AK2G SoC. The first three patches enhance the cadence-quadspi driver to support loopback clock and

Re: [PATCH 0/2] serial: 8250: add support for MediaTek BTIF controller

On Thu, 2017-08-03 at 01:05 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patchset introduces the support for MediaTek BTIF controller. > > MediaTek BTIF controller is the serial interface similar to UART but > it > works only as the digital device

Re: [PATCH 0/2] serial: 8250: add support for MediaTek BTIF controller

On Thu, 2017-08-03 at 01:05 +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patchset introduces the support for MediaTek BTIF controller. > > MediaTek BTIF controller is the serial interface similar to UART but > it > works only as the digital device which is mainly used to

[PATCH V6 2/2] PCI: handle CRS returned by device after FLR

An endpoint is allowed to issue Configuration Request Retry Status (CRS) following a Function Level Reset (FLR) request to indicate that it is not ready to accept new requests. CRS is defined in PCIe r3.1, sec 2.3.1. Request Handling Rules and CRS usage in FLR context is mentioned in PCIe r3.1,

[PATCH V6 2/2] PCI: handle CRS returned by device after FLR

An endpoint is allowed to issue Configuration Request Retry Status (CRS) following a Function Level Reset (FLR) request to indicate that it is not ready to accept new requests. CRS is defined in PCIe r3.1, sec 2.3.1. Request Handling Rules and CRS usage in FLR context is mentioned in PCIe r3.1,

[PATCH V6 1/2] PCI: limit FLR wait time to 100ms maximum

Code is currently allowing PCIe devices to extend polling time up to 1 second. Reducing the wait time for virtual functions to 100ms maximum to satisfy spec requirement mentioned in PCIe r3.1, sec 6.6.2. Function-Level Reset (FLR). SR-IOV r1.1, sec 2.2.2 also mentions that the virtual function's

[PATCH V6 1/2] PCI: limit FLR wait time to 100ms maximum

Code is currently allowing PCIe devices to extend polling time up to 1 second. Reducing the wait time for virtual functions to 100ms maximum to satisfy spec requirement mentioned in PCIe r3.1, sec 6.6.2. Function-Level Reset (FLR). SR-IOV r1.1, sec 2.2.2 also mentions that the virtual function's

[PATCH 2/9] [media] ttpci: budget: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by and work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/media/pci/ttpci/budget.c | 2 +- 1 file

[PATCH 2/9] [media] ttpci: budget: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by and work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/media/pci/ttpci/budget.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v3 1/7] integrity: Introduce struct evm_hmac_xattr

Hello Mimi, Thanks for your review! The patch at the end of the email implements your suggestions, what do you think? Mimi Zohar writes: > On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote: >> A separate struct evm_hmac_xattr is introduced, with the

Re: [PATCH v3 1/7] integrity: Introduce struct evm_hmac_xattr

Hello Mimi, Thanks for your review! The patch at the end of the email implements your suggestions, what do you think? Mimi Zohar writes: > On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote: >> A separate struct evm_hmac_xattr is introduced, with the original >> definition of

[PATCH 6/9] [media] ttpci: av7110: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by and work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/media/pci/ttpci/av7110.c | 2 +- 1 file

[PATCH 6/9] [media] ttpci: av7110: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by and work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/media/pci/ttpci/av7110.c | 2 +- 1 file changed, 1 insertion(+), 1

<    3   4   5   6   7   8   9   10   11   12   >