* Re: [PATCH 1/1] edac: fix improper return value
From: Borislav Petkov @ 2016-12-04 10:07 UTC (permalink / raw)
To: Pan Bian; +Cc: Mauro Carvalho Chehab, linux-edac, linux-kernel, Pan Bian
In-Reply-To: <1480831638-5361-1-git-send-email-bianpan201604@163.com>
On Sun, Dec 04, 2016 at 02:07:18PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016@163.com>
>
> When the call to zalloc_cpumask_var() fails, returning "false" seems
> improper. The real value of macro "false" is 0, and 0 means no error.
> This patch fixes the bug, returning "-ENOMEM".
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189071
That bugzilla entry wasn't really needed.
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/edac/amd64_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied,
thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH 2/2] Staging: ks7010: eap_packet.h: fixed coding style issue
From: Manoj Sawai @ 2016-12-04 14:59 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-kernel, Manoj Sawai
Rearranged comments so that lines are less than 80 characters long
Signed-off-by: Manoj Sawai <mas@iitkgp.ac.in>
---
drivers/staging/ks7010/eap_packet.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ks7010/eap_packet.h b/drivers/staging/ks7010/eap_packet.h
index df7f760e4110..45d30b8ed0b1 100644
--- a/drivers/staging/ks7010/eap_packet.h
+++ b/drivers/staging/ks7010/eap_packet.h
@@ -58,12 +58,15 @@ struct ieee802_1x_eapol_key {
* encrypt the Key field; 64-bit NTP timestamp MAY be used here
*/
unsigned char replay_counter[IEEE8021X_REPLAY_COUNTER_LEN];
- unsigned char key_iv[IEEE8021X_KEY_IV_LEN]; /* cryptographically random number */
+
+ /* cryptographically random number */
+ unsigned char key_iv[IEEE8021X_KEY_IV_LEN];
unsigned char key_index; /*
* key flag in the most significant bit:
* 0 = broadcast (default key),
- * 1 = unicast (key mapping key); key index is in the
- * 7 least significant bits
+ * 1 = unicast (key mapping key);
+ * key index is in the 7 least
+ * significant bits
*/
/*
* HMAC-MD5 message integrity check computed with MS-MPPE-Send-Key as
--
2.11.0
^ permalink raw reply related
* [PATCH] Staging: ks7010: ks7010_stio.h: fixed coding style error
From: Manoj Sawai @ 2016-12-04 14:21 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-kernel, Manoj Sawai
Fixed 2 coding style errors about trailing whitespaces.
Signed-off-by: Manoj Sawai <mas@iitkgp.ac.in>
---
drivers/staging/ks7010/ks7010_sdio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ks7010/ks7010_sdio.h b/drivers/staging/ks7010/ks7010_sdio.h
index 0a0951ffffa6..0f5fd848e23d 100644
--- a/drivers/staging/ks7010/ks7010_sdio.h
+++ b/drivers/staging/ks7010/ks7010_sdio.h
@@ -1,5 +1,5 @@
/*
- * Driver for KeyStream, KS7010 based SDIO cards.
+ * Driver for KeyStream, KS7010 based SDIO cards.
*
* Copyright (C) 2006-2008 KeyStream Corp.
* Copyright (C) 2009 Renesas Technology Corp.
@@ -41,7 +41,7 @@
/* Write Index Register */
#define WRITE_INDEX 0x000010
-/* Write Status/Read Data Size Register
+/* Write Status/Read Data Size Register
* for network packet (less than 2048 bytes data)
*/
#define WSTATUS_RSIZE 0x000014
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] Input: mouse: synaptics - change msleep to usleep_range for small msecs
From: Igor Grinberg @ 2016-12-04 8:02 UTC (permalink / raw)
To: Aniroop Mathur, Dmitry Torokhov, linux-input, linux-kernel
Cc: s.samuel, r.mahale, Aniroop Mathur
In-Reply-To: <CAOXgUe0FPkByE-0piMeNLaU3iTd_k0Nj_pZzEU4pv_9WzBzt1w@mail.gmail.com>
Hi Aniroop Mathur,
On 11/29/16 23:02, Aniroop Mathur wrote:
> Dear Mike Rapoport, Igor Grinberg,
> Greetings!
>
> I am Aniroop Mathur from Samsung R&D Institute, India.
>
> I have submitted one patch as below for review to Linux Open Source.
> The problem is that we do not have the hardware available with us to
> test it and we would like to test it before actually applying it.
> As you are the author of this driver, I am contacting you to request you
> provide your feedback upon this patch.
>
> Also if you have the hardware available, could you please help to
> test this patch on your hardware? or could you provide contact points
> of individuals who could support to test it?
This touchpad and the driver was used on an old PXA270 based PDA.
I currently don't have those at hand to test the patch.
>
> Thank you!
>
> BR,
> Aniroop Mathur
>
> On Tue, Nov 29, 2016 at 1:25 AM, Aniroop Mathur <a.mathur@samsung.com> wrote:
>> msleep(1~20) may not do what the caller intends, and will often sleep longer.
>> (~20 ms actual sleep for any value given in the 1~20ms range)
Well, it should be at least 1ms as stated in my comment just before the define.
So, from the correctness perspective larger values will also do the job.
Additionally, since I've taken a spare 2ms, and you are making it even more
precise (3000us + 100us) - it will still do the job and stay correct.
So, there should be no issue from correctness POV.
>> This is not the desired behaviour for many cases like device resume time,
>> device suspend time, device enable time, retry logic, etc.
>> Thus, change msleep to usleep_range for precise wakeups.
This is a human interface touchpad device, even having 20ms soft reset
sleep time will not impact the responsiveness for humans.
IMHO, there is no need for precise wakeups for this device, so I wouldn't
bother.
>>
>> Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
>> ---
>> drivers/input/mouse/synaptics_i2c.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/mouse/synaptics_i2c.c b/drivers/input/mouse/synaptics_i2c.c
>> index aa7c5da..4d688a6 100644
>> --- a/drivers/input/mouse/synaptics_i2c.c
>> +++ b/drivers/input/mouse/synaptics_i2c.c
>> @@ -29,7 +29,7 @@
>> * after soft reset, we should wait for 1 ms
>> * before the device becomes operational
>> */
>> -#define SOFT_RESET_DELAY_MS 3
>> +#define SOFT_RESET_DELAY_US 3000
>> /* and after hard reset, we should wait for max 500ms */
>> #define HARD_RESET_DELAY_MS 500
>>
>> @@ -311,7 +311,7 @@ static int synaptics_i2c_reset_config(struct i2c_client *client)
>> if (ret) {
>> dev_err(&client->dev, "Unable to reset device\n");
>> } else {
>> - msleep(SOFT_RESET_DELAY_MS);
>> + usleep_range(SOFT_RESET_DELAY_US, SOFT_RESET_DELAY_US + 100);
>> ret = synaptics_i2c_config(client);
>> if (ret)
>> dev_err(&client->dev, "Unable to config device\n");
>> --
>> 2.6.2
>>
>
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] perf/core: remove invalid warning from list_update_cgroup_event
From: David Carrillo-Cisneros @ 2016-12-04 8:46 UTC (permalink / raw)
To: linux-kernel
Cc: x86@kernel.org, Ingo Molnar, Thomas Gleixner, Andi Kleen,
Kan Liang, Peter Zijlstra, Vegard Nossum, Marcelo Tosatti,
Nilay Vaish, Borislav Petkov, Vikas Shivappa, Ravi V Shankar,
Fenghua Yu, Paul Turner, Stephane Eranian,
David Carrillo-Cisneros
The warning introduced in commit:
979bfef8607c ("perf/core: Do not set cpuctx->cgrp for unscheduled cgroups")
assumed that a cgroup switch always precedes list_del_event. This is not
the case. Remove warning.
Make sure that cpuctx->cgrp is NULL until a cgroup event is sched in or
ctx->nr_cgroups == 0.
Signed-off-by: David Carrillo-Cisneros <davidcc@google.com>
---
kernel/events/core.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 6ee1feb..02c8421 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -903,17 +903,14 @@ list_update_cgroup_event(struct perf_event *event,
*/
cpuctx = __get_cpu_context(ctx);
- /* Only set/clear cpuctx->cgrp if current task uses event->cgrp. */
- if (perf_cgroup_from_task(current, ctx) != event->cgrp) {
- /*
- * We are removing the last cpu event in this context.
- * If that event is not active in this cpu, cpuctx->cgrp
- * should've been cleared by perf_cgroup_switch.
- */
- WARN_ON_ONCE(!add && cpuctx->cgrp);
- return;
- }
- cpuctx->cgrp = add ? event->cgrp : NULL;
+ /*
+ * cpuctx->cgrp is NULL until a cgroup event is sched in or
+ * ctx->nr_cgroup == 0 .
+ */
+ if (add && perf_cgroup_from_task(current, ctx) == event->cgrp)
+ cpuctx->cgrp = event->cgrp;
+ else if (!add)
+ cpuctx->cgrp = NULL;
}
#else /* !CONFIG_CGROUP_PERF */
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/1] net: bnx2x: fix improper return value
From: Pan Bian @ 2016-12-04 8:39 UTC (permalink / raw)
To: Michal Kalderon, Yuval Mintz, Ariel Elior, everest-linux-l2,
netdev
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
Marco BNX2X_ALLOC_AND_SET(arr, lbl, func) calls kmalloc() to allocate
memory, and jumps to label "lbl" if the allocation fails. Label "lbl"
first cleans memory and then returns variable rc. Before calling the
macro, the value of variable rc is 0. Because 0 means no error, the
callers of bnx2x_init_firmware() may be misled. This patch fixes the bug,
assigning "-ENOMEM" to rc before calling macro NX2X_ALLOC_AND_SET().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189141
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 0cee4c0..6f9fc20 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13505,6 +13505,7 @@ static int bnx2x_init_firmware(struct bnx2x *bp)
/* Initialize the pointers to the init arrays */
/* Blob */
+ rc = -ENOMEM;
BNX2X_ALLOC_AND_SET(init_data, request_firmware_exit, be32_to_cpu_n);
/* Opcodes */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Srinivas Ramana @ 2016-12-04 8:36 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, linux-arm-kernel, linux-kernel, linux-arm-msm
In-Reply-To: <20161202110845.GC8266@arm.com>
On 12/02/2016 04:38 PM, Will Deacon wrote:
> On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
>> Extend the trace_clock to support the arch timer cycle
>> counter so that we can get the monotonic cycle count
>> in the traces. This will help in correlating the traces with the
>> timestamps/events in other subsystems in the soc which share
>> this common counter for driving their timers.
>
> I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
> particular, the "perf" trace_clock hangs off sched_clock, which should
> be backed by the architected counter anyway. What does the cycle counter in
> isolation tell you, given that the frequency isn't architected?
>
> I think I'm missing something here.
>
> Will
>
Having cycle counter would help in the cases where we want to correlate
the time with other subsystems which are outside cpu subsystem.
local_clock or even the perf track_clock uses sched_clock which gets
suspended during system suspend. Yes, they are backed up by the
architected counter but they ignore the cycles spent in suspend. so,
when comparing with monotonically increasing cycle counter, other clocks
doesn't help. It seems X86 uses the TSC counter to help such cases.
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.
From: kbuild test robot @ 2016-12-04 8:19 UTC (permalink / raw)
To: Rich Felker; +Cc: kbuild-all, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
Hi Rich,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 0cb65c83304a341b9d09678448d7c8b550689531
commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a builtin device tree blob in the kernel
date: 4 months ago
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 190fe191cfbead9fe089453dd092869c9469c6d4
# save the attached .config to linux build tree
make.cross ARCH=sh
All errors (new ones prefixed by >>):
>> make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.
make[2]: Target '__build' not remade because of errors.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40539 bytes --]
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Alexey Kardashevskiy @ 2016-12-04 8:12 UTC (permalink / raw)
To: Chen-Yu Tsai, Icenowy Zheng
Cc: Maxime Ripard, Rob Herring, Russell King, Andre Przywara,
Hans de Goede, Arnd Bergmann, Vishnu Patekar,
linux-doc@vger.kernel.org, linux-arm-kernel, linux-kernel,
devicetree, linux-sunxi
In-Reply-To: <CAGb2v661hBsd7tBcYByeRKEZh+8YMB3ewbnkrT3rUvzP2f90yQ@mail.gmail.com>
On 03/12/16 03:41, Chen-Yu Tsai wrote:
> Hi,
>
> On Fri, Dec 2, 2016 at 11:05 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
>> SDIO Wi-Fi chip by Allwinner (XR819).
>>
>> Add a device tree file for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> Changes since v2:
>> - Merged SDIO Wi-Fi patch into it.
>> - SDIO Wi-Fi: add a ethernet1 alias to it, as it has no internal NVRAM.
>> - SDIO Wi-Fi: changed pinctrl binding to generic pinconf
>> - removed all gpio pinctrl nodes
>> - changed h2plus to h2-plus
>> Changes since v1:
>> - Convert to generic pinconf bindings.
>> - SDIO Wi-Fi: add patch.
>>
>> Some notes:
>> - The uart1 and uart2 is available on the unsoldered gpio header.
>> - The onboard USB connector has its Vbus directly connected to DCIN-5V (the
>> power jack)
>>
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 159 ++++++++++++++++++++++
>> 2 files changed, 160 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 6447abc..59f6e86 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -844,6 +844,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>> sun8i-a33-sinlinx-sina33.dtb \
>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>> sun8i-a83t-cubietruck-plus.dtb \
>> + sun8i-h2-plus-orangepi-zero.dtb \
>> sun8i-h3-bananapi-m2-plus.dtb \
>> sun8i-h3-nanopi-neo.dtb \
>> sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>> new file mode 100644
>> index 0000000..d18807f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>> @@ -0,0 +1,159 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file 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 for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> + model = "Xunlong Orange Pi Zero";
>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
>> + ethernet1 = &xr819;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + pwr_led {
>> + label = "orangepi:green:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + status_led {
>> + label = "orangepi:red:status";
>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +
>> + reg_vcc_wifi: reg_vcc_wifi {
>> + compatible = "regulator-fixed";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-wifi";
>> + enable-active-high;
>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins_a>;
>> + vmmc-supply = <®_vcc_wifi>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +
>> + /*
>> + * Explicitly define the sdio device, so that we can add an ethernet
>> + * alias for it (which e.g. makes u-boot set a mac-address).
>> + */
>> + xr819: sdio_wifi@1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +&mmc1_pins_a {
>> + bias-pull-up;
>
> This is already set in h3.dtsi
>
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pins_a>;
>> + status = "okay";
>> +};
>> +
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart1_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart2_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&usbphy {
>> + /* USB VBUS is always on */
>
> I think this comment could use a little work.
>
> AFAIK this board doesn't have an actual USB port.
Mine does have one port.
> It's just the D+/D- pins on the pin header, along
> with the board-wide 5V, also on the pin header.
>
> ChenYu
>
>> + status = "okay";
>> +};
>> --
>> 2.10.2
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
--
Alexey
^ permalink raw reply
* RE: [RESEND PATCH V6 0/6] Add support for privileged mappings
From: Sricharan @ 2016-12-04 7:48 UTC (permalink / raw)
To: 'Robin Murphy', jcrouse, pdaly, jgebben, joro,
linux-kernel, pratikp, iommu, tzeng, linux-arm-kernel,
will.deacon, mitchelh, vinod.koul
In-Reply-To: <e7e05493-e216-d744-b828-351d2c70150d@arm.com>
Hi Robin,
>Hi Sricharan,
>
>On 02/12/16 14:55, Sricharan R wrote:
>> This series is a resend of the V5 that Mitch sent sometime back [2]
>> All the patches are the same and i have just rebased. Not sure why this
>> finally did not make it last time. The last patch in the previous
>> series does not apply now [3], so just redid that. Also Copied the tags
>> that he had from last time as well.
>
>Heh, I was assuming this would be down to me to pick up. Vinod did have
>some complaints last time about the commit message on the PL330 patch -
>I did get as far as rewriting that and reworking onto my SMMU
>changes[1], I just hadn't got round to sending it, so it fell onto the
>"after the next merge window" pile.
>
>I'd give some review comments, but they'd essentially be a diff against
>that branch :)
>
Sure, i did not knew that you were on this already. I can repost with the diff
from your branch taken in or wait for you as well. I am fine with either ways
that you suggest.
I checked the patches against your branch, i see that the changes are,
1) one patch for implementing it for armv7s descriptor
2) Changes on pl330 patch commit logs and
3) One patch for doing the revert on arm-smmuv3 as well.
Regards,
Sricharan
^ permalink raw reply
* Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
From: Alan Modra @ 2016-12-04 7:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, Adam Borowski, Greg Kroah-Hartman,
Linux Kbuild mailing list, Michal Marek, Ben Hutchings,
Debian kernel maintainers, linux-arch@vger.kernel.org,
Ingo Molnar, Nicholas Piggin, Linux Kernel Mailing List
In-Reply-To: <14455987.OWjnZpEEup@wuerfel>
On Fri, Dec 02, 2016 at 11:55:58AM +0100, Arnd Bergmann wrote:
> I have managed to bisect the link failure to a specific binutils
> commit by Alan Modra now:
>
> d983c8c ("Strip undefined symbols from .symtab")
>
> went into binutils-2_26 and was reverted in
>
> a82e3ef ("Revert "Strip undefined symbols from .symtab"")
>
> after the release branch for 2.26 was started, so that version
> ended up being fine. However, the 2.27 version never saw the revert
> and causes loadable kernel modules to become unusable when they refer
> to a weak symbol in vmlinux. This works with 2.26 and lower:
See https://sourceware.org/ml/binutils/2016-01/msg00118.html thread
for discussion on why the patch was reverted for 2.26. At the time I
believed that only the ppc64 kernel was affected, by a weak undefined
"__crc_TOC." disappearing. Am I correct in thinking that remained
true up until Linus' merge commit 84d69848c9 2016-10-14?
As far as reverting the binutils commit goes, I'm quite willing to do
that if necessary. You can see how important I think the fix was by
viewing https://sourceware.org/bugzilla/show_bug.cgi?id=4317 and
noticing that the bug was reported in 2007 and didn't see any action
for 8 years..
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN
From: Neftin, Sasha @ 2016-12-04 7:35 UTC (permalink / raw)
To: Baicar, Tyler, jeffrey.t.kirsher, intel-wired-lan, netdev,
linux-kernel, okaya, timur
In-Reply-To: <a5e8ac37-9769-960b-8134-c90c5c061f12@codeaurora.org>
On 12/2/2016 7:02 PM, Baicar, Tyler wrote:
> Hello Sasha,
>
> Were you able to reproduce this issue?
>
> Do you have a patch fixing the close function inconsistencies that you
> mentioned which I could try out?
>
> Thanks,
> Tyler
>
> On 11/21/2016 1:40 PM, Baicar, Tyler wrote:
>> On 11/17/2016 6:31 AM, Neftin, Sasha wrote:
>>> On 11/13/2016 10:34 AM, Neftin, Sasha wrote:
>>>> On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
>>>>> Hello Sasha,
>>>>>
>>>>> On 11/9/2016 11:19 PM, Neftin, Sasha wrote:
>>>>>> On 11/9/2016 11:41 PM, Tyler Baicar wrote:
>>>>>>> Move IRQ free code so that it will happen regardless of the
>>>>>>> __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ
>>>>>>> if the __E1000_DOWN bit is cleared. This is not sufficient because
>>>>>>> it is possible for __E1000_DOWN to be set without releasing the IRQ.
>>>>>>> In such a situation, we will hit a kernel bug later in e1000_remove
>>>>>>> because the IRQ still has action since it was never freed. A
>>>>>>> secondary bus reset can cause this case to happen.
>>>>>>>
>>>>>>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>>>>>>> ---
>>>>>>> drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>>>> index 7017281..36cfcb0 100644
>>>>>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>>>> @@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>>>>>>> if (!test_bit(__E1000_DOWN, &adapter->state)) {
>>>>>>> e1000e_down(adapter, true);
>>>>>>> - e1000_free_irq(adapter);
>>>>>>> /* Link status message must follow this format */
>>>>>>> pr_info("%s NIC Link is Down\n", adapter->netdev->name);
>>>>>>> }
>>>>>>> + e1000_free_irq(adapter);
>>>>>>> +
>>>>>>> napi_disable(&adapter->napi);
>>>>>>> e1000e_free_tx_resources(adapter->tx_ring);
>>>>>>>
>>>>>> I would like not recommend insert this change. This change related
>>>>>> driver state machine, we afraid from lot of synchronization
>>>>>> problem and
>>>>>> issues.
>>>>>> We need keep e1000_free_irq in loop and check for 'test_bit' ready.
>>>>> What do you mean here? There is no loop. If __E1000_DOWN is set
>>>>> then we
>>>>> will never free the IRQ.
>>>>>
>>>>>> Another point, does before execute secondary bus reset your SW
>>>>>> back up
>>>>>> pcie configuration space as properly?
>>>>> After a secondary bus reset, the link needs to recover and go back
>>>>> to a
>>>>> working state after 1 second.
>>>>>
>>>>> From the callstack, the issue is happening while removing the
>>>>> endpoint
>>>>> from the system, before applying the secondary bus reset.
>>>>>
>>>>> The order of events is
>>>>> 1. remove the drivers
>>>>> 2. cause a secondary bus reset
>>>>> 3. wait 1 second
>>>> Actually, this is too much, usually link up in less than 100ms.You can
>>>> check Data Link Layer indication.
>>>>> 4. recover the link
>>>>>
>>>>> callstack:
>>>>> free_msi_irqs+0x6c/0x1a8
>>>>> pci_disable_msi+0xb0/0x148
>>>>> e1000e_reset_interrupt_capability+0x60/0x78
>>>>> e1000_remove+0xc8/0x180
>>>>> pci_device_remove+0x48/0x118
>>>>> __device_release_driver+0x80/0x108
>>>>> device_release_driver+0x2c/0x40
>>>>> pci_stop_bus_device+0xa0/0xb0
>>>>> pci_stop_bus_device+0x3c/0xb0
>>>>> pci_stop_root_bus+0x54/0x80
>>>>> acpi_pci_root_remove+0x28/0x64
>>>>> acpi_bus_trim+0x6c/0xa4
>>>>> acpi_device_hotplug+0x19c/0x3f4
>>>>> acpi_hotplug_work_fn+0x28/0x3c
>>>>> process_one_work+0x150/0x460
>>>>> worker_thread+0x50/0x4b8
>>>>> kthread+0xd4/0xe8
>>>>> ret_from_fork+0x10/0x50
>>>>>
>>>>> Thanks,
>>>>> Tyler
>>>>>
>>>> Hello Tyler,
>>>> Okay, we need consult more about this suggestion.
>>>> May I ask what is setup you run? Is there NIC or on board LAN? I would
>>>> like try reproduce this issue in our lab's too.
>>>> Also, is same issue observed with same scenario and others NIC's too?
>>>> Sasha
>>>> _______________________________________________
>>>> Intel-wired-lan mailing list
>>>> Intel-wired-lan@lists.osuosl.org
>>>> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>>>
>>> Hello Tyler,
>>> I see some in consistent implementation of __*_close methods in our
>>> drivers. Do you have any igb NIC to check if same problem persist there?
>>> Thanks,
>>> Sasha
>> Hello Sasha,
>>
>> I couldn't find an igb NIC to test with, but I did find another e1000e
>> card that does not cause the same issue. That card is:
>>
>> 0004:01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>> Network Connection
>> Subsystem: Intel Corporation Gigabit CT Desktop Adapter
>> Physical Slot: 5-1
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 299
>> Region 0: Memory at c01001c0000 (32-bit, non-prefetchable)
>> [size=128K]
>> Region 1: Memory at c0100100000 (32-bit, non-prefetchable)
>> [size=512K]
>> Region 2: I/O ports at 1000 [size=32]
>> Region 3: Memory at c01001e0000 (32-bit, non-prefetchable)
>> [size=16K]
>> Expansion ROM at c0100180000 [disabled] [size=256K]
>> Capabilities: [c8] Power Management version 2
>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>> PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000397f0040 Data: 0000
>> Capabilities: [e0] Express (v1) Endpoint, MSI 00
>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>> <512ns, L1 <64us
>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>> Unsupported+
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>> MaxPayload 256 bytes, MaxReadReq 512 bytes
>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
>> AuxPwr+ TransPend-
>> LnkCap: Port #8, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>> Exit Latency L0s <128ns, L1 <64us
>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>> LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> Capabilities: [a0] MSI-X: Enable- Count=5 Masked-
>> Vector table: BAR=3 offset=00000000
>> PBA: BAR=3 offset=00002000
>> Capabilities: [100 v1] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr-
>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+
>> AERCap: First Error Pointer: 00, GenCap- CGenEn-
>> ChkCap- ChkEn-
>> Capabilities: [140 v1] Device Serial Number
>> 68-05-ca-ff-ff-29-47-34
>> Kernel driver in use: e1000e
>>
>> Here are the kernel logs from first running the test on this card and
>> then running the test on the Intel 82571EB card that I originally
>> found the issue with (you can see the issue doesn't happen on this
>> card but does on the other):
>>
>> [ 44.146749] ACPI: \_SB_.PCI0: Device has suffered a power fault
>> [ 44.155238] pcieport 0000:00:00.0: PCIe Bus Error:
>> severity=Uncorrected (Non-Fatal), type=Transaction Layer,
>> id=0000(Requester ID)
>> [ 44.166111] pcieport 0000:00:00.0: device [17cb:0400] error
>> status/mask=00004000/00400000
>> [ 44.174420] pcieport 0000:00:00.0: [14] Completion Timeout (First)
>> [ 44.401943] e1000e 0000:01:00.0 eth0: Timesync Tx Control register
>> not set as expected
>> [ 82.445586] pcieport 0002:00:00.0: PCIe Bus Error:
>> severity=Corrected, type=Physical Layer, id=0000(Receiver ID)
>> [ 82.454851] pcieport 0002:00:00.0: device [17cb:0400] error
>> status/mask=00000001/00006000
>> [ 82.463209] pcieport 0002:00:00.0: [ 0] Receiver Error
>> [ 82.469355] pcieport 0002:00:00.0: PCIe Bus Error:
>> severity=Uncorrected (Non-Fatal), type=Transaction Layer,
>> id=0000(Requester ID)
>> [ 82.481026] pcieport 0002:00:00.0: device [17cb:0400] error
>> status/mask=00004000/00400000
>> [ 82.489343] pcieport 0002:00:00.0: [14] Completion Timeout (First)
>> [ 82.504573] ACPI: \_SB_.PCI2: Device has suffered a power fault
>> [ 84.528036] kernel BUG at drivers/pci/msi.c:369!
>>
>> I'm not sure why it reproduces on the 82571EB card and not the 82574L
>> card. The only obvious difference is there is no Reciever Error on the
>> 82574L card.
>>
>> If you have a patch fixing the inconsistencies you mentioned with the
>> __*_close methods I would certainly be willing to test it out!
>>
>> Thanks,
>> Tyler
>>
>
Hello Tyler,
We do not tried reproduce issues yet. As I know hit on BUG_ON happen on
very old NIC. Our more new NIC do not experienced such problem. I would
like recommend do not change kernel code in this moment. This is very
sensitive for a driver state machine and we afraid from opening lot of
issues. I will investigate more depth this problem later(hope have a
time for it) and let you know if we have suggest fixes for this problem.
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Leon Romanovsky @ 2016-12-04 7:17 UTC (permalink / raw)
To: Pan Bian
Cc: Yishai Hadas, Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma, linux-kernel, Pan Bian
In-Reply-To: <1480833938-6284-1-git-send-email-bianpan201603@163.com>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On Sun, Dec 04, 2016 at 02:45:38PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016@163.com>
>
> If uhw->inlen is non-zero, the value of variable err is 0 if the copy
> succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
> will return 0 to the callers. As a result, the callers cannot detect the
> errors. This patch fixes the bug, assign "-ENOMEM" to err before the
> NULL pointer checks, and remove the initialization of err at the
> beginning.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Pan Bian @ 2016-12-04 6:45 UTC (permalink / raw)
To: Leon Romanovsky, Yishai Hadas, Doug Ledford, Sean Hefty,
Hal Rosenstock, linux-rdma
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
If uhw->inlen is non-zero, the value of variable err is 0 if the copy
succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
will return 0 to the callers. As a result, the callers cannot detect the
errors. This patch fixes the bug, assign "-ENOMEM" to err before the
NULL pointer checks, and remove the initialization of err at the
beginning.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/infiniband/hw/mlx4/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index b597e82..a87c395 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -430,7 +430,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
struct mlx4_ib_dev *dev = to_mdev(ibdev);
struct ib_smp *in_mad = NULL;
struct ib_smp *out_mad = NULL;
- int err = -ENOMEM;
+ int err;
int have_ib_ports;
struct mlx4_uverbs_ex_query_device cmd;
struct mlx4_uverbs_ex_query_device_resp resp = {.comp_mask = 0};
@@ -455,6 +455,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
sizeof(resp.response_length);
in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL);
out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL);
+ err = -ENOMEM;
if (!in_mad || !out_mad)
goto out;
--
1.9.1
^ permalink raw reply related
* arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction
From: kbuild test robot @ 2016-12-04 6:45 UTC (permalink / raw)
To: Pete Delaney; +Cc: kbuild-all, linux-kernel, Chris Zankel, Max Filippov
[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]
Hi Pete,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 0cb65c83304a341b9d09678448d7c8b550689531
commit: d0b73b488c55df905ea8faaad079f8535629ed26 xtensa: Add config files for Diamond 233L - Rev C processor variant
date: 3 years, 9 months ago
config: xtensa-generic_kc705_defconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d0b73b488c55df905ea8faaad079f8535629ed26
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction
vim +41 arch/xtensa/include/asm/initialize_mmu.h
c622b29d Max Filippov 2012-11-19 25
c622b29d Max Filippov 2012-11-19 26 #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19 27
c622b29d Max Filippov 2012-11-19 28 #define XTENSA_HWVERSION_RC_2009_0 230000
c622b29d Max Filippov 2012-11-19 29
c622b29d Max Filippov 2012-11-19 30 .macro initialize_mmu
c622b29d Max Filippov 2012-11-19 31
c622b29d Max Filippov 2012-11-19 32 #if XCHAL_HAVE_S32C1I && (XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19 33 /*
c622b29d Max Filippov 2012-11-19 34 * We Have Atomic Operation Control (ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19 35 * For details see Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19 36 */
c622b29d Max Filippov 2012-11-19 37 #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19 38 movi a3, 0x25 /* For SMP/MX -- internal for writeback,
c622b29d Max Filippov 2012-11-19 39 * RCW otherwise
c622b29d Max Filippov 2012-11-19 40 */
c622b29d Max Filippov 2012-11-19 @41 #else
c622b29d Max Filippov 2012-11-19 42 movi a3, 0x29 /* non-MX -- Most cores use Std Memory
c622b29d Max Filippov 2012-11-19 43 * Controlers which usually can't use RCW
c622b29d Max Filippov 2012-11-19 44 */
c622b29d Max Filippov 2012-11-19 45 #endif
c622b29d Max Filippov 2012-11-19 46 wsr a3, atomctl
c622b29d Max Filippov 2012-11-19 47 #endif /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19 48 * (XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19 49 */
:::::: The code at line 41 was first introduced by commit
:::::: c622b29d1f38021411965b7e0170ab055551b257 xtensa: initialize atomctl SR
:::::: TO: Max Filippov <jcmvbkbc@gmail.com>
:::::: CC: Chris Zankel <chris@zankel.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 7508 bytes --]
^ permalink raw reply
* [PATCH 1/1] net: ethernet: broadcom: fix improper return value
From: Pan Bian @ 2016-12-04 6:29 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2, netdev; +Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
Marco BNX2X_ALLOC_AND_SET(arr, lbl, func) calls kmalloc() to allocate
memory, and jumps to label "lbl" if the allocation fails. Label "lbl"
first cleans memory and then returns variable rc. Before calling the
macro, the value of variable rc is 0. Because 0 means no error, the
callers of bnx2x_init_firmware() may be misled. This patch fixes the bug,
assigning "-ENOMEM" to rc before calling macro NX2X_ALLOC_AND_SET().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189141
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 0cee4c0..6f9fc20 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13505,6 +13505,7 @@ static int bnx2x_init_firmware(struct bnx2x *bp)
/* Initialize the pointers to the init arrays */
/* Blob */
+ rc = -ENOMEM;
BNX2X_ALLOC_AND_SET(init_data, request_firmware_exit, be32_to_cpu_n);
/* Opcodes */
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] xen: set error code on failures
From: Pan Bian @ 2016-12-04 6:24 UTC (permalink / raw)
To: Boris Ostrovsky, David Vrabel, Juergen Gross, xen-devel
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
The return variable rc is initialized with "-ENOMEM" outside the loop.
However, it is reset in the loop, and its value is not negative during
the second or after repeat of the loop. If kzalloc() fails then, it will
return 0. This patch fixes the bug, assigning "-ENOMEM" to rc when
kzalloc() or alloc_page() returns NULL.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189111
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/xen/gntalloc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 7a47c4c..55ef246 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -130,15 +130,19 @@ static int add_grefs(struct ioctl_gntalloc_alloc_gref *op,
rc = -ENOMEM;
for (i = 0; i < op->count; i++) {
gref = kzalloc(sizeof(*gref), GFP_KERNEL);
- if (!gref)
+ if (!gref) {
+ rc = -ENOMEM;
goto undo;
+ }
list_add_tail(&gref->next_gref, &queue_gref);
list_add_tail(&gref->next_file, &queue_file);
gref->users = 1;
gref->file_index = op->index + i * PAGE_SIZE;
gref->page = alloc_page(GFP_KERNEL|__GFP_ZERO);
- if (!gref->page)
+ if (!gref->page) {
+ rc = -ENOMEM;
goto undo;
+ }
/* Grant foreign access to the page. */
rc = gnttab_grant_foreign_access(op->domid,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/1] infiniband: hw: ocrdma: fix bad initialization
From: Leon Romanovsky @ 2016-12-04 6:20 UTC (permalink / raw)
To: Pan Bian
Cc: Selvin Xavier, Devesh Sharma, Mitesh Ahuja, Doug Ledford,
Sean Hefty, Hal Rosenstock, linux-rdma, linux-kernel, Pan Bian
In-Reply-To: <1480770621-6249-1-git-send-email-bianpan201602@163.com>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Sat, Dec 03, 2016 at 09:10:21PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016@163.com>
>
> In function ocrdma_mbx_create_ah_tbl(), returns the value of status on
> errors. However, because status is initialized with 0, 0 will be
> returned even if on error paths. This patch initialize status with
> "-ENOMEM".
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188831
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/1] mtd: ubi: fix improper return value
From: Pan Bian @ 2016-12-04 6:12 UTC (permalink / raw)
To: Artem Bityutskiy, Richard Weinberger, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Cyrille Pitchen,
linux-mtd
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
When __vmalloc() returns a NULL pointer, the region is not checked, and
we cannot make sure that only 0xFF bytes are present at offset. Thus,
returning 0 seems improper.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189081
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/mtd/ubi/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index b6fb8f9..b54fe05 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -1413,7 +1413,7 @@ int ubi_self_check_all_ff(struct ubi_device *ubi, int pnum, int offset, int len)
buf = __vmalloc(len, GFP_NOFS, PAGE_KERNEL);
if (!buf) {
ubi_err(ubi, "cannot allocate memory to check for 0xFFs");
- return 0;
+ return -ENOMEM;
}
err = mtd_read(ubi->mtd, addr, len, &read, buf);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] net: ethernet: qlogic: fix improper return value
From: Pan Bian @ 2016-12-04 6:15 UTC (permalink / raw)
To: Harish Patil, Manish Chopra, Dept-GELinuxNICDev, netdev
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
When the call to qlcnic_alloc_mbx_args() fails, returning variable "err"
seems improper. With reference to the context, returing variable
"config" may be better.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189101
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
index bdbcd2b..21c4aca 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
@@ -3189,7 +3189,7 @@ int qlcnic_83xx_test_link(struct qlcnic_adapter *adapter)
err = qlcnic_alloc_mbx_args(&cmd, adapter, QLCNIC_CMD_GET_LINK_STATUS);
if (err)
- return err;
+ return config;
err = qlcnic_issue_cmd(adapter, &cmd);
if (err) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Leon Romanovsky @ 2016-12-04 6:15 UTC (permalink / raw)
To: Pan Bian
Cc: Yishai Hadas, Doug Ledford, Sean Hefty, Hal Rosenstock,
linux-rdma, linux-kernel, Pan Bian
In-Reply-To: <1480830544-5002-1-git-send-email-bianpan201603@163.com>
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
On Sun, Dec 04, 2016 at 01:49:04PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2016@163.com>
>
> If uhw->inlen is non-zero, the value of variable err is 0 if the copy
> succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
> will return 0 to the callers. As a result, the callers cannot detect the
> errors. This patch fixes the bug, assigning "-ENOMEM" to err before
> the NULL pointer checks.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/infiniband/hw/mlx4/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
> index b597e82..f6c5158 100644
> --- a/drivers/infiniband/hw/mlx4/main.c
> +++ b/drivers/infiniband/hw/mlx4/main.c
> @@ -455,6 +455,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
> sizeof(resp.response_length);
> in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL);
> out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL);
> + err = -ENOMEM;
> if (!in_mad || !out_mad)
> goto out;
In such case, the err initialization at the beginning of
mlx4_ib_query_device function is not necessary. Can you please remove it?
Besides that, look good.
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
>
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/1] net: ethernet: qlogic: set error code on failure
From: Pan Bian @ 2016-12-04 5:53 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2, netdev; +Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
When calling dma_mapping_error(), the value of return variable rc is 0.
And when the call returns an unexpected value, rc is not set to a
negative errno. Thus, it will return 0 on the error path, and its
callers cannot detect the bug. This patch fixes the bug, assigning
"-ENOMEM" to err.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189041
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index f95385c..62ae55b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -1730,6 +1730,7 @@ static int qed_ll2_start_xmit(struct qed_dev *cdev, struct sk_buff *skb)
mapping))) {
DP_NOTICE(cdev,
"Unable to map frag - dropping packet\n");
+ rc = -ENOMEM;
goto err;
}
} else {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 07/13] net: ethernet: ti: cpts: clean up event list if event pool is empty
From: kbuild test robot @ 2016-12-04 6:09 UTC (permalink / raw)
To: Grygorii Strashko
Cc: kbuild-all, David S. Miller, netdev, Mugunthan V N,
Richard Cochran, Sekhar Nori, linux-kernel, linux-omap,
Rob Herring, devicetree, Murali Karicheri, Wingman Kwok,
Thomas Gleixner, Grygorii Strashko
In-Reply-To: <20161202203023.25526-8-grygorii.strashko@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3916 bytes --]
Hi WingMan,
[auto build test ERROR on net/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[cannot apply to net-next/master]
[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/Grygorii-Strashko/net-ethernet-ti-cpts-switch-to-readl-writel_relaxed/20161204-010355
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
Note: the linux-review/Grygorii-Strashko/net-ethernet-ti-cpts-switch-to-readl-writel_relaxed/20161204-010355 HEAD f938805dce662197c057c75ac67849f60da87c9f builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from include/linux/dma-mapping.h:6:0,
from include/linux/skbuff.h:34,
from include/linux/ip.h:20,
from include/linux/ptp_classify.h:26,
from drivers/net/ethernet/ti/cpts.c:25:
drivers/net/ethernet/ti/cpts.c: In function 'cpts_purge_events':
>> drivers/net/ethernet/ti/cpts.c:76:15: error: 'struct cpts' has no member named 'dev'
dev_dbg(cpts->dev, "cpts: event pool cleaned up %d\n", removed);
^
include/linux/device.h:1209:26: note: in definition of macro 'dev_dbg'
dev_printk(KERN_DEBUG, dev, format, ##arg); \
^~~
drivers/net/ethernet/ti/cpts.c: In function 'cpts_fifo_read':
drivers/net/ethernet/ti/cpts.c:94:16: error: 'struct cpts' has no member named 'dev'
dev_err(cpts->dev, "cpts: event pool empty\n");
^~
vim +76 drivers/net/ethernet/ti/cpts.c
19 */
20 #include <linux/err.h>
21 #include <linux/if.h>
22 #include <linux/hrtimer.h>
23 #include <linux/module.h>
24 #include <linux/net_tstamp.h>
> 25 #include <linux/ptp_classify.h>
26 #include <linux/time.h>
27 #include <linux/uaccess.h>
28 #include <linux/workqueue.h>
29 #include <linux/if_ether.h>
30 #include <linux/if_vlan.h>
31
32 #include "cpts.h"
33
34 #define cpts_read32(c, r) readl_relaxed(&c->reg->r)
35 #define cpts_write32(c, v, r) writel_relaxed(v, &c->reg->r)
36
37 static int event_expired(struct cpts_event *event)
38 {
39 return time_after(jiffies, event->tmo);
40 }
41
42 static int event_type(struct cpts_event *event)
43 {
44 return (event->high >> EVENT_TYPE_SHIFT) & EVENT_TYPE_MASK;
45 }
46
47 static int cpts_fifo_pop(struct cpts *cpts, u32 *high, u32 *low)
48 {
49 u32 r = cpts_read32(cpts, intstat_raw);
50
51 if (r & TS_PEND_RAW) {
52 *high = cpts_read32(cpts, event_high);
53 *low = cpts_read32(cpts, event_low);
54 cpts_write32(cpts, EVENT_POP, event_pop);
55 return 0;
56 }
57 return -1;
58 }
59
60 static int cpts_purge_events(struct cpts *cpts)
61 {
62 struct list_head *this, *next;
63 struct cpts_event *event;
64 int removed = 0;
65
66 list_for_each_safe(this, next, &cpts->events) {
67 event = list_entry(this, struct cpts_event, list);
68 if (event_expired(event)) {
69 list_del_init(&event->list);
70 list_add(&event->list, &cpts->pool);
71 ++removed;
72 }
73 }
74
75 if (removed)
> 76 dev_dbg(cpts->dev, "cpts: event pool cleaned up %d\n", removed);
77 return removed ? 0 : -1;
78 }
79
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28475 bytes --]
^ permalink raw reply
* [PATCH 1/1] edac: fix improper return value
From: Pan Bian @ 2016-12-04 6:07 UTC (permalink / raw)
To: Borislav Petkov, Mauro Carvalho Chehab, linux-edac; +Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
When the call to zalloc_cpumask_var() fails, returning "false" seems
improper. The real value of macro "false" is 0, and 0 means no error.
This patch fixes the bug, returning "-ENOMEM".
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189071
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/edac/amd64_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index ee181c5..72a2c75 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2539,7 +2539,7 @@ static int toggle_ecc_err_reporting(struct ecc_settings *s, u16 nid, bool on)
if (!zalloc_cpumask_var(&cmask, GFP_KERNEL)) {
amd64_warn("%s: error allocating mask\n", __func__);
- return false;
+ return -ENOMEM;
}
get_cpus_on_this_dct_cpumask(cmask, nid);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] scsi: snic: fix improper return value
From: Pan Bian @ 2016-12-04 6:02 UTC (permalink / raw)
To: Narsimhulu Musini, Sesidhar Baddela, James E.J. Bottomley,
Martin K. Petersen, linux-scsi
Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
When the calls to mempool_create_slab_pool() return unexpected values,
the value of return variable ret is 0. 0 means no error. Thus, the
caller of fnic_probe() cannot detect the error, and may be misled. This
patch fixes the bug, assigning "-ENOMEM" to ret before calling
mempool_create_slab_pool().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189061
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/scsi/snic/snic_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/snic/snic_main.c b/drivers/scsi/snic/snic_main.c
index 396b32d..e8907e6 100644
--- a/drivers/scsi/snic/snic_main.c
+++ b/drivers/scsi/snic/snic_main.c
@@ -586,6 +586,7 @@
for (i = 0; i < SNIC_IO_LOCKS; i++)
spin_lock_init(&snic->io_req_lock[i]);
+ ret = -ENOMEM;
pool = mempool_create_slab_pool(2,
snic_glob->req_cache[SNIC_REQ_CACHE_DFLT_SGL]);
if (!pool) {
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox