Re: [PATCH 1/2] kexec: Add quick kexec support for kernel
On 08/14/20 at 01:52am, Sang Yan wrote:
> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> copy all segments from vmalloced memory to kernel boot memory,
> because of disabled mmu.
It is not the case on all archs, I assume your case is arm64, please
describe it in patch log :)
About the arm64 problem, I know Pavel Tatashin is working on a patchset
to improve the performance with enabling mmu.
I added Pavel in cc, can you try his patches?
>
> We introduce quick kexec to save time of copying memory as above,
> just like kdump(kexec on crash), by using reserved memory
> "Quick Kexec".
This approach may have gain, but it also introduce extra requirements to
pre-reserve a memory region. I wonder how Eric thinks about the idea.
Anyway the "quick" name sounds not very good, I would suggest do not
introduce a new param, and the code can check if pre-reserved region
exist then use it, if not then fallback to old way.
>
> Constructing quick kimage as the same as crash kernel,
> then simply copy all segments of kimage to reserved memroy.
>
> We also add this support in syscall kexec_load using flags
> of KEXEC_QUICK.
>
> Signed-off-by: Sang Yan
> ---
> arch/Kconfig | 10 ++
> include/linux/ioport.h | 3 +++
> include/linux/kexec.h | 13 +++-
> include/uapi/linux/kexec.h | 3 +++
> kernel/kexec.c | 10 ++
> kernel/kexec_core.c| 41 +-
> 6 files changed, 70 insertions(+), 10 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 3329fa143637..eca782cb8e29 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -21,6 +21,16 @@ config KEXEC_CORE
> config KEXEC_ELF
> bool
>
> +config QUICK_KEXEC
> + bool "Support for quick kexec"
> + depends on KEXEC_CORE
> + help
> + Say y here to enable this feature.
> + It use reserved memory to accelerate kexec, just like crash
> + kexec, load new kernel and initrd to reserved memory, and
> + boot new kernel on that memory. It will save the time of
> + relocating kernel.
> +
> config HAVE_IMA_KEXEC
> bool
>
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 6c2b06fe8beb..f37c632accbe 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -136,6 +136,9 @@ enum {
> IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
> IORES_DESC_RESERVED = 7,
> IORES_DESC_SOFT_RESERVED= 8,
> +#ifdef CONFIG_QUICK_KEXEC
> + IORES_DESC_QUICK_KEXEC = 9,
> +#endif
> };
>
> /*
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 9e93bef52968..976bf9631070 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -269,9 +269,12 @@ struct kimage {
> unsigned long control_page;
>
> /* Flags to indicate special processing */
> - unsigned int type : 1;
> + unsigned int type : 2;
> #define KEXEC_TYPE_DEFAULT 0
> #define KEXEC_TYPE_CRASH 1
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_TYPE_QUICK 2
> +#endif
> unsigned int preserve_context : 1;
> /* If set, we are using file mode kexec syscall */
> unsigned int file_mode:1;
> @@ -331,6 +334,11 @@ extern int kexec_load_disabled;
> #define KEXEC_FLAGS(KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT)
> #endif
>
> +#ifdef CONFIG_QUICK_KEXEC
> +#undef KEXEC_FLAGS
> +#define KEXEC_FLAGS(KEXEC_ON_CRASH | KEXEC_QUICK)
> +#endif
> +
> /* List of defined/legal kexec file flags */
> #define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
>KEXEC_FILE_NO_INITRAMFS)
> @@ -340,6 +348,9 @@ extern int kexec_load_disabled;
> extern struct resource crashk_res;
> extern struct resource crashk_low_res;
> extern note_buf_t __percpu *crash_notes;
> +#ifdef CONFIG_QUICK_KEXEC
> +extern struct resource quick_kexec_res;
> +#endif
>
> /* flag to track if kexec reboot is in progress */
> extern bool kexec_in_progress;
> diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> index 05669c87a0af..e3213614b713 100644
> --- a/include/uapi/linux/kexec.h
> +++ b/include/uapi/linux/kexec.h
> @@ -12,6 +12,9 @@
> /* kexec flags for different usage scenarios */
> #define KEXEC_ON_CRASH 0x0001
> #define KEXEC_PRESERVE_CONTEXT 0x0002
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_QUICK 0x0004
> +#endif
> #define KEXEC_ARCH_MASK 0x
>
> /*
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index f977786fe498..428af4cd3e1a 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -44,6 +44,9 @@ static int kimage_alloc_init(struct kimage **rimage,
> unsigned long entry,
> int ret;
> struct kimage *image;
> bool kexec_on_panic = flags & KEXEC_ON_CRASH;
> +#ifdef CONFIG_QUICK_KEXEC
> + bool kexec_on_quick = flags & KEXEC_QUICK;
> +#endif
>
> if (kexec_on_p
Re: [PATCH] mm: include CMA pages in lowmem_reserve at boot
On Thu 13-08-20 10:55:17, Doug Berger wrote: [...] > One example might be a 1GB arm platform that defines a 256MB default CMA > region. The default zones might map as follows: > [0.00] cma: Reserved 256 MiB at 0x3000 > [0.00] Zone ranges: > [0.00] DMA [mem 0x-0x2fff] > [0.00] Normal empty > [0.00] HighMem [mem 0x3000-0x3fff] [...] > > Here you can see that the lowmem_reserve array for the DMA zone is all > 0's. This is because the HighMem zone is consumed by the CMA region > whose pages haven't been activated to increase the zone managed count > when init_per_zone_wmark_min() is invoked at boot. > > If we access the /proc/sys/vm/lowmem_reserve_ratio sysctl with: > # cat /proc/sys/vm/lowmem_reserve_ratio > 256 32 0 0 Yes, this is really an unexpected behavior. [...] > Here the lowmem_reserve back pressure for the DMA zone for allocations > that target the HighMem zone is now 256 pages. Now 1MB is still not a > lot of additional back pressure, but the watermarks on the HighMem zone > aren't very large either so User space allocations can easily start > consuming the DMA zone while kswapd starts trying to reclaim space in > HighMem. This excess pressure on DMA zone memory can potentially lead to > earlier triggers of OOM Killer and/or kernel fallback allocations into > CMA Movable pages which can interfere with the ability of CMA to obtain > larger size contiguous allocations. > > All of that said, my main concern is that I don't like the inconsistency > between the boot time and run time results. Thanks for the clarification. I would suggest extending your changlog by the following. " In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout [0.00] cma: Reserved 256 MiB at 0x3000 [0.00] Zone ranges: [0.00] DMA [mem 0x-0x2fff] [0.00] Normal empty [0.00] HighMem [mem 0x3000-0x3fff] would result in 0 lowmem_reserve for the DMA zone. This would allow userspace the deplete the DMA zone easily. Funnily enough $ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because it forces setup_per_zone_lowmem_reserve as a side effect. " With that feel free to add Acked-by: Michal Hocko
Re: [PATCH] MIPS: Loongson: Set CONFIG_FRAME_WARN=2048 in loongson3_defconfig to fix build warning
On Fri, Aug 14, 2020 at 10:56:33AM +0800, Tiezhu Yang wrote:
> Fixes: 70b838292bef ("MIPS: Update default config file for Loongson-3")
I'm not so sure whether this warrants a fixes tag.
> arch/mips/configs/loongson3_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/configs/loongson3_defconfig
> b/arch/mips/configs/loongson3_defconfig
> index a65b08d..2b356d9 100644
> --- a/arch/mips/configs/loongson3_defconfig
> +++ b/arch/mips/configs/loongson3_defconfig
> @@ -403,7 +403,7 @@ CONFIG_CRYPTO_TEA=m
> CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRYPTO_DEFLATE=m
> CONFIG_PRINTK_TIME=y
> -CONFIG_FRAME_WARN=1024
> +CONFIG_FRAME_WARN=2048
what about just dropping it ? Default for 64bit is 2048. Leaving it out
of the config has the advantage that you will get a change of the default
for free.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
RE: [PATCH v5 3/3] fpga: dfl: add support for N3000 Nios private feature
> > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > > > index 7cd5a29..f6252cd 100644 > > > --- a/drivers/fpga/Kconfig > > > +++ b/drivers/fpga/Kconfig > > > @@ -191,6 +191,17 @@ config FPGA_DFL_AFU > > >to the FPGA infrastructure via a Port. There may be more than one > > >Port/AFU per DFL based FPGA device. > > > > > > +config FPGA_DFL_N3000_NIOS > > > > FPGA_DFL_NIOS_INTEL_PAC_N3000 > > Why we need to be that specific? I think we don't have to add so many > info for the naming. dfl N3000 nios is unique and aligned with the file > name and driver name. Looks like this driver only works for this card, not designed for common reuse I think. This is why I am thinking if it can be more specific, and matches with descriptions below. > > > > > > +tristate "FPGA DFL N3000 NIOS Driver" > > > > FPGA DFL NIOS Driver for Intel PAC N3000 > > > > > +depends on FPGA_DFL > > > +select REGMAP > > > +help > > > + This is the driver for the N3000 Nios private feature on Intel > > > + PAC (Programmable Acceleration Card) N3000. It communicates > > > + with the embedded Nios processor to configure the retimers on > > > + the card. It also instantiates the SPI master (spi-altera) for > > > + the card's BMC (Board Management Controller) control. > > > + > > > config FPGA_DFL_PCI > > > tristate "FPGA DFL PCIe Device Driver" > > > depends on PCI && FPGA_DFL > > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > > > index d8e21df..27f20f2 100644 > > > --- a/drivers/fpga/Makefile > > > +++ b/drivers/fpga/Makefile > > > @@ -44,5 +44,7 @@ dfl-fme-objs += dfl-fme-perf.o > > > dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o > > > dfl-afu-objs += dfl-afu-error.o > > > > > > +obj-$(CONFIG_FPGA_DFL_N3000_NIOS) += dfl-n3000-nios.o > > > + > > > # Drivers for FPGAs which implement DFL > > > obj-$(CONFIG_FPGA_DFL_PCI)+= dfl-pci.o > > > diff --git a/drivers/fpga/dfl-n3000-nios.c b/drivers/fpga/dfl-n3000-nios.c > > > new file mode 100644 > > > index 000..aeac224 > > > --- /dev/null > > > +++ b/drivers/fpga/dfl-n3000-nios.c > > > @@ -0,0 +1,528 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * DFL device driver for Nios private feature on Intel PAC (Programmable > > > + * Acceleration Card) N3000 > > > + * > > > + * Copyright (C) 2019-2020 Intel Corporation, Inc. > > > + * > > > + * Authors: > > > + * Wu Hao > > > + * Xu Yilun > > > + */ > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include "dfl.h" > > > + > > > +static char *fec_mode = "rs"; > > > +module_param(fec_mode, charp, 0444); > > > +MODULE_PARM_DESC(fec_mode, "FEC mode of the ethernet retimer on > > > Intel PAC N3000"); > > > + > > > +/* N3000 Nios private feature registers */ > > > +#define NIOS_SPI_PARAM0x8 > > > +#define PARAM_SHIFT_MODE_MSKBIT_ULL(1) > > > +#define PARAM_SHIFT_MODE_MSB0 > > > +#define PARAM_SHIFT_MODE_LSB1 > > > +#define PARAM_DATA_WIDTHGENMASK_ULL(7, 2) > > > +#define PARAM_NUM_CSGENMASK_ULL(13, 8) > > > +#define PARAM_CLK_POLBIT_ULL(14) > > > +#define PARAM_CLK_PHASEBIT_ULL(15) > > > +#define PARAM_PERIPHERAL_IDGENMASK_ULL(47, 32) > > > + > > > +#define NIOS_SPI_CTRL0x10 > > > +#define CTRL_WR_DATAGENMASK_ULL(31, 0) > > > +#define CTRL_ADDRGENMASK_ULL(44, 32) > > > +#define CTRL_CMD_MSKGENMASK_ULL(63, 62) > > > +#define CTRL_CMD_NOP0 > > > +#define CTRL_CMD_RD1 > > > +#define CTRL_CMD_WR2 > > > + > > > +#define NIOS_SPI_STAT0x18 > > > +#define STAT_RD_DATAGENMASK_ULL(31, 0) > > > +#define STAT_RW_VALBIT_ULL(32) > > > + > > > +/* Nios handshake registers, indirect access */ > > > +#define NIOS_INIT0x1000 > > > +#define NIOS_INIT_DONEBIT(0) > > > +#define NIOS_INIT_STARTBIT(1) > > > +/* Mode for PKVL A, link 0, the same below */ > > > +#define REQ_FEC_MODE_A0_MSKGENMASK(9, 8) > > > +#define REQ_FEC_MODE_A1_MSKGENMASK(11, 10) > > > +#define REQ_FEC_MODE_A2_MSKGENMASK(13, 12) > > > +#define REQ_FEC_MODE_A3_MSKGENMASK(15, 14) > > > +#define REQ_FEC_MODE_B0_MSKGENMASK(17, 16) > > > +#define REQ_FEC_MODE_B1_MSKGENMASK(19, 18) > > > +#define REQ_FEC_MODE_B2_MSKGENMASK(21, 20) > > > +#define REQ_FEC_MODE_B3_MSKGENMASK(23, 22) > > > +#define REQ_FEC_MODE_NO0x0 > > > +#define REQ_FEC_MODE_KR0x1 > > > +#define REQ_FEC_MODE_RS0x2 > > > + > > > +#define NIOS_FW_VERSION0x1004 > > > +#define NIOS_FW_VERSION_PATCHGENMASK(23, 20) > > > +#define NIOS_FW_VERSION_MINORGENMASK(27, 24) > > > +#define NIOS_FW_VERSION_MAJORGENMASK(31, 28) > > > + > > > +#define PKVL_A_MODE_STS0x1020 > > > +#define PKVL_B_MODE_STS0x1024 > > > +#define PKVL_MODE_STS_GROUP_MSKGENMASK(15, 8) > > > +#define PKVL_MODE_STS_GROUP_OK0x0 > > > +#define PKVL_MODE_STS_ID_MSKGENMASK(7, 0) > > > +/* When GROUP MASK field == GROUP_OK */ > > > +#define PKVL_MODE_ID_RESET0x0 > > > +#define PKVL_MODE_ID_4X10G0x1 > >
[PATCH v2] powerpc: Drop _nmask_and_or_msr()
_nmask_and_or_msr() is only used at two places to set MSR_IP. The SYNC is unnecessary as the users are not PowerPC 601. Can be easily writen in C. Do it, and drop _nmask_and_or_msr() Signed-off-by: Christophe Leroy --- v2: Removed the prototype in asm/processor.h --- arch/powerpc/include/asm/processor.h | 1 - arch/powerpc/kernel/misc_32.S | 13 - arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 3 ++- arch/powerpc/platforms/embedded6xx/storcenter.c | 3 ++- 4 files changed, 4 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h index ed0d633ab5aa..5f6b3ee84dd1 100644 --- a/arch/powerpc/include/asm/processor.h +++ b/arch/powerpc/include/asm/processor.h @@ -441,7 +441,6 @@ extern void poweroff_now(void); extern int fix_alignment(struct pt_regs *); extern void cvt_fd(float *from, double *to); extern void cvt_df(double *from, float *to); -extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val); #ifdef CONFIG_PPC64 /* diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index b24f866fef81..8d9cb5df580e 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -215,19 +215,6 @@ _GLOBAL(low_choose_7447a_dfs) #endif /* CONFIG_CPU_FREQ_PMAC && CONFIG_PPC_BOOK3S_32 */ -/* - * complement mask on the msr then "or" some values on. - * _nmask_and_or_msr(nmask, value_to_or) - */ -_GLOBAL(_nmask_and_or_msr) - mfmsr r0 /* Get current msr */ - andcr0,r0,r3/* And off the bits set in r3 (first parm) */ - or r0,r0,r4/* Or on the bits in r4 (second parm) */ - SYNC/* Some chip revs have problems here... */ - mtmsr r0 /* Update machine state */ - isync - blr /* Done */ - #ifdef CONFIG_40x /* diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c index 15437abe1f6d..b95c3380d2b5 100644 --- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c +++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c @@ -147,7 +147,8 @@ static void __noreturn mpc7448_hpc2_restart(char *cmd) local_irq_disable(); /* Set exception prefix high - to the firmware */ - _nmask_and_or_msr(0, MSR_IP); + mtmsr(mfmsr() | MSR_IP); + isync(); for (;;) ; /* Spin until reset happens */ } diff --git a/arch/powerpc/platforms/embedded6xx/storcenter.c b/arch/powerpc/platforms/embedded6xx/storcenter.c index ed1914dd34bb..e346ddcef45e 100644 --- a/arch/powerpc/platforms/embedded6xx/storcenter.c +++ b/arch/powerpc/platforms/embedded6xx/storcenter.c @@ -101,7 +101,8 @@ static void __noreturn storcenter_restart(char *cmd) local_irq_disable(); /* Set exception prefix high - to the firmware */ - _nmask_and_or_msr(0, MSR_IP); + mtmsr(mfmsr() | MSR_IP); + isync(); /* Wait for reset to happen */ for (;;) ; -- 2.25.0
[PATCH] rcu: shrink each possible cpu krcp
From: Zqiang
Due to cpu hotplug. some cpu may be offline after call "kfree_call_rcu"
func, if the shrinker is triggered at this time, we should drain each
possible cpu "krcp".
Signed-off-by: Zqiang
---
kernel/rcu/tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 8ce77d9ac716..619ccbb3fe4b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3443,7 +3443,7 @@ kfree_rcu_shrink_count(struct shrinker *shrink, struct
shrink_control *sc)
unsigned long count = 0;
/* Snapshot count of all CPUs */
- for_each_online_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
struct kfree_rcu_cpu *krcp = per_cpu_ptr(&krc, cpu);
count += READ_ONCE(krcp->count);
@@ -3458,7 +3458,7 @@ kfree_rcu_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
int cpu, freed = 0;
unsigned long flags;
- for_each_online_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
int count;
struct kfree_rcu_cpu *krcp = per_cpu_ptr(&krc, cpu);
@@ -3491,7 +3491,7 @@ void __init kfree_rcu_scheduler_running(void)
int cpu;
unsigned long flags;
- for_each_online_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
struct kfree_rcu_cpu *krcp = per_cpu_ptr(&krc, cpu);
raw_spin_lock_irqsave(&krcp->lock, flags);
--
2.17.1
Re: [PATCH V2] mm, page_alloc: fix core hung in free_pcppages_bulk()
On Thu 13-08-20 22:57:32, Charan Teja Kalla wrote:
> Thanks Michal.
>
> On 8/13/2020 10:00 PM, Michal Hocko wrote:
> > On Thu 13-08-20 21:51:29, Charan Teja Kalla wrote:
> >> Thanks Michal for comments.
> >>
> >> On 8/13/2020 5:11 PM, Michal Hocko wrote:
> >>> On Tue 11-08-20 18:28:23, Charan Teja Reddy wrote:
> >>> [...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e4896e6..839039f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1304,6 +1304,11 @@ static void free_pcppages_bulk(struct zone *zone,
> int count,
> struct page *page, *tmp;
> LIST_HEAD(head);
>
> +/*
> + * Ensure proper count is passed which otherwise would stuck in
> the
> + * below while (list_empty(list)) loop.
> + */
> +count = min(pcp->count, count);
> while (count) {
> struct list_head *list;
> >>>
> >>>
> >>> How does this prevent the race actually?
> >>
> >> This doesn't prevent the race. This only fixes the core hung(as this is
> >> called with spin_lock_irq()) caused by the race condition. This core
> >> hung is because of incorrect count value is passed to the
> >> free_pcppages_bulk() function.
> >
> > Let me ask differently. What does enforce that the count and lists do
> > not get out of sync in the loop.
>
> count value is updated whenever an order-0 page is being added to the
> pcp lists through free_unref_page_commit(), which is being called with
> both interrupts, premption disabled.
> static void free_unref_page_commit(struct page *page, {
>
> list_add(&page->lru, &pcp->lists[migratetype]);
> pcp->count++
> }
>
> As these are pcp lists, they only gets touched by another process when
> this process is context switched, which happens only after enabling
> premption or interrupts. So, as long as process is operating on these
> pcp lists in free_unref_page_commit function, the count and lists are
> always synced.
>
> However, the problem here is not that the count and lists are being out
> of sync. They do always in sync, as explained above. It is with the
> asking free_pcppages_bulk() to free the pages more than what is present
> in the pcp lists which is ending up in while(list_empty()).
You are right. I managed to confuse myself. The thing is that the batch
count is out of sync.
> > Your changelog says that the fix is to
> > use the proper value without any specifics.
> >
> Will change this to: Ensure the count value passed is not greater than
> the pcp lists count. Any better you suggest?
Yes, this makes it more clear.
Feel free to add
Acked-by: Michal Hocko
--
Michal Hocko
SUSE Labs
Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real
On 08/11/20 at 12:40pm, Orson Zhai wrote:
> From: Thomas Gleixner
>
> Timestamps printed in kernel log are retrieved by local_clock which reads
> jiffies as a referrence clock source.
> But it is diffcult to be synchronized with logs generated out of kernel,
> say some remote processors (Modem) in the Soc of mobile phones.
> Jiffies will be unchanged when system is in suspend mode but Modem will
> not.
>
> So timestamps are required to be compensated with suspend time in some
> complecated scenarios especially for Android system. As an initial
> implementation was rejected by Linus, Thomas made this patch [1] 2 yeas
> ago to replace ts_nsec with a struct ts that consists 3 types of time:
> mono, boot and real.
>
> This is an updated version which comes from patch [1] written by Thomas
> and suggestion [2] about VMCORE_INFO given by Linus.
>
> It provides the prerequisite code to print kernel logs with boot or real
> timestamp in the future.
>
> [1] https://lore.kernel.org/lkml/alpine.DEB.2.20.1711142341130.2221@nanos/
> [2]
> https://lore.kernel.org/lkml/ca+55afz-vvpbow0rvdw4en5yhwauzcmvsyzrqec41qdfodi...@mail.gmail.com/
>
> Cc. Thomas Gleixner
> Cc. Linus Torvalds
> Cc. Prarit Bhargava
> Cc. Petr Mladek
> Signed-off-by: Orson Zhai
> Tested-by: Cixi Geng
> ---
> This patch has been tested in qemu-x86-system. One problem is the timestamp
> in kernel log will be printed [0.00] for longer time than before.
>
> 1 [0.00] microcode: microcode updated early to revision 0x28, date =
> 2019-11-12
> 2 [0.00] Linux version 5.8.0+ (root@spreadtrum) (gcc (Ubuntu
> 7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #2 SMP
> Fri Aug 7 21:30:51 CST 2020
> 3 [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.8.0+
> root=UUID=4d889bca-be18-433d-9b86-c1c1714cc293 ro quiet splash vt.handoff=1
> 4 [0.00] KERNEL supported cpus:
> 5 [0.00] Intel GenuineIntel
>
> 223 [0.00] Tracing variant of Tasks RCU enabled.
> 224 [0.00] rcu: RCU calculated value of scheduler-enlistment delay is
> 25 jiffies.
> 225 [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16,
> nr_cpu_ids=4
> 226 [0.00] NR_IRQS: 524544, nr_irqs: 456, preallocated irqs: 16
> 227 [0.059662] random: crng done (trusting CPU's manufacturer)
>
> 228 [0.059662] Console: colour dummy device 80x25
> 229 [0.059662] printk: console [tty0] enabled
> 230 [0.059662] ACPI: Core revision 20200528
>
> compared to old log:
>
> 69 [0.00] reserve setup_data: [mem
> 0x0001-0x00021fdf] usable
> 70 [0.00] efi: EFI v2.31 by American Megatrends
> 71 [0.00] efi: ESRT=0xdbf69818 ACPI=0xdaef8000 ACPI 2.0=0xdaef8000
> SMBIOS=0xf0480
> 72 [0.00] SMBIOS 2.8 present.
> 73 [0.00] DMI: LENOVO ThinkCentre M4500t-N000/, BIOS FCKT58AUS
> 09/17/2014
> 74 [0.00] tsc: Fast TSC calibration using PIT
> 75 [0.00] tsc: Detected 3292.477 MHz processor
> 76 [0.000503] e820: update [mem 0x-0x0fff] usable ==> reserved
>
> 77 [0.000504] e820: remove [mem 0x000a-0x000f] usable
> 78 [0.000510] last_pfn = 0x21fe00 max_arch_pfn = 0x4
> 79 [0.000513] MTRR default type: uncachable
>
> include/linux/crash_core.h | 6 --
> include/linux/timekeeping.h | 15 +++
> kernel/printk/printk.c | 34 +++---
> kernel/time/timekeeping.c | 36 +---
> 4 files changed, 63 insertions(+), 28 deletions(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 525510a..85b96cd 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -50,9 +50,11 @@ phys_addr_t paddr_vmcoreinfo_note(void);
> #define VMCOREINFO_STRUCT_SIZE(name) \
> vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
> (unsigned long)sizeof(struct name))
> -#define VMCOREINFO_OFFSET(name, field) \
> +#define VMCOREINFO_FIELD_OFFSET(name, field, offset) \
> vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
> - (unsigned long)offsetof(struct name, field))
> + (unsigned long)offsetof(struct name, offset))
> +#define VMCOREINFO_OFFSET(name, field) \
> + VMCOREINFO_FIELD_OFFSET(name, field, field)
We do not regard the VMCOREINFO* as a strict ABI, makedumpfile and
crash tool can update to check the new field first then fallback to the old
name.
These crash dump tools are not usual userspace applications, although we
try not to break them, but if we have to and a tool update can make it
work again then I suggest we go with the change instead of doing the
trick.
Thanks
Dave
fs/ocfs2/suballoc.c:2430:2-8: preceding lock on line 2413
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e764a1e32337aaf325fc5b14a5bbd06eabba4699
commit: 464170647b5648bb81f3615567485fcb9a685bed jbd2: Make state lock a
spinlock
date: 10 months ago
config: x86_64-randconfig-c002-20200812 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
coccinelle warnings: (new ones prefixed by >>)
>> fs/ocfs2/suballoc.c:2430:2-8: preceding lock on line 2413
vim +2430 fs/ocfs2/suballoc.c
415cb800375cc4 Mark Fasheh 2007-09-16 2379
b4414eea0e7b9c Mark Fasheh 2010-03-11 2380 static int
ocfs2_block_group_clear_bits(handle_t *handle,
ccd979bdbce9fb Mark Fasheh 2005-12-15 2381
struct inode *alloc_inode,
ccd979bdbce9fb Mark Fasheh 2005-12-15 2382
struct ocfs2_group_desc *bg,
ccd979bdbce9fb Mark Fasheh 2005-12-15 2383
struct buffer_head *group_bh,
ccd979bdbce9fb Mark Fasheh 2005-12-15 2384
unsigned int bit_off,
b4414eea0e7b9c Mark Fasheh 2010-03-11 2385
unsigned int num_bits,
b4414eea0e7b9c Mark Fasheh 2010-03-11 2386
void (*undo_fn)(unsigned int bit,
b4414eea0e7b9c Mark Fasheh 2010-03-11 2387
unsigned long *bmap))
ccd979bdbce9fb Mark Fasheh 2005-12-15 2388 {
ccd979bdbce9fb Mark Fasheh 2005-12-15 2389 int status;
ccd979bdbce9fb Mark Fasheh 2005-12-15 2390 unsigned int tmp;
ccd979bdbce9fb Mark Fasheh 2005-12-15 2391 struct ocfs2_group_desc
*undo_bg = NULL;
464170647b5648 Thomas Gleixner 2019-08-09 2392 struct journal_head *jh;
ccd979bdbce9fb Mark Fasheh 2005-12-15 2393
42035306132802 Joel Becker 2008-11-13 2394 /* The caller got this
descriptor from
42035306132802 Joel Becker 2008-11-13 2395 *
ocfs2_read_group_descriptor(). Any corruption is a code bug. */
42035306132802 Joel Becker 2008-11-13 2396
BUG_ON(!OCFS2_IS_VALID_GROUP_DESC(bg));
ccd979bdbce9fb Mark Fasheh 2005-12-15 2397
2f73e135b83c50 Tao Ma 2011-02-22 2398
trace_ocfs2_block_group_clear_bits(bit_off, num_bits);
ccd979bdbce9fb Mark Fasheh 2005-12-15 2399
b4414eea0e7b9c Mark Fasheh 2010-03-11 2400 BUG_ON(undo_fn &&
!ocfs2_is_cluster_bitmap(alloc_inode));
0cf2f7632b1789 Joel Becker 2009-02-12 2401 status =
ocfs2_journal_access_gd(handle, INODE_CACHE(alloc_inode),
b4414eea0e7b9c Mark Fasheh 2010-03-11 2402
group_bh,
b4414eea0e7b9c Mark Fasheh 2010-03-11 2403
undo_fn ?
b4414eea0e7b9c Mark Fasheh 2010-03-11 2404
OCFS2_JOURNAL_ACCESS_UNDO :
b4414eea0e7b9c Mark Fasheh 2010-03-11 2405
OCFS2_JOURNAL_ACCESS_WRITE);
ccd979bdbce9fb Mark Fasheh 2005-12-15 2406 if (status < 0) {
ccd979bdbce9fb Mark Fasheh 2005-12-15 2407
mlog_errno(status);
ccd979bdbce9fb Mark Fasheh 2005-12-15 2408 goto bail;
ccd979bdbce9fb Mark Fasheh 2005-12-15 2409 }
ccd979bdbce9fb Mark Fasheh 2005-12-15 2410
464170647b5648 Thomas Gleixner 2019-08-09 2411 jh = bh2jh(group_bh);
b4414eea0e7b9c Mark Fasheh 2010-03-11 2412 if (undo_fn) {
464170647b5648 Thomas Gleixner 2019-08-09 @2413
spin_lock(&jh->b_state_lock);
464170647b5648 Thomas Gleixner 2019-08-09 2414 undo_bg =
(struct ocfs2_group_desc *) jh->b_committed_data;
94e41ecfe0f202 Sunil Mushran 2009-06-19 2415
BUG_ON(!undo_bg);
94e41ecfe0f202 Sunil Mushran 2009-06-19 2416 }
ccd979bdbce9fb Mark Fasheh 2005-12-15 2417
ccd979bdbce9fb Mark Fasheh 2005-12-15 2418 tmp = num_bits;
ccd979bdbce9fb Mark Fasheh 2005-12-15 2419 while(tmp--) {
ccd979bdbce9fb Mark Fasheh 2005-12-15 2420
ocfs2_clear_bit((bit_off + tmp),
ccd979bdbce9fb Mark Fasheh 2005-12-15 2421
(unsigned long *) bg->bg_bitmap);
b4414eea0e7b9c Mark Fasheh 2010-03-11 2422 if (undo_fn)
b4414eea0e7b9c Mark Fasheh 2010-03-11 2423
undo_fn(bit_off + tmp,
ccd979bdbce9fb Mark Fasheh 2005-12-15 2424
(unsigned long *) undo_bg->bg_bitmap);
ccd979bdbce9fb Mark Fasheh 2005-12-15 2425 }
ccd979bdbce9fb Mark Fasheh 2005-12-15 2426
le16_add_cpu(&bg->bg_free_bits_count, num_bits);
9b5cd10e4c14a1 Srinivas Eeda 2010-10-05 2427 if
(le16_to_cpu(bg->bg_free_bits_count
Re: [PATCH] edac,ghes,cper: Add Row Extension to Memory Error Record
On Mon, 27 Jul 2020 at 20:15, Alex Kluver wrote:
>
> Memory errors could be printed with incorrect row values since the DIMM
> size has outgrown the 16 bit row field in the CPER structure. UEFI
> Specification Version 2.8 has increased the size of row by allowing it to
> use the first 2 bits from a previously reserved space within the structure.
>
> When needed, add the extension bits to the row value printed.
>
> Based on UEFI 2.8 Table 299. Memory Error Record
>
> Tested-by: Russ Anderson
> Signed-off-by: Alex Kluver
> ---
> drivers/edac/ghes_edac.c| 10 --
> drivers/firmware/efi/cper.c | 11 +--
> include/linux/cper.h| 9 +++--
> 3 files changed, 24 insertions(+), 6 deletions(-)
>
Unless any of the EDAC folks object, I will take this as a fix via the EFI tree.
Thanks,
Ard.
> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
> index cb3dab56a875..cfa3156300f5 100644
> --- a/drivers/edac/ghes_edac.c
> +++ b/drivers/edac/ghes_edac.c
> @@ -337,8 +337,14 @@ void ghes_edac_report_mem_error(int sev, struct
> cper_sec_mem_err *mem_err)
> p += sprintf(p, "rank:%d ", mem_err->rank);
> if (mem_err->validation_bits & CPER_MEM_VALID_BANK)
> p += sprintf(p, "bank:%d ", mem_err->bank);
> - if (mem_err->validation_bits & CPER_MEM_VALID_ROW)
> - p += sprintf(p, "row:%d ", mem_err->row);
> + if (mem_err->validation_bits & (CPER_MEM_VALID_ROW |
> CPER_MEM_VALID_ROW_EXT)) {
> + u32 row_extended = 0;
> + if (mem_err->validation_bits & CPER_MEM_VALID_ROW_EXT)
> + row_extended = (mem_err->extended &
> CPER_MEM_EXT_ROW_MASK)
> + < + row_extended |= mem_err->row;
> + p += sprintf(p, "row:%d ", row_extended);
> + }
> if (mem_err->validation_bits & CPER_MEM_VALID_COLUMN)
> p += sprintf(p, "col:%d ", mem_err->column);
> if (mem_err->validation_bits & CPER_MEM_VALID_BIT_POSITION)
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index f564e15fbc7e..5faaf6ecd659 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -234,8 +234,14 @@ static int cper_mem_err_location(struct
> cper_mem_err_compact *mem, char *msg)
> n += scnprintf(msg + n, len - n, "bank: %d ", mem->bank);
> if (mem->validation_bits & CPER_MEM_VALID_DEVICE)
> n += scnprintf(msg + n, len - n, "device: %d ", mem->device);
> - if (mem->validation_bits & CPER_MEM_VALID_ROW)
> - n += scnprintf(msg + n, len - n, "row: %d ", mem->row);
> + if (mem->validation_bits & (CPER_MEM_VALID_ROW |
> CPER_MEM_VALID_ROW_EXT)) {
> + u32 row_extended = 0;
> + if (mem->validation_bits & CPER_MEM_VALID_ROW_EXT)
> + row_extended = (mem->extended & CPER_MEM_EXT_ROW_MASK)
> + < + row_extended |= mem->row;
> + n += scnprintf(msg + n, len - n, "row: %d ", row_extended);
> + }
> if (mem->validation_bits & CPER_MEM_VALID_COLUMN)
> n += scnprintf(msg + n, len - n, "column: %d ", mem->column);
> if (mem->validation_bits & CPER_MEM_VALID_BIT_POSITION)
> @@ -292,6 +298,7 @@ void cper_mem_err_pack(const struct cper_sec_mem_err *mem,
> cmem->requestor_id = mem->requestor_id;
> cmem->responder_id = mem->responder_id;
> cmem->target_id = mem->target_id;
> + cmem->extended = mem->extended;
> cmem->rank = mem->rank;
> cmem->mem_array_handle = mem->mem_array_handle;
> cmem->mem_dev_handle = mem->mem_dev_handle;
> diff --git a/include/linux/cper.h b/include/linux/cper.h
> index 8537e9282a65..c8313753ee49 100644
> --- a/include/linux/cper.h
> +++ b/include/linux/cper.h
> @@ -230,6 +230,10 @@ enum {
> #define CPER_MEM_VALID_RANK_NUMBER 0x8000
> #define CPER_MEM_VALID_CARD_HANDLE 0x1
> #define CPER_MEM_VALID_MODULE_HANDLE 0x2
> +#define CPER_MEM_VALID_ROW_EXT 0x4
> +
> +#define CPER_MEM_EXT_ROW_MASK 0x3
> +#define CPER_MEM_EXT_ROW_SHIFT 16
>
> #define CPER_PCIE_VALID_PORT_TYPE 0x0001
> #define CPER_PCIE_VALID_VERSION0x0002
> @@ -443,7 +447,7 @@ struct cper_sec_mem_err_old {
> u8 error_type;
> };
>
> -/* Memory Error Section (UEFI >= v2.3), UEFI v2.7 sec N.2.5 */
> +/* Memory Error Section (UEFI >= v2.3), UEFI v2.8 sec N.2.5 */
> struct cper_sec_mem_err {
> u64 validation_bits;
> u64 error_status;
> @@ -461,7 +465,7 @@ struct cper_sec_mem_err {
> u64 responder_id;
> u64 target_id;
> u8 error_type;
> - u8 reserved;
> + u8 extended;
> u16 rank;
> u16 mem_array_handle; /* "c
Re: [PATCH 0/3] Three small fixes to cmdline parsing
On Thu, 13 Aug 2020 at 20:58, Arvind Sankar wrote: > > First 2 are resends: > https://lore.kernel.org/linux-efi/20200725155916.1376773-1-nived...@alum.mit.edu/ > https://lore.kernel.org/linux-efi/20200729193300.598448-1-nived...@alum.mit.edu/ > > Arvind Sankar (3): > efi/libstub: Stop parsing arguments at "--" > efi/libstub: Handle NULL cmdline > efi/libstub: Handle unterminated cmdline > Thanks Arvind. I already applied #1 and #2 locally, so I will just pick up the last one. > drivers/firmware/efi/libstub/efi-stub-helper.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > -- > 2.26.2 >
[PATCH 2/2] arm64: Reserve memory for quick kexec
Reserve memory for quick kexec on arm64
with cmdline "quickkexec=".
Signed-off-by: Sang Yan
---
arch/arm64/kernel/setup.c | 6 ++
arch/arm64/mm/init.c | 43 +++
2 files changed, 49 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 77c4c9bad1b8..2a5dc032d95e 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -369,6 +369,12 @@ void __init __no_sanitize_address setup_arch(char
**cmdline_p)
*/
init_task.thread_info.ttbr0 = __pa_symbol(empty_zero_page);
#endif
+#ifdef CONFIG_QUICK_KEXEC
+ if (quick_kexec_res.end &&
+ quick_kexec_res.start >= res->start &&
+ quick_kexec_res.end <= res->end)
+ request_resource(res, &quick_kexec_res);
+#endif
if (boot_args[1] || boot_args[2] || boot_args[3]) {
pr_err("WARNING: x1-x3 nonzero in violation of boot protocol:\n"
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 481d22c32a2e..579acb93728f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -130,6 +130,45 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
+#ifdef CONFIG_QUICK_KEXEC
+static int __init parse_quick_kexec(char *p)
+{
+ if (!p)
+ return 0;
+
+ quick_kexec_res.end = PAGE_ALIGN(memparse(p, NULL));
+
+ return 0;
+}
+early_param("quickkexec", parse_quick_kexec);
+
+static void __init reserve_quick_kexec(void)
+{
+ unsigned long long mem_start, mem_len;
+
+ mem_len = quick_kexec_res.end;
+ if (mem_len == 0)
+ return;
+
+ /* Current arm64 boot protocol requires 2MB alignment */
+ mem_start = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT,
+ mem_len, CRASH_ALIGN);
+ if (mem_start == 0) {
+ pr_warn("cannot allocate quick kexec mem (size:0x%llx)\n",
+ mem_len);
+ quick_kexec_res.end = 0;
+ return;
+ }
+
+ memblock_reserve(mem_start, mem_len);
+ pr_info("quick kexec mem reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
+ mem_start, mem_start + mem_len, mem_len >> 20);
+
+ quick_kexec_res.start = mem_start;
+ quick_kexec_res.end = mem_start + mem_len - 1;
+}
+#endif
+
#ifdef CONFIG_CRASH_DUMP
static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
const char *uname, int depth, void *data)
@@ -399,6 +438,10 @@ void __init arm64_memblock_init(void)
reserve_crashkernel();
+#ifdef CONFIG_QUICK_KEXEC
+ reserve_quick_kexec();
+#endif
+
reserve_elfcorehdr();
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
--
2.19.1
[PATCH 1/2] kexec: Add quick kexec support for kernel
In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
copy all segments from vmalloced memory to kernel boot memory,
because of disabled mmu.
We introduce quick kexec to save time of copying memory as above,
just like kdump(kexec on crash), by using reserved memory
"Quick Kexec".
Constructing quick kimage as the same as crash kernel,
then simply copy all segments of kimage to reserved memroy.
We also add this support in syscall kexec_load using flags
of KEXEC_QUICK.
Signed-off-by: Sang Yan
---
arch/Kconfig | 10 ++
include/linux/ioport.h | 3 +++
include/linux/kexec.h | 13 +++-
include/uapi/linux/kexec.h | 3 +++
kernel/kexec.c | 10 ++
kernel/kexec_core.c| 41 +-
6 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 3329fa143637..eca782cb8e29 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -21,6 +21,16 @@ config KEXEC_CORE
config KEXEC_ELF
bool
+config QUICK_KEXEC
+ bool "Support for quick kexec"
+ depends on KEXEC_CORE
+ help
+ Say y here to enable this feature.
+ It use reserved memory to accelerate kexec, just like crash
+ kexec, load new kernel and initrd to reserved memory, and
+ boot new kernel on that memory. It will save the time of
+ relocating kernel.
+
config HAVE_IMA_KEXEC
bool
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 6c2b06fe8beb..f37c632accbe 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -136,6 +136,9 @@ enum {
IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
IORES_DESC_RESERVED = 7,
IORES_DESC_SOFT_RESERVED= 8,
+#ifdef CONFIG_QUICK_KEXEC
+ IORES_DESC_QUICK_KEXEC = 9,
+#endif
};
/*
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 9e93bef52968..976bf9631070 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -269,9 +269,12 @@ struct kimage {
unsigned long control_page;
/* Flags to indicate special processing */
- unsigned int type : 1;
+ unsigned int type : 2;
#define KEXEC_TYPE_DEFAULT 0
#define KEXEC_TYPE_CRASH 1
+#ifdef CONFIG_QUICK_KEXEC
+#define KEXEC_TYPE_QUICK 2
+#endif
unsigned int preserve_context : 1;
/* If set, we are using file mode kexec syscall */
unsigned int file_mode:1;
@@ -331,6 +334,11 @@ extern int kexec_load_disabled;
#define KEXEC_FLAGS(KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT)
#endif
+#ifdef CONFIG_QUICK_KEXEC
+#undef KEXEC_FLAGS
+#define KEXEC_FLAGS(KEXEC_ON_CRASH | KEXEC_QUICK)
+#endif
+
/* List of defined/legal kexec file flags */
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
@@ -340,6 +348,9 @@ extern int kexec_load_disabled;
extern struct resource crashk_res;
extern struct resource crashk_low_res;
extern note_buf_t __percpu *crash_notes;
+#ifdef CONFIG_QUICK_KEXEC
+extern struct resource quick_kexec_res;
+#endif
/* flag to track if kexec reboot is in progress */
extern bool kexec_in_progress;
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index 05669c87a0af..e3213614b713 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -12,6 +12,9 @@
/* kexec flags for different usage scenarios */
#define KEXEC_ON_CRASH 0x0001
#define KEXEC_PRESERVE_CONTEXT 0x0002
+#ifdef CONFIG_QUICK_KEXEC
+#define KEXEC_QUICK0x0004
+#endif
#define KEXEC_ARCH_MASK0x
/*
diff --git a/kernel/kexec.c b/kernel/kexec.c
index f977786fe498..428af4cd3e1a 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -44,6 +44,9 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned
long entry,
int ret;
struct kimage *image;
bool kexec_on_panic = flags & KEXEC_ON_CRASH;
+#ifdef CONFIG_QUICK_KEXEC
+ bool kexec_on_quick = flags & KEXEC_QUICK;
+#endif
if (kexec_on_panic) {
/* Verify we have a valid entry point */
@@ -69,6 +72,13 @@ static int kimage_alloc_init(struct kimage **rimage,
unsigned long entry,
image->type = KEXEC_TYPE_CRASH;
}
+#ifdef CONFIG_QUICK_KEXEC
+ if (kexec_on_quick) {
+ image->control_page = quick_kexec_res.start;
+ image->type = KEXEC_TYPE_QUICK;
+ }
+#endif
+
ret = sanity_check_segment_list(image);
if (ret)
goto out_free_image;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c19c0dad1ebe..b73dd749368b 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -70,6 +70,16 @@ struct resource crashk_low_res = {
.desc = IORES_DESC_CRASH_KERNEL
};
+#ifdef CONFIG_QUICK_KEXEC
+struct resource quick_kexec_res = {
+ .name = "Quick kexec
[RFC][PATCH v2 2/2] dma-heap: Add a system-uncached heap
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we have no such flag, and by default the
current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
This does have a few "ugly" bits that were required to get
the buffer properly flushed out initially which I'd like to
improve. So feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Robin Murphy
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix build issue on sh reported-by: kernel test robot
* Rework to use for_each_sgtable_sg(), dma_map_sgtable(), and
for_each_sg_page() along with numerous other cleanups suggested
by Robin Murphy
---
drivers/dma-buf/heaps/Kconfig| 10 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_uncached_heap.c | 371 +++
3 files changed, 382 insertions(+)
create mode 100644 drivers/dma-buf/heaps/system_uncached_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..420b0ed0a512 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -5,6 +5,16 @@ config DMABUF_HEAPS_SYSTEM
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+config DMABUF_HEAPS_SYSTEM_UNCACHED
+ bool "DMA-BUF Uncached System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the uncached system dmabuf heap. This
+ heap is backed by pages from the buddy allocator, but pages are setup
+ for write combining. This avoids cache management overhead, and can
+ be faster if pages are mostly untouched by the cpu. If in doubt,
+ say Y.
+
config DMABUF_HEAPS_CMA
bool "DMA-BUF CMA Heap"
depends on DMABUF_HEAPS && DMA_CMA
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..085685ec478f 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM_UNCACHED) += system_uncached_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/system_uncached_heap.c
b/drivers/dma-buf/heaps/system_uncached_heap.c
new file mode 100644
index ..3b8e699bcae7
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_uncached_heap.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Uncached System DMA-Heap exporter
+ *
+ * Copyright (C) 2020 Linaro Ltd.
+ *
+ * Based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct uncached_heap {
+ struct dma_heap *heap;
+};
+
+struct uncached_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+ if (ret) {
+ kfree(new_table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sgtable_sg(table, sg, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset);
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+static int dma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_a
[RFC][PATCH v2 1/2] dma-heap: Keep track of the heap device struct
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Robin Murphy
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 33 +
include/linux/dma-heap.h | 9 +
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
* @heap_devt heap device node
* @list list head connecting to list of heaps
* @heap_cdev heap char device
+ * @heap_dev heap device struct
*
* Represents a heap of memory from which buffers can be made.
*/
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+ struct device *heap_dev;
};
static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+ return heap->heap_dev;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
- struct device *dev_ret;
unsigned int minor;
int ret;
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
goto err1;
}
- dev_ret = device_create(dma_heap_class,
- NULL,
- heap->heap_devt,
- NULL,
- heap->name);
- if (IS_ERR(dev_ret)) {
+ heap->heap_dev = device_create(dma_heap_class,
+ NULL,
+ heap->heap_devt,
+ NULL,
+ heap->name);
+ if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
- err_ret = ERR_CAST(dev_ret);
+ err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+ /* Make sure it doesn't disappear on us */
+ heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(&heap_list_lock);
list_add(&heap->list, &heap_list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.17.1
Re: [PATCH v5 0/6] Support running driver's probe for a device powered off
On 8/14/20 12:11 PM, Bingbu Cao wrote: > > > On 8/10/20 10:27 PM, Sakari Ailus wrote: >> Hi all, >> > ...snip... >> >> The use case is such that there is a privacy LED next to an integrated >> user-facing laptop camera, and this LED is there to signal the user that >> the camera is recording a video or capturing images. That LED also happens >> to be wired to one of the power supplies of the camera, so whenever you >> power on the camera, the LED will be lit, whether images are captured from >> the camera --- or not. There's no way to implement this differently >> without additional software control (allowing of which is itself a >> hardware design decision) on most CSI-2-connected camera sensors as they >> simply have no pin to signal the camera streaming state. >> >> This is also what happens during driver probe: the camera will be powered >> on by the I²C subsystem calling dev_pm_domain_attach() and the device is >> already powered on when the driver's own probe function is called. To the >> user this visible during the boot process as a blink of the privacy LED, >> suggesting that the camera is recording without the user having used an >> application to do that. From the end user's point of view the behaviour is >> not expected and for someone unfamiliar with internal workings of a >> computer surely seems quite suspicious --- even if images are not being >> actually captured. >> >> I've tested these on linux-next master. They also apply to Wolfram's >> i2c/for-next branch, there's a patch that affects the I²C core changes >> here (see below). The patches apart from that apply to Bartosz's >> at24/for-next as well as Mauro's linux-media master branch. > > Sakari, we meet one issue - once the vcm sub-device registered, the user space > will try to open the VCM (I have not figure out who did that), it will also > trigger the acpi pm resume/suspend, as the VCM always shares same power rail > with camera sensor, so the privacy LED still has a blink. Sakari, please ignore my previous comment, it is not related to this change. I see the sub device open is caused by v4l_id program from udev. > >> > ...snip... > -- Best regards, Bingbu Cao
Re: fsl_espi errors on v5.7.15
On 14.08.2020 04:48, Chris Packham wrote: > Hi, > > I'm seeing a problem with accessing spi-nor after upgrading a T2081 > based system to linux v5.7.15 > > For this board u-boot and the u-boot environment live on spi-nor. > > When I use fw_setenv from userspace I get the following kernel logs > > # fw_setenv foo=1 > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but SPIE_DON isn't set! > fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty! > fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32 > fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty! > fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32 > fsl_espi ffe11.spi: Transfer done but rx/tx fifo's aren't empty! > fsl_espi ffe11.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32 > ... > This error reporting doesn't exist yet in 4.4. So you may have an issue under 4.4 too, it's just not reported. Did you verify that under 4.4 fw_setenv actually has an effect? > If I run fw_printenv (before getting it into a bad state) it is able to > display the content of the boards u-boot environment. > This might indicate an issue with spi being locked. I've seen related questions, just use the search engine of your choice and check for fw_setenv and locked. > If been unsuccessful in producing a setup for bisecting the issue. I do > know the issue doesn't occur on the old 4.4.x based kernel but that's > probably not much help. > > Any pointers on what the issue (and/or solution) might be. > > Thanks, > Chris > Heiner
Re: [PATCH v5 0/9] Raspberry Pi 4 USB firmware initialization rework
On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote: > > > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote: > > Hi everyone. > > > > On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote: > > > On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be > > > loaded directly from an EEPROM or, if not present, by the SoC's > > > co-processor, VideoCore. This series reworks how we handle this. > > > > > > The previous solution makes use of PCI quirks and exporting platform > > > specific functions. Albeit functional it feels pretty shoehorned. This > > > proposes an alternative way of handling the triggering of the xHCI chip > > > initialization trough means of a reset controller. > > > > > > The benefits are pretty evident: less platform churn in core xHCI code, > > > and no explicit device dependency management in pcie-brcmstb. > > > > > > Note that patch #1 depends on another series[1], that was just applied > > > into the clk maintainer's tree. > > > > > > The series is based on v5.8-rc3 > > > > > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html > > > v2: https://lkml.org/lkml/2020/6/9/875 > > > v1: > > > https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulie...@suse.de/T/#t > > > > > > [1] > > > https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743...@swboyd.mtv.corp.google.com/T/#t > > > > > > --- > > > > We were waiting on a dependency to be merged upstream to get this. They are > > now > > in, so could we move things forward? > > > > I can take the device tree patches, I guess philipp can take the reset > > controller code. But I'm not so sure who should be taking the PCI/USB > > counterparts. > > Should we route everything through the USB tree since that is where the > changes that do require synchronization with other subsystems and DTS is > needed the most? > -- > Florian That's fine with me, if everyone else is ok with it :)
Re: [PATCH] rtc: cmos: initialize rtc time when reading alarm
Hi Alexandre, On Thu, Aug 13, 2020 at 5:33 PM Alexandre Belloni wrote: > > Hi, > > On 13/08/2020 15:41:34+1000, Victor Ding wrote: > > cmos_read_alarm() may leave certain fields of a struct rtc_time > > untouched; therefore, these fields contain garbage if not properly > > initialized, leading to inconsistent values when converting into > > time64_t. > > This patch to set all fields of a struct rtc_time to -1 before calling > > cmos_read_alarm(). > > > > I don't think this actually helps with the conversion as mktime64 > is taking unsigned int so I would think you need the whole logic that is > in __rtc_read_alarm It's true that this change does not produce a correct time64_t; however, it isn't the intention either. The proposed change only produces a consistent value: calling obtaining identical struct rtc_time if the CMOS wakealarm is unchanged. In the case of suspend/resume, a correct value time64_t is not necessary; a consistent value is sufficient to correctly perform an equality test for `t_current_expires` and `t_saved_expires`. Logic to deduce a correct time64_t is expensive and hence I would like to avoid __rtc_read_alarm's logic here. Prior to this patch, the struct rtc_time is uninitialized. After calling cmos_read_alarm(), the tm_year field is always left untouched and hence contains only garbage. On platforms without enhanced RTC timers, the tm_mon and tm_mday fields are left with garbage as well. Therefore, `t_current_expires` and `t_saved_expires` from garbage data, which leads to incorrect equality test results. > > > Signed-off-by: Victor Ding > > --- > > > > drivers/rtc/rtc-cmos.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c > > index bcc96ab7793f..c99af567780d 100644 > > --- a/drivers/rtc/rtc-cmos.c > > +++ b/drivers/rtc/rtc-cmos.c > > @@ -1006,6 +1006,7 @@ static int cmos_suspend(struct device *dev) > > enable_irq_wake(cmos->irq); > > } > > > > + memset(&cmos->saved_wkalrm.time, -1, sizeof(struct rtc_time)); > > cmos_read_alarm(dev, &cmos->saved_wkalrm); > > > > dev_dbg(dev, "suspend%s, ctrl %02x\n", > > @@ -1054,6 +1055,7 @@ static void cmos_check_wkalrm(struct device *dev) > > return; > > } > > > > + memset(¤t_alarm.time, -1, sizeof(struct rtc_time)); > > cmos_read_alarm(dev, ¤t_alarm); > > t_current_expires = rtc_tm_to_time64(¤t_alarm.time); > > t_saved_expires = rtc_tm_to_time64(&cmos->saved_wkalrm.time); > > -- > > 2.28.0.236.gb10cc79966-goog > > > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best regards, Victor Ding
Re: [PATCH v8 1/4] power: supply: core: add quick charge type property
On Fri, Aug 14, 2020 at 11:46:54AM +0800, Qiwu Huang wrote: > From: Qiwu Huang > > Reports the kind of quick charge type based on > different adapter power. > > Signed-off-by: Qiwu Huang > --- > Documentation/ABI/testing/sysfs-class-power | 21 + > drivers/power/supply/power_supply_sysfs.c | 1 + > drivers/power/supply/qcom_smbb.c| 51 + > include/linux/power_supply.h| 14 ++ > 4 files changed, 87 insertions(+) You should also submit your driver that uses these new attributes at the same time. What happened to that request? Otherwise no one really knows how these are being used, or if they even are used by anyone. thanks, greg k-h
Re: [PATCH] kexec: Delete an unnecessary comparison
On Thu, 2020-08-13 at 20:45 +0800, Youling Tang wrote:
> Regardless of whether the ret value is zero or non-zero, the trajectory
> of the program execution is the same, so there is no need to compare.
>
> Signed-off-by: Youling Tang
> ---
> kernel/kexec_file.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 78c0837..3ad0ae2 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -800,8 +800,6 @@ static int kexec_calculate_store_digests(struct kimage
> *image)
>
> ret = kexec_purgatory_get_set_symbol(image,
> "purgatory_sha256_digest",
>digest,
> SHA256_DIGEST_SIZE, 0);
> - if (ret)
> - goto out_free_digest;
> }
>
> out_free_digest:
If you really want to change the function, then
you could change a couple of breaks to gotos,
remove multiple unnecessary tests, and unindent
a block of code too.
---
kernel/kexec_file.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index ca40bef75a61..34a025e85887 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -763,7 +763,7 @@ static int kexec_calculate_store_digests(struct kimage
*image)
ret = crypto_shash_update(desc, ksegment->kbuf,
ksegment->bufsz);
if (ret)
- break;
+ goto out_free_digest;
/*
* Assume rest of the buffer is filled with zero and
@@ -777,32 +777,26 @@ static int kexec_calculate_store_digests(struct kimage
*image)
bytes = zero_buf_sz;
ret = crypto_shash_update(desc, zero_buf, bytes);
if (ret)
- break;
+ goto out_free_digest;
nullsz -= bytes;
}
- if (ret)
- break;
-
sha_regions[j].start = ksegment->mem;
sha_regions[j].len = ksegment->memsz;
j++;
}
- if (!ret) {
- ret = crypto_shash_final(desc, digest);
- if (ret)
- goto out_free_digest;
- ret = kexec_purgatory_get_set_symbol(image,
"purgatory_sha_regions",
-sha_regions,
sha_region_sz, 0);
- if (ret)
- goto out_free_digest;
+ ret = crypto_shash_final(desc, digest);
+ if (ret)
+ goto out_free_digest;
- ret = kexec_purgatory_get_set_symbol(image,
"purgatory_sha256_digest",
-digest,
SHA256_DIGEST_SIZE, 0);
- if (ret)
- goto out_free_digest;
- }
+ ret = kexec_purgatory_get_set_symbol(image, "purgatory_sha_regions",
+sha_regions, sha_region_sz, 0);
+ if (ret)
+ goto out_free_digest;
+
+ ret = kexec_purgatory_get_set_symbol(image, "purgatory_sha256_digest",
+digest, SHA256_DIGEST_SIZE, 0);
out_free_digest:
kfree(digest);
Re: [PATCH v3 2/2] dma-pool: Only allocate from CMA when in same memory zone
On Sat, Aug 08, 2020 at 08:33:54AM +0200, Christoph Hellwig wrote: > On Fri, Aug 07, 2020 at 10:50:19AM +0200, Nicolas Saenz Julienne wrote: > > On Fri, 2020-08-07 at 07:21 +0200, Christoph Hellwig wrote: > > > On Thu, Aug 06, 2020 at 08:47:55PM +0200, Nicolas Saenz Julienne wrote: > > > > There is no guarantee to CMA's placement, so allocating a zone specific > > > > atomic pool from CMA might return memory from a completely different > > > > memory zone. To get around this double check CMA's placement before > > > > allocating from it. > > > > > > As the builtbot pointed out, memblock_start_of_DRAM can't be used from > > > non-__init code. But lookig at it I think throwing that in > > > is bogus anyway, as cma_get_base returns a proper physical address > > > already. > > > > It does indeed, but I'm comparing CMA's base with bitmasks that don't take > > into > > account where the memory starts. Say memory starts at 0x8000, and CMA > > falls > > into ZONE_DMA [0x8000 0xC000], if you want to compare it with > > DMA_BIT_MASK(zone_dma_bits) you're forced to unify the memory bases. > > > > That said, I now realize that this doesn't work for ZONE_DMA32 which has a > > hard > > limit on 32bit addresses reglardless of the memory base. > > > > That said I still need to call memblock_start_of_DRAM() any suggestions WRT > > that? I could save the value in dma_atomic_pool_init(), which is __init > > code. > > The pool must be about a 32-bit physical address. The offsets can be > different for every device.. Do you plan to resend this one without the memblock_start_of_DRAM thingy?
[PATCH v4 0/4] Add basic node support for Mediatek MT8192 SoC
MT8192 is a SoC based on 64bit ARMv8 architecture. It contains 4 CA55 and 4 CA76 cores. MT8192 share many HW IP with MT65xx series. This patchset was tested on MT8192 evaluation board and use correct clock to she ll. Based on v5.8-rc1 Change in v4: 1. Remove scpsys, spmi and apu nodes 2. Add i2c nodes 3. Update watchdog binding 4. Update dependency list Change in v3: Fix typo in binding document of timer Change in v2: 1. Remove mt8192-power.h from mt8192.dtsi which is not used yet 2. Add timer binding document and device tree node in mt8192.dtsi 3. Remove watchdog driver modification Seiya Wang (3): arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile dt-bindings: serial: Add compatible for Mediatek MT8192 dt-bindings: timer: Add compatible for Mediatek MT8192 --- This patch depends on [PATCH v2 1/3] dt-bindings: pinctrl: mt8192: add pinctrl file [PATCH v2 2/3] dt-bindings: pinctrl: mt8192: add binding document [PATCH v2 3/4] dt-bindings: mediatek: add compatible for MT6873/8192 pwrap [PATCH v2 1/2] dt-bindings: spi: update bindings for MT8192 SoC [PATCH 2/4] clk: mediatek: Add dt-bindings for MT8192 clocks [PATCH v2 1/5] dt-bindings: ARM: Mediatek: Document bindings for MT8192 [v4,3/5] dt-binding: mediatek: mt8192: update mtk-wdt document Please also accept this patch together with [1][2][3][4][5][6] to avoid build and dt binding check error. [1] http://lists.infradead.org/pipermail/linux-mediatek/2020-August/015002.html [2] http://lists.infradead.org/pipermail/linux-mediatek/2020-August/015005.html [3] http://lists.infradead.org/pipermail/linux-mediatek/2020-July/014546.html [4] http://lists.infradead.org/pipermail/linux-mediatek/2020-July/014406.html [5] http://lists.infradead.org/pipermail/linux-mediatek/2020-July/014450.html [6] http://lists.infradead.org/pipermail/linux-mediatek/2020-July/014898.html [7] http://lists.infradead.org/pipermail/linux-mediatek/2020-August/015046.html --- .../devicetree/bindings/serial/mtk-uart.txt| 1 + .../devicetree/bindings/watchdog/mtk-wdt.txt | 2 + arch/arm64/boot/dts/mediatek/Makefile | 1 + arch/arm64/boot/dts/mediatek/mt8192-evb.dts| 29 + arch/arm64/boot/dts/mediatek/mt8192.dtsi | 663 + drivers/watchdog/mtk_wdt.c | 5 + 6 files changed, 701 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt8192-evb.dts create mode 100644 arch/arm64/boot/dts/mediatek/mt8192.dtsi -- 2.14.1
[PATCH v4 1/3] arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile
Add basic chip support for Mediatek MT8192
Signed-off-by: Seiya Wang
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 29 ++
arch/arm64/boot/dts/mediatek/mt8192.dtsi| 693
3 files changed, 723 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8192-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8192.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index a57af9da9f5c..80320ed2d82c 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -11,4 +11,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
new file mode 100644
index ..0205837fa698
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ * Author: Seiya Wang
+ */
+/dts-v1/;
+#include "mt8192.dtsi"
+
+/ {
+ model = "MediaTek MT8192 evaluation board";
+ compatible = "mediatek,mt8192-evb", "mediatek,mt8192";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
new file mode 100644
index ..b3fab4f45252
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -0,0 +1,693 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ * Author: Seiya Wang
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8192";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clk26m: oscillator0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "clk26m";
+ };
+
+ clk32k: oscillator1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "clk32k";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x000>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <&l2_0>;
+ capacity-dmips-mhz = <768>;
+ };
+
+ cpu1: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x100>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <&l2_0>;
+ capacity-dmips-mhz = <768>;
+ };
+
+ cpu2: cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x200>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <&l2_0>;
+ capacity-dmips-mhz = <768>;
+ };
+
+ cpu3: cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x300>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <&l2_0>;
+ capacity-dmips-mhz = <768>;
+ };
+
+ cpu4: cpu@400 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a76";
+ reg = <0x400>;
+ enable-method = "psci";
+ clock-frequency = <217100>;
+ next-level-cache = <&l2_1>;
+ capacity-dmips-mhz = <1024>;
+ };
+
+ cpu5: cpu@500 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a76";
+
[PATCH v4 3/3] dt-bindings: timer: Add compatible for Mediatek MT8192
This commit adds dt-binding documentation of timer for Mediatek MT8192 SoC Platform. Acked-by: Rob Herring Signed-off-by: Seiya Wang --- Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index 0d256486f886..690a9c0966ac 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -22,6 +22,7 @@ Required properties: For those SoCs that use SYST * "mediatek,mt8183-timer" for MT8183 compatible timers (SYST) + * "mediatek,mt8192-timer" for MT8192 compatible timers (SYST) * "mediatek,mt7629-timer" for MT7629 compatible timers (SYST) * "mediatek,mt6765-timer" for MT6765 and all above compatible timers (SYST) -- 2.14.1
[PATCH v4 2/3] dt-bindings: serial: Add compatible for Mediatek MT8192
This commit adds dt-binding documentation of uart for Mediatek MT8192 SoC Platform. Acked-by: Rob Herring Signed-off-by: Seiya Wang --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index 3a3b57079f0d..647b5aee86f3 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -19,6 +19,7 @@ Required properties: * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS + * "mediatek,mt8192-uart", "mediatek,mt6577-uart" for MT8192 compatible UARTS * "mediatek,mt8516-uart" for MT8516 compatible UARTS * "mediatek,mt6577-uart" for MT6577 and all of the above -- 2.14.1
Re: [PATCH v2] nvme: Use spin_lock_irq() when taking the ctrl->lock
There's an unrelated whitespace change in nvme_init_identify(). Otherwise, looks fine. Oops, sorry. can this be fixed up when it's merged? Fixed and queued.
Re: [PATCH] fs: Eliminate a local variable to make the code more clear
Ping
On Wed, Jul 29, 2020 at 11:21 PM Hao Lee wrote:
>
> The dentry local variable is introduced in 'commit 84d17192d2afd ("get
> rid of full-hash scan on detaching vfsmounts")' to reduce the length of
> some long statements for example
> mutex_lock(&path->dentry->d_inode->i_mutex). We have already used
> inode_lock(dentry->d_inode) to do the same thing now, and its length is
> acceptable. Furthermore, it seems not concise that assign path->dentry
> to local variable dentry in the statement before goto. So, this function
> would be more clear if we eliminate the local variable dentry.
>
> The function logic is not changed.
>
> Signed-off-by: Hao Lee
> ---
> fs/namespace.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 4a0f600a3328..fcb93586fcc9 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2187,20 +2187,19 @@ static int attach_recursive_mnt(struct mount
> *source_mnt,
> static struct mountpoint *lock_mount(struct path *path)
> {
> struct vfsmount *mnt;
> - struct dentry *dentry = path->dentry;
> retry:
> - inode_lock(dentry->d_inode);
> - if (unlikely(cant_mount(dentry))) {
> - inode_unlock(dentry->d_inode);
> + inode_lock(path->dentry->d_inode);
> + if (unlikely(cant_mount(path->dentry))) {
> + inode_unlock(path->dentry->d_inode);
> return ERR_PTR(-ENOENT);
> }
> namespace_lock();
> mnt = lookup_mnt(path);
> if (likely(!mnt)) {
> - struct mountpoint *mp = get_mountpoint(dentry);
> + struct mountpoint *mp = get_mountpoint(path->dentry);
> if (IS_ERR(mp)) {
> namespace_unlock();
> - inode_unlock(dentry->d_inode);
> + inode_unlock(path->dentry->d_inode);
> return mp;
> }
> return mp;
> @@ -2209,7 +2208,7 @@ static struct mountpoint *lock_mount(struct path *path)
> inode_unlock(path->dentry->d_inode);
> path_put(path);
> path->mnt = mnt;
> - dentry = path->dentry = dget(mnt->mnt_root);
> + path->dentry = dget(mnt->mnt_root);
> goto retry;
> }
>
> --
> 2.24.1
>
BUG: corrupted list in hci_chan_del
Hello, syzbot found the following issue on: HEAD commit:990f2273 Merge tag 's390-5.9-2' of git://git.kernel.org/pu.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1631149190 kernel config: https://syzkaller.appspot.com/x/.config?x=9c89856ae5fc8b6 dashboard link: https://syzkaller.appspot.com/bug?extid=21e61af4106356a893be compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+21e61af4106356a89...@syzkaller.appspotmail.com list_del corruption. prev->next should be 8880a2c52c00, but was [ cut here ] kernel BUG at lib/list_debug.c:51! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 11221 Comm: syz-executor.0 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__list_del_entry_valid.cold+0xf/0x55 lib/list_debug.c:51 Code: e8 0a af bf fd 0f 0b 48 89 f1 48 c7 c7 60 fe 93 88 4c 89 e6 e8 f6 ae bf fd 0f 0b 48 89 ee 48 c7 c7 00 00 94 88 e8 e5 ae bf fd <0f> 0b 4c 89 ea 48 89 ee 48 c7 c7 40 ff 93 88 e8 d1 ae bf fd 0f 0b RSP: 0018:c90008907828 EFLAGS: 00010282 RAX: 0054 RBX: RCX: RDX: 88805eb3a5c0 RSI: 815dbc57 RDI: f52001120ef7 RBP: 8880a2c52c00 R08: 0054 R09: 8880ae7318e7 R10: R11: 0004e618 R12: 88809421fe00 R13: 8920ff20 R14: fbfff1522378 R15: 888097af65d8 FS: () GS:8880ae70() knlGS: CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 7f0f6a6c5000 CR3: 09a8d000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_del_entry include/linux/list.h:132 [inline] list_del_rcu include/linux/rculist.h:158 [inline] hci_chan_del+0x3f/0x190 net/bluetooth/hci_conn.c:1733 l2cap_conn_del+0x61b/0x9e0 net/bluetooth/l2cap_core.c:1900 l2cap_disconn_cfm net/bluetooth/l2cap_core.c:8160 [inline] l2cap_disconn_cfm+0x85/0xa0 net/bluetooth/l2cap_core.c:8153 hci_disconn_cfm include/net/bluetooth/hci_core.h:1438 [inline] hci_conn_hash_flush+0x114/0x220 net/bluetooth/hci_conn.c:1557 hci_dev_do_close+0x5c6/0x1080 net/bluetooth/hci_core.c:1770 hci_unregister_dev+0x1bd/0xe30 net/bluetooth/hci_core.c:3790 vhci_release+0x70/0xe0 drivers/bluetooth/hci_vhci.c:340 __fput+0x285/0x920 fs/file_table.c:281 task_work_run+0xdd/0x190 kernel/task_work.c:135 exit_task_work include/linux/task_work.h:25 [inline] do_exit+0xb7d/0x29f0 kernel/exit.c:806 do_group_exit+0x125/0x310 kernel/exit.c:903 get_signal+0x40b/0x1ee0 kernel/signal.c:2743 arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811 exit_to_user_mode_loop kernel/entry/common.c:135 [inline] exit_to_user_mode_prepare+0x15d/0x1c0 kernel/entry/common.c:166 syscall_exit_to_user_mode+0x59/0x2b0 kernel/entry/common.c:241 __do_fast_syscall_32+0x63/0x80 arch/x86/entry/common.c:127 do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:149 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7f33569 Code: Bad RIP value. RSP: 002b:f550c12c EFLAGS: 0292 ORIG_RAX: 00f0 RAX: fe00 RBX: 08b9c014 RCX: 0080 RDX: RSI: RDI: 08b9c018 RBP: f550c228 R08: R09: R10: R11: R12: R13: R14: R15: Modules linked in: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v5 3/3] fpga: dfl: add support for N3000 Nios private feature
On Thu, Aug 13, 2020 at 04:43:33PM +0800, Wu, Hao wrote: > > Subject: [PATCH v5 3/3] fpga: dfl: add support for N3000 Nios private > > feature > > > > This patch adds support for the Nios handshake private feature on Intel > > PAC (Programmable Acceleration Card) N3000. > > > > The Nios is the embedded processor on the FPGA card. This private feature > > provides a handshake interface to FPGA Nois firmware, which receives > > retimer configuration command from host and executes via an internal SPI > > master (spi-altera). When Nios finishes the configuration, host takes over > > the ownership of the SPI master to control an Intel MAX10 BMC (Board > > Management Controller) Chip on the SPI bus. > > > > For Nios firmware handshake part, this driver requests the retimer > > configuration for Nios with parameters from module param, and adds some > > sysfs nodes for user to query the onboard retimer's working mode and > > Nios firmware version. > > > > For SPI part, this driver adds a spi-altera platform device as well as > > the MAX10 BMC spi slave info. A spi-altera driver will be matched to > > handle the following SPI work. > > > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > > Signed-off-by: Matthew Gerlach > > Signed-off-by: Russ Weight > > Reviewed-by: Tom Rix > > --- > > v3: Add the doc for this driver > > Minor fixes for comments from Tom > > v4: Move the err log in regmap implementation, and delete > > n3000_nios_writel/readl(), they have nothing to wrapper now. > > Some minor fixes and comments improvement. > > v5: Fix the output of fec_mode sysfs inf to "no" on 10G configuration, > > cause no FEC mode could be configured for 10G. > > Rename the dfl_n3000_nios_* to n3000_nios_* > > Improves comments. > > --- > > .../ABI/testing/sysfs-bus-dfl-devices-n3000-nios | 18 + > > Documentation/fpga/dfl-n3000-nios.rst | 45 ++ > > Documentation/fpga/index.rst | 1 + > > drivers/fpga/Kconfig | 11 + > > drivers/fpga/Makefile | 2 + > > drivers/fpga/dfl-n3000-nios.c | 528 > > + > > 6 files changed, 605 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl-devices- > > n3000-nios > > create mode 100644 Documentation/fpga/dfl-n3000-nios.rst > > create mode 100644 drivers/fpga/dfl-n3000-nios.c > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios > > b/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios > > new file mode 100644 > > index 000..221d635 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios > > @@ -0,0 +1,18 @@ > > +What:/sys/bus/dfl/devices/dfl_dev.X/fec_mode > > +Date:Aug 2020 > > +KernelVersion:5.10 > > +Contact:Xu Yilun > > +Description:Read-only. It returns the FEC mode of the ethernet retimer > > +configured by NIOS firmware. "rs" for Reed Solomon FEC, > > "kr" > > +for Fire Code FEC, "no" FOR NO FEC. The FEC mode could be > > set > > +by module parameters, but it could only be set once after the > > +board powers up. > > +Format: string > > + > > +What:/sys/bus/dfl/devices/dfl_dev.X/nios_fw_version > > +Date:Aug 2020 > > +KernelVersion:5.10 > > +Contact:Xu Yilun > > +Description:Read-only. It returns the NIOS firmware version in FPGA. Its > > +format is "major.minor.patch". > > +Format: %x.%x.%x > > diff --git a/Documentation/fpga/dfl-n3000-nios.rst > > b/Documentation/fpga/dfl-n3000-nios.rst > > new file mode 100644 > > index 000..c562aab > > --- /dev/null > > +++ b/Documentation/fpga/dfl-n3000-nios.rst > > @@ -0,0 +1,45 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > += > > +N3000 Nios Private Feature Driver > > += > > + > > +The N3000 Nios driver supports for the Nios handshake private feature on > > Intel > > +PAC (Programmable Acceleration Card) N3000. > > + > > +The Nios is the embedded processor on the FPGA card. This private feature > > +provides a handshake interface to FPGA Nios firmware, which receives the > > +ethernet retimer configuration command from host and does the > > configuration via > > +an internal SPI master (spi-altera). When Nios finishes the configuration, > > host > > +takes over the ownership of the SPI master to control an Intel MAX10 BMC > > (Board > > +Management Controller) Chip on the SPI bus. > > + > > +So the driver does 2 major tasks on probe, uses the Nios firmware to > > configure > > +the ethernet retimer, and then creates a spi master platform device with > > the > > +MAX10 device info in spi_board_info. > > + > > +Module Parameters > > += > > + > > +The N3000 Nios driver supports the following module parameters: > > + > > +* fec_mode: string > > + Require the Nios firmware to set the FEC (Forward Error Correction) mode > > of > > + the ethernet retimer on the Intel PAC N3000. The possi
[PATCH] regulator: Add support for RT4801 Display Bias regulator driver
From: ChiYuan Huang
Adds support for the RT4801 DSV. It has two regulators (DSVP/DSVN) with an I2C
interface. DSVP/DSVN can provide the display panel module for the
positive/negative
voltage range from (+/-)4V to (+/-)6V.
---
.../regulator/richtek,rt4801-regulator.yaml| 80
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/rt4801-regulator.c | 223 +
4 files changed, 311 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
create mode 100644 drivers/regulator/rt4801-regulator.c
diff --git
a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
new file mode 100644
index ..28d30e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt4801-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT4801 Display Bias regulators
+
+maintainers:
+ - ChiYuan Huang
+
+description: |
+ Regulator nodes should be named to DSVP and DSVN. The
+ definition for each of these nodes is defined using the standard
+ binding for regulators at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT4801H/DS4801H-00.pdf
+
+#The valid names for RT4801 regulator nodes are:
+#DSVP, DSVN
+
+properties:
+ compatible:
+enum:
+ - richtek,rt4801
+
+ reg:
+maxItems: 1
+
+ enable-gpios:
+description: GPIOs to use to enable DSVP/DSVN regulator.
+ The first one is ENP to enable DSVP, and second one is ENM to enable
DSVN.
+ Number of GPIO in the array list could be 1 or 2.
+ If only one gpio is specified, only one gpio used to control ENP/ENM.
+ Else both are spefied, DSVP/DSVN could be controlled individually.
+ Othersie, this property not specified. treat both as always-on regulator.
+minItems: 1
+maxItems: 2
+
+patternProperties:
+ "^DSV(P|N)$":
+type: object
+$ref: regulator.yaml#
+description:
+ Properties for single display bias regulator.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ - enable-gpios
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+rt4801@73 {
+compatible = "richtek,rt4801";
+reg = <0x73>;
+enable-gpios = <&gpio26 2 0>, <&gpio26 3 0>;
+
+dsvp: DSVP {
+regulator-name = "rt4801,dsvp";
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <600>;
+regulator-boot-on;
+};
+dsvn: DSVN {
+regulator-name = "rt4801,dsvn";
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <600>;
+regulator-boot-on;
+};
+
+};
+};
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index de17ef7..2786f11 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -894,6 +894,13 @@ config REGULATOR_RN5T618
config REGULATOR_ROHM
tristate
+config REGULATOR_RT4801
+ tristate "Richtek RT4801 Regulators"
+ depends on I2C
+ help
+ This adds support for voltage regulators in Richtek RT4801 Display
Bias IC.
+ The device supports two regulators (DSVP/DSVN).
+
config REGULATOR_RT5033
tristate "Richtek RT5033 Regulators"
depends on MFD_RT5033
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index d8d3ecf..d091e52d 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_REGULATOR_RC5T583) += rc5t583-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808-regulator.o
obj-$(CONFIG_REGULATOR_RN5T618) += rn5t618-regulator.o
obj-$(CONFIG_REGULATOR_ROHM) += rohm-regulator.o
+obj-$(CONFIG_REGULATOR_RT4801) += rt4801-regulator.o
obj-$(CONFIG_REGULATOR_RT5033) += rt5033-regulator.o
obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
diff --git a/drivers/regulator/rt4801-regulator.c
b/drivers/regulator/rt4801-regulator.c
new file mode 100644
index ..0ddc670
--- /dev/null
+++ b/drivers/regulator/rt4801-regulator.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RT4801_REG_VOP 0x00
+#define RT4801_REG_VON 0x01
+#define RT4801_REG_APPS0x03
+
+#define VOUT_MASK 0x1F
+
+#define MIN_UV 400
+#define STEP_UV10
+#define MAX_UV
Re: [RFC][PATCH 2/2] dma-heap: Add a system-uncached heap
On Mon, Aug 3, 2020 at 4:06 AM Robin Murphy wrote:
>
> On 2020-07-29 06:16, John Stultz wrote:
> > This adds a heap that allocates non-contiguous buffers that are
> > marked as writecombined, so they are not cached by the CPU.
> >
...
> > + ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
> > + if (ret) {
> > + kfree(new_table);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + new_sg = new_table->sgl;
> > + for_each_sg(table->sgl, sg, table->nents, i) {
>
> Consider using the new sgtable helpers that are just about to land - in
> this case, for_each_sgtable_sg().
Ack! Thanks for the suggestion!
> > + memcpy(new_sg, sg, sizeof(*sg));
> > + new_sg->dma_address = 0;
>
> This seems a little bit hairy, as in theory a consumer could still treat
> a nonzero DMA length as the address being valid. Rather than copying the
> whole entry then trying to undo parts of that, maybe just:
>
> sg_set_page(new_sg, sg_page(sg), sg->len, sg->offset);
>
> ?
Sounds good.
> > +static struct sg_table *dma_heap_map_dma_buf(struct dma_buf_attachment
> > *attachment,
> > + enum dma_data_direction
> > direction)
> > +{
> > + struct dma_heap_attachment *a = attachment->priv;
> > + struct sg_table *table = a->table;
> > +
> > + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> > direction,
> > + DMA_ATTR_SKIP_CPU_SYNC |
> > DMA_ATTR_WRITE_COMBINE))
>
> dma_map_sgtable()
>
> Also, DMA_ATTR_WRITE_COMBINE is meaningless for streaming DMA.
>
Hrm. Ok, my grasp of "streaming" vs "consistent" definitions are maybe
slightly off, since while we are mapping and unmapping buffers, the
point of this heap is that the allocated memory is uncached/coherent,
so we avoid the cache sync overhead on each mapping/unmapping, which I
thought was closer to the "consistent" definition.
But maybe if the mapping and unmapping part is really the key
difference, then ok.
Either way, from my testing, you seem to be right that the
ATTR_WRITE_COMBINE doesn't seem to make any difference in behavior.
> > + pgprot = pgprot_writecombine(PAGE_KERNEL);
> > +
> > + for_each_sg(table->sgl, sg, table->nents, i) {
>
> for_each_sg_page()
Ack.
> > + /*
> > + * XXX This is hackish. While the buffer will be uncached, we need
> > + * to initially flush cpu cache, since the the __GFP_ZERO on the
> > + * allocation means the zeroing was done by the cpu and thus it is
> > likely
> > + * cached. Map & flush it out now so we don't get corruption later on.
> > + *
> > + * Ideally we could do this without using the heap device as a dummy
> > dev.
> > + */
> > + dma_map_sg_attrs(dma_heap_get_dev(heap), table->sgl, table->nents,
> > + DMA_BIDIRECTIONAL, DMA_ATTR_WRITE_COMBINE);
>
> Again, DMA_ATTR_WRITE_COMBINE is meaningless here.
>
> > + dma_sync_sg_for_device(dma_heap_get_dev(heap), table->sgl,
> > table->nents,
> > +DMA_BIDIRECTIONAL);
>
> This doesn't do anything that the map hasn't already just done.
Good point!
> > + }
> > + dma_heap_get_dev(heap->heap)->dma_mask = &dummy_mask;
> > + dma_set_mask(dma_heap_get_dev(heap->heap), DMA_BIT_MASK(64));
>
> Much as I'd hate to encourage using dma_coerce_mask_and_coherent(), I'm
> not sure this is really any better :/
Sounds fair.
Thanks so much for the review, I really appreciate the feedback!
(Sorry I was a little slow to respond. The merge window has really
been something this cycle.. :P)
I'll get this all integrated and resend the patch here shortly.
thanks
-john
[PATCH v2 3/4] powerpc: Rewrite 4xx flush_cache_instruction() in C
Nothing prevents flush_cache_instruction() from being writen in C.
Do it to improve readability and maintainability.
This function is very small and isn't called from assembly,
make it static inline in asm/cacheflush.h
Signed-off-by: Christophe Leroy
---
v2: Written as a static inline instead of adding a new C file for this function
alone.
---
arch/powerpc/include/asm/cacheflush.h | 8
arch/powerpc/kernel/misc_32.S | 7 +--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 481877879fec..138e46d8c04e 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -98,7 +98,15 @@ static inline void invalidate_dcache_range(unsigned long
start,
mb(); /* sync */
}
+#ifdef CONFIG_4xx
+static inline void flush_instruction_cache(void)
+{
+ iccci((void *)KERNELBASE);
+ isync();
+}
+#else
void flush_instruction_cache(void);
+#endif
#include
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 5c074c2ff5b5..1bda207459a8 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -272,12 +272,8 @@ _ASM_NOKPROBE_SYMBOL(real_writeb)
/*
* Flush instruction cache.
*/
-#if !defined(CONFIG_PPC_8xx) && !defined(CONFIG_PPC_BOOK3S_32)
+#ifdef CONFIG_FSL_BOOKE
_GLOBAL(flush_instruction_cache)
-#if defined(CONFIG_4xx)
- lis r3, KERNELBASE@h
- iccci 0,r3
-#elif defined(CONFIG_FSL_BOOKE)
#ifdef CONFIG_E200
mfspr r3,SPRN_L1CSR0
ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC
@@ -289,7 +285,6 @@ _GLOBAL(flush_instruction_cache)
mfspr r3,SPRN_L1CSR1
ori r3,r3,L1CSR1_ICFI|L1CSR1_ICLFR
mtspr SPRN_L1CSR1,r3
-#endif /* CONFIG_4xx */
isync
blr
EXPORT_SYMBOL(flush_instruction_cache)
--
2.25.0
[PATCH v2 1/4] powerpc: Remove flush_instruction_cache for book3s/32
The only callers of flush_instruction_cache() are: arch/powerpc/kernel/swsusp_booke.S: bl flush_instruction_cache arch/powerpc/mm/nohash/40x.c: flush_instruction_cache(); arch/powerpc/mm/nohash/44x.c: flush_instruction_cache(); arch/powerpc/mm/nohash/fsl_booke.c: flush_instruction_cache(); arch/powerpc/platforms/44x/machine_check.c: flush_instruction_cache(); arch/powerpc/platforms/44x/machine_check.c: flush_instruction_cache(); This function is not used by book3s/32, drop it. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/misc_32.S | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index b24f866fef81..5c074c2ff5b5 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -271,9 +271,8 @@ _ASM_NOKPROBE_SYMBOL(real_writeb) /* * Flush instruction cache. - * This is a no-op on the 601. */ -#ifndef CONFIG_PPC_8xx +#if !defined(CONFIG_PPC_8xx) && !defined(CONFIG_PPC_BOOK3S_32) _GLOBAL(flush_instruction_cache) #if defined(CONFIG_4xx) lis r3, KERNELBASE@h @@ -290,18 +289,11 @@ _GLOBAL(flush_instruction_cache) mfspr r3,SPRN_L1CSR1 ori r3,r3,L1CSR1_ICFI|L1CSR1_ICLFR mtspr SPRN_L1CSR1,r3 -#elif defined(CONFIG_PPC_BOOK3S_601) - blr /* for 601, do nothing */ -#else - /* 603/604 processor - use invalidate-all bit in HID0 */ - mfspr r3,SPRN_HID0 - ori r3,r3,HID0_ICFI - mtspr SPRN_HID0,r3 #endif /* CONFIG_4xx */ isync blr EXPORT_SYMBOL(flush_instruction_cache) -#endif /* CONFIG_PPC_8xx */ +#endif /* * Copy a whole page. We use the dcbz instruction on the destination -- 2.25.0
[PATCH v2 2/4] powerpc: Move flush_instruction_cache() prototype in asm/cacheflush.h
flush_instruction_cache() belongs to the cache flushing function
family.
Move its prototype in asm/cacheflush.h
Signed-off-by: Christophe Leroy
---
v2: new
---
arch/powerpc/include/asm/cacheflush.h | 2 ++
arch/powerpc/include/asm/processor.h | 1 -
arch/powerpc/platforms/44x/machine_check.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 54764c6e922d..481877879fec 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -98,6 +98,8 @@ static inline void invalidate_dcache_range(unsigned long
start,
mb(); /* sync */
}
+void flush_instruction_cache(void);
+
#include
#endif /* _ASM_POWERPC_CACHEFLUSH_H */
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..d828813e35de 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -435,7 +435,6 @@ extern void power7_idle_type(unsigned long type);
extern void power9_idle_type(unsigned long stop_psscr_val,
unsigned long stop_psscr_mask);
-extern void flush_instruction_cache(void);
extern void hard_reset_now(void);
extern void poweroff_now(void);
extern int fix_alignment(struct pt_regs *);
diff --git a/arch/powerpc/platforms/44x/machine_check.c
b/arch/powerpc/platforms/44x/machine_check.c
index 90ad6ac529d2..a5c898bb9bab 100644
--- a/arch/powerpc/platforms/44x/machine_check.c
+++ b/arch/powerpc/platforms/44x/machine_check.c
@@ -7,6 +7,7 @@
#include
#include
+#include
int machine_check_440A(struct pt_regs *regs)
{
--
2.25.0
[PATCH v2 4/4] powerpc: Rewrite FSL_BOOKE flush_cache_instruction() in C
Nothing prevents flush_cache_instruction() from being writen in C.
Do it to improve readability and maintainability.
This function is only use by low level callers, it is not
intended to be used by module. Don't export it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/misc_32.S | 22 --
arch/powerpc/mm/nohash/fsl_booke.c | 16
2 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 1bda207459a8..87717966f5cd 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -268,28 +268,6 @@ _ASM_NOKPROBE_SYMBOL(real_writeb)
#endif /* CONFIG_40x */
-
-/*
- * Flush instruction cache.
- */
-#ifdef CONFIG_FSL_BOOKE
-_GLOBAL(flush_instruction_cache)
-#ifdef CONFIG_E200
- mfspr r3,SPRN_L1CSR0
- ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC
- /* msync; isync recommended here */
- mtspr SPRN_L1CSR0,r3
- isync
- blr
-#endif
- mfspr r3,SPRN_L1CSR1
- ori r3,r3,L1CSR1_ICFI|L1CSR1_ICLFR
- mtspr SPRN_L1CSR1,r3
- isync
- blr
-EXPORT_SYMBOL(flush_instruction_cache)
-#endif
-
/*
* Copy a whole page. We use the dcbz instruction on the destination
* to reduce memory traffic (it eliminates the unnecessary reads of
diff --git a/arch/powerpc/mm/nohash/fsl_booke.c
b/arch/powerpc/mm/nohash/fsl_booke.c
index 0c294827d6e5..36bda962d3b3 100644
--- a/arch/powerpc/mm/nohash/fsl_booke.c
+++ b/arch/powerpc/mm/nohash/fsl_booke.c
@@ -219,6 +219,22 @@ unsigned long __init mmu_mapin_ram(unsigned long base,
unsigned long top)
return tlbcam_addrs[tlbcam_index - 1].limit - PAGE_OFFSET + 1;
}
+void flush_instruction_cache(void)
+{
+ unsigned long tmp;
+
+ if (IS_ENABLED(CONFIG_E200)) {
+ tmp = mfspr(SPRN_L1CSR0);
+ tmp |= L1CSR0_CFI | L1CSR0_CLFC;
+ mtspr(SPRN_L1CSR0, tmp);
+ } else {
+ tmp = mfspr(SPRN_L1CSR1);
+ tmp |= L1CSR1_ICFI | L1CSR1_ICLFR;
+ mtspr(SPRN_L1CSR1, tmp);
+ }
+ isync();
+}
+
/*
* MMU_init_hw does the chip-specific initialization of the MMU hardware.
*/
--
2.25.0
[PATCH] usb: gadget: f_tcm: Fix some resource leaks in some error paths
If a memory allocation fails within a 'usb_ep_alloc_request()' call, the
already allocated memory must be released.
Fix a mix-up in the code and free the correct requests.
Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP +
BOT")
Signed-off-by: Christophe JAILLET
---
drivers/usb/gadget/function/f_tcm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_tcm.c
b/drivers/usb/gadget/function/f_tcm.c
index d94b814328c8..184165e27908 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -753,12 +753,13 @@ static int uasp_alloc_stream_res(struct f_uas *fu, struct
uas_stream *stream)
goto err_sts;
return 0;
+
err_sts:
- usb_ep_free_request(fu->ep_status, stream->req_status);
- stream->req_status = NULL;
-err_out:
usb_ep_free_request(fu->ep_out, stream->req_out);
stream->req_out = NULL;
+err_out:
+ usb_ep_free_request(fu->ep_in, stream->req_in);
+ stream->req_in = NULL;
out:
return -ENOMEM;
}
--
2.25.1
Re: [PATCH 1/5] powerpc: Remove flush_instruction_cache for book3s/32
Le 13/08/2020 à 14:14, Christoph Hellwig a écrit : On Thu, Aug 13, 2020 at 01:13:08PM +0100, Christoph Hellwig wrote: On Thu, Aug 13, 2020 at 10:12:00AM +, Christophe Leroy wrote: -#ifndef CONFIG_PPC_8xx +#if !defined(CONFIG_PPC_8xx) && !defined(CONFIG_PPC_BOOK3S_32) _GLOBAL(flush_instruction_cache) #if defined(CONFIG_4xx) lis r3, KERNELBASE@h @@ -290,18 +289,11 @@ _GLOBAL(flush_instruction_cache) mfspr r3,SPRN_L1CSR1 ori r3,r3,L1CSR1_ICFI|L1CSR1_ICLFR mtspr SPRN_L1CSR1,r3 -#elif defined(CONFIG_PPC_BOOK3S_601) - blr /* for 601, do nothing */ -#else - /* 603/604 processor - use invalidate-all bit in HID0 */ - mfspr r3,SPRN_HID0 - ori r3,r3,HID0_ICFI - mtspr SPRN_HID0,r3 #endif /* CONFIG_4xx */ isync blr EXPORT_SYMBOL(flush_instruction_cache) -#endif /* CONFIG_PPC_8xx */ +#endif /* CONFIG_PPC_8xx || CONFIG_PPC_BOOK3S_32 */ What about untangling this into entirely separate versions instead of the ifdef mess? Also the export does not seem to be needed at all. Ok, I see that you do that later, sorry. In v2, I drop the untangling patch, because the series completely dismantles flush_instruction_cache() so there is no need for an ephemeral untanggled version of it. Christophe
Re: [PATCH] perf stat: update POWER9 metrics to utilize other metrics
On 8/14/20 9:13 AM, Ian Rogers wrote:
> On Thu, Aug 13, 2020 at 3:21 PM Paul A. Clarke wrote:
>>
>> These changes take advantage of the new capability added in
>> merge commit 00e4db51259a5f936fec1424b884f029479d3981
>> "Allow using computed metrics in calculating other metrics".
>>
>> The net is a simplification of the expressions for a handful
>> of metrics, but no functional change.
>>
>> Signed-off-by: Paul A. Clarke
>
Hi Paul,
The patch looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
> Acked-by: Ian Rogers
> (Re-sent with plain text enabled to avoid lkml bounce)
>
> Thanks,
> Ian
>
>
>>
>> ---
>> .../arch/powerpc/power9/metrics.json | 48 +--
>> 1 file changed, 24 insertions(+), 24 deletions(-)
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> index 80816d6402e9..f8784c608479 100644
>> --- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> +++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
>> @@ -60,7 +60,7 @@
>> },
>> {
>> "BriefDescription": "Stalls due to short latency decimal floating
>> ops.",
>> -"MetricExpr": "(PM_CMPLU_STALL_DFU -
>> PM_CMPLU_STALL_DFLONG)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dfu_stall_cpi - dflong_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "dfu_other_stall_cpi"
>> },
>> @@ -72,7 +72,7 @@
>> },
>> {
>> "BriefDescription": "Completion stall by Dcache miss which resolved
>> off node memory/cache",
>> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS -
>> PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM -
>> PM_CMPLU_STALL_DMISS_REMOTE)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dmiss_non_local_stall_cpi - dmiss_remote_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "dmiss_distant_stall_cpi"
>> },
>> @@ -90,7 +90,7 @@
>> },
>> {
>> "BriefDescription": "Completion stall due to cache miss that
>> resolves in the L2 or L3 without conflict",
>> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L2L3 -
>> PM_CMPLU_STALL_DMISS_L2L3_CONFLICT)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dmiss_l2l3_stall_cpi -
>> dmiss_l2l3_conflict_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "dmiss_l2l3_noconflict_stall_cpi"
>> },
>> @@ -114,7 +114,7 @@
>> },
>> {
>> "BriefDescription": "Completion stall by Dcache miss which resolved
>> outside of local memory",
>> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS -
>> PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dmiss_l3miss_stall_cpi - dmiss_l21_l31_stall_cpi -
>> dmiss_lmem_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "dmiss_non_local_stall_cpi"
>> },
>> @@ -126,7 +126,7 @@
>> },
>> {
>> "BriefDescription": "Stalls due to short latency double precision
>> ops.",
>> -"MetricExpr": "(PM_CMPLU_STALL_DP -
>> PM_CMPLU_STALL_DPLONG)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "dp_stall_cpi - dplong_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "dp_other_stall_cpi"
>> },
>> @@ -155,7 +155,7 @@
>> "MetricName": "emq_full_stall_cpi"
>> },
>> {
>> -"MetricExpr": "(PM_CMPLU_STALL_ERAT_MISS +
>> PM_CMPLU_STALL_EMQ_FULL)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "erat_miss_stall_cpi + emq_full_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "emq_stall_cpi"
>> },
>> @@ -173,7 +173,7 @@
>> },
>> {
>> "BriefDescription": "Completion stall due to execution units for
>> other reasons.",
>> -"MetricExpr": "(PM_CMPLU_STALL_EXEC_UNIT - PM_CMPLU_STALL_FXU -
>> PM_CMPLU_STALL_DP - PM_CMPLU_STALL_DFU - PM_CMPLU_STALL_PM -
>> PM_CMPLU_STALL_CRYPTO - PM_CMPLU_STALL_VFXU -
>> PM_CMPLU_STALL_VDP)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "exec_unit_stall_cpi - scalar_stall_cpi -
>> vector_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "exec_unit_other_stall_cpi"
>> },
>> @@ -197,7 +197,7 @@
>> },
>> {
>> "BriefDescription": "Stalls due to short latency integer ops",
>> -"MetricExpr": "(PM_CMPLU_STALL_FXU -
>> PM_CMPLU_STALL_FXLONG)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "fxu_stall_cpi - fxlong_stall_cpi",
>> "MetricGroup": "cpi_breakdown",
>> "MetricName": "fxu_other_stall_cpi"
>> },
>> @@ -221,7 +221,7 @@
>> },
>> {
>> "BriefDescription": "Instruction Completion Table other stalls",
>> -"MetricExpr": "(PM_ICT_NOSLOT_CYC - PM_ICT_NOSLOT_IC_MISS -
>> PM_ICT_NOSLOT_BR_MPRED_ICMISS - PM_ICT_NOSLOT_BR_MPRED -
>> PM_ICT_NOSLOT_DISP_HELD)/PM_RUN_INST_CMPL",
>> +"MetricExpr": "nothing
Re: [PATCH] kexec: Delete an unnecessary comparison
On 08/13/20 at 08:45pm, Youling Tang wrote: > Regardless of whether the ret value is zero or non-zero, the trajectory > of the program execution is the same, so there is no need to compare. > > Signed-off-by: Youling Tang > --- > kernel/kexec_file.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > index 78c0837..3ad0ae2 100644 > --- a/kernel/kexec_file.c > +++ b/kernel/kexec_file.c > @@ -800,8 +800,6 @@ static int kexec_calculate_store_digests(struct kimage > *image) > > ret = kexec_purgatory_get_set_symbol(image, > "purgatory_sha256_digest", >digest, > SHA256_DIGEST_SIZE, 0); > - if (ret) > - goto out_free_digest; > } > > out_free_digest: > -- > 2.1.0 > Acked-by: Dave Young Thanks Dave
[PATCH v2] powerpc: Remove flush_instruction_cache() on 8xx
flush_instruction_cache() is never used on 8xx, remove it.
Signed-off-by: Christophe Leroy
---
v2: Becomes a standalone patch independant of the series dismantling the ASM
flush_instruction_cache()
---
arch/powerpc/mm/nohash/8xx.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c
index d2b37146ae6c..231ca95f9ffb 100644
--- a/arch/powerpc/mm/nohash/8xx.c
+++ b/arch/powerpc/mm/nohash/8xx.c
@@ -244,13 +244,6 @@ void set_context(unsigned long id, pgd_t *pgd)
mb();
}
-void flush_instruction_cache(void)
-{
- isync();
- mtspr(SPRN_IC_CST, IDC_INVALL);
- isync();
-}
-
#ifdef CONFIG_PPC_KUEP
void __init setup_kuep(bool disabled)
{
--
2.25.0
Re: [PATCH v4 2/2] fcntl: introduce F_SET_DESCRIPTION
On Thu, Aug 13, 2020 at 10:28 PM Christoph Hellwig wrote: > > One intended usage is to allow processes to self-document sockets > > for netstat and friends to report > > NAK. There is no way we're going to bloat a criticial structure like > struct file for some vanity information like this. The useful case is for sockets - Is there a more suited place to do that? Do you think adding a setsockopt and sk_description to struct sock would work, or would be considered the same?
[PATCH v5 2/2] Add Intel LGM soc DMA support.
Add DMA controller driver for Lightning Mountain(LGM) family of SoCs.
The main function of the DMA controller is the transfer of data from/to any
DPlus compliant peripheral to/from the memory. A memory to memory copy
capability can also be configured.
This ldma driver is used for configure the device and channnels for data
and control paths.
Signed-off-by: Amireddy Mallikarjuna reddy
---
v1:
- Initial version.
v2:
- Fix device tree bot issues, correspondign driver changes done.
- Fix kerntel test robot warnings.
>> drivers/dma/lgm/lgm-dma.c:729:5: warning: no previous prototype for
function 'intel_dma_chan_desc_cfg' [-Wmissing-prototypes]
int intel_dma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base,
^
drivers/dma/lgm/lgm-dma.c:729:1: note: declare 'static' if the function is
not intended to be used outside of this translation unit
int intel_dma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base,
^
static
1 warning generated.
vim +/intel_dma_chan_desc_cfg +729 drivers/dma/lgm/lgm-dma.c
728
> 729 int intel_dma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base,
730 int desc_num)
731 {
732 return ldma_chan_desc_cfg(to_ldma_chan(chan), desc_base,
desc_num);
733 }
734 EXPORT_SYMBOL_GPL(intel_dma_chan_desc_cfg);
735
Reported-by: kernel test robot
---
v3:
- Fix smatch warning.
smatch warnings:
drivers/dma/lgm/lgm-dma.c:1306 ldma_cfg_init() error: uninitialized symbol
'ret'.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
v4:
- Address Thomas Langer comments in dtbinding and corresponding driver side
changes.
- Driver side changes to corresponding device tree changes.
v5:
- Add changes to read 'dmas' properties and update the config properties driver
side.
- Add virt_dma_desc utilizes virt-dma API.
---
drivers/dma/Kconfig |2 +
drivers/dma/Makefile|1 +
drivers/dma/lgm/Kconfig |9 +
drivers/dma/lgm/Makefile|2 +
drivers/dma/lgm/lgm-dma.c | 1944 +++
include/linux/dma/lgm_dma.h | 27 +
6 files changed, 1985 insertions(+)
create mode 100644 drivers/dma/lgm/Kconfig
create mode 100644 drivers/dma/lgm/Makefile
create mode 100644 drivers/dma/lgm/lgm-dma.c
create mode 100644 include/linux/dma/lgm_dma.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index de41d7928bff..caeaf12fd524 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -737,6 +737,8 @@ source "drivers/dma/ti/Kconfig"
source "drivers/dma/fsl-dpaa2-qdma/Kconfig"
+source "drivers/dma/lgm/Kconfig"
+
# clients
comment "DMA Clients"
depends on DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e60f81331d4c..0b899b076f4e 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx_dma.o
obj-$(CONFIG_ST_FDMA) += st_fdma.o
obj-$(CONFIG_FSL_DPAA2_QDMA) += fsl-dpaa2-qdma/
+obj-$(CONFIG_INTEL_LDMA) += lgm/
obj-y += mediatek/
obj-y += qcom/
diff --git a/drivers/dma/lgm/Kconfig b/drivers/dma/lgm/Kconfig
new file mode 100644
index ..bdb5b0d91afb
--- /dev/null
+++ b/drivers/dma/lgm/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config INTEL_LDMA
+ bool "Lightning Mountain centralized low speed DMA and high speed DMA
controllers"
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Enable support for intel Lightning Mountain SOC DMA controllers.
+ These controllers provide DMA capabilities for a variety of on-chip
+ devices such as SSC, HSNAND and GSWIP.
diff --git a/drivers/dma/lgm/Makefile b/drivers/dma/lgm/Makefile
new file mode 100644
index ..f318a8eff464
--- /dev/null
+++ b/drivers/dma/lgm/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_INTEL_LDMA) += lgm-dma.o
diff --git a/drivers/dma/lgm/lgm-dma.c b/drivers/dma/lgm/lgm-dma.c
new file mode 100644
index ..4bd6ef9a2656
--- /dev/null
+++ b/drivers/dma/lgm/lgm-dma.c
@@ -0,0 +1,1944 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lightning Mountain centralized low speed and high speed DMA controller
driver
+ *
+ * Copyright (c) 2016 ~ 2020 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+#include "../virt-dma.h"
+
+#define DRIVER_NAME"lgm-ldma"
+
+#define DMA_ID 0x0008
+#define DMA_ID_REV GENMASK(7, 0)
+#define DMA_ID_PNR
Re: [PATCH] dma-debug: fix debug_dma_assert_idle(), use rcu_read_lock()
On Thu, Aug 13, 2020 at 12:02:41PM -0700, Linus Torvalds wrote:
> Yeah, that's ridiculously expensive, and serializes things for no good reason.
>
> Your patch looks obviously correct to me (Christoph?),
It also looks correct to me.
> but it also
> makes me go "why are we doing this in the first place"?
>
> Because it looks to me like
> (a) the debug check is wrong
> (b) this is left-over from early debugging
>
> In particular, I don't see why we couldn't do a COW on a page that is
> under writeback at the same time. We're not changing the page that is
> doing DMA.
Yes. We don't need to check for a DMA to the device, but a DMA from
the device while under DMA obviously is bogus. But then again you'd
need to try really hard to do that.
> In fact, the whole "COW with DMA" makes me feel like the real bug may
> have been due that whole "ambiguous COW" thing, which was fixed in
> 17839856fd58 ("gup: document and work around "COW can break either
> way" issue")
>
> That debug thing goes back almost 7 years, and I don't think it has
> caught anything in those seven years, but I could be wrong.
>
> The commit that adds it does talk about a bug, but that code was
> removed entirely eventually. And google shows no hits for
> debug_dma_assert_idle() since - until your email.
>
> So my gut feel is that we should remove the check entirely, although
> your patch does seem like a big improvement.
>
> Christoph?
The whole thing predates my involvement with the code, but I defintively
think the patch from Hugh is a major improvement. But I would also
have no problem with just removing it entirely.
[PATCH v2] media: v4l2-ctrl: add control for long term reference.
LTR (Long Term Reference) frames are the frames that are encoded
sometime in the past and stored in the DPB buffer list to be used
as reference to encode future frames.
This change adds controls to enable this feature.
Signed-off-by: Dikshita Agarwal
---
.../userspace-api/media/v4l/ext-ctrls-codec.rst| 23 ++
drivers/media/v4l2-core/v4l2-ctrls.c | 6 ++
include/uapi/linux/v4l2-controls.h | 4
3 files changed, 33 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index d0d506a..6d1b005 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -4272,3 +4272,26 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
- Selecting this value specifies that HEVC slices are expected
to be prefixed by Annex B start codes. According to :ref:`hevc`
valid start codes can be 3-bytes 0x01 or 4-bytes 0x0001.
+
+``V4L2_CID_MPEG_VIDEO_LTRCOUNT (enum)``
+ Specifies the number of Long Term Reference frames encoder needs to
+ generate or keep.
+ This control is used to query or configure the number of Long Term
+ Reference frames.
+
+``V4L2_CID_MPEG_VIDEO_MARKLTRFRAME (enum)``
+ This control is used to mark current frame as Long Term Reference
+ frame.
+ this provides a Long Term Reference index that ranges from 0
+ to LTR count-1 and then the particular frame will be marked with that
+ Long Term Reference index.
+
+``V4L2_CID_MPEG_VIDEO_USELTRFRAME (enum)``
+ Specifies the Long Term Reference frame(s) to be used for encoding
+ the current frame.
+ This provides a bitmask which consists of bits [0, 15]. A total of N
+ LSB bits of this field are valid, where N is the maximum number of
+ Long Term Reference frames supported.
+ All the other bits are invalid and should be rejected.
+ The LSB corresponds to the Long Term Reference index 0. Bit N-1 from
+ the LSB corresponds to the Long Term Reference index max LTR count-1.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 3f3fbcd..3138c72 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -991,6 +991,9 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS: return "HEVC
Slice Parameters";
case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
Decode Mode";
case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return "HEVC
Start Code";
+ case V4L2_CID_MPEG_VIDEO_LTRCOUNT: return "LTR Count";
+ case V4L2_CID_MPEG_VIDEO_MARKLTRFRAME: return "Mark LTR";
+ case V4L2_CID_MPEG_VIDEO_USELTRFRAME: return "Use LTR";
/* CAMERA controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1224,6 +1227,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
break;
case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ case V4L2_CID_MPEG_VIDEO_LTRCOUNT:
+ case V4L2_CID_MPEG_VIDEO_MARKLTRFRAME:
+ case V4L2_CID_MPEG_VIDEO_USELTRFRAME:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 6227141..f2daa86 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -742,6 +742,10 @@ enum v4l2_cid_mpeg_video_hevc_size_of_length_field {
#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR (V4L2_CID_MPEG_BASE +
642)
#define V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES (V4L2_CID_MPEG_BASE +
643)
#define V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR (V4L2_CID_MPEG_BASE +
644)
+#define V4L2_CID_MPEG_VIDEO_LTRCOUNT (V4L2_CID_MPEG_BASE + 645)
+#define V4L2_CID_MPEG_VIDEO_MARKLTRFRAME (V4L2_CID_MPEG_BASE + 646)
+#define V4L2_CID_MPEG_VIDEO_USELTRFRAME(V4L2_CID_MPEG_BASE +
647)
+
/* MPEG-class control IDs specific to the CX2341x driver as defined by V4L2 */
#define V4L2_CID_MPEG_CX2341X_BASE
(V4L2_CTRL_CLASS_MPEG | 0x1000)
--
1.9.1
Re: [PATCH v4 2/2] fcntl: introduce F_SET_DESCRIPTION
On Thu, Aug 13, 2020 at 08:54:53PM -0700, Pascal Bouchareine wrote: > This command attaches a description to a file descriptor for > troubleshooting purposes. The free string is displayed in the > process fdinfo file for that fd /proc/pid/fdinfo/fd. > > One intended usage is to allow processes to self-document sockets > for netstat and friends to report NAK. There is no way we're going to bloat a criticial structure like struct file for some vanity information like this.
[PATCH v5 0/2] Add Intel LGM soc DMA support
Add DMA controller driver for Lightning Mountain(LGM) family of SoCs. The main function of the DMA controller is the transfer of data from/to any DPlus compliant peripheral to/from the memory. A memory to memory copy capability can also be configured. This ldma driver is used for configure the device and channnels for data and control paths. These controllers provide DMA capabilities for a variety of on-chip devices such as SSC, HSNAND and GSWIP. - Future Plans: - LGM SOC also supports Hardware Memory Copy engine. The role of the HW Memory copy engine is to offload memory copy operations from the CPU. Amireddy Mallikarjuna reddy (2): dt-bindings: dma: Add bindings for intel LGM SOC Add Intel LGM soc DMA support. .../devicetree/bindings/dma/intel,ldma.yaml| 319 drivers/dma/Kconfig|2 + drivers/dma/Makefile |1 + drivers/dma/lgm/Kconfig|9 + drivers/dma/lgm/Makefile |2 + drivers/dma/lgm/lgm-dma.c | 1944 include/linux/dma/lgm_dma.h| 27 + 7 files changed, 2304 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/intel,ldma.yaml create mode 100644 drivers/dma/lgm/Kconfig create mode 100644 drivers/dma/lgm/Makefile create mode 100644 drivers/dma/lgm/lgm-dma.c create mode 100644 include/linux/dma/lgm_dma.h -- 2.11.0
[PATCH v5 1/2] dt-bindings: dma: Add bindings for intel LGM SOC
Add DT bindings YAML schema for DMA controller driver of Lightning Mountain(LGM) SoC. Signed-off-by: Amireddy Mallikarjuna reddy --- v1: - Initial version. v2: - Fix bot errors. v3: - No change. v4: - Address Thomas langer comments - use node name pattern as dma-controller as in common binding. - Remove "_" (underscore) in instance name. - Remove "port-" and "chan-" in attribute name for both 'dma-ports' & 'dma-channels' child nodes. v5: - Moved some of the attributes in 'dma-ports' & 'dma-channels' child nodes to dma client/consumer side as cells in 'dmas' properties. --- .../devicetree/bindings/dma/intel,ldma.yaml| 319 + 1 file changed, 319 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/intel,ldma.yaml diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml b/Documentation/devicetree/bindings/dma/intel,ldma.yaml new file mode 100644 index ..9beaf191a6de --- /dev/null +++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml @@ -0,0 +1,319 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/intel,ldma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lightning Mountain centralized low speed DMA and high speed DMA controllers. + +maintainers: + - chuanhua@intel.com + - mallikarjunax.re...@intel.com + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + $nodename: + pattern: "^dma-controller(@.*)?$" + + "#dma-cells": + const: 1 + + compatible: + anyOf: + - const: intel,lgm-cdma + - const: intel,lgm-dma2tx + - const: intel,lgm-dma1rx + - const: intel,lgm-dma1tx + - const: intel,lgm-dma0tx + - const: intel,lgm-dma3 + - const: intel,lgm-toe-dma30 + - const: intel,lgm-toe-dma31 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + intel,dma-poll-cnt: + $ref: /schemas/types.yaml#definitions/uint32 + description: + DMA descriptor polling counter. It may need fine tune according + to the system application scenario. + + intel,dma-byte-en: + type: boolean + description: + DMA byte enable is only valid for DMA write(RX). + Byte enable(1) means DMA write will be based on the number of dwords + instead of the whole burst. + + intel,dma-drb: +type: boolean +description: + DMA descriptor read back to make sure data and desc synchronization. + + intel,dma-burst: +$ref: /schemas/types.yaml#definitions/uint32 +description: + Specifiy the DMA burst size(in dwords), the valid value will be 8, 16, 32. + Default is 16 for data path dma, 32 is for memcopy DMA. + + intel,dma-polling-cnt: +$ref: /schemas/types.yaml#definitions/uint32 +description: + DMA descriptor polling counter. It may need fine tune according to + the system application scenario. + + intel,dma-desc-in-sram: +type: boolean +description: + DMA descritpors in SRAM or not. Some old controllers descriptors + can be in DRAM or SRAM. The new ones are all in SRAM. + + intel,dma-orrc: +$ref: /schemas/types.yaml#definitions/uint32 +description: + DMA outstanding read counter. The maximum value is 16, and it may + need fine tune according to the system application scenarios. + + intel,dma-dburst-wr: +type: boolean +description: + Enable RX dynamic burst write. It only applies to RX DMA and memcopy DMA. + + + dma-ports: +type: object +description: + This sub-node must contain a sub-node for each DMA port. +properties: + '#address-cells': +const: 1 + '#size-cells': +const: 0 + +patternProperties: + "^dma-ports@[0-9]+$": + type: object + + properties: +reg: + items: +- enum: [0, 1, 2, 3, 4, 5] + description: + Which port this node refers to. + +intel,name: + $ref: /schemas/types.yaml#definitions/string-array + description: + Port name of each DMA port. + +intel,chans: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + The channels included on this port. Format is channel start + number and how many channels on this port. + + required: +- reg +- intel,name +- intel,chans + + + ldma-channels: +type: object +description: + This sub-node must contain a sub-node for each DMA channel. +properties: + '#address-cells': +const: 1 + '#size-cells': +const: 0 + +patternProperties: + "^ldma-channels@[0-15]+$": + type: object + + properties: +reg: + items: +- enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] + description: +
Re: [RFC PATCH 00/16] Core scheduling v6(Internet mail)
On 2020/8/14 12:04, benbjiang(蒋彪) wrote:
>
>
>> On Aug 14, 2020, at 9:36 AM, Li, Aubrey wrote:
>>
>> On 2020/8/14 8:26, benbjiang(蒋彪) wrote:
>>>
>>>
On Aug 13, 2020, at 12:28 PM, Li, Aubrey wrote:
On 2020/8/13 7:08, Joel Fernandes wrote:
> On Wed, Aug 12, 2020 at 10:01:24AM +0800, Li, Aubrey wrote:
>> Hi Joel,
>>
>> On 2020/8/10 0:44, Joel Fernandes wrote:
>>> Hi Aubrey,
>>>
>>> Apologies for replying late as I was still looking into the details.
>>>
>>> On Wed, Aug 05, 2020 at 11:57:20AM +0800, Li, Aubrey wrote:
>>> [...]
+/*
+ * Core scheduling policy:
+ * - CORE_SCHED_DISABLED: core scheduling is disabled.
+ * - CORE_COOKIE_MATCH: tasks with same cookie can run
+ * on the same core concurrently.
+ * - CORE_COOKIE_TRUST: trusted task can run with kernel
thread on the same core concurrently.
+ * - CORE_COOKIE_LONELY: tasks with cookie can run only
+ * with idle thread on the same core.
+ */
+enum coresched_policy {
+ CORE_SCHED_DISABLED,
+ CORE_SCHED_COOKIE_MATCH,
+ CORE_SCHED_COOKIE_TRUST,
+ CORE_SCHED_COOKIE_LONELY,
+};
We can set policy to CORE_COOKIE_TRUST of uperf cgroup and fix this
kind
of performance regression. Not sure if this sounds attractive?
>>>
>>> Instead of this, I think it can be something simpler IMHO:
>>>
>>> 1. Consider all cookie-0 task as trusted. (Even right now, if you apply
>>> the
>>> core-scheduling patchset, such tasks will share a core and sniff on
>>> each
>>> other. So let us not pretend that such tasks are not trusted).
>>>
>>> 2. All kernel threads and idle task would have a cookie 0 (so that will
>>> cover
>>> ksoftirqd reported in your original issue).
>>>
>>> 3. Add a config option (CONFIG_SCHED_CORE_DEFAULT_TASKS_UNTRUSTED).
>>> Default
>>> enable it. Setting this option would tag all tasks that are forked
>>> from a
>>> cookie-0 task with their own cookie. Later on, such tasks can be added
>>> to
>>> a group. This cover's PeterZ's ask about having 'default untrusted').
>>> (Users like ChromeOS that don't want to userspace system processes to
>>> be
>>> tagged can disable this option so such tasks will be cookie-0).
>>>
>>> 4. Allow prctl/cgroup interfaces to create groups of tasks and override
>>> the
>>> above behaviors.
>>
>> How does uperf in a cgroup work with ksoftirqd? Are you suggesting I set
>> uperf's
>> cookie to be cookie-0 via prctl?
>
> Yes, but let me try to understand better. There are 2 problems here I
> think:
>
> 1. ksoftirqd getting idled when HT is turned on, because uperf is sharing
> a
> core with it: This should not be any worse than SMT OFF, because even SMT
> OFF
> would also reduce ksoftirqd's CPU time just core sched is doing. Sure
> core-scheduling adds some overhead with IPIs but such a huge drop of perf
> is
> strange. Peter any thoughts on that?
>
> 2. Interface: To solve the performance problem, you are saying you want
> uperf
> to share a core with ksoftirqd so that it is not forced into idle. Why
> not
> just keep uperf out of the cgroup?
I guess this is unacceptable for who runs their apps in container and vm.
>>> IMHO, just as Joel proposed,
>>> 1. Consider all cookie-0 task as trusted.
>>> 2. All kernel threads and idle task would have a cookie 0
>>> In that way, all tasks with cookies(including uperf in a cgroup) could run
>>> concurrently with kernel threads.
>>> That could be a good solution for the issue. :)
>>
>> From uperf point of review, it can trust cookie-0(I assume we still need
>> some modifications to change cookie-match to cookie-compatible to allow
>> ZERO and NONZERO run together).
>>
>> But from kernel thread point of review, it can NOT trust uperf, unless
>> we set uperf's cookie to 0.
> That’s right. :)
> Could we set the cookie of cgroup where uperf lies to 0?
>
IMHO the disadvantage is that if there are two or more cgroups set cookie-0,
then the user applications in these cgroups could run concurrently on a core,
though all of them are set as trusted, we made a hole of user->user isolation.
Thanks,
-Aubrey
[PATCH] xhci: Do not use GFP_KERNEL in (potentially) atomic context
'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be
submitted in interrupt context" (see comment related to 'usb_submit_urb()'
in 'drivers/usb/core/urb.c')
So this flag should be used in all the calling chain.
Up to now, 'xhci_check_maxpacket()' which is only called from
'xhci_urb_enqueue()', uses GFP_KERNEL.
Be safe and pass the mem_flags to this function as well.
Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the
command ring")
Signed-off-by: Christophe JAILLET
---
I'm not 100% sure of the Fixes tag. The commit is the only that introduced
this GFP_KERNEL, but I've not checked what was the behavior before that.
If the patch is correct, I guess that a cc stable should be welcome.
---
drivers/usb/host/xhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3c41b14ecce7..b536f18e4cfd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1382,7 +1382,7 @@ static int xhci_configure_endpoint(struct xhci_hcd *xhci,
* we need to issue an evaluate context command and wait on it.
*/
static int xhci_check_maxpacket(struct xhci_hcd *xhci, unsigned int slot_id,
- unsigned int ep_index, struct urb *urb)
+ unsigned int ep_index, struct urb *urb, gfp_t mem_flags)
{
struct xhci_container_ctx *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
@@ -1413,7 +1413,7 @@ static int xhci_check_maxpacket(struct xhci_hcd *xhci,
unsigned int slot_id,
* changes max packet sizes.
*/
- command = xhci_alloc_command(xhci, true, GFP_KERNEL);
+ command = xhci_alloc_command(xhci, true, mem_flags);
if (!command)
return -ENOMEM;
@@ -1509,7 +1509,7 @@ static int xhci_urb_enqueue(struct usb_hcd *hcd, struct
urb *urb, gfp_t mem_flag
*/
if (urb->dev->speed == USB_SPEED_FULL) {
ret = xhci_check_maxpacket(xhci, slot_id,
- ep_index, urb);
+ ep_index, urb, mem_flags);
if (ret < 0) {
xhci_urb_free_priv(urb_priv);
urb->hcpriv = NULL;
--
2.25.1
Re: [PATCH] soc: qcom: socinfo: add SC7180 entry to soc_id array
On 2020-08-13 20:33, Douglas Anderson wrote:
Add an entry for SC7180 SoC.
Signed-off-by: Douglas Anderson
---
drivers/soc/qcom/socinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index e19102f46302..e56eea29615c 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -223,6 +223,7 @@ static const struct soc_id soc_id[] = {
{ 321, "SDM845" },
{ 341, "SDA845" },
{ 356, "SM8250" },
+ { 425, "SC7180" },
};
static const char *socinfo_machine(struct device *dev, unsigned int
id)
From the chipinfo document that I have at hand, this is correct soc id
for SC7180, so
Reviewed-by: Sai Prakash Ranjan
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2] softirq: add irq off checking for __raise_softirq_irqoff
__raise_softirq_irqoff() will update per-CPU mask of pending softirqs,
it need to be called in irq disabled context in order to keep it atomic
operation, otherwise it will be interrupted by hardware interrupt,
and per-CPU softirqs pending mask will be corrupted, the result is
there will be unexpected issue, for example hrtimer soft irq will
be losed and soft hrtimer will never be expire and handled.
Enable CONFIG_PROVE_LOCKING to use lockdep_assert_irqs_disabled() to
check hardirqs and softirqs status, and provide warning in irqs enabled
context.
Signed-off-by: Jiafei Pan
---
Changes in v2:
- use lockdep_assert_irqs_disabled()
- removed extra comments
- changed commit message
kernel/softirq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index bf88d7f62433..09229ad82209 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -481,6 +481,7 @@ void raise_softirq(unsigned int nr)
void __raise_softirq_irqoff(unsigned int nr)
{
+ lockdep_assert_irqs_disabled();
trace_softirq_raise(nr);
or_softirq_pending(1UL << nr);
}
--
2.17.1
[GIT PULL] Kconfig updates for v5.9-rc1
Hi Linus, Please pull Kconfig updates for v5.9-rc1 Thanks. The following changes since commit bcf876870b95592b52519ed4aafcf9d95999bc9c: Linux 5.8 (2020-08-02 14:21:45 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kconfig-v5.9 for you to fetch changes up to d4bbe8a1b55aeaadfa0fa982b468eaec9b799f1a: kconfig: qconf: move setOptionMode() to ConfigList from ConfigView (2020-08-14 13:47:21 +0900) Kconfig updates for v5.9 - remove '---help---' keyword support - fix mouse events for 'menuconfig' symbols in search view of qconf - code cleanups of qconf Masahiro Yamada (23): kconfig: remove '---help---' support Revert "checkpatch: kconfig: prefer 'help' over '---help---'" kconfig: constify XPM data kconfig: add 'static' to some file-local data kconfig: qconf: remove ->addSeparator() to menuBar kconfig: qconf: do not use 'menu' variable for (QMenuBar *) kconfig: qconf: use 'menu' variable for (QMenu *) kconfig: qconf: remove toolBar from ConfigMainWindow members kconfig: qconf: overload addToolBar() to create and insert toolbar kconfig: qconf: remove unused ConfigList::listView() kconfig: qconf: remove name from ConfigSearchWindow constructor kconfig: qconf: omit parent to QHBoxLayout() kconfig: qconf: remove unused argument from ConfigList::updateList() kconfig: qconf: remove unused argument from ConfigView::updateList() kconfig: qconf: remove 'parent' from ConfigList::updateMenuList() kconfig: qconf: drop more localization code kconfig: qconf: remove ConfigItem::pixmap/setPixmap kconfig: qconf: remove ConfigList::addColumn/removeColumn kconfig: qconf: remove ConfigItem::text/setText kconfig: qconf: remove unused voidPix, menuInvPix kconfig: qconf: refactor icon setups kconfig: qconf: do not limit the pop-up menu to the first row kconfig: qconf: move setOptionMode() to ConfigList from ConfigView Maxime Chretien (1): kconfig: qconf: Fix mouse events in search view scripts/checkkconfigsymbols.py | 2 +- scripts/checkpatch.pl | 6 +- scripts/kconfig/images.c | 30 +++ scripts/kconfig/images.h | 30 +++ scripts/kconfig/lexer.l| 4 +- scripts/kconfig/qconf.cc | 319 ++-- scripts/kconfig/qconf.h| 56 +++- scripts/kconfig/symbol.c | 14 ++- 8 files changed, 218 insertions(+), 243 deletions(-) -- Best Regards Masahiro Yamada
[PATCH] ALSA: hda/realtek: Add quirk for Samsung Galaxy Flex Book
The Flex Book uses the same ALC298 codec as other Samsung laptops which
have the no headphone sound bug, like my Samsung Notebook. The Flex Book
owner used Early Patching to confirm that this quirk fixes the bug.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423
Signed-off-by: Mike Pozulp
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 2477f3ed7237..449ea64919ec 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7688,6 +7688,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)",
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x144d, 0xc169, "Samsung Notebook 9 Pen
(NP930SBE-K01US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x144d, 0xc176, "Samsung Notebook 9 Pro
(NP930MBE-K04US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
+ SND_PCI_QUIRK(0x144d, 0xc189, "Samsung Galaxy Flex Book
(NT950QCG-X716)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)",
ALC269_FIXUP_ATIV_BOOK_8),
SND_PCI_QUIRK(0x144d, 0xc812, "Samsung Notebook Pen S (NT950SBE-X58)",
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807",
ALC283_FIXUP_HEADSET_MIC),
--
2.26.2
Re: [PATCH v5 3/6] ov5670: Support probe whilst the device is in a low power state
On 8/12/20 5:12 PM, Bingbu Cao wrote:
>
>
> On 8/10/20 10:27 PM, Sakari Ailus wrote:
>> Tell ACPI device PM code that the driver supports the device being in a
>> low power state when the driver's probe function is entered.
>>
>> Signed-off-by: Sakari Ailus
>> ---
>> drivers/media/i2c/ov5670.c | 23 ++-
>> 1 file changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
>> index f26252e35e08d..1f75b888d2a18 100644
>> --- a/drivers/media/i2c/ov5670.c
>> +++ b/drivers/media/i2c/ov5670.c
>> @@ -2456,6 +2456,7 @@ static int ov5670_probe(struct i2c_client *client)
>> struct ov5670 *ov5670;
>> const char *err_msg;
>> u32 input_clk = 0;
>> +bool low_power;
>> int ret;
>>
>> device_property_read_u32(&client->dev, "clock-frequency", &input_clk);
>> @@ -2472,11 +2473,14 @@ static int ov5670_probe(struct i2c_client *client)
>> /* Initialize subdev */
>> v4l2_i2c_subdev_init(&ov5670->sd, client, &ov5670_subdev_ops);
>>
>> -/* Check module identity */
>> -ret = ov5670_identify_module(ov5670);
>> -if (ret) {
>> -err_msg = "ov5670_identify_module() error";
>> -goto error_print;
>> +low_power = acpi_dev_state_low_power(&client->dev);
>> +if (!low_power) {
>> +/* Check module identity */
>> +ret = ov5670_identify_module(ov5670);
>> +if (ret) {
>> +err_msg = "ov5670_identify_module() error";
>> +goto error_print;
>> +
>
> Sakari, thanks for your patch.
> one question - With this change, there will be no chance for driver to
> guarantee
> that the camera sensor plugged in is the camera that the matched driver
> actually
> can drive until try to streaming the camera, so is it necessary to return
> appropriate error in .s_stream ops to notify user it is not the hardware that
> current driver can drive? if no other better way.
Sakari, please ignore my previous comment, it is not related to this change. I
see the sub device open is caused by v4l_id program from udev.
>
--
Best regards,
Bingbu Cao
Re: [PATCH] arm64: Add KRYO4XX gold CPU core to spectre-v2 safe list
On 2020-08-13 23:29, Marc Zyngier wrote:
On 2020-08-13 13:33, Sai Prakash Ranjan wrote:
On 2020-08-13 16:09, Marc Zyngier wrote:
On 2020-08-13 10:40, Will Deacon wrote:
On Thu, Aug 13, 2020 at 02:49:37PM +0530, Sai Prakash Ranjan wrote:
On 2020-08-13 14:33, Will Deacon wrote:
> On Thu, Aug 13, 2020 at 01:48:34PM +0530, Sai Prakash Ranjan wrote:
> > KRYO4XX gold/big CPU cores are based on Cortex-A76 which has CSV2
> > bits set and are spectre-v2 safe. But on big.LITTLE systems where
> > they are coupled with other CPU cores such as the KRYO4XX silver
> > based on Cortex-A55 which are spectre-v2 safe but do not have CSV2
> > bits set, the system wide safe value will be set to the lowest value
> > of CSV2 bits as per FTR_LOWER_SAFE defined for CSV2 bits of register
> > ID_AA64PFR0_EL1.
> >
> > This is a problem when booting a guest kernel on gold CPU cores
> > where it will incorrectly report ARM_SMCCC_ARCH_WORKAROUND_1 warning
> > and consider them as vulnerable for Spectre variant 2 due to system
> > wide safe value which is used in kvm emulation code when reading id
> > registers. One wrong way of fixing this is to set the FTR_HIGHER_SAFE
> > for CSV2 bits, so instead add the KRYO4XX gold CPU core to the safe
> > list which will be consulted even when the sanitised read reports
> > that CSV2 bits are not set for KRYO4XX gold cores.
> >
> > Reported-by: Stephen Boyd
> > Signed-off-by: Sai Prakash Ranjan
> > ---
> > arch/arm64/kernel/cpu_errata.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/cpu_errata.c
> > b/arch/arm64/kernel/cpu_errata.c
> > index 6bd1d3ad037a..6cbdd2d98a2a 100644
> > --- a/arch/arm64/kernel/cpu_errata.c
> > +++ b/arch/arm64/kernel/cpu_errata.c
> > @@ -545,6 +545,7 @@ static const struct midr_range
> > spectre_v2_safe_list[] = {
> > MIDR_ALL_VERSIONS(MIDR_HISI_TSV110),
> > MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_3XX_SILVER),
> > MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER),
> > + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD),
>
> We shouldn't be putting CPUs in the safe list when they have CSV2
> reporting
> that they are mitigated in hardware, so I don't think this is the right
> approach.
>
Ok but the only thing I find wrong in this approach is that it is a
redundant
information because CSV2 is already advertising the mitigation, but
again
CSV2 check is done first so it doesn't really hurt to add it to the
safe
list because we already know that it is safe.
It simply doesn't scale. That's why CSV2 exists in the first place,
so we
don't have to modify the kernel everytime a new CPU is invented.
> Sounds more like KVM should advertise CSV2 for the vCPUs if all of the
> physical CPUs without CSV2 set are on the safe list. But then again, KVM
> has always been slightly in denial about big.LITTLE because you can't
> sensibly expose it to a guest if there are detectable differences...
>
Sorry but I don't see how the guest kernel will see the CSV2 bits
set for
gold CPU cores without actually adding them to the safe list or
reading the
not sanitised value of ID_AA64PFR0_EL1 ?
Well that's for somebody to figure out in the patch. I'm just saying
that
adding cores to the safe list when they already have a CSV2 field
conveying
the same information is the wrong approach. The right appproach is
for KVM
to expose CSV2 as set when the system is not affected by the
erratum.
A sensible way to fix this would be with something like that:
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 077293b5115f..2735db21ff0d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1131,6 +1131,9 @@ static u64 read_id_reg(const struct kvm_vcpu
*vcpu,
if (!vcpu_has_sve(vcpu))
val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
val &= ~(0xfUL << ID_AA64PFR0_AMU_SHIFT);
+ if (!(val & (0xfUL << ID_AA64PFR0_CSV2_SHIFT)) &&
+ get_spectre_v2_workaround_state() ==
ARM64_BP_HARDEN_NOT_REQUIRED)
+ val |= (1UL << ID_AA64PFR0_CSV2_SHIFT);
} else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
(0xfUL << ID_AA64ISAR1_API_SHIFT) |
Thanks Marc, I gave this a go on SC7180 where the issue was seen and
this fix is good.
Tested-by: Sai Prakash Ranjan
There is still a problem with this approach. A late CPU could
come up after a guest has been started. If that CPU identified
as vulnerable by the host kernel, get_spectre_v2_workaround_state()
will return a different value, breaking the guest (or more
likely, leaving it exposed to Spectre-v2 attacks).
We'd need to disable the late onlining of CPUs that would change
the mitigation state, and this is... ugly.
Ugh, yes indeed and here I was thinking that these things are
straightforward :(
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
Re: net/tipc/udp_media.c:743: undefined reference to `ipv6_dev_find'
On 8/13/20 2:35 AM, Xin Long wrote: > On Wed, Aug 12, 2020 at 7:21 AM kernel test robot wrote: >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head: c636eef2ee3696f261a35f34989842701a107895 >> commit: 5a6f6f579178dbeb33002d93b4f646c31348fac9 tipc: set ub->ifindex for >> local ipv6 address >> date: 6 days ago >> config: ia64-randconfig-r005-20200811 (attached as .config) >> compiler: ia64-linux-gcc (GCC) 9.3.0 >> reproduce (this is a W=1 build): >> wget >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >> ~/bin/make.cross >> chmod +x ~/bin/make.cross >> git checkout 5a6f6f579178dbeb33002d93b4f646c31348fac9 >> # save the attached .config to linux build tree >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross >> ARCH=ia64 >> >> If you fix the issue, kindly add following tag as appropriate >> Reported-by: kernel test robot >> >> All errors (new ones prefixed by >>): >> >>ia64-linux-ld: net/tipc/udp_media.o: in function `tipc_udp_enable': net/tipc/udp_media.c:743: undefined reference to `ipv6_dev_find' > To use some APIs exported from ipv6 code. > We need add this: > > --- a/net/tipc/Kconfig > +++ b/net/tipc/Kconfig > @@ -6,6 +6,7 @@ > menuconfig TIPC > tristate "The TIPC Protocol" > depends on INET > + depends on IPV6 || IPV6=n > Thanks. Works for me. Acked-by: Randy Dunlap # build-tested Please make a proper patch and send it to the maintainers. -- ~Randy
RE: [EXT] Re: [PATCH] softirq: add irq off checking for __raise_softirq_irqoff
> From: Steven Rostedt
> Sent: Thursday, August 13, 2020 10:57 PM
>
> On Thu, 13 Aug 2020 03:03:46 +
> Jiafei Pan wrote:
>
> > Any comments? Thanks.
> >
> > @Steven Rostedt, I thinks irq off checking is necessary especially
>
> This is probably more for Thomas Gleixner.
>
> > for Preempt-RT kernel, because some context may be changed from irq
> > off to irq on when enable Preempt RT, I once met a issue that hrtimer
> > soft irq is lost when enabled Preempt RT, finally I found
> > napi_schedule_irqoff is called in hardware interrupt handler, there
> > maybe no issue for non RT kernel, but for Preempt RT, interrupt is
> > threaded, so irq is on in interrupt handler, the result is
> > __raise_softirq_irqoff is called in irq on context, so that per-CPU
> > softirq masking is corrupted because of the process of updating of
> > soft irq masking is interrupted and not a atomic operation , and then
> > caused hrtimer soft irq is lost. So I think adding irq status checking
> > in __raise_softirq_irqoff can report such issue directly and help us
> > to find the root cause of such issue.
> >
> > I know that there may be performance impaction to add extra checking
> > here, if it is the case, how about to include it in some debug
> > configuration items? Such as CONFIG_DEBUG_PREEMPT or other debug
> > items?
> >
>
>
> > Best Regards,
> > Jiafei.
> >
> > -Original Message-
> > From: Jiafei Pan
> > Sent: Thursday, August 6, 2020 12:07 PM
> > To: pet...@infradead.org; mi...@kernel.org; t...@linutronix.de;
> > rost...@goodmis.org; romain.per...@gmail.com; w...@kernel.org
> > Cc: linux-kernel@vger.kernel.org; linux-rt-us...@vger.kernel.org;
> > Jiafei Pan ; Leo Li ; Vladimir
> > Oltean ; Jiafei Pan
> > Subject: [PATCH] softirq: add irq off checking for
> > __raise_softirq_irqoff
> >
> > __raise_softirq_irqoff will update per-CPU mask of pending softirqs, it need
> to be called in irq disabled context in order to keep it atomic operation,
> otherwise it will be interrupted by hardware interrupt, and per-CPU softirqs
> pending mask will be corrupted, the result is there will be unexpected issue,
> for example hrtimer soft irq will be losed and soft hrtimer will never be
> expire
> and handled.
>
> Please wrap your change logs.
[Jiafei Pan] Thanks, will update it.
>
> >
> > Adding irqs disabled checking here to provide warning in irqs enabled
> context.
> >
> > Signed-off-by: Jiafei Pan
> > ---
> > kernel/softirq.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/softirq.c b/kernel/softirq.c index
> > bf88d7f62433..11f61e54a3ae 100644
> > --- a/kernel/softirq.c
> > +++ b/kernel/softirq.c
> > @@ -481,6 +481,11 @@ void raise_softirq(unsigned int nr)
> >
> > void __raise_softirq_irqoff(unsigned int nr) {
> > + /* This function can only be called in irq disabled context,
> > + * otherwise or_softirq_pending will be interrupted by hardware
> > + * interrupt, so that there will be unexpected issue.
> > + */
> > + WARN_ON_ONCE(!irqs_disabled());
>
> Perhaps: lockdep_assert_irqs_disabled() is more appropriate, and doesn't add
> extra overhead on production systems.
>
> -- Steve
[Jiafei Pan] Thanks, will update it.
>
>
> > trace_softirq_raise(nr);
> > or_softirq_pending(1UL << nr);
> > }
> > --
> > 2.17.1
Re: [PATCH v5 0/6] Support running driver's probe for a device powered off
On 8/10/20 10:27 PM, Sakari Ailus wrote: > Hi all, > ...snip... > > The use case is such that there is a privacy LED next to an integrated > user-facing laptop camera, and this LED is there to signal the user that > the camera is recording a video or capturing images. That LED also happens > to be wired to one of the power supplies of the camera, so whenever you > power on the camera, the LED will be lit, whether images are captured from > the camera --- or not. There's no way to implement this differently > without additional software control (allowing of which is itself a > hardware design decision) on most CSI-2-connected camera sensors as they > simply have no pin to signal the camera streaming state. > > This is also what happens during driver probe: the camera will be powered > on by the I²C subsystem calling dev_pm_domain_attach() and the device is > already powered on when the driver's own probe function is called. To the > user this visible during the boot process as a blink of the privacy LED, > suggesting that the camera is recording without the user having used an > application to do that. From the end user's point of view the behaviour is > not expected and for someone unfamiliar with internal workings of a > computer surely seems quite suspicious --- even if images are not being > actually captured. > > I've tested these on linux-next master. They also apply to Wolfram's > i2c/for-next branch, there's a patch that affects the I²C core changes > here (see below). The patches apart from that apply to Bartosz's > at24/for-next as well as Mauro's linux-media master branch. Sakari, we meet one issue - once the vcm sub-device registered, the user space will try to open the VCM (I have not figure out who did that), it will also trigger the acpi pm resume/suspend, as the VCM always shares same power rail with camera sensor, so the privacy LED still has a blink. > ...snip... -- Best regards, Bingbu Cao
[PATCH v2] seqlock: Fix build errors
Fix the following build errors: In file included from ./include/linux/time.h:6:0, from ./include/linux/compat.h:10, from arch/mips/kernel/asm-offsets.c:12: ./include/linux/seqlock.h: In function ???write_seqcount_begin_nested???: ./include/linux/seqlock.h:286:2: error: implicit declaration of function ???raw_smp_processor_id??? [-Werror=implicit-function-declaration] lockdep_assert_preemption_disabled(); ^ ./arch/mips/include/asm/smp.h: At top level: ./arch/mips/include/asm/smp.h:28:19: error: static declaration of ???raw_smp_processor_id??? follows non-static declaration static inline int raw_smp_processor_id(void) ^ cc1: some warnings being treated as errors scripts/Makefile.build:117: recipe for target 'arch/mips/kernel/asm-offsets.s' failed make[1]: *** [arch/mips/kernel/asm-offsets.s] Error 1 arch/mips/Makefile:396: recipe for target 'archprepare' failed make: *** [archprepare] Error 2 Signed-off-by: Xingxing Su --- v2: update the commit message include/linux/seqlock.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h index 54bc204..4763c13 100644 --- a/include/linux/seqlock.h +++ b/include/linux/seqlock.h @@ -17,6 +17,7 @@ #include #include #include +#include #include /* -- 2.1.0
Re: [RFC PATCH 00/16] Core scheduling v6(Internet mail)
> On Aug 14, 2020, at 9:36 AM, Li, Aubrey wrote:
>
> On 2020/8/14 8:26, benbjiang(蒋彪) wrote:
>>
>>
>>> On Aug 13, 2020, at 12:28 PM, Li, Aubrey wrote:
>>>
>>> On 2020/8/13 7:08, Joel Fernandes wrote:
On Wed, Aug 12, 2020 at 10:01:24AM +0800, Li, Aubrey wrote:
> Hi Joel,
>
> On 2020/8/10 0:44, Joel Fernandes wrote:
>> Hi Aubrey,
>>
>> Apologies for replying late as I was still looking into the details.
>>
>> On Wed, Aug 05, 2020 at 11:57:20AM +0800, Li, Aubrey wrote:
>> [...]
>>> +/*
>>> + * Core scheduling policy:
>>> + * - CORE_SCHED_DISABLED: core scheduling is disabled.
>>> + * - CORE_COOKIE_MATCH: tasks with same cookie can run
>>> + * on the same core concurrently.
>>> + * - CORE_COOKIE_TRUST: trusted task can run with kernel
>>> thread on the same core concurrently.
>>> + * - CORE_COOKIE_LONELY: tasks with cookie can run only
>>> + * with idle thread on the same core.
>>> + */
>>> +enum coresched_policy {
>>> + CORE_SCHED_DISABLED,
>>> + CORE_SCHED_COOKIE_MATCH,
>>> + CORE_SCHED_COOKIE_TRUST,
>>> + CORE_SCHED_COOKIE_LONELY,
>>> +};
>>>
>>> We can set policy to CORE_COOKIE_TRUST of uperf cgroup and fix this kind
>>> of performance regression. Not sure if this sounds attractive?
>>
>> Instead of this, I think it can be something simpler IMHO:
>>
>> 1. Consider all cookie-0 task as trusted. (Even right now, if you apply
>> the
>> core-scheduling patchset, such tasks will share a core and sniff on each
>> other. So let us not pretend that such tasks are not trusted).
>>
>> 2. All kernel threads and idle task would have a cookie 0 (so that will
>> cover
>> ksoftirqd reported in your original issue).
>>
>> 3. Add a config option (CONFIG_SCHED_CORE_DEFAULT_TASKS_UNTRUSTED).
>> Default
>> enable it. Setting this option would tag all tasks that are forked from
>> a
>> cookie-0 task with their own cookie. Later on, such tasks can be added
>> to
>> a group. This cover's PeterZ's ask about having 'default untrusted').
>> (Users like ChromeOS that don't want to userspace system processes to be
>> tagged can disable this option so such tasks will be cookie-0).
>>
>> 4. Allow prctl/cgroup interfaces to create groups of tasks and override
>> the
>> above behaviors.
>
> How does uperf in a cgroup work with ksoftirqd? Are you suggesting I set
> uperf's
> cookie to be cookie-0 via prctl?
Yes, but let me try to understand better. There are 2 problems here I
think:
1. ksoftirqd getting idled when HT is turned on, because uperf is sharing a
core with it: This should not be any worse than SMT OFF, because even SMT
OFF
would also reduce ksoftirqd's CPU time just core sched is doing. Sure
core-scheduling adds some overhead with IPIs but such a huge drop of perf
is
strange. Peter any thoughts on that?
2. Interface: To solve the performance problem, you are saying you want
uperf
to share a core with ksoftirqd so that it is not forced into idle. Why not
just keep uperf out of the cgroup?
>>>
>>> I guess this is unacceptable for who runs their apps in container and vm.
>> IMHO, just as Joel proposed,
>> 1. Consider all cookie-0 task as trusted.
>> 2. All kernel threads and idle task would have a cookie 0
>> In that way, all tasks with cookies(including uperf in a cgroup) could run
>> concurrently with kernel threads.
>> That could be a good solution for the issue. :)
>
> From uperf point of review, it can trust cookie-0(I assume we still need
> some modifications to change cookie-match to cookie-compatible to allow
> ZERO and NONZERO run together).
>
> But from kernel thread point of review, it can NOT trust uperf, unless
> we set uperf's cookie to 0.
That’s right. :)
Could we set the cookie of cgroup where uperf lies to 0?
Thx.
Regards,
Jiang
>
> Thanks,
> -Aubrey
>
[PATCH v4 1/2] mm: add GFP mask param to strndup_user
Let caller specify allocation.
Keep the existing calls with GFP_USER, and enforce the existing
defense against log spam from userspace with __GFP_NOWARN.
Signed-off-by: Pascal Bouchareine
---
drivers/dma-buf/dma-buf.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs_params.c | 2 +-
drivers/gpu/drm/vc4/vc4_bo.c | 3 +-
drivers/input/misc/uinput.c| 2 +-
drivers/s390/char/keyboard.c | 3 +-
drivers/vfio/vfio.c| 3 +-
drivers/virt/fsl_hypervisor.c | 4 +--
fs/f2fs/file.c | 3 +-
fs/fsopen.c| 6 ++--
fs/namespace.c | 2 +-
fs/nfs/fs_context.c| 8 +++--
fs/xfs/xfs_ioctl.c | 2 +-
include/linux/string.h | 2 +-
kernel/events/core.c | 2 +-
kernel/module.c| 2 +-
kernel/trace/trace_event_perf.c| 2 +-
mm/util.c | 34 +-
net/core/pktgen.c | 2 +-
security/keys/dh.c | 3 +-
security/keys/keyctl.c | 17 +++
security/keys/keyctl_pkey.c| 2 +-
21 files changed, 63 insertions(+), 43 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 1ca609f66fdf..3d94ba811f4b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -326,7 +326,7 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
*/
static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
{
- char *name = strndup_user(buf, DMA_BUF_NAME_LEN);
+ char *name = strndup_user(buf, DMA_BUF_NAME_LEN, GFP_USER);
long ret = 0;
if (IS_ERR(name))
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 62b2c5f0495d..4c0a77e15c09 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -142,7 +142,7 @@ static ssize_t i915_param_charp_write(struct file *file,
kernel_param_lock(THIS_MODULE);
old = *s;
- new = strndup_user(ubuf, PAGE_SIZE);
+ new = strndup_user(ubuf, PAGE_SIZE, GFP_USER);
if (IS_ERR(new)) {
len = PTR_ERR(new);
goto out;
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 72d30d90b856..deb2c4957a6f 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -1072,7 +1072,8 @@ int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
if (!args->len)
return -EINVAL;
- name = strndup_user(u64_to_user_ptr(args->name), args->len + 1);
+ name = strndup_user(u64_to_user_ptr(args->name), args->len + 1,
+ GFP_USER);
if (IS_ERR(name))
return PTR_ERR(name);
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index f2593133e524..11627a4b4d87 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -926,7 +926,7 @@ static long uinput_ioctl_handler(struct file *file,
unsigned int cmd,
goto out;
}
- phys = strndup_user(p, 1024);
+ phys = strndup_user(p, 1024, GFP_USER);
if (IS_ERR(phys)) {
retval = PTR_ERR(phys);
goto out;
diff --git a/drivers/s390/char/keyboard.c b/drivers/s390/char/keyboard.c
index 567aedc03c76..8e58921d5db4 100644
--- a/drivers/s390/char/keyboard.c
+++ b/drivers/s390/char/keyboard.c
@@ -464,7 +464,8 @@ do_kdgkb_ioctl(struct kbd_data *kbd, struct kbsentry __user
*u_kbs,
case KDSKBSENT:
if (!perm)
return -EPERM;
- p = strndup_user(u_kbs->kb_string, sizeof(u_kbs->kb_string));
+ p = strndup_user(u_kbs->kb_string,
+ sizeof(u_kbs->kb_string), GFP_USER);
if (IS_ERR(p))
return PTR_ERR(p);
kfree(kbd->func_table[kb_func]);
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 580099afeaff..d55aae6661eb 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1547,7 +1547,8 @@ static long vfio_group_fops_unl_ioctl(struct file *filep,
{
char *buf;
- buf = strndup_user((const char __user *)arg, PAGE_SIZE);
+ buf = strndup_user((const char __user *)arg, PAGE_SIZE,
+ GFP_USER);
if (IS_ERR(buf))
return PTR_ERR(buf);
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
index 1b0b11b55d2a..142c74aab2b0 100644
--- a/drivers/virt/fsl_hypervisor.c
+++ b/drivers/virt/fsl_hypervisor.c
@@ -346,11 +34
[PATCH v4 0/2] proc,fcntl: introduce F_SET_DESCRIPTION
This is a first attempt at taking Alexey's comments into account This goes against v5.8 tl;dr in commit 2/2 but motivation is also described a bit in https://lore.kernel.org/linux-api/CAGbU3_nVvuzMn2wo4_ZKufWcGfmGsopVujzTWw-Bbeky=xs...@mail.gmail.com/
[PATCH v4 2/2] fcntl: introduce F_SET_DESCRIPTION
This command attaches a description to a file descriptor for
troubleshooting purposes. The free string is displayed in the
process fdinfo file for that fd /proc/pid/fdinfo/fd.
One intended usage is to allow processes to self-document sockets
for netstat and friends to report
Signed-off-by: Pascal Bouchareine
---
fs/fcntl.c | 21 +
fs/file_table.c| 2 ++
fs/proc/fd.c | 5 +
include/linux/fs.h | 3 +++
include/uapi/linux/fcntl.h | 5 +
5 files changed, 36 insertions(+)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 2e4c0fa2074b..9fbeaaf02802 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -319,6 +319,24 @@ static long fcntl_rw_hint(struct file *file, unsigned int
cmd,
}
}
+static long fcntl_set_description(struct file *file, char __user *desc)
+{
+ char *d, *old;
+
+ d = strndup_user(desc, MAX_FILE_DESC_SIZE, GFP_KERNEL_ACCOUNT);
+ if (IS_ERR(d))
+ return PTR_ERR(d);
+
+ spin_lock(&file->f_lock);
+ old = file->f_description;
+ file->f_description = d;
+ spin_unlock(&file->f_lock);
+
+ kfree(old);
+
+ return 0;
+}
+
static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
struct file *filp)
{
@@ -426,6 +444,9 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned
long arg,
case F_SET_FILE_RW_HINT:
err = fcntl_rw_hint(filp, cmd, arg);
break;
+ case F_SET_DESCRIPTION:
+ err = fcntl_set_description(filp, argp);
+ break;
default:
break;
}
diff --git a/fs/file_table.c b/fs/file_table.c
index 656647f9575a..6673a48d2ea1 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -272,6 +272,8 @@ static void __fput(struct file *file)
eventpoll_release(file);
locks_remove_file(file);
+ kfree(file->f_description);
+
ima_file_free(file);
if (unlikely(file->f_flags & FASYNC)) {
if (file->f_op->fasync)
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 81882a13212d..60b3ff971b2b 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -57,6 +57,11 @@ static int seq_show(struct seq_file *m, void *v)
(long long)file->f_pos, f_flags,
real_mount(file->f_path.mnt)->mnt_id);
+ spin_lock(&file->f_lock);
+ if (file->f_description)
+ seq_printf(m, "desc:\t%s\n", file->f_description);
+ spin_unlock(&file->f_lock);
+
show_fd_locks(m, file, files);
if (seq_has_overflowed(m))
goto out;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index f5abba86107d..a2a683d603b6 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -980,6 +980,9 @@ struct file {
struct address_space*f_mapping;
errseq_tf_wb_err;
errseq_tf_sb_err; /* for syncfs */
+
+#define MAX_FILE_DESC_SIZE 256
+ char*f_description;
} __randomize_layout
__attribute__((aligned(4))); /* lest something weird decides that 2 is OK */
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index 2f86b2ad6d7e..465385e52f49 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -55,6 +55,11 @@
#define F_GET_FILE_RW_HINT (F_LINUX_SPECIFIC_BASE + 13)
#define F_SET_FILE_RW_HINT (F_LINUX_SPECIFIC_BASE + 14)
+/*
+ * Set file description
+ */
+#define F_SET_DESCRIPTION (F_LINUX_SPECIFIC_BASE + 15)
+
/*
* Valid hint values for F_{GET,SET}_RW_HINT. 0 is "not set", or can be
* used to clear any hints previously set.
--
2.25.1
[PATCH v8 2/4] power: supply: core: add wireless charger adapter type property
From: Qiwu Huang
Reports what type of wireless adapter connection is
currently active for the supply.
for example it can show if ADAPTER_PD capable source is attached.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 28 +
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 19 ++
3 files changed, 48 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index dd3773dcf16a..03ab449fae8a 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -729,3 +729,31 @@ Contact: Fei Jiang
3: QUICK_CHARGE_TURBE,
4: QUICK_CHARGE_SUPER.
+= Wireless Charger Properties =
+What: /sys/class/power_supply//tx_adapter
+Date: Jul 2020
+Contact: Fei Jiang
+Description:
+ Reports the type of wireless adapter connection is currently
active for
+ the supply, for example it can show if ADAPTER_PD capable source
+ is attached. Expect common wireless adapter type, also increase
by
+ some vendor private adapter type(ex. ADAPTER_PD_40W).
+
+ Access: Read-Only
+ Valid values:
+ 0: ADAPTER_NONE,
+ 1: ADAPTER_SDP,
+ 2: ADAPTER_DCP,
+ 3: ADAPTER_CDP,
+ 4: ADAPTER_OCP,
+ 5: ADAPTER_QC2,
+ 6: ADAPTER_QC3,
+ 7: ADAPTER_PD,
+ 8: ADAPTER_AUTH_FAILED,
+ 9: ADAPTER_PRIVATE_QC3,
+ 10: ADAPTER_PRIVATE_PD,
+ 11: ADAPTER_CAR_POWER,
+ 12: ADAPTER_PRIVATE_PD_40W,
+ 13: ADAPTER_VOICE_BOX,
+ 14: ADAPTER_PRIVATE_PD_50W.
+
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 9554d7907373..f2458e21d02b 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -207,6 +207,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(MANUFACTURER),
POWER_SUPPLY_ATTR(SERIAL_NUMBER),
POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
+ POWER_SUPPLY_ATTR(TX_ADAPTER),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index bd99658c05be..00254e096a4a 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -168,6 +168,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_MANUFACTURER,
POWER_SUPPLY_PROP_SERIAL_NUMBER,
POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
+ POWER_SUPPLY_PROP_TX_ADAPTER,
};
enum power_supply_type {
@@ -211,6 +212,24 @@ enum power_supply_quick_charge_type {
QUICK_CHARGE_MAX,
};
+enum power_supply_tx_adapter_type {
+ ADAPTER_NONE = 0, /* Nothing Attached */
+ ADAPTER_SDP,/* Standard Downstream Port */
+ ADAPTER_CDP,/* Charging Downstream Port */
+ ADAPTER_DCP,/* Dedicated Charging Port */
+ ADAPTER_OCP,/* Other Charging Port */
+ ADAPTER_QC2,/* Qualcomm Charge 2.0 */
+ ADAPTER_QC3,/* Qualcomm Charge 3.0 */
+ ADAPTER_PD, /* Power Delivery Port */
+ ADAPTER_AUTH_FAILED,/* Authenticated Failed Adapter
*/
+ ADAPTER_PRIVATE_QC3,/* Qualcomm Charge 3.0 with
Private Protocol */
+ ADAPTER_PRIVATE_PD, /* PD Adapter with Private
Protocol */
+ ADAPTER_CAR_POWER, /* Wireless Car Charger */
+ ADAPTER_PRIVATE_PD_40W, /* 40W PD Adapter with Private
Protocol */
+ ADAPTER_VOICE_BOX, /* Voice Box which Support
Wireless Charger */
+ ADAPTER_PRIVATE_PD_50W, /* 50W PD Adapter with Private
Protocol */
+};
+
enum power_supply_notifier_events {
PSY_EVENT_PROP_CHANGED,
};
--
2.28.0
[PATCH v8 4/4] power: supply: core: property to control reverse charge
From: Qiwu Huang
Interface to control wireless reverse charge.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 14 ++
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 1 +
3 files changed, 16 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index 4459b720feb2..8840fdf483a7 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -779,3 +779,17 @@ Description:
Access: Read-Only
Valid values: 0 - 100
+
+What: /sys/class/power_supply//reverse_chg_mode
+Date: Jul 2020
+Contact: Fei Jiang
+Description:
+ Some devices support wireless reverse charge function which
+ charge other devices.The property provider interface to
+ enable/disable wireless reverse charge.If enabled, start TX
+ mode and detect RX. Disabled when timeout or manual setting.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index e420a453095e..81916b6b6ccf 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -209,6 +209,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
POWER_SUPPLY_ATTR(TX_ADAPTER),
POWER_SUPPLY_ATTR(SIGNAL_STRENGTH),
+ POWER_SUPPLY_ATTR(REVERSE_CHG_MODE),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 747338118fa1..988d3f05ea1c 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -170,6 +170,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
POWER_SUPPLY_PROP_TX_ADAPTER,
POWER_SUPPLY_PROP_SIGNAL_STRENGTH,
+ POWER_SUPPLY_PROP_REVERSE_CHG_MODE,
};
enum power_supply_type {
--
2.28.0
[PATCH v8 3/4] power: supply: core: add wireless signal strength property
From: Qiwu Huang
reports wireless signal strength.
The value show degree of coupling between tx and rx.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 22 +
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h| 1 +
3 files changed, 24 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index 03ab449fae8a..4459b720feb2 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -757,3 +757,25 @@ Description:
13: ADAPTER_VOICE_BOX,
14: ADAPTER_PRIVATE_PD_50W.
+What: /sys/class/power_supply//signal_strength
+Date: Jul 2020
+Contact: Fei Jiang
+Description:
+ In PING phase, RX transmits a signal strength packet as the
+ first communication packet to instruct the base to keep power
+ signal on.The value reports wireless signal strength and show
+ degree of coupling.
+
+ The Qi Wireless Power Transfer System is published by the
+ Wireless Power Consortium.The ping phase is the necessary stage
+ for matching transmitter and receiver. In this phase,the Power
+ Transmitter executes a Digital Ping, and listens for a response.
+ If the Power Transmitter discovers a Power Receiver, the Power
+ Transmitter may extend the Digital Ping,i.e. maintain the Power
+ Signal at the level of the Digital Ping. This causes the system
+ to proceed to the identification & configuration phase. If the
+ Power Transmitter does not extend the Digital Ping, the system
+ shall revert to the selection phase.
+
+ Access: Read-Only
+ Valid values: 0 - 100
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index f2458e21d02b..e420a453095e 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -208,6 +208,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(SERIAL_NUMBER),
POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
POWER_SUPPLY_ATTR(TX_ADAPTER),
+ POWER_SUPPLY_ATTR(SIGNAL_STRENGTH),
};
static struct attribute *
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 00254e096a4a..747338118fa1 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -169,6 +169,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_SERIAL_NUMBER,
POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
POWER_SUPPLY_PROP_TX_ADAPTER,
+ POWER_SUPPLY_PROP_SIGNAL_STRENGTH,
};
enum power_supply_type {
--
2.28.0
[PATCH v8 0/4] add some power supply properties about wireless/wired charging
From: Qiwu Huang This patchset aims to provide power supply properties about wireless/wired charging. "quick_charge_type" reports different types of quick charge based on the charging power; "tx_adapter" shows" the type of wireless charging adapter; "signal_strength" shows the coupling level between TX and RX; "reverse_chg_mode" provides the interface of enabling/disabling wireless reverse charging. Changes in v8 - Add quick charge type driver in qcom_smbb suggested by GregKH Changes in v7 - Fix PATCH version error in 0/X email Changes in v6 - Replace "phones" with "devices" suggested by GregKH - Add permission statement for "reverse_chg_mode" - Update description for "reverse_chg_mode" in ABI suggested by GregKH - Update description for "PING phase" in ABI suggested by GregKH Changes in v5 - Add details in 0/X email Changes in v4 - Exclude the patch of "power: supply: supply battery soc with decimal form" - Fix some typo Changes in v3 - Add enumederated for quick charge type - Add enumederated for tx adapter type - Update the return type and description in ABI Changes in v2 - modify to capital letters for "power_supply_attrs" - Update the return type and description in ABI Qiwu Huang (4): power: supply: core: add quick charge type property power: supply: core: add wireless charger adapter type property power: supply: core: add wireless signal strength property power: supply: core: property to control reverse charge Documentation/ABI/testing/sysfs-class-power | 85 + drivers/power/supply/power_supply_sysfs.c | 4 + drivers/power/supply/qcom_smbb.c| 51 + include/linux/power_supply.h| 35 + 4 files changed, 175 insertions(+) -- 2.28.0
[PATCH v8 1/4] power: supply: core: add quick charge type property
From: Qiwu Huang
Reports the kind of quick charge type based on
different adapter power.
Signed-off-by: Qiwu Huang
---
Documentation/ABI/testing/sysfs-class-power | 21 +
drivers/power/supply/power_supply_sysfs.c | 1 +
drivers/power/supply/qcom_smbb.c| 51 +
include/linux/power_supply.h| 14 ++
4 files changed, 87 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index 216d61a22f1e..dd3773dcf16a 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -708,3 +708,24 @@ Description:
Access: Read
Valid values: 1-31
+
+What: /sys/class/power_supply//quick_charge_type
+Date: Jul 2020
+Contact: Fei Jiang
+ Description:
+ Reports the kind of quick charge type based on different
adapter power.
+ Different quick charge type represent different charging power.
+ QUICK_CHARGE_NORMAL : Charging Power <= 10W
+ QUICK_CHARGE_FAST : 10W < Charging Power <= 20W
+ QUICK_CHARGE_FLASH : 20W < Charging Power <= 30W
+ QUICK_CHARGE_TURBE : 30W < Charging Power <= 50W
+ QUICK_CHARGE_SUPER : Charging Power > 50W
+
+ Access: Read-Only
+ Valid values:
+ 0: QUICK_CHARGE_NORMAL,
+ 1: QUICK_CHARGE_FAST,
+ 2: QUICK_CHARGE_FLASH,
+ 3: QUICK_CHARGE_TURBE,
+ 4: QUICK_CHARGE_SUPER.
+
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index bc79560229b5..9554d7907373 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -206,6 +206,7 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(MODEL_NAME),
POWER_SUPPLY_ATTR(MANUFACTURER),
POWER_SUPPLY_ATTR(SERIAL_NUMBER),
+ POWER_SUPPLY_ATTR(QUICK_CHARGE_TYPE),
};
static struct attribute *
diff --git a/drivers/power/supply/qcom_smbb.c b/drivers/power/supply/qcom_smbb.c
index c890e1cec720..afd38cf38832 100644
--- a/drivers/power/supply/qcom_smbb.c
+++ b/drivers/power/supply/qcom_smbb.c
@@ -485,6 +485,53 @@ static const struct smbb_irq {
{ "dc-valid", smbb_dc_valid_handler },
};
+struct quick_charge {
+ enum power_supply_type adap_type;
+ enum power_supply_quick_charge_type adap_cap;
+};
+
+static struct quick_charge adapter_cap[10] = {
+ { POWER_SUPPLY_TYPE_USB,QUICK_CHARGE_NORMAL },
+ { POWER_SUPPLY_TYPE_USB_DCP,QUICK_CHARGE_NORMAL },
+ { POWER_SUPPLY_TYPE_USB_CDP,QUICK_CHARGE_NORMAL },
+ { POWER_SUPPLY_TYPE_USB_ACA,QUICK_CHARGE_NORMAL },
+ { POWER_SUPPLY_TYPE_USB_FLOAT, QUICK_CHARGE_NORMAL },
+ { POWER_SUPPLY_TYPE_USB_PD, QUICK_CHARGE_FAST },
+ { POWER_SUPPLY_TYPE_USB_HVDCP, QUICK_CHARGE_FAST },
+ { POWER_SUPPLY_TYPE_USB_HVDCP_3,QUICK_CHARGE_FAST },
+ { POWER_SUPPLY_TYPE_USB_HVDCP_3P5, QUICK_CHARGE_FAST },
+ {0, 0},
+};
+
+static int get_quick_charge_type(struct smbb_charger *chg)
+{
+ union power_supply_propval prop = {0, };
+ int charger_type, rc;
+ int i = 0;
+
+ rc = power_supply_get_property(chg->bat_psy,
+ POWER_SUPPLY_PROP_STATUS, &prop);
+ if (rc < 0)
+ return rc;
+ if (prop.intval == POWER_SUPPLY_STATUS_DISCHARGING)
+ return 0;
+
+ rc = power_supply_get_property(chg->usb_psy,
+ POWER_SUPPLY_PROP_USB_TYPE, &prop);
+ if (rc < 0)
+ return rc;
+ charger_type = prop.intval;
+
+ while (adapter_cap[i].adap_type != 0) {
+ if (charger_type == adapter_cap[i].adap_type) {
+ return adapter_cap[i].adap_cap;
+ }
+ i++;
+ }
+
+ return 0;
+}
+
static int smbb_usbin_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -505,6 +552,9 @@ static int smbb_usbin_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX:
val->intval = 250;
break;
+ case POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE:
+ val->intval = get_quick_charge_type(chg);
+ break;
default:
rc = -EINVAL;
break;
@@ -695,6 +745,7 @@ static enum power_supply_property smbb_charger_properties[]
= {
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+ POWER_SUPPLY_PROP_QUICK_CHARGE_TYPE,
};
stati
Re: [PATCH] perf stat: update POWER9 metrics to utilize other metrics
On Thu, Aug 13, 2020 at 3:21 PM Paul A. Clarke wrote:
>
> These changes take advantage of the new capability added in
> merge commit 00e4db51259a5f936fec1424b884f029479d3981
> "Allow using computed metrics in calculating other metrics".
>
> The net is a simplification of the expressions for a handful
> of metrics, but no functional change.
>
> Signed-off-by: Paul A. Clarke
Acked-by: Ian Rogers
(Re-sent with plain text enabled to avoid lkml bounce)
Thanks,
Ian
>
> ---
> .../arch/powerpc/power9/metrics.json | 48 +--
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> index 80816d6402e9..f8784c608479 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> @@ -60,7 +60,7 @@
> },
> {
> "BriefDescription": "Stalls due to short latency decimal floating
> ops.",
> -"MetricExpr": "(PM_CMPLU_STALL_DFU -
> PM_CMPLU_STALL_DFLONG)/PM_RUN_INST_CMPL",
> +"MetricExpr": "dfu_stall_cpi - dflong_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "dfu_other_stall_cpi"
> },
> @@ -72,7 +72,7 @@
> },
> {
> "BriefDescription": "Completion stall by Dcache miss which resolved
> off node memory/cache",
> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS -
> PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM -
> PM_CMPLU_STALL_DMISS_REMOTE)/PM_RUN_INST_CMPL",
> +"MetricExpr": "dmiss_non_local_stall_cpi - dmiss_remote_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "dmiss_distant_stall_cpi"
> },
> @@ -90,7 +90,7 @@
> },
> {
> "BriefDescription": "Completion stall due to cache miss that
> resolves in the L2 or L3 without conflict",
> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L2L3 -
> PM_CMPLU_STALL_DMISS_L2L3_CONFLICT)/PM_RUN_INST_CMPL",
> +"MetricExpr": "dmiss_l2l3_stall_cpi - dmiss_l2l3_conflict_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "dmiss_l2l3_noconflict_stall_cpi"
> },
> @@ -114,7 +114,7 @@
> },
> {
> "BriefDescription": "Completion stall by Dcache miss which resolved
> outside of local memory",
> -"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS -
> PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM)/PM_RUN_INST_CMPL",
> +"MetricExpr": "dmiss_l3miss_stall_cpi - dmiss_l21_l31_stall_cpi -
> dmiss_lmem_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "dmiss_non_local_stall_cpi"
> },
> @@ -126,7 +126,7 @@
> },
> {
> "BriefDescription": "Stalls due to short latency double precision
> ops.",
> -"MetricExpr": "(PM_CMPLU_STALL_DP -
> PM_CMPLU_STALL_DPLONG)/PM_RUN_INST_CMPL",
> +"MetricExpr": "dp_stall_cpi - dplong_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "dp_other_stall_cpi"
> },
> @@ -155,7 +155,7 @@
> "MetricName": "emq_full_stall_cpi"
> },
> {
> -"MetricExpr": "(PM_CMPLU_STALL_ERAT_MISS +
> PM_CMPLU_STALL_EMQ_FULL)/PM_RUN_INST_CMPL",
> +"MetricExpr": "erat_miss_stall_cpi + emq_full_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "emq_stall_cpi"
> },
> @@ -173,7 +173,7 @@
> },
> {
> "BriefDescription": "Completion stall due to execution units for
> other reasons.",
> -"MetricExpr": "(PM_CMPLU_STALL_EXEC_UNIT - PM_CMPLU_STALL_FXU -
> PM_CMPLU_STALL_DP - PM_CMPLU_STALL_DFU - PM_CMPLU_STALL_PM -
> PM_CMPLU_STALL_CRYPTO - PM_CMPLU_STALL_VFXU -
> PM_CMPLU_STALL_VDP)/PM_RUN_INST_CMPL",
> +"MetricExpr": "exec_unit_stall_cpi - scalar_stall_cpi -
> vector_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "exec_unit_other_stall_cpi"
> },
> @@ -197,7 +197,7 @@
> },
> {
> "BriefDescription": "Stalls due to short latency integer ops",
> -"MetricExpr": "(PM_CMPLU_STALL_FXU -
> PM_CMPLU_STALL_FXLONG)/PM_RUN_INST_CMPL",
> +"MetricExpr": "fxu_stall_cpi - fxlong_stall_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "fxu_other_stall_cpi"
> },
> @@ -221,7 +221,7 @@
> },
> {
> "BriefDescription": "Instruction Completion Table other stalls",
> -"MetricExpr": "(PM_ICT_NOSLOT_CYC - PM_ICT_NOSLOT_IC_MISS -
> PM_ICT_NOSLOT_BR_MPRED_ICMISS - PM_ICT_NOSLOT_BR_MPRED -
> PM_ICT_NOSLOT_DISP_HELD)/PM_RUN_INST_CMPL",
> +"MetricExpr": "nothing_dispatched_cpi - ict_noslot_ic_miss_cpi -
> ict_noslot_br_mpred_icmiss_cpi - ict_noslot_br_mpred_cpi -
> ict_noslot_disp_held_cpi",
> "MetricGroup": "cpi_breakdown",
> "MetricName": "ict_noslot_cyc_other_cpi"
> },
> @@ -245,7 +245,7 @@
>
Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
On (20/08/13 12:35), John Ogness wrote: > I believe I failed to recognize the fundamental problem. The fundamental > problem is that the pr_cont() semantics are very poor. The semantics is pretty clear - use it only in UP early bootup, anything else is broken :) /* * Annotation for a "continued" line of log printout (only done after a * line that had no enclosing \n). Only to be used by core/arch code * during early bootup (a continued line is not SMP-safe otherwise). */ #define KERN_CONT KERN_SOH "c" > I now strongly believe that we need to fix those semantics by having the > pr_cont() user take responsibility for buffering the message. Patching the > ~2000 pr_cont() users will be far easier than continuing to twist ourselves > around this madness. I welcome this effort. We've been talking about the fact that pr_cont() is not something we can ignore anymore (we have more and more SMP users of it) since the Kernel Summit in Santa Fe, NM, but the general response back then was "oh my god, who cares" (pretty sure this is very close to what Ted Ts'o said during the printk session). > Here is an example for a new pr_cont() API: > > struct pr_cont c; > > pr_cont_alloc_info(&c); >(or alternatively) > dev_cont_alloc_info(dev, &c); > > pr_cont(&c, "1"); > pr_cont(&c, "2"); > > pr_cont_flush(&c); This might be a bit more complex. One thing that we need to handle here, I believe, is that the context which crashes the kernel should flush its cont buffer, because the information there is relevant to the crash: pr_cont_alloc_info(&c); pr_cont(&c, "1"); pr_cont(&c, "2"); >> oops panic() << pr_cont_flush(&c); We better flush that context's pr_cont buffer during panic(). Another example: pr_cont_alloc_info(&c); for (i = 0; i < p->sz; i++) pr_cont(&c, p->buf[i]); >> page fault exit << pr_cont_flush(&c); I believe we need to preliminary flush pr_cont() in this case as well, because the information there might be very helpful. -ss
RE: [EXT] Re: [PATCH] softirq: add irq off checking for __raise_softirq_irqoff
> From: Peter Zijlstra
> Sent: Thursday, August 13, 2020 1:58 PM
>
> On Thu, Aug 06, 2020 at 12:07:29PM +0800, Jiafei Pan wrote:
> > __raise_softirq_irqoff will update per-CPU mask of pending softirqs,
> > it need to be called in irq disabled context in order to keep it
> > atomic operation, otherwise it will be interrupted by hardware
> > interrupt, and per-CPU softirqs pending mask will be corrupted, the
> > result is there will be unexpected issue, for example hrtimer soft irq
> > will be losed and soft hrtimer will never be expire and handled.
> >
> > Adding irqs disabled checking here to provide warning in irqs enabled
> > context.
> >
> > Signed-off-by: Jiafei Pan
> > ---
> > kernel/softirq.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/softirq.c b/kernel/softirq.c index
> > bf88d7f62433..11f61e54a3ae 100644
> > --- a/kernel/softirq.c
> > +++ b/kernel/softirq.c
> > @@ -481,6 +481,11 @@ void raise_softirq(unsigned int nr)
> >
> > void __raise_softirq_irqoff(unsigned int nr) {
> > + /* This function can only be called in irq disabled context,
> > + * otherwise or_softirq_pending will be interrupted by hardware
> > + * interrupt, so that there will be unexpected issue.
> > + */
>
> Comment style is wrong, also I'm not sure the comment is really helpfull.
[Jiafei Pan] Thanks for your comments, yes, function name already indicate the
function
Should be called in irq off context, will remove the comment in next version.
>
> > + WARN_ON_ONCE(!irqs_disabled());
>
> lockdep_assert_irqs_disabled();
>
> > trace_softirq_raise(nr);
> > or_softirq_pending(1UL << nr);
> > }
Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages
On Fri, Aug 14, 2020 at 10:45:37AM +0800, Zhaoyang Huang wrote: > On Fri, Aug 14, 2020 at 10:33 AM Andrew Morton > wrote: > > > > On Fri, 14 Aug 2020 10:20:11 +0800 Zhaoyang Huang > > wrote: > > > > > On Fri, Aug 14, 2020 at 10:07 AM Matthew Wilcox > > > wrote: > > > > > > > > On Fri, Aug 14, 2020 at 02:43:55AM +0100, Matthew Wilcox wrote: > > > > > On Fri, Aug 14, 2020 at 09:30:11AM +0800, Zhaoyang Huang wrote: > > > > > > file->f_ra->ra_pages will remain the initialized value since it > > > > > > opend, which may > > > > > > be NOT equal to bdi->ra_pages as the latter one is updated > > > > > > somehow(etc, > > > > > > echo xxx > /sys/block/dm/queue/read_ahead_kb).So sync ra->ra_pages > > > > > > to the > > > > > > updated value when sync read. > > > > > > > > > > It still ignores the work done by shrink_readahead_size_eio() > > > > > and fadvise(POSIX_FADV_SEQUENTIAL). > > > > > > > > ... by the way, if you're trying to update one particular file's > > > > readahead > > > > state, you can just call fadvise(POSIX_FADV_NORMAL) on it. > > > > > > > > If you want to update every open file's ra_pages by writing to sysfs, > > > > then just no. We don't do that. > > > No, What I want to fix is the file within one process's context keeps > > > using the initialized value when it is opened and not sync with new > > > value when bdi->ra_pages changes. > > > > So you're saying that > > > > echo xxx > /sys/block/dm/queue/read_ahead_kb > > > > does not affect presently-open files, and you believe that it should do > > so? > > > > I guess that could be a reasonable thing to want - it's reasonable for > > a user to expect that writing to a global tunable will take immediate > > global effect. I guess. > > > > But as Matthew says, it would help if you were to explain why this is > > needed. In full detail. What operational problems is the present > > implementation causing? > The real scenario is some system(like android) will turbo read during > startup via expanding the readahead window and then set it back to > normal(128kb as usual). However, some files in the system process > context will keep to be opened since it is opened up and has no chance > to sync with the updated value as it is almost impossible to change > the files attached to the inode(processes are unaware of these > things). we have to fix it from a kernel perspective. OK, this is a much more useful description of the problem, thank you! I can think of two possibilities here. One is that maybe our readahead heuristics just don't work on modern phone hardware. Perhaps we need to ramp up more aggressively by default. The other is that maybe it really is just a "boost at startup" kind of situation and so we should support _that_. Some interface where we can set a ra_boost, and then do: if (ra_boost) newsize *= 2; in get_init_ra_size().
Re: [GIT] Networking
The pull request you sent on Thu, 13 Aug 2020 16:10:57 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a1d21081a60dfb7fddf4a38b66d9cef603b317a9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v4 3/7] genirq: Introduce irq_suspend_one() and irq_resume_one() callbacks
Hi,
On Thu, Aug 13, 2020 at 7:07 PM Thomas Gleixner wrote:
>
> Doug,
>
> On Thu, Aug 13 2020 at 15:58, Doug Anderson wrote:
> > On Thu, Aug 13, 2020 at 3:09 PM Thomas Gleixner wrote:
> >> > * If this interrupt fires while the system is suspended then please
> >> > wake the system up.
> >>
> >> Well, that's kinda contradicting itself. If the interrupt is masked then
> >> what is the point? I'm surely missing something subtle here.
> >
> > This is how I've always been told that the API works and there are at
> > least a handful of drivers in the kernel whose suspend routines both
> > enable wakeup and call disable_irq(). Isn't this also documented as
> > of commit f9f21cea3113 ("genirq: Clarify that irq wake state is
> > orthogonal to enable/disable")?
>
> Fair enough. The wording there is unfortunate and I probably should have
> spent more brain cycles before applying it. It suggests that this is a
> pure driver problem. I should have asked some of the questions I asked
> now back then :(
I mean, certainly a driver could be rewritten not to do this. ...and,
in fact, the easier approach (for just solving my immediate concern)
would be to change cros-ec not to do this. However, it was my
understanding that what cros-ec was doing was actually just fine and
part of the API to drivers. This understanding was solidified when
the patch I mentioned landed. When looking at this before I found
that certainly there are other drivers that do this and it felt better
to implement the proper thing rather than add a hack to cros-ec to
work around the Qualcomm pinctrl driver.
In general the idea here, I think, is that in the "suspend" call of a
driver it might want to disable interrupts so that it doesn't have to
deal with them after the driver has configured things (and adjusted
its internal data structures) for suspend. However, it might still
want its interrupt to cause a wakeup. ...so it wants the wakeup to
happen (and its resume call to be made to get everything back in the
right state) and at the end of the resume call it wants to enable its
interrupt handler again. That seems like a sane design pattern to me,
but maybe I'm crazy. Yes, I guess the driver could implement the
"noirq" suspend function, but sometimes it's simpler to have a single
suspend function that first leverages interrupts, then disables them
at an exact point it can control, and then finishes adjusting its
state.
I'll also note that the concept that a masked interrupt can "wake you
up" is also not unlike how ARM SoCs work, which is part of what made
me feel like this API was fine. Specifically if you have interrupts
masked at the CPU level and then enter "WFI" (wait for interrupt) it
will wake up (or come out of idle) from one of those masked
interrupts.
> >> If that's the main problem which is solved in these callbacks, then I
> >> really have to ask why this has not been raised years ago. Why can't
> >> people talk?
> >
> > Not all of us have the big picture that you do to know how things
> > ought to work, I guess. If nothing else someone looking at this
> > problem would think: "this must be a common problem, let's go see how
> > all the other places do it" and then they find how everyone else is
> > doing it and do it that way. It requires the grander picture that a
> > maintainer has in order to say: whoa, everyone's copying the same
> > hack--let's come up with a better solution.
>
> That's not the point. I know how these things happen, but I fail to
> understand why nobody ever looks at this and says: OMG, I need to do yet
> another variant of copy&pasta of the same thing every other driver
> does. Why is there no infrastructure for that?
>
> Asking that question does not require a maintainer who always encouraged
> people to talk about exactly these kind of things instead of going off
> and creating the gazillionst broken copy of the same thing with yet
> another wart working around core code problems and thereby violating
> layering and introducing bugs which wouldn't exist otherwise.
>
> Spare me all the $corp reasons. I've heard all of them and if not then
> the not yet known reason won't be any more convincing. :)
As per above, if I was simply motivated to hack it to get it done I
would have suggested we just muck with cros_ec. I certainly do have a
bias for getting things done and getting things landed, but I also try
to pride myself in not saying that we should just accept any old hack.
Perhaps many people posting patches just want any old crap landed, but
I'd like to think I'm not one of them.
> One of the most underutilized strengths of FOSS is that you can go and
> ask someone who has the big picture in his head before you go off and
> waste time on distangling copy&pasta, dealing with the resulting obvious
> bugs and then the latent ones which only surface 3 month after the
> product has shipped. Or like in this case figure out that the copy&pasta
> road is a dead end and then create something new without s
drivers/scsi/smartpqi/smartpqi_init.c:2070 pqi_update_scsi_devices() error: we previously assumed 'physdev_list' could be null (see line 2006)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: dddcbc139e96bd18d8c65ef7b7e440f0d32457c2
commit: 5e6a9760f7da4dd86cca43ac6423695d6cb0dff4 scsi: smartpqi: add module
param for exposure order
date: 12 months ago
config: ia64-randconfig-m031-20200811 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
New smatch warnings:
drivers/scsi/smartpqi/smartpqi_init.c:2070 pqi_update_scsi_devices() error: we
previously assumed 'physdev_list' could be null (see line 2006)
Old smatch warnings:
drivers/scsi/smartpqi/smartpqi_init.c:2077 pqi_update_scsi_devices() error: we
previously assumed 'logdev_list' could be null (see line 2013)
drivers/scsi/smartpqi/smartpqi_init.c:2134 pqi_update_scsi_devices() warn:
inconsistent indenting
drivers/scsi/smartpqi/smartpqi_init.c:6995 pqi_ctrl_init() warn: impossible
condition '(ctrl_info->max_outstanding_requests > (~0)) => (0-u32max > u32max)'
vim +/physdev_list +2070 drivers/scsi/smartpqi/smartpqi_init.c
1977
1978 static int pqi_update_scsi_devices(struct pqi_ctrl_info *ctrl_info)
1979 {
1980 int i;
1981 int rc;
1982 LIST_HEAD(new_device_list_head);
1983 struct report_phys_lun_extended *physdev_list = NULL;
1984 struct report_log_lun_extended *logdev_list = NULL;
1985 struct report_phys_lun_extended_entry *phys_lun_ext_entry;
1986 struct report_log_lun_extended_entry *log_lun_ext_entry;
1987 struct bmic_identify_physical_device *id_phys = NULL;
1988 u32 num_physicals;
1989 u32 num_logicals;
1990 struct pqi_scsi_dev **new_device_list = NULL;
1991 struct pqi_scsi_dev *device;
1992 struct pqi_scsi_dev *next;
1993 unsigned int num_new_devices;
1994 unsigned int num_valid_devices;
1995 bool is_physical_device;
1996 u8 *scsi3addr;
1997 unsigned int physical_index;
1998 unsigned int logical_index;
1999 static char *out_of_memory_msg =
2000 "failed to allocate memory, device discovery stopped";
2001
2002 rc = pqi_get_device_lists(ctrl_info, &physdev_list,
&logdev_list);
2003 if (rc)
2004 goto out;
2005
> 2006 if (physdev_list)
2007 num_physicals =
2008
get_unaligned_be32(&physdev_list->header.list_length)
2009 / sizeof(physdev_list->lun_entries[0]);
2010 else
2011 num_physicals = 0;
2012
2013 if (logdev_list)
2014 num_logicals =
2015
get_unaligned_be32(&logdev_list->header.list_length)
2016 / sizeof(logdev_list->lun_entries[0]);
2017 else
2018 num_logicals = 0;
2019
2020 if (num_physicals) {
2021 /*
2022 * We need this buffer for calls to
pqi_get_physical_disk_info()
2023 * below. We allocate it here instead of inside
2024 * pqi_get_physical_disk_info() because it's a fairly
large
2025 * buffer.
2026 */
2027 id_phys = kmalloc(sizeof(*id_phys), GFP_KERNEL);
2028 if (!id_phys) {
2029 dev_warn(&ctrl_info->pci_dev->dev, "%s\n",
2030 out_of_memory_msg);
2031 rc = -ENOMEM;
2032 goto out;
2033 }
2034 }
2035
2036 num_new_devices = num_physicals + num_logicals;
2037
2038 new_device_list = kmalloc_array(num_new_devices,
2039 sizeof(*new_device_list),
2040 GFP_KERNEL);
2041 if (!new_device_list) {
2042 dev_warn(&ctrl_info->pci_dev->dev, "%s\n",
out_of_memory_msg);
2043 rc = -ENOMEM;
2044 goto out;
2045 }
2046
2047 for (i = 0; i < num_new_devices; i++) {
2048 device = kzalloc(sizeof(*device), GFP_KERNEL);
2049 if (!device) {
2050 dev_warn(&ctrl_info->pci_dev->dev, "%s\n",
2051 out_of_memory_msg);
2052 rc = -ENOMEM;
2053 goto out;
2054 }
2055 list_add_tail(&device->new_device_list_entry,
2056 &new_device_list_head);
2057 }
2058
2059 device = NULL;
2060 num_valid_devices = 0;
2061 physical_index = 0;
2062 logical_index
linux-next: Tree for Aug 14
Hi all,
News: The merge window has opened, so please do not add any v5.10
related material to your linux-next included branches until after the
merge window closes again.
Changes since 20200813:
My fixes tree contains:
73c7adb54169 ("device_cgroup: Fix RCU list debugging warning")
Linus' tree lost its WARNING.
Non-merge commits (relative to Linus' tree): 939
1201 files changed, 29318 insertions(+), 10477 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 327 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (dddcbc139e96 Merge tag 'docs-5.9-2' of
git://git.lwn.net/linux)
Merging fixes/master (73c7adb54169 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (06a81c1c7db9 Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging arc-current/for-curr (11ba468877bb Linux 5.8-rc5)
Merging arm-current/fixes (5c6360ee4a0e ARM: 8988/1: mmu: fix crash in EFI
calls due to p4d typo in create_mapping_late())
Merging arm64-fixes/for-next/fixes (6a7389f0312f MAINTAINERS: Include drivers
subdirs for ARM PMU PROFILING AND DEBUGGING entry)
Merging arm-soc-fixes/arm/fixes (fe1d899f4212 ARM: dts: keystone-k2g-evm: fix
rgmii phy-mode for ksz9031 phy)
Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2)
Merging drivers-memory-fixes/fixes (b3a9e3b9622a Linux 5.8-rc1)
Merging m68k-current/for-linus (382f429bb559 m68k: defconfig: Update defconfigs
for v5.8-rc3)
Merging powerpc-fixes/fixes (6553fb799f60 powerpc/pkeys: Fix boot failures with
Nemo board (A-EON AmigaOne X1000))
Merging s390-fixes/fixes (00e4db51259a Merge tag 'perf-tools-2020-08-10' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (94c7eb54c4b8 random32: add a tracepoint for prandom_u32())
Merging bpf/master (a62f68c172c3 doc: Add link to bpf helpers man page)
Merging ipsec/master (61ee4137b574 ip_vti: Fix unused variable warning)
Merging netfilter/master (2f941622fd88 netfilter: nft_compat: remove flush
counter optimization)
Merging ipvs/master (7c7ab580db49 net: Convert to use the fallthrough macro)
Merging wireless-drivers/master (1cfd3426ef98 ath10k: Fix NULL pointer
dereference in AHB device probe)
Merging mac80211/master (9643609423c7 Revert "ipv4: tunnel: fix compilation on
ARCH=um")
Merging rdma-fixes/for-rc (bcf876870b95 Linux 5.8)
Merging sound-current/for-linus (5a25de6df789 ALSA: echoaudio: Fix potential
Oops in snd_echo_resume())
Merging sound-asoc-fixes/for-linus (933cc41085d5 Merge remote-tracking branch
'asoc/for-5.9' into asoc-linus)
Merging regmap-fixes/for-linus (2b0f61e27f75 Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (75f4d068cb0d Merge remote-tracking branch
'regulator/for-5.9' into regulator-linus)
Merging spi-fixes/for-linus (3ea884314328 Merge remote-tracking branch
'spi/for-5.9' into spi-linus)
Merging pci-current/fo
[PATCH v4 16/20] tools: gpio: rename nlines to num_lines
Rename nlines to num_lines to be consistent with other usage for fields
describing the number of entries in an array.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-hammer.c | 26 +-
tools/gpio/gpio-utils.c | 20 ++--
tools/gpio/gpio-utils.h | 6 +++---
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/tools/gpio/gpio-hammer.c b/tools/gpio/gpio-hammer.c
index 9fd926e8cb52..a2c7577fad5c 100644
--- a/tools/gpio/gpio-hammer.c
+++ b/tools/gpio/gpio-hammer.c
@@ -22,7 +22,7 @@
#include
#include "gpio-utils.h"
-int hammer_device(const char *device_name, unsigned int *lines, int nlines,
+int hammer_device(const char *device_name, unsigned int *lines, int num_lines,
unsigned int loops)
{
struct gpiohandle_data data;
@@ -33,7 +33,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
unsigned int iteration = 0;
memset(&data.values, 0, sizeof(data.values));
- ret = gpiotools_request_linehandle(device_name, lines, nlines,
+ ret = gpiotools_request_linehandle(device_name, lines, num_lines,
GPIOHANDLE_REQUEST_OUTPUT, &data,
"gpio-hammer");
if (ret < 0)
@@ -46,15 +46,15 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
goto exit_close_error;
fprintf(stdout, "Hammer lines [");
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d", lines[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "] on %s, initial states: [", device_name);
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d", data.values[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "]\n");
@@ -63,7 +63,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
j = 0;
while (1) {
/* Invert all lines so we blink */
- for (i = 0; i < nlines; i++)
+ for (i = 0; i < num_lines; i++)
data.values[i] = !data.values[i];
ret = gpiotools_set_values(fd, &data);
@@ -81,9 +81,9 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
j = 0;
fprintf(stdout, "[");
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d: %d", lines[i], data.values[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "]\r");
@@ -121,7 +121,7 @@ int main(int argc, char **argv)
const char *device_name = NULL;
unsigned int lines[GPIOHANDLES_MAX];
unsigned int loops = 0;
- int nlines;
+ int num_lines;
int c;
int i;
@@ -158,11 +158,11 @@ int main(int argc, char **argv)
return -1;
}
- nlines = i;
+ num_lines = i;
- if (!device_name || !nlines) {
+ if (!device_name || !num_lines) {
print_usage();
return -1;
}
- return hammer_device(device_name, lines, nlines, loops);
+ return hammer_device(device_name, lines, num_lines, loops);
}
diff --git a/tools/gpio/gpio-utils.c b/tools/gpio/gpio-utils.c
index 16a5d9cb9da2..d527980bcb94 100644
--- a/tools/gpio/gpio-utils.c
+++ b/tools/gpio/gpio-utils.c
@@ -38,7 +38,7 @@
* such as "gpiochip0"
* @lines: An array desired lines, specified by offset
* index for the associated GPIO device.
- * @nline: The number of lines to request.
+ * @num_lines: The number of lines to request.
* @flag: The new flag for requsted gpio. Reference
* "linux/gpio.h" for the meaning of flag.
* @data: Default value will be set to gpio when flag is
@@ -56,7 +56,7 @@
* On failure return the errno.
*/
int gpiotools_request_linehandle(const char *device_name, unsigned int *lines,
-unsigned int nlines, unsigned int flag,
+unsigned int num_lines, unsigned int flag,
struct gpiohandle_data *data,
const char *consumer_label)
{
@@ -78,12 +78,12 @@ int gpiotools_request_linehandle(const char *device_name,
unsigned int *lines,
goto exit_free_name;
}
- for (i = 0; i
[PATCH v4 19/20] tools: gpio: add multi-line monitoring to gpio-event-mon
Extend gpio-event-mon to support monitoring multiple lines.
This would require multiple lineevent requests to implement using uAPI v1,
but can be performed with a single line request using uAPI v2.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-event-mon.c | 45 -
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index d6a831200c18..e50bb107ea3a 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -26,7 +26,8 @@
#include "gpio-utils.h"
int monitor_device(const char *device_name,
- unsigned int line,
+ unsigned int *lines,
+ unsigned int num_lines,
struct gpio_v2_line_config *config,
unsigned int loops)
{
@@ -47,7 +48,7 @@ int monitor_device(const char *device_name,
goto exit_free_name;
}
- ret = gpiotools_request_line(device_name, &line, 1, config,
+ ret = gpiotools_request_line(device_name, lines, num_lines, config,
"gpio-event-mon");
if (ret < 0)
goto exit_device_close;
@@ -55,8 +56,10 @@ int monitor_device(const char *device_name,
lfd = ret;
/* Read initial states */
- values.mask = 1;
+ values.mask = 0;
values.bits = 0;
+ for (i = 0; i < num_lines; i++)
+ gpiotools_set_bit(&values.mask, i);
ret = gpiotools_get_values(lfd, &values);
if (ret < 0) {
fprintf(stderr,
@@ -65,9 +68,23 @@ int monitor_device(const char *device_name,
goto exit_line_close;
}
- fprintf(stdout, "Monitoring line %d on %s\n", line, device_name);
- fprintf(stdout, "Initial line value: %d\n",
- gpiotools_test_bit(values.bits, 0));
+ if (num_lines == 1) {
+ fprintf(stdout, "Monitoring line %d on %s\n", lines[0],
device_name);
+ fprintf(stdout, "Initial line value: %d\n",
+ gpiotools_test_bit(values.bits, 0));
+ } else {
+ fprintf(stdout, "Monitoring lines %d", lines[0]);
+ for (i = 1; i < num_lines - 1; i++)
+ fprintf(stdout, ", %d", lines[i]);
+ fprintf(stdout, " and %d on %s\n", lines[i], device_name);
+ fprintf(stdout, "Initial line values: %d",
+ gpiotools_test_bit(values.bits, 0));
+ for (i = 1; i < num_lines - 1; i++)
+ fprintf(stdout, ", %d",
+ gpiotools_test_bit(values.bits, i));
+ fprintf(stdout, " and %d\n",
+ gpiotools_test_bit(values.bits, i));
+ }
while (1) {
struct gpio_v2_line_event event;
@@ -126,7 +143,7 @@ void print_usage(void)
fprintf(stderr, "Usage: gpio-event-mon [options]...\n"
"Listen to events on GPIO lines, 0->1 1->0\n"
" -n Listen on GPIOs on a named device (must be
stated)\n"
- " -o Offset to monitor\n"
+ " -o Offset of line to monitor (may be repeated)\n"
" -d Set line as open drain\n"
" -s Set line as open source\n"
" -r Listen for rising edges\n"
@@ -146,7 +163,8 @@ void print_usage(void)
int main(int argc, char **argv)
{
const char *device_name = NULL;
- unsigned int line = -1;
+ unsigned int lines[GPIO_V2_LINES_MAX];
+ unsigned int num_lines = 0;
unsigned int loops = 0;
struct gpio_v2_line_config config;
int c;
@@ -162,7 +180,12 @@ int main(int argc, char **argv)
device_name = optarg;
break;
case 'o':
- line = strtoul(optarg, NULL, 10);
+ if (num_lines >= GPIO_V2_LINES_MAX) {
+ print_usage();
+ return -1;
+ }
+ lines[num_lines] = strtoul(optarg, NULL, 10);
+ num_lines++;
break;
case 'd':
config.flags |= GPIO_V2_LINE_FLAG_OPEN_DRAIN;
@@ -182,7 +205,7 @@ int main(int argc, char **argv)
}
}
- if (!device_name || line == -1) {
+ if (!device_name || num_lines == 0) {
print_usage();
return -1;
}
@@ -191,5 +214,5 @@ int main(int argc, char **argv)
"falling edges\n");
config.flags |= EDGE_FLAGS;
}
- return monitor_device(device_name, line, &config, loops);
+ return monitor_device(device_name, lines, num_lines, &config, loops);
}
--
2.28.0
[PATCH v4 20/20] tools: gpio: add debounce support to gpio-event-mon
Add support for debouncing monitored lines to gpio-event-mon.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-event-mon.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index e50bb107ea3a..bd5ea3cc6e85 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -148,11 +148,12 @@ void print_usage(void)
" -s Set line as open source\n"
" -r Listen for rising edges\n"
" -f Listen for falling edges\n"
+ " -b Debounce the line with period n microseconds\n"
" [-c ]Do loops (optional, infinite loop if not
stated)\n"
" -? This helptext\n"
"\n"
"Example:\n"
- "gpio-event-mon -n gpiochip0 -o 4 -r -f\n"
+ "gpio-event-mon -n gpiochip0 -o 4 -r -f -b 1\n"
);
}
@@ -167,11 +168,12 @@ int main(int argc, char **argv)
unsigned int num_lines = 0;
unsigned int loops = 0;
struct gpio_v2_line_config config;
- int c;
+ int c, attr, i;
+ unsigned long debounce_period = 0;
memset(&config, 0, sizeof(config));
config.flags = GPIO_V2_LINE_FLAG_INPUT;
- while ((c = getopt(argc, argv, "c:n:o:dsrf?")) != -1) {
+ while ((c = getopt(argc, argv, "c:n:o:b:dsrf?")) != -1) {
switch (c) {
case 'c':
loops = strtoul(optarg, NULL, 10);
@@ -187,6 +189,9 @@ int main(int argc, char **argv)
lines[num_lines] = strtoul(optarg, NULL, 10);
num_lines++;
break;
+ case 'b':
+ debounce_period = strtoul(optarg, NULL, 10);
+ break;
case 'd':
config.flags |= GPIO_V2_LINE_FLAG_OPEN_DRAIN;
break;
@@ -205,6 +210,15 @@ int main(int argc, char **argv)
}
}
+ if (debounce_period) {
+ attr = config.num_attrs;
+ config.num_attrs++;
+ for (i = 0; i < num_lines; i++)
+ gpiotools_set_bit(&config.attrs[attr].mask, i);
+ config.attrs[attr].attr.id = GPIO_V2_LINE_ATTR_ID_DEBOUNCE;
+ config.attrs[attr].attr.debounce_period = debounce_period;
+ }
+
if (!device_name || num_lines == 0) {
print_usage();
return -1;
--
2.28.0
[PATCH v4 18/20] tools: gpio: port gpio-event-mon to v2 uAPI
Port the gpio-event-mon tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-event-mon.c | 91 +++--
1 file changed, 47 insertions(+), 44 deletions(-)
diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
index 1a303a81aeef..d6a831200c18 100644
--- a/tools/gpio/gpio-event-mon.c
+++ b/tools/gpio/gpio-event-mon.c
@@ -23,17 +23,16 @@
#include
#include
#include
+#include "gpio-utils.h"
int monitor_device(const char *device_name,
unsigned int line,
- uint32_t handleflags,
- uint32_t eventflags,
+ struct gpio_v2_line_config *config,
unsigned int loops)
{
- struct gpioevent_request req;
- struct gpiohandle_data data;
+ struct gpio_v2_line_values values;
char *chrdev_name;
- int fd;
+ int cfd, lfd;
int ret;
int i = 0;
@@ -41,44 +40,39 @@ int monitor_device(const char *device_name,
if (ret < 0)
return -ENOMEM;
- fd = open(chrdev_name, 0);
- if (fd == -1) {
+ cfd = open(chrdev_name, 0);
+ if (cfd == -1) {
ret = -errno;
fprintf(stderr, "Failed to open %s\n", chrdev_name);
goto exit_free_name;
}
- req.lineoffset = line;
- req.handleflags = handleflags;
- req.eventflags = eventflags;
- strcpy(req.consumer_label, "gpio-event-mon");
-
- ret = ioctl(fd, GPIO_GET_LINEEVENT_IOCTL, &req);
- if (ret == -1) {
- ret = -errno;
- fprintf(stderr, "Failed to issue GET EVENT "
- "IOCTL (%d)\n",
- ret);
- goto exit_close_error;
- }
+ ret = gpiotools_request_line(device_name, &line, 1, config,
+"gpio-event-mon");
+ if (ret < 0)
+ goto exit_device_close;
+ else
+ lfd = ret;
/* Read initial states */
- ret = ioctl(req.fd, GPIOHANDLE_GET_LINE_VALUES_IOCTL, &data);
- if (ret == -1) {
- ret = -errno;
- fprintf(stderr, "Failed to issue GPIOHANDLE GET LINE "
- "VALUES IOCTL (%d)\n",
+ values.mask = 1;
+ values.bits = 0;
+ ret = gpiotools_get_values(lfd, &values);
+ if (ret < 0) {
+ fprintf(stderr,
+ "Failed to issue GPIO LINE GET VALUES IOCTL (%d)\n",
ret);
- goto exit_close_error;
+ goto exit_line_close;
}
fprintf(stdout, "Monitoring line %d on %s\n", line, device_name);
- fprintf(stdout, "Initial line value: %d\n", data.values[0]);
+ fprintf(stdout, "Initial line value: %d\n",
+ gpiotools_test_bit(values.bits, 0));
while (1) {
- struct gpioevent_data event;
+ struct gpio_v2_line_event event;
- ret = read(req.fd, &event, sizeof(event));
+ ret = read(lfd, &event, sizeof(event));
if (ret == -1) {
if (errno == -EAGAIN) {
fprintf(stderr, "nothing available\n");
@@ -96,12 +90,14 @@ int monitor_device(const char *device_name,
ret = -EIO;
break;
}
- fprintf(stdout, "GPIO EVENT %llu: ", event.timestamp);
+ fprintf(stdout, "GPIO EVENT at %llu on line %d (%d|%d) ",
+ event.timestamp, event.offset, event.line_seqno,
+ event.seqno);
switch (event.id) {
- case GPIOEVENT_EVENT_RISING_EDGE:
+ case GPIO_V2_LINE_EVENT_RISING_EDGE:
fprintf(stdout, "rising edge");
break;
- case GPIOEVENT_EVENT_FALLING_EDGE:
+ case GPIO_V2_LINE_EVENT_FALLING_EDGE:
fprintf(stdout, "falling edge");
break;
default:
@@ -114,8 +110,11 @@ int monitor_device(const char *device_name,
break;
}
-exit_close_error:
- if (close(fd) == -1)
+exit_line_close:
+ if (close(lfd) == -1)
+ perror("Failed to close line file");
+exit_device_close:
+ if (close(cfd) == -1)
perror("Failed to close GPIO character device file");
exit_free_name:
free(chrdev_name);
@@ -140,15 +139,20 @@ void print_usage(void)
);
}
+#define EDGE_FLAGS \
+ (GPIO_V2_LINE_FLAG_EDGE_RISING | \
+GPIO_V2_LINE_FLAG_EDGE_FALLING)
+
int main(int argc, char **argv)
{
const char *device_name = NULL;
unsigned int line = -1;
unsigned int loops = 0;
- uint32_t handleflags = GPIOHANDLE_REQUEST_INPUT;
- uint32_t eventflags = 0;
+ struct gpio_v2_line_config config;
[PATCH v4 14/20] tools: gpio: port lsgpio to v2 uAPI
Port the lsgpio tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/lsgpio.c | 60 -
1 file changed, 38 insertions(+), 22 deletions(-)
diff --git a/tools/gpio/lsgpio.c b/tools/gpio/lsgpio.c
index b08d7a5e779b..deda38244026 100644
--- a/tools/gpio/lsgpio.c
+++ b/tools/gpio/lsgpio.c
@@ -25,57 +25,73 @@
struct gpio_flag {
char *name;
- unsigned long mask;
+ unsigned long long mask;
};
struct gpio_flag flagnames[] = {
{
- .name = "kernel",
- .mask = GPIOLINE_FLAG_KERNEL,
+ .name = "used",
+ .mask = GPIO_V2_LINE_FLAG_USED,
+ },
+ {
+ .name = "input",
+ .mask = GPIO_V2_LINE_FLAG_INPUT,
},
{
.name = "output",
- .mask = GPIOLINE_FLAG_IS_OUT,
+ .mask = GPIO_V2_LINE_FLAG_OUTPUT,
},
{
.name = "active-low",
- .mask = GPIOLINE_FLAG_ACTIVE_LOW,
+ .mask = GPIO_V2_LINE_FLAG_ACTIVE_LOW,
},
{
.name = "open-drain",
- .mask = GPIOLINE_FLAG_OPEN_DRAIN,
+ .mask = GPIO_V2_LINE_FLAG_OPEN_DRAIN,
},
{
.name = "open-source",
- .mask = GPIOLINE_FLAG_OPEN_SOURCE,
+ .mask = GPIO_V2_LINE_FLAG_OPEN_SOURCE,
},
{
.name = "pull-up",
- .mask = GPIOLINE_FLAG_BIAS_PULL_UP,
+ .mask = GPIO_V2_LINE_FLAG_BIAS_PULL_UP,
},
{
.name = "pull-down",
- .mask = GPIOLINE_FLAG_BIAS_PULL_DOWN,
+ .mask = GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN,
},
{
.name = "bias-disabled",
- .mask = GPIOLINE_FLAG_BIAS_DISABLE,
+ .mask = GPIO_V2_LINE_FLAG_BIAS_DISABLED,
},
};
-void print_flags(unsigned long flags)
+static void print_attributes(struct gpio_v2_line_info *info)
{
int i;
- int printed = 0;
+ const char *field_format = "%s";
for (i = 0; i < ARRAY_SIZE(flagnames); i++) {
- if (flags & flagnames[i].mask) {
- if (printed)
- fprintf(stdout, " ");
- fprintf(stdout, "%s", flagnames[i].name);
- printed++;
+ if (info->flags & flagnames[i].mask) {
+ fprintf(stdout, field_format, flagnames[i].name);
+ field_format = ", %s";
}
}
+
+ if ((info->flags & GPIO_V2_LINE_FLAG_EDGE_RISING) &&
+ (info->flags & GPIO_V2_LINE_FLAG_EDGE_FALLING))
+ fprintf(stdout, field_format, "both-edges");
+ else if (info->flags & GPIO_V2_LINE_FLAG_EDGE_RISING)
+ fprintf(stdout, field_format, "rising-edge");
+ else if (info->flags & GPIO_V2_LINE_FLAG_EDGE_FALLING)
+ fprintf(stdout, field_format, "falling-edge");
+
+ for (i = 0; i < info->num_attrs; i++) {
+ if (info->attrs[i].id == GPIO_V2_LINE_ATTR_ID_DEBOUNCE)
+ fprintf(stdout, ", debounce_period=%dusec",
+ info->attrs[0].debounce_period);
+ }
}
int list_device(const char *device_name)
@@ -109,18 +125,18 @@ int list_device(const char *device_name)
/* Loop over the lines and print info */
for (i = 0; i < cinfo.lines; i++) {
- struct gpioline_info linfo;
+ struct gpio_v2_line_info linfo;
memset(&linfo, 0, sizeof(linfo));
- linfo.line_offset = i;
+ linfo.offset = i;
- ret = ioctl(fd, GPIO_GET_LINEINFO_IOCTL, &linfo);
+ ret = ioctl(fd, GPIO_V2_GET_LINEINFO_IOCTL, &linfo);
if (ret == -1) {
ret = -errno;
perror("Failed to issue LINEINFO IOCTL\n");
goto exit_close_error;
}
- fprintf(stdout, "\tline %2d:", linfo.line_offset);
+ fprintf(stdout, "\tline %2d:", linfo.offset);
if (linfo.name[0])
fprintf(stdout, " \"%s\"", linfo.name);
else
@@ -131,7 +147,7 @@ int list_device(const char *device_name)
fprintf(stdout, " unused");
if (linfo.flags) {
fprintf(stdout, " [");
- print_flags(linfo.flags);
+ print_attributes(&linfo);
fprintf(stdout, "]");
}
fprintf(stdout, "\n");
--
2.28.0
[PATCH v4 09/20] gpiolib: cdev: support edge detection for uAPI v2
Add support for edge detection to lines requested using
GPIO_V2_GET_LINE_IOCTL.
Signed-off-by: Kent Gibson
---
The edge_detector implementation is based on the v1 lineevent implementation.
drivers/gpio/gpiolib-cdev.c | 316 +++-
drivers/gpio/gpiolib.c | 2 +
drivers/gpio/gpiolib.h | 2 +
3 files changed, 319 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 28273f3105d3..1d42a01f5414 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -382,11 +382,43 @@ static int linehandle_create(struct gpio_device *gdev,
void __user *ip)
}
#endif /* CONFIG_GPIO_CDEV_V1 */
+/**
+ * struct edge_detector - contains the state of a line edge detector
+ * @line: the corresponding line request
+ * @irq: the interrupt triggered in response to events on this GPIO
+ * @flags: the flags, GPIO_V2_LINE_FLAG_EDGE_RISING and/or
+ * GPIO_V2_LINE_FLAG_EDGE_FALLING, indicating the edge detection applied
+ * @timestamp: cache for the timestamp storing it between hardirq and IRQ
+ * thread, used to bring the timestamp close to the actual event
+ * @seqno: the seqno for the current edge event in the sequence of events
+ * for the corresponding line request. Ths is drawn from the @line.
+ * @line_seqno: the seqno for the current edge event in the sequence of
+ * events for this line.
+ */
+struct edge_detector {
+ struct line *line;
+ unsigned int irq;
+ u64 flags;
+ /*
+* timestamp and seqno are shared by edge_irq_handler() and
+* edge_irq_thread() which are themselves mutually exclusive.
+*/
+ u64 timestamp;
+ u32 seqno;
+ u32 line_seqno;
+};
+
/**
* struct line - contains the state of a userspace line request
* @gdev: the GPIO device the line request pertains to
* @label: consumer label used to tag descriptors
* @num_descs: the number of descriptors held in the descs array
+ * @wait: wait queue that handles blocking reads of events
+ * @events: KFIFO for the GPIO events
+ * @seqno: the sequence number for edge events generated on all lines in
+ * this line request. Note that this is not used when @num_descs is 1, as
+ * the line_seqno is then the same and is cheaper to calculate.
+ * @edets: an array of edge detectors, of size @num_descs
* @descs: the GPIO descriptors held by this line request, with @num_descs
* elements.
*/
@@ -394,9 +426,146 @@ struct line {
struct gpio_device *gdev;
const char *label;
u32 num_descs;
+ wait_queue_head_t wait;
+ DECLARE_KFIFO_PTR(events, struct gpio_v2_line_event);
+ atomic_t seqno;
+ struct edge_detector *edets;
struct gpio_desc *descs[];
};
+static inline struct gpio_desc *edge_detector_desc(
+ const struct edge_detector *edet)
+{
+ return edet->line->descs[edet - &edet->line->edets[0]];
+}
+
+static irqreturn_t edge_irq_thread(int irq, void *p)
+{
+ struct edge_detector *edet = p;
+ struct line *line = edet->line;
+ struct gpio_desc *desc = edge_detector_desc(edet);
+ struct gpio_v2_line_event le;
+ int ret;
+
+ /* Do not leak kernel stack to userspace */
+ memset(&le, 0, sizeof(le));
+
+ /*
+* We may be running from a nested threaded interrupt in which case
+* we didn't get the timestamp from edge_irq_handler().
+*/
+ if (!edet->timestamp) {
+ le.timestamp = ktime_get_ns();
+ if (line->num_descs != 1)
+ edet->seqno = atomic_inc_return(&line->seqno);
+ } else {
+ le.timestamp = edet->timestamp;
+ }
+ edet->timestamp = 0;
+
+ if (edet->flags == (GPIO_V2_LINE_FLAG_EDGE_RISING |
+ GPIO_V2_LINE_FLAG_EDGE_FALLING)) {
+ int level = gpiod_get_value_cansleep(desc);
+
+ if (level)
+ /* Emit low-to-high event */
+ le.id = GPIO_V2_LINE_EVENT_RISING_EDGE;
+ else
+ /* Emit high-to-low event */
+ le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE;
+ } else if (edet->flags == GPIO_V2_LINE_FLAG_EDGE_RISING) {
+ /* Emit low-to-high event */
+ le.id = GPIO_V2_LINE_EVENT_RISING_EDGE;
+ } else if (edet->flags == GPIO_V2_LINE_FLAG_EDGE_FALLING) {
+ /* Emit high-to-low event */
+ le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE;
+ } else {
+ return IRQ_NONE;
+ }
+ edet->line_seqno++;
+ le.line_seqno = edet->line_seqno;
+ le.seqno = (line->num_descs == 1) ? le.line_seqno : edet->seqno;
+ le.offset = gpio_chip_hwgpio(desc);
+
+ ret = kfifo_in_spinlocked_noirqsave(&line->events, &le,
+ 1, &line->wait.lock);
+ if (ret)
+ wake_up_poll(&line->wait, EPOLLIN
[PATCH v4 11/20] gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL
Add support for the GPIO_V2_LINE_SET_VALUES_IOCTL.
Signed-off-by: Kent Gibson
---
drivers/gpio/gpiolib-cdev.c | 67 +
1 file changed, 67 insertions(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 04472c2b6678..de88b7a5ba0f 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -811,6 +811,71 @@ static long line_get_values(struct line *line, void __user
*ip)
return 0;
}
+static long line_set_values_locked(struct line *line,
+ struct gpio_v2_line_values *lv)
+{
+ DECLARE_BITMAP(vals, GPIO_V2_LINES_MAX);
+ struct gpio_desc **descs;
+ int ret, i, didx, num_set = 0;
+
+ bitmap_zero(vals, GPIO_V2_LINES_MAX);
+ for (i = 0; i < line->num_descs; i++) {
+ if (lv->mask & BIT_ULL(i)) {
+ if (!test_bit(FLAG_IS_OUT, &line->descs[i]->flags))
+ return -EPERM;
+ if (lv->bits & BIT_ULL(i))
+ __set_bit(num_set, vals);
+ num_set++;
+ }
+ }
+ if (num_set == 0)
+ return -EINVAL;
+
+ if (num_set == line->num_descs)
+ /* Reuse the array setting function */
+ return gpiod_set_array_value_complex(false,
+true,
+line->num_descs,
+line->descs,
+NULL,
+vals);
+
+ /* build compacted desc array and values */
+ descs = kmalloc_array(num_set, sizeof(*descs), GFP_KERNEL);
+ for (didx = 0, i = 0; i < line->num_descs; i++) {
+ if (lv->mask & BIT_ULL(i)) {
+ descs[didx] = line->descs[i];
+ didx++;
+ }
+ }
+ ret = gpiod_set_array_value_complex(false,
+ true,
+ num_set,
+ descs,
+ NULL,
+ vals);
+
+ kfree(descs);
+ return ret;
+}
+
+static long line_set_values(struct line *line, void __user *ip)
+{
+ struct gpio_v2_line_values lv;
+ int ret;
+
+ if (copy_from_user(&lv, ip, sizeof(lv)))
+ return -EFAULT;
+
+ mutex_lock(&line->config_mutex);
+
+ ret = line_set_values_locked(line, &lv);
+
+ mutex_unlock(&line->config_mutex);
+
+ return ret;
+}
+
static long line_set_config_locked(struct line *line,
struct gpio_v2_line_config *lc)
{
@@ -880,6 +945,8 @@ static long line_ioctl(struct file *file, unsigned int cmd,
if (cmd == GPIO_V2_LINE_GET_VALUES_IOCTL)
return line_get_values(line, ip);
+ else if (cmd == GPIO_V2_LINE_SET_VALUES_IOCTL)
+ return line_set_values(line, ip);
else if (cmd == GPIO_V2_LINE_SET_CONFIG_IOCTL)
return line_set_config(line, ip);
--
2.28.0
[PATCH v4 12/20] gpiolib: cdev: support setting debounce
Add support for setting debounce on a line via the GPIO uAPI.
Where debounce is not supported by hardware, a software debounce is
provided.
Signed-off-by: Kent Gibson
---
The implementation of the software debouncer waits for the line to be
stable for the debounce period before determining if a level change,
and a corresponding edge event, has occurred. This provides maximum
protection against glitches, but also introduces a debounce_period
latency to edge events.
The software debouncer is integrated with the edge detection as it
utilises the line interrupt, and integration is simpler than getting
the two to interwork. Where software debounce AND edge detection is
required, the debouncer provides both.
Due to the tight integration between the debouncer and edge detection,
and to avoid particular corner cases, it is not allowed to alter the
debounce value if edge detection is enabled. Changing the debounce with
edge detection enabled is a very unlikely use case, so it is preferable
to disallow it rather than complicate the code to allow it.
Should the user wish to alter the debounce value in such cases they will
need to release and re-request the line.
Changes for v4:
- fix handling of mask in line_get_values
Changes for v3:
- only GPIO_V2 field renaming
Changes for v2:
- improve documentation on fields shared by threads.
- use READ_ONCE/WRITE_ONCE for shared fields rather than atomic_t
which was overkill.
drivers/gpio/gpiolib-cdev.c | 265 +++-
drivers/gpio/gpiolib.h | 4 +
2 files changed, 263 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index de88b7a5ba0f..77fabf815de8 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include "gpiolib.h"
@@ -395,6 +397,9 @@ static int linehandle_create(struct gpio_device *gdev, void
__user *ip)
* for the corresponding line request. Ths is drawn from the @line.
* @line_seqno: the seqno for the current edge event in the sequence of
* events for this line.
+ * @work: the worker that implements software debouncing
+ * @sw_debounced: flag indicating if the software debouncer is active
+ * @level: the current debounced physical level of the line
*/
struct edge_detector {
struct line *line;
@@ -406,7 +411,27 @@ struct edge_detector {
*/
u64 timestamp;
u32 seqno;
+ /*
+* line_seqno is used by either edge_irq_thread() or
+* debounce_work_func() which are themselves mutually exclusive.
+*/
u32 line_seqno;
+ /*
+* -- debouncer specific fields --
+*/
+ struct delayed_work work;
+ /*
+* sw_debounce is shared by line_set_config(), which is the only
+* setter, and line_ioctl(), which can live with a slightly stale
+* value.
+*/
+ unsigned int sw_debounced;
+ /*
+* level is shared by debounce_work_func(), which is the only
+* setter, and line_ioctl() which can live with a slightly stale
+* value.
+*/
+ unsigned int level;
};
/**
@@ -523,6 +548,10 @@ static int edge_detector_start(struct edge_detector *edet)
int ret, irq, irqflags = 0;
struct gpio_desc *desc;
+ if (READ_ONCE(edet->sw_debounced))
+ /* debouncer is setup and will provide edge detection */
+ return 0;
+
desc = edge_detector_desc(edet);
irq = gpiod_to_irq(desc);
@@ -554,17 +583,215 @@ static int edge_detector_start(struct edge_detector
*edet)
return 0;
}
+/*
+ * returns the current debounced logical value.
+ */
+static int debounced_value(struct edge_detector *edet)
+{
+ int value;
+
+ /*
+* minor race - debouncer may be stopped here, so edge_detector_stop
+* must leave the value unchanged so the following will read the level
+* from when the debouncer was last running.
+*/
+ value = READ_ONCE(edet->level);
+
+ if (test_bit(FLAG_ACTIVE_LOW, &edge_detector_desc(edet)->flags))
+ value = !value;
+
+ return value;
+}
+
+static irqreturn_t debounce_irq_handler(int irq, void *p)
+{
+ struct edge_detector *edet = p;
+ struct gpio_desc *desc = edge_detector_desc(edet);
+
+ mod_delayed_work(system_wq,
+&edet->work,
+usecs_to_jiffies(READ_ONCE(desc->debounce_period)));
+
+ return IRQ_HANDLED;
+}
+
+static void debounce_work_func(struct work_struct *work)
+{
+ struct gpio_v2_line_event le;
+ int ret, level;
+ struct edge_detector *edet =
+ container_of(work, struct edge_detector, work.work);
+ struct gpio_desc *desc = edge_detector_desc(edet);
+ struct line *line;
[PATCH v4 17/20] tools: gpio: port gpio-hammer to v2 uAPI
Port the gpio-hammer tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-hammer.c | 32 +++
tools/gpio/gpio-utils.c | 119 ++-
tools/gpio/gpio-utils.h | 50 +---
3 files changed, 128 insertions(+), 73 deletions(-)
diff --git a/tools/gpio/gpio-hammer.c b/tools/gpio/gpio-hammer.c
index a2c7577fad5c..54fdf59dd320 100644
--- a/tools/gpio/gpio-hammer.c
+++ b/tools/gpio/gpio-hammer.c
@@ -25,23 +25,30 @@
int hammer_device(const char *device_name, unsigned int *lines, int num_lines,
unsigned int loops)
{
- struct gpiohandle_data data;
+ struct gpio_v2_line_values values;
+ struct gpio_v2_line_config config;
char swirr[] = "-\\|/";
int fd;
int ret;
int i, j;
unsigned int iteration = 0;
- memset(&data.values, 0, sizeof(data.values));
- ret = gpiotools_request_linehandle(device_name, lines, num_lines,
- GPIOHANDLE_REQUEST_OUTPUT, &data,
- "gpio-hammer");
+ memset(&config, 0, sizeof(config));
+ config.flags = GPIO_V2_LINE_FLAG_OUTPUT;
+
+ ret = gpiotools_request_line(device_name, lines, num_lines,
+&config, "gpio-hammer");
if (ret < 0)
goto exit_error;
else
fd = ret;
- ret = gpiotools_get_values(fd, &data);
+ values.mask = 0;
+ values.bits = 0;
+ for (i = 0; i < num_lines; i++)
+ gpiotools_set_bit(&values.mask, i);
+
+ ret = gpiotools_get_values(fd, &values);
if (ret < 0)
goto exit_close_error;
@@ -53,7 +60,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
}
fprintf(stdout, "] on %s, initial states: [", device_name);
for (i = 0; i < num_lines; i++) {
- fprintf(stdout, "%d", data.values[i]);
+ fprintf(stdout, "%d", gpiotools_test_bit(values.bits, i));
if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
@@ -64,14 +71,14 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
while (1) {
/* Invert all lines so we blink */
for (i = 0; i < num_lines; i++)
- data.values[i] = !data.values[i];
+ gpiotools_change_bit(&values.bits, i);
- ret = gpiotools_set_values(fd, &data);
+ ret = gpiotools_set_values(fd, &values);
if (ret < 0)
goto exit_close_error;
/* Re-read values to get status */
- ret = gpiotools_get_values(fd, &data);
+ ret = gpiotools_get_values(fd, &values);
if (ret < 0)
goto exit_close_error;
@@ -82,7 +89,8 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
fprintf(stdout, "[");
for (i = 0; i < num_lines; i++) {
- fprintf(stdout, "%d: %d", lines[i], data.values[i]);
+ fprintf(stdout, "%d: %d", lines[i],
+ gpiotools_test_bit(values.bits, i));
if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
@@ -97,7 +105,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int num_lines,
ret = 0;
exit_close_error:
- gpiotools_release_linehandle(fd);
+ gpiotools_release_line(fd);
exit_error:
return ret;
}
diff --git a/tools/gpio/gpio-utils.c b/tools/gpio/gpio-utils.c
index d527980bcb94..68edc1a329e2 100644
--- a/tools/gpio/gpio-utils.c
+++ b/tools/gpio/gpio-utils.c
@@ -33,34 +33,32 @@
* release these lines.
*/
/**
- * gpiotools_request_linehandle() - request gpio lines in a gpiochip
+ * gpiotools_request_line() - request gpio lines in a gpiochip
* @device_name: The name of gpiochip without prefix "/dev/",
* such as "gpiochip0"
* @lines: An array desired lines, specified by offset
* index for the associated GPIO device.
* @num_lines: The number of lines to request.
- * @flag: The new flag for requsted gpio. Reference
- * "linux/gpio.h" for the meaning of flag.
- * @data: Default value will be set to gpio when flag is
- * GPIOHANDLE_REQUEST_OUTPUT.
- * @consumer_label:The name of consumer, such as "sysfs",
+ * @config:The new config for requested gpio. Reference
+ * "linux/gpio.h" for config details.
+ * @consumer: The name of consumer, such as "sysfs",
* "powerkey". This is useful for other users to
* know who is using.
[PATCH v4 15/20] tools: gpio: port gpio-watch to v2 uAPI
Port the gpio-watch tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-watch.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/gpio/gpio-watch.c b/tools/gpio/gpio-watch.c
index 5cea24fddfa7..6f048350a27e 100644
--- a/tools/gpio/gpio-watch.c
+++ b/tools/gpio/gpio-watch.c
@@ -21,8 +21,8 @@
int main(int argc, char **argv)
{
- struct gpioline_info_changed chg;
- struct gpioline_info req;
+ struct gpio_v2_line_info_changed chg;
+ struct gpio_v2_line_info req;
struct pollfd pfd;
int fd, i, j, ret;
char *event, *end;
@@ -40,11 +40,11 @@ int main(int argc, char **argv)
for (i = 0, j = 2; i < argc - 2; i++, j++) {
memset(&req, 0, sizeof(req));
- req.line_offset = strtoul(argv[j], &end, 0);
+ req.offset = strtoul(argv[j], &end, 0);
if (*end != '\0')
goto err_usage;
- ret = ioctl(fd, GPIO_GET_LINEINFO_WATCH_IOCTL, &req);
+ ret = ioctl(fd, GPIO_V2_GET_LINEINFO_WATCH_IOCTL, &req);
if (ret) {
perror("unable to set up line watch");
return EXIT_FAILURE;
@@ -71,13 +71,13 @@ int main(int argc, char **argv)
}
switch (chg.event_type) {
- case GPIOLINE_CHANGED_REQUESTED:
+ case GPIO_V2_LINE_CHANGED_REQUESTED:
event = "requested";
break;
- case GPIOLINE_CHANGED_RELEASED:
+ case GPIO_V2_LINE_CHANGED_RELEASED:
event = "released";
break;
- case GPIOLINE_CHANGED_CONFIG:
+ case GPIO_V2_LINE_CHANGED_CONFIG:
event = "config changed";
break;
default:
@@ -87,7 +87,7 @@ int main(int argc, char **argv)
}
printf("line %u: %s at %llu\n",
- chg.info.line_offset, event, chg.timestamp);
+ chg.info.offset, event, chg.timestamp);
}
}
--
2.28.0
[PATCH v4 10/20] gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL
Add support for GPIO_V2_LINE_SET_CONFIG_IOCTL, the uAPI v2
line set config ioctl.
Signed-off-by: Kent Gibson
---
drivers/gpio/gpiolib-cdev.c | 92 +
1 file changed, 92 insertions(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 1d42a01f5414..04472c2b6678 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -418,6 +419,8 @@ struct edge_detector {
* @seqno: the sequence number for edge events generated on all lines in
* this line request. Note that this is not used when @num_descs is 1, as
* the line_seqno is then the same and is cheaper to calculate.
+ * @config_mutex: mutex for serializing ioctl() calls to ensure consistency
+ * of configuration, particularly multi-step accesses to desc flags.
* @edets: an array of edge detectors, of size @num_descs
* @descs: the GPIO descriptors held by this line request, with @num_descs
* elements.
@@ -429,6 +432,7 @@ struct line {
wait_queue_head_t wait;
DECLARE_KFIFO_PTR(events, struct gpio_v2_line_event);
atomic_t seqno;
+ struct mutex config_mutex;
struct edge_detector *edets;
struct gpio_desc *descs[];
};
@@ -703,6 +707,30 @@ static int gpio_v2_line_config_validate(struct
gpio_v2_line_config *lc,
return 0;
}
+static int gpio_v2_line_config_change_validate(struct line *line,
+ struct gpio_v2_line_config *lc)
+{
+ int i;
+ u64 flags;
+ struct gpio_desc *desc;
+
+ for (i = 0; i < line->num_descs; i++) {
+ desc = line->descs[i];
+ flags = gpio_v2_line_config_flags(lc, i);
+ /* disallow edge detection changes */
+ if (line->edets[i].flags != (flags & GPIO_V2_LINE_EDGE_FLAGS))
+ return -EINVAL;
+
+ if (line->edets[i].flags) {
+ /* disallow polarity changes */
+ if (test_bit(FLAG_ACTIVE_LOW, &desc->flags) !=
+ ((flags & GPIO_V2_LINE_FLAG_ACTIVE_LOW) != 0))
+ return -EINVAL;
+ }
+ }
+ return 0;
+}
+
static void gpio_v2_line_config_flags_to_desc_flags(u64 flags,
unsigned long *flagsp)
{
@@ -783,6 +811,67 @@ static long line_get_values(struct line *line, void __user
*ip)
return 0;
}
+static long line_set_config_locked(struct line *line,
+ struct gpio_v2_line_config *lc)
+{
+ struct gpio_desc *desc;
+ int i, ret;
+ u64 flags;
+
+ ret = gpio_v2_line_config_change_validate(line, lc);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < line->num_descs; i++) {
+ desc = line->descs[i];
+ flags = gpio_v2_line_config_flags(lc, i);
+
+ gpio_v2_line_config_flags_to_desc_flags(flags, &desc->flags);
+ /*
+* Lines have to be requested explicitly for input
+* or output, else the line will be treated "as is".
+*/
+ if (flags & GPIO_V2_LINE_FLAG_OUTPUT) {
+ int val = gpio_v2_line_config_output_value(lc, i);
+
+ edge_detector_stop(&line->edets[i]);
+ ret = gpiod_direction_output(desc, val);
+ if (ret)
+ return ret;
+ } else if (flags & GPIO_V2_LINE_FLAG_INPUT) {
+ ret = gpiod_direction_input(desc);
+ if (ret)
+ return ret;
+ }
+
+ blocking_notifier_call_chain(&desc->gdev->notifier,
+GPIO_V2_LINE_CHANGED_CONFIG,
+desc);
+ }
+ return 0;
+}
+
+static long line_set_config(struct line *line, void __user *ip)
+{
+ struct gpio_v2_line_config lc;
+ int ret;
+
+ if (copy_from_user(&lc, ip, sizeof(lc)))
+ return -EFAULT;
+
+ ret = gpio_v2_line_config_validate(&lc, line->num_descs);
+ if (ret)
+ return ret;
+
+ mutex_lock(&line->config_mutex);
+
+ ret = line_set_config_locked(line, &lc);
+
+ mutex_unlock(&line->config_mutex);
+
+ return ret;
+}
+
static long line_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
@@ -791,6 +880,8 @@ static long line_ioctl(struct file *file, unsigned int cmd,
if (cmd == GPIO_V2_LINE_GET_VALUES_IOCTL)
return line_get_values(line, ip);
+ else if (cmd == GPIO_V2_LINE_SET_CONFIG_IOCTL)
+ return line_set_config(line, ip);
return -EINVAL;
}
@@ -964,6 +1055,7 @@ static int line_crea
[PATCH v4 13/20] gpio: uapi: document uAPI v1 as deprecated
Update uAPI documentation to deprecate v1 structs and ioctls.
Signed-off-by: Kent Gibson
---
include/uapi/linux/gpio.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 0eb1f53b47e0..4af67415d73e 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -274,6 +274,9 @@ struct gpio_v2_line_event {
/*
* ABI v1
+ *
+ * This version of the ABI is deprecated and will be removed in the future.
+ * Use the latest version of the ABI, defined above, instead.
*/
/* Informational flags */
@@ -297,6 +300,9 @@ struct gpio_v2_line_event {
* @consumer: a functional name for the consumer of this GPIO line as set by
* whatever is using it, will be empty if there is no current user but may
* also be empty if the consumer doesn't set this up
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_info instead.
*/
struct gpioline_info {
__u32 line_offset;
@@ -328,6 +334,9 @@ enum {
* guarantee there are no implicit holes between it and subsequent members.
* The 20-byte padding at the end makes sure we don't add any implicit padding
* at the end of the structure on 64-bit architectures.
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_info_changed instead.
*/
struct gpioline_info_changed {
struct gpioline_info info;
@@ -367,6 +376,9 @@ struct gpioline_info_changed {
* @fd: if successful this field will contain a valid anonymous file handle
* after a GPIO_GET_LINEHANDLE_IOCTL operation, zero or negative value
* means error
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_request instead.
*/
struct gpiohandle_request {
__u32 lineoffsets[GPIOHANDLES_MAX];
@@ -386,6 +398,9 @@ struct gpiohandle_request {
* this specifies the default output value, should be 0 (low) or
* 1 (high), anything else than 0 or 1 will be interpreted as 1 (high)
* @padding: reserved for future use and should be zero filled
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_config instead.
*/
struct gpiohandle_config {
__u32 flags;
@@ -398,6 +413,9 @@ struct gpiohandle_config {
* @values: when getting the state of lines this contains the current
* state of a line, when setting the state of lines these should contain
* the desired target state
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_values instead.
*/
struct gpiohandle_data {
__u8 values[GPIOHANDLES_MAX];
@@ -421,6 +439,9 @@ struct gpiohandle_data {
* @fd: if successful this field will contain a valid anonymous file handle
* after a GPIO_GET_LINEEVENT_IOCTL operation, zero or negative value
* means error
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_request instead.
*/
struct gpioevent_request {
__u32 lineoffset;
@@ -440,6 +461,9 @@ struct gpioevent_request {
* struct gpioevent_data - The actual event being pushed to userspace
* @timestamp: best estimate of time of event occurrence, in nanoseconds
* @id: event identifier
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_event instead.
*/
struct gpioevent_data {
__u64 timestamp;
@@ -464,6 +488,8 @@ struct gpioevent_data {
/*
* v1 ioctl()s
+ *
+ * These ioctl()s are deprecated. Use the v2 equivalent instead.
*/
#define GPIO_GET_LINEINFO_IOCTL _IOWR(0xB4, 0x02, struct gpioline_info)
#define GPIO_GET_LINEHANDLE_IOCTL _IOWR(0xB4, 0x03, struct gpiohandle_request)
--
2.28.0
[PATCH v4 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL
Add support for GPIO_V2_GET_LINEINFO_IOCTL and
GPIO_V2_GET_LINEINFO_WATCH_IOCTL.
Signed-off-by: Kent Gibson
---
The core of this change is the event kfifo switching to contain
struct gpioline_info_changed_v2, instead of v1 as v2 is richer.
The two uAPI versions are mostly independent - other than where they both
provide line info changes via reads on the chip fd. As the info change
structs differ between v1 and v2, the infowatch implementation tracks which
version of the infowatch ioctl, either GPIO_GET_LINEINFO_WATCH_IOCTL or
GPIO_V2_GET_LINEINFO_WATCH_IOCTL, initiates the initial watch and returns
the corresponding info change struct to the read. The version supported
on that fd locks to that version on the first watch request, so subsequent
watches from that process must use the same uAPI version.
Changes for v4:
- replace strncpy with memcpy in gpio_v2_line_info_to_v1
drivers/gpio/gpiolib-cdev.c | 194 +++-
1 file changed, 167 insertions(+), 27 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 8671e04ff989..28273f3105d3 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -162,7 +162,8 @@ static long linehandle_set_config(struct linehandle_state
*lh,
}
blocking_notifier_call_chain(&desc->gdev->notifier,
-GPIOLINE_CHANGED_CONFIG, desc);
+GPIO_V2_LINE_CHANGED_CONFIG,
+desc);
}
return 0;
}
@@ -334,7 +335,7 @@ static int linehandle_create(struct gpio_device *gdev, void
__user *ip)
}
blocking_notifier_call_chain(&desc->gdev->notifier,
-GPIOLINE_CHANGED_REQUESTED, desc);
+GPIO_V2_LINE_CHANGED_REQUESTED,
desc);
dev_dbg(&gdev->dev, "registered chardev handle for line %d\n",
offset);
@@ -716,7 +717,7 @@ static int line_create(struct gpio_device *gdev, void
__user *ip)
}
blocking_notifier_call_chain(&desc->gdev->notifier,
-GPIOLINE_CHANGED_REQUESTED, desc);
+GPIO_V2_LINE_CHANGED_REQUESTED,
desc);
dev_dbg(&gdev->dev, "registered chardev handle for line %d\n",
offset);
@@ -1065,7 +1066,7 @@ static int lineevent_create(struct gpio_device *gdev,
void __user *ip)
goto out_free_le;
blocking_notifier_call_chain(&desc->gdev->notifier,
-GPIOLINE_CHANGED_REQUESTED, desc);
+GPIO_V2_LINE_CHANGED_REQUESTED, desc);
irq = gpiod_to_irq(desc);
if (irq <= 0) {
@@ -1132,17 +1133,59 @@ static int lineevent_create(struct gpio_device *gdev,
void __user *ip)
return ret;
}
+static void gpio_v2_line_info_to_v1(struct gpio_v2_line_info *info_v2,
+ struct gpioline_info *info_v1)
+{
+ int flagsv2 = info_v2->flags;
+
+ memcpy(info_v1->name, info_v2->name, sizeof(info_v1->name));
+ memcpy(info_v1->consumer, info_v2->consumer,
+ sizeof(info_v1->consumer));
+ info_v1->line_offset = info_v2->offset;
+ info_v1->flags = 0;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_USED)
+ info_v1->flags |= GPIOLINE_FLAG_KERNEL;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_OUTPUT)
+ info_v1->flags |= GPIOLINE_FLAG_IS_OUT;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_ACTIVE_LOW)
+ info_v1->flags |= GPIOLINE_FLAG_ACTIVE_LOW;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_OPEN_DRAIN)
+ info_v1->flags |= GPIOLINE_FLAG_OPEN_DRAIN;
+ if (flagsv2 & GPIO_V2_LINE_FLAG_OPEN_SOURCE)
+ info_v1->flags |= GPIOLINE_FLAG_OPEN_SOURCE;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_BIAS_PULL_UP)
+ info_v1->flags |= GPIOLINE_FLAG_BIAS_PULL_UP;
+ if (flagsv2 & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN)
+ info_v1->flags |= GPIOLINE_FLAG_BIAS_PULL_DOWN;
+ if (flagsv2 & GPIO_V2_LINE_FLAG_BIAS_DISABLED)
+ info_v1->flags |= GPIOLINE_FLAG_BIAS_DISABLE;
+}
+
+static void gpio_v2_line_info_changed_to_v1(
+ struct gpio_v2_line_info_changed *lic_v2,
+ struct gpioline_info_changed *lic_v1)
+{
+ gpio_v2_line_info_to_v1(&lic_v2->info, &lic_v1->info);
+ lic_v1->timestamp = lic_v2->timestamp;
+ lic_v1->event_type = lic_v2->event_type;
+}
+
#endif /* CONFIG_GPIO_CDEV_V1 */
static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
- struct gpioline_info *info)
+ struct gpio_v2_line_info *info)
{
struct gpio_chip *gc = desc->gdev->chip;
bool ok_for_pinctrl
[PATCH v4 06/20] gpiolib: add build option for CDEV v1 ABI
Add a build option to allow the removal of the CDEV v1 ABI. Suggested-by: Bartosz Golaszewski Signed-off-by: Kent Gibson --- This patch is before the v2 implementation, and is non-functional until that patch, as some parts of that patch would be written slightly differently if removing v1 was not considered. Adding this patch after that would necessitate revisiting the v2 changes, so this ordering results in two simpler patches. drivers/gpio/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 8e409b9c33dc..0c62e35cf3a6 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -82,6 +82,18 @@ config GPIO_CDEV If unsure, say Y. +config GPIO_CDEV_V1 + bool "Support GPIO ABI Version 1" + default y + depends on GPIO_CDEV + help + Say Y here to support version 1 of the GPIO CDEV ABI. + + This ABI version is deprecated and will be removed in the future. + Please use the latest ABI for new developments. + + If unsure, say Y. + config GPIO_GENERIC depends on HAS_IOMEM # Only for IOMEM drivers tristate -- 2.28.0
[PATCH v4 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL
Add support for requesting lines using the GPIO_V2_GET_LINE_IOCTL, and
returning their current values using GPIO_V2_LINE_GET_VALUES_IOCTL.
Signed-off-by: Kent Gibson
---
The struct line implementation is based on the v1 struct linehandle
implementation.
The line_ioctl() is a simple wrapper around line_get_values() here, but
will be extended with other ioctls in subsequent patches.
Changes for v4:
- fix handling of mask in line_get_values
drivers/gpio/gpiolib-cdev.c | 413
1 file changed, 413 insertions(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 8b012879fe3f..8671e04ff989 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
+#include
#include
#include
#include
@@ -34,6 +36,7 @@
* GPIO line handle management
*/
+#ifdef CONFIG_GPIO_CDEV_V1
/**
* struct linehandle_state - contains the state of a userspace handle
* @gdev: the GPIO device the handle pertains to
@@ -376,6 +379,390 @@ static int linehandle_create(struct gpio_device *gdev,
void __user *ip)
linehandle_free(lh);
return ret;
}
+#endif /* CONFIG_GPIO_CDEV_V1 */
+
+/**
+ * struct line - contains the state of a userspace line request
+ * @gdev: the GPIO device the line request pertains to
+ * @label: consumer label used to tag descriptors
+ * @num_descs: the number of descriptors held in the descs array
+ * @descs: the GPIO descriptors held by this line request, with @num_descs
+ * elements.
+ */
+struct line {
+ struct gpio_device *gdev;
+ const char *label;
+ u32 num_descs;
+ struct gpio_desc *descs[];
+};
+
+#define GPIO_V2_LINE_BIAS_FLAGS \
+ (GPIO_V2_LINE_FLAG_BIAS_PULL_UP | \
+GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN | \
+GPIO_V2_LINE_FLAG_BIAS_DISABLED)
+
+#define GPIO_V2_LINE_DIRECTION_FLAGS \
+ (GPIO_V2_LINE_FLAG_INPUT | \
+GPIO_V2_LINE_FLAG_OUTPUT)
+
+#define GPIO_V2_LINE_DRIVE_FLAGS \
+ (GPIO_V2_LINE_FLAG_OPEN_DRAIN | \
+GPIO_V2_LINE_FLAG_OPEN_SOURCE)
+
+#define GPIO_V2_LINE_VALID_FLAGS \
+ (GPIO_V2_LINE_FLAG_ACTIVE_LOW | \
+GPIO_V2_LINE_DIRECTION_FLAGS | \
+GPIO_V2_LINE_DRIVE_FLAGS | \
+GPIO_V2_LINE_BIAS_FLAGS)
+
+static u64 gpio_v2_line_config_flags(struct gpio_v2_line_config *lc,
+int line_idx)
+{
+ int i;
+ u64 mask = BIT_ULL(line_idx);
+
+ for (i = 0; i < lc->num_attrs; i++) {
+ if ((lc->attrs[i].attr.id == GPIO_V2_LINE_ATTR_ID_FLAGS) &&
+ (lc->attrs[i].mask & mask))
+ return lc->attrs[i].attr.flags;
+ }
+ return lc->flags;
+}
+
+static int gpio_v2_line_config_output_value(struct gpio_v2_line_config *lc,
+ int line_idx)
+{
+ int i;
+ u64 mask = BIT_ULL(line_idx);
+
+ for (i = 0; i < lc->num_attrs; i++) {
+ if ((lc->attrs[i].attr.id ==
GPIO_V2_LINE_ATTR_ID_OUTPUT_VALUES) &&
+ (lc->attrs[i].mask & mask))
+ return !!(lc->attrs[i].attr.values & mask);
+ }
+ return 0;
+}
+
+static int gpio_v2_line_flags_validate(u64 flags)
+{
+ /* Return an error if an unknown flag is set */
+ if (flags & ~GPIO_V2_LINE_VALID_FLAGS)
+ return -EINVAL;
+
+ /*
+* Do not allow both INPUT & OUTPUT flags to be set as they are
+* contradictory.
+*/
+ if ((flags & GPIO_V2_LINE_FLAG_INPUT) &&
+ (flags & GPIO_V2_LINE_FLAG_OUTPUT))
+ return -EINVAL;
+
+ /*
+* Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If
+* the hardware actually supports enabling both at the same time the
+* electrical result would be disastrous.
+*/
+ if ((flags & GPIO_V2_LINE_FLAG_OPEN_DRAIN) &&
+ (flags & GPIO_V2_LINE_FLAG_OPEN_SOURCE))
+ return -EINVAL;
+
+ /* Drive requires explicit output direction. */
+ if ((flags & GPIO_V2_LINE_DRIVE_FLAGS) &&
+ !(flags & GPIO_V2_LINE_FLAG_OUTPUT))
+ return -EINVAL;
+
+ /* Bias requies explicit direction. */
+ if ((flags & GPIO_V2_LINE_BIAS_FLAGS) &&
+ !(flags & GPIO_V2_LINE_DIRECTION_FLAGS))
+ return -EINVAL;
+
+ /* Only one bias flag can be set. */
+ if (((flags & GPIO_V2_LINE_FLAG_BIAS_DISABLED) &&
+(flags & (GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN |
+ GPIO_V2_LINE_FLAG_BIAS_PULL_UP))) ||
+ ((flags & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN) &&
+(flags & GPIO_V2_LINE_FLAG_BIAS_PULL_UP)))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int gpio_v2_line_config_validate(struct gpio_v2_line_config *lc,
+ int num_lines)
+{
+ int i, ret;
+ u64 fl
Re: [PATCH] bootconfig: Fix off-by-one in xbc_node_compose_key_after()
On Thu, 13 Aug 2020 19:38:18 -0700
Andrew Morton wrote:
> On Thu, 13 Aug 2020 18:30:50 -0400 Steven Rostedt wrote:
>
> > From: Steven Rostedt (VMware)
> >
> > While reviewing some patches for bootconfig, I noticed the following
> > code in xbc_node_compose_key_after():
> >
> > ret = snprintf(buf, size, "%s%s", xbc_node_get_data(node),
> >depth ? "." : "");
> > if (ret < 0)
> > return ret;
> > if (ret > size) {
> > size = 0;
> > } else {
> > size -= ret;
> > buf += ret;
> > }
> >
> > But snprintf() returns the number of bytes that would be written, not
> > the number of bytes that are written (ignoring the nul terminator).
> > This means that if the number of non null bytes written were to equal
> > size, then the nul byte, which snprintf() always adds, will overwrite
> > that last byte.
> >
> > ret = snprintf(buf, 5, "hello");
> > printf("buf = '%s'\n", buf);
> > printf("ret = %d\n", ret);
> >
> > produces:
> >
> > buf = 'hell'
> > ret = 5
> >
> > The string was truncated without ret being greater than 5.
> > Test (ret >= size) for overwrite.
>
> What are the end-user visible effects of the bug? IOW, why cc:stable?
>
Hmm, looking at it at a wider view, it may not be an issue. The tools
code calls this code, and I looked to see if it was possible to corrupt
the buffer by an incorrect size. But now that I'm looking at the else
part of the section, it may not be a problem as it may act the same.
That is, ret == size will make size = 0 with the size -= ret, and we
get the same result.
OK, you can drop the patch. Thanks for the review!
Although, there's no error message if the buffer is not big enough to
hold the fields.
Masami?
-- Steve
[PATCH v4 03/20] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes
Replace constant array sizes with a macro constant to clarify the source
of array sizes, provide a place to document any constraints on the size,
and to simplify array sizing in userspace if constructing structs
from their composite fields.
Signed-off-by: Kent Gibson
---
include/uapi/linux/gpio.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 9c27cecf406f..285cc10355b2 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -14,6 +14,11 @@
#include
#include
+/*
+ * The maximum size of name and label arrays.
+ */
+#define GPIO_MAX_NAME_SIZE 32
+
/**
* struct gpiochip_info - Information about a certain GPIO chip
* @name: the Linux kernel name of this GPIO chip
@@ -22,8 +27,8 @@
* @lines: number of GPIO lines on this chip
*/
struct gpiochip_info {
- char name[32];
- char label[32];
+ char name[GPIO_MAX_NAME_SIZE];
+ char label[GPIO_MAX_NAME_SIZE];
__u32 lines;
};
@@ -52,8 +57,8 @@ struct gpiochip_info {
struct gpioline_info {
__u32 line_offset;
__u32 flags;
- char name[32];
- char consumer[32];
+ char name[GPIO_MAX_NAME_SIZE];
+ char consumer[GPIO_MAX_NAME_SIZE];
};
/* Maximum number of requested handles */
@@ -123,7 +128,7 @@ struct gpiohandle_request {
__u32 lineoffsets[GPIOHANDLES_MAX];
__u32 flags;
__u8 default_values[GPIOHANDLES_MAX];
- char consumer_label[32];
+ char consumer_label[GPIO_MAX_NAME_SIZE];
__u32 lines;
int fd;
};
@@ -182,7 +187,7 @@ struct gpioevent_request {
__u32 lineoffset;
__u32 handleflags;
__u32 eventflags;
- char consumer_label[32];
+ char consumer_label[GPIO_MAX_NAME_SIZE];
int fd;
};
--
2.28.0
[PATCH v4 05/20] gpiolib: make cdev a build option
Make the gpiolib-cdev module a build option. This allows the CDEV
interface to be removed from the kernel to reduce kernel size in
applications where is it not required, and provides the parent for
other other CDEV interface specific build options to follow.
Suggested-by: Bartosz Golaszewski
Signed-off-by: Kent Gibson
---
drivers/gpio/Kconfig| 17 +++--
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpiolib-cdev.h | 15 +++
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8030fd91a3cc..8e409b9c33dc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -66,8 +66,21 @@ config GPIO_SYSFS
This ABI is deprecated. If you want to use GPIO from userspace,
use the character device /dev/gpiochipN with the appropriate
- ioctl() operations instead. The character device is always
- available.
+ ioctl() operations instead.
+
+config GPIO_CDEV
+ bool
+ prompt "Character device (/dev/gpiochipN) support" if EXPERT
+ default y
+ help
+ Say Y here to add the character device /dev/gpiochipN interface
+ for GPIOs. The character device allows userspace to control GPIOs
+ using ioctl() operations.
+
+ Only say N if you are sure that the GPIO character device is not
+ required.
+
+ If unsure, say Y.
config GPIO_GENERIC
depends on HAS_IOMEM # Only for IOMEM drivers
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4f9abff4f2dc..7c24c8d77068 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -7,8 +7,8 @@ obj-$(CONFIG_GPIOLIB) += gpiolib.o
obj-$(CONFIG_GPIOLIB) += gpiolib-devres.o
obj-$(CONFIG_GPIOLIB) += gpiolib-legacy.o
obj-$(CONFIG_GPIOLIB) += gpiolib-devprop.o
-obj-$(CONFIG_GPIOLIB) += gpiolib-cdev.o
obj-$(CONFIG_OF_GPIO) += gpiolib-of.o
+obj-$(CONFIG_GPIO_CDEV)+= gpiolib-cdev.o
obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
diff --git a/drivers/gpio/gpiolib-cdev.h b/drivers/gpio/gpiolib-cdev.h
index 973578e7ad10..19a4e3d57120 100644
--- a/drivers/gpio/gpiolib-cdev.h
+++ b/drivers/gpio/gpiolib-cdev.h
@@ -5,7 +5,22 @@
#include
+#ifdef CONFIG_GPIO_CDEV
+
int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt);
void gpiolib_cdev_unregister(struct gpio_device *gdev);
+#else
+
+static inline int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt)
+{
+ return 0;
+}
+
+static inline void gpiolib_cdev_unregister(struct gpio_device *gdev)
+{
+}
+
+#endif /* CONFIG_GPIO_CDEV */
+
#endif /* GPIOLIB_CDEV_H */
--
2.28.0
[PATCH v4 04/20] gpio: uapi: define uAPI v2
Add a new version of the uAPI to address existing 32/64-bit alignment
issues, add support for debounce and event sequence numbers, allow
requested lines with different configurations, and provide some future
proofing by adding padding reserved for future use.
The alignment issue relates to the gpioevent_data, which packs to different
sizes on 32-bit and 64-bit platforms. That creates problems for 32-bit apps
running on 64-bit kernels. uAPI v2 addresses that particular issue, and
the problem more generally, by adding pad fields that explicitly pad
structs out to 64-bit boundaries, so they will pack to the same size now,
and even if some of the reserved padding is used for __u64 fields in the
future.
The new structs have been analysed with pahole to ensure that they
are sized as expected and contain no implicit padding.
The lack of future proofing in v1 makes it impossible to, for example,
add the debounce feature that is included in v2.
The future proofing is addressed by providing configurable attributes in
line config and reserved padding in all structs for future features.
Specifically, the line request, config, info, info_changed and event
structs receive updated versions and new ioctls.
As the majority of the structs and ioctls were being replaced, it is
opportune to rework some of the other aspects of the uAPI:
v1 has three different flags fields, each with their own separate
bit definitions. In v2 that is collapsed to one - gpio_v2_line_flag.
The handle and event requests are merged into a single request, the line
request, as the two requests were mostly the same other than the edge
detection provided by event requests. As a byproduct, the v2 uAPI allows
for multiple lines producing edge events on the same line handle.
This is a new capability as v1 only supports a single line in an event
request.
As a consequence, there are now only two types of file handle to be
concerned with, the chip and the line, and it is clearer which ioctls
apply to which type of handle.
There is also some minor renaming of fields for consistency compared to
their v1 counterparts, e.g. offset rather than lineoffset or line_offset,
and consumer rather than consumer_label.
Additionally, v1 GPIOHANDLES_MAX becomes GPIO_V2_LINES_MAX in v2 for
clarity, and the gpiohandle_data __u8 array becomes a bitmap in
gpio_v2_line_values.
The v2 uAPI is mostly a reorganisation and extension of v1, so userspace
code, particularly libgpiod, should readily port to it.
Signed-off-by: Kent Gibson
---
Changes for v4:
- clarify bitmap width in GPIO_V2_LINES_MAX description
Changes for v3:
- relocated commentary into commit description
- hard limit max requested lines to 64 so bitmaps always fit in a single
u64.
- prefix all v2 symbols with GPIO_V2
- 64-bit flag values to ULL
- use __aligned_u64 to ensure 64-bit fields are 64-bit aligned
- support masked get values, as per set values.
Changes for v2:
- lower case V1 and V2, except in capitalized names
- hyphenate 32/64-bit
- rename bitmap field to bits
- drop PAD_SIZE consts in favour of hard coded numbers
- sort includes
- change config flags to __u64
- increase padding of gpioline_event
- relocate GPIOLINE_CHANGED enum into v2 section (is common with v1)
- rework config to collapse direction, drive, bias and edge enums back
into flags and add optional attributes that can be associated with a
subset of the requested lines.
Changes for v1 (since the RFC):
- document the constraints on array sizes to maintain 32/64 alignment
- add sequence numbers to gpioline_event
- use bitmap for values instead of array of __u8
- gpioline_info_v2 contains gpioline_config instead of its composite fields
- provide constants for all array sizes, especially padding
- renamed "GPIOLINE_FLAG_V2_KERNEL" to "GPIOLINE_FLAG_V2_USED"
- renamed "default_values" to "values"
- made gpioline_direction zero based
- document clock used in gpioline_event timestamp
- add event_buffer_size to gpioline_request
- rename debounce to debounce_period
- rename lines to num_lines
include/uapi/linux/gpio.h | 273 +-
1 file changed, 266 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 285cc10355b2..0eb1f53b47e0 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -16,6 +16,8 @@
/*
* The maximum size of name and label arrays.
+ *
+ * Must be a multiple of 8 to ensure 32/64-bit alignment of structs.
*/
#define GPIO_MAX_NAME_SIZE 32
@@ -32,6 +34,248 @@ struct gpiochip_info {
__u32 lines;
};
+/*
+ * Maximum number of requested lines.
+ *
+ * Must be no greater than 64, as bitmaps are restricted here to 64-bits
+ * for simplicity, and a multiple of 2 to ensure 32/64-bit alignment of
+ * structs.
+ */
+#define GPIO_V2_LINES_MAX 64
+
+/*
+ * The maximum number of configuration attributes associated with a line
+ * request.
+ */
+#define GPIO_V2_LINE_NUM_ATTRS_MAX
[PATCH v4 02/20] gpiolib: cdev: replace strncpy with strscpy
Replace usage of strncpy with strscpy to remove -Wstringop-truncation
warnings.
The structs being populated are zeroed, to prevent stack leakage as
they are returned to userspace, so strscpy performs the equivalent
function without the warnings.
Reported-by: kernel test robot
Signed-off-by: Kent Gibson
---
The memset in gpio_desc_to_lineinfo(), in conjunction with the strscpy,
is necessary as strncpy zeroed pads the remainder of the destination.
It is also guarantees that the info cannot contain kernel stack that could
get leaked to userspace. This is useful here, but is even more important
for the v2 info that this function is changed to generate in a subsequent
patch as that struct contains padding and attribute arrays that need to be
initialised.
drivers/gpio/gpiolib-cdev.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index e95e3eab9867..8b012879fe3f 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -752,6 +752,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
bool ok_for_pinctrl;
unsigned long flags;
+ memset(info, 0, sizeof(*info));
info->line_offset = gpio_chip_hwgpio(desc);
/*
* This function takes a mutex so we must check this before taking
@@ -765,19 +766,11 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
spin_lock_irqsave(&gpio_lock, flags);
- if (desc->name) {
- strncpy(info->name, desc->name, sizeof(info->name));
- info->name[sizeof(info->name) - 1] = '\0';
- } else {
- info->name[0] = '\0';
- }
+ if (desc->name)
+ strscpy(info->name, desc->name, sizeof(info->name));
- if (desc->label) {
- strncpy(info->consumer, desc->label, sizeof(info->consumer));
- info->consumer[sizeof(info->consumer) - 1] = '\0';
- } else {
- info->consumer[0] = '\0';
- }
+ if (desc->label)
+ strscpy(info->consumer, desc->label, sizeof(info->consumer));
/*
* Userspace only need to know that the kernel is using this GPIO so
@@ -841,12 +834,10 @@ static long gpio_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
memset(&chipinfo, 0, sizeof(chipinfo));
- strncpy(chipinfo.name, dev_name(&gdev->dev),
+ strscpy(chipinfo.name, dev_name(&gdev->dev),
sizeof(chipinfo.name));
- chipinfo.name[sizeof(chipinfo.name)-1] = '\0';
- strncpy(chipinfo.label, gdev->label,
+ strscpy(chipinfo.label, gdev->label,
sizeof(chipinfo.label));
- chipinfo.label[sizeof(chipinfo.label)-1] = '\0';
chipinfo.lines = gdev->ngpio;
if (copy_to_user(ip, &chipinfo, sizeof(chipinfo)))
return -EFAULT;
--
2.28.0
[PATCH v3] nvmem: core: add sanity check in nvmem_device_read()
nvmem device read/write could be called directly once nvmem
device registered, the sanity check should be done before each
nvmem_reg_read/write().
Signed-off-by: Bingbu Cao
---
drivers/nvmem/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 927eb5f6003f..09ad5a06efee 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -69,6 +69,9 @@ static BLOCKING_NOTIFIER_HEAD(nvmem_notifier);
static int nvmem_reg_read(struct nvmem_device *nvmem, unsigned int offset,
void *val, size_t bytes)
{
+ if (bytes + offset > nvmem->size)
+ return -EINVAL;
+
if (nvmem->reg_read)
return nvmem->reg_read(nvmem->priv, offset, val, bytes);
@@ -80,6 +83,9 @@ static int nvmem_reg_write(struct nvmem_device *nvmem,
unsigned int offset,
{
int ret;
+ if (bytes + offset > nvmem->size)
+ return -EINVAL;
+
if (nvmem->reg_write) {
gpiod_set_value_cansleep(nvmem->wp_gpio, 0);
ret = nvmem->reg_write(nvmem->priv, offset, val, bytes);
--
2.7.4
[PATCH v4 01/20] gpiolib: cdev: desc_to_lineinfo should set info offset
Set the value of the line info offset in desc_to_lineinfo, rather than relying on it being passed in the info. This makes the function behave as you would expect from the name - it generates the line info corresponding to a given GPIO desc. Signed-off-by: Kent Gibson --- There are some instances where this results in the offset being set when it is already set in the info, but I think this is clearer especially considering that, as part of the replacement of strncpy with strscpy and to to ensure kernel stack cannot be leaked to userspace, the info is zeroed in a subsequent patch. drivers/gpio/gpiolib-cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index e6c9b78adfc2..e95e3eab9867 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -752,6 +752,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc, bool ok_for_pinctrl; unsigned long flags; + info->line_offset = gpio_chip_hwgpio(desc); /* * This function takes a mutex so we must check this before taking * the spinlock. @@ -933,7 +934,6 @@ static int lineinfo_changed_notify(struct notifier_block *nb, return NOTIFY_DONE; memset(&chg, 0, sizeof(chg)); - chg.info.line_offset = gpio_chip_hwgpio(desc); chg.event_type = action; chg.timestamp = ktime_get_ns(); gpio_desc_to_lineinfo(desc, &chg.info); -- 2.28.0
[PATCH v2] sched: print fields name when do sched_show_task
Current sysrq(t) output task fields name are not aligned with
actual task fields value, e.g.:
kernel: sysrq: Show State
kernel: taskPC stack pid father
kernel: systemd S12456 1 0 0x
kernel: Call Trace:
kernel: ? __schedule+0x240/0x740
To make it more readable, print fields name together with task fields
value in same line, remove separate fields name print, new format looks
like:
kernel: sysrq: Show State
kernel: task:systemd state:S stack:12920 pid:1 ppid: 0
flags:0x
kernel: Call Trace:
kernel: __schedule+0x282/0x620
Signed-off-by: Libing Zhou
---
v2:
Quote the new format as well in the changelog per Ingo suggested.
kernel/sched/core.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e15543cb8481..0ad554cb0bbb 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6069,10 +6069,10 @@ void sched_show_task(struct task_struct *p)
if (!try_get_task_stack(p))
return;
- printk(KERN_INFO "%-15.15s %c", p->comm, task_state_to_char(p));
+ pr_info("task:%-15.15s state:%c", p->comm, task_state_to_char(p));
if (p->state == TASK_RUNNING)
- printk(KERN_CONT " running task");
+ pr_cont(" running task");
#ifdef CONFIG_DEBUG_STACK_USAGE
free = stack_not_used(p);
#endif
@@ -6081,8 +6081,8 @@ void sched_show_task(struct task_struct *p)
if (pid_alive(p))
ppid = task_pid_nr(rcu_dereference(p->real_parent));
rcu_read_unlock();
- printk(KERN_CONT "%5lu %5d %6d 0x%08lx\n", free,
- task_pid_nr(p), ppid,
+ pr_cont(" stack:%5lu pid:%5d ppid:%6d flags:0x%08lx\n",
+ free, task_pid_nr(p), ppid,
(unsigned long)task_thread_info(p)->flags);
print_worker_info(KERN_INFO, p);
@@ -6117,13 +6117,6 @@ void show_state_filter(unsigned long state_filter)
{
struct task_struct *g, *p;
-#if BITS_PER_LONG == 32
- printk(KERN_INFO
- " taskPC stack pid father\n");
-#else
- printk(KERN_INFO
- " taskPC stack pid father\n");
-#endif
rcu_read_lock();
for_each_process_thread(g, p) {
/*
--
2.22.0
