RE: [EXT] Re: [next, v2] dmaengine: fsl-dpaa2-qdma: export the symbols

2019-10-22 Thread Peng Ma


>-Original Message-
>From: Vinod Koul 
>Sent: 2019年10月23日 13:09
>To: Peng Ma 
>Cc: dan.j.willi...@intel.com; Leo Li ;
>anders.rox...@linaro.org; linux-kernel@vger.kernel.org;
>dmaeng...@vger.kernel.org
>Subject: [EXT] Re: [next, v2] dmaengine: fsl-dpaa2-qdma: export the symbols
>
>Caution: EXT Email
>
>On 23-10-19, 12:56, Peng Ma wrote:
>> The symbols were not exported leading to error:
>>
>> WARNING: modpost: missing MODULE_LICENSE() in
>drivers/dma/fsl-dpaa2-qdma/dpdmai.o
>> see include/linux/module.h for more information
>> GZIParch/arm64/boot/Image.gz
>> ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>undefined!
>> ERROR: "dpdmai_set_rx_queue"
>[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> ERROR: "dpdmai_get_tx_queue"
>[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> ERROR: "dpdmai_get_rx_queue"
>[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> ERROR: "dpdmai_get_attributes"
>[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>undefined!
>> ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>undefined!
>> ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>undefined!
>> ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>undefined!
>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static
>EXPORT_SYMBOL_GPL
>> make[2]: *** [__modpost] Error 1
>> make[1]: *** [modules] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> make: *** [sub-make] Error 2
>>
>> So export it.
>
>Applied, thanks
[Peng Ma] Got it.
Thanks,
Peng
>
>--
>~Vinod


[PATCH 1/1] staging: exfat: Update MAINTAINERS file

2019-10-22 Thread Valdis Kletnieks
Add a L: tag so get_maintainers.pl output includes the linux-fsdevel list

Signed-off-by: Valdis Kletnieks 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3d09efe69508..188435ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6186,6 +6186,7 @@ F:include/uapi/linux/mii.h
 
 EXFAT FILE SYSTEM
 M: Valdis Kletnieks 
+L: linux-fsde...@vger.kernel.org
 S: Maintained
 F: drivers/staging/exfat/
 
-- 
2.23.0



Re: linux-next: Tree for Oct 14 (insn_decoder_test)

2019-10-22 Thread Masami Hiramatsu
Hi,

On Mon, 14 Oct 2019 08:30:02 -0700
Randy Dunlap  wrote:

> On 10/13/19 11:47 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20191011:
> > 
> 
> on x86_64:
> 
>   HOSTCC  arch/x86/tools/insn_decoder_test
>   HOSTCC  arch/x86/tools/insn_sanity
>   TESTposttest
> arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder 
> bug, please report this.
> arch/x86/tools/insn_decoder_test: warning: 81000bf1:  f7 0b 00 01 08 
> 00   testl  $0x80100,(%rbx)
> arch/x86/tools/insn_decoder_test: warning: objdump says 6 bytes, but 
> insn_get_length() says 2
> arch/x86/tools/insn_decoder_test: warning: Decoded and checked 11913894 
> instructions with 1 failures
>   TESTposttest
> arch/x86/tools/insn_sanity: Success: decoded and checked 100 random 
> instructions with 0 errors (seed:0x871ce29c)

Hmm, curious.

x86-opcode-map.txt said,
f7: Grp3_2 Ev (1A)

and "0x0b" is 1011b, Group encoding bits are 5,4,3 (reg field),
so group index is 001.

GrpTable: Grp3_2
0: TEST Ev,Iz
1:

Hmm, "f7 0b" is not assigned to any instruction... (testl should be f7 03)

I've checked Intel SDM May 2019 version(*), but the Opcode Map (Table A-6. 
Opecode
Extensions for One- and Two-byte Opecodes by Group Number) showed the group 
index
001 is still blank. I've also checked that Table B-13 (General Purpose 
Instruction
 Formats and Encodings for Non-64-Bit Modes (Note that this has no REX prefix)) 
but
I couldn't find "f7 0b".

At last, I found that on AMD64 Architecture Programmer's Manual Volume 3, 
Appendix A.2
Table A-6. ModRM.reg Extensions for the Primary Opcode Map(**), which shows 
that both
f7 + reg=000 and f7 + reg=001 are same. So only on AMD64, it is officially 
available
instruction.

(*) 
https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf
(**) https://www.amd.com/system/files/TechDocs/24594.pdf

OK, so this should be fixed with below patch.

--
>From b3f45b86df25be59fcf417730ab4c69c6310eaad Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu 
Date: Wed, 23 Oct 2019 14:45:35 +0900
Subject: [PATCH] x86/decoder: Add TEST opcode to Group3-2

Add TEST opcode to Group3-2 reg=001b as same as Group3-1 does.

Commit 12a78d43de76 ("x86/decoder: Add new TEST instruction pattern")
added a TEST opcode assignment to f6 XX/001/XXX (Group 3-1), but not
added f7 XX/001/XXX (Group 3-2). Actually these TEST opcode is not
described in Intel SDM Vol2, but described in AMD64 Architecture
Programmer's Manual Vol.3, Appendix A.2 Table A-6. ModRM.reg
Extensions for the Primary Opcode Map.

Without this fix, Randy found a warning by insn_decoder_test related
to this issue as below.

  HOSTCC  arch/x86/tools/insn_decoder_test
  HOSTCC  arch/x86/tools/insn_sanity
  TESTposttest
arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder 
bug, please report this.
arch/x86/tools/insn_decoder_test: warning: 81000bf1:f7 0b 00 01 08 
00   testl  $0x80100,(%rbx)
arch/x86/tools/insn_decoder_test: warning: objdump says 6 bytes, but 
insn_get_length() says 2
arch/x86/tools/insn_decoder_test: warning: Decoded and checked 11913894 
instructions with 1 failures
  TESTposttest
arch/x86/tools/insn_sanity: Success: decoded and checked 100 random 
instructions with 0 errors (seed:0x871ce29c)

To fix this error, add TEST opcode according to AMD64 APM Vol.3.

Reported-by: Randy Dunlap 
Signed-off-by: Masami Hiramatsu 
---
 arch/x86/lib/x86-opcode-map.txt   | 2 +-
 tools/arch/x86/lib/x86-opcode-map.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
index e0b85930dd77..4635ce298d1d 100644
--- a/arch/x86/lib/x86-opcode-map.txt
+++ b/arch/x86/lib/x86-opcode-map.txt
@@ -907,7 +907,7 @@ EndTable
 
 GrpTable: Grp3_2
 0: TEST Ev,Iz
-1:
+1: TEST Ev,Iz
 2: NOT Ev
 3: NEG Ev
 4: MUL rAX,Ev
diff --git a/tools/arch/x86/lib/x86-opcode-map.txt 
b/tools/arch/x86/lib/x86-opcode-map.txt
index e0b85930dd77..4635ce298d1d 100644
--- a/tools/arch/x86/lib/x86-opcode-map.txt
+++ b/tools/arch/x86/lib/x86-opcode-map.txt
@@ -907,7 +907,7 @@ EndTable
 
 GrpTable: Grp3_2
 0: TEST Ev,Iz
-1:
+1: TEST Ev,Iz
 2: NOT Ev
 3: NEG Ev
 4: MUL rAX,Ev
-- 
2.20.1
-- 
Masami Hiramatsu 


Re: [PATCH v3 5/8] riscv: mark some code and data as file-static

2019-10-22 Thread Greentime Hu
Paul Walmsley  於 2019年10月19日 週六 下午3:58寫道:
>
> Several functions and arrays which are only used in the files in which
> they are declared are missing "static" qualifiers.  Warnings for these
> symbols are reported by sparse:
>
> arch/riscv/kernel/stacktrace.c:22:14: warning: symbol 'walk_stackframe' was 
> not declared. Should it be static?
> arch/riscv/kernel/vdso.c:28:18: warning: symbol 'vdso_data' was not declared. 
> Should it be static?
> arch/riscv/mm/init.c:42:6: warning: symbol 'setup_zero_page' was not 
> declared. Should it be static?
> arch/riscv/mm/init.c:152:7: warning: symbol 'fixmap_pte' was not declared. 
> Should it be static?
> arch/riscv/mm/init.c:211:7: warning: symbol 'trampoline_pmd' was not 
> declared. Should it be static?
> arch/riscv/mm/init.c:212:7: warning: symbol 'fixmap_pmd' was not declared. 
> Should it be static?
> arch/riscv/mm/init.c:219:7: warning: symbol 'early_pmd' was not declared. 
> Should it be static?
> arch/riscv/mm/sifive_l2_cache.c:145:12: warning: symbol 'sifive_l2_init' was 
> not declared. Should it be static?
>
> Resolve these warnings by marking them as static.
>
> Signed-off-by: Paul Walmsley 
> ---
>  arch/riscv/kernel/stacktrace.c  |  6 --
>  arch/riscv/kernel/vdso.c|  2 +-
>  arch/riscv/mm/init.c| 12 +++-
>  arch/riscv/mm/sifive_l2_cache.c |  2 +-
>  4 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
> index 0940681d2f68..fd908baed51c 100644
> --- a/arch/riscv/kernel/stacktrace.c
> +++ b/arch/riscv/kernel/stacktrace.c
> @@ -19,8 +19,10 @@ struct stackframe {
> unsigned long ra;
>  };
>
> -void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
> -bool (*fn)(unsigned long, void *), void *arg)
> +static void notrace walk_stackframe(struct task_struct *task,
> +   struct pt_regs *regs,
> +   bool (*fn)(unsigned long, void *),
> +   void *arg)

I think walk_stackframe() could not be static because it will be used
in perf_callchain.c.


Re: [PATCH v2] vhost: introduce mdev based hardware backend

2019-10-22 Thread Jason Wang



On 2019/10/23 上午11:02, Tiwei Bie wrote:

On Tue, Oct 22, 2019 at 09:30:16PM +0800, Jason Wang wrote:

On 2019/10/22 下午5:52, Tiwei Bie wrote:

This patch introduces a mdev based hardware vhost backend.
This backend is built on top of the same abstraction used
in virtio-mdev and provides a generic vhost interface for
userspace to accelerate the virtio devices in guest.

This backend is implemented as a mdev device driver on top
of the same mdev device ops used in virtio-mdev but using
a different mdev class id, and it will register the device
as a VFIO device for userspace to use. Userspace can setup
the IOMMU with the existing VFIO container/group APIs and
then get the device fd with the device name. After getting
the device fd of this device, userspace can use vhost ioctls
to setup the backend.

Signed-off-by: Tiwei Bie 
---
This patch depends on below series:
https://lkml.org/lkml/2019/10/17/286

v1 -> v2:
- Replace _SET_STATE with _SET_STATUS (MST);
- Check status bits at each step (MST);
- Report the max ring size and max number of queues (MST);
- Add missing MODULE_DEVICE_TABLE (Jason);
- Only support the network backend w/o multiqueue for now;


Any idea on how to extend it to support devices other than net? I think we
want a generic API or an API that could be made generic in the future.

Do we want to e.g having a generic vhost mdev for all kinds of devices or
introducing e.g vhost-net-mdev and vhost-scsi-mdev?

One possible way is to do what vhost-user does. I.e. Apart from
the generic ring, features, ... related ioctls, we also introduce
device specific ioctls when we need them. As vhost-mdev just needs
to forward configs between parent and userspace and even won't
cache any info when possible,



So it looks to me this is only possible if we expose e.g set_config and 
get_config to userspace.




I think it might be better to do
this in one generic vhost-mdev module.



Looking at definitions of VhostUserRequest in qemu, it mixed generic API 
with device specific API. If we want go this ways (a generic 
vhost-mdev), more questions needs to be answered:


1) How could userspace know which type of vhost it would use? Do we need 
to expose virtio subsystem device in for userspace this case?


2) That generic vhost-mdev module still need to filter out unsupported 
ioctls for a specific type. E.g if it probes a net device, it should 
refuse API for other type. This in fact a vhost-mdev-net but just not 
modularize it on top of vhost-mdev.








- Some minor fixes and improvements;
- Rebase on top of virtio-mdev series v4;

RFC v4 -> v1:
- Implement vhost-mdev as a mdev device driver directly and
connect it to VFIO container/group. (Jason);
- Pass ring addresses as GPAs/IOVAs in vhost-mdev to avoid
meaningless HVA->GPA translations (Jason);

RFC v3 -> RFC v4:
- Build vhost-mdev on top of the same abstraction used by
virtio-mdev (Jason);
- Introduce vhost fd and pass VFIO fd via SET_BACKEND ioctl (MST);

RFC v2 -> RFC v3:
- Reuse vhost's ioctls instead of inventing a VFIO regions/irqs
based vhost protocol on top of vfio-mdev (Jason);

RFC v1 -> RFC v2:
- Introduce a new VFIO device type to build a vhost protocol
on top of vfio-mdev;

   drivers/vfio/mdev/mdev_core.c |  12 +
   drivers/vhost/Kconfig |   9 +
   drivers/vhost/Makefile|   3 +
   drivers/vhost/mdev.c  | 415 ++
   include/linux/mdev.h  |   3 +
   include/uapi/linux/vhost.h|  13 ++
   6 files changed, 455 insertions(+)
   create mode 100644 drivers/vhost/mdev.c

diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 5834f6b7c7a5..2963f65e6648 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -69,6 +69,18 @@ void mdev_set_virtio_ops(struct mdev_device *mdev,
   }
   EXPORT_SYMBOL(mdev_set_virtio_ops);
+/* Specify the vhost device ops for the mdev device, this
+ * must be called during create() callback for vhost mdev device.
+ */
+void mdev_set_vhost_ops(struct mdev_device *mdev,
+   const struct virtio_mdev_device_ops *vhost_ops)
+{
+   WARN_ON(mdev->class_id);
+   mdev->class_id = MDEV_CLASS_ID_VHOST;
+   mdev->device_ops = vhost_ops;
+}
+EXPORT_SYMBOL(mdev_set_vhost_ops);
+
   const void *mdev_get_dev_ops(struct mdev_device *mdev)
   {
return mdev->device_ops;
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 3d03ccbd1adc..7b5c2f655af7 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -34,6 +34,15 @@ config VHOST_VSOCK
To compile this driver as a module, choose M here: the module will be 
called
vhost_vsock.
+config VHOST_MDEV
+   tristate "Vhost driver for Mediated devices"
+   depends on EVENTFD && VFIO && VFIO_MDEV
+   select VHOST
+   default n
+   ---help---
+   Say M here to enable the vhost_mdev module for use with
+   the mediated device based hardware vhost accelerators.

Re: [PATCH v2 04/11] dt-bindings: phy-mtk-tphy: add a new reference clock

2019-10-22 Thread Kishon Vijay Abraham I
Hi Rob,

On 18/09/19 1:58 AM, Rob Herring wrote:
> On Fri, 30 Aug 2019 15:14:51 +0800, Chunfeng Yun wrote:
>> Usually the digital and analog phys use the same reference clock,
>> but on some platforms, they are separated, so add another optional
>> clock to support it.
>> In order to keep the clock names consistent with PHY IP's, use
>> the da_ref for analog phy and ref clock for digital phy.
>>
>> Signed-off-by: Chunfeng Yun 
>> ---
>> v2: fix typo of analog and needed
>> ---
>>  Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
> 
> Acked-by: Rob Herring 

I see you've acked a couple of patches in the series. However the other
dt-binding patch neither has an Ack or NAK. Is there a specific reason or can I
merge the series?

Thanks
Kishon


Re: [PATCH] rtlwifi: Remove unnecessary NULL check in rtl_regd_init

2019-10-22 Thread Pkshih
On Tue, 2019-10-22 at 17:47 -0700, Nathan Chancellor wrote:
> When building with Clang + -Wtautological-pointer-compare:
> 
> drivers/net/wireless/realtek/rtlwifi/regd.c:389:33: warning: comparison
> of address of 'rtlpriv->regd' equal to a null pointer is always false
> [-Wtautological-pointer-compare]
> if (wiphy == NULL || >regd == NULL)
>   ~^~~~
> 1 warning generated.
> 
> The address of an array member is never NULL unless it is the first
> struct member so remove the unnecessary check. This was addressed in
> the staging version of the driver in commit f986978b32b3 ("Staging:
> rtlwifi: remove unnecessary NULL check").
> 
> While we are here, fix the following checkpatch warning:
> 
> CHECK: Comparison to NULL could be written "!wiphy"
> 35: FILE: drivers/net/wireless/realtek/rtlwifi/regd.c:389:
> +   if (wiphy == NULL)
> 
> Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
> Link:https://github.com/ClangBuiltLinux/linux/issues/750
> Signed-off-by: Nathan Chancellor 

Looks good.
Thanks for your fix.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c
> b/drivers/net/wireless/realtek/rtlwifi/regd.c
> index c10432cd703e..8be31e0ad878 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -386,7 +386,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
>   struct wiphy *wiphy = hw->wiphy;
>   struct country_code_to_enum_rd *country = NULL;
>  
> - if (wiphy == NULL || >regd == NULL)
> + if (!wiphy)
>   return -EINVAL;
>  
>   /* init country_code from efuse channel plan */




Re: [PATCH 3/3] phy: ti: j721e-wiz: Manage typec-gpio-dir

2019-10-22 Thread Jyri Sarha
On 22/10/2019 16:22, Roger Quadros wrote:
> Based on this GPIO state we need to configure LN10
> bit to swap lane0 and lane1 if required (flipped connector).
> 
> Type-C companions typically need some time after the cable is
> plugged before and before they reflect the correct status of
> Type-C plug orientation on the DIR line.
> 
> Type-C Spec specifies CC attachment debounce time (tCCDebounce)
> of 100 ms (min) to 200 ms (max).
> 
> Use the DT property to figure out if we need to add delay
> or not before sampling the Type-C DIR line.
> 
> Signed-off-by: Roger Quadros 
> Signed-off-by: Sekhar Nori 
> ---
>  drivers/phy/ti/phy-j721e-wiz.c | 41 ++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index 2a95da843e9f..2becdbcb762a 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -9,6 +9,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -22,6 +24,7 @@
>  #define WIZ_SERDES_CTRL  0x404
>  #define WIZ_SERDES_TOP_CTRL  0x408
>  #define WIZ_SERDES_RST   0x40c
> +#define WIZ_SERDES_TYPEC 0x410
>  #define WIZ_LANECTL(n)   (0x480 + (0x40 * (n)))
>  
>  #define WIZ_MAX_LANES4
> @@ -29,6 +32,8 @@
>  #define WIZ_DIV_NUM_CLOCKS_16G   2
>  #define WIZ_DIV_NUM_CLOCKS_10G   1
>  
> +#define WIZ_SERDES_TYPEC_LN10_SWAP   BIT(30)
> +
>  enum wiz_lane_standard_mode {
>   LANE_MODE_GEN1,
>   LANE_MODE_GEN2,
> @@ -206,6 +211,8 @@ struct wiz {
>   u32 num_lanes;
>   struct platform_device  *serdes_pdev;
>   struct reset_controller_dev wiz_phy_reset_dev;
> + struct gpio_desc*gpio_typec_dir;
> + int typec_dir_delay;
>  };
>  
>  static int wiz_reset(struct wiz *wiz)
> @@ -703,6 +710,21 @@ static int wiz_phy_reset_deassert(struct 
> reset_controller_dev *rcdev,
>   struct wiz *wiz = dev_get_drvdata(dev);
>   int ret;
>  
> + /* if typec-dir gpio was specified, set LN10 SWAP bit based on that */
> + if (id == 0 && wiz->gpio_typec_dir) {
> + if (wiz->typec_dir_delay)
> + msleep_interruptible(wiz->typec_dir_delay);
> +
> + if (gpiod_get_value_cansleep(wiz->gpio_typec_dir)) {
> + regmap_update_bits(wiz->regmap, WIZ_SERDES_TYPEC,
> +WIZ_SERDES_TYPEC_LN10_SWAP,
> +WIZ_SERDES_TYPEC_LN10_SWAP);

A nit pick, but wouldn't it be more coherent with the rest of the driver
to define a REG_FIELD also for TYPEC_LN10_SWAP bit?

> + } else {
> + regmap_update_bits(wiz->regmap, WIZ_SERDES_TYPEC,
> +WIZ_SERDES_TYPEC_LN10_SWAP, 0);
> + }
> + }
> +
>   if (id == 0) {
>   ret = regmap_field_write(wiz->phy_reset_n, true);
>   return ret;
> @@ -789,6 +811,25 @@ static int wiz_probe(struct platform_device *pdev)
>   goto err_addr_to_resource;
>   }
>  
> + wiz->gpio_typec_dir = devm_gpiod_get_optional(dev, "typec-dir",
> +   GPIOD_IN);
> + if (IS_ERR(wiz->gpio_typec_dir)) {
> + ret = PTR_ERR(wiz->gpio_typec_dir);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to request typec-dir gpio: %d\n",
> + ret);
> + goto err_addr_to_resource;
> + }
> +
> + if (wiz->gpio_typec_dir) {
> + ret = of_property_read_u32(node, "typec-dir-debounce",
> +>typec_dir_delay);
> + if (ret && ret != -EINVAL) {
> + dev_err(dev, "Invalid typec-dir-debounce property\n");
> + goto err_addr_to_resource;
> + }
> + }
> +
>   wiz->dev = dev;
>   wiz->regmap = regmap;
>   wiz->num_lanes = num_lanes;
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [PATCH] opp: of: drop incorrect lockdep_assert_held()

2019-10-22 Thread Viresh Kumar
On 10-10-19, 16:00, Viresh Kumar wrote:
> _find_opp_of_np() doesn't traverse the list of OPP tables but instead
> just the entries within an OPP table and so only requires to lock the
> OPP table itself.
> 
> The lockdep_assert_held() was added there by mistake and isn't really
> required.
> 
> Fixes: 5d6d106fa455 ("OPP: Populate required opp tables from "required-opps" 
> property")
> Cc: v5.0+  # v5.0+
> Reported-by: Niklas Cassel 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/opp/of.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 1813f5ad5fa2..6dc41faf74b5 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -77,8 +77,6 @@ static struct dev_pm_opp *_find_opp_of_np(struct opp_table 
> *opp_table,
>  {
>   struct dev_pm_opp *opp;
>  
> - lockdep_assert_held(_table_lock);
> -
>   mutex_lock(_table->lock);
>  
>   list_for_each_entry(opp, _table->opp_list, node) {

@Niklas, any inputs from your side  here would be appreciated :)

-- 
viresh


[PATCH v1 1/1] scsi: ufs: Add command logging infrastructure

2019-10-22 Thread Can Guo
Add the necessary infrastructure to keep timestamp history
of commands, events and other useful info for debugging
complex issues. This helps in diagnosing events leading
upto failure.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/Kconfig  |  12 +++
 drivers/scsi/ufs/ufshcd.c | 214 +++---
 drivers/scsi/ufs/ufshcd.h |  24 +-
 3 files changed, 218 insertions(+), 32 deletions(-)

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 0b845ab..afc70cb 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -50,6 +50,18 @@ config SCSI_UFSHCD
  However, do not compile this as a module if your root file system
  (the one containing the directory /) is located on a UFS device.
 
+config SCSI_UFSHCD_CMD_LOGGING
+   bool "Universal Flash Storage host controller driver layer command 
logging support"
+   depends on SCSI_UFSHCD
+   help
+ This selects the UFS host controller driver layer command logging.
+ UFS host controller driver layer command logging records all the
+ command information sent from UFS host controller for debugging
+ purpose.
+
+ Select this if you want above mentioned debug information captured.
+ If unsure, say N.
+
 config SCSI_UFSHCD_PCI
tristate "PCI bus based UFS Controller support"
depends on SCSI_UFSHCD && PCI
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c28c144..f3faa85 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -91,6 +91,9 @@
 /* default delay of autosuspend: 2000 ms */
 #define RPM_AUTOSUSPEND_DELAY_MS 2000
 
+/* Maximum command logging entries */
+#define UFSHCD_MAX_CMD_LOGGING 20
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)   \
({  \
int _ret;   \
@@ -328,14 +331,135 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba 
*hba, unsigned int tag,
>input_param1);
 }
 
-static void ufshcd_add_command_trace(struct ufs_hba *hba,
-   unsigned int tag, const char *str)
+static inline void ufshcd_add_command_trace(struct ufs_hba *hba,
+   struct ufshcd_cmd_log_entry *entry)
+{
+   if (trace_ufshcd_command_enabled()) {
+   u32 intr = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+
+   trace_ufshcd_command(dev_name(hba->dev), entry->str, entry->tag,
+entry->doorbell, entry->transfer_len, intr,
+entry->lba, entry->cmd_id);
+   }
+}
+
+#ifdef CONFIG_SCSI_UFSHCD_CMD_LOGGING
+static void ufshcd_cmd_log_init(struct ufs_hba *hba)
+{
+   /* Allocate log entries */
+   if (!hba->cmd_log.entries) {
+   hba->cmd_log.entries = kcalloc(UFSHCD_MAX_CMD_LOGGING,
+   sizeof(struct ufshcd_cmd_log_entry), GFP_KERNEL);
+   if (!hba->cmd_log.entries)
+   return;
+   dev_dbg(hba->dev, "%s: cmd_log.entries initialized\n",
+   __func__);
+   }
+}
+
+static void __ufshcd_cmd_log(struct ufs_hba *hba, char *str, char *cmd_type,
+unsigned int tag, u8 cmd_id, u8 idn, u8 lun,
+sector_t lba, int transfer_len)
+{
+   struct ufshcd_cmd_log_entry *entry;
+
+   if (!hba->cmd_log.entries)
+   return;
+
+   entry = >cmd_log.entries[hba->cmd_log.pos];
+   entry->lun = lun;
+   entry->str = str;
+   entry->cmd_type = cmd_type;
+   entry->cmd_id = cmd_id;
+   entry->lba = lba;
+   entry->transfer_len = transfer_len;
+   entry->idn = idn;
+   entry->doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+   entry->tag = tag;
+   entry->tstamp = ktime_get();
+   entry->outstanding_reqs = hba->outstanding_reqs;
+   entry->seq_num = hba->cmd_log.seq_num;
+   hba->cmd_log.seq_num++;
+   hba->cmd_log.pos = (hba->cmd_log.pos + 1) % UFSHCD_MAX_CMD_LOGGING;
+
+   ufshcd_add_command_trace(hba, entry);
+}
+
+static void ufshcd_cmd_log(struct ufs_hba *hba, char *str, char *cmd_type,
+   unsigned int tag, u8 cmd_id, u8 idn)
+{
+   __ufshcd_cmd_log(hba, str, cmd_type, tag, cmd_id, idn, 0, 0, 0);
+}
+
+static void ufshcd_dme_cmd_log(struct ufs_hba *hba, char *str, u8 cmd_id)
+{
+   ufshcd_cmd_log(hba, str, "dme", 0, cmd_id, 0);
+}
+
+static void ufshcd_print_cmd_log(struct ufs_hba *hba)
+{
+   int i;
+   int pos;
+   struct ufshcd_cmd_log_entry *p;
+
+   if (!hba->cmd_log.entries)
+   return;
+
+   pos = hba->cmd_log.pos;
+   for (i = 0; i < UFSHCD_MAX_CMD_LOGGING; i++) {
+   p = >cmd_log.entries[pos];
+   pos = (pos + 1) % UFSHCD_MAX_CMD_LOGGING;
+
+   if 

[PATCH 1/8] staging: exfat: Clean up namespace pollution, part 1

2019-10-22 Thread Valdis Kletnieks
Make as much as possible static.  We're over-exuberant here for the benefit
of a following patch, as the compiler will flag now-unused static code

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  | 156 ++---
 drivers/staging/exfat/exfat_core.c | 142 +-
 2 files changed, 149 insertions(+), 149 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 3abab33e932c..0c779c8dd858 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -768,107 +768,107 @@ void buf_init(struct super_block *sb);
 void buf_shutdown(struct super_block *sb);
 int FAT_read(struct super_block *sb, u32 loc, u32 *content);
 s32 FAT_write(struct super_block *sb, u32 loc, u32 content);
-u8 *FAT_getblk(struct super_block *sb, sector_t sec);
-void FAT_modify(struct super_block *sb, sector_t sec);
+static u8 *FAT_getblk(struct super_block *sb, sector_t sec);
+static void FAT_modify(struct super_block *sb, sector_t sec);
 void FAT_release_all(struct super_block *sb);
-void FAT_sync(struct super_block *sb);
+static void FAT_sync(struct super_block *sb);
 u8 *buf_getblk(struct super_block *sb, sector_t sec);
 void buf_modify(struct super_block *sb, sector_t sec);
 void buf_lock(struct super_block *sb, sector_t sec);
 void buf_unlock(struct super_block *sb, sector_t sec);
 void buf_release(struct super_block *sb, sector_t sec);
 void buf_release_all(struct super_block *sb);
-void buf_sync(struct super_block *sb);
+static void buf_sync(struct super_block *sb);
 
 /* fs management functions */
 void fs_set_vol_flags(struct super_block *sb, u32 new_flag);
-void fs_error(struct super_block *sb);
+static void fs_error(struct super_block *sb);
 
 /* cluster management functions */
-s32 clear_cluster(struct super_block *sb, u32 clu);
-s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
+static s32 clear_cluster(struct super_block *sb, u32 clu);
+static s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
  struct chain_t *p_chain);
-s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
+static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
struct chain_t *p_chain);
-void fat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
+static void fat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
  s32 do_relse);
-void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
+static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
s32 do_relse);
-u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
+static u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
 s32 count_num_clusters(struct super_block *sb, struct chain_t *dir);
-s32 fat_count_used_clusters(struct super_block *sb);
-s32 exfat_count_used_clusters(struct super_block *sb);
+static s32 fat_count_used_clusters(struct super_block *sb);
+static s32 exfat_count_used_clusters(struct super_block *sb);
 void exfat_chain_cont_cluster(struct super_block *sb, u32 chain, s32 len);
 
 /* allocation bitmap management functions */
 s32 load_alloc_bitmap(struct super_block *sb);
 void free_alloc_bitmap(struct super_block *sb);
-s32 set_alloc_bitmap(struct super_block *sb, u32 clu);
-s32 clr_alloc_bitmap(struct super_block *sb, u32 clu);
-u32 test_alloc_bitmap(struct super_block *sb, u32 clu);
-void sync_alloc_bitmap(struct super_block *sb);
+static s32 set_alloc_bitmap(struct super_block *sb, u32 clu);
+static s32 clr_alloc_bitmap(struct super_block *sb, u32 clu);
+static u32 test_alloc_bitmap(struct super_block *sb, u32 clu);
+static void sync_alloc_bitmap(struct super_block *sb);
 
 /* upcase table management functions */
 s32 load_upcase_table(struct super_block *sb);
 void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
-u32 fat_get_entry_type(struct dentry_t *p_entry);
-u32 exfat_get_entry_type(struct dentry_t *p_entry);
-void fat_set_entry_type(struct dentry_t *p_entry, u32 type);
-void exfat_set_entry_type(struct dentry_t *p_entry, u32 type);
-u32 fat_get_entry_attr(struct dentry_t *p_entry);
-u32 exfat_get_entry_attr(struct dentry_t *p_entry);
-void fat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-void exfat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-u8 fat_get_entry_flag(struct dentry_t *p_entry);
-u8 exfat_get_entry_flag(struct dentry_t *p_entry);
-void fat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-void exfat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-u32 fat_get_entry_clu0(struct dentry_t *p_entry);
-u32 exfat_get_entry_clu0(struct dentry_t *p_entry);
-void fat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-void exfat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-u64 fat_get_entry_size(struct dentry_t *p_entry);
-u64 exfat_get_entry_size(struct 

[PATCH 6/8] staging: exfat: More static cleanups for exfat_core.c

2019-10-22 Thread Valdis Kletnieks
Move static function bodies before first use, remove the definition in exfat.h

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  |   6 -
 drivers/staging/exfat/exfat_core.c | 500 ++---
 2 files changed, 250 insertions(+), 256 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 654a0c46c1a0..b93df526355b 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -786,10 +786,6 @@ void exfat_chain_cont_cluster(struct super_block *sb, u32 
chain, s32 len);
 /* allocation bitmap management functions */
 s32 load_alloc_bitmap(struct super_block *sb);
 void free_alloc_bitmap(struct super_block *sb);
-static s32 set_alloc_bitmap(struct super_block *sb, u32 clu);
-static s32 clr_alloc_bitmap(struct super_block *sb, u32 clu);
-static u32 test_alloc_bitmap(struct super_block *sb, u32 clu);
-static void sync_alloc_bitmap(struct super_block *sb);
 
 /* upcase table management functions */
 s32 load_upcase_table(struct super_block *sb);
@@ -812,8 +808,6 @@ void release_entry_set(struct entry_set_cache_t *es);
 static s32 write_whole_entry_set(struct super_block *sb, struct 
entry_set_cache_t *es);
 s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
   u32 type);
-static void update_dir_checksum(struct super_block *sb, struct chain_t *p_dir,
-s32 entry);
 void update_dir_checksum_with_entry_set(struct super_block *sb,
struct entry_set_cache_t *es);
 bool is_dir_empty(struct super_block *sb, struct chain_t *p_dir);
diff --git a/drivers/staging/exfat/exfat_core.c 
b/drivers/staging/exfat/exfat_core.c
index dd69a9a6dddc..1a49da231946 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -132,6 +132,199 @@ static void fs_error(struct super_block *sb)
}
 }
 
+/*
+ *  Allocation Bitmap Management Functions
+ */
+
+s32 load_alloc_bitmap(struct super_block *sb)
+{
+   int i, j, ret;
+   u32 map_size;
+   u32 type;
+   sector_t sector;
+   struct chain_t clu;
+   struct bmap_dentry_t *ep;
+   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
+   struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
+
+   clu.dir = p_fs->root_dir;
+   clu.flags = 0x01;
+
+   while (clu.dir != CLUSTER_32(~0)) {
+   if (p_fs->dev_ejected)
+   break;
+
+   for (i = 0; i < p_fs->dentries_per_clu; i++) {
+   ep = (struct bmap_dentry_t *)get_entry_in_dir(sb, ,
+ i, NULL);
+   if (!ep)
+   return FFS_MEDIAERR;
+
+   type = p_fs->fs_func->get_entry_type((struct dentry_t 
*)ep);
+
+   if (type == TYPE_UNUSED)
+   break;
+   if (type != TYPE_BITMAP)
+   continue;
+
+   if (ep->flags == 0x0) {
+   p_fs->map_clu  = GET32_A(ep->start_clu);
+   map_size = (u32)GET64_A(ep->size);
+
+   p_fs->map_sectors = ((map_size - 1) >> 
p_bd->sector_size_bits) + 1;
+
+   p_fs->vol_amap = 
kmalloc_array(p_fs->map_sectors,
+  sizeof(struct 
buffer_head *),
+  GFP_KERNEL);
+   if (!p_fs->vol_amap)
+   return FFS_MEMORYERR;
+
+   sector = START_SECTOR(p_fs->map_clu);
+
+   for (j = 0; j < p_fs->map_sectors; j++) {
+   p_fs->vol_amap[j] = NULL;
+   ret = sector_read(sb, sector + j, 
&(p_fs->vol_amap[j]), 1);
+   if (ret != FFS_SUCCESS) {
+   /*  release all buffers and 
free vol_amap */
+   i = 0;
+   while (i < j)
+   
brelse(p_fs->vol_amap[i++]);
+
+   kfree(p_fs->vol_amap);
+   p_fs->vol_amap = NULL;
+   return ret;
+   }
+   }
+
+   p_fs->pbr_bh = NULL;
+   return FFS_SUCCESS;
+   }
+   }
+
+   if (FAT_read(sb, clu.dir, ) != 0)
+   return FFS_MEDIAERR;
+   }
+
+   return FFS_FORMATERR;
+}
+
+void 

[PATCH 7/8] staging: exfat: Finished code movement for static cleanups in exfat_core.c

2019-10-22 Thread Valdis Kletnieks
Move static function bodies before first use, remove the definition in exfat.h

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  |  10 -
 drivers/staging/exfat/exfat_core.c | 661 ++---
 2 files changed, 330 insertions(+), 341 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index b93df526355b..8738e41dd5a5 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -793,10 +793,6 @@ void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
 struct timestamp_t *tm_current(struct timestamp_t *tm);
-static void init_file_entry(struct file_dentry_t *ep, u32 type);
-static void init_strm_entry(struct strm_dentry_t *ep, u8 flags, u32 start_clu,
-u64 size);
-static void init_name_entry(struct name_dentry_t *ep, u16 *uniname);
 
 struct dentry_t *get_entry_in_dir(struct super_block *sb, struct chain_t 
*p_dir,
  s32 entry, sector_t *sector);
@@ -805,7 +801,6 @@ struct entry_set_cache_t *get_entry_set_in_dir(struct 
super_block *sb,
   u32 type,
   struct dentry_t **file_ep);
 void release_entry_set(struct entry_set_cache_t *es);
-static s32 write_whole_entry_set(struct super_block *sb, struct 
entry_set_cache_t *es);
 s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
   u32 type);
 void update_dir_checksum_with_entry_set(struct super_block *sb,
@@ -819,11 +814,6 @@ s32 get_num_entries_and_dos_name(struct super_block *sb, 
struct chain_t *p_dir,
 void get_uni_name_from_dos_entry(struct super_block *sb,
 struct dos_dentry_t *ep,
 struct uni_name_t *p_uniname, u8 mode);
-static s32 extract_uni_name_from_name_entry(struct name_dentry_t *ep, u16 
*uniname,
-   s32 order);
-static s32 fat_generate_dos_name(struct super_block *sb, struct chain_t *p_dir,
- struct dos_name_t *p_dosname);
-static void fat_attach_count_to_dos_name(u8 *dosname, s32 count);
 u16 calc_checksum_2byte(void *data, s32 len, u16 chksum, s32 type);
 
 /* name resolution functions */
diff --git a/drivers/staging/exfat/exfat_core.c 
b/drivers/staging/exfat/exfat_core.c
index 1a49da231946..7332e69fcbcd 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -791,6 +791,168 @@ void free_upcase_table(struct super_block *sb)
p_fs->vol_utbl = NULL;
 }
 
+static s32 __write_partial_entries_in_entry_set(struct super_block *sb,
+   struct entry_set_cache_t *es,
+   sector_t sec, s32 off, u32 
count)
+{
+   s32 num_entries, buf_off = (off - es->offset);
+   u32 remaining_byte_in_sector, copy_entries;
+   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
+   struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
+   u32 clu;
+   u8 *buf, *esbuf = (u8 *)&(es->__buf);
+
+   pr_debug("%s entered es %p sec %llu off %d count %d\n",
+   __func__, es, (unsigned long long)sec, off, count);
+   num_entries = count;
+
+   while (num_entries) {
+   /* white per sector base */
+   remaining_byte_in_sector = (1 << p_bd->sector_size_bits) - off;
+   copy_entries = min_t(s32,
+remaining_byte_in_sector >> 
DENTRY_SIZE_BITS,
+num_entries);
+   buf = buf_getblk(sb, sec);
+   if (!buf)
+   goto err_out;
+   pr_debug("es->buf %p buf_off %u\n", esbuf, buf_off);
+   pr_debug("copying %d entries from %p to sector %llu\n",
+   copy_entries, (esbuf + buf_off),
+   (unsigned long long)sec);
+   memcpy(buf + off, esbuf + buf_off,
+  copy_entries << DENTRY_SIZE_BITS);
+   buf_modify(sb, sec);
+   num_entries -= copy_entries;
+
+   if (num_entries) {
+   /* get next sector */
+   if (IS_LAST_SECTOR_IN_CLUSTER(sec)) {
+   clu = GET_CLUSTER_FROM_SECTOR(sec);
+   if (es->alloc_flag == 0x03) {
+   clu++;
+   } else {
+   if (FAT_read(sb, clu, ) == -1)
+   goto err_out;
+   }
+   sec = START_SECTOR(clu);
+   } else {
+   sec++;
+   }
+   off = 0;
+   buf_off += copy_entries << DENTRY_SIZE_BITS;
+

[PATCH 4/8] staging: exfat: Cleanup static entries in exfat.h

2019-10-22 Thread Valdis Kletnieks
Many of the static definitions that remain are not needed, as the function
definition is already before the first use.

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h | 53 ---
 1 file changed, 53 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 9cd78b6417d0..dbd86a6cdc95 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -782,17 +782,9 @@ static void buf_sync(struct super_block *sb);
 
 /* fs management functions */
 void fs_set_vol_flags(struct super_block *sb, u32 new_flag);
-static void fs_error(struct super_block *sb);
 
 /* cluster management functions */
-static s32 clear_cluster(struct super_block *sb, u32 clu);
-static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
-   struct chain_t *p_chain);
-static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
-   s32 do_relse);
-static u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
 s32 count_num_clusters(struct super_block *sb, struct chain_t *dir);
-static s32 exfat_count_used_clusters(struct super_block *sb);
 void exfat_chain_cont_cluster(struct super_block *sb, u32 chain, s32 len);
 
 /* allocation bitmap management functions */
@@ -808,36 +800,12 @@ s32 load_upcase_table(struct super_block *sb);
 void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
-static u32 exfat_get_entry_type(struct dentry_t *p_entry);
-static void exfat_set_entry_type(struct dentry_t *p_entry, u32 type);
-static u32 exfat_get_entry_attr(struct dentry_t *p_entry);
-static void exfat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-static u8 exfat_get_entry_flag(struct dentry_t *p_entry);
-static void exfat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-static u32 exfat_get_entry_clu0(struct dentry_t *p_entry);
-static void exfat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-static u64 exfat_get_entry_size(struct dentry_t *p_entry);
-static void exfat_set_entry_size(struct dentry_t *p_entry, u64 size);
 struct timestamp_t *tm_current(struct timestamp_t *tm);
-static void exfat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
- u8 mode);
-static void exfat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
- u8 mode);
-static s32 exfat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir,
-s32 entry, u32 type, u32 start_clu, u64 size);
-static s32 exfat_init_ext_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
-s32 entry, s32 num_entries,
-struct uni_name_t *p_uniname,
-   struct dos_name_t *p_dosname);
 static void init_file_entry(struct file_dentry_t *ep, u32 type);
 static void init_strm_entry(struct strm_dentry_t *ep, u8 flags, u32 start_clu,
 u64 size);
 static void init_name_entry(struct name_dentry_t *ep, u16 *uniname);
-static void exfat_delete_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
-   s32 entry, s32 order, s32 num_entries);
 
-static s32 find_location(struct super_block *sb, struct chain_t *p_dir, s32 
entry,
- sector_t *sector, s32 *offset);
 struct dentry_t *get_entry_in_dir(struct super_block *sb, struct chain_t 
*p_dir,
  s32 entry, sector_t *sector);
 struct entry_set_cache_t *get_entry_set_in_dir(struct super_block *sb,
@@ -846,18 +814,6 @@ struct entry_set_cache_t *get_entry_set_in_dir(struct 
super_block *sb,
   struct dentry_t **file_ep);
 void release_entry_set(struct entry_set_cache_t *es);
 static s32 write_whole_entry_set(struct super_block *sb, struct 
entry_set_cache_t *es);
-static s32 write_partial_entries_in_entry_set(struct super_block *sb,
-  struct entry_set_cache_t *es,
-  struct dentry_t *ep, u32 count);
-static s32 search_deleted_or_unused_entry(struct super_block *sb,
-  struct chain_t *p_dir, s32 num_entries);
-static s32 find_empty_entry(struct inode *inode, struct chain_t *p_dir,
-s32 num_entries);
-static s32 exfat_find_dir_entry(struct super_block *sb, struct chain_t *p_dir,
-struct uni_name_t *p_uniname, s32 num_entries,
-struct dos_name_t *p_dosname, u32 type);
-static s32 exfat_count_ext_entries(struct super_block *sb, struct chain_t 
*p_dir,
-   s32 entry, struct dentry_t *p_entry);
 s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
   u32 type);
 static void update_dir_checksum(struct super_block *sb, struct chain_t *p_dir,
@@ -873,25 +829,16 @@ s32 

[PATCH 8/8] staging: exfat: Update TODO

2019-10-22 Thread Valdis Kletnieks
Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/TODO | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/exfat/TODO b/drivers/staging/exfat/TODO
index b60e50b9cf4e..110c30834bd2 100644
--- a/drivers/staging/exfat/TODO
+++ b/drivers/staging/exfat/TODO
@@ -1,21 +1,17 @@
 exfat_core.c - ffsReadFile - the goto err_out seem to leak a brelse().
 same for ffsWriteFile.
 
-exfat_core.c - fs_sync(sb,0) all over the place looks fishy as hell.
-There's only one place that calls it with a non-zero argument.
-Randomly removing fs_sync() calls is *not* the right answer, especially
-if the removal then leaves a call to fs_set_vol_flags(VOL_CLEAN), as that
-says the file system is clean and synced when we *know* it isn't.
-The proper fix here is to go through and actually analyze how DELAYED_SYNC
-should work, and any time we're setting VOL_CLEAN, ensure the file system
-has in fact been synced to disk.  In other words, changing the 'false' to
-'true' is probably more correct. Also, it's likely that the one current
-place where it actually does an bdev_sync isn't sufficient in the DELAYED_SYNC
-case.
-
 ffsTruncateFile -  if (old_size <= new_size) {
 That doesn't look right. How did it ever work? Are they relying on lazy
 block allocation when actual writes happen? If nothing else, it never
 does the 'fid->size = new_size' and do the inode update
 
 ffsSetAttr() is just dangling in the breeze, not wired up at all...
+
+exfat_core.c - The original code called fs_sync(sb,0) all over the place,
+with only one place that calls it with a non-zero argument. That's now been
+reversed, but a proper audit of sync and flush-to-disk is certainly needed.
+
+buf_sync(), sync_alloc_bitmap(), and FAT_sync() aren't actually used
+anyplace.  This is probably related to the borked original implementatin
+of fs_sync() that didn't actually do anything either.
-- 
2.23.0



[PATCH 5/8] staging: exfat: Clean up static definitions in exfat_cache.c

2019-10-22 Thread Valdis Kletnieks
Move static function bodies before first use, remove the definition in exfat.h

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h   |  4 --
 drivers/staging/exfat/exfat_cache.c | 94 +++--
 2 files changed, 48 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index dbd86a6cdc95..654a0c46c1a0 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -768,17 +768,13 @@ void buf_init(struct super_block *sb);
 void buf_shutdown(struct super_block *sb);
 int FAT_read(struct super_block *sb, u32 loc, u32 *content);
 s32 FAT_write(struct super_block *sb, u32 loc, u32 content);
-static u8 *FAT_getblk(struct super_block *sb, sector_t sec);
-static void FAT_modify(struct super_block *sb, sector_t sec);
 void FAT_release_all(struct super_block *sb);
-static void FAT_sync(struct super_block *sb);
 u8 *buf_getblk(struct super_block *sb, sector_t sec);
 void buf_modify(struct super_block *sb, sector_t sec);
 void buf_lock(struct super_block *sb, sector_t sec);
 void buf_unlock(struct super_block *sb, sector_t sec);
 void buf_release(struct super_block *sb, sector_t sec);
 void buf_release_all(struct super_block *sb);
-static void buf_sync(struct super_block *sb);
 
 /* fs management functions */
 void fs_set_vol_flags(struct super_block *sb, u32 new_flag);
diff --git a/drivers/staging/exfat/exfat_cache.c 
b/drivers/staging/exfat/exfat_cache.c
index e1b001718709..e9ad0353b4e5 100644
--- a/drivers/staging/exfat/exfat_cache.c
+++ b/drivers/staging/exfat/exfat_cache.c
@@ -193,6 +193,50 @@ void buf_shutdown(struct super_block *sb)
 {
 }
 
+static u8 *FAT_getblk(struct super_block *sb, sector_t sec)
+{
+   struct buf_cache_t *bp;
+   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
+
+   bp = FAT_cache_find(sb, sec);
+   if (bp) {
+   move_to_mru(bp, _fs->FAT_cache_lru_list);
+   return bp->buf_bh->b_data;
+   }
+
+   bp = FAT_cache_get(sb, sec);
+
+   FAT_cache_remove_hash(bp);
+
+   bp->drv = p_fs->drv;
+   bp->sec = sec;
+   bp->flag = 0;
+
+   FAT_cache_insert_hash(sb, bp);
+
+   if (sector_read(sb, sec, >buf_bh, 1) != FFS_SUCCESS) {
+   FAT_cache_remove_hash(bp);
+   bp->drv = -1;
+   bp->sec = ~0;
+   bp->flag = 0;
+   bp->buf_bh = NULL;
+
+   move_to_lru(bp, _fs->FAT_cache_lru_list);
+   return NULL;
+   }
+
+   return bp->buf_bh->b_data;
+}
+
+static void FAT_modify(struct super_block *sb, sector_t sec)
+{
+   struct buf_cache_t *bp;
+
+   bp = FAT_cache_find(sb, sec);
+   if (bp)
+   sector_write(sb, sec, bp->buf_bh, 0);
+}
+
 static int __FAT_read(struct super_block *sb, u32 loc, u32 *content)
 {
s32 off;
@@ -441,50 +485,6 @@ int FAT_write(struct super_block *sb, u32 loc, u32 content)
return ret;
 }
 
-u8 *FAT_getblk(struct super_block *sb, sector_t sec)
-{
-   struct buf_cache_t *bp;
-   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
-
-   bp = FAT_cache_find(sb, sec);
-   if (bp) {
-   move_to_mru(bp, _fs->FAT_cache_lru_list);
-   return bp->buf_bh->b_data;
-   }
-
-   bp = FAT_cache_get(sb, sec);
-
-   FAT_cache_remove_hash(bp);
-
-   bp->drv = p_fs->drv;
-   bp->sec = sec;
-   bp->flag = 0;
-
-   FAT_cache_insert_hash(sb, bp);
-
-   if (sector_read(sb, sec, >buf_bh, 1) != FFS_SUCCESS) {
-   FAT_cache_remove_hash(bp);
-   bp->drv = -1;
-   bp->sec = ~0;
-   bp->flag = 0;
-   bp->buf_bh = NULL;
-
-   move_to_lru(bp, _fs->FAT_cache_lru_list);
-   return NULL;
-   }
-
-   return bp->buf_bh->b_data;
-}
-
-void FAT_modify(struct super_block *sb, sector_t sec)
-{
-   struct buf_cache_t *bp;
-
-   bp = FAT_cache_find(sb, sec);
-   if (bp)
-   sector_write(sb, sec, bp->buf_bh, 0);
-}
-
 void FAT_release_all(struct super_block *sb)
 {
struct buf_cache_t *bp;
@@ -510,7 +510,8 @@ void FAT_release_all(struct super_block *sb)
up(_sem);
 }
 
-void FAT_sync(struct super_block *sb)
+/* FIXME - this function is not used anyplace. See TODO */
+static void FAT_sync(struct super_block *sb)
 {
struct buf_cache_t *bp;
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
@@ -704,7 +705,8 @@ void buf_release_all(struct super_block *sb)
up(_sem);
 }
 
-void buf_sync(struct super_block *sb)
+/* FIXME - this function is not used anyplace. See TODO */
+static void buf_sync(struct super_block *sb)
 {
struct buf_cache_t *bp;
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
-- 
2.23.0



[PATCH 3/8] staging: exfat: Remove FAT/VFAT mount support, part 2

2019-10-22 Thread Valdis Kletnieks
Remove no longer referenced FAT/VFAT routines.

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  |  49 +-
 drivers/staging/exfat/exfat_core.c | 755 -
 2 files changed, 2 insertions(+), 802 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index c2db3e9e9785..9cd78b6417d0 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -786,17 +786,12 @@ static void fs_error(struct super_block *sb);
 
 /* cluster management functions */
 static s32 clear_cluster(struct super_block *sb, u32 clu);
-static s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
- struct chain_t *p_chain);
 static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
struct chain_t *p_chain);
-static void fat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
- s32 do_relse);
 static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
s32 do_relse);
 static u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
 s32 count_num_clusters(struct super_block *sb, struct chain_t *dir);
-static s32 fat_count_used_clusters(struct super_block *sb);
 static s32 exfat_count_used_clusters(struct super_block *sb);
 void exfat_chain_cont_cluster(struct super_block *sb, u32 chain, s32 len);
 
@@ -813,63 +808,36 @@ s32 load_upcase_table(struct super_block *sb);
 void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
-static u32 fat_get_entry_type(struct dentry_t *p_entry);
 static u32 exfat_get_entry_type(struct dentry_t *p_entry);
-static void fat_set_entry_type(struct dentry_t *p_entry, u32 type);
 static void exfat_set_entry_type(struct dentry_t *p_entry, u32 type);
-static u32 fat_get_entry_attr(struct dentry_t *p_entry);
 static u32 exfat_get_entry_attr(struct dentry_t *p_entry);
-static void fat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
 static void exfat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-static u8 fat_get_entry_flag(struct dentry_t *p_entry);
 static u8 exfat_get_entry_flag(struct dentry_t *p_entry);
-static void fat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
 static void exfat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-static u32 fat_get_entry_clu0(struct dentry_t *p_entry);
 static u32 exfat_get_entry_clu0(struct dentry_t *p_entry);
-static void fat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
 static void exfat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-static u64 fat_get_entry_size(struct dentry_t *p_entry);
 static u64 exfat_get_entry_size(struct dentry_t *p_entry);
-static void fat_set_entry_size(struct dentry_t *p_entry, u64 size);
 static void exfat_set_entry_size(struct dentry_t *p_entry, u64 size);
 struct timestamp_t *tm_current(struct timestamp_t *tm);
-static void fat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
-   u8 mode);
 static void exfat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
  u8 mode);
-static void fat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
-   u8 mode);
 static void exfat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
  u8 mode);
-static s32 fat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir, 
s32 entry,
-  u32 type, u32 start_clu, u64 size);
 static s32 exfat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir,
 s32 entry, u32 type, u32 start_clu, u64 size);
-static s32 fat_init_ext_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
-  s32 entry, s32 num_entries,
-  struct uni_name_t *p_uniname,
-  struct dos_name_t *p_dosname);
 static s32 exfat_init_ext_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
 s32 entry, s32 num_entries,
 struct uni_name_t *p_uniname,
struct dos_name_t *p_dosname);
-static void init_dos_entry(struct dos_dentry_t *ep, u32 type, u32 start_clu);
-static void init_ext_entry(struct ext_dentry_t *ep, s32 order, u8 chksum,
-   u16 *uniname);
 static void init_file_entry(struct file_dentry_t *ep, u32 type);
 static void init_strm_entry(struct strm_dentry_t *ep, u8 flags, u32 start_clu,
 u64 size);
 static void init_name_entry(struct name_dentry_t *ep, u16 *uniname);
-static void fat_delete_dir_entry(struct super_block *sb, struct chain_t *p_dir,
- s32 entry, s32 order, s32 num_entries);
 static void exfat_delete_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
s32 entry, s32 order, s32 num_entries);
 
 static s32 find_location(struct 

[PATCH 2/8] staging: exfat: Remove FAT/VFAT mount support, part 1

2019-10-22 Thread Valdis Kletnieks
Remove the top-level mount functionality, to make this driver handle
only exfat file systems.

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/Kconfig   |   9 --
 drivers/staging/exfat/exfat.h   |   2 -
 drivers/staging/exfat/exfat_core.c  | 142 
 drivers/staging/exfat/exfat_super.c |   8 +-
 4 files changed, 1 insertion(+), 160 deletions(-)

diff --git a/drivers/staging/exfat/Kconfig b/drivers/staging/exfat/Kconfig
index ce32dfe33bec..0130019cbec2 100644
--- a/drivers/staging/exfat/Kconfig
+++ b/drivers/staging/exfat/Kconfig
@@ -6,15 +6,6 @@ config EXFAT_FS
help
  This adds support for the exFAT file system.
 
-config EXFAT_DONT_MOUNT_VFAT
-   bool "Prohibit mounting of fat/vfat filesystems by exFAT"
-   depends on EXFAT_FS
-   default y
-   help
- By default, the exFAT driver will only mount exFAT filesystems, and 
refuse
- to mount fat/vfat filesystems.  Set this to 'n' to allow the exFAT 
driver
- to mount these filesystems.
-
 config EXFAT_DISCARD
bool "enable discard support"
depends on EXFAT_FS
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 0c779c8dd858..c2db3e9e9785 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -935,8 +935,6 @@ s32 resolve_path(struct inode *inode, char *path, struct 
chain_t *p_dir,
 static s32 resolve_name(u8 *name, u8 **arg);
 
 /* file operation functions */
-static s32 fat16_mount(struct super_block *sb, struct pbr_sector_t *p_pbr);
-static s32 fat32_mount(struct super_block *sb, struct pbr_sector_t *p_pbr);
 s32 exfat_mount(struct super_block *sb, struct pbr_sector_t *p_pbr);
 s32 create_dir(struct inode *inode, struct chain_t *p_dir,
   struct uni_name_t *p_uniname, struct file_id_t *fid);
diff --git a/drivers/staging/exfat/exfat_core.c 
b/drivers/staging/exfat/exfat_core.c
index 0260e4fe3762..fd481b21f8b6 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -2980,148 +2980,6 @@ s32 resolve_path(struct inode *inode, char *path, 
struct chain_t *p_dir,
 /*
  *  File Operation Functions
  */
-static struct fs_func fat_fs_func = {
-   .alloc_cluster = fat_alloc_cluster,
-   .free_cluster = fat_free_cluster,
-   .count_used_clusters = fat_count_used_clusters,
-
-   .init_dir_entry = fat_init_dir_entry,
-   .init_ext_entry = fat_init_ext_entry,
-   .find_dir_entry = fat_find_dir_entry,
-   .delete_dir_entry = fat_delete_dir_entry,
-   .get_uni_name_from_ext_entry = fat_get_uni_name_from_ext_entry,
-   .count_ext_entries = fat_count_ext_entries,
-   .calc_num_entries = fat_calc_num_entries,
-
-   .get_entry_type = fat_get_entry_type,
-   .set_entry_type = fat_set_entry_type,
-   .get_entry_attr = fat_get_entry_attr,
-   .set_entry_attr = fat_set_entry_attr,
-   .get_entry_flag = fat_get_entry_flag,
-   .set_entry_flag = fat_set_entry_flag,
-   .get_entry_clu0 = fat_get_entry_clu0,
-   .set_entry_clu0 = fat_set_entry_clu0,
-   .get_entry_size = fat_get_entry_size,
-   .set_entry_size = fat_set_entry_size,
-   .get_entry_time = fat_get_entry_time,
-   .set_entry_time = fat_set_entry_time,
-};
-
-static s32 fat16_mount(struct super_block *sb, struct pbr_sector_t *p_pbr)
-{
-   s32 num_reserved, num_root_sectors;
-   struct bpb16_t *p_bpb = (struct bpb16_t *)p_pbr->bpb;
-   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
-   struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
-
-   if (p_bpb->num_fats == 0)
-   return FFS_FORMATERR;
-
-   num_root_sectors = GET16(p_bpb->num_root_entries) << DENTRY_SIZE_BITS;
-   num_root_sectors = ((num_root_sectors - 1) >>
-   p_bd->sector_size_bits) + 1;
-
-   p_fs->sectors_per_clu = p_bpb->sectors_per_clu;
-   p_fs->sectors_per_clu_bits = ilog2(p_bpb->sectors_per_clu);
-   p_fs->cluster_size_bits = p_fs->sectors_per_clu_bits +
- p_bd->sector_size_bits;
-   p_fs->cluster_size = 1 << p_fs->cluster_size_bits;
-
-   p_fs->num_FAT_sectors = GET16(p_bpb->num_fat_sectors);
-
-   p_fs->FAT1_start_sector = p_fs->PBR_sector + GET16(p_bpb->num_reserved);
-   if (p_bpb->num_fats == 1)
-   p_fs->FAT2_start_sector = p_fs->FAT1_start_sector;
-   else
-   p_fs->FAT2_start_sector = p_fs->FAT1_start_sector +
- p_fs->num_FAT_sectors;
-
-   p_fs->root_start_sector = p_fs->FAT2_start_sector +
- p_fs->num_FAT_sectors;
-   p_fs->data_start_sector = p_fs->root_start_sector + num_root_sectors;
-
-   p_fs->num_sectors = GET16(p_bpb->num_sectors);
-   if (p_fs->num_sectors == 0)
-   p_fs->num_sectors = GET32(p_bpb->num_huge_sectors);
-
-   num_reserved = p_fs->data_start_sector - p_fs->PBR_sector;

[PATCH 0/8] staging: exfat: Code cleanups

2019-10-22 Thread Valdis Kletnieks
Two main goals here - remove the code to mount FAT and VFAT filesystes,
and make a lot of functions static to reduce namespace pollution.

Valdis Kletnieks (8):
  staging: exfat: Clean up namespace pollution, part 1
  staging: exfat: Remove FAT/VFAT mount support, part 1
  staging: exfat: Remove FAT/VFAT mount support, part 2
  staging: exfat: Cleanup static entries in exfat.h
  staging: exfat: Clean up static definitions in exfat_cache.c
  staging: exfat: More static cleanups for exfat_core.c
  staging: exfat: Finished code movement for static cleanups in exfat_core.c
  staging: exfat: Update TODO

 drivers/staging/exfat/Kconfig   |9 -
 drivers/staging/exfat/TODO  |   20 +-
 drivers/staging/exfat/exfat.h   |  122 +-
 drivers/staging/exfat/exfat_cache.c |   94 +-
 drivers/staging/exfat/exfat_core.c  | 2162 ---
 drivers/staging/exfat/exfat_super.c |8 +-
 6 files changed, 690 insertions(+), 1725 deletions(-)

-- 
2.23.0



Re: [PATCH] phy-mvebu-a3700-utmi: Use devm_platform_ioremap_resource() in mvebu_a3700_utmi_phy_probe()

2019-10-22 Thread Kishon Vijay Abraham I


On 26/09/19 9:50 PM, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 26 Sep 2019 18:15:23 +0200
> 
> Simplify this function implementation by using a known wrapper function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

merged, thanks!

-Kishon

> ---
>  drivers/phy/marvell/phy-mvebu-a3700-utmi.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/phy/marvell/phy-mvebu-a3700-utmi.c 
> b/drivers/phy/marvell/phy-mvebu-a3700-utmi.c
> index ded900b06f5a..23bc3bf5c4c0 100644
> --- a/drivers/phy/marvell/phy-mvebu-a3700-utmi.c
> +++ b/drivers/phy/marvell/phy-mvebu-a3700-utmi.c
> @@ -216,20 +216,13 @@ static int mvebu_a3700_utmi_phy_probe(struct 
> platform_device *pdev)
>   struct device *dev = >dev;
>   struct mvebu_a3700_utmi *utmi;
>   struct phy_provider *provider;
> - struct resource *res;
> 
>   utmi = devm_kzalloc(dev, sizeof(*utmi), GFP_KERNEL);
>   if (!utmi)
>   return -ENOMEM;
> 
>   /* Get UTMI memory region */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "Missing UTMI PHY memory resource\n");
> - return -ENODEV;
> - }
> -
> - utmi->regs = devm_ioremap_resource(dev, res);
> + utmi->regs = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(utmi->regs))
>   return PTR_ERR(utmi->regs);
> 
> --
> 2.23.0
> 


Re: [PATCH] namespace: fix namespace.pl script to support relative paths

2019-10-22 Thread Masahiro Yamada
On Tue, Oct 1, 2019 at 5:49 AM Keller, Jacob E  wrote:
>
> > -Original Message-
> > From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> > Sent: Saturday, September 28, 2019 5:21 PM
> > To: Keller, Jacob E 
> > Cc: Randy Dunlap ; intel-wired-...@lists.osuosl.org; 
> > linux-
> > ker...@vger.kernel.org; linux-kbuild 
> > Subject: Re: [PATCH] namespace: fix namespace.pl script to support relative 
> > paths
> >
> > On Sat, Sep 28, 2019 at 8:30 AM Keller, Jacob E
> >  wrote:
> > >
> > > > -Original Message-
> > > > From: Randy Dunlap [mailto:rdun...@infradead.org]
> > > > Sent: Friday, September 27, 2019 4:12 PM
> > > > To: Keller, Jacob E 
> > > > Cc: intel-wired-...@lists.osuosl.org; linux-kernel@vger.kernel.org; 
> > > > linux-kbuild
> >  > > > kbu...@vger.kernel.org>; Masahiro Yamada 
> > > > Subject: Re: [PATCH] namespace: fix namespace.pl script to support 
> > > > relative paths
> > > >
> > > >
> > > > re: https://lore.kernel.org/lkml/20190129204319.15238-1-
> > jacob.e.kel...@intel.com/
> > > >
> > > > Did anything happen with this patch?
> > > >
> > > > Please send it to linux-kbu...@vger.kernel.org and
> > > > Cc: Masahiro Yamada 
> > > >
> > > > You can also add:
> > > > Acked-by: Randy Dunlap 
> > > > Tested-by: Randy Dunlap 
> > > >
> > > >
> > > > I was just about to fix this script but I decided to first see if 
> > > > anyone else
> > > > had already done so.  Thanks.
> > > >
> > > > --
> > > > ~Randy
> > >
> > > Done, thanks.
> > >
> > > Regards,
> > > Jake
> >
> >
> > Applied to linux/kbuild. Thanks.
> >
>
> Great, thanks!


This scripts has been 5-year broken,
and I did not see any complaint except from you.
So, I wonder how many people are using this.

Nor, do I understand how to use it.

Could you teach me a bit more about this script?



Something might be missing in my mind, but
I do not know how to use this script in a useful way.



It provides three checks.

[1] list_multiply_defined()

This warns multiple definition of functions.

The compiler would fail if it saw any multiple definition,
so the reports from this check are all false-positive.


[2] resolve_external_references()

This warns unresolved symbols.

The compiler would fail if it saw any unresolved symbol,
so the reports from this check are all false-positive, too.




[3] list_extra_externals

This warns symbols with no reference.

This potentially contains lots of false-positives.
For example, the core framework provides APIs, but if all drivers
are disabled, there is no user of those APIs.




I built the kernel with x86_64_defconfig,
and namespacecheck provides

1400 line reports for [1].
200 line reports for [2].
6800 line reports for [3].

Most of these seem false-positives.



How can I use it for the code improvement?

[3] might be still useful to find 'static' candidates,
but it would be difficult given the amount of the report.

-- 
Best Regards
Masahiro Yamada


Re: DMA: JZ4780: Add DMA driver for X1000.

2019-10-22 Thread Vinod Koul
On 23-10-19, 11:05, Zhou Yanjie wrote:
> 1.Add the DMA bindings for the X1000 SoC from Ingenic.
> 2.Add support for probing the dma-jz4780 driver on the
>   X1000 SoC from Ingenic.

The subsystem in dmaengine and not dma

Please resend with correct tags!

Thanks
-- 
~Vinod


Re: [next, v2] dmaengine: fsl-dpaa2-qdma: export the symbols

2019-10-22 Thread Vinod Koul
On 23-10-19, 12:56, Peng Ma wrote:
> The symbols were not exported leading to error:
> 
> WARNING: modpost: missing MODULE_LICENSE() in 
> drivers/dma/fsl-dpaa2-qdma/dpdmai.o
> see include/linux/module.h for more information
> GZIParch/arm64/boot/Image.gz
> ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_set_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_get_tx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_get_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_get_attributes" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [sub-make] Error 2
> 
> So export it.

Applied, thanks

-- 
~Vinod


Re: [alsa-devel] KASAN: slab-out-of-bounds Read in parse_term_proc_unit

2019-10-22 Thread Takashi Iwai
#syz dup: KASAN: slab-out-of-bounds Read in build_audio_procunit


[next, v2] dmaengine: fsl-dpaa2-qdma: export the symbols

2019-10-22 Thread Peng Ma
The symbols were not exported leading to error:

WARNING: modpost: missing MODULE_LICENSE() in 
drivers/dma/fsl-dpaa2-qdma/dpdmai.o
see include/linux/module.h for more information
GZIParch/arm64/boot/Image.gz
ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_set_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_get_tx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_get_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_get_attributes" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [sub-make] Error 2

So export it.

Signed-off-by: Peng Ma 
Reported-by: Anders Roxell 
---
Changed for v2:
- Rewrite the title and subject

 drivers/dma/fsl-dpaa2-qdma/dpdmai.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c 
b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
index fbc2b2f..f8a1f66 100644
--- a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
+++ b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright 2019 NXP
 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +91,7 @@ int dpdmai_open(struct fsl_mc_io *mc_io, u32 cmd_flags,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_open);
 
 /**
  * dpdmai_close() - Close the control session of the object
@@ -113,6 +115,7 @@ int dpdmai_close(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_close);
 
 /**
  * dpdmai_create() - Create the DPDMAI object
@@ -177,6 +180,7 @@ int dpdmai_enable(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_enable);
 
 /**
  * dpdmai_disable() - Disable the DPDMAI, stop sending and receiving frames.
@@ -197,6 +201,7 @@ int dpdmai_disable(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_disable);
 
 /**
  * dpdmai_reset() - Reset the DPDMAI, returns the object to initial state.
@@ -217,6 +222,7 @@ int dpdmai_reset(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_reset);
 
 /**
  * dpdmai_get_attributes() - Retrieve DPDMAI attributes.
@@ -252,6 +258,7 @@ int dpdmai_get_attributes(struct fsl_mc_io *mc_io, u32 
cmd_flags,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_get_attributes);
 
 /**
  * dpdmai_set_rx_queue() - Set Rx queue configuration
@@ -285,6 +292,7 @@ int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io, u32 
cmd_flags, u16 token,
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_set_rx_queue);
 
 /**
  * dpdmai_get_rx_queue() - Retrieve Rx queue attributes.
@@ -325,6 +333,7 @@ int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io, u32 
cmd_flags, u16 token,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_get_rx_queue);
 
 /**
  * dpdmai_get_tx_queue() - Retrieve Tx queue attributes.
@@ -364,3 +373,6 @@ int dpdmai_get_tx_queue(struct fsl_mc_io *mc_io, u32 
cmd_flags,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_get_tx_queue);
+
+MODULE_LICENSE("GPL v2");
-- 
2.9.5



[BUGFIX PATCH v3 2/5] selftests: vm: Build/Run 64bit tests only on 64bit arch

2019-10-22 Thread Masami Hiramatsu
Some virtual address range tests requires 64bit address space,
and we can not build and run those tests on the 32bit machine.

Filter the 64bit architectures in Makefile and run_vmtests,
so that those tests are built/run only on 64bit archs.

Signed-off-by: Masami Hiramatsu 
Cc: Anshuman Khandual 
Cc: Aneesh Kumar K.V 
---
 tools/testing/selftests/vm/Makefile|5 +
 tools/testing/selftests/vm/run_vmtests |   10 ++
 2 files changed, 15 insertions(+)

diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index 9534dc2bc929..7f9a8a8c31da 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 # Makefile for vm selftests
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/')
 
 CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
 LDLIBS = -lrt
@@ -16,8 +18,11 @@ TEST_GEN_FILES += on-fault-limit
 TEST_GEN_FILES += thuge-gen
 TEST_GEN_FILES += transhuge-stress
 TEST_GEN_FILES += userfaultfd
+
+ifneq (,$(filter $(ARCH),arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 
sparc64 x86_64))
 TEST_GEN_FILES += va_128TBswitch
 TEST_GEN_FILES += virtual_address_range
+endif
 
 TEST_PROGS := run_vmtests
 
diff --git a/tools/testing/selftests/vm/run_vmtests 
b/tools/testing/selftests/vm/run_vmtests
index 951c507a27f7..a692ea828317 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -58,6 +58,14 @@ else
exit 1
 fi
 
+#filter 64bit architectures
+ARCH64STR="arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64"
+if [ -z $ARCH ]; then
+  ARCH=`uname -m 2>/dev/null | sed -e 's/aarch64.*/arm64/'`
+fi
+VADDR64=0
+echo "$ARCH64STR" | grep $ARCH && VADDR64=1
+
 mkdir $mnt
 mount -t hugetlbfs none $mnt
 
@@ -189,6 +197,7 @@ else
echo "[PASS]"
 fi
 
+if [ $VADDR64 -ne 0 ]; then
 echo "-"
 echo "running virtual_address_range"
 echo "-"
@@ -210,6 +219,7 @@ if [ $? -ne 0 ]; then
 else
 echo "[PASS]"
 fi
+fi # VADDR64
 
 echo ""
 echo "running vmalloc stability smoke test"



[BUGFIX PATCH v3 4/5] selftests: net: Fix printf format warnings on arm

2019-10-22 Thread Masami Hiramatsu
Fix printf format warnings on arm (and other 32bit arch).

 - udpgso.c and udpgso_bench_tx use %lu for size_t but it
   should be unsigned long long on 32bit arch.

 - so_txtime.c uses %ld for int64_t, but it should be
   unsigned long long on 32bit arch.

Signed-off-by: Masami Hiramatsu 
Cc: Willem de Bruijn 
Cc: David S. Miller 
---
 tools/testing/selftests/net/so_txtime.c   |4 ++--
 tools/testing/selftests/net/udpgso.c  |3 ++-
 tools/testing/selftests/net/udpgso_bench_tx.c |3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/so_txtime.c 
b/tools/testing/selftests/net/so_txtime.c
index 53f598f06647..34df4c8882af 100644
--- a/tools/testing/selftests/net/so_txtime.c
+++ b/tools/testing/selftests/net/so_txtime.c
@@ -105,8 +105,8 @@ static void do_recv_one(int fdr, struct timed_send *ts)
tstop = (gettime_ns() - glob_tstart) / 1000;
texpect = ts->delay_us >= 0 ? ts->delay_us : 0;
 
-   fprintf(stderr, "payload:%c delay:%ld expected:%ld (us)\n",
-   rbuf[0], tstop, texpect);
+   fprintf(stderr, "payload:%c delay:%lld expected:%lld (us)\n",
+   rbuf[0], (long long)tstop, (long long)texpect);
 
if (rbuf[0] != ts->data)
error(1, 0, "payload mismatch. expected %c", ts->data);
diff --git a/tools/testing/selftests/net/udpgso.c 
b/tools/testing/selftests/net/udpgso.c
index b8265ee9923f..cab334e51ac1 100644
--- a/tools/testing/selftests/net/udpgso.c
+++ b/tools/testing/selftests/net/udpgso.c
@@ -448,7 +448,8 @@ static bool __send_one(int fd, struct msghdr *msg, int 
flags)
if (ret == -1)
error(1, errno, "sendmsg");
if (ret != msg->msg_iov->iov_len)
-   error(1, 0, "sendto: %d != %lu", ret, msg->msg_iov->iov_len);
+   error(1, 0, "sendto: %d != %llu", ret,
+   (unsigned long long)msg->msg_iov->iov_len);
if (msg->msg_flags)
error(1, 0, "sendmsg: return flags 0x%x\n", msg->msg_flags);
 
diff --git a/tools/testing/selftests/net/udpgso_bench_tx.c 
b/tools/testing/selftests/net/udpgso_bench_tx.c
index ada99496634a..17512a43885e 100644
--- a/tools/testing/selftests/net/udpgso_bench_tx.c
+++ b/tools/testing/selftests/net/udpgso_bench_tx.c
@@ -405,7 +405,8 @@ static int send_udp_segment(int fd, char *data)
if (ret == -1)
error(1, errno, "sendmsg");
if (ret != iov.iov_len)
-   error(1, 0, "sendmsg: %u != %lu\n", ret, iov.iov_len);
+   error(1, 0, "sendmsg: %u != %llu\n", ret,
+   (unsigned long long)iov.iov_len);
 
return 1;
 }



[BUGFIX PATCH v3 5/5] selftests: sync: Fix cast warnings on arm

2019-10-22 Thread Masami Hiramatsu
Fix warnings on __u64 and pointer translation on arm and
other 32bit architectures. Since the pointer is 32bits on
those archs, we should not directly cast those types.

Signed-off-by: Masami Hiramatsu 
Cc: Emilio López 
---
 tools/testing/selftests/sync/sync.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/sync/sync.c 
b/tools/testing/selftests/sync/sync.c
index f3d599f249b9..7741c0518d18 100644
--- a/tools/testing/selftests/sync/sync.c
+++ b/tools/testing/selftests/sync/sync.c
@@ -109,7 +109,7 @@ static struct sync_file_info *sync_file_info(int fd)
return NULL;
}
 
-   info->sync_fence_info = (uint64_t)fence_info;
+   info->sync_fence_info = (uint64_t)(unsigned long)fence_info;
 
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
if (err < 0) {
@@ -124,7 +124,7 @@ static struct sync_file_info *sync_file_info(int fd)
 
 static void sync_file_info_free(struct sync_file_info *info)
 {
-   free((void *)info->sync_fence_info);
+   free((void *)(unsigned long)info->sync_fence_info);
free(info);
 }
 
@@ -152,7 +152,7 @@ int sync_fence_count_with_status(int fd, int status)
if (!info)
return -1;
 
-   fence_info = (struct sync_fence_info *)info->sync_fence_info;
+   fence_info = (struct sync_fence_info *)(unsigned 
long)info->sync_fence_info;
for (i = 0 ; i < info->num_fences ; i++) {
if (fence_info[i].status == status)
count++;



[BUGFIX PATCH v3 3/5] selftests: net: Use size_t and ssize_t for counting file size

2019-10-22 Thread Masami Hiramatsu
Use size_t and ssize_t correctly for counting send file size
instead of unsigned long and long, because long is 32bit on
32bit arch, which is not enough for counting long file size (>4GB).

Signed-off-by: Masami Hiramatsu 
Cc: Eric Dumazet 
Cc: David S. Miller 
---
 tools/testing/selftests/net/tcp_mmap.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/tcp_mmap.c 
b/tools/testing/selftests/net/tcp_mmap.c
index 31ced79f4f25..33035d1b3f6d 100644
--- a/tools/testing/selftests/net/tcp_mmap.c
+++ b/tools/testing/selftests/net/tcp_mmap.c
@@ -71,7 +71,7 @@
 #define MSG_ZEROCOPY0x400
 #endif
 
-#define FILE_SZ (1UL << 35)
+#define FILE_SZ (1ULL << 35)
 static int cfg_family = AF_INET6;
 static socklen_t cfg_alen = sizeof(struct sockaddr_in6);
 static int cfg_port = 8787;
@@ -155,7 +155,7 @@ void *child_thread(void *arg)
socklen_t zc_len = sizeof(zc);
int res;
 
-   zc.address = (__u64)addr;
+   zc.address = (__u64)((unsigned long)addr);
zc.length = chunk_size;
zc.recv_skip_hint = 0;
res = getsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE,
@@ -302,7 +302,7 @@ int main(int argc, char *argv[])
 {
struct sockaddr_storage listenaddr, addr;
unsigned int max_pacing_rate = 0;
-   unsigned long total = 0;
+   size_t total = 0;
char *host = NULL;
int fd, c, on = 1;
char *buffer;
@@ -417,7 +417,7 @@ int main(int argc, char *argv[])
zflg = 0;
}
while (total < FILE_SZ) {
-   long wr = FILE_SZ - total;
+   ssize_t wr = FILE_SZ - total;
 
if (wr > chunk_size)
wr = chunk_size;



[BUGFIX PATCH v3 1/5] selftests: proc: Make va_max 1MB

2019-10-22 Thread Masami Hiramatsu
Currently proc-self-map-files-002.c sets va_max (max test address
of user virtual address) to 4GB, but it is too big for 32bit
arch and 1UL << 32 is overflow on 32bit long.
Also since this value should be enough bigger than vm.mmap_min_addr
(64KB or 32KB by default), 1MB should be enough.

Make va_max 1MB unconditionally.

Signed-off-by: Masami Hiramatsu 
Cc: Alexey Dobriyan 
---
 Changes in v3:
  - Make the va_max 1MB unconditionally, according to Alexey's comment.
 Changes in v2:
  - Make the va_max 1GB according to Alexey's comment.
---
 .../selftests/proc/proc-self-map-files-002.c   |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/proc/proc-self-map-files-002.c 
b/tools/testing/selftests/proc/proc-self-map-files-002.c
index 47b7473dedef..e6aa00a183bc 100644
--- a/tools/testing/selftests/proc/proc-self-map-files-002.c
+++ b/tools/testing/selftests/proc/proc-self-map-files-002.c
@@ -47,7 +47,11 @@ static void fail(const char *fmt, unsigned long a, unsigned 
long b)
 int main(void)
 {
const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
-   const unsigned long va_max = 1UL << 32;
+   /*
+* va_max must be enough bigger than vm.mmap_min_addr, which is
+* 64KB/32KB by default. (depends on CONFIG_LSM_MMAP_MIN_ADDR)
+*/
+   const unsigned long va_max = 1UL << 20;
unsigned long va;
void *p;
int fd;



[BUGFIX PATCH v3 0/5] selftests: Fixes for 32bit arch

2019-10-22 Thread Masami Hiramatsu
Hi,

Here are the 3rd version of kselftest fixes some on 32bit arch
(e.g. arm)

In this version, I updated [1/5] to make va_max 1MB unconditionally
according to Alexey's comment.

When I built the ksefltest on arm, I hit some 32bit related warnings.
Here are the patches to fix those issues.


 - [1/5] va_max was set 2^32 even on 32bit arch. This can make
va_max == 0 and always fail. Make it 1GB unconditionally.
 - [2/5] Some VM tests requires 64bit user space, which should
not run on 32bit arch.
 - [3/5] For counting the size of large file, we should use
size_t instead of unsinged long.
 - [4/5] Gcc warns printf format for size_t and int64_t on
32bit arch. Use %llu and cast it.
 - [5/5] Gcc warns __u64 and pointer type castings. It should
once translated to unsigned long.

Thank you,

---

Masami Hiramatsu (5):
  selftests: proc: Make va_max 1MB
  selftests: vm: Build/Run 64bit tests only on 64bit arch
  selftests: net: Use size_t and ssize_t for counting file size
  selftests: net: Fix printf format warnings on arm
  selftests: sync: Fix cast warnings on arm


 tools/testing/selftests/net/so_txtime.c|4 ++--
 tools/testing/selftests/net/tcp_mmap.c |8 
 tools/testing/selftests/net/udpgso.c   |3 ++-
 tools/testing/selftests/net/udpgso_bench_tx.c  |3 ++-
 .../selftests/proc/proc-self-map-files-002.c   |6 +-
 tools/testing/selftests/sync/sync.c|6 +++---
 tools/testing/selftests/vm/Makefile|5 +
 tools/testing/selftests/vm/run_vmtests |   10 ++
 8 files changed, 33 insertions(+), 12 deletions(-)

--
Masami Hiramatsu (Linaro) 


linux-next: Tree for Oct 23

2019-10-22 Thread Stephen Rothwell
Hi all,

Changes since 20191022:

Non-merge commits (relative to Linus' tree): 5530
 5340 files changed, 192671 insertions(+), 90844 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 310 trees (counting Linus' and 78 trees of bug
fix patches pending for the current merge release).

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 (3b7c59a1950c Merge tag 'pinctrl-v5.4-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl)
Merging fixes/master (54ecb8f7028c Linux 5.4-rc1)
Merging kbuild-current/fixes (7d194c2100ad Linux 5.4-rc4)
Merging arc-current/for-curr (5effc09c4907 ARC: perf: Accommodate big-endian 
CPU)
Merging arm-current/fixes (39f4d4410484 Merge branch 'misc' into fixes)
Merging arm-soc-fixes/arm/fixes (cc3fafdaf5cb Merge tag 
'arm-soc/for-5.4/devicetree-fixes-part2' of 
https://github.com/Broadcom/stblinux into arm/fixes)
Merging arm64-fixes/for-next/fixes (777d062e5bee Merge branch 'errata/tx2-219' 
into for-next/fixes)
Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache())
Merging powerpc-fixes/fixes (d10f60ae27d2 powerpc/32s: fix 
allow/prevent_user_access() when crossing segment boundaries.)
Merging s390-fixes/fixes (ac49303d9ef0 s390/kaslr: add support for 
R_390_GLOB_DAT relocation type)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (b30605319794 r8152: add device id for Lenovo ThinkPad USB-C 
Dock Gen 2)
Merging bpf/master (cd7455f1013e bpf: Fix use after free in subprog's jited 
symbol removal)
Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer 
overflow in taprio_set_picos_per_byte)
Merging netfilter/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig 
help text)
Merging ipvs/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help 
text)
Merging wireless-drivers/master (d79749f7716d ath10k: fix latency issue for 
QCA988x)
Merging mac80211/master (82ad862115c2 Merge branch 'smc-fixes')
Merging rdma-fixes/for-rc (777a8b32bc0f IB/core: Use rdma_read_gid_l2_fields to 
compare GID L2 fields)
Merging sound-current/for-linus (ba8bf0967a15 ALSA: usb-audio: Fix copy 
error in the validator)
Merging sound-asoc-fixes/for-linus (38dd8f172b2d Merge branch 'asoc-5.4' into 
asoc-linus)
Merging regmap-fixes/for-linus (da0c9ea146cb Linux 5.4-rc2)
Merging regulator-fixes/for-linus (d730b0dd62b4 Merge branch 'regulator-5.4' 
into regulator-linus)
Merging spi-fixes/for-linus (44885b636ef0 Merge branch 'spi-5.4' into spi-linus)
Merging pci-current/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging driver-core.current/driver-core-linus (82af5b660967 sysfs: Fixes 
__BIN_ATTR_WO() macro)
Merging tty.current/tty-linus (f50b6805dbb9 8250-men-mcb: fix error checking 
when get_num_ports returns -ENODEV)
Merging usb.current/usb-linus (9794476942d8 usb: cdns3: Error out if 
USB_DR_MODE_UNKNOWN in cdns3_core_init_role())
Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix 
races between fsg_disable and fsg_set_alt)
Merging usb-serial-fixes/usb-linus (bc25770f00d3 USB: serial: ti_usb_3410_5052: 
clean up serial data access)
Merging usb-chipidea-fixes/ci-for-usb-stable (16009db47c51 usb: chipidea: udc: 
workaround for en

Re: [BUGFIX PATCH v2 1/5] selftests: proc: Make va_max 1GB on 32bit arch

2019-10-22 Thread Masami Hiramatsu
On Wed, 23 Oct 2019 10:56:18 +0900
Masami Hiramatsu  wrote:

> On Mon, 21 Oct 2019 20:30:53 +0300
> Alexey Dobriyan  wrote:
> 
> > On Mon, Oct 21, 2019 at 05:28:09PM +0900, Masami Hiramatsu wrote:
> > > Currently proc-self-map-files-002.c sets va_max (max test address
> > > of user virtual address) to 4GB, but it is too big for 32bit
> > > arch and 1UL << 32 is overflow on 32bit long.
> > > 
> > > Make va_max 1GB on 32bit arch like i386 and arm.
> > 
> > > +#if __BITS_PER_LONG == 32
> > > +# define VA_MAX (1UL << 30)
> > > +#elif __BITS_PER_LONG == 64
> > > +# define VA_MAX (1UL << 32)
> > > +#else
> > > +# define VA_MAX 0
> > > +#endif
> > > +
> > >  int main(void)
> > >  {
> > >   const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
> > > - const unsigned long va_max = 1UL << 32;
> > > + const unsigned long va_max = VA_MAX;
> > 
> > No, just make it like 1MB unconditionally.
> 
> Ah, I sse. BTW, would you mean 1GB?

I understand that 1MB will be good enough, since vm.mmap_min_addr is
64KB by default (except for arm/arm64 which is 32KB).
OK, I'll update and resend.

Thank you,

> 
> > This is not intended to cover all address space, just large enough part
> > (larger than reasonable vm.mmap_min_addr)
> 
> Then, should we better to check the /proc/sys/vm/mmap_min_addr?
> 
> Thank you,
> 
> -- 
> Masami Hiramatsu 


-- 
Masami Hiramatsu 


Re: [PATCH] clocksource/drivers: Fix memory leak in ttc_setup_clockevent

2019-10-22 Thread Navid Emamdoost
Thanks for the feedback, I updated this patch and sent v2.
Also, I submitted a patch to fix the error handling path in
ttc_setup_clocksource(). Here is the link to it:
https://lore.kernel.org/patchwork/patch/1143242/

On Tue, Oct 22, 2019 at 3:51 AM Michal Simek  wrote:
>
> On 22. 10. 19 10:26, Markus Elfring wrote:
> >> In the impelementation of ttc_setup_clockevent() the allocated memory
> >> for ttcce should be released if clk_notifier_register() fails.
> >
> > * Please avoid the copying of typos from previous change descriptions.
> >
> > * Under which circumstances will an “imperative mood” matter for you here?
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=7d194c2100ad2a6dded545887d02754948ca5241#n151
> >
> >
> >> +++ b/drivers/clocksource/timer-cadence-ttc.c
> >> @@ -424,6 +424,7 @@ static int __init ttc_setup_clockevent(struct clk *clk,
> >>  >ttc.clk_rate_change_nb);
> >>  if (err) {
> >>  pr_warn("Unable to register clock notifier.\n");
> >> +kfree(ttcce);
> >>  return err;
> >>  }
> >
> > This addition looks correct.
> > But I would prefer to move such exception handling code to the end of
> > this function implementation so that duplicate source code will be reduced.
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=7d194c2100ad2a6dded545887d02754948ca5241#n450
>
> Just a note. Maybe you should also consider to fix this error path in
> ttc_setup_clocksource() when notifier also can fail that there is no
> need to continue with code execution.
>
> Thanks,
> Michal



-- 
Navid.


[PATCH] clocksource/drivers: Fix error handling in ttc_setup_clocksource

2019-10-22 Thread Navid Emamdoost
In the implementation of ttc_setup_clocksource() when
clk_notifier_register() fails the execution should go to error handling.
Additionally, to avoid memory leak the allocated memory for ttccs should
be released, too. So, goto error handling to release the memory and
return.

Fixes: e932900a3279 ("arm: zynq: Use standard timer binding")
Signed-off-by: Navid Emamdoost 
---
 drivers/clocksource/timer-cadence-ttc.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/timer-cadence-ttc.c 
b/drivers/clocksource/timer-cadence-ttc.c
index 88fe2e9ba9a3..035e16bc17d3 100644
--- a/drivers/clocksource/timer-cadence-ttc.c
+++ b/drivers/clocksource/timer-cadence-ttc.c
@@ -328,10 +328,8 @@ static int __init ttc_setup_clocksource(struct clk *clk, 
void __iomem *base,
ttccs->ttc.clk = clk;
 
err = clk_prepare_enable(ttccs->ttc.clk);
-   if (err) {
-   kfree(ttccs);
-   return err;
-   }
+   if (err)
+   goto release_ttccs;
 
ttccs->ttc.freq = clk_get_rate(ttccs->ttc.clk);
 
@@ -341,8 +339,10 @@ static int __init ttc_setup_clocksource(struct clk *clk, 
void __iomem *base,
 
err = clk_notifier_register(ttccs->ttc.clk,
>ttc.clk_rate_change_nb);
-   if (err)
+   if (err) {
pr_warn("Unable to register clock notifier.\n");
+   goto release_ttccs;
+   }
 
ttccs->ttc.base_addr = base;
ttccs->cs.name = "ttc_clocksource";
@@ -363,16 +363,18 @@ static int __init ttc_setup_clocksource(struct clk *clk, 
void __iomem *base,
 ttccs->ttc.base_addr + TTC_CNT_CNTRL_OFFSET);
 
err = clocksource_register_hz(>cs, ttccs->ttc.freq / PRESCALE);
-   if (err) {
-   kfree(ttccs);
-   return err;
-   }
+   if (err)
+   goto release_ttccs;
 
ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
sched_clock_register(ttc_sched_clock_read, timer_width,
 ttccs->ttc.freq / PRESCALE);
 
return 0;
+
+release_ttccs:
+   kfree(ttccs);
+   return err;
 }
 
 static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,
-- 
2.17.1



Re: [PATCH 1/2] configs: ARM: omap2plus: Enable OMAP3_THERMAL

2019-10-22 Thread H. Nikolaus Schaller


> Am 23.10.2019 um 00:19 schrieb Tony Lindgren :
> 
> * Adam Ford  [191022 19:01]:
>> On Tue, Oct 22, 2019 at 11:22 AM Tony Lindgren  wrote:
>>> 
>>> Hi,
>>> 
>>> * Adam Ford  [191007 15:06]:
 The some in the OMAP3 family have a bandgap thermal sensor, but
 omap2plus has it disabled.
 
 This patch enables the OMAP3_THERMAL by default like the rest of
 the OMAP family.
>>> 
>>> Looks like this breaks off mode during idle for omap3, and that's
>>> probably why it never got enabled. The difference in power
>>> consumption during idle is about 7mW vs 32mW for the SoC as
>>> measured from torpedo shunt for main_battery_som.
>>> 
>>> I think the right fix might be simply to add handling for
>>> CPU_CLUSTER_PM_ENTER to the related thermal driver to disable
>>> it during idle like we have for gpio-omap.c for example.
>> 
>> I am not sure I know where to start on fixing that issue.  Would you
>> entertain enabling the driver if we set the device tree to 'disabled'
>> by default?  This way if people want to to use it, it can be enabled
>> on a per-device option.  Once the power stuff gets resolved, we might
>> be able to enable it by default.  For people who are planning on using
>> the DM3730 @ 1GHz in high temp environments, I am not sure they'll
>> care about low power.
> 
> They should both work fine together though. They are not mutually
> exclusive features.
> 
>> I'll try to look into it when I have time, but I was hoping a
>> compromise might be a reasonable work-around.
> 
> It should be hopefully a trivial fix.. I have not looked at the
> driver code though.

If I am taken right, it is the drivers/thermal/ti-soc-thermal/ti-*.c
which is a common driver for omap3, omap4, omap5. They only differ
in the thermal data and which registers and bits are used to access
the ADC.

So is this problem with off mode also known for omap4 and omap5?

BR,
Nikolaus



Re: KMSAN: uninit-value in build_audio_procunit

2019-10-22 Thread Takashi Iwai
#syz dup: KASAN: slab-out-of-bounds Read in build_audio_procunit

The fix is on the way...


[PATCH v2] clocksource/drivers: Fix memory leak in ttc_setup_clockevent

2019-10-22 Thread Navid Emamdoost
In the implementation of ttc_setup_clockevent() release the allocated
memory for ttcce if clk_notifier_register() fails.

Fixes: 70504f311d4b ("clocksource/drivers/cadence_ttc: Convert init function to 
return error")
Signed-off-by: Navid Emamdoost 
---
Changes in v2:
- Added goto label for error handling
- Update description and fix typo

 drivers/clocksource/timer-cadence-ttc.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/timer-cadence-ttc.c 
b/drivers/clocksource/timer-cadence-ttc.c
index 88fe2e9ba9a3..0caacbc67102 100644
--- a/drivers/clocksource/timer-cadence-ttc.c
+++ b/drivers/clocksource/timer-cadence-ttc.c
@@ -411,10 +411,8 @@ static int __init ttc_setup_clockevent(struct clk *clk,
ttcce->ttc.clk = clk;
 
err = clk_prepare_enable(ttcce->ttc.clk);
-   if (err) {
-   kfree(ttcce);
-   return err;
-   }
+   if (err)
+   goto release_ttcce;
 
ttcce->ttc.clk_rate_change_nb.notifier_call =
ttc_rate_change_clockevent_cb;
@@ -424,7 +422,7 @@ static int __init ttc_setup_clockevent(struct clk *clk,
>ttc.clk_rate_change_nb);
if (err) {
pr_warn("Unable to register clock notifier.\n");
-   return err;
+   goto release_ttcce;
}
 
ttcce->ttc.freq = clk_get_rate(ttcce->ttc.clk);
@@ -453,15 +451,18 @@ static int __init ttc_setup_clockevent(struct clk *clk,
 
err = request_irq(irq, ttc_clock_event_interrupt,
  IRQF_TIMER, ttcce->ce.name, ttcce);
-   if (err) {
-   kfree(ttcce);
-   return err;
-   }
+   if (err)
+   goto release_ttcce;
 
clockevents_config_and_register(>ce,
ttcce->ttc.freq / PRESCALE, 1, 0xfffe);
 
return 0;
+
+release_ttcce:
+
+   kfree(ttcce);
+   return err;
 }
 
 /**
-- 
2.17.1



Re: [PATCH] dmaengine: fsl-dpaa2-qdma: Fixed build error when enable dpaa2 qdma module driver

2019-10-22 Thread Vinod Koul
Hi Peng,

On 23-10-19, 10:19, Peng Ma wrote:

A patch title should detail the change it is doing so a better patch
title would be: "dmaengine: fsl-dpaa2-qdma: export the symbols"

> Fixed the following error:
> WARNING: modpost: missing MODULE_LICENSE() in 
> drivers/dma/fsl-dpaa2-qdma/dpdmai.o
> see include/linux/module.h for more information
> GZIParch/arm64/boot/Image.gz
> ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_set_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_get_tx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_get_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_get_attributes" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
> undefined!
> ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [sub-make] Error 2

And here in the log, you should say the symbols were not exported
leading to error 

So export it

> 
> Signed-off-by: Peng Ma 
> Reported-by: Anders Roxell 
> ---
>  drivers/dma/fsl-dpaa2-qdma/dpdmai.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c 
> b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
> index fbc2b2f..f8a1f66 100644
> --- a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
> +++ b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  // Copyright 2019 NXP
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -90,6 +91,7 @@ int dpdmai_open(struct fsl_mc_io *mc_io, u32 cmd_flags,
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_open);
>  
>  /**
>   * dpdmai_close() - Close the control session of the object
> @@ -113,6 +115,7 @@ int dpdmai_close(struct fsl_mc_io *mc_io, u32 cmd_flags, 
> u16 token)
>   /* send command to mc*/
>   return mc_send_command(mc_io, );
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_close);
>  
>  /**
>   * dpdmai_create() - Create the DPDMAI object
> @@ -177,6 +180,7 @@ int dpdmai_enable(struct fsl_mc_io *mc_io, u32 cmd_flags, 
> u16 token)
>   /* send command to mc*/
>   return mc_send_command(mc_io, );
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_enable);
>  
>  /**
>   * dpdmai_disable() - Disable the DPDMAI, stop sending and receiving frames.
> @@ -197,6 +201,7 @@ int dpdmai_disable(struct fsl_mc_io *mc_io, u32 
> cmd_flags, u16 token)
>   /* send command to mc*/
>   return mc_send_command(mc_io, );
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_disable);
>  
>  /**
>   * dpdmai_reset() - Reset the DPDMAI, returns the object to initial state.
> @@ -217,6 +222,7 @@ int dpdmai_reset(struct fsl_mc_io *mc_io, u32 cmd_flags, 
> u16 token)
>   /* send command to mc*/
>   return mc_send_command(mc_io, );
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_reset);
>  
>  /**
>   * dpdmai_get_attributes() - Retrieve DPDMAI attributes.
> @@ -252,6 +258,7 @@ int dpdmai_get_attributes(struct fsl_mc_io *mc_io, u32 
> cmd_flags,
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_get_attributes);
>  
>  /**
>   * dpdmai_set_rx_queue() - Set Rx queue configuration
> @@ -285,6 +292,7 @@ int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io, u32 
> cmd_flags, u16 token,
>   /* send command to mc*/
>   return mc_send_command(mc_io, );
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_set_rx_queue);
>  
>  /**
>   * dpdmai_get_rx_queue() - Retrieve Rx queue attributes.
> @@ -325,6 +333,7 @@ int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io, u32 
> cmd_flags, u16 token,
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_get_rx_queue);
>  
>  /**
>   * dpdmai_get_tx_queue() - Retrieve Tx queue attributes.
> @@ -364,3 +373,6 @@ int dpdmai_get_tx_queue(struct fsl_mc_io *mc_io, u32 
> cmd_flags,
>  
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(dpdmai_get_tx_queue);
> +
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.9.5

-- 
~Vinod


Re: [PATCH 3/3] x86/ftrace: Use text_poke()

2019-10-22 Thread Andy Lutomirski
On Tue, Oct 22, 2019 at 4:49 PM Alexei Starovoitov
 wrote:
>
> On Tue, Oct 22, 2019 at 03:45:26PM -0700, Andy Lutomirski wrote:
> >
> >
> > >> On Oct 22, 2019, at 2:58 PM, Alexei Starovoitov 
> > >>  wrote:
> > >>
> > >> On Tue, Oct 22, 2019 at 05:04:30PM -0400, Steven Rostedt wrote:
> > >> I gave a solution for this. And that is to add another flag to allow
> > >> for just the minimum to change the ip. And we can even add another flag
> > >> to allow for changing the stack if needed (to emulate a call with the
> > >> same parameters).
> > >
> > > your solution is to reduce the overhead.
> > > my solution is to remove it competely. See the difference?
> > >
> > >> By doing this work, live kernel patching will also benefit. Because it
> > >> is also dealing with the unnecessary overhead of saving regs.
> > >> And we could possibly even have kprobes benefit from this if a kprobe
> > >> doesn't need full regs.
> > >
> > > Neither of two statements are true. The per-function generated trampoline
> > > I'm talking about is bpf specific. For a function with two arguments it's 
> > > just:
> > > push rbp
> > > mov rbp, rsp
> > > push rdi
> > > push rsi
> > > lea  rdi,[rbp-0x10]
> > > call jited_bpf_prog
> > > pop rsi
> > > pop rdi
> > > leave
> > > ret
> >
> > Why are you saving rsi?  You said upthread that you’re saving the args, but 
> > rsi is already available in rsi.
>
> because rsi is caller saved. The above example is for probing something
> like tcp_set_state(struct sock *sk, int state) that everyone used to
> kprobe until we got a tracepoint there.
> The main bpf prog has only one argument R1 == rdi on x86,
> but it's allowed to clobber all caller saved regs.
> Just like x86 function that accepts one argument in rdi can clobber rsi and 
> others.
> So it's essential to save 'sk' and 'state' for tcp_set_state()
> to continue as nothing happened.

Oh, right, you're hijacking the very first instruction, so you know
that the rest of the arg regs as well as rax are unused.

But I find it hard to believe that this is a particularly meaningful
optimization compared to the version that saves all the C-clobbered
registers.  Steven,

Also, Alexei, are you testing on a CONFIG_FRAME_POINTER=y kernel?  The
ftrace code has a somewhat nasty special case to make
CONFIG_FRAME_POINTER=y work right, and your example trampoline does
not but arguably should have exaclty the same fixup.  For good
performance, you should be using CONFIG_FRAME_POINTER=n.

Steven, with your benchmark, could you easily make your actual ftrace
hook do nothing at all and get a perf report on the result (i.e. call
the traced function in a loop a bunch of times under perf record -e
cycles or similar)?  It would be interesting to see exactly what
trampoline code you're generating and just how bad it is.  ISTM it
should be possible to squeeze very good performance out of ftrace.  I
suppose you could also have a fancier mode than just "IP" that
specifies that the caller knows exactly which registers are live and
what they are.  Then you could generate code that's exactly as good as
Alexei's.


[PATCH v1 1/2] scsi: ufs: Introduce a vops for resetting host controller

2019-10-22 Thread Can Guo
Some UFS host controllers need their specific implementations of resetting
to get them into a good state. Provide a new vops to allow the platform
driver to implement this own reset operation.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 16 
 drivers/scsi/ufs/ufshcd.h | 10 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c28c144..161e3c4 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3859,6 +3859,14 @@ static int ufshcd_link_recovery(struct ufs_hba *hba)
ufshcd_set_eh_in_progress(hba);
spin_unlock_irqrestore(hba->host->host_lock, flags);
 
+   ret = ufshcd_vops_full_reset(hba);
+   if (ret)
+   dev_warn(hba->dev, "%s: full reset returned %d\n",
+ __func__, ret);
+
+   /* Reset the attached device */
+   ufshcd_vops_device_reset(hba);
+
ret = ufshcd_host_reset_and_restore(hba);
 
spin_lock_irqsave(hba->host->host_lock, flags);
@@ -6241,6 +6249,11 @@ static int ufshcd_reset_and_restore(struct ufs_hba *hba)
int retries = MAX_HOST_RESET_RETRIES;
 
do {
+   err = ufshcd_vops_full_reset(hba);
+   if (err)
+   dev_warn(hba->dev, "%s: full reset returned %d\n",
+   __func__, err);
+
/* Reset the attached device */
ufshcd_vops_device_reset(hba);
 
@@ -8384,6 +8397,9 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
goto exit_gating;
}
 
+   /* Reset controller to power on reset (POR) state */
+   ufshcd_vops_full_reset(hba);
+
/* Reset the attached device */
ufshcd_vops_device_reset(hba);
 
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index e0fe247..253b9ea 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -296,6 +296,8 @@ struct ufs_pwr_mode_info {
  * @apply_dev_quirks: called to apply device specific quirks
  * @suspend: called during host controller PM callback
  * @resume: called during host controller PM callback
+ * @full_reset: called for handling variant specific implementations of
+ *  resetting the hci
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
  * @device_reset: called to issue a reset pulse on the UFS device
@@ -325,6 +327,7 @@ struct ufs_hba_variant_ops {
int (*apply_dev_quirks)(struct ufs_hba *);
int (*suspend)(struct ufs_hba *, enum ufs_pm_op);
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
+   int (*full_reset)(struct ufs_hba *hba);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
void(*device_reset)(struct ufs_hba *hba);
@@ -1076,6 +1079,13 @@ static inline int ufshcd_vops_resume(struct ufs_hba 
*hba, enum ufs_pm_op op)
return 0;
 }
 
+static inline int ufshcd_vops_full_reset(struct ufs_hba *hba)
+{
+   if (hba->vops && hba->vops->full_reset)
+   return hba->vops->full_reset(hba);
+   return 0;
+}
+
 static inline void ufshcd_vops_dbg_register_dump(struct ufs_hba *hba)
 {
if (hba->vops && hba->vops->dbg_register_dump)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v1 2/2] scsi: ufs-qcom: Add reset control support for host controller

2019-10-22 Thread Can Guo
Add reset control for host controller and provide it through vops to UFS
core driver.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-qcom.c | 43 +++
 drivers/scsi/ufs/ufs-qcom.h |  3 +++
 2 files changed, 46 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index a5b7148..3dee906 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -576,6 +576,39 @@ static int ufs_qcom_resume(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
return 0;
 }
 
+static int ufs_qcom_full_reset(struct ufs_hba *hba)
+{
+   int ret = -ENOTSUPP;
+   struct ufs_qcom_host *host = ufshcd_get_variant(hba);
+
+   if (!host->core_reset) {
+   dev_warn(hba->dev, "%s: failed, err = %d\n", __func__, ret);
+   goto out;
+   }
+
+   ret = reset_control_assert(host->core_reset);
+   if (ret) {
+   dev_err(hba->dev, "%s: core_reset assert failed, err = %d\n",
+__func__, ret);
+   goto out;
+   }
+
+   /*
+* The hardware requirement for delay between assert/deassert
+* is at least 3-4 sleep clock (32.7KHz) cycles, which comes to
+* ~125us (4/32768). To be on the safe side add 200us delay.
+*/
+   usleep_range(200, 210);
+
+   ret = reset_control_deassert(host->core_reset);
+   if (ret)
+   dev_err(hba->dev, "%s: core_reset deassert failed, err = %d\n",
+__func__, ret);
+
+out:
+   return ret;
+}
+
 #ifdef CONFIG_MSM_BUS_SCALING
 static int ufs_qcom_get_bus_vote(struct ufs_qcom_host *host,
const char *speed_mode)
@@ -1101,6 +1134,15 @@ static int ufs_qcom_init(struct ufs_hba *hba)
host->hba = hba;
ufshcd_set_variant(hba, host);
 
+   /* Setup the reset control of HCI */
+   host->core_reset = devm_reset_control_get(hba->dev, "rst");
+   if (IS_ERR(host->core_reset)) {
+   err = PTR_ERR(host->core_reset);
+   dev_warn(dev, "Failed to get reset control %d\n", err);
+   host->core_reset = NULL;
+   err = 0;
+   }
+
/* Fire up the reset controller. Failure here is non-fatal. */
host->rcdev.of_node = dev->of_node;
host->rcdev.ops = _qcom_reset_ops;
@@ -1596,6 +1638,7 @@ static void ufs_qcom_device_reset(struct ufs_hba *hba)
.apply_dev_quirks   = ufs_qcom_apply_dev_quirks,
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
+   .full_reset = ufs_qcom_full_reset,
.dbg_register_dump  = ufs_qcom_dump_dbg_regs,
.device_reset   = ufs_qcom_device_reset,
 };
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index d401f17..2d95e7c 100644
--- a/drivers/scsi/ufs/ufs-qcom.h
+++ b/drivers/scsi/ufs/ufs-qcom.h
@@ -6,6 +6,7 @@
 #define UFS_QCOM_H_
 
 #include 
+#include 
 
 #define MAX_UFS_QCOM_HOSTS 1
 #define MAX_U32 (~(u32)0)
@@ -233,6 +234,8 @@ struct ufs_qcom_host {
u32 dbg_print_en;
struct ufs_qcom_testbus testbus;
 
+   /* Reset control of HCI */
+   struct reset_control *core_reset;
struct reset_controller_dev rcdev;
 
struct gpio_desc *device_reset;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: [PATCH 3/7] Add a UFFD_SECURE flag to the userfaultfd API.

2019-10-22 Thread Andy Lutomirski
Trying again.  It looks like I used the wrong address for Pavel.

On Sat, Oct 12, 2019 at 6:14 PM Andy Lutomirski  wrote:
>
> [adding more people because this is going to be an ABI break, sigh]
>
> On Sat, Oct 12, 2019 at 5:52 PM Daniel Colascione  wrote:
> >
> > On Sat, Oct 12, 2019 at 4:10 PM Andy Lutomirski  wrote:
> > >
> > > On Sat, Oct 12, 2019 at 12:16 PM Daniel Colascione  
> > > wrote:
> > > >
> > > > The new secure flag makes userfaultfd use a new "secure" anonymous
> > > > file object instead of the default one, letting security modules
> > > > supervise userfaultfd use.
> > > >
> > > > Requiring that users pass a new flag lets us avoid changing the
> > > > semantics for existing callers.
> > >
> > > Is there any good reason not to make this be the default?
> > >
> > >
> > > The only downside I can see is that it would increase the memory usage
> > > of userfaultfd(), but that doesn't seem like such a big deal.  A
> > > lighter-weight alternative would be to have a single inode shared by
> > > all userfaultfd instances, which would require a somewhat different
> > > internal anon_inode API.
> >
> > I'd also prefer to just make SELinux use mandatory, but there's a
> > nasty interaction with UFFD_EVENT_FORK. Adding a new UFFD_SECURE mode
> > which blocks UFFD_EVENT_FORK sidesteps this problem. Maybe you know a
> > better way to deal with it.
>
> ...
>
> > But maybe we can go further: let's separate authentication and
> > authorization, as we do in other LSM hooks. Let's split my
> > inode_init_security_anon into two hooks, inode_init_security_anon and
> > inode_create_anon. We'd define the former to just initialize the file
> > object's security information --- in the SELinux case, figuring out
> > its class and SID --- and define the latter to answer the yes/no
> > question of whether a particular anonymous inode creation should be
> > allowed. Normally, anon_inode_getfile2() would just call both hooks.
> > We'd add another anon_inode_getfd flag, ANON_INODE_SKIP_AUTHORIZATION
> > or something, that would tell anon_inode_getfile2() to skip calling
> > the authorization hook, effectively making the creation always
> > succeed. We can then make the UFFD code pass
> > ANON_INODE_SKIP_AUTHORIZATION when it's creating a file object in the
> > fork child while creating UFFD_EVENT_FORK messages.
>
> That sounds like an improvement.  Or maybe just teach SELinux that
> this particular fd creation is actually making an anon_inode that is a
> child of an existing anon inode and that the context should be copied
> or whatever SELinux wants to do.  Like this, maybe:
>
> static int resolve_userfault_fork(struct userfaultfd_ctx *ctx,
>   struct userfaultfd_ctx *new,
>   struct uffd_msg *msg)
> {
> int fd;
>
> Change this:
>
> fd = anon_inode_getfd("[userfaultfd]", _fops, new,
>   O_RDWR | (new->flags & 
> UFFD_SHARED_FCNTL_FLAGS));
>
> to something like:
>
>   fd = anon_inode_make_child_fd(..., ctx->inode, ...);
>
> where ctx->inode is the one context's inode.
>
> *** HOWEVER *** !!!
>
> Now that you've pointed this mechanism out, it is utterly and
> completely broken and should be removed from the kernel outright or at
> least severely restricted.  A .read implementation MUST NOT ACT ON THE
> CALLING TASK.  Ever.  Just imagine the effect of passing a userfaultfd
> as stdin to a setuid program.
>
> So I think the right solution might be to attempt to *remove*
> UFFD_EVENT_FORK.  Maybe the solution is to say that, unless the
> creator of a userfaultfd() has global CAP_SYS_ADMIN, then it cannot
> use UFFD_FEATURE_EVENT_FORK) and print a warning (once) when
> UFFD_FEATURE_EVENT_FORK is allowed.  And, after some suitable
> deprecation period, just remove it.  If it's genuinely useful, it
> needs an entirely new API based on ioctl() or a syscall.  Or even
> recvmsg() :)
>
> And UFFD_SECURE should just become automatic, since you don't have a
> problem any more. :-p
>
> --Andy


Re: dma coherent memory user-space maps

2019-10-22 Thread Christoph Hellwig
Sorry, but travel for meeting.  I'll try to get to it as quick as
I can.


Re: [PATCH v2 2/2] dt-bindings: iio: adc: Add DT docs for AD7292

2019-10-22 Thread Marcelo Schmitt
Hi Rob,

OK, thanks for the explanation.

I indeed missed some details from the documentation. I will be more
careful on my next readings.

I see there are other documentation files at Documentation/devicetree/
and Documentation/devicetree/bindings/. Besides these, would you
recommend other documentation and/or material for those who want to
write dt-bindings that validate with dt-schema?

Thanks in advance,

Marcelo

On 10/22, Rob Herring wrote:
> On Tue, Oct 22, 2019 at 9:06 AM Marcelo Schmitt
>  wrote:
> >
> > Hi,
> >
> > I ran the DTC and CHECK for AD7292 schema however, the target '__build'
> > did not run due to errors found in regulator/fixed-regulator.yaml and
> > arm/allwinner,sun4i-a10-csi.yaml.
> 
> Fixes for those are still pending in -next. Use 'make -k' and ignore those.
> 
> >
> > I recall seeing something about the maxItems requirement over regulator
> > supplies being changed on the iio mailing list, so I updated my repo
> > locally, cloned and reinstalled the dt-schema toolset. However, I still
> > can't make it go through the '__build' target.
> >
> > Python 3.7.5rc1 is my default python and I got the following pip3
> > packages installed:
> >
> > ruamel.yaml0.16.5
> > ruamel.yaml.clib   0.2.0
> > rfc39871.3.8
> > jsonschema 3.0.1
> > dtschema   0.0.1  at $HOME//dt-schema
> >
> > Debian Bullseye packages installed:
> > python3-yaml/testing,now 5.1.2-1
> > libyaml-dev/testing,now 0.2.2-1
> >
> > I was only able to run DTC after installing the libyaml-dev package, so
> > I think it might be worth to add it to the project dependencies at
> > https://github.com/robherring/dt-schema.
> 
> Strictly speaking, it's not a dependency for dt-schema. It's
> documented in Documentation/devicetree/writing-schema.rst. I've added
> a pointer to that in bindings/submitting-patches.txt. I'm not sure how
> else to make it more obvious.
> 
> BTW, You will get a useful error message if libyaml is missing when
> building 'make dtbs_check'. I need to make that work for
> dt_binding_check.
> 
> > apt-get install libyaml-dev
> 
> You need the lib too, but that tends to already be installed. IIRC,
> installing the headers doesn't install the lib automatically.
> 
> In any case, I wanted to avoid putting in distro specific instructions
> in the kernel.
> 
> Rob
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Kernel USP" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-usp+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kernel-usp/CAL_JsqLf8kpOu0MQN-TAhQkiZCGfMKWmztnHNo%2B2BAVqfX8yGQ%40mail.gmail.com.


Re: [PATCH V2] usb: typec: Add sysfs node to show connector orientation

2019-10-22 Thread Puma Hsu
Hi Greg,


On Wed, Oct 23, 2019 at 1:27 AM Greg KH  wrote:
>
> On Tue, Oct 22, 2019 at 04:59:24PM +0800, Puma Hsu wrote:
> > Export the Type-C connector orientation so that user space
> > can get this information.
> >
> > Signed-off-by: Puma Hsu 
> > ---
> >  Documentation/ABI/testing/sysfs-class-typec | 11 +++
> >  drivers/usb/typec/class.c   | 18 ++
> >  2 files changed, 29 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> > b/Documentation/ABI/testing/sysfs-class-typec
> > index d7647b258c3c..b22f71801671 100644
> > --- a/Documentation/ABI/testing/sysfs-class-typec
> > +++ b/Documentation/ABI/testing/sysfs-class-typec
> > @@ -108,6 +108,17 @@ Contact: Heikki Krogerus 
> > 
> >  Description:
> >   Revision number of the supported USB Type-C specification.
> >
> > +What:/sys/class/typec//connector_orientation
> > +Date:October 2019
> > +Contact: Puma Hsu 
> > +Description:
> > + Indicates which typec connector orientation is configured now.
> > + cc1 is defined as "normal" and cc2 is defined as "reversed".
>
> Why the blank line after "Description:"?  Shouldn't "Indicates..." be
> right after it?

I checked the coding style for sysfs-class-*, all of them put the
description at the next line behind "Description:"
Should I change it?

> > +
> > + Valid value:
> > + - unknown (nothing configured)
> > + - normal (configured in cc1 side)
> > + - reversed (configured in cc2 side)
> >
> >  USB Type-C partner devices (eg. /sys/class/typec/port0-partner/)
> >
> > diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> > index 94a3eda62add..911d06676aeb 100644
> > --- a/drivers/usb/typec/class.c
> > +++ b/drivers/usb/typec/class.c
> > @@ -1245,6 +1245,23 @@ static ssize_t 
> > usb_power_delivery_revision_show(struct device *dev,
> >  }
> >  static DEVICE_ATTR_RO(usb_power_delivery_revision);
> >
> > +static const char * const typec_connector_orientation[] = {
> > + [TYPEC_ORIENTATION_NONE]= "unknown",
> > + [TYPEC_ORIENTATION_NORMAL]  = "normal",
> > + [TYPEC_ORIENTATION_REVERSE] = "reversed",
> > +};
> > +
> > +static ssize_t connector_orientation_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
>
> Can you line this up properly?

Yes, I will update it in version3 once the previous problem is confirmed.

>
> thanks,
>
> greg k-h


Thanks in advance.
Puma Hsu


Re: [RFC PATCH] cpufreq: mark duplicate frequencies as invalid and continue as normal

2019-10-22 Thread Viresh Kumar
On 22-10-19, 18:32, Sudeep Holla wrote:
> Currently if we encounter duplicate frequency table entries, we abort
> the validation and return error immediately. Instead of failing, we
> can mark the entry as invalid and continue to function normal.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/freq_table.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Hi Viresh,
> 
> Since commit da0c6dc00c69 ("cpufreq: Handle sorted frequency tables more
> efficiently"), I seem to have modified the firmware entry on my TC2 to
> drop 500MHz and had not seen the issue with duplicate entries and had
> totally forgotten about it.
> 
> Recently I reverted back to original setting as I corrupted it and
> started seeing this issues. I don't know the background for raising
> duplicates as fatal error but we did allow it when we add arm_big_little.c
> and hence this RFC. If there are known issues with this approach, I can
> continue with changed firmware config.
> 
> With switcher, we have:
> (little cluster)
> Virt: 175 MHz, 200 MHz, 250 MHz, 300 MHz, 350 MHz, 400 MHz, 450 MHz, 500 MHz
> Actu: 350 MHz, 400 MHz, 500 MHz, 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz
> (big cluster)
> 500 MHz, 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz
> 
> with 500 MHz duplicate in merged table.
> 
> Regards,
> Sudeep
> 
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index ded427e0a488..e9bf287846d6 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -305,9 +305,10 @@ static int set_freq_table_sorted(struct cpufreq_policy 
> *policy)
>   }
>  
>   if (pos->frequency == prev->frequency) {
> - pr_warn("Duplicate freq-table entries: %u\n",
> + pr_warn("Duplicate freq-table entries: %u marking it 
> invalid\n,",
>   pos->frequency);
> - return -EINVAL;
> + pos->frequency = CPUFREQ_ENTRY_INVALID;
> + continue;
>   }
>  
>   /* Frequency increased from prev to pos */

Of course we can do this, but I don't see why we shouldn't force
people to fix the freq-tables instead. What's the point of allowing
people to have duplicate entries instead ? This shouldn't happen with
OPP tables as we check for duplicate entries there as well.

-- 
viresh


Re: [PATCH v2 2/2] RISC-V: defconfig: Enable Goldfish RTC driver

2019-10-22 Thread Anup Patel
On Wed, Oct 23, 2019 at 6:37 AM Paul Walmsley  wrote:
>
> On Tue, 22 Oct 2019, Alistair Francis wrote:
>
> > I think it makese sense for this to go into Linux first.
> >
> > The QEMU patches are going to be accepted, just some nit picking to do
> > first :)
> >
> > After that we have to wait for a PR and then a QEMU release until most
> > people will see the change in QEMU. In that time Linux 5.4 will be
> > released, if this can make it into 5.4 then everyone using 5.4 will get
> > the new RTC as soon as they upgrade QEMU (QEMU provides the device
> > tree). If this has to wait until QEMU has support then it won't be
> > supported for users until even later.
> >
> > Users are generally slow to update kernels (buildroot is still using
> > 5.1 by default for example) so the sooner changes like this go in the
> > better.
>
> The defconfigs are really just for kernel developers.  We expect users to
> define their own Kconfigs for their own needs.
>
> If using the Goldfish code really is what we all want to do (see below),
> then the kernel patch that should go in right away -- which also has no
> dependence on what QEMU does -- would be the first patch of this series:
>
> https://lore.kernel.org/linux-riscv/20190925063706.56175-2-anup.pa...@wdc.com/
>
> And that should go in via whoever is maintaining the Goldfish driver, not
> the RISC-V tree.  (It looks like drivers/platform/goldfish is completely
> unmaintained - a red flag! - so probably someone needs to persuade Greg or
> Andrew to take it.)

GregKH has already queued this for Linux-5.5 and you can see this
commit present in linux-next tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/platform/goldfish?h=next-20191022

>
> Incidentally, just looking at drivers/platform/goldfish, that driver seems
> to be some sort of Google-specific RPC driver.  Are you all really sure

Nopes, it's not RPC driver. In fact, all Goldfish virtual platform devices
are MMIO devices.

> you want to enable that just for an RTC?  Seems like overkill - there are
> much simpler RTCs out there.

No, it's not overkill. All Goldfish virtual platform devices are quite simple
MMIO devices having bare minimum registers required for device
functioning.

The problem is VirtIO spec does not define any RTC device so instead of
inventing our own virtual RTC device we re-use RTC device defined in
Goldfish virtual platform for QEMU virt machine. This way we can re-use
the Linux Goldfish RTC driver.

BTW, I will send-out QEMU Goldfish RTC patches today or tomorrow
addressing nit comments from Alistair.

Regards,
Anup


Re: [PATCH] cpufreq: s3c64xx: Remove pointless NULL check in s3c64xx_cpufreq_driver_init

2019-10-22 Thread Viresh Kumar
On 22-10-19, 17:09, Nathan Chancellor wrote:
> When building with Clang + -Wtautological-pointer-compare:
> 
> drivers/cpufreq/s3c64xx-cpufreq.c:152:6: warning: comparison of array
> 's3c64xx_freq_table' equal to a null pointer is always false
> [-Wtautological-pointer-compare]
> if (s3c64xx_freq_table == NULL) {
> ^~
> 1 warning generated.
> 
> The definition of s3c64xx_freq_table is surrounded by an ifdef
> directive for CONFIG_CPU_S3C6410, which is always true for this driver
> because it depends on it in drivers/cpufreq/Kconfig.arm (and if it
> weren't, there would be a build error because s3c64xx_freq_table would
> not be a defined symbol).
> 
> Resolve this warning by removing the unnecessary NULL check because it
> is always false as Clang notes. While we are at it, remove the
> unnecessary ifdef conditional because it is always true.
> 
> Fixes: b3748ddd8056 ("[ARM] S3C64XX: Initial support for DVFS")

+broonie, who wrote this patch to see his views on why he kept it like
this.

> Link: https://github.com/ClangBuiltLinux/linux/issues/748
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/cpufreq/s3c64xx-cpufreq.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c 
> b/drivers/cpufreq/s3c64xx-cpufreq.c
> index af0c00dabb22..c6bdfc308e99 100644
> --- a/drivers/cpufreq/s3c64xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c64xx-cpufreq.c
> @@ -19,7 +19,6 @@
>  static struct regulator *vddarm;
>  static unsigned long regulator_latency;
>  
> -#ifdef CONFIG_CPU_S3C6410
>  struct s3c64xx_dvfs {
>   unsigned int vddarm_min;
>   unsigned int vddarm_max;
> @@ -48,7 +47,6 @@ static struct cpufreq_frequency_table s3c64xx_freq_table[] 
> = {
>   { 0, 4, 80 },
>   { 0, 0, CPUFREQ_TABLE_END },
>  };
> -#endif
>  
>  static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
> unsigned int index)
> @@ -149,11 +147,6 @@ static int s3c64xx_cpufreq_driver_init(struct 
> cpufreq_policy *policy)
>   if (policy->cpu != 0)
>   return -EINVAL;
>  
> - if (s3c64xx_freq_table == NULL) {
> - pr_err("No frequency information for this CPU\n");
> - return -ENODEV;
> - }
> -
>   policy->clk = clk_get(NULL, "armclk");
>   if (IS_ERR(policy->clk)) {
>   pr_err("Unable to obtain ARMCLK: %ld\n",
> -- 
> 2.23.0

-- 
viresh


Re: [PATCH v6 11/43] compat_ioctl: move drivers to compat_ptr_ioctl

2019-10-22 Thread Al Viro
On Tue, Oct 22, 2019 at 12:26:09PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 22, 2019 at 6:34 AM Al Viro  wrote:
> >
> > On Wed, Oct 09, 2019 at 09:10:11PM +0200, Arnd Bergmann wrote:
> > > Each of these drivers has a copy of the same trivial helper function to
> > > convert the pointer argument and then call the native ioctl handler.
> > >
> > > We now have a generic implementation of that, so use it.
> >
> > I'd rather flipped your #7 (ceph_compat_ioctl() introduction) past
> > that one...
> 
> The idea was to be able to backport the ceph patch as a bugfix
> to stable kernels without having to change it or backport
> compat_ptr_ioctl() as well.
> 
> If you still prefer it that way, I'd move to a simpler version of this
> patch and drop the Cc:stable.

What I'm going to do is to put the introduction of compat_ptr_ioctl()
into a never-rebased branch; having e.g. ceph patch done on top of
it should suffice - it can go into -stable just fine.  Trivially
backported all the way back, has no prereqs and is guaranteed to
cause no conflicts, so if any -stable fodder ends up depending upon
it, there will be no problem whatsoever.  IMO that commit should
precede everything else in the queue...

Another thing is that I'd fold #8 into #6 - it clearly belongs
in there.


Re: [PATCH v2] vhost: introduce mdev based hardware backend

2019-10-22 Thread Tiwei Bie
On Tue, Oct 22, 2019 at 09:30:16PM +0800, Jason Wang wrote:
> On 2019/10/22 下午5:52, Tiwei Bie wrote:
> > This patch introduces a mdev based hardware vhost backend.
> > This backend is built on top of the same abstraction used
> > in virtio-mdev and provides a generic vhost interface for
> > userspace to accelerate the virtio devices in guest.
> > 
> > This backend is implemented as a mdev device driver on top
> > of the same mdev device ops used in virtio-mdev but using
> > a different mdev class id, and it will register the device
> > as a VFIO device for userspace to use. Userspace can setup
> > the IOMMU with the existing VFIO container/group APIs and
> > then get the device fd with the device name. After getting
> > the device fd of this device, userspace can use vhost ioctls
> > to setup the backend.
> > 
> > Signed-off-by: Tiwei Bie 
> > ---
> > This patch depends on below series:
> > https://lkml.org/lkml/2019/10/17/286
> > 
> > v1 -> v2:
> > - Replace _SET_STATE with _SET_STATUS (MST);
> > - Check status bits at each step (MST);
> > - Report the max ring size and max number of queues (MST);
> > - Add missing MODULE_DEVICE_TABLE (Jason);
> > - Only support the network backend w/o multiqueue for now;
> 
> 
> Any idea on how to extend it to support devices other than net? I think we
> want a generic API or an API that could be made generic in the future.
> 
> Do we want to e.g having a generic vhost mdev for all kinds of devices or
> introducing e.g vhost-net-mdev and vhost-scsi-mdev?

One possible way is to do what vhost-user does. I.e. Apart from
the generic ring, features, ... related ioctls, we also introduce
device specific ioctls when we need them. As vhost-mdev just needs
to forward configs between parent and userspace and even won't
cache any info when possible, I think it might be better to do
this in one generic vhost-mdev module.

> 
> 
> > - Some minor fixes and improvements;
> > - Rebase on top of virtio-mdev series v4;
> > 
> > RFC v4 -> v1:
> > - Implement vhost-mdev as a mdev device driver directly and
> >connect it to VFIO container/group. (Jason);
> > - Pass ring addresses as GPAs/IOVAs in vhost-mdev to avoid
> >meaningless HVA->GPA translations (Jason);
> > 
> > RFC v3 -> RFC v4:
> > - Build vhost-mdev on top of the same abstraction used by
> >virtio-mdev (Jason);
> > - Introduce vhost fd and pass VFIO fd via SET_BACKEND ioctl (MST);
> > 
> > RFC v2 -> RFC v3:
> > - Reuse vhost's ioctls instead of inventing a VFIO regions/irqs
> >based vhost protocol on top of vfio-mdev (Jason);
> > 
> > RFC v1 -> RFC v2:
> > - Introduce a new VFIO device type to build a vhost protocol
> >on top of vfio-mdev;
> > 
> >   drivers/vfio/mdev/mdev_core.c |  12 +
> >   drivers/vhost/Kconfig |   9 +
> >   drivers/vhost/Makefile|   3 +
> >   drivers/vhost/mdev.c  | 415 ++
> >   include/linux/mdev.h  |   3 +
> >   include/uapi/linux/vhost.h|  13 ++
> >   6 files changed, 455 insertions(+)
> >   create mode 100644 drivers/vhost/mdev.c
> > 
> > diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> > index 5834f6b7c7a5..2963f65e6648 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -69,6 +69,18 @@ void mdev_set_virtio_ops(struct mdev_device *mdev,
> >   }
> >   EXPORT_SYMBOL(mdev_set_virtio_ops);
> > +/* Specify the vhost device ops for the mdev device, this
> > + * must be called during create() callback for vhost mdev device.
> > + */
> > +void mdev_set_vhost_ops(struct mdev_device *mdev,
> > +   const struct virtio_mdev_device_ops *vhost_ops)
> > +{
> > +   WARN_ON(mdev->class_id);
> > +   mdev->class_id = MDEV_CLASS_ID_VHOST;
> > +   mdev->device_ops = vhost_ops;
> > +}
> > +EXPORT_SYMBOL(mdev_set_vhost_ops);
> > +
> >   const void *mdev_get_dev_ops(struct mdev_device *mdev)
> >   {
> > return mdev->device_ops;
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index 3d03ccbd1adc..7b5c2f655af7 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -34,6 +34,15 @@ config VHOST_VSOCK
> > To compile this driver as a module, choose M here: the module will be 
> > called
> > vhost_vsock.
> > +config VHOST_MDEV
> > +   tristate "Vhost driver for Mediated devices"
> > +   depends on EVENTFD && VFIO && VFIO_MDEV
> > +   select VHOST
> > +   default n
> > +   ---help---
> > +   Say M here to enable the vhost_mdev module for use with
> > +   the mediated device based hardware vhost accelerators.
> > +
> >   config VHOST
> > tristate
> > ---help---
> > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > index 6c6df24f770c..ad9c0f8c6d8c 100644
> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -10,4 +10,7 @@ vhost_vsock-y := vsock.o
> >   obj-$(CONFIG_VHOST_RING) += vringh.o
> > +obj-$(CONFIG_VHOST_MDEV) += vhost_mdev.o
> > +vhost_mdev-y := mdev.o
> > +
> >  

[PATCH 1/2] dt-bindings: DMA: Add X1000 bindings.

2019-10-22 Thread Zhou Yanjie
Add the DMA bindings for the X1000 Soc from Ingenic.

Signed-off-by: Zhou Yanjie 
---
 .../devicetree/bindings/dma/jz4780-dma.txt |  3 +-
 include/dt-bindings/dma/x1000-dma.h| 40 ++
 2 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/dma/x1000-dma.h

diff --git a/Documentation/devicetree/bindings/dma/jz4780-dma.txt 
b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
index 636fcb2..ec89782 100644
--- a/Documentation/devicetree/bindings/dma/jz4780-dma.txt
+++ b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
@@ -7,10 +7,11 @@ Required properties:
   * ingenic,jz4725b-dma
   * ingenic,jz4770-dma
   * ingenic,jz4780-dma
+  * ingenic,x1000-dma
 - reg: Should contain the DMA channel registers location and length, followed
   by the DMA controller registers location and length.
 - interrupts: Should contain the interrupt specifier of the DMA controller.
-- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
+- clocks: Should contain a clock specifier for the JZ4780/X1000 PDMA clock.
 - #dma-cells: Must be <2>. Number of integer cells in the dmas property of
   DMA clients (see below).
 
diff --git a/include/dt-bindings/dma/x1000-dma.h 
b/include/dt-bindings/dma/x1000-dma.h
new file mode 100644
index ..401e165
--- /dev/null
+++ b/include/dt-bindings/dma/x1000-dma.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * This header provides macros for X1000 DMA bindings.
+ *
+ * Copyright (c) 2019 Zhou Yanjie 
+ */
+
+#ifndef __DT_BINDINGS_DMA_X1000_DMA_H__
+#define __DT_BINDINGS_DMA_X1000_DMA_H__
+
+/*
+ * Request type numbers for the X1000 DMA controller (written to the DRTn
+ * register for the channel).
+ */
+#define X1000_DMA_DMIC_RX  0x5
+#define X1000_DMA_I2S0_TX  0x6
+#define X1000_DMA_I2S0_RX  0x7
+#define X1000_DMA_AUTO 0x8
+#define X1000_DMA_UART2_TX 0x10
+#define X1000_DMA_UART2_RX 0x11
+#define X1000_DMA_UART1_TX 0x12
+#define X1000_DMA_UART1_RX 0x13
+#define X1000_DMA_UART0_TX 0x14
+#define X1000_DMA_UART0_RX 0x15
+#define X1000_DMA_SSI0_TX  0x16
+#define X1000_DMA_SSI0_RX  0x17
+#define X1000_DMA_MSC0_TX  0x1a
+#define X1000_DMA_MSC0_RX  0x1b
+#define X1000_DMA_MSC1_TX  0x1c
+#define X1000_DMA_MSC1_RX  0x1d
+#define X1000_DMA_PCM0_TX  0x20
+#define X1000_DMA_PCM0_RX  0x21
+#define X1000_DMA_SMB0_TX  0x24
+#define X1000_DMA_SMB0_RX  0x25
+#define X1000_DMA_SMB1_TX  0x26
+#define X1000_DMA_SMB1_RX  0x27
+#define X1000_DMA_SMB2_TX  0x28
+#define X1000_DMA_SMB2_RX  0x29
+
+#endif /* __DT_BINDINGS_DMA_X1000_DMA_H__ */
-- 
2.7.4




DMA: JZ4780: Add DMA driver for X1000.

2019-10-22 Thread Zhou Yanjie
1.Add the DMA bindings for the X1000 SoC from Ingenic.
2.Add support for probing the dma-jz4780 driver on the
  X1000 SoC from Ingenic.




[PATCH 2/2] DMA: JZ4780: Add support for the X1000.

2019-10-22 Thread Zhou Yanjie
Add support for probing the dma-jz4780 driver on the X1000 Soc.

Signed-off-by: Zhou Yanjie 
---
 drivers/dma/dma-jz4780.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c
index 7fe9309..c7f1199 100644
--- a/drivers/dma/dma-jz4780.c
+++ b/drivers/dma/dma-jz4780.c
@@ -1012,11 +1012,18 @@ static const struct jz4780_dma_soc_data 
jz4780_dma_soc_data = {
.flags = JZ_SOC_DATA_ALLOW_LEGACY_DT | JZ_SOC_DATA_PROGRAMMABLE_DMA,
 };
 
+static const struct jz4780_dma_soc_data x1000_dma_soc_data = {
+   .nb_channels = 8,
+   .transfer_ord_max = 7,
+   .flags = JZ_SOC_DATA_ALLOW_LEGACY_DT | JZ_SOC_DATA_PROGRAMMABLE_DMA,
+};
+
 static const struct of_device_id jz4780_dma_dt_match[] = {
{ .compatible = "ingenic,jz4740-dma", .data = _dma_soc_data },
{ .compatible = "ingenic,jz4725b-dma", .data = _dma_soc_data },
{ .compatible = "ingenic,jz4770-dma", .data = _dma_soc_data },
{ .compatible = "ingenic,jz4780-dma", .data = _dma_soc_data },
+   { .compatible = "ingenic,x1000-dma", .data = _dma_soc_data },
{},
 };
 MODULE_DEVICE_TABLE(of, jz4780_dma_dt_match);
-- 
2.7.4




Re: [PATCH] hugetlbfs: add O_TMPFILE support

2019-10-22 Thread Mike Kravetz
On 10/22/19 12:09 AM, Piotr Sarna wrote:
> On 10/21/19 7:17 PM, Mike Kravetz wrote:
>> On 10/15/19 4:37 PM, Mike Kravetz wrote:
>>> On 10/15/19 3:50 AM, Michal Hocko wrote:
 On Tue 15-10-19 11:01:12, Piotr Sarna wrote:
> With hugetlbfs, a common pattern for mapping anonymous huge pages
> is to create a temporary file first.

 Really? I though that this is normally done by shmget(SHM_HUGETLB) or
 mmap(MAP_HUGETLB). Or maybe I misunderstood your definition on anonymous
 huge pages.

> Currently libraries like
> libhugetlbfs and seastar create these with a standard mkstemp+unlink
> trick,
>>>
>>> I would guess that much of libhugetlbfs was writen before MAP_HUGETLB
>>> was implemented.  So, that is why it does not make (more) use of that
>>> option.
>>>
>>> The implementation looks to be straight forward.  However, I really do
>>> not want to add more functionality to hugetlbfs unless there is specific
>>> use case that needs it.
>>
>> It was not my intention to shut down discussion on this patch.  I was just
>> asking if there was a (new) use case for such a change.  I am checking with
>> our DB team as I seem to remember them using the create/unlink approach for
>> hugetlbfs in one of their upcoming models.
>>
>> Is there a new use case you were thinking about?
>>
> 
> Oh, I indeed thought it was a shutdown. The use case I was thinking about was 
> in Seastar, where the create+unlink trick is used for creating temporary 
> files (in a generic way, not only for hugetlbfs). I simply intended to 
> migrate it to a newer approach - O_TMPFILE. However,
> for the specific case of hugetlbfs it indeed makes more sense to skip it and 
> use mmap's MAP_HUGETLB, so perhaps it's not worth it to patch a perfectly 
> good and stable file system just to provide a semi-useful flag support. My 
> implementation of tmpfile for hugetlbfs is straightforward indeed, but the 
> MAP_HUGETLB argument made me realize that it may not be worth the trouble - 
> especially that MAP_HUGETLB is here since 2.6 and O_TMPFILE was introduced 
> around v3.11, so the mmap way looks more portable.
> 
> tldr: I'd be very happy to get my patch accepted, but the use case I had in 
> mind can be easily solved with MAP_HUGETLB, so I don't insist.

If you really are after something like 'anonymous memory' for Seastar,
then MAP_HUGETLB would be the better approach.

I'm still checking with Oracle DB team as they may have a use for O_TMPFILE
in an upcoming release.  In their use case, they want an open fd to work with.
If it looks like they will proceed in this direction, we can work to get
your patch moved forward.

Thanks,
-- 
Mike Kravetz


答复: [PATCH] scripts: fix memleak error in read_file

2019-10-22 Thread linfeilong
On Tue, 22 Oct 2019 11:47:59 + linfeilong  wrote:
>
>> An error is found by the static code analysis tool: "memleak"
>> Fix this by add free before return.
>> 
>> Signed-off-by: Feilong Lin 
>> ---
>>  scripts/insert-sys-cert.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/scripts/insert-sys-cert.c b/scripts/insert-sys-cert.c 
>> index 8902836..22d99a8 100644
>> --- a/scripts/insert-sys-cert.c
>> +++ b/scripts/insert-sys-cert.c
>> @@ -250,6 +250,7 @@ static char *read_file(char *file_name, int *size)
>>  }
>>  if (read(fd, buf, *size) != *size) {
>>  perror("File read failed");
>> +free(buf);
>>  close(fd);
>>  return NULL;
>>  }
>
>A few lines later we do
>
>   return buf;
>
>so the patch adds a use-after-free error. 
>
>We could do a free(cert) down in main() or we could just do nothing -
>read_file() is only called a single time.

Thanks, but there is no use-after-free as we do free just before return NULL.
And I think do free in error scenes makes the code look better.


Re: [PATCH 4/5] tracing: Handle the trace array ref counter in new functions

2019-10-22 Thread Steven Rostedt
On Wed, 16 Oct 2019 16:42:02 -0700
Divya Indi  wrote:

> Hi Steve,
> 
> Thanks again for taking the time to review and providing feedback. Please 
> find my comments inline.
> 
> On 10/15/19 4:04 PM, Steven Rostedt wrote:
> > Sorry for taking so long to getting to these patches.
> >
> > On Wed, 14 Aug 2019 10:55:26 -0700
> > Divya Indi  wrote:
> >  
> >> For functions returning a trace array Eg: trace_array_create(), we need to
> >> increment the reference counter associated with the trace array to ensure 
> >> it
> >> does not get freed when in use.
> >>
> >> Once we are done using the trace array, we need to call
> >> trace_array_put() to make sure we are not holding a reference to it
> >> anymore and the instance/trace array can be removed when required.  
> > I think it would be more in line with other parts of the kernel if we
> > don't need to do the trace_array_put() before calling
> > trace_array_destroy().  
> 
> The reason we went with this approach is
> 
> instance_mkdir -  ref_ctr = 0  // Does not return a trace array ptr.
> trace_array_create -  ref_ctr = 1  // Since this returns a trace array 
> ptr.
> trace_array_lookup -  ref_ctr = 1  // Since this returns a trace array 
> ptr.
> 
> if we make trace_array_destroy to expect ref_ctr to be 1, we risk destroying 
> the trace array while in use.
> 
> We could make it -
> 
> instance_mkdir -  ref_ctr = 1
> trace_array_create -ref_ctr = 2
> trace_array_lookup -ref_ctr = 2+  // depending on no of lookups
> 
> but, we'd still need the trace_array_put() (?)
> 
> We can also have one function doing create (if does not exist) or lookup (if 
> exists), but that would require
> some redundant code since instance_mkdir needs to return -EXIST when a trace 
> array already exists.
> 
> Let me know your thoughts on this.
> 

Can't we just move the trace_array_put() in the instance_rmdir()?

static int instance_rmdir(const char *name)
{
struct trace_array *tr;
int ret;

mutex_lock(_mutex);
mutex_lock(_types_lock);

ret = -ENODEV;
list_for_each_entry(tr, _trace_arrays, list) {
if (tr->name && strcmp(tr->name, name) == 0) {
__trace_array_put(tr);
ret = __remove_instance(tr);
if (ret)
tr->ref++;
break;
}
}

mutex_unlock(_types_lock);
mutex_unlock(_mutex);

return ret;
}

-- Steve


RE: [PATCH 0/7] towards QE support on ARM

2019-10-22 Thread Qiang Zhao
On 22/10/2019 18:18, Rasmus Villemoes  wrote:
> -Original Message-
> From: Rasmus Villemoes 
> Sent: 2019年10月22日 18:18
> To: Qiang Zhao ; Leo Li 
> Cc: Timur Tabi ; Greg Kroah-Hartman
> ; linux-kernel@vger.kernel.org;
> linux-ser...@vger.kernel.org; Jiri Slaby ;
> linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/7] towards QE support on ARM
> 
> On 22/10/2019 04.24, Qiang Zhao wrote:
> > On Mon, Oct 22, 2019 at 6:11 AM Leo Li wrote
> 
> >> Right.  I'm really interested in getting this applied to my tree and
> >> make it upstream.  Zhao Qiang, can you help to review Rasmus's
> >> patches and comment?
> >
> > As you know, I maintained a similar patchset removing PPC, and someone
> told me qe_ic should moved into drivers/irqchip/.
> > I also thought qe_ic is a interrupt control driver, should be moved into dir
> irqchip.
> 
> Yes, and I also plan to do that at some point. However, that's orthogonal to
> making the driver build on ARM, so I don't want to mix the two. Making it
> usable on ARM is my/our priority currently.
> 
> I'd appreciate your input on my patches.

Yes, we can put this patchset in first place, ensure it can build and work on 
ARM, then push another patchset to move qe_ic.

Best Regards,
Qiang



RE: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support

2019-10-22 Thread Peng Ma
Hi Anders,

The fixed patch link as follows:
https://lore.kernel.org/lkml/20191023021959.35596-1-peng...@nxp.com/
Please check it.

Best Regards,
Peng
>-Original Message-
>From: Anders Roxell 
>Sent: 2019年10月22日 19:11
>To: Peng Ma 
>Cc: Vinod Koul ; dan.j.willi...@intel.com; Leo Li
>; linux-kernel@vger.kernel.org;
>dmaeng...@vger.kernel.org
>Subject: Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
>DPDMAI(Data Path DMA Interface) support
>
>Caution: EXT Email
>
>On 2019-10-22 10:19, Peng Ma wrote:
>> Hi Anders && Viod,
>>
>> I sent v6 patch to fix the build error, please check.
>
>oh I will check, didn't see them when I sent out my email. =/
>
>Cheers,
>Anders
>
>> Patchwork link:
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>
>hwork.kernel.org%2Fproject%2Flinux-dmaengine%2Flist%2F%3Fseries%3D191
>3
>>
>97data=02%7C01%7Cpeng.ma%40nxp.com%7C7f201966dd744703dd4
>c08d756e8
>>
>19a2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637073427176
>654617
>>
>mp;sdata=%2Fsg0iOhBDCqrTzDxS0WPmQoEmq%2BrvbpZd7xytloH484%3D
>mp;reserv
>> ed=0
>>
>> Best Regards,
>> Peng
>> >-Original Message-
>> >From: Anders Roxell 
>> >Sent: 2019年10月22日 17:27
>> >To: Peng Ma 
>> >Cc: Vinod Koul ; dan.j.willi...@intel.com; Leo Li
>> >; linux-kernel@vger.kernel.org;
>> >dmaeng...@vger.kernel.org
>> >Subject: Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
>> >DPDMAI(Data Path DMA Interface) support
>> >
>> >Caution: EXT Email
>> >
>> >On Thu, 17 Oct 2019 at 08:16, Peng Ma  wrote:
>> >>
>> >> Hi Vinod,
>> >>
>> >> Thanks very much for your reply.
>> >>
>> >> Best Regards,
>> >> Peng
>> >> >-Original Message-
>> >> >From: Vinod Koul 
>> >> >Sent: 2019年10月17日 12:11
>> >> >To: Peng Ma 
>> >> >Cc: dan.j.willi...@intel.com; Leo Li ;
>> >> >linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org
>> >> >Subject: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
>> >> >DPDMAI(Data Path DMA Interface) support
>> >> >
>> >> >Caution: EXT Email
>> >> >
>> >> >On 30-09-19, 02:04, Peng Ma wrote:
>> >> >> The MC(Management Complex) exports the DPDMAI(Data Path DMA
>> >> >Interface)
>> >> >> object as an interface to operate the DPAA2(Data Path
>> >> >> Acceleration Architecture 2) qDMA Engine. The DPDMAI enables
>> >> >> sending frame-based requests to qDMA and receiving back
>> >> >> confirmation response on transaction completion, utilizing the
>> >> >> DPAA2 QBMan(Queue Manager and Buffer Manager
>> >> >> hardware) infrastructure. DPDMAI object provides up to two
>> >> >> priorities for processing qDMA requests.
>> >> >> The following list summarizes the DPDMAI main features and
>capabilities:
>> >> >>   1. Supports up to two scheduling priorities for processing
>> >> >>   service requests.
>> >> >>   - Each DPDMAI transmit queue is mapped to one of two
>service
>> >> >>   priorities, allowing further prioritization in hardware between
>> >> >>   requests from different DPDMAI objects.
>> >> >>   2. Supports up to two receive queues for incoming transaction
>> >> >>   completion confirmations.
>> >> >>   - Each DPDMAI receive queue is mapped to one of two receive
>> >> >>   priorities, allowing further prioritization between other
>> >> >>   interfaces when associating the DPDMAI receive queues to
>DPIO
>> >> >>   or DPCON(Data Path Concentrator) objects.
>> >> >>   3. Supports different scheduling options for processing
>received
>> >> >>   packets:
>> >> >>   - Queues can be configured either in 'parked' mode (default),
>> >> >>   or attached to a DPIO object, or attached to DPCON object.
>> >> >>   4. Allows interaction with one or more DPIO objects for
>> >> >>   dequeueing/enqueueing frame descriptors(FD) and for
>> >> >>   acquiring/releasing buffers.
>> >> >>   5. Supports enable, disable, and reset operations.
>> >> >>
>> >> >> Add dpdmai to support some platforms with dpaa2 qdma engine.
>> >> >
>> >> >Applied both, thanks
>> >
>> >I see this error when I'm building.
>> >
>> >WARNING: modpost: missing MODULE_LICENSE() in
>> >drivers/dma/fsl-dpaa2-qdma/dpdmai.o
>> >see include/linux/module.h for more information
>> >ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_set_rx_queue"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_get_tx_queue"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_get_rx_queue"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_get_attributes"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> 

[PATCH v3 2/2] HID: google: Add of_match table to Whiskers switch device.

2019-10-22 Thread Ikjoon Jang
Add a device tree match table.

Signed-off-by: Ikjoon Jang 
Reviewed-by: Dmitry Torokhov 
---
 drivers/hid/hid-google-hammer.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 84f8c127ebdc..b726f8a15044 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -264,12 +265,21 @@ static const struct acpi_device_id cbas_ec_acpi_ids[] = {
 };
 MODULE_DEVICE_TABLE(acpi, cbas_ec_acpi_ids);
 
+#ifdef CONFIG_OF
+static const struct of_device_id cbas_ec_of_match[] = {
+   { .compatible = "google,cros-cbas" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, cbas_ec_of_match);
+#endif
+
 static struct platform_driver cbas_ec_driver = {
.probe = cbas_ec_probe,
.remove = cbas_ec_remove,
.driver = {
.name = "cbas_ec",
.acpi_match_table = ACPI_PTR(cbas_ec_acpi_ids),
+   .of_match_table = of_match_ptr(cbas_ec_of_match),
.pm = _ec_pm_ops,
},
 };
-- 
2.23.0.866.gb869b98d4c-goog



[PATCH v3 1/2] dt-bindings: input: Add DT bindings for Whiskers switch

2019-10-22 Thread Ikjoon Jang
Add the DT binding document for Hammer's TABLET_MODE switch.

Signed-off-by: Ikjoon Jang 
---
 .../devicetree/bindings/input/cros-cbas.yaml  | 22 +++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-cbas.yaml

diff --git a/Documentation/devicetree/bindings/input/cros-cbas.yaml 
b/Documentation/devicetree/bindings/input/cros-cbas.yaml
new file mode 100644
index ..3bc989c6a295
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-cbas.yaml
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cros-cbas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS Hammer's Base Attached Switch
+
+maintainers:
+  - Dmitry Torokhov 
+
+description:
+  This device is used to signal when a detachable base is attached to a
+  Chrome OS tablet. The node for this device must be under a cros-ec node
+  like google,cros-ec-spi or google,cros-ec-i2c.
+
+properties:
+  compatible:
+const: google,cros-cbas
+
+required:
+  - compatible
-- 
2.23.0.866.gb869b98d4c-goog



Re: Linux-next: 20191022: perf: bpf_helpers_doc.py: not found

2019-10-22 Thread Leo Yan
Hi Naresh,

On Tue, Oct 22, 2019 at 09:04:04PM +0530, Naresh Kamboju wrote:
> We have noticed perf (OE recipe) build failure on linux next 20191022.
> do you see this failure ?
> 
> /bin/sh: 1: perf/1.0-r9/perf-1.0/scripts/bpf_helpers_doc.py: not found
> Makefile:184: recipe for target 'bpf_helper_defs.h' failed
> make[3]: *** [bpf_helper_defs.h] Error 127
> make[3]: *** Deleting file 'bpf_helper_defs.h'
> Makefile.perf:765: recipe for target 'perf/1.0-r9/perf-1.0/libbpf.a' failed
> make[2]: *** [perf/1.0-r9/perf-1.0/libbpf.a] Error 2

I tested for two methods with linux-next, one is native building mode
for Arm64 building on DB410c board, another is cross compiling Arm64
binary on my x86 laptop.  Both cannot reproduce this failure.

After read your shared build log and I think the building process is
expected: Perf tool tries to build libbpf, so it changes to the
building folder 'BPF_DIR' (which is under $(srctree)/tools/lib/bpf/),
then failed to find file $(srctree)/scripts/bpf_helpers_doc.py.

Here $(srctree) means the kernel's root folder.

Seems to me, this failure is caused by missing to sync kernel files
$linux_src/scripts to the OE folder 'perf/1.0-r9/perf-1.0/scripts'?

Thanks,
Leo Yan

> Metadata:
> 
> kernel: 5.4.0-rc4
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git branch: master
> git commit: a722f75b2923b4fd44c17e7255e822ac48fe85f0
> git describe: next-20191022
> Test details: 
> https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20191022
> 
> Full build log:
> https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=hikey,label=docker-lkft/631/consoleText
> 
> - Naresh


Re: [PATCH -next] scsi: cxlflash: remove set but not used variable 'ioarcb'

2019-10-22 Thread Martin K. Petersen


YueHaibing,

> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/scsi/cxlflash/main.c:47:22: warning:
>  variable ioarcb set but not used [-Wunused-but-set-variable]

Applied to 5.5/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


[PATCH v3 0/2] HID: google: add device tree bindings for

2019-10-22 Thread Ikjoon Jang
DT bindings for Whiskers swich device and its documentation.

v3: dt bindings description changed
v2: dropped a patch not relevant to DT bindings

Ikjoon Jang (2):
  dt-bindings: input: Add DT bindings for Whiskers switch
  HID: google: Add of_match table to Whiskers switch device.

 .../devicetree/bindings/input/cros-cbas.yaml  | 22 +++
 drivers/hid/hid-google-hammer.c   | 10 +
 2 files changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-cbas.yaml

-- 
2.23.0.866.gb869b98d4c-goog



RE: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support

2019-10-22 Thread Peng Ma
Hi Vinod,

>-Original Message-
>From: Vinod Koul 
>Sent: 2019年10月23日 0:10
>To: Peng Ma 
>Cc: Anders Roxell ; dan.j.willi...@intel.com; Leo Li
>; linux-kernel@vger.kernel.org;
>dmaeng...@vger.kernel.org
>Subject: Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
>DPDMAI(Data Path DMA Interface) support
>
>Caution: EXT Email
>
>Please *do* *not* top post!
>
>On 22-10-19, 10:19, Peng Ma wrote:
>> Hi Anders && Viod,
>
>Its Vinod!
>
[Peng Ma] I am very sorry to spell your name wrong, I will pay attention to 
from now!
>>
>> I sent v6 patch to fix the build error, please check.
>> Patchwork link:
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>
>hwork.kernel.org%2Fproject%2Flinux-dmaengine%2Flist%2F%3Fseries%3D191
>3
>>
>97data=02%7C01%7Cpeng.ma%40nxp.com%7C19ac47d605bf44aa99d
>e08d7570a
>>
>5e64%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637073574351
>786723
>>
>mp;sdata=%2B%2FazVuPMJZUonfvz8gLWGVeakKW0tRFYyjj344IbDg4%3D
>p;reserv
>> ed=0
>
>No I have already applied v5, please send fixes on top on dmaengine-next!
>Would also make sense to give credit to Anders using Reported-by tag
>
[Peng Ma] Ok, Got it.
The patchwork link:
https://patchwork.kernel.org/patch/11205611/
>>
>> Best Regards,
>> Peng
>> >-Original Message-
>> >From: Anders Roxell 
>> >Sent: 2019年10月22日 17:27
>> >To: Peng Ma 
>> >Cc: Vinod Koul ; dan.j.willi...@intel.com; Leo Li
>> >; linux-kernel@vger.kernel.org;
>> >dmaeng...@vger.kernel.org
>> >Subject: Re: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
>> >DPDMAI(Data Path DMA Interface) support
>> >
>> >Caution: EXT Email
>> >
>> >On Thu, 17 Oct 2019 at 08:16, Peng Ma  wrote:
>> >>
>> >> Hi Vinod,
>> >>
>> >> Thanks very much for your reply.
>> >>
>> >> Best Regards,
>> >> Peng
>> >> >-Original Message-
>> >> >From: Vinod Koul 
>> >> >Sent: 2019年10月17日 12:11
>> >> >To: Peng Ma 
>> >> >Cc: dan.j.willi...@intel.com; Leo Li ;
>> >> >linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org
>> >> >Subject: [EXT] Re: [V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the
>> >> >DPDMAI(Data Path DMA Interface) support
>> >> >
>> >> >Caution: EXT Email
>> >> >
>> >> >On 30-09-19, 02:04, Peng Ma wrote:
>> >> >> The MC(Management Complex) exports the DPDMAI(Data Path DMA
>> >> >Interface)
>> >> >> object as an interface to operate the DPAA2(Data Path
>> >> >> Acceleration Architecture 2) qDMA Engine. The DPDMAI enables
>> >> >> sending frame-based requests to qDMA and receiving back
>> >> >> confirmation response on transaction completion, utilizing the
>> >> >> DPAA2 QBMan(Queue Manager and Buffer Manager
>> >> >> hardware) infrastructure. DPDMAI object provides up to two
>> >> >> priorities for processing qDMA requests.
>> >> >> The following list summarizes the DPDMAI main features and
>capabilities:
>> >> >>   1. Supports up to two scheduling priorities for processing
>> >> >>   service requests.
>> >> >>   - Each DPDMAI transmit queue is mapped to one of two
>service
>> >> >>   priorities, allowing further prioritization in hardware between
>> >> >>   requests from different DPDMAI objects.
>> >> >>   2. Supports up to two receive queues for incoming transaction
>> >> >>   completion confirmations.
>> >> >>   - Each DPDMAI receive queue is mapped to one of two receive
>> >> >>   priorities, allowing further prioritization between other
>> >> >>   interfaces when associating the DPDMAI receive queues to
>DPIO
>> >> >>   or DPCON(Data Path Concentrator) objects.
>> >> >>   3. Supports different scheduling options for processing
>received
>> >> >>   packets:
>> >> >>   - Queues can be configured either in 'parked' mode (default),
>> >> >>   or attached to a DPIO object, or attached to DPCON object.
>> >> >>   4. Allows interaction with one or more DPIO objects for
>> >> >>   dequeueing/enqueueing frame descriptors(FD) and for
>> >> >>   acquiring/releasing buffers.
>> >> >>   5. Supports enable, disable, and reset operations.
>> >> >>
>> >> >> Add dpdmai to support some platforms with dpaa2 qdma engine.
>> >> >
>> >> >Applied both, thanks
>> >
>> >I see this error when I'm building.
>> >
>> >WARNING: modpost: missing MODULE_LICENSE() in
>> >drivers/dma/fsl-dpaa2-qdma/dpdmai.o
>> >see include/linux/module.h for more information
>> >ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_set_rx_queue"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_get_tx_queue"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_get_rx_queue"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_get_attributes"
>> >[drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
>> >ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko]
>> >undefined!
>> >ERROR: "dpdmai_disable" 

Re: [RFC PATCH v2 10/16] mm,hwpoison: Rework soft offline for free pages

2019-10-22 Thread Naoya Horiguchi
On Tue, Oct 22, 2019 at 12:33:25PM +0200, Oscar Salvador wrote:
> On Tue, Oct 22, 2019 at 12:24:57PM +0200, Michal Hocko wrote:
> > Yes, that makes a perfect sense. What I am saying that the migration
> > (aka trying to recover) is the main and only difference. The soft
> > offline should poison page tables when not able to migrate as well
> > IIUC.
> 
> Yeah, I see your point.
> I do not really why soft-offline strived so much to left the page
> untouched unless it was able to content the problem.
> 
> Note that if we start now to poison pages even if we could not 
> content them (in soft-offline mode), that is a big and visible user
> change.

It's declared that soft offline never disrupts userspace by design,
so if poisoning page tables in migration failure, we could break this
and send SIGBUSs.  Then end users would complain that their processes
are killed by corrected (so non-urgent) errors.

Thanks,
Naoya Horiguchi


Re: [PATCH v2] scsi: lpfc: Honor module parameter lpfc_use_adisc

2019-10-22 Thread Martin K. Petersen


Hi Daniel,

> The initial lpfc_desc_set_adisc implementation dea3101e0a5c ("lpfc:
> add Emulex FC driver version 8.0.28") enabled ADISC if

Fixed up Hannes' email typo and applied to 5.4/scsi-fixes.

Also, please run checkpatch next time. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


[PATCH] dmaengine: fsl-dpaa2-qdma: Fixed build error when enable dpaa2 qdma module driver

2019-10-22 Thread Peng Ma
Fixed the following error:
WARNING: modpost: missing MODULE_LICENSE() in 
drivers/dma/fsl-dpaa2-qdma/dpdmai.o
see include/linux/module.h for more information
GZIParch/arm64/boot/Image.gz
ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_set_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_get_tx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_get_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_get_attributes" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] 
undefined!
ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [sub-make] Error 2

Signed-off-by: Peng Ma 
Reported-by: Anders Roxell 
---
 drivers/dma/fsl-dpaa2-qdma/dpdmai.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c 
b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
index fbc2b2f..f8a1f66 100644
--- a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
+++ b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright 2019 NXP
 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +91,7 @@ int dpdmai_open(struct fsl_mc_io *mc_io, u32 cmd_flags,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_open);
 
 /**
  * dpdmai_close() - Close the control session of the object
@@ -113,6 +115,7 @@ int dpdmai_close(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_close);
 
 /**
  * dpdmai_create() - Create the DPDMAI object
@@ -177,6 +180,7 @@ int dpdmai_enable(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_enable);
 
 /**
  * dpdmai_disable() - Disable the DPDMAI, stop sending and receiving frames.
@@ -197,6 +201,7 @@ int dpdmai_disable(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_disable);
 
 /**
  * dpdmai_reset() - Reset the DPDMAI, returns the object to initial state.
@@ -217,6 +222,7 @@ int dpdmai_reset(struct fsl_mc_io *mc_io, u32 cmd_flags, 
u16 token)
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_reset);
 
 /**
  * dpdmai_get_attributes() - Retrieve DPDMAI attributes.
@@ -252,6 +258,7 @@ int dpdmai_get_attributes(struct fsl_mc_io *mc_io, u32 
cmd_flags,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_get_attributes);
 
 /**
  * dpdmai_set_rx_queue() - Set Rx queue configuration
@@ -285,6 +292,7 @@ int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io, u32 
cmd_flags, u16 token,
/* send command to mc*/
return mc_send_command(mc_io, );
 }
+EXPORT_SYMBOL_GPL(dpdmai_set_rx_queue);
 
 /**
  * dpdmai_get_rx_queue() - Retrieve Rx queue attributes.
@@ -325,6 +333,7 @@ int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io, u32 
cmd_flags, u16 token,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_get_rx_queue);
 
 /**
  * dpdmai_get_tx_queue() - Retrieve Tx queue attributes.
@@ -364,3 +373,6 @@ int dpdmai_get_tx_queue(struct fsl_mc_io *mc_io, u32 
cmd_flags,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dpdmai_get_tx_queue);
+
+MODULE_LICENSE("GPL v2");
-- 
2.9.5



Re: [PATCH v2] usercopy: Avoid soft lockups in test_check_nonzero_user()

2019-10-22 Thread Michael Ellerman
Christian Brauner  writes:
> On Thu, Oct 17, 2019 at 09:00:48AM +1100, Michael Ellerman wrote:
>> Christian Brauner  writes:
>> > On Wed, Oct 16, 2019 at 11:27:32PM +1100, Michael Ellerman wrote:
>> >> On a machine with a 64K PAGE_SIZE, the nested for loops in
>> >> test_check_nonzero_user() can lead to soft lockups, eg:
>> >> 
>> >>   watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [modprobe:611]
>> >>   Modules linked in: test_user_copy(+) vmx_crypto gf128mul crc32c_vpmsum 
>> >> virtio_balloon ip_tables x_tables autofs4
>> >>   CPU: 4 PID: 611 Comm: modprobe Tainted: G L
>> >> 5.4.0-rc1-gcc-8.2.0-1-gf5a1a536fa14-dirty #1151
>> >>   ...
>> >>   NIP __might_sleep+0x20/0xc0
>> >>   LR  __might_fault+0x40/0x60
>> >>   Call Trace:
>> >> check_zeroed_user+0x12c/0x200
>> >> test_user_copy_init+0x67c/0x1210 [test_user_copy]
>> >> do_one_initcall+0x60/0x340
>> >> do_init_module+0x7c/0x2f0
>> >> load_module+0x2d94/0x30e0
>> >> __do_sys_finit_module+0xc8/0x150
>> >> system_call+0x5c/0x68
>> >> 
>> >> Even with a 4K PAGE_SIZE the test takes multiple seconds. Instead
>> >> tweak it to only scan a 1024 byte region, but make it cross the
>> >> page boundary.
>> >> 
>> >> Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
>> >> Suggested-by: Aleksa Sarai 
>> >> Signed-off-by: Michael Ellerman 
>> >
>> > With Aleksa's Reviewed-by I've picked this up:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=copy_struct_from_user
>> 
>> Thanks. Are you planning to send that to Linus for v5.4 or v5.5 ?
>
> This looks like a pretty straight bugfix to me since it's clearly
> causing an issue for you on power so v5.4-rc4 is what I'd aim for. I
> just want it to be in linux-next until tomorrow.

I see it in mainine now, thanks!

cheers


Re: [RFC PATCH v2 10/16] mm,hwpoison: Rework soft offline for free pages

2019-10-22 Thread Naoya Horiguchi
On Tue, Oct 22, 2019 at 11:58:52AM +0200, Oscar Salvador wrote:
> On Tue, Oct 22, 2019 at 11:22:56AM +0200, Michal Hocko wrote:
> > Hmm, that might be a misunderstanding on my end. I thought that it is
> > the MCE handler to say whether the failure is recoverable or not. If yes
> > then we can touch the content of the memory (that would imply the
> > migration). Other than that both paths should be essentially the same,
> > no? Well unrecoverable case would be essentially force migration failure
> > path.
> > 
> > MADV_HWPOISON is explicitly documented to test MCE handling IIUC:
> > : This feature is intended for testing of memory error-handling
> > : code; it is available only if the kernel was configured with
> > : CONFIG_MEMORY_FAILURE.
> > 
> > There is no explicit note about the type of the error that is injected
> > but I think it is reasonably safe to assume this is a recoverable one.
> 
> MADV_HWPOISON stands for hard-offline.
> MADV_SOFT_OFFLINE stands for soft-offline.

Maybe MADV_HWPOISON should've be named like MADV_HARD_OFFLINE, although
it's API and hard to change once implemented.

> 
> MADV_SOFT_OFFLINE (since Linux 2.6.33)
>   Soft offline the pages in the range specified by addr and
>   length.  The memory of each page in the specified range is
>   preserved (i.e., when next accessed, the same content will be
>   visible, but in a new physical page frame), and the original
>   page is offlined (i.e., no longer used, and taken out of
>   normal memory management).  The effect of the
>   MADV_SOFT_OFFLINE operation is invisible to (i.e., does not
>   change the semantics of) the calling process.
> 
>   This feature is intended for testing of memory error-handling
>   code;

Although this expression might not clear enough, madvise(MADV_HWPOISON or
MADV_SOFT_OFFLINE) only covers memory error handling part, not MCE handling
part.  We have some other injection methods in the lower layers like
mce-inject and APEI.

> it is available only if the kernel was configured with
>   CONFIG_MEMORY_FAILURE.
> 
> 
> But both follow different approaches.
> 
> I think it is up to some controlers to trigger soft-offline or hard-offline:

Yes, I think so.  One usecase of soft offline is triggered by CMCI interrupt
in Intel CPU.  CMCI handler stores corrected error events in /dev/mcelog.
mcelogd polls on this device file and if corrected errors occur often enough
(IIRC the default threshold is "10 events in 24 hours",) mcelogd triggers
soft-offline via soft_offline_page under /sys.

OTOH, hard-offline is triggered directly (accurately over ring buffer to 
separate
context) from MCE handler.  mcelogd logs MCE events but does not involve in
page offline logic.

> 
> static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, 
> int sev)
> {
> #ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE
>   ...
> /* iff following two events can be handled properly by now */
> if (sec_sev == GHES_SEV_CORRECTED &&
> (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED))
> flags = MF_SOFT_OFFLINE;
> if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE)
> flags = 0;
> 
> if (flags != -1)
> memory_failure_queue(pfn, flags);
>   ...
> #endif
>  }
> 
> 
> static void memory_failure_work_func(struct work_struct *work)
> {
>   ...
>   for (;;) {
>   spin_lock_irqsave(_cpu->lock, proc_flags);
>   gotten = kfifo_get(_cpu->fifo, );
>   spin_unlock_irqrestore(_cpu->lock, proc_flags);
>   if (!gotten)
>   break;
>   if (entry.flags & MF_SOFT_OFFLINE)
>   soft_offline_page(pfn_to_page(entry.pfn), entry.flags);
>   else
>   memory_failure(entry.pfn, entry.flags);
>   }
>  }
> 
> AFAICS, for hard-offline case, a recovered event would be if:
> 
> - the page to shut down is already free
> - the page was unmapped
> 
> In some cases we need to kill the process if it holds dirty pages.

One caveat is that even if the process maps dirty error pages, we
don't have to kill it unless the error data is consumed.

Thanks,
Naoya Horiguchi


Re: [PATCH 3/3] x86/ftrace: Use text_poke()

2019-10-22 Thread Steven Rostedt
On Tue, 22 Oct 2019 18:17:40 -0400
Steven Rostedt  wrote:

> > your solution is to reduce the overhead.
> > my solution is to remove it competely. See the difference?  
> 
> You're just trimming it down. I'm curious to what overhead you save by
> not saving all parameter registers, and doing a case by case basis?

I played with adding a ftrace_ip_caller, that only modifies the ip, and
passes a regs with bare minimum saved (allowing the callback to modify
the regs->ip).

I modified the test-events-sample to just hijack the do_raw_spin_lock()
function, which is a very hot path, as it is called by most of the
spin_lock code.

I then ran:

 # perf stat -r 20 /work/c/hackbench 50

vanilla, as nothing is happening.

I then enabled the test-events-sample with the new ftrace ip
modification only.

I then had it do the hijack of do_raw_spin_lock() with the current
ftrace_regs_caller that kprobes and live kernel patching use.

The improvement was quite noticeable.

Baseline: (no tracing)

# perf stat -r 20 /work/c/hackbench 50
Time: 1.146
Time: 1.120
Time: 1.102
Time: 1.099
Time: 1.136
Time: 1.123
Time: 1.128
Time: 1.115
Time: 1.111
Time: 1.192
Time: 1.160
Time: 1.156
Time: 1.135
Time: 1.144
Time: 1.150
Time: 1.120
Time: 1.121
Time: 1.120
Time: 1.106
Time: 1.127

 Performance counter stats for '/work/c/hackbench 50' (20 runs):

  9,056.18 msec task-clock#6.770 CPUs utilized  
  ( +-  0.26% )
   148,461  context-switches  #0.016 M/sec  
  ( +-  2.58% )
18,397  cpu-migrations#0.002 M/sec  
  ( +-  3.24% )
54,029  page-faults   #0.006 M/sec  
  ( +-  0.63% )
33,227,808,738  cycles#3.669 GHz
  ( +-  0.25% )
23,314,273,335  stalled-cycles-frontend   #   70.16% frontend cycles 
idle ( +-  0.25% )
23,568,794,330  instructions  #0.71  insn per cycle 

  #0.99  stalled cycles per 
insn  ( +-  0.26% )
 3,756,521,438  branches  #  414.802 M/sec  
  ( +-  0.29% )
36,949,690  branch-misses #0.98% of all branches
  ( +-  0.46% )

1.3377 +- 0.0213 seconds time elapsed  ( +-  1.59% )

Using IPMODIFY without regs:

# perf stat -r 20 /work/c/hackbench 50
Time: 1.193
Time: 1.115
Time: 1.145
Time: 1.129
Time: 1.121
Time: 1.132
Time: 1.136
Time: 1.156
Time: 1.133
Time: 1.131
Time: 1.138
Time: 1.150
Time: 1.147
Time: 1.137
Time: 1.178
Time: 1.121
Time: 1.142
Time: 1.158
Time: 1.143
Time: 1.168

 Performance counter stats for '/work/c/hackbench 50' (20 runs):

  9,231.39 msec task-clock#6.917 CPUs utilized  
  ( +-  0.39% )
   136,822  context-switches  #0.015 M/sec  
  ( +-  3.06% )
17,308  cpu-migrations#0.002 M/sec  
  ( +-  2.61% )
54,521  page-faults   #0.006 M/sec  
  ( +-  0.57% )
33,875,937,399  cycles#3.670 GHz
  ( +-  0.39% )
23,575,136,580  stalled-cycles-frontend   #   69.59% frontend cycles 
idle ( +-  0.41% )
24,246,404,007  instructions  #0.72  insn per cycle 

  #0.97  stalled cycles per 
insn  ( +-  0.33% )
 3,878,453,510  branches  #  420.138 M/sec  
  ( +-  0.36% )
47,653,911  branch-misses #1.23% of all branches
  ( +-  0.43% )

   1.33462 +- 0.00440 seconds time elapsed  ( +-  0.33% )


The current ftrace_regs_caller: (old way of doing it)

# perf stat -r 20 /work/c/hackbench 50
Time: 1.114
Time: 1.153
Time: 1.236
Time: 1.208
Time: 1.179
Time: 1.183
Time: 1.217
Time: 1.190
Time: 1.157
Time: 1.172
Time: 1.215
Time: 1.165
Time: 1.171
Time: 1.188
Time: 1.176
Time: 1.217
Time: 1.341
Time: 1.238
Time: 1.363
Time: 1.287

 Performance counter stats for '/work/c/hackbench 50' (20 runs):

  9,522.76 msec task-clock#6.653 CPUs utilized  
  ( +-  0.36% )
   131,347  context-switches  #0.014 M/sec  
  ( +-  3.37% )
17,090  cpu-migrations#0.002 M/sec  
  ( +-  3.56% )
54,126  page-faults   #0.006 M/sec  
  ( +-  0.71% )
34,942,273,861  cycles#3.669 GHz
  ( +-  0.35% )
24,517,757,272  stalled-cycles-frontend   #   70.17% frontend cycles 
idle ( +-  0.35% )
24,684,124,265  instructions  #0.71  insn per cycle 

  #0.99  

[PATCH v2] cpuidle: not unset the driver if it already exist

2019-10-22 Thread Zhenzhong Duan
__cpuidle_set_driver() check if there is an already exist driver and
unset it before return with -EBUSY. The next call will succeed as it's
just unset.

check if any of the CPUs in the mask have a driver different from drv
already and if so return -EBUSY before updating any cpuidle_drivers
per-CPU pointers.

Signed-off-by: Zhenzhong Duan 
---
v2: update code logic per Rafael

 drivers/cpuidle/driver.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 80c1a83..acfce04 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -62,24 +62,23 @@ static inline void __cpuidle_unset_driver(struct 
cpuidle_driver *drv)
  * __cpuidle_set_driver - set per CPU driver variables for the given driver.
  * @drv: a valid pointer to a struct cpuidle_driver
  *
- * For each CPU in the driver's cpumask, unset the registered driver per CPU
- * to @drv.
- *
- * Returns 0 on success, -EBUSY if the CPUs have driver(s) already.
+ * Returns 0 on success, -EBUSY if any CPU in the cpumask have a driver
+ * different from drv already.
  */
 static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
 {
int cpu;
 
for_each_cpu(cpu, drv->cpumask) {
+   struct cpuidle_driver *old_drv;
 
-   if (__cpuidle_get_cpu_driver(cpu)) {
-   __cpuidle_unset_driver(drv);
+   old_drv = __cpuidle_get_cpu_driver(cpu);
+   if (old_drv && old_drv != drv)
return -EBUSY;
-   }
+   }
 
+   for_each_cpu(cpu, drv->cpumask)
per_cpu(cpuidle_drivers, cpu) = drv;
-   }
 
return 0;
 }
-- 
1.8.3.1



[PATCH 0/3] perf: Allow running without stdin

2019-10-22 Thread Igor Lubashev
This series allows perf to run in batch mode with stdin closed.
This is arguably a bug fix for code that runs with --stdio option and does not
check for EOF return code from getc().

This series makes the following work as expected:

  $ perf top --stdio < /dev/null
  $ perf kvm top --stdio < /dev/null

Patches:
  01: perf top: Allow running without stdin
Make "perf top --stdio" handle EOF from stdin correctly.
There is one getc() that does not handle EOF explicitly, since its return
value is checked against a list of known characters, and the main loop in
display_thread() will handle the EOF on the next iteration.

  02: perf kvm: Allow running without stdin
Make "perf kvm --stdio" handle EOF from stdin correctly.

  03: perf kvm: Use evlist layer api when possible
This is a simple fix for a needless layering violation.

Igor Lubashev (3):
  perf top: Allow running without stdin
  perf kvm: Allow running without stdin
  perf kvm: Use evlist layer api when possible

 tools/perf/builtin-kvm.c | 35 +--
 tools/perf/builtin-top.c | 10 --
 2 files changed, 29 insertions(+), 16 deletions(-)

-- 
2.7.4



[PATCH 3/3] perf kvm: Use evlist layer api when possible

2019-10-22 Thread Igor Lubashev
No need for layer violations when a proper evlist api is available.

Signed-off-by: Igor Lubashev 
---
 tools/perf/builtin-kvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 5217aa3596c7..340927c2b243 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1005,7 +1005,7 @@ static int kvm_events_live_report(struct perf_kvm_stat 
*kvm)
}
 
if (!rc && !done)
-   err = fdarray__poll(fda, 100);
+   err = evlist__poll(kvm->evlist, 100);
}
 
evlist__disable(kvm->evlist);
-- 
2.7.4



[PATCH 2/3] perf kvm: Allow running without stdin

2019-10-22 Thread Igor Lubashev
Allow perf kvm --stdio to run without access to stdin.
This lets perf kvm to run in a batch mode until interrupted.

The following now works as expected:

  $ perf kvm top --stdio < /dev/null

Signed-off-by: Igor Lubashev 
---
 tools/perf/builtin-kvm.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 858da896b518..5217aa3596c7 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -930,18 +930,20 @@ static int fd_set_nonblock(int fd)
 
 static int perf_kvm__handle_stdin(void)
 {
-   int c;
-
-   c = getc(stdin);
-   if (c == 'q')
+   switch (getc(stdin)) {
+   case 'q':
+   done = 1;
return 1;
-
-   return 0;
+   case EOF:
+   return 0;
+   default:
+   return 1;
+   }
 }
 
 static int kvm_events_live_report(struct perf_kvm_stat *kvm)
 {
-   int nr_stdin, ret, err = -EINVAL;
+   int nr_stdin = -1, ret, err = -EINVAL;
struct termios save;
 
/* live flag must be set first */
@@ -972,13 +974,16 @@ static int kvm_events_live_report(struct perf_kvm_stat 
*kvm)
if (evlist__add_pollfd(kvm->evlist, kvm->timerfd) < 0)
goto out;
 
-   nr_stdin = evlist__add_pollfd(kvm->evlist, fileno(stdin));
-   if (nr_stdin < 0)
-   goto out;
-
if (fd_set_nonblock(fileno(stdin)) != 0)
goto out;
 
+   /* add stdin, if it is connected */
+   if (getc(stdin) != EOF) {
+   nr_stdin = evlist__add_pollfd(kvm->evlist, fileno(stdin));
+   if (nr_stdin < 0)
+   goto out;
+   }
+
/* everything is good - enable the events and process */
evlist__enable(kvm->evlist);
 
@@ -994,8 +999,10 @@ static int kvm_events_live_report(struct perf_kvm_stat 
*kvm)
if (err)
goto out;
 
-   if (fda->entries[nr_stdin].revents & POLLIN)
-   done = perf_kvm__handle_stdin();
+   if (nr_stdin >= 0 && fda->entries[nr_stdin].revents & POLLIN) {
+   if (!perf_kvm__handle_stdin())
+   fda->entries[nr_stdin].events = 0;
+   }
 
if (!rc && !done)
err = fdarray__poll(fda, 100);
-- 
2.7.4



Re: [BUGFIX PATCH v2 1/5] selftests: proc: Make va_max 1GB on 32bit arch

2019-10-22 Thread Masami Hiramatsu
On Mon, 21 Oct 2019 20:30:53 +0300
Alexey Dobriyan  wrote:

> On Mon, Oct 21, 2019 at 05:28:09PM +0900, Masami Hiramatsu wrote:
> > Currently proc-self-map-files-002.c sets va_max (max test address
> > of user virtual address) to 4GB, but it is too big for 32bit
> > arch and 1UL << 32 is overflow on 32bit long.
> > 
> > Make va_max 1GB on 32bit arch like i386 and arm.
> 
> > +#if __BITS_PER_LONG == 32
> > +# define VA_MAX (1UL << 30)
> > +#elif __BITS_PER_LONG == 64
> > +# define VA_MAX (1UL << 32)
> > +#else
> > +# define VA_MAX 0
> > +#endif
> > +
> >  int main(void)
> >  {
> > const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
> > -   const unsigned long va_max = 1UL << 32;
> > +   const unsigned long va_max = VA_MAX;
> 
> No, just make it like 1MB unconditionally.

Ah, I sse. BTW, would you mean 1GB?

> This is not intended to cover all address space, just large enough part
> (larger than reasonable vm.mmap_min_addr)

Then, should we better to check the /proc/sys/vm/mmap_min_addr?

Thank you,

-- 
Masami Hiramatsu 


[PATCH 1/3] perf top: Allow running without stdin

2019-10-22 Thread Igor Lubashev
Allow perf top --stdio to run without access to stdin.
This lets perf top to run in a batch mode until interrupted.

The following now works as expected:

  $ perf top < /dev/null

Signed-off-by: Igor Lubashev 
---
 tools/perf/builtin-top.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index d96f24c8770d..fbc0dc135b8a 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -665,6 +665,7 @@ static void display_setup_sig(void)
 static void *display_thread(void *arg)
 {
struct pollfd stdin_poll = { .fd = 0, .events = POLLIN };
+   nfds_t nfds = 1;
struct termios save;
struct perf_top *top = arg;
int delay_msecs, c;
@@ -684,7 +685,8 @@ static void *display_thread(void *arg)
delay_msecs = top->delay_secs * MSEC_PER_SEC;
set_term_quiet_input();
/* trash return*/
-   getc(stdin);
+   if (getc(stdin) == EOF)
+   nfds = 0;
 
while (!done) {
perf_top__print_sym_table(top);
@@ -692,7 +694,7 @@ static void *display_thread(void *arg)
 * Either timeout expired or we got an EINTR due to SIGWINCH,
 * refresh screen in both cases.
 */
-   switch (poll(_poll, 1, delay_msecs)) {
+   switch (poll(_poll, nfds, delay_msecs)) {
case 0:
continue;
case -1:
@@ -701,6 +703,10 @@ static void *display_thread(void *arg)
__fallthrough;
default:
c = getc(stdin);
+   if (c == EOF) {
+   nfds = 0;
+   continue;
+   }
tcsetattr(0, TCSAFLUSH, );
 
if (perf_top__handle_keypress(top, c))
-- 
2.7.4



[PATCH v1 1/2] scsi: ufs: export hibern8 entry and exit

2019-10-22 Thread Asutosh Das
Qualcomm controllers need to be in hibern8 before scaling up
or down the clocks. Hence, export the hibern8 entry and exit
functions.

Signed-off-by: Asutosh Das 
---
 drivers/scsi/ufs/ufshcd.c | 8 
 drivers/scsi/ufs/ufshcd.h | 3 ++-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c28c144..57d9315 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -250,8 +250,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
 static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
 bool skip_ref_clk);
 static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
-static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
-static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
 static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
 static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
 static void ufshcd_resume_clkscaling(struct ufs_hba *hba);
@@ -3904,7 +3902,7 @@ static int __ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
return ret;
 }
 
-static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
+int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
 {
int ret = 0, retries;
 
@@ -3916,8 +3914,9 @@ static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
 out:
return ret;
 }
+EXPORT_SYMBOL_GPL(ufshcd_uic_hibern8_enter);
 
-static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
+int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
 {
struct uic_command uic_cmd = {0};
int ret;
@@ -3943,6 +3942,7 @@ static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(ufshcd_uic_hibern8_exit);
 
 static void ufshcd_auto_hibern8_enable(struct ufs_hba *hba)
 {
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index e0fe247..1e3daf5 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -1107,5 +1107,6 @@ static inline u8 ufshcd_scsi_to_upiu_lun(unsigned int 
scsi_lun)
 
 int ufshcd_dump_regs(struct ufs_hba *hba, size_t offset, size_t len,
 const char *prefix);
-
+int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
+int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
 #endif /* End of Header */
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



[PATCH v1 2/2] scsi: ufs-qcom: enter and exit hibern8 during clock scaling

2019-10-22 Thread Asutosh Das
Qualcomm controller needs to be in hibern8 before scaling clocks.
This change puts the controller in hibern8 state before scaling
and brings it out after scaling of clocks.

Signed-off-by: Asutosh Das 
---
 drivers/scsi/ufs/ufs-qcom.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index a5b7148..d117088 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1305,6 +1305,9 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba *hba,
int err = 0;
 
if (status == PRE_CHANGE) {
+   err = ufshcd_uic_hibern8_enter(hba);
+   if (err)
+   return err;
if (scale_up)
err = ufs_qcom_clk_scale_up_pre_change(hba);
else
@@ -1324,6 +1327,7 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba *hba,
dev_req_params->hs_rate,
false);
ufs_qcom_update_bus_bw_vote(host);
+   ufshcd_uic_hibern8_exit(hba);
}
 
 out:
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



Re: [PATCH v7 3/5] x86/kvm: Add "nopvspin" parameter to disable PV spinlocks

2019-10-22 Thread Zhenzhong Duan



On 2019/10/23 5:03, Sean Christopherson wrote:

On Tue, Oct 22, 2019 at 08:46:46PM +0800, Zhenzhong Duan wrote:

Hi Vitaly,

On 2019/10/22 19:36, Vitaly Kuznetsov wrote:


Zhenzhong Duan  writes:


...snip


diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 249f14a..3945aa5 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -825,18 +825,36 @@ __visible bool __kvm_vcpu_is_preempted(long cpu)
   */
  void __init kvm_spinlock_init(void)
  {
-   /* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-   if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
+   /*
+* In case host doesn't support KVM_FEATURE_PV_UNHALT there is still an
+* advantage of keeping virt_spin_lock_key enabled: virt_spin_lock() is
+* preferred over native qspinlock when vCPU is preempted.
+*/
+   if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) {
+   pr_info("PV spinlocks disabled, no host support.\n");
return;
+   }
+   /*
+* Disable PV qspinlock and use native qspinlock when dedicated pCPUs
+* are available.
+*/
if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
-   static_branch_disable(_spin_lock_key);
-   return;
+   pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME 
hints.\n");
+   goto out;
}
-   /* Don't use the pvqspinlock code if there is only 1 vCPU. */
-   if (num_possible_cpus() == 1)
-   return;
+   if (num_possible_cpus() == 1) {
+   pr_info("PV spinlocks disabled, single CPU.\n");
+   goto out;
+   }
+
+   if (nopvspin) {
+   pr_info("PV spinlocks disabled, forced by \"nopvspin\" 
parameter.\n");
+   goto out;
+   }
+
+   pr_info("PV spinlocks enabled\n");
__pv_init_lock_hash();
pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
@@ -849,6 +867,8 @@ void __init kvm_spinlock_init(void)
pv_ops.lock.vcpu_is_preempted =
PV_CALLEE_SAVE(__kvm_vcpu_is_preempted);
}
+out:
+   static_branch_disable(_spin_lock_key);

You probably need to add 'return' before 'out:' as it seems you're
disabling virt_spin_lock_key in all cases now).

virt_spin_lock_key is kept enabled in 
!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)
case which is the only case virt_spin_lock() optimization is used.

When PV qspinlock is enabled, virt_spin_lock() isn't called in
__pv_queued_spin_lock_slowpath() in which case we don't care
virt_spin_lock_key's value.

So adding 'return' or not are both ok, I chosed to save a line,
let me know if you prefer to add a 'return' and I'll change it.

It'd be worth adding a comment here if you end up spinning another version
to change the logging prefix.  The logic is sound and I like the end
result, but I had the same knee jerk "this can't be right!?!?" reaction as
Vitaly.


Sure, will do in next version.

Thanks

Zhenzhong



Re: [PATCH] mm: thp: handle page cache THP correctly in PageTransCompoundMap

2019-10-22 Thread Hugh Dickins
On Tue, 22 Oct 2019, Yang Shi wrote:
> On 10/22/19 3:27 PM, Hugh Dickins wrote:
> > 
> > I completely agree that the current PageTransCompoundMap() is wrong.
> > 
> > A fix for that is one of many patches I've not yet got to upstreaming.
> > Comparing yours and mine, I'm worried by your use of PageDoubleMap(),
> > because really that's a flag for anon THP, and not properly supported
> > on shmem (or now I suppose file) THP - I forget the details, is it
> > that it sometimes gets set, but never cleared?  Generally, we just
> > don't refer to PageDoubleMap() on shmem THPs (but there may be
> > exceptions: sorting out the THP mapcount maze, and eliminating
> > PageDoubleMap(), is one of my long-held ambitions, not yet reached).
> > 
> > Here's the patch I've been carrying, but it's from earlier, so I
> > should warn that I've done no more than build-testing it on 5.4,
> > and I'm too far away from these issues at the moment to be able to
> > make a good judgement or argue for it - I hope you and others can
> > decide which patch is the better.  I should also add that we're
> > barely using PageTransCompoundMap() at all: at best it can only
> > give a heuristic guess as to whether the page is pmd-mapped in
> > any particular case, and we preferred to take forward the KVM
> > patches we posted back in April 2016, plumbing hva down to where
> > it's needed - though of course those are somewhat different now.
> 
> Thanks for catching this. I was definitely thinking about using
> compount_mapcount instead of DoubleMap flag when I was working the patch. I
> just simply thought it would change less file by using DoubleMap flag but I
> didn't notice it was kind of unbalanced for file THP.
> 
> With the unbalanced DoubleMap flag, it sounds better to use
> compound_mapcount.

Yes: no doubt PageDoubleMap could be fixed on shmem+file, but I have no
interest in doing that, because it's just unnecessary overhead for them.
(They have their own overhead, of subpage mapcounting for pmd: which is
something to eliminate and unify with anon when I get around to it.)

> 
> Thanks for sharing your patch, I'm going to rework v2 by using
> compound_mapcount. Do you mind I might steal your patch?

Please do! One less for me to worry about, thanks.

> 
> I'm supposed we'd better fix this bug regardless of whether you would like to
> move forward your KVM patches.

Absolutely. There remain a few other uses of PageTransCompoundMap
anyway, and I really wanted this outright mm fix to go in before
re-submitting AndresLC's KVM patch (I'll ask a KVM-savvy colleague
to take that over, Cc'ing you, once the mm end is correct).

Hugh


Re: [PATCH v7 2/5] x86/kvm: Change print code to use pr_*() format

2019-10-22 Thread Zhenzhong Duan



On 2019/10/23 5:01, Sean Christopherson wrote:

On Mon, Oct 21, 2019 at 05:11:13PM +0800, Zhenzhong Duan wrote:

pr_*() is preferred than printk(KERN_* ...), after change all the print
in arch/x86/kernel/kvm.c will have "kvm_guest: xxx" style.

No functional change.

Signed-off-by: Zhenzhong Duan 
Reviewed-by: Vitaly Kuznetsov 
Cc: Paolo Bonzini 
Cc: Radim Krcmar 
Cc: Sean Christopherson 
Cc: Vitaly Kuznetsov 
Cc: Wanpeng Li 
Cc: Jim Mattson 
Cc: Joerg Roedel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
---
  arch/x86/kernel/kvm.c | 30 --
  1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 3bc6a266..249f14a 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -7,6 +7,8 @@
   *   Authors: Anthony Liguori 
   */
  
+#define pr_fmt(fmt) "kvm_guest: " fmt

Sort of a silly nit, especially since I suggested kvm_guest...

What about using kvm-guest instead of kvm_guest to be consistent with
kvm-clock, the other prolific logger in a KVM guest.

E.g.

   kvm-clock: cpu 1, msr 551e041, secondary cpu clock
   kvm-guest: setup async PF for cpu 1
   kvm-guest: stealtime: cpu 1, msr 277695f40
   kvm-clock: cpu 2, msr 551e081, secondary cpu clock
   kvm-guest: setup async PF for cpu 2
   kvm-guest: stealtime: cpu 2, msr 277715f40
   kvm-clock: cpu 3, msr 551e0c1, secondary cpu clock
   kvm-guest: setup async PF for cpu 3
   kvm-guest: stealtime: cpu 3, msr 277795f40
   kvm-clock: cpu 4, msr 551e101, secondary cpu clock
   
instead of


   kvm-clock: cpu 1, msr 551e041, secondary cpu clock
   kvm_guest: setup async PF for cpu 1
   kvm_guest: stealtime: cpu 1, msr 277695f40
   kvm-clock: cpu 2, msr 551e081, secondary cpu clock
   kvm_guest: setup async PF for cpu 2
   kvm_guest: stealtime: cpu 2, msr 277715f40
   kvm-clock: cpu 3, msr 551e0c1, secondary cpu clock
   kvm_guest: setup async PF for cpu 3
   kvm_guest: stealtime: cpu 3, msr 277795f40
   kvm-clock: cpu 4, msr 551e101, secondary cpu clock


Good suggestion, will do, thanks for point out.

Zhenzhong



Re: [PATCH v3] scripts/nsdeps: use alternative sed delimiter

2019-10-22 Thread Masahiro Yamada
On Tue, Oct 22, 2019 at 8:04 PM Jessica Yu  wrote:
>
> When doing an out of tree build with O=, the nsdeps script constructs
> the absolute pathname of the module source file so that it can insert
> MODULE_IMPORT_NS statements in the right place. However, ${srctree}
> contains an unescaped path to the source tree, which, when used in a sed
> substitution, makes sed complain:
>
> ++ sed 's/[^ ]* *//home/jeyu/jeyu-linux\/&/g'
> sed: -e expression #1, char 12: unknown option to `s'
>
> The sed substitution command 's' ends prematurely with the forward
> slashes in the pathname, and sed errors out when it encounters the 'h',
> which is an invalid sed substitution option. To avoid escaping forward
> slashes ${srctree}, we can use '|' as an alternative delimiter for
> sed instead to avoid this error.
>
> Signed-off-by: Jessica Yu 
> ---
>
> v3: don't need to escape '/' since we're using a different delimiter.
>
>  scripts/nsdeps | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/nsdeps b/scripts/nsdeps
> index 3754dac13b31..dda6fbac016e 100644
> --- a/scripts/nsdeps
> +++ b/scripts/nsdeps
> @@ -33,7 +33,7 @@ generate_deps() {
> if [ ! -f "$ns_deps_file" ]; then return; fi
> local mod_source_files=`cat $mod_file | sed -n 1p 
>  \
>   | sed -e 's/\.o/\.c/g'  
>  \
> - | sed "s/[^ ]* 
> */${srctree}\/&/g"`
> + | sed "s|[^ ]* 
> *|${srctree}/&|g"`
> for ns in `cat $ns_deps_file`; do
> echo "Adding namespace $ns to module $mod_name (if needed)."
> generate_deps_for_ns $ns $mod_source_files
> --
> 2.16.4
>

Reviewed-by: Masahiro Yamada 

-- 
Best Regards
Masahiro Yamada


[PATCH] Input: synaptics-rmi4 - validate that the rmi_dev pointer is set before dereferencing it

2019-10-22 Thread Andrew Duggan
A bug in hid-rmi was causing rmi_unregister_transport_device() to be
called even if the call to rmi_register_transport_device() failed to
allocate the rmi device. A patch has been submitted to fix the issue in
hid-rmi. This patch will ensure that should a simialr situation
occur then the rmi driver will not dereference a NULL pointer.

Signed-off-by: Andrew Duggan 
---
 drivers/input/rmi4/rmi_bus.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index af706a583656..6c3abae1e159 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -118,8 +118,10 @@ void rmi_unregister_transport_device(struct 
rmi_transport_dev *xport)
 {
struct rmi_device *rmi_dev = xport->rmi_dev;
 
-   device_del(_dev->dev);
-   put_device(_dev->dev);
+   if (rmi_dev) {
+   device_del(_dev->dev);
+   put_device(_dev->dev);
+   }
 }
 EXPORT_SYMBOL(rmi_unregister_transport_device);
 
-- 
2.20.1



[PATCH] HID: rmi: Check that the RMI_STARTED bit is set before unregistering the RMI transport device

2019-10-22 Thread Andrew Duggan
In the event that the RMI device is unreachable, the calls to
rmi_set_mode() or rmi_set_page() will fail before registering the RMI
transport device. When the device is removed, rmi_remove() will call
rmi_unregister_transport_device() which will attempt to access the
rmi_dev pointer which was not set. This patch adds a check of the
RMI_STARTED bit before calling rmi_unregister_transport_device().
The RMI_STARTED bit is only set after rmi_register_transport_device()
completes successfully. A subsequent patch in the RMI core will add
checks to validate the pointers before accessing them.

The kernel oops was reported in this message:
https://www.spinics.net/lists/linux-input/msg58433.html

Signed-off-by: Andrew Duggan 
Reported-by: Federico Cerutti 
---
 drivers/hid/hid-rmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 7c6abd7e0979..9ce22acdfaca 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -744,7 +744,8 @@ static void rmi_remove(struct hid_device *hdev)
 {
struct rmi_data *hdata = hid_get_drvdata(hdev);
 
-   if (hdata->device_flags & RMI_DEVICE) {
+   if ((hdata->device_flags & RMI_DEVICE)
+   && test_bit(RMI_STARTED, >flags)) {
clear_bit(RMI_STARTED, >flags);
cancel_work_sync(>reset_work);
rmi_unregister_transport_device(>xport);
-- 
2.20.1



Re: [PATCH v7 5/7] kvm: x86: Add CET CR4 bit and XSS support

2019-10-22 Thread Yang Weijiang
On Tue, Oct 22, 2019 at 01:13:21PM -0700, Sean Christopherson wrote:
> On Fri, Oct 18, 2019 at 09:58:02AM +0800, Yang Weijiang wrote:
> > On Thu, Oct 17, 2019 at 12:56:42PM -0700, Sean Christopherson wrote:
> > > On Wed, Oct 02, 2019 at 12:05:23PM -0700, Jim Mattson wrote:
> > > > > +   u64 kvm_xss = kvm_supported_xss();
> > > > > +
> > > > > +   best->ebx =
> > > > > +   xstate_required_size(vcpu->arch.xcr0 | 
> > > > > kvm_xss, true);
> > > > 
> > > > Shouldn't this size be based on the *current* IA32_XSS value, rather
> > > > than the supported IA32_XSS bits? (i.e.
> > > > s/kvm_xss/vcpu->arch.ia32_xss/)
> > > 
> > > Ya.
> > >
> > I'm not sure if I understand correctly, kvm_xss is what KVM supports,
> > but arch.ia32_xss reflects what guest currently is using, shoudn't CPUID
> > report what KVM supports instead of current status?
> > Will CPUID match current IA32_XSS status if guest changes it runtime?
> 
> Not in this case.  Select CPUID output is dependent on current state as
> opposed to being a constant defind by hardware.  Per the SDM, EBX is:
> 
>   The size in bytes of the XSAVE area containing all states enabled by
>   XCRO | IA32_XSS
> 
> Since KVM is emulating CPUID for the guest, XCR0 and IA32_XSS in this
> context refers to the guest's current/actual XCR0/IA32_XSS values.  The
> purpose of this behavior is so that software can call CPUID to query the
> actual amount of memory that is needed for XSAVE(S), as opposed to the
> absolute max size that _might_ be needed.
> 
> MONITOR/MWAIT is the other case that comes to mind where CPUID dynamically
> reflects configured state, e.g. MWAIT is reported as unsupported if it's
> disabled via IA32_MISC_ENABLE MSR.
Yep, make sense, thank you for explanation.


Re: [PATCH v7 1/7] KVM: CPUID: Fix IA32_XSS support in CPUID(0xd,i) enumeration

2019-10-22 Thread Yang Weijiang
On Tue, Oct 22, 2019 at 12:46:15PM -0700, Sean Christopherson wrote:
> On Fri, Oct 18, 2019 at 09:28:09AM +0800, Yang Weijiang wrote:
> > On Thu, Oct 17, 2019 at 12:46:22PM -0700, Sean Christopherson wrote:
> > > On Wed, Oct 02, 2019 at 10:26:10AM -0700, Jim Mattson wrote:
> > > > > +   entry->eax = 0;
> > > > > +   entry->ebx = 0;
> > > > > +   entry->ecx = 0;
> > > > > +   entry->edx = 0;
> > > > > +   return;
> > > > > +   }
> > > > > +   if (entry->ecx)
> > > > > +   entry->ebx = 0;
> > > > 
> > > > This seems to back up my claims above regarding the EBX output for
> > > > cases 0 and 1, but aside from those subleaves, is this correct? For
> > > > subleaves > 1, ECX bit 1 can be set for extended state components that
> > > > need to be cache-line aligned. Such components could map to a valid
> > > > bit in XCR0 and have a non-zero offset from the beginning of the
> > > > non-compacted XSAVE area.
> > > > 
> > > > > +   entry->edx = 0;
> > > > 
> > > > This seems too aggressive. See my comments above regarding EDX outputs
> > > > for cases 0 and 1.
> > > > 
> > Sean, I don't know how to deal with entry->edx here as SDM says it's
> > reserved for valid subleaf.
> 
> The SDM also states:
> 
>   Bit 31 - 00: Reports the supported bits of the upper 32 bits of XCR0.
>   XCR0[n+32] can be set to 1 only if EDX[n] is 1.
> 
> the second part, "Bits 31 - 00: Reserved" is at best superfluous, e.g. it
> could be interpreted as saying that XCR0[63:32] are currently reserved,
> and at worst the extra qualifier is an SDM bug and should be removed.
> 
> TL;DR: Ignore the blurb about the bits being reserved.
Thanks Sean, I'll follow it.


Re: [PATCH v2 2/2] RISC-V: defconfig: Enable Goldfish RTC driver

2019-10-22 Thread Paul Walmsley
On Tue, 22 Oct 2019, Alistair Francis wrote:

> I think it makese sense for this to go into Linux first.
> 
> The QEMU patches are going to be accepted, just some nit picking to do
> first :)
> 
> After that we have to wait for a PR and then a QEMU release until most
> people will see the change in QEMU. In that time Linux 5.4 will be
> released, if this can make it into 5.4 then everyone using 5.4 will get
> the new RTC as soon as they upgrade QEMU (QEMU provides the device
> tree). If this has to wait until QEMU has support then it won't be
> supported for users until even later.
> 
> Users are generally slow to update kernels (buildroot is still using
> 5.1 by default for example) so the sooner changes like this go in the
> better.

The defconfigs are really just for kernel developers.  We expect users to 
define their own Kconfigs for their own needs.

If using the Goldfish code really is what we all want to do (see below), 
then the kernel patch that should go in right away -- which also has no 
dependence on what QEMU does -- would be the first patch of this series:

https://lore.kernel.org/linux-riscv/20190925063706.56175-2-anup.pa...@wdc.com/

And that should go in via whoever is maintaining the Goldfish driver, not 
the RISC-V tree.  (It looks like drivers/platform/goldfish is completely 
unmaintained - a red flag! - so probably someone needs to persuade Greg or 
Andrew to take it.)

Incidentally, just looking at drivers/platform/goldfish, that driver seems 
to be some sort of Google-specific RPC driver.  Are you all really sure 
you want to enable that just for an RTC?  Seems like overkill - there are 
much simpler RTCs out there.


- Paul


Re: [PATCH v4 5/5] net: dsa: add support for Atheros AR9331 build-in switch

2019-10-22 Thread Andrew Lunn
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -52,6 +52,8 @@ source "drivers/net/dsa/microchip/Kconfig"
>  
>  source "drivers/net/dsa/mv88e6xxx/Kconfig"
>  
> +source "drivers/net/dsa/qca/Kconfig"
> +
>  source "drivers/net/dsa/sja1105/Kconfig"
>  
>  config NET_DSA_QCA8K

> diff --git a/drivers/net/dsa/qca/Kconfig b/drivers/net/dsa/qca/Kconfig
> new file mode 100644
> index ..7e4978f46642
> --- /dev/null
> +++ b/drivers/net/dsa/qca/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config NET_DSA_AR9331
> + tristate "Atheros AR9331 Ethernet switch support"

This is where things are a little bit unobvious. If you do
make menu

and go into the DSA menu, you will find the drivers are all sorted
into Alphabetic order, based on the tristate text. But you have
inserted your "Atheros AR9331", after "NXP SJA1105".

It would probably be best if you make the tristate "Qualcomm Atheros
AR9331 ...". The order would be correct then,

> +static int ar9331_sw_port_enable(struct dsa_switch *ds, int port,
> +  struct phy_device *phy)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct regmap *regmap = priv->regmap;
> + int ret;
> +
> + /* nothing to enable. Just set link to initial state */
> + ret = regmap_write(regmap, AR9331_SW_REG_PORT_STATUS(port), 0);
> + if (ret)
> + dev_err_ratelimited(priv->dev, "%s: %i\n", __func__, ret);
> +
> + return ret;
> +}
> +
> +static void ar9331_sw_port_disable(struct dsa_switch *ds, int port)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct regmap *regmap = priv->regmap;
> + int ret;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_PORT_STATUS(port), 0);
> + if (ret)
> + dev_err_ratelimited(priv->dev, "%s: %i\n", __func__, ret);
> +}

I've asked this before, but i don't remember the answer. Why are
port_enable and port_disable the same?

> +static int ar9331_sw_irq_init(struct ar9331_sw_priv *priv)
> +{
> + struct device_node *np = priv->dev->of_node;
> + struct device *dev = priv->dev;
> + int ret, irq;
> +
> + irq = of_irq_get(np, 0);
> + if (irq <= 0) {
> + dev_err(dev, "failed to get parent IRQ\n");
> + return irq ? irq : -EINVAL;
> + }
> +
> + ret = devm_request_threaded_irq(dev, irq, NULL, ar9331_sw_irq,
> + IRQF_ONESHOT, AR9331_SW_NAME, priv);
> + if (ret) {
> + dev_err(dev, "unable to request irq: %d\n", ret);
> + return ret;
> + }
> +
> + priv->irqdomain = irq_domain_add_linear(np, 1, _sw_irqdomain_ops,
> + priv);
> + if (!priv->irqdomain) {
> + dev_err(dev, "failed to create IRQ domain\n");
> + return -EINVAL;
> + }
> +
> + irq_set_parent(irq_create_mapping(priv->irqdomain, 0), irq);
> +
> + return 0;
> +}


> +static int ar9331_sw_probe(struct mdio_device *mdiodev)
> +{
> + struct ar9331_sw_priv *priv;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->regmap = devm_regmap_init(>dev, _sw_bus, priv,
> + _mdio_regmap_config);
> + if (IS_ERR(priv->regmap)) {
> + ret = PTR_ERR(priv->regmap);
> + dev_err(>dev, "regmap init failed: %d\n", ret);
> + return ret;
> + }
> +
> + priv->sw_reset = devm_reset_control_get(>dev, "switch");
> + if (IS_ERR(priv->sw_reset)) {
> + dev_err(>dev, "missing switch reset\n");
> + return PTR_ERR(priv->sw_reset);
> + }
> +
> + priv->sbus = mdiodev->bus;
> + priv->dev = >dev;
> +
> + ret = ar9331_sw_irq_init(priv);
> + if (ret)
> + return ret;
> +
> + priv->ds = dsa_switch_alloc(>dev, AR9331_SW_PORTS);
> + if (!priv->ds)
> + return -ENOMEM;
> +
> + priv->ds->priv = priv;
> + priv->ops = ar9331_sw_ops;
> + priv->ds->ops = >ops;
> + dev_set_drvdata(>dev, priv);
> +
> + return dsa_register_switch(priv->ds);

If there is an error here, you need to undo the IRQ code, etc.

> +}
> +
> +static void ar9331_sw_remove(struct mdio_device *mdiodev)
> +{
> + struct ar9331_sw_priv *priv = dev_get_drvdata(>dev);
> +
> + mdiobus_unregister(priv->mbus);
> + dsa_unregister_switch(priv->ds);
> +
> + reset_control_assert(priv->sw_reset);

You also need to clean up the IRQ code here.

Thanks
Andrew


Re: [PATCH v6 03/10] iommu/vt-d: Replace Intel specific PASID allocator with IOASID

2019-10-22 Thread Raj, Ashok
On Tue, Oct 22, 2019 at 04:53:16PM -0700, Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
> 
> Signed-off-by: Jacob Pan 
> ---
>  drivers/iommu/intel-iommu.c | 12 ++--
>  drivers/iommu/intel-pasid.c | 36 
>  drivers/iommu/intel-svm.c   | 37 +
>  3 files changed, 27 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 3aff0141c522..72febcf2c48f 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -5311,7 +5311,7 @@ static void auxiliary_unlink_device(struct dmar_domain 
> *domain,
>   domain->auxd_refcnt--;
>  
>   if (!domain->auxd_refcnt && domain->default_pasid > 0)
> - intel_pasid_free_id(domain->default_pasid);
> + ioasid_free(domain->default_pasid);

if the domain is gauranteed to be torn down, its ok.. but otherwise
do you need to clear domain->default_pasid to avoid accidental reference
in some other code path?

>  }
>  
>  static int aux_domain_add_dev(struct dmar_domain *domain,
> @@ -5329,10 +5329,10 @@ static int aux_domain_add_dev(struct dmar_domain 
> *domain,
>   if (domain->default_pasid <= 0) {
>   int pasid;
>  
> - pasid = intel_pasid_alloc_id(domain, PASID_MIN,
> -  pci_max_pasids(to_pci_dev(dev)),
> -  GFP_KERNEL);
> - if (pasid <= 0) {
> + /* No private data needed for the default pasid */
> + pasid = ioasid_alloc(NULL, PASID_MIN, 
> pci_max_pasids(to_pci_dev(dev)) - 1,

If we ensure IOMMU max-pasid is full 20bit width, its good. In a vIOMMU
if iommu max pasid is restricted for some kind of partitioning in future
you want to consider limiting to no more than what's provisioned in the vIOMMU 
right?


> + NULL);
> + if (pasid == INVALID_IOASID) {
>   pr_err("Can't allocate default pasid\n");
>   return -ENODEV;
>   }
> @@ -5368,7 +5368,7 @@ static int aux_domain_add_dev(struct dmar_domain 
> *domain,
>   spin_unlock(>lock);
>   spin_unlock_irqrestore(_domain_lock, flags);
>   if (!domain->auxd_refcnt && domain->default_pasid > 0)
> - intel_pasid_free_id(domain->default_pasid);
> + ioasid_free(domain->default_pasid);
>  
>   return ret;
>  }
> diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
> index 76bcbb21e112..c0d1f28d3412 100644
> --- a/drivers/iommu/intel-pasid.c
> +++ b/drivers/iommu/intel-pasid.c
> @@ -26,42 +26,6 @@
>   */
>  static DEFINE_SPINLOCK(pasid_lock);
>  u32 intel_pasid_max_id = PASID_MAX;
> -static DEFINE_IDR(pasid_idr);
> -
> -int intel_pasid_alloc_id(void *ptr, int start, int end, gfp_t gfp)
> -{
> - int ret, min, max;
> -
> - min = max_t(int, start, PASID_MIN);
> - max = min_t(int, end, intel_pasid_max_id);
> -
> - WARN_ON(in_interrupt());
> - idr_preload(gfp);
> - spin_lock(_lock);
> - ret = idr_alloc(_idr, ptr, min, max, GFP_ATOMIC);
> - spin_unlock(_lock);
> - idr_preload_end();
> -
> - return ret;
> -}
> -
> -void intel_pasid_free_id(int pasid)
> -{
> - spin_lock(_lock);
> - idr_remove(_idr, pasid);
> - spin_unlock(_lock);
> -}
> -
> -void *intel_pasid_lookup_id(int pasid)
> -{
> - void *p;
> -
> - spin_lock(_lock);
> - p = idr_find(_idr, pasid);
> - spin_unlock(_lock);
> -
> - return p;
> -}
>  
>  static int check_vcmd_pasid(struct intel_iommu *iommu)
>  {
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
> index 9b159132405d..5aef5b7bf561 100644
> --- a/drivers/iommu/intel-svm.c
> +++ b/drivers/iommu/intel-svm.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "intel-pasid.h"
> @@ -318,16 +319,15 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, 
> int flags, struct svm_dev_
>   if (pasid_max > intel_pasid_max_id)
>   pasid_max = intel_pasid_max_id;
>  
> - /* Do not use PASID 0 in caching mode (virtualised IOMMU) */
> - ret = intel_pasid_alloc_id(svm,
> -!!cap_caching_mode(iommu->cap),
> -pasid_max - 1, GFP_KERNEL);
> - if (ret < 0) {
> + /* Do not use PASID 0, reserved for RID to PASID */
> + svm->pasid = ioasid_alloc(NULL, PASID_MIN,
> + pasid_max - 1, svm);
> + if (svm->pasid == INVALID_IOASID) {
>   kfree(svm);
>   kfree(sdev);
> + ret = ENOSPC;
>   goto out;
>   }
> - svm->pasid = ret;
>   

Re: [PATCH] ASoC: rsnd: dma: set bus width to data width for monaural data

2019-10-22 Thread Kuninori Morimoto


Hi

> According to R-Car3 HW manual 40.3.3 (Data Format on Audio Local Bus),
> in case of monaural data writing or reading through Audio-DMAC,
> it's always in Left Justified format, so both src and dst
> DMA Bus width should be equal to physical data width.
> 
> Therefore set src and dst's DMA bus width to:
>  - [monaural case] data width
>  - [non-monaural case] 32bits (as prior applying the patch)
> 
> Cc: Andrew Gabbasov 
> Cc: Timo Wischer 
> Signed-off-by: Jiada Wang 
> Signed-off-by: Eugeniu Rosca 
> ---

I don't know how Monaural works, but I know you are using it.
Thus don't say Acked-by and/or Reviewed-by,
but I have no objection about this patch.

Thank you for your help !!
Best regards
---
Kuninori Morimoto


[PATCH v2 1/9] perf tools: add parse events append error

2019-10-22 Thread Ian Rogers
Parse event error handling may overwrite one error string with another
creating memory leaks and masking errors. Introduce a helper routine
that appends error messages and avoids the memory leak.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.c | 102 ++---
 tools/perf/util/parse-events.h |   2 +
 tools/perf/util/pmu.c  |  36 ++--
 3 files changed, 89 insertions(+), 51 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index db882f630f7e..4d42344698b8 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -182,6 +182,34 @@ static int tp_event_has_id(const char *dir_path, struct 
dirent *evt_dir)
 
 #define MAX_EVENT_LENGTH 512
 
+void parse_events__append_error(struct parse_events_error *err, int idx,
+   char *str, char *help)
+{
+   char *new_str = NULL;
+
+   WARN(!str, "WARNING: failed to provide error string");
+   if (err->str) {
+   int ret;
+
+   if (err->help)
+   ret = asprintf(_str,
+   "%s (previous error: %s(help: %s))",
+   str, err->str, err->help);
+   else
+   ret = asprintf(_str,
+   "%s (previous error: %s)",
+   str, err->str);
+   if (ret < 0)
+   new_str = NULL;
+   else
+   zfree();
+   }
+   err->idx = idx;
+   free(err->str);
+   err->str = new_str ?: str;
+   free(err->help);
+   err->help = help;
+}
 
 struct tracepoint_path *tracepoint_id_to_path(u64 config)
 {
@@ -931,13 +959,12 @@ static int check_type_val(struct parse_events_term *term,
if (type == term->type_val)
return 0;
 
-   if (err) {
-   err->idx = term->err_val;
-   if (type == PARSE_EVENTS__TERM_TYPE_NUM)
-   err->str = strdup("expected numeric value");
-   else
-   err->str = strdup("expected string value");
-   }
+   if (err)
+   parse_events__append_error(err, term->err_val,
+   type == PARSE_EVENTS__TERM_TYPE_NUM
+   ? strdup("expected numeric value")
+   : strdup("expected string value"),
+   NULL);
return -EINVAL;
 }
 
@@ -972,8 +999,11 @@ static bool config_term_shrinked;
 static bool
 config_term_avail(int term_type, struct parse_events_error *err)
 {
+   char *err_str;
+
if (term_type < 0 || term_type >= __PARSE_EVENTS__TERM_TYPE_NR) {
-   err->str = strdup("Invalid term_type");
+   parse_events__append_error(err, -1,
+   strdup("Invalid term_type"), NULL);
return false;
}
if (!config_term_shrinked)
@@ -992,9 +1022,9 @@ config_term_avail(int term_type, struct parse_events_error 
*err)
return false;
 
/* term_type is validated so indexing is safe */
-   if (asprintf(>str, "'%s' is not usable in 'perf stat'",
-config_term_names[term_type]) < 0)
-   err->str = NULL;
+   if (asprintf(_str, "'%s' is not usable in 'perf stat'",
+   config_term_names[term_type]) >= 0)
+   parse_events__append_error(err, -1, err_str, NULL);
return false;
}
 }
@@ -1036,17 +1066,20 @@ do {
   \
case PARSE_EVENTS__TERM_TYPE_BRANCH_SAMPLE_TYPE:
CHECK_TYPE_VAL(STR);
if (strcmp(term->val.str, "no") &&
-   parse_branch_str(term->val.str, >branch_sample_type)) 
{
-   err->str = strdup("invalid branch sample type");
-   err->idx = term->err_val;
+   parse_branch_str(term->val.str,
+   >branch_sample_type)) {
+   parse_events__append_error(err, term->err_val,
+   strdup("invalid branch sample type"),
+   NULL);
return -EINVAL;
}
break;
case PARSE_EVENTS__TERM_TYPE_TIME:
CHECK_TYPE_VAL(NUM);
if (term->val.num > 1) {
-   err->str = strdup("expected 0 or 1");
-   err->idx = term->err_val;
+   parse_events__append_error(err, term->err_val,
+   strdup("expected 0 or 1"),
+   NULL);
return -EINVAL;
 

[PATCH v2 8/9] perf tools: if pmu configuration fails free terms

2019-10-22 Thread Ian Rogers
Avoid a memory leak when the configuration fails.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f7c8d0853d71..6bf64b3767cc 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1400,8 +1400,15 @@ int parse_events_add_pmu(struct parse_events_state 
*parse_state,
if (get_config_terms(head_config, _terms))
return -ENOMEM;
 
-   if (perf_pmu__config(pmu, , head_config, parse_state->error))
+   if (perf_pmu__config(pmu, , head_config, parse_state->error)) {
+   struct perf_evsel_config_term *pos, *tmp;
+
+   list_for_each_entry_safe(pos, tmp, _terms, list) {
+   list_del_init(>list);
+   free(pos);
+   }
return -EINVAL;
+   }
 
evsel = __add_event(list, _state->idx, ,
get_config_name(head_config), pmu,
-- 
2.23.0.866.gb869b98d4c-goog



[PATCH v2 6/9] perf tools: add destructors for parse event terms

2019-10-22 Thread Ian Rogers
If parsing fails then destructors are ran to clean the up the stack.
Rename the head union member to make the term and evlist use cases more
distinct, this simplifies matching the correct destructor.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.y | 69 +++---
 1 file changed, 48 insertions(+), 21 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 545ab7cefc20..4725b14b9db4 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pmu.h"
 #include "evsel.h"
 #include "parse-events.h"
@@ -37,6 +38,25 @@ static struct list_head* alloc_list()
return list;
 }
 
+static void free_list_evsel(struct list_head* list_evsel)
+{
+   struct perf_evsel *pos, *tmp;
+
+   list_for_each_entry_safe(pos, tmp, list_evsel, node) {
+   list_del_init(>node);
+   perf_evsel__delete(pos);
+   }
+   free(list_evsel);
+}
+
+static void free_term(struct parse_events_term *term)
+{
+   if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR)
+   free(term->val.str);
+   zfree(>array.ranges);
+   free(term);
+}
+
 static void inc_group_count(struct list_head *list,
   struct parse_events_state *parse_state)
 {
@@ -66,6 +86,7 @@ static void inc_group_count(struct list_head *list,
 %type  PE_VALUE_SYM_TOOL
 %type  PE_RAW
 %type  PE_TERM
+%type  value_sym
 %type  PE_NAME
 %type  PE_BPF_OBJECT
 %type  PE_BPF_SOURCE
@@ -76,37 +97,43 @@ static void inc_group_count(struct list_head *list,
 %type  PE_EVENT_NAME
 %type  PE_PMU_EVENT_PRE PE_PMU_EVENT_SUF PE_KERNEL_PMU_EVENT
 %type  PE_DRV_CFG_TERM
-%type  value_sym
-%type  event_config
-%type  opt_event_config
-%type  opt_pmu_config
+%destructor { free ($$); } 
 %type  event_term
-%type  event_pmu
-%type  event_legacy_symbol
-%type  event_legacy_cache
-%type  event_legacy_mem
-%type  event_legacy_tracepoint
+%destructor { free_term ($$); } 
+%type  event_config
+%type  opt_event_config
+%type  opt_pmu_config
+%destructor { parse_events_terms__delete ($$); } 
+%type  event_pmu
+%type  event_legacy_symbol
+%type  event_legacy_cache
+%type  event_legacy_mem
+%type  event_legacy_tracepoint
+%type  event_legacy_numeric
+%type  event_legacy_raw
+%type  event_bpf_file
+%type  event_def
+%type  event_mod
+%type  event_name
+%type  event
+%type  events
+%type  group_def
+%type  group
+%type  groups
+%destructor { free_list_evsel ($$); } 
 %type  tracepoint_name
-%type  event_legacy_numeric
-%type  event_legacy_raw
-%type  event_bpf_file
-%type  event_def
-%type  event_mod
-%type  event_name
-%type  event
-%type  events
-%type  group_def
-%type  group
-%type  groups
+%destructor { free ($$.sys); free ($$.event); } 
 %type  array
 %type  array_term
 %type  array_terms
+%destructor { free ($$.ranges); } 
 
 %union
 {
char *str;
u64 num;
-   struct list_head *head;
+   struct list_head *list_evsel;
+   struct list_head *list_terms;
struct parse_events_term *term;
struct tracepoint_name {
char *sys;
-- 
2.23.0.866.gb869b98d4c-goog



[PATCH v2 5/9] perf tools: avoid a malloc for array events

2019-10-22 Thread Ian Rogers
Use realloc rather than malloc+memcpy to possibly avoid a memory
allocation when appending array elements.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.y | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 26cb65798522..545ab7cefc20 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -691,14 +691,12 @@ array_terms ',' array_term
struct parse_events_array new_array;
 
new_array.nr_ranges = $1.nr_ranges + $3.nr_ranges;
-   new_array.ranges = malloc(sizeof(new_array.ranges[0]) *
- new_array.nr_ranges);
+   new_array.ranges = realloc($1.ranges,
+   sizeof(new_array.ranges[0]) *
+   new_array.nr_ranges);
ABORT_ON(!new_array.ranges);
-   memcpy(_array.ranges[0], $1.ranges,
-  $1.nr_ranges * sizeof(new_array.ranges[0]));
memcpy(_array.ranges[$1.nr_ranges], $3.ranges,
   $3.nr_ranges * sizeof(new_array.ranges[0]));
-   free($1.ranges);
free($3.ranges);
$$ = new_array;
 }
-- 
2.23.0.866.gb869b98d4c-goog



[PATCH v2 3/9] perf tools: ensure config and str in terms are unique

2019-10-22 Thread Ian Rogers
Make it easier to release memory associated with parse event terms by
duplicating the string for the config name and ensuring the val string
is a duplicate.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.c | 33 -
 tools/perf/util/parse-events.y |  4 +++-
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index a8f8801bd127..f7c8d0853d71 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1424,7 +1424,6 @@ int parse_events_add_pmu(struct parse_events_state 
*parse_state,
 int parse_events_multi_pmu_add(struct parse_events_state *parse_state,
   char *str, struct list_head **listp)
 {
-   struct list_head *head;
struct parse_events_term *term;
struct list_head *list;
struct perf_pmu *pmu = NULL;
@@ -1441,19 +1440,30 @@ int parse_events_multi_pmu_add(struct 
parse_events_state *parse_state,
 
list_for_each_entry(alias, >aliases, list) {
if (!strcasecmp(alias->name, str)) {
+   struct list_head *head;
+   char *config;
+
head = malloc(sizeof(struct list_head));
if (!head)
return -1;
INIT_LIST_HEAD(head);
-   if (parse_events_term__num(, 
PARSE_EVENTS__TERM_TYPE_USER,
-  str, 1, false, , 
NULL) < 0)
+   config = strdup(str);
+   if (!config)
+   return -1;
+   if (parse_events_term__num(,
+  PARSE_EVENTS__TERM_TYPE_USER,
+  config, 1, false, ,
+  NULL) < 0) {
+   free(list);
+   free(config);
return -1;
+   }
list_add_tail(>list, head);
 
if (!parse_events_add_pmu(parse_state, list,
  pmu->name, head,
  true, true)) {
-   pr_debug("%s -> %s/%s/\n", str,
+   pr_debug("%s -> %s/%s/\n", config,
 pmu->name, alias->str);
ok++;
}
@@ -1462,8 +1472,10 @@ int parse_events_multi_pmu_add(struct parse_events_state 
*parse_state,
}
}
}
-   if (!ok)
+   if (!ok) {
+   free(list);
return -1;
+   }
*listp = list;
return 0;
 }
@@ -2761,13 +2773,13 @@ int parse_events_term__sym_hw(struct parse_events_term 
**term,
struct parse_events_term temp = {
.type_val  = PARSE_EVENTS__TERM_TYPE_STR,
.type_term = PARSE_EVENTS__TERM_TYPE_USER,
-   .config= config ?: (char *) "event",
+   .config= config ?: strdup("event"),
};
 
BUG_ON(idx >= PERF_COUNT_HW_MAX);
sym = _symbols_hw[idx];
 
-   return new_term(term, , (char *) sym->symbol, 0);
+   return new_term(term, , strdup(sym->symbol), 0);
 }
 
 int parse_events_term__clone(struct parse_events_term **new,
@@ -2776,12 +2788,15 @@ int parse_events_term__clone(struct parse_events_term 
**new,
struct parse_events_term temp = {
.type_val  = term->type_val,
.type_term = term->type_term,
-   .config= term->config,
+   .config= term->config ? strdup(term->config) : NULL,
.err_term  = term->err_term,
.err_val   = term->err_val,
};
 
-   return new_term(new, , term->val.str, term->val.num);
+   if (term->type_val == PARSE_EVENTS__TERM_TYPE_NUM)
+   return new_term(new, , NULL, term->val.num);
+   else
+   return new_term(new, , strdup(term->val.str), 0);
 }
 
 int parse_events_copy_term_list(struct list_head *old,
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 48126ae4cd13..27d6b187c9b1 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -644,9 +644,11 @@ PE_NAME array '=' PE_VALUE
 PE_DRV_CFG_TERM
 {
struct parse_events_term *term;
+   char *config = strdup($1);
 
+   ABORT_ON(!config);
ABORT_ON(parse_events_term__str(, PARSE_EVENTS__TERM_TYPE_DRV_CFG,
-

[PATCH v2 9/9] perf tools: add a deep delete for parse event terms

2019-10-22 Thread Ian Rogers
Add a parse_events_term deep delete function so that owned strings and
arrays are freed.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.c | 16 +---
 tools/perf/util/parse-events.h |  1 +
 tools/perf/util/parse-events.y | 12 ++--
 tools/perf/util/pmu.c  |  2 +-
 4 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 6bf64b3767cc..5e7bebc8fad4 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2806,6 +2806,18 @@ int parse_events_term__clone(struct parse_events_term 
**new,
return new_term(new, , strdup(term->val.str), 0);
 }
 
+void parse_events_term__delete(struct parse_events_term *term)
+{
+   if (term->array.nr_ranges)
+   zfree(>array.ranges);
+
+   if (term->type_val != PARSE_EVENTS__TERM_TYPE_NUM)
+   zfree(>val.str);
+
+   zfree(>config);
+   free(term);
+}
+
 int parse_events_copy_term_list(struct list_head *old,
 struct list_head **new)
 {
@@ -2836,10 +2848,8 @@ void parse_events_terms__purge(struct list_head *terms)
struct parse_events_term *term, *h;
 
list_for_each_entry_safe(term, h, terms, list) {
-   if (term->array.nr_ranges)
-   zfree(>array.ranges);
list_del_init(>list);
-   free(term);
+   parse_events_term__delete(term);
}
 }
 
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index a7d42faeab0c..d1ade97e2357 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -139,6 +139,7 @@ int parse_events_term__sym_hw(struct parse_events_term 
**term,
  char *config, unsigned idx);
 int parse_events_term__clone(struct parse_events_term **new,
 struct parse_events_term *term);
+void parse_events_term__delete(struct parse_events_term *term);
 void parse_events_terms__delete(struct list_head *terms);
 void parse_events_terms__purge(struct list_head *terms);
 void parse_events__clear_array(struct parse_events_array *a);
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index d1cceb3bc620..649c63809bad 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -49,14 +49,6 @@ static void free_list_evsel(struct list_head* list_evsel)
free(list_evsel);
 }
 
-static void free_term(struct parse_events_term *term)
-{
-   if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR)
-   free(term->val.str);
-   zfree(>array.ranges);
-   free(term);
-}
-
 static void inc_group_count(struct list_head *list,
   struct parse_events_state *parse_state)
 {
@@ -99,7 +91,7 @@ static void inc_group_count(struct list_head *list,
 %type  PE_DRV_CFG_TERM
 %destructor { free ($$); } 
 %type  event_term
-%destructor { free_term ($$); } 
+%destructor { parse_events_term__delete ($$); } 
 %type  event_config
 %type  opt_event_config
 %type  opt_pmu_config
@@ -693,7 +685,7 @@ event_config ',' event_term
struct parse_events_term *term = $3;
 
if (!head) {
-   free_term(term);
+   parse_events_term__delete(term);
YYABORT;
}
list_add_tail(>list, head);
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 0fc2a51bb953..081e55300237 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -1258,7 +1258,7 @@ int perf_pmu__check_alias(struct perf_pmu *pmu, struct 
list_head *head_terms,
info->metric_name = alias->metric_name;
 
list_del_init(>list);
-   free(term);
+   parse_events_term__delete(term);
}
 
/*
-- 
2.23.0.866.gb869b98d4c-goog



[PATCH v2 4/9] perf tools: move ALLOC_LIST into a function

2019-10-22 Thread Ian Rogers
Having a YYABORT in a macro makes it hard to free memory for components
of a rule. Separate the logic out.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.y | 65 ++
 1 file changed, 43 insertions(+), 22 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 27d6b187c9b1..26cb65798522 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -25,12 +25,17 @@ do { \
YYABORT; \
 } while (0)
 
-#define ALLOC_LIST(list) \
-do { \
-   list = malloc(sizeof(*list)); \
-   ABORT_ON(!list);  \
-   INIT_LIST_HEAD(list); \
-} while (0)
+static struct list_head* alloc_list()
+{
+   struct list_head *list;
+
+   list = malloc(sizeof(*list));
+   if (!list)
+   return NULL;
+
+   INIT_LIST_HEAD(list);
+   return list;
+}
 
 static void inc_group_count(struct list_head *list,
   struct parse_events_state *parse_state)
@@ -238,7 +243,8 @@ PE_NAME opt_pmu_config
if (error)
error->idx = @1.first_column;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
if (parse_events_add_pmu(_parse_state, list, $1, $2, false, false)) {
struct perf_pmu *pmu = NULL;
int ok = 0;
@@ -306,7 +312,8 @@ value_sym '/' event_config '/'
int type = $1 >> 16;
int config = $1 & 255;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_numeric(_parse_state, list, type, config, 
$3));
parse_events_terms__delete($3);
$$ = list;
@@ -318,7 +325,8 @@ value_sym sep_slash_slash_dc
int type = $1 >> 16;
int config = $1 & 255;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_numeric(_parse_state, list, type, config, 
NULL));
$$ = list;
 }
@@ -327,7 +335,8 @@ PE_VALUE_SYM_TOOL sep_slash_slash_dc
 {
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_tool(_parse_state, list, $1));
$$ = list;
 }
@@ -339,7 +348,8 @@ PE_NAME_CACHE_TYPE '-' PE_NAME_CACHE_OP_RESULT '-' 
PE_NAME_CACHE_OP_RESULT opt_e
struct parse_events_error *error = parse_state->error;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_cache(list, _state->idx, $1, $3, $5, 
error, $6));
parse_events_terms__delete($6);
$$ = list;
@@ -351,7 +361,8 @@ PE_NAME_CACHE_TYPE '-' PE_NAME_CACHE_OP_RESULT 
opt_event_config
struct parse_events_error *error = parse_state->error;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_cache(list, _state->idx, $1, $3, NULL, 
error, $4));
parse_events_terms__delete($4);
$$ = list;
@@ -363,7 +374,8 @@ PE_NAME_CACHE_TYPE opt_event_config
struct parse_events_error *error = parse_state->error;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_cache(list, _state->idx, $1, NULL, 
NULL, error, $2));
parse_events_terms__delete($2);
$$ = list;
@@ -375,7 +387,8 @@ PE_PREFIX_MEM PE_VALUE '/' PE_VALUE ':' PE_MODIFIER_BP 
sep_dc
struct parse_events_state *parse_state = _parse_state;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_breakpoint(list, _state->idx,
 (void *) $2, $6, $4));
$$ = list;
@@ -386,7 +399,8 @@ PE_PREFIX_MEM PE_VALUE '/' PE_VALUE sep_dc
struct parse_events_state *parse_state = _parse_state;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_breakpoint(list, _state->idx,
 (void *) $2, NULL, $4));
$$ = list;
@@ -397,7 +411,8 @@ PE_PREFIX_MEM PE_VALUE ':' PE_MODIFIER_BP sep_dc
struct parse_events_state *parse_state = _parse_state;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_breakpoint(list, _state->idx,
 (void *) $2, $4, 0));
$$ = list;
@@ -408,7 +423,8 @@ PE_PREFIX_MEM PE_VALUE sep_dc
struct parse_events_state *parse_state = _parse_state;
struct list_head *list;
 
-   ALLOC_LIST(list);
+   list = alloc_list();
+   ABORT_ON(!list);
ABORT_ON(parse_events_add_breakpoint(list, _state->idx,
 

[PATCH v2 2/9] perf tools: splice events onto evlist even on error

2019-10-22 Thread Ian Rogers
If event parsing fails the event list is leaked, instead splice the list
onto the out result and let the caller cleanup.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 4d42344698b8..a8f8801bd127 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1962,15 +1962,20 @@ int parse_events(struct evlist *evlist, const char *str,
 
ret = parse_events__scanner(str, _state, PE_START_EVENTS);
perf_pmu__parse_cleanup();
+
+   if (list_empty(_state.list)) {
+   WARN_ONCE(true, "WARNING: event parser found nothing\n");
+   return -1;
+   }
+
+   /*
+* Add list to the evlist even with errors to allow callers to clean up.
+*/
+   perf_evlist__splice_list_tail(evlist, _state.list);
+
if (!ret) {
struct evsel *last;
 
-   if (list_empty(_state.list)) {
-   WARN_ONCE(true, "WARNING: event parser found 
nothing\n");
-   return -1;
-   }
-
-   perf_evlist__splice_list_tail(evlist, _state.list);
evlist->nr_groups += parse_state.nr_groups;
last = evlist__last(evlist);
last->cmdline_group_boundary = true;
-- 
2.23.0.866.gb869b98d4c-goog



[PATCH v2 7/9] perf tools: before yyabort-ing free components

2019-10-22 Thread Ian Rogers
Yyabort doesn't destruct inputs and so this must be done manually before
using yyabort.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.y | 250 +
 1 file changed, 195 insertions(+), 55 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 4725b14b9db4..d1cceb3bc620 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -152,6 +152,7 @@ start_events: groups
 {
struct parse_events_state *parse_state = _parse_state;
 
+   /* frees $1 */
parse_events_update_lists($1, _state->list);
 }
 
@@ -161,6 +162,7 @@ groups ',' group
struct list_head *list  = $1;
struct list_head *group = $3;
 
+   /* frees $3 */
parse_events_update_lists(group, list);
$$ = list;
 }
@@ -170,6 +172,7 @@ groups ',' event
struct list_head *list  = $1;
struct list_head *event = $3;
 
+   /* frees $3 */
parse_events_update_lists(event, list);
$$ = list;
 }
@@ -182,8 +185,14 @@ group:
 group_def ':' PE_MODIFIER_EVENT
 {
struct list_head *list = $1;
+   int err;
 
-   ABORT_ON(parse_events__modifier_group(list, $3));
+   err = parse_events__modifier_group(list, $3);
+   free($3);
+   if (err) {
+   free_list_evsel(list);
+   YYABORT;
+   }
$$ = list;
 }
 |
@@ -196,6 +205,7 @@ PE_NAME '{' events '}'
 
inc_group_count(list, _parse_state);
parse_events__set_leader($1, list, _parse_state);
+   free($1);
$$ = list;
 }
 |
@@ -214,6 +224,7 @@ events ',' event
struct list_head *event = $3;
struct list_head *list  = $1;
 
+   /* frees $3 */
parse_events_update_lists(event, list);
$$ = list;
 }
@@ -226,13 +237,19 @@ event_mod:
 event_name PE_MODIFIER_EVENT
 {
struct list_head *list = $1;
+   int err;
 
/*
 * Apply modifier on all events added by single event definition
 * (there could be more events added for multiple tracepoint
 * definitions via '*?'.
 */
-   ABORT_ON(parse_events__modifier_event(list, $2, false));
+   err = parse_events__modifier_event(list, $2, false);
+   free($2);
+   if (err) {
+   free_list_evsel(list);
+   YYABORT;
+   }
$$ = list;
 }
 |
@@ -241,8 +258,14 @@ event_name
 event_name:
 PE_EVENT_NAME event_def
 {
-   ABORT_ON(parse_events_name($2, $1));
+   int err;
+
+   err = parse_events_name($2, $1);
free($1);
+   if (err) {
+   free_list_evsel($2);
+   YYABORT;
+   }
$$ = $2;
 }
 |
@@ -262,23 +285,32 @@ PE_NAME opt_pmu_config
 {
struct parse_events_state *parse_state = _parse_state;
struct parse_events_error *error = parse_state->error;
-   struct list_head *list, *orig_terms, *terms;
+   struct list_head *list = NULL, *orig_terms = NULL, *terms= NULL;
+   char *pattern = NULL;
+
+#define CLEANUP_YYABORT\
+   do {\
+   parse_events_terms__delete($2); \
+   parse_events_terms__delete(orig_terms); \
+   free($1);   \
+   YYABORT;\
+   } while(0)
 
if (parse_events_copy_term_list($2, _terms))
-   YYABORT;
+   CLEANUP_YYABORT;
 
if (error)
error->idx = @1.first_column;
 
list = alloc_list();
-   ABORT_ON(!list);
+   if (!list)
+   CLEANUP_YYABORT;
if (parse_events_add_pmu(_parse_state, list, $1, $2, false, false)) {
struct perf_pmu *pmu = NULL;
int ok = 0;
-   char *pattern;
 
if (asprintf(, "%s*", $1) < 0)
-   YYABORT;
+   CLEANUP_YYABORT;
 
while ((pmu = perf_pmu__scan(pmu)) != NULL) {
char *name = pmu->name;
@@ -287,31 +319,32 @@ PE_NAME opt_pmu_config
strncmp($1, "uncore_", 7))
name += 7;
if (!fnmatch(pattern, name, 0)) {
-   if (parse_events_copy_term_list(orig_terms, 
)) {
-   free(pattern);
-   YYABORT;
-   }
+   if (parse_events_copy_term_list(orig_terms, 
))
+   CLEANUP_YYABORT;
if (!parse_events_add_pmu(_parse_state, list, 
pmu->name, terms, true, false))
ok++;
parse_events_terms__delete(terms);
}
}
 
-   free(pattern);
-
if (!ok)

  1   2   3   4   5   6   7   8   9   >