Re: [PATCH bpf-next v2 2/4] selftests: bpf: Add helper to compare socket cookies
On Mon, Sep 28, 2020 at 10:08:03AM +0100, Lorenz Bauer wrote:
> We compare socket cookies to ensure that insertion into a sockmap worked.
> Pull this out into a helper function for use in other tests.
>
> Signed-off-by: Lorenz Bauer
> ---
> .../selftests/bpf/prog_tests/sockmap_basic.c | 50 +--
> 1 file changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
> b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
> index 4b7a527e7e82..67d3301bdf81 100644
> --- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
> +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
> @@ -50,6 +50,37 @@ static int connected_socket_v4(void)
> return -1;
> }
>
> +static void compare_cookies(struct bpf_map *src, struct bpf_map *dst)
> +{
> + __u32 i, max_entries = bpf_map__max_entries(src);
> + int err, duration, src_fd, dst_fd;
This should have a compiler warning. "duration" is not initialized.
RE: [PATCH 0/2] Enable support IPI_CPU_CRASH_STOP to be pseudo-NMI
Hi Marc Thank you for your reply. > On 2020-09-28 03:43, ito-yui...@fujitsu.com wrote: > > Hi Marc, Sumit > > > > I would appreciate if you have any advice on this patch. > > I haven't had a chance to look into it, as I'm not even sure I'll take the > core > series in the first place (there are outstanding regressions I can't > reproduce, > let alone fix them). > I understand it. Please let me know if there is anything I can do. I sincerely hope that your patches will be merged into the mainline. > > > > Yuichi Ito > > > >> Enable support IPI_CPU_CRASH_STOP to be pseudo-NMI > >> > >> This patchset enables IPI_CPU_CRASH_STOP IPI to be pseudo-NMI. > >> This allows kdump to collect system information even when the CPU is > >> in a HARDLOCKUP state. > >> > >> Only IPI_CPU_CRASH_STOP uses NMI and the other IPIs remain normal > >> IRQs. > >> > >> The patch has been tested on ThunderX. > > Which ThunderX? TX2 (at least the incarnation I used in the past) wasn't able > to correctly deal with priorities. I tried it with ThunderX CN8890. If you tell me steps to reproduce the problem of TX2, I will investigate it with TX as well. > M. > -- > Jazz is not dead. It just smells funny... Thank you and best regards, Yuichi Ito
[gustavoars-linux:for-linus/kspp] BUILD SUCCESS e1ea50331eaed753dfbc68e1263228c581cd6a10
i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20200928 x86_64 randconfig-a003-20200928 x86_64 randconfig-a004-20200928 x86_64 randconfig-a002-20200928 x86_64 randconfig-a006-20200928 x86_64 randconfig-a001-20200928 i386 randconfig-a006-20200928 i386 randconfig-a002-20200928 i386 randconfig-a003-20200928 i386 randconfig-a004-20200928 i386 randconfig-a005-20200928 i386 randconfig-a001-20200928 i386 randconfig-a012-20200928 i386 randconfig-a016-20200928 i386 randconfig-a014-20200928 i386 randconfig-a013-20200928 i386 randconfig-a015-20200928 i386 randconfig-a011-20200928 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a005-20200927 x86_64 randconfig-a003-20200927 x86_64 randconfig-a004-20200927 x86_64 randconfig-a002-20200927 x86_64 randconfig-a006-20200927 x86_64 randconfig-a001-20200927 x86_64 randconfig-a011-20200928 x86_64 randconfig-a013-20200928 x86_64 randconfig-a015-20200928 x86_64 randconfig-a014-20200928 x86_64 randconfig-a016-20200928 x86_64 randconfig-a012-20200928 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v6 3/6] mm: introduce memfd_secret system call to create "secret" memory areas
On Thu, 2020-09-24 at 16:29 +0300, Mike Rapoport wrote: > Introduce "memfd_secret" system call with the ability to create > memory > areas visible only in the context of the owning process and not > mapped not > only to other processes but in the kernel page tables as well. > > The user will create a file descriptor using the memfd_secret() > system call > where flags supplied as a parameter to this system call will define > the > desired protection mode for the memory associated with that file > descriptor. > > Currently there are two protection modes: > > * exclusive - the memory area is unmapped from the kernel direct map > and it > is present only in the page tables of the owning mm. Seems like there were some concerns raised around direct map efficiency, but in case you are going to rework this...how does this memory work for the existing kernel functionality that does things like this? get_user_pages(, ); ptr = kmap(page); foo = *ptr; Not sure if I'm missing something, but I think apps could cause the kernel to access a not-present page and oops.
Re: [PATCH 1/1] selinux: Measure state and hash of policy using IMA
On 9/28/20 9:29 AM, Stephen Smalley wrote: On Sat, Sep 26, 2020 at 12:40 PM Lakshmi Ramasubramanian wrote: Critical data structures of security modules are currently not measured. Therefore an attestation service, for instance, would not be able to attest whether the security modules are always operating with the policies and configurations that the system administrator had setup. The policies and configurations for the security modules could be tampered by rogue user mode agents or modified through some inadvertent actions on the system. Measuring such critical data would enable an attestation service to reliably assess the security configuration of the system. SELinux configuration and policy are some of the critical data for this security module that need to be measured. This measurement can be used by an attestation service, for instance, to verify if the configurations and policies have been setup correctly and that they haven't been tampered at run-time. Measure SELinux configurations, policy capabilities settings, and the hash of the loaded policy by calling the IMA hook ima_measure_critical_data(). Since the size of the loaded policy can be large (several MB), measure the hash of the policy instead of the entire policy to avoid bloating the IMA log entry. Add "selinux" to the list of supported data sources maintained by IMA to enable measuring SELinux data. Please provide an example /etc/ima/ima-policy snippet for enabling this support, e.g. measure func=CRITICAL_DATA data_sources=selinux template=ima-buf Will do. Since SELinux calls the IMA hook to measure data before a custom IMA policy is loaded, enable queuing if CONFIG_SECURITY_SELINUX is enabled, to defer processing SELinux data until a custom IMA policy is loaded. Sample measurement of SELinux state and hash of the policy: 10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state-1595389364:287899386 696e697469616c697a65643d313b656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574776f726b5f706565725f636f6e74726f6c733d313b6f70656e5f7065726d733d313b657874656e6465645f736f636b65745f636c6173733d313b616c776179735f636865636b5f6e6574776f726b3d303b6367726f75705f7365636c6162656c3d313b6e6e705f6e6f737569645f7472616e736974696f6e3d313b67656e66735f7365636c6162656c5f73796d6c696e6b733d303 10 9e81...0857 ima-buf sha256:4941...68fc selinux-policy-hash-1597335667:462051628 8d1d...1834 To verify the measurement check the following: Execute the following command to extract the measured data from the IMA log for SELinux configuration (selinux-state). grep -m 1 "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 | xxd -r -p NB This will only extract the first such record, which will always be prior to policy load (initialized=0) so that won't be terribly useful. For real verification, they would want to check all such records or at least the last/latest one (depending on their goal). Will update to fetch the latest measurement entry for selinux state. I have posted a patch that adds test in LTP to validate selinux measurement made by IMA. That test extracts the latest selinux measurement entry from the IMA log and validates. The link to that patch is https://patchwork.kernel.org/patch/11804587/ The output should be the list of key-value pairs. For example, initialized=1;enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0; To verify the measured data with the current SELinux state: => enabled should be set to 1 if /sys/fs/selinux folder exists, 0 otherwise For other entries, compare the integer value in the files => /sys/fs/selinux/enforce => /sys/fs/selinux/checkreqprot And, each of the policy capabilities files under => /sys/fs/selinux/policy_capabilities To be clear, actual verification would be against an expected state and done on a system other than the measured system, typically requiring "initialized=1; enabled=1;enforcing=1;checkreqprot=0;" for a secure state and then whatever policy capabilities are actually set in the expected policy (which can be extracted from the policy itself via seinfo or the like). Agreed. The measurement of selinux state done by IMA would ideally be validated by a remote attestation service against expected state. For selinux-policy-hash, the hash of SELinux policy is included in the IMA log entry. To verify the measured data with the current SELinux policy run the following commands and verify the output hash values match. sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1 grep -m 1 "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 As above, this will only extract the first policy load, whereas for real verification they will want to check either all of them or at least the latest/last one. For actual
Re: [PATCH 4.19 38/92] kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler
Hi,
On Mon, 28 Sep 2020 18:15:35 -0400
Steven Rostedt wrote:
> On Mon, 28 Sep 2020 18:09:42 -0400
> Steven Rostedt wrote:
>
> > On Tue, 29 Sep 2020 01:32:59 +0530
> > Naresh Kamboju wrote:
> >
> > > stable rc branch 4.19 build warning on arm64.
> > >
> > > ../kernel/kprobes.c: In function ‘kill_kprobe’:
> > > ../kernel/kprobes.c:1070:33: warning: statement with no effect
> > > [-Wunused-value]
> > > 1070 | #define disarm_kprobe_ftrace(p) (-ENODEV)
> > > | ^
> > > ../kernel/kprobes.c:2090:3: note: in expansion of macro
> > > ‘disarm_kprobe_ftrace’
> > > 2090 | disarm_kprobe_ftrace(p);
> > > | ^~~~
> >
> > Seems to affect upstream as well.
> >
>
> Bah, no (tested the wrong kernel).
>
> You want this commit too:
>
> 10de795a5addd ("kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE")
It seems that this commit's Fixes tag is wrong.
ae6aa16fdc163 (Masami Hiramatsu 2012-06-05 19:28:32 +0900 1079)
#define prepare_kprobe(p) arch_prepare_kprobe(p)
12310e3437554 (Jessica Yu 2018-01-10 00:51:23 +0100 1080)
#define arm_kprobe_ftrace(p) (-ENODEV)
297f9233b53a0 (Jessica Yu 2018-01-10 00:51:24 +0100 1081)
#define disarm_kprobe_ftrace(p) (-ENODEV)
Thus, it should have "Fixes: 297f9233b53a ("kprobes: Propagate error from
disarm_kprobe_ftrace()")"
$ git tag -l --contains 297f9233b53a | grep "^v[[:digit:].]*$" | cut -f1-2 -d.
| uniq
v4.16
v4.17
v4.18
v4.19
v4.20
v5.0
v5.1
v5.2
v5.3
v5.4
v5.5
v5.6
v5.7
v5.8
So the commit 10de795a5addd must be backported to 4.19.y and 5.4.y.
Thank you,
--
Masami Hiramatsu
Re: PROBLEM: zstd bzImage decompression fails for some x86_32 config on 5.9-rc1
On Tue, Sep 29, 2020 at 05:15:38AM +, Nick Terrell wrote: > > > > On Sep 28, 2020, at 11:02 AM, Nick Terrell wrote: > > > > > > > >> On Sep 28, 2020, at 1:55 AM, Feng Tang wrote: > >> > >> Hi Nick, > >> > >> 0day has found some kernel decomprssion failure case since 5.9-rc1 (X86_32 > >> build), and it could be related with ZSTD code, though initially we > >> bisected > >> to some other commits. > >> > >> The error messages are: > >>Decompressing Linux... > >> > >>ZSTD-compressed data is corrupt > >> > >> This could be reproduced by compiling the kernel with attached config, > >> and use QEMU to boot it. > >> > >> We suspect it could be related with the kernel size, as we only see > >> it on big kernel, and some more info are: > >> > >> * If we remove a lot of kernel config to build a much smaller kernel, > >> it will boot fine > >> > >> * If we change the zstd algorithm from zstd22 to zstd19, the kernel will > >> boot fine with below patch > >> > >> Please let me know if you need more info, and sorry for the late report > >> as we just tracked down to this point. > > > > Thanks for the report, I will look into it today. > > CC: Petr Malat > > I’ve successfully reproduced, and found the issue. It turns out that this > patch [0] from Petr Malat fixes the issue. As I mentioned in that thread, his > fix corresponds to this upstream commit [1]. Glad to know there is already a fix. > Can we get Petr's patch merged into v5.9? > > This bug only happens when the window size is > 8 MB. A non-kernel workaround > would be to compress the kernel level 19 instead of level 22, which uses an > 8 MB window size, instead of a 128 MB window size. > > The reason it only shows up for large kernels, is that the code is only buggy > when an offset > 8 MB is used, so a kernel <= 8 MB can't trigger the bug. > > Best, > Nick > > [0] https://lkml.org/lkml/2020/9/14/94 With this patch, all the failed cases on my side could boot fine. Tested-by: Feng Tang Thanks, Feng > [1] > https://github.com/facebook/zstd/commit/8a5c0c98ae5a7884694589d7a69bc99011add94d
Re: [PATCH 3/5] iommu/tegra-smmu: Use iommu_fwspec in .probe_/.attach_device()
On Tue, Sep 29, 2020 at 07:06:37AM +0300, Dmitry Osipenko wrote: > ... > >> As I mentioned in another reply, I think tegra_smmu_find() should be all > >> you need in this case. > > > > This function is used by .probe_device() where its dev pointer is > > an SMMU client. IIUC, tegra_smmu_find() needs np pointer of "mc". > > For a PCI device that doesn't have a DT node with iommus property, > > not sure how we can use tegra_smmu_find(). > > Perhaps you could get np from struct pci_dev.bus? Possibly yes...but I was hoping the solution would be potentially reused by other devices that don't have DT nodes, USB for example, though I haven't tested with current version.
Re: [PATCH v3 0/2] arm64/mm: Enable color zero pages
Hi Catalin, On 9/29/20 1:22 AM, Catalin Marinas wrote: On Mon, Sep 28, 2020 at 05:22:54PM +1000, Gavin Shan wrote: Testing === [1] The experiment reveals how heavily the (L1) data cache miss impacts the overall application's performance. The machine where the test is carried out has the following L1 data cache topology. In the mean while, the host kernel have following configurations. The test case allocates contiguous page frames through HugeTLBfs and reads 4-bytes data from the same offset (0x0) from these (N) contiguous page frames. N is equal to 8 or 9 separately in the following two test cases. This is repeated for one million of times. Note that 8 is number of L1 data cache ways. The experiment is cause L1 cache thrashing on one particular set. Host: CONFIG_ARM64_PAGE_SHIFT=12 DEFAULT_HUGE_PAGE_SIZE=2MB L1 dcache: cache-line-size=64 number-of-sets=64 number-of-ways=8 N=8 N=9 -- cache-misses: 43,4299,038,460 L1-dcache-load-misses: 43,4299,038,460 seconds time elapsed: 0.299206372 0.722253140 (2.41 times) [2] The experiment should have been carried out on machine where the L1 data cache capacity of one particular way is larger than 4KB. However, I'm unable to find such kind of machines. So I have to evaluate the performance impact caused by L2 data cache thrashing. The experiment is carried out on the machine, which has following L1/L2 data cache topology. The host kernel configuration is same to [1]. The corresponding test program allocates contiguous page frames through hugeTLBfs and builds VMAs backed by zero pages. These contiguous pages are sequentially read from fixed offset (0) in step of 32KB and by 8 times. After that, the VMA backed by zero pages are sequentially read in step of 4KB and by once. It's repeated by 8 millions of times. Note 32KB is the cache capacity in one L2 data cache way and 8 is number of L2 data cache sets. This experiment is to cause L2 data cache thrashing on one particular set. L1 dcache: L2 dcache: cache-line-size=64 number-of-sets=512 number-of-ways=8 --- cache-references: 1,427,213,7371,421,394,472 cache-misses: 35,804,552 42,636,698 L1-dcache-load-misses: 35,804,552 42,636,698 seconds time elapsed: 2.602511671 2.098198172 (+19.3%) No-one is denying a performance improvement in a very specific way but what's missing here is explaining how these artificial benchmarks relate to real-world applications. Thanks for your comments. It depends on the activities of reading zero pages and its frequency. The idea is to distribute reading zero page(s) on multiple sets of caches. Otherwise, the cache sets corresponding to these zero page(s) are have more load and prone to cause cache thrashing, depending on the workload pattern though. As discussed on v1, there are two use cases from the kernel code: (1) /proc/vmcore (2) DAX. For (1), it's only valid on x86 where those non-RAM-resident pages are mapped and backed by zero page(s). For (2), I was expecting to setup xfs and DAX on RBD (Ram Block Device). Unfortunately, DAX support for RBD was removed two years ago and I'm unable to enable xfs and DAX on RBD. DAX is only supported on limited hardware and I don't have around. # mknod /dev/ramdisk b 1 20 # mkfs.xfs /dev/ramdisk # mkdir -p /tmp/ramdisk # mount -txfs -odax /dev/ramdisk /tmp/ramdisk # dmesg | tail -n 4 [ 3721.848830] brd: module loaded [ 3772.015934] XFS (ram20): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [ 3772.023423] XFS (ram20): DAX unsupported by block device. Turning off DAX. [ 3772.030285] XFS (ram20): DAX and reflink cannot be used together! the feature just needs a couple of extra pages and it wouldn't be a concern. However, the caching behavior for reading zero page(s) is altering because the caches for zero pages are distributed. It depends on how frequently these zero page(s) are accessed. Also, I tried to build the kernel image and no performance altering is detected. command: make -j 80 clean; time make -j 80 (was executed for 3 times) without the patch: 3m29.084s 3m29.265s 3m30.806s with the patch:3m28.954s 3m29.819s 3m30.180s Cheers, Gavin
[RFC PATCH] scripts/most_common_subject_prefix.pl: Find the most common commit subject prefix
A common patch subject prefix for specific files is to use the
lowest level directory or just the basename of the file without the
file extension. For patches that touch multiple files, it's common to
use the basename directory as the commit prefix.
For example, patches to files in drivers/net/ethernet/intel/igb/ are
most commonly prefixed with "igb: ".
But many subsystems have specific commit subject line prefixes that are
not simply the containing base directory. For example, patches to
drivers/staging are most often prefixed with "staging: : "
then "".
So add a tool that can help find what prefix the subsystem or file most
commonly uses for patch commit subject lines.
This tool uses git log history in various ways to find the most common
prefix used in for a specific file or path.
$ ./scripts/most_common_subject_prefix.pl
This will emit a single line that is the most commonly used commit
subject prefix up to and including the last colon of the commit subject
for commits that _only_ include the specific file and not any other file.
For instance:
$ ./scripts/most_common_subject_prefix.pl arch/arm/net/bpf_jit_32.c
ARM: net: bpf:
An optional flag is --details which by default shows up to the 5 most common
commit subject prefixes and will show commits with just the single file as
well as commits that include other files.
$ ./scripts/most_common_subject_prefix.pl arch/arm/net/bpf_jit_32.c --details
Single file commits:
24 ARM: net: bpf:
5 bpf, arm32:
3 bpf, arm:
2 arm, bpf:
1 ARM: net:
Multiple file commits:
4 ARM: net: bpf:
2 arm:
2 bpf:
1 ARM: net:
1 arm: bpf:
command-line options are currently:
--git-since= (default: 5-years-ago)
(use commits more recent than this date to find the typical subject prefix)
--details show subject prefix details (default: 0/off)
--detail_lines= lines of details to show (default: 5)
--root=PATHPATH to the kernel tree root (default: ./)
Signed-off-by: Joe Perches
---
scripts/most_common_subject_prefix.pl | 183 ++
1 file changed, 183 insertions(+)
create mode 100755 scripts/most_common_subject_prefix.pl
diff --git a/scripts/most_common_subject_prefix.pl
b/scripts/most_common_subject_prefix.pl
new file mode 100755
index ..c3ceeacbec2f
--- /dev/null
+++ b/scripts/most_common_subject_prefix.pl
@@ -0,0 +1,183 @@
+#!/usr/bin/env perl
+
+# Show possible patch subject prefixes for a file in git
+
+# use only commits that modify the file argument and
+# emit up to the 5 most common commit headers
+
+use warnings;
+use strict;
+
+my $P = $0;
+my $V = '0.1';
+
+my $git_command ='export LANGUAGE=en_US.UTF-8; git';
+my $root;
+my $gitroot = $ENV{'GIT_DIR'};
+$gitroot = ".git" if !defined($gitroot);
+my $git_since = "5-years-ago";
+my $details = 0;
+my $detail_lines = 5;
+my $version = 0;
+my $help = 0;
+
+sub usage {
+print <
+version: $V
+
+Options:
+ --git-since= (default: $git_since)
+(use commits more recent than this date to find the typical subject prefix)
+ --details show subject prefix details (default: $details)
+ --detail_lines= lines of details to show (default: $detail_lines)
+ --root=PATHPATH to the kernel tree root (default: ./)
+
+EOT
+}
+
+use Getopt::Long qw(:config no_auto_abbrev);
+
+if (!GetOptions(
+ 'git-since=s' => \$git_since,
+ 'details!' => \$details,
+ 'detail_lines=i'=> \$detail_lines,
+ 'root=s'=> \$root,
+ 'v|version' => \$version,
+ 'h|help|usage' => \$help,
+ )) {
+die "$P: invalid argument - use --help if necessary\n";
+}
+
+if ($help != 0) {
+usage();
+exit 0;
+}
+
+if ($version != 0) {
+print("${P} ${V}\n");
+exit 0;
+}
+
+die "$P: Must have a single argument\n" if ($#ARGV != 0);
+
+die "$P: git not found\n" if (which("git") eq "");
+die "$P: git directory not found\n" if (!(-e "$gitroot"));
+
+if (defined $root) {
+ if (!top_of_kernel_tree($root)) {
+ die "$P: $root: --root does not point at a valid kernel tree\n";
+ }
+} else {
+ if (top_of_kernel_tree('.')) {
+ $root = '.';
+ } elsif ($0 =~ m@(.*)/scripts/[^/]*$@ &&
+top_of_kernel_tree($1)) {
+ $root = $1;
+ }
+}
+
+if (!defined $root) {
+ print "$P: Must be run from the top-level dir of a kernel tree\n";
+ exit(2);
+}
+
+sub prefixes_from_subjects {
+ my ($array_ref) = @_;
+ my %lc;
+ my @subjects = ();
+
+ foreach my $line (@$array_ref) {
+ my $pos = rindex($line, ':');
+ if ($pos > 0) {
+ my $prefix = substr($line, 0, $pos + 1);
+ $lc{$prefix}++;
+ }
+ }
+
+ foreach my $subject (sort { $lc{$b} <=> $lc{$a} or $a cmp
Re: [PATCH bpf-next v2 1/4] bpf: sockmap: enable map_update_elem from bpf_iter
On Mon, Sep 28, 2020 at 10:08:02AM +0100, Lorenz Bauer wrote: > Allow passing a pointer to a BTF struct sock_common* when updating > a sockmap or sockhash. Since BTF pointers can fault and therefore be > NULL at runtime we need to add an additional !sk check to > sock_map_update_elem. Since we may be passed a request or timewait > socket we also need to check sk_fullsock. Doing this allows calling > map_update_elem on sockmap from bpf_iter context, which uses > BTF pointers. Acked-by: Martin KaFai Lau
Re: general protection fault in gfs2_withdraw
syzbot has bisected this issue to:
commit 601ef0d52e9617588fcff3df26953592f2eb44ac
Author: Bob Peterson
Date: Tue Jan 28 19:23:45 2020 +
gfs2: Force withdraw to replay journals and wait for it to finish
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=151d25e390
start commit: 7c7ec322 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=171d25e390
console output: https://syzkaller.appspot.com/x/log.txt?x=131d25e390
kernel config: https://syzkaller.appspot.com/x/.config?x=6184b75aa6d48d66
dashboard link: https://syzkaller.appspot.com/bug?extid=50a8a9cf8127f2c6f5df
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13c6a10990
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15d45ed390
Reported-by: syzbot+50a8a9cf8127f2c6f...@syzkaller.appspotmail.com
Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it
to finish")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [RFC PATCH 1/2] kvm/x86: intercept guest changes to X86_CR4_LA57
On Tue, Sep 29, 2020 at 12:24 AM Sean Christopherson
wrote:
>
> On Mon, Sep 28, 2020 at 04:30:46PM +0800, Lai Jiangshan wrote:
> > From: Lai Jiangshan
> >
> > When shadowpaping is enabled, guest should not be allowed
> > to toggle X86_CR4_LA57. And X86_CR4_LA57 is a rarely changed
> > bit, so we can just intercept all the attempts to toggle it
> > no matter shadowpaping is in used or not.
> >
> > Fixes: fd8cb433734ee ("KVM: MMU: Expose the LA57 feature to VM.")
> > Cc: Sean Christopherson
> > Cc: Yu Zhang
> > Cc: Paolo Bonzini
> > Signed-off-by: Lai Jiangshan
> > ---
> > No test to toggle X86_CR4_LA57 in guest since I can't access to
> > any CPU supports it. Maybe it is not a real problem.
>
Hello
Thanks for reviewing.
> LA57 doesn't need to be intercepted. It can't be toggled in 64-bit mode
> (causes a #GP), and it's ignored in 32-bit mode. That means LA57 can only
> take effect when 64-bit mode is enabled, at which time KVM will update its
> MMU context accordingly.
>
Oh, I missed that part which is so obvious that the patch
seems impertinent.
But X86_CR4_LA57 is so fundamental that it makes me afraid to
give it over to guests. And it is rarely changed too. At least,
there is no better reason to give it to the guest than
intercepting it.
There might be another reason that this patch is still needed with
an updated changelog.
When a user (via VMM such as qemu) launches a VM with LA57 disabled
in its cpuid on a LA57 enabled host. The hypervisor, IMO, needs to
intercept guest's changes to X86_CR4_LA57 even when the guest is still
in the non-paging mode. Otherwise the hypervisor failed to detective
such combination when the guest changes paging mode later.
Anyway, maybe it is still not a real problem.
Thanks
Lai
Re: [PATCH v2 23/25] powerpc/signal: Create 'unsafe' versions of copy_[ck][fpr/vsx]_to_user()
Le 29/09/2020 à 07:22, Christophe Leroy a écrit :
Le 29/09/2020 à 04:04, Christopher M. Riedl a écrit :
On Tue Aug 18, 2020 at 12:19 PM CDT, Christophe Leroy wrote:
For the non VSX version, that's trivial. Just use unsafe_copy_to_user()
instead of __copy_to_user().
For the VSX version, remove the intermediate step through a buffer and
use unsafe_put_user() directly. This generates a far smaller code which
is acceptable to inline, see below:
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal.h | 53
1 file changed, 53 insertions(+)
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index f610cfafa478..2559a681536e 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -32,7 +32,54 @@ unsigned long copy_fpr_to_user(void __user *to,
struct task_struct *task);
unsigned long copy_ckfpr_to_user(void __user *to, struct task_struct
*task);
unsigned long copy_fpr_from_user(struct task_struct *task, void __user
*from);
unsigned long copy_ckfpr_from_user(struct task_struct *task, void __user
*from);
+
+#define unsafe_copy_fpr_to_user(to, task, label) do { \
+ struct task_struct *__t = task; \
+ u64 __user *buf = (u64 __user *)to; \
+ int i; \
+ \
+ for (i = 0; i < ELF_NFPREG - 1 ; i++) \
+ unsafe_put_user(__t->thread.TS_FPR(i), [i], label); \
+ unsafe_put_user(__t->thread.fp_state.fpscr, [i], label); \
+} while (0)
+
I've been working on the PPC64 side of this "unsafe" rework using this
series as a basis. One question here - I don't really understand what
the benefit of re-implementing this logic in macros (similarly for the
other copy_* functions below) is?
Not sure either.
The whole purpose is to not manage the error through a local var but
exclusively use labels.
However, GCC is probably smart enough to understand it and drop the local var
while inlining.
One important thing however is to make sure we won't end up with an outline function, otherwise you
completely loose the benefit of the label stuff. And you get a function call inside a user access,
which is what we want to avoid.
I am considering a "__unsafe_copy_*" implementation in signal.c for
each (just the original implementation w/ using the "unsafe_" variants
of the uaccess stuff) which gets called by the "safe" functions w/ the
appropriate "user_*_access_begin/user_*_access_end". Something like
(pseudo-ish code):
Good idea, however ...
/* signal.c */
unsigned long __unsafe_copy_fpr_to_user(...)
{
...
unsafe_copy_to_user(..., bad);
return 0;
bad:
return 1; /* -EFAULT? */
}
This __unsafe_copy_fpr_to_user() has to be in signal.h and must be tagged 'static __always_inline'
for the reasons explained above.
unsigned long copy_fpr_to_user(...)
{
unsigned long err;
if (!user_write_access_begin(...))
return 1; /* -EFAULT? */
err = __unsafe_copy_fpr_to_user(...);
user_write_access_end();
return err;
}
Also note that at the end (ie when both PPC32 and PPC64 signal code are using "unsafe" versions),
the "safe" version won't be used anymore and will be dropped.
Christophe
RE: [PATCH v6] mm/zswap: move to use crypto_acomp API for hardware acceleration
> -Original Message-
> From: Song Bao Hua (Barry Song)
> Sent: Tuesday, September 29, 2020 10:02 AM
> To: 'Sebastian Andrzej Siewior'
> Cc: a...@linux-foundation.org; herb...@gondor.apana.org.au;
> da...@davemloft.net; linux-cry...@vger.kernel.org; linux...@kvack.org;
> linux-kernel@vger.kernel.org; Luis Claudio R . Goncalves
> ; Mahipal Challa ;
> Seth Jennings ; Dan Streetman ;
> Vitaly Wool ; Wangzhou (B)
> ; fanghao (A) ; Colin
> Ian King
> Subject: RE: [PATCH v6] mm/zswap: move to use crypto_acomp API for
> hardware acceleration
>
>
>
> > -Original Message-
> > From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
> > Sent: Tuesday, September 29, 2020 4:25 AM
> > To: Song Bao Hua (Barry Song)
> > Cc: a...@linux-foundation.org; herb...@gondor.apana.org.au;
> > da...@davemloft.net; linux-cry...@vger.kernel.org; linux...@kvack.org;
> > linux-kernel@vger.kernel.org; Luis Claudio R . Goncalves
> > ; Mahipal Challa ;
> > Seth Jennings ; Dan Streetman ;
> > Vitaly Wool ; Wangzhou (B)
> > ; fanghao (A) ; Colin
> > Ian King
> > Subject: Re: [PATCH v6] mm/zswap: move to use crypto_acomp API for
> > hardware acceleration
> >
> > On 2020-08-19 00:31:00 [+1200], Barry Song wrote:
> > > diff --git a/mm/zswap.c b/mm/zswap.c
> > > index fbb782924ccc..00b5f14a7332 100644
> > > --- a/mm/zswap.c
> > > +++ b/mm/zswap.c
> > > @@ -127,9 +129,17 @@
> > module_param_named(same_filled_pages_enabled,
> > zswap_same_filled_pages_enabled,
> > > * data structures
> > > **/
> > >
> > > +struct crypto_acomp_ctx {
> > > + struct crypto_acomp *acomp;
> > > + struct acomp_req *req;
> > > + struct crypto_wait wait;
> > > + u8 *dstmem;
> > > + struct mutex *mutex;
> > > +};
> > > +
> > > struct zswap_pool {
> > > struct zpool *zpool;
> > > - struct crypto_comp * __percpu *tfm;
> > > + struct crypto_acomp_ctx __percpu *acomp_ctx;
> > > struct kref kref;
> > > struct list_head list;
> > > struct work_struct release_work;
> > > @@ -388,23 +398,43 @@ static struct zswap_entry
> > *zswap_entry_find_get(struct rb_root *root,
> > > * per-cpu code
> > > **/
> > > static DEFINE_PER_CPU(u8 *, zswap_dstmem);
> > > +/*
> > > + * If users dynamically change the zpool type and compressor at runtime,
> > i.e.
> > > + * zswap is running, zswap can have more than one zpool on one cpu, but
> > they
> > > + * are sharing dtsmem. So we need this mutex to be per-cpu.
> > > + */
> > > +static DEFINE_PER_CPU(struct mutex *, zswap_mutex);
> >
> > There is no need to make it sturct mutex*. You could make it struct
> > mutex. The following make it more obvious how the relation here is (even
> > without a comment):
> >
> > |struct zswap_mem_pool {
> > | void*dst_mem;
> > | struct mutexlock;
> > |};
> > |
> > |static DEFINE_PER_CPU(struct zswap_mem_pool , zswap_mem_pool);
> >
> > Please access only this, don't add use a pointer in a another struct to
> > dest_mem or lock which may confuse people.
>
> Well. It seems sensible.
After second thought and trying to make this change, I would like to change my
mind
and disagree with this idea. Two reasons:
1. while using this_cpu_ptr() without preemption lock, people usually put all
things bound
with one cpu to one structure, so that once we get the pointer of the whole
structure, we get
all its parts belonging to the same cpu. If we move the dstmem and mutex out of
the structure
containing them, we will have to do:
a. get_cpu_ptr() for the acomp_ctx //lock preemption
b. this_cpu_ptr() for the dstmem and mutex
c. put_cpu_ptr() for the acomp_ctx //unlock preemption
d. mutex_lock()
sg_init_one()
compress/decompress etc.
...
mutex_unlock
as the get() and put() have a preemption lock/unlock, this will make certain
this_cpu_ptr()
in the step "b" will return the right dstmem and mutex which belong to the same
cpu with
step "a".
The steps from "a" to "c" are quite silly and confusing. I believe the existing
code aligns
with the most similar code in kernel better:
a. this_cpu_ptr() //get everything for one cpu
b. mutex_lock()
sg_init_one()
compress/decompress etc.
...
mutex_unlock
2. while allocating mutex, we can put the mutex into local memory by using
kmalloc_node().
If we move to "struct mutex lock" directly, most CPUs in a NUMA server will
have to access
remote memory to read/write the mutex, therefore, this will increase the
latency dramatically.
Thanks
Barry
Re: [PATCH v2 23/25] powerpc/signal: Create 'unsafe' versions of copy_[ck][fpr/vsx]_to_user()
Le 29/09/2020 à 04:04, Christopher M. Riedl a écrit :
On Tue Aug 18, 2020 at 12:19 PM CDT, Christophe Leroy wrote:
For the non VSX version, that's trivial. Just use unsafe_copy_to_user()
instead of __copy_to_user().
For the VSX version, remove the intermediate step through a buffer and
use unsafe_put_user() directly. This generates a far smaller code which
is acceptable to inline, see below:
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal.h | 53
1 file changed, 53 insertions(+)
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index f610cfafa478..2559a681536e 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -32,7 +32,54 @@ unsigned long copy_fpr_to_user(void __user *to,
struct task_struct *task);
unsigned long copy_ckfpr_to_user(void __user *to, struct task_struct
*task);
unsigned long copy_fpr_from_user(struct task_struct *task, void __user
*from);
unsigned long copy_ckfpr_from_user(struct task_struct *task, void __user
*from);
+
+#define unsafe_copy_fpr_to_user(to, task, label) do { \
+ struct task_struct *__t = task; \
+ u64 __user *buf = (u64 __user *)to; \
+ int i; \
+ \
+ for (i = 0; i < ELF_NFPREG - 1 ; i++) \
+ unsafe_put_user(__t->thread.TS_FPR(i), [i], label); \
+ unsafe_put_user(__t->thread.fp_state.fpscr, [i], label); \
+} while (0)
+
I've been working on the PPC64 side of this "unsafe" rework using this
series as a basis. One question here - I don't really understand what
the benefit of re-implementing this logic in macros (similarly for the
other copy_* functions below) is?
Not sure either.
The whole purpose is to not manage the error through a local var but
exclusively use labels.
However, GCC is probably smart enough to understand it and drop the local var
while inlining.
One important thing however is to make sure we won't end up with an outline function, otherwise you
completely loose the benefit of the label stuff. And you get a function call inside a user access,
which is what we want to avoid.
I am considering a "__unsafe_copy_*" implementation in signal.c for
each (just the original implementation w/ using the "unsafe_" variants
of the uaccess stuff) which gets called by the "safe" functions w/ the
appropriate "user_*_access_begin/user_*_access_end". Something like
(pseudo-ish code):
Good idea, however ...
/* signal.c */
unsigned long __unsafe_copy_fpr_to_user(...)
{
...
unsafe_copy_to_user(..., bad);
return 0;
bad:
return 1; /* -EFAULT? */
}
This __unsafe_copy_fpr_to_user() has to be in signal.h and must be tagged 'static __always_inline'
for the reasons explained above.
unsigned long copy_fpr_to_user(...)
{
unsigned long err;
if (!user_write_access_begin(...))
return 1; /* -EFAULT? */
err = __unsafe_copy_fpr_to_user(...);
user_write_access_end();
return err;
}
/* signal.h */
unsigned long __unsafe_copy_fpr_to_user(...);
#define unsafe_copy_fpr_to_user(..., label) \
unsafe_op_wrap(__unsafe_copy_fpr_to_user(...), label)
This way there is a single implementation for each copy routine "body".
The "unsafe" wrappers then just exist as simple macros similar to what
x86 does: "unsafe_" macro wraps "__unsafe" functions for the goto label.
Yes, good point.
Christophe
Re: [PATCH v2 25/25] powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version
Le 29/09/2020 à 04:55, Christopher M. Riedl a écrit :
On Tue Aug 18, 2020 at 12:19 PM CDT, Christophe Leroy wrote:
Change those two functions to be used within a user access block.
For that, change save_general_regs() to and unsafe_save_general_regs(),
then replace all user accesses by unsafe_ versions.
This series leads to a reduction from 2.55s to 1.73s of
the system CPU time with the following microbench app
on an mpc832x with KUAP (approx 32%)
Without KUAP, the difference is in the noise.
void sigusr1(int sig) { }
int main(int argc, char **argv)
{
int i = 10;
signal(SIGUSR1, sigusr1);
for (;i--;)
raise(SIGUSR1);
exit(0);
}
An additional 0.10s reduction is achieved by removing
CONFIG_PPC_FPU, as the mpc832x has no FPU.
A bit less spectacular on an 8xx as KUAP is less heavy, prior to
the series (with KUAP) it ran in 8.10 ms. Once applies the removal
of FPU regs handling, we get 7.05s. With the full series, we get 6.9s.
If artificially re-activating FPU regs handling with the full series,
we get 7.6s.
So for the 8xx, the removal of the FPU regs copy is what makes the
difference, but the rework of handle_signal also have a benefit.
Same as above, without KUAP the difference is in the noise.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/signal_32.c | 224
1 file changed, 111 insertions(+), 113 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c
b/arch/powerpc/kernel/signal_32.c
index 86539a4e0514..f795fe0240a1 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -93,8 +93,8 @@ static inline int get_sigset_t(sigset_t *set,
#define to_user_ptr(p) ptr_to_compat(p)
#define from_user_ptr(p) compat_ptr(p)
-static inline int save_general_regs(struct pt_regs *regs,
- struct mcontext __user *frame)
+static __always_inline int
+save_general_regs_unsafe(struct pt_regs *regs, struct mcontext __user
*frame)
{
elf_greg_t64 *gregs = (elf_greg_t64 *)regs;
int val, i;
@@ -108,10 +108,12 @@ static inline int save_general_regs(struct pt_regs
*regs,
else
val = gregs[i];
- if (__put_user(val, >mc_gregs[i]))
- return -EFAULT;
+ unsafe_put_user(val, >mc_gregs[i], failed);
}
return 0;
+
+failed:
+ return 1;
}
static inline int restore_general_regs(struct pt_regs *regs,
@@ -148,11 +150,15 @@ static inline int get_sigset_t(sigset_t *set,
const sigset_t __user *uset)
#define to_user_ptr(p) ((unsigned long)(p))
#define from_user_ptr(p) ((void __user *)(p))
-static inline int save_general_regs(struct pt_regs *regs,
- struct mcontext __user *frame)
+static __always_inline int
+save_general_regs_unsafe(struct pt_regs *regs, struct mcontext __user
*frame)
{
WARN_ON(!FULL_REGS(regs));
- return __copy_to_user(>mc_gregs, regs, GP_REGS_SIZE);
+ unsafe_copy_to_user(>mc_gregs, regs, GP_REGS_SIZE, failed);
+ return 0;
+
+failed:
+ return 1;
}
static inline int restore_general_regs(struct pt_regs *regs,
@@ -170,6 +176,11 @@ static inline int restore_general_regs(struct
pt_regs *regs,
}
#endif
+#define unsafe_save_general_regs(regs, frame, label) do { \
+ if (save_general_regs_unsafe(regs, frame)) \
Minor nitpick (sorry); this naming seems a bit strange to me, in x86 it
is "__unsafe_" as a prefix instead of "_unsafe" as a suffix. That sounds
a bit better to me, what do you think? Unless there is some convention I
am not aware of here apart from "unsafe_" using a goto label for errors.
You are probably right, I have never been good at naming stuff.
Christophe
Re: [PATCH WIP 1/6] media: vidtv: extract the initial CRC value to into a #define
Em Tue, 29 Sep 2020 00:26:20 -0300
"Daniel W. S. Almeida" escreveu:
> From: Daniel W. S. Almeida
On a very quick look, patches seem good. Why did you mark them as WIP?
Next time, please add a patch 0, specially when you tag something as
WIP, or RFC.
>
> The same constant (0x) is used in three different functions.
This one at least seems to be ready for merging ;-)
Regards,
Mauro
>
> Extract it into a #define to avoid repetition.
>
> Signed-off-by: Daniel W. S. Almeida
> ---
> drivers/media/test-drivers/vidtv/vidtv_psi.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.c
> b/drivers/media/test-drivers/vidtv/vidtv_psi.c
> index 3151b300a91b..a24e84adc8ce 100644
> --- a/drivers/media/test-drivers/vidtv/vidtv_psi.c
> +++ b/drivers/media/test-drivers/vidtv/vidtv_psi.c
> @@ -30,6 +30,7 @@
>
> #define CRC_SIZE_IN_BYTES 4
> #define MAX_VERSION_NUM 32
> +#define INITIAL_CRC 0x
>
> static const u32 CRC_LUT[256] = {
> /* from libdvbv5 */
> @@ -794,7 +795,7 @@ u32 vidtv_psi_pat_write_into(struct
> vidtv_psi_pat_write_args args)
> /* the number of bytes written by this function */
> u32 nbytes = 0;
> const u16 pat_pid = VIDTV_PAT_PID;
> - u32 crc = 0x;
> + u32 crc = INITIAL_CRC;
>
> struct vidtv_psi_table_pat_program *p = args.pat->program;
>
> @@ -990,7 +991,7 @@ u32 vidtv_psi_pmt_write_into(struct
> vidtv_psi_pmt_write_args args)
> {
> /* the number of bytes written by this function */
> u32 nbytes = 0;
> - u32 crc = 0x;
> + u32 crc = INITIAL_CRC;
>
> struct vidtv_psi_desc *table_descriptor = args.pmt->descriptor;
> struct vidtv_psi_table_pmt_stream *stream = args.pmt->stream;
> @@ -1143,7 +1144,7 @@ u32 vidtv_psi_sdt_write_into(struct
> vidtv_psi_sdt_write_args args)
> u32 nbytes = 0;
> u16 sdt_pid = VIDTV_SDT_PID; /* see ETSI EN 300 468 v1.15.1 p. 11 */
>
> - u32 crc = 0x;
> + u32 crc = INITIAL_CRC;
>
> struct vidtv_psi_table_sdt_service *service = args.sdt->service;
> struct vidtv_psi_desc *service_desc = (args.sdt->service) ?
Thanks,
Mauro
Re: [PATCH] ipvs: Add traffic statistic up even it is VS/DR or VS/TUN mode
especially in public cloud case, statistic is related to monitorring
and billing , both ingress and egress packets will go throught ipvs,
even dr/tun mode.
in dr/tun mode, ipvs need to do nothing except statistic, so
skb->ipvs_property = 1
regards
On Tue, Sep 29, 2020 at 1:04 PM longguang.yue wrote:
>
> It's ipvs's duty to do traffic statistic if packets get hit,
> no matter what mode it is.
>
> Signed-off-by: longguang.yue
> ---
> net/netfilter/ipvs/ip_vs_core.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index e3668a6e54e4..ed523057f07f 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1413,8 +1413,11 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int
> hooknum, struct sk_buff *skb, in
> ipvs, af, skb, );
>
> if (likely(cp)) {
> - if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
> + if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ){
> + ip_vs_out_stats(cp, skb);
> + skb->ipvs_property = 1;
> goto ignore_cp;
> + }
> return handle_response(af, skb, pd, cp, , hooknum);
> }
>
> --
> 2.20.1 (Apple Git-117)
>
Re: PROBLEM: zstd bzImage decompression fails for some x86_32 config on 5.9-rc1
> On Sep 28, 2020, at 11:02 AM, Nick Terrell wrote: > > > >> On Sep 28, 2020, at 1:55 AM, Feng Tang wrote: >> >> Hi Nick, >> >> 0day has found some kernel decomprssion failure case since 5.9-rc1 (X86_32 >> build), and it could be related with ZSTD code, though initially we bisected >> to some other commits. >> >> The error messages are: >> >> early console in setup code >> Wrong EFI loader signature. >> early console in extract_kernel >> input_data: 0x046f50b4 >> input_len: 0x01ebbeb6 >> output: 0x0100 >> output_len: 0x04fc535c >> kernel_total_size: 0x055f5000 >> needed_size: 0x055f5000 >> >> Decompressing Linux... >> >> ZSTD-compressed data is corrupt >> >> This could be reproduced by compiling the kernel with attached config, >> and use QEMU to boot it. >> >> We suspect it could be related with the kernel size, as we only see >> it on big kernel, and some more info are: >> >> * If we remove a lot of kernel config to build a much smaller kernel, >> it will boot fine >> >> * If we change the zstd algorithm from zstd22 to zstd19, the kernel will >> boot fine with below patch >> >> diff --git a/arch/x86/boot/compressed/Makefile >> b/arch/x86/boot/compressed/Makefile >> index 3962f59..8fe71ba 100644 >> --- a/arch/x86/boot/compressed/Makefile >> +++ b/arch/x86/boot/compressed/Makefile >> @@ -147,7 +147,7 @@ $(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE >> $(obj)/vmlinux.bin.zst: $(vmlinux.bin.all-y) FORCE >> - $(call if_changed,zstd22) >> + $(call if_changed,zstd) >> >> >> Please let me know if you need more info, and sorry for the late report >> as we just tracked down to this point. > > Thanks for the report, I will look into it today. CC: Petr Malat I’ve successfully reproduced, and found the issue. It turns out that this patch [0] from Petr Malat fixes the issue. As I mentioned in that thread, his fix corresponds to this upstream commit [1]. Can we get Petr's patch merged into v5.9? This bug only happens when the window size is > 8 MB. A non-kernel workaround would be to compress the kernel level 19 instead of level 22, which uses an 8 MB window size, instead of a 128 MB window size. The reason it only shows up for large kernels, is that the code is only buggy when an offset > 8 MB is used, so a kernel <= 8 MB can't trigger the bug. Best, Nick [0] https://lkml.org/lkml/2020/9/14/94 [1] https://github.com/facebook/zstd/commit/8a5c0c98ae5a7884694589d7a69bc99011add94d > Best, > Nick > >> Thanks, >> Feng >> >> >> >>
Re: [PATCH v6 4/4] KVM: nSVM: implement on demand allocation of the nested state
On Wed, Sep 23, 2020 at 12:10:25AM +0300, Maxim Levitsky wrote:
> This way we don't waste memory on VMs which don't use nesting
> virtualization even when the host enabled it for them.
>
> Signed-off-by: Maxim Levitsky
> ---
> arch/x86/kvm/svm/nested.c | 42 ++
> arch/x86/kvm/svm/svm.c| 55 ++-
> arch/x86/kvm/svm/svm.h| 6 +
> 3 files changed, 79 insertions(+), 24 deletions(-)
>
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index 09417f5197410..dd13856818a03 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -467,6 +467,9 @@ int nested_svm_vmrun(struct vcpu_svm *svm)
>
> vmcb12 = map.hva;
>
> + if (WARN_ON(!svm->nested.initialized))
Probably should use WARN_ON_ONCE, if this is somehow it, userspace could
easily spam the kernel.
Side topic, do we actually need 'initialized'? Wouldn't checking for a
valid nested.msrpm or nested.hsave suffice?
> + return 1;
> +
> if (!nested_vmcb_checks(svm, vmcb12)) {
> vmcb12->control.exit_code= SVM_EXIT_ERR;
> vmcb12->control.exit_code_hi = 0;
> @@ -684,6 +687,45 @@ int nested_svm_vmexit(struct vcpu_svm *svm)
> return 0;
> }
Re: [PATCH v6 3/4] KVM: x86: allow kvm_x86_ops.set_efer to return an error value
On Wed, Sep 23, 2020 at 12:10:24AM +0300, Maxim Levitsky wrote:
> This will be used to signal an error to the userspace, in case
> the vendor code failed during handling of this msr. (e.g -ENOMEM)
>
> Signed-off-by: Maxim Levitsky
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e4b07be450d4e..df53baa0059fe 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1456,6 +1456,7 @@ static int set_efer(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> {
> u64 old_efer = vcpu->arch.efer;
> u64 efer = msr_info->data;
> + int r;
>
> if (efer & efer_reserved_bits)
> return 1;
> @@ -1472,7 +1473,12 @@ static int set_efer(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> efer &= ~EFER_LMA;
> efer |= vcpu->arch.efer & EFER_LMA;
>
> - kvm_x86_ops.set_efer(vcpu, efer);
> + r = kvm_x86_ops.set_efer(vcpu, efer);
> +
Nit: IMO, omitting the newline would help the reader make a direct connection
between setting 'r' and checking 'r'.
> + if (r) {
> + WARN_ON(r > 0);
> + return r;
> + }
>
> /* Update reserved bits */
> if ((efer ^ old_efer) & EFER_NX)
> --
> 2.26.2
>
[PATCH] ipvs: Add traffic statistic up even it is VS/DR or VS/TUN mode
It's ipvs's duty to do traffic statistic if packets get hit,
no matter what mode it is.
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index e3668a6e54e4..ed523057f07f 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1413,8 +1413,11 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum,
struct sk_buff *skb, in
ipvs, af, skb, );
if (likely(cp)) {
- if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+ if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ){
+ ip_vs_out_stats(cp, skb);
+ skb->ipvs_property = 1;
goto ignore_cp;
+ }
return handle_response(af, skb, pd, cp, , hooknum);
}
--
2.20.1 (Apple Git-117)
[PATCH v3 2/2] iommu/tegra-smmu: Expend mutex protection range
This is used to protect potential race condition at use_count.
since probes of client drivers, calling attach_dev(), may run
concurrently.
Signed-off-by: Nicolin Chen
---
Changelog
v2->v3:
* Renamed label "err_unlock" to "unlock"
v1->v2:
* N/A
drivers/iommu/tegra-smmu.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index ec4c9dafff95..6a3ecc334481 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -256,26 +256,19 @@ static int tegra_smmu_alloc_asid(struct tegra_smmu *smmu,
unsigned int *idp)
{
unsigned long id;
- mutex_lock(>lock);
-
id = find_first_zero_bit(smmu->asids, smmu->soc->num_asids);
- if (id >= smmu->soc->num_asids) {
- mutex_unlock(>lock);
+ if (id >= smmu->soc->num_asids)
return -ENOSPC;
- }
set_bit(id, smmu->asids);
*idp = id;
- mutex_unlock(>lock);
return 0;
}
static void tegra_smmu_free_asid(struct tegra_smmu *smmu, unsigned int id)
{
- mutex_lock(>lock);
clear_bit(id, smmu->asids);
- mutex_unlock(>lock);
}
static bool tegra_smmu_capable(enum iommu_cap cap)
@@ -420,17 +413,21 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu,
struct tegra_smmu_as *as)
{
u32 value;
- int err;
+ int err = 0;
+
+ mutex_lock(>lock);
if (as->use_count > 0) {
as->use_count++;
- return 0;
+ goto unlock;
}
as->pd_dma = dma_map_page(smmu->dev, as->pd, 0, SMMU_SIZE_PD,
DMA_TO_DEVICE);
- if (dma_mapping_error(smmu->dev, as->pd_dma))
- return -ENOMEM;
+ if (dma_mapping_error(smmu->dev, as->pd_dma)) {
+ err = -ENOMEM;
+ goto unlock;
+ }
/* We can't handle 64-bit DMA addresses */
if (!smmu_dma_addr_valid(smmu, as->pd_dma)) {
@@ -453,24 +450,35 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu,
as->smmu = smmu;
as->use_count++;
+ mutex_unlock(>lock);
+
return 0;
err_unmap:
dma_unmap_page(smmu->dev, as->pd_dma, SMMU_SIZE_PD, DMA_TO_DEVICE);
+unlock:
+ mutex_unlock(>lock);
+
return err;
}
static void tegra_smmu_as_unprepare(struct tegra_smmu *smmu,
struct tegra_smmu_as *as)
{
- if (--as->use_count > 0)
+ mutex_lock(>lock);
+
+ if (--as->use_count > 0) {
+ mutex_unlock(>lock);
return;
+ }
tegra_smmu_free_asid(smmu, as->id);
dma_unmap_page(smmu->dev, as->pd_dma, SMMU_SIZE_PD, DMA_TO_DEVICE);
as->smmu = NULL;
+
+ mutex_unlock(>lock);
}
static int tegra_smmu_attach_dev(struct iommu_domain *domain,
--
2.17.1
[PATCH v3 0/2] iommu/tegra-smmu: Two followup changes
Two followup patches for tegra-smmu: PATCH-1 is a clean-up patch for the recently applied SWGROUP change. PATCH-2 fixes a potential race condition Changelog v2->v3: * PATCH-2: renamed "err_unlock" to "unlock" v1->v2: * Separated first two changs of V1 so they may get applied first, since the other three changes need some extra time to finalize. Nicolin Chen (2): iommu/tegra-smmu: Unwrap tegra_smmu_group_get iommu/tegra-smmu: Expend mutex protection range drivers/iommu/tegra-smmu.c | 53 ++ 1 file changed, 25 insertions(+), 28 deletions(-) -- 2.17.1
[PATCH v3 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get
The tegra_smmu_group_get was added to group devices in different
SWGROUPs and it'd return a NULL group pointer upon a mismatch at
tegra_smmu_find_group(), so for most of clients/devices, it very
likely would mismatch and need a fallback generic_device_group().
But now tegra_smmu_group_get handles devices in same SWGROUP too,
which means that it would allocate a group for every new SWGROUP
or would directly return an existing one upon matching a SWGROUP,
i.e. any device will go through this function.
So possibility of having a NULL group pointer in device_group()
is upon failure of either devm_kzalloc() or iommu_group_alloc().
In either case, calling generic_device_group() no longer makes a
sense. Especially for devm_kzalloc() failing case, it'd cause a
problem if it fails at devm_kzalloc() yet succeeds at a fallback
generic_device_group(), because it does not create a group->list
for other devices to match.
This patch simply unwraps the function to clean it up.
Signed-off-by: Nicolin Chen
---
Changelog
v2->v3:
* N/A
v1->v2:
* Changed type of swgroup to "unsigned int", following Thierry's
commnets.
drivers/iommu/tegra-smmu.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 0becdbfea306..ec4c9dafff95 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -903,10 +903,12 @@ static void tegra_smmu_group_release(void *iommu_data)
mutex_unlock(>lock);
}
-static struct iommu_group *tegra_smmu_group_get(struct tegra_smmu *smmu,
- unsigned int swgroup)
+static struct iommu_group *tegra_smmu_device_group(struct device *dev)
{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
const struct tegra_smmu_group_soc *soc;
+ unsigned int swgroup = fwspec->ids[0];
struct tegra_smmu_group *group;
struct iommu_group *grp;
@@ -950,19 +952,6 @@ static struct iommu_group *tegra_smmu_group_get(struct
tegra_smmu *smmu,
return group->group;
}
-static struct iommu_group *tegra_smmu_device_group(struct device *dev)
-{
- struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
- struct iommu_group *group;
-
- group = tegra_smmu_group_get(smmu, fwspec->ids[0]);
- if (!group)
- group = generic_device_group(dev);
-
- return group;
-}
-
static int tegra_smmu_of_xlate(struct device *dev,
struct of_phandle_args *args)
{
--
2.17.1
Re: [PATCH] net/x25: Fix null-ptr-deref in x25_connect
On 2020-09-29 03:43, David Miller wrote:
From: Martin Schiller
Date: Mon, 28 Sep 2020 11:23:27 +0200
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 0bbb283f23c9..0524a5530b91 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -820,7 +820,7 @@ static int x25_connect(struct socket *sock, struct
sockaddr *uaddr,
rc = x25_wait_for_connection_establishment(sk);
if (rc)
- goto out_put_neigh;
+ goto out;
If x25_wait_for_connection_establishment() returns because of an
interrupting
signal, we are not going to call x25_disconnect().
The case you are fixing only applies _sometimes_ when
x25_wait_for_connection_establishment() returns. But not always.
That neighbour has to be released at this spot otherwise.
OK, thanks for the hint. So I think the simplest solution would be to
check
that x25->neighbour is != NULL like this:
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 0bbb283f23c9..046d3fee66a9 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -825,7 +825,7 @@ static int x25_connect(struct socket *sock, struct
sockaddr *uaddr,
sock->state = SS_CONNECTED;
rc = 0;
out_put_neigh:
- if (rc) {
+ if (rc && x25->neighbour) {
read_lock_bh(_list_lock);
x25_neigh_put(x25->neighbour);
x25->neighbour = NULL;
--
What do you think?
If that would be OK, I'll send a v2 of the Patch.
- Martin
Re: [PATCH v2 for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs
On Tue, 29 Sep 2020 10:28:05 +0900 Joonsoo Kim wrote: > > What about manually emptying the pcplists beforehand? > > It also increases the probability. schedule() or interrupt after emptying but > before the allocation could invalidate the effect. Keep local interrupts disabled across the pcp drain and the allocation attempt. > > Or byassing the pcplists for this caller and calling __rmqueue() directly? > > What this patch does is this one. I meant via a different function rather than by adding overhead to the existing commonly-used function.
Re: [PATCH v3] Bluetooth: Check for encryption key size on connect
Hi Marcel,
On Tue, 29 Sep 2020 at 00:43, Marcel Holtmann wrote:
>
> Hi Archie,
>
> > When receiving connection, we only check whether the link has been
> > encrypted, but not the encryption key size of the link.
> >
> > This patch adds check for encryption key size, and reject L2CAP
> > connection which size is below the specified threshold (default 7)
> > with security block.
> >
> > Here is some btmon trace.
> > @ MGMT Event: New Link Key (0x0009) plen 26{0x0001} [hci0] 5.847722
> > Store hint: No (0x00)
> > BR/EDR Address: 38:00:25:F7:F1:B0 (OUI 38-00-25)
> > Key type: Unauthenticated Combination key from P-192 (0x04)
> > Link key: 7bf2f68c81305d63a6b0ee2c5a7a34bc
> > PIN length: 0
> >> HCI Event: Encryption Change (0x08) plen 4#29 [hci0] 5.871537
> > Status: Success (0x00)
> > Handle: 256
> > Encryption: Enabled with E0 (0x01)
> > < HCI Command: Read Encryp... (0x05|0x0008) plen 2 #30 [hci0] 5.871609
> > Handle: 256
> >> HCI Event: Command Complete (0x0e) plen 7 #31 [hci0] 5.872524
> >Read Encryption Key Size (0x05|0x0008) ncmd 1
> > Status: Success (0x00)
> > Handle: 256
> > Key size: 3
> >
> > // WITHOUT PATCH //
> >> ACL Data RX: Handle 256 flags 0x02 dlen 12#42 [hci0] 5.895023
> >L2CAP: Connection Request (0x02) ident 3 len 4
> > PSM: 4097 (0x1001)
> > Source CID: 64
> > < ACL Data TX: Handle 256 flags 0x00 dlen 16#43 [hci0] 5.895213
> >L2CAP: Connection Response (0x03) ident 3 len 8
> > Destination CID: 64
> > Source CID: 64
> > Result: Connection successful (0x)
> > Status: No further information available (0x)
> >
> > // WITH PATCH //
> >> ACL Data RX: Handle 256 flags 0x02 dlen 12#42 [hci0] 4.887024
> >L2CAP: Connection Request (0x02) ident 3 len 4
> > PSM: 4097 (0x1001)
> > Source CID: 64
> > < ACL Data TX: Handle 256 flags 0x00 dlen 16#43 [hci0] 4.887127
> >L2CAP: Connection Response (0x03) ident 3 len 8
> > Destination CID: 0
> > Source CID: 64
> > Result: Connection refused - security block (0x0003)
> > Status: No further information available (0x)
> >
> > Signed-off-by: Archie Pusaka
> >
> > ---
> >
> > Changes in v3:
> > * Move the check to hci_conn_check_link_mode()
> >
> > Changes in v2:
> > * Add btmon trace to the commit message
> >
> > net/bluetooth/hci_conn.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index 9832f8445d43..89085fac797c 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -1348,6 +1348,10 @@ int hci_conn_check_link_mode(struct hci_conn
> > *conn)
> > !test_bit(HCI_CONN_ENCRYPT, >flags))
> > return 0;
> >
> > + if (test_bit(HCI_CONN_ENCRYPT, >flags) &&
> > + conn->enc_key_size < conn->hdev->min_enc_key_size)
> > + return 0;
> > +
> > return 1;
> > }
>
> I am a bit concerned since we had that check and I on purpose moved it.
> See commit 693cd8ce3f88 for the change where I removed and commit
> d5bb334a8e17 where I initially added it.
>
> Naively adding the check in that location caused a major regression with
> Bluetooth 2.0 devices. This makes me a bit reluctant to re-add it here
> since I restructured the whole change to check the key size a different
> location.
> >>>
> >>> I have tried this patch (both v2 and v3) to connect with a Bluetooth
> >>> 2.0 device, it doesn't have any connection problem.
> >>> I suppose because in the original patch (d5bb334a8e17), there is no
> >>> check for the HCI_CONN_ENCRYPT flag.
> >>
> >> while that might be the case, I am still super careful. Especially also in
> >> conjunction with the email / patch from Alex trying to add just another
> >> encryption key size check. If we really need them or even both, we have to
> >> audit the whole code since I must have clearly missed something when
> >> adding the KNOB fix.
> >>
> Now I have to ask, are you running an upstream kernel with both commits
> above that address KNOB vulnerability?
> >>>
> >>> Actually no, I haven't heard of KNOB vulnerability before.
> >>> This patch is written for qualification purposes, specifically to pass
> >>> GAP/SEC/SEM/BI-05-C to BI-08-C.
> >>> However, it sounds like it could also prevent some KNOB vulnerability
> >>> as a bonus.
> >>
> >> That part worries me since there should be no gaps that allows an
> >> encryption key size downgrade if our side supports Read Encryption Key
> >> Size.
> >>
> >> We really
[PATCH] kernel: exit: fix a spacing coding style
Add some spaces before and after the operator.
Signed-off-by: jiahao
---
kernel/exit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 733e80f..a3c831c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -869,7 +869,7 @@ EXPORT_SYMBOL(complete_and_exit);
SYSCALL_DEFINE1(exit, int, error_code)
{
- do_exit((error_code&0xff)<<8);
+ do_exit((error_code & 0xff) << 8);
}
/*
--
2.7.4
Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
On Tue, 29 Sep 2020 02:17:19 +0100 Matthew Wilcox wrote:
> On Mon, Sep 28, 2020 at 06:03:07PM -0700, Andrew Morton wrote:
> > On Sat, 26 Sep 2020 22:39:19 +0100 "Matthew Wilcox (Oracle)"
> > wrote:
> >
> > > Here is a very rare race which leaks memory:
> >
> > Not worth a cc:stable?
>
> Yes, it probably should have been.
Have you a feeling for how often this occurs?
> I just assume the stablebot will
> pick up anything that has a Fixes: tag.
We asked them not to do that for mm/ patches. Crazy stuff was getting
backported.
> > >
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -4947,6 +4947,9 @@ void __free_pages(struct page *page, unsigned int
> > > order)
> > > {
> > > if (put_page_testzero(page))
> > > free_the_page(page, order);
> > > + else if (!PageHead(page))
> > > + while (order-- > 0)
> > > + free_the_page(page + (1 << order), order);
> >
> > Well that's weird and scary looking. `page' has non-zero refcount yet
> > we go and free random followon pages. Methinks it merits an
> > explanatory comment?
>
> Well, poot. I lost that comment in the shuffling of patches. In a
> different tree, I have:
>
> @@ -4943,10 +4943,19 @@ static inline void free_the_page(struct page *page,
> unsi
> gned int order)
> __free_pages_ok(page, order);
> }
>
> +/*
> + * If we free a non-compound allocation, another thread may have a
"non-compound, higher-order", I suggest?
> + * speculative reference to the first page. It has no way of knowing
> + * about the rest of the allocation, so we have to free all but the
> + * first page here.
> + */
> void __free_pages(struct page *page, unsigned int order)
> {
> if (put_page_testzero(page))
> free_the_page(page, order);
> + else if (!PageHead(page))
> + while (order-- > 0)
> + free_the_page(page + (1 << order), order);
> }
> EXPORT_SYMBOL(__free_pages);
>
>
> Although I'm now thinking of making that comment into kernel-doc and
> turning it into advice to the caller rather than an internal note to
> other mm developers.
hm. But what action could the caller take? The explanatory comment
seems OK to me.
Re: [PATCH v7 bpf-next 8/8] selftests/bpf: add test for bpf_seq_printf_btf helper
On Mon, Sep 28, 2020 at 4:36 AM Alan Maguire wrote:
>
> Add a test verifying iterating over tasks and displaying BTF
> representation of task_struct succeeds.
>
> Suggested-by: Alexei Starovoitov
> Signed-off-by: Alan Maguire
> ---
Hey Alan,
These selftests rely on having struct btf_ptr and BTF_F_COMPACT (and
other) flags to be present in vmlinux.h. While there is nothing wrong
with that per se, it does break selftests builds on older kernels,
because there struct btf_ptr isn't yet present in kernel:
progs/netif_receive_skb.c:131:21: error: use of undeclared identifier
'BTF_F_NONAME'
TEST_BTF(str, int, BTF_F_NONAME, "0", 0);
^
progs/netif_receive_skb.c:131:2: error: use of undeclared identifier
'BTF_F_COMPACT'; did you mean 'TT_COMPAT'?
TEST_BTF(str, int, BTF_F_NONAME, "0", 0);
^
progs/netif_receive_skb.c:50:28: note: expanded from macro 'TEST_BTF'
__u64 _hflags = _flags | BTF_F_COMPACT; \
^
/data/users/andriin/linux/tools/testing/selftests/bpf/tools/include/vmlinux.h:330:2:
note: 'TT_COMPAT' declared here
TT_COMPAT = 2,
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
progs/bpf_iter_task_btf.c:21:24: error: variable has incomplete type
'struct btf_ptr'
static struct btf_ptr ptr = { };
^
/data/users/andriin/linux/tools/testing/selftests/bpf/tools/include/bpf/bpf_helper_defs.h:33:8:
note: forward declaration of 'struct btf_ptr'
struct btf_ptr;
We actually do build the very latest selftests against old kernels
(4.9 and 5.5 at the moment) as part of libbpf CI, so it would be nice
to fix this problem and keep selftests compilable.
Do you mind following up with a change to define struct btf_ptr and
those BTF_F_xxx flags explicitly for selftests only, similarly to how
we do it for bpf_iter context structs? See progs/bpf_iter.h for
examples. Thanks.
> tools/testing/selftests/bpf/prog_tests/bpf_iter.c | 74
> ++
> .../selftests/bpf/progs/bpf_iter_task_btf.c| 50 +++
> 2 files changed, 124 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_btf.c
>
[...]
Re: [PATCH 6/8] usb: cdnsp: Device side header file for CDNSP driver
On 20-09-28 14:27:39, Pawel Laszczak wrote:
> Patch defines macros, registers and structures used by
> Device side driver.
>
> Because the size of main patch is very big, I’ve decided to create
> separate patch for gadget.h. It should simplify reviewing the code.
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/cdnsp/gadget.h | 1459
I have no seen there are folder cdnsp from previous patches.
Peter
> 1 file changed, 1459 insertions(+)
> create mode 100644 drivers/usb/cdnsp/gadget.h
>
> diff --git a/drivers/usb/cdnsp/gadget.h b/drivers/usb/cdnsp/gadget.h
> new file mode 100644
> index ..bfc4196c3b10
> --- /dev/null
> +++ b/drivers/usb/cdnsp/gadget.h
> @@ -0,0 +1,1459 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Cadence CDNSP DRD Driver.
> + *
> + * Copyright (C) 2020 Cadence.
> + *
> + * Author: Pawel Laszczak
> + *
> + * Code based on Linux XHCI driver.
> + * Origin: Copyright (C) 2008 Intel Corp.
> + */
> +#ifndef __LINUX_CDNSP_GADGET_H
> +#define __LINUX_CDNSP_GADGET_H
> +
> +#include
> +#include
> +#include
> +
> +/* Max number slots - only 1 is allowed. */
> +#define CDNSP_DEV_MAX_SLOTS 1
> +
> +#define CDNSP_EP0_SETUP_SIZE 512
> +
> +/*16 for in and 16 for out. */
> +#define CDNSP_ENDPOINTS_NUM 32
> +
> +/* Best Effort Service Latency. */
> +#define CDNSP_DEFAULT_BESL 0
> +
> +/* Device Controller command default timeout value in us */
> +#define CDNSP_CMD_TIMEOUT(15 * 1000)
> +
> +/* Up to 16 ms to halt an device controller */
> +#define CDNSP_MAX_HALT_USEC (16 * 1000)
> +
> +#define CDNSP_CTX_SIZE 2112
> +
> +/*
> + * Controller register interface.
> + */
> +
> +/**
> + * struct cdnsp_cap_regs - CDNSP Registers.
> + * @hc_capbase: Length of the capabilities register and controller
> + * version number
> + * @hcs_params1: HCSPARAMS1 - Structural Parameters 1
> + * @hcs_params2: HCSPARAMS2 - Structural Parameters 2
> + * @hcs_params3: HCSPARAMS3 - Structural Parameters 3
> + * @hcc_params: HCCPARAMS - Capability Parameters
> + * @db_off: DBOFF - Doorbell array offset
> + * @run_regs_off: RTSOFF - Runtime register space offset
> + * @hcc_params2: HCCPARAMS2 Capability Parameters 2,
> + */
> +struct cdnsp_cap_regs {
> + __le32 hc_capbase;
> + __le32 hcs_params1;
> + __le32 hcs_params2;
> + __le32 hcs_params3;
> + __le32 hcc_params;
> + __le32 db_off;
> + __le32 run_regs_off;
> + __le32 hcc_params2;
> + /* Reserved up to (CAPLENGTH - 0x1C) */
> +};
> +
> +/* hc_capbase bitmasks. */
> +/* bits 7:0 - how long is the Capabilities register. */
> +#define HC_LENGTH(p) (((p) >> 00) & GENMASK(7, 0))
> +/* bits 31:16*/
> +#define HC_VERSION(p)(((p) >> 16) & GENMASK(15, 1))
> +
> +/* HCSPARAMS1 - hcs_params1 - bitmasks */
> +/* bits 0:7, Max Device Endpoints */
> +#define HCS_ENDPOINTS_MASK GENMASK(7, 0)
> +#define HCS_ENDPOINTS(p) (((p) & HCS_ENDPOINTS_MASK) >> 0)
> +
> +/* HCCPARAMS offset from PCI base address */
> +#define HCC_PARAMS_OFFSET0x10
> +
> +/* HCCPARAMS - hcc_params - bitmasks */
> +/* true: device controller can use 64-bit address pointers. */
> +#define HCC_64BIT_ADDR(p)((p) & BIT(0))
> +/* true: device controller uses 64-byte Device Context structures. */
> +#define HCC_64BYTE_CONTEXT(p)((p) & BIT(2))
> +/* Max size for Primary Stream Arrays - 2^(n+1), where n is bits 12:15. */
> +#define HCC_MAX_PSA(p) p) >> 12) & 0xf) + 1)
> +/* Extended Capabilities pointer from PCI base. */
> +#define HCC_EXT_CAPS(p) (((p) & GENMASK(31, 16)) >> 16)
> +
> +#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
> +
> +/* db_off bitmask - bits 0:1 reserved. */
> +#define DBOFF_MASK GENMASK(31, 2)
> +
> +/* run_regs_off bitmask - bits 0:4 reserved. */
> +#define RTSOFF_MASK GENMASK(31, 5)
> +
> +/**
> + * struct cdnsp_op_regs - Device Controller Operational Registers.
> + * @command: USBCMD - Controller command register.
> + * @status: USBSTS - Controller status register.
> + * @page_size: This indicates the page size that the device controller
> supports.
> + * If bit n is set, the controller supports a page size of
> 2^(n+12),
> + * up to a 128MB page size. 4K is the minimum page size.
> + * @dnctrl: DNCTRL - Device notification control register.
> + * @cmd_ring: CRP - 64-bit Command Ring Pointer.
> + * @dcbaa_ptr: DCBAAP - 64-bit Device Context Base Address Array Pointer.
> + * @config_reg: CONFIG - Configure Register
> + * @port_reg_base: PORTSCn - base address for Port Status and Control
> + * Each port has a Port Status and Control register,
> + * followed by a Port Power Management Status and Control
> + * register, a Port Link Info register, and a reserved
> + * register.
> + */
> +struct cdnsp_op_regs {
> + __le32 command;
> + __le32 status;
> +
Re: [PATCH v4] kvm,x86: Exit to user space in case page fault error
On Mon, Jul 20, 2020 at 05:13:59PM -0400, Vivek Goyal wrote:
> ---
> arch/x86/include/asm/kvm_host.h | 2 ++
> arch/x86/kvm/mmu.h | 2 +-
> arch/x86/kvm/mmu/mmu.c | 2 +-
> arch/x86/kvm/x86.c | 54 +++--
> include/linux/kvm_types.h | 1 +
> 5 files changed, 56 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index be5363b21540..e6f8d3f1a377 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -137,6 +137,7 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t
> base_gfn, int level)
> #define KVM_NR_VAR_MTRR 8
>
> #define ASYNC_PF_PER_VCPU 64
> +#define ERROR_GFN_PER_VCPU 64
Aren't these two related? I.e. wouldn't it make sense to do:
#define ERROR_GFN_PER_VCPU ASYNC_PF_PER_VCPU
Or maybe even size error_gfns[] to ASYNC_PF_PER_VCPU?
>
> enum kvm_reg {
> VCPU_REGS_RAX = __VCPU_REGS_RAX,
> @@ -778,6 +779,7 @@ struct kvm_vcpu_arch {
> unsigned long nested_apf_token;
> bool delivery_as_pf_vmexit;
> bool pageready_pending;
> + gfn_t error_gfns[ERROR_GFN_PER_VCPU];
> } apf;
>
> /* OSVW MSRs (AMD only) */
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 444bb9c54548..d0a2a12c7bb6 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -60,7 +60,7 @@ void kvm_init_mmu(struct kvm_vcpu *vcpu, bool reset_roots);
> void kvm_init_shadow_mmu(struct kvm_vcpu *vcpu, u32 cr0, u32 cr4, u32 efer);
> void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, bool execonly,
>bool accessed_dirty, gpa_t new_eptp);
> -bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu);
> +bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu, gfn_t gfn);
> int kvm_handle_page_fault(struct kvm_vcpu *vcpu, u64 error_code,
> u64 fault_address, char *insn, int insn_len);
>
...
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 88c593f83b28..c1f5094d6e53 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -263,6 +263,13 @@ static inline void kvm_async_pf_hash_reset(struct
> kvm_vcpu *vcpu)
> vcpu->arch.apf.gfns[i] = ~0;
> }
>
> +static inline void kvm_error_gfn_hash_reset(struct kvm_vcpu *vcpu)
> +{
> + int i;
Need a newline.
> + for (i = 0; i < ERROR_GFN_PER_VCPU; i++)
> + vcpu->arch.apf.error_gfns[i] = GFN_INVALID;
> +}
> +
> static void kvm_on_user_return(struct user_return_notifier *urn)
> {
> unsigned slot;
> @@ -9484,6 +9491,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
> vcpu->arch.pat = MSR_IA32_CR_PAT_DEFAULT;
>
> kvm_async_pf_hash_reset(vcpu);
> + kvm_error_gfn_hash_reset(vcpu);
> kvm_pmu_init(vcpu);
>
> vcpu->arch.pending_external_vector = -1;
> @@ -9608,6 +9616,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool
> init_event)
>
> kvm_clear_async_pf_completion_queue(vcpu);
> kvm_async_pf_hash_reset(vcpu);
> + kvm_error_gfn_hash_reset(vcpu);
> vcpu->arch.apf.halted = false;
>
> if (kvm_mpx_supported()) {
> @@ -10369,6 +10378,36 @@ void kvm_set_rflags(struct kvm_vcpu *vcpu, unsigned
> long rflags)
> }
> EXPORT_SYMBOL_GPL(kvm_set_rflags);
>
> +static inline u32 kvm_error_gfn_hash_fn(gfn_t gfn)
> +{
> + BUILD_BUG_ON(!is_power_of_2(ERROR_GFN_PER_VCPU));
> +
> + return hash_32(gfn & 0x, order_base_2(ERROR_GFN_PER_VCPU));
> +}
> +
> +static void kvm_add_error_gfn(struct kvm_vcpu *vcpu, gfn_t gfn)
> +{
> + u32 key = kvm_error_gfn_hash_fn(gfn);
> +
> + /*
> + * Overwrite the previous gfn. This is just a hint to do
> + * sync page fault.
> + */
> + vcpu->arch.apf.error_gfns[key] = gfn;
> +}
> +
> +/* Returns true if gfn was found in hash table, false otherwise */
> +static bool kvm_find_and_remove_error_gfn(struct kvm_vcpu *vcpu, gfn_t gfn)
> +{
> + u32 key = kvm_error_gfn_hash_fn(gfn);
Mostly out of curiosity, do we really need a hash? E.g. could we get away
with an array of 4 values? 2 values? Just wondering if we can avoid 64*8
bytes per CPU.
One thought would be to use the index to handle the case of no error gfns so
that the size of the array doesn't affect lookup for the common case, e.g.
...
u8 error_gfn_head;
gfn_t error_gfns[ERROR_GFN_PER_VCPU];
} apf;
if (vcpu->arch.apf.error_gfn_head == 0xff)
return false;
for (i = 0; i < vcpu->arch.apf.error_gfn_head; i++) {
if (vcpu->arch.apf.error_gfns[i] == gfn) {
vcpu->arch.apf.error_gfns[i] = INVALID_GFN;
return true;
}
}
return true;
Or you could even avoid INVALID_GFN altogether by compacting the array on
removal. The VM is probably dead anyways, burning a few cycles to clean
Seien Sie glücklich 2.000.000,00 Euro
Herzlichen Glückwunsch, Ihre E-Mail wurde zufällig ausgewählt. Ihre E-Mail hat € 2.000.000,00 gewonnen. Kontaktieren Sie die E-Mail unten für weitere Informationen und Anspruch auf das Geld. cwjacksonjun...@gmail.com Herzlichen Glückwunsch noch einmal. ___ Congratulations, your email was randomly selected. Your email won € 2,000,000.00 euros. contact the email below for more information and claim of the money. cwjacksonjun...@gmail.com Congratulations once again.
Re: [PATCH 5/8] usb: cdns3: Changed type of gadget_dev in cdns structure
On 20-09-28 14:27:38, Pawel Laszczak wrote:
> Patch changes the type for gadget_dev pointer in cdns structure from
> pointer to cdns3_device structure to void pointer.
> This filed is in reusable code and after this change it will be used to
> point to both cdns3_device or cdnsp_device objects.
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/cdns3/core.h | 4 ++--
> drivers/usb/cdns3/gadget.c | 6 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
> index 0c6e14683b36..267923904a37 100644
> --- a/drivers/usb/cdns3/core.h
> +++ b/drivers/usb/cdns3/core.h
> @@ -55,7 +55,7 @@ struct cdns_role_driver {
> * @roles: array of supported roles for this controller
> * @role: current role
> * @host_dev: the child host device pointer for cdns core
> - * @gadget_dev: the child gadget device pointer for cdns3 core
> + * @gadget_dev: the child gadget device pointer
> * @usb2_phy: pointer to USB2 PHY
> * @usb3_phy: pointer to USB3 PHY
> * @mutex: the mutex for concurrent code at driver
> @@ -87,7 +87,7 @@ struct cdns {
> struct cdns_role_driver *roles[USB_ROLE_DEVICE + 1];
> enum usb_role role;
> struct platform_device *host_dev;
> - struct cdns3_device *gadget_dev;
> + void*gadget_dev;
> struct phy *usb2_phy;
> struct phy *usb3_phy;
> /* mutext used in workqueue*/
> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> index 26f68182e65e..f9cbc84bbfb8 100644
> --- a/drivers/usb/cdns3/gadget.c
> +++ b/drivers/usb/cdns3/gadget.c
> @@ -3177,7 +3177,9 @@ static int __cdns3_gadget_init(struct cdns *cdns)
> static int cdns3_gadget_suspend(struct cdns *cdns, bool do_wakeup)
> {
> struct cdns3_device *priv_dev = cdns->gadget_dev;
> + unsigned long flags;
>
> + spin_lock_irqsave(_dev->lock, flags);
unrelated changes?
> cdns3_disconnect_gadget(priv_dev);
>
> priv_dev->gadget.speed = USB_SPEED_UNKNOWN;
> @@ -3186,6 +3188,7 @@ static int cdns3_gadget_suspend(struct cdns *cdns, bool
> do_wakeup)
>
> /* disable interrupt for device */
> writel(0, _dev->regs->usb_ien);
> + spin_unlock_irqrestore(_dev->lock, flags);
>
> return 0;
> }
> @@ -3193,11 +3196,14 @@ static int cdns3_gadget_suspend(struct cdns *cdns,
> bool do_wakeup)
> static int cdns3_gadget_resume(struct cdns *cdns, bool hibernated)
> {
> struct cdns3_device *priv_dev = cdns->gadget_dev;
> + unsigned long flags;
>
> if (!priv_dev->gadget_driver)
> return 0;
>
> + spin_lock_irqsave(_dev->lock, flags);
ditto
> cdns3_gadget_config(priv_dev);
> + spin_unlock_irqrestore(_dev->lock, flags);
>
> return 0;
> }
> --
> 2.17.1
>
--
Thanks,
Peter Chen
Re: [PATCH 7/8] usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver
On Mon, 2020-09-28 at 14:27 +0200, Pawel Laszczak wrote:
> This patch introduces the main part of Cadence USBSSP DRD driver
> to Linux kernel.
> To reduce the patch size a little bit, the header file gadget.h was
> intentionally added as separate patch.
>
> The Cadence USBSSP DRD Controller is a highly configurable IP Core which
> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
> Host Only (XHCI)configurations.
>
> The current driver has been validated with FPGA platform. We have
> support for PCIe bus, which is used on FPGA prototyping.
>
> The host side of USBSS DRD controller is compliant with XHCI.
> The architecture for device side is almost the same as for host side,
> and most of the XHCI specification can be used to understand how
> this controller operates.
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/Kconfig |1 +
> drivers/usb/Makefile |1 +
> drivers/usb/cdns3/core.c | 19 +-
> drivers/usb/cdns3/drd.c | 28 +
> drivers/usb/cdns3/drd.h |2 +
> drivers/usb/cdns3/gadget-export.h | 18 +-
> drivers/usb/cdns3/host-export.h |4 +-
> drivers/usb/cdnsp/Kconfig | 40 +
> drivers/usb/cdnsp/Makefile|7 +
> drivers/usb/cdnsp/cdnsp-pci.c | 247 +++
> drivers/usb/cdnsp/ep0.c | 480 ++
> drivers/usb/cdnsp/gadget.c| 1946
> drivers/usb/cdnsp/gadget.h| 139 ++
> drivers/usb/cdnsp/mem.c | 1312
> drivers/usb/cdnsp/ring.c | 2363 +
> 15 files changed, 6600 insertions(+), 7 deletions(-)
> create mode 100644 drivers/usb/cdnsp/Kconfig
> create mode 100644 drivers/usb/cdnsp/Makefile
> create mode 100644 drivers/usb/cdnsp/cdnsp-pci.c
> create mode 100644 drivers/usb/cdnsp/ep0.c
> create mode 100644 drivers/usb/cdnsp/gadget.c
> create mode 100644 drivers/usb/cdnsp/mem.c
> create mode 100644 drivers/usb/cdnsp/ring.c
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 26475b409b53..555c4a4cb465 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -112,6 +112,7 @@ source "drivers/usb/usbip/Kconfig"
> endif
>
> source "drivers/usb/cdns3/Kconfig"
> +source "drivers/usb/cdnsp/Kconfig"
>
> source "drivers/usb/mtu3/Kconfig"
>
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index 1c1c1d659394..84727f7a4b92 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_USB_DWC2) += dwc2/
> obj-$(CONFIG_USB_ISP1760)+= isp1760/
>
> obj-$(CONFIG_USB_CDNS3) += cdns3/
> +obj-$(CONFIG_USB_CDNSP) += cdnsp/
>
> obj-$(CONFIG_USB_MON)+= mon/
> obj-$(CONFIG_USB_MTU3) += mtu3/
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index 2af99294beaa..560783092d8a 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -138,7 +138,14 @@ static int cdns_core_init_role(struct cdns *cdns)
> dr_mode = best_dr_mode;
>
> if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
> - ret = cdns_host_init(cdns);
> + if ((cdns->version == CDNSP_CONTROLLER_V2 &&
> + IS_ENABLED(CONFIG_USB_CDNSP_HOST)) ||
> + (cdns->version < CDNSP_CONTROLLER_V2 &&
> + IS_ENABLED(CONFIG_USB_CDNS3_HOST)))
> + ret = cdns_host_init(cdns);
> + else
> + ret = -ENXIO;
> +
> if (ret) {
> dev_err(dev, "Host initialization failed with %d\n",
> ret);
> @@ -147,7 +154,15 @@ static int cdns_core_init_role(struct cdns *cdns)
> }
>
> if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_PERIPHERAL) {
> - ret = cdns3_gadget_init(cdns);
> + if (cdns->version == CDNSP_CONTROLLER_V2 &&
> + IS_ENABLED(CONFIG_USB_CDNSP_GADGET))
> + ret = cdnsp_gadget_init(cdns);
> + else if (cdns->version < CDNSP_CONTROLLER_V2 &&
> + IS_ENABLED(CONFIG_USB_CDNS3_GADGET))
> + ret = cdns3_gadget_init(cdns);
> + else
> + ret = -ENXIO;
> +
> if (ret) {
> dev_err(dev, "Device initialization failed with %d\n",
> ret);
> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
> index 7feb622972da..3c732e19c61c 100644
> --- a/drivers/usb/cdns3/drd.c
> +++ b/drivers/usb/cdns3/drd.c
> @@ -90,6 +90,32 @@ int cdns_get_vbus(struct cdns *cdns)
> return vbus;
> }
>
> +void cdns_clear_vbus(struct cdns *cdns)
> +{
> + u32 reg;
> +
> + if (cdns->version != CDNSP_CONTROLLER_V2)
> + return;
> +
> + reg = readl(>otg_cdnsp_regs->override);
> + reg |= OVERRIDE_SESS_VLD_SEL;
> +
[PATCH v4] Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support
This patch add support for WCN6855 i.e. patch and nvm download
support.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e600 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I: If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 65 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 65 Ivl=1ms
Signed-off-by: Rocky Liao
---
drivers/bluetooth/btusb.c | 66 +++
1 file changed, 53 insertions(+), 13 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 9f294b941943..1005b6e8ff74 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -59,6 +59,7 @@ static struct usb_driver btusb_driver;
#define BTUSB_MEDIATEK 0x20
#define BTUSB_WIDEBAND_SPEECH 0x40
#define BTUSB_VALID_LE_STATES 0x80
+#define BTUSB_QCA_WCN6855 0x100
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
@@ -291,6 +292,10 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3501), .driver_info = BTUSB_QCA_ROME |
BTUSB_WIDEBAND_SPEECH },
+ /* QCA WCN6855 chipset */
+ { USB_DEVICE(0x0cf3, 0xe600), .driver_info = BTUSB_QCA_WCN6855 |
+BTUSB_WIDEBAND_SPEECH },
+
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = BTUSB_BCM92035 },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = BTUSB_WRONG_SCO_MTU },
@@ -3409,6 +3414,27 @@ static int btusb_set_bdaddr_ath3012(struct hci_dev *hdev,
return 0;
}
+static int btusb_set_bdaddr_wcn6855(struct hci_dev *hdev,
+ const bdaddr_t *bdaddr)
+{
+ struct sk_buff *skb;
+ u8 buf[6];
+ long ret;
+
+ memcpy(buf, bdaddr, sizeof(bdaddr_t));
+
+ skb = __hci_cmd_sync_ev(hdev, 0xfc14, sizeof(buf), buf,
+ HCI_EV_CMD_COMPLETE, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ ret = PTR_ERR(skb);
+ bt_dev_err(hdev, "Change address command failed (%ld)", ret);
+ return ret;
+ }
+ kfree_skb(skb);
+
+ return 0;
+}
+
#define QCA_DFU_PACKET_LEN 4096
#define QCA_GET_TARGET_VERSION 0x09
@@ -3428,7 +3454,8 @@ struct qca_version {
} __packed;
struct qca_rampatch_version {
- __le16 rom_version;
+ __le16 rom_version_high;
+ __le16 rom_version_low;
__le16 patch_version;
} __packed;
@@ -3440,12 +3467,14 @@ struct qca_device_info {
};
static const struct qca_device_info qca_devices_table[] = {
- { 0x0100, 20, 4, 10 }, /* Rome 1.0 */
- { 0x0101, 20, 4, 10 }, /* Rome 1.1 */
- { 0x0200, 28, 4, 18 }, /* Rome 2.0 */
- { 0x0201, 28, 4, 18 }, /* Rome 2.1 */
- { 0x0300, 28, 4, 18 }, /* Rome 3.0 */
- { 0x0302, 28, 4, 18 }, /* Rome 3.2 */
+ { 0x0100, 20, 4, 8 }, /* Rome 1.0 */
+ { 0x0101, 20, 4, 8 }, /* Rome 1.1 */
+ { 0x0200, 28, 4, 16 }, /* Rome 2.0 */
+ { 0x0201, 28, 4, 16 }, /* Rome 2.1 */
+ { 0x0300, 28, 4, 16 }, /* Rome 3.0 */
+ { 0x0302, 28, 4, 16 }, /* Rome 3.2 */
+ { 0x00130100, 40, 4, 16 }, /* WCN6855 1.0 */
+ { 0x00130200, 40, 4, 16 }, /* WCN6855 2.0 */
};
static int btusb_qca_send_vendor_req(struct usb_device *udev, u8 request,
@@ -3547,8 +3576,8 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev
*hdev,
{
struct
Re: [PATCH v3 1/5] fpga: dfl: rename the bus type "dfl" to "fpga-dfl"
Hi Xu, On Tue, Sep 29, 2020 at 09:23:23AM +0800, Xu Yilun wrote: > Hi moritz: > > On Sun, Sep 27, 2020 at 04:36:47PM +0800, Xu Yilun wrote: > > Hi Greg, > > > > On Sun, Sep 27, 2020 at 09:54:01AM +0200, Greg KH wrote: > > > On Sun, Sep 27, 2020 at 03:37:54PM +0800, Xu Yilun wrote: > > > > Hi Greg, > > > > > > > > On Sun, Sep 27, 2020 at 07:51:08AM +0200, Greg KH wrote: > > > > > On Sat, Sep 26, 2020 at 12:22:19PM -0700, Moritz Fischer wrote: > > > > > > Hi Greg, > > > > > > > > > > > > On Sat, Sep 26, 2020 at 08:09:13AM +0200, Greg KH wrote: > > > > > > > On Sat, Sep 26, 2020 at 10:23:46AM +0800, Xu Yilun wrote: > > > > > > > > Hi greg, > > > > > > > > > > > > > > > > About the bus naming, I summarized some questions we've > > > > > > > > discussed to check > > > > > > > > with you. See inline. > > > > > > > > > > > > > > > > On Thu, Sep 24, 2020 at 10:27:00AM -0700, Moritz Fischer wrote: > > > > > > > > > Hi Xu, > > > > > > > > > > > > > > > > > > On Fri, Sep 25, 2020 at 12:59:57AM +0800, Xu Yilun wrote: > > > > > > > > > > Now the DFL device drivers could be made as independent > > > > > > > > > > modules and put > > > > > > > > > > in different subsystems according to their functionalities. > > > > > > > > > > So the name > > > > > > > > > > should be descriptive and unique in the whole kernel. > > > > > > > > > > > > > > > > > > > > The patch changes the naming of dfl bus related structures, > > > > > > > > > > functions, > > > > > > > > > > APIs and documentations. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Xu Yilun > > > > > > > > > > --- > > > > > > > > > > Documentation/ABI/testing/sysfs-bus-dfl | 15 -- > > > > > > > > > > Documentation/ABI/testing/sysfs-bus-fpga-dfl | 15 ++ > > > > > > > > > > MAINTAINERS | 2 +- > > > > > > > > > > drivers/fpga/dfl.c | 254 > > > > > > > > > > ++- > > > > > > > > > > drivers/fpga/dfl.h | 77 > > > > > > > > > > 5 files changed, 184 insertions(+), 179 deletions(-) > > > > > > > > > > delete mode 100644 Documentation/ABI/testing/sysfs-bus-dfl > > > > > > > > > > create mode 100644 > > > > > > > > > > Documentation/ABI/testing/sysfs-bus-fpga-dfl > > > > > > > > > > > > > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-dfl > > > > > > > > > > b/Documentation/ABI/testing/sysfs-bus-dfl > > > > > > > > > > deleted file mode 100644 > > > > > > > > > > index 23543be..000 > > > > > > > > > > --- a/Documentation/ABI/testing/sysfs-bus-dfl > > > > > > > > > > +++ /dev/null > > > > > > > > > > @@ -1,15 +0,0 @@ > > > > > > > > > > -What: /sys/bus/dfl/devices/dfl_dev.X/type > > > > > > > > > > -Date: Aug 2020 > > > > > > > > > > -KernelVersion: 5.10 > > > > > > > > > > -Contact: Xu Yilun > > > > > > > > > > -Description: Read-only. It returns type of DFL FIU > > > > > > > > > > of the device. Now DFL > > > > > > > > > > - supports 2 FIU types, 0 for FME, 1 for PORT. > > > > > > > > > > - Format: 0x%x > > > > > > > > > > - > > > > > > > > > > -What: > > > > > > > > > > /sys/bus/dfl/devices/dfl_dev.X/feature_id > > > > > > > > > > -Date: Aug 2020 > > > > > > > > > > -KernelVersion: 5.10 > > > > > > > > > > -Contact: Xu Yilun > > > > > > > > > > -Description: Read-only. It returns feature > > > > > > > > > > identifier local to its DFL FIU > > > > > > > > > > - type. > > > > > > > > > > - Format: 0x%x > > > > > > > > > > > > > > > > > > You're changing userland facing ABI. I think that's something > > > > > > > > > to avoid, > > > > > > > > > please check with Greg on the rules since this hasn't been in > > > > > > > > > a release yet. > > > > > > > > > > > > > > > > > > > > > > > > > I'm going to change the name of bus stuff for other subsystems, > > > > > > > > to be > > > > > > > > aligned, I also consider change the bus_type.name and dfl > > > > > > > > dev_name. But > > > > > > > > it will cause the changing of user ABIs. No user case for these > > > > > > > > user ABI > > > > > > > > now cause they are just queued, is it good I change them? > > > > > > > > > > > > > > Why change the user name here? No need for that, right? Unless > > > > > > > you > > > > > > > really want to, and think that no one will notice. If so, fine, > > > > > > > change > > > > > > > them :) > > > > > > > > > > > > Let's leave it as is -- An FPGA is one possible implementation and > > > > > > as for > > > > > > other buses, you wouldn't call it fpga-usb or usb-fpga just because > > > > > > the > > > > > > USB bus is implemented in an FPGA if it behaves like a normal USB > > > > > > bus. > > > > > > Having an ASIC based DFL bus show up under dfl-fpga / fpga-dfl in > > > > > > sysfs > > > > > > would be super confusing. > > > > I thought we have consensus that "dfl" could be used out
Re: [PATCH V3 6/8] mm: and drivers core: Convert hugetlb_report_node_meminfo to sysfs_emit
On Mon, Sep 28, 2020 at 05:53:07PM -0700, Joe Perches wrote: > On Sat, 2020-09-19 at 08:22 +0200, Greg Kroah-Hartman wrote: > > On Wed, Sep 16, 2020 at 01:40:43PM -0700, Joe Perches wrote: > > > Convert the unbound sprintf in hugetlb_report_node_meminfo to use > > > sysfs_emit_at so that no possible overrun of a PAGE_SIZE buf can occur. > [] > > I'll take a look at it on Monday... > > (noting that you didn't say _which_ Monday...) True :) > Greg are you going to take this or should I ask someone else? > > The first sysfs_emit addition patch was first posted about a month > ago without much change. > > I think it'd be useful to get it into -next before 5.9 is released. I'll dig into this today...
Re: linux-next: build failure after merge of the vfs tree
On Fri, Sep 25, 2020 at 02:38:20PM +0100, Al Viro wrote:
> On Fri, Sep 25, 2020 at 10:01:28PM +1000, Stephen Rothwell wrote:
> > $ x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
> > $ x86_64-linux-gnu-ld --version
> > GNU ld (GNU Binutils for Debian) 2.35
> >
> > and the gcc plugins don't get built for the allnoconfig builds.
>
> > I reverted my Revert commit after I finished linux-next today and built
> > the x86_64 allnoconfig verion of lib/iov_iter.s:
> >
> > $ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"'
> > lib/iov_iter.s
> > # 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
> > cmp $140737488351232,%rdx; sbb %rcx,%rcx; #, uaddr, mask
>
> Wait a sec...
> static inline unsigned long array_index_mask_nospec(unsigned long index,
> unsigned long size)
> {
> unsigned long mask;
>
> asm volatile ("cmp %1,%2; sbb %0,%0;"
> :"=r" (mask)
> :"g"(size),"r" (index)
> :"cc");
> return mask;
> }
>
> used with large constant size will blow up - "g" is wrong, since cmp allows
> 64bit arguments to be register or memory ones; immediates can't go past
> 32bit.
>
> Looks like on the configs where it builds we end up with not seeing it's
> a constant...
>
> Josh, any ideas? We could, of course, make it "r"(size), but that would
> be unpleasant in all existing callers...
Sorry, I've been traveling. I'd just vote for making it "r".
array_index_nospec() is always called after a usercopy. I don't think
anyone will notice the extra mov, for the cases where it would be
propagated as an immediate. And the argument *is* an unsigned long
after all.
Stephen, can you confirm this fixes it?
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index d158ea1fa250..69045ac62f58 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -40,7 +40,7 @@ static inline unsigned long array_index_mask_nospec(unsigned
long index,
asm volatile ("cmp %1,%2; sbb %0,%0;"
:"=r" (mask)
- :"g"(size),"r" (index)
+ :"r"(size), "r"(index)
:"cc");
return mask;
}
Re: [PATCH 3/5] iommu/tegra-smmu: Use iommu_fwspec in .probe_/.attach_device()
... >> As I mentioned in another reply, I think tegra_smmu_find() should be all >> you need in this case. > > This function is used by .probe_device() where its dev pointer is > an SMMU client. IIUC, tegra_smmu_find() needs np pointer of "mc". > For a PCI device that doesn't have a DT node with iommus property, > not sure how we can use tegra_smmu_find(). Perhaps you could get np from struct pci_dev.bus?
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Lorenzo, Thanks a lot for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2020年9月28日 17:39 > To: Z.q. Hou > Cc: Rob Herring ; linux-kernel@vger.kernel.org; PCI > ; Bjorn Helgaas ; > Gustavo Pimentel ; Michael Walle > ; Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Thu, Sep 24, 2020 at 04:24:47AM +, Z.q. Hou wrote: > > Hi Rob, > > > > Thanks a lot for your comments! > > > > > -Original Message- > > > From: Rob Herring > > > Sent: 2020年9月18日 23:28 > > > To: Z.q. Hou > > > Cc: linux-kernel@vger.kernel.org; PCI ; > > > Lorenzo Pieralisi ; Bjorn Helgaas > > > ; Gustavo Pimentel > > > ; Michael Walle > ; > > > Ard Biesheuvel > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > > > dw_child_pcie_ops > > > > > > On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou > wrote: > > > > > > > > Hi Rob, > > > > > > > > Thanks a lot for your comments! > > > > > > > > > -Original Message- > > > > > From: Rob Herring > > > > > Sent: 2020年9月17日 4:29 > > > > > To: Z.q. Hou > > > > > Cc: linux-kernel@vger.kernel.org; PCI > > > > > ; Lorenzo Pieralisi > > > > > ; Bjorn Helgaas > > > > > ; Gustavo Pimentel > > > > > ; Michael Walle > > > ; > > > > > Ard Biesheuvel > > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > > > > > dw_child_pcie_ops > > > > > > > > > > On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou > > > > > > > > wrote: > > > > > > > > > > > > From: Hou Zhiqiang > > > > > > > > > > > > On NXP Layerscape platforms, it results in SError in the > > > > > > enumeration of the PCIe controller, which is not connecting > > > > > > with an Endpoint device. And it doesn't make sense to > > > > > > enumerate the Endpoints when the PCIe link is down. So this > > > > > > patch added the link up check to avoid to fire configuration > transactions on link down bus. > > > > > > > > > > Michael reported the same issue as well. > > > > > > > > > > What happens if the link goes down between the check and the > access? > > > > > > > > This patch cannot cover this case, and will get the SError. > > > > But I think it makes sense to avoid firing transactions on link down > > > > bus. > > > > > > That's impossible to do without a race even in h/w. > > > > Agree. > > > > > > > > > > It's a racy check. I'd like to find an alternative solution. > > > > > It's even worse if Layerscape is used in ECAM mode. I looked at > > > > > the EDK2 setup for layerscape[1] and it looks like root ports > > > > > are just skipped if link > > > is down. > > > > > Maybe a link down just never happens once up, but if so, then we > > > > > only need to check it once and fail probe. > > > > > > > > Many customers connect the FPGA Endpoint, which may establish PCIe > > > > link after the PCIe enumeration and then rescan the PCIe bus, so I > > > > think it should not exit the probe of root port even if there is > > > > not link up > > > during enumeration. > > > > > > That's a good reason. I want to unify the behavior here as it varies > > > per platform currently and wasn't sure which way to go. > > > > > > > > > > > I've dug into this a bit more and am curious about the > > > > > PCIE_ABSERR register setting which is set to: > > > > > > > > > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of > > > > > non-posted request */ > > > > > > > > > > It seems to me this is not what we want at least for config > > > > > accesses, but commit 84d897d6993 where this was added seems to > > > > > say otherwise. Is it not possible to configure the response per access > type? > > > > > > > > Thanks a lot for your investigation! > > > > The story is like this: Some customers worry about these silent > > > > error (DWC PCIe IP won't forward the error of outbound non-post > > > > request by default), so we were pushed to enable the error > > > > forwarding to AXI in the commit > > > > 84d897d6993 as you saw. But it cannot differentiate the config > > > > transactions from the MEM_rd, except the Vendor ID access, which > > > > is controlled by a separate bit and it was set to not forward > > > > error of access > > > of Vendor ID. > > > > So we think it's okay to enable the error forwarding, the SError > > > > should not occur, because after the enumeration it won't access > > > > the > > > non-existent functions. > > > > > > We've rejected upstream support for platforms aborting on config > > > accesses[1]. I think there's clear consensus that aborting is the > > > wrong behavior. > > > > > > Do MEM_wr errors get forwarded? Seems like that would be enough. > > > Also, wouldn't page faults catch most OOB accesses anyways? You need > > > things page aligned anyways with an IOMMU and doing userspace access > > > or guest assignment. > > > > Yes, errors of MEM_wr can be forwarded. > > > > > > > > Here's another idea, how about only enabling forwarding errors if > > > the link is up? If really would need to be
Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote: > I don’t personally care that much about EMODPE but, you could probably > get the point across with something like: > > SGX’s EPCM permission bits do not obviate the need to enforce these > rules in the PTEs because enclaves can freely modify the EPCM > permissions using EMODPE. > > IOW, EMODPE is not really special here; rather, EMODPE’s existence > demonstrates that EADD / EEXTEND are not special. So I did "disagree and commit" with this one. I'm not actually diagreeing on anything what Dave wrote, on the contrary it is an understandable high level description. I just thought that it would not hurt to remark that the ISA contains such peculiarities as EMODPE. I did only very rudimentary clean up for the text (e.g. fix the ioctl name, add shortt summary and not much else). Does not make sense to waste more time to this. I'll move on to implement the missing boot time patching for the vDSO so that we get the next version out. " mm: Add 'mprotect' hook to struct vm_operations_struct Background == 1. SGX enclave pages are populated with data by copying data to them from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). 2. We want to be able to restrict those normal memory data sources. For instance, before copying data to an executable enclave page, we might ensure that the source is executable. 3. Enclave page permissions are dynamic just like normal permissions and can be adjusted at runtime with mprotect() (along with a corresponding special instruction inside the enclave). 4. The original data source may have have long since vanished at the time when enclave page permission are established (mmap() or mprotect()). Solution The solution is to force enclaves creators to declare their intent up front to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). This intent can me immediately compared to the source data mapping (and rejected if necessary). It is also stashed off and then later compared with enclave PTEs to ensure that any future mmap()/mprotect() operations performed by the enclave creator or the enclave itself are consistent with the earlier declared permissions. Essentially, this means that whenever the kernel is asked to change an enclave PTE, it needs to ensure the change is consistent with that stashed intent. There is an existing vm_ops->mmap() hook which allows SGX to do that for mmap(). However, there is no ->mprotect() hook. Add a vm_ops->mprotect() hook so that mprotect() operations which are inconsistent with any page's stashed intent can be rejected by the driver. Implications However, there is currently no implementation of the intent checks at the time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES). That means that the intent argument (SGX_PROT_*) is currently unused. " /Jarkko
Re: [PATCH v2 1/3] ARM: tegra: Add device-tree for Ouya
26.09.2020 16:47, Dmitry Osipenko пишет:
> 26.09.2020 05:01, Peter Geis пишет:
> ...
+ pmic: pmic@2d {
+ compatible = "ti,tps65911";
+ reg = <0x2d>;
+
+ interrupts = ;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ ti,system-power-controller;
>>>
>>> Are the ti,sleep-keep-ck32k and other properties not needed for Ouya
>>> like they are needed for Nexus 7?
>>
>> Ouya is wall powered, so ultra low power isn't terribly necessary.
>> Also with LP1 and LP0 not working, it doesn't make much sense to
>> implement this yet.
>
> The keep-ck32 is not about power saving. If PMC is running off PMIC's
> oscillator during LP1 suspend, then this should be one of the reasons
> why LP1 doesn't work for you.
>
I missed that you set nvidia,suspend-mode to LP2, so perhaps should be
good as-is for now.
arch/powerpc/kexec/core.c:246:29: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb0155a09b0224a7147cb07a4ce6034c8d29667f
commit: 793b08e2efff3ec020c5c5861d00ed394fcdd488 powerpc/kexec: Move kexec
files into a dedicated subdir.
date: 10 months ago
config: powerpc-randconfig-s032-20200929 (attached as .config)
compiler: powerpc-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.2-201-g24bdaac6-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=793b08e2efff3ec020c5c5861d00ed394fcdd488
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 793b08e2efff3ec020c5c5861d00ed394fcdd488
# 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=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> arch/powerpc/kexec/core.c:246:29: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned long long static
>> [addressable] [toplevel] [usertype] crashk_base @@ got restricted __be32
>> [usertype] @@
arch/powerpc/kexec/core.c:246:29: sparse: expected unsigned long long
static [addressable] [toplevel] [usertype] crashk_base
arch/powerpc/kexec/core.c:246:29: sparse: got restricted __be32
[usertype]
>> arch/powerpc/kexec/core.c:248:29: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned long long static
>> [addressable] [toplevel] [usertype] crashk_size @@ got restricted __be32
>> [usertype] @@
arch/powerpc/kexec/core.c:248:29: sparse: expected unsigned long long
static [addressable] [toplevel] [usertype] crashk_size
arch/powerpc/kexec/core.c:248:29: sparse: got restricted __be32
[usertype]
arch/powerpc/kexec/core.c:256:19: sparse: sparse: incorrect type in
assignment (different base types) @@ expected unsigned long long static
[addressable] [toplevel] mem_limit @@ got restricted __be32 [usertype] @@
arch/powerpc/kexec/core.c:256:19: sparse: expected unsigned long long
static [addressable] [toplevel] mem_limit
arch/powerpc/kexec/core.c:256:19: sparse: got restricted __be32
[usertype]
>> arch/powerpc/kexec/core.c:272:20: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned long long static
>> [addressable] [toplevel] [usertype] kernel_end @@ got restricted __be32
>> [usertype] @@
arch/powerpc/kexec/core.c:272:20: sparse: expected unsigned long long
static [addressable] [toplevel] [usertype] kernel_end
arch/powerpc/kexec/core.c:272:20: sparse: got restricted __be32
[usertype]
vim +246 arch/powerpc/kexec/core.c
ea961a828fe7250 arch/powerpc/kernel/machine_kexec.c Anton Blanchard
2014-01-22 235
6f29c3298b18216 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 236 static void __init export_crashk_values(struct device_node
*node)
6f29c3298b18216 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 237 {
6f29c3298b18216 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 238/* There might be existing crash kernel properties, but
we can't
6f29c3298b18216 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 239 * be sure what's in them, so remove them. */
925e2d1ded80fcc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh
2016-04-28 240of_remove_property(node, of_find_property(node,
925e2d1ded80fcc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh
2016-04-28 241"linux,crashkernel-base", NULL));
925e2d1ded80fcc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh
2016-04-28 242of_remove_property(node, of_find_property(node,
925e2d1ded80fcc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh
2016-04-28 243"linux,crashkernel-size", NULL));
6f29c3298b18216 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 244
6f29c3298b18216 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 245if (crashk_res.start != 0) {
ea961a828fe7250 arch/powerpc/kernel/machine_kexec.c Anton Blanchard
2014-01-22 @246crashk_base = cpu_to_be_ulong(crashk_res.start),
79d1c712958f943 arch/powerpc/kernel/machine_kexec.c Nathan Fontenot
2012-10-02 247of_add_property(node, _base_prop);
ea961a828fe7250 arch/powerpc/kernel/machine_kexec.c Anton Blanchard
2014-01-22 @248
Re: [RFC PATCH 3/3] KVM: x86: Use KVM_BUG/KVM_BUG_ON to handle bugs that are fatal to the VM
On Fri, Sep 25, 2020 at 11:06:10PM +0200, Paolo Bonzini wrote: > On 25/09/20 19:12, Sean Christopherson wrote: > >> Do we actually want to prevent *all* ioctls? E.g. when 'vm bugged' > >> condition is triggered userspace may want to extract some information to > >> assist debugging but even things like KVM_GET_[S]REGS will just return > >> -EIO. I'm not sure it is generally safe to enable *everything* (except > >> for KVM_RUN which should definitely be forbidden) so maybe your approach > >> is preferable. > > > > The answer to this probably depends on the answer to the first question of > > when it's appropriate to use KVM_BUG(). E.g. if we limit usage to fatal or > > dangrous cases, then blocking all ioctls() is probably the right thing do > > do. > > I think usage should be limited to dangerous cases, basically WARN_ON > level. However I agree with Vitaly that KVM_GET_* should be allowed. Makes sense. On the topic of feedback from Vitaly, while dredging through my mailbox I rediscovered his suggestion of kvm->kvm_internal_bug (or maybe just kvm->internal_bug) instead of kvm->vm_bugged[*]. Like past me, I like the "internal" variants better. [*] https://lkml.kernel.org/r/20190930153358.gd14...@linux.intel.com > The other question is whether to return -EIO or KVM_EXIT_INTERNAL_ERROR. > The latter is more likely to be handled already by userspace. And probably less confusing for unsuspecting users. E.g. -EIO is most likely to be interpreted as "I screwed up", whereas KVM_EXIT_INTERNAL_ERROR will correctly be read as "KVM screwed up".
Re: [PATCH v38 16/24] x86/sgx: Add a page reclaimer
On Mon, Sep 28, 2020 at 06:14:39PM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > > + spin_lock(_active_page_list_lock);
> > > > + for (i = 0; i < SGX_NR_TO_SCAN; i++) {
> > > > + if (list_empty(_active_page_list))
> > >
> > > Isn't it enough to do this once, i.e., not in the loop? You're holding
> > > sgx_active_page_list_lock...
>
> Argh, I missed this until I looked at Jarkko's updated tree.
>
> The reason for checking list_empty() on every iteration is that the loop is
> greedy, i.e. it tries to grab and reclaim up to 16 (SGX_NR_TO_SCAN) EPC pages
> at a time.
>
> > I think that would make sense. Distantly analogous to the EINIT
> > discussion. Too complex code for yet to be known problem workloads I'd
> > say.
>
> No. Please no.
I added this comment in the beginning of the sgx_reclaim_pages() based
on your response:
/*
* Take a fixed number of pages from the head of the active page pool and
* reclaim them to the enclave's private shmem files. Skip the pages, which have
* been accessed since the last scan. Move those pages to the tail of active
* page pool so that the pages get scanned in LRU like fashion.
*
* Batch process a chunk of pages (at the moment 16) in order to degrade amount
* of IPI's and ETRACK's potentially required. sgx_encl_ewb() does degrade a bit
* among the HW threads with three stage EWB pipeline (EWB, ETRACK + EWB and IPI
* + EWB) but not sufficiently. Reclaiming one page at a time would also be
* problematic as it would increase the lock contention too much, which would
* halt forward progress.
*/
And reverted reclaimer patch as it was. Do you have anything in mind
that I should add or modify in it?
/Jarkko
Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
On Mon, Sep 28, 2020 at 06:03:07PM -0700, Andrew Morton wrote: > Well that's weird and scary looking. `page' has non-zero refcount yet > we go and free random followon pages. Methinks it merits an > explanatory comment? Here's some kernel-doc. Opinions? /** * __free_pages - Free pages allocated with alloc_pages(). * @page: The page pointer returned from alloc_pages(). * @order: The order of the allocation. * * This function differs from put_page() in that it can free multi-page * allocations that were not allocated with %__GFP_COMP. This function * does not check that the @order passed in matches that of the * allocation, so it is possible to leak memory. Freeing more memory than * was allocated will probably be warned about by other debugging checks. * * It is only safe to use the page reference count to determine when * to free an allocation if you use %__GFP_COMP (in which case, you may * as well use put_page() to free the page). Another thread may have a * speculative reference to the first page, but it has no way of knowing * about the rest of the allocation, so we have to free all but the * first page here. * * Context: May be called in interrupt context but not NMI context. */
Re: [PATCH 2/8] usb: cdns3: Split core.c into cdns3-plat and core.c file
On 20-09-28 14:27:35, Pawel Laszczak wrote:
> Patch splits file core.c into core.c containing the common reusable code
> and cnd3-plat.c containing device platform specific code. These changes
cdns3-plat.c
Pawel, at 5.10-rc1, there are some cdns3 driver updates at Felipe's
next tree, you may create patches based on that to avoid rebase effects in
future.
Peter
> are required to make possible reuse DRD part of CDNS3 driver in CDNSP
> driver.
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/cdns3/Makefile | 2 +-
> drivers/usb/cdns3/cdns3-plat.c | 209 +
> drivers/usb/cdns3/core.c | 181 +++-
> drivers/usb/cdns3/core.h | 8 +-
> 4 files changed, 234 insertions(+), 166 deletions(-)
> create mode 100644 drivers/usb/cdns3/cdns3-plat.c
>
> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
> index d47e341a6f39..a1fe9612053a 100644
> --- a/drivers/usb/cdns3/Makefile
> +++ b/drivers/usb/cdns3/Makefile
> @@ -2,7 +2,7 @@
> # define_trace.h needs to know how to find our header
> CFLAGS_trace.o := -I$(src)
>
> -cdns3-y := core.o drd.o
> +cdns3-y := cdns3-plat.o core.o drd.o
>
> obj-$(CONFIG_USB_CDNS3) += cdns3.o
> cdns3-$(CONFIG_USB_CDNS3_GADGET) += gadget.o ep0.o
> diff --git a/drivers/usb/cdns3/cdns3-plat.c b/drivers/usb/cdns3/cdns3-plat.c
> new file mode 100644
> index ..f35e9dca30fe
> --- /dev/null
> +++ b/drivers/usb/cdns3/cdns3-plat.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cadence USBSS DRD Driver.
> + *
> + * Copyright (C) 2018-2020 Cadence.
> + * Copyright (C) 2017-2018 NXP
> + * Copyright (C) 2019 Texas Instrumentsq
> + *
> + *
> + * Author: Peter Chen
> + * Pawel Laszczak
> + * Roger Quadros
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +
> +/**
> + * cdns3_plat_probe - probe for cdns3 core device
> + * @pdev: Pointer to cdns3 core platform device
> + *
> + * Returns 0 on success otherwise negative errno
> + */
> +static int cdns3_plat_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct resource *res;
> + struct cdns3 *cdns;
> + void __iomem *regs;
> + int ret;
> +
> + cdns = devm_kzalloc(dev, sizeof(*cdns), GFP_KERNEL);
> + if (!cdns)
> + return -ENOMEM;
> +
> + cdns->dev = dev;
> +
> + platform_set_drvdata(pdev, cdns);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "host");
> + if (!res) {
> + dev_err(dev, "missing host IRQ\n");
> + return -ENODEV;
> + }
> +
> + cdns->xhci_res[0] = *res;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "xhci");
> + if (!res) {
> + dev_err(dev, "couldn't get xhci resource\n");
> + return -ENXIO;
> + }
> +
> + cdns->xhci_res[1] = *res;
> +
> + cdns->dev_irq = platform_get_irq_byname(pdev, "peripheral");
> + if (cdns->dev_irq == -EPROBE_DEFER)
> + return cdns->dev_irq;
> +
> + if (cdns->dev_irq < 0)
> + dev_err(dev, "couldn't get peripheral irq\n");
> +
> + regs = devm_platform_ioremap_resource_byname(pdev, "dev");
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> + cdns->dev_regs = regs;
> +
> + cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
> + if (cdns->otg_irq == -EPROBE_DEFER)
> + return cdns->otg_irq;
> +
> + if (cdns->otg_irq < 0) {
> + dev_err(dev, "couldn't get otg irq\n");
> + return cdns->otg_irq;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
> + if (!res) {
> + dev_err(dev, "couldn't get otg resource\n");
> + return -ENXIO;
> + }
> +
> + cdns->otg_res = *res;
> +
> + cdns->usb2_phy = devm_phy_optional_get(dev, "cdns3,usb2-phy");
> + if (IS_ERR(cdns->usb2_phy))
> + return PTR_ERR(cdns->usb2_phy);
> +
> + ret = phy_init(cdns->usb2_phy);
> + if (ret)
> + return ret;
> +
> + cdns->usb3_phy = devm_phy_optional_get(dev, "cdns3,usb3-phy");
> + if (IS_ERR(cdns->usb3_phy))
> + return PTR_ERR(cdns->usb3_phy);
> +
> + ret = phy_init(cdns->usb3_phy);
> + if (ret)
> + goto err_phy3_init;
> +
> + ret = phy_power_on(cdns->usb2_phy);
> + if (ret)
> + goto err_phy2_power_on;
> +
> + ret = phy_power_on(cdns->usb3_phy);
> + if (ret)
> + goto err_phy3_power_on;
> +
> + ret = cdns3_init(cdns);
> + if (ret)
> + goto err_cdns_init;
> +
> + device_set_wakeup_capable(dev, true);
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> +
> + /*
> + * The controller needs less time between bus and
Re: [PATCHv4] perf kvm: add kvm-stat for arm64
On (20/09/17 19:02), Sergey Senozhatsky wrote: > Add support for perf kvm stat on arm64 platform. > > Example: > # perf kvm stat report > > Analyze events for all VMs, all VCPUs: > > VM-EXITSamples Samples% Time%Min TimeMax Time > Avg time > >DABT_LOW 66186798.91%40.45% 2.19us 3364.65us > 6.24us ( +- 0.34% ) > IRQ 4598 0.69%57.44% 2.89us 3397.59us > 1276.27us ( +- 1.61% ) > WFx 1475 0.22% 1.71% 2.22us 3388.63us > 118.31us ( +- 8.69% ) >IABT_LOW 1018 0.15% 0.38% 2.22us 2742.07us > 38.29us ( +- 12.55% ) > SYS64180 0.03% 0.01% 2.07us112.91us > 6.57us ( +- 14.95% ) > HVC64 17 0.00% 0.01% 2.19us322.35us > 42.95us ( +- 58.98% ) > > Total Samples:669155, Total events handled time:10216387.86us. > > Signed-off-by: Sergey Senozhatsky > Reviewed-by: Leo Yan > Tested-by: Leo Yan Arnaldo, any opinion on this? -ss
[PATCH v2] tools lib traceevent: Hide non API functions
There are internal library functions, which are not decalred as a static.
They are used inside the library from different files. Hide them from
the library users, as they are not part of the API.
These functions are made hidden and are renamed without the prefix "tep_":
tep_free_plugin_paths
tep_peek_char
tep_buffer_init
tep_get_input_buf_ptr
tep_get_input_buf
tep_read_token
tep_free_token
tep_free_event
tep_free_format_field
Reported-by: Ben Hutchings
Signed-off-by: Tzvetomir Stoyanov (VMware)
---
v1 of the patch is here:
https://lore.kernel.org/r/20200924070609.100771-2-tz.stoya...@gmail.com
v2 changes:
- Removed leading underscores from the names of newly hidden internal
functions.
tools/lib/traceevent/event-parse-api.c | 8 +-
tools/lib/traceevent/event-parse-local.h | 24 --
tools/lib/traceevent/event-parse.c | 96 ++--
tools/lib/traceevent/event-parse.h | 8 --
tools/lib/traceevent/event-plugin.c | 2 +-
tools/lib/traceevent/parse-filter.c | 23 +++---
6 files changed, 56 insertions(+), 105 deletions(-)
diff --git a/tools/lib/traceevent/event-parse-api.c
b/tools/lib/traceevent/event-parse-api.c
index 4faf52a65791..f8361e45d446 100644
--- a/tools/lib/traceevent/event-parse-api.c
+++ b/tools/lib/traceevent/event-parse-api.c
@@ -92,7 +92,7 @@ bool tep_test_flag(struct tep_handle *tep, enum tep_flag flag)
return false;
}
-unsigned short tep_data2host2(struct tep_handle *tep, unsigned short data)
+__hidden unsigned short data2host2(struct tep_handle *tep, unsigned short data)
{
unsigned short swap;
@@ -105,7 +105,7 @@ unsigned short tep_data2host2(struct tep_handle *tep,
unsigned short data)
return swap;
}
-unsigned int tep_data2host4(struct tep_handle *tep, unsigned int data)
+__hidden unsigned int data2host4(struct tep_handle *tep, unsigned int data)
{
unsigned int swap;
@@ -120,8 +120,8 @@ unsigned int tep_data2host4(struct tep_handle *tep,
unsigned int data)
return swap;
}
-unsigned long long
-tep_data2host8(struct tep_handle *tep, unsigned long long data)
+__hidden unsigned long long
+data2host8(struct tep_handle *tep, unsigned long long data)
{
unsigned long long swap;
diff --git a/tools/lib/traceevent/event-parse-local.h
b/tools/lib/traceevent/event-parse-local.h
index d805a920af6f..fd4bbcfbb849 100644
--- a/tools/lib/traceevent/event-parse-local.h
+++ b/tools/lib/traceevent/event-parse-local.h
@@ -15,6 +15,8 @@ struct event_handler;
struct func_resolver;
struct tep_plugins_dir;
+#define __hidden __attribute__((visibility ("hidden")))
+
struct tep_handle {
int ref_count;
@@ -102,12 +104,20 @@ struct tep_print_parse {
struct tep_print_arg*len_as_arg;
};
-void tep_free_event(struct tep_event *event);
-void tep_free_format_field(struct tep_format_field *field);
-void tep_free_plugin_paths(struct tep_handle *tep);
-
-unsigned short tep_data2host2(struct tep_handle *tep, unsigned short data);
-unsigned int tep_data2host4(struct tep_handle *tep, unsigned int data);
-unsigned long long tep_data2host8(struct tep_handle *tep, unsigned long long
data);
+void free_tep_event(struct tep_event *event);
+void free_tep_format_field(struct tep_format_field *field);
+void free_tep_plugin_paths(struct tep_handle *tep);
+
+unsigned short data2host2(struct tep_handle *tep, unsigned short data);
+unsigned int data2host4(struct tep_handle *tep, unsigned int data);
+unsigned long long data2host8(struct tep_handle *tep, unsigned long long data);
+
+/* access to the internal parser */
+int peek_char(void);
+void init_input_buf(const char *buf, unsigned long long size);
+unsigned long long get_input_buf_ptr(void);
+const char *get_input_buf(void);
+enum tep_event_type read_token(char **tok);
+void free_token(char *tok);
#endif /* _PARSE_EVENTS_INT_H */
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 5acc18b32606..032ecb22cde9 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -54,19 +54,19 @@ static int show_warning = 1;
warning(fmt, ##__VA_ARGS__);\
} while (0)
-static void init_input_buf(const char *buf, unsigned long long size)
+__hidden void init_input_buf(const char *buf, unsigned long long size)
{
input_buf = buf;
input_buf_siz = size;
input_buf_ptr = 0;
}
-const char *tep_get_input_buf(void)
+__hidden const char *get_input_buf(void)
{
return input_buf;
}
-unsigned long long tep_get_input_buf_ptr(void)
+__hidden unsigned long long get_input_buf_ptr(void)
{
return input_buf_ptr;
}
@@ -100,26 +100,13 @@ process_defined_func(struct trace_seq *s, void *data, int
size,
static void free_func_handle(struct tep_function_handler *func);
-/**
- * tep_buffer_init - init buffer for parsing
- * @buf: buffer to parse
- * @size: the size of the buffer
- *
- * For use
Re: [PATCH v6 1/3] remoteproc: Move coredump configuration to sysfs
On Mon 28 Sep 17:17 CDT 2020, Rishabh Bhatnagar wrote:
> Move coredump configuration from debugfs to sysfs.This will
> allow usage of this configuration feature in production
> devices where access to debugfs might be limited.
>
> Signed-off-by: Rishabh Bhatnagar
I like the end result of this series now Rishabh, but...
> ---
> Documentation/ABI/testing/sysfs-class-remoteproc | 24 +++
> drivers/remoteproc/remoteproc_debugfs.c | 90
>
> drivers/remoteproc/remoteproc_sysfs.c| 64 +
> 3 files changed, 88 insertions(+), 90 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc
> b/Documentation/ABI/testing/sysfs-class-remoteproc
> index 36094fb..f6c44fa 100644
> --- a/Documentation/ABI/testing/sysfs-class-remoteproc
> +++ b/Documentation/ABI/testing/sysfs-class-remoteproc
> @@ -58,3 +58,27 @@ Description: Remote processor name
> Reports the name of the remote processor. This can be used by
> userspace in exactly identifying a remote processor and ease
> up the usage in modifying the 'firmware' or 'state' files.
> +
> +What:/sys/class/remoteproc/.../coredump
> +Date:July 2020
> +Contact: Bjorn Andersson , Ohad Ben-Cohen
>
> +Description: Remote processor coredump configuration
> +
> + Reports the coredump configuration of the remote processor,
> + which will be one of:
> +
> + "default"
...can you please make this "enabled" already here, so that patch 3
doesn't touch the definition of the sysfs. That way we don't introduce a
new sysfs attribute and immediately change it.
Please keep the remainder (rename of defines etc) in patch 3 as is - I
just want the string exposed to userspace to be consistent here.
(Or if you find the end result, you can move patch 3 before this change
in the series)
Regards,
Bjorn
> + "inline"
> + "disabled"
> +
> + "default" means when the remote processor's coredump is
> + collected it will be copied to a separate buffer and that
> + buffer is exposed to userspace.
> +
> + "inline" means when the remote processor's coredump is
> + collected userspace will directly read from the remote
> + processor's device memory. Extra buffer will not be used to
> + copy the dump. Also recovery process will not proceed until
> + all data is read by usersapce.
> +
> + "disabled" means no dump will be collected.
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c
> b/drivers/remoteproc/remoteproc_debugfs.c
> index 2e3b3e2..732770e 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -28,94 +28,6 @@
> static struct dentry *rproc_dbg;
>
> /*
> - * A coredump-configuration-to-string lookup table, for exposing a
> - * human readable configuration via debugfs. Always keep in sync with
> - * enum rproc_coredump_mechanism
> - */
> -static const char * const rproc_coredump_str[] = {
> - [RPROC_COREDUMP_DEFAULT]= "default",
> - [RPROC_COREDUMP_INLINE] = "inline",
> - [RPROC_COREDUMP_DISABLED] = "disabled",
> -};
> -
> -/* Expose the current coredump configuration via debugfs */
> -static ssize_t rproc_coredump_read(struct file *filp, char __user *userbuf,
> -size_t count, loff_t *ppos)
> -{
> - struct rproc *rproc = filp->private_data;
> - char buf[20];
> - int len;
> -
> - len = scnprintf(buf, sizeof(buf), "%s\n",
> - rproc_coredump_str[rproc->dump_conf]);
> -
> - return simple_read_from_buffer(userbuf, count, ppos, buf, len);
> -}
> -
> -/*
> - * By writing to the 'coredump' debugfs entry, we control the behavior of the
> - * coredump mechanism dynamically. The default value of this entry is
> "default".
> - *
> - * The 'coredump' debugfs entry supports these commands:
> - *
> - * default: This is the default coredump mechanism. When the remoteproc
> - * crashes the entire coredump will be copied to a separate buffer
> - * and exposed to userspace.
> - *
> - * inline: The coredump will not be copied to a separate buffer and the
> - * recovery process will have to wait until data is read by
> - * userspace. But this avoid usage of extra memory.
> - *
> - * disabled: This will disable coredump. Recovery will proceed without
> - * collecting any dump.
> - */
> -static ssize_t rproc_coredump_write(struct file *filp,
> - const char __user *user_buf, size_t count,
> - loff_t *ppos)
> -{
> - struct rproc *rproc = filp->private_data;
> - int ret, err = 0;
> - char buf[20];
> -
> - if (count > sizeof(buf))
> - return -EINVAL;
> -
> - ret =
[PATCH WIP 5/6] media: vidtv: Move s302m specific fields into encoder context
From: Daniel W. S. Almeida
A few fields used only by the tone generator in the s302m encoder
are stored in struct vidtv_encoder. Move them into
struct vidtv_s302m_ctx instead. While we are at it: fix a
checkpatch warning for long lines.
Signed-off-by: Daniel W. S. Almeida
---
.../media/test-drivers/vidtv/vidtv_encoder.h | 3 --
.../media/test-drivers/vidtv/vidtv_s302m.c| 30 +++
.../media/test-drivers/vidtv/vidtv_s302m.h| 3 ++
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_encoder.h
b/drivers/media/test-drivers/vidtv/vidtv_encoder.h
index 65d81daef4c3..f742d566fbcb 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_encoder.h
+++ b/drivers/media/test-drivers/vidtv/vidtv_encoder.h
@@ -131,9 +131,6 @@ struct vidtv_encoder {
u32 encoder_buf_offset;
u64 sample_count;
- int last_duration;
- int note_offset;
- enum musical_notes last_tone;
struct vidtv_access_unit *access_units;
diff --git a/drivers/media/test-drivers/vidtv/vidtv_s302m.c
b/drivers/media/test-drivers/vidtv/vidtv_s302m.c
index 6e5e72ce90d0..f7afbda6335d 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_s302m.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_s302m.c
@@ -233,36 +233,38 @@ static u16 vidtv_s302m_get_sample(struct vidtv_encoder *e)
{
u16 sample;
int pos;
+ struct vidtv_s302m_ctx *ctx = e->ctx;
if (!e->src_buf) {
/*
* Simple tone generator: play the tones at the
* beethoven_5th_symphony array.
*/
- if (e->last_duration <= 0) {
+ if (ctx->last_duration <= 0) {
if (e->src_buf_offset >=
ARRAY_SIZE(beethoven_5th_symphony))
e->src_buf_offset = 0;
- e->last_tone =
beethoven_5th_symphony[e->src_buf_offset].note;
- e->last_duration =
beethoven_5th_symphony[e->src_buf_offset].duration * S302M_SAMPLING_RATE_HZ /
COMPASS / 5;
+ ctx->last_tone =
beethoven_5th_symphony[e->src_buf_offset].note;
+ ctx->last_duration =
beethoven_5th_symphony[e->src_buf_offset].duration *
+S302M_SAMPLING_RATE_HZ / COMPASS /
5;
e->src_buf_offset++;
- e->note_offset = 0;
+ ctx->note_offset = 0;
} else {
- e->last_duration--;
+ ctx->last_duration--;
}
/* Handle silent */
- if (!e->last_tone) {
+ if (!ctx->last_tone) {
e->src_buf_offset = 0;
return 0x8000;
}
- pos = (2 * PI * e->note_offset * e->last_tone /
S302M_SAMPLING_RATE_HZ);
+ pos = (2 * PI * ctx->note_offset * ctx->last_tone /
S302M_SAMPLING_RATE_HZ);
if (pos == 360)
- e->note_offset = 0;
+ ctx->note_offset = 0;
else
- e->note_offset++;
+ ctx->note_offset++;
return (fixp_sin32(pos % (2 * PI)) >> 16) + 0x8000;
}
@@ -445,6 +447,10 @@ struct vidtv_encoder
{
struct vidtv_encoder *e;
u32 priv_sz = sizeof(struct vidtv_s302m_ctx);
+ struct vidtv_s302m_ctx *ctx = kzalloc(priv_sz, GFP_KERNEL);
+
+ if (!ctx)
+ return NULL;
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e)
@@ -460,16 +466,14 @@ struct vidtv_encoder
e->encoder_buf_offset = 0;
e->sample_count = 0;
- e->last_duration = 0;
e->src_buf = (args.src_buf) ? args.src_buf : NULL;
e->src_buf_sz = (args.src_buf) ? args.src_buf_sz : 0;
e->src_buf_offset = 0;
e->is_video_encoder = false;
- e->ctx = kzalloc(priv_sz, GFP_KERNEL);
- if (!e->ctx)
- return NULL;
+ e->ctx = ctx;
+ ctx->last_duration = 0;
e->encode = vidtv_s302m_encode;
e->clear = vidtv_s302m_clear;
diff --git a/drivers/media/test-drivers/vidtv/vidtv_s302m.h
b/drivers/media/test-drivers/vidtv/vidtv_s302m.h
index eafe457e761d..a0101734e758 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_s302m.h
+++ b/drivers/media/test-drivers/vidtv/vidtv_s302m.h
@@ -38,6 +38,9 @@ struct vidtv_s302m_ctx {
struct vidtv_encoder *enc;
u32 frame_index;
u32 au_count;
+ int last_duration;
+ int note_offset;
+ enum musical_notes last_tone;
};
/**
--
2.28.0
[PATCH WIP 4/6] media: vidtv: psi: extract descriptor chaining code into a helper
From: Daniel W. S. Almeida
The code to append a descriptor to the end of a chain is repeated
throughout the psi generator code. Extract it into its own helper
function to avoid cluttering.
Signed-off-by: Daniel W. S. Almeida
---
drivers/media/test-drivers/vidtv/vidtv_psi.c | 49 ++--
1 file changed, 15 insertions(+), 34 deletions(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.c
b/drivers/media/test-drivers/vidtv/vidtv_psi.c
index e331fc7d8eef..2cf103057b19 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_psi.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_psi.c
@@ -313,6 +313,16 @@ static u32 table_section_crc32_write_into(struct
crc32_write_args args)
return nbytes;
}
+static void vidtv_psi_desc_chain(struct vidtv_psi_desc *head, struct
vidtv_psi_desc *desc)
+{
+ if (head) {
+ while (head->next)
+ head = head->next;
+
+ head->next = desc;
+ }
+}
+
struct vidtv_psi_desc_service *vidtv_psi_service_desc_init(struct
vidtv_psi_desc *head,
enum service_type
service_type,
char *service_name,
@@ -346,12 +356,7 @@ struct vidtv_psi_desc_service
*vidtv_psi_service_desc_init(struct vidtv_psi_desc
if (provider_name && provider_name_len)
desc->provider_name = kstrdup(provider_name, GFP_KERNEL);
- if (head) {
- while (head->next)
- head = head->next;
-
- head->next = (struct vidtv_psi_desc *)desc;
- }
+ vidtv_psi_desc_chain(head, (struct vidtv_psi_desc *)desc);
return desc;
}
@@ -379,13 +384,7 @@ struct vidtv_psi_desc_registration
additional_ident_info,
additional_info_len);
- if (head) {
- while (head->next)
- head = head->next;
-
- head->next = (struct vidtv_psi_desc *)desc;
- }
-
+ vidtv_psi_desc_chain(head, (struct vidtv_psi_desc *)desc);
return desc;
}
@@ -404,13 +403,7 @@ struct vidtv_psi_desc_network_name
if (network_name && network_name_len)
desc->network_name = kstrdup(network_name, GFP_KERNEL);
- if (head) {
- while (head->next)
- head = head->next;
-
- head->next = (struct vidtv_psi_desc *)desc;
- }
-
+ vidtv_psi_desc_chain(head, (struct vidtv_psi_desc *)desc);
return desc;
}
@@ -448,13 +441,7 @@ struct vidtv_psi_desc_service_list
desc->length = length;
desc->service_list = head_e;
- if (head) {
- while (head->next)
- head = head->next;
-
- head->next = (struct vidtv_psi_desc *)desc;
- }
-
+ vidtv_psi_desc_chain(head, (struct vidtv_psi_desc *)desc);
return desc;
}
@@ -493,13 +480,7 @@ struct vidtv_psi_desc_short_event
if (text && text_len)
desc->text = kstrdup(text, GFP_KERNEL);
- if (head) {
- while (head->next)
- head = head->next;
-
- head->next = (struct vidtv_psi_desc *)desc;
- }
-
+ vidtv_psi_desc_chain(head, (struct vidtv_psi_desc *)desc);
return desc;
}
--
2.28.0
[PATCH WIP 3/6] media: vidtv: psi: Implement an Event Information Table (EIT)
From: Daniel W. S. Almeida
Implement an Event Information Table (EIT) as per EN 300 468
5.2.4.
The EIT provides information in chronological order regarding
the events contained within each service.
For now only present event information is supported.
Signed-off-by: Daniel W. S. Almeida
---
.../driver-api/media/drivers/vidtv.rst| 8 +-
.../media/test-drivers/vidtv/vidtv_channel.c | 73 +++-
.../media/test-drivers/vidtv/vidtv_channel.h | 3 +
drivers/media/test-drivers/vidtv/vidtv_mux.c | 14 +
drivers/media/test-drivers/vidtv/vidtv_mux.h | 2 +
drivers/media/test-drivers/vidtv/vidtv_psi.c | 315 +-
drivers/media/test-drivers/vidtv/vidtv_psi.h | 121 ++-
7 files changed, 527 insertions(+), 9 deletions(-)
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst
b/Documentation/driver-api/media/drivers/vidtv.rst
index 2d7ddf676b13..38c49a3c11a7 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -149,11 +149,11 @@ vidtv_psi.[ch]
Because the generator is implemented in a separate file, it can be
reused elsewhere in the media subsystem.
- Currently vidtv supports working with 4 PSI tables: PAT, PMT,
- SDT and NIT.
+ Currently vidtv supports working with 5 PSI tables: PAT, PMT,
+ SDT, NIT and EIT.
The specification for PAT and PMT can be found in *ISO 13818-1:
- Systems*, while the specification for the SDT, NIT can be found in *ETSI
+ Systems*, while the specification for the SDT, NIT, EIT can be found in
*ETSI
EN 300 468: Specification for Service Information (SI) in DVB
systems*.
@@ -197,6 +197,8 @@ vidtv_channel.[ch]
#. Their programs will be concatenated to populate the PAT
+ #. Their events will be concatenated to populate the EIT
+
#. For each program in the PAT, a PMT section will be created
#. The PMT section for a channel will be assigned its streams.
diff --git a/drivers/media/test-drivers/vidtv/vidtv_channel.c
b/drivers/media/test-drivers/vidtv/vidtv_channel.c
index 6137a2b43420..daf41df0bd66 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c
@@ -9,6 +9,7 @@
* When vidtv boots, it will create some hardcoded channels.
* Their services will be concatenated to populate the SDT.
* Their programs will be concatenated to populate the PAT
+ * Their events will be concatenated to populate the EIT
* For each program in the PAT, a PMT section will be created
* The PMT section for a channel will be assigned its streams.
* Every stream will have its corresponding encoder polled to produce TS
packets
@@ -58,6 +59,10 @@ struct vidtv_channel
const __be32 s302m_fid =
cpu_to_be32(VIDTV_S302M_FORMAT_IDENTIFIER);
char *name = ENCODING_ISO8859_15 "Beethoven";
char *provider = ENCODING_ISO8859_15 "LinuxTV.org";
+ char *iso_language_code = ENCODING_ISO8859_15 "eng";
+ char *event_name = ENCODING_ISO8859_15 "Beethoven Music";
+ char *event_text = ENCODING_ISO8859_15 "Beethoven's 5th Symphony";
+ const u16 s302m_beethoven_event_id = 1;
struct vidtv_channel *s302m;
struct vidtv_s302m_encoder_init_args encoder_args = {};
@@ -70,7 +75,7 @@ struct vidtv_channel
if (!s302m->name)
goto free_s302m;
- s302m->service = vidtv_psi_sdt_service_init(NULL, s302m_service_id);
+ s302m->service = vidtv_psi_sdt_service_init(NULL, s302m_service_id,
false, true);
if (!s302m->service)
goto free_name;
@@ -112,6 +117,13 @@ struct vidtv_channel
if (!s302m->encoders)
goto free_streams;
+ s302m->events = vidtv_psi_eit_event_init(NULL,
s302m_beethoven_event_id);
+ s302m->events->descriptor = (struct vidtv_psi_desc *)
+ vidtv_psi_short_event_desc_init(NULL,
+
iso_language_code,
+ event_name,
+ event_text);
+
if (head) {
while (head->next)
head = head->next;
@@ -135,6 +147,48 @@ struct vidtv_channel
return NULL;
}
+static struct vidtv_psi_table_eit_event
+*vidtv_channel_eit_event_cat_into_new(struct vidtv_mux *m)
+{
+ /* Concatenate the events */
+ const struct vidtv_channel *cur_chnl = m->channels;
+
+ struct vidtv_psi_table_eit_event *curr = NULL;
+ struct vidtv_psi_table_eit_event *head = NULL;
+ struct vidtv_psi_table_eit_event *tail = NULL;
+
+ struct vidtv_psi_desc *desc = NULL;
+ u16 event_id;
+
+ if (!cur_chnl)
+ return NULL;
+
+ while (cur_chnl) {
+ curr = cur_chnl->events;
+
+
[PATCH WIP 6/6] media: vidtv: psi: fix missing assignments in while loops
From: Daniel W. S. Almeida
Some variables were only assigned once but were used in while
loops as if they had been updated at every iteration. Fix this.
Signed-off-by: Daniel W. S. Almeida
---
drivers/media/test-drivers/vidtv/vidtv_psi.c | 22 +---
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.c
b/drivers/media/test-drivers/vidtv/vidtv_psi.c
index 2cf103057b19..ddbffea4c353 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_psi.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_psi.c
@@ -1191,9 +1191,7 @@ u32 vidtv_psi_pmt_write_into(struct
vidtv_psi_pmt_write_args args)
struct vidtv_psi_desc *table_descriptor = args.pmt->descriptor;
struct vidtv_psi_table_pmt_stream *stream = args.pmt->stream;
- struct vidtv_psi_desc *stream_descriptor = (stream) ?
-
args.pmt->stream->descriptor :
- NULL;
+ struct vidtv_psi_desc *stream_descriptor;
struct header_write_args h_args = {};
struct psi_write_args psi_args = {};
@@ -1253,6 +1251,8 @@ u32 vidtv_psi_pmt_write_into(struct
vidtv_psi_pmt_write_args args)
nbytes += vidtv_psi_ts_psi_write_into(psi_args);
+ stream_descriptor = stream->descriptor;
+
while (stream_descriptor) {
/* write the stream descriptors, if any */
d_args.dest_buf = args.buf;
@@ -1343,9 +1343,7 @@ u32 vidtv_psi_sdt_write_into(struct
vidtv_psi_sdt_write_args args)
u32 crc = INITIAL_CRC;
struct vidtv_psi_table_sdt_service *service = args.sdt->service;
- struct vidtv_psi_desc *service_desc = (args.sdt->service) ?
- args.sdt->service->descriptor :
- NULL;
+ struct vidtv_psi_desc *service_desc;
struct header_write_args h_args = {};
struct psi_write_args psi_args = {};
@@ -1392,6 +1390,8 @@ u32 vidtv_psi_sdt_write_into(struct
vidtv_psi_sdt_write_args args)
nbytes += vidtv_psi_ts_psi_write_into(psi_args);
+ service_desc = service->descriptor;
+
while (service_desc) {
/* copy the service descriptors, if any */
d_args.dest_buf = args.buf;
@@ -1639,9 +1639,7 @@ u32 vidtv_psi_nit_write_into(struct
vidtv_psi_nit_write_args args)
struct vidtv_psi_desc *table_descriptor = args.nit->descriptor;
struct vidtv_psi_table_transport *transport = args.nit->transport;
- struct vidtv_psi_desc *transport_descriptor = (transport) ?
-
args.nit->transport->descriptor :
- NULL;
+ struct vidtv_psi_desc *transport_descriptor;
struct header_write_args h_args = {};
struct psi_write_args psi_args = {};
@@ -1709,6 +1707,8 @@ u32 vidtv_psi_nit_write_into(struct
vidtv_psi_nit_write_args args)
nbytes += vidtv_psi_ts_psi_write_into(psi_args);
+ transport_descriptor = transport->descriptor;
+
while (transport_descriptor) {
/* write the transport descriptors, if any */
d_args.dest_buf = args.buf;
@@ -1846,9 +1846,7 @@ u32 vidtv_psi_eit_write_into(struct
vidtv_psi_eit_write_args args)
u32 crc = INITIAL_CRC;
struct vidtv_psi_table_eit_event *event = args.eit->event;
- struct vidtv_psi_desc *event_descriptor = (args.eit->event) ?
- args.eit->event->descriptor :
- NULL;
+ struct vidtv_psi_desc *event_descriptor;
struct header_write_args h_args = {};
struct psi_write_args psi_args = {};
--
2.28.0
[PATCH WIP 2/6] media: vidtv: psi: add a Network Information Table (NIT)
From: Daniel W. S. Almeida
Add a Network Information Table (NIT) as specified in ETSI EN 300 468.
This table conveys information relating to the physical organization of
the multiplexes carried via a given network and the characteristics of
the network itself.
It is conveyed in the output of vidtv as packets with TS PID of 0x0010
Signed-off-by: Daniel W. S. Almeida
---
.../driver-api/media/drivers/vidtv.rst| 6 +-
.../media/test-drivers/vidtv/vidtv_bridge.c | 4 +
.../media/test-drivers/vidtv/vidtv_channel.c | 61
drivers/media/test-drivers/vidtv/vidtv_mux.c | 17 +
drivers/media/test-drivers/vidtv/vidtv_mux.h | 9 +
drivers/media/test-drivers/vidtv/vidtv_psi.c | 345 +-
drivers/media/test-drivers/vidtv/vidtv_psi.h | 119 +-
7 files changed, 549 insertions(+), 12 deletions(-)
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst
b/Documentation/driver-api/media/drivers/vidtv.rst
index 65115448c52d..2d7ddf676b13 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -149,11 +149,11 @@ vidtv_psi.[ch]
Because the generator is implemented in a separate file, it can be
reused elsewhere in the media subsystem.
- Currently vidtv supports working with 3 PSI tables: PAT, PMT and
- SDT.
+ Currently vidtv supports working with 4 PSI tables: PAT, PMT,
+ SDT and NIT.
The specification for PAT and PMT can be found in *ISO 13818-1:
- Systems*, while the specification for the SDT can be found in *ETSI
+ Systems*, while the specification for the SDT, NIT can be found in *ETSI
EN 300 468: Specification for Service Information (SI) in DVB
systems*.
diff --git a/drivers/media/test-drivers/vidtv/vidtv_bridge.c
b/drivers/media/test-drivers/vidtv/vidtv_bridge.c
index 46655e34a332..069e0cf526c2 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_bridge.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_bridge.c
@@ -28,6 +28,8 @@
//#define MUX_BUF_MIN_SZ
#define TUNER_DEFAULT_ADDR 0x68
#define DEMOD_DEFAULT_ADDR 0x60
+#define VIDTV_DEFAULT_NETWORK_ID 0x744
+#define VIDTV_DEFAULT_NETWORK_NAME "LinuxTV.org"
/* LNBf fake parameters: ranges used by an Universal (extended) European LNBf
*/
#define LNB_CUT_FREQUENCY 1170
@@ -166,6 +168,8 @@ static int vidtv_start_streaming(struct vidtv_dvb *dvb)
.si_period_usecs = si_period_msec * USEC_PER_MSEC,
.pcr_pid = pcr_pid,
.transport_stream_id = VIDTV_DEFAULT_TS_ID,
+ .network_id = VIDTV_DEFAULT_NETWORK_ID,
+ .network_name= VIDTV_DEFAULT_NETWORK_NAME,
};
struct device *dev = >pdev->dev;
u32 mux_buf_sz;
diff --git a/drivers/media/test-drivers/vidtv/vidtv_channel.c
b/drivers/media/test-drivers/vidtv/vidtv_channel.c
index 748697a783a9..6137a2b43420 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c
@@ -279,10 +279,57 @@ vidtv_channel_pmt_match_sections(struct vidtv_channel
*channels,
}
}
+static struct vidtv_psi_desc_service_list_entry
+*vidtv_channel_build_service_list(struct vidtv_psi_table_sdt_service *s)
+{
+ struct vidtv_psi_desc_service_list_entry *curr_e = NULL;
+ struct vidtv_psi_desc_service_list_entry *head_e = NULL;
+ struct vidtv_psi_desc_service_list_entry *prev_e = NULL;
+ struct vidtv_psi_desc *desc = s->descriptor;
+ struct vidtv_psi_desc_service *s_desc;
+
+ while (s) {
+ while (desc) {
+ if (s->descriptor->type != SERVICE_DESCRIPTOR)
+ goto next_desc;
+
+ s_desc = (struct vidtv_psi_desc_service *)desc;
+
+ curr_e = kzalloc(sizeof(*curr_e), GFP_KERNEL);
+ curr_e->service_id = s->service_id;
+ curr_e->service_type = s_desc->service_type;
+
+ if (!head_e)
+ head_e = curr_e;
+ if (prev_e)
+ prev_e->next = curr_e;
+
+ prev_e = curr_e;
+
+next_desc:
+ desc = desc->next;
+ }
+ s = s->next;
+ }
+ return head_e;
+}
+
+static void vidtv_channel_destroy_service_list(struct
vidtv_psi_desc_service_list_entry *e)
+{
+ struct vidtv_psi_desc_service_list_entry *tmp;
+
+ while (e) {
+ tmp = e;
+ e = e->next;
+ kfree(tmp);
+ }
+}
+
int vidtv_channel_si_init(struct vidtv_mux *m)
{
struct vidtv_psi_table_pat_program *programs = NULL;
struct vidtv_psi_table_sdt_service *services = NULL;
+ struct vidtv_psi_desc_service_list_entry *service_list = NULL;
m->si.pat =
[PATCH WIP 1/6] media: vidtv: extract the initial CRC value to into a #define
From: Daniel W. S. Almeida
The same constant (0x) is used in three different functions.
Extract it into a #define to avoid repetition.
Signed-off-by: Daniel W. S. Almeida
---
drivers/media/test-drivers/vidtv/vidtv_psi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.c
b/drivers/media/test-drivers/vidtv/vidtv_psi.c
index 3151b300a91b..a24e84adc8ce 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_psi.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_psi.c
@@ -30,6 +30,7 @@
#define CRC_SIZE_IN_BYTES 4
#define MAX_VERSION_NUM 32
+#define INITIAL_CRC 0x
static const u32 CRC_LUT[256] = {
/* from libdvbv5 */
@@ -794,7 +795,7 @@ u32 vidtv_psi_pat_write_into(struct
vidtv_psi_pat_write_args args)
/* the number of bytes written by this function */
u32 nbytes = 0;
const u16 pat_pid = VIDTV_PAT_PID;
- u32 crc = 0x;
+ u32 crc = INITIAL_CRC;
struct vidtv_psi_table_pat_program *p = args.pat->program;
@@ -990,7 +991,7 @@ u32 vidtv_psi_pmt_write_into(struct
vidtv_psi_pmt_write_args args)
{
/* the number of bytes written by this function */
u32 nbytes = 0;
- u32 crc = 0x;
+ u32 crc = INITIAL_CRC;
struct vidtv_psi_desc *table_descriptor = args.pmt->descriptor;
struct vidtv_psi_table_pmt_stream *stream = args.pmt->stream;
@@ -1143,7 +1144,7 @@ u32 vidtv_psi_sdt_write_into(struct
vidtv_psi_sdt_write_args args)
u32 nbytes = 0;
u16 sdt_pid = VIDTV_SDT_PID; /* see ETSI EN 300 468 v1.15.1 p. 11 */
- u32 crc = 0x;
+ u32 crc = INITIAL_CRC;
struct vidtv_psi_table_sdt_service *service = args.sdt->service;
struct vidtv_psi_desc *service_desc = (args.sdt->service) ?
--
2.28.0
Re: [PATCH 0/8] Introduced new Cadence USBSSP DRD Driver.
On 20-09-28 14:27:33, Pawel Laszczak wrote: > This patch introduce new Cadence USBSS DRD driver to linux kernel. > > The Cadence USBSS DRD Controller is a highly configurable IP Core which > can be instantiated as Dual-Role Device (DRD), Peripheral Only and > Host Only (XHCI)configurations. > > The current driver has been validated with FPGA burned. We have support > for PCIe bus, which is used on FPGA prototyping. > > The host side of USBSS-DRD controller is compliance with XHCI > specification, so it works with standard XHCI Linux driver. > > The host side of USBSS DRD controller is compliant with XHCI. The device side? > The architecture for device side is almost the same as for host side, > and most of the XHCI specification can be used to understand how > this controller operates. > > This controller and driver support Full Speed, Hight Speed, Supper Speed > and Supper Speed Plus USB protocol. > > The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. > The last letter of this acronym means PLUS. The formal name of controller > is USBSSP but it's to generic so I've decided to use CDNSP. > > The patch 1: adds support for DRD CDNSP. > The patch 2: separates common code that can be reusable by cdnsp driver. > The patch 3: moves reusable code to separate module. > The patch 4: changes prefixes in reusable code frome cdns3 to common cdns. > The patch 5: adopts gadget_dev pointer in cdns structure to make possible >use it in both drivers. > The patches 6-8: add the main part of driver and has been intentionally > split into 3 part. In my opinion such division should not > affect understanding and reviewing the driver, and cause that > main patch (7/8) is little smaller. Patch 6 introduces main > header file for driver, 7 is the main part that implements all > functionality of driver and 8 introduces tracepoints. > > --- > > Pawel Laszczak (7): > usb: cdns3: Add support for DRD CDNSP > usb: cdns3: Split core.c into cdns3-plat and core.c file > usb: cdns3: Moves reusable code to separate module > usb: cdns3: Refactoring names in reusable code > usb: cdns3: Changed type of gadget_dev in cdns structure > usb: cdnsp: Device side header file for CDNSP driver > usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver > usb: cdnsp: Add tracepoints for CDNSP driver > > drivers/usb/Kconfig |1 + > drivers/usb/Makefile |1 + > drivers/usb/cdns3/Kconfig |8 + > drivers/usb/cdns3/Makefile|8 +- > drivers/usb/cdns3/cdns3-plat.c| 209 +++ > drivers/usb/cdns3/core.c | 336 ++-- > drivers/usb/cdns3/core.h | 51 +- > drivers/usb/cdns3/drd.c | 219 ++- > drivers/usb/cdns3/drd.h | 93 +- > drivers/usb/cdns3/gadget-export.h | 26 +- > drivers/usb/cdns3/gadget.c| 29 +- > drivers/usb/cdns3/host-export.h | 10 +- > drivers/usb/cdns3/host.c | 23 +- > drivers/usb/cdnsp/Kconfig | 40 + > drivers/usb/cdnsp/Makefile| 12 + > drivers/usb/cdnsp/cdnsp-pci.c | 247 +++ > drivers/usb/cdnsp/debug.h | 583 +++ > drivers/usb/cdnsp/ep0.c | 500 ++ > drivers/usb/cdnsp/gadget.c| 2009 > drivers/usb/cdnsp/gadget.h| 1598 +++ > drivers/usb/cdnsp/mem.c | 1326 > drivers/usb/cdnsp/ring.c | 2426 + > drivers/usb/cdnsp/trace.c | 12 + > drivers/usb/cdnsp/trace.h | 840 ++ > 24 files changed, 10228 insertions(+), 379 deletions(-) > create mode 100644 drivers/usb/cdns3/cdns3-plat.c > create mode 100644 drivers/usb/cdnsp/Kconfig > create mode 100644 drivers/usb/cdnsp/Makefile > create mode 100644 drivers/usb/cdnsp/cdnsp-pci.c > create mode 100644 drivers/usb/cdnsp/debug.h > create mode 100644 drivers/usb/cdnsp/ep0.c > create mode 100644 drivers/usb/cdnsp/gadget.c > create mode 100644 drivers/usb/cdnsp/gadget.h > create mode 100644 drivers/usb/cdnsp/mem.c > create mode 100644 drivers/usb/cdnsp/ring.c > create mode 100644 drivers/usb/cdnsp/trace.c > create mode 100644 drivers/usb/cdnsp/trace.h > > -- > 2.17.1 > -- Thanks, Peter Chen
[v5,2/4] dt-binding: mediatek: mt8192: update mtk-wdt document
update mtk-wdt document for MT8192 platform Signed-off-by: Crystal Guo Reviewed-by: Matthias Brugger Reviewed-by: Guenter Roeck --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 45eedc2c3141..e36ba60de829 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 "mediatek,mt8183-wdt": for MT8183 "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 + "mediatek,mt8192-wdt": for MT8192 - reg : Specifies base physical address and size of the registers. -- 2.18.0
[v5,4/4] watchdog: mt8192: add wdt support
Add support for watchdog device found in MT8192 SoC
Signed-off-by: Crystal Guo
Reviewed-by: Matthias Brugger
Reviewed-by: Guenter Roeck
---
drivers/watchdog/mtk_wdt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index d6a6393f609d..aef0c2db6a11 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,10 @@ static const struct mtk_wdt_data mt8183_data = {
.toprgu_sw_rst_num = MT8183_TOPRGU_SW_RST_NUM,
};
+static const struct mtk_wdt_data mt8192_data = {
+ .toprgu_sw_rst_num = MT8192_TOPRGU_SW_RST_NUM,
+};
+
static int toprgu_reset_update(struct reset_controller_dev *rcdev,
unsigned long id, bool assert)
{
@@ -322,6 +327,7 @@ static const struct of_device_id mtk_wdt_dt_ids[] = {
{ .compatible = "mediatek,mt2712-wdt", .data = _data },
{ .compatible = "mediatek,mt6589-wdt" },
{ .compatible = "mediatek,mt8183-wdt", .data = _data },
+ { .compatible = "mediatek,mt8192-wdt", .data = _data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
--
2.18.0
[v5,1/4] dt-binding: mediatek: watchdog: fix the description of compatible
The watchdog driver for MT2712 and MT8183 relies on DT data, so the fallback compatible MT6589 won't work. Signed-off-by: Crystal Guo Reviewed-by: Matthias Brugger Reviewed-by: Guenter Roeck --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 4dd36bd3f1ad..45eedc2c3141 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -4,13 +4,13 @@ Required properties: - compatible should contain: "mediatek,mt2701-wdt", "mediatek,mt6589-wdt": for MT2701 - "mediatek,mt2712-wdt", "mediatek,mt6589-wdt": for MT2712 + "mediatek,mt2712-wdt": for MT2712 "mediatek,mt6589-wdt": for MT6589 "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 - "mediatek,mt8183-wdt", "mediatek,mt6589-wdt": for MT8183 + "mediatek,mt8183-wdt": for MT8183 "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 - reg : Specifies base physical address and size of the registers. -- 2.18.0
[v5,0/4] watchdog: mt8192: add wdt support
v5 changes: fix typos on: https://patchwork.kernel.org/patch/11697493/ v4 changes: revise commit messages. v3 changes: https://patchwork.kernel.org/patch/11692731/ https://patchwork.kernel.org/patch/11692767/ https://patchwork.kernel.org/patch/11692729/ https://patchwork.kernel.org/patch/11692771/ https://patchwork.kernel.org/patch/11692733/ Crystal Guo (4): dt-binding: mediatek: watchdog: fix the description of compatible dt-binding: mediatek: mt8192: update mtk-wdt document dt-binding: mt8192: add toprgu reset-controller head file watchdog: mt8192: add wdt support .../devicetree/bindings/watchdog/mtk-wdt.txt | 5 ++-- drivers/watchdog/mtk_wdt.c | 6 + .../dt-bindings/reset-controller/mt8192-resets.h | 30 ++ 3 files changed, 39 insertions(+), 2 deletions(-) create mode 100644 include/dt-bindings/reset-controller/mt8192-resets.h
[v5,3/4] dt-binding: mt8192: add toprgu reset-controller head file
add toprgu reset-controller head file for MT8192 platform Signed-off-by: Crystal Guo Reviewed-by: Matthias Brugger Acked-by: Guenter Roeck --- .../reset-controller/mt8192-resets.h | 30 +++ 1 file changed, 30 insertions(+) create mode 100644 include/dt-bindings/reset-controller/mt8192-resets.h diff --git a/include/dt-bindings/reset-controller/mt8192-resets.h b/include/dt-bindings/reset-controller/mt8192-resets.h new file mode 100644 index ..be9a7ca245b9 --- /dev/null +++ b/include/dt-bindings/reset-controller/mt8192-resets.h @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Yong Liang + */ + +#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT8192 +#define _DT_BINDINGS_RESET_CONTROLLER_MT8192 + +#define MT8192_TOPRGU_MM_SW_RST1 +#define MT8192_TOPRGU_MFG_SW_RST 2 +#define MT8192_TOPRGU_VENC_SW_RST 3 +#define MT8192_TOPRGU_VDEC_SW_RST 4 +#define MT8192_TOPRGU_IMG_SW_RST 5 +#define MT8192_TOPRGU_MD_SW_RST7 +#define MT8192_TOPRGU_CONN_SW_RST 9 +#define MT8192_TOPRGU_CONN_MCU_SW_RST 12 +#define MT8192_TOPRGU_IPU0_SW_RST 14 +#define MT8192_TOPRGU_IPU1_SW_RST 15 +#define MT8192_TOPRGU_AUDIO_SW_RST 17 +#define MT8192_TOPRGU_CAMSYS_SW_RST18 +#define MT8192_TOPRGU_MJC_SW_RST 19 +#define MT8192_TOPRGU_C2K_S2_SW_RST20 +#define MT8192_TOPRGU_C2K_SW_RST 21 +#define MT8192_TOPRGU_PERI_SW_RST 22 +#define MT8192_TOPRGU_PERI_AO_SW_RST 23 + +#define MT8192_TOPRGU_SW_RST_NUM 23 + +#endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8192 */ -- 2.18.0
Re: [PATCH v4 12/20] dt-bindings: arm: hisilicon: convert hisilicon,hi3798cv200-perictrl bindings to json-schema
On 2020/9/29 3:14, Rob Herring wrote:
> On Mon, Sep 28, 2020 at 11:13:16PM +0800, Zhen Lei wrote:
>> Convert the Hisilicon Hi3798CV200 Peripheral Controller binding to DT
>> schema format using json-schema.
>>
>> Signed-off-by: Zhen Lei
>> ---
>> .../controller/hisilicon,hi3798cv200-perictrl.txt | 21 --
>> .../controller/hisilicon,hi3798cv200-perictrl.yaml | 45
>> ++
>> 2 files changed, 45 insertions(+), 21 deletions(-)
>> delete mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt
>> deleted file mode 100644
>> index 0d5282f4670658d..000
>> ---
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt
>> +++ /dev/null
>> @@ -1,21 +0,0 @@
>> -Hisilicon Hi3798CV200 Peripheral Controller
>> -
>> -The Hi3798CV200 Peripheral Controller controls peripherals, queries
>> -their status, and configures some functions of peripherals.
>> -
>> -Required properties:
>> -- compatible: Should contain "hisilicon,hi3798cv200-perictrl", "syscon"
>> - and "simple-mfd".
>> -- reg: Register address and size of Peripheral Controller.
>> -- #address-cells: Should be 1.
>> -- #size-cells: Should be 1.
>> -
>> -Examples:
>> -
>> -perictrl: peripheral-controller@8a2 {
>> -compatible = "hisilicon,hi3798cv200-perictrl", "syscon",
>> - "simple-mfd";
>> -reg = <0x8a2 0x1000>;
>> -#address-cells = <1>;
>> -#size-cells = <1>;
>> -};
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.yaml
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.yaml
>> new file mode 100644
>> index 000..4e547017e368393
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.yaml
>> @@ -0,0 +1,45 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id:
>> http://devicetree.org/schemas/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Hisilicon Hi3798CV200 Peripheral Controller
>> +
>> +maintainers:
>> + - Wei Xu
>> +
>> +description: |
>> + The Hi3798CV200 Peripheral Controller controls peripherals, queries
>> + their status, and configures some functions of peripherals.
>> +
>> +properties:
>> + compatible:
>> +items:
>> + - const: hisilicon,hi3798cv200-perictrl
>> + - const: syscon
>> + - const: simple-mfd
>> +
>> + reg:
>> +description: Register address and size
>> +maxItems: 1
>> +
>> + '#address-cells':
>> +const: 1
>> +
>> + '#size-cells':
>> +const: 1
>
> That implies child nodes. You need some sort of schema for them.
OK, I will drop #address-cells and #size-cells in this binding.
>
>> +
>> +required:
>> + - compatible
>> + - reg
>> +
>> +examples:
>> + - |
>> +perictrl: peripheral-controller@8a2 {
>> +compatible = "hisilicon,hi3798cv200-perictrl", "syscon",
>> "simple-mfd";
>> +reg = <0x8a2 0x1000>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +};
>> +...
>> --
>> 1.8.3
>>
>>
>
> .
>
[PATCH v4 0/4] Qualcomm Light Pulse Generator
This series introduces a generic pattern interface in the LED class and a driver for the Qualcomm Light Pulse Generator. It seems like it's been almost 3 years since I posted v3, which was hung up on the lack of conclusion on the hw_pattern and multicolor support. Now that those are concluded I hope we can make some progress on the LPG support again. The dts patches are included in the series as "examples", ultimately my expectation is that the dt binding and driver patches are picked up through the leds tree, while Andy or myself take the dts patches. Bjorn Andersson (4): dt-bindings: leds: Add Qualcomm Light Pulse Generator binding leds: Add driver for Qualcomm LPG arm64: dts: qcom: msm8996: Add mpp and lpg blocks arm64: dts: qcom: Add user LEDs on db820c .../bindings/leds/leds-qcom-lpg.yaml | 170 +++ arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 49 + arch/arm64/boot/dts/qcom/pm8994.dtsi |9 + arch/arm64/boot/dts/qcom/pmi8994.dtsi | 20 + drivers/leds/Kconfig |9 + drivers/leds/Makefile |1 + drivers/leds/leds-qcom-lpg.c | 1213 + 7 files changed, 1471 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml create mode 100644 drivers/leds/leds-qcom-lpg.c -- 2.28.0
[PATCH v4 1/4] dt-bindings: leds: Add Qualcomm Light Pulse Generator binding
This adds the binding document describing the three hardware blocks
related to the Light Pulse Generator found in a wide range of Qualcomm
PMICs.
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- Rewritten as YAML
- Adopt multicolor model
.../bindings/leds/leds-qcom-lpg.yaml | 170 ++
1 file changed, 170 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
new file mode 100644
index ..5c6e98fc3b9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Light Pulse Generator
+
+maintainers:
+ - Bjorn Andersson
+
+description: >
+ The Qualcomm Light Pulse Generator consists of three different hardware
blocks;
+ a ramp generator with lookup table, the light pulse generator and a three
+ channel current sink. These blocks are found in a wide range of Qualcomm
PMICs.
+
+properties:
+ compatible:
+enum:
+ - qcom,pm8916-pwm
+ - qcom,pm8941-lpg
+ - qcom,pm8994-lpg
+ - qcom,pmi8994-lpg
+ - qcom,pmi8998-lpg
+
+ "#pwm-cells":
+const: 2
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ "qcom,power-source":
+$ref: /schemas/types.yaml#definitions/uint32
+description: >
+ power-source used to drive the output, as defined in the datasheet.
+ Should be specified if the TRILED block is present
+enum:
+ - 0
+ - 1
+ - 3
+
+patternProperties:
+ "^led@[0-9a-f]$":
+type: object
+$ref: common.yaml#
+properties:
+ "qcom,dtest":
+$ref: /schemas/types.yaml#definitions/uint32-array
+description: >
+ configures the output into an internal test line of the pmic.
Specified
+ by a list of u32 pairs, one pair per channel, where each pair
denotes the
+ test line to drive and the second configures how the value should be
+ outputed, as defined in the datasheet
+minItems: 2
+maxItems: 2
+
+required:
+ - reg
+
+ "^multi-led$":
+type: object
+$ref: leds-class-multicolor.yaml#
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ "^led@[0-9a-f]$":
+type: object
+$ref: common.yaml#
+
+properties:
+ "qcom,dtest":
+$ref: /schemas/types.yaml#definitions/uint32-array
+description: >
+ configures the output into an internal test line of the pmic.
Specified
+ by a list of u32 pairs, one pair per channel, where each pair
denotes the
+ test line to drive and the second configures how the value
should be
+ outputed, as defined in the datasheet
+minItems: 2
+maxItems: 2
+
+required:
+ - reg
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+lpg {
+ compatible = "qcom,pmi8994-lpg";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ qcom,power-source = <1>;
+
+ led@1 {
+reg = <1>;
+label = "green:user1";
+ };
+
+ led@2 {
+reg = <2>;
+label = "green:user0";
+default-state = "on";
+ };
+
+ led@3 {
+reg = <3>;
+label = "green:user2";
+ };
+
+ led@4 {
+reg = <4>;
+label = "green:user3";
+
+qcom,dtest = <4 1>;
+ };
+};
+ - |
+#include
+
+lpg {
+ compatible = "qcom,pmi8994-lpg";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ qcom,power-source = <1>;
+
+ multi-led {
+color = ;
+ label = "rgb:notification";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@1 {
+ reg = <1>;
+ color = ;
+};
+
+led@2 {
+ reg = <2>;
+ color = ;
+};
+
+led@3 {
+ reg = <3>;
+ color = ;
+};
+ };
+};
+ - |
+lpg {
+ compatible = "qcom,pm8916-pwm";
+ #pwm-cells = <2>;
+};
+...
--
2.28.0
[PATCH v4 4/4] arm64: dts: qcom: Add user LEDs on db820c
The db820c has 4 "user LEDs", all connected to the PMI8994. The first
three are connected to the three current sinks provided by the TRILED
and the fourth is connected to MPP2.
By utilizing the DTEST bus the MPP is fed the control signal from the
fourth LPG block, providing a consistent interface to the user.
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- Updated labels
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 49
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..7e51677d256e 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -8,6 +8,7 @@
#include "pmi8994.dtsi"
#include
#include
+#include
#include
#include
#include
@@ -682,6 +683,54 @@ pinconf {
};
};
+_mpps {
+ pmi8994_mpp2_userled4: mpp2-userled4 {
+ pins = "mpp2";
+ function = "sink";
+
+ output-low;
+ qcom,dtest = <4>;
+ };
+};
+
+_lpg {
+ qcom,power-source = <1>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_mpp2_userled4>;
+
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ label = "green:user1";
+
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "green:user0";
+ default-state = "on";
+ };
+
+ led@3 {
+ reg = <3>;
+ label = "green:user2";
+ };
+
+ led@4 {
+ reg = <4>;
+ label = "green:user3";
+
+ qcom,dtest = <4 1>;
+ };
+};
+
_spmi_regulators {
vdd_gfx: s2@1700 {
reg = <0x1700 0x100>;
--
2.28.0
[PATCH v4 2/4] leds: Add driver for Qualcomm LPG
The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
PMICs from Qualcomm. It can operate on fixed parameters or based on a
lookup-table, altering the duty cycle over time - which provides the
means for e.g. hardware assisted transitions of LED brightness.
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- Adopt multicolor model
- Simplified hw_pattern implementation
drivers/leds/Kconfig |9 +
drivers/leds/Makefile|1 +
drivers/leds/leds-qcom-lpg.c | 1213 ++
3 files changed, 1223 insertions(+)
create mode 100644 drivers/leds/leds-qcom-lpg.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 849d3c5f908e..d500648c586f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -803,6 +803,15 @@ config LEDS_POWERNV
To compile this driver as a module, choose 'm' here: the module
will be called leds-powernv.
+config LEDS_QCOM_LPG
+ tristate "LED support for Qualcomm LPG"
+ depends on LEDS_CLASS_MULTICOLOR
+ depends on OF
+ depends on SPMI
+ help
+ This option enables support for the Light Pulse Generator found in a
+ wide variety of Qualcomm PMICs.
+
config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 73e603e1727e..52d0ea26fc35 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_LEDS_PCA963X)+= leds-pca963x.o
obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
+obj-$(CONFIG_LEDS_QCOM_LPG)+= leds-qcom-lpg.o
obj-$(CONFIG_LEDS_REGULATOR) += leds-regulator.o
obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
diff --git a/drivers/leds/leds-qcom-lpg.c b/drivers/leds/leds-qcom-lpg.c
new file mode 100644
index ..17594ce37c9a
--- /dev/null
+++ b/drivers/leds/leds-qcom-lpg.c
@@ -0,0 +1,1213 @@
+/*
+ * Copyright (c) 2017-2019 Linaro Ltd
+ * Copyright (c) 2010-2012, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LPG_PATTERN_CONFIG_REG 0x40
+#define LPG_SIZE_CLK_REG 0x41
+#define LPG_PREDIV_CLK_REG 0x42
+#define PWM_TYPE_CONFIG_REG0x43
+#define PWM_VALUE_REG 0x44
+#define PWM_ENABLE_CONTROL_REG 0x46
+#define PWM_SYNC_REG 0x47
+#define LPG_RAMP_DURATION_REG 0x50
+#define LPG_HI_PAUSE_REG 0x52
+#define LPG_LO_PAUSE_REG 0x54
+#define LPG_HI_IDX_REG 0x56
+#define LPG_LO_IDX_REG 0x57
+#define PWM_SEC_ACCESS_REG 0xd0
+#define PWM_DTEST_REG(x) (0xe2 + (x) - 1)
+
+#define TRI_LED_SRC_SEL0x45
+#define TRI_LED_EN_CTL 0x46
+#define TRI_LED_ATC_CTL0x47
+
+#define LPG_LUT_REG(x) (0x40 + (x) * 2)
+#define RAMP_CONTROL_REG 0xc8
+
+struct lpg_channel;
+struct lpg_data;
+
+/**
+ * struct lpg - LPG device context
+ * @dev: struct device for LPG device
+ * @map: regmap for register access
+ * @pwm: PWM-chip object, if operating in PWM mode
+ * @lut_base: base address of the LUT block (optional)
+ * @lut_size: number of entries in the LUT block
+ * @lut_bitmap:allocation bitmap for LUT entries
+ * @triled_base: base address of the TRILED block (optional)
+ * @triled_src:power-source for the TRILED
+ * @channels: list of PWM channels
+ * @num_channels: number of @channels
+ */
+struct lpg {
+ struct device *dev;
+ struct regmap *map;
+
+ struct pwm_chip pwm;
+
+ const struct lpg_data *data;
+
+ u32 lut_base;
+ u32 lut_size;
+ unsigned long *lut_bitmap;
+
+ u32 triled_base;
+ u32 triled_src;
+
+ struct lpg_channel *channels;
+ unsigned int num_channels;
+};
+
+/**
+ * struct lpg_channel - per channel data
+ * @lpg: reference to parent lpg
+ * @base: base address of the PWM channel
+ * @triled_mask: mask in TRILED to enable this channel
+ * @lut_mask: mask in LUT to start pattern generator for this channel
+ * @in_use:channel is exposed to LED framework
+ * @color: color of the LED attached to this channel
+ * @dtest_line:DTEST line for output, or 0 if disabled
+ * @dtest_value:
[PATCH v4 3/4] arm64: dts: qcom: msm8996: Add mpp and lpg blocks
The pm8994 contains a 6 LPG channels. The pmi8994 contains 4 MPP
channels and a 4 channel LPG, with TRILED and LUT blocks.
Add nodes for these blocks.
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- None
arch/arm64/boot/dts/qcom/pm8994.dtsi | 9 +
arch/arm64/boot/dts/qcom/pmi8994.dtsi | 20
2 files changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi
b/arch/arm64/boot/dts/qcom/pm8994.dtsi
index 7e4f46cb..b5bef687aa3c 100644
--- a/arch/arm64/boot/dts/qcom/pm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8994.dtsi
@@ -86,6 +86,15 @@ pmic@1 {
#address-cells = <1>;
#size-cells = <0>;
+ pm8994_lpg: lpg {
+ compatible = "qcom,pm8994-lpg";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
pm8994_spmi_regulators: regulators {
compatible = "qcom,pm8994-regulators";
};
diff --git a/arch/arm64/boot/dts/qcom/pmi8994.dtsi
b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
index e5ed28ab9b2d..23f41328d191 100644
--- a/arch/arm64/boot/dts/qcom/pmi8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
@@ -19,6 +19,17 @@ pmi8994_gpios: gpios@c000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+ pmi8994_mpps: mpps@a000 {
+ compatible = "qcom,pm8994-mpp";
+ reg = <0xa000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,
+<0 0xa1 0 IRQ_TYPE_NONE>,
+<0 0xa2 0 IRQ_TYPE_NONE>,
+<0 0xa3 0 IRQ_TYPE_NONE>;
+ };
};
pmic@3 {
@@ -27,6 +38,15 @@ pmic@3 {
#address-cells = <1>;
#size-cells = <0>;
+ pmi8994_lpg: lpg@b100 {
+ compatible = "qcom,pmi8994-lpg";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
pmi8994_spmi_regulators: regulators {
compatible = "qcom,pmi8994-regulators";
#address-cells = <1>;
--
2.28.0
Re: [PATCH v13 02/10] KVM: x86/vmx: Make vmx_set_intercept_for_msr() non-static and expose it
On Sun, Jul 26, 2020 at 11:32:21PM +0800, Like Xu wrote:
> It's reasonable to call vmx_set_intercept_for_msr() in other vmx-specific
> files (e.g. pmu_intel.c), so expose it without semantic changes hopefully.
I suppose it's reasonable, but you still need to state what is actually
going to use it.
> Signed-off-by: Like Xu
> ---
> arch/x86/kvm/vmx/vmx.c | 4 ++--
> arch/x86/kvm/vmx/vmx.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dcde73a230c6..162c668d58f5 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -3772,8 +3772,8 @@ static __always_inline void
> vmx_enable_intercept_for_msr(unsigned long *msr_bitm
> }
> }
>
> -static __always_inline void vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> - u32 msr, int type, bool
> value)
> +__always_inline void vmx_set_intercept_for_msr(unsigned long *msr_bitmap,
> + u32 msr, int type, bool value)
> {
> if (value)
> vmx_enable_intercept_for_msr(msr_bitmap, msr, type);
> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> index 0d06951e607c..08c850596cfc 100644
> --- a/arch/x86/kvm/vmx/vmx.h
> +++ b/arch/x86/kvm/vmx/vmx.h
> @@ -356,6 +356,8 @@ void vmx_update_host_rsp(struct vcpu_vmx *vmx, unsigned
> long host_rsp);
> int vmx_find_msr_index(struct vmx_msrs *m, u32 msr);
> int vmx_handle_memory_failure(struct kvm_vcpu *vcpu, int r,
> struct x86_exception *e);
> +void vmx_set_intercept_for_msr(unsigned long *msr_bitmap,
> + u32 msr, int type, bool value);
This completely defeats the purpose of __always_inline.
>
> #define POSTED_INTR_ON 0
> #define POSTED_INTR_SN 1
> --
> 2.21.3
>
Re: [PATCH v4 20/20] dt-bindings: arm: hisilicon: convert LPC controller bindings to json-schema
On 2020/9/29 3:16, Rob Herring wrote:
> On Mon, Sep 28, 2020 at 11:13:24PM +0800, Zhen Lei wrote:
>> Convert the Hisilicon Hip06 SoCs implement a Low Pin Count (LPC)
>> controller binding to DT schema format using json-schema.
>>
>> Signed-off-by: Zhen Lei
>> ---
>> .../arm/hisilicon/hisilicon-low-pin-count.txt | 33
>> .../arm/hisilicon/hisilicon-low-pin-count.yaml | 61
>> ++
>> 2 files changed, 61 insertions(+), 33 deletions(-)
>> delete mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>> deleted file mode 100644
>> index 10bd35f9207f2ee..000
>> ---
>> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
>> +++ /dev/null
>> @@ -1,33 +0,0 @@
>> -Hisilicon Hip06 Low Pin Count device
>> - Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
>> - provides I/O access to some legacy ISA devices.
>> - Hip06 is based on arm64 architecture where there is no I/O space. So, the
>> - I/O ports here are not CPU addresses, and there is no 'ranges' property in
>> - LPC device node.
>> -
>> -Required properties:
>> -- compatible: value should be as follows:
>> -(a) "hisilicon,hip06-lpc"
>> -(b) "hisilicon,hip07-lpc"
>> -- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
>> -- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
>> -- reg: base memory range where the LPC register set is mapped.
>> -
>> -Note:
>> - The node name before '@' must be "isa" to represent the binding stick to
>> the
>> - ISA/EISA binding specification.
>> -
>> -Example:
>> -
>> -isa@a01b {
>> -compatible = "hisilicon,hip06-lpc";
>> -#address-cells = <2>;
>> -#size-cells = <1>;
>> -reg = <0x0 0xa01b 0x0 0x1000>;
>> -
>> -ipmi0: bt@e4 {
>> -compatible = "ipmi-bt";
>> -device_type = "ipmi";
>> -reg = <0x01 0xe4 0x04>;
>> -};
>> -};
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.yaml
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.yaml
>> new file mode 100644
>> index 000..83ca10adce71b62
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.yaml
>> @@ -0,0 +1,61 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id:
>> http://devicetree.org/schemas/arm/hisilicon/hisilicon-low-pin-count.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Hisilicon Hip06 Low Pin Count device
>> +
>> +maintainers:
>> + - Wei Xu
>> +
>> +description: |
>> + Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
>> + provides I/O access to some legacy ISA devices.
>> + Hip06 is based on arm64 architecture where there is no I/O space. So, the
>> + I/O ports here are not CPU addresses, and there is no 'ranges' property in
>> + LPC device node.
>> +
>> +properties:
>> + $nodename:
>> +pattern: '^isa@[0-9a-f]+$'
>> +description: |
>> + The node name before '@' must be "isa" to represent the binding stick
>> + to the ISA/EISA binding specification.
>> +
>> + compatible:
>> +enum:
>> + - hisilicon,hip06-lpc
>> + - hisilicon,hip07-lpc
>> +
>> + reg:
>> +description: base memory range where the LPC register set is mapped.
>
> Drop description.
OK
>
>> +maxItems: 1
>> +
>> + '#address-cells':
>> +description: must be 2 which stick to the ISA/EISA binding doc.
>
> Drop.
OK
>
>> +const: 2
>> +
>> + '#size-cells':
>> +description: must be 1 which stick to the ISA/EISA binding doc.
>
> Drop.
OK
>
>> +const: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>
> additionalProperties:
> type: object
OK, I will add it.
>
>> +
>> +examples:
>> + - |
>> +isa@a01b {
>> +compatible = "hisilicon,hip06-lpc";
>> +#address-cells = <2>;
>> +#size-cells = <1>;
>> +reg = <0xa01b 0x1000>;
>> +
>> +ipmi0: bt@e4 {
>> +compatible = "ipmi-bt";
>> +device_type = "ipmi";
>> +reg = <0x01 0xe4 0x04>;
>> +};
>> +};
>> +...
>> --
>> 1.8.3
>>
>>
>
> .
>
Re: [PATCH v4 07/20] dt-bindings: arm: hisilicon: convert system controller bindings to json-schema
On 2020/9/29 3:13, Rob Herring wrote:
> On Mon, Sep 28, 2020 at 11:13:11PM +0800, Zhen Lei wrote:
>> Convert the Hisilicon system controller and its variants binding to DT
>> schema format using json-schema. All of them are grouped into one yaml
>> file, to help users understand differences and avoid repeated
>> descriptions.
>>
>> Signed-off-by: Zhen Lei
>> ---
>> .../controller/hisilicon,hi6220-sysctrl.txt| 19
>> .../controller/hisilicon,hip01-sysctrl.txt | 19
>> .../arm/hisilicon/controller/hisilicon,sysctrl.txt | 25 -
>> .../hisilicon/controller/hisilicon,sysctrl.yaml| 115
>> +
>> .../bindings/arm/hisilicon/hi3519-sysctrl.txt | 14 ---
>> 5 files changed, 115 insertions(+), 77 deletions(-)
>> delete mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-sysctrl.txt
>> delete mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip01-sysctrl.txt
>> delete mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.yaml
>> delete mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-sysctrl.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-sysctrl.txt
>> deleted file mode 100644
>> index 07e318eda254f52..000
>> ---
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-sysctrl.txt
>> +++ /dev/null
>> @@ -1,19 +0,0 @@
>> -Hisilicon Hi6220 system controller
>> -
>> -Required properties:
>> -- compatible : "hisilicon,hi6220-sysctrl"
>> -- reg : Register address and size
>> -- #clock-cells: should be set to 1, many clock registers are defined
>> - under this controller and this property must be present.
>> -
>> -Hisilicon designs this controller as one of the system controllers,
>> -its main functions are the same as Hisilicon system controller, but
>> -the register offset of some core modules are different.
>> -
>> -Example:
>> -/*for Hi6220*/
>> -sys_ctrl: sys_ctrl@f703 {
>> -compatible = "hisilicon,hi6220-sysctrl", "syscon";
>> -reg = <0x0 0xf703 0x0 0x2000>;
>> -#clock-cells = <1>;
>> -};
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip01-sysctrl.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip01-sysctrl.txt
>> deleted file mode 100644
>> index db2dfdce799db91..000
>> ---
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip01-sysctrl.txt
>> +++ /dev/null
>> @@ -1,19 +0,0 @@
>> -Hisilicon HiP01 system controller
>> -
>> -Required properties:
>> -- compatible : "hisilicon,hip01-sysctrl"
>> -- reg : Register address and size
>> -
>> -The HiP01 system controller is mostly compatible with hisilicon
>> -system controller,but it has some specific control registers for
>> -HIP01 SoC family, such as slave core boot, and also some same
>> -registers located at different offset.
>> -
>> -Example:
>> -
>> -/* for hip01-ca9x2 */
>> -sysctrl: system-controller@1000 {
>> -compatible = "hisilicon,hip01-sysctrl", "hisilicon,sysctrl";
>> -reg = <0x1000 0x1000>;
>> -reboot-offset = <0x4>;
>> -};
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.txt
>> deleted file mode 100644
>> index 963f7f1ca7a2f0c..000
>> ---
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.txt
>> +++ /dev/null
>> @@ -1,25 +0,0 @@
>> -Hisilicon system controller
>> -
>> -Required properties:
>> -- compatible : "hisilicon,sysctrl"
>> -- reg : Register address and size
>> -
>> -Optional properties:
>> -- smp-offset : offset in sysctrl for notifying slave cpu booting
>> -cpu 1, reg;
>> -cpu 2, reg + 0x4;
>> -cpu 3, reg + 0x8;
>> -If reg value is not zero, cpun exit wfi and go
>> -- resume-offset : offset in sysctrl for notifying cpu0 when resume
>> -- reboot-offset : offset in sysctrl for system reboot
>> -
>> -Example:
>> -
>> -/* for Hi3620 */
>> -sysctrl: system-controller@fc802000 {
>> -compatible = "hisilicon,sysctrl";
>> -reg = <0xfc802000 0x1000>;
>> -smp-offset = <0x31c>;
>> -resume-offset = <0x308>;
>> -reboot-offset = <0x4>;
>> -};
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.yaml
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.yaml
>> new file
Re: [PATCH v4 03/20] dt-bindings: arm: hisilicon: add binding for SD5203 SoC
On 2020/9/29 3:07, Rob Herring wrote: > On Mon, Sep 28, 2020 at 11:13:07PM +0800, Zhen Lei wrote: >> Add devicetree binding for Hisilicon SD5203 SoC. >> >> Signed-off-by: Zhen Lei >> --- >> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml >> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml >> index 6d17309c7c84308..3337eebc61da812 100644 >> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml >> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml >> @@ -59,4 +59,8 @@ properties: >>- description: HiP07 D05 Board >> items: >>- const: hisilicon,hip07-d05 >> + >> + - description: SD5203 Board > > This should be a board compatible and then a SoC compatible. OK, I will fix it. > >> +items: >> + - const: hisilicon,sd5203 >> ... >> -- >> 1.8.3 >> >> > > . >
Re: [PATCH v4 01/20] dt-bindings: arm: hisilicon: split the dt-bindings of each controller into a separate file
On 2020/9/29 3:05, Rob Herring wrote:
> On Mon, Sep 28, 2020 at 11:13:05PM +0800, Zhen Lei wrote:
>> Split the devicetree bindings of each Hisilicon controller from
>> hisilicon.txt into a separate file, the file name is the compatible name
>> attach the .txt file name extension.
>>
>> All Hi6220 dedicated controllers are grouped into subdirectory "hi3620".
>> All HiPxx dedicated controllers are grouped into subdirectory "hipxx"
>>
>> Signed-off-by: Zhen Lei
>> ---
>> .../arm/hisilicon/controller/hisilicon,cpuctrl.txt | 8 +
>> .../hisilicon/controller/hisilicon,dsa-subctrl.txt | 15 ++
>> .../controller/hisilicon,hi3798cv200-perictrl.txt | 21 ++
>> .../controller/hisilicon,hi6220-aoctrl.txt | 18 ++
>> .../controller/hisilicon,hi6220-mediactrl.txt | 18 ++
>> .../controller/hisilicon,hi6220-pmctrl.txt | 18 ++
>> .../controller/hisilicon,hi6220-sramctrl.txt | 16 ++
>> .../controller/hisilicon,hi6220-sysctrl.txt| 19 ++
>> .../controller/hisilicon,hip01-sysctrl.txt | 19 ++
>> .../controller/hisilicon,hip04-bootwrapper.txt | 9 +
>> .../controller/hisilicon,hip04-fabric.txt | 5 +
>> .../controller/hisilicon,pcie-sas-subctrl.txt | 15 ++
>> .../arm/hisilicon/controller/hisilicon,pctrl.txt | 13 +
>> .../controller/hisilicon,peri-subctrl.txt | 16 ++
>> .../arm/hisilicon/controller/hisilicon,sysctrl.txt | 25 ++
>> .../bindings/arm/hisilicon/hisilicon.txt | 262
>> -
>> 16 files changed, 235 insertions(+), 262 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,cpuctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,dsa-subctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-aoctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-mediactrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-pmctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-sramctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi6220-sysctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip01-sysctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip04-bootwrapper.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hip04-fabric.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,pcie-sas-subctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,pctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,peri-subctrl.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,sysctrl.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,cpuctrl.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,cpuctrl.txt
>> new file mode 100644
>> index 000..ceffac537671668
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,cpuctrl.txt
>> @@ -0,0 +1,8 @@
>> +Hisilicon CPU controller
>> +
>> +Required properties:
>> +- compatible : "hisilicon,cpuctrl"
>> +- reg : Register address and size
>> +
>> +The clock registers and power registers of secondary cores are defined
>> +in CPU controller, especially in HIX5HD2 SoC.
>> diff --git
>> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,dsa-subctrl.txt
>>
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,dsa-subctrl.txt
>> new file mode 100644
>> index 000..4d1c6abf03f6f97
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,dsa-subctrl.txt
>> @@ -0,0 +1,15 @@
>> +Hisilicon HiP05/HiP06 DSA sub system controller
>> +
>> +Required properties:
>> +- compatible : "hisilicon,dsa-subctrl", "syscon";
>
> This and others with only 'reg' can just be moved to syscon.yaml.
OK, I will do it.
>
>> +- reg : Register address and size
>> +
>> +The DSA sub system controller is shared by peripheral controllers in
>> +HiP05 or HiP06 Soc to implement some basic configurations.
>> +
>> +Example:
>> +/* for HiP05 dsa sub system */
>> +pcie_sas: system_controller@a000 {
>> +compatible = "hisilicon,dsa-subctrl", "syscon";
>> +reg = <0xa000 0x1>;
>> +};
...
>
> .
>
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/ethernet/marvell/prestera/prestera_main.c: In function
'prestera_port_dev_lower_find':
drivers/net/ethernet/marvell/prestera/prestera_main.c:504:33: error: passing
argument 2 of 'netdev_walk_all_lower_dev' from incompatible pointer type
[-Werror=incompatible-pointer-types]
504 | netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, );
| ^~~
| |
| int (*)(struct net_device *, void *)
In file included from include/linux/etherdevice.h:21,
from drivers/net/ethernet/marvell/prestera/prestera_main.c:4:
include/linux/netdevice.h:4571:16: note: expected 'int (*)(struct net_device *,
struct netdev_nested_priv *)' but argument is of type 'int (*)(struct
net_device *, void *)'
4571 | int (*fn)(struct net_device *lower_dev,
| ~~^
4572 | struct netdev_nested_priv *priv),
|
drivers/net/ethernet/marvell/prestera/prestera_main.c:504:58: error: passing
argument 3 of 'netdev_walk_all_lower_dev' from incompatible pointer type
[-Werror=incompatible-pointer-types]
504 | netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, );
| ^
| |
| struct
prestera_port **
In file included from include/linux/etherdevice.h:21,
from drivers/net/ethernet/marvell/prestera/prestera_main.c:4:
include/linux/netdevice.h:4573:37: note: expected 'struct netdev_nested_priv *'
but argument is of type 'struct prestera_port **'
4573 | struct netdev_nested_priv *priv);
| ~~~^~~~
cc1: some warnings being treated as errors
Caused by commit
eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested
interface infrastructure")
interacting with commit
e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation")
also in the net-next tree.
I applied the following fix patch.
From: Stephen Rothwell
Date: Tue, 29 Sep 2020 12:57:59 +1000
Subject: [PATCH] fix up for "net: core: introduce struct netdev_nested_priv for
nested interface infrastructure"
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/marvell/prestera/prestera_main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/prestera/prestera_main.c
b/drivers/net/ethernet/marvell/prestera/prestera_main.c
index 9bd57b89d1d0..633d8770be35 100644
--- a/drivers/net/ethernet/marvell/prestera/prestera_main.c
+++ b/drivers/net/ethernet/marvell/prestera/prestera_main.c
@@ -482,9 +482,10 @@ bool prestera_netdev_check(const struct net_device *dev)
return dev->netdev_ops == _netdev_ops;
}
-static int prestera_lower_dev_walk(struct net_device *dev, void *data)
+static int prestera_lower_dev_walk(struct net_device *dev,
+ struct netdev_nested_priv *priv)
{
- struct prestera_port **pport = data;
+ struct prestera_port **pport = (struct prestera_port **)priv->data;
if (prestera_netdev_check(dev)) {
*pport = netdev_priv(dev);
@@ -497,11 +498,13 @@ static int prestera_lower_dev_walk(struct net_device
*dev, void *data)
struct prestera_port *prestera_port_dev_lower_find(struct net_device *dev)
{
struct prestera_port *port = NULL;
+ struct netdev_nested_priv priv;
if (prestera_netdev_check(dev))
return netdev_priv(dev);
- netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, );
+ priv.data = (void *)
+ netdev_walk_all_lower_dev(dev, prestera_lower_dev_walk, );
return port;
}
--
2.28.0
--
Cheers,
Stephen Rothwell
pgp3Z6LuxPhxb.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] mm: remove extra ZONE_DEVICE struct page refcount
On Fri, Sep 25, 2020 at 01:44:42PM -0700, Ralph Campbell wrote: > ZONE_DEVICE struct pages have an extra reference count that complicates the > code for put_page() and several places in the kernel that need to check the > reference count to see that a page is not being used (gup, compaction, > migration, etc.). Clean up the code so the reference count doesn't need to > be treated specially for ZONE_DEVICE. > > Signed-off-by: Ralph Campbell > --- > arch/powerpc/kvm/book3s_hv_uvmem.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- > include/linux/dax.h| 2 +- > include/linux/memremap.h | 7 ++- > include/linux/mm.h | 44 -- > lib/test_hmm.c | 2 +- > mm/gup.c | 44 -- > mm/internal.h | 8 +++ > mm/memremap.c | 82 ++ > mm/migrate.c | 5 -- > mm/page_alloc.c| 3 + > mm/swap.c | 46 +++ > 12 files changed, 44 insertions(+), 203 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c > b/arch/powerpc/kvm/book3s_hv_uvmem.c > index 7705d5557239..e6ec98325fab 100644 > --- a/arch/powerpc/kvm/book3s_hv_uvmem.c > +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c > @@ -711,7 +711,7 @@ static struct page *kvmppc_uvmem_get_page(unsigned long > gpa, struct kvm *kvm) > > dpage = pfn_to_page(uvmem_pfn); > dpage->zone_device_data = pvt; > - get_page(dpage); > + init_page_count(dpage); The powerpc change looks good. Passes a quick sanity test of booting/rebooting a secure guest on Power. Tested-by: Bharata B Rao Regards, Bharata.
Re: [PATCH v2 23/25] powerpc/signal: Create 'unsafe' versions of copy_[ck][fpr/vsx]_to_user()
On Tue Aug 18, 2020 at 12:19 PM CDT, Christophe Leroy wrote:
> For the non VSX version, that's trivial. Just use unsafe_copy_to_user()
> instead of __copy_to_user().
>
> For the VSX version, remove the intermediate step through a buffer and
> use unsafe_put_user() directly. This generates a far smaller code which
> is acceptable to inline, see below:
>
> Standard VSX version:
>
> <.copy_fpr_to_user>:
> 0: 7c 08 02 a6 mflr r0
> 4: fb e1 ff f8 std r31,-8(r1)
> 8: 39 00 00 20 li r8,32
> c: 39 24 0b 80 addi r9,r4,2944
> 10: 7d 09 03 a6 mtctr r8
> 14: f8 01 00 10 std r0,16(r1)
> 18: f8 21 fe 71 stdu r1,-400(r1)
> 1c: 39 41 00 68 addi r10,r1,104
> 20: e9 09 00 00 ld r8,0(r9)
> 24: 39 4a 00 08 addi r10,r10,8
> 28: 39 29 00 10 addi r9,r9,16
> 2c: f9 0a 00 00 std r8,0(r10)
> 30: 42 00 ff f0 bdnz 20 <.copy_fpr_to_user+0x20>
> 34: e9 24 0d 80 ld r9,3456(r4)
> 38: 3d 42 00 00 addis r10,r2,0
> 3a: R_PPC64_TOC16_HA .toc
> 3c: eb ea 00 00 ld r31,0(r10)
> 3e: R_PPC64_TOC16_LO_DS .toc
> 40: f9 21 01 70 std r9,368(r1)
> 44: e9 3f 00 00 ld r9,0(r31)
> 48: 81 29 00 20 lwz r9,32(r9)
> 4c: 2f 89 00 00 cmpwi cr7,r9,0
> 50: 40 9c 00 18 bge cr7,68 <.copy_fpr_to_user+0x68>
> 54: 4c 00 01 2c isync
> 58: 3d 20 40 00 lis r9,16384
> 5c: 79 29 07 c6 rldicr r9,r9,32,31
> 60: 7d 3d 03 a6 mtspr 29,r9
> 64: 4c 00 01 2c isync
> 68: 38 a0 01 08 li r5,264
> 6c: 38 81 00 70 addi r4,r1,112
> 70: 48 00 00 01 bl 70 <.copy_fpr_to_user+0x70>
> 70: R_PPC64_REL24 .__copy_tofrom_user
> 74: 60 00 00 00 nop
> 78: e9 3f 00 00 ld r9,0(r31)
> 7c: 81 29 00 20 lwz r9,32(r9)
> 80: 2f 89 00 00 cmpwi cr7,r9,0
> 84: 40 9c 00 18 bge cr7,9c <.copy_fpr_to_user+0x9c>
> 88: 4c 00 01 2c isync
> 8c: 39 20 ff ff li r9,-1
> 90: 79 29 00 44 rldicr r9,r9,0,1
> 94: 7d 3d 03 a6 mtspr 29,r9
> 98: 4c 00 01 2c isync
> 9c: 38 21 01 90 addi r1,r1,400
> a0: e8 01 00 10 ld r0,16(r1)
> a4: eb e1 ff f8 ld r31,-8(r1)
> a8: 7c 08 03 a6 mtlr r0
> ac: 4e 80 00 20 blr
>
> 'unsafe' simulated VSX version (The ... are only nops) using
> unsafe_copy_fpr_to_user() macro:
>
> unsigned long copy_fpr_to_user(void __user *to,
> struct task_struct *task)
> {
> unsafe_copy_fpr_to_user(to, task, failed);
> return 0;
> failed:
> return 1;
> }
>
> <.copy_fpr_to_user>:
> 0: 39 00 00 20 li r8,32
> 4: 39 44 0b 80 addi r10,r4,2944
> 8: 7d 09 03 a6 mtctr r8
> c: 7c 69 1b 78 mr r9,r3
> ...
> 20: e9 0a 00 00 ld r8,0(r10)
> 24: f9 09 00 00 std r8,0(r9)
> 28: 39 4a 00 10 addi r10,r10,16
> 2c: 39 29 00 08 addi r9,r9,8
> 30: 42 00 ff f0 bdnz 20 <.copy_fpr_to_user+0x20>
> 34: e9 24 0d 80 ld r9,3456(r4)
> 38: f9 23 01 00 std r9,256(r3)
> 3c: 38 60 00 00 li r3,0
> 40: 4e 80 00 20 blr
> ...
> 50: 38 60 00 01 li r3,1
> 54: 4e 80 00 20 blr
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/signal.h | 53
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
> index f610cfafa478..2559a681536e 100644
> --- a/arch/powerpc/kernel/signal.h
> +++ b/arch/powerpc/kernel/signal.h
> @@ -32,7 +32,54 @@ unsigned long copy_fpr_to_user(void __user *to,
> struct task_struct *task);
> unsigned long copy_ckfpr_to_user(void __user *to, struct task_struct
> *task);
> unsigned long copy_fpr_from_user(struct task_struct *task, void __user
> *from);
> unsigned long copy_ckfpr_from_user(struct task_struct *task, void __user
> *from);
> +
> +#define unsafe_copy_fpr_to_user(to, task, label) do { \
> + struct task_struct *__t = task; \
> + u64 __user *buf = (u64 __user *)to; \
> + int i; \
> + \
> + for (i = 0; i < ELF_NFPREG - 1 ; i++) \
> + unsafe_put_user(__t->thread.TS_FPR(i), [i], label); \
> + unsafe_put_user(__t->thread.fp_state.fpscr, [i], label); \
> +} while (0)
> +
I've been working on the PPC64 side of this "unsafe" rework using this
series as a basis. One question here - I don't really understand what
the benefit of re-implementing this logic in macros (similarly for the
other copy_* functions below) is?
I am considering a "__unsafe_copy_*" implementation in signal.c for
each (just the original implementation w/ using the "unsafe_" variants
of the uaccess stuff) which gets called by the "safe" functions w/ the
appropriate "user_*_access_begin/user_*_access_end". Something like
(pseudo-ish code):
/* signal.c */
unsigned long __unsafe_copy_fpr_to_user(...)
{
...
unsafe_copy_to_user(..., bad);
return 0;
bad:
return 1; /* -EFAULT? */
}
unsigned long copy_fpr_to_user(...)
{
unsigned long err;
if (!user_write_access_begin(...))
return 1; /* -EFAULT? */
err = __unsafe_copy_fpr_to_user(...);
user_write_access_end();
return err;
}
/* signal.h */
unsigned long __unsafe_copy_fpr_to_user(...);
#define unsafe_copy_fpr_to_user(..., label) \
Re: [PATCH v2 25/25] powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version
On Tue Aug 18, 2020 at 12:19 PM CDT, Christophe Leroy wrote:
> Change those two functions to be used within a user access block.
>
> For that, change save_general_regs() to and unsafe_save_general_regs(),
> then replace all user accesses by unsafe_ versions.
>
> This series leads to a reduction from 2.55s to 1.73s of
> the system CPU time with the following microbench app
> on an mpc832x with KUAP (approx 32%)
>
> Without KUAP, the difference is in the noise.
>
> void sigusr1(int sig) { }
>
> int main(int argc, char **argv)
> {
> int i = 10;
>
> signal(SIGUSR1, sigusr1);
> for (;i--;)
> raise(SIGUSR1);
> exit(0);
> }
>
> An additional 0.10s reduction is achieved by removing
> CONFIG_PPC_FPU, as the mpc832x has no FPU.
>
> A bit less spectacular on an 8xx as KUAP is less heavy, prior to
> the series (with KUAP) it ran in 8.10 ms. Once applies the removal
> of FPU regs handling, we get 7.05s. With the full series, we get 6.9s.
> If artificially re-activating FPU regs handling with the full series,
> we get 7.6s.
>
> So for the 8xx, the removal of the FPU regs copy is what makes the
> difference, but the rework of handle_signal also have a benefit.
>
> Same as above, without KUAP the difference is in the noise.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/signal_32.c | 224
> 1 file changed, 111 insertions(+), 113 deletions(-)
>
> diff --git a/arch/powerpc/kernel/signal_32.c
> b/arch/powerpc/kernel/signal_32.c
> index 86539a4e0514..f795fe0240a1 100644
> --- a/arch/powerpc/kernel/signal_32.c
> +++ b/arch/powerpc/kernel/signal_32.c
> @@ -93,8 +93,8 @@ static inline int get_sigset_t(sigset_t *set,
> #define to_user_ptr(p) ptr_to_compat(p)
> #define from_user_ptr(p) compat_ptr(p)
>
> -static inline int save_general_regs(struct pt_regs *regs,
> - struct mcontext __user *frame)
> +static __always_inline int
> +save_general_regs_unsafe(struct pt_regs *regs, struct mcontext __user
> *frame)
> {
> elf_greg_t64 *gregs = (elf_greg_t64 *)regs;
> int val, i;
> @@ -108,10 +108,12 @@ static inline int save_general_regs(struct pt_regs
> *regs,
> else
> val = gregs[i];
>
> - if (__put_user(val, >mc_gregs[i]))
> - return -EFAULT;
> + unsafe_put_user(val, >mc_gregs[i], failed);
> }
> return 0;
> +
> +failed:
> + return 1;
> }
>
> static inline int restore_general_regs(struct pt_regs *regs,
> @@ -148,11 +150,15 @@ static inline int get_sigset_t(sigset_t *set,
> const sigset_t __user *uset)
> #define to_user_ptr(p) ((unsigned long)(p))
> #define from_user_ptr(p) ((void __user *)(p))
>
> -static inline int save_general_regs(struct pt_regs *regs,
> - struct mcontext __user *frame)
> +static __always_inline int
> +save_general_regs_unsafe(struct pt_regs *regs, struct mcontext __user
> *frame)
> {
> WARN_ON(!FULL_REGS(regs));
> - return __copy_to_user(>mc_gregs, regs, GP_REGS_SIZE);
> + unsafe_copy_to_user(>mc_gregs, regs, GP_REGS_SIZE, failed);
> + return 0;
> +
> +failed:
> + return 1;
> }
>
> static inline int restore_general_regs(struct pt_regs *regs,
> @@ -170,6 +176,11 @@ static inline int restore_general_regs(struct
> pt_regs *regs,
> }
> #endif
>
> +#define unsafe_save_general_regs(regs, frame, label) do { \
> + if (save_general_regs_unsafe(regs, frame)) \
Minor nitpick (sorry); this naming seems a bit strange to me, in x86 it
is "__unsafe_" as a prefix instead of "_unsafe" as a suffix. That sounds
a bit better to me, what do you think? Unless there is some convention I
am not aware of here apart from "unsafe_" using a goto label for errors.
> + goto label; \
> +} while (0)
> +
> /*
> * When we have signals to deliver, we set up on the
> * user stack, going down from the original stack pointer:
> @@ -249,21 +260,19 @@ static void prepare_save_user_regs(int
> ctx_has_vsx_region)
> #endif
> }
>
> -static int save_user_regs(struct pt_regs *regs, struct mcontext __user
> *frame,
> - struct mcontext __user *tm_frame, int ctx_has_vsx_region)
> +static int save_user_regs_unsafe(struct pt_regs *regs, struct mcontext
> __user *frame,
> + struct mcontext __user *tm_frame, int ctx_has_vsx_region)
> {
> unsigned long msr = regs->msr;
>
> /* save general registers */
> - if (save_general_regs(regs, frame))
> - return 1;
> + unsafe_save_general_regs(regs, frame, failed);
>
> #ifdef CONFIG_ALTIVEC
> /* save altivec registers */
> if (current->thread.used_vr) {
> - if (__copy_to_user(>mc_vregs, >thread.vr_state,
> - ELF_NVRREG * sizeof(vector128)))
> - return 1;
> + unsafe_copy_to_user(>mc_vregs, >thread.vr_state,
> + ELF_NVRREG * sizeof(vector128), failed);
> /* set MSR_VEC in the saved MSR value to indicate that
> frame->mc_vregs contains valid data */
> msr |= MSR_VEC;
> @@ -276,11 +285,10 @@ static int save_user_regs(struct pt_regs *regs,
> struct mcontext __user *frame,
> * most significant bits of that same vector. --BenH
> * Note that the current VRSAVE value is in the SPR at this point.
> */
> - if (__put_user(current->thread.vrsave, (u32 __user
>
[PATCH v5] Introduce support for Systems Management Driver over WMI for Dell Systems
The Dell WMI Systems Management Driver provides a sysfs
interface for systems management to enable BIOS configuration
capability on certain Dell Systems.
This driver allows user to configure Dell systems with a
uniform common interface. To facilitate this, the patch
introduces a generic way for driver to be able to create
configurable BIOS Attributes available in Setup (F2) screen.
Cc: Hans de Goede
Cc: Andy Shevchenko
Cc: mark gross
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Prasanth KSR
Signed-off-by: Prasanth KSR
Signed-off-by: Divya Bharathi
---
Changes from v4 to v5:
- Correct Kconfig description to not use "WMI" twice.
- s/is_authentication_set/is_enabled/
- Specify that all attributes are optional and take UTF8
- Change authentication type to "role" and "mechanism"
- Explain what semicolons are
- Adjust whitespace of documentation
Changes from v3 to v4:
- Create a firmware-attributes class and tie ksets to a virtual device in it
- Make modifier and value_modifier "dell only" attributes.
- Correct some errors caught by kernel build bot around missing prototypes
- Remove mutexes from populate_* functions and put in
init_dell_bios_attrib_wmi instead
- Move all code into a subdirectory drivers/platform/x86/dell-wmi-sysman and
remove dell-wmi-*
prefix on files
- Move all data structures into shared struct
- In alloc functions instead of kzalloc use kcalloc and check that there is no
overflow
+ Same check for other alloc_foo-data functions
- populate_*: Move sysfs_create_group to end of the function to prevent race
conditions
- Save kernel object into each data instance and only remove that rather than
sysfs_remove_group
- Document in sysfs file what causes change uevents to come through
- Only notify with change uevent one time on multiple settings modifications
- Adjust lots of string handling
- Make more objects static
- Various whitespace corrections
- Document map_wmi_error properly
- Bump version to 5.11 (February 2021)
Changes from v2 to v3:
- Fix a possible NULL pointer error in init
- Add missing newlines to all dev_err/dev_dbg/pr_err/pr_debug statements
- Correct updating passwords when both Admin and System password are set
- Correct the WMI driver name
- Correct some namespace clashing when compiled into the kernel (Reported by
Mark Gross)
- Correct some comment typos
- Adopt suggestions made by Hans:
+ Use single global mutex
+ Clarify reason for uevents with a comment
+ Remove functions for set and get current password
+ Rename lower_bound to min_value and upper_bound to max_value
+ Rename possible_value to possible_values
+ Remove references to float
+ Build a separate passwords directory again since it behaves differently
from the other
attributes
+ Move more calls from pr_err -> dev_err
- Documentation cleanups (see v2 patch feedback)
+ Grouping types
+ Syntax of `modifier` output
Changes from v1 to v2:
- use pr_fmt instead of pr_err(DRIVER_NAME
- re-order variables reverse xmas tree order
- correct returns of -1 to error codes
- correct usage of {} on some split line statements
- Refine all documentation deficiencies suggested by Hans
- Merge all attributes to a single directory
- Overhaul WMI interface interaction as suggested by Hans
* Move WMI driver registration to start of module
* Remove usage of lists that only use first entry for WMI interfaces
* Create a global structure shared across interface source files
* Make get_current_password function static
* Remove get_pending changes function, shared across global structure now.
- Overhaul use of mutexes
* Make kset list mutex shared across source files
* Remove unneeded dell-wmi-sysman call_mutex
* Keep remaining call_mutexes in WMI functions
- Move security area calculation into a function
- Use NLS helper for utf8->utf16 conversion
.../testing/sysfs-class-firmware-attributes | 219 +++
MAINTAINERS | 8 +
drivers/platform/x86/Kconfig | 12 +
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/dell-wmi-sysman/Makefile | 8 +
.../x86/dell-wmi-sysman/biosattr-interface.c | 199 ++
.../x86/dell-wmi-sysman/dell-wmi-sysman.h | 195 ++
.../x86/dell-wmi-sysman/enum-attributes.c | 188 ++
.../x86/dell-wmi-sysman/int-attributes.c | 169 +
.../x86/dell-wmi-sysman/passobj-attributes.c | 171 +
.../dell-wmi-sysman/passwordattr-interface.c | 167 +
.../x86/dell-wmi-sysman/string-attributes.c | 156 +
drivers/platform/x86/dell-wmi-sysman/sysman.c | 589 ++
13 files changed, 2082 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-firmware-attributes
create mode 100644 drivers/platform/x86/dell-wmi-sysman/Makefile
create mode 100644 drivers/platform/x86/dell-wmi-sysman/biosattr-interface.c
create mode 100644
Re: [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel
On 2020/9/28 20:57, Geert Uytterhoeven wrote:
> Hi Zhen,
>
> On Mon, Sep 28, 2020 at 2:15 PM Ard Biesheuvel wrote:
>> On Mon, 28 Sep 2020 at 13:57, Leizhen (ThunderTown)
>> wrote:
>>> On 2020/9/28 18:14, Ard Biesheuvel wrote:
On Mon, 28 Sep 2020 at 11:27, Zhen Lei wrote:
>
> mov r4, pc
> and r4, r4, #0xf800 //truncated to 128MiB boundary
> add r4, r4, #TEXT_OFFSET//PA(_start)
>
> Currently, the decompressed kernel must be placed at the position: 128MiB
> boundary + TEXT_OFFSET. This limitation is just because we masked PC with
> 0xf8000. Actually, we can directly obtain PA(_start) by using formula
> : VA(_start) + (PHYS_OFFSET - PAGE_OFFSET).
>
> So the "PA(_start) - TEXT_OFFSET" can be 2MiB boundary, 1MiB boundary,
> and so on.
>
> Signed-off-by: Zhen Lei
No, this won't work.
>>>
>>> But it works well on my board.
>>>
>>
>> That is because you load zImage at the base of DRAM.
>>
The whole reason for rounding to a multiple of 128 MB is that we
cannot infer the start of DRAM from the placement of the zImage (which
provides _start).
>>>
>>> Maybe this is further guaranteed by the following code:
>>> /*
>>> * Set up a page table only if it won't overwrite ourself.
>>> * That means r4 < pc || r4 - 16k page directory > &_end.
>>> * Given that r4 > &_end is most unfrequent, we add a rough
>>> * additional 1MB of room for a possible appended DTB.
>>> */
>>>
>>> In addition, the Image has already been loaded when this position is
>>> reached.
>>>
>>> --- <--128MiB boundary
>>> | |
>>> --- <--TEXT_OFFSET <--
>>> | (1)Image | |
>>> |
>>> | | |
>>> --- (2)--copyto-
>>> | (2)Image |
>>> ---
>>>
>>> I don't think it's the case of (2), but (1). Because no code modification is
>>> required for the case (2).
>>>
>>> By the way, I'm not familiar with the arm32 code, so I'm just speculating.
>>>
>>
>> The zImage code that runs has not received *any* information from the
>> platform on where DRAM starts, so the only info it has is the current
>> placement of zImage.
>>
>> So when zImage is loaded at the intended base of DRAM, things work fine.
>>
>> If the zImage is loaded close to the end of a 128 MB region, the
>> rounding would pick the start of that 128 MB region. However, the
>> _start symbol you are using will point to an address that is close to
>> the end of the 128 MB [given that it is inside zImage] so your logic
>> will pick an address that is much higher in memory.
>
> https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses
> https://people.kernel.org/linusw/how-the-arm32-kernel-starts
> are good reads.
Thanks for your information.
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
> .
>
Re: [PATCH v8 05/11] dt-bindings: connector: Add property to set initial current cap for FRS
On Tue, Sep 22, 2020 at 9:04 AM Rob Herring wrote: > > On Mon, Sep 21, 2020 at 12:55:49PM -0700, Badhri Jagan Sridharan wrote: > > This change adds frs-typec-current which allows setting the initial current > > capability of the new source when vSafe5V is applied during PD3.0 > > sink Fast Role Swap. > > > > Signed-off-by: Badhri Jagan Sridharan > > --- > > Changes since v1: > > - Changing patch version to v6 to fix version number confusion. > > > > Changes since v6: > > - Removed the redundant usb-connector.txt that I created by mistake. > > - Moved to yaml. > > > > Changes since v7: > > - Rebase > > --- > > .../devicetree/bindings/connector/usb-connector.yaml | 8 > > include/dt-bindings/usb/pd.h | 10 ++ > > 2 files changed, 18 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > index 9bd52e63c935..1ca8e6a337e5 100644 > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > @@ -142,6 +142,14 @@ properties: > > required: > >- port@0 > > > > + frs-typec-current: > > +description: Initial current capability of the new source when vSafe5V > > + is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO > > - Sink" > > + of "USB Power Delivery Specification Revision 3.0, Version 1.2" > > provides the > > + different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C > > Current" > > + provides a detailed description of the field. > > +$ref: /schemas/types.yaml#/definitions/uint32 > > Looks the same/similar to this[1]. Please come up with a common > approach to cover both. > > Rob > > https://lore.kernel.org/linux-arm-kernel/20200902075707.9052-2-amelie.delau...@st.com/ Hi Rob, The values will not be an exact overlap as it's a different functionality. [1] introduces a property for defining the power operation mode for the type-c connector. However [2] introduces a property to define the new-source's current capability during Fast role swap operation. However, I modified [2] to use string based enums to follow the pattern in [1] in v9 version of the patch which I just sent out. 1. https://lore.kernel.org/linux-arm-kernel/20200902075707.9052-2-amelie.delau...@st.com/ 2. https://lore.kernel.org/patchwork/patch/1309792/ Thanks, Badhri
Re: [PATCH 2/5 V2] PCI: pciehp: check and wait port status out of DPC before handling DLLSC and PDC
On Tue, Sep 29, 2020 at 12:44 AM Sinan Kaya wrote:
>
> On 9/28/2020 7:10 AM, Sinan Kaya wrote:
> > On 9/27/2020 10:01 PM, Zhao, Haifeng wrote:
> >> Sinan,
> >>I explained the reason why locks don't protect this case in the patch
> >> description part.
> >> Write side and read side hold different semaphore and mutex.
> >>
> > I have been thinking about it some time but is there any reason why we
> > have to handle all port AER/DPC/HP events in different threads?
> >
> > Can we go to single threaded event loop for all port drivers events?
> >
> > This will require some refactoring but it wlll eliminate the lock
> > nightmares we are having.
> >
> > This means no sleeping. All sleeps need to happen outside of the loop.
> >
> > I wanted to see what you all are thinking about this.
> >
> > It might become a performance problem if the system is
> > continuously observing a hotplug/aer/dpc events.
> >
> > I always think that these should be rare events.
>
> If restructuring would be too costly, the preferred solution should be
> to fix the locks in hotplug driver rather than throwing there a random
> wait call.
My first though is to unify the pci_bus_sem & pci_rescan_remove_lock
to one sleepable lock, but verifying every
locking scenario to sort out dead lock warning, it is horrible job. I
gave up and then played the device status waiting trick
to workaround it.
index 03d37128a24f..477d4c499f87 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3223,17 +3223,19 @@ EXPORT_SYMBOL_GPL(pci_rescan_bus);
* pci_rescan_bus(), pci_rescan_bus_bridge_resize() and PCI device removal
* routines should always be executed under this mutex.
*/
-static DEFINE_MUTEX(pci_rescan_remove_lock);
+/* static DEFINE_MUTEX(pci_rescan_remove_lock); */
void pci_lock_rescan_remove(void)
{
- mutex_lock(_rescan_remove_lock);
+ /*mutex_lock(_rescan_remove_lock); */
+ down_write(_bus_sem);
}
EXPORT_SYMBOL_GPL(pci_lock_rescan_remove);
void pci_unlock_rescan_remove(void)
{
- mutex_unlock(_rescan_remove_lock);
+ /*mutex_unlock(_rescan_remove_lock); */
+ up_write(_bus_sem);
}
EXPORT_SYMBOL_GPL(pci_unlock_rescan_remove);
Thanks，
Ethan
[PATCH v6 1/1] dt-bindings: dw-apb-ictl: convert to json-schema
Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
binding to DT schema format using json-schema.
Signed-off-by: Zhen Lei
---
.../interrupt-controller/snps,dw-apb-ictl.txt | 43 --
.../interrupt-controller/snps,dw-apb-ictl.yaml | 68 ++
2 files changed, 68 insertions(+), 43 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
deleted file mode 100644
index 2db59df9408f4c6..000
---
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
-
-Synopsys DesignWare provides interrupt controller IP for APB known as
-dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
-APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
-controller in some SoCs, e.g. Hisilicon SD5203.
-
-Required properties:
-- compatible: shall be "snps,dw-apb-ictl"
-- reg: physical base address of the controller and length of memory mapped
- region starting with ENABLE_LOW register
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: number of cells to encode an interrupt-specifier, shall be
1
-
-Additional required property when it's used as secondary interrupt controller:
-- interrupts: interrupt reference to primary interrupt controller
-
-The interrupt sources map to the corresponding bits in the interrupt
-registers, i.e.
-- 0 maps to bit 0 of low interrupts,
-- 1 maps to bit 1 of low interrupts,
-- 32 maps to bit 0 of high interrupts,
-- 33 maps to bit 1 of high interrupts,
-- (optional) fast interrupts start at 64.
-
-Example:
- /* dw_apb_ictl is used as secondary interrupt controller */
- aic: interrupt-controller@3000 {
- compatible = "snps,dw-apb-ictl";
- reg = <0x3000 0xc00>;
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupt-parent = <>;
- interrupts = ;
- };
-
- /* dw_apb_ictl is used as primary interrupt controller */
- vic: interrupt-controller@1013 {
- compatible = "snps,dw-apb-ictl";
- reg = <0x1013 0x1000>;
- interrupt-controller;
- #interrupt-cells = <1>;
- };
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
new file mode 100644
index 000..33b3992d1c27c63
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
+
+maintainers:
+ - Sebastian Hesselbarth
+
+description: |
+ Synopsys DesignWare provides interrupt controller IP for APB known as
+ dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
+ with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
+ interrupt controller in some SoCs, e.g. Hisilicon SD5203.
+
+ The interrupt sources map to the corresponding bits in the interrupt
+ registers, i.e.
+ - 0 maps to bit 0 of low interrupts,
+ - 1 maps to bit 1 of low interrupts,
+ - 32 maps to bit 0 of high interrupts,
+ - 33 maps to bit 1 of high interrupts,
+ - (optional) fast interrupts start at 64.
+
+properties:
+ compatible:
+const: snps,dw-apb-ictl
+
+ interrupt-controller: true
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ "#interrupt-cells":
+const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+/* dw_apb_ictl is used as secondary interrupt controller */
+interrupt-controller@3000 {
+compatible = "snps,dw-apb-ictl";
+reg = <0x3000 0xc00>;
+interrupt-controller;
+#interrupt-cells = <1>;
+interrupt-parent = <>;
+interrupts = <0 3 4>;
+};
+
+/* dw_apb_ictl is used as primary interrupt controller */
+interrupt-controller@1013 {
+compatible = "snps,dw-apb-ictl";
+reg = <0x1013 0x1000>;
+interrupt-controller;
+#interrupt-cells = <1>;
+};
+...
--
1.8.3
[PATCH v6 0/1] irqchip: dw-apb-ictl: support hierarchy irq domain
v6 -- > v7
All other 5 patches are applied, this is the only one left. And it depends
on: https://www.spinics.net/lists/devicetree/msg379734.html
The modifications of this version are:
1. Remove the unneeded allOf. It's already selected based on node name.
allOf:
- $ref: /schemas/interrupt-controller.yaml#
2. Drop the descriptionss of the properties: reg, interrupts, #interrupt-cells.
They are common and not new to this binding.
3. add "additionalProperties: false"
4. remove the unused labels in "example:"
-aic: interrupt-controller@3000 {
-vic: interrupt-controller@1013 {
+interrupt-controller@3000 {
+interrupt-controller@1013 {
v5 --> v6:
1. add Reviewed-by: Rob Herring for Patch 4.
2. Some modifications are made to Patch 5:
1) add " |" for each "description:" property if its content exceeds one line,
to tell the yaml keep the "newline" character.
2) add "..." to mark the end of the yaml file.
3) Change the name list of maintainers to the author of
"snps,dw-apb-ictl.txt"
maintainers:
- - Marc Zyngier
+ - Sebastian Hesselbarth
4) add "maxItems: 1" for property "reg".
5) for property "interrupts":
interrupts:
-minItems: 1
-maxItems: 65
+maxItems: 1
6) move below descriptions under the top level property "description:"
description: |
Synopsys DesignWare provides interrupt controller IP for APB known as
dw_apb_ictl. The IP is used as secondary interrupt controller in some
SoCs
with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
interrupt controller in some SoCs, e.g. Hisilicon SD5203.
+ The interrupt sources map to the corresponding bits in the interrupt
+ registers, i.e.
+ - 0 maps to bit 0 of low interrupts,
+ - 1 maps to bit 1 of low interrupts,
+ - 32 maps to bit 0 of high interrupts,
+ - 33 maps to bit 1 of high interrupts,
+ - (optional) fast interrupts start at 64.
+
For more details of 2-6), please refer https://lkml.org/lkml/2020/9/24/13
v4 --> v5:
1. Add WARN_ON(1) in set_handle_irq() if !GENERIC_IRQ_MULTI_HANDLER
2. Convert "snps,dw-apb-ictl.txt" to "snps,dw-apb-ictl.yaml"
3. Fix the errors detected by "snps,dw-apb-ictl.yaml" on arch/arc
v3 --> v4:
1. remove "gc->chip_types[0].chip.irq_eoi = irq_gc_noop;", the "chip.irq_eoi"
hook
is not needed by handle_level_irq(). Thanks for Marc Zyngier's review.
2. Add a new patch: define an empty function set_handle_irq() if
!GENERIC_IRQ_MULTI_HANDLER
to avoid compilation error on arch/arc system.
v2 --> v3:
1. change (1 << hwirq) to BIT(hwirq).
2. change __exception_irq_entry to __irq_entry, so we can "#include
"
instead of "#include ". Ohterwise, an compilation error
will be
reported on arch/csky.
drivers/irqchip/irq-dw-apb-ictl.c:20:10: fatal error: asm/exception.h: No
such file or directory
3. use "if (!parent || (np == parent))" to determine whether it is primary
interrupt controller.
4. make the primary interrupt controller case also use function
handle_level_irq(), I used
handle_fasteoi_irq() as flow_handler before.
5. Other minor changes are not detailed.
v1 --> v2:
According to Marc Zyngier's suggestion, discard adding an independent SD5203-VIC
driver, but make the dw-apb-ictl irqchip driver to support hierarchy irq domain.
It was originally available only for secondary interrupt controller, now it can
also be used as primary interrupt controller. The related dt-bindings is updated
appropriately.
Add "Suggested-by: Marc Zyngier ".
Add "Tested-by: Haoyu Lv ".
v1:
The interrupt controller of SD5203 SoC is VIC(vector interrupt controller), it's
based on Synopsys DesignWare APB interrupt controller (dw_apb_ictl) IP, but it
can not directly use dw_apb_ictl driver. The main reason is that VIC is used as
primary interrupt controller and dw_apb_ictl driver worked for secondary
interrupt controller. So add a new driver: "hisilicon,sd5203-vic".
Zhen Lei (1):
dt-bindings: dw-apb-ictl: convert to json-schema
.../interrupt-controller/snps,dw-apb-ictl.txt | 43 --
.../interrupt-controller/snps,dw-apb-ictl.yaml | 68 ++
2 files changed, 68 insertions(+), 43 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
--
1.8.3
[tip:x86/irq] BUILD SUCCESS 981aa1d366bf46bdc1c9259a5ab818a8d522724e
allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20200928 x86_64 randconfig-a003-20200928 x86_64 randconfig-a004-20200928 x86_64 randconfig-a002-20200928 x86_64 randconfig-a006-20200928 x86_64 randconfig-a001-20200928 i386 randconfig-a006-20200928 i386 randconfig-a002-20200928 i386 randconfig-a003-20200928 i386 randconfig-a004-20200928 i386 randconfig-a005-20200928 i386 randconfig-a001-20200928 i386 randconfig-a002-20200927 i386 randconfig-a006-20200927 i386 randconfig-a003-20200927 i386 randconfig-a004-20200927 i386 randconfig-a005-20200927 i386 randconfig-a001-20200927 x86_64 randconfig-a011-20200927 x86_64 randconfig-a013-20200927 x86_64 randconfig-a014-20200927 x86_64 randconfig-a015-20200927 x86_64 randconfig-a012-20200927 x86_64 randconfig-a016-20200927 i386 randconfig-a012-20200928 i386 randconfig-a013-20200928 i386 randconfig-a011-20200928 i386 randconfig-a016-20200928 i386 randconfig-a014-20200928 i386 randconfig-a015-20200928 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a011-20200928 x86_64 randconfig-a013-20200928 x86_64 randconfig-a015-20200928 x86_64 randconfig-a014-20200928 x86_64 randconfig-a016-20200928 x86_64 randconfig-a012-20200928 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v8 05/11] dt-bindings: connector: Add property to set initial current cap for FRS
On Mon, Sep 28, 2020 at 1:57 AM Jun Li wrote: > > Badhri Jagan Sridharan 于2020年9月24日周四 下午6:09写道： > > > > Hi Jun, > > > > Thanks for the feedback ! > > The sink PDO from current source reflects the current source's(i.e. > > transmitter of the FRS signal) power requirement during fr swap. > > The current sink (i.e. receiver of the FRS signal) should check if it > > will be able to satisfy the current source's > > requirement during frswap before enabling the frs signal reception. > > The property in this patch refers to maximum current capability > > that the current sink can satisfy. > > In this case I agree a new property is required. > > Rob mentioned another similar property for typec[1], which is > for typec source(without power delivery) to define its power > capability to present its Rp, so a different usage. > > [1]https://lore.kernel.org/linux-arm-kernel/20200902075707.9052-2-amelie.delau...@st.com/ > > > Perhaps, I should name it > > sink-frs-typec-current. Does that make sense to you ? > > it looks better, thanks. Ended up naming it new-source-frs-type-ccurrent and have sent the v9 version of the patch. Thanks for you reviews ! > > Li Jun > > > > Thanks, > > Badhri > > > > On Wed, Sep 23, 2020 at 3:43 AM Jun Li wrote: > > > > > > Badhri Jagan Sridharan 于2020年9月22日周二 上午3:57写道： > > > > > > > > This change adds frs-typec-current which allows setting the initial > > > > current > > > > capability of the new source when vSafe5V is applied during PD3.0 > > > > sink Fast Role Swap. > > > > > > > > Signed-off-by: Badhri Jagan Sridharan > > > > --- > > > > Changes since v1: > > > > - Changing patch version to v6 to fix version number confusion. > > > > > > > > Changes since v6: > > > > - Removed the redundant usb-connector.txt that I created by mistake. > > > > - Moved to yaml. > > > > > > > > Changes since v7: > > > > - Rebase > > > > --- > > > > .../devicetree/bindings/connector/usb-connector.yaml | 8 > > > > include/dt-bindings/usb/pd.h | 10 ++ > > > > 2 files changed, 18 insertions(+) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > > b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > > index 9bd52e63c935..1ca8e6a337e5 100644 > > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > > @@ -142,6 +142,14 @@ properties: > > > > required: > > > >- port@0 > > > > > > > > + frs-typec-current: > > > > +description: Initial current capability of the new source when > > > > vSafe5V > > > > + is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply > > > > PDO - Sink" > > > > + of "USB Power Delivery Specification Revision 3.0, Version 1.2" > > > > provides the > > > > + different power levels and "6.4.1.3.1.6 Fast Role Swap USB > > > > Type-C Current" > > > > + provides a detailed description of the field. > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > > > If it's a part of sink PDO, I think you don't need a new property for > > > this, just > > > define it directly into sink-pdos by adding a new PDO define for PD 3.0, > > > something like: > > > > > > sink-pdos = > > FRS_CURRENT_1P5A)>; > > > > > > Li Jun > > > > + > > > > required: > > > >- compatible > > > > > > > > diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h > > > > index 985f2bbd4d24..db1ad4532197 100644 > > > > --- a/include/dt-bindings/usb/pd.h > > > > +++ b/include/dt-bindings/usb/pd.h > > > > @@ -35,6 +35,16 @@ > > > > > > > > #define VSAFE5V 5000 /* mv units */ > > > > > > > > +/* > > > > + * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power > > > > Delivery Specification Revision 3.0, > > > > + * Version 1.2" > > > > + * Initial current capability of the new source when vSafe5V is > > > > applied. > > > > + */ > > > > +#define FRS_NOT_SUPPORTED 0 > > > > +#define FRS_DEFAULT_POWER 1 > > > > +#define FRS_5V_1P5A2 > > > > +#define FRS_5V_3A 3 > > > > + > > > > #define PDO_BATT_MAX_VOLT_SHIFT20 /* 50mV units */ > > > > #define PDO_BATT_MIN_VOLT_SHIFT10 /* 50mV units */ > > > > #define PDO_BATT_MAX_PWR_SHIFT 0 /* 250mW units */ > > > > -- > > > > 2.28.0.681.g6f77f65b4e-goog > > > >
Re: [PATCH v8 03/11] dt-bindings: usb: Maxim type-c controller device tree binding document
On Tue, Sep 22, 2020 at 8:59 AM Rob Herring wrote: > > On Mon, 21 Sep 2020 12:55:47 -0700, Badhri Jagan Sridharan wrote: > > Add device tree binding document for Maxim TCPCI based Type-C chip driver > > > > Signed-off-by: Badhri Jagan Sridharan > > --- > > Changes since v1: > > - Changing patch version to v6 to fix version number confusion. > > > > Changes since v6: > > - Migrated to yaml format. > > > > Changes since v7: > > - Rebase on usb-next > > .../devicetree/bindings/usb/maxim,tcpci.yaml | 63 +++ > > 1 file changed, 63 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > Error: Documentation/devicetree/bindings/usb/maxim,tcpci.example.dts:38.36-37 > syntax error > FATAL ERROR: Unable to parse input tree > make[1]: *** [scripts/Makefile.lib:342: > Documentation/devicetree/bindings/usb/maxim,tcpci.example.dt.yaml] Error 1 > make[1]: *** Waiting for unfinished jobs > make: *** [Makefile:1366: dt_binding_check] Error 2 > > > See https://patchwork.ozlabs.org/patch/1368587 > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. > Fixed in v9 and have sent it out. Thanks, Badhri
[PATCH v9 12/15] usb: typec: tcpm: Parse frs type-c current from device tree
New source's current capability is now defined as string based
device tree property through new-source-frs-typec-current.
Refactor tcpm code to parse new-source-frs-typec-current and
infer local port's new source current capability during frs.
Signed-off-by: Badhri Jagan Sridharan
---
v9 is the first version of this patch in this series to rebase
TCPM code to read new source frs current from
new-source-frs-typec-current.
---
drivers/usb/typec/tcpm/tcpm.c | 41 +++
include/linux/usb/typec.h | 12 ++
2 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 02b7f623f584..d5a3e2b3bea2 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -180,16 +180,11 @@ enum adev_actions {
ADEV_ATTENTION,
};
-/*
- * Initial current capability of the new source when vSafe5V is applied during
PD3.0 Fast Role Swap.
- * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery
Specification Revision 3.0,
- * Version 1.2"
- */
-enum frs_typec_current {
- FRS_NOT_SUPPORTED,
- FRS_DEFAULT_POWER,
- FRS_5V_1P5A,
- FRS_5V_3A,
+static const char * const typec_new_source_frs_current[] = {
+ [FRS_NOT_SUPPORTED] = "not-supported",
+ [FRS_DEFAULT_POWER] = "default",
+ [FRS_5V_1P5A] = "1.5A",
+ [FRS_5V_3A] = "3.0A",
};
/* Events from low level driver */
@@ -364,7 +359,7 @@ struct tcpm_port {
bool self_powered;
/* FRS */
- enum frs_typec_current frs_current;
+ enum typec_new_source_frs_current new_source_frs_current;
/* Sink caps have been queried */
bool sink_cap_done;
@@ -1713,7 +1708,7 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
unsigned int cnt = pd_header_cnt_le(msg->header);
unsigned int rev = pd_header_rev_le(msg->header);
unsigned int i;
- enum frs_typec_current frs_current;
+ enum typec_new_source_frs_current partner_frs_current;
bool frs_enable;
int ret;
@@ -1786,12 +1781,13 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
for (i = 0; i < cnt; i++)
port->sink_caps[i] = le32_to_cpu(msg->payload[i]);
- frs_current = (port->sink_caps[0] & PDO_FIXED_FRS_CURR_MASK) >>
+ partner_frs_current = (port->sink_caps[0] &
PDO_FIXED_FRS_CURR_MASK) >>
PDO_FIXED_FRS_CURR_SHIFT;
- frs_enable = frs_current && (frs_current <= port->frs_current);
+ frs_enable = partner_frs_current && (partner_frs_current <=
+
port->new_source_frs_current);
tcpm_log(port,
"Port partner FRS capable partner_frs_current:%u
port_frs_current:%u enable:%c",
-frs_current, port->frs_current, frs_enable ? 'y' :
'n');
+partner_frs_current, port->new_source_frs_current,
frs_enable ? 'y' : 'n');
if (frs_enable) {
ret = port->tcpc->enable_frs(port->tcpc, true);
tcpm_log(port, "Enable FRS %s, ret:%d\n", ret ? "fail"
: "success", ret);
@@ -4746,7 +4742,8 @@ static int tcpm_fw_get_caps(struct tcpm_port *port,
{
const char *cap_str;
int ret;
- u32 mw, frs_current;
+ u32 mw;
+ const char *new_source_frs_current;
if (!fwnode)
return -EINVAL;
@@ -4817,9 +4814,15 @@ static int tcpm_fw_get_caps(struct tcpm_port *port,
/* FRS can only be supported byb DRP ports */
if (port->port_type == TYPEC_PORT_DRP) {
- ret = fwnode_property_read_u32(fwnode, "frs-typec-current",
_current);
- if (ret >= 0 && frs_current <= FRS_5V_3A)
- port->frs_current = frs_current;
+ ret = fwnode_property_read_string(fwnode,
"new-source-frs-typec-current",
+ _source_frs_current);
+ if (!ret) {
+ ret = match_string(typec_new_source_frs_current,
+
ARRAY_SIZE(typec_new_source_frs_current),
+ new_source_frs_current);
+ if (ret >= 0)
+ port->new_source_frs_current = ret;
+ }
}
return 0;
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 9cb1bec94b71..76bb078a433c 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -72,6 +72,18 @@ enum typec_orientation {
TYPEC_ORIENTATION_REVERSE,
};
+/*
+ * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery
Specification Revision 3.0,
+ * Version 1.2"
+ * Initial current capability of the new source when vSafe5V is applied.
[PATCH v9 08/15] usb: typec: tcpci_maxim: Add support for Sink FRS
Upon receiving ALERT_EXTENDED.TCPC_SINK_FAST_ROLE_SWAP signal
tcpm to start Sink fast role swap signal.
Inform when TCPM is sourcing vbus.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- rebase on usb-next
- Added Reviewed-by: Heikki
Changes since v7:
- Rebase on usb-next
Changes since v8:
- None.
---
drivers/usb/typec/tcpm/tcpci_maxim.c | 50 +---
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
b/drivers/usb/typec/tcpm/tcpci_maxim.c
index 91337ddb4962..723d7dd38f75 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
@@ -106,13 +106,22 @@ static void max_tcpci_init_regs(struct max_tcpci_chip
*chip)
return;
}
+ ret = max_tcpci_write8(chip, TCPC_ALERT_EXTENDED, 0xff);
+ if (ret < 0) {
+ dev_err(chip->dev, "Unable to clear TCPC_ALERT_EXTENDED
ret:%d\n", ret);
+ return;
+ }
+
alert_mask = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_DISCARDED |
TCPC_ALERT_TX_FAILED |
TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_RX_STATUS |
TCPC_ALERT_CC_STATUS |
- TCPC_ALERT_VBUS_DISCNCT | TCPC_ALERT_RX_BUF_OVF |
TCPC_ALERT_POWER_STATUS;
+ TCPC_ALERT_VBUS_DISCNCT | TCPC_ALERT_RX_BUF_OVF |
TCPC_ALERT_POWER_STATUS |
+ /* Enable Extended alert for detecting Fast Role Swap Signal */
+ TCPC_ALERT_EXTND;
ret = max_tcpci_write16(chip, TCPC_ALERT_MASK, alert_mask);
if (ret < 0) {
- dev_err(chip->dev, "Error writing to TCPC_ALERT_MASK ret:%d\n",
ret);
+ dev_err(chip->dev,
+ "Error enabling TCPC_ALERT: TCPC_ALERT_MASK write
failed ret:%d\n", ret);
return;
}
@@ -122,6 +131,10 @@ static void max_tcpci_init_regs(struct max_tcpci_chip
*chip)
dev_err(chip->dev, "Error writing to TCPC_POWER_CTRL ret:%d\n",
ret);
return;
}
+
+ ret = max_tcpci_write8(chip, TCPC_ALERT_EXTENDED_MASK,
TCPC_SINK_FAST_ROLE_SWAP);
+ if (ret < 0)
+ return;
}
static void process_rx(struct max_tcpci_chip *chip, u16 status)
@@ -225,10 +238,23 @@ static void process_power_status(struct max_tcpci_chip
*chip)
if (ret < 0)
return;
- if (pwr_status == 0xff)
+ if (pwr_status == 0xff) {
max_tcpci_init_regs(chip);
- else
+ } else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS) {
+ tcpm_sourcing_vbus(chip->port);
+ /*
+* Alawys re-enable boost here.
+* In normal case, when say an headset is attached, TCPM would
+* have instructed to TCPC to enable boost, so the call is a
+* no-op.
+* But for Fast Role Swap case, Boost turns on autonomously
without
+* AP intervention, but, needs AP to enable source mode
explicitly
+* for AP to regain control.
+*/
+ max_tcpci_set_vbus(chip->tcpci, >data, true, false);
+ } else {
tcpm_vbus_change(chip->port);
+ }
}
static void process_tx(struct max_tcpci_chip *chip, u16 status)
@@ -249,6 +275,7 @@ static irqreturn_t _max_tcpci_irq(struct max_tcpci_chip
*chip, u16 status)
{
u16 mask;
int ret;
+ u8 reg_status;
/*
* Clear alert status for everything except RX_STATUS, which shouldn't
@@ -274,6 +301,21 @@ static irqreturn_t _max_tcpci_irq(struct max_tcpci_chip
*chip, u16 status)
}
}
+ if (status & TCPC_ALERT_EXTND) {
+ ret = max_tcpci_read8(chip, TCPC_ALERT_EXTENDED, _status);
+ if (ret < 0)
+ return ret;
+
+ ret = max_tcpci_write8(chip, TCPC_ALERT_EXTENDED, reg_status);
+ if (ret < 0)
+ return ret;
+
+ if (reg_status & TCPC_SINK_FAST_ROLE_SWAP) {
+ dev_info(chip->dev, "FRS Signal");
+ tcpm_sink_frs(chip->port);
+ }
+ }
+
if (status & TCPC_ALERT_RX_STATUS)
process_rx(chip, status);
--
2.28.0.709.gb0816b6eb0-goog
[PATCH v9 06/15] usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)
PD 3.0 spec defines a new mechanism for power role swap called
Fast role swap. This change enables TCPM to support FRS when
acting as sink.
Once the explicit contract is negotiated, sink port is
expected to query the source port for sink caps to
determine whether the source is FRS capable.
Bits 23 & 24 of fixed pdo of the sink caps from the source, when
set, indicates the current needed by the source when fast role
swap is in progress(Implicit contract phasae). 0 indicates that
the source does not support Fast Role Swap.
Upon receiving the FRS signal from the source,
TCPC(TCPM_FRS_EVENT) informs TCPM to start the Fast role swap sequence.
1. TCPM sends FRS PD message: FR_SWAP_SEND
2. If response is not received within the expiry of
SenderResponseTimer, Error recovery is triggered.:
FR_SWAP_SEND_TIMEOUT
3. Upon receipt of the accept message, TCPM waits for
PSSourceOffTimer for PS_READY message from the partner:
FR_SWAP_SNK_SRC_NEW_SINK_READY.
TCPC is expected to autonomously turn on vbus once the FRS
signal is received and vbus voltage falls below vsafe5v within
tSrcFrSwap. This is different from traditional power role swap
where the vbus sourcing is turned on by TCPM.
4. By this time, TCPC most likely would have started to
source vbus, TCPM waits for tSrcFrSwap to see if the
lower level TCPC driver signals TCPM_SOURCING_VBUS event:
FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED.
5. When TCPC signals sourcing vbus, TCPM sends PS_READY msg and
changes the CC pin from Rd to Rp. This is the end of fast
role swap sequence and TCPM initiates the sequnce to negotiate
explicit contract by transitioning into SRC_STARTUP after
SwapSrcStart.
The code is written based on the sequence described in "Figure 8-107:
Dual-role Port in Sink to Source Fast Role Swap State Diagram" of
USB Power Delivery Specification Revision 3.0, Version 1.2.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
- Rebased on top of usb-next and resolved conflicts due to the below
changes:
3ed8e1c2ac99 usb: typec: tcpm: Migrate workqueue to RT priority for
processing events
6bbe2a90a0bb usb: typec: tcpm: During PR_SWAP, source caps should be sent
only after tSwapSourceStart
- enable_frs sequence is now run as part of the same kthread that runs
the state machines.
- Fixed the implicit fallthrough warning in the switch case for
FR_SWAP_CANCEL case.
Changes since v6:
- Moved frs_current from caps to tcpm_port as Heikki suggested.
Changes since v7:
- Added Reviewed-by: Heikki
Changes since v8:
- No change.
---
drivers/usb/typec/tcpm/tcpm.c | 229 +-
include/linux/usb/pd.h| 19 +--
include/linux/usb/tcpm.h | 8 +-
3 files changed, 244 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 92806547f485..55535c4f66bf 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -106,6 +106,13 @@
S(VCONN_SWAP_TURN_ON_VCONN),\
S(VCONN_SWAP_TURN_OFF_VCONN), \
\
+ S(FR_SWAP_SEND),\
+ S(FR_SWAP_SEND_TIMEOUT),\
+ S(FR_SWAP_SNK_SRC_TRANSITION_TO_OFF), \
+ S(FR_SWAP_SNK_SRC_NEW_SINK_READY), \
+ S(FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED), \
+ S(FR_SWAP_CANCEL), \
+ \
S(SNK_TRY), \
S(SNK_TRY_WAIT),\
S(SNK_TRY_WAIT_DEBOUNCE), \
@@ -127,6 +134,9 @@
S(GET_PPS_STATUS_SEND), \
S(GET_PPS_STATUS_SEND_TIMEOUT), \
\
+ S(GET_SINK_CAP),\
+ S(GET_SINK_CAP_TIMEOUT),\
+ \
S(ERROR_RECOVERY), \
S(PORT_RESET), \
S(PORT_RESET_WAIT_OFF)
@@ -170,11 +180,25 @@ enum adev_actions {
ADEV_ATTENTION,
};
+/*
+ * Initial current capability of the new source when vSafe5V is applied during
PD3.0 Fast Role Swap.
+ * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery
Specification Revision 3.0,
+ * Version 1.2"
+ */
+enum frs_typec_current {
+ FRS_NOT_SUPPORTED,
+ FRS_DEFAULT_POWER,
+ FRS_5V_1P5A,
+ FRS_5V_3A,
+};
+
/* Events from low level driver */
#define TCPM_CC_EVENT BIT(0)
#define TCPM_VBUS_EVENTBIT(1)
#define TCPM_RESET_EVENT BIT(2)
+#define TCPM_FRS_EVENT BIT(3)
+#define TCPM_SOURCING_VBUS BIT(4)
#define LOG_BUFFER_ENTRIES 1024
#define LOG_BUFFER_ENTRY_SIZE 128
@@ -184,6 +208,8 @@ enum adev_actions {
#define
Re: [RFC] process /proc/PID/smaps vs /proc/PID/smaps_rollup
On (20/09/29 11:05), Sergey Senozhatsky wrote: > Hello, > > One of our unprivileged daemon process needs process PSS info. That > info is usually available in /proc/PID/smaps on per-vma basis, on > in /proc/PID/smaps_rollup as a bunch of accumulated per-vma values. > The latter one is much faster and simpler to get, but, unlike smaps, > smaps_rollup requires PTRACE_MODE_READ, which we don't want to > grant to our unprivileged daemon. > > So the question is - can we get, somehow, accumulated PSS info from > a non-privileged process? (Iterating through all process' smaps > vma-s consumes quite a bit of CPU time). This is related to another > question - why do smaps and smaps_rollup have different permission > requirements? Hold on, seems that I misread something, /proc/PID/smaps is also unavailable. So the question is, then, how do we get PSS info of a random user-space process from an unprivileged daemon? -ss
[PATCH v9 14/15] usb: typec: tcpci: Implement Auto discharge disconnect callbacks
vImplement callbacks for enabling/disabling
POWER_CONTROL.AutoDischargeDisconnect.
Programs VBUS_SINK_DISCONNECT_THRESHOLD based on the
voltage requested as sink, mode of operation.
The programmed threshold is based on vSinkDisconnect and
vSinkDisconnectPD values.
Add auto_discharge_disconnect to tdata to allow TCPC chip
level drivers enable AutoDischargeDisconnect.
Signed-off-by: Badhri Jagan Sridharan
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Rebase on usb-next.
Changes since v7:
Heikki's suggestion:
- Moved the actual write to TCPC_VBUS_SINK_DISCONNECT_THRESH
as it's common to all chip drivers.
- Renaming the tcpci_data callback as
get_auto_vbus_discharge_threshold
Changes since v8:
- Removed get_auto_vbus_discharge_threshold callback and moved the logic
to program the default threshold for TCPC_VBUS_SINK_DISCONNECT_THRESH
into the TCPCI code.
---
drivers/usb/typec/tcpm/tcpci.c | 63 +-
drivers/usb/typec/tcpm/tcpci.h | 14 ++--
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index f91688e43991..12d983a75510 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -18,7 +18,10 @@
#include "tcpci.h"
-#define PD_RETRY_COUNT 3
+#definePD_RETRY_COUNT 3
+#defineAUTO_DISCHARGE_DEFAULT_THRESHOLD_MV 3500
+#defineAUTO_DISCHARGE_PD_HEADROOM_MV 850
+#defineAUTO_DISCHARGE_PPS_HEADROOM_MV 1250
struct tcpci {
struct device *dev;
@@ -268,6 +271,58 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool
enable)
enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
}
+static int tcpci_enable_auto_vbus_discharge(struct tcpc_dev *dev, bool enable)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+ int ret;
+
+ ret = regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
TCPC_POWER_CTRL_AUTO_DISCHARGE,
+enable ? TCPC_POWER_CTRL_AUTO_DISCHARGE : 0);
+ return ret;
+}
+
+static int tcpci_set_auto_vbus_discharge_threshold(struct tcpc_dev *dev, enum
typec_pwr_opmode mode,
+ bool pps_active, u32
requested_vbus_voltage_mv)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+ unsigned int pwr_ctrl, threshold = 0;
+ int ret;
+
+ /*
+* Indicates that vbus is going to go away due PR_SWAP, hard reset etc.
+* Do not discharge vbus here.
+*/
+ if (requested_vbus_voltage_mv == 0)
+ goto write_thresh;
+
+ ret = regmap_read(tcpci->regmap, TCPC_POWER_CTRL, _ctrl);
+ if (ret < 0)
+ return ret;
+
+ if (pwr_ctrl & TCPC_FAST_ROLE_SWAP_EN) {
+ /* To prevent disconnect when the source is fast role swap is
capable. */
+ threshold = AUTO_DISCHARGE_DEFAULT_THRESHOLD_MV;
+ } else if (mode == TYPEC_PWR_MODE_PD) {
+ if (pps_active)
+ threshold = (95 * requested_vbus_voltage_mv / 100) -
+ AUTO_DISCHARGE_PD_HEADROOM_MV;
+ else
+ threshold = (95 * requested_vbus_voltage_mv / 100) -
+ AUTO_DISCHARGE_PPS_HEADROOM_MV;
+ } else {
+ /* 3.5V for non-pd sink */
+ threshold = AUTO_DISCHARGE_DEFAULT_THRESHOLD_MV;
+ }
+
+ threshold = threshold / TCPC_VBUS_SINK_DISCONNECT_THRESH_LSB_MV;
+
+ if (threshold > TCPC_VBUS_SINK_DISCONNECT_THRESH_MAX)
+ return -EINVAL;
+
+write_thresh:
+ return tcpci_write16(tcpci, TCPC_VBUS_SINK_DISCONNECT_THRESH,
threshold);
+}
+
static int tcpci_enable_frs(struct tcpc_dev *dev, bool enable)
{
struct tcpci *tcpci = tcpc_to_tcpci(dev);
@@ -638,6 +693,12 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data)
tcpci->tcpc.enable_frs = tcpci_enable_frs;
tcpci->tcpc.frs_sourcing_vbus = tcpci_frs_sourcing_vbus;
+ if (tcpci->data->auto_discharge_disconnect) {
+ tcpci->tcpc.enable_auto_vbus_discharge =
tcpci_enable_auto_vbus_discharge;
+ tcpci->tcpc.set_auto_vbus_discharge_threshold =
+ tcpci_set_auto_vbus_discharge_threshold;
+ }
+
err = tcpci_parse_config(tcpci);
if (err < 0)
return ERR_PTR(err);
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index b418fe11b527..3fe313655f0c 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -8,6 +8,8 @@
#ifndef __LINUX_USB_TCPCI_H
#define __LINUX_USB_TCPCI_H
+#include
+
#define TCPC_VENDOR_ID 0x0
#define TCPC_PRODUCT_ID0x2
#define TCPC_BCD_DEV 0x4
@@ -67,6 +69,7 @@
[PATCH v9 15/15] usb: typec: tcpci_maxim: Enable auto discharge disconnect
Enable auto discharge disconnect for Maxim TCPC. Signed-off-by: Badhri Jagan Sridharan --- Changes since v1: - Changing patch version to v6 to fix version number confusion. Changes since v6: - Rebase on usb-next. Changes since v7: - Heikki's suggestion: Moved the actual write of TCPC_VBUS_SINK_DISCONNECT_THRES register to tcpci code. Changes since v8: - Moved the logic to program the default values of TCPC_VBUS_SINK_DISCONNECT_THRESH into the tcpci code. --- drivers/usb/typec/tcpm/tcpci_maxim.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c b/drivers/usb/typec/tcpm/tcpci_maxim.c index 43dcad95e897..55dea33387ec 100644 --- a/drivers/usb/typec/tcpm/tcpci_maxim.c +++ b/drivers/usb/typec/tcpm/tcpci_maxim.c @@ -441,6 +441,7 @@ static int max_tcpci_probe(struct i2c_client *client, const struct i2c_device_id chip->data.TX_BUF_BYTE_x_hidden = true; chip->data.init = tcpci_init; chip->data.frs_sourcing_vbus = max_tcpci_frs_sourcing_vbus; + chip->data.auto_discharge_disconnect = true; max_tcpci_init_regs(chip); chip->tcpci = tcpci_register_port(chip->dev, >data); -- 2.28.0.709.gb0816b6eb0-goog
[PATCH v9 13/15] usb: typec: tcpm: Implement enabling Auto Discharge disconnect support
TCPCI spec allows TCPC hardware to autonomously discharge the vbus
capacitance upon disconnect. The expectation is that the TCPM enables
AutoDischargeDisconnect while entering SNK/SRC_ATTACHED states. Hardware
then automously discharges vbus when the vbus falls below a certain
threshold i.e. VBUS_SINK_DISCONNECT_THRESHOLD.
Apart from enabling the vbus discharge circuit, AutoDischargeDisconnect
is also used a flag to move TCPCI based TCPC implementations into
Attached.Snk/Attached.Src state as mentioned in
Figure 4-15. TCPC State Diagram before a Connection of the
USB Type-C Port Controller Interface Specification.
In such TCPC implementations, setting AutoDischargeDisconnect would
prevent TCPC into entering "Connection_Invalid" state as well.
Signed-off-by: Badhri Jagan Sridharan
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Fixed incorrect data_role error that I introduced by mistake in
the previous version.
Changes since v7:
- Rebase on usb-next
Changes since v8:
- Removing the call to tcpm_set_auto_vbus_discharge_threshold
in the source path.
---
drivers/usb/typec/tcpm/tcpm.c | 60 ---
include/linux/usb/tcpm.h | 15 +
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index d5a3e2b3bea2..51a14d282109 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -1701,6 +1701,24 @@ static void tcpm_handle_alert(struct tcpm_port *port,
const __le32 *payload,
}
}
+static int tcpm_set_auto_vbus_discharge_threshold(struct tcpm_port *port,
+ enum typec_pwr_opmode mode,
bool pps_active,
+ u32 requested_vbus_voltage)
+{
+ int ret;
+
+ if (!port->tcpc->set_auto_vbus_discharge_threshold)
+ return 0;
+
+ ret = port->tcpc->set_auto_vbus_discharge_threshold(port->tcpc, mode,
pps_active,
+
requested_vbus_voltage);
+ tcpm_log_force(port,
+ "set_auto_vbus_discharge_threshold mode:%d pps_active:%c
vbus:%u ret:%d",
+ mode, pps_active ? 'y' : 'n', requested_vbus_voltage,
ret);
+
+ return ret;
+}
+
static void tcpm_pd_data_request(struct tcpm_port *port,
const struct pd_message *msg)
{
@@ -1871,6 +1889,10 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
port->current_limit,
port->supply_voltage);
port->explicit_contract = true;
+ tcpm_set_auto_vbus_discharge_threshold(port,
+
TYPEC_PWR_MODE_PD,
+
port->pps_data.active,
+
port->supply_voltage);
tcpm_set_state(port, SNK_READY, 0);
} else {
/*
@@ -2785,8 +2807,12 @@ static int tcpm_src_attach(struct tcpm_port *port)
if (ret < 0)
return ret;
- ret = tcpm_set_roles(port, true, TYPEC_SOURCE,
-tcpm_data_role_for_source(port));
+ if (port->tcpc->enable_auto_vbus_discharge) {
+ ret = port->tcpc->enable_auto_vbus_discharge(port->tcpc, true);
+ tcpm_log_force(port, "enable vbus discharge ret:%d", ret);
+ }
+
+ ret = tcpm_set_roles(port, true, TYPEC_SOURCE,
tcpm_data_role_for_source(port));
if (ret < 0)
return ret;
@@ -2853,6 +2879,12 @@ static void tcpm_unregister_altmodes(struct tcpm_port
*port)
static void tcpm_reset_port(struct tcpm_port *port)
{
+ int ret;
+
+ if (port->tcpc->enable_auto_vbus_discharge) {
+ ret = port->tcpc->enable_auto_vbus_discharge(port->tcpc, false);
+ tcpm_log_force(port, "Disable vbus discharge ret:%d", ret);
+ }
tcpm_unregister_altmodes(port);
tcpm_typec_disconnect(port);
port->attached = false;
@@ -2917,8 +2949,13 @@ static int tcpm_snk_attach(struct tcpm_port *port)
if (ret < 0)
return ret;
- ret = tcpm_set_roles(port, true, TYPEC_SINK,
-tcpm_data_role_for_sink(port));
+ if (port->tcpc->enable_auto_vbus_discharge) {
+ tcpm_set_auto_vbus_discharge_threshold(port,
TYPEC_PWR_MODE_USB, false, VSAFE5V);
+ ret = port->tcpc->enable_auto_vbus_discharge(port->tcpc, true);
+ tcpm_log_force(port, "enable vbus discharge ret:%d", ret);
+ }
+
+ ret = tcpm_set_roles(port, true,
[PATCH v9 04/15] usb: typec: tcpci_maxim: Chip level TCPC driver
Chip level TCPC driver for Maxim's TCPCI implementation.
This TCPC implementation does not support the following
commands: COMMAND.SinkVbus, COMMAND.SourceVbusDefaultVoltage,
COMMAND.SourceVbusHighVoltage. Instead the sinking and sourcing
from vbus is supported by writes to custom registers.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
- Removed setting USB_PSY and terminating description with period as
suggested by Randy.
Changes since v6:
- Addressed Heikki comments:
- Removed TX discarded message
- Removed the redundant TCPC_POWER_STATUS_UNINIT check
- Cleaned up irq setup routine
Changes since v7:
- Added reviewed-by: Heikki
Changes since v8:
- None
---
drivers/usb/typec/tcpm/Kconfig | 6 +
drivers/usb/typec/tcpm/Makefile | 15 +-
drivers/usb/typec/tcpm/tcpci.h | 1 +
drivers/usb/typec/tcpm/tcpci_maxim.c | 461 +++
4 files changed, 476 insertions(+), 7 deletions(-)
create mode 100644 drivers/usb/typec/tcpm/tcpci_maxim.c
diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index 58a64e1bf627..557f392fe24d 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -35,6 +35,12 @@ config TYPEC_MT6360
USB Type-C. It works with Type-C Port Controller Manager
to provide USB PD and USB Type-C functionalities.
+config TYPEC_TCPCI_MAXIM
+ tristate "Maxim TCPCI based Type-C chip driver"
+ help
+ MAXIM TCPCI based Type-C/PD chip driver. Works with
+ with Type-C Port Controller Manager.
+
endif # TYPEC_TCPCI
config TYPEC_FUSB302
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index 7592ccb8c526..7d499f3569fd 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -1,8 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
-obj-$(CONFIG_TYPEC_FUSB302)+= fusb302.o
-obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
-typec_wcove-y := wcove.o
-obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
-obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
-obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
+obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
+obj-$(CONFIG_TYPEC_FUSB302)+= fusb302.o
+obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
+typec_wcove-y := wcove.o
+obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
+obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
+obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
+obj-$(CONFIG_TYPEC_TCPCI_MAXIM)+= tcpci_maxim.o
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 4d441bdf24d5..82f021a82456 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -109,6 +109,7 @@
#define TCPC_RX_BYTE_CNT 0x30
#define TCPC_RX_BUF_FRAME_TYPE 0x31
+#define TCPC_RX_BUF_FRAME_TYPE_SOP 0
#define TCPC_RX_HDR0x32
#define TCPC_RX_DATA 0x34 /* through 0x4f */
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
b/drivers/usb/typec/tcpm/tcpci_maxim.c
new file mode 100644
index ..91337ddb4962
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020, Google LLC
+ *
+ * MAXIM TCPCI based TCPC driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tcpci.h"
+
+#define PD_ACTIVITY_TIMEOUT_MS 1
+
+#define TCPC_VENDOR_ALERT 0x80
+
+#define TCPC_RECEIVE_BUFFER_COUNT_OFFSET 0
+#define TCPC_RECEIVE_BUFFER_FRAME_TYPE_OFFSET 1
+#define TCPC_RECEIVE_BUFFER_RX_BYTE_BUF_OFFSET 2
+
+/*
+ * LongMessage not supported, hence 32 bytes for buf to be read from
RECEIVE_BUFFER.
+ * DEVICE_CAPABILITIES_2.LongMessage = 0, the value in READABLE_BYTE_COUNT reg
shall be
+ * less than or equal to 31. Since, RECEIVE_BUFFER len = 31 +
1(READABLE_BYTE_COUNT).
+ */
+#define TCPC_RECEIVE_BUFFER_LEN32
+
+#define MAX_BUCK_BOOST_SID 0x69
+#define MAX_BUCK_BOOST_OP 0xb9
+#define MAX_BUCK_BOOST_OFF 0
+#define MAX_BUCK_BOOST_SOURCE 0xa
+#define MAX_BUCK_BOOST_SINK0x5
+
+struct max_tcpci_chip {
+ struct tcpci_data data;
+ struct tcpci *tcpci;
+ struct device *dev;
+ struct i2c_client *client;
+ struct tcpm_port *port;
+};
+
+static const struct regmap_range max_tcpci_tcpci_range[] = {
+ regmap_reg_range(0x00, 0x95)
+};
+
+const struct regmap_access_table max_tcpci_tcpci_write_table = {
+ .yes_ranges
[PATCH v9 05/15] dt-bindings: connector: Add property to set initial current cap for FRS
This change adds frs-typec-current which allows setting the initial current capability of the new source when vSafe5V is applied during PD3.0 sink Fast Role Swap. Signed-off-by: Badhri Jagan Sridharan --- Changes since v1: - Changing patch version to v6 to fix version number confusion. Changes since v6: - Removed the redundant usb-connector.txt that I created by mistake. - Moved to yaml. Changes since v7: - Rebase Changes since v8: - Redefine new-source-frs-typec-current as string enums to address Rob Herring's comment. --- .../bindings/connector/usb-connector.yaml | 26 +++ include/dt-bindings/usb/pd.h | 10 +++ 2 files changed, 36 insertions(+) diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 9bd52e63c935..0b8cd08a8678 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -142,6 +142,32 @@ properties: required: - port@0 + new-source-frs-typec-current: +description: Initial current capability of the new source when vSafe5V + is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO - Sink" + of "USB Power Delivery Specification Revision 3.0, Version 1.2" provides the + different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C Current" + provides a detailed description of the field. The sink PDO from current source + reflects the current source's(i.e. transmitter of the FRS signal) power + requirement during fr swap. The current sink (i.e. receiver of the FRS signal), + a.k.a new source, should check if it will be able to satisfy the current source's, + new sink's, requirement during frswap before enabling the frs signal reception. + This property refers to maximum current capability that the current sink can + satisfy. During FRS, VBUS voltage is at 5V, as the partners are in implicit + contract, hence, the power level is only a function of the current capability. + "not-supported" implies sink to source fast role swap not supported. + "default" refers to default USB power level as described by + "Table 6-14 Fixed Supply PDO - Sink". + "1.5A" refers to 1.5A@5V. + "3.0A" refers to 3.0A@5V. + +$ref: /schemas/types.yaml#/definitions/string +enum: + - not-supported + - default + - 1.5A + - 3.0A + required: - compatible diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h index 985f2bbd4d24..db1ad4532197 100644 --- a/include/dt-bindings/usb/pd.h +++ b/include/dt-bindings/usb/pd.h @@ -35,6 +35,16 @@ #define VSAFE5V 5000 /* mv units */ +/* + * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery Specification Revision 3.0, + * Version 1.2" + * Initial current capability of the new source when vSafe5V is applied. + */ +#define FRS_NOT_SUPPORTED 0 +#define FRS_DEFAULT_POWER 1 +#define FRS_5V_1P5A2 +#define FRS_5V_3A 3 + #define PDO_BATT_MAX_VOLT_SHIFT20 /* 50mV units */ #define PDO_BATT_MIN_VOLT_SHIFT10 /* 50mV units */ #define PDO_BATT_MAX_PWR_SHIFT 0 /* 250mW units */ -- 2.28.0.709.gb0816b6eb0-goog
[PATCH v9 07/15] usb: typec: tcpci: Implement callbacks for FRS
Implement tcpc.enable_frs to enable TCPC to receive
Fast role swap signal.
Additionally set the sink disconnect threshold to 4v
to prevent disconnect during Fast Role swap.
Signed-off-by: Badhri Jagan Sridharan
Reviewed-by: Heikki Krogerus
---
Changes since v1:
- Changing patch version to v6 to fix version number confusion.
Changes since v6:
- Rebase on usb-next.
- Fixed formatting error.
- Added Reviewed-by: Heikki.
Changes since v7:
- Rebase on usb-next.
Changes since v8:
- None.
---
drivers/usb/typec/tcpm/tcpci.c | 17 +
drivers/usb/typec/tcpm/tcpci.h | 8
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index d6a6fac82d48..f9f0af64da5f 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -268,6 +268,22 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool
enable)
enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
}
+static int tcpci_enable_frs(struct tcpc_dev *dev, bool enable)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+ int ret;
+
+ /* To prevent disconnect during FRS, set disconnect threshold to 3.5V */
+ ret = tcpci_write16(tcpci, TCPC_VBUS_SINK_DISCONNECT_THRESH, enable ? 0
: 0x8c);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
TCPC_FAST_ROLE_SWAP_EN, enable ?
+TCPC_FAST_ROLE_SWAP_EN : 0);
+
+ return ret;
+}
+
static int tcpci_set_bist_data(struct tcpc_dev *tcpc, bool enable)
{
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
@@ -611,6 +627,7 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data)
tcpci->tcpc.set_roles = tcpci_set_roles;
tcpci->tcpc.pd_transmit = tcpci_pd_transmit;
tcpci->tcpc.set_bist_data = tcpci_set_bist_data;
+ tcpci->tcpc.enable_frs = tcpci_enable_frs;
err = tcpci_parse_config(tcpci);
if (err < 0)
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 82f021a82456..5ef07a56d67a 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -16,6 +16,7 @@
#define TCPC_PD_INT_REV0xa
#define TCPC_ALERT 0x10
+#define TCPC_ALERT_EXTND BIT(14)
#define TCPC_ALERT_EXTENDED_STATUS BIT(13)
#define TCPC_ALERT_VBUS_DISCNCTBIT(11)
#define TCPC_ALERT_RX_BUF_OVF BIT(10)
@@ -37,6 +38,9 @@
#define TCPC_EXTENDED_STATUS_MASK 0x16
#define TCPC_EXTENDED_STATUS_MASK_VSAFE0V BIT(0)
+#define TCPC_ALERT_EXTENDED_MASK 0x17
+#define TCPC_SINK_FAST_ROLE_SWAP BIT(0)
+
#define TCPC_CONFIG_STD_OUTPUT 0x18
#define TCPC_TCPC_CTRL 0x19
@@ -63,6 +67,7 @@
#define TCPC_POWER_CTRL0x1c
#define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0)
+#define TCPC_FAST_ROLE_SWAP_EN BIT(7)
#define TCPC_CC_STATUS 0x1d
#define TCPC_CC_STATUS_TOGGLINGBIT(5)
@@ -74,11 +79,14 @@
#define TCPC_POWER_STATUS 0x1e
#define TCPC_POWER_STATUS_UNINIT BIT(6)
+#define TCPC_POWER_STATUS_SOURCING_VBUSBIT(4)
#define TCPC_POWER_STATUS_VBUS_DET BIT(3)
#define TCPC_POWER_STATUS_VBUS_PRESBIT(2)
#define TCPC_FAULT_STATUS 0x1f
+#define TCPC_ALERT_EXTENDED0x21
+
#define TCPC_COMMAND 0x23
#define TCPC_CMD_WAKE_I2C 0x11
#define TCPC_CMD_DISABLE_VBUS_DETECT 0x22
--
2.28.0.709.gb0816b6eb0-goog
[PATCH v9 10/15] usb: typec: tcpci: frs sourcing vbus callback
During FRS hardware autonomously starts to source vbus. Provide
callback to perform chip specific operations.
Signed-off-by: Badhri Jagan Sridharan
---
v9 is the first version of this patch in the series. Added to fix
occasional bug of vbus turning back on when disconnecting the FRS accessory
after disconnect.
---
drivers/usb/typec/tcpm/tcpci.c | 9 +
drivers/usb/typec/tcpm/tcpci.h | 4
2 files changed, 13 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index f9f0af64da5f..f91688e43991 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -284,6 +284,14 @@ static int tcpci_enable_frs(struct tcpc_dev *dev, bool
enable)
return ret;
}
+static void tcpci_frs_sourcing_vbus(struct tcpc_dev *dev)
+{
+ struct tcpci *tcpci = tcpc_to_tcpci(dev);
+
+ if (tcpci->data->frs_sourcing_vbus)
+ tcpci->data->frs_sourcing_vbus(tcpci, tcpci->data);
+}
+
static int tcpci_set_bist_data(struct tcpc_dev *tcpc, bool enable)
{
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
@@ -628,6 +636,7 @@ struct tcpci *tcpci_register_port(struct device *dev,
struct tcpci_data *data)
tcpci->tcpc.pd_transmit = tcpci_pd_transmit;
tcpci->tcpc.set_bist_data = tcpci_set_bist_data;
tcpci->tcpc.enable_frs = tcpci_enable_frs;
+ tcpci->tcpc.frs_sourcing_vbus = tcpci_frs_sourcing_vbus;
err = tcpci_parse_config(tcpci);
if (err < 0)
diff --git a/drivers/usb/typec/tcpm/tcpci.h b/drivers/usb/typec/tcpm/tcpci.h
index 5ef07a56d67a..b418fe11b527 100644
--- a/drivers/usb/typec/tcpm/tcpci.h
+++ b/drivers/usb/typec/tcpm/tcpci.h
@@ -143,6 +143,9 @@
/*
* @TX_BUF_BYTE_x_hidden
* optional; Set when TX_BUF_BYTE_x can only be accessed through
I2C_WRITE_BYTE_COUNT.
+ * @frs_sourcing_vbus:
+ * Optional; Callback to perform chip specific operations when FRS
+ * is sourcing vbus.
*/
struct tcpci;
struct tcpci_data {
@@ -154,6 +157,7 @@ struct tcpci_data {
int (*start_drp_toggling)(struct tcpci *tcpci, struct tcpci_data *data,
enum typec_cc_status cc);
int (*set_vbus)(struct tcpci *tcpci, struct tcpci_data *data, bool
source, bool sink);
+ void (*frs_sourcing_vbus)(struct tcpci *tcpci, struct tcpci_data *data);
};
struct tcpci *tcpci_register_port(struct device *dev, struct tcpci_data *data);
--
2.28.0.709.gb0816b6eb0-goog
