Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the kaslr implementation, let's reimplement
> >> the matching of the "nokaslr" option with it.
> >>
> >> Signed-off-by: Marc Zyngier
> >> Acked-by: Catalin Marinas
> >> Acked-by: David Brazdil
> >> ---
> >> arch/arm64/kernel/idreg-override.c | 15 +
> >> arch/arm64/kernel/kaslr.c | 36
> >> ++
> >> 2 files changed, 17 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/idreg-override.c
> >> b/arch/arm64/kernel/idreg-override.c
> >> index cbb8eaa48742..3ccf51b84ba4 100644
> >> --- a/arch/arm64/kernel/idreg-override.c
> >> +++ b/arch/arm64/kernel/idreg-override.c
> >> @@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
> >> {
> >> },
> >> };
> >>
> >> +extern struct arm64_ftr_override kaslr_feature_override;
> >> +
> >> +static const struct ftr_set_desc kaslr __initdata = {
> >
> > This should be __initconst not __initdata (below too)
> >
> >> + .name = "kaslr",
> >> +#ifdef CONFIG_RANDOMIZE_BASE
> >> + .override = _feature_override,
> >> +#endif
> >> + .fields = {
> >> + { "disabled", 0 },
> >> + {}
> >> + },
> >> +};
> >> +
> >> static const struct ftr_set_desc * const regs[] __initdata = {
> >> ,
> >> + ,
> >> };
> >>
> >> static const struct {
> >> @@ -41,6 +55,7 @@ static const struct {
> >> } aliases[] __initdata = {
> >> { "kvm-arm.mode=nvhe", "id_aa64mmfr1.vh=0" },
> >> { "kvm-arm.mode=protected", "id_aa64mmfr1.vh=0" },
> >> + { "nokaslr","kaslr.disabled=1" },
> >> };
> >>
> >
> > This struct now takes up
> > - ~100 bytes for the characters themselves (which btw are not emitted
> > into __initdata or __initconst)
> > - 6x8 bytes for the char pointers
> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> > quantities that need to be relocated at boot (on a kernel built with
> > KASLR)
> >
> > I know it's only a drop in the ocean, but in this case, where the
> > struct is statically declared and defined only once, and in the same
> > place, we could easily turn this into
> >
> > static const struct {
> >char alias[24];
> >char param[20];
> > };
> >
> > and get rid of all the overhead. The only slightly annoying thing is
> > that the array sizes need to be kept in sync with the largest instance
> > appearing in the array, but this is easy when the struct type is
> > declared in the same place where its only instance is defined.
>
> Fair enough. I personally find the result butt-ugly, but I agree
> that it certainly saves some memory. Does the following work for
> you? I can even give symbolic names to the various constants (how
> generous of me! ;-).
>
To be honest, I was anticipating more of a discussion, but this looks
reasonable to me. Does 'charfeature[80];' really need 80 bytes
though?
> diff --git a/arch/arm64/kernel/idreg-override.c
> b/arch/arm64/kernel/idreg-override.c
> index d1310438d95c..9e7043bdc808 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -14,15 +14,15 @@
> #include
>
> struct ftr_set_desc {
> - const char *name;
> + charname[20];
> struct arm64_ftr_override *override;
> struct {
> - const char *name;
> + charname[20];
> u8 shift;
> } fields[];
> };
>
> -static const struct ftr_set_desc mmfr1 __initdata = {
> +static const struct ftr_set_desc mmfr1 __initconst = {
> .name = "id_aa64mmfr1",
> .override = _aa64mmfr1_override,
> .fields = {
> @@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
> },
> };
>
> -static const struct ftr_set_desc pfr1 __initdata = {
> +static const struct ftr_set_desc pfr1 __initconst = {
> .name = "id_aa64pfr1",
> .override = _aa64pfr1_override,
> .fields = {
> @@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
> },
> };
>
> -static const struct ftr_set_desc isar1 __initdata = {
> +static const struct ftr_set_desc isar1 __initconst = {
> .name = "id_aa64isar1",
> .override = _aa64isar1_override,
> .fields = {
> @@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
>
> extern struct arm64_ftr_override kaslr_feature_override;
>
> -static const struct ftr_set_desc kaslr __initdata = {
> +static const struct ftr_set_desc kaslr __initconst =
Re: [PATCH 2/2] spidev: Add cisco device compatible
On Thu, 21 Jan 2021 15:12:36 -0800, Daniel Walker wrote: > Add compatible string for Cisco device present on the Cisco Petra > platform. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [2/2] spidev: Add cisco device compatible commit: 396cf2a46adddbf51373e16225c1d25254310046 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 0/2] mmc: J7200: Add support for higher speed modes in MMCSD subsystems
On 19:43-20210125, Aswath Govindraju wrote: > >>> Will also help to provide some verification log along with this. > >>> > >> > >> May I know what sort of logs would be best to provide. Would enumeration > >> logs during boot suffice ? > >> > >> Like this, > >> https://pastebin.ubuntu.com/p/v9NRV7GwMw/ ? > > > > That just says we detected the cards, no? > > I thought we had tests around this? Something including > > /sys/kernel/debug/mmc*/ios > > > > Something that demonstrates that this actually runs at the claimed > > speeds? That would be nice on linux-next, if possible as well.. > > > > Yes there are tests which confirm that claimed speeds are functional. I > will add them in the respin. Awesome. much appreciated. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v7 13/14] selftests/vm: test flag is broken
On Sun, Jan 24, 2021 at 6:03 PM John Hubbard wrote:
>
> On 1/21/21 7:37 PM, Pavel Tatashin wrote:
> > In gup_test both gup_flags and test_flags use the same flags field.
> > This is broken.
> >
> > Farther, in the actual gup_test.c all the passed gup_flags are erased and
> > unconditionally replaced with FOLL_WRITE.
> >
> > Which means that test_flags are ignored, and code like this always
> > performs pin dump test:
> >
> > 155 if (gup->flags & GUP_TEST_FLAG_DUMP_PAGES_USE_PIN)
> > 156 nr = pin_user_pages(addr, nr, gup->flags,
> > 157 pages + i, NULL);
> > 158 else
> > 159 nr = get_user_pages(addr, nr, gup->flags,
> > 160 pages + i, NULL);
> > 161 break;
> >
> > Add a new test_flags field, to allow raw gup_flags to work.
> > Add a new subcommand for DUMP_USER_PAGES_TEST to specify that pin test
> > should be performed.
> > Remove unconditional overwriting of gup_flags via FOLL_WRITE. But,
> > preserve the previous behaviour where FOLL_WRITE was the default flag,
> > and add a new option "-W" to unset FOLL_WRITE.
> >
> > Rename flags with gup_flags.
>
> Hi Pavel,
>
> Thanks again for fixing this up! Looks good, with a tiny point about the
> subject line:
>
> 1) To follow convention, the subject line should say what you're doing,
> not what the previous condition was. Also, there are several tests in that
> directory, so we should say which one. So more like this:
>
> "selftests/vm: gup_test: fix test flag"
>
> That is just a minor documentation point, so either way, feel free to add:
>
>
> Reviewed-by: John Hubbard
Thank you for your review , I will change the subject line in the next update.
Pasha
>
>
> thanks,
> --
> John Hubbard
> NVIDIA
>
> >
> > With the fix, dump works like this:
> >
> > root@virtme:/# gup_test -c
> > page #0, starting from user virt addr: 0x7f8acb9e4000
> > page:d3d2ee27 refcount:2 mapcount:1 mapping:
> > index:0x0 pfn:0x100bcf
> > anon flags: 0x3080016(referenced|uptodate|lru|swapbacked)
> > raw: 03080016 d0e204021608 d0e208df2e88 8ea04243ec61
> > raw: 0002
> > page dumped because: gup_test: dump_pages() test
> > DUMP_USER_PAGES_TEST: done
> >
> > root@virtme:/# gup_test -c -p
> > page #0, starting from user virt addr: 0x7fd19701b000
> > page:baed3c7d refcount:1025 mapcount:1 mapping:
> > index:0x0 pfn:0x108008
> > anon flags: 0x3080014(uptodate|lru|swapbacked)
> > raw: 03080014 d0e204200188 d0e205e09088 8ea04243ee71
> > raw: 0401
> > page dumped because: gup_test: dump_pages() test
> > DUMP_USER_PAGES_TEST: done
> >
> > Refcount shows the difference between pin vs no-pin case.
> > Also change type of nr from int to long, as it counts number of pages.
> >
> > Signed-off-by: Pavel Tatashin
> > ---
> > mm/gup_test.c | 23 ++-
> > mm/gup_test.h | 3 ++-
> > tools/testing/selftests/vm/gup_test.c | 15 +++
> > 3 files changed, 23 insertions(+), 18 deletions(-)
> >
> > diff --git a/mm/gup_test.c b/mm/gup_test.c
> > index e3cf78e5873e..a6ed1c877679 100644
> > --- a/mm/gup_test.c
> > +++ b/mm/gup_test.c
> > @@ -94,7 +94,7 @@ static int __gup_test_ioctl(unsigned int cmd,
> > {
> > ktime_t start_time, end_time;
> > unsigned long i, nr_pages, addr, next;
> > - int nr;
> > + long nr;
> > struct page **pages;
> > int ret = 0;
> > bool needs_mmap_lock =
> > @@ -126,37 +126,34 @@ static int __gup_test_ioctl(unsigned int cmd,
> > nr = (next - addr) / PAGE_SIZE;
> > }
> >
> > - /* Filter out most gup flags: only allow a tiny subset here:
> > */
> > - gup->flags &= FOLL_WRITE;
> > -
> > switch (cmd) {
> > case GUP_FAST_BENCHMARK:
> > - nr = get_user_pages_fast(addr, nr, gup->flags,
> > + nr = get_user_pages_fast(addr, nr, gup->gup_flags,
> >pages + i);
> > break;
> > case GUP_BASIC_TEST:
> > - nr = get_user_pages(addr, nr, gup->flags, pages + i,
> > + nr = get_user_pages(addr, nr, gup->gup_flags, pages +
> > i,
> > NULL);
> > break;
> > case PIN_FAST_BENCHMARK:
> > - nr = pin_user_pages_fast(addr, nr, gup->flags,
> > + nr = pin_user_pages_fast(addr, nr, gup->gup_flags,
> >pages + i);
> > break;
> >
Re: [PATCH] mm/filemap: Adding missing mem_cgroup_uncharge() to __add_to_page_cache_locked()
On 1/25/21 1:30 AM, Miaohe Lin wrote:
On 2021/1/25 12:24, Waiman Long wrote:
The commit 3fea5a499d57 ("mm: memcontrol: convert page
cache to a new mem_cgroup_charge() API") introduced a bug in
__add_to_page_cache_locked() causing the following splat:
[ 1570.068330] page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
[ 1570.068333] pages's memcg:8889a4116000
[ 1570.068343] [ cut here ]
[ 1570.068346] kernel BUG at mm/memcontrol.c:2924!
[ 1570.068355] invalid opcode: [#1] SMP KASAN PTI
[ 1570.068359] CPU: 35 PID: 12345 Comm: cat Tainted: G S W I
5.11.0-rc4-debug+ #1
[ 1570.068363] Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25
12/06/2017
[ 1570.068365] RIP: 0010:commit_charge+0xf4/0x130
:
[ 1570.068375] RSP: 0018:8881b38d70e8 EFLAGS: 00010286
[ 1570.068379] RAX: RBX: ea00260ddd00 RCX:
0027
[ 1570.068382] RDX: RSI: 0004 RDI:
88907ebe05a8
[ 1570.068384] RBP: ea00260ddd00 R08: ed120fd7c0b6 R09:
ed120fd7c0b6
[ 1570.068386] R10: 88907ebe05ab R11: ed120fd7c0b5 R12:
ea00260ddd38
[ 1570.068389] R13: 8889a4116000 R14: 8889a4116000 R15:
0001
[ 1570.068391] FS: 7ff039638680() GS:88907ea0()
knlGS:
[ 1570.068394] CS: 0010 DS: ES: CR0: 80050033
[ 1570.068396] CR2: 7f36f354cc20 CR3: 0008a0126006 CR4:
007706e0
[ 1570.068398] DR0: DR1: DR2:
[ 1570.068400] DR3: DR6: fffe0ff0 DR7:
0400
[ 1570.068402] PKRU: 5554
[ 1570.068404] Call Trace:
[ 1570.068407] mem_cgroup_charge+0x175/0x770
[ 1570.068413] __add_to_page_cache_locked+0x712/0xad0
[ 1570.068439] add_to_page_cache_lru+0xc5/0x1f0
[ 1570.068461] cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
[ 1570.068524] __fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
[ 1570.068540] __nfs_readpages_from_fscache+0x16d/0x630 [nfs]
[ 1570.068585] nfs_readpages+0x24e/0x540 [nfs]
[ 1570.068693] read_pages+0x5b1/0xc40
[ 1570.068711] page_cache_ra_unbounded+0x460/0x750
[ 1570.068729] generic_file_buffered_read_get_pages+0x290/0x1710
[ 1570.068756] generic_file_buffered_read+0x2a9/0xc30
[ 1570.068832] nfs_file_read+0x13f/0x230 [nfs]
[ 1570.068872] new_sync_read+0x3af/0x610
[ 1570.068901] vfs_read+0x339/0x4b0
[ 1570.068909] ksys_read+0xf1/0x1c0
[ 1570.068920] do_syscall_64+0x33/0x40
[ 1570.068926] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1570.068930] RIP: 0033:0x7ff039135595
Before that commit, there was a try_charge() and commit_charge()
in __add_to_page_cache_locked(). These 2 separated charge functions
were replaced by a single mem_cgroup_charge(). However, it forgot
to add a matching mem_cgroup_uncharge() when the xarray insertion
failed with the page released back to the pool. Fix this by adding a
mem_cgroup_uncharge() call when insertion error happens.
Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new
mem_cgroup_charge() API")
Signed-off-by: Waiman Long
Cc stable should be needed.
Yes, this patch should go to stable. I think the stable tree maintainers
will automatically pick up patches with the "Fixes" tag. That is why I
don't explicitly put a "cc:stable" line in the patch.
Thanks,
Longman
[PATCH v2] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
YUV 4:4:4 is not subsampled, fix this in the docs.
Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV formats
to common file")
Signed-off-by: Helen Koike
---
Changes in v2:
- s/No sub-sampling/The chroma plane is not subsampled/ (Laurent)
- Fixed description regarding the number of bytes (Laurent)
---
Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
index 7d4d39201a3f..1e0db602cc1b 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
@@ -396,9 +396,9 @@ number of lines as the luma plane.
NV24 and NV42
-
-Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
-horizontal direction. Chroma lines contain half the number of pixels and the
-same number of bytes as luma lines, and the chroma plane contains the same
+Semi-planar YUV 4:4:4 formats. The chroma plane is not subsampled.
+Chroma lines contain the same number of pixels and twice the
+number of bytes as luma lines, and the chroma plane contains the same
number of lines as the luma plane.
.. flat-table:: Sample 4x4 NV24 Image
--
2.30.0
[PATCH 2/2] KVM: arm64: Skip the cache flush when coalescing tables into a block
After dirty-logging is stopped for a VM configured with huge mappings,
KVM will recover the table mappings back to block mappings. As we only
replace the existing page tables with a block entry and the cacheability
has not been changed, the cache maintenance opreations can be skipped.
Signed-off-by: Yanan Wang
---
arch/arm64/kvm/mmu.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8e8549ea1d70..37b427dcbc4f 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -744,7 +744,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
{
int ret = 0;
bool write_fault, writable, force_pte = false;
- bool exec_fault;
+ bool exec_fault, adjust_hugepage;
bool device = false;
unsigned long mmu_seq;
struct kvm *kvm = vcpu->kvm;
@@ -872,12 +872,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
mark_page_dirty(kvm, gfn);
}
- if (fault_status != FSC_PERM && !device)
+ /*
+* There is no necessity to perform cache maintenance operations if we
+* will only replace the existing table mappings with a block mapping.
+*/
+ adjust_hugepage = fault_granule < vma_pagesize ? true : false;
+ if (fault_status != FSC_PERM && !device && !adjust_hugepage)
clean_dcache_guest_page(pfn, vma_pagesize);
if (exec_fault) {
prot |= KVM_PGTABLE_PROT_X;
- invalidate_icache_guest_page(pfn, vma_pagesize);
+ if (!adjust_hugepage)
+ invalidate_icache_guest_page(pfn, vma_pagesize);
}
if (device)
--
2.19.1
[PATCH 0/2] Performance improvement about cache flush
Hi, This two patches are posted to introduce a new method that can distinguish cases of allocating memcache more precisely, and to elide some unnecessary cache flush. For patch-1: With a guest translation fault, we don't really need the memcache pages when only installing a new entry to the existing page table or replacing the table entry with a block entry. And with a guest permission fault, we also don't need the memcache pages for a write_fault in dirty-logging time if VMs are not configured with huge mappings. So a new method is introduced to distinguish cases of allocating memcache more precisely. For patch-2: If migration of a VM with hugepages is canceled midway, KVM will adjust the stage-2 table mappings back to block mappings. With multiple vCPUs accessing guest pages within the same 1G range, there could be numbers of translation faults to handle, and KVM will uniformly flush data cache for 1G range before handling the faults. As it will cost a long time to flush the data cache for 1G range of memory(130ms on Kunpeng 920 servers, for example), the consequent cache flush for each translation fault will finally lead to vCPU stuck for seconds or even a soft lockup. I have met both the stuck and soft lockup on Kunpeng servers with FWB not supported. When KVM need to recover the table mappings back to block mappings, as we only replace the existing page tables with a block entry and the cacheability has not been changed, the cache maintenance opreations can be skipped. Yanan Wang (2): KVM: arm64: Distinguish cases of allocating memcache more precisely KVM: arm64: Skip the cache flush when coalescing tables into a block arch/arm64/kvm/mmu.c | 37 + 1 file changed, 21 insertions(+), 16 deletions(-) -- 2.19.1
Re: [PATCH v2 09/17] mfd: Support for ROHM BD71815 PMIC core
On Tue, 19 Jan 2021, Matti Vaittinen wrote:
> Add core support for ROHM BD71815 Power Management IC.
>
> The IC integrates regulators, a battery charger with a coulomb counter,
> a real-time clock (RTC), clock gate and general-purpose outputs (GPO).
>
> Signed-off-by: Matti Vaittinen
> ---
> Changes since v1:
> - Used BIT() for better readability
> - removed some unused definitions
>
> drivers/mfd/Kconfig | 15 +-
> drivers/mfd/rohm-bd71828.c | 416 +--
> include/linux/mfd/rohm-bd71815.h | 561 +++
> include/linux/mfd/rohm-bd71828.h | 3 +
> 4 files changed, 952 insertions(+), 43 deletions(-)
> create mode 100644 include/linux/mfd/rohm-bd71815.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index bdfce7b15621..59bfacb91898 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1984,19 +1984,20 @@ config MFD_ROHM_BD70528
> charger.
>
> config MFD_ROHM_BD71828
> - tristate "ROHM BD71828 Power Management IC"
> + tristate "ROHM BD71828 and BD71815 Power Management IC"
> depends on I2C=y
> depends on OF
> select REGMAP_I2C
> select REGMAP_IRQ
> select MFD_CORE
> help
> - Select this option to get support for the ROHM BD71828 Power
> - Management IC. BD71828GW is a single-chip power management IC for
> - battery-powered portable devices. The IC integrates 7 buck
> - converters, 7 LDOs, and a 1500 mA single-cell linear charger.
> - Also included is a Coulomb counter, a real-time clock (RTC), and
> - a 32.768 kHz clock gate.
> + Select this option to get support for the ROHM BD71828 and BD71815
> + Power Management ICs. BD71828GW and BD71815AGW are single-chip power
> + management ICs mainly for battery-powered portable devices.
> + The BD71828 integrates 7 buck converters and 7 LDOs. The BD71815
> + has 5 bucks, 7 LDOs, and a boost for driving LEDs. Both ICs provide
> + also a single-cell linear charger, a Coulomb counter, a real-time
> + clock (RTC), GPIOs and a 32.768 kHz clock gate.
>
> config MFD_STM32_LPTIMER
> tristate "Support for STM32 Low-Power Timer"
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index 210261d026f2..28b82477ce4c 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -2,7 +2,7 @@
> //
> // Copyright (C) 2019 ROHM Semiconductors
> //
> -// ROHM BD71828 PMIC driver
> +// ROHM BD71828/BD71815 PMIC driver
>
> #include
> #include
> @@ -11,7 +11,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -29,12 +31,102 @@ static struct gpio_keys_platform_data
> bd71828_powerkey_data = {
> .name = "bd71828-pwrkey",
> };
>
> -static const struct resource rtc_irqs[] = {
> +static const struct resource bd71815_rtc_irqs[] = {
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_RTC0, "bd71815-rtc-alm-0"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_RTC1, "bd71815-rtc-alm-1"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_RTC2, "bd71815-rtc-alm-2"),
> +};
> +
> +static const struct resource bd71828_rtc_irqs[] = {
> DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC0, "bd71828-rtc-alm-0"),
> DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC1, "bd71828-rtc-alm-1"),
> DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC2, "bd71828-rtc-alm-2"),
> };
>
> +static struct resource bd71815_power_irqs[] = {
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_RMV, "bd71815-dcin-rmv"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CLPS_OUT, "bd71815-clps-out"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CLPS_IN, "bd71815-clps-in"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_OVP_RES, "bd71815-dcin-ovp-res"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_OVP_DET, "bd71815-dcin-ovp-det"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_MON_RES, "bd71815-dcin-mon-res"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_MON_DET, "bd71815-dcin-mon-det"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_UV_RES, "bd71815-vsys-uv-res"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_UV_DET, "bd71815-vsys-uv-det"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_LOW_RES, "bd71815-vsys-low-res"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_LOW_DET, "bd71815-vsys-low-det"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_MON_RES, "bd71815-vsys-mon-res"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_MON_RES, "bd71815-vsys-mon-det"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_WDG_TEMP, "bd71815-chg-wdg-temp"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_WDG_TIME, "bd71815-chg-wdg"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_RECHARGE_RES, "bd71815-rechg-res"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_RECHARGE_DET, "bd71815-rechg-det"),
> + DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_RANGED_TEMP_TRANSITION,
> + "bd71815-ranged-temp-transit"),
The new line limit is 100.
Re: [PATCH 1/3] tracing: Merge irqflags + preempt counter.
On 2021-01-22 17:07:50 [-0500], Steven Rostedt wrote:
> On Wed, 13 Jan 2021 00:00:55 +0100
> Sebastian Andrzej Siewior wrote:
>
> > +unsigned int _tracing_gen_ctx_flags(unsigned long irqflags);
> > +unsigned int tracing_gen_ctx_flags(void);
> > +unsigned int tracing_gen_ctx_flags_dect(void);
>
> Since I'm now trying to avoid underscore functions when possible, the above
> should be:
>
> _tracing_gen_ctx_flags() --> tracing_gen_ctx_flags()
> tracing_gen_ctx_flags()--> tracing_gen_ctx()
> tracing_gen_ctx_flags_dect --> tracing_gen_ctx_dec()
>
> Note, "_dec()" should be used instead of "_dect()" as "_dec" is commonly
> used around the kernel, and I had really no idea what "_dect" was, until I
> looked at the two functions.
Okay, let me do the renames.
> And looking at the implementation, I wonder if we should make this into
> static inlines in the header as follows:
>
> unsigned int tracing_gen_ctx_irq_test(int irqs_status);
>
> #ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT
> static inline unsigned int tracing_gen_ctx_flags(unsigned long irqflags)
> {
> unsigned int irq_status = irqs_disabled(irqflags) ?
> TRACE_FLAG_IRQS_OFF : 0;
> return tracing_gen_ctx_irq_test(irq_status);
> }
> static inline unsigned int tracing_gen_ctx(void)
> {
> unsigned long irqflags;
>
> local_save_flags(irqflags);
> return tracing_gen_ctx_flags(irqflags);
> }
> #else
> static inline unsigned int tracing_gen_ctx_flags(unsigned long irqflags)
> {
> return tracing_gen_ctx_irq_test(TRACE_FLAG_IRQS_NOSUPPORT);
> }
> static inline unsigned int tracing_gen_ctx(void)
> {
> return tracing_gen_ctx_irq_test(TRACE_FLAG_IRQS_NOSUPPORT);
> }
> #endif
>
> static inline unsigned int tracing_gen_ctx_dec(void)
> {
> unsigned int trace_ctx;
>
> trace_ctx = tracing_gen_ctx();
> /*** Comment about buffer_reserve here ***/
> if (IS_ENABLED(CONFIG_PREEMPTION))
> trace_ctx--;
> return trace_ctx;
> }
>
> Then all you need to do is implement the tracing_gen_ctx_irq_test() without
> adding and #ifdefs in it, and just or in the "irq_status" to trace_flags,
> without any conditionals.
You just moved that from one place to another. I had to move enum
trace_flag_type just before tracing_gen_ctx_irq_test() so it is
available by tracing_gen_ctx_flags(). I don't know if you earn by
inlining much, the gcc numbers for vmlinux:
text data bss dec filename
24306853 21869070 14205180 60381103 vmlinux-rc5
24306482 21869070 14205180 60380732 vmlinux-rc5-merge-irqflags
24306852 21869070 14205180 60381102 vmlinux-rc5-merge-irqflags-inline
I know that a reduction by ~300 byte isn't exactly breath taking. I run
the test twice because the reduction in text by one byte looked odd but
it is what it is. Inlining only tracing_gen_ctx_dec() probably makes
sense especially since there is one user.
I can post the irqflags-merge and the inlinining as two seprate patches
and you can then decide if you merge the two patches or drop the
inlining.
> -- Steve
Sebastian
Re: [PATCH v3 0/2] net: sfp: add support for GPON RTL8672/RTL9601C and Ubiquiti U-Fiber
On Monday 18 January 2021 10:34:35 Pali Rohár wrote: > On Monday 11 January 2021 12:39:07 Pali Rohár wrote: > > This is a third version of patches which add workarounds for > > RTL8672/RTL9601C EEPROMs and Ubiquiti U-Fiber Instant SFP. > > > > Russel's PATCH v2 2/3 was dropped from this patch series as > > it is being handled separately. > > Andrew and Russel, are you fine with this third iteration of patches? > Or are there still some issues which needs to be fixed? PING! > > Pali Rohár (2): > > net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips > > net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant > > > > drivers/net/phy/sfp-bus.c | 15 + > > drivers/net/phy/sfp.c | 117 ++ > > 2 files changed, 97 insertions(+), 35 deletions(-) > > > > -- > > 2.20.1 > >
Re: [PATCH] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
On 1/25/21 10:57 AM, Helen Koike wrote:
>
>
> On 1/23/21 6:56 AM, Laurent Pinchart wrote:
>> Hi Helen,
>>
>> Thank you for the patch.
>>
>> On Fri, Jan 22, 2021 at 03:27:23PM -0300, Helen Koike wrote:
>>> YUV 4:4:4 is not subsampled, fix this in the docs.
>>>
>>> Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV
>>> formats to common file")
>>> Signed-off-by: Helen Koike
>>> ---
>>> Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> index 7d4d39201a3f..bcb4ef24c334 100644
>>> --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> @@ -396,8 +396,8 @@ number of lines as the luma plane.
>>> NV24 and NV42
>>> -
>>>
>>> -Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
>>> -horizontal direction. Chroma lines contain half the number of pixels and
>>> the
>>> +Semi-planar YUV 4:4:4 formats. No sub-sampling.
>>
>> "The chroma plane is not subsampled." ?
>
> Ack.
>
>>
>>> +Chroma lines contain the same number of pixels and the
>>> same number of bytes as luma lines, and the chroma plane contains the same
>>> number of lines as the luma plane.
>>
>> That's not quite right, the chroma lines contain twice the number of
>> pixels and bytes, as there's one Cb and one Cr value in the chroma line
>> for each Y value in the luma line.
Actually, it is the same number o pixels, but twice the number o bytes.
Since a trio (YCbCr) compose a pixel.
At least this is how I understand comparing the logic of the text description
of NV16 YUV4:2:2.
Regards,
Helen
>>
>>
>> Maybe the text could be reflowed ?
>>
>
> Ack.
>
> I'll submit v2 updating the text.
>
> Thanks,
> Helen
>
Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
On 2021-01-25 12:54, Ard Biesheuvel wrote:
On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
Given that the early cpufeature infrastructure has borrowed quite
a lot of code from the kaslr implementation, let's reimplement
the matching of the "nokaslr" option with it.
Signed-off-by: Marc Zyngier
Acked-by: Catalin Marinas
Acked-by: David Brazdil
---
arch/arm64/kernel/idreg-override.c | 15 +
arch/arm64/kernel/kaslr.c | 36
++
2 files changed, 17 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/kernel/idreg-override.c
b/arch/arm64/kernel/idreg-override.c
index cbb8eaa48742..3ccf51b84ba4 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
{
},
};
+extern struct arm64_ftr_override kaslr_feature_override;
+
+static const struct ftr_set_desc kaslr __initdata = {
This should be __initconst not __initdata (below too)
+ .name = "kaslr",
+#ifdef CONFIG_RANDOMIZE_BASE
+ .override = _feature_override,
+#endif
+ .fields = {
+ { "disabled", 0 },
+ {}
+ },
+};
+
static const struct ftr_set_desc * const regs[] __initdata = {
,
+ ,
};
static const struct {
@@ -41,6 +55,7 @@ static const struct {
} aliases[] __initdata = {
{ "kvm-arm.mode=nvhe", "id_aa64mmfr1.vh=0" },
{ "kvm-arm.mode=protected", "id_aa64mmfr1.vh=0" },
+ { "nokaslr","kaslr.disabled=1" },
};
This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted
into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as
quantities that need to be relocated at boot (on a kernel built with
KASLR)
I know it's only a drop in the ocean, but in this case, where the
struct is statically declared and defined only once, and in the same
place, we could easily turn this into
static const struct {
char alias[24];
char param[20];
};
and get rid of all the overhead. The only slightly annoying thing is
that the array sizes need to be kept in sync with the largest instance
appearing in the array, but this is easy when the struct type is
declared in the same place where its only instance is defined.
Fair enough. I personally find the result butt-ugly, but I agree
that it certainly saves some memory. Does the following work for
you? I can even give symbolic names to the various constants (how
generous of me! ;-).
Thanks,
M.
diff --git a/arch/arm64/kernel/idreg-override.c
b/arch/arm64/kernel/idreg-override.c
index d1310438d95c..9e7043bdc808 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -14,15 +14,15 @@
#include
struct ftr_set_desc {
- const char *name;
+ charname[20];
struct arm64_ftr_override *override;
struct {
- const char *name;
+ charname[20];
u8 shift;
} fields[];
};
-static const struct ftr_set_desc mmfr1 __initdata = {
+static const struct ftr_set_desc mmfr1 __initconst = {
.name = "id_aa64mmfr1",
.override = _aa64mmfr1_override,
.fields = {
@@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
},
};
-static const struct ftr_set_desc pfr1 __initdata = {
+static const struct ftr_set_desc pfr1 __initconst = {
.name = "id_aa64pfr1",
.override = _aa64pfr1_override,
.fields = {
@@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
},
};
-static const struct ftr_set_desc isar1 __initdata = {
+static const struct ftr_set_desc isar1 __initconst = {
.name = "id_aa64isar1",
.override = _aa64isar1_override,
.fields = {
@@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
extern struct arm64_ftr_override kaslr_feature_override;
-static const struct ftr_set_desc kaslr __initdata = {
+static const struct ftr_set_desc kaslr __initconst = {
.name = "kaslr",
#ifdef CONFIG_RANDOMIZE_BASE
.override = _feature_override,
@@ -65,7 +65,7 @@ static const struct ftr_set_desc kaslr __initdata = {
},
};
-static const struct ftr_set_desc * const regs[] __initdata = {
+static const struct ftr_set_desc * const regs[] __initconst = {
,
,
,
@@ -73,9 +73,9 @@ static const struct ftr_set_desc * const regs[]
__initdata = {
};
static const struct {
- const char *alias;
- const char *feature;
-} aliases[] __initdata = {
+ charalias[30];
+ char
Re: [RFC PATCH v1] sched/fair: limit load balance redo times at the same sched_domain level
On 2021/1/25 18:56, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 06:50, Aubrey Li wrote:
>>
>> A long-tail load balance cost is observed on the newly idle path,
>> this is caused by a race window between the first nr_running check
>> of the busiest runqueue and its nr_running recheck in detach_tasks.
>>
>> Before the busiest runqueue is locked, the tasks on the busiest
>> runqueue could be pulled by other CPUs and nr_running of the busiest
>> runqueu becomes 1, this causes detach_tasks breaks with LBF_ALL_PINNED
>
> We should better detect that when trying to detach task like below
This should be a compromise from my understanding. If we give up load balance
this time due to the race condition, we do reduce the load balance cost on the
newly idle path, but if there is an imbalance indeed at the same sched_domain
level, we have to wait the next softirq entry to handle that imbalance. This
means the tasks on the second busiest runqueue have to stay longer, which could
introduce tail latency as well. That's why I introduced a variable to control
the redo loops. I'll send this to the benchmark queue to see if it makes any
difference.
Thanks,
-Aubrey
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7688,6 +7688,16 @@ static int detach_tasks(struct lb_env *env)
>
> lockdep_assert_held(>src_rq->lock);
>
> + /*
> +* Another CPU has emptied this runqueue in the meantime.
> +* Just return and leave the load_balance properly.
> +*/
> + if (env->src_rq->nr_running <= 1 && !env->loop) {
> + /* Clear the flag as we will not test any task */
> + env->flags &= ~LBF_ALL_PINNED;
> + return 0;
> + }
> +
> if (env->imbalance <= 0)
> return 0;
>
>
>> flag set, and triggers load_balance redo at the same sched_domain level.
>>
>> In order to find the new busiest sched_group and CPU, load balance will
>> recompute and update the various load statistics, which eventually leads
>> to the long-tail load balance cost.
>>
>> This patch introduces a variable(sched_nr_lb_redo) to limit load balance
>> redo times, combined with sysctl_sched_nr_migrate, the max load balance
>> cost is reduced from 100+ us to 70+ us, measured on a 4s x86 system with
>> 192 logical CPUs.
>>
>> Cc: Andi Kleen
>> Cc: Tim Chen
>> Cc: Srinivas Pandruvada
>> Cc: Rafael J. Wysocki
>> Signed-off-by: Aubrey Li
>> ---
>> kernel/sched/fair.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index ae7ceba..b59f371 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -7407,6 +7407,8 @@ struct lb_env {
>> unsigned intloop;
>> unsigned intloop_break;
>> unsigned intloop_max;
>> + unsigned intredo_cnt;
>> + unsigned intredo_max;
>>
>> enum fbq_type fbq_type;
>> enum migration_type migration_type;
>> @@ -9525,6 +9527,7 @@ static int should_we_balance(struct lb_env *env)
>> return group_balance_cpu(sg) == env->dst_cpu;
>> }
>>
>> +static const unsigned int sched_nr_lb_redo = 1;
>> /*
>> * Check this_cpu to ensure it is balanced within domain. Attempt to move
>> * tasks if there is an imbalance.
>> @@ -9547,6 +9550,7 @@ static int load_balance(int this_cpu, struct rq
>> *this_rq,
>> .dst_grpmask= sched_group_span(sd->groups),
>> .idle = idle,
>> .loop_break = sched_nr_migrate_break,
>> + .redo_max = sched_nr_lb_redo,
>> .cpus = cpus,
>> .fbq_type = all,
>> .tasks = LIST_HEAD_INIT(env.tasks),
>> @@ -9682,7 +9686,8 @@ static int load_balance(int this_cpu, struct rq
>> *this_rq,
>> * destination group that is receiving any migrated
>> * load.
>> */
>> - if (!cpumask_subset(cpus, env.dst_grpmask)) {
>> + if (!cpumask_subset(cpus, env.dst_grpmask) &&
>> + ++env.redo_cnt < env.redo_max) {
>> env.loop = 0;
>> env.loop_break = sched_nr_migrate_break;
>> goto redo;
>> --
>> 2.7.4
>>
Re: [PATCH] Revert "mm: memcontrol: avoid workload stalls when lowering memory.high"
Johannes Weiner writes:
This reverts commit 536d3bf261a2fc3b05b3e91e7eef7383443015cf, as it
can cause writers to memory.high to get stuck in the kernel forever,
performing page reclaim and consuming excessive amounts of CPU cycles.
Before the patch, a write to memory.high would first put the new limit
in place for the workload, and then reclaim the requested delta. After
the patch, the kernel tries to reclaim the delta before putting the
new limit into place, in order to not overwhelm the workload with a
sudden, large excess over the limit. However, if reclaim is actively
racing with new allocations from the uncurbed workload, it can keep
the write() working inside the kernel indefinitely.
This is causing problems in Facebook production. A privileged
system-level daemon that adjusts memory.high for various workloads
running on a host can get unexpectedly stuck in the kernel and
essentially turn into a sort of involuntary kswapd for one of the
workloads. We've observed that daemon busy-spin in a write() for
minutes at a time, neglecting its other duties on the system, and
expending privileged system resources on behalf of a workload.
To remedy this, we have first considered changing the reclaim logic to
break out after a couple of loops - whether the workload has converged
to the new limit or not - and bound the write() call this way.
However, the root cause that inspired the sequence change in the first
place has been fixed through other means, and so a revert back to the
proven limit-setting sequence, also used by memory.max, is preferable.
The sequence was changed to avoid extreme latencies in the workload
when the limit was lowered: the sudden, large excess created by the
limit lowering would erroneously trigger the penalty sleeping code
that is meant to throttle excessive growth from below. Allocating
threads could end up sleeping long after the write() had already
reclaimed the delta for which they were being punished.
However, erroneous throttling also caused problems in other scenarios
at around the same time. This resulted in commit b3ff92916af3 ("mm,
memcg: reclaim more aggressively before high allocator throttling"),
included in the same release as the offending commit. When allocating
threads now encounter large excess caused by a racing write() to
memory.high, instead of entering punitive sleeps, they will simply be
tasked with helping reclaim down the excess, and will be held no
longer than it takes to accomplish that. This is in line with regular
limit enforcement - i.e. if the workload allocates up against or over
an otherwise unchanged limit from below.
With the patch breaking userspace, and the root cause addressed by
other means already, revert it again.
Fixes: 536d3bf261a2 ("mm: memcontrol: avoid workload stalls when lowering
memory.high")
Cc: # 5.8+
Reported-by: Tejun Heo
Signed-off-by: Johannes Weiner
Acked-by: Chris Down
Re: [RFC PATCH 0/4] make jbd2 debug switch per device
Thanks for your reply. Jan Kara wrote on 2021/1/25 20:41: > On Fri 22-01-21 14:43:18, Chunguang Xu wrote: >> On a multi-disk machine, because jbd2 debugging switch is global, this >> confuses the logs of multiple disks. It is not easy to distinguish the >> logs of each disk and the amount of generated logs is very large. Or a >> separate debugging switch for each disk would be better, so that you >> can easily distinguish the logs of a certain disk. >> >> We can enable jbd2 debugging of a device in the following ways: >> echo X > /proc/fs/jbd2/sdX/jbd2_debug >> >> But there is a small disadvantage here. Because the debugging switch is >> placed in the journal_t object, the log before the object is initialized >> will be lost. However, usually this will not have much impact on >> debugging. > > OK, I didn't look at the series yet but I'm wondering: How are you using > jbd2 debugging? I mean obviously it isn't meant for production use but > rather for debugging JBD2 bugs so I'm kind of wondering in which case too > many messages matter. We perform stress testing on machines in the test environment, and use scripts to capture journal related logs to analyze problems. There are 12 disks on this machine, and each disk runs different jobs. Our test kernel also adds some additional function-related logs. If we adjust the log level to a higher level, a large number of logs have nothing to do with the disk to be observed. These logs are generated by system agents or coordinated tasks. This makes the log difficul to analyze. > And if the problem is that there's a problem with distinguishing messages > from multiple filesystems, then it would be perhaps more useful to add > journal identification to each message similarly as we do it with ext4 > messages (likely by using journal->j_dev) - which is very simple to do > after your patches 3 and 4. Our test kernel did this. Because it broke the log format, I was not sure whether it would break something, so I didn't bring this part. Even if the device information is added, when there are more disks and the log level is higher, there will be a lot of irrelevant logs, which makes it necessary to consume a lot of CPU to filter messages. Therefore, a device-level switch is provided to make everything simpler. > > Honza >
Re: [PATCH v2 08/17] mfd: Add ROHM BD71815 ID
On Tue, 19 Jan 2021, Matti Vaittinen wrote: > Add chip ID for ROHM BD71815 and PMIC so that drivers can identify > this IC. > > Signed-off-by: Matti Vaittinen > --- > No changes since v1. > > include/linux/mfd/rohm-generic.h | 1 + > 1 file changed, 1 insertion(+) For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
On 1/23/21 6:56 AM, Laurent Pinchart wrote:
> Hi Helen,
>
> Thank you for the patch.
>
> On Fri, Jan 22, 2021 at 03:27:23PM -0300, Helen Koike wrote:
>> YUV 4:4:4 is not subsampled, fix this in the docs.
>>
>> Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV
>> formats to common file")
>> Signed-off-by: Helen Koike
>> ---
>> Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> index 7d4d39201a3f..bcb4ef24c334 100644
>> --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> @@ -396,8 +396,8 @@ number of lines as the luma plane.
>> NV24 and NV42
>> -
>>
>> -Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
>> -horizontal direction. Chroma lines contain half the number of pixels and the
>> +Semi-planar YUV 4:4:4 formats. No sub-sampling.
>
> "The chroma plane is not subsampled." ?
Ack.
>
>> +Chroma lines contain the same number of pixels and the
>> same number of bytes as luma lines, and the chroma plane contains the same
>> number of lines as the luma plane.
>
> That's not quite right, the chroma lines contain twice the number of
> pixels and bytes, as there's one Cb and one Cr value in the chroma line
> for each Y value in the luma line.
>
>
> Maybe the text could be reflowed ?
>
Ack.
I'll submit v2 updating the text.
Thanks,
Helen
Re: [PATCH v2 04/17] mfd: bd718x7: simplify by cleaning unnecessary device data
On Tue, 19 Jan 2021, Matti Vaittinen wrote: > Most ROHM PMIC sub-devices only use the regmap pointer from > parent device. They can obtain this by dev_get_regamap so in > most cases the MFD device does not need to allocate and populate > the driver data. Simplify drivers by removing this. > > The BD70528 still needs the access to watchdog mutex so keep > rohm_regmap_dev in use on BD70528 RTC and WDG drivers for now. > > Signed-off-by: Matti Vaittinen > --- > > No changes since v1 > > drivers/mfd/rohm-bd718x7.c | 43 > include/linux/mfd/rohm-bd718x7.h | 13 -- > 2 files changed, 16 insertions(+), 40 deletions(-) For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] bridge: Use PTR_ERR_OR_ZERO instead if(IS_ERR(...)) + PTR_ERR
On 25/01/2021 04:39, Jiapeng Zhong wrote: > coccicheck suggested using PTR_ERR_OR_ZERO() and looking at the code. > > Fix the following coccicheck warnings: > > ./net/bridge/br_multicast.c:1295:7-13: WARNING: PTR_ERR_OR_ZERO can be > used. > > Reported-by: Abaci > Signed-off-by: Jiapeng Zhong > --- > net/bridge/br_multicast.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 257ac4e..2229d10 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1292,7 +1292,7 @@ static int br_multicast_add_group(struct net_bridge *br, > pg = __br_multicast_add_group(br, port, group, src, filter_mode, > igmpv2_mldv1, false); > /* NULL is considered valid for host joined groups */ > - err = IS_ERR(pg) ? PTR_ERR(pg) : 0; > + err = PTR_ERR_OR_ZERO(pg); > spin_unlock(>multicast_lock); > > return err; > This should be targeted at net-next. Acked-by: Nikolay Aleksandrov
[PATCH 6/7] USB: serial: cp210x: fix RTS handling
Clearing TIOCM_RTS should always deassert RTS and setting the same bit
should enable auto-RTS if hardware flow control is enabled.
This allows user space to throttle input directly at the source also
when hardware-assisted flow control is enabled and makes dtr_rts()
always deassert both lines during close (when HUPCL is set).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 47 +++--
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 4ba3fb096bf1..f00b736f3cd3 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -1166,7 +1166,10 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
- flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ if (port_priv->rts)
+ flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ else
+ flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
port_priv->crtscts = true;
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
@@ -1286,6 +1289,8 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
unsigned int set, unsigned int clear)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ struct cp210x_flow_ctl flow_ctl;
+ u32 ctl_hs, flow_repl;
u16 control = 0;
int ret;
@@ -1313,16 +1318,44 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
}
/*
-* SET_MHS cannot be used to control RTS when auto-RTS is enabled.
-* Note that RTS is still deasserted when disabling the UART on close.
+* Use SET_FLOW to set DTR and enable/disable auto-RTS when hardware
+* flow control is enabled.
*/
- if (port_priv->crtscts)
- control &= ~CONTROL_WRITE_RTS;
+ if (port_priv->crtscts && control & CONTROL_WRITE_RTS) {
+ ret = cp210x_read_reg_block(port, CP210X_GET_FLOW, _ctl,
+ sizeof(flow_ctl));
+ if (ret)
+ goto out_unlock;
- dev_dbg(>dev, "%s - control = 0x%04x\n", __func__, control);
+ ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
+ flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
- ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+ ctl_hs &= ~CP210X_SERIAL_DTR_MASK;
+ if (port_priv->dtr)
+ ctl_hs |= CP210X_SERIAL_DTR_ACTIVE;
+ else
+ ctl_hs |= CP210X_SERIAL_DTR_INACTIVE;
+ flow_repl &= ~CP210X_SERIAL_RTS_MASK;
+ if (port_priv->rts)
+ flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ else
+ flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
+
+ flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs);
+ flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
+
+ dev_dbg(>dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n",
+ __func__, ctl_hs, flow_repl);
+
+ ret = cp210x_write_reg_block(port, CP210X_SET_FLOW, _ctl,
+ sizeof(flow_ctl));
+ } else {
+ dev_dbg(>dev, "%s - control = 0x%04x\n", __func__,
control);
+
+ ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+ }
+out_unlock:
mutex_unlock(_priv->mutex);
return ret;
--
2.26.2
[PATCH 4/7] USB: serial: cp210x: clean up flow-control debug message
Shorten the flow-control debug message by abbreviating the field names and reducing the value width to two characters. The latter improves readability since all but the least significant byte will almost always be zero anyway. Signed-off-by: Johan Hovold --- drivers/usb/serial/cp210x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index aa874641374a..36ae44818c13 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -1191,8 +1191,8 @@ static void cp210x_set_flow_control(struct tty_struct *tty, flow_ctl.ulXonLimit = cpu_to_le32(128); flow_ctl.ulXoffLimit = cpu_to_le32(128); - dev_dbg(>dev, "%s - ulControlHandshake=0x%08x, ulFlowReplace=0x%08x\n", - __func__, ctl_hs, flow_repl); + dev_dbg(>dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__, + ctl_hs, flow_repl); flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs); flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl); -- 2.26.2
Re: 回复: 回复: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()
>
>
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月25日 5:57
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki (Sony); LKML; RCU; Paul E . McKenney; Michael Ellerman;
> Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj Upadhyay; Joel
> Fernandes; Peter Zijlstra; Michal Hocko; Thomas Gleixner; Theodore Y . Ts'o;
> Sebastian Andrzej Siewior; Oleksiy Avramchenko
> 主题: Re: 回复: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()
>
> >Hello, Zhang.
>
> > >
> > >发件人: Uladzislau Rezki (Sony)
> > >发送时间: 2021年1月21日 0:21
> > >收件人: LKML; RCU; Paul E . McKenney; Michael Ellerman
> > >抄送: Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj >Upadhyay;
> > >Joel Fernandes; Peter Zijlstra; Michal Hocko; Thomas >Gleixner; Theodore Y
> > >. Ts'o; Sebastian Andrzej Siewior; Uladzislau >Rezki; Oleksiy Avramchenko
> > >主题: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()
> > >
> > >Since the page is obtained in a fully preemptible context, dropping
> > >the lock can lead to migration onto another CPU. As a result a prev.
> > >bnode of that CPU may be underutilised, because a decision has been
> > >made for a CPU that was run out of free slots to store a pointer.
> > >
> > >migrate_disable/enable() are now independent of RT, use it in order
> > >to prevent any migration during a page request for a specific CPU it
> > >is requested for.
> >
> >
> > Hello Rezki
> >
> > The critical migrate_disable/enable() area is not allowed to block, under
> > RT and non RT.
> > There is such a description in preempt.h
> >
> >
> > * Notes on the implementation.
> > *
> > * The implementation is particularly tricky since existing code patterns
> > * dictate neither migrate_disable() nor migrate_enable() is allowed to
> > block.
> > * This means that it cannot use cpus_read_lock() to serialize against
> > hotplug,
> > * nor can it easily migrate itself into a pending affinity mask change on
> > * migrate_enable().
> >
> >How i interpret it is migrate_enable()/migrate_disable() are not allowed to
> >use any blocking primitives, such as rwsem/mutexes/etc. in order to mark a
> >current context as non-migratable.
> >
> >void migrate_disable(void)
> >{
> > struct task_struct *p = current;
> >
> > if (p->migration_disabled) {
> > p->migration_disabled++;
> > return;
> > }
>
> > preempt_disable();
> > this_rq()->nr_pinned++;
> > p->migration_disabled = 1;
> > preempt_enable();
> >}
> >
> >It does nothing that prevents you from doing schedule() or even wait for any
> >event(mutex slow path behaviour), when the process is removed from the
> >run-queue.
> >I mean after the migrate_disable() is invoked. Or i miss something?
>
> Hello Rezki
>
> Sorry, there's something wrong with the previous description.
> There are the following scenarios
>
> Due to migrate_disable will increase this_rq()->nr_pinned , after that
> if get_free_page be blocked, and this time, CPU going offline,
> the sched_cpu_wait_empty() be called in per-cpu "cpuhp/%d" task,
> and be blocked.
>
But after the migrate_disable() is invoked a CPU can not be brought down.
If there are pinned tasks a "hotplug path" will be blocked on
balance_hotplug_wait()
call.
> blocked:
> sched_cpu_wait_empty()
> {
> struct rq *rq = this_rq();
>rcuwait_wait_event(>hotplug_wait,
>rq->nr_running == 1 && !rq_has_pinned_tasks(rq),
>TASK_UNINTERRUPTIBLE);
> }
>
Exactly.
> wakeup:
> balance_push()
> {
> if (is_per_cpu_kthread(push_task) ||
> is_migration_disabled(push_task)) {
>
> if (!rq->nr_running && !rq_has_pinned_tasks(rq) &&
> rcuwait_active(>hotplug_wait)) {
> raw_spin_unlock(>lock);
> rcuwait_wake_up(>hotplug_wait);
> raw_spin_lock(>lock);
> }
> return;
> }
> }
>
> One of the conditions for this function to wake up is "rq->nr_pinned == 0"
> that is to say between migrate_disable/enable, if blocked will defect CPU
> going
> offline longer blocking time.
>
Indeed, the hotplug time is affected. For example in case of waiting for
a mutex to be released, an owner will wakeup waiters. But this is expectable.
>
> I'm not sure that's a problem，and I didn't find it in the kernel code
> between
> migrate_disable/enable possible sleep calls.
>
For example z3fold.c:
/* Add to the appropriate unbuddied list */
static inline void add_to_unbuddied(struct z3fold_pool *pool,
struct z3fold_header *zhdr)
{
if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0 ||
zhdr->middle_chunks == 0) {
struct list_head *unbuddied;
int freechunks = num_free_chunks(zhdr);
migrate_disable();
unbuddied = this_cpu_ptr(pool->unbuddied);
[PATCH 1/7] USB: serial: cp210x: suppress modem-control errors
The CP210X_SET_MHS request cannot be used to control RTS when hardware
flow control (auto-RTS) is enabled and instead returns an error which is
currently logged as:
cp210x ttyUSB0: failed set request 0x7 status: -32
when opening and closing a port (and on TIOCMSET requests).
Add a crtscts flag to keep track of the hardware flow-control setting
and use it to suppress any request to change RTS when auto-RTS is
enabled.
Note that RTS is still deasserted when disabling the UART as part of
close.
Reported-by: Pho Tran
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index d813a052738f..7e4a09b42c99 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define DRIVER_DESC "Silicon Labs CP210x RS232 serial adaptor driver"
@@ -264,7 +265,10 @@ struct cp210x_port_private {
u8 bInterfaceNumber;
boolevent_mode;
enum cp210x_event_state event_state;
- u8 lsr;
+ u8 lsr;
+
+ struct mutexmutex;
+ boolcrtscts;
};
static struct usb_serial_driver cp210x_device = {
@@ -1117,6 +1121,7 @@ static bool cp210x_termios_change(const struct ktermios
*a, const struct ktermio
static void cp210x_set_flow_control(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
struct cp210x_special_chars chars;
struct cp210x_flow_ctl flow_ctl;
u32 flow_repl;
@@ -1143,10 +1148,12 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
return;
}
+ mutex_lock(_priv->mutex);
+
ret = cp210x_read_reg_block(port, CP210X_GET_FLOW, _ctl,
sizeof(flow_ctl));
if (ret)
- return;
+ goto out_unlock;
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
@@ -1161,10 +1168,12 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_FLOW_CTL);
+ port_priv->crtscts = true;
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
flow_repl |= CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_ACTIVE);
+ port_priv->crtscts = false;
}
if (I_IXOFF(tty))
@@ -1188,6 +1197,8 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
cp210x_write_reg_block(port, CP210X_SET_FLOW, _ctl,
sizeof(flow_ctl));
+out_unlock:
+ mutex_unlock(_priv->mutex);
}
static void cp210x_set_termios(struct tty_struct *tty,
@@ -1272,7 +1283,9 @@ static int cp210x_tiocmset(struct tty_struct *tty,
static int cp210x_tiocmset_port(struct usb_serial_port *port,
unsigned int set, unsigned int clear)
{
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
u16 control = 0;
+ int ret;
if (set & TIOCM_RTS) {
control |= CONTROL_RTS;
@@ -1291,9 +1304,22 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
control |= CONTROL_WRITE_DTR;
}
+ mutex_lock(_priv->mutex);
+
+ /*
+* SET_MHS cannot be used to control RTS when auto-RTS is enabled.
+* Note that RTS is still deasserted when disabling the UART on close.
+*/
+ if (port_priv->crtscts)
+ control &= ~CONTROL_WRITE_RTS;
+
dev_dbg(>dev, "%s - control = 0x%.4x\n", __func__, control);
- return cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+ ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+
+ mutex_unlock(_priv->mutex);
+
+ return ret;
}
static void cp210x_dtr_rts(struct usb_serial_port *port, int on)
@@ -1770,6 +1796,7 @@ static int cp210x_port_probe(struct usb_serial_port *port)
return -ENOMEM;
port_priv->bInterfaceNumber = cp210x_interface_num(serial);
+ mutex_init(_priv->mutex);
usb_set_serial_port_data(port, port_priv);
--
2.26.2
[PATCH 2/7] USB: serial: cp210x: fix modem-control handling
The vendor request used to set the flow-control settings also sets the
state of the modem-control lines.
Add state variables to keep track of the modem-control lines to avoid
always asserting the lines whenever the flow-control settings are
updated.
This specifically also avoids asserting DTR/RTS when opening a port with
the line speed set to B0.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 7e4a09b42c99..9378b4bba34b 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -269,6 +269,8 @@ struct cp210x_port_private {
struct mutexmutex;
boolcrtscts;
+ booldtr;
+ boolrts;
};
static struct usb_serial_driver cp210x_device = {
@@ -1162,7 +1164,10 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
ctl_hs &= ~CP210X_SERIAL_DCD_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DSR_SENSITIVITY;
ctl_hs &= ~CP210X_SERIAL_DTR_MASK;
- ctl_hs |= CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_ACTIVE);
+ if (port_priv->dtr)
+ ctl_hs |= CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_ACTIVE);
+ else
+ ctl_hs |= CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_INACTIVE);
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
@@ -1172,7 +1177,10 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
- flow_repl |= CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_ACTIVE);
+ if (port_priv->rts)
+ flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_ACTIVE);
+ else
+ flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_INACTIVE);
port_priv->crtscts = false;
}
@@ -1287,25 +1295,29 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
u16 control = 0;
int ret;
+ mutex_lock(_priv->mutex);
+
if (set & TIOCM_RTS) {
+ port_priv->rts = true;
control |= CONTROL_RTS;
control |= CONTROL_WRITE_RTS;
}
if (set & TIOCM_DTR) {
+ port_priv->dtr = true;
control |= CONTROL_DTR;
control |= CONTROL_WRITE_DTR;
}
if (clear & TIOCM_RTS) {
+ port_priv->rts = false;
control &= ~CONTROL_RTS;
control |= CONTROL_WRITE_RTS;
}
if (clear & TIOCM_DTR) {
+ port_priv->dtr = false;
control &= ~CONTROL_DTR;
control |= CONTROL_WRITE_DTR;
}
- mutex_lock(_priv->mutex);
-
/*
* SET_MHS cannot be used to control RTS when auto-RTS is enabled.
* Note that RTS is still deasserted when disabling the UART on close.
--
2.26.2
[PATCH 5/7] USB: serial: cp210x: clean up printk zero padding
Use the 0-flag and a field width to specify zero-padding consistently in printk messages. Signed-off-by: Johan Hovold --- drivers/usb/serial/cp210x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index 36ae44818c13..4ba3fb096bf1 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -1319,7 +1319,7 @@ static int cp210x_tiocmset_port(struct usb_serial_port *port, if (port_priv->crtscts) control &= ~CONTROL_WRITE_RTS; - dev_dbg(>dev, "%s - control = 0x%.4x\n", __func__, control); + dev_dbg(>dev, "%s - control = 0x%04x\n", __func__, control); ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control); @@ -1353,7 +1353,7 @@ static int cp210x_tiocmget(struct tty_struct *tty) |((control & CONTROL_RING)? TIOCM_RI : 0) |((control & CONTROL_DCD) ? TIOCM_CD : 0); - dev_dbg(>dev, "%s - control = 0x%.2x\n", __func__, control); + dev_dbg(>dev, "%s - control = 0x%02x\n", __func__, control); return result; } -- 2.26.2
[PATCH 7/7] USB: serial: cp210x: clean up auto-RTS handling
Clear the RTS bits of the flow-control request before determining the
new value when updating the settings.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index f00b736f3cd3..cc4f63a06f9e 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -1163,9 +1163,9 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
else
ctl_hs |= CP210X_SERIAL_DTR_INACTIVE;
+ flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
- flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (port_priv->rts)
flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
else
@@ -1173,7 +1173,6 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
port_priv->crtscts = true;
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
- flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (port_priv->rts)
flow_repl |= CP210X_SERIAL_RTS_ACTIVE;
else
--
2.26.2
Re: [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability
On Mon, Jan 25, 2021 at 2:25 PM Miklos Szeredi wrote:
>
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
> >
> > On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > > filesystems (overlayfs and ecryptfs) into account.
> > >
> > > That patch fixed the overlay case, but made the ecryptfs case worse.
> >
> > Thanks for sending a fix!
> >
> > I know that you don't have an eCryptfs setup to test with but I'm at a
> > loss about how to test this from the userns/fscaps side of things. Do
> > you have a sequence of unshare/setcap/getcap commands that I can run on
> > a file inside of an eCryptfs mount to verify that the bug exists after
> > 7c03e2cda4a5 and then again to verify that this patch fixes the bug?
>
> You need two terminals:
> $ =
> # = root
>
> $ unshare -Um
> $ echo $$
>
> # echo "0 1000 1" > uid_map
NOTE: is assumed to have uid=1000, so this and following
"1000" values need to be fixed up if it's not the case.
Thanks,
Miklos
[PATCH] drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()
Smatch found an uninitialized variable bug in this code:
drivers/gpu/drm/i915/gvt/cmd_parser.c:3191 intel_gvt_update_reg_whitelist()
error: uninitialized symbol 'ret'.
The first thing that Smatch complains about is that "ret" isn't set if
we don't enter the "for_each_engine(engine, _priv->gt, id) {" loop.
Presumably we always have at least one engine so that's a false
positive.
But it's definitely a bug to not set "ret" if i915_gem_object_pin_map()
fails.
Let's fix the bug and silence the false positive.
Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd accessible
reg whitelist")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 7fb91de06557..d54ea0e4681d 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3103,7 +3103,7 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
struct intel_vgpu_submission *s = >submission;
struct i915_request *requests[I915_NUM_ENGINES] = {};
bool is_ctx_pinned[I915_NUM_ENGINES] = {};
- int ret;
+ int ret = 0;
if (gvt->is_reg_whitelist_updated)
return;
@@ -3157,6 +3157,7 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
if (IS_ERR(vaddr)) {
gvt_err("failed to pin init ctx obj, ring=%d,
err=%lx\n",
id, PTR_ERR(vaddr));
+ ret = PTR_ERR(vaddr);
goto out;
}
--
2.29.2
[RFC PATCH v3 13/13] vsock_test: add SOCK_SEQPACKET tests
This adds two tests of SOCK_SEQPACKET socket: both transfer data and then
test MSG_EOR and MSG_TRUNC flags. Cases for connect(), bind(), etc. are
not tested, because it is same as for stream socket.
Signed-off-by: Arseny Krasnov
---
tools/testing/vsock/util.c | 32 ++--
tools/testing/vsock/util.h | 3 +
tools/testing/vsock/vsock_test.c | 126 +++
3 files changed, 156 insertions(+), 5 deletions(-)
diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index 93cbd6f603f9..2acbb7703c6a 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -84,7 +84,7 @@ void vsock_wait_remote_close(int fd)
}
/* Connect to and return the file descriptor. */
-int vsock_stream_connect(unsigned int cid, unsigned int port)
+static int vsock_connect(unsigned int cid, unsigned int port, int type)
{
union {
struct sockaddr sa;
@@ -101,7 +101,7 @@ int vsock_stream_connect(unsigned int cid, unsigned int
port)
control_expectln("LISTENING");
- fd = socket(AF_VSOCK, SOCK_STREAM, 0);
+ fd = socket(AF_VSOCK, type, 0);
timeout_begin(TIMEOUT);
do {
@@ -120,11 +120,21 @@ int vsock_stream_connect(unsigned int cid, unsigned int
port)
return fd;
}
+int vsock_stream_connect(unsigned int cid, unsigned int port)
+{
+ return vsock_connect(cid, port, SOCK_STREAM);
+}
+
+int vsock_seqpacket_connect(unsigned int cid, unsigned int port)
+{
+ return vsock_connect(cid, port, SOCK_SEQPACKET);
+}
+
/* Listen on and return the first incoming connection. The remote
* address is stored to clientaddrp. clientaddrp may be NULL.
*/
-int vsock_stream_accept(unsigned int cid, unsigned int port,
- struct sockaddr_vm *clientaddrp)
+static int vsock_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp, int type)
{
union {
struct sockaddr sa;
@@ -145,7 +155,7 @@ int vsock_stream_accept(unsigned int cid, unsigned int port,
int client_fd;
int old_errno;
- fd = socket(AF_VSOCK, SOCK_STREAM, 0);
+ fd = socket(AF_VSOCK, type, 0);
if (bind(fd, , sizeof(addr.svm)) < 0) {
perror("bind");
@@ -189,6 +199,18 @@ int vsock_stream_accept(unsigned int cid, unsigned int
port,
return client_fd;
}
+int vsock_stream_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp)
+{
+ return vsock_accept(cid, port, clientaddrp, SOCK_STREAM);
+}
+
+int vsock_seqpacket_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp)
+{
+ return vsock_accept(cid, port, clientaddrp, SOCK_SEQPACKET);
+}
+
/* Transmit one byte and check the return value.
*
* expected_ret:
diff --git a/tools/testing/vsock/util.h b/tools/testing/vsock/util.h
index e53dd09d26d9..a3375ad2fb7f 100644
--- a/tools/testing/vsock/util.h
+++ b/tools/testing/vsock/util.h
@@ -36,8 +36,11 @@ struct test_case {
void init_signals(void);
unsigned int parse_cid(const char *str);
int vsock_stream_connect(unsigned int cid, unsigned int port);
+int vsock_seqpacket_connect(unsigned int cid, unsigned int port);
int vsock_stream_accept(unsigned int cid, unsigned int port,
struct sockaddr_vm *clientaddrp);
+int vsock_seqpacket_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp);
void vsock_wait_remote_close(int fd);
void send_byte(int fd, int expected_ret, int flags);
void recv_byte(int fd, int expected_ret, int flags);
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 5a4fb80fa832..db6cc49fa5e4 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include "timeout.h"
#include "control.h"
@@ -279,6 +281,120 @@ static void test_stream_msg_peek_server(const struct
test_opts *opts)
close(fd);
}
+#define MESSAGES_CNT 7
+#define MESSAGE_EOR_IDX (MESSAGES_CNT / 2)
+static void test_seqpacket_msg_send_client(const struct test_opts *opts)
+{
+ int fd;
+
+ fd = vsock_seqpacket_connect(opts->peer_cid, 1234);
+ if (fd < 0) {
+ perror("connect");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Send several messages, one with MSG_EOR flag */
+ for (int i = 0; i < MESSAGES_CNT; i++)
+ send_byte(fd, 1, (i != MESSAGE_EOR_IDX) ? 0 : MSG_EOR);
+
+ control_writeln("SENDDONE");
+ close(fd);
+}
+
+static void test_seqpacket_msg_send_server(const struct test_opts *opts)
+{
+ int fd;
+ char buf[16];
+ struct msghdr msg = {0};
+ struct iovec iov = {0};
+
+ fd = vsock_seqpacket_accept(VMADDR_CID_ANY, 1234, NULL);
+ if (fd < 0) {
+ perror("accept");
+
Re: [PATCH v2] sched/fair: check for idle core
On Mon, 25 Jan 2021, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 10:20, Julia Lawall wrote:
> >
> >
> >
> > On Mon, 25 Jan 2021, Mel Gorman wrote:
> >
> > > On Sun, Jan 24, 2021 at 09:38:14PM +0100, Julia Lawall wrote:
> > > >
> > > >
> > > > On Tue, 27 Oct 2020, Mel Gorman wrote:
> > > >
> > > > > On Thu, Oct 22, 2020 at 03:15:50PM +0200, Julia Lawall wrote:
> > > > > > Fixes: 11f10e5420f6 ("sched/fair: Use load instead of runnable load
> > > > > > in wakeup path")
> > > > > > Signed-off-by: Julia Lawall
> > > > > > Reviewed-by Vincent Guittot
> > > > > >
> > > > >
> > > > > While not a universal win, it was mostly a win or neutral. In few
> > > > > cases
> > > > > where there was a problem, one benchmark I'm a bit suspicious of
> > > > > generally
> > > > > as occasionally it generates bad results for unknown and unpredictable
> > > > > reasons. In another, it was very machine specific and the differences
> > > > > were small in absolte time rather than relative time. Other tests on
> > > > > the
> > > > > same machine were fine so overall;
> > > > >
> > > > > Acked-by: Mel Gorman
> > > >
> > > > Recently, we have been testing the phoronix multicore benchmarks. On
> > > > v5.9
> > > > with this patch, the preparation time of phoronix slows down, from ~23
> > > > seconds to ~28 seconds. In v5.11-rc4, we see 29 seconds. It's not yet
> > > > clear what causes the problem. But perhaps the patch should be removed
> > > > from v5.11, until the problem is understood.
> > > >
> > > > commit d8fcb81f1acf651a0e50eacecca43d0524984f87
> > > >
> > >
> > > I'm not 100% convinved given that it was a mix of wins and losses. In
> > > the wakup path in general, universal wins almost never happen. It's not
> > > 100% clear from your mail what happens during the preparation patch. If
> > > it included time to download the benchmarks and install then it would be
> > > inherently variable due to network time (if download) or cache hotness
> > > (if installing/compiling). While preparation time can be interesting --
> > > for example, if preparation involves reading a lot of files from disk,
> > > it's not universally interesting when it's not the critical phase of a
> > > benchmark.
> >
> > The benchmark is completely downloaded prior to the runs. There seems to
> > be some perturbation to the activation of containerd. Normally it is
> > even: * * * *
>
> Does it impact the benchmark results too or only the preparation prior
> to running the benchmark ?
Looking at a few of the benchmarks, there is no clear pattern which is
better. But there is not a big degradation, like from 23 to 28 seconds
for the preparation time. I will report back when we figure out more.
julia
>
> >
> > and with the patch it becomes more like: * ** **
> >
> > That is every other one is on time, and every other one is late.
> >
> > But I don't know why this happens.
> >
> > julia
> >
> > >
> > > I think it would be better to wait until the problem is fully understood
> > > to see if it's a timing artifact (e.g. a race between when prev_cpu is
> > > observed to be idle and when it is busy).
>
> I agree that a better understanding of what is happening is necessary
> before any changes
>
> > >
> > > --
> > > Mel Gorman
> > > SUSE Labs
> > >
>
Re: [PATCH 2/5] mm,memory_hotplug: Allocate memmap from the added memory range
On 25.01.21 12:18, Oscar Salvador wrote: > On Mon, Jan 25, 2021 at 11:57:20AM +0100, David Hildenbrand wrote: >> I'm confused. >> >> 1. Assume we hotplug memory, online it to ZONE_MOVABLE. The vmemmap gets >> allocated from altmap space. > > The vmemmap could have never been allocated from altmap in case hpage vmemmap > feature is enabled. > > Have a look at [1]. > If is_hugetlb_free_vmemmap_enabled(), vmemmap_populate() ends up calling > vmemmap_populate_basepages(). Oh, it calls "vmemmap_populate_basepages(start, end, node, NULL);" the "NULL" part is the important bit. > > And since no memory was consumed from altmap, and hence > altmap_alloc_block_buf() > was never called, vmem_altmap->alloc will be 0, and > memory_block->nr_vmemmap_pages > will be 0 as well. > > But on a second though, true is that we will get in trouble if hpage vmemmap > feature ever gets to work with vmemmap_populate_hugepages. > I will queue that to look in a new future. This seriously needs comments and documentation. The problem is where to document as long as one of both series is not merged yet :) At least in the cover letter, because this is not obvious how both things will play along. Thanks! -- Thanks, David / dhildenb
[PATCH] optee: simplify i2c access
From: Arnd Bergmann
Storing a bogus i2c_client structure on the stack adds overhead and
causes a compile-time warning:
drivers/tee/optee/rpc.c:493:6: error: stack frame size of 1056 bytes in
function 'optee_handle_rpc' [-Werror,-Wframe-larger-than=]
void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param,
Change the implementation of handle_rpc_func_cmd_i2c_transfer() to
open-code the i2c_transfer() call, which makes it easier to read
and avoids the warning.
Fixes: c05210ab9757 ("drivers: optee: allow op-tee to access devices on the i2c
bus")
Signed-off-by: Arnd Bergmann
---
drivers/tee/optee/rpc.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index 1e3614e4798f..6cbb3643c6c4 100644
--- a/drivers/tee/optee/rpc.c
+++ b/drivers/tee/optee/rpc.c
@@ -54,8 +54,9 @@ static void handle_rpc_func_cmd_get_time(struct optee_msg_arg
*arg)
static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
struct optee_msg_arg *arg)
{
- struct i2c_client client = { 0 };
struct tee_param *params;
+ struct i2c_adapter *adapter;
+ struct i2c_msg msg = { };
size_t i;
int ret = -EOPNOTSUPP;
u8 attr[] = {
@@ -85,48 +86,48 @@ static void handle_rpc_func_cmd_i2c_transfer(struct
tee_context *ctx,
goto bad;
}
- client.adapter = i2c_get_adapter(params[0].u.value.b);
- if (!client.adapter)
+ adapter = i2c_get_adapter(params[0].u.value.b);
+ if (!adapter)
goto bad;
if (params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT) {
- if (!i2c_check_functionality(client.adapter,
+ if (!i2c_check_functionality(adapter,
I2C_FUNC_10BIT_ADDR)) {
- i2c_put_adapter(client.adapter);
+ i2c_put_adapter(adapter);
goto bad;
}
- client.flags = I2C_CLIENT_TEN;
+ msg.flags = I2C_M_TEN;
}
- client.addr = params[0].u.value.c;
- snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr);
+ msg.addr = params[0].u.value.c;
+ msg.buf = params[2].u.memref.shm->kaddr;
+ msg.len = params[2].u.memref.size;
switch (params[0].u.value.a) {
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
- ret = i2c_master_recv(, params[2].u.memref.shm->kaddr,
- params[2].u.memref.size);
+ msg.flags |= I2C_M_RD;
break;
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
- ret = i2c_master_send(, params[2].u.memref.shm->kaddr,
- params[2].u.memref.size);
break;
default:
- i2c_put_adapter(client.adapter);
+ i2c_put_adapter(adapter);
goto bad;
}
+ ret = i2c_transfer(adapter, , 1);
+
if (ret < 0) {
arg->ret = TEEC_ERROR_COMMUNICATION;
} else {
- params[3].u.value.a = ret;
+ params[3].u.value.a = msg.len;
if (optee_to_msg_param(arg->params, arg->num_params, params))
arg->ret = TEEC_ERROR_BAD_PARAMETERS;
else
arg->ret = TEEC_SUCCESS;
}
- i2c_put_adapter(client.adapter);
+ i2c_put_adapter(adapter);
kfree(params);
return;
bad:
--
2.29.2
Re: [RFC PATCH v3 03/13] af_vsock: implement SEQPACKET rx loop
25.01.2021 14:12, Arseny Krasnov пишет: This adds receive loop for SEQPACKET. It looks like receive loop for SEQPACKET, ^^^ You meant "STREAM"?
Re: [RFC PATCH] kvm: arm64: Try stage2 block mapping for host device MMIO
I forget to give the link of the bugfix I mentioned below :-).
[1] https://lkml.org/lkml/2020/5/1/1294
On 2021/1/25 19:25, Keqian Zhu wrote:
> Hi Marc,
>
> On 2021/1/22 17:45, Marc Zyngier wrote:
>> On 2021-01-22 08:36, Keqian Zhu wrote:
>>> The MMIO region of a device maybe huge (GB level), try to use block
>>> mapping in stage2 to speedup both map and unmap.
>>>
>>> Especially for unmap, it performs TLBI right after each invalidation
>>> of PTE. If all mapping is of PAGE_SIZE, it takes much time to handle
>>> GB level range.
>>
>> This is only on VM teardown, right? Or do you unmap the device more ofet?
>> Can you please quantify the speedup and the conditions this occurs in?
>
> Yes, and there are some other paths (includes what your patch series handles)
> will do the unmap action:
>
> 1、guest reboot without S2FWB: stage2_unmap_vm（）which only unmaps guest
> regular RAM.
> 2、userspace deletes memslot: kvm_arch_flush_shadow_memslot().
> 3、rollback of device MMIO mapping: kvm_arch_prepare_memory_region().
> 4、rollback of dirty log tracking: If we enable hugepage for guest RAM, after
> dirty log is stopped,
>the newly created block mappings will
> unmap all page mappings.
> 5、mmu notifier: kvm_unmap_hva_range(). AFAICS, we will use this path when VM
> teardown or guest resets pass-through devices.
> The bugfix[1] gives the reason for
> unmapping MMIO region when guest resets pass-through devices.
>
> unmap related to MMIO region, as this patch solves:
> point 1 is not applied.
> point 2 occurs when userspace unplug pass-through devices.
> point 3 can occurs, but rarely.
> point 4 is not applied.
> point 5 occurs when VM teardown or guest resets pass-through devices.
>
> And I had a look at your patch series, it can solve:
> For VM teardown, elide CMO and perform VMALL instead of individually (But
> current kernel do not go through this path when VM teardown).
> For rollback of dirty log tracking, elide CMO.
> For kvm_unmap_hva_range, if event is MMU_NOTIFY_UNMAP. elide CMO.
>
> (But I doubt the CMOs in unmap. As we perform CMOs in user_mem_abort when
> install new stage2 mapping for VM,
> maybe the CMO in unmap is unnecessary under all conditions :-) ?)
>
> So it shows that we are solving different parts of unmap, so they are not
> conflicting. At least this patch can
> still speedup map of device MMIO region, and speedup unmap of device MMIO
> region even if we do not need to perform
> CMO and TLBI ;-).
>
> speedup: unmap 8GB MMIO on FPGA.
>
>beforeafter opt
> cost30+ minutes949ms
>
> Thanks,
> Keqian
>
>>
>> I have the feeling that we are just circling around another problem,
>> which is that we could rely on a VM-wide TLBI when tearing down the
>> guest. I worked on something like that[1] a long while ago, and parked
>> it for some reason. Maybe it is worth reviving.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/elide-cmo-tlbi
>>
>>>
>>> Signed-off-by: Keqian Zhu
>>> ---
>>> arch/arm64/include/asm/kvm_pgtable.h | 11 +++
>>> arch/arm64/kvm/hyp/pgtable.c | 15 +++
>>> arch/arm64/kvm/mmu.c | 12
>>> 3 files changed, 34 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_pgtable.h
>>> b/arch/arm64/include/asm/kvm_pgtable.h
>>> index 52ab38db04c7..2266ac45f10c 100644
>>> --- a/arch/arm64/include/asm/kvm_pgtable.h
>>> +++ b/arch/arm64/include/asm/kvm_pgtable.h
>>> @@ -82,6 +82,17 @@ struct kvm_pgtable_walker {
>>> const enum kvm_pgtable_walk_flagsflags;
>>> };
>>>
>>> +/**
>>> + * kvm_supported_pgsize() - Get the max supported page size of a mapping.
>>> + * @pgt:Initialised page-table structure.
>>> + * @addr:Virtual address at which to place the mapping.
>>> + * @end:End virtual address of the mapping.
>>> + * @phys:Physical address of the memory to map.
>>> + *
>>> + * The smallest return value is PAGE_SIZE.
>>> + */
>>> +u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64
>>> phys);
>>> +
>>> /**
>>> * kvm_pgtable_hyp_init() - Initialise a hypervisor stage-1 page-table.
>>> * @pgt:Uninitialised page-table structure to initialise.
>>> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
>>> index bdf8e55ed308..ab11609b9b13 100644
>>> --- a/arch/arm64/kvm/hyp/pgtable.c
>>> +++ b/arch/arm64/kvm/hyp/pgtable.c
>>> @@ -81,6 +81,21 @@ static bool kvm_block_mapping_supported(u64 addr,
>>> u64 end, u64 phys, u32 level)
>>> return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
>>> }
>>>
>>> +u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64
>>> phys)
>>> +{
>>> +u32 lvl;
>>> +u64 pgsize = PAGE_SIZE;
>>> +
>>> +for (lvl = pgt->start_level; lvl < KVM_PGTABLE_MAX_LEVELS; lvl++) {
>>> +if
Re: [PATCH] x86/kgdb: Allow removal of early BPs
Hi,
I wanted to ask about the status of the patch. Let us know if there are any
other steps we can undertake.
Kind regards
Lorena
On Fri 2020-12-18 16:44:21, Daniel Thompson wrote:
> Hi Stefan
>
> On Mon, Dec 14, 2020 at 03:13:12PM +0100, Stefan Saecherl wrote:
> > The problem is that breakpoints that are set early (e.g. via kgdbwait)
> > cannot be deleted after boot completed (to be precise after mark_rodata_ro
> > ran).
> >
> > When setting a breakpoint early there are executable pages that are
> > writable so the copy_to_kernel_nofault call in kgdb_arch_set_breakpoint
> > succeeds and the breakpoint is saved as type BP_BREAKPOINT.
> >
> > Later in the boot write access to these pages is restricted. So when
> > removing the breakpoint the copy_to_kernel_nofault call in
> > kgdb_arch_remove_breakpoint is destined to fail and the breakpoint removal
> > fails. So after copy_to_kernel_nofault failed try to text_poke_kgdb which
> > can work around nonwriteability.
> >
> > One thing to consider when doing this is that code can go away during boot
> > (e.g. .init.text). Previously kgdb_arch_remove_breakpoint handled this case
> > gracefully by just having copy_to_kernel_nofault fail but if one then calls
> > text_poke_kgdb the system dies due to the BUG_ON we moved out of
> > __text_poke. To avoid this __text_poke now returns an error in case of a
> > nonpresent code page and the error is handled at call site.
> >
> > Checkpatch complains about two uses of BUG_ON but the new code should not
> > trigger BUG_ON in cases where the old didn't.
> >
> > Co-developed-by: Lorena Kretzschmar
> > Signed-off-by: Lorena Kretzschmar
> > Signed-off-by: Stefan Saecherl
>
> I took this to be a gap in the kgdbtest suite so I added a couple of
> tests that cover this area. Before this patch they failed now they
> pass (at least they do for ARCH=x86).
>
> I don't see any new failures either, so:
>
> Tested-by: Daniel Thompson
>
>
> Daniel.
>
>
>
> > ---
> > arch/x86/kernel/alternative.c | 16 +++
> > arch/x86/kernel/kgdb.c| 54 ---
> > 2 files changed, 48 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> > index 2400ad62f330..0f145d837885 100644
> > --- a/arch/x86/kernel/alternative.c
> > +++ b/arch/x86/kernel/alternative.c
> > @@ -878,11 +878,9 @@ static void *__text_poke(void *addr, const void
> > *opcode, size_t len)
> > if (cross_page_boundary)
> > pages[1] = virt_to_page(addr + PAGE_SIZE);
> > }
> > - /*
> > -* If something went wrong, crash and burn since recovery paths are not
> > -* implemented.
> > -*/
> > - BUG_ON(!pages[0] || (cross_page_boundary && !pages[1]));
> > +
> > + if (!pages[0] || (cross_page_boundary && !pages[1]))
> > + return ERR_PTR(-EFAULT);
> >
> > /*
> > * Map the page without the global bit, as TLB flushing is done with
> > @@ -976,7 +974,13 @@ void *text_poke(void *addr, const void *opcode, size_t
> > len)
> > {
> > lockdep_assert_held(_mutex);
> >
> > - return __text_poke(addr, opcode, len);
> > + addr = __text_poke(addr, opcode, len);
> > + /*
> > +* If something went wrong, crash and burn since recovery paths are not
> > +* implemented.
> > +*/
> > + BUG_ON(IS_ERR(addr));
> > + return addr;
> > }
> >
> > /**
> > diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
> > index ff7878df96b4..e98c9c43db7c 100644
> > --- a/arch/x86/kernel/kgdb.c
> > +++ b/arch/x86/kernel/kgdb.c
> > @@ -731,6 +731,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned
> > long ip)
> > int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > {
> > int err;
> > + void *addr;
> >
> > bpt->type = BP_BREAKPOINT;
> > err = copy_from_kernel_nofault(bpt->saved_instr, (char *)bpt->bpt_addr,
> > @@ -747,8 +748,14 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > */
> > if (mutex_is_locked(_mutex))
> > return -EBUSY;
> > - text_poke_kgdb((void *)bpt->bpt_addr, arch_kgdb_ops.gdb_bpt_instr,
> > - BREAK_INSTR_SIZE);
> > +
> > + addr = text_poke_kgdb((void *)bpt->bpt_addr,
> > arch_kgdb_ops.gdb_bpt_instr,
> > + BREAK_INSTR_SIZE);
> > + /* This should never trigger because the above call to
> > copy_from_kernel_nofault
> > +* already succeeded.
> > +*/
> > + BUG_ON(IS_ERR(addr));
> > +
> > bpt->type = BP_POKE_BREAKPOINT;
> >
> > return 0;
> > @@ -756,21 +763,36 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> >
> > int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> > {
> > - if (bpt->type != BP_POKE_BREAKPOINT)
> > - goto knl_write;
> > - /*
> > -* It is safe to call text_poke_kgdb() because normal kernel execution
> > -* is stopped on all cores, so long as the text_mutex is not locked.
> > -*/
> > - if
Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m
On Mon, 25 Jan 2021 at 14:09, Arnd Bergmann wrote: > > On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote: > > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote: > > > > > > From: Arnd Bergmann > > > > > > When CONFIG_ATH9K is built-in but LED support is in a loadable > > > module, both ath9k drivers fails to link: > > > > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_deinit_leds': > > > gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister' > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_init_leds': > > > gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext' > > > > > > The problem is that the 'imply' keyword does not enforce any dependency > > > but is only a weak hint to Kconfig to enable another symbol from a > > > defconfig file. > > > > > > Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect > > > configuration but still allows building the driver without LED support. > > > > > > The 'select MAC80211_LEDS' is now ensures that the LED support is > > > actually used if it is present, and the added Kconfig dependency > > > on MAC80211_LEDS ensures that it cannot be enabled manually when it > > > has no effect. > > > > But we do not want to have this dependency (selecting MAC80211_LEDS). > > I fixed this problem here: > > https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/ > > Maybe let's take this approach? > > Generally speaking, I don't like to have a device driver specific Kconfig > setting 'select' a subsystem', for two reasons: > > - you suddenly get asked for tons of new LED specific options when > enabling seemingly benign options > > - Mixing 'depends on' and 'select' leads to bugs with circular > dependencies that usually require turning some other 'select' > into 'depends on'. > > The problem with LEDS_CLASS in particular is that there is a mix of drivers > using one vs the other roughly 50:50. Yes, you are right, I also don't like it. However it was like this before my commit so I am not introducing a new issue. The point is that in your choice the MAC80211_LEDS will be selected if LEDS_CLASS is present, which is exactly what I was trying to fix/remove. My WiFi dongle does not have a LED and it causes a periodic (every second) event. However I still have LEDS_CLASS for other LEDS in the system. Best regards, Krzysztof On Mon, 25 Jan 2021 at 14:09, Arnd Bergmann wrote: > > On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote: > > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote: > > > > > > From: Arnd Bergmann > > > > > > When CONFIG_ATH9K is built-in but LED support is in a loadable > > > module, both ath9k drivers fails to link: > > > > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_deinit_leds': > > > gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister' > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_init_leds': > > > gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext' > > > > > > The problem is that the 'imply' keyword does not enforce any dependency > > > but is only a weak hint to Kconfig to enable another symbol from a > > > defconfig file. > > > > > > Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect > > > configuration but still allows building the driver without LED support. > > > > > > The 'select MAC80211_LEDS' is now ensures that the LED support is > > > actually used if it is present, and the added Kconfig dependency > > > on MAC80211_LEDS ensures that it cannot be enabled manually when it > > > has no effect. > > > > But we do not want to have this dependency (selecting MAC80211_LEDS). > > I fixed this problem here: > > https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/ > > Maybe let's take this approach? > > Generally speaking, I don't like to have a device driver specific Kconfig > setting 'select' a subsystem', for two reasons: > > - you suddenly get asked for tons of new LED specific options when > enabling seemingly benign options > > - Mixing 'depends on' and 'select' leads to bugs with circular > dependencies that usually require turning some other 'select' > into 'depends on'. > > The problem with LEDS_CLASS in particular is that there is a mix of drivers > using one vs the other roughly 50:50. > > Arnd
Re: [PATCH bpf-next v3 3/3] xsk: build skb by page
From: Xuan Zhuo
Date: Mon, 25 Jan 2021 11:10:43 +0800
> On Fri, 22 Jan 2021 16:24:17 +, Alexander Lobakin wrote:
> > From: Xuan Zhuo
> > Date: Fri, 22 Jan 2021 23:36:29 +0800
> >
> > > On Fri, 22 Jan 2021 12:08:00 +, Alexander Lobakin
> > > wrote:
> > > > From: Alexander Lobakin
> > > > Date: Fri, 22 Jan 2021 11:55:35 +
> > > >
> > > > > From: Alexander Lobakin
> > > > > Date: Fri, 22 Jan 2021 11:47:45 +
> > > > >
> > > > > > From: Eric Dumazet
> > > > > > Date: Thu, 21 Jan 2021 16:41:33 +0100
> > > > > >
> > > > > > > On 1/21/21 2:47 PM, Xuan Zhuo wrote:
> > > > > > > > This patch is used to construct skb based on page to save
> > > > > > > > memory copy
> > > > > > > > overhead.
> > > > > > > >
> > > > > > > > This function is implemented based on IFF_TX_SKB_NO_LINEAR.
> > > > > > > > Only the
> > > > > > > > network card priv_flags supports IFF_TX_SKB_NO_LINEAR will use
> > > > > > > > page to
> > > > > > > > directly construct skb. If this feature is not supported, it is
> > > > > > > > still
> > > > > > > > necessary to copy data to construct skb.
> > > > > > > >
> > > > > > > > Performance Testing
> > > > > > > >
> > > > > > > > The test environment is Aliyun ECS server.
> > > > > > > > Test cmd:
> > > > > > > > ```
> > > > > > > > xdpsock -i eth0 -t -S -s
> > > > > > > > ```
> > > > > > > >
> > > > > > > > Test result data:
> > > > > > > >
> > > > > > > > size64 512 10241500
> > > > > > > > copy1916747 1775988 1600203 1440054
> > > > > > > > page1974058 1953655 1945463 1904478
> > > > > > > > percent 3.0%10.0% 21.58% 32.3%
> > > > > > > >
> > > > > > > > Signed-off-by: Xuan Zhuo
> > > > > > > > Reviewed-by: Dust Li
> > > > > > > > ---
> > > > > > > > net/xdp/xsk.c | 104
> > > > > > > > --
> > > > > > > > 1 file changed, 86 insertions(+), 18 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > > > > > index 4a83117..38af7f1 100644
> > > > > > > > --- a/net/xdp/xsk.c
> > > > > > > > +++ b/net/xdp/xsk.c
> > > > > > > > @@ -430,6 +430,87 @@ static void xsk_destruct_skb(struct
> > > > > > > > sk_buff *skb)
> > > > > > > > sock_wfree(skb);
> > > > > > > > }
> > > > > > > >
> > > > > > > > +static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock
> > > > > > > > *xs,
> > > > > > > > + struct xdp_desc
> > > > > > > > *desc)
> > > > > > > > +{
> > > > > > > > + u32 len, offset, copy, copied;
> > > > > > > > + struct sk_buff *skb;
> > > > > > > > + struct page *page;
> > > > > > > > + void *buffer;
> > > > > > > > + int err, i;
> > > > > > > > + u64 addr;
> > > > > > > > +
> > > > > > > > + skb = sock_alloc_send_skb(>sk, 0, 1, );
> > > >
> > > > Also,
> > > > maybe we should allocate it with NET_SKB_PAD so NIC drivers could
> > > > use some reserved space?
> > > >
> > > > skb = sock_alloc_send_skb(>sk, NET_SKB_PAD, 1,
> > > > );
> > > > ...
> > > > skb_reserve(skb, NET_SKB_PAD);
> > > >
> > > > Eric, what do you think?
> > >
> > > I think you are right. Some space should be added to continuous
> > > equipment. This
> > > space should also be added in the copy mode below. Is LL_RESERVED_SPACE
> > > more
> > > appropriate?
> >
> > No. If you look at __netdev_alloc_skb() and __napi_alloc_skb(), they
> > reserve NET_SKB_PAD at the beginning of linear area. Documentation of
> > __build_skb() also says that driver should reserve NET_SKB_PAD before
> > the actual frame, so it is a standartized hardware-independent
> > headroom.
>
> I understand that these scenarios are in the case of receiving packets, and
> the
> increased space is used by the protocol stack, especially RPS. I don't know if
> this also applies to the sending scenario?
>
> > Leaving that space in skb->head will allow developers to implement
> > IFF_TX_SKB_NO_LINEAR in a wider variety of drivers, especially when
> > a driver has to prepend some sort of data before the actual frame.
> > Since it's usually of a size of one cacheline, shouldn't be a big
> > deal.
> >
>
> I agree with this. Some network cards require some space. For example,
> virtio-net needs to add a virtio_net_hdr_mrg_rxbuf before skb->data, so my
> original understanding is used here. When we send the skb to the
> driver, the driver may need a memory space. So I refer to the
> implementation of __ip_append_data, I feel that adding
> LL_RESERVED_SPACE is a suitable solution.
>
> I feel that I may still not understand the use scene you mentioned. Can you
> elaborate on what you understand this space will be used for?
LL_RESERVED_SPACE() consists of L2 header size (Ethernet for the most
cases) and dev->needed_headroom. That is not a value to count on, as:
- L2 header is already here in XSK buffer;
- not all drivers set
Re: [PATCH net-next v2 2/2] net: dsa: mt7530: MT7530 optional GPIO support
On Mon, Jan 25, 2021 at 12:43:22PM +0800, DENG Qingfang wrote: > MT7530's LED controller can drive up to 15 LED/GPIOs. > > Add support for GPIO control and allow users to use its GPIOs by > setting gpio-controller property in device tree. > > Signed-off-by: DENG Qingfang Reviewed-by: Andrew Lunn Andrew
Re: [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability
On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
>
> On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > filesystems (overlayfs and ecryptfs) into account.
> >
> > That patch fixed the overlay case, but made the ecryptfs case worse.
>
> Thanks for sending a fix!
>
> I know that you don't have an eCryptfs setup to test with but I'm at a
> loss about how to test this from the userns/fscaps side of things. Do
> you have a sequence of unshare/setcap/getcap commands that I can run on
> a file inside of an eCryptfs mount to verify that the bug exists after
> 7c03e2cda4a5 and then again to verify that this patch fixes the bug?
You need two terminals:
$ =
# = root
$ unshare -Um
$ echo $$
# echo "0 1000 1" > uid_map
# cp uid_map gid_map
# echo 1000 2000 1 >> uid_map
# echo 2000 3000 1 >> uid_map
# cat uid_map > /proc//uid_map
# cat gid_map > /proc//gid_map
$ mkdir ~/tmp ~/mnt
$ mount -t tmpfs tmpfs ~/tmp
$ pwd
/home/
# nsenter -t -m
# [setup ecryptfs on /home//mnt using /home//tmp]
$ cd ~/mnt
$ touch test
$ /sbin/setcap -n 1000 cap_dac_override+eip test
$ /sbin/getcap -n test
test = cap_dac_override+eip [rootid=1000]
Without the patch, I'm thinking that it will do a double translate and
end up with rootid=2000 in the user namespace, but I might well have
messed it up...
Let me know how this goes.
Thanks,
Miklos
Re: linux-next: build warning after merge of the xfs tree
On Mon, Jan 25, 2021 at 09:55:32AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the xfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/xfs/xfs_log.c: In function 'xfs_log_cover':
> fs/xfs/xfs_log.c::16: warning: unused variable 'log' [-Wunused-variable]
> | struct xlog *log = mp->m_log;
> |^~~
>
> Introduced by commit
>
> 303591a0a947 ("xfs: cover the log during log quiesce")
>
Oops, patch below. Feel free to apply or squash into the original
commit.
Brian
--- 8< ---
>From 6078f06e2bd4c82111a85a2032c39a56654b0be6 Mon Sep 17 00:00:00 2001
From: Brian Foster
Date: Mon, 25 Jan 2021 08:22:56 -0500
Subject: [PATCH] xfs: fix unused log variable in xfs_log_cover()
The log variable is only used in kernels with asserts enabled.
Remove it and open code the dereference to avoid unused variable
warnings.
Signed-off-by: Brian Foster
---
fs/xfs/xfs_log.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index 58699881c100..d8b814227734 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -1108,12 +1108,11 @@ static int
xfs_log_cover(
struct xfs_mount*mp)
{
- struct xlog *log = mp->m_log;
int error = 0;
boolneed_covered;
- ASSERT((xlog_cil_empty(log) && xlog_iclogs_empty(log) &&
- !xfs_ail_min_lsn(log->l_ailp)) ||
+ ASSERT((xlog_cil_empty(mp->m_log) && xlog_iclogs_empty(mp->m_log) &&
+ !xfs_ail_min_lsn(mp->m_log->l_ailp)) ||
XFS_FORCED_SHUTDOWN(mp));
if (!xfs_log_writable(mp))
--
2.26.2
Re: [PATCH] dsa: vsc73xx: add support for vlan filtering
On Mon, Jan 25, 2021 at 12:45 AM Vladimir Oltean wrote: > Anyhow, you did not approve or disprove the tag_8021q idea. I just don't understand it well enough so I didn't know what to say about that... > With VLAN trunking on the CPU port, how would per-port traffic be > managed? Would it be compatible with hardware-accelerated bridging > (which this driver still does not support)? I think in vendor code it is done like it is done on the RTL8366RB: one VLAN per port, so the filtering inside the switch isolate the ports by assigning them one VLAN each and the PTAG of the packets make sure they can only reach the desired port. (+/- my half-assed knowledge of how VLAN actually works, one day I think I understand it, next day I don't understand it anymore) Yours, Linus Walleij
Re: [PATCH] kgdb: use new API for breakpoint tasklet
On Mon, 25 Jan 2021 at 12:03, Daniel Thompson
wrote:
>
> On Sat, Jan 23, 2021 at 07:42:37PM +0100, Emil Renner Berthing wrote:
> > This converts the kgdb_tasklet_breakpoint to use the new API in
> > commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
> >
> > The new API changes the argument passed to the callback function, but
> > fortunately the argument isn't used so it is straight forward to use
> > DECLARE_TASKLET() rather than DECLARE_TASKLET_OLD().
>
> This patch overlaps with a more ambitious patch from Davidlohr.
> Perhaps you can join in with the other thread since the discussion
> there is unresolved. See:
> https://lkml.org/lkml/2021/1/14/1320
Ah, that's cool. Getting rid of tasklets is much better than merely
trying to get rid of the old tasklet API. Please ignore this patch
then.
/Emil
>
> Daniel.
>
>
> >
> > Signed-off-by: Emil Renner Berthing
> > ---
> > kernel/debug/debug_core.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> > index af6e8b4fb359..98d44c2bb0a4 100644
> > --- a/kernel/debug/debug_core.c
> > +++ b/kernel/debug/debug_core.c
> > @@ -1090,13 +1090,13 @@ static void kgdb_unregister_callbacks(void)
> > * such as is the case with kgdboe, where calling a breakpoint in the
> > * I/O driver itself would be fatal.
> > */
> > -static void kgdb_tasklet_bpt(unsigned long ing)
> > +static void kgdb_tasklet_bpt(struct tasklet_struct *unused)
> > {
> > kgdb_breakpoint();
> > atomic_set(_break_tasklet_var, 0);
> > }
> >
> > -static DECLARE_TASKLET_OLD(kgdb_tasklet_breakpoint, kgdb_tasklet_bpt);
> > +static DECLARE_TASKLET(kgdb_tasklet_breakpoint, kgdb_tasklet_bpt);
> >
> > void kgdb_schedule_breakpoint(void)
> > {
> > --
> > 2.30.0
> >
Re: [PATCH] m68k: let clk_enable() return immediately if clk is NULL
Hi Defang,
On 28/12/20 12:07 pm, Defang Bo wrote:
Similar to commit<742859adc721>("m68k: let clk_disable() return immediately if clk
is NULL").
there should be a check for clk to prevent NULL pointer dereference.
Signed-off-by: Defang Bo
I have applied this to the m68knommu git tree, for-next branch -
with blank line added as per Geert's suggestion.
Regards
Greg
---
arch/m68k/coldfire/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 7bc666e..6decd11 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -90,6 +90,9 @@ EXPORT_SYMBOL(clk_get);
int clk_enable(struct clk *clk)
{
unsigned long flags;
+ if (!clk)
+ return -EINVAL;
+
spin_lock_irqsave(_lock, flags);
if ((clk->enabled++ == 0) && clk->clk_ops)
clk->clk_ops->enable(clk);
Re: [PATCH v2 2/4] KVM: SVM: Add emulation support for #GP triggered by SVM instructions
On Thu, 2021-01-21 at 14:40 -0800, Sean Christopherson wrote: > On Thu, Jan 21, 2021, Maxim Levitsky wrote: > > BTW, on unrelated note, currently the smap test is broken in kvm-unit tests. > > I bisected it to commit 322cdd6405250a2a3e48db199f97a45ef519e226 > > > > It seems that the following hack (I have no idea why it works, > > since I haven't dug deep into the area 'fixes', the smap test for me) > > > > -#define USER_BASE (1 << 24) > > +#define USER_BASE (1 << 25) > > https://lkml.kernel.org/r/2021012808.619347-2-imbre...@linux.ibm.com > Thanks! Best regards, Maxim Levitsky
Re: [PATCH] [5.8 regression] net: ks8851: fix link error
On Mon, Jan 25, 2021 at 01:19:20PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> An object file cannot be built for both loadable module and built-in
> use at the same time:
>
> arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in
> function `ks8851_probe_common':
> ks8851_common.c:(.text+0xf80): undefined reference to `__this_module'
>
> Change the ks8851_common code to be a standalone module instead,
> and use Makefile logic to ensure this is built-in if at least one
> of its two users is.
>
> Fixes: 797047f875b5 ("net: ks8851: Implement Parallel bus operations")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Andrew Lunn
Andrew
Re: [PATCH] sched/fair: Rate limit calls to update_blocked_averages() for NOHZ
On Fri, 22 Jan 2021 at 19:39, Qais Yousef wrote: > > On 01/22/21 17:56, Vincent Guittot wrote: > > > --- > > > kernel/sched/fair.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index 04a3ce20da67..fe2dc0024db5 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -8381,7 +8381,7 @@ static bool update_nohz_stats(struct rq *rq, bool > > > force) > > > if (!cpumask_test_cpu(cpu, nohz.idle_cpus_mask)) > > > return false; > > > > > > - if (!force && !time_after(jiffies, > > > rq->last_blocked_load_update_tick)) > > > + if (!force && !time_after(jiffies, > > > rq->last_blocked_load_update_tick + (HZ/20))) > > > > This condition is there to make sure to update blocked load at most > > once a tick in order to filter newly idle case otherwise the rate > > limit is already done by load balance interval > > This hard coded (HZ/20) looks really like an ugly hack > > This was meant as an RFC patch to discuss the problem really. > > Joel is seeing update_blocked_averages() taking ~100us. Half of it seems in > processing __update_blocked_fair() and the other half in > sugov_update_shared(). > So roughly 50us each. Note that each function is calling an iterator in Can I assume that a freq change happens if sugov_update_shared() takes 50us ? which would mean that the update was useful at the end ? > return. Correct me if my numbers are wrong Joel. > > Running on a little core on low frequency these numbers don't look too odd. > So I'm not seeing how we can speed these functions up. > > But since update_sg_lb_stats() will end up with multiple calls to > update_blocked_averages() in one go, this latency adds up quickly. > > One noticeable factor in Joel's system is the presence of a lot of cgroups. > Which is essentially what makes __update_blocked_fair() expensive, and it > seems > to always return something has decayed so we end up with a call to > sugov_update_shared() in every call. > > I think we should limit the expensive call to update_blocked_averages() but At the opposite, some will complain that block values stay stall to high value and prevent any useful adjustment. Also update_blocked average is already rate limited with idle and busy load_balance Seems like the problem raised by Joel is the number of newly idle load balance > I honestly don't know what would be the right way to do it :-/ > > Or maybe there's another better alternative too.. > > Thanks > > -- > Qais Yousef > > > > > > return true; > > > > > > update_blocked_averages(cpu); > > > -- > > > 2.30.0.280.ga3ce27912f-goog > > >
Re: [PATCH v2 00/14] PHY: Add support in Sierra to use external clock
On 22/12/20 12:35 pm, Kishon Vijay Abraham I wrote: > The previous version of the patch series can be found @ [1] > > Changes from v1: > 1) Remove the part that prevents configuration if the SERDES is already >configured and focus only on using external clock and the associated >cleanups > 2) Change patch ordering > 3) Use exclusive reset control APIs > 4) Fix error handling code > 5) Include DT patches in this series (I can send this separately to DT > MAINTAINER once the driver patches are merged) > > [1] -> http://lore.kernel.org/r/20201103035556.21260-1-kis...@ti.com > I have couple of reports from kernel test robot. If there are any other comments on this series, I can fix them. Thanks Kishon > Kishon Vijay Abraham I (14): > phy: cadence: Sierra: Fix PHY power_on sequence > phy: ti: j721e-wiz: Invoke wiz_init() before > of_platform_device_create() > dt-bindings: phy: cadence-sierra: Add bindings for the PLLs within > SERDES > phy: ti: j721e-wiz: Get PHY properties only for "phy" or "link" > subnode > phy: cadence: cadence-sierra: Create PHY only for "phy" or "link" > sub-nodes > phy: cadence: cadence-sierra: Move all clk_get_*() to a separate > function > phy: cadence: cadence-sierra: Move all reset_control_get*() to a > separate function > phy: cadence: cadence-sierra: Explicitly request exclusive reset > control > phy: cadence: sierra: Model reference receiver as clocks (gate clocks) > phy: cadence: sierra: Enable pll_cmnlc and pll_cmnlc1 clocks > arm64: dts: ti: k3-j721e-main: Add DT nodes for clocks within Sierra > SERDES > arm64: dts: ti: k3-j721e-main: Fix external refclk input to SERDES > arm64: dts: ti: k3-j721e-common-proc-board: Use external clock for > SERDES > arm64: dts: ti: k3-j721e-common-proc-board: Re-name "link" name as > "phy" > > .../bindings/phy/phy-cadence-sierra.yaml | 89 ++- > .../dts/ti/k3-j721e-common-proc-board.dts | 57 +- > arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 186 -- > drivers/phy/cadence/phy-cadence-sierra.c | 543 -- > drivers/phy/ti/phy-j721e-wiz.c| 21 +- > 5 files changed, 808 insertions(+), 88 deletions(-) >
Re: [PATCH 1/1] process_madvise.2: Add process_madvise man page
On Wed 20-01-21 12:23:37, Suren Baghdasaryan wrote: [...] > MADV_COLD (since Linux 5.4.1) > Deactivate a given range of pages by moving them from active to > inactive LRU list. This is done to accelerate the reclaim of these > pages. The advice might be ignored for some pages in the range when it > is not applicable. I do not think we want to talk about active/inactive LRU lists here. Wouldn't it be sufficient to say Deactive a given range of pages which will make them a more probable reclaim target should there be a memory pressure. This is a non-destructive operation. Other than that, looks good to me from the content POV. Thanks! -- Michal Hocko SUSE Labs
Re: KASAN: slab-out-of-bounds Write in record_print_text
On 2021-01-25, syzbot
wrote:
> syzbot found the following issue on:
>
> HEAD commit:e6806137 Merge tag 'irq_urgent_for_v5.11_rc5' of git://git..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10c59c6f50
> kernel config: https://syzkaller.appspot.com/x/.config?x=be33d8015c9de024
> dashboard link: https://syzkaller.appspot.com/bug?extid=a42d84593d6a89a76f26
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1575e6b4d0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17aea4e8d0
>
> The issue was bisected to:
>
> commit f0e386ee0c0b71ea6f7238506a4d0965a2dbef11
> Author: John Ogness
> Date: Thu Jan 14 17:04:12 2021 +
>
> printk: fix buffer overflow potential for print_text()
Thank you syzbot for your valuable work. A fix has already been posted
and queued:
https://lkml.kernel.org/r/20210124202728.4718-1-john.ogn...@linutronix.de
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f30130d0
> final oops: https://syzkaller.appspot.com/x/report.txt?x=140b0130d0
> console output: https://syzkaller.appspot.com/x/log.txt?x=100b0130d0
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+a42d84593d6a89a76...@syzkaller.appspotmail.com
> Fixes: f0e386ee0c0b ("printk: fix buffer overflow potential for print_text()")
>
> ==
> BUG: KASAN: slab-out-of-bounds in record_print_text+0x33f/0x380
> kernel/printk/printk.c:1401
> Write of size 1 at addr 88801c2faf40 by task in:imklog/8158
>
> CPU: 1 PID: 8158 Comm: in:imklog Not tainted 5.11.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x107/0x163 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230
> __kasan_report mm/kasan/report.c:396 [inline]
> kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
> record_print_text+0x33f/0x380 kernel/printk/printk.c:1401
> syslog_print+0x2bb/0x430 kernel/printk/printk.c:1459
> do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
> do_syslog+0x49/0x60 kernel/printk/printk.c:1567
> kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
> pde_read fs/proc/inode.c:321 [inline]
> proc_reg_read+0x119/0x300 fs/proc/inode.c:331
> vfs_read+0x1b5/0x570 fs/read_write.c:494
> ksys_read+0x12d/0x250 fs/read_write.c:634
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f3e2eec922d
> Code: c1 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83
> ec 08 e8 4e fc ff ff 48 89 04 24 b8 00 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2
> e8 97 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
> RSP: 002b:7f3e2c865580 EFLAGS: 0293 ORIG_RAX:
> RAX: ffda RBX: RCX: 7f3e2eec922d
> RDX: 1fa0 RSI: 7f3e2c865da0 RDI: 0004
> RBP: 55d0880849d0 R08: R09: 0401
> R10: 0001 R11: 0293 R12: 7f3e2c865da0
> R13: 1fa0 R14: 1f9f R15: 7f3e2c865df3
>
> Allocated by task 8158:
> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
> kasan_set_track mm/kasan/common.c:46 [inline]
> set_alloc_info mm/kasan/common.c:401 [inline]
> kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429
> kmalloc include/linux/slab.h:552 [inline]
> syslog_print+0xb2/0x430 kernel/printk/printk.c:1430
> do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
> do_syslog+0x49/0x60 kernel/printk/printk.c:1567
> kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
> pde_read fs/proc/inode.c:321 [inline]
> proc_reg_read+0x119/0x300 fs/proc/inode.c:331
> vfs_read+0x1b5/0x570 fs/read_write.c:494
> ksys_read+0x12d/0x250 fs/read_write.c:634
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> The buggy address belongs to the object at 88801c2fa800
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 832 bytes to the right of
> 1024-byte region [88801c2fa800, 88801c2fac00)
> The buggy address belongs to the page:
> page:eb65f4f5 refcount:1 mapcount:0 mapping:
> index:0x0 pfn:0x1c2f8
> head:eb65f4f5 order:2 compound_mapcount:0 compound_pincount:0
> flags: 0xfff0010200(slab|head)
> raw: 00fff0010200 dead0100 dead0122 888010041140
> raw: 80080008 0001
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> 88801c2fae00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> 88801c2fae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>88801c2faf00: fc fc fc fc fc fc fc fc
Re: [PATCH bpf-next v3 3/3] xsk: build skb by page
On Mon, Jan 25, 2021 at 1:43 PM Xuan Zhuo wrote:
>
> On Mon, 25 Jan 2021 08:44:38 +0100, Magnus Karlsson
> wrote:
> > On Mon, Jan 25, 2021 at 3:27 AM Xuan Zhuo
> > wrote:
> > >
> > > On Fri, 22 Jan 2021 19:37:06 +0100, Magnus Karlsson
> > > wrote:
> > > > On Fri, Jan 22, 2021 at 6:26 PM Alexander Lobakin
> > > > wrote:
> > > > >
> > > > > From: Xuan Zhuo
> > > > > Date: Fri, 22 Jan 2021 23:39:15 +0800
> > > > >
> > > > > > On Fri, 22 Jan 2021 13:55:14 +0100, Magnus Karlsson
> > > > > > wrote:
> > > > > > > On Fri, Jan 22, 2021 at 1:39 PM Alexander Lobakin
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > From: Magnus Karlsson
> > > > > > > > Date: Fri, 22 Jan 2021 13:18:47 +0100
> > > > > > > >
> > > > > > > > > On Fri, Jan 22, 2021 at 12:57 PM Alexander Lobakin
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > From: Alexander Lobakin
> > > > > > > > > > Date: Fri, 22 Jan 2021 11:47:45 +
> > > > > > > > > >
> > > > > > > > > > > From: Eric Dumazet
> > > > > > > > > > > Date: Thu, 21 Jan 2021 16:41:33 +0100
> > > > > > > > > > >
> > > > > > > > > > > > On 1/21/21 2:47 PM, Xuan Zhuo wrote:
> > > > > > > > > > > > > This patch is used to construct skb based on page to
> > > > > > > > > > > > > save memory copy
> > > > > > > > > > > > > overhead.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This function is implemented based on
> > > > > > > > > > > > > IFF_TX_SKB_NO_LINEAR. Only the
> > > > > > > > > > > > > network card priv_flags supports IFF_TX_SKB_NO_LINEAR
> > > > > > > > > > > > > will use page to
> > > > > > > > > > > > > directly construct skb. If this feature is not
> > > > > > > > > > > > > supported, it is still
> > > > > > > > > > > > > necessary to copy data to construct skb.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Performance Testing
> > > > > > > > > > > > >
> > > > > > > > > > > > > The test environment is Aliyun ECS server.
> > > > > > > > > > > > > Test cmd:
> > > > > > > > > > > > > ```
> > > > > > > > > > > > > xdpsock -i eth0 -t -S -s
> > > > > > > > > > > > > ```
> > > > > > > > > > > > >
> > > > > > > > > > > > > Test result data:
> > > > > > > > > > > > >
> > > > > > > > > > > > > size64 512 10241500
> > > > > > > > > > > > > copy1916747 1775988 1600203 1440054
> > > > > > > > > > > > > page1974058 1953655 1945463 1904478
> > > > > > > > > > > > > percent 3.0%10.0% 21.58% 32.3%
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Xuan Zhuo
> > > > > > > > > > > > > Reviewed-by: Dust Li
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > net/xdp/xsk.c | 104
> > > > > > > > > > > > > --
> > > > > > > > > > > > > 1 file changed, 86 insertions(+), 18 deletions(-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > > > > > > > > > > index 4a83117..38af7f1 100644
> > > > > > > > > > > > > --- a/net/xdp/xsk.c
> > > > > > > > > > > > > +++ b/net/xdp/xsk.c
> > > > > > > > > > > > > @@ -430,6 +430,87 @@ static void
> > > > > > > > > > > > > xsk_destruct_skb(struct sk_buff *skb)
> > > > > > > > > > > > > sock_wfree(skb);
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > +static struct sk_buff *xsk_build_skb_zerocopy(struct
> > > > > > > > > > > > > xdp_sock *xs,
> > > > > > > > > > > > > + struct
> > > > > > > > > > > > > xdp_desc *desc)
> > > > > > > > > > > > > +{
> > > > > > > > > > > > > + u32 len, offset, copy, copied;
> > > > > > > > > > > > > + struct sk_buff *skb;
> > > > > > > > > > > > > + struct page *page;
> > > > > > > > > > > > > + void *buffer;
> > > > > > > > > > > > > + int err, i;
> > > > > > > > > > > > > + u64 addr;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + skb = sock_alloc_send_skb(>sk, 0, 1, );
> > > > > > > > > > > > > + if (unlikely(!skb))
> > > > > > > > > > > > > + return ERR_PTR(err);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + addr = desc->addr;
> > > > > > > > > > > > > + len = desc->len;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + buffer = xsk_buff_raw_get_data(xs->pool, addr);
> > > > > > > > > > > > > + offset = offset_in_page(buffer);
> > > > > > > > > > > > > + addr = buffer - xs->pool->addrs;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + for (copied = 0, i = 0; copied < len; i++) {
> > > > > > > > > > > > > + page = xs->pool->umem->pgs[addr >>
> > > > > > > > > > > > > PAGE_SHIFT];
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + get_page(page);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + copy = min_t(u32, PAGE_SIZE - offset, len -
> > > > > > > > > > > > > copied);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + skb_fill_page_desc(skb, i, page, offset,
> > > > > > > > > > > > > copy);
> > > > > > > > > > > > > +
> > >
Re: 5.11 new lockdep warning related to led-class code (also may involve ata / piix controller)
Hi,
On 1/13/21 9:59 AM, Hans de Goede wrote:
> Hi,
>
> On 1/12/21 11:30 PM, Pavel Machek wrote:
>> Hi!
>>
>>> Booting a 5.11-rc2 kernel with lockdep enabled inside a virtualbox vm
>>> (which still
>>> emulates good old piix ATA controllers) I get the below lockdep splat early
>>> on during boot:
>>>
>>> This seems to be led-class related but also seems to have a (P)ATA
>>> part to it. To the best of my knowledge this is a new problem in
>>> 5.11 .
>>
>> This is on my for-next branch:
>>
>> commit 9a5ad5c5b2d25508996f10ee6b428d5df91d9160 (HEAD -> for-next,
>> origin/for-next)
>>
>> leds: trigger: fix potential deadlock with libata
>>
>> We have the following potential deadlock condition:
>>
>>
>> WARNING: possible irq lock inversion dependency detected
>> 5.10.0-rc2+ #25 Not tainted
>>
>> swapper/3/0 just changed the state of lock:
>> 8880063bd618 (>lock){-...}-{2:2}, at:
>> ata_bmdma_interrupt+0x27/0x200
>> but this lock took another, HARDIRQ-READ-unsafe lock in the past:
>> (>leddev_list_lock){.+.?}-{2:2}
>>
>> If I'm not mistaken, that should fix your issue.
>
> I can confirm that this fixes things, thanks.
>
> I assume that this will be part of some future 5.11 fixes pull-req?
This *regression* fix seems to still have not landed in 5.11-rc5, can
we please get this on its way to Linus ?
Regards,
Hans
Re: [PATCH v4 2/4] mm: failfast mode with __GFP_NORETRY in alloc_contig_range
On Mon 25-01-21 14:12:02, Michal Hocko wrote: > On Thu 21-01-21 09:55:00, Minchan Kim wrote: > > Contiguous memory allocation can be stalled due to waiting > > on page writeback and/or page lock which causes unpredictable > > delay. It's a unavoidable cost for the requestor to get *big* > > contiguous memory but it's expensive for *small* contiguous > > memory(e.g., order-4) because caller could retry the request > > in different range where would have easy migratable pages > > without stalling. > > > > This patch introduce __GFP_NORETRY as compaction gfp_mask in > > alloc_contig_range so it will fail fast without blocking > > when it encounters pages needed waiting. > > I am not against controling how hard this allocator tries with gfp mask > but this changelog is rather void on any data and any user. OK, I can see that a user is in the last patch. -- Michal Hocko SUSE Labs
Re: [PATCH net-next v2 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding
On Mon, Jan 25, 2021 at 5:43 AM DENG Qingfang wrote: > Add device tree binding to support MT7530 GPIO controller. > > Signed-off-by: DENG Qingfang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH net-next v2 2/2] net: dsa: mt7530: MT7530 optional GPIO support
On Mon, Jan 25, 2021 at 5:43 AM DENG Qingfang wrote: > MT7530's LED controller can drive up to 15 LED/GPIOs. > > Add support for GPIO control and allow users to use its GPIOs by > setting gpio-controller property in device tree. > > Signed-off-by: DENG Qingfang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m
On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote: > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > When CONFIG_ATH9K is built-in but LED support is in a loadable > > module, both ath9k drivers fails to link: > > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > `ath_deinit_leds': > > gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister' > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > `ath_init_leds': > > gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext' > > > > The problem is that the 'imply' keyword does not enforce any dependency > > but is only a weak hint to Kconfig to enable another symbol from a > > defconfig file. > > > > Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect > > configuration but still allows building the driver without LED support. > > > > The 'select MAC80211_LEDS' is now ensures that the LED support is > > actually used if it is present, and the added Kconfig dependency > > on MAC80211_LEDS ensures that it cannot be enabled manually when it > > has no effect. > > But we do not want to have this dependency (selecting MAC80211_LEDS). > I fixed this problem here: > https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/ > Maybe let's take this approach? Generally speaking, I don't like to have a device driver specific Kconfig setting 'select' a subsystem', for two reasons: - you suddenly get asked for tons of new LED specific options when enabling seemingly benign options - Mixing 'depends on' and 'select' leads to bugs with circular dependencies that usually require turning some other 'select' into 'depends on'. The problem with LEDS_CLASS in particular is that there is a mix of drivers using one vs the other roughly 50:50. Arnd
[PATCH 0/1] mfd: da9063: Support SMBus and I2C mode
On an NXP i.MX6 Solo processor we are running an application which makes use of real-time threads (SCHED_RR). In combination with a DA9063 we experienced (rare) random shut-downs and reboots. We found that the issue was caused by a combination of the (default) DA9063 SMBus mode and non-atomic I2C transactions of the i.MX6 I2C driver. Because a transaction could be idle for longer than the SMBus clock time-out due to a real-time thread the DA9063 would time-out and receive the second half of the transaction as an unintended message. The solution we are giving to review in this patch is to allow using the I2C mode of the DA9063. We kindly ask for feedback and eventually hope for an integration to the mainline. Because we are on a vendor kernel we were not able to test this patch on the current mainline kernel. Though, we tested a (very similar) patch on our (close to mainline) Linux 4.14 and 5.4 vendor kernels. Hubert Streidl (1): mfd: da9063: Support SMBus and I2C mode Documentation/devicetree/bindings/mfd/da9063.txt | 7 +++ drivers/mfd/da9063-core.c| 9 + drivers/mfd/da9063-i2c.c | 13 + include/linux/mfd/da9063/core.h | 1 + include/linux/mfd/da9063/registers.h | 3 +++ 5 files changed, 33 insertions(+) -- 2.25.1
Re: [PATCH v4 1/4] mm: cma: introduce gfp flag in cma_alloc instead of no_warn
On Thu 21-01-21 09:54:59, Minchan Kim wrote:
> The upcoming patch will introduce __GFP_NORETRY semantic
> in alloc_contig_range which is a failfast mode of the API.
> Instead of adding a additional parameter for gfp, replace
> no_warn with gfp flag.
>
> To keep old behaviors, it follows the rule below.
>
> no_warn gfp_flags
>
> false GFP_KERNEL
> trueGFP_KERNEL|__GFP_NOWARN
> gfp & __GFP_NOWARN GFP_KERNEL | (gfp & __GFP_NOWARN)
>
> Reviewed-by: Suren Baghdasaryan
> Signed-off-by: Minchan Kim
[...]
> diff --git a/mm/cma.c b/mm/cma.c
> index 0ba69cd16aeb..d50627686fec 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -419,13 +419,13 @@ static inline void cma_debug_show_areas(struct cma
> *cma) { }
> * @cma: Contiguous memory region for which the allocation is performed.
> * @count: Requested number of pages.
> * @align: Requested alignment of pages (in PAGE_SIZE order).
> - * @no_warn: Avoid printing message about failed allocation
> + * @gfp_mask: GFP mask to use during the cma allocation.
Call out supported gfp flags explicitly. Have a look at kvmalloc_node
for a guidance.
--
Michal Hocko
SUSE Labs
[PATCH v2 2/2] thermal: Move therm_throt there from x86/mce
From: Borislav Petkov
This functionality has nothing to do with MCE, move it to the thermal
framework and untangle it from MCE.
Have thermal_set_handler() check the build-time assigned default handler
stub was the one used before therm_throt assigns a new one.
Requested-by: Peter Zijlstra
Signed-off-by: Borislav Petkov
---
arch/x86/Kconfig | 4 ---
arch/x86/include/asm/irq.h| 4 +++
arch/x86/include/asm/mce.h| 16 --
arch/x86/include/asm/thermal.h| 21 ++
arch/x86/kernel/cpu/intel.c | 3 ++
arch/x86/kernel/cpu/mce/Makefile | 2 --
arch/x86/kernel/cpu/mce/intel.c | 1 -
arch/x86/kernel/irq.c | 29 +++
drivers/thermal/intel/Kconfig | 4 +++
drivers/thermal/intel/Makefile| 1 +
.../thermal/intel}/therm_throt.c | 25 ++--
drivers/thermal/intel/x86_pkg_temp_thermal.c | 3 +-
12 files changed, 67 insertions(+), 46 deletions(-)
create mode 100644 arch/x86/include/asm/thermal.h
rename {arch/x86/kernel/cpu/mce => drivers/thermal/intel}/therm_throt.c (97%)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f851179ff0..9989db3a9bf5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1158,10 +1158,6 @@ config X86_MCE_INJECT
If you don't know what a machine check is and you don't do kernel
QA it is safe to say n.
-config X86_THERMAL_VECTOR
- def_bool y
- depends on X86_MCE_INTEL
-
source "arch/x86/events/Kconfig"
config X86_LEGACY_VM86
diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
index 528c8a71fe7f..ad65fe7dceb1 100644
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -53,4 +53,8 @@ void arch_trigger_cpumask_backtrace(const struct cpumask
*mask,
#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace
#endif
+#ifdef CONFIG_X86_THERMAL_VECTOR
+void thermal_set_handler(void (*handler)(void));
+#endif
+
#endif /* _ASM_X86_IRQ_H */
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index def9aa5e1fa4..ddfb3cad8dff 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -288,22 +288,6 @@ extern void (*mce_threshold_vector)(void);
/* Deferred error interrupt handler */
extern void (*deferred_error_int_vector)(void);
-/*
- * Thermal handler
- */
-
-void intel_init_thermal(struct cpuinfo_x86 *c);
-
-/* Interrupt Handler for core thermal thresholds */
-extern int (*platform_thermal_notify)(__u64 msr_val);
-
-/* Interrupt Handler for package thermal thresholds */
-extern int (*platform_thermal_package_notify)(__u64 msr_val);
-
-/* Callback support of rate control, return true, if
- * callback has rate control */
-extern bool (*platform_thermal_package_rate_control)(void);
-
/*
* Used by APEI to report memory error via /dev/mcelog
*/
diff --git a/arch/x86/include/asm/thermal.h b/arch/x86/include/asm/thermal.h
new file mode 100644
index ..58b0e0a4af6e
--- /dev/null
+++ b/arch/x86/include/asm/thermal.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_THERMAL_H
+#define _ASM_X86_THERMAL_H
+
+/* Interrupt Handler for package thermal thresholds */
+extern int (*platform_thermal_package_notify)(__u64 msr_val);
+
+/* Interrupt Handler for core thermal thresholds */
+extern int (*platform_thermal_notify)(__u64 msr_val);
+
+/* Callback support of rate control, return true, if
+ * callback has rate control */
+extern bool (*platform_thermal_package_rate_control)(void);
+
+#ifdef CONFIG_X86_THERMAL_VECTOR
+void intel_init_thermal(struct cpuinfo_x86 *c);
+#else
+static inline void intel_init_thermal(struct cpuinfo_x86 *c) { }
+#endif
+
+#endif /* _ASM_X86_THERMAL_H */
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 59a1e3ce3f14..71221af87cb1 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_64
#include
@@ -719,6 +720,8 @@ static void init_intel(struct cpuinfo_x86 *c)
tsx_disable();
split_lock_init();
+
+ intel_init_thermal(c);
}
#ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/cpu/mce/Makefile b/arch/x86/kernel/cpu/mce/Makefile
index 9f020c994154..015856abdbb1 100644
--- a/arch/x86/kernel/cpu/mce/Makefile
+++ b/arch/x86/kernel/cpu/mce/Makefile
@@ -9,8 +9,6 @@ obj-$(CONFIG_X86_MCE_THRESHOLD) += threshold.o
mce-inject-y := inject.o
obj-$(CONFIG_X86_MCE_INJECT) += mce-inject.o
-obj-$(CONFIG_X86_THERMAL_VECTOR) += therm_throt.o
-
obj-$(CONFIG_ACPI_APEI)+= apei.o
obj-$(CONFIG_X86_MCELOG_LEGACY)+= dev-mcelog.o
diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c
index c2476fe0682e..e309476743b7 100644
--- a/arch/x86/kernel/cpu/mce/intel.c
+++
[PATCH v2 1/2] x86/mce: Get rid of mcheck_intel_therm_init()
From: Borislav Petkov
Move the APIC_LVTTHMR read which needs to happen on the BSP, to
intel_init_thermal(). One less boot dependency.
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/mce.h| 6 --
arch/x86/kernel/cpu/mce/core.c| 1 -
arch/x86/kernel/cpu/mce/therm_throt.c | 14 +++---
3 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 56cdeaac76a0..def9aa5e1fa4 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -304,12 +304,6 @@ extern int (*platform_thermal_package_notify)(__u64
msr_val);
* callback has rate control */
extern bool (*platform_thermal_package_rate_control)(void);
-#ifdef CONFIG_X86_THERMAL_VECTOR
-extern void mcheck_intel_therm_init(void);
-#else
-static inline void mcheck_intel_therm_init(void) { }
-#endif
-
/*
* Used by APEI to report memory error via /dev/mcelog
*/
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index e133ce1e562b..c68e21b4ea0d 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -2178,7 +2178,6 @@ __setup("mce", mcheck_enable);
int __init mcheck_init(void)
{
- mcheck_intel_therm_init();
mce_register_decode_chain(_nb);
mce_register_decode_chain(_uc_nb);
mce_register_decode_chain(_default_nb);
diff --git a/arch/x86/kernel/cpu/mce/therm_throt.c
b/arch/x86/kernel/cpu/mce/therm_throt.c
index a7cd2d203ced..5b1aa0f30655 100644
--- a/arch/x86/kernel/cpu/mce/therm_throt.c
+++ b/arch/x86/kernel/cpu/mce/therm_throt.c
@@ -633,23 +633,15 @@ static int intel_thermal_supported(struct cpuinfo_x86 *c)
return 1;
}
-void __init mcheck_intel_therm_init(void)
-{
- /*
-* This function is only called on boot CPU. Save the init thermal
-* LVT value on BSP and use that value to restore APs' thermal LVT
-* entry BIOS programmed later
-*/
- if (intel_thermal_supported(_cpu_data))
- lvtthmr_init = apic_read(APIC_LVTTHMR);
-}
-
void intel_init_thermal(struct cpuinfo_x86 *c)
{
unsigned int cpu = smp_processor_id();
int tm2 = 0;
u32 l, h;
+ if ((c == _cpu_data) && intel_thermal_supported(c))
+ lvtthmr_init = apic_read(APIC_LVTTHMR);
+
if (!intel_thermal_supported(c))
return;
--
2.29.2
[PATCH v2 0/2] Move ...mce/therm_throt.c to drivers/thermal/
From: Borislav Petkov
Hi,
here's v2 which addresses peterz's comments to patch 2.
@thermal folks, lemme know if you have any objections otherwise I'll
route this through the tip tree.
Thx.
Changelog:
==
v1:
so this has come up a bunch of times in the past and PeterZ is right
- that thing doesn't have anything to do with the MCE glue so move it
where it belongs.
Thx.
Borislav Petkov (2):
x86/mce: Get rid of mcheck_intel_therm_init()
thermal: Move therm_throt there from x86/mce
arch/x86/Kconfig | 4 --
arch/x86/include/asm/irq.h| 4 ++
arch/x86/include/asm/mce.h| 22 ---
arch/x86/include/asm/thermal.h| 21 ++
arch/x86/kernel/cpu/intel.c | 3 ++
arch/x86/kernel/cpu/mce/Makefile | 2 -
arch/x86/kernel/cpu/mce/core.c| 1 -
arch/x86/kernel/cpu/mce/intel.c | 1 -
arch/x86/kernel/irq.c | 29 ++
drivers/thermal/intel/Kconfig | 4 ++
drivers/thermal/intel/Makefile| 1 +
.../thermal/intel}/therm_throt.c | 39 +++
drivers/thermal/intel/x86_pkg_temp_thermal.c | 3 +-
13 files changed, 70 insertions(+), 64 deletions(-)
create mode 100644 arch/x86/include/asm/thermal.h
rename {arch/x86/kernel/cpu/mce => drivers/thermal/intel}/therm_throt.c (96%)
--
2.29.2
Re: [PATCH 1/4] ARM: dts: qcom: msm8974: add gpu support
On 1/24/21 11:05 PM, Pavel Machek wrote: > On Sun 2021-01-24 15:56:07, Iskren Chernev wrote: >> From: Brian Masney >> >> Add support for the a3xx GPU > > This is phone, right? Can I ask phone-de...@vger.kernel.org to be > cc-ed? CC-ing phone-de...@vger.kernel.org. I'm not sure why you didn't do it :-/ > > Thank you, > Pavel > > Regards, Iskren
[PATCH v3 2/3] drm/bridge: anx7625: fix not correct return value
At some time, the original code may return non zero value, force return 0
if operation finished
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc059..04536cc 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -189,10 +189,10 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
AP_AUX_CTRL_STATUS);
if (val < 0 || (val & 0x0F)) {
DRM_DEV_ERROR(dev, "aux status %02x\n", val);
- val = -EIO;
+ return -EIO;
}
- return val;
+ return 0;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
--
2.7.4
RE: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and add cluster scheduler
> -Original Message- > From: Dietmar Eggemann [mailto:dietmar.eggem...@arm.com] > Sent: Wednesday, January 13, 2021 1:53 AM > To: Song Bao Hua (Barry Song) ; Morten Rasmussen > ; Tim Chen > Cc: valentin.schnei...@arm.com; catalin.mari...@arm.com; w...@kernel.org; > r...@rjwysocki.net; vincent.guit...@linaro.org; l...@kernel.org; > gre...@linuxfoundation.org; Jonathan Cameron ; > mi...@redhat.com; pet...@infradead.org; juri.le...@redhat.com; > rost...@goodmis.org; bseg...@google.com; mgor...@suse.de; > mark.rutl...@arm.com; sudeep.ho...@arm.com; aubrey...@linux.intel.com; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > linux-a...@vger.kernel.org; linux...@openeuler.org; xuwei (O) > ; Zengtao (B) ; tiantao (H) > > Subject: Re: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and > add cluster scheduler > > On 08/01/2021 22:30, Song Bao Hua (Barry Song) wrote: > > > >> -Original Message- > >> From: Morten Rasmussen [mailto:morten.rasmus...@arm.com] > >> Sent: Saturday, January 9, 2021 4:13 AM > >> To: Tim Chen > >> Cc: Song Bao Hua (Barry Song) ; > >> valentin.schnei...@arm.com; catalin.mari...@arm.com; w...@kernel.org; > >> r...@rjwysocki.net; vincent.guit...@linaro.org; l...@kernel.org; > >> gre...@linuxfoundation.org; Jonathan Cameron > ; > >> mi...@redhat.com; pet...@infradead.org; juri.le...@redhat.com; > >> dietmar.eggem...@arm.com; rost...@goodmis.org; bseg...@google.com; > >> mgor...@suse.de; mark.rutl...@arm.com; sudeep.ho...@arm.com; > >> aubrey...@linux.intel.com; linux-arm-ker...@lists.infradead.org; > >> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; > >> linux...@openeuler.org; xuwei (O) ; Zengtao (B) > >> ; tiantao (H) > >> Subject: Re: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters > and > >> add cluster scheduler > >> > >> On Thu, Jan 07, 2021 at 03:16:47PM -0800, Tim Chen wrote: > >>> On 1/6/21 12:30 AM, Barry Song wrote: > ARM64 server chip Kunpeng 920 has 6 clusters in each NUMA node, and each > cluster has 4 cpus. All clusters share L3 cache data while each cluster > has local L3 tag. On the other hand, each cluster will share some > internal system bus. This means cache is much more affine inside one > cluster > than across clusters. > >>> > >>> There is a similar need for clustering in x86. Some x86 cores could share > >> L2 caches that > >>> is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 > clusters > >>> of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing > >> L3). > >>> Having a sched domain at the L2 cluster helps spread load among > >>> L2 domains. This will reduce L2 cache contention and help with > >>> performance for low to moderate load scenarios. > >> > >> IIUC, you are arguing for the exact opposite behaviour, i.e. balancing > >> between L2 caches while Barry is after consolidating tasks within the > >> boundaries of a L3 tag cache. One helps cache utilization, the other > >> communication latency between tasks. Am I missing something? > > > > Morten, this is not true. > > > > we are both actually looking for the same behavior. My patch also > > has done the exact same behavior of spreading with Tim's patch. > > That's the case for the load-balance path because of the extra Sched > Domain (SD) (CLS/MC_L2) below MC. > > But in wakeup you add code which leads to a different packing strategy. Yes, but I put a note for the 1st case: "Case 1. we have two tasks *without* any relationship running in a system with 2 clusters and 8 cpus" so for tasks without wake-up relationship, the current patch will only result in spreading. Anyway, I will also test Tim's benchmark in kunpeng920 with the SCHED_CLUTER to see what will happen. Till now, benchmark has only covered the case to figure out the benefit of changing wake-up path. I would also be interested in figuring out what we have got from the change of load_balance(). > > It looks like that Tim's workload (SPECrate mcf) shows a performance > boost solely because of the changes the additional MC_L2 SD introduces > in load balance. The wakeup path is unchanged, i.e. llc-packing. IMHO we > have to carefully distinguish between packing vs. spreading in wakeup > and load-balance here. > > > Considering the below two cases: > > Case 1. we have two tasks without any relationship running in a system with > 2 clusters and 8 cpus. > > > > Without the sched_domain of cluster, these two tasks might be put as below: > > +---++-+ > > | ++ ++ || | > > | |task| |task| || | > > | |1 | |2 | || | > > | ++ ++ || | > > | || | > > | cluster1|| cluster2| > > +---++-+ > > With the
Re: [PATCH v4 1/3] arm64: Improve kernel address detection of __is_lm_address()
Hi Vincenzo, On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote: > Currently, the __is_lm_address() check just masks out the top 12 bits > of the address, but if they are 0, it still yields a true result. > This has as a side effect that virt_addr_valid() returns true even for > invalid virtual addresses (e.g. 0x0). > > Improve the detection checking that it's actually a kernel address > starting at PAGE_OFFSET. > > Cc: Catalin Marinas > Cc: Will Deacon > Suggested-by: Catalin Marinas > Reviewed-by: Catalin Marinas > Signed-off-by: Vincenzo Frascino Looking around, it seems that there are some existing uses of virt_addr_valid() that expect it to reject addresses outside of the TTBR1 range. For example, check_mem_type() in drivers/tee/optee/call.c. Given that, I think we need something that's easy to backport to stable. This patch itself looks fine, but it's not going to backport very far, so I suspect we might need to write a preparatory patch that adds an explicit range check to virt_addr_valid() which can be trivially backported. For this patch: Acked-by: Mark Rutland Thanks, Mark. > --- > arch/arm64/include/asm/memory.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 18fce223b67b..99d7e1494aaa 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -247,9 +247,11 @@ static inline const void *__tag_set(const void *addr, u8 > tag) > > > /* > - * The linear kernel range starts at the bottom of the virtual address space. > + * Check whether an arbitrary address is within the linear map, which > + * lives in the [PAGE_OFFSET, PAGE_END) interval at the bottom of the > + * kernel's TTBR1 address range. > */ > -#define __is_lm_address(addr)(((u64)(addr) & ~PAGE_OFFSET) < > (PAGE_END - PAGE_OFFSET)) > +#define __is_lm_address(addr)(((u64)(addr) ^ PAGE_OFFSET) < > (PAGE_END - PAGE_OFFSET)) > > #define __lm_to_phys(addr) (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET) > #define __kimg_to_phys(addr) ((addr) - kimage_voffset) > -- > 2.30.0 >
Re: [PATCH RFC v1 00/15] iommu/virtio: Nested stage support with Arm
Hi Shameer, On 1/22/21 9:19 PM, Shameerali Kolothum Thodi wrote: Hi Vivek, -Original Message- From: Vivek Kumar Gautam [mailto:vivek.gau...@arm.com] Sent: 21 January 2021 17:34 To: Auger Eric ; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; io...@lists.linux-foundation.org; virtualizat...@lists.linux-foundation.org Cc: j...@8bytes.org; will.dea...@arm.com; m...@redhat.com; robin.mur...@arm.com; jean-phili...@linaro.org; alex.william...@redhat.com; kevin.t...@intel.com; jacob.jun@linux.intel.com; yi.l@intel.com; lorenzo.pieral...@arm.com; Shameerali Kolothum Thodi Subject: Re: [PATCH RFC v1 00/15] iommu/virtio: Nested stage support with Arm Hi Eric, On 1/19/21 2:33 PM, Auger Eric wrote: Hi Vivek, On 1/15/21 1:13 PM, Vivek Gautam wrote: This patch-series aims at enabling Nested stage translation in guests using virtio-iommu as the paravirtualized iommu. The backend is supported with Arm SMMU-v3 that provides nested stage-1 and stage-2 translation. This series derives its purpose from various efforts happening to add support for Shared Virtual Addressing (SVA) in host and guest. On Arm, most of the support for SVA has already landed. The support for nested stage translation and fault reporting to guest has been proposed [1]. The related changes required in VFIO [2] framework have also been put forward. This series proposes changes in virtio-iommu to program PASID tables and related stage-1 page tables. A simple iommu-pasid-table library is added for this purpose that interacts with vendor drivers to allocate and populate PASID tables. In Arm SMMUv3 we propose to pull the Context Descriptor (CD) management code out of the arm-smmu-v3 driver and add that as a glue vendor layer to support allocating CD tables, and populating them with right values. These CD tables are essentially the PASID tables and contain stage-1 page table configurations too. A request to setup these CD tables come from virtio-iommu driver using the iommu-pasid-table library when running on Arm. The virtio-iommu then pass these PASID tables to the host using the right virtio backend and support in VMM. For testing we have added necessary support in kvmtool. The changes in kvmtool are based on virtio-iommu development branch by Jean-Philippe Brucker [3]. The tested kernel branch contains following in the order bottom to top on the git hash - a) v5.11-rc3 b) arm-smmu-v3 [1] and vfio [2] changes from Eric to add nested page table support for Arm. c) Smmu test engine patches from Jean-Philippe's branch [4] d) This series e) Domain nesting info patches [5][6][7]. f) Changes to add arm-smmu-v3 specific nesting info (to be sent to the list). This kernel is tested on Neoverse reference software stack with Fixed virtual platform. Public version of the software stack and FVP is available here[8][9]. A big thanks to Jean-Philippe for his contributions towards this work and for his valuable guidance. [1] https://lore.kernel.org/linux-iommu/20201118112151.25412-1-eric.auger @redhat.com/T/ [2] https://lore.kernel.org/kvmarm/20201116110030.32335-12-eric.auger@red hat.com/T/ [3] https://jpbrucker.net/git/kvmtool/log/?h=virtio-iommu/devel [4] https://jpbrucker.net/git/linux/log/?h=sva/smmute [5] https://lore.kernel.org/kvm/1599734733-6431-2-git-send-email-yi.l.liu @intel.com/ [6] https://lore.kernel.org/kvm/1599734733-6431-3-git-send-email-yi.l.liu @intel.com/ [7] https://lore.kernel.org/kvm/1599734733-6431-4-git-send-email-yi.l.liu @intel.com/ [8] https://developer.arm.com/tools-and-software/open-source-software/arm -platforms-software/arm-ecosystem-fvps [9] https://git.linaro.org/landing-teams/working/arm/arm-reference-platfo rms.git/about/docs/rdn1edge/user-guide.rst Could you share a public branch where we could find all the kernel pieces. Thank you in advance Apologies for the delay. It took a bit of time to sort things out for a public branch. The branch is available in my github now. Please have a look. https://github.com/vivek-arm/linux/tree/5.11-rc3-nested-pgtbl-arm-smmuv3-vi rtio-iommu > Thanks for this. Do you have a corresponding kvmtool branch mentioned above as public? Thanks for showing interest. I will publish the kvmtool branch asap. Though the current development is based on Jean's branch for virtio-iommu [1], I plan to rebase the changes to master soon. Thanks & regards Vivek [1] https://jpbrucker.net/git/kvmtool/log/?h=virtio-iommu/devel Thanks, Shameer
[PATCH v3 3/3] drm/bridge: anx7625: add MIPI DPI input feature support
Add MIPI rx DPI input support
Reported-by: kernel test robot
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 326 --
drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +-
2 files changed, 285 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 04536cc..c7fc92b 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
-static int anx7625_write_and_or(struct anx7625_data *ctx,
- struct i2c_client *client,
- u8 offset, u8 and_mask, u8 or_mask)
+static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
- int val;
+ int i, ret;
- val = anx7625_reg_read(ctx, client, offset);
- if (val < 0)
- return val;
+ ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CONTROL_REGISTER, 0x80);
+ for (i = 0; i < 13; i++)
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_BIT_MATRIX_12 + i,
+0x18 + i);
- return anx7625_reg_write(ctx, client,
-offset, (val & and_mask) | (or_mask));
+ return ret;
}
static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
@@ -195,6 +195,60 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
+static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
+u8 addrh, u8 addrm, u8 addrl,
+u8 len, u8 *buf)
+{
+ struct device *dev = >client->dev;
+ int ret;
+ u8 cmd;
+
+ if (len > MAX_DPCD_BUFFER_SIZE) {
+ DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
+ return -EINVAL;
+ }
+
+ cmd = ((len - 1) << 4) | 0x09;
+
+ /* Set command and length */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_COMMAND, cmd);
+
+ /* Set aux access address */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_7_0, addrl);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_15_8, addrm);
+ ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_19_16, addrh);
+
+ /* Enable aux access */
+ ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
+
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
+ return -EIO;
+ }
+
+ usleep_range(2000, 2100);
+
+ ret = wait_aux_op_finish(ctx);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_BUFF_START, len, buf);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "read dpcd register failed\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int anx7625_video_mute_control(struct anx7625_data *ctx,
u8 status)
{
@@ -219,38 +273,6 @@ static int anx7625_video_mute_control(struct anx7625_data
*ctx,
return ret;
}
-static int anx7625_config_audio_input(struct anx7625_data *ctx)
-{
- struct device *dev = >client->dev;
- int ret;
-
- /* Channel num */
- ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
-
- /* FS */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_4,
- 0xf0, AUDIO_FS_48K);
- /* Word length */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_5,
- 0xf0, AUDIO_W_LEN_24_24MAX);
- /* I2S */
- ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
- ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
-AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
- /* Audio change flag */
- ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
- AP_AV_STATUS, AP_AUDIO_CHG);
-
- if (ret < 0)
- DRM_DEV_ERROR(dev, "fail to config audio.\n");
-
- return ret;
-}
-
/* Reduction
[PATCH -next] usb: core: Remove unused including
Fix the following versioncheck warning: drivers/usb/core/hcd.c:14:1: unused including Reported-by: Hulk Robot Signed-off-by: Zou Wei --- drivers/usb/core/hcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 3f03813..53bc93d 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -11,7 +11,6 @@ #include #include -#include #include #include #include -- 2.6.2
[PATCH] perf test: Add parse-metric memory bandwidth testcase
Event duration_time in a metric expression requires special handling.
Improve test coverage by including a metric whose expression includes
duration_time. The actual metric is a copied from the L1D_Cache_Fill_BW
metric on my broadwell machine.
Signed-off-by: John Garry
---
Based on acme perf/core + "perf metricgroup: Fix for metrics containing
duration_time"
diff --git a/tools/perf/tests/parse-metric.c b/tools/perf/tests/parse-metric.c
index ce7be37f0d88..6dc1db1626ad 100644
--- a/tools/perf/tests/parse-metric.c
+++ b/tools/perf/tests/parse-metric.c
@@ -69,6 +69,10 @@ static struct pmu_event pme_test[] = {
.metric_expr= "1/m3",
.metric_name= "M3",
},
+{
+ .metric_expr= "64 * l1d.replacement / 10 / duration_time",
+ .metric_name= "L1D_Cache_Fill_BW",
+},
{
.name = NULL,
}
@@ -107,6 +111,8 @@ static void load_runtime_stat(struct runtime_stat *st,
struct evlist *evlist,
evlist__for_each_entry(evlist, evsel) {
count = find_value(evsel->name, vals);
perf_stat__update_shadow_stats(evsel, count, 0, st);
+ if (!strcmp(evsel->name, "duration_time"))
+ update_stats(_nsecs_stats, count);
}
}
@@ -321,6 +327,23 @@ static int test_recursion_fail(void)
return 0;
}
+static int test_memory_bandwidth(void)
+{
+ double ratio;
+ struct value vals[] = {
+ { .event = "l1d.replacement", .val = 400 },
+ { .event = "duration_time", .val = 2 },
+ { .event = NULL, },
+ };
+
+ TEST_ASSERT_VAL("failed to compute metric",
+ compute_metric("L1D_Cache_Fill_BW", vals, ) == 0);
+ TEST_ASSERT_VAL("L1D_Cache_Fill_BW, wrong ratio",
+ 1.28 == ratio);
+
+ return 0;
+}
+
static int test_metric_group(void)
{
double ratio1, ratio2;
@@ -353,5 +376,6 @@ int test__parse_metric(struct test *test __maybe_unused,
int subtest __maybe_unu
TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
TEST_ASSERT_VAL("recursion fail failed", test_recursion_fail() == 0);
TEST_ASSERT_VAL("test metric group", test_metric_group() == 0);
+ TEST_ASSERT_VAL("Memory bandwidth", test_memory_bandwidth() == 0);
return 0;
}
--
2.26.2
Re: [PATCH v3] iio: adc: stm32-adc: enable timestamping for non-DMA usage
On 1/25/21 12:21 PM, Ahmad Fatoum wrote:
> For non-DMA usage, we have an easy way to associate a timestamp with a
> sample: iio_pollfunc_store_time stores a timestamp in the primary
> trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
> to push out the buffer along with the timestamp.
>
> For this to work, the driver needs to register an IIO_TIMESTAMP channel.
> Do this.
>
> For DMA, it's not as easy, because we don't push the buffers out of
> stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
> a tasklet scheduled after a DMA completion.
>
> Preferably, the DMA controller would copy us the timestamp into that buffer
> as well. Until this is implemented, restrict timestamping support to
> only PIO. For low-frequency sampling, PIO is probably good enough.
>
> Cc: Holger Assmann
> Acked-by: Fabrice Gasnier
> Signed-off-by: Ahmad Fatoum
> ---
> v2 -> v3:
> - explicitly specify alignment (Jonathan)
> - increase buffer size to hold additional timestamp
> v1 -> v2:
> - Added comment about timestamping being PIO only (Fabrice)
> - Added missing DMA resource clean up in error path (Fabrice)
> - Added Fabrice's Acked-by
> ---
> drivers/iio/adc/stm32-adc.c | 39 +
> 1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index c067c994dae2..ab2f440d7afb 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -177,7 +177,7 @@ struct stm32_adc_cfg {
> * @offset: ADC instance register offset in ADC block
> * @cfg: compatible configuration data
> * @completion: end of single conversion completion
> - * @buffer: data buffer
> + * @buffer: data buffer + 8 bytes for timestamp if enabled
^
> * @clk: clock for this adc instance
> * @irq: interrupt for this adc instance
> * @lock:spinlock
> @@ -200,7 +200,7 @@ struct stm32_adc {
> u32 offset;
> const struct stm32_adc_cfg *cfg;
> struct completion completion;
> - u16 buffer[STM32_ADC_MAX_SQ];
> + u16 buffer[STM32_ADC_MAX_SQ + 8] __aligned(8);
^^ ^
How does that fit together?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: OpenPGP digital signature
RE: [PATCH] drm/amd/display: use div_s64() for 64-bit division
[AMD Public Use]
Hi Arnd Bergmann,
Thanks for your patch. This link error during compile has been fixed by below
commit and been submitted to drm-next branch already.
5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Arnd Bergmann
Sent: Monday, January 25, 2021 7:40 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Koenig,
Christian ; David Airlie ; Daniel
Vetter ; Aberback, Joshua ; Lakha,
Bhawanpreet ; Kazlauskas, Nicholas
Cc: Arnd Bergmann ; Chalmers, Wesley ;
Zhuo, Qingqing ; Siqueira, Rodrigo
; linux-kernel@vger.kernel.org;
amd-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Jacky Liao
; Leung, Martin
Subject: [PATCH] drm/amd/display: use div_s64() for 64-bit division
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perform the division here. One of them was an unsigned
division originally, but it looks like signed division was intended, so use
that to consistently allow a negative delay.
Fixes: ea7154d8d9fb ("drm/amd/display: Update
dcn30_apply_idle_power_optimizations() code")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index dff83c6a142a..a133e399e76d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -772,8 +772,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
cursor_cache_enable ?
_attr : NULL)) {
unsigned int v_total =
stream->adjust.v_total_max ?
stream->adjust.v_total_max :
stream->timing.v_total;
- unsigned int refresh_hz = (unsigned long long)
stream->timing.pix_clk_100hz *
- 100LL / (v_total *
stream->timing.h_total);
+ unsigned int refresh_hz = div_s64((unsigned
long long) stream->timing.pix_clk_100hz *
+ 100LL, v_total *
stream->timing.h_total);
/*
* one frame time in microsec:
@@ -800,8 +800,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
unsigned int denom = refresh_hz * 6528;
unsigned int stutter_period =
dc->current_state->perf_params.stutter_period_us;
- tmr_delay = (((100LL + 2 * stutter_period *
refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
/* scale should be increased until it fits into
6 bits */ @@ -815,8 +815,8 @@ bool dcn30_apply_idle_power_optimizations(struct
dc *dc, bool enable)
}
denom *= 2;
- tmr_delay = (((100LL + 2 *
stutter_period * refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
}
--
2.29.2
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Cguchun.chen%40amd.com%7C4bb97aae9edc4153392c08d8c1260048%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637471716255231899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kLdkVHfkYx%2Bd249%2BmtG5GJTq295Pxzw7mgTe0FD8QvY%3Dreserved=0
KASAN: slab-out-of-bounds Write in record_print_text
Hello,
syzbot found the following issue on:
HEAD commit:e6806137 Merge tag 'irq_urgent_for_v5.11_rc5' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10c59c6f50
kernel config: https://syzkaller.appspot.com/x/.config?x=be33d8015c9de024
dashboard link: https://syzkaller.appspot.com/bug?extid=a42d84593d6a89a76f26
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1575e6b4d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17aea4e8d0
The issue was bisected to:
commit f0e386ee0c0b71ea6f7238506a4d0965a2dbef11
Author: John Ogness
Date: Thu Jan 14 17:04:12 2021 +
printk: fix buffer overflow potential for print_text()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f30130d0
final oops: https://syzkaller.appspot.com/x/report.txt?x=140b0130d0
console output: https://syzkaller.appspot.com/x/log.txt?x=100b0130d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a42d84593d6a89a76...@syzkaller.appspotmail.com
Fixes: f0e386ee0c0b ("printk: fix buffer overflow potential for print_text()")
==
BUG: KASAN: slab-out-of-bounds in record_print_text+0x33f/0x380
kernel/printk/printk.c:1401
Write of size 1 at addr 88801c2faf40 by task in:imklog/8158
CPU: 1 PID: 8158 Comm: in:imklog Not tainted 5.11.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:120
print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230
__kasan_report mm/kasan/report.c:396 [inline]
kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
record_print_text+0x33f/0x380 kernel/printk/printk.c:1401
syslog_print+0x2bb/0x430 kernel/printk/printk.c:1459
do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
do_syslog+0x49/0x60 kernel/printk/printk.c:1567
kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
pde_read fs/proc/inode.c:321 [inline]
proc_reg_read+0x119/0x300 fs/proc/inode.c:331
vfs_read+0x1b5/0x570 fs/read_write.c:494
ksys_read+0x12d/0x250 fs/read_write.c:634
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f3e2eec922d
Code: c1 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83
ec 08 e8 4e fc ff ff 48 89 04 24 b8 00 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8
97 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:7f3e2c865580 EFLAGS: 0293 ORIG_RAX:
RAX: ffda RBX: RCX: 7f3e2eec922d
RDX: 1fa0 RSI: 7f3e2c865da0 RDI: 0004
RBP: 55d0880849d0 R08: R09: 0401
R10: 0001 R11: 0293 R12: 7f3e2c865da0
R13: 1fa0 R14: 1f9f R15: 7f3e2c865df3
Allocated by task 8158:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:401 [inline]
kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429
kmalloc include/linux/slab.h:552 [inline]
syslog_print+0xb2/0x430 kernel/printk/printk.c:1430
do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
do_syslog+0x49/0x60 kernel/printk/printk.c:1567
kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
pde_read fs/proc/inode.c:321 [inline]
proc_reg_read+0x119/0x300 fs/proc/inode.c:331
vfs_read+0x1b5/0x570 fs/read_write.c:494
ksys_read+0x12d/0x250 fs/read_write.c:634
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 88801c2fa800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 832 bytes to the right of
1024-byte region [88801c2fa800, 88801c2fac00)
The buggy address belongs to the page:
page:eb65f4f5 refcount:1 mapcount:0 mapping: index:0x0
pfn:0x1c2f8
head:eb65f4f5 order:2 compound_mapcount:0 compound_pincount:0
flags: 0xfff0010200(slab|head)
raw: 00fff0010200 dead0100 dead0122 888010041140
raw: 80080008 0001
page dumped because: kasan: bad access detected
Memory state around the buggy address:
88801c2fae00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88801c2fae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88801c2faf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
88801c2faf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88801c2fb000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for
Re: [PATCH] i915: Fix DRM_I915_WERROR dependencies
Quoting Arnd Bergmann (2021-01-25 12:26:44) > From: Arnd Bergmann > > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails > to honor its dependencies: > > WARNING: unmet direct dependencies detected for DRM_I915_WERROR > Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && > !COMPILE_TEST [=y] > Selected by [m]: > - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] DRM_I915_DEBUG now depends on !COMPILE_TEST and EXPERT. -Chris
[PATCH] mmc: brcmstb: Fix sdhci_pltfm_suspend link error
From: Arnd Bergmann
sdhci_pltfm_suspend() is only available when CONFIG_PM_SLEEP
support is built into the kernel, which caused a regression
in a recent bugfix:
ld.lld: error: undefined symbol: sdhci_pltfm_suspend
>>> referenced by sdhci-brcmstb.c
>>> mmc/host/sdhci-brcmstb.o:(sdhci_brcmstb_shutdown) in archive
>>> drivers/built-in.a
Making the call conditional on the symbol fixes the link
error.
Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
Fixes: e7b5d63a82fe ("mmc: sdhci-brcmstb: Add shutdown callback")
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
It would be helpful if someone could test this to ensure that the
driver works correctly even when CONFIG_PM_SLEEP is disabled
---
drivers/mmc/host/sdhci-brcmstb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index f9780c65ebe9..dc9280b149db 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -314,7 +314,8 @@ static int sdhci_brcmstb_probe(struct platform_device *pdev)
static void sdhci_brcmstb_shutdown(struct platform_device *pdev)
{
- sdhci_pltfm_suspend(>dev);
+ if (IS_ENABLED(CONFIG_PM_SLEEP))
+ sdhci_pltfm_suspend(>dev);
}
MODULE_DEVICE_TABLE(of, sdhci_brcm_of_match);
--
2.29.2
Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS
On Mon, Jan 25, 2021 at 04:08:22PM +0800, Like Xu wrote: > Hi Peter, > > On 2021/1/22 17:56, Peter Zijlstra wrote: > > On Fri, Jan 15, 2021 at 10:51:38AM -0800, Sean Christopherson wrote: > > > On Fri, Jan 15, 2021, Andi Kleen wrote: > > > > > I'm asking about ucode/hardare. Is the "guest pebs buffer write -> > > > > > PEBS PMI" > > > > > guaranteed to be atomic? > > > > > > > > Of course not. > > > > > > So there's still a window where the guest could observe the bad counter > > > index, > > > correct? > > > > Guest could do a hypercall to fix up the DS area before it tries to read > > it I suppose. Or the HV could expose the index mapping and have the > > guest fix up it. > > A weird (malicious) guest would read unmodified PEBS records in the > guest PEBS buffer from other vCPUs without the need for hypercall or > index mapping from HV. > > Do you see any security issues on this host index leak window? > > > > > Adding a little virt crud on top shouldn't be too hard. > > > > The patches 13-17 in this version has modified the guest PEBS buffer > to correct the index mapping information in the guest PEBS records. Right, but given there is no atomicity between writing the DS area and triggering the PMI (as already established earlier in this thread), a malicious guest can already access this information, no?
[PATCH] arm64: kfence: fix header inclusion
From: Arnd Bergmann
Randconfig builds started warning about a missing function declaration
after set_memory_valid() is moved to a new file:
In file included from mm/kfence/core.c:26:
arch/arm64/include/asm/kfence.h:17:2: error: implicit declaration of function
'set_memory_valid' [-Werror,-Wimplicit-function-declaration]
Include the correct header again.
Fixes: 9e18ec3cfabd ("set_memory: allow querying whether set_direct_map_*() is
actually enabled")
Fixes: 204555ff8bd6 ("arm64, kfence: enable KFENCE for ARM64")
Signed-off-by: Arnd Bergmann
---
arch/arm64/include/asm/kfence.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h
index d061176d57ea..aa855c6a0ae6 100644
--- a/arch/arm64/include/asm/kfence.h
+++ b/arch/arm64/include/asm/kfence.h
@@ -8,7 +8,7 @@
#ifndef __ASM_KFENCE_H
#define __ASM_KFENCE_H
-#include
+#include
static inline bool arch_kfence_init_pool(void) { return true; }
--
2.29.2
Re: [PATCH 0/4] perf vendor events arm64: Some tidy-up/refactoring
On 25/01/2021 11:53, John Garry wrote: + Missed reviewers for https://lore.kernel.org/lkml/1611575600-2440-1-git-send-email-john.ga...@huawei.com/T/#u There is much event duplication in the common and uarch events for A76 and Ampere eMag support, so factor out into a common JSON. Since the wording for events may differ between CPU datasheet and the architecture reference manual, the current wording is kept. This is unless there are minor differences. In addition, event names are renamed to be same as architecture reference manual, to keep commonality. Also a minor fix is included for the Ampere eMag JSON. John Garry (4): perf vendor events arm64: Fix Ampere eMag event typo perf vendor events arm64: Add common and uarch event JSON perf vendor events arm64: Reference common and uarch events for Ampere eMag perf vendor events arm64: Reference common and uarch events for A76 .../arch/arm64/ampere/emag/branch.json| 8 +- .../arch/arm64/ampere/emag/bus.json | 5 +- .../arch/arm64/ampere/emag/cache.json | 58 +--- .../arch/arm64/ampere/emag/clock.json | 4 +- .../arch/arm64/ampere/emag/exception.json | 10 +- .../arch/arm64/ampere/emag/instruction.json | 34 +-- .../arch/arm64/ampere/emag/memory.json| 11 +- .../arch/arm64/arm/cortex-a76-n1/branch.json | 12 +- .../arch/arm64/arm/cortex-a76-n1/bus.json | 19 +- .../arch/arm64/arm/cortex-a76-n1/cache.json | 118 +++-- .../arm64/arm/cortex-a76-n1/exception.json| 10 +- .../arm64/arm/cortex-a76-n1/instruction.json | 45 +--- .../arch/arm64/arm/cortex-a76-n1/memory.json | 6 +- .../arch/arm64/arm/cortex-a76-n1/other.json | 4 +- .../arm64/arm/cortex-a76-n1/pipeline.json | 12 +- .../arm64/armv8-common-and-microarch.json | 248 ++ 16 files changed, 356 insertions(+), 248 deletions(-) create mode 100644 tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
Re: [PATCH 2/3] blk-mq: Always complete remote completions requests in softirq
On Sat, Jan 23, 2021 at 09:10:26PM +0100, Sebastian Andrzej Siewior wrote: > Controllers with multiple queues have their IRQ-handelers pinned to a > CPU. The core shouldn't need to complete the request on a remote CPU. > > Remove this case and always raise the softirq to complete the request. What about changing blk_mq_trigger_softirq to take a void * argument and thus removing __blk_mq_complete_request_remote entirely?
[PATCH v2 net-next] net: core: devlink: add 'dropped' stats field for DROP trap action
Whenever query statistics is issued for trap with DROP action,
devlink subsystem would also fill-in statistics 'dropped' field.
In case if device driver did't register callback for hard drop
statistics querying, 'dropped' field will be omitted and not filled.
Add trap_drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
Signed-off-by: Oleksandr Mazur
---
V2:
1) Change commit description / subject.
2) Remove HARD_DROP action.
3) Remove devlink UAPI changes.
4) Rename hard statistics get callback to be 'trap_drop_counter_get'
5) Make callback get called for existing trap action - DROP:
whenever statistics for trap with DROP action is queried,
devlink subsystem would call-in callback to get stats from HW;
6) Add changes to the netdevsim support implemented changes
(as well as changes to make it possible to test netdevsim with
these changes).
7) Add new test cases to the netdevsim's kselftests to test new
changes provided with this patchset;
Test-results:
# selftests: drivers/net/netdevsim: devlink_trap.sh
# TEST: Initialization[ OK ]
# TEST: Trap action [ OK ]
# TEST: Trap metadata [ OK ]
# TEST: Non-existing trap [ OK ]
# TEST: Non-existing trap action [ OK ]
# TEST: Trap statistics [ OK ]
# TEST: Trap group action [ OK ]
# TEST: Non-existing trap group [ OK ]
# TEST: Trap group statistics [ OK ]
# TEST: Trap policer [ OK ]
# TEST: Trap policer binding [ OK ]
# TEST: Port delete [ OK ]
# TEST: Device delete [ OK ]
ok 1 selftests: drivers/net/netdevsim: devlink_trap.sh
drivers/net/netdevsim/dev.c | 21 +++
drivers/net/netdevsim/netdevsim.h | 1 +
include/net/devlink.h | 10
net/core/devlink.c| 55 +--
.../drivers/net/netdevsim/devlink_trap.sh | 10
.../selftests/net/forwarding/devlink_lib.sh | 26 +
6 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index 816af1f55e2c..1fc8c7a2a1e3 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -231,6 +231,9 @@ static int nsim_dev_debugfs_init(struct nsim_dev *nsim_dev)
debugfs_create_bool("fail_trap_policer_counter_get", 0600,
nsim_dev->ddir,
_dev->fail_trap_policer_counter_get);
+ debugfs_create_bool("fail_trap_drop_counter_get", 0600,
+ nsim_dev->ddir,
+ _dev->fail_trap_drop_counter_get);
nsim_udp_tunnels_debugfs_create(nsim_dev);
return 0;
}
@@ -416,6 +419,7 @@ struct nsim_trap_data {
struct delayed_work trap_report_dw;
struct nsim_trap_item *trap_items_arr;
u64 *trap_policers_cnt_arr;
+ u64 trap_hard_drop_cnt;
struct nsim_dev *nsim_dev;
spinlock_t trap_lock; /* Protects trap_items_arr */
};
@@ -892,6 +896,22 @@ nsim_dev_devlink_trap_policer_counter_get(struct devlink
*devlink,
return 0;
}
+int nsim_dev_devlink_trap_drop_counter_get(struct devlink *devlink,
+ const struct devlink_trap *trap,
+ u64 *p_drops)
+{
+ struct nsim_dev *nsim_dev = devlink_priv(devlink);
+ u64 *cnt;
+
+ if (nsim_dev->fail_trap_drop_counter_get)
+ return -EINVAL;
+
+ cnt = _dev->trap_data->trap_hard_drop_cnt;
+ *p_drops = (*cnt)++;
+
+ return 0;
+}
+
static const struct devlink_ops nsim_dev_devlink_ops = {
.supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT
|
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK,
@@ -905,6 +925,7 @@ static const struct devlink_ops nsim_dev_devlink_ops = {
.trap_group_set = nsim_dev_devlink_trap_group_set,
.trap_policer_set = nsim_dev_devlink_trap_policer_set,
.trap_policer_counter_get = nsim_dev_devlink_trap_policer_counter_get,
+ .trap_drop_counter_get = nsim_dev_devlink_trap_drop_counter_get,
};
#define NSIM_DEV_MAX_MACS_DEFAULT 32
diff --git a/drivers/net/netdevsim/netdevsim.h
b/drivers/net/netdevsim/netdevsim.h
index 48163c5f2ec9..b0d8ec7d09a5 100644
[PATCH] amdgpu: fix clang build warning
From: Arnd Bergmann
clang warns about the -mhard-float command line arguments
on architectures that do not support this:
clang: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Move this into the gcc-specific arguments.
Fixes: e77165bf7b02 ("drm/amd/display: Add DCN3 blocks to Makefile")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 --
drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 3 ++-
drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 3 ++-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
index c20331eb62e0..dfd77b3cc84d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
@@ -32,8 +32,8 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o dcn30_dpp.o
dcn30_optc.o \
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -msse
endif
ifdef CONFIG_PPC64
@@ -45,6 +45,8 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o += -mhard-float
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
index 3ca7d911d25c..09264716d1dc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
@@ -14,7 +14,7 @@ DCN301 = dcn301_init.o dcn301_resource.o dcn301_dccg.o \
dcn301_dio_link_encoder.o dcn301_hwseq.o dcn301_panel_cntl.o
dcn301_hubbub.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -25,6 +25,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
index 8d4924b7dc22..101620a8867a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
@@ -13,7 +13,7 @@
DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -24,6 +24,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mhard-float
endif
ifdef CONFIG_X86
--
2.29.2
Re: [PATCH v2 0/4] MIPS: process: Some fixes and improvements about get_frame_info()
On Thu, Jan 21, 2021 at 01:31:34PM +0800, Jinyang He wrote: > Not familiar with microMIPS. Not test on microMIPS. > > Changelog v2: > - Thanks to Thomas for suggesting that remove and sort header includes. > [PATCH 1/4] for details. > - Thanks to Jiaxun for test v1 and told me it stuck at loading init. > I mistakenly thought that r_format.rs and pool32a_format.rs are the same. > See [PATCH 4/4] for details. > > Jinyang He (4): > MIPS: process: Remove unnecessary headers inclusion > MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op > MIPS: Fix get_frame_info() handing of function size > MIPS: Add is_jr_ra_ins() to end the loop early > > arch/mips/kernel/process.c | 87 > ++ > 1 file changed, 50 insertions(+), 37 deletions(-) I've re-added linux/random.h and asm/mips-cps.h in your first patch and applied all four patches to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[RFC 3/3] thunderbolt: build kunit tests without structleak plugin
From: Arnd Bergmann
The structleak plugin causes the stack frame size to grow immensely:
drivers/thunderbolt/test.c:1529:1: error: the frame size of 1176 bytes is
larger than 1024 bytes [-Werror=frame-larger-than=]
Turn it off in this file.
Signed-off-by: Arnd Bergmann
---
drivers/thunderbolt/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 7aa48f6c41d9..e571c0495a84 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -7,6 +7,7 @@ thunderbolt-objs += nvm.o retimer.o quirks.o
thunderbolt-${CONFIG_ACPI} += acpi.o
thunderbolt-$(CONFIG_DEBUG_FS) += debugfs.o
thunderbolt-${CONFIG_USB4_KUNIT_TEST} += test.o
+CFLAGS_REMOVE_test.o += -fplugin-arg-structleak_plugin-byref
-fplugin-arg-structleak_plugin-byref-all
thunderbolt_dma_test-${CONFIG_USB4_DMA_TEST} += dma_test.o
obj-$(CONFIG_USB4_DMA_TEST) += thunderbolt_dma_test.o
--
2.29.2
[RFC 2/3] drivers/base: build kunit tests without structleak plugin
From: Arnd Bergmann The structleak plugin causes the stack frame size to grow immensely: drivers/base/test/property-entry-test.c: In function 'pe_test_reference': drivers/base/test/property-entry-test.c:481:1: error: the frame size of 2640 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] 481 | } | ^ drivers/base/test/property-entry-test.c: In function 'pe_test_uints': drivers/base/test/property-entry-test.c:99:1: error: the frame size of 2592 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Turn it off in this file. Signed-off-by: Arnd Bergmann --- drivers/base/test/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/test/Makefile b/drivers/base/test/Makefile index 3ca56367c84b..2f15fae8625f 100644 --- a/drivers/base/test/Makefile +++ b/drivers/base/test/Makefile @@ -2,3 +2,4 @@ obj-$(CONFIG_TEST_ASYNC_DRIVER_PROBE) += test_async_driver_probe.o obj-$(CONFIG_KUNIT_DRIVER_PE_TEST) += property-entry-test.o +CFLAGS_REMOVE_property-entry-test.o += -fplugin-arg-structleak_plugin-byref -fplugin-arg-structleak_plugin-byref-all -- 2.29.2
Re: [PATCH v2 04/16] rpmsg: ctrl: implement the ioctl function to create device
Hi Mathieu,
On 1/22/21 9:59 PM, Mathieu Poirier wrote:
> On Fri, Jan 22, 2021 at 02:05:27PM +0100, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 1/22/21 12:52 AM, Mathieu Poirier wrote:
>>> On Tue, Dec 22, 2020 at 11:57:14AM +0100, Arnaud Pouliquen wrote:
Implement the ioctl function that parses the list of
rpmsg drivers registered to create an associated device.
To be ISO user API, in a first step, the driver_override
is only allowed for the RPMsg raw service, supported by the
rpmsg_char driver.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_ctrl.c | 43 --
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_ctrl.c b/drivers/rpmsg/rpmsg_ctrl.c
index 065e2e304019..8381b5b2b794 100644
--- a/drivers/rpmsg/rpmsg_ctrl.c
+++ b/drivers/rpmsg/rpmsg_ctrl.c
@@ -56,12 +56,51 @@ static int rpmsg_ctrl_dev_open(struct inode *inode,
struct file *filp)
return 0;
}
+static const char *rpmsg_ctrl_get_drv_name(u32 service)
+{
+ struct rpmsg_ctl_info *drv_info;
+
+ list_for_each_entry(drv_info, _drv_list, node) {
+ if (drv_info->ctrl->service == service)
+ return drv_info->ctrl->drv_name;
+ }
+
>>>
>>> I'm unsure about the above... To me this looks like what the .match()
>>> function
>>> of a bus would do. And when I read Bjorn's comment he brought up the
>>> auxiliary_bus. I don't know about the auxiliary_bus but it is worth looking
>>> into. Registering with a bus would streamline a lot of the code in this
>>> patchset.
>>
>> As answered Bjorn, we already have the RPMsg bus to manage the rpmsg devices.
>> Look like duplication from my POV, except if the IOCTL does not manage
>> channel
>> but only endpoint.
>>
>> In my design I considered that the rpmsg_ctrl creates a channel associated
>> to a
>> rpmsg_device such as the RPMsg ns_announcement.
>>
>> Based on this assumption, if we implement the auxiliary_bus (or other) for
>> the
>> rpmsg_ctrl a RPMsg driver will have to manage the probe by rpmsg_bus and by
>> the
>> auxillary bus. The probe from the auxiliary bus would lead to the creation
>> of an
>> RPMsg device on the rpmsg_bus, so a duplication with cross dependencies and
>> would probably make tricky the remove part.
>>
>> That said, I think the design depends on the functionality that should be
>> implemented in the rpmsg_ctrl. Here is an alternative approach based on the
>> auxiliary bus, which I'm starting to think about:
>>
>> The current approach of the rpmsg_char driver is to use the IOCTRL interface
>> to
>> instantiate a cdev with an endpoint (the RPMsg device is associated with the
>> ioctl dev). This would correspond to the use of an auxiliary bus to manage
>> local
>> endpoint creations.
>>
>> We could therefore consider an RPMsg name service based on an RPmsg device.
>> This
>> RPMsg device would register a kind of "RPMsg service endpoint" driver on the
>> auxiliary rpmsg_ioctl bus.
>> The rpmsg_ctrl will be used to instantiate the endpoints for this RPMsg
>> device.
>> on user application request the rpmsg_ctrl will call the appropriate
>> auxiliary
>> device to create an endpoint.
>>
>> If we consider that one objective of this series is to allow application to
>> initiate the communication with the remote processor, so to be able to
>> initiate
>> the service (ns announcement sent to the remote processor).
>> This implies that:
>> -either the RPMsg device has been probed first by a remote ns announcement
>> or by
>> a Linux kernel driver using the "driver_override", to register an auxiliary
>> device. In this case an endpoint will be created associated to the RPMsg
>> service
>> - or create a RPMsg device on first ioctl endpoint creation request, if it
>> does
>> not exist (that could trig a NS announcement to remote processor).
>>
>> But I'm not sure that this approach would work with QCOM RPMsg backends...
>>
>
> I don't think there is a way forward with this set without a clear
> understanding
> of the Glink and SMD drivers. I have already spent a fair amount of time in
> the
> Glink driver and will continue on Monday with SMD.
>
>>>
>>> I'm out of time for today - I will continue tomorrow.
>>
>> It seems to me that the main point to step forward is to clarify the global
>> design and features of the rpmsg-ctrl.
>> Depending on the decision taken, this series could be trashed and rewritten
>> from
>> a blank page...To not lost to much time on the series don't hesitate to limit
>> the review to the minimum.
>>
>
> I doubt you will ever get clear guidelines on the whole solution. I will get
> back to you once I am done with the SMD driver, which should be in the
> latter part of next week.
Thanks for your time past on this topic!
I don't expect a clear guidance but that we clarify the objective of this RPMsg
[RFC 1/3] bitfield: build kunit tests without structleak plugin
From: Arnd Bergmann The structleak plugin causes the stack frame size to grow immensely: lib/bitfield_kunit.c: In function 'test_bitfields_constants': lib/bitfield_kunit.c:93:1: error: the frame size of 7440 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Turn it off in this file. Signed-off-by: Arnd Bergmann --- lib/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/Makefile b/lib/Makefile index b5307d3eec1a..6a7300f0f02f 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -348,6 +348,7 @@ obj-$(CONFIG_PLDMFW) += pldmfw/ # KUnit tests obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o +CFLAGS_REMOVE_bitfield_kunit.o += -fplugin-arg-structleak_plugin-byref -fplugin-arg-structleak_plugin-byref-all obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o obj-$(CONFIG_BITS_TEST) += test_bits.o -- 2.29.2
[PATCH] blk: wbt: remove unused parameter from wbt_should_throttle
From: Lei Chen
The first parameter rwb is not used for this function.
So just remove it.
Signed-off-by: Lei Chen
---
block/blk-wbt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index 0321ca8..42aed01 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -518,7 +518,7 @@ static void __wbt_wait(struct rq_wb *rwb, enum wbt_flags
wb_acct,
rq_qos_wait(rqw, , wbt_inflight_cb, wbt_cleanup_cb);
}
-static inline bool wbt_should_throttle(struct rq_wb *rwb, struct bio *bio)
+static inline bool wbt_should_throttle(struct bio *bio)
{
switch (bio_op(bio)) {
case REQ_OP_WRITE:
@@ -545,7 +545,7 @@ static enum wbt_flags bio_to_wbt_flags(struct rq_wb *rwb,
struct bio *bio)
if (bio_op(bio) == REQ_OP_READ) {
flags = WBT_READ;
- } else if (wbt_should_throttle(rwb, bio)) {
+ } else if (wbt_should_throttle(bio)) {
if (current_is_kswapd())
flags |= WBT_KSWAPD;
if (bio_op(bio) == REQ_OP_DISCARD)
--
1.8.3.1
[RFC PATCH v3 09/13] virtio/vsock: add SEQPACKET receive logic
This modifies current receive logic for SEQPACKET support:
1) Inserts 'SEQ_BEGIN' packet to socket's rx queue.
2) Inserts 'RW' packet to socket's rx queue, but without merging with
buffer of last packet in queue.
3) Performs check for packet and socket types on receive(if mismatch,
then reset connection).
Signed-off-by: Arseny Krasnov
---
net/vmw_vsock/virtio_transport_common.c | 79 ++---
1 file changed, 58 insertions(+), 21 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c
b/net/vmw_vsock/virtio_transport_common.c
index dcce35d7b462..90f9feef9d8f 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -397,6 +397,14 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
return err;
}
+static u16 virtio_transport_get_type(struct sock *sk)
+{
+ if (sk->sk_type == SOCK_STREAM)
+ return VIRTIO_VSOCK_TYPE_STREAM;
+ else
+ return VIRTIO_VSOCK_TYPE_SEQPACKET;
+}
+
static inline void virtio_transport_del_n_free_pkt(struct virtio_vsock_pkt
*pkt)
{
list_del(>list);
@@ -1050,39 +1058,49 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
struct virtio_vsock_pkt *pkt)
{
struct virtio_vsock_sock *vvs = vsk->trans;
- bool can_enqueue, free_pkt = false;
+ bool free_pkt = false;
pkt->len = le32_to_cpu(pkt->hdr.len);
pkt->off = 0;
spin_lock_bh(>rx_lock);
- can_enqueue = virtio_transport_inc_rx_pkt(vvs, pkt);
- if (!can_enqueue) {
+ if (!virtio_transport_inc_rx_pkt(vvs, pkt)) {
free_pkt = true;
goto out;
}
- /* Try to copy small packets into the buffer of last packet queued,
-* to avoid wasting memory queueing the entire buffer with a small
-* payload.
-*/
- if (pkt->len <= GOOD_COPY_LEN && !list_empty(>rx_queue)) {
- struct virtio_vsock_pkt *last_pkt;
+ switch (le16_to_cpu(pkt->hdr.type)) {
+ case VIRTIO_VSOCK_TYPE_STREAM: {
+ /* Try to copy small packets into the buffer of last packet
queued,
+* to avoid wasting memory queueing the entire buffer with a
small
+* payload.
+*/
+ if (pkt->len <= GOOD_COPY_LEN && !list_empty(>rx_queue)) {
+ struct virtio_vsock_pkt *last_pkt;
- last_pkt = list_last_entry(>rx_queue,
- struct virtio_vsock_pkt, list);
+ last_pkt = list_last_entry(>rx_queue,
+ struct virtio_vsock_pkt,
list);
- /* If there is space in the last packet queued, we copy the
-* new packet in its buffer.
-*/
- if (pkt->len <= last_pkt->buf_len - last_pkt->len) {
- memcpy(last_pkt->buf + last_pkt->len, pkt->buf,
- pkt->len);
- last_pkt->len += pkt->len;
- free_pkt = true;
- goto out;
+ /* If there is space in the last packet queued, we copy
the
+* new packet in its buffer.
+*/
+ if (pkt->len <= last_pkt->buf_len - last_pkt->len) {
+ memcpy(last_pkt->buf + last_pkt->len, pkt->buf,
+ pkt->len);
+ last_pkt->len += pkt->len;
+ free_pkt = true;
+ goto out;
+ }
}
+
+ break;
+ }
+ case VIRTIO_VSOCK_TYPE_SEQPACKET: {
+ break;
+ }
+ default:
+ goto out;
}
list_add_tail(>list, >rx_queue);
@@ -1101,6 +1119,14 @@ virtio_transport_recv_connected(struct sock *sk,
int err = 0;
switch (le16_to_cpu(pkt->hdr.op)) {
+ case VIRTIO_VSOCK_OP_SEQ_BEGIN: {
+ struct virtio_vsock_sock *vvs = vsk->trans;
+
+ spin_lock_bh(>rx_lock);
+ list_add_tail(>list, >rx_queue);
+ spin_unlock_bh(>rx_lock);
+ return err;
+ }
case VIRTIO_VSOCK_OP_RW:
virtio_transport_recv_enqueue(vsk, pkt);
sk->sk_data_ready(sk);
@@ -1247,6 +1273,12 @@ virtio_transport_recv_listen(struct sock *sk, struct
virtio_vsock_pkt *pkt,
return 0;
}
+static bool virtio_transport_valid_type(u16 type)
+{
+ return (type == VIRTIO_VSOCK_TYPE_STREAM) ||
+ (type == VIRTIO_VSOCK_TYPE_SEQPACKET);
+}
+
/* We are under the virtio-vsock's vsock->rx_lock or vhost-vsock's vq->mutex
* lock.
*/
@@ -1272,7 +1304,7 @@ void virtio_transport_recv_pkt(struct virtio_transport *t,
Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP
Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote: >On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote: >> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote: >> > Add new trap action HARD_DROP, which can be used by the >> > drivers to register traps, where it's impossible to get >> > packet reported to the devlink subsystem by the device >> > driver, because it's impossible to retrieve dropped packet >> > from the device itself. >> > In order to use this action, driver must also register >> > additional devlink operation - callback that is used >> > to retrieve number of packets that have been dropped by >> > the device. >> >> Are these global statistics about number of packets the hardware dropped >> for a specific reason or are these per-port statistics? >> >> It's a creative use of devlink-trap interface, but I think it makes >> sense. Better to re-use an existing interface than creating yet another >> one. > >Not sure if I agree, if we can't trap why is it a trap? >It's just a counter. >+1 Device might be unable to trap only the 'DROP' packets, and this information should be transparent for the user. I agree on the statement, that new action might be an overhead. I could continue on with the solution Ido Schimmel proposed: since no new action would be needed and no UAPI changes are required, i could simply do the dropped statistics (additional field) output added upon trap stats queiring. (In case if driver registerd callback, of course; and do so only for DROP actions)
[RFC v3 net-next] net: core: devlink: add 'dropped' stats field for DROP trap action
Whenever query statistics is issued for trap with DROP action,
devlink subsystem would also fill-in statistics 'dropped' field.
In case if device driver did't register callback for hard drop
statistics querying, 'dropped' field will be omitted and not filled.
Add trap_drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
Signed-off-by: Oleksandr Mazur
---
V3:
1) Mark subject as RFC instead of PATCH.
V2:
1) Change commit description / subject.
2) Remove HARD_DROP action.
3) Remove devlink UAPI changes.
4) Rename hard statistics get callback to be 'trap_drop_counter_get'
5) Make callback get called for existing trap action - DROP:
whenever statistics for trap with DROP action is queried,
devlink subsystem would call-in callback to get stats from HW;
6) Add changes to the netdevsim support implemented changes
(as well as changes to make it possible to test netdevsim with
these changes).
7) Add new test cases to the netdevsim's kselftests to test new
changes provided with this patchset;
Test-results:
# selftests: drivers/net/netdevsim: devlink_trap.sh
# TEST: Initialization[ OK ]
# TEST: Trap action [ OK ]
# TEST: Trap metadata [ OK ]
# TEST: Non-existing trap [ OK ]
# TEST: Non-existing trap action [ OK ]
# TEST: Trap statistics [ OK ]
# TEST: Trap group action [ OK ]
# TEST: Non-existing trap group [ OK ]
# TEST: Trap group statistics [ OK ]
# TEST: Trap policer [ OK ]
# TEST: Trap policer binding [ OK ]
# TEST: Port delete [ OK ]
# TEST: Device delete [ OK ]
ok 1 selftests: drivers/net/netdevsim: devlink_trap.sh
drivers/net/netdevsim/dev.c | 21 +++
drivers/net/netdevsim/netdevsim.h | 1 +
include/net/devlink.h | 10
net/core/devlink.c| 55 +--
.../drivers/net/netdevsim/devlink_trap.sh | 10
.../selftests/net/forwarding/devlink_lib.sh | 26 +
6 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index 816af1f55e2c..1fc8c7a2a1e3 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -231,6 +231,9 @@ static int nsim_dev_debugfs_init(struct nsim_dev *nsim_dev)
debugfs_create_bool("fail_trap_policer_counter_get", 0600,
nsim_dev->ddir,
_dev->fail_trap_policer_counter_get);
+ debugfs_create_bool("fail_trap_drop_counter_get", 0600,
+ nsim_dev->ddir,
+ _dev->fail_trap_drop_counter_get);
nsim_udp_tunnels_debugfs_create(nsim_dev);
return 0;
}
@@ -416,6 +419,7 @@ struct nsim_trap_data {
struct delayed_work trap_report_dw;
struct nsim_trap_item *trap_items_arr;
u64 *trap_policers_cnt_arr;
+ u64 trap_hard_drop_cnt;
struct nsim_dev *nsim_dev;
spinlock_t trap_lock; /* Protects trap_items_arr */
};
@@ -892,6 +896,22 @@ nsim_dev_devlink_trap_policer_counter_get(struct devlink
*devlink,
return 0;
}
+int nsim_dev_devlink_trap_drop_counter_get(struct devlink *devlink,
+ const struct devlink_trap *trap,
+ u64 *p_drops)
+{
+ struct nsim_dev *nsim_dev = devlink_priv(devlink);
+ u64 *cnt;
+
+ if (nsim_dev->fail_trap_drop_counter_get)
+ return -EINVAL;
+
+ cnt = _dev->trap_data->trap_hard_drop_cnt;
+ *p_drops = (*cnt)++;
+
+ return 0;
+}
+
static const struct devlink_ops nsim_dev_devlink_ops = {
.supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT
|
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK,
@@ -905,6 +925,7 @@ static const struct devlink_ops nsim_dev_devlink_ops = {
.trap_group_set = nsim_dev_devlink_trap_group_set,
.trap_policer_set = nsim_dev_devlink_trap_policer_set,
.trap_policer_counter_get = nsim_dev_devlink_trap_policer_counter_get,
+ .trap_drop_counter_get = nsim_dev_devlink_trap_drop_counter_get,
};
#define NSIM_DEV_MAX_MACS_DEFAULT 32
diff --git a/drivers/net/netdevsim/netdevsim.h
[PATCH] PCI: endpoint: Select configfs dependency
From: Arnd Bergmann
The newly added pci-epf-ntb driver uses configfs, which
causes a link failure when that is disabled at compile-time:
arm-linux-gnueabi-ld: drivers/pci/endpoint/functions/pci-epf-ntb.o: in function
`epf_ntb_add_cfs':
pci-epf-ntb.c:(.text+0x954): undefined reference to
`config_group_init_type_name'
Add a 'select' statement to Kconfig to ensure it's always there,
which is the common way to enable it for other configfs users.
Fixes: 7dc64244f9e9 ("PCI: endpoint: Add EP function driver to provide NTB
functionality")
Signed-off-by: Arnd Bergmann
---
drivers/pci/endpoint/functions/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/endpoint/functions/Kconfig
b/drivers/pci/endpoint/functions/Kconfig
index 24bfb2af65a1..5d35fcd613ef 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -16,6 +16,7 @@ config PCI_EPF_TEST
config PCI_EPF_NTB
tristate "PCI Endpoint NTB driver"
depends on PCI_ENDPOINT
+ select CONFIGFS_FS
help
Select this configuration option to enable the NTB driver
for PCI Endpoint. NTB driver implements NTB controller
--
2.29.2
Re: [PATCH] kasan: export kasan_poison
On 1/25/21 11:28 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The unit test module fails to build after adding a reference
> to kasan_poison:
>
> ERROR: modpost: "kasan_poison" [lib/test_kasan.ko] undefined!
>
> Export this symbol to make it available to loadable modules.
>
> Fixes: b9b322c2bba9 ("kasan: add match-all tag tests")
> Signed-off-by: Arnd Bergmann
Thanks I just stumbled on the same issue ;)
Reviewed-by: Vincenzo Frascino
> ---
> mm/kasan/shadow.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index de6b3f074742..32e7a5c148e6 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -94,6 +94,7 @@ void kasan_poison(const void *address, size_t size, u8
> value)
>
> __memset(shadow_start, value, shadow_end - shadow_start);
> }
> +EXPORT_SYMBOL_GPL(kasan_poison);
>
> void kasan_unpoison(const void *address, size_t size)
> {
>
--
Regards,
Vincenzo
[PATCH] i915: Fix DRM_I915_WERROR dependencies
From: Arnd Bergmann
CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
to honor its dependencies:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
Change the 'select' to a conditional one that doesn't trigger -Werror
warnings for allmodconfig builds and other compile tests.
Fixes: 4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/Kconfig.debug | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index be76054c01d8..97793b28d007 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -31,9 +31,9 @@ config DRM_I915_DEBUG
select DRM_DEBUG_SELFTEST
select DMABUF_SELFTESTS
select SW_SYNC # signaling validation framework (igt/syncobj*)
- select DRM_I915_WERROR
- select DRM_I915_DEBUG_GEM
- select DRM_I915_DEBUG_GEM_ONCE
+ select DRM_I915_WERROR if !COMPILE_TEST
+ select DRM_I915_DEBUG_GEM if !COMPILE_TEST
+ select DRM_I915_DEBUG_GEM_ONCE if !COMPILE_TEST
select DRM_I915_DEBUG_MMIO
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
--
2.29.2
Re: [PATCH v3 0/5] Scan for an idle sibling in a single pass
On 2021/1/25 17:04, Mel Gorman wrote: > On Mon, Jan 25, 2021 at 12:29:47PM +0800, Li, Aubrey wrote: > hackbench -l 2560 -g 1 on 8 cores arm64 > v5.11-rc4 : 1.355 (+/- 7.96) > + sis improvement : 1.923 (+/- 25%) > + the patch below : 1.332 (+/- 4.95) > > hackbench -l 2560 -g 256 on 8 cores arm64 > v5.11-rc4 : 2.116 (+/- 4.62%) > + sis improvement : 2.216 (+/- 3.84%) > + the patch below : 2.113 (+/- 3.01%) > >> >> 4 benchmarks reported out during weekend, with patch 3 on a x86 4s system >> with 24 cores per socket and 2 HT per core, total 192 CPUs. >> >> It looks like mid-load has notable changes on my side: >> - netperf 50% num of threads in TCP mode has 27.25% improved >> - tbench 50% num of threads has 9.52% regression >> > > It's interesting that patch 3 would make any difference on x64 given that > it's SMT2. The scan depth should have been similar. It's somewhat expected > that it will not be a universal win, particularly once the utilisation > is high enough to spill over in sched domains (25%, 50%, 75% utilisation > being interesting on 4-socket systems). In such cases, double scanning can > still show improvements for workloads that idle rapidly like tbench and > hackbench even though it's expensive. The extra scanning gives more time > for a CPU to go idle enough to be selected which can improve throughput > but at the cost of wake-up latency, aha, sorry for the confusion. Since you and Vincent discussed to drop patch3, I just mentioned I tested 5 patches with patch3, not patch3 alone. > > Hopefully v4 can be tested as well which is now just a single scan. > Sure, may I know the baseline of v4? Thanks, -Aubrey
[PATCH v3] x86/perf: Use static_call for x86_pmu.guest_get_msrs
Clean up that CONFIG_RETPOLINE crud and replace the
indirect call x86_pmu.guest_get_msrs with static_call().
Suggested-by: Peter Zijlstra (Intel)
Reported-by: kernel test robot
Signed-off-by: Like Xu
---
v2->v3 Changelog:
- fix compiler warning from [-Wmissing-prototypes]
v1->v2 Changelog:
- fix compiler error from redifinition
arch/x86/events/core.c| 20
arch/x86/events/intel/core.c | 20
arch/x86/include/asm/perf_event.h | 6 +-
3 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index e37de298a495..cf0a52c80408 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -81,6 +81,8 @@ DEFINE_STATIC_CALL_NULL(x86_pmu_swap_task_ctx,
*x86_pmu.swap_task_ctx);
DEFINE_STATIC_CALL_NULL(x86_pmu_drain_pebs, *x86_pmu.drain_pebs);
DEFINE_STATIC_CALL_NULL(x86_pmu_pebs_aliases, *x86_pmu.pebs_aliases);
+DEFINE_STATIC_CALL_NULL(x86_pmu_guest_get_msrs, *x86_pmu.guest_get_msrs);
+
u64 __read_mostly hw_cache_event_ids
[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
@@ -665,6 +667,12 @@ void x86_pmu_disable_all(void)
}
}
+struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
+{
+ return static_call(x86_pmu_guest_get_msrs)(nr);
+}
+EXPORT_SYMBOL_GPL(perf_guest_get_msrs);
+
/*
* There may be PMI landing after enabled=0. The PMI hitting could be before or
* after disable_all.
@@ -1923,6 +1931,8 @@ static void x86_pmu_static_call_update(void)
static_call_update(x86_pmu_drain_pebs, x86_pmu.drain_pebs);
static_call_update(x86_pmu_pebs_aliases, x86_pmu.pebs_aliases);
+
+ static_call_update(x86_pmu_guest_get_msrs, x86_pmu.guest_get_msrs);
}
static void _x86_pmu_read(struct perf_event *event)
@@ -1930,6 +1940,13 @@ static void _x86_pmu_read(struct perf_event *event)
x86_perf_event_update(event);
}
+static inline struct perf_guest_switch_msr *
+perf_guest_get_msrs_nop(int *nr)
+{
+ *nr = 0;
+ return NULL;
+}
+
static int __init init_hw_perf_events(void)
{
struct x86_pmu_quirk *quirk;
@@ -2001,6 +2018,9 @@ static int __init init_hw_perf_events(void)
if (!x86_pmu.read)
x86_pmu.read = _x86_pmu_read;
+ if (!x86_pmu.guest_get_msrs)
+ x86_pmu.guest_get_msrs = perf_guest_get_msrs_nop;
+
x86_pmu_static_call_update();
/*
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index d4569bfa83e3..93adf53cce5f 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3680,26 +3680,6 @@ static int intel_pmu_hw_config(struct perf_event *event)
return 0;
}
-#ifdef CONFIG_RETPOLINE
-static struct perf_guest_switch_msr *core_guest_get_msrs(int *nr);
-static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr);
-#endif
-
-struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
-{
-#ifdef CONFIG_RETPOLINE
- if (x86_pmu.guest_get_msrs == intel_guest_get_msrs)
- return intel_guest_get_msrs(nr);
- else if (x86_pmu.guest_get_msrs == core_guest_get_msrs)
- return core_guest_get_msrs(nr);
-#endif
- if (x86_pmu.guest_get_msrs)
- return x86_pmu.guest_get_msrs(nr);
- *nr = 0;
- return NULL;
-}
-EXPORT_SYMBOL_GPL(perf_guest_get_msrs);
-
static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr)
{
struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index b9a7fd0a27e2..e2a4c785e4e3 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -483,11 +483,7 @@ static inline void perf_check_microcode(void) { }
extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
extern int x86_perf_get_lbr(struct x86_pmu_lbr *lbr);
#else
-static inline struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
-{
- *nr = 0;
- return NULL;
-}
+struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
static inline int x86_perf_get_lbr(struct x86_pmu_lbr *lbr)
{
return -1;
--
2.29.2
[PATCH v3] iio: adc: stm32-adc: enable timestamping for non-DMA usage
For non-DMA usage, we have an easy way to associate a timestamp with a
sample: iio_pollfunc_store_time stores a timestamp in the primary
trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
to push out the buffer along with the timestamp.
For this to work, the driver needs to register an IIO_TIMESTAMP channel.
Do this.
For DMA, it's not as easy, because we don't push the buffers out of
stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
a tasklet scheduled after a DMA completion.
Preferably, the DMA controller would copy us the timestamp into that buffer
as well. Until this is implemented, restrict timestamping support to
only PIO. For low-frequency sampling, PIO is probably good enough.
Cc: Holger Assmann
Acked-by: Fabrice Gasnier
Signed-off-by: Ahmad Fatoum
---
v2 -> v3:
- explicitly specify alignment (Jonathan)
- increase buffer size to hold additional timestamp
v1 -> v2:
- Added comment about timestamping being PIO only (Fabrice)
- Added missing DMA resource clean up in error path (Fabrice)
- Added Fabrice's Acked-by
---
drivers/iio/adc/stm32-adc.c | 39 +
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index c067c994dae2..ab2f440d7afb 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -177,7 +177,7 @@ struct stm32_adc_cfg {
* @offset:ADC instance register offset in ADC block
* @cfg: compatible configuration data
* @completion:end of single conversion completion
- * @buffer:data buffer
+ * @buffer:data buffer + 8 bytes for timestamp if enabled
* @clk: clock for this adc instance
* @irq: interrupt for this adc instance
* @lock: spinlock
@@ -200,7 +200,7 @@ struct stm32_adc {
u32 offset;
const struct stm32_adc_cfg *cfg;
struct completion completion;
- u16 buffer[STM32_ADC_MAX_SQ];
+ u16 buffer[STM32_ADC_MAX_SQ + 8] __aligned(8);
struct clk *clk;
int irq;
spinlock_t lock; /* interrupt lock */
@@ -1718,7 +1718,7 @@ static void stm32_adc_chan_init_one(struct iio_dev
*indio_dev,
}
}
-static int stm32_adc_chan_of_init(struct iio_dev *indio_dev)
+static int stm32_adc_chan_of_init(struct iio_dev *indio_dev, bool timestamping)
{
struct device_node *node = indio_dev->dev.of_node;
struct stm32_adc *adc = iio_priv(indio_dev);
@@ -1766,6 +1766,9 @@ static int stm32_adc_chan_of_init(struct iio_dev
*indio_dev)
return -EINVAL;
}
+ if (timestamping)
+ num_channels++;
+
channels = devm_kcalloc(_dev->dev, num_channels,
sizeof(struct iio_chan_spec), GFP_KERNEL);
if (!channels)
@@ -1816,6 +1819,19 @@ static int stm32_adc_chan_of_init(struct iio_dev
*indio_dev)
stm32_adc_smpr_init(adc, channels[i].channel, smp);
}
+ if (timestamping) {
+ struct iio_chan_spec *timestamp = [scan_index];
+
+ timestamp->type = IIO_TIMESTAMP;
+ timestamp->channel = -1;
+ timestamp->scan_index = scan_index;
+ timestamp->scan_type.sign = 's';
+ timestamp->scan_type.realbits = 64;
+ timestamp->scan_type.storagebits = 64;
+
+ scan_index++;
+ }
+
indio_dev->num_channels = scan_index;
indio_dev->channels = channels;
@@ -1875,6 +1891,7 @@ static int stm32_adc_probe(struct platform_device *pdev)
struct device *dev = >dev;
irqreturn_t (*handler)(int irq, void *p) = NULL;
struct stm32_adc *adc;
+ bool timestamping = false;
int ret;
if (!pdev->dev.of_node)
@@ -1931,16 +1948,22 @@ static int stm32_adc_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- ret = stm32_adc_chan_of_init(indio_dev);
- if (ret < 0)
- return ret;
-
ret = stm32_adc_dma_request(dev, indio_dev);
if (ret < 0)
return ret;
- if (!adc->dma_chan)
+ if (!adc->dma_chan) {
+ /* For PIO mode only, iio_pollfunc_store_time stores a timestamp
+* in the primary trigger IRQ handler and
stm32_adc_trigger_handler
+* runs in the IRQ thread to push out buffer along with
timestamp.
+*/
handler = _adc_trigger_handler;
+ timestamping = true;
+ }
+
+ ret = stm32_adc_chan_of_init(indio_dev, timestamping);
+ if (ret < 0)
+ goto err_dma_disable;
ret = iio_triggered_buffer_setup(indio_dev,
[PATCH 4/4] perf vendor events arm64: Reference common and uarch events for A76
Reduce duplication in the JSONs by referencing standard events from
armv8-common-and-microarch.json
In general the "PublicDescription" fields are not modified when somewhat
significantly worded differently than the standard.
Apart from that, description and names for events slightly different to
standard are changed (to standard) for consistency.
Signed-off-by: John Garry
---
.../arch/arm64/arm/cortex-a76-n1/branch.json | 12 +-
.../arch/arm64/arm/cortex-a76-n1/bus.json | 19 ++-
.../arch/arm64/arm/cortex-a76-n1/cache.json | 118 ++
.../arm64/arm/cortex-a76-n1/exception.json| 10 +-
.../arm64/arm/cortex-a76-n1/instruction.json | 45 +++
.../arch/arm64/arm/cortex-a76-n1/memory.json | 6 +-
.../arch/arm64/arm/cortex-a76-n1/other.json | 4 +-
.../arm64/arm/cortex-a76-n1/pipeline.json | 12 +-
8 files changed, 76 insertions(+), 150 deletions(-)
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
index b5e5d055c70d..ec0dc92288ab 100644
--- a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
@@ -1,14 +1,10 @@
[
{
-"PublicDescription": "Mispredicted or not predicted branch
speculatively executed. This event counts any predictable branch instruction
which is mispredicted either due to dynamic misprediction or because the MMU is
off and the branches are statically predicted not taken.",
-"EventCode": "0x10",
-"EventName": "BR_MIS_PRED",
-"BriefDescription": "Mispredicted or not predicted branch
speculatively executed."
+"PublicDescription": "This event counts any predictable branch
instruction which is mispredicted either due to dynamic misprediction or
because the MMU is off and the branches are statically predicted not taken",
+"ArchStdEvent": "BR_MIS_PRED",
},
{
-"PublicDescription": "Predictable branch speculatively executed. This
event counts all predictable branches.",
-"EventCode": "0x12",
-"EventName": "BR_PRED",
-"BriefDescription": "Predictable branch speculatively executed."
+"PublicDescription": "This event counts all predictable branches.",
+"ArchStdEvent": "BR_PRED",
}
]
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
index fce7309ae624..6263929efce2 100644
--- a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
@@ -1,24 +1,21 @@
[
{
-"EventCode": "0x11",
-"EventName": "CPU_CYCLES",
+"PublicDescription": "The number of core clock cycles"
+"ArchStdEvent": "CPU_CYCLES",
"BriefDescription": "The number of core clock cycles."
},
{
-"PublicDescription": "Bus access. This event counts for every beat of
data transferred over the data channels between the core and the SCU. If both
read and write data beats are transferred on a given cycle, this event is
counted twice on that cycle. This event counts the sum of BUS_ACCESS_RD and
BUS_ACCESS_WR.",
-"EventCode": "0x19",
-"EventName": "BUS_ACCESS",
-"BriefDescription": "Bus access."
+"PublicDescription": "This event counts for every beat of data
transferred over the data channels between the core and the SCU. If both read
and write data beats are transferred on a given cycle, this event is counted
twice on that cycle. This event counts the sum of BUS_ACCESS_RD and
BUS_ACCESS_WR.",
+"ArchStdEvent": "BUS_ACCESS",
},
{
-"EventCode": "0x1D",
-"EventName": "BUS_CYCLES",
-"BriefDescription": "Bus cycles. This event duplicates CPU_CYCLES."
+"PublicDescription": "This event duplicates CPU_CYCLES."
+"ArchStdEvent": "BUS_CYCLES",
},
{
-"ArchStdEvent": "BUS_ACCESS_RD"
+"ArchStdEvent": "BUS_ACCESS_RD",
},
{
-"ArchStdEvent": "BUS_ACCESS_WR"
+"ArchStdEvent": "BUS_ACCESS_WR",
}
]
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
index 24594081c199..cd67bb9df139 100644
--- a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
@@ -1,133 +1,95 @@
[
{
-"PublicDescription": "L1 instruction cache refill. This event counts
any instruction fetch which misses in the cache.",
-"EventCode": "0x01",
-"EventName": "L1I_CACHE_REFILL",
-"BriefDescription": "L1 instruction cache refill"
+"PublicDescription": "This event counts any instruction fetch which
misses in the cache.",
+"ArchStdEvent": "L1I_CACHE_REFILL",
},
{
-
[PATCH 2/4] perf vendor events arm64: Add common and uarch event JSON
Add a common and microarch JSON, which can be referenced from CPU JSONs.
For now, brief and public description are as event brief event
description from the ARMv8 ARM [0], D7-11.
The list of events is not complete, as not all events will be referenced
yet.
Reference document is at the following:
[0] https://documentation-service.arm.com/static/5fa3bd1eb209f547eebd4141?token=
Signed-off-by: John Garry
---
.../arm64/armv8-common-and-microarch.json | 248 ++
1 file changed, 248 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
diff --git a/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
b/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
new file mode 100644
index ..430a023ccf6a
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
@@ -0,0 +1,248 @@
+[
+{
+"PublicDescription": "Instruction architecturally executed, Condition
code check pass, software increment",
+"EventCode": "0x00",
+"EventName": "SW_INCR",
+"BriefDescription": "Instruction architecturally executed, Condition
code check pass, software increment"
+},
+{
+"PublicDescription": "Level 1 instruction cache refill",
+"EventCode": "0x01",
+"EventName": "L1I_CACHE_REFILL",
+"BriefDescription": "Level 1 instruction cache refill"
+},
+{
+"PublicDescription": "Attributable Level 1 instruction TLB refill",
+"EventCode": "0x02",
+"EventName": "L1I_TLB_REFILL",
+"BriefDescription": "Attributable Level 1 instruction TLB refill"
+},
+{
+"PublicDescription": "Level 1 data cache refill",
+"EventCode": "0x03",
+"EventName": "L1D_CACHE_REFILL",
+"BriefDescription": "Level 1 data cache refill"
+},
+{
+"PublicDescription": "Level 1 data cache access",
+"EventCode": "0x04",
+"EventName": "L1D_CACHE",
+"BriefDescription": "Level 1 data cache access"
+},
+{
+"PublicDescription": "Attributable Level 1 data TLB refill",
+"EventCode": "0x05",
+"EventName": "L1D_TLB_REFILL",
+"BriefDescription": "Attributable Level 1 data TLB refill"
+},
+{
+"PublicDescription": "Instruction architecturally executed",
+"EventCode": "0x08",
+"EventName": "INST_RETIRED",
+"BriefDescription": "Instruction architecturally executed"
+},
+{
+"PublicDescription": "Exception taken",
+"EventCode": "0x09",
+"EventName": "EXC_TAKEN",
+"BriefDescription": "Exception taken"
+},
+{
+"PublicDescription": "Instruction architecturally executed, condition
check pass, exception return",
+"EventCode": "0x0a",
+"EventName": "EXC_RETURN",
+"BriefDescription": "Instruction architecturally executed, condition
check pass, exception return"
+},
+{
+"PublicDescription": "Instruction architecturally executed, condition
code check pass, write to CONTEXTIDR",
+"EventCode": "0x0b",
+"EventName": "CID_WRITE_RETIRED",
+"BriefDescription": "Instruction architecturally executed, condition
code check pass, write to CONTEXTIDR"
+},
+{
+"PublicDescription": "Mispredicted or not predicted branch
speculatively executed",
+"EventCode": "0x10",
+"EventName": "BR_MIS_PRED",
+"BriefDescription": "Mispredicted or not predicted branch
speculatively executed"
+},
+{
+"PublicDescription": "Cycle",
+"EventCode": "0x11",
+"EventName": "CPU_CYCLES",
+"BriefDescription": "Cycle"
+},
+{
+"PublicDescription": "Predictable branch speculatively executed",
+"EventCode": "0x12",
+"EventName": "BR_PRED",
+"BriefDescription": "Predictable branch speculatively executed"
+},
+{
+"PublicDescription": "Data memory access",
+"EventCode": "0x13",
+"EventName": "MEM_ACCESS",
+"BriefDescription": "Data memory access"
+},
+{
+"PublicDescription": "Attributable Level 1 instruction cache access",
+"EventCode": "0x14",
+"EventName": "L1I_CACHE",
+"BriefDescription": "Attributable Level 1 instruction cache access"
+},
+{
+"PublicDescription": "Attributable Level 1 data cache write-back",
+"EventCode": "0x15",
+"EventName": "L1D_CACHE_WB",
+"BriefDescription": "Attributable Level 1 data cache write-back"
+},
+{
+"PublicDescription": "Level 2 data cache access",
+"EventCode": "0x16",
+"EventName": "L2D_CACHE",
+"BriefDescription": "Level 2 data cache access"
+},
+{
+"PublicDescription": "Level 2 data refill",
+"EventCode": "0x17",
+"EventName": "L2D_CACHE_REFILL",
+"BriefDescription": "Level 2 data
Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS
On Mon, Jan 25, 2021 at 08:07:06PM +0800, Xu, Like wrote: > So under the premise that counter cross-mapping is allowed, > how can hypercall help fix it ? Hypercall or otherwise exposing the mapping, will let the guest fix it up when it already touches the data. Which avoids the host from having to access the guest memory and is faster, no?
Re: [PATCH v3 18/21] dt-bindings: allwinner: Add H616 compatible strings
On Sun, 17 Jan 2021 22:28:47 -0600 Samuel Holland wrote: Hi, > On 1/17/21 8:08 PM, Andre Przywara wrote: > > Add simple "allwinner,sun50i-h616-xxx" compatible names to existing > > bindings, and pair them with an existing fallback compatible string, > > as the devices are compatible. > > This covers I2C, infrared, RTC and SPI. > > > > Use enums to group all compatible devices together. > > > > Signed-off-by: Andre Przywara > > Acked-by: Rob Herring > > Acked-by: Wolfram Sang # for I2C > > --- > > .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 21 +++ > > .../media/allwinner,sun4i-a10-ir.yaml | 16 ++ > > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 3 +++ > > .../bindings/spi/allwinner,sun6i-a31-spi.yaml | 1 + > > 4 files changed, 17 insertions(+), 24 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > index 5b5ae402f97a..eb72dd571def 100644 > > --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > @@ -18,21 +18,14 @@ properties: > >- const: allwinner,sun4i-a10-i2c > >- const: allwinner,sun6i-a31-i2c > >- items: > > - - const: allwinner,sun8i-a23-i2c > > + - enum: > > + - allwinner,sun8i-a23-i2c > > + - allwinner,sun8i-a83t-i2c > > + - allwinner,sun50i-a64-i2c > > + - allwinner,sun50i-a100-i2c > > + - allwinner,sun50i-h6-i2c > > + - allwinner,sun50i-h616-i2c > >- const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun8i-a83t-i2c > > - - const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun50i-a64-i2c > > - - const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun50i-a100-i2c > > - - const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun50i-h6-i2c > > - - const: allwinner,sun6i-a31-i2c > > - > >- const: marvell,mv64xxx-i2c > >- const: marvell,mv78230-i2c > >- const: marvell,mv78230-a0-i2c > > diff --git > > a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > index 5fa19d4aeaf3..6d8395d6bca0 100644 > > --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > @@ -20,16 +20,12 @@ properties: > >- const: allwinner,sun5i-a13-ir > >- const: allwinner,sun6i-a31-ir > >- items: > > - - const: allwinner,sun8i-a83t-ir > > - - const: allwinner,sun6i-a31-ir > > - - items: > > - - const: allwinner,sun8i-r40-ir > > - - const: allwinner,sun6i-a31-ir > > - - items: > > - - const: allwinner,sun50i-a64-ir > > - - const: allwinner,sun6i-a31-ir > > - - items: > > - - const: allwinner,sun50i-h6-ir > > + - enum: > > + - allwinner,sun8i-a83t-ir > > + - allwinner,sun8i-r40-ir > > + - allwinner,sun50i-a64-ir > > + - allwinner,sun50i-h6-ir > > + - allwinner,sun50i-h616-ir > >- const: allwinner,sun6i-a31-ir > > > >reg: > > diff --git > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > index 37c2a601c3fa..97928efd2bc9 100644 > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > @@ -26,6 +26,9 @@ properties: > >- const: allwinner,sun50i-a64-rtc > >- const: allwinner,sun8i-h3-rtc > >- const: allwinner,sun50i-h6-rtc > > + - items: > > + - const: allwinner,sun50i-h616-rtc > > + - const: allwinner,sun50i-h6-rtc > > Since H6, the RTC manages the 24 MHz DCXO, so it provides a fourth clock > output. If this is easy to change later, then it is fine for now, but > maybe it is better to get the H616 binding correct from the beginning? So you mean that RTC register +0x160 controls the system HOSC clock, so the main input clock for all the PLLs and other clocks? And by clearing bit 1 in there we can stop this? And if that is the case, do you suggest that we should model this in the DT, so that the fixed-clock "<>" should be replaced with "< 3>"? So from a "the DT describes the hardware" point of view that would probably the right way, but not sure if Linux is happy about that. At the very least that would mean to extend the RTC driver to export a fourth clock, and all devices would now depend on the RTC (also for
Re: [PATCH v3 2/4] drm/qxl: unpin release objects
> > Just calling ttm_bo_unpin() here makes lockdep unhappy.
>
> How does that one splat? But yeah if that's a problem should be
> explained in the comment. I'd then also only do a pin_count--; to make
> sure you can still catch other pin leaks if you have them. Setting it
> to 0 kinda defeats the warning.
Figured the unpin is at the completely wrong place while trying to
reproduce the lockdep splat ...
take care,
Gerd
>From 43befab4a935114e8620af62781666fa81288255 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Mon, 25 Jan 2021 13:10:50 +0100
Subject: [PATCH] drm/qxl: unpin release objects
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index c52412724c26..28013fd1f8ea 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -347,6 +347,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
unsigned long size,
mutex_lock(>release_mutex);
if (qdev->current_release_bo_offset[cur_idx] + 1 >=
releases_per_bo[cur_idx]) {
+ qxl_bo_unpin(qdev->current_release_bo[cur_idx]);
qxl_bo_unref(>current_release_bo[cur_idx]);
qdev->current_release_bo_offset[cur_idx] = 0;
qdev->current_release_bo[cur_idx] = NULL;
--
2.29.2
