* [net-next v6 1/2] net/tls: Use socket data_ready callback on record availability
From: Vakul Garg @ 2018-07-24 10:14 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In-Reply-To: <20180724101403.27040-1-vakul.garg@nxp.com>
On receipt of a complete tls record, use socket's saved data_ready
callback instead of state_change callback.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 0c2d029c9d4c..fee1240eff92 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1028,7 +1028,7 @@ static void tls_queue(struct strparser *strp, struct sk_buff *skb)
ctx->recv_pkt = skb;
strp_pause(strp);
- strp->sk->sk_state_change(strp->sk);
+ ctx->saved_data_ready(strp->sk);
}
static void tls_data_ready(struct sock *sk)
--
2.13.6
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
From: Jisheng Zhang @ 2018-07-24 5:58 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20180720152117.GB26487@rob-hp-laptop>
Hi Rob,
On Fri, 20 Jul 2018 09:21:17 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:26:26PM +0800, Jisheng Zhang wrote:
> > Add initial dtsi file to support Synaptics AS370 SoC with quad
> > Cortex-A53 CPUs.
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > arch/arm64/boot/dts/synaptics/as370.dtsi | 177 +++++++++++++++++++++++
> > 1 file changed, 177 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/synaptics/as370.dtsi b/arch/arm64/boot/dts/synaptics/as370.dtsi
> > new file mode 100644
> > index 000000000000..20f3d658c566
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/synaptics/as370.dtsi
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (C) 2018 Synaptics Incorporated
> > + *
> > + * Author: Jisheng Zhang <jszhang@kernel.org>
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > + compatible = "syna,as370";
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + aliases {
> > + serial0 = &uart0;
>
> This normally goes in the board file. All boards will use this?
Yes. AFAIK, all boards will use uart0 as the serial console. But I could
move it to the board file.
>
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-1.0";
> > + method = "smc";
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x0>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x1>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x2>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x3>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + l2: cache {
> > + compatible = "cache";
>
> Why do you need this node? Doesn't define
If the l2 node is missing, I will get below warning:
[ 1.364795] Unable to detect cache hierarchy for CPU 0
reported by drivers/base/cacheinfo.c
>
> > + };
> > +
> > + idle-states {
> > + entry-method = "psci";
> > + CPU_SLEEP_0: cpu-sleep-0 {
> > + compatible = "arm,idle-state";
> > + local-timer-stop;
> > + arm,psci-suspend-param = <0x0010000>;
> > + entry-latency-us = <75>;
> > + exit-latency-us = <155>;
> > + min-residency-us = <1000>;
> > + };
> > + };
> > + };
> > +
> > + osc: osc {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <25000000>;
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu0>,
> > + <&cpu1>,
> > + <&cpu2>,
> > + <&cpu3>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > + };
> > +
> > + soc@f7000000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0 0xf7000000 0x1000000>;
> > +
> > + gic: interrupt-controller@901000 {
> > + compatible = "arm,gic-400";
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + reg = <0x901000 0x1000>,
> > + <0x902000 0x2000>,
> > + <0x904000 0x2000>,
> > + <0x906000 0x2000>;
> > + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > + };
> > +
> > + apb@e80000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0xe80000 0x10000>;
> > +
> > + uart0: uart@0c00 {
>
> serial@c00
will do in v2
Thanks a lot
^ permalink raw reply
* [PATCH 3/3] arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
From: Jisheng Zhang @ 2018-07-24 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720152117.GB26487@rob-hp-laptop>
Hi Rob,
On Fri, 20 Jul 2018 09:21:17 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:26:26PM +0800, Jisheng Zhang wrote:
> > Add initial dtsi file to support Synaptics AS370 SoC with quad
> > Cortex-A53 CPUs.
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > arch/arm64/boot/dts/synaptics/as370.dtsi | 177 +++++++++++++++++++++++
> > 1 file changed, 177 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/synaptics/as370.dtsi b/arch/arm64/boot/dts/synaptics/as370.dtsi
> > new file mode 100644
> > index 000000000000..20f3d658c566
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/synaptics/as370.dtsi
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (C) 2018 Synaptics Incorporated
> > + *
> > + * Author: Jisheng Zhang <jszhang@kernel.org>
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > + compatible = "syna,as370";
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + aliases {
> > + serial0 = &uart0;
>
> This normally goes in the board file. All boards will use this?
Yes. AFAIK, all boards will use uart0 as the serial console. But I could
move it to the board file.
>
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-1.0";
> > + method = "smc";
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu at 0 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x0>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + cpu1: cpu at 1 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x1>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + cpu2: cpu at 2 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x2>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + cpu3: cpu at 3 {
> > + compatible = "arm,cortex-a53", "arm,armv8";
> > + device_type = "cpu";
> > + reg = <0x3>;
> > + enable-method = "psci";
> > + next-level-cache = <&l2>;
> > + cpu-idle-states = <&CPU_SLEEP_0>;
> > + };
> > +
> > + l2: cache {
> > + compatible = "cache";
>
> Why do you need this node? Doesn't define
If the l2 node is missing, I will get below warning:
[ 1.364795] Unable to detect cache hierarchy for CPU 0
reported by drivers/base/cacheinfo.c
>
> > + };
> > +
> > + idle-states {
> > + entry-method = "psci";
> > + CPU_SLEEP_0: cpu-sleep-0 {
> > + compatible = "arm,idle-state";
> > + local-timer-stop;
> > + arm,psci-suspend-param = <0x0010000>;
> > + entry-latency-us = <75>;
> > + exit-latency-us = <155>;
> > + min-residency-us = <1000>;
> > + };
> > + };
> > + };
> > +
> > + osc: osc {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <25000000>;
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu0>,
> > + <&cpu1>,
> > + <&cpu2>,
> > + <&cpu3>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > + };
> > +
> > + soc at f7000000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0 0xf7000000 0x1000000>;
> > +
> > + gic: interrupt-controller at 901000 {
> > + compatible = "arm,gic-400";
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + reg = <0x901000 0x1000>,
> > + <0x902000 0x2000>,
> > + <0x904000 0x2000>,
> > + <0x906000 0x2000>;
> > + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > + };
> > +
> > + apb at e80000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0xe80000 0x10000>;
> > +
> > + uart0: uart at 0c00 {
>
> serial at c00
will do in v2
Thanks a lot
^ permalink raw reply
* [MODERATED] Re: [RFC PATCH 4/6] kvm: handle host mode irqs 4
From: Nicolai Stange @ 2018-07-24 5:58 UTC (permalink / raw)
To: speck
In-Reply-To: <20180723154021.GE35943@tassilo.jf.intel.com>
speck for Andi Kleen <speck@linutronix.de> writes:
>> +.macro TRACK_KERNEL_MODE_IRQ
>> +#ifdef CONFIG_X86_TRACK_KERNEL_MODE_IRQS
>> + /*
>> + * Increment the kernel mode irq generation count even if
>> + * coming from userspace -- nobody will care.
>> + */
>> + incl PER_CPU_VAR(kernel_mode_irq_gen)
>> +#endif
>> +.endm
>
> You can put it into irq_enter/exit, no need to mess with assembler code.
The reason I put it there was to avoid touching anything outside of
arch/x86.
In addition,
- uv_bau_message_interrupt() doesn't call irq_enter() at all,
- smp_reschedule_interrupt() calls it conditionally
But I'm not sure it matters much and either way is fine by me.
Thanks,
Nicolai
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 1/2] mtd: lpddr: use mtd_device_register()
From: Boris Brezillon @ 2018-07-24 5:57 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Miquel Raynal, Bert Kenward, linux-mtd,
Rafał Miłecki
In-Reply-To: <20180721115510.24078-1-zajec5@gmail.com>
On Sat, 21 Jul 2018 13:55:09 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This driver doesn't specify parsers so it can use that little helper.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Applied this one to mtd/next.
> ---
> drivers/mtd/lpddr/lpddr2_nvm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/lpddr/lpddr2_nvm.c b/drivers/mtd/lpddr/lpddr2_nvm.c
> index 5d73db2a496d..c950c880ad59 100644
> --- a/drivers/mtd/lpddr/lpddr2_nvm.c
> +++ b/drivers/mtd/lpddr/lpddr2_nvm.c
> @@ -476,7 +476,7 @@ static int lpddr2_nvm_probe(struct platform_device *pdev)
> return -EINVAL;
> }
> /* Parse partitions and register the MTD device */
> - return mtd_device_parse_register(mtd, NULL, NULL, NULL, 0);
> + return mtd_device_register(mtd, NULL, 0);
> }
>
> /*
^ permalink raw reply
* [PATCH] audit: fix potential null dereference 'context->module.name'
From: Yi Wang @ 2018-07-24 5:57 UTC (permalink / raw)
To: paul
Cc: eparis, linux-audit, linux-kernel, jiang.biao2, wang.yi59,
zhong.weidong
The variable 'context->module.name' may be null pointer when
kmalloc return null, so it's better to check it before using
to avoid null dereference.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
---
kernel/auditsc.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e80459f..4830b83 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1272,8 +1272,12 @@ static void show_special(struct audit_context *context, int *call_panic)
break;
case AUDIT_KERN_MODULE:
audit_log_format(ab, "name=");
- audit_log_untrustedstring(ab, context->module.name);
- kfree(context->module.name);
+ if (context->module.name) {
+ audit_log_untrustedstring(ab, context->module.name);
+ kfree(context->module.name);
+ } else
+ audit_log_format(ab, "(null)");
+
break;
}
audit_log_end(ab);
@@ -2409,7 +2413,8 @@ void __audit_log_kern_module(char *name)
struct audit_context *context = current->audit_context;
context->module.name = kmalloc(strlen(name) + 1, GFP_KERNEL);
- strcpy(context->module.name, name);
+ if (context->module.name)
+ strcpy(context->module.name, name);
context->type = AUDIT_KERN_MODULE;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 01/12] mfd: dt-bindings: Add wcd9335 mfd bindings
From: Vinod @ 2018-07-24 5:56 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: lee.jones, robh+dt, broonie, mark.rutland, lgirdwood, tiwai,
bgoswami, devicetree, linux-kernel, alsa-devel
In-Reply-To: <20180723155410.9494-2-srinivas.kandagatla@linaro.org>
On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC, supports
> Qualcomm Technologies, Inc. (QTI) multimedia solutions, including
> the MSM8996, MSM8976, and MSM8956 chipsets. It has in-build
in-built perhaps?
--
~Vinod
^ permalink raw reply
* Re: [PATCH 01/12] mfd: dt-bindings: Add wcd9335 mfd bindings
From: Vinod @ 2018-07-24 5:56 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: mark.rutland, devicetree, alsa-devel, bgoswami, linux-kernel,
lgirdwood, robh+dt, tiwai, broonie, lee.jones
In-Reply-To: <20180723155410.9494-2-srinivas.kandagatla@linaro.org>
On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC, supports
> Qualcomm Technologies, Inc. (QTI) multimedia solutions, including
> the MSM8996, MSM8976, and MSM8956 chipsets. It has in-build
in-built perhaps?
--
~Vinod
^ permalink raw reply
* Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
From: Leon Romanovsky @ 2018-07-24 5:56 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180724024236.GA16958@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
On Mon, Jul 23, 2018 at 08:42:36PM -0600, Jason Gunthorpe wrote:
> On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog:
> > v1->v2:
> > * Fix matcher to use the correct size.
> > * Rephrase commit log of the first patch.
> > v0->v1:
> > * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address.
> > ?* Replaced UA_ALLOC_AND_COPY to regular copy_from
> > * Added UVERBS_ATTR_NO_DATA new macro for cleaner code.
> > * Used ib_dev from uobj when it exists.
> > * ib_is_destroy_retryable was replaced by ib_destroy_usecnt
> >
> > >From Yishai:
> >
> > This series introduces vendor create and destroy flow methods on the
> > uverbs flow object by using the KABI infra-structure.
> >
> > It's done in a way that enables the driver to get its specific device
> > attributes in a raw data to match its underlay specification while still
> > using the generic ib_flow object for cleanup and code sharing.
> >
> > In addition, a specific mlx5 matcher object and its create/destroy
> > methods were introduced. This object matches the underlay flow steering
> > mask specification and is used as part of mlx5 create flow input data.
> >
> > This series supports IB_QP/TIR as its flow steering destination as
> > applicable today via the ib_create_flow API, however, it adds also an
> > option to work with DEVX object which its destination can be both TIR
> > and flow table.
> >
> > Few changes were done in the mlx5 core layer to support forward
> > compatible for the device specification raw data and to support flow
> > table when the DEVX destination is used.
> >
> > As part of this series the default IB destroy handler
> > (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be
> > used by the drivers and existing code was refactored to use it.
> >
> > Thanks
> >
> > Yishai Hadas (8):
> > net/mlx5: Add forward compatible support for the FTE match data
> > net/mlx5: Add support for flow table destination number
> > IB/mlx5: Introduce flow steering matcher object
> > IB: Consider ib_flow creation by the KABI infrastructure
> > IB/mlx5: Introduce vendor create and destroy flow methods
> > IB/mlx5: Support adding flow steering rule by raw data
> > IB/mlx5: Add support for a flow table destination
> > IB/mlx5: Expose vendor flow trees
>
> This seems fine to me. Can you send the mlx5 shared branch for the
> first two patches?
I applied two first patches with Acked-by from Saeed to mlx5-next
664000b6bb43 net/mlx5: Add support for flow table destination number
2aada6c0c96e net/mlx5: Add forward compatible support for the FTE match data
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] drm/tegra: hdmi: probe deferral error reporting
From: Marcel Ziswiler @ 2018-07-24 5:55 UTC (permalink / raw)
To: Lucas Stach, linux-tegra
Cc: Marcel Ziswiler, linux-kernel, dri-devel, Jonathan Hunter,
David Airlie, Thierry Reding
In-Reply-To: <228cdf6fe37298223d77b52fd4cdb821b0da7d11.camel@lynxeye.de>
On July 23, 2018 10:49:15 PM GMT+02:00, Lucas Stach <dev@lynxeye.de> wrote:
>Am Freitag, den 20.07.2018, 09:55 +0200 schrieb Marcel Ziswiler:
>> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>>
>> Actually report the error code from devm_regulator_get() which may as
>> well just be a probe deferral.
>
>This is still noisy, so while you are changing this I would prefer if
>this wouldn't print the error message if it's a simple probe deferral.
Yeah, trust me, I'm not the inventor of this probe deferral disaster!
>Suppressing the log message in that case gets us much cleaner kernel
>logs, where real errors stand out.
Ok, agreed. Will send a v2.
>Regards,
>Lucas
>
>>
>> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>>
>> ---
>>
>> drivers/gpu/drm/tegra/hdmi.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/hdmi.c
>b/drivers/gpu/drm/tegra/hdmi.c
>> index 0082468f703c..94c182dbb6d0 100644
>> --- a/drivers/gpu/drm/tegra/hdmi.c
>> +++ b/drivers/gpu/drm/tegra/hdmi.c
>> @@ -1693,14 +1693,16 @@ static int tegra_hdmi_probe(struct
>platform_device *pdev)
>>
>> hdmi->hdmi = devm_regulator_get(&pdev->dev, "hdmi");
>> if (IS_ERR(hdmi->hdmi)) {
>> - dev_err(&pdev->dev, "failed to get HDMI regulator\n");
>> - return PTR_ERR(hdmi->hdmi);
>> + err = PTR_ERR(hdmi->hdmi);
>> + dev_err(&pdev->dev, "failed to get HDMI regulator: %d\n", err);
>> + return err;
>> }
>>
>> hdmi->pll = devm_regulator_get(&pdev->dev, "pll");
>> if (IS_ERR(hdmi->pll)) {
>> - dev_err(&pdev->dev, "failed to get PLL regulator\n");
>> - return PTR_ERR(hdmi->pll);
>> + err = PTR_ERR(hdmi->pll);
>> + dev_err(&pdev->dev, "failed to get PLL regulator: %d\n", err);
>> + return err;
>> }
>>
>> hdmi->vdd = devm_regulator_get(&pdev->dev, "vdd");
^ permalink raw reply
* Re: [Qemu-devel] Virtual IOMMU + Virtio-net devices in a Windows VM doesn't work
From: Peter Xu @ 2018-07-24 5:55 UTC (permalink / raw)
To: Jintack Lim; +Cc: QEMU Devel Mailing List, Jason Wang, Michael S. Tsirkin
In-Reply-To: <CAHyh4xjUmwHr7b=92y7YUwKGSW0o+FUMwJLSehdzuFc3R6eLTg@mail.gmail.com>
On Mon, Jul 23, 2018 at 04:13:18PM -0400, Jintack Lim wrote:
> Hi,
>
> I'm running a Windows VM on top of KVM on x86, and one of virtio-net
> device in the Windows VM doesn't seem to work. I provided virtual
> IOMMU and two virtio-net devices to the VM: one bypassing the virtual
> IOMMU and the other one behind the virtual IOMMU[1]. It turned out
> that the virtio-net device behind virtual IOMMU didn't work while the
> one bypassing the virtual IOMMU worked well. In a linux VM with the
> same configuration, both of virtio-net device worked well.
>
> I found that there is a subtle difference between virtio-net devices
> bypassing and behind virtual IOMMU in a Linux VM. The lscpu command in
> the Linux VM shows different device names for them; the first line is
> for the bypassing one, and the second line is for the one behind the
> virtual IOMMU
>
> 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
> 01:00.0 Ethernet controller: Red Hat, Inc Device 1041 (rev 01)
>
> I wonder if this difference somehow caused the problem in the Windows
> VM. I've installed the latest virtio drivers (0.1.149) from the fedora
> project [2]
>
> Any thoughts?
>
> I'm using v4.15 Linux kernel as a host, and QEMU 2.11.0.
Have you tried the latest QEMU?
Also CC Jason and Michael.
>
> Thanks,
> Jintack
>
> [1] https://wiki.qemu.org/Features/VT-d
> [2] https://docs.fedoraproject.org/quick-docs/en-US/creating-windows-virtual-machines-using-virtio-drivers.html
>
>
Regards,
--
Peter Xu
^ permalink raw reply
* Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)
From: Junio C Hamano @ 2018-07-24 5:54 UTC (permalink / raw)
To: Ben Peart; +Cc: Duy Nguyen, Jeff King, Ben Peart, Git Mailing List
In-Reply-To: <6ff6fbdc-d9cf-019f-317c-7fdba31105c6@gmail.com>
Ben Peart <peartben@gmail.com> writes:
>> Hmm.. this means cache-tree is fully valid, unless you have changes in
>> index. We're quite aggressive in repairing cache-tree since aecf567cbf
>> (cache-tree: create/update cache-tree on checkout - 2014-07-05). If we
>> have very good cache-tree records and still spend 33s on
>> traverse_trees, maybe there's something else.
>>
>
> I'm not at all familiar with the cache-tree and couldn't find any
> documentation on it other than index-format.txt which says "it helps
> speed up tree object generation for a new commit." In this particular
> case, no new commit is being created so I don't know that the
> cache-tree would help.
cache-tree is an index extension that records tree object names for
subdirectories you see in the index. Every time you write the
contents of the index as a tree object, we need to collect the
object name for each top-level paths and write a new top-level tree
object out, after doing the same recursively for any modified
subdirectory. Whenever you add, remove or modify a path in the
index, the cache-tree entry for enclosing directories are
invalidated, so a cache-tree entry that is still valid means that
all the paths in the index under that directory match the contents
of the tree object that the cache-tree entry holds.
And that property is used by "diff-index --cached $TREE" that is run
internally. When we find that the subdirectory "D"'s cache-tree
entry is valid in the index, and the tree object recorded in the
cache-tree for that subdirectory matches the subtree D in the tree
object $TREE, then "diff-index --cached" ignores the entire
subdirectory D (which saves relatively little in the index as it
only needs to scan what is already in the memory forward, but on the
$TREE traversal side, it does not have to even open a subtree, that
can save a lot), and with a well-populated cache-tree, it can save a
significant processing.
I think that is what Duy meant to refer to while looking at the
numbers.
> After a quick look at the code, the only place I can find that tries
> to use cache_tree_matches_traversal() is in unpack_callback() and that
> only happens if n == 1 and in the "git checkout" case, n == 2. Am I
> missing something?
^ permalink raw reply
* Re: [PATCH 00/12] mfd: Add support to WCD9335 Audio Codec
From: Vinod @ 2018-07-24 5:53 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: lee.jones, robh+dt, broonie, mark.rutland, lgirdwood, tiwai,
bgoswami, devicetree, linux-kernel, alsa-devel
In-Reply-To: <20180723155410.9494-1-srinivas.kandagatla@linaro.org>
On 23-07-18, 16:53, Srinivas Kandagatla wrote:
> Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC.
> It is integrated in multiple Qualcomm SoCs like: MSM8996, MSM8976,
> and MSM8956 chipsets.
>
> WCD9335 had multiple functional blocks, like: Soundwire controller,
> interrupt mux, pin controller, Audio codec, MBHC, MAD(Mic activity Detection),
MBHC ??
> Ultrasonic proximity and pen detection, Battery-voltage monitoring and
> Codec processing engine.
>
> Currently this patchset has been only tested with SLIMbus interface due
> to hardware avaiablity, but it can be easily made to work with both SLIMbus
typo avaiablity
> and I2C/I2S.
>
> This patchset adds very basic playback and capture support witout much
> fancy features. New features will be added once the basic support is in.
> This patchset is tested on top of linux-next on DB820c for both playback
> and capture paths.
>
> This patchset also depends on the SLIMbus Stream apis which is already merged
> via char-misc tree for 4.19.
>
> Some parts of the code has been inherited from Qualcomm andriod kernel,
typo andriod
--
~Vinod
^ permalink raw reply
* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: David Miller @ 2018-07-24 4:49 UTC (permalink / raw)
To: vakul.garg; +Cc: davejwatson, netdev, borisp, aviadye, doronrk
In-Reply-To: <DB7PR04MB4252DEFEDC63C40EF287F22D8B550@DB7PR04MB4252.eurprd04.prod.outlook.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Tue, 24 Jul 2018 04:43:55 +0000
> Can you still apply the rest of two patches in the series or do I
> need to send them again separately?
When a change of any kind needs to be made to a patch series, you must
always resubmit the entire series.
Thank you.
^ permalink raw reply
* [PATCH] selftests/powerpc: Add a test of wild bctr
From: Michael Ellerman @ 2018-07-24 5:53 UTC (permalink / raw)
To: linuxppc-dev
This tests that a bctr (Branch to counter and link), ie. a function
call, to a wildly out-of-bounds address is handled correctly.
Some old kernel versions didn't handle it correctly, see eg:
"powerpc/slb: Force a full SLB flush when we insert for a bad EA"
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-April/157397.html
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/include/reg.h | 1 +
tools/testing/selftests/powerpc/mm/.gitignore | 3 +-
tools/testing/selftests/powerpc/mm/Makefile | 2 +-
tools/testing/selftests/powerpc/mm/wild_bctr.c | 153 +++++++++++++++++++++++++
4 files changed, 157 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/mm/wild_bctr.c
diff --git a/tools/testing/selftests/powerpc/include/reg.h b/tools/testing/selftests/powerpc/include/reg.h
index 7f348c059bc2..52b4710469d2 100644
--- a/tools/testing/selftests/powerpc/include/reg.h
+++ b/tools/testing/selftests/powerpc/include/reg.h
@@ -17,6 +17,7 @@
: "memory")
#define mb() asm volatile("sync" : : : "memory");
+#define barrier() asm volatile("" : : : "memory");
#define SPRN_MMCR2 769
#define SPRN_MMCRA 770
diff --git a/tools/testing/selftests/powerpc/mm/.gitignore b/tools/testing/selftests/powerpc/mm/.gitignore
index 7d7c42ed6de9..ba919308fe30 100644
--- a/tools/testing/selftests/powerpc/mm/.gitignore
+++ b/tools/testing/selftests/powerpc/mm/.gitignore
@@ -2,4 +2,5 @@ hugetlb_vs_thp_test
subpage_prot
tempfile
prot_sao
-segv_errors
\ No newline at end of file
+segv_errors
+wild_bctr
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/mm/Makefile b/tools/testing/selftests/powerpc/mm/Makefile
index 8ebbe96d80a8..893ad41460af 100644
--- a/tools/testing/selftests/powerpc/mm/Makefile
+++ b/tools/testing/selftests/powerpc/mm/Makefile
@@ -2,7 +2,7 @@
noarg:
$(MAKE) -C ../
-TEST_GEN_PROGS := hugetlb_vs_thp_test subpage_prot prot_sao segv_errors
+TEST_GEN_PROGS := hugetlb_vs_thp_test subpage_prot prot_sao segv_errors wild_bctr
TEST_GEN_FILES := tempfile
include ../../lib.mk
diff --git a/tools/testing/selftests/powerpc/mm/wild_bctr.c b/tools/testing/selftests/powerpc/mm/wild_bctr.c
new file mode 100644
index 000000000000..f8a2901dc44e
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/wild_bctr.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018, Michael Ellerman, IBM Corp.
+ *
+ * Test that an out-of-bounds branch to counter behaves as expected.
+ */
+
+#include <setjmp.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/mman.h>
+#include <ucontext.h>
+#include <unistd.h>
+
+#include "utils.h"
+
+
+#define BAD_NIP 0x788c545a18000000ull
+
+static struct pt_regs signal_regs;
+static jmp_buf setjmp_env;
+
+static void save_regs(ucontext_t *ctxt)
+{
+ struct pt_regs *regs = ctxt->uc_mcontext.regs;
+
+ memcpy(&signal_regs, regs, sizeof(signal_regs));
+}
+
+static void segv_handler(int signum, siginfo_t *info, void *ctxt_v)
+{
+ save_regs(ctxt_v);
+ longjmp(setjmp_env, 1);
+}
+
+static void usr2_handler(int signum, siginfo_t *info, void *ctxt_v)
+{
+ save_regs(ctxt_v);
+}
+
+static int ok(void)
+{
+ printf("Everything is OK in here.\n");
+ return 0;
+}
+
+#define REG_POISON 0x5a5aUL
+#define POISONED_REG(n) ((REG_POISON << 48) | ((n) << 32) | (REG_POISON << 16) | (n))
+
+static inline void poison_regs(void)
+{
+ #define POISON_REG(n) \
+ "lis " __stringify(n) "," __stringify(REG_POISON) ";" \
+ "addi " __stringify(n) "," __stringify(n) "," __stringify(n) ";" \
+ "sldi " __stringify(n) "," __stringify(n) ", 32 ;" \
+ "oris " __stringify(n) "," __stringify(n) "," __stringify(REG_POISON) ";" \
+ "addi " __stringify(n) "," __stringify(n) "," __stringify(n) ";"
+
+ asm (POISON_REG(15)
+ POISON_REG(16)
+ POISON_REG(17)
+ POISON_REG(18)
+ POISON_REG(19)
+ POISON_REG(20)
+ POISON_REG(21)
+ POISON_REG(22)
+ POISON_REG(23)
+ POISON_REG(24)
+ POISON_REG(25)
+ POISON_REG(26)
+ POISON_REG(27)
+ POISON_REG(28)
+ POISON_REG(29)
+ : // inputs
+ : // outputs
+ : "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25",
+ "26", "27", "28", "29"
+ );
+ #undef POISON_REG
+}
+
+static int check_regs(void)
+{
+ unsigned long i;
+
+ for (i = 15; i <= 29; i++)
+ FAIL_IF(signal_regs.gpr[i] != POISONED_REG(i));
+
+ printf("Regs OK\n");
+ return 0;
+}
+
+static void dump_regs(void)
+{
+ for (int i = 0; i < 32; i += 4) {
+ printf("r%02d 0x%016lx r%02d 0x%016lx " \
+ "r%02d 0x%016lx r%02d 0x%016lx\n",
+ i, signal_regs.gpr[i],
+ i+1, signal_regs.gpr[i+1],
+ i+2, signal_regs.gpr[i+2],
+ i+3, signal_regs.gpr[i+3]);
+ }
+}
+
+int test_wild_bctr(void)
+{
+ int (*func_ptr)(void);
+ struct sigaction segv = {
+ .sa_sigaction = segv_handler,
+ .sa_flags = SA_SIGINFO
+ };
+ struct sigaction usr2 = {
+ .sa_sigaction = usr2_handler,
+ .sa_flags = SA_SIGINFO
+ };
+
+ FAIL_IF(sigaction(SIGSEGV, &segv, NULL));
+ FAIL_IF(sigaction(SIGUSR2, &usr2, NULL));
+
+ bzero(&signal_regs, sizeof(signal_regs));
+
+ if (setjmp(setjmp_env) == 0) {
+ func_ptr = ok;
+ func_ptr();
+
+ kill(getpid(), SIGUSR2);
+ printf("Regs before:\n");
+ dump_regs();
+ bzero(&signal_regs, sizeof(signal_regs));
+
+ poison_regs();
+
+ func_ptr = (int (*)(void))BAD_NIP;
+ func_ptr();
+
+ FAIL_IF(1); /* we didn't segv? */
+ }
+
+ FAIL_IF(signal_regs.nip != BAD_NIP);
+
+ printf("All good - took SEGV as expected branching to 0x%llx\n", BAD_NIP);
+
+ dump_regs();
+ FAIL_IF(check_regs());
+
+ return 0;
+}
+
+int main(void)
+{
+ return test_harness(test_wild_bctr, "wild_bctr");
+}
--
2.14.1
^ permalink raw reply related
* Re: xfsprogs-dev failing to build
From: Vincent McIntyre @ 2018-07-24 4:37 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <20180724042738.GS4813@magnolia>
On Mon, Jul 23, 2018 at 09:27:38PM -0700, Darrick J. Wong wrote:
> On Tue, Jul 24, 2018 at 02:09:44PM +1000, Vincent McIntyre wrote:
> > Hi
> >
> > I am trying to build the latest xfsprogs on an older system,
> > details below. The configure script is failing on what appears
> > to be an unexpanded m4 macro,
> >
> > PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)
>
> Hmmm, I thought that pkg.m4 would be pulled in via aclocal
> automatically, but I could be wrong. :/
>
> What version of pkg-config (or I guess pkgconf?) is on the system?
>
It was not actually installed, and that was the problem.
The tree builds ok now, and xfs_repair -n works ok.
A bit odd pkg-config was not installed, I had installed the
'build-essential' metapackage but I guess it didn't pull in.
> > I'm not quite sure how to work around this or if it is a bug.
> > Any advice would be appreciated.
>
> Definitely some sort of bug...
I think the only fix needed is for the xfs.org faq page
- apt-get install libtool automake gettext libblkid-dev uuid-dev
+ apt-get install libtool automake gettext libblkid-dev uuid-dev pkg-config
Possibly libicu-dev should be added to the list also.
Thanks for the fast response.
Cheers
Vince
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix possible endless loop when clearing flow flags
From: Ori Kam @ 2018-07-24 5:50 UTC (permalink / raw)
To: Yongseok Koh, Shahaf Shuler
Cc: dev@dpdk.org, Yongseok Koh, Nélio Laranjeiro
In-Reply-To: <20180723182744.1179-1-yskoh@mellanox.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yongseok Koh
> Sent: Monday, July 23, 2018 9:28 PM
> To: Shahaf Shuler <shahafs@mellanox.com>
> Cc: dev@dpdk.org; Yongseok Koh <yskoh@mellanox.com>; Nélio Laranjeiro
> <nelio.laranjeiro@6wind.com>
> Subject: [dpdk-dev] [PATCH] net/mlx5: fix possible endless loop when
> clearing flow flags
>
> If one of (*priv->rxqs)[] is null, the for loop can iterate infinitely as
> idx can't be increased.
>
> Fixes: cd24d526395e ("net/mlx5: add mark/flag flow action")
> Cc: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> ---
> drivers/net/mlx5/mlx5_flow.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index 32854198b..c156f01eb 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -2762,22 +2762,20 @@ mlx5_flow_rxq_flags_clear(struct rte_eth_dev
> *dev)
> {
> struct priv *priv = dev->data->dev_private;
> unsigned int i;
> - unsigned int idx;
>
> - for (idx = 0, i = 0; idx != priv->rxqs_n; ++i) {
> + for (i = 0; i != priv->rxqs_n; ++i) {
> struct mlx5_rxq_ctrl *rxq_ctrl;
> unsigned int j;
>
> - if (!(*priv->rxqs)[idx])
> + if (!(*priv->rxqs)[i])
> continue;
> - rxq_ctrl = container_of((*priv->rxqs)[idx],
> + rxq_ctrl = container_of((*priv->rxqs)[i],
> struct mlx5_rxq_ctrl, rxq);
> rxq_ctrl->flow_mark_n = 0;
> rxq_ctrl->rxq.mark = 0;
> for (j = 0; j != MLX5_FLOW_TUNNEL; ++j)
> rxq_ctrl->flow_tunnels_n[j] = 0;
> rxq_ctrl->rxq.tunnel = 0;
> - ++idx;
> }
> }
>
Acked-by: Ori Kam <orika@mellanox.com>
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH v2] mtd/maps: fix solutionengine.c printk format warnings
From: Boris Brezillon @ 2018-07-24 5:49 UTC (permalink / raw)
To: Randy Dunlap
Cc: LKML, Linux-sh list, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, linux-mtd, Yoshinori Sato, Rich Felker,
Sergei Shtylyov
In-Reply-To: <0ca72308-0551-97dc-dc74-11e1d8dac5b1@infradead.org>
On Sun, 22 Jul 2018 16:28:52 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix 2 printk format warnings (this driver is currently only used by
> arch/sh/) by using "%pap" instead of "%lx".
> (or we could just cast the physical addresses to unsigned int)
>
> Fixes these build warnings:
>
> ../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
> ../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 'unsigned int'} [-Wformat=]
> ../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
> printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
> ~~~~^
> %08x
> ../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 'unsigned int'} [-Wformat=]
> ../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
> printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
> ~~~~^
> %08x
>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Brian Norris <computersforpeace@gmail.com>
> Cc: Boris Brezillon <boris.brezillon@bootlin.com>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: linux-mtd@lists.infradead.org
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: linux-sh@vger.kernel.org
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> v2: indent all lines inside the new block
>
> drivers/mtd/maps/solutionengine.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> --- linux-next-20180717.orig/drivers/mtd/maps/solutionengine.c
> +++ linux-next-20180717/drivers/mtd/maps/solutionengine.c
> @@ -59,9 +59,14 @@ static int __init init_soleng_maps(void)
> return -ENXIO;
> }
> }
> - printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
> - soleng_flash_map.phys & 0x1fffffff,
> - soleng_eprom_map.phys & 0x1fffffff);
Hm, not sure why masking with 0x1fffffff is required. It seems .phys is
either 0 or 0x1000000, so maybe we should just go for
printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 0x%pap\n",
&soleng_flash_map.phys, &soleng_eprom_map.phys);
> + {
> + resource_size_t fl_phys = soleng_flash_map.phys & 0x1fffffff;
> + resource_size_t ep_phys = soleng_eprom_map.phys & 0x1fffffff;
> +
> + printk(KERN_NOTICE
> + "Solution Engine: Flash at 0x%pap, EPROM at 0x%pap\n",
> + &fl_phys, &ep_phys);
> + }
> flash_mtd->owner = THIS_MODULE;
>
> eprom_mtd = do_map_probe("map_rom", &soleng_eprom_map);
>
>
^ permalink raw reply
* Re: [PATCH v2] mtd/maps: fix solutionengine.c printk format warnings
From: Boris Brezillon @ 2018-07-24 5:49 UTC (permalink / raw)
To: Randy Dunlap
Cc: LKML, Linux-sh list, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, linux-mtd, Yoshinori Sato, Rich Felker,
Sergei Shtylyov
In-Reply-To: <0ca72308-0551-97dc-dc74-11e1d8dac5b1@infradead.org>
On Sun, 22 Jul 2018 16:28:52 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix 2 printk format warnings (this driver is currently only used by
> arch/sh/) by using "%pap" instead of "%lx".
> (or we could just cast the physical addresses to unsigned int)
>
> Fixes these build warnings:
>
> ../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
> ../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 'unsigned int'} [-Wformat=]
> ../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
> printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
> ~~~~^
> %08x
> ../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 'unsigned int'} [-Wformat=]
> ../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
> printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
> ~~~~^
> %08x
>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Brian Norris <computersforpeace@gmail.com>
> Cc: Boris Brezillon <boris.brezillon@bootlin.com>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: linux-mtd@lists.infradead.org
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: linux-sh@vger.kernel.org
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> v2: indent all lines inside the new block
>
> drivers/mtd/maps/solutionengine.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> --- linux-next-20180717.orig/drivers/mtd/maps/solutionengine.c
> +++ linux-next-20180717/drivers/mtd/maps/solutionengine.c
> @@ -59,9 +59,14 @@ static int __init init_soleng_maps(void)
> return -ENXIO;
> }
> }
> - printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
> - soleng_flash_map.phys & 0x1fffffff,
> - soleng_eprom_map.phys & 0x1fffffff);
Hm, not sure why masking with 0x1fffffff is required. It seems .phys is
either 0 or 0x1000000, so maybe we should just go for
printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 0x%pap\n",
&soleng_flash_map.phys, &soleng_eprom_map.phys);
> + {
> + resource_size_t fl_phys = soleng_flash_map.phys & 0x1fffffff;
> + resource_size_t ep_phys = soleng_eprom_map.phys & 0x1fffffff;
> +
> + printk(KERN_NOTICE
> + "Solution Engine: Flash at 0x%pap, EPROM at 0x%pap\n",
> + &fl_phys, &ep_phys);
> + }
> flash_mtd->owner = THIS_MODULE;
>
> eprom_mtd = do_map_probe("map_rom", &soleng_eprom_map);
>
>
^ permalink raw reply
* [LTP] [RFC PATCH 1/1] pounder21: Remove
From: Petr Vorel @ 2018-07-24 5:49 UTC (permalink / raw)
To: ltp
In-Reply-To: <CAEemH2ez26eEbpcuKx2nd7WhKeR2tEP6BSGkWpsEYmK733PB1g@mail.gmail.com>
Hi Jan, Li,
> On Mon, Jul 23, 2018 at 8:46 PM, Jan Stancek <jstancek@redhat.com> wrote:
> > ----- Original Message -----
> > > It's is obsolete, not being built.
> > I think Li runs this internally.
> I occasionally use the pounder suit as a stress test to run more than 24
> hours.
> But I'm OK to remove it from the latest ltp because it has long time no
> substantive updating and the version I used is always ltp-full-20150903.
Well, if anyone uses it, I would keep it. The reason why is not compiled by
default is probably because being incompatible with our make system. But it
looks quite neglected as it downloads and builds 2.6.39 (the last 2.6.x
release).
Generally I'd be for removing old code, which nobody uses and it's somehow neglected.
Kind regards,
Petr
^ permalink raw reply
* RE: [PATCH V4] mmc: core: improve reasonableness of bus width setting for HS400es
From: Fang Hongjie(方洪杰) @ 2018-07-24 5:49 UTC (permalink / raw)
To: ulf.hansson@linaro.org
Cc: shawn.lin@rock-chips.com, adrian.hunter@intel.com,
linus.walleij@linaro.org, wsa+renesas@sang-engineering.com,
bst@pengutronix.de, chanho.min@lge.com, kyle.roeschley@ni.com,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1531818865-7387-1-git-send-email-hongjiefang@asrmicro.com>
> mmc_select_hs400es() calls mmc_select_bus_width() which will continue
> to set 4bit transfer mode if fail to set 8bit mode. The bus width
> should not be set to 4bit in HS400es.
>
> When fail to set 8bit mode, need return error directly for HS400es.
>
> Signed-off-by: Hongjie Fang <hongjiefang@asrmicro.com>
> ---
> drivers/mmc/core/mmc.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 4466f5d..0dbc512 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1338,8 +1338,12 @@ static int mmc_select_hs400es(struct mmc_card *card)
> goto out_err;
>
> err = mmc_select_bus_width(card);
> - if (err < 0)
> + if (err != MMC_BUS_WIDTH_8) {
> + pr_err("%s: switch to 8bit bus width failed, err:%d\n",
> + mmc_hostname(host), err);
> + err = -EIO;
> goto out_err;
> + }
>
> /* Switch card to HS mode */
> err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> --
> 1.9.1
Ping.
Any suggestion for it?
B&R
Hongjie
^ permalink raw reply
* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: Vakul Garg @ 2018-07-24 4:43 UTC (permalink / raw)
To: davejwatson@fb.com, David Miller
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
doronrk@fb.com
In-Reply-To: <20180723.214109.32924668491950691.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Hi Dave
Can you still apply the rest of two patches in the series or do I need to send them again separately?
Regards
Vakul
________________________________
From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> on behalf of David Miller <davem@davemloft.net>
Sent: Tuesday, July 24, 2018 10:11:09 AM
To: davejwatson@fb.com
Cc: Vakul Garg; netdev@vger.kernel.org; borisp@mellanox.com; aviadye@mellanox.com; doronrk@fb.com
Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: Dave Watson <davejwatson@fb.com>
Date: Mon, 23 Jul 2018 09:35:09 -0700
> I don't think this patch is safe as-is. sgin_arr is a stack array of
> size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
> it walks the whole chain of skbs from skb->next, and can return any
> number of segments. Therefore we need to heap allocate. I think I
> copied the IPSEC code here.
Ok I see what you are saying.
So it means that, when a non-NULL sgout is passed into decrypt_skb(),
via decrypt_skb_update(), via tls_sw_recvmsg() it means that it is the
zerocopy case and you know that you only have page frags and no SKB
frag list, right?
I agree with you that this change is therefore incorrect.
[-- Attachment #2: Type: text/html, Size: 2675 bytes --]
^ permalink raw reply
* Re: [PATCH] hexagon: switch to NO_BOOTMEM
From: Mike Rapoport @ 2018-07-24 5:47 UTC (permalink / raw)
To: Richard Kuo; +Cc: Michal Hocko, linux-hexagon, linux-mm, linux-kernel
In-Reply-To: <20180723212339.GA12771@codeaurora.org>
On Mon, Jul 23, 2018 at 04:23:39PM -0500, Richard Kuo wrote:
>
> On Mon, Jul 16, 2018 at 10:43:18AM +0300, Mike Rapoport wrote:
> > This patch adds registration of the system memory with memblock, eliminates
> > bootmem initialization and converts early memory reservations from bootmem
> > to memblock.
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>
> Sorry for the delay, and thanks for this patch.
>
> I think the first memblock_reserve should use ARCH_PFN_OFFSET instead of
> PHYS_OFFSET.
memblock_reserve gets physical address rather than a pfn.
If I read arch/hexagon/include/asm/mem-layout.h correctly, the PHYS_OFFSET
*is* the physical address of the RAM and ARCH_PFN_OFFSET is the first pfn:
#define PHYS_PFN_OFFSET (PHYS_OFFSET >> PAGE_SHIFT)
#define ARCH_PFN_OFFSET PHYS_PFN_OFFSET
Did I miss something?
> If you can amend that I'd be happy to take it through my tree or it can go
> through any other.
>
>
> Thanks,
> Richard Kuo
>
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: arm: syna: add support for the AS370 SoC
From: Jisheng Zhang @ 2018-07-24 5:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20180720151529.GA26487@rob-hp-laptop>
Hi Rob
On Fri, 20 Jul 2018 09:15:29 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:24:57PM +0800, Jisheng Zhang wrote:
> > The AS370 SoC is a new derivative of the berlin family. The only
> > difference is the SoC isn't named as berlin*.
>
> So is it a derivative or just rebranded?
A derivative new generation SoC.
>
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > Documentation/devicetree/bindings/arm/syna.txt | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt
> > index 3bab18409b7a..3ba1d7b5ee74 100644
> > --- a/Documentation/devicetree/bindings/arm/syna.txt
> > +++ b/Documentation/devicetree/bindings/arm/syna.txt
> > @@ -1,4 +1,4 @@
> > -Marvell Berlin SoC Family Device Tree Bindings
> > +Synaptics SoC Device Tree Bindings
>
> Perhaps some note about what has happened here. Otherwise it looks
> strange having "Marvell Berlin" in the document when the title says
> Synaptics SoC.
Good idea. will do in v2
>
> > ---------------------------------------------------------------
> >
> > Work in progress statement:
> > @@ -13,6 +13,10 @@ stable binding/ABI.
> >
> > ---------------------------------------------------------------
> >
> > +Boards with the Synaptics AS370 SoC shall have the following properties:
> > + Required root node property:
> > + compatible: "syna,as370"
> > +
> > Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
> > shall have the following properties:
> >
> > --
> > 2.18.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: David Miller @ 2018-07-24 4:41 UTC (permalink / raw)
To: davejwatson; +Cc: vakul.garg, netdev, borisp, aviadye, doronrk
In-Reply-To: <20180723163509.GA91424@davejwatson-mba.local>
From: Dave Watson <davejwatson@fb.com>
Date: Mon, 23 Jul 2018 09:35:09 -0700
> I don't think this patch is safe as-is. sgin_arr is a stack array of
> size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
> it walks the whole chain of skbs from skb->next, and can return any
> number of segments. Therefore we need to heap allocate. I think I
> copied the IPSEC code here.
Ok I see what you are saying.
So it means that, when a non-NULL sgout is passed into decrypt_skb(),
via decrypt_skb_update(), via tls_sw_recvmsg() it means that it is the
zerocopy case and you know that you only have page frags and no SKB
frag list, right?
I agree with you that this change is therefore incorrect.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.