Re: [PATCH] xtensa: Partially Revert "xtensa: Remove unnecessary of_platform_populate with default match table"

[Kefeng Wang]

On 2016/7/27 2:50, Max Filippov wrote:
> On Tue, Jul 26, 2016 at 01:01:32PM -0500, Rob Herring wrote:
>> This partially reverts commit 69d99e6c0d62 keeping only the main
>> purpose of the original commit which is the removal of
>> of_platform_populate() call. The moving of of_clk_init() caused changes
>> in the initialization order breaking booting.
>>
>> Fixes: 69d99e6c0d621f ("xtensa: Remove unnecessary of_platform_populate with 
>> default match table")
>> Cc: Kefeng Wang 
>> Cc: Guenter Roeck 
>> Cc: Max Filippov 
>> Signed-off-by: Rob Herring 
>> ---
>> This is on top of Guenter's build fix. Please test and I'll apply. I 

Hi all,

Sorry about the issue introduced by me, will be more careful,
and thanks Rob and Guenter to fix them.

BRs,
Kefeng


> 
> Tested-by: Max Filippov 
> 
>> tried briefly running under QEMU, but didn't have success. If anyone has 
>> up to date instructions that would be helpful as using these[1] didn't 
>> seem to work.
> 
> I think they're up to date. Another thing that need to be done right is
> the toolchain: it must match the configured CPU core. Please refer to
>   http://wiki.linux-xtensa.org/index.php/Toolchain_Overlay_File
> for more details.
> 
>>
>> [1] http://wiki.linux-xtensa.org/index.php/Xtensa_on_QEMU
>>
>>  arch/xtensa/kernel/setup.c | 9 +
>>  arch/xtensa/kernel/time.c  | 2 --
>>  2 files changed, 9 insertions(+), 2 deletions(-)
> 

linux-next: Tree for Jul 27

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160726:

My fixes tree is empty again.

The powerpc tree still had its build failure for which I applied a fix patch.

The net-next tree gained a conflict against the arm-soc tree.

The kvm tree gained a conflict against Linus' tree.

The akpm-current tree gained a conflict against the kspp tree.

Non-merge commits (relative to Linus' tree): 9127
 8362 files changed, 475335 insertions(+), 167568 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 (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 35 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 Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (3fc9d690936f Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (3fc9d690936f Merge branch 'for-4.8/drivers' of 
git://git.kernel.dk/linux-block)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (107df03203bb Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (1ba5bf993c6a xfrm: fix crash in XFRM_MSG_GETSA netlink 
handler)
Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation)
Merging sound-current/for-linus (0984d159c8ad sound: oss: Use 
kernel_read_file_from_path() for mod_firmware_load())
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (a99cde438de0 Linux 4.7-rc6)
Merging char-misc.current/char-misc-linus (dd9506954539 Merge tag 
'hwmon-for-linus-v4.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging)
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging cr

Re: [PATCH 4/9] clk: sunxi-ng: mux: Add support for mux tables

[Maxime Ripard]

On Tue, Jul 26, 2016 at 03:04:26PM +0800, Chen-Yu Tsai wrote:
> Some clock muxes have holes, i.e. invalid or unconnected inputs,
> between parent mux values.
> 
> Add support for specifying a mux table to map clock parents to
> mux values.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/clk/sunxi-ng/ccu_mux.c | 12 
>  drivers/clk/sunxi-ng/ccu_mux.h | 12 ++--
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
> index 1329b9ab481e..68b32f168a74 100644
> --- a/drivers/clk/sunxi-ng/ccu_mux.c
> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
> @@ -107,6 +107,15 @@ u8 ccu_mux_helper_get_parent(struct ccu_common *common,
>   parent = reg >> cm->shift;
>   parent &= (1 << cm->width) - 1;
>  
> + if (cm->table) {
> + int num_parents = clk_hw_get_num_parents(&common->hw);
> + int i;
> +
> + for (i = 0; i < num_parents; i++)
> + if (cm->table[i] == parent)
> + return i;
> + }
> +
>   return parent;
>  }
>  
> @@ -117,6 +126,9 @@ int ccu_mux_helper_set_parent(struct ccu_common *common,
>   unsigned long flags;
>   u32 reg;
>  
> + if (cm->table)
> + index = cm->table[index];
> +
>   spin_lock_irqsave(common->lock, flags);
>  
>   reg = readl(common->base + common->reg);
> diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
> index d35ce5e93840..f0078de78712 100644
> --- a/drivers/clk/sunxi-ng/ccu_mux.h
> +++ b/drivers/clk/sunxi-ng/ccu_mux.h
> @@ -6,8 +6,9 @@
>  #include "ccu_common.h"
>  
>  struct ccu_mux_internal {
> - u8  shift;
> - u8  width;
> + u8  shift;
> + u8  width;
> + const u8*table;
>  
>   struct {
>   u8  index;
> @@ -21,6 +22,13 @@ struct ccu_mux_internal {
>   } variable_prediv;
>  };
>  
> +#define SUNXI_CLK_MUX_TABLE(_shift, _width, _table)  \
> + {   \
> + .shift  = _shift,   \
> + .width  = _width,   \
> + .table  = _table,   \
> + }
> +

I basically had the exact same patch done a few days ago :)

This is in my A64 serie, together with some cleanup on that macro that
is not consistent with the other internal structures.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [GIT PULL] Changes for 4.8

[Juergen Gross]

On 27/07/16 08:41, Ingo Molnar wrote:
> 
> * Juergen Gross  wrote:
> 
>> Hi Linus,
>>
>> please consider pulling a patch series for 4.8 from:
>>
>>   https://github.com/jgross1/linux.git tags/for-linus-4-8
>>
>> Unfortunately 2 of the 6 patches got no Acks as the maintainers didn't
>> react in spite of multiple pings and resends. The core modification in
>> the scheduler got an Ack from Peter and multiple tests showed no
>> regressions.
>>
>> As the series is touching multiple subsystems I couldn't find anyone
>> willing to take the series via his tree (I tried Ingo, Thomas, Peter).
>>
>> Juergen Gross (6):
>>   xen: sync xen header
>>   virt, sched: add generic vcpu pinning support
>>   smp: add function to execute a function synchronously on a cpu
>>   xen: add xen_pin_vcpu() to support calling functions on a
>> dedicated pcpu
>>   dcdbas: make use of smp_call_on_cpu()
>>   hwmon: use smp_call_on_cpu() for dell-smm i8k
>>
>>  MAINTAINERS   |   1 +
>>  arch/x86/include/asm/hypervisor.h |   4 ++
>>  arch/x86/kernel/cpu/hypervisor.c  |  11 +
>>  arch/x86/xen/enlighten.c  |  40 +++
>>  drivers/firmware/dcdbas.c |  51 +--
>>  drivers/hwmon/dell-smm-hwmon.c|  36 --
>>  include/linux/hypervisor.h|  17 +++
>>  include/linux/smp.h   |   3 ++
>>  include/xen/interface/sched.h | 100 
>> +++---
>>  kernel/smp.c  |  51 +++
>>  kernel/up.c   |  18 +++
>>  11 files changed, 273 insertions(+), 59 deletions(-)
>>  create mode 100644 include/linux/hypervisor.h
> 
> Sorry, I didn't comment on this series because the concept seemed
> uncontroversial to me: you are trying to extend the virtualization
> interface to follow hardware constraints and fix bugs.
> 
> PeterZ acked the most critical bits (smp.c) and most of the changes
> are on the virtualization side.
> 
> So it's fine to me in principle, but I have not looked into finer
> details. Can take it into one of the -tip trees if Linus doesn't
> pull it for v4.8.

Thanks. I'd appreciate that.


Juergen

Re: linux-next: build warning after merge of the net-next tree

[Iyappan Subramanian]

On Tue, Jul 26, 2016 at 11:35 PM, Stephen Rothwell  
wrote:
> Hi David,
>
> On Tue, 26 Jul 2016 23:19:59 -0700 (PDT) David Miller  
> wrote:
>>
>> Fixed thusly:
>>
>> 
>> From 36232012344b8db67052432742deaf17f82e70e6 Mon Sep 17 00:00:00 2001
>> From: "David S. Miller" 
>> Date: Tue, 26 Jul 2016 23:19:29 -0700
>> Subject: [PATCH] xgene: Fix build warning with ACPI disabled.
>>
>> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
>> 'xgene_enet_phy_connect':
>> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused 
>> variable 'adev' [-Wunused-variable]
>>
>> Fixes: 8089a96f601b ("drivers: net: xgene: Add backward compatibility")
>> Reported-by: Stephen Rothwell 
>> Signed-off-by: David S. Miller 
>> ---
>>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
>> b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> index 8a2a221..7714b7d 100644
>> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> @@ -756,7 +756,6 @@ int xgene_enet_phy_connect(struct net_device *ndev)
>>   struct device_node *np;
>>   struct phy_device *phy_dev;
>>   struct device *dev = &pdata->pdev->dev;
>> - struct acpi_device *adev;
>>   int i;
>>
>>   if (dev->of_node) {
>> @@ -781,7 +780,7 @@ int xgene_enet_phy_connect(struct net_device *ndev)
>>   pdata->phy_dev = phy_dev;
>>   } else {
>>  #ifdef CONFIG_ACPI
>> - adev = acpi_phy_find_device(dev);
>> + struct acpi_device *adev = acpi_phy_find_device(dev);
>>   if (adev)
>>   pdata->phy_dev =  adev->driver_data;
>
> Looks good to me, thanks.

Thanks David, for the quick fix.

>
> --
> Cheers,
> Stephen Rothwell

Re: [PATCH 3/9] clk: sunxi-ng: mux: Increase fixed pre-divider div size

[Maxime Ripard]

On Tue, Jul 26, 2016 at 03:04:25PM +0800, Chen-Yu Tsai wrote:
> Some clocks have a predivider value that is larger than what u8 can
> store. One such example is the OUT clk found on A20/A31, which has
> a /750 pre-divider on one of the osc24M parents.
> 
> Increase the size of the div field to u16.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [GIT PULL] Changes for 4.8

[Ingo Molnar]

* Juergen Gross  wrote:

> Hi Linus,
> 
> please consider pulling a patch series for 4.8 from:
> 
>   https://github.com/jgross1/linux.git tags/for-linus-4-8
> 
> Unfortunately 2 of the 6 patches got no Acks as the maintainers didn't
> react in spite of multiple pings and resends. The core modification in
> the scheduler got an Ack from Peter and multiple tests showed no
> regressions.
> 
> As the series is touching multiple subsystems I couldn't find anyone
> willing to take the series via his tree (I tried Ingo, Thomas, Peter).
> 
> Juergen Gross (6):
>   xen: sync xen header
>   virt, sched: add generic vcpu pinning support
>   smp: add function to execute a function synchronously on a cpu
>   xen: add xen_pin_vcpu() to support calling functions on a
> dedicated pcpu
>   dcdbas: make use of smp_call_on_cpu()
>   hwmon: use smp_call_on_cpu() for dell-smm i8k
> 
>  MAINTAINERS   |   1 +
>  arch/x86/include/asm/hypervisor.h |   4 ++
>  arch/x86/kernel/cpu/hypervisor.c  |  11 +
>  arch/x86/xen/enlighten.c  |  40 +++
>  drivers/firmware/dcdbas.c |  51 +--
>  drivers/hwmon/dell-smm-hwmon.c|  36 --
>  include/linux/hypervisor.h|  17 +++
>  include/linux/smp.h   |   3 ++
>  include/xen/interface/sched.h | 100 
> +++---
>  kernel/smp.c  |  51 +++
>  kernel/up.c   |  18 +++
>  11 files changed, 273 insertions(+), 59 deletions(-)
>  create mode 100644 include/linux/hypervisor.h

Sorry, I didn't comment on this series because the concept seemed
uncontroversial to me: you are trying to extend the virtualization
interface to follow hardware constraints and fix bugs.

PeterZ acked the most critical bits (smp.c) and most of the changes
are on the virtualization side.

So it's fine to me in principle, but I have not looked into finer
details. Can take it into one of the -tip trees if Linus doesn't
pull it for v4.8.

Thanks,

Ingo

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Kalle Valo]

alexmcwhir...@triadic.us writes:

> On 2016-07-26 09:59, Christian Lamparter wrote:
>> Thanks, I gave the program a try with my WNDA3100 and a WN821N v2
>> devices.
>> I did not see any corruptions in any of the tests though. Can you
>> tell me
>> something about your wireless network too? I would like to know what
>> router
>> and firmware are you using? Also important: what's your wireless
>> configuration?
>> (WPA?, CCMP or TKIP? HT40, HT20 or Legacy rates? ...)
>>
>> Probably the quickest and easiest way to get that information is by
>> running
>> the following commands as root, when you are connected to your wifi
>> network
>> and post the results:
>> # iw dev wlan0 link
>> # iw dev wlan0 scan dump
>>
>> (You can of course remove your device's MACs, but please do it
>> consistently).
>>
>> Regards,
>> Christian
>
> I wonder if this is something that is only affecting certain NIC's?
> For example, it see this issue on sun4u boxes with tigon3 and hme
> interfaces. But on my sun4v boxes that have e1000 interfaces
> everything works fine.

Kernel configuration might also make a difference. Trying to find an
Kconfig option which affects this could be useful.

-- 
Kalle Valo

Re: linux-next: build warning after merge of the net-next tree

[Stephen Rothwell]

Hi David,

On Tue, 26 Jul 2016 23:19:59 -0700 (PDT) David Miller  
wrote:
>
> Fixed thusly:
> 
> 
> From 36232012344b8db67052432742deaf17f82e70e6 Mon Sep 17 00:00:00 2001
> From: "David S. Miller" 
> Date: Tue, 26 Jul 2016 23:19:29 -0700
> Subject: [PATCH] xgene: Fix build warning with ACPI disabled.
> 
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
> 'xgene_enet_phy_connect':
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused 
> variable 'adev' [-Wunused-variable]
> 
> Fixes: 8089a96f601b ("drivers: net: xgene: Add backward compatibility")
> Reported-by: Stephen Rothwell 
> Signed-off-by: David S. Miller 
> ---
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
> b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> index 8a2a221..7714b7d 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> @@ -756,7 +756,6 @@ int xgene_enet_phy_connect(struct net_device *ndev)
>   struct device_node *np;
>   struct phy_device *phy_dev;
>   struct device *dev = &pdata->pdev->dev;
> - struct acpi_device *adev;
>   int i;
>  
>   if (dev->of_node) {
> @@ -781,7 +780,7 @@ int xgene_enet_phy_connect(struct net_device *ndev)
>   pdata->phy_dev = phy_dev;
>   } else {
>  #ifdef CONFIG_ACPI
> - adev = acpi_phy_find_device(dev);
> + struct acpi_device *adev = acpi_phy_find_device(dev);
>   if (adev)
>   pdata->phy_dev =  adev->driver_data;

Looks good to me, thanks.

-- 
Cheers,
Stephen Rothwell

RE: Why does BIOS assign memory to 16 byte BAR

[Bharat Kumar Gogada]

> Your system host bridge: has resource
> pci_bus :00: root bus resource [mem 0xe010-0xefff] pci_bus
> :00: root bus resource [mem 0x6-0x7 pref] then one pci
> bridge:
> pci :00:00.0
> then :01:00.0 have four bars:
> pci :01:00.0: BAR 0:  [mem size 0x4000] pci :01:00.0: BAR 4:
> [mem size 0x0010 64bit] pci :01:00.0: BAR 2:  [mem size 0x0010]
> pci :01:00.0: BAR 3:  [mem size 0x0010]
> 
> 
> kernel need to get allocation for pci :00:00.0 at first
> 
> but can not find big enough space.
> 
> pci :00:00.0: BAR 8: no space for [mem size 0x6000] as it should
> come from [mem 0xe010-0xefff], and that is less 1.5G.
> 
> so all children resource from pci :01:00.0 all fail.
> 
> 
> please check if you modify your FPGA code to make pci :01:00.0
> 
> BAR 0, and BAR 4 to use 64bit pref instead non-pref mmio.
> 
> or you can check if can increase root bus mmio range
> 
>  MEM 0xe010..0xefff -> 0xe010 nwl-pcie fd0e.pcie: PCI host
> bridge to bus :00
> 
> to have more than 1.5G.
> 
Thanks Yinghai Lu.
We see that similar test is passing in x86 machine, where function one 
requesting 1GB BAR's is failing,
but function two requesting BAR's with 16byte is getting assigned BAR's.

To my knowledge on x86 BIOS assigns resources, or will kernel assign reosurces 
on x86 ?
If kernel does is there any difference between x86 and arm64 resource 
assignment logic ?

Thanks & Regards,
Bharat

  

Re: linux-next: build warnings after merge of the libata tree

[Stephen Rothwell]

Hi Tejun,

On Thu, 21 Jul 2016 10:44:59 -0400 Tejun Heo  wrote:
>
> On Thu, Jul 21, 2016 at 03:26:03PM +1000, Stephen Rothwell wrote:
> > Hi Tejun,
> > 
> > After merging the libata tree, today's linux-next build (arm
> > multi_v7_defconfig) produced these warning:
> > 
> > drivers/ata/libata-scsi.c: In function 'ata_mselect_caching':
> > drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around 
> > comparison in operand of '&' [-Wparentheses]
> > if (mpage[i + 2] & 0xfb != buf[i] & 0xfb) {
> > ^
> > drivers/ata/libata-scsi.c: In function 'ata_mselect_control':
> > drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around 
> > comparison in operand of '&' [-Wparentheses]
> > if (mpage[i + 2] & 0xfb != buf[i] & 0xfb) {
> > ^
> > 
> > Introduced by commit
> > 
> >   9b7844a8c34a ("libata-scsi: fix read-only bits checking in 
> > ata_mselect_*()")  
> 
> Already reverted the patch.  Sorry about that.

This patch is still in the libata tree
(git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next)
-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi Andrew,

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

  Makefile

between commit:

  228d96c603cf ("kbuild: Abort build on bad stack protector flag")

from the kspp tree and commit:

  f273155b8dc7 ("kbuild: abort build on bad stack protector flag")

from the akpm-current tree.

I fixed it up (I just arbitrarily used the version from the kspp tree)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v4] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

[Maxime Ripard]

On Wed, Jul 27, 2016 at 08:12:29AM +0300, stefan.mavrod...@gmail.com wrote:
> > > +®_dcdc1 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <330>;
> > > + regulator-max-microvolt = <330>;
> > > + regulator-name = "vcc-dsi";
> > > +};
> > 
> > What is it used for? Is it really necessary to keep it on at all time?
> 
> I think so.
> This is the supply for the MMC.

Then it's poorly named, and you should tie it to the MMC, and remove
the always-on if it's only used by the mmc. always-on is supposed to
be for regulators that shouldn't but turned off for the system to stay
running. Some MMC regulator doesn't fit that description.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 27 Jul 2016 16:15:33 +1000

> Hi all,
> 
> After merging the net-next tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
> 
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
> 'xgene_enet_phy_connect':
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused 
> variable 'adev' [-Wunused-variable]
>   struct acpi_device *adev;
>   ^
> 
> Introduced by commit
> 
>   8089a96f601b ("drivers: net: xgene: Add backward compatibility")
> (CONFIG_ACPI si not set for tis build)

Fixed thusly:


>From 36232012344b8db67052432742deaf17f82e70e6 Mon Sep 17 00:00:00 2001
From: "David S. Miller" 
Date: Tue, 26 Jul 2016 23:19:29 -0700
Subject: [PATCH] xgene: Fix build warning with ACPI disabled.

drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
'xgene_enet_phy_connect':
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 
'adev' [-Wunused-variable]

Fixes: 8089a96f601b ("drivers: net: xgene: Add backward compatibility")
Reported-by: Stephen Rothwell 
Signed-off-by: David S. Miller 
---
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 8a2a221..7714b7d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -756,7 +756,6 @@ int xgene_enet_phy_connect(struct net_device *ndev)
struct device_node *np;
struct phy_device *phy_dev;
struct device *dev = &pdata->pdev->dev;
-   struct acpi_device *adev;
int i;
 
if (dev->of_node) {
@@ -781,7 +780,7 @@ int xgene_enet_phy_connect(struct net_device *ndev)
pdata->phy_dev = phy_dev;
} else {
 #ifdef CONFIG_ACPI
-   adev = acpi_phy_find_device(dev);
+   struct acpi_device *adev = acpi_phy_find_device(dev);
if (adev)
pdata->phy_dev =  adev->driver_data;
 
-- 
2.1.0

linux-next: build warning after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
'xgene_enet_phy_connect':
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 
'adev' [-Wunused-variable]
  struct acpi_device *adev;
  ^

Introduced by commit

  8089a96f601b ("drivers: net: xgene: Add backward compatibility")
(CONFIG_ACPI si not set for tis build)

-- 
Cheers,
Stephen Rothwell

[RFC] net/mlx5_core/en_main: Remove deprecated create_workqueue

[Bhaktipriya Shridhar]

alloc_ordered_workqueue() with WQ_MEM_RECLAIM set replaces
deprecated create_singlethread_workqueue(). This is the identity
conversion.

A dedicated workqueue has been used since mlx5e workqueue was created to
handle all mlx5e specific tasks. This is in preparation for vxlan using
the mlx5e workqueue in order to schedule port add/remove operations.
WQ_MEM_RECLAIM has been set to guarantee forward progress under memory
pressure.

Can the workitems be executed concurrently?
Are the workitems being used on a memory reclaim path?

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index fd43929..1a96445 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3042,7 +3042,7 @@ static void *mlx5e_create_netdev(struct mlx5_core_dev 
*mdev)

priv = netdev_priv(netdev);

-   priv->wq = create_singlethread_workqueue("mlx5e");
+   priv->wq = alloc_ordered_workqueue("mlx5e", WQ_MEM_RECLAIM);
if (!priv->wq)
goto err_free_netdev;

--
2.1.4

[PATCH v4 4.8] x86/ptrace: Stop setting TS_COMPAT in ptrace code

[Andy Lutomirski]

Setting TS_COMPAT in ptrace is wrong: if we happen to do it during
syscall entry, then we'll confuse seccomp and audit.  (The former
isn't a security problem: seccomp is currently entirely insecure if a
malicious ptracer is attached.)  As a minimal fix, this patch adds a
new flag TS_I386_REGS_POKED that handles the ptrace special case.

Cc: Pedro Alves 
Cc: Kees Cook 
Acked-by: Oleg Nesterov 
Signed-off-by: Andy Lutomirski 
---

This is identical to v3 except that I added Oleg's ack and I split
it out from the rest of the series.  The other patches need some work
before I'll be fully comfortable with them.

This will have a trivial conflict with -mm.

 arch/x86/entry/common.c|  6 +-
 arch/x86/include/asm/syscall.h |  5 +
 arch/x86/include/asm/thread_info.h |  3 +++
 arch/x86/kernel/ptrace.c   | 15 +--
 arch/x86/kernel/signal.c   | 26 --
 5 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index ec138e538c44..0db497a8ff19 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -270,8 +270,12 @@ __visible inline void prepare_exit_to_usermode(struct 
pt_regs *regs)
 * handling, because syscall restart has a fixup for compat
 * syscalls.  The fixup is exercised by the ptrace_syscall_32
 * selftest.
+*
+* We also need to clear TS_REGS_POKED_I386: the 32-bit tracer
+* special case only applies after poking regs and before the
+* very next return to user mode.
 */
-   ti->status &= ~TS_COMPAT;
+   ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
 #endif
 
user_enter();
diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
index 999b7cd2e78c..4e23dd15c661 100644
--- a/arch/x86/include/asm/syscall.h
+++ b/arch/x86/include/asm/syscall.h
@@ -60,7 +60,7 @@ static inline long syscall_get_error(struct task_struct *task,
 * TS_COMPAT is set for 32-bit syscall entries and then
 * remains set until we return to user mode.
 */
-   if (task_thread_info(task)->status & TS_COMPAT)
+   if (task_thread_info(task)->status & (TS_COMPAT|TS_I386_REGS_POKED))
/*
 * Sign-extend the value so (int)-EFOO becomes (long)-EFOO
 * and will match correctly in comparisons.
@@ -239,9 +239,6 @@ static inline int syscall_get_arch(void)
 * TS_COMPAT is set for 32-bit syscall entry and then
 * remains set until we return to user mode.
 *
-* TIF_IA32 tasks should always have TS_COMPAT set at
-* system call time.
-*
 * x32 tasks should be considered AUDIT_ARCH_X86_64.
 */
if (task_thread_info(current)->status & TS_COMPAT)
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 30c133ac05cd..4bca518d11f4 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -228,6 +228,9 @@ static inline unsigned long current_stack_pointer(void)
  * have to worry about atomic accesses.
  */
 #define TS_COMPAT  0x0002  /* 32bit syscall active (64BIT)*/
+#ifdef CONFIG_COMPAT
+#define TS_I386_REGS_POKED 0x0004  /* regs poked by 32-bit ptracer */
+#endif
 #define TS_RESTORE_SIGMASK 0x0008  /* restore signal mask in do_signal() */
 
 #ifndef __ASSEMBLY__
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 600edd225e81..f79576a541ff 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -923,15 +923,18 @@ static int putreg32(struct task_struct *child, unsigned 
regno, u32 value)
 
case offsetof(struct user32, regs.orig_eax):
/*
-* A 32-bit debugger setting orig_eax means to restore
-* the state of the task restarting a 32-bit syscall.
-* Make sure we interpret the -ERESTART* codes correctly
-* in case the task is not actually still sitting at the
-* exit from a 32-bit syscall with TS_COMPAT still set.
+* Warning: bizarre corner case fixup here.  A 32-bit
+* debugger setting orig_eax to -1 wants to disable
+* syscall restart.  Make sure that the syscall
+* restart code sign-extends orig_ax.  Also make sure
+* we interpret the -ERESTART* codes correctly if
+* loaded into regs->ax in case the task is not
+* actually still sitting at the exit from a 32-bit
+* syscall with TS_COMPAT still set.
 */
regs->orig_ax = value;
if (syscall_get_nr(child, regs) >= 0)
-   task_thread_info(child)->status |= TS_COMPAT;
+   task_thread_info(child)->status |= TS_I386_REGS_POKED;
break;
 
case offsetof(struct user32, regs.eflags):

Re: [tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

[Borislav Petkov]

On Tue, Jul 26, 2016 at 01:37:07PM -0700, Kees Cook wrote:
> These ifdefs aren't needed if we added a no-op __PAGE_OFFSET_BASE to
> the 32-bit page table headers. Then the compiler will DTRT with the
> start calculation. When CONFIG_RANDOMIZE_MEMORY is set, start will
> have a non-zero value, and when not set it'll be 0.

Something like this? I'm trying to mimick the 64-bit version:

---
diff --git a/arch/x86/include/asm/page_32_types.h 
b/arch/x86/include/asm/page_32_types.h
index 3a52ee0e726d..3bae4969ac65 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -13,7 +13,8 @@
  * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
  * and CONFIG_HIGHMEM64G options in the kernel configuration.
  */
-#define __PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
+#define __PAGE_OFFSET_BASE _AC(CONFIG_PAGE_OFFSET, UL)
+#define __PAGE_OFFSET  __PAGE_OFFSET_BASE
 
 #define __START_KERNEL_map __PAGE_OFFSET
 
-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Borislav Petkov]

On Tue, Jul 26, 2016 at 02:17:29PM -0700, Thomas Garnier wrote:
> I am sorry, there has been parallel work between KASLR memory
> randomization and hibernation support. That's why hibernation was not
> tested, it was not supported when the feature was created.
> Communication will be better next time.
> 
> I will work on identifying the problem and pushing a fix.

Would you please do me a favor and stop top-posting. It really disrupts
reading the thread.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] ACPICA: cleanup method properly on error

[Vegard Nossum]

On 07/26/2016 10:28 PM, Moore, Robert wrote:

 /* Put the new state at the head of the walk list */

 if (Thread)
 {
 AcpiDsPushWalkState (WalkState, Thread);
 }

Is there any chance that Thread could be zero?


I'm not sure if this question was for me or not, but that code (modulo
the capitalisation differences) is the reason why I also used 'if
(thread)' in my patch.


Vegard




-Original Message-
From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, July 26, 2016 7:40 AM
To: Vegard Nossum ; Zheng, Lv
; Wysocki, Rafael J 
Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
sta...@vger.kernel.org; de...@acpica.org
Subject: Re: [Devel] [PATCH] ACPICA: cleanup method properly on error

We'll look at this.
Thanks.



-Original Message-
From: Vegard Nossum [mailto:vegard.nos...@oracle.com]
Sent: Friday, July 22, 2016 8:35 AM
To: Moore, Robert ; Zheng, Lv
; Wysocki, Rafael J 
Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
ker...@vger.kernel.org; Vegard Nossum ;
sta...@vger.kernel.org
Subject: [PATCH] ACPICA: cleanup method properly on error

If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
walk state push done by acpi_ds_create_walk_state(). Otherwise, the
new walk state (which has just been freed) will remain on the thread's
walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
to get the new state.

You can observe this when reading e.g.

 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status

Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum 
---
  drivers/acpi/acpica/dsmethod.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/acpica/dsmethod.c
b/drivers/acpi/acpica/dsmethod.c index 47c7b52..44b50a6 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -596,6 +596,8 @@ cleanup:
/* On error, we must terminate the method properly */

acpi_ds_terminate_control_method(obj_desc, next_walk_state);
+   if (thread)
+   acpi_ds_pop_walk_state(thread);
acpi_ds_delete_walk_state(next_walk_state);

return_ACPI_STATUS(status);
--
1.9.1


___
Devel mailing list
de...@acpica.org
https://lists.acpica.org/mailman/listinfo/devel

Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Eric Anholt]

Rob Clark  writes:

> On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt  wrote:
>> Rob Clark  writes:
>>
>>> On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt  wrote:
 Overflow memory handling is tricky: While it's still referenced by the
 BPO registers, we want to keep it from being freed.  When we are
 putting a new set of overflow memory in the registers, we need to
 assign the old one to the last rendering job using it.

 We were looking at "what's currently running in the binner", but since
 the bin/render submission split, we may end up with the binner
 completing and having no new job while the renderer is still
 processing.  So, if we don't find a bin job at all, look at the
 highest-seqno (last) render job to attach our overflow to.
>>>
>>> so, drive-by comment.. but can you allocate gem bo's without backing
>>> them immediately with pages?  If so, just always allocate the bo
>>> up-front and attach it as a dependency of the batch, and only pin it
>>> to actual pages when you have to overflow?
>>
>> The amount of overflow for a given CL is arbitrary, depending on the
>> geometry submitted, and the overflow pool just gets streamed into by the
>> hardware as you submit bin jobs.  You'll end up allocating [0,n] new
>> overflows per bin job.  I don't see where "allocate gem BOs without
>> backing them immediately with pages" idea would fit into this.
>
> well, even not knowing the size up front shouldn't really be a
> show-stopper, unless you had to mmap it to userspace, perhaps..
> normally backing pages aren't allocated until drm_gem_get_pages() so
> allocating the gem bo as placeholder to track dependencies of the
> batch/submit shouldn't be an issue.  But I noticed you don't use
> drm_gem_get_pages().. maybe w/ cma helpers it is harder to decouple
> allocation of the drm_gem_object from the backing store.

There's no period of time between "I need to allocate an overflow BO"
and "I need pages in the BO", though.

I could have a different setup that allocated a massive (all of CMA?),
fresh overflow BO per CL and populated page ranges in it as I overflow,
but with CMA you really need to never do new allocations in the hot path
because you get to stop and wait approximately forever.  So you'd want
to chunk it up so you could cache the groups of contiguous pages of
overflow, and it turns out we already have a thing for this in the form
of GEM BOs.  Anyway, doing that that means you're losing out on the rest
of the last overflow BO for the new CL, expanding the working set in
your precious 256MB CMA area.

Well, OK, actually I *do* allocate a fresh overflow BO per CL today,
because of leftover bringup code that I think I could just delete at
this point.  I'm not doing that in a -fixes commit, though.


signature.asc
Description: PGP signature

[PATCH v4 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances. The code has been
tested and works on SMP, but will not be usable without additional
J-Core SMP-support patches and appropriate hardware capable of running
SMP.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds.
The driver converts these to a 64-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 277 
 3 files changed, 286 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 47352d2..b6d4d43 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -313,6 +313,14 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 473974f..b41a834 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..373b9f9
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,277 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT 12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT 26
+#define PIT_IRQ_MASK 0x3f
+#define PIT_PRIO_MASK 0xf
+
+#define REG_PITEN 0x00
+#define REG_THROT 0x10
+#define REG_COUNT 0x14
+#define REG_BUSPD 0x18
+#define REG_SECHI 0x20
+#define REG_SECLO 0x24
+#define REG_NSEC  0x28
+
+struct jcore_clocksource {
+   struct clocksource cs;
+   __iomem void *base;
+};
+
+struct jcore_pit {
+   struct clock_event_device ced;
+   __iomem void *base;
+   unsigned long periodic_delta;
+   unsigned cpu;
+   u32 enable_val;
+};
+
+struct jcore_pit_nb {
+   struct notifier_block nb;
+   struct jcore_pit __percpu *pit_percpu;
+};
+
+static struct clocksource *jcore_cs;
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   __iomem void *base =
+   container_of(cs, struct jcore_clocksource, cs)->base;
+   u32 sechi, seclo, nsec, sechi0, seclo0;
+
+   sechi = __raw_readl(base + REG_SECHI);
+   seclo = __raw_readl(base + REG_SECLO);
+   do {
+   sechi0 = sechi;
+   seclo0 = seclo;
+   nsec  = __raw_readl(base + REG_NSEC);
+   sechi = __raw_readl(base + REG_SECHI);
+   seclo = __raw_readl(base + REG_SECLO);
+   } while (sechi0 != sechi || seclo0 != seclo);
+
+   return ((u64)sechi << 32 | seclo) * NSEC_PER_SEC + nsec;
+}
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   return jcore_clocksource_read(jcore_cs);
+}
+
+static int jcore

[PATCH v4 0/2] J-Core timer support

[Rich Felker]

This driver is used with the J2, an open-source VHDL reimplementation
of SH-2.

I've split this out from the main J-Core support patches going
upstream through my own linux-sh tree. Changes since the v3 are mainly
cleanup/simplification, inclusion of sched_clock support based on
suggestions by Daniel Lezcano, and reworking the DT bindings to use
separate reg ranges per cpu rather than cpu-offset for greater
flexibility.

Rich


Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  25 ++
 drivers/clocksource/Kconfig|   8 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 277 +
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.8.1

[PATCH v4 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..0f42af4
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,25 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number (which is also the logical cpu
+  number).
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.8.1

[PATCH v4 1/2] of: add J-Core interrupt controller bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
new file mode 100644
index 000..b7a56ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
@@ -0,0 +1,26 @@
+J-Core Advanced Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic
+  with 8 interrupt lines with programmable priorities, or "jcore,aic2" for
+  the "aic2" core with 64 interrupts.
+
+- reg: Memory region(s) for configuration. For SMP, there should be one
+  region per cpu, indexed by the sequential, zero-based hardware cpu
+  number (which is also the logical cpu number).
+
+- interrupt-controller: Identifies the node as an interrupt controller
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+
+Example:
+
+aic: interrupt-controller@200 {
+   compatible = "jcore,aic2";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+};
-- 
2.8.1

Re: [PATCH 1/6] extcon: Add the extcon_type to group each connector into five category

[Chanwoo Choi]

Hi Myungjoo,

On 2016년 07월 27일 13:27, MyungJoo Ham wrote:
>> This patch adds the new extcon type to group the each connecotr
>> into following five category. This type would be used to handle
>> the connectors as a group unit instead of a connector unit.
>> - EXTCON_TYPE_USB  : USB connector
>> - EXTCON_TYPE_CHG  : Charger connector
>> - EXTCON_TYPE_JACK : Jack connector
> 
> "Jack" seems to be an internal jargon that many people won't recognize.
> It's, in fact, 3.5-pi, isn't it?

You're right. But, the ALSA framework already used the 'jack' word
for headphone/headset/microphone for a long time. (sound/soc/soc-jack.c)
So, To prevent the confusion, I use the 'jack' word.

> 
> Anyway, this is already being used as an enum with drivers,
> I'd suggest to add a comment in extcon.h stating that 
> "Jack connector" is usually the 3.5-pi earbud connector.

Additionally,  jack means the the LINE_IN/OUT, VIDEO_IN/OUT,
SPDIF_IN/OUT in the extcon.

> 
> Anyway, I like the direction of this patch.

Thanks.

> 
> 
> Signed-off-by: MyungJoo Ham 

Regards,
Chanwoo Choi

> 
> Cheers,
> MyungJoo
> 
>> --- a/include/linux/extcon.h
>> +++ b/include/linux/extcon.h
>> @@ -29,6 +29,15 @@
>>  #include 
>>  
>>  /*
>> + * Define the type of supported external connectors
>> + */
>> +#define EXTCON_TYPE_USB BIT(0)  /* USB connector */
>> +#define EXTCON_TYPE_CHG BIT(1)  /* Charger connector */
>> +#define EXTCON_TYPE_JACKBIT(2)  /* Jack connector */
> +/* Usually, this is a 3.5-pi earbud conector 
> */
>> +#define EXTCON_TYPE_DISPBIT(3)  /* Display connector */
>> +#define EXTCON_TYPE_MISCBIT(4)  /* Miscellaneous connector */
>> +
>> +/*
>>   * Define the unique id of supported external connectors
>>   */
>>  #define EXTCON_NONE 0
>> -- 
>> 1.9.1
>>

[PATCH v4 2/2] irqchip: add J-Core AIC driver

[Rich Felker]

There are two versions of the J-Core interrupt controller in use, aic1
which generates interrupts with programmable priorities, but only
supports 8 irq lines and maps them to cpu traps in the range 17 to 24,
and aic2 which uses traps in the range 64-127 and supports up to 128
irqs, with priorities dependent on the interrupt number. The Linux
driver does not make use of priorities anyway.

For simplicity, there is no aic1-specific logic in the driver beyond
setting the priority register, which is necessary for interrupts to
work at all. Eventually aic1 will likely be phased out, but it's
currently in use in deployments and all released bitstream binaries.

Signed-off-by: Rich Felker 
---
 drivers/irqchip/Kconfig |  6 
 drivers/irqchip/Makefile|  1 +
 drivers/irqchip/irq-jcore-aic.c | 79 +
 3 files changed, 86 insertions(+)
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index fa33c50..fe58177 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -150,6 +150,12 @@ config PIC32_EVIC
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config JCORE_AIC
+   bool "J-Core integrated AIC"
+   select IRQ_DOMAIN
+   help
+ Support for the J-Core integrated AIC.
+
 config RENESAS_INTC_IRQPIN
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..5b1a2fa 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_I8259)   += irq-i8259.o
 obj-$(CONFIG_IMGPDC_IRQ)   += irq-imgpdc.o
 obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
 obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
+obj-$(CONFIG_JCORE_AIC)+= irq-jcore-aic.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
new file mode 100644
index 000..7b3b30e
--- /dev/null
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -0,0 +1,79 @@
+/*
+ * J-Core SoC AIC driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AIC1_INTPRI 8
+
+static struct aic_data {
+   struct irq_chip chip;
+   struct irq_domain *domain;
+   struct notifier_block nb;
+} aic_data;
+
+static int aic_irqdomain_map(struct irq_domain *d, unsigned int irq, 
irq_hw_number_t hwirq)
+{
+   struct aic_data *aic = d->host_data;
+
+   irq_set_chip_data(irq, aic);
+   irq_set_chip_and_handler(irq, &aic->chip, handle_simple_irq);
+   irq_set_probe(irq);
+
+   return 0;
+}
+
+static const struct irq_domain_ops aic_irqdomain_ops = {
+   .map = aic_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void noop(struct irq_data *data)
+{
+}
+
+int __init aic_irq_of_init(struct device_node *node, struct device_node 
*parent)
+{
+   struct aic_data *aic = &aic_data;
+   unsigned min_irq = 64;
+
+   pr_info("Initializing J-Core AIC\n");
+
+   if (!of_device_is_compatible(node, "jcore,aic2")) {
+   unsigned cpu;
+   for_each_possible_cpu(cpu) {
+   void __iomem *base = of_iomap(node, cpu);
+   if (!base)
+   continue;
+   pr_info("Local AIC1 enable for cpu %u at %p\n",
+   cpu, base + AIC1_INTPRI);
+   __raw_writel(0x, base + AIC1_INTPRI);
+   }
+   min_irq = 16;
+   }
+
+   aic->chip.name = node->name;
+   aic->chip.irq_mask = noop;
+   aic->chip.irq_unmask = noop;
+
+   aic->domain = irq_domain_add_linear(node, 128, &aic_irqdomain_ops, aic);
+   irq_create_strict_mappings(aic->domain, min_irq, min_irq, 128-min_irq);
+
+   return 0;
+}
+
+IRQCHIP_DECLARE(jcore_aic2, "jcore,aic2", aic_irq_of_init);
+IRQCHIP_DECLARE(jcore_aic1, "jcore,aic1", aic_irq_of_init);
-- 
2.8.1

[PATCH v4 0/2] J-Core interrupt controller support

[Rich Felker]

This driver is used with the J2, an open-source VHDL reimplementation
of SH-2.

I've split this out from the main J-Core support patches going
upstream through my own linux-sh tree. Changes since the v3 stem out
of reworking the DT to use separate reg ranges per cpu rather than
cpu-offset. The intent is to avoid out-of-mapping arithmetic via
cpu-offset and to avoid artifically restricting how the hardware lays
out the mappings, but this also allows the cpu notifier logic which
was present before to be removed with simple iteration over the reg
ranges present in its place.

Rich


Rich Felker (2):
  of: add J-Core interrupt controller bindings
  irqchip: add J-Core AIC driver

 .../bindings/interrupt-controller/jcore,aic.txt| 26 +++
 drivers/irqchip/Kconfig|  6 ++
 drivers/irqchip/Makefile   |  1 +
 drivers/irqchip/irq-jcore-aic.c| 79 ++
 4 files changed, 112 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

-- 
2.8.1

Re: [PATCH v3 01/12] of: add vendor prefix for J-Core

[Rich Felker]

On Wed, May 25, 2016 at 08:18:06AM -0500, Rob Herring wrote:
> On Wed, May 25, 2016 at 12:43 AM, Rich Felker  wrote:
> > The J-Core project (j-core.org) produces open source cpu and SoC
> > peripheral cores synthesizable as FPGA bitstreams or ASICs.
> >
> > Signed-off-by: Rich Felker 
> 
> Please add acks when posting subsequent versions.
> 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 86740d4..9c070b8 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -126,6 +126,7 @@ invensense  InvenSense Inc.
> >  isee   ISEE 2007 S.L.
> >  isil   Intersil
> >  issi   Integrated Silicon Solutions Inc.
> > +jcore  J-Core.org
> >  jedec  JEDEC Solid State Technology Association
> >  karo   Ka-Ro electronics GmbH
> >  keymileKeymile GmbH
> > --
> > 2.8.1

Since this was previously acked, can I include it in my tree for
upstreaming? Or do you want me to submit the patch again?

Rich

Re: [PATCH] clocksource: j-core: type fix init function return code

[Rich Felker]

On Tue, Jul 26, 2016 at 02:31:29PM +0200, Arnd Bergmann wrote:
> The CLOCKSOURCE_OF_DECLARE now takes a function that returns an 'int', but a 
> this
> new clocksource driver has just appeared in linux-next and causes a warning 
> because
> it has the old 'void' return value:
> 
> In file included from ../include/linux/clocksource.h:18:0,
>  from ../include/linux/clockchips.h:13,
>  from ../drivers/clocksource/jcore-pit.c:14:
> include/linux/of.h:1006:20: error: comparison of distinct pointer types lacks 
> a cast [-Werror]
> .data = (fn == (fn_type)NULL) ? fn : fn  }
> ^
> 
> This adapts the jcore_pit_init() function to the correct return type.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> ---
> The patch that introduces the warnign currently only exists in the linux-sh 
> git
> tree and showed up in linux-next this week.

I've removed the commit from my for-next branch since it's not
appropriate to go upstream through my tree. Your patch should still be
applied in the proper subsystem tree, though, I think. Daniel?

Rich


> ---
>  drivers/clocksource/jcore-pit.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
> index 373b9f954a5c..4a2f7803624b 100644
> --- a/drivers/clocksource/jcore-pit.c
> +++ b/drivers/clocksource/jcore-pit.c
> @@ -154,7 +154,7 @@ static irqreturn_t jcore_timer_interrupt(int irq, void 
> *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> -static void __init jcore_pit_init(struct device_node *node)
> +static int __init jcore_pit_init(struct device_node *node)
>  {
>   int err;
>   __iomem void *pit_base;
> @@ -169,12 +169,14 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   pit_base = of_iomap(node, 0);
>   if (!pit_base) {
>   pr_err("Error: Cannot map base address for J-Core PIT\n");
> + err = -ENXIO;
>   goto out;
>   }
>  
>   pit_irq = irq_of_parse_and_map(node, 0);
>   if (!pit_irq) {
>   pr_err("Error: J-Core PIT has no IRQ\n");
> + err = -ENXIO;
>   goto out;
>   }
>  
> @@ -183,6 +185,7 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   cs = kzalloc(sizeof *cs, GFP_KERNEL);
>   if (!cs) {
>   pr_err("Failed to allocate memory for clocksource\n");
> + err = ENOMEM;
>   goto out;
>   }
>   jcore_cs = &cs->cs;
> @@ -207,12 +210,14 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   pit_percpu = alloc_percpu(struct jcore_pit);
>   if (!pit_percpu) {
>   pr_err("Failed to allocate memory for clock event device\n");
> + err = ENOMEM;
>   goto out;
>   }
>  
>   nb = kzalloc(sizeof *nb, GFP_KERNEL);
>   if (!nb) {
>   pr_err("Failed to allocate memory for J-Core PIT notifier\n");
> + err = ENOMEM;
>   goto out;
>   }
>  
> @@ -268,10 +273,11 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>  
>   jcore_pit_local_init(this_cpu_ptr(pit_percpu));
>  
> - return;
> + return 0;
>  
>  out:
>   pr_err("Could not initialize J-Core PIT driver\n");
> + return err;
>  }
>  
>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> -- 
> 2.9.0

[PATCH BUGFIX V5] block: add missing group association in bio-cloning functions

[Paolo Valente]

When a bio is cloned, the newly created bio must be associated with
the same blkcg as the original bio (if BLK_CGROUP is enabled). If
this operation is not performed, then the new bio is not associated
with any group, and the group of the current task is returned when
the group of the bio is requested.

Depending on the cloning frequency, this may cause a large
percentage of the bios belonging to a given group to be treated
as if belonging to other groups (in most cases as if belonging to
the root group). The expected group isolation may thereby be broken.

This commit adds the missing association in bio-cloning functions.

Fixes: da2f0f74cf7d ("Btrfs: add support for blkio controllers")
Cc: sta...@vger.kernel.org # v4.3+

Signed-off-by: Paolo Valente 
Reviewed-by: Nikolay Borisov 
Reviewed-by: Jeff Moyer 
Acked-by: Tejun Heo 
---
Fixed a compilation issue reported by kbuild test robot
---
 block/bio.c  | 15 +++
 fs/btrfs/extent_io.c |  6 --
 include/linux/bio.h  |  3 +++
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 0e4aa42..4623869 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -579,6 +579,8 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
bio->bi_rw = bio_src->bi_rw;
bio->bi_iter = bio_src->bi_iter;
bio->bi_io_vec = bio_src->bi_io_vec;
+
+   bio_clone_blkcg_association(bio, bio_src);
 }
 EXPORT_SYMBOL(__bio_clone_fast);
 
@@ -684,6 +686,8 @@ integrity_clone:
}
}
 
+   bio_clone_blkcg_association(bio, bio_src);
+
return bio;
 }
 EXPORT_SYMBOL(bio_clone_bioset);
@@ -2005,6 +2009,17 @@ void bio_disassociate_task(struct bio *bio)
}
 }
 
+/**
+ * bio_clone_blkcg_association - clone blkcg association from src to dst bio
+ * @dst: destination bio
+ * @src: source bio
+ */
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src)
+{
+   if (src->bi_css)
+   WARN_ON(bio_associate_blkcg(dst, src->bi_css));
+}
+
 #endif /* CONFIG_BLK_CGROUP */
 
 static void __init biovec_init_slabs(void)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 75533ad..92fe3f8 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2696,12 +2696,6 @@ struct bio *btrfs_bio_clone(struct bio *bio, gfp_t 
gfp_mask)
btrfs_bio->csum = NULL;
btrfs_bio->csum_allocated = NULL;
btrfs_bio->end_io = NULL;
-
-#ifdef CONFIG_BLK_CGROUP
-   /* FIXME, put this into bio_clone_bioset */
-   if (bio->bi_css)
-   bio_associate_blkcg(new, bio->bi_css);
-#endif
}
return new;
 }
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 9faebf7..75fadd2 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -527,11 +527,14 @@ extern unsigned int bvec_nr_vecs(unsigned short idx);
 int bio_associate_blkcg(struct bio *bio, struct cgroup_subsys_state 
*blkcg_css);
 int bio_associate_current(struct bio *bio);
 void bio_disassociate_task(struct bio *bio);
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src);
 #else  /* CONFIG_BLK_CGROUP */
 static inline int bio_associate_blkcg(struct bio *bio,
struct cgroup_subsys_state *blkcg_css) { return 0; }
 static inline int bio_associate_current(struct bio *bio) { return -ENOENT; }
 static inline void bio_disassociate_task(struct bio *bio) { }
+static inline void bio_clone_blkcg_association(struct bio *dst,
+   struct bio *src) { }
 #endif /* CONFIG_BLK_CGROUP */
 
 #ifdef CONFIG_HIGHMEM
-- 
1.9.1

Re: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s

[Darren Hart]

On Fri, Jul 22, 2016 at 03:01:24PM -0500, Mario Limonciello wrote:
> The Dell Rugged 7202 has 3 programmable buttons (labeled P1, P2, P3)
> and a detachable magnetic keyboard/mouse.
> 
> Signed-off-by: Mario Limonciello 

+Pali

Pali, any concerns?

> ---
>  drivers/platform/x86/dell-wmi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 15c6f11..6ba42d0 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -222,6 +222,16 @@ static const struct key_entry dell_wmi_extra_keymap[] 
> __initconst = {
>  
>   /* Stealth mode toggle */
>   { KE_IGNORE, 0x155, { KEY_RESERVED } },
> +
> + /* Rugged magnetic keyboard/mouse events */
> + { KE_IGNORE, 0x156, { KEY_RESERVED } },
> + { KE_IGNORE, 0x157, { KEY_RESERVED } },
> +
> + /* Rugged programmable (P1/P2/P3 keys) */
> + { KE_KEY, 0x850, { KEY_PROG1 } },
> + { KE_KEY, 0x851, { KEY_PROG2 } },
> + { KE_KEY, 0x852, { KEY_PROG3 } },
> +
>  };
>  
>  static struct input_dev *dell_wmi_input_dev;
> -- 
> 2.7.4
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v4] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

[stefan . mavrodiev]

On Tuesday, July 26, 2016 5:33:52 PM EEST Maxime Ripard wrote:
> Hi Stefan,
> 
> On Mon, Jul 25, 2016 at 03:37:23PM +0300, Stefan Mavrodiev wrote:
> > A33-OLinuXino is A33 development board designed by Olimex LTD.
> > 
> > It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector,
> > headphone and mic jacks, connector for LiPo battery and optional
> > 4GB NAND Flash.
> > 
> > It has two 40-pin headers. One for LCD panel, and one for
> > additional modules. Also there is CSI/DSI connector.
> > 
> > Signed-off-by: Stefan Mavrodiev 
> 
> It looks mostly good, a few comments though.
> 
> > +&pio {
> > +   led_pin_olinuxino: led_pins@0 {
> > +   allwinner,pins = "PB7";
> > +allwinner,function = "gpio_out";
> 
> This line is not properly indented.
> 
> > +   allwinner,drive = ;
> > +   allwinner,pull = ;
> > +};
> 
> And this one too.
> 
> > +®_dc1sw {
> > +   regulator-name = "vcc-lcd";
> > +};
> 
> No constraints on this one?
> 
> > +®_dcdc1 {
> > +   regulator-always-on;
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-name = "vcc-dsi";
> > +};
> 
> What is it used for? Is it really necessary to keep it on at all time?

I think so.
This is the supply for the MMC.
> 
> Thanks,
> Maxime

Best regards,
Stefan Mavrodiev

Re: [PATCH 11/13] rapidio: modify for rev.3 specification changes

[Michael Ellerman]

Alexandre Bounine  writes:

> Implement changes made in RapidIO specification rev.3 to LP-Serial Physical
> Layer register definitions:
> - use per-port register offset calculations based on LP-Serial Extended
>   Features Block (EFB) Register Map type (I or II) with different per-port
>   offset step (0x20 vs. 0x40 respectfully).
> - remove deprecated Parallel Physical layer definitions and related code.
>
> Signed-off-by: Alexandre Bounine 
> Tested-by: Barry Wood 
> Cc: Matt Porter 
> Cc: Andre van Herk 
> Cc: Barry Wood 
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/rapidio/devices/rio_mport_cdev.c |2 +-
>  drivers/rapidio/devices/tsi721.c |8 +-
>  drivers/rapidio/rio-scan.c   |   74 +++--
>  drivers/rapidio/rio.c|  149 ++-
>  drivers/rapidio/rio.h|2 +-
>  drivers/rapidio/switches/tsi57x.c|   26 ++---
>  include/linux/rio.h  |   11 +--
>  include/linux/rio_regs.h |  167 +++--
>  8 files changed, 248 insertions(+), 191 deletions(-)

This is breaking the build for me on powerpc, for
corenet64_smp_defconfig at least.

eg.

http://kisskb.ellerman.id.au/kisskb/buildresult/12750751/

Commit:   Add linux-next specific files for 20160722
  13123042d0dbf7635f052efc2ae69fd9af624f1d
Compiler: powerpc-linux-gcc (GCC) 4.6.3

Possible errors
---

arch/powerpc/sysdev/fsl_rio.c:702:11: error: 'struct rio_mport' has no member 
named 'phy_type'
arch/powerpc/sysdev/fsl_rio.c:702:25: error: 'RIO_PHY_SERIAL' undeclared (first 
use in this function)
make[2]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1
make[1]: *** [arch/powerpc/sysdev] Error 2
make: *** [sub-make] Error 2

cheers

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

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

  arch/x86/kvm/vmx.c

between commit:

  4e59516a12a6 ("kvm: vmx: ensure VMCS is current while enabling PML")

from Linus' tree and commit:

  37e4c997dadf ("KVM: VMX: validate individual bits of guest 
MSR_IA32_FEATURE_CONTROL")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index df4a3b818048,b61cdadf8623..
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -8954,6 -9086,20 +9105,8 @@@ static struct kvm_vcpu *vmx_create_vcpu
vmx->nested.current_vmptr = -1ull;
vmx->nested.current_vmcs12 = NULL;
  
 -  /*
 -   * If PML is turned on, failure on enabling PML just results in failure
 -   * of creating the vcpu, therefore we can simplify PML logic (by
 -   * avoiding dealing with cases, such as enabling PML partially on vcpus
 -   * for the guest, etc.
 -   */
 -  if (enable_pml) {
 -  err = vmx_create_pml_buffer(vmx);
 -  if (err)
 -  goto free_vmcs;
 -  }
 -
+   vmx->msr_ia32_feature_control_valid_bits = FEATURE_CONTROL_LOCKED;
+ 
return &vmx->vcpu;
  
  free_vmcs:
@@@ -10913,7 -11149,17 +11161,17 @@@ out
return ret;
  }
  
+ static void vmx_setup_mce(struct kvm_vcpu *vcpu)
+ {
+   if (vcpu->arch.mcg_cap & MCG_LMCE_P)
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits |=
+   FEATURE_CONTROL_LMCE;
+   else
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits &=
+   ~FEATURE_CONTROL_LMCE;
+ }
+ 
 -static struct kvm_x86_ops vmx_x86_ops = {
 +static struct kvm_x86_ops vmx_x86_ops __ro_after_init = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
.hardware_setup = hardware_setup,

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 11:32:25AM -0700, W. Trevor King wrote:
> On Tue, Jul 26, 2016 at 11:25:24AM -0700, Andrew Vagin wrote:
> > Sure. If a process wants to compare two namespaces, it needs to get file
> > descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
> > process which has them),
> > and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
> 
> If you use the new ioctl-s to get ns_fd2, do you walk your local /proc
> to find pid2?

If you use the new ioctl-s to get nf_fd2, you will have it in the
current process, so pid2 will be getpid().

pidX identifies a process where to find fdX.

man 2 kcmp:
 The kcmp() system call can be used to check whether the  two processes
 identified  by  pid1  and  pid2 share a kernel resource such as virtual
 memory, file descriptors, and so on.

> 
> Cheers,
> Trevor
> 
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Re: [PATCH 4.4 000/146] 4.4.16-stable review

[Greg Kroah-Hartman]

On Tue, Jul 26, 2016 at 02:55:35PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > stable-rc boot: 353 boots: 7 failed, 345 passed with 1 offline 
> > (v4.4.15-147-g0b4b25c69607)
> >
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.15-147-g0b4b25c69607/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/kernel/v4.4.15-147-g0b4b25c69607/
> >
> > Tree: stable-rc
> > Branch: local/linux-4.4.y
> > Git Describe: v4.4.15-147-g0b4b25c69607
> > Git Commit: 0b4b25c69607c7515308f6a2beb6120dec2ad9dc
> > Git URL: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 64 unique boards, 17 SoC families, 27 builds out of 140
> >
> > Boot Failures Detected: 
> > https://kernelci.org/boot/?v4.4.15-147-g0b4b25c69607&fail
> >
> > arm64:
> >
> > defconfig:
> > apm-mustang-kvm-guest: 1 failed lab
> > apm-mustang-kvm-uefi-guest: 1 failed lab
> > juno-kvm-guest: 1 failed lab
> > juno-kvm-uefi-guest: 1 failed lab
> 
> Can be ignored.  KVM issues with the qemu on the rootfs, under
> investigation.
> 
> > arm:
> >
> > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > sun9i-a80-optimus: 1 failed lab
> >
> > sunxi_defconfig:
> > sun9i-a80-optimus: 1 failed lab
> >
> > multi_v7_defconfig+CONFIG_LKDTM=y:
> > sun9i-a80-optimus: 1 failed lab
> 
> These ones look legit.
> 
> I've asked the folks in the Free Electrons lab to have a closer look at
> this one.

Ok, thanks, let me know if they find I messed anything up.

greg k-h

Re: [PATCH 4.6 000/203] 4.6.5-stable review

[Greg Kroah-Hartman]

On Tue, Jul 26, 2016 at 02:27:54PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > stable-rc boot: 670 boots: 4 failed, 662 passed with 3 offline, 1 conflict 
> > (v4.6.4-204-g02256e5f7d73)
> >
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
> >
> > Tree: stable-rc
> > Branch: local/linux-4.6.y
> > Git Describe: v4.6.4-204-g02256e5f7d73
> > Git Commit: 02256e5f7d734c5aa48de4310ca72f1887aea3d4
> > Git URL: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 106 unique boards, 25 SoC families, 36 builds out of 140
> >
> > Boot Failures Detected: 
> > https://kernelci.org/boot/?v4.6.4-204-g02256e5f7d73&fail
> >
> > arm64:
> >
> > defconfig:
> > apm-mustang-kvm-guest: 1 failed lab
> > apm-mustang-kvm-uefi-guest: 1 failed lab
> > juno-kvm-uefi-guest: 1 failed lab
> >
> 
> Can be ignored: ongoing KVM issues with qemu on the rootfs here.  
> 
> > arm:
> >
> > multi_v7_defconfig+CONFIG_EFI=y:
> > am335x-bone: 1 failed lab
> 
> After retry: PASS
> 
> I re-ran this one a few times and it's OK, not sure what happend.

Thanks for letting me know.

greg k-h

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[Greg KH]

On Tue, Jul 26, 2016 at 07:05:37PM -0700, k...@exchange.microsoft.com wrote:
> +/*
> + * Create a char device that can support read/write for passing
> + * the payload.
> + */

That sounds "interesting"...

> +
> +static struct completion ip_event;
> +static bool opened;
> +
> +char hvnd_ip_addr[4];
> +char hvnd_mac_addr[6];
> +bool hvnd_addr_set;

Global variables?

> +
> +int hvnd_get_ip_addr(char **ip_addr, char **mac_addr)
> +{
> + int t;
> +
> + /*
> +  * Now wait for the user level daemon to get us the
> +  * IP addresses bound to the MAC address.
> +  */
> + if (!hvnd_addr_set) {
> + t = wait_for_completion_timeout(&ip_event, 600*HZ);
> + if (t == 0)
> + return -ETIMEDOUT;
> + }
> +
> + if (hvnd_addr_set) {
> + *ip_addr = hvnd_ip_addr;
> + *mac_addr = hvnd_mac_addr;
> + return 0;
> + }
> +
> + return -ENODATA;
> +}
> +
> +static ssize_t hvnd_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + char input[120];
> + int scaned, i;
> + unsigned int mac_addr[6], ip_addr[4];
> +
> + if (hvnd_addr_set) {
> + hvnd_error("IP/MAC address already set, ignoring input\n");
> + return count;
> + }
> +
> + if (count > sizeof(input)-1)
> + return -EINVAL;
> +
> + if (copy_from_user(input, buf, count))
> + return -EFAULT;
> +
> + input[count] = 0;
> +
> + /*
> +  * Wakeup the context that may be waiting for this.
> +  */
> + hvnd_debug("get user mode input: %s\n", input);
> +
> + scaned = sscanf(input,
> + "rdmaMacAddress=\"%x:%x:%x:%x:%x:%x\" 
> rdmaIPv4Address=\"%u.%u.%u.%u\"",
> + &mac_addr[0],
> + &mac_addr[1],
> + &mac_addr[2],
> + &mac_addr[3],
> + &mac_addr[4],
> + &mac_addr[5],
> + &ip_addr[0],
> + &ip_addr[1],
> + &ip_addr[2],
> + &ip_addr[3]);

Oh, that's a mess, you are going to parse text in the kernel that is
passed on a char device?  Please tell me that not all IB drivers are
like this...

> +
> + if (scaned == 10) {
> +
> + for (i = 0; i < 6; i++)
> + hvnd_mac_addr[i] = (char) mac_addr[i];
> + for (i = 0; i < 4; i++)
> + hvnd_ip_addr[i] = (char) ip_addr[i];
> +
> + hvnd_error("Scanned IP address: %pI4 Mac address: %pM\n",
> +hvnd_ip_addr, hvnd_mac_addr);
> +
> + hvnd_addr_set = true;
> + complete(&ip_event);
> + }
> +
> + return count;
> +}
> +
> +static int hvnd_open(struct inode *inode, struct file *f)
> +{
> + /*
> +  * The user level daemon that will open this device is
> +  * really an extension of this driver. We can have only
> +  * active open at a time.

Do you have a pointer to that code?  As it's a logical extension, you
know what the license for that code better be... :)

> +  */
> + if (opened)
> + return -EBUSY;

You just raced, and lost, oops :(

There are better ways to do this, the easiest being, why do you need
"exclusive" access at all?

> +
> + /*
> +  * The daemon is alive; setup the state.
> +  */
> + opened = true;
> + return 0;
> +}
> +
> +static int hvnd_release(struct inode *inode, struct file *f)
> +{
> + /*
> +  * The daemon has exited; reset the state.
> +  */
> + opened = false;
> + return 0;
> +}
> +
> +
> +static const struct file_operations hvnd_fops = {
> + .write  = hvnd_write,
> + .release= hvnd_release,
> + .open   = hvnd_open,
> +};
> +
> +static struct miscdevice hvnd_misc = {
> + .minor  = MISC_DYNAMIC_MINOR,
> + .name   = "hvnd_rdma",
> + .fops   = &hvnd_fops,
> +};
> +
> +static int hvnd_dev_init(void)
> +{
> + init_completion(&ip_event);
> + return misc_register(&hvnd_misc);
> +}
> +
> +static void hvnd_dev_deinit(void)
> +{
> +
> + /*
> +  * The device is going away - perhaps because the
> +  * host has rescinded the channel. Setup state so that
> +  * user level daemon can gracefully exit if it is blocked
> +  * on the read semaphore.
> +  */
> + opened = false;

But if it's blocked, it's not going to get unblocked here :(


> + /*
> +  * Signal the semaphore as the device is
> +  * going away.
> +  */
> + misc_deregister(&hvnd_misc);
> +}

Your comment doesn't match the code you are calling.

I gave up here, sorry.

Exactly why do you want a char interface?  It looks like you are using
it to configure your "hardware", surely there is already other ways to
do this and not every driver needs to roll-their-own like this?

thanks,

greg k-h

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chris Zhong]

Hi Chanwoo

On 07/27/2016 11:57 AM, Chanwoo Choi wrote:

On 2016년 07월 27일 12:51, Guenter Roeck wrote:

On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:

Hi Chris,

On 2016년 07월 27일 11:09, Chris Zhong wrote:

Hi Guernter

On 07/27/2016 09:44 AM, Guenter Roeck wrote:

Hi Chris,

On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

[ ... ]


  > +
  > +/* Properties of EXTCON_TYPE_DISP. */
  > +#define EXTCON_PROP_DISP_MIN   150
  > +#define EXTCON_PROP_DISP_MAX   150
  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
  EXTCON_PROP_DISP_MIN)

   + 1


ok.

Tested with these "+1", it works for my DP patch.


You should be able to use
https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
you didn't do that already).

Thanks,
Guenter

Thanks Guenter, and I saw this bug has fixed in extcon-test branch.



Do you test it with extcon_set_property_capability()?
And if you test this patch-es, could you send the tested-by tag for these 
patches?

Yes, the new API need this extcon_set_property_capability to be called 
before setting property.
On this basis, My DP patches works well with a little bit modification. 
Then, I will post the V7 version soon, base on this patches and 
Guenter's FIXUP patch.
Please feel free to add my Tested-by: Chris Zhong  
tag in the next version.




For my part I did. Above link is public, so you should be able to see
the complete patch set which uses the new API from
drivers/extcon/extcon-cros_ec.c.

I'll re-test tomorrow with the updated patches from your test branch.






OK. Thanks.

Regards,
Chanwoo Choi

RE: [PATCH 1/6] extcon: Add the extcon_type to group each connector into five category

[MyungJoo Ham]

> This patch adds the new extcon type to group the each connecotr
> into following five category. This type would be used to handle
> the connectors as a group unit instead of a connector unit.
> - EXTCON_TYPE_USB  : USB connector
> - EXTCON_TYPE_CHG  : Charger connector
> - EXTCON_TYPE_JACK : Jack connector

"Jack" seems to be an internal jargon that many people won't recognize.
It's, in fact, 3.5-pi, isn't it?

Anyway, this is already being used as an enum with drivers,
I'd suggest to add a comment in extcon.h stating that 
"Jack connector" is usually the 3.5-pi earbud connector.

Anyway, I like the direction of this patch.


Signed-off-by: MyungJoo Ham 

Cheers,
MyungJoo

> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -29,6 +29,15 @@
>  #include 
>  
>  /*
> + * Define the type of supported external connectors
> + */
> +#define EXTCON_TYPE_USB  BIT(0)  /* USB connector */
> +#define EXTCON_TYPE_CHG  BIT(1)  /* Charger connector */
> +#define EXTCON_TYPE_JACK BIT(2)  /* Jack connector */
+/* Usually, this is a 3.5-pi earbud conector */
> +#define EXTCON_TYPE_DISP BIT(3)  /* Display connector */
> +#define EXTCON_TYPE_MISC BIT(4)  /* Miscellaneous connector */
> +
> +/*
>   * Define the unique id of supported external connectors
>   */
>  #define EXTCON_NONE  0
> -- 
> 1.9.1
> 

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[Leon Romanovsky]

On Tue, Jul 26, 2016 at 07:05:37PM -0700, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 
> 
> This driver is a bridge driver that surfaces a Mellanox device in the Linux 
> guest and plugs into
> the "NetworkDirect" RDMA infrastructure on the Windows host. Only a subset of 
> the ibverbs are
> implemented (this decision is based on the verbs supported by the Windows 
> host).
> The control path is implemented over the vmbus using the NetworkDirect 
> protocol for
> virtualized environments. The data path bypasses the guest and host kernel 
> and the NIC is able to RDMA
> into guest addresses.
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/infiniband/Kconfig  |1 +
>  drivers/infiniband/hw/Makefile  |1 +
>  drivers/infiniband/hw/vmbus-nd/Kconfig  |5 +
>  drivers/infiniband/hw/vmbus-nd/Makefile |3 +
>  drivers/infiniband/hw/vmbus-nd/hvnd_addr.c  |  292 +++
>  drivers/infiniband/hw/vmbus-nd/mx_abi.h |  232 ++
>  drivers/infiniband/hw/vmbus-nd/provider.c   | 2844 
>  drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c | 3086 
> +++
>  drivers/infiniband/hw/vmbus-nd/vmbus_rdma.h | 2205 +++
>  9 files changed, 8669 insertions(+), 0 deletions(-)

If your final goal is to merge this driver into Linux kernel, so I will
ask from you to do the following actions:

1. Split this patch to smaller patches to allow review.
You can see as an example - latest submission of "Add Paravirtual RDMA Driver" 
[1].
2. Fix licenses, magic numbers, remove creepy comments and learn about
MAINTAINERS file.
3. Use preferred for this susbsystem title format.
4. Find the relevant mailing list and maintainer for this submission and
don't add unrelated people.

Thanks.

[1] http://marc.info/?l=linux-rdma&m=146835226218818&w=2

>  create mode 100644 drivers/infiniband/hw/vmbus-nd/Kconfig
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/Makefile
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/hvnd_addr.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/mx_abi.h
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/provider.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/vmbus_rdma.h


signature.asc
Description: Digital signature

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

[Fu Wei]

Hi all,

On 27 July 2016 at 11:33, Jisheng Zhang  wrote:
> +1
>
> On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi  wrote:
>
>> Will Deacon wrote:
>> > The kernel really needs to support both of those platforms :/
>> >
>> > For the memory-mapped counter registers, the architecture says:
>> >
>> >`If the implementation supports 64-bit atomic accesses, then the
>> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
>> >
>> > which is borderline tautological. If we take the generous reading that
>> > this means AArch64 CPUs can use readq (and I'm not completely
>> > comfortable with that assertion, particularly as you say that it breaks
>> > the model), then you still need to use readq_relaxed here to avoid a
>> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
>> > exist over there, and if you use the generic implementation then it's
>> > not atomic. In which case, we end up with the current code, as well as a
>> > readq_relaxed guarded by a questionable #ifdef that is known to break a
>> > supported platform for an unknown performance improvement. Hardly a big
>> > win.
>>
>> I know Fu dropped this patch, and I don't want to kick a dead horse, but
>> I was wondering if it would be okay to do this:
>>
>> static u64 arch_counter_get_cntvct_mem(void)
>> {
>> #ifdef readq_relaxed
>>   return readq_relaxed(arch_counter_base + CNTVCT_LO);
>> #else
>>   u32 vct_lo, vct_hi, tmp_hi;
>>
>>   do {
>>   vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>>   vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
>>   tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>>   } while (vct_hi != tmp_hi);
>>
>>   return ((u64) vct_hi << 32) | vct_lo;
>> #endif
>> }
>>
>> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h.  Why
>> would the function exist if AArch64 CPUs can't use it?

yes, that is a good idea. Thanks Timur! :-)

>
> +1

I like this idea too, but please allow me to upstream this patch separately,
because this GTDT patchset can work without it, this readq support is
a  optimizing.

I also can see another arm-related driver are using readq in this way(
#ifdef readq): bus/arm-ccn.c
And some other drivers are also doing this.

>
> I measured the performance on berlin arm64 platforms:
>
> compared with original version, using readq_relaxed could reduce
> time of arch_counter_get_cntvct_mem() by about 42%!

Great thanks for your data, :-)

>
> Thanks,
> Jisheng



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[kbuild test robot]

Hi,

[auto build test WARNING on rdma/master]
[also build test WARNING on v4.7 next-20160726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-exchange-microsoft-com/Drivers-infiniband-hw-vmbus-nd-NetworkDirect-driver-for-Linux/20160727-090222
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 
'hvnd_send_pg_buffer':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:247:20: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_cookie.pkt = (void *)cookie;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:254:6: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 (u64)(&hvnd_cookie));
 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_send_packet':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:279:20: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_cookie.pkt = (void *)cookie;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:283:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)(&hvnd_cookie), VM_PKT_DATA_INBAND,
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_open_adaptor':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:763:38: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 pr_o_adap->ioctl.input.adapter_id = (u64)nd_dev;
 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:813:132: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("adaptor handle: %p\n", (void *)uctx->adaptor_hdl);

   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:818:126: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("uar base: %p\n", (void *)uctx->uar_base);

 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:822:125: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("bf base: %p\n", (void *)uctx->bf_base);

^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_create_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:963:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)cq->cq_buf;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:972:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)cq->db_addr;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:982:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)&cq->arm_sn;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1023:60: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 ret = hvnd_send_ioctl_pkt(nd_dev, &pkt->hdr, cq_pkt_size, (u64)pkt);
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1041:4: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("CQ create after success cq handle is %p\n",
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_destroy_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1071:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)&free_cq_pkt);
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_notify_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1114:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)¬ify_cq_pkt);
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_cr_mr':
   drivers/infiniband/hw/vmbus-n

Re: [PATCH v2 2/4] arm64: dts: rockchip: add the saradc for rk3399

[Doug Anderson]

Hi,


On Tue, Jul 26, 2016 at 5:13 AM, Caesar Wang  wrote:
> This patch adds saradc needed information on rk3399 SoCs.
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v2: None
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 4c84229..b81f84b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -299,6 +299,18 @@
> };
> };
>
> +   saradc: saradc@ff10 {
> +   compatible = "rockchip,rk3399-saradc";
> +   reg = <0x0 0xff10 0x0 0x100>;
> +   interrupts = ;
> +   #io-channel-cells = <1>;
> +   clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
> +   clock-names = "saradc", "apb_pclk";
> +   resets = <&cru SRST_P_SARADC>;
> +   reset-names = "saradc-apb";
> +   status = "disabled";
> +   };
> +

Seems reasonable to me.  I'll let Heiko comment if he cares about the
sort ordering.  I can never quite figure out what it should be so I've
sorta given up on it...  ;)

Reviewed-by: Douglas Anderson 

-Doug

[GIT PULL] f2fs for 4.8

[Jaegeuk Kim]

Hi Linus,

Could you please consider this pull request?

Thanks,

The following changes since commit 4340fa55298d17049e71c7a34e04647379c269f3:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
(2016-06-02 15:08:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
tags/for-f2fs-4.8

for you to fetch changes up to 5302fb000def84100740a84d7f176c0e167b2141:

  f2fs: clean up coding style and redundancy (2016-07-25 12:58:12 -0700)


The major change in this version is mitigating cpu overheads on write paths by
replacing redundant inode page updates with mark_inode_dirty calls. And we tried
to reduce lock contentions as well to improve filesystem scalability.
Other feature is setting F2FS automatically when detecting host-managed SMR.

= Enhancement =
 - ioctl to move a range of data between files
 - inject orphan inode errors
 - avoid flush commands congestion
 - support lazytime

= Bug fixes =
 - return proper results for some dentry operations
 - fix deadlock in add_link failure
 - disable extent_cache for fcollapse/finsert


Chao Yu (9):
  f2fs: fix to avoid reading out encrypted data in page cache
  f2fs: fix to detect truncation prior rather than EIO during read
  f2fs: fix to redirty page if fail to gc data page
  f2fs: add nodiscard mount option
  f2fs: fix incorrect f_bfree calculation in ->statfs
  f2fs: fix to avoid redundant discard during fstrim
  f2fs: fix to avoid data update racing between GC and DIO
  f2fs: reset default idle interval value
  f2fs: fix to report error number of f2fs_find_entry

Jaegeuk Kim (54):
  Revert "f2fs: no need inc dirty pages under inode lock"
  f2fs: use inode pointer for {set, clear}_inode_flag
  f2fs: introduce f2fs_i_size_write with mark_inode_dirty_sync
  f2fs: introduce f2fs_i_blocks_write with mark_inode_dirty_sync
  f2fs: introduce f2fs_i_links_write with mark_inode_dirty_sync
  f2fs: call mark_inode_dirty_sync for i_field changes
  f2fs: flush inode metadata when checkpoint is doing
  f2fs: remove syncing inode page in all the cases
  f2fs: avoid unnecessary updating inode during fsync
  f2fs: add lazytime mount option
  f2fs: detect congestion of flush command issues
  f2fs: set flush_merge by default
  f2fs: remove writepages lock
  f2fs: propagate error given by f2fs_find_entry
  f2fs: inject to produce some orphan inodes
  f2fs: do not skip writing data pages
  f2fs: remove two steps to flush dirty data pages
  f2fs: return error of f2fs_lookup
  f2fs: handle writepage correctly
  f2fs: remove deprecated parameter
  f2fs: avoid wrong count on dirty inodes
  f2fs: remove obsolete parameter in f2fs_truncate
  f2fs: avoid data race between FI_DIRTY_INODE flag and update_inode
  f2fs: fix wrong percentage
  f2fs: control not to exceed # of cached nat entries
  f2fs: set mapping error for EIO
  f2fs: avoid reverse IO order for NODE and DATA
  f2fs: drop any block plugging
  f2fs: skip clean segment for gc
  f2fs: introduce mode=lfs mount option
  f2fs: fix deadlock in add_link failure
  f2fs: report error for f2fs_parent_dir
  f2fs: call update_inode_page for orphan inodes
  f2fs: detect host-managed SMR by feature flag
  f2fs: produce more nids and reduce readahead nats
  f2fs: avoid writing node/metapages during writes
  f2fs: avoid latency-critical readahead of node pages
  f2fs: introduce f2fs_set_page_dirty_nobuffer
  f2fs: call SetPageUptodate if needed
  f2fs: shrink critical region in spin_lock
  f2fs: skip to check the block address of node page
  f2fs: use percpu_rw_semaphore
  f2fs: move i_size_write in f2fs_write_end
  f2fs: avoid mark_inode_dirty
  f2fs: fix ERR_PTR returned by bio
  f2fs: refactor __exchange_data_block for speed up
  f2fs: disable extent_cache for fcollapse/finsert inodes
  f2fs: add maximum prefree segments
  f2fs: use blk_plug in all the possible paths
  f2fs: avoid memory allocation failure due to a long length
  f2fs: support an ioctl to move a range of data blocks
  f2fs: avoid data race when deciding checkpoin in f2fs_sync_file
  f2fs: handle error case with f2fs_bug_on
  f2fs: clean up coding style and redundancy

Sheng Yong (1):
  f2fs: find parent dentry correctly

Tiezhu Yang (1):
  f2fs: remove unnecessary goto statement

Yunlei He (2):
  f2fs: avoid mismatching block range for discard
  f2fs: get victim segment again after new cp

Yunlong Song (1):
  f2fs: return the errno to the caller to avoid using a wrong page

 Documentation/filesystems/f2fs.txt |   7 +-
 fs/f2fs/acl.c  |   9 +-
 fs/f2fs/acl.h  |   

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

[NeilBrown]

On Tue, Jul 26 2016, Mikulas Patocka wrote:

> On Sat, 23 Jul 2016, NeilBrown wrote:
>
>> "dirtying ... from the reclaim context" ??? What does that mean?
>> According to
>>   Commit: 26eecbf3543b ("[PATCH] vm: pageout throttling")
>> From the history tree, the purpose of throttle_vm_writeout() is to
>> limit the amount of memory that is concurrently under I/O.
>> That seems strange to me because I thought it was the responsibility of
>> each backing device to impose a limit - a maximum queue size of some
>> sort.
>
> Device mapper doesn't impose any limit for in-flight bios.

I would suggest that it probably should. At least it should
"set_wb_congested()" when the number of in-flight bios reaches some
arbitrary threshold.

The write-back throttling needs this to get an estimate of how fast the
backing device is, so it can share the dirty_threshold space fairly
among the different backing devices.

I added an arbitrary limit to raid1 back in 2011 (34db0cd60f8a1f)
because the lack of a limit was causing problems.
Specifically the write queue would get so long that ext3 would block for
an extended period when trying to flush a transaction, and that blocked
lots of other things, like atime updates.

Maybe there have been other fixes since then to other parts of the
puzzle, but the congestion tracking still seems to be an important part
of the picture and I think it would be best if every bdi would admit to
being congested well before it has consumed a significant fraction of
memory in its output queue.

> I've made some patches that limit in-flight bios for device mapper in
> the past, but there were not integrated into upstream.

I second the motion to resurrect these.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

[GIT PULL V2] Changes for 4.8

[Juergen Gross]

Hi Linus,

please consider pulling a patch series for 4.8 from:

  https://github.com/jgross1/linux.git tags/for-linus-4-8

Support calling functions on dedicated physical cpu

Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.

This patch series is adding a generic function to be able to temporarily
pin a (virtual) cpu to a dedicated physical cpu for executing above
mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
requiring this functionality are modified accordingly.

Unfortunately 2 of the 6 patches got no Acks as the maintainers didn't
react in spite of multiple pings and resends. The core modification in
the scheduler got an Ack from Peter and multiple tests showed no
regressions.

As the series is touching multiple subsystems I couldn't find anyone
willing to take the series via his tree (I tried Ingo, Thomas, Peter).

Juergen Gross (6):
  xen: sync xen header
  virt, sched: add generic vcpu pinning support
  smp: add function to execute a function synchronously on a cpu
  xen: add xen_pin_vcpu() to support calling functions on a
dedicated pcpu
  dcdbas: make use of smp_call_on_cpu()
  hwmon: use smp_call_on_cpu() for dell-smm i8k

 MAINTAINERS   |   1 +
 arch/x86/include/asm/hypervisor.h |   4 ++
 arch/x86/kernel/cpu/hypervisor.c  |  11 +
 arch/x86/xen/enlighten.c  |  40 +++
 drivers/firmware/dcdbas.c |  51 +--
 drivers/hwmon/dell-smm-hwmon.c|  36 --
 include/linux/hypervisor.h|  17 +++
 include/linux/smp.h   |   3 ++
 include/xen/interface/sched.h | 100
+++---
 kernel/smp.c  |  51 +++
 kernel/up.c   |  18 +++
 11 files changed, 273 insertions(+), 59 deletions(-)
 create mode 100644 include/linux/hypervisor.h





signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chanwoo Choi]

On 2016년 07월 27일 12:51, Guenter Roeck wrote:
> On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:
>> Hi Chris,
>>
>> On 2016년 07월 27일 11:09, Chris Zhong wrote:
>>> Hi Guernter
>>>
>>> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
 Hi Chris,

 On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

 [ ... ]

>>  > +
>>  > +/* Properties of EXTCON_TYPE_DISP. */
>>  > +#define EXTCON_PROP_DISP_MIN   150
>>  > +#define EXTCON_PROP_DISP_MAX   150
>>  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>>  EXTCON_PROP_DISP_MIN)
>>
>>   + 1
>>
>>
>> ok.
>
> Tested with these "+1", it works for my DP patch.
>
 You should be able to use
 https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
 you didn't do that already).

 Thanks,
 Guenter
>>>
>>> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
>>>
>>>
>>
>> Do you test it with extcon_set_property_capability()?
>> And if you test this patch-es, could you send the tested-by tag for these 
>> patches?
>>
> 
> For my part I did. Above link is public, so you should be able to see
> the complete patch set which uses the new API from
> drivers/extcon/extcon-cros_ec.c.
> 
> I'll re-test tomorrow with the updated patches from your test branch.

OK. Thanks. 

Regards,
Chanwoo Choi

Re: [GIT PULL] usercopy protection for v4.8

[Kees Cook]

On Tue, Jul 26, 2016 at 2:55 PM, Kees Cook  wrote:
> Hi,
>
> This is my next pull request for v4.8, which introduces a kernel self
> protection of copy_to_user/copy_from_user that has been under review and
> test on the kernel-hardening list for a while. It has lived for a bit
> in -next, and appears to be ready IMO. There will be more improvements
> in the future, but this is a solid start.
>
> Again, if I can improve these pull request emails in any way, please
> let me know. :)

Hrm, part of the complexity of the KSPP work: this series depends on
_etext fixes in the arm and arm64 trees, so this should likely wait
until those trees are pulled.

-Kees

>
> Thanks!
>
> -Kees
>
> The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
>
>   Linux 4.7 (2016-07-24 12:23:50 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
> tags/usercopy-v4.8
>
> for you to fetch changes up to ed18adc1cdd00a5c55a20fbdaed4804660772281:
>
>   mm: SLUB hardened usercopy support (2016-07-26 14:43:54 -0700)
>
> 
> Implements HARDENED_USERCOPY verification of copy_to_user/copy_from_user
> bounds checking for most architectures on SLAB and SLUB.
>
> 
> Kees Cook (11):
>   mm: Implement stack frame object validation
>   mm: Hardened usercopy
>   x86/uaccess: Enable hardened usercopy
>   ARM: uaccess: Enable hardened usercopy
>   arm64/uaccess: Enable hardened usercopy
>   ia64/uaccess: Enable hardened usercopy
>   powerpc/uaccess: Enable hardened usercopy
>   sparc/uaccess: Enable hardened usercopy
>   s390/uaccess: Enable hardened usercopy
>   mm: SLAB hardened usercopy support
>   mm: SLUB hardened usercopy support
>
> Laura Abbott (1):
>   mm: Add is_migrate_cma_page
>
>  arch/Kconfig|   9 ++
>  arch/arm/Kconfig|   1 +
>  arch/arm/include/asm/uaccess.h  |  11 +-
>  arch/arm64/Kconfig  |   1 +
>  arch/arm64/include/asm/uaccess.h|  29 +++-
>  arch/arm64/kernel/arm64ksyms.c  |   4 +-
>  arch/arm64/lib/copy_from_user.S |   4 +-
>  arch/arm64/lib/copy_to_user.S   |   4 +-
>  arch/ia64/Kconfig   |   1 +
>  arch/ia64/include/asm/uaccess.h |  18 ++-
>  arch/powerpc/Kconfig|   1 +
>  arch/powerpc/include/asm/uaccess.h  |  21 ++-
>  arch/s390/Kconfig   |   1 +
>  arch/s390/lib/uaccess.c |   2 +
>  arch/sparc/Kconfig  |   1 +
>  arch/sparc/include/asm/uaccess_32.h |  14 +-
>  arch/sparc/include/asm/uaccess_64.h |  11 +-
>  arch/x86/Kconfig|   2 +
>  arch/x86/include/asm/thread_info.h  |  44 ++
>  arch/x86/include/asm/uaccess.h  |  10 +-
>  arch/x86/include/asm/uaccess_32.h   |   2 +
>  arch/x86/include/asm/uaccess_64.h   |   2 +
>  include/linux/mmzone.h  |   2 +
>  include/linux/slab.h|  12 ++
>  include/linux/thread_info.h |  24 
>  init/Kconfig|   2 +
>  mm/Makefile |   4 +
>  mm/slab.c   |  30 
>  mm/slub.c   |  40 ++
>  mm/usercopy.c   | 268 
> 
>  security/Kconfig|  28 
>  31 files changed, 573 insertions(+), 30 deletions(-)
>  create mode 100644 mm/usercopy.c
>
> --
> Kees Cook
> Brillo & Chrome OS Security



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Guenter Roeck]

On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:
> Hi Chris,
>
> On 2016년 07월 27일 11:09, Chris Zhong wrote:
>> Hi Guernter
>>
>> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
>>> Hi Chris,
>>>
>>> On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:
>>>
>>> [ ... ]
>>>
>  > +
>  > +/* Properties of EXTCON_TYPE_DISP. */
>  > +#define EXTCON_PROP_DISP_MIN   150
>  > +#define EXTCON_PROP_DISP_MAX   150
>  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>  EXTCON_PROP_DISP_MIN)
>
>   + 1
>
>
> ok.

 Tested with these "+1", it works for my DP patch.

>>> You should be able to use
>>> https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
>>> you didn't do that already).
>>>
>>> Thanks,
>>> Guenter
>>
>> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
>>
>>
>
> Do you test it with extcon_set_property_capability()?
> And if you test this patch-es, could you send the tested-by tag for these 
> patches?
>

For my part I did. Above link is public, so you should be able to see
the complete patch set which uses the new API from
drivers/extcon/extcon-cros_ec.c.

I'll re-test tomorrow with the updated patches from your test branch.

> I'll send the next version after a few days.

Great.

Thanks,
Guenter

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

[NeilBrown]

On Mon, Jul 25 2016, Michal Hocko wrote:

> On Sat 23-07-16 10:12:24, NeilBrown wrote:

>> Maybe that is impractical, but having firm rules like that would go a
>> long way to make it possible to actually understand and reason about how
>> MM works.  As it is, there seems to be a tendency to put bandaids over
>> bandaids.
>
> Ohh, I would definitely wish for this to be more clear but as it turned
> out over time there are quite some interdependencies between MM/FS/IO
> layers which make the picture really blur. If there is a brave soul to
> make that more clear without breaking any of that it would be really
> cool ;)

Just need that comprehensive regression-test-suite and off we go


>> > My thinking was that throttle_vm_writeout is there to prevent from
>> > dirtying too many pages from the reclaim the context.  PF_LESS_THROTTLE
>> > is part of the writeout so throttling it on too many dirty pages is
>> > questionable (well we get some bias but that is not really reliable). It
>> > still makes sense to throttle when the backing device is congested
>> > because the writeout path wouldn't make much progress anyway and we also
>> > do not want to cycle through LRU lists too quickly in that case.
>> 
>> "dirtying ... from the reclaim context" ??? What does that mean?
>
> Say you would cause a swapout from the reclaim context. You would
> effectively dirty that anon page until it gets written down to the
> storage.

I should probably figure out how swap really works.  I have vague ideas
which are probably missing important details...
Isn't the first step that the page gets moved into the swap-cache - and
marked dirty I guess.  Then it gets written out and the page is marked
'clean'.
Then further memory pressure might push it out of the cache, or an early
re-use would pull it back from the cache.
If so, then "dirtying in reclaim context" could also be described as
"moving into the swap cache" - yes?  So should there be a limit on dirty
pages in the swap cache just like there is for dirty pages in any
filesystem (the max_dirty_ratio thing) ??
Maybe there is?

>> The use of PF_LESS_THROTTLE in current_may_throttle() in vmscan.c is to
>> avoid a live-lock.  A key premise is that nfsd only allocates unbounded
>> memory when it is writing to the page cache.  So it only needs to be
>> throttled when the backing device it is writing to is congested.  It is
>> particularly important that it *doesn't* get throttled just because an
>> NFS backing device is congested, because nfsd might be trying to clear
>> that congestion.
>
> Thanks for the clarification. IIUC then removing throttle_vm_writeout
> for the nfsd writeout should be harmless as well, right?

Certainly shouldn't hurt from the perspective of nfsd.

>> >> The purpose of that flag is to allow a thread to dirty a page-cache page
>> >> as part of cleaning another page-cache page.
>> >> So it makes sense for loop and sometimes for nfsd.  It would make sense
>> >> for dm-crypt if it was putting the encrypted version in the page cache.
>> >> But if dm-crypt is just allocating a transient page (which I think it
>> >> is), then a mempool should be sufficient (and we should make sure it is
>> >> sufficient) and access to an extra 10% (or whatever) of the page cache
>> >> isn't justified.
>> >
>> > If you think that PF_LESS_THROTTLE (ab)use in mempool_alloc is not
>> > appropriate then would a PF_MEMPOOL be any better?
>> 
>> Why a PF rather than a GFP flag?
>
> Well, short answer is that gfp masks are almost depleted.

Really?  We have 26.

pagemap has a cute hack to store both GFP flags and other flag bits in
the one 32 it number per address_space.  'struct address_space' could
afford an extra 32 number I think.

radix_tree_root adds 3 'tag' flags to the gfp_mask.
There is 16bits of free space in radix_tree_node (between 'offset' and
'count').  That space on the root node could store a record of which tags
are set anywhere.  Or would that extra memory de-ref be a killer?

I think we'd end up with cleaner code if we removed the cute-hacks.  And
we'd be able to use 6 more GFP flags!!  (though I do wonder if we really
need all those 26).

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chanwoo Choi]

Hi Chris,

On 2016년 07월 27일 11:09, Chris Zhong wrote:
> Hi Guernter
> 
> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
>> Hi Chris,
>>
>> On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:
>>
>> [ ... ]
>>
  > +
  > +/* Properties of EXTCON_TYPE_DISP. */
  > +#define EXTCON_PROP_DISP_MIN   150
  > +#define EXTCON_PROP_DISP_MAX   150
  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
  EXTCON_PROP_DISP_MIN)

   + 1


 ok.
>>>
>>> Tested with these "+1", it works for my DP patch.
>>>
>> You should be able to use
>> https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
>> you didn't do that already).
>>
>> Thanks,
>> Guenter
> 
> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
> 
> 

Do you test it with extcon_set_property_capability()?
And if you test this patch-es, could you send the tested-by tag for these 
patches?

I'll send the next version after a few days.

Regards,
Chanwoo Choi

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

[Jisheng Zhang]

+1

On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi  wrote:

> Will Deacon wrote:
> > The kernel really needs to support both of those platforms :/
> >
> > For the memory-mapped counter registers, the architecture says:
> >
> >`If the implementation supports 64-bit atomic accesses, then the
> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
> >
> > which is borderline tautological. If we take the generous reading that
> > this means AArch64 CPUs can use readq (and I'm not completely
> > comfortable with that assertion, particularly as you say that it breaks
> > the model), then you still need to use readq_relaxed here to avoid a
> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> > exist over there, and if you use the generic implementation then it's
> > not atomic. In which case, we end up with the current code, as well as a
> > readq_relaxed guarded by a questionable #ifdef that is known to break a
> > supported platform for an unknown performance improvement. Hardly a big
> > win.  
> 
> I know Fu dropped this patch, and I don't want to kick a dead horse, but 
> I was wondering if it would be okay to do this:
> 
> static u64 arch_counter_get_cntvct_mem(void)
> {
> #ifdef readq_relaxed
>   return readq_relaxed(arch_counter_base + CNTVCT_LO);
> #else
>   u32 vct_lo, vct_hi, tmp_hi;
> 
>   do {
>   vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>   vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
>   tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>   } while (vct_hi != tmp_hi);
> 
>   return ((u64) vct_hi << 32) | vct_lo;
> #endif
> }
> 
> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h.  Why 
> would the function exist if AArch64 CPUs can't use it?

+1

I measured the performance on berlin arm64 platforms:

compared with original version, using readq_relaxed could reduce
time of arch_counter_get_cntvct_mem() by about 42%!

Thanks,
Jisheng

Re: debug tip after earlycon is closed?

[Masahiro Yamada]

Hi Sebastian,


2016-07-27 11:17 GMT+09:00 Sebastian Reichel :
> Hi,
>
> On Wed, Jul 27, 2016 at 10:23:09AM +0900, Masahiro Yamada wrote:
>> When the kernel fails to boot and its log console is silent,
>> I use earlycon and I often find the cause of error with it.
>>
>> But, I have been wondering if there is an easy-to-use
>> debug tip which is available after earlycon is disabled.
>>
>> I noticed the current mainline would not boot on my ARMv8 board.
>> According to the following log, I am guessing something wrong
>> is happening after the "bootconsole [uniphier0] disabled" log.
>>
>> Is there a good practice to see more log?
>
> Documentation/kernel-parameters.txt
> keep_bootcon[KNL]
> Do not unregister boot console at start. This is only
> useful for debugging when something happens in the 
> window
> between unregistering the boot console and 
> initializing
> the real console.


I did not know this kernel parameter, and it is exactly what I wanted.
Thanks a lot!


-- 
Best Regards
Masahiro Yamada

from Walters's Wife, Deborah writing from my sick bed

[Deborah Walters]

from Walters's Wife, Deborah writing from my sick bed
This is Walters's wife, Deborah. I am writing this message to you today because 
of my Love for the less privileges. As a fellow faithful person like you, it is 
my desire and enthusiasm to donate amount of $19.1 million in your hands for a 
charity project, which will benefit the less privilege. Kindly reply for more 
detail;
Best Regards and remain bless.
Mrs. Deborah Walters

[PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Bob Liu]

The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
 * max_indirect_segs: Maximum amount of segments.
 * max_ring_page_order: Maximum order of pages to be used for the shared ring.
 * max_queues: Maximum of queues(rings) to be used.

But the storage backend, workload, and guest memory result in very different
tuning requirements. It's impossible to centrally predict application
characteristics so it's best to leave allow the settings can be dynamiclly
adjusted based on workload inside the Guest.

Usage:
Show current values:
cat /sys/devices/vbd-xxx/max_indirect_segs
cat /sys/devices/vbd-xxx/max_ring_page_order
cat /sys/devices/vbd-xxx/max_queues

Write new values:
echo  > /sys/devices/vbd-xxx/max_indirect_segs
echo  > /sys/devices/vbd-xxx/max_ring_page_order
echo  > /sys/devices/vbd-xxx/max_queues

Signed-off-by: Bob Liu 
--
v3:
 * Remove new_max_indirect_segments.
 * Fix BUG_ON().
v2:
 * Rename to max_ring_page_order.
 * Remove the waiting code suggested by Roger.
---
 drivers/block/xen-blkfront.c |  277 --
 1 file changed, 269 insertions(+), 8 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 1b4c380..57baa54 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -212,6 +212,10 @@ struct blkfront_info
/* Save uncomplete reqs and bios for migration. */
struct list_head requests;
struct bio_list bio_list;
+   /* For dynamic configuration. */
+   unsigned int reconfiguring:1;
+   unsigned int max_ring_page_order;
+   unsigned int max_queues;
 };
 
 static unsigned int nr_minors;
@@ -1350,6 +1354,31 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(&info->rinfo[i]);
 
+   /* Remove old xenstore nodes. */
+   if (info->nr_ring_pages > 1)
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-page-order");
+
+   if (info->nr_rings == 1) {
+   if (info->nr_ring_pages == 1) {
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-ref");
+   } else {
+   for (i = 0; i < info->nr_ring_pages; i++) {
+   char ring_ref_name[RINGREF_NAME_LEN];
+
+   snprintf(ring_ref_name, RINGREF_NAME_LEN, 
"ring-ref%u", i);
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, 
ring_ref_name);
+   }
+   }
+   } else {
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, 
"multi-queue-num-queues");
+
+   for (i = 0; i < info->nr_rings; i++) {
+   char queuename[QUEUE_NAME_LEN];
+
+   snprintf(queuename, QUEUE_NAME_LEN, "queue-%u", i);
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, queuename);
+   }
+   }
kfree(info->rinfo);
info->rinfo = NULL;
info->nr_rings = 0;
@@ -1763,15 +1792,20 @@ static int talk_to_blkback(struct xenbus_device *dev,
const char *message = NULL;
struct xenbus_transaction xbt;
int err;
-   unsigned int i, max_page_order = 0;
+   unsigned int i, backend_max_order = 0;
unsigned int ring_page_order = 0;
 
err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "max-ring-page-order", "%u", &max_page_order);
+  "max-ring-page-order", "%u", &backend_max_order);
if (err != 1)
info->nr_ring_pages = 1;
else {
-   ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
+   if (info->max_ring_page_order)
+   /* Dynamic configured through /sys. */
+   ring_page_order = min(info->max_ring_page_order, 
backend_max_order);
+   else
+   /* Default. */
+   ring_page_order = min(xen_blkif_max_ring_order, 
backend_max_order);
info->nr_ring_pages = 1 << ring_page_order;
}
 
@@ -1894,7 +1928,13 @@ static int negotiate_mq(struct blkfront_info *info)
if (err < 0)
backend_max_queues = 1;
 
-   info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
+   if (info->max_queues)
+   /* Dynamic configured through /sys */
+   info->nr_rings = min(backend_max_queues, info->max_queues);
+   else
+   /* Default. */
+   info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
+
/* We need at least one ring. */
if (!info->nr_rings)
info->nr_rings = 1;
@@ -2352,11 +2392,198 @@ static void blkfront_gather_backend_features(struct 
blkfront_info *info)
NULL);
if (err)
in

[PATCH] tools: iio: iio_generic_buffer: initialize channel array pointer

[Alison Schofield]

Uninitialized channel pointer causes segmentation fault when we
call free(channel) during cleanup() with no channels initialized.
This happens when you exit early for usage errors.  Initialize
the pointer to NULL when it is declared.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 tools/iio/iio_generic_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c
index 0e8a1f7..ae68bf0 100644
--- a/tools/iio/iio_generic_buffer.c
+++ b/tools/iio/iio_generic_buffer.c
@@ -348,7 +348,7 @@ int main(int argc, char **argv)
int notrigger = 0;
char *dummy;
 
-   struct iio_channel_info *channels;
+   struct iio_channel_info *channels = NULL;
 
register_cleanup();
 
-- 
2.1.4

Re: [PATCH v3] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

[Baolin Wang]

Hi Felipe,

On 26 July 2016 at 19:06, Felipe Ferreri Tonello  wrote:
> Hi Baolin,
>
> Sorry for not replying for previous emails because for some reason these
> emails were archived. :(
>
> On 12/07/16 10:01, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>> Acked-by: Michal Nazarewicz 
>> ---
>> Changelog:
>> v2:
>>  - Simplify the method to get buffer length.
>> v1:
>>  - Remove the in_ep modification.
>>  - Remove max_t() function.
>>
>>  drivers/usb/gadget/function/f_midi.c |   11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..3486941 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -359,10 +359,13 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> + unsigned length;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>> +
>> + req = midi_alloc_ep_req(midi->out_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>>
>
> Yes, as mentioned before, my intent was to align the size otherwise an
> actual nasty bug happens.
>
> I have two problems with this approach:
> * usb_ep_align_maybe() has a bug that it doesn't convert wMaxPacketSize
> endianness to the CPU. See my patch on that[1] subject. Also this

Yes, you are right, I missed that.

> function uses round_up which expects x and y to be a power of 2, is that
> a feasible assumption?

I suppose it only expects y is a power of 2.

> * If the gadget driver doesn't support quirk_ep_out_aligned_size,
> usb_ep_align_maybe() can potentially return a len < wMaxPacketSize.
> Basically causing a regression.

Okay.

>
> I believe we should protect this bad behavior on alloc_ep_req() in
> drivers/usb/gadget/u_f.c by forcing align the size if the endpoint in
> subject is OUT.
>
> [1] [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using
> wMaxPacketSize: https://lkml.org/lkml/2016/7/25/1028


-- 
Baolin.wang
Best Regards

[RESEND PATCH 2/4] fs: befs: Coding style fix

[Salah Triki]

Constant has to be capitalized.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/btree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/befs/btree.c b/fs/befs/btree.c
index 307645f9..e59ad20 100644
--- a/fs/befs/btree.c
+++ b/fs/befs/btree.c
@@ -85,7 +85,7 @@ struct befs_btree_node {
 };
 
 /* local constants */
-static const befs_off_t befs_bt_inval = 0xULL;
+static const befs_off_t BEFS_BT_INVAL = 0xULL;
 
 /* local functions */
 static int befs_btree_seekleaf(struct super_block *sb, const befs_data_stream 
*ds,
@@ -467,7 +467,7 @@ befs_btree_read(struct super_block *sb, const 
befs_data_stream *ds,
while (key_sum + this_node->head.all_key_count <= key_no) {
 
/* no more nodes to look in: key_no is too large */
-   if (this_node->head.right == befs_bt_inval) {
+   if (this_node->head.right == BEFS_BT_INVAL) {
*keysize = 0;
*value = 0;
befs_debug(sb,
@@ -608,7 +608,7 @@ static int
 befs_leafnode(struct befs_btree_node *node)
 {
/* all interior nodes (and only interior nodes) have an overflow node */
-   if (node->head.overflow == befs_bt_inval)
+   if (node->head.overflow == BEFS_BT_INVAL)
return 1;
else
return 0;
-- 
1.9.1

[RESEND PATCH 4/4] fs: befs: Remove goto from befs_bread_iaddr

[Salah Triki]

Since goto statement merely returns NULL, replace it with return
statement.

Signed-off-by: Salah Triki 
---
 fs/befs/io.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/fs/befs/io.c b/fs/befs/io.c
index 4223b77..af631a6 100644
--- a/fs/befs/io.c
+++ b/fs/befs/io.c
@@ -37,7 +37,7 @@ befs_bread_iaddr(struct super_block *sb, befs_inode_addr 
iaddr)
if (iaddr.allocation_group > befs_sb->num_ags) {
befs_error(sb, "BEFS: Invalid allocation group %u, max is %u",
   iaddr.allocation_group, befs_sb->num_ags);
-   goto error;
+   return NULL;
}
 
block = iaddr2blockno(sb, &iaddr);
@@ -49,13 +49,9 @@ befs_bread_iaddr(struct super_block *sb, befs_inode_addr 
iaddr)
if (bh == NULL) {
befs_error(sb, "Failed to read block %lu",
   (unsigned long)block);
-   goto error;
+   return NULL;
}
 
befs_debug(sb, "<--- %s", __func__);
return bh;
-
-  error:
-   befs_debug(sb, "<--- %s ERROR", __func__);
-   return NULL;
 }
-- 
1.9.1

[RESEND PATCH 3/4] fs: befs: Remove useless calls to brelse in befs_find_brun_dblindirect

[Salah Triki]

The calls to brelse are useless since dbl_indir_block and indir_block
are NULL.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/datastream.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c
index e224b9a..b68b6f9 100644
--- a/fs/befs/datastream.c
+++ b/fs/befs/datastream.c
@@ -471,7 +471,6 @@ befs_find_brun_dblindirect(struct super_block *sb,
   (unsigned long)
   iaddr2blockno(sb, &data->double_indirect) +
   dbl_which_block);
-   brelse(dbl_indir_block);
return BEFS_ERR;
}
 
@@ -496,7 +495,6 @@ befs_find_brun_dblindirect(struct super_block *sb,
befs_error(sb, "%s couldn't read the indirect block "
   "at blockno %lu", __func__, (unsigned long)
   iaddr2blockno(sb, &indir_run) + which_block);
-   brelse(indir_block);
return BEFS_ERR;
}
 
-- 
1.9.1

[RESEND PATCH 1/4] fs: befs: Remove redundant validation from befs_find_brun_direct

[Salah Triki]

The only caller of befs_find_brun_direct is befs_fblock2brun, which
already validates that the block is within the range of direct blocks.
So remove the duplicate validation.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/datastream.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c
index 26cc417..e224b9a 100644
--- a/fs/befs/datastream.c
+++ b/fs/befs/datastream.c
@@ -249,17 +249,9 @@ befs_find_brun_direct(struct super_block *sb, const 
befs_data_stream *data,
int i;
const befs_block_run *array = data->direct;
befs_blocknr_t sum;
-   befs_blocknr_t max_block =
-   data->max_direct_range >> BEFS_SB(sb)->block_shift;
 
befs_debug(sb, "---> %s, find %lu", __func__, (unsigned long)blockno);
 
-   if (blockno > max_block) {
-   befs_error(sb, "%s passed block outside of direct region",
-  __func__);
-   return BEFS_ERR;
-   }
-
for (i = 0, sum = 0; i < BEFS_NUM_DIRECT_BLOCKS;
 sum += array[i].len, i++) {
if (blockno >= sum && blockno < sum + (array[i].len)) {
-- 
1.9.1

Re: Volunteering for BeFS maintainership

[Theodore Ts'o]

On Tue, Jul 26, 2016 at 09:30:13PM +0100, Luis de Bethencourt wrote:
> > 
> > Sounds great!  Do you have a git tree set up for your befs development?
> 
> Yes, I have the following in github (if that is OK):
> https://github.com/luisbg/linux-befs
> 
> I have two branches there based on Linus' master:
>  - befs-linus: with patches Andrew Morton has approved
>  - befs-next: with patches I've tested but that remain under review

So it sounds like you plan to send patches through Andrew's tree.
That works fine, although if you end up sending a larger number of
patches through the linux-mm tree, it might make sense for you to send
patches to Linus directly.  So if you have a chance to get a GPG key
which is signed by people in the Kernel keyring, that would be a good
preparation for that eventuality.  That will require face-to-face
verification of your identity by people who are already in the GPG web
of trust, so it's good to plan for that in advance.

> It would be amazing to have a framework to run xfstests in a GCE VM.

Please see:

   https://thunk.org/gce-xfstests

and

https://github.com/tytso/xfstests-bld/blob/master/README.md

for more information.

I plan to do some work to make it simpler to get started using
gce-xfstests.  (Specifically, so you don't have to build the tree and
generate your own GCE image, but instead using a premade one.)

Are there userspace tools available to create and consistency check
BeFS file systems?  If so, I can try to get those included into the
test appliance image.  (Better yet, if you can arrange to have someone
create a debian package for BeFStools, that would be great.)

- Ted

Re: [PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel

[Mark yao]

On 2016年07月26日 17:02, Thierry Reding wrote:

On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote:

On 2016年07月25日 23:21, Thierry Reding wrote:

 On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote:

 Allow user add display timing on device tree with simple-panel-dsi
 or simple-panel.

 Cc: Thierry Reding 
 Cc: Rob Herring 
 Cc: Mark Rutland 

 Signed-off-by: Mark Yao 
 ---
  .../bindings/display/panel/simple-panel.txt| 48 
++
  1 file changed, 48 insertions(+)

 Sorry, not going to happen. Read this for an explanation of why not:

 
https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html

 Thierry


Hi Thierry

The blog actually not persuade me why can't use display timing on
device tree.

Okay, perhaps read it again, it addresses most of your points below.


1, Binding panel as a simple string on device tree seems simple on device tree,
but it's complex on kernel code, and kernel code would became bigger and
bigger.

I don't think the video timings in the simple-panel driver are very
complex. They also don't use very much space. And if you're really
concerned about space you can always use conditional compilation and
Kconfig symbols to remove timings for panels that you don't use.

Also, panels are characterized by much more than just video timings.
There were attempts, way back, to fully describe panels in device tree
and that failed. What you propose here is a partial solution to a much
more complex problem.

This is all explained in the blog post.


2, Our customer always ask me, where is the display timing? They only find a
simple panel string on device tree,  need search the kernel code to find the
actually timing. They are used to find all device info on device tree, but
panel timing info is not, this would confuse them. They don't want to know how
code work, just want a easier interface.

That's not a very good argument. There's plenty of data that's not in
device tree for other devices, why should panels be different? Also, I
would hope that any customer of yours knows their way around kernel
code and can therefore easily add video timings for new panels. It's
quite trivial to do, and there are many examples on how to do it.


3, I think device tree not only can use for kernel, other module also can use
it. on our project, we use uboot + kernel, the uboot support fdt, that function
can parsing device tree. So if describe the display timing on device tree, both
uboot and kernel can share same display timing, not need to describe twice, it
would save work and not easy to make mistake.

That's a bit of a stretch. Video timings is fairly straightforward data
and can be easily added to any other piece of code that you want to run.
Yes you will have to duplicate the data, but how is that different from
duplicating all the driver code?


4, For differentiation product, we face many different panel, every once in a
while, need to add a new panel, we can't convert all the panel , code the panel
on kernel seems too bad, and the kernel image became bigger and bigger.

Why can't you convert all the panels? We already support a bunch of them
and haven't yet run into any problems. If you do encounter any issues
trying to port panels to the DRM panel infrastructure, please let me
know and I can help sort them out.

The kernel image size isn't a problem either. In any modern kernel the
video timing data in the panel driver is tiny compared to the rest.


Generally, Our customer don't want to do any modify on kernel, they just modify
device tree to bring up their device. Describe the panel timing on device tree,
would make customer easy to use and reuse it.

Yes, that would perhaps make it easier for them to bring up the device.
But soon after they'll notice that there are glitches when turning the
panel on and off, and then they'll realize that they can't fix that
using their simple device tree.
About the panel on and off, I don't think the panel-simple do the good 
enough.


panel-simple only have one gpio and one regulator, and their sequence is 
hard code, Why not a panel have two gpio or two regulator? On our 
project, we find many customer don't use the RC to do panel reset, they 
directly use gpio reset, so they need a gpio to do panel reset.


the device tree panel's on and off function is what the next step I want 
to upstream, on our downstream kernel, we do like that:


panel {
power_ctrl {
  power0 {
  gpios = ;
  delay,ms = <3>;
  }
  power1 {
  regulator = ;
  delay,ms = <3>;
  }
  power2 {
  backlight = ;
  delay,ms = <3>;
  }
}
}
and on driver, power on sequence with power0->power1->power2, power down 
with power2->power1->power0.
if user want to swap the power, can easy do that by  adjust dts pow

STRICTLY CONFIDENTIAL .

[Acct. Dept. Bank Of China]

I have important transaction for you as next of kin to claim US$8.37m  Mail me 
on my private email: chi...@yahoo.com   so i can send you more details

Thanks

Mr.Chim Wai Kim










===

DISCLAIMER: This email and any files it contains are confidential and intended 
for the use of the recipient(s) only. If you are not the intended recipient you 
should notify the sender immediately and destroy the material from your system. 
Unauthorised use, disclosure, copying, distribution or any action taken or 
omitted to be taken in reliance on the information in this e-mail is prohibited 
and may be unlawful..And might be punishable under 
section 67B of the IT Act (2008

linux-next: manual merge of the net-next tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

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

  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

between commit:

  cafc4cd0c8b8 ("arm64: dts: apm: Use lowercase consistently for hex constants")

from the arm-soc tree and commit:

  8e694cd2762c ("dtb: xgene: Add MDIO node")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 21028b145d91,2e1e5daa1dc7..
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@@ -628,9 -636,9 +636,9 @@@
sgenet0: ethernet@1f61 {
compatible = "apm,xgene2-sgenet";
status = "disabled";
-   reg = <0x0 0x1f61 0x0 0x1>,
+   reg = <0x0 0x1f61 0x0 0xd100>,
 -<0x0 0x1f60 0x0 0Xd100>,
 -<0x0 0x2000 0x0 0X2>;
 +<0x0 0x1f60 0x0 0xd100>,
 +<0x0 0x2000 0x0 0x2>;
interrupts = <0 96 4>,
 <0 97 4>;
dma-coherent;

Re: [PATCH 3/4] x86/ioapic: Fix lost ioapic resource after hot-removal and hotadd

[Rui Wang]

On Wed, July 27, 2016 4:24 AM, Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:16AM +0800, Rui Wang wrote:
> > ioapic resource at 0xfecx gets lost from /proc/iomem after
> > hot-removing and then hot-adding the ioapic devices.
> >
> > After system boot, in /proc/iomem:
> > fec0-fecf : PNP0003:00
> >   fec0-fec003ff : IOAPIC 0
> >   fec01000-fec013ff : IOAPIC 1
> >   fec4-fec403ff : IOAPIC 2
> >   fec8-fec803ff : IOAPIC 3
> >   fecc-fecc03ff : IOAPIC 4
> >
> > Then hot-remove IOAPIC 2 and hot-add it again:
> > fec0-fecf : PNP0003:00
> >   fec0-fec003ff : IOAPIC 0
> >   fec01000-fec013ff : IOAPIC 1
> >   fec8-fec803ff : IOAPIC 3
> >   fecc-fecc03ff : IOAPIC 4
> >
> > The range at 0xfec4 is lost from /proc/iomem. It is because
> > handle_ioapic_add() requests resource from either PCI config BAR or
> > acpi _CRS, not both. But Intel platforms map the IOxAPIC registers
> 
> s/acpi/ACPI/
> s/ioapic/IOAPIC/ throughout
> 
> > at both the PCI config BAR (called MBAR) and the 0xfecX_YZ00 to
> > 0xfecX_Y2FF range (called ABAR). Both of the ranges should be claimed
> 
> I guess you mean the 0xfecX_YZ00-0xfecX_Y2FF range appears in _CRS?

Yes. That range appears in _CRS for each IOAPIC. I'll make it cleaner in
the commit message.

Thanks
Rui

Re: [PATCH 1/4] x86/ioapic: Support hot-removal of IOAPICs present during boot boot

[Rui Wang]

On Wed, July 27, 2016 4:20 AM Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:14AM +0800, Rui Wang wrote:
> > IOAPICs present during system boot aren't added to ioapic_list, thus
> > are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() during root bus enumeration.
> >
> > Signed-off-by: Rui Wang 
> > ---
> >  drivers/acpi/internal.h |  2 --
> >  drivers/acpi/ioapic.c   |  7 ---
> >  drivers/acpi/pci_root.c | 13 -  drivers/pci/setup-bus.c |
> > 5 -
> >  include/linux/acpi.h|  6 ++
> >  5 files changed, 26 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h index
> > 27cc7fe..6d8e67e 100644
> > --- a/drivers/acpi/internal.h
> > +++ b/drivers/acpi/internal.h
> > @@ -40,10 +40,8 @@ int acpi_sysfs_init(void);  void
> > acpi_container_init(void);  void acpi_memory_hotplug_init(void);
> >  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> > -int acpi_ioapic_add(struct acpi_pci_root *root);  int
> > acpi_ioapic_remove(struct acpi_pci_root *root);  #else -static inline
> > int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
> 
> It would be nicer if the interface change and header file munging were in a
> separate patch so they wouldn't obscure the meat of the change, i.e., the
> addition of calls to acpi_ioapic_add().

Sure. I'll split it in a newer version.

> 
> >  static inline int acpi_ioapic_remove(struct acpi_pci_root *root) {
> > return 0; }  #endif  #ifdef CONFIG_ACPI_DOCK diff --git
> > a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c index ccdc8db..0f272e2
> > 100644
> > --- a/drivers/acpi/ioapic.c
> > +++ b/drivers/acpi/ioapic.c
> > @@ -189,16 +189,17 @@ exit:
> > return AE_OK;
> >  }
> >
> > -int acpi_ioapic_add(struct acpi_pci_root *root)
> > +int acpi_ioapic_add(acpi_handle root_handle)
> >  {
> > acpi_status status, retval = AE_OK;
> >
> > -   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device-
> >handle,
> > +   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle,
> >  UINT_MAX, handle_ioapic_add, NULL,
> > -root->device->handle, (void **)&retval);
> > +root_handle, (void **)&retval);
> >
> > return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -
> ENODEV;
> > }
> > +EXPORT_SYMBOL_GPL(acpi_ioapic_add);
> 
> What loadable module needs to call this?  It shouldn't be exported unless
> there is such a module.

It's called from the ioapic driver which is built-in. I'll remove the export.

Thanks
Rui

[RESEND PATCH V3] fs: befs: Insert NULL inode to dentry

[Salah Triki]

As VFS expects, lookup inserts NULL inode to dentry when the named inode
does not exist.

Signed-off-by: Salah Triki 
---
 fs/befs/linuxvfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c
index c734f21..2fea87b 100644
--- a/fs/befs/linuxvfs.c
+++ b/fs/befs/linuxvfs.c
@@ -184,6 +184,7 @@ befs_lookup(struct inode *dir, struct dentry *dentry, 
unsigned int flags)
 
if (ret == BEFS_BT_NOT_FOUND) {
befs_debug(sb, "<--- %s %pd not found", __func__, dentry);
+   d_add(dentry, NULL);
return ERR_PTR(-ENOENT);
 
} else if (ret != BEFS_OK || offset == 0) {
-- 
1.9.1

Re: [PATCH v3 2/7] Split up struct warn_args

[kbuild test robot]

Hi,

[auto build test ERROR on next-20160726]
[also build test ERROR on v4.7]
[cannot apply to stable/master linus/master linux/master v4.7-rc7 v4.7-rc6 
v4.7-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Emese-Revfy/Introduce-the-initify-gcc-plugin/20160727-084514
config: arm-u8500_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/compiler.h:201,
from include/linux/linkage.h:4,
from include/linux/kernel.h:6,
from include/linux/debug_locks.h:4,
from kernel/panic.c:11:
   kernel/panic.c: In function 'warn_slowpath_null':
>> include/linux/stddef.h:7:14: error: incompatible type for argument 7 of 
>> '__warn'
#define NULL ((void *)0)
 ^
>> kernel/panic.c:544:74: note: in expansion of macro 'NULL'
 __warn(file, line, __builtin_return_address(0), TAINT_WARN, NULL, NULL, 
NULL);
 ^
   kernel/panic.c:478:6: note: expected 'va_list {aka __va_list}' but argument 
is of type 'void *'
void __warn(const char *file, int line, void *caller, unsigned taint,
 ^
--
   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from lib/bug.c:43:
   lib/bug.c: In function 'report_bug':
>> include/linux/stddef.h:7:14: error: incompatible type for argument 7 of 
>> '__warn'
#define NULL ((void *)0)
 ^
>> lib/bug.c:171:16: note: in expansion of macro 'NULL'
 NULL, NULL);
   ^
   In file included from arch/arm/include/asm/bug.h:59:0,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from include/asm-generic/preempt.h:4,
from ./arch/arm/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from lib/bug.c:44:
   include/asm-generic/bug.h:84:6: note: expected 'va_list {aka __va_list}' but 
argument is of type 'void *'
void __warn(const char *file, int line, void *caller, unsigned taint,
 ^

vim +/__warn +7 include/linux/stddef.h

^1da177e Linus Torvalds   2005-04-16   1  #ifndef _LINUX_STDDEF_H
^1da177e Linus Torvalds   2005-04-16   2  #define _LINUX_STDDEF_H
^1da177e Linus Torvalds   2005-04-16   3  
607ca46e David Howells2012-10-13   4  #include 
^1da177e Linus Torvalds   2005-04-16   5  
^1da177e Linus Torvalds   2005-04-16   6  #undef NULL
^1da177e Linus Torvalds   2005-04-16  @7  #define NULL ((void *)0)
6e218287 Richard Knutsson 2006-09-30   8  
6e218287 Richard Knutsson 2006-09-30   9  enum {
6e218287 Richard Knutsson 2006-09-30  10false   = 0,

:: The code at line 7 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: debug tip after earlycon is closed?

[Sebastian Reichel]

Hi,

On Wed, Jul 27, 2016 at 10:23:09AM +0900, Masahiro Yamada wrote:
> When the kernel fails to boot and its log console is silent,
> I use earlycon and I often find the cause of error with it.
> 
> But, I have been wondering if there is an easy-to-use
> debug tip which is available after earlycon is disabled.
> 
> I noticed the current mainline would not boot on my ARMv8 board.
> According to the following log, I am guessing something wrong
> is happening after the "bootconsole [uniphier0] disabled" log.
> 
> Is there a good practice to see more log?

Documentation/kernel-parameters.txt 
keep_bootcon[KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the 
window
between unregistering the boot console and initializing
the real console.

-- Sebastian


signature.asc
Description: PGP signature

[GIT PULL] xfs: update for 4.8-rc1

[Dave Chinner]

Hi Linus,

Can you please pull the XFS update from the tag below? You will get
a merge conflict against fs/xfs/xfs_ioctl.c - I committed "xfs: fix
type confusion in xfs_ioc_swapext" with an additional comment to
explain why such a unique test was being done in the ioctl code.

As for the rest of the changes, the major addition is the new iomap
based block mapping infrastructure. We've been kicking this about
locally for years, but there are other filesystems want to use it
too (e.g.  gfs2). Now it is fully working, reviewed and ready for
merge and be used by other filesystems.  There are a lot of other
fixes and cleanups in the tree, but those are XFS internal things
and none are of the scale or visibility of the iomap changes. See
the tag description below for details.

I am likely to send another pull request next week - we're ijust
about ready to merge some new functionality (on disk block->owner
reverse mapping infrastructure), but that's a huge chunk of code (74
files changed, 7283 insertions(+), 1114 deletions(-)) so I'm keeping
that separate to all the "normal" pull request changes so they don't
get lost in the noise.

-Dave.

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git 
tags/xfs-for-linus-4.8-rc1

for you to fetch changes up to f2bdfda9a1c668539bc85baf5625f6f14bc510b1:

  Merge branch 'xfs-4.8-misc-fixes-4' into for-next (2016-07-22 14:10:56 +1000)


xfs: update for 4.8-rc1

Changes in this update:
o generic iomap based IO path infrastructure
o generic iomap based fiemap implementation
o xfs iomap based Io path implementation
o buffer error handling fixes
o tracking of in flight buffer IO for unmount serialisation
o direct IO and DAX io path separation and simplification
o shortform directory format definition changes for wider platform compatibility
o various buffer cache fixes
o cleanups in preparation for rmap merge
o error injection cleanups and fixes
o log item format buffer memory allocation restructuring to prevent rare OOM
  reclaim deadlocks
o sparse inode chunks are now fully supported.


Arnd Bergmann (1):
  xfs: remove dax code from object file when disabled

Brian Foster (7):
  xfs: fix broken multi-fsb buffer logging
  xfs: remove spurious shutdown type check from xfs_bmap_finish()
  xfs: cancel eofblocks background trimming on remount read-only
  xfs: refactor xfs_reserve_blocks() to handle ENOSPC correctly
  xfs: exclude never-released buffers from buftarg I/O accounting
  xfs: track and serialize in-flight async buffers against unmount
  xfs: skip dirty pages in ->releasepage()

Christoph Hellwig (25):
  xfs: define XFS_IOC_FREEZE even if FIFREEZE is defined
  fs: move struct iomap from exportfs.h to a separate header
  fs: introduce iomap infrastructure
  fs: support DAX based iomap zeroing
  fs: iomap based fiemap implementation
  xfs: make xfs_bmbt_to_iomap available outside of xfs_pnfs.c
  xfs: reorder zeroing and flushing sequence in truncate
  xfs: implement iomap based buffered write path
  xfs: remove buffered write support from __xfs_get_blocks
  xfs: use iomap fiemap implementation
  xfs: use iomap infrastructure for DAX zeroing
  xfs: handle 64-bit length in xfs_iozero
  xfs: use xfs_zero_range in xfs_zero_eof
  xfs: split xfs_free_file_space in manageable pieces
  xfs: kill xfs_zero_remaining_bytes
  xfs: don't pass ioflags around in the ioctl path
  xfs: kill ioflags
  xfs: remove s_maxbytes enforcement in xfs_file_read_iter
  xfs: split xfs_file_read_iter into buffered and direct I/O helpers
  xfs: stop using generic_file_read_iter for direct I/O
  xfs: direct calls in the direct I/O path
  xfs: split direct I/O and DAX path
  xfs: kill xfs_dir2_sf_off_t
  xfs: kill xfs_dir2_inou_t
  xfs: remove __arch_pack

Dan Carpenter (1):
  xfs: don't allow negative error tags

Darrick J. Wong (6):
  xfs: check offsets of variable length structures
  xfs: enable buffer deadlock postmortem diagnosis via ftrace
  xfs: check for a valid error_tag in errortag_add
  xfs: rearrange xfs_bmap_add_free parameters
  xfs: convert list of extents to free into a regular list
  xfs: refactor btree maxlevels computation

Dave Chinner (14):
  xfs: reduce lock hold times in buffer writeback
  Merge branch 'fs-4.8-iomap-infrastructure' into for-next
  Merge branch 'xfs-4.8-iomap-write' into for-next
  xfs: separate freelist fixing into a separate helper
  Merge branch 'xfs-4.8-misc-fixes-2' into for-next
  Merge branch 'xfs-4.8-misc-fixes-3' into for-next
  Merge branch 'xfs-4.8-buf-fixes' into for-next
 

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

[Caesar Wang]

On 2016年07月27日 10:00, Guenter Roeck wrote:

On 07/26/2016 05:42 PM, Caesar Wang wrote:


On 2016年07月27日 01:00, Guenter Roeck wrote:

On Tue, Jul 26, 2016 at 10:47:16PM +0800, Caesar Wang wrote:

On 2016年07月26日 21:39, Guenter Roeck wrote:

static int rockchip_saradc_probe(struct platform_device *pdev)
{
struct rockchip_saradc *info = NULL;
@@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct
platform_device *pdev)
if (IS_ERR(info->regs))
return PTR_ERR(info->regs);

+ /*
+ * The reset should be an optional property, as it should work
+ * with old devicetrees as well
+ */
+ info->reset = devm_reset_control_get_optional(&pdev->dev,
+ "saradc-apb");
Does anyone know what the _optional API is for ? It seems to be 
exactly

the same
as devm_reset_control_get().

“
As far as I see, the difference is WARN_ON(1)
when  is not defined.


The _optional functions were introduced by the following commit:

->8-
commit b424080a9e086e683ad5fdc624a7cf3c024e0c0f
Author: Philipp Zabel 
Date: Fri Mar 7 15:18:47 2014 +0100

reset: Add optional resets and stubs

This patch adds device_reset_optional and
variants that drivers can use to indicate they can function without 
control
over the reset line. For those functions, stubs are added so the 
drivers can

be compiled with CONFIG_RESET_CONTROLLER disabled.
Also, device_reset is annotated with __must_check. Drivers
ignoring the return
value should use device_reset_optional instead.


Is that really what we are looking for here ? CONFIG_RESET_CONTROLLER
is required for other functions of rk3399, isn't it ?


Right, as the DRM and thermal are depend on the 
CONFIG_RESET_CONTROLLER .




Since "optional" doesn't really mean "the reset property is optional"
but "CONFIG_RESET_CONTROLLER is optional", I would suggest to use
devm_reset_control_get().


Agree, free riding.
Maybe the API (_optional) will be changed in later.
As someone make a point present an idea on 
http://www.spinics.net/lists/kernel/msg2306677.html


Okay,  devm_reset_control_get() will be better, anyway the driver has 
been depend on the CONFIG_RESET_CONTROLLER.

--

I will send a new patch for upstream if nobody object it on today.


Sorry for noisy!




Guenter


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



--
caesar wang | software engineer | w...@rock-chip.com

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chris Zhong]

Hi Guernter

On 07/27/2016 09:44 AM, Guenter Roeck wrote:

Hi Chris,

On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

[ ... ]


 > +
 > +/* Properties of EXTCON_TYPE_DISP. */
 > +#define EXTCON_PROP_DISP_MIN   150
 > +#define EXTCON_PROP_DISP_MAX   150
 > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
 EXTCON_PROP_DISP_MIN)

  + 1


ok.


Tested with these "+1", it works for my DP patch.


You should be able to use
https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
you didn't do that already).

Thanks,
Guenter


Thanks Guenter, and I saw this bug has fixed in extcon-test branch.


Thanks
Chris Zhong

Re: Volunteering for BeFS maintainership

[Salah Triki]

On Tue, Jul 26, 2016 at 01:56:56PM -0400, Theodore Ts'o wrote:
> On Tue, Jul 26, 2016 at 12:16:24AM +0100, Luis de Bethencourt wrote:
> > 
> > I will wait a few days in case other people want to comment before.
> >
> 
> Sounds great!  Do you have a git tree set up for your befs development?
> 
> And if you haven't made plans to use xfstests, I would certainly
> commend that for your consideration.  Don't forget to subscribe to
> fste...@vger.kernel.org to get xfstests announcements.  Also, if
> you're interested in a framework to easily run xfstests in a GCE
> (Google Compute Engine) VM, feel free to contact me.
> 
> Cheers,
> 
>- Ted

Thanx :)

I'm also interested in the GCE VM.

best regards,
salah

Re: [PATCH v2 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

[Guenter Roeck]

On 07/26/2016 05:42 PM, Caesar Wang wrote:


On 2016年07月27日 01:00, Guenter Roeck wrote:

On Tue, Jul 26, 2016 at 10:47:16PM +0800, Caesar Wang wrote:

On 2016年07月26日 21:39, Guenter Roeck wrote:

static int rockchip_saradc_probe(struct platform_device *pdev)
{
struct rockchip_saradc *info = NULL;
@@ -218,6 +231,21 @@ static int rockchip_saradc_probe(struct
platform_device *pdev)
if (IS_ERR(info->regs))
return PTR_ERR(info->regs);

+ /*
+ * The reset should be an optional property, as it should work
+ * with old devicetrees as well
+ */
+ info->reset = devm_reset_control_get_optional(&pdev->dev,
+ "saradc-apb");

Does anyone know what the _optional API is for ? It seems to be exactly
the same
as devm_reset_control_get().

“
As far as I see, the difference is WARN_ON(1)
when CONFIG_RESET_CONTROLLER is not defined.


The _optional functions were introduced by the following commit:

->8-
commit b424080a9e086e683ad5fdc624a7cf3c024e0c0f
Author: Philipp Zabel 
Date: Fri Mar 7 15:18:47 2014 +0100

reset: Add optional resets and stubs

This patch adds device_reset_optional and (devm_)reset_control_get_optional
variants that drivers can use to indicate they can function without control
over the reset line. For those functions, stubs are added so the drivers can
be compiled with CONFIG_RESET_CONTROLLER disabled.
Also, device_reset is annotated with __must_check. Drivers
ignoring the return
value should use device_reset_optional instead.


Is that really what we are looking for here ? CONFIG_RESET_CONTROLLER
is required for other functions of rk3399, isn't it ?


Right, as the DRM and thermal are depend on the CONFIG_RESET_CONTROLLER .



Since "optional" doesn't really mean "the reset property is optional"
but "CONFIG_RESET_CONTROLLER is optional", I would suggest to use
devm_reset_control_get().

Guenter

RE: [PATCH v2] arm64: mm: convert __dma_* routines to use start, size

[kwangwoo....@sk.com]

Hi Robin,

Thanks a lot for your comments! Please, find my comments below.

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, July 26, 2016 7:43 PM
> To: 이광우(LEE KWANGWOO) MS SW; Russell King - ARM Linux; Catalin Marinas; Will 
> Deacon; Mark Rutland;
> linux-arm-ker...@lists.infradead.org
> Cc: 김현철(KIM HYUNCHUL) MS SW; linux-kernel@vger.kernel.org; 정우석(CHUNG WOO SUK) 
> MS SW
> Subject: Re: [PATCH v2] arm64: mm: convert __dma_* routines to use start, size
> 
> On 26/07/16 08:34, Kwangwoo Lee wrote:
> > v2)
> > change __dma_* routine names using the terminoloy guidance:
> > area: takes a start and size
> > range: takes a start and end
> > use __dma_flush_area() instead of __dma_flush_range() in dma-mapping.c
> >
> > v1)
> > __dma_* routines have been converted to use start and size instread of
> > start and end addresses. The patch was origianlly for adding
> > __clean_dcache_area_poc() which will be used in pmem driver to clean
> > dcache to the PoC(Point of Coherency) in arch_wb_cache_pmem().
> >
> > The functionality of __clean_dcache_area_poc()  was equivalent to
> > __dma_clean_range(). The difference was __dma_clean_range() uses the end
> > address, but __clean_dcache_area_poc() uses the size to clean.
> >
> > Thus, __clean_dcache_area_poc() has been revised with a fall through
> > function of __dma_clean_range() after the change that __dma_* routines
> > use start and size instead of using start and end.
> >
> > Signed-off-by: Kwangwoo Lee 
> > ---
> 
> Nit: the changelog relative to the previous posting wants to be here,
> under the "---" separator; the commit message above should describe the
> _current_ state of the patch, as that's all we'll really care about once
> it's in the Git history.

OK. I'll follow the convention and use the feature.
Thank you very much for letting me know!

> >  arch/arm64/include/asm/cacheflush.h |  3 +-
> >  arch/arm64/mm/cache.S   | 71 
> > +++--
> >  arch/arm64/mm/dma-mapping.c |  6 ++--
> >  3 files changed, 41 insertions(+), 39 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cacheflush.h 
> > b/arch/arm64/include/asm/cacheflush.h
> > index c64268d..2e5fb97 100644
> > --- a/arch/arm64/include/asm/cacheflush.h
> > +++ b/arch/arm64/include/asm/cacheflush.h
> > @@ -68,6 +68,7 @@
> >  extern void flush_cache_range(struct vm_area_struct *vma, unsigned long 
> > start, unsigned long end);
> >  extern void flush_icache_range(unsigned long start, unsigned long end);
> >  extern void __flush_dcache_area(void *addr, size_t len);
> > +extern void __clean_dcache_area_poc(void *addr, size_t len);
> >  extern void __clean_dcache_area_pou(void *addr, size_t len);
> >  extern long __flush_cache_user_range(unsigned long start, unsigned long 
> > end);
> >
> > @@ -85,7 +86,7 @@ static inline void flush_cache_page(struct vm_area_struct 
> > *vma,
> >   */
> >  extern void __dma_map_area(const void *, size_t, int);
> >  extern void __dma_unmap_area(const void *, size_t, int);
> > -extern void __dma_flush_range(const void *, const void *);
> > +extern void __dma_flush_area(const void *, size_t);
> >
> >  /*
> >   * Copy user data from/to a page which is mapped into a different
> > diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
> > index 50ff9ba..4415c1b 100644
> > --- a/arch/arm64/mm/cache.S
> > +++ b/arch/arm64/mm/cache.S
> > @@ -110,14 +110,16 @@ ENDPROC(__clean_dcache_area_pou)
> >   * - end - end address of region
> >   */
> >  ENTRY(__inval_cache_range)
> > +   sub x1, x1, x0
> 
> Rather than doing this, I think it would be more sensible to simply swap
> the entry points.

This is much better idea instead of adding sub instruction! :) Thanks!

> > /* FALLTHROUGH */
> >
> >  /*
> > - * __dma_inv_range(start, end)
> > + * __dma_inv_area(start, size)
> >   * - start   - virtual start address of region
> > - * - end - virtual end address of region
> > + * - size- size in question
> >   */
> > -__dma_inv_range:
> > +__dma_inv_area:
> > +   add x1, x1, x0
> > dcache_line_size x2, x3
> > sub x3, x2, #1
> > tst x1, x3  // end cache line aligned?
> > @@ -136,46 +138,47 @@ __dma_inv_range:
> > dsb sy
> > ret
> >  ENDPIPROC(__inval_cache_range)
> > -ENDPROC(__dma_inv_range)
> > +ENDPROC(__dma_inv_area)
> > +
> > +/*
> > + * __clean_dcache_area_poc(kaddr, size)
> > + *
> > + * Ensure that any D-cache lines for the interval [kaddr, 
> > kaddr+size)
> > + * are cleaned to the PoC.
> > + *
> > + * - kaddr   - kernel address
> > + * - size- size in question
> > + */
> > +ENTRY(__clean_dcache_area_poc)
> > +   /* FALLTHROUGH */
> >
> >  /*
> > - * __dma_clean_range(start, end)
> > + * __dma_clean_area(start, size)
> >   * - start   - virtual start address of region
> > - * - end - virtual end address of region
> > + * - size- size in question
> >   */
> > -__dma_cl

Re: [PATCH v2 2/4] dt-bindings: Add a binding for Mediatek MDP

[Minghsiu Tsai]

On Tue, 2016-07-26 at 13:54 -0500, Rob Herring wrote:
> On Fri, Jul 22, 2016 at 04:33:01PM +0800, Minghsiu Tsai wrote:
> > Add a DT binding documentation of MDP for the MT8173 SoC
> > from Mediatek
> > 
> > Signed-off-by: Minghsiu Tsai 
> > ---
> >  .../devicetree/bindings/media/mediatek-mdp.txt |   96 
> > 
> >  1 file changed, 96 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > new file mode 100644
> > index 000..2dad031
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -0,0 +1,96 @@
> > +* Mediatek Media Data Path
> > +
> > +Media Data Path is used for scaling and color space conversion.
> > +
> > +Required properties (all function blocks):
> > +- compatible: "mediatek,-mdp"
> 
> What is this, ...
> 

It is used to match platform driver.


> > +"mediatek,-mdp-", one of
> 
> and this?
> 

It is string format of HW block.  could be "mt8173", and
 are "rdma", "rsz", "wdma", and "wrot".  


> > +"mediatek,-mdp-rdma"  - read DMA
> > +"mediatek,-mdp-rsz"   - resizer
> > +"mediatek,-mdp-wdma"  - write DMA
> > +"mediatek,-mdp-wrot"  - write DMA with rotation
> 
> List what are valid values of .
> 

 - mt8173. There should be other chip added in future.
I will change the property as blow:

- compatible: "mediatek,-mdp"
Should be one of
"mediatek,-mdp-rdma"  - read DMA
"mediatek,-mdp-rsz"   - resizer
"mediatek,-mdp-wdma"  - write DMA
"mediatek,-mdp-wrot"  - write DMA with rotation
 - could be 8173


If don't need , I also can change it as below. It is more clear.
- compatible: "mediatek,mt8173-mdp"
Should be one of
"mediatek,mt8173-mdp-rdma"  - read DMA
"mediatek,mt8173-mdp-rsz"   - resizer
"mediatek,mt8173-mdp-wdma"  - write DMA
"mediatek,mt8173-mdp-wrot"  - write DMA with rotation


> > +- reg: Physical base address and length of the function block register 
> > space
> > +- clocks: device clocks
> > +- power-domains: a phandle to the power domain.
> > +- mediatek,vpu: the node of video processor unit
> > +
> > +Required properties (DMA function blocks):
> > +- compatible: Should be one of
> > +"mediatek,-mdp-rdma"
> > +"mediatek,-mdp-wdma"
> > +"mediatek,-mdp-wrot"
> > +- iommus: should point to the respective IOMMU block with master port as
> > +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > +  for details.
> > +- mediatek,larb: must contain the local arbiters in the current Socs.
> 
> It is still not clear which properties apply to which compatible 
> strings.
> 

I found out the document for larb. 
I will change the property as below:

- mediatek,larb: must contain the local arbiters in the current Socs,
see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt 
  for details.


> > +
> > +Example:
> > +   mdp_rdma0: rdma@14001000 {
> > +   compatible = "mediatek,mt8173-mdp-rdma",
> > +"mediatek,mt8173-mdp";
> > +   reg = <0 0x14001000 0 0x1000>;
> > +   clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > +<&mmsys CLK_MM_MUTEX_32K>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > +   iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> > +   mediatek,larb = <&larb0>;
> > +   mediatek,vpu = <&vpu>;
> > +   };
> > +
> > +   mdp_rdma1: rdma@14002000 {
> > +   compatible = "mediatek,mt8173-mdp-rdma";
> > +   reg = <0 0x14002000 0 0x1000>;
> > +   clocks = <&mmsys CLK_MM_MDP_RDMA1>,
> > +<&mmsys CLK_MM_MUTEX_32K>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > +   iommus = <&iommu M4U_PORT_MDP_RDMA1>;
> > +   mediatek,larb = <&larb4>;
> > +   };
> > +
> > +   mdp_rsz0: rsz@14003000 {
> > +   compatible = "mediatek,mt8173-mdp-rsz";
> > +   reg = <0 0x14003000 0 0x1000>;
> > +   clocks = <&mmsys CLK_MM_MDP_RSZ0>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > +   };
> > +
> > +   mdp_rsz1: rsz@14004000 {
> > +   compatible = "mediatek,mt8173-mdp-rsz";
> > +   reg = <0 0x14004000 0 0x1000>;
> > +   clocks = <&mmsys CLK_MM_MDP_RSZ1>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > +   };
> > +
> > +   mdp_rsz2: rsz@14005000 {
> > +   compatible = "mediatek,mt8173-mdp-rsz";
> > +   reg = <0 0x14005000 0 0x1000>;
> > +   clocks = <&mmsys CLK_MM_MDP_RSZ2>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > +   };
> > +
> > +   mdp_wdma0: wdma@14006000 {
> > +   compatible = "mediatek,mt8173-mdp-wdma";
> > +   reg = <0 0x14006000 0 0x1000>;
> 

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Guenter Roeck]

Hi Chris,

On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

[ ... ]

>>
>> > +
>> > +/* Properties of EXTCON_TYPE_DISP. */
>> > +#define EXTCON_PROP_DISP_MIN   150
>> > +#define EXTCON_PROP_DISP_MAX   150
>> > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>> EXTCON_PROP_DISP_MIN)
>>
>>  + 1
>>
>>
>> ok.
>
>
> Tested with these "+1", it works for my DP patch.
>

You should be able to use
https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
you didn't do that already).

Thanks,
Guenter

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

[hejianet]

Hi Dave

On 7/26/16 11:58 PM, Dave Hansen wrote:

On 07/26/2016 08:44 AM, Jia He wrote:

This patch is to fix such soft lockup. I thouhgt it is safe to call
cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page
are out of spin_lock/unlock section.

Yikes.  So the call site for both the things you patch is this:


 while (count > persistent_huge_pages(h)) {

...

 spin_unlock(&hugetlb_lock);
 if (hstate_is_gigantic(h))
 ret = alloc_fresh_gigantic_page(h, nodes_allowed);
 else
 ret = alloc_fresh_huge_page(h, nodes_allowed);
 spin_lock(&hugetlb_lock);

and you choose to patch both of the alloc_*() functions.  Why not just
fix it at the common call site?  Seems like that
spin_lock(&hugetlb_lock) could be a cond_resched_lock() which would fix
both cases.

I agree to move the cond_resched() to a common site in set_max_huge_pages().
But do you mean the spin_lock in this while loop can be replaced by
cond_resched_lock?
IIUC, cond_resched_lock = spin_unlock+cond_resched+spin_lock.
So could you please explain more details about it? Thanks.

B.R.
Justin

Also, putting that cond_resched() inside the for_each_node*() loop is an
odd choice.  It seems to indicate that the loops can take a long time,
which really isn't the case.  The _loop_ isn't long, right?

[PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

[Liang Li]

The implementation of the current virtio-balloon is not very
efficient, the time spends on different stages of inflating
the balloon to 7GB of a 8GB idle guest:

a. allocating pages (6.5%)
b. sending PFNs to host (68.3%)
c. address translation (6.1%)
d. madvise (19%)

It takes about 4126ms for the inflating process to complete.
Debugging shows that the bottle neck are the stage b and stage d.

If using a bitmap to send the page info instead of the PFNs, we
can reduce the overhead in stage b quite a lot. Furthermore, we
can do the address translation and call madvise() with a bulk of
RAM pages, instead of the current page per page way, the overhead
of stage c and stage d can also be reduced a lot.

This patch is the kernel side implementation which is intended to
speed up the inflating & deflating process by adding a new feature
to the virtio-balloon device. With this new feature, inflating the
balloon to 7GB of a 8GB idle guest only takes 590ms, the
performance improvement is about 85%.

TODO: optimize stage a by allocating/freeing a chunk of pages
instead of a single page at a time.

Signed-off-by: Liang Li 
Suggested-by: Michael S. Tsirkin 
Cc: Michael S. Tsirkin 
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 drivers/virtio/virtio_balloon.c | 184 +++-
 1 file changed, 162 insertions(+), 22 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 8d649a2..2d18ff6 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -41,10 +41,28 @@
 #define OOM_VBALLOON_DEFAULT_PAGES 256
 #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
 
+/*
+ * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
+ * to prevent a very large page bitmap, there are two reasons for this:
+ * 1) to save memory.
+ * 2) allocate a large bitmap may fail.
+ *
+ * The actual limit of pfn is determined by:
+ * pfn_limit = min(max_pfn, VIRTIO_BALLOON_PFNS_LIMIT);
+ *
+ * If system has more pages than VIRTIO_BALLOON_PFNS_LIMIT, we will scan
+ * the page list and send the PFNs with several times. To reduce the
+ * overhead of scanning the page list. VIRTIO_BALLOON_PFNS_LIMIT should
+ * be set with a value which can cover most cases.
+ */
+#define VIRTIO_BALLOON_PFNS_LIMIT ((32 * (1ULL << 30)) >> PAGE_SHIFT) /* 32GB 
*/
+
 static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
 module_param(oom_pages, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
 
+extern unsigned long get_max_pfn(void);
+
 struct virtio_balloon {
struct virtio_device *vdev;
struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
@@ -62,6 +80,15 @@ struct virtio_balloon {
 
/* Number of balloon pages we've told the Host we're not using. */
unsigned int num_pages;
+   /* Pointer of the bitmap header. */
+   void *bmap_hdr;
+   /* Bitmap and length used to tell the host the pages */
+   unsigned long *page_bitmap;
+   unsigned long bmap_len;
+   /* Pfn limit */
+   unsigned long pfn_limit;
+   /* Used to record the processed pfn range */
+   unsigned long min_pfn, max_pfn, start_pfn, end_pfn;
/*
 * The pages we've told the Host we're not using are enqueued
 * at vb_dev_info->pages list.
@@ -105,12 +132,45 @@ static void balloon_ack(struct virtqueue *vq)
wake_up(&vb->acked);
 }
 
+static inline void init_pfn_range(struct virtio_balloon *vb)
+{
+   vb->min_pfn = ULONG_MAX;
+   vb->max_pfn = 0;
+}
+
+static inline void update_pfn_range(struct virtio_balloon *vb,
+struct page *page)
+{
+   unsigned long balloon_pfn = page_to_balloon_pfn(page);
+
+   if (balloon_pfn < vb->min_pfn)
+   vb->min_pfn = balloon_pfn;
+   if (balloon_pfn > vb->max_pfn)
+   vb->max_pfn = balloon_pfn;
+}
+
 static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
 {
struct scatterlist sg;
unsigned int len;
 
-   sg_init_one(&sg, vb->pfns, sizeof(vb->pfns[0]) * vb->num_pfns);
+   if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_PAGE_BITMAP)) {
+   struct balloon_bmap_hdr *hdr = vb->bmap_hdr;
+   unsigned long bmap_len;
+
+   /* cmd and req_id are not used here, set them to 0 */
+   hdr->cmd = cpu_to_virtio16(vb->vdev, 0);
+   hdr->page_shift = cpu_to_virtio16(vb->vdev, PAGE_SHIFT);
+   hdr->reserved = cpu_to_virtio16(vb->vdev, 0);
+   hdr->req_id = cpu_to_virtio64(vb->vdev, 0);
+   hdr->start_pfn = cpu_to_virtio64(vb->vdev, vb->start_pfn);
+   bmap_len = min(vb->bmap_len,
+   (vb->end_pfn - vb->start_pfn) / BITS_PER_BYTE);
+   hdr->bmap_len = cpu_to_virtio64(vb->vdev, bmap_len);
+   sg_init_one(&sg, hdr,
+sizeof(struct bal

[PATCH v2 repost 5/7] virtio-balloon: define feature bit and head for misc virt queue

[Liang Li]

Define a new feature bit which supports a new virtual queue. This
new virtual qeuque is for information exchange between hypervisor
and guest. The VMM hypervisor can make use of this virtual queue
to request the guest do some operations, e.g. drop page cache,
synchronize file system, etc. And the VMM hypervisor can get some
of guest's runtime information through this virtual queue, e.g. the
guest's free page information, which can be used for live migration
optimization.

Signed-off-by: Liang Li 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 include/uapi/linux/virtio_balloon.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/uapi/linux/virtio_balloon.h 
b/include/uapi/linux/virtio_balloon.h
index d3b182a..be4880f 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -35,6 +35,7 @@
 #define VIRTIO_BALLOON_F_STATS_VQ  1 /* Memory Stats virtqueue */
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_PAGE_BITMAP   3 /* Send page info with bitmap */
+#define VIRTIO_BALLOON_F_MISC_VQ   4 /* Misc info virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
@@ -101,4 +102,25 @@ struct balloon_bmap_hdr {
__virtio64 bmap_len;
 };
 
+enum balloon_req_id {
+   /* Get free pages information */
+   BALLOON_GET_FREE_PAGES,
+};
+
+enum balloon_flag {
+   /* Have more data for a request */
+   BALLOON_FLAG_CONT,
+   /* No more data for a request */
+   BALLOON_FLAG_DONE,
+};
+
+struct balloon_req_hdr {
+   /* Used to distinguish different request */
+   __virtio16 cmd;
+   /* Reserved */
+   __virtio16 reserved[3];
+   /* Request parameter */
+   __virtio64 param;
+};
+
 #endif /* _LINUX_VIRTIO_BALLOON_H */
-- 
1.9.1

[PATCH v2 repost 3/7] mm: add a function to get the max pfn

[Liang Li]

Expose the function to get the max pfn, so it can be used in the
virtio-balloon device driver.

Signed-off-by: Liang Li 
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 mm/page_alloc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8b3e134..7da61ad 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4517,6 +4517,12 @@ void show_free_areas(unsigned int filter)
show_swap_cache_info();
 }
 
+unsigned long get_max_pfn(void)
+{
+   return max_pfn;
+}
+EXPORT_SYMBOL(get_max_pfn);
+
 static void zoneref_set_zone(struct zone *zone, struct zoneref *zoneref)
 {
zoneref->zone = zone;
-- 
1.9.1

[PATCH v2 repost 6/7] mm: add the related functions to get free page info

[Liang Li]

Save the free page info into a page bitmap, will be used in virtio
balloon device driver.

Signed-off-by: Liang Li 
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 mm/page_alloc.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7da61ad..3ad8b10 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void)
 }
 EXPORT_SYMBOL(get_max_pfn);
 
+static void mark_free_pages_bitmap(struct zone *zone, unsigned long start_pfn,
+   unsigned long end_pfn, unsigned long *bitmap, unsigned long len)
+{
+   unsigned long pfn, flags, page_num;
+   unsigned int order, t;
+   struct list_head *curr;
+
+   if (zone_is_empty(zone))
+   return;
+   end_pfn = min(start_pfn + len, end_pfn);
+   spin_lock_irqsave(&zone->lock, flags);
+
+   for_each_migratetype_order(order, t) {
+   list_for_each(curr, &zone->free_area[order].free_list[t]) {
+   pfn = page_to_pfn(list_entry(curr, struct page, lru));
+   if (pfn >= start_pfn && pfn <= end_pfn) {
+   page_num = 1UL << order;
+   if (pfn + page_num > end_pfn)
+   page_num = end_pfn - pfn;
+   bitmap_set(bitmap, pfn - start_pfn, page_num);
+   }
+   }
+   }
+
+   spin_unlock_irqrestore(&zone->lock, flags);
+}
+
+int get_free_pages(unsigned long start_pfn, unsigned long end_pfn,
+   unsigned long *bitmap, unsigned long len)
+{
+   struct zone *zone;
+   int ret = 0;
+
+   if (bitmap == NULL || start_pfn > end_pfn || start_pfn >= max_pfn)
+   return 0;
+   if (end_pfn < max_pfn)
+   ret = 1;
+   if (end_pfn >= max_pfn)
+   ret = 0;
+
+   for_each_populated_zone(zone)
+   mark_free_pages_bitmap(zone, start_pfn, end_pfn, bitmap, len);
+   return ret;
+}
+EXPORT_SYMBOL(get_free_pages);
+
 static void zoneref_set_zone(struct zone *zone, struct zoneref *zoneref)
 {
zoneref->zone = zone;
-- 
1.9.1

RE: [virtio-dev] Re: [PATCH v2 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

[Li, Liang Z]

> So I'm fine with this patchset, but I noticed it was not yet reviewed by MM
> people. And that is not surprising since you did not copy memory
> management mailing list on it.
> 
> I added linux...@kvack.org Cc on this mail but this might not be enough.
> 
> Please repost (e.g. [PATCH v2 repost]) copying the relevant mailing list so we
> can get some reviews.
> 

I will repost. Thanks!

Liang

[PATCH v2 repost 1/7] virtio-balloon: rework deflate to add page to a list

[Liang Li]

will allow faster notifications using a bitmap down the road.
balloon_pfn_to_page() can be removed because it's useless.

Signed-off-by: Liang Li 
Signed-off-by: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 drivers/virtio/virtio_balloon.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 476c0e3..8d649a2 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -98,12 +98,6 @@ static u32 page_to_balloon_pfn(struct page *page)
return pfn * VIRTIO_BALLOON_PAGES_PER_PAGE;
 }
 
-static struct page *balloon_pfn_to_page(u32 pfn)
-{
-   BUG_ON(pfn % VIRTIO_BALLOON_PAGES_PER_PAGE);
-   return pfn_to_page(pfn / VIRTIO_BALLOON_PAGES_PER_PAGE);
-}
-
 static void balloon_ack(struct virtqueue *vq)
 {
struct virtio_balloon *vb = vq->vdev->priv;
@@ -176,18 +170,16 @@ static unsigned fill_balloon(struct virtio_balloon *vb, 
size_t num)
return num_allocated_pages;
 }
 
-static void release_pages_balloon(struct virtio_balloon *vb)
+static void release_pages_balloon(struct virtio_balloon *vb,
+struct list_head *pages)
 {
-   unsigned int i;
-   struct page *page;
+   struct page *page, *next;
 
-   /* Find pfns pointing at start of each page, get pages and free them. */
-   for (i = 0; i < vb->num_pfns; i += VIRTIO_BALLOON_PAGES_PER_PAGE) {
-   page = balloon_pfn_to_page(virtio32_to_cpu(vb->vdev,
-  vb->pfns[i]));
+   list_for_each_entry_safe(page, next, pages, lru) {
if (!virtio_has_feature(vb->vdev,
VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
adjust_managed_page_count(page, 1);
+   list_del(&page->lru);
put_page(page); /* balloon reference */
}
 }
@@ -197,6 +189,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
unsigned num_freed_pages;
struct page *page;
struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info;
+   LIST_HEAD(pages);
 
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
@@ -208,6 +201,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
if (!page)
break;
set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+   list_add(&page->lru, &pages);
vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
}
 
@@ -219,7 +213,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
 */
if (vb->num_pfns != 0)
tell_host(vb, vb->deflate_vq);
-   release_pages_balloon(vb);
+   release_pages_balloon(vb, &pages);
mutex_unlock(&vb->balloon_lock);
return num_freed_pages;
 }
-- 
1.9.1

[PATCH v2 repost 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

[Liang Li]

This patchset is for kernel and contains two parts of change to the
virtio-balloon. 

One is the change for speeding up the inflating & deflating process,
the main idea of this optimization is to use bitmap to send the page
information to host instead of the PFNs, to reduce the overhead of
virtio data transmission, address translation and madvise(). This can
help to improve the performance by about 85%.

Another change is for speeding up live migration. By skipping process
guest's free pages in the first round of data copy, to reduce needless
data processing, this can help to save quite a lot of CPU cycles and
network bandwidth. We put guest's free page information in bitmap and
send it to host with the virt queue of virtio-balloon. For an idle 8GB
guest, this can help to shorten the total live migration time from 2Sec
to about 500ms in the 10Gbps network environment.  


Changes from v1 to v2:
* Abandon the patch for dropping page cache.
* Put some structures to uapi head file.
* Use a new way to determine the page bitmap size.
* Use a unified way to send the free page information with the bitmap 
* Address the issues referred in MST's comments

Liang Li (7):
  virtio-balloon: rework deflate to add page to a list
  virtio-balloon: define new feature bit and page bitmap head
  mm: add a function to get the max pfn
  virtio-balloon: speed up inflate/deflate process
  virtio-balloon: define feature bit and head for misc virt queue
  mm: add the related functions to get free page info
  virtio-balloon: tell host vm's free page info

 drivers/virtio/virtio_balloon.c | 306 +++-
 include/uapi/linux/virtio_balloon.h |  41 +
 mm/page_alloc.c |  52 ++
 3 files changed, 359 insertions(+), 40 deletions(-)

-- 
1.9.1

[PATCH v2 repost 2/7] virtio-balloon: define new feature bit and page bitmap head

[Liang Li]

Add a new feature which supports sending the page information with
a bitmap. The current implementation uses PFNs array, which is not
very efficient. Using bitmap can improve the performance of
inflating/deflating significantly

The page bitmap header will used to tell the host some information
about the page bitmap. e.g. the page size, page bitmap length and
start pfn.

Signed-off-by: Liang Li 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 include/uapi/linux/virtio_balloon.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/uapi/linux/virtio_balloon.h 
b/include/uapi/linux/virtio_balloon.h
index 343d7dd..d3b182a 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -34,6 +34,7 @@
 #define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell before reclaiming 
pages */
 #define VIRTIO_BALLOON_F_STATS_VQ  1 /* Memory Stats virtqueue */
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon on OOM */
+#define VIRTIO_BALLOON_F_PAGE_BITMAP   3 /* Send page info with bitmap */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
@@ -82,4 +83,22 @@ struct virtio_balloon_stat {
__virtio64 val;
 } __attribute__((packed));
 
+/* Page bitmap header structure */
+struct balloon_bmap_hdr {
+   /* Used to distinguish different request */
+   __virtio16 cmd;
+   /* Shift width of page in the bitmap */
+   __virtio16 page_shift;
+   /* flag used to identify different status */
+   __virtio16 flag;
+   /* Reserved */
+   __virtio16 reserved;
+   /* ID of the request */
+   __virtio64 req_id;
+   /* The pfn of 0 bit in the bitmap */
+   __virtio64 start_pfn;
+   /* The length of the bitmap, in bytes */
+   __virtio64 bmap_len;
+};
+
 #endif /* _LINUX_VIRTIO_BALLOON_H */
-- 
1.9.1

[PATCH v2 repost 7/7] virtio-balloon: tell host vm's free page info

[Liang Li]

Support the request for vm's free page information, response with
a page bitmap. QEMU can make use of this free page bitmap to speed
up live migration process by skipping process the free pages.

Signed-off-by: Liang Li 
Cc: Michael S. Tsirkin 
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
---
 drivers/virtio/virtio_balloon.c | 104 +---
 1 file changed, 98 insertions(+), 6 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 2d18ff6..5ca4ad3 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -62,10 +62,13 @@ module_param(oom_pages, int, S_IRUSR | S_IWUSR);
 MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
 
 extern unsigned long get_max_pfn(void);
+extern int get_free_pages(unsigned long start_pfn, unsigned long end_pfn,
+   unsigned long *bitmap, unsigned long len);
+
 
 struct virtio_balloon {
struct virtio_device *vdev;
-   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *misc_vq;
 
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
@@ -89,6 +92,8 @@ struct virtio_balloon {
unsigned long pfn_limit;
/* Used to record the processed pfn range */
unsigned long min_pfn, max_pfn, start_pfn, end_pfn;
+   /* Request header */
+   struct balloon_req_hdr req_hdr;
/*
 * The pages we've told the Host we're not using are enqueued
 * at vb_dev_info->pages list.
@@ -373,6 +378,49 @@ static void update_balloon_stats(struct virtio_balloon *vb)
pages_to_bytes(available));
 }
 
+static void update_free_pages_stats(struct virtio_balloon *vb,
+   unsigned long req_id)
+{
+   struct scatterlist sg_in, sg_out;
+   unsigned long pfn = 0, bmap_len, max_pfn;
+   struct virtqueue *vq = vb->misc_vq;
+   struct balloon_bmap_hdr *hdr = vb->bmap_hdr;
+   int ret = 1;
+
+   max_pfn = get_max_pfn();
+   mutex_lock(&vb->balloon_lock);
+   while (pfn < max_pfn) {
+   memset(vb->page_bitmap, 0, vb->bmap_len);
+   ret = get_free_pages(pfn, pfn + vb->pfn_limit,
+   vb->page_bitmap, vb->bmap_len * BITS_PER_BYTE);
+   hdr->cmd = cpu_to_virtio16(vb->vdev, BALLOON_GET_FREE_PAGES);
+   hdr->page_shift = cpu_to_virtio16(vb->vdev, PAGE_SHIFT);
+   hdr->req_id = cpu_to_virtio64(vb->vdev, req_id);
+   hdr->start_pfn = cpu_to_virtio64(vb->vdev, pfn);
+   bmap_len = vb->pfn_limit / BITS_PER_BYTE;
+   if (!ret) {
+   hdr->flag = cpu_to_virtio16(vb->vdev,
+   BALLOON_FLAG_DONE);
+   if (pfn + vb->pfn_limit > max_pfn)
+   bmap_len = (max_pfn - pfn) / BITS_PER_BYTE;
+   } else
+   hdr->flag = cpu_to_virtio16(vb->vdev,
+   BALLOON_FLAG_CONT);
+   hdr->bmap_len = cpu_to_virtio64(vb->vdev, bmap_len);
+   sg_init_one(&sg_out, hdr,
+sizeof(struct balloon_bmap_hdr) + bmap_len);
+
+   virtqueue_add_outbuf(vq, &sg_out, 1, vb, GFP_KERNEL);
+   virtqueue_kick(vq);
+   pfn += vb->pfn_limit;
+   }
+
+   sg_init_one(&sg_in, &vb->req_hdr, sizeof(vb->req_hdr));
+   virtqueue_add_inbuf(vq, &sg_in, 1, &vb->req_hdr, GFP_KERNEL);
+   virtqueue_kick(vq);
+   mutex_unlock(&vb->balloon_lock);
+}
+
 /*
  * While most virtqueues communicate guest-initiated requests to the 
hypervisor,
  * the stats queue operates in reverse.  The driver initializes the virtqueue
@@ -511,18 +559,49 @@ static void update_balloon_size_func(struct work_struct 
*work)
queue_work(system_freezable_wq, work);
 }
 
+static void misc_handle_rq(struct virtio_balloon *vb)
+{
+   struct balloon_req_hdr *ptr_hdr;
+   unsigned int len;
+
+   ptr_hdr = virtqueue_get_buf(vb->misc_vq, &len);
+   if (!ptr_hdr || len != sizeof(vb->req_hdr))
+   return;
+
+   switch (ptr_hdr->cmd) {
+   case BALLOON_GET_FREE_PAGES:
+   update_free_pages_stats(vb, ptr_hdr->param);
+   break;
+   default:
+   break;
+   }
+}
+
+static void misc_request(struct virtqueue *vq)
+{
+   struct virtio_balloon *vb = vq->vdev->priv;
+
+   misc_handle_rq(vb);
+}
+
 static int init_vqs(struct virtio_balloon *vb)
 {
-   struct virtqueue *vqs[3];
-   vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
};
-   static const char * const names[] = { "inflate", "deflate", "stats" };
+   struct virtqueue *vq

Re: [PATCH v3 6/7] Mark a few functions with the printf attribute

[kbuild test robot]

Hi,

[auto build test WARNING on next-20160726]
[cannot apply to stable/master linus/master linux/master v4.7-rc7 v4.7-rc6 
v4.7-rc5 v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Emese-Revfy/Introduce-the-initify-gcc-plugin/20160727-084514
config: x86_64-randconfig-s3-07270832 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/acpi/acpica/utdebug.c: In function 'acpi_debug_print':
>> drivers/acpi/acpica/utdebug.c:192:26: warning: format '%ld' expects argument 
>> of type 'long int', but argument 3 has type 'u32 {aka unsigned int}' 
>> [-Wformat=]
 acpi_os_printf("%9s-%04ld ", module_name, line_number);
 ^
--
   drivers/acpi/acpica/dbhistry.c: In function 'acpi_db_display_history':
>> drivers/acpi/acpica/dbhistry.c:158:23: warning: format '%ld' expects 
>> argument of type 'long int', but argument 2 has type 'u32 {aka unsigned 
>> int}' [-Wformat=]
   acpi_os_printf("%3ld %s\n",
  ^
--
   drivers/acpi/acpica/dbinput.c: In function 'acpi_db_get_line':
>> drivers/acpi/acpica/dbinput.c:609:56: warning: format '%u' expects argument 
>> of type 'unsigned int', but argument 2 has type 'long unsigned int' 
>> [-Wformat=]
  ("Buffer overflow while parsing input line (max %u characters)\n",
   ^
   drivers/acpi/acpica/dbinput.c: In function 'acpi_db_command_dispatch':
>> drivers/acpi/acpica/dbinput.c:865:58: warning: format '%lX' expects argument 
>> of type 'long unsigned int', but argument 2 has type 'u32 {aka unsigned 
>> int}' [-Wformat=]
   ("Current debug level for file output is:%8.8lX\n",
 ^
   drivers/acpi/acpica/dbinput.c:868:58: warning: format '%lX' expects argument 
of type 'long unsigned int', but argument 2 has type 'u32 {aka unsigned int}' 
[-Wformat=]
   ("Current debug level for console output is: %8.8lX\n",
 ^
   drivers/acpi/acpica/dbinput.c:875:50: warning: format '%lX' expects argument 
of type 'long unsigned int', but argument 2 has type 'u32 {aka unsigned int}' 
[-Wformat=]
   ("Debug Level for console output was %8.8lX, now %8.8lX\n",
 ^
   drivers/acpi/acpica/dbinput.c:875:62: warning: format '%lX' expects argument 
of type 'long unsigned int', but argument 3 has type 'u32 {aka unsigned int}' 
[-Wformat=]
   ("Debug Level for console output was %8.8lX, now %8.8lX\n",
 ^
   drivers/acpi/acpica/dbinput.c:882:47: warning: format '%lX' expects argument 
of type 'long unsigned int', but argument 2 has type 'u32 {aka unsigned int}' 
[-Wformat=]
   ("Debug Level for file output was %8.8lX, now %8.8lX\n",
  ^
   drivers/acpi/acpica/dbinput.c:882:59: warning: format '%lX' expects argument 
of type 'long unsigned int', but argument 3 has type 'u32 {aka unsigned int}' 
[-Wformat=]
   ("Debug Level for file output was %8.8lX, now %8.8lX\n",
  ^
--
   drivers/acpi/acpica/dbstats.c: In function 'acpi_db_display_statistics':
>> drivers/acpi/acpica/dbstats.c:380:33: warning: format '%ld' expects argument 
>> of type 'long int', but argument 3 has type 'int' [-Wformat=]
   acpi_os_printf("%16.16s % 10ld% 10ld\n",
^
   drivers/acpi/acpica/dbstats.c:380:39: warning: format '%ld' expects argument 
of type 'long int', but argument 4 has type 'int' [-Wformat=]
   acpi_os_printf("%16.16s % 10ld% 10ld\n",
  ^
   drivers/acpi/acpica/dbstats.c:386:32: warning: format '%ld' expects argument 
of type 'long int', but argument 3 has type 'int' [-Wformat=]
  acpi_os_printf("%16.16s % 10ld% 10ld\n", "Misc/Unknown",
   ^
   drivers/acpi/acpica/dbstats.c:386:38: warning: format '%ld' expects 

Re: [PATCH v3 6/7] Mark a few functions with the printf attribute

[kbuild test robot]

Hi,

[auto build test WARNING on next-20160726]
[cannot apply to stable/master linus/master linux/master v4.7-rc7 v4.7-rc6 
v4.7-rc5 v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Emese-Revfy/Introduce-the-initify-gcc-plugin/20160727-084514
config: x86_64-randconfig-s0-07270838 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/scsi/esas2r/esas2r_init.c: In function 'esas2r_claim_interrupts':
>> drivers/scsi/esas2r/esas2r_init.c:241: warning: format '%x' expects type 
>> 'unsigned int', but argument 6 has type 'long unsigned int'
--
   drivers/scsi/esas2r/esas2r_ioctl.c: In function 'esas2r_ioctl_handler':
>> drivers/scsi/esas2r/esas2r_ioctl.c:1305: warning: format '%d' expects type 
>> 'int', but argument 3 has type 'long unsigned int'
--
   drivers/scsi/esas2r/esas2r_main.c: In function 'write_hw':
>> drivers/scsi/esas2r/esas2r_main.c:202: warning: format '%d' expects type 
>> 'int', but argument 3 has type 'long unsigned int'
   drivers/scsi/esas2r/esas2r_main.c: In function 'esas2r_dev_targ_reset':
>> drivers/scsi/esas2r/esas2r_main.c:1191: warning: format '%d' expects type 
>> 'int', but argument 4 has type 'u64'

vim +241 drivers/scsi/esas2r/esas2r_init.c

26780d9e Bradley Grove  2013-08-23  225"unknown 
interrupt_mode %d requested, "
26780d9e Bradley Grove  2013-08-23  226"falling 
back to legacy interrupt",
26780d9e Bradley Grove  2013-08-23  227
interrupt_mode);
26780d9e Bradley Grove  2013-08-23  228 goto 
use_legacy_interrupts;
26780d9e Bradley Grove  2013-08-23  229 }
26780d9e Bradley Grove  2013-08-23  230  }
26780d9e Bradley Grove  2013-08-23  231  
26780d9e Bradley Grove  2013-08-23  232  static void 
esas2r_claim_interrupts(struct esas2r_adapter *a)
26780d9e Bradley Grove  2013-08-23  233  {
4909cc2b Michael Opdenacker 2014-03-05  234 unsigned long flags = 0;
26780d9e Bradley Grove  2013-08-23  235  
26780d9e Bradley Grove  2013-08-23  236 if (a->intr_mode == 
INTR_MODE_LEGACY)
26780d9e Bradley Grove  2013-08-23  237 flags |= IRQF_SHARED;
26780d9e Bradley Grove  2013-08-23  238  
26780d9e Bradley Grove  2013-08-23  239 esas2r_log(ESAS2R_LOG_INFO,
26780d9e Bradley Grove  2013-08-23  240
"esas2r_claim_interrupts irq=%d (%p, %s, %x)",
26780d9e Bradley Grove  2013-08-23 @241a->pcid->irq, a, 
a->name, flags);
26780d9e Bradley Grove  2013-08-23  242  
26780d9e Bradley Grove  2013-08-23  243 if (request_irq(a->pcid->irq,
26780d9e Bradley Grove  2013-08-23  244 (a->intr_mode ==
26780d9e Bradley Grove  2013-08-23  245  
INTR_MODE_LEGACY) ? esas2r_interrupt :
26780d9e Bradley Grove  2013-08-23  246 
esas2r_msi_interrupt,
26780d9e Bradley Grove  2013-08-23  247 flags,
26780d9e Bradley Grove  2013-08-23  248 a->name,
26780d9e Bradley Grove  2013-08-23  249 a)) {

:: The code at line 241 was first introduced by commit
:: 26780d9e12edf45c0b98315de272b1feff5a8e93 [SCSI] esas2r: ATTO Technology 
ExpressSAS 6G SAS/SATA RAID Adapter Driver

:: TO: Bradley Grove 
:: CC: James Bottomley 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] qed: Add and use specific logging functions to reduce object size

[Joe Perches]

On Tue, 2016-07-26 at 14:25 -0700, Joe Perches wrote:
> Current DP_ macros generate a lot of code.
> Using functions with vsprintf extension %pV helps reduce that size.

Yuval, I used the same KERN_ output types, but it
is unusual that DP_INFO outputs at KERN_NOTICE.

Was that a copy/paste defect or should it be emitted at
KERN_INFO and DP_VERBOSE be emitted at KERN_DEBUG?

> define DP_INFO(cdev, fmt, ...)  \
> - do {  \
> - if (unlikely((cdev)->dp_level <= QED_LEVEL_INFO)) {   \
> - pr_notice("[%s:%d(%s)]" fmt,  \
> -   __func__, __LINE__,     \
> -   DP_NAME(cdev) ? DP_NAME(cdev) : "", \
> -   ## __VA_ARGS__);    \
> - }     \
> - } while (0)
[]
> -#define DP_VERBOSE(cdev, module, fmt, ...)   \
> - do {\
> - if (unlikely(((cdev)->dp_level <= QED_LEVEL_VERBOSE) && \
> -  ((cdev)->dp_module & module))) {   \
> - pr_notice("[%s:%d(%s)]" fmt,\
> -   __func__, __LINE__,   \
> -   DP_NAME(cdev) ? DP_NAME(cdev) : "",   \
> -   ## __VA_ARGS__);  \
> - }   \
> - } while (0)

debug tip after earlycon is closed?

[Masahiro Yamada]

Hi.


When the kernel fails to boot and its log console is silent,
I use earlycon and I often find the cause of error with it.


But, I have been wondering if there is an easy-to-use
debug tip which is available after earlycon is disabled.


I noticed the current mainline would not boot on my ARMv8 board.
According to the following log, I am guessing something wrong
is happening after the "bootconsole [uniphier0] disabled" log.

Is there a good practice to see more log?





[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.7.0-02346-g3601fbc-dirty
(yamada@beagle) (gcc version 4.9.4 20151028 (prerelease) (Linaro GCC
4.9-2016.02) ) #19 SMP PREEMPT Wed Jul 27 10:01:35 JST 2016
[0.00] Boot CPU: AArch64 Processor [410fd034]
[0.00] earlycon: uniphier0 at MMIO 0x54006800 (options
'115200n8')
[0.00] bootconsole [uniphier0] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 16 MiB at 0xbec0
[0.00] percpu: Embedded 21 pages/cpu @80003ffb3000 s48128
r8192 d29696 u86016
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: enabling workaround for ARM erratum 845719
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 258048
[0.00] Kernel command line: earlycon
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[0.00] software IO TLB [mem 0xb9c0-0xbdc0] (64MB)
mapped at [800039c0-80003dbf]
[0.00] Memory: 933680K/1048576K available (7512K kernel code,
648K rwdata, 3172K rodata, 960K init, 259K bss, 98512K reserved,
16384K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] modules : 0x - 0x0800
(   128 MB)
[0.00] vmalloc : 0x0800 - 0x7dffbfff
(129022 GB)
[0.00]   .text : 0x0808 - 0x087d
(  7488 KB)
[0.00] .rodata : 0x087d - 0x08af
(  3200 KB)
[0.00]   .init : 0x08af - 0x08be
(   960 KB)
[0.00]   .data : 0x08be - 0x08c82000
(   648 KB)
[0.00].bss : 0x08c82000 - 0x08cc2d40
(   260 KB)
[0.00] fixed   : 0x7dfffe7fd000 - 0x7dfffec0
(  4108 KB)
[0.00] PCI I/O : 0x7dfffee0 - 0x7de0
(16 MB)
[0.00] vmemmap : 0x7e00 - 0x8000
(  2048 GB maximum)
[0.00]   0x7e00 - 0x7e000100
(16 MB actual)
[0.00] memory  : 0x8000 - 0x80004000
(  1024 MB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 64.
[0.00]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=2
[0.00] NR_IRQS:64 nr_irqs:64 0
[0.00] GICv3: GIC: Using split EOI/Deactivate mode
[0.00] GICv3: CPU0: found redistributor 0 region 0:0x5fe4
[0.00] Architected cp15 timer(s) running at 50.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff
max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
[0.04] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps
every 4398046511100ns
[0.008254] Console: colour dummy device 80x25
[0.012700] console [tty0] enabled
[0.016110] bootconsole [uniphier0] disabled


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent

[Dou Liyang]

Hi, RJ

在 2016年07月26日 19:53, Rafael J. Wysocki 写道:

On Tuesday, July 26, 2016 11:59:38 AM Dou Liyang wrote:


在 2016年07月26日 07:20, Andrew Morton 写道:

On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang  wrote:


[Problem]

cpuid <-> nodeid mapping is firstly established at boot time. And workqueue 
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.

When doing node online/offline, cpuid <-> nodeid mapping is 
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.

So here is the problem:

Assume we have the following cpuid <-> nodeid in the beginning:

  Node | CPU

node 0 |  0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119

and we hot-remove node2 and node3, it becomes:

  Node | CPU

node 0 |  0-14, 60-74
node 1 | 15-29, 75-89

and we hot-add node4 and node5, it becomes:

  Node | CPU

node 0 |  0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119

But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.

When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.


Plan B is to hunt down and fix up all the workqueue structures at
hotplug-time.  Has that option been evaluated?



Yes, the option has been evaluate in this patch:
http://www.gossamer-threads.com/lists/linux/kernel/2116748



Your fix is x86-only and this bug presumably affects other
architectures, yes?I think a "Plan B" would fix all architectures?



Yes, the bug may presumably affect few architectures which support CPU
hotplug and NUMA.

We have sent the "Plan B" in our community and got a lot of advice and
ideas. Based on these suggestions, We carefully balance that two plan.
Then we choice the first.



Thirdly, what is the merge path for these patches?  Is an x86
or ACPI maintainer working with you on them?


Yes, we get a lot of guidance and help from RJ who is an ACPI maintainer.


FWIW, the patches are fine by me from the ACPI perspective.

If you want me to apply them, though, ACKs from the x86 and mm maintainers
will be necessary.



I will continue to investigate this bug and wait for maintainers's  advices.


Thanks,
Rafael





Thanks.
Dou

Re: [PATCH v3 2/7] Split up struct warn_args

[kbuild test robot]

Hi,

[auto build test ERROR on next-20160726]
[also build test ERROR on v4.7]
[cannot apply to stable/master linus/master linux/master v4.7-rc7 v4.7-rc6 
v4.7-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Emese-Revfy/Introduce-the-initify-gcc-plugin/20160727-084514
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   kernel/panic.c: In function 'warn_slowpath_null':
>> kernel/panic.c:544:2: error: incompatible type for argument 7 of '__warn'
   kernel/panic.c:478:6: note: expected 'va_list' but argument is of type 'void 
*'

vim +/__warn +544 kernel/panic.c

   538  va_end(args);
   539  }
   540  EXPORT_SYMBOL(warn_slowpath_fmt_taint);
   541  
   542  void warn_slowpath_null(const char *file, int line)
   543  {
 > 544  __warn(file, line, __builtin_return_address(0), TAINT_WARN, 
 > NULL, NULL, NULL);
   545  }
   546  EXPORT_SYMBOL(warn_slowpath_null);
   547  #endif

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chris Zhong]

Hi Chanwoo

On 07/27/2016 08:31 AM, Chanwoo Choi wrote:

Hi Guenter,

2016년 7월 27일 수요일, Guenter Roeck>님이 작성한 메시지:


On Tue, Jul 26, 2016 at 5:09 AM, Chanwoo Choi
> wrote:
> This patch support the extcon property for the external connector
> because each external connector might have the property according to
> the H/W design and the specific characteristics.
>
> - EXTCON_PROP_USB_[property name]
> - EXTCON_PROP_CHG_[property name]
> - EXTCON_PROP_JACK_[property name]
> - EXTCON_PROP_DISP_[property name]
>
> Add the new extcon APIs to get/set the property value as following:
> - int extcon_get_property(struct extcon_dev *edev, unsigned int id,
> unsigned int prop,
> union extcon_property_value *prop_val)
> - int extcon_set_property(struct extcon_dev *edev, unsigned int id,
> unsigned int prop,
> union extcon_property_value prop_val)
>
> Signed-off-by: Chanwoo Choi >
> ---
>  drivers/extcon/extcon.c | 206
+++-
>  include/linux/extcon.h  |  86 
>  2 files changed, 291 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index b1e6ee6194bc..2317aaea063f 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -196,6 +196,11 @@ struct extcon_cable {
> struct device_attribute attr_state;
>
> struct attribute *attrs[3]; /* to be fed to attr_g.attrs */
> +
> +   union extcon_property_value
usb_propval[EXTCON_PROP_USB_CNT];
> +   union extcon_property_value
chg_propval[EXTCON_PROP_CHG_CNT];
> +   union extcon_property_value
jack_propval[EXTCON_PROP_JACK_CNT];
> +   union extcon_property_value
disp_propval[EXTCON_PROP_DISP_CNT];
>  };
>
>  static struct class *extcon_class;
> @@ -248,6 +253,28 @@ static int find_cable_index_by_id(struct
extcon_dev *edev, const unsigned int id
> return -EINVAL;
>  }
>
> +static int get_extcon_type(unsigned int prop)
> +{
> +   switch (prop) {
> +   case EXTCON_PROP_USB_MIN ... EXTCON_PROP_USB_MAX:
> +   return EXTCON_TYPE_USB;
> +   case EXTCON_PROP_CHG_MIN ... EXTCON_PROP_CHG_MAX:
> +   return EXTCON_TYPE_CHG;
> +   case EXTCON_PROP_JACK_MIN ... EXTCON_PROP_JACK_MAX:
> +   return EXTCON_TYPE_JACK;
> +   case EXTCON_PROP_DISP_MIN ... EXTCON_PROP_DISP_MAX:
> +   return EXTCON_TYPE_DISP;
> +   default:
> +   return -EINVAL;
> +   }
> +}
> +
> +static bool is_extcon_attached(struct extcon_dev *edev,
unsigned int id,
> +   unsigned int index)
> +{
> +   return ((!!(edev->state & (1 << index))) == 1) ? true :
false;
> +}
> +
>  static bool is_extcon_changed(u32 prev, u32 new, int idx, bool
*attached)
>  {
> if (((prev >> idx) & 0x1) != ((new >> idx) & 0x1)) {
> @@ -258,6 +285,41 @@ static bool is_extcon_changed(u32 prev, u32
new, int idx, bool *attached)
> return false;
>  }
>
> +static bool is_extcon_property_supported(unsigned int id,
unsigned int prop)
> +{
> +   unsigned int type;
> +

int


ok.


> +   /* Check whether the property is supported or not. */
> +   type = get_extcon_type(prop);
> +   if (type < 0)

otherwise type is never < 0


you're right.


> +   return false;
> +
> +   /* Check whether a specific extcon id supports the
property or not. */
> +   if (extcon_info[id].type | type)

This is always true ?


It is my mistake. Use '&' instead of '|'.


> +   return true;
> +
> +   return false;
> +}
> +
> +#define INIT_PROPERTY(name, name_lower, type) \
> +   if (EXTCON_TYPE_##name || type) {  \

This is always true ?


It is my mistake. Use '&' instead of '||'.


> +   for (i = 0; i < EXTCON_PROP_##name##_CNT; i++) 
\
> +   cable->name_lower##_propval[i] = val;   
   \

> +   }  \
> +
> +static void init_property(struct extcon_dev *edev, unsigned int
id, int index)
> +{
> +   unsigned int type = extcon_info[id].type;
> +   struct extcon_cable *cable = &edev->cables[index];
> +   union extcon_property_value val = (union
extcon_property_value)(0);
> +   int i;
> +
> +   INIT_PROPERTY(USB, usb, type);
> +   INIT_PROPERTY(CHG, chg, type);
> +   INIT_PROPERTY(JACK, jack, type);
> +   INIT_PROP

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Christian Lamparter wrote:
> Thanks, I gave the program a try with my WNDA3100 and a WN821N v2 devices.
> I did not see any corruptions in any of the tests though. Can you tell me
> something about your wireless network too? I would like to know what router
> and firmware are you using? Also important: what's your wireless 
> configuration?

The router/access-point is a Comcast-issued Technicolor cable modem, model
TC8305C. The only thing I can find on it that looks like it might identify
a firmware version is this:

System Software Version

eMTA & DOCSIS Software Version: 01.E6.01.22.25
Packet Cable: 2.0

I assume Comcast pushes firmware updates whenever they feel like it.

There is possibly another clue. I get this message from the kernel sometimes:

ieee80211 phy0: invalid plcp cck rate (0).

I had this message appearing long before the data corruption bug started.
It never correlated with any actual problems, so I turned down the priority
level of the message to get it off the console, and forgot about it. I
was unable to discover what a "plcp" or "cck" is so the message means
nothing to me.

> (WPA?, CCMP or TKIP? HT40, HT20 or Legacy rates? ...)
> 
> Probably the quickest and easiest way to get that information is by running
> the following commands as root, when you are connected to your wifi network
> and post the results:
> # iw dev wlan0 link
> # iw dev wlan0 scan dump

Connected to cc:03:fa:bf:e9:ea (on wlan0)
SSID: HOME-E9EA
freq: 2462
RX: 20726719 bytes (106483 packets)
TX: 5902478 bytes (44707 packets)
signal: -43 dBm
tx bitrate: 54.0 MBit/s

bss flags:  short-slot-time
dtim period:1
beacon int: 100

BSS cc:03:fa:bf:e9:ea(on wlan0) -- associated
TSF: 236407205748 usec (2d, 17:40:07)
freq: 2462
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -33.00 dBm
last seen: 634452 ms ago
Information elements from Probe Response frame:
SSID: HOME-E9EA
Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0* 36.0 54.0 
DS Parameter set: channel 11
ERP: 
ERP D4.0: 
RSN: * Version: 1
 * Group cipher: TKIP
 * Pairwise ciphers: CCMP TKIP
 * Authentication suites: PSK
 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
Extended supported rates: 6.0* 9.0 12.0* 48.0 
HT capabilities:
Capabilities: 0x18bd
RX LDPC
HT20
SM Power Save disabled
RX Greenfield
RX HT20 SGI
TX STBC
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-23
HT TX MCS rate indexes are undefined
HT operation:
 * primary channel: 11
 * secondary channel offset: no secondary
 * STA channel width: 20 MHz
 * RIFS: 1
 * HT protection: nonmember
 * non-GF present: 1
 * OBSS non-GF present: 1
 * dual beacon: 0
 * dual CTS protection: 0
 * STBC beacon: 0
 * L-SIG TXOP Prot: 0
 * PCO active: 0
 * PCO phase: 0
WPS: * Version: 1.0
 * Wi-Fi Protected Setup State: 2 (Configured)
 * Response Type: 3 (AP)
 * UUID: 6d1b1911-14a9-391c-cdee-89850a5aa1ef
 * Manufacturer: Technicolor
 * Model: Technicolor
 * Model Number: 123456
 * Serial Number: 001
 * Primary Device Type: 6-0050f204-1
 * Device name: TechnicolorAP
 * Config methods: Display
 * RF Bands: 0x1
 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20
WPA: * Version: 1
 * Group cipher: TKIP
 * Pairwise ciphers: CCMP TKIP
 * Authentication suites: PSK
 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
WMM: * Parameter version 1
 * u-APSD
 * BE: CW 15-1023, AIFSN 3
 * BK: CW 15-1023, AIFSN 7
 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

-- 
Alan Curry

Re: [PATCH v3 6/7] Mark a few functions with the printf attribute

[kbuild test robot]

Hi,

[auto build test WARNING on next-20160726]
[cannot apply to stable/master linus/master linux/master v4.7-rc7 v4.7-rc6 
v4.7-rc5 v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Emese-Revfy/Introduce-the-initify-gcc-plugin/20160727-084514
config: x86_64-randconfig-s1-07270838 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/acpi/acpica/utdebug.c: In function 'acpi_debug_print':
>> drivers/acpi/acpica/utdebug.c:192: warning: format '%04ld' expects type 
>> 'long int', but argument 3 has type 'u32'
--
   drivers/acpi/acpica/dbhistry.c: In function 'acpi_db_display_history':
>> drivers/acpi/acpica/dbhistry.c:162: warning: format '%3ld' expects type 
>> 'long int', but argument 2 has type 'u32'
--
   drivers/acpi/acpica/dbinput.c: In function 'acpi_db_get_line':
>> drivers/acpi/acpica/dbinput.c:610: warning: format '%u' expects type 
>> 'unsigned int', but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbinput.c: In function 'acpi_db_command_dispatch':
>> drivers/acpi/acpica/dbinput.c:866: warning: format '%8.8lX' expects type 
>> 'long unsigned int', but argument 2 has type 'u32'
   drivers/acpi/acpica/dbinput.c:869: warning: format '%8.8lX' expects type 
'long unsigned int', but argument 2 has type 'u32'
   drivers/acpi/acpica/dbinput.c:876: warning: format '%8.8lX' expects type 
'long unsigned int', but argument 2 has type 'u32'
   drivers/acpi/acpica/dbinput.c:876: warning: format '%8.8lX' expects type 
'long unsigned int', but argument 3 has type 'u32'
   drivers/acpi/acpica/dbinput.c:883: warning: format '%8.8lX' expects type 
'long unsigned int', but argument 2 has type 'u32'
   drivers/acpi/acpica/dbinput.c:883: warning: format '%8.8lX' expects type 
'long unsigned int', but argument 3 has type 'u32'
--
   drivers/acpi/acpica/dbstats.c: In function 'acpi_db_display_statistics':
>> drivers/acpi/acpica/dbstats.c:383: warning: format '% 10ld' expects type 
>> 'long int', but argument 3 has type 'int'
   drivers/acpi/acpica/dbstats.c:383: warning: format '% 10ld' expects type 
'long int', but argument 4 has type 'int'
   drivers/acpi/acpica/dbstats.c:388: warning: format '% 10ld' expects type 
'long int', but argument 3 has type 'int'
   drivers/acpi/acpica/dbstats.c:388: warning: format '% 10ld' expects type 
'long int', but argument 4 has type 'int'
>> drivers/acpi/acpica/dbstats.c:391: warning: format '% 10ld' expects type 
>> 'long int', but argument 3 has type 'u32'
   drivers/acpi/acpica/dbstats.c:391: warning: format '% 10ld' expects type 
'long int', but argument 4 has type 'u32'
>> drivers/acpi/acpica/dbstats.c:419: warning: format '% 7ld' expects type 
>> 'long int', but argument 2 has type 'u32'
   drivers/acpi/acpica/dbstats.c:421: warning: format '% 7ld' expects type 
'long int', but argument 2 has type 'u32'
   drivers/acpi/acpica/dbstats.c:429: warning: format '% 7ld' expects type 
'long int', but argument 3 has type 'u32'
>> drivers/acpi/acpica/dbstats.c:438: warning: format '%3d' expects type 'int', 
>> but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:440: warning: format '%3d' expects type 'int', 
but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:442: warning: format '%3d' expects type 'int', 
but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:444: warning: format '%3d' expects type 'int', 
but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:446: warning: format '%3d' expects type 'int', 
but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:448: warning: format '%3d' expects type 'int', 
but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:450: warning: format '%3d' expects type 'int', 
but argument 2 has type 'long unsigned int'
   drivers/acpi/acpica/dbstats.c:452: wa

Re: [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()

[Kuninori Morimoto]

Hi Rob, Michael, Russell
Cc Rob

What is the conclusion of this patch ?
We shouldn't add devm_of_clk_get() ? or I can continue ?

> Thank you for your feedback
> 
> > > struct clk *clk_get(struct device *dev, const char *con_id)
> > > {
> > > ...
> > > if (dev) {
> > > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);
> > >
> > > ...
> > > }
> > > }
> > > 
> > > I would like to select specific device_node.
> > 
> > Do you have access to the struct device that you want to target? Can you
> > pass that device into either clk_get or devm_clk_get?
> 
> If my understanding was correct, I think I can't.
> In below case, "sound_soc" has its *dev, but "cpu" and "codec" doesn't
> have *dev, it has node only. Thus, we are using of_clk_get() for these now.
> 
>   clk = of_clk_get(cpu, xxx);
>   clk = of_clk_get(codec, xxx);
> 
>   sound_soc {
>   ...
>   cpu {
>   ...
> =>clocks = <&xxx>;
>   };
>   codec {
>   ...
> =>clocks = <&xxx>;
>   };
>   };
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel