[RESEND PATCH v4 0/2] add thermal nodes for UniPhier SoCs
This series adds thermal nodes for UniPhier PXs2 and LD20 SoCs. Resending the patches to apply the missing comments, please ignore previous v4. Changes since v3: - use the dt-bindings header to replace the limit values with THERMAL_NO_LIMIT - add the calibration value to uniphier-pxs2.dtsi - move the calibration value to uniphier-ld20.dtsi Changes since v2: - add the calibration value to device tree for LD20 reference board Changes since v1: - separate from driver's patchset[1] - add cooling-maps nodes on the device tree - fix an interrupt trigger to set 'level-triggered' according to hardware specification - bring up threshold temperature for LD20 according to the spec sheet - add cpuN labels for reference in cooling-device property on PXs2 dts [1] https://lkml.org/lkml/2017/6/28/170 Kunihiko Hayashi (2): ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for PXs2 arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20 arch/arm/boot/dts/uniphier-pxs2.dtsi | 47 ++-- arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 45 +++ 2 files changed, 88 insertions(+), 4 deletions(-) -- 2.7.4
[RESEND PATCH v4 1/2] ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for PXs2
Add nodes of thermal monitor and thermal zone for UniPhier PXs2 SoC.
The thermal monitor node is included in sysctrl. Since the efuse might not
have a calibrated value of thermal monitor, this patch gives the default
value for PXs2.
Furthermore, add cpuN labels for reference in cooling-device property.
Signed-off-by: Kunihiko Hayashi
---
arch/arm/boot/dts/uniphier-pxs2.dtsi | 47 +---
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 90b020c..f2dfebe 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -7,6 +7,8 @@
* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
+#include
+
/ {
compatible = "socionext,uniphier-pxs2";
#address-cells = <1>;
@@ -16,7 +18,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
@@ -24,9 +26,10 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
- cpu@1 {
+ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
@@ -36,7 +39,7 @@
operating-points-v2 = <&cpu_opp>;
};
- cpu@2 {
+ cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <2>;
@@ -46,7 +49,7 @@
operating-points-v2 = <&cpu_opp>;
};
- cpu@3 {
+ cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <3>;
@@ -114,6 +117,35 @@
};
};
+ thermal-zones {
+ cpu_thermal {
+ polling-delay-passive = <250>; /* 250ms */
+ polling-delay = <1000>; /* 1000ms */
+ thermal-sensors = <&pvtctl>;
+
+ trips {
+ cpu_crit: cpu_crit {
+ temperature = <95000>; /* 95C */
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ cpu_alert: cpu_alert {
+ temperature = <85000>; /* 85C */
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu0
+ THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -358,6 +390,13 @@
compatible = "socionext,uniphier-pxs2-reset";
#reset-cells = <1>;
};
+
+ pvtctl: pvtctl {
+ compatible = "socionext,uniphier-pxs2-thermal";
+ interrupts = <0 3 4>;
+ #thermal-sensor-cells = <0>;
+ socionext,tmod-calibration = <0x0f86 0x6844>;
+ };
};
nand: nand@6800 {
--
2.7.4
[RESEND PATCH v4 2/2] arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20
Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC.
The thermal monitor node is included in sysctrl. Since the efuse might not
have a calibrated value of thermal monitor, this patch gives the default
value for LD20.
Signed-off-by: Kunihiko Hayashi
---
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..59e5ae6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -7,6 +7,8 @@
* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
+#include
+
/memreserve/ 0x8000 0x0200;
/ {
@@ -46,6 +48,7 @@
clocks = <&sys_clk 32>;
enable-method = "psci";
operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -64,6 +67,7 @@
clocks = <&sys_clk 33>;
enable-method = "psci";
operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
};
cpu3: cpu@101 {
@@ -173,6 +177,40 @@
<1 10 4>;
};
+ thermal-zones {
+ cpu_thermal {
+ polling-delay-passive = <250>; /* 250ms */
+ polling-delay = <1000>; /* 1000ms */
+ thermal-sensors = <&pvtctl>;
+
+ trips {
+ cpu_crit: cpu_crit {
+ temperature = <11>; /* 110C */
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ cpu_alert: cpu_alert {
+ temperature = <10>; /* 100C */
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu0
+ THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ map1 {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu2
+ THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -410,6 +448,13 @@
watchdog {
compatible = "socionext,uniphier-wdt";
};
+
+ pvtctl: pvtctl {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <0 3 4>;
+ #thermal-sensor-cells = <0>;
+ socionext,tmod-calibration = <0x0f22 0x68ee>;
+ };
};
nand: nand@6800 {
--
2.7.4
Re: [PATCH 0/3] Add 'external mode' for GPIO-based FSI master
Hi Jeremy, On Mon, Jun 19, 2017 at 6:56 PM, Jeremy Kerr wrote: > This series (on top of current char-misc-next) implements "external > mode" (ie, support for FSI debug devices) for the GPIO-based FSI master > driver. > > We implement this control in the GPIO master driver, as it has the > mapping of raw GPIO pins to fsi control signals, and provides a > mechanism for the kernel to retain exclusive access to those GPIOs. I just noticed that this didn't get applied. I assume it's because we forgot to cc Greg. I have a v2 of some of the patches in my inbox; we should re-send that v2. It may make sense to merge in some of the latter changes we have in the openbmc tree first. Cheers, Joel > --- > Jeremy Kerr (3): > fsi: Add fsi_master_rescan() > fsi/master-gpio: Add locking around gpio operations during break & > link enable > fsi/master-gpio: Add external mode > > .../ABI/testing/sysfs-driver-fsi-master-gpio | 10 +++ > drivers/fsi/fsi-core.c | 9 ++- > drivers/fsi/fsi-master-gpio.c | 85 > +- > drivers/fsi/fsi-master.h | 2 + > 4 files changed, 102 insertions(+), 4 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-driver-fsi-master-gpio > > -- > 2.7.4 >
[GIT PULL] RCU changes for v4.14
Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus # HEAD: 94edf6f3c20c9c8ee301bde04150a91bab4bf32c Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu The main RCU related changes in this cycle were: - Removal of spin_unlock_wait() - SRCU updates - RCU torture-test updates - RCU Documentation updates - Extend the sys_membarrier() ABI with the MEMBARRIER_CMD_PRIVATE_EXPEDITED variant - Miscellaneous RCU fixes - CPU-hotplug fixes Thanks, Ingo --> Joe Perches (1): module: Fix pr_fmt() bug for header use of printk Luis R. Rodriguez (2): swait: Add idle variants which don't contribute to load average rcu: Use idle versions of swait to make idle-hack clear Manfred Spraul (1): net/netfilter/nf_conntrack_core: Fix net_conntrack_lock() Masami Hiramatsu (1): rcu/tracing: Set disable_rcu_irq_enter on rcu_eqs_exit() Mathieu Desnoyers (1): membarrier: Provide expedited private command Oleg Nesterov (1): task_work: Replace spin_unlock_wait() with lock/unlock pair Paul E. McKenney (54): documentation: Fix relation between nohz_full and rcu_nocbs init_task: Remove redundant INIT_TASK_RCU_TREE_PREEMPT() macro srcu: Move rcu_scheduler_starting() from Tiny RCU to Tiny SRCU rcutorture: Remove obsolete SRCU-C.boot srcu: Make process_srcu() be static rcutorture: Move SRCU status printing to SRCU implementations rcutorture: Print SRCU lock/unlock totals rcu: Remove CONFIG_TASKS_RCU ifdef from rcuperf.c rcutorture: Select CONFIG_PROVE_LOCKING for Tiny SRCU scenario torture: Add --kconfig argument to kvm.sh rcutorture: Don't wait for kernel when all builds fail rcutorture: Enable SRCU readers from timer handler rcutorture: Place event-traced strings into trace buffer rcutorture: Use nr_cpus rather than maxcpus to limit test size rcutorture: Add task's CPU for rcutorture writer stalls rcutorture: Eliminate unused ts_rem local from rcu_trace_clock_local() rcu: Add last-CPU to GP-kthread starvation messages rcutorture: Invoke call_rcu() from timer handler rcu: Use timer as backstop for NOCB deferred wakeups atomics: Revert addition of comment header to spin_unlock_wait() rcu: Migrate callbacks earlier in the CPU-offline timeline rcu: Make expedited GPs correctly handle hardware CPU insertion torture: Fix typo suppressing CPU-hotplug statistics rcu: Remove orphan/adopt event-tracing fields rcu: Check for NOCB CPUs and empty lists earlier in CB migration rcu: Make NOCB CPUs migrate CBs directly from outgoing CPU rcu: Advance outgoing CPU's callbacks before migrating them rcu: Eliminate rcu_state ->orphan_lock rcu: Advance callbacks after migration rcu: Localize rcu_state ->orphan_pend and ->orphan_done rcu: Remove unused RCU list functions rcu: Move callback-list warning to irq-disable region srcu: Provide ordering for CPU not involved in grace period sched: Replace spin_unlock_wait() with lock/unlock pair rcu: Drive TASKS_RCU directly off of PREEMPT rcu: Create reasonable API for do_exit() TASKS_RCU processing rcu: Add TPS() to event-traced strings rcu: Move rcu.h to new trivial-function style rcu: Add event tracing to ->gp_tasks update at GP start rcu: Add TPS() protection for _rcu_barrier_trace strings rcu: Add assertions verifying blocked-tasks list rcu: Add warning to rcu_idle_enter() for irqs enabled rcu: Remove exports from rcu_idle_exit() and rcu_idle_enter() doc: Update RCU documentation doc: Update memory-barriers.txt for read-to-write dependencies doc: Add RCU files to docbook-generation files doc: No longer allowed to use rcu_dereference on non-pointers doc: Set down RCU's scheduling-clock-interrupt needs completion: Replace spin_unlock_wait() with lock/unlock pair exit: Replace spin_unlock_wait() with lock/unlock pair ipc: Replace spin_unlock_wait() with lock/unlock pair drivers/ata: Replace spin_unlock_wait() with lock/unlock pair locking: Remove spin_unlock_wait() generic definitions arch: Remove spin_unlock_wait() arch-specific definitions Peter Zijlstra (Intel) (1): rcu: Make rcu_idle_enter() rely on callers disabling irqs Tejun Heo (1): sched: Allow migrating kthreads into online but inactive CPUs .../RCU/Design/Requirements/Requirements.html | 130 +++ Documentation/RCU/checklist.txt| 121 +++ Documentation/RCU/rcu.txt | 9 +- Documentation/RCU/rcu_dereference.txt | 61 ++ Documentation/RCU/rcubarrier.txt | 5 + Documentation/RC
[PATCH 2/2] ARM: cpuidle: replace cpuidle_get_driver with cpuidle_get_cpu_driver
commit d50a7d8acd78 ("ARM: cpuidle: Support asymmetric idle definition")
supports multiple CPU idle driver so every CPU has its own driver. When
the initialization fails, the failure handling releases the resources
for every previous CPU; so it needs to retrieve every CPU device and
driver handler and unregister them. But the function
cpuidle_get_driver() can only return current CPU driver handler but not
the iterated CPU driver handler, so it cannot release resource properly.
This patch is to replace cpuidle_get_driver() with
cpuidle_get_cpu_driver(), every CPU has its own device handler so this
function can get back correct driver handler for the CPU according to
the CPU device handler. By using this CPU driver handler we can release
resource properly.
Cc: Daniel Lezcano
Cc: Stefan Wahren
Signed-off-by: Leo Yan
Fixes: d50a7d8acd78 ("ARM: cpuidle: Support asymmetric idle definition")
---
drivers/cpuidle/cpuidle-arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index f419f6a..ef34780 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -161,9 +161,9 @@ static int __init arm_idle_init(void)
while (--cpu >= 0) {
dev = per_cpu(cpuidle_devices, cpu);
+ drv = cpuidle_get_cpu_driver(dev);
cpuidle_unregister_device(dev);
kfree(dev);
- drv = cpuidle_get_driver();
cpuidle_unregister_driver(drv);
kfree(drv);
}
--
2.7.4
[PATCH 1/2] ARM: cpuidle: refine failure handling in init flow
After applied Stefan Wahren patch ("ARM: cpuidle: Avoid memleak if init
fail") there have no memleak issue, but the code is not consistent to
handle initialization failure between driver registration and device
registration. And when device registration fails, it misses to
unregister the driver.
So this patch is to refine failure handling in init flow, it adds two
'goto' tags: when register device fails, it goto 'init_dev_fail' tag and
free 'dev' structure and unregister driver; when register driver fails,
it goto 'init_drv_fail' tag and free 'drv' structure.
Cc: Daniel Lezcano
Cc: Stefan Wahren
Signed-off-by: Leo Yan
---
drivers/cpuidle/cpuidle-arm.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 52a7505..f419f6a 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -86,10 +86,13 @@ static int __init arm_idle_init(void)
for_each_possible_cpu(cpu) {
+ drv = NULL;
+ dev = NULL;
+
drv = kmemdup(&arm_idle_driver, sizeof(*drv), GFP_KERNEL);
if (!drv) {
ret = -ENOMEM;
- goto out_fail;
+ goto init_drv_fail;
}
drv->cpumask = (struct cpumask *)cpumask_of(cpu);
@@ -104,13 +107,13 @@ static int __init arm_idle_init(void)
ret = dt_init_idle_driver(drv, arm_idle_state_match, 1);
if (ret <= 0) {
ret = ret ? : -ENODEV;
- goto init_fail;
+ goto init_drv_fail;
}
ret = cpuidle_register_driver(drv);
if (ret) {
pr_err("Failed to register cpuidle driver\n");
- goto init_fail;
+ goto init_drv_fail;
}
/*
@@ -128,14 +131,14 @@ static int __init arm_idle_init(void)
if (ret) {
pr_err("CPU %d failed to init idle CPU ops\n", cpu);
- goto out_fail;
+ goto init_dev_fail;
}
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
pr_err("Failed to allocate cpuidle device\n");
ret = -ENOMEM;
- goto out_fail;
+ goto init_dev_fail;
}
dev->cpu = cpu;
@@ -143,15 +146,19 @@ static int __init arm_idle_init(void)
if (ret) {
pr_err("Failed to register cpuidle device for CPU %d\n",
cpu);
- kfree(dev);
- goto out_fail;
+ goto init_dev_fail;
}
}
return 0;
-init_fail:
+
+init_dev_fail:
+ kfree(dev);
+ cpuidle_unregister_driver(drv);
+
+init_drv_fail:
kfree(drv);
-out_fail:
+
while (--cpu >= 0) {
dev = per_cpu(cpuidle_devices, cpu);
cpuidle_unregister_device(dev);
--
2.7.4
Re: [PATCH 1/3] dmaengine: sun6i: Correct DMA support on H3
On Fri, Sep 01, 2017 at 02:42:47PM +, Brüns, Stefan wrote:
> On Freitag, 1. September 2017 15:35:49 CEST Maxime Ripard wrote:
> > On Fri, Sep 01, 2017 at 05:04:54AM +0200, Stefan Bruens wrote:
> > > On Donnerstag, 31. August 2017 16:51:35 CEST Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Thu, Aug 31, 2017 at 01:36:07AM +0200, Stefan Brüns wrote:
> > > > > +/* Between SoC generations, there are some significant differences:
> > > > > + * - A23 added a clock gate register
> > > > > + * - the H3 burst length field has a different offset
> > > > > + */
> > > >
> > > > This is not the proper comment style.
> > > >
> > > > > +enum dmac_variant {
> > > > > + DMAC_VARIANT_A31,
> > > > > + DMAC_VARIANT_A23,
> > > > > + DMAC_VARIANT_H3,
> > > > > +};
> > > > > +
> > > >
> > > > And this is redundant with what we already have in our structures.
> > >
> > > Actually, its not. For H3, there are currently at least 3 register
> > > compatible SoCs: H5 is identical, R40 has 16 dma channels, A64 has 8
> > > channels. So if the current config structure is kept, we need 3 different
> > > compatible strings. Same for the A23, which is register compatible to
> > > e.g. A83t and V3s, but with different numbers of DMA channels.
> > >
> > > So either you decorate the code with a cascade of
> > >
> > > if ((of_is_compatible(..A23..) || of_is_compatible(..A83T..) || ...) {
> > > } else if ((of_is_compatible(..H3..) || of_is_compatible(..A64..) || ...)
> > > {
> > > } else { /* A31 */
> > > }
> > >
> > > in a number of places, or you do it just once.
> >
> > That's not how you retrieve the structures. They are already
> > associated to the compatible, and you need to do a single lookup to
> > get them. So that's nowhere near what you're suggesting. You can have
> > a look at the of_match_device in the probe function.
>
> Please have a look at the current implementation of how the clock autogating
> in the probe function is done - it matches with the compatible string.
Yeah, and we should get rid of that as well.
> Of course we can replace this with a match between sdev->config and the
> various sun6i_dma_config instances, but we would still have to do 3 matches
> for the A23 register configuration (A23 || A83T || V3s) and 3 matches for the
> H3 register configuration (H3 || R40 || A64). There are currently *7*
> different configs (V3s, R40 and A64 taken into account), but only 3 different
> register variants.
>
> This is the same rationale as the "gate_needed" boolean property proposed by
> Icenowy Zheng in the "Allwinner V3s DMA support" patch series. Obviously we
> don't need a boolean, but a ternary option to cater for the gate_needed
> differences - "NO_GATE", "A23_STYLE_GATE", "H3_STYLE_GATE".
Or we can just have an extra field in sun6i_dma_config that would set
the gate register offset? If it's non-zero, use whatever you have set
there, and then you just have to care about two cases, no matter how
many offsets we'll have in the wild.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
[GIT PULL] debugobjects changes for v4.14
Linus, Please pull the latest core-debugobjects-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-debugobjects-for-linus # HEAD: caba4cbbd27d755572730801ac34fe063fc40a32 debugobjects: Make kmemleak ignore debug objects A single commit making debugobjects interact better with kmemleak. Thanks, Ingo --> Waiman Long (1): debugobjects: Make kmemleak ignore debug objects init/main.c| 2 +- lib/debugobjects.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/init/main.c b/init/main.c index 052481fbe363..7ec20cf7b111 100644 --- a/init/main.c +++ b/init/main.c @@ -651,8 +651,8 @@ asmlinkage __visible void __init start_kernel(void) } #endif page_ext_init(); - debug_objects_mem_init(); kmemleak_init(); + debug_objects_mem_init(); setup_per_cpu_pageset(); numa_policy_init(); if (late_time_init) diff --git a/lib/debugobjects.c b/lib/debugobjects.c index 17afb0430161..2f5349c6e81a 100644 --- a/lib/debugobjects.c +++ b/lib/debugobjects.c @@ -18,6 +18,7 @@ #include #include #include +#include #define ODEBUG_HASH_BITS 14 #define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS) @@ -110,6 +111,7 @@ static void fill_pool(void) if (!new) return; + kmemleak_ignore(new); raw_spin_lock_irqsave(&pool_lock, flags); hlist_add_head(&new->node, &obj_pool); debug_objects_allocated++; @@ -1080,6 +1082,7 @@ static int __init debug_objects_replace_static_objects(void) obj = kmem_cache_zalloc(obj_cache, GFP_KERNEL); if (!obj) goto free; + kmemleak_ignore(obj); hlist_add_head(&obj->node, &objects); }
[PATCH v5 1/3] dt-bindings: add eeprom "size" property
This adds eeprom "size" as optional property for i2c eeproms.
The "size" property allows explicitly specifying the size of the
EEPROM chip in bytes.
Signed-off-by: Divagar Mohandass
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 5696eb5..1436569 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -32,6 +32,8 @@ Optional properties:
- read-only: this parameterless property disables writes to the eeprom
+ - size: total eeprom size in bytes
+
Example:
eeprom@52 {
--
1.9.1
[PATCH v5 2/3] eeprom: at24: add support to fetch eeprom device property "size"
Obtain the size of the EEPROM chip from DT if the "size" property is
specified for the device.
Signed-off-by: Divagar Mohandass
---
drivers/misc/eeprom/at24.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 764ff5df..2199c42 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -570,6 +570,10 @@ static void at24_get_pdata(struct device *dev, struct
at24_platform_data *chip)
if (device_property_present(dev, "read-only"))
chip->flags |= AT24_FLAG_READONLY;
+ err = device_property_read_u32(dev, "size", &val);
+ if (!err)
+ chip->byte_len = val;
+
err = device_property_read_u32(dev, "pagesize", &val);
if (!err) {
chip->page_size = val;
--
1.9.1
[PATCH v5 3/3] eeprom: at24: enable runtime pm support
Currently the device is kept in D0, there is an opportunity
to save power by enabling runtime pm.
Device can be daisy chained from PMIC and we can't rely on I2C core
for auto resume/suspend. Driver will decide when to resume/suspend.
Signed-off-by: Divagar Mohandass
---
drivers/misc/eeprom/at24.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2199c42..03f5cb7 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/*
* I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
@@ -501,11 +502,21 @@ static ssize_t at24_eeprom_write_i2c(struct at24_data
*at24, const char *buf,
static int at24_read(void *priv, unsigned int off, void *val, size_t count)
{
struct at24_data *at24 = priv;
+ struct i2c_client *client;
char *buf = val;
+ int ret;
if (unlikely(!count))
return count;
+ client = at24_translate_offset(at24, &off);
+
+ ret = pm_runtime_get_sync(&client->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&client->dev);
+ return ret;
+ }
+
/*
* Read data from chip, protecting against concurrent updates
* from this host, but not from other I2C masters.
@@ -518,6 +529,7 @@ static int at24_read(void *priv, unsigned int off, void
*val, size_t count)
status = at24->read_func(at24, buf, off, count);
if (status < 0) {
mutex_unlock(&at24->lock);
+ pm_runtime_put(&client->dev);
return status;
}
buf += status;
@@ -527,17 +539,29 @@ static int at24_read(void *priv, unsigned int off, void
*val, size_t count)
mutex_unlock(&at24->lock);
+ pm_runtime_put(&client->dev);
+
return 0;
}
static int at24_write(void *priv, unsigned int off, void *val, size_t count)
{
struct at24_data *at24 = priv;
+ struct i2c_client *client;
char *buf = val;
+ int ret;
if (unlikely(!count))
return -EINVAL;
+ client = at24_translate_offset(at24, &off);
+
+ ret = pm_runtime_get_sync(&client->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&client->dev);
+ return ret;
+ }
+
/*
* Write data to chip, protecting against concurrent updates
* from this host, but not from other I2C masters.
@@ -550,6 +574,7 @@ static int at24_write(void *priv, unsigned int off, void
*val, size_t count)
status = at24->write_func(at24, buf, off, count);
if (status < 0) {
mutex_unlock(&at24->lock);
+ pm_runtime_put(&client->dev);
return status;
}
buf += status;
@@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned int off, void
*val, size_t count)
mutex_unlock(&at24->lock);
+ pm_runtime_put(&client->dev);
+
return 0;
}
@@ -743,6 +770,11 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
i2c_set_clientdata(client, at24);
+ /* enable runtime pm */
+ pm_runtime_get_noresume(&client->dev);
+ pm_runtime_set_active(&client->dev);
+ pm_runtime_enable(&client->dev);
+
/*
* Perform a one-byte test read to verify that the
* chip is functional.
@@ -750,9 +782,12 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
err = at24_read(at24, 0, &test_byte, 1);
if (err) {
err = -ENODEV;
+ pm_runtime_put(&client->dev);
goto err_clients;
}
+ pm_runtime_put(&client->dev);
+
at24->nvmem_config.name = dev_name(&client->dev);
at24->nvmem_config.dev = &client->dev;
at24->nvmem_config.read_only = !writable;
@@ -795,6 +830,8 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (at24->client[i])
i2c_unregister_device(at24->client[i]);
+ pm_runtime_disable(&client->dev);
+
return err;
}
@@ -810,6 +847,9 @@ static int at24_remove(struct i2c_client *client)
for (i = 1; i < at24->num_addresses; i++)
i2c_unregister_device(at24->client[i]);
+ pm_runtime_disable(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+
return 0;
}
--
1.9.1
Re: [PATCH v4 1/3] dt-bindings: Document the hi3660 thermal sensor bindings
在 2017/9/1 2:24, Daniel Lezcano 写道:
On 29/08/2017 10:17, Tao Wang wrote:
From: Tao Wang
This adds documentation of device tree bindings for the
thermal sensor controller of hi3660 SoC.
Signed-off-by: Tao Wang
---
.../devicetree/bindings/thermal/hisi-tsensor.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
diff --git a/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
b/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
new file mode 100644
index 000..4643dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hisi-tsensor.txt
@@ -0,0 +1,37 @@
+* Temperature Sensor on hisilicon SoC
+
+Hisilicon SoC supplies temperature sensor feature, each CPU cluster and G3D
+area contains a temperture sensor. The temperture sensor produces an output
+value which has a linear relationship with the temperture of the area.
+
s/temperture/temperature/
THX
+for Hi3660,
+sensor0 monitors the temperture of A53;
+sensor1 monitors the temperture of A72;
+sensor2 monitors the temperture of GPU;
+sensor3 is a virtual sensor, which produces the maximum value of all sensors;
+sensor4 is a virtual sensor, which produces the average value of all sensors.
I don't think we need to escribe the virtual sensors in the DT bindings.
I just want to let user know the sensor id of virtual sensor, I also define it
in header file, so the header file is enough?
+** Required properties :
+- compatible: "hisilicon,thermal-tsensor".
+- reg: physical reg address of thermal sensor and length of memory mapped
+ region.
+- hisi,tsensors: number of hardware tsensors
+- hisi,coef: An array of integers (one signed cell) containing
+ coefficients to turn adc value to temperture.
+- hisi,adc-range: adc value range, minimum value is followed by maximum value.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+Example :
+Hi3660:
+tsensor: tsensor@fff3 {
+ compatible = "hisilicon,hi3660-tsensor";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ reg = <0x0 0xfff3001c 0x0 0x4>,
+ <0x0 0xfff3005c 0x0 0x4>,
+ <0x0 0xfff3009c 0x0 0x4>;
+ hisi,tsensors = ;
+ hisi,coef = <165000 (-4)>;
+ hisi,adc-range = <0x74 0x39A>;
Do we really need max sensors, coef and adc range to be specified in the DT?
Can't we assume the hi3660-tsensor has 3 sensors, and hard-code the
coef, adc, in the driver itself?
My purpose is to make the driver be compitable with our future platform.
Can't this binding be merged with the hisilicon-thermal.txt?
Thanks.
-- Daniel
[PATCH v5 0/3] enable eeprom "size" property and runtime pm
This series adds support for eeprom "size" property which will be read by the driver for eeprom size. The existing ACPI has a different default size which can be overridden with a DSD property value provided by the platform FW. This series also adds support for runtime PM. The eeprom driver currently did not have support for runtime PM and the device was kept in D0 throughout. [v1] - Add support for eeprom "size" property. - Add runtime PM support to the driver. [v2] - Improved the patch subject. [v3] - Addressed comments from Sakari Ailus. - Improved patch description. - Improved pm support patch. [v4] - Improved runtime pm support. - Addressed comments from Sakari Ailus. [v5] - Addressed comments from Sakari Ailus. - Improved error handling for PM support. Divagar Mohandass (3): dt-bindings: add eeprom "size" property eeprom: at24: add support to fetch eeprom device property "size" eeprom: at24: enable runtime pm support .../devicetree/bindings/eeprom/eeprom.txt | 2 + drivers/misc/eeprom/at24.c | 44 ++ 2 files changed, 46 insertions(+) -- 1.9.1
Re: linux-next: manual merge of the pm tree with the dmi tree
Hi Jean,
On Fri, 01 Sep 2017 15:20:21 +0200 Jean Delvare wrote:
>
> On jeu., 2017-08-31 at 11:07 +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the pm tree got a conflict in:
> >
> > drivers/acpi/blacklist.c
> >
> > between commit:
> >
> > f996c4155d0d ("dmi: Mark all struct dmi_system_id instances const")
> >
> > from the dmi tree and commit:
> >
> > 5aa5911a0ed9 ("ACPI / blacklist: add acpi_match_platform_list()")
> >
> > from the pm tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
>
> Below, where?
Oops sorry, I think this is it:
d75dc5255183bfae1181f5e1e8b260f18794d79d
diff --cc drivers/acpi/blacklist.c
index f58bbc368f88,037fd537bbf6..995c4d8922b1
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@@ -30,24 -30,7 +30,7 @@@
#include "internal.h"
- enum acpi_blacklist_predicates {
- all_versions,
- less_than_or_equal,
- equal,
- greater_than_or_equal,
- };
-
- struct acpi_blacklist_item {
- char oem_id[7];
- char oem_table_id[9];
- u32 oem_revision;
- char *table;
- enum acpi_blacklist_predicates oem_revision_predicate;
- char *reason;
- u32 is_critical_error;
- };
-
-static struct dmi_system_id acpi_rev_dmi_table[] __initdata;
+static const struct dmi_system_id acpi_rev_dmi_table[] __initconst;
/*
* POLICY: If *anything* doesn't work, put it on the blacklist.
--
Cheers,
Stephen Rothwell
Apply for your loan today at 2%
Apply for your loan today at a very low interest rate of 2%..We offer loan to every Individuals and Company's... If you are in need of any kinds of loan, do contact us now for more info
Re: [PATCH 0/3] ARM: dts: sunxi: Use defines for ccu clock indices
On Sun, Sep 03, 2017 at 04:50:15PM +0300, Priit Laes wrote:
> This is a follow-up commit for sun{4,7}i ccu conversion. Now that
> all the relevant pieces have been merged we can use dt-binding headers
> again.
>
> Also included is additional patch to add i2s0 block to sun4i dtsi header.
The last one could have been sent separately, but I applied all of
them.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v4 3/3] platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties
On Sun, Sep 3, 2017 at 3:41 PM, Hans de Goede wrote:
> The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id
> rather then just "fusb302" and needs us to set a number of device-
> properties, adjust the intel_cht_int33fe driver accordingly.
>
> One of the properties set is max-snk-mv which makes the fusb302 driver
> negotiate up to 12V charging voltage, which is a bad idea on boards
> which are not setup to handle this, so this commit also adds 2 extra
> sanity checks to make sure that the expected Whiskey Cove PMIC +
> TI bq24292i charger combo, which can handle 12V, is present.
Acked-by: Andy Shevchenko
(in case Wolfram would like to take it)
See comments below.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -Set board_info.dev_name
> -Adjust for changes in other patches in this patch-set
> ---
> drivers/platform/x86/Kconfig | 6 -
> drivers/platform/x86/intel_cht_int33fe.c | 44
> +++-
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 80b87954f6dd..c5554577681a 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -793,7 +793,7 @@ config ACPI_CMPC
>
> config INTEL_CHT_INT33FE
> tristate "Intel Cherry Trail ACPI INT33FE Driver"
> - depends on X86 && ACPI && I2C
> + depends on X86 && ACPI && I2C && REGULATOR
> ---help---
> This driver add support for the INT33FE ACPI device found on
> some Intel Cherry Trail devices.
> @@ -804,6 +804,10 @@ config INTEL_CHT_INT33FE
> This driver instantiates i2c-clients for these, so that standard
> i2c drivers for these chips can bind to the them.
>
> + If you enable this driver it is advised to also select
> + CONFIG_CHARGER_BQ24190=m, CONFIG_BATTERY_MAX17042=m and
> + CONFIG_TYPEC_FUSB302=m (currently in drivers/staging).
> +
I would put FUSB302 first since it's not obvious now that remark in
parens is related only to it. And might be better rephase the path in
terms of `make menuconfig` rather than pathname in the source tree.
> config INTEL_INT0002_VGPIO
> tristate "Intel ACPI INT0002 Virtual GPIO driver"
> depends on GPIOLIB && ACPI
> diff --git a/drivers/platform/x86/intel_cht_int33fe.c
> b/drivers/platform/x86/intel_cht_int33fe.c
> index a9cbc4b8ca63..b2925d996613 100644
> --- a/drivers/platform/x86/intel_cht_int33fe.c
> +++ b/drivers/platform/x86/intel_cht_int33fe.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define EXPECTED_PTYPE 4
> @@ -77,12 +78,21 @@ static const struct property_entry max17047_props[] = {
> { }
> };
>
> +static const struct property_entry fusb302_props[] = {
> + PROPERTY_ENTRY_STRING("fcs,extcon-name", "cht_wcove_pwrsrc"),
> + PROPERTY_ENTRY_U32("fcs,max-sink-microvolt", 1200),
> + PROPERTY_ENTRY_U32("fcs,max-sink-microamp", 300),
> + PROPERTY_ENTRY_U32("fcs,max-sink-microwatt", 3600),
> + { }
> +};
> +
> static int cht_int33fe_probe(struct i2c_client *client)
> {
> struct device *dev = &client->dev;
> struct i2c_board_info board_info;
> struct cht_int33fe_data *data;
> struct i2c_client *max17047;
> + struct regulator *regulator;
> unsigned long long ptyp;
> acpi_status status;
> int ret, fusb302_irq;
> @@ -100,6 +110,34 @@ static int cht_int33fe_probe(struct i2c_client *client)
> if (ptyp != EXPECTED_PTYPE)
> return -ENODEV;
>
> + /* Check presence of INT34D3 (hardware-rev 3) expected for ptype == 4
> */
> + if (!acpi_dev_present("INT34D3", "1", 3)) {
> + dev_err(dev, "Error PTYPE == %d, but no INT34D3 device\n",
> + EXPECTED_PTYPE);
> + return -ENODEV;
> + }
> +
> + /*
> +* We expect the WC PMIC to be paired with a TI bq24292i charger-IC.
> +* We check for the bq24292i vbus regulator here, this has 2 purposes:
> +* 1) The bq24292i allows charging with up to 12V, setting the
> fusb302's
> +*max-snk voltage to 12V with another charger-IC is not good.
> +* 2) For the fusb302 driver to get the bq24292i vbus regulator, the
> +*regulator-map, which is part of the bq24292i
> regulator_init_data,
> +*must be registered before the fusb302 is instantiated, otherwise
> +*it will end up with a dummy-regulator.
> +* Note "cht_wc_usb_typec_vbus" comes from the regulator_init_data
> +* which is defined in i2c-cht-wc.c from where the bq24292i i2c-client
> +* gets instantiated. We use regulator_get_optional here so that we
> +* don't end up getting a dummy-regulator ourselves.
> +*/
> + regulator = regulator_get_optional(dev, "cht_wc_usb_typec_vbus");
> +
Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler
On 09/01/2017 04:31 PM, Marek Szyprowski wrote:
Hi Hoegeun,
On 2017-09-01 03:47, Hoegeun Kwon wrote:
The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.
The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.
Also the scaling limits are related to post size, use pos size to
check the limits.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63
+
include/uapi/drm/exynos_drm.h | 2 ++
2 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct
device *dev,
bool swap;
int i;
+config = &property->config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct
device *dev,
goto err_property;
}
-/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct
device *dev,
goto err_property;
}
+/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to pos
+ * size, use pos size to check the limits.
+ */
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct
device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
(pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
DRM_ERROR("out of scale size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
(pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_max.vsize)) {
DRM_ERROR("out of scale size.\n");
goto err_property;
}
@@ -1676,6 +1684,15 @@ static int gsc_probe(struct platform_device
*pdev)
dev_warn(dev, "failed to get system register.\n");
ctx->sysreg = NULL;
}
+
+ret = of_property_read_u32(dev->of_node, "rot-ma
[PATCH 2/2] ip6_tunnel: fix setting hop_limit value for ipv6 tunnel
Similar to vxlan/geneve tunnel, if hop_limit is zero, it should fall back to ip6_dst_hoplimt(). Signed-off-by: Haishuang Yan --- net/ipv6/ip6_tunnel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c index 3a0ba2a..10a693a 100644 --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1184,6 +1184,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield, init_tel_txopt(&opt, encap_limit); ipv6_push_frag_opts(skb, &opt.ops, &proto); } + hop_limit = hop_limit ? : ip6_dst_hoplimit(dst); /* Calculate max headroom for all the headers and adjust * needed_headroom if necessary. -- 1.8.3.1
[PATCH v3] ip6_tunnel: Correct tos value in collect_md mode
Same as ip_gre, geneve and vxlan, use key->tos as traffic class value.
CC: Peter Dawson
Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
encapsulated packets”)
Signed-off-by: Haishuang Yan
---
Changes since v3:
* Add fixes information
* Remove obsoleted RT_TOS mask
---
net/ipv6/ip6_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ef99d59..9d65918 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device
*dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPIP;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
- dsfield = ip6_tclass(key->label);
+ dsfield = key->tos;
} else {
if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
encap_limit = t->parms.encap_limit;
@@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device
*dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPV6;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
- dsfield = ip6_tclass(key->label);
+ dsfield = key->tos;
} else {
offset = ip6_tnl_parse_tlv_enc_lim(skb,
skb_network_header(skb));
/* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head
*/
--
1.8.3.1
Re: linux-next: manual merge of the kvm tree with the tip tree
Hi all,
On Mon, 28 Aug 2017 14:52:09 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
> arch/x86/kvm/mmu.c
>
> between commit:
>
> ea2800ddb20d ("kvm/x86: Avoid clearing the C-bit in rsvd_bits()")
>
> from the tip tree and commit:
>
> d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")
>
> from the kvm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kvm/mmu.c
> index 04d750813c9d,2a8a6e3e2a31..
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@@ -4116,21 -4157,11 +4162,21 @@@ reset_shadow_zero_bits_mask(struct kvm_
>* Passing "true" to the last argument is okay; it adds a check
>* on bit 8 of the SPTEs which KVM doesn't use anyway.
>*/
> -__reset_rsvds_bits_mask(vcpu, &context->shadow_zero_check,
> +shadow_zero_check = &context->shadow_zero_check;
> +__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
> boot_cpu_data.x86_phys_bits,
> context->shadow_root_level, uses_nx,
> - guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
> - true);
> + guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
> + is_pse(vcpu), true);
> +
> +if (!shadow_me_mask)
> +return;
> +
> +for (i = context->shadow_root_level; --i >= 0;) {
> +shadow_zero_check->rsvd_bits_mask[0][i] &= ~shadow_me_mask;
> +shadow_zero_check->rsvd_bits_mask[1][i] &= ~shadow_me_mask;
> +}
> +
> }
> EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
Re: Converting struct timer_list callback argument to struct timer_list *
On Sun, Sep 03, 2017 at 01:18:44PM -0700, Kees Cook wrote: > It feels weird to have different semantics from container_of() too, so > I'll probably just switch everything around to be like all the others, > in that they are just direct wrappers around container_of()... I'll > settle on something and switch everything over. I really like the idea of passing in a variable and not the type, though. Maybe we need to add a new generic helper for that, I just can't think of a good name.
Re: linux-next: manual merge of the tip tree with the spi tree
Hi all,
On Mon, 28 Aug 2017 14:05:03 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> tools/Makefile
>
> between commit:
>
> e9d4650dcc59 ("spi: tools: add install section")
>
> from the spi tree and commit:
>
> ecda85e70277 ("x86/lguest: Remove lguest support")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc tools/Makefile
> index 616e7722b327,a19b176b914b..
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@@ -90,8 -89,8 +89,8 @@@ freefall: FORC
> kvm_stat: FORCE
> $(call descend,kvm/$@)
>
> - all: acpi cgroup cpupower gpio hv firewire lguest liblockdep \
> + all: acpi cgroup cpupower gpio hv firewire liblockdep \
> -perf selftests turbostat usb \
> +perf selftests spi turbostat usb \
> virtio vm net x86_energy_perf_policy \
> tmon freefall objtool kvm_stat
>
> @@@ -101,7 -100,7 +100,7 @@@ acpi_install
> cpupower_install:
> $(call descend,power/$(@:_install=),install)
>
> - cgroup_install firewire_install gpio_install hv_install lguest_install
> perf_install spi_install usb_install virtio_install vm_install net_install
> objtool_install:
> -cgroup_install firewire_install gpio_install hv_install perf_install
> usb_install virtio_install vm_install net_install objtool_install:
> ++cgroup_install firewire_install gpio_install hv_install perf_install
> spi_install usb_install virtio_install vm_install net_install objtool_install:
> $(call descend,$(@:_install=),install)
>
> liblockdep_install:
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the kvm tree with Linus' tree
Hi all,
On Fri, 25 Aug 2017 14:34:16 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
> arch/x86/include/asm/cpufeatures.h
>
> between commit:
>
> 5442c2699552 ("x86/cpufeature, kvm/svm: Rename (shorten) the new
> "virtualized VMSAVE/VMLOAD" CPUID flag")
>
> from Linus' tree and commit:
>
> d837312dfd5b ("KVM: SVM: Add Virtual GIF feature definition")
>
> from the kvm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/include/asm/cpufeatures.h
> index 42bbbf0f173d,0e25e7a8ab03..
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@@ -287,7 -286,8 +287,8 @@@
> #define X86_FEATURE_PAUSEFILTER (15*32+10) /* filtered pause intercept */
> #define X86_FEATURE_PFTHRESHOLD (15*32+12) /* pause filter threshold */
> #define X86_FEATURE_AVIC(15*32+13) /* Virtual Interrupt Controller */
> -#define X86_FEATURE_VIRTUAL_VMLOAD_VMSAVE (15*32+15) /* Virtual VMLOAD
> VMSAVE */
> +#define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* Virtual VMSAVE VMLOAD */
> + #define X86_FEATURE_VGIF(15*32+16) /* Virtual GIF */
>
> /* Intel-defined CPU features, CPUID level 0x0007:0 (ecx), word 16 */
> #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit
> Manipulation instructions*/
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
[PATCH v4] sched: check user input value of sysctl_sched_time_avg
System will hang if user set sysctl_sched_time_avg to 0 by
[root@XXX ~]# sysctl kernel.sched_time_avg_ms=0
Stack traceback for pid 0
0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3
883f7ccc3ae8 0018 810c4dd0
00017800 883f7ccc3d78 0003 883f7ccc3bf8
810c4fc9 883f7ccc3c08 810c5043 883f7ccc3c08
Call Trace:
[] ? update_group_capacity+0x110/0x200
[] ? update_sd_lb_stats+0x109/0x600
[] ? find_busiest_group+0x47/0x530
[] ? load_balance+0x194/0x900
[] ? update_rq_clock.part.83+0x1a/0xe0
[] ? rebalance_domains+0x152/0x290
[] ? run_rebalance_domains+0xdc/0x1d0
[] ? __do_softirq+0xfb/0x320
[] ? irq_exit+0x125/0x130
[] ? scheduler_ipi+0x97/0x160
[] ? smp_reschedule_interrupt+0x29/0x30
[] ? reschedule_interrupt+0x6e/0x80
[] ? cpuidle_enter_state+0xcc/0x230
[] ? cpuidle_enter_state+0x9c/0x230
[] ? cpuidle_enter+0x17/0x20
[] ? cpu_startup_entry+0x38c/0x420
[] ? start_secondary+0x173/0x1e0
Because divide-by-zero error happens in function
update_group_capacity()
update_cpu_capacity()
scale_rt_capacity()
{
...
total = sched_avg_period() + delta;
used = div_u64(avg, total);
...
}
Seems this issue could be reproduced on all I tried stable 4.1 - last
kernel.
To fix this issue, check user input value of sysctl_sched_time_avg, keep
it unchanged when hit invalid input, set the min limit of
sysctl_sched_time_avg to 1 ms.
Reported-by: James Puthukattukaran
Signed-off-by: Ethan Zhao
---
v2: Check it at user input side in sysctl table (peterz).
v3: Use proc_dointvec_minmax().
v4: Fix a too long line in descripton part.
kernel/sysctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..423554a 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -367,7 +367,8 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.data = &sysctl_sched_time_avg,
.maxlen = sizeof(unsigned int),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
},
#ifdef CONFIG_SCHEDSTATS
{
--
1.8.3.1
Re: linux-next: manual merge of the btrfs-kdave tree with Linus' tree
Hi all,
On Fri, 25 Aug 2017 09:58:25 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the btrfs-kdave tree got a conflict in:
>
> fs/btrfs/inode.c
>
> between commit:
>
> 58efbc9f5463 ("Btrfs: fix blk_status_t/errno confusion")
>
> from Linus' tree and commit:
>
> e6961cac730f ("btrfs: Move skip checksum check from btrfs_submit_direct to
> __btrfs_submit_dio_bio")
>
> from the btrfs-kdave tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/btrfs/inode.c
> index 24bcd5cd9cf2,d184a46e46c4..
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@@ -7991,10 -8080,9 +8081,10 @@@ static blk_status_t dio_read_error(stru
> struct extent_io_tree *failure_tree = &BTRFS_I(inode)->io_failure_tree;
> struct bio *bio;
> int isector;
> - int read_mode = 0;
> + unsigned int read_mode = 0;
> int segs;
> int ret;
> +blk_status_t status;
>
> BUG_ON(bio_op(failed_bio) == REQ_OP_WRITE);
>
> @@@ -8021,11 -8109,11 +8111,11 @@@
> bio_set_op_attrs(bio, REQ_OP_READ, read_mode);
>
> btrfs_debug(BTRFS_I(inode)->root->fs_info,
> - "Repair DIO Read Error: submitting new dio read[%#x] to
> this_mirror=%d, in_validation=%d\n",
> + "repair DIO read error: submitting new dio read[%#x] to
> this_mirror=%d, in_validation=%d",
> read_mode, failrec->this_mirror, failrec->in_validation);
>
> -ret = submit_dio_repair_bio(inode, bio, failrec->this_mirror);
> -if (ret) {
> +status = submit_dio_repair_bio(inode, bio, failrec->this_mirror);
> +if (status) {
> free_io_failure(failure_tree, io_tree, failrec);
> bio_put(bio);
> }
> @@@ -8426,9 -8513,8 +8516,9 @@@ static inline blk_status_t btrfs_lookup
> return 0;
> }
>
> -static inline int __btrfs_submit_dio_bio(struct bio *bio, struct inode
> *inode,
> - u64 file_offset, int async_submit)
> +static inline blk_status_t
> +__btrfs_submit_dio_bio(struct bio *bio, struct inode *inode, u64
> file_offset,
> -int skip_sum, int async_submit)
> ++ int async_submit)
> {
> struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
> struct btrfs_dio_private *dip = bio->bi_private;
> @@@ -8541,9 -8625,9 +8630,9 @@@ static int btrfs_submit_direct_hook(str
>*/
> atomic_inc(&dip->pending_bios);
>
> - status = __btrfs_submit_dio_bio(bio, inode, file_offset,
> skip_sum,
> -ret = __btrfs_submit_dio_bio(bio, inode, file_offset,
> - async_submit);
> -if (ret) {
> ++status = __btrfs_submit_dio_bio(bio, inode, file_offset,
> +async_submit);
> +if (status) {
> bio_put(bio);
> atomic_dec(&dip->pending_bios);
> goto out_err;
> @@@ -8561,9 -8645,8 +8650,8 @@@
> } while (submit_len > 0);
>
> submit:
> - status = __btrfs_submit_dio_bio(bio, inode, file_offset, skip_sum,
> - async_submit);
> -ret = __btrfs_submit_dio_bio(bio, inode, file_offset, async_submit);
> -if (!ret)
> ++status = __btrfs_submit_dio_bio(bio, inode, file_offset, async_submit);
> +if (!status)
> return 0;
>
> bio_put(bio);
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
[PATCH v3] sched: check user input value of sysctl_sched_time_avg
System will hang if user set sysctl_sched_time_avg to 0 by
[root@XXX ~]# sysctl kernel.sched_time_avg_ms=0
Stack traceback for pid 0
0x883f6406c600 0 0 1 3 R 0x883f6406cf50 *swapper/3
883f7ccc3ae8 0018 810c4dd0
00017800 883f7ccc3d78 0003 883f7ccc3bf8
810c4fc9 883f7ccc3c08 810c5043 883f7ccc3c08
Call Trace:
[] ? update_group_capacity+0x110/0x200
[] ? update_sd_lb_stats+0x109/0x600
[] ? find_busiest_group+0x47/0x530
[] ? load_balance+0x194/0x900
[] ? update_rq_clock.part.83+0x1a/0xe0
[] ? rebalance_domains+0x152/0x290
[] ? run_rebalance_domains+0xdc/0x1d0
[] ? __do_softirq+0xfb/0x320
[] ? irq_exit+0x125/0x130
[] ? scheduler_ipi+0x97/0x160
[] ? smp_reschedule_interrupt+0x29/0x30
[] ? reschedule_interrupt+0x6e/0x80
[] ? cpuidle_enter_state+0xcc/0x230
[] ? cpuidle_enter_state+0x9c/0x230
[] ? cpuidle_enter+0x17/0x20
[] ? cpu_startup_entry+0x38c/0x420
[] ? start_secondary+0x173/0x1e0
Because divide-by-zero error happens in function
update_group_capacity()
update_cpu_capacity()
scale_rt_capacity()
{
...
total = sched_avg_period() + delta;
used = div_u64(avg, total);
...
}
Seems this issue could be reproduced on all I tried stable 4.1 - last
kernel.
To fix this issue, check user input value of sysctl_sched_time_avg, keep
it unchanged when hit invalid input, set the min limit of sysctl_sched_time_avg
to 1 ms.
Reported-by: James Puthukattukaran
Signed-off-by: Ethan Zhao
---
v2: Check it at user input side in sysctl table (peterz).
v3: Use proc_dointvec_minmax().
kernel/sysctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..423554a 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -367,7 +367,8 @@ static int sysrq_sysctl_handler(struct ctl_table *table,
int write,
.data = &sysctl_sched_time_avg,
.maxlen = sizeof(unsigned int),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
},
#ifdef CONFIG_SCHEDSTATS
{
--
1.8.3.1
Re: linux-next: manual merge of the arm64 tree with Linus' tree
Hi all,
On Thu, 24 Aug 2017 09:22:46 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm64/kernel/fpsimd.c
>
> between commit:
>
> 096622104e14 ("arm64: fpsimd: Prevent registers leaking across exec")
>
> from Linus' tree and commit:
>
> cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq
> kernel-mode NEON")
>
> from the arm64 tree.
>
> I fixed it up (I just used the latter version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Just a reminder that the above conflict still exists.
--
Cheers,
Stephen Rothwell
Re: linux-next: build warning after merge of the dma-mapping tree
Thanks Stephen, I'll fix it.
linux-next: manual merge of the usb tree with the mips tree
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in:
drivers/phy/Makefile
between commit:
0ab3aa747f26 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU
module")
from the mips tree and commit:
cd4ec4b03dc1 ("phy: phy-mt65xx-usb3: add mediatek directory and rename file")
from the usb tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/phy/Makefile
index a8b9439a5d8e,06f3c500030d..
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@@ -4,12 -4,12 +4,12 @@@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
- obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
-
obj-$(CONFIG_ARCH_SUNXI) += allwinner/
obj-$(CONFIG_ARCH_MESON) += amlogic/
+obj-$(CONFIG_LANTIQ) += lantiq/
+ obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
obj-$(CONFIG_ARCH_RENESAS)+= renesas/
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
Re: Applied "regulator: pbias: Select voltage table based on max-voltage" to the regulator tree
Hi Mark, On Friday 01 September 2017 09:53 PM, Mark Brown wrote: > On Fri, Sep 01, 2017 at 03:18:03PM +0200, Ulf Hansson wrote: >> On 31 August 2017 at 15:50, Mark Brown wrote: >>> On Thu, Aug 31, 2017 at 05:37:34PM +0530, Kishon Vijay Abraham I wrote: > This patch should be merged along with the 1st patch of the series "mmc: host: omap_hsmmc: Remove setting PBIAS voltage". Or else it'll break MMC with omap_hsmmc driver. > > Hang on, how can this break anything? If it breaks things shouldn't > there be bugfixes for incorrect constraints somewhere? omap_hsmmc sets the pbias voltage to 3V. But here we program the volt table to support either 1.8V or 3.3V (Initially the volt table was programmed to support 3V because of a bug in TRM). So set_voltage of pbias voltage in omap_hsmmc will fail. Thanks Kishon
Re: linux-next: manual merge of the tip tree with the iommu tree
Hi all,
On Tue, 22 Aug 2017 13:50:57 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the tip tree got conflicts in:
>
> drivers/iommu/amd_iommu.c
> drivers/iommu/amd_iommu_init.c
> drivers/iommu/amd_iommu_proto.h
> drivers/iommu/amd_iommu_types.h
>
> between commits:
>
> 4c232a708be1 ("iommu/amd: Detect pre enabled translation")
> 9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
> 07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
> daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
>
> from the iommu tree and commit:
>
> 2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory
> encryption")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/iommu/amd_iommu.c
> index 31bce367866c,4ad7e5e31943..
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
> return -EBUSY;
>
> if (count > 1) {
> - __pte = PAGE_SIZE_PTE(phys_addr, page_size);
> + __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
> -__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
> +__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
> } else
> - __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
> -__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
> ++__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>
> if (prot & IOMMU_PROT_IR)
> __pte |= IOMMU_PTE_IR;
> diff --cc drivers/iommu/amd_iommu_init.c
> index ff8887ac,2292a6cece76..
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@@ -29,6 -29,8 +29,7 @@@
> #include
> #include
> #include
> -#include
> + #include
> #include
> #include
> #include
> diff --cc drivers/iommu/amd_iommu_proto.h
> index 90e62e9b01c5,3f12fb2338ea..
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
> return !!(iommu->features & f);
> }
>
> + static inline u64 iommu_virt_to_phys(void *vaddr)
> + {
> + return (u64)__sme_set(virt_to_phys(vaddr));
> + }
> +
> + static inline void *iommu_phys_to_virt(unsigned long paddr)
> + {
> + return phys_to_virt(__sme_clr(paddr));
> + }
> +
> +extern bool translation_pre_enabled(struct amd_iommu *iommu);
> +extern struct iommu_dev_data *get_dev_data(struct device *dev);
> #endif /* _ASM_X86_AMD_IOMMU_PROTO_H */
> diff --cc drivers/iommu/amd_iommu_types.h
> index 5f775fef341c,8591f43c467c..
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@@ -361,8 -343,8 +361,8 @@@
> #define GCR3_VALID 0x01ULL
>
> #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
> -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
> +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
> - #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
> + #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
> #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
>
> #define IOMMU_PROT_MASK 0x03
Just a reminder that these conflicts still exist.
--
Cheers,
Stephen Rothwell
Re: printk: what is going on with additional newlines?
On Mon, 2017-09-04 at 14:22 +0900, Sergey Senozhatsky wrote: > there is only way to serialize printks against other printks -- take > the logbuf lock. If that's really necessary, instead make that logbuf_lock a public interface and keep the rest of the code simple. I think it's more important to get printk to work reliably than keep expanding the number of lines possible to buffer.
Re: linux-next: manual merge of the tip tree with the arm64 tree
Hi all,
On Tue, 22 Aug 2017 13:38:02 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/firmware/efi/libstub/arm64-stub.c
>
> between commit:
>
> 170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")
>
> from the arm64 tree and commit:
>
> 0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section
> markers")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/firmware/efi/libstub/arm64-stub.c
> index af6ae95a5e34,f7a6970e9abc..
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@@ -9,10 -9,17 +9,18 @@@
>* published by the Free Software Foundation.
>*
>*/
> +
> + /*
> + * To prevent the compiler from emitting GOT-indirected (and thus absolute)
> + * references to the section markers, override their visibility as 'hidden'
> + */
> + #pragma GCC visibility push(hidden)
> + #include
> + #pragma GCC visibility pop
> +
> #include
> #include
> +#include
> - #include
> #include
>
> #include "efistub.h"
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
Re: printk: what is going on with additional newlines?
On (09/04/17 13:30), Sergey Senozhatsky wrote: > On (09/01/17 10:32), Joe Perches wrote: > [..] > > > +static inlin __printf(2, 3) __cold > > > > uncompiled > > > > > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...) > > > > inline > > > > thanks. > > there is always a missing d'oh... s/always/also/ -ss
Re: linux-next: manual merge of the net-next tree with the rockchip tree
Hi all,
On Tue, 22 Aug 2017 11:24:14 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> arch/arm64/boot/dts/rockchip/rk3328-evb.dts
>
> between commits:
>
> ab78718bda79 ("arm64: dts: rockchip: Enable tsadc module on RK3328
> eavluation board")
> 1e28037ec88e ("arm64: dts: rockchip: add rk805 node for rk3328-evb")
>
> from the rockchip tree and commit:
>
> 4b05bc6157eb ("ARM64: dts: rockchip: Enable gmac2phy for rk3328-evb")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> index 86605ae7b6f5,b9f36dad17e6..
> --- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> @@@ -51,147 -51,24 +51,164 @@@
> stdout-path = "serial2:150n8";
> };
>
> +dc_12v: dc-12v {
> +compatible = "regulator-fixed";
> +regulator-name = "dc_12v";
> +regulator-always-on;
> +regulator-boot-on;
> +regulator-min-microvolt = <1200>;
> +regulator-max-microvolt = <1200>;
> +};
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> ++
> +vcc_sys: vcc-sys {
> +compatible = "regulator-fixed";
> +regulator-name = "vcc_sys";
> +regulator-always-on;
> +regulator-boot-on;
> +regulator-min-microvolt = <500>;
> +regulator-max-microvolt = <500>;
> +vin-supply = <&dc_12v>;
> +};
> };
>
> + &gmac2phy {
> + phy-supply = <&vcc_phy>;
> + clock_in_out = "output";
> + assigned-clocks = <&cru SCLK_MAC2PHY_SRC>;
> + assigned-clock-rate = <5000>;
> + assigned-clocks = <&cru SCLK_MAC2PHY>;
> + assigned-clock-parents = <&cru SCLK_MAC2PHY_SRC>;
> + status = "okay";
> + };
> +
> +&i2c1 {
> +status = "okay";
> +
> +rk805: rk805@18 {
> +compatible = "rockchip,rk805";
> +reg = <0x18>;
> +interrupt-parent = <&gpio2>;
> +interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> +#clock-cells = <1>;
> +clock-output-names = "xin32k", "rk805-clkout2";
> +gpio-controller;
> +#gpio-cells = <2>;
> +pinctrl-names = "default";
> +pinctrl-0 = <&pmic_int_l>;
> +rockchip,system-power-controller;
> +wakeup-source;
> +
> +vcc1-supply = <&vcc_sys>;
> +vcc2-supply = <&vcc_sys>;
> +vcc3-supply = <&vcc_sys>;
> +vcc4-supply = <&vcc_sys>;
> +vcc5-supply = <&vcc_io>;
> +vcc6-supply = <&vcc_io>;
> +
> +regulators {
> +vdd_logic: DCDC_REG1 {
> +regulator-name = "vdd_logic";
> +regulator-min-microvolt = <712500>;
> +regulator-max-microvolt = <145>;
> +regulator-always-on;
> +regulator-boot-on;
> +regulator-state-mem {
> +regulator-on-in-suspend;
> +regulator-suspend-microvolt = <100>;
> +};
> +};
> +
> +vdd_arm: DCDC_REG2 {
> +regulator-name = "vdd_arm";
> +regulator-min-microvolt = <712500>;
> +regulator-max-microvolt = <145>;
> +regulator-always-on;
> +regulator-boot-on;
> +regulator-state-mem {
> +regulator-on-in-suspend;
> +regulator-suspend-microvolt = <95>;
> +};
> +};
> +
> +vcc_ddr: DCDC_REG3 {
> +regulator-name = "vcc_ddr";
> +regulator-always-on;
> +regulator-boot-on;
> +regulator-state-mem {
> +regulator-on-in-suspend;
> +};
> +};
> +
> +vcc_io: DCDC_REG4
Re: printk: what is going on with additional newlines?
Hello,
I'll answer to both Linus and Joe, just to keep it all one place.
On (09/01/17 13:21), Linus Torvalds wrote:
> On Fri, Sep 1, 2017 at 10:32 AM, Joe Perches wrote:
> >
> > Yes, it's a poor name. At least keep using a pr_ prefix.
>
> I'd suggest perhaps just "pr_line()".
ok, pr_line sound good.
> And instead of having those "err/info/cont" variations, the severity
> level should just be set at initialization time. Not different
> versions of "pr_line()".
>
> There's no point to having different severity variations, since the
> *only* reason for this would be for buffering. So "pr_cont()" is kind
> of assumed for everything but the first.
>
> And even if you end up doing multiple lines, if you actually do
> different severities, you damn well shouldn't buffer them together.
> They are clearly different things!
hm... may be.
the main point of prbuf is not the support of cont lines, but the
fact that buffered messages are added to the logbuf atomically,
and thus are printed in consequent lines, not the usual way:
CPU0because
CPU1this
CPU0it's easier
CPU1might
CPU0to read
CPU1be
CPU1inconvenient.
CPU0seq messages.
some people want to be able to make it to look less spaghetti-like:
CPU0because
CPU0it's easier
CPU0to read
CPU0seq messages.
CPU1this
CPU1might
CPU1be
CPU1inconvenient.
and it's not something completely wrong to ask for, I think.
well, who knows.
there is only way to serialize printks against other printks -- take
the logbuf lock. and that's what pr_line/prbuf flush is doing.
now, pr_line/prbuf/pr_buf is, of course, very limited. it should NOT
be used for things that are really important and absolutely must [if
possible] appear in serial logs/on screens/etc. simply because panic
can happen on CPUA before we flush any pending pr_line/prbuf buffers
on other CPUs. and that's exactly the reason why I initially wanted
(and still do) to implement pr_line/prbuf using printk-safe
mechanism - because we flush printk-safe buffers from panic(). so
utilizing printk-safe buffers can make pr_line less fragile. apart
from that printk-safe buffers are always there, so OOM is not a show
stopper anymore. but, like I said in another email, printk-safe buffer
is per-CPU and is also used for actual printk-safe, hence it must be
used with local IRQs disabled when we "borrow" the buffer for pr_line
(disabled preemption is not enough due to possible IRQ printk-safe
print out). this can be a bit annoying.
in it's current form, pr_line/pr_buf is NOT a replacement for pr_cont
or printk(KERN_CONT). because pr_cont has no such thing as "we were
unable to flush the buffer from CPUB because of panic on CPUA". so
pr_cont/printk(KERN_CONT) beats pr_line/pr_buf here. This can be a
major limitation. am I wrong?
another thing,
if we eventually will decide to stick to "use a seq_buf with stack
allocated char buffer to hold a single line only" design, then I'm
not entirely sure I get it why do we want to add a new API at all.
I mean, the new API does not make anything simpler or shorter. we
need to declare the buffer, seq_buf, init seq_buf, append chars to
seq_buf, flush it:
char buf[80];
struct seq_buf cont_line;
pr_line_init(&cont_line, buf, sizeof(buf));
pr_line_printf(&cont_line, "");
pr_line_printf(&cont_line, "");
pr_line_flush(&cont_line);
this asks for s/pr_line_/seq_buf_/g, no? well, except for the flush()
part. it can be replaced with printk("%s\n", cont_line->buffer).
so it seems that we need to re-think it.
-ss
Re: linux-next: manual merge of the v4l-dvb tree with the arm-soc tree
Hi all,
On Tue, 22 Aug 2017 10:55:34 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
>
> arch/arm/configs/imx_v6_v7_defconfig
>
> between commit:
>
> b834bc1c52b8 ("ARM: imx_v6_v7_defconfig: Enable staging video4linux
> drivers")
>
> from the arm-soc tree and commit:
>
> b9e1486e0e4b ("media: rc-core: do not depend on MEDIA_SUPPORT")
>
> from the v4l-dvb tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm/configs/imx_v6_v7_defconfig
> index 3a48ad809731,1736813bdea7..
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@@ -230,9 -226,7 +230,9 @@@ CONFIG_REGULATOR_MC13892=
> CONFIG_REGULATOR_PFUZE100=y
> CONFIG_MEDIA_SUPPORT=y
> CONFIG_MEDIA_CAMERA_SUPPORT=y
> - CONFIG_MEDIA_RC_SUPPORT=y
> + CONFIG_RC_CORE=y
> +CONFIG_MEDIA_CONTROLLER=y
> +CONFIG_VIDEO_V4L2_SUBDEV_API=y
> CONFIG_RC_DEVICES=y
> CONFIG_IR_GPIO_CIR=y
> CONFIG_MEDIA_USB_SUPPORT=y
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
[PATCH] binder: fix "cast to pointer from integer of different size" warning
The binder driver now could cause warnings as below on 32bit platforms
if ANDROID_BINDER_IPC_32BIT is unselected:
drivers/android/binder.c:1550:15: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
This patch fix all of them.
Signed-off-by: Jisheng Zhang
---
drivers/android/binder.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index f7665c31feca..2812586bfae5 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1547,7 +1547,8 @@ static void binder_transaction_buffer_release(struct
binder_proc *proc,
debug_id, (u64)fda->num_fds);
continue;
}
- fd_array = (u32 *)(parent_buffer + fda->parent_offset);
+ fd_array = (u32 *)(parent_buffer +
+ (uintptr_t)fda->parent_offset);
for (fd_index = 0; fd_index < fda->num_fds; fd_index++)
task_close_fd(proc, fd_array[fd_index]);
} break;
@@ -1751,7 +1752,7 @@ static int binder_translate_fd_array(struct
binder_fd_array_object *fda,
* back to the kernel address space to access it
*/
parent_buffer = parent->buffer - target_proc->user_buffer_offset;
- fd_array = (u32 *)(parent_buffer + fda->parent_offset);
+ fd_array = (u32 *)(parent_buffer + (uintptr_t)fda->parent_offset);
if (!IS_ALIGNED((unsigned long)fd_array, sizeof(u32))) {
binder_user_error("%d:%d parent offset not aligned
correctly.\n",
proc->pid, thread->pid);
@@ -1786,7 +1787,7 @@ static int binder_fixup_parent(struct binder_transaction
*t,
binder_size_t last_fixup_min_off)
{
struct binder_buffer_object *parent;
- u8 *parent_buffer;
+ uintptr_t parent_buffer;
struct binder_buffer *b = t->buffer;
struct binder_proc *proc = thread->proc;
struct binder_proc *target_proc = t->to_proc;
@@ -1817,9 +1818,9 @@ static int binder_fixup_parent(struct binder_transaction
*t,
proc->pid, thread->pid);
return -EINVAL;
}
- parent_buffer = (u8 *)(parent->buffer -
- target_proc->user_buffer_offset);
- *(binder_uintptr_t *)(parent_buffer + bp->parent_offset) = bp->buffer;
+ parent_buffer = parent->buffer - target_proc->user_buffer_offset;
+ *(binder_uintptr_t *)(parent_buffer +
+ (uintptr_t)bp->parent_offset) = bp->buffer;
return 0;
}
--
2.14.1
Re: [PATCH v4 0/3] i2c: Hookup typec power-negotation to the PMIC and charger
Hi, > The first 2 patches are i2c patches, if you could review and > merge these (preferably for 4.14, but 4.15 is fine too) that would > be great. Definately for v4.15 and I very likely won't be able to review them before rc1 or rc2 time, if even that. Sorry, but I2C core changes need extra careful review and I2C maintenance is largely done in my limited spare time. If you could get other people to review/tag the patches, this would be very helpful. > Darren, Andy, the single platform/x86 patch in here should only > be merged after the 2 i2c patches are in place, otherwise users > of the board(s) in question will end up not having any battery > monitoring. Also note that this patch applies on top of the > "[PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some > devices" > patch I send out yesterday. Is that dependency for v4.14? Would it be an idea if I take the platform patch via the i2c tree then? Regards, Wolfram signature.asc Description: PGP signature
Re: linux-next: manual merge of the spi tree with the pm tree
Hi all,
On Thu, 17 Aug 2017 13:23:08 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the spi tree got a conflict in:
>
> drivers/spi/spi.c
>
> between commit:
>
> 8a2e487e6fc1 ("spi: Use Apple device properties in absence of ACPI
> resources")
>
> from the pm tree and commit:
>
> 9b61e302210e ("spi: Pick spi bus number from Linux idr or spi alias")
>
> from the spi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/spi/spi.c
> index 7d920ea19957,43cb8b98e953..
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@@ -40,7 -40,7 +40,8 @@@
> #include
> #include
> #include
> +#include
> + #include
>
> #define CREATE_TRACE_POINTS
> #include
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the pci tree with the net tree
Hi all,
On Wed, 16 Aug 2017 09:51:28 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the pci tree got a conflict in:
>
> drivers/pci/probe.c
>
> between commit:
>
> a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
>
> from the net tree and commit:
>
> 62ce94a7a5a5 ("PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken")
>
> from the pci tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/pci/probe.c
> index e6a917b4acd3,d11fede6bd53..
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@@ -1751,67 -1753,51 +1753,94 @@@ int pci_configure_extended_tags(struct
> int ret;
>
> if (!pci_is_pcie(dev))
> - return;
> + return 0;
>
> - ret = pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &dev_cap);
> + ret = pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap);
> if (ret)
> - return;
> + return 0;
> +
> + if (!(cap & PCI_EXP_DEVCAP_EXT_TAG))
> + return 0;
> +
> + ret = pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &ctl);
> + if (ret)
> + return 0;
> +
> + host = pci_find_host_bridge(dev->bus);
> + if (!host)
> + return 0;
> +
> + /*
> + * If some device in the hierarchy doesn't handle Extended Tags
> + * correctly, make sure they're disabled.
> + */
> + if (host->no_ext_tags) {
> + if (ctl & PCI_EXP_DEVCTL_EXT_TAG) {
> + dev_info(&dev->dev, "disabling Extended Tags\n");
> + pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> +PCI_EXP_DEVCTL_EXT_TAG);
> + }
> + return 0;
> + }
>
> - if (dev_cap & PCI_EXP_DEVCAP_EXT_TAG)
> + if (!(ctl & PCI_EXP_DEVCTL_EXT_TAG)) {
> + dev_info(&dev->dev, "enabling Extended Tags\n");
> pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
>PCI_EXP_DEVCTL_EXT_TAG);
> + }
> + return 0;
> }
>
> +/**
> + * pcie_relaxed_ordering_enabled - Probe for PCIe relaxed ordering enable
> + * @dev: PCI device to query
> + *
> + * Returns true if the device has enabled relaxed ordering attribute.
> + */
> +bool pcie_relaxed_ordering_enabled(struct pci_dev *dev)
> +{
> +u16 v;
> +
> +pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v);
> +
> +return !!(v & PCI_EXP_DEVCTL_RELAX_EN);
> +}
> +EXPORT_SYMBOL(pcie_relaxed_ordering_enabled);
> +
> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
> +{
> +struct pci_dev *root;
> +
> +/* PCI_EXP_DEVICE_RELAX_EN is RsvdP in VFs */
> +if (dev->is_virtfn)
> +return;
> +
> +if (!pcie_relaxed_ordering_enabled(dev))
> +return;
> +
> +/*
> + * For now, we only deal with Relaxed Ordering issues with Root
> + * Ports. Peer-to-Peer DMA is another can of worms.
> + */
> +root = pci_find_pcie_root_port(dev);
> +if (!root)
> +return;
> +
> +if (root->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
> +pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> + PCI_EXP_DEVCTL_RELAX_EN);
> +dev_info(&dev->dev, "Disable Relaxed Ordering because the Root
> Port didn't support it\n");
> +}
> +}
> +
> static void pci_configure_device(struct pci_dev *dev)
> {
> struct hotplug_params hpp;
> int ret;
>
> pci_configure_mps(dev);
> - pci_configure_extended_tags(dev);
> + pci_configure_extended_tags(dev, NULL);
> +pci_configure_relaxed_ordering(dev);
>
> memset(&hpp, 0, sizeof(hpp));
> ret = pci_get_hp_params(dev, &hpp);
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
linux-next: build failure after merge of the rcu tree
Hi Paul,
After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "rcu_cpu_stall_suppress" [kernel/rcu/rcutorture.ko] undefined!
ERROR: "rcu_cpu_stall_suppress" [kernel/rcu/rcuperf.ko] undefined!
Caused by commit
909bd6e3d9e7 ("rcu: Suppress RCU CPU stall warnings while dumping trace")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
Re: [PATCH v3 1/2] ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for PXs2
Yamada-san,
On Thu, 10 Aug 2017 19:44:38 +0900 wrote:
> Hayashi-san
>
>
> 2017-07-05 20:53 GMT+09:00 Kunihiko Hayashi :
> > Add nodes of thermal monitor and thermal zone for UniPhier PXs2 SoC.
> > The thermal monitor is included in sysctrl.
> > Furthermore, add cpuN labels for reference in cooling-device property.
> >
> > Signed-off-by: Kunihiko Hayashi
> > ---
>
>
> Please add socionext,tmod-calibration
> in case the efuse is not brown.
I see.
I'll include it to the pvtctl node in uniphier-pxs2.dtsi.
> >
> > + thermal-zones {
> > + cpu_thermal {
> > + polling-delay-passive = <250>; /* 250ms */
> > + polling-delay = <1000>; /* 1000ms */
> > + thermal-sensors = <&pvtctl>;
> > +
> > + trips {
> > + cpu_crit: cpu_crit {
> > + temperature = <95000>; /* 95C */
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + cpu_alert: cpu_alert {
> > + temperature = <85000>; /* 85C */
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map {
> > + trip = <&cpu_alert>;
> > + cooling-device = <&cpu0 (-1) (-1)>;
> > + };
>
>
> After all, I decided to use dt-bindings headers.
> Could you use THERMAL_NO_LIMIT for clarification?
Okay, I'll replace '(-1)' to THERMAL_NO_LIMIT and add the '#include' directive.
---
Best Regards,
Kunihiko Hayashi
Re: [PATCH v3 2/2] arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20
Yamada-san,
On Thu, 10 Aug 2017 19:48:22 +0900 wrote:
> Hi Hayashi-san,
>
>
> 2017-07-05 20:53 GMT+09:00 Kunihiko Hayashi :
> > Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC.
> > The thermal monitor is included in sysctrl.
> >
> > Furthermore, since the reference board doesn't have a calibrated value of
> > thermal monitor, this patch gives the default value for LD20 reference
> > board.
> >
> > Signed-off-by: Kunihiko Hayashi
> > ---
> > .../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 4 +++
> > arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 40
> > ++
> > 2 files changed, 44 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
> > b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
> > index 609162a..d7f6b39 100644
> > --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
> > +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
> > @@ -86,3 +86,7 @@
> > &i2c0 {
> > status = "okay";
> > };
> > +
> > +&pvtctl {
> > + socionext,tmod-calibration = <0x0f22 0x68ee>;
> > +};
>
>
> I think this calib value is shared among all boards
> (ref and global).
>
>
> Please move it to the SoC dtsi.
I see. I'll move it.
> > + cooling-maps {
> > + map0 {
> > + trip = <&cpu_alert>;
> > + cooling-device = <&cpu0 (-1) (-1)>;
> > + };
> > + map1 {
> > + trip = <&cpu_alert>;
> > + cooling-device = <&cpu2 (-1) (-1)>;
> > + };
> > + };
> > + };
> > + };
> > +
>
> After all, I decided to use dt-bindings headers.
> Could you use THERMAL_NO_LIMIT for clarification?
Okay, I'll replace '(-1)' to THERMAL_NO_LIMIT and add the '#include' directive.
---
Best Regards,
Kunihiko Hayashi
Re: linux-next: manual merge of the tip tree with the pm tree
Hi all,
On Fri, 11 Aug 2017 14:06:46 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> kernel/sched/fair.c
>
> between commit:
>
> 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")
>
> from the pm tree and commit:
>
> a030d7381d8b ("sched/fair: Call cpufreq update util handlers less
> frequently on UP")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc kernel/sched/fair.c
> index d378d02fdfcb,8d5868771cb3..
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st
> }
> #endif /* CONFIG_FAIR_GROUP_SCHED */
>
> + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
> + {
> -if (&this_rq()->cfs == cfs_rq) {
> ++struct rq *rq = rq_of(cfs_rq);
> ++
> ++if (&rq->cfs == cfs_rq) {
> + /*
> + * There are a few boundary cases this might miss but it should
> + * get called often enough that that should (hopefully) not be
> + * a real problem -- added to that it only calls on the local
> + * CPU, so if we enqueue remotely we'll miss an update, but
> + * the next tick/schedule should update.
> + *
> + * It will not get called when we go idle, because the idle
> + * thread is a different class (!fair), nor will the utilization
> + * number include things like RT tasks.
> + *
> + * As is, the util number is not freq-invariant (we'd have to
> + * implement arch_scale_freq_capacity() for that).
> + *
> + * See cpu_util().
> + */
> -cpufreq_update_util(rq_of(cfs_rq), 0);
> ++cpufreq_update_util(rq, 0);
> + }
> + }
> +
> #ifdef CONFIG_SMP
> /*
>* Approximate:
Just a reminder that the above conflict still exists.
--
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the pm tree with the dmi tree
Hi all,
On Mon, 7 Aug 2017 11:40:33 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the pm tree got a conflict in:
>
> drivers/acpi/sbs.c
>
> between commit:
>
> f996c4155d0d ("dmi: Mark all struct dmi_system_id instances const")
>
> from the dmi tree and commit:
>
> 630b3aff8a51 ("treewide: Consolidate Apple DMI checks")
>
> from the pm tree.
>
> I fixed it up (the latter removed the declaration updated by the former)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Just a reminder that the above conflict still exists.
--
Cheers,
Stephen Rothwell
Re: printk: what is going on with additional newlines?
On (09/01/17 10:32), Joe Perches wrote: [..] > > +static inlin __printf(2, 3) __cold > > uncompiled > > > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...) > > inline > thanks. there is always a missing if (console_trylock()) console_unlock(); in flush() function. -ss
linux-next: manual merge of the tip tree with the mips tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/irqchip/irq-mips-gic.c
between commit:
ac04be51a650 ("irqchip: mips-gic: Remove gic_map_to_vpe()")
b6e583e41993 ("irqchip: mips-gic: Make pcpu_masks a per-cpu variable")
6ab4fb2810db ("irqchip: mips-gic: Use pcpu_masks to avoid reading
GIC_SH_MASK*")
0429ecf6a6b4 ("irqchip: mips-gic: Use cpumask_first_and() in
gic_set_affinity()")
69aa0cbafce1 ("irqchip: mips-gic: Let the core set struct irq_common_data
affinity")
from the mips tree and commit:
18416e45b761 ("irqchip/mips-gic: Report that effective affinity is a single
target")
from the tip tree.
I fixed it up (I think - see below, and please check result) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/irqchip/irq-mips-gic.c
index 7187af1bea03,6461380ff1a4..
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@@ -261,16 -457,18 +261,17 @@@ static int gic_set_affinity(struct irq_
spin_lock_irqsave(&gic_lock, flags);
/* Re-route this IRQ */
- gic_map_to_vpe(irq, mips_cm_vp_id(cpu));
+ write_gic_map_vp(irq, BIT(mips_cm_vp_id(cpu)));
/* Update the pcpu_masks */
- for (i = 0; i < min(gic_vpes, NR_CPUS); i++)
- clear_bit(irq, pcpu_masks[i].pcpu_mask);
- set_bit(irq, pcpu_masks[cpu].pcpu_mask);
+ gic_clear_pcpu_masks(irq);
+ if (read_gic_mask(irq))
+ set_bit(irq, per_cpu_ptr(pcpu_masks, cpu));
- cpumask_copy(irq_data_get_affinity_mask(d), cpumask);
+ irq_data_update_effective_affinity(d, cpumask_of(cpu));
spin_unlock_irqrestore(&gic_lock, flags);
- return IRQ_SET_MASK_OK_NOCOPY;
+ return IRQ_SET_MASK_OK;
}
#endif
Re: [PATCH v4 0/2] add thermal nodes for UniPhier SoCs
On Mon, 4 Sep 2017 11:09:51 +0900 wrote: > Hi. > > > > 2017-09-04 10:16 GMT+09:00 Kunihiko Hayashi : > > This series adds thermal nodes for UniPhier PXs2 and LD20 SoCs. > > > > Changes since v3: > > - rebase on top of linux-next > > > This repost is a spam. > > I left some comments in v3, > but no response from you > nothing was reflected in v4. Sorry I missed them. I'll reflect your comments and repost them. Thank you, > > > > > > Changes since v2: > > - add the calibration value to device tree for LD20 reference board > > > > Changes since v1: > > - separate from driver's patchset[1] > > - add cooling-maps nodes on the device tree > > - fix an interrupt trigger to set 'level-triggered' according to > > hardware specification > > - bring up threshold temperature for LD20 according to the spec sheet > > - add cpuN labels for reference in cooling-device property on PXs2 dts > > > > [1] https://lkml.org/lkml/2017/6/28/170 > > > > Kunihiko Hayashi (2): > > ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for > > PXs2 > > arm64: dts: uniphier: add nodes of thermal monitor and thermal zone > > for LD20 > > > > arch/arm/boot/dts/uniphier-pxs2.dtsi | 43 > > -- > > .../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 4 ++ > > arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 40 > > > > 3 files changed, 83 insertions(+), 4 deletions(-) > > > > -- > > 2.7.4 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe devicetree" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Best Regards > Masahiro Yamada --- Kunihiko Hayashi : hayashi.kunih...@socionext.com
Re: [PATCH][next] Thermal: int3406_thermal: fix unused variable warning
On Fri, 2017-09-01 at 10:58 +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable index was introduced by an earlier commit and is not
> used, and hence should be removed.
>
> Cleans up warning: "unused variable 'index'"
>
> Fixes: c658894562ba ("Thermal: int3406_thermal: fix thermal sysfs
> I/F")
> Signed-off-by: Colin Ian King
thanks, I will fold this cleanup into the previous commit c658894562ba
("Thermal: int3406_thermal: fix thermal sysfs I/F").
thanks,
rui
> ---
> drivers/thermal/int340x_thermal/int3406_thermal.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/thermal/int340x_thermal/int3406_thermal.c
> b/drivers/thermal/int340x_thermal/int3406_thermal.c
> index e31509ead1c9..f69ab026ba24 100644
> --- a/drivers/thermal/int340x_thermal/int3406_thermal.c
> +++ b/drivers/thermal/int340x_thermal/int3406_thermal.c
> @@ -113,7 +113,6 @@ static void int3406_thermal_get_limit(struct
> int3406_thermal_data *d)
> {
> acpi_status status;
> unsigned long long lower_limit, upper_limit;
> - int index;
>
> status = acpi_evaluate_integer(d->handle, "DDDL", NULL,
> &lower_limit);
> if (ACPI_SUCCESS(status))
[PATCH net-next 1/2] tun: reserve extra headroom only when XDP is set
We reserve headroom unconditionally which could cause unnecessary
stress on socket memory accounting because of increased trusesize. Fix
this by only reserve extra headroom when XDP is set.
Cc: Jakub Kicinski
Signed-off-by: Jason Wang
---
drivers/net/tun.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 06e8f0b..80ac18f 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -108,7 +108,7 @@ do {
\
#endif
#define TUN_HEADROOM 256
-#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD + TUN_HEADROOM)
+#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD)
/* TUN device flags */
@@ -1272,25 +1272,35 @@ static struct sk_buff *tun_build_skb(struct tun_struct
*tun,
struct page_frag *alloc_frag = ¤t->task_frag;
struct sk_buff *skb;
struct bpf_prog *xdp_prog;
- int buflen = SKB_DATA_ALIGN(len + TUN_RX_PAD) +
-SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ int buflen = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
unsigned int delta = 0;
char *buf;
size_t copied;
bool xdp_xmit = false;
- int err;
+ int err, pad = TUN_RX_PAD;
+
+ rcu_read_lock();
+ xdp_prog = rcu_dereference(tun->xdp_prog);
+ if (xdp_prog)
+ pad += TUN_HEADROOM;
+ buflen += SKB_DATA_ALIGN(len + pad);
+ rcu_read_unlock();
if (unlikely(!skb_page_frag_refill(buflen, alloc_frag, GFP_KERNEL)))
return ERR_PTR(-ENOMEM);
buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
copied = copy_page_from_iter(alloc_frag->page,
-alloc_frag->offset + TUN_RX_PAD,
+alloc_frag->offset + pad,
len, from);
if (copied != len)
return ERR_PTR(-EFAULT);
- if (hdr->gso_type)
+ /* There's a small window that XDP may be set after the check
+* of xdp_prog above, this should be rare and for simplicity
+* we do XDP on skb in case the headroom is not enough.
+*/
+ if (hdr->gso_type || !xdp_prog)
*generic_xdp = 1;
else
*generic_xdp = 0;
@@ -1303,7 +1313,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct
*tun,
u32 act;
xdp.data_hard_start = buf;
- xdp.data = buf + TUN_RX_PAD;
+ xdp.data = buf + pad;
xdp.data_end = xdp.data + len;
orig_data = xdp.data;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
@@ -1339,7 +1349,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct
*tun,
return ERR_PTR(-ENOMEM);
}
- skb_reserve(skb, TUN_RX_PAD - delta);
+ skb_reserve(skb, pad - delta);
skb_put(skb, len + delta);
get_page(alloc_frag->page);
alloc_frag->offset += buflen;
--
2.7.4
[PATCH net-next 2/2] tun: rename generic_xdp to skb_xdp
Rename "generic_xdp" to "skb_xdp" to avoid confusing it with the
generic XDP which will be done at netif_receive_skb().
Cc: Daniel Borkmann
Signed-off-by: Jason Wang
---
drivers/net/tun.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 80ac18f..3c9985f 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1267,7 +1267,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct
*tun,
struct tun_file *tfile,
struct iov_iter *from,
struct virtio_net_hdr *hdr,
-int len, int *generic_xdp)
+int len, int *skb_xdp)
{
struct page_frag *alloc_frag = ¤t->task_frag;
struct sk_buff *skb;
@@ -1301,13 +1301,13 @@ static struct sk_buff *tun_build_skb(struct tun_struct
*tun,
* we do XDP on skb in case the headroom is not enough.
*/
if (hdr->gso_type || !xdp_prog)
- *generic_xdp = 1;
+ *skb_xdp = 1;
else
- *generic_xdp = 0;
+ *skb_xdp = 0;
rcu_read_lock();
xdp_prog = rcu_dereference(tun->xdp_prog);
- if (xdp_prog && !*generic_xdp) {
+ if (xdp_prog && !*skb_xdp) {
struct xdp_buff xdp;
void *orig_data;
u32 act;
@@ -1389,7 +1389,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
bool zerocopy = false;
int err;
u32 rxhash;
- int generic_xdp = 1;
+ int skb_xdp = 1;
if (!(tun->dev->flags & IFF_UP))
return -EIO;
@@ -1448,7 +1448,11 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
}
if (tun_can_build_skb(tun, tfile, len, noblock, zerocopy)) {
- skb = tun_build_skb(tun, tfile, from, &gso, len, &generic_xdp);
+ /* For the packet that is not easy to be processed
+* (e.g gso or jumbo packet), we will do it at after
+* skb was created with generic XDP routine.
+*/
+ skb = tun_build_skb(tun, tfile, from, &gso, len, &skb_xdp);
if (IS_ERR(skb)) {
this_cpu_inc(tun->pcpu_stats->rx_dropped);
return PTR_ERR(skb);
@@ -1528,7 +1532,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
- if (generic_xdp) {
+ if (skb_xdp) {
struct bpf_prog *xdp_prog;
int ret;
--
2.7.4
Re: [PATCH net] net: dsa: loop: Do not unregister invalid fixed PHY
From: Florian Fainelli
Date: Sat, 2 Sep 2017 08:56:45 -0700
> During error injection it was possible to crash in dsa_loop_exit() because of
> an attempt to unregister an invalid PHY. We actually want to the driver
> probing
> in dsa_loop_init() even though fixed_phy_register() may return an error to
> exercise how DSA deals with such cases, but we should not be crashing during
> driver removal.
>
> Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
> Signed-off-by: Florian Fainelli
Applied and queued up for -stable, thanks.
Re: [RFC][PATCH] exec: Don't wait for ptraced threads to be reaped.
Sorry about replying to this old thread, but... On Mon, Apr 3, 2017 at 9:07 AM, Eric W. Biederman wrote: > I don't know who actually useses PTRACE_O_TRACEEXIT so I don't actually > know what the implications of changing it are. Let's see... > > gdb - no > upstart - no > lldb - yes > strace - no For the record, rr uses PTRACE_O_TRACEEXIT. When a thread exits we need to examine its address space to find its robust futex list and record the changes that will be performed by the kernel as it cleans up that list. So, any failures to deliver PTRACE_EVENT_EXIT are potentially problematic for us because we won't get a chance to examine the address space before it disappears. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [PATCH net-next v3 0/3] net: mvpp2: improve the mac address retrieval logic
From: Antoine Tenart Date: Sat, 2 Sep 2017 11:06:46 +0200 > This series aims at fixing the logic behind the MAC address retrieval in the > PPv2 driver. A possible issue is also fixed in patch 3/3 to introduce > fallbacks > when the address given in the device tree isn't valid. ... > Since v2: > - Patch 1/4 from v2 was applied on net (and net was merged in net-next). > - Rebased on net-next. > > Since v1: > - Rebased onto net (was on net-next). Series applied, thank you.
[PATCH v2] Revert "f2fs: add a new function get_ssr_cost"
This reverts commit b7b7c4cf1c9ef0272a65f1480457cbfdadcda19d.
se->ckpt_valid_blocks will never be smaller than se->valid_blocks, so just
remove get_ssr_cost.
Signed-off-by: Yunlong Song
Signed-off-by: Chao Yu
---
fs/f2fs/gc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index cd147e7..b226760 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -277,20 +277,11 @@ static unsigned int get_greedy_cost(struct f2fs_sb_info
*sbi,
valid_blocks * 2 : valid_blocks;
}
-static unsigned int get_ssr_cost(struct f2fs_sb_info *sbi,
- unsigned int segno)
-{
- struct seg_entry *se = get_seg_entry(sbi, segno);
-
- return se->ckpt_valid_blocks > se->valid_blocks ?
- se->ckpt_valid_blocks : se->valid_blocks;
-}
-
static inline unsigned int get_gc_cost(struct f2fs_sb_info *sbi,
unsigned int segno, struct victim_sel_policy *p)
{
if (p->alloc_mode == SSR)
- return get_ssr_cost(sbi, segno);
+ return get_seg_entry(sbi, segno)->ckpt_valid_blocks;
/* alloc_mode == LFS */
if (p->gc_mode == GC_GREEDY)
--
1.8.5.2
linux-next: manual merge of the block tree with Linus' tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/nvme/host/rdma.c
between commit:
b925a2dc165e ("nvme-rdma: default MR page size to 4k")
from Linus' tree and commits:
90af35123d3b ("nvme-rdma: move nvme_rdma_configure_admin_queue code location")
a7b7c7a105a5 ("nvme-rdma: Use unlikely macro in the fast path")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/nvme/host/rdma.c
index a7f7d0ae3331,6a7682620d87..
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@@ -605,10 -629,9 +626,10 @@@ out_stop_queues
return ret;
}
- static int nvme_rdma_init_io_queues(struct nvme_rdma_ctrl *ctrl)
+ static int nvme_rdma_alloc_io_queues(struct nvme_rdma_ctrl *ctrl)
{
struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
+ struct ib_device *ibdev = ctrl->device->dev;
unsigned int nr_io_queues;
int i, ret;
@@@ -656,10 -734,144 +741,144 @@@ static void nvme_rdma_destroy_admin_que
{
nvme_rdma_free_qe(ctrl->queues[0].device->dev, &ctrl->async_event_sqe,
sizeof(struct nvme_command), DMA_TO_DEVICE);
- nvme_rdma_stop_and_free_queue(&ctrl->queues[0]);
- blk_cleanup_queue(ctrl->ctrl.admin_q);
- blk_mq_free_tag_set(&ctrl->admin_tag_set);
- nvme_rdma_dev_put(ctrl->device);
+ nvme_rdma_stop_queue(&ctrl->queues[0]);
+ if (remove) {
+ blk_cleanup_queue(ctrl->ctrl.admin_q);
+ nvme_rdma_free_tagset(&ctrl->ctrl, true);
+ }
+ nvme_rdma_free_queue(&ctrl->queues[0]);
+ }
+
+ static int nvme_rdma_configure_admin_queue(struct nvme_rdma_ctrl *ctrl,
+ bool new)
+ {
+ int error;
+
+ error = nvme_rdma_alloc_queue(ctrl, 0, NVME_AQ_DEPTH);
+ if (error)
+ return error;
+
+ ctrl->device = ctrl->queues[0].device;
+
+ ctrl->max_fr_pages = min_t(u32, NVME_RDMA_MAX_SEGMENTS,
+ ctrl->device->dev->attrs.max_fast_reg_page_list_len);
+
+ if (new) {
+ ctrl->ctrl.admin_tagset = nvme_rdma_alloc_tagset(&ctrl->ctrl,
true);
+ if (IS_ERR(ctrl->ctrl.admin_tagset))
+ goto out_free_queue;
+
+ ctrl->ctrl.admin_q = blk_mq_init_queue(&ctrl->admin_tag_set);
+ if (IS_ERR(ctrl->ctrl.admin_q)) {
+ error = PTR_ERR(ctrl->ctrl.admin_q);
+ goto out_free_tagset;
+ }
+ } else {
+ error = blk_mq_reinit_tagset(&ctrl->admin_tag_set,
+nvme_rdma_reinit_request);
+ if (error)
+ goto out_free_queue;
+ }
+
+ error = nvme_rdma_start_queue(ctrl, 0);
+ if (error)
+ goto out_cleanup_queue;
+
+ error = ctrl->ctrl.ops->reg_read64(&ctrl->ctrl, NVME_REG_CAP,
+ &ctrl->ctrl.cap);
+ if (error) {
+ dev_err(ctrl->ctrl.device,
+ "prop_get NVME_REG_CAP failed\n");
+ goto out_cleanup_queue;
+ }
+
+ ctrl->ctrl.sqsize =
+ min_t(int, NVME_CAP_MQES(ctrl->ctrl.cap), ctrl->ctrl.sqsize);
+
+ error = nvme_enable_ctrl(&ctrl->ctrl, ctrl->ctrl.cap);
+ if (error)
+ goto out_cleanup_queue;
+
+ ctrl->ctrl.max_hw_sectors =
- (ctrl->max_fr_pages - 1) << (PAGE_SHIFT - 9);
++ (ctrl->max_fr_pages - 1) << (ilog2(SZ_4K) - 9);
+
+ error = nvme_init_identify(&ctrl->ctrl);
+ if (error)
+ goto out_cleanup_queue;
+
+ error = nvme_rdma_alloc_qe(ctrl->queues[0].device->dev,
+ &ctrl->async_event_sqe, sizeof(struct nvme_command),
+ DMA_TO_DEVICE);
+ if (error)
+ goto out_cleanup_queue;
+
+ return 0;
+
+ out_cleanup_queue:
+ if (new)
+ blk_cleanup_queue(ctrl->ctrl.admin_q);
+ out_free_tagset:
+ if (new)
+ nvme_rdma_free_tagset(&ctrl->ctrl, true);
+ out_free_queue:
+ nvme_rdma_free_queue(&ctrl->queues[0]);
+ return error;
+ }
+
+ static void nvme_rdma_destroy_io_queues(struct nvme_rdma_ctrl *ctrl,
+ bool remove)
+ {
+ nvme_rdma_stop_io_queues(ctrl);
+ if (remove) {
+ blk_cleanup_queue(ctrl->ctrl.connect_q);
+ nvme_rdma_free_tagset(&ctrl->ctrl, false);
+ }
+ nvme_rdma_free_io_queues(ctrl);
+ }
+
+ static int nvme_rdma_configure_io_queues(struct nvme_rdma_ctrl *ctrl, bool
new)
+ {
+ int ret;
+
Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3
On 2017/8/17 8:05, Jérôme Glisse wrote:
> Unlike unaddressable memory, coherent device memory has a real
> resource associated with it on the system (as CPU can address
> it). Add a new helper to hotplug such memory within the HMM
> framework.
>
Got an new question, coherent device( e.g CCIX) memory are likely reported to
OS
through ACPI and recognized as NUMA memory node.
Then how can their memory be captured and managed by HMM framework?
--
Regards,
Bob Liu
> Changed since v2:
> - s/host/public
> Changed since v1:
> - s/public/host
>
> Signed-off-by: Jérôme Glisse
> Reviewed-by: Balbir Singh
> ---
> include/linux/hmm.h | 3 ++
> mm/hmm.c| 88
> ++---
> 2 files changed, 86 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> index 79e63178fd87..5866f3194c26 100644
> --- a/include/linux/hmm.h
> +++ b/include/linux/hmm.h
> @@ -443,6 +443,9 @@ struct hmm_devmem {
> struct hmm_devmem *hmm_devmem_add(const struct hmm_devmem_ops *ops,
> struct device *device,
> unsigned long size);
> +struct hmm_devmem *hmm_devmem_add_resource(const struct hmm_devmem_ops *ops,
> +struct device *device,
> +struct resource *res);
> void hmm_devmem_remove(struct hmm_devmem *devmem);
>
> /*
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 1a1e79d390c1..3faa4d40295e 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -854,7 +854,11 @@ static void hmm_devmem_release(struct device *dev, void
> *data)
> zone = page_zone(page);
>
> mem_hotplug_begin();
> - __remove_pages(zone, start_pfn, npages);
> + if (resource->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY)
> + __remove_pages(zone, start_pfn, npages);
> + else
> + arch_remove_memory(start_pfn << PAGE_SHIFT,
> +npages << PAGE_SHIFT);
> mem_hotplug_done();
>
> hmm_devmem_radix_release(resource);
> @@ -890,7 +894,11 @@ static int hmm_devmem_pages_create(struct hmm_devmem
> *devmem)
> if (is_ram == REGION_INTERSECTS)
> return -ENXIO;
>
> - devmem->pagemap.type = MEMORY_DEVICE_PRIVATE;
> + if (devmem->resource->desc == IORES_DESC_DEVICE_PUBLIC_MEMORY)
> + devmem->pagemap.type = MEMORY_DEVICE_PUBLIC;
> + else
> + devmem->pagemap.type = MEMORY_DEVICE_PRIVATE;
> +
> devmem->pagemap.res = devmem->resource;
> devmem->pagemap.page_fault = hmm_devmem_fault;
> devmem->pagemap.page_free = hmm_devmem_free;
> @@ -935,9 +943,15 @@ static int hmm_devmem_pages_create(struct hmm_devmem
> *devmem)
>* over the device memory is un-accessible thus we do not want to
>* create a linear mapping for the memory like arch_add_memory()
>* would do.
> + *
> + * For device public memory, which is accesible by the CPU, we do
> + * want the linear mapping and thus use arch_add_memory().
>*/
> - ret = add_pages(nid, align_start >> PAGE_SHIFT,
> - align_size >> PAGE_SHIFT, false);
> + if (devmem->pagemap.type == MEMORY_DEVICE_PUBLIC)
> + ret = arch_add_memory(nid, align_start, align_size, false);
> + else
> + ret = add_pages(nid, align_start >> PAGE_SHIFT,
> + align_size >> PAGE_SHIFT, false);
> if (ret) {
> mem_hotplug_done();
> goto error_add_memory;
> @@ -1084,6 +1098,67 @@ struct hmm_devmem *hmm_devmem_add(const struct
> hmm_devmem_ops *ops,
> }
> EXPORT_SYMBOL(hmm_devmem_add);
>
> +struct hmm_devmem *hmm_devmem_add_resource(const struct hmm_devmem_ops *ops,
> +struct device *device,
> +struct resource *res)
> +{
> + struct hmm_devmem *devmem;
> + int ret;
> +
> + if (res->desc != IORES_DESC_DEVICE_PUBLIC_MEMORY)
> + return ERR_PTR(-EINVAL);
> +
> + static_branch_enable(&device_private_key);
> +
> + devmem = devres_alloc_node(&hmm_devmem_release, sizeof(*devmem),
> +GFP_KERNEL, dev_to_node(device));
> + if (!devmem)
> + return ERR_PTR(-ENOMEM);
> +
> + init_completion(&devmem->completion);
> + devmem->pfn_first = -1UL;
> + devmem->pfn_last = -1UL;
> + devmem->resource = res;
> + devmem->device = device;
> + devmem->ops = ops;
> +
> + ret = percpu_ref_init(&devmem->ref, &hmm_devmem_ref_release,
> + 0, GFP_KERNEL);
> + if (ret)
> + goto error_percpu_ref;
> +
> + ret = devm_add_action(device, hmm_devmem_ref_exit, &devmem->ref);
> + if (ret)
> + goto error_devm_add_action;
> +
> +
> + devmem->pfn_first = devmem->resource->start >> PAGE_SHIFT;
> + devmem->pfn_last = devmem->pfn_first +
>
Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory
On Mon, Sep 04, 2017 at 10:26:19AM +0800, Baoquan He wrote: >On 09/04/17 at 12:55am, Rafael J. Wysocki wrote: >> On Sunday, September 3, 2017 4:31:23 PM CEST Chao Fan wrote: >> > KASLR should choose the memory region of immovable node to extract kernel. >> > So get ACPI SRAT table and store the memory region of movable node which >> > kaslr shold avoid. >> >> Please elaborate. >> >> This is far too little information on what problem you are trying to address >> and why you are trying to address it in this particular way. > >Agree with Rafael. > >Why don't you try specifying those regions in cmdline and process them >in kaslr.c? Your colleague, Liyang has tried this way, just he only >considered the region in the first node. In this way, you don't need to Hi Baoquan, Yes, but if the region is not only in the first node, we can get the detail information about the memory scope and whether it's hotpluggable only by the ACPI table. The lines of code are so many, but we can get more information. Thanks, Chao Fan >touch ACPI tables with so many lines of code. > >Thanks >Baoquan > >
Re: [RFC PATCH v1 1/3] arm64/ras: support sea error recovery
Hi Julien,
On 2017/9/1 23:51, Julien Thierry wrote:
> Hi Xie,
>
> On 01/09/17 11:31, Xie XiuQi wrote:
>> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors
>> are consumed. In some cases, if the error address is in a clean page or a
>> read-only page, there is a chance to recover. Such as error occurs in a
>> instruction page, we can reread this page from disk instead of killing
>> process.
>>
>> Because memory_failure() may sleep, we can not call it directly in SEA
>> exception
>> context. So we saved faulting physical address associated with a process in
>> the
>> ghes handler and set __TIF_SEA_NOTIFY. When we return from SEA exception
>> context
>> and get into do_notify_resume() before the process running, we could check it
>> and call memory_failure() to do recovery. It's safe, because we are in
>> process
>> context.
>>
>> Signed-off-by: Xie XiuQi
>> Signed-off-by: Wang Xiongfeng
...
>> +
>> +void arm_proc_error_check(struct ghes *ghes, struct cper_sec_proc_arm *err)
>> +{
>> +int i, ret = -1;
>> +struct cper_arm_err_info *err_info;
>> +
>> +if ((ghes->generic->notify.type != ACPI_HEST_NOTIFY_SEA) ||
>> +(ghes->estatus->error_severity != CPER_SEV_RECOVERABLE))
>> +return;
>> +
>> +err_info = (struct cper_arm_err_info *)(err + 1);
>> +for (i = 0; i < err->err_info_num; i++, err_info++) {
>> +if (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR) {
>> +ret |= sea_save_info(err_info->physical_fault_addr);
>> +}
>> +}
>> +
>> +if (!ret)
>
> If ret is initialized to -1, this is never true since you only OR bits in ret.
>
> Should the body of the loop be:
> ret &= sea_save_info(err_info->physical_fault_addr);
>
> so as long as you as you manage to store 1 sea_info you set the thread flag?
>
> But if that's the case a boolean might make more sense:
>
> bool info_saved = false;
> [...]
> info_saved |= !sea_save_info(err_info->physical_fault_addr);
> [...]
> if (info_saved)
> [...]
>
You are right, I'll fix this issue, thanks.
>
>> +set_thread_flag(TIF_SEA_NOTIFY);
>> +}
>> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
>> index 089c3747..71e314e 100644
>> --- a/arch/arm64/kernel/signal.c
>> +++ b/arch/arm64/kernel/signal.c
>> @@ -38,6 +38,7 @@
>> #include
>> #include
>> #include
>> +#include
>> /*
>>* Do a signal return; undo the signal stack. These are aligned to 128-bit.
>> @@ -749,6 +750,13 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
>>* Update the trace code with the current status.
>>*/
>> trace_hardirqs_off();
>> +
>> +#ifdef CONFIG_ARM64_ERR_RECOV
>> +/* notify userspace of pending SEAs */
>> +if (thread_flags & _TIF_SEA_NOTIFY)
>> +sea_notify_process();
>> +#endif /* CONFIG_ARM64_ERR_RECOV */
>> +
>> do {
>> if (thread_flags & _TIF_NEED_RESCHED) {
>> schedule();
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 1f22a41..b38476d 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -594,14 +594,25 @@ static int do_sea(unsigned long addr, unsigned int
>> esr, struct pt_regs *regs)
>> nmi_exit();
>> }
>> -info.si_signo = SIGBUS;
>> -info.si_errno = 0;
>> -info.si_code = 0;
>> -if (esr & ESR_ELx_FnV)
>> -info.si_addr = NULL;
>> -else
>> -info.si_addr = (void __user *)addr;
>> -arm64_notify_die("", regs, &info, esr);
>> +if (user_mode(regs)) {
>> +if (test_thread_flag(TIF_SEA_NOTIFY))
>> +return ret;
>> +
>> +info.si_signo = SIGBUS;
>> +info.si_errno = 0;
>> +info.si_code = 0;
>> +if (esr & ESR_ELx_FnV)
>> +info.si_addr = NULL;
>> +else
>> +info.si_addr = (void __user *)addr;
>> +
>> +current->thread.fault_address = 0;
>> +current->thread.fault_code = esr;
>> +force_sig_info(info.si_signo, &info, current);
>> +} else {
>> +die("Uncorrected hardware memory error in kernel-access\n",
>> +regs, esr);
>> +}
>> return ret;
>> }
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index d661d45..fa9400d 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -52,6 +52,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "apei-internal.h"
>> @@ -520,6 +521,7 @@ static void ghes_do_proc(struct ghes *ghes,
>> else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
>> struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
>> +arm_proc_error_check(ghes, err);
>
> If I understand the Makefile change correctly, arm_proc_error_check is
> compiled only when CONFIG_ARM64_ERR_RECOV, don't you get a linker error here
> if this config is not selected?
>
Yes, it
Re: [PATCH net] vhost_net: correctly check tx avail during rx busy polling
On 2017年09月01日 23:51, Michael S. Tsirkin wrote:
On Fri, Sep 01, 2017 at 05:02:50PM +0800, Jason Wang wrote:
We check tx avail through vhost_enable_notify() in the past which is
wrong since it only checks whether or not guest has filled more
available buffer since last avail idx synchronization which was just
done by vhost_vq_avail_empty() before. What we really want is checking
pending buffers in the avail ring.
These are rx buffers, right? I'm not even sure why do we need to poll
for them. Running out of rx buffers is a slow path.
Actually it polls for tx buffer here. I admit the code (or probably the
variable name) is confusing here.
Fix this by calling
vhost_vq_avail_empty() instead.
This issue could be noticed by doing netperf TCP_RR benchmark as
client from guest (but not host). With this fix, TCP_RR from guest to
localhost restores from 1375.91 trans per sec to 55235.28 trans per
sec on my laptop (Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz).
Fixes: 030881372460 ("vhost_net: basic polling support")
Signed-off-by: Jason Wang
---
- The patch is needed for -stable
---
drivers/vhost/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 06d0448..1b68253 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -634,7 +634,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net
*net, struct sock *sk)
In fact why does it poll the ring at all? I thought this function's
job is to poll the socket, isn't it?
Tx notification is disabled to try to avoid vmexits, so we poll tx avail
buffers too.
preempt_enable();
- if (vhost_enable_notify(&net->dev, vq))
+ if (!vhost_vq_avail_empty(&net->dev, vq))
vhost_poll_queue(&vq->poll);
mutex_unlock(&vq->mutex);
Adding more contex:
mutex_lock(&vq->mutex);
vhost_disable_notify(&net->dev, vq);
preempt_disable();
endtime = busy_clock() + vq->busyloop_timeout;
while (vhost_can_busy_poll(&net->dev, endtime) &&
!sk_has_rx_data(sk) &&
vhost_vq_avail_empty(&net->dev, vq))
cpu_relax();
preempt_enable();
if (vhost_enable_notify(&net->dev, vq))
vhost_poll_queue(&vq->poll);
mutex_unlock(&vq->mutex);
len = peek_head_len(rvq, sk);
If you drop this we'll exit the function with notifications
disabled. Seems wrong to me.
Yes, will fix this in V2.
Thanks
--
2.7.4
Re: [PATCH] f2fs: clear get_ssr_cost
On 2017/9/4 9:54, Yunlong Song wrote:
> The update_sit_entry provides this:
> ...
> 1658 if (!f2fs_test_bit(offset, se->ckpt_valid_map))
> 1659 se->ckpt_valid_blocks += del;
> ...
> As a result, the ckpt_valid_blocks is always larger than valid_blocks.
> If not correct, can you provide
> the case valid_blocks larger than ckpt_valid_blocks?
Oh, I just nit-pick, :), how about using 'se->ckpt_valid_blocks will never be
smaller than se->valid_blocks' instead?
And could you just revert Yunlei's patch and add above commit log?
Thanks,
>
> On 2017/9/4 9:17, Chao Yu wrote:
>> On 2017/9/1 20:14, Yunlong Song wrote:
>>> se->ckpt_valid_blocks is always larger than se->valid_blocks, so
>>> get_ssr_cost can be cleared.
>> I think this is not correct.
>>
>> Thanks,
>>
>>> Signed-off-by: Yunlong Song
>>> ---
>>> fs/f2fs/gc.c | 11 +--
>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index cd147e7..b226760 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -277,20 +277,11 @@ static unsigned int get_greedy_cost(struct
>>> f2fs_sb_info *sbi,
>>> valid_blocks * 2 : valid_blocks;
>>> }
>>>
>>> -static unsigned int get_ssr_cost(struct f2fs_sb_info *sbi,
>>> - unsigned int segno)
>>> -{
>>> - struct seg_entry *se = get_seg_entry(sbi, segno);
>>> -
>>> - return se->ckpt_valid_blocks > se->valid_blocks ?
>>> - se->ckpt_valid_blocks : se->valid_blocks;
>>> -}
>>> -
>>> static inline unsigned int get_gc_cost(struct f2fs_sb_info *sbi,
>>> unsigned int segno, struct victim_sel_policy *p)
>>> {
>>> if (p->alloc_mode == SSR)
>>> - return get_ssr_cost(sbi, segno);
>>> + return get_seg_entry(sbi, segno)->ckpt_valid_blocks;
>>>
>>> /* alloc_mode == LFS */
>>> if (p->gc_mode == GC_GREEDY)
>>>
>>
>> .
>>
>
linux-next: build warning after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
sound/soc/codecs/cs43130.c: In function 'cs43130_imp_meas':
sound/soc/codecs/cs43130.c:2089:18: warning: 'hpload_seq' may be used
uninitialized in this function [-Wmaybe-uninitialized]
hpload_seq[i].msk, ac_idx);
^
Introduced by commit
8f1e5bf9b440 ("ASoC: cs43130: Add support for CS43130 codec")
This is probably a false positive.
--
Cheers,
Stephen Rothwell
Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory
On 09/04/17 at 12:55am, Rafael J. Wysocki wrote: > On Sunday, September 3, 2017 4:31:23 PM CEST Chao Fan wrote: > > KASLR should choose the memory region of immovable node to extract kernel. > > So get ACPI SRAT table and store the memory region of movable node which > > kaslr shold avoid. > > Please elaborate. > > This is far too little information on what problem you are trying to address > and why you are trying to address it in this particular way. Agree with Rafael. Why don't you try specifying those regions in cmdline and process them in kaslr.c? Your colleague, Liyang has tried this way, just he only considered the region in the first node. In this way, you don't need to touch ACPI tables with so many lines of code. Thanks Baoquan
Re: [PATCH] iio staging: tsl2x7x: clean up limit checks
On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote:
> On Mon, 21 Aug 2017 13:11:03 +0300
> Dan Carpenter wrote:
>
> > The second part of this patch is probably the most interesting. We
> > use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
> > "TSL2X7X_MAX_LUX_TABLE_SIZE". It creates a static checker warning that
> > we are going of of bounds, but in real life we always hit the break
> > statement on the last element so it's fine.
> >
> > The situation is that we normally have arrays with 3 elements of struct
> > tsl2x7x_lux which has 3 unsigned integers. If we load the table with
> > sysfs then we're allow to have 9 elements instead.
> >
> > So the size of the default table in bytes is sizeof(int) times 3 struct
> > members times 3 elements. The original code wrote it as sizeof(int)
> > times the number of elements in the bigger table (9). It happens that
> > 9 is the same thing as 3 * 3 but expressing it that way is misleading.
> >
> > For the second part of the patch, the original code just had an extra
> > "multiply by three" and now that is removed. The last element in the
> > array is always zeroed memory whether this uses the default tables or it
> > gets loaded with sysfs so we always hit the break statement anyway.
> >
> > Signed-off-by: Dan Carpenter
>
> Looks sensible to me.
>
> Cc'd Brian who has been working extensively on this driver recently as I'd
> like his input.
>
> Jonathan
> >
> > diff --git a/drivers/staging/iio/light/tsl2x7x.h
> > b/drivers/staging/iio/light/tsl2x7x.h
> > index ecae92211216..1beb8d2eb848 100644
> > --- a/drivers/staging/iio/light/tsl2x7x.h
> > +++ b/drivers/staging/iio/light/tsl2x7x.h
> > @@ -23,10 +23,6 @@
> > #define __TSL2X7X_H
> > #include
> >
> > -/* Max number of segments allowable in LUX table */
> > -#define TSL2X7X_MAX_LUX_TABLE_SIZE 9
> > -#define MAX_DEFAULT_TABLE_BYTES (sizeof(int) * TSL2X7X_MAX_LUX_TABLE_SIZE)
> > -
> > struct iio_dev;
> >
> > struct tsl2x7x_lux {
> > @@ -35,6 +31,11 @@ struct tsl2x7x_lux {
> > unsigned int ch1;
> > };
> >
> > +/* Max number of segments allowable in LUX table */
> > +#define TSL2X7X_MAX_LUX_TABLE_SIZE 9
> > +/* The default tables are all 3 elements */
> > +#define MAX_DEFAULT_TABLE_BYTES (sizeof(struct tsl2x7x_lux) * 3)
> > +
> > /**
> > * struct tsl2x7x_default_settings - power on defaults unless
> > * overridden by platform data.
> > diff --git a/drivers/staging/iio/light/tsl2x7x.c
> > b/drivers/staging/iio/light/tsl2x7x.c
> > index 786e93f16ce9..2db1715ff659 100644
> > --- a/drivers/staging/iio/light/tsl2x7x.c
> > +++ b/drivers/staging/iio/light/tsl2x7x.c
> > @@ -1113,7 +1113,7 @@ static ssize_t in_illuminance0_lux_table_show(struct
> > device *dev,
> > int i = 0;
> > int offset = 0;
> >
> > - while (i < (TSL2X7X_MAX_LUX_TABLE_SIZE * 3)) {
> > + while (i < TSL2X7X_MAX_LUX_TABLE_SIZE) {
> > offset += snprintf(buf + offset, PAGE_SIZE, "%u,%u,%u,",
> > chip->tsl2x7x_device_lux[i].ratio,
> > chip->tsl2x7x_device_lux[i].ch0,
There is a minor issue regarding the structure sizes in with both this
patch and the in-tree code. The following two structures define nine
rows in the lux table:
tsl2x7x.h:
#define TSL2X7X_MAX_LUX_TABLE_SIZE 9
struct tsl2X7X_platform_data {
...
struct tsl2x7x_lux platform_lux_table[TSL2X7X_MAX_LUX_TABLE_SIZE];
}
tsl2x7x.c:
struct tsl2X7X_chip {
...
struct tsl2x7x_lux tsl2x7x_device_lux[TSL2X7X_MAX_LUX_TABLE_SIZE];
}
tsl2x7x_defaults() has this code snippet:
memcpy(chip->tsl2x7x_device_lux,
(struct tsl2x7x_lux *)tsl2x7x_default_lux_table_group[chip->id],
MAX_DEFAULT_TABLE_BYTES);
With the old and new code, memcpy will only copy the first three rows of
the lux table. There is no security issue though with the actual
implementation since the four *_lux_table structures that are defined in
code only have three rows defined.
I believe that the correct fix is to define MAX_DEFAULT_TABLE_BYTES in
Dan's patch as follows (and keeping his other changes):
#define MAX_DEFAULT_TABLE_BYTES (sizeof(struct tsl2x7x_lux) *
TSL2X7X_MAX_LUX_TABLE_SIZE)
We may also want to shorten those #defines to keep it under 80
characters.
Brian
Re: [PATCH v4 0/2] add thermal nodes for UniPhier SoCs
Hi. 2017-09-04 10:16 GMT+09:00 Kunihiko Hayashi : > This series adds thermal nodes for UniPhier PXs2 and LD20 SoCs. > > Changes since v3: > - rebase on top of linux-next This repost is a spam. I left some comments in v3, but no response from you nothing was reflected in v4. > Changes since v2: > - add the calibration value to device tree for LD20 reference board > > Changes since v1: > - separate from driver's patchset[1] > - add cooling-maps nodes on the device tree > - fix an interrupt trigger to set 'level-triggered' according to > hardware specification > - bring up threshold temperature for LD20 according to the spec sheet > - add cpuN labels for reference in cooling-device property on PXs2 dts > > [1] https://lkml.org/lkml/2017/6/28/170 > > Kunihiko Hayashi (2): > ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for > PXs2 > arm64: dts: uniphier: add nodes of thermal monitor and thermal zone > for LD20 > > arch/arm/boot/dts/uniphier-pxs2.dtsi | 43 > -- > .../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 4 ++ > arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 40 > 3 files changed, 83 insertions(+), 4 deletions(-) > > -- > 2.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote: > On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote: > > On Fri, Sep 01, 2017 at 10:51:48PM +0900, Byungchul Park wrote: > > > On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra > > > wrote: > > > > On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote: > > > > > > > >> It would be gone _only_ at the time the history overrun, and then it > > > >> will be built again. So, you are wrong. > > > > > > s/it will be built again/the acquisition will be added into the xhlock > > > array again/ > > > > > > Now, better to understand? > > > > No, I still don't get it. How are we ever going to get the workqueue > > thread setup code back after its spooled out? > > > > > > How will it ever be build again? You only ever spawn the worker thread > > > > _ONCE_, then it runs lots and lots of works. > > > > > > > > We _could_ go fix it, but I really don't see it being worth the time and > > > > > > We don't need to fix it spending time and effort. Just *revert* all your > > > wrong patches. > > > > And get tangled up with the workqueue annotation again, no thanks. > > Having the first few works see the thread setup isn't worth it. > > > > And your work_id annotation had the same problem. > > I keep asking you for an example because I really understand you. I keep asking you for an example because I really want to understand you. > >Fix my problematic example with your patches, > >or, > >Show me a problematic scenario with my original code, you expect. > > Whatever, it would be helpful to understand you.
Re: [PATCH] f2fs: clear get_ssr_cost
The update_sit_entry provides this:
...
1658 if (!f2fs_test_bit(offset, se->ckpt_valid_map))
1659 se->ckpt_valid_blocks += del;
...
As a result, the ckpt_valid_blocks is always larger than valid_blocks.
If not correct, can you provide
the case valid_blocks larger than ckpt_valid_blocks?
On 2017/9/4 9:17, Chao Yu wrote:
On 2017/9/1 20:14, Yunlong Song wrote:
se->ckpt_valid_blocks is always larger than se->valid_blocks, so
get_ssr_cost can be cleared.
I think this is not correct.
Thanks,
Signed-off-by: Yunlong Song
---
fs/f2fs/gc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index cd147e7..b226760 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -277,20 +277,11 @@ static unsigned int get_greedy_cost(struct f2fs_sb_info
*sbi,
valid_blocks * 2 : valid_blocks;
}
-static unsigned int get_ssr_cost(struct f2fs_sb_info *sbi,
- unsigned int segno)
-{
- struct seg_entry *se = get_seg_entry(sbi, segno);
-
- return se->ckpt_valid_blocks > se->valid_blocks ?
- se->ckpt_valid_blocks : se->valid_blocks;
-}
-
static inline unsigned int get_gc_cost(struct f2fs_sb_info *sbi,
unsigned int segno, struct victim_sel_policy *p)
{
if (p->alloc_mode == SSR)
- return get_ssr_cost(sbi, segno);
+ return get_seg_entry(sbi, segno)->ckpt_valid_blocks;
/* alloc_mode == LFS */
if (p->gc_mode == GC_GREEDY)
.
--
Thanks,
Yunlong Song
Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory
On Mon, Sep 04, 2017 at 12:55:00AM +0200, Rafael J. Wysocki wrote: >On Sunday, September 3, 2017 4:31:23 PM CEST Chao Fan wrote: >> KASLR should choose the memory region of immovable node to extract kernel. >> So get ACPI SRAT table and store the memory region of movable node which >> kaslr shold avoid. > >Please elaborate. Hi Rafael, Sorry for that. The problem is: in a machine, some numa nodes are hotpluggable, some are not. The kernel should use the memory in unhotpluggable. But when extracting kernel, kaslr may chooose the memory in hotpluggable or unhotpluggable node. The ACPI SRAT table can show the node is hotpluggable or not. But the acpi_boot_table_init runs in setup_arch, which is after extracting kernel. So I imitate the initialization in acpi_boot_table_init to get the table before extracting kernel. And mark the memory region in hotpluggable node to avoid kaslr extracting kernel in these regions. Thanks, Chao Fan > >This is far too little information on what problem you are trying to address >and why you are trying to address it in this particular way. > >Thanks, >Rafael > > >
Re: [PATCH 1/1] docs-rst: media: Don't use \small for V4L2_PIX_FMT_SRGGB10 documentation
Em Sun, 3 Sep 2017 23:12:33 +0300
Sakari Ailus escreveu:
> There appears to be an issue in using \small in certain cases on Sphinx
> 1.4 and 1.5. Other format documents don't use \small either, remove it
> from here as well.
>
> Signed-off-by: Sakari Ailus
> ---
> Hi Mauro,
>
> What would you think of this as an alternative approach? No hacks needed.
> Just a recognition \small could have issues. For what it's worth, I
> couldn't reproduce the issue on Sphinx 1.4.9.
Btw, there are other places where \small runs smoothly. It is *just*
on this table that it has issues.
>
> Regards,
> Sakari
>
> Documentation/media/uapi/v4l/pixfmt-srggb10p.rst | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
> b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
> index 86cd07e5bfa3..368ee61ab209 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
> @@ -33,13 +33,6 @@ of a small V4L2_PIX_FMT_SBGGR10P image:
> **Byte Order.**
> Each cell is one byte.
>
> -
> -.. raw:: latex
> -
> -\small
Interesting... yeah, that could be possible.
> -
> -.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{10.0cm}|
Nah... Without tabularcolumns, LaTeX usually got sizes wrong and don't
always place things at the right positions I'm actually considering
adding it to all media tables, in order to be less dependent on
LaTex automatic cells resizing - with doesn't seem to work too well.
So, better to keep it, even if it works without
\small. Btw, tried your patch here (without tabularcolumns) on
Sphinx 1.6 (tomorrow, I'll do tests with other version). There, the
last "(bits x-y)" ends by being wrapped to the next line.
Yet, I guess the enclosed diff (or something like that) would be
good enough (applied after my own patch, just to quickly test it).
I'll play more with it tomorrow.
Thanks,
Mauro
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
index aa3dbf163b97..10350f3e4350 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
@@ -33,24 +33,7 @@ of a small V4L2_PIX_FMT_SBGGR10P image:
**Byte Order.**
Each cell is one byte.
-.. raw:: latex
-
-\small
-
-.. HACK:
-
- On Sphinx 1.4 and 1.5, the usage of \small just before the table
- causes it to continue at the same column where the above text ended.
-
- A possible solution would be to add a \newline on latex raw.
- Unfortunately, that causes a breakage on Sphinx 1.6.
-
- So, we're placing the \small before this note, with should be producing
- the same result on all versions
-
-.
-
-.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{10.0cm}|
+.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{6.0cm}|
.. flat-table::
:header-rows: 0
@@ -63,6 +46,7 @@ Each cell is one byte.
- B\ :sub:`02high`
- G\ :sub:`03high`
- G\ :sub:`03low`\ (bits 7--6) B\ :sub:`02low`\ (bits 5--4)
+
G\ :sub:`01low`\ (bits 3--2) B\ :sub:`00low`\ (bits 1--0)
* - start + 5:
- G\ :sub:`10high`
@@ -70,6 +54,7 @@ Each cell is one byte.
- G\ :sub:`12high`
- R\ :sub:`13high`
- R\ :sub:`13low`\ (bits 7--6) G\ :sub:`12low`\ (bits 5--4)
+
R\ :sub:`11low`\ (bits 3--2) G\ :sub:`10low`\ (bits 1--0)
* - start + 10:
- B\ :sub:`20high`
@@ -77,6 +62,7 @@ Each cell is one byte.
- B\ :sub:`22high`
- G\ :sub:`23high`
- G\ :sub:`23low`\ (bits 7--6) B\ :sub:`22low`\ (bits 5--4)
+
G\ :sub:`21low`\ (bits 3--2) B\ :sub:`20low`\ (bits 1--0)
* - start + 15:
- G\ :sub:`30high`
@@ -84,8 +70,5 @@ Each cell is one byte.
- G\ :sub:`32high`
- R\ :sub:`33high`
- R\ :sub:`33low`\ (bits 7--6) G\ :sub:`32low`\ (bits 5--4)
- R\ :sub:`31low`\ (bits 3--2) G\ :sub:`30low`\ (bits 1--0)
-
-.. raw:: latex
-\normalsize
+ R\ :sub:`31low`\ (bits 3--2) G\ :sub:`30low`\ (bits 1--0)
Re: Re: [PATCH] mm/vmstats: add counters for the page frag cache
Thanks for your reply, We already used other i/f like page_owner and kmemleak to resolve memory leakage issue. But, page_owner can only for guess but cannot find intuitively memory usage regarding page_frag_cache. And kmemleak cannot use (because of calling directly __alloc_pages_nodemask()). Additionally, some embedded linux like Android or something.. is not able to always use kmemleak & page_owner because of runtime performance deterioration. However, the root cause of this memory issue is from net device like wireless. In short, should always use wireless on device but, cannot use those memory debug tools. That's why those counters need.. and for much cheaper I can remove pgfrag_alloc_calls and pgfrag_free_calls. Thanks, Kyeongdon Kim On 2017-09-01 오후 6:21, Michal Hocko wrote: On Fri 01-09-17 12:12:36, Konstantin Khlebnikov wrote: > IMHO that's too much counters. > Per-node NR_FRAGMENT_PAGES should be enough for guessing what's going on. > Perf probes provides enough features for furhter debugging. I would tend to agree. Adding a counter based on a single debugging instance sounds like an overkill to me. Counters should be pretty cheep but this is way too specialized API to export to the userspace. We have other interfaces to debug memory leaks like page_owner. -- Michal Hocko SUSE Labs
Re: Re: [PATCH] mm/vmstats: add counters for the page frag cache
Thanks for your reply, But I couldn't find "NR_FRAGMENT_PAGES" in linux-next.git .. is that vmstat counter? or others? As you know, page_frag_alloc() directly calls __alloc_pages_nodemask() function, so that makes too difficult to see memory usage in real time even though we have "/meminfo or /slabinfo.." information. If there was a way already to figure out the memory leakage from page_frag_cache in mainline, I agree your opinion but I think we don't have it now. If those counters too much in my patch, I can say two values (pgfrag_alloc and pgfrag_free) are enough to guess what will happen and would remove pgfrag_alloc_calls and pgfrag_free_calls. Thanks, Kyeongdon Kim On 2017-09-01 오후 6:12, Konstantin Khlebnikov wrote: IMHO that's too much counters. Per-node NR_FRAGMENT_PAGES should be enough for guessing what's going on. Perf probes provides enough features for furhter debugging. On 01.09.2017 02:37, Kyeongdon Kim wrote: > There was a memory leak problem when we did stressful test > on Android device. > The root cause of this was from page_frag_cache alloc > and it was very hard to find out. > > We add to count the page frag allocation and free with function call. > The gap between pgfrag_alloc and pgfrag_free is good to to calculate > for the amount of page. > The gap between pgfrag_alloc_calls and pgfrag_free_calls is for > sub-indicator. > They can see trends of memory usage during the test. > Without it, it's difficult to check page frag usage so I believe we > should add it. > > Signed-off-by: Kyeongdon Kim > ---
Re: [f2fs-dev] [PATCH 2/2] f2fs: don't check inode's checksum if it was dirtied or writebacked
On 2017/9/2 1:25, Jaegeuk Kim wrote: > If another thread already made the page dirtied or writebacked, we must avoid > to verify checksum. If we got an error, we need to remove its uptodate as > well. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu > --- > fs/f2fs/inode.c | 3 ++- > fs/f2fs/node.c | 2 +- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c > index b4c401d456e7..c33b05aec1a1 100644 > --- a/fs/f2fs/inode.c > +++ b/fs/f2fs/inode.c > @@ -153,7 +153,8 @@ bool f2fs_inode_chksum_verify(struct f2fs_sb_info *sbi, > struct page *page) > struct f2fs_inode *ri; > __u32 provided, calculated; > > - if (!f2fs_enable_inode_chksum(sbi, page)) > + if (!f2fs_enable_inode_chksum(sbi, page) || > + PageDirty(page) || PageWriteback(page)) > return true; > > ri = &F2FS_NODE(page)->i; > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c > index 388a00262a5f..fca87835a1da 100644 > --- a/fs/f2fs/node.c > +++ b/fs/f2fs/node.c > @@ -1187,9 +1187,9 @@ static struct page *__get_node_page(struct f2fs_sb_info > *sbi, pgoff_t nid, > nid, nid_of_node(page), ino_of_node(page), > ofs_of_node(page), cpver_of_node(page), > next_blkaddr_of_node(page)); > - ClearPageUptodate(page); > err = -EINVAL; > out_err: > + ClearPageUptodate(page); > f2fs_put_page(page, 1); > return ERR_PTR(err); > } >
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote: > On Fri, Sep 01, 2017 at 10:51:48PM +0900, Byungchul Park wrote: > > On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra wrote: > > > On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote: > > > > > >> It would be gone _only_ at the time the history overrun, and then it > > >> will be built again. So, you are wrong. > > > > s/it will be built again/the acquisition will be added into the xhlock > > array again/ > > > > Now, better to understand? > > No, I still don't get it. How are we ever going to get the workqueue > thread setup code back after its spooled out? > > > > How will it ever be build again? You only ever spawn the worker thread > > > _ONCE_, then it runs lots and lots of works. > > > > > > We _could_ go fix it, but I really don't see it being worth the time and > > > > We don't need to fix it spending time and effort. Just *revert* all your > > wrong patches. > > And get tangled up with the workqueue annotation again, no thanks. > Having the first few works see the thread setup isn't worth it. > > And your work_id annotation had the same problem. I keep asking you for an example because I really understand you. Fix my problematic example with your patches, or, Show me a problematic scenario with my original code, you expect. Whatever, it would be helpful to understand you.
Re: [f2fs-dev] [PATCH 1/2] f2fs: don't need to update inode checksum for recovery
On 2017/9/2 1:25, Jaegeuk Kim wrote: > This patch fixes "f2fs: support inode checksum". > The recovered inode page will be rewritten with valid checksum. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu > --- > fs/f2fs/node.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c > index 2654c9166fba..388a00262a5f 100644 > --- a/fs/f2fs/node.c > +++ b/fs/f2fs/node.c > @@ -2287,8 +2287,6 @@ int recover_inode_page(struct f2fs_sb_info *sbi, struct > page *page) > F2FS_FITS_IN_INODE(src, le16_to_cpu(src->i_extra_isize), > i_projid)) > dst->i_projid = src->i_projid; > - > - f2fs_inode_chksum_set(sbi, ipage); > } > > new_ni = old_ni; >
Re: [PATCH] f2fs: clear get_ssr_cost
On 2017/9/1 20:14, Yunlong Song wrote:
> se->ckpt_valid_blocks is always larger than se->valid_blocks, so
> get_ssr_cost can be cleared.
I think this is not correct.
Thanks,
>
> Signed-off-by: Yunlong Song
> ---
> fs/f2fs/gc.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index cd147e7..b226760 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -277,20 +277,11 @@ static unsigned int get_greedy_cost(struct f2fs_sb_info
> *sbi,
> valid_blocks * 2 : valid_blocks;
> }
>
> -static unsigned int get_ssr_cost(struct f2fs_sb_info *sbi,
> - unsigned int segno)
> -{
> - struct seg_entry *se = get_seg_entry(sbi, segno);
> -
> - return se->ckpt_valid_blocks > se->valid_blocks ?
> - se->ckpt_valid_blocks : se->valid_blocks;
> -}
> -
> static inline unsigned int get_gc_cost(struct f2fs_sb_info *sbi,
> unsigned int segno, struct victim_sel_policy *p)
> {
> if (p->alloc_mode == SSR)
> - return get_ssr_cost(sbi, segno);
> + return get_seg_entry(sbi, segno)->ckpt_valid_blocks;
>
> /* alloc_mode == LFS */
> if (p->gc_mode == GC_GREEDY)
>
Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
Em Sun, 3 Sep 2017 22:05:23 +0200
Honza Petrouš escreveu:
> > There is still a gap at the CA API, as there are three ioctls that are used
> > only by a few drivers and whose structs are not properly documented:
> > CA_GET_MSG, CA_SEND_MSG and CA_SET_DESCR.
> >
> > The first two ones seem to be related to a way that a few drivers
> > provide to send/receive messages.
>
> I never seen usage of such R/W ioctls, all drivers I have access to
> are using read()/write() variant of communication.
Yeah, the normal usage is to use R/W syscalls.
> BTW, I just remembered dvblast app, part of videolan.org:
>
> http://www.videolan.org/projects/dvblast.html
>
> which is using CA_GET_MSG/CA_SEND_MSG:
>
> https://code.videolan.org/videolan/dvblast/blob/master/en50221.c
>From the ca_msg struct:
/* a message to/from a CI-CAM */
struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
};
It only uses length and msg fields. Describing those seem
quite obvious. However, what "index" and "type" means?
Within the Kernel, only two drivers implement it:
$ git grep -l ca_msg drivers/
drivers/media/firewire/firedtv-ci.c
drivers/media/pci/bt8xx/dst_ca.c
At the dst_ca driver, checking for those fields don't give any
useful result:
$ grep index drivers/media/pci/bt8xx/dst_ca.c
(nothing)
$ grep type drivers/media/pci/bt8xx/dst_ca.c
// Copy application_type, application_manufacturer and manufacturer_code
p_ca_caps->slot_type = 1;
p_ca_caps->descr_type = 1;
p_ca_slot_info->type = CA_CI;
p_ca_slot_info->type = CA_CI;
(btw, using "1" for slot_type and descr_type there seems a very bad
thing)
The code at ca_get_message(), handle_dst_tag(), ca_set_pmt(), etc also
doesn't seem to be using neither one of those fields.
The same happens at firedtv-ci: it also doesn't seem to be using
none of those fields.
It should be noticed that, the dst_ca seems to allow more than one
descrambler:
p_ca_caps->descr_num = slot_cap[7];
Yet, the index is not used. So, it doesn't seem to be related to
the descrambler index (or there's an implementation bug there - and
at dvblast - as none uses it).
What *I* suspect is that this were meant to be used for either
CA index/type or DESCR index/type, but, when this got implemented,
people discovered that this would be useless and never actually
used those fields. Yet, I may be completely wrong and those were
added to mean something else.
If so, then we could just change the struct to:
struct ca_msg {
unsigned int reserved[2];
unsigned int length;
unsigned char msg[256];
};
And document just length and msg.
Thanks,
Mauro
[PATCH v4 1/2] ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for PXs2
Add nodes of thermal monitor and thermal zone for UniPhier PXs2 SoC.
The thermal monitor is included in sysctrl.
Furthermore, add cpuN labels for reference in cooling-device property.
Signed-off-by: Kunihiko Hayashi
---
arch/arm/boot/dts/uniphier-pxs2.dtsi | 43
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 90b020c..c89e0d5 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -16,7 +16,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
@@ -24,9 +24,10 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
- cpu@1 {
+ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
@@ -36,7 +37,7 @@
operating-points-v2 = <&cpu_opp>;
};
- cpu@2 {
+ cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <2>;
@@ -46,7 +47,7 @@
operating-points-v2 = <&cpu_opp>;
};
- cpu@3 {
+ cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <3>;
@@ -114,6 +115,34 @@
};
};
+ thermal-zones {
+ cpu_thermal {
+ polling-delay-passive = <250>; /* 250ms */
+ polling-delay = <1000>; /* 1000ms */
+ thermal-sensors = <&pvtctl>;
+
+ trips {
+ cpu_crit: cpu_crit {
+ temperature = <95000>; /* 95C */
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ cpu_alert: cpu_alert {
+ temperature = <85000>; /* 85C */
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu0 (-1) (-1)>;
+ };
+ };
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -358,6 +387,12 @@
compatible = "socionext,uniphier-pxs2-reset";
#reset-cells = <1>;
};
+
+ pvtctl: pvtctl {
+ compatible = "socionext,uniphier-pxs2-thermal";
+ interrupts = <0 3 4>;
+ #thermal-sensor-cells = <0>;
+ };
};
nand: nand@6800 {
--
2.7.4
[PATCH v4 2/2] arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20
Add nodes of thermal monitor and thermal zone for UniPhier LD20 SoC.
The thermal monitor is included in sysctrl.
Furthermore, since the reference board doesn't have a calibrated value of
thermal monitor, this patch gives the default value for LD20 reference
board.
Signed-off-by: Kunihiko Hayashi
---
.../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 4 +++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 40 ++
2 files changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 1ca0c86..5bb63a2 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -50,3 +50,7 @@
&i2c0 {
status = "okay";
};
+
+&pvtctl {
+ socionext,tmod-calibration = <0x0f22 0x68ee>;
+};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..0f733ad 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -46,6 +46,7 @@
clocks = <&sys_clk 32>;
enable-method = "psci";
operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -64,6 +65,7 @@
clocks = <&sys_clk 33>;
enable-method = "psci";
operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
};
cpu3: cpu@101 {
@@ -173,6 +175,38 @@
<1 10 4>;
};
+ thermal-zones {
+ cpu_thermal {
+ polling-delay-passive = <250>; /* 250ms */
+ polling-delay = <1000>; /* 1000ms */
+ thermal-sensors = <&pvtctl>;
+
+ trips {
+ cpu_crit: cpu_crit {
+ temperature = <11>; /* 110C */
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ cpu_alert: cpu_alert {
+ temperature = <10>; /* 100C */
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu0 (-1) (-1)>;
+ };
+ map1 {
+ trip = <&cpu_alert>;
+ cooling-device = <&cpu2 (-1) (-1)>;
+ };
+ };
+ };
+ };
+
soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -410,6 +444,12 @@
watchdog {
compatible = "socionext,uniphier-wdt";
};
+
+ pvtctl: pvtctl {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <0 3 4>;
+ #thermal-sensor-cells = <0>;
+ };
};
nand: nand@6800 {
--
2.7.4
[PATCH v4 0/2] add thermal nodes for UniPhier SoCs
This series adds thermal nodes for UniPhier PXs2 and LD20 SoCs. Changes since v3: - rebase on top of linux-next Changes since v2: - add the calibration value to device tree for LD20 reference board Changes since v1: - separate from driver's patchset[1] - add cooling-maps nodes on the device tree - fix an interrupt trigger to set 'level-triggered' according to hardware specification - bring up threshold temperature for LD20 according to the spec sheet - add cpuN labels for reference in cooling-device property on PXs2 dts [1] https://lkml.org/lkml/2017/6/28/170 Kunihiko Hayashi (2): ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for PXs2 arm64: dts: uniphier: add nodes of thermal monitor and thermal zone for LD20 arch/arm/boot/dts/uniphier-pxs2.dtsi | 43 -- .../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 4 ++ arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 40 3 files changed, 83 insertions(+), 4 deletions(-) -- 2.7.4
Re: [PATCH 08/13] thermal/drivers/hisi: Fix configuration register setting
On Sat, Sep 02, 2017 at 10:34:34AM +0200, Daniel Lezcano wrote:
> On 02/09/2017 04:54, Leo Yan wrote:
> > On Wed, Aug 30, 2017 at 10:47:32AM +0200, Daniel Lezcano wrote:
> >> The TEMP0_CFG configuration register contains different field to set up the
> >> temperature controller. However in the code, nothing prevents a setup to
> >> overwrite the previous one: eg. writing the hdak value overwrites the
> >> sensor
> >> selection, the sensor selection overwrites the hdak value.
> >>
> >> In order to prevent such thing, use a regmap-like mechanism by reading the
> >> value before, set the corresponding bits and write the result.
> >>
> >> Signed-off-by: Daniel Lezcano
> >> ---
> >> drivers/thermal/hisi_thermal.c | 30 +-
> >> 1 file changed, 25 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/thermal/hisi_thermal.c
> >> b/drivers/thermal/hisi_thermal.c
> >> index d77a938..3e03908 100644
> >> --- a/drivers/thermal/hisi_thermal.c
> >> +++ b/drivers/thermal/hisi_thermal.c
> >> @@ -132,19 +132,39 @@ static inline void hisi_thermal_enable(void __iomem
> >> *addr, int value)
> >>writel(value, addr + TEMP0_EN);
> >> }
> >>
> >> -static inline void hisi_thermal_sensor_select(void __iomem *addr, int
> >> sensor)
> >> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
> >> {
> >> - writel((sensor << 12), addr + TEMP0_CFG);
> >> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> >> }
> >>
> >> -static inline int hisi_thermal_get_temperature(void __iomem *addr)
> >> +/*
> >> + * Temperature configuration register - Sensor selection
> >> + *
> >> + * Bits [19:12]
> >> + *
> >> + * 0x0: local sensor (default)
> >> + * 0x1: remote sensor 1 (ACPU cluster 1)
> >> + * 0x2: remote sensor 2 (ACPU cluster 0)
> >> + * 0x3: remote sensor 3 (G3D)
> >> + */
> >> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int
> >> sensor)
> >> {
> >> - return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> >> + writel(readl(addr + TEMP0_CFG) | (sensor << 12), addr + TEMP0_CFG);
> >
> > nitpick: maybe it's better to firstly clear related bits and then set
> > value?
>
> Sorry, I don't get the comment. Can you elaborate ?
Sure, here I am bit concern there the mixing old bits value and new
setting bits. My suggested code likes below:
u32 val;
val = readl(addr + TEMP0_CFG);
val &= ~0xF000;
val |= (sensor << 12);
writel(val, addr + TEMP0_CFG);
Thanks,
Leo Yan
Re: [PATCH] mm: kvfree the swap cluster info if the swap file is unsatisfactory
David Rientjes writes:
> On Thu, 31 Aug 2017, Darrick J. Wong wrote:
>
>> If initializing a small swap file fails because the swap file has a
>> problem (holes, etc.) then we need to free the cluster info as part of
>> cleanup. Unfortunately a previous patch changed the code to use
>> kvzalloc but did not change all the vfree calls to use kvfree.
>>
>
> Hopefully this can make it into 4.13.
>
> Fixes: 54f180d3c181 ("mm, swap: use kvzalloc to allocate some swap data
> structures")
> Cc: sta...@vger.kernel.org [4.12]
>
>> Found by running generic/357 from xfstests.
>>
>> Signed-off-by: Darrick J. Wong
>
> Acked-by: David Rientjes
>
> But I think there's also a memory leak and we need this on top of your
> fix:
>
>
> mm, swapfile: fix swapon frontswap_map memory leak on error
>
> Free frontswap_map if an error is encountered before enable_swap_info().
>
> Signed-off-by: David Rientjes
> ---
> mm/swapfile.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -3053,6 +3053,7 @@ SYSCALL_DEFINE2(swapon, const char __user *,
> specialfile, int, swap_flags)
> spin_unlock(&swap_lock);
> vfree(swap_map);
> kvfree(cluster_info);
> + kvfree(frontswap_map);
> if (swap_file) {
> if (inode && S_ISREG(inode->i_mode)) {
> inode_unlock(inode);
Yes. There is a memory leak.
Reviewed-by: "Huang, Ying"
Best Regards,
Huang, Ying
Re: [PATCH 00/15] Improve DVB documentation and reduce its gap
Hi Mauro, On 01.09.2017 11:32, Mauro Carvalho Chehab wrote: > Em Fri, 1 Sep 2017 10:40:28 +0200 > Honza Petrouš escreveu: > >> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab : >>> The DVB documentation was negligected for a long time, with >>> resulted on several gaps between the API description and its >>> documentation. >>> >>> I'm doing a new reading at the documentation. As result of it, >>> this series: >>> >>> - improves the introductory chapter, making it more generic; >>> - Do some adjustments at the frontend API, using kernel-doc >>> when possible. >>> - Remove unused APIs at DVB demux. I suspect that the drivers >>> implementing such APIs were either never merged upstream, >>> or the API itself were never used or was deprecated a long >>> time ago. In any case, it doesn't make any sense to carry >>> on APIs that aren't properly documented, nor are used on the >>> upstream Kernel. >>> >>> With this patch series, the gap between documentation and >>> code is solved for 3 DVB APIs: >>> >>> - Frontend API; >>> - Demux API; >>> - Net API. >>> >>> There is still a gap at the CA API that I'll try to address when I >>> have some time[1]. >>> >>> [1] There's a gap also on the legacy audio, video and OSD APIs, >>> but, as those are used only by a single very old deprecated >>> hardware (av7110), it is probably not worth the efforts. >>> av7110 cards may be old, but there are still users of these cards. For instance I'm watching TV received and decoded with such card in this moment. So what do you mean with "deprecated hardware"? >> I agree that av7110 is very very old piece of hw (but it is already >> in my hall of fame because of its Skystar 1 incarnation as >> first implementation of DVB in Linux) and it is sad that we still >> don't have at least one driver for any SoC with embedded DVB >> devices. > Yeah, av7110 made history. Please notice that this series doesn't > remove any API that it is used by it. All it removes are the APIs > that there's no Kernel driver using. > > Carry on APIs without client is usually a very bad idea, as nobody > could be certain about how to use it. It is even worse when such > APIs are not properly documented (with is the case here). > >> I understand that the main issue is that no any DVB-enabled >> SoC vendor is interested in upstreaming theirs code, but I still hope >> it will change in near future(*) > We have one driver for a SoC DVB hardware at: > drivers/media/platform/sti/c8sectpfe/ > > I guess it still doesn't cover the entire SoC, but this is a WiP. If I > remember well, at the midia part of the SoC, they started by submitting > the Remote Controller code. > >> Without having full-featured DVB device in vanilla, we surely don't >> get some parts of DVB API covered. I can imagine that when >> somebody comes with such full-featured device he wants to reinvent >> just removed bits. > Re-adding the removed bits is easy. However, the API defined for > av7110 is old and it is showing its age: it assumes a limited number > of possible inputs/outputs. Modern SoC has a lot more ways link the > audio/video IP blocks than what the API provides. On a modern SoC, > not only DVB is supported, but also analog inputs (to support things > like composite input), cameras, HDMI inputs and even analog TV. > All of them interconnected to a media ISP. The current FF API can't > represent such hardware. > > The best API to represent those pipelines that exist on SoC for > multimedia is the media controller, where all IP blocks and their > links (whatever they are) can be represented, if needed. > > The audio and video DVB API is also too limited: it hasn't > evolved since when it was added. For audio, the ALSA API > allows a way more control of the hardware; for video, the > V4L2 API nowadays has all the bits to control video decoding > and encoding. Both APIs provide support for audio and video > inputs commonly found on those devices. The real advantage of the DVB audio/video/osd API is the possibility of frame synchronous audio/video/overlay output for high-quality audio/video playback, maybe with picture-in-picture functionality. Especially audio synchronization is not easy when the audio format changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on HDMI output. While HDMI output hardware usually takes video frames and audio packets (and AVI info frames for audio/video format signalization) synchronously, V4L2 and ALSA rip these data blocks apart and push these through different pipelines with different buffering properties. This makes it very difficult for userspace applications. With the DVB API the hardware takes care of the synchronisation. > Also, nowadays, video decoding usually happens at the GPU on SoC. So, > in practice, a SoC FF would likely use the DRM subsystem to control the > video codecs. I think this is a common misunderstanding. Video is decoded on separate hardware blocks nowadays, not on a (3D-)GPU. GPU vendors
Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
Em Sun, 3 Sep 2017 22:05:23 +0200
Honza Petrouš escreveu:
> 1) #define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
>
>
> CA_SET_DESCR is used for feeding descrambler device
> with correct keys (called here "control words") what
> allows to get services unscrambled.
>
> The best docu is:
>
> "Digital Video Broadcasting (DVB);
> Support for use of the DVB Scrambling Algorithm version 3
> within digital broadcasting systems"
>
> Defined as DVB Document A125 and publicly
> available here:
>
> https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
>
>
> typedef struct ca_descr {
> unsigned int index;
> unsigned int parity;/* 0 == even, 1 == odd */
> unsigned char cw[8];
> } ca_descr_t;
>
> The 'index' is adress of the descrambler instance, as there exist
> limited number of them (retieved by CA_GET_DESCR_INFO).
Thanks for the info. If I understood well, the enclosed patch should
be documenting it.
Thanks,
Mauro
[PATCH] media: ca docs: document CA_SET_DESCR ioctl and structs
The av7110 driver uses CA_SET_DESCR to store the descrambler
control words at the CA descrambler slots.
Document it.
Thanks-to: Honza Petrouš
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst
b/Documentation/media/uapi/dvb/ca-set-descr.rst
index 9c484317d55c..a6c47205ffd8 100644
--- a/Documentation/media/uapi/dvb/ca-set-descr.rst
+++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
@@ -28,22 +28,11 @@ Arguments
``msg``
Pointer to struct :c:type:`ca_descr`.
-.. c:type:: ca_descr
-
-.. code-block:: c
-
-struct ca_descr {
- unsigned int index;
- unsigned int parity;
- unsigned char cw[8];
-};
-
-
Description
---
-.. note:: This ioctl is undocumented. Documentation is welcome.
-
+CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
+keys (refered as control words).
Return Value
diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
index f66ed53f4dc7..a62ddf0cebcd 100644
--- a/include/uapi/linux/dvb/ca.h
+++ b/include/uapi/linux/dvb/ca.h
@@ -109,9 +109,16 @@ struct ca_msg {
unsigned char msg[256];
};
+/**
+ * struct ca_descr - CA descrambler control words info
+ *
+ * @index: CA Descrambler slot
+ * @parity: control words parity, where 0 means even and 1 means odd
+ * @cw: CA Descrambler control words
+ */
struct ca_descr {
unsigned int index;
- unsigned int parity;/* 0 == even, 1 == odd */
+ unsigned int parity;
unsigned char cw[8];
};
Re: [PATCH 09/13] thermal/drivers/hisi: Remove costly sensor inspection
On Sat, Sep 02, 2017 at 03:10:29PM +0200, Daniel Lezcano wrote:
[...]
> On 02/09/2017 05:29, Leo Yan wrote:
> > On Wed, Aug 30, 2017 at 10:47:33AM +0200, Daniel Lezcano wrote:
> >> The sensor is all setup, bind, resetted, acked, etc... every single second.
> >>
> >> That was the way to workaround a problem with the interrupt bouncing again
> >> and
> >> again.
> >>
> >> With the following changes, we fix all in one:
> >>
> >> - Do the setup, one time, at probe time
> >>
> >> - Add the IRQF_ONESHOT, ack the interrupt in the threaded handler
> >>
> >> - Remove the interrupt handler
> >>
> >> - Set the correct value for the LAG register
> >>
> >> - Remove all the irq_enabled stuff in the code as the interruption
> >>handling is fixed
> >>
> >> - Remove the 3ms delay
> >>
> >> - Reorder the initialization routine to be in the right order
> >>
> >> It ends up to a nicer code and more efficient, the 3-5ms delay is removed
> >> from
> >> the get_temp() path.
> >>
> >> Signed-off-by: Daniel Lezcano
> >> ---
> >> drivers/thermal/hisi_thermal.c | 203
> >> +++--
> >> 1 file changed, 93 insertions(+), 110 deletions(-)
> >>
> >> diff --git a/drivers/thermal/hisi_thermal.c
> >> b/drivers/thermal/hisi_thermal.c
> >> index 3e03908..b038d8a 100644
> >> --- a/drivers/thermal/hisi_thermal.c
> >> +++ b/drivers/thermal/hisi_thermal.c
> >> @@ -39,6 +39,7 @@
> >> #define HISI_TEMP_BASE(-6)
> >> #define HISI_TEMP_RESET (10)
> >> #define HISI_TEMP_STEP(784)
> >> +#define HISI_TEMP_LAG (3500)
> >
> > So I am curious what's the reason to select 3.5'c for lag value? Is
> > this a heuristics result?
>
> Yes, it is. I tried 5°C but I find it too long. After several tests, I
> found 3.5°C looked fine.
>
> [ ... ]
>
> >> + * A very short lag can lead to an interrupt storm, a long lag
> >> + * increase the latency to react to the temperature changes. In our
> >> + * case, that is not really a problem as we are polling the
> >> + * temperature.
> >
> > So here means if we set a long lag value and the interrupt is delayed,
> > sometimes we even don't receive the interrupt; but this is acceptable
> > due we are polling the temperature so we still can get the updated
> > temperature value, right?
> No, what I meant is if the hysteresis is too large, eg. 45 - 65, then
> the interrupt will come after the temperature goes below 45 and that may
> take a long time, especially if the temperature is fluctuating between
> the two hysteresis values.
>
> The only setup preventing an interrupt to happen is when crossing the
> low value hysteresis is not possible in practical. For example, the
> temperature of the SoC is ~44°C at idle time. If we set the threshold to
> 65°C and the lag to the max 24°C, the interrupt will raised when we go
> below 41°C and that situation can't happen.
>
> In the current situation, the interrupt is only used to raise an alarm.
Thanks for the explanation, Ionela (have Cced.) reminded me the
interrupt for 'alarm on' is fatal, if we use polling method then the
delay can be 1000ms, but with interrupt to alarm we can handle the
temperature rasing immediately.
> The get temperature is resulting from a polling, so the delay between
> the alarm on/off is not issue for now.
Understood.
> >> + *
> >> + * [0:4] : lag register
> >> + *
> >> + * The temperature is coded in steps, cf. HISI_TEMP_STEP.
> >> + *
> >> + * Min : 0x00 : 0.0 °C
> >> + * Max : 0x1F : 24.3 °C
> >> + *
> >> + * The 'value' parameter is in milliCelsius.
> >> + */
> >> static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> >> {
> >> - writel(value, addr + TEMP0_LAG);
> >> + writel((value / HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
> >> }
>
>
> [ ... ]
>
> >> - thermal_zone_device_update(data->sensors.tzd,
> >> - THERMAL_EVENT_UNSPECIFIED);
> >> + } else if (temp < sensor->thres_temp) {
> >> + dev_crit(&data->pdev->dev, "THERMAL ALARM stopped: %d < %d\n",
> >> + temp, sensor->thres_temp);
> >> + }
> >
> > For temperature increasing and decreasing both cases, can always call
> > thermal_zone_device_update()?
>
> That is something I asked myself but I finally decided to not change the
> current behavior and let that be added in a separate patch.
This is fine.
Thanks,
Leo Yan
[GIT PULL] hwmon updates for v4.14
Hi Linus, Please pull hwmon updates for Linux v4.14 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.14 Thanks, Guenter -- The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e: Linux 4.13-rc4 (2017-08-06 18:44:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus-v4.14 for you to fetch changes up to 7074d0a92758603369655ef5d4f49e6caaae0b4e: hwmon: (ltq-cputemp) add cpu temp sensor driver (2017-09-01 07:24:14 -0700) hwmon updates for v4.14 - New driver for Lantiq CPU temperature sensor - New driver for IBM CFF power supply - New PMBus driver for TPS53679 - Add support for LM5066I lm25066 PMBus driver - Add support for Intel VID protocol VR13 to PMBus drivers - Add support for CAT34TS02C, GT30TS00, GT34TS02, and CAT34TS04 to jc42 driver - Cleanup and minor improvements in several drivers Anton Vasilyev (1): hwmon: (stts751) buffer overrun on wrong chip configuration Arnd Bergmann (1): hwmon: (aspeed-pwm) add THERMAL dependency Arvind Yadav (6): hwmon: constify attribute_group structures. hwmon: (nct7802) constify attribute_group structures. hwmon: (adc128d818) constify attribute_group structures. hwmon: (adt7475) constify attribute_group structures. hwmon: (i5k_amb) constify pci_device_id hwmon: (ftsteutates) constify i2c_device_id Colin Ian King (1): hwmon: (asc7621) make several arrays static const Edward A. James (7): hwmon: (pmbus): Switch status registers to 16 bit hwmon: (pmbus): Access word data for STATUS_WORD hwmon: (pmbus): Add generic alarm bit for iin and pin hwmon: (pmbus) Add debugfs for status registers dt-bindings: hwmon: Document the IBM CCF power supply version 1 hwmon: (pmbus) Add IBM Common Form Factor (CFF) power supply driver Documentation: hwmon: Document the IBM CFF power supply Florian Eckert (2): hwmon: (ltq-cputemp) add devicetree bindings documentation hwmon: (ltq-cputemp) add cpu temp sensor driver Guenter Roeck (3): hwmon: (jc42) Add support for GT30TS00, GT34TS02, and CAT34TS04 hwmon: (jc42) Add support for CAT34TS02C Merge remote-tracking branch 'lee/ib-mfd-hwmon-4.14' into hwmon-next Julia Lawall (2): hwmon: (core) constify thermal_zone_of_device_ops structures hwmon: (scpi) constify thermal_zone_of_device_ops structures Maciej S. Szmigiero (2): hwmon: (it87) Split out chip registers setting code on probe path hwmon: (it87) Reapply probe path chip registers settings after resume Mykola Kostenok (2): Documentation: dt-bindings: aspeed-pwm-tacho cooling device. hwmon: (aspeed-pwm-tacho) cooling device support. Rob Herring (1): hwmon: (ads1015) Convert to using %pOF instead of full_name Sebastian Reichel (4): mfd: da9052: Add register details for TSI hwmon: da9052: Replace S_IRUGO with 0444 mfd: da9052: Make touchscreen registration optional hwmon: da9052: Add support for TSI channel Thilo Cestonaro (1): hwmon: (ftsteutates) Fix clearing alarm sysfs entries Vadim Pasternak (2): hwmon: (pmbus) Add support for Intel VID protocol VR13 hwmon: (pmbus) Add support for Texas Instruments tps53679 device Xo Wang (2): hwmon: (pmbus/lm25066) Offset coefficient depends on CL hwmon: (pmbus/lm25066) Add support for TI LM5066I .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 9 + .../devicetree/bindings/hwmon/ibm,cffps1.txt | 21 ++ .../devicetree/bindings/hwmon/ltq-cputemp.txt | 10 + Documentation/hwmon/ftsteutates| 4 + Documentation/hwmon/ibm-cffps | 54 Documentation/hwmon/lm25066| 9 +- drivers/hwmon/Kconfig | 8 + drivers/hwmon/Makefile | 1 + drivers/hwmon/adc128d818.c | 2 +- drivers/hwmon/ads1015.c| 14 +- drivers/hwmon/adt7475.c| 16 +- drivers/hwmon/asc7621.c| 4 +- drivers/hwmon/aspeed-pwm-tacho.c | 116 +++- drivers/hwmon/da9052-hwmon.c | 285 ++-- drivers/hwmon/ftsteutates.c| 4 +- drivers/hwmon/hwmon.c | 4 +- drivers/hwmon/i5k_amb.c| 2 +- drivers/hwmon/it87.c | 214 +++ drivers/hwmon/jc42.c | 19 ++ drivers/hwmon/ltq-cputemp.c| 163 drivers/hwmon/nct7802.c| 10 +- drivers/hwmon
Re: [PATCH 08/10] dmaengine: sun6i: Add support for Allwinner A64 and compatibles
On Montag, 4. September 2017 01:37:58 CEST André Przywara wrote:
> > @@ -1090,6 +1101,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dma_match);
> >
> > static int sun6i_dma_probe(struct platform_device *pdev)
> > {
> >
> > const struct of_device_id *device;
> >
> > + struct device_node *np = pdev->dev.of_node;
>
> Is this some rebase/split artefact?
>
> Cheers,
> Andre.
>
Yes, that one should be in patch 7/10 ...
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
Re: [PATCH 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree
On Montag, 4. September 2017 01:44:54 CEST André Przywara wrote:
> Hi,
>
> On 03/09/17 23:40, Stefan Brüns wrote:
> > To avoid introduction of a new compatible for each small SoC/DMA
> > controller
> > variation, move the definition of the channel count to the devicetree.
> >
> > The number of vchans is no longer explicit, but limited by the highest
> > port/DMA request number. The result is a slight overallocation for SoCs
> > with a sparse port mapping.
> >
> > Signed-off-by: Stefan Brüns
> > ---
> >
> > drivers/dma/sun6i-dma.c | 35 ++-
> > 1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > index c69dadb853d2..bd4c2e4a759b 100644
> > --- a/drivers/dma/sun6i-dma.c
> > +++ b/drivers/dma/sun6i-dma.c
> > @@ -42,6 +42,9 @@
> >
> > #define DMA_STAT 0x30
> >
> > +/* Offset between DMA_IRQ_EN and DMA_IRQ_STAT limits number of channels
> > */
> > +#define DMA_MAX_CHANNELS (DMA_IRQ_CHAN_NR * 0x10 / 4)
> > +
> >
> > /*
> >
> > * sun8i specific registers
> > */
> >
> > @@ -65,7 +68,8 @@
> >
> > #define DMA_CHAN_LLI_ADDR 0x08
> >
> > #define DMA_CHAN_CUR_CFG 0x0c
> >
> > -#define DMA_CHAN_CFG_SRC_DRQ(x)((x) & 0x1f)
> > +#define DMA_CHAN_MAX_DRQ 0x1f
> > +#define DMA_CHAN_CFG_SRC_DRQ(x)((x) & DMA_CHAN_MAX_DRQ)
> >
> > #define DMA_CHAN_CFG_SRC_IO_MODE BIT(5)
> > #define DMA_CHAN_CFG_SRC_LINEAR_MODE (0 << 5)
> > #define DMA_CHAN_CFG_SRC_BURST_A31(x) (((x) & 0x3) << 7)
> >
> > @@ -1173,6 +1177,35 @@ static int sun6i_dma_probe(struct platform_device
> > *pdev)>
> > sdc->num_vchans = sdc->cfg->nr_max_vchans;
> > sdc->max_request = sdc->cfg->nr_max_requests;
> >
> > + ret = of_property_read_u32(np, "dma-channels", &sdc->num_pchans);
> > + if (ret && !sdc->num_pchans) {
> > + dev_err(&pdev->dev, "Can't get dma-channels.\n");
> > + return ret;
> > + }
> > +
> > + if (sdc->num_pchans > DMA_MAX_CHANNELS) {
> > + dev_err(&pdev->dev, "Number of dma-channels out of range.\n");
> > + return -EINVAL;
> > + }
> > +
> > + ret = of_property_read_u32(np, "dma-requests", &sdc->max_request);
> > + if (ret && !sdc->max_request) {
> > + dev_info(&pdev->dev, "Missing dma-requests, using %u.\n",
> > +DMA_CHAN_MAX_DRQ);
>
> Mmmh, is this mapping of "!sdc->max_request" -> DMA_CHAN_MAX_DRQ
> implemented somewhere else? Or is it just missing here:
> sdc->max_request = DMA_CHAN_MAX_DRQ;
Well spotted, that assignment is actually missing.
With this line added, your comment for patch 8/10 should also be addressed
(regarding the default value).
> Otherwise this is looking good, thanks for picking up the DT property
> approach!
>
> Cheers,
> Andre.
>
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
linux-next: manual merge of the s390 tree with Linus' tree
Hi all,
Today's linux-next merge of the s390 tree got a conflict in:
arch/s390/include/asm/mmu_context.h
between commit:
0b89ede62963 ("s390/mm: fork vs. 5 level page tabel")
from Linus' tree and commit:
f1c1174fa099 ("s390/mm: use new mm defines instead of magic values")
from the s390 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/s390/include/asm/mmu_context.h
index 24bc41622a98,31eea6261488..
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@@ -44,12 -45,7 +45,12 @@@ static inline int init_new_context(stru
mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
_ASCE_USER_BITS | _ASCE_TYPE_REGION3;
break;
+ case -PAGE_SIZE:
+ /* forked 5-level task, set new asce with new_mm->pgd */
+ mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
+ _ASCE_USER_BITS | _ASCE_TYPE_REGION1;
+ break;
- case 1UL << 53:
+ case _REGION1_SIZE:
/* forked 4-level task, set new asce with new mm->pgd */
mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
_ASCE_USER_BITS | _ASCE_TYPE_REGION2;
Re: [PATCH 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree
Hi,
On 03/09/17 23:40, Stefan Brüns wrote:
> To avoid introduction of a new compatible for each small SoC/DMA controller
> variation, move the definition of the channel count to the devicetree.
>
> The number of vchans is no longer explicit, but limited by the highest
> port/DMA request number. The result is a slight overallocation for SoCs
> with a sparse port mapping.
>
> Signed-off-by: Stefan Brüns
> ---
> drivers/dma/sun6i-dma.c | 35 ++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index c69dadb853d2..bd4c2e4a759b 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -42,6 +42,9 @@
>
> #define DMA_STAT 0x30
>
> +/* Offset between DMA_IRQ_EN and DMA_IRQ_STAT limits number of channels */
> +#define DMA_MAX_CHANNELS (DMA_IRQ_CHAN_NR * 0x10 / 4)
> +
> /*
> * sun8i specific registers
> */
> @@ -65,7 +68,8 @@
> #define DMA_CHAN_LLI_ADDR0x08
>
> #define DMA_CHAN_CUR_CFG 0x0c
> -#define DMA_CHAN_CFG_SRC_DRQ(x) ((x) & 0x1f)
> +#define DMA_CHAN_MAX_DRQ 0x1f
> +#define DMA_CHAN_CFG_SRC_DRQ(x) ((x) & DMA_CHAN_MAX_DRQ)
> #define DMA_CHAN_CFG_SRC_IO_MODE BIT(5)
> #define DMA_CHAN_CFG_SRC_LINEAR_MODE (0 << 5)
> #define DMA_CHAN_CFG_SRC_BURST_A31(x)(((x) & 0x3) << 7)
> @@ -1173,6 +1177,35 @@ static int sun6i_dma_probe(struct platform_device
> *pdev)
> sdc->num_vchans = sdc->cfg->nr_max_vchans;
> sdc->max_request = sdc->cfg->nr_max_requests;
>
> + ret = of_property_read_u32(np, "dma-channels", &sdc->num_pchans);
> + if (ret && !sdc->num_pchans) {
> + dev_err(&pdev->dev, "Can't get dma-channels.\n");
> + return ret;
> + }
> +
> + if (sdc->num_pchans > DMA_MAX_CHANNELS) {
> + dev_err(&pdev->dev, "Number of dma-channels out of range.\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32(np, "dma-requests", &sdc->max_request);
> + if (ret && !sdc->max_request) {
> + dev_info(&pdev->dev, "Missing dma-requests, using %u.\n",
> + DMA_CHAN_MAX_DRQ);
Mmmh, is this mapping of "!sdc->max_request" -> DMA_CHAN_MAX_DRQ
implemented somewhere else? Or is it just missing here:
sdc->max_request = DMA_CHAN_MAX_DRQ;
Otherwise this is looking good, thanks for picking up the DT property
approach!
Cheers,
Andre.
> + }
> +
> + if (sdc->max_request > DMA_CHAN_MAX_DRQ) {
> + dev_err(&pdev->dev, "Value of dma-requests out of range.\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * If the number of vchans is not specified, derive it from the
> + * highest port number, at most one channel per port and direction.
> + */
> + if (!sdc->num_vchans)
> + sdc->num_vchans = 2 * (sdc->max_request + 1);
> +
> sdc->pchans = devm_kcalloc(&pdev->dev, sdc->num_pchans,
> sizeof(struct sun6i_pchan), GFP_KERNEL);
> if (!sdc->pchans)
>
Re: [PATCH 08/10] dmaengine: sun6i: Add support for Allwinner A64 and compatibles
Hi,
On 03/09/17 23:40, Stefan Brüns wrote:
> The A64 SoC has the same dma engine as the H3 (sun8i), with a
> reduced amount of physical channels. To allow future reuse of the
> compatible, leave the channel count etc. in the config data blank
> and retrieve it from the devicetree.
>
> Signed-off-by: Stefan Brüns
> ---
> drivers/dma/sun6i-dma.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index bd4c2e4a759b..4fae7ffad549 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -1076,6 +1076,16 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> .nr_max_vchans = 34,
> .dmac_variant= DMAC_VARIANT_H3,
> };
> +
> +/*
> + * The A64 binding uses the number of dma channels from the
> + * device tree node.
> + */
> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> + .nr_max_channels = 0,
> + .nr_max_requests = 0,
But this does not work with the "dma-requests" property being optional
according to the binding spec? Either we put the value for the A64 in
here (and thus force the R40 and others to specify this in the DT) or we
map the "0" from struct config to DMA_CHAN_MAX_DRQ in the probe function.
> + .nr_max_vchans = 0,
> + .dmac_variant= DMAC_VARIANT_H3,
> };
>
> static const struct of_device_id sun6i_dma_match[] = {
> @@ -1083,6 +1093,7 @@ static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
> { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg
> },
> { .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
> + { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg
> },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
> @@ -1090,6 +1101,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dma_match);
> static int sun6i_dma_probe(struct platform_device *pdev)
> {
> const struct of_device_id *device;
> + struct device_node *np = pdev->dev.of_node;
Is this some rebase/split artefact?
Cheers,
Andre.
> struct sun6i_dma_dev *sdc;
> struct resource *res;
> int ret, i;
>
Re: [PATCH 0/7] EDAC, mce_amd: Issue decoded MCE through the tracepoint
On Wed, Aug 30, 2017 at 07:30:58PM -0400, Steven Rostedt wrote:
> On Wed, 30 Aug 2017 14:47:19 -0700
> mark gross wrote:
>
>
> > > struct dentry *ras_debugfs_dir;
> > >
> > > static atomic_t trace_count = ATOMIC_INIT(0);
> > > @@ -12,7 +14,9 @@ EXPORT_SYMBOL_GPL(ras_userspace_consumers);
> > >
> > > static int trace_show(struct seq_file *m, void *v)
> > > {
> > > - return atomic_read(&trace_count);
> > > + seq_printf(m, "readers:%d\n", atomic_read(&trace_count));
> > > + seq_printf(m, "has decoder:%d\n", mca_cfg.has_decoder);
> >
> > do you want to worry about this debugfs interfaces as ABI?
>
> It's the old, if a tree falls in the forest issue. If you break the ABI
> but nobody is around to notice, did it really break?
perhaps, but what I was trying to point out was: "multi line debugFS printf's
like this are very easy to change to append other information and you might
want to worry about the ABI implications that could happen in the future."
--mark
>
> > debugfs changes have bitten me on one specific OS in irritating ways.
> >
> > I'm not sure what the word is for debugfs interfaces as ABI these days so
> > this
> > feedback may be not so useful.
>
> I discussed this with Boris before he sent it out. The current code is
> actually broken. The trace_show() looks to be just a stub for a hack to
> have userspace tell the kernel it's reading something (the
> trace_count). The trace_show() function here returns the trace_count,
> which is just wrong. The seq_file show function is suppose to return
> less than zero on error, zero on success, or greater than zero if the
> show is suppose to skip the current field but not error out. This
> trace_show() function doesn't actually show anything. If you cat the
> file, it will be blank. Returning zero or greater than zero has the
> same effect. Which is nothing.
>
> -- Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] dmaengine: sun6i: Correct setting of clock autogating register for A83T/H3
On 03/09/17 23:40, Stefan Brüns wrote:
> The H83T uses a compatible string different from the A23, but requires
A83T
> the same clock autogating register setting.
>
> The H3 also requires setting the clock autogating register, but has
> the register at a different offset.
>
> Some currently available SoCs not yet supported by the sun6i-dma driver
> will require new compatible strings. These SoCs either follow the A23
> register model (e.g. V3s) or the H3 register model (A64, R40), so a new
> variable is added to the config struct to group SoCs with common register
> models.
As mentioned in that other mail, using the actual properties as names
here instead of grouping them to rather arbitrary groups seems more
useful and future-proof to me and should be easier to read.
In this case this should simplify this patch:
sun8i_a23_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 24,
.nr_max_vchans = 37,
+ .auto_clock_gate = 0x20,
...
- if (of_device_is_compatible(pdev->dev.of_node,
- "allwinner,sun8i-a23-dma"))
- writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
+ if (sdc->cfg->auto_clock_gate)
+ writel(SUN8I_DMA_GATE_ENABLE,
+ sdc->base + sdc->cfg->auto_clock_gate);
> Signed-off-by: Stefan Brüns
> ---
> drivers/dma/sun6i-dma.c | 34 +++---
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a2358780ab2c..1d9b3be30d22 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -48,6 +48,9 @@
> #define SUN8I_DMA_GATE 0x20
> #define SUN8I_DMA_GATE_ENABLE0x4
>
> +#define SUNXI_H3_SECURITE_REG0x20
typo? SUNXI_H3_SECURITY_REG ?
Cheers,
Andre.
> +#define SUNXI_H3_DMA_GATE0x28
> +#define SUNXI_H3_DMA_GATE_ENABLE 0x4
> /*
> * Channels specific registers
> */
> @@ -90,6 +93,21 @@
> #define NORMAL_WAIT 8
> #define DRQ_SDRAM1
>
> +/*
> + * DMA Controller generations
> + *
> + * Newer SoC generations changed or added some register definitions:
> + * - A23 added a clock gate register
> + * - H3 has a different offset for the clock gating register,
> + * the burst length field has a different offset in the channel
> + * configuration register, also additional burst lengths/widths.
> + */
> +enum dmac_variant {
> + DMAC_VARIANT_A31,
> + DMAC_VARIANT_A23,
> + DMAC_VARIANT_H3,
> +};
> +
> /*
> * Hardware channels / ports representation
> *
> @@ -101,6 +119,7 @@ struct sun6i_dma_config {
> u32 nr_max_channels;
> u32 nr_max_requests;
> u32 nr_max_vchans;
> + enum dmac_variant dmac_variant;
> };
>
> /*
> @@ -998,6 +1017,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
> .nr_max_channels = 16,
> .nr_max_requests = 30,
> .nr_max_vchans = 53,
> + .dmac_variant= DMAC_VARIANT_A31,
> };
>
> /*
> @@ -1009,23 +1029,29 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
> .nr_max_channels = 8,
> .nr_max_requests = 24,
> .nr_max_vchans = 37,
> + .dmac_variant= DMAC_VARIANT_A23,
> };
>
> static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> .nr_max_channels = 8,
> .nr_max_requests = 28,
> .nr_max_vchans = 39,
> + .dmac_variant= DMAC_VARIANT_A23,
> };
>
> /*
> * The H3 has 12 physical channels, a maximum DRQ port id of 27,
> * and a total of 34 usable source and destination endpoints.
> + * It also supports additional burst lengths and bus widths,
> + * and the burst length fields have different offsets.
> */
>
> static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> .nr_max_channels = 12,
> .nr_max_requests = 27,
> .nr_max_vchans = 34,
> + .dmac_variant= DMAC_VARIANT_H3,
> +};
> };
>
> static const struct of_device_id sun6i_dma_match[] = {
> @@ -1177,11 +1203,13 @@ static int sun6i_dma_probe(struct platform_device
> *pdev)
> /*
>* sun8i variant requires us to toggle a dma gating register,
>* as seen in Allwinner's SDK. This register is not documented
> - * in the A23 user manual.
> + * in the A23 user manual, but appears in e.g. the H83T manual.
> + * For the H3, H5 and A64, the register has a different location
>*/
> - if (of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun8i-a23-dma"))
> + if (sdc->cfg->dmac_variant == DMAC_VARIANT_A23)
> writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
> + else if (sdc->cfg->dmac_variant == DMAC_VARIANT_H3)
> + writel(SUNXI_H3_DMA_GATE_ENABLE, sdc->base + SUNXI_H3_DMA_GATE);
>
> return 0;
>
>
Re: [PATCH 3/3] dmaengine: sun6i: Add support for Allwinner A64
On 02/09/17 03:02, Stefan Bruens wrote:
> On Samstag, 2. September 2017 00:32:50 CEST André Przywara wrote:
>> Hi,
>>
>> On 01/09/17 02:19, Stefan Bruens wrote:
>>> On Freitag, 1. September 2017 02:31:35 CEST Andre Przywara wrote:
Hi,
On 31/08/17 00:36, Stefan Brüns wrote:
> The A64 SoC has the same dma engine as the H3 (sun8i), with a
> reduced amount of physical channels. Add the proper config data
> and compatible string to support it.
...
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 5f4eee4513e5..6a17c5d63582 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -1068,6 +1068,12 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg =
> {
>
> .nr_max_vchans = 34,
> .dmac_variant= DMAC_VARIANT_H3,
>
> };
>
> +
> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> + .nr_max_channels = 8,
> + .nr_max_requests = 27,
> + .nr_max_vchans = 38,
> + .dmac_variant= DMAC_VARIANT_H3,
>
> };
>
> [...]
>>> There are also the incompatibilities in the "DMA channel configuration
>>> register" (burst length; burst width; burst length field offset).
>>>
>>> We can either have 3 different compatible strings, or another property for
>>> the register model.
>>
>> The latter is usually frowned upon, using separate compatible strings
>> for each group of SoCs is the way to go here.
>
> Just for clarification, I was not talking about a property in the devicetree,
> but about a struct member in the config data, i.e. the .dmac_variant above.
Ah, I see. I was indeed talking about device tree nodes.
So in this case I would lean towards mapping the actual properties to
member names in struct sun6i_dma_config, in this case something like:
.auto_clock_gate = 0x28;
.max_burst_width = 16;
This looks more flexible to me and avoids hard to read code where
property A is used in SoC X and Y, but property B in SoC X and Z, for
instance.
In the auto clock gate case this would result in an easy-to-read:
writel(SUN8I_DMA_GATE_ENABLE,
sdc->base + sdc->cfg->auto_clock_gate);
(possibly guarded somehow to catch that A31 case)
Sorry for the delay in this answer, I see that you kept the
DMAC_VARIANT_ style for your new post, and the end result doesn't look
too bad. But maybe still changing this is not too hard now that you have
more fine grained patches?
Cheers,
Andre.
Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory
On Sunday, September 3, 2017 4:31:23 PM CEST Chao Fan wrote: > KASLR should choose the memory region of immovable node to extract kernel. > So get ACPI SRAT table and store the memory region of movable node which > kaslr shold avoid. Please elaborate. This is far too little information on what problem you are trying to address and why you are trying to address it in this particular way. Thanks, Rafael
[PATCH 03/10] dmaengine: sun6i: Restructure code to allow extension for new SoCs
The current code mixes three distinct operations when transforming
the slave config to register settings:
1. special handling of DMA_SLAVE_BUSWIDTH_UNDEFINED, maxburst == 0
2. range checking
3. conversion of raw to register values
As the range checks depend on the specific SoC, move these out of the
conversion to distinct operations.
Signed-off-by: Stefan Brüns
---
drivers/dma/sun6i-dma.c | 58 +
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index f1a139f0102f..c5644bd0f91a 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -185,6 +185,8 @@ struct sun6i_dma_dev {
struct sun6i_pchan *pchans;
struct sun6i_vchan *vchans;
const struct sun6i_dma_config *cfg;
+ u32 src_burst_lengths;
+ u32 dst_burst_lengths;
};
static struct device *chan2dev(struct dma_chan *chan)
@@ -270,10 +272,6 @@ static inline s8 convert_burst(u32 maxburst)
static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
{
- if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
- (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
- return -EINVAL;
-
return addr_width >> 1;
}
@@ -520,41 +518,43 @@ static int set_config(struct sun6i_dma_dev *sdev,
enum dma_transfer_direction direction,
u32 *p_cfg)
{
+ enum dma_slave_buswidth src_addr_width, dst_addr_width;
+ u32 src_maxburst, dst_maxburst;
s8 src_width, dst_width, src_burst, dst_burst;
+ src_addr_width = sconfig->src_addr_width;
+ dst_addr_width = sconfig->dst_addr_width;
+ src_maxburst = sconfig->src_maxburst;
+ dst_maxburst = sconfig->dst_maxburst;
+
switch (direction) {
case DMA_MEM_TO_DEV:
- src_burst = convert_burst(sconfig->src_maxburst ?
- sconfig->src_maxburst : 8);
- src_width = convert_buswidth(sconfig->src_addr_width !=
- DMA_SLAVE_BUSWIDTH_UNDEFINED ?
- sconfig->src_addr_width :
- DMA_SLAVE_BUSWIDTH_4_BYTES);
- dst_burst = convert_burst(sconfig->dst_maxburst);
- dst_width = convert_buswidth(sconfig->dst_addr_width);
+ if (src_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
+ src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ src_maxburst = src_maxburst ? src_maxburst : 8;
break;
case DMA_DEV_TO_MEM:
- src_burst = convert_burst(sconfig->src_maxburst);
- src_width = convert_buswidth(sconfig->src_addr_width);
- dst_burst = convert_burst(sconfig->dst_maxburst ?
- sconfig->dst_maxburst : 8);
- dst_width = convert_buswidth(sconfig->dst_addr_width !=
- DMA_SLAVE_BUSWIDTH_UNDEFINED ?
- sconfig->dst_addr_width :
- DMA_SLAVE_BUSWIDTH_4_BYTES);
+ if (dst_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
+ dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ dst_maxburst = dst_maxburst ? dst_maxburst : 8;
break;
default:
return -EINVAL;
}
- if (src_burst < 0)
- return src_burst;
- if (src_width < 0)
- return src_width;
- if (dst_burst < 0)
- return dst_burst;
- if (dst_width < 0)
- return dst_width;
+ if (!(BIT(src_addr_width) & sdev->slave.src_addr_widths))
+ return -EINVAL;
+ if (!(BIT(dst_addr_width) & sdev->slave.dst_addr_widths))
+ return -EINVAL;
+ if (!(BIT(src_maxburst) & sdev->src_burst_lengths))
+ return -EINVAL;
+ if (!(BIT(dst_maxburst) & sdev->dst_burst_lengths))
+ return -EINVAL;
+
+ src_width = convert_buswidth(src_addr_width);
+ dst_width = convert_buswidth(dst_addr_width);
+ dst_burst = convert_burst(dst_maxburst);
+ src_burst = convert_burst(src_maxburst);
*p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |
DMA_CHAN_CFG_DST_WIDTH(dst_width);
@@ -1150,6 +1150,8 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->slave.dst_addr_widths =
BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+ sdc->src_burst_lengths = BIT(1) | BIT(8);
+ sdc->dst_burst_lengths = BIT(1) | BIT(8);
sdc->slave.directions = BIT(DMA_D
[PATCH 01/10] dmaengine: sun6i: Correct setting of clock autogating register for A83T/H3
The H83T uses a compatible string different from the A23, but requires
the same clock autogating register setting.
The H3 also requires setting the clock autogating register, but has
the register at a different offset.
Some currently available SoCs not yet supported by the sun6i-dma driver
will require new compatible strings. These SoCs either follow the A23
register model (e.g. V3s) or the H3 register model (A64, R40), so a new
variable is added to the config struct to group SoCs with common register
models.
Signed-off-by: Stefan Brüns
---
drivers/dma/sun6i-dma.c | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index a2358780ab2c..1d9b3be30d22 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -48,6 +48,9 @@
#define SUN8I_DMA_GATE 0x20
#define SUN8I_DMA_GATE_ENABLE 0x4
+#define SUNXI_H3_SECURITE_REG 0x20
+#define SUNXI_H3_DMA_GATE 0x28
+#define SUNXI_H3_DMA_GATE_ENABLE 0x4
/*
* Channels specific registers
*/
@@ -90,6 +93,21 @@
#define NORMAL_WAIT8
#define DRQ_SDRAM 1
+/*
+ * DMA Controller generations
+ *
+ * Newer SoC generations changed or added some register definitions:
+ * - A23 added a clock gate register
+ * - H3 has a different offset for the clock gating register,
+ * the burst length field has a different offset in the channel
+ * configuration register, also additional burst lengths/widths.
+ */
+enum dmac_variant {
+ DMAC_VARIANT_A31,
+ DMAC_VARIANT_A23,
+ DMAC_VARIANT_H3,
+};
+
/*
* Hardware channels / ports representation
*
@@ -101,6 +119,7 @@ struct sun6i_dma_config {
u32 nr_max_channels;
u32 nr_max_requests;
u32 nr_max_vchans;
+ enum dmac_variant dmac_variant;
};
/*
@@ -998,6 +1017,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_channels = 16,
.nr_max_requests = 30,
.nr_max_vchans = 53,
+ .dmac_variant= DMAC_VARIANT_A31,
};
/*
@@ -1009,23 +1029,29 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 24,
.nr_max_vchans = 37,
+ .dmac_variant= DMAC_VARIANT_A23,
};
static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 28,
.nr_max_vchans = 39,
+ .dmac_variant= DMAC_VARIANT_A23,
};
/*
* The H3 has 12 physical channels, a maximum DRQ port id of 27,
* and a total of 34 usable source and destination endpoints.
+ * It also supports additional burst lengths and bus widths,
+ * and the burst length fields have different offsets.
*/
static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_channels = 12,
.nr_max_requests = 27,
.nr_max_vchans = 34,
+ .dmac_variant= DMAC_VARIANT_H3,
+};
};
static const struct of_device_id sun6i_dma_match[] = {
@@ -1177,11 +1203,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)
/*
* sun8i variant requires us to toggle a dma gating register,
* as seen in Allwinner's SDK. This register is not documented
-* in the A23 user manual.
+* in the A23 user manual, but appears in e.g. the H83T manual.
+* For the H3, H5 and A64, the register has a different location
*/
- if (of_device_is_compatible(pdev->dev.of_node,
- "allwinner,sun8i-a23-dma"))
+ if (sdc->cfg->dmac_variant == DMAC_VARIANT_A23)
writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
+ else if (sdc->cfg->dmac_variant == DMAC_VARIANT_H3)
+ writel(SUNXI_H3_DMA_GATE_ENABLE, sdc->base + SUNXI_H3_DMA_GATE);
return 0;
--
2.14.1
[PATCH 00/10] dmaengine: sun6i: Fixes for H3/A83T, enable A64
Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T
(sun8i) variant") and commit f008db8c00c1 ("dmaengine: sun6i: Add support for
Allwinner H3 (sun8i) variant") added support for the A83T resp. H3, but missed
some differences between the original A31 and A83T/H3.
The first patch add a variable to group different SoC generations, i.e. A31,
A23+A83T, H3+later, and uses it to for the correct clock autogating setting.
The second and fourth patches reuse this variable to reflect changes in the
channel config register, i.e. different field offsets, new burst widths/lengths.
The third patch restructures some code required for the fourth patch.
Patch 5 restructures the code to decouple some controller details (e.g. channel
count) from the compatible string/the config.
Patches 6, 7 and 8 introduce and use the "dma-chans" property for the A64.
Although
register compatible to the H3, the channel count differs and thus it requires a
new compatible. To avoid introduction of new compatibles for each minor
variation,
anything but the register model is moved to devicetree properties. There
is at least one SoC (R40) which can then reuse the A64 compatible, the same
would have worked for A83T+V3s.
Patches 9 and 10 add the DMA controller node to the devicetree and add the DMA
controller reference to the SPI nodes.
This patch series could be called v2, but the patches were split and
significantly
restructured, thus listing changes individually is not to meaningful.
Stefan Brüns (10):
dmaengine: sun6i: Correct setting of clock autogating register for
A83T/H3
dmaengine: sun6i: Correct burst length field offsets for H3
dmaengine: sun6i: Restructure code to allow extension for new SoCs
dmaengine: sun6i: Enable additional burst lengths/widths on H3
dmaengine: sun6i: Move number of pchans/vchans/request to device
struct
arm64: allwinner: a64: Add devicetree binding for DMA controller
dmaengine: sun6i: Retrieve channel count/max request from devicetree
dmaengine: sun6i: Add support for Allwinner A64 and compatibles
arm64: allwinner: a64: Add device node for DMA controller
arm64: allwinner: a64: add dma controller references to spi nodes
.../devicetree/bindings/dma/sun6i-dma.txt | 26 +++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 15 ++
drivers/dma/sun6i-dma.c| 207 -
3 files changed, 197 insertions(+), 51 deletions(-)
--
2.14.1
