【BUG】The kernel start fail when enable CONFIG_ARM64_LSE_ATOMICS and KCOV_INSTRUMENT_ALL

[Bixuan Cui]

Hi,
I try to start the kernel(v4.14.0-rc4) by qemu while enable 
CONFIG_ARM64_LSE_ATOMICS and KCOV_INSTRUMENT_ALL(use 
arch/arm64/configs/defconfig) at the same time. Then
it hang:
qemu-system-aarch64 -kernel Image -m 2048 -smp 8 -initrd qemu-le.rootfs -cpu 
cortex-a57 -nographic -machine virt,kernel_irqchip=on -append 'console=ttyAMA0 
root=/dev/ram rdinit=/sbin/init nohz_full=1 earlycon=pl011,0x900' -rtc 
base=localtime -device virtio-net-device,netdev=net0 -netdev 
type=tap,id=net0,script=no,downscript=no,ifname=tap2
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.14.0-rc4 #24 SMP PREEMPT Mon Oct 16 11:02:11 CST 
2017
[0.00] Boot CPU: AArch64 Processor [411fd070]
[0.00] Machine model: linux,dummy-virt
[0.00] earlycon: pl11 at MMIO 0x0900 (options '')
[0.00] bootconsole [pl11] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0xbc00

After I try kernel v4.13 and it's the same result.
I trace the code and find it stop at the end of '__init_single_page(page, pfn, 
zone, nid)' in memmap_init_zone() of mm/page_alloc.c ：

static void __meminit __init_single_page(struct page *page, unsigned long pfn,
unsigned long zone, int nid)
{
set_page_links(page, zone, nid, pfn);
init_page_count(page);
page_mapcount_reset(page);
page_cpupid_reset_last(page);

INIT_LIST_HEAD(>lru);

#ifdef WANT_PAGE_VIRTUAL
/* The shift won't overflow because ZONE_NORMAL is below 4G. */
if (!is_highmem_idx(zone))
set_page_address(page, __va(pfn << PAGE_SHIFT));
#endif
//  printk("stop here\n");
}

Anyone can give me advice?

Thanks,
Bixuan Cui

【BUG】The kernel start fail when enable CONFIG_ARM64_LSE_ATOMICS and KCOV_INSTRUMENT_ALL

[Bixuan Cui]

Hi,
I try to start the kernel(v4.14.0-rc4) by qemu while enable 
CONFIG_ARM64_LSE_ATOMICS and KCOV_INSTRUMENT_ALL(use 
arch/arm64/configs/defconfig) at the same time. Then
it hang:
qemu-system-aarch64 -kernel Image -m 2048 -smp 8 -initrd qemu-le.rootfs -cpu 
cortex-a57 -nographic -machine virt,kernel_irqchip=on -append 'console=ttyAMA0 
root=/dev/ram rdinit=/sbin/init nohz_full=1 earlycon=pl011,0x900' -rtc 
base=localtime -device virtio-net-device,netdev=net0 -netdev 
type=tap,id=net0,script=no,downscript=no,ifname=tap2
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.14.0-rc4 #24 SMP PREEMPT Mon Oct 16 11:02:11 CST 
2017
[0.00] Boot CPU: AArch64 Processor [411fd070]
[0.00] Machine model: linux,dummy-virt
[0.00] earlycon: pl11 at MMIO 0x0900 (options '')
[0.00] bootconsole [pl11] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0xbc00

After I try kernel v4.13 and it's the same result.
I trace the code and find it stop at the end of '__init_single_page(page, pfn, 
zone, nid)' in memmap_init_zone() of mm/page_alloc.c ：

static void __meminit __init_single_page(struct page *page, unsigned long pfn,
unsigned long zone, int nid)
{
set_page_links(page, zone, nid, pfn);
init_page_count(page);
page_mapcount_reset(page);
page_cpupid_reset_last(page);

INIT_LIST_HEAD(>lru);

#ifdef WANT_PAGE_VIRTUAL
/* The shift won't overflow because ZONE_NORMAL is below 4G. */
if (!is_highmem_idx(zone))
set_page_address(page, __va(pfn << PAGE_SHIFT));
#endif
//  printk("stop here\n");
}

Anyone can give me advice?

Thanks,
Bixuan Cui

[PATCH] PCI: dwc: dra7xx: Print link state to console for debug

[Faiz Abbas]

Enable support for printing the LTSSM link state for debugging PCI
when link is down.

Signed-off-by: Faiz Abbas 
---
 drivers/pci/dwc/pci-dra7xx.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 34427a6..7b150b0 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -98,6 +98,18 @@ struct dra7xx_pcie_of_data {
 
 #define to_dra7xx_pcie(x)  dev_get_drvdata((x)->dev)
 
+static char state[][20] = {
+   "DETECT_QUIET", "DETECT_ACT", "POLL_ACTIVE", "POLL_COMPLIANCE",
+   "POLL_CONFIG", "PRE_DETECT_QUIET", "DETECT_WAIT", "CFG_LINKWD_START",
+   "CFG_LINKWD_ACEPT", "CFG_LANENUM_WAIT", "CFG_LANENUM_ACEPT",
+   "CFG_COMPLETE", "CFG_IDLE", "RCVRY_LOCK", "RCVRY_SPEED",
+   "RCVRY_RCVRCFG", "RCVRY_IDLE", "L0", "L0S", "L123_SEND_EIDLE",
+   "L1_IDLE", "L2_IDLE", "L2_WAKE", "DISABLED_ENTRY", "DISABLED_IDLE",
+   "DISABLED", "LPBK_ENTRY", "LPBK_ACTIVE", "LPBK_EXIT",
+   "LPBK_EXIT_TIMEOUT", "HOT_RESET_ENTRY", "HOT_RESET", "RCVRY_EQ0",
+   "RCVRY_EQ1", "RCVRY_EQ2", "RCVRY_EQ3"
+};
+
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
 {
return readl(pcie->base + offset);
@@ -118,6 +130,15 @@ static int dra7xx_pcie_link_up(struct dw_pcie *pci)
 {
struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
u32 reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_PHY_CS);
+   u32 cmd_reg;
+   u32 ltssm_state;
+
+   if (!(reg & LINK_UP)) {
+   cmd_reg = dra7xx_pcie_readl(dra7xx,
+   PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+   ltssm_state = (cmd_reg & GENMASK(7, 2)) >> 2;
+   dev_err(pci->dev, "Link state:%s\n", state[ltssm_state]);
+   }
 
return !!(reg & LINK_UP);
 }
-- 
2.7.4

[PATCH] PCI: dwc: dra7xx: Print link state to console for debug

[Faiz Abbas]

Enable support for printing the LTSSM link state for debugging PCI
when link is down.

Signed-off-by: Faiz Abbas 
---
 drivers/pci/dwc/pci-dra7xx.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 34427a6..7b150b0 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -98,6 +98,18 @@ struct dra7xx_pcie_of_data {
 
 #define to_dra7xx_pcie(x)  dev_get_drvdata((x)->dev)
 
+static char state[][20] = {
+   "DETECT_QUIET", "DETECT_ACT", "POLL_ACTIVE", "POLL_COMPLIANCE",
+   "POLL_CONFIG", "PRE_DETECT_QUIET", "DETECT_WAIT", "CFG_LINKWD_START",
+   "CFG_LINKWD_ACEPT", "CFG_LANENUM_WAIT", "CFG_LANENUM_ACEPT",
+   "CFG_COMPLETE", "CFG_IDLE", "RCVRY_LOCK", "RCVRY_SPEED",
+   "RCVRY_RCVRCFG", "RCVRY_IDLE", "L0", "L0S", "L123_SEND_EIDLE",
+   "L1_IDLE", "L2_IDLE", "L2_WAKE", "DISABLED_ENTRY", "DISABLED_IDLE",
+   "DISABLED", "LPBK_ENTRY", "LPBK_ACTIVE", "LPBK_EXIT",
+   "LPBK_EXIT_TIMEOUT", "HOT_RESET_ENTRY", "HOT_RESET", "RCVRY_EQ0",
+   "RCVRY_EQ1", "RCVRY_EQ2", "RCVRY_EQ3"
+};
+
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
 {
return readl(pcie->base + offset);
@@ -118,6 +130,15 @@ static int dra7xx_pcie_link_up(struct dw_pcie *pci)
 {
struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
u32 reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_PHY_CS);
+   u32 cmd_reg;
+   u32 ltssm_state;
+
+   if (!(reg & LINK_UP)) {
+   cmd_reg = dra7xx_pcie_readl(dra7xx,
+   PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+   ltssm_state = (cmd_reg & GENMASK(7, 2)) >> 2;
+   dev_err(pci->dev, "Link state:%s\n", state[ltssm_state]);
+   }
 
return !!(reg & LINK_UP);
 }
-- 
2.7.4

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

[Josh Poimboeuf]

On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote:
> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
> > On 10/12/2017 03:27 PM, Andrew Cooper wrote:
> >> On 12/10/17 20:11, Boris Ostrovsky wrote:
> >>> There is also another problem:
> >>>
> >>> [1.312425] general protection fault:  [#1] SMP
> >>> [1.312901] Modules linked in:
> >>> [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
> >>> [1.313878] task: 88003e2c task.stack: c938c000
> >>> [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5
> >>> [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046
> >>> [1.315336] RAX: 000c RBX: 55f550168040 RCX:
> >>> 7fcfc959f59a
> >>> [1.315827] RDX:  RSI:  RDI:
> >>> 
> >>> [1.316315] RBP: 000a R08: 037f R09:
> >>> 0064
> >>> [1.316805] R10: 1f89cbf5 R11: 88003e2c R12:
> >>> 7fcfc958ad60
> >>> [1.317300] R13:  R14: 55f550185954 R15:
> >>> 1000
> >>> [1.317801] FS:  () GS:88003f80()
> >>> knlGS:
> >>> [1.318267] CS:  e033 DS:  ES:  CR0: 80050033
> >>> [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4:
> >>> 00042660
> >>> [1.319235] Call Trace:
> >>> [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
> >>> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
> >>> 00 50  15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
> >>> [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: 
> >>> c938ff50
> >>> [1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
> >>> [1.345009] Kernel panic - not syncing: Attempted to kill init!
> >>> exitcode=0x000b
> >>>
> >>>
> >>> All code
> >>> 
> >>>0:51   push   %rcx
> >>>1:50   push   %rax
> >>>2:57   push   %rdi
> >>>3:56   push   %rsi
> >>>4:52   push   %rdx
> >>>5:51   push   %rcx
> >>>6:6a dapushq  $0xffda
> >>>8:41 50push   %r8
> >>>a:41 51push   %r9
> >>>c:41 52push   %r10
> >>>e:41 53push   %r11
> >>>   10:48 83 ec 30  sub$0x30,%rsp
> >>>   14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11
> >>>   1b:00 00
> >>>   1d:41 f7 03 df 39 08 90 testl  $0x900839df,(%r11)
> >>>   24:0f 85 a5 00 00 00jne0xcf
> >>>   2a:50   push   %rax
> >>>   2b:*ff 15 9c 95 d0 ffcallq  *-0x2f6a64(%rip)#
> >>> 0xffd095cd<-- trapping instruction
> >>>   31:58   pop%rax
> >>>   32:48 3d 4c 01 00 00cmp$0x14c,%rax
> >>>   38:77 0fja 0x49
> >>>   3a:4c 89 d1 mov%r10,%rcx
> >>>   3d:ff   .byte 0xff
> >>>   3e:14 c5adc$0xc5,%al
> >>>
> >>>
> >>> so the original 'cli' was replaced with the pv call but to me the offset
> >>> looks a bit off, no? Shouldn't it always be positive?
> >> callq takes a 32bit signed displacement, so jumping back by up to 2G is
> >> perfectly legitimate.
> > Yes, but
> >
> > ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath
> > 817365dd t entry_SYSCALL_64_fastpath
> > ostr@workbase> nm vmlinux | grep " pv_irq_ops"
> > 81c2dbc0 D pv_irq_ops
> > ostr@workbase>
> >
> > so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I
> > didn't mean that x86 instruction set doesn't allow negative
> > displacement, I was trying to say that pv_irq_ops always live further down)
> 
> I believe the problem is this:
> 
> #define PV_INDIRECT(addr)   *addr(%rip)
> 
> The displacement that the linker computes will be relative to the where
> this instruction is placed at the time of linking, which is in
> .pv_altinstructions (and not .text). So when we copy it into .text the
> displacement becomes bogus.

apply_alternatives() is supposed to adjust that displacement based on
the new IP, though it could be messing that up somehow.  (See patch
10/13.)

-- 
Josh

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

[Josh Poimboeuf]

On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote:
> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
> > On 10/12/2017 03:27 PM, Andrew Cooper wrote:
> >> On 12/10/17 20:11, Boris Ostrovsky wrote:
> >>> There is also another problem:
> >>>
> >>> [1.312425] general protection fault:  [#1] SMP
> >>> [1.312901] Modules linked in:
> >>> [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
> >>> [1.313878] task: 88003e2c task.stack: c938c000
> >>> [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5
> >>> [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046
> >>> [1.315336] RAX: 000c RBX: 55f550168040 RCX:
> >>> 7fcfc959f59a
> >>> [1.315827] RDX:  RSI:  RDI:
> >>> 
> >>> [1.316315] RBP: 000a R08: 037f R09:
> >>> 0064
> >>> [1.316805] R10: 1f89cbf5 R11: 88003e2c R12:
> >>> 7fcfc958ad60
> >>> [1.317300] R13:  R14: 55f550185954 R15:
> >>> 1000
> >>> [1.317801] FS:  () GS:88003f80()
> >>> knlGS:
> >>> [1.318267] CS:  e033 DS:  ES:  CR0: 80050033
> >>> [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4:
> >>> 00042660
> >>> [1.319235] Call Trace:
> >>> [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
> >>> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
> >>> 00 50  15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
> >>> [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: 
> >>> c938ff50
> >>> [1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
> >>> [1.345009] Kernel panic - not syncing: Attempted to kill init!
> >>> exitcode=0x000b
> >>>
> >>>
> >>> All code
> >>> 
> >>>0:51   push   %rcx
> >>>1:50   push   %rax
> >>>2:57   push   %rdi
> >>>3:56   push   %rsi
> >>>4:52   push   %rdx
> >>>5:51   push   %rcx
> >>>6:6a dapushq  $0xffda
> >>>8:41 50push   %r8
> >>>a:41 51push   %r9
> >>>c:41 52push   %r10
> >>>e:41 53push   %r11
> >>>   10:48 83 ec 30  sub$0x30,%rsp
> >>>   14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11
> >>>   1b:00 00
> >>>   1d:41 f7 03 df 39 08 90 testl  $0x900839df,(%r11)
> >>>   24:0f 85 a5 00 00 00jne0xcf
> >>>   2a:50   push   %rax
> >>>   2b:*ff 15 9c 95 d0 ffcallq  *-0x2f6a64(%rip)#
> >>> 0xffd095cd<-- trapping instruction
> >>>   31:58   pop%rax
> >>>   32:48 3d 4c 01 00 00cmp$0x14c,%rax
> >>>   38:77 0fja 0x49
> >>>   3a:4c 89 d1 mov%r10,%rcx
> >>>   3d:ff   .byte 0xff
> >>>   3e:14 c5adc$0xc5,%al
> >>>
> >>>
> >>> so the original 'cli' was replaced with the pv call but to me the offset
> >>> looks a bit off, no? Shouldn't it always be positive?
> >> callq takes a 32bit signed displacement, so jumping back by up to 2G is
> >> perfectly legitimate.
> > Yes, but
> >
> > ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath
> > 817365dd t entry_SYSCALL_64_fastpath
> > ostr@workbase> nm vmlinux | grep " pv_irq_ops"
> > 81c2dbc0 D pv_irq_ops
> > ostr@workbase>
> >
> > so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I
> > didn't mean that x86 instruction set doesn't allow negative
> > displacement, I was trying to say that pv_irq_ops always live further down)
> 
> I believe the problem is this:
> 
> #define PV_INDIRECT(addr)   *addr(%rip)
> 
> The displacement that the linker computes will be relative to the where
> this instruction is placed at the time of linking, which is in
> .pv_altinstructions (and not .text). So when we copy it into .text the
> displacement becomes bogus.

apply_alternatives() is supposed to adjust that displacement based on
the new IP, though it could be messing that up somehow.  (See patch
10/13.)

-- 
Josh

Re: [GIT PULL] vfs i_version fix for Linus

[Al Viro]

On Mon, Oct 16, 2017 at 05:00:20PM -0400, Mimi Zohar wrote:
> Hi Al,
> 
> This pull request contains a single patch that allows file systems to
> be mounted with i_version.  I would really appreciate your forwarding
> this patch to Linus.

Applied.

Re: [GIT PULL] vfs i_version fix for Linus

[Al Viro]

On Mon, Oct 16, 2017 at 05:00:20PM -0400, Mimi Zohar wrote:
> Hi Al,
> 
> This pull request contains a single patch that allows file systems to
> be mounted with i_version.  I would really appreciate your forwarding
> this patch to Linus.

Applied.

[PATCH v4 0/3] add UniPhier efuse support

[Keiji Hayashibara]

This series adds support for eFuse implemented on UniPhier LD20 SoCs.
The eFuse device is under soc-glue and this register implements as read only.

patch v1
https://lkml.org/lkml/2017/8/31/880

patch v2
https://lkml.org/lkml/2017/10/6/20

patch v3
https://lkml.org/lkml/2017/10/17/35

Changes between v4 and v3
=
1. Fix mistakes in label correction with v3 patch


Keiji Hayashibara (3):
  dt-bindings: nvmem: add description for UniPhier eFuse
  nvmem: uniphier: add UniPhier eFuse driver
  arm64: dts: uniphier: add efuse node for LD20

 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 +++
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 18 
 drivers/nvmem/Kconfig  | 11 +++
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 5 files changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
 create mode 100644 drivers/nvmem/uniphier-efuse.c

-- 
2.7.4

[PATCH v4 3/3] arm64: dts: uniphier: add efuse node for LD20

[Keiji Hayashibara]

Add efuse node for UniPhier LD20 SoC.
This efuse node is included in soc-glue.

Signed-off-by: Keiji Hayashibara 
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..ddefde6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -376,6 +376,24 @@
};
};
 
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   };
+   };
+
aidet: aidet@5fc2 {
compatible = "socionext,uniphier-ld20-aidet";
reg = <0x5fc2 0x200>;
-- 
2.7.4

[PATCH v4 0/3] add UniPhier efuse support

[Keiji Hayashibara]

This series adds support for eFuse implemented on UniPhier LD20 SoCs.
The eFuse device is under soc-glue and this register implements as read only.

patch v1
https://lkml.org/lkml/2017/8/31/880

patch v2
https://lkml.org/lkml/2017/10/6/20

patch v3
https://lkml.org/lkml/2017/10/17/35

Changes between v4 and v3
=
1. Fix mistakes in label correction with v3 patch


Keiji Hayashibara (3):
  dt-bindings: nvmem: add description for UniPhier eFuse
  nvmem: uniphier: add UniPhier eFuse driver
  arm64: dts: uniphier: add efuse node for LD20

 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 +++
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 18 
 drivers/nvmem/Kconfig  | 11 +++
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 5 files changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
 create mode 100644 drivers/nvmem/uniphier-efuse.c

-- 
2.7.4

[PATCH v4 3/3] arm64: dts: uniphier: add efuse node for LD20

[Keiji Hayashibara]

Add efuse node for UniPhier LD20 SoC.
This efuse node is included in soc-glue.

Signed-off-by: Keiji Hayashibara 
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..ddefde6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -376,6 +376,24 @@
};
};
 
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   };
+   };
+
aidet: aidet@5fc2 {
compatible = "socionext,uniphier-ld20-aidet";
reg = <0x5fc2 0x200>;
-- 
2.7.4

[PATCH v4 2/3] nvmem: uniphier: add UniPhier eFuse driver

[Keiji Hayashibara]

Add eFuse driver for Socionext UniPhier series SoC.
Note that eFuse device is under soc-glue and this register
implements as read only.

Signed-off-by: Keiji Hayashibara 
---
 drivers/nvmem/Kconfig  | 11 +
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 3 files changed, 110 insertions(+)
 create mode 100644 drivers/nvmem/uniphier-efuse.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 101ced4..9c32cfe 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -123,6 +123,17 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called nvmem_sunxi_sid.
 
+config UNIPHIER_EFUSE
+   tristate "UniPhier SoCs eFuse support"
+   depends on ARCH_UNIPHIER || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ This is a simple driver to dump specified values of UniPhier SoC
+ from eFuse.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-uniphier-efuse.
+
 config NVMEM_VF610_OCOTP
tristate "VF610 SoC OCOTP support"
depends on SOC_VF610 || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 1731406..2d07162 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE)  += nvmem_rockchip_efuse.o
 nvmem_rockchip_efuse-y := rockchip-efuse.o
 obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
+obj-$(CONFIG_UNIPHIER_EFUSE)   += nvmem-uniphier-efuse.o
+nvmem-uniphier-efuse-y := uniphier-efuse.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
new file mode 100644
index 000..2bb45c4
--- /dev/null
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -0,0 +1,97 @@
+/*
+ * UniPhier eFuse driver
+ *
+ * Copyright (C) 2017 Socionext Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct uniphier_efuse_priv {
+   void __iomem *base;
+};
+
+static int uniphier_reg_read(void *context,
+unsigned int reg, void *_val, size_t bytes)
+{
+   struct uniphier_efuse_priv *priv = context;
+   u32 *val = _val;
+   int offs;
+
+   for (offs = 0; offs < bytes; offs += sizeof(u32))
+   *val++ = readl(priv->base + reg + offs);
+
+   return 0;
+}
+
+static int uniphier_efuse_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct nvmem_config econfig ={};
+   struct uniphier_efuse_priv *priv;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   priv->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(priv->base))
+   return PTR_ERR(priv->base);
+
+   econfig.stride = 4;
+   econfig.word_size = 4;
+   econfig.read_only = true;
+   econfig.reg_read = uniphier_reg_read;
+   econfig.size = resource_size(res);
+   econfig.priv = priv;
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pdev, nvmem);
+
+   return 0;
+}
+
+static int uniphier_efuse_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static const struct of_device_id uniphier_efuse_of_match[] = {
+   { .compatible = "socionext,uniphier-efuse",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
+
+static struct platform_driver uniphier_efuse_driver = {
+   .probe = uniphier_efuse_probe,
+   .remove = uniphier_efuse_remove,
+   .driver = {
+   .name = "uniphier-efuse",
+   .of_match_table = uniphier_efuse_of_match,
+   },
+};
+module_platform_driver(uniphier_efuse_driver);
+
+MODULE_AUTHOR("Keiji Hayashibara ");
+MODULE_DESCRIPTION("UniPhier eFuse driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

[PATCH v4 2/3] nvmem: uniphier: add UniPhier eFuse driver

[Keiji Hayashibara]

Add eFuse driver for Socionext UniPhier series SoC.
Note that eFuse device is under soc-glue and this register
implements as read only.

Signed-off-by: Keiji Hayashibara 
---
 drivers/nvmem/Kconfig  | 11 +
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 3 files changed, 110 insertions(+)
 create mode 100644 drivers/nvmem/uniphier-efuse.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 101ced4..9c32cfe 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -123,6 +123,17 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called nvmem_sunxi_sid.
 
+config UNIPHIER_EFUSE
+   tristate "UniPhier SoCs eFuse support"
+   depends on ARCH_UNIPHIER || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ This is a simple driver to dump specified values of UniPhier SoC
+ from eFuse.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-uniphier-efuse.
+
 config NVMEM_VF610_OCOTP
tristate "VF610 SoC OCOTP support"
depends on SOC_VF610 || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 1731406..2d07162 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE)  += nvmem_rockchip_efuse.o
 nvmem_rockchip_efuse-y := rockchip-efuse.o
 obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
+obj-$(CONFIG_UNIPHIER_EFUSE)   += nvmem-uniphier-efuse.o
+nvmem-uniphier-efuse-y := uniphier-efuse.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
new file mode 100644
index 000..2bb45c4
--- /dev/null
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -0,0 +1,97 @@
+/*
+ * UniPhier eFuse driver
+ *
+ * Copyright (C) 2017 Socionext Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct uniphier_efuse_priv {
+   void __iomem *base;
+};
+
+static int uniphier_reg_read(void *context,
+unsigned int reg, void *_val, size_t bytes)
+{
+   struct uniphier_efuse_priv *priv = context;
+   u32 *val = _val;
+   int offs;
+
+   for (offs = 0; offs < bytes; offs += sizeof(u32))
+   *val++ = readl(priv->base + reg + offs);
+
+   return 0;
+}
+
+static int uniphier_efuse_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct nvmem_config econfig ={};
+   struct uniphier_efuse_priv *priv;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   priv->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(priv->base))
+   return PTR_ERR(priv->base);
+
+   econfig.stride = 4;
+   econfig.word_size = 4;
+   econfig.read_only = true;
+   econfig.reg_read = uniphier_reg_read;
+   econfig.size = resource_size(res);
+   econfig.priv = priv;
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pdev, nvmem);
+
+   return 0;
+}
+
+static int uniphier_efuse_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static const struct of_device_id uniphier_efuse_of_match[] = {
+   { .compatible = "socionext,uniphier-efuse",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
+
+static struct platform_driver uniphier_efuse_driver = {
+   .probe = uniphier_efuse_probe,
+   .remove = uniphier_efuse_remove,
+   .driver = {
+   .name = "uniphier-efuse",
+   .of_match_table = uniphier_efuse_of_match,
+   },
+};
+module_platform_driver(uniphier_efuse_driver);
+
+MODULE_AUTHOR("Keiji Hayashibara ");
+MODULE_DESCRIPTION("UniPhier eFuse driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

Re: [PATCH v2] printk: hash addresses printed with %p

[Joe Perches]

On Tue, 2017-10-17 at 15:52 +1100, Tobin C. Harding wrote:
> Currently there are many places in the kernel where addresses are being
> printed using an unadorned %p. Kernel pointers should be printed using
> %pK allowing some control via the kptr_restrict sysctl. Exposing addresses
> gives attackers sensitive information about the kernel layout in memory.
> 
> We can reduce the attack surface by hashing all addresses printed with
> %p. This will of course break some users, forcing code printing needed
> addresses to be updated.
> 
> For what it's worth, usage of unadorned %p can be broken down as follows
> 
> git grep '%p[^KFfSsBRrbMmIiEUVKNhdDgCGO]' | wc -l

Not really.
There are many asm uses included there

I think a better grep is:

$ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
   1084 arch
 20 block
 10 crypto
 32 Documentation
   8121 drivers
   1221 fs
143 include
101 kernel
 69 lib
100 mm
   1510 net
 40 samples
  7 scripts
 11 security
166 sound
152 tools
  2 virt

> arch: 2512

arch is especially overestimated.

Re: [PATCH v2] printk: hash addresses printed with %p

[Joe Perches]

On Tue, 2017-10-17 at 15:52 +1100, Tobin C. Harding wrote:
> Currently there are many places in the kernel where addresses are being
> printed using an unadorned %p. Kernel pointers should be printed using
> %pK allowing some control via the kptr_restrict sysctl. Exposing addresses
> gives attackers sensitive information about the kernel layout in memory.
> 
> We can reduce the attack surface by hashing all addresses printed with
> %p. This will of course break some users, forcing code printing needed
> addresses to be updated.
> 
> For what it's worth, usage of unadorned %p can be broken down as follows
> 
> git grep '%p[^KFfSsBRrbMmIiEUVKNhdDgCGO]' | wc -l

Not really.
There are many asm uses included there

I think a better grep is:

$ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
   1084 arch
 20 block
 10 crypto
 32 Documentation
   8121 drivers
   1221 fs
143 include
101 kernel
 69 lib
100 mm
   1510 net
 40 samples
  7 scripts
 11 security
166 sound
152 tools
  2 virt

> arch: 2512

arch is especially overestimated.

Re: [GIT PULL for v4.14-rc6] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Em Mon, 16 Oct 2017 20:15:33 -0400
Linus Torvalds  escreveu:

> On Mon, Oct 16, 2017 at 4:31 PM, Mauro Carvalho Chehab
>  wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
> > media/v4.14-2  
> 
> No such tag.
> 
> Did you forget to push out? The latest tag I see is v4.14-1.

Yes, I forgot to push, sorry[1]!

I just pushed it manually. You should now be able to see the
media/v4.14-2 tag there on my tree.

[1] Actually, my scripts were supposed to push it. I'm out of town for
two weeks (this week in US, next week in EU), so, I'm handling it from
my notebook, instead of using my usual machine. Maybe some setup
differences caused a flaw to it, or maybe the local copy of the script
is outdated. I'll double-check tomorrow to be sure that, if I need 
to do another push before returning home, everything would be just fine.

> I do see the branch (v4l_for_linus) that contains the commit you
> mention, but no tag..

Yep, the branch is identical to what's referenced by the tag.

Thanks,
Mauro


pgpz_YmBV1dLZ.pgp
Description: Assinatura digital OpenPGP

Re: [GIT PULL for v4.14-rc6] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Em Mon, 16 Oct 2017 20:15:33 -0400
Linus Torvalds  escreveu:

> On Mon, Oct 16, 2017 at 4:31 PM, Mauro Carvalho Chehab
>  wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
> > media/v4.14-2  
> 
> No such tag.
> 
> Did you forget to push out? The latest tag I see is v4.14-1.

Yes, I forgot to push, sorry[1]!

I just pushed it manually. You should now be able to see the
media/v4.14-2 tag there on my tree.

[1] Actually, my scripts were supposed to push it. I'm out of town for
two weeks (this week in US, next week in EU), so, I'm handling it from
my notebook, instead of using my usual machine. Maybe some setup
differences caused a flaw to it, or maybe the local copy of the script
is outdated. I'll double-check tomorrow to be sure that, if I need 
to do another push before returning home, everything would be just fine.

> I do see the branch (v4l_for_linus) that contains the commit you
> mention, but no tag..

Yep, the branch is identical to what's referenced by the tag.

Thanks,
Mauro


pgpz_YmBV1dLZ.pgp
Description: Assinatura digital OpenPGP

[PATCH v4 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

[Keiji Hayashibara]

Add uniphier-efuse dt-bindings documentation.

Signed-off-by: Keiji Hayashibara 
---
 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt

diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt 
b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
new file mode 100644
index 000..eccf490
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
@@ -0,0 +1,49 @@
+= UniPhier eFuse device tree bindings =
+
+This UniPhier eFuse must be under soc-glue.
+
+Required properties:
+- compatible: should be "socionext,uniphier-efuse"
+- reg: should contain the register location and length
+
+= Data cells =
+Are child nodes of efuse, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   usb_mon: usb-mon@54 {
+   reg = <0x54 0xc>;
+   };
+   };
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   usb {
+   ...
+   nvmem-cells = <_mon>;
+   nvmem-cell-names = "usb_mon";
+   }
-- 
2.7.4

[PATCH v4 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

[Keiji Hayashibara]

Add uniphier-efuse dt-bindings documentation.

Signed-off-by: Keiji Hayashibara 
---
 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt

diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt 
b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
new file mode 100644
index 000..eccf490
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
@@ -0,0 +1,49 @@
+= UniPhier eFuse device tree bindings =
+
+This UniPhier eFuse must be under soc-glue.
+
+Required properties:
+- compatible: should be "socionext,uniphier-efuse"
+- reg: should contain the register location and length
+
+= Data cells =
+Are child nodes of efuse, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   usb_mon: usb-mon@54 {
+   reg = <0x54 0xc>;
+   };
+   };
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   usb {
+   ...
+   nvmem-cells = <_mon>;
+   nvmem-cell-names = "usb_mon";
+   }
-- 
2.7.4

Re: [PATCH 0/2] block/SCSI MQ: two RESTART related patches

[Ming Lei]

On Tue, Oct 17, 2017 at 01:04:16PM +0800, Ming Lei wrote:
> Hi Jens,
> 
> The 1st patch runs idle hctx after dealy in scsi_mq_get_budget(),
> so that we can keep same behaviour with before, and it can be
> thought as a fix.
> 
> The 2nd patch cleans up RESTART, and removes handling for TAG_SHARED
> from current blk-mq's RESTART mechanism because SCSI_MQ can covers its
> restart by itself, so that no need to handle TAG_SHARED in blk-mq
> RESTART. And >20% IOPS boost is observed in my rand read test over
> scsi_debug.
> 
> John, please test this two patches and see if it may improve your SAS
> IO performance, and you can find the two patches in the following branch:
> 
>   https://github.com/ming1/linux/commits/blk_mq_improve_restart_V1

Forget to mention, you need to either pull the above branch directly
or apply the two patches against for-next branch of Jens' block
tree:

git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
#for-next

-- 
Ming

Re: [PATCH 0/2] block/SCSI MQ: two RESTART related patches

[Ming Lei]

On Tue, Oct 17, 2017 at 01:04:16PM +0800, Ming Lei wrote:
> Hi Jens,
> 
> The 1st patch runs idle hctx after dealy in scsi_mq_get_budget(),
> so that we can keep same behaviour with before, and it can be
> thought as a fix.
> 
> The 2nd patch cleans up RESTART, and removes handling for TAG_SHARED
> from current blk-mq's RESTART mechanism because SCSI_MQ can covers its
> restart by itself, so that no need to handle TAG_SHARED in blk-mq
> RESTART. And >20% IOPS boost is observed in my rand read test over
> scsi_debug.
> 
> John, please test this two patches and see if it may improve your SAS
> IO performance, and you can find the two patches in the following branch:
> 
>   https://github.com/ming1/linux/commits/blk_mq_improve_restart_V1

Forget to mention, you need to either pull the above branch directly
or apply the two patches against for-next branch of Jens' block
tree:

git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
#for-next

-- 
Ming

kvm_intel fails to load on CPUs running Linux 4.12 or later

[Jason R Begley]

I see that this has been discussed before, but I have ran into the same 
problem recently after trying kernel 4.13.6 and the kvm_intel module 
would not load. I stumbled across an article from Sat, 5 Aug 2017 
21:26:42 with the same issue. Is there any way to fix this? Below is a 
cpuinfo




processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU    5150  @ 2.66GHz
stepping    : 6
microcode   : 0xcd
cpu MHz : 600.000
cache size  : 4096 KB
physical id : 3
siblings    : 2
core id : 1
cpu cores   : 2
apicid  : 7
initial apicid  : 7
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid 
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm 
dca lahf_lm tpr_shadow dtherm

bugs    :
bogomips    : 5335.26
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Thank you for the help,

J

kvm_intel fails to load on CPUs running Linux 4.12 or later

[Jason R Begley]

I see that this has been discussed before, but I have ran into the same 
problem recently after trying kernel 4.13.6 and the kvm_intel module 
would not load. I stumbled across an article from Sat, 5 Aug 2017 
21:26:42 with the same issue. Is there any way to fix this? Below is a 
cpuinfo




processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU    5150  @ 2.66GHz
stepping    : 6
microcode   : 0xcd
cpu MHz : 600.000
cache size  : 4096 KB
physical id : 3
siblings    : 2
core id : 1
cpu cores   : 2
apicid  : 7
initial apicid  : 7
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid 
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm 
dca lahf_lm tpr_shadow dtherm

bugs    :
bogomips    : 5335.26
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Thank you for the help,

J

Re: [PATCH v2 5/5] mmc: dw_mmc: Cleanup the DTO timer like the CTO one

[Doug Anderson]

Hi,

On Mon, Oct 16, 2017 at 6:17 PM, Shawn Lin  wrote:
> Hi Doug
>
>
> On 2017/10/13 4:11, Douglas Anderson wrote:
>>
>> The recent CTO timer introduced in commit 03de19212ea3 ("mmc: dw_mmc:
>> introduce timer for broken command transfer over scheme") was causing
>> observable problems due to race conditions.  Previous patches have
>> fixed those race conditions.
>>
>> It can be observed that these same race conditions ought to be
>> theoretically possible with the DTO timer too though they are
>> massively less likely to happen because the data timeout is always set
>> to 0xff right now.  That means even at a 200 MHz card clock we
>> were arming the DTO timer for 94 ms:
>>>>> (0xff * 1000. / 2) + 10
>>93.886075
>>
>> We always also were setting the DTO timer _after_ starting the
>> transfer, unlike how the old code was seting the CTO timer.
>>
>> In any case, even though the DTO timer is much less likely to have
>> races, it still makes sense to add code to handle it _just in case_.
>>
>> Signed-off-by: Douglas Anderson 
>> ---
>>
>> Changes in v2:
>> - Cleanup the DTO timer new for v2
>>
>>   drivers/mmc/host/dw_mmc.c | 54
>> ---
>>   1 file changed, 51 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 6bc87b1385a9..bc0808615431 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1950,7 +1950,11 @@ static void dw_mci_set_drto(struct dw_mci *host)
>> /* add a bit spare time */
>> drto_ms += 10;
>>   - mod_timer(>dto_timer, jiffies + msecs_to_jiffies(drto_ms));
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>> +   if (!test_bit(EVENT_DATA_COMPLETE, >pending_events))
>> +   mod_timer(>dto_timer,
>> + jiffies + msecs_to_jiffies(drto_ms));
>> +   spin_unlock_irqrestore(>irq_lock, irqflags);
>>   }
>> static bool dw_mci_clear_pending_cmd_complete(struct dw_mci *host)
>> @@ -1971,6 +1975,18 @@ static bool
>> dw_mci_clear_pending_cmd_complete(struct dw_mci *host)
>> return true;
>>   }
>>   +static bool dw_mci_clear_pending_data_complete(struct dw_mci *host)
>> +{
>> +   if (!test_bit(EVENT_DATA_COMPLETE, >pending_events))
>> +   return false;
>> +
>> +   /* Extra paranoia just like dw_mci_clear_pending_cmd_complete() */
>> +   WARN_ON(del_timer_sync(>dto_timer));
>> +   clear_bit(EVENT_DATA_COMPLETE, >pending_events);
>> +
>> +   return true;
>> +}
>> +
>>   static void dw_mci_tasklet_func(unsigned long priv)
>>   {
>> struct dw_mci *host = (struct dw_mci *)priv;
>> @@ -2112,8 +2128,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
>> /* fall through */
>> case STATE_DATA_BUSY:
>> -   if (!test_and_clear_bit(EVENT_DATA_COMPLETE,
>> -   >pending_events)) {
>> +   if (!dw_mci_clear_pending_data_complete(host)) {
>> /*
>>  * If data error interrupt comes but data
>> over
>>  * interrupt doesn't come within the given
>> time.
>> @@ -2683,6 +2698,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void
>> *dev_id)
>> }
>> if (pending & SDMMC_INT_DATA_OVER) {
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>> +
>> del_timer(>dto_timer);
>> mci_writel(host, RINTSTS, SDMMC_INT_DATA_OVER);
>> @@ -2695,6 +2712,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void
>> *dev_id)
>> }
>> set_bit(EVENT_DATA_COMPLETE,
>> >pending_events);
>> tasklet_schedule(>tasklet);
>> +
>> +   spin_unlock_irqrestore(>irq_lock, irqflags);
>> }
>> if (pending & SDMMC_INT_RXDR) {
>> @@ -3044,7 +3063,31 @@ static void dw_mci_cto_timer(unsigned long arg)
>>   static void dw_mci_dto_timer(unsigned long arg)
>>   {
>> struct dw_mci *host = (struct dw_mci *)arg;
>> +   unsigned long irqflags;
>> +   u32 pending;
>> +
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>>   + /*
>> +* The DTO timer is much longer than the CTO timer, so it's even
>> less
>> +* likely that we'll these cases, but it pays to be paranoid.
>> +*/
>> +   pending = mci_readl(host, MINTSTS); /* read-only mask reg */
>> +   if (pending & SDMMC_INT_DATA_OVER) {
>> +   /* The interrupt should fire; no need to act but we can
>> warn */
>> +   dev_warn(host->dev, "Unexpected data interrupt
>> latency\n");
>> +   goto exit;
>
>
> I was checking a problem like this:
>
> (1) Start a CTO timer
> (2) Start a command
> (3) Got 

Re: [PATCH v2 5/5] mmc: dw_mmc: Cleanup the DTO timer like the CTO one

[Doug Anderson]

Hi,

On Mon, Oct 16, 2017 at 6:17 PM, Shawn Lin  wrote:
> Hi Doug
>
>
> On 2017/10/13 4:11, Douglas Anderson wrote:
>>
>> The recent CTO timer introduced in commit 03de19212ea3 ("mmc: dw_mmc:
>> introduce timer for broken command transfer over scheme") was causing
>> observable problems due to race conditions.  Previous patches have
>> fixed those race conditions.
>>
>> It can be observed that these same race conditions ought to be
>> theoretically possible with the DTO timer too though they are
>> massively less likely to happen because the data timeout is always set
>> to 0xff right now.  That means even at a 200 MHz card clock we
>> were arming the DTO timer for 94 ms:
>>>>> (0xff * 1000. / 2) + 10
>>93.886075
>>
>> We always also were setting the DTO timer _after_ starting the
>> transfer, unlike how the old code was seting the CTO timer.
>>
>> In any case, even though the DTO timer is much less likely to have
>> races, it still makes sense to add code to handle it _just in case_.
>>
>> Signed-off-by: Douglas Anderson 
>> ---
>>
>> Changes in v2:
>> - Cleanup the DTO timer new for v2
>>
>>   drivers/mmc/host/dw_mmc.c | 54
>> ---
>>   1 file changed, 51 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 6bc87b1385a9..bc0808615431 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1950,7 +1950,11 @@ static void dw_mci_set_drto(struct dw_mci *host)
>> /* add a bit spare time */
>> drto_ms += 10;
>>   - mod_timer(>dto_timer, jiffies + msecs_to_jiffies(drto_ms));
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>> +   if (!test_bit(EVENT_DATA_COMPLETE, >pending_events))
>> +   mod_timer(>dto_timer,
>> + jiffies + msecs_to_jiffies(drto_ms));
>> +   spin_unlock_irqrestore(>irq_lock, irqflags);
>>   }
>> static bool dw_mci_clear_pending_cmd_complete(struct dw_mci *host)
>> @@ -1971,6 +1975,18 @@ static bool
>> dw_mci_clear_pending_cmd_complete(struct dw_mci *host)
>> return true;
>>   }
>>   +static bool dw_mci_clear_pending_data_complete(struct dw_mci *host)
>> +{
>> +   if (!test_bit(EVENT_DATA_COMPLETE, >pending_events))
>> +   return false;
>> +
>> +   /* Extra paranoia just like dw_mci_clear_pending_cmd_complete() */
>> +   WARN_ON(del_timer_sync(>dto_timer));
>> +   clear_bit(EVENT_DATA_COMPLETE, >pending_events);
>> +
>> +   return true;
>> +}
>> +
>>   static void dw_mci_tasklet_func(unsigned long priv)
>>   {
>> struct dw_mci *host = (struct dw_mci *)priv;
>> @@ -2112,8 +2128,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
>> /* fall through */
>> case STATE_DATA_BUSY:
>> -   if (!test_and_clear_bit(EVENT_DATA_COMPLETE,
>> -   >pending_events)) {
>> +   if (!dw_mci_clear_pending_data_complete(host)) {
>> /*
>>  * If data error interrupt comes but data
>> over
>>  * interrupt doesn't come within the given
>> time.
>> @@ -2683,6 +2698,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void
>> *dev_id)
>> }
>> if (pending & SDMMC_INT_DATA_OVER) {
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>> +
>> del_timer(>dto_timer);
>> mci_writel(host, RINTSTS, SDMMC_INT_DATA_OVER);
>> @@ -2695,6 +2712,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void
>> *dev_id)
>> }
>> set_bit(EVENT_DATA_COMPLETE,
>> >pending_events);
>> tasklet_schedule(>tasklet);
>> +
>> +   spin_unlock_irqrestore(>irq_lock, irqflags);
>> }
>> if (pending & SDMMC_INT_RXDR) {
>> @@ -3044,7 +3063,31 @@ static void dw_mci_cto_timer(unsigned long arg)
>>   static void dw_mci_dto_timer(unsigned long arg)
>>   {
>> struct dw_mci *host = (struct dw_mci *)arg;
>> +   unsigned long irqflags;
>> +   u32 pending;
>> +
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>>   + /*
>> +* The DTO timer is much longer than the CTO timer, so it's even
>> less
>> +* likely that we'll these cases, but it pays to be paranoid.
>> +*/
>> +   pending = mci_readl(host, MINTSTS); /* read-only mask reg */
>> +   if (pending & SDMMC_INT_DATA_OVER) {
>> +   /* The interrupt should fire; no need to act but we can
>> warn */
>> +   dev_warn(host->dev, "Unexpected data interrupt
>> latency\n");
>> +   goto exit;
>
>
> I was checking a problem like this:
>
> (1) Start a CTO timer
> (2) Start a command
> (3) Got CMD_DONE interrupt and cancel the CTO timer
> (4) Start 

[PATCH 2/2] blk-mq: don't handle TAG_SHARED in restart

[Ming Lei]

Now restart is used in the following cases, and TAG_SHARED is for
SCSI only.

1) .get_budget() returns BLK_STS_RESOURCE
- if resource in target/host level isn't satistifed, this SCSI device
will be added in shost->starved_list, and the whole queue will be rerun
(via SCSI's built-in RESTART) in scsi_end_request() after any request
initiated from this host/targe is completed. Forget to mention, host level
resource is always respected by blk-mq before running .queue_rq().

- the same is true if resource in the queue level isn't satisfied.

- if there isn't outstanding request on this queue, then SCSI's RESTART
can't work(blk-mq's can't work too), and the queue will be run after
SCSI_QUEUE_DELAY, and finally all starved sdevs will be handled by SCSI's
RESTART when this request is finished

2) scsi_dispatch_cmd() returns BLK_STS_RESOURCE
- if there isn't onprogressing request on this queue, the queue
will be run after SCSI_QUEUE_DELAY

- otherwise, SCSI's RESTART covers the rerun.

3) blk_mq_get_driver_tag() failed
- BLK_MQ_S_TAG_WAITING covers the cross-queue RESTART for driver
allocation.

In one word, SCSI's built-in RESTART is enough to cover itself.
So we don't need to pay special attention to TAG_SHARED wrt. restart.

Signed-off-by: Ming Lei 
---
 block/blk-mq-sched.c | 78 +++-
 1 file changed, 4 insertions(+), 74 deletions(-)

diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index df8581bb0a37..daab27feb653 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -68,25 +68,17 @@ static void blk_mq_sched_mark_restart_hctx(struct 
blk_mq_hw_ctx *hctx)
set_bit(BLK_MQ_S_SCHED_RESTART, >state);
 }
 
-static bool blk_mq_sched_restart_hctx(struct blk_mq_hw_ctx *hctx)
+void blk_mq_sched_restart(struct blk_mq_hw_ctx *hctx)
 {
if (!test_bit(BLK_MQ_S_SCHED_RESTART, >state))
-   return false;
-
-   if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
-   struct request_queue *q = hctx->queue;
+   return;
 
-   if (test_and_clear_bit(BLK_MQ_S_SCHED_RESTART, >state))
-   atomic_dec(>shared_hctx_restart);
-   } else
-   clear_bit(BLK_MQ_S_SCHED_RESTART, >state);
+   clear_bit(BLK_MQ_S_SCHED_RESTART, >state);
 
if (blk_mq_hctx_has_pending(hctx)) {
blk_mq_run_hw_queue(hctx, true);
-   return true;
+   return;
}
-
-   return false;
 }
 
 /* return true if hctx need to run again */
@@ -385,68 +377,6 @@ static bool blk_mq_sched_bypass_insert(struct 
blk_mq_hw_ctx *hctx,
return true;
 }
 
-/**
- * list_for_each_entry_rcu_rr - iterate in a round-robin fashion over rcu list
- * @pos:loop cursor.
- * @skip:   the list element that will not be examined. Iteration starts at
- *  @skip->next.
- * @head:   head of the list to examine. This list must have at least one
- *  element, namely @skip.
- * @member: name of the list_head structure within typeof(*pos).
- */
-#define list_for_each_entry_rcu_rr(pos, skip, head, member)\
-   for ((pos) = (skip);\
-(pos = (pos)->member.next != (head) ? list_entry_rcu(  \
-   (pos)->member.next, typeof(*pos), member) : \
- list_entry_rcu((pos)->member.next->next, typeof(*pos), member)), \
-(pos) != (skip); )
-
-/*
- * Called after a driver tag has been freed to check whether a hctx needs to
- * be restarted. Restarts @hctx if its tag set is not shared. Restarts hardware
- * queues in a round-robin fashion if the tag set of @hctx is shared with other
- * hardware queues.
- */
-void blk_mq_sched_restart(struct blk_mq_hw_ctx *const hctx)
-{
-   struct blk_mq_tags *const tags = hctx->tags;
-   struct blk_mq_tag_set *const set = hctx->queue->tag_set;
-   struct request_queue *const queue = hctx->queue, *q;
-   struct blk_mq_hw_ctx *hctx2;
-   unsigned int i, j;
-
-   if (set->flags & BLK_MQ_F_TAG_SHARED) {
-   /*
-* If this is 0, then we know that no hardware queues
-* have RESTART marked. We're done.
-*/
-   if (!atomic_read(>shared_hctx_restart))
-   return;
-
-   rcu_read_lock();
-   list_for_each_entry_rcu_rr(q, queue, >tag_list,
-  tag_set_list) {
-   queue_for_each_hw_ctx(q, hctx2, i)
-   if (hctx2->tags == tags &&
-   blk_mq_sched_restart_hctx(hctx2))
-   goto done;
-   }
-   j = hctx->queue_num + 1;
-   for (i = 0; i < queue->nr_hw_queues; i++, j++) {
-   if (j == queue->nr_hw_queues)
-   j = 0;
-   hctx2 = 

[PATCH 2/2] blk-mq: don't handle TAG_SHARED in restart

[Ming Lei]

Now restart is used in the following cases, and TAG_SHARED is for
SCSI only.

1) .get_budget() returns BLK_STS_RESOURCE
- if resource in target/host level isn't satistifed, this SCSI device
will be added in shost->starved_list, and the whole queue will be rerun
(via SCSI's built-in RESTART) in scsi_end_request() after any request
initiated from this host/targe is completed. Forget to mention, host level
resource is always respected by blk-mq before running .queue_rq().

- the same is true if resource in the queue level isn't satisfied.

- if there isn't outstanding request on this queue, then SCSI's RESTART
can't work(blk-mq's can't work too), and the queue will be run after
SCSI_QUEUE_DELAY, and finally all starved sdevs will be handled by SCSI's
RESTART when this request is finished

2) scsi_dispatch_cmd() returns BLK_STS_RESOURCE
- if there isn't onprogressing request on this queue, the queue
will be run after SCSI_QUEUE_DELAY

- otherwise, SCSI's RESTART covers the rerun.

3) blk_mq_get_driver_tag() failed
- BLK_MQ_S_TAG_WAITING covers the cross-queue RESTART for driver
allocation.

In one word, SCSI's built-in RESTART is enough to cover itself.
So we don't need to pay special attention to TAG_SHARED wrt. restart.

Signed-off-by: Ming Lei 
---
 block/blk-mq-sched.c | 78 +++-
 1 file changed, 4 insertions(+), 74 deletions(-)

diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index df8581bb0a37..daab27feb653 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -68,25 +68,17 @@ static void blk_mq_sched_mark_restart_hctx(struct 
blk_mq_hw_ctx *hctx)
set_bit(BLK_MQ_S_SCHED_RESTART, >state);
 }
 
-static bool blk_mq_sched_restart_hctx(struct blk_mq_hw_ctx *hctx)
+void blk_mq_sched_restart(struct blk_mq_hw_ctx *hctx)
 {
if (!test_bit(BLK_MQ_S_SCHED_RESTART, >state))
-   return false;
-
-   if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
-   struct request_queue *q = hctx->queue;
+   return;
 
-   if (test_and_clear_bit(BLK_MQ_S_SCHED_RESTART, >state))
-   atomic_dec(>shared_hctx_restart);
-   } else
-   clear_bit(BLK_MQ_S_SCHED_RESTART, >state);
+   clear_bit(BLK_MQ_S_SCHED_RESTART, >state);
 
if (blk_mq_hctx_has_pending(hctx)) {
blk_mq_run_hw_queue(hctx, true);
-   return true;
+   return;
}
-
-   return false;
 }
 
 /* return true if hctx need to run again */
@@ -385,68 +377,6 @@ static bool blk_mq_sched_bypass_insert(struct 
blk_mq_hw_ctx *hctx,
return true;
 }
 
-/**
- * list_for_each_entry_rcu_rr - iterate in a round-robin fashion over rcu list
- * @pos:loop cursor.
- * @skip:   the list element that will not be examined. Iteration starts at
- *  @skip->next.
- * @head:   head of the list to examine. This list must have at least one
- *  element, namely @skip.
- * @member: name of the list_head structure within typeof(*pos).
- */
-#define list_for_each_entry_rcu_rr(pos, skip, head, member)\
-   for ((pos) = (skip);\
-(pos = (pos)->member.next != (head) ? list_entry_rcu(  \
-   (pos)->member.next, typeof(*pos), member) : \
- list_entry_rcu((pos)->member.next->next, typeof(*pos), member)), \
-(pos) != (skip); )
-
-/*
- * Called after a driver tag has been freed to check whether a hctx needs to
- * be restarted. Restarts @hctx if its tag set is not shared. Restarts hardware
- * queues in a round-robin fashion if the tag set of @hctx is shared with other
- * hardware queues.
- */
-void blk_mq_sched_restart(struct blk_mq_hw_ctx *const hctx)
-{
-   struct blk_mq_tags *const tags = hctx->tags;
-   struct blk_mq_tag_set *const set = hctx->queue->tag_set;
-   struct request_queue *const queue = hctx->queue, *q;
-   struct blk_mq_hw_ctx *hctx2;
-   unsigned int i, j;
-
-   if (set->flags & BLK_MQ_F_TAG_SHARED) {
-   /*
-* If this is 0, then we know that no hardware queues
-* have RESTART marked. We're done.
-*/
-   if (!atomic_read(>shared_hctx_restart))
-   return;
-
-   rcu_read_lock();
-   list_for_each_entry_rcu_rr(q, queue, >tag_list,
-  tag_set_list) {
-   queue_for_each_hw_ctx(q, hctx2, i)
-   if (hctx2->tags == tags &&
-   blk_mq_sched_restart_hctx(hctx2))
-   goto done;
-   }
-   j = hctx->queue_num + 1;
-   for (i = 0; i < queue->nr_hw_queues; i++, j++) {
-   if (j == queue->nr_hw_queues)
-   j = 0;
-   hctx2 = 

[PATCH 0/2] block/SCSI MQ: two RESTART related patches

[Ming Lei]

Hi Jens,

The 1st patch runs idle hctx after dealy in scsi_mq_get_budget(),
so that we can keep same behaviour with before, and it can be
thought as a fix.

The 2nd patch cleans up RESTART, and removes handling for TAG_SHARED
from current blk-mq's RESTART mechanism because SCSI_MQ can covers its
restart by itself, so that no need to handle TAG_SHARED in blk-mq
RESTART. And >20% IOPS boost is observed in my rand read test over
scsi_debug.

John, please test this two patches and see if it may improve your SAS
IO performance, and you can find the two patches in the following branch:

https://github.com/ming1/linux/commits/blk_mq_improve_restart_V1


Ming Lei (2):
  SCSI: run idle hctx after delay in scsi_mq_get_budget()
  blk-mq: don't handle TAG_SHARED in restart

 block/blk-mq-sched.c| 78 +++--
 drivers/scsi/scsi_lib.c | 13 +++--
 2 files changed, 14 insertions(+), 77 deletions(-)

-- 
2.9.5

[PATCH 0/2] block/SCSI MQ: two RESTART related patches

[Ming Lei]

Hi Jens,

The 1st patch runs idle hctx after dealy in scsi_mq_get_budget(),
so that we can keep same behaviour with before, and it can be
thought as a fix.

The 2nd patch cleans up RESTART, and removes handling for TAG_SHARED
from current blk-mq's RESTART mechanism because SCSI_MQ can covers its
restart by itself, so that no need to handle TAG_SHARED in blk-mq
RESTART. And >20% IOPS boost is observed in my rand read test over
scsi_debug.

John, please test this two patches and see if it may improve your SAS
IO performance, and you can find the two patches in the following branch:

https://github.com/ming1/linux/commits/blk_mq_improve_restart_V1


Ming Lei (2):
  SCSI: run idle hctx after delay in scsi_mq_get_budget()
  blk-mq: don't handle TAG_SHARED in restart

 block/blk-mq-sched.c| 78 +++--
 drivers/scsi/scsi_lib.c | 13 +++--
 2 files changed, 14 insertions(+), 77 deletions(-)

-- 
2.9.5

[PATCH 1/2] SCSI: run idle hctx after delay in scsi_mq_get_budget()

[Ming Lei]

If there isn't any outstanding request in this queue, both
blk-mq's RESTART and SCSI's builtin RESTART can't work,
so we have to deal with this case by running this queue
after delay.

Fixes: d04b6d97d0a1(scsi: implement .get_budget and .put_budget for blk-mq)
Signed-off-by: Ming Lei 
---
 drivers/scsi/scsi_lib.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 6f10afaca25b..08c495364b28 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1959,6 +1959,14 @@ static void scsi_mq_put_budget(struct blk_mq_hw_ctx 
*hctx)
put_device(>sdev_gendev);
 }
 
+static void scsi_mq_run_idle_hctx(struct scsi_device *sdev,
+   struct blk_mq_hw_ctx *hctx)
+{
+   if (atomic_read(>device_busy) == 0 &&
+   !scsi_device_blocked(sdev))
+   blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
+}
+
 static blk_status_t scsi_mq_get_budget(struct blk_mq_hw_ctx *hctx)
 {
struct request_queue *q = hctx->queue;
@@ -1989,6 +1997,7 @@ static blk_status_t scsi_mq_get_budget(struct 
blk_mq_hw_ctx *hctx)
 out_put_device:
put_device(>sdev_gendev);
 out:
+   scsi_mq_run_idle_hctx(sdev, hctx);
return BLK_STS_RESOURCE;
 }
 
@@ -2039,9 +2048,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx 
*hctx,
case BLK_STS_OK:
break;
case BLK_STS_RESOURCE:
-   if (atomic_read(>device_busy) == 0 &&
-   !scsi_device_blocked(sdev))
-   blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
+   scsi_mq_run_idle_hctx(sdev, hctx);
break;
default:
/*
-- 
2.9.5

[PATCH 1/2] SCSI: run idle hctx after delay in scsi_mq_get_budget()

[Ming Lei]

If there isn't any outstanding request in this queue, both
blk-mq's RESTART and SCSI's builtin RESTART can't work,
so we have to deal with this case by running this queue
after delay.

Fixes: d04b6d97d0a1(scsi: implement .get_budget and .put_budget for blk-mq)
Signed-off-by: Ming Lei 
---
 drivers/scsi/scsi_lib.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 6f10afaca25b..08c495364b28 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1959,6 +1959,14 @@ static void scsi_mq_put_budget(struct blk_mq_hw_ctx 
*hctx)
put_device(>sdev_gendev);
 }
 
+static void scsi_mq_run_idle_hctx(struct scsi_device *sdev,
+   struct blk_mq_hw_ctx *hctx)
+{
+   if (atomic_read(>device_busy) == 0 &&
+   !scsi_device_blocked(sdev))
+   blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
+}
+
 static blk_status_t scsi_mq_get_budget(struct blk_mq_hw_ctx *hctx)
 {
struct request_queue *q = hctx->queue;
@@ -1989,6 +1997,7 @@ static blk_status_t scsi_mq_get_budget(struct 
blk_mq_hw_ctx *hctx)
 out_put_device:
put_device(>sdev_gendev);
 out:
+   scsi_mq_run_idle_hctx(sdev, hctx);
return BLK_STS_RESOURCE;
 }
 
@@ -2039,9 +2048,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx 
*hctx,
case BLK_STS_OK:
break;
case BLK_STS_RESOURCE:
-   if (atomic_read(>device_busy) == 0 &&
-   !scsi_device_blocked(sdev))
-   blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
+   scsi_mq_run_idle_hctx(sdev, hctx);
break;
default:
/*
-- 
2.9.5

Re: [lkp-robot] [x86/mm] c4c3c3c2d0: will-it-scale.per_process_ops -61.0% regression

[Markus Trippelsdorf]

On 2017.10.16 at 18:06 -0700, Andy Lutomirski wrote:
> On Mon, Oct 16, 2017 at 3:15 AM, Borislav Petkov  wrote:
> > On Mon, Oct 16, 2017 at 10:39:17AM +0800, kernel test robot wrote:
> >>
> >> Greeting,
> >>
> >> FYI, we noticed a -61.0% regression of will-it-scale.per_process_ops due 
> >> to commit:

I think you are reading this wrong:
-61.0% regression means 61.0% improvement.

-- 
Markus

Re: [lkp-robot] [x86/mm] c4c3c3c2d0: will-it-scale.per_process_ops -61.0% regression

[Markus Trippelsdorf]

On 2017.10.16 at 18:06 -0700, Andy Lutomirski wrote:
> On Mon, Oct 16, 2017 at 3:15 AM, Borislav Petkov  wrote:
> > On Mon, Oct 16, 2017 at 10:39:17AM +0800, kernel test robot wrote:
> >>
> >> Greeting,
> >>
> >> FYI, we noticed a -61.0% regression of will-it-scale.per_process_ops due 
> >> to commit:

I think you are reading this wrong:
-61.0% regression means 61.0% improvement.

-- 
Markus

[PATCH v2] printk: hash addresses printed with %p

[Tobin C. Harding]

Currently there are many places in the kernel where addresses are being
printed using an unadorned %p. Kernel pointers should be printed using
%pK allowing some control via the kptr_restrict sysctl. Exposing addresses
gives attackers sensitive information about the kernel layout in memory.

We can reduce the attack surface by hashing all addresses printed with
%p. This will of course break some users, forcing code printing needed
addresses to be updated.

For what it's worth, usage of unadorned %p can be broken down as follows

git grep '%p[^KFfSsBRrbMmIiEUVKNhdDgCGO]' | wc -l

arch: 2512
block: 20
crypto: 12
fs: 1221
include: 147
kernel: 109
lib: 77
mm: 120
net: 1516
security: 11
sound: 168
virt: 2
drivers: 8420

Add helper function siphash_1ulong(). Add function ptr_to_id() to map an
address to a 32 bit unique identifier.

Signed-off-by: Tobin C. Harding 
---

V2:
 - Use SipHash to do the hashing

The discussion related to this patch has been fragmented. There are
three other threads associated with this patch. Email threads by
subject:

[PATCH] printk: hash addresses printed with %p
[PATCH 0/3] add %pX specifier
[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

 include/linux/siphash.h |  2 ++
 lib/siphash.c   | 13 +
 lib/vsprintf.c  | 32 +---
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/include/linux/siphash.h b/include/linux/siphash.h
index fa7a6b9cedbf..a9392568c8b8 100644
--- a/include/linux/siphash.h
+++ b/include/linux/siphash.h
@@ -26,6 +26,8 @@ u64 __siphash_aligned(const void *data, size_t len, const 
siphash_key_t *key);
 u64 __siphash_unaligned(const void *data, size_t len, const siphash_key_t 
*key);
 #endif
 
+unsigned long siphash_1ulong(const unsigned long a, const siphash_key_t *key);
+
 u64 siphash_1u64(const u64 a, const siphash_key_t *key);
 u64 siphash_2u64(const u64 a, const u64 b, const siphash_key_t *key);
 u64 siphash_3u64(const u64 a, const u64 b, const u64 c,
diff --git a/lib/siphash.c b/lib/siphash.c
index 3ae58b4edad6..63f4ff57c9ce 100644
--- a/lib/siphash.c
+++ b/lib/siphash.c
@@ -116,6 +116,19 @@ EXPORT_SYMBOL(__siphash_unaligned);
 #endif
 
 /**
+ * siphash_1ulong - computes siphash PRF value
+ * @first: value to hash
+ * @key: the siphash key
+ */
+unsigned long siphash_1ulong(const unsigned long first, const siphash_key_t 
*key)
+{
+#ifdef CONFIG_64BIT
+   return (unsigned long)siphash_1u64((u64)first, key);
+#endif
+   return (unsigned long)siphash_1u32((u32)first, key);
+}
+
+/**
  * siphash_1u64 - compute 64-bit siphash PRF value of a u64
  * @first: first u64
  * @key: the siphash key
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 86c3385b9eb3..afd1c835b0f6 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_BLOCK
 #include 
 #endif
@@ -503,6 +504,7 @@ char *number(char *buf, char *end, unsigned long long num,
*buf = '0';
++buf;
}
+
/* actual digits of result */
while (--i >= 0) {
if (buf < end)
@@ -1591,6 +1593,28 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
 }
 
+/* Maps a pointer to a 32 bit unique identifier. */
+static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
spec)
+{
+   static siphash_key_t ptr_secret __read_mostly;
+   static bool have_key = false;
+   unsigned long hashval;
+
+   /* Kernel doesn't boot if we use get_random_once() */
+   if (!have_key) {
+   get_random_bytes(_secret, sizeof(ptr_secret));
+   have_key = true;
+   }
+
+   hashval = siphash_1ulong((unsigned long)ptr, _secret);
+
+   spec.field_width = 2 + 2 * sizeof(unsigned int); /* 0x + hex */
+   spec.flags = SPECIAL | SMALL | ZEROPAD;
+   spec.base = 16;
+
+   return number(buf, end, (u32)hashval, spec);
+}
+
 int kptr_restrict __read_mostly;
 
 /*
@@ -1703,6 +1727,9 @@ int kptr_restrict __read_mostly;
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
  * pointer to the real address.
+ *
+ * Default behaviour (unadorned %p) is to hash the address, rendering it useful
+ * as a unique identifier.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1858,14 +1885,13 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
}
-   spec.flags |= SMALL;
+
if (spec.field_width == -1) {
spec.field_width = default_width;
spec.flags |= ZEROPAD;
}
-   spec.base = 16;
 
-   return number(buf, end, (unsigned long) ptr, spec);
+ 

[PATCH v2] printk: hash addresses printed with %p

[Tobin C. Harding]

Currently there are many places in the kernel where addresses are being
printed using an unadorned %p. Kernel pointers should be printed using
%pK allowing some control via the kptr_restrict sysctl. Exposing addresses
gives attackers sensitive information about the kernel layout in memory.

We can reduce the attack surface by hashing all addresses printed with
%p. This will of course break some users, forcing code printing needed
addresses to be updated.

For what it's worth, usage of unadorned %p can be broken down as follows

git grep '%p[^KFfSsBRrbMmIiEUVKNhdDgCGO]' | wc -l

arch: 2512
block: 20
crypto: 12
fs: 1221
include: 147
kernel: 109
lib: 77
mm: 120
net: 1516
security: 11
sound: 168
virt: 2
drivers: 8420

Add helper function siphash_1ulong(). Add function ptr_to_id() to map an
address to a 32 bit unique identifier.

Signed-off-by: Tobin C. Harding 
---

V2:
 - Use SipHash to do the hashing

The discussion related to this patch has been fragmented. There are
three other threads associated with this patch. Email threads by
subject:

[PATCH] printk: hash addresses printed with %p
[PATCH 0/3] add %pX specifier
[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

 include/linux/siphash.h |  2 ++
 lib/siphash.c   | 13 +
 lib/vsprintf.c  | 32 +---
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/include/linux/siphash.h b/include/linux/siphash.h
index fa7a6b9cedbf..a9392568c8b8 100644
--- a/include/linux/siphash.h
+++ b/include/linux/siphash.h
@@ -26,6 +26,8 @@ u64 __siphash_aligned(const void *data, size_t len, const 
siphash_key_t *key);
 u64 __siphash_unaligned(const void *data, size_t len, const siphash_key_t 
*key);
 #endif
 
+unsigned long siphash_1ulong(const unsigned long a, const siphash_key_t *key);
+
 u64 siphash_1u64(const u64 a, const siphash_key_t *key);
 u64 siphash_2u64(const u64 a, const u64 b, const siphash_key_t *key);
 u64 siphash_3u64(const u64 a, const u64 b, const u64 c,
diff --git a/lib/siphash.c b/lib/siphash.c
index 3ae58b4edad6..63f4ff57c9ce 100644
--- a/lib/siphash.c
+++ b/lib/siphash.c
@@ -116,6 +116,19 @@ EXPORT_SYMBOL(__siphash_unaligned);
 #endif
 
 /**
+ * siphash_1ulong - computes siphash PRF value
+ * @first: value to hash
+ * @key: the siphash key
+ */
+unsigned long siphash_1ulong(const unsigned long first, const siphash_key_t 
*key)
+{
+#ifdef CONFIG_64BIT
+   return (unsigned long)siphash_1u64((u64)first, key);
+#endif
+   return (unsigned long)siphash_1u32((u32)first, key);
+}
+
+/**
  * siphash_1u64 - compute 64-bit siphash PRF value of a u64
  * @first: first u64
  * @key: the siphash key
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 86c3385b9eb3..afd1c835b0f6 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_BLOCK
 #include 
 #endif
@@ -503,6 +504,7 @@ char *number(char *buf, char *end, unsigned long long num,
*buf = '0';
++buf;
}
+
/* actual digits of result */
while (--i >= 0) {
if (buf < end)
@@ -1591,6 +1593,28 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
 }
 
+/* Maps a pointer to a 32 bit unique identifier. */
+static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
spec)
+{
+   static siphash_key_t ptr_secret __read_mostly;
+   static bool have_key = false;
+   unsigned long hashval;
+
+   /* Kernel doesn't boot if we use get_random_once() */
+   if (!have_key) {
+   get_random_bytes(_secret, sizeof(ptr_secret));
+   have_key = true;
+   }
+
+   hashval = siphash_1ulong((unsigned long)ptr, _secret);
+
+   spec.field_width = 2 + 2 * sizeof(unsigned int); /* 0x + hex */
+   spec.flags = SPECIAL | SMALL | ZEROPAD;
+   spec.base = 16;
+
+   return number(buf, end, (u32)hashval, spec);
+}
+
 int kptr_restrict __read_mostly;
 
 /*
@@ -1703,6 +1727,9 @@ int kptr_restrict __read_mostly;
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
  * pointer to the real address.
+ *
+ * Default behaviour (unadorned %p) is to hash the address, rendering it useful
+ * as a unique identifier.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1858,14 +1885,13 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
}
-   spec.flags |= SMALL;
+
if (spec.field_width == -1) {
spec.field_width = default_width;
spec.flags |= ZEROPAD;
}
-   spec.base = 16;
 
-   return number(buf, end, (unsigned long) ptr, spec);
+   return 

[tip:x86/timers 7/8] undefined reference to `tsc_async_resets'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/timers
head:   97d21003df3e7504c899b1701546f18ff475966f
commit: 6c66350d0a482892793b888b07c1177fc6d4b344 [7/8] x86/tsc: Provide a means 
to disable TSC ART
config: i386-randconfig-x0-10171011 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 6c66350d0a482892793b888b07c1177fc6d4b344
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/tsc.o: In function `tsc_init':
>> (.init.text+0x87b): undefined reference to `tsc_async_resets'

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


.config.gz
Description: application/gzip

[tip:x86/timers 7/8] undefined reference to `tsc_async_resets'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/timers
head:   97d21003df3e7504c899b1701546f18ff475966f
commit: 6c66350d0a482892793b888b07c1177fc6d4b344 [7/8] x86/tsc: Provide a means 
to disable TSC ART
config: i386-randconfig-x0-10171011 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 6c66350d0a482892793b888b07c1177fc6d4b344
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/tsc.o: In function `tsc_init':
>> (.init.text+0x87b): undefined reference to `tsc_async_resets'

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


.config.gz
Description: application/gzip

[PATCH v3 0/3] add UniPhier efuse support

[Keiji Hayashibara]

This series adds support for eFuse implemented on UniPhier LD20 SoCs.
The eFuse device is under soc-glue and this register implements as read only.

patch v1
https://lkml.org/lkml/2017/8/31/880

patch v2
https://lkml.org/lkml/2017/10/6/20

Changes between v3 and v2
=
1. Fix use of '_' in dt-binnding documentation.


Keiji Hayashibara (3):
  dt-bindings: nvmem: add description for UniPhier eFuse
  nvmem: uniphier: add UniPhier eFuse driver
  arm64: dts: uniphier: add efuse node for LD20

 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 +++
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 18 
 drivers/nvmem/Kconfig  | 11 +++
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 5 files changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
 create mode 100644 drivers/nvmem/uniphier-efuse.c

-- 
2.7.4

[PATCH v3 0/3] add UniPhier efuse support

[Keiji Hayashibara]

This series adds support for eFuse implemented on UniPhier LD20 SoCs.
The eFuse device is under soc-glue and this register implements as read only.

patch v1
https://lkml.org/lkml/2017/8/31/880

patch v2
https://lkml.org/lkml/2017/10/6/20

Changes between v3 and v2
=
1. Fix use of '_' in dt-binnding documentation.


Keiji Hayashibara (3):
  dt-bindings: nvmem: add description for UniPhier eFuse
  nvmem: uniphier: add UniPhier eFuse driver
  arm64: dts: uniphier: add efuse node for LD20

 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 +++
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 18 
 drivers/nvmem/Kconfig  | 11 +++
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 5 files changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
 create mode 100644 drivers/nvmem/uniphier-efuse.c

-- 
2.7.4

[PATCH v3 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

[Keiji Hayashibara]

Add uniphier-efuse dt-bindings documentation.

Signed-off-by: Keiji Hayashibara 
---
 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt

diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt 
b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
new file mode 100644
index 000..dd78bc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
@@ -0,0 +1,49 @@
+= UniPhier eFuse device tree bindings =
+
+This UniPhier eFuse must be under soc-glue.
+
+Required properties:
+- compatible: should be "socionext,uniphier-efuse"
+- reg: should contain the register location and length
+
+= Data cells =
+Are child nodes of efuse, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   usb-mon: usb-mon@54 {
+   reg = <0x54 0xc>;
+   };
+   };
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   usb {
+   ...
+   nvmem-cells = <>;
+   nvmem-cell-names = "usb-mon";
+   }
-- 
2.7.4

[PATCH v3 2/3] nvmem: uniphier: add UniPhier eFuse driver

[Keiji Hayashibara]

Add eFuse driver for Socionext UniPhier series SoC.
Note that eFuse device is under soc-glue and this register
implements as read only.

Signed-off-by: Keiji Hayashibara 
---
 drivers/nvmem/Kconfig  | 11 +
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 3 files changed, 110 insertions(+)
 create mode 100644 drivers/nvmem/uniphier-efuse.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 101ced4..9c32cfe 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -123,6 +123,17 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called nvmem_sunxi_sid.
 
+config UNIPHIER_EFUSE
+   tristate "UniPhier SoCs eFuse support"
+   depends on ARCH_UNIPHIER || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ This is a simple driver to dump specified values of UniPhier SoC
+ from eFuse.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-uniphier-efuse.
+
 config NVMEM_VF610_OCOTP
tristate "VF610 SoC OCOTP support"
depends on SOC_VF610 || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 1731406..2d07162 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE)  += nvmem_rockchip_efuse.o
 nvmem_rockchip_efuse-y := rockchip-efuse.o
 obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
+obj-$(CONFIG_UNIPHIER_EFUSE)   += nvmem-uniphier-efuse.o
+nvmem-uniphier-efuse-y := uniphier-efuse.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
new file mode 100644
index 000..2bb45c4
--- /dev/null
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -0,0 +1,97 @@
+/*
+ * UniPhier eFuse driver
+ *
+ * Copyright (C) 2017 Socionext Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct uniphier_efuse_priv {
+   void __iomem *base;
+};
+
+static int uniphier_reg_read(void *context,
+unsigned int reg, void *_val, size_t bytes)
+{
+   struct uniphier_efuse_priv *priv = context;
+   u32 *val = _val;
+   int offs;
+
+   for (offs = 0; offs < bytes; offs += sizeof(u32))
+   *val++ = readl(priv->base + reg + offs);
+
+   return 0;
+}
+
+static int uniphier_efuse_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct nvmem_config econfig ={};
+   struct uniphier_efuse_priv *priv;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   priv->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(priv->base))
+   return PTR_ERR(priv->base);
+
+   econfig.stride = 4;
+   econfig.word_size = 4;
+   econfig.read_only = true;
+   econfig.reg_read = uniphier_reg_read;
+   econfig.size = resource_size(res);
+   econfig.priv = priv;
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pdev, nvmem);
+
+   return 0;
+}
+
+static int uniphier_efuse_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static const struct of_device_id uniphier_efuse_of_match[] = {
+   { .compatible = "socionext,uniphier-efuse",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
+
+static struct platform_driver uniphier_efuse_driver = {
+   .probe = uniphier_efuse_probe,
+   .remove = uniphier_efuse_remove,
+   .driver = {
+   .name = "uniphier-efuse",
+   .of_match_table = uniphier_efuse_of_match,
+   },
+};
+module_platform_driver(uniphier_efuse_driver);
+
+MODULE_AUTHOR("Keiji Hayashibara ");
+MODULE_DESCRIPTION("UniPhier eFuse driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

[PATCH v3 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

[Keiji Hayashibara]

Add uniphier-efuse dt-bindings documentation.

Signed-off-by: Keiji Hayashibara 
---
 .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt

diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt 
b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
new file mode 100644
index 000..dd78bc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
@@ -0,0 +1,49 @@
+= UniPhier eFuse device tree bindings =
+
+This UniPhier eFuse must be under soc-glue.
+
+Required properties:
+- compatible: should be "socionext,uniphier-efuse"
+- reg: should contain the register location and length
+
+= Data cells =
+Are child nodes of efuse, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   usb-mon: usb-mon@54 {
+   reg = <0x54 0xc>;
+   };
+   };
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   usb {
+   ...
+   nvmem-cells = <>;
+   nvmem-cell-names = "usb-mon";
+   }
-- 
2.7.4

[PATCH v3 2/3] nvmem: uniphier: add UniPhier eFuse driver

[Keiji Hayashibara]

Add eFuse driver for Socionext UniPhier series SoC.
Note that eFuse device is under soc-glue and this register
implements as read only.

Signed-off-by: Keiji Hayashibara 
---
 drivers/nvmem/Kconfig  | 11 +
 drivers/nvmem/Makefile |  2 +
 drivers/nvmem/uniphier-efuse.c | 97 ++
 3 files changed, 110 insertions(+)
 create mode 100644 drivers/nvmem/uniphier-efuse.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 101ced4..9c32cfe 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -123,6 +123,17 @@ config NVMEM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called nvmem_sunxi_sid.
 
+config UNIPHIER_EFUSE
+   tristate "UniPhier SoCs eFuse support"
+   depends on ARCH_UNIPHIER || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ This is a simple driver to dump specified values of UniPhier SoC
+ from eFuse.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-uniphier-efuse.
+
 config NVMEM_VF610_OCOTP
tristate "VF610 SoC OCOTP support"
depends on SOC_VF610 || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 1731406..2d07162 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE)  += nvmem_rockchip_efuse.o
 nvmem_rockchip_efuse-y := rockchip-efuse.o
 obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem_sunxi_sid.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
+obj-$(CONFIG_UNIPHIER_EFUSE)   += nvmem-uniphier-efuse.o
+nvmem-uniphier-efuse-y := uniphier-efuse.o
 obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
new file mode 100644
index 000..2bb45c4
--- /dev/null
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -0,0 +1,97 @@
+/*
+ * UniPhier eFuse driver
+ *
+ * Copyright (C) 2017 Socionext Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct uniphier_efuse_priv {
+   void __iomem *base;
+};
+
+static int uniphier_reg_read(void *context,
+unsigned int reg, void *_val, size_t bytes)
+{
+   struct uniphier_efuse_priv *priv = context;
+   u32 *val = _val;
+   int offs;
+
+   for (offs = 0; offs < bytes; offs += sizeof(u32))
+   *val++ = readl(priv->base + reg + offs);
+
+   return 0;
+}
+
+static int uniphier_efuse_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct resource *res;
+   struct nvmem_device *nvmem;
+   struct nvmem_config econfig ={};
+   struct uniphier_efuse_priv *priv;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   priv->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(priv->base))
+   return PTR_ERR(priv->base);
+
+   econfig.stride = 4;
+   econfig.word_size = 4;
+   econfig.read_only = true;
+   econfig.reg_read = uniphier_reg_read;
+   econfig.size = resource_size(res);
+   econfig.priv = priv;
+   econfig.dev = dev;
+   nvmem = nvmem_register();
+   if (IS_ERR(nvmem))
+   return PTR_ERR(nvmem);
+
+   platform_set_drvdata(pdev, nvmem);
+
+   return 0;
+}
+
+static int uniphier_efuse_remove(struct platform_device *pdev)
+{
+   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+   return nvmem_unregister(nvmem);
+}
+
+static const struct of_device_id uniphier_efuse_of_match[] = {
+   { .compatible = "socionext,uniphier-efuse",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
+
+static struct platform_driver uniphier_efuse_driver = {
+   .probe = uniphier_efuse_probe,
+   .remove = uniphier_efuse_remove,
+   .driver = {
+   .name = "uniphier-efuse",
+   .of_match_table = uniphier_efuse_of_match,
+   },
+};
+module_platform_driver(uniphier_efuse_driver);
+
+MODULE_AUTHOR("Keiji Hayashibara ");
+MODULE_DESCRIPTION("UniPhier eFuse driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

[PATCH v3 3/3] arm64: dts: uniphier: add efuse node for LD20

[Keiji Hayashibara]

Add efuse node for UniPhier LD20 SoC.
This efuse node is included in soc-glue.

Signed-off-by: Keiji Hayashibara 
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..ddefde6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -376,6 +376,24 @@
};
};
 
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   };
+   };
+
aidet: aidet@5fc2 {
compatible = "socionext,uniphier-ld20-aidet";
reg = <0x5fc2 0x200>;
-- 
2.7.4

[PATCH v3 3/3] arm64: dts: uniphier: add efuse node for LD20

[Keiji Hayashibara]

Add efuse node for UniPhier LD20 SoC.
This efuse node is included in soc-glue.

Signed-off-by: Keiji Hayashibara 
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..ddefde6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -376,6 +376,24 @@
};
};
 
+   soc-glue@5f90 {
+   compatible = "socionext,uniphier-ld20-soc-glue-debug",
+"simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x5f90 0x2000>;
+
+   efuse@100 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x100 0x28>;
+   };
+
+   efuse@200 {
+   compatible = "socionext,uniphier-efuse";
+   reg = <0x200 0x68>;
+   };
+   };
+
aidet: aidet@5fc2 {
compatible = "socionext,uniphier-ld20-aidet";
reg = <0x5fc2 0x200>;
-- 
2.7.4

Re: [PATCH 24/25] thermal/drivers/hisi: Add support for hi3660 SoC

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:49PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> This patch adds the support for thermal sensor on the Hi3660 SoC.
> Hi3660 tsensor support alarm interrupt and have three configurable
> alarm thresholds, it also has a configurable hysteresis interval,
> interrupt will be triggered when temperature rise above the alarm
> threshold or fall below the hysteresis threshold.

Minor:


CHECK: Alignment should match open parenthesis
#173: FILE: drivers/thermal/hisi_thermal.c:214:
+   writel(DIV_ROUND_UP(value, HI3660_TEMP_STEP) & 0x7F,
+   addr + HI3660_LAG(id));

total: 0 errors, 0 warnings, 1 checks, 205 lines checked

> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 146 
> -
>  1 file changed, 145 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index e87ca6c..10276f0 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -39,12 +39,24 @@
>  #define HI6220_TEMP0_RST_MSK (0x1C)
>  #define HI6220_TEMP0_VALUE   (0x28)
>  
> +#define HI3660_OFFSET(chan)  ((chan) * 0x40)
> +#define HI3660_TEMP(chan)(HI3660_OFFSET(chan) + 0x1C)
> +#define HI3660_TH(chan)  (HI3660_OFFSET(chan) + 0x20)
> +#define HI3660_LAG(chan) (HI3660_OFFSET(chan) + 0x28)
> +#define HI3660_INT_EN(chan)  (HI3660_OFFSET(chan) + 0x2C)
> +#define HI3660_INT_CLR(chan) (HI3660_OFFSET(chan) + 0x30)
> +
>  #define HI6220_TEMP_BASE (-6)
>  #define HI6220_TEMP_RESET(10)
>  #define HI6220_TEMP_STEP (785)
>  #define HI6220_TEMP_LAG  (3500)
>  
> +#define HI3660_TEMP_BASE (-63780)
> +#define HI3660_TEMP_STEP (205)
> +#define HI3660_TEMP_LAG  (4000)
> +
>  #define HI6220_DEFAULT_SENSOR2
> +#define HI3660_DEFAULT_SENSOR1
>  
>  #define MAX_THRES_NUM2
>  
> @@ -96,6 +108,24 @@ static inline int hi6220_thermal_temp_to_step(int temp)
>  }
>  
>  /*
> + * for Hi3660,
> + *   Step: 189/922 (0.205)
> + *   Temperature base: -63.780°C
> + *
> + * The register is programmed in temperature steps, every step is 205
> + * millidegree and begins at -63 780 m°C
> + */
> +static inline int hi3660_thermal_step_to_temp(int step)
> +{
> + return HI3660_TEMP_BASE + step * HI3660_TEMP_STEP;
> +}
> +
> +static inline int hi3660_thermal_temp_to_step(int temp)
> +{
> + return DIV_ROUND_UP(temp - HI3660_TEMP_BASE, HI3660_TEMP_STEP);
> +}
> +
> +/*
>   * The lag register contains 5 bits encoding the temperature in steps.
>   *
>   * Each time the temperature crosses the threshold boundary, an
> @@ -169,6 +199,45 @@ static inline int hi6220_thermal_get_temperature(void 
> __iomem *addr)
>  }
>  
>  /*
> + * [0:6] lag register
> + *
> + * The temperature is coded in steps, cf. HI3660_TEMP_STEP.
> + *
> + * Min : 0x00 :  0.0 °C
> + * Max : 0x7F : 26.0 °C
> + *
> + */
> +static inline void hi3660_thermal_set_lag(void __iomem *addr,
> +   int id, int value)
> +{
> + writel(DIV_ROUND_UP(value, HI3660_TEMP_STEP) & 0x7F,
> + addr + HI3660_LAG(id));
> +}
> +
> +static inline void hi3660_thermal_alarm_clear(void __iomem *addr,
> +   int id, int value)
> +{
> + writel(value, addr + HI3660_INT_CLR(id));
> +}
> +
> +static inline void hi3660_thermal_alarm_enable(void __iomem *addr,
> +int id, int value)
> +{
> + writel(value, addr + HI3660_INT_EN(id));
> +}
> +
> +static inline void hi3660_thermal_alarm_set(void __iomem *addr,
> + int id, int value)
> +{
> + writel(value, addr + HI3660_TH(id));
> +}
> +
> +static inline int hi3660_thermal_get_temperature(void __iomem *addr, int id)
> +{
> + return hi3660_thermal_step_to_temp(readl(addr + HI3660_TEMP(id)));
> +}
> +
> +/*
>   * Temperature configuration register - Sensor selection
>   *
>   * Bits [19:12]
> @@ -206,11 +275,22 @@ static int hi6220_thermal_irq_handler(struct 
> hisi_thermal_data *data)
>   return 0;
>  }
>  
> +static int hi3660_thermal_irq_handler(struct hisi_thermal_data *data)
> +{
> + hi3660_thermal_alarm_clear(data->regs, data->sensor.id, 1);
> + return 0;
> +}
> +
>  static int hi6220_thermal_get_temp(struct hisi_thermal_data *data)
>  {
>   return hi6220_thermal_get_temperature(data->regs);
>  }
>  
> +static int hi3660_thermal_get_temp(struct hisi_thermal_data *data)
> +{
> + return hi3660_thermal_get_temperature(data->regs, data->sensor.id);
> +}
> +
>  static int 

Re: [PATCH 24/25] thermal/drivers/hisi: Add support for hi3660 SoC

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:49PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> This patch adds the support for thermal sensor on the Hi3660 SoC.
> Hi3660 tsensor support alarm interrupt and have three configurable
> alarm thresholds, it also has a configurable hysteresis interval,
> interrupt will be triggered when temperature rise above the alarm
> threshold or fall below the hysteresis threshold.

Minor:


CHECK: Alignment should match open parenthesis
#173: FILE: drivers/thermal/hisi_thermal.c:214:
+   writel(DIV_ROUND_UP(value, HI3660_TEMP_STEP) & 0x7F,
+   addr + HI3660_LAG(id));

total: 0 errors, 0 warnings, 1 checks, 205 lines checked

> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 146 
> -
>  1 file changed, 145 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index e87ca6c..10276f0 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -39,12 +39,24 @@
>  #define HI6220_TEMP0_RST_MSK (0x1C)
>  #define HI6220_TEMP0_VALUE   (0x28)
>  
> +#define HI3660_OFFSET(chan)  ((chan) * 0x40)
> +#define HI3660_TEMP(chan)(HI3660_OFFSET(chan) + 0x1C)
> +#define HI3660_TH(chan)  (HI3660_OFFSET(chan) + 0x20)
> +#define HI3660_LAG(chan) (HI3660_OFFSET(chan) + 0x28)
> +#define HI3660_INT_EN(chan)  (HI3660_OFFSET(chan) + 0x2C)
> +#define HI3660_INT_CLR(chan) (HI3660_OFFSET(chan) + 0x30)
> +
>  #define HI6220_TEMP_BASE (-6)
>  #define HI6220_TEMP_RESET(10)
>  #define HI6220_TEMP_STEP (785)
>  #define HI6220_TEMP_LAG  (3500)
>  
> +#define HI3660_TEMP_BASE (-63780)
> +#define HI3660_TEMP_STEP (205)
> +#define HI3660_TEMP_LAG  (4000)
> +
>  #define HI6220_DEFAULT_SENSOR2
> +#define HI3660_DEFAULT_SENSOR1
>  
>  #define MAX_THRES_NUM2
>  
> @@ -96,6 +108,24 @@ static inline int hi6220_thermal_temp_to_step(int temp)
>  }
>  
>  /*
> + * for Hi3660,
> + *   Step: 189/922 (0.205)
> + *   Temperature base: -63.780°C
> + *
> + * The register is programmed in temperature steps, every step is 205
> + * millidegree and begins at -63 780 m°C
> + */
> +static inline int hi3660_thermal_step_to_temp(int step)
> +{
> + return HI3660_TEMP_BASE + step * HI3660_TEMP_STEP;
> +}
> +
> +static inline int hi3660_thermal_temp_to_step(int temp)
> +{
> + return DIV_ROUND_UP(temp - HI3660_TEMP_BASE, HI3660_TEMP_STEP);
> +}
> +
> +/*
>   * The lag register contains 5 bits encoding the temperature in steps.
>   *
>   * Each time the temperature crosses the threshold boundary, an
> @@ -169,6 +199,45 @@ static inline int hi6220_thermal_get_temperature(void 
> __iomem *addr)
>  }
>  
>  /*
> + * [0:6] lag register
> + *
> + * The temperature is coded in steps, cf. HI3660_TEMP_STEP.
> + *
> + * Min : 0x00 :  0.0 °C
> + * Max : 0x7F : 26.0 °C
> + *
> + */
> +static inline void hi3660_thermal_set_lag(void __iomem *addr,
> +   int id, int value)
> +{
> + writel(DIV_ROUND_UP(value, HI3660_TEMP_STEP) & 0x7F,
> + addr + HI3660_LAG(id));
> +}
> +
> +static inline void hi3660_thermal_alarm_clear(void __iomem *addr,
> +   int id, int value)
> +{
> + writel(value, addr + HI3660_INT_CLR(id));
> +}
> +
> +static inline void hi3660_thermal_alarm_enable(void __iomem *addr,
> +int id, int value)
> +{
> + writel(value, addr + HI3660_INT_EN(id));
> +}
> +
> +static inline void hi3660_thermal_alarm_set(void __iomem *addr,
> + int id, int value)
> +{
> + writel(value, addr + HI3660_TH(id));
> +}
> +
> +static inline int hi3660_thermal_get_temperature(void __iomem *addr, int id)
> +{
> + return hi3660_thermal_step_to_temp(readl(addr + HI3660_TEMP(id)));
> +}
> +
> +/*
>   * Temperature configuration register - Sensor selection
>   *
>   * Bits [19:12]
> @@ -206,11 +275,22 @@ static int hi6220_thermal_irq_handler(struct 
> hisi_thermal_data *data)
>   return 0;
>  }
>  
> +static int hi3660_thermal_irq_handler(struct hisi_thermal_data *data)
> +{
> + hi3660_thermal_alarm_clear(data->regs, data->sensor.id, 1);
> + return 0;
> +}
> +
>  static int hi6220_thermal_get_temp(struct hisi_thermal_data *data)
>  {
>   return hi6220_thermal_get_temperature(data->regs);
>  }
>  
> +static int hi3660_thermal_get_temp(struct hisi_thermal_data *data)
> +{
> + return hi3660_thermal_get_temperature(data->regs, data->sensor.id);
> +}
> +
>  static int hi6220_thermal_disable_sensor(struct hisi_thermal_data *data)
>  {
>   /* disable 

Re: [PATCH 22/25] thermal/drivers/hisi: Add support for multi temp threshold

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:47PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> The next patches will provide the support for the hi3660 where the temperature
> sensor can have multiple alarm levels. In order to set the scene to support 
> it,
> we have to convert the current code to be able to support multiple threshold
> values.
> 
> [Daniel Lezcano: Restated the log]

CHECK: Prefer kernel type 'u32' over 'uint32_t'
#113: FILE: drivers/thermal/hisi_thermal.c:54:
+   uint32_t thres_temp[MAX_THRES_NUM];

total: 0 errors, 1 warnings, 1 checks, 67 lines checked



> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b5a7159..e87ca6c 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -46,10 +46,12 @@
>  
>  #define HI6220_DEFAULT_SENSOR2
>  
> +#define MAX_THRES_NUM2
> +
>  struct hisi_thermal_sensor {
>   struct thermal_zone_device *tzd;
>   uint32_t id;
> - uint32_t thres_temp;
> + uint32_t thres_temp[MAX_THRES_NUM];
>  };
>  
>  struct hisi_thermal_data {
> @@ -244,7 +246,7 @@ static int hi6220_thermal_enable_sensor(struct 
> hisi_thermal_data *data)
>   hi6220_thermal_set_lag(data->regs, HI6220_TEMP_LAG);
>  
>   /* enable for interrupt */
> - hi6220_thermal_alarm_set(data->regs, sensor->thres_temp);
> + hi6220_thermal_alarm_set(data->regs, sensor->thres_temp[0]);
>  
>   hi6220_thermal_reset_set(data->regs, HI6220_TEMP_RESET);
>  
> @@ -303,7 +305,7 @@ static int hisi_thermal_get_temp(void *__data, int *temp)
>   *temp = data->get_temp(data);
>  
>   dev_dbg(>pdev->dev, "id=%d, temp=%d, thres=%d\n",
> - sensor->id, *temp, sensor->thres_temp);
> + sensor->id, *temp, sensor->thres_temp[0]);
>  
>   return 0;
>  }
> @@ -322,16 +324,16 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int 
> irq, void *dev)
>  
>   hisi_thermal_get_temp(data, );
>  
> - if (temp >= sensor->thres_temp) {
> + if (temp >= sensor->thres_temp[0]) {
>   dev_crit(>pdev->dev, "THERMAL ALARM: %d > %d\n",
> -  temp, sensor->thres_temp);
> +  temp, sensor->thres_temp[0]);
>  
>   thermal_zone_device_update(data->sensor.tzd,
>  THERMAL_EVENT_UNSPECIFIED);
>  
>   } else {
>   dev_crit(>pdev->dev, "THERMAL ALARM stopped: %d < %d\n",
> -  temp, sensor->thres_temp);
> +  temp, sensor->thres_temp[0]);
>   }
>  
>   return IRQ_HANDLED;
> @@ -341,7 +343,7 @@ static int hisi_thermal_register_sensor(struct 
> platform_device *pdev,
>   struct hisi_thermal_data *data,
>   struct hisi_thermal_sensor *sensor)
>  {
> - int ret, i;
> + int ret, i, thres_idx = 0;
>   const struct thermal_trip *trip;
>  
>   sensor->tzd = devm_thermal_zone_of_sensor_register(>dev,
> @@ -359,8 +361,9 @@ static int hisi_thermal_register_sensor(struct 
> platform_device *pdev,
>  
>   for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) {
>   if (trip[i].type == THERMAL_TRIP_PASSIVE) {
> - sensor->thres_temp = trip[i].temperature;
> - break;
> + sensor->thres_temp[thres_idx++] = trip[i].temperature;
> + if (thres_idx >= MAX_THRES_NUM)
> + break;
>   }
>   }
>  
> -- 
> 2.7.4
> 

Re: [PATCH 22/25] thermal/drivers/hisi: Add support for multi temp threshold

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:47PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> The next patches will provide the support for the hi3660 where the temperature
> sensor can have multiple alarm levels. In order to set the scene to support 
> it,
> we have to convert the current code to be able to support multiple threshold
> values.
> 
> [Daniel Lezcano: Restated the log]

CHECK: Prefer kernel type 'u32' over 'uint32_t'
#113: FILE: drivers/thermal/hisi_thermal.c:54:
+   uint32_t thres_temp[MAX_THRES_NUM];

total: 0 errors, 1 warnings, 1 checks, 67 lines checked



> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index b5a7159..e87ca6c 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -46,10 +46,12 @@
>  
>  #define HI6220_DEFAULT_SENSOR2
>  
> +#define MAX_THRES_NUM2
> +
>  struct hisi_thermal_sensor {
>   struct thermal_zone_device *tzd;
>   uint32_t id;
> - uint32_t thres_temp;
> + uint32_t thres_temp[MAX_THRES_NUM];
>  };
>  
>  struct hisi_thermal_data {
> @@ -244,7 +246,7 @@ static int hi6220_thermal_enable_sensor(struct 
> hisi_thermal_data *data)
>   hi6220_thermal_set_lag(data->regs, HI6220_TEMP_LAG);
>  
>   /* enable for interrupt */
> - hi6220_thermal_alarm_set(data->regs, sensor->thres_temp);
> + hi6220_thermal_alarm_set(data->regs, sensor->thres_temp[0]);
>  
>   hi6220_thermal_reset_set(data->regs, HI6220_TEMP_RESET);
>  
> @@ -303,7 +305,7 @@ static int hisi_thermal_get_temp(void *__data, int *temp)
>   *temp = data->get_temp(data);
>  
>   dev_dbg(>pdev->dev, "id=%d, temp=%d, thres=%d\n",
> - sensor->id, *temp, sensor->thres_temp);
> + sensor->id, *temp, sensor->thres_temp[0]);
>  
>   return 0;
>  }
> @@ -322,16 +324,16 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int 
> irq, void *dev)
>  
>   hisi_thermal_get_temp(data, );
>  
> - if (temp >= sensor->thres_temp) {
> + if (temp >= sensor->thres_temp[0]) {
>   dev_crit(>pdev->dev, "THERMAL ALARM: %d > %d\n",
> -  temp, sensor->thres_temp);
> +  temp, sensor->thres_temp[0]);
>  
>   thermal_zone_device_update(data->sensor.tzd,
>  THERMAL_EVENT_UNSPECIFIED);
>  
>   } else {
>   dev_crit(>pdev->dev, "THERMAL ALARM stopped: %d < %d\n",
> -  temp, sensor->thres_temp);
> +  temp, sensor->thres_temp[0]);
>   }
>  
>   return IRQ_HANDLED;
> @@ -341,7 +343,7 @@ static int hisi_thermal_register_sensor(struct 
> platform_device *pdev,
>   struct hisi_thermal_data *data,
>   struct hisi_thermal_sensor *sensor)
>  {
> - int ret, i;
> + int ret, i, thres_idx = 0;
>   const struct thermal_trip *trip;
>  
>   sensor->tzd = devm_thermal_zone_of_sensor_register(>dev,
> @@ -359,8 +361,9 @@ static int hisi_thermal_register_sensor(struct 
> platform_device *pdev,
>  
>   for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) {
>   if (trip[i].type == THERMAL_TRIP_PASSIVE) {
> - sensor->thres_temp = trip[i].temperature;
> - break;
> + sensor->thres_temp[thres_idx++] = trip[i].temperature;
> + if (thres_idx >= MAX_THRES_NUM)
> + break;
>   }
>   }
>  
> -- 
> 2.7.4
> 

Re: [PATCH 19/25] thermal/drivers/hisi: Put platform code together

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:44PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> Reorganize the code for next patches by moving the functions upper in
> the file which will prevent a forward declaration. There is no functional
> change here.
> 


CHECK: Please don't use multiple blank lines
#104: FILE: drivers/thermal/hisi_thermal.c:204:
 
 +

 total: 0 errors, 0 warnings, 1 checks, 88 lines checked


> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 76 
> +-
>  1 file changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index befdb28..ff9055a 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -201,6 +201,44 @@ static void hisi_thermal_disable_sensor(struct 
> hisi_thermal_data *data)
>   clk_disable_unprepare(data->clk);
>  }
>  
> +
> +static int hisi_thermal_setup(struct hisi_thermal_data *data)
> +{
> + struct hisi_thermal_sensor *sensor = >sensor;
> + int ret;
> +
> + /* enable clock for tsensor */
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> + /* disable module firstly */
> + hisi_thermal_reset_enable(data->regs, 0);
> + hisi_thermal_enable(data->regs, 0);
> +
> + /* select sensor id */
> + hisi_thermal_sensor_select(data->regs, sensor->id);
> +
> + /* setting the hdak time */
> + hisi_thermal_hdak_set(data->regs, 0);
> +
> + /* setting lag value between current temp and the threshold */
> + hisi_thermal_set_lag(data->regs, HISI_TEMP_LAG);
> +
> + /* enable for interrupt */
> + hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
> +
> + hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
> +
> + /* enable module */
> + hisi_thermal_reset_enable(data->regs, 1);
> + hisi_thermal_enable(data->regs, 1);
> +
> + hisi_thermal_alarm_clear(data->regs, 0);
> + hisi_thermal_alarm_enable(data->regs, 1);
> +
> + return 0;
> +}
>  static int hisi_thermal_get_temp(void *__data, int *temp)
>  {
>   struct hisi_thermal_data *data = __data;
> @@ -291,44 +329,6 @@ static void hisi_thermal_toggle_sensor(struct 
> hisi_thermal_sensor *sensor,
>   on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
>  }
>  
> -static int hisi_thermal_setup(struct hisi_thermal_data *data)
> -{
> - struct hisi_thermal_sensor *sensor = >sensor;
> - int ret;
> -
> - /* enable clock for tsensor */
> - ret = clk_prepare_enable(data->clk);
> - if (ret)
> - return ret;
> -
> - /* disable module firstly */
> - hisi_thermal_reset_enable(data->regs, 0);
> - hisi_thermal_enable(data->regs, 0);
> -
> - /* select sensor id */
> - hisi_thermal_sensor_select(data->regs, sensor->id);
> -
> - /* setting the hdak time */
> - hisi_thermal_hdak_set(data->regs, 0);
> -
> - /* setting lag value between current temp and the threshold */
> - hisi_thermal_set_lag(data->regs, HISI_TEMP_LAG);
> -
> - /* enable for interrupt */
> - hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
> -
> - hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
> -
> - /* enable module */
> - hisi_thermal_reset_enable(data->regs, 1);
> - hisi_thermal_enable(data->regs, 1);
> -
> - hisi_thermal_alarm_clear(data->regs, 0);
> - hisi_thermal_alarm_enable(data->regs, 1);
> -
> - return 0;
> -}
> -
>  static int hisi_thermal_probe(struct platform_device *pdev)
>  {
>   struct hisi_thermal_data *data;
> -- 
> 2.7.4
> 

Re: [PATCH 20/25] thermal/drivers/hisi: Add platform prefix to function name

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:45PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> As the next patches will provide support for the hikey3660's sensor, several
> functions with the same purpose but for different platforms will be 
> introduced.
> In order to make a clear distinction between them, let's prefix the function
> names with the platform name.
> 
> This patch has no functional changes.


CHECK: Alignment should match open parenthesis
#188: FILE: drivers/thermal/hisi_thermal.c:124:
+   writel(DIV_ROUND_UP(value, HI6220_TEMP_STEP) & 0x1F,
+   addr + HI6220_TEMP0_LAG);

CHECK: Alignment should match open parenthesis
#210: FILE: drivers/thermal/hisi_thermal.c:140:
+   writel(hi6220_thermal_temp_to_step(temp) | 0x0FF00,
+   addr + HI6220_TEMP0_TH);

total: 0 errors, 1 warnings, 2 checks, 286 lines checked



> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 145 
> +
>  1 file changed, 73 insertions(+), 72 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index ff9055a..8a70ab7 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -26,25 +26,24 @@
>  
>  #include "thermal_core.h"
>  
> -#define TEMP0_LAG(0x0)
> -#define TEMP0_TH (0x4)
> -#define TEMP0_RST_TH (0x8)
> -#define TEMP0_CFG(0xC)
> -#define TEMP0_CFG_SS_MSK (0xF000)
> -#define TEMP0_CFG_HDAK_MSK   (0x30)
> -#define TEMP0_EN (0x10)
> -#define TEMP0_INT_EN (0x14)
> -#define TEMP0_INT_CLR(0x18)
> -#define TEMP0_RST_MSK(0x1C)
> -#define TEMP0_VALUE  (0x28)
> -
> -#define HISI_TEMP_BASE   (-6)
> -#define HISI_TEMP_RESET  (10)
> -#define HISI_TEMP_STEP   (785)
> -#define HISI_TEMP_LAG(3500)
> -
> -#define HISI_MAX_SENSORS 4
> -#define HISI_DEFAULT_SENSOR  2
> +#define HI6220_TEMP0_LAG (0x0)
> +#define HI6220_TEMP0_TH  (0x4)
> +#define HI6220_TEMP0_RST_TH  (0x8)
> +#define HI6220_TEMP0_CFG (0xC)
> +#define HI6220_TEMP0_CFG_SS_MSK  (0xF000)
> +#define HI6220_TEMP0_CFG_HDAK_MSK(0x30)
> +#define HI6220_TEMP0_EN  (0x10)
> +#define HI6220_TEMP0_INT_EN  (0x14)
> +#define HI6220_TEMP0_INT_CLR (0x18)
> +#define HI6220_TEMP0_RST_MSK (0x1C)
> +#define HI6220_TEMP0_VALUE   (0x28)
> +
> +#define HI6220_TEMP_BASE (-6)
> +#define HI6220_TEMP_RESET(10)
> +#define HI6220_TEMP_STEP (785)
> +#define HI6220_TEMP_LAG  (3500)
> +
> +#define HI6220_DEFAULT_SENSOR2
>  
>  struct hisi_thermal_sensor {
>   struct thermal_zone_device *tzd;
> @@ -78,14 +77,14 @@ struct hisi_thermal_data {
>   *   steps = (Temp - TempBase) / 785
>   *
>   */
> -static inline int hisi_thermal_step_to_temp(int step)
> +static inline int hi6220_thermal_step_to_temp(int step)
>  {
> - return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
> + return HI6220_TEMP_BASE + (step * HI6220_TEMP_STEP);
>  }
>  
> -static inline int hisi_thermal_temp_to_step(int temp)
> +static inline int hi6220_thermal_temp_to_step(int temp)
>  {
> - return DIV_ROUND_UP(temp - HISI_TEMP_BASE, HISI_TEMP_STEP);
> + return DIV_ROUND_UP(temp - HI6220_TEMP_BASE, HI6220_TEMP_STEP);
>  }
>  
>  /*
> @@ -112,51 +111,53 @@ static inline int hisi_thermal_temp_to_step(int temp)
>   *
>   * [0:4] : lag register
>   *
> - * The temperature is coded in steps, cf. HISI_TEMP_STEP.
> + * The temperature is coded in steps, cf. HI6220_TEMP_STEP.
>   *
>   * Min : 0x00 :  0.0 °C
>   * Max : 0x1F : 24.3 °C
>   *
>   * The 'value' parameter is in milliCelsius.
>   */
> -static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> +static inline void hi6220_thermal_set_lag(void __iomem *addr, int value)
>  {
> - writel(DIV_ROUND_UP(value, HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
> + writel(DIV_ROUND_UP(value, HI6220_TEMP_STEP) & 0x1F,
> + addr + HI6220_TEMP0_LAG);
>  }
>  
> -static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> +static inline void hi6220_thermal_alarm_clear(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_INT_CLR);
> + writel(value, addr + HI6220_TEMP0_INT_CLR);
>  }
>  
> -static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> +static inline void hi6220_thermal_alarm_enable(void 

Re: [PATCH 19/25] thermal/drivers/hisi: Put platform code together

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:44PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> Reorganize the code for next patches by moving the functions upper in
> the file which will prevent a forward declaration. There is no functional
> change here.
> 


CHECK: Please don't use multiple blank lines
#104: FILE: drivers/thermal/hisi_thermal.c:204:
 
 +

 total: 0 errors, 0 warnings, 1 checks, 88 lines checked


> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 76 
> +-
>  1 file changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index befdb28..ff9055a 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -201,6 +201,44 @@ static void hisi_thermal_disable_sensor(struct 
> hisi_thermal_data *data)
>   clk_disable_unprepare(data->clk);
>  }
>  
> +
> +static int hisi_thermal_setup(struct hisi_thermal_data *data)
> +{
> + struct hisi_thermal_sensor *sensor = >sensor;
> + int ret;
> +
> + /* enable clock for tsensor */
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> + /* disable module firstly */
> + hisi_thermal_reset_enable(data->regs, 0);
> + hisi_thermal_enable(data->regs, 0);
> +
> + /* select sensor id */
> + hisi_thermal_sensor_select(data->regs, sensor->id);
> +
> + /* setting the hdak time */
> + hisi_thermal_hdak_set(data->regs, 0);
> +
> + /* setting lag value between current temp and the threshold */
> + hisi_thermal_set_lag(data->regs, HISI_TEMP_LAG);
> +
> + /* enable for interrupt */
> + hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
> +
> + hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
> +
> + /* enable module */
> + hisi_thermal_reset_enable(data->regs, 1);
> + hisi_thermal_enable(data->regs, 1);
> +
> + hisi_thermal_alarm_clear(data->regs, 0);
> + hisi_thermal_alarm_enable(data->regs, 1);
> +
> + return 0;
> +}
>  static int hisi_thermal_get_temp(void *__data, int *temp)
>  {
>   struct hisi_thermal_data *data = __data;
> @@ -291,44 +329,6 @@ static void hisi_thermal_toggle_sensor(struct 
> hisi_thermal_sensor *sensor,
>   on ? THERMAL_DEVICE_ENABLED : THERMAL_DEVICE_DISABLED);
>  }
>  
> -static int hisi_thermal_setup(struct hisi_thermal_data *data)
> -{
> - struct hisi_thermal_sensor *sensor = >sensor;
> - int ret;
> -
> - /* enable clock for tsensor */
> - ret = clk_prepare_enable(data->clk);
> - if (ret)
> - return ret;
> -
> - /* disable module firstly */
> - hisi_thermal_reset_enable(data->regs, 0);
> - hisi_thermal_enable(data->regs, 0);
> -
> - /* select sensor id */
> - hisi_thermal_sensor_select(data->regs, sensor->id);
> -
> - /* setting the hdak time */
> - hisi_thermal_hdak_set(data->regs, 0);
> -
> - /* setting lag value between current temp and the threshold */
> - hisi_thermal_set_lag(data->regs, HISI_TEMP_LAG);
> -
> - /* enable for interrupt */
> - hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
> -
> - hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
> -
> - /* enable module */
> - hisi_thermal_reset_enable(data->regs, 1);
> - hisi_thermal_enable(data->regs, 1);
> -
> - hisi_thermal_alarm_clear(data->regs, 0);
> - hisi_thermal_alarm_enable(data->regs, 1);
> -
> - return 0;
> -}
> -
>  static int hisi_thermal_probe(struct platform_device *pdev)
>  {
>   struct hisi_thermal_data *data;
> -- 
> 2.7.4
> 

Re: [PATCH 20/25] thermal/drivers/hisi: Add platform prefix to function name

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:45PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> As the next patches will provide support for the hikey3660's sensor, several
> functions with the same purpose but for different platforms will be 
> introduced.
> In order to make a clear distinction between them, let's prefix the function
> names with the platform name.
> 
> This patch has no functional changes.


CHECK: Alignment should match open parenthesis
#188: FILE: drivers/thermal/hisi_thermal.c:124:
+   writel(DIV_ROUND_UP(value, HI6220_TEMP_STEP) & 0x1F,
+   addr + HI6220_TEMP0_LAG);

CHECK: Alignment should match open parenthesis
#210: FILE: drivers/thermal/hisi_thermal.c:140:
+   writel(hi6220_thermal_temp_to_step(temp) | 0x0FF00,
+   addr + HI6220_TEMP0_TH);

total: 0 errors, 1 warnings, 2 checks, 286 lines checked



> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 145 
> +
>  1 file changed, 73 insertions(+), 72 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index ff9055a..8a70ab7 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -26,25 +26,24 @@
>  
>  #include "thermal_core.h"
>  
> -#define TEMP0_LAG(0x0)
> -#define TEMP0_TH (0x4)
> -#define TEMP0_RST_TH (0x8)
> -#define TEMP0_CFG(0xC)
> -#define TEMP0_CFG_SS_MSK (0xF000)
> -#define TEMP0_CFG_HDAK_MSK   (0x30)
> -#define TEMP0_EN (0x10)
> -#define TEMP0_INT_EN (0x14)
> -#define TEMP0_INT_CLR(0x18)
> -#define TEMP0_RST_MSK(0x1C)
> -#define TEMP0_VALUE  (0x28)
> -
> -#define HISI_TEMP_BASE   (-6)
> -#define HISI_TEMP_RESET  (10)
> -#define HISI_TEMP_STEP   (785)
> -#define HISI_TEMP_LAG(3500)
> -
> -#define HISI_MAX_SENSORS 4
> -#define HISI_DEFAULT_SENSOR  2
> +#define HI6220_TEMP0_LAG (0x0)
> +#define HI6220_TEMP0_TH  (0x4)
> +#define HI6220_TEMP0_RST_TH  (0x8)
> +#define HI6220_TEMP0_CFG (0xC)
> +#define HI6220_TEMP0_CFG_SS_MSK  (0xF000)
> +#define HI6220_TEMP0_CFG_HDAK_MSK(0x30)
> +#define HI6220_TEMP0_EN  (0x10)
> +#define HI6220_TEMP0_INT_EN  (0x14)
> +#define HI6220_TEMP0_INT_CLR (0x18)
> +#define HI6220_TEMP0_RST_MSK (0x1C)
> +#define HI6220_TEMP0_VALUE   (0x28)
> +
> +#define HI6220_TEMP_BASE (-6)
> +#define HI6220_TEMP_RESET(10)
> +#define HI6220_TEMP_STEP (785)
> +#define HI6220_TEMP_LAG  (3500)
> +
> +#define HI6220_DEFAULT_SENSOR2
>  
>  struct hisi_thermal_sensor {
>   struct thermal_zone_device *tzd;
> @@ -78,14 +77,14 @@ struct hisi_thermal_data {
>   *   steps = (Temp - TempBase) / 785
>   *
>   */
> -static inline int hisi_thermal_step_to_temp(int step)
> +static inline int hi6220_thermal_step_to_temp(int step)
>  {
> - return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
> + return HI6220_TEMP_BASE + (step * HI6220_TEMP_STEP);
>  }
>  
> -static inline int hisi_thermal_temp_to_step(int temp)
> +static inline int hi6220_thermal_temp_to_step(int temp)
>  {
> - return DIV_ROUND_UP(temp - HISI_TEMP_BASE, HISI_TEMP_STEP);
> + return DIV_ROUND_UP(temp - HI6220_TEMP_BASE, HI6220_TEMP_STEP);
>  }
>  
>  /*
> @@ -112,51 +111,53 @@ static inline int hisi_thermal_temp_to_step(int temp)
>   *
>   * [0:4] : lag register
>   *
> - * The temperature is coded in steps, cf. HISI_TEMP_STEP.
> + * The temperature is coded in steps, cf. HI6220_TEMP_STEP.
>   *
>   * Min : 0x00 :  0.0 °C
>   * Max : 0x1F : 24.3 °C
>   *
>   * The 'value' parameter is in milliCelsius.
>   */
> -static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
> +static inline void hi6220_thermal_set_lag(void __iomem *addr, int value)
>  {
> - writel(DIV_ROUND_UP(value, HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
> + writel(DIV_ROUND_UP(value, HI6220_TEMP_STEP) & 0x1F,
> + addr + HI6220_TEMP0_LAG);
>  }
>  
> -static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
> +static inline void hi6220_thermal_alarm_clear(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_INT_CLR);
> + writel(value, addr + HI6220_TEMP0_INT_CLR);
>  }
>  
> -static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
> +static inline void hi6220_thermal_alarm_enable(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_INT_EN);
> + 

Re: [PATCH 21/25] thermal/drivers/hisi: Prepare to add support for other hisi platforms

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:46PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> For platform compatibility, add the tsensor ops to a thermal data structure.
> Each platform has its own probe function to register proper tsensor ops
> function to the pointer, platform related resource request are also 
> implemented
> in the platform probe function.

Please fix minor check patch issues like:
CHECK: Please don't use multiple blank lines
#142: FILE: drivers/thermal/hisi_thermal.c:67:
 
 +

 CHECK: Please don't use multiple blank lines
 #218: FILE: drivers/thermal/hisi_thermal.c:297:
 +
 +

 CHECK: Alignment should match open parenthesis
 #335: FILE: drivers/thermal/hisi_thermal.c:424:
 +  ret = devm_request_threaded_irq(dev, data->irq, NULL,
 +  hisi_thermal_alarm_irq_thread,



> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 135 
> +++--
>  1 file changed, 89 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 8a70ab7..b5a7159 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "thermal_core.h"
>  
> @@ -30,7 +31,7 @@
>  #define HI6220_TEMP0_TH  (0x4)
>  #define HI6220_TEMP0_RST_TH  (0x8)
>  #define HI6220_TEMP0_CFG (0xC)
> -#define HI6220_TEMP0_CFG_SS_MSK  (0xF000)
> +#define HI6220_TEMP0_CFG_SS_MSK  (0xF000)
>  #define HI6220_TEMP0_CFG_HDAK_MSK(0x30)
>  #define HI6220_TEMP0_EN  (0x10)
>  #define HI6220_TEMP0_INT_EN  (0x14)
> @@ -41,7 +42,7 @@
>  #define HI6220_TEMP_BASE (-6)
>  #define HI6220_TEMP_RESET(10)
>  #define HI6220_TEMP_STEP (785)
> -#define HI6220_TEMP_LAG  (3500)
> +#define HI6220_TEMP_LAG  (3500)
>  
>  #define HI6220_DEFAULT_SENSOR2
>  
> @@ -52,6 +53,10 @@ struct hisi_thermal_sensor {
>  };
>  
>  struct hisi_thermal_data {
> + int (*get_temp)(struct hisi_thermal_data *data);
> + int (*enable_sensor)(struct hisi_thermal_data *data);
> + int (*disable_sensor)(struct hisi_thermal_data *data);
> + int (*irq_handler)(struct hisi_thermal_data *data);
>   struct platform_device *pdev;
>   struct clk *clk;
>   struct hisi_thermal_sensor sensor;
> @@ -59,6 +64,7 @@ struct hisi_thermal_data {
>   int irq;
>  };
>  
> +
>  /*
>   * The temperature computation on the tsensor is as follow:
>   *   Unit: millidegree Celsius
> @@ -192,7 +198,18 @@ static inline void hi6220_thermal_hdak_set(void __iomem 
> *addr, int value)
>  (value << 4), addr + HI6220_TEMP0_CFG);
>  }
>  
> -static void hi6220_thermal_disable_sensor(struct hisi_thermal_data *data)
> +static int hi6220_thermal_irq_handler(struct hisi_thermal_data *data)
> +{
> + hi6220_thermal_alarm_clear(data->regs, 1);
> + return 0;
> +}
> +
> +static int hi6220_thermal_get_temp(struct hisi_thermal_data *data)
> +{
> + return hi6220_thermal_get_temperature(data->regs);
> +}
> +
> +static int hi6220_thermal_disable_sensor(struct hisi_thermal_data *data)
>  {
>   /* disable sensor module */
>   hi6220_thermal_enable(data->regs, 0);
> @@ -200,9 +217,9 @@ static void hi6220_thermal_disable_sensor(struct 
> hisi_thermal_data *data)
>   hi6220_thermal_reset_enable(data->regs, 0);
>  
>   clk_disable_unprepare(data->clk);
> + return 0;
>  }
>  
> -
>  static int hi6220_thermal_enable_sensor(struct hisi_thermal_data *data)
>  {
>   struct hisi_thermal_sensor *sensor = >sensor;
> @@ -240,12 +257,50 @@ static int hi6220_thermal_enable_sensor(struct 
> hisi_thermal_data *data)
>  
>   return 0;
>  }
> +
> +static int hi6220_thermal_probe(struct hisi_thermal_data *data)
> +{
> + struct platform_device *pdev = data->pdev;
> + struct device *dev = >dev;
> + struct resource *res;
> + int ret;
> +
> + data->get_temp = hi6220_thermal_get_temp;
> + data->enable_sensor = hi6220_thermal_enable_sensor;
> + data->disable_sensor = hi6220_thermal_disable_sensor;
> + data->irq_handler = hi6220_thermal_irq_handler;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(data->regs)) {
> + dev_err(dev, "failed to get io address\n");
> + return PTR_ERR(data->regs);
> + }
> +
> + data->clk = devm_clk_get(dev, "thermal_clk");
> + if (IS_ERR(data->clk)) {
> + ret = PTR_ERR(data->clk);
> + if (ret != -EPROBE_DEFER)
> + 

Re: [PATCH 21/25] thermal/drivers/hisi: Prepare to add support for other hisi platforms

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:46PM +0200, Daniel Lezcano wrote:
> From: Kevin Wangtao 
> 
> For platform compatibility, add the tsensor ops to a thermal data structure.
> Each platform has its own probe function to register proper tsensor ops
> function to the pointer, platform related resource request are also 
> implemented
> in the platform probe function.

Please fix minor check patch issues like:
CHECK: Please don't use multiple blank lines
#142: FILE: drivers/thermal/hisi_thermal.c:67:
 
 +

 CHECK: Please don't use multiple blank lines
 #218: FILE: drivers/thermal/hisi_thermal.c:297:
 +
 +

 CHECK: Alignment should match open parenthesis
 #335: FILE: drivers/thermal/hisi_thermal.c:424:
 +  ret = devm_request_threaded_irq(dev, data->irq, NULL,
 +  hisi_thermal_alarm_irq_thread,



> 
> Signed-off-by: Kevin Wangtao 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 135 
> +++--
>  1 file changed, 89 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 8a70ab7..b5a7159 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "thermal_core.h"
>  
> @@ -30,7 +31,7 @@
>  #define HI6220_TEMP0_TH  (0x4)
>  #define HI6220_TEMP0_RST_TH  (0x8)
>  #define HI6220_TEMP0_CFG (0xC)
> -#define HI6220_TEMP0_CFG_SS_MSK  (0xF000)
> +#define HI6220_TEMP0_CFG_SS_MSK  (0xF000)
>  #define HI6220_TEMP0_CFG_HDAK_MSK(0x30)
>  #define HI6220_TEMP0_EN  (0x10)
>  #define HI6220_TEMP0_INT_EN  (0x14)
> @@ -41,7 +42,7 @@
>  #define HI6220_TEMP_BASE (-6)
>  #define HI6220_TEMP_RESET(10)
>  #define HI6220_TEMP_STEP (785)
> -#define HI6220_TEMP_LAG  (3500)
> +#define HI6220_TEMP_LAG  (3500)
>  
>  #define HI6220_DEFAULT_SENSOR2
>  
> @@ -52,6 +53,10 @@ struct hisi_thermal_sensor {
>  };
>  
>  struct hisi_thermal_data {
> + int (*get_temp)(struct hisi_thermal_data *data);
> + int (*enable_sensor)(struct hisi_thermal_data *data);
> + int (*disable_sensor)(struct hisi_thermal_data *data);
> + int (*irq_handler)(struct hisi_thermal_data *data);
>   struct platform_device *pdev;
>   struct clk *clk;
>   struct hisi_thermal_sensor sensor;
> @@ -59,6 +64,7 @@ struct hisi_thermal_data {
>   int irq;
>  };
>  
> +
>  /*
>   * The temperature computation on the tsensor is as follow:
>   *   Unit: millidegree Celsius
> @@ -192,7 +198,18 @@ static inline void hi6220_thermal_hdak_set(void __iomem 
> *addr, int value)
>  (value << 4), addr + HI6220_TEMP0_CFG);
>  }
>  
> -static void hi6220_thermal_disable_sensor(struct hisi_thermal_data *data)
> +static int hi6220_thermal_irq_handler(struct hisi_thermal_data *data)
> +{
> + hi6220_thermal_alarm_clear(data->regs, 1);
> + return 0;
> +}
> +
> +static int hi6220_thermal_get_temp(struct hisi_thermal_data *data)
> +{
> + return hi6220_thermal_get_temperature(data->regs);
> +}
> +
> +static int hi6220_thermal_disable_sensor(struct hisi_thermal_data *data)
>  {
>   /* disable sensor module */
>   hi6220_thermal_enable(data->regs, 0);
> @@ -200,9 +217,9 @@ static void hi6220_thermal_disable_sensor(struct 
> hisi_thermal_data *data)
>   hi6220_thermal_reset_enable(data->regs, 0);
>  
>   clk_disable_unprepare(data->clk);
> + return 0;
>  }
>  
> -
>  static int hi6220_thermal_enable_sensor(struct hisi_thermal_data *data)
>  {
>   struct hisi_thermal_sensor *sensor = >sensor;
> @@ -240,12 +257,50 @@ static int hi6220_thermal_enable_sensor(struct 
> hisi_thermal_data *data)
>  
>   return 0;
>  }
> +
> +static int hi6220_thermal_probe(struct hisi_thermal_data *data)
> +{
> + struct platform_device *pdev = data->pdev;
> + struct device *dev = >dev;
> + struct resource *res;
> + int ret;
> +
> + data->get_temp = hi6220_thermal_get_temp;
> + data->enable_sensor = hi6220_thermal_enable_sensor;
> + data->disable_sensor = hi6220_thermal_disable_sensor;
> + data->irq_handler = hi6220_thermal_irq_handler;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(data->regs)) {
> + dev_err(dev, "failed to get io address\n");
> + return PTR_ERR(data->regs);
> + }
> +
> + data->clk = devm_clk_get(dev, "thermal_clk");
> + if (IS_ERR(data->clk)) {
> + ret = PTR_ERR(data->clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "failed to get thermal clk: %d\n", ret);
> + return 

Re: [PATCH V1 2/2] pinctrl: qcom: spmi-gpio: Set is_enabled flag in set_mux()

[Fenglin Wu]

On 10/17/2017 6:29 AM, Bjorn Andersson wrote:

On Thu 12 Oct 23:15 PDT 2017, fengl...@codeaurora.org wrote:


From: Fenglin Wu 

The initial value of is_enabled flag is read out from hardware in
pmic_gpio_populate(), and it will be set in pmic_gpio_config_set() if
pinconf is defined. For any GPIOs disabled initially in hardware which
only have pinmux defined, they won't be enabled in pmic_gpio_set_mux()
calling. So set is_enabled flag in set_mux() to ensure the GPIO module
could be enabled in above case.



I'm still interested in knowing when it is valid to configure a pin with
only mux, no config.  I.e. in what cases does setting a alternative
function make the pinconfig not count.

I agreed that any pins should be configured with pinmux as well as
pinconf, but the driver doesn't prevent the case of only pinmux defined,
right? I am not sure if this is valid case but it would happen: The
hardware or the sw prior to linux kernel has the default setting of the
function and config for one GPIO but we need to keep it disabled until
the consumer request it, in this case, we just need to define the pinmux
and ignore the pinconf definition in its device node.



Regards,
Bjorn


Signed-off-by: Fenglin Wu 
---
  drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 0a1e173..219c934 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -312,6 +312,7 @@ static int pmic_gpio_set_mux(struct pinctrl_dev *pctldev, 
unsigned function,
}
  
  	pad = pctldev->desc->pins[pin].drv_data;

+   pad->is_enabled = true;
/*
 * Non-LV/MV subtypes only support 2 special functions,
 * offsetting the dtestx function values by 2
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.


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



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

Re: [PATCH V1 2/2] pinctrl: qcom: spmi-gpio: Set is_enabled flag in set_mux()

[Fenglin Wu]

On 10/17/2017 6:29 AM, Bjorn Andersson wrote:

On Thu 12 Oct 23:15 PDT 2017, fengl...@codeaurora.org wrote:


From: Fenglin Wu 

The initial value of is_enabled flag is read out from hardware in
pmic_gpio_populate(), and it will be set in pmic_gpio_config_set() if
pinconf is defined. For any GPIOs disabled initially in hardware which
only have pinmux defined, they won't be enabled in pmic_gpio_set_mux()
calling. So set is_enabled flag in set_mux() to ensure the GPIO module
could be enabled in above case.



I'm still interested in knowing when it is valid to configure a pin with
only mux, no config.  I.e. in what cases does setting a alternative
function make the pinconfig not count.

I agreed that any pins should be configured with pinmux as well as
pinconf, but the driver doesn't prevent the case of only pinmux defined,
right? I am not sure if this is valid case but it would happen: The
hardware or the sw prior to linux kernel has the default setting of the
function and config for one GPIO but we need to keep it disabled until
the consumer request it, in this case, we just need to define the pinmux
and ignore the pinconf definition in its device node.



Regards,
Bjorn


Signed-off-by: Fenglin Wu 
---
  drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 0a1e173..219c934 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -312,6 +312,7 @@ static int pmic_gpio_set_mux(struct pinctrl_dev *pctldev, 
unsigned function,
}
  
  	pad = pctldev->desc->pins[pin].drv_data;

+   pad->is_enabled = true;
/*
 * Non-LV/MV subtypes only support 2 special functions,
 * offsetting the dtestx function values by 2
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.


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



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

Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully

[John Fastabend]

On 10/15/2017 03:13 PM, Richard Weinberger wrote:
> Am Montag, 16. Oktober 2017, 00:00:20 CEST schrieb Richard Weinberger:
>> max_entries is user controlled and used as input for __alloc_percpu().
>> This function expects that the allocation size is a power of two and
>> less than PCPU_MIN_UNIT_SIZE.
>> Otherwise a WARN() is triggered.
> 
> On a second though, I think we should also have a hard limit for 
> ->max_entries 
> or check for an overflow here:
> 

Or just,

static u64 dev_map_bitmap_size(const union bpf_attr *attr)
{
return BITS_TO_LONGS((u64) attr->max_entries) *
sizeof(unsigned long);
}

Let me know if you want me to send a patch or if you want to.

Thanks,
John

> static u64 dev_map_bitmap_size(const union bpf_attr *attr)
> {
> return BITS_TO_LONGS(attr->max_entries) * sizeof(unsigned long);
> }
> 
> Thanks,
> //richard
> 

Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully

[John Fastabend]

On 10/15/2017 03:13 PM, Richard Weinberger wrote:
> Am Montag, 16. Oktober 2017, 00:00:20 CEST schrieb Richard Weinberger:
>> max_entries is user controlled and used as input for __alloc_percpu().
>> This function expects that the allocation size is a power of two and
>> less than PCPU_MIN_UNIT_SIZE.
>> Otherwise a WARN() is triggered.
> 
> On a second though, I think we should also have a hard limit for 
> ->max_entries 
> or check for an overflow here:
> 

Or just,

static u64 dev_map_bitmap_size(const union bpf_attr *attr)
{
return BITS_TO_LONGS((u64) attr->max_entries) *
sizeof(unsigned long);
}

Let me know if you want me to send a patch or if you want to.

Thanks,
John

> static u64 dev_map_bitmap_size(const union bpf_attr *attr)
> {
> return BITS_TO_LONGS(attr->max_entries) * sizeof(unsigned long);
> }
> 
> Thanks,
> //richard
> 

Re: [PATCH 0/7] drm/sun4i: More cleanups

[Chen-Yu Tsai]

On Tue, Oct 17, 2017 at 12:23 PM, Chen-Yu Tsai  wrote:
> Hi,
>
> Here's another bunch of cleanups for sun4i-drm. Most of these were
> found while working on A10/A20 DRM and HDMI support. To be clear,
> nothing was broken before these patches.
>
> Changes since v1:
>
>   - Expanded commit message for patch 5 explaining the details of
> memory address difference, wrap-around, and why only a few
> devices were affected.

Sorry. The subject should have said "v2".

ChenYu

Re: [PATCH 0/7] drm/sun4i: More cleanups

[Chen-Yu Tsai]

On Tue, Oct 17, 2017 at 12:23 PM, Chen-Yu Tsai  wrote:
> Hi,
>
> Here's another bunch of cleanups for sun4i-drm. Most of these were
> found while working on A10/A20 DRM and HDMI support. To be clear,
> nothing was broken before these patches.
>
> Changes since v1:
>
>   - Expanded commit message for patch 5 explaining the details of
> memory address difference, wrap-around, and why only a few
> devices were affected.

Sorry. The subject should have said "v2".

ChenYu

[PATCH v2 3/7] drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory

[Chen-Yu Tsai]

Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.

This patch uses this helper to replace our own open coded version of the
same function.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 1cc1780f5091..243ddfdc9403 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -209,22 +209,11 @@ int sun4i_backend_update_layer_buffer(struct 
sun4i_backend *backend,
 {
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
-   struct drm_gem_cma_object *gem;
u32 lo_paddr, hi_paddr;
dma_addr_t paddr;
-   int bpp;
-
-   /* Get the physical address of the buffer in memory */
-   gem = drm_fb_cma_get_gem_obj(fb, 0);
-
-   DRM_DEBUG_DRIVER("Using GEM @ %pad\n", >paddr);
-
-   /* Compute the start of the displayed memory */
-   bpp = fb->format->cpp[0];
-   paddr = gem->paddr + fb->offsets[0];
-   paddr += (state->src_x >> 16) * bpp;
-   paddr += (state->src_y >> 16) * fb->pitches[0];
 
+   /* Get the start of the displayed memory */
+   paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", );
 
/* Write the 32 lower bits of the address (in bits) */
-- 
2.14.2

[PATCH v2 3/7] drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory

[Chen-Yu Tsai]

Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.

This patch uses this helper to replace our own open coded version of the
same function.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 1cc1780f5091..243ddfdc9403 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -209,22 +209,11 @@ int sun4i_backend_update_layer_buffer(struct 
sun4i_backend *backend,
 {
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
-   struct drm_gem_cma_object *gem;
u32 lo_paddr, hi_paddr;
dma_addr_t paddr;
-   int bpp;
-
-   /* Get the physical address of the buffer in memory */
-   gem = drm_fb_cma_get_gem_obj(fb, 0);
-
-   DRM_DEBUG_DRIVER("Using GEM @ %pad\n", >paddr);
-
-   /* Compute the start of the displayed memory */
-   bpp = fb->format->cpp[0];
-   paddr = gem->paddr + fb->offsets[0];
-   paddr += (state->src_x >> 16) * bpp;
-   paddr += (state->src_y >> 16) * fb->pitches[0];
 
+   /* Get the start of the displayed memory */
+   paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", );
 
/* Write the 32 lower bits of the address (in bits) */
-- 
2.14.2

[PATCH v2 6/7] drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits

[Chen-Yu Tsai]

While debugging inverted color from the HDMI output on the A10, I
found that the lowest 3 bits were set. These were cleared on A20
boards that had normal display output. By manually toggling these
bits the mapping of the color components to these bits was found.

While these are not used anywhere, it would be nice to document
them somewhere.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 9b97da39927e..b685ee11623d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -72,6 +72,11 @@
 #define SUN4I_HDMI_PAD_CTRL1_HALVE_CLK BIT(6)
 #define SUN4I_HDMI_PAD_CTRL1_REG_AMP(n)(((n) & 7) << 3)
 
+/* These bits seem to invert the TMDS data channels */
+#define SUN4I_HDMI_PAD_CTRL1_INVERT_R  BIT(2)
+#define SUN4I_HDMI_PAD_CTRL1_INVERT_G  BIT(1)
+#define SUN4I_HDMI_PAD_CTRL1_INVERT_B  BIT(0)
+
 #define SUN4I_HDMI_PLL_CTRL_REG0x208
 #define SUN4I_HDMI_PLL_CTRL_PLL_EN BIT(31)
 #define SUN4I_HDMI_PLL_CTRL_BWSBIT(30)
-- 
2.14.2

[PATCH v2 4/7] drm/sun4i: backend: Add comment explaining why registers are cleared

[Chen-Yu Tsai]

Many of the backend's layer configuration registers have undefined
default values. This poses a risk as we use regmap_update_bits in
some places, and don't overwrite the whole register.

At probe/bind time we explicitly clear all the control registers
by writing 0 to them. This patch adds a more detailed explanation
on why we're doing this.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 243ddfdc9403..4fefd8add714 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -412,7 +412,14 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
 
list_add_tail(>engine.list, >engine_list);
 
-   /* Reset the registers */
+   /*
+* Many of the backend's layer configuration registers have
+* undefined default values. This poses a risk as we use
+* regmap_update_bits in some places, and don't overwrite
+* the whole register.
+*
+* Clear the registers here to have something predictable.
+*/
for (i = 0x800; i < 0x1000; i += 4)
regmap_write(backend->engine.regs, i, 0);
 
-- 
2.14.2

[PATCH v2 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address

[Chen-Yu Tsai]

The display backend, as well as other peripherals that have a DRAM
clock gate and access DRAM directly, bypassing the system bus,
address the DRAM starting from 0x0, while physical addresses the
system uses starts from 0x4000 (or 0x2000 in A80's case).

This issue was witnessed on the Cubietruck, which has 2GB of RAM.

Devices with less RAM function normally due to the DRAM address
wrapping around. CMA seems to always allocate its buffer at a
very high address, close to the end of DRAM.

On a 1GB RAM device, the physical address would be something like
0x7800. The DRAM address 0x7800 would access the same DRAM
region as 0x3800 on a system, as the DRAM address would only
span 0x0 ~ 0x3fff. The bit 0x4000 is non-functional in this
case.

However on the Cubietruck, the DRAM is 2GB. The physical address
is 0x4000 ~ 0xbfff. The buffer would be something like
0xb800. But the DRAM address span 0x0 ~ 0x7fff, meaning
the buffer address wraps around to 0x3800, which is wrong.
The correct DRAM address for it should be 0x7800.

Correct the address configured into the backend layer registers
by PHYS_OFFSET to account for this.

Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 4fefd8add714..d18d7e88d511 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -216,6 +216,13 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", );
 
+   /*
+* backend DMA accesses DRAM directly, bypassing the system
+* bus. As such, the address range is different and the buffer
+* address needs to be corrected.
+*/
+   paddr -= PHYS_OFFSET;
+
/* Write the 32 lower bits of the address (in bits) */
lo_paddr = paddr << 3;
DRM_DEBUG_DRIVER("Setting address lower bits to 0x%x\n", lo_paddr);
-- 
2.14.2

[PATCH v2 6/7] drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits

[Chen-Yu Tsai]

While debugging inverted color from the HDMI output on the A10, I
found that the lowest 3 bits were set. These were cleared on A20
boards that had normal display output. By manually toggling these
bits the mapping of the color components to these bits was found.

While these are not used anywhere, it would be nice to document
them somewhere.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 9b97da39927e..b685ee11623d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -72,6 +72,11 @@
 #define SUN4I_HDMI_PAD_CTRL1_HALVE_CLK BIT(6)
 #define SUN4I_HDMI_PAD_CTRL1_REG_AMP(n)(((n) & 7) << 3)
 
+/* These bits seem to invert the TMDS data channels */
+#define SUN4I_HDMI_PAD_CTRL1_INVERT_R  BIT(2)
+#define SUN4I_HDMI_PAD_CTRL1_INVERT_G  BIT(1)
+#define SUN4I_HDMI_PAD_CTRL1_INVERT_B  BIT(0)
+
 #define SUN4I_HDMI_PLL_CTRL_REG0x208
 #define SUN4I_HDMI_PLL_CTRL_PLL_EN BIT(31)
 #define SUN4I_HDMI_PLL_CTRL_BWSBIT(30)
-- 
2.14.2

[PATCH v2 4/7] drm/sun4i: backend: Add comment explaining why registers are cleared

[Chen-Yu Tsai]

Many of the backend's layer configuration registers have undefined
default values. This poses a risk as we use regmap_update_bits in
some places, and don't overwrite the whole register.

At probe/bind time we explicitly clear all the control registers
by writing 0 to them. This patch adds a more detailed explanation
on why we're doing this.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 243ddfdc9403..4fefd8add714 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -412,7 +412,14 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
 
list_add_tail(>engine.list, >engine_list);
 
-   /* Reset the registers */
+   /*
+* Many of the backend's layer configuration registers have
+* undefined default values. This poses a risk as we use
+* regmap_update_bits in some places, and don't overwrite
+* the whole register.
+*
+* Clear the registers here to have something predictable.
+*/
for (i = 0x800; i < 0x1000; i += 4)
regmap_write(backend->engine.regs, i, 0);
 
-- 
2.14.2

[PATCH v2 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address

[Chen-Yu Tsai]

The display backend, as well as other peripherals that have a DRAM
clock gate and access DRAM directly, bypassing the system bus,
address the DRAM starting from 0x0, while physical addresses the
system uses starts from 0x4000 (or 0x2000 in A80's case).

This issue was witnessed on the Cubietruck, which has 2GB of RAM.

Devices with less RAM function normally due to the DRAM address
wrapping around. CMA seems to always allocate its buffer at a
very high address, close to the end of DRAM.

On a 1GB RAM device, the physical address would be something like
0x7800. The DRAM address 0x7800 would access the same DRAM
region as 0x3800 on a system, as the DRAM address would only
span 0x0 ~ 0x3fff. The bit 0x4000 is non-functional in this
case.

However on the Cubietruck, the DRAM is 2GB. The physical address
is 0x4000 ~ 0xbfff. The buffer would be something like
0xb800. But the DRAM address span 0x0 ~ 0x7fff, meaning
the buffer address wraps around to 0x3800, which is wrong.
The correct DRAM address for it should be 0x7800.

Correct the address configured into the backend layer registers
by PHYS_OFFSET to account for this.

Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 4fefd8add714..d18d7e88d511 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -216,6 +216,13 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", );
 
+   /*
+* backend DMA accesses DRAM directly, bypassing the system
+* bus. As such, the address range is different and the buffer
+* address needs to be corrected.
+*/
+   paddr -= PHYS_OFFSET;
+
/* Write the 32 lower bits of the address (in bits) */
lo_paddr = paddr << 3;
DRM_DEBUG_DRIVER("Setting address lower bits to 0x%x\n", lo_paddr);
-- 
2.14.2

[PATCH 0/7] drm/sun4i: More cleanups

[Chen-Yu Tsai]

Hi,

Here's another bunch of cleanups for sun4i-drm. Most of these were
found while working on A10/A20 DRM and HDMI support. To be clear,
nothing was broken before these patches.

Changes since v1:

  - Expanded commit message for patch 5 explaining the details of
memory address difference, wrap-around, and why only a few
devices were affected.

Patch 1 trims the sun4i-drm probe sequence by not adding repeating
components. The component can deal with duplicates, but it leads
to excessive debug logs which is confusing for developers not in
the know.

Patch 2 moves regmap creation to a point where access is actually
possible, i.e. clocks enabled and reset controls deasserted.

Patch 3 moves to the new drm_fb_cma_get_gem_addr() helper instead
of open coding the same thing.

Patch 4 expands the comment explaining why we clear the backend
registers explicitly.

Patch 5 fixes the buffer address programmed into the backend layer
registers. This issue only hits devices with more than 1GB RAM.

Patch 6 documents some newly discovered but unused register bits
in the HDMI controller.

Patch 7 delays setting of the PAD_CTRL1 register in the HDMI controller
to the mode_set function. The main reason to do this is that between
probe time and when the display is actually setup, the controller itself
toggles some of the bits in this register. In particular, on the A10
it toggles the invert bits documented in the previous patch. This
causes the color to be completed inverted.

Please have a look.

Regards
ChenYu

Chen-Yu Tsai (7):
  drm/sun4i: don't add components that are already in the queue
  drm/sun4i: backend: Create regmap after access is possible
  drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display
memory
  drm/sun4i: backend: Add comment explaining why registers are cleared
  drm/sun4i: backend: Offset layer buffer address by DRAM starting
address
  drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits
  drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

 drivers/gpu/drm/sun4i/sun4i_backend.c  | 45 ++
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 16 
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  5 
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 26 
 4 files changed, 61 insertions(+), 31 deletions(-)

-- 
2.14.2

[PATCH v2 7/7] drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

[Chen-Yu Tsai]

Initially we configured the PAD_CTRL1 register at probe/bind time.
However it seems the HDMI controller will modify some of the bits
in this register by itself. On the A10 it is particularly annoying
as it toggles the output invert bits, which inverts the colors on
the display output.

The U-boot driver this driver is based on sets this register twice,
though it seems it's only needed for actual display output. Hence
we move it to the mode_set function.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 027b5608dbe6..6ca6e6a74c4a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -144,6 +144,22 @@ static void sun4i_hdmi_mode_set(struct drm_encoder 
*encoder,
writel(SUN4I_HDMI_UNKNOWN_INPUT_SYNC,
   hdmi->base + SUN4I_HDMI_UNKNOWN_REG);
 
+   /*
+* Setup output pad (?) controls
+*
+* This is done here instead of at probe/bind time because
+* the controller seems to toggle some of the bits on its own.
+*
+* We can't just initialize the register there, we need to
+* protect the clock bits that have already been read out and
+* cached by the clock framework.
+*/
+   val = readl(hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
+   val &= SUN4I_HDMI_PAD_CTRL1_HALVE_CLK;
+   val |= hdmi->variant->pad_ctrl1_init_val;
+   writel(val, hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
+   val = readl(hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
+
/* Setup timing registers */
writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
   SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
@@ -489,16 +505,6 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
writel(hdmi->variant->pad_ctrl0_init_val,
   hdmi->base + SUN4I_HDMI_PAD_CTRL0_REG);
 
-   /*
-* We can't just initialize the register there, we need to
-* protect the clock bits that have already been read out and
-* cached by the clock framework.
-*/
-   reg = readl(hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
-   reg &= SUN4I_HDMI_PAD_CTRL1_HALVE_CLK;
-   reg |= hdmi->variant->pad_ctrl1_init_val;
-   writel(reg, hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
-
reg = readl(hdmi->base + SUN4I_HDMI_PLL_CTRL_REG);
reg &= SUN4I_HDMI_PLL_CTRL_DIV_MASK;
reg |= hdmi->variant->pll_ctrl_init_val;
-- 
2.14.2

[PATCH 0/7] drm/sun4i: More cleanups

[Chen-Yu Tsai]

Hi,

Here's another bunch of cleanups for sun4i-drm. Most of these were
found while working on A10/A20 DRM and HDMI support. To be clear,
nothing was broken before these patches.

Changes since v1:

  - Expanded commit message for patch 5 explaining the details of
memory address difference, wrap-around, and why only a few
devices were affected.

Patch 1 trims the sun4i-drm probe sequence by not adding repeating
components. The component can deal with duplicates, but it leads
to excessive debug logs which is confusing for developers not in
the know.

Patch 2 moves regmap creation to a point where access is actually
possible, i.e. clocks enabled and reset controls deasserted.

Patch 3 moves to the new drm_fb_cma_get_gem_addr() helper instead
of open coding the same thing.

Patch 4 expands the comment explaining why we clear the backend
registers explicitly.

Patch 5 fixes the buffer address programmed into the backend layer
registers. This issue only hits devices with more than 1GB RAM.

Patch 6 documents some newly discovered but unused register bits
in the HDMI controller.

Patch 7 delays setting of the PAD_CTRL1 register in the HDMI controller
to the mode_set function. The main reason to do this is that between
probe time and when the display is actually setup, the controller itself
toggles some of the bits in this register. In particular, on the A10
it toggles the invert bits documented in the previous patch. This
causes the color to be completed inverted.

Please have a look.

Regards
ChenYu

Chen-Yu Tsai (7):
  drm/sun4i: don't add components that are already in the queue
  drm/sun4i: backend: Create regmap after access is possible
  drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display
memory
  drm/sun4i: backend: Add comment explaining why registers are cleared
  drm/sun4i: backend: Offset layer buffer address by DRAM starting
address
  drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits
  drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

 drivers/gpu/drm/sun4i/sun4i_backend.c  | 45 ++
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 16 
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  5 
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 26 
 4 files changed, 61 insertions(+), 31 deletions(-)

-- 
2.14.2

[PATCH v2 7/7] drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

[Chen-Yu Tsai]

Initially we configured the PAD_CTRL1 register at probe/bind time.
However it seems the HDMI controller will modify some of the bits
in this register by itself. On the A10 it is particularly annoying
as it toggles the output invert bits, which inverts the colors on
the display output.

The U-boot driver this driver is based on sets this register twice,
though it seems it's only needed for actual display output. Hence
we move it to the mode_set function.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 027b5608dbe6..6ca6e6a74c4a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -144,6 +144,22 @@ static void sun4i_hdmi_mode_set(struct drm_encoder 
*encoder,
writel(SUN4I_HDMI_UNKNOWN_INPUT_SYNC,
   hdmi->base + SUN4I_HDMI_UNKNOWN_REG);
 
+   /*
+* Setup output pad (?) controls
+*
+* This is done here instead of at probe/bind time because
+* the controller seems to toggle some of the bits on its own.
+*
+* We can't just initialize the register there, we need to
+* protect the clock bits that have already been read out and
+* cached by the clock framework.
+*/
+   val = readl(hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
+   val &= SUN4I_HDMI_PAD_CTRL1_HALVE_CLK;
+   val |= hdmi->variant->pad_ctrl1_init_val;
+   writel(val, hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
+   val = readl(hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
+
/* Setup timing registers */
writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
   SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
@@ -489,16 +505,6 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
writel(hdmi->variant->pad_ctrl0_init_val,
   hdmi->base + SUN4I_HDMI_PAD_CTRL0_REG);
 
-   /*
-* We can't just initialize the register there, we need to
-* protect the clock bits that have already been read out and
-* cached by the clock framework.
-*/
-   reg = readl(hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
-   reg &= SUN4I_HDMI_PAD_CTRL1_HALVE_CLK;
-   reg |= hdmi->variant->pad_ctrl1_init_val;
-   writel(reg, hdmi->base + SUN4I_HDMI_PAD_CTRL1_REG);
-
reg = readl(hdmi->base + SUN4I_HDMI_PLL_CTRL_REG);
reg &= SUN4I_HDMI_PLL_CTRL_DIV_MASK;
reg |= hdmi->variant->pll_ctrl_init_val;
-- 
2.14.2

[PATCH v2 1/7] drm/sun4i: don't add components that are already in the queue

[Chen-Yu Tsai]

Even though the components framework can handle duplicate entries,
the extra entries cause a lot more debug messages to be generated,
which would be confusing to developers not familiar with our driver
and the framework in general.

Instead, we can scan the relatively small queue and check if the
component to be added is already queued up. Since the display
pipelines are symmetrical (not considering the third display
pipeline on the A80), and we add components level by level, when
we get to the second instance at the same level, any shared downstream
components would already be in the queue.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a2012638d5f7..b5879d4620d8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -226,6 +226,18 @@ struct endpoint_list {
struct list_head list;
 };
 
+static bool node_is_in_list(struct list_head *endpoints,
+   struct device_node *node)
+{
+   struct endpoint_list *endpoint;
+
+   list_for_each_entry(endpoint, endpoints, list)
+   if (endpoint->node == node)
+   return true;
+
+   return false;
+}
+
 static int sun4i_drv_add_endpoints(struct device *dev,
   struct list_head *endpoints,
   struct component_match **match,
@@ -292,6 +304,10 @@ static int sun4i_drv_add_endpoints(struct device *dev,
}
}
 
+   /* skip downstream node if it is already in the queue */
+   if (node_is_in_list(endpoints, remote))
+   continue;
+
/* Add downstream nodes to the queue */
endpoint = kzalloc(sizeof(*endpoint), GFP_KERNEL);
if (!endpoint) {
-- 
2.14.2

[PATCH v2 1/7] drm/sun4i: don't add components that are already in the queue

[Chen-Yu Tsai]

Even though the components framework can handle duplicate entries,
the extra entries cause a lot more debug messages to be generated,
which would be confusing to developers not familiar with our driver
and the framework in general.

Instead, we can scan the relatively small queue and check if the
component to be added is already queued up. Since the display
pipelines are symmetrical (not considering the third display
pipeline on the A80), and we add components level by level, when
we get to the second instance at the same level, any shared downstream
components would already be in the queue.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a2012638d5f7..b5879d4620d8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -226,6 +226,18 @@ struct endpoint_list {
struct list_head list;
 };
 
+static bool node_is_in_list(struct list_head *endpoints,
+   struct device_node *node)
+{
+   struct endpoint_list *endpoint;
+
+   list_for_each_entry(endpoint, endpoints, list)
+   if (endpoint->node == node)
+   return true;
+
+   return false;
+}
+
 static int sun4i_drv_add_endpoints(struct device *dev,
   struct list_head *endpoints,
   struct component_match **match,
@@ -292,6 +304,10 @@ static int sun4i_drv_add_endpoints(struct device *dev,
}
}
 
+   /* skip downstream node if it is already in the queue */
+   if (node_is_in_list(endpoints, remote))
+   continue;
+
/* Add downstream nodes to the queue */
endpoint = kzalloc(sizeof(*endpoint), GFP_KERNEL);
if (!endpoint) {
-- 
2.14.2

[PATCH v2 2/7] drm/sun4i: backend: Create regmap after access is possible

[Chen-Yu Tsai]

The backend has various clocks and reset controls that need to be
enabled and deasserted before register access is possible.

Move the creation of the regmap to after the clocks and reset controls
have been configured where it makes more sense.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ec5943627aa5..1cc1780f5091 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -369,13 +369,6 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
if (IS_ERR(regs))
return PTR_ERR(regs);
 
-   backend->engine.regs = devm_regmap_init_mmio(dev, regs,
-
_backend_regmap_config);
-   if (IS_ERR(backend->engine.regs)) {
-   dev_err(dev, "Couldn't create the backend regmap\n");
-   return PTR_ERR(backend->engine.regs);
-   }
-
backend->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(backend->reset)) {
dev_err(dev, "Couldn't get our reset line\n");
@@ -421,6 +414,13 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
}
}
 
+   backend->engine.regs = devm_regmap_init_mmio(dev, regs,
+
_backend_regmap_config);
+   if (IS_ERR(backend->engine.regs)) {
+   dev_err(dev, "Couldn't create the backend regmap\n");
+   return PTR_ERR(backend->engine.regs);
+   }
+
list_add_tail(>engine.list, >engine_list);
 
/* Reset the registers */
-- 
2.14.2

[PATCH v2 2/7] drm/sun4i: backend: Create regmap after access is possible

[Chen-Yu Tsai]

The backend has various clocks and reset controls that need to be
enabled and deasserted before register access is possible.

Move the creation of the regmap to after the clocks and reset controls
have been configured where it makes more sense.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ec5943627aa5..1cc1780f5091 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -369,13 +369,6 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
if (IS_ERR(regs))
return PTR_ERR(regs);
 
-   backend->engine.regs = devm_regmap_init_mmio(dev, regs,
-
_backend_regmap_config);
-   if (IS_ERR(backend->engine.regs)) {
-   dev_err(dev, "Couldn't create the backend regmap\n");
-   return PTR_ERR(backend->engine.regs);
-   }
-
backend->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(backend->reset)) {
dev_err(dev, "Couldn't get our reset line\n");
@@ -421,6 +414,13 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
}
}
 
+   backend->engine.regs = devm_regmap_init_mmio(dev, regs,
+
_backend_regmap_config);
+   if (IS_ERR(backend->engine.regs)) {
+   dev_err(dev, "Couldn't create the backend regmap\n");
+   return PTR_ERR(backend->engine.regs);
+   }
+
list_add_tail(>engine.list, >engine_list);
 
/* Reset the registers */
-- 
2.14.2

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

[Bin Liu]

On Mon, Oct 16, 2017 at 11:54:27PM +1100, Jonathan Liu wrote:
> On 16 October 2017 at 23:49, Bin Liu  wrote:
> > On Mon, Oct 16, 2017 at 04:13:51PM +1100, Jonathan Liu wrote:
> >> On 10 October 2017 at 14:22, Bin Liu  wrote:
> >> > On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote:
> >> >> This fixes a kernel oops when unloading the driver due to usb_put_phy
> >> >> being called after usb_phy_generic_unregister when the device is
> >> >> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
> >> >> be NULL in usb_put_phy and results in a NULL pointer dereference.
> >> >>
> >> >> Cc: sta...@vger.kernel.org # v4.3+
> >> >> Signed-off-by: Jonathan Liu 
> >> >> ---
> >> >> Changes for v2:
> >> >>  - Use devm_usb_put_phy instead of usb_put_phy
> >> >>
> >> >>  drivers/usb/musb/sunxi.c | 2 ++
> >> >>  1 file changed, 2 insertions(+)
> >> >>
> >> >> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> >> >> index c9a09b5bb6e5..dc353e24d53c 100644
> >> >> --- a/drivers/usb/musb/sunxi.c
> >> >> +++ b/drivers/usb/musb/sunxi.c
> >> >> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
> >> >>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
> >> >>   sunxi_sram_release(musb->controller->parent);
> >> >>
> >> >> + devm_usb_put_phy(glue->dev, glue->xceiv);
> >> >> +
> >> >>   return 0;
> >> >>  }
> >> >
> >> >
> >>
> >> > Applied. Thanks.
> >> > -Bin.
> >>
> >> Which repository was it applied to?
> >
> > I don't have a public repo (yet), but the patch has been sent to Greg,
> > so it should be merged into the next -rc.
> >
> > Regards,
> > -Bin.
> 
> The MAINTAINERS file has
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git listed as
> the tree for drivers/usb/musb/. I guess that should be updated.

I will create a patch for it. Thanks for reporting this.

Regards,
-Bin.

Re: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

[Bin Liu]

On Mon, Oct 16, 2017 at 11:54:27PM +1100, Jonathan Liu wrote:
> On 16 October 2017 at 23:49, Bin Liu  wrote:
> > On Mon, Oct 16, 2017 at 04:13:51PM +1100, Jonathan Liu wrote:
> >> On 10 October 2017 at 14:22, Bin Liu  wrote:
> >> > On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote:
> >> >> This fixes a kernel oops when unloading the driver due to usb_put_phy
> >> >> being called after usb_phy_generic_unregister when the device is
> >> >> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
> >> >> be NULL in usb_put_phy and results in a NULL pointer dereference.
> >> >>
> >> >> Cc: sta...@vger.kernel.org # v4.3+
> >> >> Signed-off-by: Jonathan Liu 
> >> >> ---
> >> >> Changes for v2:
> >> >>  - Use devm_usb_put_phy instead of usb_put_phy
> >> >>
> >> >>  drivers/usb/musb/sunxi.c | 2 ++
> >> >>  1 file changed, 2 insertions(+)
> >> >>
> >> >> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> >> >> index c9a09b5bb6e5..dc353e24d53c 100644
> >> >> --- a/drivers/usb/musb/sunxi.c
> >> >> +++ b/drivers/usb/musb/sunxi.c
> >> >> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
> >> >>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
> >> >>   sunxi_sram_release(musb->controller->parent);
> >> >>
> >> >> + devm_usb_put_phy(glue->dev, glue->xceiv);
> >> >> +
> >> >>   return 0;
> >> >>  }
> >> >
> >> >
> >>
> >> > Applied. Thanks.
> >> > -Bin.
> >>
> >> Which repository was it applied to?
> >
> > I don't have a public repo (yet), but the patch has been sent to Greg,
> > so it should be merged into the next -rc.
> >
> > Regards,
> > -Bin.
> 
> The MAINTAINERS file has
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git listed as
> the tree for drivers/usb/musb/. I guess that should be updated.

I will create a patch for it. Thanks for reporting this.

Regards,
-Bin.

Re: [PATCH 08/25] thermal/drivers/hisi: Fix configuration register setting

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:33PM +0200, Daniel Lezcano wrote:
> The TEMP0_CFG configuration register contains different field to set up the
> temperature controller. However in the code, nothing prevents a setup to
> overwrite the previous one: eg. writing the hdak value overwrites the sensor
> selection, the sensor selection overwrites the hdak value.
> 
> In order to prevent such thing, use a regmap-like mechanism by reading the
> value before, set the corresponding bits and write the result.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 8e8a117..5688556 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -30,6 +30,8 @@
>  #define TEMP0_TH (0x4)
>  #define TEMP0_RST_TH (0x8)
>  #define TEMP0_CFG(0xC)
> +#define TEMP0_CFG_SS_MSK (0xF000)
> +#define TEMP0_CFG_HDAK_MSK   (0x30)
>  #define TEMP0_EN (0x10)
>  #define TEMP0_INT_EN (0x14)
>  #define TEMP0_INT_CLR(0x18)
> @@ -132,19 +134,41 @@ static inline void hisi_thermal_enable(void __iomem 
> *addr, int value)
>   writel(value, addr + TEMP0_EN);
>  }
>  
> -static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
>  {
> - writel((sensor << 12), addr + TEMP0_CFG);
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
>  }
>  
> -static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +/*
> + * Temperature configuration register - Sensor selection
> + *
> + * Bits [19:12]
> + *
> + * 0x0: local sensor (default)
> + * 0x1: remote sensor 1 (ACPU cluster 1)
> + * 0x2: remote sensor 2 (ACPU cluster 0)
> + * 0x3: remote sensor 3 (G3D)
> + */
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
>  {
> - return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> + writel((readl(addr + TEMP0_CFG) & ~TEMP0_CFG_SS_MSK ) |


ERROR: space prohibited before that close parenthesis ')'
#135: FILE: drivers/thermal/hisi_thermal.c:154:
+   writel((readl(addr + TEMP0_CFG) & ~TEMP0_CFG_SS_MSK ) |



> +(sensor << 12), addr + TEMP0_CFG);
>  }
>  
> +/*
> + * Temperature configuration register - Hdak conversion polling interval
> + *
> + * Bits [5:4]
> + *
> + * 0x0 :   0.768 ms
> + * 0x1 :   6.144 ms
> + * 0x2 :  49.152 ms
> + * 0x3 : 393.216 ms
> + */
>  static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_CFG);
> + writel((readl(addr + TEMP0_CFG) & ~TEMP0_CFG_HDAK_MSK) |
> +(value << 4), addr + TEMP0_CFG);
>  }
>  
>  static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> -- 
> 2.7.4
> 

Re: [PATCH 08/25] thermal/drivers/hisi: Fix configuration register setting

[Eduardo Valentin]

On Tue, Oct 10, 2017 at 08:02:33PM +0200, Daniel Lezcano wrote:
> The TEMP0_CFG configuration register contains different field to set up the
> temperature controller. However in the code, nothing prevents a setup to
> overwrite the previous one: eg. writing the hdak value overwrites the sensor
> selection, the sensor selection overwrites the hdak value.
> 
> In order to prevent such thing, use a regmap-like mechanism by reading the
> value before, set the corresponding bits and write the result.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/hisi_thermal.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index 8e8a117..5688556 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -30,6 +30,8 @@
>  #define TEMP0_TH (0x4)
>  #define TEMP0_RST_TH (0x8)
>  #define TEMP0_CFG(0xC)
> +#define TEMP0_CFG_SS_MSK (0xF000)
> +#define TEMP0_CFG_HDAK_MSK   (0x30)
>  #define TEMP0_EN (0x10)
>  #define TEMP0_INT_EN (0x14)
>  #define TEMP0_INT_CLR(0x18)
> @@ -132,19 +134,41 @@ static inline void hisi_thermal_enable(void __iomem 
> *addr, int value)
>   writel(value, addr + TEMP0_EN);
>  }
>  
> -static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
> +static inline int hisi_thermal_get_temperature(void __iomem *addr)
>  {
> - writel((sensor << 12), addr + TEMP0_CFG);
> + return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
>  }
>  
> -static inline int hisi_thermal_get_temperature(void __iomem *addr)
> +/*
> + * Temperature configuration register - Sensor selection
> + *
> + * Bits [19:12]
> + *
> + * 0x0: local sensor (default)
> + * 0x1: remote sensor 1 (ACPU cluster 1)
> + * 0x2: remote sensor 2 (ACPU cluster 0)
> + * 0x3: remote sensor 3 (G3D)
> + */
> +static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
>  {
> - return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
> + writel((readl(addr + TEMP0_CFG) & ~TEMP0_CFG_SS_MSK ) |


ERROR: space prohibited before that close parenthesis ')'
#135: FILE: drivers/thermal/hisi_thermal.c:154:
+   writel((readl(addr + TEMP0_CFG) & ~TEMP0_CFG_SS_MSK ) |



> +(sensor << 12), addr + TEMP0_CFG);
>  }
>  
> +/*
> + * Temperature configuration register - Hdak conversion polling interval
> + *
> + * Bits [5:4]
> + *
> + * 0x0 :   0.768 ms
> + * 0x1 :   6.144 ms
> + * 0x2 :  49.152 ms
> + * 0x3 : 393.216 ms
> + */
>  static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
>  {
> - writel(value, addr + TEMP0_CFG);
> + writel((readl(addr + TEMP0_CFG) & ~TEMP0_CFG_HDAK_MSK) |
> +(value << 4), addr + TEMP0_CFG);
>  }
>  
>  static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
> -- 
> 2.7.4
> 

[PATCH v2] of: dynamic: fix memory leak related to properties of __of_node_dup

[Lixin Wang]

If a node with no properties is dynamically added, then a property is
dynamically added to the node, then the property is dynamically removed,
the result will be node->properties == NULL and node->deadprops != NULL.

Signed-off-by: Lixin Wang 
---
v1:
 * Change the description of this patch as suggested by Frank Rowand.

 drivers/of/dynamic.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..465d43b 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -335,6 +335,10 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
 
+   if (!prop) {
+   prop = node->deadprops;
+   node->deadprops = NULL;
+   }
while (prop) {
struct property *next = prop->next;
kfree(prop->name);
-- 
2.6.2

[PATCH v2] of: dynamic: fix memory leak related to properties of __of_node_dup

[Lixin Wang]

If a node with no properties is dynamically added, then a property is
dynamically added to the node, then the property is dynamically removed,
the result will be node->properties == NULL and node->deadprops != NULL.

Signed-off-by: Lixin Wang 
---
v1:
 * Change the description of this patch as suggested by Frank Rowand.

 drivers/of/dynamic.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..465d43b 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -335,6 +335,10 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
 
+   if (!prop) {
+   prop = node->deadprops;
+   node->deadprops = NULL;
+   }
while (prop) {
struct property *next = prop->next;
kfree(prop->name);
-- 
2.6.2

Re: [PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

[kbuild test robot]

Hi Mario,

[auto build test ERROR on platform-drivers-x86/for-next]
[also build test ERROR on v4.14-rc5 next-20171016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
for-next
config: x86_64-randconfig-x013-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
 HEAD 73d71487dc3728417e851f3fac100ee4d6cdebd1 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/platform/x86/dell-smbios.c: In function 'location_show':
   drivers/platform/x86/dell-smbios.c:238:7: error: implicit declaration of 
function 'capable' [-Werror=implicit-function-declaration]
 if (!capable(CAP_SYS_ADMIN))
  ^~~
>> drivers/platform/x86/dell-smbios.c:238:15: error: 'CAP_SYS_ADMIN' undeclared 
>> (first use in this function)
 if (!capable(CAP_SYS_ADMIN))
  ^
   drivers/platform/x86/dell-smbios.c:238:15: note: each undeclared identifier 
is reported only once for each function it appears in
   drivers/platform/x86/dell-smbios.c: In function 'value_show':
   drivers/platform/x86/dell-smbios.c:252:15: error: 'CAP_SYS_ADMIN' undeclared 
(first use in this function)
 if (!capable(CAP_SYS_ADMIN))
  ^
   cc1: some warnings being treated as errors

vim +/CAP_SYS_ADMIN +238 drivers/platform/x86/dell-smbios.c

0b0f338a Mario Limonciello 2017-10-14  232  
0b0f338a Mario Limonciello 2017-10-14  233  static ssize_t location_show(struct 
device *dev,
0b0f338a Mario Limonciello 2017-10-14  234   struct 
device_attribute *attr, char *buf)
0b0f338a Mario Limonciello 2017-10-14  235  {
0b0f338a Mario Limonciello 2017-10-14  236  int i;
0b0f338a Mario Limonciello 2017-10-14  237  
0b0f338a Mario Limonciello 2017-10-14 @238  if (!capable(CAP_SYS_ADMIN))
0b0f338a Mario Limonciello 2017-10-14  239  return -EPERM;
0b0f338a Mario Limonciello 2017-10-14  240  
0b0f338a Mario Limonciello 2017-10-14  241  i = match_attribute(dev, attr);
0b0f338a Mario Limonciello 2017-10-14  242  if (i > 0)
0b0f338a Mario Limonciello 2017-10-14  243  return scnprintf(buf, 
PAGE_SIZE, "%08x", da_tokens[i].location);
0b0f338a Mario Limonciello 2017-10-14  244  return 0;
0b0f338a Mario Limonciello 2017-10-14  245  }
0b0f338a Mario Limonciello 2017-10-14  246  

:: The code at line 238 was first introduced by commit
:: 0b0f338a482cc8b1f4807887c866d7095d8d1b16 platform/x86: dell-smbios: Add 
a sysfs interface for SMBIOS tokens

:: TO: Mario Limonciello <mario.limoncie...@dell.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: application/gzip

Re: [PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

[kbuild test robot]

Hi Mario,

[auto build test ERROR on platform-drivers-x86/for-next]
[also build test ERROR on v4.14-rc5 next-20171016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
for-next
config: x86_64-randconfig-x013-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
 HEAD 73d71487dc3728417e851f3fac100ee4d6cdebd1 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/platform/x86/dell-smbios.c: In function 'location_show':
   drivers/platform/x86/dell-smbios.c:238:7: error: implicit declaration of 
function 'capable' [-Werror=implicit-function-declaration]
 if (!capable(CAP_SYS_ADMIN))
  ^~~
>> drivers/platform/x86/dell-smbios.c:238:15: error: 'CAP_SYS_ADMIN' undeclared 
>> (first use in this function)
 if (!capable(CAP_SYS_ADMIN))
  ^
   drivers/platform/x86/dell-smbios.c:238:15: note: each undeclared identifier 
is reported only once for each function it appears in
   drivers/platform/x86/dell-smbios.c: In function 'value_show':
   drivers/platform/x86/dell-smbios.c:252:15: error: 'CAP_SYS_ADMIN' undeclared 
(first use in this function)
 if (!capable(CAP_SYS_ADMIN))
  ^
   cc1: some warnings being treated as errors

vim +/CAP_SYS_ADMIN +238 drivers/platform/x86/dell-smbios.c

0b0f338a Mario Limonciello 2017-10-14  232  
0b0f338a Mario Limonciello 2017-10-14  233  static ssize_t location_show(struct 
device *dev,
0b0f338a Mario Limonciello 2017-10-14  234   struct 
device_attribute *attr, char *buf)
0b0f338a Mario Limonciello 2017-10-14  235  {
0b0f338a Mario Limonciello 2017-10-14  236  int i;
0b0f338a Mario Limonciello 2017-10-14  237  
0b0f338a Mario Limonciello 2017-10-14 @238  if (!capable(CAP_SYS_ADMIN))
0b0f338a Mario Limonciello 2017-10-14  239  return -EPERM;
0b0f338a Mario Limonciello 2017-10-14  240  
0b0f338a Mario Limonciello 2017-10-14  241  i = match_attribute(dev, attr);
0b0f338a Mario Limonciello 2017-10-14  242  if (i > 0)
0b0f338a Mario Limonciello 2017-10-14  243  return scnprintf(buf, 
PAGE_SIZE, "%08x", da_tokens[i].location);
0b0f338a Mario Limonciello 2017-10-14  244  return 0;
0b0f338a Mario Limonciello 2017-10-14  245  }
0b0f338a Mario Limonciello 2017-10-14  246  

:: The code at line 238 was first introduced by commit
:: 0b0f338a482cc8b1f4807887c866d7095d8d1b16 platform/x86: dell-smbios: Add 
a sysfs interface for SMBIOS tokens

:: TO: Mario Limonciello 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

Re: [PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

[kbuild test robot]

Hi Mario,

[auto build test WARNING on platform-drivers-x86/for-next]
[also build test WARNING on v4.14-rc5 next-20171016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/platform/x86/dell-smbios.c:108:2-3: Unneeded semicolon
   drivers/platform/x86/dell-smbios.c:87:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

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

Re: [PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

[kbuild test robot]

Hi Mario,

[auto build test WARNING on platform-drivers-x86/for-next]
[also build test WARNING on v4.14-rc5 next-20171016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/platform/x86/dell-smbios.c:108:2-3: Unneeded semicolon
   drivers/platform/x86/dell-smbios.c:87:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

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

[PATCH] platform/x86: dell-smbios: fix semicolon.cocci warnings

[kbuild test robot]

drivers/platform/x86/dell-smbios.c:108:2-3: Unneeded semicolon
drivers/platform/x86/dell-smbios.c:87:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 79480699ede0 ("platform/x86: dell-smbios: Introduce dispatcher for SMM 
calls")
CC: Mario Limonciello 
Signed-off-by: Fengguang Wu 
---

 dell-smbios.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -84,7 +84,7 @@ void dell_smbios_unregister_device(struc
put_device(d);
break;
}
-   };
+   }
mutex_unlock(_mutex);
dev_dbg(d, "Remove device: %s\n", d->driver->name);
 }
@@ -105,7 +105,7 @@ int dell_smbios_call(struct calling_inte
call_fn = priv->call_fn;
selected_dev = priv->device;
}
-   };
+   }
 
if (!selected_dev) {
ret = -ENODEV;

[PATCH] platform/x86: dell-smbios: fix semicolon.cocci warnings

[kbuild test robot]

drivers/platform/x86/dell-smbios.c:108:2-3: Unneeded semicolon
drivers/platform/x86/dell-smbios.c:87:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 79480699ede0 ("platform/x86: dell-smbios: Introduce dispatcher for SMM 
calls")
CC: Mario Limonciello 
Signed-off-by: Fengguang Wu 
---

 dell-smbios.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -84,7 +84,7 @@ void dell_smbios_unregister_device(struc
put_device(d);
break;
}
-   };
+   }
mutex_unlock(_mutex);
dev_dbg(d, "Remove device: %s\n", d->driver->name);
 }
@@ -105,7 +105,7 @@ int dell_smbios_call(struct calling_inte
call_fn = priv->call_fn;
selected_dev = priv->device;
}
-   };
+   }
 
if (!selected_dev) {
ret = -ENODEV;

Re: [PATCH v8 12/15] platform/x86: dell-smbios: Add filtering support

[kbuild test robot]

Hi Mario,

[auto build test ERROR on platform-drivers-x86/for-next]
[also build test ERROR on v4.14-rc5 next-20171016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
for-next
config: x86_64-randconfig-x001-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/platform/x86/dell-smbios.c:53:3: error: 'CAP_SYS_ADMIN' undeclared 
>> here (not in a function)
 {CAP_SYS_ADMIN, CLASS_TOKEN_READ, SELECT_TOKEN_STD},
  ^
>> drivers/platform/x86/dell-smbios.c:88:3: error: initializer element is not 
>> constant
 {CAP_SYS_ADMIN, CAPSULE_EN_TOKEN, CAPSULE_DIS_TOKEN},
  ^
   drivers/platform/x86/dell-smbios.c:88:3: note: (near initialization for 
'token_whitelist[0].need_capability')
   drivers/platform/x86/dell-smbios.c: In function 'dell_smbios_call_filter':
   drivers/platform/x86/dell-smbios.c:245:8: error: implicit declaration of 
function 'capable' [-Werror=implicit-function-declaration]
   capable(token_whitelist[i].need_capability)) {
   ^~~
>> drivers/platform/x86/dell-smbios.c:271:14: error: 'CAP_SYS_RAWIO' undeclared 
>> (first use in this function)
 if (capable(CAP_SYS_RAWIO)) {
 ^
   drivers/platform/x86/dell-smbios.c:271:14: note: each undeclared identifier 
is reported only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/CAP_SYS_ADMIN +53 drivers/platform/x86/dell-smbios.c

47  
48  /* calls that are whitelisted for given capabilities */
49  static struct smbios_call call_whitelist[] = {
50  /* generally tokens are allowed, but may be further filtered or
51   * restricted by token blacklist or whitelist
52   */
  > 53  {CAP_SYS_ADMIN, CLASS_TOKEN_READ,   SELECT_TOKEN_STD},
54  {CAP_SYS_ADMIN, CLASS_TOKEN_READ,   SELECT_TOKEN_AC},
55  {CAP_SYS_ADMIN, CLASS_TOKEN_READ,   SELECT_TOKEN_BAT},
56  {CAP_SYS_ADMIN, CLASS_TOKEN_WRITE,  SELECT_TOKEN_STD},
57  {CAP_SYS_ADMIN, CLASS_TOKEN_WRITE,  SELECT_TOKEN_AC},
58  {CAP_SYS_ADMIN, CLASS_TOKEN_WRITE,  SELECT_TOKEN_BAT},
59  /* used by userspace: fwupdate */
60  {CAP_SYS_ADMIN, CLASS_ADMIN_PROP,   SELECT_ADMIN_PROP},
61  /* used by userspace: fwupd */
62  {CAP_SYS_ADMIN, CLASS_INFO, SELECT_DOCK},
63  {CAP_SYS_ADMIN, CLASS_FLASH_INTERFACE,  SELECT_FLASH_INTERFACE},
64  };
65  
66  /* calls that are explicitly blacklisted */
67  static struct smbios_call call_blacklist[] = {
68  {0x, 01, 07}, /* manufacturing use */
69  {0x, 06, 05}, /* manufacturing use */
70  {0x, 11, 03}, /* write once */
71  {0x, 11, 07}, /* write once */
72  {0x, 11, 11}, /* write once */
73  {0x, 19, -1}, /* diagnostics */
74  /* handled by kernel: dell-laptop */
75  {0x, CLASS_INFO, SELECT_RFKILL},
76  {0x, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT},
77  };
78  
79  struct token_range {
80  u32 need_capability;
81  u16 min;
82  u16 max;
83  };
84  
85  /* tokens that are whitelisted for given capabilities */
86  static struct token_range token_whitelist[] = {
87  /* used by userspace: fwupdate */
  > 88  {CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
89  /* can indicate to userspace that WMI is needed */
90  {0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
91  };
92  

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


.config.gz
Description: application/gzip

Re: [PATCH v8 12/15] platform/x86: dell-smbios: Add filtering support

[kbuild test robot]

Hi Mario,

[auto build test ERROR on platform-drivers-x86/for-next]
[also build test ERROR on v4.14-rc5 next-20171016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce-support-for-Dell-SMBIOS-over-WMI/20171017-103109
base:   git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
for-next
config: x86_64-randconfig-x001-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/platform/x86/dell-smbios.c:53:3: error: 'CAP_SYS_ADMIN' undeclared 
>> here (not in a function)
 {CAP_SYS_ADMIN, CLASS_TOKEN_READ, SELECT_TOKEN_STD},
  ^
>> drivers/platform/x86/dell-smbios.c:88:3: error: initializer element is not 
>> constant
 {CAP_SYS_ADMIN, CAPSULE_EN_TOKEN, CAPSULE_DIS_TOKEN},
  ^
   drivers/platform/x86/dell-smbios.c:88:3: note: (near initialization for 
'token_whitelist[0].need_capability')
   drivers/platform/x86/dell-smbios.c: In function 'dell_smbios_call_filter':
   drivers/platform/x86/dell-smbios.c:245:8: error: implicit declaration of 
function 'capable' [-Werror=implicit-function-declaration]
   capable(token_whitelist[i].need_capability)) {
   ^~~
>> drivers/platform/x86/dell-smbios.c:271:14: error: 'CAP_SYS_RAWIO' undeclared 
>> (first use in this function)
 if (capable(CAP_SYS_RAWIO)) {
 ^
   drivers/platform/x86/dell-smbios.c:271:14: note: each undeclared identifier 
is reported only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/CAP_SYS_ADMIN +53 drivers/platform/x86/dell-smbios.c

47  
48  /* calls that are whitelisted for given capabilities */
49  static struct smbios_call call_whitelist[] = {
50  /* generally tokens are allowed, but may be further filtered or
51   * restricted by token blacklist or whitelist
52   */
  > 53  {CAP_SYS_ADMIN, CLASS_TOKEN_READ,   SELECT_TOKEN_STD},
54  {CAP_SYS_ADMIN, CLASS_TOKEN_READ,   SELECT_TOKEN_AC},
55  {CAP_SYS_ADMIN, CLASS_TOKEN_READ,   SELECT_TOKEN_BAT},
56  {CAP_SYS_ADMIN, CLASS_TOKEN_WRITE,  SELECT_TOKEN_STD},
57  {CAP_SYS_ADMIN, CLASS_TOKEN_WRITE,  SELECT_TOKEN_AC},
58  {CAP_SYS_ADMIN, CLASS_TOKEN_WRITE,  SELECT_TOKEN_BAT},
59  /* used by userspace: fwupdate */
60  {CAP_SYS_ADMIN, CLASS_ADMIN_PROP,   SELECT_ADMIN_PROP},
61  /* used by userspace: fwupd */
62  {CAP_SYS_ADMIN, CLASS_INFO, SELECT_DOCK},
63  {CAP_SYS_ADMIN, CLASS_FLASH_INTERFACE,  SELECT_FLASH_INTERFACE},
64  };
65  
66  /* calls that are explicitly blacklisted */
67  static struct smbios_call call_blacklist[] = {
68  {0x, 01, 07}, /* manufacturing use */
69  {0x, 06, 05}, /* manufacturing use */
70  {0x, 11, 03}, /* write once */
71  {0x, 11, 07}, /* write once */
72  {0x, 11, 11}, /* write once */
73  {0x, 19, -1}, /* diagnostics */
74  /* handled by kernel: dell-laptop */
75  {0x, CLASS_INFO, SELECT_RFKILL},
76  {0x, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT},
77  };
78  
79  struct token_range {
80  u32 need_capability;
81  u16 min;
82  u16 max;
83  };
84  
85  /* tokens that are whitelisted for given capabilities */
86  static struct token_range token_whitelist[] = {
87  /* used by userspace: fwupdate */
  > 88  {CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
89  /* can indicate to userspace that WMI is needed */
90  {0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
91  };
92  

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


.config.gz
Description: application/gzip

Re: [PATCH] scsi: gdth: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: gdth: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: smartpqi: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: smartpqi: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: aic94xx: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: aic94xx: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: dc395x: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: dc395x: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> In preparation for unconditionally passing the struct timer_list
> pointer to all timer callbacks, switch to using the new timer_setup()
> and from_timer() to pass the timer pointer explicitly.

Reviewed-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering