Re: Old platforms: bring out your dead
On Sat, Jan 9, 2021 at 9:21 PM Baruch Siach wrote: > > Hi Arnd, > > On Sat, Jan 09 2021, Arnd Bergmann wrote: > > * digicolor -- added in 2014, no notable changes after 2015 > > I have access to the hardware and I'm still interested in maintaining > mainline kernel support for it. Ok, dropping it from the list, thanks for your reply! Arnd
Re: Old platforms: bring out your dead
On Sat, Jan 9, 2021 at 6:34 PM Florian Fainelli wrote: > On 1/8/2021 2:55 PM, Arnd Bergmann wrote: > > * bcm/kona -- added in 2013, no notable changes after 2014 > > I have a development board that I occasionally turn on for testing > upstream kernels, it has not broken in a while which is why it did not > get much updates. I don't feel strongly with respect to keep it or > dropping it though. Does that include all Kona-family SoCs or just one of them? I see Kconfig listing bcm23550, bcm2166x and five variants of bcm281xx. We've seen a bit of a comeback of older phones making it into mainline, so it's possible this platform might see a revival as well. I now found a list of phones with partial postmarketos support [1] and ongoing work as of last year. Let's leave it untouched for now and see if any of those make it upstream. If only the reference boards are supported and nobody wants to use new kernels on commercial hardware in a few years, we can then remove it. Arnd [1] https://wiki.postmarketos.org/wiki/Broadcom_chipsets
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Sat, Jan 9, 2021 at 3:55 AM Drew Fustini wrote: > I discussed my use case and this patch on #armlinux earlier this week > and Alexandre Belloni suggested looking at the pinmux-pins debugfs file. This sounds reasonable. > This made me think that a possible solution could be to define a store > function for pinmux-pins to handle something like " ". > I believe the ability to activate a pin function (or pin group) from > userspace would satisfy our beagleboard.org use-case. > > Does that seem like a reasonable approach? This sounds like a good approach. Yours, Linus Walleij
[PATCH] wireguard: netlink: add multicast notification for peer changes
This commit adds a new multicast group to the netlink api for wireguard.
The purpose of this multicast group is to notify userspace when the
peers of an interface change. Right now this is only done when the
endpoint is changed by whatever means.
An example for an consumer of this API would be a service that keeps
track of all peer endpoints and sends this information to the peers.
This would allow NAT-to-NAT connections without the need of using
STUN on each client.
Signed-off-by: Linus Lotz
---
drivers/net/wireguard/netlink.c | 52 -
drivers/net/wireguard/netlink.h | 4 +++
drivers/net/wireguard/socket.c | 4 +++
include/uapi/linux/wireguard.h | 3 ++
4 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index d0f3b6d7f408..88eff0a797f4 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -618,6 +618,12 @@ static const struct genl_ops genl_ops[] = {
}
};
+static struct genl_multicast_group genl_mcgrps[] = {
+ {
+ .name = WG_MULTICAST_GROUP_PEER_CHANGE
+ }
+};
+
static struct genl_family genl_family __ro_after_init = {
.ops = genl_ops,
.n_ops = ARRAY_SIZE(genl_ops),
@@ -626,7 +632,9 @@ static struct genl_family genl_family __ro_after_init = {
.maxattr = WGDEVICE_A_MAX,
.module = THIS_MODULE,
.policy = device_policy,
- .netnsok = true
+ .netnsok = true,
+ .mcgrps = genl_mcgrps,
+ .n_mcgrps = ARRAY_SIZE(genl_mcgrps)
};
int __init wg_genetlink_init(void)
@@ -638,3 +646,45 @@ void __exit wg_genetlink_uninit(void)
{
genl_unregister_family(_family);
}
+
+int wg_genl_mcast_peer_endpoint_change(struct wg_peer *peer)
+{
+ struct sk_buff *skb;
+ void *hdr, *peer_nest, *peer_array_nest;
+ int fail;
+
+ skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+ hdr = genlmsg_put(skb, 0, 0,
+ _family, 0, WG_CMD_CHANGED_PEER);
+
+ nla_put_u32(skb, WGDEVICE_A_IFINDEX, peer->device->dev->ifindex);
+ nla_put_string(skb, WGDEVICE_A_IFNAME, peer->device->dev->name);
+
+ peer_nest = nla_nest_start(skb, WGDEVICE_A_PEERS);
+ peer_array_nest = nla_nest_start(skb, 0);
+ down_read(>handshake.lock);
+ nla_put(skb, WGPEER_A_PUBLIC_KEY, NOISE_PUBLIC_KEY_LEN,
+ peer->handshake.remote_static);
+ up_read(>handshake.lock);
+
+ read_lock_bh(>endpoint_lock);
+ if (peer->endpoint.addr.sa_family == AF_INET)
+ fail = nla_put(skb, WGPEER_A_ENDPOINT,
+ sizeof(peer->endpoint.addr4),
+ >endpoint.addr4);
+ else if (peer->endpoint.addr.sa_family == AF_INET6)
+ fail = nla_put(skb, WGPEER_A_ENDPOINT,
+ sizeof(peer->endpoint.addr6),
+ >endpoint.addr6);
+ read_unlock_bh(>endpoint_lock);
+ if (fail)
+ return fail;
+
+ nla_nest_end(skb, peer_array_nest);
+ nla_nest_end(skb, peer_nest);
+ genlmsg_end(skb, hdr);
+
+ fail = genlmsg_multicast_netns(_family, dev_net(peer->device->dev),
+ skb, 0, 0, GFP_KERNEL);
+ return fail;
+}
diff --git a/drivers/net/wireguard/netlink.h b/drivers/net/wireguard/netlink.h
index 15100d92e2e3..74ecc72a79a6 100644
--- a/drivers/net/wireguard/netlink.h
+++ b/drivers/net/wireguard/netlink.h
@@ -6,6 +6,10 @@
#ifndef _WG_NETLINK_H
#define _WG_NETLINK_H
+#include "peer.h"
+
+int wg_genl_mcast_peer_endpoint_change(struct wg_peer *peer);
+
int wg_genetlink_init(void);
void wg_genetlink_uninit(void);
diff --git a/drivers/net/wireguard/socket.c b/drivers/net/wireguard/socket.c
index 410b318e57fb..d826e1f2b51c 100644
--- a/drivers/net/wireguard/socket.c
+++ b/drivers/net/wireguard/socket.c
@@ -8,6 +8,7 @@
#include "socket.h"
#include "queueing.h"
#include "messages.h"
+#include "netlink.h"
#include
#include
@@ -293,6 +294,9 @@ void wg_socket_set_peer_endpoint(struct wg_peer *peer,
dst_cache_reset(>endpoint_cache);
out:
write_unlock_bh(>endpoint_lock);
+
+ /* We need to notify the netlink listeners for about this change */
+ wg_genl_mcast_peer_endpoint_change(peer);
}
void wg_socket_set_peer_endpoint_from_skb(struct wg_peer *peer,
diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h
index ae88be14c947..22a012644d71 100644
--- a/include/uapi/linux/wireguard.h
+++ b/include/uapi/linux/wireguard.h
@@ -136,9 +136,12 @@
#define WG_KEY_LEN 32
+#define WG_MULTICAST_GROUP_PEER_CHANGE "wg_peer_change"
+
enum wg_cmd {
WG_CMD_GET_DEVICE,
WG_CMD_SET_DEVICE,
+ WG_CMD_CHANGED_PEER,
__WG_CMD_MAX
};
#define WG_CMD_MAX (__WG_CMD_MAX - 1)
--
2.26.2
[ANNOUNCE] erofs-utils: release 1.2.1
Hi folks, A new version erofs-utils 1.2.1 is available at: git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git tags/v1.2.1 This is a quick release addressing recent reported issues since v1.2: - fix reported build issues due to different corner configurations; - (mkfs.erofs, AOSP) fix sub-directory prefix for canned fs_config. Thanks, Gao Xiang
Re: [PATCH] net/ipv6: warning: %u in format string (no. 2) requires 'unsigned int' but the argument type is 'signed int'.
On Thu, 7 Jan 2021 10:47:34 +0800 Jiapeng Zhong wrote: > The print format of this parameter does not match, because it is defined > as int type, so modify the matching format of this parameter to %d format. > > Signed-off-by: Jiapeng Zhong > Reported-by: Abaci > --- > net/ipv6/proc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c > index d6306aa..26c702b 100644 > --- a/net/ipv6/proc.c > +++ b/net/ipv6/proc.c > @@ -169,7 +169,7 @@ static void snmp6_seq_show_icmpv6msg(struct seq_file > *seq, atomic_long_t *smib) > val = atomic_long_read(smib + i); > if (!val) > continue; > - snprintf(name, sizeof(name), "Icmp6%sType%u", > + snprintf(name, sizeof(name), "Icmp6%sType%d", > i & 0x100 ? "Out" : "In", i & 0xff); > seq_printf(seq, "%-32s\t%lu\n", name, val); > } Type can't be negative, there is no reason for @i to be signed. Changing type of @i sounds like a better idea.
WARNING in rds_rdma_extra_size
Hello,
syzbot found the following issue on:
HEAD commit:6207214a Merge tag 'afs-fixes-04012021' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=146967c0d0
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=1bd2b07f93745fa38425
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1351c11f50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1710cb50d0
The issue was bisected to:
commit fdadd04931c2d7cd294dc5b2b342863f94be53a3
Author: Daniel Borkmann
Date: Tue Dec 11 11:14:12 2018 +
bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10056f70d0
final oops: https://syzkaller.appspot.com/x/report.txt?x=12056f70d0
console output: https://syzkaller.appspot.com/x/log.txt?x=14056f70d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1bd2b07f93745fa38...@syzkaller.appspotmail.com
Fixes: fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
[ cut here ]
WARNING: CPU: 1 PID: 8462 at mm/page_alloc.c:4976
__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011
Modules linked in:
CPU: 1 PID: 8462 Comm: syz-executor292 Not tainted 5.11.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976
Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00
48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89
74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
RSP: 0018:c9000169f790 EFLAGS: 00010246
RAX: RBX: 1920002d3ef6 RCX:
RDX: RSI: dc00 RDI: 00040dc0
RBP: 00040dc0 R08: R09:
R10: 81b1f7f1 R11: R12: 0018
R13: 0018 R14: R15: 000ff1f0
FS: 00f3c880() GS:8880b9f0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f6b332916c0 CR3: 133c3000 CR4: 00350ee0
Call Trace:
alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
alloc_pages include/linux/gfp.h:547 [inline]
kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
kmalloc_array include/linux/slab.h:592 [inline]
kcalloc include/linux/slab.h:621 [inline]
rds_rdma_extra_size+0xb2/0x3b0 net/rds/rdma.c:568
rds_rm_size net/rds/send.c:928 [inline]
rds_sendmsg+0x20d7/0x3020 net/rds/send.c:1265
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:672
sys_sendmsg+0x6e8/0x810 net/socket.c:2345
___sys_sendmsg+0xf3/0x170 net/socket.c:2399
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2432
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440359
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffe89376b68 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 00440359
RDX: RSI: 20001600 RDI: 0003
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10: R11: 0246 R12: 00401b60
R13: 00401bf0 R14: R15:
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v2 14/15] cpufreq: qcom-hw: Implement CPRh aware OSM programming
Hi AngeloGioacchino,
I love your patch! Yet something to improve:
[auto build test ERROR on pm/linux-next]
[also build test ERROR on robh/for-next linux/master linus/master v5.11-rc2
next-20210108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/AngeloGioacchino-Del-Regno/Enable-CPRh-3-4-CPU-Scaling-on-various-QCOM-SoCs/20210110-021002
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: arm-randconfig-r022-20210108 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/390ca2a9300484089b567314e6a8c145f0652248
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
AngeloGioacchino-Del-Regno/Enable-CPRh-3-4-CPU-Scaling-on-various-QCOM-SoCs/20210110-021002
git checkout 390ca2a9300484089b567314e6a8c145f0652248
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/math.h:5,
from include/linux/kernel.h:13,
from include/linux/clk.h:13,
from include/linux/cpufreq.h:11,
from drivers/cpufreq/qcom-cpufreq-hw.c:11:
drivers/cpufreq/qcom-cpufreq-hw.c: In function 'qcom_cpufreq_gen_params':
>> arch/arm/include/asm/div64.h:51:36: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
51 | #define do_div(n, base) __div64_32(&(n), base)
|^~~~
||
|u32 * {aka unsigned int *}
drivers/cpufreq/qcom-cpufreq-hw.c:555:3: note: in expansion of macro 'do_div'
555 | do_div(millivolts, 1000);
| ^~
arch/arm/include/asm/div64.h:24:45: note: expected 'uint64_t *' {aka 'long
long unsigned int *'} but argument is of type 'u32 *' {aka 'unsigned int *'}
24 | static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
| ~~^
drivers/cpufreq/qcom-cpufreq-hw.c: In function 'qcom_cpufreq_acd_regbit':
>> arch/arm/include/asm/div64.h:51:36: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
51 | #define do_div(n, base) __div64_32(&(n), base)
|^~~~
||
|u32 * {aka unsigned int *}
drivers/cpufreq/qcom-cpufreq-hw.c:650:2: note: in expansion of macro 'do_div'
650 | do_div(regbit, 4);
| ^~
arch/arm/include/asm/div64.h:24:45: note: expected 'uint64_t *' {aka 'long
long unsigned int *'} but argument is of type 'u32 *' {aka 'unsigned int *'}
24 | static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
| ~~^
drivers/cpufreq/qcom-cpufreq-hw.c: In function 'qcom_cpufreq_hw_read_lut':
>> arch/arm/include/asm/div64.h:51:36: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
51 | #define do_div(n, base) __div64_32(&(n), base)
|^~~~
||
|u32 * {aka unsigned int *}
drivers/cpufreq/qcom-cpufreq-hw.c:1085:3: note: in expansion of macro
'do_div'
1085 | do_div(freq, 1000);
| ^~
arch/arm/include/asm/div64.h:24:45: note: expected 'uint64_t *' {aka 'long
long unsigned int *'} but argument is of type 'u32 *' {aka 'unsigned int *'}
24 | static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
| ~~^
drivers/cpufreq/qcom-cpufreq-hw.c: In function
'qcom_cpufreq_hw_driver_probe':
>> arch/arm/include/asm/div64.h:51:36: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
51 | #define do_div(n, base) __div64_32(&(n), base)
|^~~~
||
|long unsigned int *
drivers/cpufreq/qcom-cpufreq-hw.c:1591:2: note: in expansion of macro
'do_div'
Re: [PATCH] target/file: don't zero iter before iov_iter_bvec
On 1/9/21 12:40, Pavel Begunkov wrote: > I expect you won't find any, but such little things can pile up > into a not-easy-to-spot overhead over time. That is what I suspected with the resulting assembly. The commit log needs to document that there is no direct impact on the performance which can be seen with this patch, but this is nice to have micro-optimization in the long run.
Re: [PATCH v8] iio: Handle enumerated properties with gaps
On Sat, Jan 9, 2021 at 9:23 PM Jonathan Cameron wrote: > > On Thu, 7 Jan 2021 13:20:49 +0200 > Alexandru Ardelean wrote: > > > From: Lars-Peter Clausen > > > > Some enums might have gaps or reserved values in the middle of their value > > range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a > > meaning, but 2 is a reserved value and can not be used. > > > > Add support for such enums to the IIO enum helper functions. A reserved > > values is marked by setting its entry in the items array to NULL rather > > than the normal descriptive string value. > > > > Signed-off-by: Lars-Peter Clausen > > Signed-off-by: Alexandru Ardelean > > Applied to the togreg branch of iio.git and pushed out as testing for all > the normal autobuilder related reasons. > > Note I can still rebase so if anyone wants to add tags or comment it's > not yet too late! Free to add Reviewed-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 0/5] Unify NUMA implementation between ARM64 & RISC-V
On Sun, 13 Dec 2020 17:02:19 PST (-0800), ati...@atishpatra.org wrote: On Wed, Nov 18, 2020 at 4:39 PM Atish Patra wrote: This series attempts to move the ARM64 numa implementation to common code so that RISC-V can leverage that as well instead of reimplementing it again. RISC-V specific bits are based on initial work done by Greentime Hu [1] but modified to reuse the common implementation to avoid duplication. [1] https://lkml.org/lkml/2020/1/10/233 This series has been tested on qemu with numa enabled for both RISC-V & ARM64. It would be great if somebody can test it on numa capable ARM64 hardware platforms. This patch series doesn't modify the maintainers list for the common code (arch_numa) as I am not sure if somebody from ARM64 community or Greg should take up the maintainership. Ganapatrao was the original author of the arm64 version. I would be happy to update that in the next revision once it is decided. # numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 node 0 size: 486 MB node 0 free: 470 MB node 1 cpus: 4 5 6 7 node 1 size: 424 MB node 1 free: 408 MB node distances: node 0 1 0: 10 20 1: 20 10 # numactl -show policy: default preferred node: current physcpubind: 0 1 2 3 4 5 6 7 cpubind: 0 1 nodebind: 0 1 membind: 0 1 The patches are also available at https://github.com/atishp04/linux/tree/5.11_numa_unified_v5 For RISC-V, the following qemu series is a pre-requisite(already available in upstream) https://patchwork.kernel.org/project/qemu-devel/list/?series=303313 Testing: RISC-V: Tested in Qemu and 2 socket OmniXtend FPGA. ARM64: 2 socket kunpeng920 (4 nodes around 250G a node) Tested-by: Jonathan Cameron Changes from v4->v5: 1. Added by Acked-by & Reviewed-by tags. 2. Swapped patch 1 & 2 in v4 version. Changes from v3->v4: 1. Removed redundant duplicate header. 2. Added Reviewed-by tags. Changes from v2->v3: 1. Added Acked-by/Reviewed-by tags. 2. Replaced asm/acpi.h with linux/acpi.h 3. Defined arch_acpi_numa_init as static. Changes from v1->v2: 1. Replaced ARM64 specific compile time protection with ACPI specific ones. 2. Dropped common pcibus_to_node changes. Added required changes in RISC-V. 3. Fixed few typos. Atish Patra (4): arm64, numa: Change the numa init functions name to be generic numa: Move numa implementation to common code riscv: Separate memory init from paging init riscv: Add numa support for riscv64 platform Greentime Hu (1): riscv: Add support pte_protnone and pmd_protnone if CONFIG_NUMA_BALANCING arch/arm64/Kconfig| 1 + arch/arm64/include/asm/numa.h | 48 + arch/arm64/kernel/acpi_numa.c | 12 - arch/arm64/mm/Makefile| 1 - arch/arm64/mm/init.c | 4 +- arch/riscv/Kconfig| 31 ++- arch/riscv/include/asm/mmzone.h | 13 + arch/riscv/include/asm/numa.h | 8 +++ arch/riscv/include/asm/pci.h | 14 + arch/riscv/include/asm/pgtable.h | 21 arch/riscv/kernel/setup.c | 11 +++- arch/riscv/kernel/smpboot.c | 12 - arch/riscv/mm/init.c | 10 +++- drivers/base/Kconfig | 6 +++ drivers/base/Makefile | 1 + .../mm/numa.c => drivers/base/arch_numa.c | 27 -- include/asm-generic/numa.h| 52 +++ 17 files changed, 200 insertions(+), 72 deletions(-) create mode 100644 arch/riscv/include/asm/mmzone.h create mode 100644 arch/riscv/include/asm/numa.h rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (96%) create mode 100644 include/asm-generic/numa.h -- 2.25.1 ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv Hey Palmer, I did not see this series in for-next. Let me know if you need anything else to be done for this series. Sorry about that. It's on for-next, with Randy's comment addressed. There was one merge conflict: we don't have resource_init() in for-next yet (which I think means I missed something else). IDK if that's necessary for the NUMA stuff, I just dropped it. I haven't tested this yet.
Re: upstream build error (11)
On Wed, Oct 28, 2020 at 9:31 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:4d09c1d9 Merge tag 'devicetree-fixes-for-5.10-1' of git://.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1615899c50 > kernel config: https://syzkaller.appspot.com/x/.config?x=a5c844e56cc50cdb > dashboard link: https://syzkaller.appspot.com/bug?extid=5b0d0de84d6c65b8dd2b > compiler: gcc (GCC) 10.1.0-syz 20200507 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+5b0d0de84d6c65b8d...@syzkaller.appspotmail.com > > mm/process_vm_access.c:277:5: error: implicit declaration of function > 'in_compat_syscall'; did you mean 'in_ia32_syscall'? > [-Werror=implicit-function-declaration] Other build failures are piling behind this. #syz fix: mm/process_vm_access: Add missing #include
Re: [PATCH] x86/vm86/32: Remove VM86_SCREEN_BITMAP support
> On Jan 9, 2021, at 12:17 PM, ebied...@xmission.com wrote:
>
> Andy Lutomirski writes:
>
>> The implementation was rather buggy. It unconditionally marked PTEs
>> read-only, even for VM_SHARED mappings. I'm not sure whether this is
>> actually a problem, but it certainly seems unwise. More importantly, it
>> released the mmap lock before flushing the TLB, which could allow a racing
>> CoW operation to falsely believe that the underlying memory was not
>> writable.
>>
>> I can't find any users at all of this mechanism, so just remove it.
>
> In another age this was used by dosemu. Have you looked at dosemu to
> see if it still uses this support (on 32bit where dosemu can use vm86)?
>
> It may still be a valid removal target I just wanted to point out what
> the original user was.
I’m pretty sure that dosemu2 does not use this support. I think the original
dosemu doesn’t either, but I’m also not convinced it has any users at all.
I meant to cc Stas, and I will for v2.
>
> Eric
>
>> Cc: Andrea Arcangeli
>> Cc: Linux-MM
>> Cc: Jason Gunthorpe
>> Cc: x...@kernel.org
>> Cc: Linus Torvalds
>> Cc: Matthew Wilcox
>> Cc: Jann Horn
>> Cc: Jan Kara
>> Cc: Yu Zhao
>> Cc: Peter Xu
>> Signed-off-by: Andy Lutomirski
>> ---
>> arch/x86/include/uapi/asm/vm86.h | 2 +-
>> arch/x86/kernel/vm86_32.c| 55 ++--
>> 2 files changed, 10 insertions(+), 47 deletions(-)
>>
>> diff --git a/arch/x86/include/uapi/asm/vm86.h
>> b/arch/x86/include/uapi/asm/vm86.h
>> index d2ee4e307ef8..50004fb4590d 100644
>> --- a/arch/x86/include/uapi/asm/vm86.h
>> +++ b/arch/x86/include/uapi/asm/vm86.h
>> @@ -106,7 +106,7 @@ struct vm86_struct {
>> /*
>> * flags masks
>> */
>> -#define VM86_SCREEN_BITMAP0x0001
>> +#define VM86_SCREEN_BITMAP0x0001/* no longer supported */
>>
>> struct vm86plus_info_struct {
>>unsigned long force_return_for_pic:1;
>> diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
>> index 764573de3996..28b9e8d511e1 100644
>> --- a/arch/x86/kernel/vm86_32.c
>> +++ b/arch/x86/kernel/vm86_32.c
>> @@ -160,49 +160,6 @@ void save_v86_state(struct kernel_vm86_regs *regs, int
>> retval)
>>do_exit(SIGSEGV);
>> }
>>
>> -static void mark_screen_rdonly(struct mm_struct *mm)
>> -{
>> -struct vm_area_struct *vma;
>> -spinlock_t *ptl;
>> -pgd_t *pgd;
>> -p4d_t *p4d;
>> -pud_t *pud;
>> -pmd_t *pmd;
>> -pte_t *pte;
>> -int i;
>> -
>> -mmap_write_lock(mm);
>> -pgd = pgd_offset(mm, 0xA);
>> -if (pgd_none_or_clear_bad(pgd))
>> -goto out;
>> -p4d = p4d_offset(pgd, 0xA);
>> -if (p4d_none_or_clear_bad(p4d))
>> -goto out;
>> -pud = pud_offset(p4d, 0xA);
>> -if (pud_none_or_clear_bad(pud))
>> -goto out;
>> -pmd = pmd_offset(pud, 0xA);
>> -
>> -if (pmd_trans_huge(*pmd)) {
>> -vma = find_vma(mm, 0xA);
>> -split_huge_pmd(vma, pmd, 0xA);
>> -}
>> -if (pmd_none_or_clear_bad(pmd))
>> -goto out;
>> -pte = pte_offset_map_lock(mm, pmd, 0xA, );
>> -for (i = 0; i < 32; i++) {
>> -if (pte_present(*pte))
>> -set_pte(pte, pte_wrprotect(*pte));
>> -pte++;
>> -}
>> -pte_unmap_unlock(pte, ptl);
>> -out:
>> -mmap_write_unlock(mm);
>> -flush_tlb_mm_range(mm, 0xA, 0xA + 32*PAGE_SIZE, PAGE_SHIFT,
>> false);
>> -}
>> -
>> -
>> -
>> static int do_vm86_irq_handling(int subfunction, int irqnumber);
>> static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus);
>>
>> @@ -282,6 +239,15 @@ static long do_sys_vm86(struct vm86plus_struct __user
>> *user_vm86, bool plus)
>>offsetof(struct vm86_struct, int_revectored)))
>>return -EFAULT;
>>
>> +
>> +/* VM86_SCREEN_BITMAP had numerous bugs and appears to have no users. */
>> +if (v.flags & VM86_SCREEN_BITMAP) {
>> +char comm[TASK_COMM_LEN];
>> +
>> +pr_info_once("vm86: '%s' uses VM86_SCREEN_BITMAP, which is no
>> longer supported\n", get_task_comm(comm, current);
>> +return -EINVAL;
>> +}
>> +
>>memset(, 0, sizeof(vm86regs));
>>
>>vm86regs.pt.bx = v.regs.ebx;
>> @@ -370,9 +336,6 @@ static long do_sys_vm86(struct vm86plus_struct __user
>> *user_vm86, bool plus)
>>update_task_stack(tsk);
>>preempt_enable();
>>
>> -if (vm86->flags & VM86_SCREEN_BITMAP)
>> -mark_screen_rdonly(tsk->mm);
>> -
>>memcpy((struct kernel_vm86_regs *)regs, , sizeof(vm86regs));
>>return regs->ax;
>> }
Sie haben eine Spende von € 5.800.000,00.
Sie haben eine Spende von € 5.800.000,00. von Mavis Wanczyk antworten Sie mit diesem Code [MW530342019], um die Spende zu erhalten Vous avez un don de 5 800 000,00 €. de Mavis Wanczyk répondez avec ce code [MW530342019] pour recevoir le don
Re: [PATCH] target/file: don't zero iter before iov_iter_bvec
On 09/01/2021 20:09, Chaitanya Kulkarni wrote:
> On 1/9/21 07:59, Pavel Begunkov wrote:
>> iov_iter_bvec() initialises iterators well, no need to pre-zero it
>> beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it
>> out and generate extra code for that (confirmed with assembly).
> It will be great if we can quantify this optimization with the actual
> performance
> numbers.
I expect you won't find any, but such little things can pile up
into a not-easy-to-spot overhead over time.
In any case, I don't think this requires performance justification
because it neither makes it less safe or uglier. Those iov_iter*()
are there to handle initialisation, that's a part of the iter API.
>> Signed-off-by: Pavel Begunkov
>> ---
>> drivers/target/target_core_file.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/target/target_core_file.c
>> b/drivers/target/target_core_file.c
>> index cce455929778..5a66854def95 100644
>> --- a/drivers/target/target_core_file.c
>> +++ b/drivers/target/target_core_file.c
>> @@ -267,7 +267,7 @@ fd_execute_rw_aio(struct se_cmd *cmd, struct scatterlist
>> *sgl, u32 sgl_nents,
>> struct fd_dev *fd_dev = FD_DEV(dev);
>> struct file *file = fd_dev->fd_file;
>> struct target_core_file_cmd *aio_cmd;
>> -struct iov_iter iter = {};
>> +struct iov_iter iter;
>> struct scatterlist *sg;
>> ssize_t len = 0;
>> int ret = 0, i;
>
--
Pavel Begunkov
Re: [PATCH 0/6] Add timestamp channel for hid-sensors
On Tue, 5 Jan 2021 17:35:09 +0800 Ye Xiang wrote: > This patch series add a timestamp channel for hid sensors, > including gravity sensor, gyro sensor, magnetometer sensor, > ambient light sensor, inclinometer sensor, and rotation sensor. > > With this patch series, user can get the time when sensor yield > a sample. > > Ye Xiang (6): > iio: hid-sensor-accel-3d: Add timestamp channel for gravity sensor > iio: hid-sensor-gyro-3d: Add timestamp channel > iio: hid-sensor-als: Add timestamp channel > iio: hid-sensor-magn-3d: Add timestamp channel > iio: hid-sensor-incl-3d: Add timestamp channel > iio: hid-sensor-rotation: Add timestamp channel > > drivers/iio/accel/hid-sensor-accel-3d.c | 6 ++- > drivers/iio/gyro/hid-sensor-gyro-3d.c | 40 +--- > drivers/iio/light/hid-sensor-als.c| 39 --- > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 48 --- > drivers/iio/orientation/hid-sensor-incl-3d.c | 43 ++--- > drivers/iio/orientation/hid-sensor-rotation.c | 46 ++ > 6 files changed, 134 insertions(+), 88 deletions(-) Series applied with a bit of fuzz and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan >
Re: [PATCH trivial] MIPS: bitops: Fix reference to ffz location
On Fri, Jan 08, 2021 at 11:55:26AM +0100, Geert Uytterhoeven wrote: > Unlike most other architectures, MIPS defines ffz() below ffs(). > > Signed-off-by: Geert Uytterhoeven > --- > arch/mips/include/asm/bitops.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: Old platforms: bring out your dead
Hi Arnd,
On Sat, Jan 09 2021, Arnd Bergmann wrote:
> * digicolor -- added in 2014, no notable changes after 2015
I have access to the hardware and I'm still interested in maintaining
mainline kernel support for it.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH] x86/vm86/32: Remove VM86_SCREEN_BITMAP support
Andy Lutomirski writes:
> The implementation was rather buggy. It unconditionally marked PTEs
> read-only, even for VM_SHARED mappings. I'm not sure whether this is
> actually a problem, but it certainly seems unwise. More importantly, it
> released the mmap lock before flushing the TLB, which could allow a racing
> CoW operation to falsely believe that the underlying memory was not
> writable.
>
> I can't find any users at all of this mechanism, so just remove it.
In another age this was used by dosemu. Have you looked at dosemu to
see if it still uses this support (on 32bit where dosemu can use vm86)?
It may still be a valid removal target I just wanted to point out what
the original user was.
Eric
> Cc: Andrea Arcangeli
> Cc: Linux-MM
> Cc: Jason Gunthorpe
> Cc: x...@kernel.org
> Cc: Linus Torvalds
> Cc: Matthew Wilcox
> Cc: Jann Horn
> Cc: Jan Kara
> Cc: Yu Zhao
> Cc: Peter Xu
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/include/uapi/asm/vm86.h | 2 +-
> arch/x86/kernel/vm86_32.c| 55 ++--
> 2 files changed, 10 insertions(+), 47 deletions(-)
>
> diff --git a/arch/x86/include/uapi/asm/vm86.h
> b/arch/x86/include/uapi/asm/vm86.h
> index d2ee4e307ef8..50004fb4590d 100644
> --- a/arch/x86/include/uapi/asm/vm86.h
> +++ b/arch/x86/include/uapi/asm/vm86.h
> @@ -106,7 +106,7 @@ struct vm86_struct {
> /*
> * flags masks
> */
> -#define VM86_SCREEN_BITMAP 0x0001
> +#define VM86_SCREEN_BITMAP 0x0001/* no longer supported */
>
> struct vm86plus_info_struct {
> unsigned long force_return_for_pic:1;
> diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
> index 764573de3996..28b9e8d511e1 100644
> --- a/arch/x86/kernel/vm86_32.c
> +++ b/arch/x86/kernel/vm86_32.c
> @@ -160,49 +160,6 @@ void save_v86_state(struct kernel_vm86_regs *regs, int
> retval)
> do_exit(SIGSEGV);
> }
>
> -static void mark_screen_rdonly(struct mm_struct *mm)
> -{
> - struct vm_area_struct *vma;
> - spinlock_t *ptl;
> - pgd_t *pgd;
> - p4d_t *p4d;
> - pud_t *pud;
> - pmd_t *pmd;
> - pte_t *pte;
> - int i;
> -
> - mmap_write_lock(mm);
> - pgd = pgd_offset(mm, 0xA);
> - if (pgd_none_or_clear_bad(pgd))
> - goto out;
> - p4d = p4d_offset(pgd, 0xA);
> - if (p4d_none_or_clear_bad(p4d))
> - goto out;
> - pud = pud_offset(p4d, 0xA);
> - if (pud_none_or_clear_bad(pud))
> - goto out;
> - pmd = pmd_offset(pud, 0xA);
> -
> - if (pmd_trans_huge(*pmd)) {
> - vma = find_vma(mm, 0xA);
> - split_huge_pmd(vma, pmd, 0xA);
> - }
> - if (pmd_none_or_clear_bad(pmd))
> - goto out;
> - pte = pte_offset_map_lock(mm, pmd, 0xA, );
> - for (i = 0; i < 32; i++) {
> - if (pte_present(*pte))
> - set_pte(pte, pte_wrprotect(*pte));
> - pte++;
> - }
> - pte_unmap_unlock(pte, ptl);
> -out:
> - mmap_write_unlock(mm);
> - flush_tlb_mm_range(mm, 0xA, 0xA + 32*PAGE_SIZE, PAGE_SHIFT,
> false);
> -}
> -
> -
> -
> static int do_vm86_irq_handling(int subfunction, int irqnumber);
> static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus);
>
> @@ -282,6 +239,15 @@ static long do_sys_vm86(struct vm86plus_struct __user
> *user_vm86, bool plus)
> offsetof(struct vm86_struct, int_revectored)))
> return -EFAULT;
>
> +
> + /* VM86_SCREEN_BITMAP had numerous bugs and appears to have no users. */
> + if (v.flags & VM86_SCREEN_BITMAP) {
> + char comm[TASK_COMM_LEN];
> +
> + pr_info_once("vm86: '%s' uses VM86_SCREEN_BITMAP, which is no
> longer supported\n", get_task_comm(comm, current);
> + return -EINVAL;
> + }
> +
> memset(, 0, sizeof(vm86regs));
>
> vm86regs.pt.bx = v.regs.ebx;
> @@ -370,9 +336,6 @@ static long do_sys_vm86(struct vm86plus_struct __user
> *user_vm86, bool plus)
> update_task_stack(tsk);
> preempt_enable();
>
> - if (vm86->flags & VM86_SCREEN_BITMAP)
> - mark_screen_rdonly(tsk->mm);
> -
> memcpy((struct kernel_vm86_regs *)regs, , sizeof(vm86regs));
> return regs->ax;
> }
WARNING in bpf_prog_test_run_raw_tp
Hello,
syzbot found the following issue on:
HEAD commit:f6e7a024 Merge tag 'arc-5.11-rc3' of git://git.kernel.org/..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=16f6472b50
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=4f98876664c7337a4ae6
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1004b248d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1773c76750
The issue was bisected to:
commit 1b4d60ec162f82ea29a2e7a907b5c6cc9f926321
Author: Song Liu
Date: Fri Sep 25 20:54:29 2020 +
bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e5b0f750
final oops: https://syzkaller.appspot.com/x/report.txt?x=17e5b0f750
console output: https://syzkaller.appspot.com/x/log.txt?x=13e5b0f750
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4f98876664c7337a4...@syzkaller.appspotmail.com
Fixes: 1b4d60ec162f ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint")
[ cut here ]
WARNING: CPU: 1 PID: 8484 at mm/page_alloc.c:4976
__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011
Modules linked in:
CPU: 1 PID: 8484 Comm: syz-executor862 Not tainted 5.11.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976
Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00
48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89
74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
RSP: 0018:c900012efb10 EFLAGS: 00010246
RAX: RBX: 19200025df66 RCX:
RDX: RSI: dc00 RDI: 00140dc0
RBP: 00140dc0 R08: R09:
R10: 81b1f7e1 R11: R12: 0014
R13: 0014 R14: R15:
FS: 0190c880() GS:8880b9e0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f08b7f316c0 CR3: 12073000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
alloc_pages include/linux/gfp.h:547 [inline]
kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
kmalloc include/linux/slab.h:557 [inline]
kzalloc include/linux/slab.h:682 [inline]
bpf_prog_test_run_raw_tp+0x4b5/0x670 net/bpf/test_run.c:282
bpf_prog_test_run kernel/bpf/syscall.c:3120 [inline]
__do_sys_bpf+0x1ea9/0x4f10 kernel/bpf/syscall.c:4398
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440499
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffe1f3bfb18 EFLAGS: 0246 ORIG_RAX: 0141
RAX: ffda RBX: 004002c8 RCX: 00440499
RDX: 0048 RSI: 2600 RDI: 000a
RBP: 006ca018 R08: R09: 004002c8
R10: R11: 0246 R12: 00401ca0
R13: 00401d30 R14: R15:
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Sie haben eine Spende von € 5.800.000,00.
Sie haben eine Spende von € 5.800.000,00. von Mavis Wanczyk antworten Sie mit diesem Code [MW530342019], um die Spende zu erhalten Vous avez un don de 5 800 000,00 €. de Mavis Wanczyk répondez avec ce code [MW530342019] pour recevoir le don
Re: [PATCH] target/file: don't zero iter before iov_iter_bvec
On 1/9/21 07:59, Pavel Begunkov wrote:
> iov_iter_bvec() initialises iterators well, no need to pre-zero it
> beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it
> out and generate extra code for that (confirmed with assembly).
It will be great if we can quantify this optimization with the actual
performance
numbers.
> Signed-off-by: Pavel Begunkov
> ---
> drivers/target/target_core_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/target/target_core_file.c
> b/drivers/target/target_core_file.c
> index cce455929778..5a66854def95 100644
> --- a/drivers/target/target_core_file.c
> +++ b/drivers/target/target_core_file.c
> @@ -267,7 +267,7 @@ fd_execute_rw_aio(struct se_cmd *cmd, struct scatterlist
> *sgl, u32 sgl_nents,
> struct fd_dev *fd_dev = FD_DEV(dev);
> struct file *file = fd_dev->fd_file;
> struct target_core_file_cmd *aio_cmd;
> - struct iov_iter iter = {};
> + struct iov_iter iter;
> struct scatterlist *sg;
> ssize_t len = 0;
> int ret = 0, i;
Re: [PATCH] MIPS: Support binutils configured with --enable-mips-fix-loongson3-llsc=yes
On Sat, 9 Jan 2021, Aurelien Jarno wrote: > diff --git a/arch/mips/Makefile b/arch/mips/Makefile > index cd4343edeb11..5ffdd67093bc 100644 > --- a/arch/mips/Makefile > +++ b/arch/mips/Makefile > @@ -136,6 +136,25 @@ cflags-$(CONFIG_SB1XXX_CORELIS) += $(call > cc-option,-mno-sched-prolog) \ > # > cflags-y += -fno-stack-check > > +# binutils from v2.35 when built with --enable-mips-fix-loongson3-llsc=yes, > +# supports an -mfix-loongson3-llsc flag which emits a sync prior to each ll > +# instruction to work around a CPU bug (see __SYNC_loongson3_war in > asm/sync.h > +# for a description). > +# > +# We disable this in order to prevent the assembler meddling with the > +# instruction that labels refer to, ie. if we label an ll instruction: > +# > +# 1: ll v0, 0(a0) > +# > +# ...then with the assembler fix applied the label may actually point at a > sync > +# instruction inserted by the assembler, and if we were using the label in an > +# exception table the table would no longer contain the address of the ll > +# instruction. Interesting. Given that a MIPS assembler is generally free to shuffle instructions as it sees fit in its default reorder mode as long as that does not change the semantics of the code executed, shouldn't we instead place all label/instruction pairs used for exception handling in noreorder blocks so as to make sure the label refers to the instruction an exception handler expects it to? E.g. for the case quoted above: .setpush .setnoreorder 1: ll v0, 0(a0) .setpop Maciej
Re: [PATCH v3 3/3] dt-bindings: arm: fsl: Add Variscite i.MX6UL compatibles
On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute wrote: > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml > b/Documentation/devicetree/bindings/arm/fsl.yaml > index 05906e2..5f74d78 100644 > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -240,6 +240,7 @@ properties: >- technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL > Pico-Dwarf >- technexion,imx6ul-pico-hobbit # TechNexion i.MX6UL > Pico-Hobbit >- technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi > + - variscite,imx6ul-var-6ulcustomboard # i.MX UltraLite > Carrier-board You missed to add a "6" in the description: i.MX6 UltraLite Carrier-board
[PATCH] MIPS: lantiq: irq: register the interrupt controllers with irqchip_init
Add support for more interrupt controllers by switching from
of_irq_init() to irqchip_init() in Lantiq's arch_init_irq(). This
requires switching the ICU interrupt controller to use
IRQCHIP_DECLARE(), like a real irqchip driver would do.
This is needed for future changes when new irqchip drivers are
implemented:
- a dedicated driver for the EIU interrupt controller
- a driver for the MSI PIC (Programmable Interrupt Controller) found on
VRX200 and newer SoCs
- ..or any other driver which uses IRQCHIP_DECLARE
Signed-off-by: Martin Blumenstingl
---
arch/mips/lantiq/irq.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index df8eed3875f6..76806d11e483 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -422,12 +423,9 @@ unsigned int get_c0_compare_int(void)
return CP0_LEGACY_COMPARE_IRQ;
}
-static const struct of_device_id of_irq_ids[] __initconst = {
- { .compatible = "lantiq,icu", .data = icu_of_init },
- {},
-};
+IRQCHIP_DECLARE(lantiq_icu, "lantiq,icu", icu_of_init);
void __init arch_init_irq(void)
{
- of_irq_init(of_irq_ids);
+ irqchip_init();
}
--
2.30.0
Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy
On Sat, Jan 9, 2021 at 11:33 AM Matthew Wilcox wrote: > > On Thu, Jan 07, 2021 at 01:05:19PM -0800, Linus Torvalds wrote: > > Side note, and not really related to UFFD, but the mmap_sem in > > general: I was at one point actually hoping that we could make the > > mmap_sem a spinlock, or at least make the rule be that we never do any > > IO under it. At which point a write lock hopefully really shouldn't be > > such a huge deal. > > There's a (small) group of us working towards that. It has some > prerequisites, but where we're hoping to go currently: > > - Replace the vma rbtree with a b-tree protected with a spinlock > - Page faults walk the b-tree under RCU, like peterz/laurent's SPF patchset > - If we need to do I/O, take a refcount on the VMA > > After that, we can gradually move things out from mmap_sem protection > to just the vma tree spinlock, or whatever makes sense for them. In a > very real way the mmap_sem is the MM layer's BKL. Well, we could do the "no IO" part first, and keep the semaphore part. Some people actually prefer a semaphore to a spinlock, because it doesn't end up causing preemption issues. As long as you don't do IO (or memory allocations) under a semaphore (ok, in this case it's a rwsem, same difference), it might even be preferable to keep it as a semaphore rather than as a spinlock. So it doesn't necessarily have to go all the way - we _could_ just try something like "when taking the mmap_sem, set a thread flag" and then have a "warn if doing allocations or IO under that flag". And since this is about performance, not some hard requirement, it might not even matter if we catch all cases. If we fix it so that any regular load on most normal filesystems never see the warning, we'd already be golden. Of course, I think we've had issues with rw_sems for _other_ reasons. Waiman actually removed the reader optimistic spinning because it caused bad interactions with mixed reader-writer loads. So rwsemapores may end up not working as well as spinlocks if the common situation is "just wait a bit, you'll get it". Linus
Re: [PATCH v8 2/3] ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard
On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute wrote:
> + panel1: panel-lcd {
> + compatible = "sgd,gktw70sdad1sd";
> +
> + backlight = <_lcd>;
> + power-supply = <_touch_3v3>;
> + label = "gktw70sdad1sd";
> +
> + display-timing {
If you pass the compatible, then you don't need to add the
display-timing in the device tree.
Re: [PULL REQUEST] i2c for 5.11
The pull request you sent on Sat, 9 Jan 2021 09:31:56 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/caab314792aca89f327abc8b9f730526d3080366 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL]: dmaengine fixes for v5.11
The pull request you sent on Sat, 9 Jan 2021 14:31:24 +0530: > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git > tags/dmaengine-fix-5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f408126be7dc642102224cdb55d6533519a67c19 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] hwmon fixes for v5.11-rc3
The pull request you sent on Sat, 9 Jan 2021 10:22:41 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > hwmon-for-v5.11-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2ff90100ace886895e4fbb2850b8d5e49d931ed6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v8 1/3] ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
Hi Oliver,
On Fri, Jan 8, 2021 at 7:22 PM Oliver Graute wrote:
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_enet1>;
> + phy-mode = "rmii";
> + phy-handle = <>;
> + phy-reset-gpios=< 10 1>;
> + phy-reset-duration=<100>;
These properties are obsolete. Please describe the Ethernet PHY reset
inside the ethernet-phy nodes as per:
Documentation/devicetree/bindings/net/ethernet-phy.yaml
> + phy-reset-on-resume;
This property does not exist.
arch/sh/kernel/kgdb.c:310:38: sparse: sparse: incorrect type in argument 1 (different base types)
Hi Luc,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 996e435fd401de35df62ac943ab9402cfe85c430
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 4 months ago
config: sh-randconfig-s031-20210110 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-208-g46a52ca4-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
arch/sh/kernel/kgdb.c:49:26: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long pc @@
arch/sh/kernel/kgdb.c:49:26: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/kgdb.c:49:26: sparse: got unsigned long pc
arch/sh/kernel/kgdb.c:146:26: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got long @@
arch/sh/kernel/kgdb.c:146:26: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/kgdb.c:146:26: sparse: got long
arch/sh/kernel/kgdb.c:160:17: sparse: sparse: incorrect type in argument 1
(different base types) @@ expected void const volatile [noderef] __iomem
*ptr @@ got unsigned long static [assigned] [toplevel] stepped_address @@
arch/sh/kernel/kgdb.c:160:17: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/kgdb.c:160:17: sparse: got unsigned long static
[assigned] [toplevel] stepped_address
>> arch/sh/kernel/kgdb.c:310:38: sparse: sparse: incorrect type in argument 1
>> (different base types) @@ expected void const volatile [noderef] __iomem
>> *ptr @@ got unsigned long @@
arch/sh/kernel/kgdb.c:310:38: sparse: expected void const volatile
[noderef] __iomem *ptr
arch/sh/kernel/kgdb.c:310:38: sparse: got unsigned long
--
drivers/input/serio/serport.c:213:21: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected unsigned long const
*__gu_addr @@ got unsigned long [noderef] __user * @@
drivers/input/serio/serport.c:213:21: sparse: expected unsigned long
const *__gu_addr
drivers/input/serio/serport.c:213:21: sparse: got unsigned long
[noderef] __user *
>> drivers/input/serio/serport.c:213:21: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __user *ptr @@ got unsigned long const *__gu_addr @@
drivers/input/serio/serport.c:213:21: sparse: expected void const
volatile [noderef] __user *ptr
drivers/input/serio/serport.c:213:21: sparse: got unsigned long const
*__gu_addr
--
drivers/tee/tee_core.c:683:13: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected unsigned int const *__gu_addr @@
got unsigned int [noderef] __user * @@
drivers/tee/tee_core.c:683:13: sparse: expected unsigned int const
*__gu_addr
drivers/tee/tee_core.c:683:13: sparse: got unsigned int [noderef] __user
*
>> drivers/tee/tee_core.c:683:13: sparse: sparse: incorrect type in argument 1
>> (different address spaces) @@ expected void const volatile [noderef]
>> __user *ptr @@ got unsigned int const *__gu_addr @@
drivers/tee/tee_core.c:683:13: sparse: expected void const volatile
[noderef] __user *ptr
drivers/tee/tee_core.c:683:13: sparse: got unsigned int const *__gu_addr
drivers/tee/tee_core.c:781:13: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected unsigned int const *__gu_addr @@
got unsigned int [noderef] __user * @@
drivers/tee/tee_core.c:781:13: sparse: expected unsigned int const
*__gu_addr
drivers/tee/tee_core.c:781:13: sparse: got unsigned int [noderef] __user
*
drivers/tee/tee_core.c:781:13: sparse: sparse: incorrect type in argument 1
(different address spaces) @@ expected void const volatile [noderef] __user
*ptr @@ got unsigned int const *__gu_addr @@
drivers/tee/tee_core.c:781:13: sparse: expected
Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy
On Thu, Jan 07, 2021 at 01:05:19PM -0800, Linus Torvalds wrote: > Side note, and not really related to UFFD, but the mmap_sem in > general: I was at one point actually hoping that we could make the > mmap_sem a spinlock, or at least make the rule be that we never do any > IO under it. At which point a write lock hopefully really shouldn't be > such a huge deal. There's a (small) group of us working towards that. It has some prerequisites, but where we're hoping to go currently: - Replace the vma rbtree with a b-tree protected with a spinlock - Page faults walk the b-tree under RCU, like peterz/laurent's SPF patchset - If we need to do I/O, take a refcount on the VMA After that, we can gradually move things out from mmap_sem protection to just the vma tree spinlock, or whatever makes sense for them. In a very real way the mmap_sem is the MM layer's BKL.
[PATCH] MIPS: Support binutils configured with --enable-mips-fix-loongson3-llsc=yes
>From version 2.35, binutils can be configured with --enable-mips-fix-loongson3-llsc=yes, which means it defaults to -mfix-loongson3-llsc. This breaks labels which might then point at the wrong instruction. The workaround to explicitly pass -mno-fix-loongson3-llsc has been added in Linux version 5.1, but is only enabled when building a Loongson 64 kernel. As vendors might use a common toolchain for building Loongson and non-Loongson kernels, just move that workaround to arch/mips/Makefile. At the same time update the comments to reflect the current status. Cc: sta...@vger.kernel.org # 5.1+ Cc: YunQiang Su Signed-off-by: Aurelien Jarno --- arch/mips/Makefile| 19 +++ arch/mips/loongson64/Platform | 22 -- 2 files changed, 19 insertions(+), 22 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index cd4343edeb11..5ffdd67093bc 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -136,6 +136,25 @@ cflags-$(CONFIG_SB1XXX_CORELIS)+= $(call cc-option,-mno-sched-prolog) \ # cflags-y += -fno-stack-check +# binutils from v2.35 when built with --enable-mips-fix-loongson3-llsc=yes, +# supports an -mfix-loongson3-llsc flag which emits a sync prior to each ll +# instruction to work around a CPU bug (see __SYNC_loongson3_war in asm/sync.h +# for a description). +# +# We disable this in order to prevent the assembler meddling with the +# instruction that labels refer to, ie. if we label an ll instruction: +# +# 1: ll v0, 0(a0) +# +# ...then with the assembler fix applied the label may actually point at a sync +# instruction inserted by the assembler, and if we were using the label in an +# exception table the table would no longer contain the address of the ll +# instruction. +# +# Avoid this by explicitly disabling that assembler behaviour. +# +cflags-y += $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,) + # # CPU-dependent compiler/assembler options for optimization. # diff --git a/arch/mips/loongson64/Platform b/arch/mips/loongson64/Platform index ec42c5085905..e2354e128d9a 100644 --- a/arch/mips/loongson64/Platform +++ b/arch/mips/loongson64/Platform @@ -5,28 +5,6 @@ cflags-$(CONFIG_CPU_LOONGSON64)+= -Wa,--trap -# -# Some versions of binutils, not currently mainline as of 2019/02/04, support -# an -mfix-loongson3-llsc flag which emits a sync prior to each ll instruction -# to work around a CPU bug (see __SYNC_loongson3_war in asm/sync.h for a -# description). -# -# We disable this in order to prevent the assembler meddling with the -# instruction that labels refer to, ie. if we label an ll instruction: -# -# 1: ll v0, 0(a0) -# -# ...then with the assembler fix applied the label may actually point at a sync -# instruction inserted by the assembler, and if we were using the label in an -# exception table the table would no longer contain the address of the ll -# instruction. -# -# Avoid this by explicitly disabling that assembler behaviour. If upstream -# binutils does not merge support for the flag then we can revisit & remove -# this later - for now it ensures vendor toolchains don't cause problems. -# -cflags-$(CONFIG_CPU_LOONGSON64)+= $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,) - # # binutils from v2.25 on and gcc starting from v4.9.0 treat -march=loongson3a # as MIPS64 R2; older versions as just R1. This leaves the possibility open -- 2.29.2
[PATCH] dts64: mt7622: fix slow sd card access
From: Frank Wunderlich
- change sdcard (mmc1) to uhs by change vqmmc-supply to 1V8 because driver
maps pinctrl depending on this
- add reset-control for mmc1 like it's done for mmc0/emmc
Fixes: 2c002a3049f7 ("arm64: dts: mt7622: add mmc related device nodes")
Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board")
Signed-off-by: Frank Wunderlich
---
arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 3 ++-
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
index 2f77dc40b9b8..916ca89ab8eb 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -232,10 +232,11 @@ {
bus-width = <4>;
max-frequency = <5000>;
cap-sd-highspeed;
+ mmc-hs200-1_8v;
r_smpl = <1>;
cd-gpios = < 81 GPIO_ACTIVE_LOW>;
vmmc-supply = <_3p3v>;
- vqmmc-supply = <_3p3v>;
+ vqmmc-supply = <_1p8v>;
assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
assigned-clock-parents = < CLK_TOP_UNIV48M>;
};
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 5b9ec032ce8d..7c6d871538a6 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -698,6 +698,8 @@ mmc1: mmc@1124 {
clocks = < CLK_PERI_MSDC30_1_PD>,
< CLK_TOP_AXI_SEL>;
clock-names = "source", "hclk";
+ resets = < MT7622_PERI_MSDC1_SW_RST>;
+ reset-names = "hrst";
status = "disabled";
};
--
2.25.1
Re: [PATCH v3 0/6] add timestamp channel for hid-sensors
On Tue, 5 Jan 2021 17:26:33 +0800 "Ye, Xiang" wrote: > On Tue, Jan 05, 2021 at 12:53:44AM -0800, Srinivas Pandruvada wrote: > > On Tue, 2021-01-05 at 15:21 +0800, Ye Xiang wrote: > > > This patch series add a timestamp channel for hid sensors, > > > including gravity sensor, gyro sensor, magnetometer sensor, > > > ambient light sensor, inclinometer sensor, and rotation sensor. > > > > > > With this patch series, user can get the time when sensor yield > > > a sample. > > > > > I think this series is v1 for upstream not v3. > Sorry, it's v1 for upstream. will resent it as v1. v3 is our internal review > version. > Future notice, if you make a mistake of this particular type - don't resend and carry on with future version numbers. Otherwise it gets really confusing if we get to a public v3 version! Monotonic version numbers only :) Not a bit problem though but if that does happen check I don't grab the wrong version. Jonathan > Thanks > Ye Xiang > > > > > > > --- > > > v3: > > > - hid-sensor-magn-3d: fix iio_val buffer len issue. > > > - hid-sensor-accel-3d: refine commit message > > > > > > v2: > > > - remove unrelated changes. > > > > > > Ye Xiang (6): > > > iio: hid-sensor-accel-3d: Add timestamp channel for gravity sensor > > > iio: hid-sensor-gyro-3d: Add timestamp channel > > > iio: hid-sensor-als: Add timestamp channel > > > iio: hid-sensor-magn-3d: Add timestamp channel > > > iio: hid-sensor-incl-3d: Add timestamp channel > > > iio: hid-sensor-rotation: Add timestamp channel > > > > > > drivers/iio/accel/hid-sensor-accel-3d.c | 6 ++- > > > drivers/iio/gyro/hid-sensor-gyro-3d.c | 40 +--- > > > drivers/iio/light/hid-sensor-als.c | 39 --- > > > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 48 - > > > -- > > > drivers/iio/orientation/hid-sensor-incl-3d.c | 43 ++--- > > > drivers/iio/orientation/hid-sensor-rotation.c | 46 ++--- > > > - > > > 6 files changed, 134 insertions(+), 88 deletions(-) > > > > > > >
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Fri, Jan 8, 2021 at 7:24 PM Oliver Graute wrote: > > On 19/12/20, Oliver Graute wrote: > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD > > to panel-simple. > > > > The panel spec from Variscite can be found at: > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf > > some clue what bus_format and bus_flags I have to use? > > [ 42.505156] panel-simple panel-lcd: Specify missing bus_flags > [ 42.511090] panel-simple panel-lcd: Specify missing bus_format > [ 42.615131] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 Does this patch work? https://pastebin.com/raw/diTMVsh8
Re: [PATCH v8] iio: Handle enumerated properties with gaps
On Thu, 7 Jan 2021 13:20:49 +0200
Alexandru Ardelean wrote:
> From: Lars-Peter Clausen
>
> Some enums might have gaps or reserved values in the middle of their value
> range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a
> meaning, but 2 is a reserved value and can not be used.
>
> Add support for such enums to the IIO enum helper functions. A reserved
> values is marked by setting its entry in the items array to NULL rather
> than the normal descriptive string value.
>
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
Applied to the togreg branch of iio.git and pushed out as testing for all
the normal autobuilder related reasons.
Note I can still rebase so if anyone wants to add tags or comment it's
not yet too late!
Jonathan
> ---
>
> Changelog v7 -> v8:
> *
> https://lore.kernel.org/linux-iio/20210107084434.35283-1-alexandru.ardel...@analog.com/
> * dropped patch 'lib/string.c: add __sysfs_match_string_with_gaps() helper'
> * merged __sysfs_match_string_with_gaps into drivers/iio/industrial-core.c
> as iio_sysfs_match_string_with_gaps()
>
> drivers/iio/industrialio-core.c | 39 ++---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index e9ee9363fed0..db20e2ab437d 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -169,6 +169,36 @@ static const char * const iio_chan_info_postfix[] = {
> [IIO_CHAN_INFO_CALIBAMBIENT] = "calibambient",
> };
>
> +/**
> + * iio_sysfs_match_string_with_gaps - matches given string in an array with
> gaps
> + * @array: array of strings
> + * @n: number of strings in the array
> + * @str: string to match with
> + *
> + * Returns index of @str in the @array or -EINVAL, similar to match_string().
> + * Uses sysfs_streq instead of strcmp for matching.
> + *
> + * This routine will look for a string in an array of strings.
> + * The search will continue until the element is found or the n-th element
> + * is reached, regardless of any NULL elements in the array.
> + */
> +static int iio_sysfs_match_string_with_gaps(const char * const *array,
> size_t n,
> + const char *str)
> +{
> + const char *item;
> + int index;
> +
> + for (index = 0; index < n; index++) {
> + item = array[index];
> + if (!item)
> + continue;
> + if (sysfs_streq(item, str))
> + return index;
> + }
> +
> + return -EINVAL;
> +}
> +
> #if defined(CONFIG_DEBUG_FS)
> /*
> * There's also a CONFIG_DEBUG_FS guard in include/linux/iio/iio.h for
> @@ -470,8 +500,11 @@ ssize_t iio_enum_available_read(struct iio_dev
> *indio_dev,
> if (!e->num_items)
> return 0;
>
> - for (i = 0; i < e->num_items; ++i)
> + for (i = 0; i < e->num_items; ++i) {
> + if (!e->items[i])
> + continue;
> len += scnprintf(buf + len, PAGE_SIZE - len, "%s ",
> e->items[i]);
> + }
>
> /* replace last space with a newline */
> buf[len - 1] = '\n';
> @@ -492,7 +525,7 @@ ssize_t iio_enum_read(struct iio_dev *indio_dev,
> i = e->get(indio_dev, chan);
> if (i < 0)
> return i;
> - else if (i >= e->num_items)
> + else if (i >= e->num_items || !e->items[i])
> return -EINVAL;
>
> return snprintf(buf, PAGE_SIZE, "%s\n", e->items[i]);
> @@ -509,7 +542,7 @@ ssize_t iio_enum_write(struct iio_dev *indio_dev,
> if (!e->set)
> return -EINVAL;
>
> - ret = __sysfs_match_string(e->items, e->num_items, buf);
> + ret = iio_sysfs_match_string_with_gaps(e->items, e->num_items, buf);
> if (ret < 0)
> return ret;
>
Re: [PATCH v5 3/3] iio: dac: ad5766: add driver support for AD5766
On Fri, 8 Jan 2021 20:37:39 +0200
Cristian Pop wrote:
> The AD5766/AD5767 are 16-channel, 16-bit/12-bit, voltage output dense DACs
> Digital-to-Analog converters.
>
> This change adds support for these DACs.
>
> Signed-off-by: Cristian Pop
One comment inline about including linux/unaligned/be_byteshift.h
that needed a bit of an investigation of the history of that file.
As long as you are happy with it I can switch this over to
asm/unaligned.h whilst applying.
Otherwise I'm happy with this now.
So all that's left is giving Rob time to take another look at the
dt bindings.
thanks,
Jonathan
> ---
> Changelog v5:
> - Remove explicit init in "ad5766_span_tbl"
> - Check the return value of "devm_gpiod_get_optional()" call
> - Remove unreachable code in "ad5766_read_ext"
> drivers/iio/dac/Kconfig | 10 +
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ad5766.c | 643 +++
> 3 files changed, 654 insertions(+)
> create mode 100644 drivers/iio/dac/ad5766.c
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 6f6074a5d3db..cea07b4cced1 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -189,6 +189,16 @@ config AD5764
> To compile this driver as a module, choose M here: the
> module will be called ad5764.
>
> +config AD5766
> + tristate "Analog Devices AD5766/AD5767 DAC driver"
> + depends on SPI_MASTER
> + help
> + Say yes here to build support for Analog Devices AD5766, AD5767
> + Digital to Analog Converter.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad5766.
> +
> config AD5770R
> tristate "Analog Devices AD5770R IDAC driver"
> depends on SPI_MASTER
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 2fc481167724..33e16f14902a 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_AD5755) += ad5755.o
> obj-$(CONFIG_AD5755) += ad5758.o
> obj-$(CONFIG_AD5761) += ad5761.o
> obj-$(CONFIG_AD5764) += ad5764.o
> +obj-$(CONFIG_AD5766) += ad5766.o
> obj-$(CONFIG_AD5770R) += ad5770r.o
> obj-$(CONFIG_AD5791) += ad5791.o
> obj-$(CONFIG_AD5686) += ad5686.o
> diff --git a/drivers/iio/dac/ad5766.c b/drivers/iio/dac/ad5766.c
> new file mode 100644
> index ..dac35711771e
> --- /dev/null
> +++ b/drivers/iio/dac/ad5766.c
> @@ -0,0 +1,643 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Analog Devices AD5766, AD5767
> + * Digital to Analog Converters driver
> + * Copyright 2019-2020 Analog Devices Inc.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Strangely I hadn't noticed the direct include of this either of the other
drivers
in IIO that do it. Looking back at the history of that file, it is documented
as being safe, but then intension is that you include asm/unaligned.h as there
may be a better option for a given architecture. Particularly likely if it is a
big
endian architecture.
If I haven't missed anything I'd rather we make that change here and probably
also clear up the few that have snuck in already.
> +
> +#define AD5766_UPPER_WORD_SPI_MASK GENMASK(31, 16)
> +#define AD5766_LOWER_WORD_SPI_MASK GENMASK(15, 0)
> +#define AD5766_DITHER_SOURCE_MASK(ch)GENMASK(((2 * ch) + 1),
> (2 * ch))
> +#define AD5766_DITHER_SOURCE(ch, source) BIT((ch * 2) + source)
> +#define AD5766_DITHER_SCALE_MASK(x) AD5766_DITHER_SOURCE_MASK(x)
> +#define AD5766_DITHER_SCALE(ch, scale) (scale << (ch * 2))
> +#define AD5766_DITHER_ENABLE_MASK(ch)BIT(ch)
> +#define AD5766_DITHER_ENABLE(ch, state) ((!state) << ch)
> +#define AD5766_DITHER_INVERT_MASK(ch)BIT(ch)
> +#define AD5766_DITHER_INVERT(ch, state) (state << ch)
> +
> +#define AD5766_CMD_NOP_MUX_OUT 0x00
> +#define AD5766_CMD_SDO_CNTRL 0x01
> +#define AD5766_CMD_WR_IN_REG(x) (0x10 | ((x) &
> GENMASK(3, 0)))
> +#define AD5766_CMD_WR_DAC_REG(x) (0x20 | ((x) & GENMASK(3, 0)))
> +#define AD5766_CMD_SW_LDAC 0x30
> +#define AD5766_CMD_SPAN_REG 0x40
> +#define AD5766_CMD_WR_PWR_DITHER 0x51
> +#define AD5766_CMD_WR_DAC_REG_ALL0x60
> +#define AD5766_CMD_SW_FULL_RESET 0x70
> +#define AD5766_CMD_READBACK_REG(x) (0x80 | ((x) & GENMASK(3, 0)))
> +#define AD5766_CMD_DITHER_SIG_1 0x90
> +#define AD5766_CMD_DITHER_SIG_2 0xA0
> +#define AD5766_CMD_INV_DITHER0xB0
> +#define AD5766_CMD_DITHER_SCALE_10xC0
> +#define AD5766_CMD_DITHER_SCALE_20xD0
> +
> +#define AD5766_FULL_RESET_CODE 0x1234
> +
> +enum ad5766_type {
> + ID_AD5766,
> +
Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy
On Sat, Jan 9, 2021 at 11:03 AM Andy Lutomirski wrote: > > > > > Sorry to ask but I'm curious, what also goes wrong if the user > > modifies memory under GUP pin from vmsplice? That's not obvious to > > see. > > It breaks the otherwise true rule that the data in pipe buffers is > immutable. Note that this continued harping on vmsplice() is entirely misguided. Anything using GUP has the same issues. This really has nothing to do with vmsplice() per se. In many ways, vmsplice() might be the least of your issues, because it's fairly easy to just limit that for untrusted use. And no, that does not mean "we should make vmsplice root-only" kind of limiting. There are no security issues in any normal situation. Again, it's mainly about things that don't trust each other _despite_ running in similar contexts as far as the kernel is concerned. IOW, exactly that "zygote" kind of situation. If you are a JIT (whether Zygote or a web browser), you basically need to limit the things the untrusted JIT'ed code can do. And that limiting may include vmsplice(). But note the "include" part of "include vmsplice()". Any other GUP user really does have the same issues, it may just be less obvious and have very different timings (or depend on access to devices etc). Absolutely nothing cares about "data in pipe buffers changing" in any other case. You can already write any data you want to a pipe, it doesn't matter if it changes after the write or not. (In many ways, "data in the page cache" is a *much* more difficult issue for the kernel, and it's fundamental to any shared mmap. It's much more difficult because that data is obviously very much also accessible for DMA etc for writeout, and if you have something like "checksums are calculated separately and non-atomically from the actual DMA accesses", you will potentially get checksum errors where the actual disk contents don't match your separately calculated checksums until the _next_ write. This can actually be a feature - seeing "further modifications were concurrent to the write" - but most people end up considering it a bug). Linus
Re: [BUG mips llvm] MIPS: malformed R_MIPS_{HI16,LO16} with LLVM
From: Nick Desaulniers Date: Sat, 9 Jan 2021 09:50:44 -0800 > On Sat, Jan 9, 2021 at 9:11 AM Alexander Lobakin wrote: >> >> Machine: MIPS32 R2 Big Endian (interAptiv (multi)) >> >> While testing MIPS with LLVM, I found a weird and very rare bug with >> MIPS relocs that LLVM emits into kernel modules. It happens on both >> 11.0.0 and latest git snapshot and applies, as I can see, only to >> references to static symbols. >> >> When the kernel loads the module, it allocates a space for every >> section and then manually apply the relocations relative to the >> new address. >> >> Let's say we have a function phy_probe() in drivers/net/phy/libphy.ko. >> It's static and referenced only in phy_register_driver(), where it's >> used to fill callback pointer in a structure. >> >> The real function address after module loading is 0xc06c1444, that >> is observed in its ELF st_value field. >> There are two relocs related to this usage in phy_register_driver(): >> >> R_MIPS_HI16 refers to 0x3c01 >> R_MIPS_LO16 refers to 0x24339444 >> >> The address of .text is 0xc06b8000. So the destination is calculated >> as follows: >> >> 0x from hi16; >> 0x9444 from lo16 (sign extend as it's always treated as signed); >> 0xc06b8000 from base. >> >> = 0xc06b1444. The value is lower than the real phy_probe() address >> (0xc06c1444) by 0x1 and is lower than the base address of >> module's .text, so it's 100% incorrect. >> >> This results in: >> >> [2.204022] CPU 3 Unable to handle kernel paging request at virtual >> address c06b1444, epc == c06b1444, ra == 803f1090 >> >> The correct instructions should be: >> >> R_MIPS_HI16 0x3c010001 >> R_MIPS_LO16 0x24339444 >> >> so there'll be 0x0001 from hi16. >> >> I tried to catch those bugs in arch/mips/kernel/module.c (by checking >> if the destination is lower than the base address, which should never >> happen), and seems like I have only 3 such places in libphy.ko (and >> one in nf_tables.ko). >> I don't think it should be handled somehow in mentioned source code >> as it would look rather ugly and may break kernels build with GNU >> stack, which seems to not produce such bad codes. >> >> If I should report this to any other resources, please let me know. >> I chose clang-built-linux and LKML as it may not happen with userland >> (didn't tried to catch). > > Thanks for the report. Sounds like we may indeed be producing an > incorrect relocation. This is only seen for big endian triples? Unfortunately I don't have a LE board to play with, so can confirm only Big Endian. (BTW, if someone can say if it's possible for MIPS (and how if it is) to launch a LE kernel from BE-booted preloader and U-Boot, that would be super cool) > Getting a way for us to deterministically reproduce would be a good > first step. Which config or configs beyond defconfig, and which > relocations specifically are you observing this with? I use `make 32r2_defconfig` which combines several configs from arch/mips/configs: - generic_defconfig; - generic/32r2.config; - generic/eb.config. Aside from that, I enable a bunch of my WIP drivers and the Netfilter. On my setup, this bug is always present in libphy.ko, so CONFIG_PHYLIB=m (with all deps) should be enough. The three failed relocs belongs to this part of code: [0] llvm-readelf on them: Relocation section '.rel.text' at offset 0xbf60 contains 2281 entries:¬ [...] 5740 00029305 R_MIPS_HI16 .text 5744 00029306 R_MIPS_LO16 .text 5720 00029305 R_MIPS_HI16 .text 5748 00029306 R_MIPS_LO16 .text 573c 00029305 R_MIPS_HI16 .text 574c 00029306 R_MIPS_LO16 .text The first pair is the one from my first mail: 0x3c01 <-- should be 0x3c010001 to work properly 0x24339444 I'm planning to hunt for more now, will let you know. [0] https://elixir.bootlin.com/linux/v5.11-rc2/source/drivers/net/phy/phy_device.c#L2989 > Thanks, > ~Nick Desaulniers Thanks, Al
Re: [PATCH v2 2/3] net: sfp: assume that LOS is not implemented if both LOS normal and inverted is set
On Saturday 09 January 2021 15:46:01 Russell King - ARM Linux admin wrote: > On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote: > > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote: > > > From: Russell King > > > > > > Some GPON SFP modules (e.g. Ubiquiti U-Fiber Instant) have set both > > > SFP_OPTIONS_LOS_INVERTED and SFP_OPTIONS_LOS_NORMAL bits in their EEPROM. > > > > > > Such combination of bits is meaningless so assume that LOS signal is not > > > implemented. > > > > > > This patch fixes link carrier for GPON SFP module Ubiquiti U-Fiber > > > Instant. > > > > > > Signed-off-by: Russell King > > > Signed-off-by: Pali Rohár > > > > Reviewed-by: Andrew Lunn > > I'd like to send this patch irrespective of discussion on the other > patches - I already have it committed in my repository with a different > description, but the patch content is the same. > > Are you happy if I transfer Andrew's r-b tag, and convert yours to an > acked-by before I send it? > > I'd also like to add a patch that allows 2.5G if no other modes are > found, but the bitrate specified by the module allows 2.5G speed - much > like we do for 1G speeds. Russell, should I send a new version of patch series without this patch?
Re: [PATCH v5 2/3] Documentation/ABI/testing: Add documentation for AD5766 new ABI
On Fri, 8 Jan 2021 20:37:38 +0200 Cristian Pop wrote: > New interface is proposed for dither functionality. This future allows > composing an external signals to the selected output channel. > The dither signal can be turned on/off, scaled, inverted, or it can be > selected from different sources. > > Signed-off-by: Cristian Pop Hi Cristian, One trivial inline to fix if you need to respin. Otherwise I can tidy up whilst applying. Jonathan > --- > Changelog v5: > - Rename property to: "in_voltageY_dither_enable" > - Change scale values to: "1 0.75 0.5 0.25" > - Specify KernelVersion > .../ABI/testing/sysfs-bus-iio-dac-ad5766 | 31 +++ > 1 file changed, 31 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dac-ad5766 > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac-ad5766 > b/Documentation/ABI/testing/sysfs-bus-iio-dac-ad5766 > new file mode 100644 > index ..6e5e383b2c53 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-iio-dac-ad5766 > @@ -0,0 +1,31 @@ > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_dither_ennable Typo, enable but I can fix that whilst applying if there is nothing else. Jonathan > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Dither enable. Write 1 to enable dither or 0 to disable it. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_dither_invert > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Inverts the dither applied to the selected DAC channel. Dither > is not > + inverted by default. Write "1" to invert dither. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_dither_scale_available > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Returns possible scalings available for the current channel. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_dither_scale > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Scales the dither before it is applied to the selected channel. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_dither_source > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Selects dither source applied to the selected channel. Write > "0" to > + select N0 source, write "1" to select N1 source.
[PATCH v7 7/7] ARM: dts: imx50-kobo-aura: Add Netronix embedded controller
Enable the Netronix EC on the Kobo Aura ebook reader.
Several features are still missing:
- Frontlight/backlight. The vendor kernel drives the frontlight LED
using the PWM output of the EC and an additional boost pin that
increases the brightness.
- Battery monitoring
- Interrupts for RTC alarm and low-battery events
Signed-off-by: Jonathan Neuschäfer
---
v5-v7:
- no changes
v4:
- https://lore.kernel.org/lkml/20201123000913.1506944-1-j.neuschae...@gmx.net/
- Add 'grp' suffix to pinctrl node
v3:
- https://lore.kernel.org/lkml/20200925050818.2512375-1-j.neuschae...@gmx.net/
- Remove interrupt-controller property from embedded-controller node
- subnodes of embedded-controller node in to the main node
v2:
- https://lore.kernel.org/lkml/20200905144503.1067124-3-j.neuschae...@gmx.net/
- Fix pwm-cells property (should be 2, not 1)
---
arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx50-kobo-aura.dts
b/arch/arm/boot/dts/imx50-kobo-aura.dts
index 97cfd970fe742..82ce8c43be867 100644
--- a/arch/arm/boot/dts/imx50-kobo-aura.dts
+++ b/arch/arm/boot/dts/imx50-kobo-aura.dts
@@ -143,10 +143,24 @@ {
pinctrl-0 = <_i2c3>;
status = "okay";
- /* TODO: embedded controller at 0x43 */
+ embedded-controller@43 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ec>;
+ compatible = "netronix,ntxec";
+ reg = <0x43>;
+ system-power-controller;
+ interrupts-extended = < 11 IRQ_TYPE_EDGE_FALLING>;
+ #pwm-cells = <2>;
+ };
};
{
+ pinctrl_ec: ecgrp {
+ fsl,pins = <
+ MX50_PAD_CSPI_SS0__GPIO4_11 0x0 /* INT
*/
+ >;
+ };
+
pinctrl_gpiokeys: gpiokeysgrp {
fsl,pins = <
MX50_PAD_CSPI_MISO__GPIO4_100x0
--
2.29.2
[PATCH v7 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
The Netronix EC provides a PWM output which is used for the backlight
on some ebook readers. This patches adds a driver for the PWM output.
The .get_state callback is not implemented, because the PWM state can't
be read back from the hardware.
Signed-off-by: Jonathan Neuschäfer
---
v7:
- no changes
v6:
- https://lore.kernel.org/lkml/20201208011000.3060239-5-j.neuschae...@gmx.net/
- Move period / duty cycle setting code to a function
- Rename pwmchip_to_priv to ntxec_pwm_from_chip
- Set period and duty cycle only before enabling the output
- Mention that duty=0, enable=1 is assumed not to happen
- Interleave writes to the period and duty cycle registers, to minimize the
window of time that an inconsistent state is configured
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-5-j.neuschae...@gmx.net/
- Avoid truncation of period and duty cycle to 32 bits
- Make ntxec_pwm_ops const
- Use regmap_multi_reg_write
- Add comment about get_state to ntxec_pwm_ops
- Add comments about non-atomicity of (period, duty cycle) update
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-5-j.neuschae...@gmx.net/
- Document hardware/driver limitations
- Only accept normal polarity
- Fix a typo ("zone" -> "zero")
- change MAX_PERIOD_NS to 0x * 125
- Clamp period to the maximum rather than returning an error
- Rename private struct pointer to priv
- Rearrage control flow in _probe to save a few lines and a temporary variable
- Add missing MODULE_ALIAS line
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-5-j.neuschae...@gmx.net/
- Relicense as GPLv2 or later
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Fix bogus ?: in return line
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschae...@gmx.net/
- Various grammar and style improvements, as suggested by Uwe Kleine-König,
Lee Jones, and Alexandre Belloni
- Switch to regmap
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use the .apply callback instead of the old API
- Add a #define for the time base (125ns)
- Don't change device state in .probe; this avoids multiple problems
- Rework division and overflow check logic to perform divisions in 32 bits
- Avoid setting duty cycle to zero, to work around a hardware quirk
---
drivers/pwm/Kconfig | 8 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-ntxec.c | 182
3 files changed, 191 insertions(+)
create mode 100644 drivers/pwm/pwm-ntxec.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047acb..a2830b8832b97 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -393,6 +393,14 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_NTXEC
+ tristate "Netronix embedded controller PWM support"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the PWM output of the embedded
+ controller found in certain e-book readers designed by the original
+ design manufacturer Netronix.
+
config PWM_OMAP_DMTIMER
tristate "OMAP Dual-Mode Timer PWM support"
depends on OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092a..7d97eb595bbef 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MESON) += pwm-meson.o
obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_NTXEC)+= pwm-ntxec.o
obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c
new file mode 100644
index 0..1db30a6caa3ad
--- /dev/null
+++ b/drivers/pwm/pwm-ntxec.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements PWM output.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ *
+ * Limitations:
+ * - The get_state callback is not implemented, because the current state of
+ * the PWM output can't be read back from the hardware.
+ * - The hardware can only generate normal polarity output.
+ * - The period and duty cycle can't be changed together in one atomic action.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_pwm {
+ struct device *dev;
+ struct ntxec *ec;
+ struct pwm_chip chip;
+};
+
[PATCH v7 5/7] rtc: New driver for RTC in Netronix embedded controller
With this driver, mainline Linux can keep its time and date in sync with
the vendor kernel.
Advanced functionality like alarm and automatic power-on is not yet
supported.
Signed-off-by: Jonathan Neuschäfer
Acked-by: Alexandre Belloni
---
v7:
- Adjust to recent RTC API change (rtc_register_device ->
devm_rtc_register_device)
v6:
- no changes
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-6-j.neuschae...@gmx.net/
- Add Alexandre Belloni's A-b
- Use regmap_multi_reg_write
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-6-j.neuschae...@gmx.net/
- Remove "driver" from Kconfig entry for consistency with most other entries
- Add missing MODULE_ALIAS line
- Give NTXEC_REG_READ_ macros longer names
- Solve the read tearing issue using Alexandre Belloni's algorithm
- Solve the write tearing issue using Uwe Kleine-König's algorithm
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-6-j.neuschae...@gmx.net/
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
- Relicense as GPLv2 or later
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-7-j.neuschae...@gmx.net/
- Rework top-of-file comment [Lee Jones]
- Sort the #include lines [Alexandre Belloni]
- don't align = signs in struct initializers [Uwe Kleine-König]
- Switch to regmap
- Fix register number used to read minutes and seconds
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use devm_rtc_allocate_device and rtc_register_device, set ->range_min and
->range_max
---
drivers/rtc/Kconfig | 8 +++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-ntxec.c | 143
3 files changed, 152 insertions(+)
create mode 100644 drivers/rtc/rtc-ntxec.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6123f9f4fbc90..d49cf387add14 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1315,6 +1315,14 @@ config RTC_DRV_CROS_EC
This driver can also be built as a module. If so, the module
will be called rtc-cros-ec.
+config RTC_DRV_NTXEC
+ tristate "Netronix embedded controller RTC"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the RTC functionality of the
+ embedded controller found in certain e-book readers designed by the
+ original design manufacturer Netronix.
+
comment "on-CPU RTC drivers"
config RTC_DRV_ASM9260
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index bb8f319b09fbf..92c26eafe70ce 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_RTC_DRV_MT7622)+= rtc-mt7622.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
obj-$(CONFIG_RTC_DRV_MXC) += rtc-mxc.o
obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
+obj-$(CONFIG_RTC_DRV_NTXEC)+= rtc-ntxec.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
obj-$(CONFIG_RTC_DRV_PALMAS) += rtc-palmas.o
diff --git a/drivers/rtc/rtc-ntxec.c b/drivers/rtc/rtc-ntxec.c
new file mode 100644
index 0..09cdbcab8eff9
--- /dev/null
+++ b/drivers/rtc/rtc-ntxec.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements access to the RTC time and date.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_rtc {
+ struct device *dev;
+ struct ntxec *ec;
+};
+
+#define NTXEC_REG_WRITE_YEAR 0x10
+#define NTXEC_REG_WRITE_MONTH 0x11
+#define NTXEC_REG_WRITE_DAY0x12
+#define NTXEC_REG_WRITE_HOUR 0x13
+#define NTXEC_REG_WRITE_MINUTE 0x14
+#define NTXEC_REG_WRITE_SECOND 0x15
+
+#define NTXEC_REG_READ_YEAR_MONTH 0x20
+#define NTXEC_REG_READ_MDAY_HOUR 0x21
+#define NTXEC_REG_READ_MINUTE_SECOND 0x23
+
+static int ntxec_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ntxec_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int value;
+ int res;
+
+retry:
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MINUTE_SECOND,
);
+ if (res < 0)
+ return res;
+
+ tm->tm_min = value >> 8;
+ tm->tm_sec = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MDAY_HOUR, );
+ if (res < 0)
+ return res;
+
+ tm->tm_mday = value >> 8;
+ tm->tm_hour = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_YEAR_MONTH, );
+ if (res < 0)
+ return res;
+
+ tm->tm_year = (value >> 8) + 100;
+ tm->tm_mon = (value &
[PATCH v7 6/7] MAINTAINERS: Add entry for Netronix embedded controller
Let's make sure I'll notice when there are patches for the NTXEC drivers. Signed-off-by: Jonathan Neuschäfer --- v4-v7: - no changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-7-j.neuschae...@gmx.net/ - Remove pwm and rtc bindings v2: - https://lore.kernel.org/lkml/20200905144503.1067124-2-j.neuschae...@gmx.net/ - No changes --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 546aa66428c9f..0c6e739e3afb7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12298,6 +12298,15 @@ F: include/net/netrom.h F: include/uapi/linux/netrom.h F: net/netrom/ +NETRONIX EMBEDDED CONTROLLER +M: Jonathan Neuschäfer +S: Maintained +F: Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +F: drivers/mfd/ntxec.c +F: drivers/pwm/pwm-ntxec.c +F: drivers/rtc/rtc-ntxec.c +F: include/linux/mfd/ntxec.h + NETRONOME ETHERNET DRIVERS M: Simon Horman R: Jakub Kicinski -- 2.29.2
Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy
> On Jan 8, 2021, at 3:34 PM, Andrea Arcangeli wrote: > > On Fri, Jan 08, 2021 at 10:31:24AM -0800, Andy Lutomirski wrote: >> Can we just remove vmsplice() support? We could make it do a normal > >> copy, thereby getting rid of a fair amount of nastiness and potential >> attacks. Even ignoring issues relating to the length of time that the >> vmsplice reference is alive, we also have whatever problems could be >> caused by a malicious or misguided user vmsplice()ing some memory and >> then modifying it. > > Sorry to ask but I'm curious, what also goes wrong if the user > modifies memory under GUP pin from vmsplice? That's not obvious to > see. It breaks the otherwise true rule that the data in pipe buffers is immutable. Even just quoting the manpage: SPLICE_F_GIFT The user pages are a gift to the kernel. The application may not modify this memory ever, otherwise the page cache and on- disk data may differ. That's no good. I can also imagine use cases in which modified vmsplice() pages that end up in various parts of the network stack could be problematic. For example, if you can arrange for TCP or, worse, TLS to transmit data and then retransmit modified data, you might get odd results. In the latter case, some security properties of TLS might be broken. --Andy
drivers/rtc/rtc-meson.c:388:34: warning: unused variable 'meson_rtc_dt_match'
Hi Martin,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 996e435fd401de35df62ac943ab9402cfe85c430
commit: d8fe6009aa3ecbeeab3a4ec1a8bce68959a885be rtc: support for the Amlogic
Meson RTC
date: 1 year, 11 months ago
config: x86_64-randconfig-a006-20210110 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
bc556e5685c0f97e79fb7b3c6f15cc5062db8e36)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d8fe6009aa3ecbeeab3a4ec1a8bce68959a885be
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout d8fe6009aa3ecbeeab3a4ec1a8bce68959a885be
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/rtc/rtc-meson.c:388:34: warning: unused variable
>> 'meson_rtc_dt_match' [-Wunused-const-variable]
static const struct of_device_id meson_rtc_dt_match[] = {
^
1 warning generated.
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on HAS_IOMEM && BACKLIGHT_LCD_SUPPORT
Selected by
- ACPI_CMPC && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL ||
RFKILL
- SAMSUNG_Q10 && X86 && X86_PLATFORM_DEVICES && ACPI
vim +/meson_rtc_dt_match +388 drivers/rtc/rtc-meson.c
387
> 388 static const struct of_device_id meson_rtc_dt_match[] = {
389 { .compatible = "amlogic,meson6-rtc", },
390 { .compatible = "amlogic,meson8-rtc", },
391 { .compatible = "amlogic,meson8b-rtc", },
392 { .compatible = "amlogic,meson8m2-rtc", },
393 { },
394 };
395 MODULE_DEVICE_TABLE(of, meson_rtc_dt_match);
396
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors
On Wed, 6 Jan 2021 21:23:53 + Jyoti Bhayana wrote: > Hi Jonathan, > > Instead of adding IIO_VAL_INT_H32_L32, I am thinking of adding > IIO_VAL_FRACTIONAL_LONG > or IIO_VAL_FRACTIONAL_64 as the scale/exponent used for min/max range can be > different > than the one used in resolution according to specification. That's somewhat 'odd'. Given min/max are inherently values the sensor is supposed to be able to return why give them different resolutions? Can you point me at a specific section of the spec? The axis_min_range_low etc fields don't seem to have units specified but I assumed they were in sensor units and so same scale factors? > > I am planning to use read_avail for IIO_CHAN_INFO_PROCESSED using > IIO_AVAIL_RANGE > and this new IIO_VAL_FRACTIONAL_64 for min range,max range and resolution. > Instead of two values used in IIO_VAL_FRACTIONAL, IIO_VAL_FRACTIONAL_64 will > use 4 values > val_high,val_low,and val2_high and val2_low. I'm not keen on the changing that internal kernel interface unless we absolutely have to. read_avail() is called from consumer drivers and they won't know anything about this new variant. > > Let me know if that is an acceptable solution. Hmm. It isn't a standard use of the ABI given the value in the buffer is (I assume) raw (needs scale applied). However, it isn't excluded by the ABI docs. Whether a standard userspace is going to expect it is not clear to me. I don't want to end up in a position where we end up with available being generally added for processed when what most people care about is what the value range they might get from a polled read is (rather than via a buffer). So I'm not that keen on this solution but if we can find a way to avoid it. Jonathan > > > Thanks, > Jyoti >
Re: [PATCH] maintainers: update my email address
On Fri, Jan 8, 2021 at 10:46 PM Darrick J. Wong wrote: > > Change my email contact ahead of a likely painful eleven-month migration > to a certain cobalt enteprisey groupware cloud product that will totally > break my workflow. Some day I may get used to having to email being > sequestered behind both claret and cerulean oath2+sms 2fa layers, but > for now I'll stick with keying in one password to receive an email vs. > the required four. So I appreciate this email coming from your old email address, but I also just want to note that as long as you then use the oracle email address for sending email, commit authorship, and "Signed-off-by:" (or Acked-by etc) addresses, those tend to be the ones that _primarily_ get used when people then CC you on issues. Well, at least that's how I work. The MAINTAINERS file tends to be the secondary one. But I wish you best of luck with the new email setup ;) Linus
Re: [PATCH] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
On Sat, Jan 9, 2021 at 7:08 PM Rafael J. Wysocki wrote: > On Saturday, January 9, 2021 10:37:41 AM CET Dexuan Cui wrote: ... > > Do you want a simple strlen() check like the below, or a full > > check of the AAA or format? > > It would be good to check the format too while at it. Let me summarize. It seems from my perspective that the best is to have two checks here (as far as I got word "too" in Rafael's reply): - per length with a message that "length is exceeded" - per format with probably different messages depending on the checks (like "vendor prefix has incorrect format" and "device id has incorrect format"). -- With Best Regards, Andy Shevchenko
Re: [PATCH v4 0/3] add custom hinge sensor support
On Thu, 31 Dec 2020 10:46:40 +0800 "Ye, Xiang" wrote: > On Wed, Dec 30, 2020 at 12:05:17PM +, Jonathan Cameron wrote: > > On Tue, 15 Dec 2020 13:44:41 +0800 > > Ye Xiang wrote: > > > > > Here we register one iio device with three channels which present angle > > > for > > > hinge, keyboard and screen. > > > > > > This driver works on devices with Intel integrated sensor hub, where > > > hinge sensor is presented using a custom sensor usage id. > > > > > > Here the angle is presented in degrees, which is converted to radians. > > > > Other than those minor bits I'm happy to fix up in patch 2, this looks > > good to me. However, I'll need a Jiri Ack for the hid parts before > > I apply it. We are are early in this cycle, so no great rush given > > the usual xmas slow down! > > Ok, let's wait Jiri to review the hid parts. Thanks for the help. Series applied with the changes mentioned in review of patch 2. Applied to the togreg branch of iio.git and pushed out as testing for the various autobuilders to poke at it at and see if they can find anything I missed. Thanks, Jonathan > > Thanks > Ye Xiang > > > > > > > > Changes since v3: > > > - hid-sensor-custom: remove sensor_inst::custom_pdev_exposed. > > > - hid-sensor-custom: use static buf, w_buf to avoid using goto in > > > get_known_custom_sensor_index. > > > - hid-sensor-custom-intel-hinge: use devm_ prefix function instead. > > > - sysfs-bus-iio: put in_anglY_raw together with in_angl_raw. > > > > > > Changes since v2: > > > - use 1 iio device instead of 3 for hinge sensor. > > > - use indexed channel instead of modified channel and added channel > > > labels. > > > - remove 2,3 patch in last version, add a document patch to describe the > > > hinge channels. > > > - hid-sensor-custom: use meaningful return value in > > > get_known_custom_sensor_index and checked in call side. > > > - hid-sensor-ids.h: use HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) to > > > define custom sensor value. > > > > > > Changes since v1: > > > - fixed errors reported by lkp > > > > > > Ye Xiang (3): > > > HID: hid-sensor-custom: Add custom sensor iio support > > > iio: hid-sensors: Add hinge sensor driver > > > iio:Documentation: Add documentation for hinge sensor channels > > > > > > Documentation/ABI/testing/sysfs-bus-iio | 11 + > > > drivers/hid/hid-sensor-custom.c | 143 +++ > > > .../hid-sensors/hid-sensor-attributes.c | 2 + > > > drivers/iio/position/Kconfig | 16 + > > > drivers/iio/position/Makefile | 1 + > > > .../position/hid-sensor-custom-intel-hinge.c | 391 ++ > > > include/linux/hid-sensor-ids.h| 14 + > > > 7 files changed, 578 insertions(+) > > > create mode 100644 drivers/iio/position/hid-sensor-custom-intel-hinge.c > > > > >
Re: [PATCH 3/5] clk: qcom: mmcc-sdm660: Add MDP clock source CXC to MDSS GDSC
Il giorno sab 5 dic 2020 alle ore 06:08 Bjorn Andersson
ha scritto:
>
> On Sat 26 Sep 08:03 CDT 2020, khol...@gmail.com wrote:
>
> > From: AngeloGioacchino Del Regno
> >
> > It is required for optimal performance and to avoid MDP stalls to
> > retain mem/periph on GDSC enablement: to achieve this, let's add
> > the required CXC to the MDSS GDSC.
> >
>
> Can you please explain how you came to this conclusion, I don't see the
> reference to the MDP_CLK_SRC in the downstream kernel.
>
> Thanks,
> Bjorn
>
Hey!
I am sure I don't have to go too deep with such an explanation. You know,
downstream is seriously tangled, perhaps that's why you couldn't find how.
By the way, as you can see, here in sdm660-mdss.dtsi we have the
MDP_CLK_SRC clock:
https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/sdm660-mdss.dtsi?h=LA.UM.8.2.r2-03400-sdm660.0#n121
Since downstream uses to set the mem/periph retain in a different way,
here you find
some references to what you're looking for:
https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/drivers/video/fbdev/msm/mdss_mdp.c?h=LA.UM.8.2.r2-03400-sdm660.0#n1555
...of course, also from my own tests, failing to set these flags will
stall the MDP as
soon as we hit a resume from MDP idle power collapse.
P.S.: Sorry for the late reply!
--Angelo
> > Signed-off-by: AngeloGioacchino Del Regno
> > ---
> > drivers/clk/qcom/mmcc-sdm660.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/clk/qcom/mmcc-sdm660.c b/drivers/clk/qcom/mmcc-sdm660.c
> > index 234aca7c873b..7b1384cf8506 100644
> > --- a/drivers/clk/qcom/mmcc-sdm660.c
> > +++ b/drivers/clk/qcom/mmcc-sdm660.c
> > @@ -2572,6 +2572,8 @@ static struct gdsc mdss_gdsc = {
> > .pd = {
> > .name = "mdss",
> > },
> > + .cxcs = (unsigned int []){ 0x2040 },
> > + .cxc_count = 1,
> > .pwrsts = PWRSTS_OFF_ON,
> > };
> >
> > --
> > 2.28.0
> >
Re: [PATCH v2] PCI: Fix Intel i210 by avoiding overlapping of BARs
Hi Bjorn, Am 2021-01-08 22:20, schrieb Bjorn Helgaas: On Wed, Dec 30, 2020 at 07:53:17PM +0100, Michael Walle wrote: The Intel i210 doesn't work if the Expansion ROM BAR overlaps with another BAR. Networking won't work at all and once a packet is sent the netdev watchdog will bite: 1) Is this a regression? It sounds like you don't know for sure because earlier kernels don't support your platform. Whats the background of the question? The board is offially supported since 5.8. I doubt that the code responsible to not touch the ExpROM BAR in pci_std_update_resource() were recently changed/added; the comment refers to a mail from 2005. So no I don't think it is a regression per se. It is just that some combination of hardware and firmware will program the BARs in away so that this bug is triggered. And chances of this happing are very unlikely. Do we agree that it should be irrelevant how the firmware programs and enables the BARs in this case? I.e. you could "fix" u-boot to match the way linux will assign addresses to the BARs. But that would just work around the real issue here. IMO. 2) Can you open a bugzilla at https://bugzilla.kernel.org and attach the complete dmesg and "sudo lspci -vv" output? I want to see whether Linux is assigning something incorrectly or this is a consequence of some firmware initialization. Sure, but you wouldn't even see the error with "lspci -vv" because lspci will just show the mapping linux assigned to it. But not whats written to the actual BAR for the PCI card. I'll also include a "lspci -xx". I've enabled CONFIG_PCI_DEBUG, too. https://bugzilla.kernel.org/show_bug.cgi?id=211105 3) If the Intel i210 is defective in how it handles an Expansion ROM that overlaps another BAR, a quirk might be the right fix. But my guess is the device is working correctly per spec and there's something wrong in how firmware/Linux is assigning things. That would mean we need a more generic fix that's not a quirk and not tied to the Intel i210. Agreed, but as you already stated (and I've also found that in the PCI spec) the Expansion ROM address decoder can be shared by the other BARs and it shouldn't matter as long as the ExpROM BAR is disabled, which is the case here. I've included the Intel ML, maybe the Intel guys can comment on that. [ 89.059374] [ cut here ] [ 89.064019] NETDEV WATCHDOG: enP2p1s0 (igb): transmit queue 0 timed out [ 89.070681] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:443 dev_watchdog+0x3a8/0x3b0 [ 89.078989] Modules linked in: [ 89.082053] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 5.11.0-rc1-00020-gc16f033804b #289 [ 89.091574] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 89.099870] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 89.105900] pc : dev_watchdog+0x3a8/0x3b0 [ 89.109923] lr : dev_watchdog+0x3a8/0x3b0 [ 89.113945] sp : 80001000bd50 [ 89.117268] x29: 80001000bd50 x28: 0008 [ 89.122602] x27: 0004 x26: 0140 [ 89.127935] x25: 002001c6c000 x24: 002001c2b940 [ 89.133267] x23: 8000118c7000 x22: 002001c6c39c [ 89.138600] x21: 002001c6bfb8 x20: 002001c6c3b8 [ 89.143932] x19: x18: 0010 [ 89.149264] x17: x16: [ 89.154596] x15: x14: 0720072007200720 [ 89.159928] x13: 0720072007740775 x12: 80001195b980 [ 89.165260] x11: 0003 x10: 800011943940 [ 89.170592] x9 : 800010100d44 x8 : 00017fe8 [ 89.175924] x7 : c000efff x6 : 0001 [ 89.181255] x5 : x4 : [ 89.186587] x3 : x2 : 8000118eb908 [ 89.191919] x1 : 84d8200845006900 x0 : [ 89.197251] Call trace: [ 89.199701] dev_watchdog+0x3a8/0x3b0 [ 89.203374] call_timer_fn+0x38/0x208 [ 89.207049] run_timer_softirq+0x290/0x540 [ 89.211158] __do_softirq+0x138/0x404 [ 89.214831] irq_exit+0xe8/0xf8 [ 89.217981] __handle_domain_irq+0x70/0xc8 [ 89.222091] gic_handle_irq+0xc8/0x2b0 [ 89.225850] el1_irq+0xb8/0x180 [ 89.228999] arch_cpu_idle+0x18/0x40 [ 89.232587] default_idle_call+0x70/0x214 [ 89.236610] do_idle+0x21c/0x290 [ 89.239848] cpu_startup_entry+0x2c/0x70 [ 89.243783] secondary_start_kernel+0x1a0/0x1f0 [ 89.248332] ---[ end trace 1687af62576397bc ]--- [ 89.253350] igb 0002:01:00.0 enP2p1s0: Reset adapter This entire splat is overkill. The useful part is what somebody who trips over this might google for. Strip out the "cut here", the timestamps, the register dump, and the last 6-8 lines of the call trace. This seem to be different from subsys to subsys, but whatever ;) -michael
[GIT PULL] hwmon fixes for v5.11-rc3
Hi Linus, Please pull hwmon fixes for Linux v5.11-rc3 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-v5.11-rc3 Thanks, Guenter -- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-v5.11-rc3 for you to fetch changes up to 84e261553e6f919bf0b4d65244599ab2b41f1da5: hwmon: (amd_energy) fix allocation of hwmon_channel_info config (2021-01-08 07:31:03 -0800) hwmon fixes for v5.11-rc3 Fix possible KASAN issue in amd_energy driver Avoid configuration problem in pwm-fan driver Fix kernel-doc warning in sbtsi_temp documentation David Arcari (1): hwmon: (amd_energy) fix allocation of hwmon_channel_info config Randy Dunlap (1): hwmon: (sbtsi_temp) Fix Documenation kernel-doc warning Uwe Kleine-König (1): hwmon: (pwm-fan) Ensure that calculation doesn't discard big period values Documentation/hwmon/sbtsi_temp.rst | 2 +- drivers/hwmon/amd_energy.c | 3 ++- drivers/hwmon/pwm-fan.c| 12 +++- 3 files changed, 14 insertions(+), 3 deletions(-)
memory leak in tcp_cdg_init
Hello, syzbot found the following issue on: HEAD commit:36bbbd0e Merge branch 'rcu/urgent' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16ef4dfb50 kernel config: https://syzkaller.appspot.com/x/.config?x=b991a69440391446 dashboard link: https://syzkaller.appspot.com/bug?extid=f1e24a0594d4e3a895d3 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13e1bb2b50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f1e24a0594d4e3a89...@syzkaller.appspotmail.com 2021/01/05 17:50:00 executed programs: 127 2021/01/05 17:50:06 executed programs: 146 2021/01/05 17:50:12 executed programs: 157 2021/01/05 17:50:19 executed programs: 175 BUG: memory leak unreferenced object 0x888125940080 (size 64): comm "syz-executor.1", pid 3, jiffies 4294986279 (age 14.750s) 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: [] kmalloc_array include/linux/slab.h:592 [inline] [ ] kcalloc include/linux/slab.h:621 [inline] [ ] tcp_cdg_init+0x37/0x60 net/ipv4/tcp_cdg.c:380 [ ] tcp_init_congestion_control+0x31/0x160 net/ipv4/tcp_cong.c:183 [<9761f0eb>] tcp_reinit_congestion_control net/ipv4/tcp_cong.c:207 [inline] [<9761f0eb>] tcp_set_congestion_control+0x35e/0x380 net/ipv4/tcp_cong.c:377 [<825a01e7>] do_tcp_setsockopt net/ipv4/tcp.c:3319 [inline] [<825a01e7>] tcp_setsockopt+0x3fc/0x13f0 net/ipv4/tcp.c:3599 [<09f41711>] __sys_setsockopt+0x1b0/0x360 net/socket.c:2115 [<8873566c>] __do_sys_setsockopt net/socket.c:2126 [inline] [<8873566c>] __se_sys_setsockopt net/socket.c:2123 [inline] [<8873566c>] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2123 [<48fbe902>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888125940880 (size 64): comm "syz-executor.4", pid 5, jiffies 4294986279 (age 14.750s) 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: [ ] kmalloc_array include/linux/slab.h:592 [inline] [ ] kcalloc include/linux/slab.h:621 [inline] [ ] tcp_cdg_init+0x37/0x60 net/ipv4/tcp_cdg.c:380 [ ] tcp_init_congestion_control+0x31/0x160 net/ipv4/tcp_cong.c:183 [<9761f0eb>] tcp_reinit_congestion_control net/ipv4/tcp_cong.c:207 [inline] [<9761f0eb>] tcp_set_congestion_control+0x35e/0x380 net/ipv4/tcp_cong.c:377 [<825a01e7>] do_tcp_setsockopt net/ipv4/tcp.c:3319 [inline] [<825a01e7>] tcp_setsockopt+0x3fc/0x13f0 net/ipv4/tcp.c:3599 [<09f41711>] __sys_setsockopt+0x1b0/0x360 net/socket.c:2115 [<8873566c>] __do_sys_setsockopt net/socket.c:2126 [inline] [<8873566c>] __se_sys_setsockopt net/socket.c:2123 [inline] [<8873566c>] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2123 [<48fbe902>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH v7 2/7] dt-bindings: mfd: Add binding for Netronix embedded controller
This EC is found in e-book readers of multiple brands (e.g. Kobo,
Tolino), and is typically implemented as a TI MSP430 microcontroller.
It controls different functions of the system, such as power on/off,
RTC, PWM for the backlight. The exact functionality provided can vary
between boards.
Signed-off-by: Jonathan Neuschäfer
Reviewed-by: Rob Herring
---
v5-v7:
- no changes
v4:
- Add R-b tag
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-3-j.neuschae...@gmx.net/
- Remove binding in text form patch description again
- Add additionalProperties: false
- Remove interrupt-controller property from example
- Merge pwm/rtc nodes into main node
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-3-j.neuschae...@gmx.net/
- Add the plaintext DT binding for comparison
---
.../bindings/mfd/netronix,ntxec.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
new file mode 100644
index 0..59a630025f52f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/netronix,ntxec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Netronix Embedded Controller
+
+maintainers:
+ - Jonathan Neuschäfer
+
+description: |
+ This EC is found in e-book readers of multiple brands (e.g. Kobo, Tolino),
and
+ is typically implemented as a TI MSP430 microcontroller.
+
+properties:
+ compatible:
+const: netronix,ntxec
+
+ reg:
+items:
+ - description: The I2C address of the EC
+
+ system-power-controller:
+type: boolean
+description: See
Documentation/devicetree/bindings/power/power-controller.txt
+
+ interrupts:
+minItems: 1
+description:
+ The EC can signal interrupts via a GPIO line
+
+ "#pwm-cells":
+const: 2
+description: |
+ Number of cells in a PWM specifier.
+
+ The following PWM channels are supported:
+- 0: The PWM channel controlled by registers 0xa1-0xa7
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ec: embedded-controller@43 {
+pinctrl-names = "default";
+pinctrl-0 = <_ntxec>;
+
+compatible = "netronix,ntxec";
+reg = <0x43>;
+system-power-controller;
+interrupt-parent = <>;
+interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+#pwm-cells = <2>;
+};
+};
+
+backlight {
+compatible = "pwm-backlight";
+pwms = < 0 5>;
+power-supply = <_regulator>;
+};
+
+backlight_regulator: regulator-dummy {
+compatible = "regulator-fixed";
+regulator-name = "backlight";
+};
--
2.29.2
[PATCH v7 1/7] dt-bindings: Add vendor prefix for Netronix, Inc.
Netronix, Inc. (http://www.netronixinc.com/) makes ebook reader board designs, which are for example used in Kobo and Tolino devices. An alternative prefix for Netronix would be "ntx", which is already used in code released by Netronix. It is shorter, but perhaps less clear. Signed-off-by: Jonathan Neuschäfer Acked-by: Rob Herring --- v4-v7: - No changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-2-j.neuschae...@gmx.net/ - Add Acked-by tag v2: - No changes --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 041ae90b0d8fd..4d36b8173b568 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -756,6 +756,8 @@ patternProperties: description: Broadcom Corporation (formerly NetLogic Microsystems) "^netron-dy,.*": description: Netron DY + "^netronix,.*": +description: Netronix, Inc. "^netxeon,.*": description: Shenzhen Netxeon Technology CO., LTD "^neweast,.*": -- 2.29.2
[PATCH v7 3/7] mfd: Add base driver for Netronix embedded controller
The Netronix embedded controller is a microcontroller found in some
e-book readers designed by the original design manufacturer Netronix,
Inc. It contains RTC, battery monitoring, system power management, and
PWM functionality.
This driver implements register access and version detection.
Third-party hardware documentation is available at:
https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
The EC supports interrupts, but the driver doesn't make use of them so
far.
Signed-off-by: Jonathan Neuschäfer
Acked-for-MFD-by: Lee Jones
---
v7:
- Add #define for version number (suggested by Lee Jones).
v6:
- https://lore.kernel.org/lkml/20201208011000.3060239-4-j.neuschae...@gmx.net/
- Add Lee Jones' ACK
v5:
- no changes
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-4-j.neuschae...@gmx.net/
- include asm/unaligned.h after linux/*
- Use put_unaligned_be16 instead of open-coded big-endian packing
- Clarify that 0x90=0xff00 causes an error in downstream kernel too
- Add commas after non-sentinel positions
- ntxec.h: declare structs device and regmap
- Replace WARN_ON usage and add comments to explain errors
- Replace dev_alert with dev_warn when the result isn't handled
- Change subdevice registration error message to dev_err
- Declare ntxec_reg8 as returning __be16
- Restructure version detection code
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-4-j.neuschae...@gmx.net/
- Add (EC) to CONFIG_MFD_NTXEC prompt
- Relicense as GPLv2 or later
- Add email address to copyright line
- remove empty lines in ntxec_poweroff and ntxec_restart functions
- Split long lines
- Remove 'Install ... handler' comments
- Make naming of struct i2c_client parameter consistent
- Remove struct ntxec_info
- Rework 'depends on' lines in Kconfig, hard-depend on I2C, select REGMAP_I2C
and
MFD_CORE
- Register subdevices via mfd_cells
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-4-j.neuschae...@gmx.net/
- Add a description of the device to the patch text
- Unify spelling as 'Netronix embedded controller'.
'Netronix' is the proper name of the manufacturer, but 'embedded controller'
is just a label that I have assigned to the device.
- Switch to regmap, avoid regmap use in poweroff and reboot handlers.
Inspired by cf84dc0bb40f4 ("mfd: rn5t618: Make restart handler atomic safe")
- Use a list of known-working firmware versions instead of checking for a
known-incompatible version
- Prefix registers with NTXEC_REG_
- Define register values as constants
- Various style cleanups as suggested by Lee Jones
- Don't align = signs in struct initializers [Uwe Kleine-König]
- Don't use dev_dbg for an error message
- Explain sleep in poweroff handler
- Remove (struct ntxec).client
- Switch to .probe_new in i2c driver
- Add .remove callback
- Make CONFIG_MFD_NTXEC a tristate option
---
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/ntxec.c | 216 ++
include/linux/mfd/ntxec.h | 37 +++
4 files changed, 265 insertions(+)
create mode 100644 drivers/mfd/ntxec.c
create mode 100644 include/linux/mfd/ntxec.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bdfce7b156216..4280bcd47ec7d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -976,6 +976,17 @@ config MFD_VIPERBOARD
You need to select the mfd cell drivers separately.
The drivers do not support all features the board exposes.
+config MFD_NTXEC
+ tristate "Netronix embedded controller (EC)"
+ depends on OF || COMPILE_TEST
+ depends on I2C
+ select REGMAP_I2C
+ select MFD_CORE
+ help
+ Say yes here if you want to support the embedded controller found in
+ certain e-book readers designed by the original design manufacturer
+ Netronix.
+
config MFD_RETU
tristate "Nokia Retu and Tahvo multi-function device"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 14fdb188af022..948a3bf8e3e57 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -219,6 +219,7 @@ obj-$(CONFIG_MFD_INTEL_PMC_BXT) += intel_pmc_bxt.o
obj-$(CONFIG_MFD_INTEL_PMT)+= intel_pmt.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
+obj-$(CONFIG_MFD_NTXEC)+= ntxec.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_RK808)+= rk808.o
obj-$(CONFIG_MFD_RN5T618) += rn5t618.o
diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
new file mode 100644
index 0..22ed2ef0669cb
--- /dev/null
+++ b/drivers/mfd/ntxec.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC,
[PATCH v2 10/15] MAINTAINERS: Add entry for Qualcomm CPRv3/v4/Hardened driver
Add maintainers entry for the Qualcomm CPR3/CPR4/CPRh driver. Signed-off-by: AngeloGioacchino Del Regno --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c8c006f08dcc..a37c3ae91f2f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14461,6 +14461,12 @@ S: Maintained F: Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml F: drivers/soc/qcom/cpr.c +QUALCOMM CORE POWER REDUCTION v3/v4/Hardened AVS DRIVER +M: AngeloGioacchino Del Regno +S: Maintained +F: Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml +F: drivers/soc/qcom/cpr3.c + QUALCOMM CPUFREQ DRIVER MSM8996/APQ8096 M: Ilia Lin L: linux...@vger.kernel.org -- 2.29.2
[PATCH v2 01/15] cpuidle: qcom_spm: Detach state machine from main SPM handling
In commit a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic
CPUidle driver") the SPM driver has been converted to a
generic CPUidle driver: that was mainly made to simplify the
driver and that was a great accomplishment;
Though, it was ignored that the SPM driver is not used only
on the ARM architecture.
In preparation for the enablement of SPM features on AArch64/ARM64,
split the cpuidle-qcom-spm driver in two: the CPUIdle related
state machine (currently used only on ARM SoCs) stays there, while
the SPM communication handling lands back in soc/qcom/spm.c and
also making sure to not discard the simplifications that were
introduced in the aforementioned commit.
Since now the "two drivers" are split, the SCM dependency in the
main SPM handling is gone and for this reason it was also possible
to move the SPM initialization early: this will also make sure that
whenever the SAW CPUIdle driver is getting initialized, the SPM
driver will be ready to do the job.
Please note that the anticipation of the SPM initialization was
also done to optimize the boot times on platforms that have their
CPU/L2 idle states managed by other means (such as PSCI), while
needing SAW initialization for other purposes, like AVS control.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/cpuidle/Kconfig.arm| 1 +
drivers/cpuidle/cpuidle-qcom-spm.c | 294 ++---
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm.c | 198 +++
include/soc/qcom/spm.h | 45 +
6 files changed, 312 insertions(+), 236 deletions(-)
create mode 100644 drivers/soc/qcom/spm.c
create mode 100644 include/soc/qcom/spm.h
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 0844fadc4be8..c5e2f4d0df04 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -112,6 +112,7 @@ config ARM_QCOM_SPM_CPUIDLE
select CPU_IDLE_MULTIPLE_DRIVERS
select DT_IDLE_STATES
select QCOM_SCM
+ select QCOM_SPM
help
Select this to enable cpuidle for Qualcomm processors.
The Subsystem Power Manager (SPM) controls low power modes for the
diff --git a/drivers/cpuidle/cpuidle-qcom-spm.c
b/drivers/cpuidle/cpuidle-qcom-spm.c
index adf91a6e4d7d..3dd7bb10b82d 100644
--- a/drivers/cpuidle/cpuidle-qcom-spm.c
+++ b/drivers/cpuidle/cpuidle-qcom-spm.c
@@ -18,146 +18,13 @@
#include
#include
#include
+#include
#include
#include
#include "dt_idle_states.h"
-#define MAX_PMIC_DATA 2
-#define MAX_SEQ_DATA 64
-#define SPM_CTL_INDEX 0x7f
-#define SPM_CTL_INDEX_SHIFT4
-#define SPM_CTL_EN BIT(0)
-
-enum pm_sleep_mode {
- PM_SLEEP_MODE_STBY,
- PM_SLEEP_MODE_RET,
- PM_SLEEP_MODE_SPC,
- PM_SLEEP_MODE_PC,
- PM_SLEEP_MODE_NR,
-};
-
-enum spm_reg {
- SPM_REG_CFG,
- SPM_REG_SPM_CTL,
- SPM_REG_DLY,
- SPM_REG_PMIC_DLY,
- SPM_REG_PMIC_DATA_0,
- SPM_REG_PMIC_DATA_1,
- SPM_REG_VCTL,
- SPM_REG_SEQ_ENTRY,
- SPM_REG_SPM_STS,
- SPM_REG_PMIC_STS,
- SPM_REG_NR,
-};
-
-struct spm_reg_data {
- const u8 *reg_offset;
- u32 spm_cfg;
- u32 spm_dly;
- u32 pmic_dly;
- u32 pmic_data[MAX_PMIC_DATA];
- u8 seq[MAX_SEQ_DATA];
- u8 start_index[PM_SLEEP_MODE_NR];
-};
-
-struct spm_driver_data {
- struct cpuidle_driver cpuidle_driver;
- void __iomem *reg_base;
- const struct spm_reg_data *reg_data;
-};
-
-static const u8 spm_reg_offset_v2_1[SPM_REG_NR] = {
- [SPM_REG_CFG] = 0x08,
- [SPM_REG_SPM_CTL] = 0x30,
- [SPM_REG_DLY] = 0x34,
- [SPM_REG_SEQ_ENTRY] = 0x80,
-};
-
-/* SPM register data for 8974, 8084 */
-static const struct spm_reg_data spm_reg_8974_8084_cpu = {
- .reg_offset = spm_reg_offset_v2_1,
- .spm_cfg = 0x1,
- .spm_dly = 0x3C102800,
- .seq = { 0x03, 0x0B, 0x0F, 0x00, 0x20, 0x80, 0x10, 0xE8, 0x5B, 0x03,
- 0x3B, 0xE8, 0x5B, 0x82, 0x10, 0x0B, 0x30, 0x06, 0x26, 0x30,
- 0x0F },
- .start_index[PM_SLEEP_MODE_STBY] = 0,
- .start_index[PM_SLEEP_MODE_SPC] = 3,
-};
-
-static const u8 spm_reg_offset_v1_1[SPM_REG_NR] = {
- [SPM_REG_CFG] = 0x08,
- [SPM_REG_SPM_CTL] = 0x20,
- [SPM_REG_PMIC_DLY] = 0x24,
- [SPM_REG_PMIC_DATA_0] = 0x28,
- [SPM_REG_PMIC_DATA_1] = 0x2C,
- [SPM_REG_SEQ_ENTRY] = 0x80,
-};
-
-/* SPM register data for 8064 */
-static const struct spm_reg_data spm_reg_8064_cpu = {
- .reg_offset = spm_reg_offset_v1_1,
- .spm_cfg = 0x1F,
- .pmic_dly = 0x02020004,
- .pmic_data[0] = 0x0084009C,
- .pmic_data[1] = 0x00A4001C,
- .seq = { 0x03, 0x0F, 0x00, 0x24, 0x54, 0x10, 0x09, 0x03, 0x01,
- 0x10, 0x54, 0x30, 0x0C, 0x24, 0x30, 0x0F },
-
[PATCH v2 12/15] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property
From: Manivannan Sadhasivam Add devicetree documentation for 'qcom,freq-domain' property specific to Qualcomm CPUs. This property is used to reference the CPUFREQ node along with Domain ID (0/1). Signed-off-by: Manivannan Sadhasivam Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 14cd727d3c4b..1d60975df23a 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -290,6 +290,12 @@ properties: * arm/msm/qcom,kpss-acc.txt + qcom,freq-domain: +$ref: '/schemas/types.yaml#/definitions/phandle-array' +description: | + CPUs supporting freq-domain must set their "qcom,freq-domain" property + with phandle to a cpufreq_hw node followed by the Domain ID(0/1). + rockchip,pmu: $ref: '/schemas/types.yaml#/definitions/phandle' description: | -- 2.29.2
[PATCH v2 06/15] soc: qcom: cpr: Move common functions to new file
In preparation for implementing a new driver that will be handling
CPRv3, CPRv4 and CPR-Hardened, format out common functions to a new
file.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/cpr-common.c | 382 +
drivers/soc/qcom/cpr-common.h | 113 +
drivers/soc/qcom/cpr.c| 441 +++---
4 files changed, 523 insertions(+), 415 deletions(-)
create mode 100644 drivers/soc/qcom/cpr-common.c
create mode 100644 drivers/soc/qcom/cpr-common.h
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 24514c722832..778a2a5f07bb 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -3,7 +3,7 @@ CFLAGS_rpmh-rsc.o := -I$(src)
obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
-obj-$(CONFIG_QCOM_CPR) += cpr.o
+obj-$(CONFIG_QCOM_CPR) += cpr-common.o cpr.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
diff --git a/drivers/soc/qcom/cpr-common.c b/drivers/soc/qcom/cpr-common.c
new file mode 100644
index ..70e1e0f441db
--- /dev/null
+++ b/drivers/soc/qcom/cpr-common.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cpr-common.h"
+
+int cpr_read_efuse(struct device *dev, const char *cname, u32 *data)
+{
+ struct nvmem_cell *cell;
+ ssize_t len;
+ char *ret;
+ int i;
+
+ *data = 0;
+
+ cell = nvmem_cell_get(dev, cname);
+ if (IS_ERR(cell)) {
+ if (PTR_ERR(cell) != -EPROBE_DEFER)
+ dev_err(dev, "undefined cell %s\n", cname);
+ return PTR_ERR(cell);
+ }
+
+ ret = nvmem_cell_read(cell, );
+ nvmem_cell_put(cell);
+ if (IS_ERR(ret)) {
+ dev_err(dev, "can't read cell %s\n", cname);
+ return PTR_ERR(ret);
+ }
+
+ for (i = 0; i < len; i++)
+ *data |= ret[i] << (8 * i);
+
+ kfree(ret);
+ dev_dbg(dev, "efuse read(%s) = %x, bytes %zd\n", cname, *data, len);
+
+ return 0;
+}
+
+int cpr_populate_ring_osc_idx(struct device *dev,
+ struct fuse_corner *fuse_corner,
+ const struct cpr_fuse *cpr_fuse,
+ int num_fuse_corners)
+{
+ struct fuse_corner *end = fuse_corner + num_fuse_corners;
+ u32 data;
+ int ret;
+
+ for (; fuse_corner < end; fuse_corner++, cpr_fuse++) {
+ ret = cpr_read_efuse(dev, cpr_fuse->ring_osc,
+);
+ if (ret)
+ return ret;
+ fuse_corner->ring_osc_idx = data;
+ }
+
+ return 0;
+}
+
+int cpr_read_fuse_uV(int init_v_width, int step_size_uV, int ref_uV,
+int adj, int step_volt, const char *init_v_efuse,
+struct device *dev)
+{
+ int steps, uV;
+ u32 bits = 0;
+ int ret;
+
+ ret = cpr_read_efuse(dev, init_v_efuse, );
+ if (ret)
+ return ret;
+
+ steps = bits & (BIT(init_v_width - 1) - 1);
+ /* Not two's complement.. instead highest bit is sign bit */
+ if (bits & BIT(init_v_width - 1))
+ steps = -steps;
+
+ uV = ref_uV + steps * step_size_uV;
+
+ /* Apply open-loop fixed adjustments to fused values */
+ uV += adj;
+
+ return DIV_ROUND_UP(uV, step_volt) * step_volt;
+}
+
+const struct cpr_fuse *cpr_get_fuses(struct device *dev, int tid,
+int num_fuse_corners)
+{
+ struct cpr_fuse *fuses;
+ int i;
+
+ fuses = devm_kcalloc(dev, num_fuse_corners,
+sizeof(struct cpr_fuse),
+GFP_KERNEL);
+ if (!fuses)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < num_fuse_corners; i++) {
+ char tbuf[50];
+
+ snprintf(tbuf, sizeof(tbuf), "cpr%d_ring_osc%d", tid, i + 1);
+ fuses[i].ring_osc = devm_kstrdup(dev, tbuf, GFP_KERNEL);
+ if (!fuses[i].ring_osc)
+ return ERR_PTR(-ENOMEM);
+
+ snprintf(tbuf, sizeof(tbuf),
+"cpr%d_init_voltage%d", tid, i + 1);
+ fuses[i].init_voltage = devm_kstrdup(dev, tbuf,
+GFP_KERNEL);
+ if (!fuses[i].init_voltage)
+
[PATCH v2 00/15] Enable CPRh/3/4, CPU Scaling on various QCOM SoCs
Changes in v2: - Rebased qcom-cpufreq-hw dt-binding on top of Manivannan's patches - Fixed CPR and CPR3 YAML doc issues - Fixed bugs in qcom-cpufreq-hw: -- The APM corner number is now handled correctly when a corner with higher voltage than the maximum APM threshold is detected -- The APM corner number now gets written to the SEQ1 register, useful for older firmwares - Changes in CPR3: -- Memory footprint has been reduced, as unsigned int variables were changed to u8/u16 where applicable (a lot of them, actually) -- Some masks were wrong and have been fixed -- Min/max step quotients moved in thread descriptor, as they are not global on MSM8998 -- Fixed a bug about enabling thread aggregation on CPR hardware using one thread but multiple hw instances (these cannot be aggregated) -- Added calculations on post voltage adjustments for open and closed loop voltages, needed by MSM8998 -- Added some more safety checks around the corner voltage calculation -- Added fine-tuning open/closed loop based on fixed value offsets, needed by MSM8998 -- Fixed wrong scaling factor logic: it worked because I had lucky values on SDM630, but MSM8998 was an entirely different story!! I thought that these values were per-ring-oscillator, but it turns out that they are per-fuse-corner instead. Silly me! -- Added parameters and compatible for MSM8998 Silver/Gold clusters - Added MSM8998 to cpufreq-dt-platdev blacklist - Implemented dynamic Memory Accelerator corners support in both CPR3 and qcom-cpufreq-hw, needed by MSM8998 - Implemented ACD programming in qcom-cpufreq-hw, needed by MSM8998 - Added MSM8998 Silver/Gold parameters to the CPR3 (CPR-Hardened) driver - Fixed MSM8998 SAW parameters on SPM driver - Tested again on three different SDM630 smartphones (Xperia XA2/XA2Ultra/10) - Now also tested on two different MSM8998 smartphones (Xperia XZ Premium and F(x)Tec Pro1) This patch series is definitely big. Yup. But it all goes together... here's why: This series implements full support for CPU scaling on *many* Qualcomm SoCs and partial support for the others on which the Operating State Manager is not present. Since this is a bit tangled, let's go step by step. First of all, there's the SPM: this is a component that we can find on very old chips, like MSM8974; there, it has been used to actually do the power scaling basically "on its own" - sending the cores in a specific sleep mode to save power. On the newer ones, including MSM8998, SDM630, 660 and others, it is still present! Though, this time, it's being used for the cluster caches and it has a different firmware (and maybe it's also slightly different HW), implementing the SAWv4.1 set and getting controlled *not by the OS* but by other controllers in the SoC (like the OSM). Contrary from MSM8974 and the like, this new version of the SPM just requires us to set the initial parameters for AVS and *nothing else*, as its states will be totally managed internally. Then, hardening here we come! In all the new SoCs - as new as SM8150 and most probably even newer ones - there are also new versions of "the same old story".. and here I'm referring to the Core Power Reduction (CPR) block: since MSM8996 (or around that time frame), this block has got a sort of major change... which actually varies the register set and implements "threads". I won't go far with explaining that in this cover letter (as it's all explained in the commits) but, in short, here's the catch: CPR v3, v4 and CPR-Hardened are all based over the same register set and are extensions of their previous. A sort of special treatment must be given to CPR-Hardened (CPRh): this is the one that's present on the newest SoCs, as this is a hardened version of CPR4 and - in this version - it has got the ability to also get managed internally, along with the SAWv4.1, by the Operating State Manager (OSM). And finally, we get to the OSM. This final piece appeared on MSM8998 for the first time (as far as I know), and it is (a sort of microcontroller?) doing the "real deal": CPU DVFS through a lookup table providing "corners" - or "performance states" - to the OS; pretty straightforward way of offloading a whole lot of tasks that the kernel would otherwise have to do. And there we go with the full picture: - From SDM845 onwards, SAW, CPRh and OSM are getting setup by the bootloader/TZ *before* booting the OS, so then all the OS has to do is to request a specific performance state to the OSM hardware and forget about all the rest, which is anyway protected by the hypervisor (so there's no access anyway); BUT: - In MSM/APQ 8998, SDM/SDA 630/636/660 (and other variants), there is no setup of any of these puzzle pieces, and they're also (basically) fully accessible, which means that the OS must do it in order to get in the same state as the newer ones and to get the entire scaling hardware to start rolling. "Simply", that's it. Now that I've written a
[PATCH v2 08/15] dt-bindings: avs: cpr: Convert binding to YAML schema
Convert the qcom,cpr.txt document to YAML schema and place it in the
appropriate directory, since this driver was moved from power/avs
to soc/qcom, but forgets to move the documentation.
Fixes: a7305e684fcf ("PM: AVS: qcom-cpr: Move the driver to the qcom specific
drivers")
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/power/avs/qcom,cpr.txt | 131 +-
.../bindings/soc/qcom/qcom,cpr.yaml | 116
MAINTAINERS | 2 +-
3 files changed, 118 insertions(+), 131 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml
diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
b/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
index ab0d5ebbad4e..2ada8cd08949 100644
--- a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
+++ b/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt
@@ -1,130 +1 @@
-QCOM CPR (Core Power Reduction)
-
-CPR (Core Power Reduction) is a technology to reduce core power on a CPU
-or other device. Each OPP of a device corresponds to a "corner" that has
-a range of valid voltages for a particular frequency. While the device is
-running at a particular frequency, CPR monitors dynamic factors such as
-temperature, etc. and suggests adjustments to the voltage to save power
-and meet silicon characteristic requirements.
-
-- compatible:
- Usage: required
- Value type:
- Definition: should be "qcom,qcs404-cpr", "qcom,cpr" for qcs404
-
-- reg:
- Usage: required
- Value type:
- Definition: base address and size of the rbcpr register region
-
-- interrupts:
- Usage: required
- Value type:
- Definition: should specify the CPR interrupt
-
-- clocks:
- Usage: required
- Value type:
- Definition: phandle to the reference clock
-
-- clock-names:
- Usage: required
- Value type:
- Definition: must be "ref"
-
-- vdd-apc-supply:
- Usage: required
- Value type:
- Definition: phandle to the vdd-apc-supply regulator
-
-- #power-domain-cells:
- Usage: required
- Value type:
- Definition: should be 0
-
-- operating-points-v2:
- Usage: required
- Value type:
- Definition: A phandle to the OPP table containing the
- performance states supported by the CPR
- power domain
-
-- acc-syscon:
- Usage: optional
- Value type:
- Definition: phandle to syscon for writing ACC settings
-
-- nvmem-cells:
- Usage: required
- Value type:
- Definition: phandle to nvmem cells containing the data
- that makes up a fuse corner, for each fuse corner.
- As well as the CPR fuse revision.
-
-- nvmem-cell-names:
- Usage: required
- Value type:
- Definition: should be "cpr_quotient_offset1", "cpr_quotient_offset2",
- "cpr_quotient_offset3", "cpr_init_voltage1",
- "cpr_init_voltage2", "cpr_init_voltage3", "cpr_quotient1",
- "cpr_quotient2", "cpr_quotient3", "cpr_ring_osc1",
- "cpr_ring_osc2", "cpr_ring_osc3", "cpr_fuse_revision"
- for qcs404.
-
-Example:
-
- cpr_opp_table: cpr-opp-table {
- compatible = "operating-points-v2-qcom-level";
-
- cpr_opp1: opp1 {
- opp-level = <1>;
- qcom,opp-fuse-level = <1>;
- };
- cpr_opp2: opp2 {
- opp-level = <2>;
- qcom,opp-fuse-level = <2>;
- };
- cpr_opp3: opp3 {
- opp-level = <3>;
- qcom,opp-fuse-level = <3>;
- };
- };
-
- power-controller@b018000 {
- compatible = "qcom,qcs404-cpr", "qcom,cpr";
- reg = <0x0b018000 0x1000>;
- interrupts = <0 15 IRQ_TYPE_EDGE_RISING>;
- clocks = <_board>;
- clock-names = "ref";
- vdd-apc-supply = <_s3>;
- #power-domain-cells = <0>;
- operating-points-v2 = <_opp_table>;
- acc-syscon = <>;
-
- nvmem-cells = <_efuse_quot_offset1>,
- <_efuse_quot_offset2>,
- <_efuse_quot_offset3>,
- <_efuse_init_voltage1>,
- <_efuse_init_voltage2>,
- <_efuse_init_voltage3>,
- <_efuse_quot1>,
- <_efuse_quot2>,
- <_efuse_quot3>,
- <_efuse_ring1>,
- <_efuse_ring2>,
- <_efuse_ring3>,
- <_efuse_revision>;
- nvmem-cell-names = "cpr_quotient_offset1",
- "cpr_quotient_offset2",
-
[PATCH v2 13/15] dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings
From: Manivannan Sadhasivam
Convert Qualcomm cpufreq devicetree binding to YAML.
Signed-off-by: Manivannan Sadhasivam
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 ---
.../bindings/cpufreq/cpufreq-qcom-hw.yaml | 204 ++
2 files changed, 204 insertions(+), 172 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
deleted file mode 100644
index 9299028ee712..
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
+++ /dev/null
@@ -1,172 +0,0 @@
-Qualcomm Technologies, Inc. CPUFREQ Bindings
-
-CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
-SoCs to manage frequency in hardware. It is capable of controlling frequency
-for multiple clusters.
-
-Properties:
-- compatible
- Usage: required
- Value type:
- Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss".
-
-- clocks
- Usage: required
- Value type: From common clock binding.
- Definition: clock handle for XO clock and GPLL0 clock.
-
-- clock-names
- Usage: required
- Value type: From common clock binding.
- Definition: must be "xo", "alternate".
-
-- reg
- Usage: required
- Value type:
- Definition: Addresses and sizes for the memory of the HW bases in
- each frequency domain.
-- reg-names
- Usage: Optional
- Value type:
- Definition: Frequency domain name i.e.
- "freq-domain0", "freq-domain1".
-
-- #freq-domain-cells:
- Usage: required.
- Definition: Number of cells in a freqency domain specifier.
-
-* Property qcom,freq-domain
-Devices supporting freq-domain must set their "qcom,freq-domain" property with
-phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node.
-
-
-Example:
-
-Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch
-DCVS state together.
-
-/ {
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- CPU0: cpu@0 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x0>;
- enable-method = "psci";
- next-level-cache = <_0>;
- qcom,freq-domain = <_hw 0>;
- L2_0: l2-cache {
- compatible = "cache";
- next-level-cache = <_0>;
- L3_0: l3-cache {
- compatible = "cache";
- };
- };
- };
-
- CPU1: cpu@100 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x100>;
- enable-method = "psci";
- next-level-cache = <_100>;
- qcom,freq-domain = <_hw 0>;
- L2_100: l2-cache {
- compatible = "cache";
- next-level-cache = <_0>;
- };
- };
-
- CPU2: cpu@200 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x200>;
- enable-method = "psci";
- next-level-cache = <_200>;
- qcom,freq-domain = <_hw 0>;
- L2_200: l2-cache {
- compatible = "cache";
- next-level-cache = <_0>;
- };
- };
-
- CPU3: cpu@300 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x300>;
- enable-method = "psci";
- next-level-cache = <_300>;
- qcom,freq-domain = <_hw 0>;
- L2_300: l2-cache {
- compatible = "cache";
- next-level-cache = <_0>;
- };
- };
-
- CPU4: cpu@400 {
- device_type = "cpu";
- compatible = "qcom,kryo385";
- reg = <0x0 0x400>;
- enable-method = "psci";
- next-level-cache = <_400>;
- qcom,freq-domain =
[PATCH v2 09/15] soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened
This commit introduces a new driver, based on the one for cpr v1,
to enable support for the newer Qualcomm Core Power Reduction
hardware, known downstream as CPR3, CPR4 and CPRh, and support
for MSM8998 and SDM630 CPU power reduction.
In these new versions of the hardware, support for various new
features was introduced, including voltage reduction for the GPU,
security hardening and a new way of controlling CPU DVFS,
consisting in internal communication between microcontrollers,
specifically the CPR-Hardened and the Operating State Manager.
The CPR v3, v4 and CPRh are present in a broad range of SoCs,
from the mid-range to the high end ones including, but not limited
to, MSM8953/8996/8998, SDM630/636/660/845.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/Kconfig | 17 +
drivers/soc/qcom/Makefile |1 +
drivers/soc/qcom/cpr-common.c | 35 +-
drivers/soc/qcom/cpr-common.h |4 +
drivers/soc/qcom/cpr3.c | 2905 +
5 files changed, 2956 insertions(+), 6 deletions(-)
create mode 100644 drivers/soc/qcom/cpr3.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 37f22dcd20af..9d3f35fc4ab1 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -42,6 +42,23 @@ config QCOM_CPR
To compile this driver as a module, choose M here: the module will
be called qcom-cpr
+config QCOM_CPR3
+ tristate "QCOM Core Power Reduction (CPR v3/v4/Hardened) support"
+ depends on ARCH_QCOM && HAS_IOMEM
+ select PM_OPP
+ select REGMAP
+ help
+ Say Y here to enable support for the CPR hardware found on a broad
+ variety of Qualcomm SoCs like MSM8996, MSM8998, SDM630, SDM660,
+ SDM845 and others.
+
+ This driver populates OPP tables and makes adjustments to them
+ based on feedback from the CPR hardware. If you want to do CPU
+ and/or GPU frequency scaling say Y here.
+
+ To compile this driver as a module, choose M here: the module will
+ be called qcom-cpr3
+
config QCOM_GENI_SE
tristate "QCOM GENI Serial Engine Driver"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 778a2a5f07bb..0500283c2dc5 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_CPR) += cpr-common.o cpr.o
+obj-$(CONFIG_QCOM_CPR3)+= cpr-common.o cpr3.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
diff --git a/drivers/soc/qcom/cpr-common.c b/drivers/soc/qcom/cpr-common.c
index 70e1e0f441db..8a2650c94a10 100644
--- a/drivers/soc/qcom/cpr-common.c
+++ b/drivers/soc/qcom/cpr-common.c
@@ -252,6 +252,29 @@ u32 cpr_get_fuse_corner(struct dev_pm_opp *opp, u32 tid)
of_node_put(np);
return fc;
+
+}
+
+void cpr_get_corner_post_vadj(struct dev_pm_opp *opp, u32 tid,
+ s32 *open_loop, s32 *closed_loop)
+{
+ struct device_node *np;
+
+ /*
+* There is no of_property_read_s32_index, so we just store the
+* result into a s32 variable. After all, the OF API is doing
+* the exact same for of_property_read_s32...
+*/
+ np = dev_pm_opp_get_of_node(opp);
+ if (of_property_read_u32_index(np, "qcom,opp-oloop-vadj", tid,
+ open_loop))
+ *open_loop = 0;
+
+ if (of_property_read_u32_index(np, "qcom,opp-cloop-vadj", tid,
+ closed_loop))
+ *closed_loop = 0;
+
+ of_node_put(np);
}
unsigned long cpr_get_opp_hz_for_req(struct dev_pm_opp *ref,
@@ -294,11 +317,10 @@ int cpr_calculate_scaling(const char *quot_offset,
const struct fuse_corner_data *fdata,
const struct corner *corner)
{
- u32 quot_diff = 0;
- unsigned long freq_diff;
- int scaling;
+ u64 freq_diff;
const struct fuse_corner *fuse, *prev_fuse;
- int ret;
+ u32 quot_diff;
+ int scaling, ret;
fuse = corner->fuse_corner;
prev_fuse = fuse - 1;
@@ -315,8 +337,9 @@ int cpr_calculate_scaling(const char *quot_offset,
}
freq_diff = fuse->max_freq - prev_fuse->max_freq;
- freq_diff /= 100; /* Convert to MHz */
- scaling = 1000 * quot_diff / freq_diff;
+ freq_diff = div_u64(freq_diff, 100); /* Convert to MHz */
+ scaling = 1000 * quot_diff;
+ do_div(scaling, freq_diff);
return min(scaling, fdata->max_quot_scale);
}
diff --git a/drivers/soc/qcom/cpr-common.h b/drivers/soc/qcom/cpr-common.h
index 83a1f7c941b8..96ff6301c81e 100644
---
[PATCH v7 0/7] Netronix embedded controller driver for Kobo and Tolino ebook readers
This patchset adds basic support for the embedded controller found on older ebook reader boards designed by/with the ODM Netronix Inc.[1] and sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine. These drivers are based on information contained in the vendor kernel sources, but in order to all information in a single place, I documented the register interface of the EC on GitHub[2]. [1]: http://www.netronixinc.com/products.aspx?ID=1 [2]: https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller v7: - Adjust the RTC patch to a change in the RTC API: rtc_register_device is now devm_rtc_register_device. - Add a #define for the known firmware version (0xd726). Lee Jones suggested doing this in a follow-up patch, but since I'm respinning the series anyway, I'm doing it here. v6: - Additional cleanups in the PWM driver - Added Lee Jones' ACK to the MFD driver patch v5: - https://lore.kernel.org/lkml/20201201011513.1627028-1-j.neuschae...@gmx.net/ - Avoid truncation of PWM period and duty cycle to 32 bits - A few cleanups and additional comments in the PWM driver - Use regmap_multi_reg_write v4: - https://lore.kernel.org/lkml/2020112739.1455132-1-j.neuschae...@gmx.net/ - Spell out ODM (original design manufacturer) - Solve corner cases in the RTC driver - Clean up use of log levels vs. error codes - Add more comments explaining some peculiarities - Add missing MODULE_ALIAS lines - Various other cleanups v3: - https://lore.kernel.org/lkml/20200924192455.2484005-1-j.neuschae...@gmx.net/ - A few code cleanups - A few devicetree related cleanups - PWM and RTC functionality were moved from subnodes in the devicetree to the main node. This also means that the subdrivers no longer need DT compatible strings, but are instead loaded via the mfd_cell mechanism. - The drivers are now published under GPLv2-or-later rather than GPLv2-only. v2: - https://lore.kernel.org/lkml/20200905133230.1014581-1-j.neuschae...@gmx.net/ - Moved txt DT bindings to patch descriptions and removed patch 1/10 "DT bindings in plain text format" - New patch 7/10 "rtc: Introduce RTC_TIMESTAMP_END_2255" - Rebased on 5.9-rc3 - Various other changes which are documented in each patch v1: - https://lore.kernel.org/lkml/20200620223915.1311485-1-j.neuschae...@gmx.net/ Jonathan Neuschäfer (7): dt-bindings: Add vendor prefix for Netronix, Inc. dt-bindings: mfd: Add binding for Netronix embedded controller mfd: Add base driver for Netronix embedded controller pwm: ntxec: Add driver for PWM function in Netronix EC rtc: New driver for RTC in Netronix embedded controller MAINTAINERS: Add entry for Netronix embedded controller ARM: dts: imx50-kobo-aura: Add Netronix embedded controller .../bindings/mfd/netronix,ntxec.yaml | 76 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 9 + arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +- drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/ntxec.c | 216 ++ drivers/pwm/Kconfig | 8 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-ntxec.c | 182 +++ drivers/rtc/Kconfig | 8 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-ntxec.c | 143 include/linux/mfd/ntxec.h | 37 +++ 14 files changed, 710 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml create mode 100644 drivers/mfd/ntxec.c create mode 100644 drivers/pwm/pwm-ntxec.c create mode 100644 drivers/rtc/rtc-ntxec.c create mode 100644 include/linux/mfd/ntxec.h -- 2.29.2
[PATCH v2 14/15] cpufreq: qcom-hw: Implement CPRh aware OSM programming
On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is being programmed in the bootloader and write-protected by the hypervisor, leaving to the OS read-only access to some of its registers (in order to read the Lookup Tables and also some status registers) and write access to the p-state register, for for the OS to request a specific performance state to trigger a DVFS switch on the CPU through the OSM hardware. On old SoCs though (MSM8998, SDM630/660 and variants), the bootloader will *not* initialize the OSM (and the CPRh, as it is a requirement for it) before booting the OS, making any request to trigger a performance state change ineffective, as the hardware doesn't have any Lookup Table, nor is storing any parameter to trigger a DVFS switch. In this case, basically all of the OSM registers are *not* write protected for the OS, even though some are - but write access is granted through SCM calls. This commit introduces support for OSM programming, which has to be done on these old SoCs that were distributed (almost?) always with a bootloader that does not do any CPRh nor OSM init before booting the kernel. In order to program the OSM on these SoCs, it is necessary to fullfill a "special" requirement: the Core Power Reduction Hardened (CPRh) hardware block must be initialized, as the OSM is "talking" to it in order to perform the Voltage part of DVFS; here, we are calling initialization of this through Linux generic power domains, specifically by requesting a genpd attach from the qcom-cpufreq-hw driver, which will give back voltages associated to each CPU frequency that has been declared in the OPPs, scaled and interpolated with the previous one, and will also give us parameters for the Array Power Mux (APM) and mem-acc, in order for this driver to be then able to generate the Lookup Tables that will be finally programmed to the OSM hardware. After writing the parameters to the OSM and enabling it, all the programming work will never happen anymore until a OS reboot, so all of the allocations and "the rest" will be disposed-of: this is done mainly to leave the code that was referred only to the new SoCs intact, as to also emphasize on the fact that the OSM HW is, in the end, the exact same; apart some register offsets that are slightly different, the entire logic is the same. This also adds the parameters to support CPU scaling on SDM630 and MSM8998. Signed-off-by: AngeloGioacchino Del Regno --- drivers/cpufreq/qcom-cpufreq-hw.c | 1240 - 1 file changed, 1210 insertions(+), 30 deletions(-) diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c index 9ed5341dc515..9d8544bbc842 100644 --- a/drivers/cpufreq/qcom-cpufreq-hw.c +++ b/drivers/cpufreq/qcom-cpufreq-hw.c @@ -1,33 +1,256 @@ // SPDX-License-Identifier: GPL-2.0 /* * Copyright (c) 2018, The Linux Foundation. All rights reserved. + * + * OSM hardware initial programming + * Copyright (C) 2020, AngeloGioacchino Del Regno + * */ #include #include +#include #include #include #include #include #include #include +#include #include #include +#include #define LUT_MAX_ENTRIES40U -#define LUT_SRCGENMASK(31, 30) +#define LUT_SRC_845GENMASK(31, 30) +#define LUT_SRC_8998 GENMASK(27, 26) +#define LUT_PLL_DIVGENMASK(25, 24) #define LUT_L_VAL GENMASK(7, 0) #define LUT_CORE_COUNT GENMASK(18, 16) +#define LUT_VOLT_VCGENMASK(21, 16) #define LUT_VOLT GENMASK(11, 0) -#define CLK_HW_DIV 2 #define LUT_TURBO_IND 1 +#define OSM_BOOT_TIME_US 5 + +#define CYCLE_COUNTER_CLK_RATIOGENMASK(5, 1) +#define OSM_XO_RATIO_VAL (10 - 1) +#define CYCLE_COUNTER_USE_XO_EDGE BIT(8) + +/* FSM Boost Control */ +#define CC_BOOST_ENBIT(0) +#define PS_BOOST_ENBIT(1) +#define DCVS_BOOST_EN BIT(2) +#define BOOST_TIMER_REG_HI GENMASK(31, 16) +#define BOOST_TIMER_REG_LO GENMASK(15, 0) + +#define PLL_WAIT_LOCK_TIME_NS 2000 +#define SAFE_FREQ_WAIT_NS 1000 +#define DEXT_DECREMENT_WAIT_NS 200 + +#define BOOST_SYNC_DELAY 5 + +#define HYSTERESIS_UP_MASK GENMASK(31, 16) +#define HYSTERESIS_DN_MASK GENMASK(15, 0) +#define HYSTERESIS_CC_NS 200 +#define HYSTERESIS_LLM_NS 65535 + +/* FSM Droop Control */ +#define PC_RET_EXIT_DROOP_EN BIT(3) +#define WFX_DROOP_EN BIT(4) +#define DCVS_DROOP_EN BIT(5) +#define DROOP_TIMER1 GENMASK(31, 16) +#define DROOP_TIMER0 GENMASK(15, 0) +#define DROOP_CTRL_VAL (BIT(3) | BIT(17) | BIT(31)) +#define
[PATCH v2 05/15] cpufreq: blacklist MSM8998 in cpufreq-dt-platdev
Add the MSM8998 to the blacklist since the CPU scaling is handled
out of this.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index d8935e525807..bc1ac5971dbe 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -131,6 +131,7 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "qcom,apq8096", },
{ .compatible = "qcom,msm8996", },
+ { .compatible = "qcom,msm8998", },
{ .compatible = "qcom,qcs404", },
{ .compatible = "qcom,sc7180", },
{ .compatible = "qcom,sdm630", },
--
2.29.2
[PATCH v2 02/15] soc: qcom: spm: Implement support for SAWv4.1, SDM630/660 L2 AVS
Implement the support for SAW v4.1, used in at least MSM8998,
SDM630, SDM660 and APQ variants and, while at it, also add the
configuration for the SDM630/660 Silver and Gold cluster L2
Adaptive Voltage Scaler: this is also one of the prerequisites
to allow the OSM controller to perform DCVS.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/spm.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
index 0c8aa9240c41..843732d12c54 100644
--- a/drivers/soc/qcom/spm.c
+++ b/drivers/soc/qcom/spm.c
@@ -32,9 +32,28 @@ enum spm_reg {
SPM_REG_SEQ_ENTRY,
SPM_REG_SPM_STS,
SPM_REG_PMIC_STS,
+ SPM_REG_AVS_CTL,
+ SPM_REG_AVS_LIMIT,
SPM_REG_NR,
};
+static const u16 spm_reg_offset_v4_1[SPM_REG_NR] = {
+ [SPM_REG_AVS_CTL] = 0x904,
+ [SPM_REG_AVS_LIMIT] = 0x908,
+};
+
+static const struct spm_reg_data spm_reg_660_gold_l2 = {
+ .reg_offset = spm_reg_offset_v4_1,
+ .avs_ctl = 0x1010031,
+ .avs_limit = 0x4580458,
+};
+
+static const struct spm_reg_data spm_reg_660_silver_l2 = {
+ .reg_offset = spm_reg_offset_v4_1,
+ .avs_ctl = 0x101c031,
+ .avs_limit = 0x4580458,
+};
+
static const u16 spm_reg_offset_v2_1[SPM_REG_NR] = {
[SPM_REG_CFG] = 0x08,
[SPM_REG_SPM_CTL] = 0x30,
@@ -126,6 +145,10 @@ void spm_set_low_power_mode(struct spm_driver_data *drv,
}
static const struct of_device_id spm_match_table[] = {
+ { .compatible = "qcom,sdm660-gold-saw2-v4.1-l2",
+ .data = _reg_660_gold_l2 },
+ { .compatible = "qcom,sdm660-silver-saw2-v4.1-l2",
+ .data = _reg_660_silver_l2 },
{ .compatible = "qcom,msm8974-saw2-v2.1-cpu",
.data = _reg_8974_8084_cpu },
{ .compatible = "qcom,apq8084-saw2-v2.1-cpu",
@@ -169,6 +192,8 @@ static int spm_dev_probe(struct platform_device *pdev)
* CPU was held in reset, the reset signal could trigger the SPM state
* machine, before the sequences are completely written.
*/
+ spm_register_write(drv, SPM_REG_AVS_CTL, drv->reg_data->avs_ctl);
+ spm_register_write(drv, SPM_REG_AVS_LIMIT, drv->reg_data->avs_limit);
spm_register_write(drv, SPM_REG_CFG, drv->reg_data->spm_cfg);
spm_register_write(drv, SPM_REG_DLY, drv->reg_data->spm_dly);
spm_register_write(drv, SPM_REG_PMIC_DLY, drv->reg_data->pmic_dly);
@@ -178,7 +203,8 @@ static int spm_dev_probe(struct platform_device *pdev)
drv->reg_data->pmic_data[1]);
/* Set up Standby as the default low power mode */
- spm_set_low_power_mode(drv, PM_SLEEP_MODE_STBY);
+ if (drv->reg_data->reg_offset[SPM_REG_SPM_CTL])
+ spm_set_low_power_mode(drv, PM_SLEEP_MODE_STBY);
return 0;
}
--
2.29.2
[PATCH v2 11/15] dt-bindings: soc: qcom: cpr3: Add bindings for CPR3 driver
Add the bindings for the CPR3 driver to the documentation.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/soc/qcom/qcom,cpr3.yaml | 241 ++
1 file changed, 241 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
b/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
new file mode 100644
index ..e2753740c86b
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
@@ -0,0 +1,241 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/qcom/qcom,cpr3.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm Core Power Reduction v3/v4/Hardened (CPR3, CPR4, CPRh)
+
+description: |
+ CPR (Core Power Reduction) is a technology to reduce core power on a CPU
+ or other device. Each OPP of a device corresponds to a "corner" that has
+ a range of valid voltages for a particular frequency. While the device is
+ running at a particular frequency, CPR monitors dynamic factors such as
+ temperature, etc. and suggests or, in the CPR-Hardened case performs,
+ adjustments to the voltage to save power and meet silicon characteristic
+ requirements.
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+properties:
+ compatible:
+oneOf:
+ - description: CPRv3 controller
+items:
+ - const: qcom,cpr3
+ - description: CPRv4 controller
+items:
+ - const: qcom,cpr4
+ - description: CPRv4-Hardened controller
+items:
+ - enum:
+ - qcom,msm8998-cprh
+ - qcom,sdm630-cprh
+ - const: qcom,cprh
+
+ reg:
+description: Base address and size of the CPR controller(s)
+minItems: 1
+maxItems: 2
+
+ interrupts:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: "ref"
+
+ clocks:
+items:
+ - description: CPR reference clock
+
+ vdd-supply:
+description: Autonomous Phase Control (APC) or other power supply
+
+ '#power-domain-cells':
+const: 1
+
+ acc-syscon:
+description: phandle to syscon for writing ACC settings
+
+ nvmem-cells:
+description: Cells containing the fuse corners and revision data
+minItems: 10
+maxItems: 32
+
+ nvmem-cell-names:
+minItems: 10
+maxItems: 32
+
+ operating-points-v2: true
+
+required:
+ - compatible
+ - reg
+ - clock-names
+ - clocks
+ - "#power-domain-cells"
+ - nvmem-cells
+ - nvmem-cell-names
+ - operating-points-v2
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+cpus {
+#address-cells = <2>;
+#size-cells = <0>;
+
+cpu@0 {
+compatible = "qcom,kryo280";
+device_type = "cpu";
+reg = <0x0 0x0>;
+operating-points-v2 = <_gold_opp_table>;
+power-domains = <_cprh 0>;
+power-domain-names = "cprh";
+};
+
+cpu@100 {
+compatible = "qcom,kryo280";
+device_type = "cpu";
+reg = <0x0 0x0>;
+operating-points-v2 = <_silver_opp_table>;
+power-domains = <_cprh 1>;
+power-domain-names = "cprh";
+};
+};
+
+cpu_silver_opp_table: cpu-silver-opp-table {
+compatible = "operating-points-v2";
+opp-shared;
+
+opp-184320 {
+opp-hz = /bits/ 64 <184320>;
+required-opps = <_opp3>;
+};
+opp-109440 {
+opp-hz = /bits/ 64 <109440>;
+required-opps = <_opp2>;
+};
+opp-3 {
+opp-hz = /bits/ 64 <3>;
+required-opps = <_opp1>;
+};
+};
+
+cpu_gold_opp_table: cpu-gold-opp-table {
+compatible = "operating-points-v2";
+opp-shared;
+
+opp-220800 {
+opp-hz = /bits/ 64 <220800>;
+required-opps = <_opp3>;
+};
+opp-111360 {
+opp-hz = /bits/ 64 <111360>;
+required-opps = <_opp2>;
+};
+opp-3 {
+opp-hz = /bits/ 64 <3>;
+required-opps = <_opp1>;
+};
+};
+
+cprh_opp_table: cpr-hardened-opp-table {
+compatible = "operating-points-v2-qcom-level";
+
+cprh_opp1: opp1 {
+opp-level = <1>;
+qcom,opp-fuse-level = <1>;
+};
+cprh_opp2: opp2 {
+opp-level = <2>;
+qcom,opp-fuse-level = <2>;
+};
+cprh_opp3: opp3 {
+opp-level = <3>;
+qcom,opp-fuse-level = <2 3>;
+};
+};
+
+apc_cprh: power-controller@179c8000 {
+compatible = "qcom,msm8998-cprh", "qcom,cprh";
+reg = <0x0179c8000 0x4000>, <0x0179c4000 0x4000>;
+clocks = < GCC_HMSS_RBCPR_CLK>;
+clock-names = "ref";
+
+
[PATCH v2 04/15] cpufreq: blacklist SDM630/636/660 in cpufreq-dt-platdev
Add the SDM630, SDM636 and SDM660 to the blacklist since the CPU
scaling is handled out of this.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3776d960f405..d8935e525807 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -133,6 +133,9 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "qcom,msm8996", },
{ .compatible = "qcom,qcs404", },
{ .compatible = "qcom,sc7180", },
+ { .compatible = "qcom,sdm630", },
+ { .compatible = "qcom,sdm636", },
+ { .compatible = "qcom,sdm660", },
{ .compatible = "qcom,sdm845", },
{ .compatible = "st,stih407", },
--
2.29.2
[PATCH v2 15/15] dt-bindings: cpufreq: qcom-hw: Add bindings for 8998
The OSM programming addition has been done under the qcom,cpufreq-hw-8998 compatible name: specify the requirement of two additional register spaces for this functionality. This implementation, with the same compatible, has been tested on MSM8998 and SDM630. Signed-off-by: AngeloGioacchino Del Regno --- .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 44 --- 1 file changed, 39 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index bc81b6203e27..0bf539954558 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -18,6 +18,10 @@ description: | properties: compatible: oneOf: + - description: Non-secure v1 of CPUFREQ HW +items: + - const: qcom,cpufreq-hw-8998 + - description: v1 of CPUFREQ HW items: - const: qcom,cpufreq-hw @@ -30,19 +34,27 @@ properties: reg: minItems: 2 -maxItems: 3 +maxItems: 7 items: - description: Frequency domain 0 register region - description: Frequency domain 1 register region - description: Frequency domain 2 register region + - description: PLL ACD domain 0 register region + - description: PLL ACD domain 1 register region + - description: Operating State Manager domain 0 register region + - description: Operating State Manager domain 1 register region reg-names: minItems: 2 -maxItems: 3 +maxItems: 7 items: - - const: freq-domain0 - - const: freq-domain1 - - const: freq-domain2 + - const: "freq-domain0" + - const: "freq-domain1" + - const: "freq-domain2" + - const: "osm-acd0" + - const: "osm-acd1" + - const: "osm-domain0" + - const: "osm-domain1" clocks: items: @@ -57,6 +69,28 @@ properties: '#freq-domain-cells': const: 1 +allOf: + - if: + properties: + reg-names: + contains: + const: qcom,cpufreq-hw-8998 + then: + properties: + reg: + minItems: 4 + maxItems: 6 + reg-names: + items: + minItems: 4 + else: + properties: + reg: + maxItems: 3 + reg-names: + items: + maxItems: 3 + required: - compatible - reg -- 2.29.2
[PATCH v2 07/15] arm64: qcom: qcs404: Change CPR nvmem-names
The CPR driver's common functions were split and put in another
file in order to support newer CPR revisions: to simplify the
commonization, the expected names of the fuses had to be changed
in order for both new and old support to use the same fuse name
retrieval function and keeping the naming consistent.
The thread id was added to the fuse name and, since CPRv1 does
not support threads, it is expected to always read ID 0, which
means that the expected name here is now "cpr0_(fuse_name)"
instead of "cpr_(fuse_name)": luckily, QCS404 is the only user
so change it accordingly.
Signed-off-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index b654b802e95c..5d5a33c7eb82 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -1168,19 +1168,19 @@ cpr: power-controller@b018000 {
<_efuse_ring2>,
<_efuse_ring3>,
<_efuse_revision>;
- nvmem-cell-names = "cpr_quotient_offset1",
- "cpr_quotient_offset2",
- "cpr_quotient_offset3",
- "cpr_init_voltage1",
- "cpr_init_voltage2",
- "cpr_init_voltage3",
- "cpr_quotient1",
- "cpr_quotient2",
- "cpr_quotient3",
- "cpr_ring_osc1",
- "cpr_ring_osc2",
- "cpr_ring_osc3",
- "cpr_fuse_revision";
+ nvmem-cell-names = "cpr0_quotient_offset1",
+ "cpr0_quotient_offset2",
+ "cpr0_quotient_offset3",
+ "cpr0_init_voltage1",
+ "cpr0_init_voltage2",
+ "cpr0_init_voltage3",
+ "cpr0_quotient1",
+ "cpr0_quotient2",
+ "cpr0_quotient3",
+ "cpr0_ring_osc1",
+ "cpr0_ring_osc2",
+ "cpr0_ring_osc3",
+ "cpr0_fuse_revision";
};
timer@b12 {
--
2.29.2
[PATCH v2 03/15] soc: qcom: spm: Add compatible for MSM8998 SAWv4.1 L2
Add the SAWv4.1 parameters for MSM8998's Gold and Silver clusters.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/spm.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
index 843732d12c54..2e6312663293 100644
--- a/drivers/soc/qcom/spm.c
+++ b/drivers/soc/qcom/spm.c
@@ -54,6 +54,18 @@ static const struct spm_reg_data spm_reg_660_silver_l2 = {
.avs_limit = 0x4580458,
};
+static const struct spm_reg_data spm_reg_8998_gold_l2 = {
+ .reg_offset = spm_reg_offset_v4_1,
+ .avs_ctl = 0x1010031,
+ .avs_limit = 0x4700470,
+};
+
+static const struct spm_reg_data spm_reg_8998_silver_l2 = {
+ .reg_offset = spm_reg_offset_v4_1,
+ .avs_ctl = 0x1010031,
+ .avs_limit = 0x4200420,
+};
+
static const u16 spm_reg_offset_v2_1[SPM_REG_NR] = {
[SPM_REG_CFG] = 0x08,
[SPM_REG_SPM_CTL] = 0x30,
@@ -149,6 +161,10 @@ static const struct of_device_id spm_match_table[] = {
.data = _reg_660_gold_l2 },
{ .compatible = "qcom,sdm660-silver-saw2-v4.1-l2",
.data = _reg_660_silver_l2 },
+ { .compatible = "qcom,msm8998-gold-saw2-v4.1-l2",
+ .data = _reg_8998_gold_l2 },
+ { .compatible = "qcom,msm8998-silver-saw2-v4.1-l2",
+ .data = _reg_8998_silver_l2 },
{ .compatible = "qcom,msm8974-saw2-v2.1-cpu",
.data = _reg_8974_8084_cpu },
{ .compatible = "qcom,apq8084-saw2-v2.1-cpu",
--
2.29.2
Re: [RFC 2/2] clk: vc5: Add support for optional load capacitance
Hi Adam,
On 09/01/21 04:00, Adam Ford wrote:
> On Fri, Jan 8, 2021 at 4:49 PM Luca Ceresoli wrote:
>>
>> Hi Adam,
>>
>> On 06/01/21 18:39, Adam Ford wrote:
>>> There are two registers which can set the load capacitance for
>>> XTAL1 and XTAL2. These are optional registers when using an
>>> external crystal. Parse the device tree and set the
>>> corresponding registers accordingly.
>>
>> No need to repeat the first 2 sentences, they are already in patch 1.
>
> The reason I did that was because if someone does a git log on the
> individual file, they'd see the comment. While it's redundant not, it
> might not be as obvious in the future when looking back. Not
> everyone reviews the history of the binding, but the source files' git
> logs usually have some value. However, if you want me to drop it or
> rephrase it, I can do that.
Makes sense, I had never considered that before.
>>> +static int vc5_map_cap_value(u32 femtofarads)
>>> +{
>>> + int mapped_value;
>>> +
>>> + /* The datasheet explicitly states 9000 - 25000 */
>>> + if ((femtofarads < 9000) || (femtofarads > 25000))
>>> + return -EINVAL;
>>> +
>>> + /* The lowest target we can hit is 9430, so exit if it's less */
>>> + if (femtofarads < 9430)
>>> + return 0;
>>> +
>>> + /*
>>> + * According to VersaClock 6E Programming Guide, there are 6
>>> + * bits which translate to 64 entries in XTAL registers 12 and
>>> + * 13. Because bits 0 and 1 increase the capacitance the
>>> + * same, some of the values can be repeated. Plugging this
>>> + * into a spreadsheet and generating a trendline, the output
>>> + * equation becomes x = (y-9098.29) / 216.44, where 'y' is
>>> + * the desired capacitance in femtofarads, and x is the value
>>> + * of XTAL[5:0].
>>> + * To help with rounding, do fixed point math
>>> + */
>>> + femtofarads *= 100;
>>> + mapped_value = (femtofarads - 909829) / 21644;
>>
>> Thanks for the extensive comment, but I am confused. Not by your code
>> which is very clean and readable, but by the chip documentation
>> (disclaimer: I haven't read it in full depth).
>
> I was confused too since the datasheet and programmers manual differ a bit.
>>
>> The 5P49V6965 datasheet at page 17 clearly states capacitance can be
>> increased in 0.5 pF steps. The "VersaClock 6E Family Register
>> Descriptions and Programming Guide" at page 18 shows a table that allows
>> 0.43 pF. Can you clarify how the thing works?
>
> I used the Versaclock 6E doc which is based on the following:
>
> BIT 5 - Add 6.92pF
> BIT 4 - Add 3.46pF
> BIT 3 - Add 1.73pF
> BIT 2 - Add 0.86pF
> Bit 1 - Add 0.43pF
> Bit 0 - Add 0.43pF
>
> Because the Datasheet starts at 9pF, the math I used, assumes these
> numbers are added to 9pF.
> Because the datasheet shows the increments are in .5pF increments, the
> 430nF seems close. The datasheet shows 9pF - 25pF and based on the
> programmer table, we could get close to 25pF by enabling all bits and
> adding 9pF, however the math doesn't quite hit 25pF.
>
> For what it's worth I needed around 11.5pF, and with this patch, the
> hardware engineer said our ppm went from around 70 ppm to around 4ppm.
Did he measure what happens if you set the register according to the 0.5
pF interpretation? Does it improve? I understand the difference is
probably olwer than the noise, but who knows.
>>> +
>>> + /*
>>> + * The datasheet states, the maximum capacitance is 25000,
>>> + * but the programmer guide shows a max value is 22832,
>>> + * so values higher values could overflow, so cap it.
>>> + */
>>
>> The 22832 limit is if you assume 0.43 pF steps. Assuming 0.5 pF steps
>> leads to 25000. Now I am more confused than before.
>
> I agree. It would be nice to get some clarification from Renesas.
Definitely. Do you have access to some support from them?
I don't think I have, but I can ask next week.
Regards.
--
Luca
Re: [BUG mips llvm] MIPS: malformed R_MIPS_{HI16,LO16} with LLVM
On Sat, Jan 9, 2021 at 9:11 AM Alexander Lobakin wrote: > > Machine: MIPS32 R2 Big Endian (interAptiv (multi)) > > While testing MIPS with LLVM, I found a weird and very rare bug with > MIPS relocs that LLVM emits into kernel modules. It happens on both > 11.0.0 and latest git snapshot and applies, as I can see, only to > references to static symbols. > > When the kernel loads the module, it allocates a space for every > section and then manually apply the relocations relative to the > new address. > > Let's say we have a function phy_probe() in drivers/net/phy/libphy.ko. > It's static and referenced only in phy_register_driver(), where it's > used to fill callback pointer in a structure. > > The real function address after module loading is 0xc06c1444, that > is observed in its ELF st_value field. > There are two relocs related to this usage in phy_register_driver(): > > R_MIPS_HI16 refers to 0x3c01 > R_MIPS_LO16 refers to 0x24339444 > > The address of .text is 0xc06b8000. So the destination is calculated > as follows: > > 0x from hi16; > 0x9444 from lo16 (sign extend as it's always treated as signed); > 0xc06b8000 from base. > > = 0xc06b1444. The value is lower than the real phy_probe() address > (0xc06c1444) by 0x1 and is lower than the base address of > module's .text, so it's 100% incorrect. > > This results in: > > [2.204022] CPU 3 Unable to handle kernel paging request at virtual > address c06b1444, epc == c06b1444, ra == 803f1090 > > The correct instructions should be: > > R_MIPS_HI16 0x3c010001 > R_MIPS_LO16 0x24339444 > > so there'll be 0x0001 from hi16. > > I tried to catch those bugs in arch/mips/kernel/module.c (by checking > if the destination is lower than the base address, which should never > happen), and seems like I have only 3 such places in libphy.ko (and > one in nf_tables.ko). > I don't think it should be handled somehow in mentioned source code > as it would look rather ugly and may break kernels build with GNU > stack, which seems to not produce such bad codes. > > If I should report this to any other resources, please let me know. > I chose clang-built-linux and LKML as it may not happen with userland > (didn't tried to catch). Thanks for the report. Sounds like we may indeed be producing an incorrect relocation. This is only seen for big endian triples? Getting a way for us to deterministically reproduce would be a good first step. Which config or configs beyond defconfig, and which relocations specifically are you observing this with? -- Thanks, ~Nick Desaulniers
Re: Old platforms: bring out your dead
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote: > * dove -- added in 2009, obsoleted by mach-mvebu in 2015 May be obsoleted, but I still use this for my dove cubox with additional patches. > * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW > have one Yes, and still running: Linux flint 5.6.12+ #94 Sat Oct 17 23:44:28 BST 2020 armv4l armv4l armv4l GNU/Linux > * iop32x -- added in 2006, no notable changes other than my cleanup, but > I think there are still users I have two TheCUS N2100s here, one still powered up and running and one is currently available if anyone wants the machine. Both may become available if anyone wants them later in 2021. I notice Heiner Kallweit has been patching some of this code recently. > * rpc -- prehistoric, but I think Russell still uses his machine Yes, and I have sent some patches in the 5.x timeframe, and I do have some further ones I could send, mostly around SCSI stuff. It is my only machine that gives me access to some old tape backups and syquest cartridges (not that any of that contains "modern" data.) > * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it I also have some further patches that have been hanging around for some time to modernise sa1100 a bit. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH] mm/swap_slots.c: Remove unnecessary NULL pointer check
On Sat, Jan 09, 2021 at 03:09:43AM -0500, Miaohe Lin wrote:
> The cache->slots and cache->slots_ret is already checked before we try to
> drain it. And kvfree can handle the NULL pointer itself. So remove the
> NULL pointer check here.
> @@ -178,7 +178,7 @@ static void drain_slots_cache_cpu(unsigned int cpu,
> unsigned int type,
> swapcache_free_entries(cache->slots + cache->cur, cache->nr);
> cache->cur = 0;
> cache->nr = 0;
> - if (free_slots && cache->slots) {
> + if (free_slots) {
Prove that swapcache_free_entries() doesn't change cache->slots.
> @@ -188,13 +188,12 @@ static void drain_slots_cache_cpu(unsigned int cpu,
> unsigned int type,
> spin_lock_irq(>free_lock);
> swapcache_free_entries(cache->slots_ret, cache->n_ret);
> cache->n_ret = 0;
> - if (free_slots && cache->slots_ret) {
> + if (free_slots) {
... or ->slots_ret
> - if (slots)
> - kvfree(slots);
> + kvfree(slots);
This is fine.
Re: Old platforms: bring out your dead
On 1/8/2021 2:55 PM, Arnd Bergmann wrote: > After v5.10 was officially declared an LTS kernel, I had a look around > the Arm platforms that look like they have not seen any patches from > their maintainers or users that are actually running the hardware for > at least five years (2015 or earlier). I made some statistics and lists > for my lwn.net article last year [1], so I'd thought I'd share a summary > here for discussion about what we should remove. As I found three > years ago when I removed several CPU architectures, it makes sense > to do this in bulk, to simplify a scripted search for device drivers, header > files and Kconfig options that become unused in the process. > > This is probably a mix of platforms that are completely unused and > those that just work, but I have no good way of knowing which one > it is. Without hearing back about these, I'd propose removing all of > these: > > * asm9260 -- added in 2014, no notable changes after 2015 > * axxia -- added in 2014, no notable changes after 2015 > * bcm/kona -- added in 2013, no notable changes after 2014 I have a development board that I occasionally turn on for testing upstream kernels, it has not broken in a while which is why it did not get much updates. I don't feel strongly with respect to keep it or dropping it though. -- Florian
Re: KMSAN: uninit-value in __crypto_memneq (2)
On Sat, Jan 9, 2021 at 6:14 PM Eric Biggers wrote: > > +Jason, since this looks WireGuard-related. I suspect that the uninit was created by geneve or batadv and then just handed off to wireguard, which couldn't deal with it at that point. > On Sat, Jan 09, 2021 at 05:05:24AM -0800, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. > > git tree: https://github.com/google/kmsan.git master > > console output: https://syzkaller.appspot.com/x/log.txt?x=142ab9c0d0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=2cdf4151c9653e32 > > dashboard link: https://syzkaller.appspot.com/bug?extid=e0f501056b282add58a6 > > compiler: clang version 11.0.0 > > (https://github.com/llvm/llvm-project.git > > ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+e0f501056b282add5...@syzkaller.appspotmail.com > > > > = > > BUG: KMSAN: uninit-value in __crypto_memneq_16 crypto/memneq.c:99 [inline] > > BUG: KMSAN: uninit-value in __crypto_memneq+0x42c/0x470 crypto/memneq.c:161 > > CPU: 0 PID: 20526 Comm: kworker/0:3 Not tainted 5.10.0-rc4-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Workqueue: wg-crypt-wg1 wg_packet_decrypt_worker > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0x21c/0x280 lib/dump_stack.c:118 > > kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 > > __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 > > __crypto_memneq_16 crypto/memneq.c:99 [inline] > > __crypto_memneq+0x42c/0x470 crypto/memneq.c:161 > > crypto_memneq include/crypto/algapi.h:277 [inline] > > chacha20poly1305_crypt_sg_inplace+0x1662/0x1cd0 > > lib/crypto/chacha20poly1305.c:311 > > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > > lib/crypto/chacha20poly1305.c:351 > > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 > > kthread+0x51c/0x560 kernel/kthread.c:292 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > > > Uninit was stored to memory at: > > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > > put_unaligned_le64 include/linux/unaligned/access_ok.h:50 [inline] > > poly1305_core_emit+0x625/0x6a0 lib/crypto/poly1305-donna64.c:182 > > poly1305_final_generic+0xe2/0x280 lib/crypto/poly1305.c:71 > > poly1305_final include/crypto/poly1305.h:94 [inline] > > chacha20poly1305_crypt_sg_inplace+0x15cf/0x1cd0 > > lib/crypto/chacha20poly1305.c:310 > > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > > lib/crypto/chacha20poly1305.c:351 > > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 > > kthread+0x51c/0x560 kernel/kthread.c:292 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > > > Uninit was stored to memory at: > > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > > poly1305_core_blocks+0x8f4/0x940 lib/crypto/poly1305-donna64.c:107 > > poly1305_update_generic+0x1a7/0x5a0 lib/crypto/poly1305.c:49 > > poly1305_update include/crypto/poly1305.h:83 [inline] > > chacha20poly1305_crypt_sg_inplace+0x1496/0x1cd0 > > lib/crypto/chacha20poly1305.c:302 > > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > > lib/crypto/chacha20poly1305.c:351 > > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 > > kthread+0x51c/0x560 kernel/kthread.c:292 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > > > Uninit was stored to memory at: > > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > > poly1305_core_blocks+0x8f4/0x940 lib/crypto/poly1305-donna64.c:107 > > poly1305_update_generic+0x1a7/0x5a0 lib/crypto/poly1305.c:49 > > poly1305_update include/crypto/poly1305.h:83 [inline] > > chacha20poly1305_crypt_sg_inplace+0xb4d/0x1cd0 > >
Re: [PATCH v9 00/16] Add support for Clang LTO
On Sat, Jan 9, 2021 at 6:06 PM Josh Poimboeuf wrote: > > On Sat, Jan 09, 2021 at 11:03:57AM -0600, Josh Poimboeuf wrote: > > On Sat, Jan 09, 2021 at 05:45:47PM +0100, Sedat Dilek wrote: > > > I tried merging with clang-cfi Git which is based on Linux v5.11-rc2+ > > > with a lot of merge conflicts. > > > > > > Did you try on top of cfi-10 Git tag which is based on Linux v5.10? > > > > > > Whatever you successfully did... Can you give me a step-by-step > > > instruction? > > > > Oops, my bad. My last three commits (which I just added) do conflict. > > Sorry for the confusion. > > > > Just drop my last three commits: > > > > git fetch > > https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git > > objtool-vmlinux > > git checkout -B tmp FETCH_HEAD > > git reset --hard HEAD~~~ > > git fetch https://github.com/samitolvanen/linux clang-lto > > git rebase --onto FETCH_HEAD 79881bfc57be > > Last one should be: > > git rebase --onto FETCH_HEAD 2c85ebc57b3e > OK, that worked fine. So commit 2c85ebc57b3e is v5.10 Git tag in upstream. So, I substituted: git rebase --onto FETCH_HEAD v5.10 Thanks. - Sedat -
Re: Old platforms: bring out your dead
On 1/8/2021 4:16 PM, Linus Walleij wrote: >> * ep93xx -- added in 2006, LinusW still working on it, any users left? > > I was contacted by a user of this platform, using it with mainline and > fixing bugs in the GPIO driver for this kernel cycle. So it has users. You can count me as one of the users, I still use my TS7300 system, however because of the amount of RAM I don't regularly update it. -- Florian
[ANNOUNCE] 4.9.250-rt165
Hello RT-list! I'm pleased to announce the 4.9.250-rt165 stable release. This release is just an update to the new stable v4.9.250 version and no RT specific changes have been performed. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: fddc3eaab668becf2d42af17db4d1f9ce3e719f1 Or to build 4.9.250-rt165 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.9.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.9.250.xz https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.250-rt165.patch.xz Enjoy! Luis
Re: [PATCH v12] ARM: uncompress: Validate start of physical memory against passed DTB
04.01.2021 16:01, Geert Uytterhoeven пишет: > Currently, the start address of physical memory is obtained by masking > the program counter with a fixed mask of 0xf800. This mask value > was chosen as a balance between the requirements of different platforms. > However, this does require that the start address of physical memory is > a multiple of 128 MiB, precluding booting Linux on platforms where this > requirement is not fulfilled. > > Fix this limitation by validating the masked address against the memory > information in the passed DTB. Only use the start address > from DTB when masking would yield an out-of-range address, prefer the > traditional method in all other cases. Note that this applies only to the > explicitly passed DTB on modern systems, and not to a DTB appended to > the kernel, or to ATAGS. The appended DTB may need to be augmented by > information from ATAGS, which may need to rely on knowledge of the start > address of physical memory itself. > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM > on the RZA2MEVB sub board, which is located at 0x0C00 (CS3 space), > i.e. not at a multiple of 128 MiB. > > Suggested-by: Nicolas Pitre > Suggested-by: Ard Biesheuvel > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Ard Biesheuvel > Acked-by: Nicolas Pitre > --- > Submitted to RMK's patch tracker. > > v12: > - Drop unneeded initialization of r in get_val(), I tested this patch on NVIDIA Tegra and haven't spotted any problems. Tested-by: Dmitry Osipenko
Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander
Hi AngeloGioacchino,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pinctrl/devel]
[also build test ERROR on v5.11-rc2 next-20210108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/AngeloGioacchino-Del-Regno/Add-Awinic-AW9523-B-I2C-GPIO-Expander-driver/20210109-220525
base:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: sparc-randconfig-r025-20210110 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/9cf5980cd08c30aec01a24e284a0553396a1fa64
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
AngeloGioacchino-Del-Regno/Add-Awinic-AW9523-B-I2C-GPIO-Expander-driver/20210109-220525
git checkout 9cf5980cd08c30aec01a24e284a0553396a1fa64
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/pinctrl/pinctrl-aw9523.c: In function 'aw9523_pconf_get':
drivers/pinctrl/pinctrl-aw9523.c:292:11: error: implicit declaration of
function 'FIELD_GET'; did you mean 'FOLL_GET'?
[-Werror=implicit-function-declaration]
292 |val = !FIELD_GET(AW9523_GCR_GPOMD_MASK, val);
| ^
| FOLL_GET
drivers/pinctrl/pinctrl-aw9523.c: In function 'aw9523_init_irq':
>> drivers/pinctrl/pinctrl-aw9523.c:880:9: error: 'struct gpio_irq_chip' has no
>> member named 'parent_domain'
880 | gpioirq->parent_domain = NULL;
| ^~
cc1: some warnings being treated as errors
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) ||
ARCH_WANT_FRAME_POINTERS || MCOUNT
Selected by
- LOCKDEP && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && !MIPS && !PPC && !ARM
&& !S390 && !MICROBLAZE && !ARC && !X86
- FAULT_INJECTION_STACKTRACE_FILTER && FAULT_INJECTION_DEBUG_FS &&
STACKTRACE_SUPPORT && !X86_64 && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM
&& !ARC && !X86
vim +880 drivers/pinctrl/pinctrl-aw9523.c
832
833 static int aw9523_init_irq(struct aw9523 *awi, int irq)
834 {
835 struct device *dev = awi->dev;
836 struct gpio_irq_chip *gpioirq;
837 struct irq_chip *irqchip;
838 int i, ret;
839
840 if (!device_property_read_bool(dev, "interrupt-controller"))
841 return 0;
842
843 irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
844 if (!irqchip)
845 return -ENOMEM;
846
847 awi->irq = devm_kzalloc(dev, sizeof(*awi->irq), GFP_KERNEL);
848 if (!awi->irq)
849 return -ENOMEM;
850
851 irqchip->name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
852 if (!irqchip->name)
853 return -ENOMEM;
854
855 irqchip->irq_mask = aw9523_irq_mask;
856 irqchip->irq_unmask = aw9523_irq_unmask;
857 irqchip->irq_bus_lock = aw9523_irq_bus_lock;
858 irqchip->irq_bus_sync_unlock = aw9523_irq_bus_sync_unlock;
859 irqchip->irq_set_type = aw9523_gpio_irq_type;
860
861 for (i = 0; i < AW9523_NUM_PORTS; i++) {
862 bitmap_fill(awi->irq->masked[i], AW9523_PINS_PER_PORT);
863 bitmap_fill(awi->irq->old_masked[i],
AW9523_PINS_PER_PORT);
864 }
865 awi->irq->irqchip = irqchip;
866 mutex_init(>irq->lock);
867
868 ret = devm_request_threaded_irq(dev, irq, NULL,
aw9523_irq_thread_func,
869 IRQF_ONESHOT, dev_name(dev),
awi);
870 if (ret) {
871 dev_err(dev, "Failed to request irq %d\n", irq);
872 return ret;
873 }
874
875 gpioirq = >gpio.irq;
876 gpioirq->chip = irqchip;
877 gpioirq->parent_handler = NULL;
878 gpioirq->num_parents = 0;
879 gpioirq->parents = NULL;
Re: [PATCH v4 mips-next 0/7] MIPS: vmlinux.lds.S sections fixes & cleanup
From: Thomas Bogendoerfer Date: Sat, 9 Jan 2021 12:12:59 +0100 > On Thu, Jan 07, 2021 at 12:33:38PM +, Alexander Lobakin wrote: >> This series hunts the problems discovered after manual enabling of >> ARCH_WANT_LD_ORPHAN_WARN. Notably: >> - adds the missing PAGE_ALIGNED_DATA() section affecting VDSO >>placement (marked for stable); >> - properly stops .eh_frame section generation. >> >> Compile and runtime tested on MIPS32R2 CPS board with no issues >> using two different toolkits: >> - Binutils 2.35.1, GCC 10.2.0; >> - LLVM stack 11.0.0. >> >> Since v3 [2]: >> - fix the third patch as GNU stack emits .rel.dyn into VDSO for >>some reason if .cfi_sections is specified. >> >> Since v2 [1]: >> - stop discarding .eh_frame and just prevent it from generating >>(Kees); >> - drop redundant sections assertions (Fangrui); >> - place GOT table in .text instead of asserting as it's not empty >>when building with LLVM (Nathan); >> - catch compound literals in generic definitions when building with >>LD_DEAD_CODE_DATA_ELIMINATION (Kees); >> - collect two Reviewed-bys (Kees). >> >> Since v1 [0]: >> - catch .got entries too as LLD may produce it (Nathan); >> - check for unwanted sections to be zero-sized instead of >>discarding (Fangrui). >> >> [0] https://lore.kernel.org/linux-mips/20210104121729.46981-1-aloba...@pm.me >> [1] https://lore.kernel.org/linux-mips/20210106200713.31840-1-aloba...@pm.me >> [2] https://lore.kernel.org/linux-mips/20210107115120.281008-1-aloba...@pm.me >> >> Alexander Lobakin (7): >> MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section >> MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS >> MIPS: properly stop .eh_frame generation >> MIPS: vmlinux.lds.S: catch bad .rel.dyn at link time >> MIPS: vmlinux.lds.S: explicitly declare .got table >> vmlinux.lds.h: catch compound literals into data and BSS >> MIPS: select ARCH_WANT_LD_ORPHAN_WARN > > this breaks my builds: > > LD vmlinux.o > MODPOST vmlinux.symvers > MODINFO modules.builtin.modinfo > GEN modules.builtin > LD .tmp_vmlinux.kallsyms1 > mips64-linux-gnu-ld: Unexpected run-time relocations (.rel) detected! I think they should be handled as it's done for ARM64 [0]. Will do v5 soon. [0] https://elixir.bootlin.com/linux/v5.11-rc2/source/arch/arm64/kernel/vmlinux.lds.S#L219 > $ mips64-linux-gnu-ld --version > GNU ld version 2.27-3.fc24 > > $ mips64-linux-gnu-gcc --version > mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2) > > Thomas. Thanks, Alex > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea.[ RFC1925, 2.3 ]
Re: KMSAN: uninit-value in __crypto_memneq (2)
+Jason, since this looks WireGuard-related. On Sat, Jan 09, 2021 at 05:05:24AM -0800, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. > git tree: https://github.com/google/kmsan.git master > console output: https://syzkaller.appspot.com/x/log.txt?x=142ab9c0d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=2cdf4151c9653e32 > dashboard link: https://syzkaller.appspot.com/bug?extid=e0f501056b282add58a6 > compiler: clang version 11.0.0 > (https://github.com/llvm/llvm-project.git > ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+e0f501056b282add5...@syzkaller.appspotmail.com > > = > BUG: KMSAN: uninit-value in __crypto_memneq_16 crypto/memneq.c:99 [inline] > BUG: KMSAN: uninit-value in __crypto_memneq+0x42c/0x470 crypto/memneq.c:161 > CPU: 0 PID: 20526 Comm: kworker/0:3 Not tainted 5.10.0-rc4-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: wg-crypt-wg1 wg_packet_decrypt_worker > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x21c/0x280 lib/dump_stack.c:118 > kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 > __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 > __crypto_memneq_16 crypto/memneq.c:99 [inline] > __crypto_memneq+0x42c/0x470 crypto/memneq.c:161 > crypto_memneq include/crypto/algapi.h:277 [inline] > chacha20poly1305_crypt_sg_inplace+0x1662/0x1cd0 > lib/crypto/chacha20poly1305.c:311 > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > lib/crypto/chacha20poly1305.c:351 > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 > kthread+0x51c/0x560 kernel/kthread.c:292 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > Uninit was stored to memory at: > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > put_unaligned_le64 include/linux/unaligned/access_ok.h:50 [inline] > poly1305_core_emit+0x625/0x6a0 lib/crypto/poly1305-donna64.c:182 > poly1305_final_generic+0xe2/0x280 lib/crypto/poly1305.c:71 > poly1305_final include/crypto/poly1305.h:94 [inline] > chacha20poly1305_crypt_sg_inplace+0x15cf/0x1cd0 > lib/crypto/chacha20poly1305.c:310 > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > lib/crypto/chacha20poly1305.c:351 > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 > kthread+0x51c/0x560 kernel/kthread.c:292 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > Uninit was stored to memory at: > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > poly1305_core_blocks+0x8f4/0x940 lib/crypto/poly1305-donna64.c:107 > poly1305_update_generic+0x1a7/0x5a0 lib/crypto/poly1305.c:49 > poly1305_update include/crypto/poly1305.h:83 [inline] > chacha20poly1305_crypt_sg_inplace+0x1496/0x1cd0 > lib/crypto/chacha20poly1305.c:302 > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > lib/crypto/chacha20poly1305.c:351 > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 > kthread+0x51c/0x560 kernel/kthread.c:292 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > Uninit was stored to memory at: > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > poly1305_core_blocks+0x8f4/0x940 lib/crypto/poly1305-donna64.c:107 > poly1305_update_generic+0x1a7/0x5a0 lib/crypto/poly1305.c:49 > poly1305_update include/crypto/poly1305.h:83 [inline] > chacha20poly1305_crypt_sg_inplace+0xb4d/0x1cd0 > lib/crypto/chacha20poly1305.c:263 > chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 > lib/crypto/chacha20poly1305.c:351 > decrypt_packet drivers/net/wireguard/receive.c:284 [inline] > wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 > process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 > worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418
[BUG mips llvm] MIPS: malformed R_MIPS_{HI16,LO16} with LLVM
Machine: MIPS32 R2 Big Endian (interAptiv (multi)) While testing MIPS with LLVM, I found a weird and very rare bug with MIPS relocs that LLVM emits into kernel modules. It happens on both 11.0.0 and latest git snapshot and applies, as I can see, only to references to static symbols. When the kernel loads the module, it allocates a space for every section and then manually apply the relocations relative to the new address. Let's say we have a function phy_probe() in drivers/net/phy/libphy.ko. It's static and referenced only in phy_register_driver(), where it's used to fill callback pointer in a structure. The real function address after module loading is 0xc06c1444, that is observed in its ELF st_value field. There are two relocs related to this usage in phy_register_driver(): R_MIPS_HI16 refers to 0x3c01 R_MIPS_LO16 refers to 0x24339444 The address of .text is 0xc06b8000. So the destination is calculated as follows: 0x from hi16; 0x9444 from lo16 (sign extend as it's always treated as signed); 0xc06b8000 from base. = 0xc06b1444. The value is lower than the real phy_probe() address (0xc06c1444) by 0x1 and is lower than the base address of module's .text, so it's 100% incorrect. This results in: [2.204022] CPU 3 Unable to handle kernel paging request at virtual address c06b1444, epc == c06b1444, ra == 803f1090 The correct instructions should be: R_MIPS_HI16 0x3c010001 R_MIPS_LO16 0x24339444 so there'll be 0x0001 from hi16. I tried to catch those bugs in arch/mips/kernel/module.c (by checking if the destination is lower than the base address, which should never happen), and seems like I have only 3 such places in libphy.ko (and one in nf_tables.ko). I don't think it should be handled somehow in mentioned source code as it would look rather ugly and may break kernels build with GNU stack, which seems to not produce such bad codes. If I should report this to any other resources, please let me know. I chose clang-built-linux and LKML as it may not happen with userland (didn't tried to catch). Thanks, Al
Re: [PATCH v3] driver core: Fix device link device name collision
On Sat, Jan 9, 2021 at 8:49 AM Michael Walle wrote:
>
> Am 2021-01-08 18:22, schrieb Saravana Kannan:
> > On Fri, Jan 8, 2021 at 12:16 AM Michael Walle wrote:
> >>
> >> Am 2021-01-08 02:24, schrieb Saravana Kannan:
> >> > The device link device's name was of the form:
> >> > --
> >> >
> >> > This can cause name collision as reported here [1] as device names are
> >> > not globally unique. Since device names have to be unique within the
> >> > bus/class, add the bus/class name as a prefix to the device names used
> >> > to
> >> > construct the device link device name.
> >> >
> >> > So the devuce link device's name will be of the form:
> >> > :--:
> >> >
> >> > [1] -
> >> > https://lore.kernel.org/lkml/20201229033440.32142-1-mich...@walle.cc/
> >> >
> >> > Cc: sta...@vger.kernel.org
> >> > Fixes: 287905e68dd2 ("driver core: Expose device link details in
> >> > sysfs")
> >> > Reported-by: Michael Walle
> >> > Signed-off-by: Saravana Kannan
> >> > ---
> >> [..]
> >>
> >> The changes are missing for the error path and
> >> devlink_remove_symlinks(),
> >> right?
> >
> > Removing symlinks doesn't need the name. Just needs the "handle". So
> > we are good there.
>
> I don't get it. What is the "handle"? Without the patch below
> kernfs_remove_by_name() in sysfs_remove_link will return -ENOENT. With
> the patch it will return 0.
>
> And even if it would work, how is this even logical:
Ah sorry, I confused it with removing device attrs. I need to fix up
the symlink remove path.
>
> snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con),
> dev_name(con));
> ret = sysfs_create_link(>kobj, >link_dev.kobj, buf);
> if (ret)
> goto err_con_dev;
> snprintf(buf, len, "supplier:%s:%s", dev_bus_name(sup),
> dev_name(sup));
> ret = sysfs_create_link(>kobj, >link_dev.kobj, buf);
> if (ret)
> goto err_sup_dev;
> [..]
> err_sup_dev:
> snprintf(buf, len, "consumer:%s", dev_name(con));
> sysfs_remove_link(>kobj, buf);
>
> You call sysfs_create_link("consumer:bus_name:dev_name") but the
> corresponding rollback is sysfs_remove_link("consumer:dev_name"), that
> is super confusing.
>
> >> diff --git a/drivers/base/core.c b/drivers/base/core.c
> >> index 4140a69dfe18..385e16d92874 100644
> >> --- a/drivers/base/core.c
> >> +++ b/drivers/base/core.c
> >> @@ -485,7 +485,7 @@ static int devlink_add_symlinks(struct device
> >> *dev,
> >> goto out;
> >>
> >> err_sup_dev:
> >> - snprintf(buf, len, "consumer:%s", dev_name(con));
> >> + snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con),
> >> dev_name(con));
> >> sysfs_remove_link(>kobj, buf);
> >> err_con_dev:
> >> sysfs_remove_link(>link_dev.kobj, "consumer");
> >> @@ -508,7 +508,9 @@ static void devlink_remove_symlinks(struct device
> >> *dev,
> >> sysfs_remove_link(>link_dev.kobj, "consumer");
> >> sysfs_remove_link(>link_dev.kobj, "supplier");
> >>
> >> - len = max(strlen(dev_name(sup)), strlen(dev_name(con)));
> >> + len = max(strlen(dev_bus_name(sup)) + strlen(dev_name(sup)),
> >> + strlen(dev_bus_name(con)) + strlen(dev_name(con)));
> >> + len += strlen(":");
> >> len += strlen("supplier:") + 1;
> >> buf = kzalloc(len, GFP_KERNEL);
> >> if (!buf) {
> >> @@ -516,9 +518,9 @@ static void devlink_remove_symlinks(struct device
> >> *dev,
> >> return;
> >> }
> >>
> >> - snprintf(buf, len, "supplier:%s", dev_name(sup));
> >> + snprintf(buf, len, "supplier:%s:%s", dev_bus_name(sup),
> >> dev_name(sup));
> >> sysfs_remove_link(>kobj, buf);
> >> - snprintf(buf, len, "consumer:%s", dev_name(con));
> >> + snprintf(buf, len, "consumer:%s:%s", dev_bus_name(sup),
> >> dev_name(con));
Ah I completely skimmed over this code thinking it was code from my
patch. Like I said, I was struggling with the length of the email due
to the logs. Anyway, I'll fix up the remove symlink path too. Thanks
for catching that.
> btw this should be dev_bus_name(con).
>
> >> sysfs_remove_link(>kobj, buf);
> >> kfree(buf);
> >> }
> >>
> >> With these changes:
> >>
> >> Tested-by: Michael Walle
> >
> > Greg,
> >
> > I think it's good to pick up this version if you don't see any issues.
>
> Why so fast?
Sorry, didn't mean to rush. I was just trying to say I wasn't planning
on a v4 because I thought your Tested-by was for my unchanged v4, but
clearly I need to send a v4.
-Saravana
Re: [PATCH] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
On Saturday, January 9, 2021 10:37:41 AM CET Dexuan Cui wrote: > > From: Andy Shevchenko > > Sent: Saturday, January 9, 2021 12:52 AM > >> > >> Hi Rafael, Len, and all, > >> Can you please take a look at the v2 patch? > >> > >> The Linux mainline has been broken for several weeks when it > >> runs as a guest on Hyper-V, so we'd like this to be fixed ASAP, > >> as more people are being affected > > > > I would like to see a warning printed when the dupped > > string violates the spec. > > Hi Andy, > Do you want a simple strlen() check like the below, or a full > check of the AAA or format? It would be good to check the format too while at it. > Can we have the v2 (https://lkml.org/lkml/2021/1/8/53) merged > first, and then we can add another patch for the format checking? Yes, we can. I'm going to apply the v2 early next week. Thanks!
Re: BUG: unable to handle kernel paging request in percpu_ref_exit
On 09/01/2021 17:01, syzbot wrote: > Hello, > > syzbot has tested the proposed patch and the reproducer did not trigger any > issue: #syz fix: io_uring: Fix return value from alloc_fixed_file_ref_node > > Reported-and-tested-by: syzbot+99ed55100402022a6...@syzkaller.appspotmail.com > > Tested on: > > commit: d9d05217 io_uring: stop SQPOLL submit on creator's death > git tree: git://git.kernel.dk/linux-block > kernel config: https://syzkaller.appspot.com/x/.config?x=2455d075a1c4afa8 > dashboard link: https://syzkaller.appspot.com/bug?extid=99ed55100402022a6276 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Note: testing is done by a robot and is best-effort only. > -- Pavel Begunkov
WARNING in qp_host_alloc_queue
Hello, syzbot found the following issue on: HEAD commit:36bbbd0e Merge branch 'rcu/urgent' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12d5176750 kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224 dashboard link: https://syzkaller.appspot.com/bug?extid=3ad726072ce632af076c compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17f5b9c0d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d194db50 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1443a3a8d0 final oops: https://syzkaller.appspot.com/x/report.txt?x=1643a3a8d0 console output: https://syzkaller.appspot.com/x/log.txt?x=1243a3a8d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3ad726072ce632af0...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 8496 at mm/page_alloc.c:4976 __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011 Modules linked in: CPU: 1 PID: 8496 Comm: syz-executor831 Not tainted 5.11.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976 Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8 RSP: 0018:c9000130f840 EFLAGS: 00010246 RAX: RBX: 192000261f0c RCX: RDX: RSI: dc00 RDI: 00040dc0 RBP: 00040dc0 R08: R09: R10: 81b1f7f1 R11: R12: 000c R13: 000c R14: R15: 88801bb5ec00 FS: 013e5880() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f72e34306c0 CR3: 1d402000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267 alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x2e/0xb0 mm/slab_common.c:837 kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853 kmalloc include/linux/slab.h:557 [inline] kzalloc include/linux/slab.h:682 [inline] qp_host_alloc_queue+0x4d/0x230 drivers/misc/vmw_vmci/vmci_queue_pair.c:540 qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline] qp_broker_alloc+0xea7/0x1bf0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739 vmci_qp_broker_alloc+0x48/0x60 drivers/misc/vmw_vmci/vmci_queue_pair.c:1932 vmci_host_do_alloc_queuepair.constprop.0+0x2c8/0x3a0 drivers/misc/vmw_vmci/vmci_host.c:463 vmci_host_unlocked_ioctl+0x13c7/0x1e50 drivers/misc/vmw_vmci/vmci_host.c:927 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4402f9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffd50062838 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004002c8 RCX: 004402f9 RDX: 2040 RSI: 07a8 RDI: 0003 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0246 R12: 00401b00 R13: 00401b90 R14: R15: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] evm: Fix memleak in init_desc
On Sat, Jan 09, 2021 at 07:33:05PM +0800, Dinghao Liu wrote:
> When kmalloc() fails, tmp_tfm allocated by
> crypto_alloc_shash() has not been freed, which
> leads to memleak.
>
> Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
> Signed-off-by: Dinghao Liu
> ---
> security/integrity/evm/evm_crypto.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/security/integrity/evm/evm_crypto.c
> b/security/integrity/evm/evm_crypto.c
> index 168c3b78ac47..39fb31a638ac 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -73,7 +73,7 @@ static struct shash_desc *init_desc(char type, uint8_t
> hash_algo)
> {
> long rc;
> const char *algo;
> - struct crypto_shash **tfm, *tmp_tfm;
> + struct crypto_shash **tfm, *tmp_tfm = NULL;
> struct shash_desc *desc;
>
> if (type == EVM_XATTR_HMAC) {
> @@ -118,13 +118,18 @@ static struct shash_desc *init_desc(char type, uint8_t
> hash_algo)
> alloc:
> desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> GFP_KERNEL);
> - if (!desc)
> + if (!desc) {
> + if (tmp_tfm)
> + crypto_free_shash(tmp_tfm);
> return ERR_PTR(-ENOMEM);
> + }
>
> desc->tfm = *tfm;
>
> rc = crypto_shash_init(desc);
> if (rc) {
> + if (tmp_tfm)
> + crypto_free_shash(tmp_tfm);
> kfree(desc);
> return ERR_PTR(rc);
> }
There's no need to check for NULL before calling crypto_free_shash().
- Eric
Re: [PATCH v9 00/16] Add support for Clang LTO
On Sat, Jan 09, 2021 at 11:03:57AM -0600, Josh Poimboeuf wrote: > On Sat, Jan 09, 2021 at 05:45:47PM +0100, Sedat Dilek wrote: > > I tried merging with clang-cfi Git which is based on Linux v5.11-rc2+ > > with a lot of merge conflicts. > > > > Did you try on top of cfi-10 Git tag which is based on Linux v5.10? > > > > Whatever you successfully did... Can you give me a step-by-step instruction? > > Oops, my bad. My last three commits (which I just added) do conflict. > Sorry for the confusion. > > Just drop my last three commits: > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git > objtool-vmlinux > git checkout -B tmp FETCH_HEAD > git reset --hard HEAD~~~ > git fetch https://github.com/samitolvanen/linux clang-lto > git rebase --onto FETCH_HEAD 79881bfc57be Last one should be: git rebase --onto FETCH_HEAD 2c85ebc57b3e -- Josh
Re: [PATCH v9 00/16] Add support for Clang LTO
On Sat, Jan 09, 2021 at 05:45:47PM +0100, Sedat Dilek wrote: > I tried merging with clang-cfi Git which is based on Linux v5.11-rc2+ > with a lot of merge conflicts. > > Did you try on top of cfi-10 Git tag which is based on Linux v5.10? > > Whatever you successfully did... Can you give me a step-by-step instruction? Oops, my bad. My last three commits (which I just added) do conflict. Sorry for the confusion. Just drop my last three commits: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git objtool-vmlinux git checkout -B tmp FETCH_HEAD git reset --hard HEAD~~~ git fetch https://github.com/samitolvanen/linux clang-lto git rebase --onto FETCH_HEAD 79881bfc57be -- Josh
Re: [PATCH] iov_iter: optimise iter type checking
On Sat, Jan 09, 2021 at 04:09:08PM +, Pavel Begunkov wrote:
> On 06/12/2020 16:01, Pavel Begunkov wrote:
> > On 21/11/2020 14:37, Pavel Begunkov wrote:
> >> The problem here is that iov_iter_is_*() helpers check types for
> >> equality, but all iterate_* helpers do bitwise ands. This confuses
> >> compilers, so even if some cases were handled separately with
> >> iov_iter_is_*(), corresponding ifs in iterate*() right after are not
> >> eliminated.
> >>
> >> E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
> >> still checks for discard iter type and generates unreachable code down
> >> the line.
> >
> > Ping. This one should be pretty simple
>
> Ping please. Any doubts about this patch?
Sorry, had been buried in other crap. I'm really not fond of the
bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
into switches...
How about moving the READ/WRITE part into MSB? Checking is just as fast
(if not faster - check for sign vs. checking bit 0). And turn the
types into straight (dense) enum.
Almost all iov_iter_rw() callers have the form (iov_iter_rw(iter) == READ) or
(iov_iter_rw(iter) == WRITE). Out of 50-odd callers there are 5 nominal
exceptions:
fs/cifs/smbdirect.c:1936:iov_iter_rw(>msg_iter));
fs/exfat/inode.c:442: int rw = iov_iter_rw(iter);
fs/f2fs/data.c:3639:int rw = iov_iter_rw(iter);
fs/f2fs/f2fs.h:4082:int rw = iov_iter_rw(iter);
fs/f2fs/f2fs.h:4092:int rw = iov_iter_rw(iter);
The first one is debugging printk
if (iov_iter_rw(>msg_iter) == WRITE) {
/* It's a bug in upper layer to get there */
cifs_dbg(VFS, "Invalid msg iter dir %u\n",
iov_iter_rw(>msg_iter));
rc = -EINVAL;
goto out;
}
and if you look at the condition, the quality of message is
underwhelming - "Data source msg iter passed by caller" would
be more informative.
Other 4... exfat one is
if (rw == WRITE) {
...
}
...
if (ret < 0 && (rw & WRITE))
exfat_write_failed(mapping, size);
IOW, doing
bool is_write = iov_iter_rw(iter) == WRITE;
would be cleaner. f2fs.h ones are
int rw = iov_iter_rw(iter);
if ( && rw == WRITE ...
so they are of the same sort (assuming we want that local
variable in the first place).
f2fs/data.c is the least trivial - it includes things like
if (!down_read_trylock(>i_gc_rwsem[rw])) {
and considering the amount of other stuff done there,
I would suggest something like
int rw = is_data_source(iter) ? WRITE : READ;
I'll dig myself from under ->d_revalidate() code review, look
through the iov_iter-related series and post review, hopefully
by tonight.
Re: [PATCH] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
On Sat, Jan 9, 2021 at 10:58 AM H. Nikolaus Schaller wrote:
>
> Hi Adam,
>
> > Am 09.01.2021 um 17:39 schrieb Adam Ford :
> >
> > Previously, the 1GHz variants were marked as a turbo,
> > because that variant has reduced thermal operating range.
> >
> > Now that the thermal throttling is in place, it should be
> > safe to remove the turbo-mode from the 1GHz variants, because
> > the CPU will automatically slow if the thermal limit is reached.
>
> Subject and description may be misunderstood in a way that 1GHz
> is now disabled.
>
> Rather the 1GHz OPP is now permanently enabled and does no longer
> need to be manuall enabled through something like
> /sys/devices/system/cpu/cpufreq/boost.
I just sent a V2, before I saw this. I can send a V3 with your
feedback. I just want to give Tony and/or others a chance to chime
in.
>
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > index 3a5228562b0d..3451f9be104e 100644
> > --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > @@ -70,6 +70,7 @@ nand@0,0 {
> > gpmc,device-width = <2>;
> > #address-cells = <1>;
> > #size-cells = <1>;
> > + status = "disabled";
>
> this does not seem to match the description?
I just sent an apology e-mail because I realized I grabbed the wrong file.
>
> > };
> > };
> >
> > --
> > 2.25.1
> >
>
> BR,
> Nikolaus
>
