* Re: [PATCH] net/mlx5: fix tci mask filter
From: Yongseok Koh @ 2018-07-23 22:38 UTC (permalink / raw)
To: Nélio Laranjeiro; +Cc: dev@dpdk.org, Shahaf Shuler, stable@dpdk.org
In-Reply-To: <ea99ac4effbb0ab7ec01de2e068be910936fc1bf.1532330280.git.nelio.laranjeiro@6wind.com>
> On Jul 23, 2018, at 12:18 AM, Nelio Laranjeiro <nelio.laranjeiro@6wind.com> wrote:
>
> In mlx5_traffic_enable() the TCI mask for the VLAN is wrong causing the
> sub flow engine to reject the rule.
>
> Fixes: 272733b5ebfd ("net/mlx5: use flow to enable unicast traffic")
> Cc: stable@dpdk.org
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> ---
Acked-by: Yongseok Koh <yskoh@mellanox.com>
Thanks
^ permalink raw reply
* Re: [PATCH v7 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Jae Hyun Yoo @ 2018-07-23 22:36 UTC (permalink / raw)
To: Randy Dunlap, Jean Delvare, Guenter Roeck, Rob Herring,
Mark Rutland, Lee Jones, Joel Stanley, Andrew Jeffery,
Jonathan Corbet, Greg Kroah-Hartman, Gustavo Pimentel,
Kishon Vijay Abraham I, Lorenzo Pieralisi, Darrick J . Wong,
Eric Sandeen, Arnd Bergmann, Wu Hao, Tomohiro Kusumi,
Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Philippe Ombredanne,
Vinod Koul, Stephen Boyd, David Kershner, Uwe Kleine-Konig,
Sagar Dharia, Johan Hovold, Thomas Gleixner, Juergen Gross,
Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, James Feist, Jason M Biils,
Vernon Mauery
In-Reply-To: <c1abe3ec-fc26-d8b0-c769-e9295577ac05@infradead.org>
Hi Randy,
On 7/23/2018 3:21 PM, Randy Dunlap wrote:
> On 07/23/2018 02:47 PM, Jae Hyun Yoo wrote:
>> This commit adds PECI client MFD driver.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Andrew Jeffery <andrew@aj.id.au>
>> Cc: James Feist <james.feist@linux.intel.com>
>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>> Cc: Joel Stanley <joel@jms.id.au>
>> Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
>> ---
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/intel-peci-client.c | 182 ++++++++++++++++++++++++++
>> include/linux/mfd/intel-peci-client.h | 81 ++++++++++++
>> 4 files changed, 278 insertions(+)
>> create mode 100644 drivers/mfd/intel-peci-client.c
>> create mode 100644 include/linux/mfd/intel-peci-client.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index f3fa516011ec..e38b591479d4 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -595,6 +595,20 @@ config MFD_INTEL_MSIC
>> Passage) chip. This chip embeds audio, battery, GPIO, etc.
>> devices used in Intel Medfield platforms.
>>
>> +config MFD_INTEL_PECI_CLIENT
>> + bool "Intel PECI client"
>> + depends on (PECI || COMPILE_TEST)
>> + select MFD_CORE
>> + help
>> + If you say yes to this option, support will be included for the
>> + multi-funtional Intel PECI (Platform Environment Control Interface)
>
> multi-functional
>
Thanks for your pointing it out. Will fix it.
Thanks,
Jae
>> + client. PECI is a one-wire bus interface that provides a communication
>> + channel from PECI clients in Intel processors and chipset components
>> + to external monitoring or control devices.
>> +
>> + Additional drivers must be enabled in order to use the functionality
>> + of the device.
>> +
>> config MFD_IPAQ_MICRO
>> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
>> depends on SA1100_H3100 || SA1100_H3600
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Jae Hyun Yoo @ 2018-07-23 22:36 UTC (permalink / raw)
To: Randy Dunlap, Jean Delvare, Guenter Roeck, Rob Herring,
Mark Rutland, Lee Jones, Joel Stanley, Andrew Jeffery,
Jonathan Corbet, Greg Kroah-Hartman, Gustavo Pimentel,
Kishon Vijay Abraham I, Lorenzo Pieralisi, Darrick J . Wong,
Eric Sandeen, Arnd Bergmann, Wu Hao, Tomohiro Kusumi,
Bryant G . Ly, Frederic Barrat <fbarra>
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, James Feist, Jason M Biils,
Vernon Mauery
In-Reply-To: <c1abe3ec-fc26-d8b0-c769-e9295577ac05@infradead.org>
Hi Randy,
On 7/23/2018 3:21 PM, Randy Dunlap wrote:
> On 07/23/2018 02:47 PM, Jae Hyun Yoo wrote:
>> This commit adds PECI client MFD driver.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Andrew Jeffery <andrew@aj.id.au>
>> Cc: James Feist <james.feist@linux.intel.com>
>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>> Cc: Joel Stanley <joel@jms.id.au>
>> Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
>> ---
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/intel-peci-client.c | 182 ++++++++++++++++++++++++++
>> include/linux/mfd/intel-peci-client.h | 81 ++++++++++++
>> 4 files changed, 278 insertions(+)
>> create mode 100644 drivers/mfd/intel-peci-client.c
>> create mode 100644 include/linux/mfd/intel-peci-client.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index f3fa516011ec..e38b591479d4 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -595,6 +595,20 @@ config MFD_INTEL_MSIC
>> Passage) chip. This chip embeds audio, battery, GPIO, etc.
>> devices used in Intel Medfield platforms.
>>
>> +config MFD_INTEL_PECI_CLIENT
>> + bool "Intel PECI client"
>> + depends on (PECI || COMPILE_TEST)
>> + select MFD_CORE
>> + help
>> + If you say yes to this option, support will be included for the
>> + multi-funtional Intel PECI (Platform Environment Control Interface)
>
> multi-functional
>
Thanks for your pointing it out. Will fix it.
Thanks,
Jae
>> + client. PECI is a one-wire bus interface that provides a communication
>> + channel from PECI clients in Intel processors and chipset components
>> + to external monitoring or control devices.
>> +
>> + Additional drivers must be enabled in order to use the functionality
>> + of the device.
>> +
>> config MFD_IPAQ_MICRO
>> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
>> depends on SA1100_H3100 || SA1100_H3600
>
>
^ permalink raw reply
* [PATCH v7 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Jae Hyun Yoo @ 2018-07-23 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1abe3ec-fc26-d8b0-c769-e9295577ac05@infradead.org>
Hi Randy,
On 7/23/2018 3:21 PM, Randy Dunlap wrote:
> On 07/23/2018 02:47 PM, Jae Hyun Yoo wrote:
>> This commit adds PECI client MFD driver.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Andrew Jeffery <andrew@aj.id.au>
>> Cc: James Feist <james.feist@linux.intel.com>
>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>> Cc: Joel Stanley <joel@jms.id.au>
>> Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
>> ---
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/intel-peci-client.c | 182 ++++++++++++++++++++++++++
>> include/linux/mfd/intel-peci-client.h | 81 ++++++++++++
>> 4 files changed, 278 insertions(+)
>> create mode 100644 drivers/mfd/intel-peci-client.c
>> create mode 100644 include/linux/mfd/intel-peci-client.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index f3fa516011ec..e38b591479d4 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -595,6 +595,20 @@ config MFD_INTEL_MSIC
>> Passage) chip. This chip embeds audio, battery, GPIO, etc.
>> devices used in Intel Medfield platforms.
>>
>> +config MFD_INTEL_PECI_CLIENT
>> + bool "Intel PECI client"
>> + depends on (PECI || COMPILE_TEST)
>> + select MFD_CORE
>> + help
>> + If you say yes to this option, support will be included for the
>> + multi-funtional Intel PECI (Platform Environment Control Interface)
>
> multi-functional
>
Thanks for your pointing it out. Will fix it.
Thanks,
Jae
>> + client. PECI is a one-wire bus interface that provides a communication
>> + channel from PECI clients in Intel processors and chipset components
>> + to external monitoring or control devices.
>> +
>> + Additional drivers must be enabled in order to use the functionality
>> + of the device.
>> +
>> config MFD_IPAQ_MICRO
>> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
>> depends on SA1100_H3100 || SA1100_H3600
>
>
^ permalink raw reply
* Re: [PATCH v7 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Jae Hyun Yoo @ 2018-07-23 22:36 UTC (permalink / raw)
To: Randy Dunlap, Jean Delvare, Guenter Roeck, Rob Herring,
Mark Rutland, Lee Jones, Joel Stanley, Andrew Jeffery,
Jonathan Corbet, Greg Kroah-Hartman, Gustavo Pimentel,
Kishon Vijay Abraham I, Lorenzo Pieralisi, Darrick J . Wong,
Eric Sandeen, Arnd Bergmann, Wu Hao, Tomohiro Kusumi,
Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Philippe Ombredanne,
Vinod Koul, Stephen Boyd, David Kershner, Uwe Kleine-Konig,
Sagar Dharia, Johan Hovold, Thomas Gleixner, Juergen Gross,
Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, James Feist, Jason M Biils,
Vernon Mauery
In-Reply-To: <c1abe3ec-fc26-d8b0-c769-e9295577ac05@infradead.org>
Hi Randy,
On 7/23/2018 3:21 PM, Randy Dunlap wrote:
> On 07/23/2018 02:47 PM, Jae Hyun Yoo wrote:
>> This commit adds PECI client MFD driver.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Andrew Jeffery <andrew@aj.id.au>
>> Cc: James Feist <james.feist@linux.intel.com>
>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>> Cc: Joel Stanley <joel@jms.id.au>
>> Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
>> ---
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/intel-peci-client.c | 182 ++++++++++++++++++++++++++
>> include/linux/mfd/intel-peci-client.h | 81 ++++++++++++
>> 4 files changed, 278 insertions(+)
>> create mode 100644 drivers/mfd/intel-peci-client.c
>> create mode 100644 include/linux/mfd/intel-peci-client.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index f3fa516011ec..e38b591479d4 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -595,6 +595,20 @@ config MFD_INTEL_MSIC
>> Passage) chip. This chip embeds audio, battery, GPIO, etc.
>> devices used in Intel Medfield platforms.
>>
>> +config MFD_INTEL_PECI_CLIENT
>> + bool "Intel PECI client"
>> + depends on (PECI || COMPILE_TEST)
>> + select MFD_CORE
>> + help
>> + If you say yes to this option, support will be included for the
>> + multi-funtional Intel PECI (Platform Environment Control Interface)
>
> multi-functional
>
Thanks for your pointing it out. Will fix it.
Thanks,
Jae
>> + client. PECI is a one-wire bus interface that provides a communication
>> + channel from PECI clients in Intel processors and chipset components
>> + to external monitoring or control devices.
>> +
>> + Additional drivers must be enabled in order to use the functionality
>> + of the device.
>> +
>> config MFD_IPAQ_MICRO
>> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
>> depends on SA1100_H3100 || SA1100_H3600
>
>
^ permalink raw reply
* [PATCH v7 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Jae Hyun Yoo @ 2018-07-23 22:36 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <c1abe3ec-fc26-d8b0-c769-e9295577ac05@infradead.org>
Hi Randy,
On 7/23/2018 3:21 PM, Randy Dunlap wrote:
> On 07/23/2018 02:47 PM, Jae Hyun Yoo wrote:
>> This commit adds PECI client MFD driver.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Andrew Jeffery <andrew@aj.id.au>
>> Cc: James Feist <james.feist@linux.intel.com>
>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>> Cc: Joel Stanley <joel@jms.id.au>
>> Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
>> ---
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/intel-peci-client.c | 182 ++++++++++++++++++++++++++
>> include/linux/mfd/intel-peci-client.h | 81 ++++++++++++
>> 4 files changed, 278 insertions(+)
>> create mode 100644 drivers/mfd/intel-peci-client.c
>> create mode 100644 include/linux/mfd/intel-peci-client.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index f3fa516011ec..e38b591479d4 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -595,6 +595,20 @@ config MFD_INTEL_MSIC
>> Passage) chip. This chip embeds audio, battery, GPIO, etc.
>> devices used in Intel Medfield platforms.
>>
>> +config MFD_INTEL_PECI_CLIENT
>> + bool "Intel PECI client"
>> + depends on (PECI || COMPILE_TEST)
>> + select MFD_CORE
>> + help
>> + If you say yes to this option, support will be included for the
>> + multi-funtional Intel PECI (Platform Environment Control Interface)
>
> multi-functional
>
Thanks for your pointing it out. Will fix it.
Thanks,
Jae
>> + client. PECI is a one-wire bus interface that provides a communication
>> + channel from PECI clients in Intel processors and chipset components
>> + to external monitoring or control devices.
>> +
>> + Additional drivers must be enabled in order to use the functionality
>> + of the device.
>> +
>> config MFD_IPAQ_MICRO
>> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
>> depends on SA1100_H3100 || SA1100_H3600
>
>
^ permalink raw reply
* Re: [Intel-gfx] [drm-tip:drm-tip 7/8] debug.c:undefined reference to `save_stack_trace'
From: Rodrigo Vivi @ 2018-07-23 22:36 UTC (permalink / raw)
To: kbuild test robot, Vetter, Daniel; +Cc: intel-gfx, kbuild-all, dri-devel
In-Reply-To: <201807211123.JXxAXvzn%fengguang.wu@intel.com>
On Sat, Jul 21, 2018 at 11:30:27AM +0800, kbuild test robot wrote:
> Hi Rodrigo,
>
> It's probably a bug fix that unveils the link errors.
>
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 20532651221ed29af16e2db0a7ec8b9bd482c994
> commit: 315fade0d9f3edbf2592599056c8defbdd95a3ab [7/8] Merge remote-tracking branch 'drm-intel/topic/core-for-CI' into drm-tip
> config: m68k-allyesconfig (attached as .config)
> compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 315fade0d9f3edbf2592599056c8defbdd95a3ab
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=m68k
>
> All errors (new ones prefixed by >>):
>
> kernel/dma/debug.o: In function `dma_entry_alloc':
> >> debug.c:(.text+0x11d2): undefined reference to `save_stack_trace'
> kernel/backtracetest.o: In function `backtrace_regression_test':
> >> backtracetest.c:(.text+0xd8): undefined reference to `save_stack_trace'
> mm/slub.o: In function `set_track':
> >> slub.c:(.text+0x12b4): undefined reference to `save_stack_trace'
> fs/btrfs/ref-verify.o: In function `btrfs_ref_tree_mod':
> >> ref-verify.c:(.text+0x92e): undefined reference to `save_stack_trace'
> lib/debugobjects.o: In function `save_stack.isra.0':
> >> debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace'
probably this?
commit 3ef9e3d575a2b725e5783fd57192ceb573359a33
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Mar 20 17:02:58 2018 +0100
RFC: debugobjects: capture stack traces at _init() time
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] bpf: Add Python 3 support to selftests scripts for bpf
From: Daniel Borkmann @ 2018-07-23 22:36 UTC (permalink / raw)
To: Dan Rue, Jeremy Cline
Cc: Alexei Starovoitov, Shuah Khan, netdev, linux-kernel,
linux-kselftest, Lawrence Brakmo, jakub.kicinski
In-Reply-To: <20180723173313.ri2uz7srtdtno2hl@linode.therub.org>
On 07/23/2018 07:33 PM, Dan Rue wrote:
> On Mon, Jul 23, 2018 at 10:08:57AM -0400, Jeremy Cline wrote:
>> On 07/20/2018 04:45 PM, Daniel Borkmann wrote:
>>> On 07/18/2018 11:36 PM, Jeremy Cline wrote:
>>>> Adjust tcp_client.py and tcp_server.py to work with Python 3 by using
>>>> the print function, marking string literals as bytes, and using the
>>>> newer exception syntax. This should be functionally equivalent and
>>>> support Python 2.6 through Python 3.7.
>>>>
>>>> Signed-off-by: Jeremy Cline <jcline@redhat.com>
>>>
>>> Thanks for the patch, Jeremy! Given we also have test_offload.py in BPF
>>> kselftests and it is written for python 3 only, it would probably make
>>> sense to adapt the tcp_{client,server}.py towards python 3 as well, so
>>> we wouldn't need to keep extra compat for 2 and have a consistent version
>>> dependency. Lawrence / Jeremy, any objections?
>>
>> I certainly don't object to Python 3 only and I'm happy to drop the
>> Python 2 compatibility from this patch if that's okay.
Sounds good, lets do it, please respin with that.
> This (well, along with introducing python in the first place, which took
> me by surprise), sounds like a policy decision that should be made clear
> in the kselftest documentation (Documentation/dev-tools/kselftest.rst).
> Currently, that file does not mention any python requirement.
Right now each selftest subdir has a config file which lists dependencies,
perhaps it makes sense to have another standardized file there (e.g. 'deps')
which lists user space dependencies, so it's immediately visible what is
needed to run all tests from there. Thoughts?
> That said, I agree that python2 support is no longer necessary.
>
> My use-case (which may be unusual?): We try to run all of kselftest
> against a variety of kernels and architectures for every push to next,
> mainline, and stable/lts branches. It seems that this is not a common
> usecase, but shouldn't it be?
As far as I'm aware the intel lkp-tests bot seems also to regularly run
the kselftests for x86, if also done from arm side e.g. on latest mainline,
even better.
Thanks,
Daniel
^ permalink raw reply
* [PATCH] bpf: Add Python 3 support to selftests scripts for bpf
From: Daniel Borkmann @ 2018-07-23 22:36 UTC (permalink / raw)
In-Reply-To: <20180723173313.ri2uz7srtdtno2hl@linode.therub.org>
On 07/23/2018 07:33 PM, Dan Rue wrote:
> On Mon, Jul 23, 2018@10:08:57AM -0400, Jeremy Cline wrote:
>> On 07/20/2018 04:45 PM, Daniel Borkmann wrote:
>>> On 07/18/2018 11:36 PM, Jeremy Cline wrote:
>>>> Adjust tcp_client.py and tcp_server.py to work with Python 3 by using
>>>> the print function, marking string literals as bytes, and using the
>>>> newer exception syntax. This should be functionally equivalent and
>>>> support Python 2.6 through Python 3.7.
>>>>
>>>> Signed-off-by: Jeremy Cline <jcline at redhat.com>
>>>
>>> Thanks for the patch, Jeremy! Given we also have test_offload.py in BPF
>>> kselftests and it is written for python 3 only, it would probably make
>>> sense to adapt the tcp_{client,server}.py towards python 3 as well, so
>>> we wouldn't need to keep extra compat for 2 and have a consistent version
>>> dependency. Lawrence / Jeremy, any objections?
>>
>> I certainly don't object to Python 3 only and I'm happy to drop the
>> Python 2 compatibility from this patch if that's okay.
Sounds good, lets do it, please respin with that.
> This (well, along with introducing python in the first place, which took
> me by surprise), sounds like a policy decision that should be made clear
> in the kselftest documentation (Documentation/dev-tools/kselftest.rst).
> Currently, that file does not mention any python requirement.
Right now each selftest subdir has a config file which lists dependencies,
perhaps it makes sense to have another standardized file there (e.g. 'deps')
which lists user space dependencies, so it's immediately visible what is
needed to run all tests from there. Thoughts?
> That said, I agree that python2 support is no longer necessary.
>
> My use-case (which may be unusual?): We try to run all of kselftest
> against a variety of kernels and architectures for every push to next,
> mainline, and stable/lts branches. It seems that this is not a common
> usecase, but shouldn't it be?
As far as I'm aware the intel lkp-tests bot seems also to regularly run
the kselftests for x86, if also done from arm side e.g. on latest mainline,
even better.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] bpf: Add Python 3 support to selftests scripts for bpf
From: daniel @ 2018-07-23 22:36 UTC (permalink / raw)
In-Reply-To: <20180723173313.ri2uz7srtdtno2hl@linode.therub.org>
On 07/23/2018 07:33 PM, Dan Rue wrote:
> On Mon, Jul 23, 2018 at 10:08:57AM -0400, Jeremy Cline wrote:
>> On 07/20/2018 04:45 PM, Daniel Borkmann wrote:
>>> On 07/18/2018 11:36 PM, Jeremy Cline wrote:
>>>> Adjust tcp_client.py and tcp_server.py to work with Python 3 by using
>>>> the print function, marking string literals as bytes, and using the
>>>> newer exception syntax. This should be functionally equivalent and
>>>> support Python 2.6 through Python 3.7.
>>>>
>>>> Signed-off-by: Jeremy Cline <jcline at redhat.com>
>>>
>>> Thanks for the patch, Jeremy! Given we also have test_offload.py in BPF
>>> kselftests and it is written for python 3 only, it would probably make
>>> sense to adapt the tcp_{client,server}.py towards python 3 as well, so
>>> we wouldn't need to keep extra compat for 2 and have a consistent version
>>> dependency. Lawrence / Jeremy, any objections?
>>
>> I certainly don't object to Python 3 only and I'm happy to drop the
>> Python 2 compatibility from this patch if that's okay.
Sounds good, lets do it, please respin with that.
> This (well, along with introducing python in the first place, which took
> me by surprise), sounds like a policy decision that should be made clear
> in the kselftest documentation (Documentation/dev-tools/kselftest.rst).
> Currently, that file does not mention any python requirement.
Right now each selftest subdir has a config file which lists dependencies,
perhaps it makes sense to have another standardized file there (e.g. 'deps')
which lists user space dependencies, so it's immediately visible what is
needed to run all tests from there. Thoughts?
> That said, I agree that python2 support is no longer necessary.
>
> My use-case (which may be unusual?): We try to run all of kselftest
> against a variety of kernels and architectures for every push to next,
> mainline, and stable/lts branches. It seems that this is not a common
> usecase, but shouldn't it be?
As far as I'm aware the intel lkp-tests bot seems also to regularly run
the kselftests for x86, if also done from arm side e.g. on latest mainline,
even better.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 07/10] Input: atmel_mxt_ts - zero terminate config firmware file
From: Dmitry Torokhov @ 2018-07-23 22:35 UTC (permalink / raw)
To: Nick Dyer
Cc: linux-kernel, linux-input, Chris Healy, Nikita Yushchenko,
Lucas Stach, Nick Dyer
In-Reply-To: <20180720215122.23558-7-nick@shmanahar.org>
On Fri, Jul 20, 2018 at 10:51:19PM +0100, Nick Dyer wrote:
> From: Nick Dyer <nick.dyer@itdev.co.uk>
>
> We use sscanf to parse the configuration file, so it's necessary to zero
> terminate the configuration otherwise a truncated file can cause the
> parser to run off into uninitialised memory.
>
> Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 36 +++++++++++++++++-------
> 1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 0ce126e918f1..2d1fddafb7f9 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -279,7 +279,7 @@ enum mxt_suspend_mode {
>
> /* Config update context */
> struct mxt_cfg {
> - const u8 *raw;
> + u8 *raw;
> size_t raw_size;
> off_t raw_pos;
>
> @@ -1451,14 +1451,21 @@ static int mxt_update_cfg(struct mxt_data *data, const struct firmware *fw)
> u32 info_crc, config_crc, calculated_crc;
> u16 crc_start = 0;
>
> - cfg.raw = fw->data;
> + /* Make zero terminated copy of the OBP_RAW file */
> + cfg.raw = kzalloc(fw->size + 1, GFP_KERNEL);
kmemdup_nul()? I guess config it not that big to be concerned with
kmalloc() vs vmalloc() and allocation failures...
> + if (!cfg.raw)
> + return -ENOMEM;
> +
> + memcpy(cfg.raw, fw->data, fw->size);
> + cfg.raw[fw->size] = '\0';
> cfg.raw_size = fw->size;
>
> mxt_update_crc(data, MXT_COMMAND_REPORTALL, 1);
>
> if (strncmp(cfg.raw, MXT_CFG_MAGIC, strlen(MXT_CFG_MAGIC))) {
> dev_err(dev, "Unrecognised config file\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto release_raw;
> }
>
> cfg.raw_pos = strlen(MXT_CFG_MAGIC);
> @@ -1470,7 +1477,8 @@ static int mxt_update_cfg(struct mxt_data *data, const struct firmware *fw)
> &offset);
> if (ret != 1) {
> dev_err(dev, "Bad format\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto release_raw;
> }
>
> cfg.raw_pos += offset;
> @@ -1478,26 +1486,30 @@ static int mxt_update_cfg(struct mxt_data *data, const struct firmware *fw)
>
> if (cfg.info.family_id != data->info->family_id) {
> dev_err(dev, "Family ID mismatch!\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto release_raw;
> }
>
> if (cfg.info.variant_id != data->info->variant_id) {
> dev_err(dev, "Variant ID mismatch!\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto release_raw;
> }
>
> /* Read CRCs */
> ret = sscanf(cfg.raw + cfg.raw_pos, "%x%n", &info_crc, &offset);
> if (ret != 1) {
> dev_err(dev, "Bad format: failed to parse Info CRC\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto release_raw;
> }
> cfg.raw_pos += offset;
>
> ret = sscanf(cfg.raw + cfg.raw_pos, "%x%n", &config_crc, &offset);
> if (ret != 1) {
> dev_err(dev, "Bad format: failed to parse Config CRC\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto release_raw;
> }
> cfg.raw_pos += offset;
>
> @@ -1530,8 +1542,10 @@ static int mxt_update_cfg(struct mxt_data *data, const struct firmware *fw)
> MXT_INFO_CHECKSUM_SIZE;
> cfg.mem_size = data->mem_size - cfg.start_ofs;
> cfg.mem = kzalloc(cfg.mem_size, GFP_KERNEL);
> - if (!cfg.mem)
> - return -ENOMEM;
> + if (!cfg.mem) {
> + ret = -ENOMEM;
> + goto release_raw;
> + }
>
> ret = mxt_prepare_cfg_mem(data, &cfg);
> if (ret)
> @@ -1570,6 +1584,8 @@ static int mxt_update_cfg(struct mxt_data *data, const struct firmware *fw)
> /* T7 config may have changed */
> mxt_init_t7_power_cfg(data);
>
> +release_raw:
> + kfree(cfg.raw);
> release_mem:
> kfree(cfg.mem);
> return ret;
> --
> 2.17.1
>
--
Dmitry
^ permalink raw reply
* [patch -mm] mm, vmacache: hash addresses based on pmd fix
From: David Rientjes @ 2018-07-23 22:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: kbuild-all, lkp, Johannes Weiner, linux-mm
- use PMD_SHIFT only if CONFIG_MMU is used, otherwise there is only pgdir,
per kbuild test robot
- fix vmacache_find_exact() for correct formal name, per me
- only check vma->vm_mm == mm for CONFIG_DEBUG_VM_VMACACHE, per akpm
Tested for {allnoconfig, defconfig} on alpha, arc, arm, arm64, c6x, h8300,
i386, ia64, m68k, microblaze, mips, mips, nds32, nios2, parisc, powerpc,
riscv, s390, sh, sparc, um, and xtensa.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: David Rientjes <rientjes@google.com>
---
mm/vmacache.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/mm/vmacache.c b/mm/vmacache.c
--- a/mm/vmacache.c
+++ b/mm/vmacache.c
@@ -6,12 +6,18 @@
#include <linux/sched/task.h>
#include <linux/mm.h>
#include <linux/vmacache.h>
+#include <asm/pgtable.h>
/*
- * Hash based on the pmd of addr. Provides a good hit rate for workloads with
- * spatial locality.
+ * Hash based on the pmd of addr if configured with MMU, which provides a good
+ * hit rate for workloads with spatial locality. Otherwise, use pages.
*/
-#define VMACACHE_HASH(addr) ((addr >> PMD_SHIFT) & VMACACHE_MASK)
+#ifdef CONFIG_MMU
+#define VMACACHE_SHIFT PMD_SHIFT
+#else
+#define VMACACHE_SHIFT PAGE_SHIFT
+#endif
+#define VMACACHE_HASH(addr) ((addr >> VMACACHE_SHIFT) & VMACACHE_MASK)
/*
* Flush vma caches for threads that share a given mm.
@@ -105,8 +111,10 @@ struct vm_area_struct *vmacache_find(struct mm_struct *mm, unsigned long addr)
struct vm_area_struct *vma = current->vmacache.vmas[idx];
if (vma) {
+#ifdef CONFIG_DEBUG_VM_VMACACHE
if (WARN_ON_ONCE(vma->vm_mm != mm))
break;
+#endif
if (vma->vm_start <= addr && vma->vm_end > addr) {
count_vm_vmacache_event(VMACACHE_FIND_HITS);
return vma;
@@ -124,7 +132,7 @@ struct vm_area_struct *vmacache_find_exact(struct mm_struct *mm,
unsigned long start,
unsigned long end)
{
- int idx = VMACACHE_HASH(addr);
+ int idx = VMACACHE_HASH(start);
int i;
count_vm_vmacache_event(VMACACHE_FIND_CALLS);
^ permalink raw reply
* [alternative-merged] mm-fix-vma_is_anonymous-false-positives.patch removed from -mm tree
From: akpm @ 2018-07-23 21:30 UTC (permalink / raw)
To: aarcange, akpm, dvyukov, kirill.shutemov, marcel.ziswiler,
mm-commits, oleg, stable
The patch titled
Subject: mm: fix vma_is_anonymous() false-positives
has been removed from the -mm tree. Its filename was
mm-fix-vma_is_anonymous-false-positives.patch
This patch was dropped because an alternative patch was merged
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: mm: fix vma_is_anonymous() false-positives
vma_is_anonymous() relies on ->vm_ops being NULL to detect anonymous VMA.
This is unreliable as ->mmap may not set ->vm_ops.
False-positive vma_is_anonymous() may lead to crashes:
next ffff8801ce5e7040 prev ffff8801d20eca50 mm ffff88019c1e13c0
prot 27 anon_vma ffff88019680cdd8 vm_ops 0000000000000000
pgoff 0 file ffff8801b2ec2d00 private_data 0000000000000000
flags: 0xff(read|write|exec|shared|mayread|maywrite|mayexec|mayshare)
------------[ cut here ]------------
kernel BUG at mm/memory.c:1422!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 18486 Comm: syz-executor3 Not tainted 4.18.0-rc3+ #136
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:zap_pmd_range mm/memory.c:1421 [inline]
RIP: 0010:zap_pud_range mm/memory.c:1466 [inline]
RIP: 0010:zap_p4d_range mm/memory.c:1487 [inline]
RIP: 0010:unmap_page_range+0x1c18/0x2220 mm/memory.c:1508
Code: ff 31 ff 4c 89 e6 42 c6 04 33 f8 e8 92 dd d0 ff 4d 85 e4 0f 85 4a eb ff
ff e8 54 dc d0 ff 48 8b bd 10 fc ff ff e8 82 95 fe ff <0f> 0b e8 41 dc d0 ff
0f 0b 4c 89 ad 18 fc ff ff c7 85 7c fb ff ff
RSP: 0018:ffff8801b0587330 EFLAGS: 00010286
RAX: 000000000000013c RBX: 1ffff100360b0e9c RCX: ffffc90002620000
RDX: 0000000000000000 RSI: ffffffff81631851 RDI: 0000000000000001
RBP: ffff8801b05877c8 R08: ffff880199d40300 R09: ffffed003b5c4fc0
R10: ffffed003b5c4fc0 R11: ffff8801dae27e07 R12: 0000000000000000
R13: ffff88019c1e13c0 R14: dffffc0000000000 R15: 0000000020e01000
FS: 00007fca32251700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f04c540d000 CR3: 00000001ac1f0000 CR4: 00000000001426f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
unmap_single_vma+0x1a0/0x310 mm/memory.c:1553
zap_page_range_single+0x3cc/0x580 mm/memory.c:1644
unmap_mapping_range_vma mm/memory.c:2792 [inline]
unmap_mapping_range_tree mm/memory.c:2813 [inline]
unmap_mapping_pages+0x3a7/0x5b0 mm/memory.c:2845
unmap_mapping_range+0x48/0x60 mm/memory.c:2880
truncate_pagecache+0x54/0x90 mm/truncate.c:800
truncate_setsize+0x70/0xb0 mm/truncate.c:826
simple_setattr+0xe9/0x110 fs/libfs.c:409
notify_change+0xf13/0x10f0 fs/attr.c:335
do_truncate+0x1ac/0x2b0 fs/open.c:63
do_sys_ftruncate+0x492/0x560 fs/open.c:205
__do_sys_ftruncate fs/open.c:215 [inline]
__se_sys_ftruncate fs/open.c:213 [inline]
__x64_sys_ftruncate+0x59/0x80 fs/open.c:213
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reproducer:
#include <stdio.h>
#include <stddef.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <unistd.h>
#include <fcntl.h>
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
#define KCOV_ENABLE _IO('c', 100)
#define KCOV_DISABLE _IO('c', 101)
#define COVER_SIZE (1024<<10)
#define KCOV_TRACE_PC 0
#define KCOV_TRACE_CMP 1
int main(int argc, char **argv)
{
int fd;
unsigned long *cover;
system("mount -t debugfs none /sys/kernel/debug");
fd = open("/sys/kernel/debug/kcov", O_RDWR);
ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE);
cover = mmap(NULL, COVER_SIZE * sizeof(unsigned long),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
munmap(cover, COVER_SIZE * sizeof(unsigned long));
cover = mmap(NULL, COVER_SIZE * sizeof(unsigned long),
PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
memset(cover, 0, COVER_SIZE * sizeof(unsigned long));
ftruncate(fd, 3UL << 20);
return 0;
}
This can be fixed by assigning anonymous VMAs own vm_ops and not relying
on it being NULL.
If ->mmap() failed to set ->vm_ops, mmap_region() will set it to
dummy_vm_ops. This way we will have non-NULL ->vm_ops for all VMAs.
[kirill@shutemov.name: add comments]
Link: http://lkml.kernel.org/r/20180711121521.omugjfpuuyxscjjf@kshutemo-mobl1
[kirill.shutemov@linux.intel.com: v2]
Link: http://lkml.kernel.org/r/20180712145626.41665-2-kirill.shutemov@linux.intel.com
[kirill.shutemov@linux.intel.com: fix splat reported by Marcel]
Link: http://lkml.kernel.org/r/20180716142049.ioa2irsd2d7sphn4@black.fi.intel.com
Link: http://lkml.kernel.org/r/20180710134821.84709-2-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: syzbot+3f84280d52be9b7083cc@syzkaller.appspotmail.com
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/arm/kernel/process.c | 1 +
arch/ia64/kernel/perfmon.c | 1 +
arch/ia64/mm/init.c | 2 ++
drivers/char/mem.c | 1 +
fs/exec.c | 1 +
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 5 ++++-
mm/khugepaged.c | 4 ++--
mm/mmap.c | 11 +++++++++++
mm/nommu.c | 9 ++++++++-
mm/shmem.c | 1 +
mm/util.c | 12 ++++++++++++
12 files changed, 45 insertions(+), 4 deletions(-)
diff -puN arch/arm/kernel/process.c~mm-fix-vma_is_anonymous-false-positives arch/arm/kernel/process.c
--- a/arch/arm/kernel/process.c~mm-fix-vma_is_anonymous-false-positives
+++ a/arch/arm/kernel/process.c
@@ -334,6 +334,7 @@ static struct vm_area_struct gate_vma =
.vm_start = 0xffff0000,
.vm_end = 0xffff0000 + PAGE_SIZE,
.vm_flags = VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYEXEC,
+ .vm_ops = &dummy_vm_ops,
};
static int __init gate_vma_init(void)
diff -puN arch/ia64/kernel/perfmon.c~mm-fix-vma_is_anonymous-false-positives arch/ia64/kernel/perfmon.c
--- a/arch/ia64/kernel/perfmon.c~mm-fix-vma_is_anonymous-false-positives
+++ a/arch/ia64/kernel/perfmon.c
@@ -2292,6 +2292,7 @@ pfm_smpl_buffer_alloc(struct task_struct
vma->vm_file = get_file(filp);
vma->vm_flags = VM_READ|VM_MAYREAD|VM_DONTEXPAND|VM_DONTDUMP;
vma->vm_page_prot = PAGE_READONLY; /* XXX may need to change */
+ vma->vm_ops = &dummy_vm_ops;
/*
* Now we have everything we need and we can initialize
diff -puN arch/ia64/mm/init.c~mm-fix-vma_is_anonymous-false-positives arch/ia64/mm/init.c
--- a/arch/ia64/mm/init.c~mm-fix-vma_is_anonymous-false-positives
+++ a/arch/ia64/mm/init.c
@@ -122,6 +122,7 @@ ia64_init_addr_space (void)
vma->vm_end = vma->vm_start + PAGE_SIZE;
vma->vm_flags = VM_DATA_DEFAULT_FLAGS|VM_GROWSUP|VM_ACCOUNT;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ vma->vm_ops = &dummy_vm_ops;
down_write(¤t->mm->mmap_sem);
if (insert_vm_struct(current->mm, vma)) {
up_write(¤t->mm->mmap_sem);
@@ -141,6 +142,7 @@ ia64_init_addr_space (void)
vma->vm_page_prot = __pgprot(pgprot_val(PAGE_READONLY) | _PAGE_MA_NAT);
vma->vm_flags = VM_READ | VM_MAYREAD | VM_IO |
VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_ops = &dummy_vm_ops;
down_write(¤t->mm->mmap_sem);
if (insert_vm_struct(current->mm, vma)) {
up_write(¤t->mm->mmap_sem);
diff -puN drivers/char/mem.c~mm-fix-vma_is_anonymous-false-positives drivers/char/mem.c
--- a/drivers/char/mem.c~mm-fix-vma_is_anonymous-false-positives
+++ a/drivers/char/mem.c
@@ -708,6 +708,7 @@ static int mmap_zero(struct file *file,
#endif
if (vma->vm_flags & VM_SHARED)
return shmem_zero_setup(vma);
+ vma->vm_ops = &anon_vm_ops;
return 0;
}
diff -puN fs/exec.c~mm-fix-vma_is_anonymous-false-positives fs/exec.c
--- a/fs/exec.c~mm-fix-vma_is_anonymous-false-positives
+++ a/fs/exec.c
@@ -307,6 +307,7 @@ static int __bprm_mm_init(struct linux_b
* configured yet.
*/
BUILD_BUG_ON(VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP);
+ vma->vm_ops = &anon_vm_ops;
vma->vm_end = STACK_TOP_MAX;
vma->vm_start = vma->vm_end - PAGE_SIZE;
vma->vm_flags = VM_SOFTDIRTY | VM_STACK_FLAGS | VM_STACK_INCOMPLETE_SETUP;
diff -puN fs/hugetlbfs/inode.c~mm-fix-vma_is_anonymous-false-positives fs/hugetlbfs/inode.c
--- a/fs/hugetlbfs/inode.c~mm-fix-vma_is_anonymous-false-positives
+++ a/fs/hugetlbfs/inode.c
@@ -597,6 +597,7 @@ static long hugetlbfs_fallocate(struct f
memset(&pseudo_vma, 0, sizeof(struct vm_area_struct));
pseudo_vma.vm_flags = (VM_HUGETLB | VM_MAYSHARE | VM_SHARED);
pseudo_vma.vm_file = file;
+ pseudo_vma.vm_ops = &dummy_vm_ops;
for (index = start; index < end; index++) {
/*
diff -puN include/linux/mm.h~mm-fix-vma_is_anonymous-false-positives include/linux/mm.h
--- a/include/linux/mm.h~mm-fix-vma_is_anonymous-false-positives
+++ a/include/linux/mm.h
@@ -1536,9 +1536,12 @@ int clear_page_dirty_for_io(struct page
int get_cmdline(struct task_struct *task, char *buffer, int buflen);
+extern const struct vm_operations_struct anon_vm_ops;
+extern const struct vm_operations_struct dummy_vm_ops;
+
static inline bool vma_is_anonymous(struct vm_area_struct *vma)
{
- return !vma->vm_ops;
+ return vma->vm_ops == &anon_vm_ops;
}
#ifdef CONFIG_SHMEM
diff -puN mm/khugepaged.c~mm-fix-vma_is_anonymous-false-positives mm/khugepaged.c
--- a/mm/khugepaged.c~mm-fix-vma_is_anonymous-false-positives
+++ a/mm/khugepaged.c
@@ -440,7 +440,7 @@ int khugepaged_enter_vma_merge(struct vm
* page fault if needed.
*/
return 0;
- if (vma->vm_ops || (vm_flags & VM_NO_KHUGEPAGED))
+ if (!vma_is_anonymous(vma) || (vm_flags & VM_NO_KHUGEPAGED))
/* khugepaged not yet working on file or special mappings */
return 0;
hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK;
@@ -831,7 +831,7 @@ static bool hugepage_vma_check(struct vm
return IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) - vma->vm_pgoff,
HPAGE_PMD_NR);
}
- if (!vma->anon_vma || vma->vm_ops)
+ if (!vma->anon_vma || !vma_is_anonymous(vma))
return false;
if (is_vma_temporary_stack(vma))
return false;
diff -puN mm/mmap.c~mm-fix-vma_is_anonymous-false-positives mm/mmap.c
--- a/mm/mmap.c~mm-fix-vma_is_anonymous-false-positives
+++ a/mm/mmap.c
@@ -561,6 +561,8 @@ static unsigned long count_vma_pages_ran
void __vma_link_rb(struct mm_struct *mm, struct vm_area_struct *vma,
struct rb_node **rb_link, struct rb_node *rb_parent)
{
+ WARN_ONCE(!vma->vm_ops, "missing vma->vm_ops");
+
/* Update tracking information for the gap following the new vma. */
if (vma->vm_next)
vma_gap_update(vma->vm_next);
@@ -1762,6 +1764,11 @@ unsigned long mmap_region(struct file *f
*/
vma->vm_file = get_file(file);
error = call_mmap(file, vma);
+
+ /* All mappings must have ->vm_ops set */
+ if (!vma->vm_ops)
+ vma->vm_ops = &dummy_vm_ops;
+
if (error)
goto unmap_and_free_vma;
@@ -1780,6 +1787,9 @@ unsigned long mmap_region(struct file *f
error = shmem_zero_setup(vma);
if (error)
goto free_vma;
+ } else {
+ /* vma_is_anonymous() relies on this. */
+ vma->vm_ops = &anon_vm_ops;
}
vma_link(mm, vma, prev, rb_link, rb_parent);
@@ -2992,6 +3002,7 @@ static int do_brk_flags(unsigned long ad
INIT_LIST_HEAD(&vma->anon_vma_chain);
vma->vm_mm = mm;
+ vma->vm_ops = &anon_vm_ops;
vma->vm_start = addr;
vma->vm_end = addr + len;
vma->vm_pgoff = pgoff;
diff -puN mm/nommu.c~mm-fix-vma_is_anonymous-false-positives mm/nommu.c
--- a/mm/nommu.c~mm-fix-vma_is_anonymous-false-positives
+++ a/mm/nommu.c
@@ -1058,6 +1058,8 @@ static int do_mmap_shared_file(struct vm
int ret;
ret = call_mmap(vma->vm_file, vma);
+ if (!vma->vm_ops)
+ vma->vm_ops = &dummy_vm_ops;
if (ret == 0) {
vma->vm_region->vm_top = vma->vm_region->vm_end;
return 0;
@@ -1089,6 +1091,8 @@ static int do_mmap_private(struct vm_are
*/
if (capabilities & NOMMU_MAP_DIRECT) {
ret = call_mmap(vma->vm_file, vma);
+ if (!vma->vm_ops)
+ vma->vm_ops = &dummy_vm_ops;
if (ret == 0) {
/* shouldn't return success if we're not sharing */
BUG_ON(!(vma->vm_flags & VM_MAYSHARE));
@@ -1137,6 +1141,8 @@ static int do_mmap_private(struct vm_are
fpos = vma->vm_pgoff;
fpos <<= PAGE_SHIFT;
+ vma->vm_ops = &dummy_vm_ops;
+
ret = kernel_read(vma->vm_file, base, len, &fpos);
if (ret < 0)
goto error_free;
@@ -1144,7 +1150,8 @@ static int do_mmap_private(struct vm_are
/* clear the last little bit */
if (ret < len)
memset(base + ret, 0, len - ret);
-
+ } else {
+ vma->vm_ops = &anon_vm_ops;
}
return 0;
diff -puN mm/shmem.c~mm-fix-vma_is_anonymous-false-positives mm/shmem.c
--- a/mm/shmem.c~mm-fix-vma_is_anonymous-false-positives
+++ a/mm/shmem.c
@@ -1424,6 +1424,7 @@ static void shmem_pseudo_vma_init(struct
/* Bias interleave by inode number to distribute better across nodes */
vma->vm_pgoff = index + info->vfs_inode.i_ino;
vma->vm_policy = mpol_shared_policy_lookup(&info->policy, index);
+ vma->vm_ops = &dummy_vm_ops;
}
static void shmem_pseudo_vma_destroy(struct vm_area_struct *vma)
diff -puN mm/util.c~mm-fix-vma_is_anonymous-false-positives mm/util.c
--- a/mm/util.c~mm-fix-vma_is_anonymous-false-positives
+++ a/mm/util.c
@@ -20,6 +20,18 @@
#include "internal.h"
+/*
+ * All anonymous VMAs have ->vm_ops set to anon_vm_ops.
+ * vma_is_anonymous() reiles on anon_vm_ops to detect anonymous VMA.
+ */
+const struct vm_operations_struct anon_vm_ops = {};
+
+/*
+ * All VMAs have to have ->vm_ops set. dummy_vm_ops can be used if the VMA
+ * doesn't need to handle any of the operations.
+ */
+const struct vm_operations_struct dummy_vm_ops = {};
+
static inline int is_kernel_rodata(unsigned long addr)
{
return addr >= (unsigned long)__start_rodata &&
_
Patches currently in -mm which might be from kirill.shutemov@linux.intel.com are
mm-page_ext-drop-definition-of-unused-page_ext_debug_poison.patch
mm-page_ext-constify-lookup_page_ext-argument.patch
mm-drop-unneeded-vm_ops-checks-v2.patch
^ permalink raw reply
* Re: [PATCH v1 09/10] Input: atmel_mxt_ts - tool type is ignored when slot is closed
From: Dmitry Torokhov @ 2018-07-23 22:33 UTC (permalink / raw)
To: Nick Dyer, Benjamin Tissoires
Cc: linux-kernel, linux-input, Chris Healy, Nikita Yushchenko,
Lucas Stach, Nick Dyer
In-Reply-To: <20180720215122.23558-9-nick@shmanahar.org>
On Fri, Jul 20, 2018 at 10:51:21PM +0100, Nick Dyer wrote:
> From: Nick Dyer <nick.dyer@itdev.co.uk>
>
> input_mt_report_slot_state() ignores the tool when the slot is closed.
> Remove the tool type from these function calls, which has caused a bit of
> confusion.
Hmm, maybe we could introduce MT_TOOL_NONE or MT_TOOL_INACTIVE and get
rid of the 3rd parameter? It will require a bit of macro trickery for a
release or 2...
>
> Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index d7023d261458..c31af790ef84 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -838,8 +838,7 @@ static void mxt_proc_t9_message(struct mxt_data *data, u8 *message)
> * have happened.
> */
> if (status & MXT_T9_RELEASE) {
> - input_mt_report_slot_state(input_dev,
> - MT_TOOL_FINGER, 0);
> + input_mt_report_slot_state(input_dev, 0, 0);
> mxt_input_sync(data);
> }
>
> @@ -855,7 +854,7 @@ static void mxt_proc_t9_message(struct mxt_data *data, u8 *message)
> input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, area);
> } else {
> /* Touch no longer active, close out slot */
> - input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, 0);
> + input_mt_report_slot_state(input_dev, 0, 0);
> }
>
> data->update_input = true;
> --
> 2.17.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v10 1/7] dt-bindings: net: bluetooth: Add device tree bindings for QTI chip wcn3990
From: Matthias Kaehlcke @ 2018-07-23 22:32 UTC (permalink / raw)
To: Balakrishna Godavarthi
Cc: marcel, johan.hedberg, linux-kernel, devicetree, linux-bluetooth,
thierry.escande, rtatiya, hemantg, linux-arm-msm
In-Reply-To: <20180720133243.6851-2-bgodavar@codeaurora.org>
On Fri, Jul 20, 2018 at 07:02:37PM +0530, Balakrishna Godavarthi wrote:
> This patch enables regulators for the Qualcomm Bluetooth wcn3990
> controller.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> Changes in v10:
> * added entry for regulator currents
>
> Changes in v9:
> * updated with latest reg handle and names.
> * updated max-speed definition.
>
> Changes in v8:
> * Separated the optional entries between two chips
>
> Changes in v7:
> * no change.
>
> Changes in v6:
>
> * Changed the oper-speed to max-speed.
>
> Changes in v5:
>
> * Added entry for oper-speed and init-speed.
>
> ---
> .../bindings/net/qualcomm-bluetooth.txt | 42 ++++++++++++++++++-
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> index 0ea18a53cc29..ca04c4981048 100644
> --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> @@ -10,12 +10,34 @@ device the slave device is attached to.
> Required properties:
> - compatible: should contain one of the following:
> * "qcom,qca6174-bt"
> + * "qcom,wcn3990-bt"
> +
> +Optional properties for compatible string qcom,qca6174-bt:
>
> -Optional properties:
> - enable-gpios: gpio specifier used to enable chip
> - clocks: clock provided to the controller (SUSCLK_32KHZ)
>
> -Example:
> +Optional properties for compatible string qcom,wcn3990-bt:
> +
> + - vddio-supply: Bluetooth wcn3990 VDD_IO supply regulator handle.
> + - vddxo-supply: Bluetooth wcn3990 VDD_XO supply regulator handle.
> + - vddrf-supply: Bluetooth wcn3990 VDD_RF supply regulator handle.
> + - vddch0-supply: Bluetooth wcn3990 VDD_CH0 supply regulator handle.
> +
> + - If WCN3990 is connected to platform where RPMH PMIC processor is used
> + then the load values will be 1uA. if it is connected to platform where RPM
> + PMIC processor is used then load value will be 10000 uA.
> + if it is connected to different platform, where current values are fixed
> + as in data sheet then below property are not required.
Please provide details why these magic values are needed for RPMh and
RPM PMICs.
For RPMh it looks like a value of 1uA would cause the regulator to
enter idle mode:
static int rpmh_regulator_vrm_set_load(struct regulator_dev *rdev, int load_uA)
{
struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
unsigned int mode;
if (load_uA >= vreg->hw_data->hpm_min_load_uA)
mode = REGULATOR_MODE_NORMAL;
else
mode = REGULATOR_MODE_IDLE;
return rpmh_regulator_vrm_set_mode(rdev, mode);
}
https://patchwork.kernel.org/patch/10524299/
Is that really intended and if so why? It might make sense to save
power when really in idle mode, but I assume you somehow have to tell
the regulator to switch to normal mode when BT is used.
I also commented about this on patch "[7/7] Bluetooth: hci_qca: Add
support for Qualcomm Bluetooth chip wcn3990". I suggest to center the
discussion here and reply with a link to the other patch.
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.IGT: failure for series starting with [i-g-t,1/4] lib: Don't assert all KMS drivers support edid_override
From: Patchwork @ 2018-07-23 22:31 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20180723200736.29508-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [i-g-t,1/4] lib: Don't assert all KMS drivers support edid_override
URL : https://patchwork.freedesktop.org/series/47084/
State : failure
== Summary ==
= CI Bug Log - changes from IGT_4570_full -> IGTPW_1633_full =
== Summary - FAILURE ==
Serious unknown changes coming with IGTPW_1633_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_1633_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47084/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in IGTPW_1633_full:
=== IGT changes ===
==== Possible regressions ====
igt@gem_eio@in-flight-contexts-10ms:
shard-snb: PASS -> FAIL
==== Warnings ====
igt@gem_exec_schedule@deep-blt:
shard-apl: SKIP -> PASS +3
igt@gem_exec_schedule@deep-bsd:
shard-glk: SKIP -> PASS +3
igt@gem_mocs_settings@mocs-rc6-blt:
shard-kbl: PASS -> SKIP +1
igt@gem_mocs_settings@mocs-rc6-bsd1:
shard-kbl: SKIP -> PASS
igt@kms_atomic_interruptible@legacy-pageflip:
shard-snb: SKIP -> PASS +1
== Known issues ==
Here are the changes found in IGTPW_1633_full that come from known issues:
=== IGT changes ===
==== Issues hit ====
{igt@gem_exec_capture@many-random}:
shard-hsw: NOTRUN -> INCOMPLETE (fdo#103540)
shard-snb: NOTRUN -> INCOMPLETE (fdo#105411)
{igt@gem_exec_capture@many-zero}:
shard-apl: NOTRUN -> INCOMPLETE (fdo#103927) +1
shard-kbl: NOTRUN -> INCOMPLETE (fdo#103665) +1
shard-glk: NOTRUN -> INCOMPLETE (fdo#103359, k.org#198133) +1
igt@gem_exec_schedule@pi-ringfull-vebox:
shard-glk: NOTRUN -> FAIL (fdo#103158)
igt@gem_softpin@noreloc-s3:
shard-glk: PASS -> FAIL (fdo#103375)
igt@kms_busy@extended-modeset-hang-newfb-render-d:
shard-snb: SKIP -> INCOMPLETE (fdo#105411)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
shard-kbl: PASS -> INCOMPLETE (fdo#103665) +1
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
==== Possible fixes ====
igt@gem_mmap_gtt@coherency:
shard-glk: FAIL (fdo#100587) -> SKIP +1
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
shard-glk: FAIL (fdo#103167) -> PASS
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-snb: FAIL (fdo#103166) -> PASS
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> PASS
igt@perf_pmu@multi-client-vcs1:
shard-snb: INCOMPLETE (fdo#105411) -> SKIP
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> SKIP +1
igt@testdisplay:
shard-glk: INCOMPLETE (fdo#103359, fdo#107093, k.org#198133) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
fdo#107093 https://bugs.freedesktop.org/show_bug.cgi?id=107093
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1633
* Linux: CI_DRM_4519 -> CI_DRM_4521
CI_DRM_4519: f14c0ec8fe9acce6fd1be84766f854ab8874eb33 @ git://anongit.freedesktop.org/gfx-ci/linux
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1633: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1633/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1633/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [pull request][net 0/8] Mellanox, mlx5 fixes 2018-07-18
From: Saeed Mahameed @ 2018-07-23 21:27 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180721.102050.722565861824892185.davem@davemloft.net>
On Sat, 2018-07-21 at 10:20 -0700, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Wed, 18 Jul 2018 18:26:04 -0700
>
> > The following series provides fixes to mlx5 core and net device
> > driver.
> >
> > Please pull and let me know if there's any problem.
>
> Pulled, thanks Saeed.
>
> Based upon the thread with Or, it would be useful to do some auditing
> and make sure all tunnels set skb->encapsulation.
>
Thanks Dave, Eran's patch relies on our driver setting skb-
>encapsulation, since the rps rule is injected directly from the device
rx path once netif_receive_skb_internal is called via the gro stack way
before forwarding the skb to the tunnel netdev.
> > For -stable v4.7
> > net/mlx5e: Don't allow aRFS for encapsulated packets
> > net/mlx5e: Fix quota counting in aRFS expire flow
> >
> > For -stable v4.15
> > net/mlx5e: Only allow offloading decap egress (egdev) flows
> > net/mlx5e: Refine ets validation function
> > net/mlx5: Adjust clock overflow work period
> >
> > For -stable v4.17
> > net/mlx5: E-Switch, UBSAN fix undefined behavior in
> > mlx5_eswitch_mode
>
> Queued up.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH v6] drm/i915/dp: Limit link training clock recovery loop
From: Marc Herbert @ 2018-07-23 22:30 UTC (permalink / raw)
To: intel-gfx; +Cc: Dhinakaran Pandiyan, Rodrigo Vivi
In-Reply-To: <1532117759-20119-1-git-send-email-nathan.d.ciobanu@linux.intel.com>
Compliance aside I had a really hard time understanding the gap between 80
and 10. I mean if up to 80 tries might be needed pre-1.4, then how come 1.4
is supposed to succeed in less than 10? Confusing.
After asking Nathan and DK (thx) I suggest rephrasing the comment below with
something like this:
/* For devices pre-DP 1.4 we set the retry limit to an extremely lenient 80
max iterations = 4 (voltage levels) x 4 (preemphasis levels) x 5 (same
voltage retries). It should never take that many attempts (TODO: why not?)
but we let's be lax and tolerate all kinds of sinks because the specs
don't specify any limit (and allow infinite loops).
On the other hand, 1.4 devices should be smart and/or compliant enough and
the expectations are now higher; they're must succeed in less than 10 tries
because they know how <TODO>
*/
My 2 cents - you get the idea.
BTW I'm curious how long 80 tries typically take.
On 20/07/2018 13:15, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> x 5 identical voltages tries). Some faulty USB-C MST hubs can
> cause us to get stuck in this loop indefinitely requesting something
> like:
I heard that loop was not just the hub's fault after all.
Of course no hub should be able to trigger an infinite loop anyway,
not even a hypothetical hub.
> voltage swing: 0, pre-emphasis level: 2
> voltage swing: 1, pre-emphasis level: 2
> voltage swing: 0, pre-emphasis level: 3
>
> over and over so max_vswing would never be reached,
> drm_dp_clock_recovery_ok() would never return true and voltage_tries
> would always get reset to 1. The driver sends those values to the hub
> but the hub keeps requesting new values every time.
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
>
> @@ -170,9 +170,20 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> return false;
> }
>
> + /*
> + * DP 1.4 spec clock recovery retries defined but
> + * for devices pre-DP 1.4 we set the retry limit
> + * to 4 (voltage levels) x 4 (preemphasis levels) x
> + * x 5 (same voltage retries) = 80 (max iterations)
> + */
> + if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> + max_cr_tries = 10;
> + else
> + max_cr_tries = 80;
> +
> voltage_tries = 1;
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v2 09/10] coresight: perf: Remove set_buffer call back
From: Suzuki K Poulose @ 2018-07-23 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyN_+uTJZh7YEBPtMPvb8uQNwXvCwn_N4+D12xOVc=MNg@mail.gmail.com>
Mathieu,
On 07/23/2018 07:22 PM, Mathieu Poirier wrote:
> On Fri, 20 Jul 2018 at 03:04, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>>
>> Mathieu,
>>
>> On 19/07/18 21:36, Mathieu Poirier wrote:
>>> On Tue, Jul 17, 2018 at 06:11:40PM +0100, Suzuki K Poulose wrote:
>>>> In coresight perf mode, we need to prepare the sink before
>>>> starting a session, which is done via set_buffer call back.
>>>> We then proceed to enable the tracing. If we fail to start
>>>> the session successfully, we leave the sink configuration
>>>> unchanged. This was fine for the existing backends as they
>>>> don't have any state associated with the buffers. But with
>>>> ETR, we need to keep track of the buffer details and need
>>>> to be cleaned up if we fail. In order to make the operation
>>>> atomic and to avoid yet another call back, we get rid of
>>>> the "set_buffer" call back and pass the buffer details
>>>> via enable() call back to the sink.
>>>
>>> Suzuki,
>>>
>>> I'm not sure I understand the problem you're trying to fix there. From the
>>> implementation of tmc_enable_etr_sink_perf() in the next patch, wouldn't the
>>> same result been achievable using a callback?
>>
>> We can definitely achieve the results using "set_buffer". But for ETR,
>> we track the "perf_buf" in drvdata->perf_data when we do "set_buffer".
>> But if we failed to enable_path(), we leave the drvdata->perf_data
>> and doesn't clean it up. Now when another session is about to set_buf,
>> we check if perf_data is empty and WARNs otherwise.
>> Because we can't be sure if it belongs to an abandoned session or
>> another active session and we completely messed somewhere in the driver.
>> So, we need a clear_buffer call back if the enable fails, something
>> not really worth. Anyways, there is no point in separating set_buffer
>> and enabling the sink, as the error handling becomes cumbersome as explained
>> above.
>>
>>>
>>> I'm fine with this patch and supportive of getting rid of callbacks if we can, I
>>> just need to understand the exact problem you're after. From looking a your
>>> code (and the current implementation), if we succeed in setting the memory for
>>> the sink but fail in any of the subsequent steps i.e, enabling the rest of the
>>> compoment on the path or the source, the sink is left unchanged.
>>
>> Yes, thats right. And we should WARN (which I missed in this version) if
>> there is a perf_data already for a disabled ETR. Please see my response to the
>> next patch.
>
> The changelog for this patch states the following: "But with ETR, we
> need to keep track of the buffer details and need to be cleaned up if
> we fail."
>
> I did a deep dive in the code and in the current implementation if the
> source fails to be enabled in etm_event_start() the path and the sink
> remains unchanged. With your patchset this get fixed because a goto
> was added to disable the path when such condition occur. As such each
> component in the path will see its ->disable() callback invoked. In
> tmc_disable_etr_sink(), drvdata->perf_data is set to NULL in
> tmc_etr_disable_hw(), so the cleanup on error condition is done
> properly. As such we wouldn't need a clean_buffer() callback.
All of this is right. But we still have a case. e.g, if the ETR is
enabled in sysfs mode, coresight_enable_path() will fail after we
have set the buffer. And since we don't try to disable the path
when we fail at SINK (which is the right thing to do, as we could
be potentially disabling the ETR operated in sysfs mode), we leave
the perf_data around. And the next session finds a non-empty data.
>
> As I said I'm in favour of removing the set_buffer() callback but I
> wouldn't associated it with ETR state cleanup. If the code can be
> rearranged in a way that code can be removed then that alone is enough
> to justify the change.
>
>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
>>>> index 3cc4a0b..12a247d 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>>>> @@ -269,16 +269,11 @@ static void etm_event_start(struct perf_event *event, int flags)
>>>> path = etm_event_cpu_path(event_data, cpu);
>>>> /* We need a sink, no need to continue without one */
>>>> sink = coresight_get_sink(path);
>>>> - if (WARN_ON_ONCE(!sink || !sink_ops(sink)->set_buffer))
>>>> - goto fail_end_stop;
>>>> -
>>>> - /* Configure the sink */
>>>> - if (sink_ops(sink)->set_buffer(sink, handle,
>>>> - event_data->snk_config))
>>>> + if (WARN_ON_ONCE(!sink))
>>>> goto fail_end_stop;
>>>>
>>>> /* Nothing will happen without a path */
>>>> - if (coresight_enable_path(path, CS_MODE_PERF))
>>>> + if (coresight_enable_path(path, CS_MODE_PERF, handle))
>>>
>>> Here we already have a handle on "event_data". As such I think this is what we
>>> should feed to coresight_enable_path() rather than the handle. That way we
>>> don't need to call etm_perf_sink_config(), we just use the data.
>>
>> The advantage of passing on the handle is, we could get all the way upto the
>> "perf_event" for the given session. Passing the event_data will loose that
>> information.
>>
>> i.e, perf_event-> |perf_ouput_handle | -> |event_data | -> sink_config
>> | <-event | | |
>>
>> The purpose of the wrapper "etm_perf_sink_config()" is to abstract the way we
>> handle the information under the event_data. i.e, if we decide to make some
>> changes in the way we store event_data, we need to spill the changes every
>> where. But the perf_ouput_handle has much more stable ABI than event_data,
>> hence the choice of passing handle.
>
> I agree that etm_perf_sink_config() has value but it should take a
> void * as parameter (i.e what gets returned from perf_get_aux())
> rather than a perf_output_handle *.
Ok, did you mean :
sink_config = etm_perf_sink_config(perf_get_aux(handle)); ?
Or do you want to change the parameter passed to the enable_sink() as
well ?
Suzuki
^ permalink raw reply
* Re: [PATCH V4 2/7] mmc: sdhci: Change SDMA address register for v4 mode
From: kbuild test robot @ 2018-07-23 22:28 UTC (permalink / raw)
To: Chunyan Zhang
Cc: kbuild-all, Ulf Hansson, Adrian Hunter, linux-mmc, linux-kernel,
Orson Zhai, Baolin Wang, Billows Wu, Jason Wu, zhang.lyra
In-Reply-To: <1532340508-8749-3-git-send-email-zhang.chunyan@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 7231 bytes --]
Hi Chunyan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on ulf.hansson-mmc/next]
[also build test WARNING on v4.18-rc6 next-20180723]
[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/Chunyan-Zhang/mmc-add-support-for-sdhci-4-0/20180724-045328
base: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from drivers/mmc//host/sdhci.c:16:
drivers/mmc//host/sdhci.c: In function 'sdhci_data_irq':
>> include/linux/kern_levels.h:5:18: warning: format '%p' expects argument of type 'void *', but argument 3 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
drivers/mmc//host/sdhci.c:43:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^~~~~~~~
drivers/mmc//host/sdhci.c:2849:4: note: in expansion of macro 'DBG'
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
^~~
drivers/mmc//host/sdhci.c:2849:19: note: format string is defined here
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
~^
%d
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from drivers/mmc//host/sdhci.c:16:
include/linux/kern_levels.h:5:18: warning: format '%p' expects argument of type 'void *', but argument 5 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
drivers/mmc//host/sdhci.c:43:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^~~~~~~~
drivers/mmc//host/sdhci.c:2849:4: note: in expansion of macro 'DBG'
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
^~~
drivers/mmc//host/sdhci.c:2849:56: note: format string is defined here
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
~^
%d
--
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from drivers/mmc/host/sdhci.c:16:
drivers/mmc/host/sdhci.c: In function 'sdhci_data_irq':
>> include/linux/kern_levels.h:5:18: warning: format '%p' expects argument of type 'void *', but argument 3 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
drivers/mmc/host/sdhci.c:43:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^~~~~~~~
drivers/mmc/host/sdhci.c:2849:4: note: in expansion of macro 'DBG'
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
^~~
drivers/mmc/host/sdhci.c:2849:19: note: format string is defined here
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
~^
%d
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from drivers/mmc/host/sdhci.c:16:
include/linux/kern_levels.h:5:18: warning: format '%p' expects argument of type 'void *', but argument 5 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
drivers/mmc/host/sdhci.c:43:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^~~~~~~~
drivers/mmc/host/sdhci.c:2849:4: note: in expansion of macro 'DBG'
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
^~~
drivers/mmc/host/sdhci.c:2849:56: note: format string is defined here
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
~^
%d
vim +5 include/linux/kern_levels.h
314ba352 Joe Perches 2012-07-30 4
04d2c8c8 Joe Perches 2012-07-30 @5 #define KERN_SOH "\001" /* ASCII Start Of Header */
04d2c8c8 Joe Perches 2012-07-30 6 #define KERN_SOH_ASCII '\001'
04d2c8c8 Joe Perches 2012-07-30 7
:::::: The code at line 5 was first introduced by commit
:::::: 04d2c8c83d0e3ac5f78aeede51babb3236200112 printk: convert the format for KERN_<LEVEL> to a 2 byte pattern
:::::: TO: Joe Perches <joe@perches.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 43902 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/10] coresight: perf: Remove set_buffer call back
From: Suzuki K Poulose @ 2018-07-23 22:28 UTC (permalink / raw)
To: Mathieu Poirier
Cc: linux-arm-kernel, Linux Kernel Mailing List, Robert Walker,
Mike Leach, coresight
In-Reply-To: <CANLsYkyN_+uTJZh7YEBPtMPvb8uQNwXvCwn_N4+D12xOVc=MNg@mail.gmail.com>
Mathieu,
On 07/23/2018 07:22 PM, Mathieu Poirier wrote:
> On Fri, 20 Jul 2018 at 03:04, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>>
>> Mathieu,
>>
>> On 19/07/18 21:36, Mathieu Poirier wrote:
>>> On Tue, Jul 17, 2018 at 06:11:40PM +0100, Suzuki K Poulose wrote:
>>>> In coresight perf mode, we need to prepare the sink before
>>>> starting a session, which is done via set_buffer call back.
>>>> We then proceed to enable the tracing. If we fail to start
>>>> the session successfully, we leave the sink configuration
>>>> unchanged. This was fine for the existing backends as they
>>>> don't have any state associated with the buffers. But with
>>>> ETR, we need to keep track of the buffer details and need
>>>> to be cleaned up if we fail. In order to make the operation
>>>> atomic and to avoid yet another call back, we get rid of
>>>> the "set_buffer" call back and pass the buffer details
>>>> via enable() call back to the sink.
>>>
>>> Suzuki,
>>>
>>> I'm not sure I understand the problem you're trying to fix there. From the
>>> implementation of tmc_enable_etr_sink_perf() in the next patch, wouldn't the
>>> same result been achievable using a callback?
>>
>> We can definitely achieve the results using "set_buffer". But for ETR,
>> we track the "perf_buf" in drvdata->perf_data when we do "set_buffer".
>> But if we failed to enable_path(), we leave the drvdata->perf_data
>> and doesn't clean it up. Now when another session is about to set_buf,
>> we check if perf_data is empty and WARNs otherwise.
>> Because we can't be sure if it belongs to an abandoned session or
>> another active session and we completely messed somewhere in the driver.
>> So, we need a clear_buffer call back if the enable fails, something
>> not really worth. Anyways, there is no point in separating set_buffer
>> and enabling the sink, as the error handling becomes cumbersome as explained
>> above.
>>
>>>
>>> I'm fine with this patch and supportive of getting rid of callbacks if we can, I
>>> just need to understand the exact problem you're after. From looking a your
>>> code (and the current implementation), if we succeed in setting the memory for
>>> the sink but fail in any of the subsequent steps i.e, enabling the rest of the
>>> compoment on the path or the source, the sink is left unchanged.
>>
>> Yes, thats right. And we should WARN (which I missed in this version) if
>> there is a perf_data already for a disabled ETR. Please see my response to the
>> next patch.
>
> The changelog for this patch states the following: "But with ETR, we
> need to keep track of the buffer details and need to be cleaned up if
> we fail."
>
> I did a deep dive in the code and in the current implementation if the
> source fails to be enabled in etm_event_start() the path and the sink
> remains unchanged. With your patchset this get fixed because a goto
> was added to disable the path when such condition occur. As such each
> component in the path will see its ->disable() callback invoked. In
> tmc_disable_etr_sink(), drvdata->perf_data is set to NULL in
> tmc_etr_disable_hw(), so the cleanup on error condition is done
> properly. As such we wouldn't need a clean_buffer() callback.
All of this is right. But we still have a case. e.g, if the ETR is
enabled in sysfs mode, coresight_enable_path() will fail after we
have set the buffer. And since we don't try to disable the path
when we fail at SINK (which is the right thing to do, as we could
be potentially disabling the ETR operated in sysfs mode), we leave
the perf_data around. And the next session finds a non-empty data.
>
> As I said I'm in favour of removing the set_buffer() callback but I
> wouldn't associated it with ETR state cleanup. If the code can be
> rearranged in a way that code can be removed then that alone is enough
> to justify the change.
>
>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
>>>> index 3cc4a0b..12a247d 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>>>> @@ -269,16 +269,11 @@ static void etm_event_start(struct perf_event *event, int flags)
>>>> path = etm_event_cpu_path(event_data, cpu);
>>>> /* We need a sink, no need to continue without one */
>>>> sink = coresight_get_sink(path);
>>>> - if (WARN_ON_ONCE(!sink || !sink_ops(sink)->set_buffer))
>>>> - goto fail_end_stop;
>>>> -
>>>> - /* Configure the sink */
>>>> - if (sink_ops(sink)->set_buffer(sink, handle,
>>>> - event_data->snk_config))
>>>> + if (WARN_ON_ONCE(!sink))
>>>> goto fail_end_stop;
>>>>
>>>> /* Nothing will happen without a path */
>>>> - if (coresight_enable_path(path, CS_MODE_PERF))
>>>> + if (coresight_enable_path(path, CS_MODE_PERF, handle))
>>>
>>> Here we already have a handle on "event_data". As such I think this is what we
>>> should feed to coresight_enable_path() rather than the handle. That way we
>>> don't need to call etm_perf_sink_config(), we just use the data.
>>
>> The advantage of passing on the handle is, we could get all the way upto the
>> "perf_event" for the given session. Passing the event_data will loose that
>> information.
>>
>> i.e, perf_event-> |perf_ouput_handle | -> |event_data | -> sink_config
>> | <-event | | |
>>
>> The purpose of the wrapper "etm_perf_sink_config()" is to abstract the way we
>> handle the information under the event_data. i.e, if we decide to make some
>> changes in the way we store event_data, we need to spill the changes every
>> where. But the perf_ouput_handle has much more stable ABI than event_data,
>> hence the choice of passing handle.
>
> I agree that etm_perf_sink_config() has value but it should take a
> void * as parameter (i.e what gets returned from perf_get_aux())
> rather than a perf_output_handle *.
Ok, did you mean :
sink_config = etm_perf_sink_config(perf_get_aux(handle)); ?
Or do you want to change the parameter passed to the enable_sink() as
well ?
Suzuki
^ permalink raw reply
* Re: [PATCH v4 14/21] diff: add an internal option to dual-color diffs of diffs
From: Junio C Hamano @ 2018-07-23 22:27 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
In-Reply-To: <9de5bd2299eedbc78494cadc9dd8bda59430b2df.1532210683.git.gitgitgadget@gmail.com>
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When diffing diffs, it can be quite daunting to figure out what the heck
> is going on, as there are nested +/- signs.
>
> Let's make this easier by adding a flag in diff_options that allows
> color-coding the outer diff sign with inverted colors, so that the
> preimage and postimage is colored like the diff it is.
>
> Of course, this really only makes sense when the preimage and postimage
> *are* diffs. So let's not expose this flag via a command-line option for
> now.
>
> This is a feature that was invented by git-tbdiff, and it will be used
> by `git range-diff` in the next commit, by offering it via a new option:
> `--dual-color`.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> diff.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++-----------
> diff.h | 1 +
> 2 files changed, 69 insertions(+), 15 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index a94a8214f..e163bc8a3 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -563,14 +563,18 @@ static void check_blank_at_eof(mmfile_t *mf1, mmfile_t *mf2,
> ecbdata->blank_at_eof_in_postimage = (at - l2) + 1;
> }
>
> -static void emit_line_0(struct diff_options *o, const char *set, const char *reset,
> +static void emit_line_0(struct diff_options *o,
> + const char *set, unsigned reverse, const char *reset,
> int first, const char *line, int len)
> {
> int has_trailing_newline, has_trailing_carriage_return;
> int nofirst;
> FILE *file = o->file;
>
> - fputs(diff_line_prefix(o), file);
> + if (first)
> + fputs(diff_line_prefix(o), file);
> + else if (!len)
> + return;
Can you explain this hunk in the log message? I am not sure how the
description in the log message relates to this change. Is the idea
of this change essentially "all the existing callers that aren't
doing the diff-of-diffs send a non-NUL first character, and for them
this change is a no-op. New callers share most of the remainder of
emit_line_0() logic but do not want to show the prefix, so the
support for it is piggy-backing by a special case where first could
be NUL"?
^ permalink raw reply
* Re: [PATCH V4 2/7] mmc: sdhci: Change SDMA address register for v4 mode
From: kbuild test robot @ 2018-07-23 22:26 UTC (permalink / raw)
To: Chunyan Zhang
Cc: kbuild-all, Ulf Hansson, Adrian Hunter, linux-mmc, linux-kernel,
Orson Zhai, Baolin Wang, Billows Wu, Jason Wu, zhang.lyra
In-Reply-To: <1532340508-8749-3-git-send-email-zhang.chunyan@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 6553 bytes --]
Hi Chunyan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on ulf.hansson-mmc/next]
[also build test WARNING on v4.18-rc6 next-20180723]
[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/Chunyan-Zhang/mmc-add-support-for-sdhci-4-0/20180724-045328
base: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
config: arm-exynos_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from drivers/mmc/host/sdhci.c:16:
drivers/mmc/host/sdhci.c: In function 'sdhci_data_irq':
>> drivers/mmc/host/sdhci.c:43:11: warning: format '%p' expects argument of type 'void *', but argument 4 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/mmc/host/sdhci.c:43:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^~~~~~~~
drivers/mmc/host/sdhci.c:2849:4: note: in expansion of macro 'DBG'
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
^~~
drivers/mmc/host/sdhci.c:2849:19: note: format string is defined here
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
~^
%d
In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from drivers/mmc/host/sdhci.c:16:
drivers/mmc/host/sdhci.c:43:11: warning: format '%p' expects argument of type 'void *', but argument 6 has type 'dma_addr_t {aka unsigned int}' [-Wformat=]
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/mmc/host/sdhci.c:43:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
^~~~~~~~
drivers/mmc/host/sdhci.c:2849:4: note: in expansion of macro 'DBG'
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
^~~
drivers/mmc/host/sdhci.c:2849:56: note: format string is defined here
DBG("DMA base %pad, transferred 0x%06x bytes, next %pad\n",
~^
%d
vim +43 drivers/mmc/host/sdhci.c
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 @16 #include <linux/delay.h>
5a436cc0a drivers/mmc/host/sdhci.c Adrian Hunter 2017-03-20 17 #include <linux/ktime.h>
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 18 #include <linux/highmem.h>
b8c86fc5d drivers/mmc/host/sdhci.c Pierre Ossman 2008-03-18 19 #include <linux/io.h>
88b476797 drivers/mmc/host/sdhci.c Paul Gortmaker 2011-07-03 20 #include <linux/module.h>
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 21 #include <linux/dma-mapping.h>
5a0e3ad6a drivers/mmc/host/sdhci.c Tejun Heo 2010-03-24 22 #include <linux/slab.h>
117636092 drivers/mmc/host/sdhci.c Ralf Baechle 2007-10-23 23 #include <linux/scatterlist.h>
bd9b90279 drivers/mmc/host/sdhci.c Linus Walleij 2018-01-29 24 #include <linux/sizes.h>
250dcd114 drivers/mmc/host/sdhci.c Ulf Hansson 2017-11-27 25 #include <linux/swiotlb.h>
9bea3c850 drivers/mmc/host/sdhci.c Marek Szyprowski 2010-08-10 26 #include <linux/regulator/consumer.h>
66fd8ad51 drivers/mmc/host/sdhci.c Adrian Hunter 2011-10-03 27 #include <linux/pm_runtime.h>
92e0c44b9 drivers/mmc/host/sdhci.c Zach Brown 2016-11-02 28 #include <linux/of.h>
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 29
2f730fec8 drivers/mmc/host/sdhci.c Pierre Ossman 2008-03-17 30 #include <linux/leds.h>
2f730fec8 drivers/mmc/host/sdhci.c Pierre Ossman 2008-03-17 31
22113efd0 drivers/mmc/host/sdhci.c Aries Lee 2010-12-15 32 #include <linux/mmc/mmc.h>
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 33 #include <linux/mmc/host.h>
473b095a7 drivers/mmc/host/sdhci.c Aaron Lu 2012-07-03 34 #include <linux/mmc/card.h>
85cc1c331 drivers/mmc/host/sdhci.c Corneliu Doban 2015-02-09 35 #include <linux/mmc/sdio.h>
bec9d4e59 drivers/mmc/host/sdhci.c Guennadi Liakhovetski 2012-09-17 36 #include <linux/mmc/slot-gpio.h>
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 37
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 38 #include "sdhci.h"
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 39
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 40 #define DRIVER_NAME "sdhci"
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 41
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 42 #define DBG(f, x...) \
f421865d5 drivers/mmc/host/sdhci.c Adrian Hunter 2017-03-20 @43 pr_debug("%s: " DRIVER_NAME ": " f, mmc_hostname(host->mmc), ## x)
d129bceb1 drivers/mmc/sdhci.c Pierre Ossman 2006-03-24 44
:::::: The code at line 43 was first introduced by commit
:::::: f421865d5b4ce57013040fb1700edceb43a14b42 mmc: sdhci: Improve debug print format
:::::: TO: Adrian Hunter <adrian.hunter@intel.com>
:::::: CC: Ulf Hansson <ulf.hansson@linaro.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28339 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue
From: De Lara Guarch, Pablo @ 2018-07-23 22:25 UTC (permalink / raw)
To: Shally Verma
Cc: dev@dpdk.org, pathreya@caviumnetworks.com,
mchalla@caviumnetworks.com, Sunila Sahu, Sunila Sahu,
Ashish Gupta
In-Reply-To: <1532357474-9544-5-git-send-email-shally.verma@caviumnetworks.com>
> -----Original Message-----
> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> Sent: Monday, July 23, 2018 3:51 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> mchalla@caviumnetworks.com; Sunila Sahu <ssahu@caviumnetworks.com>;
> Sunila Sahu <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>
> Subject: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue
>
> From: Sunila Sahu <ssahu@caviumnetworks.com>
>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> ---
> drivers/compress/zlib/zlib_pmd.c | 255
> ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 254 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/compress/zlib/zlib_pmd.c b/drivers/compress/zlib/zlib_pmd.c
> index 47bc73d..dc1e230 100644
> --- a/drivers/compress/zlib/zlib_pmd.c
> +++ b/drivers/compress/zlib/zlib_pmd.c
> @@ -7,7 +7,214 @@
>
> #include "zlib_pmd_private.h"
>
> -/** Parse comp xform and set private xform/stream parameters */
> +/** Compute next mbuf in the list, assign data buffer and length,
> + * returns 0 if mbuf is NULL
> + */
> +#define COMPUTE_BUF(mbuf, data, len) \
> + ((mbuf = mbuf->next) ? \
> + (data = rte_pktmbuf_mtod(mbuf, uint8_t *)), \
> + (len = rte_pktmbuf_data_len(mbuf)) : 0)
> +
> +static void
> +process_zlib_deflate(struct rte_comp_op *op, z_stream *strm) {
...
> + /* Update z_stream with the inputs provided by application */
> + strm->next_in = rte_pktmbuf_mtod_offset(mbuf_src, uint8_t *,
> + op->src.offset);
This is assuming that src buffer is a linear buffer or that offset won't be large enough to cross boundaries between segments.
If an SGL is passed and offset is bigger than the first segment, next_in should point at a different segment, with the remaining part of the offset in that segment
(look at ISA-L SGL patch: http://patches.dpdk.org/patch/43283/). Same applies to avail_in, next_out and avail_out.
> +
> + strm->avail_in = rte_pktmbuf_data_len(mbuf_src) - op->src.offset;
> +
> + strm->next_out = rte_pktmbuf_mtod_offset(mbuf_dst, uint8_t *,
> + op->dst.offset);
> +
> + strm->avail_out = rte_pktmbuf_data_len(mbuf_dst) - op->dst.offset;
> +
...
> + strm->next_in = rte_pktmbuf_mtod_offset(mbuf_src, uint8_t *,
> + op->src.offset);
> +
> + strm->avail_in = rte_pktmbuf_data_len(mbuf_src) - op->src.offset;
> +
> + strm->next_out = rte_pktmbuf_mtod_offset(mbuf_dst, uint8_t *,
> + op->dst.offset);
> +
> + strm->avail_out = rte_pktmbuf_data_len(mbuf_dst) - op->dst.offset;
Same comments as above (compression).
...
> +static inline int
> +process_zlib_op(struct zlib_qp *qp, struct rte_comp_op *op) {
> + struct zlib_stream *stream;
> + struct zlib_priv_xform *private_xform;
> +
> + if ((op->op_type == RTE_COMP_OP_STATEFUL) ||
> + (op->src.offset > rte_pktmbuf_data_len(op->m_src)) ||
> + (op->dst.offset > rte_pktmbuf_data_len(op->m_dst))) {
Since m_src and m_dst could be SGLs, pkt_len should be checked, instead of data_len (which would be only for single segment).
Also, you should check the length too, in case of source buffers (src.offset + src.length > m_src->pkt_len).
Lastly, the two lines after the first if line should have double indentation to distinguish clearly against the body of the if.
If line is too long, consider storing the length of the buffers in variables.
> + op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
> + ZLIB_PMD_ERR("Invalid source or destination buffers or "
> + "invalid Operation requested\n");
^ permalink raw reply
* [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Alex Williamson @ 2018-07-23 22:24 UTC (permalink / raw)
To: linux-pci; +Cc: linux-kernel, linux-nvme
In-Reply-To: <20180723221533.4371.90064.stgit@gimli.home>
Take advantage of NVMe devices using a standard interface to quiesce
the controller prior to reset, including device specific delays before
and after that reset. This resolves several NVMe device assignment
scenarios with two different vendors. The Intel DC P3700 controller
has been shown to only work as a VM boot device on the initial VM
startup, failing after reset or reboot, and also fails to initialize
after hot-plug into a VM. Adding a delay after FLR resolves these
cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
from FLR with the PCI config space reading back as -1. A reproducible
instance of this behavior is resolved by clearing the enable bit in
the configuration register and waiting for the ready status to clear
(disabling the NVMe controller) prior to FLR.
As all NVMe devices make use of this standard interface and the NVMe
specification also requires PCIe FLR support, we can apply this quirk
to all devices with matching class code.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
drivers/pci/quirks.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e72c8742aafa..83853562f220 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -28,6 +28,7 @@
#include <linux/platform_data/x86/apple.h>
#include <linux/pm_runtime.h>
#include <linux/switchtec.h>
+#include <linux/nvme.h>
#include <asm/dma.h> /* isa_dma_bridge_buggy */
#include "pci.h"
@@ -3669,6 +3670,116 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, int probe)
#define PCI_DEVICE_ID_INTEL_IVB_M_VGA 0x0156
#define PCI_DEVICE_ID_INTEL_IVB_M2_VGA 0x0166
+/* NVMe controller needs delay before testing ready status */
+#define NVME_QUIRK_CHK_RDY_DELAY (1 << 0)
+/* NVMe controller needs post-FLR delay */
+#define NVME_QUIRK_POST_FLR_DELAY (1 << 1)
+
+static const struct pci_device_id nvme_reset_tbl[] = {
+ { PCI_DEVICE(0x1bb1, 0x0100), /* Seagate Nytro Flash Storage */
+ .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
+ { PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */
+ .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
+ { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */
+ .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
+ { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
+ .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
+ { PCI_DEVICE(0x144d, 0xa821), /* Samsung PM1725 */
+ .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
+ { PCI_DEVICE(0x144d, 0xa822), /* Samsung PM1725a */
+ .driver_data = NVME_QUIRK_CHK_RDY_DELAY, },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0953), /* Intel DC P3700 */
+ .driver_data = NVME_QUIRK_POST_FLR_DELAY, },
+ { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) },
+ { 0 }
+};
+
+/*
+ * The NVMe specification requires that controllers support PCIe FLR, but
+ * but some Samsung SM961/PM961 controllers fail to recover after FLR (-1
+ * config space) unless the device is quiesced prior to FLR. Do this for
+ * all NVMe devices by disabling the controller before reset. Some Intel
+ * controllers also require an additional post-FLR delay or else attempts
+ * to re-enable will timeout, do that here as well with heuristically
+ * determined delay value. Also maintain the delay between disabling and
+ * checking ready status as used by the native NVMe driver.
+ */
+static int reset_nvme(struct pci_dev *dev, int probe)
+{
+ const struct pci_device_id *id;
+ void __iomem *bar;
+ u16 cmd;
+ u32 cfg;
+
+ id = pci_match_id(nvme_reset_tbl, dev);
+ if (!id || !pcie_has_flr(dev) || !pci_resource_start(dev, 0))
+ return -ENOTTY;
+
+ if (probe)
+ return 0;
+
+ bar = pci_iomap(dev, 0, NVME_REG_CC + sizeof(cfg));
+ if (!bar)
+ return -ENOTTY;
+
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ pci_write_config_word(dev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+ cfg = readl(bar + NVME_REG_CC);
+
+ /* Disable controller if enabled */
+ if (cfg & NVME_CC_ENABLE) {
+ u64 cap = readq(bar + NVME_REG_CAP);
+ unsigned long timeout;
+
+ /*
+ * Per nvme_disable_ctrl() skip shutdown notification as it
+ * could complete commands to the admin queue. We only intend
+ * to quiesce the device before reset.
+ */
+ cfg &= ~(NVME_CC_SHN_MASK | NVME_CC_ENABLE);
+
+ writel(cfg, bar + NVME_REG_CC);
+
+ /* A heuristic value, matches NVME_QUIRK_DELAY_AMOUNT */
+ if (id->driver_data & NVME_QUIRK_CHK_RDY_DELAY)
+ msleep(2300);
+
+ /* Cap register provides max timeout in 500ms increments */
+ timeout = ((NVME_CAP_TIMEOUT(cap) + 1) * HZ / 2) + jiffies;
+
+ for (;;) {
+ u32 status = readl(bar + NVME_REG_CSTS);
+
+ /* Ready status becomes zero on disable complete */
+ if (!(status & NVME_CSTS_RDY))
+ break;
+
+ msleep(100);
+
+ if (time_after(jiffies, timeout)) {
+ pci_warn(dev, "Timeout waiting for NVMe ready status to clear after disable\n");
+ break;
+ }
+ }
+ }
+
+ pci_iounmap(dev, bar);
+
+ /*
+ * We could use the optional NVM Subsystem Reset here, hardware
+ * supporting this is simply unavailable at the time of this code
+ * to validate in comparison to PCIe FLR. NVMe spec dictates that
+ * NVMe devices shall implement PCIe FLR.
+ */
+ pcie_flr(dev);
+
+ if (id->driver_data & NVME_QUIRK_POST_FLR_DELAY)
+ msleep(250); /* Heuristic based on Intel DC P3700 */
+
+ return 0;
+}
+
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
@@ -3678,6 +3789,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
reset_ivb_igd },
{ PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
reset_chelsio_generic_dev },
+ { PCI_ANY_ID, PCI_ANY_ID, reset_nvme },
{ 0 }
};
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.