[PATCH 0/3] irqchip: meson-gpio: add support for Meson-AXG SoCs

[Yixun Lan]

  This series try to add GPIO interrupt controller support for Meson-AXG SoCs.
  The first patch is a trivial typo fix, I can fold the first two patches
together if necessary.

Yixun Lan (3):
  dt-bindings: interrupt-controller: fix the double quotes
  dt-bindings: interrupt-controller: New binding for Meson-AXG SoC
  irqchip/meson-gpio: add support for Meson-AXG SoCs

 .../bindings/interrupt-controller/amlogic,meson-gpio-intc.txt | 11 ++-
 drivers/irqchip/irq-meson-gpio.c  |  5 +
 2 files changed, 11 insertions(+), 5 deletions(-)

-- 
2.16.2

[PATCH 1/3] dt-bindings: interrupt-controller: fix the double quotes

[Yixun Lan]

The double quotes seems not ASCII type, fix it here.

Signed-off-by: Yixun Lan 
---
 .../bindings/interrupt-controller/amlogic,meson-gpio-intc.txt  | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
index a83f9a5734ca..c753d99d43db 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
@@ -9,11 +9,11 @@ number of interrupt exposed depends on the SoC.
 
 Required properties:
 
-- compatible : must have "amlogic,meson8-gpio-intc” and either
-   “amlogic,meson8-gpio-intc” for meson8 SoCs (S802) or
-   “amlogic,meson8b-gpio-intc” for meson8b SoCs (S805) or
-   “amlogic,meson-gxbb-gpio-intc” for GXBB SoCs (S905) or
-   “amlogic,meson-gxl-gpio-intc” for GXL SoCs (S905X, S912)
+- compatible : must have "amlogic,meson8-gpio-intc" and either
+"amlogic,meson8-gpio-intc" for meson8 SoCs (S802) or
+"amlogic,meson8b-gpio-intc" for meson8b SoCs (S805) or
+"amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or
+"amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912)
 - interrupt-parent : a phandle to the GIC the interrupts are routed to.
Usually this is provided at the root level of the device tree as it is
common to most of the SoC.
-- 
2.16.2

[PATCH 2/3] dt-bindings: interrupt-controller: New binding for Meson-AXG SoC

[Yixun Lan]

Update the dt-binding documentation to support new compatible string
for the GPIO interrupt controller which found in Amlogic's Meson-AXG SoC.

Signed-off-by: Yixun Lan 
---
 .../devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
index c753d99d43db..89674ad8a097 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
@@ -14,6 +14,7 @@ Required properties:
 "amlogic,meson8b-gpio-intc" for meson8b SoCs (S805) or
 "amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or
 "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912)
+"amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X)
 - interrupt-parent : a phandle to the GIC the interrupts are routed to.
Usually this is provided at the root level of the device tree as it is
common to most of the SoC.
-- 
2.16.2

[PATCH 3/3] irqchip/meson-gpio: add support for Meson-AXG SoCs

[Yixun Lan]

The Meson-AXG SoC uses the same GPIO interrupt controller IP block as the other
Meson SoCs. A total of 100 pins can be spied on, which is the sum of:
- 255:100 Undefined(no interrupt)
- 99:84, 16 pins on bank GPIOY
- 83:61, 23 pins on bank GPIOX
- 60:40, 21 pins on bank GPIOA
- 39:25, 15 pins on bank BOOT
- 24:14, 11 pins on bank GPIOZ
- 13:0 , 14 pins in the AO domain

Signed-off-by: Yixun Lan 
---
 drivers/irqchip/irq-meson-gpio.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c
index a59bdbc0b9bb..7b531fd075b8 100644
--- a/drivers/irqchip/irq-meson-gpio.c
+++ b/drivers/irqchip/irq-meson-gpio.c
@@ -63,11 +63,16 @@ static const struct meson_gpio_irq_params gxl_params = {
.nr_hwirq = 110,
 };
 
+static const struct meson_gpio_irq_params axg_params = {
+   .nr_hwirq = 100,
+};
+
 static const struct of_device_id meson_irq_gpio_matches[] = {
{ .compatible = "amlogic,meson8-gpio-intc", .data = &meson8_params },
{ .compatible = "amlogic,meson8b-gpio-intc", .data = &meson8b_params },
{ .compatible = "amlogic,meson-gxbb-gpio-intc", .data = &gxbb_params },
{ .compatible = "amlogic,meson-gxl-gpio-intc", .data = &gxl_params },
+   { .compatible = "amlogic,meson-axg-gpio-intc", .data = &axg_params },
{ }
 };
 
-- 
2.16.2

[PATCH] mtd: spi-nor: clear Extended Address Reg on switch to 3-byte addressing.

[NeilBrown]

According to section
   8.2.7 Write Extended Address Register (C5h)

of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)

   The Extended Address Register is only effective when the device is
   in the 3-Byte Address Mode.  When the device operates in the 4-Byte
   Address Mode (ADS=1), any command with address input of A31-A24
   will replace the Extended Address Register values. It is
   recommended to check and update the Extended Address Register if
   necessary when the device is switched from 4-Byte to 3-Byte Address
   Mode.

This patch adds code to implement that recommendation.  Without this,
my GNUBEE-PC1 will not successfully reboot, as the Extended Address
Register is left with a value of '1'. When the SOC attempts to read
(in 3-byte address mode) the boot loader, it reads from the wrong
location.

Signed-off-by: NeilBrown 
---
 drivers/mtd/spi-nor/spi-nor.c | 10 ++
 include/linux/mtd/spi-nor.h   |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d445a4d3b770..c303bf0d2982 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -269,6 +269,7 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
int status;
bool need_wren = false;
u8 cmd;
+   u8 val;
 
switch (JEDEC_MFR(info)) {
case SNOR_MFR_MICRON:
@@ -283,6 +284,15 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
status = nor->write_reg(nor, cmd, NULL, 0);
if (need_wren)
write_disable(nor);
+   if (!status && !enable &&
+   nor->read_reg(nor, SPINOR_OP_RDXA, &val, 1) == 0 &&
+   val != 0) {
+   /* need to reset the Extended Address Register */
+   write_enable(nor);
+   val = 0;
+   nor->write_reg(nor, SPINOR_OP_WRXA, &val, 1);
+   write_disable(nor);
+   }
 
return status;
default:
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index de36969eb359..42954419cfdf 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -62,6 +62,8 @@
 #define SPINOR_OP_RDCR 0x35/* Read configuration register */
 #define SPINOR_OP_RDFSR0x70/* Read flag status register */
 #define SPINOR_OP_CLFSR0x50/* Clear flag status register */
+#define SPINOR_OP_RDXA 0xc8/* Read Extended Address Register */
+#define SPINOR_OP_WRXA 0xc5/* Write Extended Address Register */
 
 /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
 #define SPINOR_OP_READ_4B  0x13/* Read data bytes (low frequency) */
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

KMSAN: uninit-value in af_alg_free_areq_sgls

[syzbot]

Hello,

syzbot hit the following crash on  
https://github.com/google/kmsan.git/master commit

e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
kmsan: temporarily disable visitAsmInstruction() to help syzbot
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=9c251bdd09f83b92ba95


So far this crash happened 11 times on  
https://github.com/google/kmsan.git/master.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5551473324720128
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=4782073151750144
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5003160619843584
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9c251bdd09f83b92b...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

==
BUG: KMSAN: uninit-value in atomic_sub arch/x86/include/asm/atomic.h:65  
[inline]
BUG: KMSAN: uninit-value in af_alg_free_areq_sgls+0x5ff/0xb20  
crypto/af_alg.c:669

CPU: 1 PID: 3568 Comm: syzkaller909997 Not tainted 4.16.0+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 atomic_sub arch/x86/include/asm/atomic.h:65 [inline]
 af_alg_free_areq_sgls+0x5ff/0xb20 crypto/af_alg.c:669
 af_alg_free_resources+0x66/0xf0 crypto/af_alg.c:1033
 _aead_recvmsg crypto/algif_aead.c:321 [inline]
 aead_recvmsg+0x9a4/0x2960 crypto/algif_aead.c:334
 aead_recvmsg_nokey+0x129/0x160 crypto/algif_aead.c:452
 sock_recvmsg_nosec net/socket.c:803 [inline]
 sock_recvmsg+0x1d0/0x230 net/socket.c:810
 ___sys_recvmsg+0x3fb/0x810 net/socket.c:2205
 __sys_recvmsg net/socket.c:2250 [inline]
 SYSC_recvmsg+0x298/0x3c0 net/socket.c:2262
 SyS_recvmsg+0x54/0x80 net/socket.c:2257
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43ff29
RSP: 002b:7ffd9919c808 EFLAGS: 0207 ORIG_RAX: 002f
RAX: ffda RBX: 004002c8 RCX: 0043ff29
RDX:  RSI: 2040 RDI: 0004
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10: 004002c8 R11: 0207 R12: 00401850
R13: 004018e0 R14:  R15: 

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
 __kmalloc+0x23c/0x350 mm/slub.c:3791
 kmalloc include/linux/slab.h:517 [inline]
 sock_kmalloc+0x14e/0x270 net/core/sock.c:1986
 af_alg_get_rsgl+0x427/0xe10 crypto/af_alg.c:1149
 _aead_recvmsg crypto/algif_aead.c:163 [inline]
 aead_recvmsg+0x953/0x2960 crypto/algif_aead.c:334
 aead_recvmsg_nokey+0x129/0x160 crypto/algif_aead.c:452
 sock_recvmsg_nosec net/socket.c:803 [inline]
 sock_recvmsg+0x1d0/0x230 net/socket.c:810
 ___sys_recvmsg+0x3fb/0x810 net/socket.c:2205
 __sys_recvmsg net/socket.c:2250 [inline]
 SYSC_recvmsg+0x298/0x3c0 net/socket.c:2262
 SyS_recvmsg+0x54/0x80 net/socket.c:2257
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

[PATCH] ARM64: dts: meson-axg: add GPIO interrupt controller support

[Yixun Lan]

Add the GPIO interrupt controller driver which found in the Amlogic's
Meson-AXG SoC, the controller share the similar ASIC IP as other meson SoCs.

Signed-off-by: Yixun Lan 

---
Hi Kevin
 Please note this patch depend on the GPIO interrupt driver here[0]

[0] http://lkml.kernel.org/r/20180408145700.23520-1-yixun@amlogic.com
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index b58808eb3cc8..c1105065de99 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -120,6 +120,15 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd0 0x0 0x25000>;
 
+   gpio_intc: interrupt-controller@f080 {
+   compatible = "amlogic,meson-gpio-intc";
+   reg = <0x0 0xf080 0x0 0x10>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   amlogic,channel-interrupts = <64 65 66 67 68 69 
70 71>;
+   status = "disabled";
+   };
+
pwm_ab: pwm@1b000 {
compatible = "amlogic,meson-axg-ee-pwm";
reg = <0x0 0x1b000 0x0 0x20>;
-- 
2.16.2

KMSAN: uninit-value in _decode_session6

[syzbot]

Hello,

syzbot hit the following crash on  
https://github.com/google/kmsan.git/master commit

e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
kmsan: temporarily disable visitAsmInstruction() to help syzbot
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=2974b85346f85b586f4d


Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=4871594698604544
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329060) (llvm/trunk 329054)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2974b85346f85b586...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

==
BUG: KMSAN: uninit-value in _decode_session6+0x6d1/0x1290  
net/ipv6/xfrm6_policy.c:151

CPU: 1 PID: 5714 Comm: blkid Not tainted 4.16.0+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 _decode_session6+0x6d1/0x1290 net/ipv6/xfrm6_policy.c:151
 __xfrm_decode_session+0x140/0x1c0 net/xfrm/xfrm_policy.c:2368
 xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]
 icmpv6_route_lookup net/ipv6/icmp.c:372 [inline]
 icmp6_send+0x305f/0x3460 net/ipv6/icmp.c:551
 icmpv6_send+0xe0/0x110 net/ipv6/ip6_icmp.c:43
 ip6_link_failure+0x8f/0x580 net/ipv6/route.c:2034
 dst_link_failure include/net/dst.h:426 [inline]
 ndisc_error_report+0x101/0x1a0 net/ipv6/ndisc.c:695
 neigh_invalidate+0x385/0x930 net/core/neighbour.c:883
 neigh_timer_handler+0xd85/0x12d0 net/core/neighbour.c:969
 call_timer_fn+0x26a/0x5a0 kernel/time/timer.c:1326
 expire_timers kernel/time/timer.c:1363 [inline]
 __run_timers+0xda7/0x11c0 kernel/time/timer.c:1666
 run_timer_softirq+0x43/0x70 kernel/time/timer.c:1692
 __do_softirq+0x56d/0x93d kernel/softirq.c:285
 invoke_softirq kernel/softirq.c:365 [inline]
 irq_exit+0x202/0x240 kernel/softirq.c:405
 exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:541
 smp_apic_timer_interrupt+0x64/0x90 arch/x86/kernel/apic/apic.c:1055
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:857
 
RIP: 0010:kmsan_get_origin_address_noruntime+0x8f/0x260  
include/linux/mmzone.h:1206

RSP: :880165b0fb40 EFLAGS: 0202 ORIG_RAX: ff12
RAX: 8801e5b0fcc8 RBX:  RCX: 88021fff1580
RDX: 0580 RSI:  RDI: 880165b0fcc8
RBP: 880165b0fb78 R08: 01080020 R09: 0002
R10:  R11:  R12: 0068
R13: d3a0004b R14: 880165b0fcc8 R15: 
 kmsan_set_origin_inline+0x6b/0x120 mm/kmsan/kmsan_instr.c:585
 __msan_poison_alloca+0x15c/0x1d0 mm/kmsan/kmsan_instr.c:647
 handle_mm_fault+0x1c8/0x7ba0 mm/memory.c:4114
 __do_page_fault+0xec4/0x1a10 arch/x86/mm/fault.c:1423
 do_page_fault+0xd3/0x260 arch/x86/mm/fault.c:1500
 page_fault+0x45/0x50 arch/x86/entry/entry_64.S:1151
RIP: 0033:0x7f93ad8e4789
RSP: 002b:7ffd11b3cf20 EFLAGS: 00010216
RAX: 7f93ad4742a0 RBX: 7f93adaf79a8 RCX: 04a8
RDX: 7f93ad6a9028 RSI: aaab RDI: 
RBP: 7ffd11b3d000 R08: 0001 R09: 0010
R10: 7f93ad343a30 R11: 0206 R12: 7f93ad325000
R13: 7f93ad343220 R14: 7f93ad33d748 R15: 7f93adaef740

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
 kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
 kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:526
 __msan_memcpy+0x19f/0x1f0 mm/kmsan/kmsan_instr.c:470
 skb_copy_bits+0x63a/0xdb0 net/core/skbuff.c:2046
 __pskb_pull_tail+0x483/0x22e0 net/core/skbuff.c:1883
 pskb_may_pull include/linux/skbuff.h:2112 [inline]
 _decode_session6+0x79f/0x1290 net/ipv6/xfrm6_policy.c:152
 __xfrm_decode_session+0x140/0x1c0 net/xfrm/xfrm_policy.c:2368
 xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]
 icmpv6_route_lookup net/ipv6/icmp.c:372 [inline]
 icmp6_send+0x305f/0x3460 net/ipv6/icmp.c:551
 icmpv6_send+0xe0/0x110 net/ipv6/ip6_icmp.c:43
 ip6_link_failure+0x8f/0x580 net/ipv6/route.c:2034
 dst_link_failure include/net/dst.h:426 [inline]
 ndisc_error_report+0x101/0x1a0 net/ipv6/ndisc.c:695
 neigh_invalidate+0x385/0x930 net/core/neighbour.c:883
 neigh_timer_handler+0xd85/0x12d0 net/core/neighbour.c:969
 call_timer_fn+0x26a/0x5a0 kernel/time/timer.c:1326
 expire_timers kernel/time/timer.c:1363 [inline]
 __run_timers+0xda7/0x11c0 kernel/time/timer.c:1666
 run_timer_softirq+0x43/0x70 kernel/

Re: [PATCH] Documentation: fix reST markup error in driver-api/usb/typec.rst

[Greg KH]

On Sun, Apr 08, 2018 at 10:47:12AM +0800, changbin...@intel.com wrote:
> From: Changbin Du 
> 
> There is an format error in driver-api/usb/typec.rst that breaks sphinx
> docs building.
> 
> reST markup error:
> /home/changbin/work/linux/Documentation/driver-api/usb/typec.rst:215: 
> (SEVERE/4) Unexpected section title or transition.
> 
> 
> Documentation/Makefile:68: recipe for target 'htmldocs' failed
> make[1]: *** [htmldocs] Error 1
> Makefile:1527: recipe for target 'htmldocs' failed
> make: *** [htmldocs] Error 2
> 
> Signed-off-by: Changbin Du 
> ---
>  Documentation/driver-api/usb/typec.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, someone else already sent this, sorry.  I'll be sending it
onward after 4.17-rc1 is out.

greg k-h

[PATCH v2] resource: Fix integer overflow at reallocation

[Takashi Iwai]

We've got a bug report indicating a kernel panic at booting on an
x86-32 system, and it turned out to be the invalid resource assigned
after PCI resource reallocation.  __find_resource() first aligns the
resource start address and resets the end address with start+size-1
accordingly, then checks whether it's contained.  Here the end address
may overflow the integer, although resource_contains() still returns
true because the function validates only start and end address.  So
this ends up with returning an invalid resource (start > end).

There was already an attempt to cover such a problem in the commit
47ea91b4052d ("Resource: fix wrong resource window calculation"), but
this case is an overseen one.

This patch adds the validity check in resource_contains() to see
whether the given resource has a valid range for avoiding the integer
overflow problem.

Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739
Fixes: 23c570a67448 ("resource: ability to resize an allocated resource")
Reported-and-tested-by: Michael Henders 
Reviewed-by: Ram Pai 
Cc: 
Signed-off-by: Takashi Iwai 
---

Andrew, could you pick this? It's still in a wild west...
Thanks!

v1->v2: check in resource_contains() instead of in __find_resource()

 include/linux/ioport.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..466d7be046eb 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -212,6 +212,9 @@ static inline bool resource_contains(struct resource *r1, 
struct resource *r2)
return false;
if (r1->flags & IORESOURCE_UNSET || r2->flags & IORESOURCE_UNSET)
return false;
+   /* sanity check whether it's a valid resource range */
+   if (r2->end < r2->start)
+   return false;
return r1->start <= r2->start && r1->end >= r2->end;
 }
 
-- 
2.16.3

Re: [PATCH] Documentation: fix reST markup error in driver-api/usb/typec.rst

[Du, Changbin]

On Sun, Apr 08, 2018 at 09:19:58AM +0200, Greg KH wrote:
> On Sun, Apr 08, 2018 at 10:47:12AM +0800, changbin...@intel.com wrote:
> > From: Changbin Du 
> > 
> > There is an format error in driver-api/usb/typec.rst that breaks sphinx
> > docs building.
> > 
> > reST markup error:
> > /home/changbin/work/linux/Documentation/driver-api/usb/typec.rst:215: 
> > (SEVERE/4) Unexpected section title or transition.
> > 
> > 
> > Documentation/Makefile:68: recipe for target 'htmldocs' failed
> > make[1]: *** [htmldocs] Error 1
> > Makefile:1527: recipe for target 'htmldocs' failed
> > make: *** [htmldocs] Error 2
> > 
> > Signed-off-by: Changbin Du 
> > ---
> >  Documentation/driver-api/usb/typec.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Thanks, someone else already sent this, sorry.  I'll be sending it
> onward after 4.17-rc1 is out.
>
No problem. Thanks for your quick checking!

> greg k-h

-- 
Thanks,
Changbin Du

Re: [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id

[Wolfram Sang]

Hi,

On Mon, Mar 19, 2018 at 09:10:58AM -0700, Guenter Roeck wrote:
> Commit dde67eb1beeb ("i2c: add i2c_get_device_id() to get the standard
> I2C device id") added a function to return the standard I2C device ID.
> Use that function to verify the device ID of a given device.

I am very open to these patches, just...

> 
> Cc: Peter Rosin 
> Signed-off-by: Guenter Roeck 
> ---
> RFC:
> - Compile tested only

... I would really like to have them tested. After that happened, Peter
and I can figure out who should apply them for seamless upstreaming.

> - Should there also be I2C_DEVICE_PART_ID_ANY to enable maching
>   against all parts from a given manufacturer ?

Can't we just add it when we need it?

> + dev_err(&client->dev, "unexpected device id %03x-%03x-%x\n",
> + real_id.manufacturer_id, real_id.part_id,
> + real_id.die_revision);
> + return -ENODEV;

I wonder about the ERR loglevel. ENODEV is not an error, I'd think?

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH 00/20] afs: Fixes and development

[David Howells]

Linus Torvalds  wrote:

> Now, the conflicts really do look entirely trivial, and that's not the
> problem, but the fact that you *didn't* re-send the AFS pull request
> makes me wonder if you perhaps didn't want me to pull it after all?

Sorry: Al pointed out that I was incorrectly using lookup_one_len().  I
proposed a fix, but he decided that he wanted to rejig lookup_one_len()
instead, so I was waiting for that.

Al: Can you rebase your vfs/work.dcache branch on top of linus/master (I think
the rest of your branch is pulled already)?  Or should I just merge together
the fscache patches with it and rebase my afs-next branch off of that?

David

[PATCH] firmware: dmi_scan: Use lowercase letters for UUID

[Jean Delvare]

RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this
recommendation.

Suggested by Paul Dagnelie at:
https://savannah.nongnu.org/bugs/index.php?53569

Signed-off-by: Jean Delvare 
---
 drivers/firmware/dmi_scan.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-4.16.orig/drivers/firmware/dmi_scan.c 2018-04-01 23:20:27.0 
+0200
+++ linux-4.16/drivers/firmware/dmi_scan.c  2018-04-08 09:32:20.508719012 
+0200
@@ -210,9 +210,9 @@ static void __init dmi_save_uuid(const s
 * says that this is the defacto standard.
 */
if (dmi_ver >= 0x020600)
-   sprintf(s, "%pUL", d);
+   sprintf(s, "%pUl", d);
else
-   sprintf(s, "%pUB", d);
+   sprintf(s, "%pUb", d);
 
dmi_ident[slot] = s;
 }


-- 
Jean Delvare
SUSE L3 Support

Re: simultaneous voice/data works (was Re: call/normal switch was Re: omap4-droid4: voice call support was)

[Pavel Machek]

Hi!

> > mmcli -m 0 --enable
> > mmcli -m 0  --location-enable-gps-nmea
> > watch -n .3 sudo mmcli -m 0  --location-get-gps-nmea
> > 
> > ...can be used to get GPS data. Droid4 seems to have rather bad GPS,
> > so you should probably put it near window for testing.
> > 
> > Is there way to grab data from modemmanager and feed it to gpsd, so
> > that normal applications can access gps? I don't see easy way.
> > 
> > I tried --location-enable-gps-unmanaged , but that did not work for
> > me.
> 
> That requires a TTY that would spit out the GPS data; in this mode MM
> only sends the start/stop commands, and what comes out the GPS TTY is
> undefined (at least by MM).
> 
> So unless you know that one of the 6600's TTYs does GPS and in what
> format it does GPS, then no.
> 
> Doesn't --location-get-gps-nmea work for you?  That will spit out the
> latest NMEA traces MM gets from the modem, if it supports NMEA.  I
> believe --location-status will tell you what methods MM supports with
> the modem.

Yes, --location-get-gps-nmea works for me.

I guess one way forward would be to implement --location-get-gps-nmea
support for qmicli, and use that?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [GIT PULL] Kernel lockdown for secure boot

[joeyli]

On Wed, Apr 04, 2018 at 04:31:46AM +, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov <
> alexei.starovoi...@gmail.com> wrote:
> > If the only thing that folks are paranoid about is reading
> > arbitrary kernel memory with bpf_probe_read() helper
> > then preferred patch would be to disable it during verification
> > when in lockdown mode.
> > No run-time overhead and android folks will be happy
> > that lockdown doesn't break their work.
> > They converted out-of-tree networking accounting
> > module and corresponding user daemon to use bpf:
> 
> https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf
> 
> An alternative would be to only disable kernel reads if the kernel contains
> secrets that aren't supposed to be readable by root. If the keyring is
> configured such that root can read everything, it seems like less of a
> concern?

Currently the KMK (kernel master key) can be a trusted key (TPM sealed) or a
user key (plaintext). The EVM keeps a key (plaintext) in memory that
it is decrypted from a KMK encrypted key. Those kernel reads functions should
be disabled when the KMK be loaded to keyring.

You idea is good that kernel can keep those reads functions enabled until KMK
be loaded. Which means those functions are still available before user enables
KMK and EVM.

There have another idea is using a tree to register all sensitive data
then blanking them when reading. Here is a very early developing version:

https://github.com/joeyli/linux-sensitive_data/commits/sensitive-data-tree-v0.1-v4.15

But this approach causes runtime overhead and all sensitive data address must
be found and registered (e.g. plaintext in encryption module)

Thanks a lot!
Joey Lee 

Re: [PATCH v2] add -Wpointer-arith sparse flag to toggle sizeof(void) warnings

[Luc Van Oostenryck]

On Sat, Apr 07, 2018 at 11:58:05AM -1000, Joey Pabalinas wrote:
> Recent changes to the min()/max() macros in include/linux/kernel.h
> have added a lot of noise when compiling the kernel with Sparse checking
> enabled. This mostly is due to the *huge* increase in the number of
> sizeof(void) warnings, a larger number of which can safely be ignored.
> 
> Add the -Wpointer-arith flag to enable/disable these warnings (along
> with the warning when applying sizeof to function types exactly like the
> GCC -Wpointer-arith flag) on demand; the warning itself has been disabled
> by default to reduce the large influx of noise which was inadvertently
> added by commit 3c8ba0d61d04ced9f8 (kernel.h: Retain constant expression
> output for max()/min()).

Thanks. 
It's good to me. I just have a few remarks/suggestions:
 
With the warning disabled by default (for the moment), I had to adapt
the testsuite with:

diff --git a/validation/sizeof-function.c b/validation/sizeof-function.c
index 27d535d4e..8ff67f214 100644
--- a/validation/sizeof-function.c
+++ b/validation/sizeof-function.c
@@ -35,7 +35,7 @@ int test(void)
 
 /*
  * check-name: sizeof-function
- * check-command: sparse -Wno-decl $file
+ * check-command: sparse -Wpointer-arith -Wno-decl $file
  *
  * check-error-start
 sizeof-function.c:22:14: warning: expression using sizeof on a function

> diff --git a/sparse.1 b/sparse.1
> index 88343f3170f195297a..4379406999c94b806e 100644
> --- a/sparse.1
> +++ b/sparse.1
> @@ -288,6 +288,25 @@ Standard C syntax does not permit a parenthesized string 
> as an array
>  initializer.  GCC allows this syntax as an extension.  With
>  \fB\-Wparen\-string\fR, Sparse will warn about this syntax.
>  
> +Sparse does not issue these warnings by default.
> +.
> +.TP
> +.B \-Wpointer-arith
> +Warn about anything that depends on the \fBsizeof\fR a function type or of 
> void.

Maybe it would be useful to add something along the line of "like directly using
the sizeof operator on void or doing pointer arithmetic on a void pointer" ?

> +Although non-standard (and somewhat illogical), constructs such as 
> \fBsizeof(void)\fR
> +are often useful when the intent is to operate on an expression without 
> evaluating
> +it, e.g. in the following integer constant expression predicate:
> +.nf
> +#define __is_constexpr(x) \\
> + (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
> +.fi

I think that pointer arithmetic is much more useful than taking the size of void
(being able to take the size of *any* thing is somewhere in the middle, IMO).
But in all case, I don't think this part should belong to the man page.

Cheers,
-- Luc

Re: [GIT PULL] Kernel lockdown for secure boot

[joeyli]

On Tue, Apr 03, 2018 at 07:34:25PM -0700, Alexei Starovoitov wrote:
> On Tue, Apr 3, 2018 at 9:26 AM, Andy Lutomirski  wrote:
> > On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov
> >  wrote:
> >> On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote:
> >>> >
> >>> >> "bpf: Restrict kernel image access functions when the kernel is locked 
> >>> >> down":
> >>> >> This patch just sucks in general.
> >>> >
> >>> > Yes - but that's what Alexei Starovoitov specified.  bpf kind of sucks 
> >>> > since
> >>> > it gives you unrestricted access to the kernel.
> >>>
> >>> bpf, in certain contexts, gives you unrestricted access to *reading*
> >>> kernel memory.  bpf should, under no circumstances, let you write to
> >>> the kernel unless you're using fault injection or similar.
> >>>
> >>> I'm surprised that Alexei acked this patch.  If something like XDP or
> >>> bpfilter starts becoming widely used, this patch will require a lot of
> >>> reworking to avoid breaking standard distros.
> >>
> >> my understanding was that this lockdown set attemps to disallow _reads_
> >> of kernel memory from anything, so first version of patch was adding
> >> run-time checks for bpf_probe_read() which is no-go
> >> and without this helper the bpf for tracing is losing a lot of its power,
> >> so the easiest is to disable it all.
> >
> > Fair enough.
> 
> Actually looking at the patch again:
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=78bb0059c3b8304a8d124b55feebc780fb3e0500
> 

The bpf is totally disabled in this patch.

> If the only thing that folks are paranoid about is reading
> arbitrary kernel memory with bpf_probe_read() helper
> then preferred patch would be to disable it during verification
> when in lockdown mode

Sorry for I didn't fully understand your idea...
Do you mean that using bpf verifier to filter out bpf program that
uses bpf_probe_read()?
.
> No run-time overhead and android folks will be happy
> that lockdown doesn't break their work.
> They converted out-of-tree networking accounting
> module and corresponding user daemon to use bpf:
> https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf

Thanks
Joey Lee

Re: [GIT PULL] Kernel lockdown for secure boot

[Pavel Machek]

On Tue 2018-04-03 21:08:54, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds
> 
> wrote:
> 
> > On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett  wrote:
> > >
> > >> .. maybe you don't *want* secure boot, but it's been pushed in your
> > >> face by people with an agenda?
> > >
> > > Then turn it off, or build a self-signed kernel that doesn't do this?
> 
> > Umm. So you asked a question, and then when you got an answer you said
> > "don't do that then".
> 
> > The fact is, some hardware pushes secure boot pretty hard. That has
> > *nothing* to do with some "lockdown" mode.
> 
> Secure Boot ensures that the firmware will only load signed bootloaders. If
> a signed bootloader loads a kernel that's effectively an unsigned
> bootloader, there's no point in using Secure Boot - you should just turn it
> off instead, because it's not giving you any meaningful
> security. Andy's

Not true.

I have kernel with printk() enabled. Yes, once userland is started,
you can boot another kernel, maybe.

Maybe my kernel is locked down with exception of kexec, and it does
printk(KERN_CRIT "kexecing") followed by mdelay(5000). That's pretty
good security.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

RE: Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[Wang, Dongsheng]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, April 05, 2018 2:57 AM
> To: Lorenzo Pieralisi ; Wang, Dongsheng
> 
> Cc: r...@rjwysocki.net; gre...@linuxfoundation.org; hanjun@linaro.org;
> sudeep.ho...@arm.com; Zheng, Joey ;
> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [此邮件可能存在风险] Re: [RFC PATCH 2/2] ACPI/IORT: use
> swiotlb_dma_ops when smmu probe failed
> 
> On 04/04/18 17:01, Lorenzo Pieralisi wrote:
> > [+cc Robin]
> >
> > On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote:
> >> If SMMU probe failed, master should use swiotlb as dma ops.
> >> SMMU may probe failed with specified environment, so there
> >> are not any iommu resources in iommu_device_list.
> >>
> >> The master will always get EPROBE_DEFER from really_probe
> >> (dma_configure) but in fact SMMU has probe failed. The issue
> >> causes all of masters failed to be driven.
> 
> Let's just take a step back - why is SMMU probe failing? That seems to
> be the primary issue here, because it implies that either your hardware,
> firmware or kernel is broken, any of which would make boot failure
> somewhat unsurprising anyway.
> 
It's actually not a hardware issue. This is my test case, just return
-EINVAL in arm_smmu_device_probe. The HW probe(arm_smmu_device_hw_probe)
is just part of SMMU driver probe and the failure may be caused by SW. So
I design this case, just make sure even if SMMU probe failed that cause by SW,
the MASTER also can work. _Because of our SMMU default mode is bypass._


> > I added Robin to pick his brain. An alternative would consist
> > in using a bus notifier to prevent deferred probing once the SMMU
> > driver probing failed but that seems backwards given that a major
> > reason to move to deferred probing was to remove the bus notifiers
> > dependency in the first place.
> >
> > It seems to me this is both an OF/ACPI issue - it is not an IORT
> > only problem.
> 
> Yes, this is just an instance of the general probe-deferral problem,
> e.g. once you have multiple dependencies it's possible to end up in a
> stalemate where everything including the IOMMU ends up on the deferred
> probe list with nothing to kick it and make progress again.
> 
> Furthermore it seems to me that the whole premise in this patch is
> flawed,
Ditto. :)


> since even genuine probe failure may well be transient - just
> because one attempt failed doesn't mean a later attempt can't succeed.
> Thus "the most recent probe attempt failed" cannot be considered a
> fundamentally different state from "no driver is currently bound".
> 
Agree, the genuine probe failure may well be transient. But there is
depend on SMMU probe(IOMMU instance) status. There are two situations:

1. MASTER probing, SMMU doesn't probe yet.
This case will match "the transient failure".
really_probe get an EPROBE_DEFER from IORT and the MASTER probe will be
delayed until SMMU probe successful.
2. MASTER probing, SMMU probe has failed.
really_probe will always get an EPROBE_DEFER from IORT, because kernel
has build in SMMU driver.(iort_iommu_driver_enabled) And the master
never cannot do probe.

The case 2 is I want to handle.

Cheers,
-Dongsheng

> Robin.
> 
> >
> > Lorenzo
> >
> >> Signed-off-by: Wang Dongsheng 
> >> ---
> >>   drivers/acpi/arm64/iort.c | 39
> +--
> >>   1 file changed, 33 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >> index e2f7bdd..a6f4c27 100644
> >> --- a/drivers/acpi/arm64/iort.c
> >> +++ b/drivers/acpi/arm64/iort.c
> >> @@ -774,17 +774,45 @@ static int arm_smmu_iort_xlate(struct device
> *dev, u32 streamid,
> >>return ret;
> >>   }
> >>
> >> -static inline bool iort_iommu_driver_enabled(u8 type)
> >> +static int iort_check_dev_dl_status(struct device *dev, void *data)
> >>   {
> >> +  struct fwnode_handle *fwnode = data;
> >> +
> >> +  if (dev->fwnode != fwnode)
> >> +  return 0;
> >> +
> >> +  if (dev->links.status == DL_DEV_PROBE_FAILED)
> >> +  return -ENODEV;
> >> +
> >> +  return -EPROBE_DEFER;
> >> +}
> >> +
> >> +static int iort_iommu_driver_enabled(u8 type, struct fwnode_handle
> *fwnode)
> >> +{
> >> +  bool buildin;
> >> +  int ret;
> >> +
> >>switch (type) {
> >>case ACPI_IORT_NODE_SMMU_V3:
> >> -  return IS_BUILTIN(CONFIG_ARM_SMMU_V3);
> >> +  buildin = IS_BUILTIN(CONFIG_ARM_SMMU_V3);
> >> +  break;
> >>case ACPI_IORT_NODE_SMMU:
> >> -  return IS_BUILTIN(CONFIG_ARM_SMMU);
> >> +  buildin = IS_BUILTIN(CONFIG_ARM_SMMU);
> >> +  break;
> >>default:
> >>pr_warn("IORT node type %u does not describe an SMMU\n",
> type);
> >> -  return false;
> >> +  buildin = false;
> >>}
> >> +
> >> +  if (!buildin)
> >> +  return -ENODEV;
> >> +
> >> +  ret = bus_for_each_dev(&platform_bus_type, NULL, fwnode

[PATCH] f2fs: set deadline to drop expired inmem pages

[Chao Yu]

f2fs doesn't allow abuse on atomic write class interface, so except
limiting in-mem pages' total memory usage capacity, we need to limit
start-commit time as well, otherwise we may run into infinite loop
during foreground GC because target blocks in victim segment are
belong to atomic opened file for long time.

Now, we will check the condition with f2fs_balance_fs_bg in
background threads, once if user doesn't commit data exceeding 30
seconds, we will drop all cached data, so I expect it can keep our
system running safely to prevent Dos attack.

Signed-off-by: Chao Yu 
---
 fs/f2fs/f2fs.h|  2 ++
 fs/f2fs/segment.c | 40 
 fs/f2fs/segment.h |  2 ++
 fs/f2fs/super.c   |  1 +
 4 files changed, 45 insertions(+)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 1725b82d9fb2..5b617231970b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -653,6 +653,7 @@ struct f2fs_inode_info {
struct list_head dirty_list;/* dirty list for dirs and files */
struct list_head gdirty_list;   /* linked in global dirty list */
struct list_head inmem_ilist;   /* list for inmem inodes */
+   struct timespec inmem_time; /* atomic write start time */
struct list_head inmem_pages;   /* inmemory pages managed by f2fs */
struct task_struct *inmem_task; /* store inmemory task */
struct mutex inmem_lock;/* lock for inmemory pages */
@@ -2859,6 +2860,7 @@ void destroy_node_manager_caches(void);
 bool need_SSR(struct f2fs_sb_info *sbi);
 void register_inmem_page(struct inode *inode, struct page *page);
 void drop_inmem_pages_all(struct f2fs_sb_info *sbi);
+void drop_inmem_pages_exceed_time(struct f2fs_sb_info *sbi);
 void drop_inmem_pages(struct inode *inode);
 void drop_inmem_page(struct inode *inode, struct page *page);
 int commit_inmem_pages(struct inode *inode);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index e61faff9b109..8a558f038f9f 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -208,6 +208,8 @@ void register_inmem_page(struct inode *inode, struct page 
*page)
spin_lock(&sbi->inode_lock[ATOMIC_FILE]);
if (list_empty(&fi->inmem_ilist))
list_add_tail(&fi->inmem_ilist, &sbi->inode_list[ATOMIC_FILE]);
+   if (!timespec_valid(&fi->inmem_time))
+   fi->inmem_time = current_kernel_time();
spin_unlock(&sbi->inode_lock[ATOMIC_FILE]);
inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
mutex_unlock(&fi->inmem_lock);
@@ -295,6 +297,36 @@ void drop_inmem_pages_all(struct f2fs_sb_info *sbi)
goto next;
 }
 
+void drop_inmem_pages_exceed_time(struct f2fs_sb_info *sbi)
+{
+   struct list_head *head = &sbi->inode_list[ATOMIC_FILE];
+   struct inode *inode;
+   struct f2fs_inode_info *fi, *tmp;
+
+next:
+   inode = NULL;
+
+   spin_lock(&sbi->inode_lock[ATOMIC_FILE]);
+   list_for_each_entry_safe(fi, tmp, head, inmem_ilist) {
+   struct timespec ts = current_kernel_time();
+
+   ts.tv_sec -= DEF_ATOMIC_COMMIT_INTERVAL;
+   if (timespec_compare(&fi->inmem_time, &ts) >= 0)
+   continue;
+   inode = igrab(&fi->vfs_inode);
+   break;
+   }
+   spin_unlock(&sbi->inode_lock[ATOMIC_FILE]);
+
+   if (inode) {
+   f2fs_msg(sbi->sb, KERN_WARNING,
+   "drop inmem pages of inode (ino:%lu)", inode->i_ino);
+   drop_inmem_pages(inode);
+   iput(inode);
+   goto next;
+   }
+}
+
 void drop_inmem_pages(struct inode *inode)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
@@ -306,6 +338,9 @@ void drop_inmem_pages(struct inode *inode)
if (!list_empty(&fi->inmem_ilist))
list_del_init(&fi->inmem_ilist);
spin_unlock(&sbi->inode_lock[ATOMIC_FILE]);
+
+   fi->inmem_time.tv_sec = -1;
+
mutex_unlock(&fi->inmem_lock);
 
clear_inode_flag(inode, FI_ATOMIC_FILE);
@@ -441,6 +476,9 @@ int commit_inmem_pages(struct inode *inode)
if (!list_empty(&fi->inmem_ilist))
list_del_init(&fi->inmem_ilist);
spin_unlock(&sbi->inode_lock[ATOMIC_FILE]);
+
+   fi->inmem_time.tv_sec = -1;
+
mutex_unlock(&fi->inmem_lock);
 
clear_inode_flag(inode, FI_ATOMIC_COMMIT);
@@ -491,6 +529,8 @@ void f2fs_balance_fs_bg(struct f2fs_sb_info *sbi)
else
build_free_nids(sbi, false, false);
 
+   drop_inmem_pages_exceed_time(sbi);
+
if (!is_idle(sbi) && !excess_dirty_nats(sbi))
return;
 
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 3325d0769723..f5410dcb76b4 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -215,6 +215,8 @@ struct segment_allocation {
 #define IS_DUMMY_WRITTEN_PAGE(page)\
(page_private(page) == (unsigned long)DUMMY_WRITTEN_PAGE)
 
+#define DEF_ATOMIC_COMMIT_INTERVAL 30
+
 struct

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

[Baoquan He]

On 04/06/18 at 07:50am, Dave Hansen wrote:
> I'm having a really hard time tying all the pieces back together.  Let
> me give it a shot and you can tell me where I go wrong.
> 
> On 02/27/2018 07:26 PM, Baoquan He wrote:
> > In sparse_init(), two temporary pointer arrays, usemap_map and map_map
> > are allocated with the size of NR_MEM_SECTIONS.
> 
> In sparse_init(), two temporary pointer arrays, usemap_map and map_map
> are allocated to hold the maps for every possible memory section
> (NR_MEM_SECTIONS).  However, we obviously only need the array sized for
> nr_present_sections (introduced in patch 1).

Yes, correct.

> 
> The reason this is a problem is that, with 5-level paging,
> NR_MEM_SECTIONS (8M->512M) went up dramatically and these temporary
> arrays can eat all of memory, like on kdump kernels.

With 5-level paging enabled, MAX_PHYSMEM_BITS changed from 46 to
52. You can see NR_MEM_SECTIONS becomes 64 times of the old value. So
the two temporary pointer arrays eat more memory, 8M -> 8M*64 = 512M.

# define MAX_PHYSMEM_BITS   (pgtable_l5_enabled ? 52 : 46)

> 
> This patch does two things: it makes sure to give usemap_map/mem_map a
> less gluttonous size on small systems, and it changes the map allocation
> and handling to handle the now more compact, less sparse arrays.

Yes, because 99.9% of systems do not have PB level of memory, not even TB.
Any place of memory allocatin with the size of NR_MEM_SECTIONS should be
avoided.

> 
> ---
> 
> The code looks fine to me.  It's a bit of a shame that there's no
> verification to ensure that idx_present never goes beyond the shiny new
> nr_present_sections. 

This is a good point. Do you think it's OK to replace (section_nr <
NR_MEM_SECTIONS) with (section_nr < nr_present_sections) in below
for_each macro? This for_each_present_section_nr() is only used
during sparse_init() execution.

#define for_each_present_section_nr(start, section_nr)  \
for (section_nr = next_present_section_nr(start-1); \
 ((section_nr >= 0) &&  \
  (section_nr < NR_MEM_SECTIONS) && \   
  
  (section_nr <= __highest_present_section_nr));\
 section_nr = next_present_section_nr(section_nr))

> 
> 
> > @@ -583,6 +592,7 @@ void __init sparse_init(void)
> > unsigned long *usemap;
> > unsigned long **usemap_map;
> > int size;
> > +   int idx_present = 0;
> 
> I wonder whether idx_present is a good name.  Isn't it the number of
> consumed mem_map[]s or usemaps?

Yeah, in sparse_init(), it's the index of present memory sections, and
also the number of consumed mem_map[]s or usemaps. And I remember you
suggested nr_consumed_maps instead. seems nr_consumed_maps is a little
long to index array to make code line longer than 80 chars. How about
name it idx_present in sparse_init(), nr_consumed_maps in
alloc_usemap_and_memmap(), the maps allocation function? I am also fine
to use nr_consumed_maps for all of them.

> 
> > 
> > if (!map) {
> > ms->section_mem_map = 0;
> > +   idx_present++;
> > continue;
> > }
> >  
> 
> 
> This hunk seems logically odd to me.  I would expect a non-used section
> to *not* consume an entry from the temporary array.  Why does it?  The
> error and success paths seem to do the same thing.

Yes, this place is the hardest to understand. The temorary arrays are
allocated beforehand with the size of 'nr_present_sections'. The error
paths you mentioned is caused by allocation failure of mem_map or
map_map, but whatever it's error or success paths, the sections must be
marked as present in memory_present(). Error or success paths happened
in alloc_usemap_and_memmap(), while checking if it's erorr or success
paths happened in the last for_each_present_section_nr() of
sparse_init(), and clear the ms->section_mem_map if it goes along error
paths. This is the key point of this new allocation way.

Thanks
Baoquan

Re: [PATCH v9 07/10] time: hrtimer: Introduce hrtimer_next_event_without()

[Rafael J. Wysocki]

On Saturday, April 7, 2018 4:46:38 PM CEST Frederic Weisbecker wrote:
> On Wed, Apr 04, 2018 at 10:45:39AM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > The next set of changes will need to compute the time to the next
> > hrtimer event over all hrtimers except for the scheduler tick one.
> > 
> > To that end introduce a new helper function,
> > hrtimer_next_event_without(), for computing the time until the next
> > hrtimer event over all timers except for one and modify the underlying
> > code in __hrtimer_next_event_base() to prepare it for being called by
> > that new function.
> > 
> > No intentional changes in functionality.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > v8 -> v9:
> >  * Make fewer changes to the existing code.
> >  * Add a new helper function for the handling of the use case at hand.
> > 
> > ---
> >  include/linux/hrtimer.h |1 
> >  kernel/time/hrtimer.c   |   55 
> > ++--
> >  2 files changed, 54 insertions(+), 2 deletions(-)
> > 
> > Index: linux-pm/include/linux/hrtimer.h
> > ===
> > --- linux-pm.orig/include/linux/hrtimer.h
> > +++ linux-pm/include/linux/hrtimer.h
> > @@ -426,6 +426,7 @@ static inline ktime_t hrtimer_get_remain
> >  }
> >  
> >  extern u64 hrtimer_get_next_event(void);
> > +extern u64 hrtimer_next_event_without(const struct hrtimer *exclude);
> >  
> >  extern bool hrtimer_active(const struct hrtimer *timer);
> >  
> > Index: linux-pm/kernel/time/hrtimer.c
> > ===
> > --- linux-pm.orig/kernel/time/hrtimer.c
> > +++ linux-pm/kernel/time/hrtimer.c
> > @@ -490,6 +490,7 @@ __next_base(struct hrtimer_cpu_base *cpu
> > while ((base = __next_base((cpu_base), &(active
> >  
> >  static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base,
> > +const struct hrtimer *exclude,
> >  unsigned int active,
> >  ktime_t expires_next)
> >  {
> > @@ -502,9 +503,24 @@ static ktime_t __hrtimer_next_event_base
> >  
> > next = timerqueue_getnext(&base->active);
> > timer = container_of(next, struct hrtimer, node);
> > +   if (timer == exclude) {
> > +   /* Get to the next timer in the queue. */
> > +   struct rb_node *rbn = rb_next(&next->node);
> > +
> > +   next = rb_entry_safe(rbn, struct timerqueue_node, node);
> > +   if (!next)
> > +   continue;
> 
> Minor cosmectic detail again, timerqueue_iterate_next() would do the job and
> avoid browsing timerqueue details.

And below is a patch to make this change on top of the original.

---
From: Rafael J. Wysocki 
Subject: [PATCH] time: hrtimer: Use timerqueue_iterate_next() to get to the 
next timer

Use timerqueue_iterate_next() to get to the next timer in
__hrtimer_next_event_base() without browsing the timerqueue
details diredctly.

No intentional changes in functionality.

Suggested-by: Frederic Weisbecker 
Signed-off-by: Rafael J. Wysocki 
---
 kernel/time/hrtimer.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Index: linux-pm/kernel/time/hrtimer.c
===
--- linux-pm.orig/kernel/time/hrtimer.c
+++ linux-pm/kernel/time/hrtimer.c
@@ -505,9 +505,7 @@ static ktime_t __hrtimer_next_event_base
timer = container_of(next, struct hrtimer, node);
if (timer == exclude) {
/* Get to the next timer in the queue. */
-   struct rb_node *rbn = rb_next(&next->node);
-
-   next = rb_entry_safe(rbn, struct timerqueue_node, node);
+   next = timerqueue_iterate_next(next);
if (!next)
continue;
 

Re: [GIT PULL] Kernel lockdown for secure boot

[Pavel Machek]

On Wed 2018-04-04 00:39:05, David Howells wrote:
> Linus Torvalds  wrote:
> 
> > The same thing is true of some lockdown patch. Maybe it's a good thing
> > in general. But whether it's a good thing is _entirely_ independent of
> > any secure boot issue. I can see using secure boot without it, but I
> > can very much also see using lockdown without secure boot.
> > 
> > The two things are simply entirely orthogonal. They have _zero_
> > overlap. I'm not seeing why they'd be linked at all in any way.
> 
> I'm not sure I agree.  Here's my reasoning:
> 
>  (1) Lockdown mode really needs to activated during kernel boot, before
>  userspace has a chance to run, otherwise there's a window of opportunity
>  in which the kernel *isn't* locked down.
> 
>  (2) If the kernel isn't booted in secure boot mode, then there's the
>  opportunity to tamper before the kernel even starts booting.
> 
>  (3) There doesn't seem any point in booting in secure boot mode if you don't
>  protect the running kernel image against tampering.  What does it mean to
>  be in "secure boot mode" in that case?  If the kernel can be tampered
>  with, it would seem to be, by definition, insecure.

This one is not true, either.

If kernel does "printk(KERN_CRIT "loading unsigned module");
mdelay(1);", it is useful for secure boot and provides way to
owner to play.

Nokia N9 / N950 uses this kind of "security" for example. It is rather
annoying but better than not being able to run custom kernels at all.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

答复: [PATCH] mmc: dw_mmc-k3: Fix DDR52 mode by setting required clock divisor

[liwei (CM)]

+jinguojun jingbing

-邮件原件-
发件人: Shawn Lin [mailto:shawn@rock-chips.com] 
发送时间: 2018年4月8日 9:52
收件人: Ryan Grachek
抄送: shawn@rock-chips.com; Jaehoon Chung; Ulf Hansson; 
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Zhangfei Gao; liwei 
(CM); Suzhuangluan
主题: Re: [PATCH] mmc: dw_mmc-k3: Fix DDR52 mode by setting required clock divisor

On 2018/4/6 21:41, Ryan Grachek wrote:
> On Wed, Apr 4, 2018 at 7:51 PM, Shawn Lin  wrote:
>> [+ Zhangfei Gao who added support for hi6220]
>>
>> On 2018/4/4 23:31, Ryan Grachek wrote:
>>>
>>> On Tue, Apr 3, 2018 at 6:31 AM, Shawn Lin >> > wrote:
>>>
>>>  On 2018/3/30 2:24, oscardagrach wrote:
>>>
>>>  Need at least one line commit body.
>>>
>>>  Signed-off-by: oscardagrach >> >
>>>
>>>  ---
>>> drivers/mmc/host/dw_mmc-k3.c | 10 --
>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>>  diff --git a/drivers/mmc/host/dw_mmc-k3.c
>>>  b/drivers/mmc/host/dw_mmc-k3.c
>>>  index 89cdb3d533bb..efc546cb4db8 100644
>>>  --- a/drivers/mmc/host/dw_mmc-k3.c
>>>  +++ b/drivers/mmc/host/dw_mmc-k3.c
>>>  @@ -194,8 +194,14 @@ static void dw_mci_hi6220_set_ios(struct
>>>  dw_mci *host, struct mmc_ios *ios)
>>>   int ret;
>>>   unsigned int clock;
>>> - clock = (ios->clock <= 2500) ? 2500 : ios->clock;
>>>  -
>>>  +   /* CLKDIV must be 1 for DDR52/8-bit mode */
>>>  +   if (ios->bus_width == MMC_BUS_WIDTH_8 &&
>>>  +   ios->timing == MMC_TIMING_MMC_DDR52) {
>>>  +   mci_writel(host, CLKDIV, 0x1);
>>>  +   clock = ios->clock;
>>>  +   } else {
>>>  +   clock = (ios->clock <= 2500) ? 2500 :
>>>  ios->clock;
>>>  +   }
>>>
>>>
>>>  I undertand DDR52/8-bit need CLKDIV fixed 1, but shouldn't the 
>>> following
>>>  change is more sensible?
>>>
>>>  if (ios->bus_width == MMC_BUS_WIDTH_8 && ios->timing ==
>>>  MMC_TIMING_MMC_DDR52)
>>>   clock = ios->clock * 2;
>>>  else
>>>   clock = (ios->clock <= 2500) ? 2500 : 
>>> ios->clock;
>>>
>>>
>>>  The reason is ios->clock is 52MHz and you could claim 104MHz from the
>>>  clock provider and let dw_mmc core take care of the divder to be 1.
>>>  Otherwise, you just force it to be DDR52/8-bit with a clk rate 
>>> of 26MHz.
>>>
>>>
>>>   ret = clk_set_rate(host->biu_clk, clock);
>>>   if (ret)
>>>   dev_warn(host->dev, "failed to set rate
>>>  %uHz\n", clock);
>>>
>>>
>>>
>>
>> For future wise, please use plain mode mail, but not HTML format.
>>
>>> Your feedback is correct. I see the Rockchip dwmmc driver has a 
>>> similar implementation. After applying your suggested changes, 
>>> however, my board reports "dwmmc_k3 f723d000.dwmmc0: failed to set rate 
>>> 10400Hz"
>>> during intialization of eMMC. In addition, I do not see CLKDIV being 
>>> set to 1. clk_set_rate fails and I wonder if this is out-of-scope of 
>>> the driver.
>>>
>>> If I set CLKDIV where I did prior, with your changes, the device 
>>> fails to set the clock and falls back to 52 MHz (26 MHz) and works 
>>> fine, but again, CLKDIV is reported as 0 (even though it is 1.) One 
>>> thing of interest to note is when I manually set the clock by doing:
>>> (echo 10400 > /sys/kernel/debug/mmc0/clock) the device reports 
>>> back 'mmc_host mmc0: Bus speed (slot 0) = 19840Hz (slot req 10400Hz,
>>>actual 9920HZ div = 1)' which works reliably and clk_set_rate 
>>> does not report any error.
>>>
>>
>> When looking closely into the code, at least dw_mci_hi6220_set_ios 
>> goes wrong with the bus_hz, since it should be ciu_clk but not biu_clk.
>> "b" stands for bus, and "c" stands for card IMHO, however bus_hz 
>> describs the clock to the card, provided by controller. Does the 
>> following patch help?
>>
>>
>> diff --git a/drivers/mmc/host/dw_mmc-k3.c 
>> b/drivers/mmc/host/dw_mmc-k3.c index 89cdb3d..9e78cf2 100644
>> --- a/drivers/mmc/host/dw_mmc-k3.c
>> +++ b/drivers/mmc/host/dw_mmc-k3.c
>> @@ -194,13 +194,21 @@ static void dw_mci_hi6220_set_ios(struct dw_mci 
>> *host, struct mmc_ios *ios)
>>  int ret;
>>  unsigned int clock;
>>
>> -   clock = (ios->clock <= 2500) ? 2500 : ios->clock;
>> +   if (ios->bus_width == MMC_BUS_WIDTH_8 &&
>> +   ios->timing == MMC_TIMING_MMC_DDR52)
>> +   clock = ios->clock * 2;
>> +   else
>> +   clock = (ios->clock <= 2500) ? 2500 : 
>> + ios->clock;
>>
>> -   ret = clk_set_rate(host->biu_clk, clock);
>> +   ret = clk_set_rate(host->ciu_clk, clock);
>>  if (ret)
>>  dev_warn(host->dev, "failed to set rate %uHz\n", 

[PATCH] MIPS: lantiq: gphy: Drop reboot/remove reset asserts

[Mathias Kresin]

While doing a global software reset, these bits are not cleared and let
some bootloader fail to initialise the GPHYs. The bootloader don't
expect the GPHYs in reset, as they aren't during power on.

The asserts were a workaround for a wrong syscon-reboot mask. With a
mask set which includes the GPHY resets, these resets aren't required
any more.

Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU 
syscon-mfd")
Cc: sta...@vger.kernel.org # 4.14+
Signed-off-by: Mathias Kresin 
---
 drivers/soc/lantiq/gphy.c | 34 --
 1 file changed, 34 deletions(-)

diff --git a/drivers/soc/lantiq/gphy.c b/drivers/soc/lantiq/gphy.c
index 8d86594..8c31ae7 100644
--- a/drivers/soc/lantiq/gphy.c
+++ b/drivers/soc/lantiq/gphy.c
@@ -30,7 +30,6 @@ struct xway_gphy_priv {
struct clk *gphy_clk_gate;
struct reset_control *gphy_reset;
struct reset_control *gphy_reset2;
-   struct notifier_block gphy_reboot_nb;
void __iomem *membase;
char *fw_name;
 };
@@ -64,24 +63,6 @@ static const struct of_device_id xway_gphy_match[] = {
 };
 MODULE_DEVICE_TABLE(of, xway_gphy_match);
 
-static struct xway_gphy_priv *to_xway_gphy_priv(struct notifier_block *nb)
-{
-   return container_of(nb, struct xway_gphy_priv, gphy_reboot_nb);
-}
-
-static int xway_gphy_reboot_notify(struct notifier_block *reboot_nb,
-  unsigned long code, void *unused)
-{
-   struct xway_gphy_priv *priv = to_xway_gphy_priv(reboot_nb);
-
-   if (priv) {
-   reset_control_assert(priv->gphy_reset);
-   reset_control_assert(priv->gphy_reset2);
-   }
-
-   return NOTIFY_DONE;
-}
-
 static int xway_gphy_load(struct device *dev, struct xway_gphy_priv *priv,
  dma_addr_t *dev_addr)
 {
@@ -205,14 +186,6 @@ static int xway_gphy_probe(struct platform_device *pdev)
reset_control_deassert(priv->gphy_reset);
reset_control_deassert(priv->gphy_reset2);
 
-   /* assert the gphy reset because it can hang after a reboot: */
-   priv->gphy_reboot_nb.notifier_call = xway_gphy_reboot_notify;
-   priv->gphy_reboot_nb.priority = -1;
-
-   ret = register_reboot_notifier(&priv->gphy_reboot_nb);
-   if (ret)
-   dev_warn(dev, "Failed to register reboot notifier\n");
-
platform_set_drvdata(pdev, priv);
 
return ret;
@@ -224,17 +197,10 @@ static int xway_gphy_remove(struct platform_device *pdev)
struct xway_gphy_priv *priv = platform_get_drvdata(pdev);
int ret;
 
-   reset_control_assert(priv->gphy_reset);
-   reset_control_assert(priv->gphy_reset2);
-
iowrite32be(0, priv->membase);
 
clk_disable_unprepare(priv->gphy_clk_gate);
 
-   ret = unregister_reboot_notifier(&priv->gphy_reboot_nb);
-   if (ret)
-   dev_warn(dev, "Failed to unregister reboot notifier\n");
-
return 0;
 }
 
-- 
2.7.4

Re: [PATCH 0/3] syscalls: clean up stub naming convention

[Ingo Molnar]

* Dominik Brodowski  wrote:

> In short (0x prefix removed, re-ordered):
> 
> 810f0af0 tkernel_waitid   # common (32/64) kernel helper
> 
> __in_sys_waitid   # inlined helper doing actual work
> 810f0be0 t  __do_sys_waitid   # C func calling inlined helper
> 
>  __in_compat_sys_waitid   # inlined helper doing actual work
> 810f0d80 t   __do_compat_sys_waitid   # compat C func calling inlined helper
> 
> 810f2080 T __x64_sys_waitid   # x64 64-bit-ptregs -> C stub
> 810f20b0 T__ia32_sys_waitid   # ia32 32-bit-ptregs -> C stub [unused]
> 810f2470 T __ia32_compat_sys_waitid   # ia32 32-bit-ptregs -> compat C stub
> 810f2490 T  __x32_compat_sys_waitid   # x32 64-bit-ptregs -> compat C stub

Ok, looks pretty clean and nice to me all around, and looking at the highest 
level 
syscall tables the actual calling convention and address encoding is now a 
_lot_ 
more obvious at first sight as well.

The "in" part is a tiny bit confusing because it reads like a preposition:
"are we in sys_waitid?".

But I have no better idea, other than we could perhaps use more underscores to 
signal the inline helper, instead of the 'in_' prefix:

> 810f0af0 tkernel_waitid   # common (32/64) kernel helper
> 
> _sys_waitid   # inlined helper doing actual work
> 810f0be0 t  __do_sys_waitid   # C func calling inlined helper
> 
>  _compat_sys_waitid   # inlined helper doing actual work
> 810f0d80 t   __do_compat_sys_waitid   # compat C func calling inlined helper
> 
> 810f2080 T __x64_sys_waitid   # x64 64-bit-ptregs -> C stub
> 810f20b0 T__ia32_sys_waitid   # ia32 32-bit-ptregs -> C stub [unused]
> 810f2470 T __ia32_compat_sys_waitid   # ia32 32-bit-ptregs -> compat C stub
> 810f2490 T  __x32_compat_sys_waitid   # x32 64-bit-ptregs -> compat C stub

?

There are some other variants as well, here's the list of all the options I 
could 
think of:

  - _sys_waitid()  # ridiculous number of underscores?
  - __sys_waitid() # too generic sounding?
  - __inline_sys_waitid()  # too long?
  - __il_sys_waitid()  # reminds me of the IL country code ;-)
  - __in_sys_waitid()  # easy to read as 'are we in syscall?'

None is super convinging - but maybe __inline_sys_waitid is the most natural 
one.

[ Note, whichever we pick (if we pick a new one), there no need to resend, I 
can 
  edit the patches in place if you agree. ]

One more fundamental question: why do we have the __do_sys_waitid() and 
__inline_sys_waitid() distinction - aren't the function call signatures the 
same 
with no conversion done?

I.e. couldn't we just do a single, static __do_sys_waitid(), where the compiler 
would decide to what extent inlining is justified? This would allow the 
compiler 
to inline all the intermediate code into the stubs themselves.

Or is this a side effect of the error injection feature, which needs to add 
extra 
logic at this intermediate level? That too should be able to use the 
__do_sys_waitid() variant though.

> The kbuild test robot barked at an alleged +20038 bytes kernel size regression
> for i386-tinyconfig due to the first patch of this series. That seems to be a
> false positive, as it likely doesn't take into account the change to
> scripts/bloat-o-meter. Moreover, I could not reproduce such a size regression
> on local i386 builds.

Ok, I'll ignore that.

Is UML unaffected by these renames?

Thanks,

Ingo

[PATCH] ACPI: prefer bool over int for predicates

[Joey Pabalinas]

Prefer bool over int for variables / returns which are
predicate expressions to make it explicit that these
expressions are evaluating simple "yes or no?" queries.

This makes it more obvious which expressions are _not_
that simple and require more attention, e.g. an `int ret`
meant to hold 0 or -ENOENT as a return value or an
`unsigned nmemb` meant to refer to the number of valid
members in some arbitrary array.

Change relevant variable / return types from int to bool and
prefer a true / false value for predicate expressions versus
a plain 1 / 0 value.

Signed-off-by: Joey Pabalinas 

 drivers/acpi/battery.c  |  4 ++--
 drivers/acpi/ec.c   | 20 +---
 drivers/acpi/pci_root.c | 17 ++---
 drivers/acpi/scan.c |  6 +++---
 include/acpi/acpi_bus.h |  2 +-
 5 files changed, 21 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index bdb24d636d9acc9c1a..f1a5fb5252969f0478 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1416,7 +1416,7 @@ static int acpi_battery_add(struct acpi_device *device)
battery->pm_nb.notifier_call = battery_notify;
register_pm_notifier(&battery->pm_nb);
 
-   device_init_wakeup(&device->dev, 1);
+   device_init_wakeup(&device->dev, true);
 
return result;
 
@@ -1434,7 +1434,7 @@ static int acpi_battery_remove(struct acpi_device *device)
 
if (!device || !acpi_driver_data(device))
return -EINVAL;
-   device_init_wakeup(&device->dev, 0);
+   device_init_wakeup(&device->dev, false);
battery = acpi_driver_data(device);
unregister_pm_notifier(&battery->pm_nb);
 #ifdef CONFIG_ACPI_PROCFS_POWER
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 30a5729565575f83cb..d4a564ab9cdd53046c 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -350,7 +350,7 @@ static inline bool acpi_ec_is_gpe_raised(struct acpi_ec *ec)
acpi_event_status gpe_status = 0;
 
(void)acpi_get_gpe_status(NULL, ec->gpe, &gpe_status);
-   return (gpe_status & ACPI_EVENT_FLAG_STATUS_SET) ? true : false;
+   return gpe_status & ACPI_EVENT_FLAG_STATUS_SET;
 }
 
 static inline void acpi_ec_enable_gpe(struct acpi_ec *ec, bool open)
@@ -580,28 +580,26 @@ static bool acpi_ec_guard_event(struct acpi_ec *ec)
return guarded;
 }
 
-static int ec_transaction_polled(struct acpi_ec *ec)
+static bool ec_transaction_polled(struct acpi_ec *ec)
 {
unsigned long flags;
-   int ret = 0;
+   bool polled;
 
spin_lock_irqsave(&ec->lock, flags);
-   if (ec->curr && (ec->curr->flags & ACPI_EC_COMMAND_POLL))
-   ret = 1;
+   polled = ec->curr && (ec->curr->flags & ACPI_EC_COMMAND_POLL);
spin_unlock_irqrestore(&ec->lock, flags);
-   return ret;
+   return polled;
 }
 
-static int ec_transaction_completed(struct acpi_ec *ec)
+static bool ec_transaction_completed(struct acpi_ec *ec)
 {
unsigned long flags;
-   int ret = 0;
+   bool completed;
 
spin_lock_irqsave(&ec->lock, flags);
-   if (ec->curr && (ec->curr->flags & ACPI_EC_COMMAND_COMPLETE))
-   ret = 1;
+   completed = ec->curr && (ec->curr->flags & ACPI_EC_COMMAND_COMPLETE);
spin_unlock_irqrestore(&ec->lock, flags);
-   return ret;
+   return completed;
 }
 
 static inline void ec_transaction_transition(struct acpi_ec *ec, unsigned long 
flag)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 6fc204a524932e97f4..61c0c079cff346e492 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -81,20 +81,15 @@ static DEFINE_MUTEX(osc_lock);
  * Note: we could make this API take a struct acpi_device * instead, but
  * for now, it's more convenient to operate on an acpi_handle.
  */
-int acpi_is_root_bridge(acpi_handle handle)
+bool acpi_is_root_bridge(acpi_handle handle)
 {
-   int ret;
struct acpi_device *device;
 
-   ret = acpi_bus_get_device(handle, &device);
-   if (ret)
-   return 0;
-
-   ret = acpi_match_device_ids(device, root_device_ids);
-   if (ret)
-   return 0;
-   else
-   return 1;
+   if (acpi_bus_get_device(handle, &device))
+   return false;
+   if (acpi_match_device_ids(device, root_device_ids))
+   return false;
+   return true;
 }
 EXPORT_SYMBOL_GPL(acpi_is_root_bridge);
 
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 490498eca0d3db7d6a..8e3d436184104b5799 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -625,7 +625,7 @@ int acpi_device_add(struct acpi_device *device,
 {
int result;
struct acpi_device_bus_id *acpi_device_bus_id, *new_bus_id;
-   int found = 0;
+   bool found = false;
 
if (device->handle) {
acpi_status status;
@@ -667,7 +667,7 @@ int acpi_device_add(struct acpi_device *device,
if (!strcmp(acpi_device_bus_id->bus_i

Re: [PATCH 0/6] Remove several VLAs in the crypto subsystem

[Salvatore Mesoraca]

2018-04-07 21:56 GMT+02:00 Kees Cook :
> On Sat, Apr 7, 2018 at 11:38 AM, Salvatore Mesoraca
>  wrote:
>> As suggested by Laura Abbott[2], I'm resending my patch with
>> MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they
>> can be used in other places.
>> I take this opportuinuty to deal with some other VLAs not
>> handled in the old patch.
>>
>> [1] 
>> http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>> [2] http://lkml.kernel.org/r/4e536889-439a-49e6-dd95-2d4286913...@redhat.com
>>
>> Salvatore Mesoraca (6):
>>   crypto: api - laying macros for statically allocated buffers
>>   crypto: ctr - avoid VLA use
>>   crypto: api - avoid VLA use
>>   crypto: pcbc - avoid VLA use
>>   crypto: cts - avoid VLA use
>>   crypto: cfb - avoid VLA use
>>
>>  crypto/cfb.c  | 14 ++
>>  crypto/cipher.c   |  7 ++-
>>  crypto/ctr.c  | 13 +++--
>>  crypto/cts.c  |  8 ++--
>>  crypto/internal.h |  8 
>>  crypto/pcbc.c |  9 +++--
>>  6 files changed, 48 insertions(+), 11 deletions(-)
>
> These all look good to me! Thanks for the refactoring. :)
>
> Reviewed-by: Kees Cook 

Thank you!

Salvatore

Re: [PATCH 1/6] crypto: api - laying macros for statically allocated buffers

[Salvatore Mesoraca]

2018-04-08 5:15 GMT+02:00 Herbert Xu :
> On Sat, Apr 07, 2018 at 08:38:18PM +0200, Salvatore Mesoraca wrote:
>> Creating 2 new compile-time constants for internal use,
>> in preparation for the removal of VLAs[1] from crypto code.
>> All ciphers implemented in Linux have a block size less than or
>> equal to 16 bytes and the most demanding hw require 16 bytes
>> alignment for the block buffer.
>>
>> [1] 
>> http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>>
>> Signed-off-by: Salvatore Mesoraca 
>> ---
>>  crypto/internal.h | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/crypto/internal.h b/crypto/internal.h
>> index 9a3f399..89ae41e 100644
>> --- a/crypto/internal.h
>> +++ b/crypto/internal.h
>> @@ -26,6 +26,14 @@
>>  #include 
>>  #include 
>>
>> +/*
>> + * Maximum values for blocksize and alignmask, used to allocate
>> + * static buffers that are big enough for any combination of
>> + * ciphers and architectures.
>> + */
>> +#define MAX_BLOCKSIZE16
>> +#define MAX_ALIGNMASK15
>
> No please don't put this here if you intend on using it everywhere.
> This file is reserved for truly internal bits.
>
> Perhaps include/crypto/algapi.h would be a better place.

OK, thank you for the suggestion :)

Salvatore

Re: [PATCH 2/6] crypto: ctr - avoid VLA use

[Salvatore Mesoraca]

018-04-08 5:19 GMT+02:00 Herbert Xu :
> On Sat, Apr 07, 2018 at 08:38:19PM +0200, Salvatore Mesoraca wrote:
>>
>> @@ -206,6 +207,14 @@ static struct crypto_instance *crypto_ctr_alloc(struct 
>> rtattr **tb)
>>   if (alg->cra_blocksize < 4)
>>   goto out_put_alg;
>>
>> + /* Block size must be <= MAX_BLOCKSIZE. */
>> + if (alg->cra_blocksize > MAX_BLOCKSIZE)
>> + goto out_put_alg;
>> +
>> + /* Alignmask must be <= MAX_ALIGNMASK. */
>> + if (alg->cra_alignmask > MAX_ALIGNMASK)
>> + goto out_put_alg;
>> +
>
> Since you're also adding a check to cipher algorithms in general,
> none of these individual checks are needed anymore.

Fair enough.
After removing the individual checks the modification to the single files
will be just a couple of lines, is it OK for you if I collapse all of them in
just a single commit?

Thank you,

Salvatore

[PATCH] slimbus: Fix out-of-bounds access in slim_slicesize()

[Geert Uytterhoeven]

With gcc-4.1.2:

slimbus/messaging.c: In function ‘slim_slicesize’:
slimbus/messaging.c:186: warning: statement with no effect

Indeed, clamp() is a macro not operating in-place, but returning the
clamped value.  Hence the value is not clamped at all, which may lead to
an out-of-bounds access.

Fix this by assigning the clamped value.

Fixes: afbdcc7c384b0d44 ("slimbus: Add messaging APIs to slimbus framework")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/slimbus/messaging.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
index 884419c37e8419c8..457ea1f8db309cb9 100644
--- a/drivers/slimbus/messaging.c
+++ b/drivers/slimbus/messaging.c
@@ -183,7 +183,7 @@ static u16 slim_slicesize(int code)
0, 1, 2, 3, 3, 4, 4, 5, 5, 5, 5, 6, 6, 6, 6, 7
};
 
-   clamp(code, 1, (int)ARRAY_SIZE(sizetocode));
+   code = clamp(code, 1, (int)ARRAY_SIZE(sizetocode));
 
return sizetocode[code - 1];
 }
-- 
2.7.4

Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode

[Pavel Machek]

Hi!

> Commit ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for
> control dlci") added support for DLCI to stay in Asynchronous Disconnected
> Mode (ADM). But we still get long delays waiting for commands to other
> DLCI to complete:
> 
> --> 5) C: SABM(P)
> Q>  0) C: UIH(F)
> Q>  0) C: UIH(F)
> Q>  0) C: UIH(F)
> ...
> 
> This happens because gsm_control_send() sets cretries timer to T2 that is
> by default set to 34. This will cause resend for T2 times for the control
> frame. In ADM mode, we will never get a response so the control frame, so
> retries are just delaying all the commands.
> 
> Let's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM
> mode for the control DLCI. Then we can use that in gsm_control_send() to
> set retries to 1. This means the control frame will be sent once allowing
> the other end at an opportunity to switch from ADM to ABM mode.
> 
> Note that retries will be decremented in gsm_control_retransmit() so
> we don't want to set it to 0 here.

Thanks!

I guess I'd like to test this on Droid4; there are fso-gsm0710muxd and
gsm0710muxd packages in Debian, but I assume those do multiplexing in
userspace and thus are not suitable?

Do you have a tool to use and a script?

Thanks and best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RESEND PATCH] ARM: pxa: stargate2: use device properties for at24 eeprom

[Robert Jarzmik]

Bartosz Golaszewski  writes:

> 2018-04-04 21:44 GMT+02:00 Robert Jarzmik :
>> Bartosz Golaszewski  writes:
> Yes, it does use the type field from i2c_board_info implicitly over
> i2c-core. The type field is copied over to client->name and then is
> matched against the i2c ID table from which we get the associated chip
> data (unless the type is "at24") containing the size and flags.

Ah yes, the "struct i2c_device_id at24_ids" part, I see.

Applied to pxa/for-next, thanks.

-- 
Robert

Re: [PATCH 3/6] crypto: api - avoid VLA use

[Salvatore Mesoraca]

2018-04-08 5:16 GMT+02:00 Herbert Xu :
> On Sat, Apr 07, 2018 at 08:38:20PM +0200, Salvatore Mesoraca wrote:
>>
>>  int crypto_init_cipher_ops(struct crypto_tfm *tfm)
>>  {
>> + const unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
>> + const unsigned int size = crypto_tfm_alg_blocksize(tfm);
>>   struct cipher_tfm *ops = &tfm->crt_cipher;
>>   struct cipher_alg *cipher = &tfm->__crt_alg->cra_cipher;
>>
>> + if (size > MAX_BLOCKSIZE || alignmask > MAX_ALIGNMASK)
>> + return -EINVAL;
>> +
>
> This check should be done when the algorithm is registered.  Perhaps
> crypto_check_alg.

Please correct me if I'm wrong:
isn't crypto_check_alg invoked also during hashing algorithm registration?
In this patch-set I'm dealing only with ciphers, because the maximum
block size (16)
is relatively small and it's also the most common block size with
ciphers (maybe I should
have explicitly referenced ciphers in the macro names, my bad).
I don't think that it would be OK to use a similar approach for hashes
too, because some
of them have block size >= 1024 bytes.

Thank you for your time,

Salvatore

[PATCH/RFC] soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure

[Geert Uytterhoeven]

If CONFIG_RASPBERRYPI_FIRMWARE=n:

drivers/gpio/gpio-raspberrypi-exp.c: In function 
‘rpi_exp_gpio_get_polarity’:
drivers/gpio/gpio-raspberrypi-exp.c:71: warning: ‘get.polarity’ is used 
uninitialized in this function
drivers/gpio/gpio-raspberrypi-exp.c: In function 
‘rpi_exp_gpio_get_direction’:
drivers/gpio/gpio-raspberrypi-exp.c:150: warning: ‘get.direction’ is used 
uninitialized in this function

The dummy firmware interface functions return 0, which means success,
causing subsequent code to make use of the never initialized output
parameter.

Fix this by making the dummy functions return an error code (-ENOSYS)
instead.

Note that this assumes the firmware always fills in the requested data
in the CONFIG_RASPBERRYPI_FIRMWARE=y case.

Fixes: d45f1a563b92dac7 ("staging: vc04_services: fix up rpi firmware 
functions")
Signed-off-by: Geert Uytterhoeven 
---
Should get.polarity resp. get.direction be preinitialized instead,
like is done for get.state?

static int rpi_exp_gpio_get(struct gpio_chip *gc, unsigned int off)
{
...
get.state = 0;  /* storage for returned value */

ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_STATE,
 &get, sizeof(get));
...
}

This would avoid returning uninitialized data if the firmware did not
fill in the requested data.
---
 include/soc/bcm2835/raspberrypi-firmware.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index 50df5b28d2c9df6e..8ee8991aa099af3a 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -143,13 +143,13 @@ struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node);
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
void *data, size_t len)
 {
-   return 0;
+   return -ENOSYS;
 }
 
 static inline int rpi_firmware_property_list(struct rpi_firmware *fw,
 void *data, size_t tag_size)
 {
-   return 0;
+   return -ENOSYS;
 }
 
 static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
-- 
2.7.4

Re: [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id

[Peter Rosin]

On 2018-04-08 09:34, Wolfram Sang wrote:
> Hi,
> 
> On Mon, Mar 19, 2018 at 09:10:58AM -0700, Guenter Roeck wrote:
>> Commit dde67eb1beeb ("i2c: add i2c_get_device_id() to get the standard
>> I2C device id") added a function to return the standard I2C device ID.
>> Use that function to verify the device ID of a given device.
> 
> I am very open to these patches, just...
> 
>>
>> Cc: Peter Rosin 
>> Signed-off-by: Guenter Roeck 
>> ---
>> RFC:
>> - Compile tested only
> 
> ... I would really like to have them tested. After that happened, Peter
> and I can figure out who should apply them for seamless upstreaming.
> 
>> - Should there also be I2C_DEVICE_PART_ID_ANY to enable maching
>>   against all parts from a given manufacturer ?
> 
> Can't we just add it when we need it?
> 
>> +dev_err(&client->dev, "unexpected device id %03x-%03x-%x\n",
>> +real_id.manufacturer_id, real_id.part_id,
>> +real_id.die_revision);
>> +return -ENODEV;
> 
> I wonder about the ERR loglevel. ENODEV is not an error, I'd think?

Well, in this case someone has said that I2C addr  is a  device,
but when verifying the actual device at that addr, that's not what is
found. Hence, I think an error is appropriate? On the other hand, a driver
that can handle different kinds of devices might not want the error. But
for that case, maybe the driver should be using i2c_get_device_id() and
figure out the details by itself?

Cheers,
Peter

Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource

[Baoquan He]

Hi,

Thanks for telling!

On 04/08/18 at 12:12pm, kbuild test robot wrote:
> Hi Baoquan,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16 next-20180406]
> [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/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108
> config: parisc-c3000_defconfig (attached as .config)
> compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=parisc 
> 
> All errors (new ones prefixed by >>):
> 
>drivers//parisc/lba_pci.c: In function 'lba_dump_res':
> >> drivers//parisc/lba_pci.c:173:15: error: incompatible type for argument 1 
> >> of 'lba_dump_res'
>  lba_dump_res(r->child, d+2);

I compiled with allyesconfig, don't know why this was missed. Will
change and repost.

>   ^
>drivers//parisc/lba_pci.c:162:1: note: expected 'struct resource *' but 
> argument is of type 'struct list_head'
> lba_dump_res(struct resource *r, int d)
> ^~~~
>drivers//parisc/lba_pci.c:174:15: error: incompatible type for argument 1 
> of 'lba_dump_res'
>  lba_dump_res(r->sibling, d);
>   ^
>drivers//parisc/lba_pci.c:162:1: note: expected 'struct resource *' but 
> argument is of type 'struct list_head'
> lba_dump_res(struct resource *r, int d)
> ^~~~
> 
> vim +/lba_dump_res +173 drivers//parisc/lba_pci.c
> 
> ^1da177e Linus Torvalds 2005-04-16  159  
> ^1da177e Linus Torvalds 2005-04-16  160  
> ^1da177e Linus Torvalds 2005-04-16  161  static void
> ^1da177e Linus Torvalds 2005-04-16  162  lba_dump_res(struct resource *r, int 
> d)
> ^1da177e Linus Torvalds 2005-04-16  163  {
> ^1da177e Linus Torvalds 2005-04-16  164   int i;
> ^1da177e Linus Torvalds 2005-04-16  165  
> ^1da177e Linus Torvalds 2005-04-16  166   if (NULL == r)
> ^1da177e Linus Torvalds 2005-04-16  167   return;
> ^1da177e Linus Torvalds 2005-04-16  168  
> ^1da177e Linus Torvalds 2005-04-16  169   printk(KERN_DEBUG "(%p)", 
> r->parent);
> ^1da177e Linus Torvalds 2005-04-16  170   for (i = d; i ; --i) printk(" 
> ");
> 645d11d4 Matthew Wilcox 2006-12-24  171   printk(KERN_DEBUG "%p 
> [%lx,%lx]/%lx\n", r,
> 645d11d4 Matthew Wilcox 2006-12-24  172   (long)r->start, 
> (long)r->end, r->flags);
> ^1da177e Linus Torvalds 2005-04-16 @173   lba_dump_res(r->child, d+2);
> ^1da177e Linus Torvalds 2005-04-16  174   lba_dump_res(r->sibling, d);
> ^1da177e Linus Torvalds 2005-04-16  175  }
> ^1da177e Linus Torvalds 2005-04-16  176  
> 
> :: The code at line 173 was first introduced by commit
> :: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
> 
> :: TO: Linus Torvalds 
> :: CC: Linus Torvalds 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v5 08/13] ARM: sunxi: Add initialization of CNTVOFF

[Mylène Josserand]

Hello Maxime,

On Wed, 4 Apr 2018 09:45:15 +0200
Maxime Ripard  wrote:

> On Tue, Apr 03, 2018 at 10:06:28PM +0200, Mylène Josserand wrote:
> > Hello,
> > 
> > Thank you for the review.
> > 
> > On Tue, 3 Apr 2018 11:12:18 +0200
> > Maxime Ripard  wrote:
> >   
> > > On Tue, Apr 03, 2018 at 08:18:31AM +0200, Mylène Josserand wrote:  
> > > > Add the initialization of CNTVOFF for sun8i-a83t.
> > > > 
> > > > For boot CPU, Create a new machine that handles this
> > > > function's call in an "init_early" callback.
> > > > For secondary CPUs, add this function into secondary_startup
> > > > assembly entry.
> > > > 
> > > > Signed-off-by: Mylène Josserand 
> > > > ---
> > > >  arch/arm/mach-sunxi/headsmp.S |  1 +
> > > >  arch/arm/mach-sunxi/sunxi.c   | 18 +-
> > > >  2 files changed, 18 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm/mach-sunxi/headsmp.S 
> > > > b/arch/arm/mach-sunxi/headsmp.S
> > > > index 79890fbe5613..b586b7cf803a 100644
> > > > --- a/arch/arm/mach-sunxi/headsmp.S
> > > > +++ b/arch/arm/mach-sunxi/headsmp.S
> > > > @@ -71,6 +71,7 @@ ENDPROC(sunxi_mc_smp_cluster_cache_enable)
> > > >  
> > > >  ENTRY(sunxi_mc_smp_secondary_startup)
> > > > bl  sunxi_mc_smp_cluster_cache_enable
> > > > +   bl  smp_init_cntvoff
> > > > b   secondary_startup
> > > >  ENDPROC(sunxi_mc_smp_secondary_startup)
> > > >  
> > > > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> > > > index 5e9602ce1573..090784108c0a 100644
> > > > --- a/arch/arm/mach-sunxi/sunxi.c
> > > > +++ b/arch/arm/mach-sunxi/sunxi.c
> > > > @@ -16,6 +16,7 @@
> > > >  #include 
> > > >  
> > > >  #include 
> > > > +#include 
> > > >  
> > > >  static const char * const sunxi_board_dt_compat[] = {
> > > > "allwinner,sun4i-a10",
> > > > @@ -62,7 +63,6 @@ MACHINE_END
> > > >  static const char * const sun8i_board_dt_compat[] = {
> > > > "allwinner,sun8i-a23",
> > > > "allwinner,sun8i-a33",
> > > > -   "allwinner,sun8i-a83t",
> > > > "allwinner,sun8i-h2-plus",
> > > > "allwinner,sun8i-h3",
> > > > "allwinner,sun8i-r40",
> > > > @@ -75,6 +75,22 @@ DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i Family")
> > > > .dt_compat  = sun8i_board_dt_compat,
> > > >  MACHINE_END
> > > >  
> > > > +void __init sun8i_cntvoff_init(void)
> > > > +{
> > > > +   smp_init_cntvoff();
> > > 
> > > Can't this be moved to the SMP setup code?  
> > 
> > I tried to put it in the first lines of "sunxi_mc_smp_init" function
> > but it did not work. I tried to find some callbacks to have an
> > early "init" and I only found the "init_early"'s one. There is probably
> > another way to handle that so do not hesitate to tell me any ideas.  
> 
> It's hard to say without more context about why it doesn't work. Have
> you checked the order between early_initcall, the timer initialization
> function and init_early?
> 

Yes, I tested it. I wanted to test it again to give more context. Here
is the boot log: http://code.bulix.org/n1x864-315948?raw
I added printk in the 3 functions (with "===>").

The "init_early" and "sun6i_timer" are executed before
"arch_timer_of_init" (which is the function that parses the DT property
that we used previously "arm,cpu-registers-not-fw-configured").
The "sunxi_mc_smp_init" function is called later so I guess that is why
it is not working in that case.

> > > > +}
> > > > +
> > > > +static const char * const sun8i_cntvoff_board_dt_compat[] = {
> > > > +   "allwinner,sun8i-a83t",
> > > > +   NULL,
> > > > +};
> > > > +
> > > > +DT_MACHINE_START(SUN8I_CNTVOFF_DT, "Allwinner sun8i boards needing 
> > > > cntvoff")
> > > 
> > > All of the SoCs need CNTVOFF, so that doesn't really make sense. Why
> > > not just calling it for what it is: an A83t?  
> > 
> > Sure, I will update it.  
> 
> Looking back at that code, I guess you want to change also the
> smp_init_cntvoff function. It's not really related to SMP either.

Yep, I will update it in next version.

Thanks,

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource

[Baoquan He]

On 04/08/18 at 01:55pm, kbuild test robot wrote:
> Hi Baoquan,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16 next-20180406]
> [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/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108
> config: sparc-defconfig (attached as .config)
> compiler: sparc-linux-gcc (GCC) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc 
> 
> All errors (new ones prefixed by >>):
> 
>arch/sparc/kernel/ioport.c: In function 'sparc_io_proc_show':
> >> arch/sparc/kernel/ioport.c:672:9: error: incompatible types when assigning 
> >> to type 'struct resource *' from type 'struct list_head'
>  for (r = root->child; r != NULL; r = r->sibling) {
> ^
>arch/sparc/kernel/ioport.c:672:37: error: incompatible types when 
> assigning to type 'struct resource *' from type 'struct list_head'
>  for (r = root->child; r != NULL; r = r->sibling) {
> ^

Thanks, will change and repost.

> 
> vim +672 arch/sparc/kernel/ioport.c
> 
> ^1da177e4 Linus Torvalds 2005-04-16  666  
> e7a088f93 Alexey Dobriyan2009-09-01  667  static int 
> sparc_io_proc_show(struct seq_file *m, void *v)
> ^1da177e4 Linus Torvalds 2005-04-16  668  {
> e7a088f93 Alexey Dobriyan2009-09-01  669  struct resource *root = 
> m->private, *r;
> ^1da177e4 Linus Torvalds 2005-04-16  670  const char *nm;
> ^1da177e4 Linus Torvalds 2005-04-16  671  
> e7a088f93 Alexey Dobriyan2009-09-01 @672  for (r = root->child; r 
> != NULL; r = r->sibling) {
> c31f76518 Sam Ravnborg   2014-04-21  673  if ((nm = 
> r->name) == NULL) nm = "???";
> e7a088f93 Alexey Dobriyan2009-09-01  674  seq_printf(m, 
> "%016llx-%016llx: %s\n",
> 685143ac1 Greg Kroah-Hartman 2006-06-12  675  
> (unsigned long long)r->start,
> 685143ac1 Greg Kroah-Hartman 2006-06-12  676  
> (unsigned long long)r->end, nm);
> ^1da177e4 Linus Torvalds 2005-04-16  677  }
> ^1da177e4 Linus Torvalds 2005-04-16  678  
> e7a088f93 Alexey Dobriyan2009-09-01  679  return 0;
> ^1da177e4 Linus Torvalds 2005-04-16  680  }
> ^1da177e4 Linus Torvalds 2005-04-16  681  
> 
> :: The code at line 672 was first introduced by commit
> :: e7a088f935180b90cfe6ab0aaae8a556f46885fe sparc: convert /proc/io_map, 
> /proc/dvma_map to seq_file
> 
> :: TO: Alexey Dobriyan 
> :: CC: David S. Miller 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH 0/3] syscalls: clean up stub naming convention

[Dominik Brodowski]

On Sun, Apr 08, 2018 at 10:35:50AM +0200, Ingo Molnar wrote:
>   - _sys_waitid()  # ridiculous number of underscores?
>   - __sys_waitid() # too generic sounding?

... and we'd need to rename internal helpers in net/

>   - __inline_sys_waitid()  # too long?

sounds acceptable, though a bit long (especially for the compat case, though
it doesn't really matter in the case of 
__inline_compat_sys_sched_rr_get_interval)

> One more fundamental question: why do we have the __do_sys_waitid() and 
> __inline_sys_waitid() distinction - aren't the function call signatures the 
> same 
> with no conversion done?
> 
> I.e. couldn't we just do a single, static __do_sys_waitid(), where the 
> compiler 
> would decide to what extent inlining is justified? This would allow the 
> compiler 
> to inline all the intermediate code into the stubs themselves.
> 
> Or is this a side effect of the error injection feature, which needs to add 
> extra 
> logic at this intermediate level? That too should be able to use the 
> __do_sys_waitid() variant though.

Error injection is unrelated. It seems to be for three reasons, if I read
the code (include/linux/syscalls.h) correctly:

asmlinkage long __do_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))

1)  This takes arguments of type long (to protect against CVE-2009-0029);
see https://lwn.net/Articles/604287/ : "Digging into the history of
this, it turns out that the long version ensures that 32-bit values
are correctly sign-extended for some 64-bit kernel platforms,
preventing a historical vulnerability."

{
long ret = __in_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));
__MAP(x,__SC_TEST,__VA_ARGS__);

2) We can add testing whether one of the arguments is longer than long.

__PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__));

3) This adds asmlinkage_protect() on m68k, but seems to be a no-op on other
architectures.


While reasons 1 and 3 seem irrelevant on x86, I'd like to keep the code
close to the generic one -- and reason 2 is valid in and by itself. So I'd
recommend keeping the __inline_sys / __do_sys indirection.


> Is UML unaffected by these renames?

UML is only affected by patch 3/3, but kept happy by the patch to
entry/syscalls/syscalltbl.sh.


On a somewhat related note: I'll try to prepare a patch this evening which
lets us build just the __ia32_sys and __x32_compat_sys stubs we actually
need. We have that information already in entry/syscalls/syscall_{32,64}.tbl,
it just needs to be extracted into another header file (in the form of
#define NEED_IA32_sys_xyzzz 1
) and then tested within the stubs. After some randconfig testing, this
might be worthwile to add on top of the patches already in tip-asm and the
three renaming patches currently under discussion.


Thanks,
Dominik

Re: [PATCH 2/6] crypto: ctr - avoid VLA use

[Herbert Xu]

On Sun, Apr 08, 2018 at 10:58:48AM +0200, Salvatore Mesoraca wrote:
>
> Fair enough.
> After removing the individual checks the modification to the single files
> will be just a couple of lines, is it OK for you if I collapse all of them in
> just a single commit?

Sure.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 3/6] crypto: api - avoid VLA use

[Herbert Xu]

On Sun, Apr 08, 2018 at 11:07:12AM +0200, Salvatore Mesoraca wrote:
>
> > This check should be done when the algorithm is registered.  Perhaps
> > crypto_check_alg.
> 
> Please correct me if I'm wrong:
> isn't crypto_check_alg invoked also during hashing algorithm registration?
> In this patch-set I'm dealing only with ciphers, because the maximum
> block size (16)
> is relatively small and it's also the most common block size with
> ciphers (maybe I should
> have explicitly referenced ciphers in the macro names, my bad).
> I don't think that it would be OK to use a similar approach for hashes
> too, because some
> of them have block size >= 1024 bytes.

Yes we want to make it for ciphers only even if we move it to
crypto_check_alg.

For a legacy type like cipher cou can do it by

if (!alg->cra_type && (alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
  CRYPTO_ALG_TYPE_CIPHER)
do_cipher_specific_check();

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

[David Wang]

We add this patch to show correct HW features(arch_perfmon, tpr_shadow,
vnmi, flexpriority, ept and vpid) when user execute "cat /proc/cpuinfo".

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/centaur.c | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..969fb8f 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   clear_cpu_cap(c, X86_FEATURE_VNMI);
+   clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   clear_cpu_cap(c, X86_FEATURE_EPT);
+   clear_cpu_cap(c, X86_FEATURE_VPID);
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +166,14 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned eax = cpuid_eax(10);
+   /* Check for version and the number of counters */
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +245,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
1.9.1

[PATCH 1/2] clk: at91: Added more information logging.

[Marcin]

I noticed that when debugging some USB clocking issue that there weren't
many ways to tell what the state of the USB clocking system was. This
adds a few logging statements to see what the relevant code is trying to
do.

Signed-off-by: Marcin Ziemianowicz 
---
 drivers/clk/at91/clk-pll.c   |  6 +-
 drivers/clk/at91/clk-usb.c   | 10 --
 drivers/usb/host/ohci-at91.c | 21 +++--
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 7d3223fc7161..534961766ae5 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -133,6 +133,7 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 {
struct clk_pll *pll = to_clk_pll(hw);
unsigned int pllr;
+   unsigned long recalcedrate;
u16 mul;
u8 div;
 
@@ -144,7 +145,10 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
if (!div || !mul)
return 0;
 
-   return (parent_rate / div) * (mul + 1);
+   recalcedrate = (parent_rate / div) * (mul + 1);
+   pr_debug("clk-pll: calculating new rate, (%lu hz / %u) * %u = %lu hz\n",
+   parent_rate, div, mul, recalcedrate);
+   return recalcedrate;
 }
 
 static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
index 791770a563fc..2fa877e99bac 100644
--- a/drivers/clk/at91/clk-usb.c
+++ b/drivers/clk/at91/clk-usb.c
@@ -48,11 +48,15 @@ static unsigned long at91sam9x5_clk_usb_recalc_rate(struct 
clk_hw *hw,
struct at91sam9x5_clk_usb *usb = to_at91sam9x5_clk_usb(hw);
unsigned int usbr;
u8 usbdiv;
+   unsigned int calcdclock;
 
regmap_read(usb->regmap, AT91_PMC_USB, &usbr);
usbdiv = (usbr & AT91_PMC_OHCIUSBDIV) >> SAM9X5_USB_DIV_SHIFT;
 
-   return DIV_ROUND_CLOSEST(parent_rate, (usbdiv + 1));
+   calcdclock = DIV_ROUND_CLOSEST(parent_rate, (usbdiv + 1));
+   pr_debug("clk-usb: calculating new rate, %lu hz / %u = %u hz\n",
+   parent_rate, usbdiv + 1, calcdclock);
+   return calcdclock;
 }
 
 static int at91sam9x5_clk_usb_determine_rate(struct clk_hw *hw,
@@ -98,7 +102,6 @@ static int at91sam9x5_clk_usb_determine_rate(struct clk_hw 
*hw,
if (!best_diff)
break;
}
-
if (best_rate < 0)
return best_rate;
 
@@ -142,6 +145,9 @@ static int at91sam9x5_clk_usb_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (div > SAM9X5_USB_MAX_DIV + 1 || !div)
return -EINVAL;
 
+   pr_debug("clk-usb: setting USB clock divider to %lu hz / %lu = %lu 
hz\n",
+   parent_rate, div, rate);
+
regmap_update_bits(usb->regmap, AT91_PMC_USB, AT91_PMC_OHCIUSBDIV,
   (div - 1) << SAM9X5_USB_DIV_SHIFT);
 
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 5ad9e9bdc8ee..5dfc4e464cfe 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -70,11 +70,12 @@ static const struct ohci_driver_overrides 
ohci_at91_drv_overrides __initconst =
 
 /*-*/
 
-static void at91_start_clock(struct ohci_at91_priv *ohci_at91)
+static void at91_start_clock(struct ohci_at91_priv *ohci_at91, struct device 
*dev)
 {
if (ohci_at91->clocked)
return;
 
+   dev_dbg(dev, "Enabling hclk, iclk, and setting fclk to 48 Mhz\n");
clk_set_rate(ohci_at91->fclk, 4800);
clk_prepare_enable(ohci_at91->hclk);
clk_prepare_enable(ohci_at91->iclk);
@@ -82,11 +83,12 @@ static void at91_start_clock(struct ohci_at91_priv 
*ohci_at91)
ohci_at91->clocked = true;
 }
 
-static void at91_stop_clock(struct ohci_at91_priv *ohci_at91)
+static void at91_stop_clock(struct ohci_at91_priv *ohci_at91, struct device 
*dev)
 {
if (!ohci_at91->clocked)
return;
 
+   dev_dbg(dev, "Disabling hclk, iclk, and fclk\n");
clk_disable_unprepare(ohci_at91->fclk);
clk_disable_unprepare(ohci_at91->iclk);
clk_disable_unprepare(ohci_at91->hclk);
@@ -104,12 +106,19 @@ static void at91_start_hc(struct platform_device *pdev)
/*
 * Start the USB clocks.
 */
-   at91_start_clock(ohci_at91);
+   at91_start_clock(ohci_at91, &pdev->dev);
 
/*
 * The USB host controller must remain in reset.
 */
writel(0, ®s->control);
+
+   /*
+* Say what the clocks are set to.
+*/
+   dev_dbg(&pdev->dev, "hclk set to: %lu hz\n", 
clk_get_rate(ohci_at91->hclk));
+   dev_dbg(&pdev->dev, "iclk set to: %lu hz\n", 
clk_get_rate(ohci_at91->iclk));
+   dev_dbg(&pdev->dev, "fclk set to: %lu hz\n", 
clk_get_rate(ohci_at91->fclk));
 }
 
 static void at91_stop_hc(struct platform_device *pdev)
@@ -128,7 +137,7 @@ static void at91_s

[PATCH 2/2] clk: at91: Fix for PLL set_rate changes not being actually written to PLL peripheral bits

[Marcin]

When a USB device is connected to the USB host port on the SAM9N12 then
you get "-62" error which seems to indicate USB replies from the device
are timing out. Looking around, I saw the USB bus was running at half
speed. Going further, it seems that in ..._set_rate() the PLL wasn't
actually being adjusted. Writing the multiplier and divider values to
the peripheral fixes the bus running at half speed.

Signed-off-by: Marcin Ziemianowicz 
---
 drivers/clk/at91/clk-pll.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 534961766ae5..db7155fe9346 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -288,6 +288,14 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned 
long rate,
pll->div = div;
pll->mul = mul;
 
+   // Set the PLL as per above div and mil values.
+   regmap_update_bits(pll->regmap, AT91_CKGR_PLLBR,
+   AT91_PMC_DIV | AT91_PMC_MUL,
+   (div << 0) | (mul << 16));
+
+   pr_debug("clk-pll: setting new rate, (%lu hz / %u) * %u = %lu hz\n",
+   parent_rate, div, mul, rate);
+
return 0;
 }
 
-- 
2.16.3

Re: [PATCH 1/2] clk: at91: Added more information logging.

[Greg Kroah-Hartman]

On Sun, Apr 08, 2018 at 05:43:30AM -0400, Marcin wrote:
> I noticed that when debugging some USB clocking issue that there weren't
> many ways to tell what the state of the USB clocking system was. This
> adds a few logging statements to see what the relevant code is trying to
> do.
> 
> Signed-off-by: Marcin Ziemianowicz 

Your "From:" line doesn't match this name :(

[PATCH 0/3] Add MCAN Support for dra76x

[Faiz Abbas]

The following patches add dts and hwmod support for MCAN in TI's
dra76 SOCs.

The patches depend on the following series:
https://patchwork.kernel.org/patch/10221105/

Tested on linux-next

Franklin S Cooper Jr (1):
  ARM: dts: dra76x: Add MCAN node

Lokesh Vutla (2):
  ARM: dra762: hwmod: Add MCAN support
  ARM: dts: dra762: Add MCAN clock support

 arch/arm/boot/dts/dra76-evm.dts   |  7 +
 arch/arm/boot/dts/dra76x.dtsi | 50 +++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 
 3 files changed, 89 insertions(+)

-- 
2.7.4

[PATCH 2/3] ARM: dts: dra762: Add MCAN clock support

[Faiz Abbas]

From: Lokesh Vutla 

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Faiz Abbas 
---
 arch/arm/boot/dts/dra76x.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index 1c88c58..bfc8263 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -17,3 +17,36 @@
 &crossbar_mpu {
ti,irqs-skip = <10 67 68 133 139 140>;
 };
+
+&scm_conf_clocks {
+   dpll_gmac_h14x2_ctrl_ck: dpll_gmac_h14x2_ctrl_ck@3fc {
+   #clock-cells = <0>;
+   compatible = "ti,divider-clock";
+   clocks = <&dpll_gmac_x2_ck>;
+   ti,max-div = <63>;
+   reg = <0x03fc>;
+   ti,bit-shift=<20>;
+   ti,latch-bit=<26>;
+   assigned-clocks = <&dpll_gmac_h14x2_ctrl_ck>;
+   assigned-clock-rates = <8000>;
+   };
+
+   dpll_gmac_h14x2_ctrl_mux_ck: dpll_gmac_h14x2_ctrl_mux_ck@3fc {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <&dpll_gmac_ck>, <&dpll_gmac_h14x2_ctrl_ck>;
+   reg = <0x3fc>;
+   ti,bit-shift = <29>;
+   ti,latch-bit=<26>;
+   assigned-clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+   assigned-clock-parents = <&dpll_gmac_h14x2_ctrl_ck>;
+   };
+
+   mcan_clk: mcan_clk@3fc {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&dpll_gmac_h14x2_ctrl_mux_ck>;
+   ti,bit-shift = <27>;
+   reg = <0x3fc>;
+   };
+};
-- 
2.7.4

[PATCH 1/3] ARM: dra762: hwmod: Add MCAN support

[Faiz Abbas]

From: Lokesh Vutla 

Add MCAN hwmod data and register it for dra762 silicons.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Faiz Abbas 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 62352d1..a2cd7f8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1356,6 +1356,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
 };
 
 /*
+ * 'mcan' class
+ *
+ */
+static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
+   .name   = "mcan",
+};
+
+/* mcan */
+static struct omap_hwmod dra76x_mcan_hwmod = {
+   .name   = "mcan",
+   .class  = &dra76x_mcan_hwmod_class,
+   .clkdm_name = "wkupaon_clkdm",
+   .main_clk   = "mcan_clk",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_WKUPAON_ADC_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_WKUPAON_ADC_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/*
  * 'mcspi' class
  *
  */
@@ -3818,6 +3841,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss2 
= {
.user   = OCP_USER_MPU,
 };
 
+/* l3_main_1 -> mcan */
+static struct omap_hwmod_ocp_if dra76x_l3_main_1__mcan = {
+   .master = &dra7xx_l3_main_1_hwmod,
+   .slave  = &dra76x_mcan_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l3_main_1__dmm,
&dra7xx_l3_main_2__l3_instr,
@@ -3958,6 +3989,7 @@ static struct omap_hwmod_ocp_if 
*dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
 /* SoC variant specific hwmod links */
 static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l4_per3__usb_otg_ss4,
+   &dra76x_l3_main_1__mcan,
NULL,
 };
 
-- 
2.7.4

[PATCH 3/3] ARM: dts: dra76x: Add MCAN node

[Faiz Abbas]

From: Franklin S Cooper Jr 

Add support for the MCAN peripheral which supports both classic
CAN messages along with the new CAN-FD message.

Add MCAN node to evm and enable it with a maximum datarate of 5 mbps

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Sekhar Nori 
Signed-off-by: Faiz Abbas 
---
 arch/arm/boot/dts/dra76-evm.dts |  7 +++
 arch/arm/boot/dts/dra76x.dtsi   | 17 +
 2 files changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 2deb964..2777652 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -404,3 +404,10 @@
phys = <&pcie1_phy>, <&pcie2_phy>;
phy-names = "pcie-phy0", "pcie-phy1";
 };
+
+&m_can0 {
+   status = "okay";
+   can-transceiver {
+   max-bitrate = <500>;
+   };
+};
diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
index bfc8263..71bd2a2 100644
--- a/arch/arm/boot/dts/dra76x.dtsi
+++ b/arch/arm/boot/dts/dra76x.dtsi
@@ -11,6 +11,23 @@
 / {
compatible = "ti,dra762", "ti,dra7";
 
+   ocp {
+   m_can0: mcan@42C01A00 {
+   compatible = "bosch,m_can";
+   reg = <0x42C01A00 0x4000>, <0x42C0 0x18FC>;
+   reg-names = "m_can", "message_ram";
+   interrupt-parent = <&gic>;
+   interrupts = ,
+;
+   interrupt-names = "int0", "int1";
+   ti,hwmods = "mcan";
+   clocks = <&mcan_clk>, <&l3_iclk_div>;
+   clock-names = "cclk", "hclk";
+   bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+   status = "disabled";
+   };
+   };
+
 };
 
 /* MCAN interrupts are hard-wired to irqs 67, 68 */
-- 
2.7.4

[PATCH] m68k: Fix style, spelling, and grammar in siginfo_build_tests()

[Geert Uytterhoeven]

Fixes: 4be33329d46f80e8 ("m68k: Verify the offsets in struct siginfo never 
change.")
Signed-off-by: Geert Uytterhoeven 
---
 arch/m68k/kernel/signal.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index 61a65fa374e5d006..d12b84f1ae312779 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -576,41 +576,42 @@ static inline int rt_save_fpu_state(struct ucontext 
__user *uc, struct pt_regs *
 
 static inline void siginfo_build_tests(void)
 {
-   /* This needs to be tested on m68k as it has a lesser
-* alignment requirment than x86 and that can cause surprises.
+   /*
+* This needs to be tested on m68k as it has a lesser
+* alignment requirement than x86 and that can cause surprises.
 */
 
/* This is part of the ABI and can never change in size: */
BUILD_BUG_ON(sizeof(siginfo_t) != 128);
 
-   /* Ensure the know fields never change in location */
+   /* Ensure the known fields never change in location */
BUILD_BUG_ON(offsetof(siginfo_t, si_signo) != 0);
BUILD_BUG_ON(offsetof(siginfo_t, si_errno) != 4);
BUILD_BUG_ON(offsetof(siginfo_t, si_code)  != 8);
 
/* _kill */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_pid) != 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_pid) != 0x0c);
BUILD_BUG_ON(offsetof(siginfo_t, si_uid) != 0x10);
 
/* _timer */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_tid) != 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_tid) != 0x0c);
BUILD_BUG_ON(offsetof(siginfo_t, si_overrun) != 0x10);
BUILD_BUG_ON(offsetof(siginfo_t, si_value)   != 0x14);
 
/* _rt */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_pid)   != 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_pid)   != 0x0c);
BUILD_BUG_ON(offsetof(siginfo_t, si_uid)   != 0x10);
BUILD_BUG_ON(offsetof(siginfo_t, si_value) != 0x14);
 
/* _sigchld */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_pid)!= 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_pid)!= 0x0c);
BUILD_BUG_ON(offsetof(siginfo_t, si_uid)!= 0x10);
BUILD_BUG_ON(offsetof(siginfo_t, si_status) != 0x14);
BUILD_BUG_ON(offsetof(siginfo_t, si_utime)  != 0x18);
-   BUILD_BUG_ON(offsetof(siginfo_t, si_stime)  != 0x1C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_stime)  != 0x1c);
 
/* _sigfault */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_addr) != 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_addr) != 0x0c);
 
/* _sigfault._mcerr */
BUILD_BUG_ON(offsetof(siginfo_t, si_addr_lsb) != 0x10);
@@ -623,11 +624,11 @@ static inline void siginfo_build_tests(void)
BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x12);
 
/* _sigpoll */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_band)   != 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_band)   != 0x0c);
BUILD_BUG_ON(offsetof(siginfo_t, si_fd) != 0x10);
 
/* _sigsys */
-   BUILD_BUG_ON(offsetof(siginfo_t, si_call_addr) != 0x0C);
+   BUILD_BUG_ON(offsetof(siginfo_t, si_call_addr) != 0x0c);
BUILD_BUG_ON(offsetof(siginfo_t, si_syscall)   != 0x10);
BUILD_BUG_ON(offsetof(siginfo_t, si_arch)  != 0x14);
 
-- 
2.7.4

Re: [PATCH 2/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

[Taniya Das]

Thanks Stephen for the review.

On 4/6/2018 4:50 AM, Stephen Boyd wrote:

Quoting Taniya Das (2018-03-28 23:17:53)

diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmh.txt 
b/Documentation/devicetree/bindings/clock/qcom,rpmh.txt
new file mode 100644
index 000..8222c88
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmh.txt


Can the file name be qcom,rpmh-clk?



Sure will update the file name.


@@ -0,0 +1,22 @@
+Qualcomm Technologies, Inc. RPMh Clocks
+---
+
+Resource Power Manager Hardened (RPMh) manages shared resources on
+some Qualcomm Technologies Inc. SoCs. It accepts clock requests from
+other hardware subsystems via RSC to control clocks.
+
+Required properties :
+- compatible : shall contain "qcom,rpmh-clk-sdm845"
+
+- #clock-cells : must contain 1
+
+Example :
+
+#include 
+
+   &apps_rsc {



+   clock_rpmh: qcom,rpmhclk {


Should say clock-controller for node name.



Would fix it in the next patch.


+   compatible = "qcom,rpmh-clk-sdm845";
+   #clock-cells = <1>;


Is this tabbed out correctly?



Will fix the tabs in the next patch.


+   };
+   };


--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [PATCH 1/2] clk: at91: Added more information logging.

[Marcin Ziemianowicz]

On Sun, Apr 08, 2018 at 11:54:49AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Apr 08, 2018 at 05:43:30AM -0400, Marcin wrote:
> > I noticed that when debugging some USB clocking issue that there weren't
> > many ways to tell what the state of the USB clocking system was. This
> > adds a few logging statements to see what the relevant code is trying to
> > do.
> > 
> > Signed-off-by: Marcin Ziemianowicz 
> 
> Your "From:" line doesn't match this name :(

Ah drat, I knew I did something wrong. You suggested in IRC that I wait a day
for others to reply, so after that I will attempt to version my patchset.

Re: WARNING in kmem_cache_free

[Dmitry Vyukov]

On Sun, Apr 8, 2018 at 8:01 AM, Matthew Wilcox  wrote:
> On Fri, Apr 06, 2018 at 03:33:36PM +0200, Dmitry Vyukov wrote:
>> On Fri, Apr 6, 2018 at 3:24 PM, syzbot
>>  wrote:
>> > Unfortunately, I don't have any reproducer for this crash yet.
>>
>> Interesting type of bug, I think we see this for the first time.
>
> Can you focus syzbot to try to find a reproducer?  This seems to be
> produced by calling mount() with a pathname that's somewhere between,
> say, 3950 & 4100 bytes long from a compat 32-bit task.


Something in the log definitely triggers a very bad heap corruption.

This can be reproduced following instructions at:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers

and then running:
./syz-execprog -sandbox=namespace -arch=386 -repeat=0 -procs=10 log.txt

where log.txt comes from "Raw console output" link.

Note that you need to build syzkaller with 'make TARGETARCH=386' and
the use bin/linux_386/syz-executor.

While running it I got:
BUG: KASAN: double-free or invalid-free in free_request_size+0x5b/0x70
block/blk-core.c:769
https://gist.githubusercontent.com/dvyukov/05f4e77a34795d329aa7a2f40265e396/raw/63a29123b79f1fbad3521d0ff034946be68bfd4a/gistfile1.txt

Then kernel BUG at mm/slab.c:4407!
https://gist.githubusercontent.com/dvyukov/5b3bcc90d326e9da3636aea2c95ace8f/raw/1589504c708994936681d61ba9d70029998b9b1a/gistfile1.txt

And then BUG: unable to handle kernel paging request at ebe00020
https://gist.githubusercontent.com/dvyukov/72025b1c68e488f4fda243e0c152f044/raw/d2c171bc55ad3a43cea33095fa2eea48768b1131/gistfile1.txt

One interesting thing is that if I run the log once and it does not
crash, then when I try to start binary again I am getting:
[  456.837870] Invalid argument reading file caps for /root/syz-executor
The binary somehow becomes broken on disk...

I guess syzbot did find a reproducer in this log, but did not
attribute it to this bug as it causes crashes all over the place.

Re: [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id

[Peter Rosin]

Sorry for replying to self...

On 2018-04-08 11:08, Peter Rosin wrote:
> On 2018-04-08 09:34, Wolfram Sang wrote:
>> Hi,
>>
>> On Mon, Mar 19, 2018 at 09:10:58AM -0700, Guenter Roeck wrote:
>>> Commit dde67eb1beeb ("i2c: add i2c_get_device_id() to get the standard
>>> I2C device id") added a function to return the standard I2C device ID.
>>> Use that function to verify the device ID of a given device.
>>
>> I am very open to these patches, just...
>>
>>>
>>> Cc: Peter Rosin 
>>> Signed-off-by: Guenter Roeck 
>>> ---
>>> RFC:
>>> - Compile tested only
>>
>> ... I would really like to have them tested. After that happened, Peter
>> and I can figure out who should apply them for seamless upstreaming.
>>
>>> - Should there also be I2C_DEVICE_PART_ID_ANY to enable maching
>>>   against all parts from a given manufacturer ?
>>
>> Can't we just add it when we need it?

Is it really reasonable to verify just the manufacturer? I don't see the
use case? I mean, we can never know if the verified manufacturer will
release unexpected chips further down the line.

>>> +   dev_err(&client->dev, "unexpected device id %03x-%03x-%x\n",
>>> +   real_id.manufacturer_id, real_id.part_id,
>>> +   real_id.die_revision);
>>> +   return -ENODEV;
>>
>> I wonder about the ERR loglevel. ENODEV is not an error, I'd think?
> 
> Well, in this case someone has said that I2C addr  is a  device,
> but when verifying the actual device at that addr, that's not what is
> found. Hence, I think an error is appropriate? On the other hand, a driver
> that can handle different kinds of devices might not want the error. But
> for that case, maybe the driver should be using i2c_get_device_id() and
> figure out the details by itself?

Maybe it should just be -EINVAL, and that's your real objection?

Cheers,
Peter

[PATCH v2 0/2] Add QCOM RPMh Clock driver

[Taniya Das]

 [v2]
  * Addressed comments from Stephen
  * Addressed comments from Evan

This patch series adds a driver and device tree documentation binding
for the clock control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc, SoCs such as SDM845. The clock RPMh driver
would send requests for the RPMh managed clock resources.

The RPMh clock driver depends upon the RPMh driver [1] and command DB
driver [2] which are both still undergoing review.

Thanks,
Taniya

[1]: https://lkml.org/lkml/2018/3/9/979
[2]: https://lkml.org/lkml/2018/3/14/787

Amit Nischal (2):
  clk: qcom: clk-rpmh: Add QCOM RPMh clock driver
  dt-bindings: clock: Introduce QCOM RPMh clock bindings

 .../devicetree/bindings/clock/qcom,rpmh-clk.txt |  22 ++
 drivers/clk/qcom/Kconfig|   9 +
 drivers/clk/qcom/Makefile   |   1 +
 drivers/clk/qcom/clk-rpmh.c | 394 +
 include/dt-bindings/clock/qcom,rpmh.h   |  25 ++
 5 files changed, 451 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt
 create mode 100644 drivers/clk/qcom/clk-rpmh.c
 create mode 100644 include/dt-bindings/clock/qcom,rpmh.h

--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.

[[PATCH v2] 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[Taniya Das]

From: Amit Nischal 

Add the RPMh clock driver to control the RPMh managed clock resources on
some of the Qualcomm Technologies, Inc. SoCs.

Signed-off-by: David Collins 
Signed-off-by: Amit Nischal 
Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/Kconfig  |   9 +
 drivers/clk/qcom/Makefile |   1 +
 drivers/clk/qcom/clk-rpmh.c   | 394 ++
 include/dt-bindings/clock/qcom,rpmh.h |  25 +++
 4 files changed, 429 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-rpmh.c
 create mode 100644 include/dt-bindings/clock/qcom,rpmh.h

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fbf4532..3697a6a 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -112,6 +112,15 @@ config IPQ_GCC_8074
  i2c, USB, SD/eMMC, etc. Select this for the root clock
  of ipq8074.
 
+config MSM_CLK_RPMH
+   tristate "RPMh Clock Driver"
+   depends on COMMON_CLK_QCOM && QCOM_RPMH
+   help
+RPMh manages shared resources on some Qualcomm Technologies, Inc.
+SoCs. It accepts requests from other hardware subsystems via RSC.
+Say Y if you want to support the clocks exposed by RPMh on
+platforms such as sdm845.
+
 config MSM_GCC_8660
tristate "MSM8660 Global Clock Controller"
depends on COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 230332c..b7da05b 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_IPQ_GCC_8074) += gcc-ipq8074.o
 obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
 obj-$(CONFIG_MDM_GCC_9615) += gcc-mdm9615.o
 obj-$(CONFIG_MDM_LCC_9615) += lcc-mdm9615.o
+obj-$(CONFIG_MSM_CLK_RPMH) += clk-rpmh.o
 obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
 obj-$(CONFIG_MSM_GCC_8916) += gcc-msm8916.o
 obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
new file mode 100644
index 000..763401f
--- /dev/null
+++ b/drivers/clk/qcom/clk-rpmh.c
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+
+#define CLK_RPMH_ARC_EN_OFFSET 0
+#define CLK_RPMH_VRM_EN_OFFSET 4
+#define CLK_RPMH_VRM_OFF_VAL 0
+#define CLK_RPMH_VRM_ON_VAL 1
+#define CLK_RPMH_APPS_RSC_AO_STATE_MASK (BIT(RPMH_WAKE_ONLY_STATE) | \
+BIT(RPMH_ACTIVE_ONLY_STATE))
+#define CLK_RPMH_APPS_RSC_STATE_MASK (BIT(RPMH_WAKE_ONLY_STATE) | \
+ BIT(RPMH_ACTIVE_ONLY_STATE) | \
+ BIT(RPMH_SLEEP_STATE))
+struct clk_rpmh {
+   struct clk_hw hw;
+   const char *res_name;
+   u32 res_addr;
+   u32 res_en_offset;
+   u32 res_on_val;
+   u32 res_off_val;
+   u32 state;
+   u32 aggr_state;
+   u32 last_sent_aggr_state;
+   u32 valid_state_mask;
+   struct rpmh_client *rpmh_client;
+   unsigned long rate;
+   struct clk_rpmh *peer;
+};
+
+struct rpmh_cc {
+   struct clk_onecell_data data;
+   struct clk *clks[];
+};
+
+struct clk_rpmh_desc {
+   struct clk_hw **clks;
+   size_t num_clks;
+};
+
+static DEFINE_MUTEX(rpmh_clk_lock);
+
+#define __DEFINE_CLK_RPMH(_platform, _name, _name_active, _res_name, \
+ _res_en_offset, _res_on, _res_off, _rate, \
+ _state_mask, _state_on_mask)\
+   static struct clk_rpmh _platform##_##_name_active;\
+   static struct clk_rpmh _platform##_##_name = {\
+   .res_name = _res_name,\
+   .res_en_offset = _res_en_offset,  \
+   .res_on_val = _res_on,\
+   .res_off_val = _res_off,  \
+   .rate = _rate,\
+   .peer = &_platform##_##_name_active,  \
+   .valid_state_mask = _state_mask,  \
+   .hw.init = &(struct clk_init_data){   \
+   .ops = &clk_rpmh_ops, \
+   .name = #_name,   \
+   },\
+   };\
+   static struct clk_rpmh _platform##_##_name_active = { \
+   .res_name = _res_name,\
+   .res_en_offset = _res_e

[[PATCH v2] 2/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

[Taniya Das]

From: Amit Nischal 

Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These
devices would be used for communicating resource state requests to control
the clocks managed by RPMh.

Signed-off-by: Amit Nischal 
Signed-off-by: Taniya Das 
---
 .../devicetree/bindings/clock/qcom,rpmh-clk.txt| 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt

diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt 
b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt
new file mode 100644
index 000..4ade82b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt
@@ -0,0 +1,22 @@
+Qualcomm Technologies, Inc. RPMh Clocks
+---
+
+Resource Power Manager Hardened (RPMh) manages shared resources on
+some Qualcomm Technologies Inc. SoCs. It accepts clock requests from
+other hardware subsystems via RSC to control clocks.
+
+Required properties :
+- compatible : shall contain "qcom,rpmh-clk-sdm845"
+
+- #clock-cells : must contain 1
+
+Example :
+
+#include 
+
+   &apps_rsc {
+   rpmh: clock-controller {
+   compatible = "qcom,rpmh-clk-sdm845";
+   #clock-cells = <1>;
+   };
+   };
-- 
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.

Re: WARNING in kmem_cache_free

[Dmitry Vyukov]

On Sun, Apr 8, 2018 at 12:26 PM, Dmitry Vyukov  wrote:
> On Sun, Apr 8, 2018 at 8:01 AM, Matthew Wilcox  wrote:
>> On Fri, Apr 06, 2018 at 03:33:36PM +0200, Dmitry Vyukov wrote:
>>> On Fri, Apr 6, 2018 at 3:24 PM, syzbot
>>>  wrote:
>>> > Unfortunately, I don't have any reproducer for this crash yet.
>>>
>>> Interesting type of bug, I think we see this for the first time.
>>
>> Can you focus syzbot to try to find a reproducer?  This seems to be
>> produced by calling mount() with a pathname that's somewhere between,
>> say, 3950 & 4100 bytes long from a compat 32-bit task.
>
>
> Something in the log definitely triggers a very bad heap corruption.
>
> This can be reproduced following instructions at:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers
>
> and then running:
> ./syz-execprog -sandbox=namespace -arch=386 -repeat=0 -procs=10 log.txt
>
> where log.txt comes from "Raw console output" link.
>
> Note that you need to build syzkaller with 'make TARGETARCH=386' and
> the use bin/linux_386/syz-executor.
>
> While running it I got:
> BUG: KASAN: double-free or invalid-free in free_request_size+0x5b/0x70
> block/blk-core.c:769
> https://gist.githubusercontent.com/dvyukov/05f4e77a34795d329aa7a2f40265e396/raw/63a29123b79f1fbad3521d0ff034946be68bfd4a/gistfile1.txt
>
> Then kernel BUG at mm/slab.c:4407!
> https://gist.githubusercontent.com/dvyukov/5b3bcc90d326e9da3636aea2c95ace8f/raw/1589504c708994936681d61ba9d70029998b9b1a/gistfile1.txt
>
> And then BUG: unable to handle kernel paging request at ebe00020
> https://gist.githubusercontent.com/dvyukov/72025b1c68e488f4fda243e0c152f044/raw/d2c171bc55ad3a43cea33095fa2eea48768b1131/gistfile1.txt
>
> One interesting thing is that if I run the log once and it does not
> crash, then when I try to start binary again I am getting:
> [  456.837870] Invalid argument reading file caps for /root/syz-executor
> The binary somehow becomes broken on disk...
>
> I guess syzbot did find a reproducer in this log, but did not
> attribute it to this bug as it causes crashes all over the place.



Running syz-repro utility on this log, I think I've found the guilty guy:
https://gist.githubusercontent.com/dvyukov/1dd75d55efd238e7207af1cc38478b3a/raw/403859b56b161a6fbb158e8953fac5bb6e73b1a1/gistfile1.txt

It crashes as:
BUG: KASAN: use-after-free in drbg_kcapi_seed+0x1178/0x12e0
and:
BUG: unable to handle kernel paging request at ebe00020
and with other indications of badly corrupted heap.

This points to crypto/drbg.c, so +crypto maintainers.

Re: [PATCH/RFC] soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure

[Stefan Wahren]

Hi Geert,

[add Phil]

> Geert Uytterhoeven  hat am 8. April 2018 um 11:05 
> geschrieben:
> 
> 
> If CONFIG_RASPBERRYPI_FIRMWARE=n:
> 
> drivers/gpio/gpio-raspberrypi-exp.c: In function 
> ‘rpi_exp_gpio_get_polarity’:
> drivers/gpio/gpio-raspberrypi-exp.c:71: warning: ‘get.polarity’ is used 
> uninitialized in this function
> drivers/gpio/gpio-raspberrypi-exp.c: In function 
> ‘rpi_exp_gpio_get_direction’:
> drivers/gpio/gpio-raspberrypi-exp.c:150: warning: ‘get.direction’ is used 
> uninitialized in this function
> 
> The dummy firmware interface functions return 0, which means success,
> causing subsequent code to make use of the never initialized output
> parameter.

i think this is more theoritical, because we need to get rpi_firmware first and 
in this case it's NULL.

> 
> Fix this by making the dummy functions return an error code (-ENOSYS)
> instead.

Anyway i'm okay with the change.

> 
> Note that this assumes the firmware always fills in the requested data
> in the CONFIG_RASPBERRYPI_FIRMWARE=y case.

Unfortunately i don't know.

> 
> Fixes: d45f1a563b92dac7 ("staging: vc04_services: fix up rpi firmware 
> functions")
> Signed-off-by: Geert Uytterhoeven 
> ---
> Should get.polarity resp. get.direction be preinitialized instead,
> like is done for get.state?
> 
> static int rpi_exp_gpio_get(struct gpio_chip *gc, unsigned int off)
> {
> ...
> get.state = 0;  /* storage for returned value */
> 
> ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_STATE,
>  &get, sizeof(get));
> ...
> }
> 
> This would avoid returning uninitialized data if the firmware did not
> fill in the requested data.
> ---
>  include/soc/bcm2835/raspberrypi-firmware.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
> b/include/soc/bcm2835/raspberrypi-firmware.h
> index 50df5b28d2c9df6e..8ee8991aa099af3a 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -143,13 +143,13 @@ struct rpi_firmware *rpi_firmware_get(struct 
> device_node *firmware_node);
>  static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
>   void *data, size_t len)
>  {
> - return 0;
> + return -ENOSYS;
>  }
>  
>  static inline int rpi_firmware_property_list(struct rpi_firmware *fw,
>void *data, size_t tag_size)
>  {
> - return 0;
> + return -ENOSYS;
>  }
>  
>  static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
> *firmware_node)
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH for-next v2] tracing: optimize trace_buffer_iter()

[yuan linyu]

From: yuan linyu 

use conditional operation.

Signed-off-by: yuan linyu 
---
 kernel/trace/trace.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 6fb46a06c9dc..bda717ab2095 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -582,9 +582,7 @@ static __always_inline void trace_clear_recursion(int bit)
 static inline struct ring_buffer_iter *
 trace_buffer_iter(struct trace_iterator *iter, int cpu)
 {
-   if (iter->buffer_iter && iter->buffer_iter[cpu])
-   return iter->buffer_iter[cpu];
-   return NULL;
+   return iter->buffer_iter ? iter->buffer_iter[cpu] : NULL;
 }
 
 int tracer_init(struct tracer *t, struct trace_array *tr);
-- 
2.14.1

[RFC PATCH] x86/acpi: Prevent x2apic id -1 from being accounted

[Li RongQing]

local_apic_id of acpi_madt_local_x2apic is u32, it is converted to
int when checked by default_apic_id_valid() and return true if it is
larger than 0x7fff, this is wrong

and if local_apic_id is invalid, we should prevent it from being
accounted

This fixes a bug that Purley platform displays too many possible cpu

Signed-off-by: Li RongQing 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Dou Liyang 
---
 arch/x86/include/asm/apic.h  |  4 ++--
 arch/x86/kernel/acpi/boot.c  | 10 ++
 arch/x86/kernel/apic/apic_common.c   |  2 +-
 arch/x86/kernel/apic/apic_numachip.c |  2 +-
 arch/x86/kernel/apic/x2apic.h|  2 +-
 arch/x86/kernel/apic/x2apic_phys.c   |  2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c   |  2 +-
 arch/x86/xen/apic.c  |  2 +-
 8 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 40a3d3642f3a..08acd954f00e 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -313,7 +313,7 @@ struct apic {
/* Probe, setup and smpboot functions */
int (*probe)(void);
int (*acpi_madt_oem_check)(char *oem_id, char *oem_table_id);
-   int (*apic_id_valid)(int apicid);
+   int (*apic_id_valid)(u32 apicid);
int (*apic_id_registered)(void);
 
bool(*check_apicid_used)(physid_mask_t *map, int apicid);
@@ -486,7 +486,7 @@ static inline unsigned int read_apic_id(void)
return apic->get_apic_id(reg);
 }
 
-extern int default_apic_id_valid(int apicid);
+extern int default_apic_id_valid(u32 apicid);
 extern int default_acpi_madt_oem_check(char *, char *);
 extern void default_setup_apic_routing(void);
 
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 7a37d9357bc4..7412564dc2a7 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -200,7 +200,7 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, 
const unsigned long end)
 {
struct acpi_madt_local_x2apic *processor = NULL;
 #ifdef CONFIG_X86_X2APIC
-   int apic_id;
+   u32 apic_id;
u8 enabled;
 #endif
 
@@ -222,10 +222,12 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, 
const unsigned long end)
 * to not preallocating memory for all NR_CPUS
 * when we use CPU hotplug.
 */
-   if (!apic->apic_id_valid(apic_id) && enabled)
+   if (!apic->apic_id_valid(apic_id)) {
printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
-   else
-   acpi_register_lapic(apic_id, processor->uid, enabled);
+   return 0;
+   }
+
+   acpi_register_lapic(apic_id, processor->uid, enabled);
 #else
printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
 #endif
diff --git a/arch/x86/kernel/apic/apic_common.c 
b/arch/x86/kernel/apic/apic_common.c
index a360801779ae..02b4839478b1 100644
--- a/arch/x86/kernel/apic/apic_common.c
+++ b/arch/x86/kernel/apic/apic_common.c
@@ -40,7 +40,7 @@ int default_check_phys_apicid_present(int phys_apicid)
return physid_isset(phys_apicid, phys_cpu_present_map);
 }
 
-int default_apic_id_valid(int apicid)
+int default_apic_id_valid(u32 apicid)
 {
return (apicid < 255);
 }
diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index 134e04506ab4..78778b54f904 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -56,7 +56,7 @@ static u32 numachip2_set_apic_id(unsigned int id)
return id << 24;
 }
 
-static int numachip_apic_id_valid(int apicid)
+static int numachip_apic_id_valid(u32 apicid)
 {
/* Trust what bootloader passes in MADT */
return 1;
diff --git a/arch/x86/kernel/apic/x2apic.h b/arch/x86/kernel/apic/x2apic.h
index b107de381cb5..a49b3604027f 100644
--- a/arch/x86/kernel/apic/x2apic.h
+++ b/arch/x86/kernel/apic/x2apic.h
@@ -1,6 +1,6 @@
 /* Common bits for X2APIC cluster/physical modes. */
 
-int x2apic_apic_id_valid(int apicid);
+int x2apic_apic_id_valid(u32 apicid);
 int x2apic_apic_id_registered(void);
 void __x2apic_send_IPI_dest(unsigned int apicid, int vector, unsigned int 
dest);
 unsigned int x2apic_get_apic_id(unsigned long id);
diff --git a/arch/x86/kernel/apic/x2apic_phys.c 
b/arch/x86/kernel/apic/x2apic_phys.c
index e2829bf40e4a..b5cf9e7b3830 100644
--- a/arch/x86/kernel/apic/x2apic_phys.c
+++ b/arch/x86/kernel/apic/x2apic_phys.c
@@ -101,7 +101,7 @@ static int x2apic_phys_probe(void)
 }
 
 /* Common x2apic functions, also used by x2apic_cluster */
-int x2apic_apic_id_valid(int apicid)
+int x2apic_apic_id_valid(u32 apicid)
 {
return 1;
 }
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index f11910b44638..efaf2d4f9c3c 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -557,7 +557,7 @@ static void uv_send_IPI_all(int vector)
uv_send_IPI_mask(cpu_online_mask, vec

Re: [PATCH v4 1/1] can: ucan: add driver for Theobroma Systems UCAN devices

[Wolfgang Grandegger]

Hello Jacob,

just a few minor issues and a question about bus-off handling...

Am 03.04.2018 um 16:35 schrieb Jakob Unterwurzacher:
> The UCAN driver supports the microcontroller-based USB/CAN
> adapters from Theobroma Systems. There are two form-factors
> that run essentially the same firmware:
> 
> * Seal: standalone USB stick ( https://www.theobroma-systems.com/seal )
> 
> * Mule: integrated on the PCB of various System-on-Modules from
>   Theobroma Systems like the A31-µQ7 and the RK3399-Q7
>   ( https://www.theobroma-systems.com/rk3399-q7 )
> 
> The USB wire protocol has been designed to be as generic and
> hardware-indendent as possible in the hope of being useful for
> implementation on other microcontrollers.
> 
> Signed-off-by: Martin Elshuber 
> Signed-off-by: Jakob Unterwurzacher 
> 
> Signed-off-by: Philipp Tomsich 
> ---
>  Documentation/networking/can_ucan_protocol.rst |  315 +
>  Documentation/networking/index.rst |1 +
>  drivers/net/can/usb/Kconfig|   10 +
>  drivers/net/can/usb/Makefile   |1 +
>  drivers/net/can/usb/ucan.c | 1596 
> 
>  5 files changed, 1923 insertions(+)
>  create mode 100644 Documentation/networking/can_ucan_protocol.rst
>  create mode 100644 drivers/net/can/usb/ucan.c
> 
[..snip..]

> diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
> index c36f4bdcbf4f..490cdce1f1da 100644
> --- a/drivers/net/can/usb/Kconfig
> +++ b/drivers/net/can/usb/Kconfig
> @@ -89,4 +89,14 @@ config CAN_MCBA_USB
> This driver supports the CAN BUS Analyzer interface
> from Microchip (http://www.microchip.com/development-tools/).
>  
> +config CAN_UCAN
> + tristate "Theobroma Systems UCAN interface"
> + ---help---
> +   This driver supports the Theobroma Systems
> +   UCAN USB-CAN interface.
> +
> +   UCAN is an microcontroller-based USB-CAN interface that
> +   is integrated on System-on-Modules made by Theobroma Systems
> +   (https://www.theobroma-systems.com/som-products).
> +
>  endmenu
> diff --git a/drivers/net/can/usb/Makefile b/drivers/net/can/usb/Makefile
> index 49ac7b99ba32..4176e8358232 100644
> --- a/drivers/net/can/usb/Makefile
> +++ b/drivers/net/can/usb/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_CAN_KVASER_USB) += kvaser_usb.o
>  obj-$(CONFIG_CAN_PEAK_USB) += peak_usb/
>  obj-$(CONFIG_CAN_8DEV_USB) += usb_8dev.o
>  obj-$(CONFIG_CAN_MCBA_USB) += mcba_usb.o
> +obj-$(CONFIG_CAN_UCAN) += ucan.o
> diff --git a/drivers/net/can/usb/ucan.c b/drivers/net/can/usb/ucan.c
> new file mode 100644
> index ..bb2d62dcbd7b
> --- /dev/null
> +++ b/drivers/net/can/usb/ucan.c
> @@ -0,0 +1,1596 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/* Driver for Theobroma Systems UCAN devices, Protocol Version 3
> + *
> + * Copyright (C) 2018 Theobroma Systems Design und Consulting GmbH
> + *
> + *
> + * General Description:
> + *
> + * The USB Device uses three Endpoints:
> + *
> + *   CONTROL Endpoint: Is used the setup the device (start, stop,
> + *   info, configure).
> + *
> + *   IN Endpoint: The device sends CAN Frame Messages and Device
> + *   Information using the IN endpoint.
> + *
> + *   OUT Endpoint: The driver sends configuration requests, and CAN
> + *   Frames on the out endpoint.
> + *
> + * Error Handling:
> + *
> + *   If error reporting is turned on the device encodes error into CAN
> + *   error frames (see uapi/linux/can/error.h) and sends it using the
> + *   IN Endpoint. The driver updates statistics and forward it.
> + */
> +
> +#include 

[...snip...]

> +static struct ucan_urb_context *ucan_alloc_context(struct ucan_priv *up)
> +{
> + int i;
> + unsigned long flags;
> + struct ucan_urb_context *ret = NULL;
> +
> + if (WARN_ON_ONCE(!up->context_array))
> + return NULL;
> +
> + /* execute context operation atomically */
> + spin_lock_irqsave(&up->context_lock, flags);
> +
> + for (i = 0; i < up->device_info.tx_fifo; i++) {
> + if (!up->context_array[i].allocated) {
> + /* update context */
> + ret = &up->context_array[i];
> + up->context_array[i].allocated = true;
> +
> + /* stop queue if necessary */
> + up->available_tx_urbs--;
> + if (!up->available_tx_urbs)
> + netif_stop_queue(up->netdev);
> +
> + goto done_restore;

break instead of goto!?

> + }
> + }
> +
> +done_restore:
> + spin_unlock_irqrestore(&up->context_lock, flags);
> + return ret;
> +}
> +
> +static bool ucan_release_context(struct ucan_priv *up,
> +  struct ucan_urb_context *ctx)
> +{
> + unsigned long flags;
> + bool ret = false;
> +
> + if (WARN_ON_ONCE(!up->context_array))
> + return false;
> +
> + /* execute context operation atomically */

[PATCH] thermal: tegra: soctherm: add const to struct thermal_cooling_device_ops

[srplinux2008]

From: srp linux 

Correct the typecast with const to struct thermal_cooling_device_ops.
It is the last argument to the function thermal_of_cooling_device_register
and this argument is of type const. So, declare this structure
thermal_cooling_device_ops as constant.

Signed-off-by: srp linux 
---
 drivers/thermal/tegra/soctherm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 455b58c..72da745 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -926,7 +926,7 @@ static int throt_set_cdev_state(struct 
thermal_cooling_device *cdev,
return 0;
 }
 
-static struct thermal_cooling_device_ops throt_cooling_ops = {
+static const struct thermal_cooling_device_ops throt_cooling_ops = {
.get_max_state = throt_get_cdev_max_state,
.get_cur_state = throt_get_cdev_cur_state,
.set_cur_state = throt_set_cdev_state,
-- 
2.7.4

Re: [PATCH 14/15] ARM: pxa: change SSP devices allocation

[Robert Jarzmik]

Arnd Bergmann  writes:

> I don't know exactly how the probing works, but I'd assume that we have
> the correct device pointers in pxa2xx_ac97_dev_probe() and
> asoc_ssp_probe(), or maybe in pxa2xx_ac97_*_startup() and
> pxa_ssp_startup().

Yes, let's try this way, in the former patch

"ASoC: pxa: remove the dmaengine compat need" :
+++ b/sound/arm/pxa2xx-pcm-lib.c
@@ -126,7 +127,7 @@ int __pxa2xx_pcm_open(struct snd_pcm_substream *substream)
return ret;
 
return snd_dmaengine_pcm_open(
-   substream, dma_request_slave_channel(rtd->platform->dev,
+   substream, dma_request_slave_channel(rtd->cpu_dai->dev,
 dma_params->chan_name));
 }

The cpu_dai device should be either pxa27x_ac97 or pxa-ssp-dai., and amend
the dma slave map accordingly.

Cheers.

-- 
Robert

[PATCH] f2fs: don't split checkpoint in fstrim

[Chao Yu]

From: Chao Yu 

Now, we issue discard asynchronously in separated thread instead of in
checkpoint, after that, we won't encounter long latency in checkpoint
due to huge number of synchronous discard command handling, so, we don't
need to split checkpoint to do trim in batch, merge it and obsolete
related sysfs entry.

Signed-off-by: Chao Yu 
---
 Documentation/ABI/testing/sysfs-fs-f2fs |  1 +
 fs/f2fs/f2fs.h  |  5 -
 fs/f2fs/segment.c   | 33 +
 fs/f2fs/sysfs.c |  3 +++
 4 files changed, 13 insertions(+), 29 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 540553c933b6..372b88f4e706 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -101,6 +101,7 @@ Date:   February 2015
 Contact:   "Jaegeuk Kim" 
 Description:
 Controls the trimming rate in batch mode.
+
 
 What:  /sys/fs/f2fs//cp_interval
 Date:  October 2015
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0aaf70955c77..f414f7ab8ddb 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -178,11 +178,6 @@ enum {
 #defineCP_DISCARD  0x0010
 #define CP_TRIMMED 0x0020
 
-#define DEF_BATCHED_TRIM_SECTIONS  2048
-#define BATCHED_TRIM_SEGMENTS(sbi) \
-   (GET_SEG_FROM_SEC(sbi, SM_I(sbi)->trim_sections))
-#define BATCHED_TRIM_BLOCKS(sbi)   \
-   (BATCHED_TRIM_SEGMENTS(sbi) << (sbi)->log_blocks_per_seg)
 #define MAX_DISCARD_BLOCKS(sbi)BLKS_PER_SEC(sbi)
 #define DEF_MAX_DISCARD_REQUEST8   /* issue 8 discards per 
round */
 #define DEF_MIN_DISCARD_ISSUE_TIME 50  /* 50 ms, if exists */
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 2aff7834d821..7150ab22f968 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2450,30 +2450,17 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct 
fstrim_range *range)
 
cpc.reason = CP_DISCARD;
cpc.trim_minlen = max_t(__u64, 1, F2FS_BYTES_TO_BLK(range->minlen));
+   cpc.trim_start = start_segno;
+   cpc.trim_end = end_segno;
 
-   /* do checkpoint to issue discard commands safely */
-   for (cur_segno = start_segno; cur_segno <= end_segno;
-   cur_segno = cpc.trim_end + 1) {
-   cpc.trim_start = cur_segno;
-
-   if (sbi->discard_blks == 0)
-   break;
-   else if (sbi->discard_blks < BATCHED_TRIM_BLOCKS(sbi))
-   cpc.trim_end = end_segno;
-   else
-   cpc.trim_end = min_t(unsigned int,
-   rounddown(cur_segno +
-   BATCHED_TRIM_SEGMENTS(sbi),
-   sbi->segs_per_sec) - 1, end_segno);
-
-   mutex_lock(&sbi->gc_mutex);
-   err = write_checkpoint(sbi, &cpc);
-   mutex_unlock(&sbi->gc_mutex);
-   if (err)
-   break;
+   if (sbi->discard_blks == 0)
+   goto out;
 
-   schedule();
-   }
+   mutex_lock(&sbi->gc_mutex);
+   err = write_checkpoint(sbi, &cpc);
+   mutex_unlock(&sbi->gc_mutex);
+   if (err)
+   goto out;
 
start_block = START_BLOCK(sbi, start_segno);
end_block = START_BLOCK(sbi, min(cur_segno, end_segno) + 1);
@@ -3869,8 +3856,6 @@ int build_segment_manager(struct f2fs_sb_info *sbi)
sm_info->min_hot_blocks = DEF_MIN_HOT_BLOCKS;
sm_info->min_ssr_sections = reserved_sections(sbi);
 
-   sm_info->trim_sections = DEF_BATCHED_TRIM_SECTIONS;
-
INIT_LIST_HEAD(&sm_info->sit_entry_set);
 
init_rwsem(&sm_info->curseg_lock);
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index ab54990d057d..2130d9b031a2 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -251,6 +251,9 @@ static ssize_t f2fs_sbi_store(struct f2fs_attr *a,
return count;
}
 
+   if (!strcmp(a->attr.name, "trim_sections"))
+   return -EINVAL;
+
*ui = t;
 
if (!strcmp(a->attr.name, "iostat_enable") && *ui == 0)
-- 
2.16.2.17.g38e79b1fd

[PATCH v3] backlight: otm3225a: add support for ORISE OTM3225A LCD SoC

[Felix Brack]

This patch adds a LCD driver supporting the OTM3225A LCD SoC
from ORISE Technology. This device can drive TFT LC panels having a
resolution of 240x320 pixels. After initializing the OTM3225A using
it's SPI interface it switches to use 16-bib RGB as external
display interface.

Signed-off-by: Felix Brack 
Acked-by: Daniel Thompson 

Changes in v3:
- fix a type in a comment
- don't make useless calls to msleep() by callig it with delay 0
- add Daniel Thompson's Acked-by

Changes in v2:
- use descriptive names for registers instead of hard coding them
- remove unnecessary registers in initialization sequence
- make use of resource-managed functions like devm_kzalloc()
  instead of kzalloc() which simplifies and shortens the code
- replace mdelay() by msleep()
- use module_spi_init() since we do not do anything special
  in init/exit
- use dev_name() instead of hard coding driver name multiple times
- use static storage class for structure otm3225a_ops
- sort include files alphabetically
- use standardized licensing header
- modify Makefile respecting alphabetical sort order
---
 drivers/video/backlight/Kconfig|   7 ++
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/otm3225a.c | 252 +
 3 files changed, 260 insertions(+)
 create mode 100644 drivers/video/backlight/otm3225a.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 4e1d2ad..06e187b 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -150,6 +150,13 @@ config LCD_HX8357
  If you have a HX-8357 LCD panel, say Y to enable its LCD control
  driver.
 
+  config LCD_OTM3225A
+   tristate "ORISE Technology OTM3225A support"
+   depends on SPI
+   help
+ If you have a panel based on the OTM3225A controller
+ chip then say y to include a driver for it.
+
 endif # LCD_CLASS_DEVICE
 
 #
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 8905129..2473377 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_LCD_LD9040)  += ld9040.o
 obj-$(CONFIG_LCD_LMS283GF05)   += lms283gf05.o
 obj-$(CONFIG_LCD_LMS501KF03)   += lms501kf03.o
 obj-$(CONFIG_LCD_LTV350QV) += ltv350qv.o
+obj-$(CONFIG_LCD_OTM3225A) += otm3225a.o
 obj-$(CONFIG_LCD_PLATFORM) += platform_lcd.o
 obj-$(CONFIG_LCD_S6E63M0)  += s6e63m0.o
 obj-$(CONFIG_LCD_TDO24M)   += tdo24m.o
diff --git a/drivers/video/backlight/otm3225a.c 
b/drivers/video/backlight/otm3225a.c
new file mode 100644
index 000..2472e21
--- /dev/null
+++ b/drivers/video/backlight/otm3225a.c
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Driver for ORISE Technology OTM3225A SOC for TFT LCD
+ * Copyright (C) 2017, EETS GmbH, Felix Brack 
+ *
+ * This driver implements a lcd device for the ORISE OTM3225A display
+ * controller. The control interface to the display is SPI and the display's
+ * memory is updated over the 16-bit RGB interface.
+ * The main source of information for writing this driver was provided by the
+ * OTM3225A datasheet from ORISE Technology. Some information arise from the
+ * ILI9328 datasheet from ILITEK as well as from the datasheets and sample code
+ * provided by Crystalfontz America Inc. who sells the CFAF240320A-032T, a 3.2"
+ * TFT LC display using the OTM3225A controller.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define OTM3225A_INDEX_REG 0x70
+#define OTM3225A_DATA_REG  0x72
+
+/* instruction register list */
+#define DRIVER_OUTPUT_CTRL_1   0x01
+#define DRIVER_WAVEFORM_CTRL   0x02
+#define ENTRY_MODE 0x03
+#define SCALING_CTRL   0x04
+#define DISPLAY_CTRL_1 0x07
+#define DISPLAY_CTRL_2 0x08
+#define DISPLAY_CTRL_3 0x09
+#define FRAME_CYCLE_CTRL   0x0A
+#define EXT_DISP_IFACE_CTRL_1  0x0C
+#define FRAME_MAKER_POS0x0D
+#define EXT_DISP_IFACE_CTRL_2  0x0F
+#define POWER_CTRL_1   0x10
+#define POWER_CTRL_2   0x11
+#define POWER_CTRL_3   0x12
+#define POWER_CTRL_4   0x13
+#define GRAM_ADDR_HORIZ_SET0x20
+#define GRAM_ADDR_VERT_SET 0x21
+#define GRAM_READ_WRITE0x22
+#define POWER_CTRL_7   0x29
+#define FRAME_RATE_CTRL0x2B
+#define GAMMA_CTRL_1   0x30
+#define GAMMA_CTRL_2   0x31
+#define GAMMA_CTRL_3   0x32
+#define GAMMA_CTRL_4   0x35
+#define GAMMA_CTRL_5   0x36
+#define GAMMA_CTRL_6   0x37
+#define GAMMA_CTRL_7   0x38
+#define GAMMA_CTRL_8   0x39
+#define GAMMA_CTRL_9   0x3C
+#define GAMMA_CTRL_10  0x3D
+#define WINDOW_HORIZ_RAM_START 0x50
+#define WINDOW_HORIZ_RAM_END   0x51
+#define WINDOW_VERT_RAM_START  0x52
+#define WINDOW_VERT_RAM_END0x53
+#define DRIVER_OUTPUT_CTRL_2   0x60
+#

[PATCH] f2fs: correct return value of f2fs_trim_fs

[Chao Yu]

From: Chao Yu 

Correct return value in two cases:
- return EINVAL if end boundary is out-of-range.
- return EIO if fs needs off-line check.

Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 7150ab22f968..876dd9a511af 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2435,12 +2435,12 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct 
fstrim_range *range)
return -EINVAL;
 
if (end <= MAIN_BLKADDR(sbi))
-   goto out;
+   return -EINVAL;
 
if (is_sbi_flag_set(sbi, SBI_NEED_FSCK)) {
f2fs_msg(sbi->sb, KERN_WARNING,
"Found FS corruption, run fsck to fix.");
-   goto out;
+   return -EIO;
}
 
/* start/end segment number in main_area */
-- 
2.16.2.17.g38e79b1fd

Re: [GIT PULL] SELinux patches for v4.17

[Paul Moore]

On April 8, 2018 2:13:51 AM Xin Long  wrote:
On Sat, Apr 7, 2018 at 7:07 AM, Linus Torvalds
 wrote:
On Tue, Apr 3, 2018 at 6:37 PM, Paul Moore  wrote:

Everything passes the selinux-testsuite, but there are a few known
merge conflicts.  The first is with the netdev tree and is in
net/sctp/socket.c.  Unfortunately it is a bit ugly, thankfully Stephen
Rothwell has already done the heavy lifting in resolving the merge for
you, and the SCTP folks have given his merge patch a thumbs-up.

I ended up re-doing the merge, and it looks like some more sctp
changes happened after Stephen's merge anyway, so mine didn't end up
quite like his.
You're right, a sctp fix went into net-next after Stephen's that merge.
https://patchwork.ozlabs.org/patch/884469/ (v1)
https://patchwork.ozlabs.org/patch/884971/ (v2)

Which caused the resolution to have changed again.

I've checked the new resolution on your tree, the SCTP part is all good.

Thanks for double checking that Xin.

--
paul moore
www.paul-moore.com

Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN

[Steven Rostedt]

On Sun, 8 Apr 2018 13:54:59 +0800
Zhaoyang Huang  wrote:

> On Sun, Apr 8, 2018 at 11:48 AM, Steven Rostedt  wrote:
> > On Sun,  8 Apr 2018 10:16:23 +0800
> > Zhaoyang Huang  wrote:
> >  
> >> Don't choose the process with adj == OOM_SCORE_ADJ_MIN which
> >> over-allocating pages for ring buffers.  
> >
> > Why?
> >
> > -- Steve  
> because in oom_evaluate_task, the process with adj == OOM_SCORE_ADJ_MIN will
> be suppressed by oom_badness, but with applying your latest patch,
> such process will
> be selected by oom_task_origin
> 
> if (oom_task_origin(task)) {
> points = ULONG_MAX;
> goto select;
> }
> 
> points = oom_badness(task, NULL, oc->nodemask, oc->totalpages);
> if (!points || points < oc->chosen_points)
> goto next;

And what's wrong with that?

-- Steve

Re: [GIT PULL] SELinux patches for v4.17

[Paul Moore]

On April 7, 2018 1:03:57 PM Linus Torvalds  
wrote:
On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines
 wrote:

So please check my resolution, but also somebody should tell me
"Linus, you're a cretin, sctp_connect() doesn't want that
security_sctp_bind_connect() at all because it was already done by
XYZ"

sctp_connect() or __sctp_connect() do not need to call
security_sctp_bind_connect(). This is because the connect(2) call will
handle the checks required via security_socket_connect():

Ok, thanks, that's exactly what I wanted to get.

Anyway, somebody should still verify that it all looks good in my
tree, but I don't actually expect the merge to have had any issues
even if the refactoring made it a bit more complex than most merges
are.

Thanks for the quick response Richard.

Xin Long looked it over and gave it the thumbs up, I'll take a look too, but to 
be honest I trust his SCTP understanding much more than mine.  I also do weekly 
tests of each rcX release at a minimum so if something odd pops up I'll make 
sure you get a fix.

Thanks again everyone.

--
paul moore
www.paul-moore.com

Re: INFO: rcu detected stall in io_playback_transfer

[Tetsuo Handa]

I manually simplified the reproducer.

It is quite strange that removing unshare() hides this lockup bug.
Also, explicitly closing by "close()" hides this lockup bug.
Triggering "fput() from do_exit()" from "different namespace"
somehow affects this lockup bug?


#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
const int fd = open("/dev/dsp1", O_RDWR);
int frag = (0 << 16) | 0;
char buf[48] = { };
unshare(CLONE_NEWNS);
ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &frag);
write(fd, buf, sizeof(buf));
return 0;
}

Re: INFO: rcu detected stall in io_playback_transfer

[Dmitry Vyukov]

On Sun, Apr 8, 2018 at 2:58 PM, Tetsuo Handa
 wrote:
> I manually simplified the reproducer.
>
> It is quite strange that removing unshare() hides this lockup bug.
> Also, explicitly closing by "close()" hides this lockup bug.
> Triggering "fput() from do_exit()" from "different namespace"
> somehow affects this lockup bug?
>
> 
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
> const int fd = open("/dev/dsp1", O_RDWR);
> int frag = (0 << 16) | 0;
> char buf[48] = { };
> unshare(CLONE_NEWNS);
> ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &frag);
> write(fd, buf, sizeof(buf));
> return 0;
> }
> 


Takashi has already fixed this. See this thread:
https://groups.google.com/forum/#!searchin/syzkaller-bugs/%22INFO$3A$20rcu$20detected$20stall$20in$20snd_pcm_oss_write3$20(2)%22%7Csort:date/syzkaller-bugs/D2xWV7WTRDk/sCw_gImmCAAJ

The fix commit includes tag this bug:
Reported-by: syzbot+4f2016cf5185da775...@syzkaller.appspotmail.com
But it's just that it's mentioned in the thread for another bug.

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

[Mickaël Salaün]

On 02/27/2018 10:48 PM, Mickaël Salaün wrote:
> 
> On 27/02/2018 17:39, Andy Lutomirski wrote:
>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
>>  wrote:
>>> On Tue, Feb 27, 2018 at 05:20:55AM +, Andy Lutomirski wrote:
 On Tue, Feb 27, 2018 at 4:54 AM, Alexei Starovoitov
  wrote:
> On Tue, Feb 27, 2018 at 04:40:34AM +, Andy Lutomirski wrote:
>> On Tue, Feb 27, 2018 at 2:08 AM, Alexei Starovoitov
>>  wrote:
>>> On Tue, Feb 27, 2018 at 01:41:15AM +0100, Mickaël Salaün wrote:
 The seccomp(2) syscall can be used by a task to apply a Landlock 
 program
 to itself. As a seccomp filter, a Landlock program is enforced for the
 current task and all its future children. A program is immutable and a
 task can only add new restricting programs to itself, forming a list of
 programss.

 A Landlock program is tied to a Landlock hook. If the action on a 
 kernel
 object is allowed by the other Linux security mechanisms (e.g. DAC,
 capabilities, other LSM), then a Landlock hook related to this kind of
 object is triggered. The list of programs for this hook is then
 evaluated. Each program return a 32-bit value which can deny the action
 on a kernel object with a non-zero value. If every programs of the list
 return zero, then the action on the object is allowed.

 Multiple Landlock programs can be chained to share a 64-bits value for 
 a
 call chain (e.g. evaluating multiple elements of a file path).  This
 chaining is restricted when a process construct this chain by loading a
 program, but additional checks are performed when it requests to apply
 this chain of programs to itself.  The restrictions ensure that it is
 not possible to call multiple programs in a way that would imply to
 handle multiple shared values (i.e. cookies) for one chain.  For now,
 only a fs_pick program can be chained to the same type of program,
 because it may make sense if they have different triggers (cf. next
 commits).  This restrictions still allows to reuse Landlock programs in
 a safe way (e.g. use the same loaded fs_walk program with multiple
 chains of fs_pick programs).

 Signed-off-by: Mickaël Salaün 
>>>
>>> ...
>>>
 +struct landlock_prog_set *landlock_prepend_prog(
 + struct landlock_prog_set *current_prog_set,
 + struct bpf_prog *prog)
 +{
 + struct landlock_prog_set *new_prog_set = current_prog_set;
 + unsigned long pages;
 + int err;
 + size_t i;
 + struct landlock_prog_set tmp_prog_set = {};
 +
 + if (prog->type != BPF_PROG_TYPE_LANDLOCK_HOOK)
 + return ERR_PTR(-EINVAL);
 +
 + /* validate memory size allocation */
 + pages = prog->pages;
 + if (current_prog_set) {
 + size_t i;
 +
 + for (i = 0; i < ARRAY_SIZE(current_prog_set->programs); 
 i++) {
 + struct landlock_prog_list *walker_p;
 +
 + for (walker_p = current_prog_set->programs[i];
 + walker_p; walker_p = 
 walker_p->prev)
 + pages += walker_p->prog->pages;
 + }
 + /* count a struct landlock_prog_set if we need to 
 allocate one */
 + if (refcount_read(¤t_prog_set->usage) != 1)
 + pages += round_up(sizeof(*current_prog_set), 
 PAGE_SIZE)
 + / PAGE_SIZE;
 + }
 + if (pages > LANDLOCK_PROGRAMS_MAX_PAGES)
 + return ERR_PTR(-E2BIG);
 +
 + /* ensure early that we can allocate enough memory for the new
 +  * prog_lists */
 + err = store_landlock_prog(&tmp_prog_set, current_prog_set, prog);
 + if (err)
 + return ERR_PTR(err);
 +
 + /*
 +  * Each task_struct points to an array of prog list pointers.  
 These
 +  * tables are duplicated when additions are made (which means 
 each
 +  * table needs to be refcounted for the processes using it). 
 When a new
 +  * table is created, all the refcounters on the prog_list are 
 bumped (to
 +  * track each table that references the prog). When a new prog is
 +  * added, it's just prepended to the list for the new table to 
 point
 +  * at.
 +  *
 +  * Manage all the possible errors before this step to not 
 uselessly

Re: Running syzkaller repros using kvm-xfstests

[Dmitry Vyukov]

On Sun, Apr 8, 2018 at 8:31 AM, Theodore Y. Ts'o  wrote:
> On Thu, Apr 05, 2018 at 09:37:41PM -0400, Theodore Y. Ts'o wrote:
>> Note that I haven't just been complaining about it.  I've been working
>> on ways so that the gce-xfstests and kvm-xfstests test appliances can
>> more easily be used to work on Syzbot reports.  If I can make myself
>> more efficient, or help other people be more efficient, that's
>> arguably more important than trying to fix some of the 174 currently
>> open Syzbot issues --- unless you can tell me that certain ones are
>> super urgent because they (for example) result in CVSS score > 8.
>
> I've got an initial version of this working for kvm-xfstests.  To try
> it out, grab the latest version of xfstests-bld from [1], and the
> kvm-xfstests image from [2].  For people who have never tried using
> kvm-xfstests, see [3].
>
> [1] https://github.com/tytso/xfstests-bld
> [2] 
> https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/testing/root_fs.img.x86_64
> [3] 
> https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
>
> If you're interested, please try it out, and send me comments.
>
> Sample usage:
>
> kvm-xfstest syz 
> kvm-xfstest syz 
>
> Example run:
>
> % kvm-xfstests syz 
> https://syzkaller.appspot.com/x/repro.syz?id=5709211904245760

/\/\/\/\/\/\/\/\

Nice!

But note that syzkaller is under active development, so pre-canned
binaries may not always work. Mismatching binary may not understand
all syscalls, fail to parse program, interpret arguments differently,
execute program differently, setup a different environment for the
test, etc. Now a C program captures all of this, because code that
transforms syzkaller programs into C is versioned along with the rest
of the system.
Strictly saying, for syzkaller reproducers one needs to use the exact
syzkaller revision listed along with the reproducer, see for example:
https://syzkaller.appspot.com/bug?id=3fb9c4777053e79a6d2a65ac3738664c87629a21
The "#syz test" syzbot command does this. Using a different syzkaller
revision may or may not work.



>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
> 0100   533  100   5330 0   2157  0 --:--:-- --:--:-- --:--:--  
> 2157
> Saved downloaded copy at /tmp/tytso-downloaded-repro.syz
> Networking disabled.
> KERNEL: kernel  4.16.0-xfstests-09576-g38c23685b273 #134 SMP Sun Apr 8 
> 01:36:01 EDT 2018 x86_64
> FSTESTVER: e2fsprogsv1.43.6-85-g7595699d0 (Wed, 6 Sep 2017 22:04:14 -0400)
> FSTESTVER: fio  fio-3.2 (Fri, 3 Nov 2017 15:23:49 -0600)
> FSTESTVER: quota59b280e (Mon, 5 Feb 2018 16:48:22 +0100)
> FSTESTVER: stress-ng977ae35 (Wed, 6 Sep 2017 23:45:03 -0400)
> FSTESTVER: syzkaller66f22a7f (Sat, 7 Apr 2018 14:02:03 +0200)
> FSTESTVER: xfsprogs v4.15.1 (Mon, 26 Feb 2018 19:50:56 -0600)
> FSTESTVER: xfstests-bld 3be913e (Sun, 8 Apr 2018 01:19:21 -0400)
> FSTESTVER: xfstests linux-v3.8-1925-g62cc6d02 (Fri, 23 Mar 2018 22:26:41 
> -0400)
> FSTESTCFG: "all"
> FSTESTSET: "syz/001"
> FSTESTEXC: ""
> FSTESTOPT: "aex"
> MNTOPTS: ""
> CPUS: "2"
> MEM: "1684.65"
>   totalusedfree  shared  buff/cache   
> available
> Mem:   1684 1401479   8  65
> 1507
> Swap: 0   0   0
> BEGIN TEST 4k (1 test): Ext4 4k block Sun Apr  8 01:49:02 EDT 2018
> DEVICE: /dev/vdd
> EXT_MKFS_OPTIONS: -b 4096
> EXT_MOUNT_OPTIONS: -o block_validity
> FSTYP -- ext4
> PLATFORM  -- Linux/x86_64 kvm-xfstests 4.16.0-xfstests-09576-g38c23685b273
> MKFS_OPTIONS  -- -b 4096 /dev/vdc
> MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc
>
> syz/001 [01:49:04][   22.859794] run fstests syz/001 at 2018-04-08 
> 01:49:04
> [   23.385195] EXT4-fs (vdc): mounted filesystem with ordered data mode. 
> Opts: acl,user_xattr,block_validity
> [   23.797611] EXT4-fs (vda): shut down requested (0)
> [   23.855759] [ cut here ]
> [   23.860823] DEBUG_LOCKS_WARN_ON(sem->owner != get_current())
> [   23.860881] WARNING: CPU: 1 PID: 1332 at 
> /usr/projects/linux/ext4/kernel/locking/rwsem.c:133 up_write+0x113/0x150
> [   23.876121] CPU: 1 PID: 1332 Comm: syz-executor0 Not tainted 
> 4.16.0-xfstests-09576-g38c23685b273 #134
> [   23.880836] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   23.884080] RIP: 0010:up_write+0x113/0x150
> [   23.885873] RSP: 0018:88005e0b7a68 EFLAGS: 00010286
> [   23.887902] RAX: dc08 RBX: 880066069038 RCX: 
> 9002f2ce
> [   23.890392] RDX:  RSI: 0004 RDI: 
> 0293
> [   23.892200] RBP: 8800660690a0 R08: fbfff245d71d R09: 
> fbfff245d71d
> [   23.894877]

Re: INFO: rcu detected stall in io_playback_transfer

[Tetsuo Handa]

Dmitry Vyukov wrote:
> Takashi has already fixed this. See this thread:
> https://groups.google.com/forum/#!searchin/syzkaller-bugs/%22INFO$3A$20rcu$20detected$20stall$20in$20snd_pcm_oss_write3$20(2)%22%7Csort:date/syzkaller-bugs/D2xWV7WTRDk/sCw_gImmCAAJ

Yes, I noticed it just before I post this. But the reason I posted this anyway
is that I feel that there is some other bug revealed by this reproducer.
How can Takashi' patch explain my observation (with linux-next-20180406) ?

/* Hits the stall */
int main(int argc, char *argv[])
{
const int fd = open("/dev/dsp1", O_RDWR);
int frag = (0 << 16) | 0;
char buf[48] = { };
unshare(CLONE_NEWNS);
ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &frag);
write(fd, buf, sizeof(buf));
return 0;
}

/* Does not hit the stall */
int main(int argc, char *argv[])
{
const int fd = open("/dev/dsp1", O_RDWR);
int frag = (0 << 16) | 0;
char buf[48] = { };
ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &frag);
write(fd, buf, sizeof(buf));
return 0;
}

/* Does not hit the stall */
int main(int argc, char *argv[])
{
const int fd = open("/dev/dsp1", O_RDWR);
int frag = (0 << 16) | 0;
char buf[48] = { };
unshare(CLONE_NEWNS);
ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &frag);
write(fd, buf, sizeof(buf));
close(fd);
return 0;
}

[PATCH] firmware: Fix firmware documentation for recent file renames

[Hans de Goede]

firmware_class.c was split into several files under
drivers/base/firmware_loader. The new main.c has the functions which
/request_firmware.rst references.

Signed-off-by: Hans de Goede 
---
 Documentation/driver-api/firmware/request_firmware.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-api/firmware/request_firmware.rst 
b/Documentation/driver-api/firmware/request_firmware.rst
index 61eaa81c61f6..e9557d2eae0a 100644
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -17,17 +17,17 @@ an error is returned.
 
 request_firmware
 
-.. kernel-doc:: drivers/base/firmware_class.c
+.. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: request_firmware
 
 request_firmware_direct
 ---
-.. kernel-doc:: drivers/base/firmware_class.c
+.. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: request_firmware_direct
 
 request_firmware_into_buf
 -
-.. kernel-doc:: drivers/base/firmware_class.c
+.. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: request_firmware_into_buf
 
 Asynchronous firmware requests
@@ -41,7 +41,7 @@ in atomic contexts.
 
 request_firmware_nowait
 ---
-.. kernel-doc:: drivers/base/firmware_class.c
+.. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: request_firmware_nowait
 
 Special optimizations on reboot
@@ -55,7 +55,7 @@ firmare to be loaded.
 
 firmware_request_cache()
 ---
-.. kernel-doc:: drivers/base/firmware_class.c
+.. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: firmware_request_cache
 
 request firmware API expected driver use
-- 
2.17.0

Re: [PATCH] firmware: Fix firmware documentation for recent file renames

[Luis R. Rodriguez]

On Sun, Apr 08, 2018 at 03:47:49PM +0200, Hans de Goede wrote:
> firmware_class.c was split into several files under
> drivers/base/firmware_loader. The new main.c has the functions which
> /request_firmware.rst references.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Luis R. Rodriguez 

  Luis

[PATCH v1 1/1] arm: npcm: enable L2 cache in NPCM7xx architecture

[Tomer Maimon]

Enable ARM L2 cache module in Nuvoton NPCM7xx BMC by adding
L2 cache parameters into NPCM7xx DT machine start structure.

Signed-off-by: Tomer Maimon 
---
 arch/arm/mach-npcm/npcm7xx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-npcm/npcm7xx.c b/arch/arm/mach-npcm/npcm7xx.c
index 5f7cd88103ef..c5f77d854c4f 100644
--- a/arch/arm/mach-npcm/npcm7xx.c
+++ b/arch/arm/mach-npcm/npcm7xx.c
@@ -17,4 +17,6 @@ static const char *const npcm7xx_dt_match[] = {
 DT_MACHINE_START(NPCM7XX_DT, "NPCM7XX Chip family")
.atag_offset= 0x100,
.dt_compat  = npcm7xx_dt_match,
+   .l2c_aux_val= 0x0,
+   .l2c_aux_mask   = ~0x0,
 MACHINE_END
-- 
2.14.1

[PATCH v1 0/1] arm: npcm: enable L2 cache in NPCM7xx architecture

[Tomer Maimon]

This patch Enable ARM L2 cache module in Nuvoton NPCM7xx BMC
by adding L2 cache parameters into NPCM7xx DT machine start structure.

At patch V7 arm: npcm: add basic support for Nuvoton BMCs we got comments
regarding the flags use in L2 cache module.
- https://www.spinics.net/lists/arm-kernel/msg613212.html

After checking again the L2 cache use in the NPCM7xx,
the only L2 cache flag we need to set is L2C_AUX_CTRL_SHARED_OVERRIDE 
and it is done in the device tree:
https://patchwork.kernel.org/patch/10063497/

L2 cache flag mask allowed all the flag option.

Tomer Maimon (1):
  arm: npcm: enable L2 cache in NPCM7xx architecture

 arch/arm/mach-npcm/npcm7xx.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.14.1

Re: [PATCH 3.18 00/93] 3.18.103-stable review

[Guenter Roeck]

On Fri, Apr 06, 2018 at 03:22:29PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.103 release.
> There are 93 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Apr  8 08:42:04 UTC 2018.
> Anything received after that time might be too late.
> 

Not full results this time, sorry (my build system is corrupted),
but there are various build failures in 3.18.y.

drivers/net/ethernet/freescale/fec_main.c: In function 'fec_drv_remove':
drivers/net/ethernet/freescale/fec_main.c:3342:2: error: implicit declaration 
of function 'pm_runtime_put'

and similar.

Guenter

Re: [GIT PULL] SELinux patches for v4.17

[Richard Haines]

On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote:
> On April 7, 2018 1:03:57 PM Linus Torvalds  .org> wrote:
> On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines
>  wrote:
> 
> So please check my resolution, but also somebody should tell me
> "Linus, you're a cretin, sctp_connect() doesn't want that
> security_sctp_bind_connect() at all because it was already done by
> XYZ"
> 
> sctp_connect() or __sctp_connect() do not need to call
> security_sctp_bind_connect(). This is because the connect(2) call
> will
> handle the checks required via security_socket_connect():
> 
> Ok, thanks, that's exactly what I wanted to get.
> 
> Anyway, somebody should still verify that it all looks good in my
> tree, but I don't actually expect the merge to have had any issues
> even if the refactoring made it a bit more complex than most merges
> are.
> 
> Thanks for the quick response Richard.
> 
> Xin Long looked it over and gave it the thumbs up, I'll take a look
> too, but to be honest I trust his SCTP understanding much more than
> mine.  I also do weekly tests of each rcX release at a minimum so if
> something odd pops up I'll make sure you get a fix.
> 
> Thanks again everyone.

I built the kernel this morning and sorry to spoil the party, but I've
run into a problem with lksctp-tools when running the func_tests:

make v6test
..
..
./test_timetolive_v6
test_timetolive.c  0 INFO : Creating fillmsg of size 3087
test_timetolive.c  1 PASS : Send a message with timeout
test_timetolive.c  2 PASS : Send a message with no timeout
test_timetolive.c  3 PASS : Send a fragmented message with timeout
test_timetolive.c  0 INFO :  **  SLEEPING for 3 seconds **
test_timetolive.c  4 BROK : Got a datamsg of unexpected length:23,
expected length:27
DUMP_CORE sctputil.c: 247
/bin/sh: line 1: 30981 Segmentation fault  (core dumped) ./$a
test_timetolive_v6 fails

make v4 test fails the same way. I'm using lksctp-tools from [1]. I
have not investigated the cause yet as just found this and thought I
should flag first just in case someone has the answer !!!

On the bright side, I've run the sctp-tests from [2] with no problems
and also the selinux-testsuite with my SCTP patch from [3] using an
updated Fedora policy from [4] (with sctp support added), all in
enforcing mode.

Also the LTP test passed:
cd /opt/ltp/
cat runtest/syscalls |grep connect01>runtest/connect-syscall
./runltp -pq -f connect-syscall


[1] https://github.com/sctp/lksctp-tools
[2] https://github.com/sctp/sctp-tests
[3] https://marc.info/?l=selinux&m=152156947715709&w=2
[4] https://github.com/fedora-selinux/selinux-policy


> 
> --
> paul moore
> www.paul-moore.com
> 
> 
> 

Re: [PATCH] staging: pi433: add descriptions for mutex locks

[Marcus Wolf]

Hi Valentin,

The hardware of Pi433 is working with every Raspberry Pi (on zero, you
need to solder the GPIO-pins) and with several other fruits like banana
pi. The only thing is, that you need different versions of the driver,
according to the processor, mounted on your fruit.

If you'd like to test more then ther is no hang up or crash, you will
need a second party. You could use a 433MHz socket for testing TX or a
433 thermometer for testing RX. An example code for communication with a
socket is available on the Pi433 productpage (www.pi433.de). The sample
for the thermometer isn't published yet (as always lack of time).

If you want to test more deeply (using different features of the Rf69
chip or even do some long time testing, you have more options, if you
use to Pis with Pi433.

Just let me know, what you'd like to do and what equipment, you need.

Cheers,

Marcus

Am 25.03.2018 um 16:24 schrieb Valentin Vidic:
> On Sun, Mar 25, 2018 at 03:12:52PM +0200, Marcus Wolf wrote:
>> I am not at home the next two weeks. So I can do a codereading on
>> Easter, but testing will not take place earlier then mid/end of April :-(
>>
>> If you are interested, I can provide you an engineering sample of Pi433.
> 
> Sure, let me know which version of Rpi it supports and if I need two
> to test communication.
> 

Re: [PATCH 1/2] clk: at91: Added more information logging.

[Alan Stern]

On Sun, 8 Apr 2018, Marcin wrote:

> I noticed that when debugging some USB clocking issue that there weren't
> many ways to tell what the state of the USB clocking system was. This
> adds a few logging statements to see what the relevant code is trying to
> do.
> 
> Signed-off-by: Marcin Ziemianowicz 

It seems like you have added more debugging lines than necessary.

> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -70,11 +70,12 @@ static const struct ohci_driver_overrides 
> ohci_at91_drv_overrides __initconst =
>  
>  /*-*/
>  
> -static void at91_start_clock(struct ohci_at91_priv *ohci_at91)
> +static void at91_start_clock(struct ohci_at91_priv *ohci_at91, struct device 
> *dev)
>  {
>   if (ohci_at91->clocked)
>   return;
>  
> + dev_dbg(dev, "Enabling hclk, iclk, and setting fclk to 48 Mhz\n");

Here you list all the clocks and give one frequency.

>   clk_set_rate(ohci_at91->fclk, 4800);
>   clk_prepare_enable(ohci_at91->hclk);
>   clk_prepare_enable(ohci_at91->iclk);

> @@ -104,12 +106,19 @@ static void at91_start_hc(struct platform_device *pdev)
>   /*
>* Start the USB clocks.
>*/
> - at91_start_clock(ohci_at91);
> + at91_start_clock(ohci_at91, &pdev->dev);
>  
>   /*
>* The USB host controller must remain in reset.
>*/
>   writel(0, ®s->control);
> +
> + /*
> +  * Say what the clocks are set to.
> +  */
> + dev_dbg(&pdev->dev, "hclk set to: %lu hz\n", 
> clk_get_rate(ohci_at91->hclk));
> + dev_dbg(&pdev->dev, "iclk set to: %lu hz\n", 
> clk_get_rate(ohci_at91->iclk));
> + dev_dbg(&pdev->dev, "fclk set to: %lu hz\n", 
> clk_get_rate(ohci_at91->fclk));

Here you list all the clocks a second time and give all the 
frequencies.

>  }
>  
>  static void at91_stop_hc(struct platform_device *pdev)

Alan Stern

Linux 3.18.103

[Greg KH]

I'm announcing the release of the 3.18.103 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt |9 
 Documentation/filesystems/proc.txt   |   31 
 Makefile |2 
 arch/arm/boot/dts/am335x-pepper.dts  |2 
 arch/arm/boot/dts/dra7-evm.dts   |2 
 arch/arm/boot/dts/omap3-n900.dts |4 
 arch/x86/crypto/cast5_avx_glue.c |3 
 arch/x86/include/asm/vmx.h   |1 
 arch/x86/kernel/kprobes/core.c   |9 
 arch/x86/kvm/vmx.c   |9 
 block/partitions/msdos.c |4 
 crypto/ahash.c   |7 
 drivers/ata/libata-core.c|   26 
 drivers/ata/libata-scsi.c|4 
 drivers/gpu/drm/udl/udl_fb.c |9 
 drivers/input/serio/i8042-x86ia64io.h|   24 
 drivers/leds/led-core.c  |2 
 drivers/md/raid10.c  |1 
 drivers/media/usb/usbtv/usbtv-core.c |2 
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 1020 ++-
 drivers/media/v4l2-core/v4l2-ctrls.c |   96 -
 drivers/media/v4l2-core/v4l2-ioctl.c |5 
 drivers/media/v4l2-core/videobuf2-core.c |5 
 drivers/misc/mei/main.c  |1 
 drivers/mtd/chips/jedec_probe.c  |2 
 drivers/net/can/cc770/cc770.c|  100 -
 drivers/net/can/cc770/cc770.h|2 
 drivers/net/ethernet/arc/emac_rockchip.c |6 
 drivers/net/ethernet/freescale/fec_main.c|2 
 drivers/net/team/team.c  |4 
 drivers/net/wireless/brcm80211/brcmfmac/p2p.c|   24 
 drivers/parport/parport_pc.c |4 
 drivers/pci/pci-driver.c |2 
 drivers/s390/net/qeth_core_main.c|   21 
 drivers/s390/net/qeth_l2_main.c  |2 
 drivers/s390/net/qeth_l3_main.c  |2 
 drivers/scsi/sg.c|5 
 drivers/scsi/virtio_scsi.c   |1 
 drivers/tty/vt/vt.c  |   14 
 drivers/usb/gadget/function/f_hid.c  |   24 
 drivers/usb/gadget/function/f_midi.c |6 
 drivers/usb/gadget/function/f_sourcesink.c   |6 
 drivers/usb/gadget/function/g_zero.h |1 
 drivers/usb/gadget/u_f.c |6 
 drivers/usb/gadget/u_f.h |   26 
 drivers/usb/host/xhci-mem.c  |3 
 drivers/usb/serial/cp210x.c  |1 
 drivers/usb/serial/ftdi_sio.c|2 
 drivers/usb/serial/ftdi_sio_ids.h|9 
 fs/ncpfs/ncplib_kernel.c |4 
 fs/proc/task_mmu.c   |   63 
 fs/proc/task_nommu.c |   43 
 include/linux/mm.h   |3 
 include/linux/netfilter/x_tables.h   |2 
 include/linux/usb/gadget.h   |   17 
 include/uapi/linux/usb/audio.h   |4 
 kernel/events/hw_breakpoint.c|   30 
 kernel/irq/manage.c  |4 
 kernel/kprobes.c |2 
 kernel/trace/trace_kprobe.c  |4 
 kernel/trace/trace_probe.c   |8 
 kernel/trace/trace_probe.h   |2 
 mm/util.c|   27 
 net/bluetooth/smp.c  |8 
 net/bridge/netfilter/ebt_among.c |   34 
 net/core/skbuff

Re: Linux 3.18.103

[Greg KH]

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297bee1fb..c28d4eb83b76 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:
diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index eb8a10e22f7c..04b23a83ce68 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -334,7 +334,7 @@ address   perms offset  dev   inode  pathname
 a7cb1000-a7cb2000 ---p  00:00 0
 a7cb2000-a7eb2000 rw-p  00:00 0
 a7eb2000-a7eb3000 ---p  00:00 0
-a7eb3000-a7ed5000 rw-p  00:00 0  [stack:1001]
+a7eb3000-a7ed5000 rw-p  00:00 0
 a7ed5000-a8008000 r-xp  03:00 4222   /lib/libc.so.6
 a8008000-a800a000 r--p 00133000 03:00 4222   /lib/libc.so.6
 a800a000-a800b000 rw-p 00135000 03:00 4222   /lib/libc.so.6
@@ -366,40 +366,11 @@ is not associated with a file:
 
  [heap]   = the heap of the program
  [stack]  = the stack of the main process
- [stack:1001] = the stack of the thread with tid 1001
  [vdso]   = the "virtual dynamic shared object",
 the kernel system call handler
 
  or if empty, the mapping is anonymous.
 
-The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
-of the individual tasks of a process. In this file you will see a mapping 
marked
-as [stack] if that task sees it as a stack. This is a key difference from the
-content of /proc/PID/maps, where you will see all mappings that are being used
-as stack by all of those tasks. Hence, for the example above, the task-level
-map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like this:
-
-08048000-08049000 r-xp  03:00 8312   /opt/test
-08049000-0804a000 rw-p 1000 03:00 8312   /opt/test
-0804a000-0806b000 rw-p  00:00 0  [heap]
-a7cb1000-a7cb2000 ---p  00:00 0
-a7cb2000-a7eb2000 rw-p  00:00 0
-a7eb2000-a7eb3000 ---p  00:00 0
-a7eb3000-a7ed5000 rw-p  00:00 0  [stack]
-a7ed5000-a8008000 r-xp  03:00 4222   /lib/libc.so.6
-a8008000-a800a000 r--p 00133000 03:00 4222   /lib/libc.so.6
-a800a000-a800b000 rw-p 00135000 03:00 4222   /lib/libc.so.6
-a800b000-a800e000 rw-p  00:00 0
-a800e000-a8022000 r-xp  03:00 14462  /lib/libpthread.so.0
-a8022000-a8023000 r--p 00013000 03:00 14462  /lib/libpthread.so.0
-a8023000-a8024000 rw-p 00014000 03:00 14462  /lib/libpthread.so.0
-a8024000-a8027000 rw-p  00:00 0
-a8027000-a8043000 r-xp  03:00 8317   /lib/ld-linux.so.2
-a8043000-a8044000 r--p 0001b000 03:00 8317   /lib/ld-linux.so.2
-a8044000-a8045000 rw-p 0001c000 03:00 8317   /lib/ld-linux.so.2
-aff35000-aff4a000 rw-p  00:00 0
-e000-f000 r-xp  00:00 0  [vdso]
-
 The /proc/PID/smaps is an extension based on maps, showing the memory
 consumption for each of the process's mappings. For each of mappings there
 is a series of lines such as the following:
diff --git a/Makefile b/Makefile
index f3e3931103e3..2df4a1163714 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 102
+SUBLEVEL = 103
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index ac3ca3636405..0d35ab64641c 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -138,7 +138,7 @@
 &audio_codec {
status = "okay";
 
-   reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
in

Linux 4.4.127

[Greg KH]

I'm announcing the release of the 4.4.127 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt |9 +
 Documentation/filesystems/proc.txt   |   26 
 Makefile |2 
 arch/arm/boot/dts/am335x-pepper.dts  |2 
 arch/arm/boot/dts/am57xx-beagle-x15.dts  |1 
 arch/arm/boot/dts/dra7-evm.dts   |2 
 arch/arm/boot/dts/omap3-n900.dts |4 
 arch/arm64/include/asm/memory.h  |6 
 arch/frv/include/asm/timex.h |6 
 arch/x86/crypto/cast5_avx_glue.c |3 
 arch/x86/kernel/kprobes/core.c   |9 +
 block/partitions/msdos.c |4 
 crypto/ahash.c   |7 -
 drivers/acpi/pci_irq.c   |3 
 drivers/block/mtip32xx/mtip32xx.c|   36 +
 drivers/cpufreq/cpufreq.c|6 
 drivers/infiniband/core/addr.c   |   16 ++
 drivers/infiniband/core/ucma.c   |   67 +++
 drivers/input/mousedev.c |   62 +-
 drivers/input/serio/i8042-x86ia64io.h|   24 +++
 drivers/md/dm-ioctl.c|4 
 drivers/md/raid10.c  |1 
 drivers/media/usb/usbtv/usbtv-core.c |2 
 drivers/misc/mei/main.c  |1 
 drivers/mtd/chips/jedec_probe.c  |2 
 drivers/net/ethernet/cavium/liquidio/lio_main.c  |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c   |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c|2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c|2 
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c |4 
 drivers/parport/parport_pc.c |4 
 drivers/pci/pci-driver.c |2 
 drivers/pci/probe.c  |2 
 drivers/pci/setup-res.c  |2 
 drivers/scsi/virtio_scsi.c   |1 
 drivers/spi/spi-davinci.c|2 
 drivers/staging/comedi/drivers/ni_mio_common.c   |2 
 drivers/tty/vt/vt.c  |6 
 drivers/usb/dwc2/hcd.c   |7 -
 drivers/usb/gadget/function/f_hid.c  |   24 +++
 drivers/usb/gadget/function/f_midi.c |6 
 drivers/usb/gadget/function/f_sourcesink.c   |6 
 drivers/usb/gadget/function/g_zero.h |1 
 drivers/usb/gadget/u_f.c |6 
 drivers/usb/gadget/u_f.h |   26 +++-
 drivers/usb/serial/cp210x.c  |1 
 drivers/usb/serial/ftdi_sio.c|2 
 drivers/usb/serial/ftdi_sio_ids.h|9 +
 fs/compat_ioctl.c|2 
 fs/proc/task_mmu.c   |   29 +---
 fs/proc/task_nommu.c |   28 +---
 include/linux/audit.h|   24 +++
 include/linux/cpumask.h  |   10 +
 include/linux/jiffies.h  |   13 --
 include/linux/llist.h|   21 +++
 include/linux/netfilter/x_tables.h   |2 
 include/linux/nospec.h   |   14 --
 include/linux/tty.h  |4 
 include/linux/usb/gadget.h   |   17 ++
 include/rdma/ib_addr.h   |2 
 include/uapi/linux/pci_regs.h|2 
 kernel/audit.c   |   18 --
 kernel/auditsc.c |8 -
 kernel/events/hw_breakpoint.c|   30 +---
 kernel/irq/manage.c

Re: Linux 4.4.127

[Greg KH]

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297bee1fb..c28d4eb83b76 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:
diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index 6716413c17ba..6d2689ebf824 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -383,32 +383,6 @@ is not associated with a file:
 
  or if empty, the mapping is anonymous.
 
-The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
-of the individual tasks of a process. In this file you will see a mapping 
marked
-as [stack] if that task sees it as a stack. Hence, for the example above, the
-task-level map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like 
this:
-
-08048000-08049000 r-xp  03:00 8312   /opt/test
-08049000-0804a000 rw-p 1000 03:00 8312   /opt/test
-0804a000-0806b000 rw-p  00:00 0  [heap]
-a7cb1000-a7cb2000 ---p  00:00 0
-a7cb2000-a7eb2000 rw-p  00:00 0
-a7eb2000-a7eb3000 ---p  00:00 0
-a7eb3000-a7ed5000 rw-p  00:00 0  [stack]
-a7ed5000-a8008000 r-xp  03:00 4222   /lib/libc.so.6
-a8008000-a800a000 r--p 00133000 03:00 4222   /lib/libc.so.6
-a800a000-a800b000 rw-p 00135000 03:00 4222   /lib/libc.so.6
-a800b000-a800e000 rw-p  00:00 0
-a800e000-a8022000 r-xp  03:00 14462  /lib/libpthread.so.0
-a8022000-a8023000 r--p 00013000 03:00 14462  /lib/libpthread.so.0
-a8023000-a8024000 rw-p 00014000 03:00 14462  /lib/libpthread.so.0
-a8024000-a8027000 rw-p  00:00 0
-a8027000-a8043000 r-xp  03:00 8317   /lib/ld-linux.so.2
-a8043000-a8044000 r--p 0001b000 03:00 8317   /lib/ld-linux.so.2
-a8044000-a8045000 rw-p 0001c000 03:00 8317   /lib/ld-linux.so.2
-aff35000-aff4a000 rw-p  00:00 0
-e000-f000 r-xp  00:00 0  [vdso]
-
 The /proc/PID/smaps is an extension based on maps, showing the memory
 consumption for each of the process's mappings. For each of mappings there
 is a series of lines such as the following:
diff --git a/Makefile b/Makefile
index 2b699c5f6de4..58c0390573c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 126
+SUBLEVEL = 127
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 2dbe13a3d89b..7106114c7464 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
 &audio_codec {
status = "okay";
 
-   reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 00352e761b8c..5c3bd34af9fd 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -411,6 +411,7 @@
interrupt-controller;
 
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 864f60020124..0736d04f032e 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -410,6 +410,8 @@
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
+   ti,palmas-override-powerhold;
+   ti,system-power-controller;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/

Linux 4.9.93

[Greg KH]

I'm announcing the release of the 4.9.93 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt |9 
 Makefile |2 
 arch/arm/boot/dts/am335x-pepper.dts  |2 
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi  |1 
 arch/arm/boot/dts/am57xx-idk-common.dtsi |1 
 arch/arm/boot/dts/dra7-evm.dts   |2 
 arch/arm/boot/dts/omap3-n900.dts |4 
 arch/arm/vfp/vfpmodule.c |2 
 arch/arm64/Kconfig   |   12 
 arch/arm64/include/asm/assembler.h   |3 
 arch/arm64/include/asm/cpucaps.h |3 
 arch/arm64/include/asm/cputype.h |3 
 arch/arm64/include/asm/fixmap.h  |6 
 arch/arm64/include/asm/memory.h  |6 
 arch/arm64/include/asm/mmu.h |   11 
 arch/arm64/include/asm/mmu_context.h |7 
 arch/arm64/include/asm/pgtable-hwdef.h   |1 
 arch/arm64/include/asm/pgtable-prot.h|   35 +
 arch/arm64/include/asm/pgtable.h |1 
 arch/arm64/include/asm/proc-fns.h|6 
 arch/arm64/include/asm/sysreg.h  |1 
 arch/arm64/include/asm/tlbflush.h|   16 
 arch/arm64/kernel/asm-offsets.c  |6 
 arch/arm64/kernel/cpu-reset.S|2 
 arch/arm64/kernel/cpufeature.c   |  135 ++
 arch/arm64/kernel/entry.S|  188 -
 arch/arm64/kernel/head.S |2 
 arch/arm64/kernel/process.c  |   12 
 arch/arm64/kernel/sleep.S|2 
 arch/arm64/kernel/vmlinux.lds.S  |   22 +
 arch/arm64/mm/context.c  |   25 -
 arch/arm64/mm/mmu.c  |   31 +
 arch/arm64/mm/proc.S |  216 ++-
 arch/frv/include/asm/timex.h |6 
 arch/powerpc/kernel/exceptions-64s.S |2 
 arch/powerpc/kernel/irq.c|8 
 arch/x86/crypto/cast5_avx_glue.c |3 
 arch/x86/kernel/kprobes/core.c   |9 
 block/bio.c  |4 
 block/partitions/msdos.c |4 
 crypto/ahash.c   |7 
 drivers/block/mtip32xx/mtip32xx.c|   36 -
 drivers/hid/hid-sony.c   |   45 --
 drivers/infiniband/core/addr.c   |   16 
 drivers/infiniband/core/ucma.c   |   61 +--
 drivers/input/mouse/alps.c   |   24 +
 drivers/input/mousedev.c |   62 +--
 drivers/input/serio/i8042-x86ia64io.h|   24 +
 drivers/md/dm-ioctl.c|4 
 drivers/md/raid10.c  |1 
 drivers/media/usb/usbtv/usbtv-core.c |2 
 drivers/misc/mei/main.c  |1 
 drivers/mtd/chips/jedec_probe.c  |2 
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |   50 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c   |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c|2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c|2 
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c |4 
 drivers/net/phy/mdio-xgene.c |   50 +-
 drivers/net/phy/mdio-xgene.h |4 
 drivers/parport/parport_pc.c |4 
 drivers/pci/probe.c  |2 
 drivers/pci/setup-res.c  |2 
 drivers/scsi/virtio_scsi.c   |1 
 drivers/spi/Kconfig   

Re: Linux 4.9.93

[Greg KH]

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297bee1fb..c28d4eb83b76 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:
diff --git a/Makefile b/Makefile
index 3ab3b8203bf6..f5cf4159fc20 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 92
+SUBLEVEL = 93
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 42b62f54e4b7..30e2f8770aaf 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
 &audio_codec {
status = "okay";
 
-   reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 6df7829a2c15..78bee26361f1 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -204,6 +204,7 @@
interrupt-controller;
 
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index db858fff4e18..1cc62727e43a 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -57,6 +57,7 @@
#interrupt-cells = <2>;
interrupt-controller;
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 132f2be10889..56311fd34f81 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -398,6 +398,8 @@
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
+   ti,palmas-override-powerhold;
+   ti,system-power-controller;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6003b29c0fc0..4d448f145ed1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -510,7 +510,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
-   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
+   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -527,7 +527,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
-   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
+   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
 
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index da0b33deba6d..5629d7580973 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user_vfp __user *ufp,
  */
 static int vfp_dying_cpu(unsigned int cpu)
 {
-   vfp_force_reload(cpu, current_thread_info());
+   vfp_current_hw_state[cpu] = NULL;
return 0;
 }
 
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7769c2e27788..c8471cf46cbb 100644
-

Linux 4.14.33

[Greg KH]

I'm announcing the release of the 4.14.33 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/serial/8250.txt  |1 
 Makefile   |2 
 arch/arm/boot/dts/am335x-pepper.dts|2 
 arch/arm/boot/dts/dra76-evm.dts|1 
 arch/arm/boot/dts/omap3-n900.dts   |4 -
 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts   |   63 -
 arch/arm/crypto/Makefile   |2 
 arch/arm/plat-omap/include/plat/sram.h |   11 ---
 arch/arm/plat-omap/sram.c  |   36 +++-
 arch/arm/vfp/vfpmodule.c   |2 
 arch/arm64/crypto/Makefile |2 
 arch/powerpc/kernel/exceptions-64s.S   |2 
 arch/powerpc/kernel/irq.c  |8 ++
 arch/x86/crypto/cast5_avx_glue.c   |3 -
 arch/x86/include/asm/hw_irq.h  |1 
 arch/x86/kernel/idt.c  |3 +
 arch/x86/platform/uv/tlb_uv.c  |2 
 block/bio.c|4 -
 block/partitions/msdos.c   |4 +
 crypto/ahash.c |7 +-
 crypto/lrw.c   |2 
 crypto/testmgr.h   |6 +-
 drivers/base/arch_topology.c   |   12 ++--
 drivers/char/mem.c |6 +-
 drivers/cpufreq/cpufreq.c  |6 --
 drivers/crypto/caam/ctrl.c |3 -
 drivers/crypto/ccp/ccp-crypto-rsa.c|7 +-
 drivers/crypto/inside-secure/safexcel.c|2 
 drivers/i2c/busses/i2c-stm32f7.c   |5 +
 drivers/infiniband/core/addr.c |   25 
 drivers/infiniband/core/ucma.c |   61 +---
 drivers/input/mouse/alps.c |   24 +++-
 drivers/input/serio/i8042-x86ia64io.h  |   24 
 drivers/media/usb/usbtv/usbtv-core.c   |2 
 drivers/misc/mei/main.c|1 
 drivers/mtd/chips/jedec_probe.c|2 
 drivers/mtd/nand/atmel/pmecc.c |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c  |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  |2 
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   |4 +
 drivers/parport/parport_pc.c   |4 +
 drivers/phy/qualcomm/phy-qcom-ufs.c|5 +
 drivers/staging/comedi/drivers/ni_mio_common.c |2 
 drivers/tty/serial/8250/8250_of.c  |1 
 drivers/tty/serial/8250/8250_port.c|   33 +++
 drivers/tty/vt/vt.c|6 +-
 drivers/usb/dwc2/hcd.c |7 +-
 drivers/usb/serial/cp210x.c|1 
 drivers/usb/serial/ftdi_sio.c  |2 
 drivers/usb/serial/ftdi_sio_ids.h  |9 +++
 fs/btrfs/inode.c   |   37 ++--
 fs/ceph/file.c |9 ++-
 include/linux/bitmap.h |   22 +--
 include/linux/netfilter/x_tables.h |2 
 include/rdma/ib_addr.h |2 
 include/uapi/linux/serial_core.h   |3 +
 ipc/shm.c  |   12 
 kernel/events/hw_breakpoint.c  |   30 ++
 mm/percpu-km.c |8 +-
 mm/percpu-vm.c |   18 +++---
 mm/percpu.c|   45 +--
 net/bluetooth/smp.c|8 ++
 net/bridge/netfilter/ebt_among.c   |   34 +++
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |   14 
 net/ipv6/ip6_vti.c |   20 --
 net/l2tp/l2tp_core.c   |   38 ++--
 net/l2tp/l2tp_core.h   |3 -
 net/netfilter/x_tables.c   |   37 
 net/netfilter/xt_hashlimit.c   |   16 +++--
 net/netfilter/xt_recent.c  |6 +-
 net/xfrm/xfrm_ipcomp.c |2 
 net/xfrm/xfrm_state.

Linux 4.15.16

[Greg KH]

I'm announcing the release of the 4.15.16 kernel.

All users of the 4.15 kernel series must upgrade.

The updated 4.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.15.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/serial/8250.txt  |1 
 Makefile   |2 
 arch/arm/boot/dts/am335x-pepper.dts|2 
 arch/arm/boot/dts/dra76-evm.dts|1 
 arch/arm/boot/dts/omap3-n900.dts   |4 
 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts   |   63 +++
 arch/arm/crypto/Makefile   |2 
 arch/arm/plat-omap/include/plat/sram.h |   11 -
 arch/arm/plat-omap/sram.c  |   36 
 arch/arm/vfp/vfpmodule.c   |2 
 arch/arm64/crypto/Makefile |2 
 arch/powerpc/include/asm/book3s/64/mmu.h   |3 
 arch/powerpc/include/asm/mmu_context.h |   18 +-
 arch/powerpc/kernel/exceptions-64s.S   |2 
 arch/powerpc/kernel/irq.c  |8 +
 arch/powerpc/mm/mmu_context_book3s64.c |1 
 arch/powerpc/mm/tlb-radix.c|   50 +-
 arch/x86/crypto/cast5_avx_glue.c   |3 
 arch/x86/include/asm/hw_irq.h  |1 
 arch/x86/kernel/idt.c  |3 
 arch/x86/platform/uv/tlb_uv.c  |2 
 block/bio.c|4 
 block/partitions/msdos.c   |4 
 crypto/ahash.c |7 
 crypto/lrw.c   |2 
 crypto/testmgr.h   |6 
 drivers/base/arch_topology.c   |   12 -
 drivers/char/mem.c |6 
 drivers/cpufreq/cpufreq.c  |6 
 drivers/crypto/caam/ctrl.c |3 
 drivers/crypto/ccp/ccp-crypto-rsa.c|7 
 drivers/crypto/inside-secure/safexcel.c|2 
 drivers/crypto/talitos.c   |  168 -
 drivers/gpu/drm/i915/intel_ddi.c   |   12 -
 drivers/i2c/busses/i2c-stm32f7.c   |5 
 drivers/infiniband/core/addr.c |   25 +++
 drivers/infiniband/core/ucma.c |   61 ---
 drivers/input/mouse/alps.c |   24 ++-
 drivers/input/serio/i8042-x86ia64io.h  |   24 +++
 drivers/media/usb/usbtv/usbtv-core.c   |2 
 drivers/misc/mei/main.c|1 
 drivers/mtd/chips/jedec_probe.c|2 
 drivers/mtd/nand/atmel/pmecc.c |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c  |2 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c  |2 
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   |4 
 drivers/parport/parport_pc.c   |4 
 drivers/phy/qualcomm/phy-qcom-ufs.c|5 
 drivers/staging/comedi/drivers/ni_mio_common.c |2 
 drivers/tty/serial/8250/8250_of.c  |1 
 drivers/tty/serial/8250/8250_port.c|   33 
 drivers/tty/vt/vt.c|6 
 drivers/usb/serial/cp210x.c|1 
 drivers/usb/serial/ftdi_sio.c  |2 
 drivers/usb/serial/ftdi_sio_ids.h  |9 +
 fs/btrfs/inode.c   |   37 
 fs/ceph/file.c |9 -
 include/linux/bitmap.h |   22 ++
 include/linux/netfilter/x_tables.h |2 
 include/rdma/ib_addr.h |2 
 include/uapi/linux/serial_core.h   |3 
 ipc/shm.c  |   12 +
 kernel/events/hw_breakpoint.c  |   30 ---
 mm/percpu-km.c |8 -
 mm/percpu-vm.c |   18 +-
 mm/percpu.c|   45 +++--
 net/bluetooth/smp.c|8 -
 net/bridge/netfilter/ebt_among.c   |   34 
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |   14 +
 net/ipv6/ip6_vti.c |   20 --
 net/ipv6/route.c   |   13 -
 net/l2tp/l2tp_core.c   |   38 ++--
 net/l2tp/l2tp_core.h   |3 
 net/netfilter/x_tables.c  

Re: Linux 4.14.33

[Greg KH]

diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index dad3b2ec66d4..aeb6db4e35c3 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -24,6 +24,7 @@ Required properties:
- "ti,da830-uart"
- "aspeed,ast2400-vuart"
- "aspeed,ast2500-vuart"
+   - "nuvoton,npcm750-uart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/Makefile b/Makefile
index c4c681b53ff0..00dd6af8eab4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 32
+SUBLEVEL = 33
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 9fb7426070ce..03c7d77023c6 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
 &audio_codec {
status = "okay";
 
-   reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index b024a65c6e27..f64aab450315 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -148,6 +148,7 @@
compatible = "ti,tps65917";
reg = <0x58>;
ti,system-power-controller;
+   ti,palmas-override-powerhold;
interrupt-controller;
#interrupt-cells = <2>;
 
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c66ee8432a85..4acd32a1c4ef 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -558,7 +558,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
-   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
+   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -575,7 +575,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
-   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
+   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
 
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
diff --git a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts 
b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
index 51e6f1d21c32..b2758dd8ce43 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -42,7 +42,6 @@
 
 /dts-v1/;
 #include "sun6i-a31s.dtsi"
-#include "sunxi-common-regulators.dtsi"
 #include 
 
 / {
@@ -99,6 +98,7 @@
pinctrl-0 = <&gmac_pins_rgmii_a>, <&gmac_phy_reset_pin_bpi_m2>;
phy = <&phy1>;
phy-mode = "rgmii";
+   phy-supply = <®_dldo1>;
snps,reset-gpio = <&pio 0 21 GPIO_ACTIVE_HIGH>; /* PA21 */
snps,reset-active-low;
snps,reset-delays-us = <0 1 3>;
@@ -118,7 +118,7 @@
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bpi_m2>;
-   vmmc-supply = <®_vcc3v0>;
+   vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 0 4 GPIO_ACTIVE_HIGH>; /* PA4 */
cd-inverted;
@@ -132,7 +132,7 @@
 &mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_a>;
-   vmmc-supply = <®_vcc3v0>;
+   vmmc-supply = <®_aldo1>;
mmc-pwrseq = <&mmc2_pwrseq>;
bus-width = <4>;
non-removable;
@@ -163,6 +163,8 @@
reg = <0x68>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <®_dcdc1>;
+   x-powers,drive-vbus-en;
};
 };
 
@@ -193,7 +195,28 @@
 
 #include "axp22x.dtsi"
 
+®_aldo1 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi";
+};
+
+®_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <250>;
+   regulator-name = "vcc-gmac";
+};
+
+®_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 ®_dc5ldo {
+   regulator-always-on;
regulator-min-microvolt = <70>;
regulator-max-microvolt = <132>;
regulator-name = "vdd-cpus";
@@ -233,6 +256,40 @@
   

Re: Linux 4.15.16

[Greg KH]

diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index dad3b2ec66d4..aeb6db4e35c3 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -24,6 +24,7 @@ Required properties:
- "ti,da830-uart"
- "aspeed,ast2400-vuart"
- "aspeed,ast2500-vuart"
+   - "nuvoton,npcm750-uart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/Makefile b/Makefile
index 20c9b7bfeed4..b28f0f721ec7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 15
-SUBLEVEL = 15
+SUBLEVEL = 16
 EXTRAVERSION =
 NAME = Fearless Coyote
 
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 9fb7426070ce..03c7d77023c6 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
 &audio_codec {
status = "okay";
 
-   reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+   gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index b024a65c6e27..f64aab450315 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -148,6 +148,7 @@
compatible = "ti,tps65917";
reg = <0x58>;
ti,system-power-controller;
+   ti,palmas-override-powerhold;
interrupt-controller;
#interrupt-cells = <2>;
 
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 5362139d5312..669c51c00c00 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -558,7 +558,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
-   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
+   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -575,7 +575,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
-   reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
+   gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
 
AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;
diff --git a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts 
b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
index 51e6f1d21c32..b2758dd8ce43 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -42,7 +42,6 @@
 
 /dts-v1/;
 #include "sun6i-a31s.dtsi"
-#include "sunxi-common-regulators.dtsi"
 #include 
 
 / {
@@ -99,6 +98,7 @@
pinctrl-0 = <&gmac_pins_rgmii_a>, <&gmac_phy_reset_pin_bpi_m2>;
phy = <&phy1>;
phy-mode = "rgmii";
+   phy-supply = <®_dldo1>;
snps,reset-gpio = <&pio 0 21 GPIO_ACTIVE_HIGH>; /* PA21 */
snps,reset-active-low;
snps,reset-delays-us = <0 1 3>;
@@ -118,7 +118,7 @@
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bpi_m2>;
-   vmmc-supply = <®_vcc3v0>;
+   vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 0 4 GPIO_ACTIVE_HIGH>; /* PA4 */
cd-inverted;
@@ -132,7 +132,7 @@
 &mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_a>;
-   vmmc-supply = <®_vcc3v0>;
+   vmmc-supply = <®_aldo1>;
mmc-pwrseq = <&mmc2_pwrseq>;
bus-width = <4>;
non-removable;
@@ -163,6 +163,8 @@
reg = <0x68>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <®_dcdc1>;
+   x-powers,drive-vbus-en;
};
 };
 
@@ -193,7 +195,28 @@
 
 #include "axp22x.dtsi"
 
+®_aldo1 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi";
+};
+
+®_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <250>;
+   regulator-name = "vcc-gmac";
+};
+
+®_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 ®_dc5ldo {
+   regulator-always-on;
regulator-min-microvolt = <70>;
regulator-max-microvolt = <132>;
regulator-name = "vdd-cpus";
@@ -233,6 +256,40 @@
 

Linux 4.16.1

[Greg KH]

I'm announcing the release of the 4.16.1 kernel.

All users of the 4.16 kernel series must upgrade.

The updated 4.16.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.16.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/serial/8250.txt |1 
 Makefile  |2 
 arch/arm/crypto/Makefile  |2 
 arch/arm64/crypto/Makefile|2 
 arch/x86/crypto/cast5_avx_glue.c  |3 
 block/bio.c   |4 
 crypto/ahash.c|7 
 crypto/lrw.c  |2 
 crypto/testmgr.h  |6 
 drivers/base/arch_topology.c  |   12 -
 drivers/bluetooth/hci_bcm.c   |6 
 drivers/char/mem.c|6 
 drivers/crypto/caam/ctrl.c|3 
 drivers/crypto/ccp/ccp-crypto-aes-cmac.c  |2 
 drivers/crypto/ccp/ccp-crypto-rsa.c   |7 
 drivers/crypto/ccp/ccp-crypto-sha.c   |2 
 drivers/crypto/inside-secure/safexcel.c   |2 
 drivers/crypto/talitos.c  |  168 --
 drivers/input/mouse/alps.c|   24 ++-
 drivers/input/serio/i8042-x86ia64io.h |   24 +++
 drivers/media/usb/usbtv/usbtv-core.c  |2 
 drivers/misc/mei/main.c   |1 
 drivers/parport/parport_pc.c  |4 
 drivers/siox/siox-core.c  |2 
 drivers/staging/comedi/drivers/ni_mio_common.c|2 
 drivers/tty/serial/8250/8250_of.c |1 
 drivers/tty/serial/8250/8250_port.c   |   33 
 drivers/tty/vt/vt.c   |6 
 drivers/usb/serial/cp210x.c   |1 
 drivers/usb/serial/ftdi_sio.c |2 
 drivers/usb/serial/ftdi_sio_ids.h |9 +
 fs/btrfs/inode.c  |   37 
 include/linux/bitmap.h|   22 ++
 include/linux/compat.h|6 
 include/uapi/asm-generic/siginfo.h|7 
 include/uapi/linux/serial_core.h  |3 
 36 files changed, 268 insertions(+), 155 deletions(-)

Alexander Gerasiov (1):
  parport_pc: Add support for WCH CH382L PCI-E single parallel port card.

Clemens Werther (1):
  USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator

Colin Ian King (1):
  mei: remove dev_err message on an unsupported ioctl

Conor McLoughlin (1):
  crypto: testmgr - Fix incorrect values in PKCS#1 test vector

Dennis Wassenberg (1):
  Input: i8042 - add Lenovo ThinkPad L460 to i8042 reset list

Eric Biggers (1):
  crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one

Eric W. Biederman (1):
  signal: Correct the offset of si_pkey and si_lower in struct siginfo on 
m68k

Frank Mori Hess (1):
  staging: comedi: ni_mio_common: ack ai fifo error interrupts.

Gaku Inami (1):
  Revert "base: arch_topology: fix section mismatch build warnings"

Gary R Hook (1):
  crypto: ccp - Fill the result buffer only on digest, finup, and final ops

Gavin Schenk (1):
  siox: fix possible buffer overflow in device_add_store

Greg Kroah-Hartman (1):
  Linux 4.16.1

Gregory CLEMENT (1):
  crypto: inside-secure - fix clock management

Hans de Goede (1):
  Bluetooth: hci_bcm: Add 6 new ACPI HIDs

Herbert Xu (2):
  crypto: lrw - Free rctx->ext with kzfree
  crypto: ahash - Fix early termination in hash walk

Joel Stanley (1):
  serial: 8250: Add Nuvoton NPCM UART

Johan Hovold (1):
  USB: serial: cp210x: add ELDAT Easywave RX09 id

Kees Cook (1):
  /dev/mem: Avoid overwriting "err" in read_mem()

LEROY Christophe (2):
  crypto: talitos - don't persistently map req_ctx->hw_context and 
req_ctx->buf
  crypto: talitos - fix IPsec cipher in length

Leonard Crestez (1):
  crypto: arm,arm64 - Fix random regeneration of S_shipped

Liu Bo (1):
  Btrfs: fix unexpected cow in run_delalloc_nocow

Maciej S. Szmigiero (1):
  crypto: ccp - return an actual key size from RSA max_size callback

Major Hayden (1):
  USB: serial: ftdi_sio: add RT Systems VX-8 cable

Masaki Ota (1):
  Input: ALPS - fix TrackStick detection on Thinkpad L570 and Latitude 7370

Mike Frysinger (1):
  vt: change SGR 21 to follow the standards

Mikulas Patocka (1):
  Fix slab name "biovec-(1<<(21-12))"

Oliver Neukum (1):
  media: usbtv: prevent double free in error case

Omar Sandoval (1):
  bitmap: fix memset o

Re: Linux 4.16.1

[Greg KH]

diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index dad3b2ec66d4..aeb6db4e35c3 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -24,6 +24,7 @@ Required properties:
- "ti,da830-uart"
- "aspeed,ast2400-vuart"
- "aspeed,ast2500-vuart"
+   - "nuvoton,npcm750-uart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/Makefile b/Makefile
index 363dd096e46e..1773c718074e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 16
-SUBLEVEL = 0
+SUBLEVEL = 1
 EXTRAVERSION =
 NAME = Fearless Coyote
 
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 30ef8e291271..c9919c2b7ad1 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -54,6 +54,7 @@ crct10dif-arm-ce-y:= crct10dif-ce-core.o 
crct10dif-ce-glue.o
 crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
 chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
 
+ifdef REGENERATE_ARM_CRYPTO
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
 
@@ -62,5 +63,6 @@ $(src)/sha256-core.S_shipped: $(src)/sha256-armv4.pl
 
 $(src)/sha512-core.S_shipped: $(src)/sha512-armv4.pl
$(call cmd,perl)
+endif
 
 .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index cee9b8d9830b..dfe651bdf993 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -67,6 +67,7 @@ CFLAGS_aes-glue-ce.o  := -DUSE_V8_CRYPTO_EXTENSIONS
 $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
$(call if_changed_rule,cc_o_c)
 
+ifdef REGENERATE_ARM64_CRYPTO
 quiet_cmd_perlasm = PERLASM $@
   cmd_perlasm = $(PERL) $(<) void $(@)
 
@@ -75,5 +76,6 @@ $(src)/sha256-core.S_shipped: $(src)/sha512-armv8.pl
 
 $(src)/sha512-core.S_shipped: $(src)/sha512-armv8.pl
$(call cmd,perlasm)
+endif
 
 .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S
diff --git a/arch/x86/crypto/cast5_avx_glue.c b/arch/x86/crypto/cast5_avx_glue.c
index dbea6020ffe7..575292a33bdf 100644
--- a/arch/x86/crypto/cast5_avx_glue.c
+++ b/arch/x86/crypto/cast5_avx_glue.c
@@ -66,8 +66,6 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct 
blkcipher_walk *walk,
void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src);
int err;
 
-   fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
-
err = blkcipher_walk_virt(desc, walk);
desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
 
@@ -79,6 +77,7 @@ static int ecb_crypt(struct blkcipher_desc *desc, struct 
blkcipher_walk *walk,
 
/* Process multi-block batch */
if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) {
+   fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way;
do {
fn(ctx, wdst, wsrc);
 
diff --git a/block/bio.c b/block/bio.c
index e1708db48258..53e0f0a1ed94 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -43,9 +43,9 @@
  * break badly! cannot be bigger than what you can fit into an
  * unsigned short
  */
-#define BV(x) { .nr_vecs = x, .name = "biovec-"__stringify(x) }
+#define BV(x, n) { .nr_vecs = x, .name = "biovec-"#n }
 static struct biovec_slab bvec_slabs[BVEC_POOL_NR] __read_mostly = {
-   BV(1), BV(4), BV(16), BV(64), BV(128), BV(BIO_MAX_PAGES),
+   BV(1, 1), BV(4, 4), BV(16, 16), BV(64, 64), BV(128, 128), 
BV(BIO_MAX_PAGES, max),
 };
 #undef BV
 
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 266fc1d64f61..c03cc177870b 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -92,13 +92,14 @@ int crypto_hash_walk_done(struct crypto_hash_walk *walk, 
int err)
 
if (nbytes && walk->offset & alignmask && !err) {
walk->offset = ALIGN(walk->offset, alignmask + 1);
-   walk->data += walk->offset;
-
nbytes = min(nbytes,
 ((unsigned int)(PAGE_SIZE)) - walk->offset);
walk->entrylen -= nbytes;
 
-   return nbytes;
+   if (nbytes) {
+   walk->data += walk->offset;
+   return nbytes;
+   }
}
 
if (walk->flags & CRYPTO_ALG_ASYNC)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index cbbd7c50ad19..1d813a6d3fec 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -313,7 +313,7 @@ static void exit_crypt(struct skcipher_request *req)
rctx->left = 0;
 
if (rctx->ext)
-   kfree(rctx->ext);
+   kzfree(rctx->ext);
 }
 
 static int do_encrypt(struct skcipher_request *req, int err)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 6044f6906bd6..69fb51e7b6f1 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -548,7 +548,7 @@ static c

Re: [PATCH 3.18 00/93] 3.18.103-stable review

[Greg Kroah-Hartman]

On Sun, Apr 08, 2018 at 07:07:26AM -0700, Guenter Roeck wrote:
> On Fri, Apr 06, 2018 at 03:22:29PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.103 release.
> > There are 93 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr  8 08:42:04 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Not full results this time, sorry (my build system is corrupted),

Ah, I was wondering what happened to your web results, sorry about this :(

> but there are various build failures in 3.18.y.
> 
> drivers/net/ethernet/freescale/fec_main.c: In function 'fec_drv_remove':
> drivers/net/ethernet/freescale/fec_main.c:3342:2: error: implicit declaration 
> of function 'pm_runtime_put'

Gotta love how 0-day doesn't catch these :(

I thought I fixed this up for the 4.4.y tree already, let me dig...

greg k-h

[no subject]

[E. Yuri]

You do not know me, neither i'm not desperate nor in need of help, But I'm
sure you are the kind of person I can trust with an investment on gold bars.
Only someone bearing your surname will be able to partner with me on this
and I hope and pray you don't let me down.

Br


__

Sky Silk, http://aknet.kz

Re: [PATCH] staging: pi433: add descriptions for mutex locks

[Marcus Wolf]

Hi Valentin,

like promissed, I finally had a deeper look to your proposal with
kfifo_avail and your patch from 24th of March.
In principle, I think it is a very nice idea, and we should try
to implement it.
But there is a snag: There is no guarantee, that kfifo_in will
only fail, if the fifo is full. If there will be any another
reason for kfifo_in to fail, with the new implementation there
will be no handling for that.
But I think the chance of such an situation is low to impossible
and the win in simplicity of the code is really great.

Regarding your patch, I did not understand, why you did not remove
the mutex_lock in pi433_write. Wasn't it the goal to remove it?

Below find a proposal of pi433_write function, I wrote on base
of my outdated (!), private repo. It is not compiled and not tested.
Since there is no more handling in case of an error (as well in the
propsal as in your patch), I removed the error handling completely.
I only do a test to detect proplems while writing to the tx_fifo,
but (like in your patch) do nothing for solving, just printing a line.
If this unexpected situation will occur (most probably never),
the tx_fifo will be (and stay) out of sync until driver gets unloaded.
We have to decide, whether we can stay with that. Like written above,
I thinkt the benefits are great, the chance of such kind of error
very low.
What do you think?

It could be discussed, whether it is better to return EMSGSIZE or
EAGAIN on the first check. On the one hand, there is a problem with
the message size, on the other hand (if message isn't generally too
big) after a while, there should be some more space available in
fifo, so EAGAIN may be better choice.


static ssize_t
pi433_write(struct file *filp, const char __user *buf,
size_t count, loff_t *f_pos)
{
struct pi433_instance   *instance;
struct pi433_device *device;
intrequired, copied, retval;

instance = filp->private_data;
device = instance->device;

/* check whether there is enough space available in tx_fifo */
required = sizeof(instance->tx_cfg) + sizeof(size_t) + count;
if ( num_of_bytes_to_store_in_fifo > kfifo_avail(&device->tx_fifo) ) {
dev_dbg(device->dev, "Not enough space in fifo. Need %d, but 
only have"
   , required
   , 
kfifo_avail(&device->tx_fifo) );
return -EMSGSIZE;
}

/* write the following sequence into fifo:
 * - tx_cfg
 * - size of message
 * - message
 */
retval  = kfifo_in(&device->tx_fifo, &instance->tx_cfg, 
sizeof(instance->tx_cfg));
retval += kfifo_in (&device->tx_fifo, &count, sizeof(size_t));
retval += kfifo_from_user(&device->tx_fifo, buf, count, &copied);

if (retval != required ) {
dev_dbg(device->dev, "write to fifo failed, reason unknown, non 
recoverable.");
return -EAGAIN;
}

/* start transfer */
wake_up_interruptible(&device->tx_wait_queue);
dev_dbg(device->dev, "write: generated new msg with %d bytes.", copied);

return 0;
}

Hope this helps :-)

Marcus


Am 25.03.2018 um 15:09 schrieb Valentin Vidic:
> On Sun, Mar 25, 2018 at 03:00:09PM +0200, Marcus Wolf wrote:
>> Unfortunaly I can't find the time to have a closer look on the code this
>> weekend - still busy with tax stuff :-(
>>
>> Idea sounds great. I'll try to look at the code and think about it
>> during Easter hollidays.
> 
> No problem, there is no hurry. But please do test the patch I sent yesterday:
> 
>   [PATCH] staging: pi433: cleanup tx_fifo locking
> 
> As I don't have the hardware this is just compile tested now :)
>