Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem

[Yu Chen]

From: Yu Chen 

On Sat, 21 Sep 2019 15:51:38, Russell King - ARM Linux admin wrote:
> On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote:
> > From: Yu Chen  
> >  
> > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
> > user-space doesn't know about memblock_reserve()d regions and thus
> > possible for kexec to overwrite with the new kernel or initrd.
> 
> Many reserved regions come from the kernel allocating memory during
> boot.  We don't want to prevent kexec re-using those regions.
> 
> > [0.00] Booting Linux on physical CPU 0xf00
> > [0.00] Linux version 4.9.115-rt93-dirty 
> > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2
> > 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
> > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> > cr=30c5387d
> > [0.00] CPU: div instructions available: patching division code
> > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> > instruction cache
> > [0.00] OF: fdt:Machine model: LS1021A TWR Board
> > [0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region 
> > - disabling initrd
> 
> Is the overlapping region one that is marked as reserved in DT?

the overlapping region is not reserved in DT.

> Where is the reserved region that overlaps the initrd coming from?

I found the reserved region that overlaps the initrd is kernel code & data, 
with memblock=debug cmdline start new kerne:

/ # kexec -l uImage-ls1021a --ramdisk=ramdisk-ls1021a --dtb=fdt --append="root=/
dev/ram0 rw console=ttyS0,115200 earlyprintk memblock=debug" -d
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on uImage-ls1021a of 65536 bytes failed
kernel: 0xb6c71008 kernel_size: 0x317ab8
MEMORY RANGES
8000-bfff (0)
80003000-80007fff (1)
80e0-80ff (1)
810c45a4-810c4fff (1)
81ac4000-85159fff (1)
8515a000-8515 (1)
8800-8b695fff (1)
8f00-8f004fff (1)
af709000-af7eafff (1)
af7ed000-afffbfff (1)
afffc000-afffcfff (1)
afffd000-afff (1)
bc00-bfff (1)
zImage header: 0x016f2818 0x 0x00317a78
zImage size 0x317a78, file size 0x317a78
kexec_load: entry = 0x80008000 flags = 0x28
nr_segments = 3
segment[0].buf   = 0xb6c71048
segment[0].bufsz = 0x317a78
segment[0].mem   = 0x80008000
segment[0].memsz = 0x318000
segment[1].buf   = 0xb35db048
segment[1].bufsz = 0x3695e40
segment[1].mem   = 0x80f7f000
segment[1].memsz = 0x3696000
segment[2].buf   = 0x100b108
segment[2].bufsz = 0x5090
segment[2].mem   = 0x84615000
segment[2].memsz = 0x6000
/ # kexec -e
[  126.583598] kexec_core: Starting new kernel
[  126.587815] Disabling non-boot CPUs ...
[  126.626917] CPU1: shutdown
[  126.656344] Retrying again to check for CPU kill
[  126.660947] CPU1 killed.
[  126.687585] Bye!
[0.00] Booting Linux on physical CPU 0xf00
[0.00] Linux version 4.9.115-rt93-CGEL-V6.02.10.R4-dirty 
(yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.20) ) 
#62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt:Machine model: LS1021A TWR Board
[0.00] memblock_reserve: [0x008020-0x00810c45a3] flags 0x0 
arm_memblock_init+0x44/0x23c
[0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - 
disabling initrd
[0.00] memblock_reserve: [0x0080003000-0x0080007fff] flags 0x0 
arm_mm_memblock_reserve+0x2c/0x30
[0.00] memblock_reserve: [0x0084615000-0x008461a08f] flags 0x0 
early_init_dt_reserve_memory_arch+0x24/0x28
[0.00] memblock_reserve: [0x008f00-0x008f004fff] flags 0x0 
early_init_dt_reserve_memory_arch+0x24/0x28
[0.00] memblock_reserve: [0x008840-0x008b695e3f] flags 0x0 
early_init_dt_reserve_memory_arch+0x24/0x28
[0.00] memblock_reserve: [0x00bc00-0x00bfff] flags 0x0 
memblock_alloc_range_nid+0x78/0x90
 ... 
 ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(1,0)

this overlay region is [0x008020-0x00810c45a3]

Corresponding kernel source code:
264 void __init arm_memblock_init(const struct machine_desc *mdesc)
265 {
266 /* Register the kernel text, kernel data and initrd with memblock. 
*/
267 memblock_reserve(__pa(KERNEL_START), KERNEL_END - KERNEL_START);

> 
> Thanks.
> 
> --  
> RMK

[PATCH] arm: export memblock_reserve()d regions via /proc/iomem

[Yu Chen]

From: Yu Chen 

memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
user-space doesn't know about memblock_reserve()d regions and thus
possible for kexec to overwrite with the new kernel or initrd.

[    0.00] Booting Linux on physical CPU 0xf00
[    0.00] Linux version 4.9.115-rt93-dirty (yuchen@localhost.localdomain) 
(gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2
0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
[    0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
[    0.00] CPU: div instructions available: patching division code
[    0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.00] OF: fdt:Machine model: LS1021A TWR Board
[    0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - 
disabling initrd

Signed-off-by: Yu Chen 
Reviewed-by: Junhua Huang 
---
 arch/arm/kernel/setup.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d0a464e..606d1ac 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -911,6 +911,34 @@ static void __init request_standard_resources(const struct 
machine_desc *mdesc)
request_resource(_resource, );
 }
 
+static int __init reserve_memblock_reserved_regions(void)
+{
+   u64 i, j;
+
+   for (i = 0; i < num_standard_resources; ++i) {
+   struct resource *mem = _resources[i];
+   phys_addr_t r_start, r_end, mem_size = resource_size(mem);
+
+   if (!memblock_is_region_reserved(mem->start, mem_size))
+   continue;
+
+   for_each_reserved_mem_region(j, _start, _end) {
+   resource_size_t start, end;
+
+   start = max(PFN_PHYS(PFN_DOWN(r_start)), mem->start);
+   end = min(PFN_PHYS(PFN_UP(r_end)) - 1, mem->end);
+
+   if (start > mem->end || end < mem->start)
+   continue;
+
+   reserve_region_with_split(mem, start, end, "reserved");
+   }
+   }
+
+   return 0;
+}
+arch_initcall(reserve_memblock_reserved_regions);
+
 #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE) || \
 defined(CONFIG_EFI)
 struct screen_info screen_info = {
-- 
2.7.4

Re: Patch "x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume" has been added to the 4.4-stable tree

[Yu Chen]

On Wed, Aug 28, 2019 at 10:43:51AM +0200, Greg KH wrote:
> On Wed, Aug 28, 2019 at 12:12:39AM -0400, Sasha Levin wrote:
> > This is a note to let you know that I've just added the patch titled
> > 
> > x86/pm: Introduce quirk framework to save/restore extra MSR registers 
> > around suspend/resume
> > 
> > to the 4.4-stable tree which can be found at:
> > 
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > 
> > The filename of the patch is:
> >  x86-pm-introduce-quirk-framework-to-save-restore-ext.patch
> > and it can be found in the queue-4.4 subdirectory.
> > 
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let  know about it.
> > 
> > 
> > 
> > commit d63273440aa0fdebc30d0c931f15f79beb213134
> > Author: Chen Yu 
> > Date:   Wed Nov 25 01:03:41 2015 +0800
> > 
> > x86/pm: Introduce quirk framework to save/restore extra MSR registers 
> > around suspend/resume
> > 
> > A bug was reported that on certain Broadwell platforms, after
> > resuming from S3, the CPU is running at an anomalously low
> > speed.
> > 
> > It turns out that the BIOS has modified the value of the
> > THERM_CONTROL register during S3, and changed it from 0 to 0x10,
> > thus enabled clock modulation(bit4), but with undefined CPU Duty
> > Cycle(bit1:3) - which causes the problem.
> > 
> > Here is a simple scenario to reproduce the issue:
> > 
> >  1. Boot up the system
> >  2. Get MSR 0x19a, it should be 0
> >  3. Put the system into sleep, then wake it up
> >  4. Get MSR 0x19a, it shows 0x10, while it should be 0
> > 
> > Although some BIOSen want to change the CPU Duty Cycle during
> > S3, in our case we don't want the BIOS to do any modification.
> > 
> > Fix this issue by introducing a more generic x86 framework to
> > save/restore specified MSR registers(THERM_CONTROL in this case)
> > for suspend/resume. This allows us to fix similar bugs in a much
> > simpler way in the future.
> > 
> > When the kernel wants to protect certain MSRs during suspending,
> > we simply add a quirk entry in msr_save_dmi_table, and customize
> > the MSR registers inside the quirk callback, for example:
> > 
> >   u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
> > 
> > and the quirk mechanism ensures that, once resumed from suspend,
> > the MSRs indicated by these IDs will be restored to their
> > original, pre-suspend values.
> > 
> > Since both 64-bit and 32-bit kernels are affected, this patch
> > covers the common 64/32-bit suspend/resume code path. And
> > because the MSRs specified by the user might not be available or
> > readable in any situation, we use rdmsrl_safe() to safely save
> > these MSRs.
> > 
> > Reported-and-tested-by: Marcin Kaszewski 
> > Signed-off-by: Chen Yu 
> > Acked-by: Rafael J. Wysocki 
> > Acked-by: Pavel Machek 
> > Cc: Andy Lutomirski 
> > Cc: Borislav Petkov 
> > Cc: Brian Gerst 
> > Cc: Denys Vlasenko 
> > Cc: H. Peter Anvin 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > Cc: b...@suse.de
> > Cc: len.br...@intel.com
> > Cc: li...@horizon.com
> > Cc: l...@kernel.org
> > Cc: r...@rjwysocki.net
> > Link: 
> > http://lkml.kernel.org/r/c9abdcbc173dd2f57e8990e304376f19287e92ba.1448382971.git.yu.c.c...@intel.com
> > [ More edits to the naming of data structures. ]
> > Signed-off-by: Ingo Molnar 
> 
> No git id of the patch in Linus's tree, or your signed-off-by?
>
I think the commit id in Linus'tree should be 
7a9c2dd08eadd5c6943115dbbec040c38d2e0822

Thanks,
Chenyu

> Sasha, did your scripts trigger this unintentionally somehow?
> 
> thanks,
> 
> greg k-h

Re: [PATCH v3 1/2] platform/x86: surfacepro3_button: Fix device check

[Yu Chen]

On Sat, Jul 20, 2019 at 05:05:10PM +0200, Maximilian Luz wrote:
> Do not use the surfacepro3_button driver on newer Microsoft Surface
> models, only use it on the Surface Pro 3 and 4. Newer models (5th, 6th
> and possibly future generations) use the same device as the Surface Pro
> 4 to represent their volume and power buttons (MSHW0040), but their
> actual implementation is significantly different. This patch ensures
> that the surfacepro3_button driver is only used on the Pro 3 and 4
> models, allowing a different driver to bind on other models.
> 
> Signed-off-by: Maximilian Luz 
> ---
Acked-by: Chen Yu 

Thanks,
Chenyu

Re: [PATCH v2 1/2] platform: Fix device check for surfacepro3_button

[Yu Chen]

On Tue, Jul 02, 2019 at 03:33:20AM +0200, Maximilian Luz wrote:
> On 7/2/19 3:25 AM, Maximilian Luz wrote:
> > On 7/2/19 3:14 AM, Yu Chen wrote:
> > > On Tue, Jul 02, 2019 at 02:37:39AM +0200, Maximilian Luz wrote:
> > > > +/*
> > > > + * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same 
> > > > device
> > > > + * ID (MSHW0040) for the power/volume buttons. Make sure this is the 
> > > > right
> > > > + * device by checking for the _DSM method and OEM Platform Revision.
> > > > + */
> > > > +static int surface_button_check_MSHW0040(struct acpi_device *dev)
> > > > +{
> > > > +acpi_handle handle = dev->handle;
> > > > +union acpi_object *result;
> > > > +u64 oem_platform_rev = 0;
> > > > +
> > > > +// get OEM platform revision
> > > > +result = acpi_evaluate_dsm_typed(handle, _DSM_UUID,
> > > > + MSHW0040_DSM_REVISION,
> > > > + MSHW0040_DSM_GET_OMPR,
> > > > + NULL, ACPI_TYPE_INTEGER);
> > > > +
> > > Does it mean, only 5th, 6th and newer platforms have OEM platform 
> > > revision?
> > > 3rd/4th will get NULL result? Or the opposite?
> > 
> > Correct, from my testing (with limited sample size) and AML code: 5th
> > and 6th generation devices have a non-zero OEM platform revision,
> > whereas 3rd and 4th gen. devices do not have any (i.e. result will be
> > NULL).
> > 
> > > > +if (result) {
> > > > +oem_platform_rev = result->integer.value;
> > > > +ACPI_FREE(result);
> > > > +}
> > > > +
> > > > +dev_dbg(>dev, "OEM Platform Revision %llu\n", 
> > > > oem_platform_rev);
> > > > +
> > > > +return oem_platform_rev == 0 ? 0 : -ENODEV;
> > > if 3rd/4th do not have this oem rev information while 5th/newer have,
> > > why the latter returns NODEV(it actually has this info)?
> > 
> > Since we always expect a non-zero platform revision (for 5th/6th gen.),
> > we can initialize it to zero and use that as "unknown"/"not available".
> > So if it can not be determined, we return NODEV.
> 
> Sorry, small mistake here: If it can be determined (i.e. is 5th or 6th
> gen.) then we return NODEV. Not the other way around.
>
How about using a boolean, according to the function name, if a mshw0040 revison
is detected then returns true other wise false. Other than that,
Acked-by: Chen Yu 

Best,
Chenyu
> Also to clarify on your last question:
> 
> On 7/2/19 3:14 AM, Yu Chen wrote:
> > >   static int surface_button_add(struct acpi_device *device)
> > >   {
> > >   struct surface_button *button;
> > > @@ -154,6 +188,10 @@ static int surface_button_add(struct acpi_device 
> > > *device)
> > >   strlen(SURFACE_BUTTON_OBJ_NAME)))
> > >   return -ENODEV;
> > > + error = surface_button_check_MSHW0040(device);
> > > + if (error)
> > > + return error;
> > > +
> > ditto, 3rd/4th get error=0?
> 
> You are correct.
> 
> Maximilian

Re: [PATCH v2 1/2] platform: Fix device check for surfacepro3_button

[Yu Chen]

Hi,
On Tue, Jul 02, 2019 at 02:37:39AM +0200, Maximilian Luz wrote:
> Do not use the surfacepro3_button driver on newer Microsoft Surface
> models, only use it on the Surface Pro 3 and 4. Newer models (5th, 6th
> and possibly future generations) use the same device as the Surface Pro
> 4 to represent their volume and power buttons (MSHW0040), but their
> acutal implementation is significantly different. This patch ensures
> that the surfacepro3_button driver is only used on the Pro 3 and 4
> models, allowing a different driver to bind on other models.
>
This method overall looks ok to me.
> Signed-off-by: Maximilian Luz 
> ---
>  drivers/platform/x86/surfacepro3_button.c | 38 +++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/drivers/platform/x86/surfacepro3_button.c 
> b/drivers/platform/x86/surfacepro3_button.c
> index 47c6d000465a..0e2c7dfafd9f 100644
> --- a/drivers/platform/x86/surfacepro3_button.c
> +++ b/drivers/platform/x86/surfacepro3_button.c
> @@ -20,6 +20,12 @@
>  #define SURFACE_BUTTON_OBJ_NAME  "VGBI"
>  #define SURFACE_BUTTON_DEVICE_NAME   "Surface Pro 3/4 Buttons"
>  
> +#define MSHW0040_DSM_REVISION0x01
> +#define MSHW0040_DSM_GET_OMPR0x02// get OEM Platform 
> Revision
> +static const guid_t MSHW0040_DSM_UUID =
> + GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
> +   0x49, 0x80, 0x35);
> +
>  #define SURFACE_BUTTON_NOTIFY_TABLET_MODE0xc8
>  
>  #define SURFACE_BUTTON_NOTIFY_PRESS_POWER0xc6
> @@ -142,6 +148,34 @@ static int surface_button_resume(struct device *dev)
>  }
>  #endif
>  
> +/*
> + * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same device
> + * ID (MSHW0040) for the power/volume buttons. Make sure this is the right
> + * device by checking for the _DSM method and OEM Platform Revision.
> + */
> +static int surface_button_check_MSHW0040(struct acpi_device *dev)
> +{
> + acpi_handle handle = dev->handle;
> + union acpi_object *result;
> + u64 oem_platform_rev = 0;
> +
> + // get OEM platform revision
> + result = acpi_evaluate_dsm_typed(handle, _DSM_UUID,
> +  MSHW0040_DSM_REVISION,
> +  MSHW0040_DSM_GET_OMPR,
> +  NULL, ACPI_TYPE_INTEGER);
> +
Does it mean, only 5th, 6th and newer platforms have OEM platform revision?
3rd/4th will get NULL result? Or the opposite?
> + if (result) {
> + oem_platform_rev = result->integer.value;
> + ACPI_FREE(result);
> + }
> +
> + dev_dbg(>dev, "OEM Platform Revision %llu\n", oem_platform_rev);
> +
> + return oem_platform_rev == 0 ? 0 : -ENODEV;
if 3rd/4th do not have this oem rev information while 5th/newer have,
why the latter returns NODEV(it actually has this info)?
> +}
> +
> +
>  static int surface_button_add(struct acpi_device *device)
>  {
>   struct surface_button *button;
> @@ -154,6 +188,10 @@ static int surface_button_add(struct acpi_device *device)
>   strlen(SURFACE_BUTTON_OBJ_NAME)))
>   return -ENODEV;
>  
> + error = surface_button_check_MSHW0040(device);
> + if (error)
> + return error;
> +
ditto, 3rd/4th get error=0?
>   button = kzalloc(sizeof(struct surface_button), GFP_KERNEL);
>   if (!button)
>   return -ENOMEM;
> -- 
> 2.22.0
> 
Best,
Yu

[PATCH] cpumask: cpumask_test_and_clear_cpu() comment correction

[Yu Chen]

Fix code comment for cpumask_test_and_clear_cpu().

Signed-off-by: Yu Chen 
---
 include/linux/cpumask.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 147bdec..73ca70d 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -363,7 +363,7 @@ static inline int cpumask_test_and_set_cpu(int cpu, struct 
cpumask *cpumask)
  * @cpu: cpu number (< nr_cpu_ids)
  * @cpumask: the cpumask pointer
  *
- * Returns 1 if @cpu is set in old bitmap of @cpumask, else returns 0
+ * Returns 1 if @cpu is clear in old bitmap of @cpumask, else returns 0
  *
  * test_and_clear_bit wrapper for cpumasks.
  */
-- 
2.17.1

[PATCH v4 12/12] dts: hi3660: Add support for usb on Hikey960

[Yu Chen]

This patch adds support for usb on Hikey960.

Cc: Chunfeng Yun 
Cc: Wei Xu 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v2:
* Remove device_type property.
* Add property "usb-role-switch".
v3:
* Make node "usb_phy" a subnode of usb3_otg_bc register.
* Remove property "typec-vbus-enable-val" of hisi_hikey_usb.
v4:
* Remove property "hisilicon,usb3-otg-bc-syscon" of usb-phy.
---
---
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 53 
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 74 +++
 2 files changed, 127 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index e035cf195b19..d4e11c56b250 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "HiKey960";
@@ -196,6 +197,26 @@
method = "smc";
};
};
+
+   hisi_hikey_usb: hisi_hikey_usb {
+   compatible = "hisilicon,hikey960_usb";
+   typec-vbus-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   otg-switch-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   hub-vdd33-en-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hikey_usb_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch_notify>;
+   };
+   };
+   };
+
 };
 
 /*
@@ -526,6 +547,38 @@
  {
status = "okay";
 
+   rt1711h: rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   status = "ok";
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cfg_func>;
+
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+   data-role = "dual";
+   power-role = "dual";
+   try-power-role = "sink";
+   source-pdos = ;
+   sink-pdos = ;
+   op-sink-microwatt = <1000>;
+   };
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rt1711h_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch>;
+   };
+   };
+   };
+
adv7533: adv7533@39 {
status = "ok";
compatible = "adi,adv7533";
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 2f19e0e5b7cf..77f7a191f0fd 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -355,6 +355,12 @@
#clock-cells = <1>;
};
 
+   pmctrl: pmctrl@fff31000 {
+   compatible = "hisilicon,hi3660-pmctrl", "syscon";
+   reg = <0x0 0xfff31000 0x0 0x1000>;
+   #clock-cells = <1>;
+   };
+
pmuctrl: crg_ctrl@fff34000 {
compatible = "hisilicon,hi3660-pmuctrl", "syscon";
reg = <0x0 0xfff34000 0x0 0x1000>;
@@ -1134,5 +1140,73 @@
};
};
};
+
+   usb3_otg_bc: usb3_otg_bc@ff20 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0xff20 0x0 0x1000>;
+
+   usb_phy: usb-phy {
+   compatible = "hisilicon,hi3660-usb-phy";
+   #phy-cells = <0>;
+   hisilicon,pericrg-syscon = <_ctrl>;
+   hisilicon,pctrl-syscon = <>;
+   hisilicon,usb3-otg-bc-syscon = <_otg_bc>;
+   hisilicon,eye-diagram-param = <0x22466e4>;
+   };
+   

[PATCH v4 03/12] usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc Platform

[Yu Chen]

This patch adds support for the poweron and shutdown of dwc3 core
on Hisilicon Soc Platform.

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Signed-off-by: Yu Chen 
---
 drivers/usb/dwc3/dwc3-of-simple.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index 4c2771c5e727..0ed09d876542 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -98,7 +98,8 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
 * Some controllers need to toggle the usb3-otg reset before trying to
 * initialize the PHY, otherwise the PHY times out.
 */
-   if (of_device_is_compatible(np, "rockchip,rk3399-dwc3"))
+   if (of_device_is_compatible(np, "rockchip,rk3399-dwc3") ||
+   of_device_is_compatible(np, "hisilicon,hi3660-dwc3"))
simple->need_reset = true;
 
if (of_device_is_compatible(np, "amlogic,meson-axg-dwc3") ||
@@ -243,6 +244,7 @@ static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "amlogic,meson-axg-dwc3" },
{ .compatible = "amlogic,meson-gxl-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
+   { .compatible = "hisilicon,hi3660-dwc3" },
{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
-- 
2.15.0-rc2

[PATCH v4 01/12] dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY

[Yu Chen]

This patch adds binding documentation for supporting the hi3660 usb
phy on boards like the HiKey960.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Fix some format error as suggested by Rob.
v2:
* Change hi3660 usb PHY to hi3660 USB PHY
v3:
* Make device node a subnode of usb3_otg_bc register.
v4:
* Remove "hisilicon,usb3-otg-bc-syscon" property
---
---
 .../devicetree/bindings/phy/phy-hi3660-usb3.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt 
b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
new file mode 100644
index ..e88ba7d92dcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
@@ -0,0 +1,26 @@
+Hisilicon hi3660 USB PHY
+---
+
+Required properties:
+- compatible: should be "hisilicon,hi3660-usb-phy"
+- #phy-cells: must be 0
+- hisilicon,pericrg-syscon: phandle of syscon used to control phy.
+- hisilicon,pctrl-syscon: phandle of syscon used to control phy.
+- hisilicon,eye-diagram-param: parameter set for phy
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+This is a subnode of usb3_otg_bc register node.
+
+Example:
+   usb3_otg_bc: usb3_otg_bc@ff20 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0xff20 0x0 0x1000>;
+
+   usb-phy {
+   compatible = "hisilicon,hi3660-usb-phy";
+   #phy-cells = <0>;
+   hisilicon,pericrg-syscon = <_ctrl>;
+   hisilicon,pctrl-syscon = <>;
+   hisilicon,eye-diagram-param = <0x22466e4>;
+   };
+   };
-- 
2.15.0-rc2

Re: [RFT][Update][PATCH 2/2] cpufreq: intel_pstate: Update max CPU frequency on global turbo changes

[Yu Chen]

On Fri, Mar 01, 2019 at 01:57:06PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> While the cpuinfo.max_freq value doesn't really matter for
> intel_pstate in the active mode, in the passive mode it is used by
> governors as the maximum physical frequency of the CPU and the
> results of governor computations generally depend on it.  Also it
> is made available to user space via sysfs and it should match the
> current HW configuration.
> 
> For this reason, make intel_pstate update cpuinfo.max_freq for all
> CPUs if it detects a global change of turbo frequency settings from
> "disable" to "enable" or the other way associated with a _PPC change
> notification from the platform firmware.
> 
> Note that policy_is_inactive() and cpufreq_set_policy() need to be
> made available to it for this purpose.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> Reported-by: Gabriele Mazzotta 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Update, because the patch sent previously doesn't build, due to an extra
> arg declared for intel_pstate_update_max_freq().
> 
> ---
>  drivers/cpufreq/cpufreq.c  |   12 ++--
>  drivers/cpufreq/intel_pstate.c |   33 -
>  include/linux/cpufreq.h|7 +++
>  3 files changed, 41 insertions(+), 11 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -897,6 +897,36 @@ static void intel_pstate_update_policies
>   cpufreq_update_policy(cpu);
>  }
>  
> +static void intel_pstate_update_max_freq(unsigned int cpu)
> +{
> + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> + struct cpufreq_policy new_policy;
> + struct cpudata *cpudata;
> +
> + if (!policy)
> + return;
> +
> + down_write(>rwsem);
> +
> + if (policy_is_inactive(policy))
> + goto unlock;
> +
> + cpudata = all_cpu_data[cpu];
> + policy->cpuinfo.max_freq = global.turbo_disabled_upd ?
> + cpudata->pstate.max_freq : cpudata->pstate.turbo_freq;
> +
> + memcpy(_policy, policy, sizeof(*policy));
> + new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq);
> + new_policy.min = min(policy->user_policy.min, new_policy.max);
> +
> + cpufreq_set_policy(policy, _policy);
> +
> +unlock:
> + up_write(>rwsem);
> +
> + cpufreq_cpu_put(policy);
> +}
> +
I tried to test on a macbook in hand however I did not see the _PPC
notifier on this machine so it might not cover the code path in
this patch. I checked the cpufreq with this patch using
different load and the cpufreq scales well.

>  static void intel_pstate_update_limits(unsigned int cpu)
>  {
>   mutex_lock(_pstate_driver_lock);
> @@ -908,7 +938,8 @@ static void intel_pstate_update_limits(u
>*/
>   if (global.turbo_disabled_upd != global.turbo_disabled) {
>   global.turbo_disabled_upd = global.turbo_disabled;
> - intel_pstate_update_policies();
> + for_each_possible_cpu(cpu)
> + intel_pstate_update_max_freq(cpu);
>   } else {
>   cpufreq_update_policy(cpu);
>   }
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -34,11 +34,6 @@
>  
>  static LIST_HEAD(cpufreq_policy_list);
>  
> -static inline bool policy_is_inactive(struct cpufreq_policy *policy)
> -{
> - return cpumask_empty(policy->cpus);
> -}
> -
>  /* Macros to iterate over CPU policies */
>  #define for_each_suitable_policy(__policy, __active)  \
>   list_for_each_entry(__policy, _policy_list, policy_list) \
> @@ -675,9 +670,6 @@ static ssize_t show_scaling_cur_freq(str
>   return ret;
>  }
>  
> -static int cpufreq_set_policy(struct cpufreq_policy *policy,
> - struct cpufreq_policy *new_policy);
> -
>  /**
>   * cpufreq_per_cpu_attr_write() / store_##file_name() - sysfs write access
>   */
> @@ -2235,8 +2227,8 @@ EXPORT_SYMBOL(cpufreq_get_policy);
>   *
>   * The cpuinfo part of @policy is not updated by this function.
>   */
There first seems to be some patching error when applying this on
top of upstream 5.0, but I realized that this patch is based on
intel-next.

Thanks,
Ryan

> -static int cpufreq_set_policy(struct cpufreq_policy *policy,
> -   struct cpufreq_policy *new_policy)
> +int cpufreq_set_policy(struct cpufreq_policy *policy,
> +struct cpufreq_policy *new_policy)
>  {
>   struct cpufreq_governor *old_gov;
>   int ret;
> Index: linux-pm/include/linux/cpufreq.h
> ===
> --- linux-pm.orig/include/linux/cpufreq.h
> +++ 

Re: [RFT][PATCH 0/2] cpufreq: intel_pstate: Handle _PPC updates on global turbo disable/enable

[Yu Chen]

On Fri, Mar 01, 2019 at 09:39:27AM -0800, Srinivas Pandruvada wrote:
> On Fri, 2019-03-01 at 13:43 +0100, Rafael J. Wysocki wrote:
> > Hi All,
> > 
> > This is how I would fix the issue reported in BZ 200759 (see this
> > patch series
> > from Yu too: https://marc.info/?l=linux-pm=155137672924029=2).
> > 
> > Patch [1/2] causes intel_pstate to update all policies if it gets a
> > _PPC change
> > notification and sees a global turbo disable/enable change.
> > 
> > Patch [2/2] makes it update cpuinfo.max_freq for all policies in
> > those cases.
> > 
> > The patches here have not been tested yet, so testing would be much
> > appreciated.
> > 
> > Of course, comments are welcome too!
> 
> This is the only platform, someone reported such issue.
> Can we solve this by some udev rules and offline/online cpu 1-3 on
> power source change?
>
Sound reasonable, we can deal with this BIOS problem in user space
too. But if cpu0 could not be offline, how could cpu0's policy
be updated?

Thanks,
Yu

> There are examples of changing governors on power source change.
> https://bbs.archlinux.org/viewtopic.php?id=207186
> 
> Here instead of changing governor just
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo 1 > /sys/devices/system/cpu/cpu1/online
> echo 0 >
> /sys/devices/system/cpu/cpu2/online
> echo 1 >
> /sys/devices/system/cpu/cpu2/online
> echo 0 >
> /sys/devices/system/cpu/cpu3/online
> echo 1 >
> /sys/devices/system/cpu/cpu3/online
> 
> Thanks,
> Srinivas
> 
> > 
> > Thanks,
> > Rafael
> > 
> 

Re: [PATCH 1/2][RFC v2] ACPI: add "processor.broadcast_ppc" hook to broadcast _PPC

[Yu Chen]

On Fri, Mar 01, 2019 at 10:34:46AM +0100, Rafael J. Wysocki wrote:
> On Thu, Feb 28, 2019 at 11:18 PM Rafael J. Wysocki  wrote:
> >
> > On Thu, Feb 28, 2019 at 6:59 PM Chen Yu  wrote:
> > >
> > > On some problematic platforms, the _PPC notifier is
> > > only delivered to one CPU, which might cause information
> > > inconsistent between CPUs within the package. Thus introduce a boot up 
> > > parameter to broadcast this _PPC notifier onto all
> > > online CPUs.
> > >
> > > Signed-off-by: Chen Yu 
> > > ---
> > >  drivers/acpi/processor_perflib.c | 16 ++--
> > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_perflib.c 
> > > b/drivers/acpi/processor_perflib.c
> > > index a303fd0e108c..737dbf5aa7f7 100644
> > > --- a/drivers/acpi/processor_perflib.c
> > > +++ b/drivers/acpi/processor_perflib.c
> > > @@ -63,6 +63,10 @@ module_param(ignore_ppc, int, 0644);
> > >  MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets 
> > > wrongly" \
> > >  "limited by BIOS, this should help");
> > >
> > > +static int broadcast_ppc;
> > > +module_param(broadcast_ppc, int, 0644);
> > > +MODULE_PARM_DESC(broadcast_ppc, "Broadcast the ppc to all online CPUs");
> > > +
> > >  #define PPC_REGISTERED   1
> > >  #define PPC_IN_USE   2
> > >
> > > @@ -180,8 +184,16 @@ void acpi_processor_ppc_has_changed(struct 
> > > acpi_processor *pr, int event_flag)
> > > else
> > > acpi_processor_ppc_ost(pr->handle, 0);
> > > }
> > > -   if (ret >= 0)
> > > -   cpufreq_update_policy(pr->id);
> > > +   if (ret >= 0) {
> > > +   if (broadcast_ppc) {
> > > +   int cpu;
> > > +
> > > +   for_each_possible_cpu(cpu)
> > > +   cpufreq_update_policy(cpu);
> >
> > This doesn't actually help AFAICS, because it only causes
> > acpi_processor_ppc_notifier() to be called for all policies, but
> > pr->performance_platform_limit is re-computed for the target CPU only
> > anyway, so the limit will only be applied to that one.
> >
> > What happens in the BZ is that invoking cpufreq_update_policy() for
> > all CPUs causes ->verify() to run on all of them which triggers
> > update_turbo_state() and cpuinfo.max_freq update, because
> > global.turbo_disabled has changed.
> >
> > That is rather less than straightforward and intel_pstate really
> > doesn't need any _PPC change notifications to notice that the
> > MSR_IA32_MISC_ENABLE_TURBO_DISABLE bit has changed as it checks that
> > bit on every P-state update.
> 
> Which admittedly may not be necessary if notifications are delivered.
> 
> I still don't think that updating all policies from
> acpi_processor_ppc_has_changed() is a good idea, but yes, there is a
> problem that if MSR_IA32_MISC_ENABLE_TURBO_DISABLE goes from set to
> unset, all policies need to be updated to update policy->max
> accordingly, 
Agree. policy->max might needed to be updated otherwise we might
not get correct cpufreq limit range. According to the report log
from bugzilla, if the system boots without AC and then plug the AC
after boot up, the max_perf_ratio would be incorrect because policy->max
is not updated.

# Plug the AC:

[   52.158810] CPU 0: _PPC is 6 - frequency  limited
[   52.158822] intel_pstate: set_policy cpuinfo.max 170 policy->max 170
[   52.158825] intel_pstate: cpu:0 max_state 30 min_policy_perf:8 
max_policy_perf:17
[   52.158827] intel_pstate: cpu:0 global_min:8 global_max:30
[   52.158829] intel_pstate: cpu:0 max_perf_ratio:17 min_perf_ratio:8

Thanks,
Yu
> so looking at MSR_IA32_MISC_ENABLE_TURBO_DISABLE from
> within the driver without triggering a policy update is not
> sufficient.

Re: [PATCH 2/2][RFC v2] ACPI: Update cpuinfo.max after bootup if necessary

[Yu Chen]

On Thu, Feb 28, 2019 at 11:56:48PM +0100, Rafael J. Wysocki wrote:
> On Thu, Feb 28, 2019 at 6:59 PM Chen Yu  wrote:
> >
> > On Dell Inc. XPS13 9333, the BIOS changes the value of
> > MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when
> > the power source changes), the maximum frequency of the
> > CPU is not updated accordingly. This is due to the policy's
> > cpuinfo.max is not updated when _PPC notifier fires.
> >
> > Fix this problem by updating the policy's cpuinfo.max when
> > necessary.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> > Reported-and-tested-by: Gabriele Mazzotta 
> > Originally-by: Srinivas Pandruvada 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/cpufreq/cpufreq.c  |  2 ++
> >  drivers/cpufreq/intel_pstate.c | 15 +--
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index e35a886e00bc..95e08816b512 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2237,6 +2237,8 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> > *policy,
> >
> > policy->min = new_policy->min;
> > policy->max = new_policy->max;
> > +   policy->cpuinfo.max_freq = new_policy->cpuinfo.max_freq;
> > +   policy->cpuinfo.min_freq = new_policy->cpuinfo.min_freq;
> > trace_cpu_frequency_limits(policy);
> >
> > policy->cached_target_freq = UINT_MAX;
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index dd66decf2087..841c74f69f66 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -2081,11 +2081,17 @@ static void intel_pstate_adjust_policy_max(struct 
> > cpufreq_policy *policy,
> >
> >  static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
> >  {
> > +   int max_freq;
> > struct cpudata *cpu = all_cpu_data[policy->cpu];
> >
> > update_turbo_state();
> > +   max_freq = intel_pstate_get_max_freq(cpu);
> > +
> > +   if (acpi_ppc && max_freq != policy->cpuinfo.max_freq)
> > +   policy->cpuinfo.max_freq = policy->max = max_freq;
> 
> Updating cpuinfo.max_freq here only causes the current limit to be
> reported via sysfs, because intel_pstate doesn't actually use
> cpuinfo.max_freq for anything and the core doesn't enforce it as a
> limit.
> 
> All of the computations in the active mode in the driver actually use
> the current limit anyway AFAICS.
>
Yes, but it looks like we should also take care of the cpuinfo.max
if it changes, I searched the code, it seems that other components
might use the policy's cpuinfo.max for some purpose. They might use
cpufreq_cpu_get() to get the policy, and use the cpuinfo.max_freq
directly, no matter what the mode intel_pstate is in. Such as kvm
might use it as the max tsc khz if the tsc is not constant. And i915
might consider the cpuinfo.max_freq to adjust the IA frequency on
gen6 platforms. So changing cpuinfo.max might also impact not only
cpufreq but also other components too.
> > +
> > cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
> > -intel_pstate_get_max_freq(cpu));
> > +max_freq);
> >
> > if (policy->policy != CPUFREQ_POLICY_POWERSAVE &&
> > policy->policy != CPUFREQ_POLICY_PERFORMANCE)
> > @@ -2192,11 +2198,16 @@ static struct cpufreq_driver intel_pstate = {
> >
> >  static int intel_cpufreq_verify_policy(struct cpufreq_policy *policy)
> >  {
> > +   int max_freq;
> > struct cpudata *cpu = all_cpu_data[policy->cpu];
> >
> > update_turbo_state();
> > +   max_freq = intel_pstate_get_max_freq(cpu);
> > +
> > +   if (acpi_ppc && max_freq != policy->cpuinfo.max_freq)
> > +   policy->cpuinfo.max_freq = policy->max = max_freq;
> 
> In this case (passive mode) updating cpuinfo.max_freq will actually
> cause governors to use the new value in computations, so the P-state
> selection will work somewhat differently, but that isn't really
> consistent with what acpi-cpufreq does and with setting no_turbo in
> the intel_pstate sysfs to 1 without this patch.
> 
> With acpi-cpufreq cpuinfo.max_freq is always the max frequency in the
> _PSS table regardless of what the _PSS limit is.  Also setting
> no_turbo to 1 in intel_pstate without this patch doesn't cause
> cpuinfo.max_freq to change and I don't really think that it should.
> 
> I would be tempted to always initialize cpuinfo.max_freq to the max
> turbo frequency, but there is a concern about systems in which
> MSR_IA32_MISC_ENABLE_TURBO_DISABLE is never set on the fly (just in
> the BIOS setup as it should be) and where it doesn't make sense to
> consider turbo frequencies at all.
Ok, maybe we can check the bit during boot(consider BIOS's setting)?
> 
> > cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
> > -

[PATCH v3 04/12] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc

[Yu Chen]

SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core
of Hisilicon Kirin Soc when dwc3 core act as host.

Cc: Andy Shevchenko 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
 drivers/usb/dwc3/core.c | 24 
 drivers/usb/dwc3/core.h |  6 ++
 2 files changed, 30 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a1b126f90261..f7d561fe1f04 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -117,6 +117,7 @@ static void __dwc3_set_mode(struct work_struct *work)
struct dwc3 *dwc = work_to_dwc(work);
unsigned long flags;
int ret;
+   u32 reg;
 
if (dwc->dr_mode != USB_DR_MODE_OTG)
return;
@@ -169,6 +170,11 @@ static void __dwc3_set_mode(struct work_struct *work)
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
phy_calibrate(dwc->usb2_generic_phy);
+   if (dwc->dis_split_quirk) {
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
+   reg |= DWC3_GUCTL3_SPLITDISABLE;
+   dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
+   }
}
break;
case DWC3_GCTL_PRTCAP_DEVICE:
@@ -1306,6 +1312,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
 
+   dwc->dis_split_quirk = device_property_read_bool(dev,
+   "snps,dis-split-quirk");
+
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
 
@@ -1825,10 +1834,25 @@ static int dwc3_resume(struct device *dev)
 
return 0;
 }
+
+static void dwc3_complete(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   u32 reg;
+
+   if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST &&
+   dwc->dis_split_quirk) {
+   dev_dbg(dwc->dev, "set DWC3_GUCTL3_SPLITDISABLE\n");
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
+   reg |= DWC3_GUCTL3_SPLITDISABLE;
+   dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
+   }
+}
 #endif /* CONFIG_PM_SLEEP */
 
 static const struct dev_pm_ops dwc3_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+   .complete = dwc3_complete,
SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
dwc3_runtime_idle)
 };
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index df876418cb78..bc2a1ebc0076 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -136,6 +136,7 @@
 #define DWC3_GEVNTCOUNT(n) (0xc40c + ((n) * 0x10))
 
 #define DWC3_GHWPARAMS80xc600
+#define DWC3_GUCTL30xc60c
 #define DWC3_GFLADJ0xc630
 
 /* Device Registers */
@@ -370,6 +371,9 @@
 /* Global User Control Register 2 */
 #define DWC3_GUCTL2_RST_ACTBITLATERBIT(14)
 
+/* Global User Control Register 3 */
+#define DWC3_GUCTL3_SPLITDISABLE   BIT(14)
+
 /* Device Configuration Register */
 #define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
 #define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
@@ -1210,6 +1214,8 @@ struct dwc3 {
 
unsigneddis_metastability_quirk:1;
 
+   unsigneddis_split_quirk:1;
+
u16 imod_interval;
 };
 
-- 
2.15.0-rc2

[PATCH v3 01/12] dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY

[Yu Chen]

This patch adds binding documentation for supporting the hi3660 usb
phy on boards like the HiKey960.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Fix some format error as suggested by Rob.
v2:
* Change hi3660 usb PHY to hi3660 USB PHY
v3:
* Make device node a subnode of usb3_otg_bc register.
---
---
 .../devicetree/bindings/phy/phy-hi3660-usb3.txt| 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt 
b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
new file mode 100644
index ..6096214a2bc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
@@ -0,0 +1,28 @@
+Hisilicon hi3660 USB PHY
+---
+
+Required properties:
+- compatible: should be "hisilicon,hi3660-usb-phy"
+- #phy-cells: must be 0
+- hisilicon,pericrg-syscon: phandle of syscon used to control phy.
+- hisilicon,pctrl-syscon: phandle of syscon used to control phy.
+- hisilicon,usb3-otg-bc-syscon: phandle of syscon used to control phy.
+- hisilicon,eye-diagram-param: parameter set for phy
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+This is a subnode of usb3_otg_bc register node.
+
+Example:
+   usb3_otg_bc: usb3_otg_bc@ff20 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0xff20 0x0 0x1000>;
+
+   usb-phy {
+   compatible = "hisilicon,hi3660-usb-phy";
+   #phy-cells = <0>;
+   hisilicon,pericrg-syscon = <_ctrl>;
+   hisilicon,pctrl-syscon = <>;
+   hisilicon,usb3-otg-bc-syscon = <_otg_bc>;
+   hisilicon,eye-diagram-param = <0x22466e4>;
+   };
+   };
-- 
2.15.0-rc2

[PATCH v3 07/12] phy: Add usb phy support for hi3660 Soc of Hisilicon

[Yu Chen]

This driver handles usb phy power on and shutdown for hi3660 Soc of
Hisilicon.

Cc: Andy Shevchenko 
Cc: Kishon Vijay Abraham I 
Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Cc: Mauro Carvalho Chehab 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Shawn Guo 
Cc: Pengcheng Li 
Cc: Jianguo Sun 
Cc: Masahiro Yamada 
Cc: Jiancheng Xue 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Remove unused code and add comment for time delay as suggested by
Kishon Vijay Abraham I.
v2:
* Fix license declaration.
* Remove redundant parens.
* Remove unused member variables in struct hi3660_priv.
---
---
 MAINTAINERS |   8 ++
 drivers/phy/hisilicon/Kconfig   |  10 ++
 drivers/phy/hisilicon/Makefile  |   1 +
 drivers/phy/hisilicon/phy-hi3660-usb3.c | 232 
 4 files changed, 251 insertions(+)
 create mode 100644 drivers/phy/hisilicon/phy-hi3660-usb3.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dce5c099f43c..ac2e518ab85f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15822,6 +15822,14 @@ L: linux-...@vger.kernel.org
 S: Maintained
 F: drivers/usb/roles/intel-xhci-usb-role-switch.c
 
+USB IP DRIVER FOR HISILICON KIRIN
+M:     Yu Chen 
+M: Binghui Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
+F: drivers/phy/hisilicon/phy-hi3660-usb3.c
+
 USB ISP116X DRIVER
 M: Olav Kongas 
 L: linux-...@vger.kernel.org
diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
index b40ee54a1a50..3c142f08987c 100644
--- a/drivers/phy/hisilicon/Kconfig
+++ b/drivers/phy/hisilicon/Kconfig
@@ -12,6 +12,16 @@ config PHY_HI6220_USB
 
  To compile this driver as a module, choose M here.
 
+config PHY_HI3660_USB
+   tristate "hi3660 USB PHY support"
+   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the HISILICON HI3660 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
 config PHY_HISTB_COMBPHY
tristate "HiSilicon STB SoCs COMBPHY support"
depends on (ARCH_HISI && ARM64) || COMPILE_TEST
diff --git a/drivers/phy/hisilicon/Makefile b/drivers/phy/hisilicon/Makefile
index f662a4fe18d8..75ba64e2faf8 100644
--- a/drivers/phy/hisilicon/Makefile
+++ b/drivers/phy/hisilicon/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_PHY_HI6220_USB)   += phy-hi6220-usb.o
+obj-$(CONFIG_PHY_HI3660_USB)   += phy-hi3660-usb3.o
 obj-$(CONFIG_PHY_HISTB_COMBPHY)+= phy-histb-combphy.o
 obj-$(CONFIG_PHY_HISI_INNO_USB2)   += phy-hisi-inno-usb2.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
diff --git a/drivers/phy/hisilicon/phy-hi3660-usb3.c 
b/drivers/phy/hisilicon/phy-hi3660-usb3.c
new file mode 100644
index ..97184e6f0d41
--- /dev/null
+++ b/drivers/phy/hisilicon/phy-hi3660-usb3.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Phy provider for USB 3.0 controller on HiSilicon 3660 platform
+ *
+ * Copyright (C) 2017-2018 Hilisicon Electronics Co., Ltd.
+ *     http://www.huawei.com
+ *
+ * Authors: Yu Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PERI_CRG_CLK_EN4   0x40
+#define PERI_CRG_CLK_DIS4  0x44
+#define GT_CLK_USB3OTG_REF BIT(0)
+#define GT_ACLK_USB3OTGBIT(1)
+
+#define PERI_CRG_RSTEN40x90
+#define PERI_CRG_RSTDIS4   0x94
+#define IP_RST_USB3OTGPHY_POR  BIT(3)
+#define IP_RST_USB3OTG BIT(5)
+
+#define PERI_CRG_ISODIS0x148
+#define USB_REFCLK_ISO_EN  BIT(25)
+
+#define PCTRL_PERI_CTRL3   0x10
+#define PCTRL_PERI_CTRL3_MSK_START 16
+#define USB_TCXO_ENBIT(1)
+
+#define PCTRL_PERI_CTRL24  0x64
+#define SC_CLK_USB3PHY_3MUX1_SEL   BIT(25)
+
+#define USBOTG3_CTRL0  0x00
+#define SC_USB3PHY_ABB_GT_EN   BIT(15)
+
+#define USBOTG3_CTRL2  0x08
+#define USBOTG3CTRL2_POWERDOWN_HSP BIT(0)
+#define USBOTG3CTRL2_POWERDOWN_SSP BIT(1)
+
+#define USBOTG3_CTRL3  0x0C
+#define USBOTG3_CTRL3_VBUSVLDEXT   BIT(6)
+#define USBOTG3_CTRL3_VBUSVLDEXTSELBIT(5)
+
+#define USBOTG3_CTRL4  0x10
+
+#define USBOTG3_CTRL7  0x1c
+#define REF_SSP_EN BIT(16)
+
+#define HI3660_USB_DEFAULT_PHY_PARAM   0x1c466e3
+
+struct hi3660_priv {
+   struct device *dev;
+   struct regmap *peri_crg;
+   struct regmap *pctrl;
+   struct

[PATCH v3 05/12] usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe for Hisilicon Kirin Soc

[Yu Chen]

A GCTL soft reset should be executed when switch mode for dwc3 core
of Hisilicon Kirin Soc.

Cc: Andy Shevchenko 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
 drivers/usb/dwc3/core.c | 19 +++
 drivers/usb/dwc3/core.h |  1 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f7d561fe1f04..f260977f0206 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -112,6 +112,19 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
dwc->current_dr_role = mode;
 }
 
+static void dwc3_gctl_core_soft_reset(struct dwc3 *dwc)
+{
+   u32 reg;
+
+   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+   reg |= DWC3_GCTL_CORESOFTRESET;
+   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+   reg &= ~DWC3_GCTL_CORESOFTRESET;
+   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+}
+
 static void __dwc3_set_mode(struct work_struct *work)
 {
struct dwc3 *dwc = work_to_dwc(work);
@@ -157,6 +170,10 @@ static void __dwc3_set_mode(struct work_struct *work)
 
dwc3_set_prtcap(dwc, dwc->desired_dr_role);
 
+   /* Execute a GCTL Core Soft Reset when switch mode */
+   if (dwc->gctl_reset_quirk)
+   dwc3_gctl_core_soft_reset(dwc);
+
spin_unlock_irqrestore(>lock, flags);
 
switch (dwc->desired_dr_role) {
@@ -1314,6 +1331,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
 
dwc->dis_split_quirk = device_property_read_bool(dev,
"snps,dis-split-quirk");
+   dwc->gctl_reset_quirk = device_property_read_bool(dev,
+   "snps,gctl-reset-quirk");
 
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index bc2a1ebc0076..402b3c29eb26 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1215,6 +1215,7 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
unsigneddis_split_quirk:1;
+   unsignedgctl_reset_quirk:1;
 
u16 imod_interval;
 };
-- 
2.15.0-rc2

[PATCH v3 09/12] usb: dwc3: Registering a role switch in the DRD code.

[Yu Chen]

The Type-C drivers use USB role switch API to inform the
system about the negotiated data role, so registering a role
switch in the DRD code in order to support platforms with
USB Type-C connectors.

Cc: Jun Li 
Cc: Valentin Schneider 
Cc: John Stultz 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Heikki Krogerus 
Suggested-by: Heikki Krogerus 
Signed-off-by: Yu Chen 
---
v2:
* Assign fwnode in dwc3_role_switch.
v3:
* Add default mode property for usb role switch.
* Add select USB_ROLE_SWITCH for USB_DWC3_DUAL_ROLE in Kconfig.
* Do usb_role_switch_register only if property "usb-role-switch" present.
---
---
 drivers/usb/dwc3/Kconfig |  1 +
 drivers/usb/dwc3/core.h  |  3 +++
 drivers/usb/dwc3/drd.c   | 58 +++-
 3 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 1a0404fda596..3a0cb9f1f38a 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -42,6 +42,7 @@ config USB_DWC3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_DWC3) && (USB_GADGET=y || 
USB_GADGET=USB_DWC3))
depends on (EXTCON=y || EXTCON=USB_DWC3)
+   select USB_ROLE_SWITCH
help
  This is the default mode of working of DWC3 controller where
  both host and gadget features are enabled.
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 402b3c29eb26..b2b0da007bff 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1083,6 +1084,8 @@ struct dwc3 {
struct extcon_dev   *edev;
struct notifier_block   edev_nb;
enum usb_phy_interface  hsphy_mode;
+   struct usb_role_switch  *role_sw;
+   enum usb_dr_moderole_switch_default_mode;
 
u32 fladj;
u32 irq_gadget;
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 869725d15c74..5bfea03233d7 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -474,6 +474,43 @@ static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
return edev;
 }
 
+static int dwc3_usb_role_switch_set(struct device *dev, enum usb_role role)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   u32 mode;
+
+   switch (role) {
+   case USB_ROLE_HOST:
+   mode = DWC3_GCTL_PRTCAP_HOST;
+   break;
+   case USB_ROLE_DEVICE:
+   mode = DWC3_GCTL_PRTCAP_DEVICE;
+   break;
+   default:
+   if (dwc->role_switch_default_mode == USB_DR_MODE_HOST)
+   mode = DWC3_GCTL_PRTCAP_HOST;
+   else
+   mode = DWC3_GCTL_PRTCAP_DEVICE;
+   break;
+   }
+
+   dwc3_set_mode(dwc, mode);
+   return 0;
+}
+
+static enum usb_role dwc3_usb_role_switch_get(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   unsigned long flags;
+   enum usb_role role;
+
+   spin_lock_irqsave(>lock, flags);
+   role = dwc->current_otg_role;
+   spin_unlock_irqrestore(>lock, flags);
+
+   return role;
+}
+
 int dwc3_drd_init(struct dwc3 *dwc)
 {
int ret, irq;
@@ -482,7 +519,23 @@ int dwc3_drd_init(struct dwc3 *dwc)
if (IS_ERR(dwc->edev))
return PTR_ERR(dwc->edev);
 
-   if (dwc->edev) {
+   if (device_property_read_bool(dwc->dev, "usb-role-switch")) {
+   struct usb_role_switch_desc dwc3_role_switch = {0};
+
+   if (device_property_read_bool(dwc->dev,
+   "role-switch-default-host"))
+   dwc->role_switch_default_mode = USB_DR_MODE_HOST;
+   else
+   dwc->role_switch_default_mode = USB_DR_MODE_PERIPHERAL;
+
+   dwc3_role_switch.fwnode = dev_fwnode(dwc->dev);
+   dwc3_role_switch.set = dwc3_usb_role_switch_set;
+   dwc3_role_switch.get = dwc3_usb_role_switch_get;
+   dwc->role_sw = usb_role_switch_register(dwc->dev,
+   _role_switch);
+   if (IS_ERR(dwc->role_sw))
+   return PTR_ERR(dwc->role_sw);
+   } else if (dwc->edev) {
dwc->edev_nb.notifier_call = dwc3_drd_notifier;
ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
   >edev_nb);
@@ -529,6 +582,9 @@ void dwc3_drd_exit(struct dwc3 *dwc)
 {
unsigned long flags;
 
+   if (dwc->role_sw)
+   usb_role_switch_unregister(dwc->role_sw);
+
if (dwc->edev)
extcon_unregister_notifier(dwc->edev, EXTCON_USB_HOST,
   >edev_nb);
-- 
2.15.0-rc2

[PATCH v3 02/12] dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960

[Yu Chen]

This patch adds binding documentation to support usb hub and usb
data role switch of Hisilicon HiKey960 Board.

Cc: Sergei Shtylyov 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Fix some format errors as suggested by Sergei.
* Modify gpio description to use gpiod API.
v2:
* Remove information about Hikey.
* Fix gpio description.
* Remove device_type of endpoint.
v3:
* Remove property typec-vbus-enable-val.
* Add description of pinctrl-names.
* Add example for "hisilicon,gpio-hubv1"
* Add flag in gpiod properties.
---
---
 .../bindings/misc/hisilicon-hikey-usb.txt  | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt

diff --git a/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt 
b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt
new file mode 100644
index ..422e844df719
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt
@@ -0,0 +1,52 @@
+Support usb hub and usb data role switch of Hisilicon HiKey960 Board.
+
+-
+
+Required properties:
+- compatible: "hisilicon,gpio-hubv1","hisilicon,hikey960-usb"
+- typec-vbus-gpios: gpio to control the vbus of typeC port
+- otg-switch-gpios: gpio to switch DP & DM between the hub and typeC port
+- hub-vdd33-en-gpios: gpio to enable the power of hub
+- pinctrl-names: pin configuration state name ("default")
+- pinctrl-0: pinctrl config
+
+Example
+-
+
+   hisi_hikey_usb: hisi_hikey_usb {
+   compatible = "hisilicon,hikey960-usb";
+   typec-vbus-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   otg-switch-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   hub-vdd33-en-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hikey_usb_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch_notify>;
+   };
+   };
+   };
+
+   hisi_hikey_usb: hisi_hikey_usb {
+   compatible = "hisilicon,gpio-hubv1";
+   typec-vbus-gpios = < 2 GPIO_ACTIVE_LOW>;
+   otg-switch-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   hub-vdd33-en-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hikey_usb_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch_notify>;
+   };
+   };
+   };
-- 
2.15.0-rc2

[PATCH v3 10/12] hikey960: Support usb functionality of Hikey960

[Yu Chen]

This driver handles usb hub power on and typeC port event of HiKey960 board:
1)DP switching between usb hub and typeC port base on typeC port
state
2)Control power of usb hub on Hikey960
3)Control vbus of typeC port

Cc: Chunfeng Yun 
Cc: Andy Shevchenko 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Cc: Heikki Krogerus 
Signed-off-by: Yu Chen 
---
v1:
* Using gpiod API with the gpios.
* Removing registering usb role switch.
* Registering usb role switch notifier.
v2:
* Fix license declaration.
* Add configuration of  gpio direction.
* Remove some log print.
v3:
* Remove property of "typec_vbus_enable_val".
* Remove gpiod_direction_output and set initial value of gpio by devm_gpiod_get.
---
---
 drivers/misc/Kconfig  |   6 ++
 drivers/misc/Makefile |   1 +
 drivers/misc/hisi_hikey_usb.c | 167 ++
 3 files changed, 174 insertions(+)
 create mode 100644 drivers/misc/hisi_hikey_usb.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f417b06e11c5..8d8b717759e2 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -521,6 +521,12 @@ config PVPANIC
  a paravirtualized device provided by QEMU; it lets a virtual machine
  (guest) communicate panic events to the host.
 
+config HISI_HIKEY_USB
+   tristate "USB functionality of HiSilicon Hikey Platform"
+   depends on OF && GPIOLIB
+   help
+ If you say yes here you get support for usb functionality of 
HiSilicon Hikey Platform.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e39ccbbc1b3a..dc8892b13a1a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_PCI_ENDPOINT_TEST)   += pci_endpoint_test.o
 obj-$(CONFIG_OCXL) += ocxl/
 obj-y  += cardreader/
 obj-$(CONFIG_PVPANIC)  += pvpanic.o
+obj-$(CONFIG_HISI_HIKEY_USB)   += hisi_hikey_usb.o
diff --git a/drivers/misc/hisi_hikey_usb.c b/drivers/misc/hisi_hikey_usb.c
new file mode 100644
index ..85d6fee468c0
--- /dev/null
+++ b/drivers/misc/hisi_hikey_usb.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support for usb functionality of Hikey series boards
+ * based on Hisilicon Kirin Soc.
+ *
+ * Copyright (C) 2017-2018 Hilisicon Electronics Co., Ltd.
+ * http://www.huawei.com
+ *
+ * Authors: Yu Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVICE_DRIVER_NAME "hisi_hikey_usb"
+
+#define HUB_VBUS_POWER_ON 1
+#define HUB_VBUS_POWER_OFF 0
+#define USB_SWITCH_TO_HUB 1
+#define USB_SWITCH_TO_TYPEC 0
+#define TYPEC_VBUS_POWER_ON 1
+#define TYPEC_VBUS_POWER_OFF 0
+
+struct hisi_hikey_usb {
+   struct gpio_desc *otg_switch;
+   struct gpio_desc *typec_vbus;
+   struct gpio_desc *hub_vbus;
+
+   struct usb_role_switch *role_sw;
+   struct notifier_block nb;
+};
+
+static void hub_power_ctrl(struct hisi_hikey_usb *hisi_hikey_usb, int value)
+{
+   gpiod_set_value_cansleep(hisi_hikey_usb->hub_vbus, value);
+}
+
+static void usb_switch_ctrl(struct hisi_hikey_usb *hisi_hikey_usb,
+   int switch_to)
+{
+   gpiod_set_value_cansleep(hisi_hikey_usb->otg_switch, switch_to);
+}
+
+static void usb_typec_power_ctrl(struct hisi_hikey_usb *hisi_hikey_usb,
+   int value)
+{
+   gpiod_set_value_cansleep(hisi_hikey_usb->typec_vbus, value);
+}
+
+static int hisi_hikey_role_switch(struct notifier_block *nb,
+   unsigned long state, void *data)
+{
+   struct hisi_hikey_usb *hisi_hikey_usb;
+
+   hisi_hikey_usb = container_of(nb, struct hisi_hikey_usb, nb);
+
+   switch (state) {
+   case USB_ROLE_NONE:
+   usb_typec_power_ctrl(hisi_hikey_usb, TYPEC_VBUS_POWER_OFF);
+   usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_HUB);
+   hub_power_ctrl(hisi_hikey_usb, HUB_VBUS_POWER_ON);
+   break;
+   case USB_ROLE_HOST:
+   usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_TYPEC);
+   usb_typec_power_ctrl(hisi_hikey_usb, TYPEC_VBUS_POWER_ON);
+   break;
+   case USB_ROLE_DEVICE:
+   hub_power_ctrl(hisi_hikey_usb, HUB_VBUS_POWER_OFF);
+   usb_typec_power_ctrl(hisi_hikey_usb, TYPEC_VBUS_POWER_OFF);
+   usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_TYPEC);
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
+static int hisi_hikey_usb_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *root = dev->of_node;
+   struct hisi_hikey_usb *hisi_hikey_usb;
+   int ret;
+
+   hisi_hikey_usb = 

[PATCH v3 03/12] usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc Platform

[Yu Chen]

This patch adds support for the poweron and shutdown of dwc3 core
on Hisilicon Soc Platform.
---
 drivers/usb/dwc3/dwc3-of-simple.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index 4c2771c5e727..0ed09d876542 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -98,7 +98,8 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
 * Some controllers need to toggle the usb3-otg reset before trying to
 * initialize the PHY, otherwise the PHY times out.
 */
-   if (of_device_is_compatible(np, "rockchip,rk3399-dwc3"))
+   if (of_device_is_compatible(np, "rockchip,rk3399-dwc3") ||
+   of_device_is_compatible(np, "hisilicon,hi3660-dwc3"))
simple->need_reset = true;
 
if (of_device_is_compatible(np, "amlogic,meson-axg-dwc3") ||
@@ -243,6 +244,7 @@ static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "amlogic,meson-axg-dwc3" },
{ .compatible = "amlogic,meson-gxl-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
+   { .compatible = "hisilicon,hi3660-dwc3" },
{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
-- 
2.15.0-rc2

[PATCH v3 08/12] usb: roles: Add usb role switch notifier.

[Yu Chen]

This patch adds notifier for drivers want to be informed of the usb role switch.

Cc: Greg Kroah-Hartman 
Cc: Heikki Krogerus 
Cc: Hans de Goede 
Cc: Andy Shevchenko 
Cc: John Stultz 
Suggested-by: Heikki Krogerus 
Signed-off-by: Yu Chen 
---
 drivers/usb/roles/class.c | 20 +++-
 include/linux/usb/role.h  | 46 ++
 2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index f45d8df5cfb8..e2caaa665d6e 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -20,6 +20,7 @@ struct usb_role_switch {
struct device dev;
struct mutex lock; /* device lock*/
enum usb_role role;
+   struct blocking_notifier_head nh;
 
/* From descriptor */
struct device *usb2_port;
@@ -49,8 +50,10 @@ int usb_role_switch_set_role(struct usb_role_switch *sw, 
enum usb_role role)
mutex_lock(>lock);
 
ret = sw->set(sw->dev.parent, role);
-   if (!ret)
+   if (!ret) {
sw->role = role;
+   blocking_notifier_call_chain(>nh, role, NULL);
+   }
 
mutex_unlock(>lock);
 
@@ -58,6 +61,20 @@ int usb_role_switch_set_role(struct usb_role_switch *sw, 
enum usb_role role)
 }
 EXPORT_SYMBOL_GPL(usb_role_switch_set_role);
 
+int usb_role_switch_register_notifier(struct usb_role_switch *sw,
+ struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(>nh, nb);
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_register_notifier);
+
+int usb_role_switch_unregister_notifier(struct usb_role_switch *sw,
+   struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(>nh, nb);
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_unregister_notifier);
+
 /**
  * usb_role_switch_get_role - Get the USB role for a switch
  * @sw: USB role switch
@@ -271,6 +288,7 @@ usb_role_switch_register(struct device *parent,
return ERR_PTR(-ENOMEM);
 
mutex_init(>lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(>nh);
 
sw->allow_userspace_control = desc->allow_userspace_control;
sw->usb2_port = desc->usb2_port;
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index 9684a8734757..9e1ca663387a 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -41,6 +41,8 @@ struct usb_role_switch_desc {
bool allow_userspace_control;
 };
 
+
+#if IS_ENABLED(CONFIG_USB_ROLE_SWITCH)
 int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
 enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
 struct usb_role_switch *usb_role_switch_get(struct device *dev);
@@ -50,5 +52,49 @@ struct usb_role_switch *
 usb_role_switch_register(struct device *parent,
 const struct usb_role_switch_desc *desc);
 void usb_role_switch_unregister(struct usb_role_switch *sw);
+int usb_role_switch_register_notifier(struct usb_role_switch *sw,
+ struct notifier_block *nb);
+int usb_role_switch_unregister_notifier(struct usb_role_switch *sw,
+   struct notifier_block *nb);
+#else
+static inline int usb_role_switch_set_role(struct usb_role_switch *sw,
+   enum usb_role role)
+{
+   return 0;
+}
+
+static inline enum usb_role usb_role_switch_get_role(struct usb_role_switch 
*sw)
+{
+   return USB_ROLE_NONE;
+}
+
+static inline struct usb_role_switch *usb_role_switch_get(struct device *dev)
+{
+   return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
+
+static inline struct usb_role_switch *
+usb_role_switch_register(struct device *parent,
+const struct usb_role_switch_desc *desc)
+{
+   return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_unregister(struct usb_role_switch *sw) { }
+
+static int usb_role_switch_register_notifier(struct usb_role_switch *sw,
+ struct notifier_block *nb)
+{
+   return -ENODEV;
+}
+
+static int usb_role_switch_unregister_notifier(struct usb_role_switch *sw,
+   struct notifier_block *nb)
+{
+   return -ENODEV;
+}
+#endif
 
 #endif /* __LINUX_USB_ROLE_H */
-- 
2.15.0-rc2

[PATCH v3 12/12] dts: hi3660: Add support for usb on Hikey960

[Yu Chen]

This patch adds support for usb on Hikey960.

Cc: Chunfeng Yun 
Cc: Wei Xu 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v2:
* Remove device_type property.
* Add property "usb-role-switch".
v3:
* Make node "usb_phy" a subnode of usb3_otg_bc register.
* Remove property "typec-vbus-enable-val" of hisi_hikey_usb.
---
---
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 53 
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 74 +++
 2 files changed, 127 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index 46435466f1ab..7900ca60092e 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "HiKey960";
@@ -196,6 +197,26 @@
method = "smc";
};
};
+
+   hisi_hikey_usb: hisi_hikey_usb {
+   compatible = "hisilicon,hikey960_usb";
+   typec-vbus-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   otg-switch-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   hub-vdd33-en-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hikey_usb_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch_notify>;
+   };
+   };
+   };
+
 };
 
 /*
@@ -526,6 +547,38 @@
  {
status = "okay";
 
+   rt1711h: rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   status = "ok";
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cfg_func>;
+
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+   data-role = "dual";
+   power-role = "dual";
+   try-power-role = "sink";
+   source-pdos = ;
+   sink-pdos = ;
+   op-sink-microwatt = <1000>;
+   };
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rt1711h_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch>;
+   };
+   };
+   };
+
adv7533: adv7533@39 {
status = "ok";
compatible = "adi,adv7533";
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 20ae40df61d5..bfda59a41570 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -355,6 +355,12 @@
#clock-cells = <1>;
};
 
+   pmctrl: pmctrl@fff31000 {
+   compatible = "hisilicon,hi3660-pmctrl", "syscon";
+   reg = <0x0 0xfff31000 0x0 0x1000>;
+   #clock-cells = <1>;
+   };
+
pmuctrl: crg_ctrl@fff34000 {
compatible = "hisilicon,hi3660-pmuctrl", "syscon";
reg = <0x0 0xfff34000 0x0 0x1000>;
@@ -1134,5 +1140,73 @@
};
};
};
+
+   usb3_otg_bc: usb3_otg_bc@ff20 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0xff20 0x0 0x1000>;
+
+   usb_phy: usb-phy {
+   compatible = "hisilicon,hi3660-usb-phy";
+   #phy-cells = <0>;
+   hisilicon,pericrg-syscon = <_ctrl>;
+   hisilicon,pctrl-syscon = <>;
+   hisilicon,usb3-otg-bc-syscon = <_otg_bc>;
+   hisilicon,eye-diagram-param = <0x22466e4>;
+   };
+   };
+
+   usb3: hisi_dwc3 {
+   

[PATCH v3 11/12] usb: gadget: Add configfs attribuite for controling match_existing_only

[Yu Chen]

Currently the "match_existing_only" of usb_gadget_driver in configfs is
set to one which is not flexible.
Dwc3 udc will be removed when usb core switch to host mode. This causes
failure of writing name of dwc3 udc to configfs's UDC attribuite.
To fix this we need to add a way to change the config of
"match_existing_only".
There are systems like Android do not support udev, so adding
"match_existing_only" attribute to allow configuration by user is cost little.
This patch adds a configfs attribuite for controling match_existing_only
which allow user to config "match_existing_only".

Cc: Andy Shevchenko 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
 drivers/usb/gadget/configfs.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 025129942894..be85104bfab9 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -291,6 +291,36 @@ static ssize_t gadget_dev_desc_UDC_store(struct 
config_item *item,
return ret;
 }
 
+static ssize_t gadget_driver_match_existing_only_store(struct config_item 
*item,
+   const char *page, size_t len)
+{
+   struct gadget_info *gi = to_gadget_info(item);
+   struct usb_gadget_driver *gadget_driver = 
&(gi->composite.gadget_driver);
+   bool match_existing_only;
+   int ret;
+
+   ret = kstrtobool(page, _existing_only);
+   if (ret)
+   return ret;
+
+   if (match_existing_only)
+   gadget_driver->match_existing_only = 1;
+   else
+   gadget_driver->match_existing_only = 0;
+
+   return len;
+}
+
+static ssize_t gadget_driver_match_existing_only_show(struct config_item *item,
+   char *page)
+{
+   struct gadget_info *gi = to_gadget_info(item);
+   struct usb_gadget_driver *gadget_driver = 
&(gi->composite.gadget_driver);
+   bool match_existing_only = !!gadget_driver->match_existing_only;
+
+   return sprintf(page, "%s\n", match_existing_only ? "true" : "false");
+}
+
 CONFIGFS_ATTR(gadget_dev_desc_, bDeviceClass);
 CONFIGFS_ATTR(gadget_dev_desc_, bDeviceSubClass);
 CONFIGFS_ATTR(gadget_dev_desc_, bDeviceProtocol);
@@ -300,6 +330,7 @@ CONFIGFS_ATTR(gadget_dev_desc_, idProduct);
 CONFIGFS_ATTR(gadget_dev_desc_, bcdDevice);
 CONFIGFS_ATTR(gadget_dev_desc_, bcdUSB);
 CONFIGFS_ATTR(gadget_dev_desc_, UDC);
+CONFIGFS_ATTR(gadget_, driver_match_existing_only);
 
 static struct configfs_attribute *gadget_root_attrs[] = {
_dev_desc_attr_bDeviceClass,
@@ -311,6 +342,7 @@ static struct configfs_attribute *gadget_root_attrs[] = {
_dev_desc_attr_bcdDevice,
_dev_desc_attr_bcdUSB,
_dev_desc_attr_UDC,
+   _attr_driver_match_existing_only,
NULL,
 };
 
-- 
2.15.0-rc2

[PATCH v3 06/12] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Yu Chen]

It needs more time for the device controller to clear the CmdAct of
DEPCMD on Hisilicon Kirin Soc.

Cc: Andy Shevchenko 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
 drivers/usb/dwc3/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6c9b76bcc2e1..84d701b37171 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -270,7 +270,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned 
cmd,
 {
const struct usb_endpoint_descriptor *desc = dep->endpoint.desc;
struct dwc3 *dwc = dep->dwc;
-   u32 timeout = 1000;
+   u32 timeout = 5000;
u32 saved_config = 0;
u32 reg;
 
-- 
2.15.0-rc2

[PATCH v3 00/12] Add support for usb on Hikey960

[Yu Chen]

The patchset adds support for usb functionality of Hikey960, includes:
- dwc3 driver for Hisilicon Kirin Soc hi3660
- usb driver for HiKey960 board
- some adjustment in dwc3, usb gadget and typec driver
- dts for support usb of HiKey960

This patchset based on patchset https://lkml.org/lkml/2019/1/25/344
of Heikki Krogerus

Yu Chen (12):
  dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY
  dt-bindings: misc: Add bindings for HiSilicon usb hub and data role
switch functionality on HiKey960
  usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc
Platform
  usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
  usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe for
Hisilicon Kirin Soc
  usb: dwc3: Increase timeout for CmdAct cleared by device controller
  phy: Add usb phy support for hi3660 Soc of Hisilicon
  usb: roles: Add usb role switch notifier.
  usb: dwc3: Registering a role switch in the DRD code.
  hikey960: Support usb functionality of Hikey960
  usb: gadget: Add configfs attribuite for controling
match_existing_only
  dts: hi3660: Add support for usb on Hikey960

 .../bindings/misc/hisilicon-hikey-usb.txt  |  52 +
 .../devicetree/bindings/phy/phy-hi3660-usb3.txt|  28 +++
 MAINTAINERS|   8 +
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts  |  53 +
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi  |  74 +++
 drivers/misc/Kconfig   |   6 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/hisi_hikey_usb.c  | 167 +++
 drivers/phy/hisilicon/Kconfig  |  10 +
 drivers/phy/hisilicon/Makefile |   1 +
 drivers/phy/hisilicon/phy-hi3660-usb3.c| 232 +
 drivers/usb/dwc3/Kconfig   |   1 +
 drivers/usb/dwc3/core.c|  43 
 drivers/usb/dwc3/core.h|  10 +
 drivers/usb/dwc3/drd.c |  58 +-
 drivers/usb/dwc3/dwc3-of-simple.c  |   4 +-
 drivers/usb/dwc3/gadget.c  |   2 +-
 drivers/usb/gadget/configfs.c  |  32 +++
 drivers/usb/roles/class.c  |  20 +-
 include/linux/usb/role.h   |  46 
 20 files changed, 844 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
 create mode 100644 drivers/misc/hisi_hikey_usb.c
 create mode 100644 drivers/phy/hisilicon/phy-hi3660-usb3.c

-- 
2.15.0-rc2

Re: [PATCH][RFC] ACPI: add "processor.broadcast_ppc" hook to broadcast _PPC to all online CPUs

[Yu Chen]

On Thu, Feb 14, 2019 at 11:21:13AM +0100, Rafael J. Wysocki wrote:
>  On Wed, Feb 13, 2019 at 5:44 PM Yu Chen  wrote:
> >
> > Hi Rafael,
> > On Mon, Feb 11, 2019 at 11:41:26AM +0100, Rafael J. Wysocki wrote:
> > > On Sat, Feb 9, 2019 at 12:54 PM Chen Yu  wrote:
> > > >
> > > > On Dell Inc. XPS13 9333, the BIOS changes the value of
> > > > MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when
> > > > the power source changes), the maximum frequency of the
> > > > CPU is not updated accordingly. This is due to the policy's
> > > > cpuinfo.max is not updated when _PPC notifier fires.
> > > >
> > > > Fix this problem by updating the policy's cpuinfo.max
> > > > and broadcast the _PPC notifier to all online CPUs.
> > > >
> > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> > > > Reported-and-tested-by: Gabriele Mazzotta 
> > > > Originally-by: Srinivas Pandruvada 
> > > > Signed-off-by: Chen Yu 
> > > > ---
> > > >  drivers/acpi/processor_perflib.c | 16 ++--
> > > >  drivers/cpufreq/cpufreq.c|  2 ++
> > > >  drivers/cpufreq/intel_pstate.c   | 15 ++-
> > > >  3 files changed, 30 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/processor_perflib.c 
> > > > b/drivers/acpi/processor_perflib.c
> > > > index a303fd0e108c..737dbf5aa7f7 100644
> > > > --- a/drivers/acpi/processor_perflib.c
> > > > +++ b/drivers/acpi/processor_perflib.c
> > > > @@ -63,6 +63,10 @@ module_param(ignore_ppc, int, 0644);
> > > >  MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets 
> > > > wrongly" \
> > > >  "limited by BIOS, this should help");
> > > >
> > > > +static int broadcast_ppc;
> > > > +module_param(broadcast_ppc, int, 0644);
> > > > +MODULE_PARM_DESC(broadcast_ppc, "Broadcast the ppc to all online 
> > > > CPUs");
> > > > +
> > > >  #define PPC_REGISTERED   1
> > > >  #define PPC_IN_USE   2
> > > >
> > > > @@ -180,8 +184,16 @@ void acpi_processor_ppc_has_changed(struct 
> > > > acpi_processor *pr, int event_flag)
> > > > else
> > > > acpi_processor_ppc_ost(pr->handle, 0);
> > > > }
> > > > -   if (ret >= 0)
> > > > -   cpufreq_update_policy(pr->id);
> > > > +   if (ret >= 0) {
> > > > +   if (broadcast_ppc) {
> > > > +   int cpu;
> > > > +
> > > > +   for_each_possible_cpu(cpu)
> > > > +   cpufreq_update_policy(cpu);
> > > > +   } else {
> > > > +   cpufreq_update_policy(pr->id);
> > > > +   }
> > > > +   }
> > > >  }
> > > >
> > > >  int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
> > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > > > index e35a886e00bc..95e08816b512 100644
> > > > --- a/drivers/cpufreq/cpufreq.c
> > > > +++ b/drivers/cpufreq/cpufreq.c
> > > > @@ -2237,6 +2237,8 @@ static int cpufreq_set_policy(struct 
> > > > cpufreq_policy *policy,
> > > >
> > > > policy->min = new_policy->min;
> > > > policy->max = new_policy->max;
> > > > +   policy->cpuinfo.max_freq = new_policy->cpuinfo.max_freq;
> > > > +   policy->cpuinfo.min_freq = new_policy->cpuinfo.min_freq;
> > > > trace_cpu_frequency_limits(policy);
> > > >
> > > > policy->cached_target_freq = UINT_MAX;
> > > > diff --git a/drivers/cpufreq/intel_pstate.c 
> > > > b/drivers/cpufreq/intel_pstate.c
> > > > index dd66decf2087..e1881313c396 100644
> > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > @@ -2081,11 +2081,24 @@ static void 
> > > > intel_pstate_adjust_policy_max(struct cpufreq_policy *policy,
> > > >
> > > >  static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
> > > >  {
> > > > +   int max_freq;
>

Re: [PATCH][RFC] ACPI: add "processor.broadcast_ppc" hook to broadcast _PPC to all online CPUs

[Yu Chen]

On Thu, Feb 14, 2019 at 12:36:48PM +0530, Viresh Kumar wrote:
> On 14-02-19, 00:55, Yu Chen wrote:
> > Hi Viresh,
> > On Mon, Feb 11, 2019 at 04:03:07PM +0530, Viresh Kumar wrote:
> > > On 09-02-19, 20:02, Chen Yu wrote:
> > > > On Dell Inc. XPS13 9333, the BIOS changes the value of
> > > > MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when
> > > > the power source changes), the maximum frequency of the
> > > > CPU is not updated accordingly. This is due to the policy's
> > > > cpuinfo.max is not updated when _PPC notifier fires.
> > > > 
> > > > Fix this problem by updating the policy's cpuinfo.max
> > > > and broadcast the _PPC notifier to all online CPUs.
> > > > 
> > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> > > > Reported-and-tested-by: Gabriele Mazzotta 
> > > > Originally-by: Srinivas Pandruvada 
> > > > Signed-off-by: Chen Yu 
> > > > ---
> > > >  drivers/acpi/processor_perflib.c | 16 ++--
> > > >  drivers/cpufreq/cpufreq.c|  2 ++
> > > >  drivers/cpufreq/intel_pstate.c   | 15 ++-
> > > >  3 files changed, 30 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/acpi/processor_perflib.c 
> > > > b/drivers/acpi/processor_perflib.c
> > > > index a303fd0e108c..737dbf5aa7f7 100644
> > > > --- a/drivers/acpi/processor_perflib.c
> > > > +++ b/drivers/acpi/processor_perflib.c
> > > > @@ -63,6 +63,10 @@ module_param(ignore_ppc, int, 0644);
> > > >  MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets 
> > > > wrongly" \
> > > >  "limited by BIOS, this should help");
> > > >  
> > > > +static int broadcast_ppc;
> > > > +module_param(broadcast_ppc, int, 0644);
> > > > +MODULE_PARM_DESC(broadcast_ppc, "Broadcast the ppc to all online 
> > > > CPUs");
> > > > +
> > > >  #define PPC_REGISTERED   1
> > > >  #define PPC_IN_USE   2
> > > >  
> > > > @@ -180,8 +184,16 @@ void acpi_processor_ppc_has_changed(struct 
> > > > acpi_processor *pr, int event_flag)
> > > > else
> > > > acpi_processor_ppc_ost(pr->handle, 0);
> > > > }
> > > > -   if (ret >= 0)
> > > > -   cpufreq_update_policy(pr->id);
> > > > +   if (ret >= 0) {
> > > > +   if (broadcast_ppc) {
> > > > +   int cpu;
> > > > +
> > > > +   for_each_possible_cpu(cpu)
> > > > +   cpufreq_update_policy(cpu);
> > > > +   } else {
> > > > +   cpufreq_update_policy(pr->id);
> > > > +   }
> > > > +   }
> > > >  }
> > > >  
> > > >  int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
> > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > > > index e35a886e00bc..95e08816b512 100644
> > > > --- a/drivers/cpufreq/cpufreq.c
> > > > +++ b/drivers/cpufreq/cpufreq.c
> > > > @@ -2237,6 +2237,8 @@ static int cpufreq_set_policy(struct 
> > > > cpufreq_policy *policy,
> > > >  
> > > > policy->min = new_policy->min;
> > > > policy->max = new_policy->max;
> > > > +   policy->cpuinfo.max_freq = new_policy->cpuinfo.max_freq;
> > > > +   policy->cpuinfo.min_freq = new_policy->cpuinfo.min_freq;
> > > > trace_cpu_frequency_limits(policy);
> > > >  
> > > > policy->cached_target_freq = UINT_MAX;
> > > > diff --git a/drivers/cpufreq/intel_pstate.c 
> > > > b/drivers/cpufreq/intel_pstate.c
> > > > index dd66decf2087..e1881313c396 100644
> > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > @@ -2081,11 +2081,24 @@ static void 
> > > > intel_pstate_adjust_policy_max(struct cpufreq_policy *policy,
> > > >  
> > > >  static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
> > > >  {
> > > > +   int max_freq;
> > > > struct cpudata *cpu = all_cpu_data[policy->cp

[PATCH v2 05/10] phy: Add usb phy support for hi3660 Soc of Hisilicon

[Yu Chen]

This driver handles usb phy power on and shutdown for hi3660 Soc of
Hisilicon.

Cc: Andy Shevchenko 
Cc: Kishon Vijay Abraham I 
Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Cc: Mauro Carvalho Chehab 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Shawn Guo 
Cc: Pengcheng Li 
Cc: Jianguo Sun 
Cc: Masahiro Yamada 
Cc: Jiancheng Xue 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Remove unused code and add comment for time delay as suggested by
Kishon Vijay Abraham I.
v2:
* Fix license declaration.
* Remove redundant parens.
* Remove unused member variables in struct hi3660_priv.
---
---
 MAINTAINERS |   8 ++
 drivers/phy/hisilicon/Kconfig   |  10 ++
 drivers/phy/hisilicon/Makefile  |   1 +
 drivers/phy/hisilicon/phy-hi3660-usb3.c | 232 
 4 files changed, 251 insertions(+)
 create mode 100644 drivers/phy/hisilicon/phy-hi3660-usb3.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4d04cebb4a71..8dc289faa2c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15790,6 +15790,14 @@ L: linux-...@vger.kernel.org
 S: Maintained
 F: drivers/usb/roles/intel-xhci-usb-role-switch.c
 
+USB IP DRIVER FOR HISILICON KIRIN
+M:     Yu Chen 
+M: Binghui Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
+F: drivers/phy/hisilicon/phy-hi3660-usb3.c
+
 USB ISP116X DRIVER
 M: Olav Kongas 
 L: linux-...@vger.kernel.org
diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
index b40ee54a1a50..3c142f08987c 100644
--- a/drivers/phy/hisilicon/Kconfig
+++ b/drivers/phy/hisilicon/Kconfig
@@ -12,6 +12,16 @@ config PHY_HI6220_USB
 
  To compile this driver as a module, choose M here.
 
+config PHY_HI3660_USB
+   tristate "hi3660 USB PHY support"
+   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the HISILICON HI3660 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
 config PHY_HISTB_COMBPHY
tristate "HiSilicon STB SoCs COMBPHY support"
depends on (ARCH_HISI && ARM64) || COMPILE_TEST
diff --git a/drivers/phy/hisilicon/Makefile b/drivers/phy/hisilicon/Makefile
index f662a4fe18d8..75ba64e2faf8 100644
--- a/drivers/phy/hisilicon/Makefile
+++ b/drivers/phy/hisilicon/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_PHY_HI6220_USB)   += phy-hi6220-usb.o
+obj-$(CONFIG_PHY_HI3660_USB)   += phy-hi3660-usb3.o
 obj-$(CONFIG_PHY_HISTB_COMBPHY)+= phy-histb-combphy.o
 obj-$(CONFIG_PHY_HISI_INNO_USB2)   += phy-hisi-inno-usb2.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
diff --git a/drivers/phy/hisilicon/phy-hi3660-usb3.c 
b/drivers/phy/hisilicon/phy-hi3660-usb3.c
new file mode 100644
index ..97184e6f0d41
--- /dev/null
+++ b/drivers/phy/hisilicon/phy-hi3660-usb3.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Phy provider for USB 3.0 controller on HiSilicon 3660 platform
+ *
+ * Copyright (C) 2017-2018 Hilisicon Electronics Co., Ltd.
+ *     http://www.huawei.com
+ *
+ * Authors: Yu Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PERI_CRG_CLK_EN4   0x40
+#define PERI_CRG_CLK_DIS4  0x44
+#define GT_CLK_USB3OTG_REF BIT(0)
+#define GT_ACLK_USB3OTGBIT(1)
+
+#define PERI_CRG_RSTEN40x90
+#define PERI_CRG_RSTDIS4   0x94
+#define IP_RST_USB3OTGPHY_POR  BIT(3)
+#define IP_RST_USB3OTG BIT(5)
+
+#define PERI_CRG_ISODIS0x148
+#define USB_REFCLK_ISO_EN  BIT(25)
+
+#define PCTRL_PERI_CTRL3   0x10
+#define PCTRL_PERI_CTRL3_MSK_START 16
+#define USB_TCXO_ENBIT(1)
+
+#define PCTRL_PERI_CTRL24  0x64
+#define SC_CLK_USB3PHY_3MUX1_SEL   BIT(25)
+
+#define USBOTG3_CTRL0  0x00
+#define SC_USB3PHY_ABB_GT_EN   BIT(15)
+
+#define USBOTG3_CTRL2  0x08
+#define USBOTG3CTRL2_POWERDOWN_HSP BIT(0)
+#define USBOTG3CTRL2_POWERDOWN_SSP BIT(1)
+
+#define USBOTG3_CTRL3  0x0C
+#define USBOTG3_CTRL3_VBUSVLDEXT   BIT(6)
+#define USBOTG3_CTRL3_VBUSVLDEXTSELBIT(5)
+
+#define USBOTG3_CTRL4  0x10
+
+#define USBOTG3_CTRL7  0x1c
+#define REF_SSP_EN BIT(16)
+
+#define HI3660_USB_DEFAULT_PHY_PARAM   0x1c466e3
+
+struct hi3660_priv {
+   struct device *dev;
+   struct regmap *peri_crg;
+   struct regmap *pctrl;
+   struct

[PATCH v2 06/10] usb: roles: Add usb role switch notifier.

[Yu Chen]

This patch adds notifier for drivers want to be informed of the usb role switch.

Cc: Greg Kroah-Hartman 
Cc: Heikki Krogerus 
Cc: Hans de Goede 
Cc: Andy Shevchenko 
Cc: John Stultz 
Suggested-by: Heikki Krogerus 
Signed-off-by: Yu Chen 
---
 drivers/usb/roles/class.c | 20 +++-
 include/linux/usb/role.h  | 46 ++
 2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index f45d8df5cfb8..e2caaa665d6e 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -20,6 +20,7 @@ struct usb_role_switch {
struct device dev;
struct mutex lock; /* device lock*/
enum usb_role role;
+   struct blocking_notifier_head nh;
 
/* From descriptor */
struct device *usb2_port;
@@ -49,8 +50,10 @@ int usb_role_switch_set_role(struct usb_role_switch *sw, 
enum usb_role role)
mutex_lock(>lock);
 
ret = sw->set(sw->dev.parent, role);
-   if (!ret)
+   if (!ret) {
sw->role = role;
+   blocking_notifier_call_chain(>nh, role, NULL);
+   }
 
mutex_unlock(>lock);
 
@@ -58,6 +61,20 @@ int usb_role_switch_set_role(struct usb_role_switch *sw, 
enum usb_role role)
 }
 EXPORT_SYMBOL_GPL(usb_role_switch_set_role);
 
+int usb_role_switch_register_notifier(struct usb_role_switch *sw,
+ struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(>nh, nb);
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_register_notifier);
+
+int usb_role_switch_unregister_notifier(struct usb_role_switch *sw,
+   struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(>nh, nb);
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_unregister_notifier);
+
 /**
  * usb_role_switch_get_role - Get the USB role for a switch
  * @sw: USB role switch
@@ -271,6 +288,7 @@ usb_role_switch_register(struct device *parent,
return ERR_PTR(-ENOMEM);
 
mutex_init(>lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(>nh);
 
sw->allow_userspace_control = desc->allow_userspace_control;
sw->usb2_port = desc->usb2_port;
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index 9684a8734757..9e1ca663387a 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -41,6 +41,8 @@ struct usb_role_switch_desc {
bool allow_userspace_control;
 };
 
+
+#if IS_ENABLED(CONFIG_USB_ROLE_SWITCH)
 int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
 enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
 struct usb_role_switch *usb_role_switch_get(struct device *dev);
@@ -50,5 +52,49 @@ struct usb_role_switch *
 usb_role_switch_register(struct device *parent,
 const struct usb_role_switch_desc *desc);
 void usb_role_switch_unregister(struct usb_role_switch *sw);
+int usb_role_switch_register_notifier(struct usb_role_switch *sw,
+ struct notifier_block *nb);
+int usb_role_switch_unregister_notifier(struct usb_role_switch *sw,
+   struct notifier_block *nb);
+#else
+static inline int usb_role_switch_set_role(struct usb_role_switch *sw,
+   enum usb_role role)
+{
+   return 0;
+}
+
+static inline enum usb_role usb_role_switch_get_role(struct usb_role_switch 
*sw)
+{
+   return USB_ROLE_NONE;
+}
+
+static inline struct usb_role_switch *usb_role_switch_get(struct device *dev)
+{
+   return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
+
+static inline struct usb_role_switch *
+usb_role_switch_register(struct device *parent,
+const struct usb_role_switch_desc *desc)
+{
+   return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_unregister(struct usb_role_switch *sw) { }
+
+static int usb_role_switch_register_notifier(struct usb_role_switch *sw,
+ struct notifier_block *nb)
+{
+   return -ENODEV;
+}
+
+static int usb_role_switch_unregister_notifier(struct usb_role_switch *sw,
+   struct notifier_block *nb)
+{
+   return -ENODEV;
+}
+#endif
 
 #endif /* __LINUX_USB_ROLE_H */
-- 
2.15.0-rc2

[PATCH v2 08/10] hikey960: Support usb functionality of Hikey960

[Yu Chen]

This driver handles usb hub power on and typeC port event of HiKey960 board:
1)DP switching between usb hub and typeC port base on typeC port
state
2)Control power of usb hub on Hikey960
3)Control vbus of typeC port

Cc: Andy Shevchenko 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Cc: Heikki Krogerus 
Signed-off-by: Yu Chen 

---
v1:
* Using gpiod API with the gpios.
* Removing registering usb role switch.
* Registering usb role switch notifier.
v2:
* Fix license declaration.
* Add configuration of  gpio direction.
* Remove some log print.
---
---
 drivers/misc/Kconfig  |   6 ++
 drivers/misc/Makefile |   1 +
 drivers/misc/hisi_hikey_usb.c | 181 ++
 3 files changed, 188 insertions(+)
 create mode 100644 drivers/misc/hisi_hikey_usb.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f417b06e11c5..8d8b717759e2 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -521,6 +521,12 @@ config PVPANIC
  a paravirtualized device provided by QEMU; it lets a virtual machine
  (guest) communicate panic events to the host.
 
+config HISI_HIKEY_USB
+   tristate "USB functionality of HiSilicon Hikey Platform"
+   depends on OF && GPIOLIB
+   help
+ If you say yes here you get support for usb functionality of 
HiSilicon Hikey Platform.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e39ccbbc1b3a..dc8892b13a1a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_PCI_ENDPOINT_TEST)   += pci_endpoint_test.o
 obj-$(CONFIG_OCXL) += ocxl/
 obj-y  += cardreader/
 obj-$(CONFIG_PVPANIC)  += pvpanic.o
+obj-$(CONFIG_HISI_HIKEY_USB)   += hisi_hikey_usb.o
diff --git a/drivers/misc/hisi_hikey_usb.c b/drivers/misc/hisi_hikey_usb.c
new file mode 100644
index ..70013f8e76f0
--- /dev/null
+++ b/drivers/misc/hisi_hikey_usb.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support for usb functionality of Hikey series boards
+ * based on Hisilicon Kirin Soc.
+ *
+ * Copyright (C) 2017-2018 Hilisicon Electronics Co., Ltd.
+ *     http://www.huawei.com
+ *
+ * Authors: Yu Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVICE_DRIVER_NAME "hisi_hikey_usb"
+
+#define HUB_VBUS_POWER_ON 1
+#define HUB_VBUS_POWER_OFF 0
+#define USB_SWITCH_TO_HUB 1
+#define USB_SWITCH_TO_TYPEC 0
+
+struct hisi_hikey_usb {
+   struct gpio_desc *otg_switch;
+   struct gpio_desc *typec_vbus;
+   struct gpio_desc *hub_vbus;
+   int typec_vbus_enable_val;
+
+   struct usb_role_switch *role_sw;
+   struct notifier_block nb;
+};
+
+static void hub_power_ctrl(struct hisi_hikey_usb *hisi_hikey_usb, int value)
+{
+   gpiod_set_value_cansleep(hisi_hikey_usb->hub_vbus, value);
+}
+
+static void usb_switch_ctrl(struct hisi_hikey_usb *hisi_hikey_usb,
+   int switch_to)
+{
+   gpiod_set_value_cansleep(hisi_hikey_usb->otg_switch, switch_to);
+}
+
+static void usb_typec_power_ctrl(struct hisi_hikey_usb *hisi_hikey_usb,
+   int value)
+{
+   gpiod_set_value_cansleep(hisi_hikey_usb->typec_vbus, value);
+}
+
+static int hisi_hikey_role_switch(struct notifier_block *nb,
+   unsigned long state, void *data)
+{
+   struct hisi_hikey_usb *hisi_hikey_usb;
+
+   hisi_hikey_usb = container_of(nb, struct hisi_hikey_usb, nb);
+
+   switch (state) {
+   case USB_ROLE_NONE:
+   usb_typec_power_ctrl(hisi_hikey_usb,
+   !hisi_hikey_usb->typec_vbus_enable_val);
+   usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_HUB);
+   hub_power_ctrl(hisi_hikey_usb, HUB_VBUS_POWER_ON);
+   break;
+   case USB_ROLE_HOST:
+   usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_TYPEC);
+   usb_typec_power_ctrl(hisi_hikey_usb,
+   hisi_hikey_usb->typec_vbus_enable_val);
+   break;
+   case USB_ROLE_DEVICE:
+   hub_power_ctrl(hisi_hikey_usb, HUB_VBUS_POWER_OFF);
+   usb_typec_power_ctrl(hisi_hikey_usb,
+   !hisi_hikey_usb->typec_vbus_enable_val);
+   usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_TYPEC);
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
+static int hisi_hikey_usb_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *root = dev->of_node;
+   struct hisi_hikey_usb *hisi_hikey_usb;
+   int ret;
+
+   hisi_hikey_usb = devm_kzalloc(dev, sizeof(*hisi_hi

[PATCH v2 09/10] usb: gadget: Add configfs attribuite for controling match_existing_only

[Yu Chen]

Currently the "match_existing_only" of usb_gadget_driver in configfs is
set to one which is not flexible.
Dwc3 udc will be removed when usb core switch to host mode. This causes
failure of writing name of dwc3 udc to configfs's UDC attribuite.
To fix this we need to add a way to change the config of
"match_existing_only".
There are systems like Android do not support udev, so adding
"match_existing_only" attribute to allow configuration by user is cost little.
This patch adds a configfs attribuite for controling match_existing_only
which allow user to config "match_existing_only".

Cc: Andy Shevchenko 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
 drivers/usb/gadget/configfs.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 025129942894..be85104bfab9 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -291,6 +291,36 @@ static ssize_t gadget_dev_desc_UDC_store(struct 
config_item *item,
return ret;
 }
 
+static ssize_t gadget_driver_match_existing_only_store(struct config_item 
*item,
+   const char *page, size_t len)
+{
+   struct gadget_info *gi = to_gadget_info(item);
+   struct usb_gadget_driver *gadget_driver = 
&(gi->composite.gadget_driver);
+   bool match_existing_only;
+   int ret;
+
+   ret = kstrtobool(page, _existing_only);
+   if (ret)
+   return ret;
+
+   if (match_existing_only)
+   gadget_driver->match_existing_only = 1;
+   else
+   gadget_driver->match_existing_only = 0;
+
+   return len;
+}
+
+static ssize_t gadget_driver_match_existing_only_show(struct config_item *item,
+   char *page)
+{
+   struct gadget_info *gi = to_gadget_info(item);
+   struct usb_gadget_driver *gadget_driver = 
&(gi->composite.gadget_driver);
+   bool match_existing_only = !!gadget_driver->match_existing_only;
+
+   return sprintf(page, "%s\n", match_existing_only ? "true" : "false");
+}
+
 CONFIGFS_ATTR(gadget_dev_desc_, bDeviceClass);
 CONFIGFS_ATTR(gadget_dev_desc_, bDeviceSubClass);
 CONFIGFS_ATTR(gadget_dev_desc_, bDeviceProtocol);
@@ -300,6 +330,7 @@ CONFIGFS_ATTR(gadget_dev_desc_, idProduct);
 CONFIGFS_ATTR(gadget_dev_desc_, bcdDevice);
 CONFIGFS_ATTR(gadget_dev_desc_, bcdUSB);
 CONFIGFS_ATTR(gadget_dev_desc_, UDC);
+CONFIGFS_ATTR(gadget_, driver_match_existing_only);
 
 static struct configfs_attribute *gadget_root_attrs[] = {
_dev_desc_attr_bDeviceClass,
@@ -311,6 +342,7 @@ static struct configfs_attribute *gadget_root_attrs[] = {
_dev_desc_attr_bcdDevice,
_dev_desc_attr_bcdUSB,
_dev_desc_attr_UDC,
+   _attr_driver_match_existing_only,
NULL,
 };
 
-- 
2.15.0-rc2

[PATCH v2 03/10] usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc Platform

[Yu Chen]

This patch adds support for the poweron and shutdown of dwc3 core
on Hisilicon Soc Platform.
---
 drivers/usb/dwc3/dwc3-of-simple.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index 4c2771c5e727..0ed09d876542 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -98,7 +98,8 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
 * Some controllers need to toggle the usb3-otg reset before trying to
 * initialize the PHY, otherwise the PHY times out.
 */
-   if (of_device_is_compatible(np, "rockchip,rk3399-dwc3"))
+   if (of_device_is_compatible(np, "rockchip,rk3399-dwc3") ||
+   of_device_is_compatible(np, "hisilicon,hi3660-dwc3"))
simple->need_reset = true;
 
if (of_device_is_compatible(np, "amlogic,meson-axg-dwc3") ||
@@ -243,6 +244,7 @@ static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "amlogic,meson-axg-dwc3" },
{ .compatible = "amlogic,meson-gxl-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
+   { .compatible = "hisilicon,hi3660-dwc3" },
{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
-- 
2.15.0-rc2

[PATCH v2 10/10] dts: hi3660: Add support for usb on Hikey960

[Yu Chen]

This patch adds support for usb on Hikey960.

Cc: Wei Xu 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v2:
* Remove device_type property.
* Add property "usb-role-switch".
---
---
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 54 +
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 73 +++
 2 files changed, 127 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index 46435466f1ab..2cada9d44046 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "HiKey960";
@@ -196,6 +197,27 @@
method = "smc";
};
};
+
+   hisi_hikey_usb: hisi_hikey_usb {
+   compatible = "hisilicon,hikey960_usb";
+   typec-vbus-gpios = < 2 0>;
+   typec-vbus-enable-val = <1>;
+   otg-switch-gpios = < 6 0>;
+   hub-vdd33-en-gpios = < 6 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hikey_usb_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch_notify>;
+   };
+   };
+   };
+
 };
 
 /*
@@ -526,6 +548,38 @@
  {
status = "okay";
 
+   rt1711h: rt1711h@4e {
+   compatible = "richtek,rt1711h";
+   reg = <0x4e>;
+   status = "ok";
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cfg_func>;
+
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+   data-role = "dual";
+   power-role = "dual";
+   try-power-role = "sink";
+   source-pdos = ;
+   sink-pdos = ;
+   op-sink-microwatt = <1000>;
+   };
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rt1711h_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch>;
+   };
+   };
+   };
+
adv7533: adv7533@39 {
status = "ok";
compatible = "adi,adv7533";
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 20ae40df61d5..a2808c53c538 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -355,6 +355,12 @@
#clock-cells = <1>;
};
 
+   pmctrl: pmctrl@fff31000 {
+   compatible = "hisilicon,hi3660-pmctrl", "syscon";
+   reg = <0x0 0xfff31000 0x0 0x1000>;
+   #clock-cells = <1>;
+   };
+
pmuctrl: crg_ctrl@fff34000 {
compatible = "hisilicon,hi3660-pmuctrl", "syscon";
reg = <0x0 0xfff34000 0x0 0x1000>;
@@ -1134,5 +1140,72 @@
};
};
};
+
+   usb3_otg_bc: usb3_otg_bc@ff20 {
+   compatible = "syscon";
+   reg = <0x0 0xff20 0x0 0x1000>;
+   };
+
+   usb_phy: usb-phy {
+   compatible = "hisilicon,hi3660-usb-phy";
+   #phy-cells = <0>;
+   hisilicon,pericrg-syscon = <_ctrl>;
+   hisilicon,pctrl-syscon = <>;
+   hisilicon,usb3-otg-bc-syscon = <_otg_bc>;
+   hisilicon,eye-diagram-param = <0x22466e4>;
+   };
+
+   usb3: hisi_dwc3 {
+   compatible = "hisilicon,hi3660-dwc3";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   clocks = <_ctrl HI3660_CLK_ABB_USB>,
+  

[PATCH v2 07/10] usb: dwc3: Registering a role switch in the DRD code.

[Yu Chen]

The Type-C drivers use USB role switch API to inform the
system about the negotiated data role, so registering a role
switch in the DRD code in order to support platforms with
USB Type-C connectors.

Cc: John Stultz 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Heikki Krogerus 
Suggested-by: Heikki Krogerus 
Signed-off-by: Yu Chen 
---
v2:
* Assign fwnode in dwc3_role_switch.
---
---
 drivers/usb/dwc3/core.h |  2 ++
 drivers/usb/dwc3/drd.c  | 45 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 402b3c29eb26..7385544b9936 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1083,6 +1084,7 @@ struct dwc3 {
struct extcon_dev   *edev;
struct notifier_block   edev_nb;
enum usb_phy_interface  hsphy_mode;
+   struct usb_role_switch  *role_sw;
 
u32 fladj;
u32 irq_gadget;
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 869725d15c74..cf977bb0d62e 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -474,8 +474,42 @@ static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
return edev;
 }
 
+static int dwc3_usb_role_switch_set(struct device *dev, enum usb_role role)
+{
+   u32 mode;
+
+   switch (role) {
+   case USB_ROLE_HOST:
+   mode = DWC3_GCTL_PRTCAP_HOST;
+   break;
+   case USB_ROLE_DEVICE:
+   mode = DWC3_GCTL_PRTCAP_DEVICE;
+   break;
+   default:
+   mode = DWC3_GCTL_PRTCAP_HOST;
+   break;
+   };
+
+   dwc3_set_mode(dev_get_drvdata(dev), mode);
+   return 0;
+}
+
+static enum usb_role dwc3_usb_role_switch_get(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   unsigned long flags;
+   enum usb_role role;
+
+   spin_lock_irqsave(>lock, flags);
+   role = dwc->current_otg_role;
+   spin_unlock_irqrestore(>lock, flags);
+
+   return role;
+}
+
 int dwc3_drd_init(struct dwc3 *dwc)
 {
+   struct usb_role_switch_desc dwc3_role_switch = {0};
int ret, irq;
 
dwc->edev = dwc3_get_extcon(dwc);
@@ -522,6 +556,15 @@ int dwc3_drd_init(struct dwc3 *dwc)
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
}
 
+   dwc3_role_switch.fwnode = dev_fwnode(dwc->dev);
+   dwc3_role_switch.set = dwc3_usb_role_switch_set;
+   dwc3_role_switch.get = dwc3_usb_role_switch_get;
+   dwc->role_sw = usb_role_switch_register(dwc->dev, _role_switch);
+   if (ret) {
+   dwc3_drd_exit(dwc);
+   return PTR_ERR(dwc->role_sw);
+   }
+
return 0;
 }
 
@@ -557,4 +600,6 @@ void dwc3_drd_exit(struct dwc3 *dwc)
 
if (!dwc->edev)
free_irq(dwc->otg_irq, dwc);
+
+   usb_role_switch_unregister(dwc->role_sw);
 }
-- 
2.15.0-rc2

[PATCH v2 04/10] usb: dwc3: Add two quirks for Hisilicon Kirin Soc Platform

[Yu Chen]

There are tow quirks for DesignWare USB3 DRD Core of Hisilicon Kirin Soc.
1)SPLIT_BOUNDARY_DISABLE should be set for Host mode
2)A GCTL soft reset should be executed when switch mode

Cc: Andy Shevchenko 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v2:
* Fix data type of reg from int to u32.
---
---
 drivers/usb/dwc3/core.c   | 43 +++
 drivers/usb/dwc3/core.h   |  7 +++
 drivers/usb/dwc3/gadget.c |  2 +-
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a1b126f90261..017b0527f6ab 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -112,11 +112,25 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
dwc->current_dr_role = mode;
 }
 
+static void dwc3_gctl_core_soft_reset(struct dwc3 *dwc)
+{
+   u32 reg;
+
+   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+   reg |= (DWC3_GCTL_CORESOFTRESET);
+   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+   reg &= ~(DWC3_GCTL_CORESOFTRESET);
+   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+}
+
 static void __dwc3_set_mode(struct work_struct *work)
 {
struct dwc3 *dwc = work_to_dwc(work);
unsigned long flags;
int ret;
+   u32 reg;
 
if (dwc->dr_mode != USB_DR_MODE_OTG)
return;
@@ -156,6 +170,10 @@ static void __dwc3_set_mode(struct work_struct *work)
 
dwc3_set_prtcap(dwc, dwc->desired_dr_role);
 
+   /* Execute a GCTL Core Soft Reset when switch mode */
+   if (dwc->gctl_reset_quirk)
+   dwc3_gctl_core_soft_reset(dwc);
+
spin_unlock_irqrestore(>lock, flags);
 
switch (dwc->desired_dr_role) {
@@ -169,6 +187,11 @@ static void __dwc3_set_mode(struct work_struct *work)
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
phy_calibrate(dwc->usb2_generic_phy);
+   if (dwc->dis_split_quirk) {
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
+   reg |= DWC3_GUCTL3_SPLITDISABLE;
+   dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
+   }
}
break;
case DWC3_GCTL_PRTCAP_DEVICE:
@@ -1306,6 +1329,11 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
 
+   dwc->dis_split_quirk = device_property_read_bool(dev,
+   "snps,dis-split-quirk");
+   dwc->gctl_reset_quirk = device_property_read_bool(dev,
+   "snps,gctl-reset-quirk");
+
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
 
@@ -1825,10 +1853,25 @@ static int dwc3_resume(struct device *dev)
 
return 0;
 }
+
+static void dwc3_complete(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   u32 reg;
+
+   if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST &&
+   dwc->dis_split_quirk) {
+   dev_dbg(dwc->dev, "set DWC3_GUCTL3_SPLITDISABLE\n");
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
+   reg |= DWC3_GUCTL3_SPLITDISABLE;
+   dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
+   }
+}
 #endif /* CONFIG_PM_SLEEP */
 
 static const struct dev_pm_ops dwc3_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+   .complete = dwc3_complete,
SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
dwc3_runtime_idle)
 };
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index df876418cb78..402b3c29eb26 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -136,6 +136,7 @@
 #define DWC3_GEVNTCOUNT(n) (0xc40c + ((n) * 0x10))
 
 #define DWC3_GHWPARAMS80xc600
+#define DWC3_GUCTL30xc60c
 #define DWC3_GFLADJ0xc630
 
 /* Device Registers */
@@ -370,6 +371,9 @@
 /* Global User Control Register 2 */
 #define DWC3_GUCTL2_RST_ACTBITLATERBIT(14)
 
+/* Global User Control Register 3 */
+#define DWC3_GUCTL3_SPLITDISABLE   BIT(14)
+
 /* Device Configuration Register */
 #define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
 #define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
@@ -1210,6 +1214,9 @@ struct dwc3 {
 
unsigneddis_metastability_quirk:1;
 
+   unsigneddis_split_quirk:1;
+   unsignedgctl_reset_quirk:1;
+
  

[PATCH v2 01/10] dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY

[Yu Chen]

This patch adds binding documentation for supporting the hi3660 usb
phy on boards like the HiKey960.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Fix some format error as suggested by Rob.
v2:
* Change hi3660 usb PHY to hi3660 USB PHY
---
---
 .../devicetree/bindings/phy/phy-hi3660-usb3.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt 
b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
new file mode 100644
index ..f9a3d56cfdd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
@@ -0,0 +1,21 @@
+Hisilicon hi3660 USB PHY
+---
+
+Required properties:
+- compatible: should be "hisilicon,hi3660-usb-phy"
+- #phy-cells: must be 0
+- hisilicon,pericrg-syscon: phandle of syscon used to control phy.
+- hisilicon,pctrl-syscon: phandle of syscon used to control phy.
+- hisilicon,usb3-otg-bc-syscon: phandle of syscon used to control phy.
+- hisilicon,eye-diagram-param: parameter set for phy
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+   usb-phy {
+   compatible = "hisilicon,hi3660-usb-phy";
+   #phy-cells = <0>;
+   hisilicon,pericrg-syscon = <_ctrl>;
+   hisilicon,pctrl-syscon = <>;
+   hisilicon,usb3-otg-bc-syscon = <_otg_bc>;
+   hisilicon,eye-diagram-param = <0x22466e4>;
+   };
-- 
2.15.0-rc2

[PATCH v2 00/10] Add support for usb on Hikey960

[Yu Chen]

The patchset adds support for usb functionality of Hikey960, includes:
- dwc3 driver for Hisilicon Kirin Soc hi3660
- usb driver for HiKey960 board
- some adjustment in dwc3, usb gadget and typec driver
- dts for support usb of HiKey960

---
v2:
* This patchset based on patchset https://lkml.org/lkml/2019/1/25/344
of Heikki Krogerus
---

Yu Chen (10):
  dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY
  dt-bindings: misc: Add bindings for HiSilicon usb hub and data role
switch functionality on HiKey960
  usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc
Platform
  usb: dwc3: Add two quirks for Hisilicon Kirin Soc Platform
  phy: Add usb phy support for hi3660 Soc of Hisilicon
  usb: roles: Add usb role switch notifier.
  usb: dwc3: Registering a role switch in the DRD code.
  hikey960: Support usb functionality of Hikey960
  usb: gadget: Add configfs attribuite for controling
match_existing_only
  dts: hi3660: Add support for usb on Hikey960

 .../bindings/misc/hisilicon-hikey-usb.txt  |  35 
 .../devicetree/bindings/phy/phy-hi3660-usb3.txt|  21 ++
 MAINTAINERS|   8 +
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts  |  54 +
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi  |  73 +++
 drivers/misc/Kconfig   |   6 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/hisi_hikey_usb.c  | 181 
 drivers/phy/hisilicon/Kconfig  |  10 +
 drivers/phy/hisilicon/Makefile |   1 +
 drivers/phy/hisilicon/phy-hi3660-usb3.c| 232 +
 drivers/usb/dwc3/core.c|  43 
 drivers/usb/dwc3/core.h|   9 +
 drivers/usb/dwc3/drd.c |  45 
 drivers/usb/dwc3/dwc3-of-simple.c  |   4 +-
 drivers/usb/dwc3/gadget.c  |   2 +-
 drivers/usb/gadget/configfs.c  |  32 +++
 drivers/usb/roles/class.c  |  20 +-
 include/linux/usb/role.h   |  46 
 19 files changed, 820 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
 create mode 100644 drivers/misc/hisi_hikey_usb.c
 create mode 100644 drivers/phy/hisilicon/phy-hi3660-usb3.c

-- 
2.15.0-rc2

[PATCH v2 02/10] dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960

[Yu Chen]

This patch adds binding documentation to support usb hub and usb
data role switch of Hisilicon HiKey960 Board.

Cc: Sergei Shtylyov 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: John Stultz 
Cc: Binghui Wang 
Signed-off-by: Yu Chen 
---
v1:
* Fix some format errors as suggested by Sergei.
* Modify gpio description to use gpiod API.
v2:
* Remove information about Hikey.
* Fix gpio description.
* Remove device_type of endpoint.
---
---
 .../bindings/misc/hisilicon-hikey-usb.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt

diff --git a/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt 
b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt
new file mode 100644
index ..c2b789b515df
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt
@@ -0,0 +1,35 @@
+Support usb hub and usb data role switch of Hisilicon HiKey960 Board.
+
+-
+
+Required properties:
+- compatible: "hisilicon,gpio-hubv1","hisilicon,hikey960-usb"
+- typec-vbus-gpios: gpio to control the vbus of typeC port
+- typec-vbus-enable-val: gpio value that enable the vbus of typeC port
+- otg-switch-gpios: gpio to switch DP & DM between the hub and typeC port
+- hub-vdd33-en-gpios: gpio to enable the power of hub
+- pinctrl-0: pinctrl config
+
+Example
+-
+
+   hisi_hikey_usb: hisi_hikey_usb {
+   compatible = "hisilicon,hikey960-usb";
+   typec-vbus-gpios = < 2 0>;
+   typec-vbus-enable-val = <1>;
+   otg-switch-gpios = < 6 0>;
+   hub-vdd33-en-gpios = < 6 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmx_func>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hikey_usb_ep: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_role_switch_notify>;
+   };
+   };
+
+   };
-- 
2.15.0-rc2

Re: [PATCH][RFC] ACPI: add "processor.broadcast_ppc" hook to broadcast _PPC to all online CPUs

[Yu Chen]

Hi Viresh,
On Mon, Feb 11, 2019 at 04:03:07PM +0530, Viresh Kumar wrote:
> On 09-02-19, 20:02, Chen Yu wrote:
> > On Dell Inc. XPS13 9333, the BIOS changes the value of
> > MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when
> > the power source changes), the maximum frequency of the
> > CPU is not updated accordingly. This is due to the policy's
> > cpuinfo.max is not updated when _PPC notifier fires.
> > 
> > Fix this problem by updating the policy's cpuinfo.max
> > and broadcast the _PPC notifier to all online CPUs.
> > 
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> > Reported-and-tested-by: Gabriele Mazzotta 
> > Originally-by: Srinivas Pandruvada 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/acpi/processor_perflib.c | 16 ++--
> >  drivers/cpufreq/cpufreq.c|  2 ++
> >  drivers/cpufreq/intel_pstate.c   | 15 ++-
> >  3 files changed, 30 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/acpi/processor_perflib.c 
> > b/drivers/acpi/processor_perflib.c
> > index a303fd0e108c..737dbf5aa7f7 100644
> > --- a/drivers/acpi/processor_perflib.c
> > +++ b/drivers/acpi/processor_perflib.c
> > @@ -63,6 +63,10 @@ module_param(ignore_ppc, int, 0644);
> >  MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets 
> > wrongly" \
> >  "limited by BIOS, this should help");
> >  
> > +static int broadcast_ppc;
> > +module_param(broadcast_ppc, int, 0644);
> > +MODULE_PARM_DESC(broadcast_ppc, "Broadcast the ppc to all online CPUs");
> > +
> >  #define PPC_REGISTERED   1
> >  #define PPC_IN_USE   2
> >  
> > @@ -180,8 +184,16 @@ void acpi_processor_ppc_has_changed(struct 
> > acpi_processor *pr, int event_flag)
> > else
> > acpi_processor_ppc_ost(pr->handle, 0);
> > }
> > -   if (ret >= 0)
> > -   cpufreq_update_policy(pr->id);
> > +   if (ret >= 0) {
> > +   if (broadcast_ppc) {
> > +   int cpu;
> > +
> > +   for_each_possible_cpu(cpu)
> > +   cpufreq_update_policy(cpu);
> > +   } else {
> > +   cpufreq_update_policy(pr->id);
> > +   }
> > +   }
> >  }
> >  
> >  int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index e35a886e00bc..95e08816b512 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2237,6 +2237,8 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> > *policy,
> >  
> > policy->min = new_policy->min;
> > policy->max = new_policy->max;
> > +   policy->cpuinfo.max_freq = new_policy->cpuinfo.max_freq;
> > +   policy->cpuinfo.min_freq = new_policy->cpuinfo.min_freq;
> > trace_cpu_frequency_limits(policy);
> >  
> > policy->cached_target_freq = UINT_MAX;
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index dd66decf2087..e1881313c396 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -2081,11 +2081,24 @@ static void intel_pstate_adjust_policy_max(struct 
> > cpufreq_policy *policy,
> >  
> >  static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
> >  {
> > +   int max_freq;
> > struct cpudata *cpu = all_cpu_data[policy->cpu];
> >  
> > update_turbo_state();
> > +   max_freq = intel_pstate_get_max_freq(cpu);
> > +
> > +   if (acpi_ppc && policy->max == policy->cpuinfo.max_freq &&
> 
> Why do have this check for policy->max here ?
>
Thanks for looking at this change, I've replied to another email in detail of
the scenario that, this is due to corner case that if the system boots
with battery and plug the AC after boot up, the cpufreq max limit will not
increase even the turbo has been enabled after the AC plugged.

Best,
Yu

Re: [PATCH][RFC] ACPI: add "processor.broadcast_ppc" hook to broadcast _PPC to all online CPUs

[Yu Chen]

Hi Rafael,
On Mon, Feb 11, 2019 at 11:41:26AM +0100, Rafael J. Wysocki wrote:
> On Sat, Feb 9, 2019 at 12:54 PM Chen Yu  wrote:
> >
> > On Dell Inc. XPS13 9333, the BIOS changes the value of
> > MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when
> > the power source changes), the maximum frequency of the
> > CPU is not updated accordingly. This is due to the policy's
> > cpuinfo.max is not updated when _PPC notifier fires.
> >
> > Fix this problem by updating the policy's cpuinfo.max
> > and broadcast the _PPC notifier to all online CPUs.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> > Reported-and-tested-by: Gabriele Mazzotta 
> > Originally-by: Srinivas Pandruvada 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/acpi/processor_perflib.c | 16 ++--
> >  drivers/cpufreq/cpufreq.c|  2 ++
> >  drivers/cpufreq/intel_pstate.c   | 15 ++-
> >  3 files changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_perflib.c 
> > b/drivers/acpi/processor_perflib.c
> > index a303fd0e108c..737dbf5aa7f7 100644
> > --- a/drivers/acpi/processor_perflib.c
> > +++ b/drivers/acpi/processor_perflib.c
> > @@ -63,6 +63,10 @@ module_param(ignore_ppc, int, 0644);
> >  MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets 
> > wrongly" \
> >  "limited by BIOS, this should help");
> >
> > +static int broadcast_ppc;
> > +module_param(broadcast_ppc, int, 0644);
> > +MODULE_PARM_DESC(broadcast_ppc, "Broadcast the ppc to all online CPUs");
> > +
> >  #define PPC_REGISTERED   1
> >  #define PPC_IN_USE   2
> >
> > @@ -180,8 +184,16 @@ void acpi_processor_ppc_has_changed(struct 
> > acpi_processor *pr, int event_flag)
> > else
> > acpi_processor_ppc_ost(pr->handle, 0);
> > }
> > -   if (ret >= 0)
> > -   cpufreq_update_policy(pr->id);
> > +   if (ret >= 0) {
> > +   if (broadcast_ppc) {
> > +   int cpu;
> > +
> > +   for_each_possible_cpu(cpu)
> > +   cpufreq_update_policy(cpu);
> > +   } else {
> > +   cpufreq_update_policy(pr->id);
> > +   }
> > +   }
> >  }
> >
> >  int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index e35a886e00bc..95e08816b512 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2237,6 +2237,8 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> > *policy,
> >
> > policy->min = new_policy->min;
> > policy->max = new_policy->max;
> > +   policy->cpuinfo.max_freq = new_policy->cpuinfo.max_freq;
> > +   policy->cpuinfo.min_freq = new_policy->cpuinfo.min_freq;
> > trace_cpu_frequency_limits(policy);
> >
> > policy->cached_target_freq = UINT_MAX;
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index dd66decf2087..e1881313c396 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -2081,11 +2081,24 @@ static void intel_pstate_adjust_policy_max(struct 
> > cpufreq_policy *policy,
> >
> >  static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
> >  {
> > +   int max_freq;
> > struct cpudata *cpu = all_cpu_data[policy->cpu];
> >
> > update_turbo_state();
> 
> Well, update_turbo_state() should handle the case at hand already.
> 
> That's what it's for actually: It checks if
> MSR_IA32_MISC_ENABLE_TURBO_DISABLE is set and sets
> global.turbo_disabled is that's the case.
> 
> Why isn't that sufficient?
> 
update_turbo_state() changes the flag of global.turbo_diabled but we
need to also leverage it to adjust the policy.max accordingly. This is why
we add intel_pstate_get_max_freq() to get the updated max freq in
intel_pstate_verify_policy().
> > +   max_freq = intel_pstate_get_max_freq(cpu);
> > +
> > +   if (acpi_ppc && policy->max == policy->cpuinfo.max_freq &&
> > +   max_freq != policy->cpuinfo.max_freq) {
> > +   /*
> > +* System was not running under any constraints, but the
> > +* current max possible frequency is changed. So reset
> > +* policy limits.
> > +*/
> > +   policy->cpuinfo.max_freq = policy->max = max_freq;
> > +   }
> 
> Why does policy->cpuinfo.max_freq need to be updated?
> 
This is my understanding:
There's a corner case that, if the system boots with battery,
the max cpu frequency will not scale up if we plug the AC later.
According to the log provided by Gabriele Mazzotta,  if the system
boot up with battery, then plug the AC after boot up, the max perf ratio
and policy->cpuinfo.max will remain 17 rather than increasing to
30(when AC plugged thus turbo enabled):

[   52.158810] CPU 0: _PPC is 6 - frequency  

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[Yu Chen]

Hi,
On Tue, Dec 11, 2018 at 04:37:54PM +0800, joeyli wrote:
> Hi Yu Chen,
> 
> Thanks for your response!
> 
> On Tue, Dec 11, 2018 at 11:12:21AM +0800, Yu Chen wrote:
> > Hi Joey,
> > On Mon, Dec 10, 2018 at 02:31:53PM +0800, joeyli wrote:
> > > Hi Chen Yu and ACPI experts,
> > > 
> > > On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote:
> > > > According to current implementation of acpi_pad driver,
> > > > it does not make sense to spawn any power saving threads
> > > > on the cpus which are already idle - it might bring
> > > > unnecessary overhead on these idle cpus and causes power
> > > > waste. So verify the condition that if the number of 'busy'
> > > > cpus exceeds the amount of the 'forced idle' cpus is met.
> > > > This is applicable due to round-robin attribute of the
> > > > power saving threads, otherwise ignore the setting/ACPI
> > > > notification.
> > > > 
> > > > Suggested-by: Lenny Szubowicz 
> > > > Suggested-by: Len Brown 
> > > > Cc: "Rafael J. Wysocki" 
> > > > Cc: Lenny Szubowicz 
> > > > Cc: Len Brown 
> > > > Cc: Jacob Pan 
> > > > Cc: Rui Zhang 
> > > > Cc: linux-a...@vger.kernel.org
> > > > Signed-off-by: Chen Yu 
> > > 
> > > Do you have any news for this patch? Why it did not merged by kernel
> > > maineline?
> > > 
> > We are evaluating if this could be integrated into idle injection framework.
> > May I know if there's any requirement/background from SUSE on this?
> > 
> 
> I am also looking at your patch and idle injection framework. Currently I do 
> not
> have good suggestion for your patches yet. But I will try to ready my 
> knowledge when
> you send out new version.
>
Thanks. I mean, does SUSE get report from customers who encountered this issue?
BTW, may I know the status of the encryption hibernation please?(Usin the TPM?)

Best,
Yu(Ryan)
> Thanks a lot!
> Joey Lee 

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[Yu Chen]

Hi Joey,
On Mon, Dec 10, 2018 at 02:31:53PM +0800, joeyli wrote:
> Hi Chen Yu and ACPI experts,
> 
> On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote:
> > According to current implementation of acpi_pad driver,
> > it does not make sense to spawn any power saving threads
> > on the cpus which are already idle - it might bring
> > unnecessary overhead on these idle cpus and causes power
> > waste. So verify the condition that if the number of 'busy'
> > cpus exceeds the amount of the 'forced idle' cpus is met.
> > This is applicable due to round-robin attribute of the
> > power saving threads, otherwise ignore the setting/ACPI
> > notification.
> > 
> > Suggested-by: Lenny Szubowicz 
> > Suggested-by: Len Brown 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Lenny Szubowicz 
> > Cc: Len Brown 
> > Cc: Jacob Pan 
> > Cc: Rui Zhang 
> > Cc: linux-a...@vger.kernel.org
> > Signed-off-by: Chen Yu 
> 
> Do you have any news for this patch? Why it did not merged by kernel
> maineline?
> 
We are evaluating if this could be integrated into idle injection framework.
May I know if there's any requirement/background from SUSE on this?

Best,
Ryan(Yu)
> Thanks a lot!
> Joey Lee
> 
> > ---
> >  drivers/acpi/acpi_pad.c | 52 
> > -
> >  1 file changed, 51 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> > index 552c1f7..515e60e 100644
> > --- a/drivers/acpi/acpi_pad.c
> > +++ b/drivers/acpi/acpi_pad.c
> > @@ -254,12 +254,62 @@ static void set_power_saving_task_num(unsigned int 
> > num)
> > }
> >  }
> >  
> > +/*
> > + * Extra acpi_pad threads should not be created until
> > + * the requested idle count is less than/equals to the
> > + * number of the busy cpus - it does not make sense to
> > + * throttle the idle cpus.
> > + */
> > +#define SAMPLE_INTERVAL_JIF20
> > +
> > +static u64 get_idle_time(int cpu)
> > +{
> > +   u64 idle, idle_usecs = -1ULL;
> > +
> > +   idle_usecs = get_cpu_idle_time_us(cpu, NULL);
> > +
> > +   if (idle_usecs == -1ULL)
> > +   idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
> > +   else
> > +   idle = idle_usecs * NSEC_PER_USEC;
> > +
> > +   return idle;
> > +}
> > +
> > +static bool idle_nr_valid(unsigned int num_cpus)
> > +{
> > +   int busy_nr = 0, i = 0, load_thresh = 100 - idle_pct;
> > +
> > +   if (!num_cpus)
> > +   return true;
> > +
> > +   for_each_online_cpu(i) {
> > +   u64 wall_time, idle_time;
> > +   unsigned int elapsed_delta, idle_delta, load;
> > +
> > +   wall_time = jiffies64_to_nsecs(get_jiffies_64());
> > +   idle_time = get_idle_time(i);
> > +   /* Wait and see... */
> > +   schedule_timeout_uninterruptible(SAMPLE_INTERVAL_JIF);
> > +
> > +   idle_delta = get_idle_time(i) - idle_time;
> > +   elapsed_delta = jiffies64_to_nsecs(get_jiffies_64()) - 
> > wall_time;
> > +   idle_delta = (idle_delta > elapsed_delta) ? elapsed_delta : 
> > idle_delta;
> > +   load = 100 * (elapsed_delta - idle_delta) / elapsed_delta;
> > +   if (load >= load_thresh)
> > +   busy_nr++;
> > +   }
> > +
> > +   return (busy_nr >= num_cpus) ? true : false;
> > +}
> > +
> >  static void acpi_pad_idle_cpus(unsigned int num_cpus)
> >  {
> > get_online_cpus();
> >  
> > num_cpus = min_t(unsigned int, num_cpus, num_online_cpus());
> > -   set_power_saving_task_num(num_cpus);
> > +   if (idle_nr_valid(num_cpus))
> > +   set_power_saving_task_num(num_cpus);
> >  
> > put_online_cpus();
> >  }
> > -- 
> > 2.7.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] btsdio: Do not bind to non-removable BCM43430

[Cho, Yu-Chen]

BCM43430 devices soldered onto the PCB (non-removable)
use an UART connection for bluetooth.
But also advertise btsdio support on their 3th sdio function.

Signed-off-by: Cho, Yu-Chen 
---
 drivers/bluetooth/btsdio.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 20142bc77554..b5c54053cb0f 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -297,9 +297,15 @@ static int btsdio_probe(struct sdio_func *func,
 * uart connection for bluetooth, ignore the BT SDIO interface.
 */
if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
-   func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
-   !mmc_card_is_removable(func->card->host))
-   return -ENODEV;
+   !mmc_card_is_removable(func->card->host)) {
+   switch (func->device) {
+   case SDIO_DEVICE_ID_BROADCOM_43341:
+   case SDIO_DEVICE_ID_BROADCOM_43430:
+   return -ENODEV;
+   default:
+   break;
+   }
+   }
 
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
if (!data)
-- 
2.18.0

[PATCH v2] btsdio: Do not bind to non-removable BCM43430

[Cho, Yu-Chen]

BCM43430 devices soldered onto the PCB (non-removable)
use an UART connection for bluetooth.
But also advertise btsdio support on their 3th sdio function.

Signed-off-by: Cho, Yu-Chen 
---
 drivers/bluetooth/btsdio.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 20142bc77554..b5c54053cb0f 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -297,9 +297,15 @@ static int btsdio_probe(struct sdio_func *func,
 * uart connection for bluetooth, ignore the BT SDIO interface.
 */
if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
-   func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
-   !mmc_card_is_removable(func->card->host))
-   return -ENODEV;
+   !mmc_card_is_removable(func->card->host)) {
+   switch (func->device) {
+   case SDIO_DEVICE_ID_BROADCOM_43341:
+   case SDIO_DEVICE_ID_BROADCOM_43430:
+   return -ENODEV;
+   default:
+   break;
+   }
+   }
 
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
if (!data)
-- 
2.18.0

[PATCH v2] btsdio: Do not bind to non-removable BCM43430

[Cho, Yu-Chen]

BCM43430 devices soldered onto the PCB (non-removable)
use an UART connection for bluetooth.
But also advertise btsdio support on their 3th sdio function.

Signed-off-by: Cho, Yu-Chen 
---
 drivers/bluetooth/btsdio.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 20142bc77554..a0a6d555901c 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -297,9 +297,15 @@ static int btsdio_probe(struct sdio_func *func,
 * uart connection for bluetooth, ignore the BT SDIO interface.
 */
if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
-   func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
-   !mmc_card_is_removable(func->card->host))
-   return -ENODEV;
+   !mmc_card_is_removable(func->card->host)) {
+   switch(func->device) {
+   case SDIO_DEVICE_ID_BROADCOM_43341:
+   case SDIO_DEVICE_ID_BROADCOM_43430:
+   return -ENODEV;
+   default:
+   break;
+   }
+   }
 
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
if (!data)
-- 
2.18.0

[PATCH v2] btsdio: Do not bind to non-removable BCM43430

[Cho, Yu-Chen]

BCM43430 devices soldered onto the PCB (non-removable)
use an UART connection for bluetooth.
But also advertise btsdio support on their 3th sdio function.

Signed-off-by: Cho, Yu-Chen 
---
 drivers/bluetooth/btsdio.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 20142bc77554..a0a6d555901c 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -297,9 +297,15 @@ static int btsdio_probe(struct sdio_func *func,
 * uart connection for bluetooth, ignore the BT SDIO interface.
 */
if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
-   func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
-   !mmc_card_is_removable(func->card->host))
-   return -ENODEV;
+   !mmc_card_is_removable(func->card->host)) {
+   switch(func->device) {
+   case SDIO_DEVICE_ID_BROADCOM_43341:
+   case SDIO_DEVICE_ID_BROADCOM_43430:
+   return -ENODEV;
+   default:
+   break;
+   }
+   }
 
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
if (!data)
-- 
2.18.0

[PATCH] btsdio: Do not bind to non-removable BCM43430

[Cho, Yu-Chen]

BCM43430 devices soldered onto the PCB (non-removable)
use an UART connection for bluetooth.
But also advertise btsdio support on their 3th sdio function.

Signed-off-by: Cho, Yu-Chen 
---
 drivers/bluetooth/btsdio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 20142bc77554..84d23d786ce5 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -297,7 +297,8 @@ static int btsdio_probe(struct sdio_func *func,
 * uart connection for bluetooth, ignore the BT SDIO interface.
 */
if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
-   func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+   (func->device == SDIO_DEVICE_ID_BROADCOM_43341 ||
+   func->device == SDIO_DEVICE_ID_BROADCOM_43430) &&
!mmc_card_is_removable(func->card->host))
return -ENODEV;
 
-- 
2.18.0

[PATCH] btsdio: Do not bind to non-removable BCM43430

[Cho, Yu-Chen]

BCM43430 devices soldered onto the PCB (non-removable)
use an UART connection for bluetooth.
But also advertise btsdio support on their 3th sdio function.

Signed-off-by: Cho, Yu-Chen 
---
 drivers/bluetooth/btsdio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 20142bc77554..84d23d786ce5 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -297,7 +297,8 @@ static int btsdio_probe(struct sdio_func *func,
 * uart connection for bluetooth, ignore the BT SDIO interface.
 */
if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
-   func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+   (func->device == SDIO_DEVICE_ID_BROADCOM_43341 ||
+   func->device == SDIO_DEVICE_ID_BROADCOM_43430) &&
!mmc_card_is_removable(func->card->host))
return -ENODEV;
 
-- 
2.18.0

Re: [PATCH 03/12][RFC v3] x86-32/asm/power: Create stack frames in hibernate_asm_32.S

[Yu Chen]

On Wed, Sep 19, 2018 at 10:41:16AM +0200, Rafael J. Wysocki wrote:
> On Wed, Sep 19, 2018 at 9:31 AM Chen Yu  wrote:
> >
> > From: Zhimin Gu 
> >
> > Backport
> > Commit ef0f3ed5a4ac (x86/asm/power: Create stack frames
> > in hibernate_asm_64.S)
> > and
> > Commit 4ce827b4cc58 (x86/power/64: Fix hibernation return
> > address corruption)
> >
> > And also prepare for relocated code and jump address
> > mapping.
> 
> I don't like the changelog.
> 
> It should explain the technical reasons for making the changes in the
> first place and then mention that analogous changes were made for
> 64-bit before and by which commits.
>
Ok, will change it in next version.

Thanks,
Yu
> Thanks,
> Rafael

Re: [PATCH 03/12][RFC v3] x86-32/asm/power: Create stack frames in hibernate_asm_32.S

[Yu Chen]

On Wed, Sep 19, 2018 at 10:41:16AM +0200, Rafael J. Wysocki wrote:
> On Wed, Sep 19, 2018 at 9:31 AM Chen Yu  wrote:
> >
> > From: Zhimin Gu 
> >
> > Backport
> > Commit ef0f3ed5a4ac (x86/asm/power: Create stack frames
> > in hibernate_asm_64.S)
> > and
> > Commit 4ce827b4cc58 (x86/power/64: Fix hibernation return
> > address corruption)
> >
> > And also prepare for relocated code and jump address
> > mapping.
> 
> I don't like the changelog.
> 
> It should explain the technical reasons for making the changes in the
> first place and then mention that analogous changes were made for
> 64-bit before and by which commits.
>
Ok, will change it in next version.

Thanks,
Yu
> Thanks,
> Rafael

Re: [PATCH 3/4][v2] x86, hibernate: Extract the common code of 64/32 bit system

[Yu Chen]

Hi,
On Fri, Sep 14, 2018 at 11:21:17AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 11, 2018 7:20:46 PM CEST Chen Yu wrote:
> > From: Zhimin Gu 
> > 
> > Reduce the hibernation code duplication between x86-32 and x86-64
> > by extracting the common code into hibernate.c.
> > 
> > No functional change.
> > 
> > +#include "hibernate.c"
> 
> I don't particularly like this.
> 
> Why excatly do you need to include the C file here?
>
OK, I've removed this in a new version.
> Also, the way this change is made makes it quite hard to review, as the
> new code is not exactly the same as the code being removed, so it is
> hard to say whether or not there really are no functional changes
> as claimed.
I've splitted the patch into several sub-patches and reorganized the
code to make it more readable on a new version.
> 
> This is sensitive code, mind you, and really hard to debug if anything goes
> wrong.  Please be super-careful about changing it.
> 
Ok, will test on several platforms and send out the modification.
Best,
Yu
> Thanks,
> Rafael
> 

Re: [PATCH 3/4][v2] x86, hibernate: Extract the common code of 64/32 bit system

[Yu Chen]

Hi,
On Fri, Sep 14, 2018 at 11:21:17AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 11, 2018 7:20:46 PM CEST Chen Yu wrote:
> > From: Zhimin Gu 
> > 
> > Reduce the hibernation code duplication between x86-32 and x86-64
> > by extracting the common code into hibernate.c.
> > 
> > No functional change.
> > 
> > +#include "hibernate.c"
> 
> I don't particularly like this.
> 
> Why excatly do you need to include the C file here?
>
OK, I've removed this in a new version.
> Also, the way this change is made makes it quite hard to review, as the
> new code is not exactly the same as the code being removed, so it is
> hard to say whether or not there really are no functional changes
> as claimed.
I've splitted the patch into several sub-patches and reorganized the
code to make it more readable on a new version.
> 
> This is sensitive code, mind you, and really hard to debug if anything goes
> wrong.  Please be super-careful about changing it.
> 
Ok, will test on several platforms and send out the modification.
Best,
Yu
> Thanks,
> Rafael
> 

Re: [PATCH 2/4][v2] PM / hibernate: Check the success of generating md5 digest before hibernation

[Yu Chen]

Hi Thomas,
On Thu, Sep 13, 2018 at 10:26:39AM +0200, Thomas Gleixner wrote:
> On Wed, 12 Sep 2018, Chen Yu wrote:
> >  static bool hibernation_e820_mismatch(void *buf)
> > @@ -306,6 +307,7 @@ static bool hibernation_e820_mismatch(void *buf)
> >  int arch_hibernation_header_save(void *addr, unsigned int max_size)
> >  {
> > struct restore_data_record *rdr = addr;
> > +   int ret = -EINVAL;
> 
> What's the point of initializing ret?
> 
> > if (max_size < sizeof(struct restore_data_record))
> > return -EOVERFLOW;
> > @@ -333,7 +335,9 @@ int arch_hibernation_header_save(void *addr, unsigned 
> > int max_size)
> >  
> > rdr->magic = RESTORE_MAGIC;
> >  
> > -   hibernation_e820_save(rdr->e820_digest);
> > +   ret = hibernation_e820_save(rdr->e820_digest);
> > +   if (ret)
> > +   return ret;
> >  
> > return 0;
> 
> And what;s the point of ret at all?
> 
>   return hibernation_e820_save();
> 
> is effectivly the same.
> 
ret is useless, will change to 'return hibernation_e820_save()' here.
Thanks,
Yu
> Thanks,
> 
>   tglx

Re: [PATCH 2/4][v2] PM / hibernate: Check the success of generating md5 digest before hibernation

[Yu Chen]

Hi Thomas,
On Thu, Sep 13, 2018 at 10:26:39AM +0200, Thomas Gleixner wrote:
> On Wed, 12 Sep 2018, Chen Yu wrote:
> >  static bool hibernation_e820_mismatch(void *buf)
> > @@ -306,6 +307,7 @@ static bool hibernation_e820_mismatch(void *buf)
> >  int arch_hibernation_header_save(void *addr, unsigned int max_size)
> >  {
> > struct restore_data_record *rdr = addr;
> > +   int ret = -EINVAL;
> 
> What's the point of initializing ret?
> 
> > if (max_size < sizeof(struct restore_data_record))
> > return -EOVERFLOW;
> > @@ -333,7 +335,9 @@ int arch_hibernation_header_save(void *addr, unsigned 
> > int max_size)
> >  
> > rdr->magic = RESTORE_MAGIC;
> >  
> > -   hibernation_e820_save(rdr->e820_digest);
> > +   ret = hibernation_e820_save(rdr->e820_digest);
> > +   if (ret)
> > +   return ret;
> >  
> > return 0;
> 
> And what;s the point of ret at all?
> 
>   return hibernation_e820_save();
> 
> is effectivly the same.
> 
ret is useless, will change to 'return hibernation_e820_save()' here.
Thanks,
Yu
> Thanks,
> 
>   tglx

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[Yu Chen]

On Wed, Sep 12, 2018 at 10:23:33PM +0800, Lee, Chun-Yi wrote:
> This patch adds a snapshot keys handler for using the key retention
> service api to create keys for snapshot image encryption and
> authentication.
> 
> This handler uses TPM trusted key as the snapshot master key, and the
> encryption key and authentication key are derived from the snapshot
> key. The user defined key can also be used as the snapshot master key
> , but user must be aware that the security of user key relies on user
> space.
> 
In case the kernel provides mechanism to generate key from passphase,
the master key could also be generated in kernel space other than TPM.
It seems than snapshot_key_init() is easy to add the interface for that,
right?
> The name of snapshot key is fixed to "swsusp-kmk". User should use
> the keyctl tool to load the key blob to root's user keyring. e.g.
> 
>  # /bin/keyctl add trusted swsusp-kmk "load `cat swsusp-kmk.blob`" @u
> 
> or create a new user key. e.g.
> 
>  # /bin/keyctl add user swsusp-kmk password @u
> 
> Then the disk_kmk sysfs file can be used to trigger the initialization
> of snapshot key:
> 
>  # echo 1 > /sys/power/disk_kmk
> 
> After the initialization be triggered, the secret in the payload of
> swsusp-key will be copied by hibernation and be erased. Then user can
> use keyctl to remove swsusp-kmk key from root's keyring.
> 
> If user does not trigger the initialization by disk_kmk file after
> swsusp-kmk be loaded to kernel. Then the snapshot key will be
> initialled when hibernation be triggered.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Pavel Machek 
> Cc: Chen Yu 
> Cc: Oliver Neukum 
> Cc: Ryan Chen 
> Cc: David Howells 
> Cc: Giovanni Gherdovich 
> Signed-off-by: "Lee, Chun-Yi" 
> ---
>  kernel/power/Kconfig|  14 +++
>  kernel/power/Makefile   |   1 +
>  kernel/power/hibernate.c|  36 +++
>  kernel/power/power.h|  16 +++
>  kernel/power/snapshot_key.c | 237 
> 
>  5 files changed, 304 insertions(+)
>  create mode 100644 kernel/power/snapshot_key.c
> 
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 3a6c2f87699e..7c5c30149dbc 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -76,6 +76,20 @@ config HIBERNATION
>  
> For more information take a look at 
> .
>  
> +config HIBERNATION_ENC_AUTH
> + bool "Hibernation encryption and authentication"
> + depends on HIBERNATION
> + depends on TRUSTED_KEYS
> + select CRYPTO_AES
> + select CRYPTO_HMAC
> + select CRYPTO_SHA512
> + help
> +   This option will encrypt and authenticate the memory snapshot image
> +   of hibernation. It prevents that the snapshot image be arbitrary
> +   modified. User can use TPMs trusted key or user defined key as the
> +   master key of hibernation. The TPM trusted key depends on TPM. The
> +   security of user defined key relies on user space.
> +
>  config ARCH_SAVE_PAGE_KEYS
>   bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index a3f79f0eef36..bddca7b79a28 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_FREEZER)   += process.o
>  obj-$(CONFIG_SUSPEND)+= suspend.o
>  obj-$(CONFIG_PM_TEST_SUSPEND)+= suspend_test.o
>  obj-$(CONFIG_HIBERNATION)+= hibernate.o snapshot.o swap.o user.o
> +obj-$(CONFIG_HIBERNATION_ENC_AUTH)   += snapshot_key.o
>  obj-$(CONFIG_PM_AUTOSLEEP)   += autosleep.o
>  obj-$(CONFIG_PM_WAKELOCKS)   += wakelock.o
>  
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index abef759de7c8..18d13cbf0591 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1034,6 +1034,39 @@ static ssize_t disk_store(struct kobject *kobj, struct 
> kobj_attribute *attr,
>  
>  power_attr(disk);
>  
> +#ifdef CONFIG_HIBERNATION_ENC_AUTH
> +static ssize_t disk_kmk_show(struct kobject *kobj, struct kobj_attribute 
> *attr,
> +  char *buf)
> +{
> + if (snapshot_key_initialized())
> + return sprintf(buf, "initialized\n");
> + else
> + return sprintf(buf, "uninitialized\n");
> +}
> +
> +static ssize_t disk_kmk_store(struct kobject *kobj, struct kobj_attribute 
> *attr,
> +   const char *buf, size_t n)
> +{
Does kmk mean kernel master key? It might looks unclear from first glance,
how about disk_genkey_store()?
> + int error = 0;
> + char *p;
> + int len;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + p = memchr(buf, '\n', n);
> + len = p ? p - buf : n;
> + if (strncmp(buf, "1", len))
> + return -EINVAL;
Why user is not allowed to disable(remove) it by
echo 0 ?
> +
> + error = snapshot_key_init();
> +
> + return error ? error : n;
> +}
> +
> +power_attr(disk_kmk);
> +#endif /* !CONFIG_HIBERNATION_ENC_AUTH */
> +
>  static ssize_t 

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

[Yu Chen]

On Wed, Sep 12, 2018 at 10:23:33PM +0800, Lee, Chun-Yi wrote:
> This patch adds a snapshot keys handler for using the key retention
> service api to create keys for snapshot image encryption and
> authentication.
> 
> This handler uses TPM trusted key as the snapshot master key, and the
> encryption key and authentication key are derived from the snapshot
> key. The user defined key can also be used as the snapshot master key
> , but user must be aware that the security of user key relies on user
> space.
> 
In case the kernel provides mechanism to generate key from passphase,
the master key could also be generated in kernel space other than TPM.
It seems than snapshot_key_init() is easy to add the interface for that,
right?
> The name of snapshot key is fixed to "swsusp-kmk". User should use
> the keyctl tool to load the key blob to root's user keyring. e.g.
> 
>  # /bin/keyctl add trusted swsusp-kmk "load `cat swsusp-kmk.blob`" @u
> 
> or create a new user key. e.g.
> 
>  # /bin/keyctl add user swsusp-kmk password @u
> 
> Then the disk_kmk sysfs file can be used to trigger the initialization
> of snapshot key:
> 
>  # echo 1 > /sys/power/disk_kmk
> 
> After the initialization be triggered, the secret in the payload of
> swsusp-key will be copied by hibernation and be erased. Then user can
> use keyctl to remove swsusp-kmk key from root's keyring.
> 
> If user does not trigger the initialization by disk_kmk file after
> swsusp-kmk be loaded to kernel. Then the snapshot key will be
> initialled when hibernation be triggered.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Pavel Machek 
> Cc: Chen Yu 
> Cc: Oliver Neukum 
> Cc: Ryan Chen 
> Cc: David Howells 
> Cc: Giovanni Gherdovich 
> Signed-off-by: "Lee, Chun-Yi" 
> ---
>  kernel/power/Kconfig|  14 +++
>  kernel/power/Makefile   |   1 +
>  kernel/power/hibernate.c|  36 +++
>  kernel/power/power.h|  16 +++
>  kernel/power/snapshot_key.c | 237 
> 
>  5 files changed, 304 insertions(+)
>  create mode 100644 kernel/power/snapshot_key.c
> 
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 3a6c2f87699e..7c5c30149dbc 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -76,6 +76,20 @@ config HIBERNATION
>  
> For more information take a look at 
> .
>  
> +config HIBERNATION_ENC_AUTH
> + bool "Hibernation encryption and authentication"
> + depends on HIBERNATION
> + depends on TRUSTED_KEYS
> + select CRYPTO_AES
> + select CRYPTO_HMAC
> + select CRYPTO_SHA512
> + help
> +   This option will encrypt and authenticate the memory snapshot image
> +   of hibernation. It prevents that the snapshot image be arbitrary
> +   modified. User can use TPMs trusted key or user defined key as the
> +   master key of hibernation. The TPM trusted key depends on TPM. The
> +   security of user defined key relies on user space.
> +
>  config ARCH_SAVE_PAGE_KEYS
>   bool
>  
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index a3f79f0eef36..bddca7b79a28 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_FREEZER)   += process.o
>  obj-$(CONFIG_SUSPEND)+= suspend.o
>  obj-$(CONFIG_PM_TEST_SUSPEND)+= suspend_test.o
>  obj-$(CONFIG_HIBERNATION)+= hibernate.o snapshot.o swap.o user.o
> +obj-$(CONFIG_HIBERNATION_ENC_AUTH)   += snapshot_key.o
>  obj-$(CONFIG_PM_AUTOSLEEP)   += autosleep.o
>  obj-$(CONFIG_PM_WAKELOCKS)   += wakelock.o
>  
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index abef759de7c8..18d13cbf0591 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1034,6 +1034,39 @@ static ssize_t disk_store(struct kobject *kobj, struct 
> kobj_attribute *attr,
>  
>  power_attr(disk);
>  
> +#ifdef CONFIG_HIBERNATION_ENC_AUTH
> +static ssize_t disk_kmk_show(struct kobject *kobj, struct kobj_attribute 
> *attr,
> +  char *buf)
> +{
> + if (snapshot_key_initialized())
> + return sprintf(buf, "initialized\n");
> + else
> + return sprintf(buf, "uninitialized\n");
> +}
> +
> +static ssize_t disk_kmk_store(struct kobject *kobj, struct kobj_attribute 
> *attr,
> +   const char *buf, size_t n)
> +{
Does kmk mean kernel master key? It might looks unclear from first glance,
how about disk_genkey_store()?
> + int error = 0;
> + char *p;
> + int len;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + p = memchr(buf, '\n', n);
> + len = p ? p - buf : n;
> + if (strncmp(buf, "1", len))
> + return -EINVAL;
Why user is not allowed to disable(remove) it by
echo 0 ?
> +
> + error = snapshot_key_init();
> +
> + return error ? error : n;
> +}
> +
> +power_attr(disk_kmk);
> +#endif /* !CONFIG_HIBERNATION_ENC_AUTH */
> +
>  static ssize_t 

Re: [PATCH][RFC] x86/intel_rdt: Do not display size for non-CAT resource

[Yu Chen]

Hi Reinette,
Thanks for looking at this.
On Tue, Sep 04, 2018 at 03:36:01PM -0700, Reinette Chatre wrote:
> Hi Chen Yu,
> 
> On 9/4/2018 1:24 PM, Reinette Chatre wrote:
> > On 9/4/2018 10:46 AM, Chen Yu wrote:
> >> On a platform with MB resource enabled, a divided-by-zero
> >> exception is triggered when accessing 'size':
> >>
> >> [  151.193447] divide error:  [#1] SMP PTI
> >> [  151.197743] CPU: 93 PID: 1929 Comm: cat Not tainted 
> >> 4.19.0-rc2-debug-rdt+ #25
> >> [  151.205070] Hardware name: Dell Inc. PowerEdge R640/0CRT1G, BIOS 1.3.7 
> >> 02/08/2018
> >> [  151.212783] RIP: 0010:rdtgroup_cbm_to_size+0x7e/0xa0
> >> [  151.237172] RSP: 0018:b3454f90bd88 EFLAGS: 00010246
> >> [  151.242538] RAX: 023c RBX:  RCX: 
> >> 0003
> >> [  151.249878] RDX:  RSI: 0004 RDI: 
> >> 0003
> >> [  151.257213] RBP: 96ff0089e000 R08:  R09: 
> >> 00aa
> >> [  151.264544] R10: b3454f90bd8c R11:  R12: 
> >> b5028910
> >> [  151.271887] R13: b5028910 R14: 0064 R15: 
> >> 96ff0089e000
> >> [  151.279217] FS:  7f95a623a500() GS:97170f9c() 
> >> knlGS:
> >> [  151.287532] CS:  0010 DS:  ES:  CR0: 80050033
> >> [  151.293432] CR2: 7f95a6217000 CR3: 0023f696c003 CR4: 
> >> 007606e0
> >> [  151.300766] DR0:  DR1:  DR2: 
> >> 
> >> [  151.308094] DR3:  DR6: fffe0ff0 DR7: 
> >> 0400
> >> [  151.315426] PKRU: 5554
> >> [  151.318212] Call Trace:
> >> [  151.320732]  rdtgroup_size_show+0x11a/0x1d0
> >> [  151.325039]  seq_read+0xd8/0x3b0
> >> [  151.328363]  __vfs_read+0x36/0x170
> >> [  151.331857]  vfs_read+0x89/0x130
> >> [  151.335179]  ksys_read+0x52/0xc0
> >> [  151.338500]  do_syscall_64+0x5b/0x180
> >> [  151.342261]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>
> >> This is because for MB resource, the r->cache.cbm_len is zero, thus
> >> calculating size in rdtgroup_cbm_to_size() will trigger the exception.
> >>
> >> Fix this issue by not exposing 'size' for non-CAT resources.
> >>
> >> Fixes: d9b48c86eb38 ("x86/intel_rdt: Display resource groups'
> >> allocations in bytes")
> >> Cc: Reinette Chatre 
> >> Cc: Fenghua Yu 
> >> Cc: Tony Luck 
> >> Cc: Thomas Gleixner 
> >> Signed-off-by: Chen Yu 
> >> ---
> >>  arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
> >> b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> >> index b799c00bef09..53fd07b2f61a 100644
> >> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> >> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> >> @@ -1329,7 +1329,7 @@ static struct rftype res_common_files[] = {
> >>.mode   = 0444,
> >>.kf_ops = _kf_single_ops,
> >>.seq_show   = rdtgroup_size_show,
> >> -  .fflags = RF_CTRL_BASE,
> >> +  .fflags = RF_CTRL_INFO | RFTYPE_RES_CACHE,
> >>},
> >>  
> >>  };
> >>
> > 
> > Thank you very much for catching this.
> > 
> > I think we need to change the fix a bit because from that I can tell the
> > above would cause the "size" file to be relocated to the system wide
> > "info" directory 
Okay. Just curious, if changing like this, will it be moved to 
resctrl/info/L3/size or
resctrl/info/size?
>> while we would like to have this file remain associated
> > with the resource group - but just not apply to a MB resource.
> > 
> > A similar fix may also be needed for the resource group's "mode" file
> > that was also recently introduced.
> > 
> > I am taking a closer look now.
> 
> The "size" file is intended to be associated with a resource group and
> to list the size in bytes of the cache allocations. It does not
> currently accommodate the memory bandwidth allocations as you
> discovered. A system may have multiple resources to be managed via RDT,
> it could include cache as well as memory, and to thus not expose the
> "size" file if memory bandwidth allocation is supported is not ideal
> since the user would not be able to see this information for the cache
> resources.
> 
> So, instead of not exposing the "size" file when memory bandwidth
> allocation is in use I think that we could just include the memory
> bandwidth allocation information in the existing file. This would be in
> the currently active bandwidth granularity that would essentially
> duplicate the schemata information.
> 
I might understand incorrectly, but in this way, the size in resctrl top
dir will display all the domain ranges within all the resources, say, the
size for MB, L3 will be displayed in one file, right? Will the 'size' be
displayed under each resource dir in info dir?
> While looking further at how the new files (size and mode) will behave
> when a MBA resource is 

Re: [PATCH][RFC] x86/intel_rdt: Do not display size for non-CAT resource

[Yu Chen]

Hi Reinette,
Thanks for looking at this.
On Tue, Sep 04, 2018 at 03:36:01PM -0700, Reinette Chatre wrote:
> Hi Chen Yu,
> 
> On 9/4/2018 1:24 PM, Reinette Chatre wrote:
> > On 9/4/2018 10:46 AM, Chen Yu wrote:
> >> On a platform with MB resource enabled, a divided-by-zero
> >> exception is triggered when accessing 'size':
> >>
> >> [  151.193447] divide error:  [#1] SMP PTI
> >> [  151.197743] CPU: 93 PID: 1929 Comm: cat Not tainted 
> >> 4.19.0-rc2-debug-rdt+ #25
> >> [  151.205070] Hardware name: Dell Inc. PowerEdge R640/0CRT1G, BIOS 1.3.7 
> >> 02/08/2018
> >> [  151.212783] RIP: 0010:rdtgroup_cbm_to_size+0x7e/0xa0
> >> [  151.237172] RSP: 0018:b3454f90bd88 EFLAGS: 00010246
> >> [  151.242538] RAX: 023c RBX:  RCX: 
> >> 0003
> >> [  151.249878] RDX:  RSI: 0004 RDI: 
> >> 0003
> >> [  151.257213] RBP: 96ff0089e000 R08:  R09: 
> >> 00aa
> >> [  151.264544] R10: b3454f90bd8c R11:  R12: 
> >> b5028910
> >> [  151.271887] R13: b5028910 R14: 0064 R15: 
> >> 96ff0089e000
> >> [  151.279217] FS:  7f95a623a500() GS:97170f9c() 
> >> knlGS:
> >> [  151.287532] CS:  0010 DS:  ES:  CR0: 80050033
> >> [  151.293432] CR2: 7f95a6217000 CR3: 0023f696c003 CR4: 
> >> 007606e0
> >> [  151.300766] DR0:  DR1:  DR2: 
> >> 
> >> [  151.308094] DR3:  DR6: fffe0ff0 DR7: 
> >> 0400
> >> [  151.315426] PKRU: 5554
> >> [  151.318212] Call Trace:
> >> [  151.320732]  rdtgroup_size_show+0x11a/0x1d0
> >> [  151.325039]  seq_read+0xd8/0x3b0
> >> [  151.328363]  __vfs_read+0x36/0x170
> >> [  151.331857]  vfs_read+0x89/0x130
> >> [  151.335179]  ksys_read+0x52/0xc0
> >> [  151.338500]  do_syscall_64+0x5b/0x180
> >> [  151.342261]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>
> >> This is because for MB resource, the r->cache.cbm_len is zero, thus
> >> calculating size in rdtgroup_cbm_to_size() will trigger the exception.
> >>
> >> Fix this issue by not exposing 'size' for non-CAT resources.
> >>
> >> Fixes: d9b48c86eb38 ("x86/intel_rdt: Display resource groups'
> >> allocations in bytes")
> >> Cc: Reinette Chatre 
> >> Cc: Fenghua Yu 
> >> Cc: Tony Luck 
> >> Cc: Thomas Gleixner 
> >> Signed-off-by: Chen Yu 
> >> ---
> >>  arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
> >> b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> >> index b799c00bef09..53fd07b2f61a 100644
> >> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> >> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> >> @@ -1329,7 +1329,7 @@ static struct rftype res_common_files[] = {
> >>.mode   = 0444,
> >>.kf_ops = _kf_single_ops,
> >>.seq_show   = rdtgroup_size_show,
> >> -  .fflags = RF_CTRL_BASE,
> >> +  .fflags = RF_CTRL_INFO | RFTYPE_RES_CACHE,
> >>},
> >>  
> >>  };
> >>
> > 
> > Thank you very much for catching this.
> > 
> > I think we need to change the fix a bit because from that I can tell the
> > above would cause the "size" file to be relocated to the system wide
> > "info" directory 
Okay. Just curious, if changing like this, will it be moved to 
resctrl/info/L3/size or
resctrl/info/size?
>> while we would like to have this file remain associated
> > with the resource group - but just not apply to a MB resource.
> > 
> > A similar fix may also be needed for the resource group's "mode" file
> > that was also recently introduced.
> > 
> > I am taking a closer look now.
> 
> The "size" file is intended to be associated with a resource group and
> to list the size in bytes of the cache allocations. It does not
> currently accommodate the memory bandwidth allocations as you
> discovered. A system may have multiple resources to be managed via RDT,
> it could include cache as well as memory, and to thus not expose the
> "size" file if memory bandwidth allocation is supported is not ideal
> since the user would not be able to see this information for the cache
> resources.
> 
> So, instead of not exposing the "size" file when memory bandwidth
> allocation is in use I think that we could just include the memory
> bandwidth allocation information in the existing file. This would be in
> the currently active bandwidth granularity that would essentially
> duplicate the schemata information.
> 
I might understand incorrectly, but in this way, the size in resctrl top
dir will display all the domain ranges within all the resources, say, the
size for MB, L3 will be displayed in one file, right? Will the 'size' be
displayed under each resource dir in info dir?
> While looking further at how the new files (size and mode) will behave
> when a MBA resource is 

Re: [PATCH 2/3] x86, hibernate: Extract the common code of 64/32 bit system

[Yu Chen]

On Thu, Aug 30, 2018 at 02:59:09PM +0200, Thomas Gleixner wrote:
> On Mon, 27 Aug 2018, Gu Zhimin wrote:
> > diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> > new file mode 100644
> > index 000..6f91f7b
> > --- /dev/null
> > +++ b/arch/x86/power/hibernate.c
> > @@ -0,0 +1,255 @@
> > +/*
> > + * Hibernation support for x86
> > + *
> > + * Distribute under GPLv2
> 
> We have SPDX identifiers for that and not some randomly chosen license
> hint.
>
> > +
> > +/*
> > + * pfn_is_nosave - check if given pfn is in the 'nosave' section
> 
> This is a half baken kernel doc header. 
> 
> > + */
> > +
> 
> Random new line.
> 
> > +int pfn_is_nosave(unsigned long pfn)
> > +{
> > +   unsigned long nosave_begin_pfn = __pa_symbol(&__nosave_begin) >> 
> > PAGE_SHIFT;
> > +   unsigned long nosave_end_pfn = PAGE_ALIGN(__pa_symbol(&__nosave_end)) 
> > >> PAGE_SHIFT;
> 
> Instead of blindly copying stuff please fix it so it matches kernel coding
> rules.
> 
> > +   return (pfn >= nosave_begin_pfn) && (pfn < nosave_end_pfn);
> 
> The brackets are pointless
> 
> > +}
> > +
> > +#ifdef CONFIG_X86_64
> > +static int relocate_restore_code(void)
> > +{
> > +   pgd_t *pgd;
> > +   p4d_t *p4d;
> > +   pud_t *pud;
> > +   pmd_t *pmd;
> > +   pte_t *pte;
> > +
> > +   relocated_restore_code = get_safe_page(GFP_ATOMIC);
> > +   if (!relocated_restore_code)
> > +   return -ENOMEM;
> > +
> > +   memcpy((void *)relocated_restore_code, core_restore_code, PAGE_SIZE);
> > +
> > +   /* Make the page containing the relocated code executable */
> > +   pgd = (pgd_t *)__va(read_cr3_pa()) +
> > +   pgd_index(relocated_restore_code);
> > +   p4d = p4d_offset(pgd, relocated_restore_code);
> > +   if (p4d_large(*p4d)) {
> > +   set_p4d(p4d, __p4d(p4d_val(*p4d) & ~_PAGE_NX));
> > +   goto out;
> > +   }
> > +   pud = pud_offset(p4d, relocated_restore_code);
> > +   if (pud_large(*pud)) {
> > +   set_pud(pud, __pud(pud_val(*pud) & ~_PAGE_NX));
> > +   goto out;
> > +   }
> > +   pmd = pmd_offset(pud, relocated_restore_code);
> > +   if (pmd_large(*pmd)) {
> > +   set_pmd(pmd, __pmd(pmd_val(*pmd) & ~_PAGE_NX));
> > +   goto out;
> > +   }
> > +   pte = pte_offset_kernel(pmd, relocated_restore_code);
> > +   set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_NX));
> > +out:
> > +   __flush_tlb_all();
> > +   return 0;
> > +}
> > +
> > +#define MD5_DIGEST_SIZE 16
> > +
> > +struct restore_data_record {
> > +   unsigned long jump_address;
> > +   unsigned long jump_address_phys;
> > +   unsigned long cr3;
> > +   unsigned long magic;
> > +   u8 e820_digest[MD5_DIGEST_SIZE];
> > +};
> > +
> > +#if IS_BUILTIN(CONFIG_CRYPTO_MD5)
> > +/**
> > + * get_e820_md5 - calculate md5 according to given e820 table
> > + *
> > + * @table: the e820 table to be calculated
> > + * @buf: the md5 result to be stored to
> > + */
> > +static int get_e820_md5(struct e820_table *table, void *buf)
> > +{
> > +   struct crypto_shash *tfm;
> > +   struct shash_desc *desc;
> > +   int size;
> > +   int ret = 0;
> > +
> > +   tfm = crypto_alloc_shash("md5", 0, 0);
> > +   if (IS_ERR(tfm))
> > +   return -ENOMEM;
> > +
> > +   desc = kmalloc(sizeof(struct shash_desc) + crypto_shash_descsize(tfm),
> > +  GFP_KERNEL);
> > +   if (!desc) {
> > +   ret = -ENOMEM;
> > +   goto free_tfm;
> > +   }
> > +
> > +   desc->tfm = tfm;
> > +   desc->flags = 0;
> > +
> > +   size = offsetof(struct e820_table, entries) +
> > +   sizeof(struct e820_entry) * table->nr_entries;
> > +
> > +   if (crypto_shash_digest(desc, (u8 *)table, size, buf))
> > +   ret = -EINVAL;
> > +
> > +   kzfree(desc);
> > +
> > +free_tfm:
> > +   crypto_free_shash(tfm);
> > +   return ret;
> > +}
> > +
> > +static void hibernation_e820_save(void *buf)
> > +{
> > +   get_e820_md5(e820_table_firmware, buf);
> 
> So if get_e820_md5() fails, then it will hibernate nevertheless. Why is
> that error code not propagated?
>
Thomas, thanks for reviewing this, we will fix them one by one.
Best,
Yu

> Thanks,
> 
>   tglx

Re: [PATCH 2/3] x86, hibernate: Extract the common code of 64/32 bit system

[Yu Chen]

On Thu, Aug 30, 2018 at 02:59:09PM +0200, Thomas Gleixner wrote:
> On Mon, 27 Aug 2018, Gu Zhimin wrote:
> > diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> > new file mode 100644
> > index 000..6f91f7b
> > --- /dev/null
> > +++ b/arch/x86/power/hibernate.c
> > @@ -0,0 +1,255 @@
> > +/*
> > + * Hibernation support for x86
> > + *
> > + * Distribute under GPLv2
> 
> We have SPDX identifiers for that and not some randomly chosen license
> hint.
>
> > +
> > +/*
> > + * pfn_is_nosave - check if given pfn is in the 'nosave' section
> 
> This is a half baken kernel doc header. 
> 
> > + */
> > +
> 
> Random new line.
> 
> > +int pfn_is_nosave(unsigned long pfn)
> > +{
> > +   unsigned long nosave_begin_pfn = __pa_symbol(&__nosave_begin) >> 
> > PAGE_SHIFT;
> > +   unsigned long nosave_end_pfn = PAGE_ALIGN(__pa_symbol(&__nosave_end)) 
> > >> PAGE_SHIFT;
> 
> Instead of blindly copying stuff please fix it so it matches kernel coding
> rules.
> 
> > +   return (pfn >= nosave_begin_pfn) && (pfn < nosave_end_pfn);
> 
> The brackets are pointless
> 
> > +}
> > +
> > +#ifdef CONFIG_X86_64
> > +static int relocate_restore_code(void)
> > +{
> > +   pgd_t *pgd;
> > +   p4d_t *p4d;
> > +   pud_t *pud;
> > +   pmd_t *pmd;
> > +   pte_t *pte;
> > +
> > +   relocated_restore_code = get_safe_page(GFP_ATOMIC);
> > +   if (!relocated_restore_code)
> > +   return -ENOMEM;
> > +
> > +   memcpy((void *)relocated_restore_code, core_restore_code, PAGE_SIZE);
> > +
> > +   /* Make the page containing the relocated code executable */
> > +   pgd = (pgd_t *)__va(read_cr3_pa()) +
> > +   pgd_index(relocated_restore_code);
> > +   p4d = p4d_offset(pgd, relocated_restore_code);
> > +   if (p4d_large(*p4d)) {
> > +   set_p4d(p4d, __p4d(p4d_val(*p4d) & ~_PAGE_NX));
> > +   goto out;
> > +   }
> > +   pud = pud_offset(p4d, relocated_restore_code);
> > +   if (pud_large(*pud)) {
> > +   set_pud(pud, __pud(pud_val(*pud) & ~_PAGE_NX));
> > +   goto out;
> > +   }
> > +   pmd = pmd_offset(pud, relocated_restore_code);
> > +   if (pmd_large(*pmd)) {
> > +   set_pmd(pmd, __pmd(pmd_val(*pmd) & ~_PAGE_NX));
> > +   goto out;
> > +   }
> > +   pte = pte_offset_kernel(pmd, relocated_restore_code);
> > +   set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_NX));
> > +out:
> > +   __flush_tlb_all();
> > +   return 0;
> > +}
> > +
> > +#define MD5_DIGEST_SIZE 16
> > +
> > +struct restore_data_record {
> > +   unsigned long jump_address;
> > +   unsigned long jump_address_phys;
> > +   unsigned long cr3;
> > +   unsigned long magic;
> > +   u8 e820_digest[MD5_DIGEST_SIZE];
> > +};
> > +
> > +#if IS_BUILTIN(CONFIG_CRYPTO_MD5)
> > +/**
> > + * get_e820_md5 - calculate md5 according to given e820 table
> > + *
> > + * @table: the e820 table to be calculated
> > + * @buf: the md5 result to be stored to
> > + */
> > +static int get_e820_md5(struct e820_table *table, void *buf)
> > +{
> > +   struct crypto_shash *tfm;
> > +   struct shash_desc *desc;
> > +   int size;
> > +   int ret = 0;
> > +
> > +   tfm = crypto_alloc_shash("md5", 0, 0);
> > +   if (IS_ERR(tfm))
> > +   return -ENOMEM;
> > +
> > +   desc = kmalloc(sizeof(struct shash_desc) + crypto_shash_descsize(tfm),
> > +  GFP_KERNEL);
> > +   if (!desc) {
> > +   ret = -ENOMEM;
> > +   goto free_tfm;
> > +   }
> > +
> > +   desc->tfm = tfm;
> > +   desc->flags = 0;
> > +
> > +   size = offsetof(struct e820_table, entries) +
> > +   sizeof(struct e820_entry) * table->nr_entries;
> > +
> > +   if (crypto_shash_digest(desc, (u8 *)table, size, buf))
> > +   ret = -EINVAL;
> > +
> > +   kzfree(desc);
> > +
> > +free_tfm:
> > +   crypto_free_shash(tfm);
> > +   return ret;
> > +}
> > +
> > +static void hibernation_e820_save(void *buf)
> > +{
> > +   get_e820_md5(e820_table_firmware, buf);
> 
> So if get_e820_md5() fails, then it will hibernate nevertheless. Why is
> that error code not propagated?
>
Thomas, thanks for reviewing this, we will fix them one by one.
Best,
Yu

> Thanks,
> 
>   tglx

Re: [PATCH 1/3] x86, hibernate: Fix nosave_regions setup for hibernation

[Yu Chen]

Hi,
On Thu, Aug 30, 2018 at 02:45:26PM +0200, Thomas Gleixner wrote:
> On Mon, 27 Aug 2018, Gu Zhimin wrote:
> > 
> > Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
> > This issue should also exist on 64bits systems, if there are reserved
> > regions above 4GB.
> 
> Should? Can we please have facts and not some half baken assumptions? 
> 
> On 64bit max_low_pfn is the same as max_pfn. See init_mem_mapping().
>
Thanks for pointing this out, we've overlooked the reassignment of max_low_pfn,
but just take a glance within setup_arch().
Best,
Yu

> Thanks,
> 
>   tglx

Re: [PATCH 1/3] x86, hibernate: Fix nosave_regions setup for hibernation

[Yu Chen]

Hi,
On Thu, Aug 30, 2018 at 02:45:26PM +0200, Thomas Gleixner wrote:
> On Mon, 27 Aug 2018, Gu Zhimin wrote:
> > 
> > Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
> > This issue should also exist on 64bits systems, if there are reserved
> > regions above 4GB.
> 
> Should? Can we please have facts and not some half baken assumptions? 
> 
> On 64bit max_low_pfn is the same as max_pfn. See init_mem_mapping().
>
Thanks for pointing this out, we've overlooked the reassignment of max_low_pfn,
but just take a glance within setup_arch().
Best,
Yu

> Thanks,
> 
>   tglx

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

[Yu Chen]

Hi Pavel, Joey, Oliver
Please let me describe the original requirement and my
understanding about hibernation encryption here, thus
help us sync on the same thread:
On Wed, Aug 08, 2018 at 07:50:36PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > User space doesn't need to involve. The EFI root key is generated by
> > > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot 
> > > > > service
> > > > > variable that it can only be accessed by trusted EFI binary when
> > > > > secure boot is enabled.
> > > > >
> > > > Okay, this apply to the 'suspend' phase, right?
> > > > I'm still a little confused about the 'resume' phase.
> > > > Taking encryption as example(not signature),
> > > > the purpose of doing hibernation encryption is to prevent other users
> > > > from stealing ram content. Say, user A uses a  passphrase to generate 
> > > > the
> > > 
> > > No, I don't think that's purpose here.
> > > 
> > > Purpose here is to prevent user from reading/modifying kernel memory
> > > content on machine he owns.
> > >
> > Say, A puts his laptop into hibernation and walks away,
> > and B walks by, and opens A's laptop and wakes up the system and he
> > can do what he wants. Although EFI key/TPM trusted key is enabled,
> > currently there's no certification during resume, which sounds
> > unsafe to me. Afterall, the original requirement is to probe
> 
> Define unsafe.
> 
> If you want security against bad people resuming your machines, please
Yes, this is one of the requirements.
> take a look at existing uswsusp solutions. It defends against that.
>
> If you want security against bad people tampering with your machines
> physically, sorry, there's no way to defend against that.
No, this is not the requirement.
> 
> But I thought you were trying to do something for secure boot, and "bad
> person resumes your machine" is out of scope there.
> 
Not exactly, secure boot is one solution to meet the requirement.
> So please always explain security against _what kind of attack_ you
> are trying to improve; intelligent communication is not possible
> without that.
> 
User requirement:
A is the user, B is the attacker, user A launches a STD and
encrypts A's ram data, then writes these encrypted data onto
the disk,  so that: Even if user B has access to the disk,
B could not know the content of A. Which implies:
1. If B unplugs the disk from A's machine, and plugs the disk onto
   another machine, B could not decode the content without A's
   'permission'.
2. If B is using the same machine as A, even A has walked away leaving
   the system suspend, B could not resume to A's context without
   A's 'permission'.

Previously, there are three proposal for this:
a. Enhance the uswsusp(Pavel)
b. Using user provided password to generate the key, for encryption(Yu)
c. Using security boot(TPM or EFI key) for encryption(Joey)

Since I was proposing solution b, I'll say a little more about it.
The original idea was that, the user provides a password, then this
password is used to generate the key, which means, if user B has provided
an incorrect password, the kernel will fail to decrypt the data and is
likely to fail the resume process. That is to say, no matter
which physical machine B is using, only if he has provided the
password, he would be able to resume. In the first version, the key
deviration was firstly done in kernel space, which satisfies the
requirement and both saftey. Unfortunately it was rejected and
people would like to see the key generated in user space instead.
However, using user provided key directly is not safe, according
to the discussion in the thread. I don't have good idea on
how to improve this, but only have some workarounds, say, ask the
kernel to use TPM key to protects the user provided 'key', etc.


Then let's talk a little more about secure boot. According
to my understanding, the situation secure boot tries to deal
with is a little different from the user case we raised above -
It is an enhancement for case 1, because it refuses to resume
once the machine is changed. And it does not cover case 2. But
if it is a requirement from the user, that's ok.

uswsusp is to do all the staff in user space, and other two
aim to do all the staff in kernel space. I'm not arguing
which one is better, but I'm not sure how often user is using
it, as we don't get uswsusp related bug report on kernel
bugzilla (both internally)recent years. Another point is,
why the compression is in kernel rather than in uswsusp,
it looks like the same case as encryption here.


Best,
Yu

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

[Yu Chen]

Hi Pavel, Joey, Oliver
Please let me describe the original requirement and my
understanding about hibernation encryption here, thus
help us sync on the same thread:
On Wed, Aug 08, 2018 at 07:50:36PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > User space doesn't need to involve. The EFI root key is generated by
> > > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot 
> > > > > service
> > > > > variable that it can only be accessed by trusted EFI binary when
> > > > > secure boot is enabled.
> > > > >
> > > > Okay, this apply to the 'suspend' phase, right?
> > > > I'm still a little confused about the 'resume' phase.
> > > > Taking encryption as example(not signature),
> > > > the purpose of doing hibernation encryption is to prevent other users
> > > > from stealing ram content. Say, user A uses a  passphrase to generate 
> > > > the
> > > 
> > > No, I don't think that's purpose here.
> > > 
> > > Purpose here is to prevent user from reading/modifying kernel memory
> > > content on machine he owns.
> > >
> > Say, A puts his laptop into hibernation and walks away,
> > and B walks by, and opens A's laptop and wakes up the system and he
> > can do what he wants. Although EFI key/TPM trusted key is enabled,
> > currently there's no certification during resume, which sounds
> > unsafe to me. Afterall, the original requirement is to probe
> 
> Define unsafe.
> 
> If you want security against bad people resuming your machines, please
Yes, this is one of the requirements.
> take a look at existing uswsusp solutions. It defends against that.
>
> If you want security against bad people tampering with your machines
> physically, sorry, there's no way to defend against that.
No, this is not the requirement.
> 
> But I thought you were trying to do something for secure boot, and "bad
> person resumes your machine" is out of scope there.
> 
Not exactly, secure boot is one solution to meet the requirement.
> So please always explain security against _what kind of attack_ you
> are trying to improve; intelligent communication is not possible
> without that.
> 
User requirement:
A is the user, B is the attacker, user A launches a STD and
encrypts A's ram data, then writes these encrypted data onto
the disk,  so that: Even if user B has access to the disk,
B could not know the content of A. Which implies:
1. If B unplugs the disk from A's machine, and plugs the disk onto
   another machine, B could not decode the content without A's
   'permission'.
2. If B is using the same machine as A, even A has walked away leaving
   the system suspend, B could not resume to A's context without
   A's 'permission'.

Previously, there are three proposal for this:
a. Enhance the uswsusp(Pavel)
b. Using user provided password to generate the key, for encryption(Yu)
c. Using security boot(TPM or EFI key) for encryption(Joey)

Since I was proposing solution b, I'll say a little more about it.
The original idea was that, the user provides a password, then this
password is used to generate the key, which means, if user B has provided
an incorrect password, the kernel will fail to decrypt the data and is
likely to fail the resume process. That is to say, no matter
which physical machine B is using, only if he has provided the
password, he would be able to resume. In the first version, the key
deviration was firstly done in kernel space, which satisfies the
requirement and both saftey. Unfortunately it was rejected and
people would like to see the key generated in user space instead.
However, using user provided key directly is not safe, according
to the discussion in the thread. I don't have good idea on
how to improve this, but only have some workarounds, say, ask the
kernel to use TPM key to protects the user provided 'key', etc.


Then let's talk a little more about secure boot. According
to my understanding, the situation secure boot tries to deal
with is a little different from the user case we raised above -
It is an enhancement for case 1, because it refuses to resume
once the machine is changed. And it does not cover case 2. But
if it is a requirement from the user, that's ok.

uswsusp is to do all the staff in user space, and other two
aim to do all the staff in kernel space. I'm not arguing
which one is better, but I'm not sure how often user is using
it, as we don't get uswsusp related bug report on kernel
bugzilla (both internally)recent years. Another point is,
why the compression is in kernel rather than in uswsusp,
it looks like the same case as encryption here.


Best,
Yu

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

[Yu Chen]

On Thu, Jul 19, 2018 at 01:01:49PM +0200, Pavel Machek wrote:
> On Thu 2018-07-19 07:58:51, Yu Chen wrote:
> > Hi,
> > On Wed, Jul 18, 2018 at 10:22:35PM +0200, Pavel Machek wrote:
> > > On Thu 2018-07-19 00:38:06, Chen Yu wrote:
> > > > As security becomes more and more important, we add the in-kernel
> > > > encryption support for hibernation.
> > > 
> > > Sorry, this does not really explain what security benefit it is
> > > supposed have to against what attack scenarios.
> > > 
> > > Which unfortunately means it can not reviewed.
> > > 
> > > Note that uswsusp already provides encryption. If this is supposed to
> > > have advantages over it, please say so.
> > > 
> > The advantages are described in detail in 
> > [PATCH 1/4]'s log, please refer to that.
> 
> Are you refering to this?
>
Not this one. I've sent v2 of this patch set which
explain more on this:
https://patchwork.kernel.org/patch/10532935/
Let me paste the log here:

1. (This is not to compare with uswsusp but other
tools) One advantage is: Users do not have to
encrypt the whole swap partition as other tools.

2. Ideally kernel memory should be encrypted by the
   kernel itself. We have uswsusp to support user
   space hibernation, however doing the encryption
   in kernel space has more advantages:
   2.1 Not having to transfer plain text kernel memory to
   user space. Per Lee, Chun-Yi, uswsusp is disabled
   when the kernel is locked down:
   https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
   linux-fs.git/commit/?h=lockdown-20180410&
   id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
   due to:
   "There have some functions be locked-down because
   there have no appropriate mechanisms to check the
   integrity of writing data."
   https://patchwork.kernel.org/patch/10476751/
 
   2.2 Not having to copy each page to user space
   one by one not in parallel, which might introduce
   significant amount of copy_to_user() and it might
   not be efficient on servers having large amount of DRAM.
   2.3 Distribution has requirement to do snapshot
   signature for verification, which can be built
   by leveraging this patch set.
   2.4 The encryption is in the kernel, so it doesn't
   have to worry too much about bugs in user space
   utilities and similar, for example.
> # Generally the advantage is: Users do not have to
> # encrypt the whole swap partition as other tools.
> # After all, ideally kernel memory should be encrypted
> # by the kernel itself.
> 
> Sorry, this does not really explain what security benefit it is
> supposed have to against what attack scenarios.
> 
> Note that uswsusp already provides encryption. If this is supposed to
> have advantages over it, please say so.
> 
> Also note that joeyli  has patch series which encrypts
> both in-kernel and uswsusp hibernation methods. His motivation is
> secure boot. How does this compare to his work?
>
Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature
feature can be based on this patch set.

Thanks,
Yu

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

[Yu Chen]

On Thu, Jul 19, 2018 at 01:01:49PM +0200, Pavel Machek wrote:
> On Thu 2018-07-19 07:58:51, Yu Chen wrote:
> > Hi,
> > On Wed, Jul 18, 2018 at 10:22:35PM +0200, Pavel Machek wrote:
> > > On Thu 2018-07-19 00:38:06, Chen Yu wrote:
> > > > As security becomes more and more important, we add the in-kernel
> > > > encryption support for hibernation.
> > > 
> > > Sorry, this does not really explain what security benefit it is
> > > supposed have to against what attack scenarios.
> > > 
> > > Which unfortunately means it can not reviewed.
> > > 
> > > Note that uswsusp already provides encryption. If this is supposed to
> > > have advantages over it, please say so.
> > > 
> > The advantages are described in detail in 
> > [PATCH 1/4]'s log, please refer to that.
> 
> Are you refering to this?
>
Not this one. I've sent v2 of this patch set which
explain more on this:
https://patchwork.kernel.org/patch/10532935/
Let me paste the log here:

1. (This is not to compare with uswsusp but other
tools) One advantage is: Users do not have to
encrypt the whole swap partition as other tools.

2. Ideally kernel memory should be encrypted by the
   kernel itself. We have uswsusp to support user
   space hibernation, however doing the encryption
   in kernel space has more advantages:
   2.1 Not having to transfer plain text kernel memory to
   user space. Per Lee, Chun-Yi, uswsusp is disabled
   when the kernel is locked down:
   https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
   linux-fs.git/commit/?h=lockdown-20180410&
   id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
   due to:
   "There have some functions be locked-down because
   there have no appropriate mechanisms to check the
   integrity of writing data."
   https://patchwork.kernel.org/patch/10476751/
 
   2.2 Not having to copy each page to user space
   one by one not in parallel, which might introduce
   significant amount of copy_to_user() and it might
   not be efficient on servers having large amount of DRAM.
   2.3 Distribution has requirement to do snapshot
   signature for verification, which can be built
   by leveraging this patch set.
   2.4 The encryption is in the kernel, so it doesn't
   have to worry too much about bugs in user space
   utilities and similar, for example.
> # Generally the advantage is: Users do not have to
> # encrypt the whole swap partition as other tools.
> # After all, ideally kernel memory should be encrypted
> # by the kernel itself.
> 
> Sorry, this does not really explain what security benefit it is
> supposed have to against what attack scenarios.
> 
> Note that uswsusp already provides encryption. If this is supposed to
> have advantages over it, please say so.
> 
> Also note that joeyli  has patch series which encrypts
> both in-kernel and uswsusp hibernation methods. His motivation is
> secure boot. How does this compare to his work?
>
Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature
feature can be based on this patch set.

Thanks,
Yu

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

On Wed, Jul 18, 2018 at 11:48:19PM +0800, joeyli wrote:
> On Fri, Jul 13, 2018 at 03:34:25PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> > > Hi Yu Chen, 
> > > 
> > > Sorry for my delay...
> > > 
> > > On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> [...snip]
> > > > > Why the cryption code must be indepent of snapshot code?
> > > > >
> > > > Modules can be easier to be maintained and customized/improved in the 
> > > > future IMO..
> > > 
> > > hm... currently I didn't see apparent benefit on this...
> > > 
> > > About modularization, is it possible to separate the key handler code
> > > from crypto_hibernation.c? Otherwise the snapshot signature needs
> > > to depend on encrypt function.
> > > 
> > I understand.
> > It seems that we can reuse crypto_data() for the signature logic.
> > For example, add one parameter for crypto_data(..., crypto_mode)
> > the crypto_mode is a combination of 
> > ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
> > and can be controled by sysfs. If SIGNATURE_START is enabled, the 
> > crypto_data()
> > invokes crypto_shash_update() to get "hmac(sha512)" hash, and if 
> > SIGNATURE_END
> > is enabled, crypto_shash_final() stores the final result in global buffer
> 
> I agree that the swsusp_prepare and hmac-hash codes can be extract to
> crypto_hibernation.  
> 
> > struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
> > passed to the restore kernel, the same as the salt. Besides,
> 
> The salt is stored in the swsusp_header and put in swap. What I want
> is that the signature of snapshot should be keep in the snapshot header
> as my original design in patch. The benefit is that the snapshot with
> signature can be stored to any place but not just swap. The user space
> can take snapshot image with signature to anywhere.
>
Okay, got it.
> > the swsusp_prepare_hash() in your code could be moved into
> > init_crypto_helper(), thus the signature key could also reuse
> > the same key passed from user space or via get_efi_secret_key().
> > In this way, the change in snapshot.c is minimal and the crypto
> > facilities could be maintained in one file.
> 
> I agree. But as I mentioned in that mail, the key handler codes
> in hibernation_crypto() should be extract to another C file to avoid
> the logic is mixed with the crypto code. The benefit is that we can
> add more key sources like encrypted key or EFI key in the future. 
> 
Ok, will extract the key handler code from this file.
> > > > > > 2. There's no need to traverse the snapshot image twice, if the
> > > > > >image is large(there's requirement on servers now) we can
> > > > > >simplyly do the encryption before the disk IO, and this is
> > > > > >why PATCH[2/3] looks like this.
> > > > > 
> > > > > If the encryption solution is only for block device, then the uswsusp
> > > > > interface must be locked-down when kernel is in locked mode:
> > > > > 
> > > > > uswsusp: Disable when the kernel is locked down
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > > > > 
> > > > > I still suggest to keep the solution to direct encript the snapshot
> > > > > image for uswsusp because the snapshot can be encrypted by kernel
> > > > > before user space get it.
> > > > > 
> > > > > I mean that if the uswsusp be used, then kernel direct encrypts the
> > > > > snapshot image, otherwise kernel encrypts pages before block io.
> > > > > 
> > > > I did not quite get the point, if the kernel has been locked down,
> > > > then the uswsusp is disabled, why the kernel encrypts the snapshot
> > > > for uswsusp?
> > > 
> > > There have some functions be locked-down because there have no
> > > appropriate mechanisms to check the integrity of writing data. If
> > > the snapshot image can be encrypted and authentication, then the
> > > uswsusp interface is avaiable for userspace. We do not need to lock
> > > it down.
> > Ok, I got your point. To be honest, I like your implementation to treat
> > the snapshot data seperately except that it might cause small overhead
> > when traversing large number of snapshot and make snapshot logic a little
> > coupling with crypto logic. Let me send our v2 using the 
> > crypto-before-blockio
> > for review and maybe change to your solution using the encapsulated APIs in
> > crypto_hibernate.c.
> 
> Because sometimes I stick on other topics...
> 
> If you are urgent for pushing your encryption solution. Please do not
> consider too much on signature check. Just complete your patches and push
> to kernel mainline. I will follow your result to respin my signature work.
> 
Thanks, I've just sent out another version before I noticed your
comment yesterday, let me address your concern in v3,
but please feel free to comment on v2.
Thanks,
Yu

> Thanks
> Joey Lee 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

On Wed, Jul 18, 2018 at 11:48:19PM +0800, joeyli wrote:
> On Fri, Jul 13, 2018 at 03:34:25PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> > > Hi Yu Chen, 
> > > 
> > > Sorry for my delay...
> > > 
> > > On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> [...snip]
> > > > > Why the cryption code must be indepent of snapshot code?
> > > > >
> > > > Modules can be easier to be maintained and customized/improved in the 
> > > > future IMO..
> > > 
> > > hm... currently I didn't see apparent benefit on this...
> > > 
> > > About modularization, is it possible to separate the key handler code
> > > from crypto_hibernation.c? Otherwise the snapshot signature needs
> > > to depend on encrypt function.
> > > 
> > I understand.
> > It seems that we can reuse crypto_data() for the signature logic.
> > For example, add one parameter for crypto_data(..., crypto_mode)
> > the crypto_mode is a combination of 
> > ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
> > and can be controled by sysfs. If SIGNATURE_START is enabled, the 
> > crypto_data()
> > invokes crypto_shash_update() to get "hmac(sha512)" hash, and if 
> > SIGNATURE_END
> > is enabled, crypto_shash_final() stores the final result in global buffer
> 
> I agree that the swsusp_prepare and hmac-hash codes can be extract to
> crypto_hibernation.  
> 
> > struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
> > passed to the restore kernel, the same as the salt. Besides,
> 
> The salt is stored in the swsusp_header and put in swap. What I want
> is that the signature of snapshot should be keep in the snapshot header
> as my original design in patch. The benefit is that the snapshot with
> signature can be stored to any place but not just swap. The user space
> can take snapshot image with signature to anywhere.
>
Okay, got it.
> > the swsusp_prepare_hash() in your code could be moved into
> > init_crypto_helper(), thus the signature key could also reuse
> > the same key passed from user space or via get_efi_secret_key().
> > In this way, the change in snapshot.c is minimal and the crypto
> > facilities could be maintained in one file.
> 
> I agree. But as I mentioned in that mail, the key handler codes
> in hibernation_crypto() should be extract to another C file to avoid
> the logic is mixed with the crypto code. The benefit is that we can
> add more key sources like encrypted key or EFI key in the future. 
> 
Ok, will extract the key handler code from this file.
> > > > > > 2. There's no need to traverse the snapshot image twice, if the
> > > > > >image is large(there's requirement on servers now) we can
> > > > > >simplyly do the encryption before the disk IO, and this is
> > > > > >why PATCH[2/3] looks like this.
> > > > > 
> > > > > If the encryption solution is only for block device, then the uswsusp
> > > > > interface must be locked-down when kernel is in locked mode:
> > > > > 
> > > > > uswsusp: Disable when the kernel is locked down
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > > > > 
> > > > > I still suggest to keep the solution to direct encript the snapshot
> > > > > image for uswsusp because the snapshot can be encrypted by kernel
> > > > > before user space get it.
> > > > > 
> > > > > I mean that if the uswsusp be used, then kernel direct encrypts the
> > > > > snapshot image, otherwise kernel encrypts pages before block io.
> > > > > 
> > > > I did not quite get the point, if the kernel has been locked down,
> > > > then the uswsusp is disabled, why the kernel encrypts the snapshot
> > > > for uswsusp?
> > > 
> > > There have some functions be locked-down because there have no
> > > appropriate mechanisms to check the integrity of writing data. If
> > > the snapshot image can be encrypted and authentication, then the
> > > uswsusp interface is avaiable for userspace. We do not need to lock
> > > it down.
> > Ok, I got your point. To be honest, I like your implementation to treat
> > the snapshot data seperately except that it might cause small overhead
> > when traversing large number of snapshot and make snapshot logic a little
> > coupling with crypto logic. Let me send our v2 using the 
> > crypto-before-blockio
> > for review and maybe change to your solution using the encapsulated APIs in
> > crypto_hibernate.c.
> 
> Because sometimes I stick on other topics...
> 
> If you are urgent for pushing your encryption solution. Please do not
> consider too much on signature check. Just complete your patches and push
> to kernel mainline. I will follow your result to respin my signature work.
> 
Thanks, I've just sent out another version before I noticed your
comment yesterday, let me address your concern in v3,
but please feel free to comment on v2.
Thanks,
Yu

> Thanks
> Joey Lee 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi,
On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> Hi Yu Chen, 
> 
> Sorry for my delay...
> 
> On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> > Hi Joey Lee,
> > On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote:
> > > On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> > > > Hi,
> > > > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > > > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > > > > Hi,
> > > > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > > > > Hi Chen Yu,
> > > > > > > 
> > > > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > > > > Use the helper functions introduced previously to encrypt
> > > > > > > > the page data before they are submitted to the block device.
> > > > > > > > Besides, for the case of hibernation compression, the data
> > > > > > > > are firstly compressed and then encrypted, and vice versa
> > > > > > > > for the resume process.
> > > > > > > >
> > > > > > > 
> > > > > > > I want to suggest my solution that it direct signs/encrypts the
> > > > > > > memory snapshot image. This solution is already shipped with
> > > > > > > SLE12 a couple of years:
> > > > > > > 
> > > > > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > > > > 
> > > > > > I did not see image page encryption in above link, if I understand
> > > > > 
> > > > > PM / hibernate: Generate and verify signature for snapshot image
> > > > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> > > > >
> > > > > PM / hibernate: snapshot image encryption
> > > > > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> > > > >
> > > > > The above patches sign and encrypt the data pages in snapshot image.
> > > > > It puts the signature to header.
> > > > >
> > > > It looks like your signature code can be simplyly added on top of the
> > > > solution we proposed here, how about we collaborating on this task?
> > > 
> > > OK, I will base on your user key solution to respin my signature patches.
> > >  
> > > > just my 2 cents, 
> > > > 1. The cryption code should be indepent of the snapshot code, and
> > > >this is why we implement it as a kernel module for that in 
> > > > PATCH[1/3].
> > > 
> > > Why the cryption code must be indepent of snapshot code?
> > >
> > Modules can be easier to be maintained and customized/improved in the 
> > future IMO..
> 
> hm... currently I didn't see apparent benefit on this...
> 
> About modularization, is it possible to separate the key handler code
> from crypto_hibernation.c? Otherwise the snapshot signature needs
> to depend on encrypt function.
> 
I understand.
It seems that we can reuse crypto_data() for the signature logic.
For example, add one parameter for crypto_data(..., crypto_mode)
the crypto_mode is a combination of 
ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
and can be controled by sysfs. If SIGNATURE_START is enabled, the crypto_data()
invokes crypto_shash_update() to get "hmac(sha512)" hash, and if SIGNATURE_END
is enabled, crypto_shash_final() stores the final result in global buffer
struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
passed to the restore kernel, the same as the salt. Besides,
the swsusp_prepare_hash() in your code could be moved into
init_crypto_helper(), thus the signature key could also reuse
the same key passed from user space or via get_efi_secret_key().
In this way, the change in snapshot.c is minimal and the crypto
facilities could be maintained in one file.
> > > > 2. There's no need to traverse the snapshot image twice, if the
> > > >image is large(there's requirement on servers now) we can
> > > >simplyly do the encryption before the disk IO, and this is
> > > >why PATCH[2/3] looks like this.
> > > 
> > > If the encryption solution is only for block device, then the uswsusp
> > > interface must be locked-down when kernel is in locked mode:
> > > 
> > > uswsusp: Disable when the kernel is

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi,
On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote:
> Hi Yu Chen, 
> 
> Sorry for my delay...
> 
> On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote:
> > Hi Joey Lee,
> > On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote:
> > > On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> > > > Hi,
> > > > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > > > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > > > > Hi,
> > > > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > > > > Hi Chen Yu,
> > > > > > > 
> > > > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > > > > Use the helper functions introduced previously to encrypt
> > > > > > > > the page data before they are submitted to the block device.
> > > > > > > > Besides, for the case of hibernation compression, the data
> > > > > > > > are firstly compressed and then encrypted, and vice versa
> > > > > > > > for the resume process.
> > > > > > > >
> > > > > > > 
> > > > > > > I want to suggest my solution that it direct signs/encrypts the
> > > > > > > memory snapshot image. This solution is already shipped with
> > > > > > > SLE12 a couple of years:
> > > > > > > 
> > > > > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > > > > 
> > > > > > I did not see image page encryption in above link, if I understand
> > > > > 
> > > > > PM / hibernate: Generate and verify signature for snapshot image
> > > > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> > > > >
> > > > > PM / hibernate: snapshot image encryption
> > > > > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> > > > >
> > > > > The above patches sign and encrypt the data pages in snapshot image.
> > > > > It puts the signature to header.
> > > > >
> > > > It looks like your signature code can be simplyly added on top of the
> > > > solution we proposed here, how about we collaborating on this task?
> > > 
> > > OK, I will base on your user key solution to respin my signature patches.
> > >  
> > > > just my 2 cents, 
> > > > 1. The cryption code should be indepent of the snapshot code, and
> > > >this is why we implement it as a kernel module for that in 
> > > > PATCH[1/3].
> > > 
> > > Why the cryption code must be indepent of snapshot code?
> > >
> > Modules can be easier to be maintained and customized/improved in the 
> > future IMO..
> 
> hm... currently I didn't see apparent benefit on this...
> 
> About modularization, is it possible to separate the key handler code
> from crypto_hibernation.c? Otherwise the snapshot signature needs
> to depend on encrypt function.
> 
I understand.
It seems that we can reuse crypto_data() for the signature logic.
For example, add one parameter for crypto_data(..., crypto_mode)
the crypto_mode is a combination of 
ENCRYPT/DECRYPT/SIGNATURE_START/SIGNATURE_END,
and can be controled by sysfs. If SIGNATURE_START is enabled, the crypto_data()
invokes crypto_shash_update() to get "hmac(sha512)" hash, and if SIGNATURE_END
is enabled, crypto_shash_final() stores the final result in global buffer
struct hibernation_crypto.keys.digest[SNAPSHOT_DIGEST_SIZE] which can be
passed to the restore kernel, the same as the salt. Besides,
the swsusp_prepare_hash() in your code could be moved into
init_crypto_helper(), thus the signature key could also reuse
the same key passed from user space or via get_efi_secret_key().
In this way, the change in snapshot.c is minimal and the crypto
facilities could be maintained in one file.
> > > > 2. There's no need to traverse the snapshot image twice, if the
> > > >image is large(there's requirement on servers now) we can
> > > >simplyly do the encryption before the disk IO, and this is
> > > >why PATCH[2/3] looks like this.
> > > 
> > > If the encryption solution is only for block device, then the uswsusp
> > > interface must be locked-down when kernel is in locked mode:
> > > 
> > > uswsusp: Disable when the kernel is

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi Joey Lee,
On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote:
> On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > > Hi,
> > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > > Hi Chen Yu,
> > > > > 
> > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > > Use the helper functions introduced previously to encrypt
> > > > > > the page data before they are submitted to the block device.
> > > > > > Besides, for the case of hibernation compression, the data
> > > > > > are firstly compressed and then encrypted, and vice versa
> > > > > > for the resume process.
> > > > > >
> > > > > 
> > > > > I want to suggest my solution that it direct signs/encrypts the
> > > > > memory snapshot image. This solution is already shipped with
> > > > > SLE12 a couple of years:
> > > > > 
> > > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > > 
> > > > I did not see image page encryption in above link, if I understand
> > > 
> > > PM / hibernate: Generate and verify signature for snapshot image
> > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> > >
> > > PM / hibernate: snapshot image encryption
> > > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> > >
> > > The above patches sign and encrypt the data pages in snapshot image.
> > > It puts the signature to header.
> > >
> > It looks like your signature code can be simplyly added on top of the
> > solution we proposed here, how about we collaborating on this task?
> 
> OK, I will base on your user key solution to respin my signature patches.
>  
> > just my 2 cents, 
> > 1. The cryption code should be indepent of the snapshot code, and
> >this is why we implement it as a kernel module for that in PATCH[1/3].
> 
> Why the cryption code must be indepent of snapshot code?
>
Modules can be easier to be maintained and customized/improved in the future 
IMO..
> > 2. There's no need to traverse the snapshot image twice, if the
> >image is large(there's requirement on servers now) we can
> >simplyly do the encryption before the disk IO, and this is
> >why PATCH[2/3] looks like this.
> 
> If the encryption solution is only for block device, then the uswsusp
> interface must be locked-down when kernel is in locked mode:
> 
> uswsusp: Disable when the kernel is locked down
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> 
> I still suggest to keep the solution to direct encript the snapshot
> image for uswsusp because the snapshot can be encrypted by kernel
> before user space get it.
> 
> I mean that if the uswsusp be used, then kernel direct encrypts the
> snapshot image, otherwise kernel encrypts pages before block io.
> 
I did not quite get the point, if the kernel has been locked down,
then the uswsusp is disabled, why the kernel encrypts the snapshot
for uswsusp?
> On the other hand, I have a question about asynchronous block io.
> Please see below...
> 
Okay.
> > > > > > Suggested-by: Rafael J. Wysocki 
> > > > > > Cc: Rafael J. Wysocki 
> > > > > > Cc: Pavel Machek 
> > > > > > Cc: Len Brown 
> > > > > > Cc: Borislav Petkov 
> > > > > > Cc: "Lee, Chun-Yi" 
> > > > > > Cc: linux...@vger.kernel.org
> > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > Signed-off-by: Chen Yu 
> > > > > > ---
> > > > > >  kernel/power/power.h |   1 +
> > > > > >  kernel/power/swap.c  | 215 
> > > > > > ---
> > > > > >  2 files changed, 205 insertions(+), 11 deletions(-)
> [...snip]
> > > > > >  /* kernel/power/hibernate.c */
> > > > > >  extern int swsusp_check(void);
> > > > > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > > > > index c2bcf97..2b6b3d0 100644
> > > > > > --- a/kernel/power/swap.c
> > > > > > +++ 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi Joey Lee,
On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote:
> On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > > > Hi,
> > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > > > Hi Chen Yu,
> > > > > 
> > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > > > Use the helper functions introduced previously to encrypt
> > > > > > the page data before they are submitted to the block device.
> > > > > > Besides, for the case of hibernation compression, the data
> > > > > > are firstly compressed and then encrypted, and vice versa
> > > > > > for the resume process.
> > > > > >
> > > > > 
> > > > > I want to suggest my solution that it direct signs/encrypts the
> > > > > memory snapshot image. This solution is already shipped with
> > > > > SLE12 a couple of years:
> > > > > 
> > > > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > > > 
> > > > I did not see image page encryption in above link, if I understand
> > > 
> > > PM / hibernate: Generate and verify signature for snapshot image
> > > https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
> > >
> > > PM / hibernate: snapshot image encryption
> > > https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
> > >
> > > The above patches sign and encrypt the data pages in snapshot image.
> > > It puts the signature to header.
> > >
> > It looks like your signature code can be simplyly added on top of the
> > solution we proposed here, how about we collaborating on this task?
> 
> OK, I will base on your user key solution to respin my signature patches.
>  
> > just my 2 cents, 
> > 1. The cryption code should be indepent of the snapshot code, and
> >this is why we implement it as a kernel module for that in PATCH[1/3].
> 
> Why the cryption code must be indepent of snapshot code?
>
Modules can be easier to be maintained and customized/improved in the future 
IMO..
> > 2. There's no need to traverse the snapshot image twice, if the
> >image is large(there's requirement on servers now) we can
> >simplyly do the encryption before the disk IO, and this is
> >why PATCH[2/3] looks like this.
> 
> If the encryption solution is only for block device, then the uswsusp
> interface must be locked-down when kernel is in locked mode:
> 
> uswsusp: Disable when the kernel is locked down
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=lockdown-20180410=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> 
> I still suggest to keep the solution to direct encript the snapshot
> image for uswsusp because the snapshot can be encrypted by kernel
> before user space get it.
> 
> I mean that if the uswsusp be used, then kernel direct encrypts the
> snapshot image, otherwise kernel encrypts pages before block io.
> 
I did not quite get the point, if the kernel has been locked down,
then the uswsusp is disabled, why the kernel encrypts the snapshot
for uswsusp?
> On the other hand, I have a question about asynchronous block io.
> Please see below...
> 
Okay.
> > > > > > Suggested-by: Rafael J. Wysocki 
> > > > > > Cc: Rafael J. Wysocki 
> > > > > > Cc: Pavel Machek 
> > > > > > Cc: Len Brown 
> > > > > > Cc: Borislav Petkov 
> > > > > > Cc: "Lee, Chun-Yi" 
> > > > > > Cc: linux...@vger.kernel.org
> > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > Signed-off-by: Chen Yu 
> > > > > > ---
> > > > > >  kernel/power/power.h |   1 +
> > > > > >  kernel/power/swap.c  | 215 
> > > > > > ---
> > > > > >  2 files changed, 205 insertions(+), 11 deletions(-)
> [...snip]
> > > > > >  /* kernel/power/hibernate.c */
> > > > > >  extern int swsusp_check(void);
> > > > > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > > > > index c2bcf97..2b6b3d0 100644
> > > > > > --- a/kernel/power/swap.c
> > > > > > +++ 

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

[Yu Chen]

Sorry for late reply.
On Fri, Jul 06, 2018 at 12:16:37AM +0800, joeyli wrote:
> Hi Chen Yu, 
> 
> On Wed, Jun 20, 2018 at 05:39:37PM +0800, Chen Yu wrote:
> > Hi,
> > As security becomes more and more important, we add the in-kernel
> > encryption support for hibernation.
> > 
> > This prototype is a trial version to implement the hibernation
> > encryption in the kernel, so that the users do not have to rely
> > on third-party tools to encrypt the hibernation image. The only
> > dependency on user space is that, the user space should provide
> > a valid key derived from passphrase to the kernel for image encryption.
> > 
> > There was a discussion on the mailing list on whether this key should
> > be derived in kernel or in user space. And it turns out to be generating
> > the key by user space is more acceptable[1]. So this patch set is divided
> > into two parts:
> > 1. The hibernation snapshot encryption in kernel space,
> > 2. the key derivation implementation in user space.
> > 
> > Please refer to each patch for detail, and feel free to comment on
> > this, thanks.
> > 
> > [1] https://www.spinics.net/lists/linux-crypto/msg33145.html
> > 
> > Chen Yu (3):
> >   PM / Hibernate: Add helper functions for hibernation encryption
> >   PM / Hibernate: Encrypt the snapshot pages before submitted to the
> > block device
> >   tools: create power/crypto utility
> >
> 
> I am trying this patch set.
> 
> Could you please tell me how to test the user space crypto utility with
> systemd's hibernation module? 
> 
Usage:
1. install the kernel module:
   modprobe crypto_hibernation
2. run the tool to generate the key from
   user provided passphrase:
   ./crypto_hibernate
3. launch the hibernation process:
   echo disk > /sys/power/state
4. The initrd launches cryto_hibernate
   to read previous salt from kernel and
   probe the user passphrase and generate the same key:
   ./crypto_hibernate
5. kernel uses this key to decrypt the hibernation
   snapshot.
> I have a question about the salt. If the salt is saved in image header,
> does that mean that kernel needs to read the image header before user
> space crypto utility be launched? Otherwise user space can not get
> the salt to produce key? I a bit confused about the resume process.
> 
The crypto_hibernate will first read the salt from the kernel
via ioctl(the kernel will first expose the salt for the user
in crypto_restore(), then the crypto_hibernate uses ioctl to
read it) and then uses that salt together with user provided
passphrase to generate the key, and pass that key to the kernel
for decryption.
> Thanks
> Joey Lee 

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

[Yu Chen]

Sorry for late reply.
On Fri, Jul 06, 2018 at 12:16:37AM +0800, joeyli wrote:
> Hi Chen Yu, 
> 
> On Wed, Jun 20, 2018 at 05:39:37PM +0800, Chen Yu wrote:
> > Hi,
> > As security becomes more and more important, we add the in-kernel
> > encryption support for hibernation.
> > 
> > This prototype is a trial version to implement the hibernation
> > encryption in the kernel, so that the users do not have to rely
> > on third-party tools to encrypt the hibernation image. The only
> > dependency on user space is that, the user space should provide
> > a valid key derived from passphrase to the kernel for image encryption.
> > 
> > There was a discussion on the mailing list on whether this key should
> > be derived in kernel or in user space. And it turns out to be generating
> > the key by user space is more acceptable[1]. So this patch set is divided
> > into two parts:
> > 1. The hibernation snapshot encryption in kernel space,
> > 2. the key derivation implementation in user space.
> > 
> > Please refer to each patch for detail, and feel free to comment on
> > this, thanks.
> > 
> > [1] https://www.spinics.net/lists/linux-crypto/msg33145.html
> > 
> > Chen Yu (3):
> >   PM / Hibernate: Add helper functions for hibernation encryption
> >   PM / Hibernate: Encrypt the snapshot pages before submitted to the
> > block device
> >   tools: create power/crypto utility
> >
> 
> I am trying this patch set.
> 
> Could you please tell me how to test the user space crypto utility with
> systemd's hibernation module? 
> 
Usage:
1. install the kernel module:
   modprobe crypto_hibernation
2. run the tool to generate the key from
   user provided passphrase:
   ./crypto_hibernate
3. launch the hibernation process:
   echo disk > /sys/power/state
4. The initrd launches cryto_hibernate
   to read previous salt from kernel and
   probe the user passphrase and generate the same key:
   ./crypto_hibernate
5. kernel uses this key to decrypt the hibernation
   snapshot.
> I have a question about the salt. If the salt is saved in image header,
> does that mean that kernel needs to read the image header before user
> space crypto utility be launched? Otherwise user space can not get
> the salt to produce key? I a bit confused about the resume process.
> 
The crypto_hibernate will first read the salt from the kernel
via ioctl(the kernel will first expose the salt for the user
in crypto_restore(), then the crypto_hibernate uses ioctl to
read it) and then uses that salt together with user provided
passphrase to generate the key, and pass that key to the kernel
for decryption.
> Thanks
> Joey Lee 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi,
On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > Hi Chen Yu,
> > > 
> > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > Use the helper functions introduced previously to encrypt
> > > > the page data before they are submitted to the block device.
> > > > Besides, for the case of hibernation compression, the data
> > > > are firstly compressed and then encrypted, and vice versa
> > > > for the resume process.
> > > >
> > > 
> > > I want to suggest my solution that it direct signs/encrypts the
> > > memory snapshot image. This solution is already shipped with
> > > SLE12 a couple of years:
> > > 
> > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > 
> > I did not see image page encryption in above link, if I understand
> 
> PM / hibernate: Generate and verify signature for snapshot image
> https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
>
> PM / hibernate: snapshot image encryption
> https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
>
> The above patches sign and encrypt the data pages in snapshot image.
> It puts the signature to header.
>
It looks like your signature code can be simplyly added on top of the
solution we proposed here, how about we collaborating on this task? 
just my 2 cents, 
1. The cryption code should be indepent of the snapshot code, and
   this is why we implement it as a kernel module for that in PATCH[1/3].
2. There's no need to traverse the snapshot image twice, if the
   image is large(there's requirement on servers now) we can
   simplyly do the encryption before the disk IO, and this is
   why PATCH[2/3] looks like this.
> > correctly, your code focus on signation and encrypt the hidden data,
> > but not target for the whole snapshot data.
> 
> Please ignore the hidden area because we already encrypted snapshot image.
> Those data doesn't need to erase from snapshot anymore. I will remove
> the hidden area patches in next version. 
> 
> > > The above patches still need to clean up. I am working on some
> > > other bugs, but I can clean up and send out it ASAP.
> > > 
> > > The advantage of this solution is that it produces a signed and
> > > encrypted image. Not just for writing to block device by kernel,
> > > it also can provide a signed/encrypted image to user space. User
> > > space can store the encrypted image to anywhere.
> > > 
> > > I am OK for your user space key generator because I didn't have
> > > similar solution yet. I am working on the EFI master key and also
> > > want to adapt hibernation to keyring. I will continue the works.
> > > 
> > The user space tool can easily add the keyring support besides
> > ioctl if needed.
> >
> 
> Understood.
> 
> Thanks
> Joey Lee
>  
Best,
Yu
> > Best,
> > Yu
> > > Thanks a lot!
> > > Joey Lee
> > >  
> > > > Suggested-by: Rafael J. Wysocki 
> > > > Cc: Rafael J. Wysocki 
> > > > Cc: Pavel Machek 
> > > > Cc: Len Brown 
> > > > Cc: Borislav Petkov 
> > > > Cc: "Lee, Chun-Yi" 
> > > > Cc: linux...@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Signed-off-by: Chen Yu 
> > > > ---
> > > >  kernel/power/power.h |   1 +
> > > >  kernel/power/swap.c  | 215 
> > > > ---
> > > >  2 files changed, 205 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > > > index 660aac3..637695c 100644
> > > > --- a/kernel/power/power.h
> > > > +++ b/kernel/power/power.h
> > > > @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
> > > >  #define SF_PLATFORM_MODE   1
> > > >  #define SF_NOCOMPRESS_MODE 2
> > > >  #define SF_CRC32_MODE  4
> > > > +#define SF_ENCRYPT_MODE8
> > > >  
> > > >  /* kernel/power/hibernate.c */
> > > >  extern int swsusp_check(void);
> > > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > > index c2bcf97..2b6b3d0 100644
> > > > --- a/kernel/power/swap.c
> > > > +++ b/kernel/power/swap.

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi,
On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote:
> On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote:
> > Hi,
> > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> > > Hi Chen Yu,
> > > 
> > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > > > Use the helper functions introduced previously to encrypt
> > > > the page data before they are submitted to the block device.
> > > > Besides, for the case of hibernation compression, the data
> > > > are firstly compressed and then encrypted, and vice versa
> > > > for the resume process.
> > > >
> > > 
> > > I want to suggest my solution that it direct signs/encrypts the
> > > memory snapshot image. This solution is already shipped with
> > > SLE12 a couple of years:
> > > 
> > > https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> > > 
> > I did not see image page encryption in above link, if I understand
> 
> PM / hibernate: Generate and verify signature for snapshot image
> https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
>
> PM / hibernate: snapshot image encryption
> https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929
>
> The above patches sign and encrypt the data pages in snapshot image.
> It puts the signature to header.
>
It looks like your signature code can be simplyly added on top of the
solution we proposed here, how about we collaborating on this task? 
just my 2 cents, 
1. The cryption code should be indepent of the snapshot code, and
   this is why we implement it as a kernel module for that in PATCH[1/3].
2. There's no need to traverse the snapshot image twice, if the
   image is large(there's requirement on servers now) we can
   simplyly do the encryption before the disk IO, and this is
   why PATCH[2/3] looks like this.
> > correctly, your code focus on signation and encrypt the hidden data,
> > but not target for the whole snapshot data.
> 
> Please ignore the hidden area because we already encrypted snapshot image.
> Those data doesn't need to erase from snapshot anymore. I will remove
> the hidden area patches in next version. 
> 
> > > The above patches still need to clean up. I am working on some
> > > other bugs, but I can clean up and send out it ASAP.
> > > 
> > > The advantage of this solution is that it produces a signed and
> > > encrypted image. Not just for writing to block device by kernel,
> > > it also can provide a signed/encrypted image to user space. User
> > > space can store the encrypted image to anywhere.
> > > 
> > > I am OK for your user space key generator because I didn't have
> > > similar solution yet. I am working on the EFI master key and also
> > > want to adapt hibernation to keyring. I will continue the works.
> > > 
> > The user space tool can easily add the keyring support besides
> > ioctl if needed.
> >
> 
> Understood.
> 
> Thanks
> Joey Lee
>  
Best,
Yu
> > Best,
> > Yu
> > > Thanks a lot!
> > > Joey Lee
> > >  
> > > > Suggested-by: Rafael J. Wysocki 
> > > > Cc: Rafael J. Wysocki 
> > > > Cc: Pavel Machek 
> > > > Cc: Len Brown 
> > > > Cc: Borislav Petkov 
> > > > Cc: "Lee, Chun-Yi" 
> > > > Cc: linux...@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Signed-off-by: Chen Yu 
> > > > ---
> > > >  kernel/power/power.h |   1 +
> > > >  kernel/power/swap.c  | 215 
> > > > ---
> > > >  2 files changed, 205 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > > > index 660aac3..637695c 100644
> > > > --- a/kernel/power/power.h
> > > > +++ b/kernel/power/power.h
> > > > @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
> > > >  #define SF_PLATFORM_MODE   1
> > > >  #define SF_NOCOMPRESS_MODE 2
> > > >  #define SF_CRC32_MODE  4
> > > > +#define SF_ENCRYPT_MODE8
> > > >  
> > > >  /* kernel/power/hibernate.c */
> > > >  extern int swsusp_check(void);
> > > > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > > > index c2bcf97..2b6b3d0 100644
> > > > --- a/kernel/power/swap.c
> > > > +++ b/kernel/power/swap.

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi,
On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> Hi Chen Yu,
> 
> On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > Use the helper functions introduced previously to encrypt
> > the page data before they are submitted to the block device.
> > Besides, for the case of hibernation compression, the data
> > are firstly compressed and then encrypted, and vice versa
> > for the resume process.
> >
> 
> I want to suggest my solution that it direct signs/encrypts the
> memory snapshot image. This solution is already shipped with
> SLE12 a couple of years:
> 
> https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> 
I did not see image page encryption in above link, if I understand
correctly, your code focus on signation and encrypt the hidden data,
but not target for the whole snapshot data.
> The above patches still need to clean up. I am working on some
> other bugs, but I can clean up and send out it ASAP.
> 
> The advantage of this solution is that it produces a signed and
> encrypted image. Not just for writing to block device by kernel,
> it also can provide a signed/encrypted image to user space. User
> space can store the encrypted image to anywhere.
> 
> I am OK for your user space key generator because I didn't have
> similar solution yet. I am working on the EFI master key and also
> want to adapt hibernation to keyring. I will continue the works.
> 
The user space tool can easily add the keyring support besides
ioctl if needed.

Best,
Yu
> Thanks a lot!
> Joey Lee
>  
> > Suggested-by: Rafael J. Wysocki 
> > Cc: Rafael J. Wysocki 
> > Cc: Pavel Machek 
> > Cc: Len Brown 
> > Cc: Borislav Petkov 
> > Cc: "Lee, Chun-Yi" 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Chen Yu 
> > ---
> >  kernel/power/power.h |   1 +
> >  kernel/power/swap.c  | 215 
> > ---
> >  2 files changed, 205 insertions(+), 11 deletions(-)
> > 
> > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > index 660aac3..637695c 100644
> > --- a/kernel/power/power.h
> > +++ b/kernel/power/power.h
> > @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
> >  #define SF_PLATFORM_MODE   1
> >  #define SF_NOCOMPRESS_MODE 2
> >  #define SF_CRC32_MODE  4
> > +#define SF_ENCRYPT_MODE8
> >  
> >  /* kernel/power/hibernate.c */
> >  extern int swsusp_check(void);
> > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > index c2bcf97..2b6b3d0 100644
> > --- a/kernel/power/swap.c
> > +++ b/kernel/power/swap.c
> > @@ -102,14 +102,16 @@ struct swap_map_handle {
> > unsigned int k;
> > unsigned long reqd_free_pages;
> > u32 crc32;
> > +   bool crypto;
> >  };
> >  
> >  struct swsusp_header {
> > char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
> > - sizeof(u32)];
> > +   sizeof(u32) - HIBERNATE_SALT_BYTES];
> > u32 crc32;
> > sector_t image;
> > unsigned int flags; /* Flags to pass to the "boot" kernel */
> > +   char salt[HIBERNATE_SALT_BYTES];
> > charorig_sig[10];
> > charsig[10];
> >  } __packed;
> > @@ -127,6 +129,53 @@ struct swsusp_extent {
> > unsigned long end;
> >  };
> >  
> > +/* For encryption/decryption. */
> > +static struct hibernation_crypto *hibernation_crypto_ops;
> > +
> > +void set_hibernation_ops(struct hibernation_crypto *ops)
> > +{
> > +   hibernation_crypto_ops = ops;
> > +}
> > +EXPORT_SYMBOL_GPL(set_hibernation_ops);
> > +
> > +static int crypto_data(const char *inbuf,
> > +   int inlen,
> > +   char *outbuf,
> > +   int outlen,
> > +   bool encrypt,
> > +   int page_idx)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->crypto_data)
> > +   return hibernation_crypto_ops->crypto_data(inbuf,
> > +   inlen, outbuf, outlen, encrypt, page_idx);
> > +   else
> > +   return -EINVAL;
> > +}
> > +
> > +static void crypto_save(void *outbuf)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->save)
> > +   hibernation_crypto_ops->save(outbuf);
> > +}
> > +
> > +static void crypto_restore(void *inbuf)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->restore)
> > +   hibernation_crypto_ops->restore(inbuf);
> > +}
> > +
> > +static int crypto_init(bool suspend)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->init)
> > +   return hibernation_crypto_ops->init(suspend);
> > +   else
> > +   return -EINVAL;
> > +}
> > +
> >  static struct rb_root swsusp_extents = RB_ROOT;
> >  
> >  static int swsusp_extents_insert(unsigned long swap_offset)
> > @@ -318,6 +367,10 @@ static int mark_swapfiles(struct swap_map_handle 
> > *handle, unsigned int flags)
> > 

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

[Yu Chen]

Hi,
On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote:
> Hi Chen Yu,
> 
> On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote:
> > Use the helper functions introduced previously to encrypt
> > the page data before they are submitted to the block device.
> > Besides, for the case of hibernation compression, the data
> > are firstly compressed and then encrypted, and vice versa
> > for the resume process.
> >
> 
> I want to suggest my solution that it direct signs/encrypts the
> memory snapshot image. This solution is already shipped with
> SLE12 a couple of years:
> 
> https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4.17-rc3
> 
I did not see image page encryption in above link, if I understand
correctly, your code focus on signation and encrypt the hidden data,
but not target for the whole snapshot data.
> The above patches still need to clean up. I am working on some
> other bugs, but I can clean up and send out it ASAP.
> 
> The advantage of this solution is that it produces a signed and
> encrypted image. Not just for writing to block device by kernel,
> it also can provide a signed/encrypted image to user space. User
> space can store the encrypted image to anywhere.
> 
> I am OK for your user space key generator because I didn't have
> similar solution yet. I am working on the EFI master key and also
> want to adapt hibernation to keyring. I will continue the works.
> 
The user space tool can easily add the keyring support besides
ioctl if needed.

Best,
Yu
> Thanks a lot!
> Joey Lee
>  
> > Suggested-by: Rafael J. Wysocki 
> > Cc: Rafael J. Wysocki 
> > Cc: Pavel Machek 
> > Cc: Len Brown 
> > Cc: Borislav Petkov 
> > Cc: "Lee, Chun-Yi" 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Chen Yu 
> > ---
> >  kernel/power/power.h |   1 +
> >  kernel/power/swap.c  | 215 
> > ---
> >  2 files changed, 205 insertions(+), 11 deletions(-)
> > 
> > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > index 660aac3..637695c 100644
> > --- a/kernel/power/power.h
> > +++ b/kernel/power/power.h
> > @@ -207,6 +207,7 @@ extern int swsusp_swap_in_use(void);
> >  #define SF_PLATFORM_MODE   1
> >  #define SF_NOCOMPRESS_MODE 2
> >  #define SF_CRC32_MODE  4
> > +#define SF_ENCRYPT_MODE8
> >  
> >  /* kernel/power/hibernate.c */
> >  extern int swsusp_check(void);
> > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > index c2bcf97..2b6b3d0 100644
> > --- a/kernel/power/swap.c
> > +++ b/kernel/power/swap.c
> > @@ -102,14 +102,16 @@ struct swap_map_handle {
> > unsigned int k;
> > unsigned long reqd_free_pages;
> > u32 crc32;
> > +   bool crypto;
> >  };
> >  
> >  struct swsusp_header {
> > char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
> > - sizeof(u32)];
> > +   sizeof(u32) - HIBERNATE_SALT_BYTES];
> > u32 crc32;
> > sector_t image;
> > unsigned int flags; /* Flags to pass to the "boot" kernel */
> > +   char salt[HIBERNATE_SALT_BYTES];
> > charorig_sig[10];
> > charsig[10];
> >  } __packed;
> > @@ -127,6 +129,53 @@ struct swsusp_extent {
> > unsigned long end;
> >  };
> >  
> > +/* For encryption/decryption. */
> > +static struct hibernation_crypto *hibernation_crypto_ops;
> > +
> > +void set_hibernation_ops(struct hibernation_crypto *ops)
> > +{
> > +   hibernation_crypto_ops = ops;
> > +}
> > +EXPORT_SYMBOL_GPL(set_hibernation_ops);
> > +
> > +static int crypto_data(const char *inbuf,
> > +   int inlen,
> > +   char *outbuf,
> > +   int outlen,
> > +   bool encrypt,
> > +   int page_idx)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->crypto_data)
> > +   return hibernation_crypto_ops->crypto_data(inbuf,
> > +   inlen, outbuf, outlen, encrypt, page_idx);
> > +   else
> > +   return -EINVAL;
> > +}
> > +
> > +static void crypto_save(void *outbuf)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->save)
> > +   hibernation_crypto_ops->save(outbuf);
> > +}
> > +
> > +static void crypto_restore(void *inbuf)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->restore)
> > +   hibernation_crypto_ops->restore(inbuf);
> > +}
> > +
> > +static int crypto_init(bool suspend)
> > +{
> > +   if (hibernation_crypto_ops &&
> > +   hibernation_crypto_ops->init)
> > +   return hibernation_crypto_ops->init(suspend);
> > +   else
> > +   return -EINVAL;
> > +}
> > +
> >  static struct rb_root swsusp_extents = RB_ROOT;
> >  
> >  static int swsusp_extents_insert(unsigned long swap_offset)
> > @@ -318,6 +367,10 @@ static int mark_swapfiles(struct swap_map_handle 
> > *handle, unsigned int flags)
> > 

Re: [PATCH 3/3][RFC] tools: create power/crypto utility

[Yu Chen]

Hi Eric,
On Wed, Jun 20, 2018 at 10:41:42AM -0700, Eric Biggers wrote:
> Hi Chen,
> 
> On Wed, Jun 20, 2018 at 05:40:51PM +0800, Chen Yu wrote:
> > crypto_hibernate is a user-space utility to generate
> > 512bits AES key and pass it to the kernel via ioctl
> > for hibernation encryption.(We can also add the key
> > into kernel via keyctl if necessary, but currently
> > using ioctl seems to be more straightforward as we
> > need both the key and salt transit).
> > 
> > The key derivation is based on a simplified implementation
> > of PBKDF2[1] in e2fsprogs - both the key length and the hash
> > bytes are the same - 512bits. crypto_hibernate will firstly
> > probe the user for passphrase and get salt from kernel, then
> > uses them to generate a 512bits AES key based on PBKDF2.
Thanks for reviewing this.
> 
> What is a "512bits AES key"?  Do you mean AES-256-XTS (which takes a 512-bit
> key, which the XTS mode internally splits into two keys)? 
Yes, it is AES-256-XTS.
> Do you allow for
> other algorithms, or is it hardcoded to AES-256-XTS? 
Currently it is hardcoded to AES-256-XTS. It is copied from implementation
of PBKDF2 in e2fsprogs, which is hardcoded to useAES-256-XTS for ext4 encryption
in the kernel(pbkdf2_sha512() in e2fsprogs)
> What if someone wants to
> use a different algorithm?
> 
If user wants to use a different algorithm, then I think we need to
port the code from openssl, which is the full implementation of PBKDF2
for:
https://www.ietf.org/rfc/rfc2898.txt 
> BTW, it's difficult to review this with only patch 3/3 Cc'ed to me, as there 
> is
> no context about the problem you are trying to solve and what your actual
> proposed kernel changes are.  I suggest Cc'ing linux-crypto on all 3 patches.
> 
Ok, I'll send a refreshed version.
> A few more comments below, from a very brief reading of the code:
> 
> [...]
> > +
> > +#define PBKDF2_ITERATIONS  0x
> > +#define SHA512_BLOCKSIZE 128
> > +#define SHA512_LENGTH 64
> > +#define SALT_BYTES 16
> > +#define SYM_KEY_BYTES SHA512_LENGTH
> > +#define TOTAL_USER_INFO_LEN(SALT_BYTES+SYM_KEY_BYTES)
> > +#define MAX_PASSPHRASE_SIZE1024
> > +
> > +struct hibernation_crypto_keys {
> > +   char derived_key[SYM_KEY_BYTES];
> > +   char salt[SALT_BYTES];
> > +   bool valid;
> > +};
> > +
> > +struct hibernation_crypto_keys hib_keys;
> > +
> > +static char *get_key_ptr(void)
> > +{
> > +   return hib_keys.derived_key;
> > +}
> > +
> > +static char *get_salt_ptr(void)
> > +{
> > +   return hib_keys.salt;
> > +}
> [...]
> > +
> > +
> > +#define HIBERNATE_SALT_READ  _IOW('C', 3, struct 
> > hibernation_crypto_keys)
> > +#define HIBERNATE_KEY_WRITE _IOW('C', 4, struct 
> > hibernation_crypto_keys)
> 
> Why are the ioctl numbers defined based on the size of 'struct
> hibernation_crypto_keys'?  It's not a UAPI structure, right?
> 
It's not a UAPI structure, and it is defined both in user space tool
and in kernel. Do you mean, I should put the defination of this
structure under include/uapi ?
> > +
> > +static void get_passphrase(char *passphrase, int len)
> > +{
> > +   char *p;
> > +   struct termios current_settings;
> > +
> > +   assert(len > 0);
> > +   disable_echo(_settings);
> > +   p = fgets(passphrase, len, stdin);
> > +   tcsetattr(0, TCSANOW, _settings);
> > +   printf("\n");
> > +   if (!p) {
> > +   printf("Aborting.\n");
> > +   exit(1);
> > +   }
> > +   p = strrchr(passphrase, '\n');
> > +   if (!p)
> > +   p = passphrase + len - 1;
> > +   *p = '\0';
> > +}
> > +
> > +#define CRYPTO_FILE"/dev/crypto_hibernate"
> > +
> > +static int write_keys(void)
> > +{
> > +   int fd;
> > +
> > +   fd = open(CRYPTO_FILE, O_RDWR);
> > +   if (fd < 0) {
> > +   printf("Cannot open device file...\n");
> > +   return -EINVAL;
> > +   }
> > +   ioctl(fd, HIBERNATE_KEY_WRITE, get_key_ptr());
> > +   return 0;
> 
> No error checking on the ioctl?
> 
Ok, will add error checking for it.
> Also, how is the kernel supposed to know how long the key is, and which
> algorithm it's supposed to be used for?  I assume it's hardcoded to 
> AES-256-XTS?
> What if someone wants to use a different algorithm?
> 
Yes, the length in both user space and kernel are hardcoded to AES-256-XTS.
I can add the support for other algorithm, but might need to port from
openssl first.
> > +}
> > +
> > +static int read_salt(void)
> > +{
> > +   int fd;
> > +
> > +   fd = open(CRYPTO_FILE, O_RDWR);
> > +   if (fd < 0) {
> > +   printf("Cannot open device file...\n");
> > +   return -EINVAL;
> > +   }
> > +   ioctl(fd, HIBERNATE_SALT_READ, get_salt_ptr());
> > +   return 0;
> > +}
> 
> No error checking on the ioctl?
> 
Ok, will add checkings.
> > +int main(int argc, char *argv[])
> > +{
> > +   int opt, option_index = 0;
> > +   char in_passphrase[MAX_PASSPHRASE_SIZE];
> > +
> > +   while ((opt = getopt_long_only(argc, argv, "+p:s:h",
> > +   NULL, _index)) != -1) {
> > +

Re: [PATCH 3/3][RFC] tools: create power/crypto utility

[Yu Chen]

Hi Eric,
On Wed, Jun 20, 2018 at 10:41:42AM -0700, Eric Biggers wrote:
> Hi Chen,
> 
> On Wed, Jun 20, 2018 at 05:40:51PM +0800, Chen Yu wrote:
> > crypto_hibernate is a user-space utility to generate
> > 512bits AES key and pass it to the kernel via ioctl
> > for hibernation encryption.(We can also add the key
> > into kernel via keyctl if necessary, but currently
> > using ioctl seems to be more straightforward as we
> > need both the key and salt transit).
> > 
> > The key derivation is based on a simplified implementation
> > of PBKDF2[1] in e2fsprogs - both the key length and the hash
> > bytes are the same - 512bits. crypto_hibernate will firstly
> > probe the user for passphrase and get salt from kernel, then
> > uses them to generate a 512bits AES key based on PBKDF2.
Thanks for reviewing this.
> 
> What is a "512bits AES key"?  Do you mean AES-256-XTS (which takes a 512-bit
> key, which the XTS mode internally splits into two keys)? 
Yes, it is AES-256-XTS.
> Do you allow for
> other algorithms, or is it hardcoded to AES-256-XTS? 
Currently it is hardcoded to AES-256-XTS. It is copied from implementation
of PBKDF2 in e2fsprogs, which is hardcoded to useAES-256-XTS for ext4 encryption
in the kernel(pbkdf2_sha512() in e2fsprogs)
> What if someone wants to
> use a different algorithm?
> 
If user wants to use a different algorithm, then I think we need to
port the code from openssl, which is the full implementation of PBKDF2
for:
https://www.ietf.org/rfc/rfc2898.txt 
> BTW, it's difficult to review this with only patch 3/3 Cc'ed to me, as there 
> is
> no context about the problem you are trying to solve and what your actual
> proposed kernel changes are.  I suggest Cc'ing linux-crypto on all 3 patches.
> 
Ok, I'll send a refreshed version.
> A few more comments below, from a very brief reading of the code:
> 
> [...]
> > +
> > +#define PBKDF2_ITERATIONS  0x
> > +#define SHA512_BLOCKSIZE 128
> > +#define SHA512_LENGTH 64
> > +#define SALT_BYTES 16
> > +#define SYM_KEY_BYTES SHA512_LENGTH
> > +#define TOTAL_USER_INFO_LEN(SALT_BYTES+SYM_KEY_BYTES)
> > +#define MAX_PASSPHRASE_SIZE1024
> > +
> > +struct hibernation_crypto_keys {
> > +   char derived_key[SYM_KEY_BYTES];
> > +   char salt[SALT_BYTES];
> > +   bool valid;
> > +};
> > +
> > +struct hibernation_crypto_keys hib_keys;
> > +
> > +static char *get_key_ptr(void)
> > +{
> > +   return hib_keys.derived_key;
> > +}
> > +
> > +static char *get_salt_ptr(void)
> > +{
> > +   return hib_keys.salt;
> > +}
> [...]
> > +
> > +
> > +#define HIBERNATE_SALT_READ  _IOW('C', 3, struct 
> > hibernation_crypto_keys)
> > +#define HIBERNATE_KEY_WRITE _IOW('C', 4, struct 
> > hibernation_crypto_keys)
> 
> Why are the ioctl numbers defined based on the size of 'struct
> hibernation_crypto_keys'?  It's not a UAPI structure, right?
> 
It's not a UAPI structure, and it is defined both in user space tool
and in kernel. Do you mean, I should put the defination of this
structure under include/uapi ?
> > +
> > +static void get_passphrase(char *passphrase, int len)
> > +{
> > +   char *p;
> > +   struct termios current_settings;
> > +
> > +   assert(len > 0);
> > +   disable_echo(_settings);
> > +   p = fgets(passphrase, len, stdin);
> > +   tcsetattr(0, TCSANOW, _settings);
> > +   printf("\n");
> > +   if (!p) {
> > +   printf("Aborting.\n");
> > +   exit(1);
> > +   }
> > +   p = strrchr(passphrase, '\n');
> > +   if (!p)
> > +   p = passphrase + len - 1;
> > +   *p = '\0';
> > +}
> > +
> > +#define CRYPTO_FILE"/dev/crypto_hibernate"
> > +
> > +static int write_keys(void)
> > +{
> > +   int fd;
> > +
> > +   fd = open(CRYPTO_FILE, O_RDWR);
> > +   if (fd < 0) {
> > +   printf("Cannot open device file...\n");
> > +   return -EINVAL;
> > +   }
> > +   ioctl(fd, HIBERNATE_KEY_WRITE, get_key_ptr());
> > +   return 0;
> 
> No error checking on the ioctl?
> 
Ok, will add error checking for it.
> Also, how is the kernel supposed to know how long the key is, and which
> algorithm it's supposed to be used for?  I assume it's hardcoded to 
> AES-256-XTS?
> What if someone wants to use a different algorithm?
> 
Yes, the length in both user space and kernel are hardcoded to AES-256-XTS.
I can add the support for other algorithm, but might need to port from
openssl first.
> > +}
> > +
> > +static int read_salt(void)
> > +{
> > +   int fd;
> > +
> > +   fd = open(CRYPTO_FILE, O_RDWR);
> > +   if (fd < 0) {
> > +   printf("Cannot open device file...\n");
> > +   return -EINVAL;
> > +   }
> > +   ioctl(fd, HIBERNATE_SALT_READ, get_salt_ptr());
> > +   return 0;
> > +}
> 
> No error checking on the ioctl?
> 
Ok, will add checkings.
> > +int main(int argc, char *argv[])
> > +{
> > +   int opt, option_index = 0;
> > +   char in_passphrase[MAX_PASSPHRASE_SIZE];
> > +
> > +   while ((opt = getopt_long_only(argc, argv, "+p:s:h",
> > +   NULL, _index)) != -1) {
> > +

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

[Yu Chen]

Hi,
On Thu, Jun 21, 2018 at 09:14:43PM +0200, Pavel Machek wrote:
> On Thu 2018-06-21 14:08:40, Rafael J. Wysocki wrote:
> > On Thu, Jun 21, 2018 at 10:53 AM, Pavel Machek  wrote:
> > > Hi!
> > >
> > >> As security becomes more and more important, we add the in-kernel
> > >> encryption support for hibernation.
> > > ...
> > >> There was a discussion on the mailing list on whether this key should
> > >> be derived in kernel or in user space. And it turns out to be generating
> > >> the key by user space is more acceptable[1]. So this patch set is divided
> > >> into two parts:
> > >> 1. The hibernation snapshot encryption in kernel space,
> > >> 2. the key derivation implementation in user space.
> > >
> > > uswsusp was created so that this kind of stuff could be kept in
> > > userspace. You get graphical progress bar (etc) too. As you already
> > > have userspace component for key derivation, I see no advantages to
> > > uswsusp.
> > >
> > > If you have some, please explain.
> > 
> > Not having to transfer plain text kernel memory to user space is one
> > IMO.
> 
> Well, AFAICT in this case userland has the key and encrypted data are
> on disk. That does not seem to be improvement.
> 
uswsusp needs to read the snapshot from kernel first, while
do encryption in kernel directly would reduce the IO. Besides,
the kernel memory content is protect from been read from
user space from first place, although finally they are
encrypted on the disk.

Best,
Yu

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

[Yu Chen]

Hi,
On Thu, Jun 21, 2018 at 09:14:43PM +0200, Pavel Machek wrote:
> On Thu 2018-06-21 14:08:40, Rafael J. Wysocki wrote:
> > On Thu, Jun 21, 2018 at 10:53 AM, Pavel Machek  wrote:
> > > Hi!
> > >
> > >> As security becomes more and more important, we add the in-kernel
> > >> encryption support for hibernation.
> > > ...
> > >> There was a discussion on the mailing list on whether this key should
> > >> be derived in kernel or in user space. And it turns out to be generating
> > >> the key by user space is more acceptable[1]. So this patch set is divided
> > >> into two parts:
> > >> 1. The hibernation snapshot encryption in kernel space,
> > >> 2. the key derivation implementation in user space.
> > >
> > > uswsusp was created so that this kind of stuff could be kept in
> > > userspace. You get graphical progress bar (etc) too. As you already
> > > have userspace component for key derivation, I see no advantages to
> > > uswsusp.
> > >
> > > If you have some, please explain.
> > 
> > Not having to transfer plain text kernel memory to user space is one
> > IMO.
> 
> Well, AFAICT in this case userland has the key and encrypted data are
> on disk. That does not seem to be improvement.
> 
uswsusp needs to read the snapshot from kernel first, while
do encryption in kernel directly would reduce the IO. Besides,
the kernel memory content is protect from been read from
user space from first place, although finally they are
encrypted on the disk.

Best,
Yu

Re: [PATCH][RFC] sched: cpufreq: Fix long idle judgement logic in load calculation

[Yu Chen]

Hi Viresh,
thanks for the comment,
On Thu, Jun 07, 2018 at 10:15:43AM +0530, Viresh Kumar wrote:
> On 07-06-18, 11:17, Chen Yu wrote:
> > diff --git a/drivers/cpufreq/cpufreq_governor.c 
> > b/drivers/cpufreq/cpufreq_governor.c
> > index 871bf9c..9792c80 100644
> > --- a/drivers/cpufreq/cpufreq_governor.c
> > +++ b/drivers/cpufreq/cpufreq_governor.c
> > @@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
> >  * calls, so the previous load value can be used then.
> >  */
> > load = j_cdbs->prev_load;
> > -   } else if (unlikely(time_elapsed > 2 * sampling_rate &&
> > +   } else if (((int)idle_time > 0) && unlikely(idle_time > 2 * 
> > sampling_rate &&
> 
> Yes the figures are insane, but if the idle time is around 36 minutes, the
> conversion to int will make a positive value look negative and we will exit 
> the
> conditional block. And if we don't think that we will ever get such insane 
> idle
> times or we don't want to care about them, then what about doing this instead:
> 
>   } else if ((unlikely((int)idle_time > 2 * sampling_rate &&
> 
> same below.
> 
Yes, this would be more straightforward.

Best,
Yu
> -- 
> viresh

Re: [PATCH][RFC] sched: cpufreq: Fix long idle judgement logic in load calculation

[Yu Chen]

Hi Viresh,
thanks for the comment,
On Thu, Jun 07, 2018 at 10:15:43AM +0530, Viresh Kumar wrote:
> On 07-06-18, 11:17, Chen Yu wrote:
> > diff --git a/drivers/cpufreq/cpufreq_governor.c 
> > b/drivers/cpufreq/cpufreq_governor.c
> > index 871bf9c..9792c80 100644
> > --- a/drivers/cpufreq/cpufreq_governor.c
> > +++ b/drivers/cpufreq/cpufreq_governor.c
> > @@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
> >  * calls, so the previous load value can be used then.
> >  */
> > load = j_cdbs->prev_load;
> > -   } else if (unlikely(time_elapsed > 2 * sampling_rate &&
> > +   } else if (((int)idle_time > 0) && unlikely(idle_time > 2 * 
> > sampling_rate &&
> 
> Yes the figures are insane, but if the idle time is around 36 minutes, the
> conversion to int will make a positive value look negative and we will exit 
> the
> conditional block. And if we don't think that we will ever get such insane 
> idle
> times or we don't want to care about them, then what about doing this instead:
> 
>   } else if ((unlikely((int)idle_time > 2 * sampling_rate &&
> 
> same below.
> 
Yes, this would be more straightforward.

Best,
Yu
> -- 
> viresh

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[Yu Chen]

On Sun, May 13, 2018 at 11:30:52AM +0200, Rafael J. Wysocki wrote:
> On Saturday, May 5, 2018 1:53:22 PM CEST Chen Yu wrote:
> > According to current implementation of acpi_pad driver,
> > it does not make sense to spawn any power saving threads
> > on the cpus which are already idle - it might bring
> > unnecessary overhead on these idle cpus and causes power
> > waste. So verify the condition that if the number of 'busy'
> > cpus exceeds the amount of the 'forced idle' cpus is met.
> > This is applicable due to round-robin attribute of the
> > power saving threads, otherwise ignore the setting/ACPI
> > notification.
> 
> OK, but CPUs are busy, because they are running tasks.  If acpi_pad
> kthreads run on them, the tasks they are running will migrate to the
> currently idle CPUs (unless they have specific CPU affinity) and the
> throttling will not really be effective.
>
OK, I think this makes sense, I missed the load balance scenario.
> I would think that acpi_pad should ensure that the requested number of
> CPUs will not run anything other than throttling kthreads.  Isn't that
> the case?
> 
Do you mean, we should check if the number of 'idle'(rather than the 'busy' one
in this patch) cpus is larger than the requested one? Then I think we should 
also
add a patch to use the play_idle() as power_clamp to treat the throttling 
kthreads
as idle threads thus to stop system tick. Such as the patch Jacob proposed:

Index: linux/drivers/acpi/acpi_pad.c
===
--- linux.orig/drivers/acpi/acpi_pad.c
+++ linux/drivers/acpi/acpi_pad.c
@@ -144,7 +144,6 @@ static unsigned int round_robin_time = 1
 static int power_saving_thread(void *data)
 {
struct sched_param param = {.sched_priority = 1};
-   int do_sleep;
unsigned int tsk_index = (unsigned long)data;
u64 last_jiffies = 0;
 
@@ -160,33 +159,13 @@ static int power_saving_thread(void *dat
round_robin_cpu(tsk_index);
}
 
-   do_sleep = 0;
-
-   expire_time = jiffies + HZ * (100 - idle_pct) / 100;
-
-   while (!need_resched()) {
-   if (tsc_detected_unstable && !tsc_marked_unstable) {
-   /* TSC could halt in idle, so notify users */
-   mark_tsc_unstable("TSC halts in idle");
-   tsc_marked_unstable = 1;
-   }
-   local_irq_disable();
-   tick_broadcast_enable();
-   tick_broadcast_enter();
-   stop_critical_timings();
-
-   mwait_idle_with_hints(power_saving_mwait_eax, 1);
-
-   start_critical_timings();
-   tick_broadcast_exit();
-   local_irq_enable();
-
-   if (time_before(expire_time, jiffies)) {
-   do_sleep = 1;
-   break;
-   }
+   if (tsc_detected_unstable && !tsc_marked_unstable) {
+   /* TSC could halt in idle, so notify users */
+   mark_tsc_unstable("TSC halts in idle");
+   tsc_marked_unstable = 1;
}
 
+   play_idle(jiffies_to_msecs(HZ * (100 - idle_pct) / 100));
/*
 * current sched_rt has threshold for rt task running time.
 * When a rt task uses 95% CPU time, the rt thread will be
@@ -196,8 +175,7 @@ static int power_saving_thread(void *dat
 * borrow CPU time from this CPU and cause RT task use > 95%
 * CPU time. To make 'avoid starvation' work, takes a nap here.
 */
-   if (unlikely(do_sleep))
-   schedule_timeout_killable(HZ * idle_pct / 100);
+   schedule_timeout_killable(HZ * idle_pct / 100);
 
/* If an external event has set the need_resched flag, then
 * we need to deal with it, or this loop will continue to
> Thanks,
> Rafael
> 

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[Yu Chen]

On Sun, May 13, 2018 at 11:30:52AM +0200, Rafael J. Wysocki wrote:
> On Saturday, May 5, 2018 1:53:22 PM CEST Chen Yu wrote:
> > According to current implementation of acpi_pad driver,
> > it does not make sense to spawn any power saving threads
> > on the cpus which are already idle - it might bring
> > unnecessary overhead on these idle cpus and causes power
> > waste. So verify the condition that if the number of 'busy'
> > cpus exceeds the amount of the 'forced idle' cpus is met.
> > This is applicable due to round-robin attribute of the
> > power saving threads, otherwise ignore the setting/ACPI
> > notification.
> 
> OK, but CPUs are busy, because they are running tasks.  If acpi_pad
> kthreads run on them, the tasks they are running will migrate to the
> currently idle CPUs (unless they have specific CPU affinity) and the
> throttling will not really be effective.
>
OK, I think this makes sense, I missed the load balance scenario.
> I would think that acpi_pad should ensure that the requested number of
> CPUs will not run anything other than throttling kthreads.  Isn't that
> the case?
> 
Do you mean, we should check if the number of 'idle'(rather than the 'busy' one
in this patch) cpus is larger than the requested one? Then I think we should 
also
add a patch to use the play_idle() as power_clamp to treat the throttling 
kthreads
as idle threads thus to stop system tick. Such as the patch Jacob proposed:

Index: linux/drivers/acpi/acpi_pad.c
===
--- linux.orig/drivers/acpi/acpi_pad.c
+++ linux/drivers/acpi/acpi_pad.c
@@ -144,7 +144,6 @@ static unsigned int round_robin_time = 1
 static int power_saving_thread(void *data)
 {
struct sched_param param = {.sched_priority = 1};
-   int do_sleep;
unsigned int tsk_index = (unsigned long)data;
u64 last_jiffies = 0;
 
@@ -160,33 +159,13 @@ static int power_saving_thread(void *dat
round_robin_cpu(tsk_index);
}
 
-   do_sleep = 0;
-
-   expire_time = jiffies + HZ * (100 - idle_pct) / 100;
-
-   while (!need_resched()) {
-   if (tsc_detected_unstable && !tsc_marked_unstable) {
-   /* TSC could halt in idle, so notify users */
-   mark_tsc_unstable("TSC halts in idle");
-   tsc_marked_unstable = 1;
-   }
-   local_irq_disable();
-   tick_broadcast_enable();
-   tick_broadcast_enter();
-   stop_critical_timings();
-
-   mwait_idle_with_hints(power_saving_mwait_eax, 1);
-
-   start_critical_timings();
-   tick_broadcast_exit();
-   local_irq_enable();
-
-   if (time_before(expire_time, jiffies)) {
-   do_sleep = 1;
-   break;
-   }
+   if (tsc_detected_unstable && !tsc_marked_unstable) {
+   /* TSC could halt in idle, so notify users */
+   mark_tsc_unstable("TSC halts in idle");
+   tsc_marked_unstable = 1;
}
 
+   play_idle(jiffies_to_msecs(HZ * (100 - idle_pct) / 100));
/*
 * current sched_rt has threshold for rt task running time.
 * When a rt task uses 95% CPU time, the rt thread will be
@@ -196,8 +175,7 @@ static int power_saving_thread(void *dat
 * borrow CPU time from this CPU and cause RT task use > 95%
 * CPU time. To make 'avoid starvation' work, takes a nap here.
 */
-   if (unlikely(do_sleep))
-   schedule_timeout_killable(HZ * idle_pct / 100);
+   schedule_timeout_killable(HZ * idle_pct / 100);
 
/* If an external event has set the need_resched flag, then
 * we need to deal with it, or this loop will continue to
> Thanks,
> Rafael
> 

Re: [PATCH][RFC] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[Yu Chen]

On Fri, May 04, 2018 at 04:08:42PM +0800, Chen Yu wrote:
> According to current implementation of acpi_pad driver,
> it does not make sense to spawn any power saving threads
> on the cpus which are already idle - it might bring
> unnecessary overhead on these idle cpus and causes power
> waste. So verify the condition that if the number of 'busy'
> cpus exceeds the amount of the 'forced idle' cpus - This is
> applicable due to round-robin attribute of the power saving
> threads, otherwise ignore the setting/ACPI notification.
> 
> Suggested-by: Lenny Szubowicz 
> Suggested-by: Len Brown 
> Cc: "Rafael J. Wysocki" 
> Cc: Jacob Pan 
> Cc: Rui Zhang 
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Chen Yu 
> ---
>
Please ignore this one, I'm sending out another version.
Thanks,
Yu

Re: [PATCH][RFC] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

[Yu Chen]

On Fri, May 04, 2018 at 04:08:42PM +0800, Chen Yu wrote:
> According to current implementation of acpi_pad driver,
> it does not make sense to spawn any power saving threads
> on the cpus which are already idle - it might bring
> unnecessary overhead on these idle cpus and causes power
> waste. So verify the condition that if the number of 'busy'
> cpus exceeds the amount of the 'forced idle' cpus - This is
> applicable due to round-robin attribute of the power saving
> threads, otherwise ignore the setting/ACPI notification.
> 
> Suggested-by: Lenny Szubowicz 
> Suggested-by: Len Brown 
> Cc: "Rafael J. Wysocki" 
> Cc: Jacob Pan 
> Cc: Rui Zhang 
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Chen Yu 
> ---
>
Please ignore this one, I'm sending out another version.
Thanks,
Yu

Re: [PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

[Yu Chen]

On Mon, Apr 23, 2018 at 10:48:39AM +0200, Rafael J. Wysocki wrote:
> On Saturday, April 14, 2018 6:10:55 AM CEST Yu Chen wrote:
> > From: Chen Yu <yu.c.c...@intel.com>
> > 
> > There's a use case during test to only print specific round of iterations
> > if --iterations is specified, for example, with this patch applied:
> > 
> > turbostat -i 5 -r 4
> > will capture 4 samples with 5 seconds interval.
> > 
> > Cc: Len Brown <l...@kernel.org>
> > Cc: Rafael J Wysocki <r...@rjwysocki.net>
> > Cc: Artem Bityutskiy <artem.bityuts...@intel.com>
> > Cc: Doug Smythies <dsmyth...@telus.net>
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Chen Yu <yu.c.c...@intel.com>
[cut]...
> > +   if (iterations && (++done_iters >= iterations))
> 
> The inner parens are not needed here (and similarly below).
> 
> If you fix this little one, please feel free to add
> 
> Reviewed-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> to the patch (FWIW). 
> 
OK, will do, thanks!
Yu

Re: [PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

[Yu Chen]

On Mon, Apr 23, 2018 at 10:48:39AM +0200, Rafael J. Wysocki wrote:
> On Saturday, April 14, 2018 6:10:55 AM CEST Yu Chen wrote:
> > From: Chen Yu 
> > 
> > There's a use case during test to only print specific round of iterations
> > if --iterations is specified, for example, with this patch applied:
> > 
> > turbostat -i 5 -r 4
> > will capture 4 samples with 5 seconds interval.
> > 
> > Cc: Len Brown 
> > Cc: Rafael J Wysocki 
> > Cc: Artem Bityutskiy 
> > Cc: Doug Smythies 
> > Cc: linux...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Chen Yu 
[cut]...
> > +   if (iterations && (++done_iters >= iterations))
> 
> The inner parens are not needed here (and similarly below).
> 
> If you fix this little one, please feel free to add
> 
> Reviewed-by: Rafael J. Wysocki 
> 
> to the patch (FWIW). 
> 
OK, will do, thanks!
Yu

[PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

[Yu Chen]

From: Chen Yu 

There's a use case during test to only print specific round of iterations
if --iterations is specified, for example, with this patch applied:

turbostat -i 5 -r 4
will capture 4 samples with 5 seconds interval.

Cc: Len Brown 
Cc: Rafael J Wysocki 
Cc: Artem Bityutskiy 
Cc: Doug Smythies 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu 
---
 tools/power/x86/turbostat/turbostat.8 |  2 ++
 tools/power/x86/turbostat/turbostat.c | 23 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.8 
b/tools/power/x86/turbostat/turbostat.8
index ccf2a69365cc..7452dc42273b 100644
--- a/tools/power/x86/turbostat/turbostat.8
+++ b/tools/power/x86/turbostat/turbostat.8
@@ -64,6 +64,8 @@ name as necessary to disambiguate it from others is 
necessary.  Note that option
 .PP
 \fB--interval seconds\fP overrides the default 5.0 second measurement interval.
 .PP
+\fB--iterations count\fP number of the measurement iterations.
+.PP
 \fB--out output_file\fP turbostat output is written to the specified 
output_file.
 The file is truncated if it already exists, and it is created if it does not 
exist.
 .PP
diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..ae9e3d08e3cf 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
 FILE *outf;
 int *fd_percpu;
 struct timespec interval_ts = {5, 0};
+int iterations;
 unsigned int debug;
 unsigned int quiet;
 unsigned int sums_need_wide_columns;
@@ -470,6 +471,7 @@ void help(void)
"   {core | package | j,k,l..m,n-p }\n"
"--quietskip decoding system configuration header\n"
"--interval sec Override default 5-second measurement interval\n"
+   "--iterations count number of the measurement iterations\n"
"--help print this help message\n"
"--list list column headers only\n"
"--out file create or truncate \"file\" for all output\n"
@@ -2565,6 +2567,7 @@ void turbostat_loop()
 {
int retval;
int restarted = 0;
+   int done_iters = 0;
 
 restart:
restarted++;
@@ -2581,6 +2584,7 @@ void turbostat_loop()
goto restart;
}
restarted = 0;
+   done_iters = 0;
gettimeofday(_even, (struct timezone *)NULL);
 
while (1) {
@@ -2607,6 +2611,10 @@ void turbostat_loop()
compute_average(EVEN_COUNTERS);
format_all_counters(EVEN_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
+
nanosleep(_ts, NULL);
if (snapshot_proc_sysfs_files())
goto restart;
@@ -2626,6 +2634,9 @@ void turbostat_loop()
compute_average(ODD_COUNTERS);
format_all_counters(ODD_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
}
 }
 
@@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
{"Dump",no_argument,0, 'D'},
{"debug",   no_argument,0, 'd'},/* 
internal, not documented */
{"interval",required_argument,  0, 'i'},
+   {"iterations",  required_argument,  0, 'r'},
{"help",no_argument,0, 'h'},
{"hide",required_argument,  0, 'H'},// meh, 
-h taken by --help
{"Joules",  no_argument,0, 'J'},
@@ -5014,7 +5026,7 @@ void cmdline(int argc, char **argv)
 
progname = argv[0];
 
-   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qST:v",
+   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qr:ST:v",
long_options, _index)) != -1) {
switch (opt) {
case 'a':
@@ -5063,6 +5075,15 @@ void cmdline(int argc, char **argv)
case 'q':
quiet = 1;
break;
+   case 'r':
+   iterations = strtod(optarg, NULL);
+
+   if (iterations <= 0) {
+   fprintf(outf, "iterations %d should be positive 
number\n",
+   iterations);
+   exit(2);
+   }
+   break;
case 's':
parse_show_hide(optarg, SHOW_LIST);
break;
-- 
2.13.6

[PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

[Yu Chen]

From: Chen Yu 

There's a use case during test to only print specific round of iterations
if --iterations is specified, for example, with this patch applied:

turbostat -i 5 -r 4
will capture 4 samples with 5 seconds interval.

Cc: Len Brown 
Cc: Rafael J Wysocki 
Cc: Artem Bityutskiy 
Cc: Doug Smythies 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu 
---
 tools/power/x86/turbostat/turbostat.8 |  2 ++
 tools/power/x86/turbostat/turbostat.c | 23 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.8 
b/tools/power/x86/turbostat/turbostat.8
index ccf2a69365cc..7452dc42273b 100644
--- a/tools/power/x86/turbostat/turbostat.8
+++ b/tools/power/x86/turbostat/turbostat.8
@@ -64,6 +64,8 @@ name as necessary to disambiguate it from others is 
necessary.  Note that option
 .PP
 \fB--interval seconds\fP overrides the default 5.0 second measurement interval.
 .PP
+\fB--iterations count\fP number of the measurement iterations.
+.PP
 \fB--out output_file\fP turbostat output is written to the specified 
output_file.
 The file is truncated if it already exists, and it is created if it does not 
exist.
 .PP
diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..ae9e3d08e3cf 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
 FILE *outf;
 int *fd_percpu;
 struct timespec interval_ts = {5, 0};
+int iterations;
 unsigned int debug;
 unsigned int quiet;
 unsigned int sums_need_wide_columns;
@@ -470,6 +471,7 @@ void help(void)
"   {core | package | j,k,l..m,n-p }\n"
"--quietskip decoding system configuration header\n"
"--interval sec Override default 5-second measurement interval\n"
+   "--iterations count number of the measurement iterations\n"
"--help print this help message\n"
"--list list column headers only\n"
"--out file create or truncate \"file\" for all output\n"
@@ -2565,6 +2567,7 @@ void turbostat_loop()
 {
int retval;
int restarted = 0;
+   int done_iters = 0;
 
 restart:
restarted++;
@@ -2581,6 +2584,7 @@ void turbostat_loop()
goto restart;
}
restarted = 0;
+   done_iters = 0;
gettimeofday(_even, (struct timezone *)NULL);
 
while (1) {
@@ -2607,6 +2611,10 @@ void turbostat_loop()
compute_average(EVEN_COUNTERS);
format_all_counters(EVEN_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
+
nanosleep(_ts, NULL);
if (snapshot_proc_sysfs_files())
goto restart;
@@ -2626,6 +2634,9 @@ void turbostat_loop()
compute_average(ODD_COUNTERS);
format_all_counters(ODD_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
}
 }
 
@@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
{"Dump",no_argument,0, 'D'},
{"debug",   no_argument,0, 'd'},/* 
internal, not documented */
{"interval",required_argument,  0, 'i'},
+   {"iterations",  required_argument,  0, 'r'},
{"help",no_argument,0, 'h'},
{"hide",required_argument,  0, 'H'},// meh, 
-h taken by --help
{"Joules",  no_argument,0, 'J'},
@@ -5014,7 +5026,7 @@ void cmdline(int argc, char **argv)
 
progname = argv[0];
 
-   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qST:v",
+   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qr:ST:v",
long_options, _index)) != -1) {
switch (opt) {
case 'a':
@@ -5063,6 +5075,15 @@ void cmdline(int argc, char **argv)
case 'q':
quiet = 1;
break;
+   case 'r':
+   iterations = strtod(optarg, NULL);
+
+   if (iterations <= 0) {
+   fprintf(outf, "iterations %d should be positive 
number\n",
+   iterations);
+   exit(2);
+   }
+   break;
case 's':
parse_show_hide(optarg, SHOW_LIST);
break;
-- 
2.13.6

[PATCH][v4] tools/power turbostat: if --iterations, print for specific time of iterations

[Yu Chen]

From: Chen Yu 

There's a use case during test to only print specific round of iterations
if --iterations is specified, for example, with this patch applied:

turbostat -i 5 -I 4
will capture 4 samples with 5 seconds interval.

Cc: Len Brown 
Cc: Rafael J Wysocki 
Cc: Artem Bityutskiy 
Cc: Doug Smythies 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu 
---
 tools/power/x86/turbostat/turbostat.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..a2fe96f038f0 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
 FILE *outf;
 int *fd_percpu;
 struct timespec interval_ts = {5, 0};
+int iterations;
 unsigned int debug;
 unsigned int quiet;
 unsigned int sums_need_wide_columns;
@@ -470,6 +471,7 @@ void help(void)
"   {core | package | j,k,l..m,n-p }\n"
"--quietskip decoding system configuration header\n"
"--interval sec Override default 5-second measurement interval\n"
+   "--iterations count Number of measurement iterations(requires 
'--interval'\n"
"--help print this help message\n"
"--list list column headers only\n"
"--out file create or truncate \"file\" for all output\n"
@@ -2565,6 +2567,7 @@ void turbostat_loop()
 {
int retval;
int restarted = 0;
+   int done_iters = 0;
 
 restart:
restarted++;
@@ -2581,6 +2584,7 @@ void turbostat_loop()
goto restart;
}
restarted = 0;
+   done_iters = 0;
gettimeofday(_even, (struct timezone *)NULL);
 
while (1) {
@@ -2607,6 +2611,10 @@ void turbostat_loop()
compute_average(EVEN_COUNTERS);
format_all_counters(EVEN_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
+
nanosleep(_ts, NULL);
if (snapshot_proc_sysfs_files())
goto restart;
@@ -2626,6 +2634,9 @@ void turbostat_loop()
compute_average(ODD_COUNTERS);
format_all_counters(ODD_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
}
 }
 
@@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
{"Dump",no_argument,0, 'D'},
{"debug",   no_argument,0, 'd'},/* 
internal, not documented */
{"interval",required_argument,  0, 'i'},
+   {"iterations",  required_argument,  0, 'I'},
{"help",no_argument,0, 'h'},
{"hide",required_argument,  0, 'H'},// meh, 
-h taken by --help
{"Joules",  no_argument,0, 'J'},
@@ -5014,7 +5026,7 @@ void cmdline(int argc, char **argv)
 
progname = argv[0];
 
-   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qST:v",
+   while ((opt = getopt_long_only(argc, argv, "+C:c:DdhI:i:JM:m:o:qST:v",
long_options, _index)) != -1) {
switch (opt) {
case 'a':
@@ -5036,6 +5048,15 @@ void cmdline(int argc, char **argv)
default:
help();
exit(1);
+   case 'I':
+   iterations = strtod(optarg, NULL);
+
+   if (iterations <= 0) {
+   fprintf(outf, "iterations %d should be positive 
number\n",
+   iterations);
+   exit(2);
+   }
+   break;
case 'i':
{
double interval = strtod(optarg, NULL);
-- 
2.13.6

[PATCH][v4] tools/power turbostat: if --iterations, print for specific time of iterations

[Yu Chen]

From: Chen Yu 

There's a use case during test to only print specific round of iterations
if --iterations is specified, for example, with this patch applied:

turbostat -i 5 -I 4
will capture 4 samples with 5 seconds interval.

Cc: Len Brown 
Cc: Rafael J Wysocki 
Cc: Artem Bityutskiy 
Cc: Doug Smythies 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu 
---
 tools/power/x86/turbostat/turbostat.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..a2fe96f038f0 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
 FILE *outf;
 int *fd_percpu;
 struct timespec interval_ts = {5, 0};
+int iterations;
 unsigned int debug;
 unsigned int quiet;
 unsigned int sums_need_wide_columns;
@@ -470,6 +471,7 @@ void help(void)
"   {core | package | j,k,l..m,n-p }\n"
"--quietskip decoding system configuration header\n"
"--interval sec Override default 5-second measurement interval\n"
+   "--iterations count Number of measurement iterations(requires 
'--interval'\n"
"--help print this help message\n"
"--list list column headers only\n"
"--out file create or truncate \"file\" for all output\n"
@@ -2565,6 +2567,7 @@ void turbostat_loop()
 {
int retval;
int restarted = 0;
+   int done_iters = 0;
 
 restart:
restarted++;
@@ -2581,6 +2584,7 @@ void turbostat_loop()
goto restart;
}
restarted = 0;
+   done_iters = 0;
gettimeofday(_even, (struct timezone *)NULL);
 
while (1) {
@@ -2607,6 +2611,10 @@ void turbostat_loop()
compute_average(EVEN_COUNTERS);
format_all_counters(EVEN_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
+
nanosleep(_ts, NULL);
if (snapshot_proc_sysfs_files())
goto restart;
@@ -2626,6 +2634,9 @@ void turbostat_loop()
compute_average(ODD_COUNTERS);
format_all_counters(ODD_COUNTERS);
flush_output_stdout();
+
+   if (iterations && (++done_iters >= iterations))
+   break;
}
 }
 
@@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
{"Dump",no_argument,0, 'D'},
{"debug",   no_argument,0, 'd'},/* 
internal, not documented */
{"interval",required_argument,  0, 'i'},
+   {"iterations",  required_argument,  0, 'I'},
{"help",no_argument,0, 'h'},
{"hide",required_argument,  0, 'H'},// meh, 
-h taken by --help
{"Joules",  no_argument,0, 'J'},
@@ -5014,7 +5026,7 @@ void cmdline(int argc, char **argv)
 
progname = argv[0];
 
-   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qST:v",
+   while ((opt = getopt_long_only(argc, argv, "+C:c:DdhI:i:JM:m:o:qST:v",
long_options, _index)) != -1) {
switch (opt) {
case 'a':
@@ -5036,6 +5048,15 @@ void cmdline(int argc, char **argv)
default:
help();
exit(1);
+   case 'I':
+   iterations = strtod(optarg, NULL);
+
+   if (iterations <= 0) {
+   fprintf(outf, "iterations %d should be positive 
number\n",
+   iterations);
+   exit(2);
+   }
+   break;
case 'i':
{
double interval = strtod(optarg, NULL);
-- 
2.13.6

Re: [PATCH][v3] tools/power turbostat: if --max_loop, print for specific time of loops

[Yu Chen]

Hi Doug,
On Thu, Apr 12, 2018 at 12:18:44AM -0700, Doug Smythies wrote:
> On 2018.04.11 03:31 Yu Chen wrote: 
> 
> > From: Chen Yu <yu.c.c...@intel.com>
> >
> > There's a use case during test to only print specific round of loops
> > if --iterations is specified, for example, with this patch applied:
> >
> > turbostat -i 5 -t 4
> > will capture 4 samples with 5 seconds interval.
> 
> Hi Yu,
> 
> This would be a very useful addition to turbostat.
> Please also update the man turbostat man page.
> 
> tools/power/x86/turbostat/turbostat.8
> 
OK, I will do this.
Thanks,
Yu
> ... Doug
> 
> 

Re: [PATCH][v3] tools/power turbostat: if --max_loop, print for specific time of loops

[Yu Chen]

Hi Doug,
On Thu, Apr 12, 2018 at 12:18:44AM -0700, Doug Smythies wrote:
> On 2018.04.11 03:31 Yu Chen wrote: 
> 
> > From: Chen Yu 
> >
> > There's a use case during test to only print specific round of loops
> > if --iterations is specified, for example, with this patch applied:
> >
> > turbostat -i 5 -t 4
> > will capture 4 samples with 5 seconds interval.
> 
> Hi Yu,
> 
> This would be a very useful addition to turbostat.
> Please also update the man turbostat man page.
> 
> tools/power/x86/turbostat/turbostat.8
> 
OK, I will do this.
Thanks,
Yu
> ... Doug
> 
> 

Re: [PATCH][v3] tools/power turbostat: if --max_loop, print for specific time of loops

[Yu Chen]

Hi,
On Wed, Apr 11, 2018 at 02:02:02PM +0300, Artem Bityutskiy wrote:
> A couple of nitpicks.
> 
> On Wed, 2018-04-11 at 18:30 +0800, Yu Chen wrote:
> > @@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
> >  FILE *outf;
> >  int *fd_percpu;
> >  struct timespec interval_ts = {5, 0};
> > +int iterations;
> 
> OK, out of several choices, you selected "iterations".
> 
> >  unsigned int debug;
> >  unsigned int quiet;
> >  unsigned int sums_need_wide_columns;
> > @@ -470,6 +471,7 @@ void help(void)
> > "   {core | package | j,k,l..m,n-p }\n"
> > "--quietskip decoding system configuration header\n"
> > "--interval sec Override default 5-second measurement interval\n"
> > +   "--iterations loops The number of loops if interval is specified\n"
> 
> Since "iterations" is the term, be consistent and do not mix it with
> "loops". Who knows may be the "loops" term will be used for something
> else in the future. Use something like this:
> 
> "--iterations countNumber of measurement iterations (requires '
> --interval')"
>
OK, this looks more consistent.
> > print this help mkk
> > "--list list column headers only\n"
> > "--out file create or truncate \"file\" for all output\n"
> > @@ -2565,6 +2567,7 @@ void turbostat_loop()
> >  {
> > int retval;
> > int restarted = 0;
> > +   int loops = 0;
> 
> Please, name variables in a consistent manner, this should really be
> something like 'int iters = 0'. Or may be 'done_iters', or something.
> But not "loops".
> 
OK.
> > @@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
> > {"Dump",no_argument,0, 'D'},
> > {"debug",   no_argument,0, 'd'},/* 
> > internal, not documented */
> > {"interval",required_argument,  0, 'i'},
> > +   {"iterations",  required_argument,  0, 't'},
> 
> If you used term "count", you could have consistent long and short
> option names, like '--count / -c'. I find '--iterations / -t' to be
> inconsistent, and harder to remember the short option, because I think
> about time, not "iterations" when I see -t.
However the '-c' is already used as a short form for '--cpu',
so I chose --iterations previously.

Thanks,
Yu

Re: [PATCH][v3] tools/power turbostat: if --max_loop, print for specific time of loops

[Yu Chen]

Hi,
On Wed, Apr 11, 2018 at 02:02:02PM +0300, Artem Bityutskiy wrote:
> A couple of nitpicks.
> 
> On Wed, 2018-04-11 at 18:30 +0800, Yu Chen wrote:
> > @@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
> >  FILE *outf;
> >  int *fd_percpu;
> >  struct timespec interval_ts = {5, 0};
> > +int iterations;
> 
> OK, out of several choices, you selected "iterations".
> 
> >  unsigned int debug;
> >  unsigned int quiet;
> >  unsigned int sums_need_wide_columns;
> > @@ -470,6 +471,7 @@ void help(void)
> > "   {core | package | j,k,l..m,n-p }\n"
> > "--quietskip decoding system configuration header\n"
> > "--interval sec Override default 5-second measurement interval\n"
> > +   "--iterations loops The number of loops if interval is specified\n"
> 
> Since "iterations" is the term, be consistent and do not mix it with
> "loops". Who knows may be the "loops" term will be used for something
> else in the future. Use something like this:
> 
> "--iterations countNumber of measurement iterations (requires '
> --interval')"
>
OK, this looks more consistent.
> > print this help mkk
> > "--list list column headers only\n"
> > "--out file create or truncate \"file\" for all output\n"
> > @@ -2565,6 +2567,7 @@ void turbostat_loop()
> >  {
> > int retval;
> > int restarted = 0;
> > +   int loops = 0;
> 
> Please, name variables in a consistent manner, this should really be
> something like 'int iters = 0'. Or may be 'done_iters', or something.
> But not "loops".
> 
OK.
> > @@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
> > {"Dump",no_argument,0, 'D'},
> > {"debug",   no_argument,0, 'd'},/* 
> > internal, not documented */
> > {"interval",required_argument,  0, 'i'},
> > +   {"iterations",  required_argument,  0, 't'},
> 
> If you used term "count", you could have consistent long and short
> option names, like '--count / -c'. I find '--iterations / -t' to be
> inconsistent, and harder to remember the short option, because I think
> about time, not "iterations" when I see -t.
However the '-c' is already used as a short form for '--cpu',
so I chose --iterations previously.

Thanks,
Yu