Re: [PATCH v5 4/5] cramfs: add mmap support
> + /* Don't map the last page if it contains some other data */
> + if (unlikely(pgoff + pages == max_pages)) {
> + unsigned int partial = offset_in_page(inode->i_size);
> + if (partial) {
> + char *data = sbi->linear_virt_addr + offset;
> + data += (max_pages - 1) * PAGE_SIZE + partial;
> + if (memchr_inv(data, 0, PAGE_SIZE - partial) != NULL) {
> + pr_debug("mmap: %s: last page is shared\n",
> + file_dentry(file)->d_name.name);
> + pages--;
> + }
> + }
> + }
Why is pgoff + pages == max_pages marked unlikely? Mapping the whole
file seems like a perfectly normal and likely case to me..
Also if this was my code I'd really prefer to move this into a helper:
static bool cramfs_mmap_last_page_is_shared(struct inode *inode, int offset)
{
unsigned int partial = offset_in_page(inode->i_size);
char *data = CRAMFS_SB(inode->i_sb)->linear_virt_addr + offset +
(inode->i_size & PAGE_MASK);
return memchr_inv(data + partial, 0, PAGE_SIZE - partial);
}
if (pgoff + pages == max_pages && offset_in_page(inode->i_size) &&
cramfs_mmap_last_page_is_shared(inode, offset))
pages--;
as that's much more readable and the function name provides a good
documentation of what is going on.
> + if (pages != vma_pages(vma)) {
here is how I would turn this around:
if (!pages)
goto done;
if (pages == vma_pages(vma)) {
remap_pfn_range();
goto done;
}
...
for (i = 0; i < pages; i++) {
...
vm_insert_mixed();
nr_mapped++;
}
done:
pr_debug("mapped %d out ouf %d\n", ..);
if (pages != vma_pages(vma))
vma->vm_ops = &generic_file_vm_ops;
return 0;
}
In fact we probably could just set the vm_ops unconditionally, they
just wouldn't be called, but that might be more confusing then helpful.
Re: [PATCH v4 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc
On Thu, Oct 05, 2017 at 11:21:38AM +0100, Julien Thierry wrote:
> Hi Takahiro,
>
> On 02/10/17 07:14, AKASHI Takahiro wrote:
> >arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be
> >duplicated among some architectures, so let's factor them out.
> >
> >Signed-off-by: AKASHI Takahiro
> >Cc: Dave Young
> >Cc: Vivek Goyal
> >Cc: Baoquan He
> >Cc: Michael Ellerman
> >Cc: Thiago Jung Bauermann
> >---
> > arch/powerpc/kernel/kexec_elf_64.c | 2 +-
> > arch/powerpc/kernel/machine_kexec_file_64.c | 36 ++---
> > arch/x86/kernel/kexec-bzimage64.c | 2 +-
> > arch/x86/kernel/machine_kexec_64.c | 45 +
> > include/linux/kexec.h | 15 +++
> > kernel/kexec_file.c | 63
> > ++---
> > 6 files changed, 73 insertions(+), 90 deletions(-)
> >
> >diff --git a/arch/powerpc/kernel/kexec_elf_64.c
> >b/arch/powerpc/kernel/kexec_elf_64.c
> >index 9a42309b091a..6c78c11c7faf 100644
> >--- a/arch/powerpc/kernel/kexec_elf_64.c
> >+++ b/arch/powerpc/kernel/kexec_elf_64.c
> >@@ -657,7 +657,7 @@ static void *elf64_load(struct kimage *image, char
> >*kernel_buf,
> > return ret ? ERR_PTR(ret) : fdt;
> > }
> >-struct kexec_file_ops kexec_elf64_ops = {
> >+const struct kexec_file_ops kexec_elf64_ops = {
> > .probe = elf64_probe,
> > .load = elf64_load,
> > };
> >diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c
> >b/arch/powerpc/kernel/machine_kexec_file_64.c
> >index 992c0d258e5d..e7ce78857f0b 100644
> >--- a/arch/powerpc/kernel/machine_kexec_file_64.c
> >+++ b/arch/powerpc/kernel/machine_kexec_file_64.c
> >@@ -31,8 +31,9 @@
> > #define SLAVE_CODE_SIZE256
> >-static struct kexec_file_ops *kexec_file_loaders[] = {
> >+const struct kexec_file_ops * const kexec_file_loaders[] = {
> > &kexec_elf64_ops,
> >+NULL
> > };
> > int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> >@@ -45,38 +46,7 @@ int arch_kexec_kernel_image_probe(struct kimage *image,
> >void *buf,
> > if (image->type == KEXEC_TYPE_CRASH)
> > return -ENOTSUPP;
> >-for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> >-fops = kexec_file_loaders[i];
> >-if (!fops || !fops->probe)
> >-continue;
> >-
> >-ret = fops->probe(buf, buf_len);
> >-if (!ret) {
> >-image->fops = fops;
> >-return ret;
> >-}
> >-}
> >-
> >-return ret;
> >-}
> >-
> >-void *arch_kexec_kernel_image_load(struct kimage *image)
> >-{
> >-if (!image->fops || !image->fops->load)
> >-return ERR_PTR(-ENOEXEC);
> >-
> >-return image->fops->load(image, image->kernel_buf,
> >- image->kernel_buf_len, image->initrd_buf,
> >- image->initrd_buf_len, image->cmdline_buf,
> >- image->cmdline_buf_len);
> >-}
> >-
> >-int arch_kimage_file_post_load_cleanup(struct kimage *image)
> >-{
> >-if (!image->fops || !image->fops->cleanup)
> >-return 0;
> >-
> >-return image->fops->cleanup(image->image_loader_data);
> >+return _kexec_kernel_image_probe(image, buf, buf_len);
> > }
> > /**
> >diff --git a/arch/x86/kernel/kexec-bzimage64.c
> >b/arch/x86/kernel/kexec-bzimage64.c
> >index fb095ba0c02f..705654776c0c 100644
> >--- a/arch/x86/kernel/kexec-bzimage64.c
> >+++ b/arch/x86/kernel/kexec-bzimage64.c
> >@@ -538,7 +538,7 @@ static int bzImage64_verify_sig(const char *kernel,
> >unsigned long kernel_len)
> > }
> > #endif
> >-struct kexec_file_ops kexec_bzImage64_ops = {
> >+const struct kexec_file_ops kexec_bzImage64_ops = {
> > .probe = bzImage64_probe,
> > .load = bzImage64_load,
> > .cleanup = bzImage64_cleanup,
> >diff --git a/arch/x86/kernel/machine_kexec_64.c
> >b/arch/x86/kernel/machine_kexec_64.c
> >index 1f790cf9d38f..2cdd29d64181 100644
> >--- a/arch/x86/kernel/machine_kexec_64.c
> >+++ b/arch/x86/kernel/machine_kexec_64.c
> >@@ -30,8 +30,9 @@
> > #include
> > #ifdef CONFIG_KEXEC_FILE
> >-static struct kexec_file_ops *kexec_file_loaders[] = {
> >+const struct kexec_file_ops * const kexec_file_loaders[] = {
> > &kexec_bzImage64_ops,
> >+NULL
> > };
> > #endif
> >@@ -363,27 +364,6 @@ void arch_crash_save_vmcoreinfo(void)
> > /* arch-dependent functionality related to kexec file-based syscall */
> > #ifdef CONFIG_KEXEC_FILE
> >-int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> >- unsigned long buf_len)
> >-{
> >-int i, ret = -ENOEXEC;
> >-struct kexec_file_ops *fops;
> >-
> >-for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> >-fops = kexec_file_loaders[i];
> >-if (!fops || !fops->probe)
> >-continue;
> >-
> >-ret = fops->probe(buf, buf_len);
> >-if (!ret) {
Re: [PATCH v7 2/2] tracing: Add support for preempt and irq enable/disable events
On Thu, Oct 05, 2017 at 04:28:10PM -0700, Joel Fernandes wrote: > > lockdep implements the trace_hardirq_*() in terms of *_caller(). Would > > that make sense here? > > In lockdep code, when trace_hardirqs_off is called, > trace_hardirqs_off_caller would pass CALLER_ADDR0 as > trace_hardirqs_off. > > Because of this, the first argument passed to time_hardirqs_off would > always be an offset within trace_hardirqs_off: > time_hardirqs_off(CALLER_ADDR0, ip); > > Is that intended? Seems to me that in the lockdep implementation of > trace_hardirqs_* in terms of *_caller(), we would completely miss the > second-last return address (CALLER_ADDR1) of trace_hardirqs_off(). > Also for the above reasons, I don't think it doesn't make sense to use > this reuse logic for the tracer. Atleast I feel it might change the > current behavior of the preempt/irqsoff tracer which I don't intend to > change with my current patch set. Hurm.. so I've no clue. I never looked at any of this. I think Ingo wrote that before I came joined the fun. He might (although unlikely, because its been _many_ years) still have some memories. But given that lockdep enabled kernels never got those arguments right, how useful are they? I mean, nobody seems to have noticed much.
Re: [PATCH v4 08/10] arm64: kexec_file: set up for crash dump adding elf core header
On Thu, Oct 05, 2017 at 03:15:52PM +0100, Julien Thierry wrote:
>
>
> On 02/10/17 07:14, AKASHI Takahiro wrote:
> >load_crashdump_segments() creates and loads a memory segment of elf core
> >header for crash dump.
> >
> >"linux,usable-memory-range" and "linux,elfcorehdr" will add to the 2nd
> >kernel's device-tree blob. The logic of this cod is also from kexec-tools.
> >
> >Signed-off-by: AKASHI Takahiro
> >Cc: Catalin Marinas
> >Cc: Will Deacon
> >---
> > arch/arm64/include/asm/kexec.h | 5 ++
> > arch/arm64/kernel/machine_kexec_file.c | 149
> > +
> > kernel/kexec_file.c| 2 +-
> > 3 files changed, 155 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> >index 2fadd3cbf3af..edb702e64a8a 100644
> >--- a/arch/arm64/include/asm/kexec.h
> >+++ b/arch/arm64/include/asm/kexec.h
> >@@ -98,6 +98,10 @@ static inline void crash_post_resume(void) {}
> > struct kimage_arch {
> > void *dtb_buf;
> >+/* Core ELF header buffer */
> >+void *elf_headers;
> >+unsigned long elf_headers_sz;
> >+unsigned long elf_load_addr;
> > };
> > struct kimage;
> >@@ -113,6 +117,7 @@ extern int load_other_segments(struct kimage *image,
> > unsigned long kernel_load_addr,
> > char *initrd, unsigned long initrd_len,
> > char *cmdline, unsigned long cmdline_len);
> >+extern int load_crashdump_segments(struct kimage *image);
> > #endif
> > #endif /* __ASSEMBLY__ */
> >diff --git a/arch/arm64/kernel/machine_kexec_file.c
> >b/arch/arm64/kernel/machine_kexec_file.c
> >index 8a09d89f6266..1d30b4773af5 100644
> >--- a/arch/arm64/kernel/machine_kexec_file.c
> >+++ b/arch/arm64/kernel/machine_kexec_file.c
> >@@ -32,6 +32,10 @@ int arch_kimage_file_post_load_cleanup(struct kimage
> >*image)
> > vfree(image->arch.dtb_buf);
> > image->arch.dtb_buf = NULL;
> >+vfree(image->arch.elf_headers);
> >+image->arch.elf_headers = NULL;
> >+image->arch.elf_headers_sz = 0;
> >+
> > return _kexec_kernel_post_load_cleanup(image);
> > }
> >@@ -48,6 +52,77 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf, int
> >(*func)(u64, u64, void *))
> > return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
> > }
> >+static int __init arch_kexec_file_init(void)
> >+{
> >+/* Those values are used later on loading the kernel */
> >+__dt_root_addr_cells = dt_root_addr_cells;
> >+__dt_root_size_cells = dt_root_size_cells;
> >+
> >+return 0;
> >+}
> >+late_initcall(arch_kexec_file_init);
> >+
> >+#define FDT_ALIGN(x, a) (((x) + (a) - 1) & ~((a) - 1))
> >+#define FDT_TAGALIGN(x) (FDT_ALIGN((x), FDT_TAGSIZE))
> >+
> >+static int fdt_prop_len(const char *prop_name, int len)
> >+{
> >+return (strlen(prop_name) + 1) +
> >+sizeof(struct fdt_property) +
> >+FDT_TAGALIGN(len);
> >+}
> >+
> >+static bool cells_size_fitted(unsigned long base, unsigned long size)
> >+{
> >+/* if *_cells >= 2, cells can hold 64-bit values anyway */
> >+if ((__dt_root_addr_cells == 1) && (base >= (1ULL << 32)))
> >+return false;
> >+
> >+if ((__dt_root_size_cells == 1) && (size >= (1ULL << 32)))
> >+return false;
> >+
> >+return true;
> >+}
> >+
> >+static void fill_property(void *buf, u64 val64, int cells)
> >+{
> >+u32 val32;
> >+int i;
> >+
> >+if (cells == 1) {
> >+val32 = cpu_to_fdt32((u32)val64);
> >+memcpy(buf, &val32, sizeof(val32));
> >+} else {
> >+for (i = 0; i < (cells * sizeof(u32) - sizeof(u64)); i++)
> >+*(char *)buf++ = 0;
> >+
>
> Should we use memset for this?
Sure.
> >+val64 = cpu_to_fdt64(val64);
> >+memcpy(buf, &val64, sizeof(val64));
> >+}
> >+}
> >+
> >+static int fdt_setprop_range(void *fdt, int nodeoffset, const char *name,
> >+unsigned long addr, unsigned long size)
> >+{
> >+u64 range[2];
>
> Could we just add some BUG/WARN when either __dt_root_addr_cells or
> __dt_root_size_cells is greater than 2?
Since I want to keep this function generic, I will change it to use
vmalloc().
> Both to make sure we have sane values and because it will be easier to debug
> than overwriting things on the stack.
>
> >+void *prop;
> >+size_t buf_size;
> >+int result;
> >+
> >+prop = range;
> >+buf_size = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
> >+
> >+fill_property(prop, addr, __dt_root_addr_cells);
> >+prop += __dt_root_addr_cells * sizeof(u32);
> >+
> >+fill_property(prop, size, __dt_root_size_cells);
> >+prop += __dt_root_size_cells * sizeof(u32);
>
> This is not needed (or at least we aren't doing anything with it).
Sure.
> Apart from that, patch seems fine.
Thank you for reviewing.
-Takahiro AKASHI
> Cheers,
>
> >+
> >+result = fdt_setprop(fdt, nodeoffset, name, range, buf_
Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data
On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > DMA faults can be detected by IOMMU at device level. Adding a pointer > to struct device allows IOMMU subsystem to report relevant faults > back to the device driver for further handling. > For direct assigned device (or user space drivers), guest OS holds > responsibility to handle and respond per device IOMMU fault. > Therefore we need fault reporting mechanism to propagate faults beyond > IOMMU subsystem. We use struct device all over the system, and I don't think we should bloat it for fringe case IOMMU bits. Someone really needs to take a step back and figure out how to move this into a structure that's only allocated for device that actually can do physical DMA (and/or have an iommu attached) This is the 3rd iommu field, in addition to 8 dma-specific fields that we carry around for each struct device.
Re: [PATCH] ARM: dts: stm32: add Timers driver for stm32f746 MCU
2017-10-05 18:06 GMT+02:00 Alexandre Torgue :
> Hi Benjamin,
>
> On 10/04/2017 11:27 AM, Benjamin Gaignard wrote:
>>
>> Add Timers and it sub-nodes into DT for stm32f746 family.
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> arch/arm/boot/dts/stm32f746.dtsi | 270
>> +++
>> 1 file changed, 270 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32f746.dtsi
>> b/arch/arm/boot/dts/stm32f746.dtsi
>> index 4506eb9..ae84816 100644
>> --- a/arch/arm/boot/dts/stm32f746.dtsi
>> +++ b/arch/arm/boot/dts/stm32f746.dtsi
>> @@ -82,6 +82,27 @@
>> status = "disabled";
>> };
>> + timers2: timers@4000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x4000 0x400>;
>> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM2)>;
>> + clock-names = "int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer@1 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <1>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> timer3: timer@4400 {
>> compatible = "st,stm32-timer";
>> reg = <0x4400 0x400>;
>> @@ -90,6 +111,27 @@
>> status = "disabled";
>> };
>> + timers3: timers@4400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x4400 0x400>;
>> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM3)>;
>> + clock-names = "int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer@2 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <2>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> timer4: timer@4800 {
>> compatible = "st,stm32-timer";
>> reg = <0x4800 0x400>;
>> @@ -98,6 +140,27 @@
>> status = "disabled";
>> };
>> + timers4: timers@4800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x4800 0x400>;
>> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM4)>;
>> + clock-names = "int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer@3 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <3>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> timer5: timer@4c00 {
>> compatible = "st,stm32-timer";
>> reg = <0x4c00 0x400>;
>> @@ -105,6 +168,27 @@
>> clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
>> };
>> + timers5: timers@4c00 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x4C00 0x400>;
>> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
>> + clock-names = "int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer@4 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <4>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> timer6: timer@40001000 {
>>
[PATCH v2] ARM: dts: stm32: add Timers driver for stm32f746 MCU
Add Timers and it sub-nodes into DT for stm32f746 family.
Signed-off-by: Benjamin Gaignard
---
version 2:
- without ltdc node
arch/arm/boot/dts/stm32f746.dtsi | 260 +++
1 file changed, 260 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 4506eb9..d0deee2 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -82,6 +82,27 @@
status = "disabled";
};
+ timers2: timers@4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4000 0x400>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM2)>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@1 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <1>;
+ status = "disabled";
+ };
+ };
+
timer3: timer@4400 {
compatible = "st,stm32-timer";
reg = <0x4400 0x400>;
@@ -90,6 +111,27 @@
status = "disabled";
};
+ timers3: timers@4400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4400 0x400>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM3)>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@2 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <2>;
+ status = "disabled";
+ };
+ };
+
timer4: timer@4800 {
compatible = "st,stm32-timer";
reg = <0x4800 0x400>;
@@ -98,6 +140,27 @@
status = "disabled";
};
+ timers4: timers@4800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4800 0x400>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM4)>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@3 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <3>;
+ status = "disabled";
+ };
+ };
+
timer5: timer@4c00 {
compatible = "st,stm32-timer";
reg = <0x4c00 0x400>;
@@ -105,6 +168,27 @@
clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
};
+ timers5: timers@4c00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4C00 0x400>;
+ clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@4 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <4>;
+ status = "disabled";
+ };
+ };
+
timer6: timer@40001000 {
compatible = "st,stm32-timer";
reg = <0x40001000 0x400>;
@@ -113,6 +197,22 @@
status = "disabled";
};
+ timers6: timers@40001000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x40001000 0x400>;
+
[PATCH] infiniband: add MMU dependency for user_mem
The infiniband subsystem causes a link failure when the umem
driver is built on MMU-less systems:
mm/mmu_notifier.o: In function `do_mmu_notifier_register':
mmu_notifier.c:(.text+0x32): undefined reference to `mm_take_all_locks'
drivers/infiniband/core/umem.o: In function `ib_umem_get':
umem.c:(.text+0x132): undefined reference to `can_do_mlock'
drivers/infiniband/core/umem_odp.o: In function `ib_umem_odp_map_dma_pages':
umem_odp.c:(.text+0x766): undefined reference to `get_user_pages_remote'
This bug has existed for a while but only become apparent in ARM
randconfig builds when the dependency on PCI was lifted, as none
of the ARM-NOMMU targets support PCI at the moment.
We could probably get the umem driver to build by providing an
alternative implementation 'can_do_mlock()' that returns false
on NOMMU-systems, but then we'd still have a problem with the
mmu-notifiers required by CONFIG_INFINIBAND_ON_DEMAND_PAGING,
so simply forbidding umem with NOMMU seems like the simplest
workaround.
Fixes: 931bc0d91639 ("IB: Move PCI dependency from root KConfig to HW's
KConfigs")
Signed-off-by: Arnd Bergmann
---
drivers/infiniband/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index b62b3b1e09cd..98ac46ed7214 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -45,6 +45,7 @@ config INFINIBAND_EXP_USER_ACCESS
config INFINIBAND_USER_MEM
bool
depends on INFINIBAND_USER_ACCESS != n
+ depends on MMU
default y
config INFINIBAND_ON_DEMAND_PAGING
--
2.9.0
[PATCH] cpufreq: powernv: Return the actual CPU frequency in /proc/cpuinfo
Make /proc/cpuinfo read the frequency of the CPU it is running at
instead of reading the cached value of the last requested frequency.
In conditions like WOF/throttle CPU can be running at a different
frequency than the requested frequency.
Signed-off-by: Shriya
---
arch/powerpc/platforms/powernv/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 897aa14..55ea4bf 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -311,7 +311,7 @@ static unsigned long pnv_get_proc_freq(unsigned int cpu)
{
unsigned long ret_freq;
- ret_freq = cpufreq_quick_get(cpu) * 1000ul;
+ ret_freq = cpufreq_get(cpu) * 1000ul;
/*
* If the backend cpufreq driver does not exist,
--
1.9.1
Re: [PATCH v7 2/2] tracing: Add support for preempt and irq enable/disable events
Hi Peter, On Fri, Oct 6, 2017 at 12:07 AM, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 04:28:10PM -0700, Joel Fernandes wrote: >> > lockdep implements the trace_hardirq_*() in terms of *_caller(). Would >> > that make sense here? >> >> In lockdep code, when trace_hardirqs_off is called, >> trace_hardirqs_off_caller would pass CALLER_ADDR0 as >> trace_hardirqs_off. >> >> Because of this, the first argument passed to time_hardirqs_off would >> always be an offset within trace_hardirqs_off: >> time_hardirqs_off(CALLER_ADDR0, ip); >> >> Is that intended? Seems to me that in the lockdep implementation of >> trace_hardirqs_* in terms of *_caller(), we would completely miss the >> second-last return address (CALLER_ADDR1) of trace_hardirqs_off(). >> Also for the above reasons, I don't think it doesn't make sense to use >> this reuse logic for the tracer. Atleast I feel it might change the >> current behavior of the preempt/irqsoff tracer which I don't intend to >> change with my current patch set. > > Hurm.. so I've no clue. I never looked at any of this. I think Ingo > wrote that before I came joined the fun. He might (although unlikely, > because its been _many_ years) still have some memories. > > But given that lockdep enabled kernels never got those arguments right, > how useful are they? I mean, nobody seems to have noticed much. Oh ok. So I traced this down to the original patch that added time_hardirqs_off to lockdep. I *think* it was added just to keep the irqsoff tracer working while lockdep is enabled, so that both lockdep and the tracer would work at the same time. So I guess nobody noticed any issues because nobody noticed or cared to check if irqsoff tracer showed the same results with lockdep enabled vs disabled. I think the correct way this should be rewritten is lockdep should use register_trace_* to register callbacks onto the new tracepoints I'm adding. I am working on a patch that does something like this and gets rid of the time_* functions. I will try to have an RFC out by the weekend if I hopefully don't hit any roadblocks. thanks! - Joel
Re: Questions about bluetooth on N900
Hi!
> > > > There is some interest. I'd like to have working bluetooth, and people
> > > from postmarketos
> > > > would probably like something, too. Unfortunately my experience is
> > > same as yours -- current
> > > > mainline does not work well on N900.
> > >
> > > I might try debugging that at some point, but I doubt I can resolve the
> > > issue,
> > > because I have no experience in serial port programming. With latest
> > > BlueZ I
> > > got my braille display working for few seconds, before it stalled.
> > >
> > > > > I'm considering to rebase the old hci_h4p driver on current
> > > mainline, because
> > > > > I just need a working BT connection, not code that is of good
> > > quality. Some
> > >
> > > > Ok, I may save you some work. I have rebased version, it should be in
> > > > linux-n900 on kernel.org.
> > >
> > > I found a repo from
> > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/pavel/linux-n900/.
> > > I
> > > assume that's what you meant.
> > >
> > > The latest version is based on 4.13, but it has also some changes which
> > > seem
> > > not to be related to BT. I incorporated them also, but I don't know if
> > > they
> > > are valid.
> >
> > Feel free to take those or not.
> >
> > > I was lucky that you had done rebasing of nokia_h4p, because I wouldn't
> > > have
> > > known what to do with DTS.
> > >
> > > Unfortunately the driver does not work properly. I can access N900 to some
> > > extent with my braille display, but the connection has random freezes, and
> > > accessing my GPS receiver (through RFCOMM) causes the whole system to
> > > hang.
> > >
> > > I get the following message to syslog something like 100 times per second
> > > when
> > > BRLTTY (the braille display daemon) is communicating with the display:
> > > Got IIR_RX_TIMEOUT, handling it as IIR_DRI
> > >
> > > Active BT connection also seems to trigger a bug in nokia_h4p related to
> > > spinlocks. This happens in random intervals between 0.1 s and 30 s.
> > >
> > > The bugs are:
> > > BUG: scheduling while atomic
> > > and
> > > BUG: workqueue leaked lock or atomic
> > >
> > > Stack traces suggest that it is (at least sometimes) caused by h4p_set_clk
> > > calling clk_prepare_enable and clk_disable_unprepare functions, which
> > > should
> > > only be used in non-atomic context.
> > >
> > > So, I thought it would be good for you to know that BT does not really
> > > work. I
> > > would like to work on this, but I'm afraid my knowledge is too limited to
> > > track this down. It would be good to know what is causing those IIR RX
> > > timeouts.
> > >
> > > Also working on an obsolete driver feels like stupid now that there is a
> > > driver written more properly.
> >
> > Yes, fixing obsolete driver is hard and has drawbacks. The new one
> > should be fixed.
> >
> > I believe the way forward would be
> >
> > a) add logging to the old driver, to see exact data being exchanged
> > during initialization.
> >
> > b) add logging to the new driver, and compare old and new driver
> >
> > c) fix the new driver to do the initialization same way the old driver
> > did
>
> FWIW I don't think the problem on N900 with hci_nokia ("new") driver is
> related to incorrect data/packets being sent. I'm pretty sure there is
> still some problem with the handling of flow control signals (RTS/CTS +
> the GPIOs) resulting in packets not being sent and/or received properly.
Yes, that's possible. So logging RTS/CTS + gpio transitions along with
data will be useful.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [Xen-devel] [PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
Josh Poimboeuf writes: > - For the most common runtime cases (everything except Xen and vSMP), > vmlinux disassembly now matches what the actual runtime code looks > like. This improves debuggability and kernel developer sanity (a > precious resource). > > ... > > - It's hopefully a first step in simplifying paravirt patching by > getting rid of .parainstructions, pv ops, and apply_paravirt() > completely. (I think Xen can be changed to set CPU feature bits to > specify which ops it needs during early boot, then those ops can be > patched in using early alternatives.) JFYI starting 4.14 Xen PV is not the only user of pv_mmu_ops, Hyper-V uses it for TLB shootdown now. -- Vitaly
Re: Draft manpage explaining kernel lockdown
Hi David, On Thu, Oct 05, 2017 at 12:00:24PM +0100, David Howells wrote: > Hi Ard, Michael, > > Attached is a draft for a manual page (kernel_lockdown.7) that I intend to > point at from messages emitted when the kernel prohibits something because the > kernel is in 'lockdown' mode, typically triggered by EFI secure boot. > > Let me know what you think. > > David > --- [...snip] > When lockdown is in effect, a number of things are disabled or restricted in > use. This includes special device files and kernel services that allow direct > access of the kernel image: > .P > .RS > /dev/mem > .br > /dev/kmem > .br > /dev/kcore > .br > /dev/ioports > .br > BPF memory access functions Some information for note... The BPF functions bpf_probe_read(), bpf_trace_printk() and bpf_probe_write_user() need to be lockdown to avoid accessing arbitrary addess. Our original idea is trying to filter out senstivie data address at runtime by eBPF verifier. But it can not be success. Gary Lin has investigated and comment: Although eBPF verifier can stop the reading from the hard-coded address, it's not able to stop reading arguments in the probed functions. So if the malicious user attaches a eBPF program to a function that is used to process the sensitive data, the eBPF program can print those arguments easily and this might leak the passwords or private keys. If we readlly want to allow eBPF code to access memory, then I think that the bpf bytecode should be signed by trused key in system keyring. > .RE > .P Another function may needs to be restrictred: - The perf_event_open() with PERF_SAMPLE_REGS_INTR Jann Horn raised this concern. The tool can be used to grab register to peep sensitive data. We may need to block this tracing function. Regards Joey Lee
Re: [Xen-devel] KVM PV
2017-10-03 3:11 GMT+08:00 Nadav Amit : > Paolo Bonzini wrote: > >> On 02/10/2017 12:36, George Dunlap wrote: > Although I'm not business man, I don't think the top cloud provider[s] > would allow nested virtualization, however mature nested virtualization > is. Even xen-pv is unable to be nested in the aws and azure. Check the contributors to KVM nested virtualization, you might be surprised. Nested Xen PV is not possible because the Xen hypervisor cannot run as a PV guest.>> It's a technical limitation. >>> >>> Minor correction: Xen can't run on AWS as a PV guest, but it can run >>> as an L1 hypervisor inside any "fully virtualized" VM (as both AWS and >>> Azure provide), and provide PV L2 guests. >> >> Yes, that's what I meant. >> >> Thanks George! > > BTW: If anyone missed, Google already announced that they started supporting > nested virtualization. > > https://cloudplatform.googleblog.com/2017/09/introducing-nested-virtualization-for.html Awesome! Regards, Wanpeng Li
Re: [PATCH] epoll: account epitem and eppoll_entry to kmemcg
On Thu 05-10-17 10:21:18, Michal Hocko wrote: > On Wed 04-10-17 12:33:14, Shakeel Butt wrote: > > > > > > I am not objecting to the patch I would just like to understand the > > > runaway case. ep_insert seems to limit the maximum number of watches to > > > max_user_watches which should be ~4% of lowmem if I am following the > > > code properly. pwq_cache should be bound by the number of watches as > > > well, or am I misunderstanding the code? > > > > > > > You are absolutely right that there is a per-user limit (~4% of total > > memory if no highmem) on these caches. I think it is too generous > > particularly in the scenario where jobs of multiple users are running > > on the system and the administrator is reducing cost by overcomitting > > the memory. This is unaccounted kernel memory and will not be > > considered by the oom-killer. I think by accounting it to kmemcg, for > > systems with kmem accounting enabled, we can provide better isolation > > between jobs of different users. > > Thanks for the clarification. For some reason I didn't figure that the > limit is per user, even though the name suggests so. Completely forgot to add Acked-by: Michal Hocko -- Michal Hocko SUSE Labs
Re: [PATCH] HID: usbhid: Convert timers to use timer_setup()
On Oct 04 2017 or thereabouts, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Adds pointer back to hid_device for
> multitouch.
>
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: linux-in...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Thomas Gleixner
> Signed-off-by: Kees Cook
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.
Looks good to me:
Reviewed-by: Benjamin Tissoires
Selfish request: Jiri can you add the dependency about 686fef928bba in
the commit message too? I am just preparing in case I need to backport
this in RHEL, and having the dep explicitly mentioned would save me a
little bit of extra time :)
(if not, no worries)
Cheers,
Benjamin
> ---
> drivers/hid/hid-multitouch.c | 10 ++
> drivers/hid/usbhid/hid-core.c | 8
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..b0e3e2614b18 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -112,6 +112,7 @@ struct mt_device {
> struct mt_slot curdata; /* placeholder of incoming data */
> struct mt_class mtclass;/* our mt device class */
> struct timer_list release_timer;/* to release sticky fingers */
> + struct hid_device *hdev;/* hid_device we're attached to */
> struct mt_fields *fields; /* temporary placeholder for storing the
> multitouch fields */
> unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */
> @@ -1245,10 +1246,10 @@ static void mt_release_contacts(struct hid_device
> *hid)
> td->num_received = 0;
> }
>
> -static void mt_expired_timeout(unsigned long arg)
> +static void mt_expired_timeout(struct timer_list *t)
> {
> - struct hid_device *hdev = (void *)arg;
> - struct mt_device *td = hid_get_drvdata(hdev);
> + struct mt_device *td = from_timer(td, t, release_timer);
> + struct hid_device *hdev = td->hdev;
>
> /*
>* An input report came in just before we release the sticky fingers,
> @@ -1279,6 +1280,7 @@ static int mt_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> dev_err(&hdev->dev, "cannot allocate multitouch data\n");
> return -ENOMEM;
> }
> + td->hdev = hdev;
> td->mtclass = *mtclass;
> td->inputmode = -1;
> td->maxcontact_report_id = -1;
> @@ -1330,7 +1332,7 @@ static int mt_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
>*/
> hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
>
> - setup_timer(&td->release_timer, mt_expired_timeout, (long)hdev);
> + timer_setup(&td->release_timer, mt_expired_timeout, 0);
>
> ret = hid_parse(hdev);
> if (ret != 0)
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 089bad8a9a21..9f9fe0e58f5b 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -101,10 +101,10 @@ static int hid_start_in(struct hid_device *hid)
> }
>
> /* I/O retry timer routine */
> -static void hid_retry_timeout(unsigned long _hid)
> +static void hid_retry_timeout(struct timer_list *t)
> {
> - struct hid_device *hid = (struct hid_device *) _hid;
> - struct usbhid_device *usbhid = hid->driver_data;
> + struct usbhid_device *usbhid = from_timer(usbhid, t, io_retry);
> + struct hid_device *hid = usbhid->hid;
>
> dev_dbg(&usbhid->intf->dev, "retrying intr urb\n");
> if (hid_start_in(hid))
> @@ -1363,7 +1363,7 @@ static int usbhid_probe(struct usb_interface *intf,
> const struct usb_device_id *
>
> init_waitqueue_head(&usbhid->wait);
> INIT_WORK(&usbhid->reset_work, hid_reset);
> - setup_timer(&usbhid->io_retry, hid_retry_timeout, (unsigned long) hid);
> + timer_setup(&usbhid->io_retry, hid_retry_timeout, 0);
> spin_lock_init(&usbhid->lock);
>
> ret = hid_add_device(hid);
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
Re: [PATCH] kvm, mm: account kvm related kmem slabs to kmemcg
On Fri 06-10-17 09:58:30, Anshuman Khandual wrote:
> On 10/06/2017 06:37 AM, Shakeel Butt wrote:
> > The kvm slabs can consume a significant amount of system memory
> > and indeed in our production environment we have observed that
> > a lot of machines are spending significant amount of memory that
> > can not be left as system memory overhead. Also the allocations
> > from these slabs can be triggered directly by user space applications
> > which has access to kvm and thus a buggy application can leak
> > such memory. So, these caches should be accounted to kmemcg.
>
> But there may be other situations like this where user space can
> trigger allocation from various SLAB objects inside the kernel
> which are accounted as system memory. So how we draw the line
> which ones should be accounted for memcg. Just being curious.
The thing is that we used to have an opt-out approach for kmem
accounting but we decided to go opt-in in a9bb7e620efd ("memcg: only
account kmem allocations marked as __GFP_ACCOUNT").
Since then we are adding the flag to caches/allocations which can go
wild and consume a lot of or even unbounded amount of memory.
--
Michal Hocko
SUSE Labs
Re: [PATCH v1] i2c:i2c-stm32f7: fix setup structure
On 10/05/2017 01:14 PM, Wolfram Sang wrote: > On Thu, Sep 21, 2017 at 03:30:09PM +0200, Pierre-Yves MORDRET wrote: >> I2C drive setup structure is not properly allocated. >> Make it static instead of pointer to store driver data. >> >> Signed-off-by: Pierre-Yves MORDRET > > Ouch! How did it work before? Well yes it did. When it has been discovered during internal code review I was skeptical but it turned out to be true. I tested on STM32 F7/H7 without any trouble : scary ! > > Applied to for-current, thanks! Please provide a Fixes: tag next time, > did this for you now. > Sorry I wasn't aware about that. I gonna remember for the next time. Thanks ! Py
Re: [PATCH] fs, mm: account filp and names caches to kmemcg
On Thu 05-10-17 15:21:44, Shakeel Butt wrote:
> The allocations from filp and names kmem caches can be directly
> triggered by user space applications. A buggy application can
> consume a significant amount of unaccounted system memory. Though
> we have not noticed such buggy applications in our production
> but upon close inspection, we found that a lot of machines spend
> very significant amount of memory on these caches. So, these
> caches should be accounted to kmemcg.
>
> Signed-off-by: Shakeel Butt
> ---
> fs/dcache.c | 2 +-
> fs/file_table.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index f90141387f01..fb3449161063 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -3642,7 +3642,7 @@ void __init vfs_caches_init_early(void)
> void __init vfs_caches_init(void)
> {
> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0,
> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
I might be wrong but isn't name cache only holding temporary objects
used for path resolution which are not stored anywhere?
>
> dcache_init();
> inode_init();
> diff --git a/fs/file_table.c b/fs/file_table.c
> index 61517f57f8ef..567888cdf7d3 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -312,7 +312,7 @@ void put_filp(struct file *file)
> void __init files_init(void)
> {
> filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
> - SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
> + SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL);
> percpu_counter_init(&nr_files, 0, GFP_KERNEL);
> }
Don't we have a limit for the maximum number of open files?
--
Michal Hocko
SUSE Labs
Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec
On Thu, Oct 05, 2017 at 03:39:29PM -0300, Mauro Carvalho Chehab wrote: > Em Thu, 5 Oct 2017 11:21:07 +0300 > Sakari Ailus escreveu: > > > Hi Mauro, > > > > My apologies for the late reply. > > > > On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote: > > > Em Tue, 29 Aug 2017 10:47:48 +0300 > > > Sakari Ailus escreveu: > > > > > > > Hi Mauro, > > > > > > > > Thanks for the update. A few comments below. > > > > > > > > On Mon, Aug 28, 2017 at 09:53:55AM -0300, Mauro Carvalho Chehab wrote: > > > > > Add a glossary of terms for V4L2, as several concepts are complex > > > > > enough to cause misunderstandings. > > > > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > --- > > > > > Documentation/media/uapi/v4l/glossary.rst | 147 > > > > > ++ > > > > > Documentation/media/uapi/v4l/v4l2.rst | 1 + > > > > > 2 files changed, 148 insertions(+) > > > > > create mode 100644 Documentation/media/uapi/v4l/glossary.rst > > > > > > > > > > diff --git a/Documentation/media/uapi/v4l/glossary.rst > > > > > b/Documentation/media/uapi/v4l/glossary.rst > > > > > new file mode 100644 > > > > > index ..0b6ab5adec81 > > > > > --- /dev/null > > > > > +++ b/Documentation/media/uapi/v4l/glossary.rst > > > > > @@ -0,0 +1,147 @@ > > > > > + > > > > > +Glossary > > > > > + > > > > > + > > > > > +.. note:: > > > > > + > > > > > + This goal of section is to standardize the terms used within the > > > > > V4L2 > > > > > + documentation. It is written incrementally as they are > > > > > standardized in > > > > > + the V4L2 documentation. So, it is a Work In Progress. > > > > > > > > I'd leave the WiP part out. > > > > > > IMO, it is important to mention it, as the glossary, right now, covers > > > only what's used on the first two sections of the API book. There are > > > a lot more to be covered. > > > > Works for me. > > > > > > > > > > > > > > + > > > > > +.. Please keep the glossary entries in alphabetical order > > > > > + > > > > > +.. glossary:: > > > > > + > > > > > +Bridge driver > > > > > + The same as V4L2 main driver. > > > > > > > > I've understood bridges being essentially a bus receiver + DMA. Most > > > > ISPs > > > > contain both but have more than that. How about: > > > > > > > > A driver for a bus (e.g. parallel, CSI-2) receiver and DMA. Bridge > > > > drivers > > > > typically act as V4L2 main drivers. > > > > > > No, only on some drivers the bridge driver has DMA. A vast amount of > > > drivers (USB ones) don't implement any DMA inside the driver, as it is > > > up to the USB host driver to implement support for DMA. > > > > > > There are even some USB host drivers that don't always use DMA for I/O > > > transfers, using direct I/O if the message is smaller than a threshold > > > or not multiple of the bus word. This is pretty common on SoC USB host > > > drivers. > > > > > > In any case, for the effect of this spec, and for all discussions we > > > ever had about it, bridge driver == V4L2 main driver. I don't > > > see any reason why to distinguish between them. > > > > I think you should precisely define what a bridge driver means. Generally > > ISP drivers aren't referred to as bridge drivers albeit they, too, function > > as V4L2 main drivers. > > Btw, this is already defined, currently, at v4l2-subdev.h: > > * Sub-devices are devices that are connected somehow to the main bridge > * device. These devices are usually audio/video muxers/encoders/decoders or > * sensors and webcam controllers. > * > * Usually these devices are controlled through an i2c bus, but other busses > * may also be used. > > Please notice that there it says: "main bridge" :-) > > Such definition was added since the beginning of the subdev concept, back in > 2008 and was reviewed by several V4L core developers: A lot has happened since 2008. :-) Anyway, I'll review the latest set. -- Sakari Ailus e-mail: sakari.ai...@iki.fi
[PATCH] Bugfix perf script -F ip,brstack (and brstackoff)
Prior to commit 55b9b50811ca ("perf script: Support -F brstack,dso and
brstacksym,dso"), we were printing a space before the brstack data. It
seems that this space was important. Without it, parsing is difficult.
Very sorry for the mistake.
Notice here how the "ip" and "brstack" run together:
$ perf script -F ip,brstack | head -n 1
22e18c40x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0
0x22e195d/0x22e1990/P/-/-/0 0x22e18e9/0x22e1943/P/-/-/0
0x22e1a69/0x22e18c0/P/-/-/0 0x22e19f7/0x22e1a20/P/-/-/0
0x22e1910/0x22e19ee/P/-/-/0 0x22e19e2/0x22e190b/P/-/-/0
0x22e19a1/0x22e19d0/P/-/-/0 0x22e195d/0x22e1990/P/-/-/0
0x22e18e9/0x22e1943/P/-/-/0 0x22e1a69/0x22e18c0/P/-/-/0
0x22e19f7/0x22e1a20/P/-/-/0 0x22e1910/0x22e19ee/P/-/-/0
0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0
After this diff, sanity is restored:
$ perf script -F ip,brstack | head -n 1
22e18c4 0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0
0x22e195d/0x22e1990/P/-/-/0 0x22e18e9/0x22e1943/P/-/-/0
0x22e1a69/0x22e18c0/P/-/-/0 0x22e19f7/0x22e1a20/P/-/-/0
0x22e1910/0x22e19ee/P/-/-/0 0x22e19e2/0x22e190b/P/-/-/0
0x22e19a1/0x22e19d0/P/-/-/0 0x22e195d/0x22e1990/P/-/-/0
0x22e18e9/0x22e1943/P/-/-/0 0x22e1a69/0x22e18c0/P/-/-/0
0x22e19f7/0x22e1a20/P/-/-/0 0x22e1910/0x22e19ee/P/-/-/0
0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0
Signed-off-by: Mark Santaniello
---
tools/perf/builtin-script.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 3d4c3b5..0c977b6 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -586,7 +586,7 @@ static void print_sample_brstack(struct perf_sample *sample,
thread__find_addr_map(thread, sample->cpumode,
MAP__FUNCTION, to, &alt);
}
- printf("0x%"PRIx64, from);
+ printf(" 0x%"PRIx64, from);
if (PRINT_FIELD(DSO)) {
printf("(");
map__fprintf_dsoname(alf.map, stdout);
@@ -681,7 +681,7 @@ static void print_sample_brstackoff(struct perf_sample
*sample,
if (alt.map && !alt.map->dso->adjust_symbols)
to = map__map_ip(alt.map, to);
- printf("0x%"PRIx64, from);
+ printf(" 0x%"PRIx64, from);
if (PRINT_FIELD(DSO)) {
printf("(");
map__fprintf_dsoname(alf.map, stdout);
--
2.9.5
[PATCH v2] arm64: dts: mediatek: Add cpuidle support for MT2712
Add CPU idle state nodes to enable C1/C2 idle states.
Signed-off-by: James Liao
---
changes since v1:
- Rebase to 4.14-rc1.
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 57d0396..5d4e406 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -39,6 +39,7 @@
device_type = "cpu";
compatible = "arm,cortex-a35";
reg = <0x000>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
};
cpu1: cpu@1 {
@@ -46,6 +47,7 @@
compatible = "arm,cortex-a35";
reg = <0x001>;
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
};
cpu2: cpu@200 {
@@ -53,6 +55,29 @@
compatible = "arm,cortex-a72";
reg = <0x200>;
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ };
+
+ idle-states {
+ entry-method = "arm,psci";
+
+ CPU_SLEEP_0: cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ entry-latency-us = <100>;
+ exit-latency-us = <80>;
+ min-residency-us = <2000>;
+ arm,psci-suspend-param = <0x001>;
+ };
+
+ CLUSTER_SLEEP_0: cluster-sleep-0 {
+ compatible = "arm,idle-state";
+ local-timer-stop;
+ entry-latency-us = <350>;
+ exit-latency-us = <80>;
+ min-residency-us = <3000>;
+ arm,psci-suspend-param = <0x101>;
+ };
};
};
--
1.9.1
Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support
On 02/10/17 11:32, Ulf Hansson wrote: > On 22 September 2017 at 14:37, Adrian Hunter wrote: >> Add CQE support to the block driver, including: >> - optionally using DCMD for flush requests >> - "manually" issuing discard requests >> - issuing read / write requests to the CQE >> - supporting block-layer timeouts >> - handling recovery >> - supporting re-tuning >> >> CQE offers 25% - 50% better random multi-threaded I/O. There is a slight >> (e.g. 2%) drop in sequential read speed but no observable change to >> sequential >> write. >> >> CQE automatically sends the commands to complete requests. However it only >> supports reads / writes and so-called "direct commands" (DCMD). Furthermore >> DCMD is limited to one command at a time, but discards require 3 commands. >> That makes issuing discards through CQE very awkward, but some CQE's don't >> support DCMD anyway. So for discards, the existing non-CQE approach is >> taken, where the mmc core code issues the 3 commands one at a time i.e. >> mmc_erase(). Where DCMD is used, is for issuing flushes. >> >> For host controllers without CQE support, blk-mq support is extended to >> synchronous reads/writes or, if the host supports CAP_WAIT_WHILE_BUSY, >> asynchonous reads/writes. The advantage of asynchronous reads/writes is >> that it allows the preparation of the next request while the current >> request is in progress. >> >> Signed-off-by: Adrian Hunter >> --- >> drivers/mmc/core/block.c | 732 >> ++- >> drivers/mmc/core/block.h | 8 + >> drivers/mmc/core/queue.c | 427 +-- >> drivers/mmc/core/queue.h | 54 +++- >> 4 files changed, 1189 insertions(+), 32 deletions(-) > > I have re-started to review this change now, however as stated earlier > - the total number changes really doesn't make this easy to review. > > Until I am done, I have published a new cmdq_v9 branch via my mmc tree. Have you done any more testing?
Re: [PATCH review for 4.4 12/47] clk: wm831x: fix usleep_range with bad range
On Sun, Sep 24, 2017 at 12:18:12AM +, Levin, Alexander (Sasha Levin) wrote:
> On Fri, Sep 22, 2017 at 09:46:28AM +0100, Charles Keepax wrote:
> >On Wed, Sep 20, 2017 at 04:45:02AM +, Levin, Alexander (Sasha Levin)
> >wrote:
> >> From: Nicholas Mc Guire
> >>
> >> [ Upstream commit ed784c532a3d0959db488f40a96c5127f63d42dc ]
> >>
> >> The delay here is not in atomic context and does not seem critical with
> >> respect to precision, but usleep_range(min,max) with min==max results in
> >> giving the timer subsystem no room to optimize uncritical delays. Fix
> >> this by setting the range to 2000,3000 us.
> >>
> >> Fixes: commit f05259a6ffa4 ("clk: wm831x: Add initial WM831x clock driver")
> >> Signed-off-by: Nicholas Mc Guire
> >> Acked-by: Charles Keepax
> >> Signed-off-by: Stephen Boyd
> >> Signed-off-by: Sasha Levin
> >> ---
> >> drivers/clk/clk-wm831x.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c
> >> index 763aed2de893..dfedcf5bc429 100644
> >> --- a/drivers/clk/clk-wm831x.c
> >> +++ b/drivers/clk/clk-wm831x.c
> >> @@ -101,7 +101,8 @@ static int wm831x_fll_prepare(struct clk_hw *hw)
> >>if (ret != 0)
> >>dev_crit(wm831x->dev, "Failed to enable FLL: %d\n", ret);
> >>
> >> - usleep_range(2000, 2000);
> >> + /* wait 2-3 ms for new frequency taking effect */
> >> + usleep_range(2000, 3000);
> >
> >Does this patch really make sense for stable, isn't this really
> >just a small optimisation? The patch is pretty harmless so I
> >can't see applying it causing any problems, just curious what
> >problems not having it is causing.
>
> Looking back at this, I think I misunderstood a scenario in the scheduler
> this might be causing. What you say makes sense, I'll drop it.
>
sorry for the delay - was off-line.
The motivation is that if usleep_range is used with min==max
then it allows no consolidation of highresolution timers at all
but as this is not an atomic code-section anyway it is not sensible
to force a precise timer - the pach relaxes the timing so that
the highrestimers load can be reduced.
Technically this should have no effect at all as the jitter of
the system is probably a lot higher than the range given anyway
but the range allows optimization of highresolution timers.
So basically you are right its an optimization only but it is not
only relevant to keep the highrestimers well optimized it is also
the recommendation in the kernel documentation and since there is
not drawback with this optimization I think it should be considered even
if it is not important.
thx!
hofrat
Re: [PATCH v3] HID: hid-multitouch: support fine-grain orientation reporting
Hi,
On Oct 05 2017 or thereabouts, Jiri Kosina wrote:
>
> [ adding Benjamin to CC ]
>
> On Thu, 28 Sep 2017, Wei-Ning Huang wrote:
>
> > The current hid-multitouch driver only allow the report of two
> > orientations, vertical and horizontal. We use the Azimuth orientation
> > usage 0x3F under the Digitizer usage page to report orientation if the
> > device supports it.
> >
> > Changelog:
> > v1 -> v2:
> >- Fix commit message.
> >- Remove resolution reporting for ABS_MT_ORIENTATION.
> > v2 -> v3:
> >- Fix commit message.
> >
> > Signed-off-by: Wei-Ning Huang
> > Reviewed-by: Dmitry Torokhov
> > ---
> > drivers/hid/hid-multitouch.c | 35 +--
> > include/linux/hid.h | 1 +
> > 2 files changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 440b999304a5..f9801d1b1eae 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -84,11 +84,12 @@ MODULE_LICENSE("GPL");
> > #define MT_IO_FLAGS_PENDING_SLOTS 2
> >
> > struct mt_slot {
> > - __s32 x, y, cx, cy, p, w, h;
> > + __s32 x, y, cx, cy, p, w, h, a;
> > __s32 contactid;/* the device ContactID assigned to this slot */
> > bool touch_state; /* is the touch valid? */
> > bool inrange_state; /* is the finger in proximity of the sensor? */
> > bool confidence_state; /* is the touch made by a finger? */
> > + bool has_azimuth; /* the contact reports azimuth */
> > };
> >
> > struct mt_class {
> > @@ -591,6 +592,20 @@ static int mt_touch_input_mapping(struct hid_device
> > *hdev, struct hid_input *hi,
> > td->cc_index = field->index;
> > td->cc_value_index = usage->usage_index;
> > return 1;
> > + case HID_DG_AZIMUTH:
> > + hid_map_usage(hi, usage, bit, max,
> > + EV_ABS, ABS_MT_ORIENTATION);
> > + /*
> > +* Azimuth has the range of [0, MAX) representing a full
> > +* revolution. Set ABS_MT_ORIENTATION to a quarter of
> > +* MAX according the definition of ABS_MT_ORIENTATION
> > +*/
> > + input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
> > + 0, field->logical_maximum / 4,
Shouldn't this be "-field->logical_maximum / 4, field->logical_maximum / 4,"?
Also, if HID_DG_HEIGHT is seen after HID_DG_AZIMUTH, it'll change the
ABS_MT_ORIENTATION you just set here.
> > + cls->sn_move ?
> > + field->logical_maximum / cls->sn_move : 0, 0);
> > + mt_store_field(usage, td, hi);
> > + return 1;
> > case HID_DG_CONTACTMAX:
> > /* we don't set td->last_slot_field as contactcount and
> > * contact max are global to the report */
> > @@ -683,6 +698,10 @@ static void mt_complete_slot(struct mt_device *td,
> > struct input_dev *input)
> > int wide = (s->w > s->h);
> > int major = max(s->w, s->h);
> > int minor = min(s->w, s->h);
> > + int orientation = wide;
> > +
> > + if (s->has_azimuth)
> > + orientation = s->a;
> >
> > /*
> > * divided by two to match visual scale of touch
> > @@ -699,7 +718,8 @@ static void mt_complete_slot(struct mt_device *td,
> > struct input_dev *input)
> > input_event(input, EV_ABS, ABS_MT_TOOL_Y, s->cy);
> > input_event(input, EV_ABS, ABS_MT_DISTANCE,
> > !s->touch_state);
> > - input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
> > + input_event(input, EV_ABS, ABS_MT_ORIENTATION,
> > + orientation);
> > input_event(input, EV_ABS, ABS_MT_PRESSURE, s->p);
> > input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major);
> > input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor);
> > @@ -789,6 +809,17 @@ static void mt_process_mt_event(struct hid_device
> > *hid, struct hid_field *field,
> > break;
> > case HID_DG_CONTACTCOUNT:
> > break;
> > + case HID_DG_AZIMUTH:
> > + /*
> > +* Azimuth is counter-clockwise and ranges from [0, MAX)
> > +* (a full revolution). Convert it to clockwise ranging
> > +* [-MAX/2, MAX/2].
It took me a while to get this right. The problem is the definition of
ABS_MT_ORIENTATION says that we report [-MAX/4, MAX/4], *but* we can go
out of range to [-MAX/2, MAX/2] to report upside down ellipsis.
So this is correct, but I'd lik
Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec
Hi Mauro, On Thu, Oct 05, 2017 at 09:26:51AM -0300, Mauro Carvalho Chehab wrote: > > > > > + > > > > > + See :ref:`media_controller`. > > > > > + > > > > > +MC-centric > > > > > + V4L2 hardware that requires a Media controller. > > > > > + > > > > > + See :ref:`v4l2_hardware_control`. > > > > > + > > > > > +Microprocessor > > > > > + An electronic circuitry that carries out the instructions > > > > > + of a computer program by performing the basic arithmetic, > > > > > logical, > > > > > + control and input/output (I/O) operations specified by the > > > > > + instructions on a single integrated circuit. > > > > > + > > > > > +SMBus > > > > > + A subset of I²C, with defines a stricter usage of the bus. > > > > > + > > > > > +Serial Peripheral Interface Bus - SPI > > > > > > > > We don't have "Bus" in I²C, I'd leave it out here, too. > > > > > > I2C is a serial bus (and it is implemented as a bus inside the Kernel). > > > Take a look at Documentation/i2c/summary. > > > > I don't disagree with that, but at the same time this is not related to my > > suggestion. > > > > "Bus" is not part of the abbreviation SPI, therefore we should not suggest > > that here. > > Ah, so you proposal here is just to replace: > > Serial Peripheral Interface Bus - SPI > > To > Serial Peripheral Interface - SPI > > Right? If so, it sounds OK. Yes, please. That's exactly what I had in mind. ... > > > > > +V4L2 hardware > > > > > + A hardware used to on a media device supported by the V4L2 > > > > > + subsystem. > > > > > + > > > > > +V4L2 hardware control > > > > > + The type of hardware control that a device supports. > > > > > + > > > > > + See :ref:`v4l2_hardware_control`. > > > > > + > > > > > +V4L2 main driver > > > > > + The V4L2 device driver that implements the main logic to talk > > > > > with > > > > > + the V4L2 hardware. > > > > > + > > > > > + Also known as bridge driver. > > > > > > > > Is UVC driver a bridge driver? How about instead: > > > > > > Yes, sure: UVC driver is a bridge driver/main driver. It is the UVC driver > > > that sends/receives data from the USB bus and send to the sensors. > > > It also sends data via URB to the USB host driver, with, in turn send it > > > to send to CPU (usually via DMA - although some USB drivers actually > > > implement direct I/O for short messages). > > > > > > > Bridge and ISP drivers typically are V4L2 main drivers. > > > > > > We don't have a concept of an "ISP driver". Adding it sounds very > > > > I think we do have that roughly as much as we do have bridge driver. We > > definitely also support devices that are called ISPs, therefore we do have > > ISP drivers. > > We have drivers for things implemented via ISP. However, right now, > there's no distinction at the driver if the functionality is implemented > on software (ISP) or in hardware. > > > > > > confusing, as an ISP hardware may actually implement different > > > functions - so it ends by being supported by multiple drivers. > > > > Typically ISPs are controlled by a single driver as the sub-blocks in an > > ISP usually can only be found in that very ISP. > > I'm almost sure that this is not true for Exynos drivers. There are > m2m drivers and normal drivers for the same ISP (doing different things, > like format conversion, scaling, etc). I don't know the Exynos hardware. There are exceptions but they tend to be increasingly rare as extra memory hops hurt performance and increase power consumption in common use cases. If there is a split to multiple devices, then usually the first device is CSI-2 receiver plus DMA (bridge) and the second is the ISP (i.e. where the processing happens). -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi
Re: [PATCH 1/2] sched/rt: Add a helper to test for a RT task
On Wed, Oct 04, 2017 at 05:49:00PM +0200, Sebastian Andrzej Siewior wrote:
> This helper returns true if a task has elevated priority which is true
> for RT tasks (SCHED_RR and SCHED_FIFO) and also for SCHED_DEADLINE.
> A task which runs at RT priority due to PI-boosting is not considered as
> one with elevated priority.
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> include/linux/sched/rt.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/sched/rt.h b/include/linux/sched/rt.h
> index f93329aba31a..30a86b8178f8 100644
> --- a/include/linux/sched/rt.h
> +++ b/include/linux/sched/rt.h
> @@ -17,6 +17,17 @@ static inline int rt_task(struct task_struct *p)
> return rt_prio(p->prio);
> }
>
> +static inline bool task_is_elevated(struct task_struct *tsk)
Would you be terribly upset if I rename that? I'm thinking something
like task_is_realtime() better reflects what it does.
> +{
> + int policy = tsk->policy;
> +
> + if (policy == SCHED_FIFO || policy == SCHED_RR)
> + return true;
> + if (policy == SCHED_DEADLINE)
> + return true;
> + return false;
> +}
> +
> #ifdef CONFIG_RT_MUTEXES
> /*
> * Must hold either p->pi_lock or task_rq(p)->lock.
> --
> 2.14.2
>
Re: [PATCH v3 0/3] Basical device tree parts for Allwinner R40 SoC
Hi, On Fri, Oct 06, 2017 at 06:42:30AM +, Icenowy Zheng wrote: > This patchset adds basical device tree parts for the Allwinner R40 SoC > and two boards feature this SoC -- Banana Pi M2 Ultra and Berry (The > BPi M2 Berry board uses V40 SoC, which is just a renamed R40). Applied all three, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2] block/laptop_mode: Convert timers to use timer_setup()
> -static void blk_rq_timed_out_timer(unsigned long data)
> +static void blk_rq_timed_out_timer(struct timer_list *t)
> {
> - struct request_queue *q = (struct request_queue *)data;
> + struct request_queue *q = from_timer(q, t, timeout);
>
> kblockd_schedule_work(&q->timeout_work);
> }
This isn't the laptop_mode timer, although the change itself looks fine.
> + timer_setup(&q->backing_dev_info->laptop_mode_wb_timer,
> + laptop_mode_timer_fn, 0);
And I already pointed out to Jens when he did the previous changes
to this one that it has no business being in the block code, it
really should move to mm/page-writeback.c with the rest of the
handling of this timer. Once that is fixed up your automated script
should pick it up, so we wouldn't need the manual change.
Untested patch for that below:
---
>From 77881bd72b5fb1219fc74625b0380930f9c580df Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Fri, 6 Oct 2017 10:18:53 +0200
Subject: mm: move all laptop_mode handling to backing-dev.c
It isn't block-device specific and oddly spread over multiple files
at the moment:
TODO: audit that the unregistration changes are fine
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 3 ---
include/linux/writeback.h | 6 --
mm/backing-dev.c | 36
mm/page-writeback.c | 36
4 files changed, 36 insertions(+), 45 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 14f7674fa0b1..f5f916b28c40 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -662,7 +662,6 @@ void blk_cleanup_queue(struct request_queue *q)
blk_flush_integrity();
/* @q won't process any more request, flush async actions */
- del_timer_sync(&q->backing_dev_info->laptop_mode_wb_timer);
blk_sync_queue(q);
if (q->mq_ops)
@@ -841,8 +840,6 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask,
int node_id)
q->backing_dev_info->name = "block";
q->node = node_id;
- setup_timer(&q->backing_dev_info->laptop_mode_wb_timer,
- laptop_mode_timer_fn, (unsigned long) q);
setup_timer(&q->timeout, blk_rq_timed_out_timer, (unsigned long) q);
INIT_LIST_HEAD(&q->queue_head);
INIT_LIST_HEAD(&q->timeout_list);
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index 9c0091678af4..e6ba35a5e1f7 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -327,14 +327,8 @@ static inline void cgroup_writeback_umount(void)
/*
* mm/page-writeback.c
*/
-#ifdef CONFIG_BLOCK
void laptop_io_completion(struct backing_dev_info *info);
void laptop_sync_completion(void);
-void laptop_mode_sync(struct work_struct *work);
-void laptop_mode_timer_fn(unsigned long data);
-#else
-static inline void laptop_sync_completion(void) { }
-#endif
bool node_dirty_ok(struct pglist_data *pgdat);
int wb_domain_init(struct wb_domain *dom, gfp_t gfp);
#ifdef CONFIG_CGROUP_WRITEBACK
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index e19606bb41a0..cb36f07f2af2 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -822,6 +822,38 @@ static void cgwb_remove_from_bdi_list(struct bdi_writeback
*wb)
#endif /* CONFIG_CGROUP_WRITEBACK */
+static void laptop_mode_timer_fn(unsigned long data)
+{
+ struct backing_dev_info *bdi = (struct backing_dev_info *)data;
+
+ wakeup_flusher_threads_bdi(bdi, WB_REASON_LAPTOP_TIMER);
+}
+
+/*
+ * We've spun up the disk and we're in laptop mode: schedule writeback
+ * of all dirty data a few seconds from now. If the flush is already scheduled
+ * then push it back - the user is still using the disk.
+ */
+void laptop_io_completion(struct backing_dev_info *bdi)
+{
+ mod_timer(&bdi->laptop_mode_wb_timer, jiffies + laptop_mode);
+}
+
+/*
+ * We're in laptop mode and we've just synced. The sync's writes will have
+ * caused another writeback to be scheduled by laptop_io_completion.
+ * Nothing needs to be written back anymore, so we unschedule the writeback.
+ */
+void laptop_sync_completion(void)
+{
+ struct backing_dev_info *bdi;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(bdi, &bdi_list, bdi_list)
+ del_timer(&bdi->laptop_mode_wb_timer);
+ rcu_read_unlock();
+}
+
static int bdi_init(struct backing_dev_info *bdi)
{
int ret;
@@ -835,6 +867,8 @@ static int bdi_init(struct backing_dev_info *bdi)
INIT_LIST_HEAD(&bdi->bdi_list);
INIT_LIST_HEAD(&bdi->wb_list);
init_waitqueue_head(&bdi->wb_waitq);
+ setup_timer(&bdi->laptop_mode_wb_timer,
+ laptop_mode_timer_fn, (unsigned long)bdi);
ret = cgwb_bdi_init(bdi);
@@ -916,6 +950,8 @@ EXPORT_SYMBOL(bdi_register_owner);
*/
static void bdi_remove_from_list(struct backing_dev_info *bdi)
{
+ del_timer_sync(&bdi->laptop_mode_wb_timer);
+
spin_lock_bh(&bdi_lock);
list_del
Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data
On Fri, Oct 06, 2017 at 12:11:45AM -0700, Christoph Hellwig wrote: > On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > > DMA faults can be detected by IOMMU at device level. Adding a pointer > > to struct device allows IOMMU subsystem to report relevant faults > > back to the device driver for further handling. > > For direct assigned device (or user space drivers), guest OS holds > > responsibility to handle and respond per device IOMMU fault. > > Therefore we need fault reporting mechanism to propagate faults beyond > > IOMMU subsystem. > > We use struct device all over the system, and I don't think we should > bloat it for fringe case IOMMU bits. > > Someone really needs to take a step back and figure out how to move > this into a structure that's only allocated for device that actually > can do physical DMA (and/or have an iommu attached) > > This is the 3rd iommu field, in addition to 8 dma-specific fields > that we carry around for each struct device. Ick, 8? Yeah, it's getting big... How about just a single pointer for iommu and dma-specific stuff that you all can hang crap like this off of if needed? thanks, greg k-h
Re: [PATCH] pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping
On Wed, Oct 04, 2017 at 09:42:49AM +0300, Mika Westerberg wrote: > On Tue, Oct 03, 2017 at 12:00:49PM -0500, Grygorii Strashko wrote: > > New GPIO IRQs are allocated and mapped dynamically by default when > > GPIO IRQ infrastructure is used by cherryview-pinctrl driver. > > This causes issues on some Intel platforms [1][2] with broken BIOS which > > hardcodes Linux IRQ numbers in their ACPI tables. > > > > On such platforms cherryview-pinctrl driver should allocate and map all > > GPIO IRQs at probe time. > > Side effect - "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n" > > can be seen at boot log. > > > > NOTE. It still may fail if boot sequence will changed and some interrupt > > controller will be probed before cherryview-pinctrl which will shift Linux > > IRQ > > numbering (expected with CONFIG_SPARCE_IRQ enabled). > > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=194945 > > [2] https://lkml.org/lkml/2017/9/28/153 > > Cc: Andy Shevchenko > > Cc: Chris Gorman > > Cc: Mika Westerberg > > Cc: Heikki Krogerus > > Signed-off-by: Grygorii Strashko > > Reported-by: Chris Gorman > > Reported-by: Mika Westerberg > > Looks reasonable to me. Thanks for taking care of this! > > Chris, can you try if this fixes the issue and provide your Tested-by? Linus, Chris gave his tested-by in another thread: https://patchwork.kernel.org/patch/9985087/ Chris, please let me know if that was not your intention. I'm fine with the patch as well, Acked-by: Mika Westerberg I guess this requires stable tag because if I understand comments in that bug right, it affects the whole v4.13.
[PATCH] pinctrl: meson-gx: add TEST_N i2s pinmux
Add TEST_N pinmux for channel 6 and 7 of the i2s output
Signed-off-by: Jerome Brunet
---
Hi Linus,
FYI, This change depends on clean-up series you've just merged.
Cheers,
Jerome
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 5 +
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 6 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index 62483b67f114..1881d4a0eca2 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -288,6 +288,7 @@ static const unsigned int i2s_out_lr_clk_pins[] = {
GPIOAO_10 };
static const unsigned int i2s_out_ch01_ao_pins[] = { GPIOAO_11 };
static const unsigned int i2s_out_ch23_ao_pins[] = { GPIOAO_12 };
static const unsigned int i2s_out_ch45_ao_pins[] = { GPIOAO_13 };
+static const unsigned int i2s_out_ch67_ao_pins[] = { GPIO_TEST_N };
static const unsigned int spdif_out_ao_6_pins[]= { GPIOAO_6 };
static const unsigned int spdif_out_ao_13_pins[] = { GPIOAO_13 };
@@ -562,6 +563,9 @@ static struct meson_pmx_group meson_gxbb_aobus_groups[] = {
GROUP(spdif_out_ao_13, 0, 4),
GROUP(ao_cec, 0, 15),
GROUP(ee_cec, 0, 14),
+
+ /* test n pin */
+ GROUP(i2s_out_ch67_ao, 1, 2),
};
static const char * const gpio_periphs_groups[] = {
@@ -748,6 +752,7 @@ static const char * const pwm_ao_b_groups[] = {
static const char * const i2s_out_ao_groups[] = {
"i2s_am_clk", "i2s_out_ao_clk", "i2s_out_lr_clk",
"i2s_out_ch01_ao", "i2s_out_ch23_ao", "i2s_out_ch45_ao",
+ "i2s_out_ch67_ao",
};
static const char * const spdif_out_ao_groups[] = {
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c
b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
index 04334e807170..3a14ecae9f31 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxl.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -291,6 +291,7 @@ static const unsigned int pwm_ao_b_6_pins[] = { GPIOAO_6 };
static const unsigned int i2s_out_ch23_ao_pins[] = { GPIOAO_8 };
static const unsigned int i2s_out_ch45_ao_pins[] = { GPIOAO_9 };
+static const unsigned int i2s_out_ch67_ao_pins[] = { GPIO_TEST_N };
static const unsigned int spdif_out_ao_6_pins[] = { GPIOAO_6 };
static const unsigned int spdif_out_ao_9_pins[] = { GPIOAO_9 };
@@ -557,6 +558,9 @@ static struct meson_pmx_group meson_gxl_aobus_groups[] = {
GROUP(spdif_out_ao_9, 0, 4),
GROUP(ao_cec, 0, 15),
GROUP(ee_cec, 0, 14),
+
+ /* test n pin */
+ GROUP(i2s_out_ch67_ao, 1, 2),
};
static const char * const gpio_periphs_groups[] = {
@@ -735,7 +739,7 @@ static const char * const pwm_ao_b_groups[] = {
};
static const char * const i2s_out_ao_groups[] = {
- "i2s_out_ch23_ao", "i2s_out_ch45_ao",
+ "i2s_out_ch23_ao", "i2s_out_ch45_ao", "i2s_out_ch67_ao",
};
static const char * const spdif_out_ao_groups[] = {
--
2.13.5
Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command
> AFAIU the scheduler rq->lock is held while preemption is disabled. > synchronize_sched() is used here to ensure that all pre-existing > preempt-off critical sections have completed. > > So saying that we use synchronize_sched() to synchronize with rq->lock > would be stretching the truth a bit. It's actually only true because the > scheduler holding the rq->lock is surrounded by a preempt-off > critical section. No, rq->lock is sufficient, note that rq->lock is a raw_spinlock_t which implies !preempt. Yes, we also surround the rq->lock usage with a slightly larger preempt_disable() section but that's not in fact required for this.
Re: [PATCH 1/3] pinctrl: sunxi: Introduce the strict flag
On Fri, Oct 6, 2017 at 4:54 AM, Maxime Ripard
wrote:
> Our pinctrl device should have had strict set all along. However, it wasn't
> the case, and most of our old device trees also have a pinctrl group in
> addition to the GPIOs properties, which mean that we can't really turn it
> on now.
>
> All our new SoCs don't have that group, so we should still enable that mode
> on the newer one though.
>
> In order to enable it by default, add a flag that will allow to disable
> that mode that should be set by pinctrl drivers that cannot be migrated.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 5 -
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 52edf3b5988d..1753a5b1573f 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -690,7 +690,7 @@ sunxi_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
> return 0;
> }
>
> -static const struct pinmux_ops sunxi_pmx_ops = {
> +static struct pinmux_ops sunxi_pmx_ops = {
> .get_functions_count= sunxi_pmx_get_funcs_cnt,
> .get_function_name = sunxi_pmx_get_func_name,
> .get_function_groups= sunxi_pmx_get_func_groups,
> @@ -1307,6 +1307,9 @@ int sunxi_pinctrl_init_with_variant(struct
> platform_device *pdev,
> pctrl_desc->pctlops = &sunxi_pctrl_ops;
> pctrl_desc->pmxops = &sunxi_pmx_ops;
>
> + if (desc->disable_strict_mode)
> + sunxi_pmx_ops.strict = false;
This is a bad idea. We have two pinctrl instances sharing the
same ops structure for later SoCs (the normal PIO and R_PIO).
What if they don't match? It would be better to make a copy,
(preferably) at runtime, or statically.
ChenYu
> +
> pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, pctrl_desc, pctl);
> if (IS_ERR(pctl->pctl_dev)) {
> dev_err(&pdev->dev, "couldn't register pinctrl driver\n");
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index 1bfc0d8a55df..11b128f54ed2 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -112,6 +112,7 @@ struct sunxi_pinctrl_desc {
> unsignedirq_banks;
> unsignedirq_bank_base;
> boolirq_read_needs_mux;
> + booldisable_strict_mode;
> };
>
> struct sunxi_pinctrl_function {
> --
> git-series 0.9.1
Re: [PATCH 2/3] pinctrl: sunxi: Disable strict mode for old pinctrl drivers
On Fri, Oct 6, 2017 at 4:54 AM, Maxime Ripard wrote: > Old pinctrl drivers will need to disable strict mode for various reasons, > among which: > - Some DT will still have a pinctrl group for each GPIO used, which will > be rejected by pin_request. While we could remove those nodes, we still > have to deal with old DTs. > - Some GPIOs on these boards need to have their pin configuration changed > (for bias or current), and there's no clear migration path > > Let's disable the strict mode on those SoCs so that there's no breakage. > > Signed-off-by: Maxime Ripard > --- > drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c | 1 + > drivers/pinctrl/sunxi/pinctrl-sun5i.c | 1 + > drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c | 1 + > drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c | 1 + > drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c | 1 + > drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c | 3 ++- > drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 1 + You should also set it for the R_PIO drivers. IIRC you removed some entries for them in your other patchset. Otherwise, Acked-by: Chen-Yu Tsai
Re: [PATCH 3/3] pinctrl: sunxi: Enforce the strict mode by default
On Fri, Oct 6, 2017 at 4:54 AM, Maxime Ripard wrote: > The strict mode should always have been enabled on our driver, and leaving > it unchecked just makes it harder to find a migration path as time passes. > > Let's enable it by default now so that hopefully the new SoCs should be > safe. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai
Re: [PATCH] drm/i915: Convert timers to use timer_setup()
On Thu, 05 Oct 2017, Kees Cook wrote:
> On Thu, Oct 5, 2017 at 6:45 AM, Joonas Lahtinen
> wrote:
>> On Wed, 2017-10-04 at 17:54 -0700, Kees Cook wrote:
>>> In preparation for unconditionally passing the struct timer_list pointer to
>>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>>> to pass the timer pointer explicitly.
>>>
>>> Cc: Daniel Vetter
>>> Cc: Jani Nikula
>>> Cc: David Airlie
>>> Cc: Chris Wilson
>>> Cc: Joonas Lahtinen
>>> Cc: Tvrtko Ursulin
>>> Cc: Oscar Mateo
>>> Cc: intel-...@lists.freedesktop.org
>>> Cc: dri-de...@lists.freedesktop.org
>>> Cc: Thomas Gleixner
>>> Signed-off-by: Kees Cook
>>
>>
>>
>>> @@ -32,9 +32,9 @@ static struct mock_request *first_request(struct
>>> mock_engine *engine)
>>> link);
>>> }
>>>
>>> -static void hw_delay_complete(unsigned long data)
>>> +static void hw_delay_complete(struct timer_list *t)
>>> {
>>> - struct mock_engine *engine = (typeof(engine))data;
>>> + struct mock_engine *engine = from_timer(engine, t, hw_delay);
>>
>> The order is bit strange to me, it's not same as with container_of, but
>> I guess GCC will complain for getting it wrong. It's also slightly
>> different doing the typeof for you, so I guess it makes sense, so:
>
> Yeah, this seemed to be the least bad of several options. Other things
> ended up being either very long, named unlike anything else already in
> the kernel, etc.
>
>> Reviewed-by: Joonas Lahtinen
>
> Thanks!
>
>> Do you expect for us to merge or are you looking to merge all timer
>> changes from single tree?
>
> If you have -rc3 in your tree already, please take this into your
> tree. If you prefer the timer tree to carry it, that can happen too.
> tglx suggested to me that it was better for maintainers to carry the
> changes.
We'll pick this when we have -rc3.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data
On Fri, Oct 06, 2017 at 12:11:45AM -0700, Christoph Hellwig wrote: > This is the 3rd iommu field, in addition to 8 dma-specific fields > that we carry around for each struct device. Agreed, consolidating the iommu-fields in 'struct device' into a single 'struct iommu_data' is on my todo-list. Jacob, can you add that 'struct iommu_data' to 'struct device' and put your fault-data into it? We can then move on and migrate the other fields into that struct too. Regards, Joerg
Re: [PATCH 0/6] Switch arm64 over to qrwlock
Hi Jeremy, On Thu, Oct 05, 2017 at 05:12:44PM -0500, Jeremy Linton wrote: > On 10/05/2017 07:54 AM, Will Deacon wrote: > >This patch series reworks bits of the qrwlock code that it can be used > >to replace the asm rwlocks currently implemented for arm64. The structure > >of the series is: > > > > Patches 1-3 : Work WFE into qrwlock using atomic_cond_read_acquire > > so > > we can avoid busy-waiting. > > > > Patch 4 : Enable qrwlocks for arm64 > > > > Patch 5-6 : Ensure writer slowpath fairness. This has a potential > > performance impact on the writer unlock path, so I've > > kept them at the end. > > > >The patches apply on top of my other locking cleanups: > > > > > > http://lkml.kernel.org/r/1507055129-12300-1-git-send-email-will.dea...@arm.com > > > >although the conflict with mainline is trivial to resolve without those. > >The full stack is also pushed here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git qrwlock > > > >All comments (particularly related to testing and performance) welcome! > > I haven't done any perf testing, but the machines continue to boot, and the > stress-ng test which causes task lock problems with the normal arm64 rwlock > now appears to run as expected. So, its a good start! Excellent! Mind if I add your tested-by? Will
Re: [PATCH] ALSA: usb-audio: Add sample rate quirk for Plantronics P610
On Fri, 06 Oct 2017 06:27:59 +0200,
Kai-Heng Feng wrote:
>
> Hi,
>
> On Fri, Oct 6, 2017 at 2:22 AM, Takashi Iwai wrote:
> > On Thu, 05 Oct 2017 20:04:06 +0200,
> > Kai-Heng Feng wrote:
> >>
> >> Like other Plantronics devices, P610 does not support sample
> >> rate reading. Apply sample rate quirk to it.
> >>
> >> BugLink: https://bugs.launchpad.net/bugs/1719853
> >>
> >> Signed-off-by: Kai-Heng Feng
> >
> > Hrm, maybe we should ignore all Plantronics devices?
> > Also MS Lifecam and Phoenix devices are such candidates.
> >
> > So something like below.
> >
> > Takashi
> >
> > -- 8< --
> > From: Takashi Iwai
> > Subject: [PATCH] ALSA: usb-audio: Apply vendor ID matching for sample rate
> > quirk
> >
> > So far, lots of Plantronics, MS and Phoenix Audio devices need the
> > quirk not to read sample rate back, and the list just grows.
> > In this patch, instead of adding each device, apply the quirk by
> > matching with these vendors.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > sound/usb/quirks.c | 23 +--
> > 1 file changed, 9 insertions(+), 14 deletions(-)
> >
> > diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
> > index b8cb57aeec77..9aeb05f61f78 100644
> > --- a/sound/usb/quirks.c
> > +++ b/sound/usb/quirks.c
> > @@ -1128,29 +1128,24 @@ bool snd_usb_get_sample_rate_quirk(struct
> > snd_usb_audio *chip)
> > /* devices which do not support reading the sample rate. */
> > switch (chip->usb_id) {
> > case USB_ID(0x041E, 0x4080): /* Creative Live Cam VF0610 */
> > - case USB_ID(0x045E, 0x075D): /* MS Lifecam Cinema */
> > - case USB_ID(0x045E, 0x076D): /* MS Lifecam HD-5000 */
> > - case USB_ID(0x045E, 0x076E): /* MS Lifecam HD-5001 */
> > - case USB_ID(0x045E, 0x076F): /* MS Lifecam HD-6000 */
> > - case USB_ID(0x045E, 0x0772): /* MS Lifecam Studio */
> > - case USB_ID(0x045E, 0x0779): /* MS Lifecam HD-3000 */
> > - case USB_ID(0x047F, 0x02F7): /* Plantronics BT-600 */
> > - case USB_ID(0x047F, 0x0415): /* Plantronics BT-300 */
> > - case USB_ID(0x047F, 0xAA05): /* Plantronics DA45 */
> > - case USB_ID(0x047F, 0xC022): /* Plantronics C310 */
> > - case USB_ID(0x047F, 0xC036): /* Plantronics C520-M */
> > case USB_ID(0x04D8, 0xFEEA): /* Benchmark DAC1 Pre */
> > case USB_ID(0x0556, 0x0014): /* Phoenix Audio TMX320VC */
> > case USB_ID(0x05A3, 0x9420): /* ELP HD USB Camera */
> > case USB_ID(0x074D, 0x3553): /* Outlaw RR2150 (Micronas UAC3553B) */
> > case USB_ID(0x1395, 0x740a): /* Sennheiser DECT */
> > case USB_ID(0x1901, 0x0191): /* GE B850V3 CP2114 audio interface */
> > - case USB_ID(0x1de7, 0x0013): /* Phoenix Audio MT202exe */
> > - case USB_ID(0x1de7, 0x0014): /* Phoenix Audio TMX320 */
> > - case USB_ID(0x1de7, 0x0114): /* Phoenix Audio MT202pcs */
> > case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */
> > return true;
> > }
> > +
> > + /* devices of these vendors don't support reading rate, either */
> > + switch (USB_ID_VENDOR(chip->usb_id)) {
> > + case 0x045E: /* MS Lifecam */
> > + case 0x047F: /* Plantronics */
> > + case 0x1de7: /* Phoenix Audio */
> > + return true;
> > + }
> > +
> > return false;
> > }
> >
>
> This is definitely a better approach. Thanks!
>
> Acked-by: Kai-Heng Feng
Thanks. I'll queue it for-next branch.
Meanwhile, the fix you submitted is still needed for 4.14, so I merged
it to for-linus branch, too.
Takashi
Re: __ubsan_handle_type_mismatch converted to __ubsan_handle_type_mismatch_v1
On 10/06/2017 05:29 AM, Sodagudi Prasad wrote: > Hi All, > > Based on below links __ubsan_handle_type_mismatch has been renamed to > __ubsan_handle_type_mismatch_v1. > > https://github.com/llvm-mirror/compiler-rt/commit/56faee71af1888ba12ab076b3d1f9bbe223493df#diff-21369cc6f3917b27df3ced8de89cf134 > https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg535130.html > > > When I tried to compile the kernel with LLVM seen following errors. > arch/arm64/kernel/traps.o: In function `dump_backtrace': > kernel/arch/arm64/kernel/traps.c:192: undefined reference to > `__ubsan_handle_type_mismatch_v1' > kernel/arch/arm64/kernel/traps.c:192: undefined reference to > `__ubsan_handle_type_mismatch_v1' > kernel/arch/arm64/kernel/traps.c:192: undefined reference to > `__ubsan_handle_type_mismatch_v1' > kernel/arch/arm64/kernel/traps.c:192: undefined reference to > `__ubsan_handle_type_mismatch_v1' > arch/arm64/kernel/traps.o: In function `dump_mem': > > > Can I add __ubsan_handle_type_mismatch_v1 API similar to > __ubsan_handle_type_mismatch()(I will send path for review)? > If both apis are present, then there will be backward compatibility. Let me > know if you have any other suggestions for this issue. Sounds good, send the patch please. > > -Thanks, Prasad >
Re: [PATCH 05/20] ARM: dts: sun4i: Change pinctrl nodes to avoid warning
Hi,
On Thu, Oct 05, 2017 at 03:29:56PM +, Chen-Yu Tsai wrote:
> > @@ -531,83 +531,83 @@
> > bias-pull-up;
> > };
> >
> > - ps20_pins_a: ps20@0 {
> > - pins = "PI20", "PI21";
> > + ps2_ph_pins: ps2-ph-pins {
> > + pins = "PH12", "PH13";
> > function = "ps2";
> > };
> >
> > - ps21_pins_a: ps21@0 {
> > - pins = "PH12", "PH13";
> > + ps2_pi_pins: ps2-pi-pins {
> > + pins = "PI20", "PI21";
> > function = "ps2";
> > };
>
> This part is slightly incorrect. The PS/2 block has 2 inputs.
> The first channel, or ps2-0, has only one muxing option, on
> pins PI20 and PI21. The second channel has two options, either
> PH12 + PH13 or PI14 + PI15. The names should encode which channel
> the muxing option is for.
Would ps2_ch0_pins and ps2_ch1_pi_pins work for you then?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 07/20] ARM: dts: sun4i: Remove skeleton and memory to avoid warnings
On Thu, Oct 05, 2017 at 03:43:53PM +, Chen-Yu Tsai wrote:
> On Thu, Oct 5, 2017 at 6:49 PM, Maxime Ripard
> wrote:
> > Using skeleton.dtsi will create a memory node that will generate a warning
> > in DTC. However, that node will be created by the bootloader, so we can
> > just remove it entirely in order to remove that warning.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > arch/arm/boot/dts/sun4i-a10.dtsi | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> > b/arch/arm/boot/dts/sun4i-a10.dtsi
> > index 1876abb62ec7..f64544f615ea 100644
> > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > @@ -41,14 +41,14 @@
> > * OTHER DEALINGS IN THE SOFTWARE.
> > */
> >
> > -#include "skeleton.dtsi"
> > -
> > #include
> > #include
> > #include
> > #include
> >
> > / {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > interrupt-parent = <&intc>;
> >
> > aliases {
> > @@ -160,10 +160,6 @@
> > };
> > };
> >
> > - memory {
> > - reg = <0x4000 0x8000>;
> > - };
> > -
>
> My only concern (I'm not sure if it's valid or not) is U-boot not being
> able to add nodes or properties due to lack of space within the DT
> blob. It seemed like a possibility in older versions.
>
> Otherwise,
>
> Acked-by: Chen-Yu Tsai
I don't think we really have to worry about it. We've had a bunch of
nodes (like the PSCI nodes) created in the same way for quite some
time already without causing any issues.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCHv2 2/2] mm: Consolidate page table accounting
[CC linux-api because this is a user visible change]
On Thu 05-10-17 13:14:42, Kirill A. Shutemov wrote:
> Currently, we account page tables separately for each page table level,
> but that's redundant -- we only make use of total memory allocated to
> page tables for oom_badness calculation. We also provide the information
> to userspace, but it has dubious value there too.
I completely agree! The VmPMD has been added just in case wihtout any
specific use in mind.
> This patch switches page table accounting to single counter.
>
> mm->pgtables_bytes is now used to account all page table levels. We use
> bytes, because page table size for different levels of page table tree
> may be different.
>
> The change has user-visible effect: we don't have VmPMD and VmPUD
> reported in /proc/[pid]/status. Not sure if anybody uses them.
> (As alternative, we can always report 0 kB for them.
I would go with removing the value rather than faking it. If somebody
really depends on it then we will have to revert this.
> OOM-killer report is also slightly changed: we now report pgtables_bytes
> instead of nr_ptes, nr_pmd, nr_puds.
This will actually make the parsing easier because the script doesn't
have to care about different page table sizes which we didn't handle in
oom_badness properly as well.
> The benefit is that we now calculate oom_badness() more correctly for
> machines which have different size of page tables depending on level
> or where page tables are less than a page in size.
Not only that. Another benefit is that we reduce the number of counters
and the API maintenance.
The only downside can be debugability because we do not know which page
table level could leak. But I do not remember many bugs that would be
caught by separate counters so I wouldn't lose sleep over this.
> Signed-off-by: Kirill A. Shutemov
Acked-by: Michal Hocko
Thanks for doing this! One less item on my todo list ;)
> ---
> Documentation/filesystems/proc.txt | 1 -
> Documentation/sysctl/vm.txt| 8 +++---
> fs/proc/task_mmu.c | 11 ++--
> include/linux/mm.h | 58
> --
> include/linux/mm_types.h | 8 +-
> kernel/fork.c | 16 +++
> mm/debug.c | 7 ++---
> mm/oom_kill.c | 14 -
> 8 files changed, 31 insertions(+), 92 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt
> b/Documentation/filesystems/proc.txt
> index adba21b5ada7..ec571b9bb18a 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -250,7 +250,6 @@ Table 1-2: Contents of the status files (as of 4.8)
> VmExe size of text segment
> VmLib size of shared library code
> VmPTE size of page table entries
> - VmPMD size of second level page tables
> VmSwap amount of swap used by anonymous private data
> (shmem swap usage is not included)
> HugetlbPagessize of hugetlb memory portions
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index 2717b6f2d706..2db0596d12f4 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -622,10 +622,10 @@ oom_dump_tasks
>
> Enables a system-wide task dump (excluding kernel threads) to be produced
> when the kernel performs an OOM-killing and includes such information as
> -pid, uid, tgid, vm size, rss, nr_ptes, nr_pmds, nr_puds, swapents,
> -oom_score_adj score, and name. This is helpful to determine why the OOM
> -killer was invoked, to identify the rogue task that caused it, and to
> -determine why the OOM killer chose the task it did to kill.
> +pid, uid, tgid, vm size, rss, pgtables_bytes, swapents, oom_score_adj
> +score, and name. This is helpful to determine why the OOM killer was
> +invoked, to identify the rogue task that caused it, and to determine why
> +the OOM killer chose the task it did to kill.
>
> If this is set to zero, this information is suppressed. On very
> large systems with thousands of tasks it may not be feasible to dump
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 84c262d5197a..c9c81373225d 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -25,7 +25,7 @@
>
> void task_mem(struct seq_file *m, struct mm_struct *mm)
> {
> - unsigned long text, lib, swap, ptes, pmds, puds, anon, file, shmem;
> + unsigned long text, lib, swap, anon, file, shmem;
> unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;
>
> anon = get_mm_counter(mm, MM_ANONPAGES);
> @@ -49,9 +49,6 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> 10;
> lib = (mm->exec_vm << (PAGE_SHIFT-10)) - text;
> swap = get_mm_counter(mm, MM_S
Re: [PATCHv2 1/2] mm: Introduce wrappers to access mm->nr_ptes
On Thu 05-10-17 13:14:41, Kirill A. Shutemov wrote:
> Let's add wrappers for ->nr_ptes with the same interface as for nr_pmd
> and nr_pud.
>
> It's preparation for consolidation of page-table counters in mm_struct.
You are also making the accounting dependent on MMU which is OK because
no nommu arch really accounts page tables if there is anything like that
at all on those archs but it should be mentioned in the changelog.
> Signed-off-by: Kirill A. Shutemov
Acked-by: Michal Hocko
> ---
> arch/arm/mm/pgd.c | 2 +-
> arch/sparc/mm/hugetlbpage.c | 2 +-
> arch/unicore32/mm/pgd.c | 2 +-
> fs/proc/task_mmu.c | 2 +-
> include/linux/mm.h | 32
> include/linux/mm_types.h| 2 ++
> kernel/fork.c | 6 +++---
> mm/debug.c | 2 +-
> mm/huge_memory.c| 10 +-
> mm/khugepaged.c | 2 +-
> mm/memory.c | 8
> mm/oom_kill.c | 5 ++---
> 12 files changed, 54 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mm/pgd.c b/arch/arm/mm/pgd.c
> index c1c1a5c67da1..61e281cb29fb 100644
> --- a/arch/arm/mm/pgd.c
> +++ b/arch/arm/mm/pgd.c
> @@ -141,7 +141,7 @@ void pgd_free(struct mm_struct *mm, pgd_t *pgd_base)
> pte = pmd_pgtable(*pmd);
> pmd_clear(pmd);
> pte_free(mm, pte);
> - atomic_long_dec(&mm->nr_ptes);
> + mm_dec_nr_ptes(mm);
> no_pmd:
> pud_clear(pud);
> pmd_free(mm, pmd);
> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> index fd0d85808828..29fa5967b7d2 100644
> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -396,7 +396,7 @@ static void hugetlb_free_pte_range(struct mmu_gather
> *tlb, pmd_t *pmd,
>
> pmd_clear(pmd);
> pte_free_tlb(tlb, token, addr);
> - atomic_long_dec(&tlb->mm->nr_ptes);
> + mm_dec_nr_ptes(tlb->mm);
> }
>
> static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
> diff --git a/arch/unicore32/mm/pgd.c b/arch/unicore32/mm/pgd.c
> index c572a28c76c9..a830a300aaa1 100644
> --- a/arch/unicore32/mm/pgd.c
> +++ b/arch/unicore32/mm/pgd.c
> @@ -97,7 +97,7 @@ void free_pgd_slow(struct mm_struct *mm, pgd_t *pgd)
> pte = pmd_pgtable(*pmd);
> pmd_clear(pmd);
> pte_free(mm, pte);
> - atomic_long_dec(&mm->nr_ptes);
> + mm_dec_nr_ptes(mm);
> pmd_free(mm, pmd);
> mm_dec_nr_pmds(mm);
> free:
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 627de66204bd..84c262d5197a 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -49,7 +49,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> 10;
> lib = (mm->exec_vm << (PAGE_SHIFT-10)) - text;
> swap = get_mm_counter(mm, MM_SWAPENTS);
> - ptes = PTRS_PER_PTE * sizeof(pte_t) * atomic_long_read(&mm->nr_ptes);
> + ptes = PTRS_PER_PTE * sizeof(pte_t) * mm_nr_ptes(mm);
> pmds = PTRS_PER_PMD * sizeof(pmd_t) * mm_nr_pmds(mm);
> puds = PTRS_PER_PUD * sizeof(pud_t) * mm_nr_puds(mm);
> seq_printf(m,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5125c51c9c35..e185dcdc5183 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1679,6 +1679,38 @@ static inline void mm_dec_nr_pmds(struct mm_struct *mm)
> }
> #endif
>
> +#ifdef CONFIG_MMU
> +static inline void mm_nr_ptes_init(struct mm_struct *mm)
> +{
> + atomic_long_set(&mm->nr_ptes, 0);
> +}
> +
> +static inline unsigned long mm_nr_ptes(const struct mm_struct *mm)
> +{
> + return atomic_long_read(&mm->nr_ptes);
> +}
> +
> +static inline void mm_inc_nr_ptes(struct mm_struct *mm)
> +{
> + atomic_long_inc(&mm->nr_ptes);
> +}
> +
> +static inline void mm_dec_nr_ptes(struct mm_struct *mm)
> +{
> + atomic_long_dec(&mm->nr_ptes);
> +}
> +#else
> +static inline void mm_nr_ptes_init(struct mm_struct *mm) {}
> +
> +static inline unsigned long mm_nr_ptes(const struct mm_struct *mm)
> +{
> + return 0;
> +}
> +
> +static inline void mm_inc_nr_ptes(struct mm_struct *mm) {}
> +static inline void mm_dec_nr_ptes(struct mm_struct *mm) {}
> +#endif
> +
> int __pte_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long address);
> int __pte_alloc_kernel(pmd_t *pmd, unsigned long address);
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6c8c2bb9e5a1..95d0eefe1f4a 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -398,7 +398,9 @@ struct mm_struct {
>*/
> atomic_t mm_count;
>
> +#ifdef CONFIG_MMU
> atomic_long_t nr_ptes; /* PTE page table pages */
> +#endif
> #if CONFIG_PGTABLE_LEVELS > 2
> atomic_long_t nr_pmds; /* PMD page table pages */
> #endif
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 5624918154db..d466181902cf 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -813
Re: [PATCH 1/2] sched/rt: Add a helper to test for a RT task
On 2017-10-06 10:19:37 [+0200], Peter Zijlstra wrote: > > --- a/include/linux/sched/rt.h > > +++ b/include/linux/sched/rt.h > > @@ -17,6 +17,17 @@ static inline int rt_task(struct task_struct *p) > > return rt_prio(p->prio); > > } > > > > +static inline bool task_is_elevated(struct task_struct *tsk) > > Would you be terribly upset if I rename that? I'm thinking something > like task_is_realtime() better reflects what it does. no, not at all. Sebastian
[PATCH 4.9 001/104] drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: "Kristian H. Kristensen"
[ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ]
We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
macro to work correctly.
Signed-off-by: Kristian H. Kristensen
Signed-off-by: Daniel Vetter
Link:
http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsb...@google.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
include/uapi/drm/drm_fourcc.h |1 +
1 file changed, 1 insertion(+)
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -154,6 +154,7 @@ extern "C" {
/* Vendor Ids: */
#define DRM_FORMAT_MOD_NONE 0
+#define DRM_FORMAT_MOD_VENDOR_NONE0
#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
#define DRM_FORMAT_MOD_VENDOR_NV 0x03
[PATCH 4.9 000/104] 4.9.54-stable review
This is the start of the stable review cycle for the 4.9.54 release. There are 104 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 8 08:37:55 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.54-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.9.54-rc1 Gerald Schaefer s390/mm: make pmdp_invalidate() do invalidation only Arnd Bergmann ttpci: address stringop overflow warning Arnd Bergmann ALSA: au88x0: avoid theoretical uninitialized access Nicholas Mc Guire ASoC: rt5660: remove double const Nicholas Mc Guire ASoC: rt5659: drop double const Arnd Bergmann ASoC: rt5514: fix gcc-7 warning Arnd Bergmann ARM: remove duplicate 'const' annotations' Arnd Bergmann IB/qib: fix false-postive maybe-uninitialized warning Len Brown tools/power turbostat: bugfix: GFXMHz column not changing Jon Mason ARM: dts: BCM5301X: Fix memory start address Gwendal Grignou libata: transport: Remove circular dependency at free time Charles Keepax ASoC: wm_adsp: Return an error on write to a disabled volatile control Darrick J. Wong xfs: remove kmem_zalloc_greedy Heiner Kallweit i2c: meson: fix wrong variable usage in meson_i2c_put_data Pablo Neira Ayuso netfilter: nf_tables: set pktinfo->thoff at AH header if found Shaohua Li md/raid10: submit bio directly to replacement disk Zhu Yanjun rds: ib: add error handle Laurent Dufour mm/cgroup: avoid panic when init with low memory Mark Rutland arm64: kasan: avoid bad virt_to_pfn() Oleksandr Tyshchenko iommu/io-pgtable-arm: Check for leaf entry before dereferencing it Dou Liyang x86/acpi: Restore the order of CPU IDs Rafael J. Wysocki cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set() Nathan Fontenot ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs Jason Yan nfs: make nfs4_cb_sv_ops static Arvind Yadav parisc: perf: Fix potential NULL pointer dereference Liping Zhang netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max Sagi Grimberg nvme-rdma: handle cpu unplug when re-establishing the controller Matt Redfearn MIPS: smp-cps: Fix retrieval of VPE mask on big endian CPUs Thibault Saunier exynos-gsc: Do not swap cb/cr for semi planar formats Marek Szyprowski iommu/exynos: Block SYSMMU while invalidating FLPD cache Matt Redfearn MIPS: IRQ Stack: Unwind IRQ stack onto task stack Liping Zhang netfilter: invoke synchronize_rcu after set the _hook_ to NULL Randy Dunlap drivers/rapidio/devices/tsi721.c: make module parameter variable name unique Mike Galbraith kasan: do not sanitize kexec purgatory Mike Kravetz hugetlbfs: initialize shared policy as part of inode allocation Ondrej Zary sata_via: Enable hotplug only on VT6421 Liu Bo Btrfs: fix potential use-after-free for cloned bio Liu Bo Btrfs: fix segmentation fault when doing dio read Ido Schimmel bridge: netlink: register netdevice before executing changelink Heiner Kallweit mmc: sdio: fix alignment issue in struct sdio_func sudarsana.kall...@cavium.com qed: Fix possible system hang in the dcbnl-getdcbx() path. Florian Fainelli net: dsa: b53: Include IMP/CPU port in dumb forwarding mode Ansis Atteka udp: disable inner UDP checksum offloads in IPsec case Roman Spychała usb: plusb: Add support for PL-27A1 Pan Bian team: fix memory leaks Alexander Potapenko net/packet: check length in getsockopt() called with PACKET_HDRLEN Myungho Jung net: core: Prevent from dereferencing null pointer when releasing SKB Juerg Haefliger lkdtm: Fix Oops when unloading the module Arvind Yadav mips: ath79: clock:- Unmap region obtained by of_iomap Arnd Bergmann MIPS: Lantiq: Fix another request_mem_region() return code check Benjamin Tissoires HID: wacom: release the resources before leaving despite devm Brian Starkey drm: mali-dp: Fix transposed horizontal/vertical flip Brian Starkey drm: mali-dp: Fix destination size handling when rotating Linus Walleij ASoC: dapm: fix some pointer error handling Axel Köllhofer rtl8xxxu: Add additional USB IDs for rtl8192eu devices Peter Chen usb: chipidea: vbus event may exist before starting gadget Sricharan R iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged' David E. Box spi: pxa2xx: Add support for Intel Gemini Lake Michal Kazior ath10k:
[PATCH 4.9 016/104] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Marcin Niestroj
[ Upstream commit ca244a83ecc7f0a9242ee2116e622cb6d7ec2a90 ]
On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
events (such as power buton presses) by setting nWAKEUP output
low. After that it waits 5s for proper device boot. Currently it doesn't
happen, as the processor doesn't listen for such events. Consequently
TPS65217 changes state from SLEEP (RTC-only state) to OFF.
Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
detect power on events and recover immediately from RTC-only states,
without powering off RTC and losing time.
Signed-off-by: Marcin Niestroj
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/boot/dts/am335x-chilisom.dtsi |8
1 file changed, 8 insertions(+)
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -124,6 +124,14 @@
&rtc {
system-power-controller;
+
+ pinctrl-0 = <&ext_wakeup>;
+ pinctrl-names = "default";
+
+ ext_wakeup: ext-wakeup {
+ pins = "ext_wakeup0";
+ input-enable;
+ };
};
/* NAND Flash */
[PATCH 4.9 024/104] iio: adc: imx25-gcq: Fix module autoload
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Javier Martinez Canillas
[ Upstream commit 8f0d7daf53972da0004f7a5a4d938c85333db300 ]
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
$
After this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
alias: of:N*T*Cfsl,imx25-gcqC*
alias: of:N*T*Cfsl,imx25-gcq
Signed-off-by: Javier Martinez Canillas
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/iio/adc/fsl-imx25-gcq.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/fsl-imx25-gcq.c
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -401,6 +401,7 @@ static const struct of_device_id mx25_gc
{ .compatible = "fsl,imx25-gcq", },
{ /* Sentinel */ }
};
+MODULE_DEVICE_TABLE(of, mx25_gcq_ids);
static struct platform_driver mx25_gcq_driver = {
.driver = {
[PATCH 4.9 015/104] scsi: be2iscsi: Add checks to validate CID alloc/free
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jitendra Bhivare
[ Upstream commit 413f365657a8b9669bd0ba3628e9fde9ce63604e ]
Set CID slot to 0x to indicate empty.
Check if connection already exists in conn_table before binding.
Check if endpoint already NULL before putting back CID.
Break ep->conn link in free_ep to ignore completions after freeing.
Signed-off-by: Jitendra Bhivare
Reviewed-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/be2iscsi/be_iscsi.c | 163 +++
drivers/scsi/be2iscsi/be_main.c |7 -
drivers/scsi/be2iscsi/be_main.h |1
3 files changed, 87 insertions(+), 84 deletions(-)
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -166,33 +166,6 @@ beiscsi_conn_create(struct iscsi_cls_ses
}
/**
- * beiscsi_bindconn_cid - Bind the beiscsi_conn with phba connection table
- * @beiscsi_conn: The pointer to beiscsi_conn structure
- * @phba: The phba instance
- * @cid: The cid to free
- */
-static int beiscsi_bindconn_cid(struct beiscsi_hba *phba,
- struct beiscsi_conn *beiscsi_conn,
- unsigned int cid)
-{
- uint16_t cri_index = BE_GET_CRI_FROM_CID(cid);
-
- if (phba->conn_table[cri_index]) {
- beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG,
- "BS_%d : Connection table already occupied.
Detected clash\n");
-
- return -EINVAL;
- } else {
- beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
- "BS_%d : phba->conn_table[%d]=%p(beiscsi_conn)\n",
- cri_index, beiscsi_conn);
-
- phba->conn_table[cri_index] = beiscsi_conn;
- }
- return 0;
-}
-
-/**
* beiscsi_conn_bind - Binds iscsi session/connection with TCP connection
* @cls_session: pointer to iscsi cls session
* @cls_conn: pointer to iscsi cls conn
@@ -212,6 +185,7 @@ int beiscsi_conn_bind(struct iscsi_cls_s
struct hwi_wrb_context *pwrb_context;
struct beiscsi_endpoint *beiscsi_ep;
struct iscsi_endpoint *ep;
+ uint16_t cri_index;
ep = iscsi_lookup_endpoint(transport_fd);
if (!ep)
@@ -229,20 +203,34 @@ int beiscsi_conn_bind(struct iscsi_cls_s
return -EEXIST;
}
-
- pwrb_context = &phwi_ctrlr->wrb_context[BE_GET_CRI_FROM_CID(
- beiscsi_ep->ep_cid)];
+ cri_index = BE_GET_CRI_FROM_CID(beiscsi_ep->ep_cid);
+ if (phba->conn_table[cri_index]) {
+ if (beiscsi_conn != phba->conn_table[cri_index] ||
+ beiscsi_ep != phba->conn_table[cri_index]->ep) {
+ __beiscsi_log(phba, KERN_ERR,
+ "BS_%d : conn_table not empty at %u: cid
%u conn %p:%p\n",
+ cri_index,
+ beiscsi_ep->ep_cid,
+ beiscsi_conn,
+ phba->conn_table[cri_index]);
+ return -EINVAL;
+ }
+ }
beiscsi_conn->beiscsi_conn_cid = beiscsi_ep->ep_cid;
beiscsi_conn->ep = beiscsi_ep;
beiscsi_ep->conn = beiscsi_conn;
+ /**
+* Each connection is associated with a WRBQ kept in wrb_context.
+* Store doorbell offset for transmit path.
+*/
+ pwrb_context = &phwi_ctrlr->wrb_context[cri_index];
beiscsi_conn->doorbell_offset = pwrb_context->doorbell_offset;
-
beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
- "BS_%d : beiscsi_conn=%p conn=%p ep_cid=%d\n",
- beiscsi_conn, conn, beiscsi_ep->ep_cid);
-
- return beiscsi_bindconn_cid(phba, beiscsi_conn, beiscsi_ep->ep_cid);
+ "BS_%d : cid %d phba->conn_table[%u]=%p\n",
+ beiscsi_ep->ep_cid, cri_index, beiscsi_conn);
+ phba->conn_table[cri_index] = beiscsi_conn;
+ return 0;
}
static int beiscsi_iface_create_ipv4(struct beiscsi_hba *phba)
@@ -973,9 +961,9 @@ int beiscsi_conn_start(struct iscsi_cls_
*/
static int beiscsi_get_cid(struct beiscsi_hba *phba)
{
- unsigned short cid = 0x, cid_from_ulp;
- struct ulp_cid_info *cid_info = NULL;
uint16_t cid_avlbl_ulp0, cid_avlbl_ulp1;
+ unsigned short cid, cid_from_ulp;
+ struct ulp_cid_info *cid_info;
/* Find the ULP which has more CID available */
cid_avlbl_ulp0 = (phba->cid_array_info[BEISCSI_ULP0]) ?
@@ -984,20 +972,27 @@ static int beiscsi_get_cid(struct beiscs
BEISCSI_ULP1_AVLBL_CID(phba) : 0;
cid_from_ulp = (cid_avlbl_ulp0 > cid_avlbl_ulp1) ?
BEISCSI_ULP0 : BEISCSI_ULP1;
+ /**
+
[PATCH 4.9 023/104] hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Guenter Roeck [ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ] Writes into limit attributes can overflow due to multplications and additions with unbound input values. Writing into fan limit attributes can result in a crash with a division by zero if very large values are written and the fan divider is larger than 1. Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/hwmon/gl520sm.c | 27 +-- 1 file changed, 17 insertions(+), 10 deletions(-) --- a/drivers/hwmon/gl520sm.c +++ b/drivers/hwmon/gl520sm.c @@ -208,11 +208,13 @@ static ssize_t get_cpu_vid(struct device } static DEVICE_ATTR(cpu0_vid, S_IRUGO, get_cpu_vid, NULL); -#define VDD_FROM_REG(val) (((val) * 95 + 2) / 4) -#define VDD_TO_REG(val) clamp_valval) * 4 + 47) / 95), 0, 255) - -#define IN_FROM_REG(val) ((val) * 19) -#define IN_TO_REG(val) clamp_valval) + 9) / 19), 0, 255) +#define VDD_FROM_REG(val) DIV_ROUND_CLOSEST((val) * 95, 4) +#define VDD_CLAMP(val) clamp_val(val, 0, 255 * 95 / 4) +#define VDD_TO_REG(val)DIV_ROUND_CLOSEST(VDD_CLAMP(val) * 4, 95) + +#define IN_FROM_REG(val) ((val) * 19) +#define IN_CLAMP(val) clamp_val(val, 0, 255 * 19) +#define IN_TO_REG(val) DIV_ROUND_CLOSEST(IN_CLAMP(val), 19) static ssize_t get_in_input(struct device *dev, struct device_attribute *attr, char *buf) @@ -349,8 +351,13 @@ static SENSOR_DEVICE_ATTR(in4_max, S_IRU #define DIV_FROM_REG(val) (1 << (val)) #define FAN_FROM_REG(val, div) ((val) == 0 ? 0 : (48 / ((val) << (div -#define FAN_TO_REG(val, div) ((val) <= 0 ? 0 : \ - clamp_val((48 + ((val) << ((div)-1))) / ((val) << (div)), 1, 255)) + +#define FAN_BASE(div) (48 >> (div)) +#define FAN_CLAMP(val, div)clamp_val(val, FAN_BASE(div) / 255, \ + FAN_BASE(div)) +#define FAN_TO_REG(val, div) ((val) == 0 ? 0 : \ +DIV_ROUND_CLOSEST(48, \ + FAN_CLAMP(val, div) << (div))) static ssize_t get_fan_input(struct device *dev, struct device_attribute *attr, char *buf) @@ -513,9 +520,9 @@ static SENSOR_DEVICE_ATTR(fan2_div, S_IR static DEVICE_ATTR(fan1_off, S_IRUGO | S_IWUSR, get_fan_off, set_fan_off); -#define TEMP_FROM_REG(val) (((val) - 130) * 1000) -#define TEMP_TO_REG(val) clamp_val(val) < 0 ? \ - (val) - 500 : (val) + 500) / 1000) + 130), 0, 255) +#define TEMP_FROM_REG(val) (((val) - 130) * 1000) +#define TEMP_CLAMP(val)clamp_val(val, -13, 125000) +#define TEMP_TO_REG(val) (DIV_ROUND_CLOSEST(TEMP_CLAMP(val), 1000) + 130) static ssize_t get_temp_input(struct device *dev, struct device_attribute *attr, char *buf)
[PATCH 4.9 002/104] drm: bridge: add DT bindings for TI ths8135
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Bartosz Golaszewski
[ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
Link:
http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszew...@baylibre.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt | 46
++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+---
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
[PATCH 4.9 037/104] arm: dts: mt2701: Add subsystem clock controller device nodes
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: James Liao
[ Upstream commit f235c7e7a75325f28a33559a71f25a0eca6112db ]
Add MT2701 subsystem clock controllers, inlcude mmsys, imgsys,
vdecsys, hifsys, ethsys and bdpsys.
Signed-off-by: James Liao
Signed-off-by: Matthias Brugger
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/boot/dts/mt2701.dtsi | 36
1 file changed, 36 insertions(+)
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -174,4 +174,40 @@
clocks = <&uart_clk>;
status = "disabled";
};
+
+ mmsys: syscon@1400 {
+ compatible = "mediatek,mt2701-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: syscon@1500 {
+ compatible = "mediatek,mt2701-imgsys", "syscon";
+ reg = <0 0x1500 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: syscon@1600 {
+ compatible = "mediatek,mt2701-vdecsys", "syscon";
+ reg = <0 0x1600 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ hifsys: syscon@1a00 {
+ compatible = "mediatek,mt2701-hifsys", "syscon";
+ reg = <0 0x1a00 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ethsys: syscon@1b00 {
+ compatible = "mediatek,mt2701-ethsys", "syscon";
+ reg = <0 0x1b00 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ bdpsys: syscon@1c00 {
+ compatible = "mediatek,mt2701-bdpsys", "syscon";
+ reg = <0 0x1c00 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
[PATCH 4.9 003/104] GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit 14d37564fa3dc4e5d4c6828afcd26ac14e6796c5 ]
This patch fixes a place where function gfs2_glock_iter_next can
reference an invalid error pointer.
Signed-off-by: Dan Carpenter
Signed-off-by: Bob Peterson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/gfs2/glock.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1820,16 +1820,18 @@ void gfs2_glock_exit(void)
static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi)
{
- do {
- gi->gl = rhashtable_walk_next(&gi->hti);
+ while ((gi->gl = rhashtable_walk_next(&gi->hti))) {
if (IS_ERR(gi->gl)) {
if (PTR_ERR(gi->gl) == -EAGAIN)
continue;
gi->gl = NULL;
+ return;
}
- /* Skip entries for other sb and dead entries */
- } while ((gi->gl) && ((gi->sdp != gi->gl->gl_name.ln_sbd) ||
- __lockref_is_dead(&gi->gl->gl_lockref)));
+ /* Skip entries for other sb and dead entries */
+ if (gi->sdp == gi->gl->gl_name.ln_sbd &&
+ !__lockref_is_dead(&gi->gl->gl_lockref))
+ return;
+ }
}
static void *gfs2_glock_seq_start(struct seq_file *seq, loff_t *pos)
[PATCH 4.9 041/104] sfc: get PIO buffer size from the NIC
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Edward Cree
[ Upstream commit c634700f7eec3c0da46e299cd0a0ae8b594f9b55 ]
The 8000 series SFC NICs have 4K PIO buffers, rather than the 2K of
the 7000 series. Rather than having a hard-coded PIO buffer size
(ER_DZ_TX_PIOBUF_SIZE), read it from the GET_CAPABILITIES_V2 MCDI
response.
Signed-off-by: Edward Cree
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/sfc/ef10.c | 16 ++--
drivers/net/ethernet/sfc/nic.h |2 ++
drivers/net/ethernet/sfc/tx.c |1 -
3 files changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -197,11 +197,15 @@ static int efx_ef10_init_datapath_caps(s
nic_data->datapath_caps =
MCDI_DWORD(outbuf, GET_CAPABILITIES_OUT_FLAGS1);
- if (outlen >= MC_CMD_GET_CAPABILITIES_V2_OUT_LEN)
+ if (outlen >= MC_CMD_GET_CAPABILITIES_V2_OUT_LEN) {
nic_data->datapath_caps2 = MCDI_DWORD(outbuf,
GET_CAPABILITIES_V2_OUT_FLAGS2);
- else
+ nic_data->piobuf_size = MCDI_WORD(outbuf,
+ GET_CAPABILITIES_V2_OUT_SIZE_PIO_BUFF);
+ } else {
nic_data->datapath_caps2 = 0;
+ nic_data->piobuf_size = ER_DZ_TX_PIOBUF_SIZE;
+ }
/* record the DPCPU firmware IDs to determine VEB vswitching support.
*/
@@ -825,8 +829,8 @@ static int efx_ef10_link_piobufs(struct
offset = ((efx->tx_channel_offset + efx->n_tx_channels -
tx_queue->channel->channel - 1) *
efx_piobuf_size);
- index = offset / ER_DZ_TX_PIOBUF_SIZE;
- offset = offset % ER_DZ_TX_PIOBUF_SIZE;
+ index = offset / nic_data->piobuf_size;
+ offset = offset % nic_data->piobuf_size;
/* When the host page size is 4K, the first
* host page in the WC mapping may be within
@@ -1161,11 +1165,11 @@ static int efx_ef10_dimension_resources(
* functions of the controller.
*/
if (efx_piobuf_size != 0 &&
- ER_DZ_TX_PIOBUF_SIZE / efx_piobuf_size * EF10_TX_PIOBUF_COUNT >=
+ nic_data->piobuf_size / efx_piobuf_size * EF10_TX_PIOBUF_COUNT >=
efx->n_tx_channels) {
unsigned int n_piobufs =
DIV_ROUND_UP(efx->n_tx_channels,
-ER_DZ_TX_PIOBUF_SIZE / efx_piobuf_size);
+nic_data->piobuf_size / efx_piobuf_size);
rc = efx_ef10_alloc_piobufs(efx, n_piobufs);
if (rc)
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -500,6 +500,7 @@ enum {
* @pio_write_base: Base address for writing PIO buffers
* @pio_write_vi_base: Relative VI number for @pio_write_base
* @piobuf_handle: Handle of each PIO buffer allocated
+ * @piobuf_size: size of a single PIO buffer
* @must_restore_piobufs: Flag: PIO buffers have yet to be restored after MC
* reboot
* @rx_rss_context: Firmware handle for our RSS context
@@ -537,6 +538,7 @@ struct efx_ef10_nic_data {
void __iomem *wc_membase, *pio_write_base;
unsigned int pio_write_vi_base;
unsigned int piobuf_handle[EF10_TX_PIOBUF_COUNT];
+ u16 piobuf_size;
bool must_restore_piobufs;
u32 rx_rss_context;
bool rx_rss_context_exclusive;
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -27,7 +27,6 @@
#ifdef EFX_USE_PIO
-#define EFX_PIOBUF_SIZE_MAX ER_DZ_TX_PIOBUF_SIZE
#define EFX_PIOBUF_SIZE_DEF ALIGN(256, L1_CACHE_BYTES)
unsigned int efx_piobuf_size __read_mostly = EFX_PIOBUF_SIZE_DEF;
[PATCH 4.9 046/104] ath10k: prevent sta pointer rcu violation
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Michal Kazior
[ Upstream commit 0a744d927406389e00687560d9ce3c5ab0e58db9 ]
Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.
It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.
Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).
This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.
The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.
Signed-off-by: Michal Kazior
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/ath/ath10k/core.h |1 +
drivers/net/wireless/ath/ath10k/mac.c | 18 ++
2 files changed, 19 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -314,6 +314,7 @@ struct ath10k_peer {
struct ieee80211_vif *vif;
struct ieee80211_sta *sta;
+ bool removed;
int vdev_id;
u8 addr[ETH_ALEN];
DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3738,6 +3738,9 @@ struct ieee80211_txq *ath10k_mac_txq_loo
if (!peer)
return NULL;
+ if (peer->removed)
+ return NULL;
+
if (peer->sta)
return peer->sta->txq[tid];
else if (peer->vif)
@@ -7422,6 +7425,20 @@ ath10k_mac_op_switch_vif_chanctx(struct
return 0;
}
+static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+struct ieee80211_sta *sta)
+{
+ struct ath10k *ar;
+ struct ath10k_peer *peer;
+
+ ar = hw->priv;
+
+ list_for_each_entry(peer, &ar->peers, list)
+ if (peer->sta == sta)
+ peer->removed = true;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue = ath10k_mac_op_wake_tx_queue,
@@ -7462,6 +7479,7 @@ static const struct ieee80211_ops ath10k
.assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
.unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
+ .sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
[PATCH 4.9 048/104] iommu/arm-smmu: Set privileged attribute to default instead of unprivileged
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Sricharan R [ Upstream commit e19898077cfb642fe151ba22981e795c74d9e114 ] Currently the driver sets all the device transactions privileges to UNPRIVILEGED, but there are cases where the iommu masters wants to isolate privileged supervisor and unprivileged user. So don't override the privileged setting to unprivileged, instead set it to default as incoming and let it be controlled by the pagetable settings. Acked-by: Will Deacon Signed-off-by: Sricharan R Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/arm-smmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -1211,7 +1211,7 @@ static int arm_smmu_domain_add_master(st continue; s2cr[idx].type = type; - s2cr[idx].privcfg = S2CR_PRIVCFG_UNPRIV; + s2cr[idx].privcfg = S2CR_PRIVCFG_DEFAULT; s2cr[idx].cbndx = cbndx; arm_smmu_write_s2cr(smmu, idx); }
[PATCH 4.9 052/104] drm: mali-dp: Fix destination size handling when rotating
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Brian Starkey
[ Upstream commit edabb3c4cd2d035bc93a3d67b25a304ea6217301 ]
The destination rectangle provided by userspace in the CRTC_X/Y/W/H
properties is already expressed as the dimensions after rotation.
This means we shouldn't swap the width and height ourselves when a
90/270 degree rotation is requested, so remove the code doing the swap.
Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/arm/malidp_planes.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,13 +150,8 @@ static void malidp_de_plane_update(struc
/* convert src values from Q16 fixed point to integer */
src_w = plane->state->src_w >> 16;
src_h = plane->state->src_h >> 16;
- if (plane->state->rotation & MALIDP_ROTATED_MASK) {
- dest_w = plane->state->crtc_h;
- dest_h = plane->state->crtc_w;
- } else {
- dest_w = plane->state->crtc_w;
- dest_h = plane->state->crtc_h;
- }
+ dest_w = plane->state->crtc_w;
+ dest_h = plane->state->crtc_h;
malidp_hw_write(mp->hwdev, format_id, mp->layer->base);
[PATCH 4.9 044/104] ASoC: dapm: handle probe deferrals
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Walleij
[ Upstream commit 37e1df8c95e2c8a57c77eafc097648f6e40a60ff ]
This starts to handle probe deferrals on regulators and clocks
on the ASoC DAPM.
I came to this patch after audio stopped working on Ux500 ages
ago and I finally looked into it to see what is wrong. I had
messages like this in the console since a while back:
ab8500-codec.0: ASoC: Failed to request audioclk: -517
ab8500-codec.0: ASoC: Failed to create DAPM control audioclk
ab8500-codec.0: Failed to create new controls -12
snd-soc-mop500.0: ASoC: failed to instantiate card -12
snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)!
snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12
Apparently because the widget table for the codec looks like
this (sound/soc/codecs/ab8500-codec.c):
static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = {
/* Clocks */
SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"),
/* Regulators */
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0),
So when we call snd_soc_register_codec() and any of these widgets
get a deferred probe we do not get an -EPROBE_DEFER (-517) back as
we should and instead we just fail. Apparently the code assumes
that clocks and regulators must be available at this point and
not defer.
After this patch it rather looks like this:
ab8500-codec.0: Failed to create new controls -517
snd-soc-mop500.0: ASoC: failed to instantiate card -517
snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)!
(...)
abx500-clk.0: registered clocks for ab850x
snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
I'm pretty happy about the patch as it it, but I'm a bit
uncertain on how to proceed: there are a lot of users of the
external functions snd_soc_dapm_new_control() (111 sites)
and that will now return an occassional error pointer, which
is not handled in the calling sites.
I want an indication from the maintainers whether I should just
go in and augment all these call sites, or if deferred probe
is frowned upon when it leads to this much overhead.
Signed-off-by: Linus Walleij
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/soc-dapm.c | 42 ++
sound/soc/soc-topology.c |9 +
2 files changed, 51 insertions(+)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -358,6 +358,10 @@ static int dapm_kcontrol_data_alloc(stru
snd_soc_dapm_new_control_unlocked(widget->dapm,
&template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -392,6 +396,10 @@ static int dapm_kcontrol_data_alloc(stru
data->widget = snd_soc_dapm_new_control_unlocked(
widget->dapm, &template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -3311,11 +3319,22 @@ snd_soc_dapm_new_control(struct snd_soc_
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
w = snd_soc_dapm_new_control_unlocked(dapm, widget);
+ /* Do not nag about probe deferrals */
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create DAPM control %s (%d)\n",
+ widget->name, ret);
+ goto out_unlock;
+ }
if (!w)
dev_err(dapm->dev,
"ASoC: Failed to create DAPM control %s\n",
widget->name);
+out_unlock:
mutex_unlock(&dapm->card->dapm_mutex);
return w;
}
@@ -3338,6 +3357,8 @@ snd_soc_dapm_new_control_unlocked(struct
w->regulator = devm_regulator_get(dapm->dev, w->name);
if (IS_ERR(w->regulator)) {
ret = PTR_ERR(w->regulator);
+ if (ret == -EPROBE_DEFER)
+ return ERR
[PATCH 4.9 060/104] team: fix memory leaks
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Pan Bian
[ Upstream commit 72ec0bc64b9a5d8e0efcb717abfc757746b101b7 ]
In functions team_nl_send_port_list_get() and
team_nl_send_options_get(), pointer skb keeps the return value of
nlmsg_new(). When the call to genlmsg_put() fails, the memory is not
freed(). This will result in memory leak bugs.
Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options
transfers")
Signed-off-by: Pan Bian
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/team/team.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2366,8 +2366,10 @@ start_again:
hdr = genlmsg_put(skb, portid, seq, &team_nl_family, flags |
NLM_F_MULTI,
TEAM_CMD_OPTIONS_GET);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (nla_put_u32(skb, TEAM_ATTR_TEAM_IFINDEX, team->dev->ifindex))
goto nla_put_failure;
@@ -2639,8 +2641,10 @@ start_again:
hdr = genlmsg_put(skb, portid, seq, &team_nl_family, flags |
NLM_F_MULTI,
TEAM_CMD_PORT_LIST_GET);
- if (!hdr)
+ if (!hdr) {
+ nlmsg_free(skb);
return -EMSGSIZE;
+ }
if (nla_put_u32(skb, TEAM_ATTR_TEAM_IFINDEX, team->dev->ifindex))
goto nla_put_failure;
[PATCH 4.9 058/104] net: core: Prevent from dereferencing null pointer when releasing SKB
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Myungho Jung
[ Upstream commit 9899886d5e8ec5b343b1efe44f185a0e68dc6454 ]
Added NULL check to make __dev_kfree_skb_irq consistent with kfree
family of functions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
Signed-off-by: Myungho Jung
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |3 +++
1 file changed, 3 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2355,6 +2355,9 @@ void __dev_kfree_skb_irq(struct sk_buff
{
unsigned long flags;
+ if (unlikely(!skb))
+ return;
+
if (likely(atomic_read(&skb->users) == 1)) {
smp_rmb();
atomic_set(&skb->users, 0);
[PATCH 4.9 033/104] serial: 8250_port: Remove dangerous pr_debug()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Alexey Brodkin
[ Upstream commit 699a11ba7ec869b006623182881f2f1f5b4aea53 ]
With CONFIG_DYNAMIC_DEBUG if dyndbg enables debug output in
8250_port.c deadlock happens inevitably on UART IRQ handling.
That's the problematic execution path:
>8
UART IRQ:
serial8250_interrupt() ->
serial8250_handle_irq(): lock "port->lock" ->
pr_debug() ->
serial8250_console_write(): bump in locked "port->lock".
OR (if above pr_debug() gets removed):
serial8250_tx_chars() ->
pr_debug() ->
serial8250_console_write(): bump in locked "port->lock".
>8
So let's get rid of those not that much useful debug entries.
Discussed problem could be easily reproduced with QEMU for x86_64.
As well as this fix could be mimicked with muting of dynamic debug for
the problematic lines as simple as:
>8
dyndbg="+p; file 8250_port.c line 1756 -p; file 8250_port.c line 1822 -p"
>8
Signed-off-by: Alexey Brodkin
Cc: Jiri Slaby
Cc: Peter Hurley
Cc: Phillip Raffeck
Cc: Anton Wuerfel
Cc: "Matwey V. Kornilov"
Cc: Yegor Yefremov
Cc: Thor Thayer
Reviewed-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial/8250/8250_port.c |4
1 file changed, 4 deletions(-)
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1751,8 +1751,6 @@ void serial8250_tx_chars(struct uart_825
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(port);
- pr_debug("%s: THRE\n", __func__);
-
/*
* With RPM enabled, we have to wait until the FIFO is empty before the
* HW can go idle. So we get here once again with empty FIFO and disable
@@ -1817,8 +1815,6 @@ int serial8250_handle_irq(struct uart_po
status = serial_port_in(port, UART_LSR);
- pr_debug("%s: status = %x\n", __func__, status);
-
if (status & (UART_LSR_DR | UART_LSR_BI)) {
if (!up->dma || handle_rx_dma(up, iir))
status = serial8250_rx_chars(up, status);
[PATCH 4.9 078/104] nvme-rdma: handle cpu unplug when re-establishing the controller
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sagi Grimberg
[ Upstream commit c248c64387fac5a6b31b343d9acb78f478e8619c ]
If a cpu unplug event has occured, we need to take the minimum
of the provided nr_io_queues and the number of online cpus,
otherwise we won't be able to connect them as blk-mq mapping
won't dispatch to those queues.
Reviewed-by: Christoph Hellwig
Signed-off-by: Sagi Grimberg
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/nvme/host/rdma.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -337,8 +337,6 @@ static int __nvme_rdma_init_request(stru
struct ib_device *ibdev = dev->dev;
int ret;
- BUG_ON(queue_idx >= ctrl->queue_count);
-
ret = nvme_rdma_alloc_qe(ibdev, &req->sqe, sizeof(struct nvme_command),
DMA_TO_DEVICE);
if (ret)
@@ -643,8 +641,22 @@ out_free_queues:
static int nvme_rdma_init_io_queues(struct nvme_rdma_ctrl *ctrl)
{
+ struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
+ unsigned int nr_io_queues;
int i, ret;
+ nr_io_queues = min(opts->nr_io_queues, num_online_cpus());
+ ret = nvme_set_queue_count(&ctrl->ctrl, &nr_io_queues);
+ if (ret)
+ return ret;
+
+ ctrl->queue_count = nr_io_queues + 1;
+ if (ctrl->queue_count < 2)
+ return 0;
+
+ dev_info(ctrl->ctrl.device,
+ "creating %d I/O queues.\n", nr_io_queues);
+
for (i = 1; i < ctrl->queue_count; i++) {
ret = nvme_rdma_init_queue(ctrl, i,
ctrl->ctrl.opts->queue_size);
@@ -1795,20 +1807,8 @@ static const struct nvme_ctrl_ops nvme_r
static int nvme_rdma_create_io_queues(struct nvme_rdma_ctrl *ctrl)
{
- struct nvmf_ctrl_options *opts = ctrl->ctrl.opts;
int ret;
- ret = nvme_set_queue_count(&ctrl->ctrl, &opts->nr_io_queues);
- if (ret)
- return ret;
-
- ctrl->queue_count = opts->nr_io_queues + 1;
- if (ctrl->queue_count < 2)
- return 0;
-
- dev_info(ctrl->ctrl.device,
- "creating %d I/O queues.\n", opts->nr_io_queues);
-
ret = nvme_rdma_init_io_queues(ctrl);
if (ret)
return ret;
[PATCH 4.9 082/104] ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Nathan Fontenot [ Upstream commit 9501df3cd9204f5859f649182431616a31ee88a1 ] The pointer array for the tx/rx sub crqs should be free'ed when releasing the tx/rx sub crqs. Signed-off-by: Nathan Fontenot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/ibm/ibmvnic.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -1253,6 +1253,7 @@ static void release_sub_crqs(struct ibmv release_sub_crq_queue(adapter, adapter->tx_scrq[i]); } + kfree(adapter->tx_scrq); adapter->tx_scrq = NULL; } @@ -1265,6 +1266,7 @@ static void release_sub_crqs(struct ibmv release_sub_crq_queue(adapter, adapter->rx_scrq[i]); } + kfree(adapter->rx_scrq); adapter->rx_scrq = NULL; }
[PATCH 4.9 031/104] serial: 8250: moxa: Store num_ports in brd
4.9-stable review patch. If anyone has any objections, please let me know. -- From: "Matwey V. Kornilov" [ Upstream commit 9c4b60fe5313c125b1bf68ef04b0010512c27f2d ] When struct moxa8250_board is allocated, then num_ports should be initialized in order to use it later in moxa8250_remove. Signed-off-by: Matwey V. Kornilov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/tty/serial/8250/8250_moxa.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/tty/serial/8250/8250_moxa.c +++ b/drivers/tty/serial/8250/8250_moxa.c @@ -68,6 +68,7 @@ static int moxa8250_probe(struct pci_dev sizeof(unsigned int) * nr_ports, GFP_KERNEL); if (!brd) return -ENOMEM; + brd->num_ports = nr_ports; memset(&uart, 0, sizeof(struct uart_8250_port));
[PATCH 4.9 065/104] mmc: sdio: fix alignment issue in struct sdio_func
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Heiner Kallweit
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit
Tested-by: Helmut Klein
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/core/sdio_bus.c | 12 +++-
include/linux/mmc/sdio_func.h |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -266,7 +266,7 @@ static void sdio_release_func(struct dev
sdio_free_func_cis(func);
kfree(func->info);
-
+ kfree(func->tmpbuf);
kfree(func);
}
@@ -281,6 +281,16 @@ struct sdio_func *sdio_alloc_func(struct
if (!func)
return ERR_PTR(-ENOMEM);
+ /*
+* allocate buffer separately to make sure it's properly aligned for
+* DMA usage (incl. 64 bit DMA)
+*/
+ func->tmpbuf = kmalloc(4, GFP_KERNEL);
+ if (!func->tmpbuf) {
+ kfree(func);
+ return ERR_PTR(-ENOMEM);
+ }
+
func->card = card;
device_initialize(&func->dev);
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -53,7 +53,7 @@ struct sdio_func {
unsigned intstate; /* function state */
#define SDIO_STATE_PRESENT (1<<0) /* present in sysfs */
- u8 tmpbuf[4]; /* DMA:able scratch buffer */
+ u8 *tmpbuf;/* DMA:able scratch buffer */
unsignednum_info; /* number of info strings */
const char **info; /* info strings */
[PATCH 4.9 076/104] [media] exynos-gsc: Do not swap cb/cr for semi planar formats
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Thibault Saunier [ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ] In the case of semi planar formats cb and cr are in the same plane in memory, meaning that will be set to 'cb' whatever the format is, and whatever the (packed) order of those components are. Suggested-by: Nicolas Dufresne Signed-off-by: Thibault Saunier Signed-off-by: Javier Martinez Canillas Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/media/platform/exynos-gsc/gsc-core.c |2 -- 1 file changed, 2 deletions(-) --- a/drivers/media/platform/exynos-gsc/gsc-core.c +++ b/drivers/media/platform/exynos-gsc/gsc-core.c @@ -849,9 +849,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) || (frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) || - (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) || (frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) || - (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) || (frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M)) swap(addr->cb, addr->cr);
[PATCH 4.9 066/104] bridge: netlink: register netdevice before executing changelink
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ido Schimmel
[ Upstream commit 5b8d5429daa05bebef6ffd3297df3b502cc6f184 ]
Peter reported a kernel oops when executing the following command:
$ ip link add name test type bridge vlan_default_pvid 1
[13634.939408] BUG: unable to handle kernel NULL pointer dereference at
0190
[13634.939436] IP: __vlan_add+0x73/0x5f0
[...]
[13634.939783] Call Trace:
[13634.939791] ? pcpu_next_unpop+0x3b/0x50
[13634.939801] ? pcpu_alloc+0x3d2/0x680
[13634.939810] ? br_vlan_add+0x135/0x1b0
[13634.939820] ? __br_vlan_set_default_pvid.part.28+0x204/0x2b0
[13634.939834] ? br_changelink+0x120/0x4e0
[13634.939844] ? br_dev_newlink+0x50/0x70
[13634.939854] ? rtnl_newlink+0x5f5/0x8a0
[13634.939864] ? rtnl_newlink+0x176/0x8a0
[13634.939874] ? mem_cgroup_commit_charge+0x7c/0x4e0
[13634.939886] ? rtnetlink_rcv_msg+0xe1/0x220
[13634.939896] ? lookup_fast+0x52/0x370
[13634.939905] ? rtnl_newlink+0x8a0/0x8a0
[13634.939915] ? netlink_rcv_skb+0xa1/0xc0
[13634.939925] ? rtnetlink_rcv+0x24/0x30
[13634.939934] ? netlink_unicast+0x177/0x220
[13634.939944] ? netlink_sendmsg+0x2fe/0x3b0
[13634.939954] ? _copy_from_user+0x39/0x40
[13634.939964] ? sock_sendmsg+0x30/0x40
[13634.940159] ? ___sys_sendmsg+0x29d/0x2b0
[13634.940326] ? __alloc_pages_nodemask+0xdf/0x230
[13634.940478] ? mem_cgroup_commit_charge+0x7c/0x4e0
[13634.940592] ? mem_cgroup_try_charge+0x76/0x1a0
[13634.940701] ? __handle_mm_fault+0xdb9/0x10b0
[13634.940809] ? __sys_sendmsg+0x51/0x90
[13634.940917] ? entry_SYSCALL_64_fastpath+0x1e/0xad
The problem is that the bridge's VLAN group is created after setting the
default PVID, when registering the netdevice and executing its
ndo_init().
Fix this by changing the order of both operations, so that
br_changelink() is only processed after the netdevice is registered,
when the VLAN group is already initialized.
Fixes: b6677449dff6 ("bridge: netlink: call br_changelink() during
br_dev_newlink()")
Signed-off-by: Nikolay Aleksandrov
Signed-off-by: Ido Schimmel
Reported-by: Peter V. Saveliev
Tested-by: Peter V. Saveliev
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/bridge/br_netlink.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1098,11 +1098,14 @@ static int br_dev_newlink(struct net *sr
spin_unlock_bh(&br->lock);
}
- err = br_changelink(dev, tb, data);
+ err = register_netdevice(dev);
if (err)
return err;
- return register_netdevice(dev);
+ err = br_changelink(dev, tb, data);
+ if (err)
+ unregister_netdevice(dev);
+ return err;
}
static size_t br_get_size(const struct net_device *brdev)
[PATCH 4.9 068/104] Btrfs: fix potential use-after-free for cloned bio
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Liu Bo
[ Upstream commit a967efb30b3afa3d858edd6a17f544f9e9e46eea ]
KASAN reports that there is a use-after-free case of bio in btrfs_map_bio.
If we need to submit IOs to several disks at a time, the original bio
would get cloned and mapped to the destination disk, but we really should
use the original bio instead of a cloned bio to do the sanity check
because cloned bios are likely to be freed by its endio.
Reported-by: Diego
Signed-off-by: Liu Bo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/volumes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6226,7 +6226,7 @@ int btrfs_map_bio(struct btrfs_root *roo
for (dev_nr = 0; dev_nr < total_devs; dev_nr++) {
dev = bbio->stripes[dev_nr].dev;
if (!dev || !dev->bdev ||
- (bio_op(bio) == REQ_OP_WRITE && !dev->writeable)) {
+ (bio_op(first_bio) == REQ_OP_WRITE && !dev->writeable)) {
bbio_error(bbio, first_bio, logical);
continue;
}
[PATCH 4.9 089/104] md/raid10: submit bio directly to replacement disk
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Shaohua Li
[ Upstream commit 6d399783e9d4e9bd44931501948059d24ad96ff8 ]
Commit 57c67df(md/raid10: submit IO from originating thread instead of
md thread) submits bio directly for normal disks but not for replacement
disks. There is no point we shouldn't do this for replacement disks.
Cc: NeilBrown
Signed-off-by: Shaohua Li
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/raid10.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1407,11 +1407,24 @@ retry_write:
mbio->bi_private = r10_bio;
atomic_inc(&r10_bio->remaining);
+
+ cb = blk_check_plugged(raid10_unplug, mddev,
+ sizeof(*plug));
+ if (cb)
+ plug = container_of(cb, struct raid10_plug_cb,
+ cb);
+ else
+ plug = NULL;
spin_lock_irqsave(&conf->device_lock, flags);
- bio_list_add(&conf->pending_bio_list, mbio);
- conf->pending_count++;
+ if (plug) {
+ bio_list_add(&plug->pending, mbio);
+ plug->pending_cnt++;
+ } else {
+ bio_list_add(&conf->pending_bio_list, mbio);
+ conf->pending_count++;
+ }
spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!mddev_check_plugged(mddev))
+ if (!plug)
md_wakeup_thread(mddev->thread);
}
}
[PATCH 4.9 092/104] xfs: remove kmem_zalloc_greedy
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: "Darrick J. Wong"
[ Upstream commit 08b005f1333154ae5b404ca28766e0ffb9f1c150 ]
The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
it to grab 1-4 pages for staging of inobt records. The infinite loop in
the greedy allocation function is causing hangs[1] in generic/269, so
just get rid of the greedy allocator in favor of kmem_zalloc_large.
This makes bulkstat somewhat more likely to ENOMEM if there's really no
pages to spare, but eliminates a source of hangs.
[1]
http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
---
v2: remove single-page fallback
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/xfs/kmem.c | 18 --
fs/xfs/kmem.h |2 --
fs/xfs/xfs_itable.c |6 ++
3 files changed, 2 insertions(+), 24 deletions(-)
--- a/fs/xfs/kmem.c
+++ b/fs/xfs/kmem.c
@@ -24,24 +24,6 @@
#include "kmem.h"
#include "xfs_message.h"
-/*
- * Greedy allocation. May fail and may return vmalloced memory.
- */
-void *
-kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize)
-{
- void*ptr;
- size_t kmsize = maxsize;
-
- while (!(ptr = vzalloc(kmsize))) {
- if ((kmsize >>= 1) <= minsize)
- kmsize = minsize;
- }
- if (ptr)
- *size = kmsize;
- return ptr;
-}
-
void *
kmem_alloc(size_t size, xfs_km_flags_t flags)
{
--- a/fs/xfs/kmem.h
+++ b/fs/xfs/kmem.h
@@ -69,8 +69,6 @@ static inline void kmem_free(const void
}
-extern void *kmem_zalloc_greedy(size_t *, size_t, size_t);
-
static inline void *
kmem_zalloc(size_t size, xfs_km_flags_t flags)
{
--- a/fs/xfs/xfs_itable.c
+++ b/fs/xfs/xfs_itable.c
@@ -361,7 +361,6 @@ xfs_bulkstat(
xfs_agino_t agino; /* inode # in allocation group */
xfs_agnumber_t agno; /* allocation group number */
xfs_btree_cur_t *cur; /* btree cursor for ialloc btree */
- size_t irbsize; /* size of irec buffer in bytes */
xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */
int nirbuf; /* size of irbuf */
int ubcount; /* size of user's buffer */
@@ -388,11 +387,10 @@ xfs_bulkstat(
*ubcountp = 0;
*done = 0;
- irbuf = kmem_zalloc_greedy(&irbsize, PAGE_SIZE, PAGE_SIZE * 4);
+ irbuf = kmem_zalloc_large(PAGE_SIZE * 4, KM_SLEEP);
if (!irbuf)
return -ENOMEM;
-
- nirbuf = irbsize / sizeof(*irbuf);
+ nirbuf = (PAGE_SIZE * 4) / sizeof(*irbuf);
/*
* Loop over the allocation groups, starting from the last
[PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Mark Rutland [ Upstream commit b0de0ccc8b9edd8846828e0ecdc35deacdf186b0 ] Booting a v4.11-rc1 kernel with DEBUG_VIRTUAL and KASAN enabled produces the following splat (trimmed for brevity): [0.00] virt_to_phys used for non-linear address: 2808 (0x2808) [0.00] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 __virt_to_phys+0x48/0x70 [0.00] PC is at __virt_to_phys+0x48/0x70 [0.00] LR is at __virt_to_phys+0x48/0x70 [0.00] Call trace: [0.00] [] __virt_to_phys+0x48/0x70 [0.00] [] kasan_init+0x1c0/0x498 [0.00] [] setup_arch+0x2fc/0x948 [0.00] [] start_kernel+0xb8/0x570 [0.00] [] __primary_switched+0x6c/0x74 This is because we use virt_to_pfn() on a kernel image address when trying to figure out its nid, so that we can allocate its shadow from the same node. As with other recent changes, this patch uses lm_alias() to solve this. We could instead use NUMA_NO_NODE, as x86 does for all shadow allocations, though we'll likely want the "real" memory shadow to be backed from its corresponding nid anyway, so we may as well be consistent and find the nid for the image shadow. Cc: Catalin Marinas Cc: Will Deacon Acked-by: Laura Abbott Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/arm64/mm/kasan_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/mm/kasan_init.c +++ b/arch/arm64/mm/kasan_init.c @@ -153,7 +153,7 @@ void __init kasan_init(void) clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END); vmemmap_populate(kimg_shadow_start, kimg_shadow_end, -pfn_to_nid(virt_to_pfn(_text))); +pfn_to_nid(virt_to_pfn(lm_alias(_text; /* * vmemmap_populate() has populated the shadow region that covers the
[PATCH 4.9 095/104] ARM: dts: BCM5301X: Fix memory start address
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jon Mason
[ Upstream commit 88d1fa70c21d7b431386cfe70cdc514d98b0c9c4 ]
Memory starts at 0x8000, not 0. 0 "works" due to mirrior of the
first 128M of RAM to that address. Anything greater than 128M will
quickly find nothing there. Correcting the starting address has
everything working again.
Signed-off-by: Jon Mason
Fixes: 7eb05f6d ("ARM: dts: bcm5301x: Add BCM SVK DT files")
Signed-off-by: Florian Fainelli
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/boot/dts/bcm953012k.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/bcm953012k.dts
+++ b/arch/arm/boot/dts/bcm953012k.dts
@@ -48,7 +48,7 @@
};
memory {
- reg = <0x 0x1000>;
+ reg = <0x8000 0x1000>;
};
};
[PATCH 4.9 099/104] ASoC: rt5514: fix gcc-7 warning
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit 03ba791df98d15d07ea74075122af71e35c7611c upstream.
gcc-7 warns that there is a duplicate 'const' specifier in some
variables that are declared using the SOC_ENUM_SINGLE_DECL macro:
sound/soc/codecs/rt5514.c:398:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
sound/soc/codecs/rt5514.c:405:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
This removes one to fix the warning.
Fixes: 4a6180ea7399 ("ASoC: rt5514: add rt5514 codec driver")
Signed-off-by: Arnd Bergmann
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/rt5514.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/soc/codecs/rt5514.c
+++ b/sound/soc/codecs/rt5514.c
@@ -395,14 +395,14 @@ static const char * const rt5514_dmic_sr
"DMIC1", "DMIC2"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo1_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD0_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
static const struct snd_kcontrol_new rt5514_sto1_dmic_mux =
SOC_DAPM_ENUM("Stereo1 DMIC Source", rt5514_stereo1_dmic_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo2_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD1_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
[PATCH 4.9 069/104] sata_via: Enable hotplug only on VT6421
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ondrej Zary
[ Upstream commit 3cf864520e877505158f09075794a08abab11bbe ]
Commit 57e5568fda27 ("sata_via: Implement hotplug for VT6421") adds
hotplug IRQ handler for VT6421 but enables hotplug on all chips. This
is a bug because it causes "irq xx: nobody cared" error on VT6420 when
hot-(un)plugging a drive:
[ 381.839948] irq 20: nobody cared (try booting with the "irqpoll" option)
[ 381.840014] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc5+ #148
[ 381.840066] Hardware name: P4VM800/P4VM800, BIOS P1.60 05/29/2006
[ 381.840117] Call Trace:
[ 381.840167]
[ 381.840225] ? dump_stack+0x44/0x58
[ 381.840278] ? __report_bad_irq+0x14/0x97
[ 381.840327] ? handle_edge_irq+0xa5/0xa5
[ 381.840376] ? note_interrupt+0x155/0x1cf
[ 381.840426] ? handle_edge_irq+0xa5/0xa5
[ 381.840474] ? handle_irq_event_percpu+0x32/0x38
[ 381.840524] ? handle_irq_event+0x1f/0x38
[ 381.840573] ? handle_fasteoi_irq+0x69/0xb8
[ 381.840625] ? handle_irq+0x4f/0x5d
[ 381.840672]
[ 381.840726] ? do_IRQ+0x2e/0x8b
[ 381.840782] ? common_interrupt+0x2c/0x34
[ 381.840836] ? mwait_idle+0x60/0x82
[ 381.840892] ? arch_cpu_idle+0x6/0x7
[ 381.840949] ? do_idle+0x96/0x18e
[ 381.841002] ? cpu_startup_entry+0x16/0x1a
[ 381.841057] ? start_kernel+0x319/0x31c
[ 381.84] ? startup_32_smp+0x166/0x168
[ 381.841165] handlers:
[ 381.841219] [] ata_bmdma_interrupt
[ 381.841274] Disabling IRQ #20
Seems that VT6420 can do hotplug too (there's no documentation) but the
comments say that SCR register access (required for detecting hotplug
events) can cause problems on these chips.
For now, just keep hotplug disabled on anything other than VT6421.
Signed-off-by: Ondrej Zary
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/ata/sata_via.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -644,14 +644,16 @@ static void svia_configure(struct pci_de
pci_write_config_byte(pdev, SATA_NATIVE_MODE, tmp8);
}
- /* enable IRQ on hotplug */
- pci_read_config_byte(pdev, SVIA_MISC_3, &tmp8);
- if ((tmp8 & SATA_HOTPLUG) != SATA_HOTPLUG) {
- dev_dbg(&pdev->dev,
- "enabling SATA hotplug (0x%x)\n",
- (int) tmp8);
- tmp8 |= SATA_HOTPLUG;
- pci_write_config_byte(pdev, SVIA_MISC_3, tmp8);
+ if (board_id == vt6421) {
+ /* enable IRQ on hotplug */
+ pci_read_config_byte(pdev, SVIA_MISC_3, &tmp8);
+ if ((tmp8 & SATA_HOTPLUG) != SATA_HOTPLUG) {
+ dev_dbg(&pdev->dev,
+ "enabling SATA hotplug (0x%x)\n",
+ (int) tmp8);
+ tmp8 |= SATA_HOTPLUG;
+ pci_write_config_byte(pdev, SVIA_MISC_3, tmp8);
+ }
}
/*
[PATCH 4.9 071/104] kasan: do not sanitize kexec purgatory
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith [ Upstream commit 13a6798e4a03096b11bf402a063786a7be55d426 ] Fixes this: kexec: Undefined symbol: __asan_load8_noabort kexec-bzImage64: Loading purgatory failed Link: http://lkml.kernel.org/r/1489672155.4458.7.ca...@gmx.de Signed-off-by: Mike Galbraith Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/x86/purgatory/Makefile |1 + 1 file changed, 1 insertion(+) --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -8,6 +8,7 @@ PURGATORY_OBJS = $(addprefix $(obj)/,$(p LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib targets += purgatory.ro +KASAN_SANITIZE := n KCOV_INSTRUMENT := n # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
[PATCH 4.9 064/104] qed: Fix possible system hang in the dcbnl-getdcbx() path.
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: "sudarsana.kall...@cavium.com"
[ Upstream commit 62289ba27558553871fd047baadaaeda886c6a63 ]
qed_dcbnl_get_dcbx() API uses kmalloc in GFT_KERNEL mode. The API gets
invoked in the interrupt context by qed_dcbnl_getdcbx callback. Need
to invoke this kmalloc in atomic mode.
Signed-off-by: Sudarsana Reddy Kalluru
Signed-off-by: Yuval Mintz
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -1222,7 +1222,7 @@ static struct qed_dcbx_get *qed_dcbnl_ge
{
struct qed_dcbx_get *dcbx_info;
- dcbx_info = kzalloc(sizeof(*dcbx_info), GFP_KERNEL);
+ dcbx_info = kmalloc(sizeof(*dcbx_info), GFP_ATOMIC);
if (!dcbx_info)
return NULL;
[PATCH 4.9 096/104] tools/power turbostat: bugfix: GFXMHz column not changing
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Len Brown
[ Upstream commit 22048c5485503749754b3b5daf9d99ef89fcacdc ]
turbostat displays a GFXMHz column, which comes from reading
/sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz
But GFXMHz was not changing, even when a manual
cat /sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz
showed a new value.
It turns out that a rewind() on the open file is not sufficient,
fflush() (or a close/open) is needed to read fresh values.
Reported-by: Yaroslav Isakov
Signed-off-by: Len Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/power/x86/turbostat/turbostat.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -2003,8 +2003,10 @@ int snapshot_gfx_mhz(void)
if (fp == NULL)
fp =
fopen_or_die("/sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz", "r");
- else
+ else {
rewind(fp);
+ fflush(fp);
+ }
retval = fscanf(fp, "%d", &gfx_cur_mhz);
if (retval != 1)
[PATCH 4.4 01/50] drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
4.4-stable review patch. If anyone has any objections, please let me know. -- From: "Kristian H. Kristensen" [ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ] We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code() macro to work correctly. Signed-off-by: Kristian H. Kristensen Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsb...@google.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- include/uapi/drm/drm_fourcc.h |1 + 1 file changed, 1 insertion(+) --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -150,6 +150,7 @@ /* Vendor Ids: */ #define DRM_FORMAT_MOD_NONE 0 +#define DRM_FORMAT_MOD_VENDOR_NONE0 #define DRM_FORMAT_MOD_VENDOR_INTEL 0x01 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02 #define DRM_FORMAT_MOD_VENDOR_NV 0x03
[PATCH 4.4 11/50] hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Guenter Roeck [ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ] Writes into limit attributes can overflow due to multplications and additions with unbound input values. Writing into fan limit attributes can result in a crash with a division by zero if very large values are written and the fan divider is larger than 1. Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/hwmon/gl520sm.c | 27 +-- 1 file changed, 17 insertions(+), 10 deletions(-) --- a/drivers/hwmon/gl520sm.c +++ b/drivers/hwmon/gl520sm.c @@ -208,11 +208,13 @@ static ssize_t get_cpu_vid(struct device } static DEVICE_ATTR(cpu0_vid, S_IRUGO, get_cpu_vid, NULL); -#define VDD_FROM_REG(val) (((val) * 95 + 2) / 4) -#define VDD_TO_REG(val) clamp_valval) * 4 + 47) / 95), 0, 255) - -#define IN_FROM_REG(val) ((val) * 19) -#define IN_TO_REG(val) clamp_valval) + 9) / 19), 0, 255) +#define VDD_FROM_REG(val) DIV_ROUND_CLOSEST((val) * 95, 4) +#define VDD_CLAMP(val) clamp_val(val, 0, 255 * 95 / 4) +#define VDD_TO_REG(val)DIV_ROUND_CLOSEST(VDD_CLAMP(val) * 4, 95) + +#define IN_FROM_REG(val) ((val) * 19) +#define IN_CLAMP(val) clamp_val(val, 0, 255 * 19) +#define IN_TO_REG(val) DIV_ROUND_CLOSEST(IN_CLAMP(val), 19) static ssize_t get_in_input(struct device *dev, struct device_attribute *attr, char *buf) @@ -349,8 +351,13 @@ static SENSOR_DEVICE_ATTR(in4_max, S_IRU #define DIV_FROM_REG(val) (1 << (val)) #define FAN_FROM_REG(val, div) ((val) == 0 ? 0 : (48 / ((val) << (div -#define FAN_TO_REG(val, div) ((val) <= 0 ? 0 : \ - clamp_val((48 + ((val) << ((div)-1))) / ((val) << (div)), 1, 255)) + +#define FAN_BASE(div) (48 >> (div)) +#define FAN_CLAMP(val, div)clamp_val(val, FAN_BASE(div) / 255, \ + FAN_BASE(div)) +#define FAN_TO_REG(val, div) ((val) == 0 ? 0 : \ +DIV_ROUND_CLOSEST(48, \ + FAN_CLAMP(val, div) << (div))) static ssize_t get_fan_input(struct device *dev, struct device_attribute *attr, char *buf) @@ -513,9 +520,9 @@ static SENSOR_DEVICE_ATTR(fan2_div, S_IR static DEVICE_ATTR(fan1_off, S_IRUGO | S_IWUSR, get_fan_off, set_fan_off); -#define TEMP_FROM_REG(val) (((val) - 130) * 1000) -#define TEMP_TO_REG(val) clamp_val(val) < 0 ? \ - (val) - 500 : (val) + 500) / 1000) + 130), 0, 255) +#define TEMP_FROM_REG(val) (((val) - 130) * 1000) +#define TEMP_CLAMP(val)clamp_val(val, -13, 125000) +#define TEMP_TO_REG(val) (DIV_ROUND_CLOSEST(TEMP_CLAMP(val), 1000) + 130) static ssize_t get_temp_input(struct device *dev, struct device_attribute *attr, char *buf)
[PATCH 4.4 13/50] iio: adc: hx711: Add DT binding for avia,hx711
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Andreas Klinger
[ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger
Acked-by: Rob Herring
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 18 +++
Documentation/devicetree/bindings/vendor-prefixes.txt|1
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,18 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+ - avdd-supply:Definition of the regulator used as analog supply
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ avdd-suppy = <&avdd>;
+};
+
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -31,6 +31,7 @@ asahi-kasei Asahi Kasei Corp.
atmel Atmel Corporation
auoAU Optronics Corporation
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
bosch Bosch Sensortec GmbH
[PATCH 4.4 24/50] ASoC: dapm: handle probe deferrals
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Walleij
[ Upstream commit 37e1df8c95e2c8a57c77eafc097648f6e40a60ff ]
This starts to handle probe deferrals on regulators and clocks
on the ASoC DAPM.
I came to this patch after audio stopped working on Ux500 ages
ago and I finally looked into it to see what is wrong. I had
messages like this in the console since a while back:
ab8500-codec.0: ASoC: Failed to request audioclk: -517
ab8500-codec.0: ASoC: Failed to create DAPM control audioclk
ab8500-codec.0: Failed to create new controls -12
snd-soc-mop500.0: ASoC: failed to instantiate card -12
snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)!
snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12
Apparently because the widget table for the codec looks like
this (sound/soc/codecs/ab8500-codec.c):
static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = {
/* Clocks */
SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"),
/* Regulators */
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0),
So when we call snd_soc_register_codec() and any of these widgets
get a deferred probe we do not get an -EPROBE_DEFER (-517) back as
we should and instead we just fail. Apparently the code assumes
that clocks and regulators must be available at this point and
not defer.
After this patch it rather looks like this:
ab8500-codec.0: Failed to create new controls -517
snd-soc-mop500.0: ASoC: failed to instantiate card -517
snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)!
(...)
abx500-clk.0: registered clocks for ab850x
snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
I'm pretty happy about the patch as it it, but I'm a bit
uncertain on how to proceed: there are a lot of users of the
external functions snd_soc_dapm_new_control() (111 sites)
and that will now return an occassional error pointer, which
is not handled in the calling sites.
I want an indication from the maintainers whether I should just
go in and augment all these call sites, or if deferred probe
is frowned upon when it leads to this much overhead.
Signed-off-by: Linus Walleij
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/soc-dapm.c | 42 ++
sound/soc/soc-topology.c |9 +
2 files changed, 51 insertions(+)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -358,6 +358,10 @@ static int dapm_kcontrol_data_alloc(stru
snd_soc_dapm_new_control_unlocked(widget->dapm,
&template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -392,6 +396,10 @@ static int dapm_kcontrol_data_alloc(stru
data->widget = snd_soc_dapm_new_control_unlocked(
widget->dapm, &template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -3278,11 +3286,22 @@ snd_soc_dapm_new_control(struct snd_soc_
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
w = snd_soc_dapm_new_control_unlocked(dapm, widget);
+ /* Do not nag about probe deferrals */
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create DAPM control %s (%d)\n",
+ widget->name, ret);
+ goto out_unlock;
+ }
if (!w)
dev_err(dapm->dev,
"ASoC: Failed to create DAPM control %s\n",
widget->name);
+out_unlock:
mutex_unlock(&dapm->card->dapm_mutex);
return w;
}
@@ -3304,6 +3323,8 @@ snd_soc_dapm_new_control_unlocked(struct
w->regulator = devm_regulator_get(dapm->dev, w->name);
if (IS_ERR(w->regulator)) {
ret = PTR_ERR(w->regulator);
+ if (ret == -EPROBE_DEFER)
+ return ERR
[PATCH 4.4 06/50] MIPS: Ensure bss section ends on a long-aligned address
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Paul Burton [ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ] When clearing the .bss section in kernel_entry we do so using LONG_S instructions, and branch whilst the current write address doesn't equal the end of the .bss section minus the size of a long integer. The .bss section always begins at a long-aligned address and we always increment the write pointer by the size of a long integer - we therefore rely upon the .bss section ending at a long-aligned address. If this is not the case then the long-aligned write address can never be equal to the non-long-aligned end address & we will continue to increment past the end of the .bss section, attempting to zero the rest of memory. Despite this requirement that .bss end at a long-aligned address we pass 0 as the end alignment requirement to the BSS_SECTION macro and thus don't guarantee any particular alignment, allowing us to hit the error condition described above. Fix this by instead passing 8 bytes as the end alignment argument to the BSS_SECTION macro, ensuring that the end of the .bss section is always at least long-aligned. Signed-off-by: Paul Burton Cc: linux-m...@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14526/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/mips/kernel/vmlinux.lds.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -159,7 +159,7 @@ SECTIONS * Force .bss to 64K alignment so that .bss..swapper_pg_dir * gets that alignment. .sbss should be empty, so there will be * no holes after __init_end. */ - BSS_SECTION(0, 0x1, 0) + BSS_SECTION(0, 0x1, 8) _end = . ;
[PATCH 4.4 03/50] GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit 14d37564fa3dc4e5d4c6828afcd26ac14e6796c5 ]
This patch fixes a place where function gfs2_glock_iter_next can
reference an invalid error pointer.
Signed-off-by: Dan Carpenter
Signed-off-by: Bob Peterson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/gfs2/glock.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1798,16 +1798,18 @@ void gfs2_glock_exit(void)
static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi)
{
- do {
- gi->gl = rhashtable_walk_next(&gi->hti);
+ while ((gi->gl = rhashtable_walk_next(&gi->hti))) {
if (IS_ERR(gi->gl)) {
if (PTR_ERR(gi->gl) == -EAGAIN)
continue;
gi->gl = NULL;
+ return;
}
- /* Skip entries for other sb and dead entries */
- } while ((gi->gl) && ((gi->sdp != gi->gl->gl_name.ln_sbd) ||
- __lockref_is_dead(&gi->gl->gl_lockref)));
+ /* Skip entries for other sb and dead entries */
+ if (gi->sdp == gi->gl->gl_name.ln_sbd &&
+ !__lockref_is_dead(&gi->gl->gl_lockref))
+ return;
+ }
}
static void *gfs2_glock_seq_start(struct seq_file *seq, loff_t *pos)
[PATCH 4.4 25/50] audit: log 32-bit socketcalls
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Richard Guy Briggs
[ Upstream commit 62bc306e2083436675e33b5bdeb6a77907d35971 ]
32-bit socketcalls were not being logged by audit on x86_64 systems.
Log them. This is basically a duplicate of the call from
net/socket.c:sys_socketcall(), but it addresses the impedance mismatch
between 32-bit userspace process and 64-bit kernel audit.
See: https://github.com/linux-audit/audit-kernel/issues/14
Signed-off-by: Richard Guy Briggs
Acked-by: David S. Miller
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
include/linux/audit.h | 20
net/compat.c | 17 ++---
2 files changed, 34 insertions(+), 3 deletions(-)
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -281,6 +281,20 @@ static inline int audit_socketcall(int n
return __audit_socketcall(nargs, args);
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ unsigned long a[AUDITSC_ARGS];
+ int i;
+
+ if (audit_dummy_context())
+ return 0;
+
+ for (i = 0; i < nargs; i++)
+ a[i] = (unsigned long)args[i];
+ return __audit_socketcall(nargs, a);
+}
+
static inline int audit_sockaddr(int len, void *addr)
{
if (unlikely(!audit_dummy_context()))
@@ -407,6 +421,12 @@ static inline int audit_socketcall(int n
{
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ return 0;
+}
+
static inline void audit_fd_pair(int fd1, int fd2)
{ }
static inline int audit_sockaddr(int len, void *addr)
--- a/net/compat.c
+++ b/net/compat.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -767,14 +768,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd
COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
{
- int ret;
- u32 a[6];
+ u32 a[AUDITSC_ARGS];
+ unsigned int len;
u32 a0, a1;
+ int ret;
if (call < SYS_SOCKET || call > SYS_SENDMMSG)
return -EINVAL;
- if (copy_from_user(a, args, nas[call]))
+ len = nas[call];
+ if (len > sizeof(a))
+ return -EINVAL;
+
+ if (copy_from_user(a, args, len))
return -EFAULT;
+
+ ret = audit_socketcall_compat(len / sizeof(a[0]), a);
+ if (ret)
+ return ret;
+
a0 = a[0];
a1 = a[1];
[PATCH 4.4 16/50] IB/ipoib: Fix deadlock over vlan_mutex
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Feras Daoud
[ Upstream commit 1c3098cdb05207e740715857df7b0998e372f527 ]
This patch fixes Deadlock while executing ipoib_vlan_delete.
The function takes the vlan_rwsem semaphore and calls
unregister_netdevice. The later function calls
ipoib_mcast_stop_thread that cause workqueue flush.
When the queue has one of the ipoib_ib_dev_flush_xxx events,
a deadlock occur because these events also tries to catch the
same vlan_rwsem semaphore.
To fix, unregister_netdevice should be called after releasing
the semaphore.
Fixes: cbbe1efa4972 ("IPoIB: Fix deadlock between ipoib_open() and child
interface create")
Signed-off-by: Feras Daoud
Signed-off-by: Erez Shitrit
Reviewed-by: Alex Vesker
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -185,7 +185,6 @@ int ipoib_vlan_delete(struct net_device
list_for_each_entry_safe(priv, tpriv, &ppriv->child_intfs, list) {
if (priv->pkey == pkey &&
priv->child_type == IPOIB_LEGACY_CHILD) {
- unregister_netdevice(priv->dev);
list_del(&priv->list);
dev = priv->dev;
break;
@@ -193,6 +192,11 @@ int ipoib_vlan_delete(struct net_device
}
up_write(&ppriv->vlan_rwsem);
+ if (dev) {
+ ipoib_dbg(ppriv, "delete child vlan %s\n", dev->name);
+ unregister_netdevice(dev);
+ }
+
rtnl_unlock();
if (dev) {
[PATCH 4.4 18/50] IB/ipoib: Replace list_del of the neigh->list with list_del_init
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Feras Daoud
[ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
In order to resolve a situation where a few process delete
the same list element in sequence and cause panic, list_del
is replaced with list_del_init. In this case if the first
process that calls list_del releases the lock before acquiring
it again, other processes who can acquire the lock will call
list_del_init.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
Signed-off-by: Feras Daoud
Signed-off-by: Erez Shitrit
Reviewed-by: Alex Vesker
Signed-off-by: Leon Romanovsky
Reviewed-by: Yuval Shaia
Signed-off-by: Doug Ledford
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/infiniband/ulp/ipoib/ipoib_main.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1239,7 +1239,7 @@ static void __ipoib_reap_neigh(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1406,7 +1406,7 @@ void ipoib_neigh_free(struct ipoib_neigh
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
return;
} else {
@@ -1491,7 +1491,7 @@ void ipoib_del_neighs_by_gid(struct net_
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1533,7 +1533,7 @@ static void ipoib_flush_neighs(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
}
}
[PATCH 4.4 47/50] IB/qib: fix false-postive maybe-uninitialized warning
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit f6aafac184a3e46e919769dd4faa8bf0dc436534 upstream.
aarch64-linux-gcc-7 complains about code it doesn't fully understand:
drivers/infiniband/hw/qib/qib_iba7322.c: In function 'qib_7322_txchk_change':
include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
The code is right, and despite trying hard, I could not come up with a version
that I liked better than just adding a fake initialization here to shut up the
warning.
Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand
adapters")
Signed-off-by: Arnd Bergmann
Acked-by: Ira Weiny
Signed-off-by: Doug Ledford
Signed-off-by: Greg Kroah-Hartman
---
drivers/infiniband/hw/qib/qib_iba7322.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/qib/qib_iba7322.c
+++ b/drivers/infiniband/hw/qib/qib_iba7322.c
@@ -7097,7 +7097,7 @@ static void qib_7322_txchk_change(struct
unsigned long flags;
while (wait) {
- unsigned long shadow;
+ unsigned long shadow = 0;
int cstart, previ = -1;
/*
[PATCH 4.4 00/50] 4.4.91-stable review
This is the start of the stable review cycle for the 4.4.91 release. There are 50 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 8 08:36:32 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.91-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.4.91-rc1 Arnd Bergmann ttpci: address stringop overflow warning Arnd Bergmann ALSA: au88x0: avoid theoretical uninitialized access Arnd Bergmann ARM: remove duplicate 'const' annotations' Arnd Bergmann IB/qib: fix false-postive maybe-uninitialized warning Jisheng Zhang drivers: firmware: psci: drop duplicate const from psci_of_match Gwendal Grignou libata: transport: Remove circular dependency at free time Darrick J. Wong xfs: remove kmem_zalloc_greedy Heiner Kallweit i2c: meson: fix wrong variable usage in meson_i2c_put_data Shaohua Li md/raid10: submit bio directly to replacement disk Zhu Yanjun rds: ib: add error handle Oleksandr Tyshchenko iommu/io-pgtable-arm: Check for leaf entry before dereferencing it Arvind Yadav parisc: perf: Fix potential NULL pointer dereference Liping Zhang netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max Thibault Saunier exynos-gsc: Do not swap cb/cr for semi planar formats Matt Redfearn MIPS: IRQ Stack: Unwind IRQ stack onto task stack Liping Zhang netfilter: invoke synchronize_rcu after set the _hook_ to NULL Ido Schimmel bridge: netlink: register netdevice before executing changelink Heiner Kallweit mmc: sdio: fix alignment issue in struct sdio_func Roman Spychała usb: plusb: Add support for PL-27A1 Pan Bian team: fix memory leaks Alexander Potapenko net/packet: check length in getsockopt() called with PACKET_HDRLEN Myungho Jung net: core: Prevent from dereferencing null pointer when releasing SKB Arnd Bergmann MIPS: Lantiq: Fix another request_mem_region() return code check Linus Walleij ASoC: dapm: fix some pointer error handling Peter Chen usb: chipidea: vbus event may exist before starting gadget Richard Guy Briggs audit: log 32-bit socketcalls Linus Walleij ASoC: dapm: handle probe deferrals Alden Tondettar partitions/efi: Fix integer overflow in GPT size calculation Markus Elfring pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show() Johan Hovold USB: serial: mos7840: fix control-message error handling Johan Hovold USB: serial: mos7720: fix control-message error handling Pan Bian drm/amdkfd: fix improper return value on error Feras Daoud IB/ipoib: Replace list_del of the neigh->list with list_del_init Feras Daoud IB/ipoib: rtnl_unlock can not come after free_netdev Feras Daoud IB/ipoib: Fix deadlock over vlan_mutex Christophe JAILLET tty: goldfish: Fix a parameter of a call to free_irq Afzal Mohammed ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM Andreas Klinger iio: adc: hx711: Add DT binding for avia,hx711 Hans de Goede iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications Guenter Roeck hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes Niklas Söderlund sh_eth: use correct name for ECMR_MPDE bit Hans de Goede extcon: axp288: Use vbus-valid instead of -present to determine cable presence Guilherme G Piccoli igb: re-assign hw address pointer on reset after PCI error Colin Ian King MIPS: ralink: Fix incorrect assignment on ralink_soc Paul Burton MIPS: Ensure bss section ends on a long-aligned address Simon Horman ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes Santosh Shilimkar RDS: RDMA: Fix the composite message user notification Dan Carpenter GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next Bartosz Golaszewski drm: bridge: add DT bindings for TI ths8135 Kristian H. Kristensen drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define - Diffstat: .../bindings/display/bridge/ti,ths8135.txt | 46 +++ .../devicetree/bindings/iio/adc/avia-hx711.txt | 18 + .../devicetree/bindings/vendor-prefixes.txt| 1 + Makefile | 4 +- arch/arm/Kconfig-nommu | 3 +- arch/arm/boot/dts/r8a7790.dtsi | 12 ++- arch/arm/mach-at91/pm.c| 2 +- arch/arm/mach-bcm/bcm_kona_smc.c | 2 +- arch/arm/mach-cns3xxx
[PATCH 4.4 08/50] igb: re-assign hw address pointer on reset after PCI error
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Guilherme G Piccoli [ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ] Whenever the igb driver detects the result of a read operation returns a value composed only by F's (like 0x), it will detach the net_device, clear the hw_addr pointer and warn to the user that adapter's link is lost - those steps happen on igb_rd32(). In case a PCI error happens on Power architecture, there's a recovery mechanism called EEH, that will reset the PCI slot and call driver's handlers to reset the adapter and network functionality as well. We observed that once hw_addr is NULL after the error is detected on igb_rd32(), it's never assigned back, so in the process of resetting the network functionality we got a NULL pointer dereference in both igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid such bug, this patch re-assigns the hw_addr value in the slot_reset handler. Reported-by: Anthony H Thai Reported-by: Harsha Thyagaraja Signed-off-by: Guilherme G Piccoli Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/intel/igb/igb_main.c |5 + 1 file changed, 5 insertions(+) --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -7658,6 +7658,11 @@ static pci_ers_result_t igb_io_slot_rese pci_enable_wake(pdev, PCI_D3hot, 0); pci_enable_wake(pdev, PCI_D3cold, 0); + /* In case of PCI error, adapter lose its HW address +* so we should re-assign it here. +*/ + hw->hw_addr = adapter->io_addr; + igb_reset(adapter); wr32(E1000_WUS, ~0); result = PCI_ERS_RESULT_RECOVERED;
[PATCH 4.4 50/50] [media] ttpci: address stringop overflow warning
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit 69d3973af1acd4c0989ec8218c05f12d303cd7cf upstream.
gcc-7.0.1 warns about old code in ttpci:
In file included from drivers/media/pci/ttpci/av7110.c:63:0:
In function 'irdebi.isra.2',
inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:659:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size
between 18446744071562067968 and 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
memcpy(av7110->debi_virt, (char *) &res, count);
In function 'irdebi.isra.2',
inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:668:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size
between 18446744071562067968 and 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
memcpy(av7110->debi_virt, (char *) &res, count);
Apparently, 'count' can be negative here, which will then get turned
into a giant size argument for memcpy. Changing the sizes to 'unsigned
int' instead seems safe as we already check for maximum sizes, and it
also simplifies the code a bit.
Signed-off-by: Arnd Bergmann
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/pci/ttpci/av7110_hw.c |8
drivers/media/pci/ttpci/av7110_hw.h | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/media/pci/ttpci/av7110_hw.c
+++ b/drivers/media/pci/ttpci/av7110_hw.c
@@ -56,11 +56,11 @@
by Nathan Laredo */
int av7110_debiwrite(struct av7110 *av7110, u32 config,
-int addr, u32 val, int count)
+int addr, u32 val, unsigned int count)
{
struct saa7146_dev *dev = av7110->dev;
- if (count <= 0 || count > 32764) {
+ if (count > 32764) {
printk("%s: invalid count %d\n", __func__, count);
return -1;
}
@@ -78,12 +78,12 @@ int av7110_debiwrite(struct av7110 *av71
return 0;
}
-u32 av7110_debiread(struct av7110 *av7110, u32 config, int addr, int count)
+u32 av7110_debiread(struct av7110 *av7110, u32 config, int addr, unsigned int
count)
{
struct saa7146_dev *dev = av7110->dev;
u32 result = 0;
- if (count > 32764 || count <= 0) {
+ if (count > 32764) {
printk("%s: invalid count %d\n", __func__, count);
return 0;
}
--- a/drivers/media/pci/ttpci/av7110_hw.h
+++ b/drivers/media/pci/ttpci/av7110_hw.h
@@ -377,14 +377,14 @@ extern int av7110_fw_request(struct av71
/* DEBI (saa7146 data extension bus interface) access */
extern int av7110_debiwrite(struct av7110 *av7110, u32 config,
- int addr, u32 val, int count);
+ int addr, u32 val, unsigned int count);
extern u32 av7110_debiread(struct av7110 *av7110, u32 config,
- int addr, int count);
+ int addr, unsigned int count);
/* DEBI during interrupt */
/* single word writes */
-static inline void iwdebi(struct av7110 *av7110, u32 config, int addr, u32
val, int count)
+static inline void iwdebi(struct av7110 *av7110, u32 config, int addr, u32
val, unsigned int count)
{
av7110_debiwrite(av7110, config, addr, val, count);
}
@@ -397,7 +397,7 @@ static inline void mwdebi(struct av7110
av7110_debiwrite(av7110, config, addr, 0, count);
}
-static inline u32 irdebi(struct av7110 *av7110, u32 config, int addr, u32 val,
int count)
+static inline u32 irdebi(struct av7110 *av7110, u32 config, int addr, u32 val,
unsigned int count)
{
u32 res;
@@ -408,7 +408,7 @@ static inline u32 irdebi(struct av7110 *
}
/* DEBI outside interrupts, only for count <= 4! */
-static inline void wdebi(struct av7110 *av7110, u32 config, int addr, u32 val,
int count)
+static inline void wdebi(struct av7110 *av7110, u32 config, int addr, u32 val,
unsigned int count)
{
unsigned long flags;
@@ -417,7 +417,7 @@ static inline void wdebi(struct av7110 *
spin_unlock_irqrestore(&av7110->debilock, flags);
}
-static inline u32 rdebi(struct av7110 *av7110, u32 config, int addr, u32 val,
int count)
+static inline u32 rdebi(struct av7110 *av7110, u32 config, int addr, u32 val,
unsigned int count)
{
unsigned long flags;
u32 res;
[PATCH 4.4 35/50] netfilter: invoke synchronize_rcu after set the _hook_ to NULL
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Liping Zhang
[ Upstream commit 3b7dabf029478bb80507a6c4500ca94132a2bc0b ]
Otherwise, another CPU may access the invalid pointer. For example:
CPU0CPU1
- rcu_read_lock();
- pfunc = _hook_;
_hook_ = NULL; -
mod unload -
- pfunc(); // invalid, panic
- rcu_read_unlock();
So we must call synchronize_rcu() to wait the rcu reader to finish.
Also note, in nf_nat_snmp_basic_fini, synchronize_rcu() will be invoked
by later nf_conntrack_helper_unregister, but I'm inclined to add a
explicit synchronize_rcu after set the nf_nat_snmp_hook to NULL. Depend
on such obscure assumptions is not a good idea.
Last, in nfnetlink_cttimeout, we use kfree_rcu to free the time object,
so in cttimeout_exit, invoking rcu_barrier() is not necessary at all,
remove it too.
Signed-off-by: Liping Zhang
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/netfilter/nf_nat_snmp_basic.c |1 +
net/netfilter/nf_conntrack_ecache.c|2 ++
net/netfilter/nf_conntrack_netlink.c |1 +
net/netfilter/nf_nat_core.c|2 ++
net/netfilter/nfnetlink_cttimeout.c|2 +-
5 files changed, 7 insertions(+), 1 deletion(-)
--- a/net/ipv4/netfilter/nf_nat_snmp_basic.c
+++ b/net/ipv4/netfilter/nf_nat_snmp_basic.c
@@ -1304,6 +1304,7 @@ static int __init nf_nat_snmp_basic_init
static void __exit nf_nat_snmp_basic_fini(void)
{
RCU_INIT_POINTER(nf_nat_snmp_hook, NULL);
+ synchronize_rcu();
nf_conntrack_helper_unregister(&snmp_trap_helper);
}
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -200,6 +200,7 @@ void nf_conntrack_unregister_notifier(st
BUG_ON(notify != new);
RCU_INIT_POINTER(net->ct.nf_conntrack_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
+ /* synchronize_rcu() is called from ctnetlink_exit. */
}
EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);
@@ -236,6 +237,7 @@ void nf_ct_expect_unregister_notifier(st
BUG_ON(notify != new);
RCU_INIT_POINTER(net->ct.nf_expect_event_cb, NULL);
mutex_unlock(&nf_ct_ecache_mutex);
+ /* synchronize_rcu() is called from ctnetlink_exit. */
}
EXPORT_SYMBOL_GPL(nf_ct_expect_unregister_notifier);
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -3415,6 +3415,7 @@ static void __exit ctnetlink_exit(void)
#ifdef CONFIG_NETFILTER_NETLINK_GLUE_CT
RCU_INIT_POINTER(nfnl_ct_hook, NULL);
#endif
+ synchronize_rcu();
}
module_init(ctnetlink_init);
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -892,6 +892,8 @@ static void __exit nf_nat_cleanup(void)
#ifdef CONFIG_XFRM
RCU_INIT_POINTER(nf_nat_decode_session_hook, NULL);
#endif
+ synchronize_rcu();
+
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
synchronize_net();
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -611,8 +611,8 @@ static void __exit cttimeout_exit(void)
#ifdef CONFIG_NF_CONNTRACK_TIMEOUT
RCU_INIT_POINTER(nf_ct_timeout_find_get_hook, NULL);
RCU_INIT_POINTER(nf_ct_timeout_put_hook, NULL);
+ synchronize_rcu();
#endif /* CONFIG_NF_CONNTRACK_TIMEOUT */
- rcu_barrier();
}
module_init(cttimeout_init);
[PATCH 4.4 40/50] iommu/io-pgtable-arm: Check for leaf entry before dereferencing it
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Oleksandr Tyshchenko
[ Upstream commit ed46e66cc1b3d684042f92dfa2ab15ee917b4cac ]
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko
CC: Will Deacon
CC: Robin Murphy
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/iommu/io-pgtable-arm.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -335,8 +335,12 @@ static int __arm_lpae_map(struct arm_lpa
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
pte |= ARM_LPAE_PTE_NSTABLE;
__arm_lpae_set_pte(ptep, pte, cfg);
- } else {
+ } else if (!iopte_leaf(pte, lvl)) {
cptep = iopte_deref(pte, data);
+ } else {
+ /* We require an unmap first */
+ WARN_ON(!selftest_running);
+ return -EEXIST;
}
/* Rinse, repeat */
[PATCH 4.4 46/50] drivers: firmware: psci: drop duplicate const from psci_of_match
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jisheng Zhang
commit 1d2d8de44a6c20af262b4c3d3b93ef7ec3c5488e upstream.
This is to fix below sparse warning:
drivers/firmware/psci.c:mmm:nn: warning: duplicate const
Signed-off-by: Jisheng Zhang
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
---
drivers/firmware/psci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -424,7 +424,7 @@ out_put_node:
return err;
}
-static const struct of_device_id const psci_of_match[] __initconst = {
+static const struct of_device_id psci_of_match[] __initconst = {
{ .compatible = "arm,psci", .data = psci_0_1_init},
{ .compatible = "arm,psci-0.2", .data = psci_0_2_init},
{ .compatible = "arm,psci-1.0", .data = psci_0_2_init},
[PATCH 4.4 43/50] i2c: meson: fix wrong variable usage in meson_i2c_put_data
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Heiner Kallweit
[ Upstream commit 3b0277f198ac928f323c42e180680d2f79aa980d ]
Most likely a copy & paste error.
Signed-off-by: Heiner Kallweit
Acked-by: Jerome Brunet
Signed-off-by: Wolfram Sang
Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller")
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/i2c/busses/i2c-meson.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -175,7 +175,7 @@ static void meson_i2c_put_data(struct me
wdata1 |= *buf++ << ((i - 4) * 8);
writel(wdata0, i2c->regs + REG_TOK_WDATA0);
- writel(wdata0, i2c->regs + REG_TOK_WDATA1);
+ writel(wdata1, i2c->regs + REG_TOK_WDATA1);
dev_dbg(i2c->dev, "%s: data %08x %08x len %d\n", __func__,
wdata0, wdata1, len);
[PATCH 4.4 37/50] [media] exynos-gsc: Do not swap cb/cr for semi planar formats
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Thibault Saunier [ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ] In the case of semi planar formats cb and cr are in the same plane in memory, meaning that will be set to 'cb' whatever the format is, and whatever the (packed) order of those components are. Suggested-by: Nicolas Dufresne Signed-off-by: Thibault Saunier Signed-off-by: Javier Martinez Canillas Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/media/platform/exynos-gsc/gsc-core.c |2 -- 1 file changed, 2 deletions(-) --- a/drivers/media/platform/exynos-gsc/gsc-core.c +++ b/drivers/media/platform/exynos-gsc/gsc-core.c @@ -849,9 +849,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) || (frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) || - (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) || (frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) || - (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) || (frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M)) swap(addr->cb, addr->cr);
[PATCH 4.4 39/50] parisc: perf: Fix potential NULL pointer dereference
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Arvind Yadav
[ Upstream commit 74e3f6e63da6c8e8246fba1689e040bc926b4a1a ]
Fix potential NULL pointer dereference and clean up
coding style errors (code indent, trailing whitespaces).
Signed-off-by: Arvind Yadav
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/parisc/kernel/perf.c | 94 +++---
1 file changed, 49 insertions(+), 45 deletions(-)
--- a/arch/parisc/kernel/perf.c
+++ b/arch/parisc/kernel/perf.c
@@ -39,7 +39,7 @@
* the PDC INTRIGUE calls. This is done to eliminate bugs introduced
* in various PDC revisions. The code is much more maintainable
* and reliable this way vs having to debug on every version of PDC
- * on every box.
+ * on every box.
*/
#include
@@ -195,8 +195,8 @@ static int perf_config(uint32_t *image_p
static int perf_release(struct inode *inode, struct file *file);
static int perf_open(struct inode *inode, struct file *file);
static ssize_t perf_read(struct file *file, char __user *buf, size_t cnt,
loff_t *ppos);
-static ssize_t perf_write(struct file *file, const char __user *buf, size_t
count,
- loff_t *ppos);
+static ssize_t perf_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos);
static long perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
static void perf_start_counters(void);
static int perf_stop_counters(uint32_t *raddr);
@@ -222,7 +222,7 @@ extern void perf_intrigue_disable_perf_c
/*
* configure:
*
- * Configure the cpu with a given data image. First turn off the counters,
+ * Configure the cpu with a given data image. First turn off the counters,
* then download the image, then turn the counters back on.
*/
static int perf_config(uint32_t *image_ptr)
@@ -234,7 +234,7 @@ static int perf_config(uint32_t *image_p
error = perf_stop_counters(raddr);
if (error != 0) {
printk("perf_config: perf_stop_counters = %ld\n", error);
- return -EINVAL;
+ return -EINVAL;
}
printk("Preparing to write image\n");
@@ -242,7 +242,7 @@ printk("Preparing to write image\n");
error = perf_write_image((uint64_t *)image_ptr);
if (error != 0) {
printk("perf_config: DOWNLOAD = %ld\n", error);
- return -EINVAL;
+ return -EINVAL;
}
printk("Preparing to start counters\n");
@@ -254,7 +254,7 @@ printk("Preparing to start counters\n");
}
/*
- * Open the device and initialize all of its memory. The device is only
+ * Open the device and initialize all of its memory. The device is only
* opened once, but can be "queried" by multiple processes that know its
* file descriptor.
*/
@@ -298,8 +298,8 @@ static ssize_t perf_read(struct file *fi
* called on the processor that the download should happen
* on.
*/
-static ssize_t perf_write(struct file *file, const char __user *buf, size_t
count,
- loff_t *ppos)
+static ssize_t perf_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
{
int err;
size_t image_size;
@@ -307,11 +307,11 @@ static ssize_t perf_write(struct file *f
uint32_t interface_type;
uint32_t test;
- if (perf_processor_interface == ONYX_INTF)
+ if (perf_processor_interface == ONYX_INTF)
image_size = PCXU_IMAGE_SIZE;
- else if (perf_processor_interface == CUDA_INTF)
+ else if (perf_processor_interface == CUDA_INTF)
image_size = PCXW_IMAGE_SIZE;
- else
+ else
return -EFAULT;
if (!capable(CAP_SYS_ADMIN))
@@ -331,22 +331,22 @@ static ssize_t perf_write(struct file *f
/* First check the machine type is correct for
the requested image */
-if (((perf_processor_interface == CUDA_INTF) &&
- (interface_type != CUDA_INTF)) ||
- ((perf_processor_interface == ONYX_INTF) &&
- (interface_type != ONYX_INTF)))
+ if (((perf_processor_interface == CUDA_INTF) &&
+ (interface_type != CUDA_INTF)) ||
+ ((perf_processor_interface == ONYX_INTF) &&
+ (interface_type != ONYX_INTF)))
return -EINVAL;
/* Next check to make sure the requested image
is valid */
- if (((interface_type == CUDA_INTF) &&
+ if (((interface_type == CUDA_INTF) &&
(test >= MAX_CUDA_IMAGES)) ||
- ((interface_type == ONYX_INTF) &&
- (test >= MAX_ONYX_IMAGES)))
+ ((interface_type == ONYX_INTF) &&
+ (test >= MAX_ONYX_IMAGES)))
return -EINVAL;
/* Copy the image into the processor */
- if (interface_type == CUDA_INTF)
+ if (
[PATCH 4.4 33/50] mmc: sdio: fix alignment issue in struct sdio_func
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Heiner Kallweit
[ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]
Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
small DMA buffer not meeting this requirement.
When testing switching to descriptor chain mode in meson-gx driver
SDIO is broken therefore. Fix this by allocating the small DMA buffer
separately as kmalloc ensures that the returned memory area is
properly aligned for every basic data type.
Signed-off-by: Heiner Kallweit
Tested-by: Helmut Klein
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/core/sdio_bus.c | 12 +++-
include/linux/mmc/sdio_func.h |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -266,7 +266,7 @@ static void sdio_release_func(struct dev
sdio_free_func_cis(func);
kfree(func->info);
-
+ kfree(func->tmpbuf);
kfree(func);
}
@@ -281,6 +281,16 @@ struct sdio_func *sdio_alloc_func(struct
if (!func)
return ERR_PTR(-ENOMEM);
+ /*
+* allocate buffer separately to make sure it's properly aligned for
+* DMA usage (incl. 64 bit DMA)
+*/
+ func->tmpbuf = kmalloc(4, GFP_KERNEL);
+ if (!func->tmpbuf) {
+ kfree(func);
+ return ERR_PTR(-ENOMEM);
+ }
+
func->card = card;
device_initialize(&func->dev);
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -53,7 +53,7 @@ struct sdio_func {
unsigned intstate; /* function state */
#define SDIO_STATE_PRESENT (1<<0) /* present in sysfs */
- u8 tmpbuf[4]; /* DMA:able scratch buffer */
+ u8 *tmpbuf;/* DMA:able scratch buffer */
unsignednum_info; /* number of info strings */
const char **info; /* info strings */
[PATCH 4.4 29/50] net: core: Prevent from dereferencing null pointer when releasing SKB
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Myungho Jung
[ Upstream commit 9899886d5e8ec5b343b1efe44f185a0e68dc6454 ]
Added NULL check to make __dev_kfree_skb_irq consistent with kfree
family of functions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
Signed-off-by: Myungho Jung
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |3 +++
1 file changed, 3 insertions(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2338,6 +2338,9 @@ void __dev_kfree_skb_irq(struct sk_buff
{
unsigned long flags;
+ if (unlikely(!skb))
+ return;
+
if (likely(atomic_read(&skb->users) == 1)) {
smp_rmb();
atomic_set(&skb->users, 0);
