Re: [PATCH v5 1/1] memory_hotplug: Add a bounds check to __add_pages
On Mon, 2019-09-30 at 12:21 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> On PowerPC, the address ranges allocated to OpenCAPI LPC memory
> are allocated from firmware. These address ranges may be higher
> than what older kernels permit, as we increased the maximum
> permissable address in commit 4ffe713b7587
> ("powerpc/mm: Increase the max addressable memory to 2PB"). It is
> possible that the addressable range may change again in the
> future.
>
> In this scenario, we end up with a bogus section returned from
> __section_nr (see the discussion on the thread "mm: Trigger bug on
> if a section is not found in __section_nr").
>
> Adding a check here means that we fail early and have an
> opportunity to handle the error gracefully, rather than rumbling
> on and potentially accessing an incorrect section.
>
> Further discussion is also on the thread ("powerpc: Perform a bounds
> check in arch_add_memory")
> http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
>
> Signed-off-by: Alastair D'Silva
> ---
> mm/memory_hotplug.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c73f09913165..1909607da640 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn,
> unsigned long nr_pages,
> return 0;
> }
>
> +static int check_hotplug_memory_addressable(unsigned long pfn,
> + unsigned long nr_pages)
> +{
> + const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
> +
> + if (max_addr >> MAX_PHYSMEM_BITS) {
> + const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS +
> 1)) - 1;
> + WARN(1,
> + "Hotplugged memory exceeds maximum addressable
> address, range=%#lx-%#lx, maximum=%#lx\n",
Gah, these should all be %#llx.
> + PFN_PHYS(pfn), max_addr, max_allowed);
> + return -E2BIG;
> + }
> +
> + return 0;
> +}
> +
> /*
> * Reasonably generic function for adding memory. It is
> * expected that archs that support memory hotplug will
> @@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long
> pfn, unsigned long nr_pages,
> unsigned long nr, start_sec, end_sec;
> struct vmem_altmap *altmap = restrictions->altmap;
>
> + err = check_hotplug_memory_addressable(pfn, nr_pages);
> + if (err)
> + return err;
> +
> if (altmap) {
> /*
>* Validate altmap is within bounds of the total
> request
[PATCH] ARM: module: remove 'always false' statement
The each field of 'struct elf32_rel' is declared as below.
typedef struct elf32_rel {
Elf32_Addr r_offset;
Elf32_Word r_info;
} Elf32_Rel;
typedef __u32 Elf32_Addr;
typedef __u32 Elf32_Word;
This means that 'r_offset' and 'r_info' could contain non-negative value.
So 'always false' statement can be dropped.
Signed-off-by: Austin Kim
---
arch/arm/kernel/module.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f..617de32 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -83,7 +83,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab,
unsigned int symindex,
#endif
offset = ELF32_R_SYM(rel->r_info);
- if (offset < 0 || offset > (symsec->sh_size /
sizeof(Elf32_Sym))) {
+ if (offset > (symsec->sh_size / sizeof(Elf32_Sym))) {
pr_err("%s: section %u reloc %u: bad relocation sym
offset\n",
module->name, relindex, i);
return -ENOEXEC;
@@ -92,8 +92,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab,
unsigned int symindex,
sym = ((Elf32_Sym *)symsec->sh_addr) + offset;
symname = strtab + sym->st_name;
- if (rel->r_offset < 0 || rel->r_offset > dstsec->sh_size -
sizeof(u32)) {
- pr_err("%s: section %u reloc %u sym '%s': out of bounds
relocation, offset %d size %u\n",
+ if (rel->r_offset > dstsec->sh_size - sizeof(u32)) {
+ pr_err("%s: section %u reloc %u sym '%s': out of bounds
relocation, offset %u size %u\n",
module->name, relindex, i, symname,
rel->r_offset, dstsec->sh_size);
return -ENOEXEC;
--
2.6.2
Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings
On Mon, Sep 30, 2019 at 8:35 AM Borislav Petkov wrote: > > On Tue, Sep 24, 2019 at 07:46:59AM +0300, Alexander Kapshuk wrote: > > gawk 5.0.1 generates the regexp warnings shown below: > > GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c > > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape > > sequence `\:' is not a known regexp operator > > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: > > (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape > > sequence `\&' is not a known regexp operator > > > > Ealier versions of gawk are not known to generate these warnings. > > > > The gawk manual referenced below does not list characters ':' and '&' > > as needing escaping, so 'unescape' them. > > https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html > > > > Running diff on the output generated by the script before and after > > applying the patch reported no differences. > > > > Signed-off-by: Alexander Kapshuk > > Reported-by: kbuild test robot > > Reviewed-by: Borislav Petkov > > This is not how Reviewed-by works. Read here: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes > > for future reference. I fixed it up now. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette Thank you for taking in the patch and clarifying my misunderstanding about the use of 'Reviewed-by'. Point taken.
Re: [PATCH v6] perf: Sharing PMU counters across compatible events
Hi Peter, > On Sep 18, 2019, at 10:23 PM, Song Liu wrote: > > This patch tries to enable PMU sharing. To make perf event scheduling > fast, we use special data structures. > > An array of "struct perf_event_dup" is added to the perf_event_context, > to remember all the duplicated events under this ctx. All the events > under this ctx has a "dup_id" pointing to its perf_event_dup. Compatible > events under the same ctx share the same perf_event_dup. The following > figure shows a simplified version of the data structure. > > ctx -> perf_event_dup -> master > ^ > | > perf_event /| > | > perf_event / > > Connection among perf_event and perf_event_dup are built when events are > added or removed from the ctx. So these are not on the critical path of > schedule or perf_rotate_context(). > > On the critical paths (add, del read), sharing PMU counters doesn't > increase the complexity. Helper functions event_pmu_[add|del|read]() are > introduced to cover these cases. All these functions have O(1) time > complexity. > > We allocate a separate perf_event for perf_event_dup->master. This needs > extra attention, because perf_event_alloc() may sleep. To allocate the > master event properly, a new pointer, tmp_master, is added to perf_event. > tmp_master carries a separate perf_event into list_[add|del]_event(). > The master event has valid ->ctx and holds ctx->refcount. > > Details about the handling of the master event is added to > include/linux/perf_event.h, before struct perf_event_dup. Could you please share your comments/suggestions on this work? Thanks, Song
Re: [PATCH] arm64: tegra: only map accessible sysram
On 9/29/19 2:08 PM, Mian Yousaf Kaukab wrote: > Most of the SysRAM is secure and only accessible by TF-A. > Don't map this inaccessible memory in kernel. Only map pages > used by bpmp driver. I don't believe this change is correct. The actual patch doesn't implement mapping a subset of the RAM (a software issue), but rather it changes the DT representation of the SYSRAM hardware. The SYSRAM hardware always does start at 0x3000, even if a subset of the address range is dedicated to a specific purpose. If the kernel must map only part of the RAM, then some additional property should indicate this. Also, I believe it's incorrect to hard-code into the kernel's DT the range of addresses used by the secure monitor/OS, since this can vary depending on what the user actually chooses to install as the secure monitor/OS. Any indication of such regions should be filled in at runtime by some boot firmware or the secure monitor/OS itself, or retrieved using some runtime API rather than DT.
Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings
On Tue, Sep 24, 2019 at 07:46:59AM +0300, Alexander Kapshuk wrote: > gawk 5.0.1 generates the regexp warnings shown below: > GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape > sequence `\:' is not a known regexp operator > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: > (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape > sequence `\&' is not a known regexp operator > > Ealier versions of gawk are not known to generate these warnings. > > The gawk manual referenced below does not list characters ':' and '&' > as needing escaping, so 'unescape' them. > https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html > > Running diff on the output generated by the script before and after > applying the patch reported no differences. > > Signed-off-by: Alexander Kapshuk > Reported-by: kbuild test robot > Reviewed-by: Borislav Petkov This is not how Reviewed-by works. Read here: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes for future reference. I fixed it up now. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] perf: rework memory accounting in perf_mmap()
> On Sep 16, 2019, at 1:10 PM, Hechao Li wrote: > > Song Liu wrote on Mon [2019-Sep-16 12:43:16 -0700]: >> Hi Peter, >> >>> On Sep 4, 2019, at 2:46 PM, Song Liu wrote: >>> >>> perf_mmap() always increases user->locked_vm. As a result, "extra" could >>> grow bigger than "user_extra", which doesn't make sense. Here is an >>> example case: >>> >>> Note: Assume "user_lock_limit" is very small. >>> | # of perf_mmap calls |vma->vm_mm->pinned_vm|user->locked_vm| >>> | 0| 0 | 0 | >>> | 1| user_extra | user_extra| >>> | 2| 3 * user_extra | 2 * user_extra| >>> | 3| 6 * user_extra | 3 * user_extra| >>> | 4| 10 * user_extra | 4 * user_extra| >>> >>> Fix this by maintaining proper user_extra and extra. >>> >>> Reported-by: Hechao Li >>> Cc: Jie Meng >>> Cc: Peter Zijlstra >>> Signed-off-by: Song Liu >> >> Could you please share your feedbacks/comments on this one? >> >> Thanks, >> Song > > The change looks good to me. Thanks, Song. > > Reviewed-By: Hechao Li Thanks Hechao! Hi Peter, Does this fix look good to you? Thanks, Song
[PATCH] iio: adc: Variables could be uninitalized if regmap_read() fails
Several functions in this file are trying to use regmap_read() to
initialize the specific variable, however, if regmap_read() fails,
the variable could be uninitialized but used directly, which is
potentially unsafe. The return value of regmap_read() should be
checked and handled.
Signed-off-by: Yizhuo
---
drivers/iio/adc/bcm_iproc_adc.c | 45 -
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 646ebdc0a8b4..6df19ceb5ff2 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -137,6 +137,7 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq, void
*data)
u32 channel_intr_status;
u32 intr_status;
u32 intr_mask;
+ int ret;
struct iio_dev *indio_dev = data;
struct iproc_adc_priv *adc_priv = iio_priv(indio_dev);
@@ -145,8 +146,19 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq,
void *data)
* Make sure this interrupt is intended for us.
* Handle only ADC channel specific interrupts.
*/
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, _status);
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, _mask);
+ ret = regmap_read(adc_priv->regmap,
+ IPROC_INTERRUPT_STATUS, _status);
+ if (ret) {
+ dev_err(_dev->dev, "Fail to read
IPROC_INTERRUPT_STATUS.\n");
+ return ret;
+ }
+
+ ret = regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, _mask);
+ if (ret) {
+ dev_err(_dev->dev, "Fail to read
IPROC_INTERRUPT_MASK.\n");
+ return ret;
+ }
+
intr_status = intr_status & intr_mask;
channel_intr_status = (intr_status & IPROC_ADC_INTR_MASK) >>
IPROC_ADC_INTR;
@@ -162,6 +174,7 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq,
void *data)
struct iproc_adc_priv *adc_priv;
struct iio_dev *indio_dev = data;
unsigned int valid_entries;
+ int ret;
u32 intr_status;
u32 intr_channels;
u32 channel_status;
@@ -169,23 +182,37 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq,
void *data)
adc_priv = iio_priv(indio_dev);
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, _status);
+ ret = regmap_read(adc_priv->regmap,
+ IPROC_INTERRUPT_STATUS, _status);
+ if (ret) {
+ dev_err(_dev->dev, "Fail to read
IPROC_INTERRUPT_STATUS.\n");
+ return ret;
+ }
+
dev_dbg(_dev->dev,
"iproc_adc_interrupt_handler(),INTRPT_STS:%x\n",
intr_status);
intr_channels = (intr_status & IPROC_ADC_INTR_MASK) >> IPROC_ADC_INTR;
if (intr_channels) {
- regmap_read(adc_priv->regmap,
+ ret = regmap_read(adc_priv->regmap,
IPROC_ADC_CHANNEL_INTERRUPT_STATUS +
IPROC_ADC_CHANNEL_OFFSET * adc_priv->chan_id,
_intr_status);
+ if (ret) {
+ dev_err(_dev->dev, "Fail to read the
register.\n");
+ return ret;
+ }
if (ch_intr_status & IPROC_ADC_CHANNEL_WTRMRK_INTR_MASK) {
- regmap_read(adc_priv->regmap,
+ ret = regmap_read(adc_priv->regmap,
IPROC_ADC_CHANNEL_STATUS +
IPROC_ADC_CHANNEL_OFFSET *
adc_priv->chan_id,
_status);
+ if (ret) {
+ dev_err(_dev->dev, "Fail to read the
register.\n");
+ return ret;
+ }
valid_entries = ((channel_status &
IPROC_ADC_CHANNEL_VALID_ENTERIES_MASK) >>
@@ -230,6 +257,7 @@ static int iproc_adc_do_read(struct iio_dev *indio_dev,
u32 mask;
u32 val_check;
int failed_cnt = 0;
+ int ret;
struct iproc_adc_priv *adc_priv = iio_priv(indio_dev);
mutex_lock(_priv->mutex);
@@ -284,7 +312,12 @@ static int iproc_adc_do_read(struct iio_dev *indio_dev,
* Testing has shown that this may loop a few time, but we have never
* hit the full count.
*/
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, _check);
+ ret = regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, _check);
+ if (ret) {
+ dev_err(_dev->dev, "Fail to read
IPROC_INTERRUPT_MASK.\n");
+ return ret;
+ }
+
while (val_check != val) {
failed_cnt++;
--
2.17.1
Re: [PATCH v4] arm64: use generic free_initrd_mem()
On 09/28/2019 01:32 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> arm64 calls memblock_free() for the initrd area in its implementation of
> free_initrd_mem(), but this call has no actual effect that late in the boot
> process. By the time initrd is freed, all the reserved memory is managed by
> the page allocator and the memblock.reserved is unused, so the only purpose
> of the memblock_free() call is to keep track of initrd memory for debugging
> and accounting.
Thats correct. memblock_free_all() gets called before free_initrd_mem().
>
> Without the memblock_free() call the only difference between arm64 and the
> generic versions of free_initrd_mem() is the memory poisoning.
>
> Move memblock_free() call to the generic code, enable it there
> for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
> implementation of free_initrd_mem() on arm64.
This improves free_initrd_mem() generic implementation for others to use.
>
> Signed-off-by: Mike Rapoport
Tested-by: Anshuman Khandual #arm64
Reviewed-by: Anshuman Khandual
> ---
>
> v4:
> * memblock_free() aligned area around the initrd
>
> v3:
> * fix powerpc build
>
> v2:
> * add memblock_free() to the generic free_initrd_mem()
> * rebase on the current upstream
>
>
> arch/arm64/mm/init.c | 12
> init/initramfs.c | 8
> 2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a5..87a0e3b 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -580,18 +580,6 @@ void free_initmem(void)
> unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
> }
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - unsigned long aligned_start, aligned_end;
> -
> - aligned_start = __virt_to_phys(start) & PAGE_MASK;
> - aligned_end = PAGE_ALIGN(__virt_to_phys(end));
> - memblock_free(aligned_start, aligned_end - aligned_start);
> - free_reserved_area((void *)start, (void *)end, 0, "initrd");
> -}
> -#endif
> -
> /*
> * Dump out memory limit information on panic.
> */
> diff --git a/init/initramfs.c b/init/initramfs.c
> index c47dad0..8ec1be4 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> static ssize_t __init xwrite(int fd, const char *p, size_t count)
> {
> @@ -529,6 +530,13 @@ extern unsigned long __initramfs_size;
>
> void __weak free_initrd_mem(unsigned long start, unsigned long end)
> {
> +#ifdef CONFIG_ARCH_KEEP_MEMBLOCK
> + unsigned long aligned_start = ALIGN_DOWN(start, PAGE_SIZE);
> + unsigned long aligned_end = ALIGN(end, PAGE_SIZE);
> +
> + memblock_free(__pa(aligned_start), aligned_end - aligned_start);
> +#endif
> +
> free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
> "initrd");
> }
>
[PATCH] AF_PACKET doesnt strip VLAN information
When an application sends with AF_PACKET and places a vlan header on
the raw packet; then the AF_PACKET needs to move the tag into the skb
so that it gets processed normally through the rest of the transmit
path.
This is particularly a problem on Hyper-V where the host only allows
vlan in the offload info.
Cc: xe-linux-exter...@cisco.com
---
net/packet/af_packet.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e2742b0..cfe0904 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1849,15 +1849,35 @@ static int packet_rcv_spkt(struct sk_buff *skb, struct
net_device *dev,
return 0;
}
-static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)
+static int packet_parse_headers(struct sk_buff *skb, struct socket *sock)
{
if ((!skb->protocol || skb->protocol == htons(ETH_P_ALL)) &&
sock->type == SOCK_RAW) {
+ __be16 ethertype;
+
skb_reset_mac_header(skb);
+
+ ethertype = eth_hdr(skb)->h_proto;
+ /*
+* If Vlan tag is present in the packet
+* move it to skb
+ */
+ if (eth_type_vlan(ethertype)) {
+ int err;
+ __be16 vlan_tci;
+
+ err = __skb_vlan_pop(skb, _tci);
+ if (unlikely(err))
+ return err;
+
+ __vlan_hwaccel_put_tag(skb, ethertype, vlan_tci);
+ }
+
skb->protocol = dev_parse_header_protocol(skb);
}
skb_probe_transport_header(skb);
+ return 0;
}
/*
@@ -1979,7 +1999,9 @@ static int packet_sendmsg_spkt(struct socket *sock,
struct msghdr *msg,
if (unlikely(extra_len == 4))
skb->no_fcs = 1;
- packet_parse_headers(skb, sock);
+ err = packet_parse_headers(skb, sock);
+ if (err)
+ goto out_unlock;
dev_queue_xmit(skb);
rcu_read_unlock();
--
2.7.4
Re: [EXT] Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
On 2019-09-30 04:43, Biwen Li wrote: >> >> On 2019-09-29 12:36, Biwen Li wrote: >>> On some Layerscape boards like LS2085ARDB and LS2088ARDB, input >>> pull-up resistors on PCA954x MUX device are missing on board, So, if >>> MUX are disabled after powered-on, input lines will float leading to >>> incorrect functionality. SDA and SCL are not "inputs". They are part of a bus and are both bidirectional signals. Speaking of input signals in an I2C context is ambiguous. >> >> Hi! >> >> Are you saying that the parent bus of the mux is relying on some pull-ups >> inside >> the mux? > Yes, as follows: > > VCC > > --- > > |--- > || > > \\ > > /10K resister / 10k resister > > \\ > > || > || >I2C1_SCL I2C1_SCL > | -- > |SCL | > |SCL | >I2C1_SDA | PCA9547 |I2C1_SDA | | > PCA9547 | > |SDA | > |---|SDA | > >-- > --wrong design(need software fix as above or hardware fix)-- > --proper design-- Ok, got it (but the "picture" didn't help). >> >>> Hence, PCA954x MUX device should never be turned-off after power-on. >>> >>> Add property to skip disabling PCA954x MUX device if device tree >>> contains "i2c-mux-never-disable" >>> for PCA954x device node. >>> >>> Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB (Board revision >>> found on Rev.B, Rev.C and Rev.D) >> >> I think you should follow the example of the i2c-mux-gpio driver and >> implement >> the idle-state property instead. >> >> That is a lot more consistent, assuming it solves the problem at hand? > Got it, thanks, I will try it. I'll wait for that patch then, instead of spending more energy on the never-disable approach. Cheers, Peter
[PATCH] PCI: Add Loongson vendor ID and device IDs
Add the Loongson vendor ID and device IDs to pci_ids.h to be used in the future. The Loongson IDs can be found at the following link: https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids Co-developed-by: Lu Zeng Signed-off-by: Lu Zeng Signed-off-by: Tiezhu Yang --- include/linux/pci_ids.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 21a5724..119639d 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -3111,4 +3111,23 @@ #define PCI_VENDOR_ID_NCUBE0x10ff +#define PCI_VENDOR_ID_LOONGSON 0x0014 +#define PCI_DEVICE_ID_LOONGSON_HT 0x7a00 +#define PCI_DEVICE_ID_LOONGSON_APB 0x7a02 +#define PCI_DEVICE_ID_LOONGSON_GMAC0x7a03 +#define PCI_DEVICE_ID_LOONGSON_OTG 0x7a04 +#define PCI_DEVICE_ID_LOONGSON_GPU_2K1000 0x7a05 +#define PCI_DEVICE_ID_LOONGSON_DC 0x7a06 +#define PCI_DEVICE_ID_LOONGSON_HDA 0x7a07 +#define PCI_DEVICE_ID_LOONGSON_SATA0x7a08 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X1 0x7a09 +#define PCI_DEVICE_ID_LOONGSON_SPI 0x7a0b +#define PCI_DEVICE_ID_LOONGSON_LPC 0x7a0c +#define PCI_DEVICE_ID_LOONGSON_DMA 0x7a0f +#define PCI_DEVICE_ID_LOONGSON_EHCI0x7a14 +#define PCI_DEVICE_ID_LOONGSON_GPU_7A1000 0x7a15 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X4 0x7a19 +#define PCI_DEVICE_ID_LOONGSON_OHCI0x7a24 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X8 0x7a29 + #endif /* _LINUX_PCI_IDS_H */ -- 2.1.0
Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y
On Fri, 2019-09-27 at 21:41 +0200, Dmitry Vyukov wrote:
> On Fri, Sep 27, 2019 at 4:22 PM Walter Wu wrote:
> >
> > On Fri, 2019-09-27 at 15:07 +0200, Dmitry Vyukov wrote:
> > > On Fri, Sep 27, 2019 at 5:43 AM Walter Wu
> > > wrote:
> > > >
> > > > memmove() and memcpy() have missing underflow issues.
> > > > When -7 <= size < 0, then KASAN will miss to catch the underflow issue.
> > > > It looks like shadow start address and shadow end address is the same,
> > > > so it does not actually check anything.
> > > >
> > > > The following test is indeed not caught by KASAN:
> > > >
> > > > char *p = kmalloc(64, GFP_KERNEL);
> > > > memset((char *)p, 0, 64);
> > > > memmove((char *)p, (char *)p + 4, -2);
> > > > kfree((char*)p);
> > > >
> > > > It should be checked here:
> > > >
> > > > void *memmove(void *dest, const void *src, size_t len)
> > > > {
> > > > check_memory_region((unsigned long)src, len, false, _RET_IP_);
> > > > check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> > > >
> > > > return __memmove(dest, src, len);
> > > > }
> > > >
> > > > We fix the shadow end address which is calculated, then generic KASAN
> > > > get the right shadow end address and detect this underflow issue.
> > > >
> > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
> > > >
> > > > Signed-off-by: Walter Wu
> > > > Reported-by: Dmitry Vyukov
> > > > ---
> > > > lib/test_kasan.c | 36
> > > > mm/kasan/generic.c | 8 ++--
> > > > 2 files changed, 42 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > > > index b63b367a94e8..8bd014852556 100644
> > > > --- a/lib/test_kasan.c
> > > > +++ b/lib/test_kasan.c
> > > > @@ -280,6 +280,40 @@ static noinline void __init
> > > > kmalloc_oob_in_memset(void)
> > > > kfree(ptr);
> > > > }
> > > >
> > > > +static noinline void __init kmalloc_oob_in_memmove_underflow(void)
> > > > +{
> > > > + char *ptr;
> > > > + size_t size = 64;
> > > > +
> > > > + pr_info("underflow out-of-bounds in memmove\n");
> > > > + ptr = kmalloc(size, GFP_KERNEL);
> > > > + if (!ptr) {
> > > > + pr_err("Allocation failed\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + memset((char *)ptr, 0, 64);
> > > > + memmove((char *)ptr, (char *)ptr + 4, -2);
> > > > + kfree(ptr);
> > > > +}
> > > > +
> > > > +static noinline void __init kmalloc_oob_in_memmove_overflow(void)
> > > > +{
> > > > + char *ptr;
> > > > + size_t size = 64;
> > > > +
> > > > + pr_info("overflow out-of-bounds in memmove\n");
> > > > + ptr = kmalloc(size, GFP_KERNEL);
> > > > + if (!ptr) {
> > > > + pr_err("Allocation failed\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + memset((char *)ptr, 0, 64);
> > > > + memmove((char *)ptr + size, (char *)ptr, 2);
> > > > + kfree(ptr);
> > > > +}
> > > > +
> > > > static noinline void __init kmalloc_uaf(void)
> > > > {
> > > > char *ptr;
> > > > @@ -734,6 +768,8 @@ static int __init kmalloc_tests_init(void)
> > > > kmalloc_oob_memset_4();
> > > > kmalloc_oob_memset_8();
> > > > kmalloc_oob_memset_16();
> > > > + kmalloc_oob_in_memmove_underflow();
> > > > + kmalloc_oob_in_memmove_overflow();
> > > > kmalloc_uaf();
> > > > kmalloc_uaf_memset();
> > > > kmalloc_uaf2();
> > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > index 616f9dd82d12..34ca23d59e67 100644
> > > > --- a/mm/kasan/generic.c
> > > > +++ b/mm/kasan/generic.c
> > > > @@ -131,9 +131,13 @@ static __always_inline bool
> > > > memory_is_poisoned_n(unsigned long addr,
> > > > size_t size)
> > > > {
> > > > unsigned long ret;
> > > > + void *shadow_start = kasan_mem_to_shadow((void *)addr);
> > > > + void *shadow_end = kasan_mem_to_shadow((void *)addr + size - 1)
> > > > + 1;
> > > >
> > > > - ret = memory_is_nonzero(kasan_mem_to_shadow((void *)addr),
> > > > - kasan_mem_to_shadow((void *)addr + size - 1) +
> > > > 1);
> > > > + if ((long)size < 0)
> > > > + shadow_end = kasan_mem_to_shadow((void *)addr + size);
> > >
> > > Hi Walter,
> > >
> > > Thanks for working on this.
> > >
> > > If size<0, does it make sense to continue at all? We will still check
> > > 1PB of shadow memory? What happens when we pass such huge range to
> > > memory_is_nonzero?
> > > Perhaps it's better to produce an error and bail out immediately if
> > > size<0?
> >
> > I agree with what you said. when size<0, it is indeed an unreasonable
> > behavior, it should be blocked from continuing to do.
> >
> >
> > > Also, what's the failure mode of the tests? Didn't they badly corrupt
> > > memory? We tried to keep tests such
RE: [PATCH] staging: exfat: add exfat filesystem code to
> [..] > > Put it in drivers/staging/sdfat/. > > > > But really we want someone from Samsung to say that they will treat > > the staging version as upstream. It doesn't work when people apply > > fixes to their version and a year later back port the fixes into > > staging. The staging tree is going to have tons and tons of white space > > fixes so backports are a pain. All development needs to be upstream > > first where the staging driver is upstream. Otherwise we should just > > wait for Samsung to get it read to be merged in fs/ and not through the > > staging tree. > Quite frankly, > This whole thing came as a huge-huge surprise to us, we did not initiate > upstreaming of exfat/sdfat code and, as of this moment, I'm not exactly > sure that we are prepared for any immediate radical changes to our internal > development process which people all of a sudden want from us. I need to > discuss with related people on internal thread. > please wait a while:) We decide to contribute sdfat directly and treat upstream exfat. Perhaps more time is needed for patch preparation(exfat rename + vfat removal + clean-up) and internal processes. After contributing sdfat v2.2.0 as the base, We will also provide change-set of sdfat v2.3.0 later. Thanks! > > Thanks! > > > > regards, > > dan carpenter > >
[PATCH] spi: lpspi: fix memory leak in fsl_lpspi_probe
In fsl_lpspi_probe an SPI controller is allocated either via
spi_alloc_slave or spi_alloc_master. In all but one error cases this
controller is put by going to error handling code. This commit fixes the
case when pm_runtime_get_sync fails and it should go to the error
handling path.
Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi")
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-fsl-lpspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index d08e9324140e..3528ed5eea9b 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -938,7 +938,7 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(fsl_lpspi->dev);
if (ret < 0) {
dev_err(fsl_lpspi->dev, "failed to enable clock\n");
- return ret;
+ goto out_controller_put;
}
temp = readl(fsl_lpspi->base + IMX7ULP_PARAM);
--
2.17.1
linux-next: Tree for Sep 30
Hi all, Changes since 20190926: The powerpc tree (well, Linus' tree really) gained a build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 462 574 files changed, 9710 insertions(+), 4176 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 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 310 trees (counting Linus' and 77 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 (a3c0e7b1fe1f Merge tag 'libnvdimm-fixes-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm) Merging fixes/master (609488bc979f Linux 5.3-rc2) Merging kbuild-current/fixes (f97c81dc6ca5 Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc) Merging arc-current/for-curr (089cf7f6ecb2 Linux 5.3-rc7) Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for pfn_valid of arm) Merging arm-soc-fixes/arm/fixes (9bfd7319e8d3 Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging arm64-fixes/for-next/fixes (799c85105233 arm64: Fix reference to docs for ARM64_TAGGED_ADDR_ABI) Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache()) Merging powerpc-fixes/fixes (253c892193ab powerpc/eeh: Fix eeh eeh_debugfs_break_device() with SRIOV devices) Merging s390-fixes/fixes (d45331b00ddb Linux 5.3-rc4) Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging bpf/master (3c30819dc68a Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (00b368502d18 xen-netfront: do not assume sk_buff_head list is empty in error handling) Merging netfilter/master (faeacb6ddb13 net: tap: clean up an indentation issue) Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes') Merging wireless-drivers/master (2b481835cf4e wil6210: use after free in wil_netif_rx_any()) Merging mac80211/master (f794dc2304d8 sctp: fix the missing put_user when dumping transport thresholds) Merging rdma-fixes/for-rc (531a64e4c35b RDMA/siw: Fix IPv6 addr_list locking) Merging sound-current/for-linus (f41f900568d9 ALSA: usb-audio: Add DSD support for EVGA NU Audio) Merging sound-asoc-fixes/for-linus (84b66885fdcf Merge branch 'asoc-5.4' into asoc-linus) Merging regmap-fixes/for-linus (0161b8716465 Merge branch 'regmap-5.3' into regmap-linus) Merging regulator-fixes/for-linus (f9a60abc26d9 Merge branch 'regulator-5.4' into regulator-linus) Merging spi-fixes/for-linus (60b76d1c3b0a Merge branch 'spi-5.4' into spi-linus) Merging pci-current/for-linus (5184d449600f Merge tag 'microblaze-v5.4-rc1' of git://git.monstr.eu/linux-2.6-microblaze) Merging driver-core.current/driver-core-linus (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging tty.current/tty-linus (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging usb.current/usb-linus (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt) Merging
[PATCH] spi: gpio: prevent memroy leak in spi_gpio_probe
In spi_gpio_probe an SPI master is allocated via spi_alloc_master, but
this controller should be released if devm_add_action_or_reset fails,
otherwise memory leaks. This commit adds Fixes: spi_contriller_put in
case of failure for devm_add_action_or_reset.
Fixes: 8b797490b4db ("spi: gpio: Make sure spi_master_put() is called in every
error path")
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 1d3e23ec20a6..f9c5bbb74714 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -371,8 +371,10 @@ static int spi_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
status = devm_add_action_or_reset(>dev, spi_gpio_put, master);
- if (status)
+ if (status) {
+ spi_master_put(master);
return status;
+ }
if (of_id)
status = spi_gpio_probe_dt(pdev, master);
--
2.17.1
Re: x86/random: Speculation to the rescue
On Sun, Sep 29, 2019 at 06:16:33PM -0700, Linus Torvalds wrote: > > - or just say "hey, a lot of people find jitter entropy reasonable, > so let's just try this". > I'm OK with this as a starting point. If a jitter entropy system allow us to get pass this logjam, let's do it. At least for the x86 architecture, it will be security through obscurity. And if the alternative is potentially failing where the adversary can attack the CRNG, it's my preference. It's certainly better than nothing. That being said, I'd very much like to see someone do an analysis of how well these jitter schemes work on an RISC-V iplementation (you know, the ones that were so simplistic and didn't have any speculation so they weren't vulnerable to Specture/Meltdown). If jitter approaches turn out not to work that well on RISC-V, perhaps that will be a goad for future RISC-V chips to include the crypto extension to their ISA. In the long term (not in time for the 5.4 merge window), I'm convinced that we should be trying as many ways of getting entropy as possible. If we're using UEFI, we should be trying to get it from UEFI's secure random number generator; if there is a TPM, we should be trying to get random numbers from the RPM, and mix them in, and so on. After all, the reason why lived with getrandom(0) blocking for five years was because for the vast majority of x86 platforms, it simply wasn't problem in practice. We need to get back to that place where in practice, we've harvested as much uncertainty from hardware as possible, so most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security. - Ted
[v2,2/2] dt-bindings: i2c-mux-pca954x: Add optional property i2c-mux-never-disable
The patch adds an optional property i2c-mux-never-disable Signed-off-by: Biwen Li --- Change in v2: - update documentation Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt index 30ac6a60f041..71b73d0fdb62 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt @@ -34,6 +34,7 @@ Optional Properties: - first cell is the pin number - second cell is used to specify flags. See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + - i2c-mux-never-disable: always forces mux to be enabled. Example: -- 2.17.1
[v2,1/2] i2c: pca954x: Add property to skip disabling PCA954x MUX device
On some Layerscape boards like LS2085ARDB and LS2088ARDB,
input pull-up resistors on PCA954x MUX device are missing on board,
So, if MUX are disabled after powered-on, input lines will float
leading to incorrect functionality.
Hence, PCA954x MUX device should never be turned-off after
power-on.
Add property to skip disabling PCA954x MUX device
if device tree contains "i2c-mux-never-disable"
for PCA954x device node.
Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB
(The hardware bug found on board revision
Rev.B, Rev.C and Rev.D)
Signed-off-by: Biwen Li
---
Change in v2:
- update variable name
disable_mux->never_disable
drivers/i2c/muxes/i2c-mux-pca954x.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 923aa3a5a3dc..b4647b033163 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -93,6 +93,11 @@ struct pca954x {
struct irq_domain *irq;
unsigned int irq_mask;
raw_spinlock_t lock;
+ /*
+* never disable value will write to control register of mux
+* to always enable mux
+*/
+ u8 never_disable;
};
/* Provide specs for the PCA954x types we know about */
@@ -258,6 +263,11 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc,
u32 chan)
struct i2c_client *client = data->client;
s8 idle_state;
+ if (data->never_disable) {
+ data->last_chan = data->chip->nchans;
+ return pca954x_reg_write(muxc->parent, client,
data->never_disable);
+ }
+
idle_state = READ_ONCE(data->idle_state);
if (idle_state >= 0)
/* Set the mux back to a predetermined channel */
@@ -462,16 +472,32 @@ static int pca954x_probe(struct i2c_client *client,
}
}
+ /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
+* The point here is that you must not disable a mux if there
+* are no pullups on the input or you mess up the I2C. This
+* needs to be put into the DTS really as the kernel cannot
+* know this otherwise.
+*/
+
+ data->never_disable = np &&
+ of_property_read_bool(np, "i2c-mux-never-disable") &&
+ data->chip->muxtype == pca954x_ismux ?
+ data->chip->enable : 0;
+
/* Write the mux register at addr to verify
* that the mux is in fact present. This also
* initializes the mux to disconnected state.
*/
- if (i2c_smbus_write_byte(client, 0) < 0) {
+ if (i2c_smbus_write_byte(client, data->never_disable) < 0) {
dev_warn(dev, "probe failed\n");
return -ENODEV;
}
- data->last_chan = 0; /* force the first selection */
+ if (data->never_disable)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0; /* force the first selection
*/
+
data->idle_state = MUX_IDLE_AS_IS;
idle_disconnect_dt = np &&
@@ -531,8 +557,11 @@ static int pca954x_resume(struct device *dev)
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
struct pca954x *data = i2c_mux_priv(muxc);
- data->last_chan = 0;
- return i2c_smbus_write_byte(client, 0);
+ if (data->never_disable)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0;
+ return i2c_smbus_write_byte(client, data->never_disable);
}
#endif
--
2.17.1
Re: [PATCH v8] perf diff: Report noisy for cycles diff
Hi Jiri, Hi Arnaldo, Can this patch be accepted? Thanks Jin Yao On 9/25/2019 9:14 AM, Jin Yao wrote: This patch prints the stddev and hist for the cycles diff of program block. It can help us to understand if the cycles is noisy or not. This patch is inspired by Andi Kleen's patch https://lwn.net/Articles/600471/ We create new option '--cycles-hist'. Example: perf record -b ./div perf record -b ./div perf diff -c cycles # Baseline [Program Block Range] Cycles Diff Shared Object Symbol # .. . # 46.72% [div.c:40 -> div.c:40]0 div[.] main 46.72% [div.c:42 -> div.c:44]0 div[.] main 46.72% [div.c:42 -> div.c:39]0 div[.] main 20.54% [random_r.c:357 -> random_r.c:394]1 libc-2.27.so [.] __random_r 20.54% [random_r.c:357 -> random_r.c:380]0 libc-2.27.so [.] __random_r 20.54% [random_r.c:388 -> random_r.c:388]0 libc-2.27.so [.] __random_r 20.54% [random_r.c:388 -> random_r.c:391]0 libc-2.27.so [.] __random_r 17.04% [random.c:288 -> random.c:291]0 libc-2.27.so [.] __random 17.04% [random.c:291 -> random.c:291]0 libc-2.27.so [.] __random 17.04% [random.c:293 -> random.c:293]0 libc-2.27.so [.] __random 17.04% [random.c:295 -> random.c:295]0 libc-2.27.so [.] __random 17.04% [random.c:295 -> random.c:295]0 libc-2.27.so [.] __random 17.04% [random.c:298 -> random.c:298]0 libc-2.27.so [.] __random 8.40% [div.c:22 -> div.c:25]0 div[.] compute_flag 8.40% [div.c:27 -> div.c:28]0 div[.] compute_flag 5.14% [rand.c:26 -> rand.c:27]0 libc-2.27.so [.] rand 5.14% [rand.c:28 -> rand.c:28]0 libc-2.27.so [.] rand 2.15% [rand@plt+0 -> rand@plt+0]0 div[.] rand@plt 0.00% [kernel.kallsyms] [k] __x86_indirect_thunk_rax 0.00% [do_mmap+714 -> do_mmap+732] -10 [kernel.kallsyms] [k] do_mmap 0.00% [do_mmap+737 -> do_mmap+765]1 [kernel.kallsyms] [k] do_mmap 0.00% [do_mmap+262 -> do_mmap+299]0 [kernel.kallsyms] [k] do_mmap 0.00% [__x86_indirect_thunk_r15+0 -> __x86_indirect_thunk_r15+0]7 [kernel.kallsyms] [k] __x86_indirect_thunk_r15 0.00% [native_sched_clock+0 -> native_sched_clock+119] -1 [kernel.kallsyms] [k] native_sched_clock 0.00%[native_write_msr+0 -> native_write_msr+16] -13 [kernel.kallsyms] [k] native_write_msr When we enable the option '--cycles-hist', the output is perf diff -c cycles --cycles-hist # Baseline [Program Block Range] Cycles Diffstddev/Hist Shared Object Symbol # .. . . # 46.72% [div.c:40 -> div.c:40]0 ± 37.8% ▁█▁▁██▁█ div[.] main 46.72% [div.c:42 -> div.c:44]0 ± 49.4% ▁▁▂█ div[.] main 46.72% [div.c:42 -> div.c:39]0 ± 24.1% ▃█▂▄▁▃▂▁ div[.] main 20.54% [random_r.c:357 -> random_r.c:394]1 ± 33.5% ▅▂▁█▃▁▂▁ libc-2.27.so [.] __random_r 20.54% [random_r.c:357 -> random_r.c:380]0 ± 39.4% ▁▁█▁██▅▁ libc-2.27.so [.] __random_r 20.54% [random_r.c:388 -> random_r.c:388]0 libc-2.27.so [.] __random_r 20.54%
[PATCH] fs: affs: fix a memroy leak in affs_remount
In affs_remount if data is provided it is duplicated into new_opts. But this is not actually used later! The allocated memory for new_opts is only released if pare_options fail. This commit adds release for new_opts. Signed-off-by: Navid Emamdoost --- fs/affs/super.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/affs/super.c b/fs/affs/super.c index cc463ae47c12..1d38fdbc5148 100644 --- a/fs/affs/super.c +++ b/fs/affs/super.c @@ -598,6 +598,8 @@ affs_remount(struct super_block *sb, int *flags, char *data) memcpy(sbi->s_volume, volume, 32); spin_unlock(>symlink_lock); + kfree(new_opts); + if ((bool)(*flags & SB_RDONLY) == sb_rdonly(sb)) return 0; -- 2.17.1
Re: [GIT PULL] SMB3 Fixes
The pull request you sent on Sat, 28 Sep 2019 16:36:21 -0500: > git://git.samba.org/sfrench/cifs-2.6.git tags/5.4-rc-smb3-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7edee5229c8f4e075fe71274620bb11ead885c9b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Documentation/process/embargoed-hardware-issues patches for 5.4-rc1
The pull request you sent on Sun, 29 Sep 2019 12:53:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > tags/char-misc-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/97f9a3c4eee55b0178b518ae7114a6a53372913d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: x86/random: Speculation to the rescue
On Sun, Sep 29, 2019 at 6:16 PM Linus Torvalds wrote: > > But I've committed that patch and the revert of the ext4 revert to a > local branch, I'll do some basic testing of it (which honestly on my > machines are kind of pointless, since all of them support rdrand), but > assuming it passes the basic smoke tests - and I expect it to - I'll > merge it for rc1. All my smoke testing looked fine - I disabled trusting the CPU, I increased the required entropy a lot, and to actually trigger the lockup issue without the broken user space, I made /dev/urandom do that "wait for entropy" thing too. It all looked sane to me, and the urandom part also had the side effect of then silencing all the "reading urandom without entropy" warning cases as expected. So it's merged. Note that what I merged did _not_ contain the urandom changes, that was purely for my testing. But it might well be a reasonable thing to do at some point. Of course, whether this jitter-entropy approach is reasonable in the first place ends up likely being debated, but it does seem to be the simplest way forward. Linus
RE: [EXT] Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
> > Hello Biwen, > > > + /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB: > > +* The point here is that you must not disable a mux if there > > +* are no pullups on the input or you mess up the I2C. This > > +* needs to be put into the DTS really as the kernel cannot > > +* know this otherwise. > > +*/ > > Can you please explain what a "mess up" is? This is a hardware bug that happened on NXP board LS2085ARDB and LS2088ARDB. So give a software fix for the hardware bug. > > And also, should we put this new DTS property in related default bindings? > > If not, are you planning a documentation update for the users to notify them > about this? I will update bindings document on v2. > > -- > Cengiz Can
RE: [EXT] Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
>
> On 2019-09-29 12:36, Biwen Li wrote:
> > On some Layerscape boards like LS2085ARDB and LS2088ARDB, input
> > pull-up resistors on PCA954x MUX device are missing on board, So, if
> > MUX are disabled after powered-on, input lines will float leading to
> > incorrect functionality.
>
> Hi!
>
> Are you saying that the parent bus of the mux is relying on some pull-ups
> inside
> the mux?
Yes, as follows:
VCC
---
|---
||
\\
/10K resister / 10k resister
\\
||
||
I2C1_SCL I2C1_SCL |
--
|SCL |
|SCL |
I2C1_SDA | PCA9547 |I2C1_SDA | |
PCA9547 |
|SDA |
|---|SDA |
--
--wrong design(need software fix as above or hardware fix)--
--proper design--
>
> > Hence, PCA954x MUX device should never be turned-off after power-on.
> >
> > Add property to skip disabling PCA954x MUX device if device tree
> > contains "i2c-mux-never-disable"
> > for PCA954x device node.
> >
> > Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB (Board revision
> > found on Rev.B, Rev.C and Rev.D)
>
> I think you should follow the example of the i2c-mux-gpio driver and implement
> the idle-state property instead.
>
> That is a lot more consistent, assuming it solves the problem at hand?
Got it, thanks, I will try it.
>
> >
> > Signed-off-by: Biwen Li
> > ---
> > drivers/i2c/muxes/i2c-mux-pca954x.c | 33
> > +
> > 1 file changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > index 923aa3a5a3dc..ea8aca54d572 100644
> > --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > @@ -93,6 +93,7 @@ struct pca954x {
> > struct irq_domain *irq;
> > unsigned int irq_mask;
> > raw_spinlock_t lock;
> > + u8 disable_mux; /* do not disable mux if val not 0 */
>
> Awful number of negations there. The name is also backwards given that a
> non-zero value means that the mux should *not* be disabled. I would have
> reused the name from the binding.
>
> bool never_disable;
>
> A bit less confusing...
Got it,thanks, I will let it clear in v2.
>
> > };
> >
> > /* Provide specs for the PCA954x types we know about */ @@ -258,6
> > +259,11 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc,
> u32 chan)
> > struct i2c_client *client = data->client;
> > s8 idle_state;
> >
> > + if (data->disable_mux != 0) {
>
> Please drop " != 0" and use the variable as a truth value. More instances
> below...
Got it, I will correct it in v2.
>
> > + data->last_chan = data->chip->nchans;
> > + return pca954x_reg_write(muxc->parent, client,
> data->disable_mux);
> > + }
> > +
> > idle_state = READ_ONCE(data->idle_state);
> > if (idle_state >= 0)
> > /* Set the mux back to a predetermined channel */ @@
> > -462,16 +468,32 @@ static int pca954x_probe(struct i2c_client *client,
> > }
> > }
> >
> > + /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
> > + * The point here is that you must not disable a mux if there
> > + * are no pullups on the input or you mess up the I2C. This
> > + * needs to be put into the DTS really as the kernel cannot
> > + * know this otherwise.
> > + */
> > +
> > + data->disable_mux = np &&
> > + of_property_read_bool(np, "i2c-mux-never-disable") &&
>
> i2c-mux-never-disable needs to be documented. However see above for my
> point that you should do it like the i2c-mux-gpio driver. Any usage of
> idle-state
> still needs to be documented
[PATCH] usb: dwc3: pci: prevent memory leak in dwc3_pci_probe
In dwc3_pci_probe a call to platform_device_alloc allocates a device
which is correctly put in case of error except one case: when the call to
platform_device_add_properties fails it directly returns instead of
going to error handling. This commit replaces return with the goto.
Fixes: 1a7b12f69a94 ("usb: dwc3: pci: Supply device properties via driver data")
Signed-off-by: Navid Emamdoost
---
drivers/usb/dwc3/dwc3-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 5e8e18222f92..023f0357efd7 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -258,7 +258,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, const struct
pci_device_id *id)
ret = platform_device_add_properties(dwc->dwc3, p);
if (ret < 0)
- return ret;
+ goto err;
ret = dwc3_pci_quirks(dwc);
if (ret)
--
2.17.1
Re: [PATCH] virt: vbox: fix memory leak in hgcm_call_preprocess_linaddr
It is a neat fix now, thank you.
On Sat, Sep 28, 2019 at 4:54 AM Hans de Goede wrote:
>
> Hi,
>
> On 28-09-2019 01:04, Navid Emamdoost wrote:
> > In hgcm_call_preprocess_linaddr memory is allocated for bounce_buf but
> > is not released if copy_form_user fails. The release is added.
> >
> > Fixes: 579db9d45cb4 ("virt: Add vboxguest VMMDEV communication code")
> >
> > Signed-off-by: Navid Emamdoost
>
> Thank you for catching this, I agree this is a bug, but I think we
> can fix it in a cleaner way (see below).
>
> > ---
> > drivers/virt/vboxguest/vboxguest_utils.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/virt/vboxguest/vboxguest_utils.c
> > b/drivers/virt/vboxguest/vboxguest_utils.c
> > index 75fd140b02ff..7965885a50fa 100644
> > --- a/drivers/virt/vboxguest/vboxguest_utils.c
> > +++ b/drivers/virt/vboxguest/vboxguest_utils.c
> > @@ -222,8 +222,10 @@ static int hgcm_call_preprocess_linaddr(
> >
> > if (copy_in) {
> > ret = copy_from_user(bounce_buf, (void __user *)buf, len);
> > - if (ret)
> > + if (ret) {
> > + kvfree(bounce_buf);
> > return -EFAULT;
> > + }
> > } else {
> > memset(bounce_buf, 0, len);
> > }
> >
>
> First let me quote some more of the function, pre leak fix, for context:
>
> bounce_buf = kvmalloc(len, GFP_KERNEL);
> if (!bounce_buf)
> return -ENOMEM;
>
> if (copy_in) {
> ret = copy_from_user(bounce_buf, (void __user *)buf, len);
> if (ret)
> return -EFAULT;
> } else {
> memset(bounce_buf, 0, len);
> }
>
> *bounce_buf_ret = bounce_buf;
>
> This function gets called repeatedly by hgcm_call_preprocess(), and the
> caller of hgcm_call_preprocess() already takes care of freeing the
> bounce bufs both on a (later) error and on success:
>
> ret = hgcm_call_preprocess(parms, parm_count, _bufs, );
> if (ret) {
> /* Even on error bounce bufs may still have been allocated */
> goto free_bounce_bufs;
> }
>
> ...
>
> free_bounce_bufs:
> if (bounce_bufs) {
> for (i = 0; i < parm_count; i++)
> kvfree(bounce_bufs[i]);
> kfree(bounce_bufs);
> }
>
> So we are already taking care of freeing bounce-bufs allocated for previous
> parameters to the call (which me must do anyways), so a cleaner fix would
> be to store the allocated bounce_buf in the bounce_bufs array before
> doing the copy_from_user, then if copy_from_user fails it will be cleaned
> up by the code at the free_bounce_bufs label.
>
> IOW I believe it is better to fix this by changing the part of
> hgcm_call_preprocess_linaddr I quoted to:
>
> bounce_buf = kvmalloc(len, GFP_KERNEL);
> if (!bounce_buf)
> return -ENOMEM;
>
> *bounce_buf_ret = bounce_buf;
>
> if (copy_in) {
> ret = copy_from_user(bounce_buf, (void __user *)buf, len);
> if (ret)
> return -EFAULT;
> } else {
> memset(bounce_buf, 0, len);
> }
>
> This should also fix the leak in IMHO is a clear way of doing so.
>
> Regards,
>
> Hans
>
>
>
>
>
--
Navid.
[PATCH v5 0/1] Add bounds check for Hotplugged memory
From: Alastair D'Silva This series adds bounds checks for hotplugged memory, ensuring that it is within the physically addressable range (for platforms that define MAX_(POSSIBLE_)PHYSMEM_BITS. This allows for early failure, rather than attempting to access bogus section numbers. Changelog: V5: - Factor out calculation into max_allowed var - Declare unchanging vars as const - Use PFN_PHYS macro instead of shifting by PAGE_SHIFT V4: - Relocate call to __add_pages - Add a warning when the addressable check fails V3: - Perform the addressable check before we take the hotplug lock V2: - Don't use MAX_POSSIBLE_PHYSMEM_BITS as it's wider that what may be available Alastair D'Silva (1): memory_hotplug: Add a bounds check to __add_pages mm/memory_hotplug.c | 20 1 file changed, 20 insertions(+) -- 2.21.0
[PATCH v5 1/1] memory_hotplug: Add a bounds check to __add_pages
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB"). It is
possible that the addressable range may change again in the
future.
In this scenario, we end up with a bogus section returned from
__section_nr (see the discussion on the thread "mm: Trigger bug on
if a section is not found in __section_nr").
Adding a check here means that we fail early and have an
opportunity to handle the error gracefully, rather than rumbling
on and potentially accessing an incorrect section.
Further discussion is also on the thread ("powerpc: Perform a bounds
check in arch_add_memory")
http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
Signed-off-by: Alastair D'Silva
---
mm/memory_hotplug.c | 20
1 file changed, 20 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..1909607da640 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn, unsigned long
nr_pages,
return 0;
}
+static int check_hotplug_memory_addressable(unsigned long pfn,
+ unsigned long nr_pages)
+{
+ const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
+
+ if (max_addr >> MAX_PHYSMEM_BITS) {
+ const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS + 1)) - 1;
+ WARN(1,
+"Hotplugged memory exceeds maximum addressable address,
range=%#lx-%#lx, maximum=%#lx\n",
+PFN_PHYS(pfn), max_addr, max_allowed);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
/*
* Reasonably generic function for adding memory. It is
* expected that archs that support memory hotplug will
@@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned
long nr_pages,
unsigned long nr, start_sec, end_sec;
struct vmem_altmap *altmap = restrictions->altmap;
+ err = check_hotplug_memory_addressable(pfn, nr_pages);
+ if (err)
+ return err;
+
if (altmap) {
/*
* Validate altmap is within bounds of the total request
--
2.21.0
[V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support
The MC(Management Complex) exports the DPDMAI(Data Path DMA Interface)
object as an interface to operate the DPAA2(Data Path Acceleration
Architecture 2) qDMA Engine. The DPDMAI enables sending frame-based
requests to qDMA and receiving back confirmation response on transaction
completion, utilizing the DPAA2 QBMan(Queue Manager and Buffer Manager
hardware) infrastructure. DPDMAI object provides up to two priorities for
processing qDMA requests.
The following list summarizes the DPDMAI main features and capabilities:
1. Supports up to two scheduling priorities for processing
service requests.
- Each DPDMAI transmit queue is mapped to one of two service
priorities, allowing further prioritization in hardware between
requests from different DPDMAI objects.
2. Supports up to two receive queues for incoming transaction
completion confirmations.
- Each DPDMAI receive queue is mapped to one of two receive
priorities, allowing further prioritization between other
interfaces when associating the DPDMAI receive queues to DPIO
or DPCON(Data Path Concentrator) objects.
3. Supports different scheduling options for processing received
packets:
- Queues can be configured either in 'parked' mode (default),
or attached to a DPIO object, or attached to DPCON object.
4. Allows interaction with one or more DPIO objects for
dequeueing/enqueueing frame descriptors(FD) and for
acquiring/releasing buffers.
5. Supports enable, disable, and reset operations.
Add dpdmai to support some platforms with dpaa2 qdma engine.
Signed-off-by: Peng Ma
---
changed for v5:
- Clean up the format.
- Delete some useless struct and macro.
- Fix spell.
- Move the description of function from header to C file.
drivers/dma/fsl-dpaa2-qdma/dpdmai.c | 366 +++
drivers/dma/fsl-dpaa2-qdma/dpdmai.h | 177 +
2 files changed, 543 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpdmai.c
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpdmai.h
diff --git a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
new file mode 100644
index 000..fbc2b2f
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2019 NXP
+
+#include
+#include
+#include
+#include "dpdmai.h"
+
+struct dpdmai_rsp_get_attributes {
+ __le32 id;
+ u8 num_of_priorities;
+ u8 pad0[3];
+ __le16 major;
+ __le16 minor;
+};
+
+struct dpdmai_cmd_queue {
+ __le32 dest_id;
+ u8 priority;
+ u8 queue;
+ u8 dest_type;
+ u8 pad;
+ __le64 user_ctx;
+ union {
+ __le32 options;
+ __le32 fqid;
+ };
+};
+
+struct dpdmai_rsp_get_tx_queue {
+ __le64 pad;
+ __le32 fqid;
+};
+
+#define MC_CMD_OP(_cmd, _param, _offset, _width, _type, _arg) \
+ ((_cmd).params[_param] |= mc_enc((_offset), (_width), _arg))
+
+/* cmd, param, offset, width, type, arg_name */
+#define DPDMAI_CMD_CREATE(_cmd, _cfg) \
+do { \
+ typeof(_cmd) (cmd) = (_cmd); \
+ typeof(_cfg) (cfg) = (_cfg); \
+ MC_CMD_OP(cmd, 0, 8, 8, u8, (cfg)->priorities[0]);\
+ MC_CMD_OP(cmd, 0, 16, 8, u8, (cfg)->priorities[1]);\
+} while (0)
+
+static inline u64 mc_enc(int lsoffset, int width, u64 val)
+{
+ return (val & MAKE_UMASK64(width)) << lsoffset;
+}
+
+/**
+ * dpdmai_open() - Open a control session for the specified object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpdmai_id: DPDMAI unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpdmai_create() function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpdmai_open(struct fsl_mc_io *mc_io, u32 cmd_flags,
+ int dpdmai_id, u16 *token)
+{
+ struct fsl_mc_command cmd = { 0 };
+ __le64 *cmd_dpdmai_id;
+ int err;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPDMAI_CMDID_OPEN,
+ cmd_flags, 0);
+
+ cmd_dpdmai_id = cmd.params;
+ *cmd_dpdmai_id = cpu_to_le32(dpdmai_id);
+
+ /* send command to mc*/
+ err = mc_send_command(mc_io, );
+ if (err)
+ return err;
+
+ /* retrieve response parameters */
+ *token = mc_cmd_hdr_read_token();
+
+ return 0;
+}
+
+/**
+ *
[V5 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs
DPPA2(Data Path Acceleration Architecture 2) qDMA supports
virtualized channel by allowing DMA jobs to be enqueued into
different work queues. Core can initiate a DMA transaction by
preparing a frame descriptor(FD) for each DMA job and enqueuing
this job through a hardware portal. DPAA2 components can also
prepare a FD and enqueue a DMA job through a hardware portal.
The qDMA prefetches DMA jobs through DPAA2 hardware portal. It
then schedules and dispatches to internal DMA hardware engines,
which generate read and write requests. Both qDMA source data and
destination data can be either contiguous or non-contiguous using
one or more scatter/gather tables.
The qDMA supports global bandwidth flow control where all DMA
transactions are stalled if the bandwidth threshold has been reached.
Also supported are transaction based read throttling.
Add NXP dppa2 qDMA to support some of Layerscape SoCs.
such as: LS1088A, LS208xA, LX2, etc.
Signed-off-by: Peng Ma
---
changed for v5:
- Clean up the format and code.
- Update comments.
- Add error logs.
drivers/dma/Kconfig |2 +
drivers/dma/Makefile|1 +
drivers/dma/fsl-dpaa2-qdma/Kconfig |9 +
drivers/dma/fsl-dpaa2-qdma/Makefile |3 +
drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 825 +++
drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.h | 153 ++
6 files changed, 993 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/fsl-dpaa2-qdma/Kconfig
create mode 100644 drivers/dma/fsl-dpaa2-qdma/Makefile
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 76859aa..e4dd9c6 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -673,6 +673,8 @@ source "drivers/dma/sh/Kconfig"
source "drivers/dma/ti/Kconfig"
+source "drivers/dma/fsl-dpaa2-qdma/Kconfig"
+
# clients
comment "DMA Clients"
depends on DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5bddf6f..15a318d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_UNIPHIER_MDMAC) += uniphier-mdmac.o
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-y += mediatek/
obj-y += qcom/
diff --git a/drivers/dma/fsl-dpaa2-qdma/Kconfig
b/drivers/dma/fsl-dpaa2-qdma/Kconfig
new file mode 100644
index 000..258ed6b
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/Kconfig
@@ -0,0 +1,9 @@
+menuconfig FSL_DPAA2_QDMA
+ tristate "NXP DPAA2 QDMA"
+ depends on ARM64
+ depends on FSL_MC_BUS && FSL_MC_DPIO
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ NXP Data Path Acceleration Architecture 2 QDMA driver,
+ using the NXP MC bus driver.
diff --git a/drivers/dma/fsl-dpaa2-qdma/Makefile
b/drivers/dma/fsl-dpaa2-qdma/Makefile
new file mode 100644
index 000..c1d0226
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+# Makefile for the NXP DPAA2 qDMA controllers
+obj-$(CONFIG_FSL_DPAA2_QDMA) += dpaa2-qdma.o dpdmai.o
diff --git a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
new file mode 100644
index 000..c70a796
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
@@ -0,0 +1,825 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2019 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../virt-dma.h"
+#include "dpdmai.h"
+#include "dpaa2-qdma.h"
+
+static bool smmu_disable = true;
+
+static struct dpaa2_qdma_chan *to_dpaa2_qdma_chan(struct dma_chan *chan)
+{
+ return container_of(chan, struct dpaa2_qdma_chan, vchan.chan);
+}
+
+static struct dpaa2_qdma_comp *to_fsl_qdma_comp(struct virt_dma_desc *vd)
+{
+ return container_of(vd, struct dpaa2_qdma_comp, vdesc);
+}
+
+static int dpaa2_qdma_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct dpaa2_qdma_chan *dpaa2_chan = to_dpaa2_qdma_chan(chan);
+ struct dpaa2_qdma_engine *dpaa2_qdma = dpaa2_chan->qdma;
+ struct device *dev = _qdma->priv->dpdmai_dev->dev;
+
+ dpaa2_chan->fd_pool = dma_pool_create("fd_pool", dev,
+ sizeof(struct dpaa2_fd),
+ sizeof(struct dpaa2_fd), 0);
+ if (!dpaa2_chan->fd_pool)
+ goto err;
+
+ dpaa2_chan->fl_pool = dma_pool_create("fl_pool", dev,
+ sizeof(struct dpaa2_fl_entry),
+ sizeof(struct dpaa2_fl_entry), 0);
+ if (!dpaa2_chan->fl_pool)
+ goto err_fd;
+
+ dpaa2_chan->sdd_pool =
+ dma_pool_create("sdd_pool", dev,
+
[PATCH v10 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
We unconditionally set the HW_AFDBM capability and only enable it on
CPUs which really have the feature. But sometimes we need to know
whether this cpu has the capability of HW AF. So decouple AF from
DBM by new helper cpu_has_hw_af().
Signed-off-by: Jia He
Suggested-by: Suzuki Poulose
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/cpufeature.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 9cde5d2e768f..949bc7c85030 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -659,6 +659,16 @@ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int
parange)
default: return CONFIG_ARM64_PA_BITS;
}
}
+
+/* Check whether hardware update of the Access flag is supported */
+static inline bool cpu_has_hw_af(void)
+{
+ if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
+ return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
+
+ return false;
+}
+
#endif /* __ASSEMBLY__ */
#endif
--
2.17.1
[PATCH v10 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/pgtable.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7576df00eb50..e96fb82f62de 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -885,6 +885,20 @@ static inline void update_mmu_cache(struct vm_area_struct
*vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying from user will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. We don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ WARN_ON(preemptible());
+
+ return !cpu_has_hw_af();
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.1
[PATCH v10 0/3] fix double page fault on arm64
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there will be a double page fault in __copy_from_user_inatomic of cow_user_page. As told by Catalin: "On arm64 without hardware Access Flag, copying from user will fail because the pte is old and cannot be marked young. So we always end up with zeroed page after fork() + CoW for pfn mappings. we don't always have a hardware-managed access flag on arm64." Changes v10: add r-b from Catalin and a-b from Kirill in PATCH 03 remoe Reported-by in PATCH 01 v9: refactor cow_user_page for indention optimization (Catalin) hold the ptl longer (Catalin) v8: change cow_user_page's return type (Matthew) v7: s/pte_spinlock/pte_offset_map_lock (Kirill) v6: fix error case of returning with spinlock taken (Catalin) move kmap_atomic to avoid handling kunmap_atomic v5: handle the case correctly when !pte_same fix kbuild test failed v4: introduce cpu_has_hw_af (Suzuki) bail out if !pte_same (Kirill) v3: add vmf->ptl lock/unlock (Kirill A. Shutemov) add arch_faults_on_old_pte (Matthew, Catalin) v2: remove FAULT_FLAG_WRITE when setting pte access flag (Catalin) Jia He (3): arm64: cpufeature: introduce helper cpu_has_hw_af() arm64: mm: implement arch_faults_on_old_pte() on arm64 mm: fix double page fault on arm64 if PTE_AF is cleared arch/arm64/include/asm/cpufeature.h | 10 +++ arch/arm64/include/asm/pgtable.h| 14 mm/memory.c | 99 - 3 files changed, 108 insertions(+), 15 deletions(-) -- 2.17.1
[PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[9b007000] pgd=00023d4f8003, pud=00023da9b003,
pmd=00023d4b3003, pte=36298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
in case there can be some obscure use-case.(by Kirill)
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Signed-off-by: Jia He
Reported-by: Yibo Cai
Reviewed-by: Catalin Marinas
Acked-by: Kirill A. Shutemov
---
mm/memory.c | 99 +
1 file changed, 84 insertions(+), 15 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index b1ca51a079f2..1f56b0118ef5 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2145,32 +2152,82 @@ static inline int pte_unmap_same(struct mm_struct *mm,
pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned
long va, struct vm_area_struct *vma)
+static inline bool cow_user_page(struct page *dst, struct page *src,
+struct vm_fault *vmf)
{
+ bool ret;
+ void *kaddr;
+ void __user *uaddr;
+ bool force_mkyoung;
+ struct vm_area_struct *vma = vmf->vma;
+ struct mm_struct *mm = vma->vm_mm;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
+ if (likely(src)) {
+ copy_user_highpage(dst, src, addr, vma);
+ return true;
+ }
+
/*
* If the source page was a PFN mapping, we don't have
* a "struct page" for it. We do a best-effort copy by
* just copying from the original user address. If that
* fails, we just zero-fill it. Live with it.
*/
- if (unlikely(!src)) {
- void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ kaddr = kmap_atomic(dst);
+ uaddr = (void __user *)(addr & PAGE_MASK);
+
+ /*
+* On architectures with software "accessed" bits, we would
+* take a double page fault, so mark it accessed here.
+*/
+ force_mkyoung = arch_faults_on_old_pte() && !pte_young(vmf->orig_pte);
+ if (force_mkyoung) {
+ pte_t entry;
+
+ vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, >ptl);
+ if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ /*
+* Other thread has already handled the fault
+* and we don't need to do anything. If it's
+* not the case, the fault will be triggered
+* again on the same address.
+*/
+ ret = false;
+ goto pte_unlock;
+ }
+
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr, vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ }
+ /*
+* This really shouldn't fail, because the page is there
+* in the page tables. But it might just be unreadable,
+* in which case we just give up and fill the result with
+* zeroes.
+*/
+ if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
/*
-* This really shouldn't fail, because the page is there
-* in the page tables. But it might just be unreadable,
-* in which case we just give up and fill the result with
-* zeroes.
+* Give a warn in case there
Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()
On 2019/09/30 9:28, Sasha Levin wrote:
> On Sun, Sep 29, 2019 at 11:43:38PM +0900, Tetsuo Handa wrote:
>> On 2019/09/29 22:54, Greg Kroah-Hartman wrote:
>>> From: Waiman Long
>>>
>>> [ Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf ]
>>>
>>> Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
>>> warning right after a previous lockdep warning. It is likely that the
>>> previous warning turned off lock debugging causing the lockdep to have
>>> inconsistency states leading to the lock downgrade warning.
>>>
>>> Fix that by add a check for debug_locks at the beginning of
>>> __lock_downgrade().
>>
>> Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in
>> __lock_downgrade()".
>> We had a revert patch shown below in the past.
>
> We had a revert in the stable trees, but that revert was incorrect.
>
> Take a look at commit 513e1073d52e55 upstream, it patches
> __lock_set_class() (even though the subject line says
> __lock_downgrade()). So this is not a backporting error as the revert
> said it is, but is rather the intended location to be patched.
>
> If this is actually wrong, then it should be addressed upstream first.
>
Hmm, upstream has two commits with same author, same date, same subject,
different hash, different content.
I couldn't find from
https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com
that
we want to patch both __lock_set_class() and __lock_downgrade(), but I found
that the tip-bot has patched
__lock_downgrade() on "2019-01-21 11:29" and __lock_set_class() on "2019-02-04
8:56".
Seems that we by error patched both functions, though patching both functions
should be harmless...
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4115) static int
00ef9f734 kernel/lockdep.c (Peter Zijlstra2008-12-04
09:00:17 +0100 4116) __lock_set_class(struct lockdep_map *lock, const char
*name,
00ef9f734 kernel/lockdep.c (Peter Zijlstra2008-12-04
09:00:17 +0100 4117)struct lock_class_key *key, unsigned int
subclass,
00ef9f734 kernel/lockdep.c (Peter Zijlstra2008-12-04
09:00:17 +0100 4118)unsigned long ip)
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4119) {
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4120) struct task_struct *curr = current;
8c8889d8e kernel/locking/lockdep.c (Imre Deak 2019-05-24
23:15:08 +0300 4121) unsigned int depth, merged = 0;
41c2c5b86 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:15 +0900 4122) struct held_lock *hlock;
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4123) struct lock_class *class;
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4124) int i;
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4125)
513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4126) if (unlikely(!debug_locks))
513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4127) return 0;
513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4128)
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4162) static int __lock_downgrade(struct lockdep_map *lock,
unsigned long ip)
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4163) {
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4164) struct task_struct *curr = current;
8c8889d8e kernel/locking/lockdep.c (Imre Deak 2019-05-24
23:15:08 +0300 4165) unsigned int depth, merged = 0;
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4166) struct held_lock *hlock;
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4167) int i;
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4168)
714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4169) if (unlikely(!debug_locks))
714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4170) return 0;
714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4171)
commit 513e1073d52e55b8024b4f238a48de7587c64ccf
Author: Waiman Long
Date: Wed Jan 9 23:03:25 2019 -0500
locking/lockdep: Add debug_locks check in __lock_downgrade()
commit 71492580571467fb7177aade19c18ce7486267f5
Author: Waiman Long
Date: Wed Jan 9 23:03:25 2019 -0500
locking/lockdep: Add debug_locks check in __lock_downgrade()
Re: [PATCH v3] patman: Use the Change-Id, version, and prefix in the Message-Id
On Fri, 27 Sep 2019 at 10:25, Douglas Anderson wrote: > > As per the centithread on ksummit-discuss [1], there are folks who > feel that if a Change-Id is present in a developer's local commit that > said Change-Id could be interesting to include in upstream posts. > Specifically if two commits are posted with the same Change-Id there's > a reasonable chance that they are either the same commit or a newer > version of the same commit. Specifically this is because that's how > gerrit has trained people to work. > > There is much angst about Change-Id in upstream Linux, but one thing > that seems safe and non-controversial is to include the Change-Id as > part of the string of crud that makes up a Message-Id. > > Let's give that a try. > > In theory (if there is enough adoption) this could help a tool more > reliably find various versions of a commit. This actually might work > pretty well for U-Boot where (I believe) quite a number of developers > use patman, so there could be critical mass (assuming that enough of > these people also use a git hook that adds Change-Id to their > commits). I was able to find this git hook by searching for "gerrit > change id git hook" in my favorite search engine. > > In theory one could imagine something like this could be integrated > into other tools, possibly even git-send-email. Getting it into > patman seems like a sane first step, though. > > NOTE: this patch is being posted using a patman containing this patch, > so you should be able to see the Message-Id of this patch and see that > it contains my local Change-Id, which ends in 2b9 if you want to > check. > > [1] > https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html > > Signed-off-by: Douglas Anderson > --- > > Changes in v3: > - Allow faking the time of Message-Id for testing (testBasic) > - Add skip_blank for Change-Id (testBasic). > - Check the Message-Id in testBasic. Applied to u-boot-dm/next, thanks! > > Changes in v2: > - Add a "v" before the version part of the Message-Id > - Reorder the parts of the Message-Id as per Johannes. > > tools/patman/README | 8 - > tools/patman/commit.py | 3 ++ > tools/patman/patchstream.py | 64 +++-- > tools/patman/test.py| 15 +++-- > 4 files changed, 85 insertions(+), 5 deletions(-)
Re: x86/random: Speculation to the rescue
On Sat, Sep 28, 2019 at 4:53 PM Linus Torvalds wrote: > > But hey, here's a made-up patch. It basically does jitter entropy, but > it uses a more complex load than the fibonacci LFSR folding: it calls > "schedule()" in a loop, and it sets up a timer to fire. Ok, I'm sure a lot of people will end up finding this distasteful, and I'll admit to just waffling about it myself. But I am supposed to close the merge window today, and honestly, I want _something_ to happen about the getrandom() issue during the 5.4 merge cycle. So I had a few choices - just ignore things and hope some consensus happens - start the movement to a new getrandom() interface and encourage user space to say "yeah, I don't need _secure_ random numbers" - or just say "hey, a lot of people find jitter entropy reasonable, so let's just try this". And I went with that last choice. If it works, it makes the getrandom() interface changes a non-issue. I'm not saying my patch is going to be the last word on the issue. I'm _personally_ ok with it and believe it's not crazy, and if it then makes serious people go "Eww" and send some improvements to it, then it has served its purpose. But I've committed that patch and the revert of the ext4 revert to a local branch, I'll do some basic testing of it (which honestly on my machines are kind of pointless, since all of them support rdrand), but assuming it passes the basic smoke tests - and I expect it to - I'll merge it for rc1. I also have my old readdir branch that I decided I want to merge due to the (completely independent) discussion about filldir issues, so I'll probably end up delaying rc1 until tomorrow, but just a heads up. I don't want to leave this until "some time later in the -rc series", although I will be _more_ than happy to have people send me fixes to my somewhat simplistic patch. That said, my patch may be simplistic, but I suspect using a loop with a real load like schedule() and arming a timer is a lot more realistic than some of the jitter entropy papers with their _very_ trivial LFSR's and some made-up pointer chasing. But yeah, I think improvements to it are also not unexpected or unreasonable ;) Linus
Re: [PATCH v3 04/10] sched/fair: rework load_balance
On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote: > > Also the load balance decisions have been consolidated in the 3 > functions > below after removing the few bypasses and hacks of the current code: > - update_sd_pick_busiest() select the busiest sched_group. > - find_busiest_group() checks if there is an imbalance between local > and > busiest group. > - calculate_imbalance() decides what have to be moved. I really like the direction this series is going. However, I suppose I should run these patches for a few days with some of our test workloads before I send out an ack for this patch :) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
[PATCH] acpi: Mute gcc warning
When build with "EXTRA_CFLAGS=-Wall" gcc warns:
arch/x86/boot/compressed/acpi.c:29:30: warning: get_cmdline_acpi_rsdp defined
but not used [-Wunused-function]
Fixes: 41fa1ee9c6d6 ("acpi: Ignore acpi_rsdp kernel param when the kernel has
been locked down")
Signed-off-by: Zhenzhong Duan
Cc: Josh Boyer
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: "H. Peter Anvin"
Cc: Chao Fan
---
arch/x86/boot/compressed/acpi.c | 48 -
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index 149795c..25019d4 100644
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -21,30 +21,6 @@
struct mem_vector immovable_mem[MAX_NUMNODES*2];
/*
- * Max length of 64-bit hex address string is 19, prefix "0x" + 16 hex
- * digits, and '\0' for termination.
- */
-#define MAX_ADDR_LEN 19
-
-static acpi_physical_address get_cmdline_acpi_rsdp(void)
-{
- acpi_physical_address addr = 0;
-
-#ifdef CONFIG_KEXEC
- char val[MAX_ADDR_LEN] = { };
- int ret;
-
- ret = cmdline_find_option("acpi_rsdp", val, MAX_ADDR_LEN);
- if (ret < 0)
- return 0;
-
- if (kstrtoull(val, 16, ))
- return 0;
-#endif
- return addr;
-}
-
-/*
* Search EFI system tables for RSDP. If both ACPI_20_TABLE_GUID and
* ACPI_TABLE_GUID are found, take the former, which has more features.
*/
@@ -298,6 +274,30 @@ acpi_physical_address get_rsdp_addr(void)
}
#if defined(CONFIG_RANDOMIZE_BASE) && defined(CONFIG_MEMORY_HOTREMOVE)
+/*
+ * Max length of 64-bit hex address string is 19, prefix "0x" + 16 hex
+ * digits, and '\0' for termination.
+ */
+#define MAX_ADDR_LEN 19
+
+static acpi_physical_address get_cmdline_acpi_rsdp(void)
+{
+ acpi_physical_address addr = 0;
+
+#ifdef CONFIG_KEXEC
+ char val[MAX_ADDR_LEN] = { };
+ int ret;
+
+ ret = cmdline_find_option("acpi_rsdp", val, MAX_ADDR_LEN);
+ if (ret < 0)
+ return 0;
+
+ if (kstrtoull(val, 16, ))
+ return 0;
+#endif
+ return addr;
+}
+
/* Compute SRAT address from RSDP. */
static unsigned long get_acpi_srat_table(void)
{
--
1.8.3.1
Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()
On Sun, Sep 29, 2019 at 11:43:38PM +0900, Tetsuo Handa wrote: On 2019/09/29 22:54, Greg Kroah-Hartman wrote: From: Waiman Long [ Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf ] Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning. Fix that by add a check for debug_locks at the beginning of __lock_downgrade(). Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()". We had a revert patch shown below in the past. We had a revert in the stable trees, but that revert was incorrect. Take a look at commit 513e1073d52e55 upstream, it patches __lock_set_class() (even though the subject line says __lock_downgrade()). So this is not a backporting error as the revert said it is, but is rather the intended location to be patched. If this is actually wrong, then it should be addressed upstream first. -- Thanks, Sasha
Re: [PATCH 2/4] rsicv: avoid sending a SIGTRAP to a user thread trapped in WARN()
On Sat, Sep 28, 2019 at 6:56 AM Christoph Hellwig wrote: > > Oh and s/rsicv/riscv/ in the subject, please. Oh! Thank you for finding this typo. I will correct it.
linux-next: build failure after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
arch/powerpc/mm/book3s64/pgtable.c: In function 'flush_partition':
arch/powerpc/mm/book3s64/pgtable.c:216:3: error: implicit declaration of
function 'radix__flush_all_lpid_guest'; did you mean 'radix__flush_all_lpid'?
[-Werror=implicit-function-declaration]
216 | radix__flush_all_lpid_guest(lpid);
| ^~~
| radix__flush_all_lpid
Caused by commit
99161de3a283 ("powerpc/64s/radix: tidy up TLB flushing code")
radix__flush_all_lpid_guest() is only declared for CONFIG_PPC_RADIX_MMU
which is not set for this build.
I am not sure why this did not show up earlier (maybe a Kconfig
change?).
I added the following hack for today.
From: Stephen Rothwell
Date: Mon, 30 Sep 2019 10:09:17 +1000
Subject: [PATCH] powerpc/64s/radix: fix for "tidy up TLB flushing code" and
!CONFIG_PPC_RADIX_MMU
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/book3s/64/tlbflush-radix.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 4ce795d30377..ca8db193ae38 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -35,6 +35,10 @@ static inline void radix__flush_all_lpid(unsigned int lpid)
{
WARN_ON(1);
}
+static inline void radix__flush_all_lpid_guest(unsigned int lpid)
+{
+ WARN_ON(1);
+}
#endif
extern void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
--
2.23.0.rc1
--
Cheers,
Stephen Rothwell
pgpGH1YpIi9UZ.pgp
Description: OpenPGP digital signature
Re: [GIT PULL][SECURITY] Kernel lockdown patches for v5.4
On Sat, 28 Sep 2019, Linus Torvalds wrote: > On Fri, Sep 27, 2019 at 11:19 AM Linus Torvalds > wrote: > > > > This is one of the pull requests that I have to go through commit by > > commit because of the history of this thing. > > > > And I've yet to empty my queue of all the _regular_ things that came > > in this merge window, so I haven't had time. > > I've emptied my queue (well, in the meantime I got new pull requests, > but what else is new..) and went through the security pulls yesterday > and this morning, and found nothing objectionable. > > So it's merged now. Thanks. Matthew has agreed to maintain this code now that it's merged. Matthew: please submit a maintainer entry for this. -- James Morris
Re: [PATCH] arm64: dts: rockchip: Fix usb-c on Hugsun X99 TV Box
On Sun, Sep 29, 2019 at 01:22:17PM +0200, Vicente Bergas wrote:
> On Sunday, September 29, 2019 5:22:30 AM CEST, Vivek Unune wrote:
> > Fix usb-c on X99 TV Box. Tested with armbian w/ kernel 5.3
> >
> > Signed-off-by: Vivek Unune
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > index 0d1f5f9a0de9..c133e8d64b2a 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > @@ -644,7 +644,7 @@
> > status = "okay";
> > u2phy0_host: host-port {
> > - phy-supply = <_host>;
> > + phy-supply = <_typec>;
> > status = "okay";
> > };
> > @@ -712,7 +712,7 @@
> > _dwc3_0 {
> > status = "okay";
> > - dr_mode = "otg";
> > + dr_mode = "host";
> > };
> > _1 {
>
> Hi Vivek,
>
> which is the relationship of your patch and this commit:
>
> e1d9149e8389f1690cdd4e4056766dd26488a0fe
> arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire
>
> with respect to this other commit:
>
> c09b73cfac2a9317f1104169045c519c6021aa1d
> usb: dwc3: don't set gadget->is_otg flag
>
> ?
>
> I did not test reverting e1d9149e since c09b73cf was applied.
>
> Regards,
> Vicenç.
>
Hi Vicenç,
Indeed, I was motivated by e1d9149e ("arm64: dts: rockchip: Fix USB3
Type-C on rk3399-sapphire"). X99 TV box showed exact same symptoms
with usb-c port. After applying the fix, it worked.
I was not aware of c09b73cf ("usb: dwc3: don't set gadget->is_otg
flag") and it will be interesting to test it. This might render
my fix unecessary.
Thanks,
Vivek
hello
Hello My name is Joe Akaba I am a lawyer by profession. I wish to offer you the next of kin to my client. You will inherit the sum of ($8.5 Million) dollars my client left in the bank before his death. My client is a citizen of your country who died in auto crash with his wife and only son. I will be entitled with 50% of the total fund while 50% will be for you. Please contact my private email here for more details:joeakab...@gmail.com Many thanks in advance, Mr.Joe Akaba Hallo Mein Name ist Joe Akaba . Ich bin von Beruf Rechtsanwalt. Ich möchte Ihnen anbieten die nächsten Verwandten zu meinem Klienten. Sie erben die Summe von ($8.5 Millionen US-Dollar) Dollar, die mein Kunde vor seinem Tod in der Bank gelassen hat. Mein Mandant ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und nur Sohn. Ich werde mit 50% des Gesamtfonds berechtigt sein, während 50% sein für dich. Bitte kontaktieren Sie meine private E-Mail hier für weitere Informationen: joeakab...@gmail.com Vielen Dank im Voraus, Mr.Joe Akaba
Re: [PATCH 1/1] media: dvbsky: use a single mutex and state buffers for all R/W ops
This works very well for me.
(and please see unrelated comment below)
On 9/29/19 10:04 AM, Andrei Koshkosh wrote:
Signed-off-by: Andrei Koshkosh
---
drivers/media/usb/dvb-usb-v2/dvbsky.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index c41e10b..6a118a0 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -22,7 +22,6 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR receiver.");
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
struct dvbsky_state {
- struct mutex stream_mutex;
u8 ibuf[DVBSKY_BUF_LEN];
u8 obuf[DVBSKY_BUF_LEN];
u8 last_lock;
@@ -61,16 +60,18 @@ static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8
onoff)
{
struct dvbsky_state *state = d_to_priv(d);
int ret;
- u8 obuf_pre[3] = { 0x37, 0, 0 };
- u8 obuf_post[3] = { 0x36, 3, 0 };
+ static u8 obuf_pre[3] = { 0x37, 0, 0 };
+ static u8 obuf_post[3] = { 0x36, 3, 0 };
- mutex_lock(>stream_mutex);
- ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0);
+ mutex_lock(>usb_mutex);
+ memcpy(state->obuf, obuf_pre, 3);
+ ret = dvb_usbv2_generic_write_locked(d, state->obuf, 3);
if (!ret && onoff) {
msleep(20);
- ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0);
+ memcpy(state->obuf, obuf_post, 3);
+ ret = dvb_usbv2_generic_write_locked(d, state->obuf, 3);
}
- mutex_unlock(>stream_mutex);
+ mutex_unlock(>usb_mutex);
return ret;
}
@@ -599,7 +600,6 @@ static int dvbsky_init(struct dvb_usb_device *d)
if (ret)
return ret;
*/
commented-out code has call to non-existing function.
- mutex_init(>stream_mutex);
state->last_lock = 0;
Thanks,
Jan Pieter.
Re: [PATCH] dt-bindings: arm: rockchip: fix Theobroma-System board bindings
Am Dienstag, 17. September 2019, 10:34:53 CEST schrieb Heiko Stuebner: > The naming convention for the existing Theobroma boards is > soc-q7module-baseboard, so rk3399-puma-haikou and the in-kernel > devicetrees also follow that scheme. > > For some reason in the binding a wrong or outdated naming slipped > in which does not match the used devicetrees and makes the dt-schema > complain now. > > Fix this by using the names used in the wild by actual boards. > > Signed-off-by: Heiko Stuebner added a Fixes tag and applies as fix for 5.4
Re: [PATCH 4/6] arm64: dts: rockchip: Rename roc-pc with libretech notation
Hi Jagan,
Am Donnerstag, 19. September 2019, 07:28:20 CEST schrieb Jagan Teki:
> Though the ROC-PC is manufactured by firefly, it is co-designed
> by libretch like other Libretech computer boards from allwinner,
> amlogic does.
>
> So, it is always meaningful to keep maintain those vendors who
> are part of design participation so-that the linux mainline
> code will expose outside world who are the makers of such
> hardware prototypes.
>
> So, rename the existing rk3399-roc-pc.dts with libretch notation,
> rk3399-libretech-roc-rk3399-pc.dts
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 2 +-
> .../{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} | 0
Somewhat "randomly" renaming files for "exposure" of the maker isn't the
way to go. Especially as the file name itself is merely a handle and not
meant for fame. The board filename should mainly enable developers to
hopefully the correct board file to use/change - and "rk3399-roc-pc"
is sufficiently unique to do that.
Similar to how the NanoPi boards do that.
And renames not only loose the history of changes but also in this case
the file is in the kernel since july 2018 - more than a year, so this might
actually affect the workflow of someone.
So I'd really expect an actual technical reason for a rename.
Heiko
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts =>
> rk3399-libretech-roc-rk3399-pc.dts} (100%)
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index 1f18a9392d15..73c10ddb4300 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -21,12 +21,12 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-libretech-roc-rk3399-pc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
> -dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
> similarity index 100%
> rename from arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> rename to arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
>
Re: [PATCH 1/6] arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
Hi Jagan,
Am Donnerstag, 19. September 2019, 07:28:17 CEST schrieb Jagan Teki:
> ROC-PC is not able to boot linux console if PWM2_d is
> unattached to any pinctrl logic.
>
> To be precise the linux boot hang with last logs as,
> ...
> .
> [0.003367] Console: colour dummy device 80x25
> [0.003788] printk: console [tty0] enabled
> [0.004178] printk: bootconsole [uart8250] disabled
>
> In ROC-PC the PWM2_d pin is connected to LOG_DVS_PWM of
> VDD_LOG. So, for normal working operations this needs to
> active and pull-down.
>
> This patch fix, by attaching pinctrl active and pull-down
> the pwm2.
This looks highly dubious on first glance. The pwm subsystem nor
the Rockchip pwm driver do not do any pinctrl handling.
So I don't really see where that "active" pinctrl state is supposed
to come from.
Comparing with the pwm driver in the vendor tree I see that there
is such a state defined there. But that code there also looks strange
as that driver never again leaves this active state after entering it.
Also for example all the Gru devices run with quite a number of pwm-
regulators without needing additional fiddling with the pwm itself, so
I don't really see why that should be different here.
Heiko
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> index 19f7732d728c..c53f3d571620 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> @@ -548,6 +548,8 @@
> };
>
> {
> + pinctrl-names = "active";
> + pinctrl-0 = <_pin_pull_down>;
> status = "okay";
> };
>
>
Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
On 2019-09-29 12:36, Biwen Li wrote:
> On some Layerscape boards like LS2085ARDB and LS2088ARDB,
> input pull-up resistors on PCA954x MUX device are missing on board,
> So, if MUX are disabled after powered-on, input lines will float
> leading to incorrect functionality.
Hi!
Are you saying that the parent bus of the mux is relying on some
pull-ups inside the mux?
> Hence, PCA954x MUX device should never be turned-off after
> power-on.
>
> Add property to skip disabling PCA954x MUX device
> if device tree contains "i2c-mux-never-disable"
> for PCA954x device node.
>
> Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB
> (Board revision found on Rev.B, Rev.C and Rev.D)
I think you should follow the example of the i2c-mux-gpio driver
and implement the idle-state property instead.
That is a lot more consistent, assuming it solves the problem
at hand?
>
> Signed-off-by: Biwen Li
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.c | 33 +
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index 923aa3a5a3dc..ea8aca54d572 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -93,6 +93,7 @@ struct pca954x {
> struct irq_domain *irq;
> unsigned int irq_mask;
> raw_spinlock_t lock;
> + u8 disable_mux; /* do not disable mux if val not 0 */
Awful number of negations there. The name is also backwards given that
a non-zero value means that the mux should *not* be disabled. I would
have reused the name from the binding.
bool never_disable;
A bit less confusing...
> };
>
> /* Provide specs for the PCA954x types we know about */
> @@ -258,6 +259,11 @@ static int pca954x_deselect_mux(struct i2c_mux_core
> *muxc, u32 chan)
> struct i2c_client *client = data->client;
> s8 idle_state;
>
> + if (data->disable_mux != 0) {
Please drop " != 0" and use the variable as a truth value. More
instances below...
> + data->last_chan = data->chip->nchans;
> + return pca954x_reg_write(muxc->parent, client,
> data->disable_mux);
> + }
> +
> idle_state = READ_ONCE(data->idle_state);
> if (idle_state >= 0)
> /* Set the mux back to a predetermined channel */
> @@ -462,16 +468,32 @@ static int pca954x_probe(struct i2c_client *client,
> }
> }
>
> + /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
> + * The point here is that you must not disable a mux if there
> + * are no pullups on the input or you mess up the I2C. This
> + * needs to be put into the DTS really as the kernel cannot
> + * know this otherwise.
> + */
> +
> + data->disable_mux = np &&
> + of_property_read_bool(np, "i2c-mux-never-disable") &&
i2c-mux-never-disable needs to be documented. However see above for my
point that you should do it like the i2c-mux-gpio driver. Any usage
of idle-state still needs to be documented for pca954x binding.
> + data->chip->muxtype == pca954x_ismux ?
> + data->chip->enable : 0;
Why do you not allow never-disable for switches?
Cheers,
Peter
> +
> /* Write the mux register at addr to verify
>* that the mux is in fact present. This also
>* initializes the mux to disconnected state.
>*/
> - if (i2c_smbus_write_byte(client, 0) < 0) {
> + if (i2c_smbus_write_byte(client, data->disable_mux) < 0) {
> dev_warn(dev, "probe failed\n");
> return -ENODEV;
> }
>
> - data->last_chan = 0; /* force the first selection */
> + if (data->disable_mux != 0)
> + data->last_chan = data->chip->nchans;
> + else
> + data->last_chan = 0; /* force the first selection
> */
> +
> data->idle_state = MUX_IDLE_AS_IS;
>
> idle_disconnect_dt = np &&
> @@ -531,8 +553,11 @@ static int pca954x_resume(struct device *dev)
> struct i2c_mux_core *muxc = i2c_get_clientdata(client);
> struct pca954x *data = i2c_mux_priv(muxc);
>
> - data->last_chan = 0;
> - return i2c_smbus_write_byte(client, 0);
> + if (data->disable_mux != 0)
> + data->last_chan = data->chip->nchans;
> + else
> + data->last_chan = 0;
> + return i2c_smbus_write_byte(client, data->disable_mux);
> }
> #endif
>
>
Re: linux-next: no release today
Hi Mark, On Mon, 16 Sep 2019 02:37:27 +0100 Mark Brown wrote: > > On Thu, Sep 05, 2019 at 04:02:37PM +1000, Stephen Rothwell wrote: > > > As I said yesterday, there will be no release today, or any day until > > September 30. > > I'm going to try to provide some builds for this week (16th-20th). > There may also be a build for the 15th depending on how much rebuilding > the rest of the trees is needed for the build I've got ongoing. I just want to say a big thank you for taking this on again. -- Cheers, Stephen Rothwell pgpKEXZ6_MbGs.pgp Description: OpenPGP digital signature
Re: [PATCH v2] perf tools: avoid sample_reg_masks being const + weak
On Fri, Sep 27, 2019 at 02:43:41PM -0700, Ian Rogers wrote:
> Being const + weak breaks with some compilers that constant-propagate
> from the weak symbol. This behavior is outside of the specification, but
> in LLVM is chosen to match GCC's behavior.
>
> LLVM's implementation was set in this patch:
> https://github.com/llvm/llvm-project/commit/f49573d1eedcf1e44893d5a062ac1b72c8419646
> A const + weak symbol is set to be weak_odr:
> https://llvm.org/docs/LangRef.html
> ODR is one definition rule, and given there is one constant definition
> constant-propagation is possible. It is possible to get this code to
> miscompile with LLVM when applying link time optimization. As compilers
> become more aggressive, this is likely to break in more instances.
>
> Move the definition of sample_reg_masks to the conditional part of
> perf_regs.h and guard usage with HAVE_PERF_REGS_SUPPORT. This avoids the
> weak symbol.
>
> Fix an issue when HAVE_PERF_REGS_SUPPORT isn't defined from patch v1.
>
> Signed-off-by: Ian Rogers
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> tools/perf/util/parse-regs-options.c | 8 ++--
> tools/perf/util/perf_regs.c | 4
> tools/perf/util/perf_regs.h | 4 ++--
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/util/parse-regs-options.c
> b/tools/perf/util/parse-regs-options.c
> index ef46c2848808..e687497b3aac 100644
> --- a/tools/perf/util/parse-regs-options.c
> +++ b/tools/perf/util/parse-regs-options.c
> @@ -13,7 +13,7 @@ static int
> __parse_regs(const struct option *opt, const char *str, int unset, bool intr)
> {
> uint64_t *mode = (uint64_t *)opt->value;
> - const struct sample_reg *r;
> + const struct sample_reg *r = NULL;
> char *s, *os = NULL, *p;
> int ret = -1;
> uint64_t mask;
> @@ -46,19 +46,23 @@ __parse_regs(const struct option *opt, const char *str,
> int unset, bool intr)
>
> if (!strcmp(s, "?")) {
> fprintf(stderr, "available registers: ");
> +#ifdef HAVE_PERF_REGS_SUPPORT
> for (r = sample_reg_masks; r->name; r++) {
> if (r->mask & mask)
> fprintf(stderr, "%s ", r->name);
> }
> +#endif
> fputc('\n', stderr);
> /* just printing available regs */
> return -1;
> }
> +#ifdef HAVE_PERF_REGS_SUPPORT
> for (r = sample_reg_masks; r->name; r++) {
> if ((r->mask & mask) && !strcasecmp(s, r->name))
> break;
> }
> - if (!r->name) {
> +#endif
> + if (!r || !r->name) {
> ui__warning("Unknown register \"%s\", check man
> page or run \"perf record %s?\"\n",
> s, intr ? "-I" : "--user-regs=");
> goto error;
> diff --git a/tools/perf/util/perf_regs.c b/tools/perf/util/perf_regs.c
> index 2774cec1f15f..5ee47ae1509c 100644
> --- a/tools/perf/util/perf_regs.c
> +++ b/tools/perf/util/perf_regs.c
> @@ -3,10 +3,6 @@
> #include "perf_regs.h"
> #include "event.h"
>
> -const struct sample_reg __weak sample_reg_masks[] = {
> - SMPL_REG_END
> -};
> -
> int __weak arch_sdt_arg_parse_op(char *old_op __maybe_unused,
>char **new_op __maybe_unused)
> {
> diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
> index 47fe34e5f7d5..e014c2c038f4 100644
> --- a/tools/perf/util/perf_regs.h
> +++ b/tools/perf/util/perf_regs.h
> @@ -15,8 +15,6 @@ struct sample_reg {
> #define SMPL_REG2(n, b) { .name = #n, .mask = 3ULL << (b) }
> #define SMPL_REG_END { .name = NULL }
>
> -extern const struct sample_reg sample_reg_masks[];
> -
> enum {
> SDT_ARG_VALID = 0,
> SDT_ARG_SKIP,
> @@ -27,6 +25,8 @@ uint64_t arch__intr_reg_mask(void);
> uint64_t arch__user_reg_mask(void);
>
> #ifdef HAVE_PERF_REGS_SUPPORT
> +extern const struct sample_reg sample_reg_masks[];
> +
> #include
>
> #define DWARF_MINIMAL_REGS ((1ULL << PERF_REG_IP) | (1ULL << PERF_REG_SP))
> --
> 2.23.0.444.g18eeb5a265-goog
>
[GIT PULL] tracing: A few minor fix ups
Linus,
A few more tracing fixes:
- Fixed a buffer overflow by checking nr_args correctly in probes
- Fixed a warning that is reported by clang
- Fixed a possible memory leak in error path of filter processing
- Fixed the selftest that checks for failures, but wasn't failing
- Minor clean up on call site output of a memory trace event
Please pull the latest trace-v5.4-3 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v5.4-3
Tag SHA1: 6bd391b341525bebf22f3fbbaea7ffb35f7cccb6
Head SHA1: 8ed4889eb83179dbc9a105cfed65cc42ecb61097
Changbin Du (1):
mm, tracing: Print symbol name for call_site in trace events
Masami Hiramatsu (1):
tracing/probe: Fix to check the difference of nr_args before adding probe
Nathan Chancellor (1):
tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macro
Navid Emamdoost (1):
tracing: Have error path in predicate_parse() free its allocated memory
Steven Rostedt (VMware) (1):
selftests/ftrace: Fix same probe error test
include/trace/events/kmem.h | 7 ---
kernel/trace/trace.h | 10 +-
kernel/trace/trace_events_filter.c | 6 --
kernel/trace/trace_probe.c | 16
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 2 +-
5 files changed, 30 insertions(+), 11 deletions(-)
---
diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index eb57e3037deb..69e8bb8963db 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -35,8 +35,8 @@ DECLARE_EVENT_CLASS(kmem_alloc,
__entry->gfp_flags = gfp_flags;
),
- TP_printk("call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
- __entry->call_site,
+ TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
+ (void *)__entry->call_site,
__entry->ptr,
__entry->bytes_req,
__entry->bytes_alloc,
@@ -131,7 +131,8 @@ DECLARE_EVENT_CLASS(kmem_free,
__entry->ptr= ptr;
),
- TP_printk("call_site=%lx ptr=%p", __entry->call_site, __entry->ptr)
+ TP_printk("call_site=%pS ptr=%p",
+ (void *)__entry->call_site, __entry->ptr)
);
DEFINE_EVENT(kmem_free, kfree,
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 26b0a08f3c7d..f801d154ff6a 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -365,11 +365,11 @@ static inline struct trace_array *top_trace_array(void)
__builtin_types_compatible_p(typeof(var), type *)
#undef IF_ASSIGN
-#define IF_ASSIGN(var, entry, etype, id) \
- if (FTRACE_CMP_TYPE(var, etype)) { \
- var = (typeof(var))(entry); \
- WARN_ON(id && (entry)->type != id); \
- break; \
+#define IF_ASSIGN(var, entry, etype, id) \
+ if (FTRACE_CMP_TYPE(var, etype)) { \
+ var = (typeof(var))(entry); \
+ WARN_ON(id != 0 && (entry)->type != id);\
+ break; \
}
/* Will cause compile errors if type is not found. */
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index c773b8fb270c..c9a74f82b14a 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -452,8 +452,10 @@ predicate_parse(const char *str, int nr_parens, int
nr_preds,
switch (*next) {
case '(': /* #2 */
- if (top - op_stack > nr_parens)
- return ERR_PTR(-EINVAL);
+ if (top - op_stack > nr_parens) {
+ ret = -EINVAL;
+ goto out_free;
+ }
*(++top) = invert;
continue;
case '!': /* #3 */
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index baf58a3612c0..905b10af5d5c 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -178,6 +178,16 @@ void __trace_probe_log_err(int offset, int err_type)
if (!command)
return;
+ if (trace_probe_log.index >= trace_probe_log.argc) {
+ /**
+* Set the error position is next to the last arg + space.
+* Note that len includes the terminal null and the cursor
+* appaers at pos + 1.
+*/
+ pos = len;
+ offset = 0;
+ }
+
[PATCH] arm64: tegra: only map accessible sysram
Most of the SysRAM is secure and only accessible by TF-A.
Don't map this inaccessible memory in kernel. Only map pages
used by bpmp driver.
Signed-off-by: Mian Yousaf Kaukab
---
Only tegra186 is tested. Tested on Jetson TX2.
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 14 +++---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 14 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 47cd831fcf44..a861f46125fd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1174,23 +1174,23 @@
power-domains = < TEGRA186_POWER_DOMAIN_GPU>;
};
- sysram@3000 {
+ sysram@3004e000 {
compatible = "nvidia,tegra186-sysram", "mmio-sram";
- reg = <0x0 0x3000 0x0 0x5>;
+ reg = <0x0 0x3004e000 0x0 0x2000>;
#address-cells = <2>;
#size-cells = <2>;
- ranges = <0 0x0 0x0 0x3000 0x0 0x5>;
+ ranges = <0 0x0 0x0 0x3004e000 0x0 0x2000>;
- cpu_bpmp_tx: shmem@4e000 {
+ cpu_bpmp_tx: shmem@e000 {
compatible = "nvidia,tegra186-bpmp-shmem";
- reg = <0x0 0x4e000 0x0 0x1000>;
+ reg = <0x0 0x0 0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
- cpu_bpmp_rx: shmem@4f000 {
+ cpu_bpmp_rx: shmem@f000 {
compatible = "nvidia,tegra186-bpmp-shmem";
- reg = <0x0 0x4f000 0x0 0x1000>;
+ reg = <0x0 0x1000 0x0 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 3c0cf54f0aab..98b9399d6b7f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1430,23 +1430,23 @@
0x8200 0x0 0x4000 0x1f 0x4000 0x0
0xc000>; /* non-prefetchable memory (3GB) */
};
- sysram@4000 {
+ sysram@4004e000 {
compatible = "nvidia,tegra194-sysram", "mmio-sram";
- reg = <0x0 0x4000 0x0 0x5>;
+ reg = <0x0 0x4004e000 0x0 0x2000>;
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x0 0x4000 0x5>;
+ ranges = <0x0 0x0 0x4004e000 0x2000>;
- cpu_bpmp_tx: shmem@4e000 {
+ cpu_bpmp_tx: shmem@e000 {
compatible = "nvidia,tegra194-bpmp-shmem";
- reg = <0x4e000 0x1000>;
+ reg = <0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
- cpu_bpmp_rx: shmem@4f000 {
+ cpu_bpmp_rx: shmem@f000 {
compatible = "nvidia,tegra194-bpmp-shmem";
- reg = <0x4f000 0x1000>;
+ reg = <0x1000 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
--
2.16.4
[for-linus][PATCH 1/5] tracing/probe: Fix to check the difference of nr_args before adding probe
From: Masami Hiramatsu
Steven reported that a test triggered:
==
BUG: KASAN: slab-out-of-bounds in trace_kprobe_create+0xa9e/0xe40
Read of size 8 at addr 8880c4f25a48 by task ftracetest/4798
CPU: 2 PID: 4798 Comm: ftracetest Not tainted 5.3.0-rc6-test+ #30
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03
07/14/2016
Call Trace:
dump_stack+0x7c/0xc0
? trace_kprobe_create+0xa9e/0xe40
print_address_description+0x6c/0x332
? trace_kprobe_create+0xa9e/0xe40
? trace_kprobe_create+0xa9e/0xe40
__kasan_report.cold.6+0x1a/0x3b
? trace_kprobe_create+0xa9e/0xe40
kasan_report+0xe/0x12
trace_kprobe_create+0xa9e/0xe40
? print_kprobe_event+0x280/0x280
? match_held_lock+0x1b/0x240
? find_held_lock+0xac/0xd0
? fs_reclaim_release.part.112+0x5/0x20
? lock_downgrade+0x350/0x350
? kasan_unpoison_shadow+0x30/0x40
? __kasan_kmalloc.constprop.6+0xc1/0xd0
? trace_kprobe_create+0xe40/0xe40
? trace_kprobe_create+0xe40/0xe40
create_or_delete_trace_kprobe+0x2e/0x60
trace_run_command+0xc3/0xe0
? trace_panic_handler+0x20/0x20
? kasan_unpoison_shadow+0x30/0x40
trace_parse_run_command+0xdc/0x163
vfs_write+0xe1/0x240
ksys_write+0xba/0x150
? __ia32_sys_read+0x50/0x50
? tracer_hardirqs_on+0x61/0x180
? trace_hardirqs_off_caller+0x43/0x110
? mark_held_locks+0x29/0xa0
? do_syscall_64+0x14/0x260
do_syscall_64+0x68/0x260
Fix to check the difference of nr_args before adding probe
on existing probes. This also may set the error log index
bigger than the number of command parameters. In that case
it sets the error position is next to the last parameter.
Link:
http://lkml.kernel.org/r/156966474783.3478.13217501608215769150.stgit@devnote2
Fixes: ca89bc071d5e ("tracing/kprobe: Add multi-probe per event support")
Reported-by: Steven Rostedt (VMware)
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_probe.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index baf58a3612c0..905b10af5d5c 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -178,6 +178,16 @@ void __trace_probe_log_err(int offset, int err_type)
if (!command)
return;
+ if (trace_probe_log.index >= trace_probe_log.argc) {
+ /**
+* Set the error position is next to the last arg + space.
+* Note that len includes the terminal null and the cursor
+* appaers at pos + 1.
+*/
+ pos = len;
+ offset = 0;
+ }
+
/* And make a command string from argv array */
p = command;
for (i = 0; i < trace_probe_log.argc; i++) {
@@ -1084,6 +1094,12 @@ int trace_probe_compare_arg_type(struct trace_probe *a,
struct trace_probe *b)
{
int i;
+ /* In case of more arguments */
+ if (a->nr_args < b->nr_args)
+ return a->nr_args + 1;
+ if (a->nr_args > b->nr_args)
+ return b->nr_args + 1;
+
for (i = 0; i < a->nr_args; i++) {
if ((b->nr_args <= i) ||
((a->args[i].type != b->args[i].type) ||
--
2.20.1
[for-linus][PATCH 3/5] tracing: Have error path in predicate_parse() free its allocated memory
From: Navid Emamdoost
In predicate_parse, there is an error path that is not going to
out_free instead it returns directly which leads to a memory leak.
Link: http://lkml.kernel.org/r/20190920225800.3870-1-navid.emamdo...@gmail.com
Signed-off-by: Navid Emamdoost
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_events_filter.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index c773b8fb270c..c9a74f82b14a 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -452,8 +452,10 @@ predicate_parse(const char *str, int nr_parens, int
nr_preds,
switch (*next) {
case '(': /* #2 */
- if (top - op_stack > nr_parens)
- return ERR_PTR(-EINVAL);
+ if (top - op_stack > nr_parens) {
+ ret = -EINVAL;
+ goto out_free;
+ }
*(++top) = invert;
continue;
case '!': /* #3 */
--
2.20.1
[for-linus][PATCH 4/5] mm, tracing: Print symbol name for call_site in trace events
From: Changbin Du
To improve the readability of raw slab trace points, print the call_site ip
using '%pS'. Then we can grep events with function names.
[002] 808.188897: kmem_cache_free: call_site=putname+0x47/0x50
ptr=cef40c80
[002] 808.188898: kfree: call_site=security_cred_free+0x42/0x50
ptr=62400820
[002] 808.188904: kmem_cache_free: call_site=put_cred_rcu+0x88/0xa0
ptr=58d74ef8
[002] 808.188913: kmem_cache_alloc: call_site=prepare_creds+0x26/0x100
ptr=58d74ef8 bytes_req=168 bytes_alloc=576 gfp_flags=GFP_KERNEL
[002] 808.188917: kmalloc: call_site=security_prepare_creds+0x77/0xa0
ptr=62400820 bytes_req=8 bytes_alloc=336 gfp_flags=GFP_KERNEL|__GFP_ZERO
[002] 808.188920: kmem_cache_alloc: call_site=getname_flags+0x4f/0x1e0
ptr=cef40c80 bytes_req=4096 bytes_alloc=4480 gfp_flags=GFP_KERNEL
[002] 808.188925: kmem_cache_free: call_site=putname+0x47/0x50
ptr=cef40c80
[002] 808.188926: kfree: call_site=security_cred_free+0x42/0x50
ptr=62400820
[002] 808.188931: kmem_cache_free: call_site=put_cred_rcu+0x88/0xa0
ptr=58d74ef8
Link: http://lkml.kernel.org/r/20190914103215.23301-1-changbin...@gmail.com
Signed-off-by: Changbin Du
Signed-off-by: Steven Rostedt (VMware)
---
include/trace/events/kmem.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index eb57e3037deb..69e8bb8963db 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -35,8 +35,8 @@ DECLARE_EVENT_CLASS(kmem_alloc,
__entry->gfp_flags = gfp_flags;
),
- TP_printk("call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
- __entry->call_site,
+ TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
+ (void *)__entry->call_site,
__entry->ptr,
__entry->bytes_req,
__entry->bytes_alloc,
@@ -131,7 +131,8 @@ DECLARE_EVENT_CLASS(kmem_free,
__entry->ptr= ptr;
),
- TP_printk("call_site=%lx ptr=%p", __entry->call_site, __entry->ptr)
+ TP_printk("call_site=%pS ptr=%p",
+ (void *)__entry->call_site, __entry->ptr)
);
DEFINE_EVENT(kmem_free, kfree,
--
2.20.1
[for-linus][PATCH 0/5] tracing: Minor fixes for the last pull request
Some final fix ups that will be sent to Linus shortly. Changbin Du (1): mm, tracing: Print symbol name for call_site in trace events Masami Hiramatsu (1): tracing/probe: Fix to check the difference of nr_args before adding probe Nathan Chancellor (1): tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macro Navid Emamdoost (1): tracing: Have error path in predicate_parse() free its allocated memory Steven Rostedt (VMware) (1): selftests/ftrace: Fix same probe error test include/trace/events/kmem.h | 7 --- kernel/trace/trace.h | 10 +- kernel/trace/trace_events_filter.c | 6 -- kernel/trace/trace_probe.c | 16 .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 2 +- 5 files changed, 30 insertions(+), 11 deletions(-)
[for-linus][PATCH 2/5] tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macro
From: Nathan Chancellor
After r372664 in clang, the IF_ASSIGN macro causes a couple hundred
warnings along the lines of:
kernel/trace/trace_output.c:1331:2: warning: converting the enum
constant to a boolean [-Wint-in-bool-context]
kernel/trace/trace.h:409:3: note: expanded from macro
'trace_assign_type'
IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry,
^
kernel/trace/trace.h:371:14: note: expanded from macro 'IF_ASSIGN'
WARN_ON(id && (entry)->type != id); \
^
264 warnings generated.
This warning can catch issues with constructs like:
if (state == A || B)
where the developer really meant:
if (state == A || state == B)
This is currently the only occurrence of the warning in the kernel
tree across defconfig, allyesconfig, allmodconfig for arm32, arm64,
and x86_64. Add the implicit '!= 0' to the WARN_ON statement to fix
the warnings and find potential issues in the future.
Link:
https://github.com/llvm/llvm-project/commit/28b38c277a2941e9e891b2db30652cfd962f070b
Link: https://github.com/ClangBuiltLinux/linux/issues/686
Link: http://lkml.kernel.org/r/20190926162258.466321-1-natechancel...@gmail.com
Reviewed-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 26b0a08f3c7d..f801d154ff6a 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -365,11 +365,11 @@ static inline struct trace_array *top_trace_array(void)
__builtin_types_compatible_p(typeof(var), type *)
#undef IF_ASSIGN
-#define IF_ASSIGN(var, entry, etype, id) \
- if (FTRACE_CMP_TYPE(var, etype)) { \
- var = (typeof(var))(entry); \
- WARN_ON(id && (entry)->type != id); \
- break; \
+#define IF_ASSIGN(var, entry, etype, id) \
+ if (FTRACE_CMP_TYPE(var, etype)) { \
+ var = (typeof(var))(entry); \
+ WARN_ON(id != 0 && (entry)->type != id);\
+ break; \
}
/* Will cause compile errors if type is not found. */
--
2.20.1
[for-linus][PATCH 5/5] selftests/ftrace: Fix same probe error test
From: "Steven Rostedt (VMware)"
The "same probe" selftest that tests that adding the same probe fails
doesn't add the same probe and passes, which fails the test.
Fixes: b78b94b82122 ("selftests/ftrace: Update kprobe event error testcase")
Signed-off-by: Steven Rostedt (VMware)
---
.../selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
index 8a4025e912cb..ef1e9bafb098 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
@@ -95,7 +95,7 @@ echo 'p:kprobes/testevent _do_fork abcd=\1' > kprobe_events
check_error 'p:kprobes/testevent _do_fork ^bcd=\1' # DIFF_ARG_TYPE
check_error 'p:kprobes/testevent _do_fork ^abcd=\1:u8' # DIFF_ARG_TYPE
check_error 'p:kprobes/testevent _do_fork ^abcd=\"foo"'# DIFF_ARG_TYPE
-check_error '^p:kprobes/testevent _do_fork'# SAME_PROBE
+check_error '^p:kprobes/testevent _do_fork abcd=\1'# SAME_PROBE
fi
exit 0
--
2.20.1
[PATCH v2 4/6] media: cedrus: Detect first slice of a frame
When codec supports multiple slices in one frame, VPU has to know when
first slice of each frame is being processed, presumably to correctly
clear/set data in auxiliary buffers.
Add first_slice field to cedrus_run structure and set it according to
timestamps of capture and output buffers. If timestamps are different,
it's first slice and viceversa.
Signed-off-by: Jernej Skrabec
---
drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 2f017a651848..32cb38e541c6 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
struct cedrus_run {
struct vb2_v4l2_buffer *src;
struct vb2_v4l2_buffer *dst;
+ bool first_slice;
union {
struct cedrus_h264_run h264;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index 56ca4c9ad01c..e49c3396ca4d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+ run.first_slice = !run.dst->vb2_buf.copied_timestamp ||
+ run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
/* Apply request(s) controls if needed. */
src_req = run.src->vb2_buf.req_obj.req;
--
2.23.0
[PATCH v2 3/6] media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers
These helpers are used by stateless codecs when they support multiple
slices per frame and hold capture buffer flag is set. It's expected that
all such codecs will use this code.
Signed-off-by: Jernej Skrabec
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 35 ++
include/media/v4l2-mem2mem.h | 4 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 19937dd3c6f6..2677a07e4c9b 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -1154,6 +1154,41 @@ int v4l2_m2m_ioctl_try_decoder_cmd(struct file *file,
void *fh,
}
EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_try_decoder_cmd);
+int v4l2_m2m_ioctl_stateless_try_decoder_cmd(struct file *file, void *fh,
+struct v4l2_decoder_cmd *dc)
+{
+ if (dc->cmd != V4L2_DEC_CMD_FLUSH)
+ return -EINVAL;
+
+ dc->flags = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_stateless_try_decoder_cmd);
+
+int v4l2_m2m_ioctl_stateless_decoder_cmd(struct file *file, void *priv,
+struct v4l2_decoder_cmd *dc)
+{
+ struct v4l2_fh *fh = file->private_data;
+ struct vb2_v4l2_buffer *out_vb, *cap_vb;
+ int ret;
+
+ ret = v4l2_m2m_ioctl_stateless_try_decoder_cmd(file, priv, dc);
+ if (ret < 0)
+ return ret;
+
+ out_vb = v4l2_m2m_last_src_buf(fh->m2m_ctx);
+ cap_vb = v4l2_m2m_last_dst_buf(fh->m2m_ctx);
+
+ if (out_vb)
+ out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+ else if (cap_vb && cap_vb->is_held)
+ v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_stateless_decoder_cmd);
+
/*
* v4l2_file_operations helpers. It is assumed here same lock is used
* for the output and the capture buffer queue.
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index c9fa96c8eed1..8ae2f56c7fa3 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -714,6 +714,10 @@ int v4l2_m2m_ioctl_try_encoder_cmd(struct file *file, void
*fh,
struct v4l2_encoder_cmd *ec);
int v4l2_m2m_ioctl_try_decoder_cmd(struct file *file, void *fh,
struct v4l2_decoder_cmd *dc);
+int v4l2_m2m_ioctl_stateless_try_decoder_cmd(struct file *file, void *fh,
+struct v4l2_decoder_cmd *dc);
+int v4l2_m2m_ioctl_stateless_decoder_cmd(struct file *file, void *priv,
+struct v4l2_decoder_cmd *dc);
int v4l2_m2m_fop_mmap(struct file *file, struct vm_area_struct *vma);
__poll_t v4l2_m2m_fop_poll(struct file *file, poll_table *wait);
--
2.23.0
[PATCH v2 6/6] media: cedrus: Add support for holding capture buffer
When frame contains multiple slices and driver works in slice mode, it's
more efficient to hold capture buffer in queue until all slices of a
same frame are decoded.
Add support for that to Cedrus driver by exposing and implementing
V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
Signed-off-by: Jernej Skrabec
---
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 14 ++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e49c3396ca4d..67f7d4326fc1 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+
+ if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
+ run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+ }
+ run.dst->is_held = run.src->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+
run.first_slice = !run.dst->vb2_buf.copied_timestamp ||
run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
@@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
run.mpeg2.quantization = cedrus_find_control_data(ctx,
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+ run.dst->is_held = false;
break;
case V4L2_PIX_FMT_H264_SLICE:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index fc8579b90dab..b466041c25db 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
if (!src_buf || !dst_buf) {
v4l2_err(>v4l2_dev,
@@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
state = VB2_BUF_STATE_DONE;
v4l2_m2m_buf_done(src_buf, state);
- v4l2_m2m_buf_done(dst_buf, state);
-
+ if (!dst_buf->is_held) {
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(dst_buf, state);
+ }
v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
return IRQ_HANDLED;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 3ec3a2db790c..82198b2bb081 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -303,6 +303,17 @@ static int cedrus_s_fmt_vid_out(struct file *file, void
*priv,
ctx->src_fmt = f->fmt.pix;
+ switch (ctx->src_fmt.pixelformat) {
+ case V4L2_PIX_FMT_H264_SLICE:
+ vq->subsystem_flags |=
+ VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
+ break;
+ default:
+ vq->subsystem_flags &=
+ (u32)~VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
+ break;
+ }
+
/* Propagate colorspace information to capture. */
ctx->dst_fmt.colorspace = f->fmt.pix.colorspace;
ctx->dst_fmt.xfer_func = f->fmt.pix.xfer_func;
@@ -336,6 +347,9 @@ const struct v4l2_ioctl_ops cedrus_ioctl_ops = {
.vidioc_streamon= v4l2_m2m_ioctl_streamon,
.vidioc_streamoff = v4l2_m2m_ioctl_streamoff,
+ .vidioc_try_decoder_cmd =
v4l2_m2m_ioctl_stateless_try_decoder_cmd,
+ .vidioc_decoder_cmd = v4l2_m2m_ioctl_stateless_decoder_cmd,
+
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
--
2.23.0
[PATCH v2 2/6] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Hans Verkuil
Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
Reviewed-by: Boris Brezillon
Reviewed-by: Alexandre Courbot
Signed-off-by: Hans Verkuil
[Adjusted description]
Signed-off-by: Jernej Skrabec
---
Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +-
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
index 57f0066f4cff..f1a504836f31 100644
--- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
+++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
@@ -208,7 +208,15 @@ introduced in Linux 3.3. They are, however, mandatory for
stateful mem2mem decod
been started yet, the driver will return an ``EPERM`` error code. When
the decoder is already running, this command does nothing. No
flags are defined for this command.
-
+* - ``V4L2_DEC_CMD_FLUSH``
+ - 4
+ - Flush any held capture buffers. Only valid for stateless decoders.
+ This command is typically used when the application reached the
+ end of the stream and the last output buffer had the
+ ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
+ dequeueing the capture buffer containing the last decoded frame.
+ So this command can be used to explicitly flush that final decoded
+ frame. This command does nothing if there are no held capture buffers.
Return Value
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index adeb6b7a15cb..a79028e4d929 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
replace define V4L2_DEC_CMD_STOP decoder-cmds
replace define V4L2_DEC_CMD_PAUSE decoder-cmds
replace define V4L2_DEC_CMD_RESUME decoder-cmds
+replace define V4L2_DEC_CMD_FLUSH decoder-cmds
replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4fa9f543742d..91a79e16089c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
#define V4L2_DEC_CMD_STOP(1)
#define V4L2_DEC_CMD_PAUSE (2)
#define V4L2_DEC_CMD_RESUME (3)
+#define V4L2_DEC_CMD_FLUSH (4)
/* Flags for V4L2_DEC_CMD_START */
#define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
--
2.23.0
[PATCH v2 1/6] vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
From: Hans Verkuil
This patch adds support for the V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag.
It also adds a new V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability and
a v4l2_m2m_release_capture_buf() helper function.
Drivers should set vb2_queue->subsystem_flags to
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF to indicate support for this flag.
The device_run() function should look like this:
if (v4l2_m2m_release_capture_buf(out_vb, cap_vb)) {
v4l2_m2m_dst_buf_remove(m2m_ctx);
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
cap_vb = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
}
cap_vb->is_held = out_vb->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
...
v4l2_m2m_buf_done(out_vb, VB2_BUF_STATE_DONE);
if (!cap_vb->is_held) {
v4l2_m2m_dst_buf_remove(m2m_ctx);
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
}
In order to handle the corner case where V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
is always set for the output buffer, and you reached the last frame (so no
new output buffer will be queued with a new timestamp), the driver must
implement support for the V4L2_DEC_CMD_FLUSH command, and that should do:
struct vb2_v4l2_buffer *out_vb = v4l2_m2m_last_src_buf(m2m_ctx);
struct vb2_v4l2_buffer *cap_vb = v4l2_m2m_last_dst_buf(m2m_ctx);
if (out_vb)
out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
else if (cap_vb && cap_vb->is_held)
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
For formats that do not support slicing (e.g. VP8), the FLUSH command
just does nothing.
Signed-off-by: Hans Verkuil
Tested-by: Boris Brezillon
Reviewed-by: Boris Brezillon
[Adjust example code]
Signed-off-by: Jernej Skrabec
---
Documentation/media/uapi/v4l/buffer.rst | 13 ++
.../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++
.../media/common/videobuf2/videobuf2-v4l2.c | 8 +++-
include/media/v4l2-mem2mem.h | 42 +++
include/media/videobuf2-core.h| 3 ++
include/media/videobuf2-v4l2.h| 5 +++
include/uapi/linux/videodev2.h| 13 +++---
7 files changed, 84 insertions(+), 6 deletions(-)
diff --git a/Documentation/media/uapi/v4l/buffer.rst
b/Documentation/media/uapi/v4l/buffer.rst
index 1cbd9cde57f3..afb03906ead9 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -607,6 +607,19 @@ Buffer Flags
applications shall use this flag for output buffers if the data in
this buffer has not been created by the CPU but by some
DMA-capable unit, in which case caches have not been used.
+* .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`:
+
+ - ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF``
+ - 0x0200
+ - Only valid if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` is
+set. It is typically used with stateless decoders where multiple
+ output buffers each decode to a slice of the decoded frame.
+ Applications can set this flag when queueing the output buffer
+ to prevent the driver from dequeueing the capture buffer after
+ the output buffer has been decoded (i.e. the capture buffer is
+ 'held'). If the timestamp of this output buffer differs from that
+ of the previous output buffer, then that indicates the start of a
+ new frame and the previously held capture buffer is dequeued.
* .. _`V4L2-BUF-FLAG-LAST`:
- ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index d7faef10e39b..d0c643db477a 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -125,6 +125,7 @@ aborting or finishing any DMA in progress, an implicit
.. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
.. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
.. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS:
+.. _V4L2-BUF-CAP-SUPPORTS-M2M-HOLD-CAPTURE-BUF:
.. cssclass:: longtable
@@ -150,6 +151,11 @@ aborting or finishing any DMA in progress, an implicit
- The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still
mapped or exported via DMABUF. These orphaned buffers will be freed
when they are unmapped or when the exported DMABUF fds are closed.
+* - ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF``
+ - 0x0020
+ - Only valid for stateless decoders. If set, then userspace can set the
+``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag to hold off on returning
the
+ capture buffer until the OUTPUT timestamp changes.
Return Value
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 5a9ba3846f0a..699787f48f46 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -50,7 +50,8 @@ module_param(debug, int, 0644);
V4L2_BUF_FLAG_TIMESTAMP_MASK)
/* Output
[PATCH v2 5/6] media: cedrus: h264: Support multiple slices per frame
With recent changes, support for decoding multi-slice frames can be easily added now. Signal VPU if current slice is first in frame or not and add information about first macroblock coordinates. Signed-off-by: Jernej Skrabec --- drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index d6a782703c9b..b7260cfeb6f4 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c @@ -301,6 +301,8 @@ static void cedrus_set_params(struct cedrus_ctx *ctx, dma_addr_t src_buf_addr; u32 offset = slice->header_bit_size; u32 len = (slice->size * 8) - offset; + unsigned int pic_width_in_mbs; + bool mbaff_pic; u32 reg; cedrus_write(dev, VE_H264_VLD_LEN, len); @@ -370,12 +372,19 @@ static void cedrus_set_params(struct cedrus_ctx *ctx, reg |= VE_H264_SPS_DIRECT_8X8_INFERENCE; cedrus_write(dev, VE_H264_SPS, reg); + mbaff_pic = !(slice->flags & V4L2_H264_SLICE_FLAG_FIELD_PIC) && + (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD); + pic_width_in_mbs = sps->pic_width_in_mbs_minus1 + 1; + // slice parameters reg = 0; + reg |= ((slice->first_mb_in_slice % pic_width_in_mbs) & 0xff) << 24; + reg |= (((slice->first_mb_in_slice / pic_width_in_mbs) * (mbaff_pic + 1)) & 0xff) << 16; reg |= decode->nal_ref_idc ? BIT(12) : 0; reg |= (slice->slice_type & 0xf) << 8; reg |= slice->cabac_init_idc & 0x3; - reg |= VE_H264_SHS_FIRST_SLICE_IN_PIC; + if (run->first_slice) + reg |= VE_H264_SHS_FIRST_SLICE_IN_PIC; if (slice->flags & V4L2_H264_SLICE_FLAG_FIELD_PIC) reg |= VE_H264_SHS_FIELD_PIC; if (slice->flags & V4L2_H264_SLICE_FLAG_BOTTOM_FIELD) -- 2.23.0
[PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
This series adds support for decoding multi-slice H264 frames along with support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF. Code was tested by modified ffmpeg, which can be found here: https://github.com/jernejsk/FFmpeg, branch mainline-test It has to be configured with at least following options: --enable-v4l2-request --enable-libudev --enable-libdrm Samples used for testing: http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4 http://jernej.libreelec.tv/videos/h264/h264.mp4 Command line used for testing: ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt bgra -f fbdev /dev/fb0 Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm not sure how. ffmpeg follows exactly which slice is last in frame and sets hold flag accordingly. Improper usage of hold flag would corrupt ffmpeg assumptions and it would probably crash. Any ideas how to test this are welcome! Thanks to Jonas for adjusting ffmpeg. Please let me know what you think. Best regards, Jernej Changes from v1: - added Rb tags - updated V4L2_DEC_CMD_FLUSH documentation - updated first slice detection in Cedrus - hold capture buffer flag is set according to source format - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers Hans Verkuil (2): vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF videodev2.h: add V4L2_DEC_CMD_FLUSH Jernej Skrabec (4): media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers media: cedrus: Detect first slice of a frame media: cedrus: h264: Support multiple slices per frame media: cedrus: Add support for holding capture buffer Documentation/media/uapi/v4l/buffer.rst | 13 ++ .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++- .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++ .../media/videodev2.h.rst.exceptions | 1 + .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++- drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++ drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 + .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 - .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++-- .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++ include/media/v4l2-mem2mem.h | 46 +++ include/media/videobuf2-core.h| 3 ++ include/media/videobuf2-v4l2.h| 5 ++ include/uapi/linux/videodev2.h| 14 -- 15 files changed, 175 insertions(+), 11 deletions(-) -- 2.23.0
Re: [PATCH] arm64: dts: rockchip: fix Rockpro64 RK808 interrupt line
Am Samstag, 21. September 2019, 15:14:57 CEST schrieb Hugh Cole-Baker:
> Fix the pinctrl and interrupt specifier for RK808 to use GPIO3_B2. On the
> Rockpro64 schematic [1] page 16, it shows GPIO3_B2 used for the interrupt
> line PMIC_INT_L from the RK808, and there's a note which translates as:
> "PMU termination GPIO1_C5 changed to this".
>
> Tested by setting an RTC wakealarm and checking /proc/interrupts counters.
> Without this patch, neither the rockchip_gpio_irq counter for the RK808,
> nor the RTC alarm counter increment when the alarm time is reached.
> With this patch, both interrupt counters increment by 1 as expected.
>
> [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
>
> Fixes: e4f3fb4 ("arm64: dts: rockchip: add initial dts support for Rockpro64")
> Signed-off-by: Hugh Cole-Baker
applied as fix for 5.4
Thanks
Heiko
Why does /proc/partitions have sr0 and fd0 in it?
Hi, I was updating some tools such as udev, mdadm, lvm, and came across a hang and messages about unable to read fd0 which wasn't occurring with the old tools, but using same kernel. So I've found that in the old version the /proc/partitions didn't have fd0 whereas now it does. But both have sr0 in it. So that leads me to who populates the /proc/partitions, from the limited info you can find searching the Internet, it looks like the kernel. But obviously not since same kernel used with different results. The difference is the old system udev used the old debian create_static_nodes and didn't use devtmpfs, the new udev (eudev), uses devtmpfs and the create_static_nodes is a bash function instead of separate binary. I wonder if that has something to do with it. But since cd and floppy devices aren't partitioned traditionally (technically any block device could be but it would be non-standard) why are they in the /proc/partitions file (also the device, e.g. sda, is in there and it's not a partition). So is it not partitions but just block devices? If so, maybe /proc/partitions should be a symlink to a new /proc/blockdevices, so everyone is clear what actually goes in there (leave the old name just for backwards compatibility) ? Is there any docs on all this? Thanks!
MIPS SGI IP30
hi guys any news about the kernel? I still have a lot of trouble with the PCI. Carlo
Re: [PATCH AUTOSEL 5.3 20/49] firmware: bcm47xx_nvram: Correct size_t printf format
On 9/29/2019 10:30 AM, Sasha Levin wrote:
> From: Florian Fainelli
>
> [ Upstream commit feb4eb060c3aecc3c5076bebe699cd09f1133c41 ]
>
> When building on a 64-bit host, we will get warnings like those:
>
> drivers/firmware/broadcom/bcm47xx_nvram.c:103:3: note: in expansion of macro
> 'pr_err'
>pr_err("nvram on flash (%i bytes) is bigger than the reserved space in
> memory, will just copy the first %i bytes\n",
>^~
> drivers/firmware/broadcom/bcm47xx_nvram.c:103:28: note: format string is
> defined here
>pr_err("nvram on flash (%i bytes) is bigger than the reserved space in
> memory, will just copy the first %i bytes\n",
>~^
>%li
>
> Use %zu instead for that purpose.
This is not a fix that should be backported as it was done only to allow
the driver to the made buildable with COMPILE_TEST. Please drop it from
your auto-selection.
>
> Signed-off-by: Florian Fainelli
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Paul Burton
> Cc: linux-m...@linux-mips.org
> Cc: j...@perches.com
> Cc: Rafał Miłecki
> Cc: linux-m...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Sasha Levin
> ---
> drivers/firmware/broadcom/bcm47xx_nvram.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
> b/drivers/firmware/broadcom/bcm47xx_nvram.c
> index 77eb74666ecbc..6d2820f6aca13 100644
> --- a/drivers/firmware/broadcom/bcm47xx_nvram.c
> +++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
> @@ -96,7 +96,7 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
> lim)
> nvram_len = size;
> }
> if (nvram_len >= NVRAM_SPACE) {
> - pr_err("nvram on flash (%i bytes) is bigger than the reserved
> space in memory, will just copy the first %i bytes\n",
> + pr_err("nvram on flash (%zu bytes) is bigger than the reserved
> space in memory, will just copy the first %i bytes\n",
> nvram_len, NVRAM_SPACE - 1);
> nvram_len = NVRAM_SPACE - 1;
> }
> @@ -148,7 +148,7 @@ static int nvram_init(void)
> header.len > sizeof(header)) {
> nvram_len = header.len;
> if (nvram_len >= NVRAM_SPACE) {
> - pr_err("nvram on flash (%i bytes) is bigger than the
> reserved space in memory, will just copy the first %i bytes\n",
> + pr_err("nvram on flash (%zu bytes) is bigger than the
> reserved space in memory, will just copy the first %i bytes\n",
> header.len, NVRAM_SPACE);
> nvram_len = NVRAM_SPACE - 1;
> }
>
--
Florian
[GIT PULL] MMC updates for v5.4 take 2
Hi Linus, Here's a PR with a couple more updates/fixes for MMC fixes intended for v5.4. No worries if this doesn't get included in rc1. Details about the highlights are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit 3c6a6910a81eae3566bb5fef6ea0f624382595e6: Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2019-09-23 09:31:42 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.4-2 for you to fetch changes up to e51df6ce668a8f75ce27f83ce0f60103c568c375: mmc: host: sdhci-pci: Add Genesys Logic GL975x support (2019-09-27 20:48:20 +0200) MMC host: - sdhci-pci: Add Genesys Logic GL975x support - sdhci-tegra: Recover loss in throughput for DMA - sdhci-of-esdhc: Fix DMA bug Adrian Hunter (1): mmc: sdhci: Let drivers define their DMA mask Ben Chuang (1): mmc: host: sdhci-pci: Add Genesys Logic GL975x support Nicolin Chen (1): mmc: tegra: Implement ->set_dma_mask() Russell King (2): mmc: sdhci: improve ADMA error reporting mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence drivers/mmc/host/Kconfig | 1 + drivers/mmc/host/Makefile | 2 +- drivers/mmc/host/sdhci-of-esdhc.c | 7 +- drivers/mmc/host/sdhci-pci-core.c | 2 + drivers/mmc/host/sdhci-pci-gli.c | 352 ++ drivers/mmc/host/sdhci-pci.h | 5 + drivers/mmc/host/sdhci-tegra.c| 48 +++--- drivers/mmc/host/sdhci.c | 27 +-- drivers/mmc/host/sdhci.h | 1 + 9 files changed, 410 insertions(+), 35 deletions(-) create mode 100644 drivers/mmc/host/sdhci-pci-gli.c
Re: [PATCH 2/3] clk: let init callback return an error code
Am Dienstag, 24. September 2019, 14:39:53 CEST schrieb Jerome Brunet: > If the init callback is allowed to request resources, it needs a return > value to report the outcome of such a request. > > Signed-off-by: Jerome Brunet > --- [...] > drivers/clk/rockchip/clk-pll.c| 28 --- for the Rockchip part Acked-by: Heiko Stuebner
Re: WireGuard to port to existing Crypto API
Hi, On Wed, Sep 25, 2019 at 10:29:45AM +0200, Jason A. Donenfeld wrote: > I've long resisted the idea of porting to the existing crypto API, > because I think there are serious problems with it, in terms of > primitives, API, performance, and overall safety. I didn't want to > ship WireGuard in a form that I thought was sub-optimal from a > security perspective, since WireGuard is a security-focused project. > > But it seems like with or without us, WireGuard will get ported to the > existing crypto API. So it's probably better that we just fully > embrace it, and afterwards work evolutionarily to get Zinc into Linux > piecemeal. I've ported WireGuard already several times as a PoC to the > API and have a decent idea of the ways it can go wrong and generally > how to do it in the least-bad way. > > I realize this kind of compromise might come as a disappointment for > some folks. But it's probably better that as a project we remain > intimately involved with our Linux kernel users and the security of > the implementation, rather than slinking away in protest because we > couldn't get it all in at once. So we'll work with upstream, port to > the crypto API, and get the process moving again. We'll pick up the > Zinc work after that's done. > > I also understand there might be interested folks out there who enjoy > working with the crypto API quite a bit and would be happy to work on > the WireGuard port. Please do get in touch if you'd like to > collaborate. I have some WIP code to port WG to the crypto API, more to get an idea how hard it would be, though I read you've ported it to the api already. My other project (btrfs) is going to use blake2 in kernel and for that I'm about to submit the code, that's where it's also of interest for wg. My work is at 'github.com/kdave/WireGuard branch lkca-1'. I tried to find a way how to minimize the impact on current wg code but make it possible to iteratively extend it to the crypto API. So, there's some config-time ifdefery to select which crypto functions are using kernel or zinc api. See wg.git/src/crypto/Kbuild.include at the top, plus some source ifdefs. I made an example of blake2s port, but only compile tested. There are several problems in general that need to be solved on the kernel side first, before wireguard can work inside the kernel code base: * missing crypto functions in kernel * blake2 * curve25519 (missing completely) * missing generic crypto API callback to use blake_init_key, it's possible to use only the no-key variant (I have a patch for that, it's really easy but it's change in API so ...) The known problem is the cumbersome way to use the crypto functions, eg. for chacha/poly, I understand the pain and perhaps the reasons to start a fresh crypto library. I'm afraid the first implementation with current state of crypto API will be slow, until the API is extended to provide simple ways to transform buffers without scatterlists, request allocations, locking tfm context and whatnot. Feel free to reuse anything from the code if you think it's going the right direction. I'm not sure if I'll have time to continue with the port but at least you can consider blake2 on the way upstream. d.
Re: [PATCH 5.2 00/45] 5.2.18-stable review
stable-rc/linux-5.2.y boot: 83 boots: 0 failed, 83 passed (v5.2.17-46-g70cc0b99b90f) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.17-46-g70cc0b99b90f/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.17-46-g70cc0b99b90f/ Tree: stable-rc Branch: linux-5.2.y Git Describe: v5.2.17-46-g70cc0b99b90f Git Commit: 70cc0b99b90f823b81175b1f15f73ced86135c5b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 46 unique boards, 15 SoC families, 13 builds out of 209 --- For more info write to
Re: [PATCH 4.19 00/63] 4.19.76-stable review
stable-rc/linux-4.19.y boot: 80 boots: 1 failed, 78 passed with 1 conflict (v4.19.75-64-gb52c75f7b978) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.75-64-gb52c75f7b978/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.75-64-gb52c75f7b978/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.75-64-gb52c75f7b978 Git Commit: b52c75f7b9785d0d0e6bf145787ed2fc99f5483c Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 15 SoC families, 13 builds out of 206 Boot Regressions Detected: arm: tegra_defconfig: gcc-8: tegra124-nyan-big: lab-collabora: new failure (last pass: v4.19.75-33-gdab8e08e7087) Boot Failure Detected: arm: tegra_defconfig: gcc-8: tegra124-nyan-big: 1 failed lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: exynos_defconfig: exynos5422-odroidxu3: lab-collabora: PASS (gcc-8) lab-baylibre: FAIL (gcc-8) --- For more info write to
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 4d856f72c10ecb060868ed10ff1b1453943fc6c8: Linux 5.3 (2019-09-15 14:19:32 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes for you to fetch changes up to 9bfd7319e8d353b8b81c4cfd4d7eced71adbfbb5: Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes (2019-09-29 11:20:48 -0700) ARM: SoC fixes A few fixes that have trickled in through the merge window: - Video fixes for OMAP due to panel-dpi driver removal - Clock fixes for OMAP that broke no-idle quirks + nfsroot on DRA7 - Fixing arch version on ASpeed ast2500 - Two fixes for reset handling on ARM SCMI Adam Ford (4): ARM: omap2plus_defconfig: Fix missing video ARM: dts: logicpd-torpedo-baseboard: Fix missing video ARM: dts: am3517-evm: Fix missing video ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux Arnd Bergmann (1): ARM: aspeed: ast2500 is ARMv6K Olof Johansson (2): Merge tag 'scmi-fixes-5.4' of git://git.kernel.org/.../sudeep.holla/linux into arm/fixes Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/.../tmlind/linux-omap into arm/fixes Sudeep Holla (2): firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset reset: reset-scmi: add missing handle initialisation Tony Lindgren (3): bus: ti-sysc: Fix clock handling for no-idle quirks bus: ti-sysc: Fix handling of invalid clocks bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle() Documentation/devicetree/bindings/arm/arm,scmi.txt | 17 + MAINTAINERS| 1 + arch/arm/boot/dts/am3517-evm.dts | 23 +- arch/arm/boot/dts/logicpd-som-lv.dtsi | 26 +- arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi | 37 +-- arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-aspeed/Kconfig | 1 - arch/arm/mach-omap2/pdata-quirks.c | 4 +- drivers/bus/ti-sysc.c | 52 ++- drivers/clk/clk-scmi.c | 2 +- drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/base.c | 2 +- drivers/firmware/arm_scmi/clock.c | 33 +- drivers/firmware/arm_scmi/common.h | 18 +- drivers/firmware/arm_scmi/driver.c | 366 + drivers/firmware/arm_scmi/perf.c | 264 ++- drivers/firmware/arm_scmi/power.c | 6 +- drivers/firmware/arm_scmi/reset.c | 231 + drivers/firmware/arm_scmi/sensors.c| 57 ++-- drivers/hwmon/scmi-hwmon.c | 2 +- drivers/reset/Kconfig | 11 + drivers/reset/Makefile | 1 + drivers/reset/reset-scmi.c | 125 +++ include/linux/scmi_protocol.h | 46 ++- 24 files changed, 1046 insertions(+), 282 deletions(-) create mode 100644 drivers/firmware/arm_scmi/reset.c create mode 100644 drivers/reset/reset-scmi.c
Re: [GIT PULL 1/2] arm64: dts: exynos: Pull for v5.4
Hi, On Thu, Sep 12, 2019 at 08:32:47AM +0200, Krzysztof Kozlowski wrote: > On Wed, 11 Sep 2019 at 23:07, Arnd Bergmann wrote: > > > > On Wed, Sep 11, 2019 at 8:36 PM Krzysztof Kozlowski wrote: > > > > > > Hi, > > > > > > Unfortunately the patches were applied right after closing the linux-next. > > > > Hi Krzysztof, > > > > I took a look at these and am not convinced this is right: > > > > > 1. Fix boot of Exynos7 due to wrong address/size of memory node, > > > > The current state is clearly broken and a fix is needed, but > > I'm not sure this is the right fix. Why do you have 32-bit physical > > addressing on a 64-bit chip? I looked at commit ef72171b3621 > > that introduced it, and it seems it would be better to just > > revert back to 64-bit addresses. > > We discussed with Marek Szyprowski that either we can go back to > 64-bit addressing or stick to 32. There are not known boards with more > than 4 GB of RAM so from this point of view the choice was irrelevant. > At the end of discussion I mentioned to stick with other arm64 boards > (although not all), so revert to have 64 bit address... but Marek > chosen differently. Since you ask, let's go back with revert. > > > > > > 2. Move GPU under /soc node, > > > > No problem > > > > > 3. Minor cleanup of #address-cells. > > > > IIRC, an interrupt-controller is required to have a #address-cells > > property, even if that is normally zero. I don't remember the > > details, but the gic binding lists it as mandatory, and I think > > the PCI interrupt-map relies on it. I would just drop this patch. > > Indeed, binding requires both address and size cells. I'll drop it. Looking through the history of pending material, I didn't see a new pull for this material. Just checking in to see if there's something we missed? Thanks, -Olof
Re: [PATCH AUTOSEL 4.14 08/23] ARM: 8875/1: Kconfig: default to AEABI w/ Clang
On Sun, Sep 29, 2019 at 01:35:18PM -0400, Sasha Levin wrote: > From: Nick Desaulniers > > [ Upstream commit a05b9608456e0d4464c6f7ca8572324ace57a3f4 ] > > Clang produces references to __aeabi_uidivmod and __aeabi_idivmod for > arm-linux-gnueabi and arm-linux-gnueabihf targets incorrectly when AEABI > is not selected (such as when OABI_COMPAT is selected). > > While this means that OABI userspaces wont be able to upgraded to > kernels built with Clang, it means that boards that don't enable AEABI > like s3c2410_defconfig will stop failing to link in KernelCI when built > with Clang. > > Link: https://github.com/ClangBuiltLinux/linux/issues/482 > Link: > https://groups.google.com/forum/#!msg/clang-built-linux/yydsAAux5hk/GxjqJSW-AQAJ > > Suggested-by: Arnd Bergmann > Signed-off-by: Nick Desaulniers > Reviewed-by: Arnd Bergmann > Reviewed-by: Linus Walleij > Signed-off-by: Russell King > Signed-off-by: Sasha Levin > --- > arch/arm/Kconfig | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index cf69aab648fbd..f0080864b9ce8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1595,8 +1595,9 @@ config ARM_PATCH_IDIV > code to do integer division. > > config AEABI > - bool "Use the ARM EABI to compile the kernel" if !CPU_V7 && !CPU_V7M && > !CPU_V6 && !CPU_V6K > - default CPU_V7 || CPU_V7M || CPU_V6 || CPU_V6K > + bool "Use the ARM EABI to compile the kernel" if !CPU_V7 && \ > + !CPU_V7M && !CPU_V6 && !CPU_V6K && !CC_IS_CLANG > + default CPU_V7 || CPU_V7M || CPU_V6 || CPU_V6K || CC_IS_CLANG > help > This option allows for the kernel to be compiled using the latest > ARM ABI (aka EABI). This is only useful if you are using a user > -- > 2.20.1 > Hi Sasha, This patch will not do anything for 4.14 because CC_IS_CLANG is not defined in this tree. The Kconfig patches that make this symbol possible were not merged until 4.18. I would recommend dropping it (unless Nick has an idea to make this work). Cheers, Nathan
[PATCH v5 01/14] ARM: tegra: Remove cpuidle drivers to replace them with a new driver
Remove the old drivers to replace them cleanly with a new one later on.
Please note that old Tegra20 CPUIDLE driver used pen-locking in order to
block secondary CPU waking-up if IRQ happened to raise during of the
entering into CC6 and primary CPU already crossed point of no return, but
that is unnecessary in practice because CPUIDLE simply won't enter the
coupled CC6 state if there is some CPU activity going on. The new driver
will ensure that all secondary CPUs parked successfully at first and thus
primary CPU won't be racing with the secondaries, hence the pen-locking
functionality isn't needed anymore at all. This is the most notable thing
of this patch.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/Makefile | 13 --
arch/arm/mach-tegra/cpuidle-tegra114.c | 89 ---
arch/arm/mach-tegra/cpuidle-tegra20.c | 212 -
arch/arm/mach-tegra/cpuidle-tegra30.c | 132 ---
arch/arm/mach-tegra/cpuidle.c | 50 --
arch/arm/mach-tegra/cpuidle.h | 21 ---
arch/arm/mach-tegra/irq.c | 1 -
arch/arm/mach-tegra/irq.h | 11 --
arch/arm/mach-tegra/pm.c | 7 -
arch/arm/mach-tegra/pm.h | 1 -
arch/arm/mach-tegra/reset-handler.S| 11 --
arch/arm/mach-tegra/reset.h| 9 +-
arch/arm/mach-tegra/sleep-tegra20.S| 170
arch/arm/mach-tegra/sleep.h| 12 --
arch/arm/mach-tegra/tegra.c| 3 -
drivers/soc/tegra/Kconfig | 1 -
include/soc/tegra/cpuidle.h| 4 -
17 files changed, 2 insertions(+), 745 deletions(-)
delete mode 100644 arch/arm/mach-tegra/cpuidle-tegra114.c
delete mode 100644 arch/arm/mach-tegra/cpuidle-tegra20.c
delete mode 100644 arch/arm/mach-tegra/cpuidle-tegra30.c
delete mode 100644 arch/arm/mach-tegra/cpuidle.c
delete mode 100644 arch/arm/mach-tegra/cpuidle.h
delete mode 100644 arch/arm/mach-tegra/irq.h
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 6c1dff2eccc2..5d93a0b36866 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -8,29 +8,16 @@ obj-y += reset.o
obj-y += reset-handler.o
obj-y += sleep.o
obj-y += tegra.o
-obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= sleep-tegra20.o
obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= pm-tegra20.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= cpuidle-tegra20.o
-endif
obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= sleep-tegra30.o
obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= pm-tegra30.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= cpuidle-tegra30.o
-endif
obj-$(CONFIG_SMP) += platsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += sleep-tegra30.o
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += pm-tegra30.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_114_SOC) += cpuidle-tegra114.o
-endif
obj-$(CONFIG_ARCH_TEGRA_124_SOC) += sleep-tegra30.o
obj-$(CONFIG_ARCH_TEGRA_124_SOC) += pm-tegra30.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_124_SOC) += cpuidle-tegra114.o
-endif
obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= board-paz00.o
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c
b/arch/arm/mach-tegra/cpuidle-tegra114.c
deleted file mode 100644
index 5118f777fd66..
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ /dev/null
@@ -1,89 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include
-#include
-#include
-#include
-
-#include "cpuidle.h"
-#include "pm.h"
-#include "sleep.h"
-
-#ifdef CONFIG_PM_SLEEP
-#define TEGRA114_MAX_STATES 2
-#else
-#define TEGRA114_MAX_STATES 1
-#endif
-
-#ifdef CONFIG_PM_SLEEP
-static int tegra114_idle_power_down(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- local_fiq_disable();
-
- tegra_set_cpu_in_lp2();
- cpu_pm_enter();
-
- call_firmware_op(prepare_idle, TF_PM_MODE_LP2_NOFLUSH_L2);
-
- /* Do suspend by ourselves if the firmware does not implement it */
- if (call_firmware_op(do_idle, 0) == -ENOSYS)
- cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
-
- cpu_pm_exit();
- tegra_clear_cpu_in_lp2();
-
- local_fiq_enable();
-
- return index;
-}
-
-static void tegra114_idle_enter_s2idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
-
Re: [Cocci] [RFC PATCH] scripts: Fix coccicheck failed
> Maybe the problem would be solved by putting virtual report at the top of the > rule. I assume that support for the operation mode “patch” can eventually be considered. > But it might still fail because nothing can happen without a value > for the virtual metavariable ns. I imagine that the safe handling of this command line input parameter will trigger further software development concerns. > Should the coccinelle directory be only for things that work with make > coccicheck, I hope not. But it seems that a filter command expressed such a restriction so far. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccicheck?id=02dc96ef6c25f990452c114c59d75c368a1f4c8f#n257 Is this place an update candidate now? > or for all Coccinelle scripts? I would prefer file storage selections in this direction. How do you think about to improve the software taxonomy accordingly? Regards, Markus
[PATCH v5 09/14] clk: tegra: Add missing stubs for the case of !CONFIG_PM_SLEEP
The new CPUIDLE driver uses the Tegra's CLK API and that driver won't
strictly depend on CONFIG_PM_SLEEP, hence add the required stubs in
order to allow compiling of the new driver with the CONFIG_PM_SLEEP=n.
Signed-off-by: Dmitry Osipenko
---
include/linux/clk/tegra.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/clk/tegra.h b/include/linux/clk/tegra.h
index b8aef62cc3f5..cf0f2cb5e109 100644
--- a/include/linux/clk/tegra.h
+++ b/include/linux/clk/tegra.h
@@ -108,6 +108,19 @@ static inline void tegra_cpu_clock_resume(void)
tegra_cpu_car_ops->resume();
}
+#else
+static inline bool tegra_cpu_rail_off_ready(void)
+{
+ return false;
+}
+
+static inline void tegra_cpu_clock_suspend(void)
+{
+}
+
+static inline void tegra_cpu_clock_resume(void)
+{
+}
#endif
extern void tegra210_xusb_pll_hw_control_enable(void);
--
2.23.0
[PATCH v5 04/14] ARM: tegra: Compile sleep-tegra20/30.S unconditionally
The sleep-tegra*.S provides functionality required for suspend/resume and CPU hotplugging. The new unified CPUIDLE driver will support multiple hardware generations starting from Terga20 and ending with Tegra124, the driver will utilize functions that are provided by the assembly and thus it is cleaner to compile that code without any build-dependencies in order to avoid churning with #ifdef's. Signed-off-by: Dmitry Osipenko --- arch/arm/mach-tegra/Makefile | 10 -- arch/arm/mach-tegra/sleep.h | 2 -- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile index 5d93a0b36866..3bb44246d928 100644 --- a/arch/arm/mach-tegra/Makefile +++ b/arch/arm/mach-tegra/Makefile @@ -8,16 +8,14 @@ obj-y += reset.o obj-y += reset-handler.o obj-y += sleep.o obj-y += tegra.o -obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= sleep-tegra20.o -obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= pm-tegra20.o -obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= sleep-tegra30.o -obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= pm-tegra30.o +obj-y += sleep-tegra20.o +obj-y += sleep-tegra30.o obj-$(CONFIG_SMP) += platsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o -obj-$(CONFIG_ARCH_TEGRA_114_SOC) += sleep-tegra30.o +obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= pm-tegra20.o +obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= pm-tegra30.o obj-$(CONFIG_ARCH_TEGRA_114_SOC) += pm-tegra30.o -obj-$(CONFIG_ARCH_TEGRA_124_SOC) += sleep-tegra30.o obj-$(CONFIG_ARCH_TEGRA_124_SOC) += pm-tegra30.o obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= board-paz00.o diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h index d219872b7546..4978def9db46 100644 --- a/arch/arm/mach-tegra/sleep.h +++ b/arch/arm/mach-tegra/sleep.h @@ -118,10 +118,8 @@ void tegra_resume(void); int tegra_sleep_cpu_finish(unsigned long); void tegra_disable_clean_inv_dcache(u32 flag); -#ifdef CONFIG_HOTPLUG_CPU void tegra20_hotplug_shutdown(void); void tegra30_hotplug_shutdown(void); -#endif void tegra20_tear_down_cpu(void); int tegra30_sleep_cpu_secondary_finish(unsigned long); -- 2.23.0
[PATCH v5 14/14] ARM: tegra: Enable Tegra cpuidle driver in tegra_defconfig
The Tegra CPU Idle driver was moved out into driver/cpuidle/ directory and it is now a proper platform driver. Signed-off-by: Dmitry Osipenko --- arch/arm/configs/tegra_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 8f5c6a5b444c..9a2f11a780a8 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -25,6 +25,7 @@ CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPUFREQ_DT=y CONFIG_CPU_IDLE=y +CONFIG_ARM_TEGRA_CPUIDLE=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_TRUSTED_FOUNDATIONS=y -- 2.23.0
[PATCH v5 12/14] ARM: tegra: Create simple platform device for cpuidle driver
The new CPUIDLE driver now is a proper platform driver, hence it needs
a platform device in order to be functional. Register the platform device,
like we do that for the CPUFreq driver. Note that on some Tegra114(124)
devices PSCI may be used for the CPU hotplugging and CPUIDLE driver
doesn't support that case, thus CPUIDLE device won't be registered if
PCSI presents.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/tegra.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index d9237769a37c..f1ce2857a251 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include "board.h"
@@ -92,6 +93,9 @@ static void __init tegra_dt_init_late(void)
if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
of_machine_is_compatible("nvidia,tegra20"))
platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
+
+ if (IS_ENABLED(CONFIG_ARM_TEGRA_CPUIDLE) && !psci_smp_available())
+ platform_device_register_simple("tegra-cpuidle", -1, NULL, 0);
}
static const char * const tegra_dt_board_compat[] = {
--
2.23.0
[PATCH v5 13/14] ARM: multi_v7_defconfig: Enable Tegra cpuidle driver
The Tegra CPU Idle driver was moved out into driver/cpuidle/ directory and it is now a proper platform driver. Signed-off-by: Dmitry Osipenko --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 13ba53286901..539bb60069ee 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -110,6 +110,7 @@ CONFIG_CPU_IDLE=y CONFIG_ARM_CPUIDLE=y CONFIG_ARM_ZYNQ_CPUIDLE=y CONFIG_ARM_EXYNOS_CPUIDLE=y +CONFIG_ARM_TEGRA_CPUIDLE=y CONFIG_KERNEL_MODE_NEON=y CONFIG_RASPBERRYPI_FIRMWARE=y CONFIG_TRUSTED_FOUNDATIONS=y -- 2.23.0
[PATCH v5 07/14] ARM: tegra: Add tegra_pm_park_secondary_cpu()
This function resembles tegra_cpu_die() of the hotplug code, but
this variant is more suitable to be used for CPU PM because it's made
specifically to be used by cpu_suspend(). In short this function puts
secondary CPU offline, it will be used by the new CPUIDLE driver.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c | 14 ++
include/soc/tegra/pm.h | 6 ++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 4cc64a135a3e..7d9ef26e52a7 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -427,4 +427,18 @@ void __init tegra_init_suspend(void)
suspend_set_ops(_suspend_ops);
}
+
+int tegra_pm_park_secondary_cpu(unsigned long cpu)
+{
+ if (cpu > 0) {
+ tegra_disable_clean_inv_dcache(TEGRA_FLUSH_CACHE_LOUIS);
+
+ if (tegra_get_chip_id() == TEGRA20)
+ tegra20_hotplug_shutdown();
+ else
+ tegra30_hotplug_shutdown();
+ }
+
+ return -EINVAL;
+}
#endif
diff --git a/include/soc/tegra/pm.h b/include/soc/tegra/pm.h
index 2fbee9efda21..08477d7bfab9 100644
--- a/include/soc/tegra/pm.h
+++ b/include/soc/tegra/pm.h
@@ -27,6 +27,7 @@ int tegra30_pm_secondary_cpu_suspend(unsigned long arg);
void tegra_pm_clear_cpu_in_lp2(void);
void tegra_pm_set_cpu_in_lp2(void);
int tegra_pm_enter_lp2(void);
+int tegra_pm_park_secondary_cpu(unsigned long cpu);
#else
static inline enum tegra_suspend_mode
tegra_pm_validate_suspend_mode(enum tegra_suspend_mode mode)
@@ -55,6 +56,11 @@ static inline int tegra_pm_enter_lp2(void)
{
return -ENOTSUPP;
}
+
+static inline int tegra_pm_park_secondary_cpu(unsigned long cpu)
+{
+ return -ENOTSUPP;
+}
#endif /* CONFIG_PM_SLEEP */
#endif /* __SOC_TEGRA_PM_H__ */
--
2.23.0
[PATCH v5 06/14] ARM: tegra: Rename some of the newly exposed PM functions
Rename some of the recently exposed PM functions, prefixing them with
"tegra_pm_" and making naming of those functions more meaningful, for
consistency.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c| 10 +-
arch/arm/mach-tegra/sleep-tegra30.S | 6 +++---
include/soc/tegra/pm.h | 16
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index f9c9bce9e15d..4cc64a135a3e 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -110,7 +110,7 @@ static void suspend_cpu_complex(void)
flowctrl_cpu_suspend_enter(cpu);
}
-void tegra_clear_cpu_in_lp2(void)
+void tegra_pm_clear_cpu_in_lp2(void)
{
int phy_cpu_id = cpu_logical_map(smp_processor_id());
u32 *cpu_in_lp2 = tegra_cpu_lp2_mask;
@@ -123,7 +123,7 @@ void tegra_clear_cpu_in_lp2(void)
spin_unlock(_lp2_lock);
}
-void tegra_set_cpu_in_lp2(void)
+void tegra_pm_set_cpu_in_lp2(void)
{
int phy_cpu_id = cpu_logical_map(smp_processor_id());
u32 *cpu_in_lp2 = tegra_cpu_lp2_mask;
@@ -189,7 +189,7 @@ static void tegra_pm_set(enum tegra_suspend_mode mode)
tegra_pmc_enter_suspend_mode(mode);
}
-int tegra_idle_lp2_last(void)
+int tegra_pm_enter_lp2(void)
{
int err;
@@ -356,7 +356,7 @@ static int tegra_suspend_enter(suspend_state_t state)
tegra_suspend_enter_lp1();
break;
case TEGRA_SUSPEND_LP2:
- tegra_set_cpu_in_lp2();
+ tegra_pm_set_cpu_in_lp2();
break;
default:
break;
@@ -377,7 +377,7 @@ static int tegra_suspend_enter(suspend_state_t state)
tegra_suspend_exit_lp1();
break;
case TEGRA_SUSPEND_LP2:
- tegra_clear_cpu_in_lp2();
+ tegra_pm_clear_cpu_in_lp2();
break;
default:
break;
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S
b/arch/arm/mach-tegra/sleep-tegra30.S
index b408fa56eb89..386319a3d2d2 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -262,11 +262,11 @@ ENTRY(tegra30_sleep_core_finish)
ENDPROC(tegra30_sleep_core_finish)
/*
- * tegra30_sleep_cpu_secondary_finish(unsigned long v2p)
+ * tegra30_pm_secondary_cpu_suspend(unsigned long unused_arg)
*
* Enters LP2 on secondary CPU by exiting coherency and powergating the CPU.
*/
-ENTRY(tegra30_sleep_cpu_secondary_finish)
+ENTRY(tegra30_pm_secondary_cpu_suspend)
mov r7, lr
/* Flush and disable the L1 data cache */
@@ -278,7 +278,7 @@ ENTRY(tegra30_sleep_cpu_secondary_finish)
bl tegra30_cpu_shutdown
mov r0, #1 @ never return here
ret r7
-ENDPROC(tegra30_sleep_cpu_secondary_finish)
+ENDPROC(tegra30_pm_secondary_cpu_suspend)
/*
* tegra30_tear_down_cpu
diff --git a/include/soc/tegra/pm.h b/include/soc/tegra/pm.h
index bc1abdf41d61..2fbee9efda21 100644
--- a/include/soc/tegra/pm.h
+++ b/include/soc/tegra/pm.h
@@ -23,10 +23,10 @@ tegra_pm_validate_suspend_mode(enum tegra_suspend_mode
mode);
/* low-level resume entry point */
void tegra_resume(void);
-int tegra30_sleep_cpu_secondary_finish(unsigned long arg);
-void tegra_clear_cpu_in_lp2(void);
-void tegra_set_cpu_in_lp2(void);
-int tegra_idle_lp2_last(void);
+int tegra30_pm_secondary_cpu_suspend(unsigned long arg);
+void tegra_pm_clear_cpu_in_lp2(void);
+void tegra_pm_set_cpu_in_lp2(void);
+int tegra_pm_enter_lp2(void);
#else
static inline enum tegra_suspend_mode
tegra_pm_validate_suspend_mode(enum tegra_suspend_mode mode)
@@ -38,20 +38,20 @@ static inline void tegra_resume(void)
{
}
-static inline int tegra30_sleep_cpu_secondary_finish(unsigned long arg)
+static inline int tegra30_pm_secondary_cpu_suspend(unsigned long arg)
{
return -ENOTSUPP;
}
-static inline void tegra_clear_cpu_in_lp2(void)
+static inline void tegra_pm_clear_cpu_in_lp2(void)
{
}
-static inline void tegra_set_cpu_in_lp2(void)
+static inline void tegra_pm_set_cpu_in_lp2(void)
{
}
-static inline int tegra_idle_lp2_last(void)
+static inline int tegra_pm_enter_lp2(void)
{
return -ENOTSUPP;
}
--
2.23.0
[PATCH v5 10/14] cpuidle: Introduce unified driver for NVIDIA Tegra SoCs
The new driver is based on the old CPU Idle drivers that are removed now
from arm/arch/mach-tegra/ directory. Those removed drivers were reworked
and squashed into a single unified driver that covers multiple hardware
generations, starting from Tegra20 and ending with Tegra124. The new
driver takes slightly different approach in regards to handling of CC6
state by parking secondary CPUs explicitly into offline state, in contrast
to CPUs suspend/resume racing that old Tegra20 had. The new driver doesn't
ignore any possible errors and provides useful diagnostics information in
a case of failure.
Signed-off-by: Dmitry Osipenko
---
drivers/cpuidle/Kconfig.arm | 8 +
drivers/cpuidle/Makefile| 1 +
drivers/cpuidle/cpuidle-tegra.c | 350
include/soc/tegra/cpuidle.h | 4 +
4 files changed, 363 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-tegra.c
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index d8530475493c..6952bf7bb260 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -86,3 +86,11 @@ config ARM_MVEBU_V7_CPUIDLE
depends on ARCH_MVEBU && !ARM64
help
Select this to enable cpuidle on Armada 370, 38x and XP processors.
+
+config ARM_TEGRA_CPUIDLE
+ bool "CPU Idle Driver for NVIDIA Tegra SoCs"
+ depends on ARCH_TEGRA && !ARM64
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ select ARM_CPU_SUSPEND
+ help
+ Select this to enable cpuidle for NVIDIA Tegra20/30/114/124 SoCs.
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index ee70d5cc5b99..a15e4808d295 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_ARM_AT91_CPUIDLE) += cpuidle-at91.o
obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
obj-$(CONFIG_ARM_CPUIDLE) += cpuidle-arm.o
obj-$(CONFIG_ARM_PSCI_CPUIDLE) += cpuidle-psci.o
+obj-$(CONFIG_ARM_TEGRA_CPUIDLE)+= cpuidle-tegra.o
###
# MIPS drivers
diff --git a/drivers/cpuidle/cpuidle-tegra.c b/drivers/cpuidle/cpuidle-tegra.c
new file mode 100644
index ..a926d2781227
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-tegra.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * CPU idle driver for Tegra CPUs
+ *
+ * Copyright (c) 2010-2013, NVIDIA Corporation.
+ * Copyright (c) 2011 Google, Inc.
+ * Author: Colin Cross
+ * Gary King
+ *
+ * Rework for 3.3 by Peter De Schrijver
+ *
+ * Tegra20/124 driver unification by Dmitry Osipenko
+ */
+
+#define pr_fmt(fmt)"tegra-cpuidle: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define TEGRA_C1 0
+#define TEGRA_C7 1
+#define TEGRA_CC6 2
+
+static atomic_t tegra_idle_barrier;
+static atomic_t tegra_abort_flag;
+
+static inline bool tegra_cpuidle_using_firmware(void)
+{
+ return firmware_ops->prepare_idle && firmware_ops->do_idle;
+}
+
+static void tegra_cpuidle_report_cpus_state(void)
+{
+ unsigned int cpu, lcpu;
+
+ for_each_cpu(lcpu, cpu_possible_mask) {
+ cpu = cpu_logical_map(lcpu);
+
+ pr_err("cpu%u: online=%d flowctrl_csr=0x%08x\n",
+ cpu, cpu_online(lcpu), flowctrl_read_cpu_csr(cpu));
+ }
+}
+
+static int tegra_cpuidle_wait_for_secondary_cpus_parking(void)
+{
+ ktime_t timeout = ktime_add_ms(ktime_get(), 100);
+
+ /*
+* The primary CPU0 core shall wait for the secondaries shutdown
+* in order to power-off CPU's cluster safely. The timeout value
+* depends on the current CPU frequency, it takes about 40-150us
+* in average and over 1000us in a worst case scenario.
+*/
+ do {
+ if (tegra_cpu_rail_off_ready())
+ return 0;
+
+ } while (ktime_before(ktime_get(), timeout));
+
+ /* postmortem */
+ tegra_cpuidle_report_cpus_state();
+
+ return -ETIMEDOUT;
+}
+
+static void tegra_cpuidle_unpark_secondary_cpus(void)
+{
+ unsigned int cpu, lcpu;
+
+ for_each_cpu(lcpu, cpu_online_mask) {
+ cpu = cpu_logical_map(lcpu);
+
+ if (cpu > 0) {
+ tegra_enable_cpu_clock(cpu);
+ tegra_cpu_out_of_reset(cpu);
+ flowctrl_write_cpu_halt(cpu, 0);
+ }
+ }
+}
+
+static int tegra_cpuidle_cc6_enter(unsigned int cpu)
+{
+ int ret;
+
+ if (cpu > 0) {
+ ret = cpu_suspend(cpu, tegra_pm_park_secondary_cpu);
+ } else {
+ ret = tegra_cpuidle_wait_for_secondary_cpus_parking();
+ if (ret)
+ return ret;
+
+
[PATCH v5 03/14] ARM: tegra: Propagate error from tegra_idle_lp2_last()
The cpu_suspend() may fail, it's never good to lose information about
failure because it may become very useful for the caller. The new CPUIDLE
driver will handle all of possible error cases, including the case of
tegra_idle_lp2_last() failure.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c | 8 ++--
arch/arm/mach-tegra/pm.h | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 2f6fb54be9f8..f9c9bce9e15d 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -189,14 +189,16 @@ static void tegra_pm_set(enum tegra_suspend_mode mode)
tegra_pmc_enter_suspend_mode(mode);
}
-void tegra_idle_lp2_last(void)
+int tegra_idle_lp2_last(void)
{
+ int err;
+
tegra_pm_set(TEGRA_SUSPEND_LP2);
cpu_cluster_pm_enter();
suspend_cpu_complex();
- cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, _sleep_cpu);
+ err = cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, _sleep_cpu);
/*
* Resume L2 cache if it wasn't re-enabled early during resume,
@@ -208,6 +210,8 @@ void tegra_idle_lp2_last(void)
restore_cpu_complex();
cpu_cluster_pm_exit();
+
+ return err;
}
enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 3f3164ad04b7..ae68fc7db576 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -25,7 +25,7 @@ void tegra30_sleep_core_init(void);
void tegra_clear_cpu_in_lp2(void);
void tegra_set_cpu_in_lp2(void);
-void tegra_idle_lp2_last(void);
+int tegra_idle_lp2_last(void);
extern void (*tegra_tear_down_cpu)(void);
#ifdef CONFIG_PM_SLEEP
--
2.23.0
[PATCH v5 02/14] ARM: tegra: Change tegra_set_cpu_in_lp2() type to void
The old Tegra30 CPUIDLE driver had intention to check whether primary
CPU was the last CPU that entered LP2 (CC6) idle-state, but that
functionality never got utilized by the old-removed driver because it
never supported the CC6 while secondary CPUs were online. The new driver
will properly support CC6 on Tegra30, including the case where secondary
CPUs are online, and that knowledge about what CPUs entered CC6 won't be
needed at all because new driver will use different approach by making use
of the coupled idle-state and explicitly parking secondary CPUs before
entering into CC6.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c | 8 +---
arch/arm/mach-tegra/pm.h | 2 +-
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 6aaacb5757e1..2f6fb54be9f8 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -123,11 +123,9 @@ void tegra_clear_cpu_in_lp2(void)
spin_unlock(_lp2_lock);
}
-bool tegra_set_cpu_in_lp2(void)
+void tegra_set_cpu_in_lp2(void)
{
int phy_cpu_id = cpu_logical_map(smp_processor_id());
- bool last_cpu = false;
- cpumask_t *cpu_lp2_mask = tegra_cpu_lp2_mask;
u32 *cpu_in_lp2 = tegra_cpu_lp2_mask;
spin_lock(_lp2_lock);
@@ -135,11 +133,7 @@ bool tegra_set_cpu_in_lp2(void)
BUG_ON((*cpu_in_lp2 & BIT(phy_cpu_id)));
*cpu_in_lp2 |= BIT(phy_cpu_id);
- if ((phy_cpu_id == 0) && cpumask_equal(cpu_lp2_mask, cpu_online_mask))
- last_cpu = true;
-
spin_unlock(_lp2_lock);
- return last_cpu;
}
static int tegra_sleep_cpu(unsigned long v2p)
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 1e51a9b636eb..3f3164ad04b7 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -24,7 +24,7 @@ void tegra30_lp1_iram_hook(void);
void tegra30_sleep_core_init(void);
void tegra_clear_cpu_in_lp2(void);
-bool tegra_set_cpu_in_lp2(void);
+void tegra_set_cpu_in_lp2(void);
void tegra_idle_lp2_last(void);
extern void (*tegra_tear_down_cpu)(void);
--
2.23.0
[PATCH v5 08/14] ARM: tegra: Make outer_disable() open-coded
The outer_disable() of Tegra's suspend code is open-coded now since that helper produces spurious warning message about secondary CPUs being online. The secondaries are actually halted by the cpuidle driver on entering into LP2 idle-state. This fixes a storm of warnings once LP2 idling state is enabled on Tegra30. Signed-off-by: Dmitry Osipenko --- arch/arm/mach-tegra/pm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c index 7d9ef26e52a7..16a02937d3da 100644 --- a/arch/arm/mach-tegra/pm.c +++ b/arch/arm/mach-tegra/pm.c @@ -146,9 +146,10 @@ static int tegra_sleep_cpu(unsigned long v2p) * if any of secondary CPU's is online and this is the LP2-idle * code-path only for Tegra20/30. */ - if (trusted_foundations_registered()) - outer_disable(); - +#ifdef CONFIG_OUTER_CACHE + if (trusted_foundations_registered() && outer_cache.disable) + outer_cache.disable(); +#endif /* * Note that besides of setting up CPU reset vector this firmware * call may also do the following, depending on the FW version: -- 2.23.0
[PATCH v5 00/14] Consolidate and improve NVIDIA Tegra CPUIDLE driver(s)
Hello, This series does the following: 1. Unifies Tegra20/30/114 drivers into a single driver and moves it out into common drivers/cpuidle/ directory. 2. Enables CPU cluster power-down idling state on Tegra30. In the end there is a quite nice clean up of the Tegra CPUIDLE drivers and of the Tegra's arch code in general. Please review, thanks! Changelog: v5: - Rebased on a recent linux-next, fixed one minor conflict in Kconfig. - Improved commit's message of the "Support CPU cluster power-down state on Tegra30" patch. - The "Support CPU cluster power-down state on Tegra30" patch is also got split and now there is additional "Make outer_disable() open-coded" patch. - Made minor cosmetic changes to the "Introduce unified driver for NVIDIA Tegra SoCs" patch by improving error message and renaming one variable. v4: - Fixed compilation with !CONFIG_CACHE_L2X0 (and tested that it still works). - Replaced ktime_compare() with ktime_before() in the new driver, for consistency. v3: - Addressed review comments that were made by Jon Hunter to v2 by splitting patches into smaller (and simpler) chunks, better documenting changes in the commit messages and using proper error codes in the code. Warnings are replaced with a useful error messages in the code of "Introduce unified driver for NVIDIA Tegra SoCs" patch. Secondary CPUs parking timeout increased to 100ms because I found that it actually may happen to take more than 1ms if CPU is running on a *very* low frequency. Added diagnostic messages that are reporting Flow Controller state when CPU parking fails. Further polished cpuidle driver's code. The coupled state entering is now aborted if there is a pending SGI (Software Generated Interrupt) because it will be lost after GIC's power-cycling. Like it was done by the old Tegra20 CPUIDLE driver. v2: - Added patches to enable the new cpuidle driver in the defconfigs: ARM: multi_v7_defconfig: Enable Tegra cpuidle driver ARM: tegra: Enable Tegra cpuidle driver in tegra_defconfig - Dropped patches that removed CPUIDLE_FLAG_TIMER_STOP from the idling states because that flag actually doesn't have any negative effects, but still is correct for the case of a local CPU timer on older Tegra SoCs: cpuidle: tegra: Remove CPUIDLE_FLAG_TIMER_STOP from Tegra114/124 idle-state cpuidle: tegra: Remove CPUIDLE_FLAG_TIMER_STOP from all states - The "Add unified driver for NVIDIA Tegra SoCs" patch got more polish. Tegra30 and Terga114 states are now squashed into a single common C7 state (following Parker TRM terminology, see 17.2.2.2 Power Management States), more comments added, etc minor changes. Dmitry Osipenko (14): ARM: tegra: Remove cpuidle drivers to replace them with a new driver ARM: tegra: Change tegra_set_cpu_in_lp2() type to void ARM: tegra: Propagate error from tegra_idle_lp2_last() ARM: tegra: Compile sleep-tegra20/30.S unconditionally ARM: tegra: Expose PM functions required for new cpuidle driver ARM: tegra: Rename some of the newly exposed PM functions ARM: tegra: Add tegra_pm_park_secondary_cpu() ARM: tegra: Make outer_disable() open-coded clk: tegra: Add missing stubs for the case of !CONFIG_PM_SLEEP cpuidle: Introduce unified driver for NVIDIA Tegra SoCs cpuidle: tegra: Support CPU cluster power-down state on Tegra30 ARM: tegra: Create simple platform device for cpuidle driver ARM: multi_v7_defconfig: Enable Tegra cpuidle driver ARM: tegra: Enable Tegra cpuidle driver in tegra_defconfig arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/configs/tegra_defconfig | 1 + arch/arm/mach-tegra/Makefile | 23 +- arch/arm/mach-tegra/cpuidle-tegra114.c| 89 - arch/arm/mach-tegra/cpuidle-tegra20.c | 212 --- arch/arm/mach-tegra/cpuidle-tegra30.c | 132 --- arch/arm/mach-tegra/cpuidle.c | 50 --- arch/arm/mach-tegra/cpuidle.h | 21 -- arch/arm/mach-tegra/irq.c | 3 +- arch/arm/mach-tegra/pm.c | 50 +-- arch/arm/mach-tegra/pm.h | 4 - arch/arm/mach-tegra/reset-handler.S | 11 - arch/arm/mach-tegra/reset.h | 9 +- arch/arm/mach-tegra/sleep-tegra20.S | 170 - arch/arm/mach-tegra/sleep-tegra30.S | 6 +- arch/arm/mach-tegra/sleep.h | 15 - arch/arm/mach-tegra/tegra.c | 7 +- drivers/cpuidle/Kconfig.arm | 8 + drivers/cpuidle/Makefile | 1 + drivers/cpuidle/cpuidle-tegra.c | 349 ++ drivers/soc/tegra/Kconfig | 1 - include/linux/clk/tegra.h | 13 +
[PATCH v5 05/14] ARM: tegra: Expose PM functions required for new cpuidle driver
The upcoming unified CPUIDLE driver will be added to the drivers/cpuidle/
directory and it will require all these exposed Tegra PM-core functions.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/irq.c | 2 ++
arch/arm/mach-tegra/pm.h| 3 ---
arch/arm/mach-tegra/sleep.h | 1 -
include/soc/tegra/irq.h | 13 +
include/soc/tegra/pm.h | 25 +
5 files changed, 40 insertions(+), 4 deletions(-)
create mode 100644 include/soc/tegra/irq.h
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 4c065b54cbe7..4e1ee70b2a3f 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include "board.h"
#include "iomap.h"
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index ae68fc7db576..81525f5f4a44 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -23,9 +23,6 @@ void tegra20_sleep_core_init(void);
void tegra30_lp1_iram_hook(void);
void tegra30_sleep_core_init(void);
-void tegra_clear_cpu_in_lp2(void);
-void tegra_set_cpu_in_lp2(void);
-int tegra_idle_lp2_last(void);
extern void (*tegra_tear_down_cpu)(void);
#ifdef CONFIG_PM_SLEEP
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 4978def9db46..4718a3cb45a1 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -122,7 +122,6 @@ void tegra20_hotplug_shutdown(void);
void tegra30_hotplug_shutdown(void);
void tegra20_tear_down_cpu(void);
-int tegra30_sleep_cpu_secondary_finish(unsigned long);
void tegra30_tear_down_cpu(void);
#endif
diff --git a/include/soc/tegra/irq.h b/include/soc/tegra/irq.h
new file mode 100644
index ..8eb11a7109e4
--- /dev/null
+++ b/include/soc/tegra/irq.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2012, NVIDIA Corporation. All rights reserved.
+ */
+
+#ifndef __SOC_TEGRA_IRQ_H
+#define __SOC_TEGRA_IRQ_H
+
+#if defined(CONFIG_ARM)
+bool tegra_pending_sgi(void);
+#endif
+
+#endif /* __SOC_TEGRA_IRQ_H */
diff --git a/include/soc/tegra/pm.h b/include/soc/tegra/pm.h
index 951fcd738d55..bc1abdf41d61 100644
--- a/include/soc/tegra/pm.h
+++ b/include/soc/tegra/pm.h
@@ -6,6 +6,8 @@
#ifndef __SOC_TEGRA_PM_H__
#define __SOC_TEGRA_PM_H__
+#include
+
enum tegra_suspend_mode {
TEGRA_SUSPEND_NONE = 0,
TEGRA_SUSPEND_LP2, /* CPU voltage off */
@@ -20,6 +22,11 @@ tegra_pm_validate_suspend_mode(enum tegra_suspend_mode mode);
/* low-level resume entry point */
void tegra_resume(void);
+
+int tegra30_sleep_cpu_secondary_finish(unsigned long arg);
+void tegra_clear_cpu_in_lp2(void);
+void tegra_set_cpu_in_lp2(void);
+int tegra_idle_lp2_last(void);
#else
static inline enum tegra_suspend_mode
tegra_pm_validate_suspend_mode(enum tegra_suspend_mode mode)
@@ -30,6 +37,24 @@ tegra_pm_validate_suspend_mode(enum tegra_suspend_mode mode)
static inline void tegra_resume(void)
{
}
+
+static inline int tegra30_sleep_cpu_secondary_finish(unsigned long arg)
+{
+ return -ENOTSUPP;
+}
+
+static inline void tegra_clear_cpu_in_lp2(void)
+{
+}
+
+static inline void tegra_set_cpu_in_lp2(void)
+{
+}
+
+static inline int tegra_idle_lp2_last(void)
+{
+ return -ENOTSUPP;
+}
#endif /* CONFIG_PM_SLEEP */
#endif /* __SOC_TEGRA_PM_H__ */
--
2.23.0
[PATCH v5 11/14] cpuidle: tegra: Support CPU cluster power-down state on Tegra30
The new Tegra CPU Idle driver now has a unified code path for the coupled LP2/CC6 state, this allows to enable the deepest idling state on Tegra30 SoC where the whole CPU cluster is power-gated. Signed-off-by: Dmitry Osipenko --- drivers/cpuidle/cpuidle-tegra.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/cpuidle/cpuidle-tegra.c b/drivers/cpuidle/cpuidle-tegra.c index a926d2781227..a30a5e4fc863 100644 --- a/drivers/cpuidle/cpuidle-tegra.c +++ b/drivers/cpuidle/cpuidle-tegra.c @@ -325,7 +325,6 @@ static int tegra_cpuidle_probe(struct platform_device *pdev) tegra_idle_driver.states[TEGRA_C7].disabled = true; break; case TEGRA30: - tegra_idle_driver.states[TEGRA_CC6].disabled = true; break; case TEGRA114: case TEGRA124: -- 2.23.0
Galax GeForce GTX1650 EX-1 Click OC PCI-E 4 GB GDDR5 128Bit Video Card Improves 4K Video Rendering Speeds by LEAPS AND BOUNDS!
Subject: Galax GeForce GTX1650 EX-1 Click OC PCI-E 4 GB GDDR5 128Bit Video Card Improves 4K Video Rendering Speeds by LEAPS AND BOUNDS! Good day from Singapore, I have just bought a Galax GeForce GTX1650 EX-1 Click OC PCI-E 4 GB GDDR5 128Bit with/Display Port/HDMI/DVI-D/CoolingFan video card for SGD$230 (after some bargaining) at a 4th story computer shop in Sim Lim Square in Singapore,Singapore on 29th September 2019 Sunday Singapore Time. Prior to buying the above-mentioned video card, I was using the Sapphire AMD Radeon HD6450 video card. Rendering a 2-hour 4K video with this ultra cheapo video card (GPU acceleration of video processing TURNED OFF) took MORE THAN TEN (10) hours! The technical specifications of my ancient and primitive home desktop computer are: [01] 5th Generation Intel Core i7-5820K Extreme Edition Processor with 6 cores and 12 threads @ 3.30 GHz [02] MSI X99A SLI Krait Edition Motherboard LGA2011-3 Socket with Intel X99 chipset [03] 32 GB DDR4 Memory (Mixture of 4 sticks of Crucial and Kingston DDR4 memory sticks) [04] Windows 10 Home Edition version 1803 64-bit [05] Vegas Movie Studio 15.0 Platinum video rendering software As of 30th September 2019 Monday Singapore Time, Intel Corporation has already released 10th Generation Intel Core processors. I am truly very sorry that I am not able to afford upgrading from 5th Generation Intel Core processor systems to 10th Generation Intel Core processor systems. Hence I have to make do with buying Galax GeForce GTX1650 EX-1 Click OC PCI-E 4 GB GDDR5 128Bit video card for SGD$230 at the moment. After removing the Sapphire AMD Radeon HD6450 video card from my home desktop computer, I installed the brand new Galax GeForce GTX1650 EX-1 Click OC PCI-E 4 GB GDDR5 128Bit video card immediately. Upon booting up Windows 10 Home Edition, I quickly turned on GPU Acceleration of Video Processing in Vegas Movie Studio 15.0 Platinum. I would choose all 4K video rendering templates with "NVIDIA NVENC". >From Wikipedia: [QUOTE] Nvidia NVENC is a feature in its graphics cards that performs video encoding, offloading this compute-intensive task from the CPU. It was introduced with the Kepler-based GeForce 600 series in March 2012.[1][2] The encoder is supported in many streaming and recording programs, such as Wirecast, Open Broadcaster Software (OBS) and Bandicam, and also works with Share game capture, which is included in Nvidia's GeForce Experience software.[3][4][5] Consumer targeted GeForce graphics cards officially support no more than 2 simultaneously encoding video streams, regardless of the count of the cards installed, but this restriction can be circumvented on Linux and Windows systems by applying an unofficial patch to the drivers[6]. Professional cards support between 2 and 21 simultaneous streams per card, depending on card model and compression quality.[1] [/QUOTE] And WOW! Rendering a 2 hour 19 minute 4K Ultra HD video (taken with my Samsung NX500 4K camera) with Galax GeForce GTX1650 EX-1 Click OC PCI-E 4 GB GDDR5 128Bit video card took only 3 hours and 30 minutes!!! This is a vast and tremendous improvement from the past of taking MORE THAN 10 hours to render a 2-hour 4K video without any GPU Acceleration of video processing! What do you think would happen if I am able to afford upgrading to a 10th Generation Intel Core home desktop computer? Greetings from Singapore! -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017) and in Taiwan (5 Aug 2019): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: [GIT PULL] libnvdimm fixes for v5.4-rc1
The pull request you sent on Sat, 28 Sep 2019 18:44:17 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-fixes-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a3c0e7b1fe1fc62bba5f591c4bc404eea96823b8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
