[PATCH v5 2/2] phy: Add USB3 PHY support for Intel LGM SoC

2020-07-13 Thread Ramuthevar,Vadivel MuruganX
From: Ramuthevar Vadivel Murugan 

Add support for USB PHY on Intel LGM SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Philipp Zabel 
---
 drivers/phy/Kconfig   |  11 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-lgm-usb.c | 278 ++
 3 files changed, 290 insertions(+)
 create mode 100644 drivers/phy/phy-lgm-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b3ed94b98d9b..43ff5943f513 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -49,6 +49,17 @@ config PHY_XGENE
help
  This option enables support for APM X-Gene SoC multi-purpose PHY.
 
+config USB_LGM_PHY
+   tristate "INTEL Lightning Mountain USB PHY Driver"
+   depends on USB_SUPPORT
+   select USB_PHY
+   select REGULATOR
+   select REGULATOR_FIXED_VOLTAGE
+   help
+ Enable this to support Intel DWC3 PHY USB phy. This driver provides
+ interface to interact with USB GEN-II and USB 3.x PHY that is part
+ of the Intel network SOC.
+
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 310c149a9df5..c2cd6d756f5f 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)  += phy-lpc18xx-usb-otg.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
+obj-$(CONFIG_USB_LGM_PHY)  += phy-lgm-usb.o
 obj-$(CONFIG_ARCH_SUNXI)   += allwinner/
 obj-$(CONFIG_ARCH_MESON)   += amlogic/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
diff --git a/drivers/phy/phy-lgm-usb.c b/drivers/phy/phy-lgm-usb.c
new file mode 100644
index ..1ec9ab266e08
--- /dev/null
+++ b/drivers/phy/phy-lgm-usb.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel LGM USB PHY driver
+ *
+ * Copyright (C) 2020 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CTRL1_OFFSET   0x14
+#define SRAM_EXT_LD_DONE   BIT(25)
+#define SRAM_INIT_DONE BIT(26)
+
+#define TCPC_OFFSET0x1014
+#define TCPC_MUX_CTL   GENMASK(1, 0)
+#define MUX_NC 0
+#define MUX_USB1
+#define MUX_DP 2
+#define MUX_USBDP  3
+#define TCPC_FLIPPED   BIT(2)
+#define TCPC_LOW_POWER_EN  BIT(3)
+#define TCPC_VALID BIT(4)
+#define TCPC_CONN  \
+   (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_USB))
+#define TCPC_DISCONN   \
+   (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_NC) | TCPC_LOW_POWER_EN)
+
+static const char *const PHY_RESETS[] = { "phy31", "phy", };
+static const char *const CTL_RESETS[] = { "apb", "ctrl", };
+
+struct tca_apb {
+   struct reset_control *resets[ARRAY_SIZE(PHY_RESETS)];
+   struct regulator *vbus;
+   struct work_struct wk;
+   struct usb_phy phy;
+
+   bool phy_initialized;
+   bool connected;
+};
+
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+   union extcon_property_value property;
+   int ret;
+
+   ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+   if (ret) {
+   dev_err(ta->phy.dev, "no polarity property from extcon\n");
+   return ret;
+   }
+
+   *flipped = property.intval;
+
+   return ret;
+}
+
+static int phy_init(struct usb_phy *phy)
+{
+   struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+   void __iomem *ctrl1 = phy->io_priv + CTRL1_OFFSET;
+   int val, ret, i;
+
+   if (ta->phy_initialized)
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+   reset_control_deassert(ta->resets[i]);
+
+   ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE, 10, 10 * 
1000);
+   if (ret) {
+   dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
+   return ret;
+   }
+
+   writel(readl(ctrl1) | SRAM_EXT_LD_DONE, ctrl1);
+
+   ta->phy_initialized = true;
+   if (!ta->phy.edev) {
+   writel(TCPC_CONN, ta->phy.io_priv + TCPC_OFFSET);
+   return phy->set_vbus(phy, true);
+   }
+
+   schedule_work(>wk);
+
+   return ret;
+}
+
+static void phy_shutdown(struct usb_phy *phy)
+{
+   struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+   int i;
+
+   if (!ta->phy_initialized)
+   return;
+
+   ta->phy_initialized = false;
+   flush_work(>wk);
+   ta->phy.set_vbus(>phy, false);
+
+   ta->connected = false;
+   writel(TCPC_DISCONN, ta->phy.io_priv 

[PATCH v5 0/2] usb : phy: Add USB PHY support on Intel LGM SoC

2020-07-13 Thread Ramuthevar,Vadivel MuruganX
The USB PHY provides the optimized for low power dissipation while active, 
idle, or on standby.
Requires minimal external components, a single resistor, for best operation.
Supports 10/5-Gbps high-speed data transmission rates through 3-m USB 3.x cable
---
v5:
  - As per Felipe and Greg's suggestion usb phy driver reviewed patches
changed the folder from drivers/usb/phy to drivers/phy
  - Reviewed-By tag added in commit message
v4:
  - Andy's review comments addressed
  - drop the excess error debug prints
  - error check optimized
  - merge the split line to one line
v3:
  - Andy's review comments update
  - hardcode return value changed to actual return value from the callee
  - add error check is fixed according to the above
  - correct the assignment in redundant
  - combine the split line into one line
v2:
  - Address Phillip's review comments
  - replace devm_reset_control_get() by devm_reset_control_get_exclusive()
  - re-design the assert and deassert fucntion calls as per review comments
  - address kbuild bot warnings
  - add the comments
v1:
  - initial version

---
dt-bindings: usb: Add USB PHY support for Intel LGM SoC
v5:
  - Reviewed-By tag added
v4:
  - No Change
v3:
  - No Change
v2:
  - No Change
v1:
  - initial version
 

Ramuthevar Vadivel Murugan (2):
  dt-bindings: phy: Add USB PHY support for Intel LGM SoC
  phy: Add USB3 PHY support for Intel LGM SoC

 .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml |  53 
 drivers/phy/Kconfig|  11 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-lgm-usb.c  | 278 +
 4 files changed, 343 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
 create mode 100644 drivers/phy/phy-lgm-usb.c

-- 
2.11.0



Re: BUG: soft lockup in smp_call_function

2020-07-13 Thread syzbot
syzbot has found a reproducer for the following crash on:

HEAD commit:4437dd6e Merge tag 'io_uring-5.8-2020-07-12' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15998b4710
kernel config:  https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=cce3691658bef1b12ac9
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11a160bf10
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16d2bd7710

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cce3691658bef1b12...@syzkaller.appspotmail.com

watchdog: BUG: soft lockup - CPU#1 stuck for 123s! [syz-executor644:6902]
Modules linked in:
irq event stamp: 173384
hardirqs last  enabled at (173383): [] 
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
hardirqs last disabled at (173384): [] 
idtentry_enter_cond_rcu+0x1d/0x50 arch/x86/entry/common.c:649
softirqs last  enabled at (172872): [] 
__do_softirq+0x748/0xa60 kernel/softirq.c:319
softirqs last disabled at (172863): [] 
asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711
CPU: 1 PID: 6902 Comm: syz-executor644 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:csd_lock_wait kernel/smp.c:108 [inline]
RIP: 0010:smp_call_function_single+0x192/0x4f0 kernel/smp.c:382
Code: 10 8b 7c 24 1c 48 8d 74 24 40 48 89 44 24 50 48 8b 44 24 08 48 89 44 24 
58 e8 fa f9 ff ff 41 89 c5 eb 07 e8 90 00 0b 00 f3 90 <44> 8b 64 24 48 31 ff 41 
83 e4 01 44 89 e6 e8 fb fc 0a 00 45 85 e4
RSP: 0018:c900023a7a60 EFLAGS: 0293
RAX:  RBX: 192000474f50 RCX: 8168b985
RDX: 8880955564c0 RSI: 8168b970 RDI: 0005
RBP: c900023a7b28 R08: 0001 R09: 8880ae636dc7
R10:  R11:  R12: 0001
R13:  R14: 0001 R15: 0040
FS:  () GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004c8aa8 CR3: 09a79000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 smp_call_function_many_cond+0x1a4/0x990 kernel/smp.c:518
 __flush_tlb_others arch/x86/include/asm/paravirt.h:74 [inline]
 flush_tlb_others arch/x86/mm/tlb.c:856 [inline]
 flush_tlb_mm_range+0x295/0x4d0 arch/x86/mm/tlb.c:943
 tlb_flush arch/x86/include/asm/tlb.h:24 [inline]
 tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:425 [inline]
 tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:415 [inline]
 tlb_flush_mmu mm/mmu_gather.c:248 [inline]
 tlb_finish_mmu+0x3e7/0x8c0 mm/mmu_gather.c:328
 exit_mmap+0x2d1/0x510 mm/mmap.c:3152
 __mmput+0x122/0x470 kernel/fork.c:1093
 mmput+0x53/0x60 kernel/fork.c:1114
 exit_mm kernel/exit.c:482 [inline]
 do_exit+0xa8f/0x2a40 kernel/exit.c:792
 do_group_exit+0x125/0x310 kernel/exit.c:903
 __do_sys_exit_group kernel/exit.c:914 [inline]
 __se_sys_exit_group kernel/exit.c:912 [inline]
 __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:912
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x442478
Code: Bad RIP value.
RSP: 002b:7ffeb3621f28 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX: 0001 RCX: 00442478
RDX: 0001 RSI: 003c RDI: 0001
RBP: 004c8a70 R08: 00e7 R09: ffd0
R10: 01bb R11: 0246 R12: 0001
R13: 006dba40 R14:  R15: 
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 7110 Comm: kworker/0:0 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: wg-crypt-wg1 wg_packet_tx_worker
RIP: 0010:__lock_is_held kernel/locking/lockdep.c:4733 [inline]
RIP: 0010:lock_is_held_type+0x72/0xe0 kernel/locking/lockdep.c:4996
Code: 00 00 85 c0 7f 0d eb 72 83 c3 01 3b 9d c8 08 00 00 7d 67 48 63 c3 4c 89 
e6 48 8d 04 80 4d 8d 74 c5 00 4c 89 f7 e8 1e fe ff ff <85> c0 74 da 8b 4c 24 04 
41 bc 01 00 00 00 83 f9 ff 74 11 41 0f b6
RSP: 0018:c9007d38 EFLAGS: 0046
RAX: 0001 RBX: 0006 RCX: 86626577
RDX: dc00 RSI: 888093ce4300 RDI: 888094a20c00
RBP: 888094a20240 R08: 0001 R09: 0003
R10:  R11:  R12: 888093ce4300
R13: 888094a20b10 R14: 888094a20c00 R15: 0082
FS:  () GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2610 CR3: 9e49a000 CR4: 

[PATCH 1/1] platform/x86: revert pcengines-apuv2 wire up simswitch gpio as led

2020-07-13 Thread Florian Eckert
This reverts commit 5037d4ddda31c2dbbb018109655f61054b1756dc.

Explanation why this does not work:
This change connects the simswap to the LED subsystem of the kernel.
>From my point of view, it's nonsense. If we do it this way, then this
can be switched relatively easily via the LED subsystem (trigger:
none/default-on) and that is dangerous! If this is used, it would be
unfavorable, since there is also another trigger (trigger:
heartbeat/netdev).

Therefore, this simswap GPIO should remain in the GPIO
subsystem and be switched via it and not be connected to the LED
subsystem. To avoid the problems mentioned above. The LED subsystem is
not made for this and it is not a good compromise, but rather dangerous.

Signed-off-by: Florian Eckert 
---
 drivers/platform/x86/pcengines-apuv2.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/platform/x86/pcengines-apuv2.c 
b/drivers/platform/x86/pcengines-apuv2.c
index 9b11ef1a401f..6aff6cf41414 100644
--- a/drivers/platform/x86/pcengines-apuv2.c
+++ b/drivers/platform/x86/pcengines-apuv2.c
@@ -78,7 +78,6 @@ static const struct gpio_led apu2_leds[] = {
{ .name = "apu:green:1" },
{ .name = "apu:green:2" },
{ .name = "apu:green:3" },
-   { .name = "apu:simswap" },
 };
 
 static const struct gpio_led_platform_data apu2_leds_pdata = {
@@ -95,8 +94,6 @@ static struct gpiod_lookup_table gpios_led_table = {
NULL, 1, GPIO_ACTIVE_LOW),
GPIO_LOOKUP_IDX(AMD_FCH_GPIO_DRIVER_NAME, APU2_GPIO_LINE_LED3,
NULL, 2, GPIO_ACTIVE_LOW),
-   GPIO_LOOKUP_IDX(AMD_FCH_GPIO_DRIVER_NAME, 
APU2_GPIO_LINE_SIMSWAP,
-   NULL, 3, GPIO_ACTIVE_LOW),
}
 };
 
-- 
2.20.1



Re: [PATCH v1 8/8] watchdog: f71808e_wdt: rename variant-independent identifiers appropriately

2020-07-13 Thread Ahmad Fatoum



On 6/30/20 11:29 PM, Guenter Roeck wrote:
> On Thu, Jun 11, 2020 at 09:17:49PM +0200, Ahmad Fatoum wrote:
>> Code for the common parts of the driver, either uses watchdog_ as
>> prefix for the watchdog API or f71808e_ for everything else.
>>
>> The driver now supports 9 more variants besides the f71808e,
>> so let's rename the common parts to start with fintek_ instead.
>>
>> This makes code browsing easier, because it's readily apparent whether a
>> function is variant-specific or not. Also the watchdog_ namespace isn't
>> used anymore for the driver-internal functions.
>>
>> Signed-off-by: Ahmad Fatoum 
>> Reported-by: kernel test robot 
>> ---
>>  drivers/watchdog/f71808e_wdt.c | 98 +-
>>  1 file changed, 49 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/watchdog/f71808e_wdt.c b/drivers/watchdog/f71808e_wdt.c
>> index 7c42cbf9912e..c866d05e8788 100644
>> --- a/drivers/watchdog/f71808e_wdt.c
>> +++ b/drivers/watchdog/f71808e_wdt.c
>> @@ -114,18 +114,18 @@ static inline int superio_enter(int base);
>>  static inline void superio_select(int base, int ld);
>>  static inline void superio_exit(int base);
>>  
>> -struct watchdog_data;
>> +struct fintek_wdog_data;
>>  
>> -struct f71808e_variant {
>> +struct fintek_variant {
>>  u16 id;
>>  const char *wdt_name; /* NULL if chip lacks watchdog timer */
>> -void (*pinconf)(struct watchdog_data *wd);
>> +void (*pinconf)(struct fintek_wdog_data *wd);
>>  };
>>  
>> -struct watchdog_data {
>> +struct fintek_wdog_data {
>>  struct watchdog_device wdd;
>>  unsigned short  sioaddr;
>> -const struct f71808e_variant *variant;
>> +const struct fintek_variant *variant;
>>  struct watchdog_info ident;
>>  
>>  u8  timer_val;  /* content for the wd_time register */
>> @@ -134,7 +134,7 @@ struct watchdog_data {
>>  charpulse_mode; /* enable pulse output mode? */
>>  };
>>  
>> -static inline bool has_f81865_wdo_conf(struct watchdog_data *wd)
>> +static inline bool has_f81865_wdo_conf(struct fintek_wdog_data *wd)
>>  {
>>  return wd->variant->id == SIO_F81865_ID
>>  || wd->variant->id == SIO_F81866_ID;
>> @@ -202,9 +202,9 @@ static inline void superio_exit(int base)
>>  release_region(base, 2);
>>  }
>>  
>> -static int watchdog_set_timeout(struct watchdog_device *wdd, unsigned int 
>> new_timeout)
>> +static int fintek_wdog_set_timeout(struct watchdog_device *wdd, unsigned 
>> int new_timeout)
>>  {
>> -struct watchdog_data *wd = watchdog_get_drvdata(wdd);
>> +struct fintek_wdog_data *wd = watchdog_get_drvdata(wdd);
>>  
>>  wdd->timeout = new_timeout;
>>  if (new_timeout > 0xff) {
>> @@ -218,7 +218,7 @@ static int watchdog_set_timeout(struct watchdog_device 
>> *wdd, unsigned int new_ti
>>  return 0;
>>  }
>>  
>> -static int watchdog_set_pulse_width(struct watchdog_data *wd, unsigned int 
>> pw)
>> +static int fintek_wdog_set_pulse_width(struct fintek_wdog_data *wd, 
>> unsigned int pw)
>>  {
>>  unsigned int t1 = 25, t2 = 125, t3 = 5000;
>>  
>> @@ -246,9 +246,9 @@ static int watchdog_set_pulse_width(struct watchdog_data 
>> *wd, unsigned int pw)
>>  return 0;
>>  }
>>  
>> -static int watchdog_keepalive(struct watchdog_device *wdd)
>> +static int fintek_wdog_keepalive(struct watchdog_device *wdd)
>>  {
>> -struct watchdog_data *wd = watchdog_get_drvdata(wdd);
>> +struct fintek_wdog_data *wd = watchdog_get_drvdata(wdd);
>>  int err;
>>  
>>  err = superio_enter(wd->sioaddr);
>> @@ -274,13 +274,13 @@ static int watchdog_keepalive(struct watchdog_device 
>> *wdd)
>>  return 0;
>>  }
>>  
>> -static int watchdog_start(struct watchdog_device *wdd)
>> +static int fintek_wdog_start(struct watchdog_device *wdd)
>>  {
>> -struct watchdog_data *wd = watchdog_get_drvdata(wdd);
>> +struct fintek_wdog_data *wd = watchdog_get_drvdata(wdd);
>>  int err;
>>  
>>  /* Make sure we don't die as soon as the watchdog is enabled below */
>> -err = watchdog_keepalive(wdd);
>> +err = fintek_wdog_keepalive(wdd);
>>  if (err)
>>  return err;
>>  
>> @@ -328,9 +328,9 @@ static int watchdog_start(struct watchdog_device *wdd)
>>  return err;
>>  }
>>  
>> -static int watchdog_stop(struct watchdog_device *wdd)
>> +static int fintek_wdog_stop(struct watchdog_device *wdd)
>>  {
>> -struct watchdog_data *wd = watchdog_get_drvdata(wdd);
>> +struct fintek_wdog_data *wd = watchdog_get_drvdata(wdd);
>>  int err;
>>  
>>  err = superio_enter(wd->sioaddr);
>> @@ -346,21 +346,21 @@ static int watchdog_stop(struct watchdog_device *wdd)
>>  return 0;
>>  }
>>  
>> -static const struct watchdog_ops f71808e_wdog_ops = {
>> +static const struct watchdog_ops fintek_wdog_ops = {
>>  .owner = THIS_MODULE,
>> -.start = watchdog_start,
>> -.stop = watchdog_stop,
>> -.ping = watchdog_keepalive,
>> -.set_timeout = watchdog_set_timeout,
>> +.start = 

Re: [PATCH 1/3] ARM: dts: colibri-imx6: remove pinctrl-names orphan

2020-07-13 Thread Shawn Guo
On Fri, Jul 10, 2020 at 03:24:21PM +0200, Philippe Schenker wrote:
> This is not necessary without a pinctrl-0 statement. Remove this
> orphan.
> 
> Signed-off-by: Philippe Schenker 

Applied all, thanks.


[PATCH] [NET] AX.25 Kconfig: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 net/ax25/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ax25/Kconfig b/net/ax25/Kconfig
index 97d686d115c0..d3a9843a043d 100644
--- a/net/ax25/Kconfig
+++ b/net/ax25/Kconfig
@@ -8,7 +8,7 @@ menuconfig HAMRADIO
bool "Amateur Radio support"
help
  If you want to connect your Linux box to an amateur radio, answer Y
- here. You want to read 
+ here. You want to read 
  and more specifically about AX.25 on Linux
  .
 
@@ -39,11 +39,11 @@ config AX25
  Information about where to get supporting software for Linux amateur
  radio as well as information about how to configure an AX.25 port is
  contained in the AX25-HOWTO, available from
- . You might also want to
+ . You might also want to
  check out the file  in the
  kernel source. More information about digital amateur radio in
  general is on the WWW at
- .
+ .
 
  To compile this driver as a module, choose M here: the
  module will be called ax25.
@@ -90,7 +90,7 @@ config NETROM
  . You also might want to check out the
  file . More information about
  digital amateur radio in general is on the WWW at
- .
+ .
 
  To compile this driver as a module, choose M here: the
  module will be called netrom.
@@ -109,7 +109,7 @@ config ROSE
  .  You also might want to check out the
  file . More information about
  digital amateur radio in general is on the WWW at
- .
+ .
 
  To compile this driver as a module, choose M here: the
  module will be called rose.
-- 
2.27.0



Re: [5.8RC4][bugreport]WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree_insert+0xaf/0xc0 [fuse]

2020-07-13 Thread Vasily Averin
On 7/13/20 11:02 AM, Mikhail Gavrilov wrote:
> On Mon, 13 Jul 2020 at 12:11, Mikhail Gavrilov
>  wrote:
>>
>> On Mon, 13 Jul 2020 at 03:28, Mikhail Gavrilov
>>  wrote:
>>>
>>> Hi folks.
>>> While testing 5.8 RCs I founded that kernel log flooded by the message
>>> "WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree
>>> insert+0xaf/0xc0 [fuse]" when I start podman container.
>>> In kernel 5.7 not has such a problem.
>>
>> Maxim, I suppose you leave `WARN_ON(!wpa->ia.ap.num_pages);` for debug 
>> purpose?
>> Now this line is often called when I start the container.
>>
> 
> That odd, but I can't send an email to the author of the commit.
> mpatlasov wasn't found at virtuozzo.com.

Reported problem is not fixed yet in 5.8-rc kernels
Please take look at
https://lkml.org/lkml/2020/7/13/265

Thank you,
Vasily Averin


Re: [PATCH v4 2/2] Add Intel LGM soc DMA support.

2020-07-13 Thread Andy Shevchenko
On Mon, Jul 13, 2020 at 04:41:31PM +0800, Reddy, MallikarjunaX wrote:
> On 7/9/2020 7:09 PM, Andy Shevchenko wrote:
> > On Thu, Jul 09, 2020 at 02:01:06PM +0800, Amireddy Mallikarjuna reddy wrote:
> > > Add DMA controller driver for Lightning Mountain(LGM) family of SoCs.
> > > 
> > > The main function of the DMA controller is the transfer of data from/to 
> > > any
> > > DPlus compliant peripheral to/from the memory. A memory to memory copy
> > > capability can also be configured.
> > > 
> > > This ldma driver is used for configure the device and channnels for data
> > > and control paths.
> > > +#include "../virt-dma.h"
> > I didn't find any evidence this driver utilizes virt-dma API in full.
> > For example, there is a virt_dma_desc structure and descriptor management 
> > around it.
> > Why don't you use it?
> Lgm dma soc has its own hardware descriptor.
> and each dma channel is associated with a peripheral, it is one to one
> mapping between channel and associated peripheral.

And this neither objects nor answers to my question.

Hint: above mentioned structure is an abstraction of hardware descriptors for
easier management in Linux kernel.

-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH v5 10/10] arm64: dts: actions: Add uSD support for Cubieboard7

2020-07-13 Thread Amit Tomer
Hi,

> But this regulator is only used for the eMMC there, which we apparently
> don't have on the Cubieboard 7?

We do have eMMC present on Cubieboard 7 (both the versions of Cubieboard7), and
the regulator name is similar to what is used in
"s900-bubblegum-96.dts" .i.e. "vcc_3v1".

But Since this patch doesn't enable eMMC, it does make sense to remove this
"vcc_3v1" regulator and keep the other one.

> > Also, another day tested it without having these regulators in , and
> > still it seems to
> > work.  So should these be removed ?
>
> If there are not even referenced in the .dts, then fixed regulators are
> rather pointless. So yes, please remove this vcc-3v1 one.

Sure, I would do this.

> What is the story with the other regulator? Is there a PMIC or a power
> switch for the SD card? Or is the power supply actually hardwired?

SD_VCC is connected to SWITCH/LDO which gets input from ATM2603C PMIC.
This seems to be enabled by default ( in early bootloaders I guess).

Thanks
-Amit.


Re: [PATCH] Input: break joystick limitation of maximum 80 buttons

2020-07-13 Thread Andy Shevchenko
On Sun, Jul 12, 2020 at 07:54:54AM +0800, Wei Shuai wrote:
> The joystick max buttons 80 limitation comes from
> 
> #define BTN_JOYSTICK 0x120
> #define BTN_DEAD 0x12f
> #define BTN_TRIGGER_HAPPY 0x2c0
> #define KEY_MAX 0x2ff
> 
> include/uapi/linux/input-event-codes.h
> 
> according to function hidinput_configure_usage() in file 
> drivers/hid/hid-input.c
> 
> the joystick button mapping is not a continues space
> generally speaking, the mapping space is from
> 
> 1. BTN_JOYSTICK~BTN_DEAD
> 2. BTN_TRIGGER_HAPPY~KEY_MAX
> 
> Finally, I got the max limitation is 80.
> The patch is expanding KEY_MAX from 0x2ff to 4ff
> and the change has been verified on 104 button USB HID device on Ubuntu


If you send and resend this patch too often, nobody will take you seriously.
Also, you have to provide versioning and changelog in each submission.
Besides that, above doesn't answer to question "why?". Why are you doing this
at all? What the problem?


-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH v4] ARM: dts: vfxxx: Add node for CAAM

2020-07-13 Thread Shawn Guo
On Fri, Jul 10, 2020 at 07:02:45PM -0700, Chris Healy wrote:
> From: Andrey Smirnov  
> 
> Add node for CAAM device in NXP Vybrid SoC.
> 
> Signed-off-by: Andrey Smirnov 
> Signed-off-by: Chris Healy 
> Reviewed-by: Fabio Estevam 
> ---
> v4:
> - really add reviewed by from Fabio Estevam
> v3:
> - put version information in the correct place
> - add reviewed by from Fabio Estevam

I have picked up v2 with all these fixed up.

Shawn


Re: [PATCH v5 10/10] arm64: dts: actions: Add uSD support for Cubieboard7

2020-07-13 Thread Amit Tomer
Hi,

> Fixed regulators are used to nicely model the regulators which aren't tied to
> any PMIC. But for some cases we use them to represent supplies when there is
> no support for the specific PMIC present in the kernel and they are turned
> on/configured by the bootloader (this is what happening here).
>
> And there is no use of declaring fixed regulators when there is no consumer.
> Even if you don't define these, the corresponding supplies in the board will
> always be in the same state configured by the bootloader. So I'd suggest you
> to remove this for now.

Checked the schematics and regulator name is the same for both eMMC and uSD
Shall we keep uSD regulator sd_vcc to be consistent across ACTIONS platform?

> Since I don't have the schematics to check, please make sure you name the
> regulators as mentioned in the schematics (this could vary from board to 
> board,
> so don't just copy from others).
>

Sure, point noted.

Thanks
-Amit.


Re: [PATCH] ARM: dts: vf610-zii-spb4: Add node for switch watchdog

2020-07-13 Thread Shawn Guo
On Sun, Jul 12, 2020 at 01:03:57AM -0700, Chris Healy wrote:
> Add I2C child node for switch watchdog present on SPB4
> 
> Signed-off-by: Chris Healy 

Applied, thanks.


[PATCH 1/4] dma-mapping: Add bounced DMA ops

2020-07-13 Thread Claire Chang
The bounced DMA ops provide an implementation of DMA ops that bounce
streaming DMA in and out of a specially allocated region. Only the
operations relevant to streaming DMA are supported.

Signed-off-by: Claire Chang 
---
 include/linux/device.h  |   3 +
 include/linux/dma-mapping.h |   1 +
 kernel/dma/Kconfig  |  17 +++
 kernel/dma/Makefile |   1 +
 kernel/dma/bounced.c| 215 
 5 files changed, 237 insertions(+)
 create mode 100644 kernel/dma/bounced.c

diff --git a/include/linux/device.h b/include/linux/device.h
index 7322c51e9c0c..868b9a364003 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -588,6 +588,9 @@ struct device {
 
struct list_headdma_pools;  /* dma pools (if dma'ble) */
 
+#ifdef CONFIG_DMA_BOUNCED
+   struct dma_bounced_mem  *dma_bounced_mem;
+#endif
 #ifdef CONFIG_DMA_DECLARE_COHERENT
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
 override */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2328f451a45d..86089424dafd 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -135,6 +135,7 @@ struct dma_map_ops {
 
 extern const struct dma_map_ops dma_virt_ops;
 extern const struct dma_map_ops dma_dummy_ops;
+extern const struct dma_map_ops dma_bounced_ops;
 
 #define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
 
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 1da3f44f2565..148734c8748b 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -88,6 +88,23 @@ config DMA_DIRECT_REMAP
select DMA_REMAP
select DMA_COHERENT_POOL
 
+config DMA_BOUNCED
+   bool "DMA Bounced"
+   depends on !HIGHMEM
+   select OF_RESERVED_MEM
+   help
+ This enables support for bounced DMA pools which provide a level of
+ DMA memory protection on systems with limited hardware protection
+ capabilities, such as those lacking an IOMMU. It does so by bouncing
+ the data to a specially allocated DMA-accessible protected region
+ before mapping and unmapping. One can assign the protected memory
+ region in the device tree by using reserved-memory.
+
+ For more information see
+ 

+ and .
+ If unsure, say "n".
+
 config DMA_CMA
bool "DMA Contiguous Memory Allocator"
depends on HAVE_DMA_CONTIGUOUS && CMA
diff --git a/kernel/dma/Makefile b/kernel/dma/Makefile
index 370f63344e9c..f5fb4f42326a 100644
--- a/kernel/dma/Makefile
+++ b/kernel/dma/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_HAS_DMA)  += mapping.o direct.o dummy.o
+obj-$(CONFIG_DMA_BOUNCED)  += bounced.o
 obj-$(CONFIG_DMA_CMA)  += contiguous.o
 obj-$(CONFIG_DMA_DECLARE_COHERENT) += coherent.o
 obj-$(CONFIG_DMA_VIRT_OPS) += virt.o
diff --git a/kernel/dma/bounced.c b/kernel/dma/bounced.c
new file mode 100644
index ..fcaabb5eccf2
--- /dev/null
+++ b/kernel/dma/bounced.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Bounced DMA support.
+ *
+ * This implements the mitigations for lack of IOMMU by bouncing the data to a
+ * specially allocated region before mapping and unmapping.
+ *
+ * Copyright 2020 Google LLC.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dma_bounced_mem {
+   void**orig_addr;
+   void*virt_base;
+   dma_addr_t  device_base;
+   dma_addr_t  device_end;
+   struct gen_pool *pool;
+   size_t  size;
+};
+
+static void dma_bounced_set_orig_virt(struct device *dev, dma_addr_t dma_addr,
+ void *orig_addr)
+{
+   struct dma_bounced_mem *mem = dev->dma_bounced_mem;
+   int idx = (dma_addr - mem->device_base) >> PAGE_SHIFT;
+
+   if (dma_addr < mem->device_base || dma_addr >= mem->device_end)
+   return;
+
+   mem->orig_addr[idx] = orig_addr;
+}
+
+static void *dma_bounced_get_orig_virt(struct device *dev, dma_addr_t dma_addr)
+{
+   struct dma_bounced_mem *mem = dev->dma_bounced_mem;
+   int idx = (dma_addr - mem->device_base) >> PAGE_SHIFT;
+
+   if (dma_addr < mem->device_base || dma_addr >= mem->device_end)
+   return NULL;
+
+   return mem->orig_addr[idx];
+}
+
+static void *dma_bounced_get_virt(struct device *dev, dma_addr_t dma_addr)
+{
+   struct dma_bounced_mem *mem = dev->dma_bounced_mem;
+
+   if (dma_addr < mem->device_base || dma_addr >= mem->device_end)
+   return NULL;
+
+   return (dma_addr - mem->device_base) + mem->virt_base;
+}
+
+static void dma_bounced_sync_single_for_cpu(struct device *dev,
+   dma_addr_t dma_addr, size_t size,
+   enum 

[PATCH 0/4] Bounced DMA support

2020-07-13 Thread Claire Chang
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.

For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus
is not behind an IOMMU. As PCI-e, by design, gives the device full
access to system memory, a vulnerability in the Wi-Fi firmware could
easily escalate to a full system exploit (remote wifi exploits: [1a],
[1b] that shows a full chain of exploits; [2], [3]).

To mitigate the security concerns, we introduce bounced DMA. The bounced
DMA ops provide an implementation of DMA ops that bounce streaming DMA
in and out of a specially allocated region. The feature on its own
provides a basic level of protection against the DMA overwriting buffer
contents at unexpected times. However, to protect against general data
leakage and system memory corruption, the system needs to provide a way
to restrict the DMA to a predefined memory region (this is usually done
at firmware level, e.g. in ATF on some ARM platforms).

Currently, 32-bit architectures are not supported because of the need to
handle HIGHMEM, which increases code complexity and adds more
performance penalty for such platforms. Also, bounced DMA can not be
enabled on devices behind an IOMMU, as those require an IOMMU-aware
implementation of DMA ops and do not require this kind of mitigation
anyway.

[1a] 
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
[1b] 
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
[2] https://blade.tencent.com/en/advisories/qualpwn/
[3] 
https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/


Claire Chang (4):
  dma-mapping: Add bounced DMA ops
  dma-mapping: Add bounced DMA pool
  dt-bindings: of: Add plumbing for bounced DMA pool
  of: Add plumbing for bounced DMA pool

 .../reserved-memory/reserved-memory.txt   |  36 +++
 drivers/of/address.c  |  37 +++
 drivers/of/device.c   |   3 +
 drivers/of/of_private.h   |   6 +
 include/linux/device.h|   3 +
 include/linux/dma-mapping.h   |   1 +
 kernel/dma/Kconfig|  17 +
 kernel/dma/Makefile   |   1 +
 kernel/dma/bounced.c  | 304 ++
 9 files changed, 408 insertions(+)
 create mode 100644 kernel/dma/bounced.c

-- 
2.27.0.383.g050319c2ae-goog



[PATCH 4/4] of: Add plumbing for bounced DMA pool

2020-07-13 Thread Claire Chang
If a device is not behind an IOMMU, we look up the device node and set
up the bounced DMA when the bounced-dma property is presented. One can
specify two reserved-memory nodes in the device tree. One with
shared-dma-pool to handle the coherent DMA buffer allocation, and
another one with bounced-dma-pool for regular DMA to/from system memory,
which would be subject to bouncing.

Signed-off-by: Claire Chang 
---
 drivers/of/address.c| 37 +
 drivers/of/device.c |  3 +++
 drivers/of/of_private.h |  6 ++
 3 files changed, 46 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..a767b80f8862 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1009,6 +1010,42 @@ int of_dma_get_range(struct device_node *np, u64 
*dma_addr, u64 *paddr, u64 *siz
return ret;
 }
 
+int of_dma_set_bounce_buffer(struct device *dev)
+{
+   int length, size, ret, i;
+   u32 idx[2];
+
+   if (!dev || !dev->of_node)
+   return -EINVAL;
+
+   if (!of_get_property(dev->of_node, "bounced-dma", ))
+   return 0;
+
+   size = length / sizeof(idx[0]);
+   if (size > ARRAY_SIZE(idx)) {
+   dev_err(dev,
+   "bounced-dma expected less than or equal to 2 indexs, 
but got %d\n",
+   size);
+   return -EINVAL;
+   }
+
+   ret = of_property_read_u32_array(dev->of_node, "bounced-dma", idx,
+size);
+
+   for (i = 0; i < size; i++) {
+   ret = of_reserved_mem_device_init_by_idx(dev, dev->of_node,
+idx[i]);
+   if (ret) {
+   dev_err(dev,
+   "of_reserved_mem_device_init_by_idx() failed 
with %d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 /**
  * of_dma_is_coherent - Check if device is coherent
  * @np:device node
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 27203bfd0b22..238beef48a50 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -169,6 +169,9 @@ int of_dma_configure(struct device *dev, struct device_node 
*np, bool force_dma)
 
arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
 
+   if (!iommu)
+   return of_dma_set_bounce_buffer(dev);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(of_dma_configure);
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index edc682249c00..3d1b8cca1519 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -160,12 +160,18 @@ extern int of_bus_n_size_cells(struct device_node *np);
 #ifdef CONFIG_OF_ADDRESS
 extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
u64 *paddr, u64 *size);
+extern int of_dma_set_bounce_buffer(struct device *dev);
 #else
 static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
   u64 *paddr, u64 *size)
 {
return -ENODEV;
 }
+
+static inline int of_dma_get_bounce_buffer(struct device *dev)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* _LINUX_OF_PRIVATE_H */
-- 
2.27.0.383.g050319c2ae-goog



[PATCH 3/4] dt-bindings: of: Add plumbing for bounced DMA pool

2020-07-13 Thread Claire Chang
Introduce the new compatible string, bounced-dma-pool, for bounced DMA.
One can specify the address and length of the bounced memory region by
bounced-dma-pool in the device tree.

Signed-off-by: Claire Chang 
---
 .../reserved-memory/reserved-memory.txt   | 36 +++
 1 file changed, 36 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index 4dd20de6977f..45b3134193ea 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -51,6 +51,24 @@ compatible (optional) - standard definition
   used as a shared pool of DMA buffers for a set of devices. It can
   be used by an operating system to instantiate the necessary pool
   management subsystem if necessary.
+- bounced-dma-pool: This indicates a region of memory meant to be used
+  as a pool of DMA bounce buffers for a given device. When using this,
+  the no-map and reusable properties must not be set, so the operating
+  system can create a virtual mapping that will be used for
+  synchronization. Also, there must be a bounced-dma property in the
+  device node to specify the indexes of reserved-memory nodes. One can
+  specify two reserved-memory nodes in the device tree. One with
+  shared-dma-pool to handle the coherent DMA buffer allocation, and
+  another one with bounced-dma-pool for regular DMA to/from system
+  memory, which would be subject to bouncing. The main purpose for
+  bounced DMA is to mitigate the lack of DMA access control on systems
+  without an IOMMU, which could result in the DMA accessing the system
+  memory at unexpected times and/or unexpected addresses, possibly
+  leading to data leakage or corruption. The feature on its own 
provides
+  a basic level of protection against the DMA overwriting buffer
+  contents at unexpected times. However, to protect against general 
data
+  leakage and system memory corruption, the system needs to provide a
+  way to restrict the DMA to a predefined memory region.
 - vendor specific string in the form ,[-]
 no-map (optional) - empty property
 - Indicates the operating system must not create a virtual mapping
@@ -117,6 +135,17 @@ one for multimedia processing (named 
multimedia-memory@7700, 64MiB).
compatible = "acme,multimedia-memory";
reg = <0x7700 0x400>;
};
+
+   wifi_bounced_dma_mem_region: wifi_bounced_dma_mem_region {
+   compatible = "bounced-dma-pool";
+   reg = <0x5000 0x400>;
+   };
+
+   wifi_coherent_mem_region: wifi_coherent_mem_region {
+   compatible = "shared-dma-pool";
+   reg = <0x5400 0x40>;
+   };
+
};
 
/* ... */
@@ -135,4 +164,11 @@ one for multimedia processing (named 
multimedia-memory@7700, 64MiB).
memory-region = <_reserved>;
/* ... */
};
+
+   pcie_wifi: pcie_wifi@0,0 {
+   memory-region = <_bounced_dma_mem_region>,
+<_coherent_mem_region>;
+   bounced-dma = <0>, <1>;
+   /* ... */
+   };
 };
-- 
2.27.0.383.g050319c2ae-goog



[PATCH 2/4] dma-mapping: Add bounced DMA pool

2020-07-13 Thread Claire Chang
Add the initialization function to create bounce buffer pools from
matching reserved-memory nodes in the device tree.

The bounce buffer pools provide a basic level of protection against
the DMA overwriting buffer contents at unexpected times. However, to
protect against general data leakage and system memory corruption, the
system needs to provide a way to restrict the DMA to a predefined memory
region.

Signed-off-by: Claire Chang 
---
 kernel/dma/bounced.c | 89 
 1 file changed, 89 insertions(+)

diff --git a/kernel/dma/bounced.c b/kernel/dma/bounced.c
index fcaabb5eccf2..0bfd6cf90aee 100644
--- a/kernel/dma/bounced.c
+++ b/kernel/dma/bounced.c
@@ -12,6 +12,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 struct dma_bounced_mem {
@@ -213,3 +216,89 @@ const struct dma_map_ops dma_bounced_ops = {
.max_mapping_size   = dma_bounced_max_mapping_size,
.get_merge_boundary = NULL,
 };
+
+static int dma_bounced_device_init(struct reserved_mem *rmem,
+  struct device *dev)
+{
+   struct dma_bounced_mem *mem;
+   int ret;
+
+   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+   if (!mem)
+   return -ENOMEM;
+
+   mem->virt_base =
+   devm_memremap(dev, rmem->base, rmem->size, MEMREMAP_WB);
+   if (!mem->virt_base) {
+   ret = -EINVAL;
+   goto error;
+   }
+
+   mem->size = rmem->size;
+   mem->device_base = phys_to_dma(dev, rmem->base);
+   mem->device_end = mem->device_base + rmem->size;
+
+   mem->orig_addr = kcalloc(mem->size >> PAGE_SHIFT,
+sizeof(*mem->orig_addr), GFP_KERNEL);
+   if (!mem->orig_addr) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
+   mem->pool = devm_gen_pool_create(dev, PAGE_SHIFT, NUMA_NO_NODE,
+"bounced DMA");
+   if (!mem->pool) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
+   ret = gen_pool_add_virt(mem->pool, (unsigned long)mem->virt_base,
+   rmem->base, rmem->size, NUMA_NO_NODE);
+   if (ret)
+   goto error;
+
+   dev->dma_bounced_mem = mem;
+   set_dma_ops(dev, _bounced_ops);
+
+   return 0;
+
+error:
+   kfree(mem);
+
+   return ret;
+}
+
+static void dma_bounced_device_release(struct reserved_mem *rmem,
+  struct device *dev)
+{
+   struct dma_bounced_mem *mem = dev->dma_bounced_mem;
+
+   set_dma_ops(dev, NULL);
+   dev->dma_bounced_mem = NULL;
+
+   kfree(mem->orig_addr);
+   kfree(mem);
+}
+
+static const struct reserved_mem_ops rmem_dma_bounced_ops = {
+   .device_init= dma_bounced_device_init,
+   .device_release = dma_bounced_device_release,
+};
+
+static int __init dma_bounced_setup(struct reserved_mem *rmem)
+{
+   unsigned long node = rmem->fdt_node;
+
+   if (of_get_flat_dt_prop(node, "reusable", NULL) ||
+   of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
+   of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
+   of_get_flat_dt_prop(node, "no-map", NULL))
+   return -EINVAL;
+
+   rmem->ops = _dma_bounced_ops;
+   pr_info("Reserved memory: created DMA bounced memory pool at %pa, size 
%ld MiB\n",
+   >base, (unsigned long)rmem->size / SZ_1M);
+   return 0;
+}
+
+RESERVEDMEM_OF_DECLARE(dma, "bounced-dma-pool", dma_bounced_setup);
-- 
2.27.0.383.g050319c2ae-goog



Re: [PATCH 5/6] uaccess: add force_uaccess_{begin,end} helpers

2020-07-13 Thread Geert Uytterhoeven
On Fri, Jul 10, 2020 at 3:57 PM Christoph Hellwig  wrote:
> Add helpers to wraper the get_fs/set_fs magic for undoing any damage

to wrap

> done by set_fs(KERNEL_DS).  There is no real functional benefit, but this
> documents the intent of these calls better, and will allow stubbing the
> functions out easily for kernels builds that do not allow address space
> overrides in the future.
>
> Signed-off-by: Christoph Hellwig 

>  arch/m68k/include/asm/tlbflush.h | 12 ++--

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH] Staging: speakup: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/staging/speakup/spkguide.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/spkguide.txt 
b/drivers/staging/speakup/spkguide.txt
index 1e622cd34363..3782f6a09e97 100644
--- a/drivers/staging/speakup/spkguide.txt
+++ b/drivers/staging/speakup/spkguide.txt
@@ -1531,7 +1531,7 @@ The Free Software Foundation may publish new, revised 
versions
 of the GNU Free Documentation License from time to time.  Such new
 versions will be similar in spirit to the present version, but may
 differ in detail to address new problems or concerns.  See
-http://www.gnu.org/copyleft/.
+https://www.gnu.org/copyleft/.
 
 Each version of the License is given a distinguishing version number.
 If the Document specifies that a particular numbered version of this
-- 
2.27.0



Re: [Linux-kernel-mentees] [PATCH net] qrtr: Fix ZERO_SIZE_PTR deref in qrtr_tun_write_iter()

2020-07-13 Thread Dan Carpenter
On Sun, Jul 12, 2020 at 02:36:31PM -0700, Eric Biggers wrote:
> On Sun, Jul 12, 2020 at 05:03:00PM -0400, Peilin Ye wrote:
> > qrtr_tun_write_iter() is dereferencing `ZERO_SIZE_PTR`s when `from->count`
> > equals to zero. Fix it by rejecting zero-length kzalloc() requests.
> > 
> > This patch fixes the following syzbot bug:
> > 
> > 
> > https://syzkaller.appspot.com/bug?id=f56bbe6668873ee245986bbd23312b895fa5a50a
> > 
> > Reported-by: syzbot+03e343dbccf82a524...@syzkaller.appspotmail.com
> > Signed-off-by: Peilin Ye 
> > ---
> >  net/qrtr/tun.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/net/qrtr/tun.c b/net/qrtr/tun.c
> > index 15ce9b642b25..5465e94ba8e5 100644
> > --- a/net/qrtr/tun.c
> > +++ b/net/qrtr/tun.c
> > @@ -80,6 +80,9 @@ static ssize_t qrtr_tun_write_iter(struct kiocb *iocb, 
> > struct iov_iter *from)
> > ssize_t ret;
> > void *kbuf;
> >  
> > +   if (!len)
> > +   return -EINVAL;
> > +
> > kbuf = kzalloc(len, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
> 
> Wasn't this already fixed by:
> 
> commit 8ff41cc21714704ef0158a546c3c4d07fae2c952
> Author: Dan Carpenter 
> Date:   Tue Jun 30 14:46:15 2020 +0300
> 
> net: qrtr: Fix an out of bounds read qrtr_endpoint_post()


Yep.  If you're using kmalloc() you can allocate a zero byte buffer but
you just can't access the array.  for (i = 0; i < 0; i++) works.

It's interesting because at the time, I wrote the patch I thought "len"
probably couldn't be zero but I just checked it for completeness and
readability.

regards,
dan carpenter


Re: [PATCH 4/6] uaccess: remove segment_eq

2020-07-13 Thread Geert Uytterhoeven
On Fri, Jul 10, 2020 at 3:58 PM Christoph Hellwig  wrote:
> segment_eq is only used to implement uaccess_kernel.  Just open code
> uaccess_kernel in the arch uaccess headers and remove one layer of
> indirection.
>
> Signed-off-by: Christoph Hellwig 

>  arch/m68k/include/asm/segment.h   | 2 +-

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 1/2] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC

2020-07-13 Thread Lee Jones
On Mon, 13 Jul 2020, Xu Yilun wrote:

> This patch implements the basic functions of the BMC chip for some Intel
> FPGA PCIe Acceleration Cards (PAC). The BMC is implemented using the
> intel max10 CPLD.
> 
> This BMC chip is connected to FPGA by a SPI bus. To provide reliable
> register access from FPGA, an Avalon Memory-Mapped (Avmm) transaction
> protocol over the SPI bus is used between host and slave.
> 
> This driver implements the basic register access with the regmap framework.
> The mfd cells array is empty now as a placeholder.
> 
> Signed-off-by: Xu Yilun 
> Signed-off-by: Wu Hao 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Russ Weight 
> Signed-off-by: Tom Rix 
> ---
>  .../ABI/testing/sysfs-driver-intel-m10-bmc |  15 +
>  drivers/mfd/Kconfig|  13 +
>  drivers/mfd/Makefile   |   3 +
>  drivers/mfd/intel-m10-bmc-main.c   | 176 

>  drivers/mfd/intel-spi-avmm.c   | 904 
> +

This does not belong in MFD.

Please consider moving it to drivers/spi.

>  drivers/mfd/intel-spi-avmm.h   |  35 +
>  include/linux/mfd/intel-m10-bmc.h  |  57 ++
>  7 files changed, 1203 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
>  create mode 100644 drivers/mfd/intel-m10-bmc-main.c
>  create mode 100644 drivers/mfd/intel-spi-avmm.c
>  create mode 100644 drivers/mfd/intel-spi-avmm.h
>  create mode 100644 include/linux/mfd/intel-m10-bmc.h

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 2/2] locking/pvqspinlock: Optionally store lock holder cpu into lock

2020-07-13 Thread Peter Zijlstra
On Sun, Jul 12, 2020 at 07:05:36PM -0400, Waiman Long wrote:
> On 7/12/20 1:34 PM, Peter Zijlstra wrote:

> > And this kills it,.. if it doesn't make unconditional sense, we're not
> > going to do this. It's just too ugly.
> > 
> You mean it has to be unconditional, no option config if we want to do it.
> Right?

Yeah, the very last thing we need in this code is spurious complexity.


[PATCH] USB: ohci: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/usb/host/ohci-hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 4de91653a2c7..17374c17f331 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -16,7 +16,7 @@
  * OHCI is the main "non-Intel/VIA" standard for USB 1.1 host controller
  * interfaces (though some non-x86 Intel chips use it).  It supports
  * smarter hardware than UHCI.  A download link for the spec available
- * through the http://www.usb.org website.
+ * through the https://www.usb.org website.
  *
  * This file is licenced under the GPL.
  */
-- 
2.27.0



Re: [PATCH v5 0/5] scsi: ufs: Add Host Performance Booster Support

2020-07-13 Thread Bean Huo
On Mon, 2020-07-13 at 10:27 +0900, Daejun Park wrote:
> Hi Bart,
> 
> > > Bart - how do you want to proceed?
> > 
> > Hi Avri and Daejun,
> > 
> > As far as I can see none of the five patches have Reviewed-by tags
> > yet. I
> > think that Martin expects formal reviews for this patch series from
> > one or
> > more reviewers who are not colleagues of the author of this patch
> > series.
> > 
> > Note: recently I have been more busy than usual, hence the delayed
> > reply.
> 
> Thank you for replying to the email even though you are busy.
> 
> Arvi, Bean - if patches looks ok, can this series have your reviewed-
> by tag?
> 
> Thanks,
> Daejun

Hi Daejun


I only can give my tested-by tag since I preliminary tested it and it
works. However, as I said in the previous email, there is performance
downgrade comparing to the direct submission approach, also, we should
think about HPB 2.0.

Anyway, if Avri wants firstly make this series patch mainlined,
performance fixup later, this is fine to me. I can add and fix it
later.

BTW, you should rebase your this series set patch since there are
conflicts with latest Martin' git repo, after that, you can add my
tested-by tag.


Tested-by: Bean Huo 


Thanks,
Bean





Re: [PATCH RFC 0/3] io_uring: add restrictions to support untrusted applications and guests

2020-07-13 Thread Stefan Hajnoczi
On Fri, Jul 10, 2020 at 06:20:17PM +0200, Stefano Garzarella wrote:
> On Fri, Jul 10, 2020 at 11:33:09AM -0400, Konrad Rzeszutek Wilk wrote:
> > .snip..
> > > Just to recap the proposal, the idea is to add some restrictions to the
> > > operations (sqe, register, fixed file) to safely allow untrusted 
> > > applications
> > > or guests to use io_uring queues.
> > 
> > Hi!
> > 
> > This is neat and quite cool - but one thing that keeps nagging me is
> > what how much overhead does this cut from the existing setup when you use
> > virtio (with guests obviously)?
> 
> I need to do more tests, but the preliminary results that I reported on
> the original proposal [1] show an overhead of ~ 4.17 uS (with iodepth=1)
> when I'm using virtio ring processed in a dedicated iothread:
> 
>   - 73 kIOPS using virtio-blk + QEMU iothread + io_uring backend
>   - 104 kIOPS using io_uring passthrough
> 
> > That is from a high level view the
> > beaty of io_uring being passed in the guest is you don't have the
> > virtio ring -> io_uring processing, right?
> 
> Right, and potentially we can share the io_uring queues directly to the
> guest userspace applications, cutting down the cost of Linux block
> layer in the guest.

Another factor is that the guest submits requests directly to the host
kernel sqpoll thread. When a virtqueue is used the sqpoll thread cannot
poll it directly so another host thread (QEMU) needs to poll the
virtqueue. The same applies for the completion code path.

Stefan


signature.asc
Description: PGP signature


Re: [PATCH V6 0/6] Support building i.MX ARMv8 platforms clock driver as module

2020-07-13 Thread Shawn Guo
On Tue, Jul 07, 2020 at 01:09:33PM +0800, Anson Huang wrote:
> Nowdays, there are more and more requirements of building SoC specific drivers
> as modules, such as Android GKI (generic kernel image), this patch set 
> supports
> building i.MX ARMv8 SoCs clock drivers as modules,
> 
> The CLK_IMXxxx is introduced for i.MX ARMv7 platforms in order to make the 
> build
> options aligned, the reason why i.MX ARMv7 platforms clock driver do NOT 
> support
> module build and COMPILE_TEST is because, some drivers like i.MX GPT timer 
> driver
> depends on clock driver to be ready before it, GPT driver uses 
> TIMER_OF_DECLARE(),
> while i.MX6/7 clock drivers use CLK_OF_DECLARE(), and GPT driver is critical 
> for
> i.MX6/7 platforms kernel boot up, so GPT driver needs to be changed to support
> loadable clock driver first, then the i.MX6/7 clock drivers can support 
> loadable
> module, this will be done later.
> 
> Changes since V5:
>   - make i.MX ARMv7 platforms clock driver to bool and NOT support 
> COMPILT_TEST,
> since they depends on ARCH_MXC or SOC config, which makes the 
> COMPILT_TEST
> NOT make enough sense, so just skip the COMPILT_TEST support for i.MX 
> ARMv7
> platform clock drivers, leave them same as original implementation.
>   - add a patch to fix build warning reported by kernel robot test on 
> i.MX6SL
> clock driver.
> 
> Anson Huang (6):
>   clk: composite: Export clk_hw_register_composite()
>   clk: imx: Support building i.MX common clock driver as module
>   clk: imx: Add clock configuration for ARMv7 platforms
>   clk: imx8m: Support module build
>   clk: imx8qxp: Support building i.MX8QXP clock driver as module
>   clk: imx6sl: Fix build warning reported by kernel test robot

I'm picking up the series and throwing it into linux-next for testing.

Shawn


Re: [PATCH v2] dmaengine: check device and channel list for empty

2020-07-13 Thread Vinod Koul
On 09-07-20, 08:23, Dave Jiang wrote:
> 
> 
> On 7/8/2020 10:35 PM, Jiri Slaby wrote:
> > On 07. 07. 20, 17:42, Dave Jiang wrote:
> > > On 7/6/2020 11:05 PM, Jiri Slaby wrote:
> > > > On 26. 06. 20, 20:09, Dave Jiang wrote:
> > > > > Check dma device list and channel list for empty before iterate as the
> > > > > iteration function assume the list to be not empty. With devices and
> > > > > channels now being hot pluggable this is a condition that needs to be
> > > > > checked. Otherwise it can cause the iterator to spin forever.
> > > > 
> > > > Could you be a little bit more specific how this can spin forever? I.e.
> > > > can you attach a stacktrace of such a behaviour?
> > > 
> > > I can't seem to find the original splat that lead me to the conclusion
> > > of it's spinning forever. As I recall, the issue seems to produce
> > > different splats and not always consistent in being reproduced. Here's a
> > > partial splat that was tracked by the internal bug database. Since with
> > > the dma device and channel list being are hot added and removed, the
> > > device and channel lists can be empty. The list_entry() and friends
> > > expect the list to not be empty (according to header comment), I added
> > > the check to ensure that isn't the case before using them in dmaengine.
> > 
> > Yes, the comment states that as it is true: you receive a
> > wild/non-checkable pointer if you do list_entry on an empty list. BUT
> > have you actually read what I wrote:
> > 
> > > > As in the empty case, ">member" is "head" (look into
> > > > list_for_each_entry) and the for loop should loop exactly zero times.
> > 
> > HERE 
> > 
> > > With the fix, we can no longer produce any of the splats. So maybe the
> > > above was a bad description of the issue.
> > 
> > No, not only the description, worse, the patch proper looks wrong.
> > 
> > > [ 4216.048375]  ? dma_channel_rebalance+0x7b/0x250
> > > [ 4216.056360]  dma_async_device_register+0x349/0x3a0
> > > [ 4216.064604]  idxd_register_dma_device+0x90/0xc0 [idxd]
> > > [ 4216.073175]  idxd_config_bus_probe.cold+0x7d/0x1fc [idxd]
> > 
> > So, the good part in the patch is the fixed locking in
> > dma_async_device_register. Otherwise it adds nonsense checks. So you
> > fixed the issue only by a chance, by a side effect as Peter pointed out.
> > Leaving aside that you broke dma_request_chan -- that could happen to
> > anybody.
> > 
> > Vinod, please drop/revert this patch. Then start over only with
> > dma_async_device_register fixed locking.
> 
> I'll start on the proper fix.

Dropped

-- 
~Vinod


linux-next: Tree for Jul 13

2020-07-13 Thread Stephen Rothwell
Hi all,

News: to check Linus' recent tree (and therefore linux-next) with sparse,
you will need a very new version of sparse. Linus says:

Sparse is really easy to build and install as a regular user. Just do

mkdir -p ~/src ; cd ~/src
git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git
cd sparse
make && make install

and it will install the sparse binaries in your ~/bin directory. No
need to be root, it just works.

Changes since 20200710:

My fixes tree contains:

  dbf24e30ce2e ("device_cgroup: Fix RCU list debugging warning")
  b236d81d9e4f ("powerpc/boot/dts: Fix dtc "pciex" warnings")

The kbuild tree still had its build failure for which I reverted a commit.

The net-next tree gained a build failure for which I reverted a commit.

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

The tip tree still had one build failure for which I reverted a commit.

The kvm-arm tree gained conflicts against the kvm tree.

The kvms390 tree gained a conflict against the kvm tree.

The tty tree gained a conflict against the drm-misc tree.

The pidfd tree gained a conflict against the risc-v tree.

The akpm-current tree gained a conflict against the net-next tree.

Non-merge commits (relative to Linus' tree): 6503
 7305 files changed, 386169 insertions(+), 148893 deletions(-)



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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (4437dd6e8f71 Merge tag 'io_uring-5.8-2020-07-12' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (b236d81d9e4f powerpc/boot/dts: Fix dtc "pciex" warnings)
Merging kbuild-current/fixes (20b1be595282 kbuild: fix single target builds for 
external modules)
Merging arc-current/for-curr (10011f7d95de ARCv2: support loop buffer (LPB) 
disabling)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb 
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (42d3f7e8da1b Merge tag 'imx-fixes-5.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2)
Merging arm64-fixes/for-next/fixes (5679b2814219 arm64/alternatives: don't 
patch up internal branches)
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length 
array with flexible-array member)
Merging powerpc-fixes/fixes (4557ac6b344b powerpc/64s/exception: Fix 0x1500 
interrupt handler crash)
Merging s390-fixes/fixes (dd9ce2d6eeae MAINTAINERS: update email address for 
Gerald Schaefer)
Merging sparc/master (5124b31c1e90 sparc: piggyback: handle invalid image)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty 
inodes after removing key)
Merging net/master (1df0d8960499 Merge tag 'libnvdimm-fix-v5.8-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm)
Merging bpf/master (55b244221c3f selftests/bpf: Fix cgroup sockopt verifier 
test)
Merging ipsec/master (17175d1a27c6 xfrm: esp6: fix encapsulation header offset 
computation)
Merging netfilter/master (ce69e563b325 tcp: make sure listeners don't 
initialize congestion-control state)
Merging ipvs/master (eadede5f9362 Merge branch 'hns3-fixes')
Merging wireless-drivers/master 

RE: [PATCH v4] 9p: retrieve fid from file when file instance exist.

2020-07-13 Thread Jianyong Wu


> -Original Message-
> From: Dominique Martinet 
> Sent: Friday, July 10, 2020 7:09 PM
> To: Jianyong Wu 
> Cc: eri...@gmail.com; lu...@ionkov.net; v9fs-
> develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org; Steve
> Capper ; Kaly Xin ; Justin He
> ; Wei Chen 
> Subject: Re: [PATCH v4] 9p: retrieve fid from file when file instance exist.
>
> Jianyong Wu wrote on Fri, Jul 10, 2020:
> > In the current setattr implementation in 9p, fid is always retrieved
> > from dentry no matter file instance exists or not. If so, there may be
> > some info related to opened file instance dropped. So it's better to
> > retrieve fid from file instance when it is passed to setattr.
> >
> > for example:
> > fd=open("tmp", O_RDWR);
> > ftruncate(fd, 10);
> >
> > The file context related with the fd will be lost as fid is always
> > retrieved from dentry, then the backend can't get the info of file
> > context. It is against the original intention of user and may lead to
> > bug.
> >
> > Signed-off-by: Jianyong Wu 
> > ---
>
>
> For next time, you can add arbitrary comments (e.g. describe briefly
> differences from previous versions) after the --- line.
>
> For others, this inits fid to NULL in both functions; thanks for picking it 
> up I'll
> refresh the patch.
>
Ok,

Thanks
Jianyong
> --
> Dominique
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


Re: [PATCH] vsock/virtio: annotate 'the_virtio_vsock' RCU pointer

2020-07-13 Thread Stefan Hajnoczi
On Fri, Jul 10, 2020 at 02:12:43PM +0200, Stefano Garzarella wrote:
> Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free
> on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock'
> pointer, but we forgot to annotate it.
> 
> This patch adds the annotation to fix the following sparse errors:
> 
> net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:171:17: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:207:17: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:561:13: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:612:9: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:631:9: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock *
> 
> Fixes: 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on 
> the_virtio_vsock")
> Reported-by: Michael S. Tsirkin 
> Signed-off-by: Stefano Garzarella 
> ---
>  net/vmw_vsock/virtio_transport.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [PATCH] vhost/scsi: fix up req type endian-ness

2020-07-13 Thread Stefan Hajnoczi
On Fri, Jul 10, 2020 at 06:48:51AM -0400, Michael S. Tsirkin wrote:
> vhost/scsi doesn't handle type conversion correctly
> for request type when using virtio 1.0 and up for BE,
> or cross-endian platforms.
> 
> Fix it up using vhost_32_to_cpu.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/vhost/scsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [PATCH v4 4/4] thermal: core: Add notifications call in the framework

2020-07-13 Thread Marek Szyprowski
Hi

On 07.07.2020 11:15, Marek Szyprowski wrote:
> On 06.07.2020 15:46, Daniel Lezcano wrote:
>> On 06/07/2020 15:17, Marek Szyprowski wrote:
>>> On 06.07.2020 12:55, Daniel Lezcano wrote:
 The generic netlink protocol is implemented but the different
 notification functions are not yet connected to the core code.

 These changes add the notification calls in the different
 corresponding places.

 Reviewed-by: Amit Kucheria 
 Signed-off-by: Daniel Lezcano 
>>> This patch landed in today's linux-next 20200706 as commit 5df786e46560
>>> ("thermal: core: Add notifications call in the framework"). Sadly it
>>> breaks booting various Samsung Exynos based boards. Here is an example
>>> log from Odroid U3 board:
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0010
>>> pgd = (ptrval)
>>> [0010] *pgd=
>>> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3-00015-g5df786e46560
>>> #1146
>>> Hardware name: Samsung Exynos (Flattened Device Tree)
>>> PC is at kmem_cache_alloc+0x13c/0x418
>>> LR is at kmem_cache_alloc+0x48/0x418
>>> pc : []    lr : []    psr: 2053
>>> ...
>>> Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
>>> Control: 10c5387d  Table: 4000404a  DAC: 0051
>>> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>>> Stack: (0xee8f1cf8 to 0xee8f2000)
>>> ...
>>> [] (kmem_cache_alloc) from [] 
>>> (__alloc_skb+0x5c/0x170)
>>> [] (__alloc_skb) from []
>>> (thermal_genl_send_event+0x24/0x174)
>>> [] (thermal_genl_send_event) from []
>>> (thermal_notify_tz_create+0x58/0x74)
>>> [] (thermal_notify_tz_create) from []
>>> (thermal_zone_device_register+0x358/0x650)
>>> [] (thermal_zone_device_register) from []
>>> (of_parse_thermal_zones+0x304/0x7a4)
>>> [] (of_parse_thermal_zones) from []
>>> (thermal_init+0xdc/0x154)
>>> [] (thermal_init) from [] 
>>> (do_one_initcall+0x8c/0x424)
>>> [] (do_one_initcall) from []
>>> (kernel_init_freeable+0x190/0x204)
>>> [] (kernel_init_freeable) from []
>>> (kernel_init+0x8/0x118)
>>> [] (kernel_init) from [] (ret_from_fork+0x14/0x20)
>>>
>>> Reverting it on top of linux-next fixes the boot issue. I will
>>> investigate it further soon.
>> Thanks for reporting this.
>>
>> Can you send the addr2line result and code it points to ?
>
> addr2line of c02b5cac (kmem_cache_alloc+0x13c/0x418) points to 
> mm/slub.c +2839, but I'm not sure if we can trust it. imho it looks 
> like some trashed memory somewhere, but I don't have time right now to 
> analyze it further now...

Just one more thing I've noticed. The crash happens only if the kernel 
is compiled with old GCC (tested with arm-linux-gnueabi-gcc (Linaro GCC 
4.9-2017.01) 4.9.4). If I compile kernel with newed GCC (like 
arm-linux-gnueabi-gcc (Linaro GCC 6.4-2017.11) 6.4.1 20171012), it works 
fine...

This happens also with Linux next-20200710, which again got this commit.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland



[PATCH] doc/zh_CN: add Chinese translation prefer section

2020-07-13 Thread Alex Shi
The add words is:

Translation Plan


Welcome for any part of kernel doc Chinese translation, expecially for
admin-guide part.

Signed-off-by: Alex Shi 
Cc: Jonathan Corbet  
Cc: Harry Wei  
Cc: linux-...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 Documentation/conf.py  | 2 +-
 Documentation/translations/zh_CN/index.rst | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index c50310d9..b5b2be8eec22 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -36,7 +36,7 @@ needs_sphinx = '1.3'
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
   'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
   'maintainers_include', 'sphinx.ext.autosectionlabel' ]
 
diff --git a/Documentation/translations/zh_CN/index.rst 
b/Documentation/translations/zh_CN/index.rst
index 76850a5dd982..f2e06546ca3f 100644
--- a/Documentation/translations/zh_CN/index.rst
+++ b/Documentation/translations/zh_CN/index.rst
@@ -10,6 +10,11 @@
 人员做出贡献。 与任何大型社区一样,知道如何完成任务将使得更改合并的过程变得更
 加容易。
 
+翻译计划
+
+
+内核中文文档欢迎任何翻译投稿,特别是关于管理员指南部分。
+
 .. toctree::
:maxdepth: 2
 
-- 
2.18.2



RE: objtool clac/stac handling change..

2020-07-13 Thread David Laight
From: Linus Torvalds
> Sent: 10 July 2020 23:37
> On Tue, Jul 7, 2020 at 5:35 AM David Laight  wrote:
> >
> >
> > So separate copy and checksum passes should easily exceed 4 bytes/clock,
> > but I suspect that doing them together never does.
> > (Unless the buffer is too big for the L1 cache.)
> 
> Its' the "touch the caches twice" that is the problem".
> 
> And it's not the "buffer is too big for L1", it's "the source, the
> destination and any incidentals are too big for L1" with the
> additional noise from replacement policies etc.

That's really what I meant.
L1D is actually (probably) only 32kB.
I guess that gives you 8k for the buffer.

It is a shame you can't use the AVX instructions in kernel.
(Although saving them probably costs more than the gain.)
Then you could use something based on:
10: load ymm,src+idx   // 32 bytes
store ymm,tgt+idx
addq sum0,ymm   // eight 32bit adds
rotate ymm,16   // Pretty sure there in an instruction for this!
addq sum1,ymm
add idx,32
jnz 10b
It is then possibly to determine the correct result from sum0/sum1.
On very recent Intel cpu that might even run at 1 iteration/clock!
(Probably needs and unroll and explicit interleave.)
At one iteration every 2 clocks it matches the ADDX[OC] loop
but includes the write.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)


Re: [PATCH v10 11/17] mtd: spi-nor: sfdp: do not make invalid quad enable fatal

2020-07-13 Thread Tudor.Ambarus
On 6/23/20 9:30 PM, Pratyush Yadav wrote:
> The Micron MT35XU512ABA flash does not support the quad enable bit. But
> instead of programming the Quad Enable Require field to 000b ("Device
> does not have a QE bit"), it is programmed to 111b ("Reserved").
> 
> While this is technically incorrect, it is not reason enough to abort
> BFPT parsing. Instead, continue BFPT parsing and let flashes set it in
> their fixup hooks.
> 
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/mtd/spi-nor/sfdp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks!


[PATCH] WAN: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/net/wan/c101.c  | 2 +-
 drivers/net/wan/n2.c| 2 +-
 drivers/net/wan/pc300too.c  | 2 +-
 drivers/net/wan/pci200syn.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wan/c101.c b/drivers/net/wan/c101.c
index cb57f9124ab1..c354a5143e99 100644
--- a/drivers/net/wan/c101.c
+++ b/drivers/net/wan/c101.c
@@ -4,7 +4,7 @@
  *
  * Copyright (C) 2000-2003 Krzysztof Halasa 
  *
- * For information see 
+ * For information see 
  *
  * Sources of information:
  *Hitachi HD64570 SCA User's Manual
diff --git a/drivers/net/wan/n2.c b/drivers/net/wan/n2.c
index f9e7fc7e9978..5bf4463873b1 100644
--- a/drivers/net/wan/n2.c
+++ b/drivers/net/wan/n2.c
@@ -4,7 +4,7 @@
  *
  * Copyright (C) 1998-2003 Krzysztof Halasa 
  *
- * For information see 
+ * For information see 
  *
  * Note: integrated CSU/DSU/DDS are not supported by this driver
  *
diff --git a/drivers/net/wan/pc300too.c b/drivers/net/wan/pc300too.c
index 190735604b2e..001fd378d417 100644
--- a/drivers/net/wan/pc300too.c
+++ b/drivers/net/wan/pc300too.c
@@ -4,7 +4,7 @@
  *
  * Copyright (C) 2000-2008 Krzysztof Halasa 
  *
- * For information see .
+ * For information see .
  *
  * Sources of information:
  *Hitachi HD64572 SCA-II User's Manual
diff --git a/drivers/net/wan/pci200syn.c b/drivers/net/wan/pci200syn.c
index b5f8aaca5f06..d0062224b216 100644
--- a/drivers/net/wan/pci200syn.c
+++ b/drivers/net/wan/pci200syn.c
@@ -4,7 +4,7 @@
  *
  * Copyright (C) 2002-2008 Krzysztof Halasa 
  *
- * For information see 
+ * For information see 
  *
  * Sources of information:
  *Hitachi HD64572 SCA-II User's Manual
-- 
2.27.0



RE

2020-07-13 Thread Lerynne West



Hallo, Sie haben eine Spende von 2.800.000,00 Euro, ich gewann die 
Amerika-Lotterie in Amerika im Wert von 343 Millionen Dollar und ich spende 
einen Teil davon an funf gluckliche Menschen und Wohltatigkeitshauser in 
Erinnerung an meinen verstorbenen Sohn, der an Krebs gestorben ist, um das 
Leben vieler Menschen zu verbessern, die von diesem Coronavirus betroffen sind, 
kontaktieren Sie mich fur weitere Details; callumfoundatio...@gmail.com
BezugFrau Lerynne West


[rcu:rcu/test 64/65] include/linux/kernel.h:1002:17: warning: cast to pointer from integer of different size

2020-07-13 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/test
head:   e4d26431bafa60b212117ec5750833d39ce1b2aa
commit: f89bf7a94ffa9446a341fefc18153e8f9bebffbb [64/65] kvm: mmu: page_track: 
Fix RCU list API usage
config: x86_64-rhel (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
git checkout f89bf7a94ffa9446a341fefc18153e8f9bebffbb
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from include/linux/pid.h:5,
from include/linux/sched.h:14,
from include/linux/kvm_host.h:12,
from arch/x86/kvm/mmu/page_track.c:14:
   arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_write':
   include/linux/rculist.h:727:30: error: expected expression before ',' token
 727 |  for (__list_check_srcu(cond), \
 |  ^
   arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro 
'hlist_for_each_entry_srcu'
 232 |  hlist_for_each_entry_srcu(n, >track_notifier_list, node,
 |  ^
   In file included from include/linux/preempt.h:11,
from include/linux/percpu.h:6,
from include/linux/context_tracking_state.h:5,
from include/linux/hardirq.h:5,
from include/linux/kvm_host.h:7,
from arch/x86/kvm/mmu/page_track.c:14:
   include/linux/compiler.h:293:2: error: expected statement before ')' token
 293 | })
 |  ^
   include/linux/list.h:955:12: note: in definition of macro 'hlist_entry_safe'
 955 |  ({ typeof(ptr) ptr = (ptr); \
 |^~~
   include/linux/rcupdate.h:366:25: note: in expansion of macro 'READ_ONCE'
 366 |  typeof(p) p1 = READ_ONCE(p); \
 | ^
   include/linux/rculist.h:728:30: note: in expansion of macro 
'rcu_dereference_raw'
 728 |   pos = 
hlist_entry_safe(rcu_dereference_raw(hlist_first_rcu(head)),\
 |  ^~~
   arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro 
'hlist_for_each_entry_srcu'
 232 |  hlist_for_each_entry_srcu(n, >track_notifier_list, node,
 |  ^
   include/linux/rcupdate.h:367:35: error: 'p1' undeclared (first use 
in this function)
 367 |  ((typeof(*p) __force __kernel *)(p1)); \
 |   ^~
   include/linux/list.h:955:12: note: in definition of macro 'hlist_entry_safe'
 955 |  ({ typeof(ptr) ptr = (ptr); \
 |^~~
   include/linux/rculist.h:728:30: note: in expansion of macro 
'rcu_dereference_raw'
 728 |   pos = 
hlist_entry_safe(rcu_dereference_raw(hlist_first_rcu(head)),\
 |  ^~~
   arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro 
'hlist_for_each_entry_srcu'
 232 |  hlist_for_each_entry_srcu(n, >track_notifier_list, node,
 |  ^
   include/linux/rcupdate.h:367:35: note: each undeclared identifier is 
reported only once for each function it appears in
 367 |  ((typeof(*p) __force __kernel *)(p1)); \
 |   ^~
   include/linux/list.h:955:12: note: in definition of macro 'hlist_entry_safe'
 955 |  ({ typeof(ptr) ptr = (ptr); \
 |^~~
   include/linux/rculist.h:728:30: note: in expansion of macro 
'rcu_dereference_raw'
 728 |   pos = 
hlist_entry_safe(rcu_dereference_raw(hlist_first_rcu(head)),\
 |  ^~~
   arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro 
'hlist_for_each_entry_srcu'
 232 |  hlist_for_each_entry_srcu(n, >track_notifier_list, node,
 |  ^
   include/linux/list.h:955:27: warning: initialization of 'int' from 'struct 
hlist_node *' makes integer from pointer without a cast [-Wint-conversion]
 955 |  ({ typeof(ptr) ptr = (ptr); \
 |   ^
   include/linux/rculist.h:728:13: note: in expansion of macro 
'hlist_entry_safe'
 728 |   pos = 
hlist_entry_safe(rcu_dereference_raw(hlist_first_rcu(head)),\
 | ^~~~
   arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro 
'hlist_for_each_entry_srcu'
 232 |  hlist_for_each_entry_srcu(n, >track_notifier_list, node,
 |  ^
   In file included from include/asm-generic/bug.h:19,
from arch/x86/include/asm/bug.h:92,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
 

Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

2020-07-13 Thread Takashi Iwai
On Mon, 13 Jul 2020 10:43:28 +0200,
Julia Lawall wrote:
> 
> 
> 
> On Mon, 13 Jul 2020, Takashi Iwai wrote:
> 
> > On Wed, 08 Jul 2020 20:14:27 +0200,
> > Dan Williams wrote:
> > >
> > > +Recommended replacements for 'blacklist/whitelist' are:
> > > +'denylist / allowlist'
> > > +'blocklist / passlist'
> >
> > I started looking through the tree now and noticed there are lots of
> > patterns like "whitelisted" or "blacklisted".  How can the words fit
> > for those?  Actually, there are two cases like:
> >
> > - Foo is blacklisted
> > - Allow to load the non-whitelisted cards
> >
> > Currently I'm replacing the former with "Foo is in denylist", but not
> 
> In the denylist?

Not really, only the allowlist exists in this case.


thanks,

Takashi


[PATCH v3 1/2] phy: Add new PHY attribute max_link_rate and APIs to get/set PHY attributes

2020-07-13 Thread Swapnil Jakhade
Add new PHY attribute max_link_rate to struct phy_attrs.
Add a pair of PHY APIs to get/set all the PHY attributes.
Use phy_set_attrs() to set attribute values in the PHY provider driver.
Use phy_get_attrs() to get attribute values in the controller driver.

Signed-off-by: Yuti Amonkar 
Signed-off-by: Swapnil Jakhade 
---
 include/linux/phy/phy.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index bcee8eba62b3..7fb59359ab7b 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -115,10 +115,12 @@ struct phy_ops {
 /**
  * struct phy_attrs - represents phy attributes
  * @bus_width: Data path width implemented by PHY
+ * @max_link_rate: Maximum link rate supported by PHY (in Mbps)
  * @mode: PHY mode
  */
 struct phy_attrs {
u32 bus_width;
+   u32 max_link_rate;
enum phy_mode   mode;
 };
 
@@ -231,6 +233,16 @@ static inline void phy_set_bus_width(struct phy *phy, int 
bus_width)
 {
phy->attrs.bus_width = bus_width;
 }
+
+static inline void phy_get_attrs(struct phy *phy, struct phy_attrs *attrs)
+{
+   memcpy(attrs, >attrs, sizeof(struct phy_attrs));
+}
+
+static inline void phy_set_attrs(struct phy *phy, struct phy_attrs attrs)
+{
+   memcpy(>attrs, , sizeof(struct phy_attrs));
+}
 struct phy *phy_get(struct device *dev, const char *string);
 struct phy *phy_optional_get(struct device *dev, const char *string);
 struct phy *devm_phy_get(struct device *dev, const char *string);
@@ -389,6 +401,16 @@ static inline void phy_set_bus_width(struct phy *phy, int 
bus_width)
return;
 }
 
+static inline void phy_get_attrs(struct phy *phy, struct phy_attrs *attrs)
+{
+   return;
+}
+
+static inline void phy_set_attrs(struct phy *phy, struct phy_attrs attrs)
+{
+   return;
+}
+
 static inline struct phy *phy_get(struct device *dev, const char *string)
 {
return ERR_PTR(-ENOSYS);
-- 
2.26.1



[PATCH v3 2/2] phy: cadence-torrent: Use kernel PHY API to set PHY attributes

2020-07-13 Thread Swapnil Jakhade
Use generic PHY framework function phy_set_attrs() to set number
of lanes and maximum link rate supported by PHY.

Signed-off-by: Swapnil Jakhade 
---
 drivers/phy/cadence/phy-cadence-torrent.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/phy/cadence/phy-cadence-torrent.c 
b/drivers/phy/cadence/phy-cadence-torrent.c
index 7116127358ee..af81707ff0c6 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -1710,6 +1710,7 @@ static int cdns_torrent_phy_probe(struct platform_device 
*pdev)
struct cdns_torrent_phy *cdns_phy;
struct device *dev = >dev;
struct phy_provider *phy_provider;
+   struct phy_attrs torrent_attr;
const struct of_device_id *match;
struct cdns_torrent_data *data;
struct device_node *child;
@@ -1852,6 +1853,12 @@ static int cdns_torrent_phy_probe(struct platform_device 
*pdev)
 cdns_phy->phys[node].num_lanes,
 cdns_phy->max_bit_rate / 1000,
 cdns_phy->max_bit_rate % 1000);
+
+   torrent_attr.bus_width = cdns_phy->phys[node].num_lanes;
+   torrent_attr.max_link_rate = cdns_phy->max_bit_rate;
+   torrent_attr.mode = PHY_MODE_DP;
+
+   phy_set_attrs(gphy, torrent_attr);
} else {
dev_err(dev, "Driver supports only PHY_TYPE_DP\n");
ret = -ENOTSUPP;
-- 
2.26.1



[PATCH v3 0/2] Add new PHY APIs to framework to get/set PHY attributes

2020-07-13 Thread Swapnil Jakhade
This patch series adds a new pair of PHY APIs that can be used to get/set
all the PHY attributes. It also adds a new PHY attribute max_link_rate.

It includes following patches:

1. v3-0001-phy-Add-new-PHY-attribute-max_link_rate-and-APIs-.patch
This patch adds max_link_rate as a new PHY attribute along with a pair of
APIs that allow using the generic PHY subsystem to get/set PHY attributes
supported by the PHY.

2. v3-0002-phy-cadence-torrent-Use-kernel-PHY-API-to-set-PHY.patch
This patch uses PHY API phy_set_attrs() to set corresponding PHY properties
in Cadence Torrent PHY driver. This will enable drivers using this PHY to
read these properties using PHY framework.

The phy_get_attrs() API will be used in the DRM bridge driver [1] which is
in the process of upstreaming.

[1]

https://lkml.org/lkml/2020/2/26/263

Version History:

v3:
- Add comment describing new PHY attribute max_link_rate
- Use of memcpy to copy structure members
- Change commit log a bit

v2:
- Implemented single pair of functions to get/set all PHY attributes

Swapnil Jakhade (2):
  phy: Add new PHY attribute max_link_rate and APIs to get/set PHY
attributes
  phy: cadence-torrent: Use kernel PHY API to set PHY attributes

 drivers/phy/cadence/phy-cadence-torrent.c |  7 +++
 include/linux/phy/phy.h   | 22 ++
 2 files changed, 29 insertions(+)

-- 
2.26.1



[RESEND PATCH v3 2/2] mfd: da9063: Add support for latest DA silicon revision

2020-07-13 Thread Adam Thomson
This update adds new regmap tables to support the latest DA silicon
which will automatically be selected based on the chip and variant
information read from the device.

Signed-off-by: Adam Thomson 
Acked-for-MFD-by: Lee Jones 
---

v3:
 - No change

v2:
 - No change

 drivers/mfd/da9063-i2c.c| 91 -
 include/linux/mfd/da9063/core.h |  1 +
 2 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 4815489..b8217ad 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -197,7 +197,7 @@ static int da9063_get_device_type(struct i2c_client *i2c, 
struct da9063 *da9063)
regmap_reg_range(DA9063_BB_REG_GP_ID_0, DA9063_BB_REG_GP_ID_19),
 };
 
-static const struct regmap_range da9063_bb_volatile_ranges[] = {
+static const struct regmap_range da9063_bb_da_volatile_ranges[] = {
regmap_reg_range(DA9063_REG_PAGE_CON, DA9063_REG_EVENT_D),
regmap_reg_range(DA9063_REG_CONTROL_A, DA9063_REG_CONTROL_B),
regmap_reg_range(DA9063_REG_CONTROL_E, DA9063_REG_CONTROL_F),
@@ -219,9 +219,9 @@ static int da9063_get_device_type(struct i2c_client *i2c, 
struct da9063 *da9063)
.n_yes_ranges = ARRAY_SIZE(da9063_bb_writeable_ranges),
 };
 
-static const struct regmap_access_table da9063_bb_volatile_table = {
-   .yes_ranges = da9063_bb_volatile_ranges,
-   .n_yes_ranges = ARRAY_SIZE(da9063_bb_volatile_ranges),
+static const struct regmap_access_table da9063_bb_da_volatile_table = {
+   .yes_ranges = da9063_bb_da_volatile_ranges,
+   .n_yes_ranges = ARRAY_SIZE(da9063_bb_da_volatile_ranges),
 };
 
 static const struct regmap_range da9063l_bb_readable_ranges[] = {
@@ -241,7 +241,7 @@ static int da9063_get_device_type(struct i2c_client *i2c, 
struct da9063 *da9063)
regmap_reg_range(DA9063_BB_REG_GP_ID_0, DA9063_BB_REG_GP_ID_19),
 };
 
-static const struct regmap_range da9063l_bb_volatile_ranges[] = {
+static const struct regmap_range da9063l_bb_da_volatile_ranges[] = {
regmap_reg_range(DA9063_REG_PAGE_CON, DA9063_REG_EVENT_D),
regmap_reg_range(DA9063_REG_CONTROL_A, DA9063_REG_CONTROL_B),
regmap_reg_range(DA9063_REG_CONTROL_E, DA9063_REG_CONTROL_F),
@@ -263,9 +263,64 @@ static int da9063_get_device_type(struct i2c_client *i2c, 
struct da9063 *da9063)
.n_yes_ranges = ARRAY_SIZE(da9063l_bb_writeable_ranges),
 };
 
-static const struct regmap_access_table da9063l_bb_volatile_table = {
-   .yes_ranges = da9063l_bb_volatile_ranges,
-   .n_yes_ranges = ARRAY_SIZE(da9063l_bb_volatile_ranges),
+static const struct regmap_access_table da9063l_bb_da_volatile_table = {
+   .yes_ranges = da9063l_bb_da_volatile_ranges,
+   .n_yes_ranges = ARRAY_SIZE(da9063l_bb_da_volatile_ranges),
+};
+
+static const struct regmap_range da9063_da_readable_ranges[] = {
+   regmap_reg_range(DA9063_REG_PAGE_CON, DA9063_BB_REG_SECOND_D),
+   regmap_reg_range(DA9063_REG_SEQ, DA9063_REG_ID_32_31),
+   regmap_reg_range(DA9063_REG_SEQ_A, DA9063_REG_AUTO3_LOW),
+   regmap_reg_range(DA9063_REG_T_OFFSET, DA9063_BB_REG_GP_ID_11),
+   regmap_reg_range(DA9063_REG_DEVICE_ID, DA9063_REG_VARIANT_ID),
+};
+
+static const struct regmap_range da9063_da_writeable_ranges[] = {
+   regmap_reg_range(DA9063_REG_PAGE_CON, DA9063_REG_PAGE_CON),
+   regmap_reg_range(DA9063_REG_FAULT_LOG, DA9063_REG_VSYS_MON),
+   regmap_reg_range(DA9063_REG_COUNT_S, DA9063_BB_REG_ALARM_Y),
+   regmap_reg_range(DA9063_REG_SEQ, DA9063_REG_ID_32_31),
+   regmap_reg_range(DA9063_REG_SEQ_A, DA9063_REG_AUTO3_LOW),
+   regmap_reg_range(DA9063_REG_CONFIG_I, DA9063_BB_REG_MON_REG_4),
+   regmap_reg_range(DA9063_BB_REG_GP_ID_0, DA9063_BB_REG_GP_ID_11),
+};
+
+static const struct regmap_access_table da9063_da_readable_table = {
+   .yes_ranges = da9063_da_readable_ranges,
+   .n_yes_ranges = ARRAY_SIZE(da9063_da_readable_ranges),
+};
+
+static const struct regmap_access_table da9063_da_writeable_table = {
+   .yes_ranges = da9063_da_writeable_ranges,
+   .n_yes_ranges = ARRAY_SIZE(da9063_da_writeable_ranges),
+};
+
+static const struct regmap_range da9063l_da_readable_ranges[] = {
+   regmap_reg_range(DA9063_REG_PAGE_CON, DA9063_REG_MON_A10_RES),
+   regmap_reg_range(DA9063_REG_SEQ, DA9063_REG_ID_32_31),
+   regmap_reg_range(DA9063_REG_SEQ_A, DA9063_REG_AUTO3_LOW),
+   regmap_reg_range(DA9063_REG_T_OFFSET, DA9063_BB_REG_GP_ID_11),
+   regmap_reg_range(DA9063_REG_DEVICE_ID, DA9063_REG_VARIANT_ID),
+};
+
+static const struct regmap_range da9063l_da_writeable_ranges[] = {
+   regmap_reg_range(DA9063_REG_PAGE_CON, DA9063_REG_PAGE_CON),
+   regmap_reg_range(DA9063_REG_FAULT_LOG, DA9063_REG_VSYS_MON),
+   regmap_reg_range(DA9063_REG_SEQ, DA9063_REG_ID_32_31),
+   regmap_reg_range(DA9063_REG_SEQ_A, DA9063_REG_AUTO3_LOW),
+   regmap_reg_range(DA9063_REG_CONFIG_I, DA9063_BB_REG_MON_REG_4),
+   

[RESEND PATCH v3 1/2] mfd: da9063: Fix revision handling to correctly select reg tables

2020-07-13 Thread Adam Thomson
The current implementation performs checking in the i2c_probe()
function of the variant_code but does this immediately after the
containing struct has been initialised as all zero. This means the
check for variant code will always default to using the BB tables
and will never select AD. The variant code is subsequently set
by device_init() and later used by the RTC so really it's a little
fortunate this mismatch works.

This update adds raw I2C read access functionality to read the chip
and variant/revision information (common to all revisions) so that
it can subsequently correctly choose the proper regmap tables for
real initialisation.

Signed-off-by: Adam Thomson 
---

v3:
 - Replaced magic numbers around I2C paged access code with enums and defines
 - Small style tidy ups as requested by Lee Jones

v2:
 - Use raw I2C read access instead of a temporary regmap to interrogate chip and
   variant id registers

 drivers/mfd/da9063-core.c|  31 --
 drivers/mfd/da9063-i2c.c | 184 +++
 include/linux/mfd/da9063/registers.h |  15 ++-
 3 files changed, 177 insertions(+), 53 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index b125f90d..a353d52 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -160,7 +160,6 @@ static int da9063_clear_fault_log(struct da9063 *da9063)
 
 int da9063_device_init(struct da9063 *da9063, unsigned int irq)
 {
-   int model, variant_id, variant_code;
int ret;
 
ret = da9063_clear_fault_log(da9063);
@@ -171,36 +170,6 @@ int da9063_device_init(struct da9063 *da9063, unsigned int 
irq)
da9063->irq_base = -1;
da9063->chip_irq = irq;
 
-   ret = regmap_read(da9063->regmap, DA9063_REG_CHIP_ID, );
-   if (ret < 0) {
-   dev_err(da9063->dev, "Cannot read chip model id.\n");
-   return -EIO;
-   }
-   if (model != PMIC_CHIP_ID_DA9063) {
-   dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
-   return -ENODEV;
-   }
-
-   ret = regmap_read(da9063->regmap, DA9063_REG_CHIP_VARIANT, _id);
-   if (ret < 0) {
-   dev_err(da9063->dev, "Cannot read chip variant id.\n");
-   return -EIO;
-   }
-
-   variant_code = variant_id >> DA9063_CHIP_VARIANT_SHIFT;
-
-   dev_info(da9063->dev,
-"Device detected (chip-ID: 0x%02X, var-ID: 0x%02X)\n",
-model, variant_id);
-
-   if (variant_code < PMIC_DA9063_BB && variant_code != PMIC_DA9063_AD) {
-   dev_err(da9063->dev,
-   "Cannot support variant code: 0x%02X\n", variant_code);
-   return -ENODEV;
-   }
-
-   da9063->variant_code = variant_code;
-
ret = da9063_irq_init(da9063);
if (ret) {
dev_err(da9063->dev, "Cannot initialize interrupts.\n");
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 455de74..4815489 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -22,12 +22,124 @@
 #include 
 #include 
 
+/*
+ * Raw I2C access required for just accessing chip and variant info before we
+ * know which device is present. The info read from the device using this
+ * approach is then used to select the correct regmap tables.
+ */
+
+#define DA9063_REG_PAGE_SIZE   0x100
+#define DA9063_REG_PAGED_ADDR_MASK 0xFF
+
+enum da9063_page_sel_buf_fmt {
+   DA9063_PAGE_SEL_BUF_PAGE_REG = 0,
+   DA9063_PAGE_SEL_BUF_PAGE_VAL,
+   DA9063_PAGE_SEL_BUF_SIZE,
+};
+
+enum da9063_paged_read_msgs {
+   DA9063_PAGED_READ_MSG_PAGE_SEL = 0,
+   DA9063_PAGED_READ_MSG_REG_SEL,
+   DA9063_PAGED_READ_MSG_DATA,
+   DA9063_PAGED_READ_MSG_CNT,
+};
+
+static int da9063_i2c_blockreg_read(struct i2c_client *client, u16 addr,
+   u8 *buf, int count)
+{
+   struct i2c_msg xfer[DA9063_PAGED_READ_MSG_CNT];
+   u8 page_sel_buf[DA9063_PAGE_SEL_BUF_SIZE];
+   u8 page_num, paged_addr;
+   int ret;
+
+   /* Determine page info based on register address */
+   page_num = (addr / DA9063_REG_PAGE_SIZE);
+   if (page_num > 1) {
+   dev_err(>dev, "Invalid register address provided\n");
+   return -EINVAL;
+   }
+
+   paged_addr = (addr % DA9063_REG_PAGE_SIZE) & DA9063_REG_PAGED_ADDR_MASK;
+   page_sel_buf[DA9063_PAGE_SEL_BUF_PAGE_REG] = DA9063_REG_PAGE_CON;
+   page_sel_buf[DA9063_PAGE_SEL_BUF_PAGE_VAL] =
+   (page_num << DA9063_I2C_PAGE_SEL_SHIFT) & DA9063_REG_PAGE_MASK;
+
+   /* Write reg address, page selection */
+   xfer[DA9063_PAGED_READ_MSG_PAGE_SEL].addr = client->addr;
+   xfer[DA9063_PAGED_READ_MSG_PAGE_SEL].flags = 0;
+   xfer[DA9063_PAGED_READ_MSG_PAGE_SEL].len = DA9063_PAGE_SEL_BUF_SIZE;
+   xfer[DA9063_PAGED_READ_MSG_PAGE_SEL].buf = page_sel_buf;
+
+   /* Select register address */
+   

[RESEND PATCH v3 0/2] Resolve revision handling and add support for DA silicon

2020-07-13 Thread Adam Thomson
This patch set fixes the currently broken revision handling in the driver's
i2c_probe() function and then adds DA support to existing permitted revisions.

v3:
 - Replaced magic numbers around I2C paged access code with enums and defines
 - Small style tidy ups as requested by Lee Jones

v2:
 - Use raw I2C read access instead of a temporary regmap to interrogate chip and
   variant id registers

Adam Thomson (2):
  mfd: da9063: Fix revision handling to correctly select reg tables
  mfd: da9063: Add support for latest DA silicon revision

 drivers/mfd/da9063-core.c|  31 
 drivers/mfd/da9063-i2c.c | 271 +++
 include/linux/mfd/da9063/core.h  |   1 +
 include/linux/mfd/da9063/registers.h |  15 +-
 4 files changed, 257 insertions(+), 61 deletions(-)

-- 
1.9.1



Re: [PATCH v7 2/8] cpufreq: mediatek: Enable clock and regulator

2020-07-13 Thread Viresh Kumar
On 10-07-20, 10:31, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" 
> 
> Need to enable regulator,
> so that the max/min requested value will be recorded
> even it is not applied right away.
> 
> Intermediate clock is not always enabled by ccf in different projects,
> so cpufreq should enable it by itself.
> 
> Change-Id: I9f4c8b1ea793794f5f9cdc65427daad1393f5df8

You are on V7 right now, these should have been gone long back.

> Signed-off-by: Andrew-sh.Cheng 
> ---
>  drivers/cpufreq/mediatek-cpufreq.c | 33 +
>  1 file changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c 
> b/drivers/cpufreq/mediatek-cpufreq.c
> index 0c98dd08273d..4b479c110cc9 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -350,6 +350,11 @@ static int mtk_cpu_dvfs_info_init(struct 
> mtk_cpu_dvfs_info *info, int cpu)
>   ret = PTR_ERR(proc_reg);
>   goto out_free_resources;
>   }
> + ret = regulator_enable(proc_reg);
> + if (ret) {
> + pr_warn("enable vproc for cpu%d fail\n", cpu);
> + goto out_free_resources;
> + }

This is already done by the OPP core now.

-- 
viresh


Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

2020-07-13 Thread Julia Lawall



On Mon, 13 Jul 2020, Takashi Iwai wrote:

> On Mon, 13 Jul 2020 10:43:28 +0200,
> Julia Lawall wrote:
> >
> >
> >
> > On Mon, 13 Jul 2020, Takashi Iwai wrote:
> >
> > > On Wed, 08 Jul 2020 20:14:27 +0200,
> > > Dan Williams wrote:
> > > >
> > > > +Recommended replacements for 'blacklist/whitelist' are:
> > > > +'denylist / allowlist'
> > > > +'blocklist / passlist'
> > >
> > > I started looking through the tree now and noticed there are lots of
> > > patterns like "whitelisted" or "blacklisted".  How can the words fit
> > > for those?  Actually, there are two cases like:
> > >
> > > - Foo is blacklisted
> > > - Allow to load the non-whitelisted cards
> > >
> > > Currently I'm replacing the former with "Foo is in denylist", but not
> >
> > In the denylist?
>
> Not really, only the allowlist exists in this case.

I'm not sure to understand.  in denylist is not grammatical.  It needs "a"
or "the".

Maybe it has to be foo is denylisted?  foo is in the implicit denyList?
foo is not in the allowList?

julia


Re: [PATCH v7 5/8] opp: Modify opp API, dev_pm_opp_get_freq(), find freq in opp, even it is disabled

2020-07-13 Thread Viresh Kumar
On 10-07-20, 10:31, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" 
> 
> Modify dev_pm_opp_get_freq() to return freqeuncy
> even this opp item is not available.
> So that we can get the information of disable opp items.
> 
> Change-Id: I54dacf13050397f5080ccdb8b07d6220e7461e4e
> CR-Id:
> Feature:
> Signed-off-by: Andrew-sh.Cheng 
> ---
>  drivers/opp/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index eed42d6b2e6b..5213e0462382 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -118,7 +118,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
>   */
>  unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
>  {
> - if (IS_ERR_OR_NULL(opp) || !opp->available) {
> + if (IS_ERR_OR_NULL(opp)) {
>   pr_err("%s: Invalid parameters\n", __func__);
>   return 0;
>   }

Please cleanup this patch for all the extra stuff that isn't required mainline
and send it again to me separately from this series.

-- 
viresh


[PATCH] alpha: Kconfig: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 arch/alpha/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 10862c5a8c76..5cb1c9c6e3a8 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -533,7 +533,7 @@ config SMP
  will run faster if you say N here.
 
  See also the SMP-HOWTO available at
- .
+ .
 
  If you don't know what to do here, say N.
 
-- 
2.27.0



Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

2020-07-13 Thread Takashi Iwai
On Mon, 13 Jul 2020 11:39:56 +0200,
Julia Lawall wrote:
> 
> 
> 
> On Mon, 13 Jul 2020, Takashi Iwai wrote:
> 
> > On Mon, 13 Jul 2020 10:43:28 +0200,
> > Julia Lawall wrote:
> > >
> > >
> > >
> > > On Mon, 13 Jul 2020, Takashi Iwai wrote:
> > >
> > > > On Wed, 08 Jul 2020 20:14:27 +0200,
> > > > Dan Williams wrote:
> > > > >
> > > > > +Recommended replacements for 'blacklist/whitelist' are:
> > > > > +'denylist / allowlist'
> > > > > +'blocklist / passlist'
> > > >
> > > > I started looking through the tree now and noticed there are lots of
> > > > patterns like "whitelisted" or "blacklisted".  How can the words fit
> > > > for those?  Actually, there are two cases like:
> > > >
> > > > - Foo is blacklisted
> > > > - Allow to load the non-whitelisted cards
> > > >
> > > > Currently I'm replacing the former with "Foo is in denylist", but not
> > >
> > > In the denylist?
> >
> > Not really, only the allowlist exists in this case.
> 
> I'm not sure to understand.  in denylist is not grammatical.  It needs "a"
> or "the".

Ah, now I see how I confused you.  The two cases I mentioned in the
above are completely individual.  They were found in two different
drivers.  I put those just as two distinct examples for the passive
form usages.  Sorry for unclearness.

What I meant about the latter was that "not in allowlist" doesn't mean
it being "in denylist".  It's simply unknown.


Takashi


drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c:365:6: warning: no previous prototype for 'mt7915_sta_add_debugfs'

2020-07-13 Thread kernel test robot
Hi Ryder,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   11ba468877bb23f28956a35e896356252d63c983
commit: ec9742a8f38ef69876e9f04be68d985c6bbb8f5f mt76: mt7915: add 
.sta_add_debugfs support
date:   9 weeks ago
config: i386-randconfig-r025-20200713 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
git checkout ec9742a8f38ef69876e9f04be68d985c6bbb8f5f
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c:365:6: warning: no 
>> previous prototype for 'mt7915_sta_add_debugfs' [-Wmissing-prototypes]
 365 | void mt7915_sta_add_debugfs(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 |  ^~

vim +/mt7915_sta_add_debugfs +365 
drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c

   364  
 > 365  void mt7915_sta_add_debugfs(struct ieee80211_hw *hw, struct 
 > ieee80211_vif *vif,

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: [PATCH v4 4/4] thermal: core: Add notifications call in the framework

2020-07-13 Thread Daniel Lezcano


Added Arnd in Cc.

On 13/07/2020 11:31, Marek Szyprowski wrote:
> Hi
> 
> On 07.07.2020 11:15, Marek Szyprowski wrote:
>> On 06.07.2020 15:46, Daniel Lezcano wrote:
>>> On 06/07/2020 15:17, Marek Szyprowski wrote:
 On 06.07.2020 12:55, Daniel Lezcano wrote:
> The generic netlink protocol is implemented but the different
> notification functions are not yet connected to the core code.
>
> These changes add the notification calls in the different
> corresponding places.
>
> Reviewed-by: Amit Kucheria 
> Signed-off-by: Daniel Lezcano 
 This patch landed in today's linux-next 20200706 as commit 5df786e46560
 ("thermal: core: Add notifications call in the framework"). Sadly it
 breaks booting various Samsung Exynos based boards. Here is an example
 log from Odroid U3 board:

 Unable to handle kernel NULL pointer dereference at virtual address 
 0010
 pgd = (ptrval)
 [0010] *pgd=
 Internal error: Oops: 5 [#1] PREEMPT SMP ARM
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3-00015-g5df786e46560
 #1146
 Hardware name: Samsung Exynos (Flattened Device Tree)
 PC is at kmem_cache_alloc+0x13c/0x418
 LR is at kmem_cache_alloc+0x48/0x418
 pc : []    lr : []    psr: 2053
 ...
 Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
 Control: 10c5387d  Table: 4000404a  DAC: 0051
 Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
 Stack: (0xee8f1cf8 to 0xee8f2000)
 ...
 [] (kmem_cache_alloc) from [] 
 (__alloc_skb+0x5c/0x170)
 [] (__alloc_skb) from []
 (thermal_genl_send_event+0x24/0x174)
 [] (thermal_genl_send_event) from []
 (thermal_notify_tz_create+0x58/0x74)
 [] (thermal_notify_tz_create) from []
 (thermal_zone_device_register+0x358/0x650)
 [] (thermal_zone_device_register) from []
 (of_parse_thermal_zones+0x304/0x7a4)
 [] (of_parse_thermal_zones) from []
 (thermal_init+0xdc/0x154)
 [] (thermal_init) from [] 
 (do_one_initcall+0x8c/0x424)
 [] (do_one_initcall) from []
 (kernel_init_freeable+0x190/0x204)
 [] (kernel_init_freeable) from []
 (kernel_init+0x8/0x118)
 [] (kernel_init) from [] (ret_from_fork+0x14/0x20)

 Reverting it on top of linux-next fixes the boot issue. I will
 investigate it further soon.
>>> Thanks for reporting this.
>>>
>>> Can you send the addr2line result and code it points to ?
>>
>> addr2line of c02b5cac (kmem_cache_alloc+0x13c/0x418) points to 
>> mm/slub.c +2839, but I'm not sure if we can trust it. imho it looks 
>> like some trashed memory somewhere, but I don't have time right now to 
>> analyze it further now...
> 
> Just one more thing I've noticed. The crash happens only if the kernel 
> is compiled with old GCC (tested with arm-linux-gnueabi-gcc (Linaro GCC 
> 4.9-2017.01) 4.9.4). If I compile kernel with newed GCC (like 
> arm-linux-gnueabi-gcc (Linaro GCC 6.4-2017.11) 6.4.1 20171012), it works 
> fine...
> 
> This happens also with Linux next-20200710, which again got this commit.
Arnd,

are you aware of any issue with this gcc version which can explain this
kernel panic ? Sounds like the problem does not appear with more recent
version.

-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


Re: [PATCH] asm-generic/sembuf: Update architecture related information in comment

2020-07-13 Thread Viresh Kumar
On 20-05-20, 15:53, Viresh Kumar wrote:
> The structure came originally from x86_32 but is used by most of the
> architectures now. Update the comment which says it is for x86 only.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  include/uapi/asm-generic/sembuf.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/uapi/asm-generic/sembuf.h 
> b/include/uapi/asm-generic/sembuf.h
> index 0e709bd3d730..f54e48fc91ae 100644
> --- a/include/uapi/asm-generic/sembuf.h
> +++ b/include/uapi/asm-generic/sembuf.h
> @@ -6,9 +6,9 @@
>  #include 
>  
>  /*
> - * The semid64_ds structure for x86 architecture.
> - * Note extra padding because this structure is passed back and forth
> - * between kernel and user space.
> + * The semid64_ds structure for most architectures (though it came from 
> x86_32
> + * originally). Note extra padding because this structure is passed back and
> + * forth between kernel and user space.
>   *
>   * semid64_ds was originally meant to be architecture specific, but
>   * everyone just ended up making identical copies without specific

Arnd, Ping.

-- 
viresh


Re: [PATCH 3/3] ARM: dts: colibri-imx7: add usb dual-role switch capability

2020-07-13 Thread Ahmad Fatoum
Hello Philippe,

On 7/10/20 3:24 PM, Philippe Schenker wrote:
> Since the runtime-pm wakeup bug was fixed in
> drivers/usb/chipidea/core.c usb dual-role host/device switching is
> working. So make use of it.
> 
> Signed-off-by: Philippe Schenker 
> 
> ---
> 
>  arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 9 +
>  arch/arm/boot/dts/imx7-colibri.dtsi | 4 ++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi 
> b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> index 97601375f264..db56a532a34a 100644
> --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> @@ -20,6 +20,14 @@ clk16m: clk16m {
>   clock-frequency = <1600>;
>   };
>  
> + extcon_usbc_det: usbc_det {
> + compatible = "linux,extcon-usb-gpio";

According to 4602f3bff266 ("usb: common: add USB GPIO based connection 
detection driver"):
"the old way using extcon to support USB Dual-Role switch is now deprecated
 when use Type-B connector."

Have you considered using a compatible = "gpio-usb-b-connector" child node 
instead?

Cheers,
Ahmad

> + id-gpio = < 14 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_usbc_det>;
> + };
> +
> +
>   gpio-keys {
>   compatible = "gpio-keys";
>   pinctrl-names = "default";
> @@ -174,6 +182,7 @@  {
>  };
>  
>   {
> + extcon = <0>, <_usbc_det>;
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi 
> b/arch/arm/boot/dts/imx7-colibri.dtsi
> index e18e89dec879..caea90d2421f 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -457,7 +457,7 @@  {
>  };
>  
>   {
> - dr_mode = "host";
> + dr_mode = "otg";
>  };
>  
>   {
> @@ -486,7 +486,7 @@  {
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_gpio1 _gpio2 _gpio3 _gpio4
> -  _gpio7 _usbc_det>;
> +  _gpio7>;
>  
>   pinctrl_gpio1: gpio1-grp {
>   fsl,pins = <
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [PATCH v8 00/12] Introduce CAP_PERFMON to secure system performance monitoring and observability

2020-07-13 Thread Alexey Budankov


On 10.07.2020 20:09, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 10, 2020 at 05:30:50PM +0300, Alexey Budankov escreveu:
>> On 10.07.2020 16:31, Ravi Bangoria wrote:
 Currently access to perf_events, i915_perf and other performance
 monitoring and observability subsystems of the kernel is open only for
 a privileged process [1] with CAP_SYS_ADMIN capability enabled in the
 process effective set [2].
> 
 This patch set introduces CAP_PERFMON capability designed to secure
 system performance monitoring and observability operations so that
 CAP_PERFMON would assist CAP_SYS_ADMIN capability in its governing role
 for performance monitoring and observability subsystems of the kernel.
>  
>>> I'm seeing an issue with CAP_PERFMON when I try to record data for a
>>> specific target. I don't know whether this is sort of a regression or
>>> an expected behavior.
>  
>> Thanks for reporting and root causing this case. The behavior looks like
>> kind of expected since currently CAP_PERFMON takes over the related part
>> of CAP_SYS_ADMIN credentials only. Actually Perf security docs [1] say
>> that access control is also subject to CAP_SYS_PTRACE credentials.
> 
> I think that stating that in the error message would be helpful, after
> all, who reads docs? 8-)

At least those who write it :D ...

> 
> I.e., this:
> 
> $ ./perf stat ls
>   Error:
>   Access to performance monitoring and observability operations is limited.
> $
> 
> Could become:
> 
> $ ./perf stat ls
>   Error:
>   Access to performance monitoring and observability operations is limited.
>   Right now only CAP_PERFMON is granted, you may need CAP_SYS_PTRACE.
> $

It would better provide reference to perf security docs in the tool output.
Looks like extending ptrace_may_access() check for perf_events with CAP_PERFMON
makes monitoring simpler and even more secure to use since Perf tool need
not to start/stop/single-step and read/write registers and memory and so on
like a debugger or strace-like tool. What do you think?

Alexei

> 
> - Arnaldo
>  
>> CAP_PERFMON could be used to extend and substitute ptrace_may_access()
>> check in perf_events subsystem to simplify user experience at least in
>> this specific case.
>>
>> Alexei
>>
>> [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
>>
>>>
>>> Without setting CAP_PERFMON:
>>>
>>>   $ getcap ./perf
>>>   $ ./perf stat -a ls
>>>     Error:
>>>     Access to performance monitoring and observability operations is 
>>> limited.
>>>   $ ./perf stat ls
>>>     Performance counter stats for 'ls':
>>>     2.06 msec task-clock:u  #    0.418 CPUs 
>>> utilized
>>>     0  context-switches:u    #    0.000 K/sec
>>>     0  cpu-migrations:u  #    0.000 K/sec
>>>
>>> With CAP_PERFMON:
>>>
>>>   $ getcap ./perf
>>>     ./perf = cap_perfmon+ep
>>>   $ ./perf stat -a ls
>>>     Performance counter stats for 'system wide':
>>>       142.42 msec cpu-clock #   25.062 CPUs 
>>> utilized
>>>   182  context-switches  #    0.001 M/sec
>>>    48  cpu-migrations    #    0.337 K/sec
>>>   $ ./perf stat ls
>>>     Error:
>>>     Access to performance monitoring and observability operations is 
>>> limited.
>>>
>>> Am I missing something silly?
>>>
>>> Analysis:
>>> -
>>> A bit more analysis lead me to below kernel code fs/exec.c:
>>>
>>>   begin_new_exec()
>>>   {
>>>     ...
>>>     if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP ||
>>>     !(uid_eq(current_euid(), current_uid()) &&
>>>   gid_eq(current_egid(), current_gid(
>>>     set_dumpable(current->mm, suid_dumpable);
>>>     else
>>>     set_dumpable(current->mm, SUID_DUMP_USER);
>>>
>>>     ...
>>>     commit_creds(bprm->cred);
>>>   }
>>>
>>> When I execute './perf stat ls', it's going into else condition and thus 
>>> sets
>>> dumpable flag as SUID_DUMP_USER. Then in commit_creds():
>>>
>>>   int commit_creds(struct cred *new)
>>>   {
>>>     ...
>>>     /* dumpability changes */
>>>     if (...
>>>     !cred_cap_issubset(old, new)) {
>>>     if (task->mm)
>>>     set_dumpable(task->mm, suid_dumpable);
>>>   }
>>>
>>> !cred_cap_issubset(old, new) fails for perf without any capability and thus
>>> it doesn't execute set_dumpable(). Whereas that condition passes for perf
>>> with CAP_PERFMON and thus it overwrites old value (SUID_DUMP_USER) with
>>> suid_dumpable in mm_flags. On an Ubuntu, suid_dumpable default value is
>>> SUID_DUMP_ROOT. On Fedora, it's SUID_DUMP_DISABLE. 
>>> (/proc/sys/fs/suid_dumpable).
>>>
>>> Now while opening an event:
>>>
>>>   perf_event_open()
>>>     ptrace_may_access()
>>>   __ptrace_may_access() {
>>>     ...
>>>     if (mm &&
>>>     

Build regressions/improvements in v5.8-rc5

2020-07-13 Thread Geert Uytterhoeven
Below is the list of build error/warning regressions/improvements in
v5.8-rc5[1] compared to v5.7[2].

Summarized:
  - build errors: +7/-4
  - build warnings: +39/-41

JFYI, when comparing v5.8-rc5[1] to v5.8-rc4[3], the summaries are:
  - build errors: +3/-0
  - build warnings: +1/-0

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/11ba468877bb23f28956a35e896356252d63c983/
 (192 out of 194 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162/
 (all 194 configs)
[3] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258/
 (192 out of 194 configs)


*** ERRORS ***

7 error regressions:
  + /kisskb/src/include/linux/compiler-gcc.h: error: #error Sorry, your 
compiler is too old - please upgrade it.:  => 15:3
  + /kisskb/src/include/linux/compiler.h: error: implicit declaration of 
function '_Generic' [-Werror=implicit-function-declaration]:  => 309:2
  + /kisskb/src/include/linux/compiler_types.h: error: expected expression 
before 'char':  => 265:5
  + error: arch/sparc/kernel/head_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against `.init.text':  => (.head.text+0x5040), 
(.head.text+0x5100)
  + error: arch/sparc/kernel/head_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section 
in arch/sparc/kernel/trampoline_32.o:  => (.init.text+0xa4)
  + error: arch/sparc/kernel/process_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against `.text':  => (.fixup+0x4), (.fixup+0xc)
  + error: arch/sparc/kernel/signal_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against `.text':  => (.fixup+0x28), (.fixup+0x34), 
(.fixup+0x10), (.fixup+0x1c), (.fixup+0x4)

4 error improvements:
  - error: modpost: "devm_ioremap" [drivers/net/ethernet/xilinx/ll_temac.ko] 
undefined!: N/A => 
  - error: modpost: "devm_ioremap_resource" 
[drivers/net/ethernet/xilinx/xilinx_emac.ko] undefined!: N/A => 
  - error: modpost: "devm_ioremap_resource" [drivers/ptp/ptp_ines.ko] 
undefined!: N/A => 
  - error: modpost: "devm_of_iomap" [drivers/net/ethernet/xilinx/ll_temac.ko] 
undefined!: N/A => 


*** WARNINGS ***

39 warning regressions:
  + /kisskb/src/block/genhd.c: warning: the frame size of 1160 bytes is larger 
than 1024 bytes [-Wframe-larger-than=]:  => 1623:1
  + /kisskb/src/drivers/gpu/drm/drm_managed.c: warning: format '%zu' expects 
argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]:  
=> 205:23
  + /kisskb/src/drivers/gpu/drm/drm_managed.c: warning: format '%zu' expects 
argument of type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]:  
=> 67:23
  + /kisskb/src/drivers/mailbox/imx-mailbox.c: warning: 'imx_mu_resume_noirq' 
defined but not used [-Wunused-function]:  => 611:12
  + /kisskb/src/drivers/mailbox/imx-mailbox.c: warning: 'imx_mu_runtime_resume' 
defined but not used [-Wunused-function]:  => 638:12
  + /kisskb/src/drivers/mailbox/imx-mailbox.c: warning: 
'imx_mu_runtime_suspend' defined but not used [-Wunused-function]:  => 629:12
  + /kisskb/src/drivers/mailbox/imx-mailbox.c: warning: 'imx_mu_suspend_noirq' 
defined but not used [-Wunused-function]:  => 601:12
  + /kisskb/src/drivers/net/ethernet/intel/ice/ice_flow.h: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]:  => 197:33
  + /kisskb/src/drivers/net/ethernet/intel/ice/ice_flow.h: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]:  => 198:32
  + /kisskb/src/drivers/scsi/dc395x.c: warning: value computed is not used 
[-Wunused-value]:  => 155:36
  + /kisskb/src/drivers/target/iscsi/cxgbit/cxgbit_target.c: warning: 
'cxgbit_tx_datain_iso.isra.39' uses dynamic stack allocation:  => 498:1
  + /kisskb/src/include/linux/compiler_attributes.h: warning: statement will 
never be executed [-Wswitch-unreachable]:  => 201:41
  + /kisskb/src/include/linux/kern_levels.h: warning: format '%zd' expects 
argument of type 'signed size_t', but argument 2 has type 'ssize_t {aka int}' 
[-Wformat=]:  => 5:18
  + /kisskb/src/kernel/bpf/syscall.c: warning: 
'bpf_prog_get_info_by_fd.isra.24' uses dynamic stack allocation:  => 3498:1
  + /kisskb/src/kernel/dma/pool.c: warning: format '%zu' expects argument of 
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]:  => 249:16
  + /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.57' uses dynamic 
stack allocation:  => 2230:1
  + /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.56' uses dynamic 
stack allocation:  => 1929:1
  + /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.55' uses dynamic 
stack allocation:  => 2298:1
  + /kisskb/src/net/smc/smc_llc.c: warning: (near initialization for 
'add_llc.hd') [-Wmissing-braces]:  => 1164:9
  + 

[PATCH] arch/sparc: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 arch/sparc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 5bf2dc163540..5f724e53ce9b 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -175,7 +175,7 @@ config SMP
  Management" code will be disabled if you say Y here.
 
  See also  and 
the SMP-HOWTO
- available at .
+ available at .
 
  If you don't know what to do here, say N.
 
-- 
2.27.0



Re: [LKP] Re: [bpf] af7ec13833: will-it-scale.per_process_ops -2.5% regression

2020-07-13 Thread Feng Tang
On Fri, Jul 03, 2020 at 01:54:39PM +0800, Rong Chen wrote:
> > This commit should not cause regression.
> >
> > Probably the variation of performance is caused by test environment 
> > which you may want to investigate further to reduce false alarming.
> > Thanks!
> 
> Hi Yonghong,
> 
> It's a function align issue, the commit effects the align of functions 
> which causes a little regression,
> we force to set -falign-functions=32 in KBUILD_CFLAGS and the regression 
> is gone:
> 
> diff --git a/Makefile b/Makefile
> index 70def4907036c..9746afa4edc21 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -476,7 +476,7 @@ LINUXINCLUDE牋? := \
>  牋牋牋? $(USERINCLUDE)
> 
>  燢BUILD_AFLAGS牋 := -D__ASSEMBLY__ -fno-PIE
> -KBUILD_CFLAGS牋 := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
> +KBUILD_CFLAGS牋 := -Wall -Wundef -falign-functions=32 
> -Werror=strict-prototypes -Wno-trigraphs \
>  牋 -fno-strict-aliasing -fno-common -fshort-wchar 
> -fno-PIE \
>  牋 -Werror=implicit-function-declaration 
> -Werror=implicit-int \
>  牋 -Wno-format-security \
 
For these strange performance change cases caused by a seemingly
unrelated commit, we have used this function alignment patch to
explain some of them to be caused by re-arrange of text code
alignment [1][2]

So one bold thought is can we merge this option into mainline under
a kernel config option in 'kernel hacking' category, with which both
developers and 0day can filter out some cases to be related with text
alignment change more easily?

[1] [LKP][mm] fd4d9c7d0c: stress-ng.switch.ops_per_sec -30.5% regression
https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/ 
[2] [mm/hugetlb] c77c0a8ac4: will-it-scale.per_process_ops 15.9% improvement
https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
(this patch is not used in the discussion, but we later used
this patch to confirm it's a text alignment case)

Thanks,
Feng



[PATCH] arm64: dts: ipq6018: Add NAND nodes

2020-07-13 Thread Robert Marko
IPQ6018 uses the same NAND and controller as IPQ8074 which
is supported by the Qualcomm NANDC driver.
So lets add the NAND node as well as node for the BAM DMA
controller that is supported by the BAM DMA driver.

Signed-off-by: Robert Marko 
---
 arch/arm64/boot/dts/qcom/ipq6018.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi 
b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 1aa8d8579463..bd4a1317c4c6 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -274,6 +274,33 @@ i2c_1: i2c@78b7000 { /* BLSP1 QUP2 */
status = "disabled";
};
 
+   qpic_bam: dma@7984000{
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7984000 0x1a000>;
+   interrupts = ;
+   clocks = < GCC_QPIC_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   status = "disabled";
+   };
+
+   nand: qpic-nand@79b {
+   compatible = "qcom,ipq8074-nand";
+   reg = <0x79b 0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <_bam 0>,
+  <_bam 1>,
+  <_bam 2>;
+   dma-names = "tx", "rx", "cmd";
+   status = "disabled";
+   };
+
intc: interrupt-controller@b00 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
-- 
2.26.2



Re: Build regressions/improvements in v5.8-rc5

2020-07-13 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:51 AM Geert Uytterhoeven
 wrote:
> JFYI, when comparing v5.8-rc5[1] to v5.8-rc4[3], the summaries are:
>   - build errors: +3/-0

  + /kisskb/src/include/linux/compiler-gcc.h: error: #error Sorry,
your compiler is too old - please upgrade it.:  => 15:3
  + /kisskb/src/include/linux/compiler.h: error: implicit declaration
of function '_Generic' [-Werror=implicit-function-declaration]:  =>
309:2
  + /kisskb/src/include/linux/compiler_types.h: error: expected
expression before 'char':  => 265:5

arcompact/axs101_defconfig, which uses a pre-v4.9 gcc:

Compiler: arcompact (arc-buildroot-linux-uclibc-gcc (Buildroot
2015.08.1) 4.8.4 / GNU ld (GNU Binutils) 2.23.2)

While at it, you may also want to upgrade

Compiler: arcv2 (arc-linux-gcc.br_real (Buildroot
2016.11-git-00613-ge98b4dd) 6.2.1 20160824 / GNU ld (GNU Binutils)
2.27.51.20160928)

as it has a buggy definition of size_t, and causes bogus warnings like:

>   + /kisskb/src/drivers/gpu/drm/drm_managed.c: warning: format '%zu' expects 
> argument of type 'size_t', but argument 4 has type 'unsigned int' 
> [-Wformat=]:  => 205:23
>   + /kisskb/src/drivers/gpu/drm/drm_managed.c: warning: format '%zu' expects 
> argument of type 'size_t', but argument 6 has type 'unsigned int' 
> [-Wformat=]:  => 67:23
>   + /kisskb/src/include/linux/kern_levels.h: warning: format '%zd' expects 
> argument of type 'signed size_t', but argument 2 has type 'ssize_t {aka int}' 
> [-Wformat=]:  => 5:18
>   + /kisskb/src/kernel/dma/pool.c: warning: format '%zu' expects argument of 
> type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]:  => 249:16

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH 0/2] MTE support for KVM guest

2020-07-13 Thread Steven Price
These patches add support to KVM to enable MTE within a guest. They are
based on Catalin's v6 MTE user-space support series[1]. Changes since
the previous RFC posting[2]:

* Correctly read/write TFSR_EL1 using {read,write}_sysreg_el1()
* Set SCTLR_EL2.ITFSB bit for non-VHE
* Minor updates to deal with rebasing

[1] https://lore.kernel.org/r/20200703153718.16973-1-catalin.mari...@arm.com
[2] https://lore.kernel.org/r/20200617123844.29960-1-steven.pr...@arm.com

Steven Price (2):
  arm64: kvm: Save/restore MTE registers
  arm64: kvm: Introduce MTE VCPU feature

 arch/arm64/include/asm/kvm_emulate.h |  3 +++
 arch/arm64/include/asm/kvm_host.h|  9 -
 arch/arm64/include/asm/sysreg.h  |  3 ++-
 arch/arm64/include/uapi/asm/kvm.h|  1 +
 arch/arm64/kvm/hyp/sysreg-sr.c   | 14 ++
 arch/arm64/kvm/mmu.c | 15 +++
 arch/arm64/kvm/reset.c   |  8 
 arch/arm64/kvm/sys_regs.c|  8 
 8 files changed, 59 insertions(+), 2 deletions(-)

-- 
2.20.1



[PATCH 1/2] arm64: kvm: Save/restore MTE registers

2020-07-13 Thread Steven Price
Define the new system registers that MTE introduces and context switch
them. Also hide the MTE feature from the ID register as it isn't
supported in a VM yet.

Signed-off-by: Steven Price 
---
 arch/arm64/include/asm/kvm_host.h |  7 +++
 arch/arm64/include/asm/sysreg.h   |  3 ++-
 arch/arm64/kvm/hyp/sysreg-sr.c| 14 ++
 arch/arm64/kvm/sys_regs.c |  7 +++
 4 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index c3e6fcc664b1..1fc306705193 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -95,6 +95,9 @@ struct kvm_arch {
 * supported.
 */
bool return_nisv_io_abort_to_user;
+
+   /* If any VCPU has MTE enabled then all memory must be MTE enabled */
+   bool vcpu_has_mte;
 };
 
 #define KVM_NR_MEM_OBJS 40
@@ -122,6 +125,8 @@ enum vcpu_sysreg {
SCTLR_EL1,  /* System Control Register */
ACTLR_EL1,  /* Auxiliary Control Register */
CPACR_EL1,  /* Coprocessor Access Control */
+   RGSR_EL1,   /* Random Allocation Tag Seed Register */
+   GCR_EL1,/* Tag Control Register */
ZCR_EL1,/* SVE Control */
TTBR0_EL1,  /* Translation Table Base Register 0 */
TTBR1_EL1,  /* Translation Table Base Register 1 */
@@ -138,6 +143,8 @@ enum vcpu_sysreg {
TPIDR_EL1,  /* Thread ID, Privileged */
AMAIR_EL1,  /* Aux Memory Attribute Indirection Register */
CNTKCTL_EL1,/* Timer Control Register (EL1) */
+   TFSRE0_EL1, /* Tag Fault Status Register (EL0) */
+   TFSR_EL1,   /* Tag Fault Stauts Register (EL1) */
PAR_EL1,/* Physical Address Register */
MDSCR_EL1,  /* Monitor Debug System Control Register */
MDCCINT_EL1,/* Monitor Debug Comms Channel Interrupt Enable Reg */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d6357c4ea015..309dda5dc45c 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -563,7 +563,8 @@
 #define SCTLR_ELx_M(BIT(0))
 
 #define SCTLR_ELx_FLAGS(SCTLR_ELx_M  | SCTLR_ELx_A | SCTLR_ELx_C | \
-SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB)
+SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB | \
+SCTLR_ELx_ITFSB)
 
 /* SCTLR_EL2 specific flags. */
 #define SCTLR_EL2_RES1 ((BIT(4))  | (BIT(5))  | (BIT(11)) | (BIT(16)) | \
diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index cc7e957f5b2c..148561412e6f 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -27,6 +27,11 @@
 static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
 {
ctxt->sys_regs[MDSCR_EL1]   = read_sysreg(mdscr_el1);
+   if (system_supports_mte()) {
+   ctxt->sys_regs[RGSR_EL1] = read_sysreg_s(SYS_RGSR_EL1);
+   ctxt->sys_regs[GCR_EL1] = read_sysreg_s(SYS_GCR_EL1);
+   ctxt->sys_regs[TFSRE0_EL1] = read_sysreg_s(SYS_TFSRE0_EL1);
+   }
 }
 
 static void __hyp_text __sysreg_save_user_state(struct kvm_cpu_context *ctxt)
@@ -54,6 +59,8 @@ static void __hyp_text __sysreg_save_el1_state(struct 
kvm_cpu_context *ctxt)
ctxt->sys_regs[CNTKCTL_EL1] = read_sysreg_el1(SYS_CNTKCTL);
ctxt->sys_regs[PAR_EL1] = read_sysreg(par_el1);
ctxt->sys_regs[TPIDR_EL1]   = read_sysreg(tpidr_el1);
+   if (system_supports_mte())
+   ctxt->sys_regs[TFSR_EL1] = read_sysreg_el1(SYS_TFSR);
 
ctxt->gp_regs.sp_el1= read_sysreg(sp_el1);
ctxt->gp_regs.elr_el1   = read_sysreg_el1(SYS_ELR);
@@ -93,6 +100,11 @@ NOKPROBE_SYMBOL(sysreg_save_guest_state_vhe);
 static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context 
*ctxt)
 {
write_sysreg(ctxt->sys_regs[MDSCR_EL1],   mdscr_el1);
+   if (system_supports_mte()) {
+   write_sysreg_s(ctxt->sys_regs[RGSR_EL1], SYS_RGSR_EL1);
+   write_sysreg_s(ctxt->sys_regs[GCR_EL1], SYS_GCR_EL1);
+   write_sysreg_s(ctxt->sys_regs[TFSRE0_EL1], SYS_TFSRE0_EL1);
+   }
 }
 
 static void __hyp_text __sysreg_restore_user_state(struct kvm_cpu_context 
*ctxt)
@@ -136,6 +148,8 @@ static void __hyp_text __sysreg_restore_el1_state(struct 
kvm_cpu_context *ctxt)
write_sysreg_el1(ctxt->sys_regs[CNTKCTL_EL1],   SYS_CNTKCTL);
write_sysreg(ctxt->sys_regs[PAR_EL1],   par_el1);
write_sysreg(ctxt->sys_regs[TPIDR_EL1], tpidr_el1);
+   if (system_supports_mte())
+   write_sysreg_el1(ctxt->sys_regs[TFSR_EL1], SYS_TFSR);
 
if (!has_vhe() &&
cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT) &&
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index baf5ce9225ce..5ca974c93bd4 100644
--- 

Re: [PATCH v1 2/6] [media] cx23885: use generic power management

2020-07-13 Thread Hans Verkuil
On 29/06/2020 09:36, Vaibhav Gupta wrote:
> The .suspend() and .resume() callbacks are not defined for this driver.
> Still, their power managemgement stucture can be easily upgraded to

management structure

> gemeric, without affecting its normal behaviour.

generic

> 
> Hence, define them NULL and use struct dev_pm_ops type to bind them.
> 
> Compile-tested only.
> 
> Signed-off-by: Vaibhav Gupta 
> ---
>  drivers/media/pci/cx23885/cx23885-core.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 7e0b0b7cc2a3..da9ee7270dfd 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -2230,14 +2230,18 @@ static const struct pci_device_id cx23885_pci_tbl[] = 
> {
>  };
>  MODULE_DEVICE_TABLE(pci, cx23885_pci_tbl);
>  
> +#define cx23885_suspend NULL
> +#define cx23885_resume NULL
> +
> +static SIMPLE_DEV_PM_OPS(cx23885_pm_ops, cx23885_suspend, cx23885_resume);
> +
>  static struct pci_driver cx23885_pci_driver = {
> - .name = "cx23885",
> - .id_table = cx23885_pci_tbl,
> - .probe= cx23885_initdev,
> - .remove   = cx23885_finidev,
> + .name  = "cx23885",
> + .id_table  = cx23885_pci_tbl,
> + .probe = cx23885_initdev,
> + .remove= cx23885_finidev,
>   /* TODO */
> - .suspend  = NULL,
> - .resume   = NULL,
> + .driver.pm = _pm_ops,

I don't entirely understand this. Wouldn't it be sufficient to just
drop the .suspend/.resume assignments here? It is now required for
driver.pm to be non-NULL?

I'm not up to speed on the changes, but normally you can leave things
NULL if you don't support a feature (PM in this case).

Regards,

Hans

>  };
>  
>  static int __init cx23885_init(void)
> 



[PATCH 2/2] arm64: kvm: Introduce MTE VCPU feature

2020-07-13 Thread Steven Price
Add a new VCPU features 'KVM_ARM_VCPU_MTE' which enables memory tagging
on a VCPU. When enabled on any VCPU in the virtual machine this causes
all pages that are faulted into the VM to have the PG_mte_tagged flag
set (and the tag storage cleared if this is the first use).

Signed-off-by: Steven Price 
---
 arch/arm64/include/asm/kvm_emulate.h |  3 +++
 arch/arm64/include/asm/kvm_host.h|  2 +-
 arch/arm64/include/uapi/asm/kvm.h|  1 +
 arch/arm64/kvm/mmu.c | 15 +++
 arch/arm64/kvm/reset.c   |  8 
 arch/arm64/kvm/sys_regs.c|  3 ++-
 6 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index 4d0f8ea600ba..1e4280f9a5ce 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -79,6 +79,9 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
if (cpus_have_const_cap(ARM64_MISMATCHED_CACHE_TYPE) ||
vcpu_el1_is_32bit(vcpu))
vcpu->arch.hcr_el2 |= HCR_TID2;
+
+   if (test_bit(KVM_ARM_VCPU_MTE, vcpu->arch.features))
+   vcpu->arch.hcr_el2 |= HCR_ATA;
 }
 
 static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index 1fc306705193..586b250f683b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -37,7 +37,7 @@
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
-#define KVM_VCPU_MAX_FEATURES 7
+#define KVM_VCPU_MAX_FEATURES 8
 
 #define KVM_REQ_SLEEP \
KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
diff --git a/arch/arm64/include/uapi/asm/kvm.h 
b/arch/arm64/include/uapi/asm/kvm.h
index ba85bb23f060..2677e1ab8c16 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -106,6 +106,7 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_SVE   4 /* enable SVE for this CPU */
 #define KVM_ARM_VCPU_PTRAUTH_ADDRESS   5 /* VCPU uses address authentication */
 #define KVM_ARM_VCPU_PTRAUTH_GENERIC   6 /* VCPU uses generic authentication */
+#define KVM_ARM_VCPU_MTE   7 /* VCPU supports Memory Tagging */
 
 struct kvm_vcpu_init {
__u32 target;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8c0035cab6b6..8d405701f534 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1940,6 +1940,21 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
phys_addr_t fault_ipa,
if (vma_pagesize == PAGE_SIZE && !force_pte)
vma_pagesize = transparent_hugepage_adjust(memslot, hva,
   , _ipa);
+   if (system_supports_mte() && kvm->arch.vcpu_has_mte && pfn_valid(pfn)) {
+   /*
+* VM will be able to see the page's tags, so we must ensure
+* they have been initialised.
+*/
+   struct page *page = pfn_to_page(pfn);
+   long i, nr_pages = compound_nr(page);
+
+   /* if PG_mte_tagged is set, tags have already been initialised 
*/
+   for (i = 0; i < nr_pages; i++, page++) {
+   if (!test_and_set_bit(PG_mte_tagged, >flags))
+   mte_clear_page_tags(page_address(page));
+   }
+   }
+
if (writable)
kvm_set_pfn_dirty(pfn);
 
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 6ed36be51b4b..39fdd95441df 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -275,6 +275,14 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
}
}
 
+   if (test_bit(KVM_ARM_VCPU_MTE, vcpu->arch.features)) {
+   if (!system_supports_mte()) {
+   ret = -EINVAL;
+   goto out;
+   }
+   vcpu->kvm->arch.vcpu_has_mte = true;
+   }
+
switch (vcpu->arch.target) {
default:
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 5ca974c93bd4..0c3c577f98fe 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1105,7 +1105,8 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
val &= ~(0xfUL << ID_AA64PFR0_AMU_SHIFT);
} else if (id == SYS_ID_AA64PFR1_EL1) {
-   val &= ~(0xfUL << ID_AA64PFR1_MTE_SHIFT);
+   if (!test_bit(KVM_ARM_VCPU_MTE, vcpu->arch.features))
+   val &= ~(0xfUL << ID_AA64PFR1_MTE_SHIFT);
} else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
 (0xfUL << ID_AA64ISAR1_API_SHIFT) |
-- 
2.20.1



Re: [PATCH v2 0/3] Power10 basic energy management

2020-07-13 Thread Pratik Sampat

Thank you for your comments,

On 13/07/20 10:53 am, Nicholas Piggin wrote:

Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm:

Changelog v1 --> v2:
1. Save-restore DAWR and DAWRX unconditionally as they are lost in
shallow idle states too
2. Rename pnv_first_spr_loss_level to pnv_first_fullstate_loss_level to
correct naming terminology

Pratik Rajesh Sampat (3):
   powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and above
   powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10
   powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable

  arch/powerpc/platforms/powernv/idle.c | 34 +--
  1 file changed, 22 insertions(+), 12 deletions(-)

These look okay to me, but the CPU_FTR_ARCH_300 test for
pnv_power9_idle_init() is actually wrong, it should be a PVR test
because idle is not completely architected (not even shallow stop
states, unfortunately).

It doesn't look like we support POWER10 idle correctly yet, and on older
kernels it wouldn't work even if we fixed newer, so ideally the PVR
check would be backported as a fix in the front of the series.

Sadly, we have no OPAL idle driver yet. Hopefully we will before the
next processor shows up :P

Thanks,
Nick


So if I understand this correctly, in powernv/idle.c where we check for
CPU_FTR_ARCH_300, we should rather be making a pvr_version_is(PVR_POWER9)
check instead?

Of course, the P10 PVR and its relevant checks will have to be added then too.

Thanks
Pratik

 



Re: [PATCH 2/6] nds32: use uaccess_kernel in show_regs

2020-07-13 Thread Greentime Hu
Christoph Hellwig  於 2020年7月10日 週五 下午9:57寫道:
>
> Use the uaccess_kernel helper instead of duplicating it.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/nds32/kernel/process.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/nds32/kernel/process.c b/arch/nds32/kernel/process.c
> index 9712fd474f2ca3..f06265949ec28b 100644
> --- a/arch/nds32/kernel/process.c
> +++ b/arch/nds32/kernel/process.c
> @@ -121,7 +121,7 @@ void show_regs(struct pt_regs *regs)
> regs->uregs[3], regs->uregs[2], regs->uregs[1], 
> regs->uregs[0]);
> pr_info("  IRQs o%s  Segment %s\n",
> interrupts_enabled(regs) ? "n" : "ff",
> -   segment_eq(get_fs(), KERNEL_DS)? "kernel" : "user");
> +   uaccess_kernel() ? "kernel" : "user");
>  }
>
>  EXPORT_SYMBOL(show_regs);

Hi Christoph, Thank you.
Acked-by: Greentime Hu 


Re: [PATCH v1 3/6] [media] cx25821: use generic power management

2020-07-13 Thread Hans Verkuil
On 29/06/2020 09:36, Vaibhav Gupta wrote:
> The .suspend() and .resume() callbacks are not defined for this driver.
> Still, their power managemgement stucture can be easily upgraded to
> gemeric, without affecting its normal behaviour.
> 
> Hence, define them NULL and use struct dev_pm_ops type to bind them.
> 
> Compile-tested only.
> 
> Signed-off-by: Vaibhav Gupta 
> ---
>  drivers/media/pci/cx25821/cx25821-core.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/cx25821/cx25821-core.c 
> b/drivers/media/pci/cx25821/cx25821-core.c
> index 41be22ce66f3..59501939d741 100644
> --- a/drivers/media/pci/cx25821/cx25821-core.c
> +++ b/drivers/media/pci/cx25821/cx25821-core.c
> @@ -1369,14 +1369,18 @@ static const struct pci_device_id cx25821_pci_tbl[] = 
> {
>  
>  MODULE_DEVICE_TABLE(pci, cx25821_pci_tbl);
>  
> +#define cx25821_suspend NULL
> +#define cx25821_resume NULL
> +
> +static SIMPLE_DEV_PM_OPS(cx25821_pm_ops, cx25821_suspend, cx25821_resume);
> +
>  static struct pci_driver cx25821_pci_driver = {
>   .name = "cx25821",
>   .id_table = cx25821_pci_tbl,
>   .probe = cx25821_initdev,
>   .remove = cx25821_finidev,
>   /* TODO */
> - .suspend = NULL,
> - .resume = NULL,
> + .driver.pm = _pm_ops,
>  };

Same question as for 2/6.

Regards,

Hans

>  
>  static int __init cx25821_init(void)
> 



Re: [PATCH v2 3/3] arm, arm64: Select CONFIG_SCHED_THERMAL_PRESSURE

2020-07-13 Thread Catalin Marinas
On Sun, Jul 12, 2020 at 05:59:17PM +0100, Valentin Schneider wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 66dc41fd49f2..96d478fb7a2e 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -100,6 +100,7 @@ config ARM64
>   select FRAME_POINTER
>   select GENERIC_ALLOCATOR
>   select GENERIC_ARCH_TOPOLOGY
> + select SCHED_THERMAL_PRESSURE
>   select GENERIC_CLOCKEVENTS
>   select GENERIC_CLOCKEVENTS_BROADCAST
>   select GENERIC_CPU_AUTOPROBE

We tend to keep these in alphabetical order. Otherwise,

Acked-by: Catalin Marinas 


RE: [PATCH] drivers: soc: Fix mailbox suspend/resume no irq for IMX SCU

2020-07-13 Thread Aisheng Dong
> From: Vincenzo Frascino 
> Sent: Monday, July 6, 2020 11:00 PM
> 
> imx_mu_suspend_noirq()/imx_mu_resume_noirq() are currently used only
> when CONFIG_PM_SLEEP configuration options is enabled. Having it disabled
> triggers the following warning at compile time:
> 
> drivers/mailbox/imx-mailbox.c:611:12: warning: ‘imx_mu_resume_noirq’
> defined but not used [-Wunused-function]
>   static int imx_mu_resume_noirq(struct device *dev)
> 
> drivers/mailbox/imx-mailbox.c:601:12: warning: ‘imx_mu_suspend_noirq’
> defined but not used [-Wunused-function]
>   static int imx_mu_suspend_noirq(struct device *dev)
> 
> Make imx_mu_suspend_noirq()/imx_mu_resume_noirq() __maybe_unused to
> address the issue.
> 
> Cc: Jassi Brar 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Pengutronix Kernel Team 
> Cc: Fabio Estevam 
> Cc: NXP Linux Team 
> Signed-off-by: Vincenzo Frascino 

There's already a fix:
https://lkml.org/lkml/2020/6/22/1555

Regards
Aisheng

> ---
>  drivers/mailbox/imx-mailbox.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 7205b825c8b5..f54f36948414 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -598,7 +598,7 @@ static const struct of_device_id imx_mu_dt_ids[] = {  };
> MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> 
> -static int imx_mu_suspend_noirq(struct device *dev)
> +static int __maybe_unused imx_mu_suspend_noirq(struct device *dev)
>  {
>   struct imx_mu_priv *priv = dev_get_drvdata(dev);
> 
> @@ -608,7 +608,7 @@ static int imx_mu_suspend_noirq(struct device *dev)
>   return 0;
>  }
> 
> -static int imx_mu_resume_noirq(struct device *dev)
> +static int __maybe_unused imx_mu_resume_noirq(struct device *dev)
>  {
>   struct imx_mu_priv *priv = dev_get_drvdata(dev);
> 
> --
> 2.27.0



[PATCH] arm64: arch_timer: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 arch/arm64/include/asm/arch_timer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/arch_timer.h 
b/arch/arm64/include/asm/arch_timer.h
index 9f0ec21d6327..c395b17eead4 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -172,7 +172,7 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
  * This insanity brought to you by speculative system register reads,
  * out-of-order memory accesses, sequence locks and Thomas Gleixner.
  *
- * 
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/631195.html
+ * 
https://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/631195.html
  */
 #define arch_counter_enforce_ordering(val) do {
\
u64 tmp, _val = (val);  \
-- 
2.27.0



[PATCH v6 1/2] net: macb: WoL support for GEM type of Ethernet controller

2020-07-13 Thread nicolas.ferre
From: Nicolas Ferre 

Adapt the Wake-on-Lan feature to the Cadence GEM Ethernet controller.
This controller has different register layout and cannot be handled by
previous code.
We disable completely interrupts on all the queues but the queue 0.
Handling of WoL interrupt is done in another interrupt handler
positioned depending on the controller version used, just between
suspend() and resume() calls.
It allows to lower pressure on the generic interrupt hot path by
removing the need to handle 2 tests for each IRQ: the first figuring out
the controller revision, the second for actually knowing if the WoL bit
is set.

Queue management in suspend()/resume() functions inspired from RFC patch
by Harini Katakam , thanks!

Cc: Claudiu Beznea 
Cc: Harini Katakam 
Signed-off-by: Nicolas Ferre 
---
Changes in v6:
- Values of registers usrio and scrt2 properly read in any case (WoL or not)
  during macb_suspend() to be restored during macb_resume()

Changes in v3:
- In macb_resume(), move to a more in-depth re-configuration of the controller
  even on the non-WoL path in order to accept deeper sleep states.
- this ends up having a phylink_stop()/phylink_start() for each of the
  WoL/!WoL paths
- In macb_resume(), keep setting the MPE bit in NCR register which is needed in
  case of deep power saving mode used
- Tests done in "standby" as well as our deeper Power Management mode:
  Backup Self-Refresh (BSR)

Changes in v2:
- Addition of pm_wakeup_event() in WoL IRQ
- In macb_resume(), removal of setting the MPE bit in NCR register which is not
  needed in any case: IP is reset on the usual path and kept alive if WoL is 
used
- In macb_resume(), complete reset of the controller is kept only for non-WoL
  case. For the WoL case, we only replace the usual IRQ handler.

 drivers/net/ethernet/cadence/macb.h  |   3 +
 drivers/net/ethernet/cadence/macb_main.c | 151 +++
 2 files changed, 127 insertions(+), 27 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index ab827fb4b6b9..4f1b41569260 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -90,6 +90,7 @@
 #define GEM_SA3T   0x009C /* Specific3 Top */
 #define GEM_SA4B   0x00A0 /* Specific4 Bottom */
 #define GEM_SA4T   0x00A4 /* Specific4 Top */
+#define GEM_WOL0x00b8 /* Wake on LAN */
 #define GEM_EFTSH  0x00e8 /* PTP Event Frame Transmitted Seconds 
Register 47:32 */
 #define GEM_EFRSH  0x00ec /* PTP Event Frame Received Seconds 
Register 47:32 */
 #define GEM_PEFTSH 0x00f0 /* PTP Peer Event Frame Transmitted 
Seconds Register 47:32 */
@@ -396,6 +397,8 @@
 #define MACB_PDRSFT_SIZE   1
 #define MACB_SRI_OFFSET26 /* TSU Seconds Register Increment */
 #define MACB_SRI_SIZE  1
+#define GEM_WOL_OFFSET 28 /* Enable wake-on-lan interrupt */
+#define GEM_WOL_SIZE   1
 
 /* Timer increment fields */
 #define MACB_TI_CNS_OFFSET 0
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index e5e37aa81b02..122c54e40f91 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1517,6 +1517,35 @@ static void macb_tx_restart(struct macb_queue *queue)
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
 }
 
+static irqreturn_t gem_wol_interrupt(int irq, void *dev_id)
+{
+   struct macb_queue *queue = dev_id;
+   struct macb *bp = queue->bp;
+   u32 status;
+
+   status = queue_readl(queue, ISR);
+
+   if (unlikely(!status))
+   return IRQ_NONE;
+
+   spin_lock(>lock);
+
+   if (status & GEM_BIT(WOL)) {
+   queue_writel(queue, IDR, GEM_BIT(WOL));
+   gem_writel(bp, WOL, 0);
+   netdev_vdbg(bp->dev, "GEM WoL: queue = %u, isr = 0x%08lx\n",
+   (unsigned int)(queue - bp->queues),
+   (unsigned long)status);
+   if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
+   queue_writel(queue, ISR, GEM_BIT(WOL));
+   pm_wakeup_event(>pdev->dev, 0);
+   }
+
+   spin_unlock(>lock);
+
+   return IRQ_HANDLED;
+}
+
 static irqreturn_t macb_interrupt(int irq, void *dev_id)
 {
struct macb_queue *queue = dev_id;
@@ -3316,6 +3345,8 @@ static const struct ethtool_ops macb_ethtool_ops = {
 static const struct ethtool_ops gem_ethtool_ops = {
.get_regs_len   = macb_get_regs_len,
.get_regs   = macb_get_regs,
+   .get_wol= macb_get_wol,
+   .set_wol= macb_set_wol,
.get_link   = ethtool_op_get_link,
.get_ts_info= macb_get_ts_info,
.get_ethtool_stats  = gem_get_ethtool_stats,
@@ -4567,33 +4598,67 @@ static int __maybe_unused macb_suspend(struct 

[PATCH v6 0/2] net: macb: Wake-on-Lan magic packet GEM and MACB handling

2020-07-13 Thread nicolas.ferre
From: Nicolas Ferre 

Hi,

Here is the second part of support for WoL magic-packet on the current macb 
driver. This one
is addressing the bulk of the feature and is based on current net-next/master.

MACB and GEM code must co-exist and as they don't share exactly the same
register layout, I had to specialize a bit the suspend/resume paths and plug a
specific IRQ handler in order to avoid overloading the "normal" IRQ hot path.

These changes were tested on both sam9x60 which embeds a MACB+FIFO controller
and sama5d2 which has a GEM+packet buffer type of controller.

Best regards,
  Nicolas

Changes in v6:
- rebase on net-next/master now that the "fixes" patches of the series are
  merged in both net and net-next.
- GEM addition and MACB update to finish the support of WoL magic-packet on the
  two revisions of the controller.

These 2 patches were last posted in v3 series.

History of previous changes already added to git commit message here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f9f41e3db40ee8d61b427d4d88c7365d968052a9

Nicolas Ferre (2):
  net: macb: WoL support for GEM type of Ethernet controller
  net: macb: Add WoL interrupt support for MACB type of Ethernet
controller

 drivers/net/ethernet/cadence/macb.h  |   3 +
 drivers/net/ethernet/cadence/macb_main.c | 188 +++
 2 files changed, 164 insertions(+), 27 deletions(-)

-- 
2.27.0



[PATCH v6 2/2] net: macb: Add WoL interrupt support for MACB type of Ethernet controller

2020-07-13 Thread nicolas.ferre
From: Nicolas Ferre 

Handle the Wake-on-Lan interrupt for the Cadence MACB Ethernet
controller.
As we do for the GEM version, we handle of WoL interrupt in a
specialized interrupt handler for MACB version that is positionned
just between suspend() and resume() calls.

Cc: Claudiu Beznea 
Cc: Harini Katakam 
Signed-off-by: Nicolas Ferre 
---
Changes in v2:
- Addition of pm_wakeup_event() in WoL IRQ

 drivers/net/ethernet/cadence/macb_main.c | 39 +++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 122c54e40f91..fce5d545ebab 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1517,6 +1517,35 @@ static void macb_tx_restart(struct macb_queue *queue)
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
 }
 
+static irqreturn_t macb_wol_interrupt(int irq, void *dev_id)
+{
+   struct macb_queue *queue = dev_id;
+   struct macb *bp = queue->bp;
+   u32 status;
+
+   status = queue_readl(queue, ISR);
+
+   if (unlikely(!status))
+   return IRQ_NONE;
+
+   spin_lock(>lock);
+
+   if (status & MACB_BIT(WOL)) {
+   queue_writel(queue, IDR, MACB_BIT(WOL));
+   macb_writel(bp, WOL, 0);
+   netdev_vdbg(bp->dev, "MACB WoL: queue = %u, isr = 0x%08lx\n",
+   (unsigned int)(queue - bp->queues),
+   (unsigned long)status);
+   if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
+   queue_writel(queue, ISR, MACB_BIT(WOL));
+   pm_wakeup_event(>pdev->dev, 0);
+   }
+
+   spin_unlock(>lock);
+
+   return IRQ_HANDLED;
+}
+
 static irqreturn_t gem_wol_interrupt(int irq, void *dev_id)
 {
struct macb_queue *queue = dev_id;
@@ -4619,8 +4648,8 @@ static int __maybe_unused macb_suspend(struct device *dev)
/* Change interrupt handler and
 * Enable WoL IRQ on queue 0
 */
+   devm_free_irq(dev, bp->queues[0].irq, bp->queues);
if (macb_is_gem(bp)) {
-   devm_free_irq(dev, bp->queues[0].irq, bp->queues);
err = devm_request_irq(dev, bp->queues[0].irq, 
gem_wol_interrupt,
   IRQF_SHARED, netdev->name, 
bp->queues);
if (err) {
@@ -4632,6 +4661,14 @@ static int __maybe_unused macb_suspend(struct device 
*dev)
queue_writel(bp->queues, IER, GEM_BIT(WOL));
gem_writel(bp, WOL, MACB_BIT(MAG));
} else {
+   err = devm_request_irq(dev, bp->queues[0].irq, 
macb_wol_interrupt,
+  IRQF_SHARED, netdev->name, 
bp->queues);
+   if (err) {
+   dev_err(dev,
+   "Unable to request IRQ %d (error %d)\n",
+   bp->queues[0].irq, err);
+   return err;
+   }
queue_writel(bp->queues, IER, MACB_BIT(WOL));
macb_writel(bp, WOL, MACB_BIT(MAG));
}
-- 
2.27.0



Re: [PATCH 4/6] uaccess: remove segment_eq

2020-07-13 Thread Greentime Hu
Christoph Hellwig  於 2020年7月10日 週五 下午9:57寫道:
>
> segment_eq is only used to implement uaccess_kernel.  Just open code
> uaccess_kernel in the arch uaccess headers and remove one layer of
> indirection.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/alpha/include/asm/uaccess.h  | 2 +-
>  arch/arc/include/asm/segment.h| 3 +--
>  arch/arm/include/asm/uaccess.h| 4 ++--
>  arch/arm64/include/asm/uaccess.h  | 2 +-
>  arch/csky/include/asm/segment.h   | 2 +-
>  arch/h8300/include/asm/segment.h  | 2 +-
>  arch/ia64/include/asm/uaccess.h   | 2 +-
>  arch/m68k/include/asm/segment.h   | 2 +-
>  arch/microblaze/include/asm/uaccess.h | 2 +-
>  arch/mips/include/asm/uaccess.h   | 2 +-
>  arch/nds32/include/asm/uaccess.h  | 2 +-
>  arch/nios2/include/asm/uaccess.h  | 2 +-
>  arch/openrisc/include/asm/uaccess.h   | 2 +-
>  arch/parisc/include/asm/uaccess.h | 2 +-
>  arch/powerpc/include/asm/uaccess.h| 3 +--
>  arch/riscv/include/asm/uaccess.h  | 4 +---
>  arch/s390/include/asm/uaccess.h   | 2 +-
>  arch/sh/include/asm/segment.h | 3 +--
>  arch/sparc/include/asm/uaccess_32.h   | 2 +-
>  arch/sparc/include/asm/uaccess_64.h   | 2 +-
>  arch/x86/include/asm/uaccess.h| 2 +-
>  arch/xtensa/include/asm/uaccess.h | 2 +-
>  include/asm-generic/uaccess.h | 4 ++--
>  include/linux/uaccess.h   | 2 --
>  24 files changed, 25 insertions(+), 32 deletions(-)
>
[...]
> diff --git a/arch/nds32/include/asm/uaccess.h 
> b/arch/nds32/include/asm/uaccess.h
> index 3a9219f53ee0d8..010ba5f1d7dd6b 100644
> --- a/arch/nds32/include/asm/uaccess.h
> +++ b/arch/nds32/include/asm/uaccess.h
> @@ -44,7 +44,7 @@ static inline void set_fs(mm_segment_t fs)
> current_thread_info()->addr_limit = fs;
>  }
>
> -#define segment_eq(a, b)   ((a) == (b))
> +#define uaccess_kernel()   (get_fs() == KERNEL_DS)
>
>  #define __range_ok(addr, size) (size <= get_fs() && addr <= (get_fs() -size))
>
Hi Christoph, Thank you.
Acked-by: Greentime Hu 


[PATCH v2 5/9] usb: cdns3: drd: changed return type from int to bool

2020-07-13 Thread Pawel Laszczak
Patch changes return type from int to bool for
cdns3_is_host and cdns3_is_device functions.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdns3/drd.c | 16 
 drivers/usb/cdns3/drd.h |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
index 05a9f7d54c46..6fe092c828b3 100644
--- a/drivers/usb/cdns3/drd.c
+++ b/drivers/usb/cdns3/drd.c
@@ -83,25 +83,25 @@ int cdns3_get_vbus(struct cdns3 *cdns)
return vbus;
 }
 
-int cdns3_is_host(struct cdns3 *cdns)
+bool cdns3_is_host(struct cdns3 *cdns)
 {
if (cdns->dr_mode == USB_DR_MODE_HOST)
-   return 1;
+   return true;
else if (!cdns3_get_id(cdns))
-   return 1;
+   return true;
 
-   return 0;
+   return false;
 }
 
-int cdns3_is_device(struct cdns3 *cdns)
+bool cdns3_is_device(struct cdns3 *cdns)
 {
if (cdns->dr_mode == USB_DR_MODE_PERIPHERAL)
-   return 1;
+   return true;
else if (cdns->dr_mode == USB_DR_MODE_OTG)
if (cdns3_get_id(cdns))
-   return 1;
+   return true;
 
-   return 0;
+   return false;
 }
 
 /**
diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h
index 04e01c4d2377..35b6d459ee58 100644
--- a/drivers/usb/cdns3/drd.h
+++ b/drivers/usb/cdns3/drd.h
@@ -153,8 +153,8 @@ struct cdns3_otg_common_regs {
 /* Only for CDNS3_CONTROLLER_V0 version */
 #define OVERRIDE_IDPULLUP_V0   BIT(24)
 
-int cdns3_is_host(struct cdns3 *cdns);
-int cdns3_is_device(struct cdns3 *cdns);
+bool cdns3_is_host(struct cdns3 *cdns);
+bool cdns3_is_device(struct cdns3 *cdns);
 int cdns3_get_id(struct cdns3 *cdns);
 int cdns3_get_vbus(struct cdns3 *cdns);
 int cdns3_drd_init(struct cdns3 *cdns);
-- 
2.17.1



[PATCH v2 3/9] usb: cnds3: drd: deleted !=

2020-07-13 Thread Pawel Laszczak
Patch deletes unnecessary != from condition statement in cdns3_drd_init
function.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdns3/drd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
index 4939a568d8a2..6d2da504ad49 100644
--- a/drivers/usb/cdns3/drd.c
+++ b/drivers/usb/cdns3/drd.c
@@ -365,7 +365,7 @@ int cdns3_drd_init(struct cdns3 *cdns)
}
 
state = readl(>otg_regs->sts);
-   if (OTGSTS_OTG_NRDY(state) != 0) {
+   if (OTGSTS_OTG_NRDY(state)) {
dev_err(cdns->dev, "Cadence USB3 OTG device not ready\n");
return -ENODEV;
}
-- 
2.17.1



[PATCH v2 2/9] usb: cdns3: drd: removed not needed variables initialization

2020-07-13 Thread Pawel Laszczak
Patch remove some variables initialization from core.c and drd.c
file.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdns3/core.c |  4 ++--
 drivers/usb/cdns3/drd.c  | 19 +--
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 1f77fb5aefbf..c498b585eb13 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -86,7 +86,7 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
struct device *dev = cdns->dev;
enum usb_dr_mode best_dr_mode;
enum usb_dr_mode dr_mode;
-   int ret = 0;
+   int ret;
 
dr_mode = usb_get_dr_mode(dev);
cdns->role = USB_ROLE_NONE;
@@ -177,7 +177,7 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
goto err;
}
 
-   return ret;
+   return 0;
 err:
cdns3_exit_roles(cdns);
return ret;
diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
index 58089841ed52..4939a568d8a2 100644
--- a/drivers/usb/cdns3/drd.c
+++ b/drivers/usb/cdns3/drd.c
@@ -29,7 +29,6 @@
  */
 int cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode mode)
 {
-   int ret = 0;
u32 reg;
 
switch (mode) {
@@ -61,7 +60,7 @@ int cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode mode)
return -EINVAL;
}
 
-   return ret;
+   return 0;
 }
 
 int cdns3_get_id(struct cdns3 *cdns)
@@ -134,11 +133,11 @@ static void cdns3_otg_enable_irq(struct cdns3 *cdns)
 int cdns3_drd_switch_host(struct cdns3 *cdns, int on)
 {
int ret, val;
-   u32 reg = OTGCMD_OTG_DIS;
 
/* switch OTG core */
if (on) {
-   writel(OTGCMD_HOST_BUS_REQ | reg, >otg_regs->cmd);
+   writel(OTGCMD_HOST_BUS_REQ | OTGCMD_OTG_DIS,
+  >otg_regs->cmd);
 
dev_dbg(cdns->dev, "Waiting till Host mode is turned on\n");
ret = readl_poll_timeout_atomic(>otg_regs->sts, val,
@@ -212,7 +211,7 @@ int cdns3_drd_switch_gadget(struct cdns3 *cdns, int on)
  */
 static int cdns3_init_otg_mode(struct cdns3 *cdns)
 {
-   int ret = 0;
+   int ret;
 
cdns3_otg_disable_irq(cdns);
/* clear all interrupts */
@@ -223,7 +222,8 @@ static int cdns3_init_otg_mode(struct cdns3 *cdns)
return ret;
 
cdns3_otg_enable_irq(cdns);
-   return ret;
+
+   return 0;
 }
 
 /**
@@ -234,7 +234,7 @@ static int cdns3_init_otg_mode(struct cdns3 *cdns)
  */
 int cdns3_drd_update_mode(struct cdns3 *cdns)
 {
-   int ret = 0;
+   int ret;
 
switch (cdns->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
@@ -307,8 +307,8 @@ static irqreturn_t cdns3_drd_irq(int irq, void *data)
 int cdns3_drd_init(struct cdns3 *cdns)
 {
void __iomem *regs;
-   int ret = 0;
u32 state;
+   int ret;
 
regs = devm_ioremap_resource(cdns->dev, >otg_res);
if (IS_ERR(regs))
@@ -359,7 +359,6 @@ int cdns3_drd_init(struct cdns3 *cdns)
cdns3_drd_thread_irq,
IRQF_SHARED,
dev_name(cdns->dev), cdns);
-
if (ret) {
dev_err(cdns->dev, "couldn't get otg_irq\n");
return ret;
@@ -371,7 +370,7 @@ int cdns3_drd_init(struct cdns3 *cdns)
return -ENODEV;
}
 
-   return ret;
+   return 0;
 }
 
 int cdns3_drd_exit(struct cdns3 *cdns)
-- 
2.17.1



[PATCH v2 7/9] usb: cdns3: core: removed 'goto not_otg'

2020-07-13 Thread Pawel Laszczak
Patch removes 'goto not_otg' instruction from
cdns3_hw_role_state_machine function.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdns3/core.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index c498b585eb13..8e3996f211a8 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -191,11 +191,17 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
  */
 static enum usb_role cdns3_hw_role_state_machine(struct cdns3 *cdns)
 {
-   enum usb_role role;
+   enum usb_role role = USB_ROLE_NONE;
int id, vbus;
 
-   if (cdns->dr_mode != USB_DR_MODE_OTG)
-   goto not_otg;
+   if (cdns->dr_mode != USB_DR_MODE_OTG) {
+   if (cdns3_is_host(cdns))
+   role = USB_ROLE_HOST;
+   if (cdns3_is_device(cdns))
+   role = USB_ROLE_DEVICE;
+
+   return role;
+   }
 
id = cdns3_get_id(cdns);
vbus = cdns3_get_vbus(cdns);
@@ -232,14 +238,6 @@ static enum usb_role cdns3_hw_role_state_machine(struct 
cdns3 *cdns)
dev_dbg(cdns->dev, "role %d -> %d\n", cdns->role, role);
 
return role;
-
-not_otg:
-   if (cdns3_is_host(cdns))
-   role = USB_ROLE_HOST;
-   if (cdns3_is_device(cdns))
-   role = USB_ROLE_DEVICE;
-
-   return role;
 }
 
 static int cdns3_idle_role_start(struct cdns3 *cdns)
-- 
2.17.1



[PATCH v2 6/9] usb: cdns3: Added CDNS3_ID_PERIPHERAL and CDNS3_ID_HOST

2020-07-13 Thread Pawel Laszczak
Patch adds 2 definitions that make it easier to understand the code.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdns3/drd.c | 4 ++--
 drivers/usb/cdns3/drd.h | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
index 6fe092c828b3..8e7673da905e 100644
--- a/drivers/usb/cdns3/drd.c
+++ b/drivers/usb/cdns3/drd.c
@@ -87,7 +87,7 @@ bool cdns3_is_host(struct cdns3 *cdns)
 {
if (cdns->dr_mode == USB_DR_MODE_HOST)
return true;
-   else if (!cdns3_get_id(cdns))
+   else if (cdns3_get_id(cdns) == CDNS3_ID_HOST)
return true;
 
return false;
@@ -98,7 +98,7 @@ bool cdns3_is_device(struct cdns3 *cdns)
if (cdns->dr_mode == USB_DR_MODE_PERIPHERAL)
return true;
else if (cdns->dr_mode == USB_DR_MODE_OTG)
-   if (cdns3_get_id(cdns))
+   if (cdns3_get_id(cdns) == CDNS3_ID_PERIPHERAL)
return true;
 
return false;
diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h
index 35b6d459ee58..3889fead9df1 100644
--- a/drivers/usb/cdns3/drd.h
+++ b/drivers/usb/cdns3/drd.h
@@ -153,6 +153,9 @@ struct cdns3_otg_common_regs {
 /* Only for CDNS3_CONTROLLER_V0 version */
 #define OVERRIDE_IDPULLUP_V0   BIT(24)
 
+#define CDNS3_ID_PERIPHERAL1
+#define CDNS3_ID_HOST  0
+
 bool cdns3_is_host(struct cdns3 *cdns);
 bool cdns3_is_device(struct cdns3 *cdns);
 int cdns3_get_id(struct cdns3 *cdns);
-- 
2.17.1



[PATCH v2 0/9] usb: cdns3: Improvements for cdns3 DRD code

2020-07-13 Thread Pawel Laszczak
Series introduce some improvements to drd.c, drd.h and core.c files of 
cdns3 driver.

Except for the first (1/9) patch that removes not needed function,
the rest patches make improvements suggested by Dan Carpenter
during reviewing CDNSP driver.
CDNSP is the next Cadence USBSSP  driver which will be upstreamed.
The DRD part is similar for both CDNS3 and CDNSP and Greg suggested
to merge the similar part of DRD code. As first step I want to merge 
some improvements.

Changes for v2:
 - Change patch titles as sugested by Peter Chen.
 - Remove typos in patch 5 and patch 7.
 - Add reviewed-by Peter Chen tag [Patch 1, patch 8 and Patch 9].

Pawel Laszczak (9):
  usb: cdns3: core: removed cdns3_get_current_role_driver function
  usb: cdns3: drd: removed not needed variables initialization
  usb: cnds3: drd: deleted !=
  usb: cdns3: drd: return IRQ_NONE explicitly.
  usb: cdns3: drd: changed return type from int to bool
  usb: cdns3: Added CDNS3_ID_PERIPHERAL and CDNS3_ID_HOST
  usb: cdns3: core: removed 'goto not_otg'
  usb: cdns3: core: removed overwriting some error code
  usb: cdns3: drd: simplify *switch_gadet and *switch_host

 drivers/usb/cdns3/core.c   |  39 +++--
 drivers/usb/cdns3/drd.c| 165 -
 drivers/usb/cdns3/drd.h|  13 ++-
 drivers/usb/cdns3/gadget.c |   4 +-
 drivers/usb/cdns3/host.c   |   4 +-
 5 files changed, 114 insertions(+), 111 deletions(-)

-- 
2.17.1



[PATCH v2 1/9] usb: cdns3: core: removed cdns3_get_current_role_driver function

2020-07-13 Thread Pawel Laszczak
Function is not used in driver so it can be removed.

Signed-off-by: Pawel Laszczak 
Reviewed-by: Peter Chen 
---
 drivers/usb/cdns3/core.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 59e5e213a99b..1f77fb5aefbf 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -27,13 +27,6 @@
 
 static int cdns3_idle_init(struct cdns3 *cdns);
 
-static inline
-struct cdns3_role_driver *cdns3_get_current_role_driver(struct cdns3 *cdns)
-{
-   WARN_ON(!cdns->roles[cdns->role]);
-   return cdns->roles[cdns->role];
-}
-
 static int cdns3_role_start(struct cdns3 *cdns, enum usb_role role)
 {
int ret;
-- 
2.17.1



[PATCH v2 4/9] usb: cdns3: drd: return IRQ_NONE explicitly.

2020-07-13 Thread Pawel Laszczak
IRQ_NONE can be returned indirect.

Signed-off-by: Pawel Laszczak 
---
 drivers/usb/cdns3/drd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
index 6d2da504ad49..05a9f7d54c46 100644
--- a/drivers/usb/cdns3/drd.c
+++ b/drivers/usb/cdns3/drd.c
@@ -279,12 +279,12 @@ static irqreturn_t cdns3_drd_irq(int irq, void *data)
u32 reg;
 
if (cdns->dr_mode != USB_DR_MODE_OTG)
-   return ret;
+   return IRQ_NONE;
 
reg = readl(>otg_regs->ivect);
 
if (!reg)
-   return ret;
+   return IRQ_NONE;
 
if (reg & OTGIEN_ID_CHANGE_INT) {
dev_dbg(cdns->dev, "OTG IRQ: new ID: %d\n",
-- 
2.17.1



Re: [PATCH 5/6] uaccess: add force_uaccess_{begin,end} helpers

2020-07-13 Thread Greentime Hu
Christoph Hellwig  於 2020年7月10日 週五 下午9:57寫道:
>
> Add helpers to wraper the get_fs/set_fs magic for undoing any damange
> done by set_fs(KERNEL_DS).  There is no real functional benefit, but this
> documents the intent of these calls better, and will allow stubbing the
> functions out easily for kernels builds that do not allow address space
> overrides in the future.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm64/kernel/sdei.c |  2 +-
>  arch/m68k/include/asm/tlbflush.h | 12 ++--
>  arch/mips/kernel/unaligned.c | 27 +--
>  arch/nds32/mm/alignment.c|  7 +++
>  arch/sh/kernel/traps_32.c| 18 --
>  drivers/firmware/arm_sdei.c  |  5 ++---
>  include/linux/uaccess.h  | 18 ++
>  kernel/events/callchain.c|  5 ++---
>  kernel/events/core.c |  5 ++---
>  kernel/kthread.c |  5 ++---
>  kernel/stacktrace.c  |  5 ++---
>  mm/maccess.c | 22 ++
>  12 files changed, 69 insertions(+), 62 deletions(-)
>
[...]
> diff --git a/arch/nds32/mm/alignment.c b/arch/nds32/mm/alignment.c
> index c8b9061a2ee3d5..1eb7ded6992b57 100644
> --- a/arch/nds32/mm/alignment.c
> +++ b/arch/nds32/mm/alignment.c
> @@ -512,7 +512,7 @@ int do_unaligned_access(unsigned long addr, struct 
> pt_regs *regs)
>  {
> unsigned long inst;
> int ret = -EFAULT;
> -   mm_segment_t seg = get_fs();
> +   mm_segment_t seg;
>
> inst = get_inst(regs->ipc);
>
> @@ -520,13 +520,12 @@ int do_unaligned_access(unsigned long addr, struct 
> pt_regs *regs)
>   "Faulting addr: 0x%08lx, pc: 0x%08lx [inst: 0x%08lx ]\n", addr,
>   regs->ipc, inst);
>
> -   set_fs(USER_DS);
> -
> +   seg = force_uaccess_begin();
> if (inst & NDS32_16BIT_INSTRUCTION)
> ret = do_16((inst >> 16) & 0x, regs);
> else
> ret = do_32(inst, regs);
> -   set_fs(seg);
> +   force_uaccess_end(seg);
>
> return ret;
>  }

Hi Christoph, Thank you.
Acked-by: Greentime Hu 


[PATCH v2 9/9] usb: cdns3: drd: simplify *switch_gadet and *switch_host

2020-07-13 Thread Pawel Laszczak
Patch split function cdns3_drd_switch_gadget and
cdns3_drd_switch_host into:
- cdns3_drd_host_on
- cdns3_drd_host_off
- cdns3_drd_gadget_on
- cdns3_drd_gadgett_off

These functions don't have any shared code so it's better to
have smaller, faster and easier functions.

Signed-off-by: Pawel Laszczak 
Reviewed-by: Peter Chen 
---
 drivers/usb/cdns3/drd.c| 124 -
 drivers/usb/cdns3/drd.h|   6 +-
 drivers/usb/cdns3/gadget.c |   4 +-
 drivers/usb/cdns3/host.c   |   4 +-
 4 files changed, 76 insertions(+), 62 deletions(-)

diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
index 8e7673da905e..6234bcd6158a 100644
--- a/drivers/usb/cdns3/drd.c
+++ b/drivers/usb/cdns3/drd.c
@@ -124,85 +124,97 @@ static void cdns3_otg_enable_irq(struct cdns3 *cdns)
 }
 
 /**
- * cdns3_drd_switch_host - start/stop host
- * @cdns: Pointer to controller context structure
- * @on: 1 for start, 0 for stop
+ * cdns3_drd_host_on - start host.
+ * @cdns: Pointer to controller context structure.
  *
- * Returns 0 on success otherwise negative errno
+ * Returns 0 on success otherwise negative errno.
  */
-int cdns3_drd_switch_host(struct cdns3 *cdns, int on)
+int cdns3_drd_host_on(struct cdns3 *cdns)
 {
-   int ret, val;
+   u32 val;
+   int ret;
 
-   /* switch OTG core */
-   if (on) {
-   writel(OTGCMD_HOST_BUS_REQ | OTGCMD_OTG_DIS,
-  >otg_regs->cmd);
-
-   dev_dbg(cdns->dev, "Waiting till Host mode is turned on\n");
-   ret = readl_poll_timeout_atomic(>otg_regs->sts, val,
-   val & OTGSTS_XHCI_READY,
-   1, 10);
-   if (ret) {
-   dev_err(cdns->dev, "timeout waiting for xhci_ready\n");
-   return ret;
-   }
-   } else {
-   writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
-  OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
-  >otg_regs->cmd);
-   /* Waiting till H_IDLE state.*/
-   readl_poll_timeout_atomic(>otg_regs->state, val,
- !(val & OTGSTATE_HOST_STATE_MASK),
- 1, 200);
-   }
+   /* Enable host mode. */
+   writel(OTGCMD_HOST_BUS_REQ | OTGCMD_OTG_DIS,
+  >otg_regs->cmd);
 
-   return 0;
+   dev_dbg(cdns->dev, "Waiting till Host mode is turned on\n");
+   ret = readl_poll_timeout_atomic(>otg_regs->sts, val,
+   val & OTGSTS_XHCI_READY, 1, 10);
+
+   if (ret)
+   dev_err(cdns->dev, "timeout waiting for xhci_ready\n");
+
+   return ret;
 }
 
 /**
- * cdns3_drd_switch_gadget - start/stop gadget
- * @cdns: Pointer to controller context structure
- * @on: 1 for start, 0 for stop
+ * cdns3_drd_host_off - stop host.
+ * @cdns: Pointer to controller context structure.
+ */
+void cdns3_drd_host_off(struct cdns3 *cdns)
+{
+   u32 val;
+
+   writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
+  OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
+  >otg_regs->cmd);
+
+   /* Waiting till H_IDLE state.*/
+   readl_poll_timeout_atomic(>otg_regs->state, val,
+ !(val & OTGSTATE_HOST_STATE_MASK),
+ 1, 200);
+}
+
+/**
+ * cdns3_drd_gadget_on - start gadget.
+ * @cdns: Pointer to controller context structure.
  *
  * Returns 0 on success otherwise negative errno
  */
-int cdns3_drd_switch_gadget(struct cdns3 *cdns, int on)
+int cdns3_drd_gadget_on(struct cdns3 *cdns)
 {
int ret, val;
u32 reg = OTGCMD_OTG_DIS;
 
/* switch OTG core */
-   if (on) {
-   writel(OTGCMD_DEV_BUS_REQ | reg, >otg_regs->cmd);
+   writel(OTGCMD_DEV_BUS_REQ | reg, >otg_regs->cmd);
 
-   dev_dbg(cdns->dev, "Waiting till Device mode is turned on\n");
+   dev_dbg(cdns->dev, "Waiting till Device mode is turned on\n");
 
-   ret = readl_poll_timeout_atomic(>otg_regs->sts, val,
-   val & OTGSTS_DEV_READY,
-   1, 10);
-   if (ret) {
-   dev_err(cdns->dev, "timeout waiting for dev_ready\n");
-   return ret;
-   }
-   } else {
-   /*
-* driver should wait at least 10us after disabling Device
-* before turning-off Device (DEV_BUS_DROP)
-*/
-   usleep_range(20, 30);
-   writel(OTGCMD_HOST_BUS_DROP | OTGCMD_DEV_BUS_DROP |
-  OTGCMD_DEV_POWER_OFF | OTGCMD_HOST_POWER_OFF,
-  >otg_regs->cmd);
-   /* Waiting till DEV_IDLE state.*/
-   readl_poll_timeout_atomic(>otg_regs->state, val,

[PATCH v2 8/9] usb: cdns3: core: removed overwriting some error code

2020-07-13 Thread Pawel Laszczak
Some error code can be preserved, so we can remove overwriting
error code returned by some functions.

Signed-off-by: Pawel Laszczak 
Reviewed-by: Peter Chen 
---
 drivers/usb/cdns3/core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index 8e3996f211a8..72885c5edb09 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -347,7 +347,6 @@ static int cdns3_role_set(struct usb_role_switch *sw, enum 
usb_role role)
case USB_ROLE_HOST:
break;
default:
-   ret = -EPERM;
goto pm_put;
}
}
@@ -358,17 +357,14 @@ static int cdns3_role_set(struct usb_role_switch *sw, 
enum usb_role role)
case USB_ROLE_DEVICE:
break;
default:
-   ret = -EPERM;
goto pm_put;
}
}
 
cdns3_role_stop(cdns);
ret = cdns3_role_start(cdns, role);
-   if (ret) {
+   if (ret)
dev_err(cdns->dev, "set role %d has failed\n", role);
-   ret = -EPERM;
-   }
 
 pm_put:
pm_runtime_put_sync(cdns->dev);
@@ -393,7 +389,7 @@ static int cdns3_probe(struct platform_device *pdev)
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret) {
dev_err(dev, "error setting dma mask: %d\n", ret);
-   return -ENODEV;
+   return ret;
}
 
cdns = devm_kzalloc(dev, sizeof(*cdns), GFP_KERNEL);
-- 
2.17.1



RE: [PATCH] phy: renesas: rcar-gen3-usb2: fix SError happen if DEBUG_SHIRQ is enabled

2020-07-13 Thread Yoshihiro Shimoda
Hi Vinod,

> From: Vinod Koul, Sent: Monday, July 13, 2020 2:17 PM
> 
> Hi Yoshihiro,
> 
> On 09-07-20, 19:36, Yoshihiro Shimoda wrote:
> > If CONFIG_DEBUG_SHIRQ was enabled, r8a77951-salvator-xs could boot
> > correctly. If we appended "earlycon keep_bootcon" to the kernel
> > command like, we could get kernel log like below.
> >
> > SError Interrupt on CPU0, code 0xbf02 -- SError
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > 5.8.0-rc3-salvator-x-00505-g6c843129e6faaf01 #785
> > Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 
> > (DT)
> > pstate: 60400085 (nZCv daIf +PAN -UAO BTYPE=--)
> > pc : rcar_gen3_phy_usb2_irq+0x14/0x54
> > lr : free_irq+0xf4/0x27c
> >
> > This means free_irq() calls the interrupt handler while PM runtime
> > is not getting if DEBUG_SHIRQ is enabled and rcar_gen3_phy_usb2_probe()
> > failed. To fix the issue, add a condition into the interrupt
> > handler to avoid register access if any phys are not initialized.
> >
> > Note that rcar_gen3_is_any_rphy_initialized() was introduced on v5.2.
> > So, if we backports this patch to v5.1 or less, we need to make
> > other way.
> 
> Should we really check phy is initialized? I think the issue here is
> that you register irq first, so your handler can be invoked. Right fix
> for this would be to move the irq registration to later in the probe
> when we are ready to handle interrupts

Thank you for your review! I think we need to check whether phy is initialized
even if the irq registration moves to rcar_gen3_phy_usb2_init() because the 
current
driver will have multiple phy instances. However, moving the irq registration 
can be
easy to backport than this patch, I think. So, I'll modify this patch as you 
suggested.

Best regards,
Yoshihiro Shiomda



Re: [PATCH 0/5] arm64: perf: Proper cap_user_time* support

2020-07-13 Thread Will Deacon
Hi Leo,

On Mon, Jul 13, 2020 at 02:08:00PM +0800, Leo Yan wrote:
> On Tue, May 12, 2020 at 02:40:58PM +0200, Peter Zijlstra wrote:
> > Prompted by Leo's patches, here a series that corrects the arm64 perf 
> > cap_user_time situation.
> 
> I checked the latest mainline kernel code base, found this patch set
> are missed to merge into it.
> 
> Could you confirm if this is missed or any other reasons to hold on it?

I was assuming you were going to pick them up, fix up the issues found
by you and kbuild robot and then post a full series after testing.

Will


[PATCH] arm64: dts: ti: k3-*: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 arch/arm64/boot/dts/ti/Makefile   | 2 +-
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi  | 2 +-
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi   | 2 +-
 arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 2 +-
 arch/arm64/boot/dts/ti/k3-am65.dtsi   | 2 +-
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts| 2 +-
 arch/arm64/boot/dts/ti/k3-am654.dtsi  | 2 +-
 arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 2 +-
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 2 +-
 arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi   | 2 +-
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi   | 2 +-
 arch/arm64/boot/dts/ti/k3-j721e.dtsi  | 2 +-
 include/dt-bindings/pinctrl/k3.h  | 2 +-
 13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index b397945fdf73..05c0bebf65d4 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -3,7 +3,7 @@
 # Make file to build device tree binaries for boards based on
 # Texas Instruments Inc processors
 #
-# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+# Copyright (C) 2016-2018 Texas Instruments Incorporated - https://www.ti.com/
 #
 
 dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 61815228e230..940acc6cbf26 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -2,7 +2,7 @@
 /*
  * Device Tree Source for AM6 SoC Family Main Domain peripherals
  *
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - https://www.ti.com/
  */
 #include 
 
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index ae5f813d0cac..8c1abcfe0860 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -2,7 +2,7 @@
 /*
  * Device Tree Source for AM6 SoC Family MCU Domain peripherals
  *
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 _mcu {
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index 54a133fa1bf2..dd75a5592539 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -2,7 +2,7 @@
 /*
  * Device Tree Source for AM6 SoC Family Wakeup Domain peripherals
  *
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 _wakeup {
diff --git a/arch/arm64/boot/dts/ti/k3-am65.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65.dtsi
index 5be75e430965..27c0406b10ba 100644
--- a/arch/arm64/boot/dts/ti/k3-am65.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi
@@ -2,7 +2,7 @@
 /*
  * Device Tree Source for AM6 SoC Family
  *
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 #include 
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts 
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 2f3d3316a1cf..78084a507fcf 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2016-2018 

[PATCH] iommu/mediatek: Include liunx/dma-mapping.h

2020-07-13 Thread Joerg Roedel
From: Joerg Roedel 

This fixes a compile error when cross-compiling the driver
on x86-32.

Signed-off-by: Joerg Roedel 
---
 drivers/iommu/mtk_iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 6ff62452bbf9..122925dbe547 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MTK_LARB_COM_MAX   8
-- 
2.16.3



Re: [PATCH RFC] kprobes: Remove MODULES dependency

2020-07-13 Thread Peter Zijlstra
On Mon, Jul 13, 2020 at 08:05:49AM +0300, Jarkko Sakkinen wrote:
> On Fri, Jul 10, 2020 at 12:49:10PM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 10, 2020 at 01:36:38PM +0300, Jarkko Sakkinen wrote:
> > > Just so that I know (and learn), what did exactly disable optprobes?
> > 
> > So regular, old-skool style kprobe is:
> > 
> >   - copy original instruction out
> >   - replace instruction with breakpoint (int3 on x86)
> >   - have exception handler return to the copied instruction with
> > single-step on
> >   - have single step exception handler return to the original
> > instruction stream
> > 
> > which is 2 exceptions.
> 
> Out of pure interest, how does it handle a jump (as the original
> opcode), given that it single steps a copy?

Good question, I hadn't ever looked at that detail. Anyway, I dug around
a little and it disallows 'boosting' (replacing single-step with a jmp)
for jump instructions and takes the double exception. It single steps
the original jump into 'thin-air' and does a relative fixup of the
resulting IP in the single-step exception.

For more details also see
arch/x86/kernel/kprobes/core.c:resume_execution().

> > optprobes avoid the single-step by not only writing a single
> > instruction, but additionally placing a JMP instruction behind it such
> > that it will automagically continue in the original instruction stream.
> > 
> > This brings the requirement that the copied instruction is placed
> > within the JMP displacement of the regular kernel text (s32 on x86).
> > 
> > module_alloc() ensures the memory provided is within that range.
> 
> Right, a relative jump is placed instead of 0xcc to the breakpoint?

So there's all sorts of optimizations. The one I was talking about is
apparently called boosting. That one still uses INT3 but avoids (where
possible) the single-step #DB trap by appending a JMP.d32 after it.

There's also optimized kprobes and that avoids all traps by replacing
the original instruction(s) with a JMP.d32 to a trampoline, this
trampoline calls the kprobe handler, after which it runs the original
instruction(s) and then a JMP.d32 back into where we came from.

These fully optimized kprobes have very specific constraints, best to
read the code if you want more details.

Anyway, the common theme here is that all the various optimizations rely
on the out-of-line text being withing the s32 displacement of relative
jumps.


Re: [Freedreno] [v1] drm/msm/dpu: enumerate second cursor pipe for external interface

2020-07-13 Thread kalyan_t

On 2020-07-10 22:19, Rob Clark wrote:
On Thu, Jun 25, 2020 at 5:46 AM Kalyan Thota  
wrote:


Setup an RGB HW pipe as cursor which can be used on
secondary interface.

For SC7180 2 HW pipes are enumerated as cursors
1 - primary interface
2 - secondary interface

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

index 8f2357d..23061fd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -117,10 +117,10 @@
.reg_off = 0x2AC, .bit_off = 0},
.clk_ctrls[DPU_CLK_CTRL_DMA0] = {
.reg_off = 0x2AC, .bit_off = 8},
-   .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
-   .reg_off = 0x2B4, .bit_off = 8},
.clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
-   .reg_off = 0x2BC, .bit_off = 8},
+   .reg_off = 0x2B4, .bit_off = 8},
+   .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+   .reg_off = 0x2C4, .bit_off = 8},


It looks like you shifted the register offset here from 0x2bc to
0x2c4, was that intentional?

BR,
-R

Yes Rob, the offset was wrong which i corrected in this patch.



},
 };

@@ -272,10 +272,10 @@
sc7180_vig_sblk_0, 0,  SSPP_TYPE_VIG, 
DPU_CLK_CTRL_VIG0),

SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000,  DMA_SDM845_MASK,
sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, 
DPU_CLK_CTRL_DMA0),

-   SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000,  DMA_SDM845_MASK,
-   sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, 
DPU_CLK_CTRL_DMA1),
+   SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000,  
DMA_CURSOR_SDM845_MASK,
+   sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, 
DPU_CLK_CTRL_CURSOR0),
SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000,  
DMA_CURSOR_SDM845_MASK,
-   sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, 
DPU_CLK_CTRL_CURSOR0),
+   sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, 
DPU_CLK_CTRL_CURSOR1),

 };

 /*
--
1.9.1


___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno


Re: WARNING in submit_bio_checks

2020-07-13 Thread Christoph Hellwig
On Fri, Jul 10, 2020 at 10:34:19PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:

This is not a crash, but a WARN_ONCE.  A pre-existing one that just
slightly changed the printed message recently.


[PATCH] atm: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/atm/solos-pci.c | 2 +-
 include/uapi/linux/atmioc.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index c32f7dd9879a..b7646ae55942 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
  * Driver for the Solos PCI ADSL2+ card, designed to support Linux by
- *  Traverse Technologies -- http://www.traverse.com.au/
+ *  Traverse Technologies -- https://www.traverse.com.au/
  *  Xrio Limited  -- http://www.xrio.com/
  *
  * Copyright © 2008 Traverse Technologies
diff --git a/include/uapi/linux/atmioc.h b/include/uapi/linux/atmioc.h
index cd7655e40c77..a9030bcc8d56 100644
--- a/include/uapi/linux/atmioc.h
+++ b/include/uapi/linux/atmioc.h
@@ -5,7 +5,7 @@
 
 
 /*
- * See http://icawww1.epfl.ch/linux-atm/magic.html for the complete list of
+ * See https://icawww1.epfl.ch/linux-atm/magic.html for the complete list of
  * "magic" ioctl numbers.
  */
 
-- 
2.27.0



Re: [PATCH v7 3/3] leds: trigger: implement a tty trigger

2020-07-13 Thread Uwe Kleine-König
Hello Pavel,

On Sun, Jul 12, 2020 at 10:24:53AM +0200, Pavel Machek wrote:
> > +++ b/drivers/leds/trigger/ledtrig-tty.c
> > @@ -0,0 +1,192 @@
> > +// SPDX-License-Identifier: GPL-2.0
> 
> 2.0+ is preffered.

My employer requests GPL-2.0-only for kernel code.

> > +   while (firstrun ||
> > +  icount.rx != trigger_data->rx ||
> > +  icount.tx != trigger_data->tx) {
> > +
> > +   led_set_brightness(trigger_data->led_cdev, LED_ON);
> > +
> > +   msleep(100);
> > +
> > +   led_set_brightness(trigger_data->led_cdev, LED_OFF);
> 
> Is this good idea inside workqueue?

What is "this"? The msleep? Calling led_set_brightness? What would you
recommend instead? Maybe led_set_brightness_nosleep()?

> > +   trigger_data->rx = icount.rx;
> > +   trigger_data->tx = icount.tx;
> > +   firstrun = false;
> > +
> > +   ret = tty_get_icount(trigger_data->tty, );
> > +   if (ret)
> > +   return;
> 
> Unbalanced locking.

indeed, will fix and resend after the above issues are resolved.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


[PATCH] ASoC: rockchip: spdif: Handle clk by pm runtime

2020-07-13 Thread Sugar Zhang
This patch handle the clk by pm runtime mechanism to simplify
the clk management.

Signed-off-by: Sugar Zhang 
---

 sound/soc/rockchip/rockchip_spdif.c | 59 +++--
 1 file changed, 17 insertions(+), 42 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_spdif.c 
b/sound/soc/rockchip/rockchip_spdif.c
index 6635145..6748108 100644
--- a/sound/soc/rockchip/rockchip_spdif.c
+++ b/sound/soc/rockchip/rockchip_spdif.c
@@ -306,44 +306,22 @@ static int rk_spdif_probe(struct platform_device *pdev)
return -ENOMEM;
 
spdif->hclk = devm_clk_get(>dev, "hclk");
-   if (IS_ERR(spdif->hclk)) {
-   dev_err(>dev, "Can't retrieve rk_spdif bus clock\n");
+   if (IS_ERR(spdif->hclk))
return PTR_ERR(spdif->hclk);
-   }
-   ret = clk_prepare_enable(spdif->hclk);
-   if (ret) {
-   dev_err(spdif->dev, "hclock enable failed %d\n", ret);
-   return ret;
-   }
 
spdif->mclk = devm_clk_get(>dev, "mclk");
-   if (IS_ERR(spdif->mclk)) {
-   dev_err(>dev, "Can't retrieve rk_spdif master clock\n");
-   ret = PTR_ERR(spdif->mclk);
-   goto err_disable_hclk;
-   }
-
-   ret = clk_prepare_enable(spdif->mclk);
-   if (ret) {
-   dev_err(spdif->dev, "clock enable failed %d\n", ret);
-   goto err_disable_clocks;
-   }
+   if (IS_ERR(spdif->mclk))
+   return PTR_ERR(spdif->mclk);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(regs)) {
-   ret = PTR_ERR(regs);
-   goto err_disable_clocks;
-   }
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
 
spdif->regmap = devm_regmap_init_mmio_clk(>dev, "hclk", regs,
  _spdif_regmap_config);
-   if (IS_ERR(spdif->regmap)) {
-   dev_err(>dev,
-   "Failed to initialise managed register map\n");
-   ret = PTR_ERR(spdif->regmap);
-   goto err_disable_clocks;
-   }
+   if (IS_ERR(spdif->regmap))
+   return PTR_ERR(spdif->regmap);
 
spdif->playback_dma_data.addr = res->start + SPDIF_SMPDR;
spdif->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -352,47 +330,44 @@ static int rk_spdif_probe(struct platform_device *pdev)
spdif->dev = >dev;
dev_set_drvdata(>dev, spdif);
 
-   pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
-   pm_request_idle(>dev);
+   if (!pm_runtime_enabled(>dev)) {
+   ret = rk_spdif_runtime_resume(>dev);
+   if (ret)
+   goto err_pm_runtime;
+   }
 
ret = devm_snd_soc_register_component(>dev,
  _spdif_component,
  _spdif_dai, 1);
if (ret) {
dev_err(>dev, "Could not register DAI\n");
-   goto err_pm_runtime;
+   goto err_pm_suspend;
}
 
ret = devm_snd_dmaengine_pcm_register(>dev, NULL, 0);
if (ret) {
dev_err(>dev, "Could not register PCM\n");
-   goto err_pm_runtime;
+   goto err_pm_suspend;
}
 
return 0;
 
+err_pm_suspend:
+   if (!pm_runtime_status_suspended(>dev))
+   rk_spdif_runtime_suspend(>dev);
 err_pm_runtime:
pm_runtime_disable(>dev);
-err_disable_clocks:
-   clk_disable_unprepare(spdif->mclk);
-err_disable_hclk:
-   clk_disable_unprepare(spdif->hclk);
 
return ret;
 }
 
 static int rk_spdif_remove(struct platform_device *pdev)
 {
-   struct rk_spdif_dev *spdif = dev_get_drvdata(>dev);
-
pm_runtime_disable(>dev);
if (!pm_runtime_status_suspended(>dev))
rk_spdif_runtime_suspend(>dev);
 
-   clk_disable_unprepare(spdif->mclk);
-   clk_disable_unprepare(spdif->hclk);
-
return 0;
 }
 
-- 
2.7.4





Re: [PATCH v4 4/4] thermal: core: Add notifications call in the framework

2020-07-13 Thread Daniel Lezcano
On 13/07/2020 11:31, Marek Szyprowski wrote:
> Hi
> 
> On 07.07.2020 11:15, Marek Szyprowski wrote:
>> On 06.07.2020 15:46, Daniel Lezcano wrote:
>>> On 06/07/2020 15:17, Marek Szyprowski wrote:
 On 06.07.2020 12:55, Daniel Lezcano wrote:
> The generic netlink protocol is implemented but the different
> notification functions are not yet connected to the core code.
>
> These changes add the notification calls in the different
> corresponding places.
>
> Reviewed-by: Amit Kucheria 
> Signed-off-by: Daniel Lezcano 
 This patch landed in today's linux-next 20200706 as commit 5df786e46560
 ("thermal: core: Add notifications call in the framework"). Sadly it
 breaks booting various Samsung Exynos based boards. Here is an example
 log from Odroid U3 board:

Does it break also arm64 platforms?


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


Re: [PATCH v5 0/5] scsi: ufs: Add Host Performance Booster Support

2020-07-13 Thread Daejun Park
Hi Bean
> > Hi Bart,
> > 
> > > > Bart - how do you want to proceed?
> > > 
> > > Hi Avri and Daejun,
> > > 
> > > As far as I can see none of the five patches have Reviewed-by tags
> > > yet. I
> > > think that Martin expects formal reviews for this patch series from
> > > one or
> > > more reviewers who are not colleagues of the author of this patch
> > > series.
> > > 
> > > Note: recently I have been more busy than usual, hence the delayed
> > > reply.
> > 
> > Thank you for replying to the email even though you are busy.
> > 
> > Arvi, Bean - if patches looks ok, can this series have your reviewed-
> > by tag?
> > 
> > Thanks,
> > Daejun
> 
> Hi Daejun
> 
> 
> I only can give my tested-by tag since I preliminary tested it and it
> works. However, as I said in the previous email, there is performance
> downgrade comparing to the direct submission approach, also, we should
> think about HPB 2.0.

I plan to add your direct submission approach with HPB 2.0.

> Anyway, if Avri wants firstly make this series patch mainlined,
> performance fixup later, this is fine to me. I can add and fix it
> later.
> 
> BTW, you should rebase your this series set patch since there are
> conflicts with latest Martin' git repo, after that, you can add my
> tested-by tag.
> 
OK, I will. Thanks!

> Tested-by: Bean Huo 
> 
> 
> Thanks,
> Bean
> 

Thanks,
Daejun


<    1   2   3   4   5   6   7   8   9   10   >