Re: [PATCH v2 1/2] platform/x86: asus-wmi: Call led hw_changed API on kbd brightness change
On Wed, Jun 13, 2018 at 8:49 PM, Andy Shevchenko wrote: > On Mon, Jun 11, 2018 at 10:18 AM, Chris Chiu wrote: >> Make asus-wmi notify on hotkey kbd brightness changes, listen for >> brightness events and update the brightness directly in the driver. > >> For this purpose, bound check on brightness in kbd_led_set must be >> based on the same data type to prevent illegal value been set. > >> @@ -497,9 +498,9 @@ static void kbd_led_set(struct led_classdev *led_cdev, >> >> asus = container_of(led_cdev, struct asus_wmi, kbd_led); >> >> - if (value > asus->kbd_led.max_brightness) >> + if ((int)value > (int)asus->kbd_led.max_brightness) >> value = asus->kbd_led.max_brightness; >> - else if (value < 0) >> + else if ((int)value < 0) >> value = 0; > > I didn't quite understand this part of the problem. > Does it exist in the current code? Can it be split to a separate change? > > Can we avoid those ugly castings? > I'd like to remove the ugly castings but there's a concern I may need some advices. I don't know whether if the bound check logic ever verified before. Maybe the value passed via sysfs is already correctly bounded? When the kbd_led_wk comes to -1, `if (value > asus->kbd_led.max_brightness)` returns true and `if (value < 0)` return false which confused me. It should relate to the 2nd argument type is enum led_brightness which I consider it as integer. The unexpected return value cause the KBD_BRTDWN cyclic, 3->2->0->-1 (3 again in kbd_led_set)->2->1. After applying the casting on both operands `if ((int)value > (int)asus->kbd_led.max_brightness)`, the other unexpected false returned by `if (value < 0)` makes each KBD_BRTDOWN to be 3 -> 2 -> 1 -> 0 -> -1 -> -2 -> -3 ->. That's what the ugly casting for. I used to tend to do boundary limit before calling kbd_led_set as follows kbd_led_set(&asus->kbd_led, MIN(asus->kbd_led_wk + 1, asus->kbd_led.max_brightness); and kbd_led_set(&asus->kbd_led, MAX(asus->kbd_led_wk - 1, 0)); If so, the boundary limit logic would be totally redundant but I think it may be still useful to check the value passed from sysfs? Any suggestion which one would be better? Chris > -- > With Best Regards, > Andy Shevchenko
Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
Hi David,
On 06/14/2018 06:02 AM, David Collins wrote:
> Hello Rajendra,
>
> On 06/11/2018 09:40 PM, Rajendra Nayak wrote:
>> The RPMh Power domain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all power domains on sdm845 SoC as part of the patch.
>> The driver can be extended to support other SoCs which support RPMh
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> drivers/soc/qcom/Kconfig| 9 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/rpmhpd.c | 427
>> include/dt-bindings/power/qcom-rpmhpd.h | 31 ++
>> 4 files changed, 468 insertions(+)
>> create mode 100644 drivers/soc/qcom/rpmhpd.c
>> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
>
> This DT header file should be included in a DT binding patch that is
> separate from the driver patch.
>
>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 5c54931a7b99..7cb7eba2b997 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
>>
>>Say y here if you intend to boot the modem remoteproc.
>>
>> +config QCOM_RPMHPD
>> +tristate "Qualcomm RPMh Power domain driver"
>> +depends on QCOM_RPMH && QCOM_COMMAND_DB
>> +help
>> + QCOM RPMh Power domain driver to support power-domains with
>> + performance states. The driver communicates a performance state
>> + value to RPMh which then translates it into corresponding voltage
>> + for the voltage rail.
>> +
>> config QCOM_RPMPD
>> tristate "Qualcomm RPM Power domain driver"
>> depends on MFD_QCOM_RPM && QCOM_SMD_RPM
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 9550c170de93..499513f63bef 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM)+= smsm.o
>> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
>> obj-$(CONFIG_QCOM_APR) += apr.o
>> obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
>> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
>> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
>> new file mode 100644
>> index ..7083ec1590ff
>> --- /dev/null
>> +++ b/drivers/soc/qcom/rpmhpd.c
>> @@ -0,0 +1,427 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
>> +
>> +#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
>> +static struct rpmhpd _platform##_##_active; \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.peer = &_platform##_##_active, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \
>> +}; \
>> +static struct rpmhpd _platform##_##_active = { \
>> +.pd = { .name = #_active, },\
>> +.peer = &_platform##_##_name, \
>> +.active_only = true,\
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
>> +BIT(RPMH_WAKE_ONLY_STATE) | \
>> +BIT(RPMH_SLEEP_STATE)), \> +
>> }
>> +
>> +#define DEFINE_RPMHPD(_platform, _name)
>> \
>> +static struct rpmhpd _platform##_##_name = {\
>> +.pd = { .name = #_name, }, \
>> +.res_name = #_name".lvl", \
>> +.valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
>> +}
>> +
>> +/*
>> + * This is the number of bytes used for each command DB aux data entry of an
>> + * ARC resource.
>> + */
>> +#define RPMH_ARC_LEVEL_SIZE 2
>> +#define RPMH_ARC_MAX_LEVELS 16
>> +
>
>
> Would you mind adding a kernel-doc comment for here for struct rpmhpd? I
> think that would make the code clearer. It would be good to mention the
> numbering spaces for 'corner' and 'level' elements as well as the usage of
> 'peer' and 'active_only' elemen
Re: [PATCH v2 4/5] thermal: tsens: Add support for SDM845
Hi Amit,
On Tue, Jun 12, 2018 at 4:24 PM, Amit Kucheria wrote:
> SDM845 uses the TSENS v2 IP block
>
> Signed-off-by: Amit Kucheria
> ---
> Documentation/devicetree/bindings/thermal/qcom-tsens.txt | 1 +
> drivers/thermal/qcom/Makefile| 2 +-
> drivers/thermal/qcom/tsens-sdm845.c | 15 +++
> drivers/thermal/qcom/tsens.c | 3 +++
> drivers/thermal/qcom/tsens.h | 5 -
> 5 files changed, 24 insertions(+), 2 deletions(-)
> create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89..8652499 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -5,6 +5,7 @@ Required properties:
> - "qcom,msm8916-tsens" : For 8916 Family of SoCs
> - "qcom,msm8974-tsens" : For 8974 Family of SoCs
> - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> + - "qcom,sdm845-tsens" : For SDM845 Family of SoCs
>
> - reg: Address range of the thermal registers
> - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 2cc2193..dc9f169 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_QCOM_TSENS) += qcom_tsens.o
> -qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o
> tsens-8974.o tsens-8960.o tsens-8996.o
> +qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o
> tsens-8974.o tsens-8960.o tsens-8996.o tsens-sdm845.o
> diff --git a/drivers/thermal/qcom/tsens-sdm845.c
> b/drivers/thermal/qcom/tsens-sdm845.c
> new file mode 100644
> index 000..a647265
> --- /dev/null
> +++ b/drivers/thermal/qcom/tsens-sdm845.c
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include "tsens.h"
> +
> +static const struct tsens_ops ops_sdm845 = {
> + .init = init_common,
> + .get_temp = get_temp_tsens_v2,
> +};
> +
> +const struct tsens_data data_sdm845 = {
Just a minor nit. 'static' here?
> + .ops= &ops_sdm845,
> +};
[snip]
Thanks & Regards
Vivek
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 5/5] soc: qcom: Remove depends on ARCH_QCOM
On Thu, Jun 14, 2018 at 12:05 PM, Vivek Gautam
wrote:
> On Wed, Jun 13, 2018 at 6:24 PM, Niklas Cassel
> wrote:
>> Since commit cab673583d96 ("soc: Unconditionally include qcom Makefile"),
>> we unconditionally include the soc/qcom/Makefile.
>>
>> This opens up the possibility to compile test the code even when
>> building for other architectures.
>
> Why do we want to do this when all of it is qcom specific?
> Besides, wouldn't this increase the binary size for other platforms.
Sorry, my bad. Send the message without completing.
Besides above points, the COMPILE_TEST flag should allow you
to compile test all of these drivers. If COMPILE_TEST is missing
in some of the configs, we should try adding that.
Or, is there anything that I am missing here for the intention of this patch?
Thanks & Regards
Vivek
>
>>
>> Remove the depends on ARCH_QCOM for all Kconfigs, except for
>> two Kconfigs that depend on QCOM_SCM, since that triggers lots of build
>> errors in qcom_scm. However, that shouldn't stop us from removing
>> it from those where it is possible.
>>
>> Signed-off-by: Niklas Cassel
>> ---
>> drivers/soc/qcom/Kconfig | 10 ++
>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 1d4a9f3ada8c..8c83025c466e 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -5,7 +5,7 @@ menu "Qualcomm SoC drivers"
>>
>> config QCOM_COMMAND_DB
>> bool "Qualcomm Command DB"
>> - depends on (ARCH_QCOM && OF) || COMPILE_TEST
>> + depends on OF || COMPILE_TEST
>> help
>> Command DB queries shared memory by key string for shared system
>> resources. Platform drivers that require to set state of a shared
>> @@ -14,7 +14,6 @@ config QCOM_COMMAND_DB
>>
>> config QCOM_GENI_SE
>> tristate "QCOM GENI Serial Engine Driver"
>> - depends on ARCH_QCOM || COMPILE_TEST
>> help
>> This driver is used to manage Generic Interface (GENI) firmware
>> based
>> Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper.
>> This
>> @@ -32,7 +31,6 @@ config QCOM_GLINK_SSR
>>
>> config QCOM_GSBI
>> tristate "QCOM General Serial Bus Interface"
>> -depends on ARCH_QCOM
>> select MFD_SYSCON
>> help
>>Say y here to enable GSBI support. The GSBI provides control
>> @@ -55,7 +53,7 @@ config QCOM_PM
>>
>> config QCOM_QMI_HELPERS
>> tristate
>> - depends on ARCH_QCOM && NET
>> + depends on NET
>> help
>> Helper library for handling QMI encoded messages. QMI encoded
>> messages are used in communication between the majority of QRTR
>> @@ -76,7 +74,6 @@ config QCOM_RMTFS_MEM
>>
>> config QCOM_SMEM
>> tristate "Qualcomm Shared Memory Manager (SMEM)"
>> - depends on ARCH_QCOM
>> depends on HWSPINLOCK
>> help
>> Say y here to enable support for the Qualcomm Shared Memory
>> Manager.
>> @@ -85,7 +82,6 @@ config QCOM_SMEM
>>
>> config QCOM_SMD_RPM
>> tristate "Qualcomm Resource Power Manager (RPM) over SMD"
>> - depends on ARCH_QCOM
>> depends on RPMSG && OF
>> help
>> If you say yes to this option, support will be included for the
>> @@ -122,7 +118,6 @@ config QCOM_SMSM
>>
>> config QCOM_WCNSS_CTRL
>> tristate "Qualcomm WCNSS control driver"
>> - depends on ARCH_QCOM
>> depends on RPMSG
>> help
>> Client driver for the WCNSS_CTRL SMD channel, used to download nv
>> @@ -130,7 +125,6 @@ config QCOM_WCNSS_CTRL
>>
>> config QCOM_APR
>> tristate "Qualcomm APR Bus (Asynchronous Packet Router)"
>> - depends on ARCH_QCOM
>> depends on RPMSG
>> help
>>Enable APR IPC protocol support between
>> --
>> 2.17.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2] x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
On Thu, Jun 14, 2018 at 07:38:59AM +0200, Oscar Salvador wrote:
> On Thu, Jun 14, 2018 at 05:16:18AM +, Naoya Horiguchi wrote:
...
> >
> > My concern is that there are a few E820 memory types rather than
> > E820_TYPE_RAM and E820_TYPE_RESERVED, and I'm not sure that putting them
> > all into memblock.reserved is really acceptable.
>
> Hi Naoya,
>
> Maybe you could just add to memblock.reserved, all unavailable ranges within
> E820_TYPE_RAM.
> Actually, in your original patch, you are walking memblock.memory, which
> should
> only contain E820_TYPE_RAM ranges (talking about x86).
>
> So I think the below would to the trick as well?
>
> @@ -1248,6 +1276,7 @@ void __init e820__memblock_setup(void)
> {
> int i;
> u64 end;
> + u64 next = 0;
>
> /*
> * The bootstrap memblock region count maximum is 128 entries
>
> @@ -1269,6 +1299,14 @@ void __init e820__memblock_setup(void)
>
> if (entry->type != E820_TYPE_RAM && entry->type !=
> E820_TYPE_RESERVED_KERN)
> continue;
>
> +
> + if (entry->type == E820_TYPE_RAM)
> + if (next < entry->addr) {
> + memblock_reserve (next, next + (entry->addr -
> next));
> + next = end;
> + }
>
> With the above patch, I can no longer see the issues either.
I double-checked and this change looks good to me.
>
> Although, there is a difference between this and your original patch.
> In your original patch, you are just zeroing the pages, while with this one
> (or with your second patch),
> we will zero the page in reserve_bootmem_region(), but that function also init
> some other fields of the struct page:
>
> mm_zero_struct_page(page);
> set_page_links(page, zone, nid, pfn);
> init_page_count(page);
> page_mapcount_reset(page);
> page_cpupid_reset_last(page);
>
> So I am not sure we want to bother doing that for pages that are really
> unreachable.
I think that considering that /proc/kpageflags can check them, some data
(even if it's trivial) might be better than just zeros.
Here's the updated patch.
Thanks for the suggestion and testing!
---
From: Naoya Horiguchi
Date: Thu, 14 Jun 2018 14:44:36 +0900
Subject: [PATCH] x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
There is a kernel panic that is triggered when reading /proc/kpageflags
on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
BUG: unable to handle kernel paging request at fffe
PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
Oops: [#1] SMP PTI
CPU: 2 PID: 1728 Comm: page-types Not tainted
4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
04/01/2014
RIP: 0010:stable_page_flags+0x27/0x3c0
Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53
48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84
10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
RSP: 0018:bbd44111fde0 EFLAGS: 00010202
RAX: fffe RBX: 7fffeff9 RCX:
RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
RBP: R08: 0001 R09: 0001
R10: bbd44111fed8 R11: R12: ed1182fff5c0
R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
FS: 7efc4335a500() GS:93a5bfc0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: fffe CR3: b2a58000 CR4: 001406e0
Call Trace:
kpageflags_read+0xc7/0x120
proc_reg_read+0x3c/0x60
__vfs_read+0x36/0x170
vfs_read+0x89/0x130
ksys_pread64+0x71/0x90
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7efc42e75e23
Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83
3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34
c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
According to kernel bisection, this problem became visible due to commit
f7f99100d8d9 which changes how struct pages are initialized.
Memblock layout affects the pfn ranges covered by node/zone. Consider
that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
the default (no memmap= given) memblock layout is like below:
MEMBLOCK configuration:
memory size = 0x0001fff75c00 reserved size = 0x0300c000
memory.cnt = 0x4
memory[0x0] [0x1000-0x0009efff], 0x0009e000
bytes on node 0 flags: 0x0
memory[0x1] [0x0010-0xbffd6fff], 0xbfed7000
bytes on node 0 flags: 0x0
memory[0x2] [0x0001-0x00013fff], 0x4000
bytes on node 0 flags: 0x0
memory[0x3] [0x00014000-0x00023fff], 0x0001
bytes on node 1
Re: [PATCH 7/7] tty: serial: lantiq: Add CCF support
On 6/13/2018 6:39 AM, Rob Herring wrote:
On Tue, Jun 12, 2018 at 01:40:34PM +0800, Songjun Wu wrote:
Previous implementation uses platform-dependent API to get the clock.
Those functions are not available for other SoC which uses the same IP.
The CCF (Common Clock Framework) have an abstraction based APIs
for clock.
Change to use CCF APIs to get clock and rate.
So that different SoCs can use the same driver.
Clocks and clock-names are updated in device tree binding.
Signed-off-by: Songjun Wu
---
.../devicetree/bindings/serial/lantiq_asc.txt | 15 +++
Please split bindings to separate patch.
Thanks.
It will be split to two separate patches, one for bindings, the other
for code.
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/lantiq.c| 101 +
3 files changed, 98 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
index 3acbd309ab9d..608f0c87a4af 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
depends on the interrupt-parent interrupt controller.
+Optional properties:
+- clocks: Should contain frequency clock and gate clock
+- clock-names: Should be "freq" and "asc"
+
Example:
asc1: serial@e100c00 {
@@ -14,3 +18,14 @@ asc1: serial@e100c00 {
interrupt-parent = <&icu0>;
interrupts = <112 113 114>;
};
+
+asc0: serial@60 {
+ compatible = "lantiq,asc";
+ reg = <0x60 0x10>;
1MB of address space? That wastes a lot of virtual space on 32-bit
systems. Just make the size the actual used range.
The size of address space will be updated to the actual used range.
+ interrupt-parent = <&gic>;
+ interrupts = ,
+ ,
+ ;
+ clocks = <&pll0aclk SSX4_CLK>, <&clkgate1 GATE_URT_CLK>;
+ clock-names = "freq", "asc";
+};
Re: [PATCH v3 7/7] soc: qcom: rpmpd/rpmhpd: Add a max vote on all corners at init
On 06/14/2018 03:58 AM, David Collins wrote:
> Hello Rajendra,
>
> On 06/11/2018 09:40 PM, Rajendra Nayak wrote:
>> As we move from no clients/consumers in kernel voting on corners,
>> to *some* voting and some not voting, we might end up in a situation
>> where the clients which remove votes can adversly impact others
>
> s/adversly/adversely/
>
>> who still don't have a way to vote.
>>
>> To avoid this situation, have a max vote on all corners at init.
>> This should/can be removed once we have all clients moved to
>> be able to vote/unvote for themselves.
>
> This change seems like a hack. Do you intend for it to be merged and then
> later reverted in Linus's tree? Could it instead be implemented in a way
> that does not require reverting and instead is enabled by some DT
> property? Alternatively, could this feature be added to the power domain
> core since it is relatively generic?
>
>
>> Signed-off-by: Rajendra Nayak
>> Acked-by: Viresh Kumar
>> ---
>> drivers/soc/qcom/rpmhpd.c | 12 +++-
>> drivers/soc/qcom/rpmpd.c | 9 +
>> 2 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
>> index 7083ec1590ff..3c753d33aeee 100644
>> --- a/drivers/soc/qcom/rpmhpd.c
>> +++ b/drivers/soc/qcom/rpmhpd.c
>> @@ -329,7 +329,7 @@ static int rpmhpd_update_level_mapping(struct rpmhpd
>> *rpmhpd)
>>
>> static int rpmhpd_probe(struct platform_device *pdev)
>> {
>> -int i, ret;
>> +int i, ret, max_level;
>> size_t num;
>> struct genpd_onecell_data *data;
>> struct rpmhpd **rpmhpds;
>> @@ -390,6 +390,16 @@ static int rpmhpd_probe(struct platform_device *pdev)
>> pm_genpd_init(&rpmhpds[i]->pd, NULL, true);
>>
>> data->domains[i] = &rpmhpds[i]->pd;
>> +
>> +/*
>> + * Until we have all consumers voting on corners
>> + * just vote the max corner on all PDs
>> + * This should ideally be *removed* once we have
>> + * all (most) consumers being able to vote
>> + */
>> +max_level = rpmhpds[i]->level_count - 1;
>> +rpmhpd_set_performance(&rpmhpds[i]->pd,
>> rpmhpds[i]->level[max_level]);
>> +rpmhpd_power_on(&rpmhpds[i]->pd);
>
> Clearly these calls will result in max level requests being sent for all
> power domains at probe time. However, it isn't clear that this will
> actually help at runtime in these two cases:
>
> 1. A consumer enables and then disables a power domain.
> - It seems like the PD would just be disabled in this case.
>
> 2. A consumer sets a non-max performance state of a power domain.
> - It seems like the PD would just be set to the new lower
> performance state since the max vote isn't known to the
> PD core for aggregation purposes.
Yes, you are right. I certainly did not seem to have thought through this
enough.
A need for something like this came up at a point where genpd could not deal
with
devices with multiple power domains. So the concern at that point was that if
some
consumers (which only need to vote on one corner) move to using this driver,
while
some others (which need to vote on multiple corners) cannot, we would end up
breaking
them.
That does not seem to be true anymore since we do have patches from Ulf which
support
having devices with multiple power domains attached which can be controlled
individually.
So if some consumer voting makes some others break, they should just be fixed
and patched
to vote as well. If all this gets handled centrally from within the clock
drivers then we
most likely won't even end up with a situation like this.
I think I will just drop this one unless Stephen/Viresh still see an issue with
some early
voters breaking others.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Re: [PATCH 4.4 00/24] 4.4.137-stable review
On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> On 13 June 2018 at 18:08, Rafael David Tinoco
> wrote:
> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> > wrote:
> >> On Wed, Jun 13, 2018 at 05:47:49PM -0300, Rafael Tinoco wrote:
> >>> Results from Linaro’s test farm.
> >>> Regressions detected.
> >>>
> >>> NOTE:
> >>>
> >>> 1) LTP vma03 test (cve-2011-2496) broken on v4.4-137-rc1 because of:
> >>>
> >>> 6ea1dc96a03a mmap: relax file size limit for regular files
> >>> bd2f9ce5bacb mmap: introduce sane default mmap limits
> >>>
> >>>discussion:
> >>>
> >>> https://github.com/linux-test-project/ltp/issues/341
> >>>
> >>>mainline commit (v4.13-rc7):
> >>>
> >>> 0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
> >>>
> >>>should be backported to 4.4.138-rc2 and fixes the issue.
> >>
> >> Really? That commit says it fixes c2a9737f45e2 ("vfs,mm: fix a dead
> >> loop in truncate_inode_pages_range()") which is not in 4.4.y at all.
> >>
> >> Did you test this out?
> >
> > Yes, the LTP contains the tests (last comment is the final test for
> > arm32, right before Jan tests i686).
> >
> > Fixing MAX_LFS_FILESIZE fixes the new limit for mmap() brought by
> > those 2 commits (file_mmap_size_max()).
> > offset tested by the LTP test is 0xfffe000.
> > file_mmap_size_max gives: 0x000 as max value, but only after
> > the mentioned patch.
> >
> > Original intent for this fix was other though.
>
> To clarify this a bit further.
>
> The LTP CVE test is breaking in the first call to mmap(), even before
> trying to remap and test the security issue. That start happening in
> this round because of those mmap() changes and the offset used in the
> LTP test. Linus changed limit checks and made them to be related to
> MAX_LFS_FILESIZE. Unfortunately, in 4.4 stable, we were missing the
> fix for MAX_LFS_FILESIZE (which before commit 0cc3b0ec23ce was less
> than the REAL 32 bit limit).
>
> Commit 0cc3b0ec23ce was made because an user noticed the FS limit not
> being what it should be. In our case, the 4.4 stable kernel, we are
> facing this 32 bit lower limit (than the real 32 bit real limit),
> because of the LTP CVE test, so we need this fix to have the real 32
> bit limit set for that macro (mmap limits did not use that macro
> before).
>
> I have tested in arm32 and Jan Stancek, who first responded to LTP
> issue, has tested this in i686 and both worked after that patch was
> included to v4.4-137-rc1 (my last test was even with 4.4.138-rc1).
>
> Hope that helps a bit.
Ok, thanks, it didn't apply cleanly but I've fixed it up now.
greg k-h
Re: [PATCH 5/5] soc: qcom: Remove depends on ARCH_QCOM
On Wed, Jun 13, 2018 at 6:24 PM, Niklas Cassel wrote:
> Since commit cab673583d96 ("soc: Unconditionally include qcom Makefile"),
> we unconditionally include the soc/qcom/Makefile.
>
> This opens up the possibility to compile test the code even when
> building for other architectures.
Why do we want to do this when all of it is qcom specific?
Besides wouldn't this increase the binary size for other platforms
>
> Remove the depends on ARCH_QCOM for all Kconfigs, except for
> two Kconfigs that depend on QCOM_SCM, since that triggers lots of build
> errors in qcom_scm. However, that shouldn't stop us from removing
> it from those where it is possible.
>
> Signed-off-by: Niklas Cassel
> ---
> drivers/soc/qcom/Kconfig | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 1d4a9f3ada8c..8c83025c466e 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -5,7 +5,7 @@ menu "Qualcomm SoC drivers"
>
> config QCOM_COMMAND_DB
> bool "Qualcomm Command DB"
> - depends on (ARCH_QCOM && OF) || COMPILE_TEST
> + depends on OF || COMPILE_TEST
> help
> Command DB queries shared memory by key string for shared system
> resources. Platform drivers that require to set state of a shared
> @@ -14,7 +14,6 @@ config QCOM_COMMAND_DB
>
> config QCOM_GENI_SE
> tristate "QCOM GENI Serial Engine Driver"
> - depends on ARCH_QCOM || COMPILE_TEST
> help
> This driver is used to manage Generic Interface (GENI) firmware
> based
> Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
> @@ -32,7 +31,6 @@ config QCOM_GLINK_SSR
>
> config QCOM_GSBI
> tristate "QCOM General Serial Bus Interface"
> -depends on ARCH_QCOM
> select MFD_SYSCON
> help
>Say y here to enable GSBI support. The GSBI provides control
> @@ -55,7 +53,7 @@ config QCOM_PM
>
> config QCOM_QMI_HELPERS
> tristate
> - depends on ARCH_QCOM && NET
> + depends on NET
> help
> Helper library for handling QMI encoded messages. QMI encoded
> messages are used in communication between the majority of QRTR
> @@ -76,7 +74,6 @@ config QCOM_RMTFS_MEM
>
> config QCOM_SMEM
> tristate "Qualcomm Shared Memory Manager (SMEM)"
> - depends on ARCH_QCOM
> depends on HWSPINLOCK
> help
> Say y here to enable support for the Qualcomm Shared Memory Manager.
> @@ -85,7 +82,6 @@ config QCOM_SMEM
>
> config QCOM_SMD_RPM
> tristate "Qualcomm Resource Power Manager (RPM) over SMD"
> - depends on ARCH_QCOM
> depends on RPMSG && OF
> help
> If you say yes to this option, support will be included for the
> @@ -122,7 +118,6 @@ config QCOM_SMSM
>
> config QCOM_WCNSS_CTRL
> tristate "Qualcomm WCNSS control driver"
> - depends on ARCH_QCOM
> depends on RPMSG
> help
> Client driver for the WCNSS_CTRL SMD channel, used to download nv
> @@ -130,7 +125,6 @@ config QCOM_WCNSS_CTRL
>
> config QCOM_APR
> tristate "Qualcomm APR Bus (Asynchronous Packet Router)"
> - depends on ARCH_QCOM
> depends on RPMSG
> help
>Enable APR IPC protocol support between
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] pinctrl: qcom: spmi-gpio: Add pm8998 and pm8005 to binding
On 6/13/2018 4:36 AM, Stephen Boyd wrote: Update the binding for two more PMICs supported by the same driver. While we're here, remove the duplicate pmi8994 lines because that support got merged twice. Cc: Rajendra Nayak Cc: Vivek Gautam Cc: Signed-off-by: Stephen Boyd --- .../devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index 5c25fcb29fb5..ffd4345415f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -7,6 +7,7 @@ PMIC's from Qualcomm. Usage: required Value type: Definition: must be one of: + "qcom,pm8005-gpio" "qcom,pm8018-gpio" "qcom,pm8038-gpio" "qcom,pm8058-gpio" @@ -15,7 +16,7 @@ PMIC's from Qualcomm. "qcom,pm8921-gpio" "qcom,pm8941-gpio" "qcom,pm8994-gpio" - "qcom,pmi8994-gpio" Thanks. Reviewed-by: Vivek Gautam BRs Vivek + "qcom,pm8998-gpio" "qcom,pma8084-gpio" "qcom,pmi8994-gpio" @@ -78,6 +79,7 @@ to specify in a pin configuration subnode: Value type: Definition: List of gpio pins affected by the properties specified in this subnode. Valid pins are: + gpio1-gpio4 for pm8005 gpio1-gpio6 for pm8018 gpio1-gpio12 for pm8038 gpio1-gpio40 for pm8058 @@ -86,7 +88,7 @@ to specify in a pin configuration subnode: gpio1-gpio44 for pm8921 gpio1-gpio36 for pm8941 gpio1-gpio22 for pm8994 - gpio1-gpio10 for pmi8994 + gpio1-gpio26 for pm8998 gpio1-gpio22 for pma8084 gpio1-gpio10 for pmi8994
Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)
On Thu, Jun 14, 2018 at 3:16 AM Masahiro Yamada wrote: > > Could you run sed directly in your tree? Sure, I did that on the plane. Now on the ground, pushed out. Somebody should double- and triple-check it. Linus
Re: [PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings
Hi David,
On 06/14/2018 03:42 AM, David Collins wrote:
> Hello Rajendra,
>
> On 06/11/2018 09:40 PM, Rajendra Nayak wrote:
>> Add DT bindings to describe the rpmh powerdomains found on Qualcomm
>
> s/powerdomains/power domains/
>
>> Technologies, Inc. SoCs. These power domains communicate a performance
>> state to RPMh, which then translates it into corresponding voltage on
>> a PMIC rail.
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> .../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
>> 1 file changed, 65 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>
> include/dt-bindings/power/qcom-rpmhpd.h from patch 6/7 should be moved to
> this patch.
right, Rob mentioned this too, I will move it in v4.
>
>>
>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> new file mode 100644
>> index ..41ef7afa6b24
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> @@ -0,0 +1,65 @@
>> +Qualcomm RPMh Power domains
>> +
>> +For RPMh Power domains, we communicate a performance state to RPMh
>> +which then translates it into a corresponding voltage on a rail
>> +
>> +Required Properties:
>> + - compatible: Should be one of the following
>> +* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
>> + - power-domain-cells: number of cells in power domain specifier
>> +must be 1
>> + - operating-points-v2: Phandle to the OPP table for the power-domain.
>> +Refer to Documentation/devicetree/bindings/power/power_domain.txt
>> +and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
>
> Could you please mention here that qcom,level properties in the associated
> opp-table should use the RPMH_REGULATOR_LEVEL_* constants? RPMh ARC
> resources depend upon the RPMH_REGULATOR_LEVEL_* constants to provide a
> mapping of levels supported by hardware.
>
>> +Example:
>
> Could you please add this here?
>
> #include
I will, I wasn't sure its okay to reference a kernel include file in a DT
binding documentation. But looking around it seems like its common practice.
>
>> +
>> +rpmhpd: power-controller {
>> +compatible = "qcom,sdm845-rpmhpd";
>> +#power-domain-cells = <1>;
>> +operating-points-v2 = <&rpmhpd_opp_table>;
>> +};
>> +
>> +rpmhpd_opp_table: opp-table {
>> +compatible = "operating-points-v2-qcom-level";
>> +
>> +rpmhpd_opp_ret: opp1 {
>> +qcom-level = <16>;
>
> As per qcom-opp.txt, 'qcom,level' should be used, not 'qcom-level'.
d'oh! I just keep getting this wrong.
>
> Where is the qcom-opp.txt patch? It isn't part of the v3 patch series but
> was in the v2 series [1].
Oops, looks like I accidentally dropped it in v3 :(
>
> Could you please change this to be the following?
>
> qcom,level = ;
>
> Also, please use the level constants for all other subnodes in this
> example as well.
>
>> +};
>> +
>> +rpmhpd_opp_min_svs: opp2 {
>> +qcom-level = <48>;
>> +};
>> +
>> +rpmhpd_opp_low_svs: opp3 {
>> +qcom-level = <64>;
>> +};
>> +
>> +rpmhpd_opp_svs: opp4 {
>> +qcom-level = <128>;
>> +};
>> +
>> +rpmhpd_opp_svs_l1: opp5 {
>> +qcom-level = <192>;
>> +};
>> +
>> +rpmhpd_opp_nom: opp6 {
>> +qcom-level = <256>;
>> +};
>> +
>> +rpmhpd_opp_nom_l1: opp7 {
>> +qcom-level = <320>;
>> +};
>> +
>> +rpmhpd_opp_nom_l2: opp8 {
>> +qcom-level = <336>;
>> +};
>> +
>> +rpmhpd_opp_turbo: opp9 {
>> +qcom-level = <384>;
>> +};
>> +
>> +rpmhpd_opp_turbo_l1: opp10 {
>> +qcom-level = <416>;
>> +};
>> +};
>
> Could you please add an example consumer DT node as well which uses
> "SDM845 Power Domain Indexes" from qcom-rpmhpd.h? It isn't clear how a
> specific power domain (e.g. SDM845_CX) is specified from the consumer
> side. It also isn't clear how the consumer specifies a mapping for the
> power domain levels that it will be using.
I can add an example consumer with a power-domains property pointing to
the phandle and index (as is general practice)
For specifying the power domain levels, I am not quite sure what the approach
we would use. One way is for consumers to use OPP bindings, but that wasn't
liked by some and we now have plans to stuff it all within the clock driver
code.
In which case I expect we would just maintain internal mapping tables for clock
frequencies/power domain levels so nothing comes in from DT, or maybe it will
come in from DT, i just don't know.
I can certainly describ
[tip:perf/urgent] perf script: Show hw-cache events
Commit-ID: fad76d4333fe73cf3f73704aa34d4ce523b1c458
Gitweb: https://git.kernel.org/tip/fad76d4333fe73cf3f73704aa34d4ce523b1c458
Author: Seeteena Thoufeek
AuthorDate: Fri, 8 Jun 2018 16:32:28 +0530
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 8 Jun 2018 13:41:30 -0300
perf script: Show hw-cache events
'perf script' fails to report hardware cache events (PERF_TYPE_HW_CACHE)
where as 'perf report' shows the samples. Fix it. Ex,
# perf record -e L1-dcache-loads ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.008 MB perf.data (11 samples)]
Before patch:
# perf script | wc -l
0
After patch:
# perf script | wc -l
11
Committer testing:
[root@jouet ~]# perf script | head -30 | tail
Timer 9803 [2] 8.963330: 1554 L1-dcache-loads: 7ffef89baae4
__vdso_clock_gettime+0xf4 ([vdso])
swapper0 [2] 8.963343: 5626 L1-dcache-loads: a66f4f6b
cpuidle_not_av+0xb (/lib/modules/4.17.0-rc5/build/vmlinux)
firefox 4853 [2] 8.964070: 18935 L1-dcache-loads: 7f0b9a00dc30
xcb_poll_for_event+0x0 (/usr/lib64/libxcb.so.1.1.0)
Softwar~cTh 4928 [2] 8.964548: 15928 L1-dcache-loads: a60d795c
update_curr+0x10c (/lib/modules/4.17.0-rc5/build/vmlinux)
firefox 4853 [2] 8.964675: 14978 L1-dcache-loads: a6897018
mutex_unlock+0x18 (/lib/modules/4.17.0-rc5/build/vmlinux)
gnome-shell 2026 [3] 8.964693: 50670 L1-dcache-loads: 7fa08854de6d
g_source_iter_next+0x6d (/usr/lib64/libglib-2.0.so.0.5400.3)
Compositor 4929 [1] 8.964784: 71772 L1-dcache-loads: 7f0b936bf078 [unknown]
(/usr/lib64/firefox/libxul.so)
Xwayland 2096 [2] 8.964919: 16799 L1-dcache-loads: 7f68ce2fcb8a
glXGetCurrentContext+0x1a (/usr/lib64/libGLX.so.0.0.0)
gnome-shell 2026 [3] 8.964997: 50670 L1-dcache-loads: 7fa08854de6d
g_source_iter_next+0x6d (/usr/lib64/libglib-2.0.so.0.5400.3)
[root@jouet ~]#
Signed-off-by: Seeteena Thoufeek
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1528455748-20087-1-git-send-email-s1see...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 12
1 file changed, 12 insertions(+)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b3bf35512d21..a31d7082188e 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -180,6 +180,18 @@ static struct {
PERF_OUTPUT_EVNAME | PERF_OUTPUT_TRACE
},
+ [PERF_TYPE_HW_CACHE] = {
+ .user_set = false,
+
+ .fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
+ PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
+ PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD,
+
+ .invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
+ },
+
[PERF_TYPE_RAW] = {
.user_set = false,
Re: [PATCH 1/2] arm64: avoid alloc memory on offline node
Hi Punit,
On 2018/6/14 1:39, Punit Agrawal wrote:
> Punit Agrawal writes:
>
>
> [...]
>
>>
>> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
>> up returning the original node in the fallback path.
>>
>> Xie, does the below patch help? I can submit a proper patch if this
>> fixes the issue for you.
>>
>> -- >8 --
>> Subject: [PATCH] arm64/numa: Enable memoryless numa nodes
>>
>> Signed-off-by: Punit Agrawal
>> ---
>> arch/arm64/Kconfig | 4
>> arch/arm64/mm/numa.c | 2 ++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index eb2cf4938f6d..5317e9aa93ab 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID
>> def_bool y
>> depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> + def_bool y
>> + depends on NUMA
>> +
>> config HAVE_SETUP_PER_CPU_AREA
>> def_bool y
>> depends on NUMA
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index dad128ba98bf..c699dcfe93de 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node);
>> static void map_cpu_to_node(unsigned int cpu, int nid)
>> {
>> set_cpu_numa_node(cpu, nid);
>> +set_numa_mem(local_memory_node(nid));
>
> Argh, this should be
>
> set_cpu_numa_mem(cpu, local_memory_node(nid));
>
> There is not guarantee that map_cpu_to_node() will be called on the
> local cpu.
>
> Hanjun, Xie - can you try with the update please?
Thanks for looking into this, we will try this tomorrow
(the hardware is occupied now) and update here.
Thanks
Hanjun
[tip:perf/urgent] perf c2c: Keep struct hist_entry at the end of struct c2c_hist_entry
Commit-ID: 4c8205273626f27b9e5a64bdc194ab483a8cce66
Gitweb: https://git.kernel.org/tip/4c8205273626f27b9e5a64bdc194ab483a8cce66
Author: Jiri Olsa
AuthorDate: Fri, 8 Jun 2018 02:22:11 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 8 Jun 2018 13:35:53 -0300
perf c2c: Keep struct hist_entry at the end of struct c2c_hist_entry
Exactly as the comment just before 'struct c2c_hist_entry" says, i.e.
the last entry in struct hist_entry is a zero length array, that when
allocating space for hist_entry gets extra space if callchains are in
use, which, if hist_entry is not at the end of c2c_hist_entry, the
members after it gets corrupted when callchains get added to the rb
trees collecting them, etc.
Signed-off-by: Jiri Olsa
Reported-by: Arnaldo Carvalho de Melo
Cc: Jin Yao
Fixes: 7f834c2e84bb ("perf c2c report: Display node for cacheline address")
Link: http://lkml.kernel.org/n/tip-bh0ke4fh2ygpj3yowna7o...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-c2c.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 307b3594525f..6a8738f7ead3 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -56,16 +56,16 @@ struct c2c_hist_entry {
struct compute_stats cstats;
+ unsigned longpaddr;
+ unsigned longpaddr_cnt;
+ bool paddr_zero;
+ char*nodestr;
+
/*
* must be at the end,
* because of its callchain dynamic entry
*/
struct hist_entry he;
-
- unsigned longpaddr;
- unsigned longpaddr_cnt;
- bool paddr_zero;
- char*nodestr;
};
static char const *coalesce_default = "pid,iaddr";
[tip:perf/urgent] perf stat: Add event parsing error handling to add_default_attributes
Commit-ID: a5cfa6217c94a1f1cfad4481fc14f5fc399abde3
Gitweb: https://git.kernel.org/tip/a5cfa6217c94a1f1cfad4481fc14f5fc399abde3
Author: Jiri Olsa
AuthorDate: Thu, 7 Jun 2018 00:15:10 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 16:03:21 -0300
perf stat: Add event parsing error handling to add_default_attributes
Add missing error handling for parse_events calls in add_default_attributes
functions. The error handler displays error details, like for transactions (-T):
Before:
$ perf stat -T
Cannot set up transaction events
After:
$ perf stat -T
Cannot set up transaction events
event syntax error:
'..cycles,cpu/cycles-t/,cpu/tx-start/,cpu/el-start/,cpu/cycles-ct/}'
\___ unknown term
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20180606221513.11302-8-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 3fc1f5286d50..22547a490e1f 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -2442,14 +2442,13 @@ static int add_default_attributes(void)
(PERF_COUNT_HW_CACHE_OP_PREFETCH<< 8) |
(PERF_COUNT_HW_CACHE_RESULT_MISS<< 16)
},
};
+ struct parse_events_error errinfo;
/* Set attrs if no event is selected and !null_run: */
if (null_run)
return 0;
if (transaction_run) {
- struct parse_events_error errinfo;
-
if (pmu_have_event("cpu", "cycles-ct") &&
pmu_have_event("cpu", "el-start"))
err = parse_events(evsel_list, transaction_attrs,
@@ -2460,6 +2459,7 @@ static int add_default_attributes(void)
&errinfo);
if (err) {
fprintf(stderr, "Cannot set up transaction events\n");
+ parse_events_print_error(&errinfo, transaction_attrs);
return -1;
}
return 0;
@@ -2485,10 +2485,11 @@ static int add_default_attributes(void)
pmu_have_event("msr", "smi")) {
if (!force_metric_only)
metric_only = true;
- err = parse_events(evsel_list, smi_cost_attrs, NULL);
+ err = parse_events(evsel_list, smi_cost_attrs,
&errinfo);
} else {
fprintf(stderr, "To measure SMI cost, it needs "
"msr/aperf/, msr/smi/ and cpu/cycles/
support\n");
+ parse_events_print_error(&errinfo, smi_cost_attrs);
return -1;
}
if (err) {
@@ -2523,12 +2524,13 @@ static int add_default_attributes(void)
if (topdown_attrs[0] && str) {
if (warn)
arch_topdown_group_warn();
- err = parse_events(evsel_list, str, NULL);
+ err = parse_events(evsel_list, str, &errinfo);
if (err) {
fprintf(stderr,
"Cannot set up top down events %s:
%d\n",
str, err);
free(str);
+ parse_events_print_error(&errinfo, str);
return -1;
}
} else {
Re: [PATCH 01/14] ubi: fastmap: Read PEB numbers more carefully
Am Donnerstag, 14. Juni 2018, 03:04:40 CEST schrieb kbuild test robot:
> Hi Richard,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on mtd/master]
> [also build test WARNING on v4.17 next-20180613]
> [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/Richard-Weinberger/ubi-Fastmap-updates/20180614-052830
> base: git://git.infradead.org/linux-mtd.git master
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
> >> drivers/mtd/ubi/fastmap.c:110:14: sparse: incorrect type in assignment
> >> (different base types) @@expected restricted __be32 [usertype] pnum @@
> >>got [usertype] pnum @@
>drivers/mtd/ubi/fastmap.c:110:14:expected restricted __be32 [usertype]
> pnum
>drivers/mtd/ubi/fastmap.c:110:14:got unsigned int
> >> drivers/mtd/ubi/fastmap.c:111:13: sparse: restricted __be32 degrades to
> >> integer
> >> drivers/mtd/ubi/fastmap.c:112:27: sparse: incorrect type in assignment
> >> (different base types) @@expected int [signed] @@got
> >> restricted __be3int [signed] @@
>drivers/mtd/ubi/fastmap.c:112:27:expected int [signed]
>drivers/mtd/ubi/fastmap.c:112:27:got restricted __be32 [usertype] pnum
>drivers/mtd/ubi/fastmap.c:116:13: sparse: restricted __be32 degrades to
> integer
>drivers/mtd/ubi/fastmap.c:116:25: sparse: restricted __be32 degrades to
> integer
>drivers/mtd/ubi/fastmap.c:121:27: sparse: incorrect type in assignment
> (different base types) @@expected int [signed] @@got
> restricted __be3int [signed] @@
>drivers/mtd/ubi/fastmap.c:121:27:expected int [signed]
>drivers/mtd/ubi/fastmap.c:121:27:got restricted __be32 [usertype] pnum
>drivers/mtd/ubi/fastmap.c:604:23: sparse: incorrect type in assignment
> (different base types) @@expected unsigned long long [unsigned] max_sqnum
> @@got nsigned long long [unsigned] max_sqnum @@
>drivers/mtd/ubi/fastmap.c:604:23:expected unsigned long long
> [unsigned] max_sqnum
>drivers/mtd/ubi/fastmap.c:604:23:got restricted __be64 [usertype] sqnum
>drivers/mtd/ubi/fastmap.c:1075:17: sparse: incorrect type in assignment
> (different base types) @@expected restricted __be32 [usertype] tmp_crc @@
>got [usertype] tmp_crc @@
>drivers/mtd/ubi/fastmap.c:1075:17:expected restricted __be32
> [usertype] tmp_crc
>drivers/mtd/ubi/fastmap.c:1075:17:got unsigned int
>drivers/mtd/ubi/fastmap.c:1077:13: sparse: incorrect type in assignment
> (different base types) @@expected restricted __be32 [usertype] crc @@
> got [usertype] crc @@
>drivers/mtd/ubi/fastmap.c:1077:13:expected restricted __be32
> [usertype] crc
>drivers/mtd/ubi/fastmap.c:1077:13:got unsigned int
>drivers/mtd/ubi/fastmap.c:1086:22: sparse: incorrect type in assignment
> (different base types) @@expected restricted __be64 [usertype] sqnum @@
> got unsigned lonrestricted __be64 [usertype] sqnum @@
>drivers/mtd/ubi/fastmap.c:1086:22:expected restricted __be64
> [usertype] sqnum
>drivers/mtd/ubi/fastmap.c:1086:22:got unsigned long long [unsigned]
> [assigned] sqnum
>
> vim +110 drivers/mtd/ubi/fastmap.c
>
>103
>104static bool read_pnum(struct ubi_device *ubi, struct
> ubi_attach_info *ai,
>105 __be32 pnum, int *out_pnum)
>106{
>107int ret = true;
>108int max_pnum = ubi->peb_count;
>109
> > 110pnum = be32_to_cpu(pnum);
> > 111if (pnum == UBI_UNKNOWN) {
> > 112*out_pnum = pnum;
>113goto out;
>114}
Okay, let's use a new variable of type int instead of reusing pnum.
Thanks,
//richard
[tip:perf/urgent] perf stat: Allow to specify specific metric column len
Commit-ID: c1a1f5d9da800dc715d8c1d8a9692c63c70c2955
Gitweb: https://git.kernel.org/tip/c1a1f5d9da800dc715d8c1d8a9692c63c70c2955
Author: Jiri Olsa
AuthorDate: Thu, 7 Jun 2018 00:15:09 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 16:01:44 -0300
perf stat: Allow to specify specific metric column len
The following change will introduce new metrics, that doesn't need such
wide hard coded spacing. Switch METRIC_ONLY_LEN macro usage with
metric_only_len variable.
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20180606221513.11302-7-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 8f3fdc052728..3fc1f5286d50 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -145,6 +145,8 @@ static struct target target = {
typedef int (*aggr_get_id_t)(struct cpu_map *m, int cpu);
+#define METRIC_ONLY_LEN 20
+
static int run_count = 1;
static boolno_inherit = false;
static volatile pid_t child_pid = -1;
@@ -182,6 +184,7 @@ static int print_mixed_hw_group_error;
static u64 *walltime_run;
static boolru_display = false;
static struct rusage ru_data;
+static unsigned intmetric_only_len =
METRIC_ONLY_LEN;
struct perf_stat {
bool record;
@@ -969,8 +972,6 @@ static void print_metric_csv(void *ctx,
fprintf(out, "%s%s%s%s", csv_sep, vals, csv_sep, unit);
}
-#define METRIC_ONLY_LEN 20
-
/* Filter out some columns that don't work well in metrics only mode */
static bool valid_only_metric(const char *unit)
@@ -1002,7 +1003,7 @@ static void print_metric_only(void *ctx, const char
*color, const char *fmt,
struct outstate *os = ctx;
FILE *out = os->fh;
char buf[1024], str[1024];
- unsigned mlen = METRIC_ONLY_LEN;
+ unsigned mlen = metric_only_len;
if (!valid_only_metric(unit))
return;
@@ -1054,7 +1055,7 @@ static void print_metric_header(void *ctx, const char
*color __maybe_unused,
if (csv_output)
fprintf(os->fh, "%s%s", unit, csv_sep);
else
- fprintf(os->fh, "%*s ", METRIC_ONLY_LEN, unit);
+ fprintf(os->fh, "%*s ", metric_only_len, unit);
}
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
[tip:perf/urgent] perf stat: Fix metric column header display alignment
Commit-ID: f515572734fb323aa0efe9ea2c546cd7fee327f7
Gitweb: https://git.kernel.org/tip/f515572734fb323aa0efe9ea2c546cd7fee327f7
Author: Jiri Olsa
AuthorDate: Thu, 7 Jun 2018 00:15:08 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 15:59:13 -0300
perf stat: Fix metric column header display alignment
Make the metric only display aligned.
Before:
# perf stat --topdown -I 1000
# time core cpus retiring bad speculation
frontend bound backend bound
1.000394323 S0-C0 2 37.4% 12.0%
31.4% 19.2%
1.000394323 S0-C1 2 25.1%9.2%
43.8% 21.9%
2.001521204 S0-C0 2 36.4% 11.4%
32.4% 19.8%
2.001521204 S0-C1 2 26.2%9.4%
43.1% 21.3%
3.001930208 S0-C0 2 35.1% 10.7%
33.6% 20.6%
3.001930208 S0-C1 2 28.9% 10.0%
40.0% 21.1%
After:
# perf stat --topdown -I 1000
# time core cpus retiring bad speculation
frontend boundbackend bound
1.000303722 S0-C0 234.2% 7.6%
34.2%24.0%
1.000303722 S0-C1 233.1% 6.4%
36.9%23.6%
2.001281055 S0-C0 234.6% 6.7%
36.8%21.8%
2.001281055 S0-C1 232.8% 7.1%
38.1%22.0%
3.001546080 S0-C0 239.3% 5.5%
32.7%22.5%
3.001546080 S0-C1 237.8% 6.0%
33.1%23.1%
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20180606221513.11302-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9e7b6f108956..8f3fdc052728 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1001,19 +1001,20 @@ static void print_metric_only(void *ctx, const char
*color, const char *fmt,
{
struct outstate *os = ctx;
FILE *out = os->fh;
- int n;
- char buf[1024];
+ char buf[1024], str[1024];
unsigned mlen = METRIC_ONLY_LEN;
if (!valid_only_metric(unit))
return;
unit = fixunit(buf, os->evsel, unit);
- n = color_fprintf(out, color ?: "", fmt, val);
- if (n > METRIC_ONLY_LEN)
- n = METRIC_ONLY_LEN;
if (mlen < strlen(unit))
mlen = strlen(unit) + 1;
- fprintf(out, "%*s", mlen - n, "");
+
+ if (color)
+ mlen += strlen(color) + sizeof(PERF_COLOR_RESET) - 1;
+
+ color_snprintf(str, sizeof(str), color ?: "", fmt, val);
+ fprintf(out, "%*s ", mlen, str);
}
static void print_metric_only_csv(void *ctx, const char *color __maybe_unused,
@@ -1053,7 +1054,7 @@ static void print_metric_header(void *ctx, const char
*color __maybe_unused,
if (csv_output)
fprintf(os->fh, "%s%s", unit, csv_sep);
else
- fprintf(os->fh, "%-*s ", METRIC_ONLY_LEN, unit);
+ fprintf(os->fh, "%*s ", METRIC_ONLY_LEN, unit);
}
static void nsec_printout(int id, int nr, struct perf_evsel *evsel, double avg)
@@ -1721,7 +1722,7 @@ static void print_interval(char *prefix, struct timespec
*ts)
fprintf(output, " counts %*s
events\n", unit_width, "unit");
break;
case AGGR_NONE:
- fprintf(output, "# time CPU");
+ fprintf(output, "# time CPU");
if (!metric_only)
fprintf(output, "counts %*s
events\n", unit_width, "unit");
break;
[tip:perf/urgent] perf stat: Use only color_fprintf call in print_metric_only
Commit-ID: b37d33edbf41b532ddd156707c037c6f4784e40b Gitweb: https://git.kernel.org/tip/b37d33edbf41b532ddd156707c037c6f4784e40b Author: Jiri Olsa AuthorDate: Thu, 7 Jun 2018 00:15:07 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 7 Jun 2018 15:58:13 -0300 perf stat: Use only color_fprintf call in print_metric_only We can call color_fprintf also for non color case, it's handled properly. This change simplifies following patch. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: David Ahern Cc: Frederic Weisbecker Cc: Milian Wolff Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/20180606221513.11302-5-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-stat.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c index f1532e3ac7d7..9e7b6f108956 100644 --- a/tools/perf/builtin-stat.c +++ b/tools/perf/builtin-stat.c @@ -1008,10 +1008,7 @@ static void print_metric_only(void *ctx, const char *color, const char *fmt, if (!valid_only_metric(unit)) return; unit = fixunit(buf, os->evsel, unit); - if (color) - n = color_fprintf(out, color, fmt, val); - else - n = fprintf(out, fmt, val); + n = color_fprintf(out, color ?: "", fmt, val); if (n > METRIC_ONLY_LEN) n = METRIC_ONLY_LEN; if (mlen < strlen(unit))
[tip:perf/urgent] perf tools: Fix error index for pmu event parser
Commit-ID: f7fa827f5f432a0b1f34e10fc49da93aeef9f817
Gitweb: https://git.kernel.org/tip/f7fa827f5f432a0b1f34e10fc49da93aeef9f817
Author: Jiri Olsa
AuthorDate: Thu, 7 Jun 2018 00:15:05 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 15:50:14 -0300
perf tools: Fix error index for pmu event parser
For events we provide specific error message we need to set error column
index, PMU parser is missing that, adding it.
Before:
$ perf stat -e cycles,krava/cycles/ kill
event syntax error: 'cycles,krava/cycles/'
\___ Cannot find PMU `krava'. Missing kernel support?
After:
$ perf stat -e cycles,krava/cycles/ kill
event syntax error: 'cycles,krava/cycles/'
\___ Cannot find PMU `krava'. Missing kernel
support?
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20180606221513.11302-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.y | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 155d2570274f..da8fe57691b8 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -227,11 +227,16 @@ event_def: event_pmu |
event_pmu:
PE_NAME opt_pmu_config
{
+ struct parse_events_state *parse_state = _parse_state;
+ struct parse_events_error *error = parse_state->error;
struct list_head *list, *orig_terms, *terms;
if (parse_events_copy_term_list($2, &orig_terms))
YYABORT;
+ if (error)
+ error->idx = @1.first_column;
+
ALLOC_LIST(list);
if (parse_events_add_pmu(_parse_state, list, $1, $2, false, false)) {
struct perf_pmu *pmu = NULL;
[tip:perf/urgent] perf stat: Add --interval-clear option
Commit-ID: 9660e08ee8cbc94ac835f2c30576c6e51fbece8f
Gitweb: https://git.kernel.org/tip/9660e08ee8cbc94ac835f2c30576c6e51fbece8f
Author: Jiri Olsa
AuthorDate: Thu, 7 Jun 2018 00:15:06 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 15:53:36 -0300
perf stat: Add --interval-clear option
Adding --interval-clear option to clear the screen before next interval.
Committer testing:
# perf stat -I 1000 --interval-clear
And, as expected, it behaves almost like:
# watch -n 0 perf stat -a sleep 1
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20180606221513.11302-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-stat.txt | 3 +++
tools/perf/builtin-stat.c | 11 +--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 5dfe102fb5b5..b10a90b6a718 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -178,6 +178,9 @@ Print count deltas for fixed number of times.
This option should be used together with "-I" option.
example: 'perf stat -I 1000 --interval-count 2 -e cycles -a'
+--interval-clear::
+Clear the screen before next interval.
+
--timeout msecs::
Stop the 'perf stat' session and print count deltas after N milliseconds
(minimum: 10 ms).
This option is not supported with the "-I" option.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 096ccb25c11f..f1532e3ac7d7 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -65,6 +65,7 @@
#include "util/tool.h"
#include "util/string2.h"
#include "util/metricgroup.h"
+#include "util/top.h"
#include "asm/bug.h"
#include
@@ -173,6 +174,7 @@ static struct cpu_map *aggr_map;
static aggr_get_id_t aggr_get_id;
static boolappend_file;
static boolinterval_count;
+static boolinterval_clear;
static const char *output_name;
static int output_fd;
static int print_free_counters_hint;
@@ -1704,9 +1706,12 @@ static void print_interval(char *prefix, struct timespec
*ts)
FILE *output = stat_config.output;
static int num_print_interval;
+ if (interval_clear)
+ puts(CONSOLE_CLEAR);
+
sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, csv_sep);
- if (num_print_interval == 0 && !csv_output) {
+ if ((num_print_interval == 0 && !csv_output) || interval_clear) {
switch (stat_config.aggr_mode) {
case AGGR_SOCKET:
fprintf(output, "# time socket cpus");
@@ -1738,7 +1743,7 @@ static void print_interval(char *prefix, struct timespec
*ts)
}
}
- if (num_print_interval == 0 && metric_only)
+ if ((num_print_interval == 0 && metric_only) || interval_clear)
print_metric_headers(" ", true);
if (++num_print_interval == 25)
num_print_interval = 0;
@@ -2057,6 +2062,8 @@ static const struct option stat_options[] = {
"(overhead is possible for values <= 100ms)"),
OPT_INTEGER(0, "interval-count", &stat_config.times,
"print counts for fixed number of times"),
+ OPT_BOOLEAN(0, "interval-clear", &interval_clear,
+ "clear screen in between new interval"),
OPT_UINTEGER(0, "timeout", &stat_config.timeout,
"stop workload and print counts after a timeout period in
ms (>= 10ms)"),
OPT_SET_UINT(0, "per-socket", &stat_config.aggr_mode,
[tip:perf/urgent] perf hists: Reimplement hists__has_callchains()
Commit-ID: c9d366287042489090da0391318df528bdce9941
Gitweb: https://git.kernel.org/tip/c9d366287042489090da0391318df528bdce9941
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 7 Jun 2018 14:42:27 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 14:42:27 -0300
perf hists: Reimplement hists__has_callchains()
There are places where we have only access to struct hists and need to
know if any of its hist_entries has callchains, like when drawing
headers for the various output modes (stdio, TUI, etc), so, when adding
a new hist_entry, check if it has callchains, storing this info for
later use by hists__has_callchains().
This reimplementation is necessary because not always a 'struct hists'
is allocated together with a 'struct perf evsel', so we can't go from
'hists' to 'perf_event_attr.sample_type & PERF_SAMPLE_CALLCHAIN'.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jin Yao
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-hg5g7yddjio3ljwyqnnaj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/hist.c | 6 --
tools/perf/util/hist.h | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 0441a92b855f..828cb9794c76 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -621,9 +621,11 @@ __hists__add_entry(struct hists *hists,
.raw_data = sample->raw_data,
.raw_size = sample->raw_size,
.ops = ops,
- };
+ }, *he = hists__findnew_entry(hists, &entry, al, sample_self);
- return hists__findnew_entry(hists, &entry, al, sample_self);
+ if (!hists->has_callchains && he && he->callchain_size != 0)
+ hists->has_callchains = true;
+ return he;
}
struct hist_entry *hists__add_entry(struct hists *hists,
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 06607c434949..73049f7f0f60 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -85,6 +85,7 @@ struct hists {
struct events_stats stats;
u64 event_stream;
u16 col_len[HISTC_NR_COLS];
+ boolhas_callchains;
int socket_filter;
struct perf_hpp_list*hpp_list;
struct list_headhpp_formats;
@@ -222,8 +223,7 @@ static inline struct hists *evsel__hists(struct perf_evsel
*evsel)
static __pure inline bool hists__has_callchains(struct hists *hists)
{
- const struct perf_evsel *evsel = hists_to_evsel(hists);
- return evsel__has_callchain(evsel);
+ return hists->has_callchains;
}
int hists__init(void);
Re: [PATCH] infiniband: fix a subtle race condition
On Wed, Jun 13, 2018 at 10:34 PM, Leon Romanovsky wrote: > > Hi Cong, > > If the compiler optimizes the first line (mutex_lock) as you wrote, > it will reuse "f" for the second line (mutex_unlock) too. Nope, check the assembly if you don't trust me, at least my compiler always fetches ctx->file without this patch. I can show you the assembly code tomorrow (too late to access my dev machine now). > > You need to ensure that ucma_modify_id() doesn't run in parallel to > anything that uses "ctx->file" directly and indirectly. > Talk is easy, show me the code. :) I knew there is probably some other race with this code even after my patch, possibly with ->close() for example, but for this specific unlock warning, this patch is sufficient. I can't solve all the races in one patch.
[tip:perf/urgent] perf hists: Make hist_entry__has_callchains() work with 'perf c2c'
Commit-ID: e5654455795f2f89328f7b301dacb6926e57e2b8
Gitweb: https://git.kernel.org/tip/e5654455795f2f89328f7b301dacb6926e57e2b8
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 7 Jun 2018 14:27:19 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 14:27:19 -0300
perf hists: Make hist_entry__has_callchains() work with 'perf c2c'
Since 'perf c2c' uses 'struct hists' not allocated together with a
'struct perf_evsel' instance, we can't go from a 'struct hist_entry'
pointer to a 'struct perf_evsel' via he->hists, so, instead, check if
space was set aside for hist_entry->callchain[0] at hist_entry__new()
time.
Reported-by: Jin Yao
Reported-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Namhyung Kim
Cc: Wang Nan
Fixes: fabd37b837f6 ("perf hists: Check if a hist_entry has callchains before
using them")
Link: https://lkml.kernel.org/n/tip-e8ife8djvvvwmeze3s4yo...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/sort.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 9ab9257ed887..8bf302cafcec 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -155,7 +155,7 @@ struct hist_entry {
static __pure inline bool hist_entry__has_callchains(struct hist_entry *he)
{
- return hists__has_callchains(he->hists);
+ return he->callchain_size != 0;
}
static inline bool hist_entry__has_pairs(struct hist_entry *he)
[tip:perf/urgent] perf hists browser gtk: Use hist_entry__has_callchains()
Commit-ID: 29f9fcdd3f8edccad5809cf939ce921752460fe7
Gitweb: https://git.kernel.org/tip/29f9fcdd3f8edccad5809cf939ce921752460fe7
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 7 Jun 2018 14:33:31 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 14:33:31 -0300
perf hists browser gtk: Use hist_entry__has_callchains()
Since we can't go from struct hists to struct evsel for all cases (c2c
is an exception) and we have access to the hist_entry, use
hist_entry__has_callchains() in the GTK+ hists browser to figure out
if callchains are available.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jin Yao
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-8owkgrruzzi5emvblwh4e...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/gtk/hists.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index b085f1b3e34d..4ab663ec3e5e 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -382,7 +382,7 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists,
gtk_tree_store_set(store, &iter, col_idx++, s, -1);
}
- if (hists__has_callchains(hists) &&
+ if (hist_entry__has_callchains(h) &&
symbol_conf.use_callchain && hists__has(hists, sym)) {
if (callchain_param.mode == CHAIN_GRAPH_REL)
total = symbol_conf.cumulate_callchain ?
Re: [PATCH V6 11/30] block: implement bio_pages_all() via bio_for_each_segment_all()
On Thu, Jun 14, 2018 at 09:23:54AM +0800, Ming Lei wrote: > On Wed, Jun 13, 2018 at 07:44:12AM -0700, Christoph Hellwig wrote: > > Given that we have a single, dubious user of bio_pages_all I'd rather > > see it as an opencoded bio_for_each_ loop in the caller. > > Yeah, that is fine since there is only one user in btrfs. And I suspect it really is checking for the wrong thing. I don't fully understand that code, but as far as I can tell it really needs to know if there is more than a file system block of data in the bio, and btrfs conflats pages with blocks. But I'd need btrfs folks to confirm this.
[tip:perf/urgent] perf hists: Save the callchain_size in struct hist_entry
Commit-ID: 41477acf092251eb0cfe83068f48dbcb2521478a
Gitweb: https://git.kernel.org/tip/41477acf092251eb0cfe83068f48dbcb2521478a
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 7 Jun 2018 14:19:54 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 7 Jun 2018 14:22:53 -0300
perf hists: Save the callchain_size in struct hist_entry
So that we can figure out the real size of the struct and also be able
to tell if callchains may be present in this histogram entry.
Since we can't always guarantee that from hist_entry->hists we can use
hists_to_evsel, to then look at evsel->attr.sample_type for
PERF_SAMPLE_CALLCHAIN, like with the 'perf c2c' tool, that uses plain
'struct hists' instances, we need another way of deciding if a specific
hist_entry instance has callchains associated with it, i.e. if its
hist_entry->callchain[0] has space allocated for.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jin Yao
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-ptvndealxs1k7myluvu9f...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/hist.c | 6 --
tools/perf/util/sort.h | 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 52e8fda93a47..0441a92b855f 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -370,9 +370,11 @@ void hists__delete_entries(struct hists *hists)
static int hist_entry__init(struct hist_entry *he,
struct hist_entry *template,
- bool sample_self)
+ bool sample_self,
+ size_t callchain_size)
{
*he = *template;
+ he->callchain_size = callchain_size;
if (symbol_conf.cumulate_callchain) {
he->stat_acc = malloc(sizeof(he->stat));
@@ -473,7 +475,7 @@ static struct hist_entry *hist_entry__new(struct hist_entry
*template,
he = ops->new(callchain_size);
if (he) {
- err = hist_entry__init(he, template, sample_self);
+ err = hist_entry__init(he, template, sample_self,
callchain_size);
if (err) {
ops->free(he);
he = NULL;
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 7cf2d5cc038e..9ab9257ed887 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -112,6 +112,8 @@ struct hist_entry {
charlevel;
u8 filtered;
+
+ u16 callchain_size;
union {
/*
* Since perf diff only supports the stdio output, TUI
Re: [GIT PULL 00/12] perf/urgent fixes and improvements
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 2696ec4566f598ab483a6bebc4ec841b2efb88ec: > > Merge tag 'perf-core-for-mingo-4.18-20180606' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2018-06-07 07:18:51 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-4.18-20180611 > > for you to fetch changes up to fad76d4333fe73cf3f73704aa34d4ce523b1c458: > > perf script: Show hw-cache events (2018-06-08 13:41:30 -0300) > > > perf/urgent fixes and improvements: > > perf stat: > > . Add --interval-clear option, to provide a 'watch' like printing (Jiri Olsa) > > . Fix metric column header display alignment (Jiri Olsa) > > . Improve error messages for default attributes, providing better output > for error in command lines such as: > > $ perf stat -T > Cannot set up transaction events > event syntax error: > '..cycles,cpu/cycles-t/,cpu/tx-start/,cpu/el-start/,cpu/cycles-ct/}' > \___ unknown term > > Where the "event syntax error" line now appears (Jiri Olsa) > > perf script: > > . Show hw-cache events too (Seeteena Thoufeek) > > perf c2c: > > . Fix data dependency problem in layout of 'struct c2c_hist_entry', where > its member 'struct hist_entry' must be at the end because it has a ZLA > as its last member, that gets space when handling callchains (Jiri Olsa) > > Core: > > - We cannot assume that a 'struct perf_evsel' is to be obtained from a > container_of operation on a 'struct hists' as there are tools, such as > 'perf c2c' that uses 'struct hist' instances without having them in > container structs that also have 'struct perf_evsel' in a particular > layout, so provide a different way of figuring out if a 'struct hists' > and 'struct hist_entry' have callchains (Arnaldo Carvalho de Melo) > > - Fix error index in the PMU event parser, so that error messages can > point to the problematic token (Jiri Olsa) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (4): > perf hists: Save the callchain_size in struct hist_entry > perf hists: Make hist_entry__has_callchains() work with 'perf c2c' > perf hists browser gtk: Use hist_entry__has_callchains() > perf hists: Reimplement hists__has_callchains() > > Jiri Olsa (7): > perf tools: Fix error index for pmu event parser > perf stat: Add --interval-clear option > perf stat: Use only color_fprintf call in print_metric_only > perf stat: Fix metric column header display alignment > perf stat: Allow to specify specific metric column len > perf stat: Add event parsing error handling to add_default_attributes > perf c2c: Keep struct hist_entry at the end of struct c2c_hist_entry > > Seeteena Thoufeek (1): > perf script: Show hw-cache events > > tools/perf/Documentation/perf-stat.txt | 3 +++ > tools/perf/builtin-c2c.c | 10 +++ > tools/perf/builtin-script.c| 12 + > tools/perf/builtin-stat.c | 48 > -- > tools/perf/ui/gtk/hists.c | 2 +- > tools/perf/util/hist.c | 12 ++--- > tools/perf/util/hist.h | 4 +-- > tools/perf/util/parse-events.y | 5 > tools/perf/util/sort.h | 4 ++- > 9 files changed, 67 insertions(+), 33 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
Re: [PATCH] infiniband: fix a subtle race condition
On Wed, Jun 13, 2018 at 04:49:47PM -0700, Cong Wang wrote: > In ucma_event_handler() we lock the mutex like this: > > mutex_lock(&ctx->file->mut); > ... > mutex_unlock(&ctx->file->mut); > > which seems correct, but we could translate it into this: > > f = ctx->file; > mutex_lock(&f->mut); > ... > f = ctx->file; > mutex_unlock(&f->mut); > > as the compiler does. And, because ucma_event_handler() is > called in a workqueue so it could race with ucma_migrate_id(), > so the following race condition could happen: > > CPU0 CPU1 > f = ctx->file; > ucma_lock_files(f, new_file); > ctx->file = new_file > ucma_lock_files(f, new_file); > mutex_lock(&f->mut); // still the old file! > ... > f = ctx->file; // now the new one!! > mutex_unlock(&f->mut); // unlock new file! > > Fix this by reading ctx->file once before mutex_lock(), so we > won't unlock a different mutex any more. Hi Cong, If the compiler optimizes the first line (mutex_lock) as you wrote, it will reuse "f" for the second line (mutex_unlock) too. You need to ensure that ucma_modify_id() doesn't run in parallel to anything that uses "ctx->file" directly and indirectly. Thanks signature.asc Description: PGP signature
[PATCH v4 0/7] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v3:
1. add two uart patches which impacted by this patchset.
2. unlock 'vc.lock' before cyclic dma callback and lock again after
it because some driver such as uart will call dmaengine_tx_status
which will acquire 'vc.lock' again and dead lock comes out.
3. remove 'Revert commit' stuff since that patch is not wrong and
combine two patch into one patch as Sascha's comment.
Change from v2:
1. include Sascha's patch to make the main patch easier to review.
Thanks Sacha.
2. remove useless 'desc'/'chan' in struct sdma_channe.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unnecessary 'pending' list.
Robin Gong (6):
tty: serial: imx: correct dma cookie status
dmaengine: imx-sdma: add virt-dma support
dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
sdma_channel'
dmaengine: imx-sdma: remove the maximum limitation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
tty: serial: imx: split all dma setup operations out of 'port.lock'
protector
Sascha Hauer (1):
dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel
drivers/dma/Kconfig | 1 +
drivers/dma/imx-sdma.c | 394 +++
drivers/tty/serial/imx.c | 99 ++--
3 files changed, 282 insertions(+), 212 deletions(-)
--
2.7.4
[PATCH v4 2/7] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel
From: Sascha Hauer
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 137 ++---
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..556d087 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -296,6 +296,30 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc*desc;
+ struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned intchn_count;
- unsigned intchn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned intirq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* call callback function.
*/
while (1) {
- bd = &sdmac->bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel
[PATCH v4 4/7] dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct sdma_channel'
Since 'sdmac->vc.lock' and 'sdmac->desc' can be used as 'lock' and
'enabled' in 'struct sdma_channel sdmac', remove them.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 719bf9f..27b76eb 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,10 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -613,14 +611,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = &sdma->channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(&sdmac->lock, flags);
}
/*
@@ -738,14 +729,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(&sdmac->lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(&sdmac->lock, flags);
- return;
- }
- spin_unlock_irqrestore(&sdmac->lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1007,15 +990,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(&sdmac->lock, flags);
-
return 0;
}
@@ -1929,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = &sdma->channel[i];
sdmac->sdma = sdma;
- spin_lock_init(&sdmac->lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v4 6/7] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f56226f..e0783a2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
-
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_bd_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v4 3/7] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 261 -
2 files changed, 170 insertions(+), 92 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6d61cd0..78715a2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -257,6 +257,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 556d087..719bf9f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -308,6 +309,7 @@ struct sdma_engine;
* @bd pointer of alloced bd
*/
struct sdma_desc {
+ struct virt_dma_descvd;
unsigned intnum_bd;
dma_addr_t bd_phys;
unsigned intbuf_tail;
@@ -331,8 +333,8 @@ struct sdma_desc {
* @word_size peripheral access size
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
struct sdma_desc*desc;
- struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -347,11 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
};
@@ -705,6 +704,35 @@ static void sdma_event_disable(struct sdma_channel *sdmac,
unsigned int event)
writel_relaxed(val, sdma->regs + chnenbl);
}
+static struct sdma_desc *to_sdma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct sdma_desc, vd.tx);
+}
+
+static void sdma_start_desc(struct sdma_channel *sdmac)
+{
+ struct virt_dma_desc *vd = vchan_next_desc(&sdmac->vc);
+ struct sdma_desc *desc;
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+
+ if (!vd) {
+ sdmac->desc = NULL;
+ return;
+ }
+ sdmac->desc = desc = to_sdma_desc(&vd->tx);
+ /*
+* Do not delete the node in desc_issued list in cyclic mode, otherwise
+* the desc alloced will never be freed in vchan_dma_desc_free_list
+*/
+ if (!(sdmac->flags & IMX_DMA_SG_LOOP))
+ list_del(&vd->node);
+
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
+ sdma_enable_channel(sdma, sdmac->channel);
+}
+
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
@@ -723,7 +751,7 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (1) {
+ while (sdmac->desc) {
struct sdma_desc *desc = sdmac->desc;
bd = &desc->bd[desc->buf_tail];
@@ -754,15 +782,16 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* SDMA transaction status by the time the client tasklet is
* executed.
*/
-
- dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
+
[PATCH v4 5/7] dmaengine: imx-sdma: remove the maximum limitation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 27b76eb..f56226f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[PATCH v4 7/7] tty: serial: imx: split all dma setup operations out of 'port.lock' protector
After sdma driver change to virt-dma, all bds will be allocated
dynamically with 'port.lock' acquired instead of statically allocated
before. That means the lock sequence is 'port.lock' -> 'fs_reclaim_acquire'
.But in case uart rx/tx dma callback coming after other kernel code which
have already acquired 'fs_reclaim_acquire' lock, which means the above lock
sequence reverted as 'fs_reclaim_acquire' -> 'port.lock'(acquired in uart
dma callback), thus, lockdep warning comes as beow. Actually don't need to
spinlock all DMA operations in UART driver with 'port.lock', because dma
driver can wipe off race condition by commone virt-dma lock . Split all dma
operations out of the code areas which protected by 'port.lock'.
[ 46.155406] =
[ 46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 46.168122] 4.17.0-rc6-8-g7caafa3-dirty #48 Not tainted
[ 46.173696] -
[ 46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[ 46.194270]
[ 46.194270] and this task is already holding:
[ 46.200106] 09a17fda (&port_lock_key){-.-.}, at: uart_write+0x84/0x190
[ 46.206658] which would create a new lock dependency:
[ 46.211710] (&port_lock_key){-.-.} -> (fs_reclaim){+.+.}
[ 46.217132]
[ 46.217132] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 46.225051] (&port_lock_key){-.-.}
[ 46.225062]
[ 46.225062] ... which became HARDIRQ-irq-safe at:
[ 46.234740] lock_acquire+0x70/0x90
[ 46.238326] _raw_spin_lock_irqsave+0x40/0x54
[ 46.242777] imx_uart_console_write+0x1bc/0x1e0
[ 46.247402] console_unlock+0x320/0x5f0
[ 46.251329] vprintk_emit+0x22c/0x3fc
[ 46.255082] vprintk_default+0x28/0x30
[ 46.258923] vprintk_func+0x78/0xcc
[ 46.262503] printk+0x34/0x54
[ 46.265566] crng_fast_load+0xf8/0x138
[ 46.269407] add_interrupt_randomness+0x21c/0x24c
[ 46.274204] handle_irq_event_percpu+0x40/0x84
[ 46.278739] handle_irq_event+0x40/0x64
[ 46.282667] handle_fasteoi_irq+0xbc/0x178
[ 46.286854] generic_handle_irq+0x28/0x3c
[ 46.290954] __handle_domain_irq+0x6c/0xe8
[ 46.295148] gic_handle_irq+0x64/0xc4
[ 46.298904] __irq_svc+0x70/0x98
[ 46.302225] _raw_spin_unlock_irq+0x30/0x34
[ 46.306505] finish_task_switch+0xc0/0x27c
[ 46.310693] __schedule+0x2c0/0x79c
[ 46.314272] schedule_idle+0x40/0x84
[ 46.317941] do_idle+0x178/0x2b4
[ 46.321259] cpu_startup_entry+0x20/0x24
[ 46.325278] rest_init+0x214/0x264
[ 46.328775] start_kernel+0x39c/0x424
[ 46.332527] (null)
[ 46.334891]
[ 46.334891] to a HARDIRQ-irq-unsafe lock:
[ 46.340379] (fs_reclaim){+.+.}
[ 46.340391]
[ 46.340391] ... which became HARDIRQ-irq-unsafe at:
[ 46.349885] ...
[ 46.349895] lock_acquire+0x70/0x90
[ 46.355225] fs_reclaim_acquire.part.3+0x38/0x48
[ 46.359933] fs_reclaim_acquire+0x1c/0x20
[ 46.364036] kmem_cache_alloc+0x2c/0x174
[ 46.368051] alloc_worker.constprop.10+0x1c/0x58
[ 46.372759] init_rescuer.part.4+0x18/0xa4
[ 46.376952] workqueue_init+0xc0/0x210
[ 46.380793] kernel_init_freeable+0x58/0x1d8
[ 46.385156] kernel_init+0x10/0x11c
[ 46.388736] ret_from_fork+0x14/0x20
[ 46.392399] (null)
[ 46.394762]
[ 46.394762] other info that might help us debug this:
[ 46.394762]
[ 46.402769] Possible interrupt unsafe locking scenario:
[ 46.402769]
[ 46.409560]CPU0CPU1
[ 46.414092]
[ 46.418622] lock(fs_reclaim);
[ 46.421772]local_irq_disable();
[ 46.427693]lock(&port_lock_key);
[ 46.433707]lock(fs_reclaim);
[ 46.439372]
[ 46.441993] lock(&port_lock_key);
[ 46.445661]
[ 46.445661] *** DEADLOCK ***
[ 46.445661]
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 97 ++--
1 file changed, 53 insertions(+), 44 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index b83bc2c..f2a2966 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -223,6 +223,7 @@ struct imx_port {
dma_cookie_trx_cookie;
unsigned inttx_bytes;
unsigned intdma_tx_nents;
+ struct work_struct tsk_dma_tx;
unsigned intsaved_reg[10];
boolcontext_saved;
};
@@ -491,8 +492,6 @@ static void imx_uart_enable_ms(struct uart_port *port)
mctrl_gpio_enable_ms(sport->gpios);
}
-static void imx_uart_dma_tx(struct imx_port *sport);
-
/* called with port.lock taken and irqs off */
static inline void imx_uart_transmit_buffer(struct imx_port *sport)
{
@@ -524,7 +523,7 @@ static inline void imx_
[PATCH v4 1/7] tty: serial: imx: correct dma cookie status
Correct to check the right rx dma cookie status in spit of it
works because only one cookie is running in the current sdma.
But it will not once sdma driver support multi cookies
running based on virt-dma.
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index c2fc6be..b83bc2c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1051,7 +1051,7 @@ static void imx_uart_dma_rx_callback(void *data)
unsigned int r_bytes;
unsigned int bd_size;
- status = dmaengine_tx_status(chan, (dma_cookie_t)0, &state);
+ status = dmaengine_tx_status(chan, sport->rx_cookie, &state);
if (status == DMA_ERROR) {
imx_uart_clear_rx_errors(sport);
--
2.7.4
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
at 10:50 PM, Greg Kroah-Hartman wrote:
> On Thu, Jun 14, 2018 at 05:41:01AM +, Nadav Amit wrote:
>> at 10:23 PM, Greg Kroah-Hartman wrote:
>>
>>> On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest
frame number (GFN) must fit in 32-bit. However, due to a bug, this check
was mistakenly ignored. In practice, when total RAM is greater than
16TB, the balloon does not work currently, making this bug unlikely to
happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline
vmballoon_reserve_page.")
Cc: sta...@vger.kernel.org
>>>
>>> Again, no blank line between these things.
>>>
>>> Also, please break this up into two different patch series. One for
>>> 4.18-final and one for 4.19-rc1. You should always split up bugfixes
>>> from new features/cleanups as that is what I have to do when sending
>>> them to Linus.
>>
>> I have only sent what I thought is appropriate for 4.18 (cleanup/features
>> will be sent separately):
>>
>> * 5 bug fixes (1-5/7)
>> * 1 update the maintainer list (7/7)
>> * 1 update to the comment to prevent checkpatch from complaining (6/7)
>>
>> If you think any patch is unsuitable to 4.18 - please say which.
>
> How do I know which patch goes to which branch? Please make it so
> obvious I can not get it wrong. Remember, I get 1000 emails a day, you
> don't want me to have to make a judgement call about anything, as I will
> mess it up :)
I appreciate your time, and understand you even need to read students’
dissertations. ;-)
I will write it clearly in the cover-letter in the next version, and move
the license changes to 4.19.
Thanks,
Nadav
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
On Thu, Jun 14, 2018 at 05:41:01AM +, Nadav Amit wrote:
> at 10:23 PM, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
> >> When balloon batching is not supported by the hypervisor, the guest
> >> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
> >> was mistakenly ignored. In practice, when total RAM is greater than
> >> 16TB, the balloon does not work currently, making this bug unlikely to
> >> happen.
> >>
> >> Fixes: ef0f8f112984 ("VMware balloon: partially inline
> >> vmballoon_reserve_page.")
> >>
> >> Cc: sta...@vger.kernel.org
> >
> > Again, no blank line between these things.
> >
> > Also, please break this up into two different patch series. One for
> > 4.18-final and one for 4.19-rc1. You should always split up bugfixes
> > from new features/cleanups as that is what I have to do when sending
> > them to Linus.
>
> I have only sent what I thought is appropriate for 4.18 (cleanup/features
> will be sent separately):
>
> * 5 bug fixes (1-5/7)
> * 1 update the maintainer list (7/7)
> * 1 update to the comment to prevent checkpatch from complaining (6/7)
>
> If you think any patch is unsuitable to 4.18 - please say which.
How do I know which patch goes to which branch? Please make it so
obvious I can not get it wrong. Remember, I get 1000 emails a day, you
don't want me to have to make a judgement call about anything, as I will
mess it up :)
thanks,
greg k-h
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
On Thu, Jun 14, 2018 at 05:33:46AM +, Nadav Amit wrote:
> at 10:24 PM, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote:
> >> Removing the paragraph about writing to the Free Software Foundation's
> >> mailing address from the sample GPL notice according to checkpatch
> >> request.
> >>
> >> In addition, updating the year and adding a license tag.
> >>
> >> Reviewed-by: Xavier Deguillard
> >> Signed-off-by: Nadav Amit
> >> ---
> >> drivers/misc/vmw_balloon.c | 7 ++-
> >> 1 file changed, 2 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> >> index 400a1ccefc8e..b982059ce7b7 100644
> >> --- a/drivers/misc/vmw_balloon.c
> >> +++ b/drivers/misc/vmw_balloon.c
> >> @@ -1,7 +1,8 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> /*
> >> * VMware Balloon driver.
> >> *
> >> - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved.
> >> + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved.
> >> *
> >> * This program is free software; you can redistribute it and/or modify it
> >> * under the terms of the GNU General Public License as published by the
> >> @@ -13,10 +14,6 @@
> >> * NON INFRINGEMENT. See the GNU General Public License for more
> >> * details.
> >
> > You still have a lot of boiler-plate text in here that can be removed.
> > Please do so.
>
> I will remove the maintainers, since it is really unsuitable.
>
> But what else do you want me to remove? This is a standard GPL license. If I
> am required to remove the GPL license, I will have to run checks to ensure
> it is appropriate.
Yes, all of the license text should be removed. Right now we have 700+
differnt wordings of "This file is released under the GPL" in the kernel
tree, and we need to clean that up. Look at all of the other SPDX
cleanups we have done already to get an idea of what is needed here.
As one example, look at 0c3b34a569f8 ("USB: typec: Remove remaining
redundant license text") which can be done after the correct SPDX line
is in the file. That's the end-goal for all kernel files.
thanks,
greg k-h
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
at 10:23 PM, Greg Kroah-Hartman wrote:
> On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
>> When balloon batching is not supported by the hypervisor, the guest
>> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
>> was mistakenly ignored. In practice, when total RAM is greater than
>> 16TB, the balloon does not work currently, making this bug unlikely to
>> happen.
>>
>> Fixes: ef0f8f112984 ("VMware balloon: partially inline
>> vmballoon_reserve_page.")
>>
>> Cc: sta...@vger.kernel.org
>
> Again, no blank line between these things.
>
> Also, please break this up into two different patch series. One for
> 4.18-final and one for 4.19-rc1. You should always split up bugfixes
> from new features/cleanups as that is what I have to do when sending
> them to Linus.
I have only sent what I thought is appropriate for 4.18 (cleanup/features
will be sent separately):
* 5 bug fixes (1-5/7)
* 1 update the maintainer list (7/7)
* 1 update to the comment to prevent checkpatch from complaining (6/7)
If you think any patch is unsuitable to 4.18 - please say which.
Thanks,
Nadav
Re: [PATCH] Staging: octeon-usb: octeon-hcd.c: Remove boiler plate and add SPDX
On Wed, Jun 13, 2018 at 05:28:25PM -0400, Javier Martinez wrote: > Removed massive boiler plate text at top of the file and instead > replaced it with a simple SPDX license identifier. > > Signed-off-by: Javier Martinez > --- > drivers/staging/octeon-usb/octeon-hcd.c | 47 ++--- > 1 file changed, 2 insertions(+), 45 deletions(-) > > diff --git a/drivers/staging/octeon-usb/octeon-hcd.c > b/drivers/staging/octeon-usb/octeon-hcd.c > index cded30f145aa..df61e8321140 100644 > --- a/drivers/staging/octeon-usb/octeon-hcd.c > +++ b/drivers/staging/octeon-usb/octeon-hcd.c > @@ -1,48 +1,5 @@ > -/* > - * This file is subject to the terms and conditions of the GNU General Public > - * License. See the file "COPYING" in the main directory of this archive > - * for more details. > - * > - * Copyright (C) 2008 Cavium Networks > - * > - * Some parts of the code were originally released under BSD license: > - * > - * Copyright (c) 2003-2010 Cavium Networks (supp...@cavium.com). All rights > - * reserved. > - * > - * Redistribution and use in source and binary forms, with or without > - * modification, are permitted provided that the following conditions are > - * met: > - * > - * * Redistributions of source code must retain the above copyright > - * notice, this list of conditions and the following disclaimer. > - * > - * * Redistributions in binary form must reproduce the above > - * copyright notice, this list of conditions and the following > - * disclaimer in the documentation and/or other materials provided > - * with the distribution. > - * > - * * Neither the name of Cavium Networks nor the names of > - * its contributors may be used to endorse or promote products > - * derived from this software without specific prior written > - * permission. > - * > - * This Software, including technical data, may be subject to U.S. export > - * control laws, including the U.S. Export Administration Act and its > associated > - * regulations, and may be subject to export or import regulations in other > - * countries. > - * > - * TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE SOFTWARE IS PROVIDED "AS IS" > - * AND WITH ALL FAULTS AND CAVIUM NETWORKS MAKES NO PROMISES, > REPRESENTATIONS OR > - * WARRANTIES, EITHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, WITH > RESPECT TO > - * THE SOFTWARE, INCLUDING ITS CONDITION, ITS CONFORMITY TO ANY > REPRESENTATION > - * OR DESCRIPTION, OR THE EXISTENCE OF ANY LATENT OR PATENT DEFECTS, AND > CAVIUM > - * SPECIFICALLY DISCLAIMS ALL IMPLIED (IF ANY) WARRANTIES OF TITLE, > - * MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, LACK > OF > - * VIRUSES, ACCURACY OR COMPLETENESS, QUIET ENJOYMENT, QUIET POSSESSION OR > - * CORRESPONDENCE TO DESCRIPTION. THE ENTIRE RISK ARISING OUT OF USE OR > - * PERFORMANCE OF THE SOFTWARE LIES WITH YOU. > - */ > +// SPDX-License-Identifier: GNU GPL That is not a valid identifier, please read the documentation for how to do this properly. Also, and more importantly, you picked the wrong one. Do NOT mess with license texts if you don't know what you are doing... greg k-h
Re: [PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
2018-06-14 14:27 GMT+09:00 Masahiro Yamada :
> If a GPIO chip is a part of a hierarchy IRQ domain, there is no
> way to specify the trigger type when gpio(d)_to_irq() allocates an
> interrupt on-the-fly.
>
> Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
> an error in the .alloc() hook of the parent domain.
> (drivers/irq/irq-uniphier-aidet.c)
>
> Even if we change irq-uniphier-aidet.c to accept the NONE type,
> GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
> Loudly complain about the use of IRQ_TYPE_NONE").
>
> Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
> is allocated. irq_set_irq_type() will override it when the irq is
> really requested.
>
> Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
> Reported-by: Katsuhiro Suzuki
> Signed-off-by: Masahiro Yamada
> Tested-by: Katsuhiro Suzuki
> ---
BTW, gpio-xgene-sb.c is also suspicious.
https://github.com/torvalds/linux/blob/v4.17/drivers/gpio/gpio-xgene-sb.c#L136
I do not have that hardware, but GIC will complain about NONE type
if gpio(d)_to_irq() is used.
Commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
only mentions DT cases.
It is unclear how to take care of GPIO-originated IRQs.
> drivers/gpio/gpio-uniphier.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
> index d3cf950..58faeb1 100644
> --- a/drivers/gpio/gpio-uniphier.c
> +++ b/drivers/gpio/gpio-uniphier.c
> @@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip,
> unsigned int offset)
> fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
> fwspec.param_count = 2;
> fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
> - fwspec.param[1] = IRQ_TYPE_NONE;
> + /*
> +* IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
> +* temporarily. Anyway, ->irq_set_type() will override it later.
> +*/
> + fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
>
> return irq_create_fwspec_mapping(&fwspec);
> }
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] selftests: vm: return Kselftest Skip code for skipped tests
On Wed, Jun 13, 2018 at 09:35:57PM -0600, Shuah Khan (Samsung OSG) wrote:
> When vm test is skipped because of unmet dependencies and/or unsupported
> configuration, it exits with error which is treated as a fail by the
> Kselftest framework. This leads to false negative result even when the
> test could not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
>
> Signed-off-by: Shuah Khan (Samsung OSG)
For the userfaultfd test
Acked-by: Mike Rapoport
> ---
> tools/testing/selftests/vm/compaction_test.c | 4 +++-
> tools/testing/selftests/vm/mlock2-tests.c| 12 +++-
> tools/testing/selftests/vm/run_vmtests | 5 -
> tools/testing/selftests/vm/userfaultfd.c | 4 +++-
> 4 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/selftests/vm/compaction_test.c
> b/tools/testing/selftests/vm/compaction_test.c
> index 1097f04e4d80..bcec71250873 100644
> --- a/tools/testing/selftests/vm/compaction_test.c
> +++ b/tools/testing/selftests/vm/compaction_test.c
> @@ -16,6 +16,8 @@
> #include
> #include
>
> +#include "../kselftest.h"
> +
> #define MAP_SIZE 1048576
>
> struct map_list {
> @@ -169,7 +171,7 @@ int main(int argc, char **argv)
> printf("Either the sysctl compact_unevictable_allowed is not\n"
> "set to 1 or couldn't read the proc file.\n"
> "Skipping the test\n");
> - return 0;
> + return KSFT_SKIP;
> }
>
> lim.rlim_cur = RLIM_INFINITY;
> diff --git a/tools/testing/selftests/vm/mlock2-tests.c
> b/tools/testing/selftests/vm/mlock2-tests.c
> index 4997b9222cfa..637b6d0ac0d0 100644
> --- a/tools/testing/selftests/vm/mlock2-tests.c
> +++ b/tools/testing/selftests/vm/mlock2-tests.c
> @@ -9,6 +9,8 @@
> #include
> #include "mlock2.h"
>
> +#include "../kselftest.h"
> +
> struct vm_boundaries {
> unsigned long start;
> unsigned long end;
> @@ -303,7 +305,7 @@ static int test_mlock_lock()
> if (mlock2_(map, 2 * page_size, 0)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(0)");
> goto unmap;
> @@ -412,7 +414,7 @@ static int test_mlock_onfault()
> if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(MLOCK_ONFAULT)");
> goto unmap;
> @@ -425,7 +427,7 @@ static int test_mlock_onfault()
> if (munlock(map, 2 * page_size)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("munlock()");
> goto unmap;
> @@ -457,7 +459,7 @@ static int test_lock_onfault_of_present()
> if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(MLOCK_ONFAULT)");
> goto unmap;
> @@ -583,7 +585,7 @@ static int test_vma_management(bool call_mlock)
> if (call_mlock && mlock2_(map, 3 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock(ONFAULT)\n");
> goto out;
> diff --git a/tools/testing/selftests/vm/run_vmtests
> b/tools/testing/selftests/vm/run_vmtests
> index 22d564673830..88cbe5575f0c 100755
> --- a/tools/testing/selftests/vm/run_vmtests
> +++ b/tools/testing/selftests/vm/run_vmtests
> @@ -2,6 +2,9 @@
> # SPDX-License-Identifier: GPL-2.0
> #please run as root
>
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
> mnt=./huge
> exitcode=0
>
> @@ -36,7 +39,7 @@ if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
> echo $(( $lackpgs + $nr_hugepgs )) > /proc/sys/vm/nr_hugepages
> if [ $? -ne 0 ]; then
> echo "Please run this test as root"
> - exit 1
> + exit $ksft_skip
> fi
> while read name size unit; do
> if [ "$name" = "HugePages_Free:" ]; t
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Thu, Jun 14, 2018 at 05:16:18AM +, Naoya Horiguchi wrote:
> On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> > On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> > [...]
> > > From: Naoya Horiguchi
> > > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > > Subject: [PATCH] mm: zero remaining unavailable struct pages
> > >
> > > There is a kernel panic that is triggered when reading /proc/kpageflags
> > > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> > >
> > > BUG: unable to handle kernel paging request at fffe
> > > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > > Oops: [#1] SMP PTI
> > > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > > 1.11.0-2.fc28 04/01/2014
> > > RIP: 0010:stable_page_flags+0x27/0x3c0
> > > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > > RAX: fffe RBX: 7fffeff9 RCX:
> > > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > > RBP: R08: 0001 R09: 0001
> > > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > > FS: 7efc4335a500() GS:93a5bfc0()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > > Call Trace:
> > >kpageflags_read+0xc7/0x120
> > >proc_reg_read+0x3c/0x60
> > >__vfs_read+0x36/0x170
> > >vfs_read+0x89/0x130
> > >ksys_pread64+0x71/0x90
> > >do_syscall_64+0x5b/0x160
> > >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7efc42e75e23
> > > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> > >
> > > According to kernel bisection, this problem became visible due to commit
> > > f7f99100d8d9 which changes how struct pages are initialized.
> > >
> > > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > > the default (no memmap= given) memblock layout is like below:
> > >
> > > MEMBLOCK configuration:
> > >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> > >memory.cnt = 0x4
> > >memory[0x0] [0x1000-0x0009efff],
> > > 0x0009e000 bytes on node 0 flags: 0x0
> > >memory[0x1] [0x0010-0xbffd6fff],
> > > 0xbfed7000 bytes on node 0 flags: 0x0
> > >memory[0x2] [0x0001-0x00013fff],
> > > 0x4000 bytes on node 0 flags: 0x0
> > >memory[0x3] [0x00014000-0x00023fff],
> > > 0x0001 bytes on node 1 flags: 0x0
> > >...
> > >
> > > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > > the range [0x1-0x13fff] is gone:
> > >
> > > MEMBLOCK configuration:
> > >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> > >memory.cnt = 0x3
> > >memory[0x0] [0x1000-0x0009efff],
> > > 0x0009e000 bytes on node 0 flags: 0x0
> > >memory[0x1] [0x0010-0xbffd6fff],
> > > 0xbfed7000 bytes on node 0 flags: 0x0
> > >memory[0x2] [0x00014000-0x00023fff],
> > > 0x0001 bytes on node 1 flags: 0x0
> > >...
> > >
> > > This causes shrinking node 0's pfn range because it is calculated by
> > > the address range of memblock.memory. So some of struct pages in the
> > > gap range are left uninitialized.
> > >
> > > We have a function zero_resv_unavail() which does zeroing the struct
> > > pages outside memblock.memory, but currently it covers only the reserved
> > > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > > This patch extends it to cover all unavailable range, which fixes
> > > the reported issue.
> >
> > Thanks for pin pointing this down Naoya! I am wondering why we cannot
> > simply mark the excluded ranges to be reserved instead.
>
> I tried your idea with the change below, and it also fixes the kernel panic.
>
> ---
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index d1f25c831447..2cef120535d4 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -1248,6 +1248,7 @@ void __init e820__memblock_setup(void)
> {
> int i;
> u64 end;
> + u64 addr = 0;
>
RE: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
Ping for RFC
> -Original Message-
> From: Manish Narani [mailto:manish.nar...@xilinx.com]
> Sent: Thursday, June 7, 2018 5:42 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; m...@kernel.org; stefan.krsmano...@aggios.com;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@vger.kernel.org; devicet...@vger.kernel.org;
> adrian.hun...@intel.com; michal.si...@xilinx.com; ulf.hans...@linaro.org
> Cc: Manish Narani
> Subject: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values
> from DT
>
> This patch adds support for reading Tap Delay values from Device Tree and
> write them via eemi calls. The macros containing these tap delay values are
> removed from the driver.
>
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 131
> +
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
> of-arasan.c
> index e3332a5..fc0fd01 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -36,6 +36,8 @@
>
> #define PHY_CLK_TOO_SLOW_HZ 40
>
> +#define MMC_BANK20x2
> +
> /*
> * On some SoCs the syscon area has a feature where the upper 16-bits of
> * each 32-bit register act as a write mask for the lower 16-bits. This
> allows
> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
> struct sdhci_host *host;
> struct clk *clk_ahb;
> struct phy *phy;
> + u32 mio_bank;
> + u32 device_id;
> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
> boolis_phy_on;
>
> boolhas_cqe;
> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
> sdhci_host *host,
> return ret;
> }
>
> +/**
> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
> + * @deviceid:Unique Id of device
> + * @itap_delay: Input Tap Delay
> + * @oitap_delay: Output Tap Delay
> + */
> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
> +otap_delay) {
> + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
> +
> + if (!eemi_ops || !eemi_ops->ioctl)
> + return;
> +
> + if (itap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_INPUT, itap_delay, NULL);
> +
> + if (otap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
> }
> +
> static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int
> clock) {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> bool ctrl_phy = false;
> + u8 itap_delay;
> + u8 otap_delay;
>
> if (!IS_ERR(sdhci_arasan->phy)) {
> if (!sdhci_arasan->is_phy_on && clock <=
> PHY_CLK_TOO_SLOW_HZ) { @@ -200,6 +231,16 @@ static void
> sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
> }
> }
>
> + if (host->version >= SDHCI_SPEC_300) {
> + if ((host->timing != MMC_TIMING_LEGACY) &&
> + (host->timing != MMC_TIMING_UHS_SDR12)) {
> + itap_delay = sdhci_arasan->itapdly[host->timing];
> + otap_delay = sdhci_arasan->otapdly[host->timing];
> + arasan_zynqmp_set_tap_delay(sdhci_arasan-
> >device_id,
> + itap_delay, otap_delay);
> + }
> + }
> +
> if (ctrl_phy && sdhci_arasan->is_phy_on) {
> phy_power_off(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = false;
> @@ -456,6 +497,7 @@ static const struct of_device_id
> sdhci_arasan_of_match[] = {
> { .compatible = "arasan,sdhci-8.9a" },
> { .compatible = "arasan,sdhci-5.1" },
> { .compatible = "arasan,sdhci-4.9a" },
> + { .compatible = "xlnx,zynqmp-8.9a" },
>
> { /* sentinel */ }
> };
> @@ -641,6 +683,74 @@ static void sdhci_arasan_unregister_sdclk(struct
> device *dev)
> of_clk_del_provider(dev->of_node);
> }
>
> +/**
> + * arasan_zynqmp_dt_parse_tap_delays - Read Tap Delay values from DT
> + *
> + * Called at initialization to parse the values of Tap Delays.
> + *
> + * @dev: Pointer to our struct device.
> + */
> +static void arasan_zynqmp_dt_parse_tap_delays(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> + st
[PATCH v4 4/7] dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct sdma_channel'
Since 'sdmac->vc.lock' and 'sdmac->desc' can be used as 'lock' and
'enabled' in 'struct sdma_channel sdmac', remove them.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 719bf9f..27b76eb 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,10 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -613,14 +611,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = &sdma->channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(&sdmac->lock, flags);
}
/*
@@ -738,14 +729,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(&sdmac->lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(&sdmac->lock, flags);
- return;
- }
- spin_unlock_irqrestore(&sdmac->lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1007,15 +990,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(&sdmac->lock, flags);
-
return 0;
}
@@ -1929,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = &sdma->channel[i];
sdmac->sdma = sdma;
- spin_lock_init(&sdmac->lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v4 3/7] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 261 -
2 files changed, 170 insertions(+), 92 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6d61cd0..78715a2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -257,6 +257,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 556d087..719bf9f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -308,6 +309,7 @@ struct sdma_engine;
* @bd pointer of alloced bd
*/
struct sdma_desc {
+ struct virt_dma_descvd;
unsigned intnum_bd;
dma_addr_t bd_phys;
unsigned intbuf_tail;
@@ -331,8 +333,8 @@ struct sdma_desc {
* @word_size peripheral access size
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
struct sdma_desc*desc;
- struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -347,11 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
};
@@ -705,6 +704,35 @@ static void sdma_event_disable(struct sdma_channel *sdmac,
unsigned int event)
writel_relaxed(val, sdma->regs + chnenbl);
}
+static struct sdma_desc *to_sdma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct sdma_desc, vd.tx);
+}
+
+static void sdma_start_desc(struct sdma_channel *sdmac)
+{
+ struct virt_dma_desc *vd = vchan_next_desc(&sdmac->vc);
+ struct sdma_desc *desc;
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+
+ if (!vd) {
+ sdmac->desc = NULL;
+ return;
+ }
+ sdmac->desc = desc = to_sdma_desc(&vd->tx);
+ /*
+* Do not delete the node in desc_issued list in cyclic mode, otherwise
+* the desc alloced will never be freed in vchan_dma_desc_free_list
+*/
+ if (!(sdmac->flags & IMX_DMA_SG_LOOP))
+ list_del(&vd->node);
+
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
+ sdma_enable_channel(sdma, sdmac->channel);
+}
+
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
@@ -723,7 +751,7 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (1) {
+ while (sdmac->desc) {
struct sdma_desc *desc = sdmac->desc;
bd = &desc->bd[desc->buf_tail];
@@ -754,15 +782,16 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* SDMA transaction status by the time the client tasklet is
* executed.
*/
-
- dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
+
[PATCH v4 6/7] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f56226f..e0783a2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
-
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_bd_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v4 0/7] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v3:
1. add two uart patches which impacted by this patchset.
2. unlock 'vc.lock' before cyclic dma callback and lock again after
it because some driver such as uart will call dmaengine_tx_status
which will acquire 'vc.lock' again and dead lock comes out.
3. remove 'Revert commit' stuff since that patch is not wrong and
combine two patch into one patch as Sascha's comment.
Change from v2:
1. include Sascha's patch to make the main patch easier to review.
Thanks Sacha.
2. remove useless 'desc'/'chan' in struct sdma_channe.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unnecessary 'pending' list.
Robin Gong (6):
tty: serial: imx: correct dma cookie status
dmaengine: imx-sdma: add virt-dma support
dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
sdma_channel'
dmaengine: imx-sdma: remove the maximum limitation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
tty: serial: imx: split all dma setup operations out of 'port.lock'
protector
Sascha Hauer (1):
dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel
drivers/dma/Kconfig | 1 +
drivers/dma/imx-sdma.c | 394 +++
drivers/tty/serial/imx.c | 99 ++--
3 files changed, 282 insertions(+), 212 deletions(-)
--
2.7.4
[PATCH v4 2/7] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel
From: Sascha Hauer
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 137 ++---
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..556d087 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -296,6 +296,30 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc*desc;
+ struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned intchn_count;
- unsigned intchn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned intirq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* call callback function.
*/
while (1) {
- bd = &sdmac->bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel
[PATCH v4 1/7] tty: serial: imx: correct dma cookie status
Correct to check the right rx dma cookie status in spit of it
works because only one cookie is running in the current sdma.
But it will not once sdma driver support multi cookies
running based on virt-dma.
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index c2fc6be..b83bc2c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1051,7 +1051,7 @@ static void imx_uart_dma_rx_callback(void *data)
unsigned int r_bytes;
unsigned int bd_size;
- status = dmaengine_tx_status(chan, (dma_cookie_t)0, &state);
+ status = dmaengine_tx_status(chan, sport->rx_cookie, &state);
if (status == DMA_ERROR) {
imx_uart_clear_rx_errors(sport);
--
2.7.4
[PATCH v4 5/7] dmaengine: imx-sdma: remove the maximum limitation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 27b76eb..f56226f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[PATCH v4 7/7] tty: serial: imx: split all dma setup operations out of 'port.lock' protector
After sdma driver change to virt-dma, all bds will be allocated
dynamically with 'port.lock' acquired instead of statically allocated
before. That means the lock sequence is 'port.lock' -> 'fs_reclaim_acquire'
.But in case uart rx/tx dma callback coming after other kernel code which
have already acquired 'fs_reclaim_acquire' lock, which means the above lock
sequence reverted as 'fs_reclaim_acquire' -> 'port.lock'(acquired in uart
dma callback), thus, lockdep warning comes as beow. Actually don't need to
spinlock all DMA operations in UART driver with 'port.lock', because dma
driver can wipe off race condition by commone virt-dma lock . Split all dma
operations out of the code areas which protected by 'port.lock'.
[ 46.155406] =
[ 46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 46.168122] 4.17.0-rc6-8-g7caafa3-dirty #48 Not tainted
[ 46.173696] -
[ 46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[ 46.194270]
[ 46.194270] and this task is already holding:
[ 46.200106] 09a17fda (&port_lock_key){-.-.}, at: uart_write+0x84/0x190
[ 46.206658] which would create a new lock dependency:
[ 46.211710] (&port_lock_key){-.-.} -> (fs_reclaim){+.+.}
[ 46.217132]
[ 46.217132] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 46.225051] (&port_lock_key){-.-.}
[ 46.225062]
[ 46.225062] ... which became HARDIRQ-irq-safe at:
[ 46.234740] lock_acquire+0x70/0x90
[ 46.238326] _raw_spin_lock_irqsave+0x40/0x54
[ 46.242777] imx_uart_console_write+0x1bc/0x1e0
[ 46.247402] console_unlock+0x320/0x5f0
[ 46.251329] vprintk_emit+0x22c/0x3fc
[ 46.255082] vprintk_default+0x28/0x30
[ 46.258923] vprintk_func+0x78/0xcc
[ 46.262503] printk+0x34/0x54
[ 46.265566] crng_fast_load+0xf8/0x138
[ 46.269407] add_interrupt_randomness+0x21c/0x24c
[ 46.274204] handle_irq_event_percpu+0x40/0x84
[ 46.278739] handle_irq_event+0x40/0x64
[ 46.282667] handle_fasteoi_irq+0xbc/0x178
[ 46.286854] generic_handle_irq+0x28/0x3c
[ 46.290954] __handle_domain_irq+0x6c/0xe8
[ 46.295148] gic_handle_irq+0x64/0xc4
[ 46.298904] __irq_svc+0x70/0x98
[ 46.302225] _raw_spin_unlock_irq+0x30/0x34
[ 46.306505] finish_task_switch+0xc0/0x27c
[ 46.310693] __schedule+0x2c0/0x79c
[ 46.314272] schedule_idle+0x40/0x84
[ 46.317941] do_idle+0x178/0x2b4
[ 46.321259] cpu_startup_entry+0x20/0x24
[ 46.325278] rest_init+0x214/0x264
[ 46.328775] start_kernel+0x39c/0x424
[ 46.332527] (null)
[ 46.334891]
[ 46.334891] to a HARDIRQ-irq-unsafe lock:
[ 46.340379] (fs_reclaim){+.+.}
[ 46.340391]
[ 46.340391] ... which became HARDIRQ-irq-unsafe at:
[ 46.349885] ...
[ 46.349895] lock_acquire+0x70/0x90
[ 46.355225] fs_reclaim_acquire.part.3+0x38/0x48
[ 46.359933] fs_reclaim_acquire+0x1c/0x20
[ 46.364036] kmem_cache_alloc+0x2c/0x174
[ 46.368051] alloc_worker.constprop.10+0x1c/0x58
[ 46.372759] init_rescuer.part.4+0x18/0xa4
[ 46.376952] workqueue_init+0xc0/0x210
[ 46.380793] kernel_init_freeable+0x58/0x1d8
[ 46.385156] kernel_init+0x10/0x11c
[ 46.388736] ret_from_fork+0x14/0x20
[ 46.392399] (null)
[ 46.394762]
[ 46.394762] other info that might help us debug this:
[ 46.394762]
[ 46.402769] Possible interrupt unsafe locking scenario:
[ 46.402769]
[ 46.409560]CPU0CPU1
[ 46.414092]
[ 46.418622] lock(fs_reclaim);
[ 46.421772]local_irq_disable();
[ 46.427693]lock(&port_lock_key);
[ 46.433707]lock(fs_reclaim);
[ 46.439372]
[ 46.441993] lock(&port_lock_key);
[ 46.445661]
[ 46.445661] *** DEADLOCK ***
[ 46.445661]
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 97 ++--
1 file changed, 53 insertions(+), 44 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index b83bc2c..f2a2966 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -223,6 +223,7 @@ struct imx_port {
dma_cookie_trx_cookie;
unsigned inttx_bytes;
unsigned intdma_tx_nents;
+ struct work_struct tsk_dma_tx;
unsigned intsaved_reg[10];
boolcontext_saved;
};
@@ -491,8 +492,6 @@ static void imx_uart_enable_ms(struct uart_port *port)
mctrl_gpio_enable_ms(sport->gpios);
}
-static void imx_uart_dma_tx(struct imx_port *sport);
-
/* called with port.lock taken and irqs off */
static inline void imx_uart_transmit_buffer(struct imx_port *sport)
{
@@ -524,7 +523,7 @@ static inline void imx_
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
at 10:24 PM, Greg Kroah-Hartman wrote: > On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote: >> Removing the paragraph about writing to the Free Software Foundation's >> mailing address from the sample GPL notice according to checkpatch >> request. >> >> In addition, updating the year and adding a license tag. >> >> Reviewed-by: Xavier Deguillard >> Signed-off-by: Nadav Amit >> --- >> drivers/misc/vmw_balloon.c | 7 ++- >> 1 file changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c >> index 400a1ccefc8e..b982059ce7b7 100644 >> --- a/drivers/misc/vmw_balloon.c >> +++ b/drivers/misc/vmw_balloon.c >> @@ -1,7 +1,8 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> /* >> * VMware Balloon driver. >> * >> - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved. >> + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved. >> * >> * This program is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License as published by the >> @@ -13,10 +14,6 @@ >> * NON INFRINGEMENT. See the GNU General Public License for more >> * details. > > You still have a lot of boiler-plate text in here that can be removed. > Please do so. I will remove the maintainers, since it is really unsuitable. But what else do you want me to remove? This is a standard GPL license. If I am required to remove the GPL license, I will have to run checks to ensure it is appropriate. Thanks, Nadav
[PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
If a GPIO chip is a part of a hierarchy IRQ domain, there is no
way to specify the trigger type when gpio(d)_to_irq() allocates an
interrupt on-the-fly.
Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
an error in the .alloc() hook of the parent domain.
(drivers/irq/irq-uniphier-aidet.c)
Even if we change irq-uniphier-aidet.c to accept the NONE type,
GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
Loudly complain about the use of IRQ_TYPE_NONE").
Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
is allocated. irq_set_irq_type() will override it when the irq is
really requested.
Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
Reported-by: Katsuhiro Suzuki
Signed-off-by: Masahiro Yamada
Tested-by: Katsuhiro Suzuki
---
drivers/gpio/gpio-uniphier.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index d3cf950..58faeb1 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip,
unsigned int offset)
fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
fwspec.param_count = 2;
fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
- fwspec.param[1] = IRQ_TYPE_NONE;
+ /*
+* IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
+* temporarily. Anyway, ->irq_set_type() will override it later.
+*/
+ fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
return irq_create_fwspec_mapping(&fwspec);
}
--
2.7.4
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote: > Removing the paragraph about writing to the Free Software Foundation's > mailing address from the sample GPL notice according to checkpatch > request. > > In addition, updating the year and adding a license tag. > > Reviewed-by: Xavier Deguillard > Signed-off-by: Nadav Amit > --- > drivers/misc/vmw_balloon.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c > index 400a1ccefc8e..b982059ce7b7 100644 > --- a/drivers/misc/vmw_balloon.c > +++ b/drivers/misc/vmw_balloon.c > @@ -1,7 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * VMware Balloon driver. > * > - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved. > + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved. > * > * This program is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License as published by the > @@ -13,10 +14,6 @@ > * NON INFRINGEMENT. See the GNU General Public License for more > * details. You still have a lot of boiler-plate text in here that can be removed. Please do so. thanks, greg k-h
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
> When balloon batching is not supported by the hypervisor, the guest
> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
> was mistakenly ignored. In practice, when total RAM is greater than
> 16TB, the balloon does not work currently, making this bug unlikely to
> happen.
>
> Fixes: ef0f8f112984 ("VMware balloon: partially inline
> vmballoon_reserve_page.")
>
> Cc: sta...@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for
4.18-final and one for 4.19-rc1. You should always split up bugfixes
from new features/cleanups as that is what I have to do when sending
them to Linus.
thanks,
greg k-h
[PATCH 1/2] PM / Domains: Rename opp_node to np
The DT node passed here isn't necessarily an OPP node, as this routine
can also be used for cases where the "required-opps" property is present
directly in the device's node. Rename it.
This also removes a stale comment.
Signed-off-by: Viresh Kumar
---
drivers/base/power/domain.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4925af5c4cf0..c298de8a8308 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2487,10 +2487,9 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
* power domain corresponding to a DT node's "required-opps" property.
*
* @dev: Device for which the performance-state needs to be found.
- * @opp_node: DT node where the "required-opps" property is present. This can
be
+ * @np: DT node where the "required-opps" property is present. This can be
* the device node itself (if it doesn't have an OPP table) or a node
* within the OPP table of a device (if device has an OPP table).
- * @state: Pointer to return performance state.
*
* Returns performance state corresponding to the "required-opps" property of
* a DT node. This calls platform specific genpd->opp_to_performance_state()
@@ -2499,7 +2498,7 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
* Returns performance state on success and 0 on failure.
*/
unsigned int of_genpd_opp_to_performance_state(struct device *dev,
- struct device_node *opp_node)
+ struct device_node *np)
{
struct generic_pm_domain *genpd;
struct dev_pm_opp *opp;
@@ -2514,7 +2513,7 @@ unsigned int of_genpd_opp_to_performance_state(struct
device *dev,
genpd_lock(genpd);
- opp = of_dev_pm_opp_find_required_opp(&genpd->dev, opp_node);
+ opp = of_dev_pm_opp_find_required_opp(&genpd->dev, np);
if (IS_ERR(opp)) {
dev_err(dev, "Failed to find required OPP: %ld\n",
PTR_ERR(opp));
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH 2/2] PM / Domains: Fix return value of of_genpd_opp_to_performance_state()
of_genpd_opp_to_performance_state() should return 0 for errors, but the
dummy routine isn't doing that. Fix it.
Signed-off-by: Viresh Kumar
---
include/linux/pm_domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 9206a4fef9ac..139f79c8477a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -276,7 +276,7 @@ static inline unsigned int
of_genpd_opp_to_performance_state(struct device *dev,
struct device_node *opp_node)
{
- return -ENODEV;
+ return 0;
}
static inline int genpd_dev_pm_attach(struct device *dev)
--
2.18.0.rc1.242.g61856ae69a2c
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> [...]
> > From: Naoya Horiguchi
> > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > Subject: [PATCH] mm: zero remaining unavailable struct pages
> >
> > There is a kernel panic that is triggered when reading /proc/kpageflags
> > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> >
> > BUG: unable to handle kernel paging request at fffe
> > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> > 04/01/2014
> > RIP: 0010:stable_page_flags+0x27/0x3c0
> > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > RAX: fffe RBX: 7fffeff9 RCX:
> > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > RBP: R08: 0001 R09: 0001
> > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > FS: 7efc4335a500() GS:93a5bfc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > Call Trace:
> >kpageflags_read+0xc7/0x120
> >proc_reg_read+0x3c/0x60
> >__vfs_read+0x36/0x170
> >vfs_read+0x89/0x130
> >ksys_pread64+0x71/0x90
> >do_syscall_64+0x5b/0x160
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7efc42e75e23
> > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> >
> > According to kernel bisection, this problem became visible due to commit
> > f7f99100d8d9 which changes how struct pages are initialized.
> >
> > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > the default (no memmap= given) memblock layout is like below:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x4
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x0001-0x00013fff],
> > 0x4000 bytes on node 0 flags: 0x0
> >memory[0x3] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > the range [0x1-0x13fff] is gone:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x3
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > This causes shrinking node 0's pfn range because it is calculated by
> > the address range of memblock.memory. So some of struct pages in the
> > gap range are left uninitialized.
> >
> > We have a function zero_resv_unavail() which does zeroing the struct
> > pages outside memblock.memory, but currently it covers only the reserved
> > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > This patch extends it to cover all unavailable range, which fixes
> > the reported issue.
>
> Thanks for pin pointing this down Naoya! I am wondering why we cannot
> simply mark the excluded ranges to be reserved instead.
I tried your idea with the change below, and it also fixes the kernel panic.
---
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d1f25c831447..2cef120535d4 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1248,6 +1248,7 @@ void __init e820__memblock_setup(void)
{
int i;
u64 end;
+ u64 addr = 0;
/*
* The bootstrap memblock region count maximum is 128 entries
@@ -1264,13 +1265,16 @@ void __init e820__memblock_setup(void)
struct e820_entry *entry = &e820_table->entries[i];
end = entry->addr + entry->size;
+
[PATCH v2 3/3] mtd: rawnand: denali: optimize timing parameters for data interface
This commit improves the ->setup_data_interface() hook.
The denali_setup_data_interface() needs the frequency of clk_x
and the ratio of clk_x / clk.
The latter is currently hardcoded in the driver, like this:
#define DENALI_CLK_X_MULT 6
The IP datasheet requires that clk_x / clk be 4, 5, or 6. I just
chose 6 because it is the most defensive value, but it is not optimal.
By getting the clock rate of both "clk" and "clk_x", the driver can
compute the timing values more precisely.
To not break the existing platforms, the fallback value, 50 MHz is
provided. It is true for all upstreamed platforms.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Split patches into sensible chunks
drivers/mtd/nand/raw/denali.c | 49 +++
drivers/mtd/nand/raw/denali.h | 1 +
drivers/mtd/nand/raw/denali_dt.c | 2 ++
drivers/mtd/nand/raw/denali_pci.c | 1 +
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 2a302a1..2de46d4 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -51,14 +51,6 @@ MODULE_LICENSE("GPL");
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-/*
- * The bus interface clock, clk_x, is phase aligned with the core clock. The
- * clk_x is an integral multiple N of the core clk. The value N is configured
- * at IP delivery time, and its available value is 4, 5, or 6. We need to
align
- * to the largest value to make it work with any possible configuration.
- */
-#define DENALI_CLK_X_MULT 6
-
static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
{
return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
@@ -954,7 +946,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
{
struct denali_nand_info *denali = mtd_to_denali(mtd);
const struct nand_sdr_timings *timings;
- unsigned long t_clk;
+ unsigned long t_x, mult_x;
int acc_clks, re_2_we, re_2_re, we_2_re, addr_2_data;
int rdwr_en_lo, rdwr_en_hi, rdwr_en_lo_hi, cs_setup;
int addr_2_data_mask;
@@ -965,15 +957,24 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
return PTR_ERR(timings);
/* clk_x period in picoseconds */
- t_clk = DIV_ROUND_DOWN_ULL(1ULL, denali->clk_x_rate);
- if (!t_clk)
+ t_x = DIV_ROUND_DOWN_ULL(1ULL, denali->clk_x_rate);
+ if (!t_x)
+ return -EINVAL;
+
+ /*
+* The bus interface clock, clk_x, is phase aligned with the core clock.
+* The clk_x is an integral multiple N of the core clk. The value N is
+* configured at IP delivery time, and its available value is 4, 5, 6.
+*/
+ mult_x = DIV_ROUND_CLOSEST_ULL(denali->clk_x_rate, denali->clk_rate);
+ if (mult_x < 4 || mult_x > 6)
return -EINVAL;
if (chipnr == NAND_DATA_IFACE_CHECK_ONLY)
return 0;
/* tREA -> ACC_CLKS */
- acc_clks = DIV_ROUND_UP(timings->tREA_max, t_clk);
+ acc_clks = DIV_ROUND_UP(timings->tREA_max, t_x);
acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
tmp = ioread32(denali->reg + ACC_CLKS);
@@ -982,7 +983,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
iowrite32(tmp, denali->reg + ACC_CLKS);
/* tRWH -> RE_2_WE */
- re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_clk);
+ re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_x);
re_2_we = min_t(int, re_2_we, RE_2_WE__VALUE);
tmp = ioread32(denali->reg + RE_2_WE);
@@ -991,7 +992,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
iowrite32(tmp, denali->reg + RE_2_WE);
/* tRHZ -> RE_2_RE */
- re_2_re = DIV_ROUND_UP(timings->tRHZ_max, t_clk);
+ re_2_re = DIV_ROUND_UP(timings->tRHZ_max, t_x);
re_2_re = min_t(int, re_2_re, RE_2_RE__VALUE);
tmp = ioread32(denali->reg + RE_2_RE);
@@ -1005,8 +1006,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
* With WE_2_RE properly set, the Denali controller automatically takes
* care of the delay; the driver need not set NAND_WAIT_TCCS.
*/
- we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min),
- t_clk);
+ we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min), t_x);
we_2_re = min_t(int, we_2_re, TWHR2_AND_WE_2_RE__WE_2_RE);
tmp = ioread32(denali->reg + TWHR2_AND_WE_2_RE);
@@ -1021,7 +1021,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
if (denali->revision < 0x0501)
addr_2_data_mask >>= 1;
- addr_2_data = DIV_ROUND_UP(timings->tADL_min, t_clk);
+ addr_2_data = DIV_ROUND_UP(timings->tA
[PATCH v2 0/3] mtd: rawnand: denali: add new clocks and improve setup_data_interface
The ->setup_data_interface() hook needs to know the clock frequency. In fact, this IP needs three clocks, bus "which clock?" is really confusing. (It is not described in the DT-binding at all.) This series adds more clocks. In the new binding, three clocks are required: core clock, bus interface clock, ECC engine clock. This series also takes care of the backward compatibility by providing hardcoded values in case the new clocks are missing. So, existing DT should work. Changes in v2: - Split patches into sensible chunks Masahiro Yamada (3): mtd: rawnand: denali_dt: use dev as a shorthand of &pdev->dev mtd: rawnand: denali_dt: add more clocks based on IP datasheet mtd: rawnand: denali: optimize timing parameters for data interface .../devicetree/bindings/mtd/denali-nand.txt| 5 ++ drivers/mtd/nand/raw/denali.c | 49 drivers/mtd/nand/raw/denali.h | 1 + drivers/mtd/nand/raw/denali_dt.c | 66 ++ drivers/mtd/nand/raw/denali_pci.c | 1 + 5 files changed, 86 insertions(+), 36 deletions(-) -- 2.7.4
linux-kernel@vger.kernel.org
Add 'dev' as a shorthand before adding more code that takes a
pointer to struce device.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali_dt.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index cfd33e6..d923cfa 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -79,44 +79,45 @@ MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
static int denali_dt_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct resource *res;
struct denali_dt *dt;
const struct denali_dt_data *data;
struct denali_nand_info *denali;
int ret;
- dt = devm_kzalloc(&pdev->dev, sizeof(*dt), GFP_KERNEL);
+ dt = devm_kzalloc(dev, sizeof(*dt), GFP_KERNEL);
if (!dt)
return -ENOMEM;
denali = &dt->denali;
- data = of_device_get_match_data(&pdev->dev);
+ data = of_device_get_match_data(dev);
if (data) {
denali->revision = data->revision;
denali->caps = data->caps;
denali->ecc_caps = data->ecc_caps;
}
- denali->dev = &pdev->dev;
+ denali->dev = dev;
denali->irq = platform_get_irq(pdev, 0);
if (denali->irq < 0) {
- dev_err(&pdev->dev, "no irq defined\n");
+ dev_err(dev, "no irq defined\n");
return denali->irq;
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "denali_reg");
- denali->reg = devm_ioremap_resource(&pdev->dev, res);
+ denali->reg = devm_ioremap_resource(dev, res);
if (IS_ERR(denali->reg))
return PTR_ERR(denali->reg);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_data");
- denali->host = devm_ioremap_resource(&pdev->dev, res);
+ denali->host = devm_ioremap_resource(dev, res);
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
- dt->clk = devm_clk_get(&pdev->dev, NULL);
+ dt->clk = devm_clk_get(dev, NULL);
if (IS_ERR(dt->clk)) {
- dev_err(&pdev->dev, "no clk available\n");
+ dev_err(dev, "no clk available\n");
return PTR_ERR(dt->clk);
}
ret = clk_prepare_enable(dt->clk);
--
2.7.4
[PATCH v2 2/3] mtd: rawnand: denali_dt: add more clocks based on IP datasheet
According to the Denali User's Guide, this IP needs three clocks:
- clk: controller core clock
- clk_x: bus interface clock
- ecc_clk: clock at which ECC circuitry is run
Currently, denali_dt.c requires a single anonymous clock and its
frequency. However, the driver needs to get the frequency of "clk_x"
not "clk". This is confusing because people tend to assume the
anonymous clock means the core clock.
Instead of the cheesy implementation, the clocks in the real hardware
should be represented in the driver and the DT-binding.
However, adding new clocks would break the existing platforms. For the
backward compatibility, the driver still accepts a single clock just as
before. If clk_x is missing, clk_x_rate is set to a hardcoded value.
It is fine because both Altera (Intel) SOCFPGA and Socionext UniPhier
use 200 MHz for the bus interface clock.
Signed-off-by: Masahiro Yamada
---
Changes in v2: split into sensible chunks
.../devicetree/bindings/mtd/denali-nand.txt| 5 +++
drivers/mtd/nand/raw/denali_dt.c | 49 --
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 0ee8edb..f33da87 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -8,6 +8,9 @@ Required properties:
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
+ - clocks: should contain phandle of the controller core clock, the bus
+interface clock, and the ECC circuit clock.
+ - clock-names: should contain "nand", "nand_x", "ecc"
Optional properties:
- nand-ecc-step-size: see nand.txt for details. If present, the value must
be
@@ -31,5 +34,7 @@ nand: nand@ff90 {
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
+ clocks = <&nand_clk>, <&nand_x_clk>, <&nand_ecc_clk>;
+ clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
};
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index d923cfa..afaae37 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -27,7 +27,9 @@
struct denali_dt {
struct denali_nand_info denali;
- struct clk *clk;
+ struct clk *clk;/* core clock */
+ struct clk *clk_x; /* bus interface clock */
+ struct clk *clk_ecc;/* ECC circuit clock */
};
struct denali_dt_data {
@@ -115,24 +117,61 @@ static int denali_dt_probe(struct platform_device *pdev)
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
- dt->clk = devm_clk_get(dev, NULL);
+ /*
+* A single anonymous clock is supported for the backward compatibility.
+* New platforms should support all the named clocks.
+*/
+ dt->clk = devm_clk_get(dev, "nand");
+ if (IS_ERR(dt->clk))
+ dt->clk = devm_clk_get(dev, NULL);
if (IS_ERR(dt->clk)) {
dev_err(dev, "no clk available\n");
return PTR_ERR(dt->clk);
}
+
+ dt->clk_x = devm_clk_get(dev, "nand_x");
+ if (IS_ERR(dt->clk_x))
+ dt->clk_x = NULL;
+
+ dt->clk_ecc = devm_clk_get(dev, "ecc");
+ if (IS_ERR(dt->clk_ecc))
+ dt->clk_ecc = NULL;
+
ret = clk_prepare_enable(dt->clk);
if (ret)
return ret;
- denali->clk_x_rate = clk_get_rate(dt->clk);
+ ret = clk_prepare_enable(dt->clk_x);
+ if (ret)
+ goto out_disable_clk;
+
+ ret = clk_prepare_enable(dt->clk_ecc);
+ if (ret)
+ goto out_disable_clk_x;
+
+ if (dt->clk_x) {
+ denali->clk_x_rate = clk_get_rate(dt->clk_x);
+ } else {
+ /*
+* Hardcode the clock rates for the backward compatibility.
+* This works for both SOCFPGA and UniPhier.
+*/
+ dev_notice(dev,
+ "necessary clock is missing. default clock rates are
used.\n");
+ denali->clk_x_rate = 2;
+ }
ret = denali_init(denali);
if (ret)
- goto out_disable_clk;
+ goto out_disable_clk_ecc;
platform_set_drvdata(pdev, dt);
return 0;
+out_disable_clk_ecc:
+ clk_disable_unprepare(dt->clk_ecc);
+out_disable_clk_x:
+ clk_disable_unprepare(dt->clk_x);
out_disable_clk:
clk_disable_unprepare(dt->clk);
@@ -144,6 +183,8 @@ static int denali_dt_remove(struct platform_device *pdev)
struct denali_dt *dt = platform_get_drvdata(pdev);
denali_remove(&dt->denali)
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 10:40:32AM +0200, Oscar Salvador wrote:
> On Wed, Jun 13, 2018 at 05:41:08AM +, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I wrote a patch for this issue.
> > There was a discussion about prechecking approach, but I finally found
> > out it's hard to make change on memblock after numa_init, so I take
> > another apporach (see patch description).
> >
> > I'm glad if you check that it works for you.
> >
> > Thanks,
> > Naoya Horiguchi
> > ---
> > From: Naoya Horiguchi
> > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > Subject: [PATCH] mm: zero remaining unavailable struct pages
> >
> > There is a kernel panic that is triggered when reading /proc/kpageflags
> > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> >
> > BUG: unable to handle kernel paging request at fffe
> > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> > 04/01/2014
> > RIP: 0010:stable_page_flags+0x27/0x3c0
> > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > RAX: fffe RBX: 7fffeff9 RCX:
> > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > RBP: R08: 0001 R09: 0001
> > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > FS: 7efc4335a500() GS:93a5bfc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > Call Trace:
> >kpageflags_read+0xc7/0x120
> >proc_reg_read+0x3c/0x60
> >__vfs_read+0x36/0x170
> >vfs_read+0x89/0x130
> >ksys_pread64+0x71/0x90
> >do_syscall_64+0x5b/0x160
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7efc42e75e23
> > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> >
> > According to kernel bisection, this problem became visible due to commit
> > f7f99100d8d9 which changes how struct pages are initialized.
> >
> > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > the default (no memmap= given) memblock layout is like below:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x4
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x0001-0x00013fff],
> > 0x4000 bytes on node 0 flags: 0x0
> >memory[0x3] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > the range [0x1-0x13fff] is gone:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x3
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > This causes shrinking node 0's pfn range because it is calculated by
> > the address range of memblock.memory. So some of struct pages in the
> > gap range are left uninitialized.
> >
> > We have a function zero_resv_unavail() which does zeroing the struct
> > pages outside memblock.memory, but currently it covers only the reserved
> > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > This patch extends it to cover all unavailable range, which fixes
> > the reported issue.
> >
> > Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
> > Signed-off-by: Naoya Horiguchi
> > ---
> > include/linux/memblock.h | 16
> > mm/page_alloc.c | 33 -
> > 2 files changed, 24 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > inde
[PATCH] extcon: Release locking when sending the notification of connector state
Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue,
extcon consumer device should always use the work. it is always not
reasonable to use work.
To fix this issue on extcon consumer device, release locking when sending
the notification of connector state.
Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support
the notification")
Cc: sta...@vger.kernel.org
Cc: Roger Quadros
Cc: Kishon Vijay Abraham I
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8bff5fd18185..f75b08a45d4e 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
return index;
spin_lock_irqsave(&edev->lock, flags);
-
state = !!(edev->state & BIT(index));
+ spin_unlock_irqrestore(&edev->lock, flags);
/*
* Call functions in a raw notifier chain for the specific one
@@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
*/
raw_notifier_call_chain(&edev->nh_all, state, edev);
+ spin_lock_irqsave(&edev->lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {
--
1.9.1
Re: [PATCH] selftests: kselftest_harness: return Kselftest Skip code for skipped tests
On Wed, Jun 13, 2018 at 6:34 PM, Shuah Khan (Samsung OSG)
wrote:
> When a test is skipped because of unmet dependencies and/or unsupported
> configuration, kselftest_harness exits with error which is treated as a
> fail by the Kselftest framework. This leads to false negative result even
> when the test could not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run. This change add skip
> handling to kselftest_harness with minimal changes adding a new skipped
> field to struct __test_metadata and using it to recognize KSFT_SKIP exit
> from the test function (t->fn) to __run_test() to the test_harness_run()
> to return the right skip code to Kselftest framework.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
Unfortunately this will not work: test step # is used as the failure
code to let test runners know where a child failed. KSFT_SKIP is 4, so
every test failing in step 4 would be seen as a skip instead of a
fail.
Tests must not exit on their own with this harness: only the existing
ASSERT/EXPECT macros can be used. uevent test should never be doing
this:
if (geteuid()) {
TH_LOG("Uevent filtering tests require root
privileges. Skipping test");
_exit(KSFT_SKIP);
}
Nor the _exit(EXIT_FAILURE) calls. Those must all be ASSERT() instead.
Perhaps a new signal could be used, but the return codes are already being used.
-Kees
>
> This change is tested on uevent test and the results are as follows:
>
> Before:
>
> TAP version 13
> selftests: uevent: uevent_filtering
>
> [==] Running 1 tests from 1 test cases.
> [ RUN ] global.uevent_filtering
> uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
> root privileges. Skipping test
> global.uevent_filtering: Test skipped at step #4
> [ FAIL ] global.uevent_filtering
> [==] 0 / 1 tests passed.
> [ FAILED ]
> not ok 1..1 selftests: uevent: uevent_filtering [FAIL]
>
> After:
>
> TAP version 13
> selftests: uevent: uevent_filtering
>
> [==] Running 1 tests from 1 test cases.
> [ RUN ] global.uevent_filtering
> uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
> root privileges. Skipping test
> global.uevent_filtering: Test skipped at step #4
> [ SKIP ] global.uevent_filtering
> not ok 1..1 selftests: uevent: uevent_filtering [SKIP]
>
> Signed-off-by: Shuah Khan (Samsung OSG)
> ---
> tools/testing/selftests/kselftest_harness.h | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kselftest_harness.h
> b/tools/testing/selftests/kselftest_harness.h
> index 6ae3730c4ee3..7af9ab97b367 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -631,6 +631,7 @@ struct __test_metadata {
> void (*fn)(struct __test_metadata *);
> int termsig;
> int passed;
> + int skipped;
> int trigger; /* extra handler after the evaluation */
> __u8 step;
> bool no_print; /* manual trigger when TH_LOG_STREAM is not available
> */
> @@ -694,6 +695,7 @@ void __run_test(struct __test_metadata *t)
> int status;
>
> t->passed = 1;
> + t->skipped = 0;
> t->trigger = 0;
> printf("[ RUN ] %s\n", t->name);
> child_pid = fork();
> @@ -716,9 +718,12 @@ void __run_test(struct __test_metadata *t)
> t->name,
> WEXITSTATUS(status));
> } else if (!t->passed) {
> + if (WEXITSTATUS(status) == KSFT_SKIP)
> + t->skipped = 1;
> fprintf(TH_LOG_STREAM,
> - "%s: Test failed at step #%d\n",
> + "%s: Test %s at step #%d\n",
> t->name,
> + (t->skipped ? "skipped" : "failed"),
> WEXITSTATUS(status));
> }
> } else if (WIFSIGNALED(status)) {
> @@ -743,7 +748,11 @@ void __run_test(struct __test_metadata *t)
> status);
> }
> }
> - printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
> + if (t->skipped)
> + printf("[ %4s ] %s\n", "SKIP", t->name);
> + else
> + printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"),
> + t->name);
> }
>
> static int test_harness_run(int __attribute__((unused)) argc,
> @@ -762,6 +771,8 @@ static int test_harness_run(int __a
Improving kselfests cross compilation
Hi Shuah,
I was giving a shot at building the kselftests from within buildroot [1]
as of Linux be779f03d563981c65cc7417cc5e0dbbc5b89d30 and there are a
number of things that make it still reasonably hard even today:
- 3c545084130c1fd5cf873a5fec3ee29070128e06 ("selftests: sparc64: char:
Selftest for privileged ADI driver") this contains inline assembly that
can only work when building for sparc64, yet this is still being built
irrespective of what ARCH is set to
- each Makefile that requires knowledge of the architecture seems to
duplicate what ARCH should be, this cannot be moved to lib.mk since
Makefiles do expect lib.mk to be included last and/or after they have
done their own overrides, but something like common.mk which contains
CC, ARCH etc. could be useful to avoid the repetition of looking at
uname -m etc. etc.
- some tests' Makefile do seem to hardcode paths to the system's include
instead of accepting a configurable path:
gpio/Makefile:
LDLIBS += -lmount -I/usr/include/libmount
I will try to submit patches in the next days that address the most
obvious issues I listed here, but in order for this effort not to be a
constant whack-a-mole game, there really needs to be at least one or two
architectures that must attempt to cross-compile (and run) those tests
and use that as an acceptance criteria.
Thanks for reading.
[1]:
https://git.buildroot.org/buildroot/tree/package/linux-tools/linux-tool-selftests.mk.in
--
Florian
Re: linux-next: manual merge of the cifs tree with Linus' tree
Steve,
Looks good. It builds and seems to work in my testing.
Thanks.
- Original Message -
From: "Steve French"
To: "Stephen Rothwell"
Cc: "CIFS" , "Linux-Next Mailing List"
, "Linux Kernel Mailing List"
, "Kees Cook" , "Ronnie
Sahlberg" , "Aurelien Aptel"
Sent: Thursday, 14 June, 2018 10:40:43 AM
Subject: Re: linux-next: manual merge of the cifs tree with Linus' tree
Ronnie,
I fixed up that patch and repushed to cifs-2.6.git for-next. Seems
trivial. Let me know if any issues.
On Wed, Jun 13, 2018 at 6:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the cifs tree got a conflict in:
>
> fs/cifs/transport.c
>
> between commit:
>
> 6da2ec56059c ("treewide: kmalloc() -> kmalloc_array()")
>
> from Linus' tree and commit:
>
> 1560d69e21c6 ("cifs: push rfc1002 generation down the stack")
>
> from the cifs tree.
>
> I fixed it up (the latter removed the code modified by the former) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] selftests: vm: return Kselftest Skip code for skipped tests
When vm test is skipped because of unmet dependencies and/or unsupported
configuration, it exits with error which is treated as a fail by the
Kselftest framework. This leads to false negative result even when the
test could not be run.
Change it to return kselftest skip code when a test gets skipped to
clearly report that the test could not be run.
Kselftest framework SKIP code is 4 and the framework prints appropriate
messages to indicate that the test is skipped.
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/testing/selftests/vm/compaction_test.c | 4 +++-
tools/testing/selftests/vm/mlock2-tests.c| 12 +++-
tools/testing/selftests/vm/run_vmtests | 5 -
tools/testing/selftests/vm/userfaultfd.c | 4 +++-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/vm/compaction_test.c
b/tools/testing/selftests/vm/compaction_test.c
index 1097f04e4d80..bcec71250873 100644
--- a/tools/testing/selftests/vm/compaction_test.c
+++ b/tools/testing/selftests/vm/compaction_test.c
@@ -16,6 +16,8 @@
#include
#include
+#include "../kselftest.h"
+
#define MAP_SIZE 1048576
struct map_list {
@@ -169,7 +171,7 @@ int main(int argc, char **argv)
printf("Either the sysctl compact_unevictable_allowed is not\n"
"set to 1 or couldn't read the proc file.\n"
"Skipping the test\n");
- return 0;
+ return KSFT_SKIP;
}
lim.rlim_cur = RLIM_INFINITY;
diff --git a/tools/testing/selftests/vm/mlock2-tests.c
b/tools/testing/selftests/vm/mlock2-tests.c
index 4997b9222cfa..637b6d0ac0d0 100644
--- a/tools/testing/selftests/vm/mlock2-tests.c
+++ b/tools/testing/selftests/vm/mlock2-tests.c
@@ -9,6 +9,8 @@
#include
#include "mlock2.h"
+#include "../kselftest.h"
+
struct vm_boundaries {
unsigned long start;
unsigned long end;
@@ -303,7 +305,7 @@ static int test_mlock_lock()
if (mlock2_(map, 2 * page_size, 0)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(0)");
goto unmap;
@@ -412,7 +414,7 @@ static int test_mlock_onfault()
if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(MLOCK_ONFAULT)");
goto unmap;
@@ -425,7 +427,7 @@ static int test_mlock_onfault()
if (munlock(map, 2 * page_size)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("munlock()");
goto unmap;
@@ -457,7 +459,7 @@ static int test_lock_onfault_of_present()
if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(MLOCK_ONFAULT)");
goto unmap;
@@ -583,7 +585,7 @@ static int test_vma_management(bool call_mlock)
if (call_mlock && mlock2_(map, 3 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock(ONFAULT)\n");
goto out;
diff --git a/tools/testing/selftests/vm/run_vmtests
b/tools/testing/selftests/vm/run_vmtests
index 22d564673830..88cbe5575f0c 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -2,6 +2,9 @@
# SPDX-License-Identifier: GPL-2.0
#please run as root
+# Kselftest framework requirement - SKIP code is 4.
+ksft_skip=4
+
mnt=./huge
exitcode=0
@@ -36,7 +39,7 @@ if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
echo $(( $lackpgs + $nr_hugepgs )) > /proc/sys/vm/nr_hugepages
if [ $? -ne 0 ]; then
echo "Please run this test as root"
- exit 1
+ exit $ksft_skip
fi
while read name size unit; do
if [ "$name" = "HugePages_Free:" ]; then
diff --git a/tools/testing/selftests/vm/userfaultfd.c
b/tools/testing/selftests/vm/userfaultfd.c
index de2f9ec8a87f..7b8171e3128a 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -69,6 +69,8 @@
#in
[PATCH] devres: Add devm_of_iomap()
There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.
This is generally open coded in drivers which is quite error prone
We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
---
include/linux/device.h | 4
lib/devres.c | 36
2 files changed, 40 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index beabdbc08420..1529775ecb36 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -686,6 +686,10 @@ extern void devm_free_pages(struct device *dev, unsigned
long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *node, int index,
+ resource_size_t *size);
+
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
void devm_remove_action(struct device *dev, void (*action)(void *), void
*data);
diff --git a/lib/devres.c b/lib/devres.c
index 78eca713b1d9..e320f80c1c4e 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
void devm_ioremap_release(struct device *dev, void *res)
{
@@ -163,6 +164,41 @@ void __iomem *devm_ioremap_resource(struct device *dev,
struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/*
+ * devm_of_iomap - Requests a resource and maps the memory mapped IO
+ *for a given device_node managed by a given device
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach of the device.
+ *
+ * This is to be used when a device requests/maps resources described
+ * by other device tree nodes (children or otherwise).
+ *
+ * @dev: The device "managing" the resource
+ * @node: The device-tree node where the resource resides
+ * @index: index of the MMIO range in the "reg" property
+ * @size: Returns the size of the resource (pass NULL if not needed)
+ * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
+ * error code on failure. Usage example:
+ *
+ * base = devm_of_iomap(&pdev->dev, node, 0, NULL);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_of_iomap(struct device *dev, struct device_node *node, int
index,
+ resource_size_t *size)
+{
+ struct resource res;
+
+ if (of_address_to_resource(node, index, &res))
+ return IOMEM_ERR_PTR(-EINVAL);
+ if (size)
+ *size = resource_size(&res);
+ return devm_ioremap_resource(dev, &res);
+}
+EXPORT_SYMBOL(devm_of_iomap);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
[PATCH] selftests: user: return Kselftest Skip code for skipped tests
When user test is skipped because of unmet dependencies and/or unsupported configuration, it exits with error which is treated as a fail by the Kselftest framework. This leads to false negative result even when the test could not be run. Change it to return kselftest skip code when a test gets skipped to clearly report that the test could not be run. Add an explicit check for module presence and return skip code if module isn't present. Kselftest framework SKIP code is 4 and the framework prints appropriate messages to indicate that the test is skipped. Signed-off-by: Shuah Khan (Samsung OSG) --- tools/testing/selftests/user/test_user_copy.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/user/test_user_copy.sh b/tools/testing/selftests/user/test_user_copy.sh index d60506fc77f8..f9b31a57439b 100755 --- a/tools/testing/selftests/user/test_user_copy.sh +++ b/tools/testing/selftests/user/test_user_copy.sh @@ -2,6 +2,13 @@ # SPDX-License-Identifier: GPL-2.0 # Runs copy_to/from_user infrastructure using test_user_copy kernel module +# Kselftest framework requirement - SKIP code is 4. +ksft_skip=4 + +if ! /sbin/modprobe -q -n test_user_copy; then + echo "user: module test_user_copy is not found [SKIP]" + exit $ksft_skip +fi if /sbin/modprobe -q test_user_copy; then /sbin/modprobe -q -r test_user_copy echo "user_copy: ok" -- 2.17.0
Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
On Tue, 2018-06-12 at 17:58 +0800, Sean Wang wrote:
> On Wed, 2018-05-30 at 08:26 +0200, Marcel Holtmann wrote:
> > Hi Sean,
> >
> > >>
>
> [ ... ]
>
> > >>> * Unknown packet (code 14 len 30)
> > >>> 0.641509
> > >>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..bl
> > >>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00uetoothd..
> > >>> * Unknown packet (code 14 len 30)
> > >>> 0.641592
> > >>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..bt
> > >>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00mon...
> > >>> * Unknown packet (code 16 len 7)[hci0]
> > >>> 6.536771
> > >>> 01 00 00 00 05 00 01 ...
> > >>> = Open Index: 00:00:46:76:22:01 [hci0]
> > >>> 6.717019
> > >>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.)[hci0]
> > >>> 6.717030
> > >>
> > >> can you try with the latest BlueZ 5.49 or git version. Seems it actually
> > >> stumbles over the extra packet here. Fun fact is that I can not get a
> > >> backtrace to pin-point the issue in btmon and why it crashes.
> > >>
> > >
> > > I had less experience updating user land BlueZ, but I can try it as
> > > possible and see whether Unknown packets still are present at newest
> > > version BlueZ. Hopefully I don't misunderstand your point here.
> >
> > please use the latest btmon and check if it can read your trace.
> >
>
> sure, I'll have a try with the latest btmon.
I use the btmon version 5.50 and it can read the trace
>
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.741093
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.742088
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.743102
> > >>> 02 01 01 00 00 .
>
>
> [ ... ]
>
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.814708
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.815705
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.816378
> > >>> 02 01 01 00 00 .
> > >>
> > >> Why do I see only HCI events here? Is this event conveying any useful
> > >> information. It is kinda complicated that this is 0xe4 event code which
> > >> is actually reserved for future use by the Bluetooth SIG. Are there any
> > >> accompanying HCI commands for this and they just not make it into btmon?
> > >>
> > >
> > > I have made all vendor HCI commands go through BlueZ core in v2 patch.
> > >
> > > And for these HCI events, they are all corresponding to vendor ACL data,
> > > applied only to firmware setup packets, but they're not being sent via
> > > BlueZ core, so they are not being logged in btmon.
> > >
> > > As for its event, where heading 0xe4 refers to a vendor event and is used
> > > on notification of that either vendor ACL data or vendor HCI command have
> > > been done.
> >
> > I would prefer if everything goes via the Bluetooth core since then we have
> > it all properly scheduled. Sending things down the ACL data path however if
> > kinda funky. Does your hardware accept sending command both via ACL data
> > and as HCI command? If so, then I would prefer sending them as HCI commands
> > since the speed improvement you think you are getting is neglectable on
> > Linux (I have been down that path). This seems to be a pure optimization
> > when Windows is driving the device.
> >
>
> firmware people said the device can support firmware download as HCI
> commands. According to my test, this way indeed works so I will improve the
> part in the next version.
>
>
> > And the vendor event 0xe4 is really only received during firmware download?
> > It is not ever received during normal operation?
> >
>
> 0xe4 is only received during chip initialization.
>
> I also thought 0xe4 is a poor definition for vendor event and already have
> notified firmware people should pick 0xff as its vendor event id in the
> future.
>
> but for now, unfortunately, 0xe4 cannot be changed on the device, the only
> way is to add a workaround in RX path as below to allow btmon can recognize
> these bad events properly.
>
> int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
> {
> struct hci_event_hdr *hdr = (void
Re: [PATCH v3 0/6] add virt-dma support for imx-sdma
Hi Lucas, I have identified the root cause besides the lockdep issue. Will contain the UART patch into my next v4 patchset. Hi Sascha, Will address your comments in v4 too. Thank you both input. On 三, 2018-06-13 at 18:07 +0200, Lucas Stach wrote: > Hi Robin, > > Am Dienstag, den 12.06.2018, 08:58 + schrieb Robin Gong: > > > > Hi Lucas, > > Is the below DEAD LOCK issue same as your side? If yes, then > > I'm afraid that we have to make another patch for uart to split dma > > functions in uart driver out of the code area which protected by > > port.lock. The warning make sense since allocate sdma bd memory > > dynamically in virt-dma instead of static allocated as before. I'll > > make another uart patch into my next version patchset. > Yes, I see the same lockdep splat on my system. Though I'm not sure > if > this is really the root cause of the issue I see. > > I'm getting timeouts for a serdev attached device and I don't think > this system ever enters memory reclaim, so the issue reported by > lockdep seems to be a mostly theoretical on this system. But lets see > how far I get when you fixed this issue, maybe the real bug is hiding > behind this one. > > Regards, > Lucas
linux-next: Tree for Jun 14
Hi all, Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180613: The cifs tree gained a conflict against Linus' tree. The fbdev tree gained a conflict against Linus' tree. The akpm-current tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 873 803 files changed, 16506 insertions(+), 11137 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (be779f03d563 Merge tag 'kbuild-v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (c90fca951e90 Merge tag 'powerpc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (60d061e34703 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (3bce593ac06b selftests: bpf: config: add config fragments) Merging ipsec/master (d6990976af7c vti6: fix PMTU caching and reporting on xmit) Merging netfilter/master (60d061e34703 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (3dc7c7badb75 IB/mlx4: Fix an error handling path in 'mlx4_ib_rereg_user_mr()') Merging sound-current/for-linus (d9d5ed1ad5d8 ALSA: usb-audio: Remove explicitly listed Mytek devices) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging tty.current/tty-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb.current/usb-linus (3ca24ce9ff76 Merge branch 'proc-cmdli
Re: [PATCH 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
Hi Peter,
On 13 June 2018 at 17:17, Baolin Wang wrote:
> Hi Peter,
>
> On 13 June 2018 at 16:53, Peter Meerwald-Stadler wrote:
>>
>>> From: Freeman Liu
>>
>> some comments below
>>
>>> The Spreadtrum SC27XX PMICs ADC controller contains 32 channels,
>>> which is used to sample voltages with 12 bits conversion.
>>>
>>> Signed-off-by: Freeman Liu
>>> Signed-off-by: Baolin Wang
>>> ---
>>> drivers/iio/adc/Kconfig | 10 +
>>> drivers/iio/adc/Makefile |1 +
>>> drivers/iio/adc/sc27xx_adc.c | 558
>>> ++
>>> 3 files changed, 569 insertions(+)
>>> create mode 100644 drivers/iio/adc/sc27xx_adc.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 9da7907..985b73e 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -621,6 +621,16 @@ config ROCKCHIP_SARADC
>>> To compile this driver as a module, choose M here: the
>>> module will be called rockchip_saradc.
>>>
>>> +config SC27XX_ADC
>>> + tristate "Spreadtrum SC27xx series PMICs ADC"
>>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>>> + help
>>> + Say yes here to build support for the integrated ADC inside the
>>> + Spreadtrum SC27xx series PMICs.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called sc27xx_adc.
>>> +
>>> config SPEAR_ADC
>>> tristate "ST SPEAr ADC"
>>> depends on PLAT_SPEAR || COMPILE_TEST
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 28a9423..03db7b5 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -59,6 +59,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>> obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-pm8xxx-xoadc.o
>>> obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>> +obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
>>> obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
>>> obj-$(CONFIG_STX104) += stx104.o
>>> obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
>>> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
>>> new file mode 100644
>>> index 000..d74310a
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/sc27xx_adc.c
>>> @@ -0,0 +1,558 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* PMIC global registers definition */
>>> +#define SC27XX_MODULE_EN 0xc08
>>> +#define SC27XX_MODULE_ADC_EN BIT(5)
>>> +#define SC27XX_ARM_CLK_EN0xc10
>>> +#define SC27XX_CLK_ADC_ENBIT(5)
>>> +#define SC27XX_CLK_ADC_CLK_ENBIT(6)
>>> +
>>> +/* ADC controller registers definition */
>>> +#define SC27XX_ADC_CTL 0x0
>>> +#define SC27XX_ADC_CH_CFG0x4
>>> +#define SC27XX_ADC_DATA 0x4c
>>> +#define SC27XX_ADC_INT_EN0x50
>>> +#define SC27XX_ADC_INT_CLR 0x54
>>> +#define SC27XX_ADC_INT_STS 0x58
>>> +#define SC27XX_ADC_INT_RAW 0x5c
>>> +
>>> +/* Bits and mask definition for SC27XX_ADC_CTL register */
>>> +#define SC27XX_ADC_ENBIT(0)
>>> +#define SC27XX_ADC_CHN_RUN BIT(1)
>>> +#define SC27XX_ADC_12BIT_MODEBIT(2)
>>> +#define SC27XX_ADC_RUN_NUM_MASK GENMASK(7, 4)
>>> +#define SC27XX_ADC_RUN_NUM_SHIFT 4
>>> +
>>> +/* Bits and mask definition for SC27XX_ADC_CH_CFG register */
>>> +#define SC27XX_ADC_CHN_ID_MASK GENMASK(4, 0)
>>> +#define SC27XX_ADC_SCALE_MASKGENMASK(10, 8)
>>> +#define SC27XX_ADC_SCALE_SHIFT 8
>>> +
>>> +/* Bits definitions for SC27XX_ADC_INT_EN registers */
>>> +#define SC27XX_ADC_IRQ_ENBIT(0)
>>> +
>>> +/* Bits definitions for SC27XX_ADC_INT_CLR registers */
>>> +#define SC27XX_ADC_IRQ_CLR BIT(0)
>>> +
>>> +/* Mask definition for SC27XX_ADC_DATA register */
>>> +#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
>>> +
>>> +/* Timeout (ms) for the trylock of hardware spinlocks */
>>> +#define SC27XX_ADC_HWLOCK_TIMEOUT5000
>>> +
>>> +/* Maximum ADC channel number */
>>> +#define SC27XX_ADC_CHANNEL_MAX 32
>>> +
>>> +/* ADC voltage ratio definition */
>>> +#define SC27XX_VOLT_RATIO(n, d) \
>>> + (((n) << SC27XX_RATIO_NUMERATOR_OFFSET) | (d))
>>> +#define SC27XX_RATIO_NUMERATOR_OFFSET16
>>> +#define SC27XX_RATIO_DENOMINATOR_MASKGENMASK(15, 0)
>>> +
>>> +/* Covert ADC values to voltage values */
>>
>> Convert
>
> Sorry for typo and will fix in next version.
>
>>
>>> +#define SC27XX_ADC_TO_VOLTAGE(volt0, volt1, adc0, adc1, value) \
>>
>> I'd rather define a function than a macro for this
>
> Sure.
>
>>
>>> + ({ \
>>> +
Re: [PATCH 08/11] staging: lustre: obdclass: move linux/linux-foo.c to foo.c
> As lustre is now linux-only, having this linux sub-directory
> with files named "linux-something" is just noise. Move them
> to a more friendly name.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> drivers/staging/lustre/lustre/obdclass/Makefile|2
> .../lustre/lustre/obdclass/linux/linux-module.c| 514
>
> .../lustre/lustre/obdclass/linux/linux-sysctl.c| 162 --
> drivers/staging/lustre/lustre/obdclass/module.c| 514
>
> drivers/staging/lustre/lustre/obdclass/sysctl.c| 162 ++
> 5 files changed, 677 insertions(+), 677 deletions(-)
> delete mode 100644
> drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> delete mode 100644
> drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
> create mode 100644 drivers/staging/lustre/lustre/obdclass/module.c
> create mode 100644 drivers/staging/lustre/lustre/obdclass/sysctl.c
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/Makefile
> b/drivers/staging/lustre/lustre/obdclass/Makefile
> index e3fa9acff4c4..e36ba2167d10 100644
> --- a/drivers/staging/lustre/lustre/obdclass/Makefile
> +++ b/drivers/staging/lustre/lustre/obdclass/Makefile
> @@ -4,7 +4,7 @@ subdir-ccflags-y +=
> -I$(srctree)/drivers/staging/lustre/lustre/include
>
> obj-$(CONFIG_LUSTRE_FS) += obdclass.o
>
> -obdclass-y := linux/linux-module.o linux/linux-sysctl.o \
> +obdclass-y := module.o sysctl.o \
> llog.o llog_cat.o llog_obd.o llog_swab.o class_obd.o debug.o \
> genops.o uuid.o lprocfs_status.o lprocfs_counters.o \
> lustre_handles.o lustre_peer.o statfs_pack.o linkea.o \
> diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> deleted file mode 100644
> index 9c800580053b..
> --- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> +++ /dev/null
> @@ -1,514 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * GPL HEADER START
> - *
> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 only,
> - * as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * General Public License version 2 for more details (a copy is included
> - * in the LICENSE file that accompanied this code).
> - *
> - * You should have received a copy of the GNU General Public License
> - * version 2 along with this program; If not, see
> - * http://www.gnu.org/licenses/gpl-2.0.html
> - *
> - * GPL HEADER END
> - */
> -/*
> - * Copyright (c) 2007, 2010, Oracle and/or its affiliates. All rights
> reserved.
> - * Use is subject to license terms.
> - *
> - * Copyright (c) 2011, 2012, Intel Corporation.
> - */
> -/*
> - * This file is part of Lustre, http://www.lustre.org/
> - * Lustre is a trademark of Sun Microsystems, Inc.
> - *
> - * lustre/obdclass/linux/linux-module.c
> - *
> - * Object Devices Class Driver
> - * These are the only exported functions, they provide some generic
> - * infrastructure for managing object devices
> - */
> -
> -#define DEBUG_SUBSYSTEM S_CLASS
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#define OBD_MAX_IOCTL_BUFFER 8192
> -
> -static int obd_ioctl_is_invalid(struct obd_ioctl_data *data)
> -{
> - if (data->ioc_len > BIT(30)) {
> - CERROR("OBD ioctl: ioc_len larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen1 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen1 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen2 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen2 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen3 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen3 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen4 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen4 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inlbuf1 && data->ioc_inllen1 == 0) {
> - CERROR("OBD ioctl: inlbuf1 pointer but 0 length\n");
> - return 1;
> - }
> -
> - if (data->ioc_inlbuf2 && data->ioc_inllen2 == 0) {
> - CERROR("OBD ioctl: inlbuf2 pointer but 0 length\n");
> - retur
Re: [PATCH 09/11] staging: lustre: discard WIRE_ATTR
> This macro adds nothing of value, and make the code harder
> to read for new readers.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> .../staging/lustre/include/linux/lnet/socklnd.h|8 ++-
> .../lustre/include/uapi/linux/lnet/lnet-types.h| 28 +---
> .../lustre/include/uapi/linux/lnet/lnetst.h|4 +-
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 22 +
> drivers/staging/lustre/lnet/selftest/rpc.h | 48
> ++--
> 5 files changed, 54 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/lnet/socklnd.h
> b/drivers/staging/lustre/include/linux/lnet/socklnd.h
> index 6bd1bca190a3..9f69257e000b 100644
> --- a/drivers/staging/lustre/include/linux/lnet/socklnd.h
> +++ b/drivers/staging/lustre/include/linux/lnet/socklnd.h
> @@ -50,7 +50,7 @@ struct ksock_hello_msg {
> __u32 kshm_ctype; /* connection type */
> __u32 kshm_nips; /* # IP addrs */
> __u32 kshm_ips[0];/* IP addrs */
> -} WIRE_ATTR;
> +} __packed;
>
> struct ksock_lnet_msg {
> struct lnet_hdr ksnm_hdr; /* lnet hdr */
> @@ -61,7 +61,7 @@ struct ksock_lnet_msg {
>* structure definitions. lnet payload will be stored just after
>* the body of structure ksock_lnet_msg_t
>*/
> -} WIRE_ATTR;
> +} __packed;
>
> struct ksock_msg {
> __u32 ksm_type; /* type of socklnd message */
> @@ -71,8 +71,8 @@ struct ksock_msg {
> struct ksock_lnet_msg lnetmsg; /* lnet message, it's empty if
> * it's NOOP
> */
> - } WIRE_ATTR ksm_u;
> -} WIRE_ATTR;
> + } __packed ksm_u;
> +} __packed;
>
> #define KSOCK_MSG_NOOP 0xC0/* ksm_u empty */
> #define KSOCK_MSG_LNET 0xC1/* lnet msg */
> diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> index 1be9b7aa7326..f97e7d9d881f 100644
> --- a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> +++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> @@ -112,14 +112,12 @@ static inline __u32 LNET_MKNET(__u32 type, __u32 num)
> return (type << 16) | num;
> }
>
> -#define WIRE_ATTR__packed
> -
> /* Packed version of lnet_process_id to transfer via network */
> struct lnet_process_id_packed {
> /* node id / process id */
> lnet_nid_t nid;
> lnet_pid_t pid;
> -} WIRE_ATTR;
> +} __packed;
>
> /*
> * The wire handle's interface cookie only matches one network interface in
> @@ -130,7 +128,7 @@ struct lnet_process_id_packed {
> struct lnet_handle_wire {
> __u64 wh_interface_cookie;
> __u64 wh_object_cookie;
> -} WIRE_ATTR;
> +} __packed;
>
> enum lnet_msg_type {
> LNET_MSG_ACK = 0,
> @@ -150,7 +148,7 @@ struct lnet_ack {
> struct lnet_handle_wire dst_wmd;
> __u64 match_bits;
> __u32 mlength;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_put {
> struct lnet_handle_wire ack_wmd;
> @@ -158,7 +156,7 @@ struct lnet_put {
> __u64 hdr_data;
> __u32 ptl_index;
> __u32 offset;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_get {
> struct lnet_handle_wire return_wmd;
> @@ -166,16 +164,16 @@ struct lnet_get {
> __u32 ptl_index;
> __u32 src_offset;
> __u32 sink_length;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_reply {
> struct lnet_handle_wire dst_wmd;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_hello {
> __u64 incarnation;
> __u32 type;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_hdr {
> lnet_nid_t dest_nid;
> @@ -192,7 +190,7 @@ struct lnet_hdr {
> struct lnet_reply reply;
> struct lnet_hello hello;
> } msg;
> -} WIRE_ATTR;
> +} __packed;
>
> /*
> * A HELLO message contains a magic number and protocol version
> @@ -208,7 +206,7 @@ struct lnet_magicversion {
> __u32 magic; /* LNET_PROTO_TCP_MAGIC */
> __u16 version_major; /* increment on incompatible change */
> __u16 version_minor; /* increment on compatible change */
> -} WIRE_ATTR;
> +} __packed;
>
> /* PROTO MAGIC for LNDs */
> #define LNET_PROTO_IB_MAGIC 0x0be91b91
> @@ -232,7 +230,7 @@ struct lnet_acceptor_connreq {
> __u32 acr_magic; /* PTL_ACCEPTOR_PROTO_MAGIC */
> __u32 acr_version;/* protocol version */
> __u64 acr_nid;/* target NID */
> -} WIRE_ATTR;
> +} __packed;
>
> #define LNET_PROTO_ACCEPTOR_VERSION 1
>
> @@ -240,7 +238,7 @@ struct lnet_ni_status {
> lnet_nid
Re: [PATCH 07/11] staging: lustre: fold lprocfs_call_handler functionality into lnet_debugfs_*
> The calling convention for ->proc_handler is rather clumsy,
> as a comment in fs/procfs/proc_sysctl.c confirms.
> lustre has copied this convention to lnet_debugfs_{read,write},
> and then provided a wrapper for handlers - lprocfs_call_handler -
> to work around the clumsiness.
>
> It is cleaner to just fold the functionality of lprocfs_call_handler()
> into lnet_debugfs_* and let them call the final handler directly.
>
> If these files were ever moved to /proc/sys (which seems unlikely) the
> handling in fs/procfs/proc_sysctl.c would need to be fixed to, but
> that would not be a bad thing.
>
> So modify all the functions that did use the wrapper to not need it
> now that a more sane calling convention is available.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> .../staging/lustre/include/linux/libcfs/libcfs.h |4 -
> drivers/staging/lustre/lnet/libcfs/module.c| 84
> +++-
> drivers/staging/lustre/lnet/lnet/router_proc.c | 41 +++---
> 3 files changed, 41 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> index edc7ed0dcb94..7ac609328256 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> @@ -57,10 +57,6 @@ int libcfs_setup(void);
> extern struct workqueue_struct *cfs_rehash_wq;
>
> void lustre_insert_debugfs(struct ctl_table *table);
> -int lprocfs_call_handler(void *data, int write, loff_t *ppos,
> - void __user *buffer, size_t *lenp,
> - int (*handler)(void *data, int write, loff_t pos,
> - void __user *buffer, int len));
>
> /*
> * Memory
> diff --git a/drivers/staging/lustre/lnet/libcfs/module.c
> b/drivers/staging/lustre/lnet/libcfs/module.c
> index 5dc7de9e6478..02c404c6738e 100644
> --- a/drivers/staging/lustre/lnet/libcfs/module.c
> +++ b/drivers/staging/lustre/lnet/libcfs/module.c
> @@ -290,33 +290,15 @@ static struct miscdevice libcfs_dev = {
>
> static int libcfs_dev_registered;
>
> -int lprocfs_call_handler(void *data, int write, loff_t *ppos,
> - void __user *buffer, size_t *lenp,
> - int (*handler)(void *data, int write, loff_t pos,
> - void __user *buffer, int len))
> -{
> - int rc = handler(data, write, *ppos, buffer, *lenp);
> -
> - if (rc < 0)
> - return rc;
> -
> - if (write) {
> - *ppos += *lenp;
> - } else {
> - *lenp = rc;
> - *ppos += rc;
> - }
> - return 0;
> -}
> -EXPORT_SYMBOL(lprocfs_call_handler);
> -
> -static int __proc_dobitmasks(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> +static int proc_dobitmasks(struct ctl_table *table, int write,
> +void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> const int tmpstrlen = 512;
> char *tmpstr;
> int rc;
> - unsigned int *mask = data;
> + size_t nob = *lenp;
> + loff_t pos = *ppos;
> + unsigned int *mask = table->data;
> int is_subsys = (mask == &libcfs_subsystem_debug) ? 1 : 0;
> int is_printk = (mask == &libcfs_printk) ? 1 : 0;
>
> @@ -351,32 +333,23 @@ static int __proc_dobitmasks(void *data, int write,
> return rc;
> }
>
> -static int proc_dobitmasks(struct ctl_table *table, int write,
> -void __user *buffer, size_t *lenp, loff_t *ppos)
> +static int proc_dump_kernel(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
> - __proc_dobitmasks);
> -}
> + size_t nob = *lenp;
>
> -static int __proc_dump_kernel(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> -{
> if (!write)
> return 0;
>
> return cfs_trace_dump_debug_buffer_usrstr(buffer, nob);
> }
>
> -static int proc_dump_kernel(struct ctl_table *table, int write,
> +static int proc_daemon_file(struct ctl_table *table, int write,
> void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
> - __proc_dump_kernel);
> -}
> + size_t nob = *lenp;
> + loff_t pos = *ppos;
>
> -static int __proc_daemon_file(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> -{
> if (!write) {
> int len = strlen(cfs_tracefile);
>
> @@ -390,13 +363,6 @@ static int __proc_daemon_file(void *data, int write,
> return cfs_trace_daemon_command_usrstr(buffer, nob);
> }
>
> -static int proc_daemon_fi
Re: [PATCH 4.4 00/24] 4.4.137-stable review
On 13 June 2018 at 18:08, Rafael David Tinoco
wrote:
> On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> wrote:
>> On Wed, Jun 13, 2018 at 05:47:49PM -0300, Rafael Tinoco wrote:
>>> Results from Linaro’s test farm.
>>> Regressions detected.
>>>
>>> NOTE:
>>>
>>> 1) LTP vma03 test (cve-2011-2496) broken on v4.4-137-rc1 because of:
>>>
>>> 6ea1dc96a03a mmap: relax file size limit for regular files
>>> bd2f9ce5bacb mmap: introduce sane default mmap limits
>>>
>>>discussion:
>>>
>>> https://github.com/linux-test-project/ltp/issues/341
>>>
>>>mainline commit (v4.13-rc7):
>>>
>>> 0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
>>>
>>>should be backported to 4.4.138-rc2 and fixes the issue.
>>
>> Really? That commit says it fixes c2a9737f45e2 ("vfs,mm: fix a dead
>> loop in truncate_inode_pages_range()") which is not in 4.4.y at all.
>>
>> Did you test this out?
>
> Yes, the LTP contains the tests (last comment is the final test for
> arm32, right before Jan tests i686).
>
> Fixing MAX_LFS_FILESIZE fixes the new limit for mmap() brought by
> those 2 commits (file_mmap_size_max()).
> offset tested by the LTP test is 0xfffe000.
> file_mmap_size_max gives: 0x000 as max value, but only after
> the mentioned patch.
>
> Original intent for this fix was other though.
To clarify this a bit further.
The LTP CVE test is breaking in the first call to mmap(), even before
trying to remap and test the security issue. That start happening in
this round because of those mmap() changes and the offset used in the
LTP test. Linus changed limit checks and made them to be related to
MAX_LFS_FILESIZE. Unfortunately, in 4.4 stable, we were missing the
fix for MAX_LFS_FILESIZE (which before commit 0cc3b0ec23ce was less
than the REAL 32 bit limit).
Commit 0cc3b0ec23ce was made because an user noticed the FS limit not
being what it should be. In our case, the 4.4 stable kernel, we are
facing this 32 bit lower limit (than the real 32 bit real limit),
because of the LTP CVE test, so we need this fix to have the real 32
bit limit set for that macro (mmap limits did not use that macro
before).
I have tested in arm32 and Jan Stancek, who first responded to LTP
issue, has tested this in i686 and both worked after that patch was
included to v4.4-137-rc1 (my last test was even with 4.4.138-rc1).
Hope that helps a bit.
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/ocfs2/journal.c
between commit:
6396bb221514 ("treewide: kzalloc() -> kcalloc()")
from Linus' tree and commits:
18dc5b7810ff ("ocfs2: without quota support, avoid calling quota recovery")
aa935a9c155b
("ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes")
from the akpm-current tree.
I fixed it up (the latter akpm-current commit also did the kzalloc to
kcalloc conversion, so I just used that version) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpk9bBQ_v7M9.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/binfmt_elf.c
between commit:
42bc47b35320 ("treewide: Use array_size() in vmalloc()")
from Linus' tree and commit:
1d5239111f52 ("coredump: fix spam with zero VMA process")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/binfmt_elf.c
index 070b6184642d,8676bb01b5a9..
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@@ -2294,8 -2294,8 +2294,8 @@@ static int elf_core_dump(struct coredum
if (segs - 1 > ULONG_MAX / sizeof(*vma_filesz))
goto end_coredump;
- vma_filesz = vmalloc(array_size(sizeof(*vma_filesz), (segs - 1)));
- if (!vma_filesz)
- vma_filesz = kvmalloc((segs - 1) * sizeof(*vma_filesz), GFP_KERNEL);
++ vma_filesz = kvmalloc(array_size(sizeof(*vma_filesz), (segs - 1)),
GFP_KERNEL);
+ if (ZERO_OR_NULL_PTR(vma_filesz))
goto end_coredump;
for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
pgpx94IIfqTpX.pgp
Description: OpenPGP digital signature
[PATCH] selftests: kselftest_harness: return Kselftest Skip code for skipped tests
When a test is skipped because of unmet dependencies and/or unsupported
configuration, kselftest_harness exits with error which is treated as a
fail by the Kselftest framework. This leads to false negative result even
when the test could not be run.
Change it to return kselftest skip code when a test gets skipped to
clearly report that the test could not be run. This change add skip
handling to kselftest_harness with minimal changes adding a new skipped
field to struct __test_metadata and using it to recognize KSFT_SKIP exit
from the test function (t->fn) to __run_test() to the test_harness_run()
to return the right skip code to Kselftest framework.
Kselftest framework SKIP code is 4 and the framework prints appropriate
messages to indicate that the test is skipped.
This change is tested on uevent test and the results are as follows:
Before:
TAP version 13
selftests: uevent: uevent_filtering
[==] Running 1 tests from 1 test cases.
[ RUN ] global.uevent_filtering
uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
root privileges. Skipping test
global.uevent_filtering: Test skipped at step #4
[ FAIL ] global.uevent_filtering
[==] 0 / 1 tests passed.
[ FAILED ]
not ok 1..1 selftests: uevent: uevent_filtering [FAIL]
After:
TAP version 13
selftests: uevent: uevent_filtering
[==] Running 1 tests from 1 test cases.
[ RUN ] global.uevent_filtering
uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
root privileges. Skipping test
global.uevent_filtering: Test skipped at step #4
[ SKIP ] global.uevent_filtering
not ok 1..1 selftests: uevent: uevent_filtering [SKIP]
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/testing/selftests/kselftest_harness.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kselftest_harness.h
b/tools/testing/selftests/kselftest_harness.h
index 6ae3730c4ee3..7af9ab97b367 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -631,6 +631,7 @@ struct __test_metadata {
void (*fn)(struct __test_metadata *);
int termsig;
int passed;
+ int skipped;
int trigger; /* extra handler after the evaluation */
__u8 step;
bool no_print; /* manual trigger when TH_LOG_STREAM is not available */
@@ -694,6 +695,7 @@ void __run_test(struct __test_metadata *t)
int status;
t->passed = 1;
+ t->skipped = 0;
t->trigger = 0;
printf("[ RUN ] %s\n", t->name);
child_pid = fork();
@@ -716,9 +718,12 @@ void __run_test(struct __test_metadata *t)
t->name,
WEXITSTATUS(status));
} else if (!t->passed) {
+ if (WEXITSTATUS(status) == KSFT_SKIP)
+ t->skipped = 1;
fprintf(TH_LOG_STREAM,
- "%s: Test failed at step #%d\n",
+ "%s: Test %s at step #%d\n",
t->name,
+ (t->skipped ? "skipped" : "failed"),
WEXITSTATUS(status));
}
} else if (WIFSIGNALED(status)) {
@@ -743,7 +748,11 @@ void __run_test(struct __test_metadata *t)
status);
}
}
- printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
+ if (t->skipped)
+ printf("[ %4s ] %s\n", "SKIP", t->name);
+ else
+ printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"),
+ t->name);
}
static int test_harness_run(int __attribute__((unused)) argc,
@@ -762,6 +771,8 @@ static int test_harness_run(int __attribute__((unused))
argc,
__run_test(t);
if (t->passed)
pass_count++;
+ else if (t->skipped)
+ return KSFT_SKIP;
else
ret = 1;
}
--
2.17.0
Re: [PATCH 0/3] sched/swait: Convert to full exclusive mode
On Tue, Jun 12, 2018 at 10:34:49AM +0200, Peter Zijlstra wrote: > As mentioned by Linus, swait is exclusive mode and had better behave like it > and be named like it. > > Make it so. Cool! When I tried testing it on x86 against recent mainline, I got: "WARNING: WARNING: Bad or missing .orc_unwind table. Disabling unwinder." But when I tested on recent mainline without your patches: 4597fcff0704 "Merge tag 'for-4.18/dm-changes-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm" I get the same warning. Trying again on today's mainline, but in the meantime, is anyone else seeing this? Thanx, Paul > --- > arch/mips/kvm/mips.c | 4 ++-- > arch/powerpc/kvm/book3s_hv.c | 6 +++--- > arch/s390/kvm/interrupt.c| 2 +- > arch/x86/kernel/kvm.c| 4 ++-- > arch/x86/kvm/lapic.c | 2 +- > include/linux/swait.h| 36 ++-- > kernel/power/suspend.c | 4 ++-- > kernel/rcu/srcutiny.c| 4 ++-- > kernel/rcu/tree.c| 8 > kernel/rcu/tree_exp.h| 4 ++-- > kernel/rcu/tree_plugin.h | 12 ++-- > kernel/sched/swait.c | 32 ++-- > virt/kvm/arm/arm.c | 4 ++-- > virt/kvm/arm/psci.c | 2 +- > virt/kvm/async_pf.c | 2 +- > virt/kvm/kvm_main.c | 4 ++-- > 16 files changed, 71 insertions(+), 59 deletions(-) > >
Re: Bug with dwc3 id detect and regulators
Hi Roger, On 2018년 06월 11일 17:53, Roger Quadros wrote: > Chanwoo, > > On 11/06/18 11:33, H. Nikolaus Schaller wrote: >> Hi Tony, >> another bug... >> >> [ 174.540313] BUG: scheduling while atomic: kworker/0:4/1327/0x0002 >> [ 174.547353] Modules linked in: omapdrm drm_kms_helper syscopyarea >> sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks bnep >> bluetooth ecdh_generic usb_f_ecm g_ether usb_f_rndis u_ether libcomposite >> configfs ipv6 arc4 wl18xx wlcore mac80211 panel_boe_w677l >> snd_soc_omap_hdmi_audio snd_soc_dmic cfg80211 dwc3 snd_soc_omap_abe_twl6040 >> snd_soc_twl6040 leds_gpio wwan_on_off connector_hdmi omapdss >> encoder_tpd12s015 cec pwm_omap_dmtimer omapdss_base pwm_bl >> generic_adc_battery ehci_omap wlcore_sdio dwc3_omap bmp280_spi >> snd_soc_ts3a227e crtouch_mt leds_is31fl319x tsc2007 bq2429x_charger >> bq27xxx_battery_i2c bq27xxx_battery ina2xx as5013 tca8418_keypad >> twl6040_vibra palmas_pwrbutton gpio_twl6040 palmas_gpadc usb3503 bmp280_i2c >> bmc150_accel_i2c w2cbw003_bluetooth bmc150_magn_i2c bmp280 bmc150_accel_core >> [ 174.624601] bmc150_magn bno055 industrialio_triggered_buffer kfifo_buf >> industrialio snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap >> snd_pcm_dmaengine [last unloaded: syscopyarea] >> [ 174.642327] CPU: 0 PID: 1327 Comm: kworker/0:4 Tainted: GW >> 4.17.0-letux+ #2408 >> [ 174.651541] Hardware name: Generic OMAP5 (Flattened Device Tree) >> [ 174.658004] Workqueue: events_power_efficient palmas_gpio_id_detect >> [ 174.664780] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 174.673109] [] (show_stack) from [] >> (dump_stack+0x7c/0x9c) >> [ 174.680881] [] (dump_stack) from [] >> (__schedule_bug+0x60/0x84) >> [ 174.689006] [] (__schedule_bug) from [] >> (__schedule+0x50/0x694) >> [ 174.697217] [] (__schedule) from [] >> (schedule+0xb0/0xcc) >> [ 174.704790] [] (schedule) from [] >> (schedule_timeout+0x354/0x3d4) >> [ 174.713100] [] (schedule_timeout) from [] >> (wait_for_common+0x118/0x158) >> [ 174.722064] [] (wait_for_common) from [] >> (omap_i2c_xfer+0x354/0x48c) >> [ 174.730749] [] (omap_i2c_xfer) from [] >> (__i2c_transfer+0x238/0x550) >> [ 174.739350] [] (__i2c_transfer) from [] >> (i2c_transfer+0x84/0xb4) >> [ 174.747685] [] (i2c_transfer) from [] >> (bq24296_i2c_reg8_read.constprop.8+0x54/0x64 [bq2429x_charger]) >> [ 174.759465] [] (bq24296_i2c_reg8_read.constprop.8 >> [bq2429x_charger]) from [] (bq24296_update_reg+0x28/0xf8 >> [bq2429x_charger]) >> [ 174.773437] [] (bq24296_update_reg [bq2429x_charger]) from >> [] (_regulator_do_disable+0x100/0x238) >> [ 174.784804] [] (_regulator_do_disable) from [] >> (_regulator_disable+0x88/0x120) >> [ 174.794404] [] (_regulator_disable) from [] >> (regulator_disable+0x30/0x60) >> [ 174.803556] [] (regulator_disable) from [] >> (dwc3_omap_set_mailbox+0x84/0xf8 [dwc3_omap]) >> [ 174.814124] [] (dwc3_omap_set_mailbox [dwc3_omap]) from >> [] (dwc3_omap_id_notifier+0x14/0x1c [dwc3_omap]) >> [ 174.826149] [] (dwc3_omap_id_notifier [dwc3_omap]) from >> [] (notifier_call_chain+0x40/0x68) >> [ 174.836867] [] (notifier_call_chain) from [] >> (raw_notifier_call_chain+0x14/0x1c) >> [ 174.846661] [] (raw_notifier_call_chain) from [] >> (extcon_sync+0x54/0x19c) >> [ 174.855804] [] (extcon_sync) from [] >> (process_one_work+0x244/0x464) >> [ 174.864386] [] (process_one_work) from [] >> (worker_thread+0x2c0/0x3ec) >> [ 174.873156] [] (worker_thread) from [] >> (kthread+0x134/0x150) >> [ 174.881087] [] (kthread) from [] >> (ret_from_fork+0x14/0x2c) >> >> It turns out that extcon_sync() holds a spinlock while sending its notifiers >> and this >> is ending up in our regulator.en/disable() which wants to use blocking i2c. >> >> Do you see similar things on the OMAP5EVM when using OTG mode? >> The Palmas SMPS10 is also handled through i2c. Or is this magically hidden >> by regmap? >> >> Well, as a workaround, I can make the regulator.en/disable() in the bq2429x >> driver >> just trigger a worker, but IMHO it is not expected for regulator ops to be >> spinlock safe. >> >> So I think extcon should not spinlock (which might be against the extcon >> design) or > > I think this something that should be addressed in the Extcon layer. > Do you really need to call the raw_notifier_call_chain() function with > spinlock held in extcon_sync()? > if yes why? To reduce the latency of notification is important of extcon. So, extcon used the spinlock before calling the notifier_call_chain to prevent the scheduled out for a moment. Also, the notifier_call calls the registered notifier function sequentially. It means that if some registered notifier function spends a lot of time, the next registered notifier might receive the notification with a delay. So, extcon used the spinlock. Unitl now, But, as you commented and previously, sometimes it caused the similar issues. (To fix similar issues, the consumer device used the w
Re: [PATCH v6 18/29] fpga: dfl: add fpga manager platform driver for FME
Hi Hao, small nit below, looks good otherwise. On Tue, Jun 12, 2018 at 06:10:32PM +0800, Wu Hao wrote: > This patch adds fpga manager driver for FPGA Management Engine (FME). It > implements fpga_manager_ops for FPGA Partial Reconfiguration function. > > Signed-off-by: Tim Whisonant > Signed-off-by: Enno Luebbers > Signed-off-by: Shiva Rao > Signed-off-by: Christopher Rauer > Signed-off-by: Kang Luwei > Signed-off-by: Xiao Guangrong > Signed-off-by: Wu Hao > Acked-by: Alan Tull > --- > v3: rename driver to dfl-fpga-fme-mgr > implemented status callback for fpga manager > rebased due to fpga api changes > v4: rename to dfl-fme-mgr, and fix SPDX license issue > add pr_credit comments and improve dev_err message > remove interface_id sysfs interface > include dfl-fme-pr.h instead of dfl.h > v5: move related register definition from dfl-fme-pr.h to dfl-fme-mgr.c > use mapped ioaddr passed via pdata for register access. > rebase due to fpga manager API changes. > include header file for readq/writeq. > v6: rebase, fix copyright time and add Acked-by from Alan. > --- > drivers/fpga/Kconfig | 6 + > drivers/fpga/Makefile | 1 + > drivers/fpga/dfl-fme-mgr.c | 334 > + > 3 files changed, 341 insertions(+) > create mode 100644 drivers/fpga/dfl-fme-mgr.c > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index 45e9220..ca97f3c 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -156,6 +156,12 @@ config FPGA_DFL_FME > FPGA platform level management features. There shall be 1 FME > per DFL based FPGA device. > > +config FPGA_DFL_FME_MGR > + tristate "FPGA DFL FME Manager Driver" > + depends on FPGA_DFL_FME > + help > + Say Y to enable FPGA Manager driver for FPGA Management Engine. > + > config FPGA_DFL_PCI > tristate "FPGA DFL PCIe Device Driver" > depends on PCI && FPGA_DFL > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > index fd334d40..23f41b0 100644 > --- a/drivers/fpga/Makefile > +++ b/drivers/fpga/Makefile > @@ -32,6 +32,7 @@ obj-$(CONFIG_OF_FPGA_REGION)+= > of-fpga-region.o > # FPGA Device Feature List Support > obj-$(CONFIG_FPGA_DFL) += dfl.o > obj-$(CONFIG_FPGA_DFL_FME) += dfl-fme.o > +obj-$(CONFIG_FPGA_DFL_FME_MGR) += dfl-fme-mgr.o > > dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c > new file mode 100644 > index 000..be0060a > --- /dev/null > +++ b/drivers/fpga/dfl-fme-mgr.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * FPGA Manager Driver for FPGA Management Engine (FME) > + * > + * Copyright (C) 2017-2018 Intel Corporation, Inc. > + * > + * Authors: > + * Kang Luwei > + * Xiao Guangrong > + * Wu Hao > + * Joseph Grecco > + * Enno Luebbers > + * Tim Whisonant > + * Ananda Ravuri > + * Christopher Rauer > + * Henry Mitchel > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include "dfl-fme-pr.h" > + > +/* FME Partial Reconfiguration Sub Feature Register Set */ > +#define FME_PR_DFH 0x0 > +#define FME_PR_CTRL 0x8 > +#define FME_PR_STS 0x10 > +#define FME_PR_DATA 0x18 > +#define FME_PR_ERR 0x20 > +#define FME_PR_INTFC_ID_H0xA8 > +#define FME_PR_INTFC_ID_L0xB0 > + > +/* FME PR Control Register Bitfield */ > +#define FME_PR_CTRL_PR_RST BIT_ULL(0) /* Reset PR engine */ > +#define FME_PR_CTRL_PR_RSTACKBIT_ULL(4) /* Ack for PR engine reset > */ > +#define FME_PR_CTRL_PR_RGN_IDGENMASK_ULL(9, 7) /* PR Region ID > */ > +#define FME_PR_CTRL_PR_START BIT_ULL(12) /* Start to request PR service */ > +#define FME_PR_CTRL_PR_COMPLETE BIT_ULL(13) /* PR data push completion > */ > + > +/* FME PR Status Register Bitfield */ > +/* Number of available entries in HW queue inside the PR engine. */ > +#define FME_PR_STS_PR_CREDIT GENMASK_ULL(8, 0) > +#define FME_PR_STS_PR_STSBIT_ULL(16) /* PR operation status */ > +#define FME_PR_STS_PR_STS_IDLE 0 > +#define FME_PR_STS_PR_CTRLR_STS GENMASK_ULL(22, 20) /* Controller > status */ > +#define FME_PR_STS_PR_HOST_STS GENMASK_ULL(27, 24) /* PR host > status */ > + > +/* FME PR Data Register Bitfield */ > +/* PR data from the raw-binary file. */ > +#define FME_PR_DATA_PR_DATA_RAW GENMASK_ULL(32, 0) > + > +/* FME PR Error Register */ > +/* PR Operation errors detected. */ > +#define FME_PR_ERR_OPERATION_ERR BIT_ULL(0) > +/* CRC error detected. */ > +#define FME_PR_ERR_CRC_ERR BIT_ULL(1) > +/* Incompatible PR bitstream detected. */ > +#define FME_PR_ERR_INCOMPATIBLE_BS BIT_ULL(2) > +/* PR data push protocol violated. */ > +#define FME_PR_ERR_PROTOCOL_ERR BIT_ULL(3) > +/* PR data fifo overflow error detected */ > +#defin
Re: [PATCH v6 1/3] phy: Update PHY power control sequence
On 2018-06-12 19:34, Vivek Gautam wrote:
Hi Can,
On 5/29/2018 10:07 AM, Can Guo wrote:
All PHYs should be powered on before register configuration starts.
And
only PCIe PHYs need an extra power control before deasserts reset
state.
Signed-off-by: Can Guo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97ef942..f779b0f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -982,6 +982,8 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp
*qmp)
if (cfg->has_phy_com_ctrl)
qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
SW_PWRDN);
+ else
+ qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
No definition of 'pcs' in this function. You are doing that in the
second patch.
But, we should add this definition here.
Also instead of having the change like this:
+ struct qmp_phy *qphy = qmp->phys[0];
void __iomem *serdes = qmp->serdes;
+ void __iomem *pcs = qphy->pcs;
Let's pass 'struct qmp_phy' to qcom_qmp_phy_com_init(), and then get
'struct qcom_qmp' and 'void __iomem *pcs' from that.
So,
-static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
+static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
{
+ struct qcom_qmp *qmp = qphy->qmp;
const struct qmp_phy_cfg *cfg = qmp->cfg;
void __iomem *serdes = qmp->serdes;
void __iomem *dp_com = qmp->dp_com;
+ void __iomem *pcs = qphy->pcs;
and
- ret = qcom_qmp_phy_com_init(qmp);
+ ret = qcom_qmp_phy_com_init(qphy);
That looks cleaner than extracting from the 0th phys.
BRs
Vivek
Sure Vivek
if (cfg->has_phy_dp_com_ctrl) {
qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
@@ -1127,7 +1129,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
* Pull out PHY from POWER DOWN state.
* This is active low enable signal to power-down PHY.
*/
- qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+ if (cfg->type == PHY_TYPE_PCIE)
+ qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
Re: [PATCH v6 17/29] fpga: dfl: fme: add partial reconfiguration sub feature support
Hi,
quick question for Alan inline below.
On Tue, Jun 12, 2018 at 06:10:31PM +0800, Wu Hao wrote:
> From: Kang Luwei
>
> Partial Reconfiguration (PR) is the most important function for FME. It
> allows reconfiguration for given Port/Accelerated Function Unit (AFU).
>
> It creates platform devices for fpga-mgr, fpga-regions and fpga-bridges,
> and invokes fpga-region's interface (fpga_region_program_fpga) for PR
> operation once PR request received via ioctl. Below user space interface
> is exposed by this sub feature.
>
> Ioctl interface:
> * DFL_FPGA_FME_PORT_PR
> Do partial reconfiguration per information from userspace, including
> target port(AFU), buffer size and address info. It returns error code
> to userspace if failed. For detailed PR error information, user needs
> to read fpga-mgr's status sysfs interface.
>
> Signed-off-by: Tim Whisonant
> Signed-off-by: Enno Luebbers
> Signed-off-by: Shiva Rao
> Signed-off-by: Christopher Rauer
> Signed-off-by: Kang Luwei
> Signed-off-by: Xiao Guangrong
> Signed-off-by: Wu Hao
> Acked-by: Alan Tull
> ---
> v2: moved the code to drivers/fpga folder as suggested by Alan Tull.
> switched to GPLv2 license.
> removed status from FPGA_FME_PORT_PR ioctl data structure.
> added platform devices creation for fpga-mgr/fpga-region/fpga-bridge.
> switched to fpga-region interface fpga_region_program_fpga for PR.
> fixed comments from Alan Tull on FPGA_MGR_PARTIAL_RECONFIG flag usage.
> fixed kbuild warnings.
> v3: rename driver files to dfl-fme-*.
> rebase due to fpga APIs change.
> replace bitfields.
> switch to fpga_cdev_find_port to find port device.
> v4: rebase and correct comments for some function.
> fix SPDX license issue.
> remove unnecessary input parameter for destroy_bridge/region function.
> add dfl-fme-pr.h for PR sub feature data structure and registers.
> v5: rebase due to DFL framework API naming changes.
> improve naming for IOCTL API, functions and data structure.
> defer finding port platform device to fme bridge.
> pass mapped ioaddr to fme manager via pdata.
> remove useless devm_kfree().
> v6: rebase, fix copyright time and improve function name.
> add Acked-by from Alan.
> ---
> drivers/fpga/Makefile | 2 +-
> drivers/fpga/dfl-fme-main.c | 43 +++-
> drivers/fpga/dfl-fme-pr.c | 474
> ++
> drivers/fpga/dfl-fme-pr.h | 84
> drivers/fpga/dfl-fme.h| 38
> include/uapi/linux/fpga-dfl.h | 28 +++
> 6 files changed, 667 insertions(+), 2 deletions(-)
> create mode 100644 drivers/fpga/dfl-fme-pr.c
> create mode 100644 drivers/fpga/dfl-fme-pr.h
> create mode 100644 drivers/fpga/dfl-fme.h
>
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index db11f34..fd334d40 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -33,7 +33,7 @@ obj-$(CONFIG_OF_FPGA_REGION)+=
> of-fpga-region.o
> obj-$(CONFIG_FPGA_DFL) += dfl.o
> obj-$(CONFIG_FPGA_DFL_FME) += dfl-fme.o
>
> -dfl-fme-objs := dfl-fme-main.o
> +dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
>
> # Drivers for FPGAs which implement DFL
> obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 889d669..7359804 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -19,6 +19,7 @@
> #include
>
> #include "dfl.h"
> +#include "dfl-fme.h"
>
> static ssize_t ports_num_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> @@ -113,6 +114,10 @@ static void fme_hdr_uinit(struct platform_device *pdev,
> .ops = &fme_hdr_ops,
> },
> {
> + .id = FME_FEATURE_ID_PR_MGMT,
> + .ops = &pr_mgmt_ops,
> + },
> + {
> .ops = NULL,
> },
> };
> @@ -187,6 +192,35 @@ static long fme_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg)
> return -EINVAL;
> }
>
> +static int fme_dev_init(struct platform_device *pdev)
> +{
> + struct dfl_feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + struct dfl_fme *fme;
> +
> + fme = devm_kzalloc(&pdev->dev, sizeof(*fme), GFP_KERNEL);
> + if (!fme)
> + return -ENOMEM;
> +
> + fme->pdata = pdata;
> +
> + mutex_lock(&pdata->lock);
> + dfl_fpga_pdata_set_private(pdata, fme);
> + mutex_unlock(&pdata->lock);
> +
> + return 0;
> +}
> +
> +static void fme_dev_destroy(struct platform_device *pdev)
> +{
> + struct dfl_feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + struct dfl_fme *fme;
> +
> + mutex_lock(&pdata->lock);
> + fme = dfl_fpga_pdata_get_private(pdata);
> + dfl_fpga_pdata_set_private(pdata, NULL);
> + mutex_unlock(&pdata->lock);
> +}
> +
> static const struct file_operations fme_fops = {
[PATCH] selftests: sparc64: Add missing SPDX License Identifiers
Add missing SPDX License Identifiers to Makefile(s). Signed-off-by: Shuah Khan (Samsung OSG) --- tools/testing/selftests/sparc64/Makefile | 1 + tools/testing/selftests/sparc64/drivers/Makefile | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/sparc64/Makefile b/tools/testing/selftests/sparc64/Makefile index 76b2206932c3..a19531dba4dc 100644 --- a/tools/testing/selftests/sparc64/Makefile +++ b/tools/testing/selftests/sparc64/Makefile @@ -1,3 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 uname_M := $(shell uname -m 2>/dev/null || echo not) ARCH ?= $(shell echo $(uname_M) | sed -e s/x86_64/x86/) diff --git a/tools/testing/selftests/sparc64/drivers/Makefile b/tools/testing/selftests/sparc64/drivers/Makefile index 6264f40bbdbc..deb0df415565 100644 --- a/tools/testing/selftests/sparc64/drivers/Makefile +++ b/tools/testing/selftests/sparc64/drivers/Makefile @@ -1,4 +1,4 @@ - +# SPDX-License-Identifier: GPL-2.0 INCLUDEDIR := -I. CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g -- 2.17.0
Re: [PATCH 01/14] ubi: fastmap: Read PEB numbers more carefully
Hi Richard,
I love your patch! Perhaps something to improve:
[auto build test WARNING on mtd/master]
[also build test WARNING on v4.17 next-20180613]
[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/Richard-Weinberger/ubi-Fastmap-updates/20180614-052830
base: git://git.infradead.org/linux-mtd.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/mtd/ubi/fastmap.c:110:14: sparse: incorrect type in assignment
>> (different base types) @@expected restricted __be32 [usertype] pnum @@
>> got [usertype] pnum @@
drivers/mtd/ubi/fastmap.c:110:14:expected restricted __be32 [usertype]
pnum
drivers/mtd/ubi/fastmap.c:110:14:got unsigned int
>> drivers/mtd/ubi/fastmap.c:111:13: sparse: restricted __be32 degrades to
>> integer
>> drivers/mtd/ubi/fastmap.c:112:27: sparse: incorrect type in assignment
>> (different base types) @@expected int [signed] @@got
>> restricted __be3int [signed] @@
drivers/mtd/ubi/fastmap.c:112:27:expected int [signed]
drivers/mtd/ubi/fastmap.c:112:27:got restricted __be32 [usertype] pnum
drivers/mtd/ubi/fastmap.c:116:13: sparse: restricted __be32 degrades to
integer
drivers/mtd/ubi/fastmap.c:116:25: sparse: restricted __be32 degrades to
integer
drivers/mtd/ubi/fastmap.c:121:27: sparse: incorrect type in assignment
(different base types) @@expected int [signed] @@got
restricted __be3int [signed] @@
drivers/mtd/ubi/fastmap.c:121:27:expected int [signed]
drivers/mtd/ubi/fastmap.c:121:27:got restricted __be32 [usertype] pnum
drivers/mtd/ubi/fastmap.c:604:23: sparse: incorrect type in assignment
(different base types) @@expected unsigned long long [unsigned] max_sqnum
@@got nsigned long long [unsigned] max_sqnum @@
drivers/mtd/ubi/fastmap.c:604:23:expected unsigned long long [unsigned]
max_sqnum
drivers/mtd/ubi/fastmap.c:604:23:got restricted __be64 [usertype] sqnum
drivers/mtd/ubi/fastmap.c:1075:17: sparse: incorrect type in assignment
(different base types) @@expected restricted __be32 [usertype] tmp_crc @@
got [usertype] tmp_crc @@
drivers/mtd/ubi/fastmap.c:1075:17:expected restricted __be32 [usertype]
tmp_crc
drivers/mtd/ubi/fastmap.c:1075:17:got unsigned int
drivers/mtd/ubi/fastmap.c:1077:13: sparse: incorrect type in assignment
(different base types) @@expected restricted __be32 [usertype] crc @@
got [usertype] crc @@
drivers/mtd/ubi/fastmap.c:1077:13:expected restricted __be32 [usertype]
crc
drivers/mtd/ubi/fastmap.c:1077:13:got unsigned int
drivers/mtd/ubi/fastmap.c:1086:22: sparse: incorrect type in assignment
(different base types) @@expected restricted __be64 [usertype] sqnum @@
got unsigned lonrestricted __be64 [usertype] sqnum @@
drivers/mtd/ubi/fastmap.c:1086:22:expected restricted __be64 [usertype]
sqnum
drivers/mtd/ubi/fastmap.c:1086:22:got unsigned long long [unsigned]
[assigned] sqnum
vim +110 drivers/mtd/ubi/fastmap.c
103
104 static bool read_pnum(struct ubi_device *ubi, struct ubi_attach_info
*ai,
105 __be32 pnum, int *out_pnum)
106 {
107 int ret = true;
108 int max_pnum = ubi->peb_count;
109
> 110 pnum = be32_to_cpu(pnum);
> 111 if (pnum == UBI_UNKNOWN) {
> 112 *out_pnum = pnum;
113 goto out;
114 }
115
116 if (pnum < 0 || pnum >= max_pnum) {
117 ubi_err(ubi, "fastmap references PEB out of range: %i",
pnum);
118 ret = false;
119 goto out;
120 } else {
121 *out_pnum = pnum;
122 }
123
124 out:
125 return ret;
126 }
127
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
On 06/13/2018 01:18 PM, Scott Branden wrote: > Hi Rob, > > Thanks for comment - reply inline. > > > On 18-06-13 12:31 PM, Florian Fainelli wrote: >> On 06/12/2018 03:54 PM, Rob Herring wrote: >>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden >>> wrote: Hi Rob, Could you please kindly comment on change below. It allows board variants to be added easily via a simple define for different number of SATA ports. On 18-06-04 09:22 AM, Florian Fainelli wrote: > On 05/18/2018 11:34 AM, Scott Branden wrote: >> Move remaining sata configuration to stingray-sata.dtsi and enable >> ports based on NUM_SATA defined. >> Now, all that needs to be done is define NUM_SATA per board. > Rob could you review this and let us know if this approach is okay or > not? Thank you! > >> Signed-off-by: Scott Branden >> --- >> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi >> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi >> index 8c68e0c..7f6d176 100644 >> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi >> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi >> @@ -43,7 +43,11 @@ >> interrupts = > IRQ_TYPE_LEVEL_HIGH>; >> #address-cells = <1>; >> #size-cells = <0>; >> +#if (NUM_SATA > 0) >> + status = "okay"; >> +#else >> status = "disabled"; >> +#endif >>> This only works if ports are contiguously enabled (0-N). You might not >>> care, but it is not a pattern that works in general. > Correct - all board designs that include this dtsi file follow such > commonality (ie. design with SATA0 first, etc). By having common board > designs it allows for commonality in dts files rather than duplicating > information everywhere. If somebody designs a bizarro board they are > free to create their own dts file of course. >>> And I'm not a fan >>> of C preprocessing in DT files in general beyond just defines for >>> single numbers. > The use of a define to specify the number of SATA ports in the board > design meets our requirements of being able to maintain many boards. We > need a method to specify the number of ports in the board design rather > than copying and pasting the information in many dts files. If you have > an alternative upstreamable mechanism to manage the configuration of > many boards without copy and paste that would be ideal? We had discussed this off-list, but I really think you should be having some sort of higher level scripting engine which is able to generate valid per-board DTS files and not have the kernel and its use of the C pre-processor attempt to solve your problems because a) it's the wrong place, and b) it is limited. -- Florian
Re: linux-next: manual merge of the cifs tree with Linus' tree
Ronnie,
I fixed up that patch and repushed to cifs-2.6.git for-next. Seems
trivial. Let me know if any issues.
On Wed, Jun 13, 2018 at 6:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the cifs tree got a conflict in:
>
> fs/cifs/transport.c
>
> between commit:
>
> 6da2ec56059c ("treewide: kmalloc() -> kmalloc_array()")
>
> from Linus' tree and commit:
>
> 1560d69e21c6 ("cifs: push rfc1002 generation down the stack")
>
> from the cifs tree.
>
> I fixed it up (the latter removed the code modified by the former) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
--
Thanks,
Steve
Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs
On Mon, Jun 11, 2018 at 03:43:02PM +0200, Arnd Bergmann wrote:
> On Mon, Jun 11, 2018 at 6:25 AM, Don Bollinger wrote:
> > optoe is an i2c based driver that supports read/write access to all
> > the pages (tables) of MSA standard SFP and similar devices (conforming
> > to the SFF-8472 spec) and MSA standard QSFP and similar devices
> > (conforming to the SFF-8436 spec).
> >
> >
> > Signed-off-by: Don Bollinger
>
> > +
> > +#undef EEPROM_CLASS
> > +#ifdef CONFIG_EEPROM_CLASS
> > +#define EEPROM_CLASS
> > +#endif
> > +#ifdef CONFIG_EEPROM_CLASS_MODULE
> > +#define EEPROM_CLASS
> > +#endif
>
> I don't understand this part: I see some older patches introducing an
> EEPROM_CLASS, but nothing ever seems to have made it into the
> mainline kernel.
>
> If that class isn't there, this code shouldn't be either. You can always
> add it back in case we decide to introduce that class later, but then
> I wouldn't make it a compile-time option but just a hard dependency
> instead.
Thanks for the feedback.
Some background will explain how optoe got here... My goal is to make
the EEPROM data and controls in {Q}SFP devices more accessible. (I'm
working for Finisar, an optics vendor.)
The ecosystem where optoe operates includes switch vendors, NOS vendors,
optics vendors and switch ASIC vendors, competing and collaborating to
build a bunch of different complete white box switch solutions.
The NOS (Network Operating System) vendors start with a Linux distro,
then add a bunch of their own patches and 'value add'. Then they
include platform drivers from the switch vendors. And they integrate
the chosen switch ASIC SDK.
Here's the key: I don't have access to all of those pieces. I can
build an environment to build my driver for many of those systems, but I
can't change other elements of that NOS.
The first NOS I targeted (Cumulus Linux) happens to be the author of the
EEPROM_CLASS patches you cited. I began with their driver (the best
available), and morphed it into optoe. To fit their environment, I kept
the EEPROM_CLASS code. They use their own platform driver (one for each
switch model) to instantiate their predecessor to the optoe driver. So,
since I don't have access to their platform driver, I kept the data
structure they pass to the probe function, where I get initialization
data. That is now struct optoe_platform_data. The *dummy items in that
struct maintain compatibility, while making it clear that they aren't
really needed.
When I targeted the next NOS, it did not have the EEPROM_CLASS code. I
figured out I could #ifdef that code, enabling me to create a driver that
works in both environments.
>
> > +struct optoe_platform_data {
> > + u32 byte_len; /* size (sum of all addr) */
> > + u16 page_size; /* for writes */
> > + u8 flags;
> > + void*dummy1;/* backward compatibility */
> > + void*dummy2;/* backward compatibility */
> > +
> > +#ifdef EEPROM_CLASS
> > + struct eeprom_platform_data *eeprom_data;
> > +#endif
> > + char port_name[MAX_PORT_NAME_LEN];
> > +};
>
> What is the backward-compatibility for? Normally we don't do it
> like that, we only keep compatibility with things that have already
> been part of the kernel, especially when you also have an #ifdef
> that makes it incompatible again ;-)
So it is actually compatible with two different kernel compilations. If
EEPROM_CLASS is configured, optoe supports that model. If not, optoe
implements a sysfs file to identify which port this device is on. It
works.
>
> > +struct optoe_data {
> > + struct optoe_platform_data chip;
>
> Maybe merge the two structures into one?
optoe_platform_data is passed in when optoe gets a probe. It is only
part of the data I need to maintain internally. I inherited this
pattern from at24.c (the predecessor ^2 to optoe).
>
> Arnd
>
All that said... I am working with my partners to see if we can remove
both the EEPROM_CLASS code and the compatibility anomalies. Technically
it would be easy. Logistically it is probably manageable. The next
step is mine, I will either remove the offending code or I will lobby to
keep it in there.
Don
Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
Hello Rajendra,
On 06/11/2018 09:40 PM, Rajendra Nayak wrote:
> The RPMh Power domain driver aggregates the corner votes from various
> consumers for the ARC resources and communicates it to RPMh.
>
> We also add data for all power domains on sdm845 SoC as part of the patch.
> The driver can be extended to support other SoCs which support RPMh
>
> Signed-off-by: Rajendra Nayak
> ---
> drivers/soc/qcom/Kconfig| 9 +
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/rpmhpd.c | 427
> include/dt-bindings/power/qcom-rpmhpd.h | 31 ++
> 4 files changed, 468 insertions(+)
> create mode 100644 drivers/soc/qcom/rpmhpd.c
> create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
This DT header file should be included in a DT binding patch that is
separate from the driver patch.
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 5c54931a7b99..7cb7eba2b997 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
>
> Say y here if you intend to boot the modem remoteproc.
>
> +config QCOM_RPMHPD
> + tristate "Qualcomm RPMh Power domain driver"
> + depends on QCOM_RPMH && QCOM_COMMAND_DB
> + help
> + QCOM RPMh Power domain driver to support power-domains with
> + performance states. The driver communicates a performance state
> + value to RPMh which then translates it into corresponding voltage
> + for the voltage rail.
> +
> config QCOM_RPMPD
> tristate "Qualcomm RPM Power domain driver"
> depends on MFD_QCOM_RPM && QCOM_SMD_RPM
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index 9550c170de93..499513f63bef 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM) += smsm.o
> obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
> obj-$(CONFIG_QCOM_APR) += apr.o
> obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
> new file mode 100644
> index ..7083ec1590ff
> --- /dev/null
> +++ b/drivers/soc/qcom/rpmhpd.c
> @@ -0,0 +1,427 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
> +
> +#define DEFINE_RPMHPD_AO(_platform, _name, _active) \
> + static struct rpmhpd _platform##_##_active; \
> + static struct rpmhpd _platform##_##_name = {\
> + .pd = { .name = #_name, }, \
> + .peer = &_platform##_##_active, \
> + .res_name = #_name".lvl", \
> + .valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
> + BIT(RPMH_WAKE_ONLY_STATE) | \
> + BIT(RPMH_SLEEP_STATE)), \
> + }; \
> + static struct rpmhpd _platform##_##_active = { \
> + .pd = { .name = #_active, },\
> + .peer = &_platform##_##_name, \
> + .active_only = true,\
> + .res_name = #_name".lvl", \
> + .valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) | \
> + BIT(RPMH_WAKE_ONLY_STATE) | \
> + BIT(RPMH_SLEEP_STATE)), \> +
> }
> +
> +#define DEFINE_RPMHPD(_platform, _name)
> \
> + static struct rpmhpd _platform##_##_name = {\
> + .pd = { .name = #_name, }, \
> + .res_name = #_name".lvl", \
> + .valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
> + }
> +
> +/*
> + * This is the number of bytes used for each command DB aux data entry of an
> + * ARC resource.
> + */
> +#define RPMH_ARC_LEVEL_SIZE 2
> +#define RPMH_ARC_MAX_LEVELS 16
> +
Would you mind adding a kernel-doc comment for here for struct rpmhpd? I
think that would make the code clearer. It would be good to mention the
numbering spaces for 'corner' and 'level' elements as well as the usage of
'peer' and 'active_only' elements.
> +struct rpmhpd {
> + struct device *dev;
> + struct generic_pm_domain pd;
> + struct rpmhpd *peer;
> + const bool activ
Re: [PATCH 3.18 00/21] 3.18.113-stable review
Greg Kroah-Hartman writes: > On Tue, Jun 12, 2018 at 03:08:12PM -0700, kernelci.org bot wrote: >> stable-rc/linux-3.18.y boot: 52 boots: 28 failed, 18 passed with 1 offline, >> 5 conflicts (v3.18.112-22-gb0582263e3c9) >> >> Full Boot Summary: >> https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-22-gb0582263e3c9/ >> Full Build Summary: >> https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-22-gb0582263e3c9/ >> >> Tree: stable-rc >> Branch: linux-3.18.y >> Git Describe: v3.18.112-22-gb0582263e3c9 >> Git Commit: b0582263e3c9810fd887ca92d19cb9ff30a4d9f6 >> Git URL: >> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> Tested: 24 unique boards, 12 SoC families, 13 builds out of 183 [...] > > That is a lot of new failures, did the whole lab fail, or is this really > a problem in v3.18.112 here? Whole lab failure (more precisely, lab operator failure) ;) gak, I updated the rootfs images to the latest buildroot, which forced me to upgrade the kernel headers used to build the rootfs from v3.10 to v4.4. So I guess it's no surprise that every single board panic'd as soon as it hit userspace. I downgraded the rootfs, and re-ran all those boot tests, and now things are 100% passing in my lab. Sorry for the noise, Kevin
[PATCH] infiniband: fix a subtle race condition
In ucma_event_handler() we lock the mutex like this:
mutex_lock(&ctx->file->mut);
...
mutex_unlock(&ctx->file->mut);
which seems correct, but we could translate it into this:
f = ctx->file;
mutex_lock(&f->mut);
...
f = ctx->file;
mutex_unlock(&f->mut);
as the compiler does. And, because ucma_event_handler() is
called in a workqueue so it could race with ucma_migrate_id(),
so the following race condition could happen:
CPU0CPU1
f = ctx->file;
ucma_lock_files(f, new_file);
ctx->file = new_file
ucma_lock_files(f, new_file);
mutex_lock(&f->mut); // still the old file!
...
f = ctx->file; // now the new one!!
mutex_unlock(&f->mut); // unlock new file!
Fix this by reading ctx->file once before mutex_lock(), so we
won't unlock a different mutex any more.
Reported-by: syzbot+e5579222b6a3edd96...@syzkaller.appspotmail.com
Cc: Doug Ledford
Cc: Jason Gunthorpe
Signed-off-by: Cong Wang
---
drivers/infiniband/core/ucma.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index ec8fb289621f..8729d6acf981 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -341,13 +341,15 @@ static int ucma_event_handler(struct rdma_cm_id *cm_id,
{
struct ucma_event *uevent;
struct ucma_context *ctx = cm_id->context;
+ struct ucma_file *cur_file;
int ret = 0;
uevent = kzalloc(sizeof(*uevent), GFP_KERNEL);
if (!uevent)
return event->event == RDMA_CM_EVENT_CONNECT_REQUEST;
- mutex_lock(&ctx->file->mut);
+ cur_file = ctx->file;
+ mutex_lock(&cur_file->mut);
uevent->cm_id = cm_id;
ucma_set_event_context(ctx, event, uevent);
uevent->resp.event = event->event;
@@ -382,12 +384,12 @@ static int ucma_event_handler(struct rdma_cm_id *cm_id,
goto out;
}
- list_add_tail(&uevent->list, &ctx->file->event_list);
- wake_up_interruptible(&ctx->file->poll_wait);
+ list_add_tail(&uevent->list, &cur_file->event_list);
+ wake_up_interruptible(&cur_file->poll_wait);
if (event->event == RDMA_CM_EVENT_DEVICE_REMOVAL)
ucma_removal_event_handler(cm_id);
out:
- mutex_unlock(&ctx->file->mut);
+ mutex_unlock(&cur_file->mut);
return ret;
}
--
2.14.4
linux-next: manual merge of the fbdev tree with Linus' tree
Hi Bartlomiej,
Today's linux-next merge of the fbdev tree got a conflict in:
drivers/video/fbdev/mmp/fb/mmpfb.c
between commit:
6396bb221514 ("treewide: kzalloc() -> kcalloc()")
from Linus' tree and commit:
e0e894f59418 ("video: fbdev-MMP: Delete an error message for a failed memory
allocation in two functions")
from the fbdev tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/video/fbdev/mmp/fb/mmpfb.c
index f27697e07c55,292b3e403044..
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@@ -493,12 -493,11 +493,11 @@@ static int modes_setup(struct mmpfb_inf
return 0;
}
/* put videomode list to info structure */
- videomodes = kzalloc(sizeof(struct fb_videomode) * videomode_num,
- GFP_KERNEL);
+ videomodes = kcalloc(videomode_num, sizeof(struct fb_videomode),
+ GFP_KERNEL);
- if (!videomodes) {
- dev_err(fbi->dev, "can't malloc video modes\n");
+ if (!videomodes)
return -ENOMEM;
- }
+
for (i = 0; i < videomode_num; i++)
mmpmode_to_fbmode(&videomodes[i], &mmp_modes[i]);
fb_videomode_to_modelist(videomodes, videomode_num, &info->modelist);
pgpIvhZBQWKYi.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
On 6/13/2018 4:33 PM, Florian Fainelli wrote:
On 06/13/2018 04:32 PM, Ray Jui wrote:
On 6/13/2018 12:49 PM, Florian Fainelli wrote:
On 06/12/2018 01:21 PM, Ray Jui wrote:
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
Cygnus SoC
Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom
Cygnus")
This appears to be the only one that is truly needed here, the two
others below probably just moved things around but the offending commit
was already introduced in the above commit.
Okay thanks. Will remove the other two "Fixes" below.
I can take care of that while applying the patches, no need for you to
resubmit, for the whole series I mean.
Excellent! Much appreciated!
Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
bus")
Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
There is no need for an extra line between the last Fixes: tag and your
Signed-off-by tag.
Got it, thanks!
And that as well.
Thanks again!
Ray
