Re: WARNING in mark_lock
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: KASAN: use-after-free Read in class_equal == BUG: KASAN: use-after-free in class_equal+0x40/0x50 kernel/locking/lockdep.c:1527 Read of size 8 at addr 88808a268ba0 by task syz-executor.1/9270 CPU: 0 PID: 9270 Comm: syz-executor.1 Not tainted 5.2.0-rc3+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: Allocated by task 2647419968: BUG: unable to handle page fault for address: 8c00b020 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 8a70067 P4D 8a70067 PUD 8a71063 PMD 0 Thread overran stack, or stack corrupted Oops: [#1] PREEMPT SMP KASAN CPU: 0 PID: 9270 Comm: syz-executor.1 Not tainted 5.2.0-rc3+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:stack_depot_fetch+0x10/0x30 lib/stackdepot.c:203 Code: e9 7b fd ff ff 4c 89 ff e8 8d b4 62 fe e9 e6 fd ff ff 90 90 90 90 90 90 90 90 89 f8 c1 ef 11 25 ff ff 1f 00 81 e7 f0 3f 00 00 <48> 03 3c c5 20 6c 04 8b 48 8d 47 18 48 89 06 8b 47 0c c3 0f 1f 00 RSP: 0018:88808a2688e8 EFLAGS: 00010006 RAX: 001f8880 RBX: 88808a269304 RCX: RDX: RSI: 88808a2688f0 RDI: 3ff0 RBP: 88808a268908 R08: 0020 R09: ed1015d044fa R10: ed1015d044f9 R11: 8880ae8227cf R12: ea0002289a00 R13: 88808a268ba0 R14: 8880aa58ec40 R15: 88808a269300 FS: 570ba940() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 8c00b020 CR3: 8dd0 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: Modules linked in: CR2: 8c00b020 ---[ end trace 4acfe4b59fbc9cdb ]--- RIP: 0010:stack_depot_fetch+0x10/0x30 lib/stackdepot.c:203 Code: e9 7b fd ff ff 4c 89 ff e8 8d b4 62 fe e9 e6 fd ff ff 90 90 90 90 90 90 90 90 89 f8 c1 ef 11 25 ff ff 1f 00 81 e7 f0 3f 00 00 <48> 03 3c c5 20 6c 04 8b 48 8d 47 18 48 89 06 8b 47 0c c3 0f 1f 00 RSP: 0018:88808a2688e8 EFLAGS: 00010006 RAX: 001f8880 RBX: 88808a269304 RCX: RDX: RSI: 88808a2688f0 RDI: 3ff0 RBP: 88808a268908 R08: 0020 R09: ed1015d044fa R10: ed1015d044f9 R11: 8880ae8227cf R12: ea0002289a00 R13: 88808a268ba0 R14: 8880aa58ec40 R15: 88808a269300 FS: 570ba940() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 8c00b020 CR3: 8dd0 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Tested on: commit: 0b58d013 bpf: tls, implement unhash to avoid transition ou.. git tree: git://github.com/cilium/linux ktls-unhash console output: https://syzkaller.appspot.com/x/log.txt?x=153368a3a0 kernel config: https://syzkaller.appspot.com/x/.config?x=2cc918d28ebd06b4 compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Re: [Xen-devel] [PATCH] ALSA: xen-front: fix unintention integer overflow on left shifts
On 6/28/19 11:46 AM, Takashi Iwai wrote:
On Thu, 27 Jun 2019 18:58:53 +0200,
Colin King wrote:
From: Colin Ian King
Shifting the integer value 1 is evaluated using 32-bit
arithmetic and then used in an expression that expects a 64-bit
value, so there is potentially an integer overflow. Fix this
by using the BIT_ULL macro to perform the shift.
Addresses-Coverity: ("Unintentional integer overflow")
Signed-off-by: Colin Ian King
Thank you for you patch,
Oleksandr
The fix is correct, but luckily we didn't hit the integer overflow, as
all passed values are less than 32bit.
In anyway, applied now. Thanks.
Takashi
---
sound/xen/xen_snd_front_alsa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/xen/xen_snd_front_alsa.c b/sound/xen/xen_snd_front_alsa.c
index b14ab512c2ce..e01631959ed8 100644
--- a/sound/xen/xen_snd_front_alsa.c
+++ b/sound/xen/xen_snd_front_alsa.c
@@ -196,7 +196,7 @@ static u64 to_sndif_formats_mask(u64 alsa_formats)
mask = 0;
for (i = 0; i < ARRAY_SIZE(ALSA_SNDIF_FORMATS); i++)
if (pcm_format_to_bits(ALSA_SNDIF_FORMATS[i].alsa) &
alsa_formats)
- mask |= 1 << ALSA_SNDIF_FORMATS[i].sndif;
+ mask |= BIT_ULL(ALSA_SNDIF_FORMATS[i].sndif);
return mask;
}
@@ -208,7 +208,7 @@ static u64 to_alsa_formats_mask(u64 sndif_formats)
mask = 0;
for (i = 0; i < ARRAY_SIZE(ALSA_SNDIF_FORMATS); i++)
- if (1 << ALSA_SNDIF_FORMATS[i].sndif & sndif_formats)
+ if (BIT_ULL(ALSA_SNDIF_FORMATS[i].sndif) & sndif_formats)
mask |= pcm_format_to_bits(ALSA_SNDIF_FORMATS[i].alsa);
return mask;
--
2.20.1
___
Xen-devel mailing list
xen-de...@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: memory leak in create_ctx
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: memory leak in create_ctx 2019/07/01 05:38:26 executed programs: 23 BUG: memory leak unreferenced object 0x888102914e00 (size 512): comm "syz-executor.4", pid 7333, jiffies 4294944085 (age 13.950s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<2f2bb8be>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<2f2bb8be>] slab_post_alloc_hook mm/slab.h:439 [inline] [<2f2bb8be>] slab_alloc mm/slab.c:3326 [inline] [<2f2bb8be>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [] kmalloc include/linux/slab.h:547 [inline] [ ] kzalloc include/linux/slab.h:742 [inline] [ ] create_ctx+0x25/0x70 net/tls/tls_main.c:648 [ ] tls_init net/tls/tls_main.c:837 [inline] [ ] tls_init+0x97/0x1f0 net/tls/tls_main.c:819 [<9d663c39>] __tcp_set_ulp net/ipv4/tcp_ulp.c:126 [inline] [<9d663c39>] tcp_set_ulp+0xe2/0x190 net/ipv4/tcp_ulp.c:147 [<551f7621>] do_tcp_setsockopt.isra.0+0x19a/0xd60 net/ipv4/tcp.c:2789 [ ] tcp_setsockopt+0x71/0x80 net/ipv4/tcp.c:3103 [<85d221c1>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3129 [ ] __sys_setsockopt+0x98/0x120 net/socket.c:2072 [ ] __do_sys_setsockopt net/socket.c:2083 [inline] [ ] __se_sys_setsockopt net/socket.c:2080 [inline] [ ] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080 [ ] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<7383b736>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888103860c00 (size 512): comm "syz-executor.0", pid 7342, jiffies 4294944115 (age 13.650s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<2f2bb8be>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<2f2bb8be>] slab_post_alloc_hook mm/slab.h:439 [inline] [<2f2bb8be>] slab_alloc mm/slab.c:3326 [inline] [<2f2bb8be>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [ ] kmalloc include/linux/slab.h:547 [inline] [ ] kzalloc include/linux/slab.h:742 [inline] [ ] create_ctx+0x25/0x70 net/tls/tls_main.c:648 [ ] tls_init net/tls/tls_main.c:837 [inline] [ ] tls_init+0x97/0x1f0 net/tls/tls_main.c:819 [<9d663c39>] __tcp_set_ulp net/ipv4/tcp_ulp.c:126 [inline] [<9d663c39>] tcp_set_ulp+0xe2/0x190 net/ipv4/tcp_ulp.c:147 [<551f7621>] do_tcp_setsockopt.isra.0+0x19a/0xd60 net/ipv4/tcp.c:2789 [ ] tcp_setsockopt+0x71/0x80 net/ipv4/tcp.c:3103 [<85d221c1>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3129 [ ] __sys_setsockopt+0x98/0x120 net/socket.c:2072 [ ] __do_sys_setsockopt net/socket.c:2083 [inline] [ ] __se_sys_setsockopt net/socket.c:2080 [inline] [ ] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080 [ ] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<7383b736>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x88810e3e1c00 (size 512): comm "syz-executor.5", pid 7384, jiffies 4294944151 (age 13.290s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<2f2bb8be>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<2f2bb8be>] slab_post_alloc_hook mm/slab.h:439 [inline] [<2f2bb8be>] slab_alloc mm/slab.c:3326 [inline] [<2f2bb8be>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [ ] kmalloc include/linux/slab.h:547 [inline] [ ] kzalloc include/linux/slab.h:742 [inline] [ ] create_ctx+0x25/0x70 net/tls/tls_main.c:648 [ ] tls_init net/tls/tls_main.c:837 [inline] [ ] tls_init+0x97/0x1f0 net/tls/tls_main.c:819 [<9d663c39>] __tcp_set_ulp net/ipv4/tcp_ulp.c:126 [inline] [<9d663c39>] tcp_set_ulp+0xe2/0x190 net/ipv4/tcp_ulp.c:147 [<551f7621>] do_tcp_setsockopt.isra.0+0x19a/0xd60 net/ipv4/tcp.c:2789 [ ] tcp_setsockopt+0x71/0x80 net/ipv4/tcp.c:3103 [<85d221c1>] sock_common_setsockopt+0x38/0x50
Re: [PATCH REBASE v2 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig
On 6/30/19 9:58 PM, Hanjun Guo wrote: On 2019/5/26 20:50, Alexandre Ghiti wrote: ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: move this declaration in arch/Kconfig and make those architectures select it. Signed-off-by: Alexandre Ghiti Reviewed-by: Palmer Dabbelt --- arch/Kconfig | 3 +++ arch/arm64/Kconfig | 2 +- arch/x86/Kconfig | 4 +--- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index c47b328eada0..d2f212dc8e72 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -577,6 +577,9 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD config HAVE_ARCH_HUGE_VMAP bool +config ARCH_WANT_HUGE_PMD_SHARE + bool + config HAVE_ARCH_SOFT_DIRTY bool diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4780eb7af842..dee7f750c42f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -70,6 +70,7 @@ config ARM64 select ARCH_SUPPORTS_NUMA_BALANCING select ARCH_WANT_COMPAT_IPC_PARSE_VERSION select ARCH_WANT_FRAME_POINTERS + select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36) select ARCH_HAS_UBSAN_SANITIZE_ALL select ARM_AMBA select ARM_ARCH_TIMER @@ -884,7 +885,6 @@ config SYS_SUPPORTS_HUGETLBFS def_bool y config ARCH_WANT_HUGE_PMD_SHARE - def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36) Why not remove config ARCH_WANT_HUGE_PMD_SHARE as well? Did I miss something? You're totally right ! Thanks for noticing, Alex Thanks Hanjun
[PATCH v2] arm64: zynqmp: Add ZynqMP SDHCI compatible string
Add the new compatible string for ZynqMP SD Host Controller for its use
in the Arasan SDHCI driver for some of the ZynqMP specific operations.
Add required properties for the same.
Signed-off-by: Manish Narani
---
This patch depends on the below series of patches:
https://lkml.org/lkml/2019/7/1/25
Changes in v2:
- Added clock-names for SD card clocks for getting clocks in the driver
---
arch/arm64/boot/dts/xilinx/zynqmp-clk.dtsi | 4 ++--
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 14 ++
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp-clk.dtsi
index 306ad21..24c04a1 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-clk.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk.dtsi
@@ -177,11 +177,11 @@
};
{
- clocks = < >;
+ clocks = <>, <>, < 0>, < 1>;
};
{
- clocks = < >;
+ clocks = <>, <>, < 0>, < 1>;
};
{
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 9aa6734..4c21346 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -493,21 +493,27 @@
};
sdhci0: mmc@ff16 {
- compatible = "arasan,sdhci-8.9a";
+ compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
interrupt-parent = <>;
interrupts = <0 48 4>;
reg = <0x0 0xff16 0x0 0x1000>;
- clock-names = "clk_xin", "clk_ahb";
+ clock-names = "clk_xin", "clk_ahb",
+ "clk_sdcard", "clk_sample";
+ #clock-cells = <1>;
+ clock-output-names = "clk_out_sd0", "clk_in_sd0";
};
sdhci1: mmc@ff17 {
- compatible = "arasan,sdhci-8.9a";
+ compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
interrupt-parent = <>;
interrupts = <0 49 4>;
reg = <0x0 0xff17 0x0 0x1000>;
- clock-names = "clk_xin", "clk_ahb";
+ clock-names = "clk_xin", "clk_ahb",
+ "clk_sdcard", "clk_sample";
+ #clock-cells = <1>;
+ clock-output-names = "clk_out_sd1", "clk_in_sd1";
};
smmu: smmu@fd80 {
--
2.1.1
RE: [net/bpf] Re: WARNING in mark_lock
Eric Biggers wrote:
> [+bpf list]
>
> On Tue, Jun 25, 2019 at 08:20:56AM +0200, Thomas Gleixner wrote:
> > On Mon, 24 Jun 2019, syzbot wrote:
> >
> > > Hello,
> >
> > CC++ Peterz
> >
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:dc636f5d Add linux-next specific files for 20190620
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=162b68b1a0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=99c104b0092a557b
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=a861f52659ae2596492b
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110b24f6a0
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+a861f52659ae25964...@syzkaller.appspotmail.com
>
> The syz repro looks bpf related, and essentially the same repro is in lots of
> other open syzbot reports which I've assigned to the bpf subsystem...
> https://lore.kernel.org/lkml/20190624050114.GA30702@sol.localdomain/
>
> {"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"tun":true,"netdev":true,"resetnet":true,"cgroups":true,"binfmt_misc":true,"close_fds":true,"tmpdir":true,"segv":true}
> bpf$MAP_CREATE(0x0, &(0x7f000280)={0xf, 0x4, 0x4, 0x400, 0x0, 0x1}, 0x3c)
> socket$rxrpc(0x21, 0x2, 0x8a)
> r0 = socket$inet6_tcp(0xa, 0x1, 0x0)
> setsockopt$inet6_tcp_int(r0, 0x6, 0x13, &(0x7fc0)=0x10001, 0x1d4)
> connect$inet6(r0, &(0x7f000140), 0x1c)
> bpf$MAP_CREATE(0x0, &(0x7f00)={0x5}, 0xfdcb)
> bpf$MAP_CREATE(0x2, &(0x7f003000)={0x3, 0x0, 0x77fffb, 0x0,
> 0x1002000, 0x0}, 0x2c)
> setsockopt$inet6_tcp_TCP_ULP(r0, 0x6, 0x1f, &(0x7f40)='tls\x00', 0x4)
#syz test: git://github.com/cilium/linux ktls-unhash
Re: [PATCH v2 1/2] rpmsg: core: add possibility to get message payload length
On Fri 10 May 08:02 PDT 2019, Arnaud Pouliquen wrote:
> Return the rpmsg buffer payload size for sending message, so rpmsg users
> can split a long message in several sub rpmsg buffers.
>
> Signed-off-by: Arnaud Pouliquen
> Signed-off-by: Fabien Dessenne
This should list each person who dealt with the patch. So the first
would be the author and the last would be the one that posted it on the
list.
If you both authored the patch then you should add Co-developed-by to
denote this.
> ---
> drivers/rpmsg/rpmsg_core.c | 20
> drivers/rpmsg/rpmsg_internal.h | 2 ++
> drivers/rpmsg/virtio_rpmsg_bus.c | 11 +++
> include/linux/rpmsg.h| 10 ++
> 4 files changed, 43 insertions(+)
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index 8122807db380..75c8c403ffe5 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -283,6 +283,26 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept,
> u32 src, u32 dst,
> }
> EXPORT_SYMBOL(rpmsg_trysend_offchannel);
>
> +/**
> + * rpmsg_get_buf_payload_size()
> + * This function returns buffer payload size available for sending messages.
> + *
> + * @ept: the rpmsg endpoint
> + *
> + * Returns buffer payload size on success and an appropriate error value on
> + * failure.
> + */
Please read
https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt
> +int rpmsg_get_buf_payload_size(struct rpmsg_endpoint *ept)
payload size can have many meanings and hopefully we'll end up in a
situation where its dynamic. But it could be considered useful to have a
way to query the maximum transmission size in such a setup.
So please rename this rpmsg_get_mtu() or something similar.
And I would prefer ssize_t as return type.
> +{
> + if (WARN_ON(!ept))
> + return -EINVAL;
> + if (!ept->ops->get_buf_payload_size)
> + return -ENXIO;
> +
> + return ept->ops->get_buf_payload_size(ept);
> +}
> +EXPORT_SYMBOL(rpmsg_get_buf_payload_size);
> +
> /*
> * match an rpmsg channel with a channel info struct.
> * this is used to make sure we're not creating rpmsg devices for channels
> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> index 0d791c30b7ea..6f733a556139 100644
> --- a/drivers/rpmsg/rpmsg_internal.h
> +++ b/drivers/rpmsg/rpmsg_internal.h
> @@ -46,6 +46,7 @@ struct rpmsg_device_ops {
> * @trysend: see @rpmsg_trysend(), required
> * @trysendto: see @rpmsg_trysendto(), optional
> * @trysend_offchannel: see @rpmsg_trysend_offchannel(), optional
> + * @get_buf_payload_size: see @rpmsg_get_buf_payload_size(), optional
> *
> * Indirection table for the operations that a rpmsg backend should
> implement.
> * In addition to @destroy_ept, the backend must at least implement @send and
> @@ -65,6 +66,7 @@ struct rpmsg_endpoint_ops {
>void *data, int len);
> __poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
>poll_table *wait);
> + int (*get_buf_payload_size)(struct rpmsg_endpoint *ept);
> };
>
> int rpmsg_register_device(struct rpmsg_device *rpdev);
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 5d3685bd76a2..82753e76e377 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -175,6 +175,7 @@ static int virtio_rpmsg_trysendto(struct rpmsg_endpoint
> *ept, void *data,
> int len, u32 dst);
> static int virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32
> src,
> u32 dst, void *data, int len);
> +static int virtio_get_buf_payload_size(struct rpmsg_endpoint *ept);
>
> static const struct rpmsg_endpoint_ops virtio_endpoint_ops = {
> .destroy_ept = virtio_rpmsg_destroy_ept,
> @@ -184,6 +185,7 @@ static const struct rpmsg_endpoint_ops
> virtio_endpoint_ops = {
> .trysend = virtio_rpmsg_trysend,
> .trysendto = virtio_rpmsg_trysendto,
> .trysend_offchannel = virtio_rpmsg_trysend_offchannel,
> + .get_buf_payload_size = virtio_get_buf_payload_size,
> };
>
> /**
> @@ -699,6 +701,15 @@ static int virtio_rpmsg_trysend_offchannel(struct
> rpmsg_endpoint *ept, u32 src,
> return rpmsg_send_offchannel_raw(rpdev, src, dst, data, len, false);
> }
>
> +static int virtio_get_buf_payload_size(struct rpmsg_endpoint *ept)
> +{
> + struct rpmsg_device *rpdev = ept->rpdev;
> + struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
> + int size = vch->vrp->buf_size - sizeof(struct rpmsg_hdr);
> +
> + return size < 0 ? -EMSGSIZE : size;
Seems that a rpmsg instance configured to not even have space for the
rpmsg_hdr in each message is rather broken. Shouldn't this be prohibited
elsewhere?
Regards,
Bjorn
> +}
> +
> static int rpmsg_recv_single(struct virtproc_info
[PATCH v2 07/11] dt-bindings: mmc: arasan: Add optional properties for Arasan SDHCI
Add optional propeties for Arasan SDHCI which are used to set clk delays
for different speed modes in the controller.
Signed-off-by: Manish Narani
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 7c79496..7425d52 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -49,6 +49,21 @@ Optional Properties:
properly. Test mode can be used to force the controller to function.
- xlnx,int-clock-stable-broken: when present, the controller always reports
that the internal clock is stable even when it is not.
+ - clk-phase-legacy: Input/Output Clock Delay pair in degrees for Legacy Mode.
+ - clk-phase-mmc-hs: Input/Output Clock Delay pair degrees for MMC HS.
+ - clk-phase-sd-hs: Input/Output Clock Delay pair in degrees for SD HS.
+ - clk-phase-uhs-sdr12: Input/Output Clock Delay pair in degrees for SDR12.
+ - clk-phase-uhs-sdr25: Input/Output Clock Delay pair in degrees for SDR25.
+ - clk-phase-uhs-sdr50: Input/Output Clock Delay pair in degrees for SDR50.
+ - clk-phase-uhs-sdr104: Input/Output Clock Delay pair in degrees for SDR104.
+ - clk-phase-uhs-ddr50: Input/Output Clock Delay pair in degrees for SD DDR50.
+ - clk-phase-mmc-ddr52: Input/Output Clock Delay pair in degrees for MMC
DDR52.
+ - clk-phase-mmc-hs200: Input/Output Clock Delay pair in degrees for MMC
HS200.
+ - clk-phase-mmc-hs400: Input/Output Clock Delay pair in degrees for MMC
HS400.
+
+ Above mentioned are the clock (phase) delays which are to be configured in
the
+ controller while switching to particular speed mode. If not specified, driver
+ will configure the default value defined for particular mode in it.
Example:
sdhci@e010 {
--
2.1.1
[PATCH v2 05/11] dt-bindings: mmc: arasan: Update Documentation for the input clock
Add documentation for an optional input clock which is essentially used in sampling the input data coming from the card. Signed-off-by: Manish Narani --- Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index 15c6397..7c79496 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt @@ -23,10 +23,10 @@ Required Properties: - reg: From mmc bindings: Register location and length. - clocks: From clock bindings: Handles to clock inputs. - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb" -Apart from these two there is one more optional clock which -is "clk_sdcard". This clock represents output clock from -controller and card. This must be specified when #clock-cells -is specified. +Apart from these two there are two more optional clocks which +are "clk_sdcard" and "clk_sample". These two clocks represent +output and input clocks between controller and card. These +must be specified when #clock-cells is specified. - interrupts: Interrupt specifier Required Properties for "arasan,sdhci-5.1": @@ -40,9 +40,9 @@ Optional Properties: - clock-output-names: If specified, this will be the name of the card clock which will be exposed by this device. Required if #clock-cells is specified. - - #clock-cells: If specified this should be the value <0>. With this -property in place we will export one clock representing the Card -Clock. This clock is expected to be consumed by our PHY. You must also + - #clock-cells: If specified this should be the value <0> or <1>. With this +property in place we will export one or two clocks representing the Card +Clock. These clocks are expected to be consumed by our PHY. You must also specify - xlnx,fails-without-test-cd: when present, the controller doesn't work when the CD line is not connected properly, and the line is not connected -- 2.1.1
[PATCH v2 06/11] mmc: sdhci-of-arasan: Add sampling clock for a phy to use
There are some operations like setting the clock delays may need to have
two clocks, one for output path and one for input path. Adding input
path clock for some phys to use.
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 118 ++---
1 file changed, 110 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index c7586f5..9513813 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -75,10 +75,14 @@ struct sdhci_arasan_soc_ctl_map {
* struct sdhci_arasan_clk_data
* @sdcardclk_hw: Struct for the clock we might provide to a PHY.
* @sdcardclk: Pointer to normal 'struct clock' for sdcardclk_hw.
+ * @sampleclk_hw: Struct for the clock we might provide to a PHY.
+ * @sampleclk: Pointer to normal 'struct clock' for sampleclk_hw.
*/
struct sdhci_arasan_clk_data {
struct clk_hw sdcardclk_hw;
struct clk *sdcardclk;
+ struct clk_hw sampleclk_hw;
+ struct clk *sampleclk;
};
/**
@@ -527,6 +531,33 @@ static const struct clk_ops arasan_sdcardclk_ops = {
};
/**
+ * sdhci_arasan_sampleclk_recalc_rate - Return the sampling clock rate
+ *
+ * Return the current actual rate of the sampling clock. This can be used
+ * to communicate with out PHY.
+ *
+ * @hw:Pointer to the hardware clock structure.
+ * @parent_rateThe parent rate (should be rate of clk_xin).
+ * Returns the sample clock rate.
+ */
+static unsigned long sdhci_arasan_sampleclk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+
+{
+ struct sdhci_arasan_clk_data *clk_data =
+ container_of(hw, struct sdhci_arasan_clk_data, sampleclk_hw);
+ struct sdhci_arasan_data *sdhci_arasan =
+ container_of(clk_data, struct sdhci_arasan_data, clk_data);
+ struct sdhci_host *host = sdhci_arasan->host;
+
+ return host->mmc->actual_clock;
+}
+
+static const struct clk_ops arasan_sampleclk_ops = {
+ .recalc_rate = sdhci_arasan_sampleclk_recalc_rate,
+};
+
+/**
* sdhci_arasan_update_clockmultiplier - Set corecfg_clockmultiplier
*
* The corecfg_clockmultiplier is supposed to contain clock multiplier
@@ -605,7 +636,7 @@ static void sdhci_arasan_update_baseclkfreq(struct
sdhci_host *host)
}
/**
- * sdhci_arasan_register_sdclk - Register the sdclk for a PHY to use
+ * sdhci_arasan_register_sdcardclk - Register the sdcardclk for a PHY to use
*
* Some PHY devices need to know what the actual card clock is. In order for
* them to find out, we'll provide a clock through the common clock framework
@@ -624,9 +655,10 @@ static void sdhci_arasan_update_baseclkfreq(struct
sdhci_host *host)
* @dev: Pointer to our struct device.
* Returns 0 on success and error value on error
*/
-static int sdhci_arasan_register_sdclk(struct sdhci_arasan_data *sdhci_arasan,
- struct clk *clk_xin,
- struct device *dev)
+static int
+sdhci_arasan_register_sdcardclk(struct sdhci_arasan_data *sdhci_arasan,
+ struct clk *clk_xin,
+ struct device *dev)
{
struct sdhci_arasan_clk_data *clk_data = _arasan->clk_data;
struct device_node *np = dev->of_node;
@@ -662,7 +694,7 @@ static int sdhci_arasan_register_sdclk(struct
sdhci_arasan_data *sdhci_arasan,
ret = of_clk_add_hw_provider(np, of_clk_hw_simple_get,
_data->sdcardclk_hw);
if (ret) {
- dev_err(dev, "Failed to add clock provider\n");
+ dev_err(dev, "Failed to add sdcard clock provider\n");
return ret;
}
@@ -676,10 +708,74 @@ static int sdhci_arasan_register_sdclk(struct
sdhci_arasan_data *sdhci_arasan,
}
/**
+ * sdhci_arasan_register_sampleclk - Register the sampleclk for a PHY to use
+ *
+ * Some PHY devices need to know what the actual card clock is. In order for
+ * them to find out, we'll provide a clock through the common clock framework
+ * for them to query.
+ *
+ * @sdhci_arasan: Our private data structure.
+ * @clk_xin: Pointer to the functional clock
+ * @dev: Pointer to our struct device.
+ * Returns 0 on success and error value on error
+ */
+static int
+sdhci_arasan_register_sampleclk(struct sdhci_arasan_data *sdhci_arasan,
+ struct clk *clk_xin,
+ struct device *dev)
+{
+ struct sdhci_arasan_clk_data *clk_data = _arasan->clk_data;
+ struct device_node *np = dev->of_node;
+ struct clk_init_data sampleclk_init;
+ const char *parent_clk_name;
+ int ret;
+
+ /* Providing a clock to the PHY is optional; no error if missing */
+ if
[PATCH v2 00/11] Arasan SDHCI enhancements and ZynqMP Tap Delays Handling
This patch series does the following: - Reorganize the Clock Handling in Arasan SD driver - Adds new sampling clock in Arasan SD driver - Adds support to set Clock Delays in SD Arasan Driver - Add SDIO Tap Delay handling in ZynqMP firmware driver - Add support for ZynqMP Tap Delays setting in Arasan SD driver Changes in v2: - Replaced the deprecated calls to clock framework APIs - Added support for dev_clk_get() call to work for SD card clock - Separated the clock data struct - Fragmented the patch series in smaller patches to make it more readable This patch series contains a DT patch, which I think should be there to maintain the order of commits. Manish Narani (11): dt-bindings: mmc: arasan: Update documentation for SD Card Clock arm64: dts: rockchip: Add optional clock property indicating sdcard clock mmc: sdhci-of-arasan: Replace deprecated clk API calls mmc: sdhci-of-arasan: Separate out clk related data to another structure dt-bindings: mmc: arasan: Update Documentation for the input clock mmc: sdhci-of-arasan: Add sampling clock for a phy to use dt-bindings: mmc: arasan: Add optional properties for Arasan SDHCI mmc: sdhci-of-arasan: Add support to set clock phase delays for SD firmware: xilinx: Add SDIO Tap Delay APIs dt-bindings: mmc: arasan: Document 'xlnx,zynqmp-8.9a' controller mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup .../devicetree/bindings/mmc/arasan,sdhci.txt | 49 ++- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 +- drivers/firmware/xilinx/zynqmp.c | 48 +++ drivers/mmc/host/sdhci-of-arasan.c | 453 - include/linux/firmware/xlnx-zynqmp.h | 15 +- 5 files changed, 540 insertions(+), 29 deletions(-) -- 2.1.1
[PATCH v2 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock
The clock handling is to be updated in the Arasan SDHCI. As the 'devm_clk_register' is deprecated in the clock framework, this needs to specify one more clock named 'clk_sdcard' to get the clock in the driver via 'devm_clk_get()'. This clock represents the clock from controller to the card. Signed-off-by: Manish Narani --- Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index 1edbb04..15c6397 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt @@ -23,6 +23,10 @@ Required Properties: - reg: From mmc bindings: Register location and length. - clocks: From clock bindings: Handles to clock inputs. - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb" +Apart from these two there is one more optional clock which +is "clk_sdcard". This clock represents output clock from +controller and card. This must be specified when #clock-cells +is specified. - interrupts: Interrupt specifier Required Properties for "arasan,sdhci-5.1": @@ -36,9 +40,10 @@ Optional Properties: - clock-output-names: If specified, this will be the name of the card clock which will be exposed by this device. Required if #clock-cells is specified. - - #clock-cells: If specified this should be the value <0>. With this property -in place we will export a clock representing the Card Clock. This clock -is expected to be consumed by our PHY. You must also specify + - #clock-cells: If specified this should be the value <0>. With this +property in place we will export one clock representing the Card +Clock. This clock is expected to be consumed by our PHY. You must also +specify - xlnx,fails-without-test-cd: when present, the controller doesn't work when the CD line is not connected properly, and the line is not connected properly. Test mode can be used to force the controller to function. @@ -70,8 +75,8 @@ Example: compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1"; reg = <0x0 0xfe33 0x0 0x1>; interrupts = ; - clocks = < SCLK_EMMC>, < ACLK_EMMC>; - clock-names = "clk_xin", "clk_ahb"; + clocks = < SCLK_EMMC>, < ACLK_EMMC>, < 0>; + clock-names = "clk_xin", "clk_ahb", "clk_sdcard"; arasan,soc-ctl-syscon = <>; assigned-clocks = < SCLK_EMMC>; assigned-clock-rates = <2>; -- 2.1.1
[PATCH v2 08/11] mmc: sdhci-of-arasan: Add support to set clock phase delays for SD
Add support to read Clock Phase Delays from the DT and set it via
clk_set_phase() API from clock framework. Some of the controllers might
have their own handling of setting clock delays, for this keep the
set_clk_delays as function pointer which can be assigned controller
specific handling of the same.
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 9513813..a545221 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -77,12 +77,18 @@ struct sdhci_arasan_soc_ctl_map {
* @sdcardclk: Pointer to normal 'struct clock' for sdcardclk_hw.
* @sampleclk_hw: Struct for the clock we might provide to a PHY.
* @sampleclk: Pointer to normal 'struct clock' for sampleclk_hw.
+ * @clk_phase_in: Array of Input Clock Phase Delays for all speed modes
+ * @clk_phase_out: Array of Output Clock Phase Delays for all speed modes
+ * @set_clk_delays:Function pointer for setting Clock Delays
*/
struct sdhci_arasan_clk_data {
struct clk_hw sdcardclk_hw;
struct clk *sdcardclk;
struct clk_hw sampleclk_hw;
struct clk *sampleclk;
+ int clk_phase_in[MMC_TIMING_MMC_HS400 + 1];
+ int clk_phase_out[MMC_TIMING_MMC_HS400 + 1];
+ void(*set_clk_delays)(struct sdhci_host *host);
};
/**
@@ -180,6 +186,7 @@ static void sdhci_arasan_set_clock(struct sdhci_host *host,
unsigned int clock)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
+ struct sdhci_arasan_clk_data *clk_data = _arasan->clk_data;
bool ctrl_phy = false;
if (!IS_ERR(sdhci_arasan->phy)) {
@@ -221,6 +228,10 @@ static void sdhci_arasan_set_clock(struct sdhci_host
*host, unsigned int clock)
sdhci_arasan->is_phy_on = false;
}
+ /* Set the Input and Output Clock Phase Delays */
+ if (clk_data->set_clk_delays)
+ clk_data->set_clk_delays(host);
+
sdhci_set_clock(host, clock);
if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE)
@@ -635,6 +646,84 @@ static void sdhci_arasan_update_baseclkfreq(struct
sdhci_host *host)
sdhci_arasan_syscon_write(host, _ctl_map->baseclkfreq, mhz);
}
+static void sdhci_arasan_set_clk_delays(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
+ struct sdhci_arasan_clk_data *clk_data = _arasan->clk_data;
+
+ clk_set_phase(clk_data->sampleclk,
+ clk_data->clk_phase_in[host->timing]);
+ clk_set_phase(clk_data->sdcardclk,
+ clk_data->clk_phase_out[host->timing]);
+}
+
+static void arasan_dt_read_clk_phase(struct device *dev,
+struct sdhci_arasan_clk_data *clk_data,
+unsigned int timing, const char *prop)
+{
+ struct device_node *np = dev->of_node;
+
+ int clk_phase[2] = {0};
+
+ /*
+* Read Tap Delay values from DT, if the DT does not contain the
+* Tap Values then use the pre-defined values.
+*/
+ if (of_property_read_variable_u32_array(np, prop, _phase[0],
+ 2, 0)) {
+ dev_dbg(dev, "Using predefined clock phase for %s = %d %d\n",
+ prop, clk_data->clk_phase_in[timing],
+ clk_data->clk_phase_out[timing]);
+ return;
+ }
+
+ /* The values read are Input and Output Clock Delays in order */
+ clk_data->clk_phase_in[timing] = clk_phase[0];
+ clk_data->clk_phase_out[timing] = clk_phase[1];
+}
+
+/**
+ * arasan_dt_parse_clk_phases - Read Clock Delay values from DT
+ *
+ * Called at initialization to parse the values of Clock Delays.
+ *
+ * @dev: Pointer to our struct device.
+ */
+static void arasan_dt_parse_clk_phases(struct device *dev,
+ struct sdhci_arasan_clk_data *clk_data)
+{
+ /*
+* This has been kept as a pointer and is assigned a function here.
+* So that different controller variants can assign their own handling
+* function.
+*/
+ clk_data->set_clk_delays = sdhci_arasan_set_clk_delays;
+
+ arasan_dt_read_clk_phase(dev, clk_data, MMC_TIMING_LEGACY,
+"clk-phase-legacy");
+ arasan_dt_read_clk_phase(dev, clk_data, MMC_TIMING_MMC_HS,
+"clk-phase-mmc-hs");
+ arasan_dt_read_clk_phase(dev, clk_data, MMC_TIMING_SD_HS,
+"clk-phase-sd-hs");
+ arasan_dt_read_clk_phase(dev, clk_data,
[PATCH v2 11/11] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup
Apart from taps set by auto tuning, ZynqMP platform has feature to set
the tap values manually. Add support to set tap delay values in HW via
ZynqMP SoC framework.
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 200 -
1 file changed, 198 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index a545221..508d942 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "cqhci.h"
#include "sdhci-pltfm.h"
@@ -32,6 +33,10 @@
#define PHY_CLK_TOO_SLOW_HZ40
+/* Default settings for ZynqMP Clock Phases */
+#define ZYNQMP_ICLK_PHASE {0, 63, 63, 0, 63, 0, 0, 183, 54, 0, 0}
+#define ZYNQMP_OCLK_PHASE {0, 60, 72, 0, 60, 72, 135, 180, 72, 36, 0}
+
/*
* On some SoCs the syscon area has a feature where the upper 16-bits of
* each 32-bit register act as a write mask for the lower 16-bits. This allows
@@ -80,6 +85,7 @@ struct sdhci_arasan_soc_ctl_map {
* @clk_phase_in: Array of Input Clock Phase Delays for all speed modes
* @clk_phase_out: Array of Output Clock Phase Delays for all speed modes
* @set_clk_delays:Function pointer for setting Clock Delays
+ * @clk_of_data: Platform specific runtime clock data storage pointer
*/
struct sdhci_arasan_clk_data {
struct clk_hw sdcardclk_hw;
@@ -89,6 +95,11 @@ struct sdhci_arasan_clk_data {
int clk_phase_in[MMC_TIMING_MMC_HS400 + 1];
int clk_phase_out[MMC_TIMING_MMC_HS400 + 1];
void(*set_clk_delays)(struct sdhci_host *host);
+ void*clk_of_data;
+};
+
+struct sdhci_arasan_zynqmp_clk_data {
+ const struct zynqmp_eemi_ops *eemi_ops;
};
/**
@@ -510,6 +521,10 @@ static const struct of_device_id sdhci_arasan_of_match[] =
{
.compatible = "arasan,sdhci-4.9a",
.data = _arasan_data,
},
+ {
+ .compatible = "xlnx,zynqmp-8.9a",
+ .data = _arasan_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
@@ -569,6 +584,144 @@ static const struct clk_ops arasan_sampleclk_ops = {
};
/**
+ * sdhci_zynqmp_sdcardclk_set_phase - Set the SD Output Clock Tap Delays
+ *
+ * Set the SD Output Clock Tap Delays for Output path
+ *
+ * @hw:Pointer to the hardware clock structure.
+ * @degreesThe clock phase shift between 0 - 359.
+ * Return: 0 on success and error value on error
+ */
+static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
+
+{
+ struct sdhci_arasan_clk_data *clk_data =
+ container_of(hw, struct sdhci_arasan_clk_data, sdcardclk_hw);
+ struct sdhci_arasan_data *sdhci_arasan =
+ container_of(clk_data, struct sdhci_arasan_data, clk_data);
+ struct sdhci_host *host = sdhci_arasan->host;
+ struct sdhci_arasan_zynqmp_clk_data *zynqmp_clk_data =
+ clk_data->clk_of_data;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_clk_data->eemi_ops;
+ const char *clk_name = clk_hw_get_name(hw);
+ u32 device_id = !strcmp(clk_name, "clk_out_sd0") ? 0 : 1;
+ u8 tap_delay, tap_max = 0;
+
+ if (!eemi_ops->sdio_out_setphase)
+ return -ENODEV;
+
+ /*
+* This is applicable for SDHCI_SPEC_300 and above
+* ZynqMP does not set phase for <=25MHz clock.
+* If degrees is zero, no need to do anything.
+*/
+ if (host->version < SDHCI_SPEC_300 ||
+ host->timing == MMC_TIMING_LEGACY ||
+ host->timing == MMC_TIMING_UHS_SDR12 || !degrees)
+ return 0;
+
+ switch (host->timing) {
+ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_SD_HS:
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_DDR50:
+ case MMC_TIMING_MMC_DDR52:
+ /* For 50MHz clock, 30 Taps are available */
+ tap_max = 30;
+ break;
+ case MMC_TIMING_UHS_SDR50:
+ /* For 100MHz clock, 15 Taps are available */
+ tap_max = 15;
+ break;
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ /* For 200MHz clock, 8 Taps are available */
+ tap_max = 8;
+ default:
+ break;
+ }
+
+ tap_delay = (degrees * tap_max) / 360;
+
+ /* Set the Clock Phase */
+ return eemi_ops->sdio_out_setphase(device_id, tap_delay);
+}
+
+static const struct clk_ops zynqmp_sdcardclk_ops = {
+ .recalc_rate = sdhci_arasan_sdcardclk_recalc_rate,
+ .set_phase = sdhci_zynqmp_sdcardclk_set_phase,
+};
+
+/**
+ * sdhci_zynqmp_sampleclk_set_phase - Set the SD Input Clock Tap Delays
+ *
+ * Set the SD Input Clock Tap Delays for Input path
+ *
+ * @hw:
[PATCH v2 02/11] arm64: dts: rockchip: Add optional clock property indicating sdcard clock
As devm_clk_register() is deprecated in the clock framework, it is mandatory to use devm_clk_get() for getting the clock. This patch adds sdcard clock which will be used for the same. Signed-off-by: Manish Narani --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 196ac9b..0b512f3 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -332,8 +332,8 @@ arasan,soc-ctl-syscon = <>; assigned-clocks = < SCLK_EMMC>; assigned-clock-rates = <2>; - clocks = < SCLK_EMMC>, < ACLK_EMMC>; - clock-names = "clk_xin", "clk_ahb"; + clocks = < SCLK_EMMC>, < ACLK_EMMC>, < 0>; + clock-names = "clk_xin", "clk_ahb", "clk_sdcard"; clock-output-names = "emmc_cardclock"; #clock-cells = <0>; phys = <_phy>; -- 2.1.1
[PATCH v2 09/11] firmware: xilinx: Add SDIO Tap Delay APIs
Add APIs for setting SDIO Tap Delays on ZynqMP platform.
Signed-off-by: Manish Narani
---
drivers/firmware/xilinx/zynqmp.c | 48
include/linux/firmware/xlnx-zynqmp.h | 15 ++-
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index fd3d837..b81f1be 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -664,6 +664,52 @@ static int zynqmp_pm_set_requirement(const u32 node, const
u32 capabilities,
qos, ack, NULL);
}
+/**
+ * zynqmp_pm_sdio_out_setphase() - PM call to set clock output delays for SD
+ * @device_id: Device ID of the SD controller
+ * @tap_delay: Tap Delay value for output clock
+ *
+ * This API function is to be used for setting the clock output delays for SD
+ * clock.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_sdio_out_setphase(u32 device_id, u8 tap_delay)
+{
+ u32 node_id = (!device_id) ? NODE_SD_0 : NODE_SD_1;
+ int ret;
+
+ ret = zynqmp_pm_ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
+ PM_TAPDELAY_OUTPUT, tap_delay, NULL);
+ if (ret)
+ pr_err("Error setting Output Tap Delay\n");
+
+ return ret;
+}
+
+/**
+ * zynqmp_pm_sdio_in_setphase() - PM call to set clock input delays for SD
+ * @device_id: Device ID of the SD controller
+ * @tap_delay: Tap Delay value for input clock
+ *
+ * This API function is to be used for setting the clock input delays for SD
+ * clock.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_sdio_in_setphase(u32 device_id, u8 tap_delay)
+{
+ u32 node_id = (!device_id) ? NODE_SD_0 : NODE_SD_1;
+ int ret;
+
+ ret = zynqmp_pm_ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
+ PM_TAPDELAY_INPUT, tap_delay, NULL);
+ if (ret)
+ pr_err("Error setting Input Tap Delay\n");
+
+ return ret;
+}
+
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.get_chipid = zynqmp_pm_get_chipid,
@@ -687,6 +733,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.set_requirement = zynqmp_pm_set_requirement,
.fpga_load = zynqmp_pm_fpga_load,
.fpga_get_status = zynqmp_pm_fpga_get_status,
+ .sdio_out_setphase = zynqmp_pm_sdio_out_setphase,
+ .sdio_in_setphase = zynqmp_pm_sdio_in_setphase,
};
/**
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 1262ea6..d9b53e5 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -92,7 +92,8 @@ enum pm_ret_status {
};
enum pm_ioctl_id {
- IOCTL_SET_PLL_FRAC_MODE = 8,
+ IOCTL_SET_SD_TAPDELAY = 7,
+ IOCTL_SET_PLL_FRAC_MODE,
IOCTL_GET_PLL_FRAC_MODE,
IOCTL_SET_PLL_FRAC_DATA,
IOCTL_GET_PLL_FRAC_DATA,
@@ -251,6 +252,16 @@ enum zynqmp_pm_request_ack {
ZYNQMP_PM_REQUEST_ACK_NON_BLOCKING,
};
+enum pm_node_id {
+ NODE_SD_0 = 39,
+ NODE_SD_1,
+};
+
+enum tap_delay_type {
+ PM_TAPDELAY_INPUT = 0,
+ PM_TAPDELAY_OUTPUT,
+};
+
/**
* struct zynqmp_pm_query_data - PM query data
* @qid: query ID
@@ -295,6 +306,8 @@ struct zynqmp_eemi_ops {
const u32 capabilities,
const u32 qos,
const enum zynqmp_pm_request_ack ack);
+ int (*sdio_out_setphase)(u32 device_id, u8 tap_delay);
+ int (*sdio_in_setphase)(u32 device_id, u8 tap_delay);
};
int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
--
2.1.1
[PATCH v2 03/11] mmc: sdhci-of-arasan: Replace deprecated clk API calls
The clk framework APIs devm_clk_register and of_clk_add_provider, which
are used here, are deprecated. Replace the calls with the new API calls.
Also add an API call devm_clk_get() to get the clock from DT.
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index b12abf9..d60a2e8 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -641,14 +641,25 @@ static int sdhci_arasan_register_sdclk(struct
sdhci_arasan_data *sdhci_arasan,
sdcardclk_init.ops = _sdcardclk_ops;
sdhci_arasan->sdcardclk_hw.init = _init;
- sdhci_arasan->sdcardclk =
- devm_clk_register(dev, _arasan->sdcardclk_hw);
+ ret = devm_clk_hw_register(dev, _arasan->sdcardclk_hw);
+ if (ret) {
+ dev_err(dev, "Failed to register SD clk_hw\n");
+ return ret;
+ }
sdhci_arasan->sdcardclk_hw.init = NULL;
- ret = of_clk_add_provider(np, of_clk_src_simple_get,
- sdhci_arasan->sdcardclk);
- if (ret)
+ ret = of_clk_add_hw_provider(np, of_clk_hw_simple_get,
+_arasan->sdcardclk_hw);
+ if (ret) {
dev_err(dev, "Failed to add clock provider\n");
+ return ret;
+ }
+
+ sdhci_arasan->sdcardclk = devm_clk_get(dev, "clk_sdcard");
+ if (IS_ERR(sdhci_arasan->sdcardclk)) {
+ dev_err(dev, "sdcardclk clock not found.\n");
+ ret = PTR_ERR(sdhci_arasan->sdcardclk);
+ }
return ret;
}
--
2.1.1
[PATCH v2 10/11] dt-bindings: mmc: arasan: Document 'xlnx,zynqmp-8.9a' controller
Add documentation for 'xlnx,zynqmp-8.9a' SDHCI controller and optional
properties followed by example.
Signed-off-by: Manish Narani
---
.../devicetree/bindings/mmc/arasan,sdhci.txt | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 7425d52..d2058ee 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -15,6 +15,9 @@ Required Properties:
- "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY
- "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY
For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
+- "xlnx,zynqmp-8.9a": ZynqMP SDHCI 8.9a PHY
+ For this device it is strongly suggested to include clock-output-names
and
+ #clock-cells.
- "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY
Note: This binding has been deprecated and moved to [5].
@@ -65,6 +68,10 @@ Optional Properties:
controller while switching to particular speed mode. If not specified, driver
will configure the default value defined for particular mode in it.
+ - xlnx,mio-bank: When specified, this will indicate the MIO bank number in
+which the command and data lines are configured. If not specified, driver
+will assume this as 0.
+
Example:
sdhci@e010 {
compatible = "arasan,sdhci-8.9a";
@@ -100,3 +107,15 @@ Example:
phy-names = "phy_arasan";
#clock-cells = <0>;
};
+
+ sdhci: mmc@ff16 {
+ compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
+ interrupt-parent = <>;
+ interrupts = <0 48 4>;
+ reg = <0x0 0xff16 0x0 0x1000>;
+ clocks = <>, <>, < 0>, < 1>;
+ clock-names = "clk_xin", "clk_ahb", "clk_sdcard", "clk_sample";
+ clock-output-names = "clk_out_sd0", "clk_in_sd0";
+ #clock-cells = <1>;
+ clk-phase-sd-hs = <63>, <72>;
+ };
--
2.1.1
[PATCH v2 04/11] mmc: sdhci-of-arasan: Separate out clk related data to another structure
To improve the code readability, use two different structs, one for
clock provider data and one for mmc platform data.
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index d60a2e8..c7586f5 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -72,13 +72,22 @@ struct sdhci_arasan_soc_ctl_map {
};
/**
+ * struct sdhci_arasan_clk_data
+ * @sdcardclk_hw: Struct for the clock we might provide to a PHY.
+ * @sdcardclk: Pointer to normal 'struct clock' for sdcardclk_hw.
+ */
+struct sdhci_arasan_clk_data {
+ struct clk_hw sdcardclk_hw;
+ struct clk *sdcardclk;
+};
+
+/**
* struct sdhci_arasan_data
* @host: Pointer to the main SDHCI host structure.
* @clk_ahb: Pointer to the AHB clock
* @phy: Pointer to the generic phy
+ * @clk_data: Struct for the Arasan Controller Clock Data.
* @is_phy_on: True if the PHY is on; false if not.
- * @sdcardclk_hw: Struct for the clock we might provide to a PHY.
- * @sdcardclk: Pointer to normal 'struct clock' for sdcardclk_hw.
* @soc_ctl_base: Pointer to regmap for syscon for soc_ctl registers.
* @soc_ctl_map: Map to get offsets into soc_ctl registers.
*/
@@ -89,8 +98,7 @@ struct sdhci_arasan_data {
boolis_phy_on;
boolhas_cqe;
- struct clk_hw sdcardclk_hw;
- struct clk *sdcardclk;
+ struct sdhci_arasan_clk_data clk_data;
struct regmap *soc_ctl_base;
const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
@@ -505,8 +513,10 @@ static unsigned long
sdhci_arasan_sdcardclk_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
+ struct sdhci_arasan_clk_data *clk_data =
+ container_of(hw, struct sdhci_arasan_clk_data, sdcardclk_hw);
struct sdhci_arasan_data *sdhci_arasan =
- container_of(hw, struct sdhci_arasan_data, sdcardclk_hw);
+ container_of(clk_data, struct sdhci_arasan_data, clk_data);
struct sdhci_host *host = sdhci_arasan->host;
return host->mmc->actual_clock;
@@ -618,6 +628,7 @@ static int sdhci_arasan_register_sdclk(struct
sdhci_arasan_data *sdhci_arasan,
struct clk *clk_xin,
struct device *dev)
{
+ struct sdhci_arasan_clk_data *clk_data = _arasan->clk_data;
struct device_node *np = dev->of_node;
struct clk_init_data sdcardclk_init;
const char *parent_clk_name;
@@ -640,25 +651,25 @@ static int sdhci_arasan_register_sdclk(struct
sdhci_arasan_data *sdhci_arasan,
sdcardclk_init.flags = CLK_GET_RATE_NOCACHE;
sdcardclk_init.ops = _sdcardclk_ops;
- sdhci_arasan->sdcardclk_hw.init = _init;
- ret = devm_clk_hw_register(dev, _arasan->sdcardclk_hw);
+ clk_data->sdcardclk_hw.init = _init;
+ ret = devm_clk_hw_register(dev, _data->sdcardclk_hw);
if (ret) {
dev_err(dev, "Failed to register SD clk_hw\n");
return ret;
}
- sdhci_arasan->sdcardclk_hw.init = NULL;
+ clk_data->sdcardclk_hw.init = NULL;
ret = of_clk_add_hw_provider(np, of_clk_hw_simple_get,
-_arasan->sdcardclk_hw);
+_data->sdcardclk_hw);
if (ret) {
dev_err(dev, "Failed to add clock provider\n");
return ret;
}
- sdhci_arasan->sdcardclk = devm_clk_get(dev, "clk_sdcard");
- if (IS_ERR(sdhci_arasan->sdcardclk)) {
+ clk_data->sdcardclk = devm_clk_get(dev, "clk_sdcard");
+ if (IS_ERR(clk_data->sdcardclk)) {
dev_err(dev, "sdcardclk clock not found.\n");
- ret = PTR_ERR(sdhci_arasan->sdcardclk);
+ ret = PTR_ERR(clk_data->sdcardclk);
}
return ret;
--
2.1.1
RE: memory leak in create_ctx
syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:79c3ba32 Merge tag 'drm-fixes-2019-06-07-1' of git://anong.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=170e0bfea0 > kernel config: https://syzkaller.appspot.com/x/.config?x=d5c73825cbdc7326 > dashboard link: https://syzkaller.appspot.com/bug?extid=06537213db7ba2745c4a > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10aa806aa0 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+06537213db7ba2745...@syzkaller.appspotmail.com > > IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready > 2019/06/08 14:55:51 executed programs: 15 > 2019/06/08 14:55:56 executed programs: 31 > 2019/06/08 14:56:02 executed programs: 51 > BUG: memory leak > unreferenced object 0x888117ceae00 (size 512): >comm "syz-executor.3", pid 7233, jiffies 4294949016 (age 13.640s) >hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [] kmemleak_alloc_recursive > include/linux/kmemleak.h:55 [inline] > [ ] slab_post_alloc_hook mm/slab.h:439 [inline] > [ ] slab_alloc mm/slab.c:3326 [inline] > [ ] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<14132182>] kmalloc include/linux/slab.h:547 [inline] > [<14132182>] kzalloc include/linux/slab.h:742 [inline] > [<14132182>] create_ctx+0x25/0x70 net/tls/tls_main.c:601 > [ ] tls_init net/tls/tls_main.c:787 [inline] > [ ] tls_init+0x97/0x1e0 net/tls/tls_main.c:769 > [<37b0c43c>] __tcp_set_ulp net/ipv4/tcp_ulp.c:126 [inline] > [<37b0c43c>] tcp_set_ulp+0xe2/0x190 net/ipv4/tcp_ulp.c:147 > [<7a284277>] do_tcp_setsockopt.isra.0+0x19a/0xd60 > net/ipv4/tcp.c:2784 > [ ] tcp_setsockopt+0x71/0x80 net/ipv4/tcp.c:3098 > [ ] sock_common_setsockopt+0x38/0x50 > net/core/sock.c:3124 > [<06b0801f>] __sys_setsockopt+0x98/0x120 net/socket.c:2072 > [ ] __do_sys_setsockopt net/socket.c:2083 [inline] > [ ] __se_sys_setsockopt net/socket.c:2080 [inline] > [ ] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080 > [ ] do_syscall_64+0x76/0x1a0 > arch/x86/entry/common.c:301 > [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x88810965dc00 (size 512): >comm "syz-executor.2", pid 7235, jiffies 4294949016 (age 13.640s) >hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [ ] kmemleak_alloc_recursive > include/linux/kmemleak.h:55 [inline] > [ ] slab_post_alloc_hook mm/slab.h:439 [inline] > [ ] slab_alloc mm/slab.c:3326 [inline] > [ ] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<14132182>] kmalloc include/linux/slab.h:547 [inline] > [<14132182>] kzalloc include/linux/slab.h:742 [inline] > [<14132182>] create_ctx+0x25/0x70 net/tls/tls_main.c:601 > [ ] tls_init net/tls/tls_main.c:787 [inline] > [ ] tls_init+0x97/0x1e0 net/tls/tls_main.c:769 > [<37b0c43c>] __tcp_set_ulp net/ipv4/tcp_ulp.c:126 [inline] > [<37b0c43c>] tcp_set_ulp+0xe2/0x190 net/ipv4/tcp_ulp.c:147 > [<7a284277>] do_tcp_setsockopt.isra.0+0x19a/0xd60 > net/ipv4/tcp.c:2784 > [ ] tcp_setsockopt+0x71/0x80 net/ipv4/tcp.c:3098 > [ ] sock_common_setsockopt+0x38/0x50 > net/core/sock.c:3124 > [<06b0801f>] __sys_setsockopt+0x98/0x120 net/socket.c:2072 > [ ] __do_sys_setsockopt net/socket.c:2083 [inline] > [ ] __se_sys_setsockopt net/socket.c:2080 [inline] > [ ] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080 > [ ] do_syscall_64+0x76/0x1a0 > arch/x86/entry/common.c:301 > [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x8881207d7600 (size 512): >comm "syz-executor.5", pid 7244, jiffies 4294949019 (age 13.610s) >hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [ ] kmemleak_alloc_recursive >
linux-next: manual merge of the nand tree with Linus' tree
Hi all,
Today's linux-next merge of the nand tree got a conflict in:
drivers/mtd/nand/raw/mtk_ecc.h
between commit:
d2912cb15bdd ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule
500")
from Linus' tree and commit:
b74e6985bfe8 ("mtd: rawnand: mtk: Re-license MTK NAND driver as Dual MIT/GPL")
from the nand tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp1fuk8HnAy1.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH v5] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On Mon, Jun 17, 2019 at 2:56 PM Chris Chiu wrote:
>
> We have 3 laptops which connect the wifi by the same RTL8723BU.
> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> They have the same problem with the in-kernel rtl8xxxu driver, the
> iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> Nevertheless, the signal strength is reported as around -40dBm,
> which is quite good. From the wireshark capture, the tx rate for each
> data and qos data packet is only 1Mbps. Compare to the Realtek driver
> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> ~12Mbps or better. The signal strength is reported similarly around
> -40dBm. That's why we want to improve.
>
> After reading the source code of the rtl8xxxu driver and Realtek's, the
> major difference is that Realtek's driver has a watchdog which will keep
> monitoring the signal quality and updating the rate mask just like the
> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> And this kind of watchdog also exists in rtlwifi driver of some specific
> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> the same member function named dm_watchdog and will invoke the
> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> mask.
>
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps.
>
> I believe the firmware of RTL8723BU may need fix. And I think we
> can still bring in the dm_watchdog as rtlwifi to improve from the
> driver side. Please leave precious comments for my commits and
> suggest what I can do better. Or suggest if there's any better idea
> to fix this. Thanks.
>
> Signed-off-by: Chris Chiu
> ---
>
>
> Notes:
> v2:
>- Fix errors and warnings complained by checkpatch.pl
>- Replace data structure rate_adaptive by 2 member variables
>- Make rtl8xxxu_wireless_mode non-static
>- Runs refresh_rate_mask() only in station mode
> v3:
>- Remove ugly rtl8xxxu_watchdog data structure
>- Make sure only one vif exists
> v4:
>- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
>- Clear priv->vif in rtl8xxxu_remove_interface
>- Add rateid as the function argument of update_rate_mask
>- Rephrase the comment for priv->vif more explicit.
> v5:
>- Make refresh_rate_mask() generic for all sub-drivers.
>- Add definitions for SNR related to help determine rssi_level
>
>
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 -
> .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 226 +-
> 2 files changed, 274 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index 8828baf26e7b..1498a8c94d5f 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -1195,6 +1195,48 @@ struct rtl8723bu_c2h {
>
> struct rtl8xxxu_fileops;
>
> +/*mlme related.*/
> +enum wireless_mode {
> + WIRELESS_MODE_UNKNOWN = 0,
> + /* Sub-Element */
> + WIRELESS_MODE_B = BIT(0),
> + WIRELESS_MODE_G = BIT(1),
> + WIRELESS_MODE_A = BIT(2),
> + WIRELESS_MODE_N_24G = BIT(3),
> + WIRELESS_MODE_N_5G = BIT(4),
> + WIRELESS_AUTO = BIT(5),
> + WIRELESS_MODE_AC = BIT(6),
> + WIRELESS_MODE_MAX = 0x7F,
> +};
> +
> +/* from rtlwifi/wifi.h */
> +enum ratr_table_mode_new {
> + RATEID_IDX_BGN_40M_2SS = 0,
> + RATEID_IDX_BGN_40M_1SS = 1,
> + RATEID_IDX_BGN_20M_2SS_BN = 2,
> + RATEID_IDX_BGN_20M_1SS_BN = 3,
> + RATEID_IDX_GN_N2SS = 4,
> + RATEID_IDX_GN_N1SS = 5,
> + RATEID_IDX_BG = 6,
> + RATEID_IDX_G = 7,
> + RATEID_IDX_B = 8,
> + RATEID_IDX_VHT_2SS = 9,
> + RATEID_IDX_VHT_1SS = 10,
> + RATEID_IDX_MIX1 = 11,
> + RATEID_IDX_MIX2 = 12,
> + RATEID_IDX_VHT_3SS = 13,
> + RATEID_IDX_BGN_3SS = 14,
> +};
> +
> +#define RTL8XXXU_RATR_STA_INIT 0
> +#define RTL8XXXU_RATR_STA_HIGH 1
> +#define RTL8XXXU_RATR_STA_MID 2
> +#define RTL8XXXU_RATR_STA_LOW 3
> +
> +#define RTL8XXXU_NOISE_FLOOR_MIN -95
> +#define RTL8XXXU_SNR_THRESH_HIGH 50
> +#define RTL8XXXU_SNR_THRESH_LOW20
> +
> struct rtl8xxxu_priv {
> struct ieee80211_hw *hw;
> struct usb_device *udev;
> @@ -1299,6 +1341,13 @@ struct rtl8xxxu_priv {
> u8 pi_enabled:1;
> u8 no_pape:1;
> u8
Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
On Thu, Jun 27, 2019 at 5:52 PM Chris Chiu wrote: > > The WiFi tx power of RTL8723BU is extremely low after booting. So > the WiFi scan gives very limited AP list and it always fails to > connect to the selected AP. This module only supports 1x1 antenna > and the antenna is switched to bluetooth due to some incorrect > register settings. > > This commit hand over the antenna control to PTA, the wifi signal > will be back to normal and the bluetooth scan can also work at the > same time. However, the btcoexist still needs to be handled under > different circumstances. If there's a BT connection established, > the wifi still fails to connect until disconneting the BT. > > Signed-off-by: Chris Chiu > --- > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++--- > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > index 3adb1d3d47ac..6c3c70d93ac1 100644 > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv > *priv) > /* > * WLAN action by PTA > */ > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04); > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c); > > /* > * BT select S0/S1 controlled by WiFi > @@ -1568,9 +1568,12 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv > *priv) > rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.ant_sel_rsv)); > > /* > -* 0x280, 0x00, 0x200, 0x80 - not clear > +* Different settings per different antenna position. > +* Antenna switch to BT: 0x280, 0x00 (inverse) > +* Antenna switch to WiFi: 0x0, 0x280 (inverse) > +* Antenna controlled by PTA: 0x200, 0x80 (inverse) > */ > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00); > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80); > > /* > * Software control, antenna at WiFi side > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c > b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c > index 8136e268b4e6..87b2179a769e 100644 > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c > @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw > *hw) > > /* Check if MAC is already powered on */ > val8 = rtl8xxxu_read8(priv, REG_CR); > + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR); > > /* > * Fix 92DU-VC S3 hang with the reason is that secondary mac is not > * initialized. First MAC returns 0xea, second MAC returns 0x00 > */ > - if (val8 == 0xea) > + if (val8 == 0xea || !(val16 & BIT(11))) > macpower = false; > else > macpower = true; > -- > 2.11.0 > Gentle ping. Cheers. Chris
Re: linux-next: build failure after merge of the bpf-next tree
Hi all,
On Mon, 1 Jul 2019 14:57:22 +1000 Stephen Rothwell
wrote:
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c:1605:5: error: conflicting
> types for 'mlx5e_open_cq'
> int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
> ^
> In file included from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:43:
> drivers/net/ethernet/mellanox/mlx5/core/en.h:977:5: note: previous
> declaration of 'mlx5e_open_cq' was here
> int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
> ^
>
> Caused by commit
>
> 8960b38932be ("linux/dim: Rename externally used net_dim members")
>
> from the net-next tree interacting with commit
>
> db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
>
> I have applied the following merge fix patch.
>
> From 8e92dbee0daa6bac412daebd08073ba9ca31c7a6 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell
> Date: Mon, 1 Jul 2019 14:55:02 +1000
> Subject: [PATCH] net/mlx5e: fix up for "linux/dim: Rename externally used
> net_dim members"
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index 9cebaa642727..f0d77eb66acf 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> @@ -974,7 +974,7 @@ int mlx5e_open_xdpsq(struct mlx5e_channel *c, struct
> mlx5e_params *params,
> void mlx5e_close_xdpsq(struct mlx5e_xdpsq *sq);
>
> struct mlx5e_cq_param;
> -int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
> +int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
> struct mlx5e_cq_param *param, struct mlx5e_cq *cq);
> void mlx5e_close_cq(struct mlx5e_cq *cq);
>
Also, this:
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c: In function
'mlx5e_open_xsk':
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:64:9: error: variable
'icocq_moder' has initializer but incomplete type
struct net_dim_cq_moder icocq_moder = {};
^~~~
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:64:26: error: storage
size of 'icocq_moder' isn't known
struct net_dim_cq_moder icocq_moder = {};
^~~
For which I applied this:
From: Stephen Rothwell
Date: Mon, 1 Jul 2019 15:00:08 +1000
Subject: [PATCH] another fix for "linux/dim: Rename externally used net_dim
members"
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
index 9b4d47c47c92..aaffa6f68dc0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
@@ -61,7 +61,7 @@ int mlx5e_open_xsk(struct mlx5e_priv *priv, struct
mlx5e_params *params,
struct mlx5e_channel *c)
{
struct mlx5e_channel_param cparam = {};
- struct net_dim_cq_moder icocq_moder = {};
+ struct dim_cq_moder icocq_moder = {};
int err;
if (!mlx5e_validate_xsk_param(params, xsk, priv->mdev))
--
2.20.1
--
Cheers,
Stephen Rothwell
pgphOHurwSHmq.pgp
Description: OpenPGP digital signature
Re: [PATCH 12/87] dma: imx-sdma: Remove call to memset after dma_alloc_coherent
On 28-06-19, 01:35, Fuqian Huang wrote:
> In commit af7ddd8a627c
> ("Merge tag 'dma-mapping-4.21' of
> git://git.infradead.org/users/hch/dma-mapping"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
Please point to the exact commit and not the merge commit. Hint use git
blame on that file...
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/dma/imx-sdma.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 99d9f431ae2c..54d86359bdf8 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1886,10 +1886,6 @@ static int sdma_init(struct sdma_engine *sdma)
> sdma->context_phys = ccb_phys +
> MAX_DMA_CHANNELS * sizeof (struct sdma_channel_control);
>
> - /* Zero-out the CCB structures array just allocated */
> - memset(sdma->channel_control, 0,
> - MAX_DMA_CHANNELS * sizeof (struct
> sdma_channel_control));
> -
> /* disable all channels */
> for (i = 0; i < sdma->drvdata->num_events; i++)
> writel_relaxed(0, sdma->regs + chnenbl_ofs(sdma, i));
> --
> 2.11.0
--
~Vinod
linux-next: build failure after merge of the bpf-next tree
Hi all,
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/ethernet/mellanox/mlx5/core/en_main.c:1605:5: error: conflicting
types for 'mlx5e_open_cq'
int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
^
In file included from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:43:
drivers/net/ethernet/mellanox/mlx5/core/en.h:977:5: note: previous declaration
of 'mlx5e_open_cq' was here
int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
^
Caused by commit
8960b38932be ("linux/dim: Rename externally used net_dim members")
from the net-next tree interacting with commit
db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
I have applied the following merge fix patch.
From 8e92dbee0daa6bac412daebd08073ba9ca31c7a6 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell
Date: Mon, 1 Jul 2019 14:55:02 +1000
Subject: [PATCH] net/mlx5e: fix up for "linux/dim: Rename externally used
net_dim members"
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 9cebaa642727..f0d77eb66acf 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -974,7 +974,7 @@ int mlx5e_open_xdpsq(struct mlx5e_channel *c, struct
mlx5e_params *params,
void mlx5e_close_xdpsq(struct mlx5e_xdpsq *sq);
struct mlx5e_cq_param;
-int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
+int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
struct mlx5e_cq_param *param, struct mlx5e_cq *cq);
void mlx5e_close_cq(struct mlx5e_cq *cq);
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpDDLMRzF8DI.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 2/4] usb: xhci: Use register defined and field names
On 29-06-19, 00:42, Mathias Nyman wrote: > > Most of this patch should probably be squashed together with the previous > patch Will do -- ~Vinod
Re: [PATCH v4 1/4] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM
On 29-06-19, 00:40, Mathias Nyman wrote:
> On 26.6.2019 10.55, Vinod Koul wrote:
> > From: Christian Lamparter
> >
> > This patch adds a firmware loader for the uPD720201K8-711-BAC-A
> > and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> > in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
> > devices which need the firmware loader on page 2 in order to
> > work as they "do not support the External ROM".
> >
> > The "Firmware Download Sequence" is describe in chapter
> > "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131.
> >
> > The firmware "K2013080.mem" is available from a USB3.0 Host to
> > PCIe Adapter (PP2U-E card) "Firmware download" archive. An
> > alternative version can be sourced from Netgear's WNDR4700 GPL
> > archives.
> >
> > The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3
> > (2012-06-15) state that the firmware is for the following devices:
> > - uPD720201 ES 2.0 sample whose revision ID is 2.
> > - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
> > - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
> >
> > Cc: Yoshihiro Shimoda
> > Signed-off-by: Christian Lamparter
> > Signed-off-by: Bjorn Andersson
> > [vkoul: fixed comments:
> > used macros for timeout count and delay
> > removed renesas_fw_alive_check
> > cleaned renesas_fw_callback
> > removed recurion for renesas_fw_download
> > added MODULE_FIRMWARE]
> > Tested-by: Christian Lamparter
> > Signed-off-by: Vinod Koul
> > ---
> > drivers/usb/host/xhci-pci.c | 454
> > 1 file changed, 454 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > index c2fe218e051f..237df5c47fca 100644
> > --- a/drivers/usb/host/xhci-pci.c
> > +++ b/drivers/usb/host/xhci-pci.c
> > @@ -12,6 +12,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include "xhci.h"
> > #include "xhci-trace.h"
> > @@ -55,6 +57,9 @@
> > #define PCI_DEVICE_ID_AMD_PROMONTORYA_1 0x43bc
> > #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
> > +#define RENESAS_RETRY 1
> > +#define RENESAS_DELAY 10
> > +
> > static const char hcd_name[] = "xhci_hcd";
> > static struct hc_driver __read_mostly xhci_pci_hc_driver;
> > @@ -279,6 +284,429 @@ static void xhci_pme_acpi_rtd3_enable(struct pci_dev
> > *dev)
> > static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
> > #endif /* CONFIG_ACPI */
> > +static const struct renesas_fw_entry {
> > + const char *firmware_name;
> > + u16 device;
> > + u8 revision;
> > + u16 expected_version;
> > +} renesas_fw_table[] = {
> > + /*
> > +* Only the uPD720201K8-711-BAC-A or uPD720202K8-711-BAA-A
> > +* are listed in R19UH0078EJ0500 Rev.5.00 as devices which
> > +* need the software loader.
> > +*
> > +* PP2U/ReleaseNote_USB3-201-202-FW.txt:
> > +*
> > +* Note: This firmware is for the following devices.
> > +* - uPD720201 ES 2.0 sample whose revision ID is 2.
> > +* - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
> > +* - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
> > +*/
> > + { "K2013080.mem", 0x0014, 0x02, 0x2013 },
> > + { "K2013080.mem", 0x0014, 0x03, 0x2013 },
> > + { "K2013080.mem", 0x0015, 0x02, 0x2013 },
> > +};
> > +
> > +MODULE_FIRMWARE("K2013080.mem");
> > +
> > +static const struct renesas_fw_entry *renesas_needs_fw_dl(struct pci_dev
> > *dev)
> > +{
> > + const struct renesas_fw_entry *entry;
> > + size_t i;
> > +
> > + /* This loader will only work with a RENESAS device. */
> > + if (!(dev->vendor == PCI_VENDOR_ID_RENESAS))
> > + return NULL;
> > +
> > + for (i = 0; i < ARRAY_SIZE(renesas_fw_table); i++) {
> > + entry = _fw_table[i];
> > + if (entry->device == dev->device &&
> > + entry->revision == dev->revision)
> > + return entry;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +static int renesas_fw_download_image(struct pci_dev *dev,
> > +const u32 *fw,
> > +size_t step)
> > +{
> > + size_t i;
> > + int err;
> > + u8 fw_status;
> > + bool data0_or_data1;
> > +
> > + /*
> > +* The hardware does alternate between two 32-bit pages.
> > +* (This is because each row of the firmware is 8 bytes).
> > +*
> > +* for even steps we use DATA0, for odd steps DATA1.
> > +*/
> > + data0_or_data1 = (step & 1) == 1;
> > +
> > + /* step+1. Read "Set DATAX" and confirm it is cleared. */
> > + for (i = 0; i < RENESAS_RETRY; i++) {
> > + err = pci_read_config_byte(dev, 0xF5, _status);
> > + if (err)
> > + return pcibios_err_to_errno(err);
> > + if (!(fw_status & BIT(data0_or_data1)))
> > + break;
> > +
> > +
linux-next: manual merge of the bpf-next tree with the net-next tree
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/en_main.c
between commit:
8960b38932be ("linux/dim: Rename externally used net_dim members")
from the net-next tree and commits:
db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
0a06382fa406 ("net/mlx5e: Encapsulate open/close queues into a function")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 1085040675ae,67b562c7f8a1..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -1567,10 -1602,8 +1602,8 @@@ static void mlx5e_destroy_cq(struct mlx
mlx5_core_destroy_cq(cq->mdev, >mcq);
}
- static int mlx5e_open_cq(struct mlx5e_channel *c,
-struct dim_cq_moder moder,
-struct mlx5e_cq_param *param,
-struct mlx5e_cq *cq)
-int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
++int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
+ struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
{
struct mlx5_core_dev *mdev = c->mdev;
int err;
@@@ -1767,45 -1800,12 +1800,12 @@@ static void mlx5e_free_xps_cpumask(stru
free_cpumask_var(c->xps_cpumask);
}
- static int mlx5e_open_channel(struct mlx5e_priv *priv, int ix,
- struct mlx5e_params *params,
- struct mlx5e_channel_param *cparam,
- struct mlx5e_channel **cp)
+ static int mlx5e_open_queues(struct mlx5e_channel *c,
+struct mlx5e_params *params,
+struct mlx5e_channel_param *cparam)
{
- int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev,
ix));
- struct net_dim_cq_moder icocq_moder = {0, 0};
+ struct dim_cq_moder icocq_moder = {0, 0};
- struct net_device *netdev = priv->netdev;
- struct mlx5e_channel *c;
- unsigned int irq;
int err;
- int eqn;
-
- err = mlx5_vector2eqn(priv->mdev, ix, , );
- if (err)
- return err;
-
- c = kvzalloc_node(sizeof(*c), GFP_KERNEL, cpu_to_node(cpu));
- if (!c)
- return -ENOMEM;
-
- c->priv = priv;
- c->mdev = priv->mdev;
- c->tstamp = >tstamp;
- c->ix = ix;
- c->cpu = cpu;
- c->pdev = priv->mdev->device;
- c->netdev = priv->netdev;
- c->mkey_be = cpu_to_be32(priv->mdev->mlx5e_res.mkey.key);
- c->num_tc = params->num_tc;
- c->xdp = !!params->xdp_prog;
- c->stats= >channel_stats[ix].ch;
- c->irq_desc = irq_to_desc(irq);
-
- err = mlx5e_alloc_xps_cpumask(c, params);
- if (err)
- goto err_free_channel;
-
- netif_napi_add(netdev, >napi, mlx5e_napi_poll, 64);
err = mlx5e_open_cq(c, icocq_moder, >icosq_cq, >icosq.cq);
if (err)
@@@ -2150,12 -2230,12 +2230,12 @@@ void mlx5e_build_ico_cq_param(struct ml
mlx5e_build_common_cq_param(priv, param);
- param->cq_period_mode = NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE;
+ param->cq_period_mode = DIM_CQ_PERIOD_MODE_START_FROM_EQE;
}
- static void mlx5e_build_icosq_param(struct mlx5e_priv *priv,
- u8 log_wq_size,
- struct mlx5e_sq_param *param)
+ void mlx5e_build_icosq_param(struct mlx5e_priv *priv,
+u8 log_wq_size,
+struct mlx5e_sq_param *param)
{
void *sqc = param->sqc;
void *wq = MLX5_ADDR_OF(sqc, sqc, wq);
pgpSBHvV9c6Ws.pgp
Description: OpenPGP digital signature
[PATCHv2] selftests/net: skip psock_tpacket test if KALLSYMS was not enabled
The psock_tpacket test will need to access /proc/kallsyms, this would require the kernel config CONFIG_KALLSYMS to be enabled first. Apart from adding CONFIG_KALLSYMS to the net/config file here, check the file existence to determine if we can run this test will be helpful to avoid a false-positive test result when testing it directly with the following commad against a kernel that have CONFIG_KALLSYMS disabled: make -C tools/testing/selftests TARGETS=net run_tests Signed-off-by: Po-Hsu Lin --- tools/testing/selftests/net/config| 1 + tools/testing/selftests/net/run_afpackettests | 14 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config index 4740404..3dea2cb 100644 --- a/tools/testing/selftests/net/config +++ b/tools/testing/selftests/net/config @@ -25,3 +25,4 @@ CONFIG_NF_TABLES_IPV6=y CONFIG_NF_TABLES_IPV4=y CONFIG_NFT_CHAIN_NAT_IPV6=m CONFIG_NFT_CHAIN_NAT_IPV4=m +CONFIG_KALLSYMS=y diff --git a/tools/testing/selftests/net/run_afpackettests b/tools/testing/selftests/net/run_afpackettests index ea5938e..8b42e8b 100755 --- a/tools/testing/selftests/net/run_afpackettests +++ b/tools/testing/selftests/net/run_afpackettests @@ -21,12 +21,16 @@ fi echo "" echo "running psock_tpacket test" echo "" -./in_netns.sh ./psock_tpacket -if [ $? -ne 0 ]; then - echo "[FAIL]" - ret=1 +if [ -f /proc/kallsyms ]; then + ./in_netns.sh ./psock_tpacket + if [ $? -ne 0 ]; then + echo "[FAIL]" + ret=1 + else + echo "[PASS]" + fi else - echo "[PASS]" + echo "[SKIP] CONFIG_KALLSYMS not enabled" fi echo "" -- 2.7.4
Re: [PATCH v6 3/3] arm64: kexec_file: add rng-seed support
On Fri, Jun 28, 2019 at 7:47 PM Hsin-Yi Wang wrote: > > > > If the RNG wasn't initialised, we'd carry on with a warning. Why do we > > follow a different policy here? > > (Sorry, please ignore previous comment) I think this part should be same as kaslr, since they are both adding random seeds: If RNG isn't initialized, we won't be able to set these seeds, and dtb can't do anything else to deal with this, so carry on with warning. If fdt_setprop failed with no space, create_dtb() will try to setup dtb again with more space. Other failures are setting fdt's error, so returns invalid.
[PATCH v5 0/2] clocksource/drivers: Create new Hyper-V clocksource driver
This patch series moves Hyper-V clock/timer code to a separate Hyper-V clocksource driver. Previously, Hyper-V clock/timer code and data structures were mixed in with other Hyper-V code in the ISA independent drivers/hv code as well as in ISA dependent code. The new Hyper-V clocksource driver is ISA agnostic, with a just few dependencies on ISA specific functions. The patch series does not change any behavior or functionality -- it only reorganizes the existing code and fixes up the linkages. A few places outside of Hyper-V code are fixed up to use the new #include file structure. This restructuring is in response to Marc Zyngier's review comments on supporting Hyper-V running on ARM64, and is a good idea in general. It increases the amount of code shared between the x86 and ARM64 architectures, and reduces the size of the new code for supporting Hyper-V on ARM64. A new version of the Hyper-V on ARM64 patches will follow once this clocksource restructuring is accepted. The code is diff'ed against the upstream tip tree: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso Changes in v5: * Revised commit summaries [Thomas Gleixner] * Removed call to clockevents_unbind_device() [Thomas Gleixner] * Restructured hv_init_clocksource() [Thomas Gleixner] * Various other small code cleanups [Thomas Gleixner] Changes in v4: * Revised commit messages * Rebased to upstream tip tree Changes in v3: * Removed boolean argument to hv_init_clocksource(). Always call sched_clock_register, which is needed on ARM64 but a no-op on x86. * Removed separate cpuhp setup in hv_stimer_alloc() and instead directly call hv_stimer_init() and hv_stimer_cleanup() from corresponding VMbus functions. This more closely matches original code and avoids clocksource stop/restart problems on ARM64 when VMbus code denies CPU offlining request. Changes in v2: * Revised commit short descriptions so the distinction between the first and second patches is clearer [GregKH] * Renamed new clocksource driver files and functions to use existing "timer" and "stimer" names instead of introducing "syntimer". [Vitaly Kuznetsov] * Introduced CONFIG_HYPER_TIMER to fix build problem when CONFIG_HYPERV=m [Vitaly Kuznetsov] * Added "Suggested-by: Marc Zyngier" Michael Kelley (2): clocksource/drivers: Make Hyper-V clocksource ISA agnostic clocksource/drivers: Continue making Hyper-V clocksource ISA agnostic MAINTAINERS | 2 + arch/x86/entry/vdso/vma.c| 2 +- arch/x86/hyperv/hv_init.c| 91 + arch/x86/include/asm/hyperv-tlfs.h | 6 + arch/x86/include/asm/mshyperv.h | 81 +--- arch/x86/include/asm/vdso/gettimeofday.h | 2 +- arch/x86/kernel/cpu/mshyperv.c | 4 +- arch/x86/kvm/x86.c | 1 + drivers/clocksource/Makefile | 1 + drivers/clocksource/hyperv_timer.c | 339 +++ drivers/hv/Kconfig | 3 + drivers/hv/hv.c | 156 +- drivers/hv/hv_util.c | 1 + drivers/hv/hyperv_vmbus.h| 3 - drivers/hv/vmbus_drv.c | 42 ++-- include/clocksource/hyperv_timer.h | 105 ++ 16 files changed, 503 insertions(+), 336 deletions(-) create mode 100644 drivers/clocksource/hyperv_timer.c create mode 100644 include/clocksource/hyperv_timer.h -- 1.8.3.1
[PATCH v5 2/2] clocksource/drivers: Continue making Hyper-V clocksource ISA agnostic
Continue consolidating Hyper-V clock and timer code into an ISA
independent Hyper-V clocksource driver. Move the existing clocksource
code under drivers/hv and arch/x86 to the new clocksource driver
while separating out the ISA dependencies. Update Hyper-V
initialization to call initialization and cleanup routines since the
Hyper-V synthetic clock is not independently enumerated in ACPI.
Update Hyper-V clocksource users in KVM and VDSO to get definitions
from a new include file.
No behavior is changed and no new functionality is added.
Suggested-by: Marc Zyngier
Reviewed-by: Vitaly Kuznetsov
Signed-off-by: Michael Kelley
---
arch/x86/entry/vdso/vma.c| 2 +-
arch/x86/hyperv/hv_init.c| 91 +---
arch/x86/include/asm/mshyperv.h | 81 +++---
arch/x86/include/asm/vdso/gettimeofday.h | 2 +-
arch/x86/kvm/x86.c | 1 +
drivers/clocksource/hyperv_timer.c | 139 +++
drivers/hv/hv_util.c | 1 +
include/clocksource/hyperv_timer.h | 78 +
8 files changed, 235 insertions(+), 160 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 8db1f59..349a61d 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -22,7 +22,7 @@
#include
#include
#include
-#include
+#include
#if defined(CONFIG_X86_64)
unsigned int __read_mostly vdso64_enabled = 1;
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 1608050..0e033ef 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -17,64 +17,13 @@
#include
#include
#include
-#include
#include
#include
#include
-
-#ifdef CONFIG_HYPERV_TSCPAGE
-
-static struct ms_hyperv_tsc_page *tsc_pg;
-
-struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
-{
- return tsc_pg;
-}
-EXPORT_SYMBOL_GPL(hv_get_tsc_page);
-
-static u64 read_hv_clock_tsc(struct clocksource *arg)
-{
- u64 current_tick = hv_read_tsc_page(tsc_pg);
-
- if (current_tick == U64_MAX)
- rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
-
- return current_tick;
-}
-
-static struct clocksource hyperv_cs_tsc = {
- .name = "hyperv_clocksource_tsc_page",
- .rating = 400,
- .read = read_hv_clock_tsc,
- .mask = CLOCKSOURCE_MASK(64),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
-};
-#endif
-
-static u64 read_hv_clock_msr(struct clocksource *arg)
-{
- u64 current_tick;
- /*
-* Read the partition counter to get the current tick count. This count
-* is set to 0 when the partition is created and is incremented in
-* 100 nanosecond units.
-*/
- rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
- return current_tick;
-}
-
-static struct clocksource hyperv_cs_msr = {
- .name = "hyperv_clocksource_msr",
- .rating = 400,
- .read = read_hv_clock_msr,
- .mask = CLOCKSOURCE_MASK(64),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
-};
+#include
void *hv_hypercall_pg;
EXPORT_SYMBOL_GPL(hv_hypercall_pg);
-struct clocksource *hyperv_cs;
-EXPORT_SYMBOL_GPL(hyperv_cs);
u32 *hv_vp_index;
EXPORT_SYMBOL_GPL(hv_vp_index);
@@ -343,42 +292,8 @@ void __init hyperv_init(void)
x86_init.pci.arch_init = hv_pci_init;
- /*
-* Register Hyper-V specific clocksource.
-*/
-#ifdef CONFIG_HYPERV_TSCPAGE
- if (ms_hyperv.features & HV_MSR_REFERENCE_TSC_AVAILABLE) {
- union hv_x64_msr_hypercall_contents tsc_msr;
-
- tsc_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
- if (!tsc_pg)
- goto register_msr_cs;
-
- hyperv_cs = _cs_tsc;
-
- rdmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr.as_uint64);
-
- tsc_msr.enable = 1;
- tsc_msr.guest_physical_address = vmalloc_to_pfn(tsc_pg);
-
- wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr.as_uint64);
-
- hyperv_cs_tsc.archdata.vclock_mode = VCLOCK_HVCLOCK;
-
- clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
- return;
- }
-register_msr_cs:
-#endif
- /*
-* For 32 bit guests just use the MSR based mechanism for reading
-* the partition counter.
-*/
-
- hyperv_cs = _cs_msr;
- if (ms_hyperv.features & HV_MSR_TIME_REF_COUNT_AVAILABLE)
- clocksource_register_hz(_cs_msr, NSEC_PER_SEC/100);
-
+ /* Register Hyper-V specific clocksource */
+ hv_init_clocksource();
return;
remove_cpuhp_state:
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index cc60e61..f4fa8a9 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -105,6 +105,17 @@ static inline
[PATCH v5 1/2] clocksource/drivers: Make Hyper-V clocksource ISA agnostic
Hyper-V clock/timer code and data structures are currently mixed
in with other code in the ISA independent drivers/hv directory as
well as the ISA dependent Hyper-V code under arch/x86. Consolidate
this code and data structures into a Hyper-V clocksource driver to
better follow the Linux model. In doing so, separate out the ISA
dependent portions so the new clocksource driver works for x86 and
for the in-process Hyper-V on ARM64 code.
To start, move the existing clockevents code to create the
new clocksource driver. Update the VMbus driver to call
initialization and cleanup routines since the Hyper-V
synthetic timers are not independently enumerated in ACPI.
No behavior is changed and no new functionality is added.
Suggested-by: Marc Zyngier
Reviewed-by: Vitaly Kuznetsov
Signed-off-by: Michael Kelley
---
MAINTAINERS| 2 +
arch/x86/include/asm/hyperv-tlfs.h | 6 ++
arch/x86/kernel/cpu/mshyperv.c | 4 +-
drivers/clocksource/Makefile | 1 +
drivers/clocksource/hyperv_timer.c | 200 +
drivers/hv/Kconfig | 3 +
drivers/hv/hv.c| 156 +
drivers/hv/hyperv_vmbus.h | 3 -
drivers/hv/vmbus_drv.c | 42
include/clocksource/hyperv_timer.h | 27 +
10 files changed, 268 insertions(+), 176 deletions(-)
create mode 100644 drivers/clocksource/hyperv_timer.c
create mode 100644 include/clocksource/hyperv_timer.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a281297..bfde42a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7313,6 +7313,7 @@ F:arch/x86/include/asm/trace/hyperv.h
F: arch/x86/include/asm/hyperv-tlfs.h
F: arch/x86/kernel/cpu/mshyperv.c
F: arch/x86/hyperv
+F: drivers/clocksource/hyperv_timer.c
F: drivers/hid/hid-hyperv.c
F: drivers/hv/
F: drivers/input/serio/hyperv-keyboard.c
@@ -7323,6 +7324,7 @@ F:drivers/uio/uio_hv_generic.c
F: drivers/video/fbdev/hyperv_fb.c
F: drivers/iommu/hyperv_iommu.c
F: net/vmw_vsock/hyperv_transport.c
+F: include/clocksource/hyperv_timer.h
F: include/linux/hyperv.h
F: include/uapi/linux/hyperv.h
F: tools/hv/
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index cdf44aa..af78cd7 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -401,6 +401,12 @@ enum HV_GENERIC_SET_FORMAT {
#define HV_STATUS_INVALID_CONNECTION_ID18
#define HV_STATUS_INSUFFICIENT_BUFFERS 19
+/*
+ * The Hyper-V TimeRefCount register and the TSC
+ * page provide a guest VM clock with 100ns tick rate
+ */
+#define HV_CLOCK_HZ (NSEC_PER_SEC/100)
+
typedef struct _HV_REFERENCE_TSC_PAGE {
__u32 tsc_sequence;
__u32 res1;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 7df29f0..1e5f7a0 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -80,6 +81,7 @@ __visible void __irq_entry hv_stimer0_vector_handler(struct
pt_regs *regs)
inc_irq_stat(hyperv_stimer0_count);
if (hv_stimer0_handler)
hv_stimer0_handler();
+ add_interrupt_randomness(HYPERV_STIMER0_VECTOR, 0);
ack_APIC_irq();
exiting_irq();
@@ -89,7 +91,7 @@ __visible void __irq_entry hv_stimer0_vector_handler(struct
pt_regs *regs)
int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void))
{
*vector = HYPERV_STIMER0_VECTOR;
- *irq = 0; /* Unused on x86/x64 */
+ *irq = -1; /* Unused on x86/x64 */
hv_stimer0_handler = handler;
return 0;
}
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 236858f..2b65c5f 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_ATCPIT100_TIMER) += timer-atcpit100.o
obj-$(CONFIG_RISCV_TIMER) += timer-riscv.o
obj-$(CONFIG_CSKY_MP_TIMER)+= timer-mp-csky.o
obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
+obj-$(CONFIG_HYPERV_TIMER) += hyperv_timer.o
diff --git a/drivers/clocksource/hyperv_timer.c
b/drivers/clocksource/hyperv_timer.c
new file mode 100644
index 000..68a28af
--- /dev/null
+++ b/drivers/clocksource/hyperv_timer.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Clocksource driver for the synthetic counter and timers
+ * provided by the Hyper-V hypervisor to guest VMs, as described
+ * in the Hyper-V Top Level Functional Spec (TLFS). This driver
+ * is instruction set architecture independent.
+ *
+ * Copyright (C) 2019, Microsoft, Inc.
+ *
+ * Author: Michael Kelley
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct clock_event_device __percpu *hv_clock_event;
+
+/*
+ * If
linux-next: build failure after merge of the rdma tree
Hi all, After merging the rdma tree, today's linux-next build (x86_64 allmodconfig) failed like this: WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_ah.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_alloc.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_cmd.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_cq.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_db.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_hem.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_mr.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_pd.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_qp.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_restrack.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in drivers/infiniband/hw/hns/hns_roce_srq.o see include/linux/module.h for more information ERROR: "hns_roce_bitmap_cleanup" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_bitmap_init" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_free_cmd_mailbox" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_alloc_cmd_mailbox" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_table_get" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_bitmap_alloc" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_table_find" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_ib_umem_write_mtt" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_mtt_cleanup" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_buf_write_mtt" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_buf_free" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_buf_alloc" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_mtt_init" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_bitmap_free" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_table_put" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_cmd_mbox" [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined! ERROR: "hns_roce_bitmap_cleanup" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_bitmap_init" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_buf_free" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_free_db" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_alloc_db" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_bitmap_free_range" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_bitmap_alloc_range" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_db_unmap_user" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_mtr_cleanup" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_get_kmem_bufs" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_buf_alloc" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_db_map_user" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_free_buf_list" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_table_get" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_mtr_attach" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_mtr_init" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_hem_list_calc_root_ba" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_get_umem_bufs" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_alloc_buf_list" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_table_put" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_init_buf_region" [drivers/infiniband/hw/hns/hns_roce_qp.ko] undefined! ERROR: "hns_roce_bitmap_free" [drivers/infiniband/hw/hns/hns_roce_pd.ko] undefined! ERROR: "hns_roce_bitmap_alloc" [drivers/infiniband/hw/hns/hns_roce_pd.ko] undefined! ERROR: "hns_roce_bitmap_cleanup"
Re: [PATCH] tools/memory-model: Update the informal documentation
On Sat, Jun 29, 2019 at 11:10:44PM +0200, Andrea Parri wrote: > The formal memory consistency model has added support for plain accesses > (and data races). While updating the informal documentation to describe > this addition to the model is highly desirable and important future work, > update the informal documentation to at least acknowledge such addition. > > Signed-off-by: Andrea Parri > Cc: Alan Stern > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Nicholas Piggin > Cc: David Howells > Cc: Jade Alglave > Cc: Luc Maranget > Cc: "Paul E. McKenney" > Cc: Akira Yokosawa > Cc: Daniel Lustig Queued for review, thank you, Andrea! Thanx, Paul > --- > tools/memory-model/Documentation/explanation.txt | 47 > +++- > tools/memory-model/README| 18 - > 2 files changed, 30 insertions(+), 35 deletions(-) > > diff --git a/tools/memory-model/Documentation/explanation.txt > b/tools/memory-model/Documentation/explanation.txt > index 68caa9a976d0c..b42f7cd718242 100644 > --- a/tools/memory-model/Documentation/explanation.txt > +++ b/tools/memory-model/Documentation/explanation.txt > @@ -42,7 +42,8 @@ linux-kernel.bell and linux-kernel.cat files that make up > the formal > version of the model; they are extremely terse and their meanings are > far from clear. > > -This document describes the ideas underlying the LKMM. It is meant > +This document describes the ideas underlying the LKMM, but excluding > +the modeling of bare C (or plain) shared memory accesses. It is meant > for people who want to understand how the model was designed. It does > not go into the details of the code in the .bell and .cat files; > rather, it explains in English what the code expresses symbolically. > @@ -354,31 +355,25 @@ be extremely complex. > Optimizing compilers have great freedom in the way they translate > source code to object code. They are allowed to apply transformations > that add memory accesses, eliminate accesses, combine them, split them > -into pieces, or move them around. Faced with all these possibilities, > -the LKMM basically gives up. It insists that the code it analyzes > -must contain no ordinary accesses to shared memory; all accesses must > -be performed using READ_ONCE(), WRITE_ONCE(), or one of the other > -atomic or synchronization primitives. These primitives prevent a > -large number of compiler optimizations. In particular, it is > -guaranteed that the compiler will not remove such accesses from the > -generated code (unless it can prove the accesses will never be > -executed), it will not change the order in which they occur in the > -code (within limits imposed by the C standard), and it will not > -introduce extraneous accesses. > - > -This explains why the MP and SB examples above used READ_ONCE() and > -WRITE_ONCE() rather than ordinary memory accesses. Thanks to this > -usage, we can be certain that in the MP example, P0's write event to > -buf really is po-before its write event to flag, and similarly for the > -other shared memory accesses in the examples. > - > -Private variables are not subject to this restriction. Since they are > -not shared between CPUs, they can be accessed normally without > -READ_ONCE() or WRITE_ONCE(), and there will be no ill effects. In > -fact, they need not even be stored in normal memory at all -- in > -principle a private variable could be stored in a CPU register (hence > -the convention that these variables have names starting with the > -letter 'r'). > +into pieces, or move them around. The use of READ_ONCE(), WRITE_ONCE(), > +or one of the other atomic or synchronization primitives prevents a > +large number of compiler optimizations. In particular, it is guaranteed > +that the compiler will not remove such accesses from the generated code > +(unless it can prove the accesses will never be executed), it will not > +change the order in which they occur in the code (within limits imposed > +by the C standard), and it will not introduce extraneous accesses. > + > +The MP and SB examples above used READ_ONCE() and WRITE_ONCE() rather > +than ordinary memory accesses. Thanks to this usage, we can be certain > +that in the MP example, the compiler won't reorder P0's write event to > +buf and P0's write event to flag, and similarly for the other shared > +memory accesses in the examples. > + > +Since private variables are not shared between CPUs, they can be > +accessed normally without READ_ONCE() or WRITE_ONCE(). In fact, they > +need not even be stored in normal memory at all -- in principle a > +private variable could be stored in a CPU register (hence the convention > +that these variables have names starting with the letter 'r'). > > > A WARNING > diff --git a/tools/memory-model/README b/tools/memory-model/README > index 2b87f3971548c..fc07b52f20286 100644 > --- a/tools/memory-model/README > +++
[RFC 1/3] rcu: Expedite the rcu quiescent state reporting if help needed
The t->rcu_read_unlock_special union's need_qs bit can be set by the scheduler tick (in rcu_flavor_sched_clock_irq) to indicate that help is needed from the rcu_read_unlock path. When this help arrives however, we can do better to speed up the quiescent state reporting which if rcu_read_unlock_special::need_qs is set might be quite urgent. Make use of this information in deciding when to do heavy-weight softirq raising where possible. Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/tree_plugin.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index c588ef98efd3..bff6410fac06 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -622,7 +622,8 @@ static void rcu_read_unlock_special(struct task_struct *t) t->rcu_read_unlock_special.b.exp_hint = false; exp = (t->rcu_blocked_node && t->rcu_blocked_node->exp_tasks) || (rdp->grpmask & rnp->expmask) || - tick_nohz_full_cpu(rdp->cpu); + tick_nohz_full_cpu(rdp->cpu) || + t->rcu_read_unlock_special.b.need_qs; // Need to defer quiescent state until everything is enabled. if (irqs_were_disabled && use_softirq && (in_interrupt() || -- 2.22.0.410.gd8fdbe21b5-goog
[RFC 2/3] rcu: Simplify rcu_note_context_switch exit from critical section
The rcu_preempt_note_context_switch() tries to handle cases where
__rcu_read_unlock() got preempted and then the context switch path does
the reporting of the quiscent state along with clearing any bits in the
rcu_read_unlock_special union.
This can be handled by just calling rcu_deferred_qs() which was added
during the RCU consolidation work and already does these checks.
Tested RCU config TREE03 for an hour which succeeds.
Cc: r...@vger.kernel.org
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree_plugin.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index bff6410fac06..ebb4d46a6267 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -313,15 +313,6 @@ void rcu_note_context_switch(bool preempt)
? rnp->gp_seq
: rcu_seq_snap(>gp_seq));
rcu_preempt_ctxt_queue(rnp, rdp);
- } else if (t->rcu_read_lock_nesting < 0 &&
- t->rcu_read_unlock_special.s) {
-
- /*
-* Complete exit from RCU read-side critical section on
-* behalf of preempted instance of __rcu_read_unlock().
-*/
- rcu_read_unlock_special(t);
- rcu_preempt_deferred_qs(t);
} else {
rcu_preempt_deferred_qs(t);
}
--
2.22.0.410.gd8fdbe21b5-goog
[RFC 3/3] Revert "rcutorture: Tweak kvm options"
This reverts commit a6fda6dab93c2c06ef4b8cb4b9258df6674d2438 which
causes kvm.sh to not run on my machines. The qemu-system-x86_64 command
runs but does nothing.
Signed-off-by: Joel Fernandes (Google)
---
I am Ok if we want to drop this patch but it is in my tree because
without it I can't run the tests.
tools/testing/selftests/rcutorture/bin/functions.sh | 13 +
.../selftests/rcutorture/configs/rcu/CFcommon | 3 ---
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh
b/tools/testing/selftests/rcutorture/bin/functions.sh
index c3a49fb4d6f6..6bcb8b5b2ff2 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -172,7 +172,7 @@ identify_qemu_append () {
local console=ttyS0
case "$1" in
qemu-system-x86_64|qemu-system-i386)
- echo selinux=0 initcall_debug debug
+ echo noapic selinux=0 initcall_debug debug
;;
qemu-system-aarch64)
console=ttyAMA0
@@ -191,19 +191,8 @@ identify_qemu_append () {
# Output arguments for qemu arguments based on the TORTURE_QEMU_MAC
# and TORTURE_QEMU_INTERACTIVE environment variables.
identify_qemu_args () {
- local KVM_CPU=""
- case "$1" in
- qemu-system-x86_64)
- KVM_CPU=kvm64
- ;;
- qemu-system-i386)
- KVM_CPU=kvm32
- ;;
- esac
case "$1" in
qemu-system-x86_64|qemu-system-i386)
- echo -machine q35,accel=kvm
- echo -cpu ${KVM_CPU}
;;
qemu-system-aarch64)
echo -machine virt,gic-version=host -cpu host
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/CFcommon
b/tools/testing/selftests/rcutorture/configs/rcu/CFcommon
index e19a444a0684..d2d2a86139db 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/CFcommon
+++ b/tools/testing/selftests/rcutorture/configs/rcu/CFcommon
@@ -1,5 +1,2 @@
CONFIG_RCU_TORTURE_TEST=y
CONFIG_PRINTK_TIME=y
-CONFIG_HYPERVISOR_GUEST=y
-CONFIG_PARAVIRT=y
-CONFIG_KVM_GUEST=y
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH] drm: bridge: DRM_SIL_SII8620 should depend on, not select INPUT
From: Randy Dunlap
A single driver should not enable (select) an entire subsystem,
such as INPUT, so change the 'select' to "depends on".
Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not have a dependency of
RC_CORE")
Signed-off-by: Randy Dunlap
Cc: Inki Dae
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: dri-de...@lists.freedesktop.org
---
Linus has written this a couple of times in the last 15 years or so,
but my search fu cannot find it. And there are a few drivers in the
kernel tree that do this, but we shouldn't be adding more that do so.
drivers/gpu/drm/bridge/Kconfig |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- lnx-52-rc7.orig/drivers/gpu/drm/bridge/Kconfig
+++ lnx-52-rc7/drivers/gpu/drm/bridge/Kconfig
@@ -83,10 +83,9 @@ config DRM_PARADE_PS8622
config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
- depends on OF
+ depends on OF && INPUT
select DRM_KMS_HELPER
imply EXTCON
- select INPUT
select RC_CORE
help
Silicon Image SII8620 HDMI/MHL bridge chip driver.
linux-next: build failure after merge of the pm tree
Hi all, After merging the pm tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/cpufreq/intel_pstate.c:11: drivers/cpufreq/intel_pstate.c: In function 'intel_pstate_update_max_freq': drivers/cpufreq/intel_pstate.c:912:31: error: 'struct cpufreq_policy' has no member named 'user_policy'; did you mean 'last_policy'? new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ include/linux/kernel.h:819:22: note: in definition of macro '__typecheck' (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ include/linux/kernel.h:843:24: note: in expansion of macro '__safe_cmp' __builtin_choose_expr(__safe_cmp(x, y), \ ^~ include/linux/kernel.h:852:19: note: in expansion of macro '__careful_cmp' #define min(x, y) __careful_cmp(x, y, <) ^ drivers/cpufreq/intel_pstate.c:912:19: note: in expansion of macro 'min' new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ drivers/cpufreq/intel_pstate.c:912:31: error: 'struct cpufreq_policy' has no member named 'user_policy'; did you mean 'last_policy'? new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ include/linux/kernel.h:827:48: note: in definition of macro '__is_constexpr' (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8))) ^ include/linux/kernel.h:833:25: note: in expansion of macro '__no_side_effects' (__typecheck(x, y) && __no_side_effects(x, y)) ^ include/linux/kernel.h:843:24: note: in expansion of macro '__safe_cmp' __builtin_choose_expr(__safe_cmp(x, y), \ ^~ include/linux/kernel.h:852:19: note: in expansion of macro '__careful_cmp' #define min(x, y) __careful_cmp(x, y, <) ^ drivers/cpufreq/intel_pstate.c:912:19: note: in expansion of macro 'min' new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ drivers/cpufreq/intel_pstate.c:912:31: error: 'struct cpufreq_policy' has no member named 'user_policy'; did you mean 'last_policy'? new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ include/linux/kernel.h:835:27: note: in definition of macro '__cmp' #define __cmp(x, y, op) ((x) op (y) ? (x) : (y)) ^ include/linux/kernel.h:852:19: note: in expansion of macro '__careful_cmp' #define min(x, y) __careful_cmp(x, y, <) ^ drivers/cpufreq/intel_pstate.c:912:19: note: in expansion of macro 'min' new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ drivers/cpufreq/intel_pstate.c:912:31: error: 'struct cpufreq_policy' has no member named 'user_policy'; did you mean 'last_policy'? new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ include/linux/kernel.h:835:40: note: in definition of macro '__cmp' #define __cmp(x, y, op) ((x) op (y) ? (x) : (y)) ^ include/linux/kernel.h:852:19: note: in expansion of macro '__careful_cmp' #define min(x, y) __careful_cmp(x, y, <) ^ drivers/cpufreq/intel_pstate.c:912:19: note: in expansion of macro 'min' new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ drivers/cpufreq/intel_pstate.c:912:31: error: 'struct cpufreq_policy' has no member named 'user_policy'; did you mean 'last_policy'? new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ include/linux/kernel.h:838:10: note: in definition of macro '__cmp_once' typeof(x) unique_x = (x); \ ^ include/linux/kernel.h:852:19: note: in expansion of macro '__careful_cmp' #define min(x, y) __careful_cmp(x, y, <) ^ drivers/cpufreq/intel_pstate.c:912:19: note: in expansion of macro 'min' new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ drivers/cpufreq/intel_pstate.c:912:31: error: 'struct cpufreq_policy' has no member named 'user_policy'; did you mean 'last_policy'? new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq); ^~~ include/linux/kernel.h:838:25: note: in definition of macro '__cmp_once' typeof(x) unique_x = (x); \ ^ include/linux/kernel.h:852:19: note: in expansion of macro '__careful_cmp' #define min(x, y) __careful_cmp(x, y, <) ^ drivers/cpufreq/intel_pstate.c:912:19: note: in expansion of macro 'min' new_policy.max =
linux-next: manual merge of the pm tree with the pci tree
Hi all,
Today's linux-next merge of the pm tree got a conflict in:
Documentation/power/pm_qos_interface.rst
between commits:
151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")
562fe2ef1a21 ("PM / QOS: Pass request type to dev_pm_qos_read_value()")
from the pci tree and commit:
0c4899702720 ("PM / QOS: Pass request type to
dev_pm_qos_{add|remove}_notifier()")
from the pm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/power/pm_qos_interface.rst
index 945fc6d760c9,cfcb1df39799..
--- a/Documentation/power/pm_qos_interface.rst
+++ b/Documentation/power/pm_qos_interface.rst
@@@ -113,76 -107,72 +113,78 @@@ the aggregated value does not require a
From kernel mode the use of this interface is the following:
int dev_pm_qos_add_request(device, handle, type, value):
-Will insert an element into the list for that identified device with the
-target value. Upon change to this list the new target is recomputed and any
-registered notifiers are called only if the target value is now different.
-Clients of dev_pm_qos need to save the handle for future use in other
-dev_pm_qos API functions.
+ Will insert an element into the list for that identified device with the
+ target value. Upon change to this list the new target is recomputed and any
+ registered notifiers are called only if the target value is now different.
+ Clients of dev_pm_qos need to save the handle for future use in other
+ dev_pm_qos API functions.
int dev_pm_qos_update_request(handle, new_value):
-Will update the list element pointed to by the handle with the new target
value
-and recompute the new aggregated target, calling the notification trees if the
-target is changed.
+ Will update the list element pointed to by the handle with the new target
+ value and recompute the new aggregated target, calling the notification
+ trees if the target is changed.
int dev_pm_qos_remove_request(handle):
-Will remove the element. After removal it will update the aggregate target
and
-call the notification trees if the target was changed as a result of removing
-the request.
+ Will remove the element. After removal it will update the aggregate target
+ and call the notification trees if the target was changed as a result of
+ removing the request.
- s32 dev_pm_qos_read_value(device):
+ s32 dev_pm_qos_read_value(device, type):
-Returns the aggregated value for a given device's constraints list.
+ Returns the aggregated value for a given device's constraints list.
enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
-Check PM QoS flags of the given device against the given mask of flags.
-The meaning of the return values is as follows:
- PM_QOS_FLAGS_ALL: All flags from the mask are set
- PM_QOS_FLAGS_SOME: Some flags from the mask are set
- PM_QOS_FLAGS_NONE: No flags from the mask are set
- PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
- initialized or the list of requests is empty.
+ Check PM QoS flags of the given device against the given mask of flags.
+ The meaning of the return values is as follows:
+
+ PM_QOS_FLAGS_ALL:
+ All flags from the mask are set
+ PM_QOS_FLAGS_SOME:
+ Some flags from the mask are set
+ PM_QOS_FLAGS_NONE:
+ No flags from the mask are set
+ PM_QOS_FLAGS_UNDEFINED:
+ The device's PM QoS structure has not been initialized
+ or the list of requests is empty.
int dev_pm_qos_add_ancestor_request(dev, handle, type, value)
-Add a PM QoS request for the first direct ancestor of the given device whose
-power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
-or whose power.set_latency_tolerance callback pointer is not NULL (for
-DEV_PM_QOS_LATENCY_TOLERANCE requests).
+ Add a PM QoS request for the first direct ancestor of the given device whose
+ power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
+ or whose power.set_latency_tolerance callback pointer is not NULL (for
+ DEV_PM_QOS_LATENCY_TOLERANCE requests).
int dev_pm_qos_expose_latency_limit(device, value)
-Add a request to the device's PM QoS list of resume latency constraints and
-create a sysfs attribute pm_qos_resume_latency_us under the device's power
-directory allowing user space to manipulate that request.
+ Add a request to the device's PM QoS list of resume latency constraints and
+ create a sysfs attribute pm_qos_resume_latency_us under the device's
[PATCH 4/4] platform: x86: Use dev_get_drvdata()
Using dev_get_drvdata directly.
Signed-off-by: Fuqian Huang
---
drivers/platform/x86/asus-wmi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 9b18a184e0aa..49049b02a015 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1353,8 +1353,7 @@ static umode_t asus_hwmon_sysfs_is_visible(struct kobject
*kobj,
struct attribute *attr, int idx)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct asus_wmi *asus = platform_get_drvdata(pdev);
+ struct asus_wmi *asus = dev_get_drvdata(dev->parent);
int dev_id = -1;
int fan_attr = -1;
u32 value = ASUS_WMI_UNSUPPORTED_METHOD;
--
2.11.0
[PATCH 1/2] drm/vkms: Add enable/disable functions per connector
Currently, virtual and writeback connectors have the code responsible
for initialization and cleanup spread around different places in vkms.
This patch creates an enable and disable function per connector which
allows vkms to hotplug connectors easily.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_drv.h | 5 ++
drivers/gpu/drm/vkms/vkms_output.c| 84 +--
drivers/gpu/drm/vkms/vkms_writeback.c | 31 --
3 files changed, 83 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 9ff2cd4ebf81..a1ca5c658355 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -152,7 +152,12 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
char *source_name,
/* Composer Support */
void vkms_composer_worker(struct work_struct *work);
+/* Virtual connector */
+int enable_virtual_connector(struct vkms_device *vkmsdev);
+void disable_virtual_connector(struct vkms_device *vkmsdev);
+
/* Writeback */
int enable_writeback_connector(struct vkms_device *vkmsdev);
+void disable_writeback_connector(struct vkms_device *connector);
#endif /* _VKMS_DRV_H_ */
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index aea1d4410864..26ecab52e82e 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -6,6 +6,7 @@
static void vkms_connector_destroy(struct drm_connector *connector)
{
+ drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -35,37 +36,19 @@ static const struct drm_connector_helper_funcs
vkms_conn_helper_funcs = {
.get_modes= vkms_conn_get_modes,
};
-int vkms_output_init(struct vkms_device *vkmsdev, int index)
+int enable_virtual_connector(struct vkms_device *vkmsdev)
{
struct vkms_output *output = >output;
- struct drm_device *dev = >drm;
struct drm_connector *connector = >connector;
struct drm_encoder *encoder = >encoder;
- struct drm_crtc *crtc = >crtc;
- struct drm_plane *primary, *cursor = NULL;
+ struct drm_device *dev = >drm;
int ret;
- primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
- if (IS_ERR(primary))
- return PTR_ERR(primary);
-
- if (enable_cursor) {
- cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
- if (IS_ERR(cursor)) {
- ret = PTR_ERR(cursor);
- goto err_cursor;
- }
- }
-
- ret = vkms_crtc_init(dev, crtc, primary, cursor);
- if (ret)
- goto err_crtc;
-
ret = drm_connector_init(dev, connector, _connector_funcs,
DRM_MODE_CONNECTOR_VIRTUAL);
if (ret) {
DRM_ERROR("Failed to init connector\n");
- goto err_connector;
+ return ret;
}
drm_connector_helper_add(connector, _conn_helper_funcs);
@@ -84,17 +67,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
goto err_attach;
}
- if (enable_writeback) {
- ret = enable_writeback_connector(vkmsdev);
- if (!ret) {
- output->composer_enabled = true;
- DRM_INFO("Writeback connector enabled");
- } else {
- DRM_ERROR("Failed to init writeback connector\n");
- }
- }
-
- drm_mode_config_reset(dev);
+ drm_connector_register(connector);
return 0;
@@ -104,6 +77,53 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
err_encoder:
drm_connector_cleanup(connector);
+ return ret;
+}
+
+void disable_virtual_connector(struct vkms_device *vkmsdev)
+{
+ struct vkms_output *output = >output;
+
+ drm_connector_unregister(>connector);
+ drm_connector_cleanup(>connector);
+ drm_encoder_cleanup(>encoder);
+}
+
+int vkms_output_init(struct vkms_device *vkmsdev, int index)
+{
+ struct vkms_output *output = >output;
+ struct drm_device *dev = >drm;
+ struct drm_crtc *crtc = >crtc;
+ struct drm_plane *primary, *cursor = NULL;
+ int ret;
+
+ primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
+ if (IS_ERR(primary))
+ return PTR_ERR(primary);
+
+ if (enable_cursor) {
+ cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
+ if (IS_ERR(cursor)) {
+ ret = PTR_ERR(cursor);
+ goto err_cursor;
+ }
+ }
+
+ ret = vkms_crtc_init(dev, crtc, primary, cursor);
+ if (ret)
+ goto err_crtc;
+
+ ret = enable_virtual_connector(vkmsdev);
+ if (ret)
+ goto err_connector;
+
+ if (enable_writeback)
+
[PATCH 2/2] drm/vkms: Introduce configfs for enabling/disabling connectors
This patch introduces an implementation of vkms subsystems through
configfs; we want to be able to reconfigure vkms instance without having
to reload the module. This commit adds the primary support for configfs
by allowing vkms to expose the ability to enable/disable its connectors.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/Makefile| 3 +-
drivers/gpu/drm/vkms/vkms_configfs.c | 229 +++
drivers/gpu/drm/vkms/vkms_drv.c | 6 +
drivers/gpu/drm/vkms/vkms_drv.h | 12 ++
4 files changed, 249 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 333d3cead0e3..f90c016cd9fe 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -6,6 +6,7 @@ vkms-y := \
vkms_crtc.o \
vkms_gem.o \
vkms_composer.o \
- vkms_writeback.o
+ vkms_writeback.o \
+ vkms_configfs.o
obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c
b/drivers/gpu/drm/vkms/vkms_configfs.c
new file mode 100644
index ..5d1a30517cca
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_configfs.c
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "vkms_drv.h"
+
+static struct config_group *connector_group;
+static struct vkms_device *vkms_device;
+
+static char *available_connectors[] = {
+ "Virtual",
+ "Writeback",
+};
+
+struct connectors_fs {
+ struct config_item item;
+ bool enable;
+};
+
+static int enable_connector(const char *name)
+{
+ int ret = 0;
+
+ if (!strcmp(name, "Writeback"))
+ ret = enable_writeback_connector(vkms_device);
+ else if (!strcmp(name, "Virtual"))
+ ret = enable_virtual_connector(vkms_device);
+
+ if (ret)
+ return ret;
+
+ drm_mode_config_reset(_device->drm);
+ return 0;
+}
+
+static void disable_connector(const char *name)
+{
+ if (!strcmp(name, "Writeback"))
+ disable_writeback_connector(vkms_device);
+ else if (!strcmp(name, "Virtual"))
+ disable_virtual_connector(vkms_device);
+}
+
+static inline struct connectors_fs *to_conn_item(struct config_item *item)
+{
+ return item ? container_of(item, struct connectors_fs, item) : NULL;
+}
+
+static ssize_t conn_fs_enable_show(struct config_item *item, char *page)
+{
+ struct connectors_fs *conn_item = to_conn_item(item);
+
+ return sprintf(page, "%d\n", conn_item->enable);
+}
+
+static ssize_t conn_fs_enable_store(struct config_item *item,
+ const char *page, size_t count)
+{
+ struct connectors_fs *conn_item = to_conn_item(item);
+ char *p = (char *)page;
+ unsigned int enable;
+ int ret;
+
+ ret = kstrtouint(p, 10, );
+ if (ret)
+ return -EINVAL;
+
+ if (enable > 1)
+ return -EINVAL;
+
+ if (enable == conn_item->enable)
+ return count;
+
+ if (enable) {
+ ret = enable_connector(item->ci_name);
+ if (ret)
+ return ret;
+ } else {
+ disable_connector(item->ci_name);
+ }
+
+ conn_item->enable = enable ? true : false;
+ return count;
+}
+
+CONFIGFS_ATTR(conn_fs_, enable);
+
+static struct configfs_attribute *connectors_fs_attrs[] = {
+ _fs_attr_enable,
+ NULL,
+};
+
+static void connectors_fs_release(struct config_item *item)
+{
+ kfree(to_conn_item(item));
+}
+
+static struct configfs_item_operations connectors_fs_ops = {
+ .release = connectors_fs_release,
+};
+
+static const struct config_item_type connectors_fs_type = {
+ .ct_item_ops= _fs_ops,
+ .ct_attrs = connectors_fs_attrs,
+ .ct_owner = THIS_MODULE,
+};
+
+static struct config_item *make_connector_item(struct config_group *group,
+ const char *name)
+{
+ struct connectors_fs *conn_item;
+ int i, ret, total_conn = ARRAY_SIZE(available_connectors);
+
+ for (i = 0; i < total_conn; i++)
+ if (!strcmp(name, available_connectors[i]))
+ break;
+
+ if (i == total_conn)
+ return ERR_PTR(-EINVAL);
+
+ ret = enable_connector(name);
+ if (ret)
+ return ERR_PTR(ret);
+
+ conn_item = kzalloc(sizeof(*conn_item), GFP_KERNEL);
+ if (!conn_item)
+ return ERR_PTR(-ENOMEM);
+
+ config_item_init_type_name(_item->item, name,
+ _fs_type);
+
+ conn_item->enable = true;
+
+ return _item->item;
+}
+
+static void drop_connector_item(struct config_group *group,
+ struct config_item *item)
+{
+ char *name = item->ci_name;
+
+ disable_connector(name);
+
+
[PATCH 2/4] input: keyboard/mouse/touchscreen/misc: Use dev_get_drvdata()
Using dev_get_drvdata directly.
Signed-off-by: Fuqian Huang
---
drivers/input/keyboard/ep93xx_keypad.c | 10 --
drivers/input/keyboard/gpio_keys.c | 3 +--
drivers/input/keyboard/imx_keypad.c | 10 --
drivers/input/keyboard/lpc32xx-keys.c| 6 ++
drivers/input/keyboard/matrix_keypad.c | 10 --
drivers/input/keyboard/omap4-keypad.c| 10 --
drivers/input/keyboard/pmic8xxx-keypad.c | 6 ++
drivers/input/keyboard/pxa27x_keypad.c | 10 --
drivers/input/keyboard/samsung-keypad.c | 12
drivers/input/keyboard/spear-keyboard.c | 10 --
drivers/input/keyboard/st-keyscan.c | 6 ++
drivers/input/keyboard/tegra-kbc.c | 10 --
drivers/input/misc/gpio-vibra.c | 6 ++
drivers/input/misc/max77693-haptic.c | 6 ++
drivers/input/misc/max8925_onkey.c | 10 --
drivers/input/misc/max8997_haptic.c | 3 +--
drivers/input/misc/msm-vibrator.c| 6 ++
drivers/input/misc/palmas-pwrbutton.c| 6 ++
drivers/input/misc/regulator-haptic.c| 6 ++
drivers/input/misc/stpmic1_onkey.c | 6 ++
drivers/input/misc/twl4030-vibra.c | 3 +--
drivers/input/misc/twl6040-vibra.c | 3 +--
drivers/input/mouse/navpoint.c | 6 ++
drivers/input/touchscreen/imx6ul_tsc.c | 6 ++
24 files changed, 62 insertions(+), 108 deletions(-)
diff --git a/drivers/input/keyboard/ep93xx_keypad.c
b/drivers/input/keyboard/ep93xx_keypad.c
index 7c70492d9d6b..bcc8a17f9a01 100644
--- a/drivers/input/keyboard/ep93xx_keypad.c
+++ b/drivers/input/keyboard/ep93xx_keypad.c
@@ -178,8 +178,7 @@ static void ep93xx_keypad_close(struct input_dev *pdev)
#ifdef CONFIG_PM_SLEEP
static int ep93xx_keypad_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
struct input_dev *input_dev = keypad->input_dev;
mutex_lock(_dev->mutex);
@@ -191,7 +190,7 @@ static int ep93xx_keypad_suspend(struct device *dev)
mutex_unlock(_dev->mutex);
- if (device_may_wakeup(>dev))
+ if (device_may_wakeup(dev))
enable_irq_wake(keypad->irq);
return 0;
@@ -199,11 +198,10 @@ static int ep93xx_keypad_suspend(struct device *dev)
static int ep93xx_keypad_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
struct input_dev *input_dev = keypad->input_dev;
- if (device_may_wakeup(>dev))
+ if (device_may_wakeup(dev))
disable_irq_wake(keypad->irq);
mutex_lock(_dev->mutex);
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index a23c23979a2e..83d66155ce74 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -290,8 +290,7 @@ static ssize_t gpio_keys_show_##name(struct device *dev,
\
struct device_attribute *attr, \
char *buf) \
{ \
- struct platform_device *pdev = to_platform_device(dev); \
- struct gpio_keys_drvdata *ddata = platform_get_drvdata(pdev); \
+ struct gpio_keys_drvdata *ddata = dev_get_drvdata(dev); \
\
return gpio_keys_attr_show_helper(ddata, buf, \
type, only_disabled); \
diff --git a/drivers/input/keyboard/imx_keypad.c
b/drivers/input/keyboard/imx_keypad.c
index ae9c51cc85f9..d820de0908db 100644
--- a/drivers/input/keyboard/imx_keypad.c
+++ b/drivers/input/keyboard/imx_keypad.c
@@ -528,8 +528,7 @@ static int imx_keypad_probe(struct platform_device *pdev)
static int __maybe_unused imx_kbd_noirq_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct imx_keypad *kbd = platform_get_drvdata(pdev);
+ struct imx_keypad *kbd = dev_get_drvdata(dev);
struct input_dev *input_dev = kbd->input_dev;
unsigned short reg_val = readw(kbd->mmio_base + KPSR);
@@ -541,7 +540,7 @@ static int __maybe_unused imx_kbd_noirq_suspend(struct
device *dev)
mutex_unlock(_dev->mutex);
- if (device_may_wakeup(>dev)) {
+ if (device_may_wakeup(dev)) {
if (reg_val & KBD_STAT_KPKD)
reg_val |= KBD_STAT_KRIE;
if (reg_val & KBD_STAT_KPKR)
@@ -556,12 +555,11 @@ static int __maybe_unused imx_kbd_noirq_suspend(struct
device *dev)
static int __maybe_unused
[PATCH 3/4] mailbox: Use dev_get_drvdata()
Using dev_get_drvdata directly.
Signed-off-by: Fuqian Huang
---
drivers/mailbox/bcm-flexrm-mailbox.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c
b/drivers/mailbox/bcm-flexrm-mailbox.c
index a64116586b4c..0cfdd53d04a1 100644
--- a/drivers/mailbox/bcm-flexrm-mailbox.c
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -1165,8 +1165,7 @@ static int flexrm_process_completions(struct flexrm_ring
*ring)
static int flexrm_debugfs_conf_show(struct seq_file *file, void *offset)
{
- struct platform_device *pdev = to_platform_device(file->private);
- struct flexrm_mbox *mbox = platform_get_drvdata(pdev);
+ struct flexrm_mbox *mbox = dev_get_drvdata(file->private);
/* Write config in file */
flexrm_write_config_in_seqfile(mbox, file);
@@ -1176,8 +1175,7 @@ static int flexrm_debugfs_conf_show(struct seq_file
*file, void *offset)
static int flexrm_debugfs_stats_show(struct seq_file *file, void *offset)
{
- struct platform_device *pdev = to_platform_device(file->private);
- struct flexrm_mbox *mbox = platform_get_drvdata(pdev);
+ struct flexrm_mbox *mbox = dev_get_drvdata(file->private);
/* Write stats in file */
flexrm_write_stats_in_seqfile(mbox, file);
--
2.11.0
[PATCH 0/2] drm/vkms: Introduce basic support for configfs
This patchset introduces the support for configfs in vkms by adding a primary structure for handling the vkms subsystem and exposing connectors as a use case. This series allows enabling/disabling virtual and writeback connectors on the fly. The first patch of this series reworks the initialization and cleanup code of each type of connector, with this change, the second patch adds the configfs support for vkms. It is important to highlight that this patchset depends on https://patchwork.freedesktop.org/series/61738/. After applying this series, the user can utilize these features with the following steps: 1. Load vkms without parameter modprobe vkms 2. Mount a configfs filesystem mount -t configfs none /mnt/ After that, the vkms subsystem will look like this: vkms/ |__connectors |__Virtual |__ enable The connectors directories have information related to connectors, and as can be seen, the virtual connector is enabled by default. Inside a connector directory (e.g., Virtual) has an attribute named ‘enable’ which is used to enable and disable the target connector. For example, the Virtual connector has the enable attribute set to 1. If the user wants to enable the writeback connector it is required to use the mkdir command, as follows: cd /mnt/vkms/connectors mkdir Writeback After the above command, the writeback connector will be enabled, and the user could see the following tree: vkms/ |__connectors |__Virtual | |__ enable |__Writeback |__ enable If the user wants to remove the writeback connector, it is required to use the command rmdir, for example rmdir Writeback Another way to enable and disable a connector it is by using the enable attribute, for example, we can disable the Virtual connector with: echo 0 > /mnt/vkms/connectors/Virtual/enable And enable it again with: echo 1 > /mnt/vkms/connectors/Virtual/enable It is important to highlight that configfs 'obey' the parameters used during the vkms load and does not allow users to remove a connector directory if it was load via module parameter. For example: modprobe vkms enable_writeback=1 vkms/ |__connectors |__Virtual | |__ enable |__Writeback |__ enable If the user tries to remove the Writeback connector with “rmdir Writeback”, the operation will be not permitted because the Writeback connector was loaded with the modules. However, the user may disable the writeback connector with: echo 0 > /mnt/vkms/connectors/Writeback/enable Rodrigo Siqueira (2): drm/vkms: Add enable/disable functions per connector drm/vkms: Introduce configfs for enabling/disabling connectors drivers/gpu/drm/vkms/Makefile | 3 +- drivers/gpu/drm/vkms/vkms_configfs.c | 229 ++ drivers/gpu/drm/vkms/vkms_drv.c | 6 + drivers/gpu/drm/vkms/vkms_drv.h | 17 ++ drivers/gpu/drm/vkms/vkms_output.c| 84 ++ drivers/gpu/drm/vkms/vkms_writeback.c | 31 +++- 6 files changed, 332 insertions(+), 38 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c -- 2.21.0 -- Rodrigo Siqueira https://siqueira.tech
[PATCH 1/4] gpu: Use dev_get_drvdata()
Using dev_get_drvdata directly.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c| 6 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
drivers/gpu/drm/msm/msm_drv.c | 3 +--
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++
7 files changed, 19 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index b3deb346a42b..fafd00d2574a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -403,16 +403,14 @@ static const struct of_device_id dt_match[] = {
#ifdef CONFIG_PM
static int adreno_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_gpu *gpu = platform_get_drvdata(pdev);
+ struct msm_gpu *gpu = dev_get_drvdata(dev);
return gpu->funcs->pm_resume(gpu);
}
static int adreno_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_gpu *gpu = platform_get_drvdata(pdev);
+ struct msm_gpu *gpu = dev_get_drvdata(dev);
return gpu->funcs->pm_suspend(gpu);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae885e5dd07d..6c6f8ca9380f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1025,16 +1025,15 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
static void dpu_unbind(struct device *dev, struct device *master, void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct dss_module_power *mp = _kms->mp;
msm_dss_put_clk(mp->clk_config, mp->num_clk);
- devm_kfree(>dev, mp->clk_config);
+ devm_kfree(dev, mp->clk_config);
mp->num_clk = 0;
if (dpu_kms->rpm_enabled)
- pm_runtime_disable(>dev);
+ pm_runtime_disable(dev);
}
static const struct component_ops dpu_ops = {
@@ -1056,8 +1055,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
static int __maybe_unused dpu_runtime_suspend(struct device *dev)
{
int rc = -1;
- struct platform_device *pdev = to_platform_device(dev);
- struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
@@ -1077,8 +1075,7 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
static int __maybe_unused dpu_runtime_resume(struct device *dev)
{
int rc = -1;
- struct platform_device *pdev = to_platform_device(dev);
- struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_encoder *encoder;
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 901009e1f219..25d1ebb32e73 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -1052,8 +1052,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+ struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
DBG("");
@@ -1062,8 +1061,7 @@ static __maybe_unused int mdp5_runtime_suspend(struct
device *dev)
static __maybe_unused int mdp5_runtime_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+ struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
DBG("");
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index dbf490176c2c..882f13725819 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -477,8 +477,7 @@ static void dsi_bus_clk_disable(struct msm_dsi_host
*msm_host)
int msm_dsi_runtime_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
+ struct msm_dsi *msm_dsi = dev_get_drvdata(dev);
struct mipi_dsi_host *host = msm_dsi->host;
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
@@ -492,8 +491,7 @@ int msm_dsi_runtime_suspend(struct device *dev)
compensation
Dear Friend, I'm sorry but happy to inform you about my success in getting those funds transferred under the cooperation of a new partner from Vietnam, though I tried my best to involve you in the business but God decided the whole situations. Presently I’m in Vietnam for investment projects with my own share of the total sum. Meanwhile, I didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us some how. Now contact my secretary in Burkina Faso her name is Ms. Jemilla Smith on her e-mail address below jemillasmit...@gmail.com ask her to send you the total of $1.1Milion which I kept for your compensation for all the past efforts and attempts to assist me in this matter. I appreciated your efforts at that time very much. So feel free and get in touched with my secretary Ms. Jemilla Smith and instruct her where to send the amount to you. Please do let me know immediately you receive it so that we can share joy after all the sufferness at that time. In the moment, I’m very busy here because of the investment projects which I and the new partner are having at hand, finally, remember that I had forwarded instruction to the secretary on your behalf to receive that money, so feel free to get in touch with Ms. Jemilla Smith she will send the amount to you without any delay OK. Extend my greetings to your family. My Best regards Yours brother Mr. Abu Salam Greetings from Vietnam
Re: [RFC PATCH 03/12] powerpc/prom_init: Add the ESM call to prom_init
On 29/06/2019 08:33, Thiago Jung Bauermann wrote:
>
> Hello Alexey,
>
> Thanks for reviewing this patch!
>
> Alexey Kardashevskiy writes:
>
>> On 21/05/2019 14:49, Thiago Jung Bauermann wrote:
>>> @@ -1707,6 +1723,43 @@ static void __init prom_close_stdin(void)
>>> }
>>> }
>>>
>>> +#ifdef CONFIG_PPC_SVM
>>> +static int prom_rtas_os_term_hcall(uint64_t args)
>>
>>
>> This is just an rtas hcall, nothing special about "os-term".
>
> Sorry, unfortunately I don't understand how we're treating os-term
> especially. Do you mean that we should inline this function directly
> into prom_rtas_os_term()?
I meant the function name - prom_rtas_os_term_hcall - should rather be
prom_rtas_hcall.
>
>>> +{
>>> + register uint64_t arg1 asm("r3") = 0xf000;
>>> + register uint64_t arg2 asm("r4") = args;
>>> +
>>> + asm volatile("sc 1\n" : "=r" (arg1) :
>>> + "r" (arg1),
>>> + "r" (arg2) :);
>>> + return arg1;
>>> +}
>>> +
>>> +static struct rtas_args __prombss os_term_args;
>>> +
>>> +static void __init prom_rtas_os_term(char *str)
>>> +{
>>> + phandle rtas_node;
>>> + __be32 val;
>>> + u32 token;
>>> +
>>> + prom_printf("%s: start...\n", __func__);
>>> + rtas_node = call_prom("finddevice", 1, 1, ADDR("/rtas"));
>>> + prom_printf("rtas_node: %x\n", rtas_node);
>>> + if (!PHANDLE_VALID(rtas_node))
>>> + return;
>>> +
>>> + val = 0;
>>> + prom_getprop(rtas_node, "ibm,os-term", , sizeof(val));
>>> + token = be32_to_cpu(val);
>>> + prom_printf("ibm,os-term: %x\n", token);
>>> + if (token == 0)
>>> + prom_panic("Could not get token for ibm,os-term\n");
>>> + os_term_args.token = cpu_to_be32(token);
>>> + prom_rtas_os_term_hcall((uint64_t)_term_args);
>>> +}
>>> +#endif /* CONFIG_PPC_SVM */
>>> +
>>> /*
>>> * Allocate room for and instantiate RTAS
>>> */
>
--
Alexey
Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace
On 2019.06.28 12:43:47 +, Zhang, Tina wrote: > Hi, > > How about GVT-g supports both vblank and page flip events. Then QEMU UI can > mask/unmask the events to decide which kind of event is expected. > For DRM UI, it can decide to mask vblank event and use page flip events. We > tried DRM UI with page flip events, the performance is great, even in the > case of front buffer rendering. For the UI like GTK, vblank event is better. > > Besides, with the irq mask/unmask mechanism, userspace can dynamically choose > between the UI timer and the events. > The idea is to deliver an event to tell userspace that "guest has display update, you need to refresh your UI". How driver implementation uses either vblank or page flip to determine that is driver specific, as same routine of vfio gfx interface will be used to refresh on guest display. If userspace doesn't set irq for vfio gfx display, it would just use own timer. > > > -Original Message- > > From: Zhang, Tina > > Sent: Friday, June 28, 2019 4:45 PM > > To: 'Gerd Hoffmann' ; Zhenyu Wang > > > > Cc: Tian, Kevin ; k...@vger.kernel.org; linux- > > ker...@vger.kernel.org; alex.william...@redhat.com; Lv, Zhiyuan > > ; Yuan, Hang ; intel-gvt- > > d...@lists.freedesktop.org; Wang, Zhi A > > Subject: RE: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to > > userspace > > > > > > > > > -Original Message- > > > From: intel-gvt-dev > > > [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On Behalf Of Gerd > > > Hoffmann > > > Sent: Friday, June 28, 2019 1:44 PM > > > To: Zhenyu Wang > > > Cc: Tian, Kevin ; k...@vger.kernel.org; linux- > > > ker...@vger.kernel.org; Zhang, Tina ; > > > alex.william...@redhat.com; Lv, Zhiyuan ; Yuan, > > > Hang ; intel-gvt-...@lists.freedesktop.org; Wang, > > > Zhi A > > > Subject: Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to > > > userspace > > > > > > On Fri, Jun 28, 2019 at 11:21:49AM +0800, Zhenyu Wang wrote: > > > > On 2019.06.27 12:31:33 +0200, Gerd Hoffmann wrote: > > > > > > > Hi, > > > > > > > > > > > > > > > Instead of delivering page flip events, we choose to post > > > > > > > > display vblank event. Handling page flip events for both > > > > > > > > primary plane and cursor plane may make user space quite > > > > > > > > busy, although we have the mask/unmask mechansim for > > mitigation. > > > > > > > > Besides, there are some cases that guest app only uses one > > > framebuffer for both drawing and display. > > > > > > > > In such case, guest OS won't do the plane page flip when the > > > > > > > > framebuffer is updated, thus the user land won't be notified > > > > > > > > about the > > > > > > > updated framebuffer. > > > > > > > > > > > > > > What happens when the guest is idle and doesn't draw anything > > > > > > > to the framebuffer? > > > > > > The vblank event will be delivered to userspace as well, unless > > > > > > guest OS > > > disable the pipe. > > > > > > Does it make sense to vfio/display? > > > > > > > > > > Getting notified only in case there are actual display updates > > > > > would be a nice optimization, assuming the hardware is able to do > > > > > that. > > > > > If the guest pageflips this is obviously trivial. Not sure this > > > > > is possible in case the guest renders directly to the frontbuffer. > > > > > > > > > > What exactly happens when the guest OS disables the pipe? Is a > > > > > vblank event delivered at least once? That would be very useful > > > > > because it will be possible for userspace to stop polling > > > > > altogether without missing the "guest disabled pipe" event. > > > > > > > > > > > > > It looks like purpose to use vblank here is to replace user space > > > > polling totally by kernel event? Which just act as display update > > > > event to replace user space timer to make it query and update planes? > > > > > > I think it makes sense to design it that way, so userspace will either > > > use the events (when supported by the driver) or a timer (fallback if > > > not) but not both. > > > > > > > Although in theory vblank is not appropriate for this which doesn't > > > > align with plane update or possible front buffer rendering at all, > > > > but looks it's just a compromise e.g not sending event for every > > > > cursor position change, etc. > > > > > > > > I think we need to define semantics for this event properly, e.g > > > > user space purely depends on this event for display update, the > > > > opportunity for issuing this event is controlled by driver when it's > > > > necessary for update, etc. Definitely not named as vblank event or > > > > only issue at vblank, that need to happen for other plane change too. > > > > > > I think it should be "display update notification", i.e. userspace > > > should check for plane changes and update the display. > > > > > > Most events will probably come from vblank (typically plane update are > > > actually committed at vblank time to avoid tearing, right?).
[v2 3/3] hwmon: (nct7904) Add extra sysfs support for fan, voltage and temperature.
From: "amy.shih"
NCT-7904D also supports reading of channel limitation registers
and SMI status registers for fan, voltage and temperature monitoring,
and also supports reading of temperature sensor type which is thermal diode,
thermistor, AMD SB-TSI or Intel PECI, thus add below sysfs nodes:
-fan[1-*]_min
-fan[1-*]_alarm
-in[1-*]_min
-in[1-*]_max
-in[1-*]_alarm
-temp[1-*]_max
-temp[1-*]_max_hyst
-temp[1-*]_emergency
-temp[1-*]_emergency_hyst
-temp[1-*]_alarm
-temp[1-*]_type
Signed-off-by: amy.shih
---
Changes in v2:
- Fix bad fallthrough in various switch statements.
- Fix the wrong declared of tmp as u8 in nct7904_write_in, declared tmp to int.
- Fix incorrect register setting of voltage.
- Fix incorrect register bit mapping of temperature alarm.
- Fix wrong return code 0x1fff in function nct7904_write_fan.
- Delete wrong comment in function nct7904_write_in.
- Fix wrong attribute names for temperature.
- Fix wrong registers setting for temperature.
---
drivers/hwmon/nct7904.c | 469
1 file changed, 424 insertions(+), 45 deletions(-)
diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
index 710c30562fc1..d842c10ba11f 100644
--- a/drivers/hwmon/nct7904.c
+++ b/drivers/hwmon/nct7904.c
@@ -46,10 +46,33 @@
#define DTS_T_CTRL1_REG0x27
#define VT_ADC_MD_REG 0x2E
+#define VSEN1_HV_LL_REG0x02/* Bank 1; 2 regs (HV/LV) per
sensor */
+#define VSEN1_LV_LL_REG0x03/* Bank 1; 2 regs (HV/LV) per
sensor */
+#define VSEN1_HV_HL_REG0x00/* Bank 1; 2 regs (HV/LV) per
sensor */
+#define VSEN1_LV_HL_REG0x01/* Bank 1; 2 regs (HV/LV) per
sensor */
+#define SMI_STS1_REG 0xC1/* Bank 0; SMI Status Register */
+#define SMI_STS5_REG 0xC5/* Bank 0; SMI Status Register */
+#define SMI_STS7_REG 0xC7/* Bank 0; SMI Status Register */
+#define SMI_STS8_REG 0xC8/* Bank 0; SMI Status Register */
+
#define VSEN1_HV_REG 0x40/* Bank 0; 2 regs (HV/LV) per sensor */
#define TEMP_CH1_HV_REG0x42/* Bank 0; same as VSEN2_HV */
#define LTD_HV_REG 0x62/* Bank 0; 2 regs in VSEN range */
+#define LTD_HV_HL_REG 0x44/* Bank 1; 1 reg for LTD */
+#define LTD_LV_HL_REG 0x45/* Bank 1; 1 reg for LTD */
+#define LTD_HV_LL_REG 0x46/* Bank 1; 1 reg for LTD */
+#define LTD_LV_LL_REG 0x47/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_CH_REG0x05/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_W_REG 0x06/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_WH_REG0x07/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_C_REG 0x04/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_C_REG 0x90/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_CH_REG 0x91/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_W_REG 0x92/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_WH_REG 0x93/* Bank 1; 1 reg per sensor */
#define FANIN1_HV_REG 0x80/* Bank 0; 2 regs (HV/LV) per sensor */
+#define FANIN1_HV_HL_REG 0x60/* Bank 1; 2 regs (HV/LV) per sensor */
+#define FANIN1_LV_HL_REG 0x61/* Bank 1; 2 regs (HV/LV) per sensor */
#define T_CPU1_HV_REG 0xA0/* Bank 0; 2 regs (HV/LV) per sensor */
#define PRTS_REG 0x03/* Bank 2 */
@@ -58,6 +81,8 @@
#define FANCTL1_FMR_REG0x00/* Bank 3; 1 reg per channel */
#define FANCTL1_OUT_REG0x10/* Bank 3; 1 reg per channel */
+#define ENABLE_TSI BIT(1)
+
static const unsigned short normal_i2c[] = {
0x2d, 0x2e, I2C_CLIENT_END
};
@@ -72,6 +97,7 @@ struct nct7904_data {
u8 fan_mode[FANCTL_MAX];
u8 enable_dts;
u8 has_dts;
+ u8 temp_mode; /* 0: TR mode, 1: TD mode */
};
/* Access functions */
@@ -170,6 +196,25 @@ static int nct7904_read_fan(struct device *dev, u32 attr,
int channel,
rpm = 135 / cnt;
*val = rpm;
return 0;
+ case hwmon_fan_min:
+ ret = nct7904_read_reg16(data, BANK_1,
+FANIN1_HV_HL_REG + channel * 2);
+ if (ret < 0)
+ return ret;
+ cnt = ((ret & 0xff00) >> 3) | (ret & 0x1f);
+ if (cnt == 0x1fff)
+ rpm = 0;
+ else
+ rpm = 135 / cnt;
+ *val = rpm;
+ return 0;
+ case hwmon_fan_alarm:
+ ret = nct7904_read_reg(data, BANK_0,
+ SMI_STS7_REG + (channel >> 3));
+ if (ret < 0)
+ return ret;
+ *val = (ret >> (channel & 0x07)) & 1;
+ return 0;
default:
return -EOPNOTSUPP;
}
@@
[PATCH] cifs: fix build by selecting CONFIG_KEYS
CONFIG_CIFS_ACL had a dependency "depends on KEYS" which was
dropped with the removal of CONFIG_CIFS_ACL. This breaks the
build on systems which don't have CONFIG_KEYS in .config:
cifsacl.c:37:15: error: variable ‘cifs_idmap_key_acl’ has
initializer but incomplete type
37 | static struct key_acl cifs_idmap_key_acl = {
| ^~~
cifsacl.c:38:3: error: ‘struct key_acl’ has no member
named ‘usage’
38 | .usage = REFCOUNT_INIT(1),
| ^
[..]
Signed-off-by: Sergey Senozhatsky
---
fs/cifs/Kconfig | 1 +
fs/cifs/cifsacl.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
index 3eee73449bdd..5912751e6f09 100644
--- a/fs/cifs/Kconfig
+++ b/fs/cifs/Kconfig
@@ -17,6 +17,7 @@ config CIFS
select CRYPTO_ECB
select CRYPTO_AES
select CRYPTO_DES
+ select KEYS
help
This is the client VFS module for the SMB3 family of NAS protocols,
(including support for the most recent, most secure dialect SMB3.1.1)
diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
index 78eed72f3af0..8ca479caf902 100644
--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.22.0
Re: [PATCH 2/6] Adjust watch_queue documentation to mention mount and superblock watches. [ver #5]
Hi David, On 6/28/19 8:50 AM, David Howells wrote: > Signed-off-by: David Howells > --- > > Documentation/watch_queue.rst | 20 +++- > drivers/misc/Kconfig |5 +++-- > 2 files changed, 22 insertions(+), 3 deletions(-) > > diff --git a/Documentation/watch_queue.rst b/Documentation/watch_queue.rst > index 4087a8e670a8..1bec2018d549 100644 > --- a/Documentation/watch_queue.rst > +++ b/Documentation/watch_queue.rst > @@ -13,6 +13,10 @@ receive notifications from the kernel. This can be used > in conjunction with:: > > * USB subsystem event notifications > > + * Mount topology change notifications > + > + * Superblock event notifications > + > > The notifications buffers can be enabled by: > > @@ -324,6 +328,19 @@ Any particular buffer can be fed from multiple sources. > Sources include: > for buses and devices. Watchpoints of this type are set on the global > device watch list. > > + * WATCH_TYPE_MOUNT_NOTIFY > + > +Notifications of this type indicate mount tree topology changes and mount > +attribute changes. A watch can be set on a particular file or directory > +and notifications from the path subtree rooted at that point will be > +intercepted. > + > + * WATCH_TYPE_SB_NOTIFY > + > +Notifications of this type indicate superblock events, such as quota > limits > +being hit, I/O errors being produced or network server loss/reconnection. > +Watches of this type are set directly on superblocks. > + > > Event Filtering > === > @@ -365,7 +382,8 @@ Where: > (watch.info & info_mask) == info_filter > > This could be used, for example, to ignore events that are not exactly on > -the watched point in a mount tree. > +the watched point in a mount tree by specifying NOTIFY_MOUNT_IN_SUBTREE > +must be 0. I'm having a little trouble parsing that sentence. Could you clarify it or maybe rewrite/modify it? Thanks. > >* ``subtype_filter`` is a bitmask indicating the subtypes that are of > interest. Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to -- ~Randy
[PATCH v2] udf: Fix incorrect final NOT_ALLOCATED (hole) extent length
In some cases, using the 'truncate' command to extend a UDF file results
in a mismatch between the length of the file's extents (specifically, due
to incorrect length of the final NOT_ALLOCATED extent) and the information
(file) length. The discrepancy can prevent other operating systems
(i.e., Windows 10) from opening the file.
Two particular errors have been observed when extending a file:
1. The final extent is larger than it should be, having been rounded up
to a multiple of the block size.
B. The final extent is not shorter than it should be, due to not having
been updated when the file's information length was increased.
Change since v1:
Simplified udf_do_extend_file() API, partially by factoring out its
handling of the "extending within the last file block" corner case.
Fixes: 2c948b3f86e5 ("udf: Avoid IO in udf_clear_inode")
Signed-off-by: Steven J. Magnani
--- a/fs/udf/inode.c2019-05-24 21:17:33.659704533 -0500
+++ b/fs/udf/inode.c2019-06-29 21:10:48.938562957 -0500
@@ -470,13 +470,15 @@ static struct buffer_head *udf_getblk(st
return NULL;
}
-/* Extend the file by 'blocks' blocks, return the number of extents added */
+/* Extend the file with new blocks totaling 'new_block_bytes',
+ * return the number of extents added
+ */
static int udf_do_extend_file(struct inode *inode,
struct extent_position *last_pos,
struct kernel_long_ad *last_ext,
- sector_t blocks)
+ loff_t new_block_bytes)
{
- sector_t add;
+ unsigned long add;
int count = 0, fake = !(last_ext->extLength & UDF_EXTENT_LENGTH_MASK);
struct super_block *sb = inode->i_sb;
struct kernel_lb_addr prealloc_loc = {};
@@ -486,7 +488,7 @@ static int udf_do_extend_file(struct ino
/* The previous extent is fake and we should not extend by anything
* - there's nothing to do... */
- if (!blocks && fake)
+ if (!new_block_bytes && fake)
return 0;
iinfo = UDF_I(inode);
@@ -517,13 +519,12 @@ static int udf_do_extend_file(struct ino
/* Can we merge with the previous extent? */
if ((last_ext->extLength & UDF_EXTENT_FLAG_MASK) ==
EXT_NOT_RECORDED_NOT_ALLOCATED) {
- add = ((1 << 30) - sb->s_blocksize -
- (last_ext->extLength & UDF_EXTENT_LENGTH_MASK)) >>
- sb->s_blocksize_bits;
- if (add > blocks)
- add = blocks;
- blocks -= add;
- last_ext->extLength += add << sb->s_blocksize_bits;
+ add = (1 << 30) - sb->s_blocksize -
+ (last_ext->extLength & UDF_EXTENT_LENGTH_MASK);
+ if (add > new_block_bytes)
+ add = new_block_bytes;
+ new_block_bytes -= add;
+ last_ext->extLength += add;
}
if (fake) {
@@ -544,28 +545,27 @@ static int udf_do_extend_file(struct ino
}
/* Managed to do everything necessary? */
- if (!blocks)
+ if (!new_block_bytes)
goto out;
/* All further extents will be NOT_RECORDED_NOT_ALLOCATED */
last_ext->extLocation.logicalBlockNum = 0;
last_ext->extLocation.partitionReferenceNum = 0;
- add = (1 << (30-sb->s_blocksize_bits)) - 1;
- last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED |
- (add << sb->s_blocksize_bits);
+ add = (1 << 30) - sb->s_blocksize;
+ last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED | add;
/* Create enough extents to cover the whole hole */
- while (blocks > add) {
- blocks -= add;
+ while (new_block_bytes > add) {
+ new_block_bytes -= add;
err = udf_add_aext(inode, last_pos, _ext->extLocation,
last_ext->extLength, 1);
if (err)
return err;
count++;
}
- if (blocks) {
+ if (new_block_bytes) {
last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED |
- (blocks << sb->s_blocksize_bits);
+ new_block_bytes;
err = udf_add_aext(inode, last_pos, _ext->extLocation,
last_ext->extLength, 1);
if (err)
@@ -596,6 +596,44 @@ out:
return count;
}
+/* Extend the final block of the file to final_block_len bytes */
+static int udf_do_extend_final_block(struct inode *inode,
+struct extent_position *last_pos,
+struct kernel_long_ad *last_ext,
+unsigned long final_block_len)
+{
+ struct super_block *sb = inode->i_sb;
+ struct kernel_lb_addr tmploc;
+ uint32_t
Re: nouveau: DRM: GPU lockup - switching to software fbcon
On (06/19/19 02:07), Ilia Mirkin wrote: > If all else fails, just remove nouveau_dri.so and/or boot with > nouveau.noaccel=1 -- should be perfect. nouveau.noaccel=1 did the trick. Is there any other, let's say less CPU-intensive, way to fix nouveau? -ss
linux-next: build warning after merge of the hwmon-staging tree
Hi all,
After merging the hwmon-staging tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/hwmon/lm90.c: In function 'lm90_write_convrate':
drivers/hwmon/lm90.c:597:42: warning: 'config_stop' may be used uninitialized
in this function [-Wmaybe-uninitialized]
if (data->flags & LM90_PAUSE_FOR_CONFIG && config_orig != config_stop)
^
drivers/hwmon/lm90.c:598:3: warning: 'config_orig' may be used uninitialized in
this function [-Wmaybe-uninitialized]
i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
^
config_orig);
Introduced by commit
479a503fa073 ("hwmon: (lm90) Fix max6658 sporadic wrong temperature reading")
--
Cheers,
Stephen Rothwell
pgpmhYqCWEvJW.pgp
Description: OpenPGP digital signature
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
On Fri, Jun 28, 2019 at 08:20:45PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-06-28 14:07:27 [-0400], Joel Fernandes wrote:
> > On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > > > I believe the .blocked field remains set even though we are not any
> > > > > more in a
> > > > > reader section because of deferred processing of the blocked lists
> > > > > that you
> > > > > mentioned yesterday.
> > > >
> > > > That can indeed happen. However, in current -rcu, that would mean
> > > > that .deferred_qs is also set, which (if in_irq()) would prevent
> > > > the raise_softirq_irqsoff() from being invoked. Which was why I was
> > > > asking the questions about whether in_irq() returns true within threaded
> > > > interrupts yesterday. If it does, I need to find if there is some way
> > > > of determining whether rcu_read_unlock_special() is being called from
> > > > a threaded interrupt in order to suppress the call to raise_softirq()
> > > > in that case.
> > >
> > > Please not that:
> > > | void irq_exit(void)
> > > | {
> > > |…
> > > in_irq() returns true
> > > | preempt_count_sub(HARDIRQ_OFFSET);
> > > in_irq() returns false
> > > | if (!in_interrupt() && local_softirq_pending())
> > > | invoke_softirq();
> > >
> > > -> invoke_softirq() does
> > > |if (!force_irqthreads) {
> > > | __do_softirq();
> > > | } else {
> > > | wakeup_softirqd();
> > > | }
> > >
> >
> > In my traces which I shared previous email, the wakeup_softirqd() gets
> > called.
> >
> > I thought force_irqthreads value is decided at boot time, so I got lost a
> > bit
> > with your comment.
>
> It does. I just wanted point out that in this case
> rcu_unlock() / rcu_read_unlock_special() won't see in_irq() true.
Paul, Sebastian, This commit breaks kvm.sh for me on both my machines. I have
to revert it to make things work otherwise the test just runs for 10 seconds
or so and dies.
"rcutorture: Tweak kvm options"
This reverts commit a6fda6dab93c2c06ef4b8cb4b9258df6674d2438.
Any thoughts or debug ideas? I am running v4.19.37
thanks,
- Joel
Re: [PATCH v4 4/4] drm/mtk: add panel orientation property
Hi, Derek:
On Fri, 2019-06-21 at 20:41 -0700, Derek Basehore wrote:
> This inits the panel orientation property for the mediatek dsi driver
> if the panel orientation (connector.display_info.panel_orientation) is
> not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
>
Reviewed-by: CK Hu
> Signed-off-by: Derek Basehore
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4a0b9150a7bb..08ffdc7526dd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -782,10 +782,18 @@ static int mtk_dsi_create_connector(struct drm_device
> *drm, struct mtk_dsi *dsi)
> DRM_ERROR("Failed to attach panel to drm\n");
> goto err_connector_cleanup;
> }
> +
> + ret = drm_connector_init_panel_orientation_property(>conn);
> + if (ret) {
> + DRM_ERROR("Failed to init panel orientation\n");
> + goto err_panel_detach;
> + }
> }
>
> return 0;
>
> +err_panel_detach:
> + drm_panel_detach(dsi->panel);
> err_connector_cleanup:
> drm_connector_cleanup(>conn);
> return ret;
Re: [PATCH REBASE v2 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig
On 2019/5/26 20:50, Alexandre Ghiti wrote: > ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: > move this declaration in arch/Kconfig and make those architectures > select it. > > Signed-off-by: Alexandre Ghiti > Reviewed-by: Palmer Dabbelt > --- > arch/Kconfig | 3 +++ > arch/arm64/Kconfig | 2 +- > arch/x86/Kconfig | 4 +--- > 3 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index c47b328eada0..d2f212dc8e72 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -577,6 +577,9 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD > config HAVE_ARCH_HUGE_VMAP > bool > > +config ARCH_WANT_HUGE_PMD_SHARE > + bool > + > config HAVE_ARCH_SOFT_DIRTY > bool > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 4780eb7af842..dee7f750c42f 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -70,6 +70,7 @@ config ARM64 > select ARCH_SUPPORTS_NUMA_BALANCING > select ARCH_WANT_COMPAT_IPC_PARSE_VERSION > select ARCH_WANT_FRAME_POINTERS > + select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES > && !ARM64_VA_BITS_36) > select ARCH_HAS_UBSAN_SANITIZE_ALL > select ARM_AMBA > select ARM_ARCH_TIMER > @@ -884,7 +885,6 @@ config SYS_SUPPORTS_HUGETLBFS > def_bool y > > config ARCH_WANT_HUGE_PMD_SHARE > - def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36) Why not remove config ARCH_WANT_HUGE_PMD_SHARE as well? Did I miss something? Thanks Hanjun
[PATCH] drm/nouveau: fix memory leak in nouveau_conn_reset()
In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc->state will be assigned to connector->state.
So using nouveau_conn_atomic_destroy_state() instead of
__drm_atomic_helper_connector_destroy_state to free the "old" asyc.
Here the is the log showing memory leak.
unreferenced object 0x8c5480483c80 (size 192):
comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s)
hex dump (first 32 bytes):
00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00 ...{T...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[<5005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0
[] nouveau_conn_reset+0x25/0xc0 [nouveau]
[<4fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau]
[] nv50_display_create+0x343/0x980 [nouveau]
[<2e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau]
[] nouveau_drm_device_init+0x182/0x7f0 [nouveau]
[] nouveau_drm_probe+0x20c/0x2c0 [nouveau]
[<7e961c3e>] local_pci_probe+0x47/0xa0
[] work_for_cpu_fn+0x1a/0x30
[<28da4805>] process_one_work+0x27c/0x660
[<1d415b04>] worker_thread+0x22b/0x3f0
[<03b69f1f>] kthread+0x12f/0x150
[] ret_from_fork+0x3a/0x50
Signed-off-by: Yongxin Liu
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 4116ee62adaf..f69ff22beee0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -252,7 +252,7 @@ nouveau_conn_reset(struct drm_connector *connector)
return;
if (connector->state)
- __drm_atomic_helper_connector_destroy_state(connector->state);
+ nouveau_conn_atomic_destroy_state(connector, connector->state);
__drm_atomic_helper_connector_reset(connector, >state);
asyc->dither.mode = DITHERING_MODE_AUTO;
asyc->dither.depth = DITHERING_DEPTH_AUTO;
--
2.14.4
Re: [PATCH] devfreq: tegra20: add COMMON_CLK dependency
Hi Arnd,
Thanks for fixup.
Reviewed-by: Chanwoo Choi
Hi Myungjoo,
This patch have to be merged for linux 5.3 before sending pull-request
because it fixed the build error of merged patch[1] on devfreq.git.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/commit/?h=for-next=028b3793284fa1bb4db73a90608d7cb24664480c
Best Regards,
Chanwoo Choi
On 19. 6. 28. 오후 7:32, Arnd Bergmann wrote:
> Compile-testing the new driver on platforms without CONFIG_COMMON_CLK
> leads to a link error:
>
> drivers/devfreq/tegra20-devfreq.o: In function `tegra_devfreq_target':
> tegra20-devfreq.c:(.text+0x288): undefined reference to `clk_set_min_rate'
>
> Add a dependency on COMMON_CLK to avoid this.
>
> Fixes: 1d39ee8dad6d ("PM / devfreq: Introduce driver for NVIDIA Tegra20")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/devfreq/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index f3b242987fd9..defe1d438710 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -107,6 +107,7 @@ config ARM_TEGRA_DEVFREQ
> config ARM_TEGRA20_DEVFREQ
> tristate "NVIDIA Tegra20 DEVFREQ Driver"
> depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST
> + depends on COMMON_CLK
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> select PM_OPP
> help
>
Re: [v5 6/7] drm/mediatek: change the dsi phytiming calculate method
Hi, Jitao:
On Thu, 2019-06-27 at 16:01 +0800, Jitao Shi wrote:
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> else
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
>
> Note:
> //(2: 1 for sync, 1 for phy idle)
> data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
>
> bpp: bit per pixel
>
> Signed-off-by: Jitao Shi
> Tested-by: Ryan Case
> Reviewed-by: CK Hu
This version is different than previous version, so you should remove
Reviewed-by tag. For this version, I still give you a
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 117 -
> 1 file changed, 80 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 1621e8cdacc2..cefdcb1509cb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -144,12 +144,6 @@
> #define DATA_0 (0xff << 16)
> #define DATA_1 (0xff << 24)
>
> -#define T_LPX5
> -#define T_HS_PREP6
> -#define T_HS_TRAIL 8
> -#define T_HS_EXIT7
> -#define T_HS_ZERO10
> -
> #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>
> #define MTK_DSI_HOST_IS_READ(type) \
> @@ -158,6 +152,25 @@
> (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> (type == MIPI_DSI_DCS_READ))
>
> +struct mtk_phy_timing {
> + u32 lpx;
> + u32 da_hs_prepare;
> + u32 da_hs_zero;
> + u32 da_hs_trail;
> +
> + u32 ta_go;
> + u32 ta_sure;
> + u32 ta_get;
> + u32 da_hs_exit;
> +
> + u32 clk_hs_zero;
> + u32 clk_hs_trail;
> +
> + u32 clk_hs_prepare;
> + u32 clk_hs_post;
> + u32 clk_hs_exit;
> +};
> +
> struct phy;
>
> struct mtk_dsi_driver_data {
> @@ -188,6 +201,7 @@ struct mtk_dsi {
> enum mipi_dsi_pixel_format format;
> unsigned int lanes;
> struct videomode vm;
> + struct mtk_phy_timing phy_timing;
> int refcount;
> bool enabled;
> u32 irq_data;
> @@ -221,17 +235,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
> {
> u32 timcon0, timcon1, timcon2, timcon3;
> u32 ui, cycle_time;
> + struct mtk_phy_timing *timing = >phy_timing;
> +
> + ui = 10 / dsi->data_rate;
> + cycle_time = div_u64(80ULL, dsi->data_rate);
> +
> + timing->lpx = NS_TO_CYCLE(60, cycle_time);
> + timing->da_hs_prepare = NS_TO_CYCLE(40 + 5 * ui, cycle_time);
> + timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
> + timing->da_hs_trail = NS_TO_CYCLE(80 + 4 * ui, cycle_time);
>
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> + timing->ta_go = 4 * timing->lpx;
> + timing->ta_sure = 3 * timing->lpx / 2;
> + timing->ta_get = 5 * timing->lpx;
> + timing->da_hs_exit = 2 * timing->lpx;
>
> - timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> - timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> - T_HS_EXIT << 24;
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> - NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> + timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
> + timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
> +
> + timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
> + timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> + timing->clk_hs_exit = 2 * timing->lpx;
> +
> + timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> + timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> + timcon1 = timing->ta_go | timing->ta_sure << 8 |
> + timing->ta_get << 16 | timing->da_hs_exit << 24;
> + timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> + timing->clk_hs_trail << 24;
> + timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> + timing->clk_hs_exit << 16;
>
> writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> @@ -418,7 +451,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> u32 horizontal_sync_active_byte;
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> - u32 dsi_tmp_buf_bpp;
> + u32 dsi_tmp_buf_bpp, data_phy_cycles;
> + struct mtk_phy_timing *timing = >phy_timing;
>
> struct videomode *vm = >vm;
>
> @@ -445,7 +479,34 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
>
Re: [PATCH 41/43] docs: extcon: convert it to ReST and move to acpi dir
Hi Mauro,
On 19. 6. 28. 오후 9:20, Mauro Carvalho Chehab wrote:
> The intel-int3496.txt file is a documentation for an ACPI driver.
>
> There's no reason to keep it on a separate directory.
>
> So, instead of keeping it on some random location, move it
> to a sub-directory inside the ACPI documentation dir,
> renaming it to .rst.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../acpi/extcon-intel-int3496.rst} | 14 ++
> Documentation/firmware-guide/acpi/index.rst| 1 +
> MAINTAINERS| 6 +++---
> 3 files changed, 14 insertions(+), 7 deletions(-)
> rename Documentation/{extcon/intel-int3496.txt =>
> firmware-guide/acpi/extcon-intel-int3496.rst} (66%)
>
> diff --git a/Documentation/extcon/intel-int3496.txt
> b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> similarity index 66%
> rename from Documentation/extcon/intel-int3496.txt
> rename to Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> index 8155dbc7fad3..5137ca834b54 100644
> --- a/Documentation/extcon/intel-int3496.txt
> +++ b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> @@ -1,5 +1,6 @@
> +=
> Intel INT3496 ACPI device extcon driver documentation
> --
> +=
>
> The Intel INT3496 ACPI device extcon driver is a driver for ACPI
> devices with an acpi-id of INT3496, such as found for example on
> @@ -13,15 +14,20 @@ between an USB host and an USB peripheral controller.
> The ACPI devices exposes this functionality by returning an array with up
> to 3 gpio descriptors from its ACPI _CRS (Current Resource Settings) call:
>
> -Index 0: The input gpio for the id-pin, this is always present and valid
> -Index 1: The output gpio for enabling Vbus output from the device to the otg
> +===
> =
> +Index 0 The input gpio for the id-pin, this is always present and valid
> +Index 1 The output gpio for enabling Vbus output from the device to the otg
> port, write 1 to enable the Vbus output (this gpio descriptor may
> be absent or invalid)
> -Index 2: The output gpio for muxing of the data pins between the USB host and
> +Index 2 The output gpio for muxing of the data pins between the USB host and
> the USB peripheral controller, write 1 to mux to the peripheral
> controller
> +===
> =
>
> There is a mapping between indices and GPIO connection IDs as follows
> +
> + === ===
> id index 0
> vbusindex 1
> mux index 2
> + === ===
> diff --git a/Documentation/firmware-guide/acpi/index.rst
> b/Documentation/firmware-guide/acpi/index.rst
> index ae609eec4679..90c90d42d9ad 100644
> --- a/Documentation/firmware-guide/acpi/index.rst
> +++ b/Documentation/firmware-guide/acpi/index.rst
> @@ -24,3 +24,4 @@ ACPI Support
> acpi-lid
> lpit
> video_extension
> + extcon-intel-int3496
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fd6fab0dec77..2cf8abf6d48e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -321,7 +321,7 @@ F:drivers/pnp/pnpacpi/
> F: include/linux/acpi.h
> F: include/linux/fwnode.h
> F: include/acpi/
> -F: Documentation/acpi/
> +F: Documentation/firmware-guide/acpi/
> F: Documentation/ABI/testing/sysfs-bus-acpi
> F: Documentation/ABI/testing/configfs-acpi
> F: drivers/pci/*acpi*
> @@ -4896,7 +4896,7 @@ S: Maintained
> F: Documentation/
> F: scripts/kernel-doc
> X: Documentation/ABI/
> -X: Documentation/acpi/
> +X: Documentation/firmware-guide/acpi/
> X: Documentation/devicetree/
> X: Documentation/i2c/
> X: Documentation/media/
> @@ -6073,7 +6073,7 @@ S: Maintained
> F: drivers/extcon/
> F: include/linux/extcon/
> F: include/linux/extcon.h
> -F: Documentation/extcon/
> +F: Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> F: Documentation/devicetree/bindings/extcon/
>
> EXYNOS DP DRIVER
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [v5 4/7] drm/mediatek: add frame size control
Hi, Jitao:
On Thu, 2019-06-27 at 16:01 +0800, Jitao Shi wrote:
> Our new DSI chip has frame size control.
> So add the driver data to control for different chips.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: CK Hu
This version is different than previous version, so you should remove
the reviewed-by tag. For this version, I still give you a
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 6b6550926db6..45e331055842 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -78,6 +78,7 @@
> #define DSI_VBP_NL 0x24
> #define DSI_VFP_NL 0x28
> #define DSI_VACT_NL 0x2C
> +#define DSI_SIZE_CON 0x38
> #define DSI_HSA_WC 0x50
> #define DSI_HBP_WC 0x54
> #define DSI_HFP_WC 0x58
> @@ -162,6 +163,7 @@ struct phy;
> struct mtk_dsi_driver_data {
> const u32 reg_cmdq_off;
> bool has_shadow_ctl;
> + bool has_size_ctl;
> };
>
> struct mtk_dsi {
> @@ -430,6 +432,10 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
> writel(vm->vfront_porch, dsi->regs + DSI_VFP_NL);
> writel(vm->vactive, dsi->regs + DSI_VACT_NL);
>
> + if (dsi->driver_data->has_size_ctl)
> + writel(vm->vactive << 16 | vm->hactive,
> +dsi->regs + DSI_SIZE_CON);
> +
> horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
Re: [PATCH] misc: fsa9480: Delete this driver
Hi Linus, On 19. 6. 30. 오후 11:03, Linus Walleij wrote: > The FSA9480 has a new driver more appropriately located > in the drivers/extcon subsystem. It is also more complete > and includes device tree support. Delete the old misc > driver. > > Cc: Paweł Chmiel > Cc: Chanwoo Choi > Cc: Arnd Bergmann > Signed-off-by: Linus Walleij > --- > drivers/misc/Kconfig | 9 - > drivers/misc/Makefile | 1 - > drivers/misc/fsa9480.c| 547 -- > include/linux/platform_data/fsa9480.h | 24 -- > 4 files changed, 581 deletions(-) > delete mode 100644 drivers/misc/fsa9480.c > delete mode 100644 include/linux/platform_data/fsa9480.h > Reviewed-by: Chanwoo Choi Best Regards, Chanwoo Choi
Re: [PATCH 22/39] docs: ocxl.rst: add it to the uAPI book
On 28/6/19 10:30 pm, Mauro Carvalho Chehab wrote:
The content of this file is user-faced.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Andrew Donnellan
---
Documentation/{ => userspace-api}/accelerators/ocxl.rst | 2 --
Documentation/userspace-api/index.rst | 1 +
MAINTAINERS | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
rename Documentation/{ => userspace-api}/accelerators/ocxl.rst (99%)
diff --git a/Documentation/accelerators/ocxl.rst
b/Documentation/userspace-api/accelerators/ocxl.rst
similarity index 99%
rename from Documentation/accelerators/ocxl.rst
rename to Documentation/userspace-api/accelerators/ocxl.rst
index b1cea19a90f5..14cefc020e2d 100644
--- a/Documentation/accelerators/ocxl.rst
+++ b/Documentation/userspace-api/accelerators/ocxl.rst
@@ -1,5 +1,3 @@
-:orphan:
-
OpenCAPI (Open Coherent Accelerator Processor Interface)
diff --git a/Documentation/userspace-api/index.rst
b/Documentation/userspace-api/index.rst
index a3233da7fa88..ad494da40009 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -20,6 +20,7 @@ place where this information is gathered.
seccomp_filter
unshare
spec_ctrl
+ accelerators/ocxl
.. only:: subproject and html
diff --git a/MAINTAINERS b/MAINTAINERS
index 29d1498ad39d..f723371dccd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11483,7 +11483,7 @@ F: arch/powerpc/include/asm/pnv-ocxl.h
F:drivers/misc/ocxl/
F:include/misc/ocxl*
F:include/uapi/misc/ocxl.h
-F: Documentation/accelerators/ocxl.rst
+F: Documentation/userspace-api/accelerators/ocxl.rst
OMAP AUDIO SUPPORT
M:Peter Ujfalusi
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
linux-next: build failure after merge of the xfs tree
Hi all,
After merging the xfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
fs/orangefs/file.c: In function 'orangefs_getflags':
fs/orangefs/file.c:372:7: warning: assignment to 'long unsigned int *' from
'__u64' {aka 'long long unsigned int'} makes pointer from integer without a
cast [-Wint-conversion]
uval = val;
^
fs/orangefs/file.c: In function 'orangefs_ioctl':
fs/orangefs/file.c:381:24: error: implicit declaration of function
'file_ioctl'; did you mean 'file_path'? [-Werror=implicit-function-declaration]
struct inode *inode = file_ioctl(file);
^~
file_path
fs/orangefs/file.c:381:24: warning: initialization of 'struct inode *' from
'int' makes pointer from integer without a cast [-Wint-conversion]
fs/orangefs/file.c:418:35: error: 'old_uval' undeclared (first use in this
function); did you mean 'p4d_val'?
ret = orangefs_getflags(inode, _uval);
^~~~
p4d_val
fs/orangefs/file.c:418:35: note: each undeclared identifier is reported only
once for each function it appears in
Caused by commit
de2baa49bbae ("vfs: create a generic checking and prep function for
FS_IOC_SETFLAGS")
I have used the xfs tree from next-20190628 for today.
--
Cheers,
Stephen Rothwell
pgpU7wXqMJZyn.pgp
Description: OpenPGP digital signature
Re: [PATCH] vfs: move_mount: reject moving kernel internal mounts
On Sat, Jun 29, 2019 at 09:39:16PM +0100, Al Viro wrote: > On Sat, Jun 29, 2019 at 01:27:44PM -0700, Eric Biggers wrote: > > > @@ -2600,7 +2600,7 @@ static int do_move_mount(struct path *old_path, > > struct path *new_path) > > if (attached && !check_mnt(old)) > > goto out; > > > > - if (!attached && !(ns && is_anon_ns(ns))) > > + if (!attached && !(ns && ns != MNT_NS_INTERNAL && is_anon_ns(ns))) > > goto out; > > > > if (old->mnt.mnt_flags & MNT_LOCKED) > > *UGH* > > Applied, but that code is getting really ugly ;-/ FWIW, it's too ugly and confusing. Look: /* The mountpoint must be in our namespace. */ if (!check_mnt(p)) goto out; /* The thing moved should be either ours or completely unattached. */ if (attached && !check_mnt(old)) goto out; if (!attached && !(ns && ns != MNT_NS_INTERNAL && is_anon_ns(ns))) goto out; OK, the first check is sane and understandable. But let's look at what's coming after it. We have two cases: 1) attached. IOW, old->mnt_parent != old. In that case we require old->mnt_ns == current mnt_ns. Anything else is rejected. 2) !attached. old->mnt_parent == old. In that case we require old->mnt_ns to be an anon namespace. Let's reorder that a bit: /* The mountpoint must be in our namespace. */ if (!check_mnt(p)) goto out; /* The thing moved must be mounted... */ if (!is_mounted(old_path->mnt)) goto out; /* ... and either ours or the root of anon namespace */ if (!(attached ? check_mnt(old) : is_anon_ns(ns))) goto out; IMO that looks saner and all it costs us is a redundant check in attached case. Objections?
linux-next: manual merge of the xfs tree with the f2fs tree
Hi all,
Today's linux-next merge of the xfs tree got a conflict in:
fs/f2fs/file.c
between commit:
360985573b55 ("f2fs: separate f2fs i_flags from fs_flags and ext4 i_flags")
from the f2fs tree and commits:
de2baa49bbae ("vfs: create a generic checking and prep function for
FS_IOC_SETFLAGS")
3dd3ba36a8ee ("vfs: create a generic checking function for FS_IOC_FSSETXATTR")
from the xfs tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/f2fs/file.c
index e7c368db8185,8799468724f9..
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@@ -1645,22 -1648,45 +1645,23 @@@ static int f2fs_file_flush(struct file
return 0;
}
-static int f2fs_ioc_getflags(struct file *filp, unsigned long arg)
-{
- struct inode *inode = file_inode(filp);
- struct f2fs_inode_info *fi = F2FS_I(inode);
- unsigned int flags = fi->i_flags;
-
- if (IS_ENCRYPTED(inode))
- flags |= F2FS_ENCRYPT_FL;
- if (f2fs_has_inline_data(inode) || f2fs_has_inline_dentry(inode))
- flags |= F2FS_INLINE_DATA_FL;
- if (is_inode_flag_set(inode, FI_PIN_FILE))
- flags |= F2FS_NOCOW_FL;
-
- flags &= F2FS_FL_USER_VISIBLE;
-
- return put_user(flags, (int __user *)arg);
-}
-
-static int __f2fs_ioc_setflags(struct inode *inode, unsigned int flags)
+static int f2fs_setflags_common(struct inode *inode, u32 iflags, u32 mask)
{
struct f2fs_inode_info *fi = F2FS_I(inode);
- unsigned int oldflags;
+ u32 oldflags;
+ int err;
/* Is it quota file? Do not allow user to mess with it */
if (IS_NOQUOTA(inode))
return -EPERM;
- flags = f2fs_mask_flags(inode->i_mode, flags);
-
oldflags = fi->i_flags;
- if ((iflags ^ oldflags) & (F2FS_APPEND_FL | F2FS_IMMUTABLE_FL))
- if (!capable(CAP_LINUX_IMMUTABLE))
- return -EPERM;
- err = vfs_ioc_setflags_prepare(inode, oldflags, flags);
++ err = vfs_ioc_setflags_prepare(inode, oldflags, iflags);
+ if (err)
+ return err;
- flags = flags & F2FS_FL_USER_MODIFIABLE;
- flags |= oldflags & ~F2FS_FL_USER_MODIFIABLE;
- fi->i_flags = flags;
+ fi->i_flags = iflags | (oldflags & ~mask);
if (fi->i_flags & F2FS_PROJINHERIT_FL)
set_inode_flag(inode, FI_PROJ_INHERIT);
@@@ -2850,53 -2773,35 +2851,33 @@@ static inline u32 f2fs_xflags_to_iflags
return iflags;
}
- static int f2fs_ioc_fsgetxattr(struct file *filp, unsigned long arg)
+ static void f2fs_fill_fsxattr(struct inode *inode, struct fsxattr *fa)
{
- struct inode *inode = file_inode(filp);
struct f2fs_inode_info *fi = F2FS_I(inode);
- struct fsxattr fa;
- memset(, 0, sizeof(struct fsxattr));
- fa.fsx_xflags = f2fs_iflags_to_xflags(fi->i_flags);
- simple_fill_fsxattr(fa, f2fs_iflags_to_xflags(fi->i_flags &
-F2FS_FL_USER_VISIBLE));
++ simple_fill_fsxattr(fa, f2fs_iflags_to_xflags(fi->i_flags));
if (f2fs_sb_has_project_quota(F2FS_I_SB(inode)))
- fa.fsx_projid = (__u32)from_kprojid(_user_ns,
- fi->i_projid);
-
- if (copy_to_user((struct fsxattr __user *)arg, , sizeof(fa)))
- return -EFAULT;
- return 0;
+ fa->fsx_projid = from_kprojid(_user_ns, fi->i_projid);
}
- static int f2fs_ioctl_check_project(struct inode *inode, struct fsxattr *fa)
+ static int f2fs_ioc_fsgetxattr(struct file *filp, unsigned long arg)
{
- /*
-* Project Quota ID state is only allowed to change from within the init
-* namespace. Enforce that restriction only if we are trying to change
-* the quota ID state. Everything else is allowed in user namespaces.
-*/
- if (current_user_ns() == _user_ns)
- return 0;
+ struct inode *inode = file_inode(filp);
+ struct fsxattr fa;
- if (__kprojid_val(F2FS_I(inode)->i_projid) != fa->fsx_projid)
- return -EINVAL;
-
- if (F2FS_I(inode)->i_flags & F2FS_PROJINHERIT_FL) {
- if (!(fa->fsx_xflags & FS_XFLAG_PROJINHERIT))
- return -EINVAL;
- } else {
- if (fa->fsx_xflags & FS_XFLAG_PROJINHERIT)
- return -EINVAL;
- }
+ f2fs_fill_fsxattr(inode, );
+ if (copy_to_user((struct fsxattr __user *)arg, , sizeof(fa)))
+ return -EFAULT;
return 0;
}
static
[PATCH 0/7] Compile-test UAPI and kernel headers
1/7: add CONFIG_CC_CAN_LINK to use it in 2/7 2/7: Compile-test exported headers 3/7: Do not generate intermediate wrappers. This will avoid header search path issue. 4/7: maybe useful for 7/7 and in some other places. Add header-test-pattern-y syntax. 5/7: Minor cleanup of gen_kheaders.sh 6/7: Exclude all files without ".h" extension from the kheaders_data.tar.xz This will be needed by 7/7 because we need to exclude "*.h.s" from the archive 7/7: Compile-test kernel-space headers in include/. Masahiro Yamada (7): init/Kconfig: add CONFIG_CC_CAN_LINK kbuild: compile-test exported headers to ensure they are self-contained kbuild: do not create wrappers for header-test-y kbuild: support header-test-pattern-y kheaders: remove meaningless -R option of 'ls' kheaders: include only headers into kheaders_data.tar.xz kbuild: compile-test kernel headers to ensure they are self-contained .gitignore |1 - Documentation/dontdiff |1 - Documentation/kbuild/makefiles.txt | 13 +- Makefile |4 +- include/Kbuild | 1253 init/Kconfig | 24 + kernel/gen_kheaders.sh | 51 +- net/bpfilter/Kconfig |2 +- scripts/Makefile.build | 10 +- scripts/Makefile.lib | 13 +- usr/.gitignore |1 - usr/Makefile |2 + usr/include/.gitignore |3 + usr/include/Makefile | 131 +++ 14 files changed, 1462 insertions(+), 47 deletions(-) create mode 100644 include/Kbuild create mode 100644 usr/include/.gitignore create mode 100644 usr/include/Makefile -- 2.17.1
[PATCH 7/7] kbuild: compile-test kernel headers to ensure they are self-contained
The headers in include/ are globally used in the kernel source tree to provide common APIs. They are included from external modules, too. It will be useful to make as many headers self-contained as possible so that we do not have to rely on a specific include order. There are more than 4000 headers in include/. In my rough analysis, 70% of them are already self-contained. With efforts, most of them can be self-contained. For now, we must exclude more than 1000 headers just because they cannot be compiled as standalone units. I added them to header-test-. The blacklist was mostly generated by a script, so the reason of the breakage should be checked later. Signed-off-by: Masahiro Yamada Tested-by: Jani Nikula --- Changes in v4: - Fix vmlinux build error - Exclude more headers for sparc Changes in v3: - Exclude more headers (Tested for allnoconfig + CONFIG_HEADER_TEST=y) Changes in v2: - Add everything to test coverage, and exclude broken ones - Rename 'Makefile' to 'Kbuild' - Add CONFIG_KERNEL_HEADER_TEST option Makefile |1 + include/Kbuild | 1253 init/Kconfig | 11 + 3 files changed, 1265 insertions(+) create mode 100644 include/Kbuild diff --git a/Makefile b/Makefile index 7f293b0431fe..d20e9d2725b8 100644 --- a/Makefile +++ b/Makefile @@ -609,6 +609,7 @@ ifeq ($(KBUILD_EXTMOD),) init-y := init/ drivers-y := drivers/ sound/ drivers-$(CONFIG_SAMPLES) += samples/ +drivers-$(CONFIG_KERNEL_HEADER_TEST) += include/ net-y := net/ libs-y := lib/ core-y := usr/ diff --git a/include/Kbuild b/include/Kbuild new file mode 100644 index ..4f9524d92a75 --- /dev/null +++ b/include/Kbuild @@ -0,0 +1,1253 @@ +# SPDX-License-Identifier: GPL-2.0-only + +# The following are excluded for now because they fail to build. +# +# Do not add a new header to the blacklist without legitimate reason. +# Please consider to fix the header first. +# +# Sorted alphabetically. +header-test- += acpi/acbuffer.h +header-test- += acpi/acpi.h +header-test- += acpi/acpi_bus.h +header-test- += acpi/acpi_drivers.h +header-test- += acpi/acpi_io.h +header-test- += acpi/acpi_lpat.h +header-test- += acpi/acpiosxf.h +header-test- += acpi/acpixf.h +header-test- += acpi/acrestyp.h +header-test- += acpi/actbl.h +header-test- += acpi/actbl1.h +header-test- += acpi/actbl2.h +header-test- += acpi/actbl3.h +header-test- += acpi/actypes.h +header-test- += acpi/battery.h +header-test- += acpi/cppc_acpi.h +header-test- += acpi/nfit.h +header-test- += acpi/platform/acenv.h +header-test- += acpi/platform/acenvex.h +header-test- += acpi/platform/acintel.h +header-test- += acpi/platform/aclinux.h +header-test- += acpi/platform/aclinuxex.h +header-test- += acpi/processor.h +header-test- += clocksource/timer-sp804.h +header-test- += crypto/cast_common.h +header-test- += crypto/internal/cryptouser.h +header-test- += crypto/pkcs7.h +header-test- += crypto/poly1305.h +header-test- += crypto/sha3.h +header-test- += drm/ati_pcigart.h +header-test- += drm/bridge/dw_hdmi.h +header-test- += drm/bridge/dw_mipi_dsi.h +header-test- += drm/drm_audio_component.h +header-test- += drm/drm_auth.h +header-test- += drm/drm_debugfs.h +header-test- += drm/drm_debugfs_crc.h +header-test- += drm/drm_displayid.h +header-test- += drm/drm_encoder_slave.h +header-test- += drm/drm_fb_cma_helper.h +header-test- += drm/drm_fixed.h +header-test- += drm/drm_format_helper.h +header-test- += drm/drm_lease.h +header-test- += drm/drm_legacy.h +header-test- += drm/drm_panel.h +header-test- += drm/drm_plane_helper.h +header-test- += drm/drm_rect.h +header-test- += drm/i915_component.h +header-test- += drm/intel-gtt.h +header-test- += drm/tinydrm/tinydrm-helpers.h +header-test- += drm/ttm/ttm_debug.h +header-test- += keys/asymmetric-parser.h +header-test- += keys/asymmetric-subtype.h +header-test- += keys/asymmetric-type.h +header-test- += keys/big_key-type.h +header-test- +=
[PATCH 2/7] kbuild: compile-test exported headers to ensure they are self-contained
Multiple people have suggested compile-testing UAPI headers to ensure
they can be really included from user-space. "make headers_check" is
obviously not enough to catch bugs, and we often leak unresolved
references to user-space.
Use the new header-test-y syntax to implement it. Please note exported
headers are compile-tested with a completely different set of compiler
flags. The header search path is set to $(objtree)/usr/include since
exported headers should not include unexported ones.
We use -std=gnu89 for the kernel space since the kernel code highly
depends on GNU extensions. On the other hand, UAPI headers should be
written in more standardized C, so they are compiled with -std=c90.
This will emit errors if C++ style comments, the keyword 'inline', etc.
are used. Please use C style comments (/* ... */), '__inline__', etc.
in UAPI headers.
There is additional compiler requirement to enable this test because
many of UAPI headers include , , ,
etc. directly or indirectly. You cannot use kernel.org pre-built
toolchains [1] since they lack .
I reused CONFIG_CC_CAN_LINK to check the system header availability.
The intention is slightly different, but a compiler that can link
userspace programs provide system headers.
For now, a lot of headers need to be excluded because they cannot
be compiled standalone, but this is a good start point.
[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html
Signed-off-by: Masahiro Yamada
Reviewed-by: Sam Ravnborg
---
Changes in v4:
- Sort the blacklist alphabetically
- Add a little more comments
- Remove scripts/cc-system-headers.sh and reuse CC_CAN_LINK
Changes in v3: None
Changes in v2:
- Add CONFIG_CPU_{BIG,LITTLE}_ENDIAN guard to avoid build error
- Use 'header-test-' instead of 'no-header-test'
- Avoid weird 'find' warning when cleaning
Makefile | 2 +-
init/Kconfig | 10
usr/.gitignore | 1 -
usr/Makefile | 2 +
usr/include/.gitignore | 3 +
usr/include/Makefile | 131 +
6 files changed, 147 insertions(+), 2 deletions(-)
create mode 100644 usr/include/.gitignore
create mode 100644 usr/include/Makefile
diff --git a/Makefile b/Makefile
index 1f35aca4fe05..f23516980796 100644
--- a/Makefile
+++ b/Makefile
@@ -1363,7 +1363,7 @@ CLEAN_DIRS += $(MODVERDIR) include/ksym
CLEAN_FILES += modules.builtin.modinfo
# Directories & files removed with 'make mrproper'
-MRPROPER_DIRS += include/config usr/include include/generated \
+MRPROPER_DIRS += include/config include/generated \
arch/$(SRCARCH)/include/generated .tmp_objdiff
MRPROPER_FILES += .config .config.old .version \
Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
diff --git a/init/Kconfig b/init/Kconfig
index 2e9813daa2c1..74192de8ada6 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -108,6 +108,16 @@ config HEADER_TEST
If you are a developer or tester and want to ensure the requested
headers are self-contained, say Y here. Otherwise, choose N.
+config UAPI_HEADER_TEST
+ bool "Compile test UAPI headers"
+ depends on HEADER_TEST && HEADERS_INSTALL && CC_CAN_LINK
+ help
+ Compile test headers exported to user-space to ensure they are
+ self-contained, i.e. compilable as standalone units.
+
+ If you are a developer or tester and want to ensure the exported
+ headers are self-contained, say Y here. Otherwise, choose N.
+
config LOCALVERSION
string "Local version - append to kernel release"
help
diff --git a/usr/.gitignore b/usr/.gitignore
index 8e48117a3f3d..be5eae1df7eb 100644
--- a/usr/.gitignore
+++ b/usr/.gitignore
@@ -7,4 +7,3 @@ initramfs_data.cpio.gz
initramfs_data.cpio.bz2
initramfs_data.cpio.lzma
initramfs_list
-include
diff --git a/usr/Makefile b/usr/Makefile
index 4a70ae43c9cb..6a89eb019275 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -56,3 +56,5 @@ $(deps_initramfs): klibcdirs
$(obj)/$(datafile_y): $(obj)/gen_init_cpio $(deps_initramfs) klibcdirs
$(Q)$(initramfs) -l $(ramfs-input) > $(obj)/$(datafile_d_y)
$(call if_changed,initfs)
+
+subdir-$(CONFIG_UAPI_HEADER_TEST) += include
diff --git a/usr/include/.gitignore b/usr/include/.gitignore
new file mode 100644
index ..a0991ff4402b
--- /dev/null
+++ b/usr/include/.gitignore
@@ -0,0 +1,3 @@
+*
+!.gitignore
+!Makefile
diff --git a/usr/include/Makefile b/usr/include/Makefile
new file mode 100644
index ..0f9f92c6016a
--- /dev/null
+++ b/usr/include/Makefile
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+# Unlike the kernel space, exported headers are written in standard C.
+# - Forbid C++ style comments
+# - Use '__inline__', '__asm__' instead of 'inline', 'asm'
+#
+# -std=c90 (equivalent to -ansi) catches the violation of those.
+# We cannot go as far as adding -Wpedantic since it emits too many warnings.
[PATCH 3/7] kbuild: do not create wrappers for header-test-y
header-test-y does not work with headers in sub-directories.
For example, you may want to write a Makefile, like this:
include/linux/Kbuild:
header-test-y += mtd/nand.h
This entry will create a wrapper include/linux/mtd/nand.hdrtest.c
with the following content:
#include "mtd/nand.h"
To make this work, we need to add $(srctree)/include/linux to the
header search path. It would be tedious to add ccflags-y.
Instead, we could change the *.hdrtest.c rule to wrap:
#include "nand.h"
This works for in-tree build since #include "..." searches in the
relative path from the header with this directive. For O=... build,
we need to add $(srctree)/include/linux/mtd to the header search path,
which will be even more tedious.
After all, I thought it would be handier to compile headers directly
without creating wrappers.
I added a new build rule to compile %.h into %.h.s
The target is %.h.s instead of %.h.o because it is slightly faster.
Also, as for GCC, an empty assembly is smaller than an empty object.
I wrote the build rule:
$(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<
instead of:
$(CC) $(c_flags) -S -o $@ -x c $<
Both work fine with GCC, but the latter is bad for Clang.
This comes down to the difference in the -Wunused-function policy.
GCC does not warn about unused 'static inline' functions at all.
Clang does not warn about the ones in included headers, but does
about the ones in the source. So, we should handle headers as
headers, not as source files.
In fact, this has been hidden since commit abb2ea7dfd82 ("compiler,
clang: suppress warning for unused static inline functions"), but we
should not rely on that.
Signed-off-by: Masahiro Yamada
Acked-by: Jani Nikula
Tested-by: Jani Nikula
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch
.gitignore | 1 -
Documentation/dontdiff | 1 -
Documentation/kbuild/makefiles.txt | 3 +--
Makefile | 1 -
scripts/Makefile.build | 10 +-
scripts/Makefile.lib | 2 +-
6 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/.gitignore b/.gitignore
index 4bb60f0fa23b..7587ef56b92d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,7 +22,6 @@
*.elf
*.gcno
*.gz
-*.hdrtest.c
*.i
*.ko
*.lex.c
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 554dfe4883d2..5eba889ea84d 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -19,7 +19,6 @@
*.grep
*.grp
*.gz
-*.hdrtest.c
*.html
*.i
*.jpeg
diff --git a/Documentation/kbuild/makefiles.txt
b/Documentation/kbuild/makefiles.txt
index ca4b24ec0399..5080fec34609 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1023,8 +1023,7 @@ When kbuild executes, the following steps are followed
(roughly):
header-test-y specifies headers (*.h) in the current directory that
should be compile tested to ensure they are self-contained,
i.e. compilable as standalone units. If CONFIG_HEADER_TEST is enabled,
- this autogenerates dummy sources to include the headers, and builds them
- as part of extra-y.
+ this builds them as part of extra-y.
--- 6.7 Commands useful for building a boot image
diff --git a/Makefile b/Makefile
index f23516980796..7f293b0431fe 100644
--- a/Makefile
+++ b/Makefile
@@ -1648,7 +1648,6 @@ clean: $(clean-dirs)
-o -name '*.dwo' -o -name '*.lst' \
-o -name '*.su' \
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
- -o -name '*.hdrtest.c' \
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
-o -name '*.asn1.[ch]' \
-o -name '*.symtypes' -o -name 'modules.order' \
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index ee0319560513..776842b7e6a3 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -294,14 +294,14 @@ quiet_cmd_cc_lst_c = MKLST $@
$(obj)/%.lst: $(src)/%.c FORCE
$(call if_changed_dep,cc_lst_c)
-# Dummy C sources for header test (header-test-y target)
+# header test (header-test-y target)
# ---
-quiet_cmd_header_test = HDRTEST $@
- cmd_header_test = echo "\#include \"$*.h\"" > $@
+quiet_cmd_cc_s_h = CC $@
+ cmd_cc_s_h = $(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<
-$(obj)/%.hdrtest.c:
- $(call cmd,header_test)
+$(obj)/%.h.s: $(src)/%.h FORCE
+ $(call if_changed_dep,cc_s_h)
# Compile assembler sources (.S)
# ---
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 3e630fcaffd1..55ae1ec65342 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -67,7 +67,7 @@ extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml,
$(dtb-))
endif
# Test self-contained headers
[PATCH 1/7] init/Kconfig: add CONFIG_CC_CAN_LINK
Currently, scripts/cc-can-link.sh is run just for BPFILTER_UMH, but defining CC_CAN_LINK will be useful in other places. Signed-off-by: Masahiro Yamada --- Changes in v4: - New patch Changes in v3: None Changes in v2: None init/Kconfig | 3 +++ net/bpfilter/Kconfig | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index df5bba27e3fe..2e9813daa2c1 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -24,6 +24,9 @@ config CLANG_VERSION int default $(shell,$(srctree)/scripts/clang-version.sh $(CC)) +config CC_CAN_LINK + def_bool $(success,$(srctree)/scripts/cc-can-link.sh $(CC)) + config CC_HAS_ASM_GOTO def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC)) diff --git a/net/bpfilter/Kconfig b/net/bpfilter/Kconfig index 91f9d878165e..fed9290e3b41 100644 --- a/net/bpfilter/Kconfig +++ b/net/bpfilter/Kconfig @@ -9,7 +9,7 @@ menuconfig BPFILTER if BPFILTER config BPFILTER_UMH tristate "bpfilter kernel module with user mode helper" - depends on $(success,$(srctree)/scripts/cc-can-link.sh $(CC)) + depends on CC_CAN_LINK default m help This builds bpfilter kernel module with embedded user mode helper -- 2.17.1
[PATCH 4/7] kbuild: support header-test-pattern-y
In my view, most of headers can be self-contained. So, it would be tedious to add every header to header-test-y explicitly. We usually end up with "all headers with some exceptions". There are two types in exceptions: [1] headers that are never compiled as standalone units For examples, include/linux/compiler-gcc.h is not intended for direct inclusion. We should always exclude such ones. [2] headers that are conditionally compiled as standalone units Some headers can be compiled only for particular architectures. For example, include/linux/arm-cci.h can be compiled only for arm/arm64 because it requires to exist. Clang can compile include/soc/nps/mtm.h only for arc because it contains an arch-specific register in inline assembler. So, you can write Makefile like this: header-test-+= linux/compiler-gcc.h header-test-$(CONFIG_ARM) += linux/arm-cci.h header-test-$(CONFIG_ARM64) += linux/arm-cci.h header-test-$(CONFIG_ARC) += soc/nps/mtm.h The new syntax header-test-pattern-y will be useful to specify "the rest". The typical usage is like this: header-test-pattern-y += */*.h This will add all the headers in sub-directories to the test coverage, excluding $(header-test-). In this regards, header-test-pattern-y behaves like a weaker variant of header-test-y. Caveat: The patterns in header-test-pattern-y are prefixed with $(srctree)/$(src)/ but not $(objtree)/$(obj)/. Stale generated headers are often left over when you traverse the git history without cleaning. Wildcard patterns for $(objtree) may match to stale headers, which could fail to compile. One pitfall is $(srctree)/$(src)/ and $(objtree)/$(obj)/ point to the same directory for in-tree building. So, header-test-pattern-y should be used with care since it can potentially match to stale headers. Caveat2: You could use wildcard for header-test-. For example, header-test- += asm-generic/% ... will exclude headers in asm-generic directory. Unfortunately, the wildcard character is '%' instead of '*' here because this is evaluated by $(filter-out ...) whereas header-test-pattern-y is evaluated by $(wildcard ...). This is a kludge, but seems useful in some places... Signed-off-by: Masahiro Yamada Tested-by: Jani Nikula --- Changes in v4: None Changes in v3: None Changes in v2: - New patch Documentation/kbuild/makefiles.txt | 10 ++ scripts/Makefile.lib | 11 +++ 2 files changed, 21 insertions(+) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 5080fec34609..b817e6cefb77 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1025,6 +1025,16 @@ When kbuild executes, the following steps are followed (roughly): i.e. compilable as standalone units. If CONFIG_HEADER_TEST is enabled, this builds them as part of extra-y. +header-test-pattern-y + + This works as a weaker version of header-test-y, and accepts wildcard + patterns. The typical usage is: + + header-test-pattern-y += *.h + + This specifies all the files that matches to '*.h' in the current + directory, but the files in 'header-test-' are excluded. + --- 6.7 Commands useful for building a boot image Kbuild provides a few macros that are useful when building a diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 55ae1ec65342..281864fcf0fe 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -67,6 +67,17 @@ extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-)) endif # Test self-contained headers + +# Wildcard searches in $(srctree)/$(src)/, but not in $(objtree)/$(obj)/. +# Stale generated headers are often left over, so pattern matching should +# be avoided. Please notice $(srctree)/$(src)/ and $(objtree)/$(obj) point +# to the same location for in-tree building. So, header-test-pattern-y should +# be used with care. +header-test-y += $(filter-out $(header-test-), \ + $(patsubst $(srctree)/$(src)/%, %, \ + $(wildcard $(addprefix $(srctree)/$(src)/, \ + $(header-test-pattern-y) + extra-$(CONFIG_HEADER_TEST) += $(addsuffix .s, $(header-test-y)) # Add subdir path -- 2.17.1
[PATCH 6/7] kheaders: include only headers into kheaders_data.tar.xz
Currently, kheaders_data.tar.xz contains some build scripts as well as headers. None of them is needed in the header archive. For ARCH=x86, this commit excludes the following from the archive: arch/x86/include/asm/Kbuild arch/x86/include/uapi/asm/Kbuild include/asm-generic/Kbuild include/config/auto.conf include/config/kernel.release include/config/tristate.conf include/uapi/asm-generic/Kbuild include/uapi/Kbuild kernel/gen_kheaders.sh This change is actually motivated for the planned header compile-testing because it will generate more build artifacts, which should not be included in the archive. Signed-off-by: Masahiro Yamada --- Changes in v4: - New patch Changes in v3: None Changes in v2: None kernel/gen_kheaders.sh | 47 ++ 1 file changed, 16 insertions(+), 31 deletions(-) diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh index 86a666f5cb17..9ff449888d9c 100755 --- a/kernel/gen_kheaders.sh +++ b/kernel/gen_kheaders.sh @@ -4,24 +4,12 @@ # This script generates an archive consisting of kernel headers # for CONFIG_IKHEADERS. set -e -spath="$(dirname "$(readlink -f "$0")")" -kroot="$spath/.." +sfile="$(readlink -f "$0")" outdir="$(pwd)" tarfile=$1 cpio_dir=$outdir/$tarfile.tmp -# Script filename relative to the kernel source root -# We add it to the archive because it is small and any changes -# to this script will also cause a rebuild of the archive. -sfile="$(realpath --relative-to $kroot "$(readlink -f "$0")")" - -src_file_list=" -include/ -arch/$SRCARCH/include/ -$sfile -" - -obj_file_list=" +dir_list=" include/ arch/$SRCARCH/include/ " @@ -33,33 +21,29 @@ arch/$SRCARCH/include/ # Uncomment it for debugging. # if [ ! -f /tmp/iter ]; then iter=1; echo 1 > /tmp/iter; # else iter=$(($(cat /tmp/iter) + 1)); echo $iter > /tmp/iter; fi -# find $src_file_list -type f | xargs ls -l > /tmp/src-ls-$iter -# find $obj_file_list -type f | xargs ls -l > /tmp/obj-ls-$iter +# find $src_file_list -name "*.h" | xargs ls -l > /tmp/src-ls-$iter +# find $obj_file_list -name "*.h" | xargs ls -l > /tmp/obj-ls-$iter # include/generated/compile.h is ignored because it is touched even when none # of the source files changed. This causes pointless regeneration, so let us # ignore them for md5 calculation. -pushd $kroot > /dev/null -src_files_md5="$(find $src_file_list -type f | +pushd $srctree > /dev/null +src_files_md5="$(find $dir_list -name "*.h" | grep -v "include/generated/compile.h" | grep -v "include/generated/autoconf.h" | - grep -v "include/config/auto.conf" | - grep -v "include/config/auto.conf.cmd" | - grep -v "include/config/tristate.conf" | xargs ls -l | md5sum | cut -d ' ' -f1)" popd > /dev/null -obj_files_md5="$(find $obj_file_list -type f | +obj_files_md5="$(find $dir_list -name "*.h" | grep -v "include/generated/compile.h" | grep -v "include/generated/autoconf.h" | - grep -v "include/config/auto.conf" | - grep -v "include/config/auto.conf.cmd" | - grep -v "include/config/tristate.conf" | xargs ls -l | md5sum | cut -d ' ' -f1)" - +# Any changes to this script will also cause a rebuild of the archive. +this_file_md5="$(ls -l $sfile | md5sum | cut -d ' ' -f1)" if [ -f $tarfile ]; then tarfile_md5="$(md5sum $tarfile | cut -d ' ' -f1)"; fi if [ -f kernel/kheaders.md5 ] && [ "$(cat kernel/kheaders.md5|head -1)" == "$src_files_md5" ] && [ "$(cat kernel/kheaders.md5|head -2|tail -1)" == "$obj_files_md5" ] && + [ "$(cat kernel/kheaders.md5|head -3|tail -1)" == "$this_file_md5" ] && [ "$(cat kernel/kheaders.md5|tail -1)" == "$tarfile_md5" ]; then exit fi @@ -71,16 +55,16 @@ fi rm -rf $cpio_dir mkdir $cpio_dir -pushd $kroot > /dev/null -for f in $src_file_list; - do find "$f" ! -name "*.cmd" ! -name ".*"; +pushd $srctree > /dev/null +for f in $dir_list; + do find "$f" -name "*.h"; done | cpio --quiet -pd $cpio_dir popd > /dev/null # The second CPIO can complain if files already exist which can # happen with out of tree builds. Just silence CPIO for now. -for f in $obj_file_list; - do find "$f" ! -name "*.cmd" ! -name ".*"; +for f in $dir_list; + do find "$f" -name "*.h"; done | cpio --quiet -pd $cpio_dir >/dev/null 2>&1 # Remove comments except SDPX lines @@ -91,6 +75,7 @@ tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null echo "$src_files_md5" > kernel/kheaders.md5 echo "$obj_files_md5" >> kernel/kheaders.md5 +echo "$this_file_md5" >> kernel/kheaders.md5 echo "$(md5sum $tarfile | cut -d ' ' -f1)" >> kernel/kheaders.md5 rm -rf $cpio_dir --
[PATCH 5/7] kheaders: remove meaningless -R option of 'ls'
The -R option of 'ls' is supposed to be used for directories. -R, --recursive list subdirectories recursively Since 'find ... -type f' only matches to regular files, we do not expect directories passed to the 'ls' command here. Giving -R is harmless at least, but unneeded. Signed-off-by: Masahiro Yamada --- Changes in v4: - New patch Changes in v3: None Changes in v2: None kernel/gen_kheaders.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh index 9a34e1d9bd7f..86a666f5cb17 100755 --- a/kernel/gen_kheaders.sh +++ b/kernel/gen_kheaders.sh @@ -33,8 +33,8 @@ arch/$SRCARCH/include/ # Uncomment it for debugging. # if [ ! -f /tmp/iter ]; then iter=1; echo 1 > /tmp/iter; # else iter=$(($(cat /tmp/iter) + 1)); echo $iter > /tmp/iter; fi -# find $src_file_list -type f | xargs ls -lR > /tmp/src-ls-$iter -# find $obj_file_list -type f | xargs ls -lR > /tmp/obj-ls-$iter +# find $src_file_list -type f | xargs ls -l > /tmp/src-ls-$iter +# find $obj_file_list -type f | xargs ls -l > /tmp/obj-ls-$iter # include/generated/compile.h is ignored because it is touched even when none # of the source files changed. This causes pointless regeneration, so let us @@ -46,7 +46,7 @@ src_files_md5="$(find $src_file_list -type f | grep -v "include/config/auto.conf" | grep -v "include/config/auto.conf.cmd" | grep -v "include/config/tristate.conf" | - xargs ls -lR | md5sum | cut -d ' ' -f1)" + xargs ls -l | md5sum | cut -d ' ' -f1)" popd > /dev/null obj_files_md5="$(find $obj_file_list -type f | grep -v "include/generated/compile.h" | @@ -54,7 +54,7 @@ obj_files_md5="$(find $obj_file_list -type f | grep -v "include/config/auto.conf" | grep -v "include/config/auto.conf.cmd" | grep -v "include/config/tristate.conf" | - xargs ls -lR | md5sum | cut -d ' ' -f1)" + xargs ls -l | md5sum | cut -d ' ' -f1)" if [ -f $tarfile ]; then tarfile_md5="$(md5sum $tarfile | cut -d ' ' -f1)"; fi if [ -f kernel/kheaders.md5 ] && -- 2.17.1
[PATCH 1/2] staging: mt7621-dts: update sdhci config.
The mtk-sd driver has been updated to support
the IP in the mt7621, so update our configuration
to work with it.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-dts/mt7621.dtsi | 41 +++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 9c90cac82efc..549ff5a0699e 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -43,6 +43,30 @@
clock-frequency = <22000>;
};
+ mmc_clock: mmc_clock@0 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <4800>;
+ };
+
+ mmc_fixed_3v3: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "mmc_power";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ mmc_fixed_1v8_io: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "mmc_io";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
palmbus: palmbus@1E00 {
compatible = "palmbus";
reg = <0x1E00 0x10>;
@@ -299,9 +323,24 @@
sdhci: sdhci@1E13 {
status = "disabled";
- compatible = "ralink,mt7620-sdhci";
+ compatible = "mediatek,mt7620-mmc";
reg = <0x1E13 0x4000>;
+ bus-width = <4>;
+ max-frequency = <4800>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ vmmc-supply = <_fixed_3v3>;
+ vqmmc-supply = <_fixed_1v8_io>;
+ disable-wp;
+
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins>;
+
+ clocks = <_clock _clock>;
+ clock-names = "source", "hclk";
+
interrupt-parent = <>;
interrupts = ;
};
[PATCH 0/2] staging: update mt7621 dts for some recent driver changes
The mt7621 MMC driver was recently removed from staging due to copyright concerns. Since then drivers/mmc/host/mtk-sd.c has been enhanced to work with the mt7621 IP. The first patch updates the dts file to match this driver. Earlier, the drivers/net/ethernet/mediatek/ driver was enhanced to work with mt7621 hardware and the mt7621-eth driver was removed from staging. The second patch enhances the mt7621.dtsi to better support this driver and particularly to allow the second network port to be used in at least one of its possible configurations. Thanks, NeilBrown --- NeilBrown (2): staging: mt7621-dts: update sdhci config. staging: mt7621-dts: add support for second network interface drivers/staging/mt7621-dts/Kconfig |7 drivers/staging/mt7621-dts/Makefile|1 + drivers/staging/mt7621-dts/gbpc1.dts |2 + drivers/staging/mt7621-dts/gbpc2.dts | 21 + drivers/staging/mt7621-dts/mt7621.dtsi | 53 +--- 5 files changed, 77 insertions(+), 7 deletions(-) create mode 100644 drivers/staging/mt7621-dts/gbpc2.dts -- Signature
[PATCH 2/2] staging: mt7621-dts: add support for second network interface
The mt7621 has two network interfaces, one that connects to an
internal switch, and one that can connect to either that switch
or an external phy, or possibly an internal phy.
The Gnubee-PC2 has an external phy for use with the second interface.
This patch add some support for the second interface to mt7621.dtsi
and add a gbpc2.dts which makes use of this. This allows the second
interface to be used.
I don't fully understand how to configure this interface - the
documentation is thin - so there could well be room for improvement
here.
Signed-off-by: NeilBrown
---
drivers/staging/mt7621-dts/Kconfig |7 ++-
drivers/staging/mt7621-dts/Makefile|1 +
drivers/staging/mt7621-dts/gbpc1.dts |2 +-
drivers/staging/mt7621-dts/gbpc2.dts | 21 +
drivers/staging/mt7621-dts/mt7621.dtsi | 12
5 files changed, 37 insertions(+), 6 deletions(-)
create mode 100644 drivers/staging/mt7621-dts/gbpc2.dts
diff --git a/drivers/staging/mt7621-dts/Kconfig
b/drivers/staging/mt7621-dts/Kconfig
index 3ea08ab9d0d3..6932ab7acadf 100644
--- a/drivers/staging/mt7621-dts/Kconfig
+++ b/drivers/staging/mt7621-dts/Kconfig
@@ -1,6 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
config DTB_GNUBEE1
- bool "GnuBee1 NAS"
+ bool "GnuBee1 2.5inch NAS"
+ depends on SOC_MT7621 && DTB_RT_NONE
+ select BUILTIN_DTB
+
+config DTB_GNUBEE2
+ bool "GnuBee2 3.5inch NAS"
depends on SOC_MT7621 && DTB_RT_NONE
select BUILTIN_DTB
diff --git a/drivers/staging/mt7621-dts/Makefile
b/drivers/staging/mt7621-dts/Makefile
index aeec48a4edc7..b4ab99fed932 100644
--- a/drivers/staging/mt7621-dts/Makefile
+++ b/drivers/staging/mt7621-dts/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_DTB_GNUBEE1) += gbpc1.dtb
+dtb-$(CONFIG_DTB_GNUBEE2) += gbpc2.dtb
obj-y += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index 250c15ace2a7..1fb560ff059c 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -119,7 +119,7 @@
{
state_default: pinctrl0 {
- gpio {
+ default_gpio: gpio {
groups = "wdt", "rgmii2", "uart3";
function = "gpio";
};
diff --git a/drivers/staging/mt7621-dts/gbpc2.dts
b/drivers/staging/mt7621-dts/gbpc2.dts
new file mode 100644
index ..52760e7351f6
--- /dev/null
+++ b/drivers/staging/mt7621-dts/gbpc2.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+#include "gbpc1.dts"
+
+/ {
+ compatible = "gnubee,gb-pc2", "mediatek,mt7621-soc";
+ model = "GB-PC2";
+};
+
+_gpio {
+ groups = "wdt", "uart3";
+ function = "gpio";
+};
+
+ {
+ status = "ok";
+};
+
+_external {
+ status = "ok";
+};
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 549ff5a0699e..a4c08110094b 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -427,16 +427,20 @@
compatible = "mediatek,eth-mac";
reg = <1>;
status = "off";
- phy-mode = "rgmii";
- phy-handle = <>;
+ phy-mode = "rgmii-rxid";
+ phy-handle = <_external>;
};
mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
- phy5: ethernet-phy@5 {
+ phy_external: ethernet-phy@5 {
+ status = "off";
reg = <5>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-rxid";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
};
switch0: switch0@0 {
[PATCH v3] rcu: Change return type of rcu_spawn_one_boost_kthread()
Hello,
I tested again if the WARN_ON_ONCE() is fired with my box.
And it was OK.
Thanks,
Byungchul
Changes from v2
-. Port the patch to a1af11a24cb0 (Paul's request)
-. Add a few new lines for a better look
Changes from v1
-. WARN_ON_ONCE() on failing to create rcu_boost_kthread.
-. Changed title and commit message a bit.
---8<---
>From 20c934c5657a7a0f13ebb050ffd350d4174965d0 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Mon, 1 Jul 2019 09:27:15 +0900
Subject: [PATCH v3] rcu: Change return type of rcu_spawn_one_boost_kthread()
The return value of rcu_spawn_one_boost_kthread() is not used any
longer. Change return type of that function from int to void.
Signed-off-by: Byungchul Park
---
kernel/rcu/tree_plugin.h | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index c588ef9..b8eea22 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1119,7 +1119,7 @@ static void rcu_preempt_boost_start_gp(struct rcu_node
*rnp)
* already exist. We only create this kthread for preemptible RCU.
* Returns zero if all is well, a negated errno otherwise.
*/
-static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
+static void rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
{
int rnp_index = rnp - rcu_get_root();
unsigned long flags;
@@ -1127,25 +1127,27 @@ static int rcu_spawn_one_boost_kthread(struct rcu_node
*rnp)
struct task_struct *t;
if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
- return 0;
+ return;
if (!rcu_scheduler_fully_active || rcu_rnp_online_cpus(rnp) == 0)
- return 0;
+ return;
rcu_state.boost = 1;
+
if (rnp->boost_kthread_task != NULL)
- return 0;
+ return;
+
t = kthread_create(rcu_boost_kthread, (void *)rnp,
"rcub/%d", rnp_index);
- if (IS_ERR(t))
- return PTR_ERR(t);
+ if (WARN_ON_ONCE(IS_ERR(t)))
+ return;
+
raw_spin_lock_irqsave_rcu_node(rnp, flags);
rnp->boost_kthread_task = t;
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
sp.sched_priority = kthread_prio;
sched_setscheduler_nocheck(t, SCHED_FIFO, );
wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
- return 0;
}
/*
@@ -1186,7 +1188,7 @@ static void __init rcu_spawn_boost_kthreads(void)
struct rcu_node *rnp;
rcu_for_each_leaf_node(rnp)
- (void)rcu_spawn_one_boost_kthread(rnp);
+ rcu_spawn_one_boost_kthread(rnp);
}
static void rcu_prepare_kthreads(int cpu)
@@ -1196,7 +1198,7 @@ static void rcu_prepare_kthreads(int cpu)
/* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
if (rcu_scheduler_fully_active)
- (void)rcu_spawn_one_boost_kthread(rnp);
+ rcu_spawn_one_boost_kthread(rnp);
}
#else /* #ifdef CONFIG_RCU_BOOST */
--
1.9.1
Re: [PATCH] docs: ipmb: place it at driver-api and convert to ReST
On Sat, Jun 29, 2019 at 07:36:46AM -0300, Mauro Carvalho Chehab wrote:
> No new doc should be added at the main Documentation/ directory.
>
> Instead, new docs should be added as ReST files, within the
> Kernel documentation body.
Got it, thanks.
-corey
>
> Fixes: 51bd6f291583 ("Add support for IPMB driver")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/driver-api/index.rst| 1 +
> .../{IPMB.txt => driver-api/ipmb.rst} | 62 ++-
> 2 files changed, 33 insertions(+), 30 deletions(-)
> rename Documentation/{IPMB.txt => driver-api/ipmb.rst} (71%)
>
> diff --git a/Documentation/driver-api/index.rst
> b/Documentation/driver-api/index.rst
> index e33849b948c7..e49c34bf16c0 100644
> --- a/Documentation/driver-api/index.rst
> +++ b/Documentation/driver-api/index.rst
> @@ -75,6 +75,7 @@ available subsections can be seen below.
> dell_rbu
> edid
> eisa
> + ipmb
> isa
> isapnp
> generic-counter
> diff --git a/Documentation/IPMB.txt b/Documentation/driver-api/ipmb.rst
> similarity index 71%
> rename from Documentation/IPMB.txt
> rename to Documentation/driver-api/ipmb.rst
> index cd20c9764705..3ec3baed84c4 100644
> --- a/Documentation/IPMB.txt
> +++ b/Documentation/driver-api/ipmb.rst
> @@ -32,11 +32,11 @@ This driver works with the I2C driver and a userspace
> program such as OpenIPMI:
>
> 1) It is an I2C slave backend driver. So, it defines a callback
> -function to set the Satellite MC as an I2C slave.
> -This callback function handles the received IPMI requests.
> + function to set the Satellite MC as an I2C slave.
> + This callback function handles the received IPMI requests.
>
> 2) It defines the read and write functions to enable a user
> -space program (such as OpenIPMI) to communicate with the kernel.
> + space program (such as OpenIPMI) to communicate with the kernel.
>
>
> Load the IPMB driver
> @@ -48,34 +48,35 @@ CONFIG_IPMB_DEVICE_INTERFACE=y
>
> 1) If you want the driver to be loaded at boot time:
>
> -a) Add this entry to your ACPI table, under the appropriate SMBus:
> +a) Add this entry to your ACPI table, under the appropriate SMBus::
>
> -Device (SMB0) // Example SMBus host controller
> -{
> - Name (_HID, "") // Vendor-Specific HID
> - Name (_UID, 0) // Unique ID of particular host controller
> - :
> - :
> -Device (IPMB)
> -{
> - Name (_HID, "IPMB0001") // IPMB device interface
> - Name (_UID, 0) // Unique device identifier
> -}
> -}
> + Device (SMB0) // Example SMBus host controller
> + {
> + Name (_HID, "") // Vendor-Specific HID
> + Name (_UID, 0) // Unique ID of particular host controller
> + :
> + :
> + Device (IPMB)
> + {
> + Name (_HID, "IPMB0001") // IPMB device interface
> + Name (_UID, 0) // Unique device identifier
> + }
> + }
>
> -b) Example for device tree:
> +b) Example for device tree::
>
> - {
> - status = "okay";
> + {
> +status = "okay";
>
> - ipmb@10 {
> - compatible = "ipmb-dev";
> - reg = <0x10>;
> - };
> -};
> +ipmb@10 {
> +compatible = "ipmb-dev";
> +reg = <0x10>;
> +};
> + };
>
> -2) Manually from Linux:
> -modprobe ipmb-dev-int
> +2) Manually from Linux::
> +
> + modprobe ipmb-dev-int
>
>
> Instantiate the device
> @@ -86,15 +87,16 @@ described in
> 'Documentation/i2c/instantiating-devices.rst'.
> If you have multiple BMCs, each connected to your Satellite MC via
> a different I2C bus, you can instantiate a device for each of
> those BMCs.
> +
> The name of the instantiated device contains the I2C bus number
> -associated with it as follows:
> +associated with it as follows::
>
> -BMC1 -- IPMB/I2C bus 1 -| /dev/ipmb-1
> + BMC1 -- IPMB/I2C bus 1 -| /dev/ipmb-1
> Satellite MC
> -BMC1 -- IPMB/I2C bus 2 -| /dev/ipmb-2
> + BMC1 -- IPMB/I2C bus 2 -| /dev/ipmb-2
>
> For instance, you can instantiate the ipmb-dev-int device from
> -user space at the 7 bit address 0x10 on bus 2:
> +user space at the 7 bit address 0x10 on bus 2::
>
># echo ipmb-dev 0x1010 > /sys/bus/i2c/devices/i2c-2/new_device
>
> --
> 2.21.0
>
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Re: [PATCH 11/12] iomap: move the xfs writeback code to iomap.c
On Fri, Jun 28, 2019 at 07:33:20AM +0200, Christoph Hellwig wrote: > On Fri, Jun 28, 2019 at 10:45:42AM +1000, Dave Chinner wrote: > > You've already mentioned two new users you want to add. I don't even > > have zone capable hardware here to test one of the users you are > > indicating will use this code, and I suspect that very few people > > do. That's a non-trivial increase in testing requirements for > > filesystem developers and distro QA departments who will want to > > change and/or validate this code path. > > Why do you assume you have to test it? Back when we shared > generic_file_read with everyone you also didn't test odd change to > it with every possible fs. I'm not sure what function you are referring to here. Can you clarify? > If you change iomap.c, you'll test it > with XFS, and Cc other maintainers so that they get a chance to > also test it and comment on it, just like we do with other shared > code in the kernel. Which is why we've had problems with the generic code paths in the past and other filesystems just copy and paste then before making signficant modifications. e.g. both ext4 and btrfs re-implement write_cache_pages() rather than use the generic writeback code because they have slightly different requirements and those developers don't want to have to worry about other filesystems every time there is an internal filesystem change that affects their writeback constraints... That's kinda what I'm getting at here: writeback isn't being shared by any of the major filesystems for good reasons... > > Indeed, integrating gfs2 into the existing generic iomap code has > > required quite a bit of munging and adding new code paths and so on. > > That's mostly been straight forward because it's just been adding > > flags and conditional code to the existing paths. The way we > > regularly rewrite sections of the XFS writeback code is a very > > different sort of modification, and one that will be much harder to > > do if we have to make those changes to generic code. > > As the person who has done a lot of the recent rewriting of the > writeback code I disagree. Most of it has been do divorce is from > leftovers of the buffer_head based sinle page at a time design from > stone age. Very little is about XFS itself, most of it has been > about not being stupid in a fairly generic way. And every since > I got rid of buffer heads xfs_aops.c has been intimately tied ^ *cough* Getting rid of bufferheads in writeback was largely a result of work I did over a period of several years, thank you very much. Yes, work you did over the same time period also got us there, but it's not all your work. > into the iomap infrastructure, and I'd rather keep those details in > one place. I.e. with this series now XFS doesn't even need to know > about the details of the iomap_page structure and the uptodate > bits. If for example I'd want to add sub-page dirty bits (which I > don't if I can avoid it) I can handle this entirely in iomap now > instead of spreading around iomap, xfs and duplicating the thing > in every copy of the XFS code that would otherwise show up. Yes, I understand your motivations, I'm just not convinced that it is the right thing to do given the history of this code and the history of filesystem writeback code in general > > i.e. shared code is good if it's simple and doesn't have a lot of > > external dependencies that restrict the type and scope of > > modifications that can be made easily. Shared code that is complex > > and comes from code that was tightly integrated with a specific > > subsystem architecture is going to carry all those architectural > > foilbles into the new "generic" code. Once it gets sufficient > > users it's going to end up with the same "we can't change this code" > > problems that we had with the existing IO path, and we'll go back to > > implementing our own writeback path > > From the high level POV I agree with your stance. But the point is > that the writeback code is not tightly integrated with xfs, and that Except it is > is why I don't want it in XFS. It is on other other hand very > tightly integrated with the iomap buffer read and write into pagecache > code, which is why I want to keep it together with that. It's not tightly integrated into the iomap read side or page cache implementations. Writeback currently gets a dirty page, we look up a block map, we add it to/create a cached ioend/bio pair. There are four lines of code in the entire XFS writeback code path that interact with iomap specific state, and that's the grand total of interactions needed to support block size < page size writeback. IOWs, we barely interact with the page cache or page/iomap state at all in writeback anymore - we just write whole pages based on the current inode extent map state. Yes, the writepage context, the ioends and the extent map structures we use to implement this can be made generic, but it's all
Re: [PATCH v2] rcu: Change return type of rcu_spawn_one_boost_kthread()
On Sun, Jun 30, 2019 at 12:38:34PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 11:43:39AM +0900, Byungchul Park wrote:
> > On Thu, Jun 27, 2019 at 01:57:03PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 09:42:40AM -0400, Joel Fernandes wrote:
> > > > On Thu, Jun 27, 2019 at 04:07:46PM +0900, Byungchul Park wrote:
> > > > > Hello,
> > > > >
> > > > > I tested if the WARN_ON_ONCE() is fired with my box and it was ok.
> > > >
> > > > Looks pretty safe to me and nice clean up!
> > > >
> > > > Acked-by: Joel Fernandes (Google)
> > >
> > > Agreed, but I still cannot find where this applies. I did try rcu/next,
> > > which is currently here:
> > >
> > > commit b989ff070574ad8b8621d866de0a8e9a65d42c80 (rcu/rcu/next, rcu/next)
> > > Merge: 4289ee7d5a83 11ca7a9d541d
> > > Author: Paul E. McKenney
> > > Date: Mon Jun 24 09:12:39 2019 -0700
> > >
> > > Merge LKMM and RCU commits
> > >
> > > Help?
> >
> > commit 204d7a60670f3f6399a4d0826667ab7863b3e429
> >
> > Merge LKMM and RCU commits
> >
> > I made it on top of the above. And could you tell me which branch I'd
> > better use when developing. I think it's been changing sometimes.
>
> That would be because idiot here took so much care to avoid risking
> pushing some early development commits into the upcoming merge window
> that he managed to misplace them entirely. The -rcu tree's "dev" branch
> now includes them. Could you please port to it?
Of course, I can.
> a1af11a24cb0 ("rcu/nocb: Make __call_rcu_nocb_wake() safe for many callbacks")
>
> > Thank you for the answer in advance!
>
> And please accept my apologies for the very confusing tree layout this
> time around!
It would be totally OK if you give me the answer when I feel confused
with branch for development. :)
>
> Thanx, Paul
Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
On Fri, Jun 28, 2019 at 11:44:11AM -0400, Steven Rostedt wrote: > On Fri, 28 Jun 2019 19:40:45 +0900 > Byungchul Park wrote: > > > Wait.. I got a little bit confused on recordering. > > > > This 'STORE rcu_read_lock_nesting = 0' can happen before > > 'STORE rcu_read_unlock_special.b.exp_hint = false' regardless of the > > order a compiler generated to by the barrier(), because anyway they > > are independent so it's within an arch's right. > > > > Then.. is this scenario possible? Or all archs properly deal with > > interrupts across this kind of reordering? > > As Paul stated, interrupts are synchronization points. Archs can only > play games with ordering when dealing with entities outside the CPU > (devices and other CPUs). But if you have assembly that has two stores, > and an interrupt comes in, the arch must guarantee that the stores are > done in that order as the interrupt sees it. > > If this is not the case, there's a hell of a lot more broken in the > kernel than just this, and "barrier()" would also be meaningless, as > that is used mostly to deal with interrupts. Clear. Dear Paul and Steve, Thank you. > -- Steve
[PATCH] net: usb: asix: init MAC address buffers
This is for fixing bug KMSAN: uninit-value in ax88772_bind Tested by https://groups.google.com/d/msg/syzkaller-bugs/aFQurGotng4/cFe9nxMCCwAJ Reported-by: syzbot+8a3fc6674bbc3978e...@syzkaller.appspotmail.com syzbot found the following crash on: HEAD commit:f75e4cfe kmsan: use kmsan_handle_urb() in urb.c git tree: kmsan console output: https://syzkaller.appspot.com/x/log.txt?x=136d720ea0 kernel config: https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a dashboard link: https://syzkaller.appspot.com/bug?extid=8a3fc6674bbc3978ed4e compiler: clang version 9.0.0 (/home/glider/llvm/clang 06d00afa61eef8f7f501ebdb4e8612ea43ec2d78) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12788316a0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120359aaa0 == BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:200 [inline] BUG: KMSAN: uninit-value in asix_set_netdev_dev_addr drivers/net/usb/asix_devices.c:73 [inline] BUG: KMSAN: uninit-value in ax88772_bind+0x93d/0x11e0 drivers/net/usb/asix_devices.c:724 CPU: 0 PID: 3348 Comm: kworker/0:2 Not tainted 5.1.0+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310 is_valid_ether_addr include/linux/etherdevice.h:200 [inline] asix_set_netdev_dev_addr drivers/net/usb/asix_devices.c:73 [inline] ax88772_bind+0x93d/0x11e0 drivers/net/usb/asix_devices.c:724 usbnet_probe+0x10f5/0x3940 drivers/net/usb/usbnet.c:1728 usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361 really_probe+0xdae/0x1d80 drivers/base/dd.c:513 driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x454/0x730 drivers/base/dd.c:844 device_initial_probe+0x4a/0x60 drivers/base/dd.c:891 bus_probe_device+0x137/0x390 drivers/base/bus.c:514 device_add+0x288d/0x30e0 drivers/base/core.c:2106 usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266 really_probe+0xdae/0x1d80 drivers/base/dd.c:513 driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x454/0x730 drivers/base/dd.c:844 device_initial_probe+0x4a/0x60 drivers/base/dd.c:891 bus_probe_device+0x137/0x390 drivers/base/bus.c:514 device_add+0x288d/0x30e0 drivers/base/core.c:2106 usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432 process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x189c/0x2460 kernel/workqueue.c:2417 kthread+0x4b5/0x4f0 kernel/kthread.c:254 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Signed-off-by: Phong Tran --- drivers/net/usb/asix_devices.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c index c9bc96310ed4..f514d19316b1 100644 --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -230,6 +230,7 @@ static int ax88172_bind(struct usbnet *dev, struct usb_interface *intf) int i; unsigned long gpio_bits = dev->driver_info->data; + memset(buf, 0, sizeof(buf)); usbnet_get_endpoints(dev,intf); /* Toggle the GPIOs in a manufacturer/model specific way */ @@ -681,6 +682,7 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf) u32 phyid; struct asix_common_private *priv; + memset(buf, 0, sizeof(buf)); usbnet_get_endpoints(dev, intf); /* Maybe the boot loader passed the MAC address via device tree */ @@ -1063,6 +1065,7 @@ static int ax88178_bind(struct usbnet *dev, struct usb_interface *intf) int ret; u8 buf[ETH_ALEN]; + memset(buf, 0, sizeof(buf)); usbnet_get_endpoints(dev,intf); /* Get the MAC address */ -- 2.11.0
High quality PCB
Dear Purchasing Mangager: Nice day! Thanks for your time to read my email.I'm Eva,from Shenzhen ZDCL Trade Co., Ltd,who learns your contact information from internet.We mainly manufacture and export in PCB copy board and PCBA OEM generation of material.Main Printed circuit board,PCB design,IC decryption,prototype production debugging,motherboards copy board. If you are interested in our business,you can contact us any time.wish our products will be helpful for your business. Eva Company name：Shenzhen ZDCL Trade Co., Ltd. Mail：18475635...@163.com Skype：+8618475635876 Wechat：18475635876
Re: [PATCH] block: fix a crash in do_task_dead()
On Wed, 5 Jun 2019, Jens Axboe wrote:
>
> How about the following plan - if folks are happy with this sched patch,
> we can queue it up for 5.3. Once that is in, I'll kill the block change
> that special cases the polled task wakeup. For 5.2, we go with Oleg's
> patch for the swap case.
I just hit the do_task_dead() kernel BUG at kernel/sched/core.c:3463!
while heavy swapping on 5.2-rc7: it looks like Oleg's patch intended
for 5.2 was not signed off, and got forgotten.
I did hit the do_task_dead() BUG (but not at all easily) on early -rcs
before seeing Oleg's patch, then folded it in and and didn't hit the BUG
again; then just tried again without it, and luckily hit in a few hours.
So I can give it an enthusiastic
Acked-by: Hugh Dickins
because it makes good sense to avoid the get/blk_wake/put overhead on
the asynch path anyway, even if it didn't work around a bug; but only
Half-Tested-by: Hugh Dickins
since I have not been exercising the synchronous path at all.
Hugh, requoting Oleg:
>
> I don't understand this code at all but I am just curious, can we do
> something like incomplete patch below ?
>
> Oleg.
>
> --- x/mm/page_io.c
> +++ x/mm/page_io.c
> @@ -140,8 +140,10 @@ int swap_readpage(struct page *page, bool synchronous)
> unlock_page(page);
> WRITE_ONCE(bio->bi_private, NULL);
> bio_put(bio);
> - blk_wake_io_task(waiter);
> - put_task_struct(waiter);
> + if (waiter) {
> + blk_wake_io_task(waiter);
> + put_task_struct(waiter);
> + }
> }
>
> int generic_swapfile_activate(struct swap_info_struct *sis,
> @@ -398,11 +400,12 @@ int swap_readpage(struct page *page, boo
>* Keep this task valid during swap readpage because the oom killer may
>* attempt to access it in the page fault retry time check.
>*/
> - get_task_struct(current);
> - bio->bi_private = current;
> bio_set_op_attrs(bio, REQ_OP_READ, 0);
> - if (synchronous)
> + if (synchronous) {
> bio->bi_opf |= REQ_HIPRI;
> + get_task_struct(current);
> + bio->bi_private = current;
> + }
> count_vm_event(PSWPIN);
> bio_get(bio);
> qc = submit_bio(bio);
[PATCH] dmaengine: dma-jz4780: Break descriptor chains on JZ4740
The current driver works perfectly fine on every generation of the
JZ47xx SoCs, except on the JZ4740.
There, when hardware descriptors are chained together (with the LINK
bit set), the next descriptor isn't automatically fetched as it should -
instead, an interrupt is raised, even if the TIE bit (Transfer Interrupt
Enable) bit is cleared. When it happens, the DMA transfer seems to be
stopped (it doesn't chain), and it's uncertain how many bytes have
actually been transferred.
Until somebody smarter than me can figure out how to make chained
descriptors work on the JZ4740, we now disable chained descriptors on
that particular SoC.
Signed-off-by: Paul Cercueil
---
drivers/dma/dma-jz4780.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c
index 263bee76ef0d..aae83389cc10 100644
--- a/drivers/dma/dma-jz4780.c
+++ b/drivers/dma/dma-jz4780.c
@@ -92,6 +92,7 @@
#define JZ_SOC_DATA_PROGRAMMABLE_DMA BIT(1)
#define JZ_SOC_DATA_PER_CHAN_PMBIT(2)
#define JZ_SOC_DATA_NO_DCKES_DCKEC BIT(3)
+#define JZ_SOC_DATA_BREAK_LINKSBIT(4)
/**
* struct jz4780_dma_hwdesc - descriptor structure read by the DMA controller.
@@ -356,6 +357,7 @@ static struct dma_async_tx_descriptor
*jz4780_dma_prep_slave_sg(
void *context)
{
struct jz4780_dma_chan *jzchan = to_jz4780_dma_chan(chan);
+ struct jz4780_dma_dev *jzdma = jz4780_dma_chan_parent(jzchan);
struct jz4780_dma_desc *desc;
unsigned int i;
int err;
@@ -376,7 +378,8 @@ static struct dma_async_tx_descriptor
*jz4780_dma_prep_slave_sg(
desc->desc[i].dcm |= JZ_DMA_DCM_TIE;
- if (i != (sg_len - 1)) {
+ if (i != (sg_len - 1) &&
+ !(jzdma->soc_data->flags & JZ_SOC_DATA_BREAK_LINKS)) {
/* Automatically proceeed to the next descriptor. */
desc->desc[i].dcm |= JZ_DMA_DCM_LINK;
@@ -665,6 +668,7 @@ static enum dma_status jz4780_dma_tx_status(struct dma_chan
*chan,
static bool jz4780_dma_chan_irq(struct jz4780_dma_dev *jzdma,
struct jz4780_dma_chan *jzchan)
{
+ struct jz4780_dma_desc *desc = jzchan->desc;
uint32_t dcs;
bool ack = true;
@@ -692,8 +696,10 @@ static bool jz4780_dma_chan_irq(struct jz4780_dma_dev
*jzdma,
jz4780_dma_begin(jzchan);
} else if (dcs & JZ_DMA_DCS_TT) {
- vchan_cookie_complete(>desc->vdesc);
- jzchan->desc = NULL;
+ if (jzchan->curr_hwdesc + 1 == desc->count) {
+ vchan_cookie_complete(>vdesc);
+ jzchan->desc = NULL;
+ }
jz4780_dma_begin(jzchan);
} else {
@@ -994,6 +1000,7 @@ static int jz4780_dma_remove(struct platform_device *pdev)
static const struct jz4780_dma_soc_data jz4740_dma_soc_data = {
.nb_channels = 6,
.transfer_ord_max = 5,
+ .flags = JZ_SOC_DATA_BREAK_LINKS,
};
static const struct jz4780_dma_soc_data jz4725b_dma_soc_data = {
--
2.21.0.593.g511ec345e18
linux-next: manual merge of the dma-mapping tree with Linus' tree
Hi all,
Today's linux-next merge of the dma-mapping tree got a conflict in:
include/linux/genalloc.h
between commit:
795ee30648c7 ("lib/genalloc: introduce chunk owners")
from Linus' tree and commit:
cf394fc5f715 ("lib/genalloc.c: Add algorithm, align and zeroed family of DMA
allocators")
from the dma-mapping tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/genalloc.h
index 205f62b8d291,ed641337df87..
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@@ -122,47 -116,21 +122,56 @@@ static inline int gen_pool_add(struct g
return gen_pool_add_virt(pool, addr, -1, size, nid);
}
extern void gen_pool_destroy(struct gen_pool *);
-extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
-extern unsigned long gen_pool_alloc_algo(struct gen_pool *, size_t,
- genpool_algo_t algo, void *data);
+unsigned long gen_pool_alloc_algo_owner(struct gen_pool *pool, size_t size,
+ genpool_algo_t algo, void *data, void **owner);
+
+static inline unsigned long gen_pool_alloc_owner(struct gen_pool *pool,
+ size_t size, void **owner)
+{
+ return gen_pool_alloc_algo_owner(pool, size, pool->algo, pool->data,
+ owner);
+}
+
+static inline unsigned long gen_pool_alloc_algo(struct gen_pool *pool,
+ size_t size, genpool_algo_t algo, void *data)
+{
+ return gen_pool_alloc_algo_owner(pool, size, algo, data, NULL);
+}
+
+/**
+ * gen_pool_alloc - allocate special memory from the pool
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ */
+static inline unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
+{
+ return gen_pool_alloc_algo(pool, size, pool->algo, pool->data);
+}
+
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
+ extern void *gen_pool_dma_alloc_algo(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma, genpool_algo_t algo, void *data);
+ extern void *gen_pool_dma_alloc_align(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma, int align);
+ extern void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
+ extern void *gen_pool_dma_zalloc_algo(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma, genpool_algo_t algo, void *data);
+ extern void *gen_pool_dma_zalloc_align(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma, int align);
-extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
+extern void gen_pool_free_owner(struct gen_pool *pool, unsigned long addr,
+ size_t size, void **owner);
+static inline void gen_pool_free(struct gen_pool *pool, unsigned long addr,
+size_t size)
+{
+ gen_pool_free_owner(pool, addr, size, NULL);
+}
+
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
extern size_t gen_pool_avail(struct gen_pool *);
pgp1g8elZ96i3.pgp
Description: OpenPGP digital signature
Re: [PATCH 4/4] drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
On Sun, Jun 30, 2019 at 2:58 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> On Sun, Jun 30, 2019 at 02:50:59PM -0700, Rob Clark wrote:
> > On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart wrote:
> > > On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > Use the drm_of_find_panel_id() helper to decide which endpoint to use
> > > > when looking up panel. This way we can support devices that have
> > > > multiple possible panels, such as the aarch64 laptops.
> > > >
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > index 2719d9c0864b..56c66a43f1a6 100644
> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > @@ -790,7 +790,7 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > > *client,
> > > > const struct i2c_device_id *id)
> > > > {
> > > > struct ti_sn_bridge *pdata;
> > > > - int ret;
> > > > + int ret, panel_id;
> > > >
> > > > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> > > > DRM_ERROR("device doesn't support I2C\n");
> > > > @@ -811,7 +811,8 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > > *client,
> > > >
> > > > pdata->dev = >dev;
> > > >
> > > > - ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
> > > > + panel_id = drm_of_find_panel_id();
> > > > + ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1,
> > > > panel_id,
> > > > >panel, NULL);
> > > > if (ret) {
> > > > DRM_ERROR("could not find any panel node\n");
> > >
> > > No, I'm sorry, but that's a no-go. We can't patch every single bridge
> > > driver to support this hack. We need a solution implemented at another
> > > level that will not spread throughout the whole subsystem.
> >
> > it could be possible to make a better helper.. but really there aren't
> > *that* many bridge drivers
> >
> > suggestions ofc welcome, but I think one way or another we are going
> > to need to patch bridges by the time we get to adding ACPI support, so
> > really trivial couple line patches to the handful of bridges we have
> > isn't really something that worries me
>
> It's only one right now as that's the only one you care about, but
> before we'll have time to blink, it will be another one, and another
> one, ... Sorry, that's a no-go for me.
I could ofc add helper call to all the existing bridges.. that seemed
a bit overkill for v1 patchset
BR,
-R
Re: [PATCH 4/4] drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
Hi Rob,
On Sun, Jun 30, 2019 at 02:50:59PM -0700, Rob Clark wrote:
> On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart wrote:
> > On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Use the drm_of_find_panel_id() helper to decide which endpoint to use
> > > when looking up panel. This way we can support devices that have
> > > multiple possible panels, such as the aarch64 laptops.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 2719d9c0864b..56c66a43f1a6 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -790,7 +790,7 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > *client,
> > > const struct i2c_device_id *id)
> > > {
> > > struct ti_sn_bridge *pdata;
> > > - int ret;
> > > + int ret, panel_id;
> > >
> > > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> > > DRM_ERROR("device doesn't support I2C\n");
> > > @@ -811,7 +811,8 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > *client,
> > >
> > > pdata->dev = >dev;
> > >
> > > - ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
> > > + panel_id = drm_of_find_panel_id();
> > > + ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, panel_id,
> > > >panel, NULL);
> > > if (ret) {
> > > DRM_ERROR("could not find any panel node\n");
> >
> > No, I'm sorry, but that's a no-go. We can't patch every single bridge
> > driver to support this hack. We need a solution implemented at another
> > level that will not spread throughout the whole subsystem.
>
> it could be possible to make a better helper.. but really there aren't
> *that* many bridge drivers
>
> suggestions ofc welcome, but I think one way or another we are going
> to need to patch bridges by the time we get to adding ACPI support, so
> really trivial couple line patches to the handful of bridges we have
> isn't really something that worries me
It's only one right now as that's the only one you care about, but
before we'll have time to blink, it will be another one, and another
one, ... Sorry, that's a no-go for me.
--
Regards,
Laurent Pinchart
Re: [PATCH 4/4] drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Use the drm_of_find_panel_id() helper to decide which endpoint to use
> > when looking up panel. This way we can support devices that have
> > multiple possible panels, such as the aarch64 laptops.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index 2719d9c0864b..56c66a43f1a6 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -790,7 +790,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > struct ti_sn_bridge *pdata;
> > - int ret;
> > + int ret, panel_id;
> >
> > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> > DRM_ERROR("device doesn't support I2C\n");
> > @@ -811,7 +811,8 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> >
> > pdata->dev = >dev;
> >
> > - ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
> > + panel_id = drm_of_find_panel_id();
> > + ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, panel_id,
> > >panel, NULL);
> > if (ret) {
> > DRM_ERROR("could not find any panel node\n");
>
> No, I'm sorry, but that's a no-go. We can't patch every single bridge
> driver to support this hack. We need a solution implemented at another
> level that will not spread throughout the whole subsystem.
>
it could be possible to make a better helper.. but really there aren't
*that* many bridge drivers
suggestions ofc welcome, but I think one way or another we are going
to need to patch bridges by the time we get to adding ACPI support, so
really trivial couple line patches to the handful of bridges we have
isn't really something that worries me
BR,
-R
linux-next: Fixes tag needs some work in the sound-asoc tree
Hi all,
In commit
8a90efd15ef6 ("ASoC: vc4: vc4_htmi: consider CPU-Platform possibility")
Fixes tag
Fixes: commit 6c6de1c9e2bf2 ("ASoC: vc4: vc4_hdmi: don't select unnecessary
Platform")
has these problem(s):
- leading word 'commit' unexpected
This as also the case for the whole follogin series of commits :-(
--
Cheers,
Stephen Rothwell
pgpeKT23h6d0f.pgp
Description: OpenPGP digital signature
Re: [PATCH v9 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
Hi Vishal,
a few questions below about the SLBF error management.
On 11/06/19 12:10, Vishal Sagar wrote:
> The Xilinx MIPI CSI-2 Rx Subsystem soft IP is used to capture images
> from MIPI CSI-2 camera sensors and output AXI4-Stream video data ready
> for image processing. Please refer to PG232 for details.
>
> The driver is used to set the number of active lanes, if enabled
> in hardware. The CSI2 Rx controller filters out all packets except for
> the packets with data type fixed in hardware. RAW8 packets are always
> allowed to pass through.
>
> It is also used to setup and handle interrupts and enable the core. It
> logs all the events in respective counters between streaming on and off.
>
> The driver supports only the video format bridge enabled configuration.
> Some data types like YUV 422 10bpc, RAW16, RAW20 are supported when the
> CSI v2.0 feature is enabled in design. When the VCX feature is enabled,
> the maximum number of virtual channels becomes 16 from 4.
>
> Signed-off-by: Vishal Sagar
> Reviewed-by: Hyun Kwon
...
> --- /dev/null
> +++ b/drivers/media/platform/xilinx/xilinx-csi2rxss.c
...
> +/**
> + * xcsi2rxss_irq_handler - Interrupt handler for CSI-2
> + * @irq: IRQ number
> + * @dev_id: Pointer to device state
> + *
> + * In the interrupt handler, a list of event counters are updated for
> + * corresponding interrupts. This is useful to get status / debug.
> + *
> + * In case of stream line buffer full condition, the IP is reset, stopped and
> + * an event is raised.
> + *
> + * Return: IRQ_HANDLED after handling interrupts
> + * IRQ_NONE is no interrupts
> + */
> +static irqreturn_t xcsi2rxss_irq_handler(int irq, void *dev_id)
> +{
> + struct xcsi2rxss_state *state = (struct xcsi2rxss_state *)dev_id;
> + struct xcsi2rxss_core *core = >core;
> + u32 status;
> +
> + status = xcsi2rxss_read(core, XCSI_ISR_OFFSET) & XCSI_ISR_ALLINTR_MASK;
> + dev_dbg_ratelimited(core->dev, "interrupt status = 0x%08x\n", status);
> +
> + if (!status)
> + return IRQ_NONE;
> +
> + /* Received a short packet */
> + if (status & XCSI_ISR_SPFIFONE) {
> + dev_dbg_ratelimited(core->dev, "Short packet = 0x%08x\n",
> + xcsi2rxss_read(core, XCSI_SPKTR_OFFSET));
> + }
> +
> + /* Short packet FIFO overflow */
> + if (status & XCSI_ISR_SPFIFOF)
> + dev_alert_ratelimited(core->dev, "Short packet FIFO
> overflowed\n");
> +
> + /*
> + * Stream line buffer full
> + * This means there is a backpressure from downstream IP
> + */
> + if (status & XCSI_ISR_SLBF) {
> + dev_alert_ratelimited(core->dev, "Stream Line Buffer Full!\n");
> + if (core->rst_gpio) {
> + gpiod_set_value(core->rst_gpio, 1);
> + /* minimum 40 dphy_clk_200M cycles */
> + ndelay(250);
> + gpiod_set_value(core->rst_gpio, 0);
> + }
> + xcsi2rxss_stop_stream(state);
I've been hit by the dreadful "Stream Line Buffer Full" error, getting
the CSI-2 RX completely stuck in SLBF and not transmitting any frames
sporadically after glitches in the incoming MIPI stream. And I found
that adding xcsi2rxss_start_stream() here just after
xcsi2rxss_stop_stream() allows to continue the stream with almost no
interruption and without userspace intervention.
Do you think this is a reliable solution, or does it have side-effects I
didn't encounter? Note I'm not using pm nor the ctrls, so register
writes are limited to the enable/disable code paths.
Does video_aresetn also reset registers?
BTW in my code I also moved xcsi2rxss_stop_stream() before the if
(core->rst_gpio) {}. There is no strong reason for this, I didn't
observe any functional difference, it just looks
more logical to me to stop the IP before resetting it.
...
> +static int xcsi2rxss_probe(struct platform_device *pdev)
> +{
> + struct v4l2_subdev *subdev;
> + struct xcsi2rxss_state *xcsi2rxss;
> + struct xcsi2rxss_core *core;
> + struct resource *res;
> + int ret, num_ctrls, i;
> +
> + xcsi2rxss = devm_kzalloc(>dev, sizeof(*xcsi2rxss), GFP_KERNEL);
> + if (!xcsi2rxss)
> + return -ENOMEM;
> +
> + core = >core;
> + core->dev = >dev;
> +
> + core->clks = devm_kmemdup(core->dev, xcsi2rxss_clks,
> + sizeof(xcsi2rxss_clks), GFP_KERNEL);
> + if (!core->clks)
> + return -ENOMEM;
> +
> + /* Reset GPIO */
> + core->rst_gpio = devm_gpiod_get_optional(core->dev, "reset",
> + GPIOD_OUT_HIGH);
Is GPIOD_OUT_HIGH correct? video_aresetn is active low.
> + if (IS_ERR(core->rst_gpio)) {
> + if (PTR_ERR(core->rst_gpio) != -EPROBE_DEFER)
> + dev_err(core->dev, "Video Reset GPIO not setup in DT");
> + return PTR_ERR(core->rst_gpio);
> + }
> +
> +
linux-next: Fixes tag needs some work in the wireless-drivers-next tree
Hi all,
In commit
d923cf6bc38a ("mt76: mt7615: fix sparse warnings: warning: cast from
restricted __le16")
Fixes tag
Fixes: 3ca0a6f6e9df ("mt7615: mcu: use standard signature for
mt7615_mcu_msg_send")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: 516c3e380533 ("mt7615: mcu: use standard signature for
mt7615_mcu_msg_send")
In commit
eda96044de27 ("mt76: mt7615: fix sparse warnings: incorrect type in
assignment (different base types)")
Fixes tag
Fixes: 7339fbc0caa5 ("mt7615: mcu: do not use function pointers whenever
possible")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: 1ca8089a55ee ("mt7615: mcu: do not use function pointers whenever
possible")
In commit
1a09d9e0e5f0 ("mt76: mt7615: fix incorrect settings in mesh mode")
Fixes tag
Fixes: f072c7ba2150 ("mt76: mt7615: enable support for mesh")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh")
--
Cheers,
Stephen Rothwell
pgpfN5SDxSxs5.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the net-next tree
Hi all,
In commit
18d219b783da ("net: hns3: fix a -Wformat-nonliteral compile warning")
Fixes tag
Fixes: 46a3df9f9718 ("Add HNS3 Acceleration Engine & Compatibility Layer
Support")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
pgphy8eeNaqPy.pgp
Description: OpenPGP digital signature
