[git pull] drm fixes

[Dave Airlie]

Hi Linus,

been a bit slow gathering these,

drm/mst: one mutex leak in a fail path
radeon: two oops fixes, one dpm fix
i915: one messy set of fixes, where we revert the original fix,
and pull back the proper set of fixes from -next on top.
nouveau: one fix for an illegal buffer placement.

Doesn't look too bad, hopefully shouldn't be too much more.

Dave.

The following changes since commit 1099f86044111e9a7807f09523e42d4c9d0fb781:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-10-19 
09:55:40 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to c50f13f911b90a722308bffbf26187ff3890aa1e:

  Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2015-10-22 10:24:55 +1000)


Adam Richter (1):
  drm: fix mutex leak in drm_dp_get_mst_branch_device

Alex Deucher (3):
  drm/radeon/dpm: don't add pwm attributes if DPM is disabled
  drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
  drm/amdgpu: add missing dpm check for KV dpm late init

Chris Wilson (2):
  drm/i915: Flush pipecontrol post-sync writes
  drm/i915: Deny wrapping an userptr into a framebuffer

Daniel Vetter (1):
  drm/i915: Fix kerneldoc for i915_gem_shrink_all

Dave Airlie (3):
  Merge branch 'linux-4.3' of 
git://anongit.freedesktop.org/nouveau/linux-2.6 into drm-fixes
  Merge tag 'drm-intel-fixes-2015-10-16' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Ilia Mirkin (1):
  drm/nouveau/gem: return only valid domain when there's only one

Jani Nikula (1):
  Revert "drm/i915: Add primary plane to mask if it's visible"

Maarten Lankhorst (1):
  drm/i915: Add primary plane to mask if it's visible

Ville Syrjälä (4):
  drm/i915: Restore lost DPLL register write on gen2-4
  drm/i915: Enable DPLL VGA mode before P1/P2 divider write
  drm/i915: Assign hwmode after encoder state readout
  drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   |   8 ++-
 drivers/gpu/drm/amd/amdgpu/kv_dpm.c  |   3 +
 drivers/gpu/drm/drm_dp_mst_topology.c|   7 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c |   2 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c  |   5 +-
 drivers/gpu/drm/i915/intel_display.c | 120 +--
 drivers/gpu/drm/i915/intel_lrc.c |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   2 +
 drivers/gpu/drm/nouveau/nouveau_gem.c|   5 +-
 drivers/gpu/drm/radeon/radeon_pm.c   |   8 ++-
 10 files changed, 97 insertions(+), 64 deletions(-)

Re: [PATCH 1/5] clk: add missing of_node_put

[Julia Lawall]

On Wed, 21 Oct 2015, Stephen Boyd wrote:

> On 10/21, Julia Lawall wrote:
> > for_each_matching_node_and_match performs an of_node_get on each iteration,
> > so a break out of the loop requires an of_node_put.
> > 
> > A simplified version of the semantic patch that fixes this problem is as
> > follows (http://coccinelle.lip6.fr):
> > 
> > // 
> > @@
> > expression e1,e2,e;
> > local idexpression np;
> > @@
> > 
> >  for_each_matching_node_and_match(np, e1, e2) {
> >... when != of_node_put(np)
> >when != e = np
> > (
> >return np;
> > |
> > +  of_node_put(np);
> > ?  return ...;
> > )
> >...
> >  }
> > // 
> > 
> > Besides the problem identified by the semantic patch, this patch adds an
> > of_node_get in front of saving np in a field of parent, to account for the
> > fact that this value will be put on going on to the next element in the
> > iteration, and then adds of_node_puts in the two loops where the parent
> > pointer can be freed.
> > 
> > Signed-off-by: Julia Lawall 
> > 
> > ---
> 
> Applied to clk-next, except I collapsed the of_node_get() into
> the assignment.
> 
> ---8<---
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index d366bfb66c58..2eae76f21d6f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3205,8 +3205,7 @@ void __init of_clk_init(const struct of_device_id 
> *matches)
>   }
>  
>   parent->clk_init_cb = match->data;
> - of_node_get(np);
> - parent->np = np;
> + parent->np = of_node_get(np);

Thanks!

julia

>   list_add_tail(>node, _provider_list);
>   }
>  
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Oct 21 (drivers/i2c/busses/i2c-designware-platdrv.c)

[Jarkko Nikula]

Hi

On 10/21/2015 11:28 PM, Randy Dunlap wrote:

On 10/20/15 23:16, Stephen Rothwell wrote:

Hi all,

There will be no linux-next releases after tomorrow until Nov 2 (kernel
summit).

Changes since 20151020:



on i386 or x86_64:

when CONFIG_PM_SLEEP is not enabled:

../drivers/i2c/busses/i2c-designware-platdrv.c:340:13: error: 
'dw_i2c_plat_prepare' undeclared here (not in a function)
   .prepare = dw_i2c_plat_prepare,
  ^
../drivers/i2c/busses/i2c-designware-platdrv.c:341:14: error: 
'dw_i2c_plat_complete' undeclared here (not in a function)
   .complete = dw_i2c_plat_complete,
   ^

Here's the fix for this:

http://marc.info/?l=linux-i2c=144541136917692=2

--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ASoC: Intel: sst: only use sst-firmware when DW DMAC is available

[Jie Yang]

Currentlly, we use Synopsys DesignWare DMA Controller for
baytrail/haswell/broadwell ADSP firmware loading, but for
skylake, we don't use it, compiling sst-firmware.c may
introduce error when CONFIG_DW_DMAC_CORE is not enabled:

sound/built-in.o: In function `sst_dma_new':
(.text+0xd7b38): undefined reference to `dw_dma_probe'
sound/built-in.o: In function `sst_dma_free':
(.text+0xd7c0a): undefined reference to `dw_dma_remove'

Here we only compile sst-firmware when CONFIG_DW_DMAC_CORE
is selected, to fix the linking error issue.

Reported-by: Randy Dunlap 
Signed-off-by: Jie Yang 
---
 sound/soc/intel/common/Makefile  | 6 +-
 sound/soc/intel/common/sst-dsp.c | 2 ++
 sound/soc/intel/common/sst-dsp.h | 2 ++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/common/Makefile b/sound/soc/intel/common/Makefile
index f24154c..d910558 100644
--- a/sound/soc/intel/common/Makefile
+++ b/sound/soc/intel/common/Makefile
@@ -1,7 +1,11 @@
-snd-soc-sst-dsp-objs := sst-dsp.o sst-firmware.o
+snd-soc-sst-dsp-objs := sst-dsp.o
 snd-soc-sst-acpi-objs := sst-acpi.o
 snd-soc-sst-ipc-objs := sst-ipc.o
 
+ifneq ($(CONFIG_DW_DMAC_CORE),)
+snd-soc-sst-dsp-objs += sst-firmware.o
+endif
+
 obj-$(CONFIG_SND_SOC_INTEL_SST) += snd-soc-sst-dsp.o snd-soc-sst-ipc.o
 obj-$(CONFIG_SND_SOC_INTEL_SST_ACPI) += snd-soc-sst-acpi.o
 
diff --git a/sound/soc/intel/common/sst-dsp.c b/sound/soc/intel/common/sst-dsp.c
index a627236..c9452e0 100644
--- a/sound/soc/intel/common/sst-dsp.c
+++ b/sound/soc/intel/common/sst-dsp.c
@@ -420,6 +420,7 @@ void sst_dsp_inbox_read(struct sst_dsp *sst, void *message, 
size_t bytes)
 }
 EXPORT_SYMBOL_GPL(sst_dsp_inbox_read);
 
+#if IS_ENABLED(CONFIG_DW_DMAC_CORE)
 struct sst_dsp *sst_dsp_new(struct device *dev,
struct sst_dsp_device *sst_dev, struct sst_pdata *pdata)
 {
@@ -484,6 +485,7 @@ void sst_dsp_free(struct sst_dsp *sst)
sst_dma_free(sst->dma);
 }
 EXPORT_SYMBOL_GPL(sst_dsp_free);
+#endif
 
 /* Module information */
 MODULE_AUTHOR("Liam Girdwood");
diff --git a/sound/soc/intel/common/sst-dsp.h b/sound/soc/intel/common/sst-dsp.h
index 1f45f18..859f0de 100644
--- a/sound/soc/intel/common/sst-dsp.h
+++ b/sound/soc/intel/common/sst-dsp.h
@@ -216,10 +216,12 @@ struct sst_pdata {
void *dsp;
 };
 
+#if IS_ENABLED(CONFIG_DW_DMAC_CORE)
 /* Initialization */
 struct sst_dsp *sst_dsp_new(struct device *dev,
struct sst_dsp_device *sst_dev, struct sst_pdata *pdata);
 void sst_dsp_free(struct sst_dsp *sst);
+#endif
 
 /* SHIM Read / Write */
 void sst_dsp_shim_write(struct sst_dsp *sst, u32 offset, u32 value);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Oct 22

[Stephen Rothwell]

Hi all,

There will be no linux-next releases until Nov 2 (due to the kernel
summit).

Changes since 20151021:

The battery tree still had its build failure so I used the version from
next-20150925.

The tip tree gained a conflict against the arm64 tree.

The akpm-current tree lost its build failure.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 9122
 7310 files changed, 351174 insertions(+), 165176 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 228 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (8a70dd266920 Merge tag 'for-linus-20151021' of 
git://git.infradead.org/intel-iommu)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (625faa6a720d clkdev: fix clk_add_alias() with a NULL 
alias device name)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs 
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (23316316c1af powerpc: Revert "Use the POWER8 Micro 
Partition Prefetch Engine in KVM HV on POWER8")
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (50010c20597d irda: precedence bug in irlmp_seq_hb_idx())
Merging ipsec/master (ca064bd89363 xfrm: Fix pmtu discovery for local generated 
packets.)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for 
nf_dup_ipv{4,6})
Merging sound-current/for-linus (d289619a219d ALSA: hda - Fix deadlock at error 
in building PCM)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access 
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag 
'iwlwifi-for-kalle-2015-10-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (f235f664a8af fbcon: initialize blink interval 
before calling fb_set_par)
Merging usb.current/usb-linus (fd7cd061adcf xhci: Add spurious wakeup quirk for 
LynxPoint-LP controllers)
Merging usb-gadget-fixes/fixes (25cb62b76430 Linux 4.3-rc5)
Merging usb-serial-fixes/usb-linus (049e6dde7e57 Linux 4.3-rc4)
Merging staging.current/staging-linus (4301de3b0ac4 Merge tag 
'iio-fixes-for-4.3a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (c8a1978e07c4 Input: sur40 - add dependency on 
VIDEO_V4L2)
Merging crypto-current/master (3fc89adb9fa4 crypto: api - Only abort operations 
on fatal signal)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default 
emit

Re: lockdep-related warning in kernel/sched/deadline.c::find_lock_later_rq()

[Wanpeng Li]

On 10/21/15 9:20 PM, Luca Abeni wrote:

Hi all,

after fixing task migrations for SCHED_DEADLINE, I started to see some
lockdep-related warnings that look like this:
[  794.428081] WARNING: CPU: 1 PID: 0 at 
/home/luca/Src/GRUB/linux-reclaiming/kernel/locking/lockdep.c:3407 
lock_release+0x3f4/0x440()

[  794.428439] releasing a pinned lock
[  794.428439] Modules linked in:
[  794.428439] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.3.0-rc5+ #32
[  794.428439] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), 
BIOS Bochs 01/01/2011
[  794.428439]  81c946d0 880007b03cc8 8135abd2 
880007b03d10
[  794.428439]  880007b03d00 810546f1 880007b159d8 
81096663
[  794.428439]  88000754c558 0001 88000754bd80 
880007b03d60

[  794.428439] Call Trace:
[  794.428439][] dump_stack+0x4b/0x69
[  794.428439]  [] warn_slowpath_common+0x81/0xc0
[  794.428439]  [] ? find_lock_later_rq+0x103/0x180
[  794.428439]  [] warn_slowpath_fmt+0x47/0x50
[  794.428439]  [] lock_release+0x3f4/0x440
[  794.428439]  [] _raw_spin_unlock+0x1a/0x30
[  794.428439]  [] find_lock_later_rq+0x103/0x180
[  794.428439]  [] push_dl_task.part.33+0x61/0x190
[  794.428439]  [] dl_task_timer+0x194/0x2e0
[  794.428439]  [] ? task_woken_dl+0x60/0x60
[  794.428439]  [] __hrtimer_run_queues+0x107/0x470
[  794.428439]  [] ? hrtimer_interrupt+0x82/0x1b0
[  794.428439]  [] hrtimer_interrupt+0xa6/0x1b0
[  794.428439]  [] local_apic_timer_interrupt+0x30/0x60
[  794.428439]  [] smp_apic_timer_interrupt+0x38/0x50
[  794.428439]  [] apic_timer_interrupt+0x84/0x90
[  794.428439][] ? default_idle+0x1b/0x140
[  794.428439]  [] ? default_idle+0x19/0x140
[  794.428439]  [] arch_cpu_idle+0xa/0x10
[  794.428439]  [] default_idle_call+0x25/0x40
[  794.428439]  [] cpu_startup_entry+0x310/0x390
[  794.428439]  [] start_secondary+0xf3/0x100
[  794.428439] ---[ end trace 1d35bf076299f814 ]---
(this happended on KVM, but I can trigger similar warnings on real 
hardware too).


This was not happening before my last patch, because push_dl_task() 
never migrated

any task, and always returned before calling find_lock_later_rq()...

Now, if I understand correctly the issue is that dl_task_timer() does:
rq = task_rq_lock(p, );
[...]
if (has_pushable_dl_tasks(rq))
push_dl_task(rq);
with task_rq_lock() that pins rq->lock and push_tl_task() that invokes
find_lock_later_rq() that unlocks rq->lock() while it is pinned.

I am not sure about how to fix this issue: as a first try, I did
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 142df26..5b1ba95 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -668,8 +668,11 @@ static enum hrtimer_restart dl_task_timer(struct 
hrtimer *timer)
  * Queueing this task back might have overloaded rq, check if we 
need

  * to kick someone away.
  */
-if (has_pushable_dl_tasks(rq))
+if (has_pushable_dl_tasks(rq)) {
+lockdep_unpin_lock(>lock);
 push_dl_task(rq);
+lockdep_pin_lock(>lock);
+}
 #endif

 unlock:

This removes the warning, but I am not sure if it is the correct fix 
(is it

valid to unpin rq->lock, here?).

If someone can confirm that this is the correct approach, I'll test 
the patch a
little bit more and then I'll send a properly signed-off patch; 
otherwise, if

someone can suggest the correct approach I'll try it.


wake_up_new_task()
  -> __task_rq_lock()
  -> task_woken()
-> push_dl/rt_tasks()
  -> push_dl/rt_task()

I think you also should consider the lockdep pin_lock in this path.

Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

[Wangnan (F)]

On 2015/10/22 6:58, Alexei Starovoitov wrote:

Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
   (do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can cause kernel splat.

Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get the 
selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov 
---
v1->v2: fix compile in case of !CONFIG_PERF_EVENTS

This patch is on top of
http://patchwork.ozlabs.org/patch/533585/
to avoid conflicts.
Even in the worst case the crash is not possible.
Only warn_on_once, so imo net-next is ok.

  kernel/bpf/arraymap.c |9 +
  kernel/events/core.c  |   16 ++--
  2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index e3cfe46b074f..75529cc94304 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -294,10 +294,11 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map, int fd)
if (IS_ERR(attr))
return (void *)attr;
  
-	if (attr->type != PERF_TYPE_RAW &&

-   !(attr->type == PERF_TYPE_SOFTWARE &&
- attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
-   attr->type != PERF_TYPE_HARDWARE) {
+   if ((attr->type != PERF_TYPE_RAW &&
+!(attr->type == PERF_TYPE_SOFTWARE &&
+  attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
+attr->type != PERF_TYPE_HARDWARE) ||
+   attr->inherit) {


This 'if' statement is so complex. What about using a inline function 
instead?


Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

[Wangnan (F)]

On 2015/10/22 13:00, Alexei Starovoitov wrote:

On 10/21/15 9:49 PM, Wangnan (F) wrote:

After applying this patch I'm unable to use perf passing perf_event
again like this:


please do not top post and trim your replies.


  # perf record -a -e evt=cycles -e
./test_config_map.c/maps.pmu_map.event=evt/ --exclude-perf ls

With -v it output:

...
adding perf_bpf_probe:func_write
adding perf_bpf_probe:func_write to 0x367d6a0
add bpf event perf_bpf_probe:func_write_return and attach bpf program 6
adding perf_bpf_probe:func_write_return
adding perf_bpf_probe:func_write_return to 0x3a7fc40
mmap size 528384B
ERROR: failed to insert value to pmu_map[0]
ERROR: Apply config to BPF failed: Invalid option for map, add -v to see
detail
Opening /sys/kernel/debug/tracing//kprobe_events write=
...

Looks like perf sets attr.inherit for cycles? I'll look into this 
problem.


yes. that's perf default.
How did it even work before?!
I was testing with your samples/bpf/tracex6 that sets inherit to zero.



Tested perf record -i option and it works for me:

# echo "" > /sys/kernel/debug/tracing/trace
# perf record -i -a -e evt=cycles -e 
./test_config_map.c/maps.pmu_map.event=evt/ --exclude-perf ls

# cat /sys/kernel/debug/tracing/trace  | grep ls
  ls-8227  [001] dN..  2526.184611: : pmu inc: 82270
  ls-8227  [001] dN..  2526.184626: : pmu inc: 40951
  ls-8227  [001] dN..  2526.184642: : pmu inc: 50659
  ls-8227  [001] dN..  2526.184657: : pmu inc: 43511
  ls-8227  [001] dN..  2526.184675: : pmu inc: 56921
...
And no warning message found in dmesg.

So I think your fix is good, we should improve perf.

Thank you.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next RFC 1/2] vhost: introduce vhost_has_work()

[Jason Wang]

This path introduces a helper which can give a hint for whether or not
there's a work queued in the work list.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c | 6 ++
 drivers/vhost/vhost.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index eec2f11..d42d11e 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -245,6 +245,12 @@ void vhost_work_queue(struct vhost_dev *dev, struct 
vhost_work *work)
 }
 EXPORT_SYMBOL_GPL(vhost_work_queue);
 
+bool vhost_has_work(struct vhost_dev *dev)
+{
+   return !list_empty(>work_list);
+}
+EXPORT_SYMBOL_GPL(vhost_has_work);
+
 void vhost_poll_queue(struct vhost_poll *poll)
 {
vhost_work_queue(poll->dev, >work);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 4772862..ea0327d 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -37,6 +37,7 @@ struct vhost_poll {
 
 void vhost_work_init(struct vhost_work *work, vhost_work_fn_t fn);
 void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work);
+bool vhost_has_work(struct vhost_dev *dev);
 
 void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn,
 unsigned long mask, struct vhost_dev *dev);
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next RFC 2/2] vhost_net: basic polling support

[Jason Wang]

This patch tries to poll for new added tx buffer for a while at the
end of tx processing. The maximum time spent on polling were limited
through a module parameter. To avoid block rx, the loop will end it
there's new other works queued on vhost so in fact socket receive
queue is also be polled.

busyloop_timeout = 50 gives us following improvement on TCP_RR test:

size/session/+thu%/+normalize%
1/ 1/   +5%/  -20%
1/50/  +17%/   +3%

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9eda69e..bbb522a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -31,7 +31,9 @@
 #include "vhost.h"
 
 static int experimental_zcopytx = 1;
+static int busyloop_timeout = 50;
 module_param(experimental_zcopytx, int, 0444);
+module_param(busyloop_timeout, int, 0444);
 MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
   " 1 -Enable; 0 - Disable");
 
@@ -287,12 +289,23 @@ static void vhost_zerocopy_callback(struct ubuf_info 
*ubuf, bool success)
rcu_read_unlock_bh();
 }
 
+static bool tx_can_busy_poll(struct vhost_dev *dev,
+unsigned long endtime)
+{
+   unsigned long now = local_clock() >> 10;
+
+   return busyloop_timeout && !need_resched() &&
+  !time_after(now, endtime) && !vhost_has_work(dev) &&
+  single_task_running();
+}
+
 /* Expects to be always run from workqueue - which acts as
  * read-size critical section for our kind of RCU. */
 static void handle_tx(struct vhost_net *net)
 {
struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *vq = >vq;
+   unsigned long endtime;
unsigned out, in;
int head;
struct msghdr msg = {
@@ -331,6 +344,8 @@ static void handle_tx(struct vhost_net *net)
  % UIO_MAXIOV == nvq->done_idx))
break;
 
+   endtime  = (local_clock() >> 10) + busyloop_timeout;
+again:
head = vhost_get_vq_desc(vq, vq->iov,
 ARRAY_SIZE(vq->iov),
 , ,
@@ -340,6 +355,10 @@ static void handle_tx(struct vhost_net *net)
break;
/* Nothing new?  Wait for eventfd to tell us they refilled. */
if (head == vq->num) {
+   if (tx_can_busy_poll(vq->dev, endtime)) {
+   cpu_relax();
+   goto again;
+   }
if (unlikely(vhost_enable_notify(>dev, vq))) {
vhost_disable_notify(>dev, vq);
continue;
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPOST PATCH] ftrace: Calculate the correct dyn_ftrace number to report to the userspace

[Minfei Huang]

On 10/15/15 at 10:25pm, Steven Rostedt wrote:
> On Thu, 17 Sep 2015 00:19:42 +0800
> Minfei Huang  wrote:
> 
> > Now, ftrace only calculate the dyn_ftrace number in the adding
> > breakpoint loop, not in adding update and finish update loop.
> > 
> > Calculate the correct dyn_ftrace, once ftrace reports the failure message
> > to the userspace.
> > 
> 
> Bah, your emails got lost in my Inbox. Sorry about that.
> 
> I'll make an effort to look at this first thing tomorrow.

Ping. Any comment is appreciate.

Thanks
Minfei

> 
> [ Cc'ing myself to remind me ]
> 
> -- Steve
> 
> > Signed-off-by: Minfei Huang 
> > ---
> >  arch/x86/kernel/ftrace.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 8b7b0a5..311bcf3 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/kernel/ftrace.c
> > @@ -556,6 +556,7 @@ void ftrace_replace_code(int enable)
> > run_sync();
> >  
> > report = "updating code";
> > +   count = 0;
> >  
> > for_ftrace_rec_iter(iter) {
> > rec = ftrace_rec_iter_record(iter);
> > @@ -563,11 +564,13 @@ void ftrace_replace_code(int enable)
> > ret = add_update(rec, enable);
> > if (ret)
> > goto remove_breakpoints;
> > +   count++;
> > }
> >  
> > run_sync();
> >  
> > report = "removing breakpoints";
> > +   count = 0;
> >  
> > for_ftrace_rec_iter(iter) {
> > rec = ftrace_rec_iter_record(iter);
> > @@ -575,6 +578,7 @@ void ftrace_replace_code(int enable)
> > ret = finish_update(rec, enable);
> > if (ret)
> > goto remove_breakpoints;
> > +   count++;
> > }
> >  
> > run_sync();
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Anand Moon]

Hi Javier,

On 22 October 2015 at 08:22, Javier Martinez Canillas
 wrote:
> Hello Krzysztof,
>
> On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote:
>> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,
>>>
>>> Thanks for your feedback.
>>>
>>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote:
 On 22.10.2015 00:15, Javier Martinez Canillas wrote:
> The pwrseq_emmc driver does a eMMC card reset before a system reboot to
> allow broken or limited ROM boot-loaders (that don't have an eMMC reset
> logic) to be able to read the second stage from the eMMC.
>
> But this has to be called before a system reboot handler and while most
> of them use the priority 128, there are other restart handlers (such as
> the syscon-reboot one) that use a higher priority. So, use the highest
> priority to make sure that the eMMC hw is reset before a system reboot.
>
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Markus Reichl 
> Tested-by: Anand Moon 
> Reviewed-by: Alim Akhtar 
>
> ---
> Hello,
>
> This patch was needed since a recent series from Alim [0] added
> syscon reboot and poweroff support to Exynos SoCs and removed
> the reset handler in the Exynos Power Management Unit (PMU) code.
>
> But the PMU and syscon-reboot restart handler have a different
> priority so [0] breaks restart when eMMC is used on these boards.
>
> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html
>
> So this patch must be merged before [0] to avoid regressions.
>
> Best regards,
> Javier
>
>  drivers/mmc/core/pwrseq_emmc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/pwrseq_emmc.c 
> b/drivers/mmc/core/pwrseq_emmc.c
> index 137c97fb7aa8..ad4f94ec7e8d 100644
> --- a/drivers/mmc/core/pwrseq_emmc.c
> +++ b/drivers/mmc/core/pwrseq_emmc.c
> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct 
> mmc_host *host,
>
>/*
> * register reset handler to ensure emmc reset also from
> -   * emergency_reboot(), priority 129 schedules it just before
> -   * system reboot
> +   * emergency_reboot(), priority 255 is the highest priority
> +   * so it will be executed before any system reboot handler.
> */
>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
> -  pwrseq->reset_nb.priority = 129;
> +  pwrseq->reset_nb.priority = 255;

 I see the problem which you are trying to solve but this may be tricker
 then just kicking the number. Some of restart handlers are registered
 with priority 192. I found few of such, like: at91_restart_nb,
 zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too
 much).

>>>
>>> Yes, the syscon-reboot restart handler also uses a priority 192 and that
>>> is why reboot with eMMC broke with Alim's patches since the PMU restart
>>> handler priority is 128.
>>>
 I guess they chose the "192" priority on purpose.

>>>
>>> I tried to understand what's the policy w.r.t priority numbering for
>>> restart handlers but only found this in the register_restart_handler
>>> kernel-doc [0]:
>>>
>>> /**
>>>  *   register_restart_handler - Register function to be called to reset
>>>  *  the system
>>>  *   @nb: Info about handler function to be called
>>>  *   @nb->priority:  Handler priority. Handlers should follow the
>>>  *   following guidelines for setting priorities.
>>>  *   0:  Restart handler of last resort,
>>>  *   with limited restart capabilities
>>>  *   128:Default restart handler; use if no other
>>>  *   restart handler is expected to be available,
>>>  *   and/or if restart functionality is
>>>  *   sufficient to restart the entire system
>>>  *   255:Highest priority restart handler, will
>>>  *   preempt all other restart handlers
>>>
>>> So, reading that is not clear to me if only the values 0, 128 and 255
>>> should be used or any value from 0-255.
>>>
>>> What's clear to me is that restart handlers to reset a specific hw block
>>> should be called before the restart handler that resets the whole system.
>>>
>>> The 192 seems to be used because there are other default restart handlers
>>> that are using a prio of 128. See for example the commit that changed the
>>> syscon-reboot prio from 128 to 192:
>>>
>>> b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver
>>
>> But were are here not talking about syscon handler but the others. Now
>> you will be ahead of them.
>>
>
> Yes, I know that. My point was that the platforms were either not using the
> mmc-pwrseq-emmc or their system restart handler already had 

[PATCH 2/2] can: xilinx: fix bug in bus error handling

[Kedareswara rao Appana]

Simply resetting the peripheral on bus off condition is not enough,
Because we also need to re-initialize the whole device.
This patch fixes this issue.

Signed-off-by: Kedareswara rao Appana 
---
 drivers/net/can/xilinx_can.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 055d6f3..9aeb85f 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -529,6 +529,8 @@ static int xcan_rx(struct net_device *ndev)
return 1;
 }
 
+static void xcan_chip_stop(struct net_device *ndev);
+
 /**
  * xcan_err_interrupt - error frame Isr
  * @ndev:  net_device pointer
@@ -558,8 +560,9 @@ static void xcan_err_interrupt(struct net_device *ndev, u32 
isr)
if (isr & XCAN_IXR_BSOFF_MASK) {
priv->can.state = CAN_STATE_BUS_OFF;
priv->can.can_stats.bus_off++;
-   /* Leave device in Config Mode in bus-off state */
-   priv->write_reg(priv, XCAN_SRR_OFFSET, XCAN_SRR_RESET_MASK);
+   /* Re-initialize the whole device in bus-off state */
+   xcan_chip_stop(ndev);
+   xcan_chip_start(ndev);
can_bus_off(ndev);
if (skb)
cf->can_id |= CAN_ERR_BUSOFF;
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] can: xilinx: use readl/writel instead of ioread/iowrite

[Kedareswara rao Appana]

The driver only supports memory-mapped I/O [by ioremap()],
so readl/writel is actually the right thing to do, IMO.
During the validation of this driver or IP on ARM 64-bit processor
while sending lot of packets observed that the tx packet drop with iowrite
Putting the barriers for each tx fifo register write fixes this issue
Instead of barriers using writel also fixed this issue.

Signed-off-by: Kedareswara rao Appana 
---
 drivers/net/can/xilinx_can.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 6114214..055d6f3 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -170,7 +170,7 @@ static const struct can_bittiming_const 
xcan_bittiming_const = {
 static void xcan_write_reg_le(const struct xcan_priv *priv, enum xcan_reg reg,
u32 val)
 {
-   iowrite32(val, priv->reg_base + reg);
+   writel(val, priv->reg_base + reg);
 }
 
 /**
@@ -183,7 +183,7 @@ static void xcan_write_reg_le(const struct xcan_priv *priv, 
enum xcan_reg reg,
  */
 static u32 xcan_read_reg_le(const struct xcan_priv *priv, enum xcan_reg reg)
 {
-   return ioread32(priv->reg_base + reg);
+   return readl(priv->reg_base + reg);
 }
 
 /**
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

[Alexei Starovoitov]

On 10/21/15 9:49 PM, Wangnan (F) wrote:

After applying this patch I'm unable to use perf passing perf_event
again like this:


please do not top post and trim your replies.


  # perf record -a -e evt=cycles -e
./test_config_map.c/maps.pmu_map.event=evt/ --exclude-perf ls

With -v it output:

...
adding perf_bpf_probe:func_write
adding perf_bpf_probe:func_write to 0x367d6a0
add bpf event perf_bpf_probe:func_write_return and attach bpf program 6
adding perf_bpf_probe:func_write_return
adding perf_bpf_probe:func_write_return to 0x3a7fc40
mmap size 528384B
ERROR: failed to insert value to pmu_map[0]
ERROR: Apply config to BPF failed: Invalid option for map, add -v to see
detail
Opening /sys/kernel/debug/tracing//kprobe_events write=
...

Looks like perf sets attr.inherit for cycles? I'll look into this problem.


yes. that's perf default.
How did it even work before?!
I was testing with your samples/bpf/tracex6 that sets inherit to zero.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator, dt: add dt support for tps6502x regulator

[Heiko Schocher]

Hello Mark,

Am 21.10.2015 um 18:17 schrieb Mark Brown:

On Wed, Oct 21, 2015 at 02:52:51PM +0200, Heiko Schocher wrote:

Am 21.10.2015 um 14:19 schrieb Mark Brown:

On Mon, Oct 19, 2015 at 08:27:13AM +0200, Heiko Schocher wrote:



If this file is needed there is something broken, if this file is not
needed then it is just noise since everything in it needs to be
overridden by users anyway.  Either way please remove it.



Uh, I thought to do it like:



arch/arm/boot/dts/tps65217.dtsi



but, okay, removed.


That too is broken and should be removed :(


Ok, I have a board which uses this regulator ... can you give me a hint,
how to remove it correctly?

I would do:

move from arch/arm/boot/dts/tps65217.dtsi into board dts

 {
+   compatible = "ti,tps65217";
[...]

and the reg and "regulator-compatible" into the corresponding
nodes ...

dcdc1_reg: regulator@0 {
+reg = <0>;
+regulator-compatible = "dcdc1";

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

[Wangnan (F)]

After applying this patch I'm unable to use perf passing perf_event 
again like this:


 # perf record -a -e evt=cycles -e 
./test_config_map.c/maps.pmu_map.event=evt/ --exclude-perf ls


With -v it output:

...
adding perf_bpf_probe:func_write
adding perf_bpf_probe:func_write to 0x367d6a0
add bpf event perf_bpf_probe:func_write_return and attach bpf program 6
adding perf_bpf_probe:func_write_return
adding perf_bpf_probe:func_write_return to 0x3a7fc40
mmap size 528384B
ERROR: failed to insert value to pmu_map[0]
ERROR: Apply config to BPF failed: Invalid option for map, add -v to see 
detail

Opening /sys/kernel/debug/tracing//kprobe_events write=
...

Looks like perf sets attr.inherit for cycles? I'll look into this problem.

Thank you.

On 2015/10/22 6:58, Alexei Starovoitov wrote:

Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
   (do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can cause kernel splat.

Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get the 
selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov 
---
v1->v2: fix compile in case of !CONFIG_PERF_EVENTS

This patch is on top of
http://patchwork.ozlabs.org/patch/533585/
to avoid conflicts.
Even in the worst case the crash is not possible.
Only warn_on_once, so imo net-next is ok.

  kernel/bpf/arraymap.c |9 +
  kernel/events/core.c  |   16 ++--
  2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index e3cfe46b074f..75529cc94304 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -294,10 +294,11 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map, int fd)
if (IS_ERR(attr))
return (void *)attr;
  
-	if (attr->type != PERF_TYPE_RAW &&

-   !(attr->type == PERF_TYPE_SOFTWARE &&
- attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
-   attr->type != PERF_TYPE_HARDWARE) {
+   if ((attr->type != PERF_TYPE_RAW &&
+!(attr->type == PERF_TYPE_SOFTWARE &&
+  attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
+attr->type != PERF_TYPE_HARDWARE) ||
+   attr->inherit) {
perf_event_release_kernel(event);
return ERR_PTR(-EINVAL);
}
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 64754bfecd70..0b6333265872 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3258,7 +3258,7 @@ static inline u64 perf_event_count(struct perf_event 
*event)
  u64 perf_event_read_local(struct perf_event *event)
  {
unsigned long flags;
-   u64 val;
+   u64 val = -EINVAL;
  
  	/*

 * Disabling interrupts avoids all counter scheduling (context
@@ -3267,12 +3267,14 @@ u64 perf_event_read_local(struct perf_event *event)
local_irq_save(flags);
  
  	/* If this is a per-task event, it must be for current */

-   WARN_ON_ONCE((event->attach_state & PERF_ATTACH_TASK) &&
-event->hw.target != current);
+   if ((event->attach_state & PERF_ATTACH_TASK) &&
+   event->hw.target != current)
+   goto out;
  
  	/* If this is a per-CPU event, it must be for this CPU */

-   WARN_ON_ONCE(!(event->attach_state & PERF_ATTACH_TASK) &&
-event->cpu != smp_processor_id());
+   if (!(event->attach_state & PERF_ATTACH_TASK) &&
+   event->cpu != smp_processor_id())
+   goto out;
  
  	/*

 * It must not be an event with inherit set, we cannot read
@@ -3284,7 +3286,8 @@ u64 perf_event_read_local(struct perf_event *event)
 * It must not have a pmu::count method, those are not
 * NMI safe.
 */
-   WARN_ON_ONCE(event->pmu->count);
+   if (event->pmu->count)
+   goto out;
  
  	/*

 * If the event is currently on this CPU, its either a per-task event,
@@ -3295,6 +3298,7 @@ u64 perf_event_read_local(struct perf_event *event)
event->pmu->read(event);
  
  	val = local64_read(>count);

+out:
local_irq_restore(flags);
  
  	return val;



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6] can: xilinx: Convert to runtime_pm

[Kedareswara rao Appana]

Instead of enabling/disabling clocks at several locations in the driver,
Use the runtime_pm framework. This consolidates the actions for runtime PM
In the appropriate callbacks and makes the driver more readable and mantainable.

Signed-off-by: Kedareswara rao Appana 
---
Sorry for the long delay for sending this next version of the patch.
somehow couldn't manage to send this next version of the patch.
 
Changes for v6:
 - Updated the driver with review comments as suggested by Marc.
Changes for v5:
 - Updated with the review comments.
   Updated the remove fuction to use runtime_pm.
Chnages for v4:
 - Updated with the review comments.
Changes for v3:
  - Converted the driver to use runtime_pm.
Changes for v2:
  - Removed the struct platform_device* from suspend/resume
as suggest by Lothar.

 drivers/net/can/xilinx_can.c | 176 +++
 1 file changed, 110 insertions(+), 66 deletions(-)

diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index fc55e8e..6114214 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME"xilinx_can"
 
@@ -138,7 +139,7 @@ struct xcan_priv {
u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
u32 val);
-   struct net_device *dev;
+   struct device *dev;
void __iomem *reg_base;
unsigned long irq_flags;
struct clk *bus_clk;
@@ -843,6 +844,13 @@ static int xcan_open(struct net_device *ndev)
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
 
+   ret = pm_runtime_get_sync(priv->dev);
+   if (ret < 0) {
+   netdev_err(ndev, "%s: pm_runtime_get failed(%d)\n",
+   __func__, ret);
+   return ret;
+   }
+
ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
ndev->name, ndev);
if (ret < 0) {
@@ -850,29 +858,17 @@ static int xcan_open(struct net_device *ndev)
goto err;
}
 
-   ret = clk_prepare_enable(priv->can_clk);
-   if (ret) {
-   netdev_err(ndev, "unable to enable device clock\n");
-   goto err_irq;
-   }
-
-   ret = clk_prepare_enable(priv->bus_clk);
-   if (ret) {
-   netdev_err(ndev, "unable to enable bus clock\n");
-   goto err_can_clk;
-   }
-
/* Set chip into reset mode */
ret = set_reset_mode(ndev);
if (ret < 0) {
netdev_err(ndev, "mode resetting failed!\n");
-   goto err_bus_clk;
+   goto err_irq;
}
 
/* Common open */
ret = open_candev(ndev);
if (ret)
-   goto err_bus_clk;
+   goto err_irq;
 
ret = xcan_chip_start(ndev);
if (ret < 0) {
@@ -888,13 +884,11 @@ static int xcan_open(struct net_device *ndev)
 
 err_candev:
close_candev(ndev);
-err_bus_clk:
-   clk_disable_unprepare(priv->bus_clk);
-err_can_clk:
-   clk_disable_unprepare(priv->can_clk);
 err_irq:
free_irq(ndev->irq, ndev);
 err:
+   pm_runtime_put(priv->dev);
+
return ret;
 }
 
@@ -911,12 +905,11 @@ static int xcan_close(struct net_device *ndev)
netif_stop_queue(ndev);
napi_disable(>napi);
xcan_chip_stop(ndev);
-   clk_disable_unprepare(priv->bus_clk);
-   clk_disable_unprepare(priv->can_clk);
free_irq(ndev->irq, ndev);
close_candev(ndev);
 
can_led_event(ndev, CAN_LED_EVENT_STOP);
+   pm_runtime_put(priv->dev);
 
return 0;
 }
@@ -935,27 +928,20 @@ static int xcan_get_berr_counter(const struct net_device 
*ndev,
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
 
-   ret = clk_prepare_enable(priv->can_clk);
-   if (ret)
-   goto err;
-
-   ret = clk_prepare_enable(priv->bus_clk);
-   if (ret)
-   goto err_clk;
+   ret = pm_runtime_get_sync(priv->dev);
+   if (ret < 0) {
+   netdev_err(ndev, "%s: pm_runtime_get failed(%d)\n",
+   __func__, ret);
+   return ret;
+   }
 
bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) & XCAN_ECR_TEC_MASK;
bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
XCAN_ECR_REC_MASK) >> XCAN_ESR_REC_SHIFT);
 
-   clk_disable_unprepare(priv->bus_clk);
-   clk_disable_unprepare(priv->can_clk);
+   pm_runtime_put(priv->dev);
 
return 0;
-
-err_clk:
-   clk_disable_unprepare(priv->can_clk);
-err:
-   return ret;
 }
 
 
@@ -968,15 +954,45 @@ static const struct net_device_ops xcan_netdev_ops = {
 
 /**
  * xcan_suspend - Suspend method for the driver
- * @dev:   Address of the platform_device structure
+ * @dev:   Address 

Re: console vs earlycon ?

[Masahiro Yamada]

Hi Peter

2015-10-21 22:20 GMT+09:00 Peter Hurley :
> On 10/21/2015 04:21 AM, Masahiro Yamada wrote:
>> Hi.
>>
>>
>>
>>
>> I think there are three places where console could be enabled.
>>
>> [1] earlycon
>>
>> Each driver entry is declared with
>> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
>>
>>
>>
>> [2] console_init()
>>
>> Each entry is declared with  console_initcall()
>>
>>
>>
>> [3]  when driver is probed
>> The console is usually enabled at this point
>> unless some special treatment is done.
>>
>>
>>
>>
>> My question is about [2].
>
> For 8250 sub-drivers, the console_initcall() is only for legacy
> platforms, and not for 8250 ports added via serial8250_register_8250_port().
>
> In this contexts, legacy platforms are:
> 1. early_serial_setup()
> 2. platforms that define SERIAL_PORT_DFNS (eg., ISA ports)
>
>
> At the point where console_initcall() occurs, the 8250 core has _not_
> been initialized (ie., serial8250_init() has _not_ run).
>
>
>
>> I am using 8250-ish UART device.
>>
>>
>> I noticed univ8250_console_match() and univ8250_console_setup()
>> always fail at the point of [2] unless early_serial_setup() has been
>> called in advance;
>> however, it looks like early_serial_setup() is only used for old platforms.
>>
>> So, console cannot be enabled at [2] for modern platforms.
>
> Since console_init() => console_initcall() occurs before almost everything,
> it's not practical to use for probed drivers.
>
>
>> My questions are:
>>
>>  -  Given that earlycon can be now available for major architectures such 
>> ARM,
>>  [2] will be deprecated at some point in the future?
>
> PPC and x86 platforms still rely on console_init() so it will be some time
> before this disappears.
>
>>  - I am implementing  earlycon  for my own UART driver.
>>Is it meaningless to implement  console_initcall()  as well as earlycon?
>
> Probed drivers should only implement earlycon and console. 8250 sub-drivers
> should only implement earlycon and/or console if the base 8250 earlycon and/or
> console are not operational.

Sorry, let me to be sure a bit.

Which does "console" in this context mean
  - console_initcall
  - console enabled when the driver is probed

I am assuming the latter.


Thanks,



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] can: xilinx: fix RX FIFO overflow error handling

[Appana Durga Kedareswara Rao]

Hi,

Thanks for the patch. Sorry for the delay in the reply.
Patch looks good to me 

Reviewed-by: Kedareswara rao Appana

The bus off condition in the error interrupt handler also needs the same 
treatment sent the patch for the same.
Please resend your patch on top of my patch series.

Regards,
Kedar


> -Original Message-
> From: Andrea Scian - DAVE Embedded Systems
> [mailto:andrea.sc...@dave.eu]
> Sent: Thursday, August 06, 2015 1:31 AM
> To: Michal Simek; Appana Durga Kedareswara Rao
> Cc: m...@pengutronix.de; w...@grandegger.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] can: xilinx: fix RX FIFO overflow error handling
> 
> 
> Michal,
> Kedar,
> 
> Any feedback regarding my patch?
> Have you ever experienced such a problem?
> 
> Andrea SCIAN
> 
> *DAVE Embedded Systems*
> via Talponedo 29/A 33080 Porcia (PN) - Italy
> Telephone: +39.0434.921215
> Telefax: +39.0434.1994030
> web: www.dave.eu 
> 
> 
> Il 24/07/2015 06:15, Michal Simek ha scritto:
> > + Kedar
> >
> > On 07/23/2015 11:13 PM, Andrea Scian wrote:
> >> Simply resetting the peripheral on RX FIFO overflow in not enough,
> >> because we also need to re-initialize the whole device.
> >> Also always enable RX FIFO overflow interrupt otherwise we may hang
> >> until another interrupt arrives (this happens if FIFO overrun and
> >> just read from CAN bus with candump)
> >>
> >> Signed-off-by: Andrea Scian 
> >> ---
> >>
> >> You can reproduce the problem with the following test-bed
> >> * connect a Zynq based board to a PC with a CAN bus adapter (e.g.
> >> PCAN USB)
> >> * start sending lots of CAN messages to Zynq system
> >> * configure and start xilinx CAN driver
> >> ** canconfig can0 bitrate 100
> >> ** canconfig can0 start
> >> * try to send/receive messages (cansend/candump)
> >> * if you send a CAN message you'll get the RX FIFO error and
> >> additional messages will not be received
> >> * if you try to get messages you simple don't receive them (no
> >> interrupt triggered)
> >> * with canconfig stop/start the hang goes away (if the others peers
> >> stop sending send lots of messages ;-) )
> >>
> >> I tested the patch over xilinx-2014.04 kernel, but the patch applies
> >> cleanly to mainline too.
> >>
> >> If someone has a better understanding of Xilinx CAN driver, please
> >> let me know if it's better to handle the error in a different manner.
> >>
> >> Maybe the bus off handler need the same threadment too.
> >>
> >> TIA,
> >>
> >> Andrea Scian
> >>
> >> ---
> >>   drivers/net/can/xilinx_can.c |5 -
> >>   1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/can/xilinx_can.c
> >> b/drivers/net/can/xilinx_can.c index 5e8b560..c278177 100644
> >> --- a/drivers/net/can/xilinx_can.c
> >> +++ b/drivers/net/can/xilinx_can.c
> >> @@ -100,6 +100,7 @@ enum xcan_reg {
> >>   #define XCAN_INTR_ALL(XCAN_IXR_TXOK_MASK |
> XCAN_IXR_BSOFF_MASK |\
> >> XCAN_IXR_WKUP_MASK |
> XCAN_IXR_SLP_MASK | \
> >> XCAN_IXR_RXNEMP_MASK |
> XCAN_IXR_ERROR_MASK | \
> >> +   XCAN_IXR_RXOFLW_MASK | \
> >> XCAN_IXR_ARBLST_MASK |
> XCAN_IXR_RXOK_MASK)
> >>
> >>   /* CAN register bit shift - XCAN___SHIFT */ @@ -526,6
> >> +527,7 @@ static int xcan_rx(struct net_device *ndev)
> >>return 1;
> >>   }
> >>
> >> +static void xcan_chip_stop(struct net_device *ndev);
> >>   /**
> >>* xcan_err_interrupt - error frame Isr
> >>* @ndev:net_device pointer
> >> @@ -597,7 +599,8 @@ static void xcan_err_interrupt(struct net_device
> *ndev, u32 isr)
> >>if (isr & XCAN_IXR_RXOFLW_MASK) {
> >>stats->rx_over_errors++;
> >>stats->rx_errors++;
> >> -  priv->write_reg(priv, XCAN_SRR_OFFSET,
> XCAN_SRR_RESET_MASK);
> >> +  xcan_chip_stop(ndev);
> >> +  xcan_chip_start(ndev);
> >>if (skb) {
> >>cf->can_id |= CAN_ERR_CRTL;
> >>cf->data[1] |= CAN_ERR_CRTL_RX_OVERFLOW;
> >>
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Jassi Brar]

On 22 October 2015 at 05:35, Suman Anna  wrote:

>>   Anyways I am OK too, if you guys want to fix it with a platform
>> specific quirk. Let me know I'll pick this patch.
>
> I haven't gotten a chance to try #1, and I won't be able to look at it
> atleast for another month. I suggest that you go ahead and pick this
> patch up, as a quirk is needed in one form or the other for #2, and #1
> is anyways a bigger change that will affect all our IPC stacks across
> all pairs of MPU - remote processors on different SoCs.
>
Yeah that is the reason I offered to pick this patch as such.
OK I'll take this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/6] MT8173 IOMMU SUPPORT

[Yong Wu]

On Wed, 2015-10-14 at 14:56 +0200, Joerg Roedel wrote:
> On Fri, Oct 09, 2015 at 10:23:02AM +0800, Yong Wu wrote:
> > Yong Wu (6):
> >   dt-bindings: iommu: Add binding for mediatek IOMMU
> >   dt-bindings: mediatek: Add smi dts binding
> >   iommu: add ARM short descriptor page table allocator
> >   memory: mediatek: Add SMI driver
> >   iommu/mediatek: Add mt8173 IOMMU driver
> >   dts: mt8173: Add iommu/smi nodes for mt8173
> > 
> >  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  61 ++
> >  .../memory-controllers/mediatek,smi-larb.txt   |  25 +
> >  .../bindings/memory-controllers/mediatek,smi.txt   |  24 +
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  81 ++
> >  drivers/iommu/Kconfig  |  33 +
> >  drivers/iommu/Makefile |   2 +
> >  drivers/iommu/io-pgtable-arm-short.c   | 827 
> > +
> >  drivers/iommu/io-pgtable-arm.c |   3 -
> >  drivers/iommu/io-pgtable.c |   3 +
> >  drivers/iommu/io-pgtable.h |  18 +-
> >  drivers/iommu/mtk_iommu.c  | 767 
> > +++
> >  drivers/memory/Kconfig |   8 +
> >  drivers/memory/Makefile|   1 +
> >  drivers/memory/mtk-smi.c   | 274 +++
> >  include/dt-bindings/memory/mt8173-larb-port.h  | 105 +++
> >  include/soc/mediatek/smi.h |  60 ++
> 
> So this contains not only IOMMU code. Are the patches dependent on each
> other or can the iommu parts be merged independently?
> 
>   Joerg
> 
Hi Joerg,
 Sorry for reply late.
 The ARM short descriptor is independent. This one can be merged
independently.

 But the mtk-iommu depend on the drivers/memory/mtk-smi.c(mtk-iommu
has called a function of the mtk-smi).
 So if there is dependence here, How should we do to merge them?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/11] exynos-ufs: add support for Exynos

[Alim Akhtar]

A Gentle Reminder !!

On 10/14/2015 06:25 PM, Alim Akhtar wrote:

This patch-set introduces UFS (Universal Flash Storage) host support
for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific driver.
And it also contains some quirks handling for Exynos.

NOTE: ** This series has a dependency on [4]. **

-Changes since v3:
* Fixed compilation warrings as reported by "Kbuild Test Robot"[5].
* Restructure the driver to make it as a platform driver, rebased on top of [4].
* Addressed review comments from Arnd Bergmann[5].
* Other misc changes and improvements.

-Changes since v2:
* Addressed review comments from Kishon[1] and Rob Herring [2]
* Splited ufs dt binding documetation from ufs driver patch

-Changes since v1:
* Addressed review comments from Alexey[3] and various review comments from 
Amit.
* Updated email id of Seungwon as his samsung id is void now.
* Added ufs platform data

[1]-> https://lkml.org/lkml/2015/9/18/29
[2]-> https://lkml.org/lkml/2015/9/21/668
[3]-> https://lkml.org/lkml/2015/8/23/124
[4]-> https://lkml.org/lkml/2015/9/2/364
[5]-> https://lkml.org/lkml/2015/10/1/402

This patch set is tested on exynos7-espresso board.

Alim Akhtar (1):
   Documentation: samsung-phy: Add dt bindings for UFS

Seungwon Jeon (10):
   phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
   scsi: ufs: add quirk to contain unconformable utrd field
   scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
   scsi: ufs: add quirk not to allow reset of interrupt aggregation
   scsi: ufs: add quirk to enable host controller without hce
   scsi: ufs: add specific callback for nexus type
   scsi: ufs: add add specific callback for hibern8
   scsi: ufs: make ufshcd_config_pwr_mode of non-static func
   Documentation: devicetree: ufs: Add DT bindings for exynos UFS host
 controller
   scsi: ufs-exynos: add UFS host support for Exynos SoCs

  .../devicetree/bindings/phy/samsung-phy.txt|   22 +
  .../devicetree/bindings/ufs/ufs-exynos.txt |  104 ++
  drivers/phy/Kconfig|7 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos-ufs.c   |  257 
  drivers/phy/phy-exynos-ufs.h   |   88 ++
  drivers/phy/phy-exynos7-ufs.h  |   89 ++
  drivers/scsi/ufs/Kconfig   |   12 +
  drivers/scsi/ufs/Makefile  |1 +
  drivers/scsi/ufs/ufs-exynos-hw.c   |  131 ++
  drivers/scsi/ufs/ufs-exynos-hw.h   |   43 +
  drivers/scsi/ufs/ufs-exynos.c  | 1317 
  drivers/scsi/ufs/ufs-exynos.h  |  247 
  drivers/scsi/ufs/ufshcd.c  |  168 ++-
  drivers/scsi/ufs/ufshcd.h  |   54 +
  drivers/scsi/ufs/ufshci.h  |   26 +-
  drivers/scsi/ufs/unipro.h  |   47 +
  include/linux/phy/phy-exynos-ufs.h |  101 ++
  18 files changed, 2695 insertions(+), 20 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
  create mode 100644 drivers/phy/phy-exynos-ufs.c
  create mode 100644 drivers/phy/phy-exynos-ufs.h
  create mode 100644 drivers/phy/phy-exynos7-ufs.h
  create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
  create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
  create mode 100644 drivers/scsi/ufs/ufs-exynos.c
  create mode 100644 drivers/scsi/ufs/ufs-exynos.h
  create mode 100644 include/linux/phy/phy-exynos-ufs.h


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel oops on mmotm-2015-10-15-15-20

[Hugh Dickins]

On Wed, 21 Oct 2015, Hugh Dickins wrote:
> On Thu, 22 Oct 2015, Minchan Kim wrote:
> > Hello Hugh,
> > 
> > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote:
> > > On Thu, 22 Oct 2015, Minchan Kim wrote:
> > > > 
> > > > I added the code to check it and queued it again but I had another oops
> > > > in this time but symptom is related to anon_vma, too.
> > > > (kernel is based on recent mmotm + unconditional mkdirty for bug fix)
> > > > It seems page_get_anon_vma returns NULL since the page was not 
> > > > page_mapped
> > > > at that time but second check of page_mapped right before try_to_unmap 
> > > > seems
> > > > to be true.
> > > > 
> > > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 
> > > > across:4191228k FS
> > > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 
> > > > across:4191228k FS
> > > > page:ea0001cfbfc0 count:3 mapcount:1 mapping:88007f1b5f51 
> > > > index:0x60aff
> > > > flags: 0x40048019(locked|uptodate|dirty|swapcache|swapbacked)
> > > > page dumped because: VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && 
> > > > !anon_vma)
> > > 
> > > That's interesting, that's one I added in my page migration series.
> > > Let me think on it, but it could well relate to the one you got before.

I think I have introduced a bug there; or rather, made more evident
a pre-existing bug.  But I'm not sure yet: the stacktrace was from
compaction (called by khugepaged, but that may not be relevant at all),
and thinking through the races with isolate_migratepages_block() is
never easy.

What's certain is that I was not giving any thought to
isolate_migratepages_block() when I added that VM_BUG_ON_PAGE():
I was thinking about "stable" anonymous pages, and how they get
faulted back in from swapcache while holding page lock.

It looks to me now as if a page might not yet be PageAnon when it's
first tested in __unmap_and_move(), when going to page_get_anon_vma();
but is page_mapped() and PageAnon() by time of calling try_to_unmap(),
where I inserted the VM_BUG_ON_PAGE().

If so, the code would always have been wrong (trying to unmap the
anonymous page, and later remap its replacement, without a hold on
the anon_vma needed to guide both lookups); but I'll have made it
more glaringly wrong with the VM_BUG_ON_PAGE() - let me pretend
that's a good step forward :)

There's a reference count check in isolated_migratepages_block()
before this, which would make it unlikely, but I doubt rules it out.

However... you did hit an anon_vma reference counting problem before
my migration changes went in, and Kirill had a vague suspicion that
he might be screwing up anon_vma refcounting in split_huge_page():
if he confirms that, I'd say it's more likely to be the cause of
your crash on this occasion.

Not hard to fix mine (though we'll probably have to lose the
VM_BUG_ON_PAGE on the way, so the real fix will be hidden by that
trivial fix), I just want to give the races more thought.

However it turns out, I think you have a very useful test there.

(And I've observed no PageDirty problems with your recent patchsets,
though I don't use MADV_FREE at all myself.)

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/8] mm: page_counter: let page_counter_try_charge() return bool

[Johannes Weiner]

page_counter_try_charge() currently returns 0 on success and -ENOMEM
on failure, which is surprising behavior given the function name.

Make it follow the expected pattern of try_stuff() functions that
return a boolean true to indicate success, or false for failure.

Signed-off-by: Johannes Weiner 
---
 include/linux/page_counter.h |  6 +++---
 mm/hugetlb_cgroup.c  |  3 ++-
 mm/memcontrol.c  | 11 +--
 mm/page_counter.c| 14 +++---
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
index 17fa4f8..7e62920 100644
--- a/include/linux/page_counter.h
+++ b/include/linux/page_counter.h
@@ -36,9 +36,9 @@ static inline unsigned long page_counter_read(struct 
page_counter *counter)
 
 void page_counter_cancel(struct page_counter *counter, unsigned long nr_pages);
 void page_counter_charge(struct page_counter *counter, unsigned long nr_pages);
-int page_counter_try_charge(struct page_counter *counter,
-   unsigned long nr_pages,
-   struct page_counter **fail);
+bool page_counter_try_charge(struct page_counter *counter,
+unsigned long nr_pages,
+struct page_counter **fail);
 void page_counter_uncharge(struct page_counter *counter, unsigned long 
nr_pages);
 int page_counter_limit(struct page_counter *counter, unsigned long limit);
 int page_counter_memparse(const char *buf, const char *max,
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 6a44263..d8fb10d 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -186,7 +186,8 @@ again:
}
rcu_read_unlock();
 
-   ret = page_counter_try_charge(_cg->hugepage[idx], nr_pages, );
+   if (!page_counter_try_charge(_cg->hugepage[idx], nr_pages, ))
+   ret = -ENOMEM;
css_put(_cg->css);
 done:
*ptr = h_cg;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c71fe40..a8ccdbc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2018,8 +2018,8 @@ retry:
return 0;
 
if (!do_swap_account ||
-   !page_counter_try_charge(>memsw, batch, )) {
-   if (!page_counter_try_charge(>memory, batch, ))
+   page_counter_try_charge(>memsw, batch, )) {
+   if (page_counter_try_charge(>memory, batch, ))
goto done_restock;
if (do_swap_account)
page_counter_uncharge(>memsw, batch);
@@ -2383,14 +2383,13 @@ int __memcg_kmem_charge_memcg(struct page *page, gfp_t 
gfp, int order,
 {
unsigned int nr_pages = 1 << order;
struct page_counter *counter;
-   int ret = 0;
+   int ret;
 
if (!memcg_kmem_is_active(memcg))
return 0;
 
-   ret = page_counter_try_charge(>kmem, nr_pages, );
-   if (ret)
-   return ret;
+   if (!page_counter_try_charge(>kmem, nr_pages, ))
+   return -ENOMEM;
 
ret = try_charge(memcg, gfp, nr_pages);
if (ret) {
diff --git a/mm/page_counter.c b/mm/page_counter.c
index 11b4bed..7c6a63d 100644
--- a/mm/page_counter.c
+++ b/mm/page_counter.c
@@ -56,12 +56,12 @@ void page_counter_charge(struct page_counter *counter, 
unsigned long nr_pages)
  * @nr_pages: number of pages to charge
  * @fail: points first counter to hit its limit, if any
  *
- * Returns 0 on success, or -ENOMEM and @fail if the counter or one of
- * its ancestors has hit its configured limit.
+ * Returns %true on success, or %false and @fail if the counter or one
+ * of its ancestors has hit its configured limit.
  */
-int page_counter_try_charge(struct page_counter *counter,
-   unsigned long nr_pages,
-   struct page_counter **fail)
+bool page_counter_try_charge(struct page_counter *counter,
+unsigned long nr_pages,
+struct page_counter **fail)
 {
struct page_counter *c;
 
@@ -99,13 +99,13 @@ int page_counter_try_charge(struct page_counter *counter,
if (new > c->watermark)
c->watermark = new;
}
-   return 0;
+   return true;
 
 failed:
for (c = counter; c != *fail; c = c->parent)
page_counter_cancel(c, nr_pages);
 
-   return -ENOMEM;
+   return false;
 }
 
 /**
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Alim Akhtar]

CCing Doug, Heiko and Enric Balletbo
To help us by testing on rk3288-veyron and am335x-sl50 boards.

On 10/22/2015 08:22 AM, Javier Martinez Canillas wrote:

Hello Krzysztof,

On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote:

On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,


Thanks for your feedback.

On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote:

On 22.10.2015 00:15, Javier Martinez Canillas wrote:

The pwrseq_emmc driver does a eMMC card reset before a system reboot to
allow broken or limited ROM boot-loaders (that don't have an eMMC reset
logic) to be able to read the second stage from the eMMC.

But this has to be called before a system reboot handler and while most
of them use the priority 128, there are other restart handlers (such as
the syscon-reboot one) that use a higher priority. So, use the highest
priority to make sure that the eMMC hw is reset before a system reboot.

Signed-off-by: Javier Martinez Canillas 
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Reviewed-by: Alim Akhtar 

---
Hello,

This patch was needed since a recent series from Alim [0] added
syscon reboot and poweroff support to Exynos SoCs and removed
the reset handler in the Exynos Power Management Unit (PMU) code.

But the PMU and syscon-reboot restart handler have a different
priority so [0] breaks restart when eMMC is used on these boards.

[0]: http://www.spinics.net/lists/arm-kernel/msg454396.html

So this patch must be merged before [0] to avoid regressions.

Best regards,
Javier

  drivers/mmc/core/pwrseq_emmc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c
index 137c97fb7aa8..ad4f94ec7e8d 100644
--- a/drivers/mmc/core/pwrseq_emmc.c
+++ b/drivers/mmc/core/pwrseq_emmc.c
@@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host 
*host,

/*
 * register reset handler to ensure emmc reset also from
-* emergency_reboot(), priority 129 schedules it just before
-* system reboot
+* emergency_reboot(), priority 255 is the highest priority
+* so it will be executed before any system reboot handler.
 */
pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
-   pwrseq->reset_nb.priority = 129;
+   pwrseq->reset_nb.priority = 255;


I see the problem which you are trying to solve but this may be tricker
then just kicking the number. Some of restart handlers are registered
with priority 192. I found few of such, like: at91_restart_nb,
zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too
much).



Yes, the syscon-reboot restart handler also uses a priority 192 and that
is why reboot with eMMC broke with Alim's patches since the PMU restart
handler priority is 128.


I guess they chose the "192" priority on purpose.



I tried to understand what's the policy w.r.t priority numbering for
restart handlers but only found this in the register_restart_handler
kernel-doc [0]:

/**
  * register_restart_handler - Register function to be called to reset
  *the system
  * @nb: Info about handler function to be called
  * @nb->priority:   Handler priority. Handlers should follow the
  * following guidelines for setting priorities.
  * 0:  Restart handler of last resort,
  * with limited restart capabilities
  * 128:Default restart handler; use if no other
  * restart handler is expected to be available,
  * and/or if restart functionality is
  * sufficient to restart the entire system
  * 255:Highest priority restart handler, will
  * preempt all other restart handlers

So, reading that is not clear to me if only the values 0, 128 and 255
should be used or any value from 0-255.

What's clear to me is that restart handlers to reset a specific hw block
should be called before the restart handler that resets the whole system.

The 192 seems to be used because there are other default restart handlers
that are using a prio of 128. See for example the commit that changed the
syscon-reboot prio from 128 to 192:

b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver


But were are here not talking about syscon handler but the others. Now
you will be ahead of them.



Yes, I know that. My point was that the platforms were either not using the
mmc-pwrseq-emmc or their system restart handler already had a lower priority
but that is not true for at least rk3288-veyron as you said.



So probably the 192 value was chosen because is in the middle of 128 and
255 but it seems to me a rather arbitrary value and I would prefer it to
be documented in some place.


Effectively, now the emmc handler will be executed before their

[PATCH 3/8] net: consolidate memcg socket buffer tracking and accounting

[Johannes Weiner]

The tcp memory controller has extensive provisions for future memory
accounting interfaces that won't materialize after all. Cut the code
base down to what's actually used, now and in the likely future.

- There won't be any different protocol counters in the future, so a
  direct sock->sk_memcg linkage is enough. This eliminates a lot of
  callback maze and boilerplate code, and restores most of the socket
  allocation code to pre-tcp_memcontrol state.

- There won't be a tcp control soft limit, so integrating the memcg
  code into the global skmem limiting scheme complicates things
  unnecessarily. Replace all that with simple and clear charge and
  uncharge calls--hidden behind a jump label--to account skb memory.

- The previous jump label code was an elaborate state machine that
  tracked the number of cgroups with an active socket limit in order
  to enable the skmem tracking and accounting code only when actively
  necessary. But this is overengineered: it was meant to protect the
  people who never use this feature in the first place. Simply enable
  the branches once when the first limit is set until the next reboot.

Signed-off-by: Johannes Weiner 
---
 include/linux/memcontrol.h   |  64 ---
 include/net/sock.h   | 135 +++
 include/net/tcp.h|   3 -
 include/net/tcp_memcontrol.h |   7 ---
 mm/memcontrol.c  | 101 +++--
 net/core/sock.c  |  78 ++-
 net/ipv4/sysctl_net_ipv4.c   |   1 -
 net/ipv4/tcp.c   |   3 +-
 net/ipv4/tcp_ipv4.c  |   9 +--
 net/ipv4/tcp_memcontrol.c| 147 +++
 net/ipv4/tcp_output.c|   6 +-
 net/ipv6/tcp_ipv6.c  |   3 -
 12 files changed, 136 insertions(+), 421 deletions(-)
 delete mode 100644 include/net/tcp_memcontrol.h

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 19ff87b..5b72f83 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -85,34 +85,6 @@ enum mem_cgroup_events_target {
MEM_CGROUP_NTARGETS,
 };
 
-/*
- * Bits in struct cg_proto.flags
- */
-enum cg_proto_flags {
-   /* Currently active and new sockets should be assigned to cgroups */
-   MEMCG_SOCK_ACTIVE,
-   /* It was ever activated; we must disarm static keys on destruction */
-   MEMCG_SOCK_ACTIVATED,
-};
-
-struct cg_proto {
-   struct page_counter memory_allocated;   /* Current allocated 
memory. */
-   struct percpu_counter   sockets_allocated;  /* Current number of 
sockets. */
-   int memory_pressure;
-   longsysctl_mem[3];
-   unsigned long   flags;
-   /*
-* memcg field is used to find which memcg we belong directly
-* Each memcg struct can hold more than one cg_proto, so container_of
-* won't really cut.
-*
-* The elegant solution would be having an inverse function to
-* proto_cgroup in struct proto, but that means polluting the structure
-* for everybody, instead of just for memcg users.
-*/
-   struct mem_cgroup   *memcg;
-};
-
 #ifdef CONFIG_MEMCG
 struct mem_cgroup_stat_cpu {
long count[MEM_CGROUP_STAT_NSTATS];
@@ -185,8 +157,15 @@ struct mem_cgroup {
 
/* Accounted resources */
struct page_counter memory;
+
+   /*
+* Legacy non-resource counters. In unified hierarchy, all
+* memory is accounted and limited through memcg->memory.
+* Consumer breakdown happens in the statistics.
+*/
struct page_counter memsw;
struct page_counter kmem;
+   struct page_counter skmem;
 
/* Normal memory consumption range */
unsigned long low;
@@ -246,9 +225,6 @@ struct mem_cgroup {
 */
struct mem_cgroup_stat_cpu __percpu *stat;
 
-#if defined(CONFIG_MEMCG_KMEM) && defined(CONFIG_INET)
-   struct cg_proto tcp_mem;
-#endif
 #if defined(CONFIG_MEMCG_KMEM)
 /* Index in the kmem_cache->memcg_params.memcg_caches array */
int kmemcg_id;
@@ -676,12 +652,6 @@ void mem_cgroup_count_vm_event(struct mm_struct *mm, enum 
vm_event_item idx)
 }
 #endif /* CONFIG_MEMCG */
 
-enum {
-   UNDER_LIMIT,
-   SOFT_LIMIT,
-   OVER_LIMIT,
-};
-
 #ifdef CONFIG_CGROUP_WRITEBACK
 
 struct list_head *mem_cgroup_cgwb_list(struct mem_cgroup *memcg);
@@ -707,15 +677,35 @@ static inline void mem_cgroup_wb_stats(struct 
bdi_writeback *wb,
 
 struct sock;
 #if defined(CONFIG_INET) && defined(CONFIG_MEMCG_KMEM)
+extern struct static_key_false mem_cgroup_sockets;
+static inline bool mem_cgroup_do_sockets(void)
+{
+   return static_branch_unlikely(_cgroup_sockets);
+}
 void sock_update_memcg(struct sock *sk);
 void sock_release_memcg(struct sock *sk);
+bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages);
+void mem_cgroup_uncharge_skmem(struct 

[PATCH 2/8] mm: memcontrol: export root_mem_cgroup

[Johannes Weiner]

A later patch will need this symbol in files other than memcontrol.c,
so export it now and replace mem_cgroup_root_css at the same time.

Signed-off-by: Johannes Weiner 
---
 include/linux/memcontrol.h | 3 ++-
 mm/backing-dev.c   | 2 +-
 mm/memcontrol.c| 5 ++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 805da1f..19ff87b 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -275,7 +275,8 @@ struct mem_cgroup {
struct mem_cgroup_per_node *nodeinfo[0];
/* WARNING: nodeinfo must be the last member here */
 };
-extern struct cgroup_subsys_state *mem_cgroup_root_css;
+
+extern struct mem_cgroup *root_mem_cgroup;
 
 /**
  * mem_cgroup_events - count memory events against a cgroup
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 095b23b..73ab967 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -702,7 +702,7 @@ static int cgwb_bdi_init(struct backing_dev_info *bdi)
 
ret = wb_init(>wb, bdi, 1, GFP_KERNEL);
if (!ret) {
-   bdi->wb.memcg_css = mem_cgroup_root_css;
+   bdi->wb.memcg_css = _mem_cgroup->css;
bdi->wb.blkcg_css = blkcg_root_css;
}
return ret;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a8ccdbc..e54f434 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -76,9 +76,9 @@
 struct cgroup_subsys memory_cgrp_subsys __read_mostly;
 EXPORT_SYMBOL(memory_cgrp_subsys);
 
+struct mem_cgroup *root_mem_cgroup __read_mostly;
+
 #define MEM_CGROUP_RECLAIM_RETRIES 5
-static struct mem_cgroup *root_mem_cgroup __read_mostly;
-struct cgroup_subsys_state *mem_cgroup_root_css __read_mostly;
 
 /* Whether the swap controller is active */
 #ifdef CONFIG_MEMCG_SWAP
@@ -4213,7 +4213,6 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
*parent_css)
/* root ? */
if (parent_css == NULL) {
root_mem_cgroup = memcg;
-   mem_cgroup_root_css = >css;
page_counter_init(>memory, NULL);
memcg->high = PAGE_COUNTER_MAX;
memcg->soft_limit = PAGE_COUNTER_MAX;
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/8] mm: memcontrol: hook up vmpressure to socket pressure

[Johannes Weiner]

Let the networking stack know when a memcg is under reclaim pressure,
so it can shrink its transmit windows accordingly.

Whenever the reclaim efficiency of a memcg's LRU lists drops low
enough for a MEDIUM or HIGH vmpressure event to occur, assert a
pressure state in the socket and tcp memory code that tells it to
reduce memory usage in sockets associated with said memory cgroup.

vmpressure events are edge triggered, so for hysteresis assert socket
pressure for a second to allow for subsequent vmpressure events to
occur before letting the socket code return to normal.

Signed-off-by: Johannes Weiner 
---
 include/linux/memcontrol.h |  9 +
 include/net/sock.h |  4 
 include/net/tcp.h  |  4 
 mm/memcontrol.c|  1 +
 mm/vmpressure.c| 29 -
 5 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index d66ae18..b9990f7 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -246,6 +246,7 @@ struct mem_cgroup {
 
 #ifdef CONFIG_INET
struct work_struct socket_work;
+   unsigned long socket_pressure;
 #endif
 
/* List of events which userspace want to receive */
@@ -696,6 +697,10 @@ void sock_update_memcg(struct sock *sk);
 void sock_release_memcg(struct sock *sk);
 bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages);
 void mem_cgroup_uncharge_skmem(struct mem_cgroup *memcg, unsigned int 
nr_pages);
+static inline bool mem_cgroup_socket_pressure(struct mem_cgroup *memcg)
+{
+   return time_before(jiffies, memcg->socket_pressure);
+}
 #else
 static inline bool mem_cgroup_do_sockets(void)
 {
@@ -716,6 +721,10 @@ static inline void mem_cgroup_uncharge_skmem(struct 
mem_cgroup *memcg,
 unsigned int nr_pages)
 {
 }
+static inline bool mem_cgroup_socket_pressure(struct mem_cgroup *memcg)
+{
+   return false;
+}
 #endif /* CONFIG_INET */
 
 #ifdef CONFIG_MEMCG_KMEM
diff --git a/include/net/sock.h b/include/net/sock.h
index 67795fc..22bfb9c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1087,6 +1087,10 @@ static inline bool sk_has_memory_pressure(const struct 
sock *sk)
 
 static inline bool sk_under_memory_pressure(const struct sock *sk)
 {
+   if (mem_cgroup_do_sockets() && sk->sk_memcg &&
+   mem_cgroup_socket_pressure(sk->sk_memcg))
+   return true;
+
if (!sk->sk_prot->memory_pressure)
return false;
 
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 77b6c7e..c7d342c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -291,6 +291,10 @@ extern int tcp_memory_pressure;
 /* optimized version of sk_under_memory_pressure() for TCP sockets */
 static inline bool tcp_under_memory_pressure(const struct sock *sk)
 {
+   if (mem_cgroup_do_sockets() && sk->sk_memcg &&
+   mem_cgroup_socket_pressure(sk->sk_memcg))
+   return true;
+
return tcp_memory_pressure;
 }
 /*
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cb1d6aa..2e09def 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4178,6 +4178,7 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
*parent_css)
 #endif
 #ifdef CONFIG_INET
INIT_WORK(>socket_work, socket_work_func);
+   memcg->socket_pressure = jiffies;
 #endif
return >css;
 
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
index 4c25e62..f64c0e1 100644
--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -137,14 +137,11 @@ struct vmpressure_event {
 };
 
 static bool vmpressure_event(struct vmpressure *vmpr,
-unsigned long scanned, unsigned long reclaimed)
+enum vmpressure_levels level)
 {
struct vmpressure_event *ev;
-   enum vmpressure_levels level;
bool signalled = false;
 
-   level = vmpressure_calc_level(scanned, reclaimed);
-
mutex_lock(>events_lock);
 
list_for_each_entry(ev, >events, node) {
@@ -162,6 +159,7 @@ static bool vmpressure_event(struct vmpressure *vmpr,
 static void vmpressure_work_fn(struct work_struct *work)
 {
struct vmpressure *vmpr = work_to_vmpressure(work);
+   enum vmpressure_levels level;
unsigned long scanned;
unsigned long reclaimed;
 
@@ -185,8 +183,29 @@ static void vmpressure_work_fn(struct work_struct *work)
vmpr->reclaimed = 0;
spin_unlock(>sr_lock);
 
+   level = vmpressure_calc_level(scanned, reclaimed);
+
+   if (level > VMPRESSURE_LOW) {
+   struct mem_cgroup *memcg;
+   /*
+* Let the socket buffer allocator know that we are
+* having trouble reclaiming LRU pages.
+*
+* For hysteresis, keep the pressure state asserted
+* for a second in which subsequent pressure events
+* can occur.
+*
+* XXX: 

[PATCH 6/8] mm: vmscan: simplify memcg vs. global shrinker invocation

[Johannes Weiner]

Letting shrink_slab() handle the root_mem_cgroup, and implicitely the
!CONFIG_MEMCG case, allows shrink_zone() to invoke the shrinkers
unconditionally from within the memcg iteration loop.

Signed-off-by: Johannes Weiner 
---
 include/linux/memcontrol.h |  2 ++
 mm/vmscan.c| 31 ---
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 6f1e0f8..d66ae18 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -482,6 +482,8 @@ void mem_cgroup_split_huge_fixup(struct page *head);
 #else /* CONFIG_MEMCG */
 struct mem_cgroup;
 
+#define root_mem_cgroup NULL
+
 static inline void mem_cgroup_events(struct mem_cgroup *memcg,
 enum mem_cgroup_events_index idx,
 unsigned int nr)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9b52ecf..ecc2125 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -411,6 +411,10 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
struct shrinker *shrinker;
unsigned long freed = 0;
 
+   /* Global shrinker mode */
+   if (memcg == root_mem_cgroup)
+   memcg = NULL;
+
if (memcg && !memcg_kmem_is_active(memcg))
return 0;
 
@@ -2417,11 +2421,22 @@ static bool shrink_zone(struct zone *zone, struct 
scan_control *sc,
shrink_lruvec(lruvec, swappiness, sc, _pages);
zone_lru_pages += lru_pages;
 
-   if (memcg && is_classzone)
+   /*
+* Shrink the slab caches in the same proportion that
+* the eligible LRU pages were scanned.
+*/
+   if (is_classzone) {
shrink_slab(sc->gfp_mask, zone_to_nid(zone),
memcg, sc->nr_scanned - scanned,
lru_pages);
 
+   if (reclaim_state) {
+   sc->nr_reclaimed +=
+   reclaim_state->reclaimed_slab;
+   reclaim_state->reclaimed_slab = 0;
+   }
+   }
+
/*
 * Direct reclaim and kswapd have to scan all memory
 * cgroups to fulfill the overall scan target for the
@@ -2439,20 +2454,6 @@ static bool shrink_zone(struct zone *zone, struct 
scan_control *sc,
}
} while ((memcg = mem_cgroup_iter(root, memcg, )));
 
-   /*
-* Shrink the slab caches in the same proportion that
-* the eligible LRU pages were scanned.
-*/
-   if (global_reclaim(sc) && is_classzone)
-   shrink_slab(sc->gfp_mask, zone_to_nid(zone), NULL,
-   sc->nr_scanned - nr_scanned,
-   zone_lru_pages);
-
-   if (reclaim_state) {
-   sc->nr_reclaimed += reclaim_state->reclaimed_slab;
-   reclaim_state->reclaimed_slab = 0;
-   }
-
vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
   sc->nr_scanned - nr_scanned,
   sc->nr_reclaimed - nr_reclaimed);
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/8] mm: memcontrol: account socket memory in unified hierarchy

[Johannes Weiner]

Hi,

this series adds socket buffer memory tracking and accounting to the
unified hierarchy memory cgroup controller.

[ Networking people, at this time please check the diffstat below to
  avoid going into convulsions. ]

Socket buffer memory can make up a significant share of a workload's
memory footprint, and so it needs to be accounted and tracked out of
the box, along with other types of memory that can be directly linked
to userspace activity, in order to provide useful resource isolation.

Historically, socket buffers were accounted in a separate counter,
without any pressure equalization between anonymous memory, page
cache, and the socket buffers. When the socket buffer pool was
exhausted, buffer allocations would fail hard and cause network
performance to tank, regardless of whether there was still memory
available to the group or not. Likewise, struggling anonymous or cache
workingsets could not dip into an idle socket memory pool. Because of
this, the feature was not usable for many real life applications.

To not repeat this mistake, the new memory controller will account all
types of memory pages it is tracking on behalf of a cgroup in a single
pool. And upon pressure, the VM reclaims and shrinks whatever memory
in that pool is within its reach.

These patches add accounting for memory consumed by sockets associated
with a cgroup to the existing pool of anonymous pages and page cache.

Patch #3 reworks the existing memcg socket infrastructure. It has many
provisions for future plans that won't materialize, and much of this
simply evaporates. The networking people should be happy about this.

Patch #5 adds accounting and tracking of socket memory to the unified
hierarchy memory controller, as described above. It uses the existing
per-cpu charge caches and triggers high limit reclaim asynchroneously.

Patch #8 uses the vmpressure extension to equalize pressure between
the pages tracked natively by the VM and socket buffer pages. As the
pool is shared, it makes sense that while natively tracked pages are
under duress the network transmit windows are also not increased.

As per above, this is an essential part of the new memory controller's
core functionality. With the unified hierarchy nearing release, please
consider this for 4.4.

 include/linux/memcontrol.h   |  90 +---
 include/linux/page_counter.h |   6 +-
 include/net/sock.h   | 139 ++--
 include/net/tcp.h|   5 +-
 include/net/tcp_memcontrol.h |   7 --
 mm/backing-dev.c |   2 +-
 mm/hugetlb_cgroup.c  |   3 +-
 mm/memcontrol.c  | 235 ++---
 mm/page_counter.c|  14 +--
 mm/vmpressure.c  |  29 -
 mm/vmscan.c  |  41 +++
 net/core/sock.c  |  78 --
 net/ipv4/sysctl_net_ipv4.c   |   1 -
 net/ipv4/tcp.c   |   3 +-
 net/ipv4/tcp_ipv4.c  |   9 +-
 net/ipv4/tcp_memcontrol.c| 147 --
 net/ipv4/tcp_output.c|   6 +-
 net/ipv6/tcp_ipv6.c  |   3 -
 18 files changed, 319 insertions(+), 499 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

[Johannes Weiner]

Socket memory can be a significant share of overall memory consumed by
common workloads. In order to provide reasonable resource isolation
out-of-the-box in the unified hierarchy, this type of memory needs to
be accounted and tracked per default in the memory controller.

Signed-off-by: Johannes Weiner 
---
 include/linux/memcontrol.h | 16 ++--
 mm/memcontrol.c| 95 --
 2 files changed, 87 insertions(+), 24 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 5b72f83..6f1e0f8 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -244,6 +244,10 @@ struct mem_cgroup {
struct wb_domain cgwb_domain;
 #endif
 
+#ifdef CONFIG_INET
+   struct work_struct socket_work;
+#endif
+
/* List of events which userspace want to receive */
struct list_head event_list;
spinlock_t event_list_lock;
@@ -676,11 +680,15 @@ static inline void mem_cgroup_wb_stats(struct 
bdi_writeback *wb,
 #endif /* CONFIG_CGROUP_WRITEBACK */
 
 struct sock;
-#if defined(CONFIG_INET) && defined(CONFIG_MEMCG_KMEM)
-extern struct static_key_false mem_cgroup_sockets;
+#ifdef CONFIG_INET
+extern struct static_key_true mem_cgroup_sockets;
 static inline bool mem_cgroup_do_sockets(void)
 {
-   return static_branch_unlikely(_cgroup_sockets);
+   if (mem_cgroup_disabled())
+   return false;
+   if (!static_branch_likely(_cgroup_sockets))
+   return false;
+   return true;
 }
 void sock_update_memcg(struct sock *sk);
 void sock_release_memcg(struct sock *sk);
@@ -706,7 +714,7 @@ static inline void mem_cgroup_uncharge_skmem(struct 
mem_cgroup *memcg,
 unsigned int nr_pages)
 {
 }
-#endif /* CONFIG_INET && CONFIG_MEMCG_KMEM */
+#endif /* CONFIG_INET */
 
 #ifdef CONFIG_MEMCG_KMEM
 extern struct static_key memcg_kmem_enabled_key;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 3789050..cb1d6aa 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1916,6 +1916,18 @@ static int memcg_cpu_hotplug_callback(struct 
notifier_block *nb,
return NOTIFY_OK;
 }
 
+static void reclaim_high(struct mem_cgroup *memcg,
+unsigned int nr_pages,
+gfp_t gfp_mask)
+{
+   do {
+   if (page_counter_read(>memory) <= memcg->high)
+   continue;
+   mem_cgroup_events(memcg, MEMCG_HIGH, 1);
+   try_to_free_mem_cgroup_pages(memcg, nr_pages, gfp_mask, true);
+   } while ((memcg = parent_mem_cgroup(memcg)));
+}
+
 /*
  * Scheduled by try_charge() to be executed from the userland return path
  * and reclaims memory over the high limit.
@@ -1923,20 +1935,13 @@ static int memcg_cpu_hotplug_callback(struct 
notifier_block *nb,
 void mem_cgroup_handle_over_high(void)
 {
unsigned int nr_pages = current->memcg_nr_pages_over_high;
-   struct mem_cgroup *memcg, *pos;
+   struct mem_cgroup *memcg;
 
if (likely(!nr_pages))
return;
 
-   pos = memcg = get_mem_cgroup_from_mm(current->mm);
-
-   do {
-   if (page_counter_read(>memory) <= pos->high)
-   continue;
-   mem_cgroup_events(pos, MEMCG_HIGH, 1);
-   try_to_free_mem_cgroup_pages(pos, nr_pages, GFP_KERNEL, true);
-   } while ((pos = parent_mem_cgroup(pos)));
-
+   memcg = get_mem_cgroup_from_mm(current->mm);
+   reclaim_high(memcg, nr_pages, GFP_KERNEL);
css_put(>css);
current->memcg_nr_pages_over_high = 0;
 }
@@ -4129,6 +4134,8 @@ struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup 
*memcg)
 }
 EXPORT_SYMBOL(parent_mem_cgroup);
 
+static void socket_work_func(struct work_struct *work);
+
 static struct cgroup_subsys_state * __ref
 mem_cgroup_css_alloc(struct cgroup_subsys_state *parent_css)
 {
@@ -4169,6 +4176,9 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
*parent_css)
 #ifdef CONFIG_CGROUP_WRITEBACK
INIT_LIST_HEAD(>cgwb_list);
 #endif
+#ifdef CONFIG_INET
+   INIT_WORK(>socket_work, socket_work_func);
+#endif
return >css;
 
 free_out:
@@ -4266,6 +4276,8 @@ static void mem_cgroup_css_free(struct 
cgroup_subsys_state *css)
 {
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
 
+   cancel_work_sync(>socket_work);
+
memcg_destroy_kmem(memcg);
__mem_cgroup_free(memcg);
 }
@@ -4948,10 +4960,15 @@ static void mem_cgroup_bind(struct cgroup_subsys_state 
*root_css)
 * guarantees that @root doesn't have any children, so turning it
 * on for the root memcg is enough.
 */
-   if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
+   if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) {
root_mem_cgroup->use_hierarchy = true;
-   else
+#ifdef CONFIG_INET
+   /* unified hierarchy always counts skmem */
+   static_branch_enable(_cgroup_sockets);
+#endif

[PATCH 4/8] mm: memcontrol: prepare for unified hierarchy socket accounting

[Johannes Weiner]

The unified hierarchy memory controller will account socket
memory. Move the infrastructure functions accordingly.

Signed-off-by: Johannes Weiner 
---
 mm/memcontrol.c | 136 
 1 file changed, 68 insertions(+), 68 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c41e6d7..3789050 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -287,74 +287,6 @@ static inline struct mem_cgroup 
*mem_cgroup_from_id(unsigned short id)
return mem_cgroup_from_css(css);
 }
 
-/* Writing them here to avoid exposing memcg's inner layout */
-#if defined(CONFIG_INET) && defined(CONFIG_MEMCG_KMEM)
-
-DEFINE_STATIC_KEY_FALSE(mem_cgroup_sockets);
-
-void sock_update_memcg(struct sock *sk)
-{
-   struct mem_cgroup *memcg;
-   /*
-* Socket cloning can throw us here with sk_cgrp already
-* filled. It won't however, necessarily happen from
-* process context. So the test for root memcg given
-* the current task's memcg won't help us in this case.
-*
-* Respecting the original socket's memcg is a better
-* decision in this case.
-*/
-   if (sk->sk_memcg) {
-   BUG_ON(mem_cgroup_is_root(sk->sk_memcg));
-   css_get(>sk_memcg->css);
-   return;
-   }
-
-   rcu_read_lock();
-   memcg = mem_cgroup_from_task(current);
-   if (css_tryget_online(>css))
-   sk->sk_memcg = memcg;
-   rcu_read_unlock();
-}
-EXPORT_SYMBOL(sock_update_memcg);
-
-void sock_release_memcg(struct sock *sk)
-{
-   if (sk->sk_memcg)
-   css_put(>sk_memcg->css);
-}
-
-/**
- * mem_cgroup_charge_skmem - charge socket memory
- * @memcg: memcg to charge
- * @nr_pages: number of pages to charge
- *
- * Charges @nr_pages to @memcg. Returns %true if the charge fit within
- * the memcg's configured limit, %false if the charge had to be forced.
- */
-bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages)
-{
-   struct page_counter *counter;
-
-   if (page_counter_try_charge(>skmem, nr_pages, ))
-   return true;
-
-   page_counter_charge(>skmem, nr_pages);
-   return false;
-}
-
-/**
- * mem_cgroup_uncharge_skmem - uncharge socket memory
- * @memcg: memcg to uncharge
- * @nr_pages: number of pages to uncharge
- */
-void mem_cgroup_uncharge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages)
-{
-   page_counter_uncharge(>skmem, nr_pages);
-}
-
-#endif
-
 #ifdef CONFIG_MEMCG_KMEM
 /*
  * This will be the memcg's index in each cache's ->memcg_params.memcg_caches.
@@ -5521,6 +5453,74 @@ void mem_cgroup_replace_page(struct page *oldpage, 
struct page *newpage)
commit_charge(newpage, memcg, true);
 }
 
+/* Writing them here to avoid exposing memcg's inner layout */
+#if defined(CONFIG_INET) && defined(CONFIG_MEMCG_KMEM)
+
+DEFINE_STATIC_KEY_FALSE(mem_cgroup_sockets);
+
+void sock_update_memcg(struct sock *sk)
+{
+   struct mem_cgroup *memcg;
+   /*
+* Socket cloning can throw us here with sk_cgrp already
+* filled. It won't however, necessarily happen from
+* process context. So the test for root memcg given
+* the current task's memcg won't help us in this case.
+*
+* Respecting the original socket's memcg is a better
+* decision in this case.
+*/
+   if (sk->sk_memcg) {
+   BUG_ON(mem_cgroup_is_root(sk->sk_memcg));
+   css_get(>sk_memcg->css);
+   return;
+   }
+
+   rcu_read_lock();
+   memcg = mem_cgroup_from_task(current);
+   if (css_tryget_online(>css))
+   sk->sk_memcg = memcg;
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(sock_update_memcg);
+
+void sock_release_memcg(struct sock *sk)
+{
+   if (sk->sk_memcg)
+   css_put(>sk_memcg->css);
+}
+
+/**
+ * mem_cgroup_charge_skmem - charge socket memory
+ * @memcg: memcg to charge
+ * @nr_pages: number of pages to charge
+ *
+ * Charges @nr_pages to @memcg. Returns %true if the charge fit within
+ * the memcg's configured limit, %false if the charge had to be forced.
+ */
+bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages)
+{
+   struct page_counter *counter;
+
+   if (page_counter_try_charge(>skmem, nr_pages, ))
+   return true;
+
+   page_counter_charge(>skmem, nr_pages);
+   return false;
+}
+
+/**
+ * mem_cgroup_uncharge_skmem - uncharge socket memory
+ * @memcg: memcg to uncharge
+ * @nr_pages: number of pages to uncharge
+ */
+void mem_cgroup_uncharge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages)
+{
+   page_counter_uncharge(>skmem, nr_pages);
+}
+
+#endif
+
 /*
  * subsys_initcall() for memory controller.
  *
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH 7/8] mm: vmscan: report vmpressure at the level of reclaim activity

[Johannes Weiner]

The vmpressure metric is based on reclaim efficiency, which in turn is
an attribute of the LRU. However, vmpressure events are currently
reported at the source of pressure rather than at the reclaim level.

Switch the reporting to the reclaim level to allow finer-grained
analysis of which memcg is having trouble reclaiming its pages.

As far as memory.pressure_level interface semantics go, events are
escalated up the hierarchy until a listener is found, so this won't
affect existing users that listen at higher levels.

This also prepares vmpressure for hooking it up to the networking
stack's memory pressure code.

Signed-off-by: Johannes Weiner 
---
 mm/vmscan.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index ecc2125..50630c8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2404,6 +2404,7 @@ static bool shrink_zone(struct zone *zone, struct 
scan_control *sc,
memcg = mem_cgroup_iter(root, NULL, );
do {
unsigned long lru_pages;
+   unsigned long reclaimed;
unsigned long scanned;
struct lruvec *lruvec;
int swappiness;
@@ -2416,6 +2417,7 @@ static bool shrink_zone(struct zone *zone, struct 
scan_control *sc,
 
lruvec = mem_cgroup_zone_lruvec(zone, memcg);
swappiness = mem_cgroup_swappiness(memcg);
+   reclaimed = sc->nr_reclaimed;
scanned = sc->nr_scanned;
 
shrink_lruvec(lruvec, swappiness, sc, _pages);
@@ -2437,6 +2439,10 @@ static bool shrink_zone(struct zone *zone, struct 
scan_control *sc,
}
}
 
+   vmpressure(sc->gfp_mask, memcg,
+  sc->nr_scanned - scanned,
+  sc->nr_reclaimed - reclaimed);
+
/*
 * Direct reclaim and kswapd have to scan all memory
 * cgroups to fulfill the overall scan target for the
@@ -2454,10 +2460,6 @@ static bool shrink_zone(struct zone *zone, struct 
scan_control *sc,
}
} while ((memcg = mem_cgroup_iter(root, memcg, )));
 
-   vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
-  sc->nr_scanned - nr_scanned,
-  sc->nr_reclaimed - nr_reclaimed);
-
if (sc->nr_reclaimed - nr_reclaimed)
reclaimable = true;
 
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] TTY, devpts: document pty count limiting

[Eric W. Biederman]

Greg KH  writes:

> On Wed, Oct 21, 2015 at 01:08:54PM +0300, Konstantin Khlebnikov wrote:
>> Logic was changed in kernel 3.4 by commit e9aba5158a80 ("tty: rework pty
>> count limiting") but still isn't documented. Better late than never.
>> 
>> Signed-off-by: Konstantin Khlebnikov 
>> ---
>>  Documentation/filesystems/devpts.txt |9 +
>>  Documentation/sysctl/kernel.txt  |7 +++
>>  2 files changed, 16 insertions(+)
>
> Any reason you didn't cc: the tty maintainer on this?

It looks like he attempted to and managed to get your old suse.de
address.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH block/for-4.4/core] blkcg: don't create "io.stat" on the root cgroup

[Jens Axboe]

On 10/21/2015 06:31 PM, Tejun Heo wrote:

Hello, Jens.

This is one of hopefully final adjustments to cgroup v2 behavior
before lifting the devel mask.  If the patch is okay, can I route the
patch through cgroup/for-4.4 so that it can go together with the
cgroup documentation update patch?


Yep that's fine, you can add my acked-by as well.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pcnet32: fix a logic error with pci_set_dma_mask

[Don Fry]

On Mon, 2015-10-12 at 05:38 -0700, David Miller wrote:
> From: Geliang Tang 
> Date: Fri,  9 Oct 2015 03:45:39 -0700
> 
> > pcnet32 can't work on my machine recently. It says "architecture
> > does not support 32bit PCI busmaster DMA". There is a logic error
> > in it: pci_set_dma_mask() return 0 means return successfully.
> > 
> > Signed-off-by: Geliang Tang 
> 
> This driver doesn't call pci_set_dma_mask() in any of my tree(s).
I failed.  My system with pcnet32 boards was down with a dead power
supply and a visual review was not good enough.  I missed that
pci_dma_supported returns 1 on success and pci_set_dma_mask returns 0 on
success.  The original patch needs to have the ! removed as Geliang Tang
points out.

Acked-by:  Don Fry 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] serial: earlycon: allow to specify uartclk in earlycon kernel-parameter

[Masahiro Yamada]

Hi Peter,

2015-10-22 0:35 GMT+09:00 Peter Hurley :
> Hi Masahiro,
>
> On 10/21/2015 11:31 AM, Masahiro Yamada wrote:
>> If it is always correct to preserve the initialization done by boot-loader,
>> the following code in 8250_early.c does not make sense.
>
> It's not always correct to preserve the initialization by the bootloader.
> For example, on my legacy x86 workstation, the bootloader does not
> initialize the h/w so when I want 8250 earlycon, I must specify the
> baud rate.

So, the input clock on the machine matches the following macro.

#define BASE_BAUD (1843200/16)


For ARM boards, we should depend on a boot loader.
Is this what you mean?

-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH v2 1/2] dt-bindings: rockchip-thermal: Add the "init" pinctrl in this document

[Caesar Wang]

在 2015年10月22日 11:45, Doug Anderson 写道:

Caesar,

On Wed, Oct 21, 2015 at 7:30 PM, Caesar Wang  wrote:

The "init" pinctrl is defined we'll set
pinctrl to this state before probe and then "default" after probe.

Add the "init" pinctrl as the OTP gpio state, since we need switch
the pin to gpio state before the TSADC controller is reset.

As I know, the TSADC controller is reset, the tshut polarity will be
a *low* signal in a short period of time for some devices.

Says:
The TSADC get the temperature on rockchip thermal.

If T(current temperature) < (setting temperature), the OTP output the
*high* signal.
If T(current temperature) > (setting temperature), the OTP output the
*low* Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the
PMIC can accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the
OTP pin is connected the others IC to control the power.

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v2:
   - Add the 'init' pinctrl more decription in commit.
   - Fix the subject to make more obvious in PATCH[1/2]
   - Resend this patch v2 since fix the subject to be specific.

Changes in v1:
   - As the Doug comments, add the 'init' property to sync document.

  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..28e84f7 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

I think Rob wanted something more in the "rockchip-thermal.txt"
document itself.  Like:

Pinctrl states:
- During device probe a driver may glitch the output line.  If this is
not acceptable for your board, you can use the standard "init" and
"default" pinctrl states.  The "init" state will be set before device
probe and "default" after.


Sound resonable.
Thanks Doug to explain!



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 03/60] sparc/PCI: Unify pci_register_region()

[Benjamin Herrenschmidt]

On Wed, 2015-10-21 at 18:27 -0700, David Miller wrote:
> From: Yinghai Lu 
> Date: Wed, 21 Oct 2015 11:16:53 -0700
> 
> > otherwise we need to compare res with pbm->mem_space or pbm
> ->mem64_space
> > to get direct parent for request_resource_conflict() calling in
> > pci_register_legacy_regions().
> 
> Right, this is the issue.
> 
> On sparc64, the cpu physical base address used for accessing 64-bit
> and non-64-bit memory spaces is different.
> 
> And that's why the resource values will be different.

This is the same on power btw, we have separate PowerBus windows to the
PHB that get mapped respectively to 32-bit PCI MMIO and 64-bit PCI
MMIO. The former gets "remapped" to generates 0-based PCI cycles, while
the latter is 1:1. So the offset between CPU and PCI changes depending
on which window you hit.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH v2 1/2] dt-bindings: rockchip-thermal: Add the "init" pinctrl in this document

[Doug Anderson]

Caesar,

On Wed, Oct 21, 2015 at 7:30 PM, Caesar Wang  wrote:
> The "init" pinctrl is defined we'll set
> pinctrl to this state before probe and then "default" after probe.
>
> Add the "init" pinctrl as the OTP gpio state, since we need switch
> the pin to gpio state before the TSADC controller is reset.
>
> As I know, the TSADC controller is reset, the tshut polarity will be
> a *low* signal in a short period of time for some devices.
>
> Says:
> The TSADC get the temperature on rockchip thermal.
>
> If T(current temperature) < (setting temperature), the OTP output the
> *high* signal.
> If T(current temperature) > (setting temperature), the OTP output the
> *low* Signal.
>
> In some cases, the OTP pin is connected to the PMIC, maybe the
> PMIC can accept the reset response time to avoid this issue.
>
> In other words, the system will be always reboot if we make the
> OTP pin is connected the others IC to control the power.
>
> Signed-off-by: Caesar Wang 
> Reviewed-by: Douglas Anderson 
> ---
>
> Changes in v2:
>   - Add the 'init' pinctrl more decription in commit.
>   - Fix the subject to make more obvious in PATCH[1/2]
>   - Resend this patch v2 since fix the subject to be specific.
>
> Changes in v1:
>   - As the Doug comments, add the 'init' property to sync document.
>
>  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> index ef802de..28e84f7 100644
> --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

I think Rob wanted something more in the "rockchip-thermal.txt"
document itself.  Like:

Pinctrl states:
- During device probe a driver may glitch the output line.  If this is
not acceptable for your board, you can use the standard "init" and
"default" pinctrl states.  The "init" state will be set before device
probe and "default" after.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 4/4] mmc: sdhci-of-arasan: add runtime pm support

[Shawn Lin]

This patch add runtime_suspend and runtime_resume for
sdhci-of-arasan. Currently we also power-off phy at
runtime_suspend for power-saving.

Signed-off-by: Shawn Lin 

Serise-changes: 4
- remove ifdef for PM callback statement
- fix missing pm_runtime_set_active
- remove pm_runtime_dont_use_autosuspend from remove hook
- add pm_runtime_force_suspend|resume for PM callback to
  deal with suspend invoked from rpm
- remove wrappers of phy ops

---

Changes in v2: None

 drivers/mmc/host/sdhci-of-arasan.c | 85 --
 1 file changed, 82 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 2d327d4..b044df7 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -30,6 +30,8 @@
 #define CLK_CTRL_TIMEOUT_MASK  (0xf << CLK_CTRL_TIMEOUT_SHIFT)
 #define CLK_CTRL_TIMEOUT_MIN_EXP   13
 
+#define ARASAN_RPM_DELAY_MS50
+
 /**
  * struct sdhci_arasan_data
  * @clk_ahb:   Pointer to the AHB clock
@@ -71,6 +73,46 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN,
 };
 
+#ifdef CONFIG_PM
+static int sdhci_arasan_runtime_suspend(struct device *dev)
+{
+   struct sdhci_host *host = dev_get_drvdata(dev);
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+   int ret;
+
+   ret = sdhci_runtime_suspend_host(host);
+   if (ret)
+   return ret;
+
+   if (!IS_ERR(sdhci_arasan->phy))
+   phy_power_off(sdhci_arasan->phy);
+
+   clk_disable_unprepare(sdhci_arasan->clk_ahb);
+   clk_disable_unprepare(pltfm_host->clk);
+
+   return 0;
+}
+
+static int sdhci_arasan_runtime_resume(struct device *dev)
+{
+   struct sdhci_host *host = dev_get_drvdata(dev);
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+
+   clk_prepare_enable(pltfm_host->clk);
+   clk_prepare_enable(sdhci_arasan->clk_ahb);
+
+   if (!IS_ERR(sdhci_arasan->phy))
+   phy_power_on(sdhci_arasan->phy);
+
+   return sdhci_runtime_resume_host(host);
+}
+#else
+#define sdhci_arasan_runtime_suspend NULL
+#define sdhci_arasan_runtime_resume NULL
+#endif
+
 #ifdef CONFIG_PM_SLEEP
 /**
  * sdhci_arasan_suspend - Suspend method for the driver
@@ -87,6 +129,12 @@ static int sdhci_arasan_suspend(struct device *dev)
struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
int ret;
 
+   ret = pm_runtime_force_suspend(dev);
+   if (ret) {
+   dev_err(dev, "problem force suspending\n");
+   return ret;
+   }
+
ret = sdhci_suspend_host(host);
if (ret)
return ret;
@@ -140,18 +188,39 @@ static int sdhci_arasan_resume(struct device *dev)
}
}
 
-   return sdhci_resume_host(host);
+   ret = sdhci_resume_host(host);
+   if (ret)
+   goto err_resume_host;
+
+   ret = pm_runtime_force_resume(dev);
+   if (ret) {
+   dev_err(dev, "problem force resuming\n");
+   goto err_force_resume;
+   }
+
+   return 0;
 
+err_force_resume:
+   sdhci_suspend_host(host);
+err_resume_host:
+   if (!IS_ERR(sdhci_arasan->phy))
+   phy_power_off(sdhci_arasan->phy);
 err_phy_power:
clk_disable_unprepare(pltfm_host->clk);
 err_clk_en:
clk_disable_unprepare(sdhci_arasan->clk_ahb);
return ret;
 }
+#else
+#define sdhci_arasan_suspend NULL
+#define sdhci_arasan_resume NULL
 #endif /* ! CONFIG_PM_SLEEP */
 
-static SIMPLE_DEV_PM_OPS(sdhci_arasan_dev_pm_ops, sdhci_arasan_suspend,
-sdhci_arasan_resume);
+static const struct dev_pm_ops sdhci_arasan_dev_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(sdhci_arasan_suspend, sdhci_arasan_resume)
+   SET_RUNTIME_PM_OPS(sdhci_arasan_runtime_suspend,
+   sdhci_arasan_runtime_resume, NULL)
+};
 
 static int sdhci_arasan_probe(struct platform_device *pdev)
 {
@@ -237,6 +306,12 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
}
}
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_set_autosuspend_delay(>dev, ARASAN_RPM_DELAY_MS);
+   pm_runtime_use_autosuspend(>dev);
+   pm_runtime_enable(>dev);
+   pm_suspend_ignore_children(>dev, 1);
+
ret = sdhci_add_host(host);
if (ret)
goto err_pltfm_free;
@@ -244,6 +319,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
return 0;
 
 err_pltfm_free:
+   pm_runtime_disable(>dev);
sdhci_pltfm_free(pdev);
 err_phy_power:
if (!IS_ERR(sdhci_arasan->phy))
@@ -265,6 +341,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
if (!IS_ERR(sdhci_arasan->phy))

[PATCH v4 3/4] mmc: sdhci-of-arasan: fix clk prepare and unprepare for PM callback

[Shawn Lin]

This patch use clk_prepare_enable and clk_disable_unprepare for
system PM callback instead of directly use clk_enable and clk_disable
without clk_prepare/unprepare.

Signed-off-by: Shawn Lin 
---

Changes in v2: None

 drivers/mmc/host/sdhci-of-arasan.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 4f30716..2d327d4 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -99,8 +99,8 @@ static int sdhci_arasan_suspend(struct device *dev)
}
}
 
-   clk_disable(pltfm_host->clk);
-   clk_disable(sdhci_arasan->clk_ahb);
+   clk_disable_unprepare(pltfm_host->clk);
+   clk_disable_unprepare(sdhci_arasan->clk_ahb);
 
return 0;
 }
@@ -120,13 +120,13 @@ static int sdhci_arasan_resume(struct device *dev)
struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
int ret;
 
-   ret = clk_enable(sdhci_arasan->clk_ahb);
+   ret = clk_prepare_enable(sdhci_arasan->clk_ahb);
if (ret) {
dev_err(dev, "Cannot enable AHB clock.\n");
return ret;
}
 
-   ret = clk_enable(pltfm_host->clk);
+   ret = clk_prepare_enable(pltfm_host->clk);
if (ret) {
dev_err(dev, "Cannot enable SD clock.\n");
goto err_clk_en;
@@ -143,9 +143,9 @@ static int sdhci_arasan_resume(struct device *dev)
return sdhci_resume_host(host);
 
 err_phy_power:
-   clk_disable(pltfm_host->clk);
+   clk_disable_unprepare(pltfm_host->clk);
 err_clk_en:
-   clk_disable(sdhci_arasan->clk_ahb);
+   clk_disable_unprepare(sdhci_arasan->clk_ahb);
return ret;
 }
 #endif /* ! CONFIG_PM_SLEEP */
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/4] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan

[Shawn Lin]

This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Also we add pm ops for PHY here if CONFIG_PM_SLEEP is enabled.
Currently, it's just mandatory for arasan,sdhci-5.1.

Signed-off-by: Shawn Lin 

Serise-changes: 4
- remove suspend/resume_phy
- add err handle label for system PM callback
- fix comments of struct sdhci_arasan_data and system PM
  callback suggested by Michal

Serise-changes: 3
- remove phy_init/exit for suspend/resume
- adjust phy_int/power_on seq to make code more reasonable
- simplify suspend/resume_phy

Serise-changes: 2
- Keep phy as a mandatory requirement for arasan,sdhci-5.1

---

Changes in v2: None

 drivers/mmc/host/sdhci-of-arasan.c | 63 +++---
 1 file changed, 59 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 75379cb..4f30716 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include "sdhci-pltfm.h"
 
 #define SDHCI_ARASAN_CLK_CTRL_OFFSET   0x2c
@@ -32,9 +33,11 @@
 /**
  * struct sdhci_arasan_data
  * @clk_ahb:   Pointer to the AHB clock
+ * @phy: Pointer to the generic phy
  */
 struct sdhci_arasan_data {
struct clk  *clk_ahb;
+   struct phy  *phy;
 };
 
 static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host)
@@ -72,7 +75,7 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
 /**
  * sdhci_arasan_suspend - Suspend method for the driver
  * @dev:   Address of the device structure
- * Returns 0 on success and error value on error
+ * Return: 0 on success and error value on error
  *
  * Put the device in a low power state.
  */
@@ -88,6 +91,14 @@ static int sdhci_arasan_suspend(struct device *dev)
if (ret)
return ret;
 
+   if (!IS_ERR(sdhci_arasan->phy)) {
+   ret = phy_power_off(sdhci_arasan->phy);
+   if (ret) {
+   dev_err(dev, "Cannot suspend phy.\n");
+   return ret;
+   }
+   }
+
clk_disable(pltfm_host->clk);
clk_disable(sdhci_arasan->clk_ahb);
 
@@ -97,7 +108,7 @@ static int sdhci_arasan_suspend(struct device *dev)
 /**
  * sdhci_arasan_resume - Resume method for the driver
  * @dev:   Address of the device structure
- * Returns 0 on success and error value on error
+ * Return: 0 on success and error value on error
  *
  * Resume operation after suspend
  */
@@ -118,11 +129,24 @@ static int sdhci_arasan_resume(struct device *dev)
ret = clk_enable(pltfm_host->clk);
if (ret) {
dev_err(dev, "Cannot enable SD clock.\n");
-   clk_disable(sdhci_arasan->clk_ahb);
-   return ret;
+   goto err_clk_en;
+   }
+
+   if (!IS_ERR(sdhci_arasan->phy)) {
+   ret = phy_power_on(sdhci_arasan->phy);
+   if (ret) {
+   dev_err(dev, "Cannot resume phy.\n");
+   goto err_phy_power;
+   }
}
 
return sdhci_resume_host(host);
+
+err_phy_power:
+   clk_disable(pltfm_host->clk);
+err_clk_en:
+   clk_disable(sdhci_arasan->clk_ahb);
+   return ret;
 }
 #endif /* ! CONFIG_PM_SLEEP */
 
@@ -188,6 +212,31 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
goto clk_disable_all;
}
 
+   sdhci_arasan->phy = ERR_PTR(-ENODEV);
+   if (of_device_is_compatible(pdev->dev.of_node,
+   "arasan,sdhci-5.1")) {
+   sdhci_arasan->phy = devm_phy_get(>dev,
+"phy_arasan");
+   if (IS_ERR(sdhci_arasan->phy)) {
+   ret = PTR_ERR(sdhci_arasan->phy);
+   dev_err(>dev, "No phy for arasan,sdhci-5.1.\n");
+   goto clk_disable_all;
+   }
+
+   ret = phy_init(sdhci_arasan->phy);
+   if (ret < 0) {
+   dev_err(>dev, "phy_init err.\n");
+   goto clk_disable_all;
+   }
+
+   ret = phy_power_on(sdhci_arasan->phy);
+   if (ret < 0) {
+   dev_err(>dev, "phy_power_on err.\n");
+   phy_exit(sdhci_arasan->phy);
+   goto err_phy_power;
+   }
+   }
+
ret = sdhci_add_host(host);
if (ret)
goto err_pltfm_free;
@@ -196,6 +245,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
 
 err_pltfm_free:
sdhci_pltfm_free(pdev);
+err_phy_power:
+   if (!IS_ERR(sdhci_arasan->phy))
+   phy_exit(sdhci_arasan->phy);
 clk_disable_all:
clk_disable_unprepare(clk_xin);
 clk_dis_ahb:
@@ -210,6 +262,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
struct 

[PATCH v4 1/4] Documentation: bindings: add description of phy for sdhci-of-arasan

[Shawn Lin]

This patch adds phys and phy-names for sdhci-of-arasan as required
properties for arasan,sdhci-5.1, and details the example as well.

Signed-off-by: Shawn Lin 

---

Changes in v2:
- Keep phy as a mandatory requirement for arasan,sdhci-5.1

 .../devicetree/bindings/mmc/arasan,sdhci.txt | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index da541c3..31b35c3 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,11 +1,12 @@
 Device Tree Bindings for the Arasan SDHCI Controller
 
-  The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
-  deviations are documented here.
+  The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+  Only deviations are documented here.
 
   [1] Documentation/devicetree/bindings/mmc/mmc.txt
   [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
   [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+  [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
 
 Required Properties:
   - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
@@ -17,6 +18,10 @@ Required Properties:
   - interrupt-parent: Phandle for the interrupt controller that services
  interrupts for this device.
 
+Required Properties for "arasan,sdhci-5.1":
+  - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
+  - phy-names:  MUST be "phy_arasan".
+
 Example:
sdhci@e010 {
compatible = "arasan,sdhci-8.9a";
@@ -26,3 +31,14 @@ Example:
interrupt-parent = <>;
interrupts = <0 24 4>;
} ;
+
+   sdhci@e280 {
+   compatible = "arasan,sdhci-5.1";
+   reg = <0xe280 0x1000>;
+   clock-names = "clk_xin", "clk_ahb";
+   clocks = < 8>, < 18>;
+   interrupt-parent = <>;
+   interrupts = <0 24 4>;
+   phys = <_phy>;
+   phy-names = "phy_arasan";
+   } ;
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Fixed Trivial Warnings in file: Deleted Spaces prior to tabs, and added lines. modified: kernel/auditfilter.c

[Scott Matheina]

On 10/21/2015 09:15 PM, Richard Guy Briggs wrote:
> On 15/10/21, Scott Matheina wrote:
>> On 10/21/2015 10:33 AM, Richard Guy Briggs wrote:
>>> On 15/10/21, Joe Perches wrote:
 On Mon, 2015-10-19 at 12:10 -0400, Richard Guy Briggs wrote:
> On 15/10/18, Scott Matheina wrote:
>> On 10/14/2015 04:54 PM, Paul Moore wrote:
>>> On Saturday, October 10, 2015 08:57:55 PM Scott Matheina wrote:
 []
 diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
 []
 @@ -109,6 +109,7 @@ void audit_free_rule_rcu(struct rcu_head *head)
  {
struct audit_entry *e = container_of(head, struct audit_entry, 
 rcu);
audit_free_rule(e);
 +
  }
>>> Why?
>> I was following the error messages in checkpatch.pl, but the warning
>> went away after adding this line. No problem with the code. 
> That sounds like a bug in checkpatch.pl, since that blank line should be
> tween the declaration and the function call.
 checkpatch message asks for a blank line after the
 "struct audit_entry *e = ..." declaration.
>>> Well then maybe it is a bug in his interpretation of the output of
>>> checkpatch.pl?  Scott, did you re-run checkpatch.pl after adding those
>>> spaces?  Did it pass?
>> The error did go away. 
> Joe, I confirm the error went away.  Looks like a bug in checkpatch.pl
> to me.  I tried a number of combinations of things and it didn't
> complain about several things it should have.  I did try a few other
> things to make sure it was still finding problems like brace placement
> and leading spaces, but it looks like the blank line checking code isn't
> working.  This is on 4.0, so maybe it has been fixed since then.  Scott,
> what kernel version are you using?
I'm running Ubuntu 14.04 LTS (Kernel 3.19.0-30-generic) on my machine.

I cloned Linus' repo for source code. I'm pretty sure you were talking about 
the active Kernel on my machine, so if not please let me know.
>
while (*list != ~0U) {
 +
unsigned n = *list++;
if (n >= AUDIT_BITMASK_SIZE * 32 - 
 AUDIT_SYSCALL_CLASSES) {
kfree(p);
>>> Why?
>> This is the same as above. Just going through the checkpatch.pl
>> script, and looking for warnings to fix. 
> Again, another manifestation of that bug?  That blank line should be
> after the declaration and before the if statement.
 []
> Well, I agree, you have to start somewhere...  Too bad you hit a bug in
> checkpatch.pl!
 Here too, not a bug in checkpatch.

 checkpatch output asks for a blank line after the
 "unsigned n" declaration, not before.
>>> - RGB
> - RGB
>
> --
> Richard Guy Briggs 
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, 
> Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Alexei Starovoitov]

On 10/21/15 8:12 PM, Wangnan (F) wrote:



On 2015/10/22 11:09, Alexei Starovoitov wrote:

On 10/21/15 6:56 PM, Wangnan (F) wrote:

One alternative solution I can image is to attach a BPF program
at sampling like kprobe, and return 0 if we don't want sampling
take action. Thought?


Do you think attaching BPF programs to sampling is an acceptable idea?


If you mean to extend 'filter' concept to sampling events?
So instead of soft_disable of non-local events, you'll attach bpf
program to sampling events and use map lookup to decide whether
to filter out or not such sampling event?


Yes.


What pt_regs would be in such case?



Sampling is based on interruption. We can use pt_reg captured by the IRQ
handler,
or we can simply pass NULL to those BPF program.


NULL is obviously not ok. Try to answer yourself 'why it's not'.
Clean implementation should add single 'if (..->prog)' to event sampling
critical path. Please don't rush it and think it through.
but the first thing first, please see my fix for bpf_perf_event_read:
http://patchwork.ozlabs.org/patch/534120/
and ack it if it makes sense.
we need to make sure existing stuff is solid, before going further.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 15/15] HMM: add documentation explaining HMM internals and how to use it.

[Randy Dunlap]

Hi,

Some corrections and a few questions...

On 10/21/15 14:00, Jérôme Glisse wrote:
> This add documentation on how HMM works and a more in depth view of how it
> should be use by device driver writers.
> 
> Signed-off-by: Jérôme Glisse 
> ---
>  Documentation/vm/hmm.txt | 219 
> +++
>  1 file changed, 219 insertions(+)
>  create mode 100644 Documentation/vm/hmm.txt
> 
> diff --git a/Documentation/vm/hmm.txt b/Documentation/vm/hmm.txt
> new file mode 100644
> index 000..febed50
> --- /dev/null
> +++ b/Documentation/vm/hmm.txt
> @@ -0,0 +1,219 @@
> +Heterogeneous Memory Management (HMM)
> +-
> +
> +The raison d'�tre of HMM is to provide a common API for device driver that

drivers

> +wants to mirror a process address space on there device and/or migrate system

   want   their

> +memory to device memory. Device driver can decide to only use one aspect of

   drivers

> +HMM (mirroring or memory migration), for instance some device can directly
> +access process address space through hardware (for instance PCIe ATS/PASID),
> +but still want to benefit from memory migration capabilities that HMM offer.
> +
> +While HMM rely on existing kernel infrastructure (namely mmu_notifier) some

 relies

> +of its features (memory migration, atomic access) require integration with
> +core mm kernel code. Having HMM as the common intermediary is more appealing

MM

> +than having each device driver hooking itself inside the common mm code.

   MM

> +
> +Moreover HMM as a layer allows integration with DMA API or page reclaimation.

   reclamation.

> +
> +
> +Mirroring address space on the device:
> +--
> +
> +Device that can't directly access transparently the process address space, 
> need
> +to mirror the CPU page table into there own page table. HMM helps to keep the

 their

> +device page table synchronize with the CPU page table. It is not expected 
> that

 synchronized

> +the device will fully mirror the CPU page table but only mirror region that 
> are

   regions

> +actively accessed by the device. For that reasons HMM only helps populating 
> and

 reason

> +synchronizing device page table for range that the device driver explicitly 
> ask

   ranges  
asks

or is only one range supported?


> +for.
> +
> +Mirroring address space inside the device page table is easy with HMM :

 HMM:

> +
> +  /* Create a mirror for the current process for your device. */
> +  your_hmm_mirror->hmm_mirror.device = your_hmm_device;
> +  hmm_mirror_register(_hmm_mirror->hmm_mirror);
> +
> +  ...
> +
> +  /* Mirror memory (in read mode) between addressA and addressB */
> +  your_hmm_event->hmm_event.start = addressA;
> +  your_hmm_event->hmm_event.end = addressB;

Multiple events (ranges) can be specified?
Is hmm_event.end (addressB) included or excluded from the range?

> +  your_hmm_event->hmm_event.etype = HMM_DEVICE_RFAULT;
> +  hmm_mirror_fault(_hmm_mirror->hmm_mirror, _hmm_event->hmm_event);
> +/* HMM callback into your driver with the >update() callback. During the
> + * callback use the HMM page table to populate the device page table. You
> + * can only use the HMM page table to populate the device page table for
> + * the specified range during the >update() callback, at any other point 
> in
> + * time the HMM page table content should be assume to be undefined.

assumed

> + */
> +your_hmm_device->update(mirror, event);
> +
> +  ...
> +
> +  /* Process is quiting or device done stop the mirroring and cleanup. */

   quitting or device done; stop

> +  hmm_mirror_unregister(_hmm_mirror->hmm_mirror);
> +  /* Device driver can free your_hmm_mirror */
> +
> +
> +HMM mirror page table:
> +--
> +
> +Each hmm_mirror object is associated with a mirror page table that HMM keeps
> +synchronize with the CPU page table by using the mmu_notifier API. HMM is 
> using

   synchronized

> +its own generic page table format because it needs to store DMA address, 
> which

   adresses,

> +are bigger than long on some architecture, and have more flags per entry than

architectures,

> +radix tree allows.
> +
> +The HMM page 

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Wangnan (F)]

On 2015/10/22 11:09, Alexei Starovoitov wrote:

On 10/21/15 6:56 PM, Wangnan (F) wrote:

One alternative solution I can image is to attach a BPF program
at sampling like kprobe, and return 0 if we don't want sampling
take action. Thought?


Do you think attaching BPF programs to sampling is an acceptable idea?


If you mean to extend 'filter' concept to sampling events?
So instead of soft_disable of non-local events, you'll attach bpf
program to sampling events and use map lookup to decide whether
to filter out or not such sampling event?


Yes.


What pt_regs would be in such case?



Sampling is based on interruption. We can use pt_reg captured by the IRQ 
handler,

or we can simply pass NULL to those BPF program.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Alexei Starovoitov]

On 10/21/15 6:56 PM, Wangnan (F) wrote:

One alternative solution I can image is to attach a BPF program
at sampling like kprobe, and return 0 if we don't want sampling
take action. Thought?


Do you think attaching BPF programs to sampling is an acceptable idea?


If you mean to extend 'filter' concept to sampling events?
So instead of soft_disable of non-local events, you'll attach bpf
program to sampling events and use map lookup to decide whether
to filter out or not such sampling event?
What pt_regs would be in such case?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: next-20151021 - compile error in fs/f2fs/checkpoint.c

[Jaegeuk Kim]

On Thu, Oct 22, 2015 at 09:47:22AM +0800, Chao Yu wrote:
> Hello,
> 
> > -Original Message-
> > From: Valdis Kletnieks [mailto:valdis.kletni...@vt.edu]
> > Sent: Thursday, October 22, 2015 2:06 AM
> > To: Chao Yu; Jaegeuk Kim; Changman Lee
> > Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> > Subject: next-20151021 - compile error in fs/f2fs/checkpoint.c
> > 
> > Building next-20151021 dies with this error:
> > 
> >   CC [M]  fs/f2fs/checkpoint.o
> > fs/f2fs/checkpoint.c: In function 'get_valid_checkpoint':
> > fs/f2fs/checkpoint.c:707:3: error: too few arguments to function 
> > 'ra_meta_pages'
> >ra_meta_pages(sbi, cp_blk_no + 1, cp_blks - 1, META_CP);
> 
> Above invoking is added in commit ("f2fs: readahead cp payload pages
> when mount") at ~9/12/2015, but sadly it's complete wrong due to my fault,
> so it is removed in our dev-test branch by Jaegeuk at ~9/26/2015. I can't
> remember the time when this commit is removed from dev branch which is for
> -next branch. I have checked next-20151022, this commit is gone, I think
> the last -next will not make any trouble to you. Could you check that?

At least, now f2fs for -next contains a fixed patch.
Thanks,

> 
> >^
> > fs/f2fs/checkpoint.c:143:5: note: declared here
> >  int ra_meta_pages(struct f2fs_sb_info *sbi, block_t start, int nrpages,
> >  ^
> > scripts/Makefile.build:258: recipe for target 'fs/f2fs/checkpoint.o' failed
> > make[2]: *** [fs/f2fs/checkpoint.o] Error 1
> > 
> > Looks like this commit:
> > 
> > commit 26879fb101f28c554294eaf25ac7817a2825b180
> > Author: Chao Yu 
> > Date:   Mon Oct 12 17:05:59 2015 +0800
> > 
> > f2fs: support lower priority asynchronous readahead in ra_meta_pages
> > 
> > missed updating one call.  Apparently this wasn't compile-tested before
> > being pushed upstream?
> 
> When this commit was updated in Jaegeuk's tree, above invoking in
> fs/f2fs/checkpoint.c:707 was gone.
> 
> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] f2fs: fix leakage of inmemory atomic pages

[Jaegeuk Kim]

If we got failure during commit_atomic_write, abort_volatile_write will be
called, but will not drop the inmemory pages due to no FI_ATOMIC_FILE.
Actually, there is no reason to check the flag in abort_volatile_write.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/file.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 91c51a6..a197215 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1443,13 +1443,9 @@ static int f2fs_ioc_abort_volatile_write(struct file 
*filp)
 
f2fs_balance_fs(F2FS_I_SB(inode));
 
-   if (f2fs_is_atomic_file(inode)) {
-   clear_inode_flag(F2FS_I(inode), FI_ATOMIC_FILE);
-   commit_inmem_pages(inode, true);
-   }
-
-   if (f2fs_is_volatile_file(inode))
-   clear_inode_flag(F2FS_I(inode), FI_VOLATILE_FILE);
+   clear_inode_flag(F2FS_I(inode), FI_ATOMIC_FILE);
+   clear_inode_flag(F2FS_I(inode), FI_VOLATILE_FILE);
+   commit_inmem_pages(inode, true);
 
mnt_drop_write_file(filp);
return ret;
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] f2fs: don't need to submit bio on error case

[Jaegeuk Kim]

If commit_atomic_write is failed, we don't need to submit any bio.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 7835e41..7efd96ad 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -249,11 +249,11 @@ int commit_inmem_pages(struct inode *inode, bool abort)
trace_f2fs_commit_inmem_page(cur->page, INMEM);
fio.page = cur->page;
err = do_write_data_page();
-   submit_bio = true;
if (err) {
unlock_page(cur->page);
break;
}
+   submit_bio = true;
}
} else {
trace_f2fs_commit_inmem_page(cur->page, INMEM_DROP);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND net-next] net: updates HNS config and documents

[Yankejian (Hackim Yim)]

在 2015/10/22 9:26, Rob Herring 写道:
> On Mon, Oct 19, 2015 at 9:36 PM, yankejian  wrote:
>> updates the bindings documents and dtsi file according to the review
>> comments from Rob Herring 
>>
>> Signed-off-by: yankejian 
>> Signed-off-by: huangdaode 
> 
> Acked-by: Rob Herring 
> 

Thanks!

>> ---
>>  Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt | 2 +-
>>  arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 8 +++-
>>  2 files changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt 
>> b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
>> index 9940aa0..9c23fdf 100644
>> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
>> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
>> @@ -12,7 +12,7 @@ Example:
>>   mdio@803c {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> -   compatible = "hisilicon,mdio","hisilicon,hns-mdio";
>> +   compatible = "hisilicon,hns-mdio","hisilicon,mdio";
>> reg = <0x0 0x803c 0x0 0x1>;
>>
>> ethernet-phy@0 {
>> diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
>> b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
>> index 3500586..606dd5a 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
>> @@ -13,14 +13,12 @@ soc0: soc@0 {
>> reg = <0x0 0x803c 0x0 0x1
>>0x0 0x8000 0x0 0x1>;
>>
>> -   soc0_phy4: ethernet-phy@4 {
>> +   soc0_phy0: ethernet-phy@0 {
>> reg = <0x0>;
>> -   device_type = "ethernet-phy";
>> compatible = "ethernet-phy-ieee802.3-c22";
>> };
>> -   soc0_phy5: ethernet-phy@5 {
>> +   soc0_phy1: ethernet-phy@1 {
>> reg = <0x1>;
>> -   device_type = "ethernet-phy";
>> compatible = "ethernet-phy-ieee802.3-c22";
>> };
>> };
>> @@ -37,7 +35,7 @@ soc0: soc@0 {
>>0x0 0xc700 0x0 0x6
>>>;
>>
>> -   phy-handle = <0 0 0 0 _phy4 _phy5 0 0>;
>> +   phy-handle = <0 0 0 0 _phy0 _phy1 0 0>;
>> interrupts = <
>> /* [14] ge fifo err 8 / xge 6**/
>> 149 0x4 150 0x4 151 0x4 152 0x4
>> --
>> 1.9.1
>>
>> --
>> 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
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote:
> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,
>>
>> Thanks for your feedback.
>>
>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote:
>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote:
 The pwrseq_emmc driver does a eMMC card reset before a system reboot to
 allow broken or limited ROM boot-loaders (that don't have an eMMC reset
 logic) to be able to read the second stage from the eMMC.

 But this has to be called before a system reboot handler and while most
 of them use the priority 128, there are other restart handlers (such as
 the syscon-reboot one) that use a higher priority. So, use the highest
 priority to make sure that the eMMC hw is reset before a system reboot.

 Signed-off-by: Javier Martinez Canillas 
 Tested-by: Markus Reichl 
 Tested-by: Anand Moon 
 Reviewed-by: Alim Akhtar 

 ---
 Hello,

 This patch was needed since a recent series from Alim [0] added
 syscon reboot and poweroff support to Exynos SoCs and removed
 the reset handler in the Exynos Power Management Unit (PMU) code.

 But the PMU and syscon-reboot restart handler have a different
 priority so [0] breaks restart when eMMC is used on these boards.

 [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html

 So this patch must be merged before [0] to avoid regressions.

 Best regards,
 Javier

  drivers/mmc/core/pwrseq_emmc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/mmc/core/pwrseq_emmc.c 
 b/drivers/mmc/core/pwrseq_emmc.c
 index 137c97fb7aa8..ad4f94ec7e8d 100644
 --- a/drivers/mmc/core/pwrseq_emmc.c
 +++ b/drivers/mmc/core/pwrseq_emmc.c
 @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct 
 mmc_host *host,
  
/*
 * register reset handler to ensure emmc reset also from
 -   * emergency_reboot(), priority 129 schedules it just before
 -   * system reboot
 +   * emergency_reboot(), priority 255 is the highest priority
 +   * so it will be executed before any system reboot handler.
 */
pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
 -  pwrseq->reset_nb.priority = 129;
 +  pwrseq->reset_nb.priority = 255;
>>>
>>> I see the problem which you are trying to solve but this may be tricker
>>> then just kicking the number. Some of restart handlers are registered
>>> with priority 192. I found few of such, like: at91_restart_nb,
>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too
>>> much).
>>>
>>
>> Yes, the syscon-reboot restart handler also uses a priority 192 and that
>> is why reboot with eMMC broke with Alim's patches since the PMU restart
>> handler priority is 128.
>>
>>> I guess they chose the "192" priority on purpose.
>>>
>>
>> I tried to understand what's the policy w.r.t priority numbering for
>> restart handlers but only found this in the register_restart_handler
>> kernel-doc [0]:
>>
>> /**
>>  *   register_restart_handler - Register function to be called to reset
>>  *  the system
>>  *   @nb: Info about handler function to be called
>>  *   @nb->priority:  Handler priority. Handlers should follow the
>>  *   following guidelines for setting priorities.
>>  *   0:  Restart handler of last resort,
>>  *   with limited restart capabilities
>>  *   128:Default restart handler; use if no other
>>  *   restart handler is expected to be available,
>>  *   and/or if restart functionality is
>>  *   sufficient to restart the entire system
>>  *   255:Highest priority restart handler, will
>>  *   preempt all other restart handlers
>>
>> So, reading that is not clear to me if only the values 0, 128 and 255
>> should be used or any value from 0-255.
>>
>> What's clear to me is that restart handlers to reset a specific hw block
>> should be called before the restart handler that resets the whole system.
>>
>> The 192 seems to be used because there are other default restart handlers
>> that are using a prio of 128. See for example the commit that changed the
>> syscon-reboot prio from 128 to 192:
>>
>> b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver
> 
> But were are here not talking about syscon handler but the others. Now
> you will be ahead of them.
>

Yes, I know that. My point was that the platforms were either not using the
mmc-pwrseq-emmc or their system restart handler already had a lower priority
but that is not true for at least rk3288-veyron as you said.
 
>>
>> So probably the 192 value was chosen because is in the middle of 128 and
>> 255 but it seems to me a 

Re: [PATCH v3 1/8] arm64: dts: qcom: 8x16: Add fixed rate on-board oscillator

[Andy Gross]

On Tue, Oct 20, 2015 at 07:57:53PM +0300, Georgi Djakov wrote:
> Add the on-board XO oscillator. This patch prepares for adding support
> for RPM controlled clocks. In order to do smooth transition and support
> both cases (RPM clock driver is enabled or nor), we first move the XO to
> the DT and change the GCC fixed-rate root clock to a dummy pass-through
> clock. Then if the RPM driver is enabled, we set the parent of the XO
> clock in the RPM clock driver to xo_board.
> The advantage of doing so is that the rate of the XO clock is not hard-
> coded in the GCC driver anymore, but comes from the board layout, so
> that is why it should be in DT anyway.
> 
> Signed-off-by: Georgi Djakov 
> ---

Looks good to me.

Reviewed-by: Andy Gross 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Wangnan (F)]

On 2015/10/22 0:57, Peter Zijlstra wrote:

On Wed, Oct 21, 2015 at 11:06:47PM +0800, pi3orama wrote:

So explain; how does this eBPF stuff work.

I think I get your point this time, and let me explain the eBPF stuff to you.

You are aware that BPF programmer can break the system in this way:

A=get_non_local_perf_event()
perf_event_read_local(A)
BOOM!

However the above logic is impossible because BPF program can't work this
way.

First of all, it is impossible for a BPF program directly invoke a
kernel function.  Doesn't like kernel module, BPF program can only
invoke functions designed for them, like what this patch does. So the
ability of BPF programs is strictly restricted by kernel. If we don't
allow BPF program call perf_event_read_local() across core, we can
check this and return error in function we provide for them.

Second: there's no way for a BPF program directly access a perf event.
All perf events have to be wrapped by a map and be accessed by BPF
functions described above. We don't allow BPF program fetch array
element from that map. So pointers of perf event is safely protected
from BPF program.

In summary, your either-or logic doesn't hold in BPF world. A BPF
program can only access perf event in a highly restricted way. We
don't allow it calling perf_event_read_local() across core, so it
can't.

Urgh, that's still horridly inconsistent. Can we please come up with a
consistent interface to perf?


BPF program and kernel module are two different worlds as I said before.

I don't think making them to share a common interface is a good idea
because such sharing will give BPF programs too much freedom than it
really need, then it will be hard prevent them to do something bad.
If we really need kernel interface, I think what we need is kernel
module, not BPF program.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: msm_serial: Make config tristate

[Andy Gross]

On Wed, Oct 21, 2015 at 04:05:23PM -0700, Stephen Boyd wrote:
> This driver works as a module, so mark it as a tristate config
> instead of a bool.
> 
> Cc: Paul Gortmaker 
> Signed-off-by: Stephen Boyd 
> ---
> 
> I tested this with a busybox ramdisk that modprobes msm_serial and
> then runs a getty on ttyMSM0. This patch should supersede Paul's earlier
> patch that removes the module code from this driver.
> 
>  drivers/tty/serial/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Andy Gross 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 1/2] ARM: gemini: remove unnecessary mdio-gpio includes

[David Miller]

From: Vivien Didelot 
Date: Tue, 20 Oct 2015 10:08:58 -0400

> Remove the inclusion of linux/mdio-gpio.h in nas4220b, wbd111 and wbd222
> boards since mdio-gpio is not used.
> 
> Signed-off-by: Vivien Didelot 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 2/2] net: mdio-gpio: move platform data header

[David Miller]

From: Vivien Didelot 
Date: Tue, 20 Oct 2015 10:08:59 -0400

> This header file only contains the platform data structure definition,
> so move it to the include/linux/platform_data/ directory.
> 
> Signed-off-by: Vivien Didelot 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v2 2/2] ARM: dts: rockchip: Add the OTP gpio pinctrl

[Caesar Wang]

Add the "init" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

"init" pinctrl property is defined by Doug's Patch[0].

Patch[0]:
https://patchwork.kernel.org/patch/7454311/

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v2:
  - Add some commits for more obvious in PATCH[2/2]

Changes in v1:
  - As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
  - As the Doug's patch to add the 'init' property.

 arch/arm/boot/dts/rk3288.dtsi | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938..6ea89aa 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -447,8 +447,9 @@
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
status = "disabled";
@@ -1273,6 +1274,10 @@
};
 
tsadc {
+   otp_gpio: otp-gpio {
+   rockchip,pins = <0 10 RK_FUNC_GPIO 
_pull_none>;
+   };
+
otp_out: otp-out {
rockchip,pins = <0 10 RK_FUNC_1 
_pull_none>;
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v2 1/2] dt-bindings: rockchip-thermal: Add the "init" pinctrl in this document

[Caesar Wang]

The "init" pinctrl is defined we'll set
pinctrl to this state before probe and then "default" after probe.

Add the "init" pinctrl as the OTP gpio state, since we need switch
the pin to gpio state before the TSADC controller is reset.

As I know, the TSADC controller is reset, the tshut polarity will be
a *low* signal in a short period of time for some devices.

Says:
The TSADC get the temperature on rockchip thermal.

If T(current temperature) < (setting temperature), the OTP output the
*high* signal.
If T(current temperature) > (setting temperature), the OTP output the
*low* Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the
PMIC can accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the
OTP pin is connected the others IC to control the power.

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v2:
  - Add the 'init' pinctrl more decription in commit.
  - Fix the subject to make more obvious in PATCH[1/2]
  - Resend this patch v2 since fix the subject to be specific.

Changes in v1:
  - As the Doug comments, add the 'init' property to sync document.

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..28e84f7 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -27,8 +27,9 @@ tsadc: tsadc@ff28 {
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
rockchip,hw-tshut-mode = <0>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v2 0/2] fix the TSHUT issue on rockchip thermal

[Caesar Wang]

We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

Says:
The TSHUT temperature is setting more than 80 degree, the default
tshut polarity is HIGH.

If T > 80C, the OTP output the High Signal.
If T < 80C, the OTP output the Low Signal.

On the moment, the TSADC controller is reset, the tshut polarity will be
Low in a short period of time.

So:
If T < 80C, the OTP output the High Signal.
If T > 80C, the OTP output the Low Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can
accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the OTP pin
is connected the others IC to control the power.

This series patchs are depend on Doug's 
patch.(https://patchwork.kernel.org/patch/7454311/)

This series patchs are based on the Linus master branch.

518cd44 ARM: dts: rockchip: Add the OTP gpio pinctrl
83e0bab dt-bindings: Add the "init" pinctrl in this document
150426c drivers/pinctrl: Add the concept of an "init" state
ce1fad2 Merge branch 'keys-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
1099f86 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
911b79c KEYS: Don't permit request_key() to construct a new keyring
37850e3 net: bcmgenet: Fix early link interrupt enabling
afc050d Merge tag 'wireless-drivers-for-davem-2015-10-17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
e277de5 tunnels: Don't require remote endpoint or ID during creation.
740dbc2 openvswitch: Scrub skb between namespaces


Tested on box board.


Changes in v2:
  - Add the 'init' pinctrl more decription in commit.
  - Fix the subject to make more obvious in PATCH[1/2]
  - Resend this patch v2 since fix the subject to be specific.
  - Add some commits for more obvious in PATCH[2/2]

Changes in v1:
  - As the Doug comments, add the 'init' property to sync document.
  - As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
  - As the Doug's patch to add the 'init' property.

Caesar Wang (2):
  dt-bindings: rockchip-thermal: Add the "init" pinctrl in this document
  ARM: dts: rockchip: Add the OTP gpio pinctrl

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
 arch/arm/boot/dts/rk3288.dtsi  | 9 +++--
 2 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the tip tree with the arm64 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/arm64/kernel/cpufeature.c

between commit:

  da8d02d19ffd ("arm64/capabilities: Make use of system wide safe value")

from the arm64 tree and commit:

  963fcd409587 ("arm64: cpufeatures: Check ICC_EL1_SRE.SRE before enabling 
ARM64_HAS_SYSREG_GIC_CPUIF")

from the tip tree.

I fixed it up (I have no idea here, so I just used the arm64 tree version)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 1/1] usb:serial add Fintek F81532/534 driver

[Peter Hung]

Hi Johan,

Johan Hovold 於 2015/9/14 下午 09:33 寫道:

On Tue, Jul 21, 2015 at 09:58:19AM +0800, Peter Hung wrote:



   4. RS422 Mode
  1. The RTS mode is dont care.
  2. Set M2/M1/M0 as 0/0/0


I don't think all gpios should be exported for these ports if they have
special functions that the driver could control transparently (e.g. for
SER_RS485_RTS_ON_SEND).


Surely, we can hide some setting with definitely setting like
RS232/RS485, but the settings is only apply to our evaluation board.

Some customers will use our F81532/534 with other brand transceiver IC.
The pins setting maybe changed, so we decided to separate UART & pins
settings and let the 3 output pins controllable for customer.

Could I preserve currently UART & pins setting mode ?



+   current_mode &= BIT(gpio_num);
+
+   mutex_unlock(_priv->change_mode_mutex);
+   f81534_wakeup_all_port(port->serial);
+
+   return !!current_mode;
+}


Your gpio implementation looks wrong, but let's get back to that after
you explain how these pins are used.

If they are not really general purpose pins, then this isn't the right
interface.


The 4x3 pins is output-only mode to control transceiver, so I'm only
implement the output functions and let all input functions failed.

Could you give some advices to me if the gpiolib interface cant be
used ?

Sorry for late reply, I'm almost ready to submit v6 when clarify some
questions.

Thanks,
--
With Best Regards,
Peter Hung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: hisilicon: fix ptr_ret.cocci warnings

[David Miller]

From: kbuild test robot 
Date: Tue, 20 Oct 2015 14:56:00 +0800

> drivers/net/ethernet/hisilicon/hns/hnae.c:442:1-3: WARNING: PTR_ERR_OR_ZERO 
> can be used
> 
> 
>  Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> 
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
> 
> CC: Arnd Bergmann 
> Signed-off-by: Fengguang Wu 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/9] Add tune support of Mediatek MMC driver

[Chaotian Jing]

On Tue, 2015-10-20 at 18:41 +0200, Ulf Hansson wrote:
> On 20 October 2015 at 11:13, Chaotian Jing  wrote:
> > Change in v2:
> > Drop the 400mhz and use assigned-clock-parents to instead
> > Split the original tune patch to several independent patches
> > Re-write the mmc_send_tuning()
> > Fix GPD checksum error
> > Move the HS400 setting to ops->prepare_hs400_tuning()
> > Modify SD driving settings
> >
> > Change in v1:
> > Add DT bindings for eMMC hardware reset
> > Add pinctrl of data strobe pin for HS400 mode
> > Modify eMMC driving settings
> > Add 400mhz source clock for HS400 mode
> > Add eMMC HS200/HS400 mode support
> > Add SD SDR50/SDR104 mode support
> > Add implement of tune function with CMD19/CMD21
> >
> > Chaotian Jing (9):
> >   mmc: core: Add DT bindings for eMMC hardware reset support
> >   mmc: dt-bindings: update Mediatek MMC bindings
> >   mmc: mediatek: make cmd_ints_mask to const
> >   mmc: mediatek: change the argument "ddr" to "timing"
> >   mmc: mediatek: fix got GPD checksum error interrupt when data transfer
> >   mmc: mediatek: add implement of ops->hw_reset()
> >   mmc: mmc: extend the mmc_send_tuning()
> >   mmc: mediatek: add HS400 support
> >   arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support
> >
> >  Documentation/devicetree/bindings/mmc/mmc.txt|   1 +
> >  Documentation/devicetree/bindings/mmc/mtk-sd.txt |  11 +-
> >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts  |  27 ++-
> >  drivers/mmc/core/host.c  |   2 +
> >  drivers/mmc/core/mmc_ops.c   |   8 +-
> >  drivers/mmc/host/dw_mmc-exynos.c |   4 +-
> >  drivers/mmc/host/dw_mmc.c|   2 +-
> >  drivers/mmc/host/dw_mmc.h|   2 +-
> >  drivers/mmc/host/mtk-sd.c| 296 
> > ---
> >  drivers/mmc/host/sdhci-esdhc-imx.c   |   6 +-
> >  drivers/mmc/host/sdhci-msm.c |   2 +-
> >  drivers/mmc/host/sdhci-sirf.c|   2 +-
> >  include/linux/mmc/core.h |   2 +-
> >  13 files changed, 314 insertions(+), 51 deletions(-)
> >
> > --
> > 1.8.1.1.dirty
> 
> I have reviewed the patches, I think they overall looks good! Some
> comments though.
> 
> You need to split patch 9, the DT parts enabling hw reset shall go in
> separately.
> 
Ok, will separate it at next revision.

> Regarding the hw-reset changes in patch1, patch6 and patch9, I believe
> I requested you to separate the HW reset changes from $subject
> patchset as they are unrelated, please do this.
> 
As you know, the hw-reset is a part of mmc retune.
so that I add it to this series.

> Running checkpatch, it gave me warnings and errors for patch 8.
> Patch7 didn't apply to my next branch.
> 

I will fix the checkpatch warnings and errors at next revision.
by the way, I tried to use "git am
0007-mmc-mmc-extend-the-mmc_send_tuning.patch" in your branch,
there was no conflict, so why couldn't apply it ?
Thx!

> Kind regards
> Uffe


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Fixed Trivial Warnings in file: Deleted Spaces prior to tabs, and added lines. modified: kernel/auditfilter.c

[Richard Guy Briggs]

On 15/10/21, Scott Matheina wrote:
> On 10/21/2015 10:33 AM, Richard Guy Briggs wrote:
> > On 15/10/21, Joe Perches wrote:
> >> On Mon, 2015-10-19 at 12:10 -0400, Richard Guy Briggs wrote:
> >>> On 15/10/18, Scott Matheina wrote:
>  On 10/14/2015 04:54 PM, Paul Moore wrote:
> > On Saturday, October 10, 2015 08:57:55 PM Scott Matheina wrote:
> >> []
> >> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> >> []
> >> @@ -109,6 +109,7 @@ void audit_free_rule_rcu(struct rcu_head *head)
> >>  {
> >>struct audit_entry *e = container_of(head, struct audit_entry, 
> >> rcu);
> >>audit_free_rule(e);
> >> +
> >>  }
> > Why?
>  I was following the error messages in checkpatch.pl, but the warning
>  went away after adding this line. No problem with the code. 
> >>> That sounds like a bug in checkpatch.pl, since that blank line should be
> >>> tween the declaration and the function call.
> >> checkpatch message asks for a blank line after the
> >> "struct audit_entry *e = ..." declaration.
> > Well then maybe it is a bug in his interpretation of the output of
> > checkpatch.pl?  Scott, did you re-run checkpatch.pl after adding those
> > spaces?  Did it pass?
> 
> The error did go away. 

Joe, I confirm the error went away.  Looks like a bug in checkpatch.pl
to me.  I tried a number of combinations of things and it didn't
complain about several things it should have.  I did try a few other
things to make sure it was still finding problems like brace placement
and leading spaces, but it looks like the blank line checking code isn't
working.  This is on 4.0, so maybe it has been fixed since then.  Scott,
what kernel version are you using?

> >>while (*list != ~0U) {
> >> +
> >>unsigned n = *list++;
> >>if (n >= AUDIT_BITMASK_SIZE * 32 - 
> >> AUDIT_SYSCALL_CLASSES) {
> >>kfree(p);
> > Why?
>  This is the same as above. Just going through the checkpatch.pl
>  script, and looking for warnings to fix. 
> >>> Again, another manifestation of that bug?  That blank line should be
> >>> after the declaration and before the if statement.
> >> []
> >>> Well, I agree, you have to start somewhere...  Too bad you hit a bug in
> >>> checkpatch.pl!
> >> Here too, not a bug in checkpatch.
> >>
> >> checkpatch output asks for a blank line after the
> >> "unsigned n" declaration, not before.
> > - RGB

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel oops on mmotm-2015-10-15-15-20

[Hugh Dickins]

On Thu, 22 Oct 2015, Minchan Kim wrote:
> Hello Hugh,
> 
> On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote:
> > On Thu, 22 Oct 2015, Minchan Kim wrote:
> > > 
> > > I added the code to check it and queued it again but I had another oops
> > > in this time but symptom is related to anon_vma, too.
> > > (kernel is based on recent mmotm + unconditional mkdirty for bug fix)
> > > It seems page_get_anon_vma returns NULL since the page was not page_mapped
> > > at that time but second check of page_mapped right before try_to_unmap 
> > > seems
> > > to be true.
> > > 
> > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k 
> > > FS
> > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k 
> > > FS
> > > page:ea0001cfbfc0 count:3 mapcount:1 mapping:88007f1b5f51 
> > > index:0x60aff
> > > flags: 0x40048019(locked|uptodate|dirty|swapcache|swapbacked)
> > > page dumped because: VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && 
> > > !anon_vma)
> > 
> > That's interesting, that's one I added in my page migration series.
> > Let me think on it, but it could well relate to the one you got before.
> 
> I will roll back to mm/madv_free-v4.3-rc5-mmotm-2015-10-15-15-20
> instead of next-20151021 to remove noise from your migration cleanup
> series and will test it again.
> If it is fixed, I will test again with your migration patchset, then.

Not a good use of your time, I think.  It's sure to be fixed in the
rc5-mmotm because that VM_BUG_ON_PAGE(blah) just does not exist in
that tree: I added it to verify my reasoning in changing the comments
about page_get_anon_vma() and PageSwapCache in mm/migrate.c.

> 
> > 
> > > page->mem_cgroup:88007f3dcc00
> > > [ cut here ]
> > > kernel BUG at mm/migrate.c:889!
> > > invalid opcode:  [#1] SMP 
> > > Dumping ftrace buffer:
> > >(ftrace buffer empty)
> > > Modules linked in:
> > > CPU: 11 PID: 59 Comm: khugepaged Not tainted 
> > > 4.3.0-rc6-next-20151021-THP-ref-madv_free+ #1557
> > 
> > Hmm, it might be me to blame, or it might be Kirill, don't know yet.
> 
> It might be me, either.
> 
> > 
> > Oh, hold on, I think Andrew has just posted a new mmotm, and it includes
> > an update to Kirill's migrate_pages-try-to-split-pages-on-queueing.patch:
> > I haven't digested yet, but it might turn out to be relevant.

Sorry, I think that was an irrelevant suggestion: today's new rc6-mmotm
is identical to yesterday's there, and the patch that was removed appears
to be identical to the one added.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] dt-bindings: Add document of Rockchip mailbox

[Caesar Wang]

Hello Jassi,

Sorry for delay reply.
在 2015年10月06日 18:34, Jassi Brar 写道:

On Mon, Sep 14, 2015 at 4:36 PM, Caesar Wang  wrote:

This add the necessary binding documentation for mailbox
found on RK3368 SoC.

Signed-off-by: Caesar Wang 
---

  .../bindings/mailbox/rockchip-mailbox.txt  | 33 ++
  1 file changed, 33 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
new file mode 100644
index 000..b9b4768
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
@@ -0,0 +1,33 @@
+Rockchip mailbox
+
+The Rockchip mailbox is used by the Rockchip CPU cores to communicate
+requests to MCU processor.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+
+ - compatible: should be one of the following.
+   - "rockchip,rk3368-mbox" for rk3368
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+   physical base address of the share buffer and length of memory mapped
+   region.

Please make shared-sram a property of user drivers.


As Rob points out,
maybe, don't we need also define it in user drivers.
As the SRAM binding (misc/sram.txt) had defined.

I just make the SCPI protocol client driver to work for mailbox.


Location and size of shared-memory is a platform property, mailbox
controller doesn't need sram to function.
   For example, protocol on some platform, with this controller, may be
trivial enough to not need a shared sram... say only 32-bits wide
requests and responses which can be passed via mailbox registers
directly.   mbox_client.tx_prepare() is where the user driver sets up
the shared-memory.

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 2/4] net:hns: Add Hip06 "RSS(Receive Side Scaling)" support to HNS Driver

[Yisen.Zhuang(Zhuangyuzeng)]

Please check my comment below. thanks.

Yisen

On 2015/10/20 23:01, Salil wrote:
> From: Salil Mehta 
> 
> This patch adds the support of "RSS (Receive Side Scaling)" feature
> provided by the Hip06 ethernet hardware to the HNS ethernet
> driver.
> 
> This feature helps in distributing the different flows (mapped as
> hash by hardware using Toeplitz Hash) to different Queues asssociated
> with the processor cores. The mapping of flow-hash values to the
> different queues is stored in indirection table (which is per Packet-
> parse-Engine/PPE). This patch also provides the changes to re-program
> the (flow-hash<->Qid) mapping using the ethtool.
> 
> Signed-off-by: Salil Mehta 
> ---
>  drivers/net/ethernet/hisilicon/hns/hnae.h |6 ++
>  drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |   81 
> -
>  drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |   74 ++-
>  drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h |   33 +++--
>  drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |   14 
>  drivers/net/ethernet/hisilicon/hns/hns_ethtool.c  |   69 ++
>  6 files changed, 267 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
> b/drivers/net/ethernet/hisilicon/hns/hnae.h
> index 70a662c..3edcade 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hnae.h
> +++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
> @@ -483,6 +483,12 @@ struct hnae_ae_ops {
> enum hnae_led_state status);
>   void (*get_regs)(struct hnae_handle *handle, void *data);
>   int (*get_regs_len)(struct hnae_handle *handle);
> + u32 (*get_rss_key_size)(struct hnae_handle *handle);
> + u32 (*get_rss_indir_size)(struct hnae_handle *handle);
> + int (*get_rss)(struct hnae_handle *handle, u32 *indir, u8 *key,
> +u8 *hfunc);
> + int (*set_rss)(struct hnae_handle *handle, const u32 *indir,
> +const u8 *key, const u8 hfunc);
>  };
>  
>  struct hnae_ae_dev {
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
> b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
> index c3d64ce..791c289 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
> @@ -748,6 +748,81 @@ int hns_ae_get_regs_len(struct hnae_handle *handle)
>   return total_num;
>  }
>  
> +static u32 hns_ae_get_rss_key_size(struct hnae_handle *handle)
> +{
> + struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
> +
> + if (!hns_ppe_is_rss_supported(ppe_cb)) {
> + pr_err("RSS feature is not supported on this hardware\n");
> + return 0;

use dev_err rather than pr_err.

> + }
> +
> + return HNS_PPEV2_RSS_KEY_SIZE;
> +}
> +
> +static u32 hns_ae_get_rss_indir_size(struct hnae_handle *handle)
> +{
> + struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
> +
> + if (!hns_ppe_is_rss_supported(ppe_cb)) {
> + pr_err("RSS feature is not supported on this hardware\n");
> + return 0;

use dev_err rather than pr_err.

> + }
> +
> + return HNS_PPEV2_RSS_IND_TBL_SIZE;
> +}
> +
> +static int hns_ae_get_rss(struct hnae_handle *handle, u32 *indir, u8 *key,
> +   u8 *hfunc)
> +{
> + struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
> + u32 i;
> +
> + if (!hns_ppe_is_rss_supported(ppe_cb)) {
> + pr_err("RSS feature is not supported on this hardware\n");
> + return -EOPNOTSUPP;

use dev_err rather than pr_err.

> + }
> +
> + /* currently we support only one type of hash function i.e. Toep hash */
> + if (hfunc)
> + *hfunc = ETH_RSS_HASH_TOP;
> +
> + /* get the RSS Key required by the user */
> + if (key)
> + memcpy(key, ppe_cb->rss_key, HNS_PPEV2_RSS_KEY_SIZE);
> +
> + /* update the current hash->queue mappings from the shadow RSS table */
> + for (i = 0; i < HNS_PPEV2_RSS_IND_TBL_SIZE; i++)
> + indir[i] = ppe_cb->rss_indir_table[i];
> +
> + return 0;
> +}
> +
> +static int hns_ae_set_rss(struct hnae_handle *handle, const u32 *indir,
> +   const u8 *key, const u8 hfunc)
> +{
> + struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
> + u32 i;
> +
> + if (!hns_ppe_is_rss_supported(ppe_cb)) {
> + pr_err("RSS feature is not supported on this hardware\n");
> + return -EOPNOTSUPP;

use dev_err rather than pr_err.

> + }
> +
> + /* set the RSS Hash Key if specififed by the user */
> + if (key)
> + hns_ppe_set_rss_key(ppe_cb, (int *)key);
> +
> + /* update the shadow RSS table */
> + for (i = 0; i < HNS_PPEV2_RSS_IND_TBL_SIZE; i++)
> + ppe_cb->rss_indir_table[i] = i;

Moving this into hns_ppe_set_indir_table will be better.

> +
> + /* now update the hardware */
> + hns_ppe_set_indir_table(ppe_cb, 

[PATCH 10/11] staging: lustre: remove last entry of libcfs_netstrfns[]

[James Simmons]

From: Frederic Saunier 

Currently NID string handling test for the last entry,
and last entry has .nf_type == (__u32) -1. If we ask
for a non existent LND we hit the last entry which then
calls a strlen on a NULL which causes a error. We can
avoid this problem if we just remove the last entry
since it is not used for anything except as a last
entry marker.

Signed-off-by: Frederic Saunier 
Signed-off-by: James Simmons 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6501
Reviewed-on: http://review.whamcloud.com/15424
Reviewed-by: frank zago 
Reviewed-by: Dmitry Eremin 
Reviewed-by: Oleg Drokin 
---
 drivers/staging/lustre/lnet/lnet/nidstrings.c |   11 +++
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index b7a65da..a5cd0ae 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -1101,8 +1101,6 @@ static struct netstrfns  libcfs_netstrfns[] = {
 /* .nf_match_addr*/  libcfs_num_match,
 /* .nf_is_contiguous */  cfs_num_is_contiguous,
 /* .nf_min_max   */  cfs_num_min_max},
-   /* placeholder for net0 alias.  It MUST BE THE LAST ENTRY */
-   {/* .nf_type  */  -1},
 };
 
 static const size_t libcfs_nnetstrfns = ARRAY_SIZE(libcfs_netstrfns);
@@ -1127,8 +1125,7 @@ libcfs_namenum2netstrfns(const char *name)
 
for (i = 0; i < libcfs_nnetstrfns; i++) {
nf = _netstrfns[i];
-   if (nf->nf_type >= 0 &&
-   !strncmp(name, nf->nf_name, strlen(nf->nf_name)))
+   if (!strncmp(name, nf->nf_name, strlen(nf->nf_name)))
return nf;
}
return NULL;
@@ -1140,8 +1137,7 @@ libcfs_name2netstrfns(const char *name)
inti;
 
for (i = 0; i < libcfs_nnetstrfns; i++)
-   if (libcfs_netstrfns[i].nf_type >= 0 &&
-   !strcmp(libcfs_netstrfns[i].nf_name, name))
+   if (!strcmp(libcfs_netstrfns[i].nf_name, name))
return _netstrfns[i];
 
return NULL;
@@ -1254,8 +1250,7 @@ libcfs_str2net_internal(const char *str, __u32 *net)
 
for (i = 0; i < libcfs_nnetstrfns; i++) {
nf = _netstrfns[i];
-   if (nf->nf_type >= 0 &&
-   !strncmp(str, nf->nf_name, strlen(nf->nf_name)))
+   if (!strncmp(str, nf->nf_name, strlen(nf->nf_name)))
break;
}
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/11] staging: lustre: add in NID range management for libcfs

[James Simmons]

From: Joshua Walgenbach 

This is a partial backport of the NID range management
added in for nodemap. We only backport the libcfs related
parts here.

Signed-off-by: Joshua Walgenbach 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3527
Reviewed-on: http://review.whamcloud.com/8057
Reviewed-by: Andreas Dilger 
Reviewed-by: Andrew Perepechko 
Reviewed-by: John L. Hammond 
Reviewed-by: Ken Hornstein 
---
 drivers/staging/lustre/include/linux/lnet/nidstr.h |3 +
 drivers/staging/lustre/lnet/lnet/nidstrings.c  |  365 +++-
 2 files changed, 355 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/linux/lnet/nidstr.h
index 1536366..4e7c9a5 100644
--- a/drivers/staging/lustre/include/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/linux/lnet/nidstr.h
@@ -89,6 +89,9 @@ struct netstrfns {
int (*nf_print_addrlist)(char *buffer, int count,
 struct list_head *list);
int (*nf_match_addr)(__u32 addr, struct list_head *list);
+   bool(*nf_is_contiguous)(struct list_head *nidlist);
+   void(*nf_min_max)(struct list_head *nidlist, __u32 *min_nid,
+ __u32 *max_nid);
 };
 
 #endif /* _LNET_NIDSTRINGS_H */
diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index 1874dfe..4402b80 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -46,6 +46,8 @@
 /* max value for numeric network address */
 #define MAX_NUMERIC_VALUE 0x
 
+#define IPSTRING_LENGTH 16
+
 /* CAVEAT VENDITOR! Keep the canonical string representation of nets/nids
  * consistent in all conversion functions.  Some code fragments are copied
  * around for the sake of clarity...
@@ -456,6 +458,317 @@ int cfs_print_nidlist(char *buffer, int count, struct 
list_head *nidlist)
 }
 EXPORT_SYMBOL(cfs_print_nidlist);
 
+/**
+ * Determines minimum and maximum addresses for a single
+ * numeric address range
+ *
+ * \param  ar
+ * \param  min_nid
+ * \param  max_nid
+ */
+static void cfs_ip_ar_min_max(struct addrrange *ar, __u32 *min_nid,
+ __u32 *max_nid)
+{
+   struct cfs_expr_list *el;
+   struct cfs_range_expr *re;
+   __u32 tmp_ip_addr = 0;
+   unsigned int min_ip[4] = {0};
+   unsigned int max_ip[4] = {0};
+   int re_count = 0;
+
+   list_for_each_entry(el, >ar_numaddr_ranges, el_link) {
+   list_for_each_entry(re, >el_exprs, re_link) {
+   min_ip[re_count] = re->re_lo;
+   max_ip[re_count] = re->re_hi;
+   re_count++;
+   }
+   }
+
+   tmp_ip_addr = ((min_ip[0] << 24) | (min_ip[1] << 16) |
+  (min_ip[2] << 8) | min_ip[3]);
+
+   if (min_nid != NULL)
+   *min_nid = tmp_ip_addr;
+
+   tmp_ip_addr = ((max_ip[0] << 24) | (max_ip[1] << 16) |
+  (max_ip[2] << 8) | max_ip[3]);
+
+   if (max_nid != NULL)
+   *max_nid = tmp_ip_addr;
+}
+
+/**
+ * Determines minimum and maximum addresses for a single
+ * numeric address range
+ *
+ * \param  ar
+ * \param  min_nid
+ * \param  max_nid
+ */
+static void cfs_num_ar_min_max(struct addrrange *ar, __u32 *min_nid,
+  __u32 *max_nid)
+{
+   struct cfs_expr_list *el;
+   struct cfs_range_expr *re;
+   unsigned int min_addr = 0;
+   unsigned int max_addr = 0;
+
+   list_for_each_entry(el, >ar_numaddr_ranges, el_link) {
+   list_for_each_entry(re, >el_exprs, re_link) {
+   if (re->re_lo < min_addr || min_addr == 0)
+   min_addr = re->re_lo;
+   if (re->re_hi > max_addr)
+   max_addr = re->re_hi;
+   }
+   }
+
+   if (min_nid != NULL)
+   *min_nid = min_addr;
+   if (max_nid != NULL)
+   *max_nid = max_addr;
+}
+
+/**
+ * Determines whether an expression list in an nidrange contains exactly
+ * one contiguous address range. Calls the correct netstrfns for the LND
+ *
+ * \param  *nidlist
+ *
+ * \retval true if contiguous
+ * \retval false if not contiguous
+ */
+bool cfs_nidrange_is_contiguous(struct list_head *nidlist)
+{
+   struct nidrange *nr;
+   struct netstrfns *nf = NULL;
+   char *lndname = NULL;
+   int netnum = -1;
+
+   list_for_each_entry(nr, nidlist, nr_link) {
+   nf = nr->nr_netstrfns;
+   if (lndname == NULL)
+   lndname = nf->nf_name;
+   if (netnum == -1)
+   netnum = nr->nr_netnum;
+
+   if (strcmp(lndname, nf->nf_name) != 0 ||
+   netnum != nr->nr_netnum)
+   return false;
+   }
+

[PATCH 03/11] staging: lustre: remove libcfs_init_string function

[James Simmons]

All the function libcfs_init_string did was initialize
a spinlock. We can initialize the spinlock statically
instead.

Signed-off-by: James Simmons 
---
 .../staging/lustre/include/linux/libcfs/libcfs.h   |2 --
 drivers/staging/lustre/lnet/lnet/nidstrings.c  |8 +---
 drivers/staging/lustre/lustre/libcfs/module.c  |2 --
 3 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 385ced1..4d74e8a 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -152,8 +152,6 @@ extern struct miscdevice libcfs_dev;
 extern char lnet_upcall[1024];
 extern char lnet_debug_log_upcall[1024];
 
-extern void libcfs_init_nidstrings(void);
-
 extern struct cfs_psdev_ops libcfs_psdev_ops;
 
 extern struct cfs_wi_sched *cfs_sched_rehash;
diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index 81ec3a8..fdbdf06 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -61,13 +61,7 @@
 static char  libcfs_nidstrings[LNET_NIDSTR_COUNT][LNET_NIDSTR_SIZE];
 static int   libcfs_nidstring_idx;
 
-static spinlock_t libcfs_nidstring_lock;
-
-void libcfs_init_nidstrings(void)
-{
-   spin_lock_init(_nidstring_lock);
-}
-EXPORT_SYMBOL(libcfs_init_nidstrings);
+static DEFINE_SPINLOCK(libcfs_nidstring_lock);
 
 char *
 libcfs_next_nidstring(void)
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c 
b/drivers/staging/lustre/lustre/libcfs/module.c
index 0d9b223..50e8fd2 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -701,8 +701,6 @@ static int init_libcfs_module(void)
 {
int rc;
 
-   libcfs_init_nidstrings();
-
rc = libcfs_debug_init(5 * 1024 * 1024);
if (rc < 0) {
pr_err("LustreError: libcfs_debug_init: %d\n", rc);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/11] staging: lustre: move struct netstrfns to nidstr.h

[James Simmons]

The reason struct netstrfns exist in nidstrings.c
was to avoid forward decleration errors. The best
way to handle this instead is to move this structure
to a header file. Since this structure is used in
the userland utilities as well so we place it in
nidstr.h which is exposed to userland.

Signed-off-by: James Simmons 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6245
Reviewed-on: http://review.whamcloud.com/15083
Reviewed-by: Dmitry Eremin 
Reviewed-by: Bob Glossman 
Reviewed-by: Oleg Drokin 
---
 drivers/staging/lustre/include/linux/lnet/nidstr.h |   13 +
 drivers/staging/lustre/lnet/lnet/nidstrings.c  |   13 -
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/linux/lnet/nidstr.h
index 082782b..b32f8cd 100644
--- a/drivers/staging/lustre/include/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/linux/lnet/nidstr.h
@@ -76,4 +76,17 @@ bool cfs_nidrange_is_contiguous(struct list_head *nidlist);
 void cfs_nidrange_find_min_max(struct list_head *nidlist, char *min_nid,
   char *max_nid, size_t nidstr_length);
 
+struct netstrfns {
+   int nf_type;
+   char*nf_name;
+   char*nf_modname;
+   void(*nf_addr2str)(__u32 addr, char *str);
+   int (*nf_str2addr)(const char *str, int nob, __u32 *addr);
+   int (*nf_parse_addrlist)(char *str, int len,
+struct list_head *list);
+   int (*nf_print_addrlist)(char *buffer, int count,
+struct list_head *list);
+   int (*nf_match_addr)(__u32 addr, struct list_head *list);
+};
+
 #endif /* _LNET_NIDSTRINGS_H */
diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index fdbdf06..6a778b9 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -208,19 +208,6 @@ libcfs_num_match(__u32 addr, struct list_head *numaddr)
return cfs_expr_list_match(addr, el);
 }
 
-struct netstrfns {
-   int   nf_type;
-   char*nf_name;
-   char*nf_modname;
-   void   (*nf_addr2str)(__u32 addr, char *str);
-   int (*nf_str2addr)(const char *str, int nob, __u32 *addr);
-   int (*nf_parse_addrlist)(char *str, int len,
-   struct list_head *list);
-   int (*nf_print_addrlist)(char *buffer, int count,
-struct list_head *list);
-   int (*nf_match_addr)(__u32 addr, struct list_head *list);
-};
-
 static struct netstrfns  libcfs_netstrfns[] = {
{/* .nf_type  */  LOLND,
 /* .nf_name  */  "lo",
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Wangnan (F)]

Hi Alexei,

On 2015/10/21 21:42, Wangnan (F) wrote:



One alternative solution I can image is to attach a BPF program
at sampling like kprobe, and return 0 if we don't want sampling
take action. Thought?


Do you think attaching BPF programs to sampling is an acceptable idea?

Thank you.


Actually speaking I don't like it very much
because the principle of soft-disable is much simpler and safe, but
if you really like it I think we can try.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/11] staging: lustre: provide separate buffers for libcfs_*2str()

[James Simmons]

From: Dmitry Eremin 

Provide duplicates with separate buffers for libcfs_*2str() functions.

Replace libcfs_nid2str() with libcfs_nid2str_r() function in critical
places.

Provide buffer size for nf_addr2str functions.

Use __u32 as nf_type always

Signed-off-by: Dmitry Eremin 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6070
Reviewed-on: http://review.whamcloud.com/13185
Reviewed-by: John L. Hammond 
Reviewed-by: Andreas Dilger 
---
 drivers/staging/lustre/include/linux/lnet/nidstr.h |   31 -
 drivers/staging/lustre/lnet/lnet/api-ni.c  |6 +-
 drivers/staging/lustre/lnet/lnet/nidstrings.c  |  138 ++--
 drivers/staging/lustre/lnet/lnet/router.c  |2 +-
 .../lustre/lustre/obdclass/lprocfs_status.c|   11 +-
 .../staging/lustre/lustre/obdclass/obd_config.c|9 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |7 +-
 drivers/staging/lustre/lustre/osc/osc_request.c|8 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|5 +-
 9 files changed, 121 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/linux/lnet/nidstr.h
index 4e7c9a5..46ad914 100644
--- a/drivers/staging/lustre/include/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/linux/lnet/nidstr.h
@@ -57,12 +57,29 @@ struct list_head;
 #define LNET_NIDSTR_COUNT  1024/* # of nidstrings */
 #define LNET_NIDSTR_SIZE   32  /* size of each one (see below for usage) */
 
-int libcfs_isknown_lnd(int type);
-char *libcfs_lnd2modname(int type);
-char *libcfs_lnd2str(int type);
+/* support decl needed by both kernel and user space */
+char *libcfs_next_nidstring(void);
+int libcfs_isknown_lnd(__u32 lnd);
+char *libcfs_lnd2modname(__u32 lnd);
+char *libcfs_lnd2str_r(__u32 lnd, char *buf, size_t buf_size);
+static inline char *libcfs_lnd2str(__u32 lnd)
+{
+   return libcfs_lnd2str_r(lnd, libcfs_next_nidstring(),
+   LNET_NIDSTR_SIZE);
+}
 int libcfs_str2lnd(const char *str);
-char *libcfs_net2str(__u32 net);
-char *libcfs_nid2str(lnet_nid_t nid);
+char *libcfs_net2str_r(__u32 net, char *buf, size_t buf_size);
+static inline char *libcfs_net2str(__u32 net)
+{
+   return libcfs_net2str_r(net, libcfs_next_nidstring(),
+   LNET_NIDSTR_SIZE);
+}
+char *libcfs_nid2str_r(lnet_nid_t nid, char *buf, size_t buf_size);
+static inline char *libcfs_nid2str(lnet_nid_t nid)
+{
+   return libcfs_nid2str_r(nid, libcfs_next_nidstring(),
+   LNET_NIDSTR_SIZE);
+}
 __u32 libcfs_str2net(const char *str);
 lnet_nid_t libcfs_str2nid(const char *str);
 int libcfs_str2anynid(lnet_nid_t *nid, const char *str);
@@ -79,10 +96,10 @@ void cfs_nidrange_find_min_max(struct list_head *nidlist, 
char *min_nid,
   char *max_nid, size_t nidstr_length);
 
 struct netstrfns {
-   int nf_type;
+   __u32   nf_type;
char*nf_name;
char*nf_modname;
-   void(*nf_addr2str)(__u32 addr, char *str);
+   void(*nf_addr2str)(__u32 addr, char *str, size_t size);
int (*nf_str2addr)(const char *str, int nob, __u32 *addr);
int (*nf_parse_addrlist)(char *str, int len,
 struct list_head *list);
diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c 
b/drivers/staging/lustre/lnet/lnet/api-ni.c
index 53ad5ef..3954126 100644
--- a/drivers/staging/lustre/lnet/lnet/api-ni.c
+++ b/drivers/staging/lustre/lnet/lnet/api-ni.c
@@ -263,7 +263,7 @@ static void lnet_assert_wire_constants(void)
 }
 
 static lnd_t *
-lnet_find_lnd_by_type(int type)
+lnet_find_lnd_by_type(__u32 type)
 {
lnd_t *lnd;
struct list_head *tmp;
@@ -272,7 +272,7 @@ lnet_find_lnd_by_type(int type)
list_for_each(tmp, _lnet.ln_lnds) {
lnd = list_entry(tmp, lnd_t, lnd_list);
 
-   if ((int)lnd->lnd_type == type)
+   if (lnd->lnd_type == type)
return lnd;
}
 
@@ -962,7 +962,7 @@ lnet_startup_lndnis(void)
struct list_head nilist;
int i;
int rc = 0;
-   int lnd_type;
+   __u32 lnd_type;
int nicount = 0;
char *nets = lnet_get_networks();
 
diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index 4402b80..b7a65da 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -693,8 +693,8 @@ void cfs_nidrange_find_min_max(struct list_head *nidlist, 
char *min_nid,
 
nf->nf_min_max(nidlist, _addr, _addr);
}
-   nf->nf_addr2str(min_addr, min_addr_str);
-   nf->nf_addr2str(max_addr, max_addr_str);
+   nf->nf_addr2str(min_addr, min_addr_str, sizeof(min_addr_str));
+   nf->nf_addr2str(max_addr, max_addr_str, sizeof(max_addr_str));
 
snprintf(min_nid, nidstr_length, 

[PATCH 07/11] staging: lustre: Avoid nid range related forward declarations in nidstring.c

[James Simmons]

Since forward declarations are frowned on upstream we move
the NID range handling to near the start of the nidstring.c
file.

Signed-off-by: James Simmons 
Reviewed-on: http://review.whamcloud.com/15086
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6245
Reviewed-by: Dmitry Eremin 
Reviewed-by: Bob Glossman 
Reviewed-by: John L. Hammond 
Reviewed-by: Oleg Drokin 
---
 drivers/staging/lustre/lnet/lnet/nidstrings.c |  782 +
 1 files changed, 395 insertions(+), 387 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index a02c1f6..1874dfe 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -63,6 +63,8 @@ static int   libcfs_nidstring_idx;
 
 static DEFINE_SPINLOCK(libcfs_nidstring_lock);
 
+static struct netstrfns *libcfs_namenum2netstrfns(const char *name);
+
 char *
 libcfs_next_nidstring(void)
 {
@@ -80,20 +82,403 @@ libcfs_next_nidstring(void)
 }
 EXPORT_SYMBOL(libcfs_next_nidstring);
 
-static int libcfs_lo_str2addr(const char *str, int nob, __u32 *addr)
+/**
+ * Nid range list syntax.
+ * \verbatim
+ *
+ *  :==  [ ' '  ]
+ * :==  '@' 
+ *:== '*' |
+ *|
+ *  
+ * :== ...
+ *  
+ *:==  |
+ *   
+ *:== '['  [ ',' ] ']'
+ *   :==  |
+ *'-'  |
+ *'-'  '/' 
+ *  :==  | 
+ *  :== "lo" | "tcp" | "o2ib" | "cib" | "openib" | "iib" |
+ *   "vib" | "ra" | "elan" | "mx" | "ptl"
+ * \endverbatim
+ */
+
+/**
+ * Structure to represent \ token of the syntax.
+ *
+ * One of this is created for each \ parsed.
+ */
+struct nidrange {
+   /**
+* Link to list of this structures which is built on nid range
+* list parsing.
+*/
+   struct list_head nr_link;
+   /**
+* List head for addrrange::ar_link.
+*/
+   struct list_head nr_addrranges;
+   /**
+* Flag indicating that *@ is found.
+*/
+   int nr_all;
+   /**
+* Pointer to corresponding element of libcfs_netstrfns.
+*/
+   struct netstrfns *nr_netstrfns;
+   /**
+* Number of network. E.g. 5 if \ is "elan5".
+*/
+   int nr_netnum;
+};
+
+/**
+ * Structure to represent \ token of the syntax.
+ */
+struct addrrange {
+   /**
+* Link to nidrange::nr_addrranges.
+*/
+   struct list_head ar_link;
+   /**
+* List head for cfs_expr_list::el_list.
+*/
+   struct list_head ar_numaddr_ranges;
+};
+
+/**
+ * Parses \ token on the syntax.
+ *
+ * Allocates struct addrrange and links to \a nidrange via
+ * (nidrange::nr_addrranges)
+ *
+ * \retval 0 if \a src parses to '*' | \ | \
+ * \retval -errno otherwise
+ */
+static int
+parse_addrange(const struct cfs_lstr *src, struct nidrange *nidrange)
+{
+   struct addrrange *addrrange;
+
+   if (src->ls_len == 1 && src->ls_str[0] == '*') {
+   nidrange->nr_all = 1;
+   return 0;
+   }
+
+   LIBCFS_ALLOC(addrrange, sizeof(struct addrrange));
+   if (addrrange == NULL)
+   return -ENOMEM;
+   list_add_tail(>ar_link, >nr_addrranges);
+   INIT_LIST_HEAD(>ar_numaddr_ranges);
+
+   return nidrange->nr_netstrfns->nf_parse_addrlist(src->ls_str,
+   src->ls_len,
+   >ar_numaddr_ranges);
+}
+
+/**
+ * Finds or creates struct nidrange.
+ *
+ * Checks if \a src is a valid network name, looks for corresponding
+ * nidrange on the ist of nidranges (\a nidlist), creates new struct
+ * nidrange if it is not found.
+ *
+ * \retval pointer to struct nidrange matching network specified via \a src
+ * \retval NULL if \a src does not match any network
+ */
+static struct nidrange *
+add_nidrange(const struct cfs_lstr *src,
+struct list_head *nidlist)
+{
+   struct netstrfns *nf;
+   struct nidrange *nr;
+   int endlen;
+   unsigned netnum;
+
+   if (src->ls_len >= LNET_NIDSTR_SIZE)
+   return NULL;
+
+   nf = libcfs_namenum2netstrfns(src->ls_str);
+   if (nf == NULL)
+   return NULL;
+   endlen = src->ls_len - strlen(nf->nf_name);
+   if (endlen == 0)
+   /* network name only, e.g. "elan" or "tcp" */
+   netnum = 0;
+   else {
+   /* e.g. "elan25" or "tcp23", refuse to parse if
+* network name is not appended with decimal or
+* hexadecimal number */
+   if (!cfs_str2num_check(src->ls_str + strlen(nf->nf_name),
+  endlen, , 0, MAX_NUMERIC_VALUE))
+   return NULL;
+   }
+
+   list_for_each_entry(nr, nidlist, nr_link) {
+   if 

[PATCH 01/11] staging: lustre: add a service that prints a nidlist

[James Simmons]

From: Gregoire Pichon 

The libcfs already provides services to parse a string into a nidlist
and to match a nid into a nidlist. This patch implements a service
that prints a nidlist into a buffer.

This is required for instance to print the nosquash_nids parameter
of the MDT procfs component.

Additionally, this patch fixes a bug in return code of
parse_addrange() routine, so that parsing of nids including
a * character works fine ('*@elan' for instance).

Signed-off-by: Gregoire Pichon 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1778
Reviewed-on: http://review.whamcloud.com/9221
Reviewed-by: Andreas Dilger 
Reviewed-by: Liang Zhen 
Reviewed-by: Oleg Drokin 
Signed-off-by: James Simmons 
---
 .../lustre/include/linux/libcfs/libcfs_string.h|2 +
 drivers/staging/lustre/include/linux/lnet/nidstr.h |2 +
 .../staging/lustre/lustre/libcfs/libcfs_string.c   |   71 +++-
 drivers/staging/lustre/lustre/libcfs/nidstrings.c  |  124 +++-
 4 files changed, 193 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
index 478e958..d178e43 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
@@ -83,6 +83,8 @@ int cfs_gettok(struct cfs_lstr *next, char delim, struct 
cfs_lstr *res);
 int cfs_str2num_check(char *str, int nob, unsigned *num,
  unsigned min, unsigned max);
 int cfs_expr_list_match(__u32 value, struct cfs_expr_list *expr_list);
+int cfs_expr_list_print(char *buffer, int count,
+   struct cfs_expr_list *expr_list);
 int cfs_expr_list_values(struct cfs_expr_list *expr_list,
 int max, __u32 **values);
 static inline void
diff --git a/drivers/staging/lustre/include/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/linux/lnet/nidstr.h
index a627be9..082782b 100644
--- a/drivers/staging/lustre/include/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/linux/lnet/nidstr.h
@@ -69,7 +69,9 @@ int libcfs_str2anynid(lnet_nid_t *nid, const char *str);
 char *libcfs_id2str(lnet_process_id_t id);
 void cfs_free_nidlist(struct list_head *list);
 int cfs_parse_nidlist(char *str, int len, struct list_head *list);
+int cfs_print_nidlist(char *buffer, int count, struct list_head *list);
 int cfs_match_nid(lnet_nid_t nid, struct list_head *list);
+
 bool cfs_nidrange_is_contiguous(struct list_head *nidlist);
 void cfs_nidrange_find_min_max(struct list_head *nidlist, char *min_nid,
   char *max_nid, size_t nidstr_length);
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index efe5e66..bbfef98 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
@@ -321,6 +321,73 @@ cfs_range_expr_parse(struct cfs_lstr *src, unsigned min, 
unsigned max,
 }
 
 /**
+ * Print the range expression \a re into specified \a buffer.
+ * If \a bracketed is true, expression does not need additional
+ * brackets.
+ *
+ * \retval number of characters written
+ */
+static int
+cfs_range_expr_print(char *buffer, int count, struct cfs_range_expr *expr,
+bool bracketed)
+{
+   int i;
+   char s[] = "[";
+   char e[] = "]";
+
+   if (bracketed)
+   s[0] = e[0] = '\0';
+
+   if (expr->re_lo == expr->re_hi)
+   i = scnprintf(buffer, count, "%u", expr->re_lo);
+   else if (expr->re_stride == 1)
+   i = scnprintf(buffer, count, "%s%u-%u%s",
+   s, expr->re_lo, expr->re_hi, e);
+   else
+   i = scnprintf(buffer, count, "%s%u-%u/%u%s",
+   s, expr->re_lo, expr->re_hi,
+   expr->re_stride, e);
+   return i;
+}
+
+/**
+ * Print a list of range expressions (\a expr_list) into specified \a buffer.
+ * If the list contains several expressions, separate them with comma
+ * and surround the list with brackets.
+ *
+ * \retval number of characters written
+ */
+int
+cfs_expr_list_print(char *buffer, int count, struct cfs_expr_list *expr_list)
+{
+   struct cfs_range_expr *expr;
+   int i = 0, j = 0;
+   int numexprs = 0;
+
+   if (count <= 0)
+   return 0;
+
+   list_for_each_entry(expr, _list->el_exprs, re_link)
+   numexprs++;
+
+   if (numexprs > 1)
+   i += scnprintf(buffer + i, count - i, "[");
+
+   list_for_each_entry(expr, _list->el_exprs, re_link) {
+   if (j++ != 0)
+   i += scnprintf(buffer + i, count - i, ",");
+   i += cfs_range_expr_print(buffer + i, count - i, expr,
+ numexprs > 1);
+   }
+
+   if (numexprs > 1)
+   i += scnprintf(buffer 

[PATCH 04/11] staging: lustre: remove cfs_ip_addr_free wrapper

[James Simmons]

No need to have a one line wrapper in libcfs that only
is used to delete a list which is only done once in the
LNet layer.

Signed-off-by: James Simmons 
---
 .../lustre/include/linux/libcfs/libcfs_string.h|1 -
 drivers/staging/lustre/lnet/lnet/config.c  |2 +-
 .../staging/lustre/lustre/libcfs/libcfs_string.c   |7 ---
 3 files changed, 1 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
index d178e43..908efaa 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
@@ -102,6 +102,5 @@ int cfs_expr_list_parse(char *str, int len, unsigned min, 
unsigned max,
 void cfs_expr_list_free_list(struct list_head *list);
 int cfs_ip_addr_parse(char *str, int len, struct list_head *list);
 int cfs_ip_addr_match(__u32 addr, struct list_head *list);
-void cfs_ip_addr_free(struct list_head *list);
 
 #endif
diff --git a/drivers/staging/lustre/lnet/lnet/config.c 
b/drivers/staging/lustre/lnet/lnet/config.c
index b09a438..1b3bc83 100644
--- a/drivers/staging/lustre/lnet/lnet/config.c
+++ b/drivers/staging/lustre/lnet/lnet/config.c
@@ -824,7 +824,7 @@ lnet_match_network_token(char *token, int len, __u32 
*ipaddrs, int nip)
for (rc = i = 0; !rc && i < nip; i++)
rc = cfs_ip_addr_match(ipaddrs[i], );
 
-   cfs_ip_addr_free();
+   cfs_expr_list_free_list();
 
return rc;
 }
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index 896185f..5166961 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
@@ -624,10 +624,3 @@ cfs_ip_addr_match(__u32 addr, struct list_head *list)
return i == 4;
 }
 EXPORT_SYMBOL(cfs_ip_addr_match);
-
-void
-cfs_ip_addr_free(struct list_head *list)
-{
-   cfs_expr_list_free_list(list);
-}
-EXPORT_SYMBOL(cfs_ip_addr_free);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/11] staging: lustre: update NID string handling

[James Simmons]

Much of the LNet network setup is managed with modprobe configuration
files. Those configurations are parse with the code in nidstring.c
which currently located in the libcfs layer. This patch series moves
nidstring.c to the LNet layer where it belongs and we update the
source with all the changes that have occured on the OpenSFS lustre
development branch.

Gregoire Pichon (1):
  staging: lustre: add a service that prints a nidlist

Joshua Walgenbach (1):
  staging: lustre: add in NID range management for libcfs

Dmitry Eremin (1):
  staging: lustre: provide separate buffers for libcfs_*2str()

Frederic Saunier (1):
  staging: lustre: remove last entry of libcfs_netstrfns[]

James Simmons (7):
  staging: lustre: move nidstring handling to LNet layer
  staging: lustre: remove libcfs_init_string function
  staging: lustre: remove cfs_ip_addr_free wrapper
  staging: lustre: move struct netstrfns to nidstr.h
  staging: lustre: move cfs_ip_addr_* function from kernel libcfs to LNet
  staging: lustre: Avoid nid range related forward declarations in nidstring.c
  staging: lustre: add in NID range management for libcfs
  staging: lustre: Use C99 initializers for struct netstrfns

 .../staging/lustre/include/linux/libcfs/libcfs.h   |2 -
 .../lustre/include/linux/libcfs/libcfs_string.h|5 +-
 drivers/staging/lustre/include/linux/lnet/nidstr.h |   47 +-
 drivers/staging/lustre/lnet/lnet/Makefile  |2 +-
 drivers/staging/lustre/lnet/lnet/api-ni.c  |6 +-
 drivers/staging/lustre/lnet/lnet/config.c  |2 +-
 drivers/staging/lustre/lnet/lnet/nidstrings.c  | 1260 
 drivers/staging/lustre/lnet/lnet/router.c  |2 +-
 drivers/staging/lustre/lustre/libcfs/Makefile  |2 +-
 .../staging/lustre/lustre/libcfs/libcfs_string.c   |  144 ++--
 drivers/staging/lustre/lustre/libcfs/module.c  |2 -
 drivers/staging/lustre/lustre/libcfs/nidstrings.c  |  842 -
 .../lustre/lustre/obdclass/lprocfs_status.c|   11 +-
 .../staging/lustre/lustre/obdclass/obd_config.c|9 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |7 +-
 drivers/staging/lustre/lustre/osc/osc_request.c|8 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|5 +-
 17 files changed, 1408 insertions(+), 948 deletions(-)
 create mode 100644 drivers/staging/lustre/lnet/lnet/nidstrings.c
 delete mode 100644 drivers/staging/lustre/lustre/libcfs/nidstrings.c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/11] staging: lustre: move cfs_ip_addr_* function from kernel libcfs to LNet

[James Simmons]

Both of cfs_ip_addr_parse and cfs_ip_addr_match which are located in
libcfs kernel module are used only for LNet so move this into the
nidstring handling code where it belongs. Also create user land
versions of these functions in the libcfs user land library.

Signed-off-by: James Simmons 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6245
Reviewed-on: http://review.whamcloud.com/15085
Reviewed-by: Bob Glossman 
Reviewed-by: Dmitry Eremin 
Reviewed-by: frank zago 
Reviewed-by: Oleg Drokin 
---
 .../lustre/include/linux/libcfs/libcfs_string.h|2 -
 drivers/staging/lustre/include/linux/lnet/nidstr.h |2 +
 drivers/staging/lustre/lnet/lnet/nidstrings.c  |   60 +++
 .../staging/lustre/lustre/libcfs/libcfs_string.c   |   62 
 4 files changed, 62 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
index 908efaa..d8d2e7d 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_string.h
@@ -100,7 +100,5 @@ void cfs_expr_list_free(struct cfs_expr_list *expr_list);
 int cfs_expr_list_parse(char *str, int len, unsigned min, unsigned max,
struct cfs_expr_list **elpp);
 void cfs_expr_list_free_list(struct list_head *list);
-int cfs_ip_addr_parse(char *str, int len, struct list_head *list);
-int cfs_ip_addr_match(__u32 addr, struct list_head *list);
 
 #endif
diff --git a/drivers/staging/lustre/include/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/linux/lnet/nidstr.h
index b32f8cd..1536366 100644
--- a/drivers/staging/lustre/include/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/linux/lnet/nidstr.h
@@ -72,6 +72,8 @@ int cfs_parse_nidlist(char *str, int len, struct list_head 
*list);
 int cfs_print_nidlist(char *buffer, int count, struct list_head *list);
 int cfs_match_nid(lnet_nid_t nid, struct list_head *list);
 
+int cfs_ip_addr_parse(char *str, int len, struct list_head *list);
+int cfs_ip_addr_match(__u32 addr, struct list_head *list);
 bool cfs_nidrange_is_contiguous(struct list_head *nidlist);
 void cfs_nidrange_find_min_max(struct list_head *nidlist, char *min_nid,
   char *max_nid, size_t nidstr_length);
diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index 6a778b9..a02c1f6 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -113,6 +113,44 @@ static int libcfs_ip_str2addr(const char *str, int nob, 
__u32 *addr)
return 0;
 }
 
+int
+cfs_ip_addr_parse(char *str, int len, struct list_head *list)
+{
+   struct cfs_expr_list *el;
+   struct cfs_lstr src;
+   int rc;
+   int i;
+
+   src.ls_str = str;
+   src.ls_len = len;
+   i = 0;
+
+   while (src.ls_str != NULL) {
+   struct cfs_lstr res;
+
+   if (!cfs_gettok(, '.', )) {
+   rc = -EINVAL;
+   goto out;
+   }
+
+   rc = cfs_expr_list_parse(res.ls_str, res.ls_len, 0, 255, );
+   if (rc != 0)
+   goto out;
+
+   list_add_tail(>el_link, list);
+   i++;
+   }
+
+   if (i == 4)
+   return 0;
+
+   rc = -EINVAL;
+out:
+   cfs_expr_list_free_list(list);
+
+   return rc;
+}
+
 static int
 libcfs_ip_addr_range_print(char *buffer, int count, struct list_head *list)
 {
@@ -128,6 +166,28 @@ libcfs_ip_addr_range_print(char *buffer, int count, struct 
list_head *list)
return i;
 }
 
+/**
+ * Matches address (\a addr) against address set encoded in \a list.
+ *
+ * \retval 1 if \a addr matches
+ * \retval 0 otherwise
+ */
+int
+cfs_ip_addr_match(__u32 addr, struct list_head *list)
+{
+   struct cfs_expr_list *el;
+   int i = 0;
+
+   list_for_each_entry_reverse(el, list, el_link) {
+   if (!cfs_expr_list_match(addr & 0xff, el))
+   return 0;
+   addr >>= 8;
+   i++;
+   }
+
+   return i == 4;
+}
+
 static void libcfs_decnum_addr2str(__u32 addr, char *str)
 {
snprintf(str, LNET_NIDSTR_SIZE, "%u", addr);
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index 5166961..d40be53 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
@@ -562,65 +562,3 @@ cfs_expr_list_free_list(struct list_head *list)
}
 }
 EXPORT_SYMBOL(cfs_expr_list_free_list);
-
-int
-cfs_ip_addr_parse(char *str, int len, struct list_head *list)
-{
-   struct cfs_expr_list*el;
-   struct cfs_lstr src;
-   int rc;
-   int i;
-
-   src.ls_str = str;
-   

[PATCH 02/11] staging: lustre: move nidstring handling to LNet layer

[James Simmons]

Moved the source file nidstring.c from libcfs to lnet
since that is the only place it is used. With the
move of nidstring to lnet some functions in libcfs
need to be exported. In later patches those functions
that are only used by LNet also will be moved to the
LNet layer. Also add in missing MAX_NUMERIC_VALUE
defination.

Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lnet/lnet/Makefile  |2 +-
 .../{lustre/libcfs => lnet/lnet}/nidstrings.c  |   13 +
 drivers/staging/lustre/lustre/libcfs/Makefile  |2 +-
 .../staging/lustre/lustre/libcfs/libcfs_string.c   |4 
 4 files changed, 15 insertions(+), 6 deletions(-)
 rename drivers/staging/lustre/{lustre/libcfs => lnet/lnet}/nidstrings.c (99%)

diff --git a/drivers/staging/lustre/lnet/lnet/Makefile 
b/drivers/staging/lustre/lnet/lnet/Makefile
index 52492fb..e276fe2 100644
--- a/drivers/staging/lustre/lnet/lnet/Makefile
+++ b/drivers/staging/lustre/lnet/lnet/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_LNET) += lnet.o
 
-lnet-y := api-ni.o config.o\
+lnet-y := api-ni.o config.o nidstrings.o   \
  lib-me.o lib-msg.o lib-eq.o lib-md.o lib-ptl.o\
  lib-socket.o lib-move.o module.o lo.o \
  router.o router_proc.o acceptor.o peer.o
diff --git a/drivers/staging/lustre/lustre/libcfs/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
similarity index 99%
rename from drivers/staging/lustre/lustre/libcfs/nidstrings.c
rename to drivers/staging/lustre/lnet/lnet/nidstrings.c
index a54594a..81ec3a8 100644
--- a/drivers/staging/lustre/lustre/libcfs/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -33,7 +33,7 @@
  * This file is part of Lustre, http://www.lustre.org/
  * Lustre is a trademark of Sun Microsystems, Inc.
  *
- * libcfs/libcfs/nidstrings.c
+ * lnet/lnet/nidstrings.c
  *
  * Author: Phil Schwan 
  */
@@ -43,6 +43,9 @@
 #include "../../include/linux/libcfs/libcfs.h"
 #include "../../include/linux/lnet/lnet.h"
 
+/* max value for numeric network address */
+#define MAX_NUMERIC_VALUE 0x
+
 /* CAVEAT VENDITOR! Keep the canonical string representation of nets/nids
  * consistent in all conversion functions.  Some code fragments are copied
  * around for the sake of clarity...
@@ -64,12 +67,13 @@ void libcfs_init_nidstrings(void)
 {
spin_lock_init(_nidstring_lock);
 }
+EXPORT_SYMBOL(libcfs_init_nidstrings);
 
-static char *
+char *
 libcfs_next_nidstring(void)
 {
-   char  *str;
-   unsigned long  flags;
+   char *str;
+   unsigned long flags;
 
spin_lock_irqsave(_nidstring_lock, flags);
 
@@ -80,6 +84,7 @@ libcfs_next_nidstring(void)
spin_unlock_irqrestore(_nidstring_lock, flags);
return str;
 }
+EXPORT_SYMBOL(libcfs_next_nidstring);
 
 static int libcfs_lo_str2addr(const char *str, int nob, __u32 *addr)
 {
diff --git a/drivers/staging/lustre/lustre/libcfs/Makefile 
b/drivers/staging/lustre/lustre/libcfs/Makefile
index ec98f44..03d3f3d 100644
--- a/drivers/staging/lustre/lustre/libcfs/Makefile
+++ b/drivers/staging/lustre/lustre/libcfs/Makefile
@@ -10,7 +10,7 @@ libcfs-linux-objs += linux-mem.o
 
 libcfs-linux-objs := $(addprefix linux/,$(libcfs-linux-objs))
 
-libcfs-all-objs := debug.o fail.o nidstrings.o module.o tracefile.o \
+libcfs-all-objs := debug.o fail.o module.o tracefile.o \
   libcfs_string.o hash.o kernel_user_comm.o \
   prng.o workitem.o libcfs_cpu.o \
   libcfs_mem.o libcfs_lock.o
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c 
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index bbfef98..896185f 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
@@ -214,6 +214,7 @@ cfs_gettok(struct cfs_lstr *next, char delim, struct 
cfs_lstr *res)
res->ls_len = end - res->ls_str + 1;
return 1;
 }
+EXPORT_SYMBOL(cfs_gettok);
 
 /**
  * Converts string to integer.
@@ -242,6 +243,7 @@ cfs_str2num_check(char *str, int nob, unsigned *num,
 
return (*num >= min && *num <= max);
 }
+EXPORT_SYMBOL(cfs_str2num_check);
 
 /**
  * Parses \ token of the syntax. If \a bracketed is false,
@@ -406,6 +408,7 @@ cfs_expr_list_match(__u32 value, struct cfs_expr_list 
*expr_list)
 
return 0;
 }
+EXPORT_SYMBOL(cfs_expr_list_match);
 
 /**
  * Convert express list (\a expr_list) to an array of all matched values
@@ -558,6 +561,7 @@ cfs_expr_list_free_list(struct list_head *list)
cfs_expr_list_free(el);
}
 }
+EXPORT_SYMBOL(cfs_expr_list_free_list);
 
 int
 cfs_ip_addr_parse(char *str, int len, struct list_head *list)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

[PATCH 11/11] staging: lustre: Use C99 initializers for struct netstrfns

[James Simmons]

Update struct netstrfns to use C99 initializers.

Remove old LND types from the netstrfns table, as they are
long obsolete and shouldn't be needed even for interop anymore.

Signed-off-by: James Simmons 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6210
Reviewed-on: http://review.whamcloud.com/15088
Reviewed-by: frank zago 
Reviewed-by: Andreas Dilger 
---
 drivers/staging/lustre/lnet/lnet/nidstrings.c |  188 +++--
 1 files changed, 51 insertions(+), 137 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c 
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index a5cd0ae..80f585a 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -893,12 +893,6 @@ libcfs_decnum_addr2str(__u32 addr, char *str, size_t size)
snprintf(str, size, "%u", addr);
 }
 
-static void
-libcfs_hexnum_addr2str(__u32 addr, char *str, size_t size)
-{
-   snprintf(str, size, "0x%x", addr);
-}
-
 static int
 libcfs_num_str2addr(const char *str, int nob, __u32 *addr)
 {
@@ -970,137 +964,57 @@ libcfs_num_match(__u32 addr, struct list_head *numaddr)
return cfs_expr_list_match(addr, el);
 }
 
-static struct netstrfns  libcfs_netstrfns[] = {
-   {/* .nf_type  */  LOLND,
-/* .nf_name  */  "lo",
-/* .nf_modname   */  "klolnd",
-/* .nf_addr2str  */  libcfs_decnum_addr2str,
-/* .nf_str2addr  */  libcfs_lo_str2addr,
-/* .nf_parse_addr*/  libcfs_num_parse,
-/* .nf_print_addrlist*/  libcfs_num_addr_range_print,
-/* .nf_match_addr*/  libcfs_num_match,
-/* .nf_is_contiguous */  cfs_num_is_contiguous,
-/* .nf_min_max   */  cfs_num_min_max},
-   {/* .nf_type  */  SOCKLND,
-/* .nf_name  */  "tcp",
-/* .nf_modname   */  "ksocklnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  libcfs_ip_addr_range_print,
-/* .nf_match_addr*/  cfs_ip_addr_match,
-/* .nf_is_contiguous */  cfs_ip_is_contiguous,
- /* .nf_min_max   */  cfs_ip_min_max},
-   {/* .nf_type  */  O2IBLND,
-/* .nf_name  */  "o2ib",
-/* .nf_modname   */  "ko2iblnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  libcfs_ip_addr_range_print,
-/* .nf_match_addr*/  cfs_ip_addr_match,
-/* .nf_is_contiguous */  cfs_ip_is_contiguous,
- /* .nf_min_max   */  cfs_ip_min_max},
-   {/* .nf_type  */  CIBLND,
-/* .nf_name  */  "cib",
-/* .nf_modname   */  "kciblnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  libcfs_ip_addr_range_print,
-/* .nf_match_addr*/  cfs_ip_addr_match,
-/* .nf_is_contiguous */  cfs_ip_is_contiguous,
- /* .nf_min_max   */  cfs_ip_min_max},
-   {/* .nf_type  */  OPENIBLND,
-/* .nf_name  */  "openib",
-/* .nf_modname   */  "kopeniblnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  libcfs_ip_addr_range_print,
-/* .nf_match_addr*/  cfs_ip_addr_match,
-/* .nf_is_contiguous */  cfs_ip_is_contiguous,
- /* .nf_min_max   */  cfs_ip_min_max},
-   {/* .nf_type  */  IIBLND,
-/* .nf_name  */  "iib",
-/* .nf_modname   */  "kiiblnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  libcfs_ip_addr_range_print,
-/* .nf_match_addr*/  cfs_ip_addr_match,
-/* .nf_is_contiguous */  cfs_ip_is_contiguous,
- /* .nf_min_max   */  cfs_ip_min_max},
-   {/* .nf_type  */  VIBLND,
-/* .nf_name  */  "vib",
-/* .nf_modname   */  "kviblnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  libcfs_ip_addr_range_print,
-/* .nf_match_addr*/  cfs_ip_addr_match,
-/* .nf_is_contiguous */  cfs_ip_is_contiguous,
- /* .nf_min_max   */  cfs_ip_min_max},
-   {/* .nf_type  */  RALND,
-/* .nf_name  */  "ra",
-/* .nf_modname   */  "kralnd",
-/* .nf_addr2str  */  libcfs_ip_addr2str,
-/* .nf_str2addr  */  libcfs_ip_str2addr,
-/* .nf_parse_addrlist*/  cfs_ip_addr_parse,
-/* .nf_print_addrlist*/  

Re: [PATCH 1/3] dt-bindings: Add document of Rockchip mailbox

[Caesar Wang]

I'm missing this patch for long time.

在 2015年10月06日 22:50, Rob Herring 写道:

On Mon, Sep 14, 2015 at 6:06 AM, Caesar Wang  wrote:

This add the necessary binding documentation for mailbox
found on RK3368 SoC.

Signed-off-by: Caesar Wang 
---

  .../bindings/mailbox/rockchip-mailbox.txt  | 33 ++
  1 file changed, 33 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
new file mode 100644
index 000..b9b4768
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
@@ -0,0 +1,33 @@
+Rockchip mailbox
+
+The Rockchip mailbox is used by the Rockchip CPU cores to communicate
+requests to MCU processor.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+
+ - compatible: should be one of the following.
+   - "rockchip,rk3368-mbox" for rk3368
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+   physical base address of the share buffer and length of memory mapped

s/share/shared/


Done.




+   region.
+ - interrupts: The interrupt number to the cpu. The interrupt specifier format
+   depends on the interrupt controller.

Need to specify the value of #mbox-cells.


Done.

+
+Example:
+
+
+/* RK3368 */
+mbox: mbox@ff6b {
+   compatible = "rockchip,rk3368-mailbox";
+   reg = <0x0 0xff6b 0x0 0x1000>,
+ <0x0 0xff8cf000 0x0 0x1000>; /* the end 4k of sram */

If this is just onchip SRAM usable for anything, then use the SRAM
binding (misc/sram.txt). It has provisions for defining the use.


Okay,  we don't need define the shared-sram in this document.


+   interrupts = ,
+,
+,
+;
+   #mbox-cells = <1>;
+};
--
1.9.1


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 for-4.4] block: flush queued bios when process blocks to avoid deadlock

[Ming Lei]

On Thu, Oct 22, 2015 at 5:49 AM, Mikulas Patocka  wrote:
>
>
> On Thu, 22 Oct 2015, Ming Lei wrote:
>
>> > Some drivers (dm-snapshot, dm-thin) do acquire a mutex in .make_requests()
>> > for every bio. It wouldn't be practical to convert them to not acquire the
>> > mutex (and it would also degrade performance of these drivers, if they had
>> > to offload every bio to a worker thread that can acquire the mutex).
>>
>> Lots of drivers handle I/O in that way, and this way makes AIO not possible
>> basically for dm-snapshot.
>
> It doesn't have to do anything with asynchronous I/O. Of course you can do
> asynchronous I/O on dm-snapshot.

But it is actually sync I/O because submit_bio() will block on the semaphore,
so this behavious isn't acceptable from AIO view. That should be why there
are very few drivers to use semaphoe/mutex in I/O path.

I have found zram has removed its rwlock from its I/O path in v3.17.

>
>> >> Also sometimes it can hurt performance by converting I/O submission
>> >> from one context into concurrent contexts of workqueue, especially
>> >> in case of sequential I/O, since plug & plug merge can't be used any
>> >> more.
>> >
>> > You can add blk_start_plug/blk_finish_plug to the function
>> > bio_alloc_rescue. That would be reasonable to make sure that the requests
>> > are merged even when they are offloaded to rescue thread.
>>
>> The IOs submitted from each wq context becomes not contineous any
>> more, so plug merge isn't doable, not mention the extra context switch
>> cost.
>
> If the requests are mergeable, blk_start_plug/blk_finish_plug will merge
> them, if not, it won't.

Plug is per task, and these requests are mergeable previously from one
same task, but after you submit them from different context via wq, it
becomes not mergeable any more via plug. Also context switch isn't free.

>
>> This kind of cost can be introduced for all bio devices just for handling
>> the unusual case, fair?
>
> Offloading bios to a worker thread when the make_request_fn function
> blocks is required to avoid a deadlock (BTW. the deadlock became more
> common in the kernel 4.3 due to unrestricted size of bios).
>
> The bio list current->bio_list introduces a false locking dependency -
> completion of a bio depends on completion of other bios on
> current->bio_list directed for different devices, thus it could create
> circular dependency resulting in deadlock.
>
> To avoid the circular dependency, each bio must be offloaded to a specific
> workqueue, so that completion of bio for device A no longer depends on
> completion of another bio for device B.

You can do that for dm-snapshot only by using per-device thread/wq or
whatever, but it isn't good to make other drivers involved by reusing
rescure wq.

>
>> >> > -   queue_work(bs->rescue_workqueue, >rescue_work);
>> >> > +   spin_lock(>rescue_lock);
>> >> > +   bio_list_add(>rescue_list, bio);
>> >> > +   queue_work(bs->rescue_workqueue, >rescue_work);
>> >> > +   spin_unlock(>rescue_lock);
>> >> > +   }
>> >>
>> >> Not like rescuring path, schedule out can be quite frequent, and the
>> >> above change will switch to submit these I/Os from wq concurrently,
>> >> which might hurt performance for sequential I/O.
>> >>
>> >> Also I am wondering why not submit these I/Os in 'current' context
>> >> just like what flush plug does?
>> >
>> > Processing requests doesn't block (they only take the queue spinlock).
>> >
>> > Processing bios can block (they can take other mutexes or semaphores), so
>> > processing them from the schedule hook is impossible - the bio's
>> > make_request function could attempt to take some lock that is already
>> > held. So - we must offload the bios to a separate workqueue.
>>
>> Yes, so better to just handle dm-snapshot in this way.
>
> All dm targets and almost all other bio-processing drivers can block in
> the make_request_fn function (for example, they may block when allocating
> from a mempool).

blk_queue_bio() and its mq pairs can block in get_request() too, and that is
acceptable, but it isn't friendly/acceptable for AIO to use mutex/semaphoe
in I/O path which can block quite frequently.

--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: next-20151021 - compile error in fs/f2fs/checkpoint.c

[Chao Yu]

Hello,

> -Original Message-
> From: Valdis Kletnieks [mailto:valdis.kletni...@vt.edu]
> Sent: Thursday, October 22, 2015 2:06 AM
> To: Chao Yu; Jaegeuk Kim; Changman Lee
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: next-20151021 - compile error in fs/f2fs/checkpoint.c
> 
> Building next-20151021 dies with this error:
> 
>   CC [M]  fs/f2fs/checkpoint.o
> fs/f2fs/checkpoint.c: In function 'get_valid_checkpoint':
> fs/f2fs/checkpoint.c:707:3: error: too few arguments to function 
> 'ra_meta_pages'
>ra_meta_pages(sbi, cp_blk_no + 1, cp_blks - 1, META_CP);

Above invoking is added in commit ("f2fs: readahead cp payload pages
when mount") at ~9/12/2015, but sadly it's complete wrong due to my fault,
so it is removed in our dev-test branch by Jaegeuk at ~9/26/2015. I can't
remember the time when this commit is removed from dev branch which is for
-next branch. I have checked next-20151022, this commit is gone, I think
the last -next will not make any trouble to you. Could you check that?

>^
> fs/f2fs/checkpoint.c:143:5: note: declared here
>  int ra_meta_pages(struct f2fs_sb_info *sbi, block_t start, int nrpages,
>  ^
> scripts/Makefile.build:258: recipe for target 'fs/f2fs/checkpoint.o' failed
> make[2]: *** [fs/f2fs/checkpoint.o] Error 1
> 
> Looks like this commit:
> 
> commit 26879fb101f28c554294eaf25ac7817a2825b180
> Author: Chao Yu 
> Date:   Mon Oct 12 17:05:59 2015 +0800
> 
> f2fs: support lower priority asynchronous readahead in ra_meta_pages
> 
> missed updating one call.  Apparently this wasn't compile-tested before
> being pushed upstream?

When this commit was updated in Jaegeuk's tree, above invoking in
fs/f2fs/checkpoint.c:707 was gone.

Thanks,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] dt-bindings: Add the "init" pinctrl in this document

[Caesar Wang]

在 2015年10月22日 09:34, Rob Herring 写道:

On Wed, Oct 21, 2015 at 8:25 PM, Caesar Wang  wrote:

The "init" pinctrl is defined we'll set
pinctrl to this state before probe and then "default" after probe.

Add the "init" pinctrl as the OTP gpio state, since we need switch
the pin to gpio state before the TSADC controller is reset.

As I know, the TSADC controller is reset, the tshut polarity will be
a *low* signal in a short period of time for some devices.

Says:
The TSADC get the temperature on rockchip thermal.

If T(current temperature) < (setting temperature), the OTP output the
*high* signal.
If T(current temperature) > (setting temperature), the OTP output the
*low* Signal.

In some cases, the OTP pin is connected to the PMIC, maybe the
PMIC can accept the reset response time to avoid this issue.

In other words, the system will be always reboot if we make the
OTP pin is connected the others IC to control the power.

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v2:
   - As the Rob comments, add the 'init' pinctrl more decription in document.

Where?


Okay,  Mr, Rob
That strictly speaking only in commit.:-(





   - fix the subject to make more obvious in PATCH[1/2]
Series-changes: 1
   - As the Doug comments, add the 'init' property to sync document.

Changes in v1: None

  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..28e84f7 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -27,8 +27,9 @@ tsadc: tsadc@ff28 {
 clock-names = "tsadc", "apb_pclk";
 resets = < SRST_TSADC>;
 reset-names = "tsadc-apb";
-   pinctrl-names = "default";
-   pinctrl-0 = <_out>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_gpio>;
+   pinctrl-1 = <_out>;
 #thermal-sensor-cells = <1>;
 rockchip,hw-tshut-temp = <95000>;
 rockchip,hw-tshut-mode = <0>;
--
1.9.1


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv

[Xiang Wang]

2015-10-15 17:40 GMT+08:00 Andy Shevchenko :
> On Thu, 2015-10-15 at 11:32 +0300, Jarkko Nikula wrote:
>> On 10/15/2015 08:46 AM, Xiang Wang wrote:
>> >
>> > In conclusion, we have 2 solutions to set the i2c controller speed
>> > mode (pci driver):
>> > 1) use hardcode value in pci driver
>> > 2) use frequency setting of "i2c device" in ACPI table (more
>> > flexible,
>> > but looks a bit strange)
>> >
>> > Do you have any preference/suggestions for above solutions? Thanks
>>
>> I don't think we can hard code especially the high-speed mode because
>>
>> most typically buses are populated with slower devices.
>>
>> Things are a bit more clear when ACPI provides timing parameters for
>> the
>> bus (for standard and fast speed modes at the moment in
>> i2c-designware-platdrv.c: dw_i2c_acpi_configure()) but still I think
>> the
>> ACPI namespace walk may be needed against potential BIOS
>> misconfigurations. For instance if it provides timing parameters for
>> all
>> speeds but there are devices with lower speed on the same bus.
>>
>> I'd take these timing parameters as configuration data for bus
>> features
>> but actual speed (speed bits in IC_CON register) is defined
>> separately.
>> To me it looks only way to achieve that is to pick slowest device
>> from
>> I2cSerialBus resource descriptors.
>
> Should it (ACPI walk) be done in PCI case as well? If so, then it needs
> to be done up to i2c-core. There you may adjust the bus speed whenever
> slave device is enumerated.
>
I think the "ACPI walk for bus speed" also works for PCI case. It'll
be good to do this in i2c-core.
By doing this we can get a minimum device speed for this bus. I2C bus
drivers can use this speed to set corresponding mode into i2c
controller.
Waiting for comments from others.

> For PCI case you have still to have hardcoded values and it should be
> maximum supported by the bus I think. When you have implemented above
> algorithm you may do this safely. Am I missing something?
Agree. It'll be safer to set a hardcoded maximum supported speed of
the bus for PCI case.
I2C bus driver can use MIN(speed_get_by_ACPI_walk,
hardcoded_max_supported_speed) for bus speed.

>
> --
> Andy Shevchenko 
> Intel Finland Oy



-- 
Regards,
Xiang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Krzysztof Kozlowski]

On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,
> 
> Thanks for your feedback.
> 
> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote:
>> On 22.10.2015 00:15, Javier Martinez Canillas wrote:
>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to
>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset
>>> logic) to be able to read the second stage from the eMMC.
>>>
>>> But this has to be called before a system reboot handler and while most
>>> of them use the priority 128, there are other restart handlers (such as
>>> the syscon-reboot one) that use a higher priority. So, use the highest
>>> priority to make sure that the eMMC hw is reset before a system reboot.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>> Tested-by: Markus Reichl 
>>> Tested-by: Anand Moon 
>>> Reviewed-by: Alim Akhtar 
>>>
>>> ---
>>> Hello,
>>>
>>> This patch was needed since a recent series from Alim [0] added
>>> syscon reboot and poweroff support to Exynos SoCs and removed
>>> the reset handler in the Exynos Power Management Unit (PMU) code.
>>>
>>> But the PMU and syscon-reboot restart handler have a different
>>> priority so [0] breaks restart when eMMC is used on these boards.
>>>
>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html
>>>
>>> So this patch must be merged before [0] to avoid regressions.
>>>
>>> Best regards,
>>> Javier
>>>
>>>  drivers/mmc/core/pwrseq_emmc.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c
>>> index 137c97fb7aa8..ad4f94ec7e8d 100644
>>> --- a/drivers/mmc/core/pwrseq_emmc.c
>>> +++ b/drivers/mmc/core/pwrseq_emmc.c
>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct 
>>> mmc_host *host,
>>>  
>>> /*
>>>  * register reset handler to ensure emmc reset also from
>>> -* emergency_reboot(), priority 129 schedules it just before
>>> -* system reboot
>>> +* emergency_reboot(), priority 255 is the highest priority
>>> +* so it will be executed before any system reboot handler.
>>>  */
>>> pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb;
>>> -   pwrseq->reset_nb.priority = 129;
>>> +   pwrseq->reset_nb.priority = 255;
>>
>> I see the problem which you are trying to solve but this may be tricker
>> then just kicking the number. Some of restart handlers are registered
>> with priority 192. I found few of such, like: at91_restart_nb,
>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too
>> much).
>>
> 
> Yes, the syscon-reboot restart handler also uses a priority 192 and that
> is why reboot with eMMC broke with Alim's patches since the PMU restart
> handler priority is 128.
> 
>> I guess they chose the "192" priority on purpose.
>>
> 
> I tried to understand what's the policy w.r.t priority numbering for
> restart handlers but only found this in the register_restart_handler
> kernel-doc [0]:
> 
> /**
>  *register_restart_handler - Register function to be called to reset
>  *   the system
>  *@nb: Info about handler function to be called
>  *@nb->priority:  Handler priority. Handlers should follow the
>  *following guidelines for setting priorities.
>  *0:  Restart handler of last resort,
>  *with limited restart capabilities
>  *128:Default restart handler; use if no other
>  *restart handler is expected to be available,
>  *and/or if restart functionality is
>  *sufficient to restart the entire system
>  *255:Highest priority restart handler, will
>  *preempt all other restart handlers
> 
> So, reading that is not clear to me if only the values 0, 128 and 255
> should be used or any value from 0-255.
> 
> What's clear to me is that restart handlers to reset a specific hw block
> should be called before the restart handler that resets the whole system.
> 
> The 192 seems to be used because there are other default restart handlers
> that are using a prio of 128. See for example the commit that changed the
> syscon-reboot prio from 128 to 192:
> 
> b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver

But were are here not talking about syscon handler but the others. Now
you will be ahead of them.

> 
> So probably the 192 value was chosen because is in the middle of 128 and
> 255 but it seems to me a rather arbitrary value and I would prefer it to
> be documented in some place.
> 
>> Effectively, now the emmc handler will be executed before their
>> handlers... is it an issue? Maybe some testing on these platforms is
>> necessary?
>>
> 
> I don't think is an issue, the reason why I chose 255 is that it is
> a documented value in the kernel-doc and since is the 

[PATCH] mm/hugetlb: i_mmap_lock_write before unmapping in remove_inode_hugepages

[Mike Kravetz]

Code was added to remove_inode_hugepages that will unmap a page if
it is mapped.  i_mmap_lock_write() must be taken during the call
to hugetlb_vmdelete_list().  This is to prevent mappings(vmas) from
being added or deleted while the list of vmas is being examined.

Signed-off-by: Mike Kravetz 
---
 fs/hugetlbfs/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index f25b72f..0f3999d 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -428,9 +428,11 @@ static void remove_inode_hugepages(struct inode *inode, 
loff_t lstart,
 * until we finish removing the page.
 */
if (page_mapped(page)) {
+   i_mmap_lock_write(mapping);
hugetlb_vmdelete_list(>i_mmap,
next * pages_per_huge_page(h),
(next + 1) * pages_per_huge_page(h));
+   i_mmap_unlock_write(mapping);
}
 
lock_page(page);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] usb: chipidea: udc: improve error handling on ep_queue

[Peter Chen]

On Fri, Sep 18, 2015 at 06:30:20PM +0100, e...@felipetonello.com wrote:
> From: "Felipe F. Tonello" 
> 
> _ep_queue() didn't check for errors when using add_td_to_list()
> which can fail if dma_pool_alloc fails, thus causing a kernel
> panic when lastnode->ptr is NULL.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
> 
> Changes for v2:
>   - Use separate patch for cleanups.
> 
>  drivers/usb/chipidea/udc.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index c936c72..7169113e 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -435,19 +435,27 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, 
> struct ci_hw_req *hwreq)
>   if (hwreq->req.dma % PAGE_SIZE)
>   pages--;
>  
> - if (rest == 0)
> - add_td_to_list(hwep, hwreq, 0);
> + if (rest == 0) {
> + ret = add_td_to_list(hwep, hwreq, 0);
> + if (ret < 0)
> + goto done;
> + }
>  
>   while (rest > 0) {
>   unsigned count = min(hwreq->req.length - hwreq->req.actual,
>   (unsigned)(pages * CI_HDRC_PAGE_SIZE));
> - add_td_to_list(hwep, hwreq, count);
> + ret = add_td_to_list(hwep, hwreq, count);
> + if (ret < 0)
> + goto done;
>   rest -= count;
>   }
>  
>   if (hwreq->req.zero && hwreq->req.length
> - && (hwreq->req.length % hwep->ep.maxpacket == 0))
> - add_td_to_list(hwep, hwreq, 0);
> + && (hwreq->req.length % hwep->ep.maxpacket == 0)) {
> + ret = add_td_to_list(hwep, hwreq, 0);
> + if (ret < 0)
> + goto done;
> + }
>  
>   firstnode = list_first_entry(>tds, struct td_node, td);
>  
> -- 
> 2.1.4
> 

Hi Felipe,

I can't apply it in my tree, would you please create it based on chipdea
tree?

https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
branch: ci-for-usb-next

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] A couple of questions about the paged I/O sub system

[Ian Kent]

On Wed, 2015-10-21 at 12:56 -0700, Hugh Dickins wrote:
> On Wed, 21 Oct 2015, Ian Kent wrote:

Thanks for taking the time to reply Hugh.

> 
> > Hi all,
> > 
> > I've been looking through some of the page reclaim code and at
> > truncate_inode_pages().
> > 
> > I'm not familiar with the code and I'm struggling to understand it.
> > 
> > One thing that is puzzling me right now is, if a file has pages
> that
> > have been modified and are swapped out when
> pagevec_lookup_entries() is
> > called will they be found?
> 
> truncate_inode_pages() is a library function which a filesystem calls
> at some stage in its inode truncation processing, to take all the
> incore
> pages out of pagecache (out of its radix_tree), and free them up
> (usually: some might be otherwise pinned in memory at the time).
> 
> A filesystem will have other work to do, very particular to that
> filesystem, to free up the actual disk blocks: that's definitely
> not part of truncate_inode_pages()'s job.
> 
> It's also called when evicting an inode no longer needed in memory,
> to free the associated pagecache, when not deleting the blocks on
> disk.
> 
> I think I don't understand your "swapped out": modifications occur to
> a page while it is in pagecache, and those modifications need to be
> written back to disk before that page can be reclaimed for other use.

Indeed, now I think about it, "swapped out" is a bad choice of words
when talking about a paged IO system.

What I'm trying to say is if pages allocated to a mapping are modified,
then under memory pressure, are they ever reclaimed by writing them to
swap storage or are they always reclaimed by writing them back to disk?

Now I think about what you've said here and looking at the code I
suspect the answer is they are always reclaimed by writing them to
disk.

> 
> > 
> > If not then how does truncate_inode_pages(_range)() handle waiting
> for
> > these pages to be swapped back in to perform the writeback and
> > truncation?
> 
> Pages are never "swapped back in to perform the writeback":
> if writeback is needed, it's done before the page can be freed from
> pagecache; and if that data is needed again after the page was freed,
> it's read back in from disk to fresh page.

That makes sense, using swap would be unnecessary double handling.

> 
> You may be worrying about what happens when a page is modified or
> under writeback when it is truncated: I think that's something each
> filesystem has to be careful of, and may deal with in different ways.

I'm wondering how a mapping nrpages can be non-zero (read greater than
one) after calling truncate_inode_pages().

But I'm looking at a much older kernel so it's quite different to
current upstream and this seemed like a question relevant to both
kernels to get some idea of how page reclaim works.

I guess what I'm really looking to work out is if it's possible, with
the current upstream kernel, for a mapping to have nrpages greater than
1 after calling truncate_inode_pages() and hopefully get some
explanation of why if that's not so.

It's certainly possible with the older kernel I'm looking at but I need
some info. before I consider looking for possible changes to back port.

> 
> I'm not sure how much to read in to your use of the word "swap".
> It's true that shmem/tmpfs uses swap (of the swapon/swapoff variety)
> as backing for its pages when under pressure (and uses its own
> variant
> shmem_undo_range() to manage that, instead of
> truncate_inode_pages()),
> but most filesystems don't use "swap" at all.
> 
> I just noticed your subject "paged I/O sub system": I hope you
> realize
> that mm/page_io.c is solely concerned with swap (of the
> swapon/swapoff
> variety), and has next to nothing to do with filesystems.  (Just as,
> conversely, mm/swap.c has next to nothing to do with swap.)

LOL, right, I'm looking at the page reclaim code which, so far, hasn't
lead me to either of those source files.

> 
> > 
> > Anyone, please?
> 
> I hope something I've said there has helped, but warn you that
> I'm a terrible person to engage in an extended conversation with!
> Expect long silences, pray for someone else to jump in.

As well as pointing out that swap storage shouldn't be used in this
case you've reminded me of the difference between swapping and demand
paging, so that's a good start.

Perhaps folks at linux-mm will have more to say.


> > Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] Add PCI support on nios2 architecture

[Ley Foon Tan]

On Thu, Oct 22, 2015 at 4:44 AM, Bjorn Helgaas  wrote:
> Hi Ley,
>
> I'm ignoring this series for now because of the build errors reported by
> the kbuild test robot.
>
> Bjorn
>
Hi Bjorn

I'm working on the newer version to fix the build errors.
Thanks.

Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] dt-bindings: Add the "init" pinctrl in this document

[Rob Herring]

On Wed, Oct 21, 2015 at 8:25 PM, Caesar Wang  wrote:
> The "init" pinctrl is defined we'll set
> pinctrl to this state before probe and then "default" after probe.
>
> Add the "init" pinctrl as the OTP gpio state, since we need switch
> the pin to gpio state before the TSADC controller is reset.
>
> As I know, the TSADC controller is reset, the tshut polarity will be
> a *low* signal in a short period of time for some devices.
>
> Says:
> The TSADC get the temperature on rockchip thermal.
>
> If T(current temperature) < (setting temperature), the OTP output the
> *high* signal.
> If T(current temperature) > (setting temperature), the OTP output the
> *low* Signal.
>
> In some cases, the OTP pin is connected to the PMIC, maybe the
> PMIC can accept the reset response time to avoid this issue.
>
> In other words, the system will be always reboot if we make the
> OTP pin is connected the others IC to control the power.
>
> Signed-off-by: Caesar Wang 
> Reviewed-by: Douglas Anderson 
> ---
>
> Changes in v2:
>   - As the Rob comments, add the 'init' pinctrl more decription in document.

Where?

>   - fix the subject to make more obvious in PATCH[1/2]
> Series-changes: 1
>   - As the Doug comments, add the 'init' property to sync document.
>
> Changes in v1: None
>
>  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> index ef802de..28e84f7 100644
> --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> @@ -27,8 +27,9 @@ tsadc: tsadc@ff28 {
> clock-names = "tsadc", "apb_pclk";
> resets = < SRST_TSADC>;
> reset-names = "tsadc-apb";
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_out>;
> +   pinctrl-names = "init", "default";
> +   pinctrl-0 = <_gpio>;
> +   pinctrl-1 = <_out>;
> #thermal-sensor-cells = <1>;
> rockchip,hw-tshut-temp = <95000>;
> rockchip,hw-tshut-mode = <0>;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller

[Rob Herring]

On Mon, Oct 19, 2015 at 1:58 AM, Marc Kleine-Budde  wrote:
> On 10/19/2015 08:39 AM, Heiko Schocher wrote:
>> add DT support for the ti hecc controller, used on
>> am3517 SoCs.
>
> A similar patch was posted a few days ago, see
> http://comments.gmane.org/gmane.linux.can/8616 and my comments.

I don't seem to have that in my inbox. Please send DT bindings to the
DT list and maintainers.

Rob

>
> Please coordinate with Anton Glukhov (Cc'ed) and/or pick up his patches
> as they are in better shape.
>
> Marc
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>>
>>  .../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
>>  arch/arm/boot/dts/am3517.dtsi  | 13 +++
>>  drivers/net/can/ti_hecc.c  | 45 
>> +-
>>  3 files changed, 76 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt 
>> b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>> new file mode 100644
>> index 000..09fab59
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>> @@ -0,0 +1,20 @@
>> +* TI HECC CAN *
>> +
>> +Required properties:
>> +  - compatible: Should be "ti,hecc"
>
> We usually put the name of the first SoC this IP core appears in to the
> compatible.
>
>> +  - reg: Should contain CAN controller registers location and length
>> +  - interrupts: Should contain IRQ line for the CAN controller
>
> I'm missing the description of the ti,* properties. I think they are
> required, too. Although the code doesn't enforce it.
>
>> +
>> +Example:
>> +
>> + can0: hecc@5c05 {
>> + compatible = "ti,hecc";
>> + reg = <0x5c05 0x4000>;
>> + interrupts = <24>;
>> + ti,hecc_scc_offset = <0>;
>> + ti,hecc_scc_ram_offset = <0x3000>;
>> + ti,hecc_ram_offset = <0x3000>;
>> + ti,hecc_mbx_offset = <0x2000>;
>> + ti,hecc_int_line = <0>;
>> + ti,hecc_version = <1>;
>
> Versioning in the OF world is done via the compatible. Are the offsets a
> per SoC parameter? I'm not sure if it's better to put
> the offsets into the driver.
>
>> + };
>> diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
>> index 5e3f5e8..47bc429 100644
>> --- a/arch/arm/boot/dts/am3517.dtsi
>> +++ b/arch/arm/boot/dts/am3517.dtsi
>> @@ -25,6 +25,19 @@
>>   interrupt-names = "mc";
>>   };
>>
>> + can0: hecc@5c05 {
>> + compatible = "ti,hecc";
>> + reg = <0x5c05 0x4000>;
>> + interrupts = <24>;
>> + ti,hecc_scc_offset = <0>;
>> + ti,hecc_scc_ram_offset = <0x3000>;
>> + ti,hecc_ram_offset = <0x3000>;
>> + ti,hecc_mbx_offset = <0x2000>;
>> + ti,hecc_int_line = <0>;
>> + ti,hecc_version = <1>;
>> + status = "disabled";
>> + };
>> +
>>   davinci_emac: ethernet@0x5c00 {
>>   compatible = "ti,am3517-emac";
>>   ti,hwmods = "davinci_emac";
>> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
>> index c08e8ea..f1705d5 100644
>> --- a/drivers/net/can/ti_hecc.c
>> +++ b/drivers/net/can/ti_hecc.c
>> @@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops 
>> = {
>>   .ndo_change_mtu = can_change_mtu,
>>  };
>>
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id ti_hecc_can_dt_ids[] = {
>> + {
>> + .compatible = "ti,hecc",
>> + }, {
>> + /* sentinel */
>> + }
>> +};
>> +MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
>> +#endif
>
> Please remove the ifdef, use __maybe_unused instead.
>
>> +
>> +static const struct ti_hecc_platform_data
>> +*ti_hecc_can_get_driver_data(struct platform_device *pdev)
>> +{
>> + if (pdev->dev.of_node) {
>> + struct ti_hecc_platform_data *data;
>> + struct device_node *np = pdev->dev.of_node;
>> +
>> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return NULL;
>> +
>> + of_property_read_u32(np, "ti,hecc_scc_offset",
>> +  >scc_hecc_offset);
>> + of_property_read_u32(np, "ti,hecc_scc_ram_offset",
>> +  >scc_ram_offset);
>> + of_property_read_u32(np, "ti,hecc_ram_offset",
>> +  >hecc_ram_offset);
>> + of_property_read_u32(np, "ti,hecc_mbx_offset",
>> +  >mbx_offset);
>> + of_property_read_u32(np, "ti,hecc_int_line",
>> +  >int_line);
>> + 

Re: [PATCH v2] iov: restore NumVFs register to 0 before return from virtfn_max_buses()

[ethan zhao]

Bjorn,

On 2015/10/22 4:54, Bjorn Helgaas wrote:

On Thu, Oct 15, 2015 at 12:16:00PM -0500, Bjorn Helgaas wrote:

Hi Ethan,

On Wed, Sep 16, 2015 at 12:19:53PM +0900, Ethan Zhao wrote:

After commit 4449f079722c ("PCI: Calculate maximum number of buses
required for VFs"),the initial value of NumVFs register was left to
non-zero after sriov_init() and no VFs was enabled in device driver.
this changed the behaviour of kernel exported by lspci and sysfs etc.
so this patch restore the NumVFs register to zero after the
calculation of max_VF_buses was done and before return from
virtfn_max_buses().

Tested on stable 4.1 and passed building on stable 4.3-rc1

Signed-off-by: Ethan Zhao 
Tested-by: Sriharsha Yadagudde 

Can you test the patch below?  I'm trying to avoid touching
PCI_SRIOV_NUM_VF in more than one place, and I think it's OK to set it
and test offset/stride at the end, instead of setting NUM_VF to zero,
testing offset/stride, computing max_bus, then setting NUM_VF to zero
again.

I applied the patch below to pci/virtualization for v4.4.


 Sorry, seems I missed your above mail, will apply your patch to my 
local branch and ask QA test again.


 Thanks,
 Ethan



commit 8e20e89658f23b8d16b1e21810e9f63c8625129c
Author: Bjorn Helgaas 
Date:   Thu Oct 15 11:31:21 2015 -0500

 PCI: Set SR-IOV NumVFs to zero after enumeration
 
 The enumeration path should leave NumVFs set to zero.  But after

 4449f079722c ("PCI: Calculate maximum number of buses required for VFs"),
 we call virtfn_max_buses() in the enumeration path, which changes NumVFs.
 This NumVFs change is visible via lspci and sysfs until a driver enables
 SR-IOV.
 
 Set NumVFs to zero after virtfn_max_buses() computes the maximum number of

 buses.
 
 Fixes: 4449f079722c ("PCI: Calculate maximum number of buses required for VFs")

 Based-on-patch-by: Ethan Zhao 
 Signed-off-by: Bjorn Helgaas 

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..0202ab0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -384,7 +384,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
int rc;
int nres;
u32 pgsz;
-   u16 ctrl, total, offset, stride;
+   u16 ctrl, total;
struct pci_sriov *iov;
struct resource *res;
struct pci_dev *pdev;
@@ -414,11 +414,6 @@ static int sriov_init(struct pci_dev *dev, int pos)
  
  found:

pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
-   pci_write_config_word(dev, pos + PCI_SRIOV_NUM_VF, 0);
-   pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, );
-   pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, );
-   if (!offset || (total > 1 && !stride))
-   return -EIO;
  
  	pci_read_config_dword(dev, pos + PCI_SRIOV_SUP_PGSIZE, );

i = PAGE_SHIFT > 12 ? PAGE_SHIFT - 12 : 0;
@@ -456,8 +451,6 @@ found:
iov->nres = nres;
iov->ctrl = ctrl;
iov->total_VFs = total;
-   iov->offset = offset;
-   iov->stride = stride;
iov->pgsz = pgsz;
iov->self = dev;
pci_read_config_dword(dev, pos + PCI_SRIOV_CAP, >cap);
@@ -475,6 +468,11 @@ found:
dev->sriov = iov;
dev->is_physfn = 1;
iov->max_VF_buses = virtfn_max_buses(dev);
+   pci_iov_set_numvfs(dev, 0);
+   if (!iov->offset || (total > 1 && !iov->stride)) {
+   rc = -EIO;
+   goto failed;
+   }
  
  	return 0;
  
@@ -484,6 +482,7 @@ failed:

res->flags = 0;
}
  
+	dev->sriov = NULL;

kfree(iov);
return rc;
  }
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [vivid] bcd56c5678: BUG: unable to handle kernel NULL pointer dereference at 0000003c

[kernel test robot]

FYI, we noticed the below changes on

git://linuxtv.org/hverkuil/media_tree.git sdrout
commit bcd56c567886b1ff0d2569d9cfe056ebbdad59c1 ("vivid: wip for sdr output")


[  123.619858] evbug: Connected device: input1 (AT Translated Set 2 keyboard at 
isa0060/serio0/input0)
[  123.662942] isa i2c-pca-isa.0: Please specify I/O base
[  123.682577] vivid-000: using single planar format API
[  123.690945] BUG: unable to handle kernel NULL pointer dereference at 003c
[  123.691050] IP: [<4104ff19>] __lock_acquire+0x72/0xd33
[  123.691050] *pde =  
[  123.691050] Oops:  [#1] 
[  123.691050] CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc1-00148-gbcd56c5 
#2
[  123.691050] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  123.691050] task: 40011000 ti: 40022000 task.ti: 40022000
[  123.691050] EIP: 0060:[<4104ff19>] EFLAGS: 00010002 CPU: 0
[  123.691050] EIP is at __lock_acquire+0x72/0xd33
[  123.691050] EAX: 0046 EBX: 0246 ECX:  EDX: 
[  123.691050] ESI: 003c EDI: 40011000 EBP: 40023d70 ESP: 40023d14
[  123.691050]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[  123.691050] CR0: 8005003b CR2: 003c CR3: 0242 CR4: 0690
[  123.691050] Stack:
[  123.691050]  0002 40023d24 41005feb 0002 40023d30 41006475  
40023d5c
[  123.691050]  41045751   cc8dfb3f 0001 40011428 0001 
40011428
[  123.691050]  40023d6c 4104f530 4224d940 4224d940 0246 003c  
40023da0
[  123.691050] Call Trace:
[  123.691050]  [<41005feb>] ? paravirt_sched_clock+0x9/0xd
[  123.691050]  [<41006475>] ? sched_clock+0x9/0xc
[  123.691050]  [<41045751>] ? sched_clock_local+0xe/0x10c
[  123.691050]  [<4104f530>] ? __lock_is_held+0x2d/0x43
[  123.691050]  [<41050eac>] lock_acquire+0x5e/0x7f
[  123.691050]  [<4173768d>] ? v4l2_ctrl_handler_setup+0x20/0xbe
[  123.691050]  [<41b17268>] mutex_lock_nested+0x48/0x2fd
[  123.691050]  [<4173768d>] ? v4l2_ctrl_handler_setup+0x20/0xbe
[  123.691050]  [<4173768d>] ? v4l2_ctrl_handler_setup+0x20/0xbe
[  123.691050]  [<41b18868>] ? __mutex_unlock_slowpath+0xf5/0xfd
[  123.691050]  [<4173768d>] v4l2_ctrl_handler_setup+0x20/0xbe
[  123.691050]  [<417447f8>] vivid_probe+0xc9f/0x171a
[  123.691050]  [<415b1695>] platform_drv_probe+0x3a/0x78
[  123.691050]  [<415b074f>] driver_probe_device+0xd1/0x1fa
[  123.691050]  [<415b08bb>] __driver_attach+0x43/0x5f
[  123.691050]  [<415af48b>] bus_for_each_dev+0x4e/0x6b
[  123.691050]  [<415b0a46>] driver_attach+0x14/0x16
[  123.691050]  [<415b0878>] ? driver_probe_device+0x1fa/0x1fa
[  123.691050]  [<415afaac>] bus_add_driver+0xb8/0x18a
[  123.691050]  [<415b0f0b>] driver_register+0x6f/0xa4
[  123.691050]  [<415b1e3d>] __platform_driver_register+0x3b/0x3d
[  123.691050]  [<423a7d31>] vivid_init+0x21/0x39
[  123.691050]  [<423a7d10>] ? viacam_driver_init+0x11/0x11
[  123.691050]  [<42375c35>] do_one_initcall+0x15e/0x16d
[  123.691050]  [<4237545b>] ? repair_env_string+0x12/0x54
[  123.691050]  [<4103ecab>] ? parse_args+0x18e/0x264
[  123.691050]  [<42375dc7>] kernel_init_freeable+0x183/0x200
[  123.691050]  [<41b147d2>] kernel_init+0x8/0xb0
[  123.691050]  [<41b1a060>] ret_from_kernel_thread+0x20/0x30
[  123.691050]  [<41b147ca>] ? rest_init+0x10e/0x10e
[  123.691050] Code: 83 3d 00 ec c0 42 00 0f 85 97 00 00 00 68 45 c4 f6 41 68 
5e 15 f6 41 68 11 0c 00 00 eb 6a 83 3d a8 c9 24 42 00 0f 84 80 00 00 00 <81> 3e 
00 ea 42 42 b8 00 00 00 00 0f 45 45 0c 89 45 0c 83 fa 01
[  123.691050] EIP: [<4104ff19>] __lock_acquire+0x72/0xd33 SS:ESP 0068:40023d14
[  123.691050] CR2: 003c
[  123.691050] ---[ end trace f7bd198a8c34c9de ]---
[  123.691050] Kernel panic - not syncing: Fatal exception





Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.3.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# 

Re: [PATCH v1 1/2] dt-bindings: Sync the dts to this document

[Caesar Wang]

在 2015年10月22日 09:18, Rob Herring 写道:

On Wed, Oct 21, 2015 at 11:48 AM, Rob Herring  wrote:

On Wed, Oct 21, 2015 at 10:45 AM, Caesar Wang  wrote:

Hi Rob,

在 2015年10月21日 23:18, Rob Herring 写道:

On Tue, Oct 20, 2015 at 9:42 PM, Caesar Wang  wrote:

Add the OTP gpio state, we need switch the pin to gpio state
before the TSADC controller is reset.

Also, please fix the subject to be specific what binding you are changing.

dt-bindings: rockchip-thermal: 


Sorry, Mr. Rob
I just sent the patch.:-(



Rob




--
Thanks,
Caesar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND net-next] net: updates HNS config and documents

[Rob Herring]

On Mon, Oct 19, 2015 at 9:36 PM, yankejian  wrote:
> updates the bindings documents and dtsi file according to the review
> comments from Rob Herring 
>
> Signed-off-by: yankejian 
> Signed-off-by: huangdaode 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt | 2 +-
>  arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 8 +++-
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt 
> b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
> index 9940aa0..9c23fdf 100644
> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
> @@ -12,7 +12,7 @@ Example:
>   mdio@803c {
> #address-cells = <1>;
> #size-cells = <0>;
> -   compatible = "hisilicon,mdio","hisilicon,hns-mdio";
> +   compatible = "hisilicon,hns-mdio","hisilicon,mdio";
> reg = <0x0 0x803c 0x0 0x1>;
>
> ethernet-phy@0 {
> diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
> index 3500586..606dd5a 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
> @@ -13,14 +13,12 @@ soc0: soc@0 {
> reg = <0x0 0x803c 0x0 0x1
>0x0 0x8000 0x0 0x1>;
>
> -   soc0_phy4: ethernet-phy@4 {
> +   soc0_phy0: ethernet-phy@0 {
> reg = <0x0>;
> -   device_type = "ethernet-phy";
> compatible = "ethernet-phy-ieee802.3-c22";
> };
> -   soc0_phy5: ethernet-phy@5 {
> +   soc0_phy1: ethernet-phy@1 {
> reg = <0x1>;
> -   device_type = "ethernet-phy";
> compatible = "ethernet-phy-ieee802.3-c22";
> };
> };
> @@ -37,7 +35,7 @@ soc0: soc@0 {
>0x0 0xc700 0x0 0x6
>>;
>
> -   phy-handle = <0 0 0 0 _phy4 _phy5 0 0>;
> +   phy-handle = <0 0 0 0 _phy0 _phy1 0 0>;
> interrupts = <
> /* [14] ge fifo err 8 / xge 6**/
> 149 0x4 150 0x4 151 0x4 152 0x4
> --
> 1.9.1
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/