Re: [PATCH] NFC: Fix error handling in rawsock_connect()
> … The patch fixes this issue. I suggest to replace this information by the tag “Fixes”. Please choose another imperative wording for your change description. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=df2fbf5bfa0e7fff8b4784507e4d68f200454318#n151 Regards, Markus
[tip:master] BUILD SUCCESS 2bef5106d9ae4b0b2612db2f477c4ab990dd44cb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 2bef5106d9ae4b0b2612db2f477c4ab990dd44cb Merge branch 'x86/entry' elapsed time: 482m configs tested: 111 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig armzeus_defconfig arm socfpga_defconfig pariscgeneric-64bit_defconfig mipsqi_lb60_defconfig arm ezx_defconfig arm pxa168_defconfig xtensa virt_defconfig arm moxart_defconfig arm zx_defconfig sh sh7770_generic_defconfig arm imote2_defconfig armclps711x_defconfig sh kfr2r09-romimage_defconfig arc nsimosci_hs_smp_defconfig xtensa iss_defconfig riscv rv32_defconfig c6xevmc6474_defconfig s390 zfcpdump_defconfig arcvdk_hs38_defconfig arc tb10x_defconfig openrisc allyesconfig arm efm32_defconfig powerpc pq2fads_defconfig arm tango4_defconfig c6xevmc6472_defconfig arm ixp4xx_defconfig i386 allyesconfig i386defconfig i386 debian-10.3 i386 allnoconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a015-20200612 i386 randconfig-a011-20200612 i386 randconfig-a014-20200612 i386 randconfig-a016-20200612 i386 randconfig-a013-20200612 i386 randconfig-a012-20200612 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um
[GIT PULL] iomap: bug fix for 5.8-rc1
Hi Linus, Please pull this single iomap bug fix for 5.8-rc1 that fixes a variable type mistake on 32-bit architectures. The branch merged cleanly with upstream head as of a few minutes ago. --D The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd: Linux 5.7-rc4 (2020-05-03 14:56:04 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-5.8-merge-1 for you to fetch changes up to d4ff3b2ef901cd451fb8a9ff4623d060a79502cd: iomap: Fix unsharing of an extent >2GB on a 32-bit machine (2020-06-08 20:58:29 -0700) New code for 5.8: - Fix an integer overflow problem in the unshare actor. Matthew Wilcox (Oracle) (1): iomap: Fix unsharing of an extent >2GB on a 32-bit machine fs/iomap/buffered-io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[GIT PULL] xfs: bug fixes for 5.8-rc1
Hi Linus, Please pull this last merge request before -rc1. We've settled down into the bugfix phase; this one fixes an error bailout path. This branch merges cleanly with master as of a few minutes ago, so please let me know if anything strange happens. --D The following changes since commit 6dcde60efd946e38fac8d276a6ca47492103e856: xfs: more lockdep whackamole with kmem_alloc* (2020-05-27 08:49:28 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.8-merge-9 for you to fetch changes up to 8cc0072469723459dc6bd7beff81b2b3149f4cf4: xfs: Add the missed xfs_perag_put() for xfs_ifree_cluster() (2020-06-08 20:57:03 -0700) Fixes for 5.8: - Fix a resource leak on an error bailout. Chuhong Yuan (1): xfs: Add the missed xfs_perag_put() for xfs_ifree_cluster() fs/xfs/xfs_inode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Re: [RFC PATCH] x86/msr: Filter MSR writes
On Fri, Jun 12, 2020 at 1:41 PM Peter Zijlstra wrote: > > On Fri, Jun 12, 2020 at 07:48:01PM +0200, Borislav Petkov wrote: > > On Fri, Jun 12, 2020 at 10:20:03AM -0700, Linus Torvalds wrote: > > > Since you already added the filtering, this looks fairly sane. > > > > > > IOW, what MSR's do we expect people to maybe write to normally? You > > > added MSR_IA32_ENERGY_PERF_BIAS as an allowed MST, maybe there are > > > others? > > > > Right, this MSR is being written by cpupower in tools/. My search was > > confined within the kernel source only so there very likely are others. > > So that tool writing to /dev/msr has already caused pain; the direct > result is that the intel pstate driver doesn't want to use an MSR shadow > variable to avoid RDMSR because that'd loose input. > > https://lkml.org/lkml/2019/3/25/310 > > (sorry, that's what google found me) > > So ideally we'd just disallow it too. It already has a sysfs file (per > those patches): > > Documentation/admin-guide/pm/intel_epb.rst Some group internal at Intel want something like this, but more extensive, They want to limit RDMSR to a subset (not exactly sure why, I don't know of MSRs that have side effects on read ... but then again not all of the MSR space is documented). On the write side they divide into categories: 1) Some MSRs can only be cleared. 2) Some MSRs can only have certain bits set 3) Some MSRs allow any write 4) Maybe something else ... this is from memory, and a somewhat cursory read of their patch. They have maybe a couple of dozen MSRs split between those classes. -Tony
Re: [GIT PULL] xfs: new code for 5.8 (now with fixed To line)
On Tue, Jun 02, 2020 at 07:40:35PM -0700, Linus Torvalds wrote: > On Tue, Jun 2, 2020 at 9:26 AM Darrick J. Wong wrote: > > > > fs/xfs/xfs_log_recover.c | 2561 > > ++-- > > 102 files changed, 4244 insertions(+), 4817 deletions(-) > > Interestingly, the changes to that xfs_log_recover.c file really seem > to break the default git diff algorithm (the linear-space Myers' > algorithm) > > The default settings give me > > fs/xfs/xfs_log_recover.c | 2801 > ++-- > 102 files changed, 4366 insertions(+), 4939 deletions(-) > > which is not very close to yours. With the extra effort "--minimal" I get > > fs/xfs/xfs_log_recover.c | 2561 > ++-- > 102 files changed, 4246 insertions(+), 4819 deletions(-) > > but based on your output, I suspect you used "--patience", which gives that > > fs/xfs/xfs_log_recover.c | 2561 > ++-- > 102 files changed, 4244 insertions(+), 4817 deletions(-) > > output (the difference there wrt minimal came from > fs/xfs/libxfs/xfs_symlink_remote.c). > > I'm used to seeing small differences in the line counts due to > different diff heuristics, but that 250 line difference for > "--patience" is more than you usually get. > > None of this matters, and I'm not at all suggesting you change any of > your workflow. One of the XFS developers suggested I experiment with --patience to see if it would make the diff output a little less eager to minimize the changed lines even at the expense of reviewability. The outcome is mostly identical, but there were a few places where using it really did help to try to keep basic code blocks together. --D > I'm just commenting because I was going "why am I not getting a > matching diffstat", and while I'm used to seeing small differences > from diff algorithms, that 240 line-count change was really a lot more > than I normally encounter. > > Linus >
Re: [GIT PULL] vfs: improve DAX behavior for 5.8, part 3
On Thu, Jun 11, 2020 at 11:00:43AM -0700, Linus Torvalds wrote:
> On Wed, Jun 10, 2020 at 7:43 PM Darrick J. Wong wrote:
> >
> > I did a test merge of this branch against upstream this evening and
> > there weren't any conflicts. The first five patches in the series were
> > already in the xfs merge, so it's only the last one that should change
> > anything. Please let us know if you have any complaints about pulling
> > this, since I can rework the branch.
>
> I've taken this, but I hate how the patches apparently got duplicated.
> It feels like they should have been a cleanly separated branch that
> was just pulled into whoever needed them when they were ready, rather
> than applied in two different places.
>
> So this is just a note for future work - duplicating the patches like
> this can cause annoyances down the line. No merge issues this time
> (they often happen when duplicate patches then have other work done on
> top of them), but things like "git bisect" now don't have quite as
> black-and-white a situation etc etc.,
>
> ("git bisect" will still find _one_ of the duplicate commits if it
> introduced a problem, so it's usually not a huge deal, but it can
> cause the bug to be then repeated if people revert that one, but
> nobody ever notices that the other commit that did the same thing is
> still around and it gets back-ported to stable or whatever..)
>
> So part of this is just in general about confusing duplicate history,
> and part of it is that the duplication can then cause later confusion.
Urgh, sorry. I /was/ careful to make sure the patches matched, but I'll
be more careful the next time this (hopefully never) happens again. :/
--D
> Linus
Re: RFC - kernel selftest result documentation (KTAP)
On Thu, Jun 11, 2020 at 2:11 AM Bird, Tim wrote: > > Some months ago I started work on a document to formalize how > kselftest implements the TAP specification. However, I didn't finish > that work. Maybe it's time to do so now. > > kselftest has developed a few differences from the original > TAP specification, and some extensions that I believe are worth > documenting. > > Essentially, we have created our own KTAP (kernel TAP) > format. I think it is worth documenting our conventions, in order to > keep everyone on the same page. > > Below is a partially completed document on my understanding > of KTAP, based on examination of some of the kselftest test > output. I have not reconciled this with the kunit output format, > which I believe has some differences (which maybe we should > resolve before we get too far into this). Thanks for doing this! This is something we've wanted to have for a while! On the KUnit side of things, we've not (intentionally) deviated too much from TAP/kselftest It's certainly our intention to hew as close as possible to what kselftest is doing: I don't think there are any real conflicts conceptually (at least at the moment), but we're almost certainly handling a few details differently. One other thing worth noting is that KUnit has a parser for our TAP results: './tools/testing/kunit/kunit.py parse' will do some basic parsing and print out results, a summary, etc. A few other comments below: > I submit the document now, before it is finished, because a patch > was recently introduced to alter one of the result conventions > (from SKIP='not ok' to SKIP='ok'). > > See the document include inline below > > == start of ktap-doc-rfc.txt == > Selftest preferred output format > > > The linux kernel selftest system uses TAP (Test Anything Protocol) > output to make testing results consumable by automated systems. A > number of Continuous Integration (CI) systems test the kernel every > day. It is useful for these systems that output from selftest > programs be consistent and machine-parsable. > > At the same time, it is useful for test results to be human-readable > as well. > > The kernel test result format is based on a variation TAP > TAP is a simple text-based format that is > documented on the TAP home page (http://testanything.org/). There > is an official TAP13 specification here: > http://testanything.org/tap-version-13-specification.html > > The kernel test result format consists of 5 major elements, > 4 of which are line-based: > * the output version line > * the plan line > * one or more test result lines (also called test result lines) > * a possible "Bail out!" line > > optional elements: > * diagnostic data > > The 5th element is diagnostic information, which is used to describe > items running in the test, and possibly to explain test results. > A sample test result is show below: > > Some other lines may be placed the test harness, and are not emitted > by individual test programs: > * one or more test identification lines > * a possible results summary line > > Here is an example: > > TAP version 13 > 1..1 > # selftests: cpufreq: main.sh > # pid 8101's current affinity mask: fff > # pid 8101's new affinity mask: 1 > ok 1 selftests: cpufreq: main.sh > > The output version line is: "TAP version 13" > > The test plan is "1..1". > > Element details > === > > Output version line > --- > The output version line is always "TAP version 13". > > Although the kernel test result format has some additions > to the TAP13 format, the version line reported by kselftest tests > is (currently) always the exact string "TAP version 13" > > This is always the first line of test output. KUnit is currently outputting "TAP version 14", as we were hoping some of our changes would get into the TAP14 spec. (Any comments, Brendan?) Maybe this should end up saying "KTAP version 1" or something? > Test plan line > -- > The test plan indicates the number of individual test cases intended to > be executed by the test. It always starts with "1.." and is followed > by the number of tests cases. In the example above, 1..1", indicates > that this test reports only 1 test case. > > The test plan line can be placed in two locations: > * the second line of test output, when the number of test cases is known >in advance > * as the last line of test output, when the number of test cases is not >known in advance. > > Most often, the number of test cases is known in advance, and the test plan > line appears as the second line of test output, immediately following > the output version line. The number of test cases might not be known > in advance if the number of tests is calculated from runtime data. > In this case, the test plan line is emitted as the last line of test > output. KUnit is currently including the test plan line only for subtests,
Re: [PATCH v6 10/12] mmap locking API: rename mmap_sem to mmap_lock
today test linux kernel master branch, I have kernel/sys.c build error. can you make a fix patch and push to linus? 2020-06-04 16:38 GMT+08:00, Michel Lespinasse : > On Thu, Jun 4, 2020 at 1:16 AM youling 257 wrote: >> 2020-06-04 13:57 GMT+08:00, Michel Lespinasse : >> > However I would like more information about your report. Did you apply >> > the series yourself ? If so, what base tree did you apply it onto ? If >> > not, what tree did you use that already included the series ? >> >> I build linux next-20200603 tree have the kernel/sys.c error. > > Thanks for the info. > > The proper fix is to replace down_write(>mmap_sem) with > mmap_write_lock(mm) and up_write(>mmap_sem) with > mmap_write_unlock(mm) > > If you just needed a quick fix to get the tree to build, what you did > (replacing mmap_sem with mmap_lock) is also fine. > > Thanks again ! > > -- > Michel "Walken" Lespinasse > A program is never fully debugged until the last user dies. >
[PATCH] drm/msm: Fix 0xfffflub in "Refactor address space initialization"
This week I started seeing GPU crashes on my DragonBoard 845c
which I narrowed down to being caused by commit ccac7ce373c1
("drm/msm: Refactor address space initialization").
Looking through the patch, Jordan and I couldn't find anything
obviously wrong, so I ended up breaking that change up into a
number of smaller logical steps so I could figure out which part
was causing the trouble.
Ends up, visually counting 'f's is hard, esp across a number
of lines:
0xfff != 0x
This patch corrects the end value we pass in to
msm_gem_address_space_create() in
adreno_iommu_create_address_space() so that it matches the value
used before the problematic patch landed.
With this change, I no longer see the GPU crashes that were
affecting me.
Cc: Shawn Guo
Cc: Rob Clark
Cc: Sean Paul
Cc: Jordan Crouse
Cc: freedr...@lists.freedesktop.org
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: John Stultz
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 89673c7ed473..3d4efe684a98 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -194,7 +194,7 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct msm_gem_address_space *aspace;
aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
- 0xfff);
+ 0x);
if (IS_ERR(aspace) && !IS_ERR(mmu))
mmu->funcs->destroy(mmu);
--
2.17.1
[tip:x86/entry] BUILD SUCCESS 0bf3924bfabd13ba21aa702344fc00b3b3263e5a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry branch HEAD: 0bf3924bfabd13ba21aa702344fc00b3b3263e5a x86/entry: Force rcu_irq_enter() when in idle task elapsed time: 481m configs tested: 115 configs skipped: 12 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig xtensa virt_defconfig arm moxart_defconfig arm zx_defconfig sh sh7770_generic_defconfig arm imote2_defconfig sh alldefconfig archsdk_defconfig mips cobalt_defconfig mipsbcm63xx_defconfig armclps711x_defconfig sh kfr2r09-romimage_defconfig arc nsimosci_hs_smp_defconfig xtensa iss_defconfig riscv rv32_defconfig c6xevmc6474_defconfig s390 debug_defconfig mipsar7_defconfig armkeystone_defconfig armmvebu_v7_defconfig arm assabet_defconfig sh urquell_defconfig powerpcamigaone_defconfig microblaze defconfig arm lpd270_defconfig arm efm32_defconfig powerpc pq2fads_defconfig arm tango4_defconfig c6xevmc6472_defconfig arm ixp4xx_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a015-20200612 i386 randconfig-a011-20200612 i386 randconfig-a014-20200612 i386 randconfig-a016-20200612 i386 randconfig-a013-20200612 i386 randconfig-a012-20200612 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64
linux-next: Tree for Jun 13
Hi all,
News: The merge window has opened, so please do *not* add v5.9 material
to your linux-next included branches until after v5.8-rc1 has been
released.
Changes since 20200612:
My fixes tree contains:
4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
The crypto-current tree gained a conflict against Linus' tree.
Non-merge commits (relative to Linus' tree): 1227
1743 files changed, 245681 insertions(+), 21966 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 324 trees (counting Linus' and 82 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (df2fbf5bfa0e Merge tag 'thermal-v5.8-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux)
Merging fixes/master (df8cb0ea9423 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (e4a42c82e943 kbuild: fix broken builds because of
GZIP,BZIP2,LZOP variables)
Merging arc-current/for-curr (9d9368e839c2 ARC: [arcompact] fix bitrot with 2
levels of interrupt)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag
'omap-for-v5.7/cpsw-fixes-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (ba051f097fc3 arm64/kernel: Fix return value
when cpu_online() fails in __cpu_up())
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length
array with flexible-array member)
Merging powerpc-fixes/fixes (e881bfaf5a5f KVM: PPC: Fix nested guest RC bits
update)
Merging s390-fixes/fixes (3d77e6a8804a Linux 5.7)
Merging sparc/master (af7b4801030c Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (6954a9e4192b ibmvnic: Flush existing work items before
device removal)
CONFLICT (content): Merge conflict in net/ipv4/tcp.c
Merging bpf/master (caf62492f479 libbpf: Support pre-initializing .bss global
variables)
Merging ipsec/master (a4902d914e50 xfrm: merge fixup for "remove output_finish
indirection from xfrm_state_afinfo")
Merging netfilter/master (c3829285b2e6 netfilter: nft_set_pipapo: Disable
preemption before getting per-CPU pointer)
Merging ipvs/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging wireless-drivers/master (f92f26f2ed2c iwlwifi: pcie: handle QuZ configs
with killer NICs as well)
Merging mac80211/master (59d4bfc1e2c0 net: fix wiki website url mac80211 and
wireless files)
Merging rdma-fixes/for-rc (3d77e6a8804a Linux 5.7)
Merging sound-current/for-linus (e7585db1b0b5 ALSA: usb-audio: Add implicit
feedback quirk for SSL2+.)
Merging sound-asoc-fixes/for-linus (cb79d5727661 Merge remote-tracking branch
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (7e295e6576af Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (dcf29f8ebd2d Merge remote-tracking branch
'regulator/for-5.8' into regulator-linus)
Merging spi-fixes/for-linus (a86cc4cfcd0b Merge remote-tracking branch
'spi/for-
Re: [PATCH v2 4/6] regulator: Add support for QCOM PMIC VBUS booster
On 6/12/20 4:19 PM, Wesley Cheng wrote: > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig > index 074a2ef55943..f9165f9f9051 100644 > --- a/drivers/regulator/Kconfig > +++ b/drivers/regulator/Kconfig > @@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI > Qualcomm SPMI PMICs as a module. The module will be named > "qcom_spmi-regulator". > > +config REGULATOR_QCOM_USB_VBUS > + tristate "Qualcomm USB Vbus regulator driver" > + depends on SPMI || COMPILE_TEST > + help > + If you say yes to this option, support will be included for the > + regulator used to enable the VBUS output. > + > + Say M here if you want to include support for enabling the VBUS output > + as a module. The module will be named "qcom_usb-regulator". Hi, Shouldn't that module name match what is in the Makefile? > + > config REGULATOR_RC5T583 > tristate "RICOH RC5T583 Power regulators" > depends on MFD_RC5T583 > diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile > index c0d6b96ebd78..cbab28aa7b56 100644 > --- a/drivers/regulator/Makefile > +++ b/drivers/regulator/Makefile > @@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o > obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o > obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o > obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o > +obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o > obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o > obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o > obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o thanks. -- ~Randy
[RESEND PATCH v10 04/10] scsi: ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk
Some UFS host controllers like Exynos uses granularities of PRDT length and
offset as bytes, whereas others uses actual segment count.
Reviewed-by: Avri Altman
Signed-off-by: Kiwoong Kim
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 30 +++---
drivers/scsi/ufs/ufshcd.h | 6 ++
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ee30ed6cc805..ba093d0d0942 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2151,8 +2151,14 @@ static int ufshcd_map_sg(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
return sg_segments;
if (sg_segments) {
- lrbp->utr_descriptor_ptr->prd_table_length =
- cpu_to_le16((u16)sg_segments);
+
+ if (hba->quirks & UFSHCD_QUIRK_PRDT_BYTE_GRAN)
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((sg_segments *
+ sizeof(struct ufshcd_sg_entry)));
+ else
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16) (sg_segments));
prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
@@ -3500,11 +3506,21 @@ static void ufshcd_host_memory_configure(struct ufs_hba
*hba)
cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
/* Response upiu and prdt offset should be in double words */
- utrdlp[i].response_upiu_offset =
- cpu_to_le16(response_offset >> 2);
- utrdlp[i].prd_table_offset = cpu_to_le16(prdt_offset >> 2);
- utrdlp[i].response_upiu_length =
- cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
+ if (hba->quirks & UFSHCD_QUIRK_PRDT_BYTE_GRAN) {
+ utrdlp[i].response_upiu_offset =
+ cpu_to_le16(response_offset);
+ utrdlp[i].prd_table_offset =
+ cpu_to_le16(prdt_offset);
+ utrdlp[i].response_upiu_length =
+ cpu_to_le16(ALIGNED_UPIU_SIZE);
+ } else {
+ utrdlp[i].response_upiu_offset =
+ cpu_to_le16(response_offset >> 2);
+ utrdlp[i].prd_table_offset =
+ cpu_to_le16(prdt_offset >> 2);
+ utrdlp[i].response_upiu_length =
+ cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
+ }
ufshcd_init_lrb(hba, >lrb[i], i);
}
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index f8d08cb9caf7..a9b9ace9fc72 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -535,6 +535,12 @@ enum ufshcd_quirks {
* enabled via HCE register.
*/
UFSHCI_QUIRK_BROKEN_HCE = 1 << 8,
+
+ /*
+* This quirk needs to be enabled if the host controller regards
+* resolution of the values of PRDTO and PRDTL in UTRD as byte.
+*/
+ UFSHCD_QUIRK_PRDT_BYTE_GRAN = 1 << 9,
};
enum ufshcd_caps {
--
2.17.1
[RESEND PATCH v10 02/10] scsi: ufs: add quirk to disallow reset of interrupt aggregation
Some host controllers support interrupt aggregation but don't allow
resetting counter and timer in software.
Reviewed-by: Avri Altman
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 3 ++-
drivers/scsi/ufs/ufshcd.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 3655b88fc862..0e9704da58bd 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4884,7 +4884,8 @@ static irqreturn_t ufshcd_transfer_req_compl(struct
ufs_hba *hba)
* false interrupt if device completes another request after resetting
* aggregation and before reading the DB.
*/
- if (ufshcd_is_intr_aggr_allowed(hba))
+ if (ufshcd_is_intr_aggr_allowed(hba) &&
+ !(hba->quirks & UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR))
ufshcd_reset_intr_aggr(hba);
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 071f0edf3f64..53096642f9a8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -523,6 +523,12 @@ enum ufshcd_quirks {
* Clear handling for transfer/task request list is just opposite.
*/
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR= 1 << 6,
+
+ /*
+* This quirk needs to be enabled if host controller doesn't allow
+* that the interrupt aggregation timer and counter are reset by s/w.
+*/
+ UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR = 1 << 7,
};
enum ufshcd_caps {
--
2.17.1
[RESEND PATCH v10 00/10] exynos-ufs: Add support for UFS HCI
This patch-set introduces UFS (Universal Flash Storage) host controller support for Samsung family SoC. Mostly, it consists of UFS PHY and host specific driver. - Changes since v9 * fixed the review comments by Rob on ufs dt bindings * Addeded Rob's reviwed-by tag on 08/10 patch - Changes since v8 * fixed make dt_binding_check error as pointed by Rob * Addressed review comments from Randy Dunlap - Changes since v7: * fixed review comments from Rob and Kishon * Addeded reviwed-by tags * rebased on top of v5.7-rc4 - Changes since v6: * Addressed review comments from Avri and Christoph * Added Reviewed-by tags of Avri and Can on various patches - Changes since v5: * re-introduce various quicks which was removed because of no driver * consumer of those quirks, initial 4 patches does the same. * Added Reviewed-by tags * rebased on top of v5.7-rc1 * included Kiwoong's patch in this series, which this driver needs - Changes since v4: * Addressed review comments from Avir and Rob * Minor improvment on the ufs phy and ufshc drivers * Added Tested-by from Pawel * Change UFS binding to DT schema format - Changes since v3: * Addressed Kishon's and Avir's review comments * fixed make dt_binding_check error as pointed by Rob - Changes since v2: * fixed build warning by kbuild test robot * Added Reported-by tags - Changes since v1: * fixed make dt_binding_check error as pointed by Rob * Addressed Krzysztof's review comments * Added Reviewed-by tags Note: This series is based on Linux-5.7-rc4 (commit: 0e698dfa2822) Alim Akhtar (9): scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr scsi: ufs: add quirk to disallow reset of interrupt aggregation scsi: ufs: add quirk to enable host controller without hce scsi: ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk dt-bindings: phy: Document Samsung UFS PHY bindings phy: samsung-ufs: add UFS PHY driver for samsung SoC dt-bindings: ufs: Add bindings for Samsung ufs host scsi: ufs-exynos: add UFS host support for Exynos SoCs arm64: dts: Add node for ufs exynos7 Kiwoong Kim (1): scsi: ufs: add quirk to fix abnormal ocs fatal error .../bindings/phy/samsung,ufs-phy.yaml | 75 + .../bindings/ufs/samsung,exynos-ufs.yaml | 89 ++ .../boot/dts/exynos/exynos7-espresso.dts |4 + arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 +- drivers/phy/samsung/Kconfig |9 + drivers/phy/samsung/Makefile |1 + drivers/phy/samsung/phy-exynos7-ufs.h | 86 ++ drivers/phy/samsung/phy-samsung-ufs.c | 380 + drivers/phy/samsung/phy-samsung-ufs.h | 143 ++ drivers/scsi/ufs/Kconfig | 12 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs-exynos.c | 1292 + drivers/scsi/ufs/ufs-exynos.h | 287 drivers/scsi/ufs/ufshcd.c | 126 +- drivers/scsi/ufs/ufshcd.h | 29 + drivers/scsi/ufs/unipro.h | 33 + 16 files changed, 2596 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml create mode 100644 Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml create mode 100644 drivers/phy/samsung/phy-exynos7-ufs.h create mode 100644 drivers/phy/samsung/phy-samsung-ufs.c create mode 100644 drivers/phy/samsung/phy-samsung-ufs.h create mode 100644 drivers/scsi/ufs/ufs-exynos.c create mode 100644 drivers/scsi/ufs/ufs-exynos.h base-commit: 0e698dfa282211e414076f9dc7e83c1c288314fd -- 2.17.1
[RESEND PATCH v10 07/10] phy: samsung-ufs: add UFS PHY driver for samsung SoC
This patch introduces Samsung UFS PHY driver. This driver
supports to deal with phy calibration and power control
according to UFS host driver's behavior.
Reviewed-by: Kiwoong Kim
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
Cc: Kishon Vijay Abraham I
Tested-by: Paweł Chmiel
---
drivers/phy/samsung/Kconfig | 9 +
drivers/phy/samsung/Makefile | 1 +
drivers/phy/samsung/phy-exynos7-ufs.h | 86 ++
drivers/phy/samsung/phy-samsung-ufs.c | 380 ++
drivers/phy/samsung/phy-samsung-ufs.h | 143 ++
5 files changed, 619 insertions(+)
create mode 100644 drivers/phy/samsung/phy-exynos7-ufs.h
create mode 100644 drivers/phy/samsung/phy-samsung-ufs.c
create mode 100644 drivers/phy/samsung/phy-samsung-ufs.h
diff --git a/drivers/phy/samsung/Kconfig b/drivers/phy/samsung/Kconfig
index 9e483d1fdaf2..fc1e3c17f842 100644
--- a/drivers/phy/samsung/Kconfig
+++ b/drivers/phy/samsung/Kconfig
@@ -29,6 +29,15 @@ config PHY_EXYNOS_PCIE
Enable PCIe PHY support for Exynos SoC series.
This driver provides PHY interface for Exynos PCIe controller.
+config PHY_SAMSUNG_UFS
+ tristate "SAMSUNG SoC series UFS PHY driver"
+ depends on OF && (ARCH_EXYNOS || COMPILE_TEST)
+ select GENERIC_PHY
+ help
+ Enable this to support the Samsung UFS PHY driver for
+ Samsung SoCs. This driver provides the interface for UFS
+ host controller to do PHY related programming.
+
config PHY_SAMSUNG_USB2
tristate "Samsung USB 2.0 PHY driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/samsung/Makefile b/drivers/phy/samsung/Makefile
index db9b1aa0de6e..3959100fe8a2 100644
--- a/drivers/phy/samsung/Makefile
+++ b/drivers/phy/samsung/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_PHY_EXYNOS_PCIE) += phy-exynos-pcie.o
+obj-$(CONFIG_PHY_SAMSUNG_UFS) += phy-samsung-ufs.o
obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
phy-exynos-usb2-y += phy-samsung-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
diff --git a/drivers/phy/samsung/phy-exynos7-ufs.h
b/drivers/phy/samsung/phy-exynos7-ufs.h
new file mode 100644
index ..c4aab792d30e
--- /dev/null
+++ b/drivers/phy/samsung/phy-exynos7-ufs.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * UFS PHY driver data for Samsung EXYNOS7 SoC
+ *
+ * Copyright (C) 2020 Samsung Electronics Co., Ltd.
+ */
+#ifndef _PHY_EXYNOS7_UFS_H_
+#define _PHY_EXYNOS7_UFS_H_
+
+#include "phy-samsung-ufs.h"
+
+#define EXYNOS7_EMBEDDED_COMBO_PHY_CTRL0x720
+#define EXYNOS7_EMBEDDED_COMBO_PHY_CTRL_MASK 0x1
+#define EXYNOS7_EMBEDDED_COMBO_PHY_CTRL_EN BIT(0)
+
+/* Calibration for phy initialization */
+static const struct samsung_ufs_phy_cfg exynos7_pre_init_cfg[] = {
+ PHY_COMN_REG_CFG(0x00f, 0xfa, PWR_MODE_ANY),
+ PHY_COMN_REG_CFG(0x010, 0x82, PWR_MODE_ANY),
+ PHY_COMN_REG_CFG(0x011, 0x1e, PWR_MODE_ANY),
+ PHY_COMN_REG_CFG(0x017, 0x84, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x035, 0x58, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x036, 0x32, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x037, 0x40, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x03b, 0x83, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x042, 0x88, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x043, 0xa6, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x048, 0x74, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x04c, 0x5b, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x04d, 0x83, PWR_MODE_ANY),
+ PHY_TRSV_REG_CFG(0x05c, 0x14, PWR_MODE_ANY),
+ END_UFS_PHY_CFG
+};
+
+static const struct samsung_ufs_phy_cfg exynos7_post_init_cfg[] = {
+ END_UFS_PHY_CFG
+};
+
+/* Calibration for HS mode series A/B */
+static const struct samsung_ufs_phy_cfg exynos7_pre_pwr_hs_cfg[] = {
+ PHY_COMN_REG_CFG(0x00f, 0xfa, PWR_MODE_HS_ANY),
+ PHY_COMN_REG_CFG(0x010, 0x82, PWR_MODE_HS_ANY),
+ PHY_COMN_REG_CFG(0x011, 0x1e, PWR_MODE_HS_ANY),
+ /* Setting order: 1st(0x16, 2nd(0x15) */
+ PHY_COMN_REG_CFG(0x016, 0xff, PWR_MODE_HS_ANY),
+ PHY_COMN_REG_CFG(0x015, 0x80, PWR_MODE_HS_ANY),
+ PHY_COMN_REG_CFG(0x017, 0x94, PWR_MODE_HS_ANY),
+ PHY_TRSV_REG_CFG(0x036, 0x32, PWR_MODE_HS_ANY),
+ PHY_TRSV_REG_CFG(0x037, 0x43, PWR_MODE_HS_ANY),
+ PHY_TRSV_REG_CFG(0x038, 0x3f, PWR_MODE_HS_ANY),
+ PHY_TRSV_REG_CFG(0x042, 0x88, PWR_MODE_HS_G2_SER_A),
+ PHY_TRSV_REG_CFG(0x042, 0xbb, PWR_MODE_HS_G2_SER_B),
+ PHY_TRSV_REG_CFG(0x043, 0xa6, PWR_MODE_HS_ANY),
+ PHY_TRSV_REG_CFG(0x048, 0x74, PWR_MODE_HS_ANY),
+ PHY_TRSV_REG_CFG(0x034, 0x35, PWR_MODE_HS_G2_SER_A),
+ PHY_TRSV_REG_CFG(0x034, 0x36, PWR_MODE_HS_G2_SER_B),
+ PHY_TRSV_REG_CFG(0x035, 0x5b, PWR_MODE_HS_G2_SER_A),
+ PHY_TRSV_REG_CFG(0x035, 0x5c,
[RESEND PATCH v10 03/10] scsi: ufs: add quirk to enable host controller without hce
Some host controllers don't support host controller enable via HCE.
Reviewed-by: Can Guo
Reviewed-by: Avri Altman
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 76 +--
drivers/scsi/ufs/ufshcd.h | 6
2 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0e9704da58bd..ee30ed6cc805 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3534,6 +3534,52 @@ static int ufshcd_dme_link_startup(struct ufs_hba *hba)
"dme-link-startup: error code %d\n", ret);
return ret;
}
+/**
+ * ufshcd_dme_reset - UIC command for DME_RESET
+ * @hba: per adapter instance
+ *
+ * DME_RESET command is issued in order to reset UniPro stack.
+ * This function now deal with cold reset.
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_dme_reset(struct ufs_hba *hba)
+{
+ struct uic_command uic_cmd = {0};
+ int ret;
+
+ uic_cmd.command = UIC_CMD_DME_RESET;
+
+ ret = ufshcd_send_uic_cmd(hba, _cmd);
+ if (ret)
+ dev_err(hba->dev,
+ "dme-reset: error code %d\n", ret);
+
+ return ret;
+}
+
+/**
+ * ufshcd_dme_enable - UIC command for DME_ENABLE
+ * @hba: per adapter instance
+ *
+ * DME_ENABLE command is issued in order to enable UniPro stack.
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_dme_enable(struct ufs_hba *hba)
+{
+ struct uic_command uic_cmd = {0};
+ int ret;
+
+ uic_cmd.command = UIC_CMD_DME_ENABLE;
+
+ ret = ufshcd_send_uic_cmd(hba, _cmd);
+ if (ret)
+ dev_err(hba->dev,
+ "dme-reset: error code %d\n", ret);
+
+ return ret;
+}
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba)
{
@@ -4251,7 +4297,7 @@ static inline void ufshcd_hba_stop(struct ufs_hba *hba,
bool can_sleep)
}
/**
- * ufshcd_hba_enable - initialize the controller
+ * ufshcd_hba_execute_hce - initialize the controller
* @hba: per adapter instance
*
* The controller resets itself and controller firmware initialization
@@ -4260,7 +4306,7 @@ static inline void ufshcd_hba_stop(struct ufs_hba *hba,
bool can_sleep)
*
* Returns 0 on success, non-zero value on failure
*/
-int ufshcd_hba_enable(struct ufs_hba *hba)
+static int ufshcd_hba_execute_hce(struct ufs_hba *hba)
{
int retry;
@@ -4308,6 +4354,32 @@ int ufshcd_hba_enable(struct ufs_hba *hba)
return 0;
}
+
+int ufshcd_hba_enable(struct ufs_hba *hba)
+{
+ int ret;
+
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_HCE) {
+ ufshcd_set_link_off(hba);
+ ufshcd_vops_hce_enable_notify(hba, PRE_CHANGE);
+
+ /* enable UIC related interrupts */
+ ufshcd_enable_intr(hba, UFSHCD_UIC_MASK);
+ ret = ufshcd_dme_reset(hba);
+ if (!ret) {
+ ret = ufshcd_dme_enable(hba);
+ if (!ret)
+ ufshcd_vops_hce_enable_notify(hba, POST_CHANGE);
+ if (ret)
+ dev_err(hba->dev,
+ "Host controller enable failed with
non-hce\n");
+ }
+ } else {
+ ret = ufshcd_hba_execute_hce(hba);
+ }
+
+ return ret;
+}
EXPORT_SYMBOL_GPL(ufshcd_hba_enable);
static int ufshcd_disable_tx_lcc(struct ufs_hba *hba, bool peer)
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 53096642f9a8..f8d08cb9caf7 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -529,6 +529,12 @@ enum ufshcd_quirks {
* that the interrupt aggregation timer and counter are reset by s/w.
*/
UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR = 1 << 7,
+
+ /*
+* This quirks needs to be enabled if host controller cannot be
+* enabled via HCE register.
+*/
+ UFSHCI_QUIRK_BROKEN_HCE = 1 << 8,
};
enum ufshcd_caps {
--
2.17.1
[RESEND PATCH v10 09/10] scsi: ufs-exynos: add UFS host support for Exynos SoCs
This patch introduces Exynos UFS host controller driver, which mainly handles vendor-specific operations including link startup, power mode change and hibernation/unhibernation. Reported-by: kbuild test robot Reported-by: Julia Lawall [robot: drivers/scsi/ufs/ufs-exynos.c:931:8-10: WARNING: possible condition with no effect (if == else) ] Reviewed-by: Kiwoong Kim Reviewed-by: Avri Altman Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar Tested-by: Paweł Chmiel --- drivers/scsi/ufs/Kconfig | 12 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs-exynos.c | 1292 + drivers/scsi/ufs/ufs-exynos.h | 287 drivers/scsi/ufs/unipro.h | 33 + 5 files changed, 1625 insertions(+) create mode 100644 drivers/scsi/ufs/ufs-exynos.c create mode 100644 drivers/scsi/ufs/ufs-exynos.h diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index e2005aeddc2d..7da886d3c323 100644 --- a/drivers/scsi/ufs/Kconfig +++ b/drivers/scsi/ufs/Kconfig @@ -160,3 +160,15 @@ config SCSI_UFS_BSG Select this if you need a bsg device node for your UFS controller. If unsure, say N. + +config SCSI_UFS_EXYNOS + bool "EXYNOS specific hooks to UFS controller platform driver" + depends on SCSI_UFSHCD_PLATFORM && (ARCH_EXYNOS || COMPILE_TEST) + select PHY_SAMSUNG_UFS + help + This selects the EXYNOS specific additions to UFSHCD platform driver. + UFS host on EXYNOS includes HCI and UNIPRO layer, and associates with + UFS-PHY driver. + + Select this if you have UFS host controller on EXYNOS chipset. + If unsure, say N. diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile index 94c6c5d7334b..f0c5b95ec9cc 100644 --- a/drivers/scsi/ufs/Makefile +++ b/drivers/scsi/ufs/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o tc-dwc-g210. obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o tc-dwc-g210.o obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o +obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o ufshcd-core-y += ufshcd.o ufs-sysfs.o ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c new file mode 100644 index ..440f2af83d9c --- /dev/null +++ b/drivers/scsi/ufs/ufs-exynos.c @@ -0,0 +1,1292 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * UFS Host Controller driver for Exynos specific extensions + * + * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd. + * Author: Seungwon Jeon + * Author: Alim Akhtar + * + */ + +#include +#include +#include +#include +#include +#include + +#include "ufshcd.h" +#include "ufshcd-pltfrm.h" +#include "ufshci.h" +#include "unipro.h" + +#include "ufs-exynos.h" + +/* + * Exynos's Vendor specific registers for UFSHCI + */ +#define HCI_TXPRDT_ENTRY_SIZE 0x00 +#define PRDT_PREFECT_ENBIT(31) +#define PRDT_SET_SIZE(x) ((x) & 0x1F) +#define HCI_RXPRDT_ENTRY_SIZE 0x04 +#define HCI_1US_TO_CNT_VAL 0x0C +#define CNT_VAL_1US_MASK 0x3FF +#define HCI_UTRL_NEXUS_TYPE0x40 +#define HCI_UTMRL_NEXUS_TYPE 0x44 +#define HCI_SW_RST 0x50 +#define UFS_LINK_SW_RSTBIT(0) +#define UFS_UNIPRO_SW_RST BIT(1) +#define UFS_SW_RST_MASK(UFS_UNIPRO_SW_RST | UFS_LINK_SW_RST) +#define HCI_DATA_REORDER 0x60 +#define HCI_UNIPRO_APB_CLK_CTRL0x68 +#define UNIPRO_APB_CLK(v, x) (((v) & ~0xF) | ((x) & 0xF)) +#define HCI_AXIDMA_RWDATA_BURST_LEN0x6C +#define HCI_GPIO_OUT 0x70 +#define HCI_ERR_EN_PA_LAYER0x78 +#define HCI_ERR_EN_DL_LAYER0x7C +#define HCI_ERR_EN_N_LAYER 0x80 +#define HCI_ERR_EN_T_LAYER 0x84 +#define HCI_ERR_EN_DME_LAYER 0x88 +#define HCI_CLKSTOP_CTRL 0xB0 +#define REFCLK_STOPBIT(2) +#define UNIPRO_MCLK_STOP BIT(1) +#define UNIPRO_PCLK_STOP BIT(0) +#define CLK_STOP_MASK (REFCLK_STOP |\ +UNIPRO_MCLK_STOP |\ +UNIPRO_PCLK_STOP) +#define HCI_MISC 0xB4 +#define REFCLK_CTRL_EN BIT(7) +#define UNIPRO_PCLK_CTRL_ENBIT(6) +#define UNIPRO_MCLK_CTRL_ENBIT(5) +#define HCI_CORECLK_CTRL_ENBIT(4) +#define CLK_CTRL_EN_MASK (REFCLK_CTRL_EN |\ +UNIPRO_PCLK_CTRL_EN |\ +UNIPRO_MCLK_CTRL_EN) +/* Device fatal error */ +#define DFES_ERR_ENBIT(31) +#define DFES_DEF_L2_ERRS (UIC_DATA_LINK_LAYER_ERROR_RX_BUF_OF |\ +UIC_DATA_LINK_LAYER_ERROR_PA_INIT) +#define DFES_DEF_L3_ERRS (UIC_NETWORK_UNSUPPORTED_HEADER_TYPE |\ +UIC_NETWORK_BAD_DEVICEID_ENC |\ +
[RESEND PATCH v10 05/10] scsi: ufs: add quirk to fix abnormal ocs fatal error
From: Kiwoong Kim
Some controller like Exynos determines if FATAL ERROR (0x7)
in OCS field in UTRD occurs for values other than GOOD (0x0)
in STATUS field in response upiu as well as errors that a
host controller can't cover.
This patch is to prevent from reporting command results in
those cases.
Signed-off-by: Kiwoong Kim
Signed-off-by: Alim Akhtar
Reviewed-by: Avri Altman
---
drivers/scsi/ufs/ufshcd.c | 6 ++
drivers/scsi/ufs/ufshcd.h | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ba093d0d0942..33ebffa8257d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4794,6 +4794,12 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
/* overall command status of utrd */
ocs = ufshcd_get_tr_ocs(lrbp);
+ if (hba->quirks & UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR) {
+ if (be32_to_cpu(lrbp->ucd_rsp_ptr->header.dword_1) &
+ MASK_RSP_UPIU_RESULT)
+ ocs = OCS_SUCCESS;
+ }
+
switch (ocs) {
case OCS_SUCCESS:
result = ufshcd_get_req_rsp(lrbp->ucd_rsp_ptr);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index a9b9ace9fc72..e1d09c2c4302 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -541,6 +541,12 @@ enum ufshcd_quirks {
* resolution of the values of PRDTO and PRDTL in UTRD as byte.
*/
UFSHCD_QUIRK_PRDT_BYTE_GRAN = 1 << 9,
+
+ /*
+* This quirk needs to be enabled if the host controller reports
+* OCS FATAL ERROR with device error through sense data
+*/
+ UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR = 1 << 10,
};
enum ufshcd_caps {
--
2.17.1
[RESEND PATCH v10 10/10] arm64: dts: Add node for ufs exynos7
Adding dt node foe UFS and UFS-PHY for exynos7 SoC.
Signed-off-by: Alim Akhtar
Tested-by: Paweł Chmiel
---
.../boot/dts/exynos/exynos7-espresso.dts | 4 ++
arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 7af288fa9475..790f12ca8981 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -406,6 +406,10 @@
};
};
+ {
+ status = "okay";
+};
+
_phy {
vbus-supply = <_vbus_reg>;
vbus-boost-supply = <_boost_5v>;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 5558045637ac..300ad7326ea8 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -220,9 +220,14 @@
#clock-cells = <1>;
clocks = <_pll>, <_top1 DOUT_ACLK_FSYS1_200>,
<_top1 DOUT_SCLK_MMC0>,
-<_top1 DOUT_SCLK_MMC1>;
+<_top1 DOUT_SCLK_MMC1>,
+<_top1 DOUT_SCLK_UFSUNIPRO20>,
+<_top1 DOUT_SCLK_PHY_FSYS1>,
+<_top1 DOUT_SCLK_PHY_FSYS1_26M>;
clock-names = "fin_pll", "dout_aclk_fsys1_200",
- "dout_sclk_mmc0", "dout_sclk_mmc1";
+ "dout_sclk_mmc0", "dout_sclk_mmc1",
+ "dout_sclk_ufsunipro20",
"dout_sclk_phy_fsys1",
+ "dout_sclk_phy_fsys1_26m";
};
serial_0: serial@1363 {
@@ -601,6 +606,40 @@
};
};
+ ufs: ufs@1557 {
+ compatible = "samsung,exynos7-ufs";
+ reg = <0x1557 0x100>, /* 0: HCI standard */
+ <0x15570100 0x100>, /* 1: Vendor specificed */
+ <0x15571000 0x200>, /* 2: UNIPRO */
+ <0x15572000 0x300>; /* 3: UFS protector */
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = ;
+ clocks = <_fsys1 ACLK_UFS20_LINK>,
+ <_fsys1 SCLK_UFSUNIPRO20_USER>;
+ clock-names = "core_clk", "sclk_unipro_main";
+ freq-table-hz = <0 0>, <0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_rst_n _refclk_out>;
+ phys = <_phy>;
+ phy-names = "ufs-phy";
+ status = "disabled";
+ };
+
+ ufs_phy: ufs-phy@15571800 {
+ compatible = "samsung,exynos7-ufs-phy";
+ reg = <0x15571800 0x240>;
+ reg-names = "phy-pma";
+ samsung,pmu-syscon = <_system_controller>;
+ #phy-cells = <0>;
+ clocks = <_fsys1 SCLK_COMBO_PHY_EMBEDDED_26M>,
+<_fsys1 PHYCLK_UFS20_RX1_SYMBOL_USER>,
+<_fsys1 PHYCLK_UFS20_RX0_SYMBOL_USER>,
+<_fsys1 PHYCLK_UFS20_TX0_SYMBOL_USER>;
+ clock-names = "ref_clk", "rx1_symbol_clk",
+ "rx0_symbol_clk",
+ "tx0_symbol_clk";
+ };
+
usbdrd_phy: phy@1550 {
compatible = "samsung,exynos7-usbdrd-phy";
reg = <0x1550 0x100>;
--
2.17.1
[RESEND PATCH v10 08/10] dt-bindings: ufs: Add bindings for Samsung ufs host
This patch adds DT bindings for Samsung ufs hci
Reviewed-by: Rob Herring
Signed-off-by: Alim Akhtar
---
.../bindings/ufs/samsung,exynos-ufs.yaml | 89 +++
1 file changed, 89 insertions(+)
create mode 100644
Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
new file mode 100644
index ..38193975c9f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/samsung,exynos-ufs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series UFS host controller Device Tree Bindings
+
+maintainers:
+ - Alim Akhtar
+
+description: |
+ Each Samsung UFS host controller instance should have its own node.
+ This binding define Samsung specific binding other then what is used
+ in the common ufshcd bindings
+ [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+
+properties:
+
+ compatible:
+enum:
+ - samsung,exynos7-ufs
+
+ reg:
+items:
+ - description: HCI register
+ - description: vendor specific register
+ - description: unipro register
+ - description: UFS protector register
+
+ reg-names:
+items:
+ - const: hci
+ - const: vs_hci
+ - const: unipro
+ - const: ufsp
+
+ clocks:
+items:
+ - description: ufs link core clock
+ - description: unipro main clock
+
+ clock-names:
+items:
+ - const: core_clk
+ - const: sclk_unipro_main
+
+ interrupts:
+maxItems: 1
+
+ phys:
+maxItems: 1
+
+ phy-names:
+const: ufs-phy
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - phys
+ - phy-names
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ufs: ufs@1557 {
+ compatible = "samsung,exynos7-ufs";
+ reg = <0x1557 0x100>,
+ <0x15570100 0x100>,
+ <0x15571000 0x200>,
+ <0x15572000 0x300>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = ;
+ clocks = <_fsys1 ACLK_UFS20_LINK>,
+<_fsys1 SCLK_UFSUNIPRO20_USER>;
+ clock-names = "core_clk", "sclk_unipro_main";
+ pinctrl-names = "default";
+ pinctrl-0 = <_rst_n _refclk_out>;
+ phys = <_phy>;
+ phy-names = "ufs-phy";
+};
+...
--
2.17.1
[RESEND PATCH v10 06/10] dt-bindings: phy: Document Samsung UFS PHY bindings
This patch documents Samsung UFS PHY device tree bindings
Reviewed-by: Rob Herring
Signed-off-by: Alim Akhtar
Tested-by: Paweł Chmiel
---
.../bindings/phy/samsung,ufs-phy.yaml | 75 +++
1 file changed, 75 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
new file mode 100644
index ..636cc501b54f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/samsung,ufs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series UFS PHY Device Tree Bindings
+
+maintainers:
+ - Alim Akhtar
+
+properties:
+ "#phy-cells":
+const: 0
+
+ compatible:
+enum:
+ - samsung,exynos7-ufs-phy
+
+ reg:
+maxItems: 1
+
+ reg-names:
+items:
+ - const: phy-pma
+
+ clocks:
+items:
+ - description: PLL reference clock
+ - description: symbol clock for input symbol ( rx0-ch0 symbol clock)
+ - description: symbol clock for input symbol ( rx1-ch1 symbol clock)
+ - description: symbol clock for output symbol ( tx0 symbol clock)
+
+ clock-names:
+items:
+ - const: ref_clk
+ - const: rx1_symbol_clk
+ - const: rx0_symbol_clk
+ - const: tx0_symbol_clk
+
+ samsung,pmu-syscon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description: phandle for PMU system controller interface, used to
+ control pmu registers bits for ufs m-phy
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - samsung,pmu-syscon
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+ufs_phy: ufs-phy@15571800 {
+compatible = "samsung,exynos7-ufs-phy";
+reg = <0x15571800 0x240>;
+reg-names = "phy-pma";
+samsung,pmu-syscon = <_system_controller>;
+#phy-cells = <0>;
+clocks = <_fsys1 SCLK_COMBO_PHY_EMBEDDED_26M>,
+ <_fsys1 PHYCLK_UFS20_RX1_SYMBOL_USER>,
+ <_fsys1 PHYCLK_UFS20_RX0_SYMBOL_USER>,
+ <_fsys1 PHYCLK_UFS20_TX0_SYMBOL_USER>;
+clock-names = "ref_clk", "rx1_symbol_clk",
+ "rx0_symbol_clk", "tx0_symbol_clk";
+
+};
+...
--
2.17.1
[RESEND PATCH v10 01/10] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
In the right behavior, setting the bit to '0' indicates clear and '1'
indicates no change. If host controller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.
Reviewed-by: Can Guo
Reviewed-by: Avri Altman
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 11 +--
drivers/scsi/ufs/ufshcd.h | 5 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 698e8d20b4ba..3655b88fc862 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -645,7 +645,11 @@ static inline int ufshcd_get_tr_ocs(struct ufshcd_lrb
*lrbp)
*/
static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
{
- ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos),
+ REG_UTP_TRANSFER_REQ_LIST_CLEAR);
}
/**
@@ -655,7 +659,10 @@ static inline void ufshcd_utrl_clear(struct ufs_hba *hba,
u32 pos)
*/
static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
{
- ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
}
/**
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 6ffc08ad85f6..071f0edf3f64 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -518,6 +518,11 @@ enum ufshcd_quirks {
* ops (get_ufs_hci_version) to get the correct version.
*/
UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION = 1 << 5,
+
+ /*
+* Clear handling for transfer/task request list is just opposite.
+*/
+ UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR= 1 << 6,
};
enum ufshcd_caps {
--
2.17.1
net boot error: BUG: using smp_processor_id() in preemptible code in ext4_mb_new_blocks
Hello, syzbot found the following crash on: HEAD commit:6954a9e4 ibmvnic: Flush existing work items before device .. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=1367d93910 kernel config: https://syzkaller.appspot.com/x/.config?x=b366fd92adf6f8b4 dashboard link: https://syzkaller.appspot.com/bug?extid=e10468d1d0662fdb7c8c compiler: gcc (GCC) 9.0.0 20181231 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e10468d1d0662fdb7...@syzkaller.appspotmail.com BUG: using smp_processor_id() in preemptible [] code: systemd-tmpfile/3971 caller is ext4_mb_new_blocks+0xa77/0x3b30 fs/ext4/mballoc.c:4711 CPU: 0 PID: 3971 Comm: systemd-tmpfile Not tainted 5.7.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] debug_smp_processor_id.cold+0x88/0x9b lib/smp_processor_id.c:57 ext4_mb_new_blocks+0xa77/0x3b30 fs/ext4/mballoc.c:4711 ext4_ext_map_blocks+0x2044/0x3410 fs/ext4/extents.c:4244 ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626 ext4_getblk+0xad/0x520 fs/ext4/inode.c:833 ext4_bread+0x7c/0x380 fs/ext4/inode.c:883 ext4_append+0x153/0x360 fs/ext4/namei.c:67 ext4_init_new_dir fs/ext4/namei.c:2757 [inline] ext4_mkdir+0x5e0/0xdf0 fs/ext4/namei.c:2802 vfs_mkdir+0x419/0x690 fs/namei.c:3627 do_mkdirat+0x21e/0x280 fs/namei.c:3650 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x7ffa928d3687 Code: 00 b8 ff ff ff ff c3 0f 1f 40 00 48 8b 05 09 d8 2b 00 64 c7 00 5f 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 d7 2b 00 f7 d8 64 89 01 48 RSP: 002b:7fff732d3c08 EFLAGS: 0246 ORIG_RAX: 0053 RAX: ffda RBX: 5637eeaceda0 RCX: 7ffa928d3687 RDX: RSI: 01ed RDI: 5637eeaceda0 RBP: 01ed R08: feff R09: 004c R10: 5637eeaced80 R11: 0246 R12: 0012 R13: 5637eeacf640 R14: R15: BUG: using smp_processor_id() in preemptible [] code: systemd-tmpfile/3971 caller is ext4_mb_new_blocks+0xa77/0x3b30 fs/ext4/mballoc.c:4711 CPU: 0 PID: 3971 Comm: systemd-tmpfile Not tainted 5.7.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] debug_smp_processor_id.cold+0x88/0x9b lib/smp_processor_id.c:57 ext4_mb_new_blocks+0xa77/0x3b30 fs/ext4/mballoc.c:4711 ext4_ext_map_blocks+0x2044/0x3410 fs/ext4/extents.c:4244 ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626 ext4_getblk+0xad/0x520 fs/ext4/inode.c:833 ext4_bread+0x7c/0x380 fs/ext4/inode.c:883 ext4_append+0x153/0x360 fs/ext4/namei.c:67 ext4_init_new_dir fs/ext4/namei.c:2757 [inline] ext4_mkdir+0x5e0/0xdf0 fs/ext4/namei.c:2802 vfs_mkdir+0x419/0x690 fs/namei.c:3627 do_mkdirat+0x21e/0x280 fs/namei.c:3650 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x7ffa928d3687 Code: 00 b8 ff ff ff ff c3 0f 1f 40 00 48 8b 05 09 d8 2b 00 64 c7 00 5f 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 d7 2b 00 f7 d8 64 89 01 48 RSP: 002b:7fff732d3c08 EFLAGS: 0246 ORIG_RAX: 0053 RAX: ffda RBX: 5637eead0870 RCX: 7ffa928d3687 RDX: RSI: 03ff RDI: 5637eead0870 RBP: 03ff R08: fec0 R09: 004c R10: 5637eead0840 R11: 0246 R12: 0012 R13: 5637eead0890 R14: R15: BUG: using smp_processor_id() in preemptible [] code: systemd-tmpfile/3971 caller is ext4_mb_new_blocks+0xa77/0x3b30 fs/ext4/mballoc.c:4711 CPU: 1 PID: 3971 Comm: systemd-tmpfile Not tainted 5.7.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] debug_smp_processor_id.cold+0x88/0x9b lib/smp_processor_id.c:57 ext4_mb_new_blocks+0xa77/0x3b30 fs/ext4/mballoc.c:4711 ext4_ext_map_blocks+0x2044/0x3410 fs/ext4/extents.c:4244 ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626 ext4_getblk+0xad/0x520 fs/ext4/inode.c:833 ext4_bread+0x7c/0x380 fs/ext4/inode.c:883 ext4_append+0x153/0x360 fs/ext4/namei.c:67 ext4_init_new_dir fs/ext4/namei.c:2757 [inline] ext4_mkdir+0x5e0/0xdf0 fs/ext4/namei.c:2802 vfs_mkdir+0x419/0x690 fs/namei.c:3627
Re: BUG: kernel NULL pointer dereference from check_preempt_wakeup()
On Tue, Jun 09, 2020 at 08:40:16AM -0700, Paul E. McKenney wrote:
> On Sun, Jun 07, 2020 at 11:57:32AM -0700, Paul E. McKenney wrote:
> > On Sat, Jun 06, 2020 at 10:29:42AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 05, 2020 at 05:51:26PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Jun 05, 2020 at 11:41:59AM -0700, Paul E. McKenney wrote:
> > > > > On Fri, Jun 05, 2020 at 07:16:07AM -0700, Paul E. McKenney wrote:
> > > > >
> > > > > And in case it is helpful, here is the output of "git bisect view",
> > > > > which lists rather more commits than "git bisect run" claims, but
> > > > > there
> > > > > are only a few scheduler commits below. I don't see anything that
> > > > > I can prove can cause this problem, but there are some that are at
> > > > > least related to this code path.
> > > > >
> > > > > Is there anything that is actually relevant?
> > > >
> > > > And the run with the WARN and tracing did hit two failures, and the
> > > > corresponding console logs are in the attached tarball. Both of them
> > > > triggered a warning as well as the failure.
> > >
> > > And the current state of the bisection, for whatever it is worth.
> >
> > The bisection finished, finally!
> >
> > 90b5363acd47 ("sched: Clean up scheduler_ipi()")
> >
> > I don't see anything immediately obvious, but then again, I do not
> > claim to understand this code. If you have additional diagnostics,
> > please let me know.
>
> But lockdep just might have spotted something useful.
> This was running the rcutorture SRCU-P scenario on
> mainline commit abfbb29297c2 ("Merge tag 'rproc-v5.8' of
> git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc").
> Unlike TREE03, SRCU-P enables lockdep.
>
> This splat features a couple of lockdep_assert_held() splats just before
> the mysterious NULL pointer dereference.
And an update based on your patch (https://paste.debian.net/1151802/)
against 44ebe016df3a ("Merge branch 'proc-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace").
Without your patch, 28 hours of rcutorture scenario TREE03 gets three NULL
pointer dereferences. With it, there are no NULL pointer dereferences,
but I did see one of these: https://paste.debian.net/1151842.
(Also shown below.)
Related or not, who knows? More as I learn more.
There is only a 5% chance of the result with your patch being a
false negative, so looking positive.
Thanx, Paul
[ 1669.614123] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 1669.615634] rcu: 13-...!: (20999 ticks this GP)
idle=fda/1/0x4002 softirq=234177/234177 fqs=0
[ 1669.618350] (t=21004 jiffies g=874585 q=4817)
[ 1669.619395] rcu: rcu_preempt kthread starved for 21005 jiffies! g874585 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
[ 1669.621920] rcu: Unless rcu_preempt kthread gets sufficient CPU time,
OOM is now expected behavior.
[ 1669.624060] rcu: RCU grace-period kthread stack dump:
[ 1669.625393] rcu_preempt I1505611 2 0x4000
[ 1669.626899] Call Trace:
[ 1669.627697] __schedule+0x25d/0x5d0
[ 1669.628475] ? _raw_spin_lock_irqsave+0x12/0x40
[ 1669.629620] schedule+0x37/0xe0
[ 1669.630404] schedule_timeout+0x109/0x210
[ 1669.631145] ? trace_raw_output_hrtimer_start+0x70/0x70
[ 1669.632069] rcu_gp_kthread+0x8e1/0x1260
[ 1669.632995] ? call_rcu+0x2d0/0x2d0
[ 1669.633881] kthread+0x138/0x160
[ 1669.634558] ? kthread_create_on_node+0x60/0x60
[ 1669.635536] ret_from_fork+0x22/0x30
[ 1669.636307] NMI backtrace for cpu 13
[ 1669.637257] CPU: 13 PID: 93 Comm: migration/13 Not tainted 5.7.0+ #18
[ 1669.638624] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.11.0-2.el7 04/01/2014
[ 1669.640360] Call Trace:
[ 1669.640913]
[ 1669.641371] dump_stack+0x57/0x70
[ 1669.642090] nmi_cpu_backtrace.cold.6+0x13/0x51
[ 1669.643066] ? lapic_can_unplug_cpu.cold.30+0x3e/0x3e
[ 1669.644298] nmi_trigger_cpumask_backtrace+0xc4/0xcd
[ 1669.645197] rcu_dump_cpu_stacks+0x96/0xc2
[ 1669.645884] rcu_sched_clock_irq.cold.86+0x118/0x506
[ 1669.646955] ? perf_event_task_tick+0x5f/0x280
[ 1669.648053] ? sched_clock+0x5/0x10
[ 1669.648788] ? cpuacct_account_field+0x14/0x70
[ 1669.649961] ? tick_switch_to_oneshot.cold.2+0x74/0x74
[ 1669.651599] update_process_times+0x1f/0x50
[ 1669.652862] tick_sched_timer+0x55/0x170
[ 1669.653685] __hrtimer_run_queues+0xfb/0x2c0
[ 1669.654669] hrtimer_interrupt+0x105/0x220
[ 1669.655696] smp_apic_timer_interrupt+0x7f/0x190
[ 1669.656700] apic_timer_interrupt+0xf/0x20
[ 1669.657384]
[ 1669.657831] RIP: 0010:stop_machine_yield+0x2/0x10
[ 1669.658554] Code: 0c 25 28 00 00 00 75 10 48 8d 65 f0 5b 41 5c 5d c3 b8 fe
ff ff ff eb e0 e8 ab c0 f4 ff 90 66 2e 0f 1f 84 00 00 00 00 00 f3 90 0f 1f
00 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 56 41 55 41 54
[ 1669.662249] RSP: :a7860039fe60 EFLAGS: 0246 ORIG_RAX:
[PATCH 0/5] LSM: Measure security module state
Critical data structures of security modules are currently not measured. Therefore an attestation service, for instance, would not be able to attest whether security modules are always operating with the policies and configuration that the system administrator had setup. The policies and configuration for the security modules could be tampered with by malware by exploiting Kernel vulnerabilities or modified through some inadvertent actions on the system. Measuring such critical data would enable an attestation service to better assess the state of the system. IMA measures system files, command line arguments passed to kexec, boot aggregate, keys, etc. It can be used to measure critical data structures of security modules as well. This change aims to address measuring critical data structures of security modules when they are initialized, when they are updated at runtime, and also periodically to detect any tampering. This change set is based off of Linux Kernel version 5.8-rc1 Lakshmi Ramasubramanian (5): IMA: Add LSM_STATE func to measure LSM data IMA: Define an IMA hook to measure LSM data LSM: Add security_state function pointer in lsm_info struct LSM: Define SELinux function to measure security state LSM: Define workqueue for measuring security module state Documentation/ABI/testing/ima_policy | 6 +- include/linux/ima.h | 4 ++ include/linux/lsm_hooks.h| 5 ++ security/integrity/ima/ima.h | 1 + security/integrity/ima/ima_api.c | 2 +- security/integrity/ima/ima_main.c| 30 + security/integrity/ima/ima_policy.c | 28 +++-- security/security.c | 91 +++- security/selinux/hooks.c | 43 + security/selinux/include/security.h | 2 + security/selinux/selinuxfs.c | 1 + 11 files changed, 205 insertions(+), 8 deletions(-) -- 2.27.0
[PATCH 4/5] LSM: Define SELinux function to measure security state
SELinux needs to implement the interface function, security_state(), for
the LSM to gather SELinux data for measuring. Define the security_state()
function in SELinux.
The security modules should be able to notify the LSM when there is
a change in the module's data. Define a function namely
security_state_change() in the LSM that the security modules
can call to provide the updated data for measurement.
Call security_state_change() function from SELinux to report data
when SELinux's state is updated.
Signed-off-by: Lakshmi Ramasubramanian
---
include/linux/lsm_hooks.h | 3 ++
security/security.c | 5
security/selinux/hooks.c| 43 +
security/selinux/include/security.h | 2 ++
security/selinux/selinuxfs.c| 1 +
5 files changed, 54 insertions(+)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index da248c3fd4ac..a63de046139e 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1572,6 +1572,9 @@ struct lsm_info {
int *state_len); /*Optional */
};
+/* Called by LSMs to notify security state change */
+extern void security_state_change(char *lsm_name, void *state, int state_len);
+
extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
extern struct lsm_info __start_early_lsm_info[], __end_early_lsm_info[];
diff --git a/security/security.c b/security/security.c
index a6e2d1cd95af..e7175db5a093 100644
--- a/security/security.c
+++ b/security/security.c
@@ -238,6 +238,11 @@ static void __init initialize_lsm(struct lsm_info *lsm)
}
}
+void security_state_change(char *lsm_name, void *state, int state_len)
+{
+ ima_lsm_state(lsm_name, state, state_len);
+}
+
static int measure_security_state(struct lsm_info *lsm)
{
char *lsm_name = NULL;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7e954b555be6..bbc908a1fcd1 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7225,6 +7225,47 @@ static __init int selinux_init(void)
return 0;
}
+static int selinux_security_state(char **lsm_name, void **state,
+ int *state_len)
+{
+ int rc = 0;
+ char *new_state;
+ static char *security_state_string = "enabled=%d;enforcing=%d";
+
+ *lsm_name = kstrdup("selinux", GFP_KERNEL);
+ if (!*lsm_name)
+ return -ENOMEM;
+
+ new_state = kzalloc(strlen(security_state_string) + 1, GFP_KERNEL);
+ if (!new_state) {
+ kfree(*lsm_name);
+ *lsm_name = NULL;
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ *state_len = sprintf(new_state, security_state_string,
+!selinux_disabled(_state),
+enforcing_enabled(_state));
+ *state = new_state;
+
+out:
+ return rc;
+}
+
+void notify_security_state_change(void)
+{
+ char *lsm_name = NULL;
+ void *state = NULL;
+ int state_len = 0;
+
+ if (!selinux_security_state(_name, , _len)) {
+ security_state_change(lsm_name, state, state_len);
+ kfree(state);
+ kfree(lsm_name);
+ }
+}
+
static void delayed_superblock_init(struct super_block *sb, void *unused)
{
selinux_set_mnt_opts(sb, NULL, 0, NULL);
@@ -7247,6 +7288,7 @@ DEFINE_LSM(selinux) = {
.enabled = _enabled_boot,
.blobs = _blob_sizes,
.init = selinux_init,
+ .security_state = selinux_security_state,
};
#if defined(CONFIG_NETFILTER)
@@ -7357,6 +7399,7 @@ int selinux_disable(struct selinux_state *state)
}
selinux_mark_disabled(state);
+ notify_security_state_change();
pr_info("SELinux: Disabled at runtime.\n");
diff --git a/security/selinux/include/security.h
b/security/selinux/include/security.h
index b0e02cfe3ce1..83c6ada45c7c 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -232,6 +232,8 @@ size_t security_policydb_len(struct selinux_state *state);
int security_policycap_supported(struct selinux_state *state,
unsigned int req_cap);
+void notify_security_state_change(void);
+
#define SEL_VEC_MAX 32
struct av_decision {
u32 allowed;
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 4781314c2510..8a5ba32a7775 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -173,6 +173,7 @@ static ssize_t sel_write_enforce(struct file *file, const
char __user *buf,
from_kuid(_user_ns, audit_get_loginuid(current)),
audit_get_sessionid(current));
enforcing_set(state, new_value);
+ notify_security_state_change();
if (new_value)
avc_ss_reset(state->avc, 0);
selnl_notify_setenforce(new_value);
--
[PATCH 1/5] IMA: Add LSM_STATE func to measure LSM data
Data provided by security modules need to be measured. A new IMA policy
is required for handling this measurement.
Define a new IMA policy func namely LSM_STATE to measure data provided
by security modules. Update ima_match_rules() to check for LSM_STATE
and ima_parse_rule() to handle LSM_STATE.
Signed-off-by: Lakshmi Ramasubramanian
---
Documentation/ABI/testing/ima_policy | 6 +-
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_policy.c | 28 +++-
4 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/ima_policy
b/Documentation/ABI/testing/ima_policy
index cd572912c593..355bc3eade33 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -29,7 +29,7 @@ Description:
base: func:=
[BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
- [KEXEC_CMDLINE] [KEY_CHECK]
+ [KEXEC_CMDLINE] [KEY_CHECK] [LSM_STATE]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
[[^]MAY_EXEC]
fsmagic:= hex value
@@ -125,3 +125,7 @@ Description:
keys added to .builtin_trusted_keys or .ima keyring:
measure func=KEY_CHECK
keyrings=.builtin_trusted_keys|.ima
+
+ Example of measure rule using LSM_STATE to measure LSM data:
+
+ measure func=LSM_STATE
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index df93ac258e01..58c62269028a 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -200,6 +200,7 @@ static inline unsigned int ima_hash_key(u8 *digest)
hook(POLICY_CHECK) \
hook(KEXEC_CMDLINE) \
hook(KEY_CHECK) \
+ hook(LSM_STATE) \
hook(MAX_CHECK)
#define __ima_hook_enumify(ENUM) ENUM,
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index bf22de8b7ce0..0cebd2404dcf 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -176,7 +176,7 @@ void ima_add_violation(struct file *file, const unsigned
char *filename,
* subj=, obj=, type=, func=, mask=, fsmagic=
* subj,obj, and type: are LSM specific.
* func: FILE_CHECK | BPRM_CHECK | CREDS_CHECK | MMAP_CHECK | MODULE_CHECK
- * | KEXEC_CMDLINE | KEY_CHECK
+ * | KEXEC_CMDLINE | KEY_CHECK | LSM_STATE
* mask: contains the permission mask
* fsmagic: hex value
*
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index e493063a3c34..1a6ee09e6993 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -417,15 +417,31 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
struct inode *inode,
const char *keyring)
{
int i;
+ int funcmatch = 0;
- if ((func == KEXEC_CMDLINE) || (func == KEY_CHECK)) {
+ switch (func) {
+ case KEXEC_CMDLINE:
+ case KEY_CHECK:
+ case LSM_STATE:
if ((rule->flags & IMA_FUNC) && (rule->func == func)) {
if (func == KEY_CHECK)
- return ima_match_keyring(rule, keyring, cred);
- return true;
- }
- return false;
+ funcmatch = ima_match_keyring(rule, keyring,
+ cred) ? 1 : -1;
+ else
+ funcmatch = 1;
+ } else
+ funcmatch = -1;
+
+ break;
+
+ default:
+ funcmatch = 0;
+ break;
}
+
+ if (funcmatch)
+ return (funcmatch == 1) ? true : false;
+
if ((rule->flags & IMA_FUNC) &&
(rule->func != func && func != POST_SETATTR))
return false;
@@ -1068,6 +1084,8 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
entry->func = KEXEC_CMDLINE;
else if (strcmp(args[0].from, "KEY_CHECK") == 0)
entry->func = KEY_CHECK;
+ else if (strcmp(args[0].from, "LSM_STATE") == 0)
+ entry->func = LSM_STATE;
else
result = -EINVAL;
if (!result)
--
2.27.0
[PATCH 3/5] LSM: Add security_state function pointer in lsm_info struct
The security modules that require their data to be measured need to
define a function that the LSM can call to gather the data.
Add a function pointer field namely security_state in lsm_info structure.
Update LSM to call this security module function, if defined, to gather
data and measure it by calling the IMA hook ima_lsm_state().
Signed-off-by: Lakshmi Ramasubramanian
---
include/linux/lsm_hooks.h | 2 ++
security/security.c | 60 ++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 3e62dab77699..da248c3fd4ac 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1568,6 +1568,8 @@ struct lsm_info {
int *enabled; /* Optional: controlled by CONFIG_LSM */
int (*init)(void); /* Required. */
struct lsm_blob_sizes *blobs; /* Optional: for blob sharing. */
+ int (*security_state)(char **lsm_name, void **state,
+ int *state_len); /*Optional */
};
extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
diff --git a/security/security.c b/security/security.c
index e0290b7e6a08..a6e2d1cd95af 100644
--- a/security/security.c
+++ b/security/security.c
@@ -86,6 +86,9 @@ static __initconst const char * const builtin_lsm_order =
CONFIG_LSM;
static __initdata struct lsm_info **ordered_lsms;
static __initdata struct lsm_info *exclusive;
+static struct lsm_info *security_state_lsms;
+static int security_state_lsms_count;
+
static __initdata bool debug;
#define init_debug(...)\
do {\
@@ -235,6 +238,57 @@ static void __init initialize_lsm(struct lsm_info *lsm)
}
}
+static int measure_security_state(struct lsm_info *lsm)
+{
+ char *lsm_name = NULL;
+ void *state = NULL;
+ int state_len = 0;
+ int rc;
+
+ if (!lsm->security_state)
+ return 0;
+
+ rc = lsm->security_state(_name, , _len);
+ if ((rc == 0) && (state_len > 0)) {
+ ima_lsm_state(lsm_name, state, state_len);
+ kfree(state);
+ kfree(lsm_name);
+ }
+
+ return rc;
+}
+
+static void __init initialize_security_state_lsms(void)
+{
+ struct lsm_info **lsm;
+ int count = 0;
+ int inx;
+
+ for (lsm = ordered_lsms; *lsm; lsm++) {
+ if ((*lsm)->security_state)
+ count++;
+ }
+
+ if (count == 0)
+ return;
+
+ security_state_lsms = kcalloc(count, sizeof(struct lsm_info),
+ GFP_KERNEL);
+ if (!security_state_lsms)
+ return;
+
+ inx = 0;
+ for (lsm = ordered_lsms; *lsm; lsm++) {
+ if ((*lsm)->security_state) {
+ security_state_lsms[inx].security_state =
+ (*lsm)->security_state;
+ inx++;
+ }
+ }
+
+ security_state_lsms_count = count;
+}
+
/* Populate ordered LSMs list from comma-separated LSM name list. */
static void __init ordered_lsm_parse(const char *order, const char *origin)
{
@@ -352,8 +406,12 @@ static void __init ordered_lsm_init(void)
lsm_early_cred((struct cred *) current->cred);
lsm_early_task(current);
- for (lsm = ordered_lsms; *lsm; lsm++)
+ for (lsm = ordered_lsms; *lsm; lsm++) {
initialize_lsm(*lsm);
+ measure_security_state(*lsm);
+ }
+
+ initialize_security_state_lsms();
kfree(ordered_lsms);
}
--
2.27.0
[PATCH 5/5] LSM: Define workqueue for measuring security module state
The data maintained by the security modules could be tampered with by
malware. The LSM needs to periodically query the state of
the security modules and measure the data when the state is changed.
Define a workqueue for handling this periodic query and measurement.
Signed-off-by: Lakshmi Ramasubramanian
---
security/security.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/security.c b/security/security.c
index e7175db5a093..3dad6766cb9d 100644
--- a/security/security.c
+++ b/security/security.c
@@ -89,6 +89,11 @@ static __initdata struct lsm_info *exclusive;
static struct lsm_info *security_state_lsms;
static int security_state_lsms_count;
+static long security_state_timeout = 30; /* 5 Minutes */
+static void security_state_handler(struct work_struct *work);
+static DECLARE_DELAYED_WORK(security_state_delayed_work,
+ security_state_handler);
+
static __initdata bool debug;
#define init_debug(...)\
do {\
@@ -294,6 +299,26 @@ static void __init initialize_security_state_lsms(void)
security_state_lsms_count = count;
}
+static void initialize_security_state_monitor(void)
+{
+ if (security_state_lsms_count == 0)
+ return;
+
+ schedule_delayed_work(_state_delayed_work,
+ msecs_to_jiffies(security_state_timeout));
+}
+
+static void security_state_handler(struct work_struct *work)
+{
+ int inx;
+
+ for (inx = 0; inx < security_state_lsms_count; inx++)
+ measure_security_state(&(security_state_lsms[inx]));
+
+ schedule_delayed_work(_state_delayed_work,
+ msecs_to_jiffies(security_state_timeout));
+}
+
/* Populate ordered LSMs list from comma-separated LSM name list. */
static void __init ordered_lsm_parse(const char *order, const char *origin)
{
@@ -417,6 +442,7 @@ static void __init ordered_lsm_init(void)
}
initialize_security_state_lsms();
+ initialize_security_state_monitor();
kfree(ordered_lsms);
}
--
2.27.0
[PATCH 2/5] IMA: Define an IMA hook to measure LSM data
LSM requires an IMA hook to be defined by the IMA subsystem to measure
the data gathered from the security modules.
Define a new IMA hook, namely ima_lsm_state(), that the LSM will call
to measure the data gathered from the security modules.
Sample IMA log entry for LSM measurement:
10 47eed9... ima-buf sha256:402f6b... lsm-state:selinux
656e61626c65643d313b656e666f7263696e673d30
Signed-off-by: Lakshmi Ramasubramanian
---
include/linux/ima.h | 4
security/integrity/ima/ima_main.c | 30 ++
2 files changed, 34 insertions(+)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 9164e1534ec9..56681a648b3d 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -26,6 +26,7 @@ extern int ima_post_read_file(struct file *file, void *buf,
loff_t size,
extern void ima_post_path_mknod(struct dentry *dentry);
extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
extern void ima_kexec_cmdline(const void *buf, int size);
+extern void ima_lsm_state(const char *lsm_name, const void *buf, int size);
#ifdef CONFIG_IMA_KEXEC
extern void ima_add_kexec_buffer(struct kimage *image);
@@ -104,6 +105,9 @@ static inline int ima_file_hash(struct file *file, char
*buf, size_t buf_size)
}
static inline void ima_kexec_cmdline(const void *buf, int size) {}
+
+static inline void ima_lsm_state(const char *lsm_name,
+const void *buf, int size) {}
#endif /* CONFIG_IMA */
#ifndef CONFIG_IMA_KEXEC
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index c1583d98c5e5..34be962054fb 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -827,6 +827,36 @@ void ima_kexec_cmdline(const void *buf, int size)
KEXEC_CMDLINE, 0, NULL);
}
+/**
+ * ima_lsm_state - measure LSM specific state
+ * @lsm_name: Name of the LSM
+ * @buf: pointer to buffer containing LSM specific state
+ * @size: Number of bytes in buf
+ *
+ * Buffers can only be measured, not appraised.
+ */
+void ima_lsm_state(const char *lsm_name, const void *buf, int size)
+{
+ const char *eventname = "lsm-state:";
+ char *lsmstatestring;
+ int lsmstatelen;
+
+ if (!lsm_name || !buf || !size)
+ return;
+
+ lsmstatelen = strlen(eventname) + strlen(lsm_name) + 1;
+ lsmstatestring = kzalloc(lsmstatelen, GFP_KERNEL);
+ if (!lsmstatestring)
+ return;
+
+ strcpy(lsmstatestring, eventname);
+ strcat(lsmstatestring, lsm_name);
+
+ process_buffer_measurement(buf, size, lsmstatestring,
+ LSM_STATE, 0, NULL);
+ kfree(lsmstatestring);
+}
+
static int __init init_ima(void)
{
int error;
--
2.27.0
Re: [PATCH v6 6/6] blktrace: fix debugfs use after free
On 2020-06-08 10:01, Luis Chamberlain wrote: > + /* > + * Blktrace needs a debugfs name even for queues that don't register > + * a gendisk, so it lazily registers the debugfs directory. But that > + * can get us into a situation where a SCSI device is found, with no > + * driver for it (yet). Then blktrace is used on the device, creating > + * the debugfs directory, and only after that a driver is loaded. In > + * that case we might already have a debugfs directory registered here. > + * Even worse we could be racing with blktrace to register it. > + */ There are LLD and ULD drivers in the SCSI subsystem. Please mention the driver type explicitly. I assume that you are referring to SCSI ULDs since only SCSI ULD drivers call device_add_disk()? Could the above comment be made shorter by only mentioning that blktrace may have been set up before or concurrently with device_add_disk() and that device_add_disk() calls blk_register_queue()? > case BLKTRACESETUP: > + if (!sdp->device->request_queue->sg_debugfs_dir) > + blk_sg_debugfs_init(sdp->device->request_queue, > + sdp->disk->disk_name); How about moving the sg_debugfs_dir check into blk_sg_debugfs_init()? Thanks, Bart.
[PATCH v2 2/2] IMA: Add audit log for failure conditions
process_buffer_measurement() and ima_alloc_key_entry() functions need to
log an audit message for auditing integrity measurement failures.
Add audit message in these two functions. Remove "pr_devel" log message
in process_buffer_measurement().
Sample audit messages:
[6.415374] audit: type=1804 audit(1592005945.627:2): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=kernel op=measuring_kexec_cmdline
cause=alloc_entry comm="swapper/0" name="kexec-cmdline" res=0 result=-12
[8.085456] audit: type=1802 audit(1592005947.297:9): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
op=policy_update cause=completed comm="systemd" res=1 result=0
[8.128004] audit: type=1804 audit(1592005947.341:11): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
op=measuring_key cause=hashing_error comm="systemd"
name=".builtin_trusted_keys" res=0 result=-22
Signed-off-by: Lakshmi Ramasubramanian
Suggested-by: Mimi Zohar
---
security/integrity/ima/ima.h| 48 -
security/integrity/ima/ima_main.c | 18 +++---
security/integrity/ima/ima_policy.c | 2 +-
security/integrity/ima/ima_queue_keys.c | 5 +++
4 files changed, 51 insertions(+), 22 deletions(-)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index df93ac258e01..c3a32e181b48 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -186,27 +186,43 @@ static inline unsigned int ima_hash_key(u8 *digest)
return (digest[0] | digest[1] << 8) % IMA_MEASURE_HTABLE_SIZE;
}
-#define __ima_hooks(hook) \
- hook(NONE) \
- hook(FILE_CHECK)\
- hook(MMAP_CHECK)\
- hook(BPRM_CHECK)\
- hook(CREDS_CHECK) \
- hook(POST_SETATTR) \
- hook(MODULE_CHECK) \
- hook(FIRMWARE_CHECK)\
- hook(KEXEC_KERNEL_CHECK)\
- hook(KEXEC_INITRAMFS_CHECK) \
- hook(POLICY_CHECK) \
- hook(KEXEC_CMDLINE) \
- hook(KEY_CHECK) \
- hook(MAX_CHECK)
-#define __ima_hook_enumify(ENUM) ENUM,
+#define __ima_hooks(hook) \
+ hook(NONE, none)\
+ hook(FILE_CHECK, file) \
+ hook(MMAP_CHECK, mmap) \
+ hook(BPRM_CHECK, bprm) \
+ hook(CREDS_CHECK, creds)\
+ hook(POST_SETATTR, post_setattr)\
+ hook(MODULE_CHECK, module) \
+ hook(FIRMWARE_CHECK, firmware) \
+ hook(KEXEC_KERNEL_CHECK, kexec_kernel) \
+ hook(KEXEC_INITRAMFS_CHECK, kexec_initramfs)\
+ hook(POLICY_CHECK, policy) \
+ hook(KEXEC_CMDLINE, kexec_cmdline) \
+ hook(KEY_CHECK, key)\
+ hook(MAX_CHECK, none)
+
+#define __ima_hook_enumify(ENUM, str) ENUM,
+#define __ima_stringify(arg) (#arg)
+#define __ima_hook_measuring_stringify(ENUM, str) \
+ (__ima_stringify(measuring_ ##str)),
enum ima_hooks {
__ima_hooks(__ima_hook_enumify)
};
+static const char * const ima_hooks_measure_str[] = {
+ __ima_hooks(__ima_hook_measuring_stringify)
+};
+
+static inline const char *func_measure_str(enum ima_hooks func)
+{
+ if (func >= MAX_CHECK)
+ return ima_hooks_measure_str[NONE];
+
+ return ima_hooks_measure_str[func];
+}
+
extern const char *const func_tokens[];
struct modsig;
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index c1583d98c5e5..8a001aa8e592 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -740,6 +740,7 @@ void process_buffer_measurement(const void *buf, int size,
int pcr, const char *keyring)
{
int ret = 0;
+ const char *audit_cause = "ENOMEM";
struct ima_template_entry *entry = NULL;
struct integrity_iint_cache iint = {};
struct ima_event_data event_data = {.iint = ,
@@ -794,21 +795,28 @@ void process_buffer_measurement(const void *buf, int size,
iint.ima_hash->length = hash_digest_size[ima_hash_algo];
ret = ima_calc_buffer_hash(buf, size, iint.ima_hash);
- if (ret < 0)
+ if (ret < 0) {
+ audit_cause = "hashing_error";
goto out;
+ }
ret = ima_alloc_init_template(_data, , template);
- if (ret < 0)
+ if (ret < 0) {
+ audit_cause = "alloc_entry";
goto out;
+ }
ret = ima_store_template(entry, violation, NULL, buf, pcr);
-
- if (ret < 0)
+ if (ret < 0) {
+ audit_cause = "store_entry";
[PATCH v2 1/2] integrity: Add result field in audit message
Result code is not included in the audit messages logged by the integrity subsystem. Add "result" field in the audit messages logged by the integrity subsystem and set the value to the result code passed to integrity_audit_msg() in the "result" parameter. Sample audit message: [6.284329] audit: type=1804 audit(1591756723.627:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel op=add_boot_aggregate cause=alloc_entry comm="swapper/0" name="boot_aggregate" res=0 result=-12 [8.085456] audit: type=1802 audit(1592005947.297:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 op=policy_update cause=completed comm="systemd" res=1 result=0 Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Steve Grubb --- security/integrity/integrity_audit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/integrity/integrity_audit.c b/security/integrity/integrity_audit.c index 5109173839cc..84002d3d5a95 100644 --- a/security/integrity/integrity_audit.c +++ b/security/integrity/integrity_audit.c @@ -53,6 +53,6 @@ void integrity_audit_msg(int audit_msgno, struct inode *inode, audit_log_untrustedstring(ab, inode->i_sb->s_id); audit_log_format(ab, " ino=%lu", inode->i_ino); } - audit_log_format(ab, " res=%d", !result); + audit_log_format(ab, " res=%d result=%d", !result, result); audit_log_end(ab); } -- 2.27.0
Re: [RFC PATCH 11/13] sched: migration changes for core scheduling
On Fri, Jun 12, 2020 at 05:32:01PM -0400, Vineeth Remanan Pillai wrote: > > AFAIR, that's what v4 did: > > > > if (available_idle_cpu(cpu)) > > #ifdef CONFIG_SCHED_CORE > > if (sched_core_enabled(cpu_rq(cpu)) && > > (p->core_cookie == > > cpu_rq(cpu)->core->core_cookie)) > > break; > > #else > > break; > > #endif > > > This patch was initially not in v4 and this is a merging of 4 patches > suggested post-v4. During the initial round, code was like above. But since > there looked like a code duplication in the different migration paths, > it was consolidated into sched_core_cookie_match() and it caused this > extra logic to this specific code path. As you mentioned, I also feel > we do not need to check for core idleness in this path. Ok, so I take it that you will make it so in v6 then, unless of course someone else objects. thanks! - Joel
Re: [PATCH 00/16] dynamic_debug: cleanups, 2 features
On Fri, Jun 12, 2020 at 3:31 PM Jason Baron wrote: > > > > On 6/5/20 12:26 PM, Jim Cromie wrote: > > Patchset starts with 7 "cleanups"; > > - it changes section name from vague "__verbose" to "__dyndbg" > > - cleaner docs, drop obsolete comment & useless debug prints, refine > > verbosity, fix a BUG_ON, ram reporting miscounts. > > > > It adds a few query parsing conveniences; > > accept combined file:line & file:func forms > > > > file inode.c:100-200# file & line-range > > file inode.c:start_*# file & function > > > > So I like the shortened notation there. > > > Then it expands flags: > > > > Adds 'u' user flag, allowing user to compose an arbitrary set of > > callsites by marking them with 'u', without altering current > > print-modifying flags. > > > > Adds 'PFMLTU' flags, which negate their lower-case counterparts. > > > > Extends flags-spec with filter-flags, which select callsites for > > modification based upon their current flags. This lets user activate > > the set of callsites marked with 'u' in a batch. > > > > echo 'u+p' > control > > > > I'm wondering if users are really going to use these and how much they > simplify things? Do you find them useful while debugging issues? > > Especially now that now that we are looking to let people define > groupings. > > Thanks, > > -Jason so we have 1- u flag - in modflags, allows marking of sets 2- filterflags - constrain matching sites to those marked plus any other subcondition you might want on your marked set 3- negating flags in filters, they allow complete match to all the bits. dont want to touch callsites marked with Pt ? (marked with t, without printing) now you can. filters let you use current flagstate to select subsets of " +p >control" +negations gives complete selectivity on that flagstate in modflags theyre more convenience, but setting and clearing 2+ bits atomically lets you both use the u bit to enable printing (inc module name filename) and retire that use of u, or to change the logging output subtly (by dropping threads display, or module-name) I cant say its essential, but its so cheap (last patch) once negating flags are in place, which are needed for full selectivity filtering. thanks Jim
Re: drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space '' of expression
On 13/6/20 2:35 am, Luc Van Oostenryck wrote:
On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote:
On 12/6/20 5:48 pm, Marc Kleine-Budde wrote:
I think this one is due to not forcing the volatile cast in __raw_write().
So this change will fix that:
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 0498192e1d98..1bc739f1f1ad 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -14,15 +14,15 @@
* that behavior here first before we include asm-generic/io.h.
*/
#define __raw_readb(addr) \
-({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
+({ u8 __v = (*(__force volatile u8 *) (addr)); __v; })
#define __raw_readw(addr) \
-({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
+({ u16 __v = (*(__force volatile u16 *) (addr)); __v; })
#define __raw_readl(addr) \
-({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
+({ u32 __v = (*(__force volatile u32 *) (addr)); __v; })
-#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) =
(b))
-#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) =
(b))
-#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
+#define __raw_writeb(b, addr) (void)((*(__force volatile u8 *) (addr)) = (b))
+#define __raw_writew(b, addr) (void)((*(__force volatile u16 *) (addr)) = (b))
+#define __raw_writel(b, addr) (void)((*(__force volatile u32 *) (addr)) = (b))
Look good to me but isn't easier to leave them undefined and include
asm-generic/io.h?
Not so simple at the moment. Although juggling a few things around within
io_no.h will let you use the asm-generic functions it will now throw up
a _lot_ of warnings in many of the architecture files that pass int constant
addresses to the raw_* functions. That is on my todo list.
Regards
Greg
Re: [GIT PULL] OpenRISC updates for v5.8
CCing list. On Sat, Jun 13, 2020 at 11:17:57AM +0900, Stafford Horne wrote: > Hi Linus, > > Please consider for pull: > > The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936: > > Linux 5.7-rc2 (2020-04-19 14:35:30 -0700) > > are available in the Git repository at: > > git://github.com/openrisc/linux.git tags/for-linus > > for you to fetch changes up to 6bd140e14d9aaa734ec37985b8b20a96c0ece948: > > openrisc: Fix issue with argument clobbering for clone/fork (2020-06-01 > 06:15:32 +0900) > > > OpenRISC updates for 5.8 > > One patch found wile I was getting the glibc port ready: > - Fix issue with clone TLS arg getting overwritten > > > Stafford Horne (1): > openrisc: Fix issue with argument clobbering for clone/fork > > arch/openrisc/kernel/entry.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH v6 4/6] blktrace: annotate required lock on do_blk_trace_setup()
On 2020-06-08 10:01, Luis Chamberlain wrote: > Ensure it is clear which lock is required on do_blk_trace_setup(). Reviewed-by: Bart Van Assche
Re: [PATCH v6 3/6] block: revert back to synchronous request_queue removal
On 2020-06-08 10:01, Luis Chamberlain wrote: > + * Drivers exist which depend on the release of the request_queue to be > + * synchronous, it should not be deferred. This sounds mysterious. Which drivers? Why do these depend on this function being synchronous? Anyway: Reviewed-by: Bart Van Assche
Re: [PATCH 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory
Hi Jerry, On 2020/6/13 7:10, Jerry Snitselaar wrote: Move Intel Kconfig and Makefile bits down into intel directory with the rest of the Intel specific files. Cc: Joerg Roedel Cc: Lu Baolu Thanks! Reviewed-by: Lu Baolu Best regards, baolu Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig| 86 +--- drivers/iommu/Makefile | 8 +--- drivers/iommu/intel/Kconfig | 86 drivers/iommu/intel/Makefile | 7 +++ 4 files changed, 96 insertions(+), 91 deletions(-) create mode 100644 drivers/iommu/intel/Kconfig create mode 100644 drivers/iommu/intel/Makefile diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index aca76383f201..b12d4ec124f6 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -176,91 +176,7 @@ config AMD_IOMMU_DEBUGFS This option is -NOT- intended for production environments, and should not generally be enabled. -# Intel IOMMU support -config DMAR_TABLE - bool - -config INTEL_IOMMU - bool "Support for Intel IOMMU using DMA Remapping Devices" - depends on PCI_MSI && ACPI && (X86 || IA64) - select IOMMU_API - select IOMMU_IOVA - select NEED_DMA_MAP_STATE - select DMAR_TABLE - select SWIOTLB - select IOASID - help - DMA remapping (DMAR) devices support enables independent address - translations for Direct Memory Access (DMA) from devices. - These DMA remapping devices are reported via ACPI tables - and include PCI device scope covered by these DMA - remapping devices. - -config INTEL_IOMMU_DEBUGFS - bool "Export Intel IOMMU internals in Debugfs" - depends on INTEL_IOMMU && IOMMU_DEBUGFS - help - !!!WARNING!!! - - DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!!! - - Expose Intel IOMMU internals in Debugfs. - - This option is -NOT- intended for production environments, and should - only be enabled for debugging Intel IOMMU. - -config INTEL_IOMMU_SVM - bool "Support for Shared Virtual Memory with Intel IOMMU" - depends on INTEL_IOMMU && X86 - select PCI_PASID - select PCI_PRI - select MMU_NOTIFIER - select IOASID - help - Shared Virtual Memory (SVM) provides a facility for devices - to access DMA resources through process address space by - means of a Process Address Space ID (PASID). - -config INTEL_IOMMU_DEFAULT_ON - def_bool y - prompt "Enable Intel DMA Remapping Devices by default" - depends on INTEL_IOMMU - help - Selecting this option will enable a DMAR device at boot time if - one is found. If this option is not selected, DMAR support can - be enabled by passing intel_iommu=on to the kernel. - -config INTEL_IOMMU_BROKEN_GFX_WA - bool "Workaround broken graphics drivers (going away soon)" - depends on INTEL_IOMMU && BROKEN && X86 - ---help--- - Current Graphics drivers tend to use physical address - for DMA and avoid using DMA APIs. Setting this config - option permits the IOMMU driver to set a unity map for - all the OS-visible memory. Hence the driver can continue - to use physical addresses for DMA, at least until this - option is removed in the 2.6.32 kernel. - -config INTEL_IOMMU_FLOPPY_WA - def_bool y - depends on INTEL_IOMMU && X86 - ---help--- - Floppy disk drivers are known to bypass DMA API calls - thereby failing to work when IOMMU is enabled. This - workaround will setup a 1:1 mapping for the first - 16MiB to make floppy (an ISA device) work. - -config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON - bool "Enable Intel IOMMU scalable mode by default" - depends on INTEL_IOMMU - help - Selecting this option will enable by default the scalable mode if - hardware presents the capability. The scalable mode is defined in - VT-d 3.0. The scalable mode capability could be checked by reading - /sys/devices/virtual/iommu/dmar*/intel-iommu/ecap. If this option - is not selected, scalable mode support could also be enabled by - passing intel_iommu=sm_on to the kernel. If not sure, please use - the default value. +source "drivers/iommu/intel/Kconfig" config IRQ_REMAP bool "Support for Interrupt Remapping" diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 342190196dfb..71dd2f382e78 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-y += intel/ obj-$(CONFIG_IOMMU_API) += iommu.o obj-$(CONFIG_IOMMU_API) += iommu-traces.o obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o @@ -17,13 +18,8 @@ obj-$(CONFIG_AMD_IOMMU_V2) += amd/iommu_v2.o obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
Re: [PATCH v8 5/7] iommu/arm-smmu: Add implementation for the adreno GPU SMMU
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20200612]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/iommu-arm-smmu-Enable-split-pagetable-support/20200612-094718
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b961f8dc8976c091180839f4483d67b7c2ca2578
config: arm64-randconfig-r026-20200612 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
3b43f006294971b8049d4807110032169780e5b8)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/iommu/arm-smmu-qcom.c:17:49: error: member reference type 'struct
>> device *' is a pointer; did you mean to use '->'?
return of_device_is_compatible(smmu_domain->dev.of_node, "qcom,adreno");
^
->
1 error generated.
vim +17 drivers/iommu/arm-smmu-qcom.c
14
15 static bool qcom_adreno_smmu_is_gpu_device(struct arm_smmu_domain
*smmu_domain)
16 {
> 17 return of_device_is_compatible(smmu_domain->dev.of_node,
"qcom,adreno");
18 }
19
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
RE: linux-next: build warning after merge of the net-next tree
> -Original Message-
> From: Stephen Rothwell
> Sent: Friday, June 12, 2020 18:16
> To: Kirsher, Jeffrey T
> Cc: David Miller ; Networking
> ; Linux Next Mailing List n...@vger.kernel.org>; Linux Kernel Mailing List ker...@vger.kernel.org>; Lifshits, Vitaly
> Subject: Re: linux-next: build warning after merge of the net-next tree
>
> Hi all,
>
> On Wed, 27 May 2020 01:15:09 + "Kirsher, Jeffrey T"
> wrote:
> >
> > > -Original Message-
> > > From: Stephen Rothwell
> > > Sent: Monday, May 25, 2020 05:40
> > > To: David Miller ; Networking
> > >
> > > Cc: Linux Next Mailing List ; Linux
> > > Kernel Mailing List ; Lifshits, Vitaly
> > > ; Kirsher, Jeffrey T
> > >
> > > Subject: linux-next: build warning after merge of the net-next tree
> > >
> > > Hi all,
> > >
> > > After merging the net-next tree, today's linux-next build (sparc64
> > > defconfig) produced this warning:
> > >
> > > drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning:
> 'e1000e_check_me'
> > > defined but not used [-Wunused-function] static bool
> > > e1000e_check_me(u16
> > > device_id)
> > > ^~~
> > >
> > > Introduced by commit
> > >
> > > e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> > > systems")
> > >
> > > CONFIG_PM_SLEEP is not set for this build.
> > >
> > [Kirsher, Jeffrey T]
> >
> > Vitaly informed me that he has a fix that he will be sending me, I will make
> sure to expedite it.
>
> I am still getting this warning.
I apologize, I have not seen a fix from Vitaly, that I am aware of. I will
make sure you have a patch before Monday.
Re: linux-next: build warning after merge of the net-next tree
Hi all,
On Wed, 27 May 2020 01:15:09 + "Kirsher, Jeffrey T"
wrote:
>
> > -Original Message-
> > From: Stephen Rothwell
> > Sent: Monday, May 25, 2020 05:40
> > To: David Miller ; Networking
> >
> > Cc: Linux Next Mailing List ; Linux Kernel
> > Mailing
> > List ; Lifshits, Vitaly
> > ;
> > Kirsher, Jeffrey T
> > Subject: linux-next: build warning after merge of the net-next tree
> >
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (sparc64
> > defconfig) produced this warning:
> >
> > drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning:
> > 'e1000e_check_me'
> > defined but not used [-Wunused-function] static bool e1000e_check_me(u16
> > device_id)
> > ^~~
> >
> > Introduced by commit
> >
> > e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
> >
> > CONFIG_PM_SLEEP is not set for this build.
> >
> [Kirsher, Jeffrey T]
>
> Vitaly informed me that he has a fix that he will be sending me, I will make
> sure to expedite it.
I am still getting this warning.
--
Cheers,
Stephen Rothwell
pgpso8fexP7Cs.pgp
Description: OpenPGP digital signature
[PATCH v2] Fix code style same in one function
From: weifenghai
Combine two assignments for the variable “l” into one statement.
Signed-off-by: weifenghai
---
kernel/cgroup/cgroup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 1ea181a58465..c3e6db6e44d8 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -4352,8 +4352,7 @@ static struct css_set *css_task_iter_next_css_set(struct
css_task_iter *it)
}
/* find the next cset */
- l = it->cset_pos;
- l = l->next;
+ l = it->cset_pos->next;
if (l == it->cset_head) {
it->cset_pos = NULL;
return NULL;
--
2.17.1
Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'
Hi!
On Fri, Jun 12, 2020 at 02:33:09PM -0700, Nick Desaulniers wrote:
> On Thu, Jun 11, 2020 at 4:53 PM Segher Boessenkool
> wrote:
> > The PowerPC part of
> > https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
> > (sorry, no anchor) documents %U.
>
> I thought those were constraints, not output templates? Oh,
> The asm statement must also use %U as a placeholder for the
> “update” flag in the corresponding load or store instruction.
> got it.
Traditionally, *all* constraints were documented here, including the
ones that are only meant for GCC's internal use. And the output
modifiers were largely not documented at all.
For GCC 10, for Power, I changed it to only document the constraints
that should be public in gcc.info (and everything in gccint.info). The
output modifiers can neatly be documented here as well, since it such a
short section now. We're not quite there yet, but getting there.
> > Traditionally the source code is the documentation for this. The code
> > here starts with the comment
> > /* Write second word of DImode or DFmode reference. Works on register
> > or non-indexed memory only. */
> > (which is very out-of-date itself, it works fine for e.g. TImode as well,
> > but alas).
> >
> > Unit tests are completely unsuitable for most compiler things like this.
>
> What? No, surely one may write tests for output operands. Grepping
> for `%L` in gcc/ was less fun than I was hoping.
You should look for 'L' instead (incl. those quotes) ;-)
Unit tests are 100x as much work, and gets <5% of the problems, compared
to regression tests. Unit tests only test the stuff you should have
written *anyway*. It is much more useful to test that much higher level
things work, IMNSHO.
> > HtH,
>
> Yes, perfect, thank you so much! So it looks like LLVM does not yet
> handle %L properly for memory operands.
> https://bugs.llvm.org/show_bug.cgi?id=46186#c4
> It's neat to see how this is implemented in GCC (and how many aren't
> implemented in LLVM, yikes :( ). For reference, this is implemented
> in PPCAsmPrinter::PrintAsmOperand() and
> PPCAsmPrinter::PrintAsmMemoryOperand() in
> llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp. GCC switches first on the
> modifier characters, then the operand type.
That is what the rs6000 backend currently does, yeah. The print_operand
function just gets passed the modifier character (as "int code", or 0 if
there is no modifier). Since there are so many modifiers there aren't
really any better options than just doing a "switch (code)" around
everything else (well, things can be factored, some helper functions,
etc., but this is mostly very old code, and it has grown organically).
> LLVM dispatches on operand type, then modifier.
That is neater, certainly for REG operands.
> When I was looking into LLVM's AsmPrinter class,
> I was surprised to see it's basically an assembler that just has
> complex logic to just do a bunch of prints, so it makes sense to see
> that pattern in GCC literally calling printf.
GCC always outputs assembler code. This is usually a big advantage, for
things like output_operand.
> Some things I don't understand from PPC parlance is the "mode"
> (preinc, predec, premodify) and small data operands?
"mode" is "machine mode" -- SImode and the like. PRE_DEC etc. are
*codes* (rtx codes), like, (mem:DF (pre_dec:SI (reg:SI 39))) (straight
from the manual).
> IIUC the bug report correctly, it looks like LLVM is failing for the
> __put_user_asm2_goto case for -m32. A simple reproducer:
> https://godbolt.org/z/jBBF9b
>
> void foo(long long in, long long* out) {
> asm volatile(
> "stw%X1 %0, %1\n\t"
> "stw%X1 %L0, %L1"
> ::"r"(in), "m"(*out));
> }
This is wrong if operands[0] is a register, btw. So it should use 'o'
as constraint (not 'm'), and then the 'X' output modifier has become
useless.
> prints (in GCC):
> foo:
> stw 3, 0(5)
> stw 4, 4(5)
> blr
> (first time looking at ppc assembler, seems constants and registers
> are not as easy to distinguish,
The instruction mnemonic always tells you what types all arguments are.
Traditionally we don't write spaces after commas, either. That is
actually easier to read -- well, if you are used to it, anyway! :-)
> https://developer.ibm.com/technologies/linux/articles/l-ppc/ say "Get
> used to it." LOL, ok).
Since quite a while you can write your assembler using register names as
well. Not using the dangerous macros the Linux kernel had/has(with
which you can write "rN" in place of any "N", and it doesn't force you
to use the register name either, so you could write "li r3,r4" and
"mr r3,0" and even "addi r3,r0,1234", all very misleading).
> so that's "store word from register 3 into dereference of register 5
> plus 0, then store word from register 4 into dereference of register 5
> plus 4?"
Yup.
> Guessing the ppc32 abi is ILP32 putting long long's into two
> separate registers?
Yes, and the order is the same as it
[PULL] alpha.git
Hi Linus, Please pull a few changes for alpha. They're mostly small janitorial fixes but there's also a build fix and most notably a patch from Mikulas that fixes a hang on boot on the Avanti platform, which required quite a bit of work and review. Thanks, Matt The following changes since commit 79ca035d2d941839f55f3b8b69f8e81c66946ed8: Merge branch 'proc-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace (2020-06-10 15:00:11 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus for you to fetch changes up to 47f634ba765085373f851e9c48dccb12ad52: alpha: Fix build around srm_sysrq_reboot_op (2020-06-12 17:43:18 -0700) Chuhong Yuan (1): alpha: Replace strncmp with str_has_prefix Enrico Weigelt, metux IT consult (1): alpha: Kconfig: pedantic formatting Jason Yan (2): alpha: remove unneeded semicolon in osf_sys.c alpha: remove unneeded semicolon in sys_eiger.c Joerg Roedel (1): alpha: Fix build around srm_sysrq_reboot_op Matt Turner (1): alpha: c_next should increase position index Mikulas Patocka (2): alpha: fix rtc port ranges alpha: fix memory barriers so that they conform to the specification Xu Wang (1): alpha: Replace sg++ with sg = sg_next(sg) arch/alpha/Kconfig | 4 +-- arch/alpha/boot/tools/objstrip.c | 2 +- arch/alpha/include/asm/io.h | 74 arch/alpha/kernel/io.c | 60 arch/alpha/kernel/osf_sys.c | 2 +- arch/alpha/kernel/pci_iommu.c| 2 +- arch/alpha/kernel/setup.c| 12 +-- arch/alpha/kernel/sys_eiger.c| 2 +- 8 files changed, 127 insertions(+), 31 deletions(-) signature.asc Description: PGP signature
[PATCH v2 01/12] iommu: Change type of pasid to unsigned int
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with ioasid's
type, define PASID and its variations (e.g. max PASID) as "unsigned int".
No PASID type change in uapi.
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Create this new patch to define PASID as "unsigned int" consistently in
iommu (Thomas)
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 5 ++--
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 +-
drivers/iommu/amd/amd_iommu.h | 13
drivers/iommu/amd/amd_iommu_types.h| 12
drivers/iommu/amd/init.c | 4 +--
drivers/iommu/amd/iommu.c | 41 ++
drivers/iommu/amd/iommu_v2.c | 22 +++---
drivers/iommu/intel/debugfs.c | 2 +-
drivers/iommu/intel/dmar.c | 13
drivers/iommu/intel/intel-pasid.h | 21 ++---
drivers/iommu/intel/iommu.c| 4 +--
drivers/iommu/intel/pasid.c| 36 +++---
drivers/iommu/intel/svm.c | 12
drivers/iommu/iommu.c | 2 +-
drivers/misc/uacce/uacce.c | 2 +-
include/linux/amd-iommu.h | 9 +++---
include/linux/intel-iommu.h| 18 +--
include/linux/intel-svm.h | 2 +-
include/linux/iommu.h | 8 ++---
include/linux/uacce.h | 2 +-
20 files changed, 121 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 7c8786b9eb0a..703d23deca76 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -139,7 +139,8 @@ void kfd_iommu_unbind_process(struct kfd_process *p)
}
/* Callback for process shutdown invoked by the IOMMU driver */
-static void iommu_pasid_shutdown_callback(struct pci_dev *pdev, int pasid)
+static void iommu_pasid_shutdown_callback(struct pci_dev *pdev,
+ unsigned int pasid)
{
struct kfd_dev *dev = kfd_device_by_pci_dev(pdev);
struct kfd_process *p;
@@ -185,7 +186,7 @@ static void iommu_pasid_shutdown_callback(struct pci_dev
*pdev, int pasid)
}
/* This function called by IOMMU driver on PPR failure */
-static int iommu_invalid_ppr_cb(struct pci_dev *pdev, int pasid,
+static int iommu_invalid_ppr_cb(struct pci_dev *pdev, unsigned int pasid,
unsigned long address, u16 flags)
{
struct kfd_dev *dev;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index f0587d94294d..3c7d1f774afe 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -714,7 +714,7 @@ struct kfd_process {
/* We want to receive a notification when the mm_struct is destroyed */
struct mmu_notifier mmu_notifier;
- uint16_t pasid;
+ unsigned int pasid;
unsigned int doorbell_index;
/*
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index f892992c8744..0914b5b6f879 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -45,12 +45,13 @@ extern int amd_iommu_register_ppr_notifier(struct
notifier_block *nb);
extern int amd_iommu_unregister_ppr_notifier(struct notifier_block *nb);
extern void amd_iommu_domain_direct_map(struct iommu_domain *dom);
extern int amd_iommu_domain_enable_v2(struct iommu_domain *dom, int pasids);
-extern int amd_iommu_flush_page(struct iommu_domain *dom, int pasid,
+extern int amd_iommu_flush_page(struct iommu_domain *dom, unsigned int pasid,
u64 address);
-extern int amd_iommu_flush_tlb(struct iommu_domain *dom, int pasid);
-extern int amd_iommu_domain_set_gcr3(struct iommu_domain *dom, int pasid,
-unsigned long cr3);
-extern int amd_iommu_domain_clear_gcr3(struct iommu_domain *dom, int pasid);
+extern int amd_iommu_flush_tlb(struct iommu_domain *dom, unsigned int pasid);
+extern int amd_iommu_domain_set_gcr3(struct iommu_domain *dom,
+unsigned int pasid, unsigned long cr3);
+extern int amd_iommu_domain_clear_gcr3(struct iommu_domain *dom,
+ unsigned int pasid);
extern struct iommu_domain *amd_iommu_get_v2_domain(struct pci_dev *pdev);
#ifdef CONFIG_IRQ_REMAP
@@ -66,7 +67,7 @@ static inline int amd_iommu_create_irq_domain(struct
amd_iommu *iommu)
#define PPR_INVALID0x1
#define PPR_FAILURE0xf
-extern int amd_iommu_complete_ppr(struct pci_dev *pdev, int pasid,
+extern int amd_iommu_complete_ppr(struct pci_dev *pdev, unsigned int pasid,
int status, int tag);
static inline bool is_rd890_iommu(struct pci_dev *pdev)
diff --git a/drivers/iommu/amd/amd_iommu_types.h
[PATCH v2 09/12] fork: Clear PASID for new mm
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this patch to initialize PASID value for a new mm.
include/linux/mm_types.h | 2 ++
kernel/fork.c| 8
2 files changed, 10 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5778db3aa42d..904bc07411a9 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -22,6 +22,8 @@
#endif
#define AT_VECTOR_SIZE (2*(AT_VECTOR_SIZE_ARCH + AT_VECTOR_SIZE_BASE + 1))
+/* Initial PASID value is 0. */
+#define INIT_PASID 0
struct address_space;
struct mem_cgroup;
diff --git a/kernel/fork.c b/kernel/fork.c
index 142b23645d82..085e72d3e9eb 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1007,6 +1007,13 @@ static void mm_init_owner(struct mm_struct *mm, struct
task_struct *p)
#endif
}
+static void mm_init_pasid(struct mm_struct *mm)
+{
+#ifdef CONFIG_PCI_PASID
+ mm->pasid = INIT_PASID;
+#endif
+}
+
static void mm_init_uprobes_state(struct mm_struct *mm)
{
#ifdef CONFIG_UPROBES
@@ -1035,6 +1042,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm,
struct task_struct *p,
mm_init_cpumask(mm);
mm_init_aio(mm);
mm_init_owner(mm, p);
+ mm_init_pasid(mm);
RCU_INIT_POINTER(mm->exe_file, NULL);
mmu_notifier_subscriptions_init(mm);
init_tlb_flush_pending(mm);
--
2.19.1
[PATCH v2 07/12] x86/msr-index: Define IA32_PASID MSR
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier (PASID), a 20-bit value. Bit 31 must be set to indicate the value programmed in the MSR is valid. Hardware uses PASID to identify process address space and direct responses to the right address space. Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck --- v2: - Change "identify process" to "identify process address space" in the commit message (Thomas) arch/x86/include/asm/msr-index.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index e8370e64a155..e5f699ff1dd6 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -237,6 +237,9 @@ #define MSR_IA32_LASTINTFROMIP 0x01dd #define MSR_IA32_LASTINTTOIP 0x01de +#define MSR_IA32_PASID 0x0d93 +#define MSR_IA32_PASID_VALID BIT_ULL(31) + /* DEBUGCTLMSR bits (others vary by model): */ #define DEBUGCTLMSR_LBR(1UL << 0) /* last branch recording */ #define DEBUGCTLMSR_BTF_SHIFT 1 -- 2.19.1
[PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)
From: Ashok Raj ENQCMD and Data Streaming Accelerator (DSA) and all of their associated features are a complicated stack with lots of interconnected pieces. This documentation provides a big picture overview for all of the features. Signed-off-by: Ashok Raj Co-developed-by: Fenghua Yu Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck --- v2: - Fix the doc format and add the doc in toctree (Thomas) - Modify the doc for better description (Thomas, Tony, Dave) Documentation/x86/index.rst | 1 + Documentation/x86/sva.rst | 287 2 files changed, 288 insertions(+) create mode 100644 Documentation/x86/sva.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 265d9e9a093b..e5d5ff096685 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -30,3 +30,4 @@ x86-specific Documentation usb-legacy-support i386/index x86_64/index + sva diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst new file mode 100644 index ..1e52208c7dda --- /dev/null +++ b/Documentation/x86/sva.rst @@ -0,0 +1,287 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Shared Virtual Addressing (SVA) with ENQCMD +=== + +Background +== + +Shared Virtual Addressing (SVA) allows the processor and device to use the +same virtual addresses avoiding the need for software to translate virtual +addresses to physical addresses. SVA is what PCIe calls Shared Virtual +Memory (SVM) + +In addition to the convenience of using application virtual addresses +by the device, it also doesn't require pinning pages for DMA. +PCIe Address Translation Services (ATS) along with Page Request Interface +(PRI) allow devices to function much the same way as the CPU handling +application page-faults. For more information please refer to PCIe +specification Chapter 10: ATS Specification. + +Use of SVA requires IOMMU support in the platform. IOMMU also is required +to support PCIe features ATS and PRI. ATS allows devices to cache +translations for the virtual address. IOMMU driver uses the mmu_notifier() +support to keep the device tlb cache and the CPU cache in sync. PRI allows +the device to request paging the virtual address before using if they are +not paged in the CPU page tables. + + +Shared Hardware Workqueues +== + +Unlike Single Root I/O Virtualization (SRIOV), Scalable IOV (SIOV) permits +the use of Shared Work Queues (SWQ) by both applications and Virtual +Machines (VM's). This allows better hardware utilization vs. hard +partitioning resources that could result in under utilization. In order to +allow the hardware to distinguish the context for which work is being +executed in the hardware by SWQ interface, SIOV uses Process Address Space +ID (PASID), which is a 20bit number defined by the PCIe SIG. + +PASID value is encoded in all transactions from the device. This allows the +IOMMU to track I/O on a per-PASID granularity in addition to using the PCIe +Resource Identifier (RID) which is the Bus/Device/Function. + + +ENQCMD +== + +ENQCMD is a new instruction on Intel platforms that atomically submits a +work descriptor to a device. The descriptor includes the operation to be +performed, virtual addresses of all parameters, virtual address of a completion +record, and the PASID (process address space ID) of the current process. + +ENQCMD works with non-posted semantics and carries a status back if the +command was accepted by hardware. This allows the submitter to know if the +submission needs to be retried or other device specific mechanisms to +implement implement fairness or ensure forward progress can be made. + +ENQCMD is the glue that ensures applications can directly submit commands +to the hardware and also permit hardware to be aware of application context +to perform I/O operations via use of PASID. + +Process Address Space Tagging += + +A new thread scoped MSR (IA32_PASID) provides the connection between +user processes and the rest of the hardware. When an application first +accesses an SVA capable device this MSR is initialized with a newly +allocated PASID. The driver for the device calls an IOMMU specific api +that sets up the routing for DMA and page-requests. + +For example, the Intel Data Streaming Accelerator (DSA) uses +intel_svm_bind_mm(), which will do the following. + +- Allocate the PASID, and program the process page-table (cr3) in the PASID + context entries. +- Register for mmu_notifier() to track any page-table invalidations to keep + the device tlb in sync. For example, when a page-table entry is invalidated, + IOMMU propagates the invalidation to device tlb. This will force any + future access by the device to this virtual address to participate in + ATS. If the IOMMU responds with proper response that a page is not + present, the device would request the
[PATCH v2 10/12] x86/process: Clear PASID state for a newly forked/cloned thread
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the downside of increased context switch overhead to setting
the PASID MSR.
Since #GP faults have to be handled on any threads that were created before
the PASID was assigned to the mm of the process, newly created threads
might as well be treated in a consistent way.
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Modify init_task_pasid().
arch/x86/kernel/process.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index f362ce0d5ac0..1b1492e337a6 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -121,6 +121,21 @@ static int set_new_tls(struct task_struct *p, unsigned
long tls)
return do_set_thread_area_64(p, ARCH_SET_FS, tls);
}
+/* Initialize the PASID state for the forked/cloned thread. */
+static void init_task_pasid(struct task_struct *task)
+{
+ struct ia32_pasid_state *ppasid;
+
+ /*
+* Initialize the PASID state so that the PASID MSR will be
+* initialized to its initial state (0) by XRSTORS when the task is
+* scheduled for the first time.
+*/
+ ppasid = get_xsave_addr(>thread.fpu.state.xsave, XFEATURE_PASID);
+ if (ppasid)
+ ppasid->pasid = INIT_PASID;
+}
+
int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
unsigned long arg, struct task_struct *p, unsigned long tls)
{
@@ -174,6 +189,9 @@ int copy_thread_tls(unsigned long clone_flags, unsigned
long sp,
task_user_gs(p) = get_user_gs(current_pt_regs());
#endif
+ if (static_cpu_has(X86_FEATURE_ENQCMD))
+ init_task_pasid(p);
+
/* Set a new TLS for the child thread? */
if (clone_flags & CLONE_SETTLS)
ret = set_new_tls(p, tls);
--
2.19.1
[PATCH v2 11/12] x86/mmu: Allocate/free PASID
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.
The PASID is freed when the process exits (so no need to keep
reference counts on how many SVM devices are sharing the PASID).
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Define a helper free_bind() to simplify error exit code in bind_mm()
(Thomas)
- Fix a ret error code in bind_mm() (Thomas)
- Change pasid's type from "int" to "unsigned int" to have consistent
pasid type in iommu (Thomas)
- Simplify alloc_pasid() a bit.
arch/x86/include/asm/iommu.h | 2 +
arch/x86/include/asm/mmu_context.h | 14
drivers/iommu/intel/svm.c | 101 +
3 files changed, 105 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
index bf1ed2ddc74b..ed41259fe7ac 100644
--- a/arch/x86/include/asm/iommu.h
+++ b/arch/x86/include/asm/iommu.h
@@ -26,4 +26,6 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
return -EINVAL;
}
+void __free_pasid(struct mm_struct *mm);
+
#endif /* _ASM_X86_IOMMU_H */
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 47562147e70b..f8c91ce8c451 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
extern atomic64_t last_mm_ctx_id;
@@ -117,9 +118,22 @@ static inline int init_new_context(struct task_struct *tsk,
init_new_context_ldt(mm);
return 0;
}
+
+static inline void free_pasid(struct mm_struct *mm)
+{
+ if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM))
+ return;
+
+ if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
+ return;
+
+ __free_pasid(mm);
+}
+
static inline void destroy_context(struct mm_struct *mm)
{
destroy_context_ldt(mm);
+ free_pasid(mm);
}
extern void switch_mm(struct mm_struct *prev, struct mm_struct *next,
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 4e775e12ae52..27dc866b8461 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -425,6 +425,53 @@ int intel_svm_unbind_gpasid(struct device *dev, unsigned
int pasid)
return ret;
}
+static void free_bind(struct intel_svm *svm, struct intel_svm_dev *sdev,
+ bool new_pasid)
+{
+ if (new_pasid)
+ ioasid_free(svm->pasid);
+ kfree(svm);
+ kfree(sdev);
+}
+
+/*
+ * If this mm already has a PASID, use it. Otherwise allocate a new one.
+ * Let the caller know if a new PASID is allocated via 'new_pasid'.
+ */
+static int alloc_pasid(struct intel_svm *svm, struct mm_struct *mm,
+ unsigned int pasid_max, bool *new_pasid,
+ unsigned int flags)
+{
+ unsigned int pasid;
+
+ *new_pasid = false;
+
+ /*
+* Reuse the PASID if the mm already has a PASID and not a private
+* PASID is requested.
+*/
+ if (mm && mm->pasid && !(flags & SVM_FLAG_PRIVATE_PASID)) {
+ /*
+* Once a PASID is allocated for this mm, the PASID
+* stays with the mm until the mm is dropped. Reuse
+* the PASID which has been already allocated for the
+* mm instead of allocating a new one.
+*/
+ ioasid_set_data(mm->pasid, svm);
+
+ return mm->pasid;
+ }
+
+ /* Allocate a new pasid. Do not use PASID 0, reserved for init PASID. */
+ pasid = ioasid_alloc(NULL, PASID_MIN, pasid_max - 1, svm);
+ if (pasid != INVALID_IOASID) {
+ /* A new pasid is allocated. */
+ *new_pasid = true;
+ }
+
+ return pasid;
+}
+
/* Caller must hold pasid_mutex, mm reference */
static int
intel_svm_bind_mm(struct device *dev, unsigned int flags,
@@ -518,6 +565,8 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
init_rcu_head(>rcu);
if (!svm) {
+ bool new_pasid;
+
svm = kzalloc(sizeof(*svm), GFP_KERNEL);
if (!svm) {
ret = -ENOMEM;
@@ -529,12 +578,9 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
if (pasid_max > intel_pasid_max_id)
pasid_max = intel_pasid_max_id;
- /* Do not use PASID 0, reserved for RID to PASID */
- svm->pasid = ioasid_alloc(NULL, PASID_MIN,
- pasid_max - 1, svm);
+ svm->pasid = alloc_pasid(svm, mm, pasid_max, _pasid, flags);
if (svm->pasid == INVALID_IOASID) {
- kfree(svm);
- kfree(sdev);
+ free_bind(svm, sdev, new_pasid);
ret =
[PATCH v2 06/12] x86/fpu/xstate: Add supervisor PASID state for ENQCMD feature
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Modify the commit message (Thomas)
arch/x86/include/asm/fpu/types.h | 10 ++
arch/x86/include/asm/fpu/xstate.h | 2 +-
arch/x86/kernel/fpu/xstate.c | 4
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index f098f6cab94b..00f8efd4c07d 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -114,6 +114,7 @@ enum xfeature {
XFEATURE_Hi16_ZMM,
XFEATURE_PT_UNIMPLEMENTED_SO_FAR,
XFEATURE_PKRU,
+ XFEATURE_PASID,
XFEATURE_MAX,
};
@@ -128,6 +129,7 @@ enum xfeature {
#define XFEATURE_MASK_Hi16_ZMM (1 << XFEATURE_Hi16_ZMM)
#define XFEATURE_MASK_PT (1 << XFEATURE_PT_UNIMPLEMENTED_SO_FAR)
#define XFEATURE_MASK_PKRU (1 << XFEATURE_PKRU)
+#define XFEATURE_MASK_PASID(1 << XFEATURE_PASID)
#define XFEATURE_MASK_FPSSE(XFEATURE_MASK_FP | XFEATURE_MASK_SSE)
#define XFEATURE_MASK_AVX512 (XFEATURE_MASK_OPMASK \
@@ -229,6 +231,14 @@ struct pkru_state {
u32 pad;
} __packed;
+/*
+ * State component 10 is supervisor state used for context-switching the
+ * PASID state.
+ */
+struct ia32_pasid_state {
+ u64 pasid;
+} __packed;
+
struct xstate_header {
u64 xfeatures;
u64 xcomp_bv;
diff --git a/arch/x86/include/asm/fpu/xstate.h
b/arch/x86/include/asm/fpu/xstate.h
index 422d8369012a..ab9833c57aaa 100644
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@ -33,7 +33,7 @@
XFEATURE_MASK_BNDCSR)
/* All currently supported supervisor features */
-#define XFEATURE_MASK_SUPERVISOR_SUPPORTED (0)
+#define XFEATURE_MASK_SUPERVISOR_SUPPORTED (XFEATURE_MASK_PASID)
/*
* Unsupported supervisor features. When a supervisor feature in this mask is
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index bda2e5eaca0e..31629e43383c 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -37,6 +37,7 @@ static const char *xfeature_names[] =
"AVX-512 ZMM_Hi256" ,
"Processor Trace (unused)" ,
"Protection Keys User registers",
+ "PASID state",
"unknown xstate feature",
};
@@ -51,6 +52,7 @@ static short xsave_cpuid_features[] __initdata = {
X86_FEATURE_AVX512F,
X86_FEATURE_INTEL_PT,
X86_FEATURE_PKU,
+ X86_FEATURE_ENQCMD,
};
/*
@@ -316,6 +318,7 @@ static void __init print_xstate_features(void)
print_xstate_feature(XFEATURE_MASK_ZMM_Hi256);
print_xstate_feature(XFEATURE_MASK_Hi16_ZMM);
print_xstate_feature(XFEATURE_MASK_PKRU);
+ print_xstate_feature(XFEATURE_MASK_PASID);
}
/*
@@ -590,6 +593,7 @@ static void check_xstate_against_struct(int nr)
XCHECK_SZ(sz, nr, XFEATURE_ZMM_Hi256, struct avx_512_zmm_uppers_state);
XCHECK_SZ(sz, nr, XFEATURE_Hi16_ZMM, struct avx_512_hi16_state);
XCHECK_SZ(sz, nr, XFEATURE_PKRU, struct pkru_state);
+ XCHECK_SZ(sz, nr, XFEATURE_PASID, struct ia32_pasid_state);
/*
* Make *SURE* to add any feature numbers in below if
--
2.19.1
[PATCH v2 08/12] mm: Define pasid in mm
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- This new patch moves "pasid" from x86 specific mm_context_t to generic
struct mm_struct per Christopher's comment:
https://lore.kernel.org/linux-iommu/20200414170252.714402-1-jean-phili...@linaro.org/T/#mb57110ffe1aaa24750eeea4f93b611f0d1913911
- Jean-Philippe Brucker released a virtually same patch. I still put this
patch in the series for better review. The upstream kernel only needs one
of the two patches eventually.
https://lore.kernel.org/linux-iommu/20200519175502.2504091-2-jean-phili...@linaro.org/
- Change CONFIG_IOASID to CONFIG_PCI_PASID (Ashok)
include/linux/mm_types.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 64ede5f150dc..5778db3aa42d 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -538,6 +538,10 @@ struct mm_struct {
atomic_long_t hugetlb_usage;
#endif
struct work_struct async_put_work;
+
+#ifdef CONFIG_PCI_PASID
+ unsigned int pasid;
+#endif
} __randomize_layout;
/*
--
2.19.1
[PATCH v2 02/12] ocxl: Change type of pasid to unsigned int
PASID is defined as "int" although it's a 20-bit value and shouldn't be
negative int. To be consistent with type defined in iommu, define PASID
as "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Create this new patch to define PASID as "unsigned int" consistently in
ocxl (Thomas)
drivers/misc/ocxl/config.c| 3 ++-
drivers/misc/ocxl/link.c | 6 +++---
drivers/misc/ocxl/ocxl_internal.h | 6 +++---
drivers/misc/ocxl/pasid.c | 2 +-
drivers/misc/ocxl/trace.h | 20 ++--
include/misc/ocxl.h | 6 +++---
6 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index c8e19bfb5ef9..22d034caed3d 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -806,7 +806,8 @@ int ocxl_config_set_TL(struct pci_dev *dev, int tl_dvsec)
}
EXPORT_SYMBOL_GPL(ocxl_config_set_TL);
-int ocxl_config_terminate_pasid(struct pci_dev *dev, int afu_control, int
pasid)
+int ocxl_config_terminate_pasid(struct pci_dev *dev, int afu_control,
+ unsigned int pasid)
{
u32 val;
unsigned long timeout;
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 58d111afd9f6..931f6ae022db 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -492,7 +492,7 @@ static u64 calculate_cfg_state(bool kernel)
return state;
}
-int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
+int ocxl_link_add_pe(void *link_handle, unsigned int pasid, u32 pidr, u32 tidr,
u64 amr, struct mm_struct *mm,
void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
void *xsl_err_data)
@@ -572,7 +572,7 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32
pidr, u32 tidr,
}
EXPORT_SYMBOL_GPL(ocxl_link_add_pe);
-int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
+int ocxl_link_update_pe(void *link_handle, unsigned int pasid, __u16 tid)
{
struct ocxl_link *link = (struct ocxl_link *) link_handle;
struct spa *spa = link->spa;
@@ -608,7 +608,7 @@ int ocxl_link_update_pe(void *link_handle, int pasid, __u16
tid)
return rc;
}
-int ocxl_link_remove_pe(void *link_handle, int pasid)
+int ocxl_link_remove_pe(void *link_handle, unsigned int pasid)
{
struct ocxl_link *link = (struct ocxl_link *) link_handle;
struct spa *spa = link->spa;
diff --git a/drivers/misc/ocxl/ocxl_internal.h
b/drivers/misc/ocxl/ocxl_internal.h
index 345bf843a38e..3ca982ba7472 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -41,7 +41,7 @@ struct ocxl_afu {
struct ocxl_afu_config config;
int pasid_base;
int pasid_count; /* opened contexts */
- int pasid_max; /* maximum number of contexts */
+ unsigned int pasid_max; /* maximum number of contexts */
int actag_base;
int actag_enabled;
struct mutex contexts_lock;
@@ -69,7 +69,7 @@ struct ocxl_xsl_error {
struct ocxl_context {
struct ocxl_afu *afu;
- int pasid;
+ unsigned int pasid;
struct mutex status_mutex;
enum ocxl_context_status status;
struct address_space *mapping;
@@ -128,7 +128,7 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
* pasid: the PASID for the AFU context
* tid: the new thread id for the process element
*/
-int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
+int ocxl_link_update_pe(void *link_handle, unsigned int pasid, __u16 tid);
int ocxl_context_mmap(struct ocxl_context *ctx,
struct vm_area_struct *vma);
diff --git a/drivers/misc/ocxl/pasid.c b/drivers/misc/ocxl/pasid.c
index d14cb56e6920..a151fc8f0bec 100644
--- a/drivers/misc/ocxl/pasid.c
+++ b/drivers/misc/ocxl/pasid.c
@@ -80,7 +80,7 @@ static void range_free(struct list_head *head, u32 start, u32
size,
int ocxl_pasid_afu_alloc(struct ocxl_fn *fn, u32 size)
{
- int max_pasid;
+ unsigned int max_pasid;
if (fn->config.max_pasid_log < 0)
return -ENOSPC;
diff --git a/drivers/misc/ocxl/trace.h b/drivers/misc/ocxl/trace.h
index 17e21cb2addd..019e2fc63b1d 100644
--- a/drivers/misc/ocxl/trace.h
+++ b/drivers/misc/ocxl/trace.h
@@ -9,13 +9,13 @@
#include
DECLARE_EVENT_CLASS(ocxl_context,
- TP_PROTO(pid_t pid, void *spa, int pasid, u32 pidr, u32 tidr),
+ TP_PROTO(pid_t pid, void *spa, unsigned int pasid, u32 pidr, u32 tidr),
TP_ARGS(pid, spa, pasid, pidr, tidr),
TP_STRUCT__entry(
__field(pid_t, pid)
__field(void*, spa)
- __field(int, pasid)
+ __field(unsigned int, pasid)
__field(u32, pidr)
__field(u32, tidr)
),
@@ -38,21 +38,21 @@ DECLARE_EVENT_CLASS(ocxl_context,
);
DEFINE_EVENT(ocxl_context,
[PATCH v2 05/12] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in ENQCMDS. There isn't any usage of ENQCMD in the kernel
as of now.
The CPU feature flag is shown as "enqcmd" in /proc/cpuinfo.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Re-write commit message (Thomas)
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/cpuid-deps.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 02dabc9e77b0..4469618c410f 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -351,6 +351,7 @@
#define X86_FEATURE_CLDEMOTE (16*32+25) /* CLDEMOTE instruction */
#define X86_FEATURE_MOVDIRI(16*32+27) /* MOVDIRI instruction */
#define X86_FEATURE_MOVDIR64B (16*32+28) /* MOVDIR64B instruction */
+#define X86_FEATURE_ENQCMD (16*32+29) /* ENQCMD and ENQCMDS
instructions */
/* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */
#define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery
support */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 3cbe24ca80ab..3a02707c1f4d 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -69,6 +69,7 @@ static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_CQM_MBM_TOTAL,X86_FEATURE_CQM_LLC },
{ X86_FEATURE_CQM_MBM_LOCAL,X86_FEATURE_CQM_LLC },
{ X86_FEATURE_AVX512_BF16, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_ENQCMD, X86_FEATURE_XSAVES},
{}
};
--
2.19.1
[PATCH v2 12/12] x86/traps: Fix up invalid PASID
A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in the current thread's PASID MSR. The
#GP fault handler will initialize the MSR if a PASID has been allocated
for this process.
Decoding the user instruction is ugly and sets a bad architecture
precedent. It may not function if the faulting instruction is modified
after #GP.
Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
without a valid PASID value programmed. #GP error codes are 16 bits and all
16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other
choice was to reflect the error code in an MSR. ENQCMD can also cause #GP
when loading from the source operand, so its not fully comprehending all
the reasons. Rather than special case the ENQCMD, in future Intel may
choose a different fault mechanism for such cases if recovery is needed on
#GP.
The following heuristic is used to avoid decoding the user instructions
to determine the precise reason for the #GP fault:
1) If the mm for the process has not been allocated a PASID, this #GP
cannot be fixed.
2) If the PASID MSR is already initialized, then the #GP was for some
other reason
3) Try initializing the PASID MSR and returning. If the #GP was from
an ENQCMD this will fix it. If not, the #GP fault will be repeated
and will hit case "2".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Update the first paragraph of the commit message (Thomas)
- Add reasons why don't decode the user instruction and don't use
#GP error code (Thomas)
- Change get_task_mm() to current->mm (Thomas)
- Add comments on why IRQ is disabled during PASID fixup (Thomas)
- Add comment in fixup() that the function is called when #GP is from
user (so mm is not NULL) (Dave Hansen)
arch/x86/include/asm/iommu.h | 1 +
arch/x86/kernel/traps.c | 23 +
drivers/iommu/intel/svm.c| 39
3 files changed, 63 insertions(+)
diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
index ed41259fe7ac..e9365a5d6f7d 100644
--- a/arch/x86/include/asm/iommu.h
+++ b/arch/x86/include/asm/iommu.h
@@ -27,5 +27,6 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
}
void __free_pasid(struct mm_struct *mm);
+bool __fixup_pasid_exception(void);
#endif /* _ASM_X86_IOMMU_H */
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 4cc541051994..0f78d5cdddfe 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_64
#include
@@ -436,6 +437,16 @@ static enum kernel_gp_hint get_kernel_gp_address(struct
pt_regs *regs,
return GP_CANONICAL;
}
+static bool fixup_pasid_exception(void)
+{
+ if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM))
+ return false;
+ if (!static_cpu_has(X86_FEATURE_ENQCMD))
+ return false;
+
+ return __fixup_pasid_exception();
+}
+
#define GPFSTR "general protection fault"
dotraplinkage void do_general_protection(struct pt_regs *regs, long error_code)
@@ -447,6 +458,18 @@ dotraplinkage void do_general_protection(struct pt_regs
*regs, long error_code)
int ret;
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
+
+ /*
+* Perform the check for a user mode PASID exception before enable
+* interrupts. Doing this here ensures that the PASID MSR can be simply
+* accessed because the contents are known to be still associated
+* with the current process.
+*/
+ if (user_mode(regs) && fixup_pasid_exception()) {
+ cond_local_irq_enable(regs);
+ return;
+ }
+
cond_local_irq_enable(regs);
if (static_cpu_has(X86_FEATURE_UMIP)) {
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 27dc866b8461..81fd2380c0f9 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1078,3 +1078,42 @@ void __free_pasid(struct mm_struct *mm)
*/
ioasid_free(pasid);
}
+
+/*
+ * Apply some heuristics to see if the #GP fault was caused by a thread
+ * that hasn't had the IA32_PASID MSR initialized. If it looks like that
+ * is the problem, try initializing the IA32_PASID MSR. If the heuristic
+ * guesses incorrectly, take one more #GP fault.
+ */
+bool __fixup_pasid_exception(void)
+{
+ u64 pasid_msr;
+ unsigned int pasid;
+
+ /*
+* This function is called only when this #GP was triggered from user
+* space. So the mm cannot be NULL.
+*/
+ pasid = current->mm->pasid;
+ /* If the mm doesn't have a valid PASID, then can't help. */
+ if (invalid_pasid(pasid))
+ return false;
+
+ /*
+* Since IRQ is disabled now, the current task still owns the FPU on
+* this CPU and the PASID MSR can be
[PATCH v2 03/12] iommu/vt-d: Change flags type to unsigned int in binding mm
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this new patch per Thomas' comment.
drivers/iommu/intel/svm.c | 7 ---
include/linux/intel-iommu.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index b5618341b4b1..4e775e12ae52 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -427,7 +427,8 @@ int intel_svm_unbind_gpasid(struct device *dev, unsigned
int pasid)
/* Caller must hold pasid_mutex, mm reference */
static int
-intel_svm_bind_mm(struct device *dev, int flags, struct svm_dev_ops *ops,
+intel_svm_bind_mm(struct device *dev, unsigned int flags,
+ struct svm_dev_ops *ops,
struct mm_struct *mm, struct intel_svm_dev **sd)
{
struct intel_iommu *iommu = intel_svm_device_to_iommu(dev);
@@ -954,7 +955,7 @@ intel_svm_bind(struct device *dev, struct mm_struct *mm,
void *drvdata)
{
struct iommu_sva *sva = ERR_PTR(-EINVAL);
struct intel_svm_dev *sdev = NULL;
- int flags = 0;
+ unsigned int flags = 0;
int ret;
/*
@@ -963,7 +964,7 @@ intel_svm_bind(struct device *dev, struct mm_struct *mm,
void *drvdata)
* and intel_svm etc.
*/
if (drvdata)
- flags = *(int *)drvdata;
+ flags = *(unsigned int *)drvdata;
mutex_lock(_mutex);
ret = intel_svm_bind_mm(dev, flags, NULL, mm, );
if (ret)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 44fa8879f829..9abc30cf10fc 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -759,7 +759,7 @@ struct intel_svm {
struct mm_struct *mm;
struct intel_iommu *iommu;
- int flags;
+ unsigned int flags;
unsigned int pasid;
int gpasid; /* In case that guest PASID is different from host PASID */
struct list_head devs;
--
2.19.1
[PATCH v2 00/12] x86: tag application address space for devices
Typical hardware devices require a driver stack to translate application buffers to hardware addresses, and a kernel-user transition to notify the hardware of new work. What if both the translation and transition overhead could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD enabled hardware like Data Streaming Accelerator (DSA) aims to achieve. Applications map portals in their local-address-space and directly submit work to them using a new instruction. This series enables ENQCMD and associated management of the new MSR (MSR_IA32_PASID). This new MSR allows an application address space to be associated with what the PCIe spec calls a Process Address Space ID (PASID). This PASID tag is carried along with all requests between applications and devices and allows devices to interact with the process address space. SVA and ENQCMD enabled device drivers need this series. The phase 2 DSA patches with SVA and ENQCMD support was released on the top of this series: https://lore.kernel.org/patchwork/cover/1244060/ This series only provides simple and basic support for ENQCMD and the MSR: 1. Clean up type definitions (patch 1-3). These patches can be in a separate series. - Define "pasid" as "unsigned int" consistently (patch 1 and 2). - Define "flags" as "unsigned int" 2. Explain different various technical terms used in the series (patch 4). 3. Enumerate support for ENQCMD in the processor (patch 5). 4. Handle FPU PASID state and the MSR during context switch (patches 6-7). 5. Define "pasid" in mm_struct (patch 8). 5. Clear PASID state for new mm and forked and cloned thread (patch 9-10). 6. Allocate and free PASID for a process (patch 11). 7. Fix up the PASID MSR in #GP handler when one thread in a process executes ENQCMD for the first time (patches 12). This patch series and the DSA phase 2 series are in https://github.com/intel/idxd-driver/tree/idxd-stage2 References: 1. Detailed information on the ENQCMD/ENQCMDS instructions and the IA32_PASID MSR can be found in Intel Architecture Instruction Set Extensions and Future Features Programming Reference: https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf 2. Detailed information on DSA can be found in DSA specification: https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification Chang log: v2: - Add patches 1-3 to define "pasid" and "flags" as "unsigned int" consistently (Thomas) (these 3 patches could be in a separate patch set) - Add patch 8 to move "pasid" to generic mm_struct (Christoph). Jean-Philippe Brucker released a virtually same patch. Upstream only needs one of the two. - Add patch 9 to initialize PASID in a new mm. - Plus other changes described in each patch (Thomas) Ashok Raj (1): docs: x86: Add documentation for SVA (Shared Virtual Addressing) Fenghua Yu (10): iommu: Change type of pasid to unsigned int ocxl: Change type of pasid to unsigned int iommu/vt-d: Change flags type to unsigned int in binding mm x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions x86/msr-index: Define IA32_PASID MSR mm: Define pasid in mm fork: Clear PASID for new mm x86/process: Clear PASID state for a newly forked/cloned thread x86/mmu: Allocate/free PASID x86/traps: Fix up invalid PASID Yu-cheng Yu (1): x86/fpu/xstate: Add supervisor PASID state for ENQCMD feature Documentation/x86/index.rst| 1 + Documentation/x86/sva.rst | 287 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/fpu/types.h | 10 + arch/x86/include/asm/fpu/xstate.h | 2 +- arch/x86/include/asm/iommu.h | 3 + arch/x86/include/asm/mmu_context.h | 14 ++ arch/x86/include/asm/msr-index.h | 3 + arch/x86/kernel/cpu/cpuid-deps.c | 1 + arch/x86/kernel/fpu/xstate.c | 4 + arch/x86/kernel/process.c | 18 ++ arch/x86/kernel/traps.c| 23 ++ drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 5 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 +- drivers/iommu/amd/amd_iommu.h | 13 +- drivers/iommu/amd/amd_iommu_types.h| 12 +- drivers/iommu/amd/init.c | 4 +- drivers/iommu/amd/iommu.c | 41 ++-- drivers/iommu/amd/iommu_v2.c | 22 +- drivers/iommu/intel/debugfs.c | 2 +- drivers/iommu/intel/dmar.c | 13 +- drivers/iommu/intel/intel-pasid.h | 21 +- drivers/iommu/intel/iommu.c| 4 +- drivers/iommu/intel/pasid.c| 36 ++-- drivers/iommu/intel/svm.c | 159 -- drivers/iommu/iommu.c | 2 +- drivers/misc/ocxl/config.c | 3 +- drivers/misc/ocxl/link.c | 6 +- drivers/misc/ocxl/ocxl_internal.h | 6 +- drivers/misc/ocxl/pasid.c | 2 +-
Re: [PATCH] alpha: Fix build around srm_sysrq_reboot_op
On Thu, Jun 11, 2020 at 2:14 AM Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The patch introducing the struct was probably never compile tested,
> because it sets a handler with a wrong function signature. Wrap the
> handler into a functions with the correct signature to fix the build.
>
> Fixes: 0f1c9688a194 ("tty/sysrq: alpha: export and use __sysrq_get_key_op()")
> Cc: Emil Velikov
> Cc: Guenter Roeck
> Signed-off-by: Joerg Roedel
> ---
Thanks, applied.
Re: [PATCH 3/3] KVM:SVM: Enable INVPCID feature on AMD
On Fri, Jun 12, 2020 at 2:47 PM Babu Moger wrote:
>
>
>
> On 6/12/20 3:10 PM, Jim Mattson wrote:
> > On Fri, Jun 12, 2020 at 12:35 PM Babu Moger wrote:
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Jim Mattson
> >>> Sent: Thursday, June 11, 2020 6:51 PM
> >>> To: Moger, Babu
> >>> Cc: Wanpeng Li ; Joerg Roedel ;
> >>> the arch/x86 maintainers ; Sean Christopherson
> >>> ; Ingo Molnar ;
> >>> Borislav Petkov ; H . Peter Anvin ; Paolo
> >>> Bonzini ; Vitaly Kuznetsov ;
> >>> Thomas Gleixner ; LKML ;
> >>> kvm list
> >>> Subject: Re: [PATCH 3/3] KVM:SVM: Enable INVPCID feature on AMD
> >>>
> >>> On Thu, Jun 11, 2020 at 2:48 PM Babu Moger wrote:
>
> The following intercept is added for INVPCID instruction:
> CodeNameCause
> A2h VMEXIT_INVPCID INVPCID instruction
>
> The following bit is added to the VMCB layout control area
> to control intercept of INVPCID:
> Byte Offset Bit(s)Function
> 14h 2 intercept INVPCID
>
> For the guests with nested page table (NPT) support, the INVPCID
> feature works as running it natively. KVM does not need to do any
> special handling in this case.
>
> Interceptions are required in the following cases.
> 1. If the guest tries to disable the feature when the underlying
> hardware supports it. In this case hypervisor needs to report #UD.
> >>>
> >>> Per the AMD documentation, attempts to use INVPCID at CPL>0 will
> >>> result in a #GP, regardless of the intercept bit. If the guest CPUID
> >>> doesn't enumerate the feature, shouldn't the instruction raise #UD
> >>> regardless of CPL? This seems to imply that we should intercept #GP
> >>> and decode the instruction to see if we should synthesize #UD instead.
> >>
> >> Purpose here is to report UD when the guest CPUID doesn't enumerate the
> >> INVPCID feature When Bare-metal supports it. It seems to work fine for
> >> that purpose. You are right. The #GP for CPL>0 takes precedence over
> >> interception. No. I am not planning to intercept GP.
> >
> > WIthout intercepting #GP, you fail to achieve your stated purpose.
>
> I think I have misunderstood this part. I was not inteding to change the
> #GP behaviour. I will remove this part. My intension of these series is to
> handle invpcid in shadow page mode. I have verified that part. Hope I did
> not miss anything else.
You don't really have to intercept INVPCID when tdp is in use, right?
There are certainly plenty of operations for which kvm does not
properly raise #UD when they aren't enumerated in the guest CPUID.
> >> I will change the text. How about this?
> >>
> >> Interceptions are required in the following cases.
> >> 1. If the guest CPUID doesn't enumerate the INVPCID feature when the
> >> underlying hardware supports it, hypervisor needs to report UD. However,
> >> #GP for CPL>0 takes precedence over interception.
> >
> > This text is not internally consistent. In one sentence, you say that
> > "hypervisor needs to report #UD." In the next sentence, you are
> > essentially saying that the hypervisor doesn't need to report #UD.
> > Which is it?
> >
> 2. When the guest is running with shadow page table enabled, in
> this case the hypervisor needs to handle the tlbflush based on the
> type of invpcid instruction type.
>
> AMD documentation for INVPCID feature is available at "AMD64
> Architecture Programmer’s Manual Volume 2: System Programming,
> Pub. 24593 Rev. 3.34(or later)"
>
> The documentation can be obtained at the links below:
> Link:
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.a
> >>> md.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdfdata=02%7C01%7
> >>> Cbabu.moger%40amd.com%7C36861b25f6d143e3b38e08d80e624472%7C3dd8
> >>> 961fe4884e608e11a82d994e183d%7C0%7C0%7C637275163374103811s
> >>> data=E%2Fdb6T%2BdO4nrtUoqhKidF6XyorsWrphj6O4WwNZpmYA%3Dres
> >>> erved=0
> Link:
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.
> >>> kernel.org%2Fshow_bug.cgi%3Fid%3D206537data=02%7C01%7Cbabu.m
> >>> oger%40amd.com%7C36861b25f6d143e3b38e08d80e624472%7C3dd8961fe488
> >>> 4e608e11a82d994e183d%7C0%7C0%7C637275163374103811sdata=b81
> >>> 9W%2FhKS93%2BAp3QvcsR0BwTQpUVUFMbIaNaisgWHRY%3Dreserved=
> >>> 0
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/include/asm/svm.h |4
> arch/x86/include/uapi/asm/svm.h |2 ++
> arch/x86/kvm/svm/svm.c | 42
> >>> +++
> 3 files changed, 48 insertions(+)
>
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index 62649fba8908..6488094f67fa 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -55,6 +55,10 @@ enum {
> INTERCEPT_RDPRU,
> };
>
> +/* Extended Intercept bits */
>
Re: [GIT PULL] sound fixes for 5.8-rc1
On Fri, Jun 12, 2020 at 4:42 AM Srinivas Kandagatla wrote: > > Thanks John for reporting this, > > On 12/06/2020 01:49, John Stultz wrote: > > On Thu, Jun 11, 2020 at 5:13 PM John Stultz wrote: > >> > >> On Thu, Jun 11, 2020 at 6:39 AM Takashi Iwai wrote: > >>> sound fixes for 5.8-rc1 > >>> > >>> Here are last-minute fixes gathered before merge window close; > >>> a few fixes are for the core while the rest majority are driver > >>> fixes. > >>> > >>> * PCM locking annotation fixes and the possible self-lock fix > >>> * ASoC DPCM regression fixes with multi-CPU DAI > >> > >> Just as a heads up, we just recently got HDMI audio working on the > >> Dragonboard 845c (Vinod has patches he's sending out here in the next > >> few days), but they suddenly stopped working today with the following > >> error: > >> [ 13.110725] msm-snd-sdm845 soc@0:sound: snd-soc-dummy-dai <-> > >> MultiMedia1 mapping ok > >> [ 13.119343] msm-snd-sdm845 soc@0:sound: snd-soc-dummy-dai <-> > >> MultiMedia2 mapping ok > >> [ 13.127969] msm-snd-sdm845 soc@0:sound: snd-soc-dummy-dai <-> > >> MultiMedia3 mapping ok > >> [ 13.135891] msm-snd-sdm845 soc@0:sound: Compress ASoC: > >> snd-soc-dummy-dai <-> MultiMedia4 mapping ok > >> [ 13.145042] msm-snd-sdm845 soc@0:sound: CPU DAI QUAT_MI2S_RX for > >> rtd HDMI Playback does not support capture > >> [ 13.154873] msm-snd-sdm845 soc@0:sound: ASoC: can't create pcm HDMI > >> Playback :-22 > >> [ 13.165634] snd-malloc: invalid device type 0 > >> [ 13.170057] snd-malloc: invalid device type 0 > >> [ 13.174888] msm-snd-sdm845 soc@0:sound: Sound card registration failed > >> [ 13.181574] msm-snd-sdm845: probe of soc@0:sound failed with error -22 > >> > >> I've bisected it down to the following commit from this pull req: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b73287f0b0745961b14e5ebcce92cc8ed24d4d52 > >> > >> Without this patch: > >> [ 13.056906] msm-snd-sdm845 soc@0:sound: snd-soc-dummy-dai <-> > >> MultiMedia1 mapping ok > >> [ 13.075465] msm-snd-sdm845 soc@0:sound: snd-soc-dummy-dai <-> > >> MultiMedia2 mapping ok > >> [ 13.092949] msm-snd-sdm845 soc@0:sound: snd-soc-dummy-dai <-> > >> MultiMedia3 mapping ok > >> [ 13.109704] msm-snd-sdm845 soc@0:sound: Compress ASoC: > >> snd-soc-dummy-dai <-> MultiMedia4 mapping ok > >> [ 13.125584] msm-snd-sdm845 soc@0:sound: i2s-hifi <-> QUAT_MI2S_RX > >> mapping ok > >> [ 13.125621] msm-snd-sdm845 soc@0:sound: multicodec <-> SLIMBUS_0_RX > >> mapping ok > >> [ 13.141682] msm-snd-sdm845 soc@0:sound: wcd934x_tx1 <-> > >> SLIMBUS_0_TX mapping ok > >> ... > >> > >> I've not managed to dig in with much analysis yet (possibly something > >> off with the current patches we have), but wanted to raise the issue > >> in case others start to see it too. > > > > I don't know the backgroun again, but would something like the > > following make sense? > > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP=7e49b248db77b5ed29b2aa278268e77650c75482 > > > > It avoids failing completely if playback or capture isn't found. > > Can you please try these two patches, I think the problem is that FE > dailinks are always set to bidirectional, this two patches should fix it. > > https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/?h=gapless/v2=bb7ce65a0ca1640cd9ff301c885f56ce00519834 > > https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/?h=gapless/v2=9b568e491f0410b453aaf5a147b75252a6943ffd > > > Once you confirm I can send them to list as fixes. Yep! These two patches work for me! Thanks so much for the quick fix! -john
Re: [PATCH 2/2] ASoC: qcom: common: set correct directions for dailinks
On Fri, Jun 12, 2020 at 5:38 AM Srinivas Kandagatla wrote: > > Currently both FE and BE dai-links are configured bi-directional, > However the DSP BE dais are only single directional, > so set the directions as supported by the BE dais. > > Fixes: c25e295cd77b (ASoC: qcom: Add support to parse common audio device > nodes") > Reported-by: John Stultz > Signed-off-by: Srinivas Kandagatla > --- Yep, this resolves the recent issue for me! Thanks so much for the quick fix! Tested-by: John Stultz thanks again! -john
Re: [PATCH v3 4/7] Bluetooth: Add handler of MGMT_OP_REMOVE_ADV_MONITOR
Hi Jakub, I uploaded v4 to address these. Thanks for the reminder. Regards, Miao On Fri, Jun 12, 2020 at 10:49 AM Jakub Kicinski wrote: > > On Thu, 11 Jun 2020 23:15:26 -0700 Miao-chen Chou wrote: > > This adds the request handler of MGMT_OP_REMOVE_ADV_MONITOR command. > > Note that the controller-based monitoring is not yet in place. This > > removes the internal monitor(s) without sending HCI traffic, so the > > request returns immediately. > > > > The following test was performed. > > - Issue btmgmt advmon-remove with valid and invalid handles. > > > > Signed-off-by: Miao-chen Chou > > Still doesn't build cleanly with W=1 C=1 > > net/bluetooth/mgmt.c:4009:46: warning: incorrect type in argument 2 > (different base types) > net/bluetooth/mgmt.c:4009:46:expected unsigned short [usertype] handle > net/bluetooth/mgmt.c:4009:46:got restricted __le16 [usertype] > monitor_handle > net/bluetooth/mgmt.c:4018:29: warning: cast from restricted __le16
linux-next: manual merge of the crypto-current tree with Linus' tree
Hi all,
Today's linux-next merge of the crypto-current tree got a conflict in:
drivers/crypto/ccp/sev-dev.c
between commit:
835ae3bb530a ("drivers/crypto/ccp/sev-dev.c: get rid of pointless
access_ok()")
from Linus' tree and commit:
832910f2e6b5 ("crypto: ccp - Fix sparse warnings in sev-dev")
from the crypto-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/crypto/ccp/sev-dev.c
index a2426334be61,aa576529283b..
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@@ -394,7 -395,9 +395,8 @@@ static int sev_ioctl_do_pek_csr(struct
goto cmd;
/* allocate a physically contiguous buffer to store the CSR blob */
+ input_address = (void __user *)input.address;
- if (!access_ok(input_address, input.length) ||
- input.length > SEV_FW_BLOB_MAX_SIZE) {
+ if (input.length > SEV_FW_BLOB_MAX_SIZE) {
ret = -EFAULT;
goto e_free;
}
@@@ -631,6 -635,13 +634,7 @@@ static int sev_ioctl_do_get_id2(struct
if (copy_from_user(, (void __user *)argp->data, sizeof(input)))
return -EFAULT;
- /* Check if we have write access to the userspace buffer */
+ input_address = (void __user *)input.address;
- if (input.address &&
- input.length &&
- !access_ok(input_address, input.length))
- return -EFAULT;
-
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@@ -745,8 -757,12 +750,11 @@@ static int sev_ioctl_do_pdh_export(stru
!input.cert_chain_address)
goto cmd;
+ input_pdh_cert_address = (void __user *)input.pdh_cert_address;
+ input_cert_chain_address = (void __user *)input.cert_chain_address;
+
/* Allocate a physically contiguous buffer to store the PDH blob. */
- if ((input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE) ||
- !access_ok(input_pdh_cert_address, input.pdh_cert_len)) {
+ if (input.pdh_cert_len > SEV_FW_BLOB_MAX_SIZE) {
ret = -EFAULT;
goto e_free;
}
pgpXK3KvvTYen.pgp
Description: OpenPGP digital signature
[PATCH v4 1/7] Bluetooth: Add definitions for advertisement monitor features
This adds support for Advertisement Monitor API. Here are the commands
and events added.
- Read Advertisement Monitor Feature command
- Add Advertisement Pattern Monitor command
- Remove Advertisement Monitor command
- Advertisement Monitor Added event
- Advertisement Monitor Removed event
Signed-off-by: Miao-chen Chou
---
Changes in v4: None
Changes in v3:
- Update command/event opcodes.
- Correct data types.
Changes in v2: None
include/net/bluetooth/mgmt.h | 49
1 file changed, 49 insertions(+)
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 16e0d87bd8fae..fcc5d0349f549 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -702,6 +702,45 @@ struct mgmt_rp_set_exp_feature {
__le32 flags;
} __packed;
+#define MGMT_ADV_MONITOR_FEATURE_MASK_OR_PATTERNSBIT(0)
+
+#define MGMT_OP_READ_ADV_MONITOR_FEATURES 0x0051
+#define MGMT_READ_ADV_MONITOR_FEATURES_SIZE0
+struct mgmt_rp_read_adv_monitor_features {
+ __le32 supported_features;
+ __le32 enabled_features;
+ __le16 max_num_handles;
+ __u8 max_num_patterns;
+ __le16 num_handles;
+ __le16 handles[];
+} __packed;
+
+struct mgmt_adv_pattern {
+ __u8 ad_type;
+ __u8 offset;
+ __u8 length;
+ __u8 value[31];
+} __packed;
+
+#define MGMT_OP_ADD_ADV_PATTERNS_MONITOR 0x0052
+struct mgmt_cp_add_adv_patterns_monitor {
+ __u8 pattern_count;
+ struct mgmt_adv_pattern patterns[];
+} __packed;
+#define MGMT_ADD_ADV_PATTERNS_MONITOR_SIZE 1
+struct mgmt_rp_add_adv_patterns_monitor {
+ __le16 monitor_handle;
+} __packed;
+
+#define MGMT_OP_REMOVE_ADV_MONITOR 0x0053
+struct mgmt_cp_remove_adv_monitor {
+ __le16 monitor_handle;
+} __packed;
+#define MGMT_REMOVE_ADV_MONITOR_SIZE 2
+struct mgmt_rp_remove_adv_monitor {
+ __le16 monitor_handle;
+} __packed;
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
__le16 opcode;
@@ -933,3 +972,13 @@ struct mgmt_ev_exp_feature_changed {
__u8uuid[16];
__le32 flags;
} __packed;
+
+#define MGMT_EV_ADV_MONITOR_ADDED 0x002b
+struct mgmt_ev_adv_monitor_added {
+ __le16 monitor_handle;
+} __packed;
+
+#define MGMT_EV_ADV_MONITOR_REMOVED0x002c
+struct mgmt_ev_adv_monitor_removed {
+ __le16 monitor_handle;
+} __packed;
--
2.26.2
[PATCH v4 4/7] Bluetooth: Add handler of MGMT_OP_REMOVE_ADV_MONITOR
This adds the request handler of MGMT_OP_REMOVE_ADV_MONITOR command.
Note that the controller-based monitoring is not yet in place. This
removes the internal monitor(s) without sending HCI traffic, so the
request returns immediately.
The following test was performed.
- Issue btmgmt advmon-remove with valid and invalid handles.
Signed-off-by: Miao-chen Chou
---
Changes in v4:
- Fix warnings.
Changes in v3:
- Update the opcode in the mgmt table.
- Convert the endianness of the returned handle.
Changes in v2: None
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 31 +++
net/bluetooth/mgmt.c | 32
3 files changed, 64 insertions(+)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 862d94f711bc0..78ac7fd282d77 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1242,6 +1242,7 @@ void hci_adv_instances_set_rpa_expired(struct hci_dev
*hdev, bool rpa_expired);
void hci_adv_monitors_clear(struct hci_dev *hdev);
void hci_free_adv_monitor(struct adv_monitor *monitor);
int hci_add_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor);
+int hci_remove_adv_monitor(struct hci_dev *hdev, u16 handle);
void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index fdbb58eb2fb22..d0f30e2e29471 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3041,6 +3041,37 @@ int hci_add_adv_monitor(struct hci_dev *hdev, struct
adv_monitor *monitor)
return 0;
}
+static int free_adv_monitor(int id, void *ptr, void *data)
+{
+ struct hci_dev *hdev = data;
+ struct adv_monitor *monitor = ptr;
+
+ idr_remove(>adv_monitors_idr, monitor->handle);
+ hci_free_adv_monitor(monitor);
+
+ return 0;
+}
+
+/* This function requires the caller holds hdev->lock */
+int hci_remove_adv_monitor(struct hci_dev *hdev, u16 handle)
+{
+ struct adv_monitor *monitor;
+
+ if (handle) {
+ monitor = idr_find(>adv_monitors_idr, handle);
+ if (!monitor)
+ return -ENOENT;
+
+ idr_remove(>adv_monitors_idr, monitor->handle);
+ hci_free_adv_monitor(monitor);
+ } else {
+ /* Remove all monitors if handle is 0. */
+ idr_for_each(>adv_monitors_idr, _adv_monitor, hdev);
+ }
+
+ return 0;
+}
+
struct bdaddr_list *hci_bdaddr_list_lookup(struct list_head *bdaddr_list,
bdaddr_t *bdaddr, u8 type)
{
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 8e0d4ccf81f15..887e193ce0038 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -114,6 +114,7 @@ static const u16 mgmt_commands[] = {
MGMT_OP_SET_EXP_FEATURE,
MGMT_OP_READ_ADV_MONITOR_FEATURES,
MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
+ MGMT_OP_REMOVE_ADV_MONITOR,
};
static const u16 mgmt_events[] = {
@@ -3994,6 +3995,36 @@ static int add_adv_patterns_monitor(struct sock *sk,
struct hci_dev *hdev,
return err;
}
+static int remove_adv_monitor(struct sock *sk, struct hci_dev *hdev,
+ void *data, u16 len)
+{
+ struct mgmt_cp_remove_adv_monitor *cp = data;
+ struct mgmt_rp_remove_adv_monitor rp;
+ int err;
+
+ BT_DBG("request for %s", hdev->name);
+
+ hci_dev_lock(hdev);
+
+ err = hci_remove_adv_monitor(hdev, __le16_to_cpu(cp->monitor_handle));
+ if (err == -ENOENT) {
+ err = mgmt_cmd_status(sk, hdev->id, MGMT_OP_REMOVE_ADV_MONITOR,
+ MGMT_STATUS_INVALID_INDEX);
+ goto unlock;
+ }
+
+ hci_dev_unlock(hdev);
+
+ rp.monitor_handle = cp->monitor_handle;
+
+ return mgmt_cmd_complete(sk, hdev->id, MGMT_OP_REMOVE_ADV_MONITOR,
+MGMT_STATUS_SUCCESS, , sizeof(rp));
+
+unlock:
+ hci_dev_unlock(hdev);
+ return err;
+}
+
static void read_local_oob_data_complete(struct hci_dev *hdev, u8 status,
u16 opcode, struct sk_buff *skb)
{
@@ -7451,6 +7482,7 @@ static const struct hci_mgmt_handler mgmt_handlers[] = {
{ read_adv_monitor_features, MGMT_READ_ADV_MONITOR_FEATURES_SIZE },
{ add_adv_patterns_monitor, MGMT_ADD_ADV_PATTERNS_MONITOR_SIZE,
HCI_MGMT_VAR_LEN },
+ { remove_adv_monitor, MGMT_REMOVE_ADV_MONITOR_SIZE },
};
void mgmt_index_added(struct hci_dev *hdev)
--
2.26.2
[PATCH v4 5/7] Bluetooth: Notify adv monitor added event
This notifies management sockets on MGMT_EV_ADV_MONITOR_ADDED event.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-add command on one
console and observe a MGMT_EV_ADV_MONITOR_ADDED event on the other
Signed-off-by: Miao-chen Chou
---
Changes in v4: None
Changes in v3:
- Convert the endianness of the returned handle.
Changes in v2: None
net/bluetooth/mgmt.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 887e193ce0038..0a1e89ce75eae 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -155,6 +155,7 @@ static const u16 mgmt_events[] = {
MGMT_EV_EXT_INFO_CHANGED,
MGMT_EV_PHY_CONFIGURATION_CHANGED,
MGMT_EV_EXP_FEATURE_CHANGED,
+ MGMT_EV_ADV_MONITOR_ADDED,
};
static const u16 mgmt_untrusted_commands[] = {
@@ -3853,6 +3854,16 @@ static int set_exp_feature(struct sock *sk, struct
hci_dev *hdev,
MGMT_STATUS_NOT_SUPPORTED);
}
+static void mgmt_adv_monitor_added(struct sock *sk, struct hci_dev *hdev,
+ u16 handle)
+{
+ struct mgmt_ev_adv_monitor_added ev;
+
+ ev.monitor_handle = cpu_to_le16(handle);
+
+ mgmt_event(MGMT_EV_ADV_MONITOR_ADDED, hdev, , sizeof(ev), sk);
+}
+
static int read_adv_monitor_features(struct sock *sk, struct hci_dev *hdev,
void *data, u16 len)
{
@@ -3905,8 +3916,8 @@ static int add_adv_patterns_monitor(struct sock *sk,
struct hci_dev *hdev,
struct mgmt_rp_add_adv_patterns_monitor rp;
struct adv_monitor *m = NULL;
struct adv_pattern *p = NULL;
+ unsigned int mp_cnt = 0, prev_adv_monitors_cnt;
__u8 cp_ofst = 0, cp_len = 0;
- unsigned int mp_cnt = 0;
int err, i;
BT_DBG("request for %s", hdev->name);
@@ -3970,6 +3981,8 @@ static int add_adv_patterns_monitor(struct sock *sk,
struct hci_dev *hdev,
hci_dev_lock(hdev);
+ prev_adv_monitors_cnt = hdev->adv_monitors_cnt;
+
err = hci_add_adv_monitor(hdev, m);
if (err) {
if (err == -ENOSPC) {
@@ -3980,6 +3993,9 @@ static int add_adv_patterns_monitor(struct sock *sk,
struct hci_dev *hdev,
goto unlock;
}
+ if (hdev->adv_monitors_cnt > prev_adv_monitors_cnt)
+ mgmt_adv_monitor_added(sk, hdev, m->handle);
+
hci_dev_unlock(hdev);
rp.monitor_handle = cpu_to_le16(m->handle);
--
2.26.2
[PATCH v4 6/7] Bluetooth: Notify adv monitor removed event
This notifies management sockets on MGMT_EV_ADV_MONITOR_REMOVED event.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-remove command on one
console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other.
Signed-off-by: Miao-chen Chou
---
Changes in v4: None
Changes in v3:
- Convert the endianness of the returned handle.
Changes in v2: None
net/bluetooth/mgmt.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 0a1e89ce75eae..325e528a1773e 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -156,6 +156,7 @@ static const u16 mgmt_events[] = {
MGMT_EV_PHY_CONFIGURATION_CHANGED,
MGMT_EV_EXP_FEATURE_CHANGED,
MGMT_EV_ADV_MONITOR_ADDED,
+ MGMT_EV_ADV_MONITOR_REMOVED,
};
static const u16 mgmt_untrusted_commands[] = {
@@ -3864,6 +3865,16 @@ static void mgmt_adv_monitor_added(struct sock *sk,
struct hci_dev *hdev,
mgmt_event(MGMT_EV_ADV_MONITOR_ADDED, hdev, , sizeof(ev), sk);
}
+static void mgmt_adv_monitor_removed(struct sock *sk, struct hci_dev *hdev,
+u16 handle)
+{
+ struct mgmt_ev_adv_monitor_added ev;
+
+ ev.monitor_handle = cpu_to_le16(handle);
+
+ mgmt_event(MGMT_EV_ADV_MONITOR_REMOVED, hdev, , sizeof(ev), sk);
+}
+
static int read_adv_monitor_features(struct sock *sk, struct hci_dev *hdev,
void *data, u16 len)
{
@@ -4016,12 +4027,15 @@ static int remove_adv_monitor(struct sock *sk, struct
hci_dev *hdev,
{
struct mgmt_cp_remove_adv_monitor *cp = data;
struct mgmt_rp_remove_adv_monitor rp;
+ unsigned int prev_adv_monitors_cnt;
int err;
BT_DBG("request for %s", hdev->name);
hci_dev_lock(hdev);
+ prev_adv_monitors_cnt = hdev->adv_monitors_cnt;
+
err = hci_remove_adv_monitor(hdev, __le16_to_cpu(cp->monitor_handle));
if (err == -ENOENT) {
err = mgmt_cmd_status(sk, hdev->id, MGMT_OP_REMOVE_ADV_MONITOR,
@@ -4029,6 +4043,9 @@ static int remove_adv_monitor(struct sock *sk, struct
hci_dev *hdev,
goto unlock;
}
+ if (hdev->adv_monitors_cnt < prev_adv_monitors_cnt)
+ mgmt_adv_monitor_removed(sk, hdev, cp->monitor_handle);
+
hci_dev_unlock(hdev);
rp.monitor_handle = cp->monitor_handle;
--
2.26.2
[PATCH v4 2/7] Bluetooth: Add handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
command. Since the controller-based monitoring is not yet in place, this
report only the supported features but not the enabled features.
The following test was performed.
- Issuing btmgmt advmon-features.
Signed-off-by: Miao-chen Chou
---
Changes in v4: None
Changes in v3:
- Update the opcode in the mgmt table.
Changes in v2:
- Convert the values from little-endian to CPU order.
- Fix comment style and improve readability.
include/net/bluetooth/hci_core.h | 24 ++
net/bluetooth/hci_core.c | 10 +-
net/bluetooth/mgmt.c | 54
net/bluetooth/msft.c | 7 +
net/bluetooth/msft.h | 9 ++
5 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index cdd4f1db8670e..431fe0265dcfb 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -25,6 +25,7 @@
#ifndef __HCI_CORE_H
#define __HCI_CORE_H
+#include
#include
#include
@@ -220,6 +221,24 @@ struct adv_info {
#define HCI_MAX_ADV_INSTANCES 5
#define HCI_DEFAULT_ADV_DURATION 2
+struct adv_pattern {
+ struct list_head list;
+ __u8 ad_type;
+ __u8 offset;
+ __u8 length;
+ __u8 value[HCI_MAX_AD_LENGTH];
+};
+
+struct adv_monitor {
+ struct list_head patterns;
+ boolactive;
+ __u16 handle;
+};
+
+#define HCI_MIN_ADV_MONITOR_HANDLE 1
+#define HCI_MAX_ADV_MONITOR_NUM_HANDLES32
+#define HCI_MAX_ADV_MONITOR_NUM_PATTERNS 16
+
#define HCI_MAX_SHORT_NAME_LENGTH 10
/* Min encryption key size to match with SMP */
@@ -477,6 +496,9 @@ struct hci_dev {
__u16 adv_instance_timeout;
struct delayed_work adv_instance_expire;
+ struct idr adv_monitors_idr;
+ unsigned intadv_monitors_cnt;
+
__u8irk[16];
__u32 rpa_timeout;
struct delayed_work rpa_expired;
@@ -1217,6 +1239,8 @@ int hci_add_adv_instance(struct hci_dev *hdev, u8
instance, u32 flags,
int hci_remove_adv_instance(struct hci_dev *hdev, u8 instance);
void hci_adv_instances_set_rpa_expired(struct hci_dev *hdev, bool rpa_expired);
+void hci_adv_monitors_clear(struct hci_dev *hdev);
+
void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb);
void hci_init_sysfs(struct hci_dev *hdev);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 83ce665d3cbfb..bfcf00e4dfa92 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -26,7 +26,6 @@
/* Bluetooth HCI core. */
#include
-#include
#include
#include
#include
@@ -2996,6 +2995,12 @@ int hci_add_adv_instance(struct hci_dev *hdev, u8
instance, u32 flags,
return 0;
}
+/* This function requires the caller holds hdev->lock */
+void hci_adv_monitors_clear(struct hci_dev *hdev)
+{
+ idr_destroy(>adv_monitors_idr);
+}
+
struct bdaddr_list *hci_bdaddr_list_lookup(struct list_head *bdaddr_list,
bdaddr_t *bdaddr, u8 type)
{
@@ -3577,6 +3582,8 @@ int hci_register_dev(struct hci_dev *hdev)
queue_work(hdev->req_workqueue, >power_on);
+ idr_init(>adv_monitors_idr);
+
return id;
err_wqueue:
@@ -3647,6 +3654,7 @@ void hci_unregister_dev(struct hci_dev *hdev)
hci_smp_irks_clear(hdev);
hci_remote_oob_data_clear(hdev);
hci_adv_instances_clear(hdev);
+ hci_adv_monitors_clear(hdev);
hci_bdaddr_list_clear(>le_white_list);
hci_bdaddr_list_clear(>le_resolv_list);
hci_conn_params_clear_all(hdev);
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 9e8a36ca3..63536d6332d45 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -36,6 +36,7 @@
#include "hci_request.h"
#include "smp.h"
#include "mgmt_util.h"
+#include "msft.h"
#define MGMT_VERSION 1
#define MGMT_REVISION 17
@@ -111,6 +112,7 @@ static const u16 mgmt_commands[] = {
MGMT_OP_READ_SECURITY_INFO,
MGMT_OP_READ_EXP_FEATURES_INFO,
MGMT_OP_SET_EXP_FEATURE,
+ MGMT_OP_READ_ADV_MONITOR_FEATURES,
};
static const u16 mgmt_events[] = {
@@ -3849,6 +3851,51 @@ static int set_exp_feature(struct sock *sk, struct
hci_dev *hdev,
MGMT_STATUS_NOT_SUPPORTED);
}
+static int read_adv_monitor_features(struct sock *sk, struct hci_dev *hdev,
+void *data, u16 len)
+{
+ struct adv_monitor *monitor = NULL;
+ struct mgmt_rp_read_adv_monitor_features *rp = NULL;
+ int handle;
+ size_t rp_size = 0;
+ __u32 supported = 0;
+ __u16 num_handles = 0;
+ __u16 handles[HCI_MAX_ADV_MONITOR_NUM_HANDLES];
+
+ BT_DBG("request for %s", hdev->name);
+
+
[PATCH v4 7/7] Bluetooth: Update background scan and report device based on advertisement monitors
This calls hci_update_background_scan() when there is any update on the
advertisement monitors. If there is at least one advertisement monitor,
the filtering policy of scan parameters should be 0x00. This also reports
device found mgmt events if there is at least one monitor.
The following cases were tested with btmgmt advmon-* commands.
(1) add a ADV monitor and observe that the passive scanning is
triggered.
(2) remove the last ADV monitor and observe that the passive scanning is
terminated.
(3) with a LE peripheral paired, repeat (1) and observe the passive
scanning continues.
(4) with a LE peripheral paired, repeat (2) and observe the passive
scanning continues.
(5) with a ADV monitor, suspend/resume the host and observe the passive
scanning continues.
Signed-off-by: Miao-chen Chou
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 13 +
net/bluetooth/hci_event.c| 5 +++--
net/bluetooth/hci_request.c | 17 ++---
net/bluetooth/mgmt.c | 5 -
5 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 78ac7fd282d77..1ce89e546a64e 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1243,6 +1243,7 @@ void hci_adv_monitors_clear(struct hci_dev *hdev);
void hci_free_adv_monitor(struct adv_monitor *monitor);
int hci_add_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor);
int hci_remove_adv_monitor(struct hci_dev *hdev, u16 handle);
+bool hci_is_adv_monitoring(struct hci_dev *hdev);
void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d0f30e2e29471..2d318916e9ebc 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3005,6 +3005,8 @@ void hci_adv_monitors_clear(struct hci_dev *hdev)
hci_free_adv_monitor(monitor);
idr_destroy(>adv_monitors_idr);
+
+ hci_update_background_scan(hdev);
}
void hci_free_adv_monitor(struct adv_monitor *monitor)
@@ -3038,6 +3040,9 @@ int hci_add_adv_monitor(struct hci_dev *hdev, struct
adv_monitor *monitor)
hdev->adv_monitors_cnt++;
monitor->handle = handle;
+
+ hci_update_background_scan(hdev);
+
return 0;
}
@@ -3069,9 +3074,17 @@ int hci_remove_adv_monitor(struct hci_dev *hdev, u16
handle)
idr_for_each(>adv_monitors_idr, _adv_monitor, hdev);
}
+ hci_update_background_scan(hdev);
+
return 0;
}
+/* This function requires the caller holds hdev->lock */
+bool hci_is_adv_monitoring(struct hci_dev *hdev)
+{
+ return !idr_is_empty(>adv_monitors_idr);
+}
+
struct bdaddr_list *hci_bdaddr_list_lookup(struct list_head *bdaddr_list,
bdaddr_t *bdaddr, u8 type)
{
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index cfeaee347db32..cbcc0b590fd41 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5447,14 +5447,15 @@ static void process_adv_report(struct hci_dev *hdev, u8
type, bdaddr_t *bdaddr,
/* Passive scanning shouldn't trigger any device found events,
* except for devices marked as CONN_REPORT for which we do send
-* device found events.
+* device found events, or advertisement monitoring requested.
*/
if (hdev->le_scan_type == LE_SCAN_PASSIVE) {
if (type == LE_ADV_DIRECT_IND)
return;
if (!hci_pend_le_action_lookup(>pend_le_reports,
- bdaddr, bdaddr_type))
+ bdaddr, bdaddr_type) &&
+ idr_is_empty(>adv_monitors_idr))
return;
if (type == LE_ADV_NONCONN_IND || type == LE_ADV_SCAN_IND)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 1acf5b8e0910c..d465dbbb1963c 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -418,11 +418,15 @@ static void __hci_update_background_scan(struct
hci_request *req)
*/
hci_discovery_filter_clear(hdev);
+ BT_DBG("%s ADV monitoring is %s", hdev->name,
+ hci_is_adv_monitoring(hdev) ? "on" : "off");
+
if (list_empty(>pend_le_conns) &&
- list_empty(>pend_le_reports)) {
+ list_empty(>pend_le_reports) &&
+ !hci_is_adv_monitoring(hdev)) {
/* If there is no pending LE connections or devices
-* to be scanned for, we should stop the background
-* scanning.
+* to be scanned for or no ADV monitors, we should stop the
+* background scanning.
*/
/* If controller is not scanning we are done. */
@@
[PATCH v4 3/7] Bluetooth: Add handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR
This adds the request handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR command.
Note that the controller-based monitoring is not yet in place. This tracks
the content of the monitor without sending HCI traffic, so the request
returns immediately.
The following manual test was performed.
- Issue btmgmt advmon-add with valid and invalid inputs.
- Issue btmgmt advmon-add more the allowed number of monitors.
Signed-off-by: Miao-chen Chou
---
Changes in v4: None
Changes in v3:
- Update the opcode in the mgmt table.
- Convert the endianness of the returned handle.
Changes in v2: None
include/net/bluetooth/hci_core.h | 2 +
net/bluetooth/hci_core.c | 40 +
net/bluetooth/mgmt.c | 100 +++
3 files changed, 142 insertions(+)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 431fe0265dcfb..862d94f711bc0 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1240,6 +1240,8 @@ int hci_remove_adv_instance(struct hci_dev *hdev, u8
instance);
void hci_adv_instances_set_rpa_expired(struct hci_dev *hdev, bool rpa_expired);
void hci_adv_monitors_clear(struct hci_dev *hdev);
+void hci_free_adv_monitor(struct adv_monitor *monitor);
+int hci_add_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor);
void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bfcf00e4dfa92..fdbb58eb2fb22 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2998,9 +2998,49 @@ int hci_add_adv_instance(struct hci_dev *hdev, u8
instance, u32 flags,
/* This function requires the caller holds hdev->lock */
void hci_adv_monitors_clear(struct hci_dev *hdev)
{
+ struct adv_monitor *monitor;
+ int handle;
+
+ idr_for_each_entry(>adv_monitors_idr, monitor, handle)
+ hci_free_adv_monitor(monitor);
+
idr_destroy(>adv_monitors_idr);
}
+void hci_free_adv_monitor(struct adv_monitor *monitor)
+{
+ struct adv_pattern *pattern;
+ struct adv_pattern *tmp;
+
+ if (!monitor)
+ return;
+
+ list_for_each_entry_safe(pattern, tmp, >patterns, list)
+ kfree(pattern);
+
+ kfree(monitor);
+}
+
+/* This function requires the caller holds hdev->lock */
+int hci_add_adv_monitor(struct hci_dev *hdev, struct adv_monitor *monitor)
+{
+ int min, max, handle;
+
+ if (!monitor)
+ return -EINVAL;
+
+ min = HCI_MIN_ADV_MONITOR_HANDLE;
+ max = HCI_MIN_ADV_MONITOR_HANDLE + HCI_MAX_ADV_MONITOR_NUM_HANDLES;
+ handle = idr_alloc(>adv_monitors_idr, monitor, min, max,
+ GFP_KERNEL);
+ if (handle < 0)
+ return handle;
+
+ hdev->adv_monitors_cnt++;
+ monitor->handle = handle;
+ return 0;
+}
+
struct bdaddr_list *hci_bdaddr_list_lookup(struct list_head *bdaddr_list,
bdaddr_t *bdaddr, u8 type)
{
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 63536d6332d45..8e0d4ccf81f15 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -113,6 +113,7 @@ static const u16 mgmt_commands[] = {
MGMT_OP_READ_EXP_FEATURES_INFO,
MGMT_OP_SET_EXP_FEATURE,
MGMT_OP_READ_ADV_MONITOR_FEATURES,
+ MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
};
static const u16 mgmt_events[] = {
@@ -3896,6 +3897,103 @@ static int read_adv_monitor_features(struct sock *sk,
struct hci_dev *hdev,
MGMT_STATUS_SUCCESS, rp, rp_size);
}
+static int add_adv_patterns_monitor(struct sock *sk, struct hci_dev *hdev,
+ void *data, u16 len)
+{
+ struct mgmt_cp_add_adv_patterns_monitor *cp = data;
+ struct mgmt_rp_add_adv_patterns_monitor rp;
+ struct adv_monitor *m = NULL;
+ struct adv_pattern *p = NULL;
+ __u8 cp_ofst = 0, cp_len = 0;
+ unsigned int mp_cnt = 0;
+ int err, i;
+
+ BT_DBG("request for %s", hdev->name);
+
+ if (len <= sizeof(*cp) || cp->pattern_count == 0) {
+ err = mgmt_cmd_status(sk, hdev->id,
+ MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
+ MGMT_STATUS_INVALID_PARAMS);
+ goto failed;
+ }
+
+ m = kmalloc(sizeof(*m), GFP_KERNEL);
+ if (!m) {
+ err = -ENOMEM;
+ goto failed;
+ }
+
+ INIT_LIST_HEAD(>patterns);
+ m->active = false;
+
+ for (i = 0; i < cp->pattern_count; i++) {
+ if (++mp_cnt > HCI_MAX_ADV_MONITOR_NUM_PATTERNS) {
+ err = mgmt_cmd_status(sk, hdev->id,
+ MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
+ MGMT_STATUS_INVALID_PARAMS);
+ goto failed;
+ }
+
+
[GIT PULL for v5.8-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.8-2 For: - some fixes for Kernel 5.8; - a set of atomisp patches. They remove several abstraction layers, and fixes clang and gcc warnings (that were hidden via some macros that were disabling 4 or 5 types of warnings there). There are also some important fixes and sensor auto-detection on newer BIOSes via ACPI _DCM tables. Thanks! Mauro - The following changes since commit 938b29db3aa9c293c7c1366b16e55e308f1a1ddd: media: Documentation: media: Refer to mbus format documentation from CSI-2 docs (2020-05-25 15:47:02 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.8-2 for you to fetch changes up to 2630e1bb0948c3134c6f22ad275ae27cc6023532: media: rkvdec: Fix H264 scaling list order (2020-06-11 19:21:38 +0200) media updates for v5.8-rc1 Arnd Bergmann (5): media: staging: media: atomisp: declare 'struct device' before using it media: staging: media: atomisp: fix enum type mixups media: staging: media: atomisp: disable all custom formats media: staging: media: atomisp: add PMIC_OPREGION dependency media: staging: media: atomisp: fix stack overflow in init_pipe_defaults() Colin Ian King (1): media: atomisp: fix a handful of spelling mistakes Geert Uytterhoeven (1): media: medium: cec: Make MEDIA_CEC_SUPPORT default to n if !MEDIA_SUPPORT Jernej Skrabec (1): media: cedrus: Implement runtime PM Jonas Karlman (2): media: v4l2-ctrls: Unset correct HEVC loop filter flag media: rkvdec: Fix H264 scaling list order Marek Szyprowski (1): media: s5p-mfc: Properly handle dma_parms for the allocated devices Mauro Carvalho Chehab (71): media: atomisp: fix pipeline initialization code media: atomisp: get rid of hmm_vm.c media: atomisp: reduce debug printk rate when IRQs are received media: atomisp: avoid a copy of v4l2_mbus_framefmt at stack media: atomisp: improve debug messages for set format media: atomisp: don't flood dmesg with -EAGAIN return codes media: atomisp: update TODO list media: atomisp: get rid of some old broken debug code media: atomisp: make it use dbg_level to control debug level media: atomisp: partially get rid of one abstraction layer media: atomisp: drop a cast for a const argument media: atomisp: fix size of delay_frames array media: atomisp: simplify hive_isp_css_mm_hrt wrapper media: atomisp: get rid of the hrt/hive_isp_css_mm_hrt abstraction layer media: atomisp: reduce abstraction at ia_css_memory_access media: atomisp: go one step further to drop ia_css_memory_access.c media: atomisp: get rid of mmgr_load and mmgr_store media: atomisp: get rid of unused memory_realloc code media: atomisp: change the type returned by mmgr alloc media: atomisp: get rid of memory_access.c media: atomisp: hmm_bo: untag user pointers media: atomisp: add debug message to help debugging hmm code media: atomisp: use Yocto Aero default hmm pool sizes media: atomisp: fix driver caps media: atomisp: use pin_user_pages() for memory allocation media: atomisp: add debug for hmm alloc media: atomisp: improve warning for IRQ enable function media: atomisp: add debug functions for received events media: atomisp: add more comments about frame allocation media: atomisp: remove kvmalloc/kvcalloc abstractions media: atomisp: avoid OOPS due to non-existing ref_frames media: atomisp: avoid an extra memset() when alloc memory media: atomisp: remove some trivial wrappers from compat css20 media: atomisp: do another round of coding style cleanup media: atomisp: get rid of non-Linux error codes media: atomisp: get rid of an error abstraction layer media: atomisp: don't cause a warn if probe failed media: atomisp: get rid of a bunch of other wrappers media: atomisp: get rid of system_types.h media: atomisp: provide more details about the firmware binaries media: atomisp: print firmware data during load media: atomisp: allow passing firmware name at modprobe time media: atomisp: add a debug message at hmm free media: atomisp: add some debug messages when binaries are used media: atomisp: add SPDX headers media: atomisp: remove format duplication at mbus->fourcc table media: atomisp: re-enable warnings again media: atomisp: get rid of sh_css_pipe.c media: atomisp: get rid of an unused IRQ duplicated event media: atomisp: get rid of a left-over wrapper function media: atomisp: comment an unused code media:
Re: [PATCH v6 0/5] Add support for DisplayPort driver on
Quoting Tanmay Shah (2020-06-11 18:50:25) > These patches add support for Display-Port driver on SnapDragon > hardware. It adds > DP driver and DP PLL driver files along with the needed device-tree > bindings. > > The block diagram of DP driver is shown below: > > > +-+ > |DRM FRAMEWORK| > +--+--+ > | >+v+ >| DP DRM | >+++ > | >+v+ > ++| DP+--++--+ > ++---+| DISPLAY |+---+ | | > |++-+-+-+| | | > || | | | | | > || | | | | | > || | | | | | > vv v v v v v > +--+ +--+ +---+ ++ ++ +---+ +-+ > | DP | | DP | |DP | | DP | | DP | |DP | | DP | > |PARSER| | HPD | |AUX| |LINK| |CTRL| |PHY| |POWER| > +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+ > | | | > +--v---+ +v-v+ > |DEVICE| | DP | > | TREE | |CATALOG| > +--+ +---+---+ > | > +---v+ > |CTRL/PHY| > | HW | > ++ > I've never seen a block diagram for a driver before... > > These patches have dependency on clock driver changes mentioned below: > https://patchwork.kernel.org/patch/11245895/ > https://patchwork.kernel.org/cover/11069083/ These are merged right? Don't need to include this if it's already merged. Can you include a changelog in the cover letter too so we know what has changed between versions of the patchset? > > Chandan Uddaraju (4): > dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon > drm: add constant N value in helper file > drm/msm/dp: add displayPort driver support > drm/msm/dp: add support for DP PLL driver > > Jeykumar Sankaran (1): > drm/msm/dpu: add display port support in DPU > [...] > > > base-commit: 48f99181fc118d82dc8bf6c7221ad1c654cb8bc2 What is this commit? I don't see it in linux-next.
Re: [RESEND PATCH] dt-bindings: property-units: Add picoseconds type
Rob On 6/12/20 5:17 PM, Rob Herring wrote: On Thu, Jun 11, 2020 at 02:46:28PM -0500, Dan Murphy wrote: Bump Merge window. Will apply when over. No worries. Just wanted to make sure it was seen and not lost. Dan
Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Hi, Neal:
Neal Liu 於 2020年6月9日 週二 下午6:25寫道：
>
> MT6873 bus frabric provides TrustZone security support and data
> protection to prevent slaves from being accessed by unexpected
> masters.
> The security violations are logged and sent to the processor for
> further analysis or countermeasures.
>
> Any occurrence of security violation would raise an interrupt, and
> it will be handled by devapc-mt6873 driver. The violation
> information is printed in order to find the murderer.
>
> Signed-off-by: Neal Liu
[snip]
> +
> +/*
> + * sramrom_vio_handler - clean sramrom violation & print violation
> information
> + * for debugging.
> + */
> +static void sramrom_vio_handler(void)
> +{
> + const struct mtk_sramrom_sec_vio_desc *sramrom_vios;
> + struct mtk_devapc_vio_info *vio_info;
> + struct arm_smccc_res res;
> + size_t sramrom_vio_sta;
> + int sramrom_vio;
> + u32 rw;
> +
> + sramrom_vios = mtk_devapc_ctx->soc->sramrom_sec_vios;
> + vio_info = mtk_devapc_ctx->soc->vio_info;
> +
> + arm_smccc_smc(MTK_SIP_KERNEL_CLR_SRAMROM_VIO,
> + 0, 0, 0, 0, 0, 0, 0, );
> +
> + sramrom_vio = res.a0;
> + sramrom_vio_sta = res.a1;
> + vio_info->vio_addr = res.a2;
> +
> + if (sramrom_vio == SRAM_VIOLATION)
> + pr_info(PFX "%s, SRAM violation is triggered\n", __func__);
> + else if (sramrom_vio == ROM_VIOLATION)
> + pr_info(PFX "%s, ROM violation is triggered\n", __func__);
> + else
> + return;
> +
> + vio_info->master_id = (sramrom_vio_sta & sramrom_vios->vio_id_mask)
> + >> sramrom_vios->vio_id_shift;
> + vio_info->domain_id = (sramrom_vio_sta &
> sramrom_vios->vio_domain_mask)
> + >> sramrom_vios->vio_domain_shift;
> + rw = (sramrom_vio_sta & sramrom_vios->vio_rw_mask) >>
> + sramrom_vios->vio_rw_shift;
I think some information, such as master_id, would be get in
devapc_extract_vio_dbg(), you need not to get it here.
> +
> + if (rw)
> + vio_info->write = 1;
> + else
> + vio_info->read = 1;
> +
> + pr_info(PFX "%s: %s:0x%x, %s:0x%x, %s:%s, %s:0x%x\n",
> + __func__, "master_id", vio_info->master_id,
> + "domain_id", vio_info->domain_id,
> + "rw", rw ? "Write" : "Read",
> + "vio_addr", vio_info->vio_addr);
> +}
> +
[snip]
> +
> +/*
> + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will
> dump
> + * violation information including which master
> violates
> + * access slave.
> + */
> +static irqreturn_t devapc_violation_irq(int irq_number, void *dev_id)
> +{
> + u32 slave_type_num = mtk_devapc_ctx->soc->slave_type_num;
Don't make mtk_devapc_ctx a global variable. You should allocate
instance of mtk_devapc_ctx in probe(), and pass mtk_devapc_ctx to
the last parameter of devm_request_irq(), and it would be the second
parameter of irq handler.
> + const struct mtk_device_info **device_info;
> + struct mtk_devapc_vio_info *vio_info;
> + int slave_type, vio_idx, index;
> + const char *vio_master;
> + unsigned long flags;
> + bool normal;
> + u8 perm;
> +
> + spin_lock_irqsave(_lock, flags);
> +
> + device_info = mtk_devapc_ctx->soc->device_info;
> + vio_info = mtk_devapc_ctx->soc->vio_info;
> + normal = false;
> + vio_idx = -1;
> + index = -1;
> +
> + /* There are multiple DEVAPC_PD */
> + for (slave_type = 0; slave_type < slave_type_num; slave_type++) {
> + if (!check_type2_vio_status(slave_type, _idx, ))
> + if (!mtk_devapc_dump_vio_dbg(slave_type, _idx,
> +))
> + continue;
> +
> + /* Ensure that violation info are written before
> +* further operations
> +*/
> + smp_mb();
> + normal = true;
> +
> + mask_module_irq(slave_type, vio_idx, true);
> +
> + if (clear_vio_status(slave_type, vio_idx))
> + pr_warn(PFX "%s, %s:0x%x, %s:0x%x\n",
> + "clear vio status failed",
> + "slave_type", slave_type,
> + "vio_index", vio_idx);
> +
> + perm = get_permission(slave_type, index, vio_info->domain_id);
> +
> + vio_master = mtk_devapc_ctx->soc->master_get
> + (vio_info->master_id,
> +vio_info->vio_addr,
> +slave_type,
> +vio_info->shift_sta_bit,
> +vio_info->domain_id);
> +
> + if (!vio_master) {
> + pr_warn(PFX
[PATCH v2 1/6] usb: typec: Add QCOM PMIC typec detection driver
The QCOM SPMI typec driver handles the role and orientation detection, and
notifies client drivers using the USB role switch framework. It registers
as a typec port, so orientation can be communicated using the typec switch
APIs. The driver also attains a handle to the VBUS output regulator, so it
can enable/disable the VBUS source when acting as a host/device.
Signed-off-by: Wesley Cheng
---
drivers/usb/typec/Kconfig | 12 ++
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/qcom-pmic-typec.c | 275
3 files changed, 288 insertions(+)
create mode 100644 drivers/usb/typec/qcom-pmic-typec.c
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b4f2aac7ae8a..595c14766e99 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -72,6 +72,18 @@ config TYPEC_TPS6598X
If you choose to build this driver as a dynamically linked module, the
module will be called tps6598x.ko.
+config TYPEC_QCOM_PMIC
+ tristate "Qualcomm PMIC USB Type-C driver"
+ depends on ARCH_QCOM
+ help
+ Driver for supporting role switch over the Qualcomm PMIC. This will
+ handle the USB Type-C role and orientation detection reported by the
+ QCOM PMIC if the PMIC has the capability to handle USB Type-C
+ detection.
+
+ It will also enable the VBUS output to connected devices when a
+ DFP connection is made.
+
source "drivers/usb/typec/mux/Kconfig"
source "drivers/usb/typec/altmodes/Kconfig"
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 7753a5c3cd46..cceffd987643 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm/
obj-$(CONFIG_TYPEC_UCSI) += ucsi/
obj-$(CONFIG_TYPEC_HD3SS3220) += hd3ss3220.o
obj-$(CONFIG_TYPEC_TPS6598X) += tps6598x.o
+obj-$(CONFIG_TYPEC_QCOM_PMIC) += qcom-pmic-typec.o
obj-$(CONFIG_TYPEC)+= mux/
diff --git a/drivers/usb/typec/qcom-pmic-typec.c
b/drivers/usb/typec/qcom-pmic-typec.c
new file mode 100644
index ..5ae3af03c638
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TYPEC_MISC_STATUS 0xb
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE BIT(6)
+#define TYPEC_MODE_CFG 0x44
+#define TYPEC_DISABLE_CMD BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define TYPEC_VCONN_CONTROL0x46
+#define VCONN_EN_SRC BIT(0)
+#define VCONN_EN_VAL BIT(1)
+#define TYPEC_EXIT_STATE_CFG 0x50
+#define SEL_SRC_UPPER_REF BIT(2)
+#define TYPEC_INTR_EN_CFG_10x5e
+#define TYPEC_INTR_EN_CFG_1_MASK GENMASK(7, 0)
+
+struct qcom_pmic_typec {
+ struct device *dev;
+ struct fwnode_handle*fwnode;
+ struct regmap *regmap;
+ u32 base;
+
+ struct typec_capability *cap;
+ struct typec_port *port;
+ struct usb_role_switch *role_sw;
+
+ struct regulator*vbus_reg;
+ boolvbus_enabled;
+};
+
+static void qcom_pmic_typec_enable_vbus_regulator(struct qcom_pmic_typec
+ *qcom_usb, bool enable)
+{
+ int ret = 0;
+
+ if (enable == qcom_usb->vbus_enabled)
+ return;
+
+ if (!qcom_usb->vbus_reg) {
+ qcom_usb->vbus_reg = devm_regulator_get(qcom_usb->dev,
+ "usb_vbus");
+ if (IS_ERR(qcom_usb->vbus_reg)) {
+ qcom_usb->vbus_reg = NULL;
+ return;
+ }
+ }
+
+ if (enable) {
+ ret = regulator_enable(qcom_usb->vbus_reg);
+ if (ret)
+ return;
+ } else {
+ ret = regulator_disable(qcom_usb->vbus_reg);
+ if (ret)
+ return;
+ }
+ qcom_usb->vbus_enabled = enable;
+}
+
+static void qcom_pmic_typec_check_connection(struct qcom_pmic_typec *qcom_usb)
+{
+ enum typec_orientation orientation;
+ enum usb_role role;
+ unsigned int stat;
+ bool enable_vbus;
+
+ regmap_read(qcom_usb->regmap, qcom_usb->base + TYPEC_MISC_STATUS,
+ );
+
+ if (stat & CC_ATTACHED) {
+ orientation = ((stat & CC_ORIENTATION) >> 1) ?
+ TYPEC_ORIENTATION_REVERSE :
+
[PATCH v2 4/6] regulator: Add support for QCOM PMIC VBUS booster
Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals. This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.
Signed-off-by: Wesley Cheng
---
drivers/regulator/Kconfig | 10 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom_usb_vbus-regulator.c | 147
3 files changed, 158 insertions(+)
create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..f9165f9f9051 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
Qualcomm SPMI PMICs as a module. The module will be named
"qcom_spmi-regulator".
+config REGULATOR_QCOM_USB_VBUS
+ tristate "Qualcomm USB Vbus regulator driver"
+ depends on SPMI || COMPILE_TEST
+ help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb-regulator".
+
config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..2b8129a04684
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+struct qcom_vbus {
+ struct device *dev;
+ u32 base;
+ struct regmap *regmap;
+ struct regulator_dev *usb_vbus_reg;
+};
+
+static int qcom_usb_vbus_enable(struct regulator_dev *rdev)
+{
+ struct qcom_vbus *vbus_out = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(vbus_out->regmap, vbus_out->base + CMD_OTG,
+ OTG_EN, OTG_EN);
+ if (rc)
+ dev_err(vbus_out->dev, "failed to enable usb_vbus\n");
+
+ return rc;
+}
+
+static int qcom_usb_vbus_disable(struct regulator_dev *rdev)
+{
+ struct qcom_vbus *vbus_out = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(vbus_out->regmap, vbus_out->base + CMD_OTG,
+ OTG_EN, 0);
+ if (rc)
+ dev_err(vbus_out->dev, "failed to disable usb_vbus\n");
+
+ return rc;
+}
+
+static int qcom_usb_vbus_is_enabled(struct regulator_dev *rdev)
+{
+ struct qcom_vbus *vbus_out = rdev_get_drvdata(rdev);
+ unsigned int value = 0;
+ int rc;
+
+ rc = regmap_read(vbus_out->regmap, vbus_out->base + CMD_OTG, );
+ if (rc)
+ dev_err(vbus_out->dev, "failed to read OTG_CTL\n");
+
+ return !!(value & OTG_EN);
+}
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+ .enable = qcom_usb_vbus_enable,
+ .disable = qcom_usb_vbus_disable,
+ .is_enabled = qcom_usb_vbus_is_enabled,
+};
+
+static const struct regulator_desc qcom_usb_vbus_rdesc = {
+ .name = "usb_vbus",
+ .ops = _usb_vbus_reg_ops,
+ .owner = THIS_MODULE,
+ .type = REGULATOR_VOLTAGE,
+};
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+ { .compatible = "qcom,pm8150b-vbus-reg" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+ struct qcom_vbus *vbus_out;
+ struct device *dev = >dev;
+ struct regulator_config config = { };
+ struct regulator_init_data init_data = { };
+ int ret;
+ u32 reg;
+
+ ret = of_property_read_u32(dev->of_node, "reg", );
+ if (ret < 0) {
+
[PATCH v2 6/6] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster
Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B. This will provide the VBUS source to connected
peripherals.
Signed-off-by: Wesley Cheng
---
arch/arm64/boot/dts/qcom/pm8150b.dtsi | 6 ++
arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 7 +++
2 files changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index ec44a8bc2f84..b7274d9d7341 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
+ qcom,dcdc@1100 {
+ compatible = "qcom,pm8150b-vbus-reg";
+ status = "disabled";
+ reg = <0x1100>;
+ };
+
qcom,typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..3845d19893eb 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -426,6 +426,13 @@ _1 {
status = "okay";
};
+_bus {
+ pmic@2 {
+ qcom,dcdc@1100 {
+ status = "okay";
+ };
+};
+
_1_dwc3 {
dr_mode = "peripheral";
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B. The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.
Signed-off-by: Wesley Cheng
---
.../bindings/usb/qcom,pmic-typec.yaml | 117 ++
1 file changed, 117 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..085b4547d75a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+ - Wesley Cheng
+
+description: |
+ Qualcomm PMIC Type C Detect
+
+properties:
+ compatible:
+enum:
+ - qcom,pm8150b-usb-typec
+
+ reg:
+maxItems: 1
+description: Type C base address
+
+ interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+ connector:
+description: Connector type for remote endpoints
+type: object
+
+properties:
+ compatible:
+enum:
+ - usb-c-connector
+
+ power-role:
+ enum:
+ - dual
+ - source
+ - sink
+
+ data-role:
+enum:
+ - dual
+ - host
+ - device
+
+ port:
+description: Remote endpoint connections
+type: object
+
+properties:
+ endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+ remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+ endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+ remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+ - compatible
+
+required:
+ - compatible
+ - interrupts
+ - connector
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts =
+<0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+port {
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint@0 {
+reg = <0>;
+remote-endpoint =
+<_ss_mux>;
+};
+
+usb3_role: endpoint@1 {
+
+reg = <1>;
+remote-endpoint =
+<_drd_switch>;
+};
+};
+};
+};
+};
+...
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator
This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode. The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.
Signed-off-by: Wesley Cheng
---
.../regulator/qcom,usb-vbus-regulator.yaml| 41 +++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..2fa76111cfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+ - Wesley Cheng
+
+description: |
+ This regulator driver controls the VBUS output by the Qualcomm PMIC. This
+ regulator will be enabled in situations where the device is required to
+ provide power to the connected peripheral.
+
+properties:
+ compatible:
+enum:
+ - qcom,pm8150b-vbus-reg
+
+ reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 0/6] Introduce PMIC based USB type C detection
Changes in v2: - Use devm_kzalloc() in qcom_pmic_typec_probe() - Add checks to make sure return value of typec_find_port_power_role() is valid - Added a VBUS output regulator driver, which will be used by the PMIC USB type c driver to enable/disable the source - Added logic to control vbus source from the PMIC type c driver when UFP/DFP is detected - Added dt-binding for this new regulator driver - Fixed Kconfig typec notation to match others - Leave type C block disabled until enabled by a platform DTS Add the required drivers for implementing type C orientation and role detection using the Qualcomm PMIC. Currently, PMICs such as the PM8150B have an integrated type C block, which can be utilized for this. This series adds the dt-binding, PMIC type C driver, and DTS nodes. The PMIC type C driver will register itself as a type C port w/ a registered type C switch for orientation, and will fetch a USB role switch handle for the role notifications. It will also have the ability to enable the VBUS output to any connected devices based on if the device is behaving as a UFP or DFP. Wesley Cheng (6): usb: typec: Add QCOM PMIC typec detection driver dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding arm64: boot: dts: qcom: pm8150b: Add node for USB type C block regulator: Add support for QCOM PMIC VBUS booster dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster .../regulator/qcom,usb-vbus-regulator.yaml| 41 +++ .../bindings/usb/qcom,pmic-typec.yaml | 117 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 13 + arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 7 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/qcom_usb_vbus-regulator.c | 147 ++ drivers/usb/typec/Kconfig | 12 + drivers/usb/typec/Makefile| 1 + drivers/usb/typec/qcom-pmic-typec.c | 275 ++ 10 files changed, 624 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c create mode 100644 drivers/usb/typec/qcom-pmic-typec.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 3/6] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection. Create the reference node to this type C
block for further use.
Signed-off-by: Wesley Cheng
---
arch/arm64/boot/dts/qcom/pm8150b.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..ec44a8bc2f84 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,14 @@ power-on@800 {
status = "disabled";
};
+ qcom,typec@1500 {
+ compatible = "qcom,pm8150b-usb-typec";
+ status = "disabled";
+ reg = <0x1500>;
+ interrupts =
+ <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+ };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 4/4] rcu: use gp_seq instead of rcu_gp_seq for consistency
On Fri, Jun 12, 2020 at 10:10:25PM +, Wei Yang wrote:
> On Fri, Jun 12, 2020 at 07:12:48AM -0700, Paul E. McKenney wrote:
> >On Fri, Jun 12, 2020 at 10:07:55AM +0800, Wei Yang wrote:
> >> Commit de30ad512a66 ("rcu: Introduce grace-period sequence numbers")
> >> introduce gp_seq in rcu_state/rcu_node/rcu_data. And this field in last
> >> two structure track the one in first.
> >>
> >> While the comment use rcu_gp_seq which is a little misleading for
> >> audience. Let's use the exact name gp_seq for consistency.
> >>
> >> Signed-off-by: Wei Yang
> >
> >I applied and pushed the others -- good eyes, and thank you!
> >
> >This one does not apply. Could you please forward-port it to
> >the "dev" branch of -rcu?
>
> The reason is someone has already fixed this :-)
That would explain it! ;-)
Thanx, Paul
> >git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >
> > Thanx, Paul
> >
> >> ---
> >> kernel/rcu/tree.h | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> >> index 512829eed545..3356842bc185 100644
> >> --- a/kernel/rcu/tree.h
> >> +++ b/kernel/rcu/tree.h
> >> @@ -41,7 +41,7 @@ struct rcu_node {
> >>raw_spinlock_t __private lock; /* Root rcu_node's lock protects */
> >>/* some rcu_state fields as well as */
> >>/* following. */
> >> - unsigned long gp_seq; /* Track rsp->rcu_gp_seq. */
> >> + unsigned long gp_seq; /* Track rsp->gp_seq. */
> >>unsigned long gp_seq_needed; /* Track furthest future GP request. */
> >>unsigned long completedqs; /* All QSes done for this node. */
> >>unsigned long qsmask; /* CPUs or groups that need to switch in */
> >> @@ -149,7 +149,7 @@ union rcu_noqs {
> >> /* Per-CPU data for read-copy update. */
> >> struct rcu_data {
> >>/* 1) quiescent-state and grace-period handling : */
> >> - unsigned long gp_seq; /* Track rsp->rcu_gp_seq counter. */
> >> + unsigned long gp_seq; /* Track rsp->gp_seq. */
> >>unsigned long gp_seq_needed; /* Track furthest future GP request. */
> >>union rcu_noqs cpu_no_qs; /* No QSes yet for this CPU. */
> >>boolcore_needs_qs; /* Core waits for quiesc state. */
> >> --
> >> 2.20.1 (Apple Git-117)
> >>
>
> --
> Wei Yang
> Help you, Help me
[PATCH 0/2] iommu: Move AMD and Intel Kconfig + Makefile bits into their directories
This patchset imeplements the suggestion from Linus to move the Kconfig and Makefile bits for AMD and Intel into their respective directories. It also cleans up a couple Kconfig entries to use the newer help attribute instead of ---help--- (complaint from checkpatch). Jerry Snitselaar (2): iommu/vt-d: Move Kconfig and Makefile bits down into intel directory iommu/amd: Move Kconfig and Makefile bits down into amd directory
[PATCH 2/2] iommu/amd: Move Kconfig and Makefile bits down into amd directory
Move AMD Kconfig and Makefile bits down into the amd directory with the rest of the AMD specific files. Cc: Joerg Roedel Cc: Suravee Suthikulpanit Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig | 45 +- drivers/iommu/Makefile | 5 + drivers/iommu/amd/Kconfig | 44 + drivers/iommu/amd/Makefile | 4 4 files changed, 50 insertions(+), 48 deletions(-) create mode 100644 drivers/iommu/amd/Kconfig create mode 100644 drivers/iommu/amd/Makefile diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index b12d4ec124f6..78a8be0053b3 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -132,50 +132,7 @@ config IOMMU_PGTABLES_L2 def_bool y depends on MSM_IOMMU && MMU && SMP && CPU_DCACHE_DISABLE=n -# AMD IOMMU support -config AMD_IOMMU - bool "AMD IOMMU support" - select SWIOTLB - select PCI_MSI - select PCI_ATS - select PCI_PRI - select PCI_PASID - select IOMMU_API - select IOMMU_IOVA - select IOMMU_DMA - depends on X86_64 && PCI && ACPI - ---help--- - With this option you can enable support for AMD IOMMU hardware in - your system. An IOMMU is a hardware component which provides - remapping of DMA memory accesses from devices. With an AMD IOMMU you - can isolate the DMA memory of different devices and protect the - system from misbehaving device drivers or hardware. - - You can find out if your system has an AMD IOMMU if you look into - your BIOS for an option to enable it or if you have an IVRS ACPI - table. - -config AMD_IOMMU_V2 - tristate "AMD IOMMU Version 2 driver" - depends on AMD_IOMMU - select MMU_NOTIFIER - ---help--- - This option enables support for the AMD IOMMUv2 features of the IOMMU - hardware. Select this option if you want to use devices that support - the PCI PRI and PASID interface. - -config AMD_IOMMU_DEBUGFS - bool "Enable AMD IOMMU internals in DebugFS" - depends on AMD_IOMMU && IOMMU_DEBUGFS - ---help--- - !!!WARNING!!! !!!WARNING!!! !!!WARNING!!! !!!WARNING!!! - - DO NOT ENABLE THIS OPTION UNLESS YOU REALLY, -REALLY- KNOW WHAT YOU ARE DOING!!! - Exposes AMD IOMMU device internals in DebugFS. - - This option is -NOT- intended for production environments, and should - not generally be enabled. - +source "drivers/iommu/amd/Kconfig" source "drivers/iommu/intel/Kconfig" config IRQ_REMAP diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 71dd2f382e78..f356bc12b1c7 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -obj-y += intel/ +obj-y += amd/ intel/ obj-$(CONFIG_IOMMU_API) += iommu.o obj-$(CONFIG_IOMMU_API) += iommu-traces.o obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o @@ -12,9 +12,6 @@ obj-$(CONFIG_IOASID) += ioasid.o obj-$(CONFIG_IOMMU_IOVA) += iova.o obj-$(CONFIG_OF_IOMMU) += of_iommu.o obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o -obj-$(CONFIG_AMD_IOMMU) += amd/iommu.o amd/init.o amd/quirks.o -obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd/debugfs.o -obj-$(CONFIG_AMD_IOMMU_V2) += amd/iommu_v2.o obj-$(CONFIG_ARM_SMMU) += arm_smmu.o arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o diff --git a/drivers/iommu/amd/Kconfig b/drivers/iommu/amd/Kconfig new file mode 100644 index ..1f061d91e0b8 --- /dev/null +++ b/drivers/iommu/amd/Kconfig @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only +# AMD IOMMU support +config AMD_IOMMU + bool "AMD IOMMU support" + select SWIOTLB + select PCI_MSI + select PCI_ATS + select PCI_PRI + select PCI_PASID + select IOMMU_API + select IOMMU_IOVA + select IOMMU_DMA + depends on X86_64 && PCI && ACPI + help + With this option you can enable support for AMD IOMMU hardware in + your system. An IOMMU is a hardware component which provides + remapping of DMA memory accesses from devices. With an AMD IOMMU you + can isolate the DMA memory of different devices and protect the + system from misbehaving device drivers or hardware. + + You can find out if your system has an AMD IOMMU if you look into + your BIOS for an option to enable it or if you have an IVRS ACPI + table. + +config AMD_IOMMU_V2 + tristate "AMD IOMMU Version 2 driver" + depends on AMD_IOMMU + select MMU_NOTIFIER + help + This option enables support for the AMD IOMMUv2 features of the IOMMU + hardware. Select this option if you want to use devices that support + the PCI PRI and PASID interface. + +config AMD_IOMMU_DEBUGFS + bool "Enable AMD IOMMU internals in DebugFS" + depends on AMD_IOMMU &&
Re: [RFC v2 1/3] dt-bindings: nvmem: Add devicetree bindings for qfprom-efuse
Hi, On Fri, Jun 12, 2020 at 2:59 PM Doug Anderson wrote: > > Hi, > > On Thu, Jun 11, 2020 at 2:49 AM Ravi Kumar Bokka > wrote: > > > > This patch adds dt-bindings document for qfprom-efuse controller. > > > > Signed-off-by: Ravi Kumar Bokka > > --- > > .../devicetree/bindings/nvmem/qfprom.yaml | 52 > > ++ > > 1 file changed, 52 insertions(+) > > Overall comment: I reviewed your v1 series and so I'm obviously > interested in your series. Please CC me on future versions. > > I would also note that, since this is relevant to Qualcomm SoCs that > you probably should be CCing "linux-arm-...@vger.kernel.org" on your > series. > > > > create mode 100644 Documentation/devicetree/bindings/nvmem/qfprom.yaml > > > > diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.yaml > > b/Documentation/devicetree/bindings/nvmem/qfprom.yaml > > new file mode 100644 > > index 000..7c8fc31 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/nvmem/qfprom.yaml > > @@ -0,0 +1,52 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/nvmem/qfprom.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Qualcomm Technologies Inc, QFPROM Efuse bindings > > + > > +maintainers: > > + - Ravi Kumar Bokka > > + > > +allOf: > > + - $ref: "nvmem.yaml#" > > + > > +properties: > > + compatible: > > +enum: > > + - qcom,qfprom > > As per discussion in patch #1, I believe SoC compatible should be here > too in case it is ever needed. This is standard practice for dts > files for IP blocks embedded in an SoC. AKA, this should be: > > items: > - enum: > - qcom,apq8064-qfprom > - qcom,apq8084-qfprom > - qcom,msm8974-qfprom > - qcom,msm8916-qfprom > - qcom,msm8996-qfprom > - qcom,msm8998-qfprom > - qcom,qcs404-qfprom > - qcom,sc7180-qfprom > - qcom,sdm845-qfprom > - const: qcom,qfprom > > NOTE: old SoCs won't have both of these and thus they will get flagged > with "dtbs_check", but I believe that's fine (Rob can correct me if > I'm wrong). The code should still work OK if the SoC isn't there but > it would be good to fix old dts files to have the SoC specific string > too. > > > > + > > + reg: > > +maxItems: 3 > > Please address feedback feedback on v1. If you disagree with my > feedback it's OK to say so (I make no claims of being always right), > but silently ignoring my feedback and sending the next version doesn't > make me feel like it's a good use of my time to keep reviewing your > series. Specifically I suggested that you actually add descriptions > rather than just putting "maxItems: 3". > > With all that has been discussed, I think the current best thing to > put there is: > > # If the QFPROM is read-only OS image then only the corrected region > # needs to be provided. If the QFPROM is writable then all 3 regions > # must be provided. > oneOf: > - items: > - description: The start of the corrected region. > - items: > - description: The start of the raw region. > - description: The start of the config region. > - description: The start of the corrected region. To address some of Srinivas's comments, I think you should actually add the 4th range in here too: - description: The start of the security control region. That allows you to read 0x6000 and get the major/minor/step properly. I will also note that as I've started reviewing the driver code it'll probably make everyone's life easiest if you keep the "corrected" region first, even if it's not numerically first. I've updated my FIXUP patch again. I might notice more comments as I review the driver more, but we'll see... -Doug
[PATCH 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory
Move Intel Kconfig and Makefile bits down into intel directory with the rest of the Intel specific files. Cc: Joerg Roedel Cc: Lu Baolu Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig| 86 +--- drivers/iommu/Makefile | 8 +--- drivers/iommu/intel/Kconfig | 86 drivers/iommu/intel/Makefile | 7 +++ 4 files changed, 96 insertions(+), 91 deletions(-) create mode 100644 drivers/iommu/intel/Kconfig create mode 100644 drivers/iommu/intel/Makefile diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index aca76383f201..b12d4ec124f6 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -176,91 +176,7 @@ config AMD_IOMMU_DEBUGFS This option is -NOT- intended for production environments, and should not generally be enabled. -# Intel IOMMU support -config DMAR_TABLE - bool - -config INTEL_IOMMU - bool "Support for Intel IOMMU using DMA Remapping Devices" - depends on PCI_MSI && ACPI && (X86 || IA64) - select IOMMU_API - select IOMMU_IOVA - select NEED_DMA_MAP_STATE - select DMAR_TABLE - select SWIOTLB - select IOASID - help - DMA remapping (DMAR) devices support enables independent address - translations for Direct Memory Access (DMA) from devices. - These DMA remapping devices are reported via ACPI tables - and include PCI device scope covered by these DMA - remapping devices. - -config INTEL_IOMMU_DEBUGFS - bool "Export Intel IOMMU internals in Debugfs" - depends on INTEL_IOMMU && IOMMU_DEBUGFS - help - !!!WARNING!!! - - DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!!! - - Expose Intel IOMMU internals in Debugfs. - - This option is -NOT- intended for production environments, and should - only be enabled for debugging Intel IOMMU. - -config INTEL_IOMMU_SVM - bool "Support for Shared Virtual Memory with Intel IOMMU" - depends on INTEL_IOMMU && X86 - select PCI_PASID - select PCI_PRI - select MMU_NOTIFIER - select IOASID - help - Shared Virtual Memory (SVM) provides a facility for devices - to access DMA resources through process address space by - means of a Process Address Space ID (PASID). - -config INTEL_IOMMU_DEFAULT_ON - def_bool y - prompt "Enable Intel DMA Remapping Devices by default" - depends on INTEL_IOMMU - help - Selecting this option will enable a DMAR device at boot time if - one is found. If this option is not selected, DMAR support can - be enabled by passing intel_iommu=on to the kernel. - -config INTEL_IOMMU_BROKEN_GFX_WA - bool "Workaround broken graphics drivers (going away soon)" - depends on INTEL_IOMMU && BROKEN && X86 - ---help--- - Current Graphics drivers tend to use physical address - for DMA and avoid using DMA APIs. Setting this config - option permits the IOMMU driver to set a unity map for - all the OS-visible memory. Hence the driver can continue - to use physical addresses for DMA, at least until this - option is removed in the 2.6.32 kernel. - -config INTEL_IOMMU_FLOPPY_WA - def_bool y - depends on INTEL_IOMMU && X86 - ---help--- - Floppy disk drivers are known to bypass DMA API calls - thereby failing to work when IOMMU is enabled. This - workaround will setup a 1:1 mapping for the first - 16MiB to make floppy (an ISA device) work. - -config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON - bool "Enable Intel IOMMU scalable mode by default" - depends on INTEL_IOMMU - help - Selecting this option will enable by default the scalable mode if - hardware presents the capability. The scalable mode is defined in - VT-d 3.0. The scalable mode capability could be checked by reading - /sys/devices/virtual/iommu/dmar*/intel-iommu/ecap. If this option - is not selected, scalable mode support could also be enabled by - passing intel_iommu=sm_on to the kernel. If not sure, please use - the default value. +source "drivers/iommu/intel/Kconfig" config IRQ_REMAP bool "Support for Interrupt Remapping" diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 342190196dfb..71dd2f382e78 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-y += intel/ obj-$(CONFIG_IOMMU_API) += iommu.o obj-$(CONFIG_IOMMU_API) += iommu-traces.o obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o @@ -17,13 +18,8 @@ obj-$(CONFIG_AMD_IOMMU_V2) += amd/iommu_v2.o obj-$(CONFIG_ARM_SMMU) += arm_smmu.o arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o -obj-$(CONFIG_DMAR_TABLE) +=
Re: 5.7-rc0: kswapd eats cpu during a disk test?!
Hi! > > +CC linux-mm > > > > On 5/31/20 12:34 PM, Pavel Machek wrote: > > > Hi! > > > > > > This is simple cat /dev/sda > /dev/zero... on thinkpad x60 (x86-32), > > > with spinning rust. > > > > > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ > > > COMMAND > > >1000 root 20 0 0 0 0 R 53.3 0.0 57:34.93 > > > kswapd0 > > > 27897 root 20 06976580536 R 44.5 0.0 1:44.53 cat > > > > > > It keeps both CPUs busy... and I don't think that's right. > > > > Does an older kernel behave differently here? > > Let me try on x220 (x86-64, first): > > 737 root 20 05404744680 R 31.2 0.0 0:09.98 cat > > 1024 root 20 0 0 0 0 S 21.4 0.0 165:22.68 kswapd0 > > > That was with ssd, result with spinning rust is similar: > > 859 root 20 05404740672 D 21.1 0.0 0:03.33 cat > > 1024 root 20 0 0 0 0 R 11.8 0.0 165:33.07 kswapd0 > > > 5.7-rc1+ kernel. > > Performance of spinning rust is down, too, on x60: > > pavel@amd:~/misc/hw/hdd1t$ sudo ddrescue --force /dev/sda1 /dev/null > GNU ddrescue 1.19 > Press Ctrl-C to interrupt > rescued: 2147 MB, errsize: 0 B, current rate:3080 kB/s >ipos: 2147 MB, errors: 0,average rate:5382 kB/s > opos: 2147 MB, run time:6.65 m, successful read: > 0 s ago > Finished > pavel@amd:~/misc/hw/hdd1t$ uname -a > Linux amd 5.7.0-next-20200611+ #123 SMP PREEMPT Thu Jun 11 > 15:41:22 CEST 2020 i686 GNU/Linux > > And there's something clearly wrong here: > > 966 root 20 0 0 0 0 R 94.4 0.0 8:18.82 kswapd0 > 23933 root 20 04612 1112 1028 D 80.6 0.0 0:26.40 > ddrescue > Same x60 under older kernel: pavel@amd:/data/fast/pavel$ sudo ddrescue --force /dev/sda4 /dev/null GNU ddrescue 1.19 Press Ctrl-C to interrupt rescued: 6593 MB, errsize: 0 B, current rate: 60424 kB/s ipos: 6593 MB, errors: 0,average rate: 95563 kB/s 3539 root 20 04616 1136 1048 D 21.4 0.0 0:15.63 ddrescue 865 root 20 0 0 0 0 S 6.9 0.0 0:04.91 kswapd0 Linux amd 4.6.0+ #172 SMP Sun Aug 14 11:25:34 CEST 2016 i686 GNU/Linux These are more reasonable numbers. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] xdp_rxq_info_user: Fix null pointer dereference. Replace malloc/memset with calloc.
Jesper Dangaard Brouer wrote:
> On Fri, 12 Jun 2020 14:53:27 -0400
> Gaurav Singh wrote:
>
> > Memset on the pointer right after malloc can cause a
> > null pointer deference if it failed to allocate memory.
> > A simple fix is to replace malloc/memset with a calloc()
> >
> > Fixes: 0fca931a6f21 ("samples/bpf: program demonstrating access to
> > xdp_rxq_info")
> > Signed-off-by: Gaurav Singh
>
> Acked-by: Jesper Dangaard Brouer
>
Acked-by: John Fastabend
Re: [PATCH bpf] bpf: sockmap: don't attach programs to UDP sockets
Jakub Sitnicki wrote:
> On Thu, 11 Jun 2020 18:25:20 +0100
> Lorenz Bauer wrote:
>
> > The stream parser infrastructure isn't set up to deal with UDP
> > sockets, so we mustn't try to attach programs to them.
> >
> > I remember making this change at some point, but I must have lost
> > it while rebasing or something similar.
> >
> > Fixes: 7b98cd42b049 ("bpf: sockmap: Add UDP support")
> > Signed-off-by: Lorenz Bauer
> > ---
> > net/core/sock_map.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> > index 00a26cf2cfe9..35cea36f3892 100644
> > --- a/net/core/sock_map.c
> > +++ b/net/core/sock_map.c
> > @@ -424,10 +424,7 @@ static int sock_map_get_next_key(struct bpf_map *map,
> > void *key, void *next)
> > return 0;
> > }
> >
> > -static bool sock_map_redirect_allowed(const struct sock *sk)
> > -{
> > - return sk->sk_state != TCP_LISTEN;
> > -}
> > +static bool sock_map_redirect_allowed(const struct sock *sk);
> >
> > static int sock_map_update_common(struct bpf_map *map, u32 idx,
> > struct sock *sk, u64 flags)
> > @@ -508,6 +505,11 @@ static bool sk_is_udp(const struct sock *sk)
> >sk->sk_protocol == IPPROTO_UDP;
> > }
> >
> > +static bool sock_map_redirect_allowed(const struct sock *sk)
> > +{
> > + return sk_is_tcp(sk) && sk->sk_state != TCP_LISTEN;
> > +}
> > +
> > static bool sock_map_sk_is_suitable(const struct sock *sk)
> > {
> > return sk_is_tcp(sk) || sk_is_udp(sk);
>
> Acked-by: Jakub Sitnicki
Thanks.
Acked-by: John Fastabend
[PATCH v3 0/2] Update K3 DSP remoteproc driver for C71x DSPs
Hi All, This series is the updated v3 version of the 64-bit TI C71x DSP support that goes along with the updated v3 TI K3 C66x DSP patch series [1]. Please see the previous cover-letters [2][3] for a summary of supported features. The only change is to Patch 1 that had to be rebased and adjusted for the changes to the K3 DSP binding file in the C66x series. Please see the individual patches for differences in v3. regards Suman [1] C66x v3: https://patchwork.kernel.org/cover/11602331/ [2] C71x v2: https://patchwork.kernel.org/cover/11563229/ [2] C71x v1: https://patchwork.kernel.org/cover/11458599/ Suman Anna (2): dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs remoteproc: k3-dsp: Add support for C71x DSPs .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 68 +++ drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 +- 2 files changed, 73 insertions(+), 15 deletions(-) -- 2.26.0
[PATCH v3 2/2] remoteproc: k3-dsp: Add support for C71x DSPs
The Texas Instrument's K3 J721E SoCs have a newer next-generation
C71x DSP Subsystem in the MAIN voltage domain in addition to the
previous generation C66x DSP subsystems. The C71x DSP subsystem is
based on the TMS320C71x DSP CorePac module. The C71x CPU is a true
64-bit machine including 64-bit memory addressing and single-cycle
64-bit base arithmetic operations and supports vector signal processing
providing a significant lift in DSP processing power over C66x DSPs.
J721E SoCs use a C711 (a one-core 512-bit vector width CPU core) DSP
that is cache coherent with the A72 Arm cores.
Each subsystem has one or more Fixed/Floating-Point DSP CPUs, with 32 KB
of L1P Cache, 48 KB of L1D SRAM that can be configured and partitioned as
either RAM and/or Cache, and 512 KB of L2 SRAM configurable as either RAM
and/or Cache. The CorePac also includes a Matrix Multiplication Accelerator
(MMA), a Stream Engine (SE) and a C71x Memory Management Unit (CMMU), an
Interrupt Controller (INTC) and a Powerdown Management Unit (PMU) modules.
Update the existing K3 DSP remoteproc driver to add support for this C71x
DSP subsystem. The firmware loading support is provided by using the newly
added 64-bit ELF loader support, and is limited to images using only
external DDR memory at the moment. The L1D and L2 SRAMs are used as scratch
memory when using as RAMs, and cannot be used for loadable segments. The
CMMU is also not supported to begin with, and the driver is designed to
treat the MMU as if it is in bypass mode.
Signed-off-by: Suman Anna
Reviewed-by: Mathieu Poirier
---
v3:
- No code changes, rebased patch
- Picked up review tags
- Switched from remoteproc/k3-dsp to remoteproc: k3-dsp in patch title
v2: https://patchwork.kernel.org/patch/11563233/
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index 668bb45b3fe8..861cc9126241 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -407,8 +407,6 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64
da, size_t len)
}
static const struct rproc_ops k3_dsp_rproc_ops = {
- .prepare= k3_dsp_rproc_prepare,
- .unprepare = k3_dsp_rproc_unprepare,
.start = k3_dsp_rproc_start,
.stop = k3_dsp_rproc_stop,
.kick = k3_dsp_rproc_kick,
@@ -618,6 +616,10 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
rproc->has_iommu = false;
rproc->recovery_disabled = true;
+ if (data->uses_lreset) {
+ rproc->ops->prepare = k3_dsp_rproc_prepare;
+ rproc->ops->unprepare = k3_dsp_rproc_unprepare;
+ }
kproc = rproc->priv;
kproc->rproc = rproc;
kproc->dev = dev;
@@ -745,6 +747,12 @@ static const struct k3_dsp_mem_data c66_mems[] = {
{ .name = "l1dram", .dev_addr = 0xf0 },
};
+/* C71x cores only have a L1P Cache, there are no L1P SRAMs */
+static const struct k3_dsp_mem_data c71_mems[] = {
+ { .name = "l2sram", .dev_addr = 0x80 },
+ { .name = "l1dram", .dev_addr = 0xe0 },
+};
+
static const struct k3_dsp_dev_data c66_data = {
.mems = c66_mems,
.num_mems = ARRAY_SIZE(c66_mems),
@@ -752,8 +760,16 @@ static const struct k3_dsp_dev_data c66_data = {
.uses_lreset = true,
};
+static const struct k3_dsp_dev_data c71_data = {
+ .mems = c71_mems,
+ .num_mems = ARRAY_SIZE(c71_mems),
+ .boot_align_addr = SZ_2M,
+ .uses_lreset = false,
+};
+
static const struct of_device_id k3_dsp_of_match[] = {
{ .compatible = "ti,j721e-c66-dsp", .data = _data, },
+ { .compatible = "ti,j721e-c71-dsp", .data = _data, },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
--
2.26.0
[PATCH v3 1/2] dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
Some Texas Instruments K3 family of SoCs have one of more newer
generation TMS320C71x CorePac processor subsystem in addition to
the existing TMS320C66x CorePac processor subsystems. Update the
device tree bindings document for the C71x DSP devices.
The example is also updated to show the single C71 DSP present
on J721E SoCs.
Signed-off-by: Suman Anna
---
v3:
- Dropped Rob's previous Reviewed-by tag due to decent changes in the
patch
- Replaced the minItems and maxItems from reg with actual items list
- Dropped C71 reserved memory nodes from example
v2: https://patchwork.kernel.org/patch/11563231/
.../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 68 +++
1 file changed, 55 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index f03e88c42a6e..8eaf326b5a7f 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -30,21 +30,12 @@ allOf:
properties:
compatible:
-const: ti,j721e-c66-dsp
+enum:
+ - ti,j721e-c66-dsp
+ - ti,j721e-c71-dsp
description:
Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
-
- reg:
-items:
- - description: Address and Size of the L2 SRAM internal memory region
- - description: Address and Size of the L1 PRAM internal memory region
- - description: Address and Size of the L1 DRAM internal memory region
-
- reg-names:
-items:
- - const: l2sram
- - const: l1pram
- - const: l1dram
+ Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
resets:
description: |
@@ -92,6 +83,40 @@ properties:
should be defined as per the generic bindings in,
Documentation/devicetree/bindings/sram/sram.yaml
+if:
+ properties:
+compatible:
+ enum:
+- ti,j721e-c66-dsp
+then:
+ properties:
+reg:
+ items:
+- description: Address and Size of the L2 SRAM internal memory region
+- description: Address and Size of the L1 PRAM internal memory region
+- description: Address and Size of the L1 DRAM internal memory region
+reg-names:
+ items:
+- const: l2sram
+- const: l1pram
+- const: l1dram
+else:
+ if:
+properties:
+ compatible:
+enum:
+ - ti,j721e-c71-dsp
+ then:
+properties:
+ reg:
+items:
+ - description: Address and Size of the L2 SRAM internal memory region
+ - description: Address and Size of the L1 DRAM internal memory region
+ reg-names:
+items:
+ - const: l2sram
+ - const: l1dram
+
required:
- compatible
- reg
@@ -116,6 +141,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x0010 0x00 0x0010 0x00 0x0002>, /*
ctrl mmr */
+ <0x00 0x6480 0x00 0x6480 0x00 0x0080>, /*
C71_0 */
<0x4d 0x8080 0x4d 0x8080 0x00 0x0080>, /*
C66_0 */
<0x4d 0x8180 0x4d 0x8180 0x00 0x0080>; /*
C66_1 */
@@ -135,5 +161,21 @@ examples:
<_0_memory_region>;
mboxes = <_cluster3 _c66_0>;
};
+
+/* J721E C71_0 DSP node */
+c71_0: dsp@6480 {
+compatible = "ti,j721e-c71-dsp";
+reg = <0x00 0x6480 0x00 0x0008>,
+ <0x00 0x64e0 0x00 0xc000>;
+reg-names = "l2sram", "l1dram";
+ti,sci = <>;
+ti,sci-dev-id = <15>;
+ti,sci-proc-ids = <0x30 0xFF>;
+resets = <_reset 15 1>;
+firmware-name = "j7-c71_0-fw";
+memory-region = <_0_dma_memory_region>,
+<_0_memory_region>;
+mboxes = <_cluster4 _c71_0>;
+};
};
};
--
2.26.0
[PATCH] clk: iproc: round clock rate to the closest
From: Lori Hikichi
Change from 'DIV_ROUND_UP' to 'DIV_ROUND_CLOSEST' when calculating the
clock divisor in the iProc ASIU clock driver to allow to get to the
closest clock rate.
Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support")
Signed-off-by: Lori Hikichi
Signed-off-by: Ray Jui
---
drivers/clk/bcm/clk-iproc-asiu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-iproc-asiu.c b/drivers/clk/bcm/clk-iproc-asiu.c
index 6fb8af506777..e062dd4992ea 100644
--- a/drivers/clk/bcm/clk-iproc-asiu.c
+++ b/drivers/clk/bcm/clk-iproc-asiu.c
@@ -119,7 +119,7 @@ static long iproc_asiu_clk_round_rate(struct clk_hw *hw,
unsigned long rate,
if (rate == *parent_rate)
return *parent_rate;
- div = DIV_ROUND_UP(*parent_rate, rate);
+ div = DIV_ROUND_CLOSEST(*parent_rate, rate);
if (div < 2)
return *parent_rate;
@@ -145,7 +145,7 @@ static int iproc_asiu_clk_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
- div = DIV_ROUND_UP(parent_rate, rate);
+ div = DIV_ROUND_CLOSEST(parent_rate, rate);
if (div < 2)
return -EINVAL;
--
2.17.1
Re: [GIT PULL] proc fixes v2 for v5.8-rc1
Linus Torvalds writes: > On Fri, Jun 12, 2020 at 1:06 PM Eric W. Biederman > wrote: >> >> I have a sense that a use after free that anyone can trigger could be a >> bit dangerous, and despite not being the only virtual filesystem in the >> kernel proc is the only virtual filesystem that called new_inode_pseudo. > > So the reason I pulled that change despite my questions was that I do > agree with the whole "there's probably little point to use > new_inode_pseudo() here" argument. > > But at the same time, I ghet the feeling that this partly just is > papering over the problem. If fsnotify causes problems with a > new_inode_pseudo() inode, then fsnotify should be _checking_ for that > case. > > And if fsnotify were to check for it, then the reason for /proc to use > it would largely go away. Maybe the debug check for umount matters, > but honestly it doesn't really seem to be a big deal. > > A pseudo-inode is basically independent of the filesystem it was > mounted as, so the generic_shutdown_super() check not triggering for > them is sensible, I feel. > > But yeah, we could also make the rule go the other way, and simply > make sure that "new_inode_pseudo()" itself checks that the super-block > you give it is something fundamenally unmountable and was created with > 'kern_mount()'. > > That would have also figured out that the /proc case was broken. > > So the main objection I have here is really that this fix feels > incomplete, and doesn't really reflect the underlying issue, just > fixes the symptom. > > Either the underlying issue is that you shouldn't call 'fsnotify' on > /proc, or the underlying issue is that /proc was using a bad inode and > nobody even noticed until the fsnotify issue. > > This is not a huge deal. I think you've fixed the bug, I just have > this itch that the thing that triggered it shouldn't have happened in > the first place. Yeah. I have a similar feeling. Especially since it took about 7 years for someone to notice something was not right. Still right now I am not up to digging and adding warnings and causing things to fail. What energy I have I am going to use to keep sorting out exec. I am not ready to page back in the fine details of how all of the filesystem pieces interact right now. I am wondering now if there are any crazy corner cases of the unix domain sockets where fsnotify could latch onto one, and have problems. It looks like the inode comes from the underlying filesystem so we should be safe. Eric
[PATCH v3 2/6] remoteproc: k3: Add TI-SCI processor control helper functions
Texas Instruments' K3 generation SoCs have specific modules/register
spaces used for configuring the various aspects of a remote processor.
These include power, reset, boot vector and other configuration features
specific to each compute processor present on the SoC. These registers
are managed by the System Controller such as DMSC on K3 AM65x SoCs.
The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used to communicate to the System Controller from various compute
processors to invoke specific services provided by the firmware running
on the System Controller.
Add a common processor control interface header file that can be used by
multiple remoteproc drivers. The helper functions within this header file
abstract the various TI SCI protocol ops for the remoteproc drivers, and
allow them to request the System Controller to be able to program and
manage various remote processors on the SoC. The remoteproc drivers are
expected to manage the life-cycle of their ti_sci_proc_dev local
structures.
Signed-off-by: Suman Anna
---
v3: New to this series, but the patch is identical to the one from the
K3 R5F series posted previously, with patch title adjusted
https://patchwork.kernel.org/patch/11456379/
drivers/remoteproc/ti_sci_proc.h | 102 +++
1 file changed, 102 insertions(+)
create mode 100644 drivers/remoteproc/ti_sci_proc.h
diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
new file mode 100644
index ..e42d8015b8e7
--- /dev/null
+++ b/drivers/remoteproc/ti_sci_proc.h
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Texas Instruments TI-SCI Processor Controller Helper Functions
+ *
+ * Copyright (C) 2018-2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Suman Anna
+ */
+
+#ifndef REMOTEPROC_TI_SCI_PROC_H
+#define REMOTEPROC_TI_SCI_PROC_H
+
+/**
+ * struct ti_sci_proc - structure representing a processor control client
+ * @sci: cached TI-SCI protocol handle
+ * @ops: cached TI-SCI proc ops
+ * @dev: cached client device pointer
+ * @proc_id: processor id for the consumer remoteproc device
+ * @host_id: host id to pass the control over for this consumer remoteproc
+ * device
+ */
+struct ti_sci_proc {
+ const struct ti_sci_handle *sci;
+ const struct ti_sci_proc_ops *ops;
+ struct device *dev;
+ u8 proc_id;
+ u8 host_id;
+};
+
+static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
+{
+ int ret;
+
+ ret = tsp->ops->request(tsp->sci, tsp->proc_id);
+ if (ret)
+ dev_err(tsp->dev, "ti-sci processor request failed: %d\n",
+ ret);
+ return ret;
+}
+
+static inline int ti_sci_proc_release(struct ti_sci_proc *tsp)
+{
+ int ret;
+
+ ret = tsp->ops->release(tsp->sci, tsp->proc_id);
+ if (ret)
+ dev_err(tsp->dev, "ti-sci processor release failed: %d\n",
+ ret);
+ return ret;
+}
+
+static inline int ti_sci_proc_handover(struct ti_sci_proc *tsp)
+{
+ int ret;
+
+ ret = tsp->ops->handover(tsp->sci, tsp->proc_id, tsp->host_id);
+ if (ret)
+ dev_err(tsp->dev, "ti-sci processor handover of %d to %d
failed: %d\n",
+ tsp->proc_id, tsp->host_id, ret);
+ return ret;
+}
+
+static inline int ti_sci_proc_set_config(struct ti_sci_proc *tsp,
+u64 boot_vector,
+u32 cfg_set, u32 cfg_clr)
+{
+ int ret;
+
+ ret = tsp->ops->set_config(tsp->sci, tsp->proc_id, boot_vector,
+ cfg_set, cfg_clr);
+ if (ret)
+ dev_err(tsp->dev, "ti-sci processor set_config failed: %d\n",
+ ret);
+ return ret;
+}
+
+static inline int ti_sci_proc_set_control(struct ti_sci_proc *tsp,
+ u32 ctrl_set, u32 ctrl_clr)
+{
+ int ret;
+
+ ret = tsp->ops->set_control(tsp->sci, tsp->proc_id, ctrl_set, ctrl_clr);
+ if (ret)
+ dev_err(tsp->dev, "ti-sci processor set_control failed: %d\n",
+ ret);
+ return ret;
+}
+
+static inline int ti_sci_proc_get_status(struct ti_sci_proc *tsp,
+u64 *boot_vector, u32 *cfg_flags,
+u32 *ctrl_flags, u32 *status_flags)
+{
+ int ret;
+
+ ret = tsp->ops->get_status(tsp->sci, tsp->proc_id, boot_vector,
+ cfg_flags, ctrl_flags, status_flags);
+ if (ret)
+ dev_err(tsp->dev, "ti-sci processor get_status failed: %d\n",
+ ret);
+ return ret;
+}
+
+#endif /* REMOTEPROC_TI_SCI_PROC_H */
--
2.26.0
[PATCH v3 5/6] remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs
The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN voltage domain that are based on the TI's standard TMS320C66x DSP CorePac module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each of L1P & L1D SRAMs that can be configured and partitioned as either RAM and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA), External Memory Controller (EMC), Extended Memory Controller (XMC) with a Region Address Translator (RAT) unit for 32-bit to 48-bit address extension/translations, an Interrupt Controller (INTC) and a Powerdown Controller (PDC). A new remoteproc module is added to perform the device management of these DSP devices. The support is limited to images using only external DDR memory at the moment, the loading support to internal memories and any on-chip RAM memories will be added in a subsequent patch. RAT support is also left for a future patch, and as such the reserved memory carveout regions are all expected to be using memory regions within the first 2 GB. Error Recovery and Power Management features are not currently supported. The C66x remote processors do not have an MMU, and so require fixed memory carveout regions matching the firmware image addresses. Support for this is provided by mandating multiple memory regions to be attached to the remoteproc device. The first memory region will be used to serve as the DMA pool for all dynamic allocations like the vrings and vring buffers. The remaining memory regions are mapped into the kernel at device probe time, and are used to provide address translations for firmware image segments without the need for any RSC_CARVEOUT entries. Any firmware image using memory outside of the supplied reserved memory carveout regions will be errored out. The driver uses various TI-SCI interfaces to talk to the System Controller (DMSC) for managing configuration, power and reset management of these cores. IPC between the A72 cores and the DSP cores is supported through the virtio rpmsg stack using shared memory and OMAP Mailboxes. Signed-off-by: Suman Anna Reviewed-by: Bjorn Andersson Reviewed-by: Mathieu Poirier --- v3: - Included slab.h to fix compile errors against latest master - Switched from remoteproc/k3-dsp to remoteproc: k3-dsp in patch title - Picked up review tags - No other code changes v2: https://patchwork.kernel.org/patch/11561783/ drivers/remoteproc/Kconfig| 13 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_k3_dsp_remoteproc.c | 702 ++ 3 files changed, 716 insertions(+) create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index c4d1731295eb..74b818b25068 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -249,6 +249,19 @@ config STM32_RPROC This can be either built-in or a loadable module. +config TI_K3_DSP_REMOTEPROC + tristate "TI K3 DSP remoteproc support" + depends on ARCH_K3 + select MAILBOX + select OMAP2PLUS_MBOX + help + Say m here to support TI's C66x and C71x DSP remote processor + subsystems on various TI K3 family of SoCs through the remote + processor framework. + + It's safe to say N here if you're not interested in utilizing + the DSP slave processors. + endif # REMOTEPROC endmenu diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile index e8b886e511f0..d457d0f87ada 100644 --- a/drivers/remoteproc/Makefile +++ b/drivers/remoteproc/Makefile @@ -30,3 +30,4 @@ qcom_wcnss_pil-y += qcom_wcnss_iris.o obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o +obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c new file mode 100644 index ..2f8b3ff5427d --- /dev/null +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c @@ -0,0 +1,702 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * TI K3 DSP Remote Processor(s) driver + * + * Copyright (C) 2018-2020 Texas Instruments Incorporated - http://www.ti.com/ + * Suman Anna + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "omap_remoteproc.h" +#include "remoteproc_internal.h" +#include "ti_sci_proc.h" + +#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK (SZ_16M - 1) + +/** + * struct k3_dsp_mem - internal memory structure + * @cpu_addr: MPU virtual address of the memory region + * @bus_addr: Bus address used to access the memory region + * @dev_addr: Device address of the memory region from DSP view + * @size: Size of the memory region + */
